深呼吸

朋友，上周我又做了不少事情，而且收获良多，忍不住跟你分享！

Awesome-Jev 星标超过 1000 个了！

自上周 Jev 发布之后，我跟进了一个 Awesome-Jev 的 Github 仓库，很受欢迎。这大概是我历史上增速最快的 Github 仓库，仅仅一周就获得了破千的星标，每天都有十多个主动提交，可以说非常热闹了。

当然，我搞这个仓库，主要还是方便自己研究。得益于之前 Awesome-Autoresearch 的经验和模板，起这个仓库很快，我并不需要重复讨论应当如何搜集，和整理的问题。

从 Awesome-Jev 收录项目的方向变化，可以看到当下信息迭代的速度有多快——我说的这个快，并非那种信息流滚动的快。而是，议题翻新的快。

这一点需要结合传播学的知识来解释一下，假设每一个项目背后都存在着对某一种事物所探索的议题（毕竟产品和项目，都是对应解决问题而生），那么从 Awesome-Jev 收录的项目来看，几乎半天时间，就会冒出新的议题方向，然后出现一堆的项目开始探索这个方向，然后再过半天时间，如此循环。

我观察 Jev 的议题变化，将它的议题循环总结为：

探索与辨认 - 应用与验证 - 尝试复现 - 理论深化 - 替代联想 - 话题消散

• 探索与辨认：探索 Jev 是什么，辨认它的具体性质、形状，它的具体性能如何，它的能力边界在哪里
• 应用与验证：尝试将 Jev 应用到更多实际的场景，该阶段大多是实验性质的，并非产生实际项目，主要是用来验证 Jev 的能力边界
• 尝试复现：尝试复刻 Jev
• 理论深化：开始有大儒为 Jev 归类为某一种模型，并开始系统总结它的能力，应用场景，对未来 AI 应用范式的影响，等等
• 替代联想：人们开始关注替代品，并关注替代品的实际应用情况
• 话题消散：由于前期积累了很多很多议题，此时，每个人都会在自己关注的议题空间里继续活动，所以该阶段随着议题分化了人们的注意力，该话题的势能开始消散

我觉得 Jev 作为一个热点，现在已经过了最热的阶段了——接下来就是凭各自的本事，将 Jev 与现实的项目深度整合了。

关于 System-One 和 Jev 的思考

要深入理解 Jev，不难，因为它本来就不难，TypeSafeai 已经把谜底放在谜面上了——Jev 是一个针对「系统一」的模型。

这个概念来自非常有名的书《思考，快与慢》，作者是诺贝尔经济学奖得主丹尼尔·卡尼曼（Daniel Kahneman）。这本书详细地向大家解释了人脑的工作机制，它存在 2 个系统，一个是「系统一」，它的特点是快速判断，自动化，且不费力，另一个是「系统二」，它的特点是缓慢，主动推理，费力。

按照这个分类，当前世界主流发展的都是「系统二」的大模型，Fable 和 Astra 的推理能力空前强大，越来越有活人感，而弊端也和「系统二」一样，更慢，消耗更加巨大。问题是，并非所有任务都用上这么强大的思考能力，我最近想整理某个项目的文档，我只是用 Astra 的 Low 这一档，只一会儿就烧了 20% 的额度。

我可以抱怨 OpenAI 不干人事，又来削用户额度了之类的，这只是事情的第一层。第二层则是，即便 OpenAI 融了这么多的钱，它也无法支撑 Astra 的无限量供应，你可以看到为了支撑这个强大的模型本身，OpenAI 本身也支付着巨大的代价——虽然它的商业模型植根于根据 token 的消耗量收费，但我充分怀疑，这种烧越多，收越多的方式是否可持续。因为每一个 token 的产生，都需要消耗电能。与之相比，互联网里的「复制代码即获得收入」，可以「一次开发，多次销售」，才可以认为边际成本几乎为零。所以，Astra 和 Fable 的额度都不经烧——我甚至偏激地认为，这两家都不应该将这么强的模型放进订阅套餐里。

