一次小修复之后的提交说明

修好了一个问题，准备提交时，却不知道该写什么。这时可以让智能体先起草提交说明。它负责把代码差异整理成文字，你负责确认文字是否准确。目标不是写得漂亮，而是让以后查看记录的人知道，这次改了什么。

§ 先确定这次要提交的范围

Git 的暂存区可以理解为本次提交的候选清单。先用 git status 查看文件状态，再用 git diff --cached 查看已经暂存的差异。不要默认让智能体概括整个工作目录，否则还没准备好的改动也可能被写进说明。

如果一次改动同时包含登录修复和页面配色调整，先考虑分开提交。清楚的提交边界，比一句精巧的标题更有用。

§ 给智能体一段明确的要求

可以从下面这段话开始：

请只根据暂存区差异起草中文提交说明，不要修改文件或执行提交。标题概括主要变化；必要时用正文解释原因。不要声称测试通过，除非已有测试结果。不确定的地方请先问我。

有终端权限的智能体可以读取差异；没有这类权限时，你可以提供相关片段。分享之前先检查内容，避免发送密钥、访问令牌或客户数据。

§ 把观察和理由分开

智能体可能看出你增加了空值判断，却不知道这样做是为了修复哪种故障。理由需要你补充，不能让它猜。

例如，你告诉它“接口偶尔返回空列表，页面因此报错”，它就可以起草“修复空列表导致的页面报错”。相比“优化页面逻辑”，这句话更方便日后检索。但如果没有验证故障确实消失，就不要写成“彻底解决”。

§ 提交前核对三件事

• 说明是否只覆盖本次暂存的内容。
• 有没有虚构测试结果、性能收益或修复范围。
• 是否解释了必要的原因，而不是逐行复述代码。

项目已有格式约定时，沿用约定即可。刚开始不必追求复杂模板，准确的一句话往往足够。

§ 让连接方式留在后台

如果你使用 Claude Code 或 Codex，可以按工具支持的配置方式接入 Vana API。服务地址是 https://api.vanaapi.com，支持 OpenAI 兼容接口，也支持 Anthropic Messages 和 Gemini 原生协议，按实际令牌用量计费，无月费。你可以创建一个 Vana API 账户，从一次小提交开始尝试。

最后，把生成说明和执行提交分开。先读差异，再改草稿，确认后才提交。智能体减少的是整理文字的时间，不是你对提交内容的责任。