任务分档
“团队应该写 spec”不等于”每个任务都要产出一份完整规格文档，再走完所有阶段”。前者要求动手前把意图、边界和验证方式说清，并留下可核对的痕迹；后者却忽略了任务之间的差别。改一句文案和迁移生产数据都套同一条重流程，前者会被文档拖慢；都只留一句话，后者又可能因为约束不够而失控。
所以真正的问题不是”要不要写 spec”，而是”这次 spec 要写多厚，配套流程要多重”。本手册分成直接做、轻 spec、完整走 spec-kit 三档；三档都有明确意图和验证证据，只是记录与约束强度不同。需求已经按第 10 章分解成一个个 feature，这一章针对单个 feature 判它走哪一档；每一档具体怎样执行，放在后面的流程章节。
11.1 三档
三档的区别不是项目类型，也不只是文档厚度，而是意图澄清、过程记录和验证约束的强弱。
| 档位 | 适用条件 | 最少留下什么 |
|---|---|---|
| 直接做 | 意图清楚、局部可逆、验证直接，没有触发硬下限 | 在任务或当前对话中写下预期结果、不应改动的范围和验证方式 |
| 轻 spec | 没有触发硬下限，但存在少量需要先澄清的边界、假设或验证问题 | 一份薄规格，加最小计划和任务拆分 |
| 完整走 spec-kit | 触发硬下限，或者意图、影响面、验证方式仍有重大不确定 | 完整规格流程及与风险相称的审查记录 |
直接做不建立单独的 spec 文件，但不能只把验收条件记在脑子里。开始修改前，至少在任务描述或当前对话中留下三件事：做完什么为真、什么不能动、怎样验证。代码行为优先建立一个会失败的测试；文案、配置和操作任务没有合适测试时，可以使用检查命令、快照、配置校验或明确的人工观察。
轻 spec 是本手册定义的档位，不是 spec-kit 的原生模式。spec-kit 的实现步骤需要已有规格、计划和任务，因此轻档仍走 specify → plan → tasks → implement，但各份材料只写当前改动所需的最小内容，并跳过不必要的可选质量门。具体走法放在后面的流程章节。
完整档用于高风险或结构性改动，按完整流程处理规格、澄清、计划、任务、分析、实现和收敛。各阶段都设置审查点；哪些节点必须由人批准，取决于风险、不可逆性和用户可见性，不要求所有步骤采用同一种人工门。
同一个项目里的不同任务可以走不同档。判档针对手头这一次变更，每次开工都重新判断。
11.2 完整档的硬下限
判档的前提是意图已经补到可以决定”做或不做”。目标还没立住、连稳定的预期结果都写不出来时，先进入需求发现和评估，不启动开发流程；决定要做以后，再对具体变更判档。
命中下面任何一项，默认完整走 spec-kit：
- 删除或改写生产数据，执行不可逆迁移；
- 改动授权、资金、计费或其他高风险业务规则；
- 让系统产生无法撤回的外部副作用，例如发送真实通知或调用不可逆的外部操作；
- 改变公开接口、持久化格式或跨系统契约，并要求现有调用方或历史数据配合迁移；
- 改变多个信任边界、部署单元或数据所有者之间的接口与协作方式。
这些硬下限约束的是变更的设计和实现，不是已经批准的发布动作。按既定流程执行一次常规部署，走运维 runbook、审批和红线，不因为”发生了部署”重新启动开发规格流程；部署时如果临时加入未评估的变更，再对新增部分判档。
“已经理解风险”不等于风险消失。只有高风险步骤被隔离，而且回滚、演练或替代控制已经有证据时，才能重新判断剩余工作；不能因为方案写清楚了，就自动降档。
11.3 三问确定基础档
没有触发硬下限时，用三问判断基础档。每一问都按低、中、高判断，冲突时取最高档。
| 判据 | 低 | 中 | 高 |
|---|---|---|---|
| 意图缺口 | 预期结果、边界和非目标都已写清 | 有少量待答问题，回答后不改变任务方向 | 已经决定要做，但关键行为或边界仍未确定，不同答案会形成不同实现方案 |
| 可撤回性 | 一次 revert 或恢复原值即可回到原状 | 需要多个步骤恢复，但恢复路径清楚且可验证 | 恢复依赖未知状态、人工补偿或无法重放的数据 |
| 改动面 | 位于一个责任边界内，接口不变 | 同一系统内涉及多个组件，但边界和所有者清楚 | 改变公共边界，或影响多个系统、部署单元和数据所有者 |
三项都是低，基础档是直接做；出现中项但没有高项，基础档是轻 spec；出现任何高项，进入完整档。这里判断的是边界和恢复难度，不按文件数量机械分档。同一模块内改多个文件可能仍是直接做，改一个授权判断也可能必须完整走流程。
任务名称也不能直接决定档位：
| 常见任务 | 可以直接做的边界 | 应当升档的情况 |
|---|---|---|
| 改文案 | 不改变法律含义、产品承诺和关键操作提示 | 改协议、价格、隐私说明或安全提示 |
| 调配置 | 本地、可回退、不影响真实环境 | 影响生产部署、权限、数据或外部服务 |
| 升依赖 | 小范围更新，接口和行为不变，验证充分 | 大版本升级、安全替换或需要迁移调用方 |
| 加字段 | 内部临时结构，不持久化、不对外暴露 | 涉及数据库、序列化、公开接口或历史数据 |
11.4 五个反证信号
确定基础档后，再检查五个信号，防止三问遗漏藏得更深的不确定性：
- 意图模糊：任务描述看似完整，但不同人仍可能实现出不同的用户行为。
- 代码结构不确定：还不知道改动属于哪个模块、由谁拥有，或者要先探索才能确定边界。
- 验证熵：没有稳定的成功判据，或者多个验证结果可能互相矛盾。
- 风险：错误会影响真实用户、敏感信息、线上稳定性，虽然还没有达到硬下限。
- 未决假设：实现依赖尚未证实的前提，前提错误会推翻方案或造成大范围返工。
任一信号明显偏高，进入完整档；出现中等信号时，直接做升为轻 spec。已经处于轻 spec，且多个中等信号叠加，也升到完整档。五个信号始终检查，不只在三问拿不准时才使用。
11.5 任务进行中的改档
做进去以后发现新边界、新风险或关键假设不成立，立即停止当前路径并升档，补齐更高档要求的澄清和记录。已经写出的代码不能代替缺失的判断依据。
降档只针对尚未开始的独立剩余工作，不把整个任务已经触发的保障撤掉。降档前要重新检查硬下限，保留已经形成的规格、决策和验证记录，并写明原来的风险为什么已经不存在。风险只是被理解、还没有被消除时，不能降档。
11.6 开工检查
按下面的顺序判档：
- 写下预期结果、不应改动的范围和验证方式；目标还没立住或尚未决定要不要做时，先进入需求发现和评估，暂不判档。
- 检查完整档的硬下限；命中任何一项，进入完整档。
- 用意图缺口、可撤回性和改动面三问确定基础档，结果冲突时取最高档。
- 用五个反证信号复查；高信号进完整档，中等信号按规则升档。
- 确认当前档位需要留下的材料，并进入对应流程。
中途出现新事实时重新执行这五步。升档立即生效；降档只适用于独立的剩余工作，而且不能突破硬下限。
本章小结
先把意图补到足以决定做或不做，再开始判档。确定要做后，先检查不可逆操作、高风险业务和关键边界等硬下限，再用意图缺口、可撤回性和改动面确定基础档，最后用五个信号反证。直接做也要留下最小验收痕迹；轻 spec 保留 spec-kit 的必要阶段，只把材料写薄；降档不能撤销已经触发的风险保障。
参考与出处
- spec-kit 从规格、计划和任务进入实现的标准流程：Spec Kit quickstart
- implement 根据已有计划和任务执行的官方命令定义：Spec Kit implement command