ce-doc-review

使用呈现特定于角色的问题的并行角色代理来审查需求或计划文档。

ce-doc-review 是 文档审查 技能 - 与链的文档端的 /ce-code-review 是同级的。它分析需求文档或实施计划，根据文档包含的内容（产品框架、设计表面、安全隐患、范围蔓延）选择审阅者角色，并行分派它们，然后自动应用安全修复，并通过结构化的四选项交互路由其余部分（每个发现的走查、自动解决最佳判断、附加到开放问题、仅报告）。

复合工程构思链是/ce-ideate → /ce-brainstorm → /ce-plan → /ce-work。 ce-doc-review 是针对 ce-brainstorm 和 ce-plan** 生成的工件的**审阅技能 - 在其各自的第 4 阶段/第 5.3.8 阶段交接时调用，并且当您想要对磁盘上的文档进行结构化审阅时也可以直接调用。

TL;DR

＃＃ 问题

在某些方面，文档审查比代码审查更困难：

• 没有类型检查器 - 当需求文档存在内部矛盾时，不会出现编译器错误
• 没有执行 - 您无法“运行”计划来查看其范围是否符合其目标
• 通才审查失败 - “看起来不错”忽略了设计差距、安全含义、未说明的范围扩展
• 交错的关注点 - 产品框架、安全性、设计、范围和可行性都需要不同的视角，但单个审阅者会优先考虑其中一个
• 调查结果缺乏所有权 - “考虑修改”，但没有说明谁决定或做什么
• 被拒绝的调查结果重新浮出水面——同样的问题被一轮又一轮地标记，因为拒绝没有被记录

解决方案

ce-doc-review 将文档审查作为具有显式门的结构化管道来运行：

• 始终在线的角色以实现连贯性和可行性
• 根据文档内容选择条件角色 - 产品镜头、设计镜头、安全镜头、范围守护者、对抗性
• 并行角色调度，具有有限并发性
• 综合管道，具有跨角色协议提升、矛盾解决和三层路由（safe_auto、gated_auto、manual + FYI）
• 决策底漆 — 逐轮抑制，因此被拒绝的发现不会重新出现，并且应用的发现得到验证
• 四选项交互 - 每个发现的演练，根据最佳判断自动解决，附加到开放问题，仅报告

是什么让它如此新颖

1. 文档内容感知角色选择

条件角色根据文档实际所说的内容激活，而不是关键字匹配：

• ce-product-lens-reviewer — 当文档对构建内容和原因做出有争议的主张时，或者当提议的工作具有战略重要性时（轨迹、身份、采用、机会成本）
• ce-design-lens-reviewer — 当文档包含 UI/UX 参考、用户流程、交互描述或视觉设计语言时
• ce-security-lens-reviewer — 当文档涉及身份验证、公共 API、数据处理、PII、支付、第三方信任边界时
• ce-scope-guardian-reviewer — 当文档具有多个优先级、大量需求计数或似乎不一致的范围边界语言时
• ce-adversarial-document-reviewer — 当文档涉及高风险领域（身份验证、支付、迁移）、提出新的抽象、缺少或扩展起源、包含需求形状前提内容或提出明确的替代方案时

2 个始终开启的（ce-coherence-reviewer、ce-feasibility-reviewer）在每次审核时运行。有条件的人物角色增加了文档内容所保证的深度。

人物角色还通过文档形状来确定其技术范围。在设置了 Origin: 的计划文档中，意味着前提已经在头脑风暴中进行了压力测试 — ce-product-lens-reviewer、ce-adversarial-document-reviewer 和 ce-scope-guardian-reviewer 抑制其前提级技术并仅运行实现级检查（技术假设、决策压力测试、架构替代方案、延迟工作范围蠕变）。在需求形状文档上，他们运行完整的技术集。 ce-feasibility-reviewer 反转：影子路径跟踪、可实现性和迁移机制的范围仅限于平面文档；在需求文档上，它严格要求“这个方向会迫使我们进行根本性的返工吗？”查看。文档类型分类在协调器中发生一次（内容形状信号 - frontmatter、R-ID 与 U-ID、部分结构），结果通过 Origin: 槽传递给每个角色，因此角色不会重新分类自己。

