工程领导者们普遍认为，尽管行业正在积极拥抱 AI，但成熟的策略尚未形成。企业已从“不计成本投入 AI”的阶段，转向关注投资回报率，然而衡量标准却付之阙如。AI 加速了编码，却也带来了代码评审、维护和“认知债务”等新瓶颈。这不再是单纯的技术问题，而是一场涉及管理、流程和组织结构的全面重塑，核心挑战在于如何平衡 AI 带来的效率与随之而来的新风险。
从“随便花钱”到追问回报
大约两年前，指令很简单：不问缘由，投资 AI。那个时代已经结束。取而代之的是一场更艰难的对话，许多公司开始向首席财务官（CFO）解释 AI 的价值。问题从“你是否在使用 AI？”变成了“你从中得到了什么？”。
挑战在于，投资回报率（ROI）中的“投资”（I）部分完全无法管理。过去，工程能力意味着人头数，财务可以建模。现在，它意味着 tokens，但没人能控制一个工程师每天会消耗多少 token。
CFO 签了合同后，就无法控制实际的投资额。如果你无法告诉我投资额，那么预测回报又有什么意义？
许多团队都撞上了同一堵墙：公司购买了工具、签订了合同，却发现内部没有财务模型来管理后续的成本。这种情况与云计算早期类似，成本是虚的，用量是未定义的，衡量指标也尚未发明。
- 更明智的做法： 与其现在强求 ROI，不如先建立一个基准线。
- 更务实的做法： 停止无节制的使用，开始标准化工具。这并非要求减少使用 AI，而是从“使用所有工具”转向“更聪明地使用相同的工具”。
招聘标准重塑：我们到底在招什么样的人？
关于招聘的讨论揭示了在场者对工程师角色的不同看法。
一位参与者明确区分了两种角色：
- 发布产品的 AI 工程师： 思考产品是什么，而不仅仅是它如何工作。他们更像是产品领导者。
- 负责系统设计的设计师： 仍然需要考虑可用性、预算和架构决策，这些是 AI 无法替代的。
面试流程也正在被重新思考。一些团队仍坚持考察系统性思维和分解模糊问题的能力。而另一些团队则已将面试重点转向 代码评审，因为这才是工程师现在实际在做的工作。
我改变了我们的面试流程，专注于代码评审，因为这才是我们真正在做的事情。而代码实现现在由 AI 辅助完成。
如果你的团队 生成代码的速度超过了评审代码的速度，你就遇到了瓶颈。约束在于人的判断力，而不是产出。
团队反应不一：这是管理问题，不是技术问题
没有哪个团队是全体热情或全体抵触的，现实情况更为复杂。
一位领导者提到，一些晚接受 AI 的员工在体验到效率提升后，不得不重新思考自己的工作方式。另一位则描述了一个更复杂的现象：一名高效使用 AI 的工程师，同时却对 AI 生成的任何内容都抱有深深的怀疑。
对“AI 让人停止思考”的担忧不止一次被提及。对此，一个有力的反驳是：这是一个管理问题，不是技术问题。工具让懒惰变得容易，领导者的工作就是让懒惰变得不值得。
你可以选择用 AI 快速写出又长又不太好的东西，也可以用它来迭代，真正把它打磨成简短精炼的内容。我们现在都能写出很长的信，但我们是否应该这样做，则是另一个问题。
一家公司的匿名调查发现，90%的工程师希望使用 AI。令人惊讶的是随之而来的问题：关于绩效管理、晋升标准，以及当任何人都能生成代码时，个人贡献如何被认可。AI 的应用速度已经超过了配套管理体系的更新速度。
“认知债务”：没人愿意谈论的新问题
AI 让编写代码变得廉价，但这并不意味着发布和维护代码也同样廉价。一位与会者简洁地指出：认知债务是新的技术债务。
在场的所有人都看到了同样的模式：团队以两年前不可能实现的速度增加功能，现在却要应对随之而来的维护开销。
- 本就难以理解的遗留代码现在变得更难，因为写代码的人追求的是 速度，而不是 严谨。
- 一些本应是临时性的内部工具，因为某人用三个提示就把它发布了，结果变成了永久性的负担。
那些流程，比如“构建还是购买”、“这是否值得长期维护”，它们的存在是有原因的。但如果你一个下午就能搞定，就很容易跳过它们。问题会在以后出现。
一个应对策略是：代码可以随便写，但写了不代表就能发布。代码是廉价的，但发布它不是。当管理层为每一个提交的代码请求（PR）庆祝时，在团队中维持这种区别变得异常困难。
谁应该提交代码？一场关于职责边界的辩论
如果 AI 让任何人都能轻松编写代码，那么产品经理（PM）是否应该提交代码请求（PR）？
房间里的意见出现了分歧。分歧点不在于技术可行性，而在于这是否是正确的目标。
一位参与者强烈反对将“非工程师发布代码到生产环境”视为一种胜利。
如果你实际上是让工程师变成代码评审监督员，保护公司免受他们没有编写的 PR 的影响，而 PM 却因发布功能而获得赞誉，那么请关注一下你工程师的心理健康。
其他人则更为务实。让非工程师在风险较低的小任务上做出贡献，可以缩短所有人的反馈循环。例如，设计师可以编写符合规范的组件，而无需等待工程师。只要有正确的护栏，这就有价值。
最终，一个更结构性的问题没有得到明确答案：如果任何人都可以发布代码，那么由谁来把所有东西整合在一起？许多人认为，唯一现实的答案是 彻底的团队自治：由三到五人的小团队对自己的决策负责，管理层的角色从把关转为协调。
代码评审成为新瓶颈，AI 或能解决
问题不在于团队无法生成代码，而在于他们无法足够快地评审代码。人工评审现在是瓶颈。解决方案不是增加更多评审员，而是更智能地进行分类。
一个团队正在尝试对 PR 进行 置信度评分：利用 AI 评估变更的风险，只将真正需要人工审查的部分呈现出来。一个 15,000 行的 PR，如果只有三行需要人工审查，那么它就只是一个三行代码的审查问题。
我真的认为你可以有一个一万五千行的 PR，然后说，我需要一个人来审查这三行。其他一切都没问题。我还不知道怎么做，但我知道这必须发生。
这里的关键是建立信任。我们不读汇编代码，因为我们信任编译器。问题在于，我们能否构建足够的验证基础设施（如功能开关、可观测性、验收测试等），以便与 AI 生成的代码建立类似的信任关系。
一个实用的建议是：现在就投资评估套件（evals），而不是以后。构建 AI 功能的成本不高，验证的成本才高。
供应商依赖：一个隐藏的风险点
当 Anthropic 或 OpenAI 提价、宕机或被颠覆时，会发生什么？
一位参与者直言，她的整个公司在 Anthropic 上存在单点故障。工程团队理解单点故障的风险，但市场和财务部门那些在 Claude 之上构建工具的人却不理解。
这么多工程之外的团队在构建东西，我不认为他们真正理解底层是什么。如果突然之间我们无法进行推理，市场部会怎样？财务部会怎样？他们会打电话给工程部。
尽管市场竞争和开源模型的发展可能会限制供应商的定价权，但真正的锁定风险不在于模型本身，而在于围绕它构建的一切：技能、工具和内部工作流程。
实用建议：在你的团队被锁定到特定的产品界面之前，现在就构建内部的 UI 包装器，使其可以调用通用的模型 API。这样，你就可以在不重建团队依赖的界面的情况下，更换底层的模型。