观察了大量第一次用 AI 做系统的案例后，有五个错误反复出现。它们都不难避免，只是发生时往往不自知。
错误一：贪大求全
表现
"既然能做，那就把客户管理、报价、订单、库存、财务、人事都做了吧。"
后果
| 后果 | 说明 |
|---|---|
| 周期拉长 | 从两周变成两个月 |
| 每一块都做不深 | 功能都有，但每个都不好用 |
| 员工难以适应 | 一次性上线太多变化 |
| 无法验证 | 不知道哪部分有效，哪部分没用 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
正确做法
第一期只做最痛的一到两个环节。比如只做"报价 + 订单"，跑通后再加库存。
判断标准：如果你要做的模块超过三个，先砍到两个。真正确定需要更多的，等第一期跑通后自然知道。
一个经验法则：第一版的功能应该是"如果只有这些，我也能用"的最小集合，而不是"如果都做好，会很完整"的理想集合。
错误二：跳过确认环节
表现
"不用给我看方案了，你直接做吧。"或者方案文档一眼没看就点确认。
后果
方案里的错误（尤其是字段定义和状态取值）会一路带到成品。等发现时，改的是系统而不是文档，成本差一个数量级。
正确做法
至少认真看方案文档的两部分：
- 字段定义：字段名和取值范围对不对
- 状态流转：状态和流转方向对不对
这两部分花 30 分钟检查，能避免 80% 的返工。
一个形象的对比：方案阶段改需求是改一张纸，生成后改需求是改一套系统。 前者的成本接近零，后者的成本按改动范围计算。
错误三：字段没定义清楚
表现
"客户信息就那些常规字段呗"——然后系统生成了一套通用字段，与你的业务对不上。
后果
| 后果 | 说明 |
|---|---|
| 关键业务信息无处可填 | 如"电镀工艺""模具编号"这类特有字段缺失 |
| 通用字段用不上 | 一堆空字段，界面混乱 |
| 后期加字段涉及结构调整 | 比一开始就想清楚成本高 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
正确做法
在描述需求时，把你业务特有的字段列出来。一个技巧：打开你现在的 Excel 表格，把列名抄一遍——那些列名就是你的字段。
判断字段是否够用的标准：能不能把你现在 Excel 里的所有列都装进去。装不进去的部分，就是要补充的字段。
错误四：忽略权限
表现
没提权限需求，系统默认所有人可见全部数据。
后果
- 业务员能看到彼此的客户和报价（引发内部矛盾）
- 成本价、利润率对所有人可见（信息泄露风险）
- 上线后再加权限，可能需要调整数据结构
正确做法
至少说明两层：
| 角色 | 可见范围 |
|---|---|
| 普通使用者 | 自己的数据 |
| 管理者 | 全部数据 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
如果涉及敏感信息（成本价、利润率、客户联系方式），明确标注谁能看。
错误五：不做备份
表现
系统上线后，从来没有备份过数据。
后果
一次误操作、一次服务器故障、一次更新失败，数据就没了。而业务数据（客户、订单、报价）是无法重建的。
正确做法
最低限度的备份策略：
| 要素 | 做法 |
|---|---|
| 频率 | 业务数据至少每日一次 |
| 份数 | 至少三份（本地一份、异地一份、云端一份） |
| 验证 | 定期做一次恢复演练 |
| 权限 | 备份文件的访问要单独控制 |
表：本表为作者依据行业公开资料整理，具体数值随企业情况而异。
一句必须记住的话：没有验证过的备份等于没有备份。很多企业"一直在备份"，直到真要恢复时才发现备份文件是空的或者损坏的。每半年做一次恢复演练，确认备份真的可用。
三个次一级但值得提的错误
六、不验收就上线
自动检查发现不了业务问题。用真实数据走一遍核心流程，这一步不能省。
七、没有并行期
系统上线立刻停用 Excel，一旦系统有问题就没有退路。建议并行一到两周。
八、没人负责
系统上线后没有明确的负责人（谁来提需求、谁来验收、谁来培训）。没有这个角色，系统会在几个月后慢慢被弃用。
“这五个错误的共同点：都是"省了小钱，花了大钱"。”— 初元AI 团队
生成完发现少了个字段，要重做吗？+
通常只需要重新描述改动，系统会定位到相关模块做增量修改。改一个字段、加一个列、调整一个流程分支，都属于低成本改动。真正成本较高的是改变整体数据结构（如从"一个客户一个联系人"改成"一个客户多个联系人"），这类改动在设计初期就应该想清楚。这也是为什么建议第一期做小范围——范围小，后期改动的代价也小。
第一次做，怎么判断功能该砍到多少？+
用一个问题判断："如果这个模块不做，我的业务跑不跑得下去？"跑得下去的，砍掉。比如做报价系统时，客户管理是必需的（不知道报给谁），而客户分析报表不是必需的（可以先手工统计）。另一个角度：先做"每天都要用"的功能，而不是"偶尔用一次"的功能——高频功能的价值更容易被感知，也更容易被验证。
系统上线后没人用，问题出在哪？+
三个常见原因。一是没有解决真实痛点（做了不痛不痒的功能），此时员工会回到原来的方式；二是操作太麻烦（录入步骤多、需要打字多），尤其是一线人员会抵触；三是没有指定负责人推动，缺少培训和持续跟进。应对策略：上线前先让一两个核心使用者参与设计和验收，让他们成为推动者；上线后头两周每天看使用数据，及时发现卡点。
本文错误清单基于作者团队观察到的常见情形，不同企业可能遇到其他问题。