CTO共识：认知负债（Cognitive Debt）已成为新的技术负债

背景

本文基于 CTO Craft 在多伦多举办的一场闭门晚宴实录整理而成。该活动采用非正式、无演示文稿、无赞助商推销的“坦诚对话”形式，旨在让资深工程领导者交流组织内部的真实状况。此次晚宴的主题聚焦于“工程领域的 AI 采用（AI adoption in engineering）”。

参与对话的 CTO 们普遍反映，尽管此前在伦敦等地已听到类似观点，但核心结论依然令人不安：目前尚无一家企业真正完全搞定了 AI 在工程中的落地难题。这种不确定性不仅体现在技术层面，更深刻地反映在财务模型、人才结构以及工程文化上。随着 AI 狂热初期的“盲目投入”阶段结束，企业正面临从“是否使用 AI”向“AI 带来了什么回报”的务实转变。

核心内容

1. 免费狂欢时代的终结与 ROI 困境

两年前，企业的指令简单直接：花钱投资 AI，无需多问。如今，这一时代已彻底结束。取而代之的是与首席财务官（CFO）之间更为艰难的对话，核心问题已从“你们是否在使用 AI”转变为“你们从中获得了什么回报？”

对于大型组织而言，期望通常在 12 个月甚至更短时间内看到回报。然而，ROI（投资回报率）中的“I”（Investment，投资）目前处于完全失控状态。

• 成本不可控： 过去工程产能以人力（Headcount）衡量，财务部门可以轻松建模；现在产能以 Token（令牌）消耗衡量，没有任何人能控制单个工程师每天消耗多少 Token。
• 财务模型缺失： 一旦签署合同，CFO 便无法掌控实际投资规模。若无法量化投资，预期的回报也就无从谈起。

许多企业陷入了与早期云计算采用相似的困境：购买了工具，签署了合同，却缺乏管理后续支出的财务模型。这被称为“FinOps 出现前的 FinOps 阶段”。目前，成本仍是幻想，使用量未定义，衡量指标尚未发明。

有参与者指出，过早追求 ROI 可能导致衡量错误的指标。更务实的做法是先建立基线（Baseline），从“什么都用”转向“更聪明地使用相同的东西”，即标准化而非单纯限制使用。

2. 工程师角色的重新定义与招聘变革

AI 的引入引发了关于“工程师究竟是谁”的认知分裂。

• 角色分化： 参与者明确区分了两种角色：
  1. AI 工程师： 负责交付产品，关注功能实现。
  2. 系统设计工程师： 负责系统架构，关注可用性、预算及 AI 无法做出的架构决策。 编程语言（Python, Go, Rust, Node 等）的重要性下降，但系统设计思维依然至关重要。
• 新软件工程师即产品领导者： 新的软件工程师不仅是技术实现者，更是产品领导者，需思考“产品是什么”而不仅是“产品如何工作”。
• 面试流程的重构： 共识倾向于保留技术基础，但方法需调整。
  • 部分团队仍测试系统性思维和问题拆解能力。
  • 最具洞察力的转变是将面试重点从“编码”转向“代码审查（Code Review）”。因为实现代码已由 AI 辅助，工程瓶颈已从“产出速度”转变为“人类判断力”。如果团队生成代码的速度快于审查速度，瓶颈就在人。

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

团队对 AI 的反应并非一边倒，而是呈现出复杂的混合状态。

• 重新校准时刻（Recalibration Moments）： 后期采用者在使用 AI 后，发现原本需数天的工作缩短至数小时，不得不重新规划工作节奏。
• 矛盾的心理状态： 存在一类工程师，他们擅长使用 AI 且生产力极高，但对 AI 生成的输出极度敏感和怀疑。这种“虽然好，但是是 AI 写的”心态反映了深层的不信任。
• 管理而非技术问题： 关于 AI 让人变懒的担忧被重新框架为管理问题。工具让懒惰变得容易，领导者的职责是让懒惰变得“不值得”。关键在于利用 AI 进行快速迭代和精炼，而非仅仅生成冗长的内容。
• 采用速度超越赋能速度： 匿名调查显示，90% 的工程师希望使用 AI。令人惊讶的不是热情，而是随之而来的对绩效考核、晋升标准及个体贡献认定的质疑。企业快速推进 AI 采用，却未更新职业路径或能力矩阵，导致员工产生焦虑。

