最近一段时间很多人都在转一个话题Anthropic 工程师在用新的 Claude Code 提示技巧。听到这种消息第一反应通常是去找一份“高级咒语清单”看看有没有能让 Claude Code 突然变聪明的句式。但我翻了一圈社区讨论和热搜词之后发现大家更关心的仍然是安装、403、乱码、怎么接本地模型、怎么和 Codex 比较这类基础问题。这说明一个很现实的情况多数人还没到拼技巧的阶段光是让 Claude Code 稳定跑起来就已经花了不少力气。而那些真正在用得不错的开发者关注点早就不是“提示词怎么写得更长”而是“怎么把提示变成一套规则、一份技能、一种可复用的协作方式”。这篇文章想聊的就是这件事。1. 先承认一个事实提示词不是越长越好1.1 Claude Code 不是聊天机器人是“带工具的实习生”Claude Code 和普通对话式 AI 最不一样的地方在于它可以读写文件、执行命令、搜索项目目录甚至调用外部的 MCP 服务。你给的提示本质上不是一段“问题”而是一份任务委托说明书。这意味着如果你只丢给它一句“帮我重构一下项目”它可能真的会动手改很多文件。改对了是运气改错了你要花更长时间收拾。它不是要把每个字都当成知识来回答而是要把你的意图翻译成一系列真实操作。所以提示技巧的核心从“让模型理解得更准”变成了“让模型在合适的边界内行动”。理解错了可以重说行动错了可能要回滚代码。1.2 所谓“新技巧”更接近一套规则化的工作方式我没有办法替 Anthropic 官方宣布某条具体的“内部提示词”因为这类信息往往是零散的、动态的也未必适合所有项目。但从工具本身的结构变化和社区实践来看那些被认为“很会提示”的人并不是掌握了什么神秘咒语。他们做的事情通常可以归纳成三个关键词规则化把项目的背景、规范、常用命令写进固定文件让 Claude Code 每次进入项目都能自动读到。技能化把经常要做的任务封装成一个可触发的 Skill避免每次重复描述操作流程。最小化上下文尽量不把整个项目粘贴进对话而是给它路径、命令和探索方法让它按需读取。这三件事看起来都不炫但它们才是真正改变使用体验的地方。相比在对话框里输入一段超长提示更像是在给 Claude Code 做一个“入职培训”。2. 把提示写进项目规则而不是留在对话框里2.1 CLAUDE.md 到底在解决什么问题用过几次 Claude Code 的人都会遇到一个场景每次新开会话它好像忘了前面说过什么。你需要重新介绍项目背景、目录结构、代码规范甚至反复提醒“不要动 migrations”。这非常消耗 token也容易让模型在关键任务上分心。一个自然的解法是把这些稳定不变的信息放到一个固定的 Markdown 文件里让工具每次启动时主动读取。在我接触的实践里最常见的文件名是CLAUDE.md也有人用CLAUDE.local.md区分项目级和用户级的规则。具体文件名和加载方式请以当前版本官方文档为准但思路是通用的。CLAUDE.md 解决的不是“提示词怎么写”而是“提示的重复劳动怎么降下来”。你不需要每次会话都重新交代背景只需要维护一份高质量的项目说明。2.2 一份够用的规则文件该包含什么很多人第一次写规则文件容易写成“项目介绍PPT”背景、愿景、价值观写了一大堆但对 Claude Code 的行为约束一点没有。真正有用的规则文件应该围绕“它会怎么动你的项目”来写。一个比较实用的结构是这样的# CLAUDE.md ## 项目背景 这是一个基于 FastAPI 的订单查询服务。 代码仓库在 monorepo 的 services/order 目录下。 ## 常用命令 - 启动uvicorn app.main:app --reload - 测试pytest tests/ -q - 格式化ruff format . ## 代码规范 - 数据库访问必须走 repositories 层禁止在路由直接写 SQL。 - 新增接口必须附带 pytest 测试。 - 不要修改 migrations 目录下已经执行的迁移文件。 - README 有架构说明修改依赖前先读一下。 ## 交付格式 完成一个任务后先列出改动文件清单再说明验证方式。 如果改了数据库结构额外说明迁移方案。这份文件不长但信息密度很高。它告诉 Claude Code 三件事项目边界在哪里、常用动作是什么、完成任务时怎么交付。这比你在提示词里临时写“你是一个资深工程师”有用得多。这里要注意一个边界规则文件不是一次写好的。真实项目里你可能要迭代几次才能找到最合适的描述方式。我通常的做法是先写最会影响行为的内容比如“哪些文件不能动”“测试命令是什么”等遇到一次越界行为再把对应的规则补进去。不要让规则文件变成一本没人看的说明书只保留会影响模型决策的内容。2.3 规则文件也会被忽略需要配合提示引用CLAUDE.md 不是万能的。它的加载优先级、长度限制、与系统提示的关系在不同版本里可能不一样。更常见的问题是当对话指令和规则文件冲突时模型通常会优先服从对话里更具体的指令。所以一个稳妥的做法是在关键任务里显式引用规则文件。比如“先读 CLAUDE.md然后按照其中‘代码规范’部分检查当前改动是否违规。”这不是重复交代而是告诉模型这份文件不是背景资料是本次任务的执行标准。工程经验里这种明确引用的效果比“请遵守项目规范”好很多。3. 用 Skills 把重复任务封装成“可触发技能”3.1 Skills 不是插件而是“可复用的操作手册”Claude Code 的能力边界一直在扩展除了 MCP另一个值得关注的是 Skills。简单理解Skills 是一组预定义的操作步骤和辅助文件模型在遇到匹配场景时可以用它来执行复杂任务。它和普通提示词的区别在于提示词是一次性的描述Skill 是可以反复触发的完整工作流。比如“做一次代码仓库健康检查”如果你每次都在对话框里写“请先看 package.json再看 src 目录统计 TODO然后输出报告”很啰嗦而且每次细节还不一样。如果封装成一个 Skill模型一旦识别到“仓库检查”这个意图就会自动按预设步骤执行。这对于团队协作尤其有价值。你不需要让每个成员都掌握一套复杂的提示词只需要维护一个公共的 Skill 目录大家都能用。3.2 一个最小 Skill 长什么样这里给出的是一个示例结构具体格式要对照你使用的 Claude Code 版本文档来调整repo-audit/ ├── SKILL.md └── scripts/ └── audit.pySKILL.md是这个技能的核心描述文件里面会写明这个技能是干什么的、什么时候触发、按什么步骤执行。一个很简化的示例--- name: repo-audit description: 当需要检查仓库结构、依赖安全或技术债时使用。 --- ## 执行步骤 1. 读取根目录的 README 和包管理配置文件。 2. 检查主要依赖版本标记明显过期的包。 3. 扫描代码中遗留的 TODO 和 FIXME。 4. 按严重程度输出问题清单并附上建议操作。为什么要有这样的文件因为它把一个模糊任务拆成了可验证的步骤。Claude Code 拿到这个 Skill 后不是自由发挥而是按你定义好的路径走。这大大降低了“它自己发挥过头”的风险。实际使用中最容易踩的坑有三个把 Skill 写得太长。模型处理长说明时同样会注意力分散尽量精简到关键步骤。没有写清楚触发条件。模型不知道什么时候该用Skill 就沦为摆设。过度封装。如果只是“让 Claude Code 写一段排序代码”没必要做一个 Skill只有任务步骤足够复杂、重复频率足够高才值得封装。3.3 Skills 与 MCP 的关系不要搞混Skills 和 MCP 是两件不同的事很多人刚接触时容易混淆。MCP 解决的是“Claude Code 怎么连上外部数据和工具”比如读取数据库、调用内部 API、操作文件系统。Skills 解决的是“当它连上这些工具之后按什么流程做事”。举个例子MCP 可以让 Claude Code 连接审阅数据库这是能力层而一个“数据库变更审阅” Skill 可以规定它先看哪些表、检查哪些字段、输出什么迁移建议这是流程层。实际项目中两者经常配合使用。但在配置顺序上我建议先把 MCP 的最小连通性验证通过再去封装 Skills。否则你封装的技能里有一半步骤会因为没有数据源而报错。另外MCP 服务如果涉及数据库或内网资源尽量使用专用只读账号权限最小化。Claude Code 越聪明越要控制它能碰到的边界。4. 省 token 的提示技巧核心是少给噪声4.1 别把整个项目都塞进提示很多人用 Claude Code 时有一个习惯为了让它“充分理解”把十几个文件内容全部粘贴进提示里。表面看是给足了上下文实际上效果反而变差。一方面token 消耗会快速上升长会话很容易撞到额度限制。另一方面模型被大量无关代码干扰后可能抓不住真正关键的信息。你给它 50 个文件的代码不如告诉它“先看src/services/order.py然后搜索paid_at字段的所有引用”。这才是省 token 的第一个技巧多给路径少给全文。Claude Code 本身有文件读写和执行命令的能力你可以让它先用ls、grep、find探索项目结构再决定读哪几个文件。这比一次性把所有内容塞进上下文更省也更容易定位问题。4.2 明确定义“完成标准”和“不要做什么”很多提示词写得不够好是因为只写了要做什么没写做到什么程度算完成也没写不能做什么。比如你让它“优化这个模块的代码”它可能改到一半觉得哪里都不顺眼顺手把别的模块也调整了。这时候你还要花时间审查哪些改动是多余的。更好的写法是“优化app/services/order.py里的查询逻辑目标是减少一次多余数据库查询。不要改动其他模块不要重构函数签名完成后输出 diff 和验证命令。”这段话同时规定了范围、目标和边界。模型不知道“优化”到底指什么但知道了“减少一次查询”是可验证的完成标准。这个技巧的核心不是“命令它”而是把任务变成一个有验收条件的工程需求。它减少的不仅是 token还有后续来回确认的成本。4.3 一次只做一件事先让它停下来汇报我见过很多失败的长任务都是因为一次性给了太多步骤“先重构 A再优化 B然后补测试最后更新文档。”听起来很高效实际上很危险。模型在前两步一旦理解偏差后面所有步骤都会在这个错误基础上继续执行。等你去检查时它已经“完成”了所有步骤错的不是一两个点而是一整条链。更稳妥的做法是拆步第一步只做 A完成后列出改动清单停下来。第二步确认没问题后再让它优化 B。第三步补测试。第四步更新文档。这种“小步执行 显式停止”的模式虽然看起来多花了几次交互但总耗时往往更少。因为每一步你都能验证输出成本是可控的。真正贵的不是多一次对话而是让模型在一长串错误假设中跑完所有步骤。5. 提示技巧落地前先解决环境问题5.1 安装完成后先跑通最小会话很多人安装 Claude Code 后第一件事就是打开大型项目结果遇到各种报错。我的建议是先在一个空目录里跑通一个最小会话。比如创建一个临时文件夹运行 Claude Code输入一个最简单的指令“输出 hello不要做其他操作”。确认工具能正常响应再进入真实项目。这一步能帮你区分两类问题是工具本身没装好还是项目上下文太复杂导致异常。如果你看到类似unable to connect或api.anthropic.com返回错误先不要急着重装。按下面这个顺序排查。5.2 常见报错排查链路遇到问题不要直接问“为什么报错”而是先判断问题发生在哪一层。一个比较通用的排查顺序是现象 → 输入 → 环境 → 参数 → 工具边界。现象优先检查说明连接失败 / 网络超时DNS、网络连通性、企业网关策略先确认基础网络环境再查工具本身请求返回 403API Key 是否有效、账户权限、请求头报错信息通常会给出更具体的原因安装时 PowerShell 报错执行策略、Node.js 版本、 npm 权限先看完整报错行再决定改哪一项终端显示乱码代码页、PowerShell 输出编码Windows 下可先切换到 UTF-8 再启动无法保存会话历史会话日志目录权限、磁盘空间检查当前用户的写权限以 403 为例常见原因包括API Key 未设置或已失效、账户没有访问对应模型的权限、请求头格式异常、服务提供方策略限制。排查时不要一上来就改代码先确认环境变量里ANTHROPIC_API_KEY是否正确设置再去官方状态页和服务文档确认当前是否有限流或故障。如果错误信息里出现了model route之类的字段说明问题很可能出在模型名称或网关路由配置上而不是提示词写错了。还有一种情况是终端乱码。在 Windows PowerShell 里如果中文或特殊字符显示乱码通常是编码问题。可以先把终端切到 UTF-8 试试chcp 65001 $OutputEncoding [Console]::OutputEncoding [System.Text.Encoding]::UTF8如果 PowerShell 本身限制脚本执行你可能会看到权限类报错。使用Set-ExecutionPolicy -Scope CurrentUser RemoteSigned可以解决部分情况但前提是你清楚这个命令对系统安全策略的影响。5.3 VSCode、IDEA、本地模型的边界要说清楚很多人在 VSCode 或 IDEA 里使用 Claude Code 插件本质上是把同一个核心工具嵌进了编辑器。好处是可以一边看代码一边操作但问题也容易混淆到底是插件的问题还是底层 CLI 的问题。排查时我会先脱离编辑器在终端里直接运行命令。如果终端正常说明问题多半出在插件的配置、路径或权限上如果终端也报错那就要回到底层工具排查。至于 Ollama、DeepSeek、CC Switch 这类社区接入方案我不否定它们的实验价值尤其适合想本地测试或降低成本的人。但必须提醒这类配置通常不在官方支持范围内版本升级可能会随时破坏兼容性能力表现也和官方模型有明显差异。如果你只是学习可以折腾如果要用于生产任务建议先把官方支持的链路跑通再决定是否切换到社区方案。另外和 Codex 的比较也经常出现在讨论里。我的判断是不要只看功能列表要看工具和你现有工作流的贴合度。Claude Code 的交互风格更接近终端 agentCodex 和 GitHub 生态结合得更紧。不同版本的上下文策略和工具调用方式也会变化选型前最好用自己的项目做一轮小样本验证而不是听别人说“哪个更强”。6. 把提示技巧沉淀成一套可复用流程6.1 我推荐的一个四步工作流现在回到最初的问题那些“很会提示”的人到底在用什么方法我觉得不是某一句提示词而是一套流程。这里分享一个我实际在用的四步工作流。第一步建模。写提示之前先想清楚任务的目标、输入、输出和边界。也就是回答四个问题要解决什么问题需要哪些文件和数据什么东西算完成绝对不要动什么第二步落规则。如果这个任务在这个项目里会重复出现把它写进 CLAUDE.md如果是一个跨项目通用的复杂流程封装成 Skill。不需要每次都在对话里重新写提示。第三步小样本验证。先用一条真实但影响可控的任务跑通流程。验证点包括模型是否读取了正确文件、输出是否符合格式、有没有越界操作。没有通过验证就不要急着扩大范围。第四步固化复盘。任务结束后把有效的提示模板、错误的边界、新发现的规则沉淀回规则文件或 Skill。这一步的价值是让下一次任务更快、更稳。这个框架并不复杂但它把提示行为从“每次随机发挥”变成了“持续积累资产”。6.2 什么情况下不需要这套流程如果你只是问一句“这段代码是什么意思”或者临时生成一段小工具脚本完全不需要又是写规则又是建 Skill过度设计反而耽误时间。需要上流程的是有以下特征的任务经常重复比如每周发布、定期代码审查、批量数据迁移。涉及多个文件容易越界。团队成员都要用需要统一行为。错误代价高比如生产环境变更、数据库操作。如果你的任务不满足这些特征直接写一个干净、具体的提示就好。先跑通再封装不要为了显得专业而制造复杂度。6.3 从“会聊天”到“会用 agent”的转变Claude Code 这类工具真正改变的不是“写提示词”这个动作而是人和工具的协作方式。以前我们使用 AI像是在搜索引擎里问问题期待一个答案现在使用 agent更像是在带一个手上有很多工具的新同事你需要给它目标、边界、反馈机制和长期记忆。这也是为什么我坚持认为提示技巧的重点不在于语言华丽而在于结构清晰。一份好的规则文件一段能准确描述完成标准的指令一个封装得当的 Skill都比一百句“请你仔细分析”有用。如果你现在还在被安装和 403 折磨不用焦虑。先把最小环境跑通再尝试写一条简洁的、有明确边界的指令。等你有了一次成功体验再慢慢把重复的部分固化下来。工具会不断更新但“让 AI 在受控范围内行动”这个原则不会变。我现在使用 Claude Code 时最先写的往往不是任务本身而是项目规则。因为我知道真正省时间的不是让模型一次做对而是让它在整个项目周期里都少跑偏。这个认知比任何一条“最新提示技巧”都更值得长期实践。 Claude Code提示技巧进阶：从规则文件到技能封装，构建可复用的AI协作流程
最近一段时间很多人都在转一个话题Anthropic 工程师在用新的 Claude Code 提示技巧。听到这种消息第一反应通常是去找一份“高级咒语清单”看看有没有能让 Claude Code 突然变聪明的句式。但我翻了一圈社区讨论和热搜词之后发现大家更关心的仍然是安装、403、乱码、怎么接本地模型、怎么和 Codex 比较这类基础问题。这说明一个很现实的情况多数人还没到拼技巧的阶段光是让 Claude Code 稳定跑起来就已经花了不少力气。而那些真正在用得不错的开发者关注点早就不是“提示词怎么写得更长”而是“怎么把提示变成一套规则、一份技能、一种可复用的协作方式”。这篇文章想聊的就是这件事。1. 先承认一个事实提示词不是越长越好1.1 Claude Code 不是聊天机器人是“带工具的实习生”Claude Code 和普通对话式 AI 最不一样的地方在于它可以读写文件、执行命令、搜索项目目录甚至调用外部的 MCP 服务。你给的提示本质上不是一段“问题”而是一份任务委托说明书。这意味着如果你只丢给它一句“帮我重构一下项目”它可能真的会动手改很多文件。改对了是运气改错了你要花更长时间收拾。它不是要把每个字都当成知识来回答而是要把你的意图翻译成一系列真实操作。所以提示技巧的核心从“让模型理解得更准”变成了“让模型在合适的边界内行动”。理解错了可以重说行动错了可能要回滚代码。1.2 所谓“新技巧”更接近一套规则化的工作方式我没有办法替 Anthropic 官方宣布某条具体的“内部提示词”因为这类信息往往是零散的、动态的也未必适合所有项目。但从工具本身的结构变化和社区实践来看那些被认为“很会提示”的人并不是掌握了什么神秘咒语。他们做的事情通常可以归纳成三个关键词规则化把项目的背景、规范、常用命令写进固定文件让 Claude Code 每次进入项目都能自动读到。技能化把经常要做的任务封装成一个可触发的 Skill避免每次重复描述操作流程。最小化上下文尽量不把整个项目粘贴进对话而是给它路径、命令和探索方法让它按需读取。这三件事看起来都不炫但它们才是真正改变使用体验的地方。相比在对话框里输入一段超长提示更像是在给 Claude Code 做一个“入职培训”。2. 把提示写进项目规则而不是留在对话框里2.1 CLAUDE.md 到底在解决什么问题用过几次 Claude Code 的人都会遇到一个场景每次新开会话它好像忘了前面说过什么。你需要重新介绍项目背景、目录结构、代码规范甚至反复提醒“不要动 migrations”。这非常消耗 token也容易让模型在关键任务上分心。一个自然的解法是把这些稳定不变的信息放到一个固定的 Markdown 文件里让工具每次启动时主动读取。在我接触的实践里最常见的文件名是CLAUDE.md也有人用CLAUDE.local.md区分项目级和用户级的规则。具体文件名和加载方式请以当前版本官方文档为准但思路是通用的。CLAUDE.md 解决的不是“提示词怎么写”而是“提示的重复劳动怎么降下来”。你不需要每次会话都重新交代背景只需要维护一份高质量的项目说明。2.2 一份够用的规则文件该包含什么很多人第一次写规则文件容易写成“项目介绍PPT”背景、愿景、价值观写了一大堆但对 Claude Code 的行为约束一点没有。真正有用的规则文件应该围绕“它会怎么动你的项目”来写。一个比较实用的结构是这样的# CLAUDE.md ## 项目背景 这是一个基于 FastAPI 的订单查询服务。 代码仓库在 monorepo 的 services/order 目录下。 ## 常用命令 - 启动uvicorn app.main:app --reload - 测试pytest tests/ -q - 格式化ruff format . ## 代码规范 - 数据库访问必须走 repositories 层禁止在路由直接写 SQL。 - 新增接口必须附带 pytest 测试。 - 不要修改 migrations 目录下已经执行的迁移文件。 - README 有架构说明修改依赖前先读一下。 ## 交付格式 完成一个任务后先列出改动文件清单再说明验证方式。 如果改了数据库结构额外说明迁移方案。这份文件不长但信息密度很高。它告诉 Claude Code 三件事项目边界在哪里、常用动作是什么、完成任务时怎么交付。这比你在提示词里临时写“你是一个资深工程师”有用得多。这里要注意一个边界规则文件不是一次写好的。真实项目里你可能要迭代几次才能找到最合适的描述方式。我通常的做法是先写最会影响行为的内容比如“哪些文件不能动”“测试命令是什么”等遇到一次越界行为再把对应的规则补进去。不要让规则文件变成一本没人看的说明书只保留会影响模型决策的内容。2.3 规则文件也会被忽略需要配合提示引用CLAUDE.md 不是万能的。它的加载优先级、长度限制、与系统提示的关系在不同版本里可能不一样。更常见的问题是当对话指令和规则文件冲突时模型通常会优先服从对话里更具体的指令。所以一个稳妥的做法是在关键任务里显式引用规则文件。比如“先读 CLAUDE.md然后按照其中‘代码规范’部分检查当前改动是否违规。”这不是重复交代而是告诉模型这份文件不是背景资料是本次任务的执行标准。工程经验里这种明确引用的效果比“请遵守项目规范”好很多。3. 用 Skills 把重复任务封装成“可触发技能”3.1 Skills 不是插件而是“可复用的操作手册”Claude Code 的能力边界一直在扩展除了 MCP另一个值得关注的是 Skills。简单理解Skills 是一组预定义的操作步骤和辅助文件模型在遇到匹配场景时可以用它来执行复杂任务。它和普通提示词的区别在于提示词是一次性的描述Skill 是可以反复触发的完整工作流。比如“做一次代码仓库健康检查”如果你每次都在对话框里写“请先看 package.json再看 src 目录统计 TODO然后输出报告”很啰嗦而且每次细节还不一样。如果封装成一个 Skill模型一旦识别到“仓库检查”这个意图就会自动按预设步骤执行。这对于团队协作尤其有价值。你不需要让每个成员都掌握一套复杂的提示词只需要维护一个公共的 Skill 目录大家都能用。3.2 一个最小 Skill 长什么样这里给出的是一个示例结构具体格式要对照你使用的 Claude Code 版本文档来调整repo-audit/ ├── SKILL.md └── scripts/ └── audit.pySKILL.md是这个技能的核心描述文件里面会写明这个技能是干什么的、什么时候触发、按什么步骤执行。一个很简化的示例--- name: repo-audit description: 当需要检查仓库结构、依赖安全或技术债时使用。 --- ## 执行步骤 1. 读取根目录的 README 和包管理配置文件。 2. 检查主要依赖版本标记明显过期的包。 3. 扫描代码中遗留的 TODO 和 FIXME。 4. 按严重程度输出问题清单并附上建议操作。为什么要有这样的文件因为它把一个模糊任务拆成了可验证的步骤。Claude Code 拿到这个 Skill 后不是自由发挥而是按你定义好的路径走。这大大降低了“它自己发挥过头”的风险。实际使用中最容易踩的坑有三个把 Skill 写得太长。模型处理长说明时同样会注意力分散尽量精简到关键步骤。没有写清楚触发条件。模型不知道什么时候该用Skill 就沦为摆设。过度封装。如果只是“让 Claude Code 写一段排序代码”没必要做一个 Skill只有任务步骤足够复杂、重复频率足够高才值得封装。3.3 Skills 与 MCP 的关系不要搞混Skills 和 MCP 是两件不同的事很多人刚接触时容易混淆。MCP 解决的是“Claude Code 怎么连上外部数据和工具”比如读取数据库、调用内部 API、操作文件系统。Skills 解决的是“当它连上这些工具之后按什么流程做事”。举个例子MCP 可以让 Claude Code 连接审阅数据库这是能力层而一个“数据库变更审阅” Skill 可以规定它先看哪些表、检查哪些字段、输出什么迁移建议这是流程层。实际项目中两者经常配合使用。但在配置顺序上我建议先把 MCP 的最小连通性验证通过再去封装 Skills。否则你封装的技能里有一半步骤会因为没有数据源而报错。另外MCP 服务如果涉及数据库或内网资源尽量使用专用只读账号权限最小化。Claude Code 越聪明越要控制它能碰到的边界。4. 省 token 的提示技巧核心是少给噪声4.1 别把整个项目都塞进提示很多人用 Claude Code 时有一个习惯为了让它“充分理解”把十几个文件内容全部粘贴进提示里。表面看是给足了上下文实际上效果反而变差。一方面token 消耗会快速上升长会话很容易撞到额度限制。另一方面模型被大量无关代码干扰后可能抓不住真正关键的信息。你给它 50 个文件的代码不如告诉它“先看src/services/order.py然后搜索paid_at字段的所有引用”。这才是省 token 的第一个技巧多给路径少给全文。Claude Code 本身有文件读写和执行命令的能力你可以让它先用ls、grep、find探索项目结构再决定读哪几个文件。这比一次性把所有内容塞进上下文更省也更容易定位问题。4.2 明确定义“完成标准”和“不要做什么”很多提示词写得不够好是因为只写了要做什么没写做到什么程度算完成也没写不能做什么。比如你让它“优化这个模块的代码”它可能改到一半觉得哪里都不顺眼顺手把别的模块也调整了。这时候你还要花时间审查哪些改动是多余的。更好的写法是“优化app/services/order.py里的查询逻辑目标是减少一次多余数据库查询。不要改动其他模块不要重构函数签名完成后输出 diff 和验证命令。”这段话同时规定了范围、目标和边界。模型不知道“优化”到底指什么但知道了“减少一次查询”是可验证的完成标准。这个技巧的核心不是“命令它”而是把任务变成一个有验收条件的工程需求。它减少的不仅是 token还有后续来回确认的成本。4.3 一次只做一件事先让它停下来汇报我见过很多失败的长任务都是因为一次性给了太多步骤“先重构 A再优化 B然后补测试最后更新文档。”听起来很高效实际上很危险。模型在前两步一旦理解偏差后面所有步骤都会在这个错误基础上继续执行。等你去检查时它已经“完成”了所有步骤错的不是一两个点而是一整条链。更稳妥的做法是拆步第一步只做 A完成后列出改动清单停下来。第二步确认没问题后再让它优化 B。第三步补测试。第四步更新文档。这种“小步执行 显式停止”的模式虽然看起来多花了几次交互但总耗时往往更少。因为每一步你都能验证输出成本是可控的。真正贵的不是多一次对话而是让模型在一长串错误假设中跑完所有步骤。5. 提示技巧落地前先解决环境问题5.1 安装完成后先跑通最小会话很多人安装 Claude Code 后第一件事就是打开大型项目结果遇到各种报错。我的建议是先在一个空目录里跑通一个最小会话。比如创建一个临时文件夹运行 Claude Code输入一个最简单的指令“输出 hello不要做其他操作”。确认工具能正常响应再进入真实项目。这一步能帮你区分两类问题是工具本身没装好还是项目上下文太复杂导致异常。如果你看到类似unable to connect或api.anthropic.com返回错误先不要急着重装。按下面这个顺序排查。5.2 常见报错排查链路遇到问题不要直接问“为什么报错”而是先判断问题发生在哪一层。一个比较通用的排查顺序是现象 → 输入 → 环境 → 参数 → 工具边界。现象优先检查说明连接失败 / 网络超时DNS、网络连通性、企业网关策略先确认基础网络环境再查工具本身请求返回 403API Key 是否有效、账户权限、请求头报错信息通常会给出更具体的原因安装时 PowerShell 报错执行策略、Node.js 版本、 npm 权限先看完整报错行再决定改哪一项终端显示乱码代码页、PowerShell 输出编码Windows 下可先切换到 UTF-8 再启动无法保存会话历史会话日志目录权限、磁盘空间检查当前用户的写权限以 403 为例常见原因包括API Key 未设置或已失效、账户没有访问对应模型的权限、请求头格式异常、服务提供方策略限制。排查时不要一上来就改代码先确认环境变量里ANTHROPIC_API_KEY是否正确设置再去官方状态页和服务文档确认当前是否有限流或故障。如果错误信息里出现了model route之类的字段说明问题很可能出在模型名称或网关路由配置上而不是提示词写错了。还有一种情况是终端乱码。在 Windows PowerShell 里如果中文或特殊字符显示乱码通常是编码问题。可以先把终端切到 UTF-8 试试chcp 65001 $OutputEncoding [Console]::OutputEncoding [System.Text.Encoding]::UTF8如果 PowerShell 本身限制脚本执行你可能会看到权限类报错。使用Set-ExecutionPolicy -Scope CurrentUser RemoteSigned可以解决部分情况但前提是你清楚这个命令对系统安全策略的影响。5.3 VSCode、IDEA、本地模型的边界要说清楚很多人在 VSCode 或 IDEA 里使用 Claude Code 插件本质上是把同一个核心工具嵌进了编辑器。好处是可以一边看代码一边操作但问题也容易混淆到底是插件的问题还是底层 CLI 的问题。排查时我会先脱离编辑器在终端里直接运行命令。如果终端正常说明问题多半出在插件的配置、路径或权限上如果终端也报错那就要回到底层工具排查。至于 Ollama、DeepSeek、CC Switch 这类社区接入方案我不否定它们的实验价值尤其适合想本地测试或降低成本的人。但必须提醒这类配置通常不在官方支持范围内版本升级可能会随时破坏兼容性能力表现也和官方模型有明显差异。如果你只是学习可以折腾如果要用于生产任务建议先把官方支持的链路跑通再决定是否切换到社区方案。另外和 Codex 的比较也经常出现在讨论里。我的判断是不要只看功能列表要看工具和你现有工作流的贴合度。Claude Code 的交互风格更接近终端 agentCodex 和 GitHub 生态结合得更紧。不同版本的上下文策略和工具调用方式也会变化选型前最好用自己的项目做一轮小样本验证而不是听别人说“哪个更强”。6. 把提示技巧沉淀成一套可复用流程6.1 我推荐的一个四步工作流现在回到最初的问题那些“很会提示”的人到底在用什么方法我觉得不是某一句提示词而是一套流程。这里分享一个我实际在用的四步工作流。第一步建模。写提示之前先想清楚任务的目标、输入、输出和边界。也就是回答四个问题要解决什么问题需要哪些文件和数据什么东西算完成绝对不要动什么第二步落规则。如果这个任务在这个项目里会重复出现把它写进 CLAUDE.md如果是一个跨项目通用的复杂流程封装成 Skill。不需要每次都在对话里重新写提示。第三步小样本验证。先用一条真实但影响可控的任务跑通流程。验证点包括模型是否读取了正确文件、输出是否符合格式、有没有越界操作。没有通过验证就不要急着扩大范围。第四步固化复盘。任务结束后把有效的提示模板、错误的边界、新发现的规则沉淀回规则文件或 Skill。这一步的价值是让下一次任务更快、更稳。这个框架并不复杂但它把提示行为从“每次随机发挥”变成了“持续积累资产”。6.2 什么情况下不需要这套流程如果你只是问一句“这段代码是什么意思”或者临时生成一段小工具脚本完全不需要又是写规则又是建 Skill过度设计反而耽误时间。需要上流程的是有以下特征的任务经常重复比如每周发布、定期代码审查、批量数据迁移。涉及多个文件容易越界。团队成员都要用需要统一行为。错误代价高比如生产环境变更、数据库操作。如果你的任务不满足这些特征直接写一个干净、具体的提示就好。先跑通再封装不要为了显得专业而制造复杂度。6.3 从“会聊天”到“会用 agent”的转变Claude Code 这类工具真正改变的不是“写提示词”这个动作而是人和工具的协作方式。以前我们使用 AI像是在搜索引擎里问问题期待一个答案现在使用 agent更像是在带一个手上有很多工具的新同事你需要给它目标、边界、反馈机制和长期记忆。这也是为什么我坚持认为提示技巧的重点不在于语言华丽而在于结构清晰。一份好的规则文件一段能准确描述完成标准的指令一个封装得当的 Skill都比一百句“请你仔细分析”有用。如果你现在还在被安装和 403 折磨不用焦虑。先把最小环境跑通再尝试写一条简洁的、有明确边界的指令。等你有了一次成功体验再慢慢把重复的部分固化下来。工具会不断更新但“让 AI 在受控范围内行动”这个原则不会变。我现在使用 Claude Code 时最先写的往往不是任务本身而是项目规则。因为我知道真正省时间的不是让模型一次做对而是让它在整个项目周期里都少跑偏。这个认知比任何一条“最新提示技巧”都更值得长期实践。