一天重写一套规则引擎，年省50万美元：AI写代码，终于开始动到企业“隐形成本”了

一场不算轰动、但很有杀伤力的“重写”

科技行业这两年听过太多“AI 帮我写了个 demo”“AI 三小时做出一个 App”的故事，热闹归热闹，很多人心里都清楚：那更像是舞台魔术，不太像企业系统真正会发生的事。

所以 Reco 这篇博客有意思的地方，不在于他们把一个东西“用 AI 重写了”，而在于他们重写的对象是 JSONata 相关能力，而且给出的结果非常企业化：一天完成，省下每年 50 万美元。这不是一个拿来发社交媒体截图的小玩具，而是一个和成本结构、产品架构、商业依赖直接相关的动作。

JSONata 本身并不是什么大众明星产品。它是一种轻量级 JSON 查询与转换语言，很多开发者会把它理解成“给 JSON 用的 XPath 或 jq 的近亲”。在数据集成、事件处理、规则匹配、工作流自动化场景里，它很常见，也很好用。问题在于，一旦企业把它放进核心产品链路，围绕它生长出来的依赖、性能开销、维护成本，往往就会悄悄变成“看不见但很贵”的技术债。

Reco 这次公开讲述的，本质上就是一次经典的软件工程选择：与其持续为外部依赖埋单，不如把关键能力收回到自己手里。只不过，这次把“重构周期”从过去可能的几周、几月，压缩到了一天。而这一压缩，正是 AI 对软件工程最有现实冲击力的地方。

省下的不是代码工时，而是企业架构里的租金

很多人看到“省 50 万美元/年”，第一反应可能是：是不是夸张了？如果只是重写一个解析器，怎么会这么贵？

但在企业软件世界里，昂贵的从来不只是几千行代码。真正贵的是依赖链条：授权费用、算力消耗、运行延迟、工程师维护时间、兼容性测试、故障排查，甚至还有“某个第三方组件一旦改动，整个产品团队都得陪跑”的组织成本。你买的看似是一个能力，背后付的却像是房租、水电、物业和中介费的打包账单。

Reco 作为做 SaaS 安全的平台公司，业务天然离不开大量规则、事件、策略、数据归一化和跨系统处理。像 JSONata 这样的表达式或转换引擎，在这种系统里很容易成为中枢神经的一部分。中枢一旦依赖外部，就会带来两个问题：一是贵，二是不自由。贵是显性的，自由受限则是长期的——你很难针对自己的业务模型做极限优化，也很难为特定客户需求快速改造。

所以，这次重写更像是在做一件“把租来的房子买下来”的事。AI 的价值不是替程序员少敲几行键盘，而是让原本由于成本太高、优先级太低而一直没做的架构性改造，突然变得可以做、值得做，而且能马上落地。对很多 CTO 来说，这类故事比任何“AI 自动生成网页”都更有吸引力，因为它直接通向利润表。

AI 编程的真正拐点：从写新功能，走向替换旧依赖

如果把时间拨回 2023 年，大家谈 AI 编程，大多围绕 Copilot、代码补全、单元测试生成，核心关键词是“提效”。到了 2024 年、2025 年，越来越多团队开始让大模型承担更完整的任务：读旧代码、理解接口、生成替代模块、补测试、做迁移脚本。到了 Reco 这类案例，味道又变了——AI 不再只是帮你加速开发，而是在帮助企业重新审视“哪些东西根本不该继续买”。

这是一个非常微妙但非常重要的变化。

过去几十年，软件工业的默认方向是分工越来越细：数据库买现成的，ETL 买现成的，规则引擎买现成的，身份认证买现成的，监控买现成的。好处是起步快，坏处是企业会逐渐变成一堆外部零件的装配厂。每个零件单看都合理，堆起来以后，成本、性能和复杂度一起失控。

