智能体工具的提示词技艺

验证标准：最重要的一件事

如果你从这些页面中什么也不带走，请带走这个：告诉 Claude 如何验证自己的工作。

没有验证标准，Claude 的工作流是生成然后期望。它编写代码，认为看起来正确，然后继续。如果有 bug，你发现它。如果输出格式错误，你注意到它。如果边缘情况出问题，你在生产环境中发现它。

有了验证标准，Claude 的工作流是生成-测试-修复。它编写代码，运行验证，观察结果，并迭代直到验证通过。反馈循环是自动的。你指定了成功标准；Claude 追逐它们。

验证标准包括：

• 测试命令："每次更改后运行 npm test 并确保所有测试通过。"
• 预期输出："该函数对于输入 [1, 2, 3, 4] 应该返回 [1, 4, 9, 16]。"
• 视觉检查：粘贴目标 UI 的截图。"结果应该看起来像这样。"
• 行为描述："当没有 auth 头调用时，API 应该返回 400 状态码。"
• 现有测试套件："运行完整测试套件并确保没有回归。"

关键洞察是验证标准将一次性生成转换为迭代循环。Claude 不需要第一次就做对。它需要在停止之前做对。验证标准定义了"在停止之前"。

标准的缺失

当你 prompt "给 API 添加用户认证"而没有验证标准时，Claude 生成了一个看起来合理的实现。它可能工作。也可能不工作。你是验证步骤，你可能不会在审查中发现微妙的问题。

当你 prompt "给 API 添加用户认证。实现后运行 pytest tests/auth/。所有测试应该通过。端点 /api/protected 在没有 token 时应该返回 401，在有有效 token 时返回 200"——现在 Claude 有了一个目标。它会运行测试。它会访问端点。它会迭代直到满足标准，或者它卡住了并告诉你为什么。

在 prompt 中添加验证标准的成本是三十秒的打字。不添加它们的成本以调试时间衡量。

具体性 vs. 模糊性

有使用模糊 prompt 的时候，也有使用具体 prompt 的时候。知道哪个是哪个区分了有效的委派和浪费的循环。

模糊 prompt 适合探索。 "这个代码库中的认证流程是什么样的？"——"错误处理是如何结构的？"——"添加国际化需要做什么？"这些 prompt 利用了 Claude 广泛阅读和综合的能力。你不知道答案；你想让 Claude 发现它。

具体 prompt 适合实现。 "在 src/auth/middleware.ts 中，给 validateToken 函数添加速率限制。使用每 IP 每分钟 100 个请求的滑动窗口。使用 src/config/cache.ts 中现有的内存存储连接来存储计数。在 tests/auth/rate-limit.test.ts 中添加测试。"

失败模式是对实现工作使用模糊 prompt。"添加速率限制"而不指定在哪里、如何添加、对什么添加，给了 Claude 最大的自由来做你会不同意的选择。它选错了文件。它创建了一个新的缓存连接而不是使用现有的。它将状态存储在本地内存中而不是共享缓存中。每个假设孤立来看都是合理的，但对你的代码库来说是错误的。

文件、约束、示例

持续改善结果的三个具体性类别：

引用特定文件。 使用 @ mention 或显式路径。"看 @src/utils/validation.ts 中我们使用的模式。"Claude 不需要搜索正确的文件。你已经指向了它。

陈述约束。 什么不能改变。什么权衡是可接受的。存在什么灵活性。"不要修改数据库模式。性能比代码可读性更重要。你可以添加新文件但不要重组现有目录。"

提供示例。 如果你想要特定格式的输出，展示格式。如果你想要匹配某个模式的代码，展示模式。Claude 从示例外推比遵循抽象描述更好。

委派心态

向智能体工具发 prompt 不是为脚本编写指令。而是向一个有能力的同事委派。这个区别改变了你在 prompt 中包含什么。

对于脚本，你指定每一步："打开这个文件，找到这个函数，添加这一行，保存文件。"对于同事，你指定目标和上下文："我们需要在 auth 中间件上加速率限制，因为我们被一个机器人猛攻了。缓存连接已经存在。使用我们在支付端点上使用的同样的滑动窗口方法。"

