think

think skill 概览

think skill 的作用

think 是一个决策支持 skill，用来把一个粗略想法变成清晰、可批准的方案，再进入写代码阶段。它最适合需求设计、架构选择、权衡分析，以及“要不要做这个？”这类主要依赖判断而不是实现的问题。

适合谁安装

如果你经常需要在 repo-first 工作流里处理产品决策、技术方向或范围明确的规划，就很适合安装 think skill。尤其适用于请求一开始就是“帮我规划一下”“最佳方案是什么”“这个要不要保留”这类价值判断场景。

它为什么不一样

这个 skill 的风格很明确：它会推动你给出具体建议，指出哪些证据会改变建议，并避免过早进入代码实现。相比通用的头脑风暴提示词，在你需要一个可直接用于决策的输出时，think for Decision Support 更有优势。

如何使用 think skill

安装并触发 think skill

使用 npx skills add tw93/Waza --skill think 安装。然后在任务属于“选择方向、塑造方案、验证思路”，而不是修复已知缺陷时使用它。think install 这一步很简单，但效果好不好，关键在于你是否给了它真实的决策上下文。

提供正确的输入形态

高质量的 think usage 提示词应包含目标、约束、受众，以及当前到底开放了哪些选择。例如： “我们需要为 SMB 管理员做一个更快的 onboarding 流程；这次只能改 UI，不能增加后端工作量，并且需要给出带权衡的建议。”

先读对文件

先从 SKILL.md 开始，因为这个 repo 有意保持极简，没有 rules/、references/ 或 resources/ 目录。真正实用的指导都在 skill 本体里：轻量模式、评估模式，以及在获得批准前不要进入实现阶段的规则。

把工作流当作决策漏斗来用

一个好的 think guide 流程是：先说明要做的决策，再列出约束，然后要求给出最佳路径，最后只有在需要时再补充风险和备选方案。如果你不确定该用轻量模式还是完整模式，先说明问题是否已经被定义清楚；这一条信息就会显著改变输出质量。

think skill 常见问答

think skill 只适合新功能吗？

不是。它也适用于架构决策、产品价值判断、带有真实权衡的重构，以及“这件事值不值得做？”这类问题。对于简单 bug 修复或一眼就能确定答案的小改动，它并不是最佳选择。

它和普通提示词有什么不同？

普通提示词通常只会给出比较发散的选项。think skill 的设计目标是推动你做决策：给出一条推荐路径、明确说明权衡，并清楚划出在批准前不能写代码的边界。 当你需要一个可以交给同事或利益相关方审阅的方案时，它会更合适。

think skill 适合新手吗？

适合，只要用户能用朴素语言说清目标。新手在提供问题、约束和期望结果时收益最大，即使他们不熟悉技术术语也没关系。

什么时候不该用 think？

如果你已经知道修复方案，只需要执行，就不要用它；如果任务足够狭窄，直接修改比分析更快，也没必要用。若你并没有真正需要做的决策，只是想快速改写一段内容，它带来的价值也会更小。

如何改进 think skill

提供可用于决策的上下文

最好的 think skill 输入会包含当前状态、目标状态、不可妥协的约束，以及成功的标准。例如，“我们需要把设置时间从 10 分钟压缩到 2 分钟，保留现有后端，并避免引入新依赖”，得到的建议会比“改进 onboarding”更有质量。

要求给出决策，而不只是想法

如果你想让 think usage 更有效，提问时要让它给出推荐结论和理由，而不是只列可能性。好的问法是：“在这些约束下，选一个方案并解释为什么它最优。” 较弱的问法是：“给我一些点子。”

把你在意的权衡说清楚

告诉 skill 你最看重什么：速度、可维护性、成本、UX、风险，还是团队产能。这样 think for Decision Support 才能输出符合你优先级的方案，而不是一个泛泛的最佳实践答案。

用更明确的约束持续迭代

如果第一次结果太宽泛，就用一个后续问题把范围收窄：补充截止时间、禁止依赖、目标用户，或者必须保留的组件。提升输出最快的方法，是在问下一个方案之前，把隐藏假设变成显式约束。