PAUL的APPLY阶段完全指南：Execute/Qualify循环与4种升级状态如何守住执行质量

【免费下载链接】paulPlan-Apply-Unify Loop — Structured AI-assisted development for Claude Code. Quality over speed-for-speeds-sake.项目地址https://gitcode.com/gh_mirrors/paul3/paul点击查看免费下载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 定义工作 执行任务 核对收口阶段职责PLAN定义目标、验收标准AC、任务与边界等待用户批准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 包含四个动作重读真实产出——重新打开刚创建/修改的文件而不是凭记忆重新运行 verify 命令——过期的验证不算验证逐行对照任务规格和关联的验收标准AC 的 Given/When/Then打分结果只有三种评分含义后续动作PASS产出与规格、AC 一致进入下一任务GAP规格或 AC 中的某项缺失修复后重新 QualifyDRIFT产出与规格不一致做岔了修复后重新 Qualify遇到 GAP 或 DRIFT 时进入修复-重验循环最多 3 次。3 次仍未通过就升级给用户提供三个选项给出指导 / 跳过任务记录偏差/ 停止执行。这套完整流程定义在 apply-phase.md 中。 值得一提的是Qualify 还附带一张反合理化自查表当你想应该能跑了我检查过了差不多就行时必须停下来跑验证、重读文件、逐字对照 AC——因为信心不是证据。这张表的原始出处见 quality-principles.md。4 种升级状态超越通过/失败的诚实度传统做法只有 pass/fail 二分法容易掩盖不确定性。PAUL 要求任务报告以下 4 种状态之一状态含义后续处理DONE完成且无顾虑走标准 Qualify 校验DONE_WITH_CONCERNS完成了但对正确性/方案/完整性存疑Qualify 优先聚焦被标记的疑点再全量检查NEEDS_CONTEXT无法完成——缺少计划中没有的信息暂停明确说出缺什么等待用户补充BLOCKED无法完成——结构性障碍权限、依赖、环境损坏停止报告已尝试什么、卡在哪、需要什么帮助三种非 DONE状态各有讲究✅DONE_WITH_CONCERNS假装自信会在验证或生产环境付出代价不如一开始就标记疑点⏸️NEEDS_CONTEXT 不算失败——它是诚实沟通避免在错误假设上做无用功补充信息后任务从头重执行而不是靠猜测填空BLOCKED 必须说清细节尝试了什么、卡在什么、需要什么帮助而不是一句含糊的我卡住了。这些状态最终都会随执行日志交给 UNIFY 阶段记录形成可审计的决策链。人工卡点与诊断式失败路由除了自动任务计划中还可以插入checkpoint卡点任务强制暂停等待人工输入。PAUL 将其分为三类定义见 checkpoints.md卡点类型占比用途checkpoint:human-verify~90%AI 已自动完成人工确认视觉效果/交互体验checkpoint:decision~9%人工做技术选型、架构决策checkpoint:human-action~1%确实无 API/CLI 可用的人工步骤如短信验证码诊断式失败路由Diagnostic Failure Routing是卡点机制的另一大亮点。当人工验证报告问题时PAUL不会直接动手改代码而是先分类根因分类信号处理路径Intent意图问题我要做的和计划的不一样归档当前计划重新规划该阶段Spec规格问题计划漏了东西或写错了先修正 AC/任务再改代码Code代码问题计划没错是实现不对标准原地修复 重新验证这防止了最常见的失败模式计划本身错了却在代码层打补丁——这种修复既脆弱又会让 UNIFY 的核对失去意义。如何快速上手 /paul:applyPAUL 通过 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 如何层层守住质量机制拦截的失败模式明确批准检查在错误假设上盲目执行边界Boundaries保护越界修改污染审计链Execute/Qualify 循环假完成、产出漂移4 种升级状态不确定性被悄悄吞掉反合理化自查表应该没问题的口头自信诊断式失败路由在错误的层次上打补丁PAUL 的哲学浓缩为一句话Quality over speed-for-speeds-sake质量优先于单纯的速度。它把复杂度藏进系统让你只面对几条保持正轨的命令。延伸阅读路径完整 APPLY 工作流apply-phase.md循环阶段语义loop-phases.md卡点与失败路由参考checkpoints.md核心质量原则quality-principles.md命令入口apply.md赞分享【免费下载链接】paulPlan-Apply-Unify Loop — Structured AI-assisted development for Claude Code. Quality over speed-for-speeds-sake.项目地址https://gitcode.com/gh_mirrors/paul3/paul点击查看免费下载相关推荐ECC 验证循环在 Kiro 会话中用六阶段 Verification Loop 守护 PR 质量的完整实战指南ECC 验证循环在 Kiro 会话中用六阶段 Verification Loop 守护 PR 质量的完整实战指南 ECCEverything Claude人工智能AI 技能AI 插件AI 评测Agent 评测MCP Clients开发工具Higress AI 辅助贡献的 issue-spec Apply 阶段协议执行模式、角色分工与精确提交审阅循环Higress AI 辅助贡献的 issue spec Apply 阶段协议执行模式、角色分工与精确提交审阅循环 本文面向在 Higress 仓库 issuAPI网关后端云原生LLM 网关人工智能MCP 服务Mavericks 中的 Asynclt;Tgt; 状态封装与 execute 异步执行指南Mavericks 中的 Asynclt;Tgt; 状态封装与 execute 异步执行指南 MavericksAndroid on Autopilot移动开发原生移动创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考