Cyber-Ming English

开始这里与落地形态

最小稳定闭环指南

English中文
最小稳定闭环指南

最小稳定闭环指南

中文 | English

这页就是第二层的跟手稳定化页。

默认目标也很简单：尽量不离开这一页，也能把最小稳定闭环搭起来。

前提只有一个：你已经手工跑通过第一层最小闭环。

这一页解决什么问题

这页解决的不是“第一次怎么跑通”，而是第二层怎么成立：

  • 跑通之后，什么才叫真正的最小稳定闭环
  • 为什么稳定闭环不是只装 Skill，也不是只做一个 Web 专有应用
  • 为什么 IDE 端 Skill 与 Web 端固定提示词必须同时就位
  • 以及你现在应该先做哪几步，才能把双端一起固定下来

一句话先钉死

最小稳定闭环 = IDE 端 Skill + Web 端固定提示词 / 专有应用，二者缺一不可。

你可以先用两个提示词手工跑通最小闭环；但如果你要进入“更稳定地反复跑”的形态，就必须把两端一起固化。

稳定闭环不是只稳一边

第二层先走这条稳定化路由

  1. 先确认你已经手工跑通过至少一轮最小闭环
  2. 先判断 IDE 端宿主是否支持项目级 Skill，Web 端宿主是否支持固定 system prompt 或专有应用
  3. 先把 IDE 端稳定下来，再把 Web 审计端固定下来
  4. 双端都固定好以后，每轮实际运行仍然只用两条很短的开工词
  5. release 同步的也不再只是 Skill，而是 IDE skill bundle + Web 审计端固定 prompt / app prompt

先判断：你是不是已经到了该稳定化的时候

适合现在进入第二层的情况

  • 你已经理解审批先行、原子执行合同、证据闭环三件事
  • 你已经手工跑通过至少一轮，不想每轮都重新贴整套长提示词
  • 你经常在 AI coding 里遇到伪完成、惰性修补、上下文腐烂
  • 你想把 IDE 执行位与 Web 审计位的动作都固定下来

还不急着进入第二层的情况

  • 你还没真正跑通过第一层
  • 你现在只是想先理解协议，不急着长期采用
  • 你的宿主对 Skill 或固定 system prompt 的支持还不稳定
  • 你当前任务很小，不值得立刻搭完整稳定化骨架

为什么两边都不能少

Skill 稳定节奏，不替代真相

只有 Skill，不算稳定闭环

如果只有 IDE 端 Skill，而 Web 审计端每轮还在临时解释角色、临时解释审计法统，那么：

  • 执行位更稳了
  • 审计位却还在漂
  • 人类每轮仍要重新布阵

这不叫稳定闭环，只叫“执行端更稳定”。

只有 Web 固定提示词，也不算稳定闭环

如果只有 Web 端固定提示词，而 IDE 端仍然每轮都靠手工长 prompt 才能挤出像样的原子执行合同，那么：

  • 审计位更稳了
  • 执行位却还在漂
  • 人类仍要在执行端反复补制度

这不叫稳定闭环，只叫“审计端更稳定”。

为什么必须双端一起固化

最小稳定闭环的目标，不是让某一边更强，而是让：

  • 执行端稳定地产出原子执行合同
  • 审计端稳定地坚持只审方案与证据
  • 人类不必每轮重新解释法统

所以稳定闭环的最低标准，天然就是双端同时就位。

IDE 端：最小要求

IDE 端要做到的最低标准是：

  • 本地已有仓库，或 agent 能自己 clone 仓库
  • 宿主支持项目级 skill 目录，或至少支持按项目加载 skill 定义
  • 已接入核心三件套：

- global_rules - approval-first-planner - approved-checklist-executor

如果 IDE 端做不到这些，就不要自称“最小稳定闭环已成立”。

给执行端 agent 的接入提示词

你现在进入最小稳定闭环接入阶段。

目标不是直接开工，而是先把 IDE 端稳定下来。

