职业思考 on 止语Lab

AI能读完所有文档，但读不到你的坑

Mon, 13 Apr 2026 00:57:38 +0800

上周技术评审会上，有人问了个问题：订单服务调库存和支付，分布式事务用什么方案？

AI秒回三种方案。Saga，实现简单性能好，但补偿逻辑复杂。TCC，隔离性好一致性高，但每个服务要写三个接口。本地消息表，对业务侵入小，但有延迟。每种方案附了代码示例和架构图。

问题来了，选哪个？

AI不知道。不是分析不了，是做不了这个判断。选哪个不取决于方案本身的优缺点，取决于你的团队维护过补偿逻辑吗？你的支付服务并发高了会死锁吗？

这些信息不在任何架构文档里。只在"上次踩过坑"的人脑子里。

**“知道选项"和"做对选择"之间，隔着一整个生产事故。**这不是能力问题，是认知结构的问题。

一、知道选项，做不了选择

回到那个评审会。

AI给了三个方案，信息完整，对比清晰。但团队里的老陈听完直接否了两个：

“Saga？上次我们写补偿逻辑花了三个月，还踩了两个P0。补偿接口的幂等性和时序问题比主流程还复杂，我们团队撑不住。”

“TCC？你看过支付服务的代码吗？Try接口会锁库存，并发一高就死锁。上次用TCC，灰度第二天就回滚了。”

“本地消息表。我知道不优雅，但基础设施支持重试，团队也熟。出问题我能快速定位。”

老陈做的不是"信息分析”，是"判断"。他不是在比较方案的优缺点，而是在回答一个更本质的问题：这个团队，在这个阶段，用这套基础设施，能撑住哪个方案？

AI能列出所有选项。但"选哪个"需要的不是信息，是判断力。判断力来自上次补偿逻辑写了三个月，来自上次TCC灰度回滚，来自消息表模式跑了一年的稳稳当当。

这些经历，文档里没有。只有经历过的人才知道。

二、看不见的坑才最致命

知道选项选不了，那把经验写下来、喂给AI不就行了？

问题是，**最危险的知识是"负向知识"——不能做什么、哪里不能碰、哪些坑是已接受的坏味道。**而负向知识几乎不会被主动记录。

一个SaaS平台做认证服务的灰度发布，从v1升级到v2。AI给了标准流程：配置Istio流量权重，监控错误率，逐步放量。流程完全正确，配置示例也没问题。

灰度那天，5%的流量打到v2，所有通过内部CRM处理的请求全部403。

原因：下游有个5年前的老系统CRM，对接时对HTTP Header的大小写敏感。v1返回x-user-role（全小写），v2用了新的HTTP库，默认规范化成X-User-Role（首字母大写）。CRM收到大写Header，解析失败。

这个大小写敏感的问题，从未被文档记录。当初发现的人直接修了，没写Wiki。v2用了新库会改Header格式，也没人意识到——除非你记得"上次CRM因为Header报过403"。

踩过坑的人会怎么做？灰度前加一行中间件，做Header大小写转换。就这一行。但AI不会建议这行代码——它不知道CRM对大小写敏感。就算AI接入了所有内部文档和事故记录，它读到的也是"发生了什么"，不是"当时为什么那么决策"——更不是"为什么以后应该这么做"。知识库解决的是信息传递，不是认知结构。

负向知识是"不能那么做"，不是"应该怎么做"。AI倾向输出"最佳实践"方案，因为训练数据偏好标准答案。但生产环境需要的不是"标准答案"，是"在这个满是历史技术债的系统里，哪个方案最不容易出事"。

三、有些东西就是说不出来

就算写下来了，有些东西你还是说不出来。

你debug的时候，为什么看一眼日志就知道"又是那个问题"？你说得清吗？大概率说不清。你可以说"内存泄漏"，但为什么你跳过了前四步排查直接看GC日志？因为上次P0事故就是这么处理的。

你能感觉到答案，但说不出来——不是表达能力的问题，是这种判断本来就不在语言能覆盖的范围内。你自己踩过的坑，你知道那个味道，但你要跟没踩过的人描述这个味道，说不出来。

骑自行车也一样——你知道怎么保持平衡，但你说不出来。踩坑经验的结构类似：“知道"和"知道为什么"之间有不可传递的差距。

你做过三次分布式事务选型，你知道"我们团队用Saga会出事”。你可以写进文档：“不建议使用Saga，因为2024年Q3补偿逻辑写了三个月且踩了两个P0。“但三个月后，新来的同事看到这条，能判断"当前情况是否和2024年Q3一样"吗？

不能。因为他不知道当时为什么补偿逻辑写了三个月——业务复杂？团队不熟？需求变了？**文档记录了"发生了什么”，但没有记录"当时为什么这么决策”。**有人会说ADR（架构决策记录）不是记了"为什么"吗？确实。但ADR记的是决策当时的推理，不是决策之后"这个选择实际上导致了什么后果"——而后者才是判断力的真正来源。