回到用户视角，很多任务不需要全程都由 Astra 或 Fable 来盯着执行，换成弱一点，快一点的模型也未尝不可。只不过现在的 Codex 和 Claude Code 并不提供这种切换，很难让人根据任务自如地切换模型。毕竟，一个项目下来，要执行的任务挺多的，有的任务难，有的任务简单，但它不是按照顺序执行的，而是根据需要产生的。每一次执行都要先输入斜杠命令，跑到切换 model 那里切换，这种操作再简单，频繁且重复了之后，都会让人感到精力巨大的浪费。而 Jev 则将这种「简单任务」的场景，再细分到，仅需要快速分类就够了。

人脑之所以发展出「系统一」和「系统二」两套机制，很大程度上也是因为节能。而且，在危险的自然界，完全依靠「系统二」显然是不够的，通过「系统一」快速辨别，快速判断是这套机制的本身基础。而且，我觉得「系统一」和「系统二」未必是孤立的，可能很多信息第一时间先经过「系统一」才到达「系统二」。所以 TypeSafeai 的创始人 Diogo Almeida写了一篇将 Jev 和 Agent 结合使用的指南。

很多人觉得 Jev 没啥难的，所以评价中不自觉地流露出一种贬低——我也觉得 Jev 不难，因为实现这个模型本身不难，但难的是思路转换。毫不讳言，Jev 会直接引发行业一次范式的切换，打破过去的路径依赖。就这件事而言，TypeSafeai 本身就值得 2 亿美元的天使融资，因为它证明了人才的价值。

对于接下来 Jev 以及 Jev 衍生品的发展，我觉得很快就会进入「微调」阶段。训练多一个 Jev 并不难，我看到有人一天之后，就拿了 Qwen-3.5-1B 的模型就训练了一个类似东西来。但这不重要，因为想要令 Jev 真正发挥价值，它必须经过「微调」，做个比方，它就是个非常擅长填选择题的「做题家」。但成为那个「做题家」的前提是，它必须经历过浩瀚的题海，甚至有一个详细的错题集。

在这件事上，数据依然是最宝贵的资产。

重构自己的笔记工具

Supertag 原名 org-supertag，是我独立开发的笔记工具。最近一段时间，我一直在重构它。这一次重构的目标是，精简模块数量，回归工具本质；目的是回归流畅的笔记体验。

一直以来 org-supertag 拥有数量众多的模块，功能全面强大，它也野心勃勃，「要将现代笔记的体验迁移到 org-mode」。直到有一天，我发现一件可怕的事实，我不愿意用 org-supertag 写笔记。所以，我停了下来，回顾自己使用 org-supertag 的经历，有觉得很舒服的部分，但也存在很多摩擦力很大的部分——后者的比重过大，导致我想用 org-supertag 写笔记的时候，心头一阵烦躁。

Org-supertag 其中一个设计的初衷，是降低笔记的整理成本，用户不用管笔记记录的位置，只需要通过特定的视图就可以直接找到对应的记录，这一点实现得不错。但 Fields 的填写与组织，还有 Table View， Kanban View 等等夹在一起，让笔记的整体流程充满摩擦力。尤其是 Fields 的存在，令笔记的流程多了一个复杂的维度——笔记不是数据库，如果真的要实现这一点，我推荐大家使用 Recutils。它是 GNU 标准工具之一，而且结构非常简单，理念是「Text as Database」，它可以和 org-mode 完美结合。

据此，我认为现代笔记工具已经走向一个弊端，作为个人的笔记工具，它没有足够的盈利点，而总要膨胀到团队协作，或者其他方面去；而功能规模的膨胀，固然令工具变得强大，但也让用户记录笔记的时候想东想西的，心智负担大，记录笔记不流畅。让我想起 Evernote 从繁荣走向衰败的历程。

我的结论是，我想要的是这样的笔记工具：在记录时不打断我思路，在整理时不要让我费神，在回顾时不复杂。幸运的是，org-supertag 尽管变得膨胀，但其基本架构完全可以做到以上 3 点，尤其数据流部分，我在这方面花费的心思最多，尽管现在经历了多次重构，但数据流并没有发生多大的变化，称得上 rubust 和 solid 了。

我最后把自己的需求缩减成了三句话：

• 记录时，不要打断我的思路。
• 整理时，不要让我费神。
• 回顾时，不要太复杂。

