【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如Github，Apache基金会），不涉及任何企业机密或未公开技术，如有侵权请联系删除

背景

上篇 blog
【Agent】【OpenCode】bash 工具提示词（commit 注意事项）（一）
分析了 bash 工具对 Git 规则的约束，首先是批量并行，在单次回复中，当用户需要获取多个互不相关的信息，且这些命令大概率都会成功时，为了达到最佳性能，应该同时并行地运行多个工具调用，比如同时运行 git status，git diff，git log 等互相独立的命令，接着规范了如何写 Git 提交信息，要求 AI 模型在提交代码前，需要把暂存区里的改动都看过一遍，并按照如下规则起草提交说明：准确概括改动类型，用词要精准；绝对不能提交敏感文件；描述简明扼要，重点说为什么，而不是做了啥；确保信息真实，能够反映改动等等，然后接着分析了需要串行执行的例子，最后提到了如果被 pre-commit hook 钩子拦截导致的失败，需要根据报错信息修复对应问题，再创建一个全新的提交，这点和前面禁止使用 --amend 场景是呼应的，下面继续分析

OpenCode

接下来继续看，下面是给 AI 划定的一些红线，用来约束 AI 在执行任务时的边界

下面详细看下

• 除了运行 Git 相关的 Bash 命令外，不能执行其他命令来读取，或者探索用户的代码，比如用 cat，grep，或 ls 去遍历整个项目，git bash 的任务时帮助用户提交代码，而不是来替用户做代码审计
• 不能使用 TodoWrite 或 Task 这类工具

TodoWrite 和 Task 这两个是 AI Agent 内部的专用的系统级工具

• TodoWrite：通常用来让 AI 生成一个可视化的任务进度条，比如列出 1、2、3、4 步，做完每一步打个勾 ✅️
• Task：通常用来让 AI 在后台把一个复杂的大目标拆分成几个小任务去并行处理

这里禁止使用主要是为了保持对话的简洁和专注

• 禁止擅自推送到远端：除非用户明确要求，否则不能执行 git push，commit 提交只是存在用户本地，而 push 推送则会把改动同步到服务器，这一步必须经过用户的允许
• 禁止使用交互式命令（带 -i 选项）：不能使用任何带 -i 选项的 Git 命令，比如 git rebase -i，或者 git add -i，因为这些命令会进入一个需要在终端里手动输入，选择或编辑的交互界面，而 AI 无法像人一样在终端里实时互动，一旦触发这种命令，整个流程就会直接卡死
• 没有改动就别硬提交：如果检查代码后，发现没有任何改动（既没有未追踪的文件，也没有修改过的文件），就不要为了提交而提交，创建一个空的 commit

下面看拉取/合并请求 Pull Request 的一些说明

首先第一部分，任何与 GitHub 相关的操作，比如处理 issue，创建 PR，检查 CI 状态，发布版本等，都用通过 Bash 工具调用 gh 命令（Github 官方命令行工具）来完成，如果用户给了一个 GitHub 网址，AI 也应该用 gh 命令去把里面的信息抓取出来，这里强调了 GitHub 相关操作的特殊性，不能直接用 git 命令，而是用 gh 官方命令

接着给 AI 规定了创建 PR 的标准流程：

• 并行收集信息（提升速度）：需要同时运行下面四个命令，来彻底搞清楚当前当前分支和远端主分支之间的差异
• git status：查看有没有还未被追踪的新文件
• git diff：查看暂存区和非暂存区的代码改动
• 检查远程分支状态，确认当前分支是不是最新的（相对于远程分支），以此判断需不需要先执行 git push 来更新远程分支
• git log 和 git diff [base-branch]...HEAD，这是最关键的一步，用来查看当前分支从远端主分支分叉出来后，所有的提交历史和完整代码差异

拿到上述信息后，AI 必须仔细分析所有即将被包含在这个 PR 里的改动，确保充分理解了从分叉点，到现在的每一次提交内容

OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog