当代码不再是资产
- 作者：Bougie
- 创建于：2026-06-19
- 更新于：2026-06-19
上周五晚上,我花十五分钟用大语言模型做了一个小东西:把一段四十分钟的会议录音扔进去,让它给我整理成一份会议纪要。我没有写一行代码,没有打开 IDE,没有建任何项目文件夹,没有在 GitHub 上建仓库,甚至没有想好这件事做完之后要把文件放在哪里。模型直接输出了一段文字,我复制粘贴到了飞书文档里,第二天早上发给同事,他们说格式还挺清晰的。
这件事小到不值一提。但我坐在电脑前盯着那段文字看了一会儿,忽然觉得哪里不太对劲。
不对的地方在于:整个过程里,我没有任何一次觉得自己在「写软件」。可是从功能上说,那段文字确实是一个软件帮我生成的——一个专门为那次会议定制的、只存在了十五分钟的、永远不会被人维护也不会被人迭代的软件。它完成了任务,然后消失了。
我忽然意识到,我已经不记得上一次这么心安理得地用完一个东西然后不管它是什么时候了。
我做了十几年的软件开发,中间吃过很多苦头。「代码腐烂」这个词我是在某本书里看到的,但我对它的理解不是从书里来的,是从自己的骨头上来的。我见过那种代码库:注释写的是三年前的需求,变量命名是当时随手敲的,测试从来没写过,依赖库停在某个版本因为升级会触发一连串的隐性 bug,整个项目像一艘被藤壶包裹的船,没人敢动,因为一动就漏。漏了之后谁负责?没有人负责,因为当初写的人早就转岗了,留下来的人只能靠绕过问题而不是解决问题活着。
所以我很早就被灌输了那套信念:代码是要被维护的资产。写代码的时候要想清楚它在未来会变成什么样子,要给自己留退路,要测试,要写文档,要让下一个接手的人不用猜你的心思。这不是多高尚的职业精神,这是被现实反复教训之后的生存本能。你不这样做,过两年你回来看自己的代码,会发现自己写的还不如别人写的能看懂。
我在这套逻辑里生活了很久,理所当然地认为它描述的是软件开发的基本规律:代码是资产,资产需要维护,维护需要成本,成本需要被预算覆盖。所以好的软件工程实践是必要的,不这样做是要付出代价的。
然后 LLM 出现了,一开始我只是把它当成一个更聪明的代码补全工具,后来它开始能写完整的函数,再后来它能写完整的小项目。我试着让它帮我生成过一些内部工具,有些确实跑起来了,帮我省了一些重复劳动。我在心里把它归类为一个「更高效的编程手段」——还是那个框架里,还是在写代码,只是写得更快了。
但这次不一样。
这次我没有写代码。我甚至没有「委托」它写代码。我只是描述了一个需求,然后拿走了结果,中间的过程我没有参与,也没有任何兴趣参与。那个输出是一次性的,它的「源代码」我不关心,它以后怎么演进我不关心,它有没有 bug 我不关心——严格来说它有没有 bug 我甚至没有手段去验证,因为我拿到的时候它已经完成任务了,任务完成之后它对我而言就已经死了。
一个没有源代码的、不会被维护的、完成即消亡的软件。
我忽然意识到,我活了十几年的那个世界里有一条公理:代码是资产。而在这个十五分钟的会议纪要生成过程里,这条公理不成立。
这才是让我愣住的原因。不是因为我发现了一个新工具,而是因为我发现了一个不需要旧工具的场合,而那个场合正在变得越来越多。
想想看我们现在用 LLM 做的那些事情:把一张图片里的表格数据扒出来写进 Excel,给小孩生成一张带拼音的田字格练字用,帮朋友算一下露营的预算按人头怎么分摊,把一段播客的音频转成文字再提炼出三个核心观点。这些事放在以前,你总得找个工具:Excel、Word、某个现成的 App,或者干脆手工做。你找工具的过程有时候比事情本身还耗时。但现在你只需要描述一下,三十秒之后你拿到了结果。
这些事情有一个共同特征:它们不需要「长期存在」。会议纪要写完了,发出去,大家看完了,这件事就结束了。田字格打印出来给小孩写了,字会了,纸扔了,这件事也结束了。露营预算算出来,钱分了,这件事还是结束了。这些东西的「寿命」可能不超过四十八小时,它们的「用户」往往就是你自己,或者你和你身边的两三个人。
以前我们做软件,不管大小,都默认它是要长期存在的。一份 Excel 表格可能会在下个月的预算里继续被修改,一个内部工具可能会在两年后被新来的同事接手,一个网站可能会在三年后被重新设计。这种「长期存在」的预期深刻地塑造了我们做软件的方式:我们必须考虑可维护性,考虑多人协作,考虑数据的持久化,考虑未来需求变化了怎么办。这些考虑不是开发者的个人偏好,它们是工业化的软件工程在过去几十年里沉淀下来的最佳实践,目的是让软件能够活着活得久一点,活得好一点。
但如果一个软件从一开始就不打算长期存在呢?
那些最佳实践的必要性就需要被重新审视了。你不需要单元测试,因为这个代码跑完一次就不会再跑了。你不需要版本管理,因为没有人在意它三个月前的版本是什么。你不需要向后兼容,因为它不会有下一个版本。你甚至不需要代码——你只需要结果。
这听起来像是软件工程的降级,是一种倒退。但如果我诚实地说,我不确定它一定是倒退。或者说,「倒退」这个词预设了一个方向,而我现在不确定那个方向是不是唯一的方向。
我有一段时间一直在想一个问题:软件工程那套方法论,到底是在解决什么问题?
表面上它解决的是「代码质量」的问题——让代码不容易出错、容易理解、容易修改。但为什么我们需要代码不容易出错、容易理解、容易修改?因为代码会被反复使用,会被多人使用,会存在很长的时间。所以那套方法论真正在解决的,是「长期存在」带来的复杂性。如果一个东西不需要长期存在,那这套方法论的核心前提就不存在了。
反过来想,一个只存在十五分钟的会议纪要生成器,它出错了我怎么办?它出错了我就让模型再生成一次。反正成本趋近于零,反正没有人在等它上线,反正它的「线上事故」最多就是我再等三十秒。它不需要 SRE,不需要灰度发布,不需要故障复盘。它的「可靠性」是通过重新运行来保证的,而不是通过写得更好的代码来保证的。
这种思路在我的经验里是陌生的,因为它完全绕过了我花了十几年学会的那些东西。但我又不得不承认,在很多场景下它确实有效——甚至比「正规开发」更有效。十五分钟拿到结果,不需要调试,不需要处理依赖冲突,不需要担心某个 API 接口悄悄变了。
更让我不安的是,我开始意识到,我过去很多「正规开发」其实也是在解决一些本来可以不存在的问题。
我曾经花了两天时间给一个一次性数据报表写了一个自动化脚本,用来处理一个季度只用一次的数据清洗。脚本写得工工整整,有单元测试,有异常处理,有详细的 README,还用 Git 做了版本控制。后来我发现下个季度再用的时候,上游数据的格式变了,脚本报错了,我花了半天时间修复——而修复的过程中我开始怀疑,这件事从头到尾花了我两天半的时间,是不是真的比手工复制粘贴更划算。
这个问题我以前不敢问自己。因为问了就意味着承认那些「最佳实践」有时候是浪费。但这两年我越来越频繁地面对这个问题了。当一个人可以直接描述需求然后拿到结果的时候,「我们为什么要这样写代码」这个问题就从哲学问题变成了现实问题。
我不是在说软件工程的那套方法论应该被抛弃。大型系统、长期项目、多人协作的场景里,它仍然是不可替代的。我只是说,它不应该是唯一的参照系。
以前我觉得「写代码」是一种能力,这种能力的价值在于你能用它构建长期存在的东西。你写的代码可以跑很多次,可以给很多人用,可以被复用,可以被迭代。随着时间推移它会增值,因为它被用得越多就越值。
但现在有一整类需求,它的价值不在于「跑很多次」,而在于「跑对一次」。你不需要一个能重复使用的工具,你需要的是当下的、定制化的、精准匹配当前任务的结果。用完即弃,不复再用。这类需求的数量正在急剧增长,因为大语言模型让「即时构建」这件事变得极其便宜。
当一个东西用完即弃的时候,它就很难被称为「资产」了。一张草稿纸上的涂鸦不是资产,一段一次性生成的会议纪要也不是资产。资产需要时间才能形成价值,而这些东西的价值在生成的一瞬间就已经被兑现了——兑现完了就没有剩余价值了。
这个变化对我的冲击在于,我一直以来把自己定义为一个「能构建资产」的人。我的价值感建立在「我写的东西会留下来」这个信念上。我 debug 一个难缠的问题会有快感,部分原因是因为我觉得我修好了一个会在未来继续存在的东西,我的努力是可持续的。但现在有一整片需求,它的本质就是不可持续的——它不是需要被修好的东西,它是一次性的,用完就碎。
这让我重新理解了一些我以前不屑于理解的东西。以前看到一些「野路子」做法——比如用 Python 脚本直接跑数据不打包成工具,比如直接在 Notion 里手写公式而不是写自动化流程——我会在心里觉得这些人不够专业,不够工程化。但我现在开始觉得,他们可能比我很早就理解了某些事情的本质:不是所有的工作都需要被「资产化」。有些工作本身就是一次性的,对它做长期投资反而是浪费。
当然,我也有困惑。
最大的困惑是:如果代码不再是资产,那什么才是?或者说,在一个「微应用」的世界里,开发者的价值锚点在哪里?
如果一个人可以不需要懂代码就能拿到结果,那「懂代码」这件事还剩下多少不可替代的价值?我不是说大语言模型可以完全取代程序员——它现在还做不到,以后能不能做到我也不确定——但对于那些「一次性工具」的场景来说,门槛确实已经被大大降低了。一个完全不懂编程的人,用自然语言描述需求,就能拿到一个以前需要写代码才能实现的结果。
这个变化不会让所有程序员都失业,就像 Excel 没有让所有会计都失业,Word 没有让所有作家都失业。但它会改变「会写代码」这件事的稀缺性,而稀缺性变了,价值分配就会变。
我自己的感受是,这个变化让我重新审视了我花了十几年积累的那些东西。不是否定它们——我在正经项目里仍然需要那些东西——而是意识到它们不再是全部。我现在有两套并行的开发体验:一套是「正经的开发」,我仍然需要版本管理、测试、代码审查,这套经验是有价值的;另一套是「即兴的开发」,我用自然语言直接拿到结果,中间过程我既不拥有也不关心。
这两套体验正在我身上共存,它们之间有一种奇怪的张力。并不是对抗的张力,而是两种完全不同的心智模式突然发现对方存在的那种张力。「正经开发」的心智模式是建筑师式的——你要想清楚你要建什么,要规划好结构,要确保它能承受时间。「即兴开发」的心智模式是速写式的——你勾勒几笔,拿到感觉对了的结果,然后扔掉草稿。
我以前只熟悉第一种。现在我不得不在两者之间切换,有时候甚至是同时切换。这种切换本身不是问题,问题是它让我意识到,第一种心智模式不是唯一的,甚至可能不是最常用的——它只是过去几十年里因为工具限制而被放大的那一种。
我坐在那台电脑前,盯着那段会议纪要又看了一会儿。
文字很工整,条理清晰,要点都覆盖了。但我忽然发现,我不知道我应该对这段文字抱有什么样的期待。我应该检查它的准确性吗?我应该担心它漏掉了什么重要信息吗?我应该保存下来以备以后参考吗?
这些问题在以前是有标准答案的:当然要检查,要担心,要保存,因为这是你花时间做出来的东西,它有价值。但现在这些标准答案忽然变得不那么理所当然了——它只是一段文字,它值多少取决于它完成了多少,而它已经完成了。
我最终没有保存那段会议纪要。我把它发出去,然后把对话框关了。
这个动作很小,但它让我想了很久。