2026 已经过半。这半年里，模型在不断的发展，在某种程度上我没有在「写代码了」。
前言
在写这篇博文之前，我在去年发过一篇 AI Coding 一年来的感悟，聊了聊从 Copilot 到 Claude Code 的转变。当时的 Claude Code，是很强，但还不能整个 workflow 都给它来做。
但博文发出去一两个月后，GPT-5.2-Codex, Cluade Opus 4.6 陆续发布了。
我大量的使用这些模型，随着使用的越多，我发现自己真正去写代码的时间越来越少了。给大家介绍一下我这几个月的变化。
当我们不再写代码时，我们在干什么？
这半年来模型的进步速度太快了。Agent 目前已经能干完几小时的工作流，甚至能同时派好几个 Agent 跑。我们自己敲键盘的速度，根本跟不上它们生成代码的速度。
既然模型写业务代码比你快好几倍，也没啥理由再自己哼哧哼哧手写了。重心自然就从「写代码」转到了「构建产品」上。
首先是实现业务，既然我们不需要自己写代码了，那实现可以全部丢给 Agent 来做。现在的模型已经非常聪明，你只需要丢给它你的需求加上你的代码库，就可以生成一段具体的实现 Prompt。我们只需要审阅实现 Prompt，感觉哪里不对，去问一下模型修正，完成之后就可以新开会话去实现了。
对于大一点的任务，比如说加一批功能或者重构，可以让它派 Sub Agent 并行干。好处是上下文窗口相当于变大了好几倍，开的 Sub Agent 越多，能干的事就越多。坏处当然就是 Token 费用了… 看看你的余额够不够。
接下来是 Review，Review 也同样重要，但你可能 Review 不过模型了。模型生成代码很快，Review 同样也很快。因此我们也得把 Review 交给模型，你只负责关键路径和代码结果的 Review。你不可能指望一个几千行的 pr 一点点去看，看完花几个小时的时间，模型已经可以又产出几个这样的 PR 了。
需要 Review 的是代码风格，架构方向对不对。可以让模型产出 Review 文档，你只需要读这些 Review 文档就行了。多 Review 几次直到模型挑不出大的毛病来就行。
最后是测试。测试比 Review 重要得多。对于业务代码好坏其实没那么关键，架构方向对了就行。但测试不行——无论是单元测试还是 GUI 测试，都得认真跑一遍，找出所有的问题。很遗憾前端这块模型还远不如人，还是得一个个测。
测出问题后，简单的小问题自己读代码顺手就改了，不用再走一遍模型。棘手的问题再回去反馈给模型，让它重新修，循环几遍直到修好。
这种转变其实是在逼着我们换个思路干活。以前写业务，调个接口，各种查库，整天纠结类定义和各种胶水代码，跟流水线上的手工业者没区别。出 bug 了或者太慢了，甩锅呗：前端骂后端接口慢，后端骂产品需求变，产品骂架构设计垃圾。大家没事找事，觉得天天写这种枯燥代码太没劲了。
行，现在 AI 直接把这些增删改查全给封装成了黑盒，我们不用去敲那几行具体的逻辑了。但还不能闲着，现在游戏规则变了，你得去当那个把所有 Agent 捏合在一起的「总导演」。你的核心壁垒，从敲键盘的速度，直接变成了你怎么画出这个系统的拓扑蓝图、怎么调度这些 AI 去给你干活。
文档，文档，还是文档！
回顾一下在之前的开发中，我们的需求是怎么来的：开会讨论、写 PRD、画原型图，这些流程的存在是因为我们互相需要沟通，确认好各类需求。在 Vibe Coding 时代，这些东西都可以转换为文档。几个人互相 Vibe Coding 协作，文档就是他们的需求来源。一个文档可以写入 api 接口，计划书，原型 ascii 界面等……
而且，文档也不需要你写。你只需要提供一些想法，现在的模型足够强，可以快速给你生成一篇文档。你只需要看一下是否符合要求就行了，有问题丢给模型回去改就行了。
有文档之后，就有很多好处。可以按照文档快速实现需求，不用每次从头跟模型去解释项目背景。丢一句「按文档把 X 功能做了」，它自己该做什么就做什么。换人接手也一样，文档 + 代码库往那一放，新来的人或者另一个小团队就可以往下继续做。
说到这个，你甚至可以一个项目分给好几个人同时做。每个人负责自己的模块，各自描述各自的文档，最后合到一起。文档也是一种分工边界：你负责 A 模块的文档，我负责 B 模块的文档，互不干扰，最后让模型去合并代码。
维护是项目的试金石
光写一堆文档还是不行的。写文档很多时候其实更偏向项目管理，只靠它根本搞不定真实业务。你还是得去理解客户的要求，然后把需求转化成具体的代码逻辑。
现在用 AI 起个新项目、写头几个功能太容易了，需求一丢，代码噼里啪啦自动生成，跑起来看着特别爽。但这只是个蜜月期，项目一旦进入维护阶段，真正的考验才开始。
这也暴露出 Vibe Coding 带来的最大隐患——虚假繁荣。AI 噼里啪啦自动把代码堆出来，界面跑通了，你就觉得大功告成万事大吉。但这本质上只是把问题强行塞进了一个更大的黑盒里。如果你自己对底层原理一窍不通，不知道为什么这里会产生并发冲突，不知道慢查询该怎么定位优化，一旦项目稍微进入深水区，AI 就会开始跟着你抓瞎。到最后，AI 给你堆出来的就是一坨金玉其外、败絮其中的技术债。自己没有硬核的底座把关能力，AI 生成得越快，屎山堆得就越猛。
说白了，LLM 拿到的上下文永远是不够全的。你不可能指望把几十万行的代码全部塞给它，让它自己去猜 Bug 到底在哪。当线上报错或者业务变更的时候，你必须得能看懂代码，在脑子里大概定位到问题出在哪个模块、哪几行代码。
只有你自己定位到了，把相关的支付回调文件或者路由中间件挑出来喂给模型，它才能帮你改对。如果你自己两眼一抹黑，遇到问题只知道把报错日志或者截图扔给 AI，AI 就会开始瞎猜、胡乱打补丁。今天这儿多一个 try-catch，明天那儿硬编码一个变量，用不了几次，整个项目就会变成一坨没人敢动的屎山。
所以，直接写几个功能确实可以，但后续维护你不会，那就是在拉屎。在 AI 时代，阅读代码和定位问题的能力，可能比写代码本身还要重要。
说的很好，那你的工作流呢？
我的工作流其实很简单：
- 根据需求，让模型阅读代码或者之前的功能文档，生成一个新功能的实现文档
- 检查是否没问题，没问题之后，丢给模型实现
- 实现的时候，我倾向于使用 sub agent，进行循环实现，包括实现，检查，修复这样的循环。如果实现代码需要前端等，我还会单独指定让模型使用某个前端 agent 去实现
- 完成了之后，模型测试后端，人工测试前端，没问题之后就大功告成了。
尾声
这半年多来，模型的能力提升确实很大，很多时候我也在焦虑是不是会被 AI 取代。
但现在我想清楚了。AI 确实很聪明，但它的上下文永远不够完整。遇到需求和问题时，第一个把这些东西串起来的依然是我们人类——去划分边界，寻找位置。除非 AI 哪天能做到把那些模糊、混乱、甚至互相矛盾的需求，完美转化为可落地的业务代码，否则就必须一直有一个「中间人」的角色去沟通和串联。程序员在这个场景下，依然有自己的优势所在。
因为在真实的开发里，最难的从来不是写出那几行逻辑，而是把客户嘴里那些语焉不详、甚至自我冲突的设想，梳理明白并转化为合理的业务结构。AI 能精准地执行指令，但它没法替客户和业务做抉择。客户说「想要一个简单的导出功能」，背后可能隐藏着权限管理、数据安全，以及高并发下的服务器开销。这些逻辑的冲突和利益的权衡，最终还是得靠人类去拍板。
写代码的门槛确实变低了，但解决真实世界复杂问题的门槛并没有降低。只要这世上还有「把人话翻译成逻辑代码」的需求，这个中间人的角色就不会消失。
不过 AI 确实也有好处，我们配一个项目，部署环境啥的，这类 AI 分分钟就给我们搞定了，你不再需要去焦头烂额的去找什么 API，什么密钥，它会自己去读文档，甚至是项目代码去为你部署，哈哈。
