Codex 里那排 fix bug，过一周就没人认得

Hamel Husain 发了一条很短的推：如果你在 Codex 里堆了很多任务，让 Codex 按 Shreya Shankar 的这篇文章重命名整个项目里的任务。他的评价是 quick quality life upgrade。翻成日常话：花几分钟整理任务名，后面找东西能少受很多罪。

痛点很具体。任务列表一长，满屏都是 fix failing test、Find issues in tagged slack thread、update config。第一天你还记得上下文，一周后只记得自己好像改过什么。Hamel 在回复里也说，他以前没想过要重命名侧栏任务，读完才意识到这事有价值。

Shreya 的文章叫 Five Principles for Generating Readable AI Text in Bulk，原始链接在 fsdatalab 博客。她讨论的是批量 AI 生成文本，比如 Claude Code 和 Codex 侧栏里的会话标题、iPhone 通知摘要、临时 dashboard。问题不在单句是否通顺，而在几十条文本放在一起时，人很难快速扫读。原文里配了五组前后对比图，值得点开看。

五条原则可以压缩成五句话。

按人读句子的顺序写。英语读者习惯先找主语、动词、宾语。列表里如果主语都一样，就省略主语，用动词开头，时态统一。Claude 侧栏原来混着名词、动名词、祈使句，改成 Measuring vLLM performance 这种连续式动词开头，扫起来顺很多。
把最重要的词放最前。人扫网页是 F 型，列表常常只看前两个词。订单邮件把 Shipped 放前面，比每封都以 Your order 开头有用。
结构和词汇统一。Notion AI 总结 GitHub issue 时，有的写 The issue reports that，有的写 Pressing Ctrl+C，还把 issue 和 page 混着用。读者得反复确认这是不是同一个东西。Perplexity Discover 的标题就统一得多。
变化只用来表达有意义的差异。Duolingo 评论主题卡里，只有 bug 卡写了版本号 7.146.0，读者会以为版本号和 bug 有关。统一模板后，差异才可解释。
动词的情感要对齐面板目的。投诉面板就用 complain，赞美面板就用 love。读者扫 dashboard 时注意力很低，动词得先告诉他这是好消息还是坏消息。

这套东西直接能拿来改 Codex 任务名。让 Codex 重命名时，不要只说取个更好的名字。给它规则：每条以动词开头，时态一致；把能区分任务的词放前面；带上仓库、PR 号或分支；同类任务用同一套结构。Hamel 推文下面有人补充，任务名里放 PR 号或分支，一周后你搜的就是这个。也有人说把命名规则写进 AGENTS.md，让新任务创建时就按规则命名，别等列表烂掉再批量救火。还有一条提醒值得记：任务做到一半会漂移，结束时最好再让 agent 改一次名。

任务名看起来是小东西，实际是搜索索引。一列 untitled task 或 fix bug，等于把上下文丢了。重命名不解决代码问题，但它让你还能找回当时的判断。原文的五个原则和对比图都在这里：https://fsdatalab.github.io/blog/agent-text-at-scale/ 。Hamel 的原推在这里：https://x.com/HamelHusain/status/2115918321141109029 。如果要直接开工，可以把这句话丢给 Codex：读这篇文章，按里面的五条原则重命名当前项目里的所有任务，保留仓库、PR 号和分支信息，同类任务使用同一结构。