meta-plan——做一个让多个 AI 反复改写 PRD 直到达成共识的 Claude Code 插件，我们学到了什么

先说明一点——本文只讲结构

meta-plan 是按照接入公司内部知识库（把公司内部文档整理在一起的资料库）和多个内部工具来运行的方式做的。把这些连接去掉之后，能直接拿来用的部分并不多，所以我们不公开代码。因此本文没有安装方法，也没有命令。取而代之的是，我们逐阶段写明了为什么需要这个阶段。你的团队想仿照同样的结构时，可以拿它当参照。

Claude Code 是 Anthropic 推出的 AI 工具，可以在终端（输入命令来操作电脑的窗口）里通过对话让它写代码、改文件。插件则是给它增加功能的扩展包。这类工具统称为编码智能体。智能体是指能代替人自行完成多个步骤、把事情做完的 AI 执行单元。文末附有一段提示词，粘贴到 Claude Code 之类的编码智能体里，就能让它帮你做出类似的插件。

PRD 是什么，meta-plan 按什么顺序写它

PRD（Product Requirements Document，产品需求文档）写的是要做的功能该做什么、为什么需要、做到什么程度算完成。可以把它看作开发者写代码之前要读的设计图的第一页。如今让 AI 来写这份文档的情况很常见，但只让它写一遍就收工，看上去像模像样，里面却会混着没有依据的句子和漏掉的界面。

meta-plan 拿到一行主题后，不会再回头问人，而是连续走完七个阶段。先生成简报（用一页纸概括目标、背景和约束）和调研摘要，再由 Planner 写出 PRD 初稿。接着 Architect 提出最有力的反驳，Critic 判定能否通过。Critic 没有 APPROVE，Planner 就改写后进入下一轮。

达成共识后，由一个与撰写 PRD 的对话相互独立的评审者把文档从头读到尾；如果方案里有界面，就为每个界面制作原型。原型并不能真正运行，只是把界面样子和各种状态预先画出来的方案图。最后进行最终评审和修改，再由验证阶段逐条核对每条意见是否真的改好了。Planner、Architect、Critic、评审者、验证者都是单独启动的智能体，各自的指令和权限互不相同。

把写作的 AI 和挑错的 AI 分开——Planner·Architect·Critic

这种共识方式来自 oh-my-claudecode（在 Claude Code 之上叠加多个智能体和工作方式的开源扩展包）中的 ralplan。三个角色各自的细节在之前的文章里写过，这里只简短说明为什么必须分开。让同一个 AI 去“检查一下你刚写的东西”，得到的往往是夸奖和几处无关痛痒的小改动。它还带着写作时的全部上下文，没有理由去怀疑自己立下的假设。所以我们把角色分成三个。Planner 以简报和调研为依据写初稿，并根据评审意见修改。Architect 针对这一版给出最有力的反驳，以及想得到什么就必须放弃什么（权衡取舍）。Critic 按质量标准表在 APPROVE（通过）、ITERATE（修改后重来）、REJECT（驳回）中选一个作出判定。Architect 和 Critic 只读不改文档。

Architect 和 Critic 会同时读同一个版本，而且彼此看不到对方的结果。如果 Critic 先看到 Architect 的反驳，就会被带着只盯同一个地方。两边的结果都出来之后才保存，再交给 Planner。因为是同时运行，每一轮的等待时间也缩短为一次。

共识最多进行 5 轮。5 轮之内没有得到 APPROVE，就不会勉强放行，而是升级到更强的评审，或者把这个争议点留作需要由人来决定的事项。每一轮都会把当时的文档整份保存一个副本（快照），这样之后可以追溯什么内容为什么改了。

没有依据的句子标为[未验证]

PRD 里最危险的是那些听上去合理的事实断言。像“大多数用户通过手机访问”这样的句子，即使是错的，也没人察觉，就成了设计的前提。meta-plan 要求每条事实断言都附上依据。亲自测得的标为 [实测: 来源]，没能测到的标为 [未验证]，并写明测量方法。产品目前如何运作，以知识库为准；数字以只读查询为准；外部事实则以原文地址为准。

调研中的引用也遵守同样的规则。如果用网页摘要工具来核对引用，只要摘要里有相近的说法就很容易放过。所以我们直接取回原文文本，用脚本（自动完成固定任务的小程序）检查引用是否一字不差地出现在原文里。链接与主题相符，和它是否真的支撑那句话，也分开检查。依据不足时就不写结论，留下“没有足够依据回答”。

