让产品用AI写业务代码、开发只负责加固？这套跨角色协同流程我跑通了
让产品用AI写业务代码，开发只负责"擦屁股"？这套流程我跑通了
大概半年前，我开始琢磨一件事：需求这玩意儿，能不能别再用Word和Confluence传了？
你要知道，过去十年我们团队的产品经理，常年干的一件事就是——写PRD，然后开发拿着PRD一脸懵地来问："这个『特殊情况下』到底是啥情况？" 然后就是无尽的会议、返工、互相觉得对方是傻子。
说白了，大部分bug不是开发技术不行，是需求本身在"人传人"的过程里变了味。
今天聊的这个新范式，可能听着有点疯，但我真觉得它能把这事儿解了。先给你看结论：
一句话说清楚这个范式
产品/业务用自己的业务理解，驱动 AI 生成业务逻辑代码，直接提 PR 进 Git 流程；开发不写业务逻辑，只做评审和二次优化——补架构、修边界、改性能、加固异常。
需求即代码
跨角色协同
说白了，需求本身就是代码，文档退化成注释和 PR 描述。需求偏差直接体现在代码逻辑上，而不是口头文字里那些含糊其辞。
文章有点长，我尽量多举例子，少讲空话。你按需跳着看也行。
一、先看清楚：传统那套到底哪儿疼
咱们先说现状，不然你不知道我为啥要折腾这玩意儿。
传统模式基本是这两种：
现状A：产品只写文档需求，开发从零翻译成代码。
翻译成本高得吓人，需求理解偏差大量发生在"产品嘴里的意思"和"开发听到的意思"之间。你说"打折"，他理解成"满减"。
现状B：产品完全不碰代码，全部开发写。
那产品只能当"需求讲述人"，开发写错了他还说不清哪儿错，因为代码对他是个黑盒。
这俩的共性痛点就一个词：翻译损耗。业务规则在"人传人"的过程里，必然丢三落四。
二、新范式的核心：需求即代码
那我的想法很简单粗暴——让懂业务的人，直接把业务逻辑"说"成代码。
产品不精通底层架构没关系，但你必须清楚四件事：
- 输入是什么（比如：用户下单，订单金额、会员等级）
- 输出是什么（比如：折扣金额、应付总额）
- 业务规则（比如：满1000减100，会员再打9折）
- 异常场景和约束（比如：金额不能为负；会员等级最高5级）
然后，把这段业务逻辑讲给 AI，让 AI 当打字机，产出一版能跑的业务逻辑代码。产品不懂框架最佳实践、不怕性能坑——那是后面开发的事儿。
关键区别是：产品提交的是"可运行的业务原型"，而不是一段描述需求的文字。
需求一但物化成代码，评审的时候大家就是对着代码聊业务，而不是对着文档脑补逻辑。
最爽的一点：需求偏差直接体现在代码逻辑上。产品提交的代码哪儿不对，开发一眼就能指出来，产品也能当场看明白，不用再猜"开发到底理解了没"。
三、完整流程长啥样
这套流程一点都不玄乎，就是 Git 的那套老规矩，只是换了配合方式：
完整流水线：业务 → AI → PR → 开发评审 → 合并
- 1. 产品讲业务：自然语言描述输入、输出、规则、异常
- 2. AI 生成业务代码：业务规则校验、简单接口、转换逻辑、算钱、报表计算
- 3. 产品本地自测：用自己的业务用例把代码跑一遍，确认 AI 没曲解需求
- 4. 提 PR：带上业务说明、期望行为、已验证的测试案例
- 5. 开发评审：核对业务逻辑是否符合作者意图；补架构、异常、事务、幂等、安全、性能；修边界 case、内存泄露、错误依赖、不符规范的地方
- 6. 开发可直改或打回：可以直接在这个分支上补 commit，也可以打回让产品用 AI 再迭代
- 7. 测试合并：验证通过后合并进主分支
看着是不是特别正常？它就是 GitFlow 换个玩法。但真正的难点从来不在流程，而在"责任"两个字。
四、最大的坑：这锅算谁的？
这是你第一个得想明白、也是最现实的问题——
如果是产品驱动 AI 写的 PR，上线出故障了，算谁的？
你想想这个场景：
- 产品说："业务逻辑我是对的，AI 代码有技术 bug。"
- 开发说："这个 PR 是产品提交过来的，我只是 review，又没让我全重写。"
两边都觉得自己有理，然后 Git 的提交记录里…只有提交人的名字。系统它分不清"业务责任人"和"技术责任人"。
原生 GitHub 机制里，提交者就是首要责任人。但产品不该也不可能为技术风险负责——他连那代码的框架都是 AI 生成的，你让他负责技术 bug，他除了脸绿还能干嘛？
所以要跑通这套流程，必须在流程上把丑话说在前头：
核心权责声明：产品提交 AI 生成的 PR ≠ 这个代码可以直接上线。
开发 Review 通过并且合并，就代表开发接管技术责任；业务正确性由提交方（产品）负责。
这个声明必须写进 PR 模板、评审清单里，强制区分两份检查清单：
- ✅ 业务侧自查：业务逻辑对不对、业务 case 过了没、输出结果符不符合预期
- ✅ 开发侧自查：异常、幂等、事务、性能、安全、依赖、编码规范
不把这个权责理顺，团队一定会抵制——没人愿意背别人用 AI 生成的代码的锅。
我踩的坑：第一次推动的时候，直接跟开发说"以后产品的代码你们 review 一下"——结果被怼得哑口无言，因为"review"在大家心里= "出了问题全算我的"。后来我把责任声明写进 PR 模板，明确"合并即接管"，才有人敢点头。
五、产品到底要不要会写代码？
这个问题我问过自己无数遍。答案是——
不是要他会写代码，而是要他能读代码，尤其是自己业务领域内的代码。
产品不需要会写复杂算法，但他必须能看懂 AI 输出的代码到底在执行什么，能识别出"AI 是不是把我的规则曲解了"。
举个例子，同样是"满减+会员折扣"，我给你看 AI 生成的初稿，你看你能不能看出问题：
def calc_discount(amount, vip_level):
"""阶梯折扣：满减 + 会员折扣。"""
discount = 0
# 满 1000 减 100
if amount >= 1000:
discount += 100
# 满 500 减 30
elif amount >= 500:
discount += 30
# 会员额外 9 折（对满减后的金额）
if vip_level >= 2:
discount += (amount - discount) * 0.1
return discount
如果你是产品，你至少得能看得出来：
1. 这三行 if/elif 是"取一档"，不是"叠加" —— 满1000只减100，不会同时减30。这符不符合你的规则？
2. 会员9折是对"满减后"的金额算的 —— 这跟你的口径一致吗？
3. 金额会不会有负数？vip_level 会不会传 None？——这几个暂时可以不管，那是开发补丁的活儿。
看出第1、2点，你的"读代码"能力就合格了。识别 AI 有没有曲解你的业务规则，这是产品不可外包的核心能力。
如果产品完全读不懂代码，那他提交的 PR 就是 AI 幻觉出来的垃圾，开发评审的成本远高于自己从头写——这套模式就彻底失去意义了。
所以你会看到，这套模式对产品的要求不是"会写代码"，而是"能验证自己领域的业务逻辑"。门槛是变了，但不是变高到离谱——是你得从"写文档"升级到"看得懂自己业务的代码在干嘛"。
六、什么业务适合，什么绝对不适合
这是很多想抄这套模式的人，最容易翻车的地方——啥都想往里塞。
我的经验是：AI 产出物，大部分只能覆盖"业务薄逻辑"。
✅ 适合产品驱动 AI 提 PR 的：
- 业务规则校验（比如优惠券是否可用）
- 状态流转（订单从"待支付"到"已支付"到"已发货"）
- 简单计算（折扣、运费、税费）
- 报表逻辑（统计、汇总、分组）
- 配置解析（把配置文件转成业务结构）
- 简单内部工具接口
- 工作流条件分支
❌ 绝对别让业务生成的（开发主导）：
- 底层框架改造
- 存储/表结构设计
- 复杂 SQL
- 并发逻辑
- 中间件交互
- 分布式事务
- 高吞吐接口
用人话说：产品提交的 PR，大多是上层业务逻辑层；底层基础设施，永远是开发的地盘。 你想让产品用 AI 去写个分布式事务，那不是解放生产力，是制造事故。
判断口诀——问一句："这个风险是否只局限在这个函数内、有清晰的输入输出、对基础设施没有深层耦合？"
✅ 是 → 适合业务驱动 AI PR；❌ 否 → 一律开发主导。
七、评审成本怎么控？(很多人卡在这)
你可能会说："产品要是天天甩一堆 AI 代码过来，我 review 的成本比自己重写还高。"
这个担心非常合理。但关键在于：产品必须先自测，再提 PR。 不是把没验证过的 AI 草稿直接扔给评审。
所以 PR 模板里必须得有这一条，强制产品填：
- 业务背景是什么
- 业务预期输入输出是啥
- 你自己已经验证过哪些 case
- 明确标注：本 PR 由 AI 辅助生成，业务责任人是谁，技术接管人是谁
把这些都填清楚，开发评审就有据可依：先核对业务逻辑符不符合意图（防 AI 幻觉），再补技术风险（异常、事务、日志、规范）。 而不是从头猜这代码想干嘛。
到这一步，评审成本是被自测吃掉了一大半的——开发是在"验证+加固"，不是在"重写"。
八、落地模板：可以直接抄的团队形态
光讲道理没用，我给你一套能直接照抄的落地配置：
团队落地五件套
- 1. 保护分支：main 不允许产品直接合并，必须经过开发 Review 批准
- 2. PR 模板：强制填业务背景、输入输出、已验 case、责任声明（业务/技术责任人）
- 3. 双清单：业务自查清单 + 开发评审清单，强制区分
- 4. 责任声明：合并即代表开发接管技术责任
- 5. 迭代闭环：开发可直改或打回产品用 AI 再迭代
这套东西我已经整理成了一个开箱即用的 GitHub 项目，把 PR 模板、评审清单、保护分支脚本、GitHub Actions、范例 PR 全打包好了，复制进团队仓库就能直接用：
九、结尾：这不是"产品取代开发"
最后我得把话说清楚——这套模式不是产品取代开发，是业务需求表达的媒介，从文档迁移到了代码原型。
开发的工作重心不会消失，而是上移了：从"翻译需求"变成"架构、质量、性能、安全把关 + 二次优化"。
现在已经有一些小团队在内部工具、低复杂度业务系统上这么玩了（产品用 Cursor/Aider 写业务代码提 MR），但核心业务系统几乎不放开——根源就是权责和技术风险。
长远看，我觉得这会是趋势：需求表达越来越靠近代码，开发的不可替代性越来越体现在"复杂技术问题"上，而不是"翻译需求"上。
一句话总结：让懂业务的人把需求物化成可运行的代码，让懂技术的人把这份代码加固到能上线。各管一摊，别再互相猜。
如果你正好也在试"Cursor 写业务代码"这条路，欢迎来仓库里逛逛，模板和 checklist 都是现成的，能省你不少事。有啥想法也欢迎留言聊。
浙公网安备 33010602011771号