CTO们的晚餐共识是AI免费花钱的时代已经翻篇了，现在每个工程领导都得回答同一个问题：你投进AI的钱到底换回了什么。
ROI里的那个I现在根本没人管得住
两年前老板们拍桌子说花钱搞AI不用问，预算随便批，合同闭眼签。现在没人这么干了。
现在换成了更难聊的话题。好几个CTO都说他们最近跟CFO吵过架，吵到脸红脖子粗那种。问题从“你们用没用AI”变成了“你们用它换来了什么”。
ROI这个东西一直都要算账，财务部门最喜欢拿这个说事。但以前算的是人头，工程师多了几个，成本清清楚楚列在表上。现在算的是token，你根本不知道手底下哪个工程师今天烧了多少token，更不知道这些token到底干了什么正经事。
合同签完字之后CFO就完全失控了，他管不了实际投资到底是多少。那你连投资数都说不清，还谈什么预期回报，这不是搞笑吗。
好几个人都撞上了同一堵墙。公司买了工具签了合同，然后发现内部根本没有财务模型能管接下来的事。大家反复提到一个类比，就是早期上云那会儿FinOps还没出现，大家都在瞎花钱，账单来了才傻眼。现在就在那个窗口期，成本还是笔糊涂账，用量也没个准谱，衡量指标还没发明出来。
有个人说得挺实在，现在就硬推ROI可能全量错，不如先老实摸底。聪明点儿的做法是先摸个底，搞清楚现在的用量和产出到底是什么水平。他觉得早晚能算清楚大概多少token能产出多少功能价值，但现在还预测不了。
更多人给出的反应是务实派，别再随便花了，开始标准化。不是说让人少用AI，而是引导大家从什么都用变成都用同样的东西并且用得聪明点。就像当年云服务一样，先管住乱花，再谈怎么花得值。
你现在招的到底是什么人
招聘这块聊出了大分歧。大家对工程师这岗位的理解不一样了，分歧大到差点吵起来。
有个人画了条很清楚的线，把两种角色分开了。
一种是做AI产品往前冲的工程师，天天跟模型打交道，快节奏往外发东西。
另一种是管系统设计的工程师，稳得住，想得远。
编程语言现在不重要了，Python、Go、Rust、Node都行，换语言跟换鞋一样随意。但系统设计没变，还是得有人操心可用性、预算、还有那些AI替不了你的架构决定。AI可不会告诉你数据库该怎么分库分表。
新的软件工程师其实是个产品负责人，得琢磨产品本身是啥，不只是它怎么工作。你得想用户要什么，功能怎么组合，体验怎么顺。但我们还是需要懂技术的人去想设计的事，这俩是两码事，一个人很难同时干好。
面试这边大家倾向先保住技术基本功，但各有各的改法。有一家还没动流程，照样考系统思维，考拆解模糊问题的能力，跟五年前没什么两样。另外几家已经在重新想了，觉得老一套考不出真东西。
最让人意外的改法来自一个技术负责人，他把面试改成了考代码审查而不是写代码，正因为他们现在干活主要就是审代码，写代码那部分基本交给AI了。他觉得面试就得面实际干的事，而不是面十年前干的事。
他把面试流程改成专注代码审查，因为那才是实际在干的事。具体实现现在靠AI辅助，你自己选怎么用agent。这个转变挺大，但逻辑上说得通。
如果你的团队生成代码比审查代码快，那瓶颈就出来了。真正的限制是人脑判断，不是产出速度。你写再多代码没人审也是白搭，堆在那边等着出问题。
团队反应和所谓的重新校准时刻
饭桌上没人说自己团队是全员热情或者全员抗拒，实际情况乱七八糟，像一锅乱炖。
有个人讲了他们公司那些晚用AI的人。稍微推了一把终于开始用了，然后碰到所谓的重新校准时刻。他们发现以前要干好几天的活儿，现在几个小时就完事了，日程突然空出来一大块，反而不知道该怎么安排时间了。以前开个周会说这周干了啥能说一堆，现在两句话就讲完了。
另一个人讲的情况更复杂。他们团队有个工程师用AI用得特别溜，产出也高，但同时对AI生成的东西疑心特别重，每行代码都要反复检查。这人看到啥都觉得是AI写的，你跟他说东西挺好，他说对是好但就是AI写的。这种矛盾的状态让人哭笑不得，但可能恰恰是最健康的态度。
有人担心AI让人不动脑子，这话出来了不止一次，而且说这话的人都是老工程师。反驳的人没否定这个担心，只是重新定义了一下，说这是管理问题不是技术问题。工具确实让人容易偷懒，你给任何人一个抄近道的选项，多数人都会选。领导的工作就是让偷懒变得不划算，让大家知道走捷径的代价是什么。
你可以拿来写又快又长又不咋样的东西，也可以拿来反复迭代最后整出一篇短的。现在我们都能写很长的信了，写长文不费劲了。至于该不该写，那是另一回事，得有人把关。
有家公司做了个匿名调查，发现九成工程师其实想用AI，比他预想的高得多。让他意外的不是这个热情，而是接下来的问题。大家开始问绩效怎么管，晋升标准怎么定，个人贡献怎么算，因为现在谁都能生成代码了，代码量这个指标彻底废了。采用速度已经超过了配套措施，工具到位了，制度没跟上。
我们AI推得很快，但职业路径没更新，能力模型也没重新想过。人家问这些问题完全合理，换谁都得问。
没人想聊的功能负债问题
AI让写代码变便宜了，便宜到几乎不要钱。但这跟便宜地发布和维护不是一码事，发布要过测试、过审查、过部署，每一步都有人力成本。
有个人总结得很干净，认知负债就是新的技术负债。以前我们讲技术负债，说的是赶工期写烂代码欠的债。现在你连代码都没亲手写，你欠的债叫认知负债，因为你根本搞不清楚这段代码到底在干什么，是谁的意思。
饭桌上的人都见过同样的套路。团队加功能的速度两年前根本不敢想，一周能顶过去一个月。但现在得应付随之而来的维护开销，bug多得修不完。本来就看不懂的老代码现在更难懂了，因为写代码的人不仔细了，他们在赶速度，能用就行。那些本来没打算永久的内部工具，现在变成永久了，因为有人用三句提示词就把它发上去了，发上去就下不来了。
那些流程，比如自己搞还是买来用，要不要长期维护，都是有道理的。但如果你一下午就能鼓捣出个东西来，就很容易跳过这些流程，觉得没必要。问题在后面等着呢，等你想起来的时候已经来不及了。
有个人说随便写，但写了不代表你要发。代码便宜，发布不便宜。在团队里保持这个区分比听起来难多了，尤其是当管理层在庆祝每个PR的时候，谁还管质量。你看着PR数量蹭蹭往上涨，能忍住不夸两句吗。
有人提出搞个专门的技术健康团队，一部分工程师写功能，另一部分专门删代码或者重构它们，两种工作同等重要。让业务部门认可这事儿的难点在于他们只认速度，重构又不产生新功能，凭什么给你拨人。
谁该往生产环境发PR
晚饭上吵得最凶的话题，是既然AI让谁都能写代码，那产品经理该不该往生产环境发PR。这个问题一出来，桌子上的气氛立刻就变了。
大家不是怀疑能不能做到，工具确实让这事儿技术上可行。吵的是这么做到底对不对，会不会把整个工程体系搞乱。
有个人狠狠怼了那种让非工程师往生产环境发东西，然后管这叫胜利的说法。他说如果你把工程师变成了代码审查监控员，整天负责保护公司不被他们没写过的PR搞垮，而产品经理因为发了东西拿功劳，那你最好去查查工程师的心理状态。这帮人迟早要跑。
另外一些人更务实，觉得别一棍子打死。让非工程师在小任务、低风险任务上能贡献，能缩短所有人的反馈周期。设计师不用等工程师就能按规范写个组件，产品经理不用开Jira工单就能改个文案错字。只要护栏设对了，这么做有价值，效率能提升不少。
有人用自动驾驶打了个比方，挺传神。一个普通非工程师配上AI辅助，可能比不配AI的普通非工程师强。但没人拿他们跟练了好多年的专业工程师比，那不公平。这个比较只在特定复杂度范围内才有意义，超出范围就扯淡了。
如果一个功能八成功力是工程，两成功力是产品思考，那工程师能干。反过来，可能产品经理也能干。他觉得实际上发生的是我们都变成了价值创造者，不管什么头衔只管捡起合理的活儿来干，边界越来越模糊。
更难的结构性问题没人给出漂亮答案。如果谁都能发东西，那谁来负责把所有东西撑住，出了问题找谁。饭桌上有几个人说唯一现实的办法是给团队极端自治，三到五个人一组自己拿主意。管理层的活儿从把关变成对齐方向，别整天卡审批。
代码审查现在是瓶颈
有个人从CI/CD的角度琢磨这事儿，觉得问题特别清楚。问题不是团队生成不了代码，而是审查不够快，PR排队等着看。
人工审查现在是瓶颈，解决办法不是加更多审查员，人加不过来。而是更聪明地分流，把精力花在刀刃上。
他们团队在试PR置信度评分，用AI评估一次变更的风险，只把真正需要人眼看的部分挑出来。一个一万五千行的PR里头，只有三行需要人审，那这就不是一万五千行的审查问题，而是三行的问题。前提是你信得过剩下的，这个信任得慢慢建。
他觉得自己真能想象有一万五千行的PR，然后说我需要人看这三行，剩下都没问题。现在还不知道怎么做到，但他知道这事儿必须得发生，不然团队迟早被PR淹死。
更深一层是抽象层的问题。我们现在不读汇编了，因为信编译器，觉得它翻译得对。问题是你能不能搭出足够的验证基础设施，功能开关、可观测性、验收测试、变异测试，好让你对AI生成的代码也有类似的信任关系。饭桌上没人说解决了这个问题，好几个人说他们在使劲往那个方向推，但离搞定还远。
有人提了个实用建议，现在赶紧搞evals，别等。搞AI功能的成本不是大头，验证的成本才是。你今天搭一套好的eval套件，将来换供应商、应对模型下架或者转开源，都不用从头来，省大事了。
搭建成本没那么高，验证成本高。你的供应商老换模型，你就跑那套eval套件，过就过，不过就改，心里有底。
你在押注哪个供应商
万一Anthropic或者OpenAI涨价了、挂掉了、或者被颠覆了怎么办，这个问题像悬在头顶的剑。
有个人说得直白，他们整个公司就押在Anthropic这一个点上，单点故障。搞工程的人都懂单点故障意味着什么，但营销和财务那边在Claude上面搭东西的人不懂。他们只管用得爽，不管底下稳不稳。
好多工程之外的团队都在搞东西，他们可能根本不懂底下跑的是啥。万一哪天推理服务突然用不了了，营销怎么办，财务怎么办，他们肯定找工程部，说系统坏了你们快修。但你修不了，因为问题不在你这里。
反驳的人说竞争会把价格按住，不用太担心。开源模型已经不是落后好几年了，最多差一两个版本，有些任务上甚至能打平。客户有别的选择，你不敢随便翻倍涨价。但大家担心的锁定其实不是模型本身，而是围着模型建起来的所有东西，技能、工具、内部工作流，这些比换个模型接口难搬多了，牵一发动全身。
实用建议是现在赶紧在通用模型API上面罩一层内部UI，别等团队被特定产品界面锁死了再动。这事儿成本低，而且意味着你可以换底下的模型，不用重写团队依赖的界面。现在花一天干的事，将来能省一个月。
总结
本文基于CTO Craft晚宴闭门讨论，记录了多位工程领导者在AI采用过程中面临的真实困境。核心观点是AI开支的免费时代已经结束，认知负债正在成为新的技术负债。文章涵盖ROI衡量困难、招聘标准变化、团队反应分化、功能维护成本激增、代码审查瓶颈以及供应商锁定风险等话题。所有引用均遵循查塔姆研究所规则，不具名使用。
一线工程师的真实感受：代码审查已经取代了写代码
Reddit上那篇关于认知负债的文章下面，工程师们的评论比原文还精彩。最热的一条回复来自一个多伦多的架构师，他说自己已经三个星期没发过PR了，百分之百的时间都在审代码。
他原来也是写代码出身的，现在的工作变成了给AI工具建护栏。具体来说就是写产品领域的明确文档，定义清楚什么算正确，把产品意图变成可执行的规则。他觉得旧有的假设——代码是正确性的可靠来源——在AI时代已经不成立了。代码现在像水一样流动，按个按钮就能完全重写。
但他也承认这事儿累死人。他负责的是核心基础架构，很多其他团队在上面加功能。他得审别人的PR，防止他们无意中搞崩核心功能。每次都要在不同系统之间跳来跳去，深入进去才能做判断。这种上下文切换极度消耗精力。
有个评论特别扎心。一个人说他以前对自己写的东西特别自豪，那种感觉现在没了。但效率和学新东西的速度确实疯了似的往上涨。
有人找到了应对办法：不提示AI写代码，提示AI写生产代码的系统
一个叫morgo_mpx的网友分享了他们团队的解法。他们的策略不是让AI直接写功能代码，而是让AI写那些能生成功能代码的系统。
他们搞了多个AI代理和产品，让它们在不同模型之间对变更达成共识。觉得这种做法的反馈循环比直接裸写PR要有效得多。但他说现在公司还在花钱搞AI的阶段，所以大部分人主业还是修bug和加功能，这些东西只能在后台偷偷跑。
另一个人追问这种做法在多大的产品和多大的工程团队里管用。morgo说他们用的是Claude Code加技能系统，配合基于规格说明的状态机功能创建技能，只要你愿意烧token，能干不少活。
但有人泼了冷水，说这只是给系统又加了一层抽象而已。你们公司不太可能写出比现有框架更好的抽象层。等你面对真正的客户解决方案时，这一套可能就不灵了。
有人警告技能萎缩和认知衰退是必然结果
有个评论说得特别狠。他说你描述的这种工作方式，必然导致技能完全萎缩加上认知能力下降。因为没有任何人或者任何团队能真正理解系统或者代码库了。代码不是任何人写的，它在你脚底下随时在变。
结果就是彻底向LLM投降，产生彻底的锁定效应。当token价格暴涨——他觉得这事儿必然发生——公司就得面对一笔非付不可的巨款。任何一个脑子清醒的CTO或者CEO都应该看到这个威胁。
有人质疑AI写大规模代码的能力
ragemonkey说AI代理根本写不出能大规模运行的好代码。小东西能搞定，一旦接近上下文窗口边界或者超过它就完全抓瞎了。
也许你可以把所有产品需求用文字写出来，让自动化测试覆盖每个角落，再让一堆代理从各个角度审查PR。但他极度怀疑这样做能省下时间或者钱。你这不就是在用模糊的英语重新写代码吗，还指望最好结果。
他觉得AI代理最好用的时候是你花大力气引导和监控的时候。你得确保自己非常清楚它们生成了什么。这本身就在限制你从这些工具里拿到的ROI。他认为除非这些代理接近AGI水平，否则问题解决不了。它们得能开会、能提问、能记住事情才行。到那时候大家都不用工作了。
有人指出这不就是重新发明了QA吗
Cyclic404说你们搞什么专门的技术健康团队，工程师分两拨，一拨写功能一拨删代码重构，两种工作同等重要。这不就是QA吗。
他说我们外包的时候就是这么干的啊。活外包出去，拿回来一堆东西，发现全是bug多得没法维护的烂代码——因为外包商就是最低价中标的——然后公司内部团队不得不重写。这些CTO仿佛在说以前这个职业就不需要验证产出不需要琢磨怎么投资似的。
认知负债和技术债到底是不是一回事
这个话题底下吵起来了。有人说认知负债就是技术债的另一种叫法，这帮高管就是不愿意听工程师说话。另一个人说不一样。技术债你至少知道它在哪里，知道有什么变通办法和坑。认知债是你连软件的大块部分都不知道是怎么回事，你根本不知道你不知道什么。
还有人贴了一篇经典论文的链接，说代码存在于工程师脑子里这个事儿从计算机诞生那天就开始了，AI只是把这个事实推到极端。
有人提出一个疯狂的想法：一切皆可重写
fzammetti说当你能在几分钟或者几小时内重写整个系统的时候，某种意义上所有东西都变成绿地开发了。维护老系统的概念会变得越来越奇怪。系统不太对劲？重写。加功能？直接重写整个东西算了。只要新版本跑过测试就行。
他特意强调自己不是赞同这个想法，只是觉得我们可能正在往那个方向走。也许不是明天，但那个地平线可能已经近得让人不舒服了。