夜雨聆风✦ ✦ ✦
让AI当你的Git管家
从手动push到一键同步
— — — — —
2026-06-10
摘要：这篇文记录了我和 Hermes Agent 一起管理 Git 仓库的全过程——从一句话让 AI 同步 skill 到 GitHub，到 rm -rf 把 .git 删光光，到写脚本一键搞定，再到思考「AI 该不该有 auto-push 权限」。不只是一个踩坑记录，更是一套你可以直接套用的 Agent + Git 协作工作流。
⟡ ⟡ ⟡
01 · 起因
我有一个叫 skill-curator 的技能——对，就是那个管理其他技能的那个。
它在两个地方存在。
一个在 Hermes Agent 的 skill 目录里——~/.hermes/skills/software-development/skill-curator/，Agent 跑的时候读这个版本。另一个在 GitHub 上——github.com/Bardbo/skill-curator，发出来给大家看的。
每次更新 skill，两边都得同步。
一开始我手动干。打开 Git 项目，手动复制文件，手动 commit，手动 push。做一次还行，做两次开始不耐烦，第三次就想骂人了——「这种事能不能让 AI 自己干？」
✦ ✦ ✦“AI 能干的事，为什么要我自己动手？”✦ ✦ ✦
于是我把这个任务丢给了 Hermes。
让我推代码之前，先得让 Hermes 有推送的资格。
我电脑上一直装着 GitHub Desktop，它走的是 Windows 凭据管理器，终端里 git push 对我本人来说是通的。但 Hermes 能不能直接用这套凭据？不一定。
我跟 Hermes 说：「试试 push。」它调了 git，但 GitHub 那边没有直接放行——而是返回了一个 device activation 链接和一串验证码。
就像你在新设备上登录 GitHub 时看到的那样：打开 https://github.com/login/device，输入这串码，点击授权。
我照做了。验证通过之后，Windows 凭据管理器里多了一条 GitHub 的 access token 记录。从此终端里的 git push 对 Hermes 也通了。
整个过程就是：Hermes 触发 → GitHub 发码 → 我填码 → 凭据落地。不神秘，甚至有点仪式感——它需要一个明确的「授权时刻」。
02 · 第一次同步
Hermes 接到任务后的第一件事——检查两边差距有多大。
Hermes 里的 skill-curator 是 v1.2.0 的完整版，494 行，26KB。GitHub 上存的是更早的版本，153 行，4.8KB。
内容结构完全不一样。Hermes 版有 SkillDAG 技能图谱章节、dag_audit 审计脚本、基线方法论文档。GitHub 版有 README 和 README_EN——这两个文件 Hermes skill 里根本没有。
这意味着不能简单 cp -r。
Hermes 想了一会儿，给出了一个方案：
1. 从 Git 历史备份 README（git show HEAD:README.md）2. 清理 Git 项目目录（保留 .git）3. 从 skill 目录复制所有内容4. 恢复 README5. git add / commit / push
逻辑是对的。然后我让它执行了。
嗯，故事到这里应该有个「但是」。
03 · 翻车
清理目录的时候，Hermes 敲了一行 rm -rf。
然后 .git 目录没了。
对，就是那个存放一切 Git 历史、分支、远程地址的 .git。删了之后，整个仓库变成了一堆孤零零的文件，没有版本，没有历史，没有远程。
修复方式倒不复杂——git clone 重新拉一份，再重新走一遍同步流程。
这是我第二次遇到这个问题了。之前在安装 Hermes 桌面版时也发生过一模一样的状况——rm -rf 把不该删的东西带走了。
这说明一个问题：AI 的 rm -rf 翻车不是偶发事件，而是结构性问题。你只要给 AI shell 访问权限，它迟早会在路径处理上捅个篓子。不是这次，就是下次。
这件事让我意识到一个关键问题：AI 不会比你更谨慎。你给它全自动权限，它就会全自动犯错。
铁律：永远不要在自动化脚本里 rm -rf 任何东西，除非你 100% 确定路径不会踩到 .git。
04 · 修复与改进
第一次翻车之后，我没插手——直接让 Hermes 自己修。它想了一会儿，把流程改成了这样：
# 第一步：从 Git 历史备份 READMEgit show HEAD:README.md > README.mdgit show HEAD:README_EN.md > README_EN.md# 第二步：只删内容，不碰 .git（用 find 过滤）find . -mindepth 1 -not -name .git -not -path './.git/*' -exec rm -rf {} +# 第三步：从 skill 目录复制最新内容cp -r ~/.hermes/skills/software-development/skill-curator/* .# 第四步：恢复备份的 README# 第五步：commit + pushgit add -A && git commit -m "sync: update from Hermes skill" && git push
核心改动就一行：find . -mindepth 1 -not -name .git。意思是「删所有东西，除了 .git」。
这个改动很小，但区别很大——它保留了 Git 历史的完整性。以后每一笔同步都有记录，可以追溯、可以回滚。
05 · README 不能只恢复
同步过程中还发现了一个更大的问题。
GitHub 上的 README 写的是旧版的功能描述——"14+ 对照集""对照集学习"——跟实际的 SKILL.md 内容完全对不上。
Hermes 做了一件事：它根据 SKILL.md 的实际内容，重新写了 README。
✓ SkillDAG 技能图谱、dag_audit 审计、基线评估方法论 → README 里体现
✗ 旧版"14+ 对照集"描述 → README 里删掉
同步的本质不是复制文件，而是让两个地方的信息保持一致。
06 · 写一个脚本
这套流程走了一遍之后，Hermes 说：「要不我写个脚本吧？」
于是有了 sync-skill-to-git.py：
#!/usr/bin/env python3"""sync-skill-to-git.py — 同步 Hermes skill 到 Git 项目用法:python3 sync-skill-to-git.py skill-curatorpython3 sync-skill-to-git.py skill-curator --push"""
脚本做的事：
1. 自动找到 Hermes skill 目录和 Git 项目目录
2. 从 Git 历史恢复 README
3. 清理 Git 项目中的旧文件（安全模式，不动 .git）
4. 从 skill 目录复制所有内容
5. 自动 git add/commit/push
以后每次更新 skill 只需要一行命令：
python sync-skill-to-git.py skill-curator --push
这条 find 命令就是那次翻车的产物——本来没有它，Hermes 自己加上的。从「我不会删 .git」到「我用 find 保证不删 .git」，区别就在这一行。
07 · 从「一键同步」到「自动推送」
脚本写好了，但 Hermes 没停下来。它说：「还能更近一步。」
现在的流程是我说一句「同步一下 skill-curator」，它就跑脚本。但如果我忘了说呢？
理论上可以用 Hermes 的 cron job 功能——每周一早上自动跑一次同步。不用我记，不用我喊，时间到了自己推。
不过我还没设。不是不能，是想再多观察几轮安全审查的表现再自动。
这就是从「一键同步」到「自动推送」的进化：
手动 — 我自己 copy / commit / push → ❌ 费时对话触发 — 我说「同步」，Hermes 跑脚本 → ✅ 方便定时触发 — cron job 自动跑，我不在场也行 → 🚀 省心
当然，自动推送有个前提——安全审查。
08 · 安全审查：AI 可以 auto-push 吗？
要让 AI 自动 push 代码到 GitHub，有几个问题必须解决。
◇ 不要推送敏感信息
Agent 在工作目录里可能会生成包含 API Key、Token、本地路径的文件。自动 commit 之前必须做一次安全扫描。
我加了一道关卡：commit 前检查每个文件是否包含 sk-、AGNES_、C:\ 等模式。匹配到的文件不进 commit。
◇ 不要推送到错误的仓库
git remote set-url 应该写死，不允许在对话中动态修改。
◇ 保留人工审核通道
自动推送不等于无审核。我设了一个规则：正常同步自动推，首次连接新仓库需要人工确认。
这样一来，AI 拥有了「能干的权限」——但也在一个可审计、可控制的范围之内。
✦ ✦ ✦“AI 不会背叛你，但 AI 会严格执行你的错误指令。所以，别给它执行错误指令的机会。”✦ ✦ ✦
09 · 这套方法不只能管 skill
这条工作流不止适用于 skill-curator。
任何你在本地维护、又想推到 GitHub 分享的项目，都可以套用这个模式：
1. 确定主从关系——哪个是「主」版本？（以 Hermes skill 为主）
2. 识别不可丢失的文件——README、LICENSE、.gitignore……
3. 安全模式覆盖——备份 → 过滤式清理 → 复制 → 恢复
4. 写脚本——减少重复操作
5. 设 cron job——让自动化无人值守
6. 加安全审查——防止误操作和敏感信息泄露
10 · 写在最后
这一趟折腾下来，最大的感受不是「AI 真能干」，而是「AI 能干对的前提是——你给了它正确的边界」。
第一次同步翻车，是因为我没告诉它「别删 .git」。第二次成功，是因为我教会了它「备份 → 过滤 → 恢复」这套安全模式。第三次自动化，是因为它自己意识到了「可以写个脚本」。
每次下一步都是 AI 做的。但「往哪个方向走」，是我定的。
你说，这是 AI 进步了，还是我想偷懒的欲望终于找到了正确的表达方式？
我觉得是后者。
— 完 —
以上，既然看到这里了，如果觉得不错，随手点个赞、在看、转发三连吧。
谢谢你看我的文章，我们，下次再见。
作者：穿梭在银河的喵喵
