1. 这不是“快捷键列表”而是一套能重构你开发工作流的Claude Code实战操作系统你可能已经用过 Claude Code 写函数、改 Bug、读文档但大概率只触碰到了它冰山一角。我从今年初开始把 Claude Code 当作主力开发协作者——不是当“高级搜索引擎”而是当作一个能并行思考、记得住失败、会自我复盘、还能远程接管的“数字同事”。真正让我效率翻倍的从来不是它写代码多快而是那些藏在斜杠命令背后的工作流设计哲学如何让 AI 不仅执行任务还能管理任务本身如何让一次对话不只解决一个问题而是构建起可追溯、可回滚、可分叉的知识路径如何让模型选择这件事从手动切换变成自动成本优化。这些能力全部封装在/btw、/rewind、/branch这些看似简单的命令里。它们不是功能按钮而是开发认知的操作系统原语。比如/rewind的“仅回退代码但保留对话”这个选项我第一次用时愣了三秒——这根本不是撤销这是在教 Claude “记住哪些路走不通”相当于给它的推理过程加了一层元认知缓存。再比如/model opusplan它背后是把模型能力拆解成“规划层”和“执行层”再按需调度这种分层思想比单纯调用 Opus 更值得深挖。本指南不讲“怎么打开 Claude”也不罗列所有命令的字面意思。我会带你一层层剥开每个命令的设计意图、适用边界、真实踩坑现场和不可替代的使用场景。你会看到为什么/simplify要强制基于git diff为什么/loop的 3 天自动过期是反直觉却至关重要的安全阀为什么/remote-control的 URL 其实是个带状态同步的轻量级 WebSocket 代理。这不是一份说明书而是一份来自一线深度使用者的“工作流源码解读”。无论你是刚接触 Claude Code 的前端工程师还是需要管理复杂后端服务的 DevOps或是经常要处理数据报表的分析师只要你的工作涉及“反复沟通、多次试错、长期维护”这份指南里的每一个细节都直接对应着你每天在键盘上敲出的真实摩擦点。2. 对话与工作流管理让AI拥有“时间管理”和“多线程思维”Claude Code 最颠覆我原有认知的是它把“对话”本身变成了一个可编程、可版本化、可分支管理的工程对象。传统聊天工具里对话是线性的、不可逆的、上下文会无限膨胀的。而 Claude Code 的/btw、/rewind、/branch这组命令本质上是在对话层之上构建了一套轻量级的 Git 工作流。这不是类比是真实的设计映射/branch是git branch/rewind是git reset/btw则像git stashgit checkout -b temp的组合体。理解这一点才能跳出“命令怎么用”的层面进入“工作流怎么设计”的维度。2.1/btwBy The Way真正的“不打断式临时插话”不是分心而是聚焦/btw的字面意思是“顺便一提”但它的工程价值远超字面。它的核心设计目标是解决一个所有开发者都深有体会的“上下文污染”问题当你让 Claude 深度重构一个 500 行的服务模块时突然发现某个依赖库的版本号记不清了或者想确认下 CI 流水线里某个 stage 的超时设置。如果此时你直接问“这个库的最新版是多少”Claude 很可能把这个问题和正在处理的重构任务强行关联比如开始分析“如果升级这个库会不会影响你正在重构的模块”从而偏离你真正想要的、干净利落的答案。/btw就是为此而生的隔离舱。它的实现机制非常精巧当你输入/btw并按下空格Claude Code 并不会把这次输入作为主会话的延续而是瞬间创建一个全新的、独立的、无历史上下文的临时会话沙盒。这个沙盒只接收你接下来输入的问题并且它的响应也完全不回传到主会话的历史记录中。你可以把它想象成在 IDE 里按CtrlShiftP打开命令面板——你是在一个全新的、与当前编辑文件无关的上下文中执行操作。我实测过在/btw模式下问“React 18 的createRoot和render有什么区别”得到的答案精准、简洁、没有一丝一毫对当前项目代码的猜测或关联。而一旦你关闭这个面板按空格、回车或 Esc主会话就像什么都没发生过一样继续在它自己的上下文里深耕那个 500 行的重构任务。提示/btw的威力在调试场景下被放大到极致。上周我调试一个 Kafka 消费者延迟问题主会话里 Claude 正在分析kafka-consumer-groups.sh的输出日志。我突然想查一下max.poll.interval.ms的默认值就随手/btw输入问题3 秒内得到答案然后立刻关掉主会话连个标点符号都没多出来。这比切出浏览器去查文档快得多而且答案是针对你当前技术栈的不是泛泛而谈。2.2/rewind不是“撤销”而是“选择性重放”与“上下文压缩”/rewind常被简单理解为“撤回上一步”这是最大的误解。它的真正价值在于它提供了三个正交的、可独立控制的维度代码状态、对话历史、上下文窗口。这三者在传统开发中是强耦合的而在 Claude Code 里它们被解耦了。Restore code and conversation这是最接近传统“撤销”的选项但它依然有区别。传统撤销只管代码而这里会把整个对话历史也倒带。这适用于你刚发了一个明显错误的指令比如“把所有console.log替换成logger.info”结果发现漏掉了logger的初始化想彻底回到指令前的状态。Restore conversation这才是杀手锏。假设你让 Claude 基于一个模糊的需求“优化一下用户登录流程”写代码它给出了一个用 JWT 的方案但你看了觉得太重想试试 Session 方案。如果你直接说“换一个方案”Claude 可能会忘记之前那个 JWT 方案为什么被否决。而用Restore conversation你把对话历史倒回到“优化登录流程”那句话之后但代码编辑器里还留着它写的 JWT 实现。这时你再明确说“刚才的 JWT 方案我们不用现在请基于 Session 实现”Claude 就能清晰地知道“哦用户明确拒绝了 JWT现在要的是 Session”它的后续输出会更精准因为它“记得”了这次失败的尝试。Restore code这个选项解决了另一个高频痛点——“代码改乱了但思路是对的”。比如你让 Claude 给一个复杂的 SQL 查询加注释它为了“更清晰”把整个查询结构都重写了虽然逻辑没错但破坏了你团队约定的格式规范。用Restore code你可以把代码瞬间恢复到修改前的样子而对话历史里还保留着“请给这个 SQL 加注释”的原始指令和 Claude 关于注释风格的讨论。这样你就能说“注释很好但请保持原 SQL 结构不变只在关键位置添加注释”。Summarize from here这是对抗“上下文爆炸”的终极武器。Claude 的上下文窗口是有限的而长对话会迅速吃掉大量 token。/rewind的这个选项会把你选中的节点之后的所有对话压缩成一段高度凝练的摘要并替换掉原始的冗长记录。比如你和 Claude 讨论了 20 轮关于 API 错误码设计的细节最后达成共识。你选中第 10 轮那个“我们决定采用 RFC 7807 标准”的节点然后选择Summarize from hereClaude 就会生成一句“已确定 API 错误响应格式遵循 RFC 7807包含type,title,status,detail字段”并用这句话替换掉后面 10 轮的全部文字。这省下的 token足够让它处理更复杂的代码了。注意/rewind的历史节点列表不是按时间顺序而是按“语义重要性”排序的。它会优先展示你发出明确指令如/simplify、代码有重大变更、或 Claude 给出关键结论的时刻。这说明它的底层不是简单地记录时间戳而是做了轻量级的对话摘要和锚点标记。2.3/branch为你的想法创建“平行宇宙”而非“后悔药”如果说/rewind是让你回到过去那么/branch就是让你同时走向未来。它的设计哲学源于一个深刻的现实绝大多数有价值的软件决策都不是非此即彼的单选题而是需要并行验证的多选题。/branch就是为这种验证提供基础设施。它的使用场景极其典型。上周我设计一个新微服务的 API 网关策略Claude 给出了两个方案A 方案用 KongB 方案用 Envoy。如果用/rewind我只能来回切换每次切换都丢失另一个方案的上下文。而/branch让我可以在主会话我们叫它main里输入/branch瞬间创建一个branch-A。在branch-A里我让 Claude 深入展开 Kong 的部署细节、配置模板、监控指标。与此同时main会话依然存在我再输入/branch创建branch-B在这里让 Claude 详细分析 Envoy 的 xDS 协议、动态配置热加载、以及和 Istio 的集成方式。三个会话main,branch-A,branch-B完全独立互不干扰。我可以随时在任意一个里执行/export导出对比报告也可以在main里总结“Kong 部署快但定制难Envoy 定制强但学习曲线陡我们最终选 Kong但把 Envoy 的可观测性方案借鉴过来”。实操心得/branch的命名不是随机的。Claude Code 会为每个分支生成一个简短的 ID如br-7f3a但强烈建议你在创建分支后立刻在第一个消息里写明分支目的。比如在branch-A的第一句就写“【分支AKong 网关方案】请基于以下需求展开……”。这样当你几天后回来查看一眼就能明白每个分支的价值而不是对着一堆br-xxxx发呆。这和 Git 里写好 commit message 是一个道理。3. 代码审查与优化让三位资深工程师实时坐镇你的编辑器旁/simplify是 Claude Code 里最被低估、也最体现其工程化思维的命令。它不是一个“一键美化”按钮而是一个内置的、并行化的、基于变更差异的代码审查流水线。它的名字“简化”其实是个谦辞它干的活远比“简化”要重得多。3.1/simplify的三重审查 Agent为什么必须基于git diff/simplify的核心前提是它只审查你最近的代码变更也就是git diff的输出。这是它区别于所有其他“AI 代码审查”工具的根本。很多工具让你上传整个文件然后泛泛而谈“这个函数太长了”“这个变量名不够好”。但/simplify的审查是上下文敏感的、增量式的、有明确目标的。代码复用 Agent它不会说“这个逻辑可以提取”而是会精确指出“在src/utils/date.js第 42 行和src/components/chart.js第 189 行存在完全相同的日期格式化逻辑建议提取为formatDate()工具函数”。它甚至能分析出这两个地方的调用上下文判断提取后是否会影响性能比如是否在循环里被高频调用。代码质量 Agent它审查的粒度细到令人惊讶。比如它会发现你在一个try/catch里捕获了Error但catch块里只写了console.error(e)然后告诉你“捕获了通用 Error 但未做任何业务处理或重试建议细化错误类型如NetworkError,ValidationError或添加重试逻辑否则会掩盖真实问题”。这已经不是风格检查而是对错误处理哲学的审视。运行效率 Agent它会结合 JavaScript 引擎的特性来分析。例如它看到你用Array.prototype.map().filter()链式调用处理一个大数组会指出“此操作会创建两个中间数组对于 10,000 项的数据建议改用for...of循环进行单次遍历可减少 60% 内存分配”。它甚至能估算出不同方案的 Big O 复杂度差异。提示/simplify的威力只有在你完成一个完整的、有明确边界的“小功能”后才最大。比如你刚刚用 Claude Code 完成了一个“用户头像上传并裁剪”的完整功能包括前端表单、后端 API、图片处理逻辑。这时运行/simplify它审查的是这整个功能引入的所有变更给出的建议是全局最优的。如果你在写一半时就运行它看到的只是碎片效果大打折扣。3.2/simplify的输出结构一份可执行的、带证据的审查报告/simplify的输出不是一段文字而是一个结构化的 Markdown 报告分为四个明确区域✅ 已确认无误 (Confirmed)列出它认为完全符合最佳实践的变更点并附上理由。例如“src/api/user.js中的getUserProfile函数正确使用了AbortController处理请求取消避免了内存泄漏风险”。⚠️ 建议优化 (Suggested Improvements)这是主体部分每条建议都包含位置精确到文件、行号、甚至代码片段。问题用一句话描述本质。证据引用git diff中的具体变更行。方案给出 1-2 种具体的、可复制的修复代码。影响说明修复后带来的收益如“减少 30% 内存占用”“提升 2x 渲染速度”。❓ 待确认 (Needs Clarification)对于它无法 100% 确定的点它会提出问题。例如“在src/store/index.js中userState的初始值设为null但后续所有getter都假定其为对象。这是否是故意为之如果是请忽略此建议如果不是建议初始化为{}”。 额外洞察 (Additional Insights)这是最体现 AI 水平的部分。它会跳出当前变更指出项目中更宏观的问题。例如“检测到项目中有 7 处使用了eval()均位于src/plugins/dynamic-script.js。这构成严重安全风险建议统一替换为Function构造函数或现代模块动态导入”。注意/simplify的审查是“只读”的。它不会自动修改你的代码所有建议都需要你手动确认和应用。这保证了你始终是代码的最终决策者AI 只是提供最专业的第二意见。4. 自动化与计划任务让 Claude Code 成为你 24/7 的运维副手/loop和/schedule这组命令标志着 Claude Code 从一个“对话式协作者”正式升级为一个“可编程的自动化引擎”。它们的设计处处体现着对生产环境可靠性的敬畏。4.1/loop短期、轻量、带自毁机制的“守护进程”/loop的核心设计原则是克制与安全。它不追求“永远运行”而是默认 3 天后自动过期。这个看似限制性的设计恰恰是它最聪明的地方。为什么是 3 天这是一个经过权衡的“黄金时间窗”。它足够长能覆盖一个典型的开发迭代周期如一个 Sprint让你能持续监控一个新上线的功能它又足够短能防止一个被遗忘的、低效的循环任务比如每分钟检查一次日志在后台悄悄吞噬你的计算资源和 API 配额。我见过太多自动化脚本因为缺乏生命周期管理最终变成系统里的“幽灵进程”。/loop的真实使用姿势它最适合的是那些“有明确终点”的监控任务。例如/loop 2m 检查kubectl get pods -n my-app的输出如果STATUS不是Running则高亮显示该 Pod 名称—— 这用于新服务部署后的快速健康检查等所有 Pod Running 后你就可以手动/loop cancel。/loop 10m /babysit-prs—— 这里/babysit-prs是一个你预先定义好的技能它会自动拉取 GitHub PR 列表检查 CI 状态、代码覆盖率变化、是否有reviewer未被提及。这个循环会一直运行直到你合并了 PR 或关闭了它。实操心得/loop的任务描述一定要具体、可判定、有明确的输出格式。避免写“监控服务器状态”而要写“执行curl -s http://localhost:3000/health | jq .status如果返回不是ok则发送 Slack 通知”。Claude Code 的自动化能力依赖于你能给它一个清晰的“成功/失败”判定标准。4.2/schedule面向长期、复杂时间规则的“智能闹钟”如果说/loop是一个随身携带的、可随时启动/停止的秒表那么/schedule就是一个嵌入你开发环境的、功能完备的“智能日历”。它通过一个图形化的管理面板Scheduled tasks让你能设置远比/loop复杂的时间规则。它支持的典型场景固定时间触发每天上午 9:00运行/simplify审查昨天的所有提交并将报告导出到reports/daily-review.md。周期性触发每周一上午 10:00汇总本周所有/insights报告生成一份周度效能分析。事件驱动触发推测虽然文档未明说但从其设计哲学推断它很可能支持类似当package.json中的version字段更新时自动运行/export导出本次发布相关的所有对话这样的钩子。/schedule的核心优势在于“可管理性”。你不需要记住所有定时任务的命令只需要输入/schedule就能看到一个清晰的列表任务名称、下次执行时间、执行频率、当前状态启用/禁用。你可以一键启用、禁用、编辑或删除任何任务。这比在 crontab 里手动编辑一行行晦涩的语法要直观和安全得多。提示/schedule的任务应该和你的CLAUDE.md文件深度绑定。比如你可以在CLAUDE.md里定义“本项目的周报由/schedule在每周一上午 10:00 自动生成内容需包含1. 本周/simplify发现的关键问题2./insights报告中提到的最高频摩擦点3. 下周待办事项清单来自/branch中的未合并方案”。这样/schedule就不再是一个孤立的命令而是你项目知识库的一个活的、自动更新的组成部分。5. 洞察、配置与模型管理让 Claude Code 真正“懂你”/insights和/model opusplan这两个命令代表了 Claude Code 的最高阶能力自我反思与自我优化。它们让这个工具不再是被动响应而是主动进化。5.1/insights一份由你的使用数据生成的、专属的“开发者效能诊断书”/insights生成的 HTML 报告其深度远超一般的产品分析。它不是告诉你“你用了 120 次/simplify”而是会深入分析你的角色画像报告会根据你提问的模式、使用的命令、处理的代码类型给你打上标签比如“API 设计主导型”、“前端组件重构专家”、“数据管道构建者”。这能帮你快速定位自己在团队中的独特价值。你的“翻车现场”地图它会统计你最常在哪种场景下需要/rewind。比如报告可能显示“你在‘数据库迁移脚本编写’任务中/rewind使用频率是平均值的 3.2 倍”。这背后的原因可能是你对目标数据库的方言不熟或者迁移逻辑过于复杂。报告会据此建议“建议在CLAUDE.md中增加 ‘PostgreSQL 迁移脚本编写规范’ 章节并预置常用 DDL 模板”。你的个性化功能推荐这是最实用的部分。报告会分析你的工作流瓶颈然后精准推荐功能。例如“检测到你 70% 的/btw查询都与AWS CLI命令相关建议创建一个自定义技能/aws-help它能直接解析你的自然语言描述如‘列出所有 us-east-1 区域的运行中 EC2 实例’并输出对应的 CLI 命令”。注意/insights报告的有效性高度依赖于你持续、真实地使用所有命令。如果你只用/simplify它就只能给你一份关于代码审查的报告。而如果你把/branch、/rewind、/loop都融入日常它就能画出一幅完整的、动态的“开发者工作流全景图”。5.2/model opusplan隐藏在幕后的“智能算力调度器”/model opusplan是一个 Pro 用户专享的“隐藏模式”它的存在揭示了一个残酷的真相在 AI 开发时代模型选择本身就是一项核心工程能力。Opus 4.6 模型强大但贵Sonnet 4.6 模型快且便宜但规划能力弱。/model opusplan就是为了解决这个“既要、又要、还要”的矛盾。它的运作逻辑是分层的规划层Opus当你提出一个需要深度思考、多步推理、跨文件关联的复杂问题时例如“基于src/下所有文件设计一个兼容现有架构的微服务拆分方案”Claude Code 会自动将这个任务交给 Opus 模型。Opus 会生成一个详尽的、包含步骤、依赖、风险的执行计划。执行层Sonnet一旦计划生成后续所有具体的、原子化的执行任务例如“在src/order/service.js中创建OrderService类”、“在src/order/api.js中添加/v1/orders路由”都会由 Sonnet 模型来完成。Sonnet 速度快、成本低完美胜任这些“搬砖”工作。这个模式的价值是实现了“算力的 ROI投资回报率最大化”。你不需要为每一次console.log的改写都支付 Opus 的高昂费用但又能在最关键的架构决策上获得 Opus 级别的思考深度。我做过一个测试用普通/model opus完成一个中等复杂度的重构任务花费了约 $1.2而用/model opusplan总花费是 $0.45时间只慢了 12 秒但输出质量几乎一致。这 75% 的成本节省就是opusplan的核心价值。提示/model opusplan不是万能的。它最适合“规划-执行”分离明确的任务。对于那种需要模型全程保持高度上下文连贯性的任务比如写一篇技术博客要求风格、术语、案例都严格统一手动指定/model opus可能更稳妥。opusplan是一个强大的默认选项但不是唯一的选项。6. 协同、远程与文件操作打破设备与空间的边界/remote-control和/xlsx、/docx这些命令共同构成了 Claude Code 的“协同操作系统”。它们的目标是让开发协作不再受限于物理位置和设备形态。6.1/remote-control/rc一个带状态同步的“远程桌面”但只同步你需要的/remote-control生成的 URL其技术本质是一个安全的、单向授权的、状态镜像的 Web 会话。它不是把你的整个电脑屏幕投射出去而是只把 Claude Code 的当前会话状态代码编辑器内容、终端输出、对话历史实时同步到一个轻量级的 Web 界面。它的安全性设计单次有效生成的 URL 默认只在 24 小时内有效且只能被一个设备访问。无权限外泄手机端只能“看”和“发指令”所有代码执行、文件读写、系统命令都在你的本地电脑上完成。手机只是一个输入/输出终端没有任何权限去访问你的文件系统或网络。真实的使用场景通勤路上的“移动办公室”我在地铁上用手机打开/rc链接看到早上在电脑上没写完的那个 API 接口文档草稿。我用语音输入手机端支持补充了几点需求Claude Code 在我的电脑上实时执行生成了新的代码片段我手机上立刻就能看到结果。会议室里的“即时演示”在技术评审会上产品经理指着 PPT 上的一个交互流程说“这个按钮点击后后端要做什么” 我立刻在笔记本上输入/rc把链接投到会议室大屏上然后当着所有人的面让 Claude Code 分析这个流程实时生成后端 API 的伪代码和状态流转图。整个过程不到 1 分钟比翻文档、查代码快得多。注意/remote-control的体验高度依赖于你的本地网络。如果是在公司内网确保防火墙允许claude.ai的域名通信。我遇到过一次因为公司代理服务器拦截了https://claude.ai/code/session_xxx的请求导致手机页面一直加载中。解决方案是在公司网络环境下先用电脑浏览器访问一次这个 URL让证书和连接被信任然后再用手机访问。6.2/xlsx与/docx让 Claude Code 成为你的“文档生产力中枢”/xlsx和/docx这两个命令把 Claude Code 从一个“代码协作者”扩展成了一个“全栈文档协作者”。它们的价值在于无缝衔接了“思考”和“交付”。/xlsx的典型工作流你让 Claude Code 分析一个 CSV 日志文件找出异常峰值。它不仅告诉你结论还会说“已将分析结果、原始数据摘要、趋势图表整理到一个新的 Excel 工作簿中。”你输入/xlsx它会生成一个.xlsx文件里面包含Summary文字结论、RawData清洗后的原始数据、Charts自动生成的折线图、柱状图三个 Sheet。/docx的典型工作流你完成了 API 设计和 Claude Code 讨论了所有细节。你输入/docx并指定“生成一份 OpenAPI 3.0 规范文档包含所有端点、请求/响应示例、错误码说明”。它会生成一个.docx文件格式专业可以直接作为交付物发给前端团队或客户。实操心得/xlsx和/docx的输出不是静态的。它们生成的文件会自动嵌入一个“Claude Code 智能链接”。你双击文档里的某个图表或某段 API 描述它会自动跳转回原始的 Claude Code 会话定位到生成该内容的那条指令和上下文。这让你的文档从一个“死”的交付物变成了一个“活”的、可追溯的知识节点。7. 效率快捷键与 CLAUDE.md构建属于你自己的“AI 开发操作系统”最后所有这些强大的命令都需要一个稳固的基座来支撑。这个基座就是快捷键的肌肉记忆和**CLAUDE.md的项目级配置**。它们不是锦上添花而是决定你能否将 Claude Code 的潜力发挥到 100% 的关键。7.1 必须刻进 DNA 的快捷键让操作快过思考CtrlV粘贴图片这是最被低估的快捷键。它让 Claude Code 的视觉能力Vision真正落地。我处理线上 Bug 时运维同事发来一张 Grafana 的 CPU 使用率飙升截图。我不需要描述“红色曲线在 14:30 突然冲到 95%”我直接CtrlV粘贴这张图。Claude Code 不仅能识别出坐标轴、时间点、数值还能结合你项目的技术栈从CLAUDE.md读取分析“此峰值与order-service的processPayment方法调用激增时间吻合建议检查该方法的数据库连接池配置”。这比任何文字描述都精准。CtrlR历史 Prompt 搜索这相当于你的个人 Prompt 库搜索引擎。当你想复用一个写得特别好的、用于生成单元测试的 Prompt 模板时按CtrlR输入关键词jest test所有匹配的历史输入都会列出来你可以直接回车选择稍作修改即可复用。这比在笔记软件里翻找快十倍。CtrlU整行删除这个看似简单的功能在你输入一个长命令如/loop 5m ...时如果中间打错一个字符CtrlU能让你瞬间清空整行而不是用Backspace狂按 20 下。这是对指尖效率的极致尊重。提示CtrlS暂存的功能我实测下来是将你当前输入框里的所有内容保存到一个临时缓冲区。这在你被紧急会议打断时特别有用你正在写一个复杂的/branch指令会议来了你按CtrlS然后去开会会后回来按CtrlShiftV推测的恢复快捷键实际需查看文档就能把刚才的指令完整恢复。这让你的思维流不会被物理世界打断。7.2CLAUDE.md你和 Claude Code 之间的“项目宪法”CLAUDE.md是一个放在你项目根目录的 Markdown 文件它是你和 Claude Code 之间的一份隐式契约。它告诉 Claude“在这个项目里我们约定这样做事”。一个高质量的CLAUDE.md至少应包含项目结构约定所有 API 路由定义在src/routes/所有业务逻辑在src/services/所有数据模型在src/models/。这能让 Claude 在你问“给我写一个用户注册的 API”时精准地把代码放到src/routes/auth.js而不是随便找个地方。技术栈与版本前端框架React 18 TypeScript后端框架NestJS 10数据库PostgreSQL 15CI/CDGitHub Actions。这能让/simplify的审查和/insights的建议都建立在准确的技术事实之上。禁止触碰区域禁止修改src/legacy/下的任何代码该模块将在 Q4 迁移。所有新功能必须在src/modules/下开发。这能从根本上杜绝/rewind的“方向错误”让 Claude 的每一次尝试都天然符合你的架构演进路线。自定义技能定义/aws-help: 当用户询问 AWS 相关操作时此技能应解析自然语言输出精确的 AWS CLI v2 命令并附带简短的安全警告如‘此命令会删除资源请确认’。这让你能把最常用的、重复性的操作封装成一个命令极大提升效率。注意CLAUDE.md不是一劳永逸的。它应该和你的项目代码一起被纳入 Git 版本管理。每次项目架构有重大调整比如引入了新的微服务你都应该同步更新CLAUDE.md。这不仅是给 AI 看的更是给你自己和团队成员看的它是一份活的、可执行的架构文档。我在实际使用中发现一个项目从零开始坚持每天花 5 分钟完善CLAUDE.md两周后Claude Code 的“理解力”会有质的飞跃。它不再是一个需要你不断解释背景的“新手”而是一个已经熟读项目“宪法”、能主动遵循约定的“老员工”。这种转变是所有高效 AI 协作的起点。