关于 thinking-out-loud
thinking-out-loud 是用于处理冗长、松散口述内容或模糊想法的 Agent Skill。它会先生成结构化复述，将用户内容与推断、猜测分开，并列出未决问题和立场变化，再进行后续行动。
主要功能
- 01以结构化复述审查整段消息
- 02区分用户内容与模型补充
- 03记录立场变化并搁置旁题
- 04复述后围绕未决项访谈
- 05获批后提供保存选项
适用场景
- 01确认长篇口述中的需求
- 02在制定计划前理清模糊想法
- 03生成产物前发现假设
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/thinking-out-loud确认已加载。
附带文件README.mdreferences/echo-format.md
详细介绍
Thinking Out Loud
十分钟的语音随想，比一个人会输入的任何提示词都能传递更多上下文，而模型也很擅长还原随想。问题出在后续环节，而且不易察觉：模型会自信地填补随想中的所有空白。“常用模型”悄然变成了某个特定模型。“标准尺寸”变成了某个特定视口。用户在随想中途改口的立场，却仍被保留为事实。这些从模型自身的角度看都不像是不确定，因此也就不会变成澄清问题。接着，模型会根据自己深信不疑的误解采取行动，而用户要等到生成的工作已经持续了一个小时才发现问题。
这个技能就是为了解决这一问题：在对任何随想采取行动前，先生成一份回声——一份简短、结构化的审查，将模型自行补充的内容与用户原话隔离开来。用户只需纠正三行，而不必调试已经生成的成品。
为什么要用回声，而不是追问
提出澄清问题是好做法，下面的访谈流程也会这么做。但仅靠提问无法确保正确理解随想，原因有两个结构性问题：
- 问题核实的是模型存疑的内容。回声核实的是模型确信的内容。 澄清问题需要模型感受到不确定，而自信的误读感觉就像知识。回声会迫使模型公开每一项推断和补全，无论模型是否感到不确定。
- 问题只是抽样；回声则是全面审查。 一段很长的随想中会包含数十条事实和未定的决定。即使问题问得很好，也只能探究三四项；模型对其余内容的理解会未经核实就进入行动阶段。回声会清点全部传递内容，而且依靠的是识别，而不是回忆：用户阅读后就能发现错误，远比自己组织答案省力；而且，随想者往往要等看到错误的猜测被写出来，才知道自己的答案是什么。
约定
- 什么都不做。 在回声获得批准之前，不编辑文件、不写代码、不制定计划、不为零散内容提供解决方案。先还原内容。
- 标明每一项补充。 推断和猜测必须放在独立部分，与用户自己的内容分开。绝不把猜测说成用户的话。
- 指出每一次改口。 采用后来的立场，但要标明改口。绝不悄悄折中或擅自选择。
- 不遗漏任何内容。 离题内容要先搁置，而不是丢弃。
- 绝不评论听写瑕疵。 根据上下文默默处理错别字、同音词、填充词和重新开始的话语。保留用户自己的用词和项目名称。
- 先询问再保存。 为获批的简报提供一个保存位置，但绝不未经提示就保存。
适用情形
- 消息是一段很长、缺少标点的意识流，包含重新开始、填充词和中途改口（“其实不对，算了吧”）
- 消息以语音开场白开头（“切换到语音识别，抱歉可能有错别字”“我在口述”）
- 用户说他们想随意聊聊或边说边想
- 用户要求通过访谈梳理模糊的想法
不适用情形
- 简短且已经表达清楚的请求
- 用户想要逐字转录、会议纪要，或在保留原话的前提下整理听写内容
- 内容很长但结构已经清晰，例如粘贴的规格说明或文档
- 用户提出了直接的问题，并希望得到直接的回答
回声
一份结构化回复。内容紧凑、便于浏览且简短：用户应能在几秒内找到并修复错误。完整模板及示例见 references/echo-format.md。
- 目标：用一句话说明用户实际想实现什么。这通常与用户最初的说法不同，也没关系。
- 已确定：将用户的决定和约束合并为一个列表。标出用户称为首要事项的内容。
- 待明确：用户长篇表达中提出但尚未回答的问题。
- 记录：立场反转（在一行中写出两个立场，并采用较晚提出的立场）和暂搁的话题（每项一行）。
- 我的补充：唯一需要指出解释性判断的部分。“推断”指强烈暗示但从未明说的内容；“猜测”指你补上的信息空缺。提醒用户优先纠正这些内容。
压缩规则，不容妥协：
- 内容不得重复。 每条事实只能出现在一个部分中。
- 不要回顾“你说过”。 除“我的补充”外的所有内容，按定义都是用户自己的内容；只有模型补充的内容才需要特别指出。
- 每条项目符号占一行。 如果一条需要两行，就拆成两条，或者删去冗余内容。
- 绝不默默明确含糊的数量词。 “常用型号”“标准尺寸”“尽快”这类说法，都应放入“待明确”或“猜测”，不能当作已明确的内容并入“已确定”。
最后邀请用户纠正，并提供访谈选项。
访谈（可选）
追问有其作用：应在审查之后进行，而不是取代审查。只有用户接受邀请，或一开始就要求访谈时，才进行访谈。
- 只询问“待明确”或“猜测”中标出的事项
- 每条消息只问一个问题，优先询问信息增益最高的问题
- 每个问题都用一个分句说明其重要性
- 最多问五个问题；一旦答案不再改变需求说明，就提前停止
- 访谈结束后，只重述回声中发生变化的部分
记录模式（多轮长篇表达）
听写工具会在一条消息中收到完整内容，无需使用此模式。当用户先启用此技能，之后再分几条消息补充想法（可能间隔很长时间）时，使用此模式。
- 只用一行简短回复确认一次（“请说吧，我在听。想让我整理回声时，说‘完成’。”）
- 对之后的每条消息，只用一行极简回复（“我在听。”）。稍作变化，避免显得机械。
- 中途不要解决问题、称赞、总结、分析或提问。
- 如果用户在长篇表达中途直接提问，最多用两句话回答，然后继续倾听。
- 用户说“完成”“回声”“给我回声”“就这些”“你听到了什么”或任何明确的同义表达时，退出此模式并给出回声。
持久化
用户批准回声后，恰好提供三个选项：
- 将需求说明附加到 CLAUDE.md，让未来的会话也能沿用
- 保存到
docs/rambles/YYYY-MM-DD-<topic>.md - 仅保留在当前对话中
获批的需求说明随后将约束本次会话的其余部分：遵循其中的决定和约束，不要再次询问。