1. 自由放任的时代已经结束

两年前，指令很简单：在AI上花钱，不问为什么。那个时代已经结束了。取而代之的是一场更艰难的对话，几位参与者显然已经与他们的CFO进行过这种对话。问题已经从“你在用AI吗？”转变为“你从中得到了什么？”对ROI（投资回报率）的需求没有改变。如果说有什么变化，那就是随意花钱的窗口正在缩小。对于大型组织来说，期望是在12个月内或更短时间内看到回报。正如一位参与者所说，挑战在于ROI中的“I”（投资）完全不受管理。工程能力过去意味着员工人数，这是财务部门可以建模的。现在它意味着token（令牌），而且没有人能控制任何单个工程师在某一天消耗多少token。一旦CFO签署了合同，他们就无法控制实际投资会是多少。如果你无法告诉我投资额，那么预测的回报又有什么意义呢？桌旁的几个人都遇到了同样的障碍：组织购买了工具，签署了合同，然后意识到公司内部没有财务模型来管理接下来会发生什么。比较不断出现：早期的云采用，在FinOps（云财务管理）出现之前的FinOps。我们正处于同样的窗口期。成本仍然是个幻想，使用量仍未定义，衡量它的指标也尚未发明出来。一位参与者的看法是：现在过于追求ROI可能意味着完全衡量错误的东西。更明智的做法是先建立一个基线。我认为最终会达到一个更可预测的状态，我们可以说，大约这么多token能带来这么多功能价值。但我认为我们现在还无法预测。一个更务实的回应，被多个团队分享：停止自由放任，开始标准化。这并不意味着我们告诉人们少用AI，而是从“使用一切”转向“更聪明地使用相同的东西”。

2. 你现在实际在招聘什么

招聘讨论揭示了在场人员对工程师实际是什么的看法存在分歧。一位参与者清晰地区分了两个经常被混为一谈的不同角色：交付产品的AI工程师，以及负责系统设计的工程师。语言不再重要：Python、Go、Rust、Node。但系统设计没有改变。仍然需要有人考虑可用性、预算以及AI无法为你做出的架构决策。新的软件工程师是产品领导者。是思考产品是什么的人，而不仅仅是它如何工作。但我们仍然需要思考设计的技术人员。这是两件不同的事情。在面试方面，共识倾向于保留技术基础，但有一些注意事项。一个团队还没有改变他们的流程，仍然测试系统思维能力，以及分解模糊问题的能力。其他人则在积极重新思考。最有趣的观点来自一位将面试转向代码审查而非编码的人，因为这正是工程师现在实际在做的事情。我改变了我们的面试流程，专注于代码审查，因为这是我们实际在做的事情。而实现现在由AI辅助，无论你选择如何使用你的agent（智能体）。如果你的团队生成代码的速度快于审查代码的速度，你就遇到了瓶颈。限制因素是人类判断，而不是产出。

3. 团队反应与“重新校准时刻”

在桌子对面，没有人描述一个团队是统一热情或统一抵制的。现实情况更加混乱。一位领导者谈到了他公司里的后期采用者，他们在被温和推动后终于加入，然后遇到了他所谓的“重新校准时刻”：意识到过去需要几天才能完成的整类工作现在只需要几个小时，并且不得不重新思考他们的日程安排如何运作。另一个人描述了一种更复杂的情况：一位工程师使用AI效率很高，确实擅长使用它，但对AI生成的输出也深表怀疑。有一个人非常擅长使用AI，效率很高，但对AI产生的任何东西都高度敏感。“这是AI写的。”“好吧，但它好吗？”“是的，它很好。但它是AI写的。”关于AI让人们停止思考的担忧不止一次被提出。反驳意见并非否定。而是一种重新框架：这是一个管理问题，而不是技术问题。这些工具很容易让人变得懒惰。领导者的工作就是让懒惰变得不值得。你可以选择快速、冗长但质量不高的东西。或者你可以用它来迭代，真正把它打磨成简短的东西。我们现在都能写很长的信。是否应该写则是另一个问题。一家公司进行了一项匿名调查，发现该组织中90%的工程师实际上想使用AI，高于预期。让他惊讶的不是热情，而是接下来发生的事情：关于绩效管理、晋升标准、以及当现在任何人都能生成代码时，个人贡献如何被认可的问题。采用已经超过了赋能。我们正在快速应用AI，但我们还没有更新职业路径或重新思考能力矩阵。他们完全有权问这些问题。

4. 没人想谈论的功能债务问题

AI让编写代码变得廉价。但这与交付或维护代码的廉价不是一回事。一位参与者说得一针见血：认知债务是新的技术债务。房间里的人都看到了同样的模式：团队以两年前不可能的速度添加功能，现在却在处理随之而来的维护开销。本来就难以理解的遗留代码现在更难了，因为编写它们的人不够谨慎。他们追求的是速度。而那些本不打算永久使用的内部工具现在变成了永久性的，因为有人用三个提示词就把它交付了。那些流程——构建还是购买，这东西值得长期维护吗——存在是有原因的。但如果你能在一下午就搞出个东西，很容易跳过它们。问题以后才会出现。一位参与者的回应是：想写什么就写什么，但写了并不意味着你交付了它。代码是廉价的，但发布它却不是。当管理层庆祝每一个PR（拉取请求）时，在团队中保持这种区分比听起来要难。一个专门的“技术健康团队”的概念被提出，作为一种结构性答案：交付功能的工程师和删除或重构它们的工程师，被视为同等有价值的工作。让一个受速度激励的业务方接受这一点才是真正的挑战。

