unstuck

/unstuck — 突破困境的解药

将“做不到”转化为新的思路。先判断障碍的类型，再针对它使用合适的横向思维技巧，而且不会止步于第一个平庸的变通方案。输出要么是一组可行思路及后续行动，要么诚实地说明“这道墙承重，应该改道实现目标”。

两种模式：

• 用户主动调用 — 有人遇到困境并提出请求。使用下方完整的 7 步工作流。
• Agent 快速路径 — 你（Agent）在执行任务时遇到障碍。请参阅 Agent 快速路径 — 在告诉用户某件事做不到之前，先运行它。

心智模型：障碍各有类型，类型决定该用哪根撬棍

“做不到”是一种说法，不是事实。它几乎总能拆解成更弱的说法：成本高、违反规则、没人做过、我不知道怎么做。只有确实不可能（受物理定律、数学或算术限制）才会结束这次探索，而且要诚实地说明原因。

障碍类型	“做不到”实际上意味着什么	主要技巧（参见 references/techniques.md）
假设	没有人重新核实过的既有观念	T1 假设剖析，T3 第一性原理
框架	目标的表述方式排除了答案	T4 切换抽象层级，T2 逆向思考，T5 逆向推演
把关者	某个人或组织说了不行	T10 追问拒绝的原因，T6 类比迁移
工具／技术	“X 不支持 Y”	T9 SCAMPER（替换基本要素），T6 类比迁移
资源	时间、资金或人手不足	T7 调整限制条件，T8 挑衅式设想
物理／数学	确实不可能（罕见）	诚实地退出 — 改道实现目标，这道墙承重

第 1 步 — 捕捉障碍

从用户处获取以下信息（用一条结构化消息，不要来回追问）：

• 目标 — 你最终想做成什么？（不是受阻的那一步，而是它要实现的工作。）
• 障碍 — 究竟是什么在阻止你？
• 尝试过的方法 — 你已经试过什么？
• 拒绝的来源 — 是谁或什么说不行？物理定律？供应商文档？某个人？错误消息？你自己的假设？
• 利害关系和截止时间 — 突破这道障碍有多重要？需要在什么时候完成？

如果用户说“我什么都试过了”，就请他们列出清单。“什么都试过了”通常只指两三件事。

第 2 步 — 判断障碍类型

使用上方的分类法。说明分类结果及原因。遵循两条规则：

1. 拆解“做不到”这个说法。 不使用“做不到”来重述障碍：“成本高”“没有文档”“他们拒绝了”“我不知道怎么做”。重述通常会指出障碍的类型。
2. 继续之前，从两个抽象层级重述问题 — 一个更抽象的层级（这项工作要实现什么？），以及一个更具体的层级（具体在哪一步、什么东西出了问题？）。许多障碍会在换一个层级后消失；若确实如此，就说明原因并跳到第 6 步。

第 3 步 — 假设剖析（始终执行）

无论障碍类型如何，都使用 references/techniques.md 中的 T1：列出问题陈述中包含的每个假设，将其标记为已核实的事实或既有观念，并质疑这些观念。大多数障碍会在这里消失；未能消除的障碍至少会得到正确界定，便于在第 4 步处理。

第 4 步 — 执行筛选后的技巧

根据障碍类型再选 2–3 种技巧（参见表格中的主要技巧；完整的筛选指导见 references/techniques.md）。每种技巧生成 2–3 个思路。

生成规则：

• 数量门槛：评估任何思路之前，至少先生成 10 个思路。 第一个变通方案通常平庸。生成过程中不要评判、讨论可行性，也不要说“但是”。
• 思路必须在类型上有所不同，而不是换个说法 — 三种“态度更好地再问一次”的做法只算一个思路。
• 此阶段欢迎异想天开的思路；它们会在第 5 步筛选，而且往往能启发可行的方案。

步骤 5 — 梳理各种思路

将每种思路归入以下类别：

• 现在尝试 — 利用现有条件即可实现；有明确的第一步行动
• 需要研究 — 如果某个未知因素得到确认，就可行 → 转交给 /deep-research
• 大胆一试，值得花 30 分钟 — 成功几率低、成本微不足道、收益不对称
• 行不通 — 违反了实际限制（说明是哪项限制）

步骤 6 — 做出选择

• 选出 1–3 种思路，每种都要有明确的下一步行动。
• 如果有 2 种或更多可行思路互相排斥 → 将这个分岔交给 /decide。
• 如果分流筛选后什么都没剩下，而且障碍是物理或数学层面的：请直说。“这道墙承重，必须改换目标”是合理且成功的结果。 建议改换后的目标应该是什么样。

步骤 7 — 归档

归档文件存放在 ${MAKERSKILLS_CONFIG:-$HOME/.config/makerskills}/unstuck/archive/（如果目录不存在，请创建）。绝不要将归档文件写入技能自身的文件夹 — 技能安装和升级会从源目录重新同步，并清除其中保存的内容。

