做 AI 编程这件事我最近最大的效率提升不是换了更强的模型也不是背了更多快捷键而是花了半天时间把 10 个中文命令装进了 Claude Code。这 10 个命令覆盖了我日常开发里最重复、最费眼、最容易被催着交差的工作代码审查、补测试、搭脚手架、查报错、改文档、筛简历、写周报等等。装上之后我在编辑器里敲一条/review或者/scaffold后面跟一句人话Claude Code 就会按固定的节奏和格式帮我干完一整段活。这篇文章就是把整套中文命令包的完整清单、模板、安装步骤、实战过程和踩坑记录都翻出来分享给正在用或准备用 Claude Code 搞 AI 编程工作流的朋友。适合两类人一类是刚装好 Claude Code还在靠对话反复粘贴提示词、觉得“也就那样”的开发者另一类是已经用了一段时间但想做一套可复用、可共享、讲中文就能调用的个人工作流包的人。看完你不需要自己从零想直接抄对应的命令模板按步骤放进项目里就能跑起来。1. 为什么要把“对话”改造成“命令”1.1 从重复提示词到即时命令真正省下的时间先算一笔账。没用命令之前我每次想让 Claude 帮我审查代码都得重新打一遍背景项目是什么语言、重点要看哪个文件、输出要什么格式、别改动代码只给意见……这些话加起来少说也有七八行。一天下来这种“重复写提示词”和“写完发现格式不对又要补一句”的次数轻松超过二十次。每次浪费两三分钟一天就是将近一个小时而且很消耗注意力——注意力这东西比时间金贵多了。命令化之后流程变成了敲/review跟上文件路径或 git 范围回车。剩下的流程全被命令模板接管Claude 会自己跑 git diff、按固定分级输出问题清单、最后给出修改优先级。我不需要重新描述需求也不用每次都强调“先定位行号再给结论”因为模板里写死了。说白了命令就是把一段写得不错的提示词变成项目里的一个按钮费用一次保存次次生效。1.2 为什么用中文语言不是技术的门槛是习惯的门槛有人会问Claude 本身就支持中文你直接说中文不就行了何必专门做“中文命令”我的理解分两层。第一层命令模板本身是全中文的。模板里写的“请做代码审查输出问题清单表格级别分为严重、一般、建议”模型完全能理解而且中文表达某些工程意图时比我用英文写提示词更不容易产生歧义尤其是涉及业务规则、字段含义、交付物格式这些地方。第二层命令的描述、参数提示、输出模板也都用中文这样我团队里的非技术背景同学——比如产品经理拿/resume去筛简历、运营拿/convert转 Word——他们也看得懂每一条命令是干嘛的。有一点我实测过自定义命令的文件名官方文档更建议用英文比如review.md但要靠 front matter 里的description写中文描述这样在编辑器里输入/之后弹出的菜单能直接看到中文说明。我也试过把文件名直接写成审查.md在 macOS 上没问题Windows 下偶尔会因为编码或文件系统兼容性出幺蛾子。所以最终统一用英文文件名 中文描述 中文模板的组合可靠和易用都占了。1.3 命令和全局提示词CLAUDE.md的分工Claude Code 支持在项目里放一个CLAUDE.md文件里面写全局规则模型每次对话都会读。这个文件很有用但我一开始犯过一个错误把 10 条命令的提示词全塞进了CLAUDE.md。结果每一次请求都要携带一大堆用不上的说明白白占用上下文窗口而且经常出现“跟它说 A 任务它却带着 B 任务的规则一起思考”的混乱。正确的做法是职责分离CLAUDE.md只放稳定的、所有任务都适用的项目级约定比如技术栈、代码风格、输出默认用中文、不要执行危险命令。具体到某一类任务的详细提示词封装成命令文件按需加载只有你主动调用某个命令时那段模板才会进入模型的上下文。这就像厨房里的调料CLAUDE.md是摆在灶台上的基础油盐每道菜都用得上命令文件是柜子里按需取用的专用酱料做红烧肉的时候才开一瓶。这样上下文干净命令执行也更稳定。2. 10 个中文命令全清单与设计思路我的命令包分成两组开发高频动作组和工作流文档组。先看总览命令触发方式核心用途使用频率/review后跟文件路径或 git 范围代码审查并输出问题分级每天多次/test后跟函数名或文件路径自动补单测并运行高频/scaffold后跟项目描述生成项目脚手架每周数次/debug粘贴报错信息或日志定位根因并给排查步骤高频/refactor后跟目标代码范围小步重构并保持可运行每周数次/resume后跟 JD 关键词简历筛选与打分排序招聘季高频/doc后跟代码文件路径生成 README/接口文档按需/sql后跟业务描述生成建表 SQL 与索引方案按需/convert后跟 Markdown 文件路径转换成 Word 文档按需/weekly无需参数读 git log生成周报每周一次2.1 开发高频动作组把最费眼的事交给 AI命令 1/review代码审查--- description: 对指定代码做 Code Review输出问题分级与修改建议 argument-hint: 文件路径或 git 范围例如 src/main.py 或 HEAD~1..HEAD --- 你是一个严格的资深代码审查员。请对 {{argument-hint}} 范围内的代码做审查 1. 如果给出的是 git 范围先执行 git diff {{argument-hint}} 获取变更内容如果给的是文件路径直接读取目标文件。 2. 输出格式问题清单表格列为“级别 / 文件:行号 / 问题描述 / 修改建议”。 3. 级别分为“严重、一般、建议”三档。“严重”包括明显的逻辑错误、安全隐患、未处理异常“一般”包括代码结构问题、可读性问题“建议”包括更优写法。 4. 每条问题必须先定位到具体行号再给结论不允许泛泛而谈。 5. 表格输出后再单独给一段“优先修复顺序”按对系统的影响程度排序。设计理由审查是我用下来性价比最高的场景。代码审查对“注意力”的要求极高AI 恰好擅长在固定范围内做地毯式扫描。模板里坚持“先定位行号再下结论”是为了避免模型输出一堆正确的废话没有行号的意见没法落地。命令 2/test补单元测试--- description: 为指定函数或模块补单元测试并尝试运行 argument-hint: 目标函数名或文件路径 --- 请为 {{argument-hint}} 补充单元测试 1. 先阅读目标代码分析输入输出和边界条件。 2. 给出测试文件路径建议生成完整的测试代码。 3. 测试必须包含正常路径、边界情况空值、极限值、异常输入。 4. 生成代码后尝试运行测试命令如 pytest 文件名把结果贴在末尾。 5. 如果运行失败直接给出修复建议而不是跳过。设计理由很多开发者的痛点不是不会写测试而是写测试太枯燥尤其在业务代码赶工时。这个命令的价值在于它会先自动跑一遍测试生成“红绿灯”让开发者基于失败信息去补代码逻辑形成快速反馈闭环。命令 3/scaffold项目脚手架--- description: 按一句话描述生成可运行的项目脚手架 argument-hint: 项目描述例如“一个 FastAPI SQLite 的待办事项后端” --- 请为 {{argument-hint}} 生成一个最小可运行的项目脚手架 1. 先列出目录树并用表格说明每个文件的职责。 2. 再依次生成关键文件依赖清单、入口文件、路由/核心逻辑、配置示例、README。 3. 依赖清单里标注版本和用途不要堆用不上的库。 4. 生成完后给出“如何启动”的三条命令从安装依赖到运行。 5. 保持最小可运行原则宁可少一个模块不要生成一堆跑不起来的空壳。设计理由这里我踩过一个坑。早期让 AI 生成项目它喜欢一股脑生成十几个文件看起来很专业实际很多是空壳跑起来缺这缺那。所以模板里强制要求“最小可运行”和“依赖清单精确”实测下来生成的脚手架靠谱程度提升很多。命令 4/debug报错排查--- description: 根据报错信息和日志定位根因 argument-hint: 粘贴报错堆栈或描述现场现象 --- 你是一个系统排查专家。请根据以下信息定位问题根因 1. 先拆解报错信息错误类型、关键堆栈帧、涉及的文件和函数。 2. 给出 2-3 个最可能的根因假设按概率从高到低排序。 3. 对每个假设给出“验证方法”如何用日志、命令行或最小复现来确认。 4. 最后给出修复建议并要求在执行任何修改前先向用户确认。 5. 如果你的分析缺少上下文明确列出你还需要哪些信息而不是瞎猜。设计理由排查问题最怕“一顿猜测猛如虎全是方向错误”。模板强制模型先列假设、再给验证手段本质是把调试变成可执行的排查清单而不是让 AI 直接给你一段可能修错地方的代码。命令 5/refactor小步重构--- description: 对目标代码做小步重构保持行为不变 argument-hint: 文件路径和想改善的方向 --- 请对 {{argument-hint}} 做一次小步重构 1. 先阅读原代码用表格列出“当前问题 / 重构方案”。 2. 重构范围限制在给定文件内不擅自修改其他模块。 3. 修改完成后展示关键代码的前后对比用代码块呈现。 4. 如果项目里有测试必须运行相关测试并给出结果。 5. 如果没有测试明确提示“本次重构未经测试覆盖建议尽快补测试”。设计理由AI 重构最可怕的是“大爆炸式重写”看着漂亮一跑就挂。命令模板里限定了单文件范围、要求前后对比和测试结果等于给模型上了安全绳。它做的是“局部优化”而不是“推倒重来”。2.2 工作流文档组让 AI 处理你的“非编程”杂活命令 6/resume简历筛选--- description: 按 JD 关键词筛选简历并生成匹配度评分排序 argument-hint: JD 关键词例如“3年Python后端、熟悉FastAPI、有高并发经验” --- 你是一个技术招聘顾问。我会在本次会话中提供若干简历全文Markdown 格式。 请根据 JD 要求对每份简历输出 1. 匹配度评分0-100并给出评分依据标注命中的关键词。 2. 经验核对项目经历与 JD 的匹配点在哪、缺失点在哪。 3. 风险提示简历中可能被高估、模糊或无法验证的描述。 4. 最后生成候选人排序表按评分降序含“姓名/评分/关键亮点/主要风险”。 JD 要求{{argument-hint}} 规则只基于简历文本中的事实打分不脑补任何项目细节。设计理由这是我目前用得最意外的一个命令。做技术管理后筛简历成了周期性噩梦。把简历转成 Markdown 丢进来AI 十几秒就能出一张对比表效率提升是数量级的。模板里“只基于文本事实打分”是血泪教训不然模型会把“参与了 XX 项目”脑补成“主导了 XX 项目”。命令 7/doc文档生成--- description: 为指定代码生成 README 或接口文档 argument-hint: 文件路径如 src/api.py --- 请为 {{argument-hint}} 生成文档 1. 阅读代码提取核心函数、类、接口的签名与职责。 2. README 格式项目简介、安装方式、使用示例、目录结构。 3. 接口文档格式方法、路径、请求参数、响应示例、错误码。 4. 输出使用中文代码示例中的变量名保持原样。 5. 最后列出“文档中可能不准确的点”提示人工复核。设计理由这个命令的额外价值在第五点。AI 生成文档时经常悄悄“发明”不存在的参数。让它主动标注“可能不准确的点”相当于让模型自己给自己把关比人工拎出来快得多。命令 8/sql建表与索引设计--- description: 根据业务描述生成建表 SQL 与索引方案 argument-hint: 业务描述例如“用户表一个用户有多张订单按交易时间查询” --- 请为 {{argument-hint}} 设计数据库表 1. 先列出实体关系涉及哪些表、主外键关系、字段含义。 2. 生成建表 SQL标注每个字段的类型选择理由尤其是用不用索引。 3. 按查询场景给出索引方案并说明索引覆盖了哪些高频条件。 4. 反查一遍有没有字段类型明显不合理、有没有缺外键、有没有冗余字段可以拆表。 5. 输出前先问自己如果数据量到百万级这个表结构还能不能扛住。设计理由让 AI 写表结构不难难的是让它在动手前想清楚关系、动手后自我检查。模板把“反查”写进流程能有效减少那种“看着能用、一上生产就慢”的劣质设计。命令 9/convertMarkdown 转 Word--- description: 将 Markdown 文档转换为 Word 文档 argument-hint: 目标 md 文件路径 --- 执行 Markdown 转 Word 操作 1. 检查 pandoc 是否已安装运行 pandoc --version未安装则提供对应系统的安装命令。 2. 运行转换pandoc {{argument-hint}} -o {{argument-hint}}.docx 3. 如果文档中包含代码块追加参数 --highlight-styletango 提升展示效果。 4. 如果文档包含中文字体问题追加参数 -V mainfontPingFang SC 或根据系统调整。 5. 转换完成后确认输出文件存在并汇报文件路径与大小。设计理由很多团队产出的方案、周报、交接文档最终都要转成 Word 走流程。这个命令看似简单其实解决了一个高频痛点不用再去“复制内容 → 粘贴到 Word → 手动调格式”。pandoc 是命令行工具Claude 通过它执行转换比我手动操作稳定得多。命令 10/weekly周报生成--- description: 读取 git log 生成周报 argument-hint: 时间范围或提交者例如“本周”或“-n 30” --- 请根据 git 提交记录生成周报 1. 执行 git log {{argument-hint}} --prettyformat:%h|%an|%ad|%s --dateformat:%Y-%m-%d 获取提交记录。 2. 按提交类型分组功能开发、Bug 修复、重构优化、文档与杂项。 3. 每组输出要点时把提交信息翻译成“做了什么完成度”不要直接抄 commit message。 4. 对仍存在的问题或风险项单列一节说明。 5. 输出格式为 Markdown保留提交哈希作为追溯依据。设计理由周报是典型的“谁写谁烦”的任务。让 AI 读 git 历史生成初稿开发者只需润色和补充背后的业务价值十分钟内就能交差。模板里“翻译成做了什么完成度”是为了避免模型把fix typo这种提交信息原样搬进周报那会显得很敷衍。3. 从零到一安装与配置整套工作流包3.1 安装 Claude Code两种系统的踩坑记录安装 Claude Code 本身不复杂官方给的是 npm 包全局安装即可npm install -g anthropic-ai/claude-code装完之后在项目目录里执行claude进入交互界面用/login完成账号授权。这里有几个容易翻车的点Node.js 版本最好在 18 以上。我有一次在旧服务器上装node 还是 14装完启动直接报错升完 node 才正常。Windows 用户装完后如果claude命令找不到大概率是 npm 全局目录没进 PATH。npm root -g查一下路径手动加进去就行。Ubuntu 上如果遇到权限问题一般是 npm 全局目录权限不够用sudo chown -R $(whoami) $(npm prefix -l)/lib/node_modules把目录归属理清别老用 sudo 跑 node 全局包。启动后有一段话我提醒一下如果提示当前网络环境或区域不受官方支持那就参考官方支持列表确认区域与账号版本这个不以任何“技巧”绕开为准。我后面的内容都基于官方支持的正常访问方式展开。3.2 VS Code 接入在编辑器里用中文命令Claude Code 官方现在有对应的 VS Code 扩展搜“Claude Code”直接装就行。装完之后不需要额外开终端直接在 VS Code 的集成终端里输入claude或者用扩展自带的侧边栏面板。我更推荐在集成终端里用理由很朴素可以顺手命令 PowerShell/bash 的操作切上下文不需要跳窗口。VS Code 里有一件事值得做把 claude 绑定成快捷键。打开keybindings.json加一条把claude插入终端的组合键。比如我绑定的是CtrlAltC在集成终端里按一下会自动弹出 claude 交互界面直接开聊或敲/review。在扩展配置里还有一个allowedTools的概念可以理解成“哪些工具 AI 可以直接调用、哪些需要弹窗确认”。我下面的命令里/review需要执行 git diff/convert需要执行 pandoc如果这些工具没在白名单里每次都要手动点确认体验会打折扣。可以在一开始把这些高频使用的只读类工具加白名单Read、Glob、Grep写文件类操作比如Write、Edit建议保留弹窗确认防止 AI 自作主张改坏文件。3.3 创建命令目录一行命令搭好全家桶命令文件统一放在项目根目录的.claude/commands/下一个命令对应一个 Markdown 文件。先建目录mkdir -p .claude/commands然后把上面那 10 个模板分别保存成review.md、test.md、scaffold.md、debug.md、refactor.md、resume.md、doc.md、sql.md、convert.md、weekly.md。全部放好后在已启动的 Claude Code 里按一下/菜单里就能看到这些命令选出来直接补参数就行。同时建议在项目根目录放一个精简的CLAUDE.md内容控制在几条实际约束内比如# 项目级约定 - 所有对用户的解释和文档输出优先使用中文。 - 本项目的技术栈是 Python 3.11 FastAPI SQLite。 - 不要执行可能破坏数据的命令如 DROP 或 rm -rf。 - 生成代码时保持精简避免无意义的注释和空壳文件。这个文件一定不要太长重点写“稳定的项目事实”和“安全边界”把具体任务逻辑留给命令模板。3.4 接第三方模型与本地模型低成本替代方案Claude Code 默认走官方模型但如果想低成本试水也可以把终点切到兼容 OpenAI/Anthropic 协议的第三方模型。社区里常见的做法是借助模型切换工具比如 cc-switch 这类维护多套 API 地址配置随时切换 DeepSeek、Qwen、GLM 等国产模型或者用 LM Studio 在本地起一个推理服务来对接。配置的原理很简单改环境变量ANTHROPIC_BASE_URL指到第三方兼容服务地址再配对应的 API Key。cc-switch 这类工具就是把这些配置做成了可视化切换界面。说点实在的建议第三方模型和官方模型在复杂任务上的差距明显。我的体会是简单模板类的命令比如/convert、/weekly、/sql第三方模型完全能胜任成本低很多但/review、/debug这类需要强逻辑推理的命令还是用官方模型稳。所以实际使用我是按命令分模型的重活好模型轻活用便宜模型。3.5 权限模式控制 AI 的“手脚”Claude Code 提供几种权限模式直接影响命令的使用体验模式行为适合场景default执行只读操作无需确认写文件需弹窗推荐日常使用安全与效率平衡acceptEdits自动接受文件编辑不再逐一确认熟悉模型行为后追求效率时plan只输出计划不执行任何工具需求分析、方案评审阶段bypassPermissions全部自动执行不推荐等于让 AI 裸奔我日常用default给了高频只读工具白名单写文件还是会弹窗确认。这样/review能一口气跑完 diff 分析但真要根据建议改代码时每一步修改都能被我看到。4. 三个真实场景的完整演练4.1 “一句话生成一个 Python 服务”的脚手架我演练过一句话/scaffold 一个 FastAPI SQLite 的待办事项后端。命令模板生效后模型先给了一个目录树todo-backend/ ├── main.py # 应用入口、路由注册 ├── models.py # SQLite 表结构与数据操作 ├── requirements.txt # 依赖清单 └── README.md # 启动说明然后生成核心文件。生成完我问了一句“能跑吗”它自动执行了pip install -r requirements.txt uvicorn main:app --reload把服务跑起来了。我实际用下来脚手架生成的项目速度没有问题但我会在依赖版本上多看一下——AI 有时候会给一些过时的版本号导致本地安装冲突。比如有一次它给的 FastAPI 还是 0.88已经是两三年前的版本我改成当前稳定版后一切正常。又用它生成了一个带登录鉴权的项目这次我在目录树阶段就打断它要求把鉴权模块单独拆出来。这算是个经验生成脚手架时不要等到所有文件写完再提需求在模型列出目录树的阶段就提改造成本最低。4.2 “审查我上一次提交”的完整 Code Review我试过直接输入/review HEAD~1..HEAD模型会执行 git diff 获取最近一次提交的变更内容然后按模板输出问题清单。一次真实的输出节选级别文件:行号问题描述修改建议严重utils.py:87异常分支里只记录了日志没有回滚事务数据会出现部分写入在 except 中调用 rollback 并重新抛出异常一般api.py:43分页参数没有做上限校验传 10000 也能查增加 max_limit 限制建议service.py:12循环内重复调用数据库查询考虑批量查询改成一次 IN 查询输出底部还有一段“优先修复顺序”把严重问题排第一。我实际拿这些意见去改代码时发现那条严重问题是真的一个事务中途出错时没有回滚已经写进去的数据会留下半截状态。这种问题靠人眼 review 容易漏AI 按模板逐行扫的时候反而能抓到。但要提醒一点审查结论可以信一半。凡是“严重”级别的问题我会自己打开对应行号重新读一读代码确认模型没有误判反而是“建议”级别比如批量查询优化这类改动直接做了风险低。这里的原则是AI 负责找出可疑点人类负责拍板和修改。4.3 “筛一份简历”的实战从摘要到评分表招一个 Python 后端候选人时我给了/resume 3年Python后端、熟悉FastAPI、有高并发经验然后把 5 份候选人简历转成 Markdown 粘贴进会话。模型很快生成了评分表和风险提示。有一套输出我记得挺深候选人 A评分 873 年 Python 后端经验符合、项目中用 FastAPI 做过订单服务但“高并发经验”描述模糊简历中未体现具体 QPS 或优化手段。候选人 B评分 82技术栈基本匹配但有一段工作经历时间存在重叠。候选人 C评分 60主要是 Java 背景Python 经验偏脚本不匹配。B 的时间重叠是我自己没注意到的AI 按时间线核对时发现了风险。不过也有翻车的地方模型在候选人 D 的评分理由里写了“主导过 XX 系统重构”我回头翻简历原文只是“参与XX系统升级”。“主导”和“参与”差别很大模板里“只基于文本事实打分”的规则就是为了压制这种脑补倾向但实际使用还是要人工复核关键结论。整体来说这个命令做不到“替你招人”但能做到“把 5 份简历里 80% 的筛选工作先做完”你只需要花时间复核最后那批最有希望的人。5. 高频问题速查与避坑实录5.1 问题速查表现象可能原因解决办法敲/xxx后没有反应或提示命令不存在命令文件不在正确路径或文件名后缀不是 .md检查是否放在项目根目录.claude/commands/下文件名规范Windows 下命令文件里的中文乱码文件保存时不是 UTF-8 编码用编辑器另存为 UTF-8 无 BOM 格式执行命令时频繁弹出权限确认工具不在白名单权限模式太严在配置里把高频只读工具加入 allowedTools上下文总是很快变长对话卡顿会话里粘贴了大文件或长日志用 Grep/Grep 先缩小范围或用/compact压缩历史切换到第三方模型后输出格式乱掉模型风格差异导致模板约束失效在命令模板里写死“必须按表格输出”或关键任务换回官方模型提示组织未开通 claude 订阅访问账号组织级限制个人账号订阅或联系组织管理员开通权限命令模板里的参数没生效front matter 字段名写错确认使用argument-hint等官方字段版本升级后复查文档5.2 上下文超长别把大文件直接扔进对话Claude Code 有一个很诱人的能力直接告诉你“把文件路径拖进来就能读”。但拖大文件进对话爽了一时后面整个会话都会因为上下文膨胀而变慢变蠢。我处理大代码文件的习惯是先让模型用 glob 和 grep 定位关键结构再按需读文件片段而不是一上来就让模型通读整个仓库。具体操作上我会在命令模板或对话里写“先列出项目结构 → 找出与需求相关的文件 → 再读取目标函数”。这样模型始终在一个精简的上下文里工作准确率和速度都会更好。5.3 模型自作主张危险命令必须拦住有一次/scaffold生成项目时模型顺手写了一句初始化命令里面带了强制删除目录的参数。好在我权限模式是default执行前弹窗确认被我拦下了。那之后我养成两个习惯第一CLAUDE.md里明确写“不要执行可能破坏数据的命令”第二命令模板里涉及命令执行时统一加一句“执行任何修改前必须先向用户确认”。这两条结合起来相当于给 AI 装了一个“安全刹车”。别嫌麻烦一旦它在无人确认状态下把项目目录清理了那效率提升的数字就是一个冷笑话。5.4 输出格式漂移格式即协议同一个命令AI 今天输出表格明天可能输出列表后天可能直接给你一段散文。我一开始以为这是偶然后来发现不做约束时这就是常态。所以命令模板里我都会写死输出结构比如“问题清单表格列为级别 / 文件:行号 / 问题描述 / 修改建议”。如果你希望输出能被脚本或外部工具进一步处理甚至可以要求模型“输出 JSON字段为 xxx”让 AI 的结果直接被代码消费。这条思路很适合把 Claude Code 输出的东西接进自动化流程。6. 从个人效率到团队资产扩展与协作思路6.1 把命令装进 Git团队共享工作流包.claude/目录完全可以提交到 Git 仓库里。新同学 clone 项目之后启动 Claude Code就自动拥有整套命令。这里有两个注意事项不要在命令文件里写私人 API Key、内网地址、敏感路径。命令文件是给团队用的里面只放模板逻辑密钥走环境变量。命令模板本身需要像普通代码一样走 Code Review。我见过团队里有人把个人习惯写进命令导致其他同事使用时行为诡异。命令模板是“团队约定”不是“个人偏好”。维护一套命令模板本质上是在维护一套“组织级的 AI 使用规范”。它沉淀的不只是提示词而是你们团队解决问题的标准动作。6.2 用 MCP 扩展能力边界Claude Code 支持 MCPModel Context Protocol模型上下文协议来扩展工具能力。举个例子我给/resume命令配了一个简单的 MCP 工具让模型可以自动读取files/resumes/*.md目录下的简历文件而不是需要我手动拖拽粘贴。这类扩展思路可以套在更多命令上/sql挂上只读数据库连接让模型直接查 schema 而不是读文档。/debug挂上日志查询工具让模型基于线上日志片段排查。/weekly挂上项目管理工具把任务状态一并拉进周报。MCP 本质上是在“命令”之上再加一层“数据访问能力”。命令行的是“怎么干活”MCP 解决的是“干活需要的数据从哪来”。6.3 和其他工作流平台的分工不抢活只配合现在市面上有很多工作流平台比如 Dify、Coze、n8n也有视觉类的 ComfyUI。不少人问我它们和 Claude Code 有什么区别、选哪个。我的理解是场景不同互为补充。Dify、Coze 这类平台适合做“多人在线、长时间运行、异步执行”的业务流程比如知识库问答助手、自动化报表、客服分流Claude Code 适合做“开发者在编辑器里的即时动作”特点是低延迟、贴近代码、即时反馈。两者可以配合Claude Code 生成的报告、文档输出可以直接通过 API 或文件方式交给工作流平台的节点继续流转到下一步通知或归档反过来工作流平台也可以把一次性的编码任务派发到本地 CLI 处理。轻量级的动作就地解决重量级的流程交给平台编排各干各擅长的部分。最后分享一个我实际使用中的体会这套中文命令包里最值的一笔投资是把/review和/test做成命令。原因不是它们“看起来厉害”而是这两个命令逼迫我形成了稳定的代码检查习惯每天提交前先跑一遍效果立竿见影。如果你也想搭自己的命令包我的建议是从两三个真正高频的命令开始用一周再把新的需求沉淀成新命令别一上来十个全上——命令是给你用的工具不是展示架的摆设。