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

超兔CRM · 业务系统选型笔记
面向 / 企业主 · IT 决策人

"这个功能，我让 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 的初衷就是便宜，这不丢人；在便宜里还能拿到比项目型更高的回报，才是厂商的本事。

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

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

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

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

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

判断一个顾问值不值得信，看他怎么对待你"土办法"：先问为什么这么干，再谈怎么改更好。

收尾　问出口的四个问题

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

Q1　先数人头：团队几个人、部门分立了吗？
三五人、老板看得见每一单，手搓原型随便试；三十人以上、部门职责清晰，两个巨坑（老板时间、一线末梢）就绕不开了——这道题比功能清单重要。

Q2　这套东西出了安全事故，第一个电话打给谁？
答不上来的，就还不该碰真实客户数据。

Q3　三年后它还在更新吗？谁在更新？
自研看人，采购看公司的团队和迭代记录——系统是活物，停更就是开始腐烂。

Q4　对面这个人，懂我的业务吗？
可靠的采购 = 公司保障（平台稳定、持续更新、团队稳健）× 顾问懂你（业务、人员、方案针对性）。两个引擎，缺一个都跑不远。

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

资料来源

1. Veracode, 2025 GenAI Code Security Report（2025-07-30 发布）。80 个编程任务、100+ 大语言模型测试：45% 的任务中模型会引入已知安全漏洞，仅 55% 的生成结果安全；且安全表现在更新、更大的模型上几乎没有改善。

2. GitClear 代码分析研究（样本 1.5 亿行代码）：AI 辅助开发与 41% 的代码扰动量（code churn）相关，即生成后两周内被重写或废弃。国内财经媒体报道见新浪财经《处理 AI Coding 留下的烂摊子，正成为一片新的蓝海市场》（2025-09-25）。

3. METR《How AI Assistance Affects Developer Productivity at Microsoft》之前的随机对照实验（2025-07，arXiv:2507.09089）：16 名资深开源开发者、246 个自有代码库真实任务；开发者预期提速 24%，自评约快 20%，实测慢 19%。中文技术社区解读见掘金《AI 编程的失控临界点》。

4. Verizon, 2026 数据泄露调查报告（DBIR）。基于 145 国、超 3.1 万起安全事件与 2.2 万起已确认泄露：涉及第三方的泄露占比达 48%（一年前 30%、两年前 15%）；45% 的员工已是企业设备上的 AI 常规用户，影子 AI 使用激增，源码、图片与结构化数据是最常被上传至外部 AI 平台的内容。

5. CSDN《我用大模型砌"屎山雕花"：5 天肝出几万行代码！产品经理的 AI 编程翻车记》：AI 建议"理论上最佳"但不适配具体场景；嵌套循环 N² 复杂度、用户输入不验证、SQL 注入风险高，"这些问题如果没有专业知识，很难发现"。

6. 搜狐《一体化 ERP+MES 平台：中小制造企业数字化转型的"必选项"而非"可选项"》：ERP 物料编码 10 位数字与 MES 12 位带字母不兼容；接口额外收费、供应商互相推诿；生产报工每晚批量同步，计划员看到的永远是"昨天的车间"。

7. 用友大贝云《Excel 不是系统：当财务、工程、运营团队还在用表格协同》：某集团工程成本管理系统上线前，5 年分包结算数据散落在 37 个命名不一的 Excel 文件中，同一字段 9 种变体，清洗占迁移周期 68%；"把它当系统用，等于用算盘跑 ERP"。