2.具有三层路由的综合管道

所有角色回归后，合成：

• 根据模式验证每个发现
• 应用基于锚点的门（丢弃不锚定到实际文档内容的发现）
• 跨角色重复数据删除
• 促进跨角色一致性的发现 - 两位审稿人发现同一问题提高了优先级
• 解决矛盾（不同的角色不同意做什么）
• 自动提升符合标准的安全汽车候选者
• 将调查结果分为三层 — safe_auto（直接应用）、gated_auto / manual（用户决定）和 FYI（仅供参考）

输出是一个综合集合，而不是每个角色的原始输出的平面列表。

3. 决策入门——逐轮抑制

当用户在同一会话中运行多轮时（应用一些结果，保留其余部分，再次运行），决策引物会继承已应用的内容与拒绝的内容：

• 应用的发现回流，以便第 N+1 轮角色可以验证修复是否实际落地
• 拒绝的发现（跳过/推迟/确认）通过指纹+证据子串重叠匹配进行抑制，因此相同的问题不会再次出现

该引物使用证据片段（每个发现的证据的前约 ​​120 个字符）进行重叠测试，而不仅仅是标题指纹识别。如果没有该片段，压制就会退回到仅标题，并且要么重新出现被拒绝的发现，要么压制过于激进。

4.四选项交互模型

当发现结果落在 gated_auto / manual 层时，用户选择如何处理它们：

如果用户已经审阅了足够的内容以信任其余部分，则演练本身支持“自动解决其余部分”转义中流。

5. 批量更改前的批量操作预览

当用户选择“以最佳判断自动解决”或“附加到未解决的问题”时，或者在演练中退出到“自动解决其余问题”时，该技能会在应用之前显示每个更改的预览。预览包括部分、查找标题、操作（应用/跳过/推迟/确认）和简要理由。用户确认或取消。这是批量操作的安全阀：用户可以在物体落地之前看到它。

6. 两种模式——交互式和无头模式

无头是来自文档生成技能的链式调用的默认设置 - /ce-plan 阶段 5.3.8 调用无头，因此例程计划自动修复并显示摘要行，而不会阻止用户。交互式用于直接调用，或者当用户从生成后菜单中选择进入 Run deeper doc review 时。

7. 带有背压的有限并行性

Persona 调度遵循线束的活动子代理限制。选定的审稿人队列；该技能会根据安全带接受的数量进行调度，并在审阅者完成时填充空闲的插槽。活动代理/并发限制生成错误被视为背压（插槽释放后重试），而不是审阅者失败。仅当成功调度超时或因非容量原因失败时，审阅者才会被记录为失败。

8. 覆盖范围透明度

输出命名哪些角色运行、由哪些信号激活以及是否有任何失败或超时。用户可以审核“正确的审阅者是否真正查看了此内容”，而无需解析内部状态。

简单示例

/ce-plan 完成了通知静音功能的标准计划的生成。阶段 5.3.8 使用计划路径调用 mode:headless 中的 /ce-doc-review。

该技能读取文档，根据内容形状信号（U-ID、计划部分结构）将其分类为 plan，读取 Origin: 槽，并分析条件角色的内容。该计划涉及 UI 表面（静音切换副本），但没有高风险领域，也没有提出新的抽象。它激活 ce-coherence-reviewer （始终开启）、 ce-feasibility-reviewer （始终开启，范围为平面形状技术）和 ce-design-lens-reviewer （UI 表面）。对抗性、范围守护者、安全镜头和产品镜头跳过——它们都不会触发已设定原点的例行计划。

三位审稿人并行派遣。他们返回 9 项原始调查结果。综合将它们合并为 6 个不同的发现：2 safe_auto（拼写错误，交叉引用损坏），3 gated_auto（关于耐用性权衡的措辞，U2 测试场景中缺少边缘情况，切换副本上的设计镜头标志），1 FYI（建议范围澄清）。

2 safe_auto 直接应用。无头模式将其余内容作为结构化文本返回 - 没有演练，没有每次查找的路由。生成后菜单上方显示一条摘要行： Doc review applied 2 fixes. 3 decisions, 1 FYI remain. 用户选择 Start /ce-work 并继续。如果他们想以交互方式解决这 3 个决定，他们会选择 Run deeper doc review 。