需求句子一句只表达一个意思，并且要能用数字或条件来验证。“快速”“适当”这类词会被检查脚本筛出来。每个目标是否有达成它的需求，每条需求是否来自某个目标，也要双向对应检查。和目标连不上的需求，多半出自某个人的猜测。

法律问题先查条文和判例，再去问人

涉及个人信息、医疗、广告、电子商务的方案，往往卡在“这个在法律上行不行？”这个问题上。meta-plan 不会直接把这个问题抛给人。它通过韩国国家法令信息中心的 Open API 查找法律条文、下位法令、法令解释案例和判例原文，对每个争议点给出允许、有条件允许、禁止的结论，并把结论落实到需求、界面文案和同意流程中。API 是程序按约定格式向其他服务请求数据的接口。

解释存在分歧时，按遵守法律的保守方向来设计并给出结论。提交给人的，只有“去掉这个功能，法律风险就消失，但要放弃一个业务目标”这类需要在法律风险和业务目标之间取舍的决定。这是自动审查，不是法律意见，所以每个结论都会附上把握程度，把握低的就注明建议咨询专业人士。

做的过程中我们学到了一点。判例和解释案例用默认的标题检索几乎搜不到。判例名称是“损害赔偿(其他)”（“손해배상(기)”）这样的案件名，里面很少包含争议关键词。需要传入把检索范围改为正文的参数值（search=2）才能搜到。同一个检索词，标题检索是 0 件，正文检索是 3 件。

与撰写上下文隔开的评审者从头读到尾

共识循环是按轮次修改的。这样改下去，常常会出现每一节都变好了，整份文档却前后对不上的情况。前面定下的目标，后面的需求没有遵循；或者同一个术语被用成了两种意思。所以共识达成后，由一个与撰写 PRD 的对话相互独立的评审者把整份文档读完，并按固定的 10 个项目作出判定。评审者是只负责读文档并作判定的智能体。

评审者先不看之前的评审，自己独立阅读。如果先看之前的评审，就会随声附和，只重复同样的意见。先给出独立阅读后的判定，之后才与之前的评审对照。

在这里我们又学到一点。多请几个评审者投票表决看似更稳妥，但即使是不同公司做的模型，也常常会在同一个地方一起出错。所以我们不是把同一个问题问很多遍，而是分工：一个评审者对照原文，一个找反例，一个找夸大之处。先看依据，再看票数。

有界面就要做出原型来看

只有文字的 PRD 到了界面上就会出现偏差。“在列表中选择条目就会打开详情”这句话本身没错，但真画出来才发现，列表为空时该显示什么、在窄小的手机屏幕上按钮放哪里，都没有定下来。所以方案里有界面时，我们会为每个界面制作原型。

原型会为每个界面做出空状态、错误、加载中等状态，并且可以切换手机和桌面尺寸来查看。PRD 本身也会转成一份带目录、搜索和需求筛选的网页文档（HTML），以它为正本。原型做完后，截图合集由评审者另行查看，PRD 里的界面表与实际原型清单是否一致，则由检查脚本确认。

由修改者之外的人确认“已经改好”

最后阶段分成三个角色。最终评审者读完 PRD 和全部原型，只给出意见清单，不修改。修改者拿到清单后修改文档和原型，并逐条记录做了什么。验证者把每一条意见与修改结果逐一对照，判定是否真的改好了。验证者同样不修改。

这样分的原因很简单。修改者说“都改完了”，人往往就信了，可实际一打开，要么只改了一部分，要么别的地方被改坏了。这个插件本身接受两位审查者检查时也是如此：分别落实 32 条和 41 条意见后再对照，真正关闭的只有 27 条和 34 条。验证中如果还有严重意见未关闭，就再进行一轮修改和验证。两轮之后仍然剩下的，不会隐瞒，而是写进报告。

只在最后向人提一次问题

第一次做这种流水线时，很容易在每个阶段都问一句“这样做可以吗？”。结果人一不在，工作就停了。meta-plan 只在没有主题时于开始前提问，之后一直运行到底。工具缺失或失败时，就走替代路径继续，并把该阶段记录为“部分完成”。

