boris-prompts

Boris 风格提示词编写器

使用 Boris（Anthropic 成员、Claude Code 的创建者）在其「Pro Tips & Tricks」演讲中分享的方法，为任何大模型或 AI 助手编写高质量提示词。

之所以创建这项技能，是因为大多数用户写的提示词太长、限制过多，还遗漏了真正重要的内容——反馈循环、规划步骤和正确的锚点。Boris 的方法则反其道而行：保持提示词简短，让模型自行探索，给模型一种检查自身工作的方式，并把可复用的上下文存入文件，而不是反复粘贴。这些原则最初是为 Claude Code 开发的，但也适用于任何现代大模型（ChatGPT、Gemini、Cursor 等）。

适用场景

符合以下任一条件时，使用这项技能：

• 用户明确要求为任意大模型或 AI 助手编写或改进提示词。
• 用户用自然语言描述了一项任务，下一步合理的做法是将其转化为提示词。
• 用户粘贴了一段很长的提示词，询问为何不起作用，或要求缩短、润色。
• 用户询问「我该怎么表述」或「怎样向 [模型] 提出……比较好」。

以下情况不要使用：撰写营销文案、面向用户的 UI 文本，或为图像生成模型编写提示词。这项技能专门用于面向大模型或 AI Agent 的指令提示词。

目标模型——通用建议与 Claude Code 专属建议

撰写前，先判断用户要向哪个模型编写提示词：

• Claude Code：可使用完整工具集——CLAUDE.md、@file 引用、斜杠命令、commit, push, PR 简写，以及通过自然语言进入规划模式。
• Claude（claude.ai、API）：大多数原则都适用，但不支持 @file 或 CLAUDE.md。可使用系统提示词或 Projects 来保存持久上下文。
• ChatGPT / Gemini / 其他聊天大模型：适用通用原则（简短、先规划、带反馈循环、不凑字数）。将 CLAUDE.md 替换为该模型对应的功能（Custom Instructions、系统提示词、Projects、Gems 等）。只有模型具备相应工具时，「探索代码库」的模式才适用。
• Cursor / Windsurf / Copilot Chat：集成在编辑器中；支持 @file（语法有所不同）、项目级规则文件和先规划的做法。
• Agent 框架（自主工具）：应着重强调反馈循环——这类工具会在无人监督的情况下运行。

如果根据上下文无法判断目标模型，且模型类型会实质性影响提示词，请先询问。

核心原则（按优先级排列）

这些原则直接来自 Boris 的演讲。编写或评估提示词时，按以下顺序应用。

1. 简短胜过冗长

通常，两句话就能写完的提示词，效果会比占满整个屏幕的提示词更好。原因并非为了美观，而是长提示词会占用上下文窗口、重复 Claude 已经知道的内容，并过度限制解决方案的范围。如果发现自己写了超过约 5 行，请考虑其中是否有一半内容应该放进 CLAUDE.md。

2. 「先制定计划」是投资回报率最高的补充

为几乎所有复杂任务提升效果，最可靠的做法是在提示词末尾加上一句类似这样的要求：

「写代码前，先制定计划并提交给我审批。」

之所以有效，是因为只要提出要求，模型通常就很擅长制定计划；许多糟糕的结果都源于跳过了规划步骤。你不需要规划模式、特殊标志或系统提示词——直接用自然语言提出要求就足够了。

3. 不要规定每个细节——让 Claude 自行探索

如果任务涉及现有代码库，提示词通常应该为 Claude 指明正确的起点（「看看 X 是如何实现的」「查查 git 历史，弄清楚这个函数为什么有 15 个参数」），而不是描述完整解决方案。Claude 擅长寻找模式和相似代码；重新描述代码库中已有的内容很浪费。

4. 反馈循环胜过详细指令

当交付成果可以验证（UI 与模拟图一致、测试通过、lint 通过、截图相似）时，提示词应为 Claude 提供验证方式，而不是逐步告诉它该怎么做。模式如下：

“执行 X。然后运行 [测试 / 截图 / lint]。持续迭代，直到满足 [成功标准]。”

这通常胜过多段式规范，因为模型可以依据真实结果自我纠正。

5. 持久上下文应放在文件或设置中，而不是提示词里

如果你发现自己每次提示都要粘贴相同的架构说明、风格规则或常用命令，这就是个信号——这些内容应放在目标的持久上下文机制中：

