★ FEATURED ARTICLE 我最近把自己日常摸鱼用的几个 AI 编程流程固化成了 10 个中文命令全部装进了 Claude Code 里。这些命令不是花架子而是把代码审阅、日志分析、单元测试补全、提交信息生成这些高频动作封装成了一条条可以直接调用的工作流。这篇文章就把整套工作流包的设计思路、每个命令的实际写法、踩过的坑和最后落地的效果完整拆开适合那些正在折腾 AI 编程助手、想把手头重复劳动交给工具的朋友。标题里说“中文命令”重点不在于把英文翻译成中文而在于命令的触发词、输出风格、交互逻辑都贴合中文开发者的习惯。比如团队里同事写的注释是中文要求代码规范描述也是中文那 AI 审阅代码时如果让它用中文输出问题清单大家沟通成本会低很多。Claude Code 对命令的定义方式支持设置命令名和参数我实测下来中文命令名在/触发时完全没问题直接在终端里敲/代码审阅就能唤起。这套命令一共 10 个分别是代码审阅、提交信息生成、重构建议、日志分析、单元测试补全、接口调试、文档生成、依赖梳理、问题修复、项目状态巡检。下面逐个聊。1. 整体工作流包设计为什么需要一套“中文命令”1.1 中文命令不是什么“炫技”而是降低心智开销先说个大实话命令本身不会让 Claude 变聪明真正起作用的是命令背后那套提示词和上下文管理策略。那为什么非要用中文命令名我以前用英文命令名不是不行但有几个痛点。第一是遗忘成本。日常用到的命令如果超过 10 个英文名容易混。比如/code-review和/review-code看着差不多敲错就白搭。换成/代码审阅之后每次调用之前脑子里不需要“中英文互译”这一步直接敲中文几乎没有记错的可能。第二是团队协作。如果团队里有人不习惯英文交互比如做后端的老同事你跟他说“你敲一下 /commit-msg 生成提交信息”他可能需要反应一下但你说“敲 /提交信息”他直接就能操作。实测下来新人上手这套工作流包的时间从小时级降到了分钟级。第三是输出风格的统一。命令触发后Claude 会按照构建好的提示词输出结构化内容比如代码审阅会固定输出“问题清单 严重级别 修改建议”的表格。用户平时对话可能口语化但命令输出必须是严格的固定格式。中文命令名和中文输出格式搭配整条链路风格统一。1.2 命令筛选不是所有任务都适合做成命令把操作变成命令有个前提这个操作要么是高频重复的要么是流程固定的要么是可以通过 AI 输出模板化的内容来减少人工整理时间的。我最初列了一份 25 个候选命令的清单最后砍到 10 个筛选标准就三条。高频这个动作一周至少会用三次以上。比如“生成提交信息”每天提交代码必用适合做成命令。低思考成本命令触发后Claude 自动带上固定的上下文和规则用户只需要给一个参数比如“改动范围”剩下的都交给命令本身。如果某个命令还需要用户长篇大论描述背景那说明逻辑还没设计好。输出可模板化命令的输出要是结构化、可直接复用的。比如日志分析输出必须包含“异常类型、报错行、可能原因、建议修复方案”几个字段如果输出只是一段自然语言不能直接粘贴到工单里价值就少了半截。按这三条标准筛下来的 10 个命令基本覆盖了日常开发的四个阶段读代码代码审阅、项目状态巡检、依赖梳理、写代码重构建议、问题修复、单元测试补全、交付提交信息生成、文档生成、接口调试、排障日志分析。1.3 整体架构命令层、规则层、上下文层这套工作流包的结构其实很简单分三层命令层定义10个命令每个命令有自己的触发词和参数说明。规则层存放在项目根目录下的CLAUDE.md规则文件里。这里存的是“全局约束”比如代码风格偏好、禁止修改的文件范围、输出语言要求等。命令本身不需要重复写这些规则因为 Claude Code 在每次会话中会先读取规则文件。上下文层命令的提示词里只写“本次动作要做什么”具体代码结构、文件路径、项目背景都通过 Claude Code 的自己读文件能力实时获取。不把项目代码塞进命令里命令保持轻量、通用。这层设计的好处是命令是通用的规则是项目的。比如/代码审阅命令可以在任何项目里用但不同项目里它读到的规则不同输出建议会有差异 —— 项目 A 要求 TypeScript 严格模式项目 B 要求兼容旧浏览器规则文件不同审阅侧重点自然不同。2. 命令清单逐个拆解每个命令怎么设计、怎么写这 10 个命令我从设计意图、触发形式、核心逻辑三个角度来拆。每个命令附一段简化版的写法示例帮助大家理解命令背后到底做什么。2.1/代码审阅最常用的一个命令核心逻辑很简单让 Claude 先读取你指定的代码文件然后按照规则文件里的代码规范做一次静态审阅。这个命令要做的不是“重新检查一遍代码是否有语法错误”而是关注“可读性、潜在 bug、边界处理、性能隐患、一致性”这几个维度。/code review 请审阅文件: $FILE实际的命令里我会指定一个参数$FILE用户可以传单文件也可以传一个目录。命令的核心不是让 AI 泛泛而谈而是要求输出格式固定问题清单按严重级别排序阻断 / 重要 / 建议每个问题关联的代码引用行号 代码片段建议修复方案风险最高的 3 个点为什么这样设计因为审阅完代码最终还是要人来修改。如果 AI 只是说“这个函数太长了建议拆分”没有给出具体行号开发者还得自己翻代码并没有节省时间。强制固定输出格式之后拿到结果可以直接对照处理工作效率提升明显。2.2/提交信息给 Git 提交写规范信息这个命令服务的是“规范提交”让每次提交信息符合团队约定比如type(scope): subject格式。以往我写提交信息总是随手敲一句“修复了 bug”过一个月自己都看不懂。现在用命令触发后它会自动对比暂存区的改动内容生成符合规范的提交信息。/commit 生成提交信息类型遵循 conventional-changelog 规范命令里不用传任何参数。Claude Code 会自己执行git diff查看暂存区改动然后自动生成信息。生成完我可以复制或直接采用支持中文和英文两种输出。实测下来生成的信息在语义粒度上比我自己写的更准确因为它会根据改动内容自动判断是feat还是fix还是refactor。补充一点使用这个命令的前提是git add已经执行否则它看不到改动内容。我一开始经常忘记先暂存后来干脆把提示词里加了“如果暂存区无改动则提示用户先执行 git add”。2.3/重构建议在动大刀之前先问 AI 一声重构风险高容易把好端端的代码改崩。这个命令的工作方式是先把目标代码读进来分析结构、圈复杂度、潜在扩展点然后输出一份“重构方案”。方案里包含当前架构的劣势分析、推荐的目标结构、分几步走、每一步的验证方式。实际产出是一张表格当前问题重构目标改动范围风险级别建议实施时机为什么单独做一个命令而不是直接对话因为直接对话时总会忘掉一些维度。命令规定必须先分析“圈复杂度”必须先评估“改动影响面”这样不会漏项。2.4/日志分析异常排查时最快的入口很多项目日志格式不统一服务一多日志文件混在一起。这个命令的价值在于把“人肉翻日志、找异常关键字、猜原因”的过程交给 AI。/日志分析 日志文件: $LOG_PATH 时间范围: $TIME_RANGE命令内置了解析逻辑先按时间线排序过滤掉无意义的心跳日志识别错误级别日志之间的关联关系最后输出“异常事件 关联日志 可能原因 排查建议”。有一个很实用的细节它会在分析前先统计日志级别的分布如果某个时间段 ERROR 比例突然飙升它会刻意标注出拐点。我踩过的坑是日志文件太大时直接把整个文件灌给 Claude 会超过上下文窗口处理速度也很慢。现在的做法是命令里内置一条“先做采样优先抽取 ERROR、WARN 级别以及时间相邻的上下文日志”避免上下文爆炸。2.5/单测补全把测试覆盖率补上编写单元测试是个精细活也是很多人拖延的重灾区。这个命令的目标不是 AI 顺手把所有测试都写了而是“参照已有测试风格补全缺失场景”。命令会先读取被测文件、已有测试文件、覆盖率报告然后找出没覆盖的分支生成补充测试用例。如果有覆盖率报告命令会读报告如果没有会让 Claude 自己分析代码分支。它的输出是完整的测试代码块可直接粘贴到测试文件里。命令里会设置一条偏执的规则“生成的测试用例至少包含正常输入、边界输入、异常输入三类。”注意一个细节AI 生成的单测不能无脑相信。有一个常见问题为了通过覆盖率检测AI 会生成一些看似覆盖了分支、但实际只是空转的测试用例。所以命令的提示词里专门有一条“不允许为了覆盖率而生成无断言的测试。”加上这一条之后测试质量明显提升。2.6/接口调试快速生成请求示例、定位联调问题处理接口联调问题时最烦的是翻文档找参数名、构造请求体、确认鉴权方式。这个命令会读取接口定义文件OpenAPI / Swagger / 后端路由代码然后按用户指定的场景生成请求示例或者对返回结果做疑难点分析。触发方式如/接口调试 接口路径: /user/info 场景: 查询用户详情输出包含请求方法、请求头、请求体示例、鉴权方式说明、可能遇到的错误码及含义。这个命令对于前后端联调很有用尤其是后端接口文档更新不及时的时候直接从代码里读取路由定义省得来回问人要文档。2.7/文档生成把散落的注释变成可用文档文档任务在工程里往往优先级很低但一旦接手维护旧项目没有文档就会被坑惨。这个命令会根据代码里的注释、函数签名和模块导出生成一份结构清晰的文档草稿。它生成的内容包括模块概览、函数签名、参数说明、返回值、使用示例、注意事项。命令会要求“先读取项目已有文档的写作风格再按同样风格生成”避免产出的文档和团队已有的风格不统一。2.8/依赖梳理搞清楚项目依赖之间的关系依赖关系混乱是旧项目的常见问题。package.json里几十个依赖哪些是直接依赖、哪些是间接依赖、哪些版本冲突人肉排查很痛苦。这个命令会读取依赖清单并分析目录结构输出一张依赖关系表和潜在风险点。输出格式为| 依赖名 | 当前版本 | 最新版本 | 直引/间接 | 风险说明 | 建议操作 |生成的建议可以包括“升级到某个版本后需要回归验证哪些模块”这个信息对排期很有价值。2.9/问题修复拿到报错直接修严格来说这不是一个自动修改器而是一个“诊断工具”。它接收报错信息或异常堆栈再结合相关代码上下文输出“根因分析 修复建议 修改后的代码”。与/代码审阅的区别是代码审阅面对的是整个文件尽量发现潜在问题问题修复是拿着明确报错去定位根因。命令会要求 Claude 先解释报错产生的链路再动手改代码避免“只改了表面症状、没有消除根因”。每次使用这个命令我都会让它先输出“根因是否确认”这个字段。如果它没有足够信息确认根因它会要求补信息而不是强行给修复方案。这个约束很关键防止 AI 在一知半解时瞎改代码。2.10/状态巡检摸清项目全貌的第一站接手新项目或者刚打开一个几周没碰的旧项目时内心最迷茫的是“这项目现在什么状态”。项目状态巡检这个命令就是把项目关键信息一次性拉出来框架、语言版本、构建工具目录结构概览技术栈亮点与风险点比如依赖了过时库全部 TODO / FIXME 位置摘录当前分支状态、未提交改动数量实际体验下来这个命令是“开局”命令。每次开始干活前跑一次比盯着 README 发愁强。它会自动跳到 README、配置文件、入口文件等关键位置读信息不用用户一点点翻。3. 工作流包的实现与落地怎么把命令变成可复用的工具3.1 命令目录结构与配置方法Claude Code 的命令目录配置本质上就是把每个命令写成一个带有函数式声明的配置文件。我实际用的目录结构大概是这样.claude/ ├── commands/ │ ├── 代码审阅.md │ ├── 提交信息.md │ ├── 重构建议.md │ ├── 日志分析.md │ ├── 单测补全.md │ ├── 接口调试.md │ ├── 文档生成.md │ ├── 依赖梳理.md │ ├── 问题修复.md │ └── 状态巡检.md └── CLAUDE.md每个.md文件就是一个命令定义。文件开头写了触发命令名、参数说明、简短描述后面跟着命令真正执行的提示词。以/提交信息为例配置文件核心结构如下--- name: 提交信息 description: 对比 git 暂存区改动按规范生成提交信息 参数: 无 --- 按 Conventions 生成一条 git commit message。 先执行 git diff --cached 查看暂存区改动分析改动文件和内容。 要求 1. 提交信息格式 type(scope): subject 2. 如果包含破坏性变更在正文中说明 BREAKING CHANGE 3. 简要描述为什么做这个改动而不是仅描述改了什么 4. 主体内容使用中文type 使用英文标准词汇 5. 最多提供 3 条候选信息并给出简短的选择理由CLAUDE.md文件放的是项目级偏好比如这个团队的风格规范、禁止触碰的文件、测试要求。每个命令在执行过程中会自动感知这个文件里的规则。3.2 参数设计怎么让命令“好用、不容易用错”参数设计是一门分寸感很强的学问。参数太少命令灵活度不够参数太多使用门槛升高。我录过 10 个命令里有 7 个不需要任何参数剩下 3 个最多 2 个参数。为什么偏好在“少参数”方向因为命令区别于脚本的本质在于它应该有“智能默认值”。比如/日志分析如果不传时间范围就默认分析最近一小时的日志如果传时间范围就按传的来。Claude Code 在解析命令时能理解自然语言参数你可以说“最近 2 小时”也可以说“2025-12-01 当天”。对 AI 来说这没有区别但对人来说输入的自然语言比你记忆一套标志位语法要好得多。参数尽量用$变量表示并在命令描述里写清楚参数格式--- name: 代码审阅 description: 审阅指定文件的代码质量 参数: $FILE 目标文件或目录 ---此外我强烈建议每个命令的描述里带上“使用前提”比如“/日志分析 需要在项目目录下执行”“/提交信息 需要先 git add”。这些描述会展示在命令列表里能显著减少用错的概率。3.3 规则文件命令效果差异最大的因素很多人的命令效果不稳定最根本的原因是全局规则文件写得太粗糙。CLAUDE.md里我放了以下六块内容项目语言和框架基础信息只有 Claude 知道项目用 Vue 还是 React、用 Python 还是 Java才能给对建议代码风格偏好分号要不要、缩进两个还是四个、组件命名用 PascalCase 还是 kebab-case禁止自动修改的文件清单比如 lock 文件、dist 目录、自动生成的 SDK 代码AI 看不懂这些文件千万别动测试约定测试文件放哪、命令怎么跑文档语言默认输出中文除非用户明确要求英文常见坑比如某些第三方库的已知问题AI 检查代码时遇到相关模式要特别关注举一个具体例子。某次在一个发版前的仓库里跑/代码审阅Claude 一直报错说某个第三方依赖的代码有问题。但实际上那是构建工具自动生成的、不能手改的文件。后来我在规则里加了“/src/libs/目录下所有文件为自动生成文件发现问题时标记为‘不可修改需上游修复’”这个问题就消失了。规则文件不是摆设它是命令效果的放大器。3.4 配置进团队仓库和个人全局配置的区别这套命令包有两个层级个人全局配置和项目级配置。个人全局配置适合那些与项目无关的通用命令比如“提交信息”“文档生成”。项目级配置适合绑定当前项目上下文的内容比如“数据库表结构”“目录风格”。我实际使用时分得很清楚与业务强相关的内容API 路由、数据模型放项目级CLAUDE.md通用 AI 交互偏好、通用命令定义放个人配置。原因是项目级配置要跟着仓库走方便团队成员共享。通用命令挪到个人配置后无论在哪个项目里都能唤起不用每个仓库粘一份。3.5 版本管理与团队分享命令包本身也是一个代码库值得用 Git 管理。我会把命令包单独建一个配置仓库.dotfiles 仓库管理模式改完命令后提交一条feat: 增加接口调试命令。团队其他成员可以直接 pull 下来放入自己的配置目录如果项目需要也可以把这套命令目录拷贝到项目根目录的.claude/下分享给参与这个项目的所有人。一份配置能不能在团队推广很大程度取决于“命令文档是否清晰”。我给每个命令都写了使用说明包括这个命令解决什么问题在什么场景下用执行的先后顺序是什么比如先 /状态巡检 再 /代码审阅常见误用方式命令文档写在每个命令的description字段和配套 README 里。好的命令包应该让队友拿到手之后不用再问你“这个命令怎么用来着”。4. 真实场景中的完整工作流串联从接手项目到提交上线光有命令清单还不够真正顺手的是把它们按场景串成工作流。我拿最近处理的一个遗留系统为例完整走一遍这套流程。4.1 开局项目状态巡检活还没开始干先跑/状态巡检。输出里能看到这个项目是一个内部的报表系统后端用了 Python 加一个老版本 ORM前端是 Vue 2。依赖里有几个已停止维护的包。目录结构里有一个scripts/report_generate.py看起来像是核心模块还有 47 个 TODO 待办。分支上挂着十几处未提交改动看起来是上一个同事改到一半的状态。看完成巡检结果我对项目的“健康状况”就有底了。这种一眼扫过去完全摸不着北的旧项目先巡检再动手能少走很多弯路。4.2 动手改需求前先看代码再重构这次需求是“报表导出增加 CSV 格式”。我先用/代码审阅 scripts/report_generate.py过一遍核心文件。审阅结果指出两个问题一是数据量大的时候内存占用会翻倍因为没有用生成器逐个写入二是异常处理覆盖不足数据库查询出错时会直接抛给前端。对于我这种刚接触这个项目的人来说这种及时的提醒非常关键不用等代码跑到线上出问题才后悔。看完审阅结果我继续用/重构建议设计“如何接入 CSV 导出且不影响现有 Excel 导出逻辑”。重构建议给出的方案是抽象一个ReportExporter基类分别实现 Excel 和 CSV 两个子类调用处按格式参数切换。按这个结构改完后改动面最小风险也可控。4.3 写完代码后单测补全、接口调试、文档生成功能写完跑一遍/单测补全。它读了report_generate.py的现有测试文件识别到测试覆盖了 Excel 导出路径但 CSV 导出路径完全没测。于是生成了 CSV 导出的测试用例包含正常数据导出、空数据导出、字段映射缺失三种场景。我补充提交后覆盖率从 61% 提升到 78%。这个项目前端调接口的方式我不熟。直接用/接口调试 接口路径: /api/report/export 场景: 导出CSV它会自动读取路由定义把请求方法、参数、返回结构列出来。前后端联调时省去了抱着接口文档反复翻找的流程。文档目前基本空白。跑完/文档生成它按照代码里的注释生成了report_generate.py的模块文档包括导出流程、参数说明、异常类型汇总。一并提交到仓库里后面的同事接手就轻松多了。4.4 提交与排障提交信息、日志分析、问题修复功能联调完毕执行git add后调用/提交信息生成的候选信息feat(report): 增加 CSV 导出支持 - 抽象 ReportExporter 基类新增 CsvExporter 实现 - 调整导出接口以支持 format 参数 - 补充 CSV 导出路径的单元测试我选了这版理由很充分它概括了重构背景也说明了技术方案后续回溯 git history 时能知道这次改动背后的意图。上线后监控发现一个报错。我导出日志跑/日志分析它识别到 CSV 导出接口在空数据时抛出的类型错误定位到是因为fields为空时 CSV 表头构造逻辑走了错误分支。拿到这个定位结果直接用/问题修复提供修复方案将表头构造逻辑提前判空空数据时直接返回空文件。修复后重新跑单测全部通过。4.5 工作流串联的总结感言这一整条链路从接手项目到交付功能以前我至少要折腾一整天这套命令包稳定情况下一个上午就能完成。不是每次命令输出都完美但可以快速确定“哪一步有问题”而不是反复手工操作去猜。版本规划上也更清晰。用完了测试、审阅、生成文档、生成提交信息再回看git log这条线比以往规整太多。5. 常见问题与排查技巧命令包用着用着出问题怎么办任何工具用久了都会遇到问题。命令包也一样。我把自己用这 10 个命令过程中遇到的典型问题和排查思路整理成速查表。5.1 命令没有按预期执行如果某个命令完全不触发或触发了但行为不对首先检查命令配置文件名与name字段是否一致。命令名里不要有空格可以用中文但不要用“代码 审阅”这种带空格的写法也不要包含会被解析出歧义的符号。然后检查工作目录是否正确。很多命令内部会调动git、读取文件如果当前目录不是项目根目录而是子目录相对路径就可能会出问题。一个快速验证方法是在项目根目录下重新执行。5.2 上下文太长响应变慢且效果下降命令本身加上项目文件内容叠加起来容易超过模型上下文窗口或可用冗余。我遇到最多的是/日志分析和/代码审阅。解决思路是“先缩小再分析”。在命令配置里强制增加一步“先读取文件大小如果超过阈值优先提取代码中的关键函数/关键目录作为分析对象避免一次性读入整个大文件。”或者在日志分析场景先按时间过滤、按日志级别过滤再判断是否读入。5.3 中文输出格式混乱命令要求输出成表格但 AI 偶尔会输出成一大段文字。这种情况基本是因为用户在原场景中追加的其他指令干扰了命令的说明。有一个相对稳定的小技巧在命令提示词里把“必须输出表格”这样的要求重复两遍并明确“不要在其他解释性文字中夹杂表格数据”。在关键位置强调一遍输出稳定性会明显变好。5.4 命令被“串场”污染这是比较隐蔽的问题。一个命令执行完之后后续继续对话新命令会“沿用”前面的语义。比如先跑了/提交信息再跑/日志分析AI 可能误将日志内容视为“最近的代码提交内容”。解决方法是命令文件里开头加一句“忽略与本次命令无关的对话上下文”。这样能有效阻断串场。另外建议在执行下一个命令前按 Esc 或清理一下会话上下文。5.5 生成的代码不可靠甚至直接编译失败AI 生成的代码偶尔引用不存在的 API 或写错变量名这无法完全避免。我的处理经验是要求命令输出后自动执行“自检”。所谓自检就是让 Claude 检查自己生成的代码先看引用的函数和变量是否在上下文中定义再看语法是否完整最后对照导入表的模块名。这一步放在输出的最后能在很大程度上减少低级错误。测试类和接口调试这类命令的效果会稳很多。5.6 不同项目之间命令行为不一致如果同一命令在不同项目里效果差异巨大十有八九是规则文件差异导致的。项目 A 的CLAUDE.md里写了“工程文件在 src 目录下自动生成的代码不要动”项目 B 没有这些规则AI 自然只能根据默认经验来响应。建议每个项目都在根目录放一个CLAUDE.md把项目独有的上下文写清楚。哪怕只写三行也比没有强。6. 一些踩坑后的心得怎么把命令包做得更好用6.1 命令要“小步快跑”不要追求一步到位一开始我设计命令时总想把所有规则一次性塞进一句话里。结果效果反而不好。比如/代码审阅最初要求“同时检查代码质量、性能、安全、可维护性、设计模式并生成重构建议”。输出内容太多反而没有重点几乎不能用。后来我把所有命令的输出都强制收敛成“最多三个重点”最严重的问题必须先列出来其余问题用一句话汇总。这样做之后输出质量明显提升人也更容易消化结果。6.2 把“不要做什么”写进命令里提示词里如果少于 10% 是“不要做什么”命令大概率会在某些边界上跑偏。给几个实际例子“不要在回答中修改用户的代码如果修改则给出完整 diff。”“不要将自动生成的文件列为问题除非是改造方案。”“不要假设测试环境已经配置了数据库连接需要在建议中给出 mock 方案。”“不要使用超出项目 dependencies 的库除非给出理由且用户确认过。”增加了一层“否定约束”让命令的安全边界变得清晰。AI 不容易“自由发挥”。6.3 测试命令本身迭代命令包也需要回归每次修改命令的提示词最好都用同一份样例数据回归一遍。我给 10 个命令各准备了一个测试样例文件放在配置仓库里。修改某个命令后对照样例重新跑一次看输出格式是否规范、关键要求是否被遵守。这样做能有效防止改坏原有功能。6.4 不要过度自动化这一点可能有些反直觉但我真心提醒不是所有事情都适合交给 AI 自动执行。比如自动重构代码、自动批量调整文件只要命令一开改动范围很难预期风险极大。我的所有命令默认都是“生成建议供用户确认”只有用户明确说“执行”之后AI 才会动手修改文件。我宁可人肉确认一遍也不半夜被线上事故吵醒。7. 后续可以怎么扩展这套工作流包这套命令包目前运行得比较顺手我还在持续扩展。目前已经在尝试的方向有两个。一个是结合 CI 流程。计划把/代码审阅和/单测补全的执行结果以评论形式回写到 Pull Request 上。这样不只本地开发时用命令团队在 code review 环节也能借助 AI 覆盖常见问题。另一个是给不同技术栈定制预置命令。现在命令包是通用版在不同框架下细节有差异。考虑按“前端 Vue 项目命令包”“Python 服务命令包”“Java 后端命令包”拆分不同版本配合对应的规则文件开箱即用性会更好。如果这篇文章看下来的读者也想自己搭一套我的建议是不要照搬我的 10 个命令先拿一周时间记录自己日常操作哪些动作重复度最高挑出 3 个做成命令用熟了再逐步扩充。命令包的价值不在于数量而在于每个命令都能真正帮你省下时间。我自己试错了两三轮才找到合适的结构你如果在折腾过程中碰到奇怪问题大概率是规则文件和参数设计的问题对照前面第 5 节逐条排查一下基本都能解决。我个人用下来的最大感受就是“中文命令”这一层设计让这套东西在团队里的接受度变得异常高。如果你也想快速验证自己的 AI 编程工作流不妨从第一个命令开始挑一个你每天都要重复做的动作花十分钟做成命令很快就能尝到甜头。
阅读完成 · 觉得有帮助？
