没有玩笑。
手写代码的时代，确实正在过去，而且不是那种「未来可能会发生」的趋势，而是已经在发生、只是分布不均的现实，大概体会到了当前马车被汽车取代的感觉。
写这篇文章算是给自己一个仪式感吧，告别一段曾经让人着迷的工作方式，同时尝试理解未来到底会变成什么样。
昨天
如果大家过去是程序员，除了「完成任务」后获得的成就感，在整个写代码的过程中也能体会到很多乐趣。
拆解整个需求，思考状态的流转，设计模块之间的关系，甚至在脑子里提前模拟整个执行路径。
很多时候，它更像是在解一道复杂的数学题，而不是在完成一个产品需求。尤其是在 debug 的时候，那种不断逼近问题核心的过程，会让人产生一种很强的快乐感——你在和一个复杂系统对抗，并且打败了它。
写代码不仅仅是「技术能力」，更是一种认知上的满足感：问题是复杂的，但你可以通过自己的思考，把它变得清晰、可控、甚至优雅。
所以在很长一段时间里，「写代码」这件事不只是工作，它本身就是一种意义的来源。
但从去年年初写的一篇 AI 杂想 开始，事情开始了变化。
今天
从 Cursor使用经验，一个需求开发全流程 介绍了 Cursor 带来的编程的质的变化，到 一行代码没写用 ai 开发了一个链接转二维码的网站，公众号引用链接更方便、Cursor 写一个网页标题重命名的浏览器插件、Cursor 开发复杂项目过程记录和利弊分析 一个个小项目，再到 Cursor 排查 eslint 问题全过程记录 问题的排查。
过去不断去和 AI 合作，探索 AI 的能力边界，但是可怕的地方在于模型进步的太快了，以前可能效果不好，但现在写的质量完全超过了人写。
一个个具体的瞬间叠加在一起，让自己逐渐意识到：手写代码，正在退出历史舞台。
-
AI 把一个内部跨端框架写的页面直接转成了 H5 页面，人全程没有读原仓库的任何代码，只负责验收，最终生成的 H5 页面样式、交互都还原的非常好
-
公司内部有人用 AI 写了一个 20 万字的「大人工智能时代下前端界面全新开发模式的思考」，可读性非常高，完全不像 AI 写的。
但是因为是写在公司内部文档里的，不方便慢慢读，然后把地址贴给龙虾，让龙虾直接生成一个 epub 的电子书格式，龙虾竟然做到了。
-
用自然语言写 sill 的时候，当发现不符合预期，在 skill 里加一句话然后重新执行，AI 真的听懂了一样，这个时刻真的让人感觉到了「大人，时代变了」。
那一刻会意识到，我们不再是在写程序，而是在「指挥系统」。
从前端开发的角度来看，过去大概就是 PC 端的表单页和 C 端页面两大类。
对于 PC 端页面，所有的交互都比较固定，无非是增删改查，对于样式要求也不严格，直接用组件就可以，这种 AI 已经完全可以胜任了，所以部分页面后端已经完成了自闭环。
那 C 端呢？
起初觉得 AI 还原视觉能力还不够，但从 MCP 开始，AI 直接读取设计稿事情就发生了变化。把 ui 稿链接给 AI，页面的字号、颜色、布局直接和 UI 稿对齐。唯一的缺点是有些视觉稿层级会乱画，导致 AI 也识别不好，但这只是规范问题而不是 AI 的问题。
UI 画好之后，逻辑层对于 AI 来说就是小菜一碟了。我们只需要告诉 AI 这个功能是什么：
读取设计稿 xxx.com/file/xxx的具体…
红包上方新增「额外必得3 元」标签，样式使用上边得到的样式，位置和原来的「抽奖必得」保持一致。由于额外红包的宽度可能超过父容器，需要给父容器加一点宽度保证标签不被裁剪。
如果同一个红包既有「抽奖必得」，又有「额外必得」，仅展示「额外必得」。
是否展示逻辑：laddertasklistv4.bin 接口中新增 extraRewardList 字段，如果该字段存在，并且元素数量大于 0，就在该红包上边新增改标签，文案使用后端下发的 badgeText。
滑动逻辑：找到 ladderList 中最后一个包含「额外必得」的红包，横滑至漏出这个红包的位置
「额外必得」标签新增动画逻辑。
动画逻辑分为三段，一个结束后执行另一个。
「额外必得」标签执行一个从小放大的过程，参考其他页面的 shakeAnimate 逻辑。
红包执行左右摇动，旋转角度：0° —— -2° —— 2°—— -2°——0°，晃动总时长 532ms，参考其他页面的 shakeAnimate 逻辑。
标签上方盖一个透明视频 https://xxxxx 执行扫光，透明视频使用 PicassoVAPView。
过去可能手写几个小时的工作量， AI 几十秒就能实现，我们只需要验收符不符合预期。
在传统开发模式中，「代码」就是表达意图的方式本身。但在 AI 协作模式中，这一层发生了根本变化：**代码不再是意图，而只是结果。**我们需要通过自然语言 、结构化的需求描述、清晰的约束条件定义来向 AI 传达你的意图，AI 再将这些意图转化为代码。
因此代码写好的好不好，很大程度在于我们描述的清不清楚，过去的一些边界情况可能是边开发边想到的，但现在我们需要学会用结构化的方式表达需求——功能范围、性能约束、技术限制、用户场景，而且最好是提前一次性想清楚，但可能很难，因此很多时候真正的瓶颈反而变成了人。
事情甚至逐渐发展的更加极端，去年我们生成代码后可能会逐行 review。但现在需求开始倒排期，原先三周的需求留给开发的时间可能只有两周，过去没有 AI 可能会据理力争，不可能，根本完成不了。
但现在有了 AI 让这变成了可能，从逐行 review AI 的代码，变成了验收结果对不对，因为代码太多了，根本没时间去逐行理解。唯一的兜底可能就是让 AI review 一下代码。
但随着一个需求接着一个需求上线，线上页面包含自己完全没看过逻辑的代码也慢慢被接受，这在过去是完全不敢想象的。代码正在从「需要理解的对象」，变成「只要结果正确即可接受的黑盒」。
代码在一个需求中的时间消耗占比逐渐降低，更多的时间花在与产品经理讨论需求的合理性，质疑设计稿中不符合用户心理模型的交互，权衡技术方案对长期维护性的影响，在多个「都行」的方案中做出取舍，处理团队沟通中的信息不对称等。
曾经优秀的程序员一个重要能力就是迁移能力，比如要解决一个问题，通过网上搜寻发现很多类似的但和已有场景有一点差别，此时只需要理解网上的方案后结合自己的代码完成即可。
而现在 AI 太擅长了，只要告诉 AI 哪里有类似的东西，AI 可以非常完美的迁移过来。甚至公司里用的是一个闭源的跨端框架，我们只需要把这些仓库放到一起，通过 Cursor 的 Codebase indexing，AI 便能很好学会新框架的语法、交互怎么用。
明天
一句话，全链路用 AI 重造。
目前模型的能力已经足够强，即使不用最强的 Claude Opus 4.6，用 Cursor 自己的 Composer 2，也能出色的完成各类任务。
因此当下缺少的是在 AI 基础上的工程化和各种研发工作流的建设。
基础侧通过 AI 改造所有的链路，代码仓库、打包工具、前端框架、基于意图的 ui 框架、流水线等等，所有流程都应该考虑在 AI 时代应该变成什么样。
业务侧利用已有基建，根据业务特性沉淀 skill，常见的错误、代码的规范等等，擅用 cc/cursor/codex 等编程工具，沉淀专属的 Command、SubAgent 等。
但所有的一切都和手写代码再也无关，我们提供思路，review 代码，甚至思路也可能是和 AI 脑暴出来的。开发这件事，将越来越和「手写代码」无关。
好消息是曾经的「35 岁退休」被消解了。过去，年轻意味着更快的执行速度，而经验意味着更好的架构能力（选择合适的技术栈、设计合理的模块划分、规划可扩展的数据流、制定清晰的组件抽象策略）。但现在，AI 已经可以很好地解决「怎么做」的问题，真正稀缺的反而是「做什么」和「为什么做」。在这个维度上，经验的重要性被放大了，而单纯的熟练度优势则在减弱。
过去我们强调的是编码能力、框架熟练度、工程经验，但在新的模式下，更重要的反而是表达能力、抽象能力和判断能力。需要能够清晰地描述问题，引导 AI，评估 AI 给出的结果是否合理，甚至在多个「看起来都可以」的方案中做出选择。
当遇到线上故障、复杂边界、性能瓶颈，那种 AI 多次尝试都解决不了的问题，过去积累的经验训练出来的人类工程师的直觉显得尤为重要。
结尾
一场革命就这样推动着，
杀死那个写代码的人，
迎接一个已经到来的未来，
不是因为他不够努力，而是因为这个时代，已经不再需要他了。
AI 飞速进步，当 AI 基建也全部落地，当企业的运转不再需要那么多人之后，我们都需要重新寻找意义，也许就又回到了 存在主义哲学--人生的意义。