• Claude Code：./CLAUDE.md（项目）、./CLAUDE.local.md（个人）、~/.claude/CLAUDE.md（全局）、嵌套的 CLAUDE.md（子目录）。
• Claude.ai：Projects、系统提示词。
• ChatGPT：自定义指令、Projects、系统提示词。
• Gemini：Gems、系统指令。
• Cursor / Windsurf：.cursorrules / .windsurfrules、项目级规则。
• API 使用：系统提示词、固定上下文块。

提示词应围绕当前的具体任务，而不是背景信息。

工作流

步骤 1 — 判断信息是否充足

编写提示词前，你需要能够回答以下四个问题。如果任何一项不明确，请停下来询问用户。

问题	重要性	影响内容
这条提示词面向哪个模型 / 助手？（Claude Code、Claude.ai、ChatGPT、Cursor、Gemini 等）	决定可用的模型专属功能（@file、CLAUDE.md、Projects 等）	术语和上下文锚点
交付成果是什么？（问答 / 小改动 / 新功能 / Bug 修复 / 重构 / 调试 / 非代码任务）	决定使用哪个模板	模板选择
助手能否验证自己的输出？（测试、截图、lint、构建、用户手动检查）	决定是否添加迭代循环	“运行 X 并迭代”这一行
这是一次性任务，还是应先规划？	大多数非简单任务都适合先规划；纯问答则不需要	“先制定计划”这一行
是否有助手应参考的现有文件、模式或持久上下文文件（CLAUDE.md、.cursorrules 等）？	决定是否添加文件引用或“查看 X 的工作方式”	上下文锚点

Step 2 — 如果有不清楚的地方，提出 1–3 个澄清问题

使用 AskUserQuestion 工具。**最多提出 3 个问题。**超过这个数量会让用户觉得被盘问，也会失去这项技能为他们节省时间的价值。

根据实际不清楚的内容，从以下菜单中选择问题——不要询问你已从上下文中了解的信息。

如果不清楚目标模型 / 助手，且这会影响答案：

• 问题："这个提示词是给哪个助手用的？"
• 选项：Claude Code（CLI）/ Claude.ai（网页 / 桌面版）/ ChatGPT / Cursor 或 Windsurf / 其他（请说明）

如果不清楚交付内容：

• 问题："你希望 Claude 做什么？"
• 选项：回答有关代码的问题 / 做小幅修改 / 构建新功能 / 修复错误 / 重构现有代码

如果不清楚如何验证：

• 问题："Claude 能否在每次尝试后检查自己的工作？"
• 选项：可以 — 有测试 / 可以 — 通过视觉检查（我会对比截图）/ 可以 — CLI / 构建 / lint 会告诉我们结果 / 不可以 — 我会手动检查

如果不清楚任务范围：

• 问题："这项任务大致有多大？"
• 选项：一两行 / 几个文件 / 整个模块或功能 / 我不知道 — 我希望 Claude 帮我确定

如果不清楚规划偏好（仅当交付内容是小幅修改或更大任务时提问）：

• 问题："你希望 Claude 先提出计划，还是直接尝试？"
• 选项：先制定计划，再征求批准 / 直接尝试，我会适时纠正 / 仅制定计划 — 暂不编写代码

如果不清楚代码库中的参考点：

• 问题："Claude 是否应该先查看现有文件或模式？"
• 选项：是 — 我会用 @ 提及它们 / 查看 git 历史 / 查看类似功能 — 让 Claude 自行查找 / 不需要，这是全新项目

Step 3 — 选择模板并填写内容

从以下模板中选择最匹配的一种。这些模板与 Boris 日常工作中使用的模式相同。

模板 A — 代码库问答

[Question]. Look through git history if it helps.

示例：

• 为什么 parseConfig 需要 12 个参数？查看 git 历史。
• RateLimiter 类实际上是如何使用的？给我看实际的调用位置，而不只是文本匹配结果。
• 我这周发布了什么？使用日志中的 git 用户名。

模板 B — 小幅修改（1 个文件，修改内容明确）

[Task]. Make the change, then [verify].

示例：

• 将 DB_URL 环境变量在所有使用位置都重命名为 DATABASE_URL。修改文件后，运行测试套件。
• 在 @components/UserForm.tsx 的“Save”按钮旁添加一个“Cancel”按钮。沿用现有的按钮样式。

模板 C — 中等规模修改，先制定计划

[Task]. Make a plan and run it by me before writing code.

示例：

• 将内存中的速率限制器替换为 Redis。先制定计划，再在修改文件前征求确认。
• 身份验证中间件正在日志中泄露会话令牌——修复此问题。先制定计划。

模板 D — 构建 / UI 工作，带反馈循环

[Task]. Use [feedback tool] to check after each change. Iterate until [success criterion].

示例：

