ce-plan

建立实施需求的护栏——决策、单元、文件、测试、范围、风险——无需规定实际代码或分步编排。计划捕捉什么；执行代理找出如何。

ce-plan 生成的计划是 带有执行护栏的决策文档，而不是实施编排。该计划捕获了已做出的决策、范围内或范围外、存在哪些原子工作单元、每个单元接触哪些文件、必须通过哪些测试场景以及需要缓解哪些风险。它不预先编写代码、精确的 API 签名或分步 shell 命令序列 - 这些是供实施代理（ce-work、另一个 AI 代理或人类）确定代码何时位于它们前面。

这种分离很重要。预先编写实施的计划在实施时往往是错误的：签名无法编译、编排陈旧、微步骤掩盖了真正的决策。捕获护栏的计划可在数周或数月内保持便携性，并尊重实施者在执行时做出的判断。

它适用于结构有帮助的任何多步骤任务——软件功能、重构、错误修复、研究计划、研究工作流程、活动规划，甚至年度热水箱维护之类的事情。相同的发动机；相同的U-ID稳定性；相同大小的模板。

这是复合工程构思链的第三步：

/ce-ideate         /ce-brainstorm      /ce-plan             /ce-work
"What's worth      "What does this     "What's needed       "Build it."
 exploring?"        need to be?"        to accomplish
                                        this?"

但它也很独立——许多团队直接通过需求文档、GitHub 问题、PRD、粗略描述或非软件多步骤任务来实现 ce-plan。

TL;DR

＃＃ 问题

人类（或没有结构的人工智能）编写的计划往往会以可预测的方式失败：

• 重新编号混乱 - 重构单位列表，问题、PR 和对话中的每个引用现在都是错误的
• 含糊的测试“场景” - “测试新行为”没有告诉实施者任何信息
• 忘记起源背景 - 头脑风暴决定这是针对特定演员的，但计划从未提及他们
• 半解决的问题 - 几个月后计划中的“待定：找出缓存策略”
• 实现编排 - 精确的方法签名、微步骤或预先编写的 shell 序列，然后在实际开始时出现错误
• 没有深度检查 - 作者没有透露该计划是否有足够的基础来执行

解决方案

ce-plan 将需要尊重哪些决定与如何在代码中满足这些决定分开：

• 计划捕获决策、范围边界、原子单元、文件、测试场景和风险——执行的形式和约束
• 它不预先编写代码、精确的 API 签名或逐步的 shell 编排——这些决定在执行时推迟给实施代理
• 稳定的 U-ID 可以在重新排序、拆分和删除后幸存下来 - 因此阻止者引用和 PR 提及在整个计划编辑过程中保持有效
• 计划决策可追溯到起源（头脑风暴中的 R-ID；测试场景中引用的 AE-ID）
• 研究在构建之前并行进行（存储库、学习、框架文档、最佳实践、规范流程）
• 编写计划后自动运行信心检查，并派遣有针对性的子代理来加强薄弱环节
• 规划时间与实施时间问题明确分开——没有虚假的确定性

是什么让它如此新颖

1. 编排的护栏——做什么，而不是如何

计划捕获决策和约束，而不是代码：做出的决策（带有基本原理）、范围边界、工作的原子单元、涉及的文件、必须通过的测试场景以及需要缓解的风险。计划故意排除精确的方法签名、特定于框架的语法、分步 shell 序列以及伪装成实现规范的伪代码。实施代理阅读计划，看到护栏，并找出如何用面前的代码来满足他们的要求。 决定属于计划；实现选择属于执行时。

为什么？预写实施的计划是脆弱的：预先提交的签名无法编译，编排的步骤变得陈旧，并且它们剥夺了实施者应根据当前上下文做出的判断。坚持护栏的计划在数周的代码更改、实施者（人类或人工智能）以及深化过程中的编辑之间保持可移植性。

这也是同一引擎适用于非软件任务的原因。热水箱维护计划包含决策、单元、等效文件（哪些阀门、哪些手册）、测试场景（“重新填充后验证是否泄漏”）和风险，但没有代码。框架干净地转移。

2. U-ID — 实现单元具有稳定、永不重新编号的标识符