何时去实现它

在以下情况下使用 ce-doc-review：

• 刚刚从 /ce-brainstorm 收到需求文档，您希望在规划之前进行结构化审查
• /ce-plan 刚刚发出一项计划，您希望在执行前进行更深入的审查
• 您处于无头模式，并且程序调用者（链技能）需要使用结构化输出进行审查
• 您想要对文档进行逐轮细化 - 决策引物可以防止循环

在以下情况下跳过 ce-doc-review：

• 文档非常短（只有 2 个项目符号的计划；审核开销超过了产出）
• 您想要代码审查，而不是文档审查 → /ce-code-review
• 该文档纯粹是信息性的（学习文档、发行说明）——没有什么可以“审查交付”的内容

用作工作流程的一部分

ce-doc-review 从文档生成技能中调用作为其审核通过：

• /ce-brainstorm 第 4 阶段 — 作为博士后选项之一提供（“代理审查需求文档”）；与全面的前提审查进行交互运行，因为验证前提正是头脑风暴的目的
• /ce-plan 阶段 5.3.8 — 置信度检查后默认在 mode:headless 中运行。 safe_auto 修复静默应用；剩余的结果显示为生成后菜单上方的一行摘要，其中 Run deeper doc review 作为想要交互式演练的用户的一流选项
• /ce-resolve-pr-feedback — 当审阅者反馈落在头脑风暴或计划文档而不是代码时

在无头模式下，呼叫者接收结构化结果并自行路由用户决策选项。

使用独立版

该技能直接适用于任何需求或计划文档：

• 具体路径 — /ce-doc-review docs/plans/2026-05-04-001-feat-notification-mute-plan.md
• 询问用户 — 没有路径的 /ce-doc-review 询问要查看哪个文档（或自动查找 docs/brainstorms/ 或 docs/plans/ 中的最新文档）
• 无头 — /ce-doc-review mode:headless docs/plans/.../plan.md 返回结构化结果，无需交互式提示

＃＃ 参考

无头模式需要路径；如果没有它，它就会出错而不是猜测。

＃＃ 常问问题

这和 ce-code-review 有什么区别？ ce-code-review 审查差异（代码更改）； ce-doc-review 审查文档（要求、计划）。不同的审稿人角色、不同的发现形式、不同的路由。两者共享多角色调度+合成模式，但针对各自的工件类型进行了调整。

为什么决策入门很重要？ 如果没有它，每一轮都会重新出现相同的发现，包括用户已经拒绝的结果。底漆使用指纹+证据片段匹配来抑制被拒绝的发现并验证应用的修复——使逐轮细化实际上是迭代的，而不是循环的。

“附加到未决问题”的用途是什么？ 对于用户希望稍后而不是现在解决的发现。它们不会在聊天中丢失，而是被附加到文档的 ## Open Questions 部分，这样它们就可以在会话中幸存下来，并且下一个计划者/实施者可以看到它们。

为什么它有批量预览？ 因为大规模的变化需要一个确认步骤。 “以最佳判断自动解决”感觉就像委托，但如果该技能默默地应用 12 个更改，而您在没有预览的情况下无法查看，那就存在风险。预览显示提交前的更改，以便用户可以取消。

如果角色超时或失败怎么办？ 该技能根据已完成的代理的调查结果继续进行，并在“覆盖范围”部分中记录失败。单个代理的失败不会阻止整个审核。

它可以审查除要求和计划之外的文件吗？ 人物角色专门针对这两种类型进行了调整。审查学习文档或发行说明是机械的，但角色建议可能无法针对该工件类型进行校准。对于广泛的文档审查，这是正确的工具；对于特定的其他类型，角色可能会出现噪音。

另请参阅

• ce-brainstorm — 生成此技能审核的要求文档
• ce-plan — 生成此技能审查的计划文档；在阶段 5.3.8 调用该技能
• ce-code-review — 代码同级技能（差异）；相同的多重角色模式，不同的神器
• ce-proof — 通过 Every 协作编辑器的替代 HITL 审查路径；互补而非替代