技术 · 深入
AI 编码验收，为什么总查不出问题
规划师定判据，验收员跑实测
这套方法解决的是「AI 写完代码后验收走过场」：把验收标准的制定者和执行者拆成两个角色——规划师在动工前就把验收标准定稿（每条按「需求、实现要点、验证方法」三段写，验证方法必须落到一条判定公式），验收员拿不到过程材料、只拿产物，在干净沙箱里跑真实源码逐条实测，并主动用非法输入制造问题。落地路径是两段：先用一份 plan.md 完成「标准写死」（本次实测 295 行、F1–F5 五条），再用一段可复制的验收提示词完成「独立实测 + 对抗探针 + 观察项留痕」，最终输出一张逐条对照的验收结论表。
方法 · 一图看懂
1
先拆角色，再谈标准 — 写实现的和定判据的必须是两个身份。规划师只产出 plan.md，不写实现代码；验收员不参与规划、也看不到开发过程，交接物只有三样：plan.md、最终产物、运行环境说明。
2
在规划阶段把验收标准写死 — 每条标准固定三段结构：需求、实现要点、验证方法。标准在动工前定稿，实施过程中只允许追加、不允许放宽——一旦允许事后改标准，验收的上限在动工前就固定了。
3
验证方法要写成公式、操作、预期三件事 — 举例：同天且节次闭区间相交即判定为冲突；操作 = 删除其中一方的课后；预期 = 该时段另一方的配色恢复。只写「课程表不应冲突」这类描述，验收员最后只能检查格式和命名。
4
单列一份不做清单 — 把本次明确不实现的边界逐条写清（本次实测写入了账号体系、移动端适配、导入导出、课程编辑四类）。不做清单同时是验收员判定「这不算缺陷」的唯一依据。
5
验收员在沙箱里跑真实源码 — 在隔离的运行环境里加载真实文件执行，不复用开发过程的单测结论（本次 71 个用例、一个断言都没有复用），也不读代码脑补通过；刷新语义统一按「全新运行上下文 + 持久层保留」执行。
6
对抗探针 + 观察项留痕 — 10 项主动制造问题的用例：非法 JSON 不崩、day=9 被丢弃、XSS 向量原样显示、双击提交被拦。跑出来的低概率边界（如固定毫秒下 10 万次生成只有 51,390 个唯一 id 的碰撞）判为不阻断，但必须写进报告留痕。
档位差异 · 判据的产出者和产出时机被写死
「验收要用可判、可重跑的客观判据」这层意思已经有过；这一页往前推的是谁来产出判据、在什么时间点产出。角色拆分单看也容易流于口号——共同点是复核方只拿产物、不拿过程，给一份可判清单。真正决定成败的，是判据必须在规划阶段由规划角色定稿：标准定得晚一步，后面所有努力只能在一个已经偏小的范围内提高。这也是本次实测里最值得注意的一点：295 行 plan.md 里的 F1–F5，没有一条是验收员事后补的。
可复制的两个写法：三段标准 与 三件事验证
写法一（每条标准）：需求原句、实现要点、「验证方法」。三段缺任何一段，标准都会退化成一句口号。
写法二（验证方法）：判定公式（或明确判断条件）+ 操作步骤 + 预期结果。例如「同天且节次闭区间相交」是公式，「删一方」是操作，「另一方配色恢复」是预期——三者拼起来，一个没读过代码的人也能判定通过与否。反面例子是「页面应美观」「交互应流畅」，这类描述会让验收员只能检查文件名拼写和格式缩进。
验收员的三条纪律，和那条不阻断也须留痕的 P10
三条纪律：一、不引用既有单测结果——开发侧 71 个用例全部作废，验收自己重新构造输入与断言；二、主动制造问题——非法 JSON、越界 day=9、XSS 向量、超长输入、双击提交，逐条试过才算测过；三、刷新即新上下文——每次重载都起一个全新的运行上下文，只保留持久层，防止内存残留骗过检查。
P10 的处理方式值得借鉴：固定毫秒时间戳下生成 10 万次只得 51,390 个唯一 id，属于低概率边界。结论是不阻断验收，但必须进报告。观察项既不缩小为不通过，也不直接删除。
不做清单不是免责声明，是判定基准
不做清单要在规划阶段就写下来，且只写「本次不做」的明确边界（账号、移动端、导入导出、课程编辑）。它的作用有两个：一是防止实施阶段自发扩大范围；二是给验收员一个基准，遇到清单之内的缺失直接判「不在范围」。副作用也要防：如果实施阶段真的补做了清单外的功能，验收员不为它负责，但也不给它通过或不通过的评价，只在报告里记一行「超出范围的新增」，避免范围扩大反过来影响验收结论。
原理 · 为什么有效
验收失效的常见原因，是「完成」的定义一直在变：写完代码的人定义完成，就会不自觉地用「能跑起来」替代「符合需求」；同样的模型评审自己写的东西，等于同一套前提自己证明自己。把判据的产出权提前到规划阶段，等于在动工前就把「什么叫完成」定了下来，验收员手里只剩执行测量，没有解释空间。独立性再补一层：不拿过程材料，就堵住了「引用既有单测」「读代码脑补通过」这两条捷径；对抗探针把「没测到」变成「测过且不崩」；观察项留痕则避免低概率边界被静默忽略或误判为不阻断。三层叠加，验收结论才可复核——换一个人拿同一份 plan.md，应该能得出同样的结论。
适用场景
适合：产物有明确可判形态的编码任务（表单校验、排课冲突、导出格式、状态机流转）；Agent 或自动化流程的产出需要独立复核；一次性交付的独立项目，比如本次 23KB 的零依赖静态站（index.html + style.css + app.js）。
不适合：需求还在探索、根本写不出可判标准的时候（此时该回去做需求，而不是走验收）；产物高度主观（文案语气、视觉美感）；需要长期演进的系统（判据写死成本高，建议改为按里程碑重定标准）；只改一行的微任务（开两个角色的开销大于收益）。
自测 · 6 问
你的验收标准是谁写的？是不是写代码的那个角色自己事后补的？
每条标准里的验证方法，能不能落到一条判定公式或一次可执行操作？
验收时有没有翻出开发过程的单测结果、日志或注释来佐证「通过」？
验收员是在干净上下文里跑真实源码，还是只读了一遍代码就下了结论？
有没有一份对抗清单：非法输入、越界值、重复提交、XSS、空数据、刷新后状态？
跑出来的观察项，有没有分成「阻断验收」和「留痕不阻断」两类分别记录？
怎么上手 · 验证步骤
按这个顺序做：① 先把需求压成一页，列出交付物清单和本次不做的四类边界；② 切到规划师身份，只写 plan.md：F1–Fn 每条三段，验证方法必须是公式 + 操作 + 预期，写不出公式的那条单独标出来，退回需求澄清；③ 实施阶段严格对照 plan.md 逐条实现，允许追加标准、禁止放宽；④ 清空过程记忆，切到验收员身份，在沙箱里加载真实源码，逐条对照验证方法执行，再补 10 项对抗探针；⑤ 输出结论表，把不通过项和观察项分两栏写清。
做一次交接检查：把 plan.md 单独交给一个没参与开发的人或另一个智能体，在它不看实现代码的前提下，看它能否照着验证方法逐条判出「通过 / 不通过」。能判出来，说明判据合格；判不出来或只能检查格式命名，就得回去把那条标准的验证方法补成公式。再补一个反向自检：验收报告里每一条「通过」，都要能指回 plan.md 里的具体编号。