昨天我在 Dependabot 的 uv 支持的 issue 下面发了一条评论：
dependabot/dependabot-core#10478 · GitHub
起因是，Dependabot 最近支持更新 uv 的 lockfile 了，但是支持的很不好，总是会给出 broken 的 lockfile，大家就都在下面抱怨。很搞笑的是，大家不知道是不是没看出来其实都是同一个问题，还是想借此机会给自己的项目打广告，很多人在评论中附上自己的项目的 CI 日志，即使这些都是重复的
我昨天的评论，就是在想，既然我本地是可以修复（重建？）这个 lock 文件的，那我为什么不能在 GitHub Actions 里运行？为什么不能在 Dependabot 打开一个 PR 的时候自动地触发修复？
然后我就跟 LLM 简要描述了下，稍加修改就成了。
name: Fix uv.lock for Dependabot
on:
push:
branches:
- "dependabot/uv/**"
workflow_dispatch:
jobs:
update-lockfile:
permissions:
contents: write
runs-on: ubuntu-latest
steps:
- name: Checkout repository
uses: actions/checkout@v4
with:
ref: ${{ github.ref }}
- name: Set up Python
uses: astral-sh/setup-uv@v5
with:
python-version: 3.12
- name: Fix lockfile
run: uv sync
- name: Commit and push uv.lock if changed
run: |
git config --global user.name 'github-actions[bot]'
git config --global user.email 'github-actions[bot]@users.noreply.github.com'
# Check if uv.lock was modified or created
if git diff --quiet --exit-code uv.lock; then
echo "uv.lock is up-to-date."
else
echo "uv.lock changed, committing updates."
git add uv.lock
git commit -m "fix `uv.lock` after dependency update"
git push origin HEAD:${{ github.ref_name }}
fi当然，还是我一直以来的观点：
LLM 辅助编码的上限是你的能力
比如我有一些碰壁的经历，让我知道：
- 提交到
github.ref会导致一个很奇怪的 bug，GitHub 会以 Dependabot 的身份把你的那个 ref merge 过来。虽然我上面的代码中最后是提交到github.ref_name，但这是我改的，LLM 生成的不是这样 - LLM 忘记了
permissions: { contents: write } - LLM 让我在 job 里的
if:语句中判断是不是 Dependabot 的请求。事实上在on:中去 filter 更好
鲁棒地编码
我觉得过了这么久，我现在发现我有一个经验，就是尽量把代码解耦合，就能让 debug 容易很多。
比如，我有的代码，给每个幂等的函数结果都用 diskcache 缓存下来，这样调试的时候就会快很多，也会便宜很多（当代码需要一些LLM请求时）。这也使得复现更容易了。
当然，用 hmr 会更高效，因为它的 invalidate 是 on-demand 的，而且不涉及重启进程。不过 hmr 0.3 我引入了一些 bug 到现在还没修复 哈哈哈