• 实现深色主题，使其与 @design/dark-mock.png 匹配。使用 puppeteer 截取页面，和设计稿进行对比并反复调整，直到视觉效果接近。
• 根据 @design/pricing.fig 导出文件构建 /pricing 页面。每次修改后，分别在桌面和移动端宽度下截图。反复调整，直到两者都匹配。
• 修复 @tests/checkout.test.ts 中失败的测试。每次修改后都运行测试套件。

模板 E — 更大规模的功能，先探索再制定计划

[Feature]. First explore the codebase to find similar patterns. Then make a plan and ask for approval. After implementing, run [verification].

示例：

• 为所有管理员操作添加审计日志。先查看代码库中现有日志记录的实现方式，再提出计划，并在编写代码前征求确认。实现后，运行测试套件。

模板 F — Git / GitHub 操作

commit, push, PR

就写这些词。Claude 会读取 git log，以匹配项目的提交格式；如有需要，会创建分支，然后推送并创建 PR。不要过度指定。

模板 G — 修复错误（修复根因，而非表象）

[Bug description, including how to reproduce]. Find the root cause, don't just patch the symptom. Make a plan first.

第 4 步 — 添加可选增强项（适用时）

这些小补充往往效果显著：

添加内容	适用情况
@path/to/file.ts	任务以某个特定文件为核心时。
Look through git history	了解现有代码的“原因”很重要时。
Don't change [X]	需要明确划定禁区时（比正面说明要改什么更有效）。

第 5 步 — 输出

向用户返回两项内容：

1. 最终提示词，放在围栏代码块中，方便复制粘贴。
2. 一行说明，解释提示词为何采用这种结构（应用了哪 1–2 条原则）。

如适用，再补充一条简短建议：

• 如果提示词两次或更多次提及相同的架构／风格信息，建议将其移至 CLAUDE.md。
• 如果用户接下来要编写许多类似的提示词，建议改为编写一个 /slash-command。

输出示例

以下示例展示了此技能的输出。请注意，提示词都很简短，说明也只有一句话。

示例 1 — 用户提供的信息完整

用户：“我想让 Claude Code 为我的 Express 应用添加 JWT 身份验证。项目里有测试。”

技能输出：

Add JWT auth to the Express app. Look at how existing middleware is structured first, then make a plan and run it by me. After implementing, run the test suite and iterate until it passes.

使用模板 E（中等规模功能，先探索和规划，再迭代反馈），因为项目有可供验证的测试套件。

示例 2 — 用户提供的信息含糊，技能提出了问题

用户：“帮我写个提示词，让 Claude 修复我的 CSS。”

技能提问：

• “CSS 哪里出了问题？”——选项：布局错乱／颜色不对／响应式问题／不知道，让 Claude 自行判断
• “Claude 能否直观检查结果？”——选项：可以，截屏检查／可以，我来目测／我有视觉回归测试

用户回答后（例如：“移动端布局错乱”＋“可以，截屏检查”）：

The mobile layout on @pages/Home.tsx is broken. Screenshot it at 375px wide using puppeteer, find what's off, fix it, and re-screenshot. Iterate until the layout looks right.

使用模板 D（反馈循环），因为 puppeteer 能让 Claude 自行验证。

示例 3 — 用户提供了现有提示词，要求改进

用户：粘贴一段 30 行的提示词，里面充斥着架构细节和风格规则

技能回应：找出可复用的上下文（架构、风格、常用命令），建议将其移至 CLAUDE.md，让提示词本身聚焦于任务。

Implement the payment retry logic described in @docs/retry-spec.md. Plan first, ask before writing code, then run the test suite.

原提示词有 30 行，其中 25 行是重复的架构／风格上下文，应该放在 CLAUDE.md 中。仅保留与任务相关的部分。

反模式（请勿这样做）

• 客套的填充语（“请问能否帮我……”）。这会浪费上下文，模型也不在意。直接使用动词。
• 在每条提示词里重复粘贴相同的架构／风格说明。只需放进 CLAUDE.md 一次。
• 对有明确验证信号的任务，列出冗长的分步指令。给出验证信号，让模型自行迭代。
• 一次性要求实现一个 3000 行的功能。先要求制定计划，审核后再分阶段实现。
• 为了省用户时间而生成一份 200 行的“完美提示词”。这项技能的核心就是让提示词更短。如果输出比用户的问题还长，那就做错了。

此技能应移交任务的情况

此技能负责编写提示词，不负责运行它。生成提示词后：

• 用户通常会自行将其复制到 Claude Code 中。
• 如果用户说“现在运行它”，那就属于另一项任务，此技能的工作到此结束。