这就是"知道规则"和"知道何时用哪个规则"的差距。规则可以文档化，“何时适用"需要判断力。判断力不能被文档传递，只能通过亲身经历获得。

你可以把所有踩坑经验写进Wiki、喂进知识库。但读Wiki的人和踩过坑的人，面对同一个决策时的反应完全不同。阅读"别人踩过的坑"和"自己踩过的坑"产生的是不同层次的判断力——前者是"知道”，后者是"知道为什么此时此地应该这么做"。不是信息差距，是认知结构差距。

四、代码会贬值，判断力不会

判断力不仅不可替代，还不可贬值。

AI让写代码的边际成本趋近于零。以前一个CRUD接口你写45分钟，现在AI写15分钟。以前搭个项目骨架要一天，现在半小时。

“我代码写得快"不再是护城河了。这层优势正在被抹平。

但有一层优势抹不平：“我知道这个方案在第三年会出问题。”

代码是会贬值的，今天写的，三年后可能被新技术替代、被重写、被遗忘。但你在某个方案上踩过的坑、做的取舍、承担的后果，不会贬值。它们长在你的判断力里，变成你面对下一个决策时的直觉。

代码商品化了，但判断力没有。判断力没法批量生产，它不是信息的汇总，而是踩坑→决策→承担后果→修正直觉的闭环。AI可以读取这个闭环的结果，但无法经历这个闭环的过程。它依赖的上下文是你的团队、你的系统、你的历史，这些上下文不能被复制，只能被经历。

你的护城河不在你写了什么代码，而在你踩过什么坑。而这个坑，AI替你踩不了。

五、出事了，AI和你的第一反应不一样

判断力在决策时管用，在故障排查时更明显。

凌晨两点，订单服务OOM告警，容器开始重启。

AI给你五步排查流程：看内存曲线，查流量变化，导出内存分析（pprof），分析占内存最多的对象，排查协程泄漏。流程完全正确，按部就班30到45分钟定位。

但经历过上次P0的工程师，第一反应不一样：

“又是OOM？先看GC频率——GC在拼命回收但内存还是涨，是泄漏不是流量。”

打开监控面板，GC频率从正常变成了每秒好几次。

“回收不动。泄漏。”

直接看内存分析里占内存最多的对象：

“上次是orderCache没过期淘汰，这次……不是，是kafkaConsumer的offset提交卡住了，消息堆积，又没有背压保护，内存暴涨。”

从告警到根因，5分钟。

不是AI给的流程不对，是有经验的人能跳过大部分步骤，因为上次踩过。他知道先看GC频率，知道大概率是泄漏不是流量，知道先排除最可能的原因。

当然，不是每次都这么顺利——但上次踩过的坑，这次确实能跳过大部分步骤。这种"快速排除"的能力，来自亲身经历。读一百篇OOM排查指南，不如凌晨两点被叫醒处理一次。

六、经验不可省略，但可以加速

说了这么多"不可替代”，那新手怎么办？如果经验不可替代，新一代程序员怎么成长？AI把初级岗位压缩了，中高级从哪来？

答案不是"经验不可获得"，而是"经验不可跳过"。

你可以读完所有游泳教材，了解自由泳的每一个动作要领。但你不亲自下水，就是不会游。教练可以让你学得更快——纠正姿势、教你换气节奏——但不能替你游。

AI就是那个教练。它可以加速你获取经验的过程：帮你跑更多实验、更快定位问题、避免已知陷阱。但有个关键区别——教练自己会游，AI不会。教练基于亲身经验教你纠正姿势，AI基于训练数据猜测你可能需要的指导。教练的"教"来自"做过"，AI的"教"来自"见过"。所以AI没法替你踩坑，也没法替你为决策扛后果。

“得自己疼过才知道”，不是悲观，是认知结构的限制。你可以在疼的过程中少走弯路，但不能跳过"疼"这个环节。

如果经验的结构性不可替代，那经验传递的正确方式不是"写文档"，而是"创造经历"——所以如果你是团队里的老手，别只写文档，带新人做一次生产事故复盘，比写十页Wiki有用。如果你是新人，别只读文档，主动参与灰度发布、故障排查，让"别人的经验"变成"你的经历"。

经验不可省略。但可以加速。

AI能读完所有文档。但文档里不会写"上次我们踩过这个坑"。

你的判断力不靠背架构模式，也不靠读技术博客。它在你踩过的坑里、做过的取舍里、为某个决策扛过的后果里。

这些东西，AI读不到。你的同事也读不到。只有你自己经历过才知道。

这不是AI目前不行的局限，是认知结构的限制。不管AI多强，有些知识只能通过亲身经历获得。就像你可以读完所有游泳教材，但不下水就是不会，“知道"和"会"之间，隔着一整个水。

