TL;DR：AI 普及后，研发瓶颈从「编码」转向「验证」，工程重心应转向用确定性手段约束概率输出。本文干货集中在技术机制层面，价值层多为共识性感慨，可信度中等偏上；但缺少成本结构与失败案例。建议：盘点 CI 反馈时长、清理伪测试、检索 AI Coding 失败案例作对冲。

一、背景与语境

这是一篇 InfoQ 的圆桌访谈，主题是"AI Coding 普及后，研发效能该如何重新衡量"。受访者是多位一线技术负责人（访谈原文未逐一署名，个人具体立场无法判断），场景是 AI 已从代码补全进化到能理解代码库、执行任务、参与 Code Review 之后，团队普遍遭遇的一个困惑：代码产出明显变快了，但研发效能指标却越来越说不清。
值得关注的原因在于，这类访谈大多停在"AI 是不是会取代程序员"，而这一篇把问题往前推了一步：**当代码生产不再是瓶颈，工程上真正稀缺的是什么？**这个提问角度比结论本身更有价值。

二、最有价值的三个观点

**其一，瓶颈从"编码"移到了"验证"。**这是整篇访谈最扎实的判断。它的支撑不是情怀，而是一个机制性论证：AI 是概率系统、必然产生幻觉，而在大型工程中错误会被指数级放大。于是工程重心的转移是必然的——从写代码，转到用确定性手段（架构约束、CI、契约测试、上下文治理）把概率输出收拢成可信交付。
其二，"确定性工程"是约束 AI 的落点。访谈提出用确定性工程约束 AI 行为、让它遵循正确的工程实践。这个提法的新意在于视角切换：不是让 AI 更聪明，而是给一个不稳定的执行者套上稳定的框架。它把 AI 视为"需要熟悉项目的顶级工程师"，因此要为它补上下文而不是替它思考。
**其三，测试从独立环节回流进编码过程。**受访者判断研发与测试的分离范式会转向测试驱动，大部分测试工作融入编码。它的逻辑链清晰：AI 需要反馈循环才能自我验证，而可执行断言就是最廉价的反馈接口。

三、可信度分析：干货与场面话

干货集中在技术机制层面。“幻觉必然被放大”“测试作为 feedback loop”"多 Agent 编排拆解大需求"这几处，都有可推演的因果，不是空话。“白盒单测价值低、契约测试价值高"这类具体判断，也来自一线手感。
**场面话则在价值层。**比如"大型软件工程最稀缺的是可被信任的交付能力”“靠谱的人、靠谱的小团队”——方向不错，但更像共识性感慨，缺乏可操作内容。它们是否只是访谈者的舒适表达，无法判断。

**提问质量中等偏上。**问题切到了关键矛盾（效率与确定性的张力、AI Code Review 的误报与漏报），但对于"如何落地"始终停在受访者口述层面，没有逼问具体案例或数据，导致全文缺一个可验证的锚点。

四、遗留问题

**文中提到但没展开的：**多 Agent 编排在真实大型代码库中的冲突率与上下文窗口限制，访谈提了概念却没给工程细节；移动端真机与 Agent 环境割裂的问题，只指出困难，没给解法。

本该涉及却缺失的：一是成本结构——AI 编码的 token/算力成本、以及验证环节的人力成本，全文未提；二是反面证据——有没有团队试过却失败的案例？通篇是正面判断，缺少反例让结论显得单向。这个缺口重要，因为"测试揉进编码"这类范式转移，现实中大概率会先经历一段混乱期，而访谈对此保持沉默。

五、对开发者的价值

值得读，但要带着怀疑读。它的实用价值不在结论（结论多为方向性共识），而在于提供了几个可自检的问题：你的团队瓶颈是不是已经从编码移到了验证？你的测试是契约还是实现复述？你的 CI 能否撑起分钟级的 Agent 反馈循环？

**三个可跟进的动作：**其一，盘点一下自家 CI 的反馈时长，这是 AI 提效的地基；其二，检查现有单测里有多大比例是"改了实现就得同步改测试"的伪测试；其三，主动去检索一遍 AI Coding 落地失败或踩坑的公开案例，用作对本文正面叙事的对冲。