直接答案
高质量提示词不是堆叠修饰词，而是明确范围、约束、证据和停止条件。
这篇内容解决什么问题
帮助开发者建立可复用的 Claude Code 提示与规划方法。
一个可执行提示词的五个组成部分
有效提示应说明目标、相关范围、不可违反的约束、期望交付物和验证方式。Claude 可以自己探索实现细节，但无法猜出团队未写明的业务边界。
文件路径、错误文本、现有实现范例和测试命令比“认真思考”更有价值。范围不确定时可以先要求只读探索，再逐步收敛。
- 目标：用户可观察到的结果。
- 范围：优先检查的目录、文件或模块。
- 约束：依赖、兼容性、禁止修改项。
- 交付：代码、测试、文档或分析报告。
- 验证：测试、构建、lint、截图或复现步骤。
修复 src/auth 中会话过期后的登录失败。先阅读现有 token refresh 实现，
不要新增依赖，也不要修改数据库结构。先写失败测试，再修复根因，
运行 auth 模块测试和 typecheck，最后列出证据与剩余风险。
用 Explore、Plan、Implement、Verify 四阶段工作
Plan 模式允许 Claude 读取和分析，但不直接编辑。适合跨文件改动、架构取舍或不熟悉的代码区。先探索现状，再形成能被人审查的计划，退出 Plan 后实施。
计划应包含具体文件、数据流、迁移或兼容风险、测试和不做事项。只有目标清楚但实现仍有选择时，计划才真正降低返工。
- 01Explore限定目录，定位真实实现、测试和历史约束。
- 02Plan列出文件级改动、风险和验证命令，等待确认。
- 03Implement按确认计划编辑，遇到新事实及时暂停。
- 04Verify运行机器可读检查并审查最终 diff。
保持 Plan 模式。分析新增 OAuth 登录需要修改哪些文件、会话数据如何流转、
需要哪些测试以及哪些内容明确不在本次范围；先不要写代码。小任务不要为了流程而规划
Plan 模式有上下文和时间成本。改拼写、增加明确日志或执行已定义的机械变更，可以直接要求修改并验证。
判断方法很简单：如果你能用一句话准确描述预期 diff，通常无需正式计划；如果连涉及哪些模块都不确定，应先探索。
给 Claude 一个它能运行的判定器
测试退出码、构建、lint、固定输入输出或浏览器截图都能形成反馈闭环。没有验证信号时，Claude 只能在实现“看起来正确”时停止。
要求展示实际命令和关键结果，而不是只说“已经验证”。对于关键改动，可让新子代理依据需求和 diff 做独立复核。
完成后运行 `pnpm test auth` 和 `pnpm typecheck`。如果失败，读取错误并修复，
直到检查通过或遇到需要我决策的真实阻塞。最终报告命令、结果和未验证项。尽早纠偏，并在上下文污染后重开
发现 Claude 走错方向时立即按 Esc 停止，指出具体错误事实和新约束。不要等它完成大批无关改动后再整体否定。
同一问题连续纠正两次仍偏离时，用 /clear 开启干净上下文，把刚学到的约束写进新的首条提示。无关任务也应分开会话，避免旧日志和失败方案干扰当前判断。
/clear
/compact 只保留已确认的接口约束、修改文件和验证命令直接提供高价值上下文
用 @ 引用文件、粘贴完整错误、附上截图或给出官方 API URL，比转述内容更准确。数据量很大时让 Claude 按需读取，而不是一次把所有日志塞进主上下文。
涉及业务选择时，可以要求 Claude 先采访你并把结论写成自包含规格。随后用新会话执行规格，给实现阶段保留干净上下文。
我要增加批量导入功能。先就数据格式、错误策略、幂等、权限、性能和 UX 采访我。
不要问代码已经能回答的问题。确认边界后把完整规格写入 SPEC.md，暂不实现。官方来源与核验范围
本文以公开官方文档为事实依据；命令和配置可能随客户端版本变化，执行前请同时核对对应来源。
查看技术核验方法