如果AI已经会了，我们为什么还要学？

Thu, 09 Apr 2026 00:00:00 +0800

这个问题本身藏着一个假设：学习的目的是"掌握知识"。

如果这个假设成立，那确实，AI 已经把你能背的都背完了，而且背得比你准，调取比你快，24 小时不睡觉。照这个逻辑，学习好像真的没什么意义。

但这个假设本身就是错的。学习的目的是建立判断力。

我举一个很具体的例子。

你用 ChatGPT 写了一段 Python 代码，它返回了一个看起来完整的方案。怎么确定这段代码没有安全漏洞？怎么确定在你的具体场景下，它不是那种"能跑但有坑"的写法？

你得懂 Python。不是为了自己写，是为了能看出它写得对不对。

AI 给了你答案，但评估答案质量这件事，得你自己来。评估靠什么？靠背景知识。没有背景知识，你面对 AI 的输出就只能信或者不信——两种都危险。

再说一个不同领域的例子。

一个律师用 AI 生成了一份合同模板。AI 写得格式规范、用词专业，比大多数实习生写得好看。但这份合同适用的是中国法还是美国法？你的甲方是国企还是外企？对赌条款在什么情形下会被法院认定无效？

AI 不知道这些，因为它的回答是训练数据的统计最优解，不是你这个案子的最优解。它不知道对方的商业模式、行业惯例里的潜规则、当地司法实践里的雷区。

跟那些说"AI 都会了还学啥"的人聊聊，你会发现，他们大多数是想偷懒。

当然，学习方式确实要变。

以前"学会"一样东西，意味着你能凭记忆把它复现出来——背公式、记语法、默写步骤。AI 让这类记忆型学习的直接价值降了很多，这是事实。

但理解一件事的能力，AI 没法替你长。

什么叫理解？你知道一个技术方案在什么条件下成立、什么条件下会崩。遇到新情况，你能把已有知识迁移过去。AI 给你五个选项的时候，你知道为什么选第三个——不是因为第三个描述最长看着专业。

记忆的价值在降，理解的价值在涨。理解是你使用 AI 的底层操作系统。

所以在 AI 时代，优先学那些帮你建立判断力的东西：基本原理、底层逻辑、领域的边界条件。这些 AI 不会帮你建立，因为它不知道你面对的具体场景是什么。

学的方法也要调整——碰到一个知识点，别只问"这是什么"，多问"它在什么情况下不成立"。靠这种理解积累下来的东西，才是真正的护城河。

最后说一个可能反直觉的事：AI 越强，学习反而越值钱。

当所有人都在用同一个 AI 工具的时候，拉开差距的就是谁能更准确地提问、更快地发现输出里的问题。这些能力不来自 AI，来自你在用 AI 之前就积累下来的东西。

以上是我的思考，欢迎聊聊你的看法。

Go代码越容易被AI写，Go工程师越值钱

Wed, 25 Mar 2026 00:00:00 +0800

Go代码越容易被AI写，Go工程师越值钱。

这句话听起来矛盾，但它是这个系列的终极结论。

前提是——你的价值不在"写代码"。

这是「AI工程时代三部曲」的收官篇。第一篇我们聊了Agent框架设计为什么比模型选型更重要，第二篇聊了技术债的真正根源是看不见的盲区。今天收尾，把视角从工具和系统拉到人身上：在这场AI冲击中，谁赢谁输？

一、旧护城河正在消失

先说一个很多Go工程师不愿意面对的事实：“选Go因为AI工具对它支持不够好"这个理由，已经不成立了。

2025年的LLM对Go的理解能力已经接近Python。并发模式、接口设计、错误处理——主流模型都能写出相当准确的Go代码。Tony Bai做过一个13种语言的AI代码生成横测，Go在20次测试中0次失败——所有静态语言中最好的成绩。他的结论是，Go的代码同质化特性（强制gofmt、单一for循环、显式错误处理）反而让AI生成的准确率更高。

换句话说，Go代码不仅不难被AI写，反而是最容易被AI写好的语言之一。

这意味着什么？

语言特性不再是护城河。过去你可以说"我会写Go并发，这个Python工程师不会”。现在AI都会。goroutine、channel、sync.WaitGroup——这些语法层面的知识，AI几秒就能生成。

那Go工程师的稀缺性到底来自哪里？

语言选择的"AI友好度"差异正在归零。你的价值必须建立在语言特性之上，而非之中。

二、2%的真相

SWE-Bench Pro（一个评估AI编程能力的基准测试）的数据给了一个精确的边界线：涉及多文件的跨模块修改，AI的成功率骤降到个位数。

这不是模型能力问题。我们在第一篇已经拆解过，同一个底层模型，换一个更好的上下文管理架构就能提升6个百分点。但即使是架构最优的工具，碰到真正的系统级修改，依然力不从心。

