同事问我你代码都让 AI 写那我们开发的意义是什么呢？

cover_image

前几天, 同事看着我用 AI 改需求, 突然问了一句： “你代码都让 AI 写了，那我们开发的意义是什么？”

我当时停了一下。不是因为我没听清。
是因为这句话，确实问到了心口上。

最近这段时间，
我做一些需求，真的可以一行代码都不写。
我把目标说清楚，把项目上下文喂进去，让 AI 去读文件、改代码、跑命令、修报错。我坐在旁边，像个监工。
有点爽。
也有点发毛。

如果放在一两年前，我会觉得这像科幻。
现在，它已经是日常了。
所以同事那句疑问，不是抬杠。
它是很多开发者心里都没敢认真回答的那个问题。

那一瞬间，我也有点慌#

我们这一行，过去默认有个朴素信念：会写代码，很重要。
写得快，写得稳，写得漂亮，更重要。
可 AI 一下场，最先被冲掉的，偏偏就是这部分。语法记忆？
API 熟练度？
样板代码的手速？
甚至很多过去要查半天文档、改半小时报错的活，现在一句话就能起飞。
说实话，这有点残忍。你辛辛苦苦练出来的肌肉，机器突然告诉你：这个动作我 3 秒就做完了。
如果「开发」只等于「手写代码」，那这个职业的确会越来越尴尬。但我后来发现，问题可能问错了。
开发的意义，从来就不只是敲键盘。
只是以前代码太贵了。
贵到我们误以为，代码本身就是工作的全部。

同事说得也没全错#

同事还有一句话，我其实是认的。
他说，你这个需求比较简单、比较独立，所以 AI 才能接得住。
要是真到了那种牵一发动全身的系统，事情就没这么简单了。这判断，不算错。
越复杂的项目，越容易藏着一堆看不见的坑。
一个字段名改了，可能会影响另一个服务。一个看似无害的逻辑，可能会把线上某个老流程打断。
还有些更麻烦。文档里没写。
代码里也看不出来。
但团队里总有人知道：这个地方不能乱动。 AI 现在最容易踩的，就是这种坑。它能把表面写得很像那么回事。
可一到隐藏约束、历史包袱、跨模块副作用，马上就容易露馅。所以我越来越觉得，复杂项目里，人不是因为「字打得更快」才重要。
而是因为人知道，哪儿能改，哪儿不能改；哪儿可以赌，哪儿必须稳。

后来我慢慢想明白了#

最近我听了不少一线工程师聊 AI 编程，也看了一些行业报告。

有一个事实让我挺震撼的：

Claude Code 的负责人 Boris Cherny 说，自从 Opus 4.5 之后，他就再也没手写过一行代码了。

他甚至觉得，编程问题已经在很大程度上被解决了。

（是的，做 AI 编程工具的人，自己都不写代码了。你品品这事儿。）

听到这话的时候，我说实话是有点恍惚的。

但仔细一想，他说的不是「工程师没用了」。

恰恰相反——他的核心理念是：不要为今天的模型构建，要为六个月后的模型构建。

也就是说，模型只会更强。

那人的价值，就会往别的地方挪。

想想也是。

说白了，很多 App 的底子，无非就是把数据拿进来，改一改，再展示出去。

AI 对这种活，天然不抗拒。真正变贵的，反而是另外几件事。

写代码之前，先得把事想清楚#

很多人以为提示词是咒语。其实不是。
现在好的提示词，更像一份需求文档。
你要说清楚目标是什么。
边界是什么。
什么不能碰。
什么算完成。说白了，你不是在教 AI 写代码，你是在定义一件事到底该怎么被做成。
这一步，谁都绕不过去。

而且我发现，

自从我开始认真写提示词之后，反倒比以前更擅长做需求分析了。

因为 AI 逼着你把模糊的想法一条条掰碎了说清楚——以前你可以靠自己脑子里「差不多知道」，

现在不行了，你得真的知道。

你不是写代码的人了，你是带团队的人#

我现在特别相信一件事：

真正厉害的开发，不是一个人闷头把所有代码写完。
而是能把一团乱麻，拆成几块清楚的东西。
哪一块让 AI 去生成？
哪一块让 AI 先出方案再评审？哪一块必须自己盯着？哪一块先别动？
有时候我会同时开几个 AI 会话。
一个查问题。
一个改前端。
一个补测试。

我更像是在带一组不会喊累、但偶尔会一本正经胡说八道的实习生。

OpenAI 工程负责人 Sherwin Wu 分享过一个数据：

能同时调度 10 到 20 个 Agent 的工程师，和不会用的工程师之间

