企业官网建设流程全解析

从想法到交付，中间最容易断的一环就是 PRD：它要么脱离现有代码，要么写完后没有进入团队协作系统。`write-a-prd` 把访谈、仓库探索、架构取舍与 GitHub/Jira 工单串成一条流程，目标不是写得好看，而是让需求能够被接着做下…

PRD 不该是“AI 写完的一篇文档”：这个 Skill 先研究代码库，再把需求落到工单

从想法到交付，中间最容易断的一环就是 PRD：它要么脱离现有代码，要么写完后没有进入团队协作系统。write-a-prd把访谈、仓库探索、架构取舍与 GitHub/Jira 工单串成一条流程，目标不是写得好看，而是让需求能够被接着做下去。

它适合接在 需求梳理 之后。下面保留原始 Skill 及完整拆解。

Skill 详解:write-a-prd(撰写产品需求文档 PRD)

• 来源仓库:mattpocock/skills(write-a-prd/SKILL.md)——前端/TypeScript 教育者 Matt Pocock 维护的一套面向真实工程团队的 Claude Code / Codex skill 合集
• 文件构成:仅一个SKILL.md文件。
• tags:[workflow, planning, project-management]

一、Frontmatter 元信息(原文)

--- name: write-a-prd description: Create a PRD through user interview, codebase exploration, and module design, then submit as an issue. Use when user wants to write a PRD, create a product requirements document, or plan a new feature. Supports both GitHub Issues and Jira. tags: [workflow, planning, project-management] ---

触发条件很明确:用户想写 PRD、创建产品需求文档、或者规划一个新功能。它的最终产物不是一份 Markdown 文件放在本地,而是直接提交为 issue tracker 里的一条 issue(GitHub Issues 或 Jira 二选一)。

二、SKILL.md 全文原文(中文翻译)

以下为源文件SKILL.md的完整中文翻译,原文为英文,可在 mattpocock/skills 仓库 的write-a-prd/SKILL.md查看。

这个技能会在用户想要创建 PRD 时被调用。如果你认为某些步骤没有必要,可以跳过。 1. 请用户用一段长而详细的文字描述他们想解决的问题,以及任何可能的解决思路。 2. 探索代码仓库,核实用户所述内容是否属实,了解当前代码库的现状。 3. 就这份方案的方方面面对用户进行不厌其烦的访谈,直到达成共识为止。沿着设计决策树的每一个分支,逐一解决决策之间的依赖关系。 4. 勾勒出完成本次实现所需要新建或修改的主要模块。主动寻找机会,把功能抽取成可以独立测试的"深模块"(deep module)。 所谓深模块(相对于浅模块而言),是指用一个简单、稳定、几乎不会变化的可测试接口,封装了大量功能的模块。 和用户核实这些模块是否符合他们的预期。和用户确认希望为哪些模块编写测试。 5. 当你对问题和解决方案有了完整的理解之后,使用下面的模板撰写 PRD。这份 PRD 应当作为一条 issue 提交到项目所配置的工单系统中。 **工单系统探测方式:** - 检查 `CLAUDE.md` 中是否配置了工单系统(例如是否存在 `### Ticket Grooming` 小节,或者写明了 Jira 项目 key) - 如果配置的是 Jira:通过 Atlassian MCP 的 `createJiraIssue` 创建,issue 类型设为 "Story",并打上 `claude-code` 标签 - 如果用的是 GitHub Issues:通过 `gh issue create` 命令行创建 - 如果两者都没配置:直接询问用户要提交到哪里 - 提交到 Jira 时,描述内容的 `contentFormat` 必须始终设置为 `"markdown"` <prd-template> ## 问题陈述(Problem Statement) 站在用户的视角,描述用户正面临的问题。 ## 解决方案(Solution) 站在用户的视角,描述该问题的解决方案。 ## 用户故事(User Stories) 一份很长的、带编号的用户故事列表。每条用户故事应采用如下格式: 1. 作为一名 <角色>,我希望获得 <功能>,以便 <收益> <user-story-example> 1. 作为一名手机银行用户,我希望能看到账户余额,以便更明智地安排我的支出决策 </user-story-example> 这份用户故事列表应当极其详尽,覆盖该功能的所有方面。 ## 实现决策(Implementation Decisions) 已经做出的一系列实现决策的列表。可以包括: - 将要新建/修改的模块 - 这些模块中将被修改的接口 - 来自开发者的技术澄清说明 - 架构决策 - Schema 变更 - API 契约 - 具体的交互方式 **不要**在其中写具体的文件路径或代码片段——它们很可能很快就会过时。 ## 测试决策(Testing Decisions) 已经做出的一系列测试决策的列表。应包含: - 什么样的测试才算是好测试的说明(只测试外部行为,不测试实现细节) - 哪些模块将会被测试 - 相关测试的既有范例(即代码库里已经存在的同类测试写法) ## 不在本次范围内(Out of Scope) 描述本 PRD 不涉及的内容。 ## 补充说明(Further Notes) 关于该功能的任何其他补充说明。 </prd-template>

