核心用法
write-a-prd 是一款面向产品经理与技术负责人的结构化 PRD 生成工具。其工作流遵循五步法：首先引导用户详细描述待解决问题与初步方案设想；其次深入探索代码库，验证用户假设并理解现有架构；随后通过 relentless interview（深度追问）逐项厘清设计决策树上的依赖关系；接着识别并设计"深模块"（deep modules）——即功能内聚高、接口简洁稳定、易于独立测试的模块单元；最终将完整理解转化为标准化 PRD，以 GitHub Issue 形式提交。
显著优点
1. 双向验证机制：不盲从用户初始描述，而是结合代码库实况进行交叉验证，避免"纸上谈兵"的需求文档。
2. 深模块设计哲学：主动寻找可独立测试的高内聚模块，提升系统可维护性与测试覆盖率。
3. 结构化输出：采用业界通用的 PRD 模板（Problem Statement → Solution → User Stories → Implementation Decisions → Testing Decisions → Out of Scope → Further Notes），确保信息完整且无遗漏。
4. 工程化落地：直接生成 GitHub Issue，打通"需求 → 文档 → 任务追踪"的闭环。
潜在局限
- 依赖用户配合度：relentless interview 环节需要用户投入较高时间成本回答细节问题，若用户急于求成可能导致信息缺失。
- 上下文窗口限制：大型代码库的 exploration 可能受 token 限制，深层依赖关系或需多轮交互。
- 模板刚性：标准化模板虽保证完整性，但对特定团队已有 PRD 格式可能需额外适配。
- 无自动同步机制：PRD 提交 Issue 后，若代码库或需求变更，需人工维护文档时效性。
适合人群
- 需要为新功能撰写正式 PRD 的产品经理
- 负责技术方案评审、希望前置模块设计的Tech Lead / 架构师
- 希望建立规范化需求流程的创业团队技术负责人
常规风险
- 过度设计风险：relentless interview 可能引导用户陷入不必要的细节，需在"足够清晰"与"快速迭代"间把握平衡。
- 代码库理解偏差：exploration 基于静态分析，动态运行时行为可能未被捕捉，导致模块设计与实际运行冲突。
- Issue 权限问题：若用户无目标仓库写入权限，提交环节将失败，需提前确认 OAuth 或 Token 配置。
- 敏感信息泄露：代码库 exploration 可能接触敏感配置，PRD 生成后需人工脱敏审查再提交至公开 Issue。