按功能写需求、设计和任务，获批后再开发

## 把项目整体指导和各功能的规范分开保存 有意识地维护两个层次的开发指导。项目指导记录长期稳定的产品背景、技术选择、代码库结构、政策和约定。功能规范定义一项范围明确的变更，并包含其需求、设计、任务、调研和验证证据。 开展功能工作前，先加载相关的项目指导；稳定约束发生变化时，应使其保持最新。绝不能让功能特有的决策在不加说明的情况下改写项目级指导。识别当前有效的规范并公开其所处阶段，使恢复后的工作从已记录的状态继续，而不是依靠猜测。 ## 先弄清范围，再决定用单个规范还是用路线图拆分 先进行一轮简短的前期调研，明确想法、受影响的系统、依赖关系和预期结果。对于一项范围明确的功能，直接启动一份规范。对于范围广泛的计划，应创建简要说明和路线图，将工作拆分为内聚的多份规范，记录依赖关系，并按依赖关系分批安排实施。 更改已有系统时，应在设计前检查现有实现，并记录差距、兼容性约束和可复用组件。只有在有意选择时才使用快速通道；即便如此，也必须产出必要的需求、设计、任务和验证工件。 ## 按顺序写需求、设计和任务，每一步都取得批准 按顺序推进规范的各个阶段： 1. 编写可测试的需求，定义行为、边界、约束和验收条件。 2. 在将需求作为设计依据之前，先由人工审查这些需求。 3. 制定设计，将每项需求映射到架构、接口、数据流、风险和验证。 4. 审查设计，然后推导出有先后顺序的实施任务，并注明依赖关系和完成检查。 5. 除非经过有意选择的快速通道已经批准了完整流程，否则应在实施前取得任务计划的批准。 如果范围发生实质性变化，应返回受影响的阶段并重新验证下游工件，而不是修补已经过时的计划。 ## 只实施已批准的任务，并选定全部或指定任务的模式 只能从已批准的任务开始实施，并明确选择执行模式。在全范围模式下，自主执行已批准的计划；适合时按任务拆分工作，整合结果，取得独立审查并运行最终验证。在选定任务模式下，只实施当前上下文中点名的任务，不得改动无关任务。 已完成的工作日后需要重新验证时，应单独开展实施审查。只有在缺少必要信息或所需权限、出现安全问题，或缺少会改变范围的决策时才暂停；困难本身并不是放弃已批准工作流的理由。 ## 复用开发技能，并接受独立审查 将专门的开发程序维护为可复用技能，其中包含一条清晰的入口指令，以及可选的模板、示例或辅助参考资料。技能应结合当前任务上下文运行，并且只有在平台、权限和任务范围允许时，才可以委派范围明确的并行调研或审查。 对实施中的发现采用对抗性审查，对故障采用根因优先的调试，并在宣称完成之前依据最新证据进行验证。即使相关技能适用于该任务的可能性很小，也要检查并应用它；表面上的简单不能证明其保障措施没有必要。 ## 持续更新规范状态，用最新证据证明已完成 即使内部推理使用另一种语言，也要使用为该规范配置的目标语言编写规范工件。在整个工作流中持续提供状态，包括当前阶段、已批准的工件、依赖关系、已完成的工作、剩余任务和待解决的决策。 不要仅凭源代码检查或任务完成就宣称成功。运行适用的实施验证，检查生成的工件，并将完成说明与当前证据关联起来。审查或实施改变结果后，应更新规范和状态，使下一个会话继承真实状态。