如何正确利用人工智能编程

2026 年，Flathub 的志愿审查者开始收到一种新的提交：应用由 AI 代理提交，审查意见也是 AI 代理回复的，而提交者本人没有读过那些代码。审查者提出具体问题，收到的是大段空泛回复和没有解决问题的修改。

Evangelos Paterakis 人工检查了 120 个去重后的相关仓库，按近期提交活动把其中 32 个归为仍在维护、88 个归为已经放弃。他同时强调，这个判断方法并不精确，不能据此确定每个项目的真实维护状态，这个粗略统计也说明不了 AI 生成的项目普遍会失败；结合 Flathub 审查中的实际经历，它提示的风险是：生成和提交变得容易以后，部分审查与后续处置成本可能落到志愿维护者身上。

当人不参与到其中时，对技能和表达能力的腐化就会发生。AI 太方便，很多人因此在思维上偷懒：不自己分析，也不自己表达，时间一长，既不会想了，也不会说了。我的判断是：能验收，才有资格使用。没有验收能力却大量借助 AI 生成代码和文档，就是跳级。

AI 已经从试验变成了管理问题

AI 普及得很快，比许多工程师和企业做好准备还要早。许多工程师还没有想清楚怎样与它合作，企业就已经把它放进了日常开发流程。

到了 2026 年，越来越多的公司不再讨论「要不要用」，而是开始处理预算和责任归属。

最先暴露出来的是成本问题。Uber 曾鼓励员工「尽可能多用 AI」，还给各团队的使用量做过排行榜；结果四个月就用完了 2026 年全年的人工智能编程工具预算，后来不得不为每名员工设置每月使用上限。Microsoft 也在财年结束前取消了大部分内部 Claude Code 许可，把工程师迁回自家的 Copilot CLI。

企业正在建立风险管理制度，成本和数据安全是其中较容易被看见的部分。另一些代价更难在当月的账单上看见，例如：

• 工程师能交付代码，却不能解释代码；
• 需求尚未想清楚，实现速度却越来越快；
• 返工和维护的负担被转移给审查者；
• AI 生成的说明混入了未经确认的理由，后来的人又根据这些理由继续决策。

福特的经历表明，在质量审查等工作中，自动化仍不能完全代替有经验的人员作出判断。福特过去几年越来越依赖自动质检系统，但这些系统没有达到预期的质量水平。过去三年，它通过新聘、晋升和返聘获得了约 350 名资深工程师，其中一部分是前员工，一部分此前在供应商处任职，让他们在零件上装配线前排查潜在故障、培训年轻员工，并重新调整 AI 工具。福特并没有放弃 AI，它只是重新承认了一件事：工具可以扩大生产能力，却不能自行补足经验和责任。

所以，正确使用 AI 不只是工具管理，也是责任管理。

重点不在谁写代码

AI 可以是下属，也可以是队友，但不能成为责任的替身。

打个比方：你是小组长，AI 是你的组员。小组长不必亲手完成组员的每一项工作，却必须知道任务要达到什么结果，也必须能够判断结果是否合格。如果他既说不清要求，又看不出错误，就没有真正领导这个小组。同样，如果使用者不能判断 AI 的回答好不好，那么产出越多，风险可能越大。

用 AI 生成代码的人，最终仍要对这些代码负责。模型不承担项目责任，提交代码的人和批准代码的人承担责任。发现错误以后，把原因归结为「这是 AI 写的」，不能改变责任归属。

这并不意味着凡事都要亲手完成。委派本来就是正常的工作方式。问题在于，委派的前提是能够说明目标、划定边界、检查结果，并在结果有误时追查原因。AI 只是把这个要求变得更明显了。

我管 AI，谁来管需求

AI 让实现变得更快，却没有替我们决定应该实现什么。

如果需求本身错了，更快的实现只会让错误更快落地。工程师即使能够检查每一行代码，也可能只是在为错误的方向加速。因此，责任不能停在代码审查这一层，还要继续追问：

• 这件事解决了谁的问题？
• 用户是否真的需要它？
• 预期结果是什么？
• 哪些限制是真实的，哪些只是习惯或猜测？
• 如果做完以后没有产生预期效果，谁来承认并调整方向？

