软件公司应用AI提效中的反常识误区

我在软件行业二十年了，最近越来越觉得一个事很反常识。

定制化软件公司，你以为成本大头是把软件做出来？不是。开发成本大概只占三成，剩下七成，全花在交付之后。用户不会用，你得教。权限配错了，你得改。软件功能覆盖不到的场景，你得人工拉数据做分析。还有些小需求，单独做一次开发都很难算进去，但不做客户又过不去。零零碎碎累积起来，才是真正的成本大头。

而且这里还有个二八定律。大多数人以为运维就是改bug，但过了上线初期那个集中修bug的阶段，bug只占运维工作的20%，剩下80%全是非bug类的——使用答疑、权限配置、数据补位、小需求迭代。

学术研究对软件维护占生命周期成本的比例，共识是60%到80%。我做定制化软件二十年，体感是70%起步，遇到关键大客户，可能更极端，80%都是交付后的成本。因为大客户更看重的，恰恰就是这后70%——软件交付之后，你能不能快速响应他们的变化，能不能在他们遇到问题时第一时间解决。

坦率的讲，这个成本结构，对定制化软件公司来说，是个沉重的负担。但换个角度看，它也是一个巨大的机会。

---

01 AI提效的算账

现在AI来了，大家都在兴奋什么？AI写代码。GitHub Copilot说46%的新代码由AI生成，开发人员生产力提升55%。Cursor、Claude Code，各种工具层出不穷。整个行业都在盯着一个方向，怎么让AI帮人更快地写代码。

但我们来算笔账。

假设AI真的让开发效率提升了55%，开发成本占总成本的30%，那总成本降了多少？30%乘以55%，16.5%。

那如果AI用在后70%呢？同样提升55%的效率，70%乘以55%，38.5%。

2.3倍的差距。

即便保守一点，后70%的AI提效只有开发侧的一半，27.5%，那总成本也能降19.25%，还是比开发侧的16.5%强。

你把AI全砸在写代码上，就算效率翻倍，总成本也就降15%。但如果你能把AI用到后70%的运维环节，效率翻倍的话，总成本降35%。一个是15%，一个是35%。

但偏偏，几乎没人盯着后70%。

也能理解。后70%太碎了，太杂了，太依赖人的判断和经验了。不像写代码，输入需求输出代码，路径清晰。后70%里面全是人——用户不会用，运维人员得去解释。权限配错了，运维人员得去改。数据拉不出来，开发人员得手动跑SQL。每一件都不复杂，但每一件都需要人来介入，而且每一件的上下文都不一样。

所以后70%是一块难啃的骨头。但难啃不代表不能啃，关键是得有路径。

---

02 AI接管后70%的四个台阶

我自己的感受是，AI对后70%的介入，不是一刀切的，而是一个从易到难的梯度。

第一层，最简单的，用户不会用。不知道入口在哪，不知道某个功能怎么操作。这类问题现在全是运维人员在回答，一个一个地解释，一个一个地截图指导。但这类问题其实最适合AI来接手——它只需要理解用户的提问，然后在系统里找到对应的答案，快速响应。不需要改代码，不需要动数据，就是回答问题。

第二层，权限配置问题。用户因为配置不当缺少权限，导致某个功能用不了。比第一层稍微复杂一点，因为它涉及到系统内部的权限体系，但本质上还是结构化的问题——查权限表，对照角色，该加的加上，该改的改掉。AI完全可以按照规则来自动处理。

第三层，功能缺口导致的人工补位。软件覆盖不了所有场景，有些数据客户要但系统里拉不出来，开发人员就得手动跑SQL，导出数据，做个分析，再发给客户。这类需求灵活多变，每次都不太一样，所以没那么容易。但可以总结出一些规律性的、有共性的部分，先让AI来自动化完成。剩下的非共性部分，再由人来兜底。

第四层，新功能开发。客户提了一个新需求，要做一个小功能。这里最关键的不是需求本身，而是这个需求该不该做，该不该放在这一期，该不该收费。这些判断必须由人来完成。人做完判断之后，AI再来接手实现。

从第一层到第四层，AI的介入程度逐步加深，人的角色也在变化——从完全不需要人，到人做判断AI来执行。不是一步到位，而是一层一层地替换。

---

03 你已经在做面向agent的事了

那问题就来了，如果你要AI真正接管后70%的这些任务，你的软件从设计的第一天起，就得为这件事做好准备。

说到这个，我最近注意到一个细节，越想越觉得有意思。

我们的客户，常常在上线之后隔三差五就提一些运维需求，每次都不大，但每次都得有人去响应。我们的运维开发人员被折腾得不行，后来他偷偷干了件事——自己写了一堆没有界面的小API，纯后端接口，没有UI，就是为了让下次遇到同类问题时，能直接调一下就搞定。

这个行为本身太寻常了，任何一个做过运维的开发都干过。但换个角度去看，其实非常诡异——你写了一个给人用的软件，有界面有按钮有流程，但运维过程中你又写了一堆没有界面的接口，不是给人用的，是给程序调用的。

你其实已经在做一件事了，只是你从来没这么命名过。

你在为agent设计接口。

那些无UI的API，本质上就是给未来的智能体预留操作入口。你不知道它什么时候来，但你的直觉告诉你，这些事不应该每次都由人来做。

而2024年底，Anthropic推出了MCP，Model Context Protocol，模型上下文协议，给AI Agent连接外部世界定了一套标准。到2026年，MCP已经被OpenAI、Google、Microsoft全盘采纳，捐赠给了Linux基金会，生态已经汇聚了上万个开源服务器。

