企业官网建设流程全解析

经常有人问我：AI时代人人都能写PRD，产品经理是不是要消失了。我的看法恰恰相反：PRD的门槛确实被AI拉低了，但写出一份能落地的PRD，真正考验你的从来不是排版和措辞，而是理解业务、定义边界、推敲细节的能力。这篇文章不想讲高深的产品理论，只分享一套我实际在用的AI辅助PRD工作流——从一句话想法到能上评审会的需求文档，包含提示词、逐轮修改的检查点，还有一份可以直接复制改写的标准化模板。适合刚转产品的同学、中小团队负责人，以及所有被需求文档折磨过的非产品岗同事。读完之后，你大概率不会变成“专业”产品经理，但一定可以少熬几个写需求的通宵。

1. 先别急着打开AI，想明白PRD到底在解决什么问题

1.1 为什么说AI降低的不是“写文档”的门槛

很多人把PRD难写归咎于“不会写文档”，其实这是表象。过去一份PRD难产，一般难在三个地方：信息组织混乱，脑子里有一堆想法，但不知道先写背景还是先写功能；术语体系不熟，不熟悉字段、状态流、验收标准这些概念，写出来研发也看不懂；评审预判不足，不知道研发会在哪个点提问、测试会在哪个点抬杠。这三件事，AI恰好都擅长，你给它一段零散的想法，它能在几秒钟内组织成有条理的结构化文本。所以我才说，AI确实把“写PRD”这个动作门槛压到了几乎为零。

但这里有个明显的陷阱。AI擅长的是“把信息组织成文本”，不是“判断这些信息是不是对的”。它可以把一个完全错误的业务假设写得非常流畅，也可以把一段合理的需求扩展出三倍篇幅的无效细节。因此“零门槛写PRD”成立的条件，是你愿意理解这个文档背后在解决什么问题，并且有能力做最后一道核验。否则你得到的只是一份看起来很专业、实际没人愿意执行的高危文档。

1.2 PRD在协作里承担的真正角色

我在不同团队里见过对PRD的两种极端态度：一种认为PRD是立项仪式，写完就锁进抽屉；另一种觉得PRD可有可无，反正最后开发看代码就行。两种都错了。PRD真正的角色，是“决策记录”加“执行约定”。

所谓决策记录，指它要把一路讨论下来的关键结论写清楚：这件事为什么做、做到什么程度、哪些事明确不做。所谓执行约定，指研发要按它开发，测试要按它验收，设计师要按它画界面。换句话说，PRD不是记录需求的散文，而是团队成员的协作合同。合同里如果写满了“大概”“可能”“尽快”这类词，就等于没有约定。这也是为什么AI写PRD时，需要重点约束它不要在关键描述上含糊。

这里可以做一个很简单的类比：把PRD想象成餐厅菜单。菜单上如果写“招牌菜A：好吃”，客人没法判断要不要点；如果写“招牌菜A：某食材搭配某酱料，微辣，出品时间8分钟”，客人才能确认合不合口味。需求文档是同样的道理，能落地的描述一定比好看的说法更值钱。

1.3 不同角色会怎么读你的PRD

我在带新人写PRD时，最常推荐的一个练习是“站在对方岗位上重读一遍”。因为一份PRD从诞生到上线，经过的角色不止一个，而他们关注的东西完全不一样。我整理过这样一张对照表：

这张表想说明一个点：模块齐全的PRD，本质上是在同时服务好几类读者。如果你只站在“记录自己想法”的角度写，肯定会漏掉研发关心的字段、测试关心的异常。AI因为没有真实协作压力，它并不知道哪些模块写深、哪些写浅，所以真正靠谱的做法是：先按照这张表列出每个角色可能提出的高频问题，再让AI去填充，这样得到的PRD才经得起评审提问。

2. 搭建脚手架：怎么给AI描述需求，它才不会乱编

2.1 为什么不能说一句“帮我写个PRD”就算完

我经常看到有人让AI写PRD，第一句话就是“帮我写一个PRD”。说实话，当AI真的能输出时，确实觉得神奇，但多试几次就会发现不对劲：同一句话，换个说法重问，AI给你的PRD结构、重点甚至功能清单都可能不一样。原因是AI没有任何真实业务背景，所有细节都来自训练数据里的“常见做法”。

