---

name: design-to-implement description: 从方案讨论到代码落地的结构化工作流技能（讨论→设计→实施规划→实施）。纯手动触发，需显式调用如 /design-to-implement，不自动激活。用任务文档驱动流程并保持跨上下文记忆。适用于"先想清楚再做"的中大型功能/模块设计与实施。工具中立，兼容任何能读写本地文件的 agent 客户端。

方案设计与实施工作流

核心理念

先讨论清楚，再动手写代码。 这套工作流强制把"想"和"做"分开：

• 讨论阶段：只对话，不写代码，所有结论沉淀到沟通过程文档
• 设计阶段：把共识整理成设计文档，这是唯一的事实来源
• 实施阶段：根据设计文档生成实施文档，按步骤落地

讨论没有结论、用户没有明确说"可以开始落地"，绝不动代码。如果一直有疑问就一直讨论下去，直到双方满意。

文档目录结构

固定存放在项目根目录下的 docs/design/，每个任务一个独立子文件夹：

项目根/
└── docs/design/
    ├── README.md              ← 全局任务总览（多任务入口，最先读这个）
    ├── 01-用户认证模块/
    │   ├── 00-任务状态.md      ← 跨上下文记忆锚点
    │   ├── 01-沟通过程.md
    │   ├── 02-设计.md          ← 含验收标准
    │   ├── 03-实施.md
    │   └── 04-测试.md          ← 用例集（实施规划阶段生成）
    └── 02-支付重构/
        └── ...

命名规则：

• 任务文件夹：全局递增两位序号 + 任务名，如 01-用户认证模块、02-支付重构。序号跨任务连续递增，保证排序与创建顺序一致。
• 任务内文档：固定阶段序号前缀：00-任务状态 / 01-沟通过程 / 02-设计 / 03-实施 / 04-测试。固定前缀让你在任何任务里都能一眼定位同一类文档。

首次进入任务时如何确定序号：查看 docs/design/ 下已有文件夹的最大序号，+1 作为新任务序号。如果目录不存在，从 01 开始。

每次新对话的第一步（多上下文记忆机制）

这套工作流可能跨多个对话上下文执行。为避免每次新对话都要大范围重读代码或丢失记忆，强制按以下顺序恢复上下文：

1. 读 docs/design/README.md —— 全局任务总览，确认有哪些任务、各自在哪个阶段。如果用户已指明任务，直接跳到该任务。
2. 读 00-任务状态.md —— 当前任务的记忆锚点，确认下一步该做什么。
3. 读当前阶段对应的文档（如在设计阶段就读 02-设计.md，在实施阶段就读 03-实施.md）。
4. 只在需要核实时才去读代码，而不是作为恢复上下文的第一手段。

00-任务状态.md 必须维护：任务一句话简介、当前阶段、关键决策摘要、待办与疑问、文档索引、上下文切换日志、变更记录（涵盖修改与回退，见下文"实施期的变更"）。

工作流的四个阶段与对应文档

阶段一：讨论（输出 → 沟通过程文档）

触发：用户提出一个新需求、新功能、新模块，或对既有方案有疑问想讨论。

行为约束：

• 这个阶段只讨论，不写任何业务代码。
• 把每一次有意义的交流（关键决策点、被否决的备选、达成的共识）追加记录到 01-沟通过程.md。
• 未决疑问追踪：在 01-沟通过程.md 顶部维护"当前未决疑问"清单。每次讨论结束前更新它——哪些问号还在、哪些新冒出来、哪些已经闭环。判断能否进入设计阶段的直接依据就是：这个清单空了没。这能让讨论收敛过程可视化，而不是凭感觉认为"讨论得差不多了"。
• 讨论是多轮的，可能跨多次对话。
• 当用户表达"可以了""就这样定了吧""开始设计吧"，且未决疑问清单已清空，进入阶段二。

何时继续讨论而非推进：只要还有未解决的设计疑问、技术选型分歧、边界没讲清，就继续在阶段一沉淀。宁可多问一轮，不要带着模糊假设进入设计。

阶段二：设计（输出 → 设计文档）

触发：讨论达成一致，未决疑问清单已清空，用户同意固化方案。

行为约束：