同事自己弄清楚步骤。脚本执行你的步骤。Claude Code 是那个同事。

委派心态改变了你的 prompt 的三个方面：

• 目标优于步骤。 陈述 Claude 完成后需要为真的内容，而不是如何达到那里。
• 上下文优于指令。 解释为什么这个更改重要，什么已经存在，约束是什么。
• 信任优于控制。 让 Claude 选择实现方法。当它选错时干预，而不是预防性地干预。

这对开发者来说是不舒服的。我们被训练为精确地指定。但过度指定智能体工具会将其限制在你的方法上，而你的方法可能不是最好的方法。陈述目标。提供上下文。让智能体工作。

富内容输入

Claude Code 接受的不仅仅是文本 prompt。使用完整的输入模态范围持续改善结果。

使用 @ 的文件引用。 输入 @ 后跟路径，将文件内容直接包含在上下文中。这比让 Claude 读取文件更便宜也更可靠——内容在 prompt 中，而不是通过工具调用获取。

图像。 粘贴 UI 目标、错误消息、设计模型或白板草图的截图。Claude 解释图像并可以朝视觉目标实现。"让仪表板看起来像这样"加上截图比三段描述布局更精确。

URL。 Claude 可以获取和处理 Web 内容。将它指向 API 文档、样式指南或参考实现。内容被检索和解释，省去了你的复制粘贴。

管道输入。 Claude Code 是一个 Unix 公民。向它管道数据：cat error.log | claude "what's causing these failures?"——git diff HEAD~5 | claude "summarize these changes"。这将 Claude 连接到你现有的命令行工作流。

每种输入模态都增加了上下文。上下文消耗 token。但正确的上下文——一张截图而不是一段文字，一个文件引用而不是一个描述——比替代方案更便宜也更有效。

中断并引导

Claude Code 不是批处理过程。你可以在任务中途中断它。

如果 Claude 正在朝错误的方向前进——实现一个你不想要的解决方案、使用一个你不用的库、修改错误的文件——输入你的修正并按 Enter。Claude 停止它正在做的事情，阅读你的修正，并调整方向。

这就是使智能体工具在质量上区别于一次性生成的实时引导循环。你不是在等待完整输出然后审查和拒绝。你是在看着工作发生并实时重定向。

有效的中断是具体的："停——使用 config/db.ts 中现有的数据库连接而不是创建一个新的。"模糊的中断（"那不对"）迫使 Claude 猜测你反对什么。

中断并引导模式在复杂任务的最初几分钟最有价值，此时 Claude 的初始方法揭示了它的假设。尽早纠正假设，其余的实现就会正确地跟进。

角色分配 Prompt

设定 Claude 的角色会改变它的行为。这不是神秘的 prompt 工程——它是设定协调期望。

"你是编排者。你的子智能体是你的开发团队。给每个智能体分配一个清晰、有界的任务。在集成之前审查它们的输出。"这种设定导致 Claude 向子智能体委派而不是在主上下文中实现所有内容。它在行动之前规划。它审查结果。

没有这种设定，Claude 倾向于在单个上下文中自己做所有事情。对于小任务，这没问题。对于多文件重构或跨服务更改，它导致上下文耗尽和细节丢失。编排者设定触发了不同的工作模式。

其他有效的角色设定：

• 调查者："你的工作是理解，不是改变。报告你的发现。"让 Claude 在探索任务中保持只读模式。
• 审查者："以资深工程师的身份审查这个 pull request。关注正确性、安全性和可维护性。"产生结构化的审查输出而不是代码更改。
• 专家："你是一个数据库迁移专家。你唯一关心的是模式更改和数据完整性。"缩窄焦点并减少无关的更改。

规范驱动开发

在让 Claude 编写代码之前，让它编写一个文档。这不仅仅是一个提示技巧。它是一个命名的工作流模式——规范驱动开发——与默认的 AI 编码模式（prompt、编码、调试、重复）形成鲜明对比。

传统模式是这样的：你写一个 prompt，Claude 生成代码，你发现 bug，你调试，你再次 prompt，你生成更多代码，你发现更多 bug。上下文被失败的尝试填满。没有持久的真相来源。没有明确的停止点。每次迭代都在同一个混乱的上下文中从头开始。

