动起来，否则你就要费劲思考了

一段时间没写信了，你还好吗？再次提起笔来，真是让人开心，每一次写信都是你我的一次重逢，为了这份不断的缘分，我也要提笔写下去。

X 的关注量突破 5000

最近，我在 X 上的粉丝突破了 5000 人，不算多，也不算少。但现在 X 上的内容更新，基本上是我指挥 Agent 来处理的，我每天除了对着一张选题表选择今天写作的内容，或者想到什么改善点之外，其它的活儿都是 Agent 一手包圆。尽管涨粉的速度在最近 1 个月变得非常迟缓，但我大概摸到了令粉丝量增长的路径——你火啥就发啥。

打字速度最高纪录达到 75wpm

之前我提到自己在通过 Keybr.com 这个网站练习打字，现在最高的记录是 75wpm，我对该速度已经感到满意，就没有继续再练习。在日常打字中，我一直使用的是 RIME + 魔然输入法这个方案，我将自己输出的习惯调整到以字词为主，打字的速度就快了许多，而且准确率还不错。

Keybr.com 的算法设计很不错，它会统计你打的哪一个英文字母容易输错，那么在下一个安排的练习环节里，就会增加多几个包含了该字母的单词。在长时间练习之后，手对键盘渐渐熟悉，开始知道自己的手指正在放在哪个位置。这时候打字的速度才开始提了上来。朋友，尽管现在大家都爱用语音输入了，甚至写啥都让 AI 来了，但我觉得，手动输出还是很有必要的，只有在自己亲自动手的时候，我们的大脑才会真正进入思考的空间。

尤其是打字的准确率提高了之后，在电脑上输出不再是那么痛苦的事情。反正，根据我自己的估计，在练习之前，我可能打一句话就会有一般时间浪费在纠正错字，修改语序等等零散的小事上。所以，练习打字还可以让人在输出时，不容易被小事打断。

封存 SPEC-AGENTS

SPEC-AGENTS 是我之前探索 Vibe Coding 方法论，从而自己设计的 SPEC 驱动的开发框架，在 Github 有 128 个星标，一共有 25 个 Fork。从第一个版本到发展到第四个版本，我在这方面的耕耘，花了不少时间。然而，在最近一个项目的大重构中，我发现把 SPEC-AGENTS 所产生的记录全部删除，直接让 Astra 来处理，之前三四天一直没能处理完的任务，只需要半天就搞定了。

在沮丧之下，我决定把它封存了。在日记里，我写了一点感想：

「在实践当中，发现强模型（Astra，Fable）本身已经具备软件工程方法方面的知识和方法，思维能力和记忆能力相比过去，进步了许多——harness 本身的进步也是有目共睹。

已经不需要一个 SPEC 像一个记事本一样，在旁边让它是不是查看，以防走偏。相反，由于过于注重 SPEC，让强模型不断的回顾历史，上下文塞入太多杂讯，结果往往是强模型浪费更多 token 在思考上，继续往上下文塞进杂讯，循环往复，便会令它的注意力焦点偏移。

基于我对 AI 的理解，我认为原因有以下几点：

反向传播算法是大模型基本的思维特征，意味着之前输出的 token，都会影响下一个 token 的输出。不断地寻找对齐也是大模型基本思维特征——两相叠加，后果就是，模型在杂讯过多，所引发的过度思考的时候，反而令自己的逻辑混乱。

因此，面对能力更强的模型，写 Prompt 或使用 Skill 都不如以往重要，重点应该放在保证它上下文的纯净。这样子强模型才能真正发挥自己在思维能力方面的优势。」

在封存了 SPEC-AGENTS 之后，我还收到一封邮件，对方说也和我一样尝试将抽象语义与开发结合，然后看到了我的项目，当他想留言与我讨论时，才发现我已经把项目封存，因此他来信想与我讨论封存项目的原因，以及在这方面想跟我继续深入讨论。我想了想，给他写了回信，不过我当时忘记了跟他提到越强大的大模型，越不需要过度严格的脚手架：

「如你所说，最大的问题是 Kernel 层的更新与迭代。和你一样，我打算使用类似「本体论」的方式，来约束开发的过程。然后最大的挑战是在一轮长程开发完成之后 Kernel 层所产生的大量漂移。