打个比方，你请代笔作家写一篇励志人物传记，只丢给他一句“写个励志人物传记”，他能写，但写出来的大概率是市面上励志故事的模板集合，而不是你朋友的故事。想让他写得具体，你得给他受访者的经历、性格、时间线。AI写PRD也是一样的，你不给背景，它就给你通用功能清单；你给的上下文越细，它就越靠近你要的那个方案。

所以我在实际工作中坚持一个基础原则：AI辅助PRD不是“一次生成”，而是“起草加多轮修订”。你扮演需求提出方兼审稿人，AI扮演初稿代笔。它的价值在草稿效率，你的价值在业务判断。

2.2 我固定用的四段式需求描述法

为了让AI每次都在同一套上下文上工作，我给自己定了一个最简输入模板，四个维度就够了：背景、目标、用户与场景、边界。

• 背景：现状是什么，哪个环节有问题。
• 目标：做完这件事后，可以量化的变化是什么。
• 用户与场景：谁会使用，在什么时间、什么情境下用。
• 边界：明确不做的事情。

写的时候有两条硬规矩。第一，背景不要写空话，比如“为了提高效率”，不如写“每周一上午需要花40分钟整理上周各人的周报”。第二，边界一定要写，因为AI最擅长往方案里塞功能，一条明确的不做清单能挡住绝大部分脑补。

下面是我在演示项目里实际用过的输入模板，你可以直接复制：

背景：团队目前用共享表格填写每周周报，在例会前主持人需要手动翻阅并汇总，经常有成员漏填，临近开会才发现。

目标：例会前30分钟，主持人能拿到一份本周进展摘要，并自动提醒未提交成员。

用户与场景：团队约10人，成员在手机或电脑上查看；主持人主要在会议前15分钟内快速浏览摘要。

边界：不做任务管理、不做日程规划、不改造现有共享表格的填写方式。

这个模板看起来很简单，但效果很好。因为AI一旦有了这四个维度的锚点，目标就不会写成“提升团队协作效率”这种大话，功能清单也会往“摘要生成”和“提醒”的方向收敛，而不是往项目管理的方向跑偏。

2.3 四个约束，让AI输出更可控

除了输入模板，我还会在提示词里加四个约束，作用是逼着AI“老实回答”，而不是自由发挥。

第一个约束是设定角色。开头就写“你是一名有5年经验的产品经理”。角色限定之后，AI的语气、结构和专业术语会更靠近从业者。第二个约束是明确任务格式，写上“请按以下结构输出PRD草案：背景、目标、用户与场景、功能需求、非功能需求、验收标准”。不要让AI自己发明结构，否则下一轮它又换一套新的，前后没法对照。第三个约束最关键，叫做“禁止脑补”，原句是“所有我没有提到的内容，一律标注为待确认，不要自行补充功能”。这句话配合边界清单，AI的幻觉会少很多。第四个约束是指定输出形式，比如“功能需求用表格呈现，功能编号、名称、优先级、详细描述、验收标准各占一列”。表格化的输出在后续修订里非常方便，可以逐行给反馈。

我实测下来，加了这四个约束之后，第一版PRD的可用度能提升一个档次。虽然还是会有一点AI自己发挥的内容，但起码已经是“可批注、可修订”的半成品，而不是一份重新写比修改更容易的文档。

3. 完整实操复盘：从一句“我想做个工具”到评审会能用的PRD

3.1 我给AI的第一版输入

下面用一个虚构但很常见的需求来跑一遍完整流程：假设我想做一个“周报速览工具”。需求来自真实的例会痛点，但具体方案并没有定型。我先把需求按照第2章的模板，组织成下面这段提示词：

你是一名有5年经验的产品经理，请基于以下内容输出一份PRD草案。

背景：团队目前用共享表格填写每周周报，主持人在例会前需要手动翻阅汇总，成员漏填要开会时才发现。

目标：例会前30分钟，主持人能拿到本周进展摘要，并自动提醒未提交成员。

用户与场景：团队约10人，主持人主要在会议前15分钟内快速浏览摘要。

