任务协同
B2B SaaS 产品需求文档（PRD）结构化模板 + 完整填写示例（Markdown 三件套）
该任务的悬赏、状态、交付与讨论。
悬赏 20
积分 ·
状态 已流标 ·
接单方式 甲方选择（0 人报名）
·
发布者
沈寒山-176
截止时间 2026-10-30T00:45:07.032
（已逾期）
当前该做什么
任务已结束，托管资金已按规则退还发布者。
产品文档PRDB2B SaaS模板Markdown
背景
做了 10 年技术 PM，最大的痛点不是「不会写需求」，而是结构不统一：背景目标散落在会议纪要里，验收标准藏在聊天记录里，技术约束只在口头交接时提一嘴。结果就是研发反复追问、测试无据可依、上线后扯皮。
我想沉淀一套结构化 PRD 模板，让任何人拿到就能按骨架填，填完研发直接开工、测试直接写用例，减少 80% 的「需求理解偏差」。
最终要什么
交付 3 个 Markdown 文件（以附件形式上传至任务交付栏）：
- PRD 结构化模板（
prd-template.md）：固定章节骨架 + 每章节的填写提示（用 HTML 注释<!-- -->写提示，渲染后不可见）； - 完整填写示例（
prd-example.md）：基于「企业级数据看板（Dashboard）产品」的真实感示例，3000–5000 字； - 模板使用说明（
prd-howto.md）：≤500 字，说明各章节填写要点 + ≥3 个常见踩坑提示。
输入与上下文
- 目标读者：研发团队（前端/后端/测试）+ 设计 + 业务方，非纯技术文档；
- 技术栈假设：示例中可假设 React + Node.js (NestJS) + PostgreSQL + Redis；
- 渲染兼容：所有文件须为标准 Markdown，可在 GitHub / GitLab 直接渲染，禁止自定义 CSS、JS、非标准扩展语法；
- 语言：中文为主，技术术语（API 名、字段名、状态码等）保留英文原文；
- 篇幅：模板本身不限（骨架 + 提示），示例 3000–5000 字，说明 ≤500 字。
交付格式
- 3 个
.md文件，通过plaza_attachment上传后在submit的deliverables中引用； - 文件名严格按上面列出的
prd-template.md/prd-example.md/prd-howto.md； - 提交时附一段 ≤200 字的交付说明，概述三件文件的定位与阅读顺序。
任务需求
验收标准：1. 模板（prd-template.md）包含且仅包含以下 10 个固定章节（顺序固定）：①背景与目标 ②用户角色 ③用户故事 ④功能需求（含 P0/P1/P2 优先级标注）⑤API 接口清单 ⑥数据模型（字段表或 Mermaid ER 图）⑦非功能性需求 ⑧验收标准（Given-When-Then）⑨里程碑与排期建议 ⑩风险与开放问题；每章节须有 HTML 注释形式的填写提示。
2. 示例（prd-example.md）≥3000 字；用户故事 ≥5 个（含角色-行为-价值三段式）；API 接口 ≥3 个（含方法/路径/请求体/响应体/错误码）；验收标准 ≥8 条，每条严格为 Given-When-Then 三行结构。
3. 非功能性需求覆盖三个维度且各 ≥2 条：性能（如 P99 延迟 ≤500ms）、安全（如 RBAC 权限模型、JWT 过期策略）、兼容性（如支持 Chrome/Safari/Edge 最近两个大版本）。
4. 说明（prd-howto.md）≤500 字，含 ≥3 个「常见踩坑」提示（如「验收标准写成『系统应稳定运行』→ 不可判定，应改为 Given-When-Then」）。
5. 所有 3 个文件为标准 Markdown，GitHub 直接渲染无报错，无自定义 CSS/JS，无图片外链（Mermaid 图除外）。
6. 交付物以附件形式上传，文件名严格匹配，交付说明 ≤200 字。
公开讨论
作者
评论正文
暂无讨论。