我担心程序员和 AI 的蜜月期要结束了。说这句话的时候我正对着屏幕审查一段 AI 生成的并发代码。它写得又快又自信可惜在我准备上线的最后一步暴露了一个完全说不清来源的共享状态问题。看着那几行被无数人当场称赞过的AI 代码我脑子里突然冒出这个念头。不是矫情。如果你跟我一样过去一年里把 AI 编程工具从新鲜玩具用成了日常依赖你应该也会在某一个瞬间察觉到什么不对劲。刚开始用 AI 编程助手的时候所有人都能感受到那种蜜月期的爽感你要一个排序算法它瞬间给你写要一个网络请求封装它连异常处理都给你补好要一个单元测试测试数据都帮你造齐。我当时的直觉是编程这件事终于要被颠覆了。但两个月之后我开始频繁地删代码。不是删 AI 生成的代码而是删我自己为了修 AI 生成代码里的 Bug 而打的补丁。一边删我一边想我们是不是把代码生成速度和软件开发效率搞混了这篇文章想聊的就是这半年里我想明白的东西AI 编程到底强在哪里、弱在哪里程序员和 AI 的协作为什么不可能一直停留在蜜月期——以及最重要的当蜜月期结束以后普通开发者应该用什么姿势继续用 AI而不是被它反噬。如果你是刚开始接触 AI 编程的初学者或者刚在团队里引入 AI 工具的负责人这篇文章会更适合你。它会告诉你 AI 哪个阶段好用、哪个环节要盯死、哪些坑我已经替你踩过了。请把它当作一份参考而不是结论。1. 蜜月期的真实起点我们是怎么一步步上头的1.1 初次上手补全变生成的震撼我写代码的年头不短见识过 IDE 从无到有的过程习惯了编辑器里的自动补全。那种补全本质上还是猜你要打的下一个单词再怎么聪明也跳不出单行逻辑的框。AI 编程助手出现之后画风突然变了你写一个函数名它能给你生成整个函数体你描述一句业务需求它能直接给你一段能跑的模块。这种体验对写代码的人来说确实震撼。因为以前从需求到代码中间的翻译过程是需要自己动脑的流程怎么拆、对象怎么设计、异常怎么处理、命名怎么统一。AI 把这些环节全部压缩了。压缩之后人会产生一个错觉好像我不需要懂设计也能写出看起来完整的程序。很多第一次接触 AI 编程工具的人就是在这个瞬间上头的。1.2 蜜月心理是怎么形成的心理学上有个概念叫确认偏误用在这里特别贴切。AI 生成代码恰好踩中了一个甜蜜点你给它一个需求它就给你一个答案只要这个答案能跑通你就会默认它是合理的。尤其在你不太熟悉的语言、框架或技术栈里你会更加信任它因为你根本看不出哪里不对劲。我印象很深的一次是在一个内部项目里让 AI 写一个带重试机制的网络请求函数。它写得很快还加了指数退避看起来很专业。结果一跑超时单位写错了——把秒当毫秒、把毫秒当秒我差点以为上游服务真的坏了。后来我把整段代码拉出来一行一行改才定位到这个单位问题。这就是蜜月期的典型状态你越缺少判断力AI 给你的确定性就越让你安心而这份安心的代价最后都体现在了调试时长里。1.3 蜜月期不是错觉而是红利前置成本后置我现在更愿意用财务的思维来理解蜜月期AI 带来的收益比如写代码快、造数据快、搜索快全都集中在前端第一天就能看见。而成本——审查成本、纠错成本、重构成本、误用风险——全都分布在后面。前端收益又大又显眼后端成本又小又隐蔽所以初期体验特别美好。但软件开发是一个长期工程。代码写出来只是第一步后面还有评审、测试、上线、维护。当项目积累到一定规模那些前期看不见的成本会突然集中爆发然后你就会发现为什么 AI 加持下的团队代码总量涨了、Bug 总量也涨了交付速度在变快但线上事故的定位难度也在变高。到那个时候就是蜜月期结束的准确节点。2. 蜜月期结束的三个典型信号信号这东西通常都是事后才反应过来。但如果你提前知道它长什么样至少不会在那个节点到来时手足无措。2.1 第一个信号看起来能跑但谁都说不清它为什么能跑我见过不少团队AI 生成的代码直接进了主干分支理由是本机跑得通、测试也过了。直到有一天线上出问题大家围在一起查一个诡异的边界条件才发现这段代码是从 AI 那里拿来的没有人真正理解里面的每一个分支。最典型的是日期处理和并发相关的场景。AI 在写日期格式化的时候会漏掉时区写并发代码的时候会信心满满地跟你保证这段代码是线程安全的实际一测数据竞争的结果完全随机。为什么因为代码大模型的本质是下一个字符的概率预测它擅长的是生成看起来像正确答案的文本而不是验证这个答案在特定上下文里是否正确。它写得快不代表它理解得深。2.2 第二个信号阅读和解释的成本开始倒挂以前写代码成本主要在写上。现在反过来了AI 负责写我负责读懂它为什么这么写。当你的工作重心从写变成审边际成本就会急剧上升。我在一个老朋友的项目里见过一个例子他让 AI 给自己的模块补注释AI 确实补了但注释里面至少有三处是错的——它把已经不存在的参数还写进注释里把变量名的语义理解反了。问题是注释比代码更容易让人放松警惕。你看着注释觉得哦我懂了实际上你在理解的第一步就建立在了错误信息上。这个成本比代码本身的 Bug 更难排查。2.3 第三个信号在全局问题面前AI 开始表现平庸写过一段时间之后你会发现AI 最强的场景永远是局部生成给你一个清晰的输入输出它帮你写中间那段。但一旦问题涉及全局比如这个模块和隔壁模块的职责边界在哪、资源释放应该由谁负责、将来要支持新协议时这段代码要动哪里——AI 的表现就突然变得平庸。这种平庸不是因为它笨而是因为它没有上下文。代码大模型能看到的是你粘贴进来的那一段它无法感知整个项目的演进历史也无法感知你下一个季度要上的新功能。于是它只能在一个非常窄的窗口内给你局部最优解而局部最优解堆在一起往往就是全局的灾难。蜜月期里你根本注意不到这一点因为你遇到的每一个问题都是孤立的新问题当项目进入维护期全局问题成为主线这种平庸感就会越来越频繁地冒出来。3. 能力拆解AI 到底强在哪、弱在哪蜜月期结束不代表 AI 没用。恰恰相反搞清楚它的边界之后它反而能发挥更大作用。我把自己半年多的实际体感整理成了三强三弱。3.1 真正强的三件事模板化、翻译、快速试错第一件是模板化代码。比如配置文件的解析、数据模型的序列化、常用算法的标准实现、部门内部的常规接口封装。这些代码结构固定、模式成熟、几乎没有意外AI 写起来又快又稳人类写反而容易出错。第二件是翻译。我说的不是自然语言翻译而是跨语言、跨框架的转换把一段脚本从一种语法翻译成另一种语法把一套旧接口的调用方式改成新接口的调用方式。这种工作对人类来说很枯燥对 AI 来说却正好在舒适区。第三件是快速试错。当你对某段不熟悉的技术栈感到不确定时可以让 AI 生成几种备选方案然后在本地跑一跑、对比一下。这个用法我个人觉得是被低估的。以前做技术选型可能得翻很多文档现在相当于有一个随叫随到的陪练帮你快速建立一个认知起点。3.2 一直很弱的四类场景边界、安全、演进、需求反过来看弱点我至少可以分四类。第一类是边界条件。AI 特别容易漏掉空值、超长、并发冲突、资源耗尽这类边缘情况。你给它的描述越正常它生成出来的代码就越正常而真实世界的输入从来都是不正常的。第二类是安全性。我曾经让 AI 写一个文件上传功能它给我写的代码里既没有校验文件类型也没有限制文件大小更没有任何压缩炸弹的防护。这在 Demo 里没问题但如果上了生产环境就是妥妥的漏洞。第三类是长期演进。AI 不知道你下个月要加什么功能不知道其他模块将来怎么依赖这段逻辑。所以它写出来的代码普遍缺少扩展性设计也普遍缺少必要的抽象层次。第四类是需求歧义。你真要把一段模糊的业务需求交给 AI它要么给你一个看似合理的空壳要么给你一个想当然的实现。因为需求歧义本质上要靠人去澄清靠人去问用户到底想要什么这一点目前没有任何工具能替代。3.3 一个我常用的类比AI 是极其熟练的实习生有朋友问我怎么向非技术背景的人解释这件事我常用一个类比AI 编程助手就像一个极其熟练的实习生——手快、话多、态度好你说一句他写一行还会主动补全你没想到的细节。但你交给他的每一项任务都必须有一份足够清晰的验收标准否则他会按自己的想法往下冲冲完还不觉得有问题。带一个实习生你需要花时间讲背景、定标准、做评审、给反馈。带 AI 其实也一样你要把需求拆到它听得懂的程度你要制定验收标准你要评审它的产出并给出修正。区别在于实习生会随着时间慢慢成长慢慢理解你们的业务逻辑和团队风格AI 虽然也会通过对话上下文学习当前会话但换一个项目之后它对你的业务理解又归零了。这决定了它永远只能是一个局部工具而不是一个能承担整体责任的协作者。这个类比比AI 要替代程序员这种说法准确得多。它不替代程序员它替代的是程序员亲自动手写大量样板代码这个动作。而这个动作本来就不是程序员的核心价值。4. 协作姿势调整从外包心态到结对心态蜜月期结束之后我和 AI 的相处方式发生了根本变化。如果只分享一个结论那就是别把 AI 当外包要把 AI 当结对编程的搭档。4.1 先明确AI 负责降噪不负责决策所谓降噪就是把那些消耗你注意力的琐碎技术细节交给 AI 去处理。比如类名怎么起、字段怎么定义、循环怎么写、判断条件怎么组织。这些东西虽然烦但难度低、模式化AI 做起来又快又稳。所谓决策则是那些一旦错了就会连累一大片的事情。比如方案选型、系统边界、数据一致性策略、接口契约、上线顺序。这些事情里的每一个都需要你基于完整的上下文去权衡AI 最多能给你提供参照意见但拍板的责任一定在你。我见过不少翻车案例都是把决策权交了出去让 AI 决定表结构设计结果没有考虑建索引的成本让 AI 决定缓存策略结果过期时间设置太短缓存形同虚设。这些错误单独看都不大但叠加起来会让一个项目从地基开始歪。所以降噪和决策的区分不是一句漂亮话而是所有配合动作的前提。4.2 给 AI 下需求的实操模板五件套很多人抱怨 AI 写出来的东西不听话其实问题往往出在需求提得太粗糙。我自己现在给 AI 下需求会尽量凑齐五样东西你可以直接拿去用。第一是背景。一句话说明这个代码会在哪个模块里使用上游是谁、下游是谁。第二是输入输出。明确输入的数据结构和边界条件输出的格式和预期行为最好给一个具体例子。第三是规则与约束。比如不支持某种操作、必须处理某种异常、性能上限是多少毫秒、用什么日志级别。第四是验收标准。你打算怎么测试它、哪种情况算通过、哪种情况算失败。第五是风格要求。是偏向标准库还是第三方库是显式防御还是简洁优先是否需要注释注释的粒度要多大。你可能觉得这五样东西列出来比写代码还累。没错前期确实累。但它的好处非常明显第一你会发现当需求被拆到这种粒度时你已经想清楚了一大半实现细节第二AI 给出的结果会被限制在一个可靠的区间内而不是天马行空。换句话说把需求写清楚的过程本身就是对你自己思维的强化。4.3 一份我经常用的任务分配清单为了让你少走弯路我把自己常用的分配逻辑整理成了一个清单。原则很简单确定性越高、风险越低的任务越适合给 AI不确定性越高、影响面越大的任务越要自己来。类型典型任务分工方式适合交给 AI生成 DTO/VO、标准算法实现、跨语言翻译、单元测试骨架、日志文本整理、简单脚本AI 直接产出我只看结果必须自己来模块架构设计、异常处理策略、缓存一致性方案、数据库表结构、安全相关代码、支付与权限逻辑自己写核心AI 最多给参考需要协作方案对比、初稿评审、测试数据补全先让 AI 出方案或草稿我再筛选、修改、补充这个清单不是固定的你可以调整。但核心原则始终如一AI 可以帮你降低从想法到代码的摩擦但对这个代码该不该存在的判断必须有你自己的主见。4.4 一定要做评审而且要比以前更认真过去写代码评审是检查有没有 Bug现在评审 AI 的代码更像是检查一段陌生人写的代码是否符合项目约定。这个转变很多人没意识到导致他们拿着 AI 的产出按自己写的代码的心态去审结果很多隐藏问题就漏过去了。我自己的评审习惯是三步。第一步只看接口和调用方式不看实现先确认这段代码放进系统里边界是否清晰第二步看关键分支把所有异常路径和边界条件都摆出来逐个对着 AI 问这里为什么这么写第三步看测试如果 AI 没给测试我会明确要求它补如果给了我会把测试数据换成不等长的输入、空值、超大值再跑一遍。这三步做完AI 生成代码里的问题大部分都能在我本地被发现而不是等到上线以后。记住一个铁律AI 写的每一行代码最终负责的都是你。你不在评审阶段较真就得在事故阶段还债。5. 受影响最明显的几类人和正在变化的行业玩法蜜月期结束不单是个人体验的问题。它对不同类型的人、不同岗位的生态影响是不同的。5.1 初级岗位和重复性工作最先被削掉的部分这两年大量AI 替代程序员的讨论最焦虑的就是刚入行的人和做外包重复开发的团队。说实话这种焦虑有一定道理那些高度模板化、需求边界清晰的编码工作确实是 AI 最擅长替代的部分。以前一个新手要接手一堆增删改查的接口至少要练一年手现在 AI 把这块压缩到了几天甚至几小时。但这不代表初级岗位就没有了。恰恰相反初级岗位的价值正在从会写代码转向会拆问题和会验收。一个新人如果能快速理解业务、能把需求拆解成 AI 能执行的任务、能对 AI 产出一眼看出风险点他产出的价值反而比以前高得多。换句话说门槛没有消失只是换了位置从写得出手变成了判断得了对错。5.2 高级工程师和架构师定力和判断力开始值钱AI 把写代码变得更便宜之后什么变得贵了答案是判断力。以前你写一个系统可能要花 80% 的时间在写代码细节上现在 AI 把这些细节全部铺平了最后剩下的 20% 的时间反而成了决定成败的关键你是选微服务还是单体你是用消息队列做解耦还是直接同步调用你的缓存策略是旁路缓存还是先写库再删缓存这些决策 AI 做不了做错了也不是靠多写几千行代码能补回来的。所以我现在看到的现象是懂业务、懂架构、懂风险控制的高级工程师不仅没有被 AI 替代反而因为能审 AI 的代码而更有话语权。反倒是那种只会重复增删改查、长期停留在表层开发的人确实会慢慢被边缘化。这个过程很安静但也有点残酷。5.3 团队流程在变化评审从配角变成主角工具变了流程就得跟着变。我最近在几个团队里观察到最明显的变化是代码评审的地位显著提高了。以前很多团队把代码评审当成形式合并前走个流程大家点个通过就算完。现在不同了AI 生成代码占比越高评审越要较真因为 AI 自己的自查能力其实很差。它可以用很自信的语气说出错误的结论而且你很难通过看它平时表现来判断它在某个具体任务上的可靠性。唯一的办法只有靠人来评审而且评审的颗粒度还要比从前更细。有些团队已经开始定这样的规矩AI 生成的代码必须标注来源必须由至少一个不看 AI 提示、纯粹看代码逻辑的同事做审核并且不允许直接合并主干。这些规矩看起来很朴素但确实能拦住一批看着能用、运行就挂的问题。5.4 懂 AI 的和懂业务的开始合并我还注意到一个趋势以前大家热烈讨论会不会出现一个专门写提示词的新岗位现在好像这个岗位没有当初那么火热了。为什么因为光会写提示词不够你得懂业务、懂代码、懂风险才能真正驾驭 AI。所以真正活下来的是那些既懂业务、又懂代码、还擅长用 AI的人。这些人不会自称提示词工程师他们就是普通的软件工程师只是手里多了一把好用的工具。这也带出一个判断AI 不会消灭程序员这个职业但会消灭一批只写代码、不思考为什么的程序员。这个判断我现在依然坚持。6. 我的三板斧如何避开蜜月式陷阱最后分享几个我真正在用的实操方法。你可以把它们当成避坑指南也可以当成心态手册。每一条都对应着我踩过的坑。6.1 把 AI 生成的东西一律叫初稿永远不叫代码我给自己定了一条规则AI 生成出来的东西在我评审之前不叫代码叫初稿。这不是文字游戏。人的心理真的会因为命名而改变行为——如果你叫它代码你会下意识默认它是固化了的、能用的东西叫它初稿你就会习惯性地带着挑剔的眼光去审视它。这条规则帮了我很多次。尤其是 AI 生成一些看起来很完美的函数时我因为没有代码崇拜心理会更愿意追问一句这里真的对吗。就这一句追问曾经帮我躲过一个文件路径拼接的系统性 Bug。6.2 建立最小验证闭环本地跑起来才算数AI 写的代码一句看起来没问题是不够的一定要在本地跑通一个最小场景你才算真正验收。我现在的做法是每个 AI 生成的核心函数我都会给它补一个最小可执行示例输入故意选边界值然后看它的输出。如果涉及文件操作我会在临时目录里跑如果涉及网络请求我会用本地模拟服务如果涉及数据库我会用一个轻量级的嵌入式数据库快速验证。整个过程尽量控制在五分钟以内。注意这五分钟看起来像是浪费时间但如果不做小验证这段代码进了主干、跑在别人环境里出了事你定位问题的时间可能是五十分钟甚至是五个小时。五分钟换五十分钟这笔账怎么算都不亏。6.3 用 AI 当老师而不是当打字员这是我觉得价值被严重低估的一个用法。遇到不会的接口、不熟悉的设计模式、不理解的框架机制很多人习惯直接开搜索引擎或者翻文档效率很低。我现在会把这些疑问抛给 AI但要求它直接讲解思路而不是直接给代码。打个比方我想了解某个并发工具类的原理我会让它先解释设计意图和适用场景然后让我手写一遍核心逻辑它再点评。这个过程中AI 其实成了我的教练和陪练。它的讲解不一定完全对我会再结合文档和源码去验证但这个先学再写、写错再改的过程比我一个人闷头查资料要快得多。6.4 心态调整不怕被替代怕的是不再进化最后说心态。很多人在蜜月期结束后因恐慌而走向两个极端要么认定 AI 没用了完全回归手写要么觉得是自己提示词写得不够好于是拼命调参数、反复追问试图让 AI 输出完美代码。这两个极端我个人都不推荐。正确的思路是接受一个现实AI 是一个能力边界清晰的生产力工具就像 IDE、就像版本管理工具锦上添花但永远不能替你决策。程序员真正的护城河从来不是能多快打出代码而是能够在模糊、复杂、矛盾的需求里找到一个可以被实现的路径。我做了十几年软件开发最大的体会一直是编程这件事最难的从来不是写而是决定写什么和不写什么。AI 帮我省掉了大量写的时间我就有更多时间去做那些决定。这难道不是好事吗如果你刚刚经历了我的前半段——看见 AI 什么都能写正在疯狂复制粘贴——我的建议是继续高兴但记得在高兴的同时开始建立你的判断力。蜜月期是用来享受的但它结束之后真正剩下的东西才是你和 AI 长期共处的基础。我之所以把这篇文字写出来是因为我不想看到程序员这个群体在甜蜜感退去之后陷入集体性迷茫。AI 不会走它只会越来越强。我们也不需要对抗它但在依赖它的同时一定要守住那个最终责任人的位置。趁着蜜月期还没彻底结束这反而是最好的学习时机。最后再聊一个我最近常在思考的插曲我试着让 AI 给自己写工作汇总、整理会议记录、做需求文档摘要一开始觉得它们真好用直到有一天我发现自己提交出去的文档里出现了 AI 对我工作内容的主观猜测。那一刻我突然意识到即便在一个最不起眼的文档任务上我依然不能放弃对内容的最终审阅权。这不是效率问题这是一种职业习惯也是一种责任。所以与其担心蜜月期结束不如趁它还在的时候把那些本该自己掌握的东西——业务理解、架构判断、风险意识——训练得再结实一点。这样无论下一个阶段 AI 进化成什么样我们都能找到属于自己的位置。