写入 <archive dir>/<YYYY-MM-DD>-<slug>.md：

# Wall: <one-line>

**Date:** YYYY-MM-DD
**Invoked by:** user | agent
**Wall type:** assumption / framing / gatekeeper / tool / resource / physics
**Goal it blocked:** <one line>

## The wall as stated
<verbatim>

## The wall decompiled
<restated without "impossible">

## Assumptions attacked
- <belief> → <held / broke>

## Techniques run
T1, T4, T7 — <one line on what each surfaced>

## Angles (all of them)
1. <angle> — try now / research / wild / dead
2. …

## Committed
**<the angle(s) chosen>** — next action: <concrete step>
(or: "Wall is load-bearing — rerouted goal to <X>")

## Outcome (fill in later)
<did the angle work?>

追加到 <archive dir>/INDEX.md（如果文件不存在，请创建）：

- 2026-07-14 — [<wall>](./<filename>.md) — <type> — **<committed angle or "rerouted">**

随着时间推移，这会成为一个模式库：用 grep 搜索它，了解哪些技巧真正帮你突破了障碍，以及哪些类型的障碍反复出现（反复出现的障碍通常意味着上游有一个未经审视的假设）。

Agent 快速路径

当你（Agent）在任务中途遇到障碍时使用。触发条件：API/工具不支持所需功能、某种方法已失败两次，或者你发现自己的回复中正要写出“这不可能”“遗憾的是”或“唯一的办法是”这样的句子。

在向用户报告走入死路之前，请先就地执行以下步骤（无需交互式记录 — 你已经了解当前障碍）：

1. 分类 — 按照上文的分类体系归类障碍，用一行说明。
2. 剖析 — 列出你框架中的 3–5 个假设，并标出沿袭而来的观点。（“光标必须是文本字符。”“这必须在客户端完成。”“API 是唯一的入口。”）
3. 运用 2 种技巧 — 根据障碍类型选择技巧，至少提出 5 种思路，以供就地补救。如果最终要向用户报告走入死路，必须先通过完整的 10 种思路门槛 — 设置这个门槛，正是为了应对需要报告走入死路的时刻。
4. 然后二选一：
   • 存在可行思路 → 继续执行（告诉用户你遇到了什么障碍，以及采取了哪种思路），或者
   • 没有可行思路 → 附上思路清单，报告走入死路：说明你尝试了什么、考虑了什么，以及每种思路为什么行不通。绝不能只说一句“这不受支持”。
5. 归档 — 如果这次尝试涉及非简单障碍，按步骤 7 的格式归档（Invoked by: agent）；耗时不到一分钟的障碍无需归档。

成功指标：用户不再看到没有附上已尝试思路凭据的走入死路报告。

配合使用

• decide — 下游：2 种或更多互相排斥的可行思路会成为交给 /decide 的分岔。上游：如果 decide 的 Q19（“哪些缺失信息会改变决定？”）中缺少的是一种选项而非信息，则可转到此处。
• deep-research — “需要研究”的思路转交给它；简报返回后，重新进入步骤 5。
• business-brainstorm — 它在判定为 Kill 时使用的“借鉴思路”操作，就是将此技能应用于商业创意。
• pm — 将选定的思路转化为看板任务。
• second-brain — 归档条目可以汇编成一篇“我突破过的障碍”维基页面。

防护原则

• 来自同意、法律或道德方面的拒绝，就是真正的拒绝。 此技能用于绕过技术和想象力方面的障碍 — 而不是他人的界限。如果障碍是“对方明确拒绝了”，就该探查是否有对方乐于接受的另一种方式（T10），绝不能强行推动已关闭的门。
• 限时：20–40 分钟。 这是一根撬棍，不是哲学研讨会。如果冲刺结束时仍未突破，就归档已尝试的内容，然后安排之后再试或改换方向。
• 坦诚收尾胜过有害的积极乐观。 经过切实尝试后认定障碍无法逾越，就是一次胜利 — 它将挥之不去的挫败感转化为明确的改道方案。

关于质量的说明

• 重述是工作的一半。 大多数“无解”的问题，都是按当前表述无解。在尝试任何技巧之前，先从两个层面重述（步骤 2），始终如此。
• 别让数量门槛沦为形式。 10 个角度如果实际上只是 3 个角度换了身伪装，就过不了这一关。必须是本质上不同的角度。
• 列出尝试过的办法，胜过泛泛地说尝试过。 “我什么都试过了” → 让对方拿出实际清单。“什么都试过了”和清单之间的差距，往往就是答案所在。
• 失败的尝试也要归档。 今天没能破解的问题，连同其角度清单一起保存；情况变化时，只需花 5 分钟回顾，而不是从头再来。