产出差距高达 70%。

这个数字挺吓人的。

但仔细一想也正常——你带过人，就知道怎么分配任务、怎么做 review、怎么兜底。

你没带过，就很容易被 AI 带沟里去。

AI 会写，但「写对了」得你说了算#

这是我这段时间最大的感受。
AI 会写。
但「会写」不等于「写对了」。
有些功能，看起来能跑。
点两下，也没报错。可一上真实数据，一上边界条件，一上线上环境，问题就出来了。
所以后来我越来越在意一件事：别只让 AI 写，还要让它自己去验证。

单元测试、接口测试、浏览器里走一遍、截图对比——什么手段都行。

我之前看过一个说法特别认同：

只要是能被验证的东西，就可以放心交给 AI。

反过来说，凡是不可验证的部分，你就得格外小心。

功能代码？写测试验证。

接口逻辑？写接口测试。

页面交互？跑 E2E。

一旦验证链条跑通了，AI 交付的就不是「可能行」，而是「确实行」。

翻译成人话就一句：

别信它那张嘴，要信跑出来的结果。

最后兜底的那个人，还是你#

这一点，AI 现在还替不了你。
功能要不要上？
体验是不是顺手？
有风险要不要回滚？
这个改动会不会影响别的团队？这个需求做出来，到底对用户有没有意义？
这些问题，不是代码能回答的。
代码只能执行。
判断，还是得人来做。
更现实一点说，线上出了事故，AI 不会来开复盘会。
楼塌了，也不能让 AI 去派出所做笔录。（虽然这么说有点损，但你明白我意思）

Anthropic 前段时间发了一份 Agent 编程趋势报告，里面有句话说得特准确：

AI 放大的是工程师已有的判断力，而非凭空替代它。

系统设计、任务拆解、质量验收——这些老功夫在 Agent 时代反而更值钱了。

写代码这件事会越来越像流水线，但「负责任」这件事，短时间内还是手工活。

对初学者，我反而更想多说两句#

有人会问：那以后是不是都不用学编程了？

我觉得不是。
如果一个刚入门的人，上来就把所有东西都丢给 AI。
自己连最基本的判断都没有。
那大概率不是捷径，是欠债。因为你连它错在哪儿，都不知道。
更别说改。
对初学者来说，AI 是放大器，不是免学卡。

但反过来看，AI 也是这个时代最好的老师。

你可以让它解释。
让它重写。
让它比较两种方案。
让它告诉你，为什么这次这么设计。
以前学编程，很多人卡在没人带。现在最大的变化，不是老师消失了。
是老师 24 小时在线了。

有个工程师说过一句话让我印象很深：

用 AI 学习，一年掌握的架构和设计知识比过去五年都多。

前提是你愿意追问，而不是无脑复制粘贴。

而且以后，很多原本不写代码的人，也会借着 AI 把想法做成工具。
这个门槛一定会降下来。但一旦东西要长期跑、多人协作、还要扛责任，工程能力还是会重新浮出来。

那以后，开发还重要吗？#

我现在的答案是：重要。而且可能比以前更重要。
只是重要的地方变了。
以前我们像泥瓦匠，一块一块砌墙。
以后更像工头，也像设计师。要看图纸。要拆任务。要验结构。
要决定哪里能快，哪里必须慢。
说得再直白一点：以后「会写代码」的人当然还在。但更贵的，是会拆系统、会验收、会判断、会负责的人。
很多人担心，AI 把开发变得不值钱了。
我倒觉得，AI 只是把那些原本就不该那么贵的部分，先打下来了。
真正值钱的东西，反而露出来了。
产品感。
架构感。
边界感。
还有对人的理解。因为软件走到最后，服务的还是人。
不是模型。
不是跑分。
也不是那一行漂漂亮亮的 Success。

最后，回到同事那句话#

如果下次再有人问我：「你代码都让 AI 写了，那我们开发的意义是什么？」

我大概会这样回答。

开发的意义，不在于你亲手敲了多少行代码。

而在于你能不能把一个模糊的问题，变成一个能落地的系统。

能不能把一个会胡来的机器，收拾成一个靠谱的帮手。能不能在速度越来越快的时候，还知道什么地方不能快。

能不能在一切都能自动生成的时候，还保住对用户的感觉，对风险的敬畏，对结果的负责。

代码会越来越不稀缺。
但判断，不会。
责任，不会。
对人的理解，也不会。
所以不是我们没意义了。

是我们终于要从「写代码的人」，重新长成「做产品、做系统、做决定的人」。
这事有点吓人。
但说实话，也挺值得期待的。