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

背景

上篇 blog
【Agent】【OpenCode】bash 工具提示词（commit 注意事项）（二）
分析了给 AI 划定的一些红线，这些红线用来约束 AI 在执行任务时的边界，比如除了运行 Git 相关的 Bash 命令外，不能执行其他命令来读取，或者探索用户的代码，不能使用 TodoWrite 或 Task 这类工具（AI Agent 内部的专用的系统级工具，主要是为了保持对话的简洁和专注），禁止擅自推送到远端，禁止使用交互式命令（带 -i 选项），没有改动就别硬提交，然后接着分析了合并请求 Pull Request 的要求，首先是与 GitHub 相关的操作，不能直接用 git 命令，而是用 gh 官方命令，然后分析了 AI 创建 PR 应该遵守的标准流程，比如并行收集信息，搞清楚当前当前分支和远端主分支之间的差异等，下面继续分析

OpenCode

OK，接着分析最后剩下的 bash 工具提示词

下面详细看下

• 分析所有改动，起草 PR 摘要：这里要求 AI 必须仔细分析所有包含在 PR 里的改动，这里特意用三个感叹号强调，不能只看最新的那次提交，而是要看从主分支分叉出来以后得每次提交，只有掌握了全部历史，AI 能才能写出一个完整，准确的 PR 总结
• 并行执行，提升效率：这里再次强调了多线程工作，如果条件允许，应该同时运行命令，然后举了一个反例（需要串行执行的例子）
  1、创建新分支（如果当前还没在独立分支上）
  2、推送到远程，如果需要推送，要加上 -u 参数（也就是 git push -u origin 分支名），这样能把本地分支和远程分支关联起来，以后直接输入 git push 就可以
  3、创建 PR：通过 gh pr create 来正式发起 PR
• 这里强调了一个小细节：HEREDOC，提示词特意要求用 HEREDOC 的格式来传递 PR 内容，下面说下 HEREDOC

HEREDOC（也叫 Here Document）可以理解为一个原封不动的多行文字包裹功能，在写代码或者敲命令时，如果想输入一大段包含换行，引号，或特殊符号的文本，通常非常麻烦，因为系统可能会误认为那些引号是代码的一部分，或者把换行当成命令结束了，而 HEREDOC 的作用就是告诉计算机，从现在 EOF 开始，到指定的结束标记 EOF 出现之前，中间所有的内容都当成纯文本，原封不动地保留下来，不进行内容解析

结合上面的 gh pr create 命令，下面来看看这个包裹是如何打包的

--body "$(cat <<'EOF' ... EOF)"

• <<'EOF'：End Of File 的缩写，这里用了单引号，表示后续的内容完全保持原样，里面的 $ 变量也不能替换
• ... 中间内容：这里可以随意写 PR 的标题，比如（## Summary），列表（- 修复了 xxx），换行等，完全不用担心格式会被系统误解析
• 最后的 EOF：这里表示多行文本到此结束

如果没有 HEREDOC，如果要在命令行里输入多行带格式的文本，就得写得像下面这样：

gh pr create --body "## Summary\n- 第一点\n- 第二点\n..."

很麻烦，需要把所有换行符写成 \n，遇到引号还需要不停地加反斜杠转义，还很容易写错，所以这里提示词特意要求用 HEREDOC，就是为了让 AI 在写 PR 描述时，能够优雅，不出错地把长文本直接塞到命令行里，避免因为格式错乱导致 PR 创建失败

• 接着再次提示了，创建 PR 也禁止使用 TodoWrite 或 Task 等内部工具
• PR 创建完成后，把生成的 PR URL 发给用户，方便用户直接点开查看检视

最后提示了如何用 gh api 命令去查看某个 PR 下的评论，OK，bash 工具分析完毕

OK，本篇先到这里，如有疑问，欢迎评论区留言讨论，祝各位功力大涨，技术更上一层楼！！！更多内容见下篇 blog
【Agent】【OpenCode】bash 工具提示词（完结）