【声明】本博客所有内容均为个人业余时间创作，所述技术案例均来自公开开源项目（如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 命令，下面来看看这个包裹是如何打包的
bash
--body "$(cat <<'EOF' ... EOF)"<<'EOF'：End Of File 的缩写，这里用了单引号，表示后续的内容完全保持原样，里面的$变量也不能替换...中间内容：这里可以随意写 PR 的标题，比如（## Summary），列表（- 修复了 xxx），换行等，完全不用担心格式会被系统误解析- 最后的
EOF：这里表示多行文本到此结束
如果没有 HEREDOC，如果要在命令行里输入多行带格式的文本，就得写得像下面这样：
bash
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 工具提示词（完结）