边界：不做任务管理、不做日程规划、不改造现有共享表格。

输出要求：结构包含背景、目标、用户与场景、功能需求、非功能需求、验收标准。功能需求用表格呈现。没有提到的内容一律标为待确认，不要脑补。

第一版跑出来的草稿确实像模像样，背景、目标、用户与场景都写得通顺，功能清单也列了七八条。但如果你只是瞄一眼就转发给研发，那就掉坑里了。接下来要做的是逐条核验。

3.2 我在AI草稿里抓到的三处硬伤

第一处硬伤是“数据可视化图表”。AI在功能清单里主动加了一条“生成多维度的可视化图表，展示成员提交率与内容分布”。我的原始输入完全没提图表，这是典型的训练数据惯性，一提到“汇总周报”，AI就觉得该配个图表看板。可实际需求里，主持人只需要在开会前扫一眼文字摘要，要不要图表完全是另一回事。所以这条属于需求延伸，先标记待确认。

第二处硬伤是“群提醒渠道”。AI把提醒功能写得很细，直接默认“通过集成消息机器人自动发送提醒”。但我在输入里只说了“自动提醒未提交成员”，这个“群”具体是哪个群、用什么工具，团队还没定。AI给出来的方案来自常见实践，渠道没确认就直接写死，会让后面的研发按错误假设开发。我把这部分改成了“在摘要页顶部展示未提交成员列表，具体提醒渠道待确认”。

第三处硬伤是验收标准不够硬。AI写出“系统应准时向未提交成员发送提醒”，这句话里的“准时”没法测试。我把它改成“在例会前30分钟生成摘要，并在生成后5分钟内触发提醒；未提交成员名单从共享表格数据源实时读取”。改动很小，但对测试同学来说，前者没法写用例，后者才能直接落地验证。

这三处硬伤很有代表性：脑补功能、默认假设、模糊验收。它们不是AI独有的问题，但AI会让它们更隐蔽，因为草稿整体太流畅，容易降低人的警惕。

3.3 把反馈丢回AI，第二版改了哪些

修正第一版时，我没有重新开对话让AI“再写一遍”，而是在同一个对话里直接给出明确反馈：

请基于上面的PRD草稿做以下修改：

1. 删除“数据可视化图表”功能，原始需求未涉及。

2. 将“群提醒渠道”改为“待确认”，不要默认具体IM渠道。

3. 重写全部验收标准，禁止使用“及时”“准时”“流畅”等模糊词，全部改为可量化的指标。

4. 功能需求表格增加一列“状态”，分为：原始需求、建议待确认、已修改。

这里有个很实用的技巧：要求AI在功能表格里加一列“状态”，方便追踪它是不是又偷偷加了内容。第二版出来后，明显收敛了很多。AI删掉了图表功能，渠道改成“待确认”，验收标准也变成了“摘要生成后立即写入缓存，高峰期内最大响应时间不超过2秒”这种相对可测的表达。但我依然不会直接采用，因为AI对“2秒”这个数字是没有依据的，它只是为了让指标看起来更硬而编出来的。我会把它改成一个基于实际数据规模的合理预估，并备注“数值待压测验证”。

3.4 最后一公里，为什么必须人工接手

有人可能会问，既然AI能在几分钟内改出第二版，那再多改几轮是不是就能直接用了？我的经验是：不能。原因很简单，PRD里最贵的不是文本，而是决策。比如“图表功能到底要不要做”，这个问题的答案取决于团队是不是愿意为它多花几个工作日的研发时间，也取决于这份摘要将来是不是要服务高层汇报，而不是取决于AI能否把它写在文档里。这类业务权衡AI完全没法判断，它只能根据文本相关性选择“提”还是“不提”。

所以我的工作流在第二版之后转成“人工接力”：我去补业务背景里没说透的上下文，去给每个功能排优先级，去把风险和依赖写清楚，去决定数据埋点。AI负责快速生成、快速改写，我负责判断、决策、补上下文。经过两轮AI修订，再花人工时间精读一遍，这份PRD才能从“看起来专业”变成“敢拿去评审”。

4. 可直接修改使用的PRD标准化模板