我自己用CodeBuddy写Go的体感也验证了这一点。写一个新的HTTP handler，AI又快又准：路由注册、请求解析、参数校验、错误返回——标准模式，几分钟搞定。但给一个现有微服务加一个跨三个package的功能就完全不同了。新的接口定义、已有repository的扩展、service层的协调逻辑——AI生成的代码开始出现明显的不一致：这边定义了一个方法签名，那边调用的参数对不上；改了一个struct的字段，依赖它的三个文件浑然不觉。最后我花在修正AI生成代码上的时间，比自己写还多。

单文件标准模式：AI胜任。跨文件系统设计：人的领地。

这个边界线在当前的LLM架构下很难突破。上下文窗口再大，也无法替代对系统整体设计的理解——AI看得见每一棵树，但看不见森林的形状。

AI在"写代码"上已经很强，但在"设计系统"上远不胜任。这个差距不是量变，是质变。

三、分化已经开始

上面两个事实叠在一起，推导出一个结论：工程师的分化已经启动。

不是"可能会分化"，是"正在分化"。GopherCon 2025的圆桌讨论上，Google的Samir Ajmani和Anthropic的多位嘉宾达成了一个共识：初级开发者的门槛正在提高，而系统工程师的价值前所未有地被凸显。

我把这种分化归结为三个层级：

第一层：提示词工程师。 会用CodeBuddy/Claude Code写代码，但不理解生成的代码为什么这么设计。他们能快速产出单文件功能，但碰到生产环境的并发bug、性能瓶颈、数据一致性问题就卡住。随着AI工具越来越好，“会用AI写代码"本身的门槛在快速降低——产品经理、设计师开始用Coding Agent直接出原型，不再等工程排期。

第二层：AI集成者。 能把AI接入现有系统，搭得出Demo。但碰到生产级问题——幻觉控制、延迟优化、成本管理——就陷入反复试错。他们知道怎么把零件拼起来，但不清楚为什么这样拼，更不知道拼错了怎么排查。

第三层：系统架构师。 理解整个系统的设计权衡，能判断"应该这么做"而不只是"能这么做”。他们让AI处理标准模式的代码生产，自己专注于跨模块的架构决策、性能优化的方案选择、系统可观测性的设计。

Go工程师有一个独特的加速条件：因为Go代码最容易被AI高质量生成，Go工程师可以最快地把"写代码"这件事交给AI，腾出时间和注意力投入系统设计。并发安全不只是"会写goroutine"，而是理解竞态条件在分布式场景下的传播路径。性能优化不只是"会用pprof"，而是判断哪个瓶颈值得解决、哪个可以容忍。这些判断AI做不到——而Go生态多年来恰好在培养这类能力。

分化的本质不是"会不会用AI"，而是"脱离代码生产后，你还有什么"。

问自己一个问题：如果明天AI能写出你日常工作中90%的代码，你还剩什么？答案就是你真正的价值。

四、赢家行动指南

赢家不是学了最多新工具的人，而是深化了最难被替代能力的人。

第一，设计清晰的系统架构。 不是画漂亮的架构图，而是在约束条件下做权衡。“这个服务拆还是不拆？拆了一致性怎么保证？不拆性能瓶颈在哪？"——这些判断没有标准答案，AI给不了你。

第二，维护完整的测试套件。 有清晰测试的项目是AI最能高效工作的环境。测试是AI的"观察信号”——没有测试，AI等于在猜。你写好测试，AI帮你写实现，这才是正确的人机协作模式。

第三，建立系统的可观测性。 这是第二篇的核心主题——看不见的盲区是最贵的技术债。你对系统的可见性越高，你做出正确决策的能力越强，AI越无法替代你。

回顾整个系列：第一篇说，Agent框架设计比模型选型更重要——竞争力不在选对工具，在设计好架构。第二篇说，技术债的根源是可观测性缺失——系统设计的质量在架构阶段就决定了。本篇的结论：有系统思维的工程师赢，没有的输。

一条线串起来：

AI工程时代的竞争力 = 系统设计能力 × AI放大系数。

系统设计能力决定上限，AI工具决定你多快到达上限。系统设计能力为零，AI放大一万倍还是零。

别再比较CodeBuddy和Claude Code哪个好用了。把那些时间花在理解你负责的系统的全局架构上。

这才是你真正的护城河。

后端开发转 AI Agent 工程师：一份接地气的自学路线

Mon, 23 Mar 2026 00:00:00 +0000

背景交代一下：我在生产环境跑过多个 Agent 系统，从单 Agent 到 Multi-Agent 编排都踩过，也参与过几个团队的技术面试。这个问题看到很多人在问，但多数回答停留在"学 LangChain 系列"层面，所以想说说我的判断。

一、市面上路线的问题在哪里

B 站和各平台的"AI Agent 入门"课，核心逻辑基本是：

安装 LangChain → 接 OpenAI API → 跑一个带工具的 ReAct 示例 → 做个 RAG demo → 完

