PAUL 是一个面向 Claude Code 的 AI 辅助开发框架，通过 Plan-Apply-Unify 循环为 AI 编程建立结构化流程。它的 APPLY（执行）阶段是整个质量保障体系的核心：每个任务都会经过Execute/Qualify（执行/验收）循环独立校验，并用4 种升级状态（DONE、DONE_WITH_CONCERNS、NEEDS_CONTEXT、BLOCKED）诚实暴露问题，让 AI 无法"假装完成"任务。本文将带你完整理解这套机制如何守住执行质量。

APPLY 在 PAUL 循环中的位置

PAUL 的核心是三步闭环，每个工作单元都必须走完整轮：

PLAN ──▶ APPLY ──▶ UNIFY 定义工作 执行任务 核对收口

APPLY 的入口条件很严格：计划必须已获用户明确批准，且 STATE.md 显示 PLAN 已完成。PAUL 从不"假设批准"——因为计划中可能藏着批准审查本该发现的错误假设。完整阶段语义可参考 loop-phases.md。

Execute/Qualify 循环：每个任务的"自检关卡"

这是 APPLY 阶段最核心的机制。每个自动任务（auto task）都走一遍E/Q 循环：

EXECUTE → REPORT STATUS → QUALIFY →（发现缺口则修复重验）→ 下一任务

第 1 步：Execute（执行）

AI 按任务定义中的<action>创建/修改文件，全程遵守计划中声明的<boundaries>（禁改边界）。边界违规会立即停止并报告，而不是"就这一次"地绕过——因为边界违规会引发难以追溯的连锁变更。

第 2 步：Report Status（如实报告）

执行后、校验前，AI 必须如实报告 4 种状态之一（详见下一节）。规则很明确：绝不悄悄产出自己都不确定的工作。

第 3 步：Qualify（独立验收）

这是防"假完成"的关键一步。PAUL 的设计哲学是：AI 对自己刚写的代码的报告天然偏乐观，要相信输出，而不是相信它"写过"的记忆。

Qualify 包含四个动作：

1. 重读真实产出——重新打开刚创建/修改的文件，而不是凭记忆；
2. 重新运行 verify 命令——过期的验证不算验证；
3. 逐行对照任务规格和关联的验收标准（AC 的 Given/When/Then）；
4. 打分，结果只有三种：

遇到 GAP 或 DRIFT 时进入"修复-重验"循环，最多 3 次。3 次仍未通过就升级给用户，提供三个选项：给出指导 / 跳过任务（记录偏差）/ 停止执行。这套完整流程定义在 apply-phase.md 中。

🔍 值得一提的是，Qualify 还附带一张"反合理化自查表"：当你想"应该能跑了""我检查过了""差不多就行"时，必须停下来跑验证、重读文件、逐字对照 AC——因为"信心不是证据"。这张表的原始出处见 quality-principles.md。

4 种升级状态：超越"通过/失败"的诚实度

传统做法只有 pass/fail 二分法，容易掩盖不确定性。PAUL 要求任务报告以下 4 种状态之一：

三种"非 DONE"状态各有讲究：

• ✅DONE_WITH_CONCERNS：假装自信会在验证或生产环境付出代价，不如一开始就标记疑点；
• ⏸️NEEDS_CONTEXT 不算失败——它是诚实沟通，避免在错误假设上做无用功；补充信息后任务从头重执行，而不是靠猜测填空；
• 🚫BLOCKED 必须说清细节（尝试了什么、卡在什么、需要什么帮助），而不是一句含糊的"我卡住了"。

这些状态最终都会随执行日志交给 UNIFY 阶段记录，形成可审计的决策链。

人工卡点与诊断式失败路由

除了自动任务，计划中还可以插入checkpoint（卡点）任务强制暂停等待人工输入。PAUL 将其分为三类（定义见 checkpoints.md）：

🎯诊断式失败路由（Diagnostic Failure Routing）是卡点机制的另一大亮点。当人工验证报告问题时，PAUL不会直接动手改代码，而是先分类根因：

这防止了最常见的失败模式：计划本身错了，却在代码层打补丁——这种修复既脆弱又会让 UNIFY 的核对失去意义。

如何快速上手 /paul:apply

PAUL 通过 npm 一键安装（Mac/Windows/Linux 均支持）：

npx paul-framework

安装后在 Claude Code 中的典型流程：

/paul:init # 1. 初始化项目（生成 PROJECT.md） /paul:plan # 2. 创建计划（自动判定 quick-fix/standard/complex） /paul:apply # 3. 执行已批准的计划 —— 本文主角 /paul:unify # 4. 收口闭环（必须执行）

所有 26 条命令可用/paul:help查看完整参考。APPLY 命令本身的定义见 apply.md。

⚠️切记：APPLY 完成后一定要运行/paul:unify。没有 UNIFY 就没有产出记录，也就没有可追溯性——这是"结构化开发"与"随手写"的分水岭。

总结：APPLY 如何层层守住质量

PAUL 的哲学浓缩为一句话：Quality over speed-for-speed's-sake（质量优先于单纯的速度）。它把复杂度藏进系统，让你只面对几条保持正轨的命令。

📂延伸阅读路径：

• 完整 APPLY 工作流：apply-phase.md
• 循环阶段语义：loop-phases.md
• 卡点与失败路由参考：checkpoints.md
• 核心质量原则：quality-principles.md
• 命令入口：apply.md