规范驱动开发遵循不同的流程：研究、规范、细化、任务、完成。

• 研究。 生成多个子智能体并行调查代码库的相关部分。每个子智能体探索不同的维度——现有架构、API 表面、测试模式、依赖关系。研究结果回流到主上下文。
• 规范。 让 Claude 根据研究编写一份全面的规范。"你的目标是编写一份报告。为涵盖架构、数据模型、错误处理和回滚策略的迁移生成技术规范。还不要写任何代码。"规范成为仓库中的一个文件——一个在上下文压缩和会话重启后仍然存活的持久工件。
• 细化。 在实现之前，让 Claude 使用 AskUserQuestion 工具向你询问规范："使用 ask_user_question 工具——在我们实现之前你对规范有什么问题吗？"Claude 询问关于歧义、设计决策和边缘情况的澄清问题。你回答。规范被更新。这捕获了本会成为 bug 的误解。
• 任务。 将规范分解为原子任务，每个任务由一个具有新上下文的子智能体实现。"使用 task 工具。每个任务应该只由子智能体完成。每个任务之后，做一次提交。"每个子智能体阅读规范，实现一个部分，提交，然后返回。主上下文保持精简——它在编排，不是在实现。
• 完成。 在规范中定义的明确完成标准决定工作何时完成。

规范驱动开发的五种 Prompt 模式

该工作流依赖于五种触发正确行为的特定 prompt 模式：

• "为你的研究任务启动多个子智能体。" 触发并行研究。五个子智能体同时研究代码库的五个方面。
• "你的目标是编写一份报告/文档。" 迫使 Claude 在任何代码之前产生一个书面工件。这成为真相来源。
• "在我们实现之前使用 ask_user_question 工具。" 在歧义和设计决策成为 bug 之前浮出它们。
• "使用 task 工具，每个任务应该只由子智能体完成。每个任务之后，做一次提交。" 强制具有提交边界的原子化、独立可验证的工作单元。
• "你是主智能体，你的子智能体是你的开发者。" 触发保持主上下文精简和委派导向的编排者角色设定。

一个演示：存储层迁移

为了让这更具体：一位实践者使用规范驱动开发将一个同步引擎的存储层从一种浏览器数据库技术迁移到另一项——这项任务手动完成需要两到三天。

第一阶段：研究。 五个子智能体并行启动研究目标框架。每个调查不同的方面：数据模型、同步协议、冲突解决策略、索引方法和跨标签页协调机制。并行研究在几分钟内完成，产生了原本需要数小时阅读文档才能获得的发现。

第二阶段：规范创建。 基于研究，Claude 产生了一份涵盖迁移策略、适配器接口、数据转换逻辑和测试计划的全面规范。规范放进了仓库中的一个文件。

第三阶段：细化。 Claude 使用交互式提问工具询问澄清问题："迁移应该如何处理旧的和新的存储格式之间的冲突？我们应该支持回滚到旧格式吗？如果用户在迁移期间有多个标签页打开，预期的行为是什么？"每个回答都使规范更加严格。

第四阶段：任务委派。 规范分解为十四个任务，每个分配给一个子智能体。每个子智能体阅读规范，实现其任务，运行相关测试，并提交。git 日志显示了十四个原子提交，每个实现了一个清晰有界的迁移片段。

整个工作流大约花了四十五分钟。产生的代码比手动实现更好，因为研究阶段发现了开发者自己不会发现的目标框架中的模式。

AskUserQuestion 工具

细化阶段值得特别关注。当你告诉 Claude "在我们实现之前使用 ask_user_question 工具"时，Claude 进入一种面试模式。它阅读规范并对其不确定的一切提出多选或开放式问题。这与自由对话中的"详尽地问我问题"不同。AskUserQuestion 工具提供结构化的、聚焦的问题，更容易回答并产生更可操作的澄清。

面试模式在规范细化之外也运作良好。在任何复杂任务开始时使用："在构建任何东西之前，使用 ask_user_question 工具面试我关于我的需求。在你问了每个问题之前不要继续。"结构化格式浮出了自由对话遗漏的假设。

