ARTICLE · 1310849
当 AI 能随手写代码,软件会不会死?
当 AI 能随手写代码,软件会不会死?AI 写代码越来越便宜，用户正在从"人"变成"Agent"。软件不会死，但它作为"应用"的形态正在瓦解——价值正从代码，沉向数据和规则。
你大概已经养成了这个新习惯：要看一个数据、合并几份表、把一种格式转成另一种，不再去找工具，也不再自己写脚本。你直接跟 AI 说一句话，它写一段代码，跑完，把结果丢给你。而那段代码，你是不看、不存、也不维护的。下次有类似的事，再让它重写一段。 这件事如果只发生在你一个人身上，好像没什么。但如果把它放大到整个行业，会推出来一个相当激进的结论—— 既然 AI 可以随手写代码、随手执行，那么大量"以帮你把某件事做了"为卖点的软件，尤其是 SaaS，存在的必要性就被抽走了。那些细碎的功能模块，不再需要有人预先写好、打包、卖给你，而是在你需要的那一刻，被现场生成。 但有一样东西没法现场生成：数据。数据必须持久地存在。 于是问题变成了：如果逻辑可以随用随生成，而数据必须保留，软件最终会长成什么样子？ 在回答之前，得先回答一个更基本的问题——现在的软件，不好吗？为什么要变？说不清驱动力，后面所有的预测都只是想象。
说实话，现在的软件并不差。界面你熟悉，点几下就能完成，这是三十多年打磨的结果。 但"不差"，是相对于过去的替代方案而言。换个尺度看，现在的软件形态承担着一组巨大、却已被我们当成正常的成本： 适配缺口 每家公司的流程都不一样，软件却是通用的。于是要么公司改流程去迁就软件，要么花钱做实施和定制。企业级软件的实施费用，通常是许可费的两到五倍——整个 SI（系统集成）行业，就是靠这个缺口活着的。 碎片化 一家中型企业平均用着上百个 SaaS，每一个都有自己的数据孤岛，自己对"客户"的定义。把数据从一个系统搬到另一个系统，是无数员工每天的实际工作。 交付滞后 业务变了，提需求给供应商，排进路线图，十八个月以后才上线——而那时候的业务，又变了。 功能冗余 大多数企业软件里，七成功能没人用，但每个用户都得为它付费。你以为大家怎么用系统的？学习在菜单里怎么绕过去、怎么导出到 Excel。几乎每个企业系统里使用率最高的功能，都是"导出 Excel"这个按钮——而这个按钮的存在本身，就是一个证据：系统给的形态，根本不是用户要的形态。 这些成本有个共同特点：它们不在你使用的那一刻被感受到，而是摊在组织层面、摊在时间上。所以没人觉得软件不好。就像二十年前，没人觉得去银行柜台办业务不好——用户不会主动要求一个他还没见过的东西。
不是因为不满，是因为约束条件变了。 技术形态的变化，很少是因为旧东西不好。马车不是因为不好才被替换的。变化发生的原因，是旧形态原本是对某个约束的适应；而现在，那个约束消失了。 现在的软件形态，是对两个约束的适应。 约束一：代码很贵。既然写代码贵，唯一经济的办法就是写一次、卖给一万家企业，这强制了通用化。而通用化又带来适配缺口、功能冗余、实施行业——整个 SI 的形态连同商业模式，全是从"代码很贵"这一个前提推出来的。 一个贴切的类比，是成衣。成衣之所以存在，是因为量身定制太贵，所以大家接受 S/M/L 的妥协。如果裁缝变得即时且免费，你就不会再买成衣了——但你会保留两样东西：你的尺寸，和面料供应商。M 码这个妥协本身，就消失了。当代码的边际成本趋于零，通用化就不再是必须的约束，均衡点就会移动。这不需要任何人对现状不满，经济规律会自己推过去。 约束二：用户只有人。现在的软件为人的眼睛和手设计——菜单、页面、按钮、点击。但接下来，越来越多的用户会是 Agent。Agent 不需要界面，它需要数据和动作。让 Agent 去点界面，那是 RPA 的老路：脆弱、慢，一改版基本就断。这是一个选择压力——当客户的 Agent 要完成一件事，它会绕过"只有界面、没有接口"的软件，直接找把数据和能力暴露出来的软件。要么你把自己拆成数据和能力，要么你被绕过。这比"用户不满"强得多，因为是生存压力。 两个约束同时松动，才是这次和过去不一样的根源。低代码、BI、API 经济过去二十年都在往同一方向推，但只松了一点点；现在是"写代码的成本"和"使用者的性质"同时变了。 还有来自供应商的推理：按席位收费，会随着 Agent 接管工作而崩塌。一个人配一百个 Agent，席位怎么算？供应商被迫找新锚点，而能守住的，只有数据、语义、规则、能力这几层。所以不只是用户在拉，供应商自己也会往下沉。
"代码不用保存，用完就扔"——这个判断，站在个人角度是错的推论，站在系统角度是错的。 那段代码对你个人没有复用价值，但它有一个不可替代的价值：解析结果。今天 AI 算出来上季度毛利是 1230 万，下个月再算是 1180 万，差在哪里？是数据变了，还是这次代码用了不同的口径？如果代码没留，这个数字就不可审计、不可复现、不可对账——在任何需要对数字负责的场景里，这是不可接受的。 所以我的第一个判断是：代码会保留，但身份变了。过去代码是资产，需要维护、版本管理、复用，是软件公司的护城河；以后代码是记录，像实验室笔记一样附着在数据产物上。保存的目的不是复用，而是解释"这个结果怎么来的"——它是 provenance，是溯源的证据。软件工程的重心，会从"维护代码库"转向"管理数据产物的来龙去脉"。
Excel 给我们的启示是：会消失的，是这一类软件——它的核心价值，只是在你自己的数据上套一层界面和工作流。 判断标准很简单：如果一个产品做的事，是帮你在自己的数据上用某种方式看、改、流转、转换，而数据本身就是你的，那它存在的全部理由就是"写这段代码很麻烦"。一旦写代码不麻烦了，它就没了。 典型的有：内部管理、后台 BI 和报表工具、表单工具、轻量项目管理、各种 dashboard、大量垂直 SaaS 里的工作流、部分 CRUD 类行业软件。 历史先例就是 Excel 本身。它早就是"持久数据 + 一次性逻辑"的模式，每个人写自己的公式，用完不维护，下次再写。按"AI 消灭软件"的逻辑，Excel 三十年前就该消灭企业级软件了，但它没有。为什么？ 答案恰好揭示了什么会留下来：定义不一致（同公司十个版本的"销售额"）、没权限审计（谁改了哪个数为什么改没人知道）、规模上不去（几十万行就卡、几百万行就崩）、多方协作没契约（你的表和供应商对不上要人工对账）。AI 时代相当于给每个人一个能力无限的 Excel，写代码不再是瓶颈，但这四个老问题会被放大一百倍，并逼着另一层东西沉淀下来。
数据基底，这四样东西会沉淀。缺任何一样，数据都没法被一群 Agent 安全地使用。 数据 + 语义。 光分表不够。这个字段什么意思？指标怎么定义？两表怎么关联？必须持久存在，否则一千个 Agent 给出一千种解释，公司内部数字永远对不上。今天这层叫元数据、本体、指标平台，一直是数据库附属品；以后它会变成企业软件的核心，应用层退场，这层接替位置。 不变量和规则。 订单未付款不能发货、审批超 50 万要两级签字、折扣超两成要主管确认——这些是业务规则，不是代码。让 Agent 每次从对话重新推断规则是危险的，它可能推断错而你不会每次都查。所以规则以声明式约束长在数据上，Agent 写的代码必须在约束内运行，碰线就被拦。代码不需要知道规则，规则由基底执行——这其实就是数据库 constraint 和 trigger 思想的大幅放大。 身份、权限、审计。 谁的 Agent 能动？哪些数据动了要留痕？Agent 越能干这层越重要。一个能写任何代码的 Agent 若无权限约束，等于把数据库 root 给了每个员工。 热路径和共享能力。 低频任务现写没问题；一天跑一亿次的东西每次现写，又贵又慢又不可靠，必须是编译好、测过、优化过的稳定代码。还有需专业积累的：支付清算、税务引擎、搜索引擎、机器学习模型、物理控制系统——难点不在写代码，在于十年沉淀的边界 case。它们以"能力"（tools / API）形式存在，让 Agent 调用而非重写。 这四样合称数据基底，是新的 system of record，是软件解体后最值钱、也最有粘性的一层。
代码的结晶化。任务第一次出现，AI 现写；重复几次，AI 发现是模式，缓存成参数化函数；组织内多人用，提升为受维护工具；跨组织用，变成协议和产品。软件不再预先设计，而从大量一次性代码里逐渐沉淀——很像 JIT 编译对热点代码的处理：先解释执行，发现热点再编译优化。软件公司角色随之改变：从"预测用户要什么、提前准备"变成"观察什么在结晶，把它接住、沉淀成可靠的东西"。 生成式 UI 的分层。长尾任务界面现生成、用完即弃；高频任务界面稳定下来，因为人需要肌肉记忆和一致性。界面分两层：稳定的壳 + 随需生成的内容。 多方契约层。你的 Agent 和供应商的 Agent 要对一张发票达成一致，这不是任何一方代码能单方面决定的，需要双方认可的协议。当每个组织都有自己的 Agent 写代码，组织间接口必须比以往更稳定明确，这类协议的重要性会超过任何单一软件。
把以上放在一起，我的判断是：软件从"应用"——界面 + 逻辑 + 数据的打包物——解体为三层。 底层：数据基底。 数据、语义、规则、权限、审计，新的 system of record。所有 Agent 代码在它之上运行、被它约束、向它归档。 中层：能力。 稳定的、有服务保障的、验证过的工具和协议——数据库、支付、搜索、模型、推理、设备控制，以及跨组织协议。存在理由要么是性能，要么是积累，要么是多方信任。 顶层：一次性生成的代码和界面。 随用随选，不为复用保留，但作为溯源记录归档到底层；反复出现的部分逐渐结晶、下沉到中层。 今天熟悉的应用，是这三层被强行捆在一起卖的。Agent 把捆绑的理由拿掉了。
对照开头的五项成本： 适配缺口消失。 代码为你这次的需要生成，没有通用版本，也就没有迁就，实施行业的存在基础随之消失。 碎片化被釜底抽薪。 不再有上百个各自为政的应用各存一份"客户"，只有一个基底、一套语义，客户在全公司唯一定义，所有 Agent 都引用它。数据搬运这项工作本身就消失了。 交付周期归零。 业务变了，规则在基底里一改，AI 生成的代码当天就按新规则跑，不再有路线图，不再有十八个月的上线。 没有冗余。 你没要的功能不被生成，不需在菜单里绕过别人要的东西，不再需要导出 Excel——Excel 作为"逃离系统的出口"这个角色彻底消失。 两项现在做不到的新能力： 每个数字都可解释（结果带着代码、数据、版本、执行、身份、规则、校验、审计的溯源记录，从事后调查变随手点开）；为价值付费而非为席位付费（买的是数据托管与调用结果，不是七成没用的功能和一百个 Agent 席位）。
当下的软件其实还有很多优点，这些优点决定了变化的边界和速度，也解释了为什么未来并非"一切现生成"。 一致性。 高频任务需要肌肉记忆，收银员、客服、调度员每天几百次操作，界面一天一个样是灾难，所以高频界面会稳定。 可预测性。 测过一万次的代码和刚生成的代码可靠性不同，关键路径要前者——这就是能力层必须存在、结晶化会发生的原因。 应用是一种组织共识。 一个 CRM 不只是工具，是公司"这样做销售"的具体编码。拆掉若无东西接住，共识会退化成"每人一张 Excel"的混乱——这正是规则和语义必须沉淀到基底的原因，基底层做不好，转变就失败，大家退回应用惯性。 采购、合规、认证成本已沉淀 ，转变会持续十年以上且不均匀：最先被替的是痛感最尖锐、风险最低处（内部工具、报表、系统间胶水、长尾需求）；最后被替的是核心交易系统和受监管领域，甚至可能一直不被替。 生成成本不为零。 推理有延迟有费用，一天一亿次现生成不划算，这同样指向结晶化而非一切现生成。
按席位收费会死，因为席位是 Agent 不是人，一人可配上百个 Agent。收费会转向：按数据托管量、按能力调用量、按结果付费。 护城河从"我的代码你写不出"，变成三种新东西： 我的数据语义你迁不走。 指标、定义、规则、溯源全在你这，迁移成本极高。 我的协议大家都在用。 多方契约形成后，网络效应难替代。 我的能力经十年边界 case 验证。 支付、税务、合规这类领域，正确性本身就是壁垒。 反过来说，今天以"功能多、界面好、工作流顺"为卖点的软件，护城河会在几年内清零。
Agent 写代码越好，"知道什么是对的"就越成为瓶颈。 当写代码成本趋近于零，剩下的全部难度都在规格说明上：业务规则是什么？数据怎么定义？合规要求是什么？什么情况该拦、什么情况该放？而这些，恰好是沉淀在数据基底上的东西。 所以这个转变不是软件消失了，是软件的重心从逻辑彻底搬到了数据和它的约束上。写代码的人会变少，定义规则、维护语义、设计契约的人会越来越多。软件公司不会消失，但活下来的会是拥有基底能力或协议的公司，而不是拥有功能的公司。
一个讨论不说自己的失效条件，就不值得信任。以下三种情况会让前面的判断不成立或大幅推迟： 代码生成可靠性停在"大部分时候对"。 若长期到不了"不检查就能跑"，每段都需人审，成本就降不到瓦解通用化的地步，变化只发生在低风险边缘。 组织其实喜欢被软件约束。 我假设企业受够迁就通用软件，但企业可能恰恰需要那个约束——约束本身就是管理，统一流程比贴合流程更有价值。如是，应用作为"流程编码"的角色会比我想象的顽固，基底层也要承担更重要的强制一致性职责。 监管锁定形态。 金融、医疗、政务等领域若监管要求用"经认证的软件"，而认证对象是可审查的应用而非"基底 + 一堆生成代码"，这些领域形态会被制度锁住，直到监管重新定义什么叫合规软件。 把这三条和前面的边界放在一起，讨论收窄为一句话：约束变了，均衡点一定会移动，方向是往数据和约束层、往逻辑和界面分散。至于移动多快、到哪里为止，由可靠性、组织偏好和监管决定——这三样，我都没有把握。
对软件公司：现在就问自己，产品价值到底在哪一层？如果主要在顶层（界面和工作流），尽快往下沉，去占住数据、语义和某个能力。 对企业：IT 最该投资的不是再买一套系统，而是把自己的数据语义、业务规则、权限模型，整理成 Agent 可以直接使用的形式——这是未来几年最有回报的基础设施。 对个人开发者：写功能的价值在下降，但定义问题、设计约束、验证正确性的价值在上升。从"会写"转向"知道什么是对的"。 最后，还是要回到那段用完就扔的代码。它看起来是软件的终点，其实是软件重新分层的起点。
