team-prd-to-alignment

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，先应用目录访问边界，再进入材料生成流程。

受众优先级

默认受众顺序：

1. 研发负责人。
2. 产品负责人。
3. 项目管理。
4. 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 修正。

工作流

1. 确定 slug 或 PRD 文件路径。
2. 读取 PRD，提取目标、范围、非目标、用户场景、验收标准、风险和开放问题。
3. 读取全局上下文、全局决策记录，以及同 slug 的规格细化、评审报告、局部上下文和局部产品决策记录。
4. 对比 PRD 与上游材料，识别裁剪、变化、冲突和仍需人类确认的问题。
5. 判断需求类型，并选择本次材料应强调的章节。
6. 提炼 1-3 个关键设计决策；证据不足时列为风险或待决问题。
7. 按演示文稿式结构生成对齐材料，优先使用短段落、列表和明确标题。
8. 按 Blocker / Risk / Discussion 分级整理冲突和待决问题。
9. 按“人类写作风格”复核并改写材料，删除空泛判断、模板句式、聊天痕迹和无证据推断。
10. 将材料写入 team-spec/active/{slug}/prd/alignment.md。
11. 输出摘要，并建议用户用该材料组织需求、研发和项目管理对齐讨论。

生成过程中如发现 PRD 存在逻辑矛盾、范围不清、验收标准缺失或无法支撑工程拆解，应在 ## 8. 风险与待决问题 中明确列出，不要自行补齐。

评审会材料应优先帮助会议快速完成四个判断：

1. 这个需求是否值得做。
2. 本次范围是否一致。
3. 风险是否可接受。
4. 是否 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。