• 把沟通过程里的结论，整理成结构化的 02-设计.md。设计文档是唯一事实来源。
• 设计文档必须尽可能完整：交付时是确定的、可执行的方案，不残留"待定""实施期再说"。完整性靠两件事保证——一是反复沟通把疑问问透，二是读现有代码确认所有依赖既有实现的事实（接口形态、表结构、调用方式等）。"设计阶段只讨论不写代码"约束针对的是业务代码；为了设计而读既有代码、确认现状，属于设计调研，不违反约束。设计阶段宁可多花时间反复打磨，也不要带着缺口进入实施——任何缺口都会在实施期变成返工或偏差。
• 验收标准属于设计的一部分：设计文档除了写"做什么、为什么"，还要写"做到什么程度算满足需求"——即抽象验收标准（规则层面，如"高危词必须拦截，文章不落库"）。验收标准定义了需求边界，是设计完整性的最后一环；没有验收标准的设计文档，等于没有"做完了"的客观定义。具体的测试用例（实例层面）不在设计文档写，而在 04-测试.md 由实施规划阶段把验收标准落成用例。
• 设计变更记录：在设计文档里维护一个"设计变更记录"区块，每次重要变更记一行（时间、改了什么、为什么改）。它与 01-沟通过程.md 互补——沟通过程是流水账，设计文档是结论，变更记录是结论的演进史。这能让"方案变更改设计文档而非实施文档"这条铁律真正可执行而不丢历史。
• 设计文档完成后，更新 00-任务状态.md 标注"设计完成，待实施"，并同步更新 docs/design/README.md 的任务阶段。

阶段三：实施规划（输出 → 实施文档）

触发：设计文档定稿。

行为约束：

• 根据设计文档生成 03-实施.md，把方案拆成可执行、可勾选的步骤清单。
• 同时把设计文档的"验收标准"落成具体测试用例，生成 04-测试.md：用例是验收标准的实例化（如验收标准"高危词必须拦截" → 用例"输入含高危词文本，预期返回 40901、文章不落库"）。用例分四层：功能（T-F）、异常（T-EX）、回归（T-R）、接口（T-API），编号格式 T-{类型}-{两位序号}，模板见 assets/test.md。
• 实施文档是"如何做"，测试文档是"测什么、预期是什么"，设计文档是"做什么、为什么"。三者职责不同，不要把设计细节照搬进实施文档，也不要在实施文档里夹带方案变更。
• 实施文档是纯粹的步骤分解，每一步只是"按设计文档的某部分去实现"，不承担任何"补全设计"的职责。如果拆步骤时发现某一步需要先"确认接口形态""回写设计""决定字段"才能动手，说明设计阶段没做完——此时应回到阶段二补全设计，而不是在实施文档里塞一个"补设计"的步骤。一句话：实施文档里不该出现任何"读代码确定方案"性质的动作，只该有"按既定方案实现"的动作。
• 实施文档里的测试动作只引用用例编号，不重复写用例内容。每个步骤完成后要验证的，写"对照用例 T-XX-XX 验证"，用例本身集中在 04-测试.md。
• 实施步骤分大步骤和小步骤两层，都要有独立的完成标记。
• 实施文档完成后，更新 00-任务状态.md 标注"待实施"。

阶段四：实施（执行实施文档的步骤）

触发：用户说"开始实施""动手吧""按文档来"。

行为约束：

• 严格按 03-实施.md 的步骤推进，每完成一步就在文档里更新标记并简记结果。
• 每完成一个步骤，对照 04-测试.md 里该步骤引用的用例验证；用例失败时该步骤不算完成，定位问题（是实施 bug 还是设计/用例本身有问题，后者走修改/回退机制）。全部步骤完成后，跑一遍回归用例（T-R）集。
• 遇到任何与设计文档不一致的情况，停下来：先更新 02-设计.md（含变更记录），再同步修订 03-实施.md 和 04-测试.md（用例随方案变），然后继续。绝不边做边偏离方案。
• 实施过程中发现的设计漏洞、新增约束、API 变动，全部回写到 02-设计.md 的"设计变更记录"区块，保持设计文档是最新的。
• 每个阶段切换、每个重要节点，都要更新 00-任务状态.md 和 docs/design/README.md。

实施期的变更：修改机制 vs 回退机制

工作流名义上是讨论→设计→实施规划→实施，但实施中发现方案和需求/现实存在偏差，是预期内的常态，不是异常——再完整的设计也不可能 100% 预见实施细节。

