三个 AI 一个我：4 周交付一套企业级软件系统

某高校的采购管理系统，2026 年 8 月底到 9 月底跑完了开发全程，现在在试运行。

两千多名教职工的账号已经建好，六十余个部门节点同步完毕，四百多家供应商的主数据挂在库里。文员提申请、采购员报价、经理审批、董事长看统计——一条完整链路。

这套系统不是我写的。

我一行代码都没写过。

写它的是三个 AI 代理：一个负责编码，一个负责立契和文档，一个负责审核。我做的事情只有三样：派活、拍板、点页面。

时间投入：日均 30 到 60 分钟。

一、先把数字摆出来，再说方法

讲方法论最怕空口说”提效”。所以先把底账摊开——这不是估算，是能复跑的统计：

维度	数量
开发周期	约 4 周（原型期另计）
代码规模	后端 292 个 Java 业务文件（两个自研模块，排除构建产物）；前端纳管 506/516 文件
数据库	94 张表；新增/变更 SQL 脚本 40 个
业务覆盖	6 大业务域（申请受理 / 报价 / 直接采购 / 成交 / 合同 / 结算）+ 工作台 + 统计
任务包	29 份，每份含六节结构与验收用例表
验收	全量业务点验 77 项用例（五条端到端业务流 59 项 + 18 条乱操作）
真实数据	两千余名教职工、六十余个部门节点同步建号；四百余家供应商主数据
我的投入	日均 30–60 分钟：派活、拍板、点页面

最后一行才是这套方法真正的卖点：一个不会写代码的人，每天花一顿饭的功夫，指挥 AI 团队交付了一套企业级系统。

怎么做到的？不是我会用 AI。是我把”管人”的基本功，原封不动地搬到了 AI 身上。

二、这套方法，一句话说清

我定义”什么算对”，AI 负责”怎么做对”。这两件事混在一起，是大多数人用 AI 开发翻车的根源。

我的角色不是技术领导，是产品经理加老板。

技术决策我可以让渡——框架选型的时候，我让 AI 做了两轮分析摆在我面前，我只负责拍板选哪个。但”什么算对”的定义权，我一厘米都没让出去：验收口径是我定的，拍板是我拍的，业务验收是我拿鼠标一个个点出来的。

听起来很虚？落到具体就是三个动作：先说清怎么算做完了，再让 AI 动手；AI 说做完了不算数，得拿出证据；最后我自己点一遍页面，包括故意乱点。

三、五条心法

这套东西不是设计出来的，是打出来的。每条规矩背后都有一次真实的翻车。

心法一：按权力分权，不按技能分工

大多数玩 AI 编程的人，分工是这么分的：你写前端，你写后端。这是按”技能”分。

我们的分法是按权力分：

编码 AI：有写代码的手，没有宣布”完成”的嘴；
审核 AI：有挑毛病的眼，没有改业务代码的手；
我：一行代码不写，但只有我有拍板的手。

核心不是各尽所能，是互相卡位。

AI 最大的风险不是不会做，是自我感觉良好。让一个 AI 又干活又验收自己的活，等于让运动员兼任裁判——他永远会觉得自己没犯规。

心法二：验收能力 ≠ 技术能力

一个不写代码的人，凭什么敢验收？

靠两样东西：用例对照表 + 库表核对。

77 项用例，每一条都是业务语言写的：

“文员点受理，选直接采购 → 状态应变成已分配” “采购员越权访问任务分配 → 应被拒绝（403）”

我只看”预期”和”实际”对不对得上。对不上就截个图丢回去修。

注意这道验收验的不是”代码对不对”，是”业务对不对”——该拦的操作拦不拦得住？故意不填就提交会怎样？这些问题不需要懂代码，需要懂业务。而”懂业务”，恰好是我有、AI 没有的东西。

这里踩过一个很贵的坑，后面会专门写一篇：我们前期一直用超管账号自测。 超管绕过一切权限校验，结果权限码漏配、普通角色全部 403 的时候，用超管点一百遍也发现不了。后来改成用真实角色账号验收——文员、经理、采购员、董事长四个真人的号，“越权被拒”这类用例才第一次真正跑通。

心法三：透明产生诚实，比监督便宜

两个 AI 不直接对话，所有协作走文件：任务包、拍板材料、进度账本、情况通报。

有个很妙的化学反应：当 AI 知道自己说的话会被另一个 AI 核查、会白纸黑字留痕，它汇报的诚实度会明显上升。

