我让一个智能体验收另一个智能体的代码：29 项全绿、一个没瞒报的碰撞，和 2 个可以直接抄的提示词

这不是测评，是一次验收拆解：规划师把验收标准写死在前，验收员沙箱实测 29 项，全绿报告还留一条碰撞观察项——提示词全贴下面，改改就能用。

1. 起点：验收这个环节，到底是不是走过场

码道（CodeArts）的 AgentTeam 模式把项目拆成五个角色：规划、开发、测试、审查、验收。前四个的价值，10 月初那篇无人值守文章说过，这次我盯上最后一个——验收员：其他角色的产物我能抽查验证，唯独「验收」走过场，开销就全白费。

正好手头有个跑完的真实项目：零依赖的课程表管家网页（index.html + style.css + app.js），给学生管周课表。交付件齐了，来还原验收员干了什么。产品页：https://codearts.huaweicloud.com/

2. 验收的上限，在规划阶段就写死了

读验收员产物前，我先读了规划师的 plan.md——295 行，在容易忽略的 .codeartsdoer/plans/ 目录。这是写给下游四个角色的任务书，跟验收关系最大的是五条验收标准（F1-F5）和「不做清单」。

F1-F5 每条三段式：需求、实现要点、验证方法。以 F5「同一时间段冲突标红」为例，验证方法写到判定公式：同天且节次闭区间相交即冲突，删一方后另一方恢复配色。不做清单更狠：账号、移动端、导入导出、课程编辑四类禁止越界——验收员逐条扫功能代码，出现即违规。

**验收标准的上限，规划阶段就写死了。**让验收员临场发挥「该查什么」，力气会花在格式命名上；写到公式层面它才会跑边界。规划提示词（可以直接抄）：

[验收标准写法] 每条功能需求三段式：需求 / 实现要点 / 验证方法
[验证方法颗粒度] 写到可执行层面：判定公式、具体操作、预期结果，不写「功能正常」
[不做清单] 单列禁止越界的功能，验收逐条扫描功能代码行，命中即违规
[对抗项] 额外列对抗场景：非法输入、边界值、异常环境，验收员逐项实测

3. 验收员的三条纪律，和 29 项检查

验收员产物在 .resultverify/：35KB 验收脚本、验证报告、结构化证据。开头声明三条纪律：

一、**不引用既有测试结果。**单测 71 用例全过，验收脚本一个断言没复用——29 项检查全独立执行：Node vm 建沙箱执行 app.js 真实源码，走真实初始化与提交路径。

二、**对抗式探针。**10 项全故意使坏：非法 JSON 不崩溃、混入 day=9 被丢弃、课程名塞 XSS 向量后原文显示且未用 innerHTML、双击提交被拦。

三、**「刷新」语义对齐了。**模拟 F5 = 全新 JS 上下文 + 持久层保留——JS 堆全重置、localStorage 从磁盘读回，比「再调一次 init」严格。

测试 40KB 比被测的 app.js（23KB）还大，验收脚本 35KB——测试加验收超过交付件本体，是判断团队真干活还是走过场最便宜的指标。

[验收链路] 规划师 plan.md（F1-F5 验收标准 + 不做清单）
    → 开发（三文件交付）→ 测试（71 用例单测）→ 审查（规则白盒）
    → 验收员：vm 沙箱独立执行真实源码
        ├── 29 项检查：功能逐条 + 对抗探针 10 项 + 边界值
        ├── 三纪律：不引用测试结果 / 对抗式使坏 / 刷新语义对齐
        └── 报告：通过项 + 观察项（低概率边界留痕，不阻断验收）

4. 第一个坑：它自己标的运行方式，跑不通

全绿之下照例抽查，第一下就撞坑。测试文件头部写着两种运行方式：node --test tests/ 和 node tests/app.test.js。第二种 71/71 通过；第一种——排最前面的——报 Cannot find module，0 用例。

表象有迷惑性：文件是智能体写的，运行方式也是它标的。判别办法朴素，写法全跑一遍：node --test tests、node --test ./tests/、node --test（无参数）、node --test tests/app.test.js——前两种报错，后三种过。

根因一句话：node --test 带显式路径时，路径被当入口文件交给 CJS 加载器解析，tests 目录没有 index.js，直接找不到模块；不带参数才走默认发现。文件头那个「官方写法」当前版本跑不通。

这条教训单独记：**智能体自己写的文档，不等于它验证过的文档。**文件头声明、README 命令、注释用法，真跑才算数。

5. 第二个坑：全绿报告里的一条观察项

29 项全 PASS 的报告里有一条 P10，名字带「观察项」：同一毫秒添加多门课的 id 唯一性。课程 id 规则是毫秒时间戳加 4 位随机数，验收员固定毫秒下压 10 万次生成，只得 51390 个唯一 id——存在碰撞。它没判 FAIL，理由在证据里：手工提交间隔远大于 1 毫秒，4 位随机 65536 种取值，属理论低概率边界。

我在本机复现了这个探针（可以直接抄）：

# 10 万次生成里有多少个唯一 id（碰撞实测）
import random
ids = {f"c_1760000000000_{random.randrange(65536):04x}" for _ in range(100000)}
print(len(ids))  # 本机实测 51386，与验收员报告的 51390 同量级

我的判断：这不算瞒报。低概率边界不阻断验收——判成 FAIL 反而说明判分器没有量级感；但必须留痕进观察项，让读报告的人拿量级决策。全绿不一定可信，带观察项的全绿才可信。

6. 验收提示词和三个判断

收敛成一条验收提示词（可以直接抄）：

[验收纪律] 不引用既有测试结果，断言独立执行；不改被测代码
[验收环境] 沙箱执行真实源码，走真实初始化/提交/渲染路径；「刷新」= 全新上下文 + 持久层保留
[对抗探针] 非法输入、边界值、异常环境、重复操作逐项实测，不查格式命名凑数
[观察项制度] 低概率理论边界不判 FAIL，写入观察项附量级证据，交人决策
[文件头命令] 被测项目自述的运行方式逐条实测，跑不通如实记录

三个判断：

1. **验收的上限在规划阶段写死。**验证方法写到公式层面，验收员才会跑边界；临场发挥只查格式。
2. **智能体自己写的文档不等于验证过的文档。**文件头排第一位的运行方式就跑不通，抽查永远从自述用法开始。
3. **验收员的诚实比全绿重要。**观察项制度让「不说谎」成为结构设计，不靠角色自觉。

金句收尾：验收员的价值不是把报告刷绿，是让每项绿都有对抗的证据——全绿里藏着的观察项，比全绿本身可信。

作者：林华鼎 · 华为云开发者发展与支持部 · 科技博主系列