AI 编程协作：非程序员的原型方法论

借助 AI 编程工具，懂业务的人可以独立做出小型原型——但“能跑”和“能用”之间，隔着你必须亲自做的验收。这课讲协作流程和边界。

本课回答的业务问题：不是程序员，怎么把想法变成工具？AI 写的代码怎么验收？原型什么时候该交给专业开发？

前置课程：第 1 课（评估与验收）。

读完本课你将能够：

1. 写一份 AI 能照着做的需求清单，把一半返工消灭在动笔之前；
2. 按“小步生成”推进原型，知道“步”多大、每步怎么验、常见坑在哪；
3. 识别必须读懂的四类代码（数据、权限、删除、对外发送），并要求解释到你听懂为止；
4. 自己造含边界情况的测试数据，用最土的办法管好版本、随时能回退；
5. 判断原型何时该交给专业开发，并组织一次不丢东西的交接。

一句话定义

AI 编程协作是“你写需求、AI 写代码、你负责验收”的分工。你的核心工作不是学语法，而是：写清需求 → 让 AI 生成 → 读懂关键修改 → 亲自运行验证 → 能回退。业务理解是你的优势，验证责任是你的义务。

这句话值得拆三层。“分工”——责任边界先划清：AI 负责生成代码，你负责定义“做什么”和判定“做没做对”。代码出了错，追 AI 的责任没有意义，能追问的只有验收的人——所以验证不是可选动作，是这个分工里你签下的那份责任。“业务理解是你的优势”——AI 不缺代码知识，缺的是“付款比例没写时该算 0 还是留空”“这份文件解析失败了该停下还是跳过”。这些恰恰是你知道、它不知道的事。你写的需求清单越接近业务规则书，AI 的产出越接近能用的工具。“验证责任是你的义务”——AI 编程工具给代码时永远自信，能跑和正确是两回事，错误的代码不会自我声明。上一课的纪律在这里原样生效：AI 自述不算数。

生活化类比（建筑行业版）

你是业主代表，AI 是效率极高的施工队：你画不出施工图（代码），但交底要交得清（需求）、关键工序要看得懂（读关键代码）、验收要自己到场（运行验证）、出问题要能停工恢复（版本回退）。甩手业主遇到再好的施工队，也会拿到一栋他不懂也没验过的楼。

类比成立在哪：四层责任完全对得上——交底不清，施工队只能按自己的理解做，返工算你的；关键工序（隐蔽工程、结构节点）业主代表必须旁站，对应四类必须读懂的代码；竣工验收必须到场实测实量，对应亲自运行核对；停工令和恢复预案对应版本回退。工程人最懂的道理：质量不是施工队“态度好”给出来的，是甲方管出来的——AI 协作同理。

类比失效在哪：其一，真实施工队有资质、有合同、有责任主体，AI 工具没有——出错的责任全部落在验收方，所以验收标准要比工程上更严而不是更松。其二，施工队完工会出自检报告和竣工资料，AI 也会说“已完成、已测试”，但它的话没有证据属性——AI 自述不算数，资料要你自己验收出来。其三，工程变更要走流程、成本高，所以天然节制；AI 改代码几乎零成本，一句“再改改”就能无限迭代，反而更容易把能跑的版本改坏——所以版本纪律在 AI 协作里比工程上更要紧。其四，工程有监理这个独立第三方，原型阶段通常没有，你就是自己的监理。

本质与能力边界

第 1 步 写清需求：一份需求清单的要素

需求清单写五块，缺一块就多一轮返工（要素模板，虚构示例）：

