diff --git a/docs/工程优化与Feature清单.md b/docs/工程优化与Feature清单.md
new file mode 100644
index 0000000..8b383d7
--- /dev/null
+++ b/docs/工程优化与Feature清单.md
@@ -0,0 +1,742 @@
+# ABOT 工程优化与 Feature 清单
+
+## 1. 文档目标
+
+本文档用于沉淀当前 ABOT 项目的工程化分析结论，并整理一份可直接进入迭代排期的优化清单。
+
+适用场景：
+
+- 作为后续软件工程优化的总入口
+- 作为版本规划与任务拆解的基础文档
+- 作为功能优化、性能治理、可维护性建设的统一 backlog
+
+本文重点不放在“再增加多少新功能”，而放在“如何让现有系统更稳、更快、更安全、更好维护、更好用”。
+
+## 2. 项目现状判断
+
+从当前仓库结构、主链路代码、插件体系、后台管理端、存储层与 AI 能力来看，ABOT 已经属于一个具备完整产品雏形的机器人系统，而不是简单的脚本集合。
+
+当前已经具备的核心能力包括：
+
+- 微信消息接入与机器人主循环
+- 插件化消息处理框架
+- 管理后台与部分运营配置能力
+- MySQL 与 Redis 双存储体系
+- 定时任务与系统任务加载机制
+- AI 自动回复、消息总结、群画像、内容生成等能力
+- 群管理、积分、媒体处理、排行榜、消息归档等业务功能
+
+整体评价如下：
+
+- 功能广度：较强
+- 产品雏形完整度：较高
+- 工程化成熟度：中等偏上，但仍有明显提升空间
+- 可运维性：初步具备，但距离稳定线上系统还有差距
+- 可扩展性：架构方向正确，但治理能力不足
+
+## 3. 当前主要问题
+
+### 3.1 安全性问题
+
+当前最优先的问题不是新功能不足，而是安全基线偏弱。
+
+主要体现在：
+
+- 配置文件中直接保存数据库、Redis、邮箱、LLM 等敏感凭据
+- 后台存在默认账号回退逻辑，部署时容易留下弱口令入口
+- Flask `secret_key` 仍是固定值，不适合正式环境
+- 缺少系统级的鉴权审计、登录失败限流、会话超时等安全能力
+
+影响：
+
+- 一旦仓库泄露或服务器暴露，风险较大
+- 配置难以安全迁移到多环境部署
+- 后台权限控制不足时，容易产生误操作与未授权访问问题
+
+### 3.2 可测试性不足
+
+当前项目已经很大，但自动化测试覆盖明显不足。
+
+主要体现在：
+
+- 缺少完整的单元测试体系
+- 缺少核心链路集成测试
+- 缺少 CI 自动校验流程
+- 功能越多，回归风险越高
+
+影响：
+
+- 每次改动都更依赖人工回归
+- 插件之间联动问题不容易提前暴露
+- 随着代码规模继续增长，维护成本会快速上升
+
+### 3.3 可观测性不足
+
+当前项目已经有日志，但还没有形成真正的观测体系。
+
+主要体现在：
+
+- 日志有了，但缺少统一指标
+- 缺少消息链路追踪
+- 缺少插件耗时、错误率、队列积压等核心监控
+- 缺少可直接定位性能瓶颈的后台页面
+
+影响：
+
+- 系统一旦变慢，很难快速定位是哪一层出问题
+- 很难为扩容、限流、降级提供数据支撑
+- 排障过程较依赖人工经验
+
+### 3.4 性能与吞吐风险
+
+消息处理主链路已经做了部分异步和并发控制，但仍有几个潜在热点：
+
+- 插件处理仍以串行判定为主，插件数量增加后会放大延迟
+- 事件系统是轻量同步发布模型，慢回调会影响主流程
+- 消息归档、媒体处理、AI 调用都可能形成局部阻塞
+- Redis 和数据库部分写法在高消息量场景下会出现额外开销
+
+影响：
+
+- 高峰期可能出现处理延迟上升
+- 群聊现场感会受到影响，尤其是 AI 即时回复场景
+- 单个插件异常时，可能拖慢整体系统
+
+### 3.5 插件治理能力不足
+
+当前插件架构已经是项目的核心优势，但治理层能力还不够强。
+
+主要体现在：
+
+- 插件有加载、启停、热更新，但缺少健康评分与故障隔离
+- 缺少插件依赖声明
+- 缺少插件资源配额机制
+- 缺少插件级性能统计与错误统计
+- 缺少插件升级兼容性约束
+
+影响：
+
+- 插件数量越多，系统复杂度越高
+- 新插件接入成本逐步上升
+- 问题出现时难以快速判断是哪个插件导致
+
+### 3.6 数据层职责逐渐变重
+
+随着功能增长，消息表、统计逻辑、媒体处理、成员画像、群画像等数据能力不断叠加，数据访问层已经有膨胀趋势。
+
+主要体现在：
+
+- 某些数据访问文件职责过多
+- 存储结构逐步同时承担在线查询、统计分析、排障追踪等多类用途
+- 部分统计逻辑仍偏“业务脚本式”，而不是标准的数据汇总链路
+
+影响：
+
+- 后续维护成本会继续升高
+- 查询性能优化难度会越来越大
+- 数据模型的边界容易变模糊
+
+### 3.7 后台可运维能力还不够
+
+当前后台已经能完成很多管理动作，但更像是“功能页面集合”，还不完全是“系统运维控制台”。
+
+主要体现在：
+
+- 缺少系统健康总览
+- 缺少任务运行历史与失败重试中心
+- 缺少插件运行态可视化
+- 缺少关键配置变更审计
+- 缺少管理员行为日志
+
+影响：
+
+- 后期维护仍要依赖日志和人工排查
+- 运维动作不够可追踪
+- 一旦项目规模变大，后台会逐渐不够用
+
+### 3.8 用户体验仍有提升空间
+
+项目已经具备很多能力，但从普通用户和群管理员角度看，仍有一些典型改进点。
+
+主要体现在：
+
+- 命令发现成本较高
+- 功能启用状态不够透明
+- 群级个性化配置入口不统一
+- AI 能力较强，但可控性和可解释性还可以继续提升
+
+影响：
+
+- 新用户上手门槛仍偏高
+- 管理员配置成本较高
+- 功能多，但不一定都能被真正使用起来
+
+## 4. 优化原则
+
+建议后续优化遵循以下原则：
+
+### 4.1 先补工程底座，再扩业务上限
+
+优先处理安全、测试、监控、性能、插件治理，再继续叠加复杂功能。
+
+### 4.2 优先做“能降低长期维护成本”的能力
+
+例如：
+
+- 自动化测试
+- 配置治理
+- 指标与追踪
+- 插件治理
+- 运维后台
+
+这些能力虽然短期不一定最显眼，但对项目长期价值最高。
+
+### 4.3 优先做“能支撑更多功能继续增长”的通用平台能力
+
+例如：
+
+- 任务中心
+- 插件元数据中心
+- 群级配置中心
+- AI 成本与策略中心
+
+这些能力做好后，后面新增业务插件的成本会明显下降。
+
+## 5. Feature Backlog
+
+以下 backlog 按优先级拆分为 P0、P1、P2。
+
+说明：
+
+- P0：建议立即进入迭代
+- P1：建议在 P0 后连续推进
+- P2：可作为增强项逐步建设
+
+---
+
+## 6. P0 优先级清单
+
+### 6.1 配置与密钥治理中心
+
+目标：
+
+- 把敏感配置从仓库中剥离
+- 支持多环境部署
+- 减少误配置导致的线上事故
+
+建议内容：
+
+- 引入 `.env` 或环境变量注入机制
+- 提供 `config.example.yaml`
+- 启动时增加配置完整性检查
+- 后台展示配置时自动脱敏
+- 区分开发、测试、生产环境配置
+
+预期收益：
+
+- 大幅降低密钥泄露风险
+- 降低部署与迁移成本
+- 提高配置管理规范性
+
+涉及模块：
+
+- `configuration.py`
+- `config.yaml`
+- `admin/dashboard`
+- 各插件 `config.toml`
+
+### 6.2 后台安全增强
+
+目标：
+
+- 提高后台管理面的安全基线
+
+建议内容：
+
+- 首次部署强制修改默认管理员密码
+- 登录失败次数限制
+- 会话过期机制
+- 安全 Cookie 配置
+- 关键操作审计日志
+- 后台密码复杂度校验
+
+预期收益：
+
+- 降低后台被暴力尝试和弱口令利用的风险
+- 提高运维操作可追踪性
+
+涉及模块：
+
+- `admin/dashboard/server.py`
+- `admin/dashboard/blueprints/auth.py`
+- `db/admin_account_db.py`
+
+### 6.3 自动化测试基线建设
+
+目标：
+
+- 为高风险核心链路补齐最基础的质量门
+
+建议内容：
+
+- 建立 `pytest` 测试框架
+- 补充配置解析测试
+- 补充插件加载测试
+- 补充消息归档测试
+- 补充后台登录测试
+- 引入基本的 mock 和 fixture 机制
+
+预期收益：
+
+- 降低后续改动的回归风险
+- 提高重构信心
+
+涉及模块：
+
+- `test/`
+- `base/plugin_common/`
+- `db/`
+- `admin/dashboard/`
+
+### 6.4 CI 持续集成
+
+目标：
+
+- 每次提交自动做基础质量校验
+
+建议内容：
+
+- 增加 GitHub Actions 工作流
+- 自动执行测试
+- 自动执行基础 lint
+- 校验关键文档与配置模板是否存在
+
+预期收益：
+
+- 让质量校验前置
+- 减少“提交后才发现明显问题”的情况
+
+涉及模块：
+
+- `.github/workflows/`
+
+### 6.5 系统健康与观测面板
+
+目标：
+
+- 让系统运行状态可视化、可量化
+
+建议内容：
+
+- 增加系统吞吐量指标
+- 增加插件成功率与错误率统计
+- 增加 AI 调用耗时统计
+- 增加消息处理延迟监控
+- 增加 Redis/MySQL 连接状态展示
+- 增加最近错误摘要面板
+
+预期收益：
+
+- 快速发现故障
+- 为性能优化提供真实数据
+
+涉及模块：
+
+- `admin/dashboard/`
+- `robot.py`
+- `main.py`
+- `utils/ai/`
+
+### 6.6 消息链路 Trace 能力
+
+目标：
+
+- 对单条消息实现“从接收到发送”的全链路追踪
+
+建议内容：
+
+- 为每条消息生成统一 trace_id
+- 日志中贯穿 trace_id
+- 插件处理结果绑定 trace_id
+- AI 请求与消息发送动作绑定 trace_id
+
+预期收益：
+
+- 排障效率大幅提升
+- 更容易定位慢点与错误点
+
+涉及模块：
+
+- `robot.py`
+- `base/plugin_common/`
+- `utils/ai/`
+- `utils/wechat/`
+
+---
+
+## 7. P1 优先级清单
+
+### 7.1 插件治理中心
+
+目标：
+
+- 把插件系统从“可加载”升级为“可治理”
+
+建议内容：
+
+- 插件元信息页面
+- 插件依赖声明
+- 插件配置校验
+- 插件运行状态监控
+- 最近错误记录
+- 插件性能排名
+
+预期收益：
+
+- 提高插件系统可维护性
+- 降低多插件并行增长的复杂度
+
+涉及模块：
+
+- `base/plugin_common/plugin_manager.py`
+- `base/plugin_common/plugin_registry.py`
+- `admin/dashboard/`
+
+### 7.2 插件超时、熔断与隔离
+
+目标：
+
+- 防止单插件问题拖垮整体系统
+
+建议内容：
+
+- 插件处理超时控制
+- 连续失败自动熔断
+- 熔断后定时恢复探测
+- 插件错误隔离与状态降级
+
+预期收益：
+
+- 提高整体稳定性
+- 降低故障扩散风险
+
+涉及模块：
+
+- `robot.py`
+- `base/plugin_common/`
+
+### 7.3 后台任务中心
+
+目标：
+
+- 让定时任务真正可管理、可追踪
+
+建议内容：
+
+- 展示任务执行历史
+- 展示上次成功时间和上次失败原因
+- 支持手动触发任务
+- 支持失败重试
+- 支持任务启停与审计
+
+预期收益：
+
+- 大幅提升后台运维能力
+- 降低定时任务异常后的排查成本
+
+涉及模块：
+
+- `utils/system_jobs.py`
+- `utils/plugin_schedule_manager.py`
+- `db/system_job_db.py`
+- `db/plugin_schedule_db.py`
+- `admin/dashboard/`
+
+### 7.4 数据层性能优化
+
+目标：
+
+- 提高高消息量场景下的吞吐与查询效率
+
+建议内容：
+
+- 梳理消息表与统计表索引
+- 优化高频查询 SQL
+- 逐步替换高成本 Redis key 扫描模式
+- 对报表类查询做汇总表或快照表
+- 增加慢 SQL 记录
+
+预期收益：
+
+- 提升整体处理效率
+- 为数据规模增长留出空间
+
+涉及模块：
+
+- `db/`
+- `utils/wechat/message_to_db.py`
+- `admin/dashboard/`
+
+### 7.5 消息归档与统计分层
+
+目标：
+
+- 降低单一数据层承担过多职责的问题
+
+建议内容：
+
+- 区分原始消息、结构化消息、统计快照、媒体资产
+- 梳理消息归档与统计写入边界
+- 为画像、总结、排行等场景设计更清晰的数据来源
+
+预期收益：
+
+- 降低维护复杂度
+- 提升查询可解释性
+
+涉及模块：
+
+- `db/message_storage.py`
+- `utils/wechat/message_to_db.py`
+- `db/scripts/migrations/`
+
+### 7.6 AI 成本与策略中心
+
+目标：
+
+- 让 AI 能力更可控、更可衡量
+
+建议内容：
+
+- 统计各插件 token 消耗
+- 统计模型成功率与平均耗时
+- 支持模型降级策略
+- 支持预算阈值告警
+- 支持按场景切换模型策略
+
+预期收益：
+
+- 降低 AI 成本不可控风险
+- 提高不同场景下的模型使用效率
+
+涉及模块：
+
+- `utils/ai/`
+- `plugins/ai_auto_response/`
+- `plugins/message_summary/`
+- `plugins/member_context/`
+
+### 7.7 命令帮助与功能发现优化
+
+目标：
+
+- 降低普通用户与管理员的使用门槛
+
+建议内容：
+
+- 自动生成按插件分类的帮助菜单
+- 按群启用状态展示实际可用命令
+- 按管理员/普通用户显示不同帮助内容
+- 后台提供命令索引与触发示例
+
+预期收益：
+
+- 提高功能使用率
+- 降低学习成本
+
+涉及模块：
+
+- `plugins/robot_menu/`
+- `utils/robot_cmd/`
+- `admin/dashboard/`
+
+---
+
+## 8. P2 优先级清单
+
+### 8.1 群级个性化配置中心
+
+目标：
+
+- 让不同群拥有不同的机器人行为策略
+
+建议内容：
+
+- 群级人格配置
+- 群级回复频率配置
+- 群级白名单和黑名单
+- 群级敏感词与休眠时段配置
+- 群级 AI 场景开关
+
+预期收益：
+
+- 提高多群场景适配能力
+- 提高管理员可控性
+
+### 8.2 用户反馈闭环
+
+目标：
+
+- 为 AI 与功能优化提供真实用户反馈数据
+
+建议内容：
+
+- 对 AI 回复增加“有用/没用”反馈
+- 管理后台查看低质量回复样本
+- 针对高频差评问题做规则与提示词优化
+
+预期收益：
+
+- 让优化方向更基于数据
+- 提高 AI 回复质量
+
+### 8.3 数据导出与备份恢复
+
+目标：
+
+- 提升系统的数据可迁移性与安全性
+
+建议内容：
+
+- 导出群消息统计报表
+- 导出积分/签到/排行数据
+- 数据备份任务
+- 恢复演练机制
+
+预期收益：
+
+- 提高运维安全性
+- 提高系统迁移与容灾能力
+
+### 8.4 多模态交互能力增强
+
+目标：
+
+- 扩展项目的智能交互上限
+
+建议内容：
+
+- 语音识别
+- 图片理解
+- 图文混合回复
+- 后台统一管理多模态能力开关
+
+预期收益：
+
+- 提高交互丰富度
+- 增强内容类插件能力
+
+### 8.5 插件模板与插件市场化能力
+
+目标：
+
+- 降低后续新增插件的开发与接入成本
+
+建议内容：
+
+- 标准插件模板
+- 插件脚手架命令
+- 插件元数据规范
+- 插件安装与升级指引
+
+预期收益：
+
+- 提高插件生态扩展效率
+- 降低维护者心智负担
+
+### 8.6 运营与数据分析能力增强
+
+目标：
+
+- 让后台不只是管理系统，也能辅助群运营
+
+建议内容：
+
+- 群活跃时段分析
+- 沉默成员识别
+- 热点话题趋势分析
+- 群行为周报/月报
+
+预期收益：
+
+- 提高项目在群运营场景下的价值
+- 为功能优化提供更多行为数据
+
+---
+
+## 9. 推荐迭代路线
+
+建议不要同时推进过多方向，而是按“三阶段”推进。
+
+### 第一阶段：补基础工程能力
+
+建议先完成：
+
+- 配置与密钥治理
+- 后台安全增强
+- 自动化测试基线
+- CI 持续集成
+- 系统健康与观测面板
+- 消息链路 Trace
+
+阶段目标：
+
+- 先把系统变成“敢持续改”的状态
+
+### 第二阶段：补平台治理能力
+
+建议推进：
+
+- 插件治理中心
+- 插件超时/熔断/隔离
+- 后台任务中心
+- 数据层性能优化
+- 消息归档与统计分层
+- AI 成本与策略中心
+
+阶段目标：
+
+- 让系统变成“能稳定扩展”的状态
+
+### 第三阶段：补产品增强能力
+
+建议推进：
+
+- 群级个性化配置中心
+- 用户反馈闭环
+- 数据导出与备份恢复
+- 多模态交互
+- 插件模板化
+- 运营分析能力
+
+阶段目标：
+
+- 让系统变成“更好用、更智能、更可运营”的状态
+
+## 10. 建议优先落地的 10 个任务
+
+如果需要进一步压缩为最小可执行版本，建议优先做以下 10 项：
+
+1. 配置脱敏与环境变量化
+2. 后台管理员安全增强
+3. `pytest` 测试框架搭建
+4. GitHub Actions 基础工作流
+5. 插件处理耗时统计
+6. 消息 trace_id 全链路打通
+7. 任务执行历史页面
+8. 插件错误与健康状态页
+9. 消息表与统计查询索引优化
+10. 命令帮助系统自动生成
+
+## 11. 结论
+
+ABOT 当前最大的优势是“功能已经足够丰富，且架构已经有平台化雏形”；最大的风险则是“功能增长速度可能快于工程治理速度”。
+
+因此，后续优化不建议继续以“堆新功能”为主，而建议转为以下主线：
+
+- 先提升安全性
+- 再补测试与观测
+- 再做插件治理与任务治理
+- 最后继续扩展产品能力
+
+如果这条路线执行得当，ABOT 后续会更像一个稳定的机器人平台，而不是一个持续膨胀的功能集合。