AI 的出现让另一条路线重新有了经济性：把少数关键、昂贵、且足够标准化的中间层能力自己做回来。不是所有东西都要重写，当然也没必要搞“自研崇拜”。但过去许多“不值得自己做”的模块，现在可能只需要一个小团队、几天时间、加上严格测试，就能做出可用版本。这会对一批中间件、低代码工具、规则处理平台乃至部分开发工具厂商形成真正压力。

说得更直白一点，AI 正在把“Build vs Buy（自建还是采购）”这道老题目重新改写。以前答案往往是“买”，因为人力最贵、时间最贵；现在答案开始变成“先让 AI 帮我们估算一下，自己做到底贵不贵”。这是企业软件市场接下来几年最值得警惕的一种变化。

这事没那么浪漫：一天重写，不等于一天放心上线

当然，听到这里也别急着把“AI 一天重写系统”当成万能神话。作为记者，我反而想给这类成功故事泼一点必要的冷水。

第一，重写最难的通常不是把功能跑起来，而是证明它在边界条件、历史兼容性、异常输入、性能峰值和安全约束下都不会出事。尤其 JSONata 这种牵涉表达式求值和数据转换的能力，稍微一个 corner case 没覆盖到，轻则结果偏差，重则策略误判。对于安全公司来说，这类错误可不是前端按钮颜色错了那么简单。

第二，AI 生成代码的速度越快，越容易制造“理解错了但看起来很像对了”的危险。很多团队会在 demo 阶段对这种流畅性感到上头，真正上线后才发现文档、测试、可观测性和长期维护才是主菜。Reco 的案例如果要真正成立，关键不只是“一天重写”，还要看后续是否建立了充分测试、验证机制，以及团队是否真的掌握了这套新系统，而不是把一个黑箱换成另一个黑箱。

第三，这种节省并不适合所有公司。能够这样做，通常意味着团队本身对业务足够理解，对原有依赖足够熟悉，也有能力建立回归测试和上线保障。换句话说，AI 能帮你抄近路，但前提是你知道自己原来走的是哪条路。对工程基础薄弱、流程混乱、测试缺失的团队而言，AI 重写未必是降本，可能是把风险提前变现。

对行业的提醒：下一轮被 AI 冲击的，可能不是程序员，而是“软件税”

我觉得 Reco 这个故事真正有穿透力的地方，在于它提醒我们：AI 对软件行业的冲击，接下来可能更多体现在成本重构，而不是岗位替代。

这几年围绕 AI 编程最吸睛的话题，总是“程序员会不会被取代”。但现实更可能是，先被压缩利润空间的，是那些靠标准化功能收取高额授权费、但技术护城河又没有想象中那么深的工具型厂商。企业不会一夜之间不买软件，但会开始更认真地问：这个模块我每年交这么多钱，到底值不值？如果 AI 能帮我在一周内做出 80 分方案，我为什么还要为 95 分方案付十倍价格？

这会逼着软件厂商走向两条路。一条是继续做更深、更复杂、更难替代的能力，比如安全合规、行业 know-how、网络效应、生态集成和服务体系；另一条则是被迫接受工具层的价格回归。说得残酷一点，很多“并不差，但也没那么不可替代”的企业软件，可能正在迎来最难熬的几年。

这也带来一个值得思考的问题：当 AI 让重写旧系统、替代中间件变得越来越容易，企业到底会因此更自由，还是会陷入新的 AI 供应商依赖？今天省下的是 JSONata 或某项授权费用，明天会不会又变成对大模型平台、推理成本、代码代理工具的新型依赖？

技术史经常这样轮回：我们以为自己在摆脱束缚，结果只是把锁从左手换到了右手。区别在于，新的锁往往更柔软，也更难察觉。

对 Reco 来说，这篇文章当然有营销意味，任何企业写“我们用 AI 省了大钱”都不可能纯粹无私。但即便把营销滤镜摘掉，这依然是一条值得行业认真看的信号：AI 编程正在从“加速开发”迈向“改写成本结构”。而每当技术开始碰利润表，真正的变革往往才刚刚开始。