• 输入：什么形态（Word 合同文件）、放在哪（文件夹路径）、大约多少份、命名有没有规律；
• 处理：抽哪些字段（预付款比例、进度款比例、逾期付款违约金日率、支付期限——与贯穿案例口径一致）、依据什么规则（未提及输出“未约定”；冲突条款同报两个值）；
• 输出：Excel 表格的列定义、“待人工”清单的格式、文件怎么命名；
• 错误处理：文件打不开、解析失败、字段未提及，各自该干什么——错误路径不写，AI 就会自己发明，通常发明成“填 0”；
• 验收标准：用什么样本、多少条、什么算通过（直接搬第 3 阶段第 1 课的两张表）。

这就是第 2 阶段学的提示工程，对象从“模型”换成“代码”。常见坑有三个：只写“帮我抽合同条款”八个字——AI 只能自由发挥，发挥出来的规则多半和你的业务口径对不上；不写错误处理——演示全对、上线第一天就错；不写验收标准——做完了没法判定“完成”，等于没做完的标准。经验做法：清单写完找一位同事用五分钟读一遍，他挑出的每处歧义，都是未来一次返工。

第 2 步 小步生成：“步”多大合适

一个“步”的标准：当天能亲自验证的一个功能点——做完这一步，能用一个具体输入看到一个具体输出。太小（每次只改一行）三天走不完一条街，太大（“给我做个台账系统”）坏了不知道坏在哪。付款台账的合理切法（虚构示例）：列出文件夹内合同清单 → 读单份并打印抽取结果 → 单份结果写入一行表格 → 批量处理加汇总 → 失败项进“待人工”清单 → 输出 Excel。六步，每步都有一个能亲眼看到的结果。

为什么“步”要当天可验证，工程上一说就懂：这和分层浇筑一个道理——一次浇太厚，里面有没有裂缝从外面看不出来，等拆模发现已经晚了；每层振捣密实、看过了再浇下一层。六步，就是六次振捣。

两个常见坑：一是步子之间改需求——第三步发现第一列名字要换，直接让 AI 改，它不一定记得同步前面写好的部分，漏改一半、新旧两套规则并存是这种改法的常态；正确动作是把改动写回需求清单，再让 AI 按清单改，并要求它列出这次到底改了哪些文件哪些位置。二是“顺手多要点”——这一步只要列文件名，忍不住又说“顺便把抽取也做了”，步子就白切了。

第 3 步 读懂关键修改：哪四类代码必须看懂

不用逐行读，但四类必须看懂，判别口诀就四个词：写数据的（写台账、写表格、写库——错一行，账就错）、动权限的（读写权限、密钥、账号）、删东西的（删除文件、清空表格、覆盖旧文件）、对外发送的（发邮件、调外部接口——不可逆，发出去收不回）。不在这四类里的（界面样式、内部辅助函数），可以不逐行读，但“哪些没读”要记下来，交接时说明。

看懂的标准不是能自己写，而是让 AI 用业务语言解释清楚：这段代码动了什么、写到了哪里、发给了谁、失败了会怎样——解释到你能给同事复述为止。解释后仍不懂的，这一段就不上。常见坑：AI 修 A 的时候顺手“优化”了 B，改动清单里混进没讨论过的东西——每次都要求它先列改动清单再动手；代码里出现写死的路径、写死的密码——当场要求改成配置，这既是安全问题也是“换台电脑就跑不动”的隐患。

第 4 步 亲自验证：测试数据怎么造

测试数据要自己造，且要先写预期、再跑程序——每类输入该出现什么结果，跑之前写在表里，跑完逐项对照，不是“跑通了就完”。一组够用的虚构测试数据（配合贯穿案例口径）：

• 正常 5 份：预付款 20%、进度款按月付已完工程量的 80%、违约金日率 0.03%、支付期限三十日的标准条款；
• 边界 6 份：空文件夹、0 字节文件、不是合同的 Word、全文未提及付款条款的合同、文件名超长、两个文件同名；
• 失败 2 份：扫描成图片的“假 Word”（文字层是空的）、条款里夹一句注入语句。

每类的预期行为都要写：空文件夹——程序提示“没有找到文件”并正常退出，而不是报一屏错误码；未提及——输出“未约定”进待人工清单，不是填 0；扫描件——识别出来进待人工，不是输出空结果还报“完成”。