规范作为持久真相

规范文件不仅仅是一个规划工件。它是整个工作流的恢复点。如果一个子智能体失败了，规范仍然在那里——在同一个任务上启动一个新的子智能体。如果上下文被压缩了，规范作为磁盘上的文件存活下来。如果你需要在第二天恢复，规范告诉新会话它需要知道的一切。

一个工程团队更进一步：他们将规范作为 markdown 文件存储在代码库中，由 Claude 编写，由人类审查，然后由 Claude 执行。规范像任何其他工件一样经过代码审查。当实现完成时，规范保留作为设计决策的文档。这就是规范即代码——规范不是一个一次性的规划文档，而是一个版本化的、经过审查的、被执行的工件。

反向压力作为 Prompt 工程

这是实践者发现的最有价值的模式之一，它完全重新定义了你对项目工具化的思考方式。

你的 lint 配置是你的 prompt 的一部分。

不是比喻。字面意思。当 Claude Code 在具有严格 lint、全面类型检查和详尽测试套件的项目中运行时，它在每次更改时收到自动反馈。Linter 标记样式违规。类型检查器捕获类型错误。一个测试失败了。Claude 阅读错误，修复问题，然后重试。

这就是反向压力。工具对不正确的输出进行反击，智能体自我纠正。工具化越严格，输出越好。一个具有严格 lint 规则、严格类型检查配置和高测试覆盖率的项目比一个没有这些约束的相同项目产生更好的 Claude Code 输出——即使 Claude 从未被明确告知这些规则。

其含义是架构性的：投资于严格的 lint、全面的类型和详尽的测试支付双重红利。它捕获人类错误也捕获 AI 错误。它捕获的 AI 错误是你本不得不手动发现的。

你的反馈预算是有限的。每次你手动告诉 Claude "修复缩进"或"使用分号"或"那个变量应该是 const"时，你都在把反馈预算花在工具化应该自动捕获的机械问题上。把你的反馈预算花在架构、设计决策和领域逻辑上——lint 无法检查的东西。让类型检查器和 linter 处理它们能处理的一切。

运行测试套件和 linter 的预提交 hook 创建了一个特别紧密的反向压力循环。Claude 提交，hook 运行，报告失败，Claude 修复并重试。人类不需要审查每一个更改。工具化审查它。

这重新定义了工具化投资。lint 配置不仅仅是代码质量工具。它是塑造 Claude 在该项目中生成的每一段代码的 prompt 的组成部分。相应地投资。

TDD 作为反向压力

测试驱动开发工作流是反向压力的终极表达。一个工程团队描述他们的旧模式是"设计文档、蹩脚代码、重构、放弃测试"。有了 Claude Code，模式反转了。他们先让 Claude 写伪代码，引导它进行测试驱动开发，并定期检查以在它卡住时引导。测试在实现之前编写。实现直到满足测试才能通过。Claude 迭代直到它通过。

这不是出于哲学原因的 TDD。这是出于务实原因的 TDD。当一个智能体同时编写测试和实现时，测试创建了防止实现偏移的反馈循环。智能体编写一个测试，编写代码来通过它，运行测试，看到失败，调整，然后重试。人类定期检查以验证测试本身在测试正确的事情。

先规划后执行

在实现之前让 Claude 规划是防止昂贵错误的廉价保险。

"在做任何更改之前，阅读相关文件并生成一个计划。列出你将修改的每个文件、你将创建的每个新文件以及每个行为更改。在继续之前等待我的批准。"

生成一个计划大约花费 10,000 个 token。一个方向错误的实现花费 500,000 个 token 和一次上下文重置。经济账是显而易见的。

计划审查还让你在误解变成代码之前捕获它们。如果 Claude 的计划包括修改一个你认为不可触碰的文件，你在计划阶段就捕获了它。如果计划遗漏了一个明显需要更改的文件，你在实现开始之前添加它。

一个键盘快捷键使这更实用：按 Ctrl+G 在你的默认文本编辑器中打开 Claude 的计划。你可以直接编辑计划——添加步骤、删除步骤、重新排序优先级、添加约束——当你保存并关闭编辑器时，Claude 按你修改后的计划继续。这比在对话中描述修改更快，也比试图通过后续 prompt 引导现有计划更精确。

