Steve Tarcza 刚听完一场把 AI 吹成"魔法"的主题演讲，转身就给我们泼了盆冷水——他管着亚马逊零售业务的技术团队，手里握着一套叫 Kiro 的 AI 编程工具，但铁律只有一条：没有人工检查，代码绝不上线。

魔法叙事 vs 工程现实

打开网易新闻 查看精彩图片

AWS 伦敦峰会的主舞台上，副总裁 Alison Kay 刚讲完一个励志故事：六名工程师用 Kiro 在 76 天内重写了 Bedrock 推理引擎，AI 代理"在他们睡觉时继续写代码、测 bug、修问题、全天候部署"。

台下掌声还没散，Tarcza 在后台接受 The Register 采访时换了个调子。

「我们必须继续培养人才，不能让初级工程师断层。不能最后落到没人维护系统的地步。」

他管的是 StoreGen 团队，服务对象不是 AWS 外部客户，而是亚马逊自家零售网站和运营系统的内部开发团队。这个定位让他必须对"魔法"保持警惕——零售系统的故障直接关联订单和钱。

Kiro 的真实边界

Kiro 的核心卖点是"规格驱动开发"（spec-driven development），今年 7 月首次预览。流程是：AI 先根据需求生成任务清单，人类审核通过后再动手写代码。

这能解决幻觉和提示注入攻击吗？

「不能，」Tarcza 直说，「最多是减少。即便如此，还是有情况会超出规格范围。」

他列举的 AI 失控场景很具体：幻觉、突破护栏、甚至"做你没让它做的事，比你要求的走得更远"。去年 Kiro 疑似卷入过一次服务中断，官方否认，归因于员工操作失误——但这类传闻本身就说明信任度有限。

安全机制：人必须在回路中

Tarcza 给出的解决方案没有技术黑话，全是组织层面的硬约束：

工程师必须始终审查输出。没有人工验证，代码不能上线。

规格驱动开发的价值在于压缩审查时间——AI 先把代码整理成人类习惯的形态，减少返工。但"减少"不等于"替代"。

这个立场在当下显得格格不入。AWS 自己也在裁员工程师，行业叙事是"AI 让团队瘦身"。Tarcza 明确反对这个方向：

「如果放任不管，你描述的那种结果（无人审查的代码上线）确实可能出现。我认为那是错误的结果……」

他的担忧很实际：如果公司裁掉 junior 工程师，未来谁来看 AI 写的代码？谁能在 AI 越界时喊停？系统维护的人才从哪来？

为什么这套逻辑值得科技从业者琢磨

亚马逊零售业务的体量决定了它的保守不是迂腐，而是算过账的。一次推荐算法故障可能让销售额波动数亿美元，物流系统的 bug 会直接瘫痪履约网络。这种场景下，"魔法"的容错率为零。

Tarcza 的表态揭示了一个被峰会 PPT 掩盖的事实：AI 编程工具的落地瓶颈不在技术能力，而在组织信任机制。规格驱动开发、人工强制审查、人才梯队保留——这三件事没有一件是算法能自动解决的。

对于正在评估 AI 开发工具的团队，这个案例的价值在于区分"演示效果"和"生产就绪"。Bedrock 引擎 76 天重写的奇迹可以讲给投资人听，但你的团队是否建立了对应的审查流程？是否有足够的人力储备？AI 越界时有没有刹车机制？

这些问题没有标准答案，但 Tarcza 至少划了一条红线：别在没想好怎么把关之前，就把方向盘交给 AI。