我给 AI 写了个「验收员」：一次 Skill 开发的踩坑记录

我想做一件挺朴素的事：给 AI 派活，让它自己分头干、自己检查，最后告诉我「做完了」。而且这个「做完了」得是真的。

这篇记录我怎么从一堆开源项目里挑出真正有用的部分，以及中途想错、又改掉的几个地方。

一开始，我想写个大而全的 Skill

手上有三份材料：一位 SpaceX 工程师的访谈和她自己开源的方法论工具 pstack；GitHub 上一个有几百个角色的角色库 agency-agents；还有一套把 AI 组织成「三省六部」的项目——我下旨，中书省拟方案，门下省审核，六部去干活。

我最初的想法是把它们揉成一个 Skill：角色全搬进来，规则写全，访谈里的经验也抄进去。

查完发现这个想法不成立。

第一，作者本人已经把方法论开源了。​ 她那个工具里有技能、有任务剧本、有专门的验证技能，比我能拼出来的完整得多。

第二，那些「角色」其实只是一段人设文字。​ 复制一个角色文件，我拿到的是提示词，不是独立会话，也不是权限。给审核的人和干活的人一样的写权限，「审核」就只是个标签。

第三，也是最要命的： 角色多不等于能把活干完。瓶颈不在人少，在没人能判定「到底算不算做完」。

所以我改了方向：不写大而全，只补中间那层薄薄的编排。

我踩的第一个坑：以为规则写全就够了

「三省六部」那个项目有个 issue，一位用户把实测写了出来：三轮审核每次都是一句「准奏」，没有实质检查；可以跳过前面的环节直接标完成；进度还显示 40%，状态已经是完成。他的原话结论是「骨架，没有肌肉」。

我看到这段就明白了一件事：它审的是计划，不是结果。​ 门下省看的是「打算怎么做」，没人去跑一遍命令、看退出码、看究竟改了哪些文件。

再往下查，问题更普遍：我翻到的这些项目，门禁几乎都是写在 Markdown 里的规矩，靠 AI 自觉遵守。可规矩写在提示词里，对话一长就漂移，AI 也完全可以直接说一句「已完成」。

于是我把「算不算做完」从 AI 手里收回来，交给一个脚本：

# 只有证据判定通过，才允许把状态写成完成
if stage != "EVIDENCE_READY":
    return False, "非法跳转"
if contract_hash != 当前契约哈希:
    return False, "契约改过，重新验证"
if result["status"] != "PASS":
    return False, "没验证通过，不许完成"

三条最要紧的规矩：缺证据就算失败，不叫「大概没问题」；完成状态只有脚本能写；审核退回两次还不行就转人工，绝不自动放行。

上下文这块，我一开始想反了

我原本打算给每个角色配一份长期记忆，觉得这样它们会越用越懂我的项目。

后来发现这会带来四个麻烦：记忆各说各话、账号凭据跟着人设到处跑、上层被下层一堆日志淹没、费用一直往上涨。

换成一句更好记的原则：角色不记，资产记。​

干活的角色只拿一个目标、一小段能改的文件、几个工具，干完这个短会话就结束。校验的人只看规格和改动对比，不看实现过程。上头只收三样东西：命令退出码、关键错误摘要、产物放在哪。中间那一大堆过程日志，一律不往上贴。

真正存下来的是能版本化的资料（功能地图、检查清单、规则），每份写清谁负责、什么版本、什么时候过期、上次核验是哪天。谁需要，就给谁看哪一份，不给写代码的灌调研资料。

还有个小设计我挺喜欢：证据分三栏写——亲眼看到的 / 我推断的 / 还不知道的。没验证过的推断不许往下传，免得一层层把猜测说成事实。

说白了，上下文管理不是「让每个 AI 记得更多」，而是「让每一层只看它要判定的那点东西」。

模型怎么分：先承认自己做不到什么

有个问题把我问住了：这几个角色分别用哪个模型？

查完代码我得承认，我写的 Skill 根本不调用模型接口，也不持有密钥。真正选模型，是宿主在启动子任务那一瞬间做的。把它说成「Skill 自动分配模型」是不老实的。

我能做的，是把分配写成一张派工单，让脚本先检查合不合规：

• 角色最多 4 个，必须有编排、执行、校验这三方；
• 编排这层不许用最贵的强推理模型——每个任务一上来就跑全套可行性分析，是最容易偷偷烧钱的地方；
• 校验的人必须用跟执行者不同的模型，不然两个可能一起犯同一个错；
• 校验的人只读，不能改文件。

强模型只留给真正难的那一两次判断。

省钱这件事，我改了目标

我最初写的是「尽可能省，但要完美完成」。这句话没法执行——「完美」没法判定，结果就是范围一路膨胀，省钱变成偷工减料。

改成：先把验收标准白纸黑字冻住，在达标的前提下再谈省钱。​ 预算上限也一起写进去，超了立刻停，不降级成一条警告。

另外加了个分流：单文件、十分钟能改完、一次就能验的活，直接一个角色干完验一次，不跑整套流程。这条「小活别动用满朝文武」，是从三省六部项目的单 Agent 快速模式里抄来的。

Skill 还是插件？我选了简单的那个

这是我纠结最久的一题。

插件确实能补上 Skill 补不了的东西。比如 DeepSeek Harness 有个「工具执行前钩子」，能在 AI 动手之前返回放行、拒绝或询问，把门禁变成真正的代码拦截；还有会话开始、每一步之前的钩子。这些对「防止 AI 自己宣布完成」很有用。

但另一类限制插件也变不出来：驱动真实界面、隔离工作区、跨模型评测——那是宿主本身的能力。

最后我先做了目录式 Skill：一个主文件、一个脚本、几个模板。理由很朴素：我现在要验证的是「证据门禁管不管用」，这是判定逻辑对不对的问题，跟跑在哪个框架里没关系。​ 这样零依赖、改完文件就生效、换个客户端也能读。这时候就套插件壳，等于为了一个还没证明有效的门禁，先背上一堆依赖、单一运行时绑定和安全审查。

一句话：插件化是代价，不是升级。​ 等门禁在真实任务上跑顺了，确实需要在工具执行前硬拦一道，再包一层薄壳也不迟。

最后跑出来什么

• 主文件 141 行，脚本零第三方依赖，58 项单测全绿；
• 正常流程：派工单通过 → 证据判定通过 → 脚本写入完成；
• 故意删掉一条证据：判定返回「未验证」，推进被拒，状态原地不动；
• 把编排角色改成强推理模型：派工单直接判不合规。

过程中还修了两个真实缺陷：状态能直接跳到「完成」、有个参数解析错位。这两个都是写完代码才发现的——也说明「把规矩写进代码」不等于规矩就对了，拒绝的路径一样得有测试。

还差什么

没在真实业务任务上跑过完整链路，插件壳没做，证据文件也还没和产物做哈希绑定。这些我都写在文档里，没假装已经完成。

一句话收尾

两三个角色负责干活，一个脚本负责宣布干完了。​

折腾这一圈我最大的收获是：多智能体里最贵的不是模型，也不是角色数量，是「谁有资格说做完了」。