它们只教你怎么跑起来，没有教你为什么会跑不起来。

真实的 Agent 系统会遇到什么？

模型输出格式偶尔不符合预期，整个工具调用链断掉
多步任务走到第 4 步突然 context 超长，不知道该截断哪里
RAG 把不相关文档检索出来，答案看上去靠谱实际上是错的
生产环境的某条链路偶发失败，你连日志都不知道该看哪里

学完 LangGraph 还是不会处理这些。课程教的是 happy path，面试和生产要的是你怎么 handle unhappy path。

这不是框架问题，是工程判断力的问题。框架学完，判断力还是零。

二、你 6 年后端经验的真正价值

你比那些"先学 AI 的人"有一个核心优势——你知道系统会坏。

一个没有后端经验的人学 Agent，会把工具调用当成魔法，觉得它不出错是默认状态。一个 6 年后端会问：这里的重试逻辑是什么？失败了怎么降级？状态怎么持久化？这次调用幂等吗？

这些直觉在 Agent 工程里比学会某个框架更值钱。

你需要做的，不是从零开始学，而是把工程直觉迁移到 AI 这个新的不确定性来源上。

三、一条能过社招面试的自学路线

分三层，从下往上建：

第一层：补 AI 工程的特有概念（2-4 周）

只是补认知盲区，不是从头学。需要掌握的核心概念：

LLM 的不确定性来源（temperature、token budget、上下文窗口边界）
RAG 的基本原理和它的失效模式（向量召回率问题、分块策略影响）
Agent 的三个设计模式：ReAct、Tool Use、Plan-and-Execute
Prompt 工程的本质：结构化约束，而不是"好好说话"

不需要课程，读官方文档和几篇高质量的博客文章足够。重点是能说清楚每个概念在什么情况下会出问题。

第二层：用工程视角做一个真实项目（4-8 周）

不是"做一个 RAG 聊天机器人"那种，而是要带着以下问题去做：

这个 Agent 能做什么，做不到什么？边界在哪里？
它什么时候会出错？出错之后系统怎么恢复？
我怎么知道它的回答质量是否下降了？

具体项目方向：一个有明确失败处理机制的 Multi-Agent 工作流，至少包含任务分配、状态持久化、错误重试、结果评估四个模块。框架用什么不重要，重要的是你能讲清楚每个设计决策背后的取舍。

第三层：建立评估体系（2-3 周，很多人跳过这里）

面试中最容易把人筛掉的不是不会写代码，而是回答不了这个问题：“你怎么衡量你的 Agent 系统的质量？”

你需要能回答：

RAG 系统的 Recall、Precision 怎么测
Agent 完成率（Task Completion Rate）怎么定义和追踪
用什么手段做 LLM 输出的质量监控（最低也得懂 LLM-as-Judge）

这一层考的就是工程判断力：你不只是会用工具，你知道怎么判断工具好不好用。面试官追问这一层，“会用框架"的候选人就答不上来。

四、关于 P6 还是 P7 的问题

面 P6 是正确选择，但别告诉面试官你只有 P6 的期望。

P7 的核心门槛不是技术深度，是架构决策能力——有没有在真实业务压力下拍板过技术方案、并对结果负责。这个靠自学绕不过去。

P6 的 AI Agent 岗位本来竞争就不激烈，因为多数候选人是"会用框架、不懂系统"的类型。面试官追问失败处理、评估体系、线上可观测性，大多数人答不上来。

你 6 年的工程经验，加上把上面三层真正做扎实，P6 是能拿到 strong hire 的评级的。

五、关于不背刺老板的事

你能提这个问题，职业成熟度是没问题的。

自学路线走完大概 3-4 个月，期间在公司内找 AI Agent 相关的项目练手是最高效的路径——不需要跳槽，真实业务场景的踩坑比什么自学项目都值钱。面试时这段经历也比个人 side project 更有说服力。

以上是我对这个问题的判断。具体到某个技术点有疑问，欢迎评论区讨论。

在AI能秒答一切的时代，人的核心竞争力到底是什么？

Thu, 12 Mar 2026 00:00:00 +0000

先说结论：提问的能力和判断的价值，是AI时代人最核心的竞争力。

AI能回答，但只有人知道该问什么问题。AI能生成100个答案，但只有人能判断哪个答案真正有价值。

这个问题可以从三个层面展开。

一、提问的能力：从"找答案"到"问对问题"

以前，知识的瓶颈是"获取"。谁能找到答案，谁就有优势。搜索引擎时代，这个瓶颈开始松动；到了AI时代，它几乎消失了。

现在你问GPT任何一个有标准答案的问题，它都能秒回。但它不会自己提问。

什么是好的提问？

是在海量信息中识别"值得探究的点"——这是一种对世界的敏感度。好的问题不是凭空冒出来的，它来自你对领域的理解、对矛盾的洞察、对空白的好奇。

