企业官网建设流程全解析

open-code-review 项目中的 AI 辅助 Git 提交：解读 /commit 斜杠命令的工程实践

【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibaba's 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 助手执行的一个标准提交流程：

1. 总结当前变更（summarize your current changes）：AI 需要先分析git status、git diff等工作区状态，理解改动内容；
2. 生成英文提交信息（generate a commit message in English）：提交信息必须以英文书写——这一点与仓库的 Agent 指南要求一致，AGENTS.md 明确写道 "Commit messages must be written in English"；
3. 暂存变更（add）：执行git add；
4. 提交（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-review（CLI 名为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的工作流是：

1. 确定版本：先执行git describe --tags --abbrev=0获取最新标签；若传入$ARGUMENTS（如v1.2.0）则使用之，否则自动将补丁号加一（如v1.1.5→v1.1.6）；
2. 生成摘要：通过git log <latest-tag>..HEAD --oneline列出两次标签间的所有提交，再用 1～3 行总结这段变更（关注"实现了什么/修复了什么"，而非罗列单个提交）；
3. 创建标签：执行git tag -s <new-version> -m "<summary>"，使用-s进行 GPG 签名，并向用户报告所创建的标签与信息。

可以看到，/tag建立在/commit产生的规范化提交历史之上——正因为每次提交都遵循 Conventional Commits，AI 才能可靠地从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的实际含义可以拆解为以下要点：

对开发者的实操建议：

1. 将/commit命令文件放入项目的.claude/commands/目录，让团队所有成员获得一致的提交行为；
2. 在命令提示词中明确"English + Conventional Commits"约束，或直接复用本仓库的写法；
3. 将代码审查（如ocr review）纳入提交前的固定步骤，先审后提；
4. 对提交历史做自动化消费（如生成 changelog、版本摘要）时，保持提交信息的结构化是前提——/commit的价值正体现在这里。

适用前提：以上命令与规范以 open-code-review 仓库当前内容为准。若要在其他项目复用，需按其所在组织的提交规范调整英文与格式要求；ocr review步骤要求已安装 open-code-review 工具（参见 安装文档）。

【免费下载链接】open-code-reviewFast, efficient, battle-tested at Alibaba's 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