iso-24495 是一个 MIT 许可的插件/技能包，旨在让 AI 编程助手（如 Claude Code、OpenAI Codex、Gemini）遵循 ISO 24495 系列简明语言原则（plain language standards）来生成回复和代码。
核心功能
- 约束 AI 的写作风格
- 要求 AI 用更短、更清晰的句子解释问题，减少冗余叙述。
- 实验显示，应用该风格后，代码审查回复的平均字数减少 17%，句子数减少 32%，且关键缺陷（如依赖数组死循环）全部保留，仅省略少数次要观察。
- 插件附带一套“代码规则”（code rules），例如：将公开入口函数放在文件最前面，每个单元只做一件事。
- 在 Claude Opus 5 的测试中，应用代码规则后，所有生成的文件都将 evaluate 入口放在了文件前 22% 的位置（对照组分散在开头或结尾），且所有 90 个实现全部通过 25 项隐藏测试。
- 对 Codex 和 Gemini 的效果不明显（可能因已有内置风格或注释量极少），但 Claude 表现出显著的结构改善。
- 仓库包含完整的测量脚本（TypeScript），可统计字数、句子数、函数数量、入口位置等。
- 作者公开了所有实验数据、提示词、生成的文件和脚本，并修复了多次测量错误（如句子分割器误判），确保结果可核查。
ISO 24495 把 Claude 的废话砍掉 78%！
一个 68 词的开场白，被压缩成 15 个词，关键信息一个没丢。
2026 年 8 月，独立开发者 Gareth Williams 公布了一组实验数据。他在 Claude Opus 5 的工作目录里塞了一个文件，然后发现 AI 写代码之前那些啰里吧嗦的开场白，从 68 个词缩到了 15 个词。代码审查回复的篇幅砍掉了 17%，句子数砍掉了 32%，但该抓的 bug 一个没漏。这件事的反常识之处在于：我们一直以为让 AI“说人话”会牺牲信息量，但实验指向了相反的方向。
用一套写作规则给 AI 戴上镣铐，它跳舞的姿势反而更精准了。
ISO 24495 是国际标准化组织在 2023 年发布的简明语言标准。它给“什么叫说人话”定了四条原则：读者能快速找到需要的信息、能理解内容、能使用内容、有信心内容是对的。Gareth Williams 把这个标准翻译成了一组规则文件，塞进 Claude Code、OpenAI Codex 和 Google Gemini 的工作目录。然后他让这三个 AI 编程助手干了两件事：审查一段有 bug 的 React 代码，以及从头实现一个表达式计算器。
结果跟他预想的完全不一样。
第一刀砍向废话：68 个词变 15 个词
先看最直观的变化。
同一个模型 Claude Opus 5，同一个提示词“实现一个规格说明”。唯一的变量是工作目录里有没有那个规则文件。
没加规则的那次，AI 的开场白写了 68 个词，分两句话。第二句话独占 57 个词。加了规则的那次，开场白只有 15 个词，一句话说完。
这不是特例。Williams 跑了三组对照实验，统计了 AI 在代码审查回复里写的 prose（也就是代码块之外的所有文字）。加了规则之后，回复的平均字数降了 17%，句子数降了 32%。两组数据的字数范围完全不重叠——也就是说，最短的“有规则回复”也比最长的“无规则回复”要短。
但真正有意思的在后头。
Williams 给 AI 看了一段 React 组件，里面藏着一个经典 bug：一个 options 对象在每次渲染时都被重新创建，然后被塞进 useEffect 的依赖数组里，导致 effect 无限循环触发。六次运行——三次有规则、三次没规则——全部抓到了这个循环 bug，也全部发现了缺少 cleanup 函数的问题。甚至还有一个额外的 bug——未编码的 query string——六次也都标记了。
核心缺陷一个没丢。
丢了什么？短回复比长回复少了四条次要观察。把 bug 的排序方式也改了。长回复里那些“顺便一提”的东西被剪掉了，剩下的全是真正该修的问题。
这就是简明语言标准对 AI 做的第一件事：把废话砍掉，把关键信息往前推。
代码结构纹丝不动：说明文规则不碰代码块
第二组实验更有意思。
Williams 让 AI 根据一份书面规格说明实现一个表达式计算器。支持运算符优先级、右结合的 ^、一元负号、括号，以及能报出错误字符位置的错误处理。每个实验臂跑十次，因为之前的三次试跑已经误导了他两次。
加了 prose 风格规则之后，代码本身几乎没变。
命名单元（函数、箭头常量、类方法）的中位数从 11.5 变成了 12。最长函数的行数从 27 行变成了 21 行。文件总行数从 161.5 行变成了 154 行。三个臂里各有三个文件用了相同的 wrapper 结构。所有九十次运行全部通过了 25 项隐藏测试。
唯一显著变化的是注释行数，从 16 行涨到了 26.5 行。
Williams 自己总结了一句话，说得特别直白：
> 如果你的抱怨是模型写出的解释又臭又长，这个工具有用。如果你的抱怨是它写出的代码没法看，那这个工具不是给你用的。
技能文件明确豁免了代码块。所以规则只管 AI 嘴巴怎么说话，不管它手怎么写字。
但 Williams 没打算停在这里。
再加 19 行代码规则：入口函数从第 195 行挪到第 7 行
他写了 19 行代码规则，用跟 prose 风格一样的口气。规则说了两件事：把公开入口点放在最前面，给每个单元只安排一件事。
然后重新跑了一遍。
命名单元从 12 个涨到了 15 个。所有实现继续全部通过 25 项测试。wrapper 结构（把所有东西塞进一个 evaluate 函数里）从 10 个文件里有 3 个，降到了 10 个里有 1 个。
但真正让人瞪大眼睛的，是一个 Williams 事先压根没打算测量的指标。
公开函数在文件里排第几？
没加任何规则的时候，10 个文件里 5 个把 evaluate 放在最前面，5 个把它放在最后面——在一百多行辅助函数后面才露面。加了 prose 风格之后，还是 5 个在前、4 个在后、1 个卡中间。
加了代码规则之后，10 个文件全部把 evaluate 放在了文件的前 22% 以内。
最极端的一个对比：某个对照组的 evaluate 出现在 197 行文件的第 195 行。加了代码规则之后，某个文件的 evaluate 出现在第 7 行。
这就是“把结果放在最前面”这条最古老的简明语言原则，在代码层面的投影。Williams 承认自己没预测到这个结果——正因为没预测到，他才格外警惕。十次运行不足以支撑显著性检验，这个指标也不是预先注册的。它只能算一个分离得特别干净的假说，而不是一个已经验证的结论。
诚实这件事，比字数重要得多
回到开场白的对比。
没加规则的那版回复，在第四颗子弹点里埋了一句话：
> 我没有运行过这些用例；目录里没有测试工具，而且你只要求输出结果，所以上述行为是基于代码推理的，不是实测的。
加了规则的那版，直接用一个加粗的章节标题把它顶到最前面：
> 验证仅靠手工。 我手工追踪了全部五个错误示例，加上 2^3^2、-2^2、.5 和 10. 对照代码——我没有编译或执行它，因为你让我不要写文件。运行 tsc 和测试文件是仍然待做的检查。
两种说法都诚实。但一种让你在第四颗子弹点里翻半天才找到 caveat。另一种直接塞到你手里，还告诉你“还有一件事没做完”。
对于任何需要审查 AI 输出的人类来说，这个习惯比省了多少字数重要得多。
Claude 听话，Codex 和 Gemini 不听话
Williams 把同样的三组实验（无规则、仅 prose 风格、prose 加代码规则）跑在了 OpenAI Codex 和 Google Gemini 3.7 Flash 上。九十次实现，全部通过了全部 25 项测试。
但入口函数的位置分布完全不同。
Codex：无规则臂 10 个文件里 6 个把入口放在最开头、4 个放在最末尾。prose 风格臂 7 个放开头、3 个放末尾。prose 加代码规则臂 5 个放开头、5 个放末尾。加了代码规则之后，放在末尾的文件反而变多了。
Gemini：分布散落在整个区间里，开头、中间、末尾都有。加了代码规则之后，放在末尾的文件也从 1 个变成了 4 个。
Claude 是唯一一个在加了代码规则之后，所有文件都把入口放在前 22% 的。
Williams 给出了两个解释。第一，Codex 的系统提示里本来就有一句“你更倾向使用简明语言而非术语”。所以它的“无规则”臂从来就不是真正的无规则，对照组被污染了。第二，Gemini 几乎不写注释——三十个文件里一共 18 行注释，中位数是 0。它每个文件里最长函数的行数中位数是 64.5 行，而 Claude 是 21 行。
作者自己搞砸了三次
这篇文章最诚实的部分，是作者把自己犯的错全抖了出来。
第一次错：他最初报道句子数减少了 52%。后来发现句子分割器把加粗里的句号当成了普通标点——Lead in. Next sentence. 被当成了一整句。修好之后，真实的降幅是 32%。
第二次错：他最早的一次尝试什么效果都没发现。后来才意识到自己的全局配置已经让每个会话都按简明语言的方式写了——对照组从一开始就不是对照组。
第三次错：他第一版文章里引用的字数和句子数，没有任何脚本能复现出来。一个 adversarial review 从保存的回复里重新数了一遍，怎么数都对不上。
测量 TypeScript 代码的脚本也被修复了三次。一开始按行匹配，看不见箭头函数体是表达式的写法、看不见参数换行的声明、看不见带类型参数的方法。三轮 review 各发现一种，每次修复之后又暴露出下一种。现在它读的是语法树。
连 counting 脚本的版本都 pin 死了——用内容哈希锁住 parser，用哈希锁住被分析的六条回复。脚本没法给自己担保，所以作者还把发布版本的 SHA-256 贴了出来。
整套实验数据、所有回复、全部实现、指令文件和脚本，都公开在 GitHub 上。标签 measurements-2026-08-22g。任何人都可以克隆下来，跑一遍，验证他说的每一个数字。
一个“不支持”的结论和一个没回答的问题
Williams 在文章最后划了一条非常清楚的线。
支持的结论：简明语言风格让代码审查回复缩短了大约六分之一，同时抓住了同样的 headline bugs。在 Claude 上，代码规则臂比另外两个臂有更多的命名单元和更靠前的入口点。全部 90 个实现全部通过 25 项测试。
不支持的结论：任何“这能普遍提升代码质量”的说法。这只是单一模型家族、单一任务、单一语言的结果。入口位置这个指标是看了数据之后才发现的，不是事先预测的。它是一个分离得很干净的假说，不是结论。要确认它，需要事先固定好这个指标、重新跑一遍。
还有一个没回答的问题：为什么 Codex 和 Gemini 加了代码规则之后，放在文件末尾的 run 反而变多了？Williams 说这是“关联而非因果”，是“下一个该测的东西”。因为它指向了跟规则目标相反的方向。
同一个规则文件，Claude 往左走，Codex 往右走，Gemini 到处走。三个模型读同一份指令，给出了三种不同的响应模式。
如果“让 AI 说人话”这件事本身都因模型而异，那“让 AI 写好代码”的规则又该怎么写？
GitHub 上那个 MIT 许可的仓库里，还躺着十四处被修复的引擎缺陷。第八轮 adversarial review 刚走完。那个在 197 行文件里出现在第 195 行的 evaluate 函数，和那个出现在第 7 行的 evaluate 函数，都在等着下一个人去复现。