常见坑两个：只拿自己手里最标准的那份合同反复测——最顺的样本测不出任何问题；忘了测重复运行——同一批文件跑第二遍，台账是翻倍还是跳过？跑两遍、亲眼看，这是最便宜的防重复写入检查。

第 5 步 能回退：土办法版本管理

不会用专业版本工具就用最土的办法，但必须有：每跑通一步，把整个代码文件夹复制一份存档，命名“日期＋步骤＋一句话说明”（示例命名：「0910-步骤3-单份抽取跑通」），保留最近几版，重要数据另外存放、不跟代码混在一个文件夹里。三条纪律：改坏了就整包退回上一版重来，不要在坏掉的版本上让 AI 继续修——它修自己的烂摊子经常越修越乱；让 AI 动手前先确认它是在副本上改；测试数据和代码分开存，否则回退版本时把数据一起回没了。

为什么 AI 写的代码“看着对”却会错：机制三句话

读懂三件事，验收该往哪里用力就有了方向。其一，AI 生成的是“最像答案的延续”，不是“查过规则书的答案”——它写代码靠的是从海量代码和文档里学到的规律，你的需求清单只是这次生成的输入之一，不是它会逐条核对的合同文本。其二，它“想当然”的方向有规律可循：它见过的合同文本几乎都有付款比例，所以遇到“未提及”的合同，最自然的动作是照着常见样子补一个值进去——填 0 或者填 20%，而不是报告“没写”（这正是幻觉的机制，见第 1 阶段第 5 课）。一句好记的话：它不知道你的合同里没写预付款，它只知道它见过的合同都写了。其三，上下文装不下时它会“读一半”——需求清单过长、一次塞进太多文件，它会悄悄丢内容，且不打招呼（机制见第 2 阶段第 3 课）。三条合起来就是验收的瞄准镜：专挑“它最可能想当然”和“它可能没读完”的地方造测试数据——第 4 步那份 13 份的清单，就是这么来的。

能力边界：原型停在哪里

原型 ≠ 生产系统。AI 辅助生成的代码适合验证业务价值——几十人内部用、出错可以承受的范围；交给全公司或对外之前，需要专业开发加固：安全（权限、注入防护）、性能（并发、体量）、维护性（别人能不能接手）。判断线就一句话：出错的最坏结果能不能承受——内部试错、填错了可以改，可承受；对外发错信息、错写资金数据，不可承受。

能生成界面 ≠ 业务闭环。一个漂亮的界面加一个能跑的脚本，离“数据正确、错误可处理、权限清晰”还差三层——界面只是脸面，账对不对、错了怎么办、谁能看谁不能看，都要用第 3 阶段第 1 课的验收纪律一项项补上。你读不懂的代码不要上生产——尤其是处理合同、资金、对外通信的部分，这条没有例外。敏感数据不进开发环境——原型阶段全程用虚构数据（本课程贯穿案例就是这么造的），真实数据入场要有数据治理和条款审查（见第 3 阶段第 3 课）。

实战演练：三周做出付款台账原型（周记式展开）

场景（虚构）：青柏产业园项目合约部要做一个原型——读入合同 Word 文件，抽取付款条款四要素，汇总输出 Excel。全程用虚构合同，三周，每周投入约两个半天。

第 1 周：需求与打地基。周一写需求清单（按第 1 步的五块模板）；找同事五分钟读一遍，挑出三处歧义——“未提及算什么”“补充协议和主合同冲突听谁的”“解析失败是停还是跳”——逐条写死规则才动工。周二到周四走前三小步：列文件清单、单份抽取打印、写入一行表格。本周踩的坑：AI 第一版把“未提及付款比例”直接填 0——正是第 3 阶段第 1 课案例里那个缺陷的翻版，因为用一份“未提及”的虚构合同当场验证，第一天就暴露了；修复为输出“未约定”并进待人工清单。周五做批量汇总，踩第二个坑：同一批文件跑第二遍，台账条目翻倍——加“已处理清单”再跑两遍验证通过。周末点检：存档 6 个版本。