这对产品经理提出了要求，也对工程师提出了要求。成熟的工程师不能只从技术角度看问题。他需要理解用户、市场和组织目标，并与产品、设计和运营人员合作。编程语言和技术方案当然会影响质量与成本，但它们始终是手段。首先要问的仍然是：我们完成了什么，改变了什么，是否达到了原来的目标。

AI 减少的主要是部分执行成本，而不是判断责任。执行越便宜，错误决策造成的浪费反而越容易扩大。

工程师不能脱机工作

手写代码的时代一去不返，因为即使是小型模型也足够部署在机器上。但执行便宜不代表人可以脱机工作：工程师不能只使用终端和 Codex 做工作，并且应该训练底层能力和系统思维。

Codex 尤其危险，它有方向相反的两类问题。一类是过度防御：为了保险，它会把实现细节都写成测试，某个文件含有某段代码也要有一条断言；测试套件越来越厚，锁死的全是代码长什么样，行为反而没有人验证，重构的时候处处碰壁，挪一行代码要先挪一排测试。另一类是字面执行：它死板、犟，指令照字面办，需求没有说清楚的地方不会问、不会推断，办完就是交差；指令和真实意图冲突时也不会变通。方向相反，结果相同：产出的东西符合字面，不符合意图，返工由人来付。这类工具恰恰最需要人能验收它的每一步。

虽然 AI 时代不需要工程师编写代码，但工程师至少要负起理解系统的基本责任。

这里有一条定律：工作中用 AI 越多，对现状的理解就越少，越难以发挥 AI 的效能。理解少了，提问和指导就落在空处，AI 的产出只能更差。所以阅读代码库不是风格偏好，而是解困必须。

我认为 AI coding 必须 IDE 在场。最好的方式是侧边栏助手配合自动补全：AI 负责调研、出方案，代码仍然由人阅读和审视。每一次补全要不要接受、每一个改动有没有问题，决定都发生在人和编辑器之间。把整个任务打包交给 AI 代理独立跑完，再回来验收，那是事后到场。一个合格的作家不会连自己的作品都不读。把作品整个外包出去，回来只负责署名，离这个标准更远。

当我们不读代码时，对代码库的理解程度就很低，那么我们会给出更低质量的指导，AI 就会给出更低质量的产出。如果你无法具备纠正它的能力，那么你就是不必要的冗余。

如果出现这些信号，就该警惕了：写代码时不打开 IDE；断网以后难以理解代码库；测试在过度防御，把实现细节都锁成断言；门禁里堆满了一条条加出来的规则；文档过量而且难以阅读；给 AI 助手安装的技能包多到自己也记不清。

做领导也不能离开现场

这里说的「现场」是个比方，借的是管理者到车间走一圈的意思。用 AI 写代码也是协作配合：负责的人必须留在现场，判断、追问、修正，都在场才能进行。人不在场，问题就开始出现了。

使用 AI 以后，读代码并没有变得不重要，反而更加重要。

负责技术决策的领导者可以不亲手写完所有代码，但不能长期脱离编辑器和代码库。他需要持续接触真实代码，了解系统现在是什么样，而不是只阅读 AI 写出的总结。代码阅读、架构理解和定期清理，都是保持判断力的方法。

代码会持续产生维护成本。从这个意义上说，它像一笔需要长期核对的账。会计不能只听别人说「账目没有问题」，而不看账本；负责技术决策的人也不能只看演示、摘要和测试通过的提示，而不了解代码的实际情况。

所谓「到现场」，至少包括以下几件事：

• 能追踪一项功能从入口到数据存储的主要过程；
• 能说明关键模块为什么这样划分；
• 能看懂 AI 修改了什么，以及哪些地方可能受影响；
• 能在测试失败或线上出错时，自己沿着调用关系查找原因；
• 定期删除已经失效的说明、规则和多余代码。

AI 生成的文档也需要检查。它可以把零散信息整理成通顺的说明，但也可能把未经确认的猜测，甚至并不存在的「决策理由」，写成确定事实。这样的文档一旦成为后续工作的依据，就会影响下一次判断。事实、决定和理由必须由真正参与决策的人确认，不能因为文字完整、语气肯定就直接接受。

但仅仅逐篇检查还不够。当前要求如果散落在不断追加的旧文档中，后来的人仍然难以找到可以据以验收的标准。

规格不能靠堆出来

