协作与交付：把要求说清楚，把检查做扎实

与智能体协作的产出质量，取决于两件事：要求说得够不够具体，以及验收环节设计得够不够硬。这两件事都跟模型能力无关，却决定了大部分结果的好坏。

先说结论

• 两个真正有效的杠杆：把要求写成可判断的形式（有范围、有阈值、有产物形状），以及让交付物先"看得见"再看；
• 最反直觉的一条：脚本全绿往往意味着"假通过"——它检查的是文件属性，而不是渲染结果；
• 不声明模式，智能体会在同一个会话里边审边改，回头已经分不清哪些是原始问题、哪些是它新引入的。

一、一次"全部检查通过"的返工

2026 年 8 月，要交一份汇报材料：一份文字稿、一份幻灯片。生成流程本身没出问题，验收脚本逐项检查页数、字数、文件体积、关键小节是否齐全——全部通过。

到现场打开才发现：幻灯片第三页的标题超出一行，右半边被裁掉；一张表格跨页断开，第二页只剩一个表头；正文字体在目标机器上不存在，回退成默认字体后行距全乱。

三处问题脚本一个都查不出来，因为它检查的是文件属性，不是渲染结果：

验收方式	耗时	实际能发现的问题
检查页数、字数、文件体积	秒级	内容缺失、字数超标
解析文档结构找未替换的模板变量	秒级	占位词、空章节
导出整页图片并打开看	分钟级	溢出、截断、断表、字体回退

只有第三行能发现"排版坏了"，而它恰恰最容易被跳过，因为它需要人真的看一眼。由此定下的规则很直白：生成物先渲染成"人能一眼看到"的形态，再讨论怎么改——幻灯片导出全页图，网页导出整页截图，图表导出图片。

稍加注意

"文件属性检查全过"是最容易制造假通过的验收。它成本极低，所以很容易被当成验收的全部；但页数、字数、体积都对，成品依然可能整体不可用。

二、模式不声明，改动就说不清

同一次交付里还有一个更隐蔽的起因。当时请智能体"看一下这个项目有没有问题"，语气是审阅，实际动作是审阅加修改：它读完文件顺手改了 6 个模块，结束时给出一份"改了什么"的清单——但原始问题和新引入的改动混在同一批 diff 里，回滚无从下手，只能人工逐段比对。

问题不在它的判断，而在没有声明当前处于哪种模式：

• 审查模式：只读、只分析，输出问题清单与依据，并明确"本次不修改任何文件"；
• 修改模式：在约定范围内改动，每处改动对应一个已确认的问题编号。

现在这两句话会写在任务的第一段，范围也一起写死，例如"只允许改 docs/ 下的文件，不要动构建配置和依赖清单"。两句话的成本，省掉的是整轮返工。

三、把要求写成可判断的形式

模糊要求	可判断的要求
帮我优化一下	把首页首屏从 3 个区块减到 2 个，并压缩到一屏内（1440×900 不出现滚动条）
检查有没有问题	逐页检查外链可达性，输出失效链接清单与状态码
做得好看一点	按这套间距与配色改，改完导出截图给我确认
再完善一下	补上失败原因分类，并在 3 个已知坏样本上验证不再中断

右列的共同点是：完成与否能被别人复现地判断。写不出右列那一句，通常说明需求本身还没想清楚——这时候派出去，大概率返工。

四、机器能判的不要占人的注意力

反过来，机械性检查不该消耗人的注意力。医学影像软件的界面交付是这一条的正面样本：用自动化驱动真实的桌面应用遍历整个界面，13 个页面、审计到 265 个可点击元素、实际执行 192 次点击、零失败。这组数字比"界面检查过了"有说服力，因为它可复现、可对账、可写进交付说明。

# 交付前的固定动作：可复现的机械检查
python -m audit.ui_walk --app build/app.exe --report out/ui-walk.json   # 遍历可点击元素
python -m check.links docs/ --fail-on-broken                             # 外链可达性

但同一次交付里也有反例：能点击不等于点了有用。自动化覆盖的是"按钮点下去不报错、界面不崩"，业务逻辑是否正确它判不了。最后的分工是脚本负责覆盖面，人负责抽查关键流程：

交给脚本（每次跑）	交给人（固定抽查点）
链接可达、构建通过、字数与体积	排版是否成立、语气是否合适
可点击元素遍历、接口返回结构	场景适配（这份材料给谁看、现场怎么用）

性价比最高的一步

在交付流程里固定一条命令：把成品导出成图片再打开看。它只花几分钟，却是唯一能拦住"文件属性全对、成品不可用"的检查。

五、可复用清单

• 会话开头声明模式（审查 / 修改），写清允许改动的范围与禁止项；
• 要求尽量带范围、阈值或产物形状，"改完是什么样"要能被别人复现地判断；
• 交付前先渲染出可视形态，人真的看一遍，再谈修改；
• 机器能判的写进脚本每次跑，必须人判的固定成抽查点，不用"再看一遍"这种话代替检查；
• 提前写下"什么情况下不算完成"，退回条件写在交付前比写在交付后有效。