我现在通常先把内容写下来，之后再决定如何整理它。好处是，写信比以往更方便了，我通常只需要从自己的日记里寻找到之前的材料，直接复制过来就行

这一次重构给我带来的教训是，「一切都要从心出发」，用心感受真正需要的功能是什么。只有自己能够一直使用下去的功能，才是值得推荐给他人使用的。

SPEC-AGENTS 封存之后的交流，以及「软件工程设计」

在上一封信里，我提到封存 SPEC-AGENTS 这个项目后，有网友 James 来信希望跟我继续讨论，我回信之后，没过多久，他又回了一封信息密度极大的邮件过来，里面有非常深刻的思想和洞察，迫使我继续深入思索这个话题——益友就是如此，能够促使你进步。

James 在邮件中提到了他设计 SPEC 开发方法的出发点，还有他那一套方法和 SPEC-AGENTS 的异同，他提到：

我觉得我们的两个抽象其实很值得并排比较一下，因为出发点极其接近，但最后似乎分别走向了：

你：如何让模型拥有一个足够好的、可持续演化的世界模型

我：如何限制模型只能在已经获得人类语义授权的世界里行动

而 Jev 又从另一个方向在追问：模型如何暴露并结构化自己的判断。

我怀疑这几条路最后还会在更高一层重新汇合。

虽然我还没能拿起笔回信，但我现在已经想到了这个最终一层的抽象应该什么——「软件工程设计」。把 SPEC 开发流视为一个软件工程，然后以软件工程的角度，重点使用抽象、复用、组合，三板斧来解决开发流过程中遇到的问题。

这个想法来自与群友 geekinney 的讨论。他在群里晒了两张使用 Pi 之后，自己编写的技能和插件，数量非常庞大，光技能将近 20 个，插件也有 10 个。我记得，才两三周前，他说要开始尝试 Pi。如此短的时间内，如此大量的成果，生产力非常惊人。

在群里，他也提出关于技能的有趣的观点：「优秀的技能，是要写出来之后，连本地小模型也能够准确地执行。」

我觉得，这个标准提得很好。我们在网络上，经常看到大 V 晒技能，效果很不错，常常弄得心痒痒的，但自己尝试又未必如此，很大的原因是大 V 跑这个技能时的客观条件，与别人有很大的不同。这意味着，这些技能基本上是一时的产物，缺乏持久性，泛用性。尽管大 V 自己用起来的效果很炫，但难以成为一个大家都可用的、优秀的技能。

总之，不要问为什么大 V 行，而自己不行，也千万不要把这事儿的原因归于自身，就好像做实验，完全两种的实验条件，得到的结果自然是不同的，这里所应当。如果按照 geekkinney 所说的，一个优秀的技能，应该如何？

geekinney 在他自己的 Telegram Channel 里系统总结了自己的想法：

「我觉得 skill 本身就是一种软件，需要按照软件的工程规范来组织。它和软件的区别在于：软件完全就是代码，要求所有的功能提前开发好，然后精确执行。而 skill 更加的灵活，它结合了自然语言和程序；程序负责具体的功能，自然语言负责定义规则，规定用什么程序来做。这样的组合放大了传统程序的能力，因为自然语言可以拓展程序的能力边界，通过最小功能的组合和复用来实现。这就是 unix shell 的哲学。

技能的内部是如此组织的，所有的功能都要最小的操作原语，常用的流程可以固化下来哪些组合，不常用的就让模型自己推理如何组合。技能与技能之间也是如此组织的，一个更复杂功能的技能可以由更小的技能组合来完成，无需重复造轮子。」

从以上总结可以看出，关键词是两个：抽象组合，复用。这也是软件工程的基本原则。

我与 geekinney 之前交换过「软件工程」的看法，和他一样，我认为在 Vibe Coding 盛行的今天，「软件工程」的素养变得更加必要了。看他对技能的开发，能够明显感受到，将「软件工程」的思维运用到其它领域的确是一个非常值得尝试的方向。

现在，我要面对一个心情问题，如果有一个朋友比你聪明，能力比你强，还比你帅，你是羡慕嫉妒恨呢，还是羡慕嫉妒恨呢？

朋友，今天的信就到这里，祝你中秋快乐，生活愉快！