偏差分两类，性质完全不同，必须严格区分，用各自的流程处理：

	修改	回退
本质	方案大体对，有缺口/遗漏需要补	这部分方案根本错了，需推倒重来
主体方案	不动	推倒
已完成产物	不作废	部分作废
频率	常态	少数
典型场景	漏字段、漏分支、漏字典值、漏考虑某个新需求点	方向错了、核心假设不成立、不符合实际业务

先判定属于哪类（判定责任见各机制说明），再按对应流程处理。判定拿不准时，倾向于先按"修改"处理并和用户确认；只有明确构成根本性错误时才走"回退"。

修改机制（常态、轻量、增量）

判定三条件（全满足才算修改）：

• 主体方案方向没问题
• 不需要作废已完成的产物
• 只是补充/微调（补字段、补分支、补字典值、补一个漏掉的新需求点等）

处理流程（严格顺序，不可颠倒）：

1. 停下当前实施
2. 先更新设计文档：在设计文档相应区块补充内容，并补一行设计变更记录
3. 等用户确认这个修改（不能自行决定、自行实施）
4. 用户确认后，同步修订实施文档
5. 再继续实施

关键原则：先更新设计、再实施，顺序不可颠倒——禁止"先实施完再回写设计文档"，那会让设计文档退化为事后记录而非事实来源。哪怕只是加一个字段，也要走完这个流程。

回退机制（少数、重量、推倒）

判定三条件（全满足才算回退）：

• 主体方案方向有问题
• 已完成的产物需要作废
• 需要重新讨论/设计

判定责任：回退的最终决定权在用户。AI 发现疑似根本性问题时，只能建议疑似回退并说明理由，由用户最终判定是否回退；AI 不能自行判定回退。

处理流程：

1. 停下当前实施
2. AI 建议疑似回退，说明理由（哪部分方向错了、为什么不成立）
3. 等用户最终判定是否回退
4. 用户确认回退后，在 00-任务状态.md 记一行：从 X 阶段回退到 Y 阶段、原因、哪些产物作废
5. 回到讨论/设计阶段重新对齐
6. 产生的新方案按原流程沉淀：新疑问进 01-沟通过程.md 未决疑问清单；方案变更进 02-设计.md 并补变更记录
7. 同步修订 03-实施.md

两条机制的共同铁律

1. 方案变更永远改设计文档，不直接改实施文档
2. 先更新设计，再实施，顺序不可颠倒（不先做后补）
3. 任何变更都要在任务状态文档留痕（修改记设计变更记录，回退额外记回退记录）
4. 用户确认是所有变更的必经卡点（修改需确认方案补充；回退需确认判定本身）

心态：偏差不可怕，可怕的是带着偏差硬做或悄悄偏离方案。把"修改"做得轻量低摩擦（常态就该顺畅），把"回退"做得慎重（推倒重来需用户拍板），两者都规范留痕，返工成本最低。

实施文档的步骤标记规范

实施步骤分大步骤和小步骤两层，都要有独立的完成标记。大步骤用标题分块并带进度计数，小步骤用四态 checkbox。

四态标记：

- [ ]  未开始
- [~] 进行中
- [x] 已完成
- [!] 阻塞（后方注明原因）

组织形式示例：

### 1. 数据库层 ✅ 1/3
- [x] 1.1 创建 users 表（含迁移脚本）
- [~] 1.2 建立索引
- [ ] 1.3 编写种子数据

### 2. 接口层 ⬜ 0/2
- [ ] 2.1 实现 POST /api/users
- [ ] 2.2 接入鉴权中间件

大步骤状态符号：

• ⬜ 未开始（0/N 完成）
• 🌗 进行中（部分完成）
• ✅ 全部完成（N/N）

进度计数格式统一为 已完成数/总数，放在大步骤标题末尾。这样既能看到整体进度，也能定位到具体卡在哪一小步。

后端项目的特殊处理

如果当前项目是纯后端项目（无前端代码、或前后端分离后端独立仓库）：