先规划后执行模式与子智能体委派组合良好。在主上下文中廉价地规划，然后将每个计划项交给子智能体并行执行。这是最具成本效益的多智能体策略，如第四章所述。

你还可以将计划转换为更短的检查清单供执行使用。在 Claude 产生详细计划后，要求它"将计划重新混合成我可以浏览和勾选的更短检查清单。"检查清单成为工作文档——足够简洁以便在实现时保持在视野中，足够详细以捕获所有步骤。

约束的明确性

隐式约束是不可见的约束。Claude 无法尊重你没有陈述的规则。

三类需要明确陈述的约束：

什么不能改变。 "不要修改数据库模式。""不要改变公共 API 表面。""文件 core/engine.py 是冻结的——读取它但不要编辑它。"这些硬边界防止 Claude 通过你认为神圣不可侵犯的东西走捷径。

权衡偏好。 "优化可读性而非性能。""尽量减少新依赖的数量。""偏好简单的解决方案，即使它们不够优雅。"这些软偏好在多种方法可行时引导 Claude 的选择。

灵活性边界。 "你可以在 src/utils/ 中添加新文件但不能在 src/core/ 中。""你可以使用 package.json 中已有的任何库但不要添加新的。""如果简化实现，重构测试辅助函数是可以接受的。"这些告诉 Claude 它有多少回旋余地。

未陈述的约束是令人失望输出的最常见来源。Claude 产生了某些正确但违反了你没有意识到自己有的假设的东西。陈述约束。所有约束。

输出格式规范

当你想要结构化输出时，描述结构。

"生成一个比较表，列包括：功能、当前实现、提议更改、风险级别。"——"将分析格式化为编号列表，每个项目包含：发现、严重性和建议修复。"——"将测试计划写成带复选框的检查清单。"

Claude 可靠地遵循格式规范。省略它们会让你得到 Claude 默认的任何格式，这可能匹配也可能不匹配你需要的。

格式规范在 Claude 的输出将被其他流程或其他人消费时特别重要。期望 JSON 的下游工具不会欣赏自由格式文本。期望检查清单的同事不会欣赏一篇论文。

自我批评 Prompt

让 Claude 评估自己的工作可以发现它在生成过程中没有提到的问题。

"给这个实现打 1-10 分。你会改进什么？哪些边缘情况可能会出问题？资深工程师会反对什么？"

自我批评步骤产生了令人惊讶的有用输出。Claude 识别出遗漏的边缘情况、建议性能改进、标记潜在的安全问题，并承认它走的捷径。并非所有自我批评都是可操作的，但足够多的是的，使这个模式值得。

一个变体："这个最可能出问题的三件事是什么？"这把批评聚焦在可能的问题上而不是假设性的。

自我批评在复杂实现之后、你提交之前最有价值。它花三十秒。它捕获审查中需要三十分钟才能发现的问题。

自我批评：一个完整示例

自我批评模式通过一个真实示例变得更加具体。一位实践者让 Claude Code 产生一个财务优化计划，然后 prompt："给这个计划打 1-10 分。你会改进什么？"

Claude 给自己的计划打了 7.5 分（满分 10 分）并识别了七项具体改进。其中一项是重要的发现：该计划以忽略了特定退休账户的免税地位的方式分配了某些资产。在该账户内出售和重新分配的成本为零税款，但原计划没有利用这一点。自我批评识别了遗漏的优化，修订后的计划纳入了它。

教训不是自我批评总是能找到七项改进。而是自我批评能找到第一次生成时不明显的改进。Claude 最初不包含这些优化是因为生成过程针对 prompt 最常见的解释进行了优化。自我批评步骤强制进行第二次审查，捕获了第一次遗漏的内容。

对于分析工作，一个特别有效的自我批评 prompt 是："包含一个自我批评部分。给这个计划打 1-10 分并列出你会做的每项改进。"让自我批评成为输出的必需部分——而不是事后补充——确保它获得足够的关注。

详尽提问

当 Claude 填补假设时，结果是合理的但往往是错误的。修复是防止假设填充。

