AI 原型快速交付前，先设退出与加固条件

AI 编程代理能把概念验证（PoC）做得很像成品，却不会自动补齐上线条件。作者的核心主张是：开工前先确定要验证的问题、截止时间和通过标准，过程中隔离环境、记录捷径，结束后明确决定停止、重建还是加固。

这篇值得读的地方，在于提醒团队防住一次常见滑坡：演示成功后，原本用来回答问题的代码，被顺手当成了产品基础。做得快不是问题，没人决定它何时结束才是。

PoC 要回答问题，而不是展示功能

「做一个 AI 客服助手原型」看似明确，其实没有判断终点。界面能聊天、回答听起来合理，就算成功了吗？

作者给出的更强表述是：助手能否正确解决上个月真实账单问题中事先约定的比例，同时把每次对话的成本控制在可接受范围内？

这里没有给出具体通过率和成本数字，因为阈值需要团队自己定。关键是把「看起来能用」改成可检查的结果。历史问题可以作为评测来源，但涉及客户信息时，仍要遵守后面的脱敏和安全要求。

作者将自己的 AI 实验推进生产时，发现代码助手、提示词工具和自动化脚本确实减少了部分任务、文档与样板代码的工作量，但整个系统改善有限：流程仍然串行，角色之间的依赖仍会造成等待，输出质量也不稳定。

生产阶段暴露出四类问题：输出是否可靠，相同输入能否得到可重复的结果，产物能否接入 Jira、CI/CD 等现有工具，以及谁负责长期维护。

PoC 没有测过的能力，演示成功也不能替它证明。

如果要验证的是回答质量，就不能拿页面完成度交差；如果要验证工作流效率，单个任务变快也不足以说明团队交付变快。

七条规则，给快速试错划出边界

作者建议在开发前后落实七件事：

1. 先约定截止日期，到期就根据已有证据做决定。
2. 提前写好通过与失败标准，避免被演示效果带着走。
3. 默认使用合成或匿名化数据；确实离不开真实客户数据时，把它作为安全决策处理。
4. 使用独立环境和独立凭证，不给生产系统写权限。
5. 每走一次捷径就记一行，包括硬编码、跳过的检查和模拟的集成。
6. 在仓库名称和界面上明确标注 PoC，防止被误认为正式产品。
7. 指定一名负责人，对最终去留负责，无论代码由人还是代理编写。

其中最容易被忽略的是「捷径日志」。它不需要复杂格式，重点是开发时随手记录，留下可供复查的事实。否则演示结束后，团队很难区分哪些功能已经实现，哪些只是让流程暂时跑通。

这份日志可以帮助估算加固工作，也能告诉审查者先看哪里。不过，它能否形成可靠的成本估算，原文没有提供数据。

哪些可以交给代理快做，哪些必须认真验

作者的原则是：对被验证的部分严格，对其他部分适当放松。

脚手架、桩代码、示例数据和一次性页面，都适合让代理快速生成。它们承担的是搭起实验环境的任务。真正决定结论的逻辑和评测，则需要更谨慎。

例如，验证 AI 回答质量时，界面可以简陋；但测试问题、正确答案的判断方式和失败案例不能敷衍。若同一个代理既写实现又写评测，测试通过可能只是双方共享了同一个错误假设。

作者要求由人定义测试用例，并同时检查失败案例和分数。他还提到，自己使用开放式代理的尝试失败了；表现较稳的代理都有明确角色、结构化输入输出，并由人验证结果。这是作者的实践观察，原文没有交代模型、任务规模或对照实验。

PoC 到期后，应该开一次短会，选择停止、重建或加固。作者认为，有了编码代理，按已经验证清楚的设计重新生成代码，有时比拆解一个客户已经依赖的演示系统更便宜。但「更便宜」同样没有量化证据。

如果选择上线，代码必须进入正常审查流程。捷径日志中的每一项都要关闭，或由具名负责人明确接受；涉及支付、权限和客户数据的部分，需要深入审查。

我的判断

我赞同作者把问题定义和退出决策放在开发速度前面。AI 生成的界面越完整，团队越容易把视觉完成度误当成工程完成度。独立环境、明确标签和捷径日志，都是成本较低的约束。

但「重建通常更便宜」应当按经验之谈看待。原文没有比较重建与渐进加固的工时，也没有说明代码规模和集成复杂度。已有实现留下多少有效资产，仍要具体检查。

另外，原文提到了可以「伪造」的部分，却没有给出完整的可跳过事项清单。不能据此认定某类检查都能省。判断依据应是：省掉它之后，实验还能不能回答最初的问题。

演示通过，只能支持事先定义过的结论。

能拿来做什么

• 开始做 AI 功能验证前，先写下一个问题、通过标准和截止日期；如果预计需要数月，先拆出风险最大的那个问题。
• 用代理搭建前端演示或 Node 脚本时，同步记录硬编码、模拟接口和跳过的检查，并在仓库与页面上标明 PoC。
• 由人准备评测用例，检查失败样本；如果目的是验证团队流程，就把现有工具接入和角色间等待也纳入观察。
• 演示结束后立即决定停止、重建或加固；选择上线时，让捷径日志随代码一起进入正式审查。