• 设计文档和实施文档只写后端内容，不涉及前端实现。
• 任何新增接口或老接口变动（URL、方法、入参、出参、错误码、鉴权要求等），必须在 02-设计.md 里设专门的 "接口变动清单" 区块集中体现。
• 接口清单格式要让前端人员能直接拿去联调，建议字段：接口路径、请求方法、请求体示例、成功响应示例、错误码表、鉴权要求、备注。
• 这个接口清单是给前端的交付物，要写得自洽、可独立阅读。
• 接口清单在设计阶段必须给出确定结论，禁止把判断推到实施阶段。凡是"这个接口是新增还是变动""路径沿用还是改""入参字段对齐哪个既有结构"这类依赖现有代码才能定论的事实，必须在设计阶段就读现有代码确认掉，把结论写进接口清单。"设计阶段只讨论不写代码"的约束针对的是业务代码——为了确认接口形态去读既有代码，属于设计调研，不属于实施，不违反约束。设计文档里禁止出现"具体取决于现有代码""实施阶段再确认"这类含糊话术，也不允许用【实施期确认】之类的标签把不确定性合法化。接口清单交付前端时必须是完全确定的，否则前端无法联调。

验收标准与测试（三层职责）

测试不是实施阶段临时补的，而是贯穿设计到实施的体系。三层职责严格分离：

层	载体	内容	性质	产出阶段
规则	02-设计.md	抽象验收标准	"做到什么程度算满足需求"	设计
实例	04-测试.md	具体测试用例	"用什么输入，预期什么输出"	实施规划
动作	03-实施.md	步骤 + 用例引用	"做什么动作，对照哪个用例验证"	实施规划

为什么这么分：验收标准是需求边界（属于设计），用例是边界的实例化，实施是落地动作。三层分开，规则改了找设计文档，用例改了找测试文档，动作改了找实施文档——各有事实来源，不会互相污染。

测试用例分层与编号：

前缀	类型	用途
T-F-	功能用例	正向流程
T-EX-	异常用例	反向、边界、错误分支
T-R-	回归用例	修改/回退后必测的关键路径（从 F/EX 里挑，防改 A 坏 B）
T-API-	接口用例	对应设计文档"接口变动清单"的每个接口

所有任务都强制生成 04-测试.md：本技能定位是中大型任务，小需求用户不会触发技能，因此不做复杂度判断——任务一旦进入实施规划阶段，测试文档就是必产物。

修改/回退与测试的关系：走修改或回退机制后，方案变了 → 用例随之更新（先改设计验收标准，再改测试用例），并在回归用例集（T-R）里至少重跑一遍，防止局部修改引发全局回归。

扩展模式 A：任务拆分（大型多模块任务）

何时启用：大型任务天然包含多个半独立模块（如"审核系统 = 敏感词过滤 + 图片审核 + 人工审核工作台"），单上下文装不下。用户在讨论阶段显式说明"这是大型任务，拆成多模块"时启用。不自动判断任务规模，必须用户显式触发。

核心机制：父任务负责总体设计 + 模块拆分 + 模块间接口契约 + 编排，子任务在父任务的边界内各自走完整 4 阶段流程。

A.1 父子任务的文档结构（嵌套式）

项目根/docs/design/
├── README.md                          ← 全局任务总览
├── 01-审核系统/                       ← 父任务
│   ├── 00-任务状态.md                 ← 用 parent-task-status.md 模板，含子任务清单
│   ├── 01-沟通过程.md                 ← 父任务级的总体讨论
│   ├── 02-设计.md                     ← 总体架构 + 模块拆分 + 模块间接口契约
│   ├── 03-实施.md                     ← 仅父级编排（集成测试、联调），不写模块内部
│   ├── 04-测试.md                     ← 仅跨模块集成测试
│   └── 子任务/
│       ├── 01-1-敏感词过滤/           ← 子任务（完整 4 阶段文档，用普通模板）
│       ├── 01-2-图片审核/
│       └── 01-3-人工审核工作台/
└── 02-其它任务/

子任务用普通模板（task-status / communication / design / implementation / test），完全不变。父任务用 assets/parent-task-status.md 模板，多出"子任务清单"区块；父任务的设计文档在普通设计模板基础上，必须额外包含两个区块：

• 模块拆分：列出拆成哪些子任务、各自职责边界
• 模块间接口契约：子任务之间的接口约定（接口签名、数据格式、调用方式等）。这是子任务能独立并行的关键，必须设计阶段定清楚

A.2 父任务的阶段推进（严格串行）

