1 月份听完了“尖不想写扣”的播客 S1E19《半年了 ! Vibe Coding 現在怎麼了 ?》，当时我感触很深，直到让子弹飞了一会之后，现在我这些年对 AI 从开始到如今的所有感受涌现了！我必须记录下来。
初识 GPT#
我不能说我从很早就了解过 AI 方面的知识，因为我当时连机器学习这种学科我都不了解，但至少我也是见证了从 GPT 3.5 发布，引爆国内技术圈的大范围讨论，再到 AI 套壳，再到国内开始爆发式的自研各种模型，再到 VibeCoding 概念的提出，再到 MCP 提出，再到 agent 提出，等等。
我觉得我是幸运的，体验了 GPT 3.5 热议到如今 AI 爆发的这整个过程，它到来让我改变了很多东西的看法，从算法到架构，从开源到职场，再从职场到人类社会，我只能用震撼二字来形容。
我非常记得在 2023 那年大概是 3 月份，当时我还在备考研究生，也刚搬完家，在新的出租屋里那个楼梯底下的工作桌上看到了 GPT 3.5 发布的消息，也是这个时候 OpenAI 在国内技术圈突然爆了，铺天盖地的 GPT 3.5 怎么厉害，怎么套壳，怎么卖课，当然我也夜不能寐，我总感觉它的出现意味着某些东西即将改变，而且甚至是一种工业革命的变革。
于是我萌发了“必须钻进去看个究竟”的想法，把备考的事情先放了一边，我拉着 铂赛东 也做了一款套壳 GPT，叫 GPT4U。（现在看来研究生没考上也是合理了，没管住自己的探索欲）
铂赛东当时我非常记得有一个开源项目叫做 ChatGPT-Next，如今已经改名为 NextChat，我们靠着它的开源项目二次开发做了自己的套壳 GPT。
NextChat当时我和 铂赛东 发现了一个 GPT 的致命问题，就是它训练的知识只停留在 2021 年的，所以如果你问“最新款的 Macbook 笔记本是多少钱”的时候，它只会给你胡说八道。我们抓住了这次的突破点，我记得当时的 New Bing 已经在“AI + 联网检索”的方面已经比较出色了，因此我们也想把这种能力复刻在自己产品上，花了两周左右的时间，从 OpenAI 怎么充值再到对接 OpenAI 接口，再到 Prompt 设计和调优，最终从技术上解决了我们让 GPT 3.5 如何联网的问题，使得 GPT4U 在私域内广受欢迎，其实当时我们也没太敢往公众视野里面推，毕竟当时我们以为这玩意儿是灰色地带的存在，研究技术是最主要的，赚米只是附属品。
现在我不妨可以放出当时我们解决 GPT 3.5 联网问题的思路，我觉得现在回看也挺有意思的，当时说了一大堆我自己的思路，突然意识到“设计 Prompt”也是一种工程问题，逐渐理解为什么当时在 Youtube 上很多人都在提到 Prompt Engineering，真的很重要，如今现在的 agent，每个厂商 Copliot、Claude Code、CodeX 等等这些都离不开 Prompt 的调优，每个 agent 都会展现出自己的风格，这真的就跟团队怎么设计 Prompt 有很大的关系。
总之，这套联网模式的方案我自己非常满意，更重要的是，产品上线之后获得了远超预期的积极反馈，也正是在这里，想由衷感谢 铂赛东 —— 在 AI 时代刚刚起势之初，可以一起并肩探索、反复推演，许多关键判断与突破都源自那段并行研究的过程。
但这不公平#
慢慢地，在我的视野里，大模型的能力变得越来越强。
第一次听到 Vibe Coding 这个概念时，我其实是困惑的。直译过来是 “氛围编程”：通过自然语言描述需求，让大模型生成代码；遇到问题，再用自然语言反馈给模型，由它继续修正。这套流程在传统编程语境下显得有些反直觉，又新鲜得令人无法忽视。
也正是在这个概念流行之后，Cursor 这样的工具开始出现，并迅速风靡。 我们团队的 Yansoul 几乎第一时间化身为 Cursor 推行官，自掏腰包开了会员，开始了他的 Vibe Coding 之旅。
Yansoul与此同时，小红书上也迅速涌现出一批 “独立开发者”。他们像被点燃了一样，高频输出内容，表达的内容几乎一致 —— “我用 AI，在 N 天内做出了一个 XXXX。”
我并不怀疑这些产品的真实性，也不否认 AI 在其中的巨大生产力价值。 真正让我感到不适的，并不是他们因此获得了流量，而是其中一部分人开始顺势输出一种更危险的结论：编程思维已经不重要了。
AI 时代的这股 “风”，吹得我脑壳疼，隐约感觉到了一丝凉意。
纵观这些所谓的 “独立开发者” 不难发现，部分人并不具备完整的工程思维、抽象能力或系统设计经验，他们能把产品 “做出来”，更多是因为大模型已经在后台承担了大量隐性复杂度 —— 包括架构建议、代码补全、错误修复，甚至决策引导。
但与此同时，如果说内心完全没有波澜，那也是不真实的。 我必须承认，我对这一切有一种很具体、也很私人的感受：我觉得这不公平。
我从五年级开始写代码，对代码本身有着强烈的兴趣，也投入了大量时间甚至走了很多弯路。那些年里，我逐渐建立起对抽象、结构、复杂度和边界的理解，现在就犹如一台大型精密仪器，巧妙地在我大脑内工作。这些能力并不显眼，却只能通过长期实践慢慢形成。
而在 AI 时代到来之后，我不得不接受一个事实： 在 “结果” 这一层面上，我和许多刚刚入场、但善于使用大模型的人，被放在了同一条评价线上。
我理解这种变化的必然性，也清楚这是技术进步带来的结果。让我真正感到不适的，并不是被追平本身，而是这些由长期投入换来的各种差异，在 AI 时代中被迅速抹平，甚至被反过来质疑其价值。
我不反对 Vibe Coding。 我也不否认 AI 正在降低创造的门槛，甚至解放一部分人。
但如果因此得出 “编程思维不再重要” 的结论，甚至反过来贬低那些仍然尊重工程、尊重抽象、尊重复杂度的人，那我无法认同。
AI 时代，人还重要吗？#
“AI 时代，人还重要吗？”，这是我思考了很长时间的问题，甚至我和团队小伙伴不止一次关于这个话题深夜 deeptalk 到凌晨三四点（我们平时也是这个点睡的）。
一开始，我确实焦虑。
随着大模型能力不断增强，我经常会把它类比成一个正在成长的实习生： 模型本身代表能力的上限，而 agent 的出现，则让这个 “实习生” 开始具备执行力，能够利用自身能力，替人完成越来越多具体的工作。
在此之前，除了前面提到的 “不公平感”，我作为从五年级就开始写代码的码农来说，更直接的感受其实是危险。
甚至在某些时刻，我会羡慕团队里的产品和老板这些身份的角色，因为我隐约意识到：他们身上最核心的能力，恰恰是 AI 难以替代的。对用户群体的感知、对大量产品的使用经验、对需求微妙变化的判断、对“什么该做、什么不该做”的直觉 —— 这些东西并不完全存在于文档或代码里，而是长期经验在一个人身上的沉淀。
反过来看程序员，情况貌似会残酷一些。 程序员的知识是高度可结构化、可沉淀、可被吸收的 —— 就像《哆啦 A 梦》里的记忆面包，只要知识能够被写进书本、写进代码、写进语料，AI 就可以“吃下去”，然后变得更强。
在那一刻，我很自然地得出了一个结论：程序员，似乎是更容易被替换的那一类人。
但后来我跟团队成员反复沟通，尝试分析他们想表达的内容背后的共性时，我的看法发生了改变。我真的很幸运，能和这样一群优秀的人共事，因为他们总能从我没有意识到的角度，重新拆解问题。
真正改变我看法的是一个很简单、却被我忽略的事实：我不应该纠结 “程序员会不会被替换”，因为被替换的，从来都只是某一类程序员。被替换的，永远是只做 CRUD、只执行需求、不理解系统整体的劳动力。
我觉得 “软件” 不是简单的代码集合，而是一个需要持续治理的系统。 架构的权衡、边界的划分、复杂度的控制、长期演进的判断 —— 至少在目前，agent 还无法独立完成一个真正自洽、可演进、可维护的系统设计。
从这个角度看，AI 时代淘汰的并不是 “程序员” 这个职业，而是那些不愿意拥抱 AI、不持续学习、不理解工程本质的人。
所以到现在为止，我反而越来越确信一件事：AI 时代确实来了，但人也变得更重要了。
人类是伟大的#
再回到人类社会本身，让我震惊的是《Attention Is All You Need》这篇论文呢是在 2017 年的时候提出的，这一年我刚上大一，但世界已经开始悄无声息的发生了一些变化。
虽然我没有一字不落的读完这篇论文，这从各方面的科普和自行查阅资料，我越来越确信：Transformer 的提出，意味着人类在信息处理范式上迈出了关键一步。
为什么我称之“迈出了关键一步”？如果你了解 Transformer，它实质上是注意力机制的算法，在海量的 token 中，通过注意力机制，选出最符合预期的文字并排列出来，这本身就跟人类的大脑很类似，换句话说，Transformer 在 token 间不断做注意力分配，就跟人的大脑在感知、语言、推理的时候不断做相关性筛选一样，人类真正抽象出了一个在工程上与人类高阶认知相似的计算范式。当我意识到人类做到了这一点的时候，我浑身鸡皮疙瘩，先是感到可怕，后是感到伟大，我认为人类文明又向前迈进了一步。
我曾经问过自己一个问题，AI 的出现，是高阶文明必定经过的里程碑吗？我认为是的。
让我们暂时抛开机械飞升、意识保存这种颇有科幻成分且较为遥远的事情，一种在星球上的高阶文明，我认为星际探索是一个文明从萌生到灭亡过程中必定要修炼的课题之一，而碳基生命的局限在于寿命的长短取决于基因序列，就像上帝制造某种生物时，给它们安装了有定时的自毁程序，并且碳基生命是脆弱且珍贵的，那么碳基生命想让某种东西代替自己肉身出去太空星际探索的话，就必然需要找到其他的“生命”（这听起来碳基生命是多么的自私，但这很有效不是吗），在地球上，这个生命最有可能的就是硅基生命。
而若想让硅基生命像人类大脑一样运转起来，那么 Transformer 这套注意力机制就是迈向类人大脑的第一步。
20 世纪 40 年代人类为了解决自身算力有限，发明了世界上第一台通用电子计算机，而在 21 世纪的今天，Transformer 这套注意力机制算法被应用在计算机中，解决了人类自身注意力有限的问题。如今 100 万字的论文，能够被 1 分钟内被概括出来，30 天的工程项目，可能允许被压缩成 3 天就可以被开发出来，这种生产力的变化是以前人类想都不敢想的，我为之感到人类是伟大的。
且慢！有些失控了#
就在我逐渐接受 “人与 agent 共生” 这件事之后，一次非常现实的团队协作场景，把我从宏观思考拉回到了现实。
事情的起点其实很积极 —— 团队里越来越多人开始尝试用 agent 写代码，包括一些并非研发背景的成员。从效率视角看，这无疑是一种生产力释放：需求可以更快被转化为可运行的代码，想法的落地成本被大幅压缩。
但这种积极感在两周后立马转变成了一种我对其的危机感，像过山车一样，原因是非研发成员开始尝试利用 agent 向生产代码提交 PR，我们开始明显感觉到系统层面的 “摩擦”。
最直接的问题不是代码能不能跑，而是代码是否应该属于这个系统。
agent 非常擅长解决 “当前任务”：修一个 bug、补一个功能、拼一个接口，这些都可以在局部上下文里完成。
🤣👉 点击观看非常荒诞但又很贴切当前 agent 能力的讲解视频 🎬
但软件系统从来不是局部问题的堆叠，它是需要长期演进的。模块边界、依赖方向、状态管理策略、命名语义一致性等等，这些隐性的约束并不会自动体现在 prompt 里，却决定了系统未来是否还能被理解、被修改、被扩展。
当缺乏工程背景的人直接把 agent 生成的代码提交进主仓库时，我们看到的是一种典型现象：
- 功能是对的，但抽象层级错位
- 能工作，但破坏了既有约定
- 修了眼前问题，却引入长期维护成本
这不是 agent 的失败，而是我们当前 agent 能力下的使用方式越过了系统治理的边界。
我后来意识到一个关键点也跟我之前提到 “AI 依然离不开人的驾驭” 的观点不谋而合：agent 本质上是一个高能力执行体，而不是系统设计者。它没有“全局记忆”，也不会天然对未来复杂度负责。它做的是局部最优，而工程需要的是全局一致。
这就像把一辆性能极强的车交给一个不理解交通系统的人 —— 车本身没有问题，但如果缺乏规则，很快整个道路都会混乱。
于是我们团队也开始尝试把问题从 “agent 能不能用”，转向 “agent 应该如何被约束”。
为 agent 设置“交通规则”，就好比团队成员使用 agent 就等于开了一辆车，这个车开得多快取决于 agent 本身的能力，而在团队的协作中，多个 agent 为同一个仓库代码贡献，就好比多辆车在一个城市道路上行走，有 A 到 B，有 C 到 D 的车辆，但 A-B、C-D 又是有交集的十字路口，因此需要一套交通规则来让城市的车辆行走的更加高效，这就是我们需要解决的问题。
但新的问题又出现了，我们在设计交通规则时，考虑的都是十字路口的交通规则，但在工程项目里，能够遇到的问题是复杂的、多样的、甚至不可重复的。这就意味着我们设计交通规则时会遇到 T 字路口、Y 字路口、星形路口等等，我们如果只用一套十字路口的交通规则来规定 agent，那么遇到其他路口的时候又会出现问题，这个举例拉回来就是说：我们在抽象出来了一套 agent 的 Skills 实际上它也只能解决单一或有限的解决某个小工程问题，但实际上一个项目是又多个不一样的小工程巧妙的串联起来的，这种串联的方式就叫做设计模式。
因此，面对 agent 有上限的 Context 限制，选用什么 Skills 来具体解决哪些工程问题显得尤为重要，但最后的最后你会发现，依然需要懂工程细节的人来决定使用什么 Skills 来让 agent 高效的工作起来。
这是我对这件事情认为是失控的本质原因。
何为工匠？#
当我们不断讨论 agent 的边界、规则与治理时，一个更底层的问题开始浮现在我脑海里：
人在创作体系中到底希望保留多少主动权。
而这，恰恰让我想到一个古老却仍然鲜活的词：
工匠。
让我们回到 antfu 的这期播客，我反而更加理解 Anthony Fu 所说的「agent 对我没有价值」这句话。这里的“没有价值”，并不是否认 agent 在宏观上的效率提升，也不是否认它对许多开发者、团队、业务场景的现实意义，而是在他个人的创作体系里，agent 并没有进入他的价值。
Anthony Fu我最终给自己下的结论只有一个：
这并不是工具的问题，而是人格与创作方式的问题。
在我看来，Anthony Fu 是一个典型的“匠人型程序员”。他并不是在“完成任务”，而是在雕琢作品。他对代码的期待不是“能跑”“够用”“大致正确”，而是“这正是我想要的结构、节奏与边界”。而 agent 的问题恰恰在于：它输出的是一种统计意义上的“合理”，而不是创作者内心已经成型但尚未被写出的那个“确定形态”。
他说 agent 写出来的东西 “不是他想要的”，这意味着：他脑子里早就有一个清晰但高度个人化的答案，而 agent 无法对齐的，并不是技术细节，而是这种内在的审美与判断。
当然，会有人说：“那只是他不会用 agent。”、“只要 prompt 写得好，agent 也能写出他想要的东西。”
但我并不认同这种反驳。因为这恰恰忽略了一点：当一个人已经足够清楚自己要什么时，让他花大量精力去 “教会” 一个 agent 如何接近他的想法，本身就是一种额外的摩擦成本。这并不比他亲手写代码更高效，甚至更让人感到失真。
这让我想到机械时代之后依然存在的工匠 —— 在流水线、机床、模板高度成熟的年代，仍然有人选择用锤子、尺子和双手，一点一点地敲打、校准、打磨。他们并不是不知道机器更快，而是他们要的不是 “差不多的成品”，而是 “这是我做出来的东西”。
在 AI 时代，我反而觉得这种仍然坚持亲手雕琢程序、不愿接受 AI 给出的 “八九不离十” 的开发者，是一种难得的存在。
你当然可以说，这在社会效率层面是落后的； 你也可以说，这样的人不适合规模化生产、不适合商业复制； 但我依然会选择敬佩。
因为他们守住的，其实不是旧工具，而是一种对创作主体性的坚持： 不是 “我如何更快地产出代码”， 而是 “这段代码，是否仍然是我”。
也许 agent 终究会变得足够好，好到连匠人也愿意让渡一部分控制权； 但在那一天到来之前，我反而庆幸这个时代， 还有人愿意慢下来，对 “差不多” 说不。