我不会写代码，为什么能指挥 AI 做出 ABI

先把事实说清楚。

我不会写代码，也不会因为做过一个 AI 项目，就把自己说成程序员。

但在 ABI 经销商经营智能系统的开发中，我确实做了一件过去不敢想的事：把自己对经销商利润、库存和经营分析的理解，拆成一套产品目标，再让多个 AI 角色分工完成设计、写代码、检查、测试和部署准备。

项目交接文档记录了这个过程：流水线里设置了 8 个角色，开发任务拆成 9 个阶段，代码生成阶段完成了 89 个文件。

如果只讲到这里，很容易变成一句吸引眼球的话：“不会代码，也能让 AI 写出 89 个文件。”

但这不是最值得讲的部分。

真正值得经销商老板拿走的，是后半段：89 个文件生成完，不等于系统能用。

进入环境验证以后，项目继续处理数据库配置、缺失迁移文件、导入路径不一致、接口命名不统一、代码中残留 Markdown 标记、前后端连接等一系列问题。原始文档还记录了 12 类 Bug 修复。

这段经历让我真正明白：AI 能把“干活”的门槛降得很低，却不会替老板承担目标、分工、验收和责任。

一、我不是让一个 AI 从头干到尾

一开始最容易产生的错觉是：找一个足够强的 AI，把产品想法告诉它，它就能一口气做完。

真实情况不是这样。

一个经营系统至少要有人回答这些问题：

经销商到底要解决什么问题；
哪些数据必须有；
利润和库存按什么口径计算；
产品先做哪些功能，哪些暂时不做；
后端、前端、测试和部署怎样衔接；
出错以后谁检查；
什么条件下可以进入下一阶段。

如果把这些问题一次性塞给一个 AI，它很容易顾此失彼。前面写的模型和后面接口对不上，某个文件换了命名，其他文件还沿用旧名字；功能看着齐全，一运行才发现缺少配置或迁移。

所以，我们没有把 AI 当成一个无所不能的员工，而是把软件公司里的岗位拆出来。

交接文档里的 8 个角色分别承担项目统筹、产品设计、后端开发、前端开发、代码审查、质量测试、部署运维和文档整理。它们本质上是不同的任务说明和检查标准，不是什么神秘技术。

老板要学的第一件事，就是不要把所有工作交给同一个模糊角色。

二、第一步不是写代码，而是把业务问题说准

ABI 的目标不是“做一个漂亮看板”，而是回答经销商反复遇到的经营问题：

哪些商品看着卖得多，实际贡献不高；
哪些库存占着资金，长期不动；
哪些客户销售额大，却因为账期、费用和退货不一定有价值；
每天有哪些异常值得老板先看；
一份分析怎样回到原始订单和数据。

这一步只能由懂生意的人完成。

AI 可以帮忙整理需求，却不知道经销商最痛的是利润、库存还是回款，也不知道一种费用应该怎样归属。业务目标如果错了，后面的代码写得再快，也只是快速做出一个没用的东西。

对老板来说，这个道理不只适用于开发系统。

你让 AI 做日报、写岗位说明书、分析客户，同样要先回答：这项工作到底要改变哪个问题？谁会使用结果？结果出来以后要采取什么行动？

三、把大项目拆成阶段，每一段都要能验收

ABI 的开发任务被拆成 9 个阶段，包括基础设施、数据模型、认证与接口、利润分析、库存分析、报表导入、预警、前端和部署。

拆阶段不是为了显得专业，而是为了控制风险。

假设一开始就同时写利润、库存、预警和前端，最后发现商品单位模型设计错了，所有模块都要返工。

分阶段以后，可以先确认：

基础环境能不能启动；
商品、客户、订单等数据结构是否合理；
登录和权限是否隔离；
利润公式能不能用一组样例数据复算；
库存分析能不能处理零销量、负库存和缺少效期；
报表导入能不能识别错误字段；
前端展示是否与后端口径一致；
部署后能不能真实访问。

每完成一段，再进入下一段。这样即使出问题，也知道问题来自哪里。

经销商做 AI 项目也应该这样。

不要把目标写成“一个月让全公司用上 AI”。可以拆成：

第一阶段：一个文员跑通日报；
第二阶段：销售主管用拜访记录生成待办；
第三阶段：财务跑通应收清单；
第四阶段：三项工作接进例会和跟进流程。

阶段越小，越容易看见结果，也越容易及时停下错误方向。

四、生成完成不是交付完成

ABI 开发文档中有两个看起来很有冲击力的节点。

第一个节点是“89/89 个文件全部生成”。

第二个节点是随后进入环境验证和 Bug 修复。

这两个节点放在一起，才是完整事实。

AI 很擅长快速生成“看起来像成品”的东西。代码文件齐了，页面也能画出来，文档标题整整齐齐。但真实运行会暴露另一类问题：

