有趣的是，这已经是我Waza技能设计系列的第三篇文章了。今天的主题是/思考，这是我在编写代码之前用于解决方案设计的技能。 我发现Claude Code中有两个设置特别有用。第一个是/model opusplan，这意味着计划是用Opus完成的，而执行是在常规Sonnet模型上运行的。这有助于我将最大使用量节省到更重要的地方。 第二个原因是，我通常使用别名c=“Claude--危险地跳过权限”运行Claude Code。我不建议技术水平较低的用户使用。我使用它是因为我知道它在做什么，主要是因为我很懒。 回到/思考。如何让最强的模型产生更好的技术计划？它从模型本身开始。模特们倾向于避免表态。我更喜欢能给出明确建议的工程师。所以我做的第一件事就是要求模型有一个观点。它必须陈述其建议，解释哪些证据可能推翻它，并避免像“有很多方法可以考虑这个问题”这样的空行。给出两三个选项是可以的，但它必须提出明确的建议，并且必须始终包括一个最小的选项。 但一个计划并不是因为听起来不错而制定的。第二步是让它反驳自己。在什么情况下，这个计划会失败？如果这些问题可以修复，则应将修复内容重新折叠到计划中，并再次呈现修订后的版本。如果计划在某些条件下失败，它必须准确说明失败的地点和原因。这样，当计划到达你手中时，权衡已经显现出来。 在规划开始之前，我还相当深入地验证了前提。首先，它检查它是否正在查看代码库的正确部分。我看到模特们制定了反对错误道路的计划。然后，它会寻找旧的技术设计文档，以避免重新发明已经存在的工作。之后，它会搜索GitHub，看看其他地方是否已经解决了类似的问题。只有在这三个步骤之后，它才开始提出解决方案。这有助于防止整个计划建立在错误的假设之上。 还有复杂性分级。如果工作涉及八个以上的文件或引入了一项新服务，则计划必须明确指出规模。如果数据流经三个以上的组件，则必须绘制ASCII图并查找循环。API密钥和第三方依赖项也必须在计划阶段列出，这样您就不会浪费时间或最终制定依赖于不可靠假设的计划。 还有一条硬性规定。该计划不能包含TBD、TODO、“我们可以稍后决定”或“类似于步骤N”等模糊短语。这又回到了行为建模。一旦你离开这种逃生舱，执行往往会偏离轨道，跳过工作，或者很难填补空白。我尽量不让模型有任何偏离精度的空间。 输出格式也很严格：我们正在做什么，我们没有做什么，选择了哪个选项以及为什么，三到五个决策因素，以及一个明确的未知数列表。/think不写代码。只有在用户批准计划后才开始执行。 当我培养这项技能时，我真的在努力捕捉技术专家如何处理解决方案设计：首先进行调查，形成明确的建议，果断地做出决定，不留任何问题，并在出现问题时立即改进计划。 如果您对规划和解决方案设计有更好的想法，请随时为Waza做出贡献。 https://（github）/tw93/waza