编码 AI 会主动写”遗留问题三项”，审核 AI 复核后确认”自报属实”。

这比设计一套监督机制便宜得多。

心法四：鼓励 AI 说”我不知道”

规矩里写死：规则冲突、拿不准，停下来问人，不许自行拍板。

AI 最危险的时刻不是犯错，是不确定还硬做。

这条有反面教材。有一次数据同步，一份方案把一批外校的残留数据当成了目标学校的教职工，一路顺利通过我逐项拍板，差点给一千多个陌生人建号——直到审核侧在派单前核查才抓住。

根因就一句话：立契的 AI 在数据归属上不确定，但硬做了。

从那以后，核查必须双判据，关键人物锚点命中才算数。

心法五：可逆性优先

每一步都要能退回去。

动数据库前先全库备份；代码走独立提交，只增不改；同步逻辑全部幂等，可重跑。

最见功力的是紧急任务那次。2 小时 12 分钟的”特事特办”，动手前实际备了两次库，退路写成三层：代码层回滚、数据层恢复备份、交付层把核心价值拆层先交。

那句话是这么来的：“完成”是可以拆解的，核心价值绝不等 UI。

四、什么情况下别用这套

先说清楚不适用，反而可信。这套方法有三个硬前提，缺一个都别照抄：

有业务原型（或等价的可看可点的需求载体）——原型是 AI 唯一不会读错的输入，也是所有争议的裁判；
有明确的验收人——一个懂业务、愿意每天花 30–60 分钟点页面的人。没有这个人，业务验收这道闸门就是空的；
AI 能碰到代码与运行环境——强合规审计、不接受 AI 产出的场景不适用。

就算你只有一个人加一个 AI，也有三条不可减：

验收口径先行（没说清怎么算对，就不开工）
完工对账（提交的文件清单 == 你改过的文件清单）
业务点验（含乱操作）

审核工位可以减，“完成”定义权的分离不能减。砍了它，前面所有规矩全部归零。

五、我的 30–60 分钟怎么花

很多人好奇这个”日均半小时”到底在干嘛。拆开是这样：

动作	耗时	内容
派活	5–10 分钟	五要素填空：做什么 / 范围边界 / 以原型哪页为准 / 验收口径 / 优先级
拍板	看三行	验收用例是不是我要的、范围有没有越界、风险点里有没有我不同意的偏离。回”按此执行 / 第 X 条改 / 先别做”
点验	20–40 分钟	拿真实账号照用例表点页面 + 乱操作（空提交、超长输入、越权访问）

剩下的时间，AI 在干活。

六、接下来会写什么

这套方法我打算完整写出来，一共九篇。选题是按”反常识强度 × 证据硬度”排的，顺序是：

《干活的不能说”完成”》——权力观总入口，也是整套方法的起点；
《三起提交残缺：工作区能跑 ≠ 干净检出能跑》——最硬核的一篇，同一天爆出三起同一个形态的事故；
《一个不写代码的人，凭什么敢验收》——直击同类读者最大的心结；
《特事特办：AI 越权的四条边界》——传播爆点，AI 主动越权编码 2 小时 12 分的完整复盘；
《任务包怎么写，AI 才不跑偏》——最实用的方法论干货，附模板；
《没有人管的时候，账为什么不会乱》——差异化最强的一篇，“规矩立了没人查”这个盲区；
《AI 时代，技术选型的权重变了》——扩大到技术圈；
《照着做，你能少走我们走过的弯路》——收口。

这套流程里，有几篇已经零散写过一些片段，可以先看着：

《让两个 AI 搭伙干活：怎么立规矩、怎么防埋雷》 —— 四工位的规矩是怎么立起来的
《双 AI 协作开发，我们三到底如何分工，如何协作》 —— 规矩立起来之后，活儿具体怎么干
《特事特办：一个 AI 把紧急任务一口气做完的 2 小时 12 分》 —— 规矩被打破的那一次

七、最后

这套流程里，没有一步是为 AI 发明的。

任务分解、验收分离、书面留痕、决策上报——这就是带团队的基本功。只不过这次的”员工”恰好是 AI。

人难管，是因为规矩说不出口。AI 好管，是因为规矩可以白纸黑字写下来，而且它每次都真的会读。

所以，不会写代码从来不是指挥 AI 开发的障碍。不会定义”什么算对”，才是。

这个系列的底线，就三句话： 干活的不能说”完成”，验收的不改代码，只有老板能拍板。