Framing problems before building

先定义问题，再开始构建

这个 skill 用来处理一种高频情况：用户拿到 Cursor 后直接开始“乱问”，但其实问题本身还没有定义清楚。
目标不是立刻给实现，而是先把问题收敛成一个能被可靠执行的任务。

与 Harness / Skill 的分工

• Harness：负责强制流程、阶段切换、状态保存、校验、重试、阻止越级执行。
• Skill：负责提供分析方法、提问框架、输出模板和判断标准。
• 本 skill：专注于“先定义问题，再决定是否进入方案或实现”这一步。

如果某个团队总会反复遇到“问题没定义清楚就开做”的情况，说明可以考虑把本 skill 的流程进一步下沉到 harness，做成强制入口。

核心原则

1. 先判断阶段，再决定动作。不要在“问题阶段”直接跳到“实现阶段”。
2. 先收敛问题，再讨论方案。如果目标都不清楚，不要产出代码方案。
3. 明确未知项。不替用户偷偷补全关键前提。
4. 约束先于实现。先写清不能做什么、必须满足什么。
5. 成功标准必须可检验。避免“做得更好”“更智能”这类空目标。

四阶段模型

先判断用户当前处于哪一阶段：

1. 想法阶段
   • 只有方向、感受、抱怨或灵感
   • 还说不清具体问题是什么
2. 问题阶段
   • 已经知道“哪里不对”，但还没收敛成明确任务
   • 常见表现是目标、约束、成功标准不完整
3. 方案阶段
   • 已经能比较方案、讨论架构、拆步骤
   • 可以开始写计划，但还不一定该写代码
4. 实现阶段
   • 任务边界明确
   • 可以编码、验证、评审、交付

如果判断为 想法阶段 或 问题阶段，默认不要直接进入实现建议。

固定流程（必走）

按下面顺序执行，不要跳步。

第 1 步：用一句话重述用户真正想解决的问题

输出一个工作定义：

• 用户表面上在问什么
• 用户真正卡住的是什么
• 为什么这个问题值得解决

如果一句话都说不顺，说明问题还没定义好。

第 2 步：判断当前阶段

从四阶段模型中选一个，并给出一句理由：

• 为什么还只是想法
• 为什么已经进入问题
• 为什么已经足以讨论方案
• 为什么可以直接实现

第 3 步：抽取五个关键字段

必须逐项填写；缺失就明确标记“未知”。

1. 目标
   • 最终想达成什么
2. 现状
   • 现在发生了什么，已有条件是什么
3. 约束
   • 时间、技术、流程、资源、质量、安全、团队边界
4. 成功标准
   • 什么结果算完成，最好可验证
5. 未知项
   • 当前还不确定、需要确认、不能假设的部分

第 4 步：识别用户是否在混淆三类内容

检查用户有没有把下面三类东西混在一起：

• 问题定义
• 解决方案
• 实现细节

如果混淆了，要拆开说清：

• 现在已经明确的是哪一层
• 还没明确的是哪一层
• 不应该提前进入的是哪一层

第 5 步：判断约束应该放在哪一层

把已有约束分到下面三类：

• 放在 harness
  • 必须被强制执行
  • 依赖运行时状态
  • 涉及校验、重试、分支、权限、阶段门禁
• 放在 skill
  • 属于可复用的方法论
  • 是提问框架、判断规则、输出模板、检查清单
• 只保留为当前上下文
  • 一次性背景
  • 变化快
  • 尚未稳定，不值得沉淀

第 6 步：决定下一步，不提前跳级

只能从下面四类里选一个主建议：

1. 继续澄清问题
2. 进入方案设计
3. 进入实现
4. 沉淀为可复用 skill / harness

如果主要问题还没定义清楚，不要建议“直接开始做”。

输出格式

默认用这个结构：

## 当前判断
- 当前阶段：[想法阶段 / 问题阶段 / 方案阶段 / 实现阶段]
- 一句话定义：[用一句话重述真正的问题]

## 五字段收敛
- 目标：[一句话]
- 现状：[一句话或两句话]
- 约束：[要点列表]
- 成功标准：[可验证结果]
- 未知项：[仍需确认的内容]

## 分层建议
- 放到 harness：[内容]
- 放到 skill：[内容]
- 仅保留在当前上下文：[内容]

## 下一步
- 建议动作：[继续澄清问题 / 进入方案设计 / 进入实现 / 沉淀为 skill 或 harness]
- 理由：[为什么]

追问规则

当信息不足时，优先追问最关键的缺口，不要一次抛太多开放问题。

优先级顺序：

1. 先问目标
2. 再问成功标准
3. 再问约束
4. 最后问实现偏好

避免这类低质量推进：

• “我先给你写个方案吧”
• “我大概理解了”
• “可以先做一个 MVP”

除非目标、边界和成功标准已经足够明确。

什么时候建议做成 Harness

当出现以下情况时，明确建议考虑 harness：

• 每次都要走同一套阶段门禁
• 不能允许 agent 直接跳到实现
• 需要强制校验输入完整性
• 需要状态跟踪、重试或审批
• 团队希望把流程标准化，而不是靠临场发挥

什么时候建议只做成 Skill

当出现以下情况时，优先建议 skill：

• 主要缺的是思考方法，而不是执行控制
• 用户问题高度模糊，需要稳定的收敛框架
• 输出格式和分析步骤可以复用
• 不依赖复杂状态机或外部系统

例子

输入

“我在想 harness 和 skill 能不能结合起来。很多工程师拿到 Cursor 就一顿乱问，最后自己要解决什么问题也不清楚。我想把这件事变得更可控。”

输出

## 当前判断
- 当前阶段：问题阶段
- 一句话定义：用户想解决的是“工程师在使用 Cursor 时，经常在问题尚未定义清楚时就进入执行，导致 agent 输出发散和低效”。

## 五字段收敛
- 目标：让 agent 在进入方案或实现前，先把问题定义收敛清楚。
- 现状：用户已经观察到高频混乱场景，但还没有固定的收敛流程。
- 约束：
  - 需要适配 Cursor 使用场景
  - 不能让流程过于重
  - 最好能沉淀成可复用资产
- 成功标准：用户能先得到结构化问题定义，再决定是否进入方案、实现或沉淀为 skill / harness。
- 未知项：
  - 这个流程是否只给个人用，还是给团队统一用
  - 是否需要系统级强制门禁

## 分层建议
- 放到 harness：
  - 禁止在信息缺失时直接进入实现
  - 记录阶段状态
  - 对输入完整性做校验
- 放到 skill：
  - 四阶段模型
  - 五字段收敛法
  - 输出模板
- 仅保留在当前上下文：
  - 当前团队的具体使用习惯

## 下一步
- 建议动作：沉淀为 skill，并视复用频率再升级为 harness
- 理由：当前最缺的是稳定的问题收敛方法，先用 skill 验证最小流程更合适。

自检清单

• 有没有先判断阶段，而不是直接给方案
• 有没有写出一句话问题定义
• 五字段是否完整
• 未知项是否被显式写出
• 是否区分了 harness、skill、上下文三层
• 下一步建议是否没有越级