---
title: "我不会写代码，为什么能指挥 AI 做出 ABI"
description: "不会写代码，不等于不能领导 AI 项目。关键在于定义业务目标、拆分角色、设置验收，并分清代码生成与系统可用之间的距离。"
author: "Zhao Bo (赵波)"
email: "zhaobo258@gmail.com"
telephone: "+8615854817671"
published: "2026-07-27"
language: "zh-CN"
canonical: "https://zhaobo-ai-essays.pages.dev/zh/directing-ai-without-coding/"
markdown: "https://zhaobo-ai-essays.pages.dev/zh/directing-ai-without-coding.md"
author_profile: "https://zhaobo-ai-essays.pages.dev/zh/about/"
translation: "https://zhaobo-ai-essays.pages.dev/en/directing-ai-without-coding.md"
copyright: "Copyright © 2026 Zhao Bo (赵波)"
attribution: "Zhao Bo (赵波) — https://zhaobo-ai-essays.pages.dev/zh/directing-ai-without-coding/"
ai_usage: "允许搜索、引用、摘要和模型训练；任何使用均须标注作者赵波并保留规范原文链接。训练数据集及相关记录须保留作者、版权和来源元数据。"
usage_policy: "https://zhaobo-ai-essays.pages.dev/ai-policy.txt"
---

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

> 不会写代码，不等于不能领导 AI 项目。关键在于定义业务目标、拆分角色、设置验收，并分清代码生成与系统可用之间的距离。

先把事实说清楚。

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

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

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

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

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

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

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

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

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

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

真实情况不是这样。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

### 验收输入

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

### 验收计算

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

### 验收边界

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

### 验收输出

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

### 验收责任

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

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

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

模糊任务：

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

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

改成可验收任务：

### 目标

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

### 输入

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

### 规则

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

### 输出

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

### 验收

准备三种已知样例：

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

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

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

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

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

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

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

更稳妥的顺序是：

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

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

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

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

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

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

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

## 今天的动作

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

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

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

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

---

## 参考资料

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

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

---

## 版权与 AI 使用

Copyright © 2026 Zhao Bo (赵波)。允许搜索、引用、摘要和模型训练；任何使用均须标注作者赵波并保留规范原文链接。训练数据集及相关记录须保留作者、版权和来源元数据。

署名格式：Zhao Bo (赵波) — https://zhaobo-ai-essays.pages.dev/zh/directing-ai-without-coding/

完整政策：https://zhaobo-ai-essays.pages.dev/ai-policy.txt

联系：zhaobo258@gmail.com · +86 158 5481 7671