夜雨聆风Spec 会在需求澄清、方案讨论和验收定义中逐步形成，但它不能永久保留成一份开发流水账。更实用的做法，是把当前有效规则、历史决策理由和本次实施计划分开维护，并在开发结束后完成一次文档收敛。
上一篇写到，旧项目不需要先补齐全部历史文档。
可以从下一次重要变更开始，修改到哪里，就确认并补齐哪里的规则。
真正做过几轮以后，另一个问题很快会出现：
Spec 到底是开发过程中的讨论文档，还是项目结束后的最终文档？
我的答案是：
它从过程中形成，但不能永远停留在过程里。开发结束后，要收敛成下一次仍然可以信任的当前规则。
两个极端，都会让 Spec 失效
第一个极端，是把 Spec 当成一次性讨论。
需求开始前写一份。开发完成后不再维护。下次修改同一个功能，又开新会话、写新文档。
几轮以后，项目里会同时出现：
第一版需求 第二次修改说明 某个 Bug 修复方案 一份代码实现总结 一份更新但不完整的规则
每份都讲对了一部分，却没人知道哪份代表现在。
第二个极端，是把所有过程都堆进同一份 Spec。
候选方案、聊天记录、文件清单、调试命令、测试输出、上线总结，全都不断往后追加。
文档越来越长，也越来越难回答一个最基本的问题：
系统现在到底应该怎样运行？
一个退款需求，为什么会产生三类文档
继续用部分退款作例子。
需求讨论时，团队可能需要回答：
哪些订单允许退款 能否多次部分退款 退款金额怎样计算 异步回调失败后怎样处理 账务和订单状态怎样保持一致
讨论中还会比较几个方案：沿用原接口，还是拆出退款指令；同步等待结果，还是先受理再异步完成。
进入开发以后，又会出现另一批内容：修改哪些模块、怎样迁移数据、测试顺序、发布步骤和回退方案。
这些内容都重要。
问题是，它们的用途和生命周期不一样。
如果全部塞进一份 Spec，下一次 Agent 很难区分当前规则、历史理由和已经完成的一次性步骤。
我会把文档分成三层
这里的 “Current Spec / Decision Record / Plan”，是本文采用的项目治理分层，不是 Superpowers 官方规定的固定命名。
Superpowers 官方工作流会区分设计规格和实施计划，也会保留 Review 与验证门槛；至于团队长期怎样组织项目事实，仍然需要结合自己的仓库和协作方式决定。
Current Spec：系统现在应该怎样
它记录当前仍然有效、下一次开发还要依赖的内容：
业务目标与适用范围 当前对外行为 核心规则和不变量 输入、输出与异常边界 权限、数据和兼容约束 可以重复执行的验收标准
判断一段内容是否应该留在 Current Spec，可以问：
下一次修改这个功能时，还需要依赖这条信息吗？
需要，就保留。
Decision Record：为什么这样决定
它记录：
当时有哪些可行方案 每个方案的主要代价 最终选择了什么 为什么没有选择其他方案 决策依赖哪些前提 什么条件变化时要重新评估
这类内容不必每次开发都完整加载。
但当团队准备推翻旧方案、调查历史问题或重新评估边界时，它很有价值。
Plan：这一次准备怎样实现
它服务于当前任务：
修改哪些模块和文件 实施顺序是什么 数据怎样迁移 测试怎样安排 如何发布和回退
Plan 的生命周期通常短于 Current Spec。
任务完成后可以归档，但不应该继续冒充系统当前规则。
一句话区分：
Current Spec 说明系统现在应该怎样，Decision Record 说明为什么这样决定，Plan 说明这一次准备怎样实现。
Spec 的确会从讨论中生长出来
复杂需求很少能在一开始就写完整。
它通常会经历：
问题提出 → 边界澄清 → 方案比较 → 决策确认 → 验收标准形成。
在这个过程中，很多信息都不能丢：
用户真正要解决什么 哪些需求明确不做 为什么选择方案 A 哪些风险被接受 哪些问题暂时没有答案
但保留过程，不等于把过程永久堆在当前规格正文里。
正确做法是让信息去到适合它的位置：
当前仍然有效的规则，进入 Current Spec 重要选择和理由，进入 Decision Record 本次执行步骤，进入 Plan 临时聊天、调试输出和一次性记录，留在任务历史或归档
开发结束后，别只改任务状态
代码完成以后，很多团队只做一件事：把任务改成“已完成”。
文档还需要一次收敛。
可以按下面这组问题检查：
最终实现有没有改变原来的决定 开发中有没有发现新的业务规则 哪些早期假设已经被证明错误 哪些验收条件以后仍然可以复用 哪些内容只属于本次实施 哪些未解决项和风险必须继续保留
然后再更新对应文档。
这一步的目标不是让文档和代码每个细节完全重复，而是让下一次开发拿到一份低噪声、可追溯、能执行的上下文。
Current Spec 不是永远不变
“最终文档”这个说法容易造成误解。
系统会继续变化，业务规则也会变化。Current Spec 当然可以更新。
关键不在于它能不能改，而在于为什么改：
有明确的新需求 有新的业务或技术决策 实现暴露了原规格缺口 原规则已经失效 验收边界发生变化
如果没有这些变化，就不应该为了证明“这次也做了文档工作”，把测试日志、聊天记录和文件清单继续追加进去。
文档越多，不等于上下文越好
AI Coding 很容易产生大量文档。
每个会话都能生成需求、计划、总结和测试报告。
如果没有分层和收敛，资料越多，Agent 越难判断什么是当前事实，什么只是一次历史过程。
真正高质量的上下文，不是内容最多，而是：
当前规则明确 历史决策可追溯 本次计划可执行 三者之间互相链接，但不互相污染
所以 Spec 既是过程的一部分，也要留下一个可以被下一次开发继续依赖的结果。
它可以从讨论中生长。
但开发结束以后，应该留下当前有效规则，而不是完整聊天记录。
下一篇：没有新增决策时，还需要修改 Spec 吗？
布噜AI · 企业级 AI Coding