AI 都会写代码了，
自己的系统自己搓？

第一关放哪儿：能跑 ≠ 能用

AI 给你搓出来的系统，第一个现实问题不是好不好用，是放哪儿。三个选项，各有死穴：

业务系统的本质是多人协作：销售在外面录，财务在里面看，老板随时查。单机跑得再顺，只要"别人用不了"，它就不是业务系统，是个大号的表格。"能跑"和"能用"之间，隔着一整个部署和运维。这一关不解决，后面都不用谈。

第二关谁保安全：漏洞不写在演示里

过了部署关，更隐蔽的一关来了。真实世界里发生过这样的事：有人用 AI 手搓了一套客户查询系统，兴冲冲发出来展示，跟帖一句话戳破——这套系统等同于直接暴露在互联网上，所有客户资料都可以拿到。

这不是手艺问题，是结构问题。Veracode 用 80 个编程任务测了 100 多个大模型：45% 的任务里，AI 会把已知的安全漏洞写进代码；更扎心的是，更新的、更大的模型，这个比例几乎没有改善^[1]。也就是说，你让 AI 写得越快越顺，没人审的漏洞积得越多。

大厂怎么对付这件事？代码评审、安全扫描、渗透测试、权限审计——一整条流程在代码后面兜底。而自己搓的系统，这些环节一个都不存在。AI 编程对非技术者提供的，本质是思路、方法和原型；业务场景的深度问题和代码的安全问题，它不会替你解决，也没人替你兜底。

第三关谁陪它长大：系统是活物

前两关是"现在能不能用"，第三关是"明年还能不能用"。业务在变：加个产品线、换个审批人、税制调整、公司扩了二十人——系统得跟着长。成熟产品后面站着一整个团队在做这件事；自己搓的系统，后面站着一个当时的热情。

还有一个正在发生的变量值得知道：数据泄露事件里涉及第三方的比例，两年内从 15% 涨到了 48%^[4]——你接入的每一个外部工具、每一个随手上传的源码片段，都在扩大你的暴露面。同一份报告还指出，45% 的员工已经是企业设备上的 AI 常规用户，源代码正是最常被上传到外部平台的内容之一^[4]。自己搓系统的代码，说不定早就在你看不见的地方转了一圈。

所以这道关的判断标准很朴素：核心业务系统是长期服务，不是一次性交付。选它，本质是选一个会持续投入的团队，和一条不会断的更新流水线。

第一本账"省钱"：省下订阅费，付掉老板时间

手搓系统的第一卖点，永远是账面上立刻省掉的订阅费。这笔账最大的问题不是算错，是只算了一半：省下的是看得见的软件费，付掉的是看不见的老板时间。

没 IT 团队的中小企业，"搓系统"的人选只有两个：老板本人，或者被抽出来的业务骨干。而中小企业恰恰是老板驱动的组织——业绩靠老板带，方向靠老板定，资源靠老板撬。老板的时间，就是这家公司最稀缺的生产资料。他每天花三四个小时对着 AI 调系统，半年就是五六百个小时（示意口径：每天 3.5 小时 × 180 天）；这五六百个小时本该拿去见客户、谈大单、定战略。省下三五万软件费，搭进去企业第一 bottleneck 的半年——这笔账，几乎从来没有中小企业算平过。

更扎心的是：连专业的人都在这笔账上翻车。METR 做过一次随机对照实验：16 名资深开源开发者、246 个来自他们自己代码库的真实任务，随机分配用不用 AI。结果三层落差——开发者预期自己快 24%，做完自评快 20%，实测慢了 19%，预期和现实差了 43 个百分点^[3]。天天写代码的老手尚且如此，第一次搓系统的人凭什么觉得自己是例外？

返工的规模也有数可查：数据分析公司 GitClear 分析了 1.5 亿行代码，发现 AI 辅助开发与 41% 的代码扰动量相关——这些代码在生成后两周内就被重写或废弃^[2]。国内财经媒体已经在报道"处理 AI Coding 留下的烂摊子，正成为一片新的蓝海市场"^[2]——你的省钱项目，正在成为别人的收费生意。

一线的声音更直观。一位国内产品经理复盘自己"5 天肝出几万行代码"的经历，标题就叫"屎山雕花"：AI 的建议往往是"理论上最佳"，但不适合具体场景；功能上看起来没问题，性能和安全全是坑——嵌套循环 N² 复杂度张口就来，用户输入基本不验证，SQL 注入风险很高，"这些问题如果没有专业知识，很难发现"^[5]。搓得越快，没被看见的坑积得越深。

第二本账"贴我的需求"：贴的是谁的需求

"自己的系统，当然贴自己的需求"——这句承诺唯一成立的前提，是搓系统的人真的握得住需求的每一个末梢。把"谁来搓"推演一遍，就露馅了。

场景一：老板亲自搓，搓出的是"他理解中的业务"