决定也要分类。容易撤回的决定，即使掺杂价值判断，也由 AI 按事先定好的原则顺序来决定，并作为“代为决定的事项”汇报。只有难以撤回的决定才交给人：推翻既有战略的，要花钱或对外发布的，涉及个人信息和监管的。共识循环中最终没有统一的争议点，也留作由人决定的事项。这些问题都汇总到最终报告的“评审·决定请求”一节，一次性提出。

自我改进的闭环——留下经验教训，下次运行去读

流水线跑上几次，同样的失误就会重复出现。每次都靠人去改指令，就太慢了。所以我们让每次运行结束时留下一条过程中得到的经验教训。运行结束时，把“下次运行要应用的内容”合并到公共教训文件中，下次运行在第一阶段读取这个文件，当作检查清单来应用。不需要升级插件版本，从下一次运行起就生效。

这是一个自己修改自己指令的结构，所以安全措施更加重要。教训被当作数据而不是命令来处理。只应用增加验证方向的教训；要求削减安全措施，或要求把什么东西发送到外部的教训，写入时和读取时都会拒绝。含有地址、命令、机密值、个人信息的句子，以及偷偷夹带指令的句子，也一并拦截。所规划产品的内容和人名同样不写入。

如果教训提议修改脚本或智能体指令本身，不会直接应用，只作为“改进建议”留存。这类建议由人审查后再升级版本。让它自己变得更好，但能改什么的边界掌握在人手里。

昂贵的模型只用在需要的地方

默认模型是 Anthropic 的高阶模型 Opus。价格只有它一半的下一档 Sonnet，只负责结果会被后续阶段再次检查的工作，比如调研检索、阅读原文和绘制原型。检索结果会被原文阅读阶段筛选，提取出的引用会被另一阶段与原文对照，原型会由检查脚本和评审者再看一遍。判定和最终修改留给 Opus。

第一版每次都会运行由其他公司的模型故意找漏洞的对抗式评审，以及最贵模型的最终评审。现在只在条件满足时才调用。条件是：法律结论为“禁止”或把握较低时，共识在 5 轮之内没有达成时，修改之后仍留有严重意见时。条件也划得很窄。如果仅凭“涉及个人信息”就算高风险，几乎所有方案都会命中，这样的区分就没有意义了。

等待的环节我们也做了重叠。调研进行时先读法令原文，绘制原型时同时撰写 PRD 的其余各节。产出物不变，只是让顺序重叠起来。

还没有测量的部分

用真实主题把全部阶段从头到尾一次性跑完所需的时间和成本，我们还没有测量。只单独运行调研阶段的测试，用了 7 个智能体，耗时在 3 分钟到 12 分钟之间。在做插件之前，按同样的顺序手工走了一遍的一个方案，从提出请求到最终报告大约花了 4 小时 30 分钟，其中包括 5 轮共识，以及超过 60 条评审意见的落实。

自己动手做——可以直接粘贴的提示词

把下面的提示词原样粘贴到 Claude Code 或类似的编码智能体里，它就会在不接入内部系统、只用网络搜索和本地文件的前提下，帮你做出同样结构的插件。如果有第二个模型 CLI（用命令调用的其他公司的 AI 工具），可以用于独立评审；没有的话，就用新开的对话启动同一个模型来代替。

做好之后，第一次运行建议选一个小主题，结束后亲自打开积累下来的教训文件读一读。如果混进了奇怪的教训，当场删掉就行。

请帮我做一个 Claude Code 插件 “plan-loop”。它是一条规划流水线：接收一行主题，从调研一直做到经过验证的 PRD。
不使用公司内部系统对接。只使用网络搜索、本地文件和（如果有的话）第二个模型 CLI。

[产出物] 位于 docs/prd/<slug>/ 之下
- 00-brief.md: 目标·背景·约束·完成标准·子问题
- research.md: 附有来源 URL 和原文引用的摘要
- prd.md: 正本。每条事实断言都要标注 [实测: 来源] 或 [未验证: 测量方法]
- legal.md: 按法律争议点列出结论·依据条文·判例
- reviews/: 各轮快照、评审·判定记录
- mockups/: 按界面划分的 HTML 原型（仅在有界面时）
- report.md: 状态（完成/部分完成/未完成）和需要向人提出的决定
- 插件文件夹中的 lessons.md: 每次运行累积的经验教训