你再看看我们那个运维开发写的那些无UI API——他做的事，和MCP Server做的事，有什么区别？

没有区别。只是缺了一个标准协议，缺了一个名字。他凭直觉在做的事，整个行业正在用一套正式框架把它标准化。

所以，软件从设计的第一天起，就要面向agent来设计。这不是一个未来时态的判断，而是一个现在进行时的事实。

---

04 从第一天起，为agent而设计

你可能觉得这话说得有点早，但你看几件事。

2026年5月，OpenAI和Anthropic前后脚做了同一件事——从卖模型转向卖服务。OpenAI这边初始投资超40亿美元成立部署公司，Anthropic那边联合黑石高盛成立15亿美元的企业AI服务合资公司。OpenAI的意思很直白，构建AI模型只是第一步，企业落地应用才是价值所在。

模型是房子，落地是物业服务。

他们用的那个模式叫FDE，Forward Deployed Engineer，前沿部署工程师。这个模式是Palantir开创的——把工程师直接“部署”到客户现场。有个工程师为空客A350项目搬到了图卢兹，住了一年，每周四天在工厂跟一线生产人员并肩工作，最后帮空客把A350制造速度提升了4倍。

Palantir交付的不是软件，是数据成果。软件只是为服务提供支撑的工具。客户买的不是工具，是配套服务。前20年都没盈利，因为服务成本太高，但一旦跑通，“40法则”得分114%，市值逼近5000亿美元。

现在OpenAI和Anthropic全盘复制了这个模式。“前沿部署工程师”的招聘启事一年暴涨7倍，从Palantir的圈内黑话变成全行业标配，只用了一年多。

但这里要讲清楚一件事。FDE解决的是“服务深度”的问题，AI解决的是“服务成本”的问题——两者不是替代关系，而是叠加关系。Palantir派一个人驻场，能覆盖的问题范围是有限的。但如果你从设计阶段就为agent预留了接口和协议，那一个FDE工程师加上AI，能覆盖原来五个人的工作量。人做判断，agent做执行，服务深度不变，成本大幅下降。

回到定制化软件公司，面向agent来设计，具体怎么做？我自己总结了几个方向，可能有些想法还不成熟，但方向是对的。

第一，暴露接口，而不是只做界面。

传统软件设计的思路是，一切功能都通过UI来操作。但如果你要AI来接管运维任务，它需要的不是按钮和表单，而是可以直接调用的API。所以从设计阶段开始，每一个功能都要同时考虑人怎么用和agent怎么用。界面给人，接口给agent。

怎么判断哪些接口该先暴露？看运维人员过去三个月手动处理最多的五类问题，这五类对应的操作，就是第一批要暴露API的。不要一上来就追求全面覆盖，先把最高频的5个场景打通，验证效果，再逐步扩展。

第二，内置操作协议。

AI要接管运维任务，不只是能调用接口就够了，它还需要知道在什么情况下调用哪个接口，按什么顺序调用，调用之后怎么判断结果。如果你在软件里内置一套操作协议——权限配置的标准流程、数据查询的推荐路径、常见问题的处理步骤——AI就能按照协议来执行，而不是每次都从零开始。

协议的颗粒度怎么定？一个简单的标准，如果同一个运维操作，你的运维人员需要跟新人解释超过两次，那就值得写成协议。解释一次的可能是特殊情况，解释两次以上的就是重复模式，就该标准化。

第三，数据本体化。

你的软件里的数据，不应该只是一堆表和字段，而应该对业务实体有清晰的定义——什么是客户，什么是订单，什么是权限，它们之间的关系是什么。人看界面就能理解这些，但AI需要的是结构化的语义信息。

Palantir的Foundry就是这么做的，把企业数据“本体化”，事物、对象、属性、关系，全部数字化。这样AI才能理解你的业务，而不只是看到一堆数字。

怎么判断数据本体化做到位了没有？一个测试，如果你的运维新人在不看界面的情况下，光看数据结构就能理解“这个客户有哪些订单、每个订单处于什么状态”，那说明本体化到位了。如果他还是得打开界面才能理解，说明数据结构对AI来说还是不够清晰。

第四，人的判断不可替代，但可以前置。

前面说AI介入的四个台阶，最后一层是需求判断——该不该做，该不该收费，该不该放在这一期。这个判断必须由人来完成。但你可以做的是，把判断的前置信息准备好，让人做判断的时候更高效。AI可以把需求分类、评估影响范围、预估开发工作量，然后把这些信息呈现给人，由人来拍板。拍板之后，AI再来执行。

面向agent的设计，不是要把人踢出去，而是让人和agent各干各最擅长的事。人做判断，agent做执行。

说到底，这四件事的核心逻辑就一条，你的软件不是只给人用的，它还要给agent用。从设计的第一天起，就要同时考虑两种用户。

你可能觉得这太超前了，现在连AI运维都还没成熟，谈什么面向agent设计。但我想说，我们那个运维开发人员，在没有AI的时候，就已经在写无UI的API了。他凭直觉做的事情，现在整个行业正在用MCP来标准化。Palantir在没有AI的时候，就已经在派工程师驻场了，现在OpenAI和Anthropic用40亿美元来复制这个模式。

这些不是预测，这些已经发生了。

软件行业正在经历一个从“卖产品”到“卖服务”的结构性转变。而定制化软件公司，因为一对一的服务模式，30/70的成本结构天然就更偏向服务端。AI来了之后，所有人都在盯着前30%的提效，但真正的收益在后70%。而要让AI真正接管后70%，你的软件从设计的第一天起，就要面向agent。

你已经在做这件事了，只是还没意识到。

现在，该有意识地去做了。