三、实现原理与工作机制

同样是纯 prompt 化的 skill,没有脚本或数据文件,核心价值在于流程 + 模板 + 落地渠道对接三件事的组合:

1. 五步走流程:
   - Step 1:先让用户"倒垃圾"——用长文本详细描述问题和可能的解决思路,不加约束地先收集原始输入。
   - Step 2:Claude 主动去探索代码仓库,验证用户说法是否属实、了解当前代码库现状——这一步把"需求"和"现实的代码约束"对齐,避免 PRD 写出脱离实际的东西。
   - Step 3:"Interview the user relentlessly"(不厌其烦地盘问用户),按"设计决策树"的每个分支逐一解决依赖关系。这是刻意强调的高强度访谈,直到达成"shared understanding"(双方共识)为止。
   - Step 4:勾勒出需要新建/修改的主要模块,并主动寻找可以抽取成"深模块(deep module)"的机会。文件里对"深模块"给出了明确定义:用简单、稳定、可单独测试的接口封装大量功能的模块(区别于"浅模块"——接口复杂但内部功能少)。这明显借鉴自 John Ousterhout《A Philosophy of Software Design》里的核心概念。之后还要跟用户逐一确认这些模块是否符合预期、哪些模块需要写测试。
   - Step 5:所有信息齐全后,套用下面的<prd-template>模板撰写正式 PRD,并提交为 issue tracker 里的一条 issue。

2. Issue tracker 自动探测逻辑:
   - 先检查项目的CLAUDE.md里是否配置了工单系统(比如是否存在### Ticket Grooming段落,或者写明了 Jira 项目 key)。
   - 如果配置的是 Jira:通过 Atlassian MCP 的createJiraIssue创建,issue 类型固定为 "Story",打上claude-code标签,并且提交内容的contentFormat必须设为"markdown"。
   - 如果用的是 GitHub Issues:走gh issue create命令行创建。
   - 如果两者都没配置:直接问用户提交到哪里,而不是自作主张。

3. PRD 模板结构(<prd-template>)固定为六个部分:Problem Statement(问题陈述,站在用户视角)→ Solution(解决方案,同样站在用户视角)→ User Stories(要求"extremely extensive",用标准的 "As a<actor>, I want a<feature>, so that<benefit>" 格式,并给出了银行 App 余额展示的例子)→ Implementation Decisions(实现决策:涉及模块、接口、架构、schema、API 等,但明确禁止写具体文件路径或代码片段,理由是"会很快过时")→ Testing Decisions(测试决策:强调"只测外部行为,不测实现细节",并要参考代码库里已有的同类测试写法)→ Out of Scope / Further Notes。

四、使用场景

• 用户说"帮我写个 PRD""写一份产品需求文档""帮我规划一个新功能并建个 ticket"。
• 团队使用 GitHub Issues 或 Jira 作为需求管理系统,希望 AI 产出的 PRD 能直接落地成一条可追踪的 issue,而不是丢一份 Markdown 文件在本地了事。
• 适合中大型功能的规划阶段,尤其是需要先摸清代码库现状、再和相关方反复确认的场景。和上面brainstormingskill 相比,这个更偏"正式交付物"和"团队协作沉淀",而不是单纯的个人构思阶段。

五、亮点总结

• "深模块"设计理念的显式引入,把架构设计的行业最佳实践直接写进了 skill 流程里,引导 Claude 在做模块拆分时不只是"照抄现有结构",而是主动寻找封装点。
• 对接真实工单系统(GitHub/Jira)的探测优先级和调用方式写得非常具体,包括 Jira 的 issue type、标签、contentFormat参数,这些都是容易在实践中被忽略的细节,写清楚后能避免生成的 PRD "有内容没有 owner / 没有留痕"。
• User Stories 部分要求"LONG""extremely extensive",这是刻意的过度覆盖策略,倾向于让 PRD 覆盖尽量多的边界场景,而不是只写主干流程。
• Implementation Decisions 里"禁止写具体文件路径或代码片段"体现了对 PRD 文档保鲜度(与代码库不同步腐化)的重视,这是很多团队写 PRD 时容易踩的坑。