| name | framing-problems-before-building |
| description | 在用户问题还没想清楚、需求模糊、直接想让 Cursor 或 agent 开始实现时，先用固定流程澄清目标、现状、约束、成功标准与未知项，并判断当前处于想法、问题、方案还是实现阶段。适用于用户讨论 agent 工作流、harness、skill、约束、方法论、需求拆解或方案收敛时，帮助决定下一步是继续澄清、写计划、设计 harness，还是沉淀为 Cursor Skill。 |
先定义问题，再开始构建
这个 skill 用来处理一种高频情况：用户拿到 Cursor 后直接开始“乱问”，但其实问题本身还没有定义清楚。
目标不是立刻给实现，而是先把问题收敛成一个能被可靠执行的任务。
与 Harness / Skill 的分工
- Harness：负责强制流程、阶段切换、状态保存、校验、重试、阻止越级执行。
- Skill：负责提供分析方法、提问框架、输出模板和判断标准。
- 本 skill：专注于“先定义问题，再决定是否进入方案或实现”这一步。
如果某个团队总会反复遇到“问题没定义清楚就开做”的情况，说明可以考虑把本 skill 的流程进一步下沉到 harness，做成强制入口。
核心原则
- 先判断阶段，再决定动作。不要在“问题阶段”直接跳到“实现阶段”。
- 先收敛问题，再讨论方案。如果目标都不清楚，不要产出代码方案。
- 明确未知项。不替用户偷偷补全关键前提。
- 约束先于实现。先写清不能做什么、必须满足什么。
- 成功标准必须可检验。避免“做得更好”“更智能”这类空目标。
四阶段模型
先判断用户当前处于哪一阶段：
- 想法阶段
- 只有方向、感受、抱怨或灵感
- 还说不清具体问题是什么
- 问题阶段
- 已经知道“哪里不对”，但还没收敛成明确任务
- 常见表现是目标、约束、成功标准不完整
- 方案阶段
- 已经能比较方案、讨论架构、拆步骤
- 可以开始写计划，但还不一定该写代码
- 实现阶段
如果判断为 想法阶段 或 问题阶段，默认不要直接进入实现建议。
固定流程（必走）
按下面顺序执行，不要跳步。
第 1 步：用一句话重述用户真正想解决的问题
输出一个工作定义：
- 用户表面上在问什么
- 用户真正卡住的是什么
- 为什么这个问题值得解决
如果一句话都说不顺，说明问题还没定义好。
第 2 步：判断当前阶段
从四阶段模型中选一个，并给出一句理由：
- 为什么还只是想法
- 为什么已经进入问题
- 为什么已经足以讨论方案
- 为什么可以直接实现
第 3 步：抽取五个关键字段
必须逐项填写；缺失就明确标记“未知”。
- 目标
- 现状
- 约束
- 成功标准
- 未知项
第 4 步：识别用户是否在混淆三类内容
检查用户有没有把下面三类东西混在一起：
如果混淆了，要拆开说清：
- 现在已经明确的是哪一层
- 还没明确的是哪一层
- 不应该提前进入的是哪一层
第 5 步：判断约束应该放在哪一层
把已有约束分到下面三类：
- 放在 harness
- 必须被强制执行
- 依赖运行时状态
- 涉及校验、重试、分支、权限、阶段门禁
- 放在 skill
- 属于可复用的方法论
- 是提问框架、判断规则、输出模板、检查清单
- 只保留为当前上下文
第 6 步：决定下一步，不提前跳级
只能从下面四类里选一个主建议：
- 继续澄清问题
- 进入方案设计
- 进入实现
- 沉淀为可复用 skill / harness
如果主要问题还没定义清楚，不要建议“直接开始做”。
输出格式
默认用这个结构：
## 当前判断
- 当前阶段：[想法阶段 / 问题阶段 / 方案阶段 / 实现阶段]
- 一句话定义：[用一句话重述真正的问题]
## 五字段收敛
- 目标：[一句话]
- 现状：[一句话或两句话]
- 约束：[要点列表]
- 成功标准：[可验证结果]
- 未知项：[仍需确认的内容]
## 分层建议
- 放到 harness：[内容]
- 放到 skill：[内容]
- 仅保留在当前上下文：[内容]
## 下一步
- 建议动作：[继续澄清问题 / 进入方案设计 / 进入实现 / 沉淀为 skill 或 harness]
- 理由：[为什么]
追问规则
当信息不足时，优先追问最关键的缺口，不要一次抛太多开放问题。
优先级顺序：
- 先问目标
- 再问成功标准
- 再问约束
- 最后问实现偏好
避免这类低质量推进：
- “我先给你写个方案吧”
- “我大概理解了”
- “可以先做一个 MVP”
除非目标、边界和成功标准已经足够明确。
什么时候建议做成 Harness
当出现以下情况时，明确建议考虑 harness：
- 每次都要走同一套阶段门禁
- 不能允许 agent 直接跳到实现
- 需要强制校验输入完整性
- 需要状态跟踪、重试或审批
- 团队希望把流程标准化，而不是靠临场发挥
什么时候建议只做成 Skill
当出现以下情况时，优先建议 skill：
- 主要缺的是思考方法，而不是执行控制
- 用户问题高度模糊，需要稳定的收敛框架
- 输出格式和分析步骤可以复用
- 不依赖复杂状态机或外部系统
例子
输入
“我在想 harness 和 skill 能不能结合起来。很多工程师拿到 Cursor 就一顿乱问，最后自己要解决什么问题也不清楚。我想把这件事变得更可控。”
输出
## 当前判断
- 当前阶段：问题阶段
- 一句话定义：用户想解决的是“工程师在使用 Cursor 时，经常在问题尚未定义清楚时就进入执行，导致 agent 输出发散和低效”。
## 五字段收敛
- 目标：让 agent 在进入方案或实现前，先把问题定义收敛清楚。
- 现状：用户已经观察到高频混乱场景，但还没有固定的收敛流程。
- 约束：
- 需要适配 Cursor 使用场景
- 不能让流程过于重
- 最好能沉淀成可复用资产
- 成功标准：用户能先得到结构化问题定义，再决定是否进入方案、实现或沉淀为 skill / harness。
- 未知项：
- 这个流程是否只给个人用，还是给团队统一用
- 是否需要系统级强制门禁
## 分层建议
- 放到 harness：
- 禁止在信息缺失时直接进入实现
- 记录阶段状态
- 对输入完整性做校验
- 放到 skill：
- 四阶段模型
- 五字段收敛法
- 输出模板
- 仅保留在当前上下文：
- 当前团队的具体使用习惯
## 下一步
- 建议动作：沉淀为 skill，并视复用频率再升级为 harness
- 理由：当前最缺的是稳定的问题收敛方法，先用 skill 验证最小流程更合适。
自检清单