配置文件放错位置；
模块名字不一致；
数据库表改了却没有迁移；
代码开头残留格式标记；
一个角色假设存在的文件，另一个角色没有生成；
前端字段和后端返回不一致；
业务公式没有经过样例复算；
安全、权限和异常情况没有覆盖。

这和经销商日常用 AI 很像。

一份看着漂亮的日报，不等于数字对；一张客户风险表，不等于可以停供；一套岗位说明书，不等于员工真的按它工作。

所以我后来把“完成”分成四层：

有产物：文件、表格、页面生成了；
能运行：在真实环境里可以打开、导入、计算；
结果正确：用已知样例复算，口径一致；
业务可用：负责人愿意用，出了问题知道谁处理。

只到第一层，不能叫交付。

五、不会技术，老板怎样验收技术工作

不会写代码，不等于什么都验不了。

老板可以从业务结果入手。

验收输入

系统需要什么资料？格式是什么？缺字段时会怎样？是否会读取不该读取的数据？

验收计算

准备一组自己知道答案的样例。比如商品进价、售价、运费和退货都已知，系统算出的利润能不能手工复算。

验收边界

零销量、空数据、负库存、重复客户、退货冲红、金额异常时，系统是报错、提醒还是悄悄给出错误结果。

验收输出

结果能不能回到原始订单、商品和客户；能不能说明依据；有没有把“建议”写成“决定”。

验收责任

谁可以看，谁可以改，谁可以执行；高风险动作有没有人工确认。

这些问题不需要老板读懂每一行代码，却需要老板懂自己的生意。

六、一个完整演示：怎样把“做利润分析”变成可验收任务

模糊任务：

给我做一个商品利润分析功能。

这句话可以生成很多代码，却无法判断做得对不对。

改成可验收任务：

目标

对指定月份的商品销售，计算“销售毛利”和“扣除可归属费用后的贡献毛利”，找出贡献毛利额最低的十个商品。

输入

已审核销售明细；
对应期间采购成本；
退货和冲红；
可直接归属的运费、促销费和破损；
商品与单位换算表。

规则

退货冲减销量与收入；
没有历史成本时不得用当前进价冒充，必须标记“成本缺失”；
总部管理费等无法直接归属的费用不强行摊到单品；
预计返利和已到账返利分开；
除零、空值和负数必须单独处理。

输出

每个商品显示销量、销售收入、采购成本、销售毛利、直接费用、贡献毛利、贡献毛利率和待核实项，并能回到原始订单。

验收

准备三种已知样例：

正常销售；
有退货和促销费；
成本缺失。

正常样例必须与手工计算一致；成本缺失时不能给出假精确利润；退货必须正确冲减。

这时，“做一个利润功能”才变成一项可以分工、检查和打回的工作。

七、AI 项目最重要的不是多快，而是能不能打回重做

ABI 流水线设计里，有“继续、查看、重做”的决策点。文件通过检查后是否继续，不是完全自动。

这个设计给我的启发很大。

很多老板把自动化理解成“人别管”。实际上，刚开始做一项新工作时，最危险的就是过早全自动。

更稳妥的顺序是：

AI 先做；
人逐项检查；
错误记录下来；
修改任务说明和规则；
连续稳定后，再减少检查频率；
高风险动作始终保留确认。

真正成熟的 AI 工作，不是从不返工，而是知道为什么返工，并把教训写回下一次流程。

八、怎样使用《AI 项目指挥与验收清单》

这份附件把一个 AI 项目拆成八块：

要解决的业务问题；
使用者和使用时机；
输入资料；
任务阶段；
角色分工；
每阶段交付物；
验收样例；
风险和人工确认点。

你不一定开发软件。做一个自动日报、客户跟进流程、库存预警，也可以使用同一张表。

最关键的两栏是“已知答案的验收样例”和“谁有权打回”。没有样例，无法判断结果对不对；没有打回权，AI 产物就会因为“看着不错”直接进入工作。

今天的动作

想一个你一直想让 AI 完成、但觉得太大的事情。

不要先问工具，也不要让 AI 直接开干。用附件把它拆成三个阶段，每个阶段只写一个交付物和一个验收方法。

如果你连第一阶段怎样验收都说不清，说明目标还要继续拆。

我从 ABI 项目真正学到的，不是“AI 会写多少代码”，而是：老板不用成为每个岗位的专家，但必须成为目标、分工和验收的负责人。

参考资料

项目原始文档：《ABI 项目交接文档 v3》，版本记录至 2026-02-17。
项目原始文档：《ABI 自动写代码原始文档》，记录 8 个角色、9 个阶段、89 个代码文件及人工决策点。
项目原始文档：《ABI 经销商经营智能系统 AI 生成版本 V2.5》。
项目内部研究底稿：《快消行业经销商 AI 应用研究说明》，2026-07-24。

下篇：《怎么给 AI 定岗位，做出第一个 AI 文员》——把一次成功提问，变成每天都能重复使用的岗位。