AI编程Agent工程纪律文本分发机制
定义
AI编程Agent工程纪律文本分发机制，是一种把工程实践写成文本化规则并分发给 AI 编程 Agent 的方法。它不依赖新增模型能力，也不以复杂插件逻辑、代码实现或额外工具链作为核心，而是把“遇到某类任务时必须按什么流程做”写成可调用的 Markdown skill 文件，让模型在不同任务场景下遵守设计、计划、调试、测试、审查、收尾等工程纪律。
在本文语境中，这种机制的核心判断非常明确：AI 编程 Agent 缺的从来不是能力，而是纪律。模型通常知道“应该写测试”“应该先查根因”“应该先设计再实现”，但在默认交互模式下，尤其当用户催促“快点改一下”“先跑起来看看”时，它会跳过这些步骤，直接进入实现或猜测式修改。
因此，这一机制解决的不是“模型不会”，而是“模型会偷懒、会跳步骤、会在压力下省略流程”。
在本文档中的语境
原文以Superpowers为例，强调它表面上是一个插件，但真正关键的部分不是插件功能，而是其内部的一组 skill。每个 skill 的本质都是一个 Markdown 文件，里面写明：当遇到某类任务时，Claude 必须按给定顺序执行哪些步骤、在哪些条件下停止、何时交接给下一个 skill、哪些行为被禁止。
原文直接指出，这些 skill：
- 不是代码逻辑
- 不是工具调用实现
- 不是“建议式提示词”
- 而是纯文本的行为约束
这也是“文本分发机制”这个概念的关键：纪律不是硬编码在模型参数里，也不是埋在插件后端逻辑里，而是以文本规则形式随 skill 一起被检索、调用和执行。
为什么说核心问题是纪律，而不是能力
文中给出的判断具有很强的边界性：Claude 并不是不知道怎么做工程，而是在默认模式下经常直接上手干，表现为“不问、不验、不收”。
典型表现包括：
- 让它加一个功能时，它会很快吐出几百行代码，但其中一部分需求是它自己补出来的，而不是用户真正要求的
- 让它修 bug 时，它会在没有完成根因调查的情况下直接猜着改
- 用户说“快速给我跑一遍看看”时，它明知道应该写测试，也可能直接跳过
- 用户说“快帮我改一下”时，它明知道 debug 应先查根因，也可能直接做猜测性修改
所以原文的重点不是“让 Claude 更聪明”，而是“让 Claude 更不容易跳步骤”。这也是“纪律优先于聪明”的具体含义：即使模型知道正确做法，如果没有硬约束，它仍可能因为默认行为模式或用户催促而省略关键环节。
载体：skill 是 Markdown 文本文件
这一机制最核心的实现载体，是 skill 文件本身。原文明确说，Superpowers 中的每一个 skill，本质上是一个 Markdown 文件，文件内容描述的是流程、边界、交接顺序和禁止事项。
这意味着：
- 纪律通过文本定义
- 流程通过文本强制
- 任务切换通过文本交接
- 行为边界也通过文本声明
它不是“再造一个更强模型”，而是给现有模型加上一套外显、可复用、可扩展的工程纪律说明书。
这种设计的一个重要含义是，约束可以被独立审阅、复用和定制。原文还提到可以创建新的 skill，并支持个人 skill 库，说明这种机制天然适合团队把自己的代码审查规范、部署流程、收尾要求等继续写成文本规则，附着到 Agent 行为上。
skill 分类
原文展示的 skill 共 14 个，分为三类：测试类、调试类、协作/工作流类。
测试类
- test-driven-development
调试类
- systematic-debugging
- verification-before-completion
协作/工作流类
- brainstorming
- writing-plans
- executing-plans
- subagent-driven-development
- dispatching-parallel-agents
- requesting-code-review
- receiving-code-review
- using-git-worktrees
- finishing-a-development-branch
- writing-skills
- using-superpowers
从这个分类可以看出，这套机制的重点不是“增加功能型插件”，而是把工程生命周期的关键节点拆出来：设计、计划、实现、测试、调试、审查、分支收尾，分别施加文本纪律。
关键机制一：先设计，未经批准不许写代码
在Superpowers中，最典型的纪律机制来自 brainstorming。原文强调，大多数人只用了它很浅的一层：问几个问题后就直接开写，等于把最关键的后续流程全部跳过。
brainstorming 中有一个明确的硬门槛：在设计展示并获得用户批准之前，不得调用实现类 skill，不得写代码，不得搭项目脚手架，也不得采取任何实现动作。
原文把这类约束称为 <HARD-GATE>，意思不是建议，而是硬性禁止。其作用是：即便用户或模型都倾向于“简单功能先做再说”，流程也必须卡住，直到设计被明确提出并获批。
brainstorming 的完整流程被写成 9 步：
- 探索项目现状，包括文件、提交记录、文档
- 如果问题涉及视觉内容，先提供可视化伴侣，并且要求单独消息呈现
- 逐条提澄清问题，每次只问一个
- 提出 2 到 3 个方案，并说明推荐理由
- 按章节展示设计方案，而且每一段都要确认
- 把设计写入规范文档并提交
- 自检 spec，扫描 TBD、TODO、内部矛盾、范围问题和歧义
- 让用户审阅 spec 文件
- 交接给AI编程任务细粒度计划拆解对应的 writing-plans
文中特别指出，最容易被跳过的是第 6 到第 8 步，也就是把设计真正落到文档、做自检、让用户审阅的部分。很多人做到方案讨论就直接进入编码，结果后续执行阶段模型对接口、范围和约束的记忆开始漂移。
这里体现出文本分发机制的第一个关键目标：把“设计必须落文档并被审阅”从经验习惯变成硬性流程。
关键机制二：计划必须细粒度、零占位符
brainstorming 的终态并不是“开始编码”，而是只能移交给 writing-plans。原文明确说，不允许跳去别的实现路径，这种单一交接顺序就是一种流程硬约束：设计之后必须先计划，不能直接开发。
writing-plans 的职责，是把 spec 拆成可以被 AI 或人类稳定执行的任务清单。其最关键的纪律有两条。
每一步必须细到 2-5 分钟
原文要求计划中的每个步骤粒度控制在 2 到 5 分钟，而不是笼统写成一个大动作。比如：
- 写一个失败的测试
- 跑一下，确认它确实失败了
- 写最小实现让测试通过
- 再跑测试，确认通过
- Commit
这里“写失败测试”和“跑一下确认失败”被明确拆成两个独立步骤，因为每一步都要有清晰完成判据。这种粒度设计，是为了降低执行阶段的不确定性，避免 Agent 做到一半无法判断“算不算完成”。