| name | team-prd-to-alignment |
| description | 将结构化 PRD 转换为适合需求、研发和项目管理评审的对齐材料。Turn structured PRDs into alignment materials for product, engineering, and project management review. |
| license | MIT |
| metadata | {"author":"coolbeevip","version":"1.0"} |
| triggers | ["PRD 对齐材料","PRD 转评审材料","生成需求研发对齐文档","PRD 给人看","需求研发对齐","生成评审会材料","PRD alignment material","turn PRD into review material","create PRD alignment deck","make PRD human readable","product engineering alignment","create review meeting material"] |
PRD 转对齐材料
这个技能用于把 team-spec-to-prd 生成的 AI 结构化 PRD，转译为适合需求、研发和项目管理人员阅读、评审和达成共识的对齐材料。它解决的问题是：PRD 可以作为 team-prd-to-issues 的机器输入，但不一定适合作为人类评审会的沟通材料。
默认输出是 Markdown，但内容组织应接近演示文稿或评审会材料：结论先行、信息分层、每一节都能支撑一次讨论。它不是 PRD 的替代品，也不是工程拆解技能。
触发边界
- 适合触发：PRD 已存在，但需要转换为人类评审、会议对齐或需求研发沟通材料。
- 不适合触发：用户要固化 PRD 时，转交
team-spec-to-prd；用户要拆工程 issue 时，转交 team-prd-to-issues。
运行时配置
统一读取目标项目根目录 team-spec/config.yml：
language: zh-CN
access_policy:
mode: default-readonly
directory_file: team-spec/access_policy/default.md
user_file_template: team-spec/access_policy/{user_name}.md
语言优先级：用户本轮明确指定 > team-spec/config.yml > 首次询问并落盘。若配置不存在，不报错，走"询问并创建"流程。
执行要求：
- 对话回复与对齐材料
team-spec/active/{slug}/prd/alignment.md 均使用 language。
- 用户临时切换语言时，本次立即生效，并询问是否回写配置。
- 在读取 PRD、规格、评审或代码前，先读取
team-spec/config.yml；如果存在 access_policy，先应用目录访问边界，再进入材料生成流程。
受众优先级
默认受众顺序：
- 研发负责人。
- 产品负责人。
- 项目管理。
- QA、运维、安全或其他相关角色。
输出时优先帮助研发快速理解系统边界、数据边界、风险、迁移影响和工程可行性，而不是复述完整业务背景。产品关注范围、用户价值和 tradeoff；项目管理关注依赖、节点和 blocker；QA、运维和安全只在需求相关时纳入重点。
输入物
主输入：
team-spec/active/{slug}/prd/prd.md。
参考输入：
team-spec/active/{slug}/spec/refine.md：规格细化产物，用于理解原始诉求和关键背景。team-spec/active/{slug}/spec/reviews.md：规格评审报告，用于提取风险、阻塞项和待决问题。team-spec/CONTEXT.md：跨需求产品语境，用于保持术语、角色和通用业务规则一致。team-spec/decisions/：跨需求产品决策记录，用于说明长期有效的范围裁剪和重要决策。team-spec/active/{slug}/spec/CONTEXT.md：当前需求局部上下文。team-spec/active/{slug}/spec/decisions/：当前需求局部产品决策记录。- 相关设计稿、业务文档、历史 PRD、研发方案或讨论记录。
如果无法唯一确定 {slug}，应停止并要求用户提供 PRD 路径或 slug，不得猜测。
输出物
team-spec/active/{slug}/prd/alignment.md：面向人类对齐的演示文稿式评审材料。- 对话中的材料摘要：目标、关键范围、待决问题和建议评审关注点。
对齐材料不修改 PRD 内容。PRD 仍是工程拆解的权威输入；对齐材料用于帮助人类快速理解、讨论和确认 PRD。
好的对齐材料应满足：
- 非作者也能快速理解需求核心变化。
- 能直接支撑评审会讨论，而不是要求参会者先完整阅读 PRD。
- 能帮助发现范围误解、工程边界误解和未决策项。
- 能暴露风险、冲突和需要升级的问题。
- 不把 PRD 重写成更长的口语版。
对齐材料结构
输出文档应使用清晰的章节编号，尽量做到每一节都像一页评审材料。
# {需求名称} 对齐材料
## 1. 目标
用 1-2 句话说明这个需求要解决什么问题，以及本次交付会带来什么变化。
## 2. 背景与现状
说明当前用户、业务或系统遇到的问题，以及为什么现在需要处理。
## 3. 本次做什么
- 范围内事项 1
- 范围内事项 2
- 范围内事项 3
## 4. 本次不做什么
- 明确非目标 1
- 延后事项 1
## 5. 用户路径变化
用用户视角说明体验、流程或操作路径会如何变化。
## 6. 关键设计决策
列出本需求最重要的 1-3 个产品或架构决策。每条说明为什么这样设计、为什么不选择其他方案，以及带来的收益和限制。
## 7. 研发需要关注什么
列出数据、权限、接口、状态流转、兼容性、迁移、监控、回滚等研发需要提前确认的事项。
## 8. 风险与待决问题
按 Blocker / Risk / Discussion 分级列出需要人类讨论或确认的问题，每条说明影响范围和建议决策人。
## 9. 对齐结论
记录本次评审后的结论、仍需补充的材料和有序号的下一步可选项。
写作原则
- 面向人类对齐：优先让需求、研发和项目管理能快速理解和讨论，不照搬 PRD 的机器化字段。
- 结论先行：先讲这个需求为什么重要、要改变什么，再展开范围、路径和风险。
- 少字段，多叙述：把 PRD 中的结构化内容转译成自然语言，不要堆砌模板字段。
- 信息去重：同一个事实尽量只出现一次。背景解释“为什么”，范围解释“做什么”，用户路径解释“用户如何变化”，风险解释“哪里仍不确定”。
- 保留分歧：如果 PRD、规格细化和评审报告之间存在冲突，必须显式列入风险或待决问题，并标明严重程度。
- 不替代 PRD：不要改变 PRD 的权威内容；发现 PRD 缺陷时，在对齐材料中指出，并建议回到对应上游技能修正。
- 适合会议使用：每一节应能在评审会上直接展开讨论，避免长篇背景堆叠。
人类写作风格
对齐材料应像一位熟悉需求的同事写给评审会的材料，避免把 PRD 换一种格式机械复述。写作时先保留事实和判断，再清理机器化表达。
必须遵守：
- 直接写事实和影响，不用“标志着”“体现了”“至关重要”“全面提升”“持续赋能”这类泛化判断。
- 能说清楚具体变化时，不写抽象价值。例如写“新增审批状态和失败重试入口”，不要写“提升流程可控性和用户体验”。
- 少用固定三段式。不要为了显得完整，机械凑出三项收益、三类风险或三步路径；有两项就写两项，有四项就写四项。
- 避免聊天式铺垫和总结语，例如“下面我们来看”“值得注意的是”“总而言之”。材料本身就是结论，不需要解释自己在做什么。
- 归因要具体。能指向 PRD、评审报告、决策记录或用户原话时，直接写来源；证据不足时写成待确认，不写“相关方认为”“业界通常认为”。
- 正向定义职责和边界。默认禁用“不是……而是……”“不仅……还……”这类反向定义句式；只有必须纠正已出现的误解时才使用，并且同一章节最多出现一次。
- 少用粗体和“短标签：说明”的列表。只有会议上需要快速定位的结论、风险等级或决策项才加粗；普通段落用自然句。
- 句子长短要有变化。关键结论可以短，背景和取舍可以稍长；不要让每个项目都长得一样。
- 不写漂亮但空的结尾。结论必须落到“是否同意范围”“谁来确认”“是否进入工程拆解”等具体动作。
生成后必须快速自检并改写：
- 是否有可删除的开场白、过渡词或口号。
- 是否有连续多个项目使用同一种句式。
- 是否出现“不是……而是……”“不仅……还……”这类反向定义；能改成正向定义时必须改写。
- 是否有只表达态度、不提供事实的形容词。
- 是否有 PRD 中没有证据支撑的推断。
- 是否有过度格式化的粗体、冒号列表或模板化标题。
页级约束
每个章节默认应像一页评审材料：
- 能在 2-5 分钟会议讨论内完成。
- 正文优先控制在约 300-500 字以内。
- 优先使用列表、表格和短段落，避免长篇叙述。
- 避免重复 PRD 细节，只抽取对评审决策有帮助的信息。
- 如果内容过多，应压缩为结论、影响和待确认项，而不是继续展开背景。
关键设计决策提炼
必须从 PRD、规格细化、评审报告和产品决策记录中提炼 1-3 个最重要的设计决策。这里的“设计决策”可以是产品边界、系统边界、数据事实源、权限模型、迁移策略、兼容策略或 AI 工作流契约。
每个决策应包含：
- 决策：本次选择了什么。
- 原因：为什么这样选。
- 取舍：为什么不选择明显备选方案。
- 影响：带来的收益、限制、迁移成本或后续约束。
如果材料中没有足够证据支持某个设计决策，不要发明；改为在风险或待决问题中说明“关键设计决策缺失”。
冲突分级
冲突和未决问题必须按严重程度区分：
Blocker：无法进入工程拆解或会导致工程方向错误，必须回到上游修正或由决策人确认。Risk：可以进入开发，但存在实现、迁移、质量、合规或交付风险，需要跟踪缓解。Discussion：适合评审会确认的问题，不阻塞当前阶段，但需要记录结论。
不要把所有问题都泛化为“风险”。每条都应说明影响范围、建议决策人和建议处理方式。
研发检查维度
生成 ## 研发需要关注什么 时，至少检查以下维度，并只保留与本需求相关的项：
- 数据模型与事实源。
- 权限边界与审计。
- 状态流转与异常状态。
- API、事件、任务或外部系统契约。
- 兼容性、迁移和数据回填。
- 回滚、灰度和降级。
- 并发、幂等和资源限制。
- 安全、隐私和合规。
- 可观测性、告警和运营支持。
- 测试入口、验收方式和回归范围。
需求类型适配
不同需求类型应调整强调重点：
- 基础设施类：强调迁移、兼容性、回滚、资源限制和可观测性。
- 用户功能类：强调用户路径变化、范围边界、非目标和验收方式。
- 平台能力类：强调系统边界、依赖关系、接口契约和权限模型。
- AI 工作流类：强调输入输出契约、提示词或工具边界、失败兜底和可评估性。
- 安全与合规类：强调权限、审计、威胁面、数据保留和合规责任。
禁止事项
禁止：
- 发明 PRD 中不存在的新功能。
- 擅自补齐未定义行为。
- 修改 PRD 范围、非目标或验收标准。
- 推断未确认需求并写成确定结论。
- 把上游材料中的冲突私自合并成一个“看起来合理”的版本。
发现缺口时，应记录为 Blocker、Risk 或 Discussion，或建议回到 team-spec-to-prd、team-spec-review、team-spec-refine 修正。
工作流
- 确定 slug 或 PRD 文件路径。
- 读取 PRD，提取目标、范围、非目标、用户场景、验收标准、风险和开放问题。
- 读取全局上下文、全局决策记录，以及同 slug 的规格细化、评审报告、局部上下文和局部产品决策记录。
- 对比 PRD 与上游材料，识别裁剪、变化、冲突和仍需人类确认的问题。
- 判断需求类型，并选择本次材料应强调的章节。
- 提炼 1-3 个关键设计决策；证据不足时列为风险或待决问题。
- 按演示文稿式结构生成对齐材料，优先使用短段落、列表和明确标题。
- 按 Blocker / Risk / Discussion 分级整理冲突和待决问题。
- 按“人类写作风格”复核并改写材料，删除空泛判断、模板句式、聊天痕迹和无证据推断。
- 将材料写入
team-spec/active/{slug}/prd/alignment.md。
- 输出摘要，并建议用户用该材料组织需求、研发和项目管理对齐讨论。
生成过程中如发现 PRD 存在逻辑矛盾、范围不清、验收标准缺失或无法支撑工程拆解，应在 ## 8. 风险与待决问题 中明确列出，不要自行补齐。
评审会材料应优先帮助会议快速完成四个判断：
- 这个需求是否值得做。
- 本次范围是否一致。
- 风险是否可接受。
- 是否 ready for engineering。
完成标准
team-spec/active/{slug}/prd/alignment.md 已生成。- 材料能让需求、研发和项目管理快速理解背景、范围、非目标、用户路径变化和研发关注点。
- 已包含 1-3 个关键设计决策；如果无法提炼，已说明缺失证据。
- 风险与待决问题已按 Blocker / Risk / Discussion 分级列出，并包含影响范围或建议决策人。
- 每节遵守页级约束，没有把 PRD 重写成长篇口语版。
- 语言自然、克制、具体，没有明显 AI 腔、口号化表达、机械三段式或过度粗体。
- 明确说明 PRD 仍是
team-prd-to-issues 的权威输入，对齐材料只服务于人类讨论。
- 如果发现 PRD 需要修正，已建议回到
team-spec-to-prd 或更上游技能处理。
最终回复
必须包含：
- 对齐材料路径和 slug。
- 目标受众、评审目标和材料是否可进入人类对齐。
- Blocker、Risk、Discussion 的摘要及待决责任人。
- PRD 是否需要返回上游修订。
- 有序号的下一步选项：进入对齐评审、返回上游修订，或基于权威 PRD 执行
team-prd-to-issues。