每个单元的标题为 - U1. **Name**、- U2. **Name** 等。 稳定性规则：在重新排序、拆分或删除后，切勿对现有 ID 重新编号。拆分保留了原始 U-ID 的原始概念；新单位采用下一个未使用的数字；删除会留下间隙（间隙很好，永远不会回填）。

这很重要，因为 ce-work 跨计划编辑通过 U-ID 引用单元。在深化过程中重新编号会默默地破坏每个阻止者引用、每个引用单元的 PR 描述以及每个下游对话。稳定性规则可以防止此类错误。

3. 起源追踪 — 来自整个计划的头脑风暴流程的 R/A/F/AE ID

当计划源自 ce-brainstorm 需求文档时，标识符会流经： 需求 (R-ID) 跟踪到计划的需求部分；参与者 (A-ID) 在影响行为或权限时继续前进；关键流程 (F-ID) 引用实现它们的实施单元；验收示例 (AE-ID) 引用了强制执行它们的测试场景 (Covers AE3. <scenario>)。在最终确定之前，原始文档的每个部分都会根据计划进行验证。没有什么会悄然掉落。

4. 指定类别中每个单元的测试场景

每个功能承载单元都枚举每个适用类别的测试场景 - 快乐路径、边缘情况（边界、空/零、并发）、错误/失败路径（无效输入、下游故障、权限）和集成（仅凭跨层行为模拟无法证明）。每个场景都指定了输入、操作和预期结果——足够具体，实施者不必发明覆盖范围。

5.置信度检查和自动深化

计划编写完成后，ce-plan 自动根据风险加权奖金对清单进行评分，挑选最薄弱的部分，派遣有针对性的子代理来加强它们（实施单元的正确性审查员、迁移的数据完整性监护人、关键技术决策的架构策略师），并将结果综合回计划中。自动模式直接整合结果；交互模式（当您要求深化现有计划时）呈现接受/拒绝的结果。发现薄弱部分的成本高昂的时刻是在执行期间，而不是在规划期间。

6. 并行多主体研究

第一阶段始终并行进行本地研究——repo-research-analyst（技术、架构、模式）和学习-researcher（来自docs/solutions/的机构记忆），加上spec-flow-analyzer（标准/深度计划的边缘情况完整性）和可选的Slack研究。然后，外部研究由意图决定，而不是单一的开关：显式请求（“研究竞争对手”、“网络最佳实践”、“哪个库”）始终运行并覆盖强大的本地模式，而隐式信号（薄弱的本地模式或推荐所依赖的未解决的外部选项集）也可以触发它。意图路由代理——框架文档研究员和最佳实践研究员如何构建它（实施指导），网络研究员存在什么选项或现有技术（景观/竞争对手扫描）；混合请求首先运行横向扫描，然后运行候选列表上的文档。

7. 通用规划——非软件工作的相同引擎

护栏而非编排框架可以干净地跨域传输。真实（非假设）用途包括年度热水箱维护、研究计划、旅行计划、研究工作流程和活动规划。非软件路径会跳过特定于软件的置信度检查，但 U-ID、依赖性排序、范围边界、测试/验证场景以及大小合适的模板均保持不变。

通用规划还区分了两种倾向。 计划寻求任务（旅行、学习课程、活动）产生一个保存的计划——工件就是可交付成果。 寻求答案任务是调查或分析问题（“X 发生的频率如何——这有什么大不了的吗？”、“我们的方法与 Y 相比如何？”），其中答案是可交付成果，没有人想要计划文件。对于这些，ce-plan 不会保释，也不会编写文档：它在聊天中陈述一个简短的、大小合适的攻击计划——既指导代理并向人类展示方法的工作脚手架——然后执行它（研究和综合，而不是编码）并提供答案。该计划是用问题的语言而不是技能的语言来表达的；内部机制保持隐藏，而影响对答案信任的警告总是浮出水面。只有真正微不足道的单一事实查找才能完全跳过计划并得到直接答复。

8. 接近高度——交付困难时的计划

