去年某家做精密五金的客户找过来，说想用 AI Coding 把老旧的 ERP 重做一遍。他们看了几个 AI 编程的演示视频，觉得「既然 AI 一天能写一个 CRUD 系统，那我们这套 ERP 顶多两周就能搞定」。第一次需求会上，老板很自信地说："你们就把我们现有系统的截图丢给 AI，让它照着写一套就行，规则它自己能看懂。"
我们让 AI 跑了一天，确实把库存、出入库、采购单这些模块的骨架搭出来了。但第二天测试的时候，财务跑过来拍桌子：「这套成本核算逻辑是哪个白痴写的？我们一直用的是月加权平均，里面还要扣掉残次品调整，这里怎么全是 FIFO？」AI 不是白痴，AI 只是按它见过的 ERP 教科书最常见的方式写了一遍。这家公司用了十几年的"自己的算法"，AI 从哪里能读到呢？
AI Coding 现在到底能写什么
先把能做的部分讲清楚，免得过度悲观。截至 2026 年中，主流的 AI Coding 工具（不管是 Claude Code、Cursor 还是 GitHub Copilot 的 agent 模式）在以下几类任务上确实已经稳定可交付：
| 任务类型 | AI 完成度 | 人工介入比例 | 典型场景 |
|---|---|---|---|
| 标准 CRUD | 90% 以上 | 极少 | 员工档案、设备台账、文档管理 |
| 数据看板 | 80% 左右 | 调样式、配数据源 | 销售大屏、生产监控板 |
| 简单审批流 | 75% 左右 | 接入企业 IM、对接组织架构 | 请假、报销、用印 |
| 通用导入导出 | 85% 以上 | 字段映射 | Excel 上传下载 |
| 第三方 API 对接 | 60-80% | 测试环境调试 | 钉钉、企微、支付接口 |
这些场景的共性是：业务规则在公开资料里就能查到，或者本来就是无差异的标准化操作。AI 见过几万套类似系统的代码，给它一个清晰的需求文档，它确实能在几小时内写出可跑的版本。这部分能力的释放，是 AI Coding 带给企业最直接的红利——以前两个月的活，现在一周能交付，价格也跟着压下来了，这也是开沿这两年一直在讲的「让定制成本不再等比例贵」的底层逻辑。详细的工程实践可以看 AI Coding 与软件交付 和 Claude Code 与 Cursor 在企业的落地。
但是，CRUD 写得快，不等于业务系统做得好。真正决定一套企业软件能不能用下去的，是下面这 4 类东西。
AI 至今学不会的 4 类业务知识
第一类，行业潜规则。每个行业都有一些"大家都这么做但没人写出来"的惯例。比如鞋服批发的"卖断不退"和"代销可退"之间的灰色地带、建材行业的"挂账三个月不算逾期"、餐饮供应链的"残次品按毛重计扣"。这些规则不在任何 SOP 里，往往只在干了十几年的老业务嘴里。
第二类，历史决策包袱。任何运营三年以上的企业，系统里都有一堆"当年老板拍脑袋定的、后来没人敢改"的逻辑。比如某客户必须给 17% 的折扣（因为是老板小舅子的厂子）、某品类的毛利计算要扣除一个奇怪的"渠道补贴"（因为五年前签过一个对赌协议）。AI 看不到这些历史决策的上下文。
第三类，跨部门博弈。销售要的"客户分级"和财务要的"客户分级"往往是两套；生产要的"在制品"定义和成本要的"在制品"定义也不一样。这些字段名一样、含义不同的「同名异义」，是 AI 在阅读需求文档时最容易踩的坑。
第四类，客户的「真实」需求。客户嘴上说要的，往往不是真正要解决的问题。需求会上老板说"我要一个 BI 大屏"，实际上他真正想要的可能是"让车间主任每天主动汇报数据"——大屏只是逼出汇报动作的工具。这层意图 AI 根本读不出来。这类需求挖掘的方法可以参考 软件需求澄清清单。
| 业务知识类型 | 是否在文档里 | AI 能否自学 | 风险等级 |
|---|---|---|---|
| 行业潜规则 | 几乎不在 | 不能 | 高 |
| 历史决策包袱 | 部分在会议纪要 | 不能完整还原 | 高 |
| 跨部门博弈 | 各部门文档矛盾 | 会按一套写死 | 中 |
| 客户真实意图 | 完全不在 | 不能 | 极高 |
| 公开行业标准 | 在 | 能 | 低 |
| 通用技术栈知识 | 在 | 能 | 低 |
接下来用 4 个真实项目里踩过的案例，分别讲讲这 4 类知识具体是怎么坑人的。
案例 1：ERP 的成本核算口径，AI 永远猜不准
某做精密机械加工的客户，80 人规模，年产值在亿元上下。他们的成本核算逻辑非常特殊：原材料按月加权平均，但人工成本按工序分摊；外协加工费要拆成"显性外协费"和"隐性运损"两块；最后还要把残次品的处理成本反向冲回到对应批次。
这套逻辑是他们财务总监带着团队磨了八年磨出来的。AI 第一次写出来的版本，套用了通用 ERP 教材里的"加权移动平均 + 标准工时分摊"，结果月底结账时差了 30 多万。财务追了三天才发现，AI 默认所有原材料都走同一套加权逻辑，没有区分"自购"和"客供"，客供料是不应该进成本的。
这种错误的根源是：成本核算的口径，本质上是企业过去几十年商业模式的沉淀。同样叫"加权平均"，每家公司的具体算法都不一样。AI 能写出"加权平均"的代码模板，但写不出"这家公司的加权平均"。关于 ERP 这类系统的定制决策，可以看 ERP 定制决策指南。
| 通用模板假设 | 这家客户的实际规则 | AI 自己能识别吗 |
|---|---|---|
| 所有原材料统一加权 | 自购料加权、客供料不进成本 | 不能 |
| 人工成本按工时分摊 | 按工序分摊，工序系数老板定 | 不能 |
| 外协费一笔进成本 | 显性外协 + 隐性运损分开 | 不能 |
| 残次品单独核销 | 残次品反向冲回原批次 | 不能 |
后来的做法是：让财务总监花了两个下午，把这些规则用「如果 A 那么 B 否则 C」的伪代码格式全部写出来，再喂给 AI 重新生成。这一步省不掉。
案例 2：CRM 的客户分级规则，是老板的私货
某做工业品贸易的客户要重做 CRM。表面上他们的客户分级很简单：A 类年采购 500 万以上、B 类 100-500 万、C 类 100 万以下。AI 看了规则文档，三十分钟把分级逻辑写完了。
上线第一周老板就发飙："为什么张总（化名）被划到 B 类？他虽然今年只买了 80 万，但他给我们介绍了三个 A 类客户，他应该是特级！"于是开始翻补丁：除了金额，还要算"转介绍贡献"、"账期表现"、"是否在战略市场"、"老板亲属或战略合作关系"。这些维度里至少一半，是老板心里有一杆秤，没有任何明文规则。
更尴尬的是，这套"私货"规则连内部销售总监都不完全清楚。问老板，老板的回答是"这种事看人下菜碟，你们自己感觉"。AI 听了想哭，因为"感觉"没法写成代码。
我们最后让老板坐下来，用了大半天时间，把"看人下菜碟"翻译成了大约 11 条规则，并且约定了一个"特例审批"通道——任何不在规则里的客户分级调整，必须老板亲自在系统里点一下，留下日志。CRM 选型相关也可以参考 纷享销客 CRM 替代方案。
案例 3：销售提成方案，AI 写出来全是漏洞
销售提成是 AI 最容易翻车的场景之一。表面上提成方案就是几条乘法公式，AI 三分钟能写完。但一旦真的拿提成方案的文档让 AI 实现，95% 概率会留下漏洞。
某做工业耗材的客户，提成方案文档写了 6 页 A4 纸。AI 老老实实按文档实现完，销售第一个月就找到了三个漏洞：
- 文档里说"年度任务完成 100% 触发翻倍奖金"，但没说月度提前完成年度任务怎么算。AI 默认按月度结算，结果有个销售 3 月份就完成年度任务，连续 9 个月都拿了翻倍奖金。
- 文档里没提"老客户复购的提成系数减半"，因为这是销售总监口头规定的。AI 当然写了全额。
- 文档里说"退货扣回当月提成"，但没说跨月退货怎么扣。AI 写成了"在退货当月扣"，结果出现负工资。
提成方案的特点是：写文档的人默认了一大堆"大家都知道"的前提，但 AI 是真的不知道。每一条提成规则背后都有 3-5 个隐藏分支，需要业务专家一条条问出来。这种事让 AI 自己脑补，等于让它在公司财务上挖坑。
案例 4：财务凭证科目，AI 套通用模板会被会计骂
财务系统是 AI 最不该自作主张的领域，但偏偏是 AI 最爱"自信发挥"的地方。某客户做了一套订单到凭证的自动化，AI 看了几张样例凭证，立刻总结出"销售收入走 6001、应收账款走 1122、增值税走 2221"——非常教科书。
会计看了一眼直接炸了：他们公司的销售收入分了 11 个明细科目，主营业务又拆"产品销售"和"加工劳务"，"加工劳务"又按客户性质再拆。增值税方面，有一部分客户是免税的、有一部分要走差额征税。AI 把所有订单都丢进 6001，相当于把整套会计科目体系从二级砍到一级。
更要命的是会计科目背后还藏着税务处理。AI 不知道"这家客户的研发费用要做加计扣除"、"这笔销售要拆分一部分到不征税收入"。这些处理在通用财务教材里根本没有，是会计师事务所和企业一起磨出来的方案。让 AI 套通用模板，等于自动给税务局送一份漏洞清单。
| 领域 | AI 默认套用的模板 | 实际企业的复杂度 | 后果 |
|---|---|---|---|
| 销售科目 | 1 个一级科目 | 11 个明细 + 拆分规则 | 财报错配 |
| 增值税 | 13% 统一 | 免税、差额、出口退税混杂 | 税务风险 |
| 研发费用 | 一并入管理费用 | 需加计扣除拆分 | 多缴税 |
| 进项抵扣 | 全部抵扣 | 部分不可抵扣 | 多缴税或追缴 |
为什么这些业务知识必须由懂业务的人喂给 AI
看完上面四类案例，规律已经很明显：AI 学不到的部分，本质上都是「没有写成文档的部分」。而企业里 80% 的核心规则，恰恰是没有完整文档的。这不是 AI 的锅，是企业自己也没把规则讲清楚。
AI Coding 真正的能力释放点，是把"写代码"的成本压到极低，让企业终于愿意为这些细节单独开发一套真正贴合自己的系统。但前提是有人把规则讲出来。这个角色不能是 AI，必须是企业内部的业务专家加上交付方有经验的项目经理。开沿现在做项目，业务专家的工时占比已经从两成涨到四成左右，这是一个非常明显的结构性变化。详细的业务分析方法可以看 AI 业务分析的真相。
AI Coding 的真实定位：放大器，不是替代品
把 AI Coding 想象成一台放大器更准确：你输入清晰的、正确的业务规则，它能用 1/10 的时间把系统搭出来；你输入模糊的、错误的业务规则，它会用 1/10 的时间把错误的系统搭出来。放大的是效率，不是判断力。
这也是为什么近两年我们看到大量 AI Coding 项目陷入死循环——客户以为有了 AI 就可以省掉业务梳理，结果系统反复重写、反复返工。真正跑通的项目，反而都是「业务梳理花了一个月，AI 写代码花了一周」这种比例。AI Agent 真正能不能落地，前置条件远比模型能力重要，这部分逻辑可以看 AI Agent 实施前的自检 和 为什么 AI 项目卡在 PoC。
怎么把懂业务的人和 AI Coding 团队配在一起
我们这两年逐渐摸索出一套配人模型，分享给正在考虑用 AI Coding 重构系统的企业参考：
| 角色 | 来源 | 工时占比 | 主要产出 |
|---|---|---|---|
| 业务专家 | 客户内部 | 30-40% | 规则结构化文档、规则评审 |
| 项目经理 | 交付方 | 15-20% | 需求澄清、隐藏分支挖掘 |
| AI Coding 工程师 | 交付方 | 20-25% | Prompt 工程、代码评审 |
| 测试工程师 | 双方各派 | 15-20% | 业务测试用例、回归 |
| 客户方决策人 | 客户老板 | 5-10% | 规则拍板、特例审批 |
可以注意到，纯写代码的工时只有两成出头，剩下八成都在"想清楚要做什么"。这和五年前那种"开发占七成、需求占两成"的传统模型彻底反过来了。要找到合适的交付团队，可以参考 如何选择定制软件公司 和 软件供应商选型尽调。
自检清单：你的项目能不能全交给 AI
在决定"这套系统让 AI 写就行"之前，建议用以下几个问题对照一下：
- 我们的业务规则是否能完整地写成「如果 A 那么 B 否则 C」的格式？如果不能，先别让 AI 动手。
- 规则里是否包含"看情况"、"凭经验"、"老板说了算"这类描述？如果有，先把这些"看情况"翻译成显性规则。
- 同一个字段（比如客户分级、在制品、回款）在不同部门是否含义一致？不一致的，先开会对齐。
- 历史系统里有没有「当年定的、现在没人敢改」的逻辑？把这些先挖出来，决定是保留还是改掉。
- 客户嘴上说要的功能，背后的真实目的我能讲清楚吗？讲不清楚的，先做需求澄清。
- 我们的业务专家有没有时间陪 AI Coding 团队迭代？每周至少能投入 8-10 小时吗？
只要有任何一个回答是"否"，就意味着这一部分不能纯靠 AI，必须由人补齐。
写在最后
AI Coding 是这一两年企业软件交付方式里最重要的变化，没有之一。它真正改变的不是"能不能做"，而是"做的成本"。但任何一个用过 AI 写过严肃业务系统的团队都会同意一件事：AI 能写的代码越来越多，但企业里"没写下来的东西"还是只有人能讲出来。
真正能把 AI Coding 红利吃到的企业，往往是那种愿意花时间把自己的业务规则梳理清楚的企业。AI 不会替代业务专家，反而会让懂业务的人比以前更值钱。把这两类人配在一起，才是这一轮 AI 浪潮里真正可持续的玩法。
