用途：把模糊想法转成可构建的规格说明、PRD、缺陷报告或项目范围界定。适用场景包括需求转化、写 PRD、提可执行缺陷、开工前界定范围、功能请求排序、为已有功能写验收标准、把大型计划拆成可交付增量。不适用于跨多项计划的季度规划、代码审查与调试、已定规格的设计决策、验证想法的用户研究。
必要输入：想法或问题、受影响的用户、已有约束（技术栈、期限、依赖）、成功指标。若想法模糊，第一步先澄清，不围绕模糊点写规格。
工作流四阶段：一、澄清想法，回答四个问题：解决什么用户问题、具体谁受益、成功指标是什么、为何是现在；任一答不出就回到用户。二、按影响与成本评估：高影响低成本立即做，高影响高成本规划并批量处理，低影响低成本列可选批次，低影响高成本跳过或推迟；合规、无障碍、安全等强制项需标注例外。三、选择格式写作：功能规格含标题、问题、用户、提案、用户故事、验收标准、范围外、依赖、成功指标、工作量、优先级；开发简报含背景、任务、约束、验证；缺陷报告含 URL 或上下文、症状、预期、复现步骤、假设、待查文件、优先级、浏览器或设备。四、排序与交付：单个功能先找最小可交付增量，先发布再迭代；待办列表先按依赖，再按优先级，再按影响与成本排序。
输出为三种 markdown 文件：spec-功能名.md、brief-任务名.md、bug-摘要.md；较大计划可放入 specs/计划名/ 文件夹，并附 README 说明概览与排序。参考文件包括功能规格模板、开发简报模板与 RICE、加权评分、MoSCoW 等排序框架。
常见失败模式：先写方案后写问题、缺少成功指标、验收标准不可测、混入“怎么做”而非“做什么”、没有范围外章节、缺陷报告缺复现步骤、验证步骤含糊、跳过最小可交付增量练习。