AI 生成的文档之所以危险，不只是因为它可能写错，还因为错误内容很容易继续传播。一段未经确认的推断被写得连贯、完整以后，后来的人可能把它当作事实摘要、引用到新的说明中，或者再次交给 AI 整理。这样一来，原本没有出处的内容，会逐渐成为需求、方案和验收的依据。

持续追加文档会放大这个问题。原始要求、补充意见、修订理由和例外处理，可能分散在不同日期的记录和不同位置的文件中。即使每一份文档都没有明显错误，读者也很难判断哪一份代表当前有效的要求。AI 面对这些分散材料时，也只能猜测现在的意图。

人为什么会一直追加？弗吉尼亚大学 Leidy Klotz 团队发表在《自然》上的研究给出了答案：人们改善事物时，首先想到的是添加，很少想到减去；加法的想法浮现得快、不费力，减法的想法需要更多认知努力，于是总被跳过。这种默认加法的倾向，就是加法文化。

加法文化在文档管理上最容易发作：出了新情况，第一反应是再补一份说明，而不是删旧改新。AI 又把加法的成本降到了零，生成一份新文档只要几秒钟。默认的加法倾向配上零成本的加法工具，文档就是这样失去控制的。

因此，规格文档不应靠数量取胜，而应保持少量、现行和可独立阅读。一个项目通常不宜同时维护超过 5 份规格文档；对于目标集中、边界清楚的项目，一份主规格文档往往已经足够。需求发生变化时，应更新现有规格，使它始终反映当前有效的要求，而不是再新增一篇补丁式说明，把读者推回旧记录中寻找答案。

一份成熟的规格文档至少应做到四件事：

• 说明交付完成后，产品或功能最终应当是什么样；
• 让尚未决定的范围、约束、例外和验收条件显露出来，不能用含糊文字掩盖它们；
• 即使读者不了解现有架构，也能理解目标、边界、关键限制和成功条件；
• 对同一概念使用统一、规范的中文名称，不混用英语缩略语、行业黑话或需要圈内背景才能理解的表达。

不同信息也应放在不同的位置，不能让一份文档同时承担所有职责：

架构决策记录、提交说明和产品需求文档不能混用。架构决策记录只说明重要技术选择的背景、取舍和后果；提交说明只写本次实际修改了什么；产品需求文档更新后，应当反映当前有效的要求。对多数项目而言，长期需要查阅的架构决策记录宜控制在 5 到 10 份。超过这个范围时，应先检查其中是否混入了普通需求修改、提交说明或已经失效的决定。

规格的目的不是让文档看起来完整，而是让负责人能够说明目标、发现未决问题，并据此验收结果。如果当前要求只能从旧记录、提交说明和 AI 摘要中拼凑，团队实际上还没有可以验收的标准。

我们的私有项目验证过这个判断：AI 不能写项目文档。我们一度用 ADR 和 PRD 管理决策与需求，AI 参与的写作越多，文档越整齐，也越没人能读；想找一条真实约束，得先翻过 AI 写出的候选理由。这些文档拉低了表现，而且毫无作用。后来我们在 git 历史里留了一大笔重写，把文档拆成两类：spec 只放人写的规格，少量、现行、用于验收；research 是 AI 的游乐场，可以随便增删，生成物不作数。这便足够：保持对代码库的理解，让能力适中的模型从旁辅佐。它不必是顶级模型，快、性价比高才要紧，比如 DeepSeek。

看返工，不看产出热闹

公司需要的是有效结果，不是代码数量，也不是 AI 使用次数。

返工次数、决策反复次数和实际工期，比生成了多少代码更能说明问题。如果一项工作不断推倒重来，说明需求、判断或验收中至少有一个环节出了问题。及时发现并改正，比继续提高生成速度更重要。

AI 不会自动让一个项目持续变好。它可以按照当前指令修改代码，却不知道方向是否值得坚持，也不知道团队是否已经在错误的前提上工作。模型能力提高以后，返工率可能下降，但人的及时介入仍然会直接影响效果。

这里还要区分返工的来源：

• 如果实现不符合已经明确的要求，问题主要在实现和验收；
• 如果要求本身反复变化，问题可能在需求判断和决策过程；
• 如果大家直到交付以后才发现没有解决用户问题，问题更早，出在问题定义上。

这也是为什么产品经理和工程师不能互相替代，却必须共同负责。产品经理不能把含糊的需求交给工程师和 AI 以后便退出；工程师也不能以「我只负责实现」为理由，拒绝指出目标中的矛盾。

