指标一挂钩，填报动作先被优化
有工程师被要求两成工单必须走AI。他的处理方式很省事：挑两成打上标记，交差。德米特里·斯帕诺斯在访谈里复述这件事时带着无奈——代码写得好，不如AI用得好。
这不是孤例。绩效一旦和填报绑定，最先被优化的永远是填报本身。史蒂夫·黄把它和当年的代码行数考核并置：一个循环展开成几十行，产出数字立刻膨胀，软件却更难维护。今天统计对象换成Token消耗、AI工单占比，规则没变，只是筹码换了。
史蒂夫盯的是交付物。调用了多少次、烧了多少预算，只说明成本侧发生了什么，说明不了问题有没有被解决。
评审席上，两种赢家
代码评审能直接暴露这种错位。一次Agent调用吐出几百行补丁，最终合并十几行；另一项任务几乎没生成代码，却定位到一条导致故障的错误配置。按调用量排名，前者赢；按故障是否消除、是否引入新风险判断，答案反过来。
德米特里不反对工程师用Agent，他质疑的是识别高绩效的方式。长期做安全与密码协议的工程师，很难在保持审慎的前提下按公司要求套用AI。他认识不少处境类似、最后选择离开的人。
这里有个常被忽略的技术事实：模型产出的代码语法层面通常很干净，问题藏在语义层。符号写反、浮点边界处理不当、并发路径漏锁，这些缺陷跑一遍单元测试未必暴露，输出有时还”看起来正常”。所以读代码不能停留在通读，得配合可执行的检查。
比较务实的做法是三层兜底。第一层是类型系统与静态分析，mypy --strict、clippy、golangci-lint 能在合并前拦住相当一部分低级错误。注意版本行为差异：mypy 1.8 起 --strict 会启用 disallow_untyped_defs 等全套检查，而 mypy 1.8.0 对 Python 3.12 的 PEP 695 泛型语法支持不完整，会误报，需升到 1.10 以上。第二层是变异测试，用 mutmut 或 PIT 往代码里注入人工缺陷，看测试能否杀掉。判定标准可以量化：存活变异体比例低于 5% 才算覆盖有效，杀不掉说明覆盖是假的。第三层是差分测试，同一输入分别跑旧实现和新实现，比对输出。三层都过，才谈得上”我审过了”。
新人交得了差，未必判得了局
德米特里没有劝年轻人远离AI。他观察到一些初级工程师已把大量编码交给模型，自己负责审查和修改——这是个人观察，不是普查数据。
问题出在下一步。新人接的任务范围小，修好Bug、测试跑绿就算交付。几年后要决定是否迁移一门语言、引入一个服务、改动跨系统的数据流，答案不再藏在单个测试结果里。
拿一次接口改动举例。Agent能补代码、写测试，但接任务的人至少得清楚：这个接口被哪些客户端调用、失败后能不能重试、改动会不会碰到历史数据。这些不清楚，测试全绿也可能只是把雷埋到上线之后。
德米特里自己的做法偏保守，逐段读AI写的代码，尤其盯数值计算。更一般的要求是弄清系统由哪些部件组成、数据库结构长什么样、出问题时从哪一处下手。连子系统和表结构都说不清的人，很难控制Agent交付出来的应用。
清空积压工单前，先问它们为什么积压
访谈里提到有人让AI批量处理积压的Jira工单。技术上确实诱人：以前排不上开发资源的任务，现在似乎都能丢给Agent。
德米特里问了一句：这些工单为什么在待办列表里躺了这么久？有些是太难，有些只是一直没那么重要。成本下降会改变优先级排序，但工单被关闭，不等于用户拿到了同等价值。
史蒂夫的年度规划例子更直白。团队想做35个项目，人手只够做前10个。AI也许能把第11、第12个拉过线，也能把白板上的想法做成可点击的原型。但排第35的那个，通常有它排在那儿的理由。
从工程角度看，批量自动化有明确的适用边界。适合交给Agent的工单通常满足几条：有明确的用户、验收条件可以写成断言、改动局限在单一服务内、失败可回滚。反过来，涉及跨系统数据迁移、权限模型调整、对外协议变更的工单，即便看起来是”小改动”，也不该让Agent独立——这类改动的失败模式是静默的，测试通过不代表线上安全。
真要试，先在隔离环境验证。用 docker compose 起一套带生产数据脱敏副本的沙箱，让Agent在分支上跑，合并前用 git diff --stat 核对改动范围是否超出预期，再跑一遍集成测试。回滚方案必须提前写好：数据库迁移要有对应的 down 脚本，配置变更要走可回退的发布通道。常见坑是只写了 up 迁移、没写 down，回滚时执行 alembic downgrade -1 直接报 Can't locate revision identified by 'xxxx'，根因是版本表里残留了已删除的迁移记录，得先手工修正 alembic_version 表再降级。没有回滚路径的自动化，等于把风险单向下压。
工作流半年一变，别浇进地基
访谈末尾谈到各种Agent编排框架。几个月前流行的流程，如今模型、工具、协作方式已经换了一轮。德米特里愿意投入资源试验，但不会把团队未来押在某套流程上。现在就认定AI工作流已经稳定，为时过早。
有三件事值得长期留在流程里，且不依赖任何一家工具：任务开始前写清验收条件；Agent完成后核对改动与测试；上线前确认影响范围和回滚办法。这三步守住，”用得更多”就不容易悄悄替代”做得更好”。
成本账要算全
评论区有人给出一个可讨论的估计：团队产出提升约两成，即便增加模型预算也可能划算。但他提醒，技术债、安全事故和法律责任会在后面把短期收益吃掉。
另一位站在审查一边：今天还能读代码，已经算保守了吗？更远的担忧是，模型生成的代码越来越多，团队再用模型去审模型，最后没人真正清楚系统里发生了什么。
这些争论最终落回日常：预算涨了多少、代码谁读、出了错谁先发现。
用真实任务做对照，别用漂亮数字下结论
让Agent多干活值得试。但”用了多少AI”不该成为唯一成绩单。
更可靠的办法是拿一类真实任务做前后对照：交付时间缩短多少、线上故障率有没有上升、值班工程师还能不能讲清系统怎么运转。数字不必好看，得能支撑下一步决策——该扩大范围，还是该收回来重做验收标准。
ID:7061