举个例子。同样面对一份财报，AI可以帮你做财务分析、风险预警、趋势预测。但"这家公司的商业模式是否可持续"这个问题本身，需要你对行业有判断；“这个增长是真实的还是粉饰的"这个怀疑，需要你有经验积累。

AI不会问你这些问题。它等你问。

所以竞争的第一层：谁能问出更好的问题，谁就掌握了方向盘。

二、判断的价值：从"信息处理"到"价值裁决”

AI给出答案的速度越来越快，质量越来越高。但答案好不好、对不对、适不适合当下场景，这个判断仍然需要人来做。

这不是因为AI不够聪明，而是因为"好"本身是一个主观标准，涉及价值观、语境、目标。

什么是好的判断？

是在多个选项中做出选择，并对选择负责。这需要两样东西：

标准感——知道什么是好的、什么是够用的、什么是不能接受的。这来自经验积累和审美训练，AI可以辅助，但无法替代。

语境理解——同一个答案，在不同场合有完全不同的意义。AI可能懂字面意思，但不一定理解你的处境、你团队的约束、你当下的优先级。

还有一点：责任承担。AI可以给出建议，但不会为结果负责。决策者永远是人。

举个例子。AI可以帮你写10个版本的文案，但它不会告诉你哪个版本最适合你的品牌调性、当前的市场情绪、你的长期战略。这需要你来判断。

所以竞争的第二层：谁能在AI的输出基础上做出更好的判断，谁就拥有了最终决定权。

三、从"操作者"到"把关人"的角色转变

把上面两层合起来，你会发现一个趋势：

人的价值正在从"执行"向"决策"迁移。

以前，你会写代码、会写文案、会做PPT，这些是硬技能，是竞争力。现在，AI可以帮你写代码、写文案、做PPT。但这些输出的质量和方向，取决于你怎么提问、怎么判断、怎么迭代。

不是技能没用了，而是技能的门槛降低了。真正的壁垒变成了：

你能否把模糊的想法变成清晰的问题
你能否从AI的输出中识别问题、提出改进方向
你能否在多个可行方案中做出取舍
你能否对最终结果负责

用AI的人取代了不会用AI的人。但会用AI的人之间，竞争的是提问和判断。

小结

AI时代，人的核心竞争力不是和AI比拼"回答问题"的能力，而是：

提问的能力——识别值得探究的问题，定义问题的边界和方向
判断的价值——在AI给出的选项中做出选择，并对结果负责

这不是说其他能力不重要。沟通、创造、执行，这些依然有价值。但在AI能秒答一切的背景下，提问和判断成为了"人"最独特、最难以被替代的能力。

回答这个问题，其实也是在回答另一个问题：你想成为AI的操作者，还是它的驾驭者？

停止「氛围编程」：AI 时代的工程师分水岭

Fri, 06 Mar 2026 00:00:00 +0000

你以为自己在用 AI 编程。

实际上，AI 在用你。

这不是修辞。当你把 AI 当作代码生成器——输入需求、接收代码、提交上线——你正在把自己训练成 AI 工作流中最没价值的环节：一个人肉回车键。

2025 年 2 月，Andrej Karpathy 在 X 上发了一条帖子，给这种编程方式起了个名字：Vibe Coding（氛围编程）——“完全沉浸在感觉中，依靠 LLM 生成代码，而不需要真正理解输出”。这个词后来被柯林斯词典选为 2025 年度词汇。

一年后的今天，行业的对话已经翻篇了。问题不再是"要不要用 AI 编程"，而是"你在 AI 工作流中扮演什么角色"。

这篇文章要说的，就是这条分水岭两边的区别。

一、你用 AI 写代码很快，但你不踏实

GitHub 的一项研究给出了一个具体数字：使用 Copilot 的开发者完成任务的速度比未使用的快 55%。实验场景是用 JavaScript 写一个 HTTP 服务器——使用 Copilot 的组平均用时 1 小时 11 分钟，对照组 2 小时 41 分钟。

55% 的提速。听起来像是一个值得庆祝的数字。

这也只是故事的一半。

另一半是你在日常工作中已经感受到的：AI 产出的代码越来越多，但你对项目代码库的掌控感在下降。你不确定那段 AI 生成的逻辑是否覆盖了所有边界情况。你不确定那个自动补全的错误处理是否真的合理。你不确定三个月后回来看这段代码，还能不能读懂。

一天产出过去一周的代码量，这在 AI 辅助开发中很常见。代价是这些代码的可维护性、安全性、性能可能都成问题。

代码审查的压力也随之而来。AI 生成的代码需要更仔细的审查，因为你不是写它的人，你不知道它的隐含假设是什么。产出量上去了，审查量也跟着上去。

这种"速度提升但掌控感下降"的体验，不是你的错觉。

它有一个准确的诊断：你在做 Vibe Coding。

