我要投稿

我让3个AI吵了一整天架，它们把PRD写完了

发布日期：2026-05-22 19:32:42 浏览次数： 1514

作者：产品异兽 Prod.Monster

微信搜一搜，关注“产品异兽 Prod.Monster”

受犬校的朋友Bink启发，他搭了个基于3个角色的Agent，在debate过程中几乎自动化的完成PRD撰写。

在交流中，我发现Bink的工作环境以B端产品为主，我也会做一些B端的需求，总结下来B端的工作环境相对稳定，业务输入、产品规范等等相对收敛，但是C端场景下，业务输入有很多隐性信息，产品规范特别是交互规范相对发散。刚开始我自己指挥几个agent互相辩论，并没有吵出来个满意的结果，本来打算放弃的。

可是很多优秀的团队已经可以用AI做这些事了啊，一定是我的原因，而不是AI的原因。这周末折腾一整天、打折的DeepSeek都让我烧心疼了、两次差点放弃后，竟然调出来个像模像样的系统。

项目被我放到github上了，可以在文末获取链接。

先展示战绩：

1.智能座舱后视镜调节功能，单模块N个功能点组合的简单需求，一遍过。

2.教育平台人才库管理demo，多用户端、多功能的稍复杂需求，一遍过。

3.智能座舱语音助手HMI交互设计，多场景、耦合较高的复杂需求，修改两遍过。

这个项目，我管它叫“产品大师”，其实更想叫它们MAGI，就是新世纪福音战士里面的超级计算机的名字。

「MAGI 是由三個獨立思考的量子電腦組成的超級電腦系統。三個 MAGI 分別命名為 MELCHIOR、BALTHASAR 和 CASPER。當需要做出重大決策時，MAGI 會進行投票，如果三個 MAGI 中至少有兩個達成一致，決策就會被執行。」

— 新世紀福音戰士（Neon Genesis Evangelion）

产品大师借用了 MAGI 的核心思想：用多个独立 Agent 互相审查达成共识，而不是靠单一个体的一次性输出。我雇了三个agent：

一位controller，负责把控流程、调度任务，管理所有硬规则。
一位PM，负责做所有产品工作，做规划、给思路、写prd、做demo。
一位reviewer，负责找茬，PM的任何产出都会被他挑三拣四。

而我，负责原始信息的输入，一般来说就是一句话。他们三个负责吵架，直到吵出共识之后，才会把结果交付给我。

整个系统中，我认为发挥作用明显的有这么几个设计：

1.强制的工作流和检查点

刚开始我并没有约束他们的工作流，后来发现他们非常容易「放大误差」。别管是因为幻觉，还是因为信息丢失，只要在前面的环节出现了一点点问题，后面就会不断放大不断放大，出来一些很离谱的结果，比如下面这种，其实我就是让他做一个常见的在汽车中控屏发起、调节后视镜的功能，他误以为是robotaxi的运营人员在云端远程调解后视镜（远程调节有卵用？），结果后面越来越发散，设计出来一个巨复杂的流程，添加了二十几个离谱的功能。

调了大半天差点放弃的时候，我突然想到，如果……如果……如果我把好的说成坏的，把黑的说成白……

（赛文凯警告）

如果我对着AI vibe writing PRD的流程是已经完全跑通，只是需要自己盯着看，那能否直接把这个流程搬给MAGI来用？

于是就有了下面的流程：

节点一，我输入原始需求之后，PM先识别需求的前置依赖项，我输入前置依赖项之后，它才开工
节点二，前置依赖识别清楚后，PM整理大致方案跟我确认，确认后才进下一步
节点三，大致方案确认了之后，如果涉及到前端需求，就先做html demo，跟我确认了交互后，才进下一步
节点四，写prd

这样别管我前置输入够不够、MAGI有没有判断出来自己缺失的信息，我能把风险变成分步的、可控的、提早暴露出来，不至于烧了一堆token之后才发现问题。

2.skill

严格要求不同的角色使用指定skill，先保证交付物的格式起码是正确的。

比如我要求PM必须用我的2red-product-monster-prd的skill来写prd，至少保证prd格式满足我的基础要求。我要求controller必须用我们团队的prd-review-skill做最终的准出检查。

哦对了，为什么是controller用skill做最终检查而不是reviewer，因为我希望reviewer的视角也是发散的、灵活的，把所有硬性的规则都由controller维护。

指定skill过程中踩到一些坑：产品大师部署时本身就是个skill，每个agent都有个自己的md，我只是在md中写上用2red-product-monster-prd的skill，但并不是每次他都能准确用到这个skill（虽然我确实已经安装好了）。后来我把这个prd skill里面的核心要求也挑出来写到了PM.md里面，这样格式就变得很稳定了。

3.SOP！SOP！SOP！

在调试之前，我从没意识到SOP这么重要，不仅仅是第一条的固定节点，而是对整个流程的管理。直接说现在我是怎么做的：

复杂度评估后做类型判定，而不是设轮次上限。 刚开始我让他们按轮次迭代，结果很容易在某一轮卡死。后来改成按 PRD 类型（功能型/策略型/修复型/架构型）自适应流程——功能型走完整三阶段，策略型加实验设计但可跳过 Demo，架构型直接跳过 Demo。这样不用纠结第几轮，只看阶段对不对口。
分批产出，禁止一口气写完。单个 HTML Demo 动辄上千行、PRD 全文 30KB+，DeepSeek 一次生成不完就会超时。现在强制 PM 先评估复杂度：简单的一次性输出，复杂的拆成三五批、每批写一个模块或一层，落盘再改下一批。
计时能力（现在好像有bug），我想让controller管理每个环节的最大时间，又弄了个watchdog计时，昨晚搞到1点没继续搞了，现在好像并没有真正跑起来……还是会有卡死的情况。

这个项目我放到了git上：git@github.com:Kira2red/magi-product.git

现在还有啥问题呢？