执行、调试与评审

约 2189 字大约 7 分钟

2026-05-30

执行、调试和评审不是同一个动作。它们分别处理三类风险：计划能否落地、问题根因是否找准、变更风险是否被覆盖。

在 Compound Engineering 中，ce-work、ce-debug、ce-code-review、ce-simplify-code、ce-optimize 都位于执行与质量阶段附近；ce-polish-beta 属于 README 中的 Beta / Experimental 能力，更适合作为前端体验打磨的补充。它们不应该混成一个“让 Agent 改完代码”的动作。

核心结论

计划进入执行后，最容易出错的地方不是“Agent 不会写代码”，而是职责混淆：

把执行当调试：没有复现和根因，就直接试修。
把调试当评审：修好了当前症状，却没有检查其他风险。
把评审当执行：发现问题很多，但没有回到计划或实现闭环。
把优化当补救：没有指标和基线，就把主观调整叫优化。

Compound Engineering 的执行与质量链路要把这些动作拆开：先按计划交付，再用调试解决根因，用评审覆盖风险，用简化、优化和 UI polishing 收敛质量。

执行链路总览

ce-work当前重点

读取 plan 或任务描述，按范围执行并保持验证节奏。

执行

ce-debug风险

从症状、复现、假设和证据走到根因与修复。

根因

ce-code-review风险

用多 persona review correctness、testing、security、maintainability 等风险。

评审

ce-simplify-code已完成

在不改变行为的前提下减少复杂度和重复。

简化

ce-optimize已完成

围绕可测指标迭代实验，而不是凭感觉调参。

指标

ce-polish-beta已完成

Beta 能力，面向前端体验，用浏览器反馈推动可感知质量改进。

体验

关系说明

验证ce-workce-debug失败时先找根因
下一步ce-workce-code-review完成后接受评审
依赖ce-code-reviewce-simplify-code风险可控后简化
回流ce-debugce-work修复回到执行验证

这条链路不是线性瀑布。调试可能把工作拉回计划，评审可能要求补测试，优化可能暴露需求指标不清。关键是让每个动作有明确职责，而不是用一个“大执行”动作吞掉所有判断。

`ce-work`：按计划执行，不重新发明计划

ce-work 的重点是把 plan、spec 或明确任务描述转成实际变更。它应该优先继承已有计划里的 scope boundaries、implementation units、files、test scenarios 和 verification，而不是在执行时重新定义产品行为。

如果输入只是一个裸需求，ce-work 可以先做轻量扫描并按复杂度判断是否直接改、列任务，或建议回到 brainstorm / plan。但对跨模块、行为变化、安全、权限、数据、迁移等任务，直接执行通常风险过高。

输入状态	合适动作
有明确 plan 或 OpenSpec artifacts	按事实源执行，遇到冲突回到对应 artifact。
小范围、低风险、行为清楚	可以直接实现并运行最小验证。
范围大、决策多、影响面广	先补 brainstorm、plan 或 OpenSpec change。
实现中发现计划不成立	暂停并修正计划，不把新范围偷偷塞进 diff。

执行阶段的质量不只看“有没有改完”，还要看有没有保持范围、验证和可追踪性。

`ce-debug`：先找根因，再谈修复

ce-debug 适合在出现错误、测试失败、线上症状、复现不稳定或多次修复失败时使用。它的核心纪律是：没有完整因果链之前，不急着修。

调试应当从症状开始，但不能停在症状：

阶段	关键问题	输出
症状	用户、测试或系统实际看到了什么？	明确问题陈述。
复现	能否稳定触发，环境条件是什么？	复现步骤或不可复现说明。
追踪	有效状态在哪里第一次变坏？	数据流、调用链、边界观察。
假设	哪个原因最可能解释所有现象？	带证据的根因假设。
验证	这个假设是否能预测其他现象？	被验证或被推翻的预测。
修复	如何消除根因，而不是遮住症状？	最小修复和回归验证。

调试和执行的分界很重要：ce-work 可以完成计划内实现；ce-debug 负责解释为什么某个行为失败。没有这个分界，Agent 很容易进入“试一个补丁看看”的循环。

`ce-code-review`：用多视角覆盖风险

ce-code-review 的价值不是给代码打分，而是把注意力拆给不同 reviewer personas。一个 reviewer 很容易只盯 correctness，另一个可能只看测试；多视角 review 的目的就是降低这种盲区。

在代码评审阶段，至少应区分这些风险：

风险维度	典型问题
Correctness	边界条件、状态转换、错误传播、行为回归。
Testing	关键路径没测、断言太弱、测试只覆盖实现细节。
Security	权限、输入、公开接口、敏感数据和越权风险。
Maintainability	复杂度、耦合、重复、死代码、抽象边界。
Performance / Reliability	N+1、缓存、重试、超时、后台任务和稳定性。
Project standards	是否符合项目规则、命名、路径、文档和 portability 约定。

评审发现不等于自动修改。低风险、确定性的修复可以直接处理；涉及行为、权限、数据、发布和产品取舍的发现，应回到计划、spec 或人工判断。

简化、优化和 polishing 的位置

ce-simplify-code 和 ce-optimize 通常在执行后段使用；ce-polish-beta 也常放在这个阶段，但需要按 Beta / Experimental 能力对待。它们关注的质量不同。

能力	适合什么时候用	不适合替代什么
`ce-simplify-code`	行为已经成立，但代码显得重复、绕、难读或偏离项目模式。	不替代需求澄清，也不为了少几行改变行为。
`ce-optimize`	有明确指标、基线和可测目标，例如性能、搜索质量、构建时间、提示效果。	不替代主观判断；没有指标时不应伪装成优化。
`ce-polish-beta`	前端功能能跑，但需要真实浏览器里的体验检查和迭代；使用时按 Beta 能力处理。	不替代产品验收、设计规范或可访问性判断。

这些动作最好发生在基础行为已经可信之后。否则，简化可能把错误行为整理得更漂亮，优化可能把错误指标推得更高，polish 可能掩盖核心流程没有成立。

什么时候回到计划或 OpenSpec

执行中发现新事实很正常，关键是不要把它们偷偷埋进实现。

发现的问题	应该回到哪里
目标用户、成功标准或非目标不清	回到 brainstorm 或 requirements。
实现路径和原 plan 不一致	更新 plan 或设计说明。
行为变化超出原范围	更新 OpenSpec proposal / specs。
验证方式不足以证明完成	更新 tasks 或 verification。
bug 暴露了设计假设错误	回到 plan 或重新做方案判断。
评审发现权限、数据或发布风险	暂停合并，补设计、测试和人工确认。

这不是流程倒退，而是把执行中学到的新事实写回事实源。Compound Engineering 的复利恰恰来自这里：一次执行不只产生代码，也让后续计划、评审和知识沉淀更可靠。

参考资料

EveryInc/compound-engineering-plugin README

执行、调试与评审

核心结论

执行链路总览

从计划到可交付结果

按计划执行

调查根因

覆盖风险

收敛质量