候选人在系统设计题上卡住了，停顿了两秒说：“我直接写个提示词（Prompt）就行。”你资历最深的面试官写下：强烈推荐录用——这正是 2026 年优秀工程师的工作方式。你资历第二深的面试官写下：不予录用——把问题丢给聊天机器人不叫工程。同样的五个字，同样的 40 分钟面试，同一张评分表上出现了 40 分的巨大差距。
候选人并没有搞砸你的面试环（Interview Loop），是你的面试环缺乏明确的观点。复盘会中最糟糕的部分不是分歧，而是每个面试官都如此确信自己的判断是正确的，以至于会议演变成了对 AI 本身的立场投票，而不是讨论这个人是否具备交付能力。
客户将智能体的回答粘贴到支持聊天中，并要求人工代表进行确认。代表看着同一款产品，却给出了相反的说法。那天，客户并没有对智能体失去信心。他们是对公司失去了信心，因为公司的两个部门在同一个小时内告诉了他们两件截然不同的事情。
一切都没有出错。AI 团队在周二通过特性标志（feature flag）发布了一个提示词更改，到周四已推行至 100%，然后便继续下一项工作了。客户成功（CS）团队的赋能周期是按月进行的 —— 以前每个产品特性都是这样落地的，而且没人针对 AI 重新协商这一流程。CS 代表队列中的宏（macro）和公共网站上的 FAQ 文档描述的仍然是之前的行为。智能体是对的。代表根据他们掌握的文档也是对的。但公司表现得各说各话。
事后分析报告（post-mortem）会说“我们发现安全问题太晚了”。但实际的调查结果应该是：安全团队发现你的时间很准时，是你的流程发现安全问题太晚了。
这是一个在 1 月份就通过了预算审批的 AI 功能，因为 CTO 和 CFO 都认为公司需要一个“AI 高光时刻”。3 月份它通过了初步的法务审查，因为当时还只是一个原型。整个第二季度，工程团队都按照商定的规范进行开发。7 月底，发布前的安全审查启动了，结果第一天威胁模型（threat model）就反馈了阻碍性问题：身份验证范围（auth scopes）、数据泄露路径、模型供应商的数据驻留（residency）政策，以及提示词注入（prompt-injection）的攻击面。团队整个季度的时间现在都花在了重新架构上，以解决那些本该在最初规范中就被明确的问题。两个季度的进度延迟，一份关于“流程改进”的高管备忘录，以及在下一个规划周期中悄然决定“降低 AI 深度集成的优先级”。
发布失败并不是因为安全团队动作慢，而是因为安全团队在功能形态已经固化之后才介入。
你画了一个包含六个季度的 AI 路线图。模型切换、新数据源、多语言发布，以及现在提供建议的提示词，在甘特图上各占一行，并根据工程量的大小确定了尺寸。接着，第一次发布推迟了四周，而复盘报告在三个不同的章节里重复了三次同样的话：“正在等待法务。”路线图原本假设工程能力是关键限制。而实际的瓶颈约束是一堆法务审查队列，每个审查都有自己三到六周的 SLA，且彼此互不知晓，最终全都压在仅有的两名产品法务身上。
错误并不在于任何一项单独的审查。每一项都是有理有据的。错误在于将四个并行功能视为四个并行的时间线，而它们的法务依赖却通过同一个上游资源进行串行处理。到第二次延期时，组织了解了问题的轮廓。到第四次时，它学会了针对此进行规划。那些能够以可预测节奏发布 AI 功能的团队，已经不再将法务吞吐量视为外部的意外，而是开始将其视为与人力和基础设施容量同等地位的规划输入。
团队上午十点开站会。第一位工程师开始汇报他的 Agent 们昨晚完成了什么——只是,早上七点启动的评测套件还没跑完,Agent 凌晨三点开的那个 PR 正在等另一个 Agent 评审、而后者的队列深度无人知晓,长跑的重构 Agent 已经进入第十一个小时(预估是四小时),既没有卡住的信号、也没有健康的信号。昨天的状态既不是"已完成",也不是"进行中"。从会议室里看,昨天的状态根本无从得知。
站会本来是一种为同步人类工作量身定做的同步仪式。每个人做一件事、完成它、睡一觉、第二天早上汇报。工作的最小单位是一个工作日。汇报的最小单位是一个人。节奏匹配的是底层介质。现在这些前提全都不成立了。今天工作的最小单位是一次 Agent 运行,它在你上床前就启动了,可能在会议进行中或会议后三小时收工。汇报的最小单位是一支集群,而不是一个人。而那个节奏——上午十点准时开始、9 到 15 分钟一轮的轮流播报——是底层介质根本不会按这个频率产出事件的节奏。
你最强的 AI 工程师在这个周期里整理了一个 eval 集、校准了一个评判提示词、并且砍掉了两个最终被证明任务形状不匹配的功能。这些工作没有一条能够塞进评估模板里。于是校准会议要么夸大该工程师最不在乎的产物——PR 数量、设计文档、值班时长——要么编织一段散文来给一个框架根本无法支撑的高评级辩护。无论哪种方式,评分标准和现实正朝着不同的方向拉扯,而这位工程师心里有数。
这套模板是为确定性软件而写的。它奖励那些你能数得过来的东西:发布了多少行代码、拥有多少服务、解决了多少个事故、值班了多少个小时。而 AI 路线图是被另一种形状的工作推进的:整理一个有代表性的 eval 切片;在模型漂移下守住一个行为包络;拒绝发布一个任务形状不适合模型的功能;耐心地缩小评判提示词和人类意图之间的差距。这些工作几乎都不产出评分标准所擅长计算的那种产物。
公司里的某个地方，四个人各自都相信第五个人在管推理账单。工程把它当成云账单的一项。AI 团队把它当成做产品的成本。财务把它当成毛利率的可变输入，默认工程那边已经在管了。产品把它当成工程吸收的间接成本。账单一直在涨，唯一达成共识的是：这账不是我的。
这不是预算问题，而是所有权真空。它第一次浮出水面，往往是因为这条线大到 CFO 在董事会上点名问起。到那时，大家临时拼凑的回答——"我们会优化"、"我们会多做缓存"、"我们会换模型"——描述的是干预手段，却没有指出谁负责。本该在一年前发生的对话，并不是怎么把账单压下去，而是这笔账究竟属于谁的损益表。
这是结构性的变化。推理在企业 AI 支出中的占比，从 2024 年的 15% 涨到 2026 年的大约 85%；同一时间窗口里，企业平均的 AI 预算从 120 万美元涨到了 700 万美元左右。一项原本属于零头的科目，现在已经是董事会会注意到的数字，而那张在变化之前画好的组织架构图里，根本没有给它留一行。
你的招聘页上写着「需要 AI 经验」。发布会的通稿里点名提到了那些 AI 功能。本季度路线图上又新承诺了两个。而真正要把这些东西交付、维护下去的团队里，只有一个工程师真懂怎么调试一次 eval 失败，两个人能自信地编辑 prompt，剩下十二个把 LLM 调用当成一个黑盒——一旦它出问题，就甩出去给别人接。
这种分布就是领导团队从没点名说出来的交付风险：团队对外宣称的 AI 能力——也就是出现在汇报幻灯片上那一个数字——是任何单个成员技能的最大值；而团队真实的交付速度，是中位数。幻灯片上写的是一个数，生产环境跑的是另一个数。
用户落到一个搜索结果页面。A 团队的智能摘要在顶部横幅里弹出:"这是要点 —— 跳过列表吧。"B 团队的内嵌助手在侧边脉冲跳动:"留在这里,我陪你继续阅读。"两个提示争夺同一段 800 毫秒的注意力,用户被惹烦了,关掉了标签页。第二天早上,A 团队报告摘要点击率提升 6%;B 团队报告助手打开率提升 4%;会议室里没有人是错的,而产品却比一个季度前更糟。
这就是那种"独立功能团队 + 单一功能 A/B 测试"的标准打法看不见的失败模式。每个团队都针对自己的指标做了局部最优。用户 —— 只有一份注意力预算、一份心智模型、一次可以给出的点击 —— 替两个团队都不愿做的整合,买了单。
打开任何季度计划电子表格，你都能找到团队交付的每一个功能、每一张外包发票、每一项云服务支出。你找不到的是那些从未发生的停机事故、在触达客户前被拦截的幻觉退款，或者是凌晨 2 点被评测（eval）拦截的 Prompt 回归。这些“非事件”没有 SKU。它们不产生工单、没有复盘报告，也没有 Slack 讨论串。因此，当评测预算面临续约时，它在与拥有 Demo 的功能争夺人力配额——而且几乎每次都会输。
这不是勇气的问题。这是一个衡量标准的问题。评测投资同时兼具安全网和测试套件的属性：它悄无声息地产生复利，在规避灾难中体现价值，而其全部价值都建立在“反事实（counterfactual）”之上。财务部门在结构上对反事实视而不见。如果你领导一支 AI 团队，你的工作不是去争论评测是否重要——这一点每个人都会点头同意。你的任务是让那些只相信电子表格的人，能够看懂这种具有复利效应且无形的投资回报。
在 2026 年的代码审查（Code Review）讨论串中，最昂贵的一句话莫过于“这是 Agent 这么写的”。这并非因为它本身是错的——有时它确实没错——而是因为它终止了本该由此开启的对话。审查者输入一个问题，作者直接引用模型的推理作为回复，讨论在任何人真正开始争论这项变更之前就结束了。反对一个自信且谈吐得体的模型的社交成本，已经悄然高过了合并一个隐蔽 Bug 的成本，而大多数团队在未来两个季度内都无法在指标中察觉到这种权衡。
这不是一个关于 AI 写代码好坏的故事。它会写代码，其中有些还写得不错。这是一个关于当编写代码的摩擦消失时，质量关卡（Quality Gate）会发生什么的故事。审查速度上升，缺陷率也随之同步上升，而这种关联并不明显，因为没有人在追踪审查耗时与缺陷时会关联作者的类别。曾经是代码库品味核心的资深工程师，在一个悄然转向“模型盲从”的文化中，变成了孤独的坚持者。
PR 审查仪表盘连续六周显示绿色。机器人捕获率、评论量、开发者的“点赞”反应——一切都很稳定。然后生产环境发生了一起安全事故，事后分析指向一个缺失的空值检查（null-check），而这个检查机器人以前是能捕获到的，大约在两个月前悄然停止了。没有人更改机器人。没有人降级模型。仪表盘从未变动。但标准变了。
这是自动化代码审查在任何产品演示中都不会出现的失效模式。团队采用 LLM 审查器是为了获得一致性——每个 PR 都遵循相同的检查清单，没有资深工程师因“心情不好”而产生的波动，初级贡献者的周转速度也很快——这种一致性在最初的一个季度确实存在。然后系统提示词（system prompt）演变了，模型升级了，few-shot 库积累了，机器人开始使用不同于团队验证时的模型，根据不同的准则来审查不同的代码库。团队对“机器人能捕获什么”的心理模型衰退成了“机器人上周捕获了什么”。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
