plan-devex-review

开发者体验计划评审

改进 API、CLI、SDK、库、开发者平台或其文档的计划。没有面向开发者的界面的策略文档，无需进行八轮 DX 评审。

范围与节奏

阅读提供的计划和相关现有实现。对于仅涉及计划的请求，不要求创建分支。对于混合请求，也要固定所请求的差异。保留已确定的约束、受保护路径和先前决策。

遵循用户要求的交互模式。否则，将相互独立的发现合并处理，只针对确实尚未解决且会影响范围或设计的选择提问。若用户要求改进，直接修正明显的计划问题；若用户只要求报告，则不做修改。立即遵循“跳过问题”的要求，说明假设并继续开展有用工作。假设不代表获准变更范围。不要重复询问已经做出的决定。

评审计划，而非实现：不要修改源代码、提交、推送或创建远程任务。相关验收标准得到满足后即停止，否则报告剩余阻碍。评分只是可选的总结，不是要求反复润色到 10/10 的目标。

模式与准备

模式	必需的评审范围	可选的探索
DX TRIAGE	第 1 轮和第 3 轮；仅关注安装和首次成功结果	不进行竞品调研或广泛的用户画像分析
DX POLISH	所有适用轮次，且限于现有界面范围	仅调查会影响决策的缺失背景信息
DX EXPANSION	所有适用轮次，外加拟议的机会	有针对性的竞品调研和更广泛的用户旅程探索

本表具有最终效力。Triage 减少的是工作量，而不仅是展示的发现。采用用户指定的模式；否则，范围较窄的变更选择 TRIAGE，完整界面选择 POLISH。范围明确时，简要说明选择，无需征求确认。

根据现有证据，确定实际使用者、任务、受支持的环境和首个有用结果。重用用户已提供的答案。对于增量工作，从界面和失败路径入手。叙事型用户画像、神奇时刻或竞争基准并非前提。

评审

仅阅读 checks.md 中选定的轮次。如可运行，记录命令、输出和观察到的摩擦。没有证据时，绝不声称亲自体验过引导流程、用户放弃使用、基准测试耗时或采用率。将模拟的用户旅程标注为假设；无法执行的运行时检查标记为未经验证。

对于每个真实问题，提供证据、影响、建议的修正和验证方式。评分可以用于表达评估结果，但不作为完成门槛，也不要求润色到 10 分。扩展提案在获批前始终是可选项。只进行一轮修正并验证；仅当仍有验收失败或用户提出新要求时才继续。

交付

更新用户要求的计划，或返回一份报告。说明已评审和省略的轮次、实际使用者／任务、重要发现、已接受的变更、未解决的决策以及具体的验收检查。根据范围给出 READY、NEEDS DECISIONS 或 INCOMPLETE。不要为了提高评分而创建无关的 SDK、社区项目、主题或托管式 Playground。