Attention Span

一组改变编码 agent 汇报方式的 markdown 文件。旗舰是 Attention-kind：结论放在第一行，每个要点单独成段并以箭头开头，重要词组加粗——只读加粗也能拿到完整答案；生僻术语只解释一次，五个词。Spartan 是同一套形状但去掉温度；Rundown 以 TL;DR 开头，用清单展示状态。三个文件之外还有：一套把「干的活」和「说的话」分开测的 benchmark，一条在插件清单、版本文件、样式文件内的标记与 git tag 不一致时就让发布失败的流水线，以及四个由样式源文件生成的用户触发技能，因此不会与正文措辞走偏。它以 Claude Code 插件安装，也能作为技能在 Claude 应用里使用；样式正文是纯 markdown，去掉 frontmatter 后可以放进别的 agent 的规则文件。

谁做的这个仓库几乎是作者一个人的活：66 次提交里 61 次出自作者本人，另外五次来自四个账号，而 CHANGELOG 给这四个账号都记了一笔已落地的改动——多 agent 安装、西班牙语 README、样式切换命令，以及一条关于简洁的规则。19 次提交带共同作者尾注，其中 18 条写的是 Claude Opus 4.8（一百万 token 上下文），一条写的是 Opus 5。

1. 01

   一个月里，一个 markdown 文件长成了插件

   仓库建于 2026-08-04，共 66 次提交：8 月 60 次，9 月的前六天 6 次。这一个月里发了七个 release，起初几乎每隔几天一个——0.2 在 2026-08-05，0.3 次日，0.4 在 2026-08-10，0.5 在 2026-08-11，0.6 在 2026-08-15，0.7 在 2026-08-21，0.8 在 2026-09-06。列表里最早的一个是 0.2，没有 0.1。tag 与 release 完全对应，因为发布流水线会在版本文件、每个样式文件里的版本标记与 tag 不一致时直接让发布失败；版本号规则是刻意扁平的，CHANGELOG 写明只有最右一位会进位。周围还有 1,150 个星、37 个 fork 和两个未关闭的 issue；提交过的账号有五个——作者 61 次，另外四个账号各一到两次。19 次提交带共同作者尾注，其中 18 条写的是 Claude Opus 4.8（一百万 token 上下文）。

2. 02

   改写之后到底长什么样

   README 用两组并排的回答来立论。同一个问题——新的社交应用该用 PostgreSQL 还是 MongoDB——未加样式的回答有 430 词，先铺一段背景才给出结论；Attention-kind 的回答 94 词，五个箭头开头的要点，第一条就是结论。Spartan 对「本周三件事、只能做两件、砍哪件」做同样的事：310 词压到 168 词；Rundown 则把一段招聘进展变成一个 TL;DR、四行清单、一条 blocker 和四个编号的下一步。这些文件要求的比「be brief」更窄：先说结论、说全答案所需的最少内容、只有在删掉会让读者付出代价时才展开、生僻术语只解释一次、任何要点不重复。CHANGELOG 记下的是逐版收窄而不是一次发明。0.2 把「回答」和「交付物」分开——解释、判断、建议要精炼，而文档、方案、规格可以按工作量展开——并写明精简只削减回复，绝不削减内部推理。0.5 加入交付物纯净：要一段提交信息或一封邮件，就只给这些，不带任何外包装；同版还加了「压缩时绝不删掉警告」和「仅凭加粗与 TL;DR 也必须能拿到完整答案」两条。

3. 03

   有人把它拆开之后，benchmark 被重做了一遍

   第一版 benchmark 上线五天后，有读者开 issue 质疑：它测的是「是否服从」，不是质量——生成答案的模型同时也是打分者，样本是 12 个问题乘两轮，而真正变化的两个指标（「answer-first」从 63% 到 96%，「skimmability」从 2.7 到 4.8）不过是把样式文件里的指令改写成评分表，分数当然会涨。作者在回复里认了这一点，说 benchmark 本可以做得更好，并重建了它。2026-08-11 那一版是按「经得起攻击」来设计的：活干得对不对由隐藏测试判定，通过与否就是事实；答案在密闭环境里生成，样式关闭与开启两组之间只差一个样式文件；而头条数字完全不使用模型当裁判。12 个编码任务上两组通过数相同，36 次里各 35 次；24 个问题上带样式的回答平均短 43%，话多的问题短 50% 到 71%，而本来就短的两行回答只短了 7%——这正是要点，省下的量与「本来会多啰嗦多少」成正比。它不用阅读难度分（文档指出那类分数只看句长），而是数「读到第一个重点之前要读多少词」：约 6 词对约 40 词，答案出现在第一行的比例 75% 对 3%。文档末尾自己列了局限，其中一条是工作量等价只在有隐藏测试的任务上成立。

4. 04

   每一条规则背后都站着一个用户

   这些规则大多来自每天在用它们的人。issue 6 报告说，一个必须等待回答的问题被埋在七段中的第四段，而它决定的是后面一个有副作用、不可逆的步骤；0.7 把修法落成一条位置规则——你必须等答复才能继续的问题放在最后一块，后面不再有任何内容，若回复还有其他内容则第一行就带上它——同一版还加了位置检查器和六个副作用场景：真实 Claude 六次全部把问题放在最后，而故意埋掉问题的对照组六次全部失败。issue 9 指出清单把「未知」并进了「未开始」，0.8 给了它第四个状态；issue 8 要求把「Your move」的选项编号，也在 0.8 落地。一位贡献者的 pull request 标题是「brevity governs the reply, not the work」，来自一次在缓慢数据管道上的会话：模型不断提前收手、想把还没验证的说法写出去，因为它把「写出来」当成了终点。issue 5 提出把样式做成技能以便在 Claude 应用里用，0.8 一并交付，并由样式文件生成。社区里还有两条线没合上：一条要求单个事实的回答直接说、不要套上 TL;DR 加下一步的整套架子，开在最后推送的当天；另一条是四份新 README 翻译的 pull request。

5. 05

   分发方式，以及它拒绝声称的东西

   真正交付的东西是一个 markdown 文件，所以分发问题基本就是「这个文件落到哪里」。最省事的路子是 Claude Code 插件，一步带来三个样式、切换命令和四个技能；手动路子是把一个文件 curl 进 output-styles 目录，再在 settings 里写明。插件清单与样式同步升版，而发布流水线在清单、版本文件、文件内标记与 tag 不一致时拒绝发布。取舍都写在明面上：样式正文约 650 个 token 的输入，每个会话加载一次、首次请求后被缓存，README 认为这点输入成本在几次回复内就被实测的输出节省盖过。样式只作用于主对话，因为子 agent 跑自己的提示词；样式文件保留编码指令不动，而隐藏测试那一组对照正是为了验证这一点。四个技能是用户触发型的，不调用就不占被动上下文，而且由脚本从样式源文件生成，两边不会走偏。README 也主动否掉了一个可能的卖点：如果目标真是省 token，更大的开销在 agent 干的活，而不是它怎么说话，作者另外两个工具正是冲这个去的。那条讨论串里有一点没有被记录覆盖：对一个写在 markdown 里的提示词使用 AGPL-3.0，以及作者最终怎么处理，材料未覆盖。