Garden Skills的SubAgent质检协议如何让另一个AI检查你的AI【免费下载链接】garden-skillsConardLis open-source Skills collection, featuring web design, knowledge retrieval, image generation, and more.项目地址: https://gitcode.com/GitHub_Trending/we/garden-skillsGarden Skills 开源仓库中的beautiful-articleSkill 内置了一套硬性的 SubAgent 质检协议它让另一个 AISubAgent以独立身份检查主 AI 写出的每一篇文章 —— 谁该被检查、用什么方式检查、检查结果以什么形式返回全部有明文规则。本文带你完整拆解这套「让 AI 检查 AI」的协议设计以及普通用户能直接复用到自己工作流里的思路。SubAgent 质检协议是什么让 AI 检查 AI 的设计先说背景。用 AI 生成内容时最大的坑不是「写不出来」而是「写得不对却自己看不出来」——上下文越滚越长AI 越容易对自己的产出「熟视无睹」。Garden Skills 里的 beautiful-article把任意素材做成精美网页文章的 Skill的解法很直接主 Agent 负责生产SubAgent 负责质检两者身份隔离。就像写代码时让另一位同事做 Code Review而不是自己检查自己的作业。整套协议在 SKILL.md 中被明确称为「硬性质检协议」并贯穿文章的 8 个 Phase。它的核心主张一句话概括不是所有质检都要开 SubAgent也不是所有质检都要写文件。5 个质检节点该开 SubAgent 的节点一览表这是协议最精华的部分完整规则见 SKILL.md 与 review-checklist.md节点质检方式产物为什么这么定Phase 1 Source默认主 Agent 内联 5 条 checklist无文件主 Agent 反正要通读源文件Phase 1 Source仅复杂/低置信源Source Reviewer SubAgent对照原件 diffreview/source-review.md静默丢失只能靠 diff 抓到Phase 2 Plan / Checkpoint 1 前主 Agent 内联自查禁止开 SubAgent无文件上下文是热的SubAgent 冷启动反而更慢Phase 4 First Spread / Checkpoint 2 前First Spread Reviewer SubAgentreview/first-spread-review.md首屏定调多一双独立眼睛更稳Phase 5 每个 SectionSection Reviewer SubAgent消息返回 pass/fail不写文件一篇 5-15 节N 份 review 文件没人再读Phase 6 终审 / Checkpoint 3 前Editorial Visual Technical 三视角 SubAgentreview/final-review.md终审结论是交付物的一部分留档有价值 注意这张表的反直觉之处Plan 阶段明明是最容易出错的阶段却明令禁止开 SubAgent反而是每个小节的检查结果不落盘、只用消息返回。规则背后全是权衡下文细说。4 种 Reviewer 质检员各查什么、返回什么协议为每类质检都定义了专用「质检员」角色和 prompt 模板模板见 review-checklist.md1. Source Reviewer —— 只在复杂源时升级出动默认情况下源文件自查就够了。只有当抽取标记为「低置信 / 复杂源」时才升级为独立 SubAgent并强制对照原件original.*做 diff 式核查结论写入review/source-review.md。因为「悄悄丢了一段内容」这类问题只有 diff 能抓出来。2. First Spread Reviewer —— 首屏验收结论留档首屏 第一节是文章的「定调」时刻。SubAgent 检查首屏像文章不像 landing page主题气质对不对封面图文并茂吗代码能构建、控制台无红字吗结论写入review/first-spread-review.md作为后续用户验收的依据。3. Section Reviewer —— 逐节快检只回消息不写文件每写完一节就起一个 SubAgent 对照清单核查完成本节 outline 任务信息保留比例达标与前后节衔接序号自洽第 08 章下绝不能出现 5.1 它的返回极简第一行 pass / failfail 则列出带证据的修复点—— 通过一行 OK不通过列问题。主 Agent 收到 fail 项后直接修对应文件再汇报本节交付。4. 终审三视角 Reviewer —— 读者、主题、技术各查一遍交付前从三个视角并行验收结论合并进review/final-review.mdEditorial Reviewer它还是一篇文章而不是应用必须保留的信息没丢Visual Reviewer主题气质统一有没有明显 AI 味紫粉渐变、圆角彩卡、emoji 装饰移动端能读吗Technical Reviewer可构建、可打开、控制台无错章节序号全篇连续单调、与 TOC 一致这三类角色还各有一句硬约束「不要替我改文件也不要泛泛夸奖」—— 质检员只出诊断不下场施工。为什么不是每一步都开 SubAgent3 个关键权衡这套协议最值得学的地方是它把「误开 SubAgent / 误写文件」定义为首要性能问题并给出三条可迁移的权衡原则上下文是热的就不必开冷启动。Plan 是 200-400 行的文字决策主 Agent 刚写完、上下文最热此时开 SubAgent 反而要重新喂一遍背景更慢更贵。→ 内联自查即可。检查频率决定产物形态。每节都检、一篇检 5-15 次如果每次都落盘一份 review 文件最后堆出十几份没人看的文档。→ 高频检查只回消息低频关键节点首屏、终审才留档。拿到结论 ≠ 完成质检。铁律第 4 条先按 fail 项把产出改完再汇报「做完了 自检结论 改了什么」直接拿原始结论汇报但不修复 违规。配套地repair-policy.md 规定修复必须「最小切片」只反馈一处就重写整篇、为修视觉动已确认结构都是被明确禁止的。把这套 AI 质检协议搬到自己的工作流4 个可复用的规则即使你不用写文章这套「让另一个 AI 检查你的 AI」的设计也能直接借用✅给关键节点配独立检查者在「定调」和「交付」两个价值最高的节点用独立 SubAgent或独立会话做检查让检查结果有留档文件。✅高频检查走轻量返回重复性环节的检查约定「一行 pass/fail 修复点」的消息格式避免产物爆炸。✅先修复再汇报把「按 fail 项改完才允许汇报」写进你的流程规则杜绝 AI 把质检报告当交差工具。✅给质检员划清边界prompt 里明确「不要替我改文件、不要泛泛夸奖」让 Reviewer 只做诊断。另外harness.md 里「状态文件是长期记忆」的设计也值得一提所有质检结论落盘到review/目录长会话中不确定某个决策时回读文件而不是凭记忆这本身就是对抗 AI「遗忘」的手段。如何开始使用安装与延伸阅读beautiful-article是 Garden Skills 仓库中的 5 个 Skill 之一其他还包括 web-design-engineer、gpt-image-2、web-video-presentation、kb-retriever面向 Claude Code、Cursor、Codex 等支持SKILL.md格式的 AI 编程代理。快速上手克隆仓库git clone https://gitcode.com/GitHub_Trending/we/garden-skills或只安装单个 Skillnpx skills add ConardLi/garden-skills -s beautiful-article延伸阅读清单协议全文skills/beautiful-article/SKILL.md重点看「硬性质检协议」段各角色质检清单与 prompt 模板skills/beautiful-article/references/review-checklist.md最小切片修复规则skills/beautiful-article/references/repair-policy.md多 Agent 并行写作与序号校准skills/beautiful-article/references/section-build.md项目总览README.zh-CN.md一句话总结让 AI 检查 AI关键不是「检查得更多」而是给对的节点配上对的检查者—— 高价值节点用独立 SubAgent 留档高频环节用消息轻量返回热上下文里就地自查。这套规则写在开源协议里谁都可以抄走。【免费下载链接】garden-skillsConardLis open-source Skills collection, featuring web design, knowledge retrieval, image generation, and more.项目地址: https://gitcode.com/GitHub_Trending/we/garden-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Garden Skills的SubAgent质检协议：如何让另一个AI检查你的AI
Garden Skills的SubAgent质检协议如何让另一个AI检查你的AI【免费下载链接】garden-skillsConardLis open-source Skills collection, featuring web design, knowledge retrieval, image generation, and more.项目地址: https://gitcode.com/GitHub_Trending/we/garden-skillsGarden Skills 开源仓库中的beautiful-articleSkill 内置了一套硬性的 SubAgent 质检协议它让另一个 AISubAgent以独立身份检查主 AI 写出的每一篇文章 —— 谁该被检查、用什么方式检查、检查结果以什么形式返回全部有明文规则。本文带你完整拆解这套「让 AI 检查 AI」的协议设计以及普通用户能直接复用到自己工作流里的思路。SubAgent 质检协议是什么让 AI 检查 AI 的设计先说背景。用 AI 生成内容时最大的坑不是「写不出来」而是「写得不对却自己看不出来」——上下文越滚越长AI 越容易对自己的产出「熟视无睹」。Garden Skills 里的 beautiful-article把任意素材做成精美网页文章的 Skill的解法很直接主 Agent 负责生产SubAgent 负责质检两者身份隔离。就像写代码时让另一位同事做 Code Review而不是自己检查自己的作业。整套协议在 SKILL.md 中被明确称为「硬性质检协议」并贯穿文章的 8 个 Phase。它的核心主张一句话概括不是所有质检都要开 SubAgent也不是所有质检都要写文件。5 个质检节点该开 SubAgent 的节点一览表这是协议最精华的部分完整规则见 SKILL.md 与 review-checklist.md节点质检方式产物为什么这么定Phase 1 Source默认主 Agent 内联 5 条 checklist无文件主 Agent 反正要通读源文件Phase 1 Source仅复杂/低置信源Source Reviewer SubAgent对照原件 diffreview/source-review.md静默丢失只能靠 diff 抓到Phase 2 Plan / Checkpoint 1 前主 Agent 内联自查禁止开 SubAgent无文件上下文是热的SubAgent 冷启动反而更慢Phase 4 First Spread / Checkpoint 2 前First Spread Reviewer SubAgentreview/first-spread-review.md首屏定调多一双独立眼睛更稳Phase 5 每个 SectionSection Reviewer SubAgent消息返回 pass/fail不写文件一篇 5-15 节N 份 review 文件没人再读Phase 6 终审 / Checkpoint 3 前Editorial Visual Technical 三视角 SubAgentreview/final-review.md终审结论是交付物的一部分留档有价值 注意这张表的反直觉之处Plan 阶段明明是最容易出错的阶段却明令禁止开 SubAgent反而是每个小节的检查结果不落盘、只用消息返回。规则背后全是权衡下文细说。4 种 Reviewer 质检员各查什么、返回什么协议为每类质检都定义了专用「质检员」角色和 prompt 模板模板见 review-checklist.md1. Source Reviewer —— 只在复杂源时升级出动默认情况下源文件自查就够了。只有当抽取标记为「低置信 / 复杂源」时才升级为独立 SubAgent并强制对照原件original.*做 diff 式核查结论写入review/source-review.md。因为「悄悄丢了一段内容」这类问题只有 diff 能抓出来。2. First Spread Reviewer —— 首屏验收结论留档首屏 第一节是文章的「定调」时刻。SubAgent 检查首屏像文章不像 landing page主题气质对不对封面图文并茂吗代码能构建、控制台无红字吗结论写入review/first-spread-review.md作为后续用户验收的依据。3. Section Reviewer —— 逐节快检只回消息不写文件每写完一节就起一个 SubAgent 对照清单核查完成本节 outline 任务信息保留比例达标与前后节衔接序号自洽第 08 章下绝不能出现 5.1 它的返回极简第一行 pass / failfail 则列出带证据的修复点—— 通过一行 OK不通过列问题。主 Agent 收到 fail 项后直接修对应文件再汇报本节交付。4. 终审三视角 Reviewer —— 读者、主题、技术各查一遍交付前从三个视角并行验收结论合并进review/final-review.mdEditorial Reviewer它还是一篇文章而不是应用必须保留的信息没丢Visual Reviewer主题气质统一有没有明显 AI 味紫粉渐变、圆角彩卡、emoji 装饰移动端能读吗Technical Reviewer可构建、可打开、控制台无错章节序号全篇连续单调、与 TOC 一致这三类角色还各有一句硬约束「不要替我改文件也不要泛泛夸奖」—— 质检员只出诊断不下场施工。为什么不是每一步都开 SubAgent3 个关键权衡这套协议最值得学的地方是它把「误开 SubAgent / 误写文件」定义为首要性能问题并给出三条可迁移的权衡原则上下文是热的就不必开冷启动。Plan 是 200-400 行的文字决策主 Agent 刚写完、上下文最热此时开 SubAgent 反而要重新喂一遍背景更慢更贵。→ 内联自查即可。检查频率决定产物形态。每节都检、一篇检 5-15 次如果每次都落盘一份 review 文件最后堆出十几份没人看的文档。→ 高频检查只回消息低频关键节点首屏、终审才留档。拿到结论 ≠ 完成质检。铁律第 4 条先按 fail 项把产出改完再汇报「做完了 自检结论 改了什么」直接拿原始结论汇报但不修复 违规。配套地repair-policy.md 规定修复必须「最小切片」只反馈一处就重写整篇、为修视觉动已确认结构都是被明确禁止的。把这套 AI 质检协议搬到自己的工作流4 个可复用的规则即使你不用写文章这套「让另一个 AI 检查你的 AI」的设计也能直接借用✅给关键节点配独立检查者在「定调」和「交付」两个价值最高的节点用独立 SubAgent或独立会话做检查让检查结果有留档文件。✅高频检查走轻量返回重复性环节的检查约定「一行 pass/fail 修复点」的消息格式避免产物爆炸。✅先修复再汇报把「按 fail 项改完才允许汇报」写进你的流程规则杜绝 AI 把质检报告当交差工具。✅给质检员划清边界prompt 里明确「不要替我改文件、不要泛泛夸奖」让 Reviewer 只做诊断。另外harness.md 里「状态文件是长期记忆」的设计也值得一提所有质检结论落盘到review/目录长会话中不确定某个决策时回读文件而不是凭记忆这本身就是对抗 AI「遗忘」的手段。如何开始使用安装与延伸阅读beautiful-article是 Garden Skills 仓库中的 5 个 Skill 之一其他还包括 web-design-engineer、gpt-image-2、web-video-presentation、kb-retriever面向 Claude Code、Cursor、Codex 等支持SKILL.md格式的 AI 编程代理。快速上手克隆仓库git clone https://gitcode.com/GitHub_Trending/we/garden-skills或只安装单个 Skillnpx skills add ConardLi/garden-skills -s beautiful-article延伸阅读清单协议全文skills/beautiful-article/SKILL.md重点看「硬性质检协议」段各角色质检清单与 prompt 模板skills/beautiful-article/references/review-checklist.md最小切片修复规则skills/beautiful-article/references/repair-policy.md多 Agent 并行写作与序号校准skills/beautiful-article/references/section-build.md项目总览README.zh-CN.md一句话总结让 AI 检查 AI关键不是「检查得更多」而是给对的节点配上对的检查者—— 高价值节点用独立 SubAgent 留档高频环节用消息轻量返回热上下文里就地自查。这套规则写在开源协议里谁都可以抄走。【免费下载链接】garden-skillsConardLis open-source Skills collection, featuring web design, knowledge retrieval, image generation, and more.项目地址: https://gitcode.com/GitHub_Trending/we/garden-skills创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考