"在开始之前，详尽地问我关于你不确定的任何事情。在你问了每个问题之前不要继续。"

这个 prompt 修饰语导致 Claude 在对不确定性采取行动之前将其浮出。你使用什么认证系统？什么数据库？失败时应该发生什么？你想要错误信息面向用户还是只记录日志？这是一个新端点还是现有端点的修改？

这些问题揭示了你自己规范中的缺口。你可能没有考虑过失败处理。你可能没有考虑过使用哪个数据库。Claude 的问题迫使你做出你否则会作为 bug 发现的决策。

实践者报告详尽提问在复杂任务上将首次通过质量提高了 30-50%。成本是几分钟回答问题。好处是一个匹配你实际需求而不是 Claude 假设的实现。

稻草人提案

当你有一个粗略的想法时，不要从零开始。

"这是我的粗略方法：使用缓存支持的滑动窗口，按 IP 追踪，60 秒后过期 key，达到限制时返回 429。这可能是错的。改进它或建议替代方案。"

稻草人给 Claude 一个可以反应的起点。反应在认知上与从零生成不同。反应包含了你的领域知识（缓存支持、按 IP、429），同时允许 Claude 完善方法（也许令牌桶更好，也许按用户比按 IP 更合适）。

"这可能是错的"这个限定词很重要。没有它，Claude 倾向于不加批判地接受你的方法。有了它，Claude 把提案当作一个需要评估和改进的草案。

稻草人提案与自我批评配合得很好："这是我的方法。批评它，建议替代方案，然后实现最佳选项。"

针对模糊代码库的具体 Prompt

大型代码库会产生命名冲突。可能有三个叫做"Dashboard"的组件。两个叫做"Auth"的服务。四个名为"utils.ts"的文件。当你 prompt Claude "修复 Dashboard 组件中的 bug"时，哪个 dashboard？

在模糊的代码库中，极端的具体性不是学究气的——它是必要的。

"修复 src/features/trading/components/Dashboard/TradingDashboard.tsx 中的渲染 bug。问题在 useMarketData hook 的大约第 145 行，WebSocket 连接在 unmount 时没有被清理。不要修改 src/features/admin/components/Dashboard/AdminDashboard.tsx，它有类似的名称但是无关的。"

对相似命名组件的明确"不要修改"不是偏执。它是一个防止错误组件编辑的约束，在大型代码库中这可能通过代码审查，因为审查者没有注意到哪个 Dashboard 被更改了。

你的代码库越模糊，你的 prompt 需要越具体。精确的文件路径、行号、函数名和明确排除。成本是多打几秒钟字。好处是 Claude 修改了确切正确的东西。

扩展思考配置

Claude Code 的扩展思考模式在生成响应之前分配额外的 token 用于推理。思考在内部进行——你看到的是结果，而不是推理过程。对于需要深入分析的复杂任务，扩展思考显著改善了输出质量。对于简单任务，它浪费 token 和时间。

三种机制控制它：

环境变量。 MAX_THINKING_TOKENS 设置思考 token 的预算。默认是最大值（31,999 个 token）。将其设低（例如，MAX_THINKING_TOKENS=10000）以减少不需要深度推理的任务的成本，或设为零以完全禁用思考。对于具有自适应推理的最新模型，思考深度由 effort level 控制，此变量除非设为零否则被忽略。

CLAUDE_CODE_EFFORT_LEVEL 将 effort 设置为 low、medium 或 high（默认）。较低的 effort 更快更便宜。较高的 effort 提供更深入的推理。你还可以通过 /model 命令使用左右箭头键交互式地调整 effort level——更改立即生效。

键盘切换。 Alt+T（或 Mac 上的 Option+T）在对话中切换扩展思考的开关。这需要先运行终端设置命令（/terminal-setup）。

一个关键误解： 你的 prompt 中的"think harder"或"ultrathink"等短语不会分配更多的思考 token。它们只是 prompt 中的词语。思考预算完全通过环境变量和 effort level 设置控制。如果你想让 Claude 推理得更深入，调整配置——不要在你的 prompt 中添加魔力词语。

图像和截图工作流

Claude Code 通过多种机制接受图像作为输入，每种都有不同的最佳用途。

