MISSION · AI-NATIVE SOFTWARE ENGINEERING
测试全绿，不等于可以合并。
你是最终对 Merge 负责的工程师。
一个 Agent 实现了缓存优化并新增了依赖。现有测试全部通过，但生成的改动绕过了事务边界，还修改了与需求无关的文件。快速接受这份 PR 很容易，真正理解它却很昂贵。
目标
在控制审查成本的同时，把回归风险与架构漂移降到可接受范围。
风险
如果这个隐藏的边界问题上线，事务成功后系统仍可能向用户返回过期状态。
Vibe Coding × Evaluation·应用 Mission·14 分钟
这份 AI 生成的 PR，你会合并吗？
你的 Coding Agent 修改了 17 个文件。CI 全绿，Diff 也看起来合理，但仍有一个架构边界被破坏。你需要判断：这些证据足够支持合并吗？
一句话理解
AI 生成代码应该依据明确的变更契约、仓库架构、针对性测试和依赖证据来判断，而不是依据 Diff 看起来是否像正确答案。
正在加载 Mission Engine…
关键要点
先 Spec，后生成
有稳定目标，才能判断 Agent 是解决了问题，还是只生成了看似合理的代码。
测试只是有限证据
CI 全绿只证明当前测试覆盖到的内容。
重点审查边界
最昂贵的回归往往来自数据、架构和运行边界被生成代码破坏。
ENGINEERING DEBRIEF
真正的审查对象是系统契约，而不是生成出来的 Patch。
测试通过是证据，不是生成代码适合进入仓库的证明。
AI Coding 压缩了实现时间，也扩大了验证责任。更可靠的流程应该先限定需求范围，检查架构不变量，为新增行为和高概率失败模式建立测试，再审查依赖变化。这样，AI Code Review 才从“看起来没问题”变成可追溯的证据过程。
- ✓先写变更契约，再判断 Agent 是否真的解决了目标问题。
- ✓审查行级 Diff 之外的仓库级架构不变量。
- ✓根据风险生成测试，而不是只覆盖 Happy Path。
- ✓把新增依赖当成架构决策的一部分。
LEARNING CONTEXT
可复用的 Mental Model
测试通过是证据，不是生成代码适合进入仓库的证明。
未看过
本次练习的 CONCEPT
- concept-specification-before-generation先定义 Spec，再生成
- concept-ai-code-reviewAI Code Review
- concept-test-first-ai测试是可执行的验收证据
- concept-evaluation-evidenceEvaluation Environment 与 Verifier Design
建议补充前置
进入这起事故前，没有必须完成的已发布前置内容。
迁移这个模型
从生成代码转向生成结论：建立一条能说明‘为什么应该相信这句话’的研究证据链。