【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除
背景
上篇 blog
【Agent】【OpenCode】bash 工具提示词（amend 风险）
继续分析了禁止使用 --amend 的两个场景，这两个场景都是为了保护用户的代码仓库不被意外修改，在 Git 里，--amend 修改历史记录是件很敏感的事情，尤其在多人合作的项目中，如果操作不当，容易导致代码冲突甚至丢失，首先是失败处理，如果提交失败，或者被钩子拒绝后，不能用 --amend，主要是为了保留失败现场，方便排查问题，然后是已推送处理，当代码被推送到远程后，不能用 amend，这是 Git 协作中很重要的规则：不能修改已经推送到远程的公共历史，因为 amend 的本质是篡改历史，使用 --amend 容易和别人已经拉取的代码产生冲突，导致别人的工作成果丢失等，下面继续分析
OpenCode
下面继续来看 bash 工具这里对 Git 规则的约束
首先是第一点，主要是说批量并行，大致就是在单次回复中，可以调用多个工具，当用户需要获取多个互不相关的信息，且这些命令大概率都会成功时，为了达到最佳性能，应该同时并行地运行多个工具调用（其实并行执行命令这点前面的提示词有提到过），然后给出了个例子
- 运行
git status查看所有未追踪的文件 - 运行
git diff查看暂存区和非暂存区的所有改动，也就是即将被提交的内容 - 运行
git log查看最近的提交记录，目的是让 AI 学习并模仿这个仓库现有的提交风格
接下来是第二点，这里规范了如何写好 Git 提交信息（Commit Message），要求 AI 模型在提交代码前，需要把暂存区里的改动都看过一遍，然后按照如下说明起草提交说明：
1、准确概括改动类型，用词要精准：首先要分析改动了啥，然后要准确总结定性，比如
- 如果是全新功能，提交信息里要用词
add表示新增 - 如果是对现有功能的该井，要用
update关键词，表示更新或优化 - 如果是修复 Bug，则必须用
fix关键词，表示修复 - 其他情况还包括
refactoring（重构），test（测试），docs（文档）等
总之，用词要精准，能够让看记录的人一下就能看出来这次改动的性质
2、绝对不能提交敏感文件 ：必须自动识别并过滤掉那些可能包含密码，或密钥的文件，比如 .env，credentials.json 等，不能把这些敏感信息提交到仓库里，如果用户明确要求提交这些文件，则必须发出警告进行提醒
3、描述简明扼要，重点说为什么，而不是做了啥：这里要求 AI 写的提交信息必须短小精悍（控制在 1~2 句话），而且要侧重于 Why，而不是 How，举个例子
- 反面例子（只说做了啥） ：修改了
user.js文件里的第 10 行代码，这种描述看了一头雾水，都不知道有啥用 - 正面例子（解释为什么）：修复用户登录失败的问题（直接点名本次改动的目的和价值）
4、确保信息真实，能够反映改动：最后再次强调了，写的提交说明必须和实际的代码改动完全对得上，不能文不对题
继续看后面两点
第三点描述和第一点类似，都是说如果几个指令互相独立的话，可以并行执行，但举的例子不一样，这里刚好反过来，给出了一个需要顺序执行的操作流程
- 把相关的未追踪文件（untracked files）添加到暂存区，相当于执行
git add - 带着之前起草的提交信息，创建这次提交，相当于执行
git commit -m ... - 提交完成，运行
git status再次确认一下是否真的提交成功
这里 git commit 需要在 git add 后面执行，而 git status 又必须在 git commit 之后执行
第四点提醒，如果提交失败，并且是被 pre-commit hook 钩子给拦截的话，AI 应该根据报错信息去修复对应问题，然后再创建一个全新的提交，这里和前面 blog 提到的禁止使用 --amend 场景是呼应的
OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Agent】【OpenCode】bash 工具提示词（commit 注意事项）（二）