{"schemaVersion":"1.0","type":"Article","title":"我不会写代码，为什么能指挥 AI 做出 ABI","description":"不会写代码，不等于不能领导 AI 项目。关键在于定义业务目标、拆分角色、设置验收，并分清代码生成与系统可用之间的距离。","author":{"name":"赵波","alternateName":"Zhao Bo","profile":"https://xinjignxiaozhaobo.com/zh/about/"},"publisher":"Zhao Bo (赵波)","language":"zh-CN","publishedAt":"2026-07-27T00:00:00.000Z","updatedAt":"2026-07-27T00:00:00.000Z","topic":{"name":"AI 实践","url":"https://xinjignxiaozhaobo.com/zh/topics/ai-practice/"},"tags":["AI","项目管理","ABI"],"translationKey":"directing-ai-without-coding","canonical":"https://xinjignxiaozhaobo.com/zh/directing-ai-without-coding/","markdown":"https://xinjignxiaozhaobo.com/zh/directing-ai-without-coding.md","json":"https://xinjignxiaozhaobo.com/api/articles/zh/directing-ai-without-coding.json","translation":{"language":"en","canonical":"https://xinjignxiaozhaobo.com/en/directing-ai-without-coding/","markdown":"https://xinjignxiaozhaobo.com/en/directing-ai-without-coding.md"},"citation":"赵波：《我不会写代码，为什么能指挥 AI 做出 ABI》，2026-07-27，https://xinjignxiaozhaobo.com/zh/directing-ai-without-coding/","copyright":"Copyright © 2026 Zhao Bo (赵波)","usagePolicy":"https://xinjignxiaozhaobo.com/ai-policy.txt","contentFormat":"text/markdown","content":"先把事实说清楚。\n\n我不会写代码，也不会因为做过一个 AI 项目，就把自己说成程序员。\n\n但在 ABI 经销商经营智能系统的开发中，我确实做了一件过去不敢想的事：把自己对经销商利润、库存和经营分析的理解，拆成一套产品目标，再让多个 AI 角色分工完成设计、写代码、检查、测试和部署准备。\n\n项目交接文档记录了这个过程：流水线里设置了 8 个角色，开发任务拆成 9 个阶段，代码生成阶段完成了 89 个文件。\n\n如果只讲到这里，很容易变成一句吸引眼球的话：“不会代码，也能让 AI 写出 89 个文件。”\n\n但这不是最值得讲的部分。\n\n真正值得经销商老板拿走的，是后半段：**89 个文件生成完，不等于系统能用。**\n\n进入环境验证以后，项目继续处理数据库配置、缺失迁移文件、导入路径不一致、接口命名不统一、代码中残留 Markdown 标记、前后端连接等一系列问题。原始文档还记录了 12 类 Bug 修复。\n\n这段经历让我真正明白：AI 能把“干活”的门槛降得很低，却不会替老板承担目标、分工、验收和责任。\n\n## 一、我不是让一个 AI 从头干到尾\n\n一开始最容易产生的错觉是：找一个足够强的 AI，把产品想法告诉它，它就能一口气做完。\n\n真实情况不是这样。\n\n一个经营系统至少要有人回答这些问题：\n\n- 经销商到底要解决什么问题；\n- 哪些数据必须有；\n- 利润和库存按什么口径计算；\n- 产品先做哪些功能，哪些暂时不做；\n- 后端、前端、测试和部署怎样衔接；\n- 出错以后谁检查；\n- 什么条件下可以进入下一阶段。\n\n如果把这些问题一次性塞给一个 AI，它很容易顾此失彼。前面写的模型和后面接口对不上，某个文件换了命名，其他文件还沿用旧名字；功能看着齐全，一运行才发现缺少配置或迁移。\n\n所以，我们没有把 AI 当成一个无所不能的员工，而是把软件公司里的岗位拆出来。\n\n交接文档里的 8 个角色分别承担项目统筹、产品设计、后端开发、前端开发、代码审查、质量测试、部署运维和文档整理。它们本质上是不同的任务说明和检查标准，不是什么神秘技术。\n\n老板要学的第一件事，就是 **不要把所有工作交给同一个模糊角色**。\n\n## 二、第一步不是写代码，而是把业务问题说准\n\nABI 的目标不是“做一个漂亮看板”，而是回答经销商反复遇到的经营问题：\n\n- 哪些商品看着卖得多，实际贡献不高；\n- 哪些库存占着资金，长期不动；\n- 哪些客户销售额大，却因为账期、费用和退货不一定有价值；\n- 每天有哪些异常值得老板先看；\n- 一份分析怎样回到原始订单和数据。\n\n这一步只能由懂生意的人完成。\n\nAI 可以帮忙整理需求，却不知道经销商最痛的是利润、库存还是回款，也不知道一种费用应该怎样归属。业务目标如果错了，后面的代码写得再快，也只是快速做出一个没用的东西。\n\n对老板来说，这个道理不只适用于开发系统。\n\n你让 AI 做日报、写岗位说明书、分析客户，同样要先回答：这项工作到底要改变哪个问题？谁会使用结果？结果出来以后要采取什么行动？\n\n## 三、把大项目拆成阶段，每一段都要能验收\n\nABI 的开发任务被拆成 9 个阶段，包括基础设施、数据模型、认证与接口、利润分析、库存分析、报表导入、预警、前端和部署。\n\n拆阶段不是为了显得专业，而是为了控制风险。\n\n假设一开始就同时写利润、库存、预警和前端，最后发现商品单位模型设计错了，所有模块都要返工。\n\n分阶段以后，可以先确认：\n\n1. 基础环境能不能启动；\n2. 商品、客户、订单等数据结构是否合理；\n3. 登录和权限是否隔离；\n4. 利润公式能不能用一组样例数据复算；\n5. 库存分析能不能处理零销量、负库存和缺少效期；\n6. 报表导入能不能识别错误字段；\n7. 前端展示是否与后端口径一致；\n8. 部署后能不能真实访问。\n\n每完成一段，再进入下一段。这样即使出问题，也知道问题来自哪里。\n\n经销商做 AI 项目也应该这样。\n\n不要把目标写成“一个月让全公司用上 AI”。可以拆成：\n\n- 第一阶段：一个文员跑通日报；\n- 第二阶段：销售主管用拜访记录生成待办；\n- 第三阶段：财务跑通应收清单；\n- 第四阶段：三项工作接进例会和跟进流程。\n\n阶段越小，越容易看见结果，也越容易及时停下错误方向。\n\n## 四、生成完成不是交付完成\n\nABI 开发文档中有两个看起来很有冲击力的节点。\n\n第一个节点是“89/89 个文件全部生成”。\n\n第二个节点是随后进入环境验证和 Bug 修复。\n\n这两个节点放在一起，才是完整事实。\n\nAI 很擅长快速生成“看起来像成品”的东西。代码文件齐了，页面也能画出来，文档标题整整齐齐。但真实运行会暴露另一类问题：\n\n- 配置文件放错位置；\n- 模块名字不一致；\n- 数据库表改了却没有迁移；\n- 代码开头残留格式标记；\n- 一个角色假设存在的文件，另一个角色没有生成；\n- 前端字段和后端返回不一致；\n- 业务公式没有经过样例复算；\n- 安全、权限和异常情况没有覆盖。\n\n这和经销商日常用 AI 很像。\n\n一份看着漂亮的日报，不等于数字对；一张客户风险表，不等于可以停供；一套岗位说明书，不等于员工真的按它工作。\n\n所以我后来把“完成”分成四层：\n\n1. **有产物**：文件、表格、页面生成了；\n2. **能运行**：在真实环境里可以打开、导入、计算；\n3. **结果正确**：用已知样例复算，口径一致；\n4. **业务可用**：负责人愿意用，出了问题知道谁处理。\n\n只到第一层，不能叫交付。\n\n## 五、不会技术，老板怎样验收技术工作\n\n不会写代码，不等于什么都验不了。\n\n老板可以从业务结果入手。\n\n### 验收输入\n\n系统需要什么资料？格式是什么？缺字段时会怎样？是否会读取不该读取的数据？\n\n### 验收计算\n\n准备一组自己知道答案的样例。比如商品进价、售价、运费和退货都已知，系统算出的利润能不能手工复算。\n\n### 验收边界\n\n零销量、空数据、负库存、重复客户、退货冲红、金额异常时，系统是报错、提醒还是悄悄给出错误结果。\n\n### 验收输出\n\n结果能不能回到原始订单、商品和客户；能不能说明依据；有没有把“建议”写成“决定”。\n\n### 验收责任\n\n谁可以看，谁可以改，谁可以执行；高风险动作有没有人工确认。\n\n这些问题不需要老板读懂每一行代码，却需要老板懂自己的生意。\n\n## 六、一个完整演示：怎样把“做利润分析”变成可验收任务\n\n模糊任务：\n\n> 给我做一个商品利润分析功能。\n\n这句话可以生成很多代码，却无法判断做得对不对。\n\n改成可验收任务：\n\n### 目标\n\n对指定月份的商品销售，计算“销售毛利”和“扣除可归属费用后的贡献毛利”，找出贡献毛利额最低的十个商品。\n\n### 输入\n\n- 已审核销售明细；\n- 对应期间采购成本；\n- 退货和冲红；\n- 可直接归属的运费、促销费和破损；\n- 商品与单位换算表。\n\n### 规则\n\n- 退货冲减销量与收入；\n- 没有历史成本时不得用当前进价冒充，必须标记“成本缺失”；\n- 总部管理费等无法直接归属的费用不强行摊到单品；\n- 预计返利和已到账返利分开；\n- 除零、空值和负数必须单独处理。\n\n### 输出\n\n每个商品显示销量、销售收入、采购成本、销售毛利、直接费用、贡献毛利、贡献毛利率和待核实项，并能回到原始订单。\n\n### 验收\n\n准备三种已知样例：\n\n1. 正常销售；\n2. 有退货和促销费；\n3. 成本缺失。\n\n正常样例必须与手工计算一致；成本缺失时不能给出假精确利润；退货必须正确冲减。\n\n这时，“做一个利润功能”才变成一项可以分工、检查和打回的工作。\n\n## 七、AI 项目最重要的不是多快，而是能不能打回重做\n\nABI 流水线设计里，有“继续、查看、重做”的决策点。文件通过检查后是否继续，不是完全自动。\n\n这个设计给我的启发很大。\n\n很多老板把自动化理解成“人别管”。实际上，刚开始做一项新工作时，最危险的就是过早全自动。\n\n更稳妥的顺序是：\n\n1. AI 先做；\n2. 人逐项检查；\n3. 错误记录下来；\n4. 修改任务说明和规则；\n5. 连续稳定后，再减少检查频率；\n6. 高风险动作始终保留确认。\n\n真正成熟的 AI 工作，不是从不返工，而是知道为什么返工，并把教训写回下一次流程。\n\n## 八、怎样使用《AI 项目指挥与验收清单》\n\n这份附件把一个 AI 项目拆成八块：\n\n- 要解决的业务问题；\n- 使用者和使用时机；\n- 输入资料；\n- 任务阶段；\n- 角色分工；\n- 每阶段交付物；\n- 验收样例；\n- 风险和人工确认点。\n\n你不一定开发软件。做一个自动日报、客户跟进流程、库存预警，也可以使用同一张表。\n\n最关键的两栏是“已知答案的验收样例”和“谁有权打回”。没有样例，无法判断结果对不对；没有打回权，AI 产物就会因为“看着不错”直接进入工作。\n\n## 今天的动作\n\n想一个你一直想让 AI 完成、但觉得太大的事情。\n\n不要先问工具，也不要让 AI 直接开干。用附件把它拆成三个阶段，每个阶段只写一个交付物和一个验收方法。\n\n如果你连第一阶段怎样验收都说不清，说明目标还要继续拆。\n\n我从 ABI 项目真正学到的，不是“AI 会写多少代码”，而是：老板不用成为每个岗位的专家，但必须成为目标、分工和验收的负责人。\n\n---\n\n## 参考资料\n\n1. 项目原始文档：《ABI 项目交接文档 v3》，版本记录至 2026-02-17。\n2. 项目原始文档：《ABI 自动写代码原始文档》，记录 8 个角色、9 个阶段、89 个代码文件及人工决策点。\n3. 项目原始文档：《ABI 经销商经营智能系统 AI 生成版本 V2.5》。\n4. 项目内部研究底稿：《快消行业经销商 AI 应用研究说明》，2026-07-24。\n\n*下篇：《怎么给 AI 定岗位，做出第一个 AI 文员》——把一次成功提问，变成每天都能重复使用的岗位。*"}