PROVE
怎样证明
产物为什么可信？证据能指回哪份输入、哪次运行、哪条规则？
把 Agent 装进可验收系统
契约、夹具、Gate 与失败样本
从“模型能跑”继续往前一步：让结果可证明、失败可复现、风险能停下。
45–50 MIN16 SLIDES4 PROJECT CUTS
NEXT先说今天刻意不讲什么
今天不再讲后端基本概念
把注意力从“服务怎么搭”移到三件更难回答的事。
STOP
怎样停
遇到高风险、歧义或工具故障，谁暂停、谁批准、谁接管？
REPLAY
怎样复现
换一份材料、换一台机器，能否用同一套夹具与检查重跑？
NEXT先拆穿一个常见错觉
真正难的不是能跑，而是能证明
同一次成功，在 Demo 和工程系统里代表完全不同的证据强度。
ONE-SHOT DEMO
看起来会做
- 一条 prompt 跑通
- 结果肉眼不错
- 失败时重新问一次
- 上下文靠人记得
VS
ENGINEERED SYSTEM
可以被验收
- 输入与输出有契约
- 批准点和停止条件明确
- 失败样本保留并归因
- 同一夹具可以复跑
一次成功回答的是“能不能”；工程证据回答的是“凭什么、到哪一步、失败怎么办”。
NEXT先看一个最不像工程的资产
这只桌宠，其实是一份资产协议
“一张可爱的图”进入运行时后，会变成尺寸、透明度、帧布局、动作语义与版本号。
RGBA透明通道
8 × 11帧网格
9标准动作类
16注视方向
pet.json
{ id, displayName,
spriteVersionNumber,
spritesheetPath }pet.json 只写 4 个字段，也足以把素材从“图片”升级为可装载资产。
NEXT图片还能承担另一种工程角色
截图不是装饰，而是证据
证据截图必须同时回答：什么时候、哪一版、哪台机器、哪条任务链，以及它证明不到哪里。
能证明2026-08-21，本机 WorkBuddy v5.3.14，这一次脱敏任务链。
不能证明课堂已通过、任意版本都一致、产品能力长期稳定。
NEXT当证据不止两张图，生产方式也要改变
课程生产被做成了编译流水线
内容不是直接写进页面，而是先经过结构化契约，再生成、检查、留下 Gate 记录。
01
Curriculum
候选课程与真实任务
→
02
Contracts
大纲、来源、页面计划
→
03
Build
HTML / notes / PPTX
→
04
QA
结构、视口、溢出、目读
→
05
Gate
只按证据升级状态
目录存在、页面能开、静态 QA 通过，都不等于课程批准。
NEXT流水线最容易忽略的是证据过期
任何改动，都会让一部分证据过期
“改了一个字，为什么还要重测？”——因为不同改动击穿的是不同证据层。
| 改动 | 失效的证据 | 最小重跑 |
|---|---|---|
| 来源 / 日期 | 事实、引用、产品版本 | 来源复核 |
| 页面文字 | 标题、口播、页序一致性 | 内容 + 目读 |
| CSS / runtime | 溢出、键盘、移动端 | 全页浏览器 QA |
| 部署配置 | 入口、资源、缓存、回滚 | 发布回读 |
构建哈希只能告诉你“变了”，失效矩阵才告诉你“该重跑什么”。
NEXT证据分层之后，角色也能分开
Multi-Agent 的价值，首先是隔离失败
角色越多不一定越好；边界清楚，才能知道失败属于谁、从哪里重跑。
ONE AGENT DOES ALL
上下文混在一起
- 规则、写作、审阅同一口径
- 错误会一路扩散
- 返工只能整段重来
- 很难知道谁批准了什么
VS
BOUNDED ROLES
失败被局部化
- 写作者只交小样
- 审阅者只报差异
- 批准点由人签
- 失败从对应文件重跑
并行是性能优化；隔离输入、权限、输出和批准责任，才是系统设计。
NEXT但不要先从“需要几个 Agent”开始
先拆成能交的文件，再分角色
Agent 角色是一种实现；可检查的中间产物才是稳定接口。
01
规则清单
把隐含判断写成真假条件
→
02
小样本
先跑 5–10 条，不吞异常
→
03
分级输出
通过 / 待审 / 阻塞
→
04
人工复核
只看差异与高风险项
→
05
规则回写
把纠错写回下一版
每个箭头都必须能停；每个方框都必须能打开、比较、签字。
NEXT有了文件接口，才谈逐级放权
自动化不是开关，而是五级放权
每一级都要用上一层的真实记录换来，不用“感觉稳定”升级。
手工两次
人全程操作，留下输入输出
小样本
限定 5–10 条，先看预览
人盯单次
工具执行，人逐步确认
低频受限
限定范围、次数与权限
日志 + 暂停
可观测、可接管、可回滚
如果暂停、回滚、责任人还没写清，第 5 级只是无人值守，不是工程化。
NEXT升级依据来自新样本，不来自旧成功
稳定性要用新样本打穿
旧样本验证回归；新样本验证边界。两者回答的是不同问题。
REGRESSIONPASS
旧 07
已知规则还能复现
GENERALIZEPASS
新 A
在既定边界内迁移
BOUNDARYFAIL
新 B
新增字段，规则不足
BOUNDARYFAIL
新 C
重复键，验收未覆盖
失败样本不是脏数据：它是下一版规则和停止条件的输入。
NEXT看到 FAIL，先别急着改 prompt
失败先归因，再决定改哪里
同一个“结果不对”，可能来自四个完全不同的故障域。
INPUT
输入问题
缺文件、字段漂移、编码损坏。先停并补材料。
TOOL
工具问题
权限、超时、格式不支持。换路径或降级。
RULE
规则问题
判断条件漏写、例外未覆盖。改规则和测试。
CONTRACT
契约问题
输出、验收、批准点含糊。先改接口。
所有失败都归因给模型，会得到更长的 prompt；不会得到更可靠的系统。
NEXT这套思路对嵌入式并不陌生
嵌入式团队其实很熟悉这套思路
不是说两套系统完全相同，而是可以复用同一种控制与验证直觉。
AGENT 工程嵌入式直觉共同问题
Agent Loop控制环
观察 → 判断 → 动作 → 再观察
Tool外设 / 驱动
能力由接口、权限、时序共同约束
停问 / 接管故障处理
进入安全态，把控制权交给人
夹具复跑HIL / 回归台架
同一输入和仪表重复验证
最值得迁移的不是术语，而是：默认会坏、设计可观测、先定义安全态。
NEXT用一题把两种工程语言接起来
现场挑战：100 份 MCU 量产日志
目标：找出 CRC 错误、掉线与过流，产出可复核的批次摘要。
INPUT
你拿到什么
- 100 份只读日志
- 设备 / 固件 / 批次映射
- 阈值与已知例外
OUTPUT
必须交什么
- 逐设备异常表
- 批次聚合摘要
- 原始行号与证据片段
- 待人工复核队列
HARD STOP
绝对不做
- 禁止刷写设备
- 禁止删除日志
- 禁止自动放行批次
现场任务两人一组：先写 1 个停止条件、1 个批准点、3 个最小测试样本。
NEXT答案不从 prompt 开始，而从验证清单开始
先把验证清单写在执行前
只要这五栏写不完整，就还没有一个可交给 Agent 的工程任务。
输入
文件、格式、版本、权利、缺失项
输出
文件形态、字段、命名、证据回链
批准点
何时必须等谁确认
停止条件
歧义、超时、高风险、工具故障
测试集
旧回归、新边界、失败样本
验证不是最后一次检查；它是系统开始运行之前的设计输入。
NEXT最后只带走一个判断
离开时，只带走一个判断
Agent 系统不是一个更长的 prompt。
模型+工具+边界+证据+人工接管
少任何一项，都可能仍是好 Demo；但还不是可验收、可接管、可持续复跑的系统。
INTERNAL SHARE · DRAFT FOR HUMAN VERIFICATION
NEXTQ&A：你们的系统现在最缺哪一项？