公司想推广Trae，我自己不太敢用Trae开发，遂测试下Trae和codex写prd的能力

在此记录下我的测试过程

由于涉及公司保密文件，故关键部分会打马赛克

Step1：写一个简略的需求说明，分别交给Trae(glm5.1)和Codex(gpt5.4)，用同样的skill同样的提示词分别生成两个prd文档

第一步就已经出问题了，我在生成prd的skill里设置了必须采用plan模式执行，否则直接拦截。正好我忘记开plan模式了，这里codex拦截了。但是trae用非plan模式执行了，没有拦截。

Step2：对比生成结果的时间

• codex用时5m 36s 6255词
• trae用时8m 19s 5251词

Step3：让另一个AI对prd进行测评

首先，先写个用于prd对比分析的提示词

本来想用claude 当裁判，但是我没买。所以用claude code + deepseek当裁判

评分结果

评分简略内容：

第五阶段：最终结论

1. 总分表（百分制）

┌────────────────┬───────┬───────┬───────────────────────────────────────┐
│ 维度 │ PRD A │ PRD B │ 说明 │
├────────────────┼───────┼───────┼───────────────────────────────────────┤
│ 结构完整性 │ 16 │ 15 │ A 稍优，异常场景覆盖更细致 │
├────────────────┼───────┼───────┼───────────────────────────────────────┤
│ 需求清晰度 │ 14 │ 15 │ B 更具体，但具体中有错 │
├────────────────┼───────┼───────┼───────────────────────────────────────┤
│ 技术准确性 │ 15 │ 11 │ B 的 regex 缺陷和 deviceID 过约束拉分 │
├────────────────┼───────┼───────┼───────────────────────────────────────┤
│ 边界与范围控制 │ 17 │ 13 │ A 紧贴原始需求，B 有范围蔓延 │
├────────────────┼───────┼───────┼───────────────────────────────────────┤
│ 开发可落地程度 │ 13 │ 14 │ B 更可操作但有坑，A 太抽象 │
├────────────────┼───────┼───────┼───────────────────────────────────────┤
│ 总分 │ 75 │ 68 │ — │
└────────────────┴───────┴───────┴───────────────────────────────────────┘

1. 综合总分

• PRD A：75/100
• PRD B：68/100

1. 最终胜者：PRD A

胜出原因：

PRD A 胜在少犯错。虽然 A过于保守、缺乏量化指标、模型加载方案模糊，但它没有引入技术性错误，且始终紧扣原始需求的边界约束（通用 vs医院专属的职责分离）。A 的「已确认 / 推断 / 待确认」标注体系虽然冗长，但为后续迭代提供了清晰的信息可信度地图。

PRD B 看起来更「好用」——有具体参数、有代码行号、有依赖图——但这些表面上的可操作性被几个关键缺陷抵消：regex在边界条件下会失效、deviceID 过滤规则可能丢弃合法数据、API 依赖未经证实。B 的问题属于做错了，A 的问题属于没做够。在
PRD 评审中，没做够比做错了更容易修复。

1. 使用建议

• PRD A 更适合作为直接开发输入（但需补齐模型加载方案和量化指标后再动手）。
• PRD B 更适合作为产品讨论草案——它的具体参数（动画时长、阈值）和依赖图可以作为讨论起点，但不能直接用于开发。
• A + B 合并会更优：用 A 的结构框架和边界定义，补入 B 的数据表、对比表、依赖图和具体参数，同时修正 B 的 regex实现建议和 deviceID 约束。

第六阶段：独立撰写水平评级

PRD A：合格产品经理水平（中等偏下）

判断依据：

• 做得好的：系统性地覆盖了 PRD 所有必要章节；对信息来源和确定性有自觉标注；对架构边界（通用 vs定制）有正确判断并贯彻全文；功能点的触发/前置/流程/异常/输入/输出/规则七要素完整。
• 做得差的：关键落地信息缺失（模型怎么加载、动画参数是多少、坐标规则具体是什么），而这些正是一个合格 PRD应该回答的核心问题。合格的 PM 不应把「按约定加载」写进 PRD而不给出约定。整篇文档更像一份需求分析报告而非可执行的需求文档。
• 与高级 PM 的差距：高级 PM会在发现大量「推断」和「待确认」后，主动将其收敛为一份明确的待确认清单并推动闭环，而不是让它们散落在全文各处。高级 PM也会给出有依据的默认决策（如「若无区域规则，默认采用单一 offset/scale 方案」），而不是停留在「推断应保留接口」。

一句话：分析到位，决策缺位。

PRD B：初级产品经理水平（偏上，未达合格线）

判断依据：

• 做得好的：有开发者视角，给出了具体行号、函数签名建议、依赖图等技术细节；对比表和表格提升了可读性；老项目 →新项目的技术栈迁移意识明确。
• 做得差的：在多个关键技术点上给出了有缺陷的具体方案（regex 无法处理嵌套 JSON、deviceID前缀硬编码过滤）。这比「不具体」更危险——不具体的 PRD 开发者会自己去想；错误的 PRD 会引导开发者写出 bug。此外，自行增加GUI 标签功能而未给出增加理由，暴露出范围控制意识不足。假设 API 存在而未验证，暴露出依赖分析不严谨。
• 与合格 PM 的差距：合格 PM 写出的技术方案不应包含已知缺陷。合格 PM应区分「这是原始需求」和「这是我推断补充的」，并对后者明确标注。合格 PM 不应在未经证实的情况下将外部 API 写入主流程。

一句话：积极性有，严谨性不足。想帮开发者省事，但省出了 bug。

总体评价：两份 PRD 都没有达到「高级产品经理水平」。PRD A 的问题是勇气不够——不敢做决策，大量内容停留在分析层。PRD B的问题是严谨不够——急于给出具体方案但未经充分验证。如果两份文档的作者坐下来合作，各取所长，产出的 PRD 可以达到 85分以上的高级水平。

3 个帖子 - 2 位参与者

阅读完整话题