1. 父任务先走"讨论 + 设计"，必须产出模块拆分 + 模块间接口契约
2. 父任务设计经用户确认后，才能启动子任务
3. 启动子任务时，按依赖关系排启动顺序：父任务设计阶段就要明确子任务间依赖（如"人工审核工作台依赖敏感词过滤的接口"），被依赖的子任务必须先完成，依赖方才能启动
4. 子任务各自走完整 4 阶段（满足依赖前提下可并行）。如何让多个子任务并行启动由所用 agent 框架决定（一般通过后台/异步子任务能力实现），具体落地参考见 B.5
5. 所有子任务完成后，父任务走"跨模块集成测试"收尾

为什么父任务和子任务不能并行：父任务的核心产出是模块间接口契约，这是子任务能独立的前提。父任务设计没定就启动子任务，子任务之间必然冲突。

A.3 子任务不能擅自改父任务定义的接口契约

接口契约是多模块的共识，任一子任务擅自改会让其他子任务失控。子任务如果发现父任务的接口契约有问题：

• 不能自行修改接口契约
• 必须回到父任务走修改机制：更新父任务的 02-设计.md（含变更记录）→ 等用户确认 → 通知所有依赖该接口的子任务 → 受影响子任务同步修订自己的设计/实施/测试

A.4 嵌套深度限制：只允许一层

父→子，不能再往下嵌套（子任务不能再有自己的子任务）。理由：嵌套层数过多会让任务关系极其复杂；如果子任务还要再拆，通常说明任务拆分粒度不对——它本身应该被重新规划为独立的父任务，而不是塞进现有多层结构里。

A.5 父任务模板使用

• 父任务状态文档：用 assets/parent-task-status.md（不要用普通 task-status 模板）
• 父任务其它文档（沟通过程/设计/实施/测试）：用普通模板，但设计文档必须额外包含 A.1 所述的两个区块
• 子任务所有文档：用普通模板，完全不变

扩展模式 B：双 agent 实施（实施分段）

何时启用：单任务内部，实施+测试两个阶段堆叠导致上下文过长。用户在实施阶段开始时显式说明"实施用双 agent 模式"时启用。不自动判断，必须用户显式触发。

核心机制：实施阶段内部拆成两个串行环节——实现 agent（按 03-实施.md 写代码）+ 测试 agent（按 04-测试.md 验证）。两者是物理独立的两个 agent（两个独立上下文），通过任务状态文档交接。B 的核心价值是上下文隔离：实现 agent 不背测试上下文，测试 agent 不背实现细节。

B.1 实现与测试的职责边界

• 实现 agent：只做 03-实施.md 里的步骤（写代码），完成后不自己跑测试，而是在 00-任务状态.md 的"实施分段状态"区块声明"实现完成，版本 X，可进入测试"
• 测试 agent：基于最新的 03-实施.md + 04-测试.md 进行验证。职责严格限于"跑用例、判失败、报告"，不负责改代码（即使发现实现 bug 也不自己改）

B.2 测试 agent 发现失败时的处理

测试 agent 跑用例失败时，初判失败根因（测试 agent 看到实际行为，最有信息优势做初判）：

• 判定为实现 bug（代码写错了，设计是对的）→ 报告给实现 agent，由实现 agent 修改。修改后必须回到测试 agent 复测该用例，通过才能进入下一步（实现 agent 单方面声明"改好了"不能闭环）
• 判定为设计 bug（代码按设计写了，但设计本身有问题）→ 不能擅自改设计，触发修改机制：停下→更新设计→等用户确认→改实施→改测试→回到测试 agent 复测

判定错了由用户纠偏；但"改设计"影响范围大，必须用户拍板。

B.3 实施分段状态区块

00-任务状态.md 增加一个可选区块（B 模式启用时才填，普通模式不填）：

## 实施分段状态（B 模式专用，普通模式留空）

- 当前环节：实现 / 测试
- 实现版本：(实现 agent 每次完成或修复后递增)
- 实现完成声明：YYYY-MM-DD，实现 agent 已声明可进入测试
- 测试进度：
  - 已通过：T-F-01, T-F-02, ...
  - 失败待修：T-EX-03（实现 bug，已报告给实现 agent），...
  - 待复测：T-EX-03（实现 agent 已修复，等测试 agent 复测）

实现 agent 和测试 agent 都读写这个区块，它是两者的唯一交接点。

B.4 与 A 的组合（A+B）