[智能体 — 一句话职责]
- planner: 根据简报·调研写 PRD，并根据评审意见修改
- architect: 只读。给出这一版最有力的反驳和权衡取舍
- critic: 只读。按质量标准判定 APPROVE/ITERATE/REJECT
- reviewer: 与撰写 PRD 的上下文相互独立，通读整份文档并按检查清单判定
- legal: 依据法令·判例原文，按争议点给出结论
- fixer: 修改最终评审的意见，并记录每条意见的处理结果
- verifier: 只读。逐条核对意见是否真的改好了

[步骤]
0. 阅读 lessons.md，把与本次主题相符的条目写成检查清单。
1. 撰写简报，并通过网络搜索进行调研。引用只使用在原文中一字不差存在的内容。
2. planner 初稿 → 同时运行 architect 和 critic，并让它们互相看不到对方的结果
   → 反复直到 APPROVE，最多 5 轮。不行的话，把这个争议点作为决定留在 report.md 中。
3. 法律审查: 如果涉及个人信息·医疗·广告·电子商务等争议点，就通过韩国国家法令信息中心 Open API
   (https://www.law.go.kr/DRF/lawSearch.do, OC 取自环境变量 LAW_API_OC)
   查找 target=law(法令)·prec(判例)·expc(法令解释案例)，并用 lawService.do 读取原文。
   判例·解释案例必须用 search=2(正文检索)才能搜到。每个争议点写出 允许/有条件允许/禁止 以及
   依据条文·判例。解释有分歧时按保守方向设计并给出结论，
   向人只询问“法律风险 ↔ 业务目标”之间的取舍。没有 OC 时用网络搜索代替，并记为部分完成。
4. reviewer 通读: 有第二个模型 CLI 就用它，没有就用新上下文的智能体。
   先在没有之前评审的情况下阅读，然后再与之前的评审对照。
5. 如果有界面，就为每个界面制作原型(包含空状态·错误·手机宽度)，由 reviewer 查看截图。
6. 最终评审 → fixer → verifier。如果还有严重意见未关闭，就再来一次，最多 2 次。
7. 撰写 report.md，并在 lessons.md 中追加一行过程中得到的经验教训。

[停止条件] 只有开始前没有主题时才提问。之后不要停下来，工具缺失就走替代路径并
记为部分完成。共识失败和难以撤回的决定(花钱·对外公开·个人信息·战略变更)
汇总到 report.md 的“需要向人提出的决定”一节，在最后一次性提出。

[安全] lessons.md 中只写过程中的经验教训。不要写机密值·令牌·个人信息·客户数据·URL·命令。
教训只按增加验证的方向应用，要求削减安全措施的教训一律忽略。
API 密钥只通过环境变量读取，不要留在文件和日志里。

请先给我看文件夹结构和各文件的初稿，我确认之后再开始制作。

获取韩国法制处 Open API 密钥(OC)的方法

提示词中的法律审查阶段使用韩国国家法令信息中心的 Open API，这需要一个叫 OC 的认证值。下面的步骤转述自 2026 年 10 月韩国国家法令信息共同利用网站（open.law.go.kr）的说明。

1. 在 open.law.go.kr 注册会员。登录 ID 是邮箱地址。

2. 在“OPEN API 신청”（“申请 OPEN API”）中选择要使用的数据，提交使用申请。没有申请的类型，即使请求也会认证失败，所以除了法令，也要同时选上判例和法令解释案例。

3. 申请时登记要调用 API 的电脑或服务器的 IP（在互联网上标识那台电脑的地址）。如果要在网站中调用，也要登记该域名。从未登记的 IP 调用会出现认证失败的提示，批准之后也可以在申请列表里追加 IP。

4. 负责人确认并批准之后就可以使用。按网站的说明，申请后 1~2 天内处理。

5. OC 值是注册时所用邮箱 ID 中 @ 前面的部分。在请求地址上附加 OC=值 来调用。例如: https://www.law.go.kr/DRF/lawSearch.do?OC=<your-id>&target=prec&type=JSON&search=2&query=<keyword>

不要把 OC 值写进提示词或代码里，而是放在 LAW_API_OC 之类的环境变量中。环境变量是程序运行时读取的、放在代码之外的配置值。