AI 工程纪律
定义
AI 工程纪律，是指把原本由资深工程师隐性遵守的开发规范，改写为 AI Agent 必须遵守的显式执行流程，并以文本规则约束其行为顺序、停止条件、交接方式与验收标准。
在本文语境中，它不是泛泛的“工程方法论”，也不是给模型新增工具能力，而是把“什么时候可以开始写代码、什么时候必须先查根因、什么时候必须先写测试、什么时候必须停下来复核”这些纪律写成可调用、可检查、可复用的文本化 skill。
其核心判断是：AI 编程 Agent 缺的往往不是能力，而是纪律。模型通常“知道”应该先设计、先验证、先找根因、先跑测试，但在“快点改一下”“先写出来看看”这种提示下，会直接跳过必要步骤，进入高返工、高漂移的默认工作模式。
在本文档中的语境
本文把 AI 工程纪律 放在 Superpowers 与 Claude Code 的使用语境下讨论。这里的重点不是某个插件界面，而是“通过纯文本 skill 分发工程流程”这一机制：每个 skill 都是在规定，当 Agent 遇到某类任务时，必须按什么顺序做、在什么条件下不能进入下一步、最终必须把工作交给哪个后续环节。
因此，AI 工程纪律 解决的问题不是“Claude 能不能做”，而是“Claude 会不会不问、不验、不收，直接上手干”。它针对的是以下常见失控模式：
- 跳过设计确认，直接实现，导致需求被模型自行脑补
- 调试时不做根因调查，直接猜测式修复
- 计划拆解过粗，执行时无法判断步骤是否完成
- 长会话中发生上下文漂移，前面确认过的接口、约束或假设被遗忘
- 临近结束时跳过验证、审查和收尾，留下未清理的工作现场
这里的“纪律”之所以重要，是因为它把执行顺序变成了可审计对象。用户不仅能看结果，还能检查 Agent 是否先完成设计、是否先稳定复现问题、是否在三次失败后停下来讨论、是否在测试通过前拒绝进入分支收尾。
核心机制：用文本硬门抑制跳步执行
AI 工程纪律 的关键机制不是能力增强，而是流程抑制。也就是说，它通过一系列硬约束，把 Agent 从“想到什么做什么”的反射式执行，改造成“前置条件满足后才能推进”的阶段式执行。
这种机制至少包含四层：
- 硬门（hard gate）：某些前置条件未满足时，明确禁止写代码、禁止实现、禁止进入下一 skill。
- 顺序性阶段：任务必须按既定阶段推进，前一阶段未完成，不得进入后一阶段。
- 显式交接：一个阶段的终态不是“差不多了”，而是产出明确文档、计划或结论，并移交给指定后续流程。
- 可验证终止条件：每一步都要能判断是否完成，而不是凭主观感觉“应该差不多”。
这就是为什么本文强调，AI 工程纪律 的价值在于抑制跳步执行。它不是让 Agent 更会写代码，而是让 Agent 更不容易在错误时间做“看似勤快、实际危险”的动作。
从设计到收尾的全链路纪律
本文覆盖的 AI 工程纪律 不是单点规范，而是从设计、计划、实现、调试、验证、审查到收尾的完整链路。其代表性的全流程可以概括为：
- 先做设计确认
- 再写可执行计划
- 然后进入实现
- 遇到问题时切回根因调试
- 完成后做验证与审查
- 最后执行分支收尾与环境清理
这种全链路纪律的意义，在于避免“局部看起来专业，整体仍然失控”。例如，单独强调测试并不能解决需求漂移；单独强调调试也不能阻止设计阶段的误解一路传导到实现阶段。只有把链路串起来，Agent 才不会在某个环节偷懒跳步。
设计纪律：先批准设计，后允许实现
设计阶段的代表性约束，是在用户批准设计前，不允许调用任何实现型 skill，不允许写代码，不允许脚手架化项目，也不允许采取实现动作。
这类约束的重点不是“多做文档”，而是把“设计已确认”变成一道硬门。只要没过门，哪怕任务看起来很简单，也不能直接开写。
在本文引用的流程中，设计阶段不是简单问答，而是一个完整的九步过程：
- 探索项目现状，包括查看文件、提交记录与现有文档；
- 如果问题涉及视觉层面，先提供可视化伴侣，并以独立消息给出；
- 逐条提出澄清问题，而且一次只问一个；
- 提出 2 到 3 个方案，并说明推荐理由；
- 分章节展示设计方案，且每一段都要求确认；
- 将设计写入规范文档并提交；
- 对 spec 自检，扫描 TBD、TODO、内部矛盾、范围错误与歧义；
- 让用户审阅 spec 文件；
- 将工作移交给 任务颗粒化计划 所对应的计划编写环节。
这里最关键、也最容易被跳过的，恰恰是后半段：把设计落成文档、对文档做自检、让用户基于文档审阅，而不是停留在对话里“差不多说清楚了”。
原因很实际：如果设计没有形成被确认的文档，后续执行阶段就只能依赖会话上下文记忆。会话一长，Agent 很容易发生上下文漂移，做到一半忘记已经约定好的接口、边界或限制。
本文还强调一个反直觉边界：即使任务很小、改动很轻，也不能因为“看起来简单”就跳过设计流程。简单任务往往藏着未说出口的隐含假设，而隐含假设恰恰是返工的重要来源。设计可以短，但不能省。
计划纪律：把任务拆到 2 到 5 分钟粒度
设计确认之后，AI 工程纪律 不允许直接进入大段实现，而是要求先把 spec 拆成可执行计划。这对应 任务颗粒化计划 的核心思想：每个步骤都应该小到能在 2 到 5 分钟内完成，并且拥有清晰的完成判定。
这种粒度不是随意建议，而是为了让 AI 或人类执行者在每一步都知道“完成了什么、还差什么、下一步是什么”。
典型拆法不是“实现功能 X”，而是类似下面这种顺序：
- 先写一个失败的测试；
- 再运行一次，确认它确实失败；
- 再写最小实现让测试通过；
- 再跑测试确认通过；
- 最后提交变更。
这里连“写失败测试”和“运行确认失败”都必须拆成两步，原因是它们的验收条件不同。前者是测试代码写出来了，后者是失败现象被真实验证了。若不拆开，执行时很容易出现“我好像已经做完这一步了”的模糊状态。
零占位符规则
AI 工程纪律 对计划还有一条很严的边界：不接受占位符式计划。像下面这些写法，都应被视为计划失败：
TBD、TODO、后续实现；- “添加适当的错误处理”这类不写具体处理方式的句子；
- “写上述内容的测试”但不给出测试内容或测试目标；
- “类似任务 N”这种靠引用代替明确描述的写法。