丢掉对 AI 的盲从，重拾工程师主导权
AI 时代，写代码的成本趋近于零，真正值钱的是工程师对代码的判断力。这篇文章主张：无论代码有多少是 AI 写的，你都必须能为其中每一行决策负责。作者从自己成为技术负责人的第一场团队谈话出发，分享了如何在日常工作中用好 AI、又不被 AI 架空的具体方法。
最近我升任技术负责人，和团队的第一场正式谈话主题是 AI。但这场谈话的内容，跟团队成员的预期完全不一样。
他们以为我会先给出一套使用规范：几条边界、一份工具清单，外加一句警告。但我真正想聊的只有一个词——而这个词，我花了会议一大半的时间才说出口。
这篇文章不是劝你少用 AI。恰恰相反，我希望大家更积极、更大胆地用它：样板代码、测试脚手架、写过四遍的迁移脚本、永远记不住的正则表达式——统统交给 AI。如果某个模型五秒钟就能写完的东西你还在手写，那你不是有原则，你只是慢。
生产力提升是实实在在的，这一点没得争。但要用得负责任。而「负责任」这三个字，分量比表面上重得多。
关键词是「主导权」
这是我想让你从这篇文章里记住的唯一一件事：
无论一段代码有多少是 AI 写的，你必须能为其中的每一个决策辩护，就像那是你亲手做出来的一样。
不是「你写的」，也不是「你大概知道它在干什么」。而是你能辩护。别人质疑里面任何一行，你都能给出回答，因为你真正思考过。
这就是完整的标准。后面所有内容，都不过是这个标准推演出来的结果。
检验方法很简单
判断你对一段代码有没有真正的主导权，方法很简单：当有人追问时，你能不能不借助工具就给出解释？
当你的拉取请求（pull request）被人质疑时，你会因为早就想清楚了而直接回答，还是把对方的问题粘贴进模型、再把返回的内容粘贴回去？
如果是第二种，那活儿其实不是你干的，你只是转了个手。这一点谁都看得出来，包括来问你的人。
让人不安的是，这个测试很容易在悄无声息中挂掉。没人会当场抓住你，PR 照常合并。问题要等很久以后才浮出水面——等到系统崩了，而你正是那个本该知道原因的人。
为什么这件事比以前更重要
一个 pull request，本质上是向别人借时间。提交一段你自己都不懂的代码，并不能省掉这段代码本该有的思考——它只是把思考转移给了 reviewer，而且思考量还会放大，因为 reviewer 得重新拼凑那些你原本掌握、却随手丢掉的前因后果。
你不是帮团队省了一小时，而是花掉了别人的一小时，而且这笔账折算下来很亏。有时候算总账，反而更慢。
代码变便宜了，判断力就变贵了。我做的系统涉及薪酬：税务、支付、入职、合规。客户付钱不是让我们生产代码——代码现在几乎免费。他们付钱，是因为我们知道某个代扣税的特殊边界情况存在，知道某笔支付过了某个时间点就撤不回来，知道某个「小小的」表结构改动会弄坏一份要向政府申报的下游报表。
廉价的生成让判断力更有价值，而不是更廉价。但前提是你得真的在用它。外包出去的判断，不是判断。
然后是学习陷阱，这是我最担心的。如果工具替你修好了 bug，而你从头到尾没排查过，那下次它再出问题，你又回到原点。你对故障模式没有记忆，也没有该往哪儿查的直觉。工程师用整个职业生涯积累起来的东西——对一个系统「会以哪些特定、可学习的方式出毛病」的心智模型——你根本没建立起来。
这么干久了，你的每一天都会变成「第一天排查这个 bug」。
如今，专业感很廉价
AI 让「看起来专业」变成了免费的东西。笃定的语气、听着很精准的词汇、像样的结构和篇幅——任何话题，瞬间生成，零成本。至于底下有没有真东西，那就另说了。
所以我们过去用来判断一个人能力的信号，已经不再可靠。比如，一个 PR 标题吹得天花乱坠，实际 diff 一看却没什么改动；再比如，一份设计文档，本质上就是把产品需求文档（PRD）用工程术语重新抄了一遍，问题还是那个问题，只是换了个更贵的字体来陈述。
我现在有个经验法则：如果一份工作听起来很唬人，但作者自己没法用大白话解释清楚，那这是危险信号，不是优势。如果一个人不能放下术语，用平常话告诉我它到底做了什么，那通常意味着这种高深是包装出来的，而不是真正掌握的。
永远不要把 AI 生成的内容当作你的产出
大家最反对的一点是：不要在 Slack、PR 评论或文档里直接贴 AI 生成的文本。AI 说的往往是对的——这从来不是问题所在。问题在于读者一眼就能看出来。生成出来的文字有一种特有的质感——语气含糊、句式整齐划一，还会去回答一个根本没人问过的问题。当读者认出这是 AI 写的，会发生比「这效率不高」更糟的事情：他们开始不那么信任你。因为你等于在说，你根本没有认真思考他们的问题，连回答都要假手于人。
你可以用模型来帮你整理思路，让它陪你起草、跟它辩论、让它对你的推理挑毛病——这些属于输入。但最终的措辞，必须是你自己的。
如果要传递的信息是你自己的，那就没有为什么不能用 AI「润色」的道理。这里的分界线在于：它是不是在替你思考。
如果模型替你整理思路，而你只是浏览一下、说句「看起来行」就发出去——那叫输出，那不是你的工作成果。如果模型的文字足够好，你愿意署上自己的名字——这也是你的产出。但那份文字必须是经过你批判性检验的思考结果，不是「看着差不多」就行了。
当 AI 能生成大量代码时，团队面临的真正挑战不是「用得太少」，而是「用得太盲」。本文从团队管理者的视角出发，给出了几条务实的落地规则：怎么把 AI 嵌入工作流而不错失对代码的掌控、哪些场景应该果断关掉 AI，以及为什么「判断力」才是 AI 时代工程师最值得打磨的能力。
组织层面怎么落地？
原则清楚了，执行才是关键。下面按我对团队的要求，逐条说明。
保证基础的易用性
每个人都该有得用，而且是免费额度用不完的那种。到 2026 年，还在限制 AI 工具的使用，既不现实，也是对团队的不尊重。头部大模型的调用成本已经趋近于零，本地小模型也能轻松跑进 IDE（集成开发环境）。在这种前提下，克扣 AI 工具的额度，就和克扣 IDE 许可证一样荒唐。
确立默认动作
习惯才是规则的终极形态，所以「每次打开新任务时先做同一件事」比任何制度都管用：先设定 AI 的角色，明确哪些工作交给它、哪些必须自己来。比如「这个 PR 你来起草，但可观测性的部分我自己写」，或者「你负责分析，我来做取舍」。
给提示词加上「防御」
所谓防御性提示词（defensive prompting），就是在关键指令前加上对预期行为的描述。我们要防的东西很具体：模型那种「无脑讨好用户」的倾向，也就是讨好偏差（sycophancy）。你问它「这个重构合理吗？」它说「完美」。你再追问，它才肯说实话，说你的方案其实有问题。
所以，别给它说「完美」的机会。换一种问法：「这个设计最值得怀疑的三个假设是什么」「照现在的做法，这事最可能的失败方式是什么」。模型很擅长给自己挑毛病，前提是你别让它不挑。
逐行审查 AI 的产出
这条规则不让步。任何模型生成的代码，想要合并就必须逐行读过、改过，而且是出于理解地去读。这可能是唯一一次由「非你本人」（尽管它是机器）替你的代码做质量把关的环节。值得你拿出独立写代码时的专注度，甚至要更严格——因为模型犯错的方式和人类不同，它的错误模式更隐蔽、更独特，错误分布也和人的直觉相悖。
没有盲区，没有「黑箱」
如果某项改动的逻辑你没搞懂，搞懂之前不要合并它。不是「先合了再说，回头补上」——必须先弄清楚，再让它进入系统。如果某个改动没有经过任何人的理解就直接上线，那这个系统就不再属于任何人了。它不再是「你和团队的系统」，等它出错时，没人会知道它为什么出错。
团队还要有足够的安全感，让大家能坦然说「这部分我不懂，谁来帮我看看」。太多因素会让工程师羞于承认这一点。主动创造这种安全感，比任何技术决策都重要。
让 AI 做辅助，而不是做代理（agent）
在有明确窗口期和验收标准的工作上，用代理没问题——比如写迁移脚本或批量处理任务。但如果你用那种「自己决定下一步、以你的身份采取行动」的东西，它必须只在一个范围内运行：无论它做什么，你都能清楚地向团队解释，并且愿意为所有后果负责。
一句话：代理可以代替你干活，但不能代替你做判断。
什么时候不适合用 AI
不熟悉的地方
如果你进入一个尚未建立认知地图的代码库，不要处处都让 AI 辅助，尤其不要让它大段大段地生成。因为这里正是它的软肋：在没有上下文的地方，AI 特别能编，而且编得很有信心。代码库越大越乱，模型对细节的掌握就越差，它的输出就越像掷骰子。
刚开始学语法、语言或框架时
学习初期，AI 相当于剧透。你追剧不会让人提前给你剧透每集，对吧？跳过那些跌宕起伏直接看大结局，有什么意思？调试排查本身就是学习——那种「假设、实验、观察、修正」的循环，恰恰是理解深度的来源。反过来做的话，你永远是那个没看过剧情、却想跟人讨论大结局的人。
高压力、高风险场景
迁移数据库 schema、接入新供应商，哪怕只是五分钟级别的事故——这种场景我明确要求团队不用 AI。手写。你可能以为自己想通了，但一定还有你没看到的细节。这种时刻，慢下来反而更快。
面试
如果在自己的面试里用 AI，那就等于在告诉对方：没有 AI，你就不会思考。不管对方能不能发现，你都输了。这个要求同时约束你团队里的每个人。
主导权是什么
我做了十一年工程师，其中大半时间处在一个「验证想法靠写」的世界里。在那个世界里，想法的质量直接体现在你写的代码里——写不出来，说明你还没想透。而如今，AI 把「写出来」这个环节变得几乎零成本，于是「想透」这件事就再也无法用「我能写出来」来掩饰了。
主导权，就是你依然能回答这样一个问题：这段代码为什么存在？为什么这么写？它的边界在哪里？如果它出错了，第一个可能的原因是什么？
如果你能回答，AI 只是你的工具；如果不能，你就是 AI 的工具。
关键要点
- 逐行审查是底线：模型生成的每段代码，都必须经你亲手读、亲手改，出于理解地去改，而不是「扫一眼没问题」。
- 提示词要「防御」：别给模型说「完美」的机会，直接问「最可能失败的三个方式」「最值得怀疑的假设是什么」，它才会说实话。
- 代理只能代劳，不能代判：让 AI 代理干活的前提，是你愿意为它的一切后果负责，且能向团队解释清楚。
- 四个场景果断关掉 AI：不熟悉的代码库、学习新语法/框架初期、高风险高压力操作、面试——这些地方 AI 不是助手，而是阻碍。
- 主导权=能回答追问：AI 把「写出来」变便宜了，「想明白」就再也无处躲藏。判断力，是 AI 时代工程师真正的硬通货。
摘要：在 AI 时代，用写作带动思考的方式没有过时，反而更值钱。工程师少写代码，不是写不出来，而是把精力放在判断和验证上；AI 生成的结果，恰好是最好的判断力训练样本。差别的关键，不是你用不用 AI，而是你是否还握有最终决定权。
写得少了，思考得更多了
「用写作带动思考」这种方式，并没有被 AI 淘汰。相反，在 AI 时代它的价值更突出。
真正做深度思考的工程师，确实写更少的代码——但这并不是因为他们写不出代码，而是他们把更多时间放在了想清楚问题上：系统应该长什么样？它需要具备哪些属性？边界条件是什么？等到这些问题有了答案，再让 AI 去填充实现细节。
代码量的减少，不代表工作量的减少。它只是把重心从「敲代码」移到了「做决定」上。
验证 AI，就是新的编程
AI 跑完一段例程后，有经验的工程师会逐行核对，确认「对，就是这样，因为……所以……」。这种行为看起来只是在检查，实质上是一种更深层的调试：验证 AI 生成的内容是否真的符合预期，本身就是编程，就是一份实打实的工作。
这也是 AI 时代最有意思的变化。以往我们调试的是自己写的代码，现在我们调试的，是 AI 的思路、假设和实现。你不需要重新写一遍，但你必须能判断它写得对不对。
判断力，需要反复练习
这个行业里最难讲清楚的一句话是：「思路很清楚，但我不确定这个设计对不对。」
判断力不是天生的，也不是一种一劳永逸的能力。它需要像写代码一样持续训练。而 AI 恰好提供了一个前所未有的练习场：拿 AI 生成的代码和自己的想法做对比。
看看它的实现，想一想：「为什么它选了这条路？代价是什么？」如果它选得更好，你就学到了一点；如果你的思路更优，你就确认自己的理解站得住。
每一次这样的对照，都是一次判断力的增长。
正确的用法：让它干活，但你来掌舵
所以，大胆用它。密集地、变着花样地用。
让它质疑你的方案，生成不同的备选路径，给思考挑毛病，做代码审查，起草初稿。这些大量、机械、重复的工作，本来就是 AI 该干的活。但最终的设计决策、验证结果、系统取舍，必须握在工程师自己手里。
对程序员来说，AI 时代的核心竞争力，不是谁更快让 AI 输出代码，而是谁能在漫天生成的代码里，认出那条正确的路。
关键要点
- AI 时代工程师的工作重心，从「写代码」转向「定义问题 + 验证输出」，后者本身就是编程的一部分。
- 判断力是练出来的，AI 生成结果与你的思路对照，是最高效的训练方式。
- 让 AI 承担机械重复劳动，但对设计方向和最终质量负责的，必须是你。