AI时代正在颠覆传统PRD文档的编写逻辑。面对AI Coding的冲击，产品经理该如何重构需求文档的核心价值？本文通过跨境电商案例，揭示从『技术细节执行者』到『业务意图管理者』的转变路径，并分享实战中提升AI协作效率的六大工具与HTML逆向重构技巧。

首先问各位产品经理一个问题，你们觉得在和业务，研发沟通需求的时候，使用什么样的方式沟通是最有效的。

在传统的软件工程中，我们通常会使用PRD，背后是因为光靠口头的表达和讨论很难形成共识，只有将大家对于需求的理解落到纸面上，大家才能有直观的，并且不随时间和空间的影响，随时都可以打开并且写下自己意见的文档。

以企业A为例，PRD文档结构包括5个部分：

1. 概述包括业务背景&痛点，业务目标&价值，术语，参考文档
2. 需求概述包括整体业务示意图，业务流程图，状态图，用例图，需求清单，用户角色
3. 系统功能概述包括功能概述，流程图，功能需求描述，页面原型，数据说明，接口需求
4. 非功能需求包括性能需求（响应时间，吞吐率，CPU（WAP/Redis/DB）），安全需求，易用性，可维护性，其他需求
5. 附录。

整体来看，这套 PRD 结构属于偏企业级、偏交付型 PRD，基本覆盖了产品、研发、测试需要的信息，完整性比较高。

随着AI Coding时代我们是否还需要沿着这个路径继续我们产品经理的PRD文档编写工作呢？

答案是显而易见的，不需要。

传统的PRD文档同时在做几件事：让业务说需求，让开发将逻辑，给测试写用例，因此需要页面，按钮，字段，状态，接口。这些信息AI只需要分分钟就可以完成，但是AI不知道为什么。为什么要做这个需求？这个规则这么设计背后的原因是什么？所以PRD更重要的是业务意图，而不是技术细节。

所以我认为PRD结构应该是这样的：

1. 业务共识：为什么？解决谁的问题？成功是什么？不解决什么？为什么现在做？
2. 需求清单：系统需要具备哪些能力？
3. 关键业务规则：哪些规则必须遵守？
4. 用户旅程：用户如何使用功能？
5. 验收标准：如何判断功能正确？

而其他的模块如页面原型，接口设计，测试用例更合适由AI根据这份核心的PRD生成一个辅助文档。

举个跨境电商行业-海外仓货物仓租计算线上化需求的例子。

传统方式下，产品需要花一周的时间完成PRD文档的编写，尤其是原型绘制，通过Axure即便在有组件的情况下，需要花费3天以上，剩下时间用来细化具体的规则和技术细节，包括每个页面，每个字段，每个按钮的操作逻辑。

用Axure画出静态页面后，标注上业务规则，然后花大量时间向业务方解释”这里会怎么计算”。每改一版规则，就要重新画一遍。

AI时代，我们只需要通过基本文字说明，大概半天能够说清楚，并提供给AI，让AI完成demo绘制和操作逻辑的描述。当然很多时候，尤其是刚开始使用AI工具时，需要磨合下他才知道你的风格。因此会需要多轮的对话，多的时候可能AI做十几个版本才能满足你的要求，但用多了，我们把指令做的更明确一些，他出来的效果就很好。

有人可能会说AI也需要做很多版本啊，我自己可能不需要这么多。有一点需要注意的是个人心态的转变，以前在产品文档工作这件事情上，产品经理是个执行者，现在我们是一个管理者，我们只需要管理好这个AI员工即可，在AI员工工作的时候，我们可以同时做其他事情，其他更需要产品经理付出大量经理去做的事情。

此外好多人会觉得，使用AI完成新模块的构建相对来说效率是比人更高，但更多时候我们的功能是针对老的功能模块进行迭代，在这种情况下又应该如何使用AI呢？针对老的功能模块，可以装一个浏览器插件-singlefile，它可以把指定页面的HTML趴下来，我会直接把HTML喂给AI，让它先做第一个版本的demo，然后在基于新的优化需求，让它迭代。当然也有一些工具，只需要一个截图，就可以1:1复刻原来页面的风格，布局，也非常高效。

笔者工具箱中存放的AI工具有Codex、Cursor、Workbuddy、Trae、Coze以及谷歌的Ai Studio。每个工具的使用成本，工作效果都不太一样，之后我们有时间可以拿出来横向对比下。如果您也有自己认为好用的AI工具，也希望能在评论区分享给大家。