5. 谁应该提交PR？

晚宴上最热烈的部分：如果AI让任何人都能轻松编写代码，那么产品经理应该提交PR吗？房间里意见不一。不是关于可能性（每个人都同意工具在技术上使其可行），而是关于这是否是值得优化的正确方向。一位参与者强烈反驳了非工程师向生产环境交付被视为胜利的说法：如果你实际上让工程师变成了代码审查监控员，保护公司免受他们没写过的PR的侵害，而产品经理却因交付而获得赞誉，那么请检查一下你工程师的心理健康。其他人则更务实。让非工程师在更小、风险更低的任务上做出贡献，可以缩短每个人的反馈循环。能够按照规格编写组件而无需等待工程师的设计师。能够修复复制错误而无需开Jira工单的产品经理。只要防护栏设置得当，这就有价值。自动驾驶汽车的类比很贴切：一个普通的AI辅助非工程师可能比一个普通的无辅助非工程师更好。但没有人将他们与那些花了多年时间培养专业知识的工程师进行比较。这种比较只在特定的复杂度范围内才有意义。如果一个功能是80%的工程和20%的产品思维，工程师可以完成。如果是反过来，也许产品经理可以处理。我认为实际发生的情况是，我们正在成为价值创造者，无论头衔如何，都会接手任何有意义的工作部分。更困难的结构性问题没有得到明确的答案：如果任何人都能交付，那么谁的工作是把所有东西整合在一起？房间里的几个人说，唯一现实的回应是激进的团队自主权：由三到五人组成的小组，拥有自己的决策权，管理层的工作转向协调而非把关。

6. 代码审查是瓶颈，AI或许能解决

一位参与者一直在从CI/CD（持续集成/持续部署）的角度思考这个问题：问题不在于团队无法生成代码，而在于他们无法足够快地审查代码。人工审查现在是瓶颈，解决方案不是增加审查者，而是更智能的分类。他的团队一直在试验对PR进行置信度评分：使用AI评估变更的风险，只呈现真正需要人工检查的部分。一个15000行的PR，只有三行需要人工审查，这不是一个15000行的审查问题。如果你能信任其余部分，这就是一个三行的问题。我真心认为你可以有一个一万五千行的PR，然后说，我需要人工审查这三行。其他所有内容都没问题。我还不知道如何做到这一点，但我知道这必须实现。更深层的观点是关于抽象层。我们不读汇编代码，我们信任编译器。问题在于，你是否能构建足够的验证基础设施——功能开关、可观测性、验收测试、变异测试——来使类似的信任关系适用于AI生成的代码。房间里没有人声称他们已经解决了这个问题。有几个人说他们正在尽最大努力朝这个方向推进。由此产生的一个实用建议是：现在就投资于评估，而不是以后。构建AI功能的成本不是难点。验证的成本才是。如果你今天构建了一套可靠的评估套件，你就可以更换供应商、应对模型弃用、或迁移到开源方案，而无需从头开始。构建成本并不高。验证成本很高。当你合作的供应商更改他们的模型时（他们经常这样做），你只需运行那套评估套件，就没事了。

7. 你押注的供应商

当Anthropic或OpenAI涨价、宕机或被颠覆时会发生什么？一位参与者直言不讳：她整个公司在Anthropic上有一个单点故障。工程部门理解单点故障。在Claude之上构建东西的市场和财务部门的人则不理解。工程部门之外的很多团队都在构建东西，我认为他们并不真正理解底层是什么。如果我们突然无法获得推理能力，市场部会怎样？财务部会怎样？他们会打电话给工程部。反驳观点是，竞争将控制价格。开源模型不再落后数年；它们最多落后几个版本。当客户有替代方案时，你不能将价格翻倍。但锁定担忧实际上并非关于模型本身。而是关于围绕它构建的一切。技能、工具、内部工作流程——这些比模型端点迁移起来困难得多。实用建议是：现在就在通用模型API之上构建内部UI包装器，趁你的团队还没有被锁定在特定的产品界面中。这样做成本低廉，而且意味着你可以在不重建团队依赖的界面的情况下，更换底层的模型。

8. 下一步是什么？在Shift大会上讨论

这些反思、反应和对话只是我们为筹备9月份Shift工程与AI大会而组织的其中一场Shift CTO晚宴的一部分。我们所有的晚宴参与者都已被邀请——你也一样！我们还在计划一些工程领导力项目，但将在整个会议议程中讨论与本文类似的话题——构建AI原生工程团队、发展你的开发者职业生涯、扩展系统。我很希望你能加入我们——获取门票，我们在扎达尔见！晚宴在查塔姆宫规则下举行。引用内容不注明出处。

---

🔗 原文链接：https://shiftmag.dev/ctos-agree-cognitive-debt-is-the-new-technical-debt-10229/