对于难题，ce-plan 可以回答一个更高的级别：制定一个接地气的方法计划（关于如何制作可交付成果的计划）并在提交之前保持在检查点——这是一种获得结构和确定性的方法，而不是零射击脆弱的结果。它是明确输入的（“为计划制定计划”，“先不要写它——计划一下你将如何实现它”），并且很少主动提供——只有当方法确实不稳定并且出错时代价高昂，所以它永远不会成为一个烦恼。在对所提供的输入进行轻微侦察（略读，而不是深入阅读）后，它在聊天中列出了方法，文件可选且可深化。在检查点，您现在运行它或保存它以供以后使用。它绘制的边界是代码与知识工作，而不是计划与执行：代码仍然流向 ce-work 的正常路径，而非代码可交付成果被标记为 execution: knowledge-work 并通过 ce-work 的轻量级剥离（或任何代理 - 计划保持可移植）运行。 ce-plan 本身永远不会执行；它会制定进场计划并放手。

简单示例

您使用 ce-brainstorm 中的需求文档调用 ce-plan。该技能检测来源，将其用作主要输入，并验证是否存在剩余的计划前解决阻止程序。

它并行调度研究——回购分析师、学习研究员——并在没有外部比较请求的情况下检测强大的本地模式，因此它跳过外部研究（明确的“研究竞争对手”或“来自网络的最佳实践”请求将覆盖它并运行景观或实施指南扫描）。规范流分析器运行到表面边缘情况。源自头脑风暴的范围界定合成呈现出分层的摘要（散文、项目符号或混合，取决于计划深度和最佳沟通内容）加上零个或多个“调用”——另一个合理的代理可能会选择不同的计划时间分叉（例如，“静音状态存储在订阅上，而不是用户上”）。确认或重定向；自动继续跳过仅针对没有值得标记的分叉的轻量级计划触发 - 标准和深度计划始终获得显式检查点。

计划写好了。然后，置信度检查会自动运行 - 它确定 Risks & Dependencies 在静音泄漏风险方面很薄弱，并且一个单元的测试场景错过了许可边缘情况，派遣数据完整性审核员和正确性审核员，并将他们的发现综合回计划中。该计划标有 deepened: 日期。

然后文档审查以无头模式运行。由于该计划已设定原点并且不涉及高风险领域，因此成本低廉的最低调度（连贯性+可行性）； safe_auto 修复（一个拼写错误，一个损坏的交叉引用）静默应用。剩余的结果显示为生成后菜单上方的一行摘要 - 例如，Doc review applied 2 fixes. 3 decisions, 1 FYI remain. 菜单显示：启动 /ce-work，运行更深入的文档审查（当剩余可操作的结果时），创建跟踪的问题，在 Proof 中打开以进行 HITL 审查，或暂停。

何时去实现它

在以下情况下使用 ce-plan：

• 您已准备好来自 ce-brainstorm 的要求文档
• 您有足够清晰的 GitHub 问题、PRD 或功能描述
• 这项工作是多步骤的，并受益于排序、依赖顺序和范围边界
• 您希望在执行之前枚举测试或验证场景
• 您正在选择一个陈旧的计划并希望将其深化（使用“深化计划”或“深化通行证”）
• 任务是非软件但多步骤 - 学习计划、活动、旅行、日常维护、研究工作流程、个人项目

在以下情况下跳过 ce-plan：

• 该任务确实是一步完成的（只需执行即可；或 ce-work 直接执行）
• 产品或结果尚未决定 → 首先ce-brainstorm
• 该错误有已知的根本原因和明显的修复方案 → ce-debug 或只是修复它

用作链式工作流程的一部分

/ce-ideate          (optional)
   |
   v
/ce-brainstorm      (define one direction)
   |  requirements / brief — R/A/F/AE-IDs in software mode
   v
/ce-plan
   |  guardrails — U-IDs traced to R/A/F/AE-IDs
   |  test scenarios with AE-link convention (Covers AE<N>)
   |  scope boundaries preserved (incl. "Outside this product's identity")
   |  confidence-checked and auto-deepened
   v
/ce-work            (execute against the guardrails)
   |  reads U-IDs as the unit of execution
   |  figures out the actual HOW with code in front of it
   |  derives progress from git, not plan body
   v
/ce-code-review     (optional)
   |
   v
/ce-compound        — capture the learning