A 和 B 是正交的，可以组合：大任务按 A 拆成子任务，每个子任务内部按 B 拆成实现+测试。组合时不需要额外机制——因为子任务就是普通任务（A.1 已说明子任务用普通模板），所以子任务内部自然支持 B。启用方式：父任务设计 + 子任务启动后，每个子任务在实施阶段开始时再决定是否启用 B。

B.5 agent 调度指引

B 模式要求两个物理独立的 agent（实现 agent 和测试 agent），它们通过"实施分段状态"区块间接交接，不直接互相通信。具体如何让两者接力，依赖你使用的 agent 框架。

无论用哪种框架，都遵循同一个通用调度模式：

1. 由一个调度方（可以是主 agent、外部编排脚本，或用户本人）读"实施分段状态"区块，判断当前环节
2. 调度方启动实现 agent，传入设计/实施文档路径，指令其按 03-实施.md 推进、完成后更新状态区块
3. 实现环节结束后，调度方启动测试 agent，传入测试文档路径，指令其按 04-测试.md 跑用例、把结果（含失败判定）写入状态区块
4. 调度方根据状态区块的测试结果决定下一步：实现 bug 则回到实现 agent 修复并复测；设计 bug 则停下报告用户走修改机制；全部通过则收尾

通用关键点：

• 实现 agent 和测试 agent 各自独立建立上下文，互不污染——这是 B 模式"上下文隔离"的核心
• 两个 agent 之间不直接感知彼此，只通过"实施分段状态"区块这个共享文档间接交接
• 调度方只做"读状态 → 判断 → 派发"，不参与实现或测试本身

具体客户端的落地参考：不同 agent 框架的子 agent / 后台任务 / 多窗口能力各不相同。本文不锁定具体实现。使用 ZCode 时，详见 assets/references/zcode-scheduling.md（按需加载：启用 B 模式且需要具体操作指引时再读）。其它客户端可参照该文件思路，对照自身能力做适配。

重要边界：技能不锁定具体调度实现

技能定义的是交接协议（实施分段状态区块的格式和语义）和角色职责（实现/测试各做什么），不锁定具体怎么调度。任何能"读文件、启动子任务、写文件"的框架都能落地 B 模式。

阶段切换的确认原则

阶段之间不是自动跳转的，需要显式信号：

进入条件	满足条件
进入讨论	（技能被手动激活即开始）
讨论 → 设计	用户明确同意固化方案，且未决疑问清单已清空
设计 → 实施规划	设计文档完成并经用户认可
实施规划 → 实施	用户明确要求开始动手
实施 → 设计（修改）	实施中发现方案缺口，按"修改机制"停下改设计，等用户确认
实施 → 讨论/设计（回退）	实施中发现根本性错误，AI 建议回退，用户最终判定后回退

如果拿不准是否该切换，默认停在当前阶段继续讨论，主动问用户。不要替用户做"方案已经够好了，可以开始写了"的判断。

模板使用

创建新文档时，从 assets/ 目录读取对应模板：

• assets/readme.md → docs/design/README.md（全局任务总览）
• assets/task-status.md → 00-任务状态.md（普通任务 / 子任务）
• assets/parent-task-status.md → 00-任务状态.md（父任务专用，A 模式启用时）
• assets/communication.md → 01-沟通过程.md
• assets/design.md → 02-设计.md（含验收标准区块；父任务需额外含模块拆分 + 接口契约区块）
• assets/implementation.md → 03-实施.md
• assets/test.md → 04-测试.md（实施规划阶段生成）

读取模板，填充实际内容，写入任务文件夹。不要凭空捏造文档结构。

技能迭代与旧任务文档

技能会持续迭代，模板和规范会更新，但已经在用的旧任务文档不会自动迁移到新规范。这是有意为之——目的是保护用户对文档结构的既有记忆，维持多上下文记忆机制的稳定性。文档结构是用户换上下文后快速定位的记忆锚，锚不能因为技能升级就被频繁变形。

处理原则：