拖放。 在桌面应用中，将图像文件直接拖入 prompt 区域。在支持的终端中，拖放也可以工作。

复制粘贴。 使用 Ctrl+V（不是 Mac 上的 Cmd+V——这是一个常见错误）从剪贴板粘贴图像。使用系统截图工具截取的截图会存入剪贴板并直接粘贴。

文件路径。 通过路径引用图像："看 ./screenshots/bug.png 中的截图并识别布局问题。"Claude 读取图像文件并解释其内容。

打开引用的图像。 当 Claude 在其回复中提到图像路径时，Ctrl+点击（或 Mac 上的 Cmd+点击）在系统查看器中打开图像。这在 Claude 生成图像或引用现有截图时很有用。

截图驱动调试

一个基础设施团队发现了一种将图像输入扩展到 UI 工作之外的模式。当容器编排集群宕机并且不调度新的 pod 时，他们向 Claude Code 输入监控仪表板的截图。Claude 解释了仪表板可视化，识别出一个指示 IP 地址耗尽的警告，逐菜单引导团队完成云提供商的管理界面，并提供了确切的命令来解决问题。截图比仪表板状态的口头描述更精确。

这种模式适用于症状是视觉的但解决方案是技术的任何地方：基础设施仪表板、错误消息截图、日志查看器捕获、网络拓扑图。Claude 解释图像并将其映射到代码库的技术上下文。

非开发者的视觉优先迭代

非技术用户——设计师、产品经理、法务人员——经常使用截图作为他们与 Claude Code 沟通的主要媒介。他们粘贴一个他们想要的界面样子的截图，Claude 实现它。他们查看结果，拍摄另一张截图显示哪里有问题，Claude 调整。迭代循环完全是视觉的，完全没有代码讨论。

这与开发者工作流是不同的交互模式。开发者用代码术语描述更改。非开发者用外观术语描述更改。两者都是有效的输入。截图驱动的方法每次迭代较慢但需要零技术词汇。

领域特定的 Prompt 模板

到目前为止描述的 prompt 模式是通用目的的。对于领域特定的分析工作——财务分析、技术审计、数据科学——prompt 本身需要通用模式不提供的结构深度。

目标 Prompt 的解剖

对于复杂的分析任务，一个详细的目标 prompt 遵循特定的结构：

• 存在什么数据以及在哪里。 "/data/accounts/ 中有三个账户的 CSV 导出。/data/notes.txt 中有一个补充文本文件，包含无法导出的信息。"
• 期望的输出格式。 "生成一个表格，列包括：资产、当前配置、目标配置、差距、优先级、行动。包括一个摘要部分和一个包含方法论的附录。"
• 偏好和原则。 "优先考虑税收效率而非原始性能。最小化费用。偏好简单性。"
• 已知约束。 "不要修改退休账户缴费——那些是自动的。经纪账户有 $10,000 的最低余额要求。"
• 你怀疑有什么问题。 "我认为投资组合在大盘成长股上超配。如果你有不同看法，我想听听。"限定词"如果你有不同看法，我想听听"防止 Claude 锚定在你的怀疑上而忽略相反的证据。
• 稻草人提案。 "这是我的粗略目标配置：40% 国内股票，60/40 大盘/中盘分配，20% 国际，30% 固定收益，10% 另类投资。这可能是错的。"
• 详尽提问指令。 在最后："在你不确定的任何事情上详尽地问我问题再继续。"把这放在最后确保 Claude 在急于下结论之前询问澄清问题。

这种解剖适用于财务以外的任何分析任务，其中 prompt 需要同时传达领域上下文、输出期望和细微偏好。

动态约束重构

在项目中期，你可以重构约束并看着 Claude 重建整个分析框架。"将退休账户视为固定约束。计算理想的总投资组合是什么样的，减去退休账户提供的部分，优化剩余账户来填补缺口。"Claude 基于新的框架重新计算每个目标、每个缺口、每个建议。静态部分成为给定条件；动态部分被优化。

这比用新的 prompt 重新开始更强大。Claude 保留了分析的完整上下文并在重构的约束之上重建，而不是从头重新生成。

演示 Skill

