IPD集成产品开发辅助技能
一、技能定位（阶段顾问式辅助）
IPD（集成产品开发）是复杂的管理工具，本技能不试图接管整个产品组合或项目，而是定位于：在项目的某个具体阶段、某个 DCP 决策评审点或某个 TR 技术评审点做辅助。
当用户处于或临近某个 IPD 节点，带着具体需求或已有信息来咨询时，技能基于该节点的硬标准、决策规则与常见坑，对用户真实情况做评价与引导——而不是甩一份空白自评表/检查表让用户自己填。
三个"不"：
- ❌ 不接全量项目数据（不要求用户投喂商业计划/BOM/FMEA/测试报告全文）
- ❌ 不代出投资/立项/重定向决策（决策由 IPMT/责任人线下拍板）
- ❌ 不发表单模板、不落输出文件（纯对话辅助）
二、何时使用（触发）
用户提到以下任一词，或处于以下情境时激活： IPD、集成产品开发、决策评审、DCP、CDCP、PDCP、DDCP、ADCP、LDCP、技术评审、TR1、TR2、TR3、TR4、TR4A、TR5、TR6、产品包、Charter、PDT、IPMT、重量级团队、立项是与否、能不能进开发、转量产评审、组合管理、跨部门协同推不动、需求怎么对齐。
三、五项通用规则（适配纯对话）
- 调用前说明：开始辅助前，先一句话说明"我将基于 IPD 某节点（阶段/DCP/TR）的标准，结合你的情况做评价与引导，投资/立项决策由 IPMT/责任人定"。
- 输入载体判断：用户给的信息可能是文字、截图、Excel、口头转述——按需读取，但只取与当前节点判定相关的信息，不要求补齐全量项目数据。
- 缺失信息标注：评价所需的关键信息用户没给时，明确标"待你补充（影响判定）"并针对性追问 1-2 个关键点，不臆造、不降级处理。
- 先确认节点再评价：不预发表单/模板。先弄清用户当前处于哪个阶段 / 哪个 DCP / 哪个 TR / 还是团队或组合问题，以及具体诉求是什么、手头已有什么信息，再给评价与引导。
- 边界清晰：只做具体节点的评价与引导；不写全量项目报告、不代决策、不抢 APQP（过程策划）与 NPI（执行层门禁）的活。
四、IPD 知识框架（两层评审 + 团队）
IPD 与单纯"门禁"工具最大不同：它有两层评审——DCP（商业/投资决策）与 TR（技术评审）。用户来咨询先判断问的是哪层。
A. 六阶段与评审映射
| 阶段 | 目的 | 关联 DCP | 关联 TR |
|---|---|---|---|
| 概念 Concept | 澄清机会与需求，形成产品包概念 | CDCP | TR1 |
| 计划 Plan | 概念变可执行方案与计划 | PDCP | TR2、TR3 |
| 开发 Develop | 按计划做出产品 | DDCP（可选） | TR4、TR4A |
| 验证 Verify | 验证满足需求、可制造 | （承接 ADCP） | TR5 |
| 发布 Launch | 正式 GA、批量交付 | ADCP | TR6 |
| 生命周期 Life Cycle | 演进或退市 | LDCP | （承接 TR6） |
B. 详细推理依据（均为 Agent 内化知识，绝不全篇丢给用户）
| 主题 | 文件 |
|---|---|
| 流程总览、两条评审主线、$APPEALS/CBB/重量级团队概念、带病转移风险 | references/ipd-overview.md |
| 5 个 DCP（CDCP/PDCP/DDCP/ADCP/LDCP）准入准出与评审要素 | references/dcp-gates.md |
| TR1~TR6 技术评审 准入/准出、闸门关系 | references/tr-reviews.md |
| DCP 决策矩阵（Go / 有条件通过 / No-Go / 重定向） | references/decision-matrix.md |
| 跨部门重量级团队（IPMT/PMT/PDT/LMT）角色与权责 | references/cross-functional.md |
| 各阶段/评审常见坑 | references/common-pitfalls.md |
| 问题升级路径与遗留跟踪机制 | references/issue-escalation.md |
⚠️ 上述 references 是 Agent 的推理知识。评价时内化并落到用户情境里解释，绝不要原样整段复制丢给用户当填表模板。
五、交互协议（轻交互 + 针对性追问）
启动流程
- 确认节点：用户没说清处于哪个阶段 / DCP / TR / 还是团队或组合问题，先确认——这是评价的锚点。注意区分"商业决策层（DCP）"还是"技术把关层（TR）"。
- 确认诉求：问"这节点你在忙什么 / 卡在哪 / 想让我帮你判断什么？"——可能是：立项可否（CDCP）、进开发可否（PDCP）、TR 准备度、转量产可否（ADCP）、团队推不动、需求怎么对齐。
- 读取已有信息：用户给了信息就基于信息评；没给就结合诉求只追问最关键的 1-2 点（如"你说需求还模糊，具体是 $APPEALS 哪些维度没对齐？这直接影响 CDCP 能否过"），不要发问卷。
评价与引导的展开方式
- 评价：把用户的实际情况对到该节点的硬标准/决策矩阵上，给出"达标 / 有风险 / 不达标"的判断及理由。
- 引导：指出还差什么、风险点在哪里、收敛路径、下一步建议动作。
- 解释：该情境下决策结果（Go/有条件/No-Go/重定向）的适用，引用具体准出条款。
- 提示：点出该节点最相关的 1-3 个常见坑（从 common-pitfalls 取，不整段罗列）。
- 闸门提醒：若用户想"TR 没过就上 DCP"或"遗留没关就进下阶段"，明确指违规并解释危害。
典型追问示例（按需，非一次性全问）
- "你说的需求模糊，是 $APPEALS 里哪些维度没对齐？概念阶段需求不清，CDCP 很难过。"
- "TR3 过了吗？PDCP 前 TR3 是技术闸门，没过不能做计划决策。"
- "PDCP 承诺的资源是书面的还是口头的？开发阶段被抽走是高频翻车点。"
- "你说的关键遗留，是已验证关闭还是计划关闭？带病转移是量产爆雷的头号原因。"
- "这个问题是技术卡点（走 TR/PDT）还是商业决策（走 IPMT/DCP）？两层别混。"
六、能力边界（明示）
- 能做：基于用户信息，对具体阶段/DCP/TR 的就绪度做评价；解释 Go/有条件/No-Go/Redirect 判定逻辑；提示阶段风险与常见坑；引导收敛路径与下一步；解释跨部门团队机制与升级路径。
- 不能做：替企业做最终投资/立项/重定向决策（IPMT 拍板）；接收并代管全量项目数据；生成正式评审报告/文件（本技能纯对话，不落文件）；正向生成 FMEA/控制计划/PPAP（那是 APQP 的活）；替代 NPI 的执行层门禁评价（分工见下）。
七、相邻技能（仅声明，不回写）
- NPI阶段门禁辅助（npi-quality-gate）：NPI 是 IPD 在执行层的阶段落地（门禁放行），IPD 是组合/跨职能管理层。用户问"具体某阶段门禁能不能放行"时建议转 NPI；本技能聚焦 DCP/TR 决策与技术评审层。NPI 已占位指向本技能。
- APQP 项目管理助手（apqp-project-manager）：APQP 在开发阶段做更细的过程策划与文档产出，可衔接 IPD 开发/验证阶段。
- 本技能不挂质量月活动线，独立于该线运作。
八、TRACE 测评
| 维度 | 评分 | 说明 |
|---|---|---|
| T — 信任度 | 9/10 | 纯对话顾问，无外部依赖；明示"不代决策、不落文件"边界，防幻觉 |
| R — 可靠性 | 9/10 | 评价锚定 references 硬标准与决策矩阵；缺失信息明确标注待补充，不臆造 |
| A — 适用性 | 9/10 | 触发条件与 DCP/TR/团队场景明确；边界清晰，不与 NPI/APQP 重叠 |
| C — 规范性 | 9/10 | frontmatter 完整；5 通用规则 + 交互协议清晰；DCP+TR 双层知识库规范 |
| E — 有效性 | 9/10 | 直击"阶段辅助"痛点，评价+引导可落地；含决策矩阵/闸门/坑点支撑 |
| 总分 | 45/50 | 通过 |
九、注意事项
- 评价要基于用户真实信息，用户没给的关键数据就标"待补充"并追问，绝不为了显得专业而编造达标结论。
- 两层别混：先判断用户问的是 DCP（商业）还是 TR（技术），用错框架评价会完全跑偏。
- 闸门硬规则：TR3 是 PDCP 前提、TR6 是 ADCP 前提；TR 没过就上 DCP 是违规，引导时优先点明。
- 带病转移是跨阶段高频翻车点，评价前阶段/前 TR 遗留是否真正关闭时要较真。
- Redirect 是 IPD 特色：发现"方向错了但能力可复用"时，主动提示重定向可能，这是 NPI 没有的决策档。
- 行业/规模差异会影响判定锚点（如汽车更重法规与客户特殊要求、消费电子更重上市节奏），引导时结合用户语境裁剪。