【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除背景上篇 blog【Agent】【OpenCode】bash 工具提示词git 提交规则分析了如何发送多条命令四条规则能并行的就并行有先后顺序的用不在乎失败的命令用;禁止用换行符然后是切换目录的规矩这点之前 blog 分析过然后是提交规则这些提交规则用来规范 AI 帮助用户使用 Git 命令提交代码时的行为防止 AI 自作主张改动 Git 仓库或者执行一些可能导致代码丢失的危险操作具体规则包括明确命令才动手严禁主动提交不动配置文件不执行毁灭性命令除非用户明确要求不绕过安全检查除非用户明确要求接着重点提到了使用--amend选项的注意事项git commit --amend 可以用来修改最近一次的提交信息但必须同时满足如下所有条件才能使用否则一律创建新的提交用户明确要求 amend或者是提交成功后 Git 钩子自动修改了文件需要补录而且要amend的提交必须是 AI 在这次对话中刚刚创建的并且这个提交还没有被推送到远程服务器下面继续分析OpenCode上篇 blog 提到了两个关键场景禁止使用--amend这两个场景都是为了保护用户的代码仓库不被意外修改在 Git 里--amend修改历史记录是件很敏感的事情尤其在多人合作的项目中如果操作不当很容易导致代码冲突甚至丢失下面来详细分析下这背后的逻辑首先是失败处理提交失败或者被钩子拒绝后不能用--amend这主要是为了保留失败现场方便排查问题有几个点保留历史痕迹如果一次提交失败了比如被 pre-commit 钩子拦截或者因为代码冲突没提交进去说明这次操作本身是有问题的比如需要先解决冲突或者更新代码如果 AI 此时强行用--amend去修补这个提交就等于把失败的尝试和修复后的结果混在了一起抹去了中间的过程清晰的排查链路让 AI 修复问题后创建一个全新的提交用户的 Git 历史记录里就会清晰地留下痕迹比如【第一次尝试失败了/被拒绝】-【第二次尝试修复了问题提交成功】这样万一后续代码出了 bug用户回看历史记录时可以清楚知道哪次修改是为了解决什么问题的接下来是已推送处理代码推送到远程后不能用amend这是 Git 协作中很重要的一条规则永远不能修改已经推送到远程的公共历史有几个点amend的本质是篡改历史当amend一个已经推送过的提交时Git 实际上是把原来的那个提交先删掉然后用同样的内容或修改后的内容生成一个全新的哈希值Commit Hash完全不同的提交来顶替引发别人的灾难假设用户和别人都在同一个分支上开发用户推送了提交 A而队友拉取了提交 A然后用户本地amend了提交 A变成了提交 Aa并强行推送到了远程此时远程仓库里的 A 变成了 Aa但别人本地还保留着旧的提交 A当别人再次拉取代码时Git 会发现远程的提交 Aa 和本地的提交 A 长得像但哈希值完全不一样此时 Git 会认为这是两份完全不同的代码就会产生极其复杂的代码冲突强制推送的风险要覆盖远程的旧提交就必须使用git push --force进行强推这在团队协作中是非常危险的操作因为该操作会直接覆盖掉别人可能已经基于旧提交开发好的功能导致别人的工作成果丢失所以基于以上两点提示词在上述两个场景对amend做了限制禁止使用最后这里再次强调了没有用户的明确要求禁止擅自提交改动否则会让用户觉得 AI 过于主动引发风险OK本篇先到这里如有疑问欢迎评论区留言讨论祝各位功力大涨技术更上一层楼更多内容见下篇 blog【Agent】【OpenCode】bash 工具提示词commit 注意事项一
82、【Agent】【OpenCode】bash 工具提示词(amend 风险)
【声明】本博客所有内容均为个人业余时间创作所述技术案例均来自公开开源项目如GithubApache基金会不涉及任何企业机密或未公开技术如有侵权请联系删除背景上篇 blog【Agent】【OpenCode】bash 工具提示词git 提交规则分析了如何发送多条命令四条规则能并行的就并行有先后顺序的用不在乎失败的命令用;禁止用换行符然后是切换目录的规矩这点之前 blog 分析过然后是提交规则这些提交规则用来规范 AI 帮助用户使用 Git 命令提交代码时的行为防止 AI 自作主张改动 Git 仓库或者执行一些可能导致代码丢失的危险操作具体规则包括明确命令才动手严禁主动提交不动配置文件不执行毁灭性命令除非用户明确要求不绕过安全检查除非用户明确要求接着重点提到了使用--amend选项的注意事项git commit --amend 可以用来修改最近一次的提交信息但必须同时满足如下所有条件才能使用否则一律创建新的提交用户明确要求 amend或者是提交成功后 Git 钩子自动修改了文件需要补录而且要amend的提交必须是 AI 在这次对话中刚刚创建的并且这个提交还没有被推送到远程服务器下面继续分析OpenCode上篇 blog 提到了两个关键场景禁止使用--amend这两个场景都是为了保护用户的代码仓库不被意外修改在 Git 里--amend修改历史记录是件很敏感的事情尤其在多人合作的项目中如果操作不当很容易导致代码冲突甚至丢失下面来详细分析下这背后的逻辑首先是失败处理提交失败或者被钩子拒绝后不能用--amend这主要是为了保留失败现场方便排查问题有几个点保留历史痕迹如果一次提交失败了比如被 pre-commit 钩子拦截或者因为代码冲突没提交进去说明这次操作本身是有问题的比如需要先解决冲突或者更新代码如果 AI 此时强行用--amend去修补这个提交就等于把失败的尝试和修复后的结果混在了一起抹去了中间的过程清晰的排查链路让 AI 修复问题后创建一个全新的提交用户的 Git 历史记录里就会清晰地留下痕迹比如【第一次尝试失败了/被拒绝】-【第二次尝试修复了问题提交成功】这样万一后续代码出了 bug用户回看历史记录时可以清楚知道哪次修改是为了解决什么问题的接下来是已推送处理代码推送到远程后不能用amend这是 Git 协作中很重要的一条规则永远不能修改已经推送到远程的公共历史有几个点amend的本质是篡改历史当amend一个已经推送过的提交时Git 实际上是把原来的那个提交先删掉然后用同样的内容或修改后的内容生成一个全新的哈希值Commit Hash完全不同的提交来顶替引发别人的灾难假设用户和别人都在同一个分支上开发用户推送了提交 A而队友拉取了提交 A然后用户本地amend了提交 A变成了提交 Aa并强行推送到了远程此时远程仓库里的 A 变成了 Aa但别人本地还保留着旧的提交 A当别人再次拉取代码时Git 会发现远程的提交 Aa 和本地的提交 A 长得像但哈希值完全不一样此时 Git 会认为这是两份完全不同的代码就会产生极其复杂的代码冲突强制推送的风险要覆盖远程的旧提交就必须使用git push --force进行强推这在团队协作中是非常危险的操作因为该操作会直接覆盖掉别人可能已经基于旧提交开发好的功能导致别人的工作成果丢失所以基于以上两点提示词在上述两个场景对amend做了限制禁止使用最后这里再次强调了没有用户的明确要求禁止擅自提交改动否则会让用户觉得 AI 过于主动引发风险OK本篇先到这里如有疑问欢迎评论区留言讨论祝各位功力大涨技术更上一层楼更多内容见下篇 blog【Agent】【OpenCode】bash 工具提示词commit 注意事项一