4. 认知负债：无人愿谈的隐性成本

AI 降低了编写代码的成本，但这不等于降低交付和维护的成本。

• 认知负债（Cognitive Debt）： 这是新的技术负债。团队以前所未有的速度添加功能，却面临随之而来的维护开销。
• 代码质量隐患： 遗留代码本就难以理解，现在因编写者追求速度而变得更难维护。一些本非永久的内部工具，因通过几个 Prompt 快速生成而被永久保留。
• 流程被绕过： 传统的“构建还是购买”、“长期维护价值”等决策流程因 AI 的快速生成能力而被跳过，问题在后期爆发。
• 区分“编写”与“交付”： 有参与者强调，“写代码”不等于“发布代码”。在管理层庆祝每一个 PR（Pull Request）的氛围中，保持这一区分极具挑战。
• 技术健康团队： 一种结构性解决方案是设立专门的“技术健康团队”，负责删除或重构代码，其价值应与交付功能的团队等同。但在以速度为导向的业务中，获得对此类投入的认可才是真正的挑战。

5. 谁应该提交 PR？

关于非工程人员（如产品经理）是否应直接提交 PR 的讨论最为激烈。

• 反对观点： 如果非工程师直接上线代码，而工程师沦为“代码审查监控员”以保护公司免受未编写代码的 PR 影响，这将严重损害工程师的心理健康。
• 务实观点： 虽然技术上可行，但是否应将其作为优化目标存在分歧。

关键要点

• 财务失控： AI 成本（Token 消耗）缺乏细粒度控制，导致 ROI 计算失效，企业急需建立类似 FinOps 的 AI 成本治理体系。
• 角色重构： 纯编码能力贬值，系统设计、产品思维及代码审查能力升值。工程师需从“代码生成者”转型为“产品领导者”和“系统架构守护者”。
• 招聘变革： 面试重点应从算法编码转向代码审查、系统性思维及问题拆解能力，因为“人类判断力”成为新的瓶颈。
• 认知负债崛起： AI 加速了代码生成，但也导致了维护难度的指数级上升。必须警惕“快速生成”带来的长期技术债务，需区分“编写”与“发布”的界限。
• 管理滞后： AI 的采用速度远超组织管理（绩效、晋升、能力模型）的更新速度，引发员工对职业发展的焦虑。
• 标准化优于自由化： 面对 AI 的无序使用，最佳策略是建立基线并推行标准化使用，而非简单限制或盲目鼓励。

意义与影响

这篇对话揭示了 AI 在工程领域落地进入深水区后的真实痛点：技术可行性已不再是瓶颈，管理和治理才是。

1. 从技术驱动转向治理驱动： 企业不能再仅靠购买 AI 工具来解决问题，必须建立相应的财务模型、代码审查标准和架构治理机制。
2. 工程文化的重塑： “认知负债”概念的提出，标志着软件工程关注点从单纯的代码质量扩展到思维负担和维护成本。工程师需要更多的时间用于审查和重构，而非编写。
3. 人才战略的调整： 招聘和培养重点将向具备产品视野、系统架构能力和批判性思维（审查 AI 输出）的复合型人才倾斜。
4. 组织敏捷性的新挑战： 企业需在保持 AI 带来的速度优势与维持长期技术健康之间找到平衡。这可能意味着需要引入专门的技术维护角色，或重新定义“交付”的价值标准。

对于 CTO 和技术领导者而言，当前的核心任务不再是探索 AI 能做什么，而是如何构建一个能够承载 AI 高速产出、同时有效控制认知负债和财务风险的工程生态系统。