AI 时代，代码会过期，知识不会
今天是我正式离职的日子。
其实这份工作在两周前就已经在我心里结束了。我提前休了两周假，等真正走到办公流程的最后一步，我发现自己没有预想中的那种失落，反而有一种很安静的轻松。我一开始还有点意外，因为一段结束的关系，通常总会留下点惋惜。后来我想明白了，轻松不是因为我讨厌这份工作，而是因为我终于结束了一段并不适合自己的旅程。适合和不适合，是很难在中途承认的事情，人总是倾向于再忍一忍。真正能承认它的时候，往往已经是要离开的时候。
所以我想趁着这个还没被新事情填满的空档，认真复盘一下这一年。如果只允许我说出一个最大的收获，那它一定不是完成了几个项目，也不是又多学会了几个框架。项目会交付，框架会过时，这些东西的保质期都很短。我这一年真正沉淀下来、并且离职之后还能带走的东西，是我给自己搭起来的一套 AI 工程工作流。这句话听上去有点平淡，但我越想越觉得，它可能是这一年里唯一一件值得认真写下来的事。
刚入职的时候，我对 AI 的用法其实很浅。我只是把 Cursor 当成一个更聪明的写代码工具，让它补全、让它改 bug、让它解释一段看不懂的老代码。它确实快，但那种快是零散的，用完就忘，第二天遇到类似的问题我还是从头再来一遍。
真正的转折是我开始建自己的文档中心。我给每一个需求都开一个独立的目录，里面有需求模板、设计模板、测试模板、Review 模板，把从提出问题到验收上线的整个开发流程都串起来。一开始我这么做，只是为了让自己想得更清楚。但做了一段时间之后我发现，我真正积累下来的东西，既不是某一句好用的 Prompt，也不是某一个模板的格式，而是一套关于“怎么和 AI 一起把一件复杂的事情做完”的方法论。
方法论和技巧的区别在于可迁移性。技巧是绑死在某个工具、某个版本上的，工具一换就失效。方法论是绑在问题结构上的，工具怎么换，问题的结构还在，它就还能用。我意识到这一点之后，很多东西一下子就串起来了。它让我第一次比较确定地看清了自己想去的方向：Harness Engineering，Agent Coding，人机协作的软件工程。如果没有这一年被迫把流程一遍遍写下来、改下来的经历，我大概还停留在“AI 是个好用的工具”这个层面，不会真的把它当成一个需要被设计的协作系统来看。收获有时候就是这样，它不来自你做成了什么，而来自你终于看清了自己在做什么。
这一年也有遗憾，而且我最大的遗憾不在技术上。
技术上的东西，说到底都是可以补的，慢一点快一点而已。真正让我难受的，是我和 Leader 的工作方式始终没能契合。他的管理风格非常强调结果和效率，节奏快，目标清晰，人文关怀这部分则比较少。这本来不是什么缺点，很多团队就是靠这种风格跑起来的。问题出在我身上：我是一个比较敏感、也比较需要被信任和被尊重的人，我在一个只谈结果、很少谈人的环境里，会持续地消耗，而且这种消耗是隐性的，等你察觉到的时候已经很深了。
我一开始下意识地想把它理解成谁对谁错，想给它一个是非判断，这样心里会好受一些。但后来我慢慢意识到，这根本不是对错问题，而是匹配问题。一个强调效率的 Leader 没有错，一个需要被尊重的下属也没有错，错的是把这两种人硬放在一起，然后指望其中一方长期委屈自己去迁就。承认这是匹配问题，比争一个对错要成熟得多，也让我不再带着怨气看这段经历。
正因为想通了这一点，我给下一份工作定了三条不能妥协的底线。第一，必须有足够自由的 AI 工具使用环境，因为我未来要做的事情，本身就建立在这套工具链之上，环境受限等于方向受限。第二，团队和 Leader 的管理风格要尊重人，要有基本的人文关怀，这不是矫情，而是我已经用一年时间验证过：在缺乏尊重的环境里，我做不出自己满意的东西。第三，工作节奏不能长期透支身心健康，因为透支是会累积的，它今天不还，明天就会连本带利地找回来。这三条不是我把要求提高了，恰恰相反，是这一年的经历让我第一次知道，对我来说什么才是真正重要、不能拿去交换的东西。
离职之后，我和朋友聊到一个更有意思的问题：AI 工程为什么还需要工作流？既然 AI 已经能写代码了，直接让它写不就行了吗？为什么还要那些模板、那些流程、那些看起来很“重”的文档？
聊下去我们才反应过来，这个问题问反了。真正的软件开发，从来就不只是写代码这一件事。需求评审、技术设计、测试设计、上线验证、事故复盘，这些环节在还没有 AI 的年代就已经存在了，而且它们的本质，是人和人之间的协作工作流。写代码只是这条流水线最末端、最显眼的一段，但它从来不是全部。一个团队真正的能力，藏在这些环节的衔接里，而不是藏在某一次代码提交里。
那么 AI 到底改变了什么？我的结论是，它没有创造工作流，它只是让工作流第一次拥有了一个能真正消费上下文的新成员。过去这些文档主要是写给人看的：写给下一个接手的同事，写给三个月后忘了细节的自己。现在它们第一次开始同时写给 AI 看。这是一个很微妙但很关键的变化。如果没有工作流，你喂给 AI 的就只是孤立的一句指令，它当然只能给你孤立的一段代码。有了工作流，你喂给它的是一整套背景、约束和意图，它才可能给你一个真正长在这个系统里的答案。所以工作流不但没有因为 AI 而变得多余，反而因为多了一个如饥似渴消费上下文的成员，变得比以前更重要了。
顺着这个思路往下想，我们碰到了一个更本质的问题：一个项目里，最重要的资产到底是什么？
直觉上我们会说是代码。但只要认真回忆一下真实的工作场景，就会发现不对。很多时候，一个项目最值钱的东西，是那些只存在于老员工脑子里的经验。为什么一个核心员工离职之后，整个项目会突然变得没人敢动？代码明明还在，一行都没少，为什么大家反而不敢碰了？因为随他一起离开的，是那些没写进代码的东西：这里为什么这么设计，当初踩过哪些坑，哪些方案已经被否决过，哪些地方看着能改其实千万不能动。这些才是维护一个系统真正依赖的知识，而它们恰恰是最容易丢的，因为它们从来没有被正式地记录下来。
我们平时说一个老项目“技术债越来越重”，习惯性地把锅甩给代码写得烂。但认真想想，很多时候代码本身并没有那么复杂，真正压垮维护者的，是上下文的丢失。技术债的利息，很大一部分是用“没人知道这里为什么这样”来支付的。代码可以慢慢读懂，但丢掉的判断和教训，是读不回来的。
那么这里有一个很现实的追问：如果这些知识真的只存在于人的记忆里，团队现在是怎么撑下来的？答案其实有点无奈，靠的是运气和人情。运气是那个关键的人还没走，人情是他走了以后你还能约他出来喝杯咖啡问两句。这是一种极其脆弱的维护方式，它随时会因为一次跳槽、一次沟通不畅而断掉。而 AI 的出现，把这个老问题进一步放大了。因为如果上下文没有被沉淀下来，AI 和那个新来的、没人带的同事一样，同样无法真正理解这个系统。你会发现，那个我们以为是“AI 时代才有”的新问题，其实是一个很老的问题，AI 只是把它照得更亮了：真正难维护的，从来不是代码，而是知识。
想到这里，我们又撞上了一个看起来自相矛盾的说法。
一种声音说，未来代码都是一次性的，AI 一分钟就能重新生成，谁还去维护它。另一种声音说，未来软件会越来越好维护，因为 AI 能帮你读懂、帮你改。这两句话听上去是对着干的，但我们越聊越觉得，它们其实都对，区别只在于你说的是哪一类系统，取决于这个系统的生命周期和它承载的价值。
对于生命周期很短的小工具、小脚本、小应用，第一种说法是对的。它们的逻辑简单，需求随时会变，与其去维护一坨旧代码，不如把需求重新描述一遍让 AI 重新生成。当生成成本已经低于维护成本的时候，代码确实变成了一次性的消耗品，用完就扔，一点都不可惜。
但对于银行、交易所、支付系统、微信这样的长期系统，第二种直觉才成立，而且要成立得更彻底一点：这类系统真正值钱的，从来就不是代码本身。是那些一点点沉淀下来的业务规则，是一次次事故换来的血泪经验，是被反复推敲过的安全策略，是整个组织在漫长时间里积累的知识和上下文。这些东西你没法让 AI 一分钟重新生成，因为它们不是被“写”出来的，是被“经历”出来的。所以对这类系统而言，代码可以重新生成，知识不能。一旦把这两类系统分开看，那个矛盾就自己消失了：未来真正需要被维护的对象，正在从代码转移到知识系统。
到这一步，一个更让我在意的结构浮出来了，它关于成本的不对称。
AI 极大地降低了表达知识的成本。写代码是一种表达知识，把脑子里的逻辑翻译成机器能执行的形式；写文档也是一种表达知识，把想法翻译成别人能读懂的形式。在这两件事上，AI 的提升是几个数量级的，快到几乎不像是同一个时代的事情。但是，它并没有同样数量级地提升获取知识的速度。观察真实的世界，理解用户到底想要什么，提出一个以前没人提过的假设，验证一条新的规律，这些事情 AI 可以帮忙，却不能直接替你完成。
我一开始觉得这只是“暂时还做不到”，后来越想越觉得，这里卡住的地方是结构性的。获取知识的瓶颈，往往不在处理信息，而在拿到信息。用户不会把自己真正的痛点打包成一段清晰的文字发给你，他们自己常常都说不清；世界也不会主动把因果关系标注好再呈现给你。你得去现场，去看真实的人在真实的约束下做真实的选择，去承受一次判断失误的代价，才能换回一点点可靠的认知。AI 没有身体，不在现场，不承担后果，它能处理你喂给它的一切，却很难自己走出去把新的东西拿回来。这就是它帮不上太多忙的地方。
这个不对称，会重新定义什么叫稀缺能力。过去的软件工程，本质上更像是在生产代码，谁写得又快又好谁就厉害。未来的软件工程，会越来越像是在生产知识：重要的不再是代码写得快不快，而是你能不能发现一个真正值得解决的问题，能不能提出一个好的假设，能不能设计一个好的实验，能不能把实验的结果沉淀成组织可以持续复用的知识。这么一路想下来，我有一个越来越清晰的感觉：未来的软件工程师，会越来越像研究员。写代码只是研究员用来验证想法的手段之一，真正的核心工作，发生在提出问题和积累认知的那一端。
最后，我们聊到了一个我印象最深的问题：如果 AI 什么都能做得比我们快，人类的优势到底还剩在哪里？
我想到一个例子，是关于写小说的。未来写小说这件事也许会变：人类负责设定世界观、塑造人物、把握情绪、制造冲突、决定故事往哪个方向走，而 AI 负责真正把那几十万字一个字一个字地写出来。写完之后，再由人类回过头去读，去判断它够不够感人，够不够让人欲罢不能，人物立不立得住，情绪是不是自然。你会发现，人类始终站在方向和判断的那一端，AI 站在执行和产量的那一端。
软件开发，我越来越觉得也会变成这个样子。人类负责方向，负责品味，负责价值判断，负责提出那个真正值得做的问题；AI 负责海量的执行。这个分工不是因为人类打字比 AI 慢才被迫如此，而是因为软件最终服务的对象不是 AI，而是人。要做出真正打动人的产品，你得先真正理解人，而理解人这件事，恰恰依赖一种 AI 很难真正拥有的能力。它不是计算能力，也不是推理能力，而是作为一个人对另一个人的理解：真正体验过恐惧，真正经历过遗憾，真正怀抱过期待，真正拥有过幸福。这些来自真实生命体验的感受，是无法靠阅读语料学来的，而它们也许永远是设计产品、创造产品最重要的源头。一个从没害怕过的东西，很难替一个害怕的人设计出真正安心的产品。
写到这里我才意识到，这篇东西其实是我离职之后的第一篇正经思考。它表面上在总结一份工作的结束，实际上在记录的是一件更大的事：我的职业身份正在发生转移，从一个“会写代码的工程师”，慢慢变成一个“设计人机协作系统的工程师”。前者的价值绑在自己的双手上，写得多快、写得多好；后者的价值绑在自己的判断上，选对了什么问题、搭对了什么流程、沉淀下什么知识。这一年最大的成长，不是我手更快了，而是我开始学着把手交出去，把注意力放到更上游的地方。
有意思的是这场思考本身的走向。我们一开始聊的其实是一个挺具体的问题：软件工程会不会越来越像做科研。但一路推下来，它把我带到了一个更深、也更简单的地方。回过头看，前面所有那些关于工作流、关于知识、关于研究员、关于小说的讨论，其实都在指向同一件事，只是从不同的角度在描述它。工作流让 AI 能消费上下文，是因为上下文本身就是知识；知识比代码更难维护，是因为知识才是真正的资产；长期系统里代码可弃而知识不可弃，也是同一个道理；而人类的最终优势，说到底是对人的理解，那同样是一种最难被表达、只能被亲身获取的知识。
所以这场思考真正的落点，不是“要不要好好写文档”，也不是“离职以后该找个什么样的团队”，而是下面这句话。它安静，但我知道它足够大，值得我在往后很长一段时间里反复推敲：AI 时代的软件工程，正在从生产代码转向生产知识；而人类最重要的竞争力，也正在从表达知识转向发现知识。