AI 时代，代码会过期，知识不会
今天是我正式离职的日子。按理说，一段旅程结束，人总该有点失落，可当我真正走到这一天，心里最清晰的情绪竟然是轻松。这轻松不是因为我讨厌工作，也不是因为解脱于某种苦役，而是因为一段并不适合自己的旅程，终于可以体面地画上句号了。我提前休息了两周，精神状态早就慢慢从工作里解绑出来，所以真到了这天，反而平静得有些不像话。
奇怪的是，当我回过头去盘点这一年到底得到了什么，我发现自己最想说的，既不是完成了哪几个项目，也不是学会了哪几个框架。那些东西当然存在，但它们并不构成我心里那个“最大收获”。真正让我觉得这一年没有白过的，是我不知不觉给自己搭起了一套 AI 工程工作流。这是一件听起来有点抽象的事，可越往后想，我越觉得它比任何一个具体成果都重要，因为它改变的不是我做了什么，而是我看待“做事”这件事本身的方式。这篇文章，就想从这套工作流出发，把这一年我和自己、和 AI、和这个正在剧变的软件工程行业之间的几场纠缠，慢慢讲清楚。
最大的收获，不在项目清单里
说来有点反直觉：一个人辛苦工作一整年，最值得记住的东西，居然不在他交付的任何一件成品里。可我确实是这么觉得的。
刚入职那会儿，我对 AI 的理解非常朴素，就是把 Cursor 当成一个更聪明的代码编辑器，让它帮我把想写的东西敲得快一点。那时候我以为，用好 AI 无非就是把 Prompt 写得更巧妙一些。可慢慢地，我开始给自己建文档中心：每一个需求都有独立的目录，目录里有需求模板、设计模板、测试模板、Review 模板，把从提出问题到最终上线的整个开发流程一环一环串起来。等我某天回头看这堆文档，才后知后觉地意识到，我真正沉淀下来的从来不是一条条 Prompt，而是一套方法论。
这就是那个看似矛盾的地方：我以为自己在积累“怎么让 AI 写代码”的技巧，实际上我积累的是“怎么组织一件复杂工作”的结构。技巧是会过期的，模型换一代，昨天的 Prompt 就可能失效；但方法论不会，因为它描述的是人如何思考、如何拆解、如何把混沌的意图变成可执行的步骤。也正因为看清了这一点，我才敢给自己认定一个方向：Harness Engineering、Agent Coding、人机协作的软件工程。我倾向于认为，一个人这一年是否真的成长，不看他手里多了几件作品，而看他有没有升级那套“生产作品的方式”。如果只是熟练地重复旧动作，产量再高，也只是原地打转而已。
不是谁对谁错，是没对上
这一年当然也有遗憾，而且我最大的遗憾恰恰不是技术上的。技术上的坑，踩过就是能力；真正让我难受的，是我和 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 时代的软件工程，正在从“生产代码”转向“生产知识”；而人类最重要的竞争力，也正在从“表达知识”转向“发现知识”。这句话我打算以后一直反复推敲下去，因为它几乎把今天所有的悖论都收进了同一个框里。工作流不是负担，是把知识变成资产的工序；管理风格的错配不是谁的错，是提醒你去发现自己真正需要什么；代码会不会一次性，取决于它底下那团知识值不值得留；表达越来越便宜，发现才越来越贵。
所以说到底，我并不觉得这是一篇失业者的伤感自白。它更像是一份交接文档，只不过交接的对象是未来的我自己。代码总会过期，会被下一代模型一分钟重写掉；可这一年里那些被我笨拙地想明白、写下来、沉淀成方法论的知识，不会。我越来越相信，一个人在这个时代真正该攒下的，不是那些迟早会被重新生成的东西，而是那些一旦丢了就再也长不回来的东西。就让我用这句稍显别扭却越想越踏实的话收尾吧：我们拼命写下的代码终有一天会被删掉，而我们真正学会的那点关于世界和人的知识，才是唯一带得走、也唯一值得带走的资产。