项目是怎么演进的
这个项目不是一开始就有"四段流程"的——它经历了一次重要的策略调整。
初始阶段：全链路走一遍
最初的做法是：每个模块都走"现状 → 接口 → 场景 → 产品定义"的完整链路。
问题很快暴露：
- 接口表和场景表维护成本高，但对最终交付的帮助有限
- 真正需要持续维护的只是"功能现状"和"MCP 工具定义"
- 产品定义和场景验证才是需要深入打磨的交付物
当前阶段：拆成"沉淀 + 验证"
调整后的策略很清晰：
- 前一段（快速）：沉淀功能现状 + MCP 工具定义
- 后一段（深入）：围绕重点模块补"智能体产品定义 + 场景验证"
不再维护"后台已有接口表"和"产品场景表"——它们只在内部分析时参考，不再作为主交付物。
当前真正在维护的四类产出
- 功能现状：模块当前"已经是什么样"的事实记录
- MCP 工具定义：每个模块的标准化工具清单（输入/输出/权限/限制/典型问法）
- 智能体产品定义文档：模块级别的"是什么、能干什么、边界在哪"
- 场景验证表：按用户任务维度的验证样本（场景 → 能力映射 → 是否可支持 → 问题 → 建议补充）
不同输入怎么推进
实际工作中，每次拿到的输入不同，推进方式也不同：
拿到操作手册
- 读手册，提炼模块现状
- 直接做对应 MCP 工具定义
拿到旧版工具清单
- 反推核心场景（而不是照搬清单）
- 判断哪些是"核心"哪些是"扩展"
- 修正 MCP 表，不盲目铺全
拿到代码或接口线索
不全仓读。只做定点校准：
- 校准真实入参/出参
- 确认修改能力是否完整
- 校准权限边界
进入验证阶段
- 基于 MCP 表收口首版智能体边界
- 产出模块产品定义文档
- 新建场景验证表
- 按"场景 + 能力映射 + 问题备注"填核心样本
这个过程证明了什么
表面上看，这是一个"MCP 工具定义"的项目。但真正难的不是写工具定义——那只是格式化工作。
真正难的是：
- 在没有先例的情况下，自己判断"什么该做什么不该做"——主动砍掉了接口表和场景表两个中间产物
- 把一个模糊的大目标（"让 AI 帮用户办事"）拆成可推进的单位——每个模块独立闭环，方法可复用
- 在约束条件下做决策——不脱离已实现能力空想，但也不被工具清单绑住视角
最终沉淀出的方法论和文档结构，不是我提前设计的，是被真实问题一步步逼出来的。