业内实战对照
实践 / 建议业内一手实战：能复用什么，不能照搬什么
对照公司已有工作
| 一手案例 | 原文核实的做法 | 公司对应资产与推荐动作 | 适用限制 |
|---|---|---|---|
| Stripe Minions Part 2 | 可替换 devbox；blueprint 混合确定性节点与 Agent；按范围加载规则；有限 CI 反馈 | 部门 VM + Golden Path：补可重建环境，让必需检查/推送/预算由代码保证 | Stripe 已有成熟开发基础设施与大规模测试；不能只复制无限权限或启动速度 |
| Spotify Honk Part 2 | 泛化或过细提示均会失败；写前置条件、目标和样例；单次一个变化，约束工具 | 项目接入卡+任务合同；code-search 在准备阶段收集，编码阶段只给必需能力 | 其迁移 Agent 主动限制动态知识工具；公司诊断任务仍需动态查询 |
| Spotify Honk Part 3 | 独立 verifiers 封装构建测试、摘要反馈；LLM judge 查越界；失败阻止 PR | IDP/Egress 验证适配+独立评审，业务套件与证据判定统一 | 原文承认 judge 尚缺正式 eval；当时验证只覆盖 Linux x86，不能代替 iOS/ARM |
| Spotify Honk Part 4 | 先查依赖与目标仓；字段映射表补上下文；放弃过于异构的 Scio 范围 | AppFramework/metadata/SFA 先核实依赖与契约映射；500 仓按能力分组 | 无构建期测试的迁移依赖维护团队人工验证，不能当端到端自主成功 |
| Uber JUnit migration | 先支持新旧 runner 共存；OpenRewrite 前置过滤、recipe、CI、增量 rollout | 存量 Java 改造先建兼容基础与确定性工具，Agent 分析例外 | 原文明确批量生成式 AI 改写未成功；AI 仅辅助调试失败 |
| Anthropic 长任务 harness | initializer、特性清单、进展文件、Git、逐项增量、端到端验证 | init/bootstrap + Multica 持久任务 + 远端 SHA；每轮检查基线和未完成 验收标准 | 案例偏全栈 Web；“禁止改测试”的提示不是执行隔离，跨 runtime 不能只靠本地文件 |
外部经验共同指向的投入
第一，确定性基础设施价值会随着 Agent 数量增加而放大：环境、目录、规则、测试和反馈原本也服务于人。 第二，缩小单次任务与工具范围，提前明确“不适用”的条件，比让 Agent 处理所有例外更容易规模化。 第三，验收结果必须独立于模型的完成声明；CI 绿灯还要看行为与覆盖。 第四，异构性和无测试会直接限制自主程度，需要接受人工残余工作并逐步补工程能力。
DORA 2025 介绍页关于 AI 放大组织已有能力的结论，与上述案例相互呼应； 这里没有把外部 PR 数、估算工时或测试规模转换为公司 ROI。 Anthropic 的 evals 资料还强调 outcome 与 trace、不同 grader 和回归评测的区别， 适合补强 bug-finder 现有评测，而非把所有评测合成一个得分。