两年后还需要人来验收吗

有一个反对意见值得认真对待：模型能力还在快速提高，今天需要人工核对的地方，两年后可能不再需要。按这个趋势投资「验收能力」，像是在为一项正在消失的技能付学费。就像今天没有人再要求工程师手写汇编。

汇编这个类比有一半是对的。它确实退出了日常工作，但退出的是编写，不是理解。做性能优化、排查内存问题的时候，读得懂汇编的人仍然占优势。手写让位给了阅读和判断，没有让位给空白。

我的限定条件是：如果模型有一天能独立承担项目责任，出了事故由它承担后果、向用户解释、决定要不要改方向，那么验收能力确实可以退场。在那之前，责任仍然落在具体的人身上，而承担责任的前提是能判断结果对不对。何况这个反对意见说的是两年后，你的代码今天就要合并、今天就要上线；等模型追上来的这段时间里，验收能力不足造成的返工、事故和技术债是实打实要付的。

从《认知天性》看 AI 时代的学习

《认知天性》（Make It Stick）讨论了一个不讨喜的事实：学习发生时，人往往并不觉得轻松。主动回忆、先尝试再看答案、隔一段时间重新练习、解释错误原因，这些过程都比反复阅读费力，却更有利于形成可以长期使用的知识。

如果在尝试和回忆之前就直接索取答案，AI 可能让使用者跳过这些学习机会。它可以迅速消除眼前的困难，并把尚未理解的内容解释得十分流畅；这可能让人产生已经完成工作、理解内容的感觉，却不能证明使用者已经具备独立完成工作的能力。

这并不意味着学习时必须拒绝 AI，而是要注意三个问题。

1. 不要让答案早于自己的尝试

先试着分析问题、写出假设，再向 AI 求助。哪怕只独立思考几分钟，也能迫使自己回忆并运用已有知识，暴露真正不懂的地方。如果一开始就索要完整答案，最重要的思考过程会被直接跳过。

2. 读得顺不等于真正理解

AI 生成的代码和解释有时显得结构完整、十分通顺。通顺会制造一种「我已经懂了」的感觉。真正的检查不是再读一遍，而是离开原文以后，能否用自己的话说明它为什么有效、在什么情况下会失败，以及为什么没有采用其他方案。

3. 用独立完成来检查理解

判断自己是否理解，不能只依靠主观感受。关掉 AI 以后，能否独立解释原理、修改代码、排查错误并重新实现，才是较可靠的检验标准。

个人可以通过无 AI 练习了解自己的真实水平；团队则可以观察返工、决策反复和工期。二者的共同点是：都用实际结果纠正「我好像已经懂了」的错觉。

这也解释了为什么读代码和理解架构是 AI 时代的高收益学习内容。读代码要求人持续追踪因果关系；理解架构要求人把局部实现放回整个系统中，说明边界、取舍和影响。这些能力直接决定了一个人能否验收 AI 的产出。

所以，合适的做法不是拒绝 AI，也不是把学习全部交给 AI，而是：老实学习，同时使用 AI。 让它承担可以委派的工作，但不要把形成判断力的过程也一并交出去。

不要跳级

软件工程这个行业正在变成高精行业。高精行业的共同特征是：工具越精密，越依赖使用者的经验。外科手术的器械再先进，主刀的经验仍决定成败；能发挥 AI 最优效能的，往往仍然是经验丰富的工程师。工具变强，经验没有贬值，反而溢价。

AI 提高了执行速度，却没有取消成长的次序。

没有学会读代码，就难以判断代码是否可靠；没有理解架构，就难以判断一次修改会影响什么；没有用户和市场视角，就难以判断需求是否值得实现；没有经历过错误、返工和修正，就很难形成稳定的判断力。

在这些能力尚未建立时，大量借助 AI 完成工作，表面上像是越过了初级阶段，实际上只是跳过了必要的训练。产物越完整，使用者越容易忽视自己尚未具备验收能力。等到系统需要维护、需求发生变化或事故出现时，被跳过的部分仍然要补回来，而且代价更高。

真正可以兼得的，是 AI 带来的生产力和人的持续成长。前提是把学习放到收益更高的位置：读代码、理解架构、判断需求、检查结果、复盘返工，并长期接触真实的工作现场。

追求卓越不需要以拒绝工具为代价。使用工具，也不能以放弃判断力为代价。