6 个来自 Anthropic 工程师的 Claude 提示词：别再让 AI 猜你的真实需求
原文信息：
- 原文标题：*I borrowed Claude prompts from Anthropic engineers and immediately stopped wasting time on bad ones*
- 来源：XDA Developers
- 作者：Mahnoor Faisal
- 发布时间：2026-06-15
- 原文链接：https://www.xda-developers.com/i-borrowed-claude-prompts-from-anthropic-engineers/
- 说明：本文基于原文整理为中文分享文章。原文中的提示词保留英文原文，便于直接复制使用。
很多人使用 AI 时，问题不在于模型“不够聪明”，而在于提示词太含糊：
“帮我做一下，要做得好一点。”
这类请求把需求、约束、判断标准都丢给模型猜。结果往往是：AI 写得很快，但你不一定看得懂；方案看似完整，但关键边界没问清；一次会话解决了问题，下次又要重新解释项目背景。
XDA 这篇文章整理了几组来自 Anthropic 工程师和 Claude 提示词库的实际用法。它们的共同点不是“措辞更高级”，而是把 AI 协作拆成几个更可靠的动作：解释、教学、访谈、计划、固化流程、沉淀记忆。
下面是最值得直接借用的 6 个提示词。
1. 让 Claude Code 一边后台执行，一边用白话解释
使用场景：
当你让 Claude Code 处理一个自己不完全懂的任务时，例如改前端、查代码结构、修一个不熟悉的报错。你不希望它只刷一堆开发者日志，而是希望它边做边解释。
原始提示词：
This is my prompt: "prompt here"
Can you spin off an async background agent to do this and then periodically poll it as it does work and summarize what is happening.
I'm not technical at all so please summarize it in a simple way for me. Use the explore agent to summarize how things work (that the other agent is working on) so I can learn while I do this. If the background agent runs into any errors, please stop and tell me but guide me in how I might be able to fix it.
Remember I am non technical, so any technical language at all is not useful to me.使用案例：
你可以把第一行的 "prompt here" 替换成真实任务，例如：
This is my prompt: "帮我检查这个项目为什么登录接口返回 500，并修复它。"
Can you spin off an async background agent to do this and then periodically poll it as it does work and summarize what is happening.
I'm not technical at all so please summarize it in a simple way for me. Use the explore agent to summarize how things work (that the other agent is working on) so I can learn while I do this. If the background agent runs into any errors, please stop and tell me but guide me in how I might be able to fix it.
Remember I am non technical, so any technical language at all is not useful to me.预期效果：
这个提示词的重点是把“执行”和“解释”拆开：后台 agent 负责实际工作，主会话定期检查进展并用非技术语言解释；如果出错，Claude 要停下来说明问题，而不是继续堆日志。对非技术用户有用，对技术用户也有用，因为它能让你在不熟悉的代码域里快速建立上下文。
2. 让 Claude 像老师一样确认你真的理解
使用场景：
AI 已经能写出代码，但你担心自己只是“看起来懂了”。这个提示词适合用在代码改动、复杂 bug 修复、业务逻辑梳理之后，让 Claude 逐步教你理解问题和方案。
原始提示词：
you are a wise and incredibly effective teacher. your goal is to make sure the human deeply understands the session.
do this incrementally with each step instead of all at once at the end. before moving on to the next stage, you should confirm that she has mastered everything in the current one. this should be high level (e.g. motivation) and low level (e.g. business logic, edge cases).
keep a running md doc with a checklist of things the human should understand. make sure she understands 1) the problem, why the problem existed, the different branches 2) the solution, why it was resolved in that way, the design decisions, the edge cases 3) the broader context of why this matters, what the changes will impact.
make sure she understands why (and drill down into more whys), make sure she understands what and how as well. understanding the problem well is imperative.
to get a sense of where she's at, proactively have her restate her understanding first. then help her fill in the gaps from there—she might ask you questions or ask to eli5, eli14, or elii (explain like she's an intern).
quiz her with open-ended or multiple choice questions with AskUserQuestion (be sure to change up the order of the correct answer, and to not reveal the answer until after the questions are submitted). show her code or have her use the debugger if necessary!
/goal the session should not end until you've verified that the human has demonstrated that she understood everything on your list.使用案例：
比如 Claude 刚修完一个支付状态流转 bug，你可以接着要求它：用这个提示词检查你是否理解了“问题为什么发生、为什么这样修、还有哪些边界条件”。
预期效果：
它会把一次性解释变成分阶段教学：先让你复述，再补齐理解缺口，再用开放题或选择题检查。最后的 /goal 是关键，它把“用户真的理解”设成会话结束条件，而不是让 Claude 自说自话。
3. 让 Claude 在写方案前先深度访谈你
使用场景：
你想做一个功能，但需求还没完全想清楚。直接让 Claude 写实现，很容易遗漏 UI、边界条件、技术取舍，后面返工。
原始提示词：
read this @SPEC.md and interview me in detail using the AskUserQuestionTool about literally anything: technical implementation, UI & UX, concerns, tradeoffs, etc. but make sure the questions are not obvious
be very in-depth and continue interviewing me continually until it's complete, then write the spec to the file使用案例：
你可以先写一个粗略的 SPEC.md，只包含目标和基本需求，然后让 Claude 用这个提示词继续追问：异常状态怎么处理、权限边界是什么、页面为空时显示什么、哪些方案不接受、是否需要兼容旧数据。
预期效果：
这个提示词把 Claude 从“接单执行者”变成“需求访谈者”。它和 Plan mode 的目标类似：先把思考做完，再写代码。区别在于，Plan mode 偏向让 Claude 给你计划；这个提示词偏向让 Claude 把你没说清的部分问出来。
4. 让 Claude 把实现计划做成 HTML，而不是长篇 Markdown
使用场景：
当实现计划很长，里面有模块关系、数据流、界面草图、关键代码片段时，普通 Markdown 很容易变成一堵文字墙。原文提到，Thariq 认为 HTML 在这类场景里更适合分享和阅读。
原始提示词：
Create a thorough implementation plan in an HTML file, be sure to make some mockups, show data flow, and add important code snippets I might want to review. Make it easy to read and digest.使用案例：
你准备实现一个后台管理页面，可以让 Claude 输出一个 HTML 计划页：顶部是目标和范围，中间是 mockup，下面是数据流和关键接口，最后列出需要评审的代码片段。
预期效果：
HTML 可以放图表、颜色、表格、交互控件和可复制代码块，打开浏览器就能看。对需要分享给团队或客户的方案，比一份很长的 Markdown 更容易消化。
但这里也要保留一个判断：HTML 更适合展示和评审，不一定更适合作为长期工程文档。长期维护、版本 diff、代码仓库协作时，Markdown 仍然有优势。
5. 把重复任务做成 Skill
使用场景：
如果你反复让 Claude 做同一套流程，比如“跑 linter、跑测试、整理 commit message”，就不该每次都重新解释。原文给出的做法是把它固化为 Skill。
原始提示词：
create a [/ship] skill for this project that [runs the linter and tests, then drafts a commit message]使用案例：
你可以把方括号里的内容换成项目里的真实流程：
create a [/release-check] skill for this project that [runs unit tests, checks formatting, verifies changelog, then drafts a release note]预期效果：
以后你只需要触发 /ship 或类似命令，Claude 就知道该执行哪套固定步骤。它的价值不是少打几个字，而是减少流程漂移：每次都按同一标准检查，而不是靠临时想起来。
6. 让 Claude 总结本次会话，建议写入 CLAUDE.md
使用场景：
一次 Claude Code 会话里，模型通常会发现很多项目事实：目录结构、测试命令、编码风格、踩过的坑、某个错误的修复方式。如果这些信息不沉淀，下次会话又要重新摸索。
原始提示词：
summarize what we did this session and suggest what to add to CLAUDE.md使用案例：
在一次较长的开发会话结束前，让 Claude 总结：本次改了什么、发现了哪些项目约定、哪些命令有效、哪些错误不要再犯。然后你人工筛选，只有真正长期有效的信息才写入 CLAUDE.md。
预期效果：
CLAUDE.md 是 Claude Code 启动时会读取的项目记忆文件。这个提示词让 Claude 主动提出“下次值得记住什么”，但最后仍需要人审核，避免把临时状态、一次性任务结果或过期信息写成长期规则。
这 6 个提示词背后的真正方法
这些提示词值得保存，不是因为它们用了某个神奇句式，而是因为它们对应了 6 个更稳定的协作原则：
- 不要让 AI 默默执行，要让它解释过程。
- 不要默认自己懂了，要让 AI 检查理解。
- 不要急着写代码，先让 AI 问出遗漏需求。
- 不要把复杂计划塞进文字墙，选择更适合评审的载体。
- 不要重复口述固定流程，把它变成 Skill。
- 不要让项目经验随会话消失，把长期有效信息写入项目记忆。
如果只记一句话：
好的提示词不是让模型“更会写”，而是让协作流程更不容易失控。
使用时的边界
这篇文章的经验主要来自 Claude Code 生态，尤其是 async background agent、explore agent、AskUserQuestionTool、Skill、CLAUDE.md 这些机制。换到其他 AI 工具时，不一定能原样执行，但背后的模式可以迁移：
- 有后台执行能力的工具：可以拆分“执行 agent”和“解释 agent”。
- 有交互提问能力的工具：可以用来做需求访谈和理解测验。
- 有项目记忆文件的工具：可以沉淀长期约定。
- 没有这些机制的普通聊天工具：仍然可以模拟其中一部分，例如要求它先提问、先列理解清单、再输出方案。
真正应该避免的是另一种极端：看到“提示词清单”就直接复制，却不思考它解决的流程问题。复制提示词只是第一步，把它改成适合自己项目的固定协作方式，才是长期收益所在。