一 人类开发者必须承担核心代码的全部责任
Linus在2026年北美开源峰会说：
“你用AI生成个一次性的，用完就扔的新项目，很合适。我们管这叫 vibe coding（氛围编程）。但如果你想做个严肃的项目，可能需要维护它 35 年甚至更久。事情就远不止写个提示词，让别人或 AI 替你生成代码那么简单了。”
（https://www.youtube.com/watch?v=fi29pfLcW4I&t=2s）
关于Vibe Coding，几乎资深工程师都有如下共识：
AI适合原型。但无论代码是人写还是 AI 生成，人类开发者都必须承担全部责任，必须能读懂、理解、必要时重写全部代码。
对于长生命周期基础设施和核心代码，不能把决策权交给提示词和大模型。
AI不会消灭程序员，但会淘汰 “只会调 prompt、不懂系统底层” 的程序员。
二 陀螺上的新世界
我完全认同上述以开源教父Linus为首的天才工程师们的观点。对于筑成信息社会基石的核心部件，他们的实践哲学在可见未来仍然极为重要。
但在生命期长达三五十年的系统之外，那些过去只是原型和玩具的，只存在三五分钟的项目/需求，是否慢慢开始创造巨大价值？
根据我个人这两个月实践得来的粗浅经验，拜天才们持续打造的各种高效信息处理工具所赐，我们所处世界的运转速度也越来越快了。我们在这越抽越快的陀螺上，发现有无数新机会亟待验证——证明有效、或者证明无效。
与快速落地相比，页面是否丑陋，是否有大大小小的bug都无关痛痒。时间不等人，别说没有屎上雕花的闲工夫，甚至开发流程多一个步骤，都会拖慢进度，令业务模型无法在有限时间窗口内实现闭环，从而丧失机会。
（图：颇为满意的价值投资分析工具）
再次声明，我完全没有轻视传统软件和传统软件开发流程的意图。但我想，在软件行业的进化之路上，或许出现了一个“即用即弃”的新分支，帮助更多人，而不只是天才工程师们，在新世界中畅游。
三 “即用即弃”不需要银弹
软件工程的核心神话是：“我们可以建造屹立不倒的大教堂。” 为此，软件开发人员思考如何设计架构、规范代码、建立文档知识库，并把这些一代代的传给那些素未谋面的运维人员和程序员。我们希望有一枚银弹，对抗熵增、对抗凋零、对抗死亡。
这个叙事可以推导出一系列关于技术遗产和传承的管理要求。“代码是公司的核心资产”， “要写能经得起时间考验的系统”，“需要有能跨代际管理传承的知识体系”。等等。可惜，没有银弹。
但在“即用即弃”的哲学下，目标从“生成无懈可击的系统”，转为“有个刚好够用的帮手”。银弹的命题就此被消解掉了。
最重要的哲学命题便是死亡。我们就从项目的死亡说起。
如果有一天开发者倦怠不想维护了，项目该怎么办？
其实死亡并不是一个需要预防的悲剧。毕竟，没什么东西必须一直存在。开发者倦怠了代表项目暂时完成了它的使命。项目不一定只能是资产，它也可能是个消费品。
项目凋零过程中都发生了什么？从开发者的角度，他曾经思考过，尝试过，做出来过。而且做出来的东西，成功的发挥过作用或者完全没有卵用。再后来，这项目逐渐与业务需要不符，慢慢地少用了，被丢弃在一边。
项目死亡后，开发者放弃的是知识的载体，但并没有放弃知识本身。在再次相遇后，他仍然站在了昨天自己的肩膀上。“我留下了什么系统”并不重要，“我能做到什么”的自我认知更为重要。带着这些经验，很快就可以复活一个项目。
上面说的是对开发者自身而言，那为别人呢？
至少他留下了一堆屎山代码和一些文档，可以给别人一些启发。就着这些素材，别人很容易先抄后超。
当然，视角放远一些，人类历史上大多文明成果最后的结局都是灰飞烟灭，化成当代人基因中一个无法描述的小片段。这种事情太多太多，需要解决吗？能解决更好，但是不解决才是常态。
讨论完凋零与死亡，对于“即用即弃”哲学中一个项目的生的状态，也就极为简单了。
我们并不是想做一堆三五分钟就死掉的小垃圾。我们的目标是打造一个面对挑战与变化，可以高速迭代实时重构的演化型系统，每一个瞬间都燃尽了人与机器的全部才思，不留一点想到而未做到的遗憾。至于它能存在多久？三分钟和三十年，都不是考虑范畴内的事情。
（注1：吉卜力工作室其实也一直在做"即用即弃"的事：每一部电影都是一次性燃烧，团队解散又重组，没有永恒的"系统"。但宫崎骏、高畑勋们内化的能力，让他们能一次次从零开始。项目死了，人还活着，而且每次都脱胎换骨。）
（注2:这和价值投资，长期持有到底是多长时间，道理相似。“永远”是希望，事情不对了，下一个交易日就需要卖出。）
四 培训AI实习生的心法
AI对于一个资深业务人员来说像什么呢？它像个年富力强、勤劳肯干，有一堆知识，却没什么经验的实习生。
你当然不敢第一时间就把任何重要事情交给它全权代劳。
你得手把手、不厌其烦的教它。
1.你们一开始对着一个工作台（网页），一遍遍摸清楚某个功能模块需要什么数据，产出的内容和格式。谁可以写入，谁可以读。
2.你开始显性的在页面加一些执行按钮。再然后你把几个按钮合成一组，缩小折叠，由另一个大大的按钮触发。
3.你和它朝夕相处，在半手工半自动的重复劳动中，你们一起发现错误，一起推敲改正。错误越来越少。终于有天，你说，那就按设定好的规则自动帮我按那个按钮吧。再定时给我个报表。
4.再后来，一切操作都变成了运维指示灯里面的一盏。
徒弟终于独当一面，师傅可以放手了。这个过程要多久？可能是下一小时，可能是下周，也可能永远等不到。反正徒弟不行之前，老师傅先干着，旧日子不都这么过的。
你跟这些AI实习生一起工作，还得接受鸡飞狗跳。他们时常碎碎念念，把你嘱咐的话（需求），像便签纸一样，在前端界面里贴的满哪都是。
起初你眼里不容沙子，寻思有朝一日要开门迎客，总得收拾的漂漂亮亮。后来你习惯了，看着他们碎碎念，你暗自庆幸这么多错误想法，不用问就暴露出来，真好。
再后来，问题越来越少，虽称不上艺术品般完美，但都够用。你也满意了。 AI现在做的，和以后做的会不会犯错？这个我十分确定，一定会。
AI到底写了什么？我不知道，也不想知道。
论迹不论心。
五 新世界与旧世界的弥合
前面的天马行空，如何与Linus代表的旧世界弥合？我觉得未来的软件开发，可以划成三个领域。
1. 在核心基础设施领域，Linus的观点仍为圭臬。
2.在高度个性化服务领域，大批现有软件开发商会被超级个体Vibe coding模式的产物代替。
3.最后一个领域则是完全未知的。超强个体在“即用即弃”哲学下，借助AI一直保持着快速推倒重来的破坏性创造能力，捕捉鲜活世界的信息。或许这里才是Vibe coding 的主战场，而这对人类数字化水平的提升到底有多大影响，完全无法估量。
真实世界，本来就求同存异，掌握普世准则是人们有限带宽下的逻辑病。有趣的是，对于真正重要的第一第三领域，争议不大。 反倒是中间那类，观念会发生激烈碰撞。
1.AI 不是来取代你的，它是来跟你学手艺的。
2.出了事师傅兜着，不存在"AI 写的所以我不负责"这种逃避。
3.质量判断问题：什么时候能放手？不是 AI 能力到了某个客观标准，而是师傅主观判断"这时候可以了"。
这三个问题里，第三个最深。它把软件质量从"工程共同体的客观标准"拉回到了"主权者的个人决策"。这在传统软件工程看来可能是危险的，但在作者的语境里，它是唯一合理的——因为系统从一开始就不打算被移交，它是师徒二人的私语言。
”
延伸阅读：
《诺曼底72小时》AI无法取代的是人类在压力面前的责任与担当