企业官网建设流程全解析

做 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 个中文命令全清单与设计思路

我的命令包分成两组：开发高频动作组和工作流文档组。先看总览：

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-style=tango 提升展示效果。 4. 如果文档包含中文字体问题，追加参数 -V mainfont="PingFang SC" 或根据系统调整。 5. 转换完成后，确认输出文件存在并汇报文件路径与大小。

设计理由：很多团队产出的方案、周报、交接文档，最终都要转成 Word 走流程。这个命令看似简单，其实解决了一个高频痛点：不用再去“复制内容 → 粘贴到 Word → 手动调格式”。pandoc 是命令行工具，Claude 通过它执行转换，比我手动操作稳定得多。

命令 10：/weekly周报生成

--- description: 读取 git log 生成周报 argument-hint: 时间范围或提交者，例如“本周”或“-n 30” --- 请根据 git 提交记录生成周报： 1. 执行 git log {{argument-hint}} --pretty=format:"%h|%an|%ad|%s" --date=format:"%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插入终端的组合键。比如我绑定的是Ctrl+Alt+C，在集成终端里按一下，会自动弹出 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，给了高频只读工具白名单，写文件还是会弹窗确认。这样/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 获取最近一次提交的变更内容，然后按模板输出问题清单。一次真实的输出节选：

输出底部还有一段“优先修复顺序”，把严重问题排第一。我实际拿这些意见去改代码时，发现那条严重问题是真的：一个事务中途出错时没有回滚，已经写进去的数据会留下半截状态。这种问题靠人眼 review 容易漏，AI 按模板逐行扫的时候反而能抓到。

但要提醒一点：审查结论可以信一半。凡是“严重”级别的问题，我会自己打开对应行号重新读一读代码，确认模型没有误判；反而是“建议”级别，比如批量查询优化，这类改动直接做了风险低。这里的原则是：AI 负责找出可疑点，人类负责拍板和修改。

4.3 “筛一份简历”的实战：从摘要到评分表

招一个 Python 后端候选人时，我给了/resume 3年Python后端、熟悉FastAPI、有高并发经验，然后把 5 份候选人简历转成 Markdown 粘贴进会话。模型很快生成了评分表和风险提示。

有一套输出我记得挺深：

• 候选人 A：评分 87，3 年 Python 后端经验符合、项目中用 FastAPI 做过订单服务，但“高并发经验”描述模糊，简历中未体现具体 QPS 或优化手段。
• 候选人 B：评分 82，技术栈基本匹配，但有一段工作经历时间存在重叠。
• 候选人 C：评分 60，主要是 Java 背景，Python 经验偏脚本，不匹配。

B 的时间重叠是我自己没注意到的，AI 按时间线核对时发现了风险。不过也有翻车的地方：模型在候选人 D 的评分理由里写了“主导过 XX 系统重构”，我回头翻简历，原文只是“参与XX系统升级”。“主导”和“参与”差别很大，模板里“只基于文本事实打分”的规则就是为了压制这种脑补倾向，但实际使用还是要人工复核关键结论。

整体来说，这个命令做不到“替你招人”，但能做到“把 5 份简历里 80% 的筛选工作先做完”，你只需要花时间复核最后那批最有希望的人。

5. 高频问题速查与避坑实录

5.1 问题速查表

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 支持 MCP（Model 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做成命令。原因不是它们“看起来厉害”，而是这两个命令逼迫我形成了稳定的代码检查习惯，每天提交前先跑一遍，效果立竿见影。如果你也想搭自己的命令包，我的建议是从两三个真正高频的命令开始，用一周，再把新的需求沉淀成新命令，别一上来十个全上——命令是给你用的工具，不是展示架的摆设。