一轮结构化提问、一次综合成稿、一遍校验。用户故事、界面文案、范围表、决策记录与验收用例——按您的模板，几分钟完成。涉及资产风险的副作用一律写为硬性拒绝。
Hedy 以一名受治理、本地部署的 AI 员工身份撰写 PRD，而不是一个云端助手。它先做五问式需求收集，综合成结构化的 §0-6 草稿，再切换到工程模式补全技术契约，最后进入评审模式挑战缺口。任何危及真实资产的动作——删除文档、覆写工单、群发消息——都会撞上默认拒绝的白名单并被硬性拒绝。一名 Hedy 负责整个 PRD 工作流：自部署、只增不改审计、来源可引。
最后更新：2026 年 7 月 20 日
问题、入口、最小范围、涉及系统、参考资料。一轮提问，拿到大部分信息量。
从背景写到验收用例——范围以“我们不做什么”的成对条目给出，每条都附理由。
按需启用：鉴权链路、错误码、幂等与事务边界——对照硬性清单逐项检查。
把 Hedy 指向一份现有 PRD，得到按严重程度排序、按章节标注的问题清单。
多数 AI 写作工具止步于生成文字。Hedy 以一名员工的身份跑完整个 PRD 工作流。它以五问式需求收集开场——问题、用户、范围、约束、成功指标——而不是靠猜。随后综合成一份覆盖 §0-6 的结构化文档：背景、目标、用户、范围、功能需求、非目标与待定问题。产出是一份团队可以评审的真正 PRD 骨架，而不是一堵文字墙。一名 Hedy 覆盖了过去由需求收集 PM、规格撰写者和评审者分担的工作。
工作按模式推进。成稿模式下，Hedy 依据访谈回答组装 §0-6。工程模式下，它补全技术契约——数据结构、API 接口面、边界情况、依赖与上线约束——让规格可实现，而非停留在愿景。评审模式下它转为对抗姿态：重读自己的草稿，标出缺失的非目标、含糊的验收标准与未言明的假设。由于 Hedy 自部署在您的基础设施上、使用您自己的模型 key（包括本地 vLLM 或 Ollama），整份 PRD 绝不离开您的网络，也没有数据次级处理方（sub-processors）。
治理就是产品本身，而不是一个设置项。当 PRD 工作触及真实资产——删除 Confluence 页面、覆写 Jira epic、向频道群发消息——Hedy 不会继续执行。写操作按白名单默认拒绝运行，任何未列入名单的副作用都是硬性拒绝，而不是一句可以被说服绕过的软性警告。这条限制落在配置与代码层，而不是提示词里，因此无法被提示词注入绕开。检索遵循提问者的 ACL，为某位请求者组装的 PRD 绝不会呈现其无权查看的文档。
每一步都可追责。动作写入只增不改审计日志——没有编辑接口，也没有删除接口。较高风险的操作要经过 L0/L1/L2 审批分级；Hedy 的证据门要求 PRD 中的事实性表述逐字引用来源，需求可以追溯到它所来自的访谈回答或文档。飞书/Lark 与 Slack 同为一级支持渠道；部署是约 30 分钟的 Docker Compose 安装，按席位授权，采用离线 Ed25519 许可。