你用过的每一个无代码平台，其定价基准都是相同的：雇佣工程师的成本。这就是其核心卖点。编写真正的软件需要稀缺且昂贵的人才，因此这些平台向你推销了一种交易——牺牲灵活性，接受沙箱的限制，作为交换，你的运营经理可以自己发布库存仪表盘，而不必在工程积压名单中等待六个月。这笔交易在过去十五年里是合理的，因为基准一直成立。代码始终是昂贵的。
然后，基准崩溃了。当一个编程智能体能够以低于 Retool 一个席位的月费，构建并维护一个真正的应用程序——即托管在仓库中、拥有你自主掌控 Schema 的真实代码时，拖拽式抽象就不再是捷径，而变成了天花板。你现在是在支付溢价，只为了被“阻止”拥有真正的软件。
但这是大多数“讣告”都搞错的地方：这些平台并不会消亡。聪明的平台已经在向那些与代码成本无关的方向转型——受监管的数据访问、经过验证的集成，以及成为 IT 部门已经批准的沙箱。内部工具的限制因素正从“谁能构建它”转向“谁被允许构建它”，这一转变重写了你评估整个内部工具栈的方式。
你公司最具战略意义的 AI 投资，可能是一位工程师在某个周五下午编写的一个 Slack 机器人。它回答“如何获取分级环境凭据”、“哪个值班人员负责认证服务”或“部署卡住时的运行手册是什么”，它节省的工程小时数比整个面向客户的 AI 路线图还要多——而后者占据了你四分之三的模型开销、安全审查队列以及发布沟通带宽。
组织架构图并未反映出这一点。OKR 文档也没有反映这一点。没有人是它的产品经理（PM），也没有人是它的工程经理（EM）。这个机器人之所以能生存下来，是因为构建它的工程师仍在回复 GitHub 上的 issue，在每一个面向客户的功能因六周的安全审查和发布就绪检查清单（之所以存在是因为客户可能会流失）而推迟发布时，它的价值正在悄然复合增长。
一家中型 SaaS 公司的资深工程师在上个季度花了整整两天时间去排查一个部署 bug，结果发现竟然是智能体的错。该智能体读取了一份最后更新于 2023 年的运行手册（Runbook），忠实地执行了第三步，并运行了一个在当前部署工具中已不再存在的命令。这份运行手册在 Wiki 中依然渲染良好——甚至截图也依然清晰可见——但它已经悄然变得对那些无法察觉环境已过时的读者充满敌意。人类作者完全没意识到，这份文档现在已经成了每个新员工的 AI 助手的关键输入。
这就是过去 18 个月里大多数工程团队中发生的悄然转变：内部 Wiki 累积了第二批受众。同样的 Confluence 页面、同样的架构图、同样的“我们如何部署”的 Gist，现在正由两个截然不同的消费者阅读——工程师本人和工程师使用的 AI 助手。这两类读者在完全不同的约束条件下消费同样的文字，并且当文档在编写时仅考虑了第一类读者时，会产生系统性的不同故障模式。
我是 Tian Pan，一名工程师型创始人，专注于智能体工程——构建自主 AI 系统并扩展工程团队。我撰写关于系统设计、技术领导力和 AI 智能体实战的实用指南。曾在 Uber、Brex 和 IoTeX 担任早期工程师。
