工具工作台：让工具服务流程

工具不是竞争力本身。知道每个工具堵住哪类失效、放在链路哪个位置，才是竞争力。

前几章建立了从需求到执行的流程。这一章回答最后一个执行层问题：工具怎么组织。原则先行：

先让流程徒手跑通，再用工具把跑通的流程固化。 顺序反过来——先堆工具再找流程——固化下来的往往是错误的流程。

一、按交付链路组织工具，而不是按工具清单收藏

工具选型的唯一判据：它堵住了链路上的哪类失效。 按方法论的环节排列：

链路环节	失效模式	工具类别	对应章节
需求	AI 用默认假设补缺口	体检清单、规格模板、EARS 句式	需求体检、规格
上下文	约束不可见、决策丢失	CLAUDE.md / rules、ADR、memory	上下文工程
代码理解	AI 只见文件不见系统	代码图谱、调用链分析、语义检索	同上（按需检索层）
执行	流程漏步骤、边界被穿透	Skill、Hook、Subagent、工作单模板	Agent 执行、工作单
验证	"看起来对"混过验收	测试、静态分析、ArchUnit、CI	验证闭环、边界
外部集成	每个工具一套私有接法	MCP（Model Context Protocol）	见下文

三条分工原则在 Agent 执行已经给出，工具层原样适用：约束进 Hook，流程进 Skill，判断留给人。

二、代码图谱：让 AI 从看文件升级到看系统

代码检索类工具（代码图谱、AST 索引、调用链分析）解决的是一类特定失效：AI 的默认视野是"当前打开的文件"，而缺陷的影响面是"整个调用网络"。它应该能回答：

• 谁调用了 GmvGenerateOrchestratorService.generateAll()？
• GMV 清洗结果 DTO 被哪些接口使用？改它会破坏谁？
• 从总控入口到平台执行器、Mapper 与汇总刷新的调用链经过哪些模块？

价值不是"搜索快"，而是让影响面分析从"AI 猜"变成"AI 查"。在验证闭环的风险暴露闸门里，这是回归范围判定的依据。

三、Skill 与 Hook：经验产品化与底线机械化

Skill 把重复流程固化成可调用单元：需求体检、规格生成、工作单生成、测试审查、缺陷复盘——每个都是"以前靠记忆、现在靠调用"的流程。判断一个流程值不值得做成 Skill：它是否每周被执行两次以上，且每次步骤相同。 开源社区已有成型技能库（如 Superpowers 等 Claude Code 技能集），先复用再自建。

Hook 把底线从自觉变成拦截：提交前必须跑测试、禁止提交密钥、修改核心模块必须先读边界规格、测试失败禁止继续。Hook 与 Skill 的分界在于后果——违反后果是"效率低"的进 Skill，违反后果是"出事故"的进 Hook。

四、MCP：工具接入的行业标准

2024 年底 Anthropic 开源的 MCP（Model Context Protocol）已被主要 AI 厂商跟进采用，成为模型接入外部工具与数据的事实标准。对工作台的意义很实际：数据库查询、代码图谱、工单系统、内部 API 用统一协议接入一次，所有支持 MCP 的 agent 工具都能用——工具投资从"绑定某个产品"变成"绑定开放协议"，这是工作台建设里为数不多能对冲工具快速迭代风险的选择。

五、设计工具：把需求体检延伸到交互层

把 Figma / Pencil 这类工具看成"美化界面"太浅。对任何带界面的系统，设计稿是一种廉价的需求验证：它会先于代码暴露页面角色、状态集合（空态、错误态、加载态）、权限差异、表单完整性、操作反馈。

这就是需求体检的第⑤维（异常与边界）和第⑥维（权限）在交互层的投影——设计稿不是代码之后的装饰，而是代码之前的规格。 在界面型需求里，一张标注了全部状态的设计稿就是行为规格的一半。

六、引入顺序：从纪律到设备

第一梯队（零工具成本，立刻生效）
1. CLAUDE.md 项目规则          ← 上下文常驻层
2. 需求体检清单 + 规格模板      ← 需求纪律
3. 工作单 + 汇报格式模板        ← 执行纪律

第二梯队（流程跑通后固化）
4. Hook：测试、密钥、边界拦截
5. Skill：体检、review、缺陷复盘
6. 代码图谱 / 检索（MCP 接入）

第三梯队（规模化后补强）
7. ArchUnit 边界测试进 CI
8. 多 Agent 编排工作流
9. 设计协作与发布检查

第一梯队全是纯文本文件——这套方法论的最小可用版本不需要安装任何东西。这也是检验工具价值的方式：如果第一梯队的纪律没建立，后面的工具只是给混乱加速。

七、反模式：工具堆积

工作台最常见的失败不是工具太少，而是工具太多：

• 收藏家模式：每个热门工具都装，每个都浅尝辄止——工具数量和交付稳定性没有相关性；
• 工具驱动流程：因为装了某工具而发明使用它的流程，本末倒置；
• 僵尸工具：装好后三个月没被任何任务真实使用，却仍在消耗上下文（每个 MCP 工具的描述都占窗口空间——这是上下文稀释的隐蔽来源）。

对每个在役工具保留一个回答："拿掉它，链路上哪个环节会退化？" 答不上来就下线。这和上下文规则文件的"删掉它会出什么错"判据是同一条纪律。

八、本章小结

• 先流程后工具：固化错误流程的工具是负资产；最小可用版本是几个纯文本文件。
• 工具按链路环节组织，每个工具对应它堵住的失效模式；约束进 Hook、流程进 Skill、判断留给人。
• 违反后果是效率低的进 Skill，是事故的进 Hook；外部集成走 MCP 对冲工具迭代风险。
• 设计稿是代码之前的规格，不是代码之后的装饰。
• 每个在役工具要能回答"拿掉它哪个环节退化"，答不上来就下线。

执行篇到此完成。下一章进入验证篇的验证闭环——证明这条流水线的产物真的能交付。

---

参考资料

• Anthropic, Model Context Protocol（2024）——模型接入外部工具与数据的开放协议，已成行业事实标准。