软件工程的复杂度就在于，计划往往赶不上变化——在开发前的约定并不能完全能够充分预估所有开发的细节，而我们往往也不会完全等待所有细节都确定之后才进入开发；我认为，大部分是产生一个想法，有一个模糊的计划框架之后，想了想大概的结构，觉得没问题了之后，就会着手进入开发阶段。

因此，在 Do 这个阶段，尤其是进入长程任务开发，中间经历了几次对原先计划的修订之后，会不可避免的产生大量语义的漂移。这种漂移如果在简单任务上，还好处理，但面对复杂任务，就会变成一场噩梦。想一想，跑了一轮 /goal 之后，发现产生 50 个漂移点，如果只是纯人工检查，会浪费半天的时间，如果只让 AI 来处理，那肯定对整个方案都不负责任。

这里，我认为 Vibe Coding 就像「潘多拉魔盒」一样，一边诱惑着我们打开盒子顷刻即满足任何欲望，但实质上它是一个诅咒。因为在设计规划阶段，人类必须应当首先探索后整个方案的空间，而这个空间也会是以后产品的空间，就好像即时战略游戏里的战争迷雾一样，也许我们还没进入建设生产，但就应该先派兵出去掌握地图的情况。在 SPEC-AGENTS 里，我一开始的假设是 AI 智能体足够强大到可以让我省下探索地图的精力，但实践则证明，并非如此。

除了以上我所提到的「语义漂移」导致无法通过纯人工解决，剩下则是工程细节的问题：

• 所有架构都放在一个文件里，对于模型本来就极为有限的上下文空间来说，是非常不划算的。已知，对于 LLM 而言上下文空间越纯净，其表现越好。
• 由于开发过程中，产生大量语义漂移，重复纠正语义漂移，则进一步增加了上下文的压力。而且，如果开发过程中一旦出现了反复重构的情况，那么 LLM 则大概率陷入正语义，与错误语义之间判断失灵的迷惘。

我原本将 SPEC-AGENTS 升级到语义权威，是因为我觉得详细记录所有任务，然后完成后再标记完成任务，这种按照开发阶段的 Vibe Coding 方法，在模型能力变强的情况下，已经过时。但我没想到，引入语义权威之后，所带来的问题并没有减少。因为语义漂移所造成的麻烦，比想象中要严重很多。

我并没有停止探索 Vibe Coding 的方法，只是在我经历了 3 天的沮丧之后，我决定暂时先停下来，不要投入精力到修补 SPEC-AGENTS 这个具体的项目里，好让我跳出来四处看看，所以我决定暂时先封存 SPEC-AGENTS。

不知道我的回复是否覆盖了你希望和我讨论的所有问题，总之，我很高兴有人来信与我共同探讨。我当前正在总结 DeepSeek Harness 的开发方法。我可以确定，它是完全 Vibe Coding 出来的，而尤为宝贵的是，团队将所有的开发记录都保留了，这为研究提供了宝贵的样本。」

与帕斯卡尔相遇

布莱士・帕斯卡尔（Blaise Pascal）是法国著名的数学家、物理学家、发明家、哲学家，同时也是一位天主教作家。

今天在逛哔哩哔哩的时候，看到了一则吸引人的标题，「动起来，否则你就要费劲思考了」，视频里讲的是帕斯卡尔的哲学思想中的一面——不要因为「逃避」而动作。视频里将这种行为特点总结为「逃避式努力」。意义就是，通过盲目的做事，掩盖虚无感，逃避问题。

我看了有所触动，因为觉得大部分人，包括我自己，在日常当中存在很多逃避式努力。反思自己，「买书」、「下载资料」全都是我逃避式努力的一种。我日常缺乏对自己的安排，因为我讨厌安排。但如果扪心自问，为何讨厌安排——心理上的难受是无法逃避的，可能这是一个难得的启动自我对话的契机。

但是没有安排，我又感到无聊和惶恐，于是我装作努力——扮演一个努力的人，来安慰自己。

很幸运通过一个视频与布莱士·帕斯卡尔相遇，让我认识到有这么一个伟人，他一生奉献于自己的信仰，开拓人类的视野，传播科学的精神。并从他的思想中，我获得了对自己的启示。

我计划阅读帕斯卡尔的《思想录》。

朋友，今天的信先写到这里了，祝你生活愉快！