德米特里·斯帕诺斯：“I just pick 20% and call it AI.”
德米特里·斯帕诺斯：公司要求至少20%的工单用AI完成，那位工程师就挑出20%，标上“用了AI”，然后交差。
史蒂夫·黄：“Ultimately, what we care about is outputs.”
史蒂夫·黄：我们最终在意的是交付结果
一位工程师被要求至少用AI完成20%的工单。德米特里·斯帕诺斯在访谈中转述了他的应对：选出20%，标上“用了AI”，交差。
这个数字但凡在公司填过“效率提升”报表的人，大概能立刻听出其中的别扭。
AI确实能让工程师写得更快。
德米特里·斯帕诺斯无奈的表示，代码写的好，不如AI用的好。
史蒂夫·黄担心的是，团队如果只数使用率，就会得到一份很好看的使用率，而未必得到更好的软件。当年统计代码行数时，工程师可以轻易写出更多行，却没有解决更多的问题；如今，工单上的“AI参与”也可能变成同一种数字游戏。
备注：史蒂夫曾在亚马逊担任首席工程师。是《A Life Engineered》访谈的主持人，嘉宾德米特里是有多年AI和机器学习实践经验的研究者。
两人谈到新人怎样成长、资深工程师怎样审查模型产出，还谈到一个颇有诱惑力的主意：让Agent把积压工单一口气清空。
以下为访谈内容，我们进行了翻译与整理。
德米特里谈“为了拿到奖励而报告使用AI”
工单上写了AI，不等于问题解决得更好
史蒂夫先说了他的观察：如今会用Agent、能控制其工作范围的工程师，往往更容易得到认可。
德米特里没有反对这点。他担心的是，公司开始用“有没有用AI”识别高绩效时，那些做得很好、但不愿在高风险任务里草率套用AI的工程师，会被看成落后者。
他举了一个假设：长期负责安全、密码协议的工程师，可能无法按公司要求的方式使用AI，同时保持这份工作所需的审慎程度。德米特里说，他认识很多处境相似、最终选择离职的人。
那位把20%工单标成“用了AI”的工程师，则说明了指标的另一面。只要奖励取决于填报，填报行为就会先被优化。
史蒂夫想起了代码行数考核。一个循环可以展开成很多行，产出数字立刻变大，软件却更难维护。把统计对象换成Token消耗或AI工单占比，问题仍然存在。
史蒂夫·黄：代码行数和Token消耗都只能说明投入了多少。判断工程师有没有提高生产力，还得看最后交付了什么。
史蒂夫将AI使用指标与过去的代码行数考核作比较
做代码评审时也能看到这种差别：一次AI调用可能写出几百行补丁，最后只留下十几行；另一项任务几乎没生成代码，却找到了导致故障的错误配置。按调用量排名，前者赢了。按故障有没有解决、有没有引入新风险来判断，答案可能相反。
新人今天能交差，几年后还会判断吗
访谈聊到初级工程师时，德米特里没有劝他们远离AI。他接触的一些年轻工程师，已经把大量编码交给模型，自己负责审查和修改。这是他的个人观察，不是针对所有开发者的调查。
他担心的是下一步：新人手里的任务通常范围小，修好Bug、跑绿测试，就能交付。等到几年后要决定是否迁移一门语言、引入一个服务，或修改跨系统的数据流，答案不再藏在单个测试结果里。
德米特里·斯帕诺斯：初级任务通常范围小，做成没做成比较容易判断。他担心新人如果跳过基础训练，几年后面对更复杂的决策，就难以判断AI给出的答案是否可靠。
德米特里担心新人跳过基础训练后，未来难以评估复杂任务的结果
这并不是让新人纯手写代码。
拿一次接口改动来说，Agent可以补代码、写测试；接任务的人至少得知道接口被哪些客户端调用、失败后能否重试、改动会不会碰到旧数据。否则测试都通过了，也可能只是把问题留给上线之后。
德米特里自己的做法相当保守：他会读AI写出的代码。他尤其在意数值计算中的小错误，一个符号或浮点处理不对，表面输出有时也能“看起来正常”。更一般的要求，是弄清系统由哪些部分组成，数据库结构在哪里，出问题时该从哪一处调整。
德米特里·斯帕诺斯：我属于会逐段读代码的那一派。
德米特里举例说明：如果连子系统和数据库结构都不清楚，工程师很难控制Agent交付的应用
一千张旧工单清空了，谁来用这些功能
德米特里还听到有人让AI批量处理积压的Jira工单。技术上这很诱人：以前排不到开发资源的任务，如今似乎都可以交给Agent。
他问了一个扎心的问题：这些工单为什么会在待办列表里待这么久？有些是因为太难，也有些只是一直没那么重要。成本下降，当然会改变优先级；但工单被关闭，不代表用户因此得到了同等价值。
德米特里·斯帕诺斯：它们为什么一直留在待办列表里？
德米特里质疑，批量清理积压工单的价值能否等同于完成高优先级项目
史蒂夫举了年度规划的例子：假设团队想做35个项目，现有人手只够做前10个。AI或许能把第11个、第12个项目拉过线，也能把原本只画在白板上的想法做成可点击的原型。但排第35的项目，通常有它排在那里的原因。
这给开发团队一个很实用的筛选办法：先挑有明确使用者、可以验证结果、以前确实卡在开发成本上的任务试AI。别把“积压已清零”当作产品价值的证明。
工作流半年一变，别把它写进团队的地基
访谈最后，德米特里谈到各式Agent编排框架。几个月前大家还在讨论一种工作流，如今模型、工具和协作方式已经变了一轮。他愿意投入资源试验，但不会把团队未来押在某一套流程上。
德米特里·斯帕诺斯：“a stable workflow pattern”
德米特里·斯帕诺斯：现在就认定AI工作流已经稳定，还太早。
德米特里谈AI工作流变化很快，不宜把某种编排方案当作长期定式
团队可以频繁换模型、换工具，但有三件事最好一直留在流程里：1.任务开始前写清验收条件；2.Agent完成后检查改动和测试；3.上线前确认影响范围与回滚办法。
这些步骤不依赖某一家工具，也能防止“用得更多”悄悄取代“做得更好”。
开发者们发声：成本是个问题，可能没人再读代码
一位留言者觉得，团队产出提高约20%是可以讨论的估计；即便增加模型预算，也可能划算。但他提醒：技术债、安全事故和法律责任，可能在之后把短期收益吃掉。
另一位留言者站在审查一边：今天能读代码，已经算“保守”了吗？还有人担心，当模型生成的代码越来越多，团队会再用模型审查模型，最后没人真正弄清系统里发生了什么。
它们把访谈里的争论推到了日常工作：预算涨了多少、代码谁读、出了错谁发现。
写在最后
让Agent多做事，当然值得试。只是别让“用了多少AI”成为唯一成绩单。
更可靠的做法，是拿一类真实任务比较：用了AI以后，交付时间缩短了多少，线上故障有没有增加，工程师是否仍能说清系统怎样运行。数字不必漂亮，得能帮团队决定下一步该改什么。
参考链接：
https://www.youtube.com/watch?v=DF5M5CJi9sM
——好文链接——
开发者低估了AI的能力！Claude工程负责人：用旧方法指挥Agent，开发者们反倒成了“传送带”
AI为什么越聊越容易犯错？Every评估负责人：旧的上下文，正在带偏你的 Agent
