想让 AI 写清楚,别写"简洁一点":从一条 issue 里抄来的禁止清单规则
今天在给自己项目的 CLAUDE.md 补一段写作规则,顺手去 claudecode 的仓库里翻翻别人都是怎么写的,翻到 issue 77136。这条是 7 月 13 号 pbower 开的,到今天还挂着 area:model 和 bug 两个标签,没有 assignee,也没有关联的分支或者 PR。

@abanana
把自己踩过的坑整理成一篇能复现的笔记,写给三个月前的自己看。
今天在给自己项目的 CLAUDE.md 补一段写作规则,顺手去 claudecode 的仓库里翻翻别人都是怎么写的,翻到 issue 77136。这条是 7 月 13 号 pbower 开的,到今天还挂着 area:model 和 bug 两个标签,没有 assignee,也没有关联的分支或者 PR。

前几天翻到 ravynOS,起因很朴素:手边有台老 MacBook,想找个轻一点的非 macOS 系统装上去折腾。官网首页看下来第一感觉是做得挺好看,第二感觉是它想做的事真多——兼容 macOS 应用、全局菜单、统一 Command 键、拖放安装、原生 Cocoa API,一屏写满。
前几天在 dev.to 上翻到 James Anderson 的一篇文章,列了 AI 应用过度工程的 7 个迹象,每条配了替代做法,最后还给了一份预防手册。评论区三十来条,基本都在讲自己踩过的坑。 七条我不打算挨个复述,那种清单你直接去看原文更快。

今天这篇笔记有点跨界,记的不是某个配置项,而是一篇上周刚挂到 arXiv 的论文(编号 2608.28281,名字叫 LoopArena)。我平时不太追新基准,一年到头挂出来的基准比真正能用上的多得多,但这篇让我停下来读完了,原因很具体:它测的那段东西,正好是我自己脚本里最没把握的一段——loop 的控制权。
前几天在 arXiv 上刷到一篇讲编程智能体作弊的论文,Francesca Gomez 写的,8 月 29 号首次提交,9 月 2 号刚出了修订版。顺手把里面的数据拆开看看,越拆越觉得说的是我自己的一个毛病:我那份 CLAUDE.md 里防作弊的部分,从头到尾全是禁令,通篇「不许」,活像一份宿舍管理条例。

今天在收拾一串 fixup 提交的时候踩了个坑,顺手记一下。场景是用 git rebase i autosquash 合并补丁提交,Git 打印了 Successfully rebased and updated,我以为完事了,回头一看 log,那条 fixup 提交还完整地躺在历史里。

今天在收尾一个小功能的时候,给上一个 commit 补了两个漏掉的文件,push 直接被拒了。操作就是 git commit amend,报错是老熟人 nonfastforward。

今天早上刷到 ClaudeDevs 在 X 上的公告:9 月 14 日起,Claude Code 的周用量额度永久上调 25%,Pro、Max、Team 和按席位计费的企业版全部覆盖。第一眼看着是好事,到我看的时候那条帖子已经两百多万阅读了。但我把数字拆开算了一遍,结论是:对我接下来几周的排期来说,这不是涨,是降。

昨晚周五,本来在改一个 CI 脚本,摸鱼的间隙刷到 OpenAI 的声明:终止和 Cursor 的合作,而且在合同允许的最晚日期之前,不会再提供任何未来的新模型。今天早上几个群已经在吵“影响大不大”,吵到后面基本变成站队了。

上个月月初 dev.to 上有一篇长文,一口气给了 18 条关于 AI 市场走向的预测,时间线上被转了好几次。说实话,宏观的那部分我一条都不打算在这里复述——超级应用谁会赢、数据中心该投多少钱,这些我既验证不了,复述一遍也只是把别人的判断搬进我的笔记,三个月后自己都分不清哪句是谁说的。

前几天刷到陶哲轩 8 月 18 日的博客,说 Palomar 登记处正式开始接受 Lean 验证数学成果的提交了。这个东西由 Lean FRO 和 ICARM 孵化,定位类似一个面向 Lean 证明的预印本服务器,登记的是外部 GitHub 仓库的特定提交快照,不替你保管代码。

前几天翻 arXiv,看到一篇 8 月 11 号挂出来的论文(编号 2608.13607),讲模型版本更新之后怎么预测「单样本回归」。这个问题我自己踩过:升级模型之后跑一遍评测集,整体分数涨了,皆大欢喜,结果仔细一对答案,发现有几个之前答对的样本这次答错了。当时我的处理方式是耸耸肩——整体涨了嘛,正常波动。

今天在 dev.to 上刷到一篇七月下旬的文章,讲的是给 Claude Code 加一个有状态的图像编辑能力,项目叫 nb2liteskillclaude。

今天在读一篇讲 COSP 的文章,顺手记一下。COSP 是 Wan 和 Google 的同事提出来的一套方法,核心思路一句话能讲完:让 LLM 从自己采样出来的答案里挑出几个例子,当作 incontext examples 嵌回 prompt 里,再跑一遍,最后对多条推理路径做 majority vote。

今天在做的事有点特别:前几天刷到一篇 Joel Abenhaim 写的论文,讲的是在无人工代码审查、无预定义测试预言的条件下,让 AI 编码代理靠“规范优先”协议完成了一次大规模架构重构。对象是一个 3,648 个文件、717,725 行代码的生产环境 TypeScript 应用。
今天跑 DiagramMMU 被一个结果卡住了,顺手记一下。这个基准 8 月中旬挂上 arXiv,3,700 张人工精选的科学图表,18,300 道人工验证过的题,六个学科。我本来只是想测一下手头模型读图的能力,结果发现真正有意思的不在问答那一档,而在两个图表到代码的任务上。
前几天在 arXiv 上刷到一篇 8 月 13 日提交的论文,RAGSieve,讲的是 RAG 里的知识投毒检测。让我停下来读第二遍的原因只有一个:它不依赖标记好的毒化样本,也不需要一份可信的对照语料,参考基准是从被检测系统自己身上构建出来的。
前几天翻到 8 月 13 号挂上 arXiv 的那篇 Vero,讲的是用 benchmark 评估 agent 在仓库级别同时写实现和写证明的能力。43 个多模块 Lean 4 仓库实例,带预定好的 API 接口、人工整理的 spec 和参考实现,支持 proofonly 和 codeandproof 两种模式。

前几天翻 arXiv 翻到一篇 5 页的短文,James Adam 一个人署名,8 月 13 日挂上去的,讲给编码 agent 做项目记忆。说实话一开始没抱期待,这个方向的论文一年几十篇,大部分是把 RAG 换个说法再讲一遍。

前几天读到一篇 8 月 14 号挂上 arXiv 的论文(编号 2608.13884,24 页),做的是一件挺费功夫的事:把 vLLM 和 SGLang 这两个仓库从创建到 2026 年 6 月的所有已合并 PR 全部拉出来做纵向分析。
