把你的 slop PR 描述藏到后面去

Source: Simon Willison Published: 11/9/2026, 12:25:05 AI English PR

AI summary

如今我项目里的多数改动都来自 Claude Code 或 Codex 替我开的 PR，而 PR 就是我的工作单元：把提交打包在一起、反复迭代直到功能完成、记录决策再合并。现在的编码代理很擅长写 PR 描述——准确又全面，会讲清问题、详细方案和验证步骤，信息量很大。它未必是 slop，但读起来像 slop：AI 写的 PR 一眼就能认出，我的第一反应就是"这么多我可不会全读"，不管内容多准确有用，光是想到读它比写它花的时间还长，我就立刻没了兴趣。

Translation(model translation, not the source's own text)

把你的低质 PR 描述藏在

把你的低质 PR 描述藏在 <details><summary>

2026年11

datasette PR #3042：通过一个小型 loader 按需加载 edit-tools.js——“edit-tools.js（约 220KB）此前会在每个表格、行和数据库页面上加载，即使对无法编辑任何内容的用户也是如此。现在只对拥有编辑权限的用户加载，并且是在他们首次与编辑功能交互时（包括鼠标悬停在编辑链接上）才加载。”

datasette-agent PR #51：register_agent_reference_types 插件钩子——“让插件可以通过新的 register_agent_reference_types(datasette) 插件钩子，把自己的条目类型添加到聊天编辑器的 # 标记中。”——如上图所示。

llm PR #1838：新增 llm openai endpoint add/list/remove/path 命令——“新增用于管理 extra-openai-models.yaml 中记录的命令，这样 OpenAI 兼容端点就可以从命令行保存，而不必手动编辑 YAML。”——随后附上了 --help 的输出。

记忆口诀

我以前总记不住这两个标签的顺序——到底是 <details><summary> 还是 <summary><details>？

下面两个技巧帮到了我。

第一，也最明显的一点：<summary> 显然就是用来概括 details 的那部分。它是你那行可点击展开的文字所用的标签——于是 <details> 元素必须把其余所有内容包起来。

更好的技巧是，永远把这两个标签叫作 “details-summary”。

“details-summary” 是两个音节加三个音节。它念起来比 “summary-details” 的三二组合要顺口得多。

把 “details-summary” 大声念上几遍，你就再也不会忘记这两个标签的顺序了。

（我还是希望 GitHub 能在他们的 Markdown 编辑器里为此加一个按钮——一部分是为了让我不必在手机键盘上费劲地敲它，一部分也是为了把这个功能的存在传播给更多 GitHub 用户。）

把你的低质 PR 描述藏在 <details><summary>

记忆口诀

更多近期文章