open-code-review 项目中的 AI 辅助 Git 提交解读 /commit 斜杠命令的工程实践【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review导读本文以 open-code-review 仓库自带的 Claude Code 斜杠命令 /commit 为切入点讲解如何让 AI 助手自动总结工作区变更、生成符合规范且为英文的提交信息并完成git add与git commit。文章同时结合仓库的贡献规范CONTRIBUTING.md、Agent 指南AGENTS.md以及 git.go 中的 Git 封装实现帮助读者理解这套提交前先审查、提交信息标准化、提交动作自动化的完整工作流并可直接复用到自己的 AI 编码流程中。一、/commit 命令是什么在 Claude Code 等支持斜杠命令Slash Command的 AI 编程工具中命令文件被放置在.claude/commands/目录下文件名即命令名。open-code-review 仓库在自己的 .claude/commands/commit.md 中定义了一个极简但功能完整的/commit命令其完整内容如下Please summarize your current changes, generate a commit message in English, then add and commit.这条提示词命令做了四件事对应 AI 助手执行的一个标准提交流程总结当前变更summarize your current changesAI 需要先分析git status、git diff等工作区状态理解改动内容生成英文提交信息generate a commit message in English提交信息必须以英文书写——这一点与仓库的 Agent 指南要求一致AGENTS.md 明确写道 Commit messages must be written in English暂存变更add执行git add提交commit执行git commit并附上第 2 步生成的提交信息。虽然命令文本只有一行但它的价值在于把总结—拟文案—暂存—提交这一日常高频操作固化为可重复、可协作的标准动作让 AI 在每次提交时都遵循同一套行为准则避免随意拟写提交信息。二、为什么提交信息必须是英文 Conventional Commits 规范/commit要求generate a commit message in English并非凭空设定而是 open-code-review 仓库工程规范的直接落地。2.1 全英文提交的工程背景AGENTS.md 规定源码文件.go、.sh、.js、.mjs、.ts、.tsx的注释、标识符和字符串一律使用英文并配有make english-check在 CI 中强制校验 ASCII 字符。提交信息是仓库历史的一部分同样要求英文以保证整个代码库从源码到提交历史的一致性。这是大型开源仓库常见的做法——多语言维护者共享同一份英文提交历史便于检索与追溯。2.2 Conventional Commits 提交格式关于提交信息的具体写法CONTRIBUTING.md 要求遵循 Conventional Commits 规范格式为type(scope): short summary [optional body]仓库给出的示例包括feat(agent): add support for custom tool definitions fix(llm): handle timeout errors in Anthropic API calls docs(README): update configuration examples即类型feat/fix/docs/refactor/test/chore等 可选的(scope)作用域 冒号与一句短摘要。项目中各模块名agent、llm、scan、session等都可作为 scope 使用。采用该格式的意义在于提交历史可被自动化工具解析例如项目的 release 说明即是从 Conventional Commits 自动生成的faq.md 中对此有明确说明而仓库也定义了与类型对应的分支前缀feat/、fix/、docs/、refactor/、test/、chore/提交与分支形成一一对应的语义。因此当/commit让 AI generate a commit message in English时合格的产出应当是一句形如feat(llm): handle timeout errors in Anthropic API calls的规范化提交信息而非随意的自然语言描述。三、提交之前先用 ocr review 做一次 AI 代码审查open-code-review 项目的 Agent 指南 AGENTS.md 在 Git Commit Notes 一节中给出了一个完整的提交流程而/commit是其中的收尾环节ocr review --audience agent --background briefly summarize the background requirements在提交前先运行 open-code-reviewCLI 名为ocr自带的代码审查命令让 Agent 以agent为目标受众审阅当前改动再执行提交。这意味着在这个项目的开发工作流里先审查AI 提交者或开发者先用ocr review发现代码问题再提交确认改动无问题后由/commit完成总结、拟信息、暂存与提交。这种审查前置的做法使提交的代码质量和提交信息的质量同时得到保障。/commit命令虽然自身只有一行但它处于 AGENTS.md 定义的完整 Git 工作流中实际价值依赖前置的审查步骤。3.1 行尾与二进制文件的处理AGENTS.md 还要求在提交时核验行尾Line endings必须为 LF 而非 CRLF必要时执行git add --renormalize .并约定新增的二进制文件必须将其扩展名加入.gitattributes。CONTRIBUTING.md 中也提到通过配置保证提交时 CRLF 被转换为 LF防止 CI 中出现行尾问题。这些约定同样属于/commit命令背后正确提交的完整定义——AI 在提交前应当确认暂存区内容符合仓库的行尾与文件属性规范。四、源码视角仓库中 Git 命令的封装方式为了理解/commit最终要调用的 Git 操作在项目代码中的形态可以查看 cmd/opencodereview/git.go。该文件封装了 CLI 所需的 Git 能力func runGitCmd(repoDir string, args ...string) ([]byte, error) { fullArgs : append([]string{-C, repoDir}, args...) cmd : exec.Command(git, fullArgs...) return cmd.CombinedOutput() } func runGitCmdStdout(repoDir string, args ...string) ([]byte, error) { fullArgs : append([]string{-C, repoDir}, args...) cmd : exec.Command(git, fullArgs...) return cmd.Output() }关键设计点所有 Git 子命令都通过git -C repoDir args...方式执行将仓库目录作为参数传入而非依赖进程当前工作目录避免多仓库并行操作时的目录状态串扰提供了两个变体runGitCmd返回合并输出stdout stderr适合诊断场景runGitCmdStdout只返回 stdout用于消费型结果如解析路径防止 git 的 stderr 警告污染数据。此外getCommitMessage函数展示了如何读取既有提交的完整信息func getCommitMessage(repoDir, commit string) (string, error) { out, err : runGitCmd(repoDir, log, -1, --format%B, --end-of-options, commit) ... return strings.TrimSpace(string(out)), nil }它通过git log -1 --format%B读取指定提交的完整正文并去除首尾空白。该能力在 open-code-review 中被用于读取被审查提交的说明例如测试 delegate_exec_test.go 中提到的commit mode auto-fills background from the commit message可见提交信息在项目中不仅是历史记录还作为后续代码审查的输入数据。这从侧面印证了/commit要求规范英文提交信息的意义机器可读、可复用。从源码结构看这个仓库把 Git 操作收敛在独立的git.go封装层中而.claude/commands/下的/commit、/tag命令则是在 AI 助手侧复用同一套 Git 语义git add、git commit、git tag两者配合构成了AI 自动化操作 程序化 Git 封装的双层结构。五、配套命令/tag 与版本发布与/commit同目录下的 .claude/commands/tag.md 定义了/tag命令展示了同一套AI 总结 执行模式的进阶用法。/tag的工作流是确定版本先执行git describe --tags --abbrev0获取最新标签若传入$ARGUMENTS如v1.2.0则使用之否则自动将补丁号加一如v1.1.5→v1.1.6生成摘要通过git log latest-tag..HEAD --oneline列出两次标签间的所有提交再用 13 行总结这段变更关注实现了什么/修复了什么而非罗列单个提交创建标签执行git tag -s new-version -m summary使用-s进行 GPG 签名并向用户报告所创建的标签与信息。可以看到/tag建立在/commit产生的规范化提交历史之上——正因为每次提交都遵循 Conventional CommitsAI 才能可靠地从git log输出中概括变更主题。二者合在一起构成了日常提交 → 版本发布的完整 AI 辅助链路。六、如何在自己的项目中使用这类命令如果你希望在 Claude Code 等工具中启用commit.md这类命令文件参考 open-code-review 仓库 .claude/commands/ 的目录结构即可项目级将命令文件放入项目根目录下的.claude/commands/如mkdir -p .claude/commands命令对当前项目生效用户级放入用户主目录下的~/.claude/commands/可跨项目全局生效。放置完成后即可在对话中直接输入/commit触发。需要说明的是open-code-review 的.claude/commands/面向的是本仓库自身的开发流程即维护者用 AI 助手向 open-code-review 提交代码这与插件生态中面向终端用户提供的审查类命令详见 integrations/claude-code.md用途不同但放置与注册机制完全一致。七、实践小结从一行命令到完整工程规范/commit的实际含义可以拆解为以下要点层面内容依据命令行为总结变更、生成英文提交信息、add commitcommit.md提交语言必须为英文AGENTS.md提交格式Conventional Commitstype(scope): summaryCONTRIBUTING.md前置流程提交前先运行ocr review --audience agent --backgroundAGENTS.md提交卫生LF 行尾、git add --renormalize、二进制文件入 .gitattributesAGENTS.md配套能力/tag基于提交历史自动生成带签名的版本标签tag.md程序化封装runGitCmd/getCommitMessage等 Git 封装git.go对开发者的实操建议将/commit命令文件放入项目的.claude/commands/目录让团队所有成员获得一致的提交行为在命令提示词中明确English Conventional Commits约束或直接复用本仓库的写法将代码审查如ocr review纳入提交前的固定步骤先审后提对提交历史做自动化消费如生成 changelog、版本摘要时保持提交信息的结构化是前提——/commit的价值正体现在这里。适用前提以上命令与规范以 open-code-review 仓库当前内容为准。若要在其他项目复用需按其所在组织的提交规范调整英文与格式要求ocr review步骤要求已安装 open-code-review 工具参见 安装文档。【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibabas scale. Hybrid architecture code review tool: deterministic pipelines LLM Agent, precise line-level comments, built-in multi-language ruleset (NPE, thread-safety, XSS, SQL injection), OpenAI Anthropic compatible.项目地址: https://gitcode.com/GitHub_Trending/op/open-code-review创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考