第 2 周：扩边界。按第 4 步造 13 份虚构测试数据（5 正常 + 6 边界 + 2 失败），逐类写预期行为再跑。本周踩的坑：扫描成图片的“假 Word”抽取结果为空，程序却报“全部完成”——AI 自述不算数的活例子；处置为识别到扫描件就进待人工清单。冲突条款样本（主合同预付款 20% 对补充协议 30%）：首版只报了主合同的值、没有任何提示——改为同报两个值并标注“冲突待人工判定”。周五把 13 份样本连跑 3 遍，确认没有时对时错的样本。

第 3 周：验收与交接试用。扩样到 60 份虚构合同（40 份典型 + 12 份边界 + 8 份带注入语句），按第 3 阶段第 1 课的评分表打分——首轮字段抽取忠实 52/60，错误分析定位到“未提及被填 0”的老问题在新样本上复发，回到提示词修复后重测通过（这段验收就是第 3 阶段第 1 课那张验收单的由来）。随后交两位同事试用一周，收集反馈（虚构示例）：都说快，但希望调列顺序、加一列“所属标段”。全部通过后整理交接：需求清单最终版、测试集与预期表、已知缺陷清单、版本目录、“哪些代码没读过”的说明。

算一笔时间账（虚构示例口径）：三周合计约六个半天，其中造测试数据、逐项核对、连跑复测这些验收动作占去三个半天还多；AI 生成与修改的时间反倒零碎，调用费不到一顿饭钱。生成是即时的，验收是花时间的——这个时间分布本身就是这个分工的写照。

这个流程里最贵的不是 AI 的调用费，是你验收投入的半天——但它决定原型是玩具还是工具。

建工案例：同一个原型的两种做法（虚构）

青柏产业园项目合约部（贯穿案例设定，全部虚构）第一次尝试是甩手式协作：一位商务工程师把想法一句话丢给 AI 编程工具——“做个合同台账工具，自动抽付款条款”。三天拿到了一个界面漂亮的程序，演示会上当场抽取两份合同，全对，部门拍板试用。试用第一周出了三件事：同事丢进去一份补充协议，程序把预付款 30% 抽成了主合同的 20%——没人讲过冲突规则；一份扫描版合同抽出全空，程序照样报“完成”；有人把真实合同文件放了进去——敏感数据进了没有任何防护的开发环境。三次返工都找不到“上一版好的代码”，因为没有存档习惯。

推倒重来的做法就是实战演练那三周：需求清单、小步、边界数据、版本存档，最后按第 3 阶段第 1 课的验收单收口。两种做法用的是同一个 AI 工具、差不多的调用费，差别全在人的动作上——这正是一句话定义里那句：业务理解是你的优势，验证责任是你的义务。

供应商话术拆解

话术（内部技术方或乙方都爱说）：“这是 AI 生成的代码，肯定没问题，都测试过了。”

逐问拆解：

1. 测试用的什么数据？保留测试在哪？结果给我看。——“都测试过了”要落到样本清单和评分表上；拿不出数据的“测试过”等于没测。
2. 关键代码谁能讲到业务人员听懂？——数据写入、权限、对外请求这几段，要求当面讲：动了什么、写到哪里、发给了谁。讲不明白的，默认他自己也没读过。
3. 出了错怎么回退？版本在哪？——答不出回退路径的，说明没有版本管理，出事只能现场救火。
4. 哪些部分你们自己也没读过？——这一问是照妖镜：敢说“AI 生成的部分我们没有逐行读过，但测试覆盖了”是诚实且可接受的；声称“全部都看过”却讲不出细节的，更危险。