老板的经验大多沉淀在中高层：懂营销、懂行业、懂趋势。但一线末梢他未必拿得住——客服场景里"客户半小时没回消息，该谁接手、怎么标记"，上门运维现场"师傅改了工单，备件库存有没有同步"，这些细节老板很可能一次都没亲手操作过。他搓出来的系统，是他俯瞰中的业务，不是跑在一线的业务。一线用起来别扭，又说不清哪里别扭，最后干脆绕开它记回自己的本子上。

场景二：各部门业务总各自搓，搓出一堆孤岛

那让懂行的人来？客服总监搓工单、销售总监搓跟单、仓储主管搓台账——每个都贴自己部门的诉求，然后呢？系统之间无法联动。一个国内制造业的真实样本：ERP 里物料编码是 10 位数字，MES 要求 12 位带字母；对接接口要额外收费；出了问题两家供应商互相推诿"是对方改了协议"；生产报工数据每晚批量同步，计划员第二天上午看到的，永远是"昨天的车间"^[6]。每个部门都贴得越准，墙就砌得越多。

三十个人，是一条分水岭

三五人的团队，老板看得见每一单，手搓"贴需求"大体成立——这篇不拦你。但团队过了三十人、部门职责开始清晰切分，企业就已经是平台化运作了：老板做的是资源组织、协调和战略部署，核心业务层靠的是部门协作、业务流规范和相互配合。这套平台能力由无数琐碎细节构成——审批到哪一级、改过的数据谁能再动、跨部门怎么交接。不从业务系统底座出发、全部从零搓，这些细节的工作量是海量的；等你补齐，半年一年过去了；而第一次搓大系统，代码问题、数据结构问题、业务逻辑问题会成片爆发。

结局往往很收敛：最后活下来的形态，退化成"方便的记录"——说穿了，就是 Excel 外面套了个壳。国内实施团队记录过一个真实场景：某集团工程成本管理系统上线前，五年的分包结算数据散落在 37 个命名不一的 Excel 文件里，"应付余额""待付金额""未结清款"同一个字段有 9 种变体，光数据清洗就占掉迁移周期的 68%——结论一句话："Excel 是卓越的计算工具，但绝非业务系统。把它当系统用，等于用算盘跑 ERP。"^[7]

分界线什么可以搓，什么必须买

三道技术关加两本经济账算完，结论反而收敛——不是二选一，是先过两个问题，线就自己浮出来了：

鼓励前者：用 AI 搓原型验证想法，是这个时代给老板的福利，成本几乎为零。管住后者：只要碰客户数据、碰钱、要跨部门协作要留痕，就走采购——不是因为技术做不到，是因为安全、运维、更新这三件事，买的是别人的整个团队在替你扛；而老板的时间和一线的末梢，你自己扛不起。

我们的看法贴需求的能力，不是搓出来的，是喂出来的

写到这儿，说说我们自己的看法。超兔做业务系统这些年，一个体会是：贴需求的能力不是搓出来的，是喂出来的。成熟平台里一个不起眼的细节——改过的数据谁能再动、审批到哪一级、跨部门怎么交接——背后是成百上千家客户踩过的坑。一个人半年搓出来的系统，贴的是一个人的理解；一个平台被无数客户喂了这么多年，贴的是无数个一线末梢。

顺着这条逻辑，超兔的产品观是低成本实现客制化：安全、更新、权限、审计这些底座能力摊在所有客户头上，谁也不用独自扛；菜单、工作台、字段、单据这些贴合业务的调整，在底座上做增量。厂商低价格能活下去，客户低成本能贴住业务，双赢才可持续。说句实话，企业选 SaaS 的初衷就是便宜，这不丢人；在便宜里还能拿到比项目型更高的回报，才是厂商的本事。

最后一条，也是我们对"贴需求"的最终回答：系统适应人，而不是人迁就系统。好的业务系统应该以最小代价去适应客户的习惯和场景，而不是让一线为了迁就系统，改掉自己顺手的工作方式。如果一套系统要求所有人先改变习惯才能用起来，它在一线就活不下去——不管它是搓出来的，还是买回来的。

后半段决定买了，也要会买

转过采购这条路，还有两个坑要绕开。

第一个坑：把"做不到"太当真。你提个需求，供应商回"数量太大，做不了"——这句话有时是真的技术边界，有时只是没努力，或者被自己家的技术惯性挡住了。判断方法不是逼问，是换问法：

第二个坑：轻易否定你场景的顾问。你的需求说出来，顾问一句"这个不合理"就打回——小心。企业里存在的做法，多半有它存在的道理；好的顾问会先承认场景的合理性，再分析哪里可以优化。顺序反过来的，要么不懂你的业务，要么不想花这个力气。

收尾问出口的四个问题

不管最后是搓是买，这四句都值得先问自己：

AI 把"做出一个系统"的门槛打到了地板上，这很好——原型验证从此零成本。但生意系统的门槛从没降过：它要的是部署、安全、更新这三件事背后一直有人兜底，还要有人握得住一线末梢的每个细节。手搓省的是订阅费，花的是老板的时间；贴的是搓系统那个人的想法，贴不住一线的痛。工具可以白嫖，兜底买不来假装。