mirror of
https://github.com/tvytlx/ai-agent-deep-dive.git
synced 2026-04-03 07:34:50 +08:00
93 lines
2.5 KiB
Markdown
93 lines
2.5 KiB
Markdown
# 06. 验证与质量保证需求文档
|
|
|
|
## 1. 为什么“做完”不等于“完成”
|
|
|
|
在 AI 编程产品里，最大的风险之一是：模型会把“代码改了”误当成“任务完成了”。
|
|
|
|
因此，这个产品必须把“验证”设计成一个独立能力，而不是可有可无的附属步骤。
|
|
|
|
## 2. 验证系统的产品目标
|
|
|
|
1. 独立检查实现是否真的可用
|
|
2. 防止只读代码就宣称完成
|
|
3. 防止 happy path 偏见
|
|
4. 让验证结果带证据而不是口头判断
|
|
|
|
## 3. 验证 Agent 的需求
|
|
|
|
### 3.1 独立角色
|
|
验证角色需要与实施角色分离，避免实现者偏见。
|
|
|
|
### 3.2 默认心智模型
|
|
验证角色的工作不是“帮实现找理由通过”，而是主动尝试发现问题。
|
|
|
|
### 3.3 必须禁止的行为
|
|
验证角色不能：
|
|
- 修改项目文件
|
|
- 安装依赖
|
|
- 用写操作掩盖问题
|
|
|
|
### 3.4 必须支持的检查类型
|
|
- build
|
|
- test suite
|
|
- lint / type-check
|
|
- 接口调用验证
|
|
- UI 自动化验证
|
|
- CLI 输入输出验证
|
|
- migration 验证
|
|
- adversarial probe
|
|
|
|
## 4. 输出格式需求
|
|
|
|
验证结果必须满足：
|
|
- 有检查项标题
|
|
- 有实际执行命令
|
|
- 有真实输出
|
|
- 有 PASS / FAIL / PARTIAL 结果
|
|
- 最后有统一 verdict
|
|
|
|
## 5. 为什么需要 adversarial probe
|
|
|
|
只验证 happy path 会导致大量问题漏检。因此系统要要求验证阶段主动尝试：
|
|
- 边界输入
|
|
- 并发场景
|
|
- 空输入 / 非法输入
|
|
- 重复请求
|
|
- 不存在资源引用
|
|
|
|
## 6. 为什么验证必须可追溯
|
|
|
|
如果验证没有命令和输出，用户无法判断：
|
|
- 到底测没测
|
|
- 测了什么
|
|
- 失败在哪
|
|
|
|
因此，质量系统必须要求“证据化验证”。
|
|
|
|
## 7. 质量保证不只是测试
|
|
|
|
这套产品的质量保证包括：
|
|
- 提示词中对诚实汇报的要求
|
|
- 验证角色的独立存在
|
|
- 执行链的日志与 transcript
|
|
- 失败可追踪
|
|
- 结果可复盘
|
|
|
|
## 8. 伪代码表达
|
|
|
|
```python
|
|
class VerificationRunner:
|
|
def verify(self, task, changed_files, context):
|
|
checks = build_verification_plan(task, changed_files)
|
|
results = []
|
|
for check in checks:
|
|
cmd = check.command
|
|
output = run(cmd)
|
|
results.append(evaluate(output, check.expectation))
|
|
return summarize_verdict(results)
|
|
```
|
|
|
|
## 9. 产品经理视角下的总需求句
|
|
|
|
> 产品必须把验证设计成独立、对抗性、证据化的质量系统：它不依赖实施者自我声明，而是通过命令、输出与统一 verdict 来证明任务是否真正完成。
|