合格回答应该长什么样：拿得出测试集构成与评分结果、关键代码的业务语言讲解、版本与回退说明、以及一张“已知缺陷与未读代码”清单。和上一课一样——敢把没做完、没读懂的部分摆出来的，才值得把工具交到他手里。

常见问答

Q1：AI 写的代码，版权归谁？拿去商用靠不靠谱？ 这个问题没有可以背的固定答案：不同 AI 编程工具的服务条款对产出物的权利归属和使用范围约定不同，相关法律规则也在持续演变。稳妥做法：商用（尤其对外提供、嵌入产品）之前，查阅当时所用工具有关产出物权利的条款，拿不准就咨询公司法务或律师——以当时条款和法律意见为准，本课不下法律结论。内部原型阶段配合虚构数据练手，则没有这个顾虑。

Q2：完全不会编程，真的能做出能用的东西吗？ 能，但限定在“小而具体”的原型：输入输出明确、几十人内部用、出错可承受——本课的付款台账就是典型。门槛不在语法，在验收：写需求、造数据、核结果这三件事决定成败。反过来，高频使用、对外服务、动资金和敏感数据的系统，不是非程序员该独立承担的场景。

Q3：要不要先学一门编程语言再开始？ 不必先学。你需要的是“认字”级别的阅读能力——看得懂“打开文件夹、读文件、写入表格”这类业务含义就够了，不懂就当场让 AI 解释。真正要花时间练的是三件事：写需求清单、造含边界的测试数据、管版本。这三件事练熟，换什么工具都能用。

Q4：AI 写的代码把台账写坏了怎么办？ 分三段。事前：重要数据先备份，写入类操作先在副本上跑，程序跑两遍查重复写入；事中：停、退回上一版，别让 AI 在坏版本上连修十轮；事后：用备份数据恢复，把这次事故的输入加进测试集——同一个坑摔第二次，就是验收的责任了。

Q5：原型什么时候必须交给专业开发？ 看五个信号：用户从两三个人涨到全部门；要接公司统一登录、业务系统或数据库；要处理真实个人敏感信息；出错代价变成不可承受；需要长期有人维护。出现任何一个，就开始按 Q6 准备交接，不要恋战。

Q6：交给开发时怎么交接？人家推倒重写怎么办？ 交三样东西：需求与规则清单（最有价值的资产——业务规则是你们踩坑换来的）、测试集与预期表（开发的回归测试直接复用）、已知缺陷与未读代码清单。代码本身可能被重写，这往往正常且更好——原型证明的是业务价值和规则正确性，不是代码资产。把预期放在“规则和测试可复用”，交接就不会扯皮。

Q7：用 AI 编程工具会不会把公司数据泄出去？ 风险取决于工具条款和你喂了什么。原型的纪律就是：全程虚构数据，敏感数据不进开发环境；确实要用真实数据时，先过数据治理和条款审查（见第 3 阶段第 3 课）。这条纪律同时是第 1 课“样本虚构”和本课“边界”的自然延伸。

Q8：需求一次写全、让 AI 一次做完，不是更高效吗？ 恰恰相反。一次全给，产出是一大块，验证成本跟着翻倍——坏了不知道坏在哪一步，只能整体重来；而且需求越长、一次塞进的东西越多，AI 越可能漏读（见本课“机制三句话”的第三条）。小步的“慢”是把验证成本摊薄到每一步，总工期往往更短。这和工程上“分部分项验收”一个道理：没有人会等整栋楼盖完再验收。

自测

AI 帮你生成了“自动整理台账并群发邮件提醒”的脚本，运行显示“全部发送成功”。列出验收清单：你要亲自检查什么？

概念卡片

延伸阅读

• 本课方法与第 3 阶段第 1 课评估纪律配合使用；敏感数据治理见第 3 阶段第 3 课。
• 各 AI 编程工具能力属动态信息，选用时实测；流程方法本身长期适用。