4.1 完整版模板：十个模块一次讲清

这里给出我常年在用的完整版PRD模板，按模块排列，适合正式需求评审和跨团队项目。你可以直接把这个框架复制到文档里，逐模块填充。

表格是框架，使用时要注意模块之间的呼应，不要各写各的。比如“背景与目标”里写的成功指标，应该能在“数据与埋点”里找到对应的埋点定义；“功能需求”里的每个功能，应该在“验收与发布”里有覆盖。AI生成最容易把模块做成松散的拼盘，这一点需要人工重点检查。

4.2 精简版模板：一页纸够用的小项目方案

不是每个需求都需要十模块。敏捷迭代、迷你工具、内部效率优化这类场景，写完整版反而是负担，评审时大家也没耐心听。我一般会在这个场景下用精简版，只保留四块：

精简版的核心是“可测”。哪怕只有一页，只要验收标准清楚，研发和测试就能干活；反过来，如果十模块齐全但全是空话，评审会一样过不去。

4.3 模板里最容易被忽略的三个角落

我用这份模板审过不少AI生成的PRD，发现三个角落最容易被遗漏。第一个是“不做清单”。很多PRD只管写要做的事，不写不做的事，结果评审会上研发会问“那要不要支持导出？要不要同时兼容旧数据？”——这两个问题会瞬间把范围扯大。把不做清单写清楚，评审会能省至少半小时。

第二个是“异常与边界条件”。比如提交过程中断网、数据格式错误、成员重复提交，这些情况要不要提示、怎么提示。AI在生成PRD时往往会忽略这些“不常见但会真实发生”的路径，而它们恰恰是最容易返工的地方。第三个是“数据埋点”。做这个功能，上线后怎么评估效果？需要在哪个环节埋点？很多人在写PRD时完全没想这件事，等上线了才突然发现没有数据支撑。我的习惯是，在“背景与目标”里写下成功指标，然后在“数据与埋点”里至少补上一个关键埋点。这个习惯，比用不用AI写PRD都重要。

5. 我实测踩过的AI写PRD的坑，以及怎么绕开

5.1 坑一：AI会一本正经地“编功能”

AI最让我头疼的一个坑，是它会在完全没有输入依据的情况下主动补功能。这其实不是Bug，而是模型训练方式决定的：训练数据里大量PRD都包含“导出报表”“消息推送”“多端适配”这些常见功能，所以模型倾向于认为这些功能“应该出现”。问题是，你的需求未必需要。

我抓到过AI给一个内部小工具加“支持导出PDF和Excel报表”，给一个轻量提醒功能加“支持多语言”。这些功能听起来都正常，但每一个都会平白增加研发成本。我的排查方法很简单：把AI生成的功能清单逐个和原始输入对照，凡是输入里没有出现过的，先标记为“建议待确认”，确定不要，就在下一轮让AI删掉，并在“不做清单”里补一条。这个动作相当于给AI的自由发挥装一个护栏。

5.2 坑二：形容词一大堆，可执行性为零

用AI生成PRD的早期，我拿到草稿时最崩溃的不是功能太少，而是修饰语太多。“全面提升员工效率”“极大优化用户体验”“增强平台稳定性”这类话，在PRD里不仅没有信息量，还会掩盖真正的问题。因为在评审会上，任何人都没办法对“极大优化”提出反对意见，但也没人知道该怎么落地。

后来我养成了一个强迫症：整篇PRD里只要看到“提升”“优化”“完善”这类没有边界的动词，就停下来问自己：这件事做完之后，用户会做什么以前不会做的事？比如“提升提醒触达率”要改成“由漏填后才被发现，变为例会前30分钟自动提醒未提交成员”，这样才能变成可执行的目标。与其让AI写出漂亮的句子，不如先建立一套“看不懂就删”的清理习惯。

5.3 坑三：用户故事写得漂亮，但没办法验收

有些朋友喜欢让AI先写一堆用户故事，比如“作为一个忙碌的团队主持人，我希望在开会前自动拿到成员进展摘要，以便节省整理时间”。这种表述读起来很有人文关怀，但问题在于：用户故事和具体验收标准往往对不上，测试拿它没法写用例。