如果你的宿主支持本地仓库操作与项目级 skill，请按下面顺序执行：
1. 若本地尚无仓库，先 git clone https://github.com/blackzhanzhan/Cyber-Ming-Protocol.git
2. 读取仓库内 `skill/` 的核心三件套：`global_rules`、`approval-first-planner`、`approved-checklist-executor`
3. 按你当前宿主支持的项目级 skill 机制接入这三件套
4. 只回报：是否支持、如何接入、哪些文件被当作实际法统、接入后下一轮会如何工作

如果你的宿主不支持项目级 skill，请明确说“IDE 端最小稳定闭环当前不成立”，不要假装已经稳定。

无论如何，都不准跳过：先交原子执行合同与边界 -> 等人类准奏 -> 再执行。

IDE 端就按这四步做

  1. 确认宿主支持本地仓库操作与项目级 skill，或至少支持项目范围装载
  2. 如果本地还没有仓库，先 clone 当前仓库
  3. 先接核心三件套：global_rules、approval-first-planner、approved-checklist-executor
  4. 如果宿主不支持项目级 skill，就明确承认“IDE 端稳定闭环当前不成立”

如果你还想判断 Skill、协议、Web 审计资产到底各是什么，再看第三层的 0。

Web 端：最小要求

Web 端要做到的最低标准是：

  • 不是每轮临时手打一大段 prompt
  • 而是把审计位法统固定成 system prompt，或固化进 Gem / GPT / 专有应用
  • 固定后的 Web 审计端只负责审方案与证据，不代替执行

Gem / GPT / Gemini Gem / 自定义应用，不是另一条协议路线。它只是 Web 端固定提示词的承载器。

如果 Web 端还没有固定提示词，那也不要自称“最小稳定闭环已成立”。

Web 端就按这四步做

  1. 不要每轮再手打一整段长审计法统
  2. 把审计位法统固定成 system prompt，或固化进 Gem / GPT / 专有应用
  3. 固定后的 Web 审计端仍然只审方案与证据，不代替执行
  4. 如果 Web 端还没有固定提示词，就明确承认“Web 端稳定闭环当前不成立”

Web 端最小固定提示词骨架

你是 Cyber-Ming-Protocol 的 Web 审计位。

你只负责：审方案、审证据、回判断。
你不是执行位，也不是终裁者。

铁律：
1. 只审方案与证据，不直接写代码，不给补丁，不代替执行位做架构决定。
2. 重点检查：伪完成、漏步、假证据、偷换目标、粒度过粗、把推断当真实执行。
3. 当前输入如果不足，先说还缺什么，不要代为实现。
4. 即使你认为可以执行或可以验收，也只回送审计判断；真正准奏与终裁都在人类手里。
5. 输出默认只允许包含：可批 / 不可批、主风险、缺失项、缩刀建议。

如果你还想判断这套稳定化形态和常见 workflow / spec-driven / agent-team 的关系，再看第三层的 0。

跑稳之后，每轮实际仍然只用两条开工词

双端都固定好之后，每轮实际运行反而不该更重，而应该更轻。

复制给执行位

按已接入的仓库法统处理本轮需求：<你的需求>
先交原子执行合同与边界，不准直接施工。

复制给 Web 审计端

当前进入本轮审案。
先审这份原子执行合同 / 证据包，不要代为实现；只回判断、主风险、缩刀建议或放行结论。

什么算最小稳定闭环已经成立

至少满足这几条：

  • 执行端不再需要每轮重新被教一次原子执行合同格式
  • Web 审计端不再需要每轮重新被教一次角色边界
  • 人类不再需要每轮重写整套法统，只需要路由方案、反馈与证据
  • 缺 IDE 端 Skill 或缺 Web 端固定提示词时，系统会明确承认“稳定闭环未成立”，而不是假装已经稳定

release 为什么必须双端一起发

如果你准备把稳定闭环当正式使用形态，那么 release 同步的就不应该只是 Skill。

双端不一起发，就会版本错位

更准确的 release 单位应该是：

  • IDE skill bundle
  • Web 审计端固定提示词 / 专有应用 prompt

只升级一边，不升级另一边，就会出现：

  • IDE 端按新法统工作
  • Web 端还按旧提示词审案

最后看起来像协议不稳，实际上只是双端版本不同步。

下一步

  • 如果你想继续进入第三层，先看 0
  • 如果你想直接对位主流方案，再看 0
  • 还没跑通过第一层：回到 0