Hide your slop PR descriptions behind <details><summary>

用 <details><summary> 隐藏你的 PR 描述杂乱部分

Simon Willison 的博客

通讯

#smallhead

由以下公司赞助：

doubleAI — doubleAI 的 Maxwell 让软件在运行时更快，无需更改代码。

现已开放早期访问

用 <details><summary> 隐藏你的 PR 描述杂乱部分

2026年11月9日

如今我所做的大部分项目修改都以 Claude Code 或 Codex 为我打开的 PR 形式出现。PR 是我的工作单元——我用它们来打包提交，反复迭代直到功能完成，记录决策，然后合并最终结果。如今的编码代理在编写 PR 描述方面非常出色。

#### 它们过于擅长描述工作内容

问题是它们太擅长了。代理撰写的 PR 描述准确且全面。它描述了问题、详细解决方案以及验证步骤。这需要吸收大量信息。

这未必是杂乱内容，但读起来却像杂乱内容！

很容易识别出 AI 生成的 PR，和其他形式的 AI 写作一样，我的即时反应可以总结为“我不会读完这些”。信息的准确性或有用性无关紧要，我立刻会因为想到阅读所需时间可能超过作者写作时间而感到厌烦……即使作者是我自己！

我想要人类的编辑判断。我想要有人思考足够长的时间，为我提供一个经过人类批准的简介，让我在高层次上理解 PR 的目的，以及它是否值得我投入更多注意力。

我认为我找到了一种低效但感觉正确的方法。

#### 将大部分内容隐藏在 details/summary 中

HTML 的 <details><summary> 元素渲染为一个可展开的标题（summary），可以展开查看更长的文本。代码如下：

<
details
>
<
summary
>
Claude Opus 5.5
</
summary
>
<
h2
>
The hook
</
h2
>
Plugins implement
<
code
>
register_agent_reference_types(datasette)
</
code
>
...
</
details
>

渲染后显示如下：

关键的是，<details><summary> 在 GitHub Markdown 中受支持。你可以直接将这些标签放入问题评论或 PR 描述中，GitHub 会隐藏细节并仅显示摘要和展开箭头。

我开始在 AI 生成的拉取请求中使用这种方法。

我的 PR 开头段落将被精心选择，作为高层次解释的摘要——这是人类能够快速理解的最短文本。

我有时还会插入一张截图，因为图片通常是快速说明新功能的最佳方式。

完整的代理撰写文章随后以 <details><summary> 形式呈现。我通常使用模型名称和工作量等级作为摘要，以明确说明情况——例如“Claude Opus 5.5 Medium”。

现在我的 PR 看起来不再那么杂乱！所有信息仍然存在，但读者可以快速浏览并获取经过人类筛选的关键信息，而不会因为多段代理生成的细节而感到视觉疲劳。

我并不总是自己撰写简介——有时代理已经提供了我需要的内容，隐藏在其他大量文本中。我对读者的承诺是，简短的开头段落将代表我的人类判断，说明哪些内容绝对值得他们花时间阅读。

以下是一些我使用这种模式的近期示例，包括我使用的开头段落：

• datasette PR #3052：重新设计行页面为垂直字段列表——“行页面原本以单行表格展示其唯一一行。对于像 GitHub 46 列仓库表这样的宽表，这种展示方式会导致页面左右两侧大量空白区域，滚动距离过远。”（附截图）

• datasette PR #3043：分页栏显示当前页面的行数——“当表格需要跨多页显示时，现在能更明显地显示当前所在位置，并在页面顶部和底部都提供导航功能。”（附截图）

• datasette PR #3042：通过小加载器按需加载 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 端点的增删改查命令——“新增用于管理 extra-openai-models.yaml 文件中记录的命令，这样兼容 OpenAI 的端点可以通过命令行保存，而无需手动编辑 YAML 文件。”——随后附上 --help 输出示例。

#### 记忆技巧

我过去常常记不住标签的顺序——是 <details><summary> 还是 <summary><details> ?

下面这两个技巧帮助了我。

首先，显而易见的是，<summary> 显然是用于总结细节的部分。这就是你点击展开的文本行对应的标签——因此 <details> 元素必须包裹其余所有内容。

更巧妙的技巧是始终将这两个标签称为“details-summary”。

“details-summary” 是两个音节后接三个音节，比“summary-details”的三二组合更顺口。

大声说出“details-summary”几次，你就再也不会忘记标签的顺序了。

（我仍然希望 GitHub 能在他们的 Markdown 编辑器中添加一个按钮来实现这个功能——一方面可以省去我在手机键盘上费力输入的麻烦，另一方面也能让更多 GitHub 用户知道这个功能的存在。）

发布于

2026 年 11 月 9 日凌晨 4:25 · 关注我在

Mastodon

、

Bluesky

Twitter

或

订阅我的电子报

更近的文章

• 我的笔记本电脑上 Qwen 3.8 27B 也能解释模型权重 - 2026 年 11 月 3 日

• 美国人口普查局与“超级智能” - 2026 年 11 月 2 日

• 10 月是 vibe 游戏开发的转折点 - 2026 年 10 月 28 日

• 战斗无人机 - 一款基于音频的多人联机 vibe 风格 RTS 游戏 - 2026 年 10 月 20 日

#primary

这是 Simon Willison 发布于 2026 年 11 月 9 日的文章《通过 <details><summary> 隐藏 PR 描述》。

github

199

html

101

markdown

36

ai

2,311

generative-ai

2,051

llms

2,015

ai-assisted-programming

408

coding-agents

265

上一篇：我的笔记本电脑上 Qwen 3.8 27B 也能解释模型权重

月度简报

以每月 10 美元赞助我，将获得精选的本月最重要的 LLM 发展摘要邮件。

支付我以减少推送！

赞助并订阅

#secondary

#wrapper

• 披露信息

• 附录

• ©

• 2002

• 2003

• 2004

• 2005

• 2006

• 2007

• 2008

• 2009

• 2010

• 2011

• 2012

• 2013

• 2014

• 2015

• 2016

• 2017

• 2018

• 2019

• 2020

• 2021

• 2022

• 2023

• 2024

• 2025

• 2026