2026 年 9 月的一场产品发布会上，公开分享了这样一个案例：东莞一家五金加工厂，用初元AI 花了一周时间做出了客户管理、报价管理、订单管理三套系统；同样需求的外包报价是 8 万元，实际投入不到千元。
这个案例值得拆开讲——不是因为它省钱，而是因为它展示了一种新的交付路径。
为什么能这么快
三个原因，缺一不可。
原因一：这三套系统属于成熟范式
客户管理、报价管理、订单管理，是制造业里被实现过成千上万次的业务系统。它们的核心结构高度相似：
| 系统 | 核心结构 |
|---|---|
| 客户管理 | 客户列表 + 详情 + 跟进记录 + 标签 + 权限 |
| 报价管理 | 报价单 + 产品行项 + 税率/有效期 + 导出 |
| 订单管理 | 订单 + 状态流转 + 明细 + 交付记录 |
成熟范式意味着可以复用，不需要从零设计。这是速度的第一来源。
原因二：四阶段确认避免返工
传统项目慢，很大一部分时间花在返工上。四阶段流程把"发现错误"的节点尽量前移：
| 阶段 | 确认什么 | 耗时量级 |
|---|---|---|
| 聊需求 | AI 通过问答补齐关键信息，信息不足时主动反问 | 小时级 |
| 出方案 | 输出功能清单、字段定义、页面结构、技术选型 | 小时级 |
| 定框架 | 先完成首页或核心模块，确认方向 | 小时级 |
| 自动生成 | 全量生成 + 自动化检查 | 小时级至天级 |
原因三：重复性编码被自动化
增删改查、列表筛选、导入导出、打印 PDF——这些功能在每个业务系统里都要写，且写法高度相似。这部分工作被自动化后，剩下的只有业务特异性部分。
需求该怎么描述
这是决定成败的一步。以五金加工厂的报价系统为例：
不好的描述
"我要一个报价系统。"
AI 不知道你报什么价、有哪些变量、要导出什么格式。它只能给出一个通用模板，大概率不匹配。
好的描述
"我要一个五金件的报价系统。产品是 CNC 加工件和钣金件。报价变量包括：材质（铝 6061、不锈钢 304、碳钢）、加工方式、数量（分 1–50、51–200、200 以上三档）、表面处理（阳极氧化、喷砂、无）、交期（常规 15 天、加急 7 天加收 20%）。报价单需要能导出 PDF，包含有效期和税率。业务员只能看自己的客户，主管能看全部。"
这段描述提供了：产品类型、变量清单、分档规则、输出要求、权限要求。有了这些，AI 能直接生成可用的方案文档。
四个确认节点各自要确认什么
节点一：需求确认
看什么：AI 反问的问题是否切中要害；补齐的信息是否准确。
注意：如果 AI 没有反问就出方案，通常说明它用了通用假设，要警惕。
节点二：方案确认
看什么：功能清单是否完整；字段定义是否正确（这是最容易出错的地方）；页面结构是否符合使用习惯。
特别注意字段定义：比如"客户状态"这个字段，你的业务里是"新客户/样品中/量产中/流失"还是别的分法？方案里写错了，后面全错。
节点三：框架确认
看什么：首页或核心模块的呈现方式；整体风格；关键流程的走向。
这是最后一次低成本调整的机会。
节点四：生成后验收
看什么：功能是否可用；移动端适配；数据导入是否正常；权限是否生效。
这一步必须人工做，不能跳过。
哪些环节仍需人工把关
必须诚实说明，以下环节自动化仍不能完全替代人：
| 环节 | 为什么需要人 |
|---|---|
| 业务规则的正确性 | 系统按你描述的规则运行，规则错了系统不会纠正 |
| 历史数据的清洗 | 脏数据（重复、格式混乱）需要人工整理 |
| 权限设置 | 涉及数据安全，需人工确认 |
| 上线前的验收 | 自动化检查能发现功能问题，发现不了业务问题 |
| 员工培训 | 任何系统都需要人来推动使用 |
一周是怎么分配的
一个现实的时间分配（参考）：
| 天 | 做什么 |
|---|---|
| 第 1 天 | 描述需求、需求确认、方案确认 |
| 第 2 天 | 框架确认、核心模块生成 |
| 第 3–4 天 | 全量生成、自检、人工验收 |
| 第 5 天 | 历史数据导入、权限配置 |
| 第 6–7 天 | 员工试用、调整、正式上线 |
注意第 6–7 天：试用和调整是不可压缩的。很多项目失败不是因为系统做不出来，而是因为没有留出让员工适应的时间。
这个路径的适用边界
能这么快，前提是需求属于成熟范式。以下情况不适用：
- 需要与已有 ERP、财务系统深度对接
- 业务逻辑高度特殊（如特殊的排产算法）
- 强合规要求（如医疗、金融相关）
- 高并发或特殊性能要求
遇到这些，仍需专业开发，周期会回到"月"的量级。诚实识别这一点，比套用一个不适用的方法更重要。