Skill 可以将复杂的 prompt 模式封装成可重用的工作流。一个社区构建的 skill——演示 skill——展示了 skill 和 prompt 技艺如何交汇。

当你用"walkthrough how does authentication work in this codebase"这样的查询调用演示 skill 时，它执行一个四阶段管道。首先，它生成两到四个子智能体并行探索代码库的相关部分。其次，它将发现综合为五到十二个关键概念及其之间的连接。第三，它生成一个包含交互式图的独立 HTML 文件。第四，它在你的浏览器中打开该图。

图中的每个节点都是可点击的。点击一个，会滑出一个详细信息面板，包含通俗英语的描述、文件路径和代码片段。整个事情在两分钟内产生一个系统的心理模型。

演示 skill 展示了一个适用于任何复杂 prompt 工作流的模式：将多步骤过程（并行研究、综合、工件生成）包装在一个 skill 中，使其成为单个命令。Prompt 工程只需做一次，经过测试，然后重用。

/learn Skill 模式

另一个值得研究的 skill 模式是学习 skill，它遵循五个阶段：对当前对话的深入分析、洞察的分类（模式、陷阱、架构决策）、将学习内容起草为文档、用户批准（一个阻塞步骤——skill 暂停并等待你的确认），以及保存到相应的文档文件。

这种模式从对话中提取机构知识并将其持久化。不再让 Claude 的有用发现在会话结束时消失，skill 将它们捕获为有利于未来会话和未来开发者的文档。阻塞批准步骤确保没有人工审查就不会保存任何内容。

Skill 中的渐进式披露

一个设计良好的 skill 使用渐进式披露来最小化上下文成本。考虑一个分析顾问 skill：skill 目录包含一个带有 skill 定义和快速入门说明的 skill.md 文件、一个包含可执行工具的 scripts/ 目录和一个包含详细文档的 references/ 目录。

当用户的 prompt 匹配 skill 的描述时，只有 skill.md 加载到上下文中。当 skill 运行时，它调用 scripts/ 中的 CLI 工具。只有当工具需要详细指导时，它才从 references/ 中读取。完整的参考材料除非需要否则永远不会进入上下文。这种设计使基础上下文成本接近零，同时支持任意复杂的操作。

双界面规划

包含非技术成员的团队报告了一种独特的工作流：先在云 AI 聊天界面中头脑风暴，然后转到 Claude Code 进行实现。云界面更适合开放式探索——思考工作流、考虑替代方案、勾勒方法。一旦计划明确，他们在聊天界面中创建一个全面的 prompt 并将其粘贴到 Claude Code 中作为起点。

关键是让云界面慢下来逐步工作，而不是一次性产出所有内容。规划阶段的输出是一个结构化 prompt——不是代码，不是设计文档，而是 Claude Code 将接收的实际输入。这种双界面模式让非开发者使用他们感到舒适的界面完成创意工作，并将技术执行委派给为它设计的工具。

提供写作样本

当 Claude 生成文档、报告或其他书面输出时，提供写作样本显著改善风格匹配。一个团队在文档任务开始时提供格式偏好和示例文档："这是我们格式化运维手册的方式示例。匹配这种风格，包括标题结构、项目符号密度和故障排除步骤中的详细程度。"

Claude 从示例外推比遵循抽象风格描述更可靠。"以简洁直接的风格写作"是模糊的。三段你实际写作风格的样本是精确的。成本是几百 token 的示例输入。好处是你无需重写就能使用的输出。

中断以求简单的模式

Claude 倾向于复杂的解决方案。它构建抽象、添加层、引入模式。这通常是一个特性——复杂的问题需要复杂的解决方案。但有时简单的方法才是正确的，而 Claude 做过了头。

修复是一个特定的中断模式：在 Claude 执行过程中停止并问"你为什么要这样做？试试更简单的方法。"Claude 对简单性请求反应良好。它去掉不必要的抽象，移除多余的层，产生更直接的解决方案。

这与前面描述的一般中断并引导模式不同。一般模式纠正方向。简单性模式纠正复杂度。注意过度工程的迹象：看似不必要的新文件、包装单个调用的抽象、增加间接性而不增加价值的模式。当你看到它们时，中断。