从 ce-plan 到 ce-work 的切换是具体的：ce-work 读取 U-ID、文件路径、范围边界和测试场景 — 然后确定实际实现。该计划告诉实施者当单元完成时必须是真实的；实施者弄清楚如何实现它。这种划分使得计划可以跨实施者和跨时间移植。

使用独立版

许多人在已经有要做的事情时直接寻求 ce-plan —— 对于软件，同样经常对于非软件多步骤任务。

软件：

• 来自 GitHub 问题 — /ce-plan https://github.com/.../issues/1234 （或粘贴问题正文）
• 来自 PRD — 带有 PRD 路径的 /ce-plan ；规划引导程序将其读取为原点
• 从一个粗略的想法 - /ce-plan "add background email digest at 8am UTC" 运行引导程序；综合可以让您在研究派遣之前纠正范围
• 重新深化现有计划 — /ce-plan deepen the auth-rewrite plan — 交互模式，代理一一呈现调查结果以供接受/拒绝
• 跨存储库规划 — 来自不同存储库的 /ce-plan "fix the busyblock bug in cli-printing-press"；跨回购目标公布，计划落地目标的 docs/plans/

非软件（通用规划模式）：

• 维护任务 — 年度热水箱维护，并在每个单元进行验证
• 学习计划 — 具有先决条件和每单元知识检查的分阶段单元
• 旅行计划 — 预订、打包、每日行程、应急范围
• 研究工作流程 — 文献收集、综合、起草阶段以及明确的可交付成果
• 活动策划 — 场地、供应商、议程、演出当天、后续活动
• 个人项目 — 车间扩建、家居装修

在通用规划模式下，U-ID、依赖顺序、范围边界和正确大小的模板都会保留。跳过软件特定的置信度检查；其他一切都以同样的方式运行。

＃＃ 参考

＃＃ 常问问题

计划不是告诉你如何构建东西吗？ 不在 ce-plan 的框架中。该计划告诉您必须遵守哪些内容——决策、范围、单位、文件、测试、风险。它故意不预先编写代码、精确的 API 签名或逐步的 shell 编排。实施代理通过他们面前的代码找出如何做。这种分离使计划保持可移植性，防止脆弱的预先承诺，并尊重实施者在执行时做出的判断。它还可以让同一个引擎以相同的结构严谨性来计划软件重构、热水箱维护和为期 6 周的学习计划。

为什么使用 U-ID 而不仅仅是编号单元？ 当单元被重新排序、拆分或删除时，编号会中断 - 问题、PR 和下游对话中的每个引用都会出错。 U-ID 是稳定的：重新排序将它们保留在适当的位置，拆分保留原始概念上的原始内容，删除留下间隙。因此，ce-work 的阻止程序引用可以跨计划编辑工作。

为什么置信度检查会自动运行？ 发现薄弱部分的成本高昂的时刻是在执行期间，而不是在规划期间。自动深化会在研究环境仍然活跃的情况下派遣有针对性的研究——比几周后实施时发现被遗漏的风险时重新研究要便宜得多。

如果我想保留现有计划并只是进行审核怎么办？ 使用加深意图快速路径：/ce-plan deepen <plan>。它以交互模式运行——代理一一呈现结果以供接受/拒绝。用户可以对整合哪些更改进行精确控制。

计划中的实现代码呢？ 默认情况下不允许。当伪代码和 DSL 语法传达解决方案的形状时，它们在高级技术设计中是允许的，明确地构建为方向指导，而不是实现规范。精确的方法签名、导入、特定于框架的语法和分步 shell 序列不属于计划。

它对于非软件计划真的有用吗？ 是的——而且这种情况越来越普遍。通用规划保留了 U-ID 概念、依赖顺序、正确大小的模板和护栏而非编排框架。实际用途包括热水箱维护、学习计划、旅行计划、研究工作流程和活动计划。

另请参阅

• ce-brainstorm — 生成成为计划起源的需求文档
• ce-ideate — 上游“要做什么”构想
• ce-work — 通过 U-ID 执行计划 U-ID
• ce-doc-review — 基于角色的计划审查
• ce-debug — bug 形状的提示在此处路由
• ce-strategy — 将计划锚定到记录的产品策略