• 不主动迁移：AI 不擅自扫描旧任务、不擅自对齐规范，即使发现旧文档格式与新规范有出入（例如旧文档有"回退记录"区块而新规范要求"变更记录"）。发现的差异最多在"实施期备忘"或对话里提一句，不擅自动手。
• 只在用户显式指令下迁移：用户主动要求"把任务 X 的文档对齐当前技能规范""迁移任务 X 到新格式"之类时才动手。AI 不替用户判断"这个旧任务该不该迁"。
• 增量补充优先：迁移默认只针对与新规范不符的部分做补充/修改，保留原文档整体结构和内容，不推翻重写。这样用户换上下文回来不需要重新阅读理解整个文档——结构没动，记忆锚还在。
• 用户明确要求重写时，支持重写，但必须先备份原文件再生成新文件：
  • 不在原文件上直接覆写
  • 备份文件加日期或版本后缀，如 00-任务状态.md.bak.20260617
  • 新文件沿用原文件名，承载重写后的内容
  • 原文件是用户的历史记忆锚，即使重写也要保留原始版本，以备对比或回退
• 迁移/重写前先说明范围：动手前先告诉用户会改哪几处（增量）或重写哪些文件（全量），改完简述动了什么，保持可预期。

反模式（要避免的）

• ❌ 讨论阶段就开始写业务代码——本末倒置。
• ❌ 把方案变更直接写进实施文档而不更新设计文档——破坏单一事实来源。
• ❌ 新对话进来不读状态文档和 README，让用户复述进度——浪费上下文。
• ❌ 实施时遇到偏差悄悄改实现、不回写设计——设计文档会逐渐失真。
• ❌ 后端项目写了前端实现细节，或接口变动没落到接口清单——前端拿不到联调依据。
• ❌ 没有显式信号就自动推进阶段——剥夺用户的决策权。
• ❌ 实施中发现方案缺口（漏字段/分支/字典值等）却直接改实施文档、不回设计文档、不等用户确认——应走"修改机制"：停下→先改设计→等确认→改实施→继续。
• ❌ 实施中发现根本性错误却硬着头皮改实施文档，或 AI 自行判定回退——应走"回退机制"：AI 只能建议，用户最终判定，记回退记录后回到讨论/设计重新对齐。
• ❌ 大步骤勾了但里面小步骤还漏着——大小步骤都要独立标记。
• ❌ 讨论发散收不回，未决疑问被新话题淹没——靠未决疑问清单强制收敛。
• ❌ 接口清单里出现"具体取决于现有代码""实施阶段再确认"之类含糊话术，或用【实施期确认】标签把不确定性合法化——依赖现有代码的事实必须在设计阶段读代码确认，设计文档交付时接口清单必须完全确定，否则前端无法联调。
• ❌ 技能迭代后擅自迁移旧任务文档、擅自对齐新规范——破坏用户记忆锚。只在用户显式指令下迁移；且默认增量补充、不全量重写；用户要求重写时必须先备份原文件再生成新文件。
• ❌ 设计文档只写方案不写验收标准——验收标准是需求边界，缺了它就没有"做完了"的客观定义，实施期验收只能凭感觉。
• ❌ 实施文档里写"单元测试覆盖 XXX"之类的泛泛动作，不引用具体用例编号——测试动作必须指向 04-测试.md 里的具体用例（如"对照 T-EX-03 验证"），否则测什么、预期是什么都不明确。
• ❌ 走完修改/回退机制后不重跑回归用例（T-R）——局部改动可能引发全局回归，必须重测关键路径。
• ❌ A 模式下父任务设计没定（模块拆分或接口契约未产出）就启动子任务——子任务之间必然冲突。父任务的设计必须先经用户确认。
• ❌ A 模式下子任务擅自修改父任务定义的接口契约——接口契约是多模块共识，必须回到父任务走修改机制，并通知所有依赖该接口的子任务。
• ❌ A 模式下子任务再嵌套子任务（超过一层）——通常说明拆分粒度不对，该子任务应重新规划为独立父任务。
• ❌ A 模式下父任务不排子任务依赖关系就让子任务全部并行——依赖方会在被依赖方未完成时卡死；依赖关系必须在父任务设计阶段明确。
• ❌ B 模式下测试 agent 自己改实现 bug——职责必须分离：测试只挑刺，修复回实现 agent；且修复后必须由测试 agent 复测，实现 agent 不能单方面声明闭环。
• ❌ B 模式下用同一个 agent 串行当"实现"和"测试"两个角色——B 的核心价值是上下文隔离，物理上必须是两个独立 agent，否则上下文根本没隔离，B 等于没启用。
• ❌ B 模式下测试 agent 发现设计 bug 就自行改设计——设计变更影响范围大，必须触发修改机制并经用户确认；测试 agent 只能初判并报告。