我的做法是，核心交付物以“功能需求”加“验收标准”为主，用户故事只作为理解需求的辅助材料，甚至干脆不写进去。一个功能点如果有清晰的触发条件、输入、处理逻辑、输出和验收标准，用户故事有没有都无所谓。与其被AI的故事感动，不如让它多写几行字段定义。

5.4 坑四：AI的“失忆”会让PRD越改越乱

第四个坑，也是我吃过最大的一次亏：AI在长对话里会丢失上下文。你在第5轮让它改功能2，它可能在第6轮把之前已经敲定的功能1结构给打乱。更常见的情况是，一次对话里改了很多处，等它重新输出时，部分已修改内容又跳回了旧版。

应对方法有三个。第一，对于已经敲定的内容，不要每次让AI重写全文，而是让它输出“本次修改的差异说明”，由你自己回填到最终文档。第二，重要决策写进“文档信息”的版本记录，不要只存在对话里。第三，如果对话超过七八轮，宁可重新开一个会话，附上当前版本全文，让AI在新上下文上继续改。本质上，你要把AI当成一个记性不太好的临时助理，而不是项目信息库。

6. 文档不是终点：评审共识与需求防漂移

6.1 评审前先做一次“走廊测试”

我每次写完PRD，不管是自己写还是AI辅助写的，都会在正式评审前做一件事：找一个完全没参与这个项目的同事，只给他5分钟，让他读一遍PRD，然后请他复述“这版到底要做什么、不做什么”。如果他说出来的内容和我的意图出现偏差，那问题多半在表达方式上，而不在读者。

这个测试在AI辅助写PRD之后变得更加重要，因为AI生成的文档结构清晰、语言流畅，特别容易让人误以为“表达得已经足够好”。但结构流畅不等于信息准确，读者能不能抓住重点，往往比文档是否精美更关键。走廊测试不需要任何专业工具，却能暴露PRD里目标不突出、模块比例失衡的问题，每次做都会有不小的收获。

6.2 需求摇摆怎么防：评审通过后进入“变更管理”

PRD最怕的不是写得差，而是评审通过后被频繁改动。今天加一个按钮，明天改一个文案，后天又说流程不对。每次改动对研发来说都是中断，项目排期也会被不断侵蚀。我的经验是，PRD评审通过那一刻起，它就该进入某种“变更管理”状态。

具体做法不复杂。小改动（比如文案调整、按钮顺序调整）由需求方直接在“版本记录”表格里追加一条说明，备注修订人和日期，不用重新出全套文档；大改动（比如新增一个核心功能、修改主流程）必须重新评审，并且要在文档里写明变更原因与影响范围。这个机制的真正作用不是禁止改需求，而是让每一次修改都有成本意识，逼着团队想清楚“改这个值不值”。

6.3 我的习惯：把PRD当合同，别当日记

最后说一个偏心态层面的习惯：把PRD当合同，别当日记。合同的特点是条目清晰、结论确定、不能随意涂抹；日记的特点是记录过程、允许犹豫、随时推翻。很多PRD写得像日记——开篇写“我们想过A方案，但后来觉得B方案也行”，中间写“具体审核时间后续再定”。研发看到这种文档，第一反应不是配合，而是等着你继续改。

所以我在用AI写PRD后，反而更强调确定性表达。需要暂定的地方，单独放进“待确认问题”清单，而不是散落在正文里；AI生成草稿时凡是出现“可考虑”“可根据实际情况”“视情况而定”这类表述，我会逐条处理成具体方案，或明确标注待确认。把犹豫放在结论之外，把决策留在正文之内，评审会才会变得高效。

最后分享一个我自己的体会：AI辅助写PRD这件事，最有价值的时刻往往不是它帮你生成草稿的十几秒，而是你盯着草稿提出第10个问题之后。以前写文档，最烦的是想法很多但组织不出来；现在AI帮我把话都写顺了，我反而必须要去追问“这里为什么这么写”“这个功能到底要不要”“这个目标能不能验证”。当你能开始提出这些问题，并且能给出一半以上的答案时，你已经是在做产品，而不是在写文档。到这一步，“AI时代人人都是产品经理”才算真正成立。