划重点：速度提升是真实的（55% 有研究支撑），但掌控感下降也是真实的。如果你只感受到了前者而忽略了后者，你可能正在用一种注定不可持续的方式和 AI 协作。

二、Vibe Coding 和 Agentic SE：不是工具的区别，是方法论的质变

先把两个概念说清楚。

Vibe Coding（氛围编程）——用直觉和提示词驱动的 AI 编程方式。你说一句话，AI 生成一段代码。你觉得差不多，提交。没有系统性的测试、没有架构审查、没有明确的质量门禁。核心特征是"快，但不可控"。

Agentic Software Engineering（智能体软件工程）——人定义目标、约束和质量标准，AI Agent 在结构化监督下自主完成从设计到提交的完整流程。核心特征是"人管方向，AI 管执行"。

两者的区别不在于你用了什么工具。用 Cursor 可以做 Vibe Coding，也可以做 Agentic SE。用 Claude Code 同样如此。

区别在方法论。

想象你管理一个实习生。Vibe Coding 相当于你口头说一句"帮我写个用户注册功能"，然后实习生闷头写了两天交给你，你看了一眼就合并了。Agentic SE 相当于你给实习生一份完整的需求文档、架构规范、测试标准和验收清单，实习生按照流程逐步完成，每个环节都有质量检查点。

同一个实习生，两种管理方式，产出的质量天差地别。

Agentic SE 的典型工作流分 6 步：

理解需求——AI 分析上下文，明确要做什么、不做什么
设计方案——AI 生成实现方案，人确认后再动手
代码实现——AI 按方案编写代码
自动测试——AI 编写并运行测试用例
质量审计——AI 检查代码规范、安全漏洞、性能问题
提交 PR——AI 生成变更说明，人做最终审查

每一步都有人的监督接入点。这和 Vibe Coding 的"一步到位"模式有本质区别。

你只需要知道：Vibe Coding 和 Agentic SE 的核心差异是"人在 AI 工作流中的位置"。前者中人是被动接收者（“AI 写了什么我就用什么”），后者中人是主动设计者（“我定义 AI 怎么工作”）。

三、2026 年的三个分水岭信号

“从 Vibe Coding 到 Agentic Engineering"这个判断不是我的发明，它正在被学术界、企业界和行业观察者同时验证。

信号一：学术界已经点名。

智谱 AI 和清华大学联合发布了 GLM-5（744B 参数），这篇论文的标题直接用了 “From Vibe Coding to Agentic Engineering”。当一个顶级研究团队把这个叙事写进论文标题，说明它已经从社交媒体上的流行语变成了学术界认可的范式描述。

信号二：企业级已经落地。

JPMorgan 在 AI Agent 领域的标杆技术会议 LangChain Interrupt 上展示了 “Ask David”——一个多智能体 AI 系统，用于处理复杂的投资研究分析。不是原型，不是 demo，是在生产环境中服务金融专业人士的系统。多个专业 Agent 各司其职，人类专家在关键节点做决策。

这就是 Agentic SE 在企业级的样子。

信号三：行业共识正在成型。

MIT Technology Review 在一篇深度分析中指出，2025 年软件工程领域最大的转变是从"追求速度和规模"到"管理上下文”。原文的表述是：“The fact the conversation has moved from questions of speed and scale to context puts software engineers right at the heart of things.”

一句话说：当 AI 的瓶颈从算力变成了上下文理解，工程师的价值不是降低了，而是被重新定义了。

信号	来源	核心信息
学术界点名	GLM-5 论文（智谱 AI / 清华）	论文标题直接使用 “From Vibe Coding to Agentic Engineering”
企业级落地	JPMorgan “Ask David”	多 Agent 系统在金融生产环境中运行
行业共识成型	MIT Technology Review	软件工程核心转变：从追求速度到管理上下文

三个信号指向同一个结论。

2026 年，工程师的分水岭不是"会不会用 AI"，而是"你在 AI 工作流中扮演什么角色"。

一句话总结：这不是一家之言。学术论文、企业实践、行业媒体从不同角度验证了同一个判断——Vibe Coding 到 Agentic Engineering 的转变正在发生。

四、Agentic Engineer 的三个核心能力

认清分水岭之后，下一个问题是：从 Vibe Coding 这一侧走到 Agentic SE 那一侧，你需要什么。

答案可以压缩成三个维度的能力转型。

从"写提示词"到"设计上下文"：上下文工程

MIT Technology Review 把这个能力叫 Context Engineering（上下文工程）。

最直观的例子：在项目根目录维护一个 CLAUDE.md 文件（如果你用 Claude Code 的话），把项目的技术栈、编码规范、禁止事项、测试要求写清楚。每次 AI 开始工作时自动读取这个文件，相当于给 AI 配了一份"项目记忆"。

