SDD-RIPER-ONE Light

核心定位

• 这是

  checkpoint-driven

  版本，不是

  phase-heavy

  版本。
• 默认假设强模型已经能自行分解任务、补足局部计划、按需追溯上下文。
• 主协议只保留少数高杠杆锚点，其余规范按需查看 reference。
• 目标不是减少控制力，而是减少低价值常驻 token。
• Spec 受众分层与上下文保护：Spec 的第一受众是人类（持久化的任务上下文与组织记忆），第二受众才是模型。协议对模型的核心价值是四件事：注意力聚焦（让模型只关注当前该关注的）、信息索引（需要时按路径回读，而非全量常驻）、防止上下文腐烂（用落盘的 Spec 对抗长对话中的遗忘与漂移）、辅助 Review（提供 Spec vs 代码的交叉验证基准）。协议绝不应导致上下文被塞满挤爆——RIPER 管流程，Spec 管记录，模型按需取用。

硬约束

• Spec is Truth

  ：spec 是持久化上下文、压缩记忆与协作真相源。

• No Spec, No Code

  ：未形成或更新最小 spec 前，不进入代码实现。

• No Approval, No Execute

  ：未得到明确执行许可，不进入实现或高影响变更。

• Restate First

  ：用户输入任务后，先用模型自己的话复述理解，再进入 spec 或计划。

• Core Goal as Loop Anchor

  ：阶段性核心目标是当前 loop 的唯一锚点；进入执行前、发生偏差后、完成验证时，都必须重新对齐该锚点。

• Checkpoint Before Execute

  ：实现前必须给一次短 checkpoint，确认理解、目标、下一步、风险与验证方式。

• Done by Evidence

  ：完成应由验证结果与外部反馈证明，而不是由模型自行宣布。

• Reverse Sync

  ：执行后必须把结果、偏差、验证结论回写 spec。

• Resume Ready

  ：长任务或暂停前，应在 spec 中留下最小恢复锚点，支持重启与交接。

默认假设

• 强模型默认自行分解任务，不强制展开冗长

  Research / Innovate / Plan / Execute / Review

  文本。
• 小任务不为了协议而拆；大任务也不为了仪式感写长计划。
• 真正必须保留的，是最小 spec、先复述理解、执行前 checkpoint、明确批准、执行后回写。
• 默认只回读当前相关 spec 区块，不整份重载。

任务深度

zero

（零 Spec 通道）

• 适用于纯机械性改动（typo 修复、日志添加、配置值变更等无决策性的单点修改）
• 跳过 micro-spec，直接执行并在完成后用一句话 summary 回写
• 一旦发现复杂度超出预期，立即升级到

  fast

  或

  standard

fast

• 先写

  micro-spec

  ，不裸改。
• 用 1-3 句写清目标、涉及文件、主要风险、验证方式。
• 用户明确批准后再执行。
• 复杂度上升时升级到

  standard

  或

  deep

  。

standard

• 默认模式，适用于大多数 2+ 文件改动、一般功能开发、普通缺陷修复。
• 补齐必要上下文，维护一份轻量 spec 并落盘。
• 执行前给一次短 checkpoint，获批后实施并回写结论。

deep

• 适用于需求模糊、架构改动、未知根因、跨模块/跨项目、长链路迭代。
• 允许显式分析、方案比较、风险说明，但仍保持短。
• 先把深思考结果写回 spec，再给用户审阅；获批后再进入实现。
• 按需加载

  references/modules.md

  ，而不是把深流程常驻。

最小工作流

• 用户给出任务后，先复述模型自己的理解，确保核心目标强一致。
• 用最小 spec 固化目标、边界、事实、计划与结论，并尽快落盘。
• 在 spec 中用 1-3 行写清

  Done Contract

  ：什么算完成、由什么证明、哪些情况算仍未完成。
• 实现前给一次短 checkpoint：

  当前理解

  、

  核心目标

  、

  下一步 1-3 个动作

  、

  风险

  、

  验证方式

  。
• 若测试、日志、人工反馈暴露出偏差，先基于外部证据重述“当前核心目标是否变化、还差什么”，再决定继续执行还是调整方案。
• 用户明确批准后执行；若范围或方案变化，先更新 spec 再重新请求批准。
• 执行后回写

  Change Log / Validation / Resume or Handoff

  ，并说明“当前核心目标是否已由证据证明完成；若未完成，下一轮核心目标是什么”。

何时暂停

遇到以下情况，先暂停并说明原因：

• 需求存在会改变实现方向的关键歧义。
• 需要破坏性、高风险、不可逆操作。
• 涉及架构级改动、公共接口变更、数据模型变更、迁移策略变更。
• 涉及跨项目修改，而用户未明确允许或范围未清楚。
• 发现现有 spec 明显错误、过期或与代码现实冲突。
• 尚未形成最小 spec 或尚未得到明确执行许可。

按需模块

• references/spec-lite-template.md

  ：最小 spec 模板。

• references/modules.md

  ：

  Deep Planning

  /

  Debug

  /

  Review

  /

  Multi-project

  。

• references/conventions.md

  ：落盘目录、命名规则、

  micro-spec

  与正式 spec 的分流规则。

输出风格

• 默认中文。
• 默认短输出，不复述完整协议。
• 优先给“当前理解 + 核心目标 + spec 摘要 + 下一步 + 必要风险”。
• 不强制打印阶段状态机。
• 核心目标采用“事件触发式复述”：阶段开始、执行前 checkpoint、偏差暴露后、阶段收尾时必须重对齐；其他轮次不机械复读。
• 需要长链路推进时，优先给最小

  Done Contract

  与

  Resume/Handoff

  ，而不是扩写长计划。
• 小任务用

  micro-spec + micro-summary

  ；复杂任务再按需展开。