这和"写一个好的提示词"是不同级别的事情。提示词解决的是"这次对话让 AI 做什么"，上下文工程解决的是"AI 在这个项目中的所有行为都遵循什么规则"。

一个是单次对话的输入，一个是持久化的工作环境设计。

前者是 Vibe Coding 的天花板。后者才是 Agentic SE 的起点。

从"手动调试"到"设计质量门禁"：测试设计

有完善测试的代码库，AI 做了改动后可以立刻验证是否破坏了现有行为。没有测试的代码库，AI 的每一次改动都是一次赌博。

这个逻辑在传统开发中就成立。在 AI 辅助开发中，它被放大了十倍——因为 AI 产出的代码量远超人类手写，如果没有自动化测试作为安全网，技术债的累积速度会让你绝望。

Agentic Engineer 的测试策略不只是"写单元测试"。它包括为 AI 的输出设计验收标准，定义什么样的代码可以自动合并、什么样的必须人工审查。

这是在给 AI 设计质量门禁。

从"一问一答"到"多 Agent 协作"：Agent 编排

Simon Willison 在他的 Agentic Engineering Patterns 系列中提出了一个核心原则：Agent 系统的最大敌人不是 LLM 的能力不够，而是不可调试性——如果你不知道 Agent 为什么做了某个决定，你就无法改进它，也无法信任它。

MCP（Model Context Protocol）正在成为 Agent 工具连接的事实标准。一个被广泛引用的类比是：MCP 对 Agent 工程的意义，类似于 REST 对 Web API 的意义——不是唯一方案，但正在成为行业默认选择。

对于大多数后端工程师来说，Agent 编排不需要你从零构建框架。它需要你理解 Agent 的协作模式，能把复杂任务分解成多个 Agent 各自负责的子任务，能设计 Agent 之间的通信和监督机制。

这些技能，和你在微服务架构中做服务编排的经验是相通的。

三个转型方向：（1）上下文工程：从写提示词到设计 AI 的工作环境；（2）测试设计：从手动调试到设计 AI 的质量门禁；（3）Agent 编排：从一问一答到多 Agent 协作流水线。这不是要你学全新的东西，而是把已有的工程思维应用到 AI 协作场景中。

五、从今天开始的三件事

如果你读到这里，认同这条分水岭确实存在，下一步不是等，是动手。

三件具体的事，每件都可以在 5 分钟内起步——起步，不是完成。从 Vibe Coding 到 Agentic SE 是一个持续的过程，这三件事只是你迈出的第一步。

第一件：给你最重要的项目加一个上下文文件。

如果你用 Claude Code，创建一个 CLAUDE.md。如果你用 Cursor，创建一个 .cursorrules。写上四样东西：技术栈说明、编码规范、禁止事项、测试要求。

不需要写很长。“这个项目用 Go 1.22，数据库是 PostgreSQL，所有 API 都要有对应的单元测试，禁止使用全局变量”——30 个字，已经比没有上下文文件的项目领先了一步。

第二件：为 AI 产出的代码补一个测试。

从最危险的模块开始——支付、权限、数据处理。不需要追求 100% 覆盖率，先给最关键的路径加上安全网。

有了测试之后，AI 的每一次改动都可以被自动验证。这是从 Vibe Coding 到 Agentic SE 最小的一步，也是最关键的一步。

第三件：改变你和 AI 对话的方式。

把"帮我写一个用户注册功能"改成"按照以下规范实现用户注册功能：接口定义见 API 文档，错误处理使用项目预定义的错误类型，需要包含输入校验和单元测试"。

前者是 Vibe Coding。后者是 Agentic SE 的起手式。

区别不在字数，在意图的精确度。

分水岭的意义不在于你站在哪一侧，而在于你是否意识到这条线的存在。

2026 年，最大的风险不是"不会用 AI"，而是"以为自己在用 AI，实际上被 AI 用"。

从今天开始，做 AI 的架构师，不是 AI 的回车键。

本文是"AI 时代工程师进化"系列的第一篇。下一篇将深入实操：Agentic Engineering Patterns——从单 Agent 到多 Agent 的可复用设计模式。

从今天开始：（1）加上下文文件（5 分钟起步）；（2）补关键路径测试；（3）升级你和 AI 对话的精确度。不需要一步到位，但需要从现在开始。

参考资料

Andrej Karpathy 关于 Vibe Coding 的原帖 — Vibe Coding 概念的起源（2025.2）
GitHub Copilot 效率研究 — 55% 速度提升的原始研究数据
GLM-5 论文 (arXiv:2602.15763) — 智谱 AI / 清华大学，标题呼应"From Vibe Coding to Agentic Engineering"
MIT Technology Review: From vibe coding to context engineering — Context Engineering 概念的行业分析
Simon Willison: Agentic Engineering Patterns — 可复用的 Agent 工程模式与实践
The Bootstrapped Founder: How to Actually Use Claude Code — Claude Code 工程化使用的最佳实践