思考笔记

李文业的思考笔记


  • 首页

  • 关于

  • 分类

  • 归档

可编程的显著性:AI时代的注意力争夺战(万维钢风格)

发表于 2026/03/13 | 分类于 AI专题

可编程的显著性:AI时代的注意力争夺战

——万维钢风格:理性思维,精英日课

一个喝水 App 引发的深层问题

先说一个小事。有人用 AI 编程,花了很短时间给自己写了个提醒喝水的 App。装上之后,饮水习惯显著改善。

这个故事的表面含义是「AI 提高了开发效率」。但如果你仔细想想,会发现它远不止于此。

我们来做一个思想实验。请问,有谁不知道喝水重要?几乎没有。这条信息早就存在于所有人的知识库里。但为什么很多人还是喝水不够?

行为科学的回答很明确:知识不等于行为。 从知道到做到,中间隔着一条巨大的鸿沟。

而这条鸿沟的本质,不是你缺乏意志力,而是注意力竞争。这件事值得好好说一说。

第一个洞察:信号、注意力和信息是三个不同的东西

大多数人把「信息」理解为客观存在的内容,把「注意力」理解为处理信息的有限资源。这个模型太粗糙了。

认知科学告诉我们一个更精确的框架——

信号是外部或内部已经存在的差异。身体的口渴是信号。手机上的红点是信号。桌上没翻的书也是信号。天气变冷带来的轻微不适是信号。冥想时出现的一阵心烦是信号。世界充满了信号,每时每刻你的身体和环境都在向你发送大量的差异。

注意力是一个极其有限的放大器。卡尼曼在《思考,快与慢》中反复强调这一点——人的系统二启动成本很高,认知资源极其有限。注意力决定了哪些信号被选中,进入意识前台。

信息则是最终产物。只有那些被注意力选中、并实际改变了你判断或行为的信号,才算得上信息。

这个三层区分至关重要。它意味着一个常被忽视的事实:

注意力不是在「处理」信息,注意力是在「生成」信息。

没有注意力的放大,大多数信号永远只是背景噪音。你每天只有极少数信号能成功进入深度处理通道。被注意力选中的信号成为信息后,又会反过来改变你的心智模型和敏感点,塑造你下一轮的注意力流向。

两者之间的真正关系是一个动态闭环:信号 → 注意力选择 → 信息成立 → 行动与反馈 → 心智模型更新 → 下一轮注意力分配。

核心判断:注意力是在决定,哪些差异有资格对你产生因果作用。 你把这些「因果席位」给了什么,什么就更有可能塑造你。这也解释了为什么一个人真正的价值排序,不是看他嘴上说什么,而是看他反复把注意力交给了什么。

「知道很多道理却过不好一生」的深层机制就在这里。「知道」只发生在内容层。改变必须发生在因果层——一条道理必须反复进入注意力前台,在关键时刻被激活,转化为行动并获得反馈,才能真正作用于人。做不到这些,它就只是知识,不是力量。

第二个洞察:长期重要的事,天生输在起跑线

现在来看一个残酷的结构性事实。

人的注意力系统是进化塑造的。理查德·泰勒和卡斯·桑斯坦在《助推》中详细分析过——人类的认知系统天然被突发的、鲜明的、情绪性的、有即时反馈的刺激吸引。这在旧石器时代完美运作:草丛里的异动需要立即注意,成熟果实的色泽应该马上吸引目光。

但现代环境完全不同了。生活中真正塑造长期人生质量的那些东西,恰恰具有相反的特征——

  • 身体缺水:信号微弱、连续、可被延后。信号强度大概是 0.5。
  • 睡眠债积累:不会即时惩罚你,只会缓慢地侵蚀你的认知能力。
  • 阅读能力退化:不会在一天内给你一个明确反馈。
  • 冥想质量下降:只是让你更容易烦躁,而不是一记警报。
  • 财务风险:长周期、低显著、弱反馈。
  • 深度关系的变质:连续、渐进、几乎没有明确的转折点。

而与此同时,一条朋友圈评论通知的信号强度是 8。一个短视频推荐的信号强度是 9。谁会赢?答案早就注定了。

核心判断:短期低价值信号的显著性,系统性地压过了长期高价值信号的显著性。

这不是你意志力的问题。这是注意力竞争场的结构性不公平。你面对的不是一个中性的注意力分配环境,而是一个被平台、产品逻辑和社交机制高度塑形过的竞技场——那些短期刺激穿着闪亮的战甲,而你的长期价值穿着灰色的毛衣。

这也解释了为什么「再提醒自己一下」「再努力一点」常常不起作用。问题不是你缺一条提醒,而是整个注意力环境的竞争规则就对长期价值不友好。

第三个洞察:AI 真正改变的是「意图到系统」的距离

理解了上面的分析,你就会明白那个喝水 App 为什么有趣了。

它做的不是给你增加一条「请喝水」的知识。它做的是弱信号增幅——把一个弱信号重新编码,提高它在注意力竞争中的排名。原来是身体在低声提醒,现在变成系统在精准地放大和重新编码。

原来是「我今天好像没怎么喝水」这样一个模糊的念头,现在变成「今天只喝了 800ml,下午两点以后是你最容易忽视补水的时段」这样一个精准的、结构化的信息。

而 AI 在这里扮演的角色,远不只是编码加速器。AI 真正改变的是一个更根本的结构:一个人从模糊意图到可运行系统之间的距离。

过去,你即便很清楚想改善某个方面——比如多喝水、规律阅读、固定冥想——中间还隔着产品设计、工程实现、界面交互、数据逻辑、反馈迭代的高门槛。大多数人最终只能依赖意志力和零散提醒。

现在,一个普通人可以低成本地把自己的价值目标变成持续运行的系统。这意味着过去很多只能停留在「我应该」的事情,现在有机会变成「我已经把它安放进环境里了」。

查尔斯·杜希格在《习惯的力量》中讲「提示——惯常行为——奖赏」回路。但他没有回答一个问题:谁来设计这个回路?过去只有大公司和平台有这个能力。现在 AI 让个体也有了。

我把这种系统叫做注意力支架。行为科学的大量研究表明,长期行为不是靠裸露意志维持的,而是靠环境、节奏、提醒、反馈和惯性共同支撑的。注意力支架不是代替你意志坚强,而是为长期重要的价值提供一套持续作用于注意力的外部结构。

AI 让个体第一次能大规模、低成本地制造属于自己的注意力支架。 这一条就足以改写个人成长的底层逻辑。

第四个洞察:可编程的显著性——一个时代级概念

在这里,我要提出一个我认为非常重要的概念:可编程的显著性(Programmable Salience)。

显著性是指某个东西能否从背景中跳出来抓住注意力。过去,大规模设计显著性的能力主要属于平台和大公司。推荐算法、通知系统、信息流,本质上都是显著性编排机器。谁掌握了这种能力,谁就对人的注意力流向拥有塑形权。

AI 让显著性变得可被个人编程了。你可以决定:

  1. 一个信号什么时候出现
  2. 以什么形式出现——文字、图表、语音、弹窗还是对话
  3. 出现频率如何
  4. 是否结合你的历史行为做动态调整
  5. 是否根据你当天的日程和状态做自适应
  6. 它是低分辨率地轻触你一下,还是在你愿意时展开更高分辨率的信息层级

信息时代正在从「获取信息」转向「编排显著性」。 过去的瓶颈是获取——我能不能搜到、学到。今天真正稀缺的是编排——哪些信息值得进入生活系统,何时进入,以何种形式进入,能否转化为持续作用。

在社会层面,这件事早就存在——平台就是注意力编排机器。但在 AI 出现之前,这种能力主要属于大公司和大型机构。今天,个体开始具备了反向使用这种能力的可能性。

这就是认知主权的新起点。

第五个洞察:你需要「神话」和「官僚制」的配合

赫拉利在《Nexus》中提出过一个深刻的判断:信息不等同于真相。历史上推动大规模合作的,往往不是最接近事实的东西,而是更能连接人、制造共同叙事、嵌入制度流程的东西。

信息首先是一种组织力量。

一旦意识到这一点,我们就更清楚地理解很多现象:为什么「事实早已知道」却无法改变行为?为什么某些叙事明明不够准确却极有动员力?因为真正起作用的从来不只是内容真假,而是某种信息形式是否成功地嵌入了网络结构、流程结构和注意力结构。

《Nexus》的一个深刻启发是:人类文明之所以能扩大合作,不仅因为我们能交换事实,还因为我们能围绕叙事建立共同想象,围绕制度建立共同流程。故事让人愿意相信,官僚制让人持续行动。

把这个洞见缩小到个人层面,会发现一个非常实用的框架:一个人要长期改变自己,需要两套系统的配合——

「神话」(叙事层): 我是谁?我重视什么?我在成为什么样的人?比如「我是一个愿意照顾身体的人」「我是一个把长期价值放在即时刺激之上的人」「我是一个珍惜深度阅读的人」。这些故事提供方向和意义。

「官僚制」(制度层): 提醒、清单、记录、表格、计数、定期回顾、例外处理、规则调整、节律安排、可视化趋势。这些看似枯燥的流程把价值从语言层带到运行层。

很多人的问题出在两者严重失衡:

  • 只有神话没有官僚制——你有大量价值观,却没有任何流程支撑,所有理想停留在心里。
  • 只有官僚制没有神话——打卡很漂亮,表格很整齐,但早已忘记为什么开始。系统从服务价值变成了替代价值。

高手的做法是让两者互相校准:叙事提供方向和意义,流程提供持续性和可执行性,二者都接受现实和反馈的修正。

这也解释了为什么喝水 App 有可能有效,也有可能失效。如果它只是一个机械计数器,最终可能只把人训练成「为了完成数字而喝水」的机器。但如果它背后始终连接着「我在照顾自己的身体」这样的叙事,那它就仍然在服务一个更高层的目标。

第六个洞察:信息系统是跨时间管理自己的装置

人的很多困难源于一个基本事实:不同时间的你,并不是同一个人。

早晨的你想健康,下午的你被工作吞没,晚上的你只想躺着。本周的你想多读书,下周的你只想刷轻松内容。情绪好的你相信长期主义,疲惫的你只想立刻舒服一点。

行为经济学家理查德·泰勒用「多个自我」模型来描述这种现象——我们可以把不同时刻的自己想象成不同的「代理人」,它们有着不同的偏好和优先级。

从这个角度看,所谓自我管理首先不是「一个统一意志如何命令自己」,而是「不同时间、不同状态的自己如何被协调」。

信息系统的本质意义就在于此:它是一种跨时间管理自己的装置。

喝水 App 不是「提醒一下」那么简单。它让过去某个清醒时刻作出的价值判断,持续地作用于后来的自己。它让「我知道健康重要」不再只是一个瞬间的认知,而变成一种跨时间的影响机制。

系统之所以有力量,不是因为它更聪明,而是因为它更稳定。它把不稳定的人连接进一个相对稳定的结构。

第七个洞察:最大的危险不是效率不足,而是代理指标劫持

最后一个关键判断。一个系统的好坏关键不在于它够不够高效,而在于它有没有自我纠错的能力。

为什么?因为最大的隐患不是系统不运转,而是代理指标劫持。

古德哈特定律说得很明白:一旦一个指标变成目标,它就不再是好的指标。

系统运行久了,那些本来只是中介手段的指标——打卡天数、完成率、数字——会悄悄取代原目标本身。你开始为打卡而冥想、为 streak 而阅读、为数字而喝水。更隐蔽的是这件事不以失败的形式出现。你觉得自己很自律,但目标已被偷换。

与之相伴的是感受力退化。系统过强时,你对身体和情绪的直接感受反而减弱。原本是「我感觉需要停一停」,变成了「系统还没报警,应该没事」。系统本来是帮你更敏锐地照顾自己,结果你越来越不依赖自己的直接感受,而是依赖外部系统的提示。

这在三个场景中表现得尤为明显:

喝水——好的系统不是简单每小时响一下,而是要理解你的工作节律、常见失守时段、对通知的敏感度。它需要既能提醒又不制造过量烦躁,既能记录又不让数字变成唯一目标。

阅读——问题从来不是有没有待读书单,而是深度理解在现代环境里的显著性太低。好的阅读系统应该帮你围绕问题阅读、围绕难点停留、围绕理解做输出、围绕间隔做回顾。否则读得再多也只是增加接触面,不会真的成为信息。

冥想——冥想最能说明系统可能异化你。它本来是训练觉察的过程,可一旦被粗暴系统化就容易退化为「我今天有没有完成练习」。好的冥想系统应该是温和的、适应性的,帮你看到模式而不是强迫你完成指标。

所以一个健康的个人系统应该包含五层结构:

  1. 传感器层——让弱信号可见。没有足够分辨率的传感器,后面一切无从谈起。
  2. 翻译器层——把模糊感受变成可处理的模式。把「觉得不太对劲」翻译成「这里有一个可以响应的模式」。
  3. 反对派层——最缺的一层。你需要定期质问自己:这套东西真的在帮我吗?我是不是在骗自己?AI 在这里的高阶用途是做你的审稿人、异议者,而不只是做你的助手。
  4. 选举层——任何规则都不应永久有效。系统必须内置废除旧规则、替换旧策略的路径。很多人不是没有系统,而是没有结束旧系统的制度。
  5. 宪法层——最高层。守住一条底线:指标只是工具,不是目标。喝水不是为了数字,阅读不是为了页数,冥想不是为了打卡。当工具和目标冲突时,工具让路。

重新定义自律:从「扛住」到「治理」

如果用一句话总结这篇文章的核心判断:

在 AI 时代,自律正在从一种人格品质,变成一种系统设计能力。

过去的自律是「扛住」——凭意志力一次次战胜分心和懒惰。今天的自律更像是「治理」——治理自己的注意力结构,治理什么会反复进入前台,治理哪些弱信号值得被放大,治理哪些指标只能做工具,治理系统如何服务于价值而不是绑架价值,治理不同时间点的自己如何形成连续性。

自由也需要重新理解。在信息密度极高的时代,自由不再只是「没人命令我」。一个人即使表面上没人强迫,也完全可能被环境和系统持续塑形。新的自由是:我能否设计自己的注意力入口,我能否让真正重要的东西获得稳定位置。

没有自己的信息生态,人的注意力就几乎必然被更强的外部生态接管。没有自己的显著性结构,人的长期价值就几乎必然被更响亮的短期刺激压过去。

AI 也带来了一个终极挑战:你会不会放弃建造自己? 一旦系统可以越来越多地替你安排、总结、建议、决策,你就面临一个微妙的诱惑——把越来越多关于「什么重要」的定义权交出去。这时人真正失去的不是某项技能,而是「建造自己」的主动权。

未来最成熟的 AI 使用方式,不是「把自己交给系统」,而是「借助系统,更有力地建造自己」。

AI 让「把意图变成持续运行的信息结构」这件事的成本骤降。这既是机会,也是挑战。

机会在于:你第一次可以为自己建造一套服务于长期价值的认知基础设施。

挑战在于:你是用 AI 来建造自己,还是不知不觉中把自己交给另一个更精密的外部系统。

一个人未来的成熟,越来越少表现为超强意志,越来越多表现为足够好的认知治理能力。未来真正有竞争力的人,不一定知道得最多或动作最快,而是那些能为自己搭建更好信息生态、更会为长期价值争夺显著性的人。

这个选择,将定义你在 AI 时代的真正自由度。

可编程的显著性:信息、注意力与自我治理的哲学审视(刘擎风格)

发表于 2026/03/13 | 分类于 AI专题

可编程的显著性:信息、注意力与自我治理的哲学审视

——刘擎风格:概念辨析与公共哲学

一、从一个日常案例进入哲学问题

我们不妨从一个看起来极其平凡的案例开始。

一位朋友借助 AI 辅助编程,为自己开发了一个提醒喝水的应用。这个小系统在恰当的时刻提示他补水,记录饮水数据,并通过可视化反馈帮助他形成了更好的习惯。结果相当明显——日常饮水量获得了实质性改善。

如果我们把这件事仅仅理解为技术效率的故事,就会错过它所揭示的更深层问题。因为「多喝水有益健康」从来就不是一条稀缺的知识。几乎所有人都知道这一点。这里的困难不在于认知层面的「不知道」,而在于一个更根本的结构性断裂:知道一件事,并不意味着这件事就能持续地作用于你。

这个断裂指向的,其实是一组古老而深刻的哲学问题:知识与行动之间的关系究竟是什么?一个人为什么会「知善而不为善」?在亚里士多德那里,这被称为 akrasia——意志薄弱。传统的解释倾向于将问题归结为意志的不坚定或理性的不够强大。

但在当代认知科学和信息技术的语境下,我们或许需要重新审视这个问题。也许核心障碍不是意志的薄弱,而是信号的淹没。

二、信号、注意力与信息:一组需要严格区分的概念

要理解这个问题,我们首先需要在概念层面做一个重要的区分。在日常用语中,「信息」和「注意力」往往被不加辨别地混用。人们说「信息太多了」,也说「注意力不够用了」,似乎二者不过是一个问题的两面。但如果我们审慎地对待这两个概念,就会发现它们之间的关系远比通常以为的更加复杂。

我认为有必要区分三个层次:

第一,信号。 信号是世界中已经存在的差异——身体的微弱口渴感、屏幕上的通知红点、一本搁置很久的书、冥想时出现的一丝烦躁。它们不依赖于任何人的关注而存在,但它们本身尚不构成有意义的信息。

第二,注意力。 注意力是将有限的认知资源指向特定信号的机制。它不只是一种被动的「接收」,更是一种主动的「选择」和「放大」。注意力决定了哪些信号从背景中被提取出来,进入前台意识。

第三,信息。 真正意义上的信息,不是客观地「摆」在那里的东西。更准确地说,信息是那些经由注意力选择,成功进入了一个主体的认知过程,并实际改变了其判断、情感状态或行动倾向的差异。

这个三层区分揭示了一个常被忽视的要点:注意力与信息之间不是简单的处理关系,而是一种生成关系。 没有注意力的参与,信号不会自动成为信息。反过来,一个信号一旦成为信息——即真正改变了一个人的心智模型——它又会反过来重塑这个人的注意力结构,影响他在下一时刻会「看见」什么。

两者构成一个动态的闭环:信号 → 注意力选择 → 信息成立 → 行动与反馈 → 心智模型更新 → 下一轮注意力分配。

从哲学上看,这里存在一种深刻的循环结构。海德格尔曾指出,我们总是已经处于一种「被抛」(Geworfenheit)的状态之中——我们不是先有一个中立的认知能力,然后再去面对世界;我们总是已经被特定的关切、情境和前理解所塑形。注意力,在某种意义上,就是这种「前理解」在认知层面的运作方式。它不是中性的处理器,而是一个已经带有方向性的选择机制。

三、注意力作为「因果席位」的分配者

如果我们进一步追问注意力的本质,就会到达一个更具力量的判断:

注意力不是在单纯地「看见」信息,它是在决定,哪些差异有资格对你产生因果作用。

这意味着,注意力的稀缺不只是「时间不够」或「认知资源有限」那么简单。更深层的含义是:能真正改变你当下与未来的「因果席位」非常有限。 你把这些席位给了什么,什么就更有可能塑造你的习惯、性格乃至命运。

因此,一个人真正的价值排序,不是看他在理论上声称什么重要,而是看他在日常运行中反复把注意力交给了什么。你可以声称你重视健康、阅读、写作、冥想、长期成长,但如果在实际生活层面,这些东西总是输给即时消息、社交反馈和碎片浏览,那在系统层面,你的生活实际上是被后者组织的。

这也揭示了「知道很多道理却过不好一生」这一普遍困惑背后更深的机制。「知道」只发生在内容层——你在心智的仓库里存入了一条命题。但改变必须发生在因果层——一条道理必须反复进入注意力前台,在关键时刻被激活,转化为行动,并获得反馈,才能真正作用于一个人的生活。做不到这些,它就只是知识,不是力量;只是内容,不是结构;只是陈述,不是因果。

四、显著性的不平等:一个结构性的伦理问题

一旦我们接受了上述概念框架,就会看到一个极具伦理意味的结构性问题:在现代生活条件下,不同类型的信号进入注意力前台的机会是极不平等的。

人类的注意力系统是长期进化的产物。它对突发的、鲜明的、情绪激烈的、具有即时社会意义的刺激高度敏感。而那些真正关乎长期生活品质的事物——身体健康的细微变化、深度阅读的缓慢积累、冥想质量的渐进退化、长期关系的无声变质、财务风险的隐性积聚——恰恰具有相反的信号特征:缓慢、连续、显著性低、反馈严重延迟。

查尔斯·泰勒在讨论现代人的道德处境时提出过「强评价」(strong evaluation)的概念——人不只是有欲望,更有对欲望进行评价的能力,能够区分哪些欲望值得追随,哪些应当被抵制。但泰勒也承认,这种强评价的能力并不是在真空中运作的。它需要特定的社会条件、文化资源和制度支撑。

我们今天面临的困境恰恰在于:现代信息环境系统性地削弱了强评价的运作条件。 当短期低价值信号的显著性持续压过长期高价值信号时,一个人即便拥有清晰的价值判断,也难以让这种判断持续地组织自己的日常行为。

这不再只是个人意志的问题,而是一个关于显著性分配的结构性正义问题。谁有权力设计什么更显著、什么更容易被看到、什么更频繁地进入人的意识前台?在当下的技术环境中,这种权力主要掌握在平台型企业手中。

这也解释了为什么「再提醒自己一下」「再努力一点」常常不起作用。问题不在于缺少一条提醒,而在于整个注意力环境的竞争规则就对长期价值不友好。你不是在一个空白平面上与自己斗争,而是在一个被平台、产品逻辑和社交机制高度塑形过的环境里,与经过精心设计的显著性机制对抗。

五、可编程的显著性:认知主权的新起点

正是在这个背景下,AI 带来的一个重要变化开始显得格外有意义。

过去,精细地设计显著性——设计什么以什么方式、在什么时机、以什么频率进入一个人的注意力——这种能力基本只属于机构和平台。而 AI 开始让这种能力部分地回到个体手中。

一个人现在可以低成本地为自己设计:某个信号何时出现、以何种形式出现、是否结合个人历史行为做动态调整、是否根据当天情境做自适应。这就是我所说的可编程的显著性。

这个概念的哲学意义在于:它开始松动过去那种个体面对大型系统时的单向被动关系。过去,个体面对平台设计的显著性结构,更多只有防御性的应对——关掉通知、删除应用、提高自控。而现在,个体开始拥有了建设性的可能——主动为自己长期珍视的价值搭建信息基础设施。

阿伦特曾将自由理解为「开端」(natality)的能力——自由不只是不受干预,更是能够在世界中发起新事物、创造新结构的能力。从这个角度看,一个人用 AI 为自己搭建服务于健康、阅读、深度思考的系统,恰恰是在行使一种阿伦特意义上的自由。他不是在消极地抵抗外部侵扰,而是在积极地为自己创建一种新的注意力秩序。

AI 真正改变的不只是编码效率,而是一个更根本的结构——一个人从模糊意图到可运行系统之间的距离。 过去,这两者之间隔着产品设计、工程实现、界面交互、数据记录、反馈逻辑和持续迭代的高门槛。现在,一个人可以低成本地把自己珍视的价值——健康、阅读、冥想、写作——变成一个真正作用于日常生活的系统。

六、叙事与制度:个人改变的双重条件

但如果我们止步于此,就会把问题过度简化为技术乐观主义。事实上,一个系统是否真正服务于人的长期价值,取决于一个更深层的条件:叙事与制度的互相校准。

赫拉利在《Nexus》中有一个深刻的洞察:信息从来不只是事实的载体。历史上推动大规模合作的,往往不是最接近事实的东西,而是更能连接人、制造共同叙事、嵌入制度流程的东西。故事让人愿意相信,制度让人持续行动。两者共同维持了复杂社会的运转。

将这个洞见缩小到个人层面,我们会发现完全同构的结构。一个人的长期自我改变,同样依赖两个要素的配合:

叙事——关于「我是谁」「我重视什么」「我在成为什么样的人」的自我理解。麦金太尔在《追寻美德》中强调,人的道德生活不是一系列孤立的决策,而是一个有统一性的叙事。我们需要一个关于自己的故事,来为日常行动提供方向和意义。

制度——那些看似枯燥但让价值得以持续运行的结构:提醒、记录、反馈、回顾、规则调整、节律安排。它们负责把价值从语言层带到运行层,把叙事变成会反复生效的机制。

这里存在一个根本性的张力。叙事没有制度的支撑,会沦为自我感动——你有大量关于理想自我的表述,但生活中没有任何机制让这些表述兑现。而制度失去了叙事的指引,则会退化为官僚主义的自我控制——你精确地打卡、记录、完成指标,却早已遗忘了做这些事的初衷。

好的个人系统,必须让叙事和制度保持动态的互相校准。 叙事提供「为什么值得」的回答;制度提供「如何让它持续生效」的路径;而现实和反馈则提供对两者的检验和修正。

七、跨时间的自我治理

这一分析还可以进一步深化。

人的很多困难,源于一个基本事实:「不同时间的我」并不是一个稳定一致的治理主体。早晨的你想健康,下午的你被工作淹没,晚上的你只想躺着。情绪好的你相信长期主义,疲惫的你只想立刻舒服一点。

从这个角度看,所谓自我管理,首先不是「一个统一意志如何命令自己」,而是「不同时间、不同状态的自己如何被协调」。你真正需要治理的,不只是当下的行动,而是时间中的多个版本的自己。

信息系统的意义由此变得非常明确:它是一种跨时间管理自己的装置。 它让过去某个清醒时刻作出的价值判断,持续地作用于后来的自己。系统之所以有力量,不是因为它更聪明,而是因为它更稳定。它把不稳定的人连接进一个相对稳定的结构。

从这个意义上讲,系统不是替代你,而是在扩大「你」作为一个跨时间主体的连续性。未来一个人越来越重要的能力,不只是会不会做事,而是会不会构造那些可以跨时间维护自己目标的机制。

八、代理指标劫持与自我纠错的必要

这就引出了一个至关重要的问题:什么才是一个「好」系统?

一个常见的误解是,好系统就是高效、稳定、自动化的系统。但效率本身并不保证价值方向的正确。一个能稳定放大错误方向的系统,不会因为运转流畅就变成好系统。

福柯对现代治理术的分析在此具有警示意义:权力最有效的运作方式,往往不是直接的压迫,而是通过设定正常与异常的标准、通过量化和分类、通过看似中立的管理技术来塑形主体。当一个人的自我系统过度依赖量化指标——打卡天数、完成率、连续记录——他实际上可能正在经历一种自我施加的福柯式治理:代理指标悄悄替代了原目标,工具反转为主人。

你开始为数字而喝水,为 streak 而阅读,为时长而冥想。系统的目标被偷换了,但因为表面上一切运转良好,这种偷换极难被察觉。

与之相伴的还有一种更深层的风险:感受力的退化。 系统本来是为了增强一个人对自身状态的觉察。但如果系统过强、提醒过密、外部指标过于替代内在感受,最终可能导致一个人与自身经验之间的距离越来越远。他不再「感受到」自己渴了,而是等系统告诉他该喝水了。

梅洛-庞蒂所强调的那种身体与世界之间的原初交往——前反思的、直接的、具身性的感知——在过度系统化的生活中反而可能被削弱。系统原本应当像一面放大镜,帮助人更清晰地感知自身;但如果它变成了义肢,就可能反过来替代了人的直接感受能力。

因此,好的系统的核心标准不是效率,而是自我纠错的能力。 如果把这一判断工程化,一个健康的个人注意力网络大概需要五个层次:

传感器层——让微弱信号可见。身体状态、阅读节律、情绪波动、专注质量,都需要被感知。

翻译器层——把模糊感受转化为可处理的信息形式。把「我觉得不太对劲」翻译成「这里有一个可以响应的模式」。

反对派层——这是最缺的一层。系统中必须有某种机制来质疑系统本身:这套东西真的在帮我吗?我的指标还对应着真实目标吗?AI 在这里的高阶用途,不只是做助手,更是做审稿人和异议者。

选举层——任何规则都不应永久有效。系统必须内置废除旧规则、替换旧策略的正当路径。否则人会被自己曾经设计的东西反向控制。

宪法层——最高的一层。始终提醒:指标只是工具,不是目标。喝水不是为了数字,阅读不是为了页数,冥想不是为了打卡。当工具和目标冲突时,目标具有最高优先级。

九、AI 的双面性:纠错机构还是宣传部?

在这里,我们还必须正视 AI 本身的双面性。

只要「什么能成为信息」这件事变得可被精细设计,那就意味着它既可能被用来帮助人,也可能被用来操控人;既可能被个体拿来重建生活,也可能被平台和系统进一步拿来占领个体。

如果一个人的 AI 系统只负责夸奖他、鼓励他、平滑他的不安、维护他的自我叙事,它就很容易变成个人宣传部。它会让人感觉被支持,却未必帮人更接近真实。如果它能温和但坚决地指出使用者正在忽视什么、逃避什么、被什么代理指标牵走,那它才有可能成为个人纠错系统的一部分。

AI 最好的未来角色,不是做一个永远顺着情绪走的伴侣型工具,而是一个既理解你、又敢于对你保持一定认知张力的系统。

十、自律的重构:从人格品质到治理能力

以上分析汇聚起来,指向了一个关于「自律」的深层重构。

传统的理解将自律视为一种人格品质:能忍耐、能克制、能坚持。这种理解预设了一个统一的意志主体,通过自身的力量来抵抗外部诱惑和内在惰性。

但在当代信息环境中,这种理解越来越不够用了。因为真正影响一个人行为轨迹的,已经不只是当下一次次的意志决斗,而是他身处怎样的信息环境、怎样的显著性结构、怎样的反馈机制。

在这样的条件下,自律正在发生一次深刻的概念转型:从「扛住」转向「治理」。 它不再只是一种内在品质的展现,而越来越像是一种系统设计和系统维护的能力——治理自己的注意力结构,治理什么持续进入前台,治理系统如何服务于价值而不是反噬价值,治理不同时间点的自己如何形成连续性。

自由也因此获得了一层新的含义。在信息密度极高、显著性竞争极强的时代,自由不再只是消极意义上的「不受干涉」,也不只是积极意义上的「自我实现」。它还包含一层新的维度:是否有能力设计自己的注意力入口,是否有能力让自己真正珍视的事物在日常生活中获得持续的因果地位。

没有自己的信息生态,人的注意力就几乎必然被更强的外部生态接管。没有自己的显著性结构,人的长期价值就几乎必然被更响亮的短期刺激压过去。

结语

从这个意义上说,一个人为自己编写的喝水 App 虽然微小,却具有哲学上的示范意义。它示范了一种在 AI 时代开始成为可能的新能力:让个体不再只是被动地被信息环境塑形,而是开始主动参与到塑造自己注意力结构的过程中来。

但这种可能性也伴随着严肃的责任。AI 可以帮助你建造系统,却不能替你决定系统应当服务于什么。它可以提供无数关于「好生活」的模板,但关于「什么是我的好生活」这个问题,最终的判断权仍然——也必须——属于你自己。

最重要的问题也许不是「AI 会不会替代人」,而是:人会不会放弃建造自己? 一旦系统可以越来越多地替你安排、总结、建议、决策,你就面临一个微妙的诱惑——把关于「什么重要」的定义权也一并交出去。这时人真正失去的不是某项技能,而是自我建造的主动权。

人的尊严,在 AI 时代,某种程度上恰恰体现在这里:不是拒绝使用系统,而是在使用系统的同时,依然保有为自己设定方向、为自己搭建纠错机制、为自己保留最终解释权的意愿和能力。

一杯水里的信息论(梁文道风格)

发表于 2026/03/13 | 分类于 AI专题

一杯水里的信息论

——梁文道风格:散文笔触,文化观照

一

有一段时间,我对「提醒」这件事很着迷。

不是因为它有多复杂,恰恰相反,是因为它太简单了,简单到让人忍不住想追问:为什么一个成年人需要被提醒去做一件他早就知道应该做的事?

起因是一个朋友的故事。他用 AI 帮自己写了一个提醒喝水的小程序。装了以后,据说饮水习惯大为改善。我听了以后觉得挺好笑——一个受过高等教育、日常能处理大量复杂工作的人,居然需要一个 App 来告诉他:你该喝水了。

但笑过之后我发现,我自己又何尝不是如此。

我桌上那个保温杯经常到下午还剩大半杯没动过。不是不渴,而是那种渴的感觉太轻了,轻到像一阵过堂风,还没等你回过神来,就被一封邮件、一条消息、一个会议通知给吹散了。

身体的声音本来就小。而我们生活的这个世界,实在太吵了。

二

博尔赫斯写过一个关于记忆的故事。《博闻强记的富内斯》里,那个什么都记得的人,因为记忆太完美而无法思考。他的问题不是信息不足,而是信息泛滥到失去了结构——每一个细节都同等地涌入意识,没有任何东西被遗忘,因此也没有任何东西真正「重要」。

这个故事总让我想到我们这个时代。

我们和富内斯的困境恰好相反,但又奇妙地相似。我们不是记得太多,而是注意到的太少——或者更准确地说,我们注意到了太多不重要的东西,以至于重要的东西反而被淹没了。

问题不在于世界上没有值得关注的事物。问题在于,值得关注的事物不会自己跳出来对你喊叫。它们通常是安静的、缓慢的、需要你主动去倾听的。一杯水在桌上安静地等着你。一本书在书架上不急不缓地立着。你身体里那个关于「该休息了」的声音,从来不会像手机通知那样带着红点和震动。

而现代生活的设计,从本质上是反倾听的——它倾向于把最能刺激你即时反应的东西推到最前面,而把那些需要时间才能展现价值的东西压到最底下。

一杯水就是这样被压到底下的。

三

这让我想到一个也许值得更认真对待的问题:什么是「信息」?

我们平时说的「信息」,通常指的是一些客观存在的内容:新闻、数据、知识、消息。它们摆在那里,等着你去获取。信息越多越好,获取信息越快越好。整个互联网时代的叙事,基本上就是围绕着「更多、更快地获取信息」展开的。

但如果你仔细想想,就会觉得这个说法有什么不对劲。

因为世界上从来不缺「差异」。你身体的每一个细微变化都是差异。你情绪的每一次波动都是差异。你面前的人的每一个表情都是差异。这些差异无处不在,每时每刻,多到不可胜数。

但它们什么时候才成为「信息」?

我觉得答案不是「当它们客观存在的时候」,而是「当它们成功进入了你的注意力、并实际影响了你的判断或行为的时候」。

也就是说,信息不是摆在那里的东西,信息是发生在你身上的东西。

注意力在这里扮演的角色,就不只是一个「接收器」,而更像是一个「发生器」——它决定哪些差异有资格从背景走到前台,成为真正改变你的力量。没有被注意力放大的差异,永远只是沉默的背景。

这也是「知道很多道理却过不好一生」的真正含义。一个道理可以被你「知道」——存放在你的知识仓库里。但只要它无法在关键时刻进入你的注意力前台,无法被激活为行动,无法获得反馈,它就无法真正作用于你。它只是内容,不是因果。只是知识,不是力量。

四

如果接受了上面的理解,就会看到一个令人不安的事实:现代生活中,哪些东西容易成为信息、哪些东西不容易成为信息,这件事是极不公平的。

身体轻微缺水——不容易成为信息。它的信号太微弱了,被一条消息通知就盖过去了。

睡眠债的积累——不容易成为信息。它是连续的、渐进的,没有哪一天会突然给你一记响亮的惩罚。

阅读能力的退化——不容易成为信息。你越来越难读长文,但你不会收到一条推送说「你的深度阅读能力这个月下降了 15%」。

冥想质量的下降——不容易成为信息。它只是表现为你更容易烦躁、更难觉察自己,但不会像一条评论通知那样跳到你面前。

长期关系的变质——不容易成为信息。它是缓慢的、连续的,几乎没有明确的转折点。

而什么容易成为信息呢?通知。红点。点赞。评论。热搜。推荐。限时优惠。——所有那些被精心设计过的、短期、鲜明、情绪性的刺激。

长期重要但短期微弱的事物,在注意力竞争中天然处于劣势。 不是因为你不重视它们,而是因为注意力竞争场的规则就对它们不友好。

五

我想起了古人的一个做法。

宋代士大夫有一种习惯,叫做「座右铭」。把自己最看重的箴言写在纸上,贴在书桌右边。每天坐下来,第一眼就能看到。

这看起来是一个很朴素的做法。但如果用我们刚才的概念来重新理解,它其实是一种非常古老的「显著性编排」技术。它做的事情和那个喝水 App 没有本质区别——都是把一个重要但容易被日常琐事冲淡的价值,通过某种手段,固定在注意力容易抵达的位置上。

差别在于,古人的信息环境相对简单。一张座右铭就足以与周遭的其他信号竞争。而今天,你的注意力面对的竞争者如此之多、如此专业、如此精于抓取你的反应——一张纸条已经完全不够用了。

所以那个喝水 App 做的事情,某种意义上就是一张升级版的「座右铭」。它把身体那个微弱的口渴信号翻译成了更结构化、更可视化、更能在当代注意力竞争中胜出的形式。它不是增加了什么新知识,而是改变了一个已有信号与注意力之间的关系。

AI 在这里扮演的角色,也许就像一种新的文房四宝。它不改变你要写什么,但它极大地改变了你能用什么来写、以什么形式来固定你的意图。

过去,把一个模糊的意图变成一个可运行的系统,中间隔着产品设计、工程实现、界面交互、数据逻辑等一系列门槛。现在,一个普通人可以低成本地把自己珍视的价值变成持续运行的结构。

这是一个不小的变化。

六

读赫拉利的《Nexus》时,有一个判断让我停了很久。

他说,信息从来不只是关于「真相」的。信息更深的功能,是连接和组织。

人类之所以能建立起大规模合作——从宗教到帝国到现代国家——不是因为我们总是在传递真实的事实,而是因为我们能围绕共同的叙事建立信任和秩序。故事未必是真的,但它能让人相信某些东西值得追求。制度未必是完美的,但它能让人持续地按照某种规则行动。

这让我想到一件很私人的事。

我曾经尝试过很多次养成规律阅读的习惯。每次开始的时候都充满热情。买书、列清单、制定计划、下载 App。但总是几周之后就逐渐松懈了。书还是堆在那里,清单还是长长的,只是我的注意力已经被别的东西带走了。

后来我慢慢意识到,问题不在于我不够自律。问题在于,「我想成为一个深度阅读者」这个叙事,在我的日常生活中缺少制度的支撑。

我有故事——我知道阅读对我意味着什么。但我没有制度——我没有任何机制来确保这个故事在日常运行中反复生效。它就像一个美好的念头,每天早上短暂地出现在脑海里,然后被一天的琐事冲走。

而那些成功占据我注意力的东西——社交媒体的信息流、邮件的通知、新闻的推送——它们之所以成功,恰恰是因为它们同时拥有叙事和制度。它们有一套完整的机制来确保自己反复出现在我面前,并且每一次出现都带着恰到好处的显著性。

一个人要长期改变自己,不只需要正确的道理,还需要叙事和制度的配合。 没有叙事,制度会变得空洞——你在打卡,但你不记得自己为什么打卡。没有制度,叙事只会停留在自我感动——你知道阅读很重要,但它在你的日常运行中没有入口。

七

人的很多困难,其实还有一层更深的原因:不同时间的你,并不是同一个人。

早晨的你想健康,下午的你被工作吞没,晚上的你只想瘫着。本周的你想多读书,下周的你只想刷轻松内容。情绪好的你相信长期主义,疲惫的你只想立刻舒服一点。

从这个角度看,所谓自我管理,首先不是「一个统一意志如何命令自己」,而是「不同时间、不同状态的自己如何被协调」。

那个喝水 App 做的事情,本质上就是让过去某个清醒时刻做出的价值判断,持续地作用于后来那些不同状态的自己。它是一种跨时间的自我照料装置。

这让我想到写信。

在通讯不发达的年代,人们写信。信是一种跨越时间和空间的媒介。你在某个清醒的、温柔的、有话想说的时刻写下一封信,然后它在若干天后到达对方手中。写信的你和收信时的对方,是两个不同时空中的人。

某种程度上,给自己搭建一个提醒系统,就像是给未来的自己写信。你在清醒的时候写下:这件事很重要。然后让系统在你不那么清醒的时候替你送达这封信。

系统之所以有力量,不是因为它更聪明,而是因为它更稳定。它把不稳定的人连接进一个相对稳定的结构。

八

不过,写到这里,我想说一些谨慎的话。

系统是好的。提醒是好的。反馈是好的。但所有这些东西都有一个前提:它们在为一个值得服务的目标工作。

我见过很多人被自己建造的系统异化。冥想变成了打卡。阅读变成了凑数。写作变成了流水线。运动变成了被手环上的数字驱使。饮水变成了凑够 2000ml 的数字游戏。系统还在完美地运转,但里面那个「人」已经不在了。目标被代理指标悄悄替换了,而替换的过程如此顺滑,以至于你自己都没有察觉。

这让我想到加缪说过的话:西西弗斯每天推石上山,重点不在于石头有没有推到山顶,而在于他是否还清楚自己为什么在推。

一个喝水 App 的价值,不在于你是否每天喝够了 2000 毫升。而在于你是否还清楚:你喝水是为了照顾自己的身体,而不是为了让一个数字变绿。

一个阅读系统的价值,不在于你是否这个月读完了四本书。而在于你是否还能在阅读中感受到某种智识上的亲密——那种文字进入你的思维、打开一个你原本没有的空间的感受。

一个冥想练习的价值,不在于你是否保持了 365 天的连续记录。而在于你是否还能在练习中真正回到呼吸,回到身体,回到那个安静的、不被任何指标衡量的当下。

指标是地图,不是风景。 当你开始为了地图而行走时,你就已经迷路了——即便地图上的路线标注得再清楚。

九

本雅明在讨论机械复制时代的艺术时,提出过「灵光」(Aura)这个概念。他说,原作之所以有一种复制品不具备的气质,在于它的「此时此地」——它的独一无二的存在感。

我觉得人的直接感受也有一种「灵光」。

「我感觉有点渴了」——这句话里包含的东西,远比「你今天只喝了 600ml」丰富得多。它包含了你对自己身体的直接觉知,包含了一种不需要经过数字中介的自我关照。那种感受是此时此地的、独一无二的、不可被完全数据化的。

系统可以帮助你找回这种感觉,但也可能取代它。好的系统像一个温和的提示——它轻轻碰你一下,然后退开,让你自己去感受。坏的系统像一面永远亮着的屏幕——它不断告诉你应该感受什么,直到你自己的感受被完全覆盖。

好的系统像一面放大镜——帮你看得更清楚,然后你自己做判断。坏的系统像一副永久的义肢——替代了你原本的能力,直到你离开它就什么都做不了。

这里面有一个更根本的问题:一个好的系统需要能自我纠错。它不只要能稳定运转,更要能在偏离时暴露自己的偏差,允许被质疑和修正。就像一个社会需要反对派和新闻自由,一个个人系统也需要某种机制来定期追问:这套东西还在服务我吗?我是不是已经在为系统打工了?

十

所以最终,问题也许不在于要不要建系统。问题在于:你和你的系统之间,是什么样的关系?

它是你的工具,还是你的主人?它是帮你回到自己的附近,还是在制造另一层遮蔽?它让你变得更敏锐了,还是更麻木了?

AI 时代让「什么会成为你的信息」这件事变得可被设计。你第一次可以比较低成本地为自己决定:什么信号在什么时候、以什么形式进入你的注意力。这件事的意义,也许比我们意识到的更大。它意味着自律不再只是「扛住诱惑」,而开始变成一种设计和治理能力——治理自己的注意力结构,治理什么反复进入前台,治理系统如何服务于价值而不是绑架价值。

但它也意味着一种新的责任。当你拥有了设计自己注意力入口的能力,你就不能再只是抱怨环境太吵、平台太坏、诱惑太多。你必须开始追问:我愿意让什么反复进入我的生命?

这个问题没有标准答案。但也许,在这个一切都可以被追踪、被量化、被优化的时代,有一种能力正在变得越来越珍贵:

那就是在没有任何系统提醒你的时候,你依然能安静地坐下来,端起那杯水,因为你感觉到自己需要它。

不是因为数据告诉你,不是因为通知提醒你,不是因为 streak 要求你。

而是因为你,你自己,在那个当下,真实地感受到了。

也许这才是所有系统最终应该服务的目标:不是让你做得更多,而是让你感受得更清楚。不是让你更高效地活着,而是让你更真实地活着。

不是让系统替我们活,而是让我们在系统的帮助下,更有能力认真地活。

这杯水里,其实藏着一整个时代的问题。而你端起它的那一刻——无论是因为系统的提醒,还是因为自己的感受——都是一个值得被认真对待的时刻。

显著性的生产与分配:注意力的人类学观察(项飙风格)

发表于 2026/03/13 | 分类于 AI专题

显著性的生产与分配:注意力的人类学观察

——项飙风格:田野视角,冷静诊断

一、一个小场景

我想从一个很小的场景说起。

有一位年轻人——他有稳定的工作,有不错的教育背景,生活条件不算差——用 AI 给自己写了一个提醒喝水的 App。不是因为他不知道喝水重要,而是因为他发现自己在工作日常常一上午都忘记喝水。App 上线之后,他的饮水习惯确实改善了。

如果我们只是把这件事理解成「技术提高了效率」,那我们其实什么都没看到。

让我试着换一个角度来观察这件事。一个受过良好教育的成年人,明确知道喝水对身体好,但需要一个外部系统来提醒自己完成这件几乎是最基本的身体照料行为。这件事本身说明了什么?

它说明的是:在当代生活条件下,一个人与自己身体之间的关系已经被高度中介化了。 他不是不关心自己的身体。他是被置于一种环境之中,这种环境使得身体的直接信号不再容易被听到。

二、附近的信号,遥远的噪音

我曾经讨论过「附近的消失」这个问题。在当代中国的城市生活中,人们越来越不关注自己的附近——附近的社区、附近的人、附近发生的事——而是被卷入一个由远方的信息构成的漩涡中。手机屏幕打开的那一刻,你就被带离了你所在的物理空间。你坐在自己的房间里,但你的注意力可能在千里之外的一条热搜上。

注意力层面上,类似的事情也在发生,而且发生得更加深入。

你的身体是你最「附近」的存在。口渴、疲倦、肌肉酸痛、情绪低落、呼吸的细微变化——这些都是来自「附近」的信号。它们不需要任何中介就可以被你感知。它们就在你之内。

但在现代工作和信息环境中,这些附近的信号被系统性地压制了。压制它们的不是什么恶意的力量,而是一种结构性的安排:你的工作节奏、你的屏幕界面、你的通知系统、你的社交媒体——这些构成了一个完整的注意力环境。在这个环境里,远方的信息天然比附近的信号更显著。

一条来自几千公里外的评论通知,在你的注意力里,比你自己身体发出的口渴信号更响亮。一个远方的热搜话题,比你自己胃在咕咕叫更容易进入你的意识前台。这不是你的选择。这是你被置入的结构使然。

从人类学的角度看,这是一个非常值得注意的现象:现代人正在经历一种注意力的外向化——注意力的重心系统性地从身体、从附近、从直接经验,转移到了屏幕、远方、中介化的信息上。

而这种外向化不是自然发生的。它是被设计的。

三、谁在生产显著性?

如果我们问一个简单的问题——「是什么决定了一个人在某一刻会注意到什么?」——答案会比你想象的更复杂。

表面上看,注意力是个人的。你在「选择」看什么、想什么、回应什么。但如果你仔细观察一个人一天的注意力流向——像做田野调查那样,追踪他从早到晚每一次注意力的转移——你会发现,绝大部分「选择」其实是由环境预先安排好的。

手机什么时候响、红点出现在哪里、推荐列表里排在前面的是什么、哪条信息被放大了、哪个界面更容易被点开——这些都不是中性的。它们是被设计过的。设计者有自己的利益和目标。

我把这个过程叫做显著性的生产。

在传统社会里,显著性更多是自然产生的。什么东西显著,主要取决于物理距离、社会关系和身体感受。你面前的人比远方的人更显著。你的饥饿比抽象的经济数据更显著。你所在社区发生的事比另一个大洲的新闻更显著。

但在当代信息环境中,显著性变成了一种可以被工业化生产的东西。平台通过算法和界面设计,大规模地制造显著性——决定什么信息「跳」出来,什么信息沉入背景。推荐算法不是在中性地传递信息,它是在精确计算什么最能抓住你的注意力、留住你的时间。

这本质上是一种权力。 谁掌握了生产显著性的能力,谁就在很大程度上决定了人们的注意力流向。而注意力流向,反过来塑造人的感知、判断和行为。

从这个角度来看,平台经济不只是一个商业模式问题,它还是一个注意力治理问题。平台不只是在「提供信息」,它在组织人们每天能看见什么、反复看见什么、因此逐渐习惯什么、相信什么、追逐什么。

在这样的环境里,那些长期重要但短期微弱的信号——身体的需要、深度阅读的积累、冥想的价值、长期关系的维护、财务的审慎规划——几乎必然会输给那些被精心设计过的高显著性刺激。不是因为人不珍视这些东西,而是因为注意力竞争场的规则本身就对它们不友好。

四、一个人的反向工程

回到那个喝水 App。

如果我们把它放在上面的分析框架里看,它其实是一个非常有意思的案例。因为这个年轻人做的事情,本质上是在进行一种显著性的反向工程。

他观察到自己的注意力环境有一个结构性的问题:身体的弱信号打不过屏幕的强刺激。然后他借助 AI,为自己搭建了一个小型的显著性生产装置——这个装置的功能是把一个原本微弱的信号(身体缺水)翻译成一种在他的注意力环境中更有竞争力的形式(结构化的提醒、数据和反馈)。

更进一步说,AI 在这里改变的不只是编码速度。它改变的是一个更根本的结构——一个人从模糊意图到可运行系统之间的距离。过去,即便你很清楚想改善某个方面,中间还隔着产品设计、工程实现、界面交互、数据逻辑、反馈迭代的高门槛。大多数人最终只能依赖意志力和零散提醒。现在,一个普通人可以低成本地把自己的价值目标变成持续运行的系统。

这件事之所以值得关注,不在于它本身有多大的实际价值,而在于它所揭示的一种新的可能性:个体开始有能力对自己的注意力环境进行局部的反向改造。

过去,在平台和算法面前,个体基本上只有两种选择:接受,或者退出(比如关掉通知、删掉 App、减少使用)。而现在,AI 提供了第三种可能——建设。你不只是被动地接受一个现有的注意力环境,也不只是通过断联来逃避,而是可以为自己搭建一个局部的、服务于自己目标的小型注意力基础设施。

但我想指出的是,这件事比它看起来更复杂。

五、叙事与制度的协同

赫拉利在《Nexus》中有一个观察让我印象深刻。他说,信息不等于真相。人类之所以能建立大规模合作——从宗教到帝国——不是因为我们交换了准确的事实,而是因为我们围绕共同的故事建立了共同的想象,围绕共同的制度建立了共同的流程。

如果把这个观察缩小到个人层面,你会发现一个类似的结构。

一个人要长期改变自己,需要两样东西的配合:叙事和制度。

叙事是你对自己讲的故事:我是谁,我重视什么,我在成为什么样的人。它提供方向和意义。制度则是那些看似枯燥但让价值持续运行的东西:提醒、记录、反馈、回顾、规则调整。它们把故事从语言层带到运行层。

在我的观察中,很多人的困境就出在这两者严重失衡。有些人有大量叙事——「我重视健康」「我想成为深度思考者」——但生活里没有任何制度支撑,所有理想停在心里。另一些人则反过来,系统做得很精密,打卡很完美,但早已忘记自己为什么开始,流程从服务人变成了控制人。

这个观察也适用于更大的社会分析。我们常常看到,一些制度在建立之初是为了实现某个价值目标,但运行久了之后,制度本身变成了目的,原来的目标被悄悄替换了。这在组织研究中是一个非常经典的现象,而在个人层面同样频繁地发生。

六、新的依赖与新的遮蔽

当一个人开始用系统来管理自己的注意力时,一种新的关系就产生了。他不再只是依赖自己的内在感受来决定做什么,他开始依赖一个外部装置。

这种依赖在短期内是有益的——它确实帮助他更好地照顾了自己的身体。但在长期中,一个值得警惕的可能性会浮现:系统可能替代而不是增强他对自身的直接感知。

原来是「我感觉有点渴了」,然后你去喝水。现在变成了「App 提醒我该喝水了」,然后你去喝水。行为结果一样,但中间发生了一个微妙的变化——你与自己身体之间多了一层中介。久而久之,你可能越来越不依赖那个直接的身体感受,而越来越依赖外部系统的提示。

这在人类学上是一个反复出现的模式。技术总是承诺增强人的能力,但同时也在改变人与自身经验之间的关系。GPS 增强了你的导航能力,但同时削弱了你的空间感知。翻译软件增强了你的跨语言交流能力,但同时降低了你学习语言的动力。

同样的逻辑也适用于注意力管理系统。它帮助你更好地照顾自己,但也可能让你更少地「亲自」照顾自己。

更隐蔽的问题是代理指标的替代效应。系统运行时间一长,那些被追踪的数字——饮水量、阅读页数、冥想时长、运动步数——就会逐渐取代它们本来代表的东西。你开始为了数字本身而行动,而不是为了数字背后的那个价值。

这种替代不是系统的「故障」,它是系统运行的内在趋势。任何把复杂的人类价值翻译成可量化指标的过程,都会丢失一些东西。而那些被丢失的,往往恰恰是最重要的——细腻的身体感受、模糊但真实的情绪、不容易被计数但深刻影响生活质量的东西。

这也解释了为什么很多人的系统表面上运转良好——打卡完成、数字好看、趋势向上——但他们自己并不觉得生活有什么本质改善。因为指标替换了经验。地图替代了风景。

七、治理的问题

如果把视野再拉大一些,我想指出的一点是:这个年轻人做的事情,本质上是一个微型治理行为。

他在治理自己的注意力。他在决定什么应该被看见、什么应该被放大、什么应该在什么时候出现。这些决定过去主要由外部环境——由平台、由工作节奏、由社会惯例——来做。现在他开始部分地把这个决定权拿回来了。

而且,这种治理还涉及到一个跨时间的维度。人的困难很多时候源于「不同时间的我」并不一致。早晨的你想健康,下午的你被工作吞没,晚上的你只想躺着。信息系统在这里做的事情,是让过去某个清醒时刻做出的价值判断,持续地作用于后来不同状态的自己。它是一种跨时间的协调装置。

这让我想到一个更大的问题。在当代社会中,注意力的分配已经不是一个纯粹的个人选择问题。它是一个治理问题——涉及权力、涉及利益、涉及人与环境之间的结构性关系。

谁在治理你的注意力?过去,主要是平台、是雇主、是社会规范。现在,AI 提供了一种新的可能性:个体也可以参与对自己注意力的治理。

但这种可能性不应被过度浪漫化。

八、不应被过度浪漫化的自由

一个人的自我治理能力,终究受到他所嵌入的更大结构的限制。你可以给自己写一个喝水 App,但你改变不了那个让你一上午忘记喝水的工作制度。你可以为自己设计一个阅读系统,但你改变不了那个持续挤压深度阅读时间的社会节奏。你可以搭建一个冥想辅助工具,但你改变不了那个让冥想变成需要被打卡管理的焦虑环境。

个体的注意力自治,始终是在更大的结构性条件下运作的。

而且,个体的自治本身也面临着内在的张力。你以为你在为自己设计系统,但你设计系统时所使用的标准——什么算「好」、什么算「成功」、什么值得追踪——这些标准本身可能已经被更大的文化逻辑塑形过了。当你把冥想转化为可追踪的分钟数时,你是否已经在用一种绩效主义的逻辑来重新编码一种原本反绩效的实践?

这不是要否定个体的能动性。个体当然可以、也应该参与对自己注意力的设计。但我们在肯定这种能动性的同时,也不能忘记去追问那些更大的问题:

是什么样的工作制度让人连喝水都需要被提醒?是什么样的信息环境让人无法安静地阅读一本书?是什么样的生活节奏让冥想和反思变成了需要被打卡管理的任务?是什么样的文化逻辑让「照顾自己」这件最基本的事变成了一个需要系统工程来解决的问题?

一个喝水 App 可以是一个好的开始。但它不能是终点。真正需要被重新设计的,不只是个人的注意力系统,还有塑造这个注意力困境的更大的社会结构。

九、一个冷静的总结

最后,我想做一个冷静的总结。

AI 时代带来了一种新的可能性:个体开始能够以较低的成本,参与对自己注意力结构的设计。在此之前,设计人的注意力流向的能力,基本上是大型机构的专属。这不是一件小事。

但我们不应把这种可能性理解为一种简单的解放叙事。它同时伴随着新的风险:

新的依赖——你可能越来越依赖外部系统来感知自己,而不是直接回到自己的身体和经验。系统从放大镜变成了义肢。

新的遮蔽——代理指标可能悄悄替代真正的价值,让你以为自己在进步,实际上只是在喂养数字。

新的自我治理术——你可能以为自己在争取自主,实际上只是把一种外部控制替换成了另一种更精致的自我控制。你用绩效逻辑管理自己的冥想,用数据思维追踪自己的感受,最终可能离真实的自己更远而不是更近。

结构性问题的个体化——当每个人都在忙着为自己搭建注意力系统时,那些真正造成注意力困境的结构性条件——过度的工作强度、无孔不入的平台逻辑、以效率为唯一价值标准的社会节奏——可能反而被遮蔽了。个体的自我优化,有可能成为不追问结构性问题的借口。

在这些可能性面前,最重要的也许不是急于建设更多系统,而是保持一种警觉:

你的系统是在帮你回到自己的附近,还是在制造另一种形式的疏远?

你是在用系统来增强自己的感受力,还是在用系统来替代它?

你是在治理自己的注意力,还是在用一种更精致的方式驯服自己?

这些问题没有标准答案。但它们值得被反复追问。

因为一个好的系统——无论是社会层面的还是个人层面的——最重要的品质从来不是高效,而是能不能在偏离时暴露自己的偏差,并允许被修正。

一个不允许被质疑的系统,无论它运转得多么流畅,最终都会把人带往错误的方向。对社会如此,对个人同样如此。

看书114个月

发表于 2026/03/08 | 分类于 每月报告

1

二月份阅读时间超出预期,原定目标300小时,实际达到315小时。能有这么大的进步,自研的番茄冥想APP功不可没。

冥想目标没完成。原定目标40小时,实际只有30小时。之所以没能达成,是因为我没当回事,还没养成天天关注冥想时间的习惯。

接下来,我会跟大家分享我是如何利用AI编程,帮助我管理自己的注意力的。

2

我分配了一小部分注意力到喝水这件事上。

我的喝水习惯很不好,常常是渴到不行才喝水。七八年前体检的时候,医生就提醒过我,有肾结石和胆囊结石,应该多喝水。

我没当回事,哪怕后面疼了好几次还是没当回事。我现在只要吃得比较饱,吃得比较油腻,就有可能因为结石刺激,导致急性胆囊炎。症状就是胸口特别疼,好几次在睡梦中被疼醒,甚至有一天晚上疼了一宿,在床上翻来滚去。

即便是这样,我还是没能改正自己喝水习惯,直到我前段时间用AI开发了一个喝水APP。

APP模仿的对象是Water Llama,前几年得奖的一个iOS APP。只花了一个小时不到,AI就把APP开发好了。我装到手机上,立刻就用得爱不释手。

它能很容易记录我的喝水次数和饮水量。如果我长时间没喝水,或者喝的水不够,它还会提醒我。我收到提醒,就会去喝水。

在使用APP之前,我估计自己一天喝水不到1L。在使用APP之后,每天喝水都超过3L。

3

跟喝水APP帮我把足够的注意力分配到喝水一样,番茄冥想APP让我更关注阅读和冥想,图书APP让我更关注自己的学习资料,ClawChat APP让我更关注使用OpenClaw,也就是最近很火的“养龙虾”。

拿起手机,我就习惯性打开番茄冥想APP,看今天的阅读次数够不够,冥想次数够不够,要不要抽空看看书,冥想一次。

闲下来了,我会打开图书APP,看最近有哪些自己跟AI共创学习资料想读。

有碎片化的时间,我还会打开ClawChat APP,跟家里安装的OpenClaw聊天,问问它的工作情况。

过去十几天,我每天打开这些APP平均超过100次,使用时长超过43分钟。

我尝试过戒手机,减少使用手机的时间,屡战屡败。

我现在发现,手机本来就是抢夺注意力的大杀器,我们不可能正面对抗它。既不现实,也没收益。

4

有了AI,我可以借助AI开发APP,借助手机把自己的注意力抢回来。

工作累了,我很难忍住不拿出手机。既然忍不住,就不忍了。我拿出手机来,看看自己是不是喝够水了,没喝够就去倒杯水喝。

中午休息,吃饭的时候我就爱玩手机。以前是刷视频和看网文,现在可以一边跟龙虾员工远程质询,一边用图书APP看学习资料。

有了大块的业余时间,我就用番茄冥想APP记录自己的看书和冥想情况。

开发APP,以前很贵,哪怕是我这种工作了很多年的程序员,都付不起这样的学习成本和时间成本。

那些大公司就不一样,他们会聘请成千上万训练有素的iOS开发工程师和算法工程师,来争夺我们的注意力。

现在有了AI,攻守之势哪怕不是彻底反转,我们也开始有了反击之力。

5

我的目标是有一天,我的手机里大部分都是我自己让AI帮我写的APP。让我的注意力,服从我自己的意志。

截至2026年2月28日,我一共阅读了19738.5小时。预计会在2026年3月25日,完成第二个10000小时,也就是总共20000小时的阅读目标。

三月份的阅读目标是700个番茄时间,也就是350个小时。冥想目标是32小时。

一个人运维五个项目的生存指南

发表于 2026/03/07 | 分类于 AI专题

一个人运维五个项目的生存指南

风格:阮一峰(技术科普体)


一、引言

我用 AI 辅助开发了五个个人项目:番茄钟 App(iOS + Spring Boot 后端)、ClawChat(聊天机器人)、OpenClaw(AI agent 框架)、喝水提醒、以及一套数字资产知识体系。

过去一周(3/1–3/6),其中两个项目接连出了线上事故。修完之后,我把教训整理成了六条原则。这篇文章是对它们的系统性梳理。

如果你也是一个人在做 side project,尤其是有后端服务在跑的那种,希望这些经验对你有用。


二、发生了什么

先说事实。

事故一(3/5):ClawChat 的上游服务 OpenClaw 不可达,HTTP 请求直接超时。系统没有任何回退机制,给用户返回一个固定的“暂时不可用”文案。根因是 launchd 启动时 PATH 环境变量与手动启动不同,导致调用了错误版本的二进制文件。

事故二(3/6):番茄 App 的 token 过期,触发重新登录,App 在重登时清除了本地缓存——包括 6 条尚未同步到服务器的番茄记录。与此同时,后端也出了问题:一条慢 SQL 引发锁等待,Tomcat 的 120 个线程全部阻塞,客户端重试请求不断涌入,连接池耗尽,整个服务雪崩。

两次事故的表象不同,但根因相同:只设计了正常流程(happy path),没有处理失败流程。


三、原则一:失败路径的三条底线

失败路径不可能穷举——一条正常流程对应的异常分支是指数级的。但以下三条底线成本低、收益高,值得作为硬性要求。

1. 用户数据不能静默丢失

凡是涉及用户创建的数据,失败时至少做到三件事:

  • 不删、不覆盖:未同步的数据是用户资产,不是临时缓存
  • 给用户一个可见的提示:不允许静默失败
  • 本地留一份兜底:关键数据有导出或恢复入口

反面案例:番茄 App 的 pendingSync 数据在重登时被清除,6 条记录永久丢失。

2. 上游变慢时不要把自己拖死

不需要完美的熔断体系,但至少做到:

  • 设 timeout:不要用框架默认的无限等待
  • 设 max inflight:不要让请求无限堆积
  • 客户端重试要有退避:5xx 或超时期间不做高频平推

反面案例:1 核机器用 120 线程默认值,慢 SQL + 客户端重试直接雪崩。

3. 关键路径加一个 fallback

不需要完美的降级方案,只要“不是直接给用户一个死胡同”:

  • HTTP 不可达 → 自动回退 CLI 调用
  • 主数据源失败 → 展示本地缓存 + 状态标记
  • 关键接口超时 → 返回降级响应而非空白

正面案例:ClawChat 修复后增加了 OPENCLAW_CLI_FALLBACK_ENABLED,HTTP 失败时自动回退 CLI。


四、原则二:小机器要主动校准参数

这是一个容易被忽略的盲区。框架的默认配置面向多核服务器设计,而大多数个人项目跑在 1 核 2GB 的小机器上。

以下是单核机器的关键参数速查表:

参数 框架默认值 单核建议值
Web 线程池(max-threads) 200 4–8
DB 连接池(maximum-pool-size) 10 3–5
请求超时(timeout) 无限/30s 10–30s
等待队列(accept-count) 100 16–32
连接泄漏检测(leak-detection) 关闭 10–15s

核心原则很简单:默认值不是安全值。 把运行参数从“默认没碰过”变成“我看过、我定的”,这件事十分钟就能做完,但能防住一次雪崩。

部署新服务时的检查项:

  1. 确认目标机器 CPU 核数和内存
  2. 按速查表设置线程池、连接池、超时参数
  3. 不使用框架默认值,显式写入配置文件
  4. 首次部署后观察 30 分钟 CPU 和内存水位

五、原则三:自愈优先于监控

一个人运维时,告警的价值是有限的。告警来了你可能在睡觉、开会、或者在另一个项目的深度工作里。你不可能 24 小时盯着。

所以正确的优先级是:先做自愈,再做监控。

场景 监控思路 自愈思路
进程挂了 发通知,等人来重启 systemd/launchd 自动重启
请求堆积 发通知,等人来限流 内置 max inflight,自动拒绝
上游不可达 发通知,等人来排查 自动 fallback(如 CLI 回退)
证书快过期 发通知,等人来续期 certbot 自动续期
连接池满 发通知,等人来杀连接 连接超时 + 泄漏检测自动释放

给 AI 提运维需求时,建议默认先问:这个能不能做成自愈的? 而不是先问“怎么监控”。

此外,减少运维面积本身也很重要。最有效的运维优化不是“更好地监控”,而是“少一个要监控的东西”。每上线新功能前问自己:能不能不加新服务?能不能复用已有的?


六、原则四:数据备份要设计驱动,不要事故驱动

事故之后我手写 SQL 把丢失的 6 个番茄补录回去了。补录之所以能成功,是因为三个条件碰巧满足:我还记得做了什么、数据量很小、我会写 SQL。这三个条件任意一个不满足,数据就永久消失。

盘点下来,我的数据保护是事故驱动的——出过事的就备份了,没出过事的就裸奔。

数据 有备份 能恢复
番茄记录(阿里云 MySQL) ✅ ✅
ClawChat 对话(腾讯云 MySQL) ❌ ❌
digital-assets 文档 ✅(Git) ✅
OpenClaw 配置(本机) ❓ ❓

空白格就是风险。

从“有备份”到真正安全,有三级台阶:

  1. 补齐空白:有 > 无。先把裸奔的数据备份起来
  2. 确认有效:能恢复 > 有备份。定期做恢复演练,确认备份不是坏的
  3. 自治运转:备份任务自身有健康检查,失败自动重试,无需人工干预

手动补录是最后手段,不应该是常规手段。


七、原则五:AI 说“完成了”需要分层验收

AI 给番茄后端写了一个 TimeConfig 修复,测试通过,AI 说“修复完成”。我信了,直接部署。结果发现改了一半。

问题不是 AI 能力不行,而是“修复完成”和“线上真的好了”之间缺少验收环节。

验收不是只能人来做。AI 和人应该各守不同层次:

层次 谁做 验什么
L1 代码正确性 AI 类型检查、lint、单元测试
L2 功能可用性 AI 冒烟测试:API 能响应、数据能存取
L3 线上真实性 AI 部署后自动验证,确认修复在线上生效
L4 体验判断 人 交互顺不顺、流程合不合理

当前的缺口在 L3。建议每个项目的部署流程最后一步,自动跑一组最小验证。例如:

  • 番茄后端:调一次 /api/current-pomodoro,确认 200 且延迟 < 500ms
  • ClawChat:发一条测试消息,确认收到回复且状态 SUCCESS

以后让 AI 做修复时,在需求最后加一句:“修完之后,写一个部署后自动验证脚本,确认修复在线上真的生效。”


八、原则六:让知识自己生长

这一周我还做了一件事:审视自己的知识沉淀体系。

3 月 1 日我建立了每日自动生成知识卡片的机制。运行一周后发现三个问题:

  1. 输入源不完整:最有价值的学习发生在 OpenClaw 对话里(故障排查、修复决策),但卡片生成流程捕捉不到
  2. 只做单日提炼:同一类问题反复出现(如 launchd PATH 差异),但系统无法跨天识别模式
  3. 知识存了不消费:卡片存到目录后没有任何流程引用它

对应的改进是建立三级进化节奏:

级别 频率 产出 目标
微进化 每日 1 张知识卡片 捕捉当天最有价值的认知点
大进化 每周 原则性文档 跨天模式识别,提炼结构性认知
超进化 每月 知识体系重构 淘汰过时认知,合并散点为专题

微进化产出原材料(卡片),大进化产出结构(原则)。没有微进化,大进化没有素材;没有大进化,微进化只是日记。

本文就是一次“大进化”的产出——它不可能从任何单张卡片中生成。


九、检查清单

最后,如果你也在一个人运维个人项目,这里是一份可以直接用的检查清单。每个项目进入“运营期”(你开始依赖它的数据,开始给它写运维文档)时,花半天过一遍:

  • 所有用户数据写入路径:失败时是否保留?是否有提示?
  • 所有外部依赖调用:是否有 timeout?是否有 max inflight?
  • 关键链路:是否有至少一个 fallback?
  • 运行参数:是否按实际机器校准过(线程池、连接池、队列)?
  • 数据备份:是否覆盖所有重要数据?是否做过恢复演练?
  • 部署流程:是否有自动化的部署后验证?
  • 进程管理:挂了能不能自动重启?

过完之后再补代码,优先级比加新功能高。


十、小结

AI 让独立开发者拥有了以前小团队才有的开发速度,但也同时制造了以前小团队才会遇到的运维问题。

开发是一次性的,运维是永久性的。每上线一个新服务,就是签了一份永久运维合同。

速度是好事,但速度之后要主动补上被跳过的东西。六条原则——失败路径底线、容量基线、自愈优先、数据安全、分层验收、知识进化——本质上都是同一件事:让你的系统有能力在你不在的时候照顾好自己。

(完)

一周两炸

发表于 2026/03/07 | 分类于 AI专题

一周两炸

风格:叙事复盘体(Netflix/Stripe 工程博客)


3 月 2 日,星期一:十个 commit

一天之内,我给 ClawChat 的后端推了十个 commit。

这是一个聊天机器人项目——用户在 Telegram 上发消息,后端调用 OpenClaw(我自己搭的 AI agent 框架)处理请求,再把结果返回去。整个后端是那天从零搭起来的,用 AI 辅助开发,速度非常快。每次调通一个功能点就 commit 一次,十个 commit 到晚上全部上线。

那天的感觉很好。像一个人同时扮演了产品经理、后端工程师和 DevOps,而且每个角色都在高效运转。AI 帮我写了大部分代码,我做架构决策和最终验证。从构思到部署,整个链条在一天内闭合。

我没有写任何异常处理逻辑。没有加 fallback。没有检查服务器的容量参数。这些事情在当时看起来完全不紧急——功能还没跑通,谁会去想失败路径?

三天后我为此付出了代价。


3 月 5 日,星期四:ClawChat 不说话了

下午我发现 ClawChat 不回消息了。发什么都是同一句话:“暂时不可用”。

排查了一会儿,发现问题出在上游。ClawChat 的后端通过 HTTP 调用 OpenClaw,而 OpenClaw 的进程是通过 macOS 的 launchd 托管启动的。当天 launchd 重启了这个进程,但 launchd 环境下的 PATH 和我手动启动时不一样——它调用了一个错误版本的二进制文件,导致 OpenClaw 实际上没有正常运行。

HTTP 请求全部超时。ClawChat 的后端没有任何回退逻辑——上游不可达,它就直接返回一个固定文案。没有尝试 CLI 调用,没有尝试缓存,没有尝试降级,没有告警。静默地、优雅地、彻底地失败了。

修复本身不难。两步:修正 launchd 的 PATH 配置,加一个环境变量 OPENCLAW_CLI_FALLBACK_ENABLED 让 HTTP 失败时自动回退 CLI。

但修完之后我坐在那里想了一会儿。这个 fallback 逻辑应该在三天前就写好的。不,应该在 3 月 2 日那十个 commit 里的某一个就包含了。我当时为什么没写?

因为没有发生过。你不会给一个还没出过故障的系统写故障恢复逻辑——这是人类的一个结构性盲区。失败路径的回报是“什么都没有发生”,所以它在任何优先级排序中都会排在最后。


3 月 6 日,星期五上午:六个番茄消失了

ClawChat 的事还没消化完,番茄 App 出事了。

事情是这样的:番茄钟 App 的 token 过期了,需要重新登录。App 在重登流程里清除了本地缓存——包括一个叫 pendingSync 的数据结构。这个结构里存着 6 条已经完成但尚未同步到服务器的番茄钟记录。

清除 = 永久丢失。没有确认弹窗。没有警告提示。没有本地备份。6 条记录,大约 3 个小时的专注时间,安静地消失了。

我当时的第一反应是恼怒。第二反应是——我还记得那六个番茄分别是什么时候做的、做了什么。于是我打开 MySQL 客户端,手写 SQL 把它们一条一条补录回去。

补录成功了。但这件事让我后背发凉。成功的前提是三个条件碰巧同时满足:我还记得、数据量小到可以手动恢复、我会写 SQL。这三个条件任意一个不满足——比如丢了 60 个而不是 6 个,比如过了一周我才发现——数据就真的没了。

事后补录不应该是数据保护的手段。它是所有自动保护都失败后的最后手段。而我的系统里,它成了唯一的手段。


3 月 6 日,星期五下午:雪崩

番茄的事还在处理,后端彻底炸了。

番茄 App 的后端跑在阿里云一台 1 核 2GB 的 ECS 上,用的 Spring Boot + Tomcat。Tomcat 的默认线程池大小是 200——我当时设成了 120,觉得已经“调低了”。HikariCP 的连接池是默认值 10。

触发雪崩的直接原因是一条慢 SQL。这条 SQL 在正常情况下执行时间可接受,但当时数据库锁等待时间变长,单条 SQL 的执行时间从几十毫秒涨到了几秒。

然后是连锁反应:

  1. 慢 SQL 导致处理线程长时间阻塞
  2. 120 个线程迅速被占满
  3. 新请求全部排队等待
  4. 客户端没有退避逻辑,超时后立即重试
  5. 重试请求涌入,线程池更加堵塞
  6. 数据库连接池也被占满,新请求直接报错
  7. 系统进入完全不可用状态

整个过程大约十分钟。从第一条慢 SQL 到全面雪崩,十分钟。

修复过程里我学到了一个事实:对一台 1 核 CPU 的机器来说,120 个线程不是“调低了”,而是荒谬地高。单核 CPU 同一时刻只能执行一个线程,其余全在排队和上下文切换。合理值是 4 到 8 个。120 线程的 Tomcat 跑在 1 核机器上,就像一个只有一个窗口的银行叫了 120 个号——你以为叫得越多处理越快,实际上窗口一次只能服务一个人,其余 119 个人全在大厅里互相踩脚。

我从来没有想过要检查这个参数。在公司里,这是 SRE 或 DBA 的事。他们帮你做容量评估、帮你调参数、帮你设告警。等你一个人做项目时,你根本不知道有这层工作要做。


3 月 6 日,星期五晚上:数据裸奔

修完雪崩之后,我做了一件以前从来没做过的事:盘点所有项目的数据备份状态。

结果让我出了一身冷汗。

番茄的 MySQL 备份了,因为之前出过事。digital-assets 文档在 Gitee 上有 Git 备份。但 ClawChat 的对话数据——跑在腾讯云的 MySQL 上——完全没有备份。没有 mysqldump,没有快照,没有任何恢复手段。如果那台服务器的硬盘坏了,所有对话记录全量丢失。

OpenClaw 的本机配置和会话数据,备份状态不明。腾讯云服务器有没有开快照,我也不确定。

这就是“事故驱动型”数据保护的必然结果:出过事的地方有了防护,没出过事的地方一片裸奔。你以为自己是安全的,直到你花十分钟做一次盘点,发现到处都是洞。


3 月 7 日,星期六:清算日

第二天是周六。我花了一整天做了一件事:把这一周的所有痛点、修复过程和教训提炼成系统性认知。

不是写一篇“本周总结”那种流水账。是坐下来,把每一次刺痛拆开,问自己:这个问题是个案还是结构性的?如果是结构性的,最小化的防护原则是什么?

六个小时之后,出来了六份文档:

一、失败路径三条底线。 不追求覆盖所有失败路径——那是不可能的——但三条底线必须做到:用户数据不能静默丢失,上游变慢时不要把自己拖死,关键路径至少有一个 fallback。

二、单核小机器容量基线。 一张速查表:Web 线程池 4–8,DB 连接池 3–5,请求超时 10–30 秒,连接泄漏检测 10–15 秒。不是精确值,但比“框架默认值”安全一百倍。

三、自愈优先原则。 一个人运维时,自愈比监控更有价值。进程挂了自动重启,请求超了自动拒绝,上游不可达自动回退。给 AI 提需求时,默认先问“能不能做成自愈的”。

四、数据安全三级台阶。 第一级补齐空白(有 > 无),第二级确认有效(能恢复 > 有备份),第三级自治运转(无需人工干预)。手动补录是最后手段,不是常规手段。

五、人机协作分层验收。 AI 验代码正确性、功能可用性、线上是否真实生效。人只验体验判断——用起来顺不顺、交互合不合理、下一步该做什么。AI 说“完成了”不等于真的完成了,需要部署后自动验证。

六、知识体系三级进化。 每日微进化(自动生成知识卡片),每周大进化(跨天复盘提炼原则),每月超进化(淘汰过时认知、合并散点为专题)。微进化产出原材料,大进化产出结构。没有大进化,微进化只是日记。


后记:速度与债务

回头看这一周,我想说的其实只有一件事。

AI 让开发变快了。这是真的。一个后端服务一天上线,一套知识体系一周建起来,这在两年前不可想象。但“跑通”和“跑稳”之间的差距没有被缩小。AI 加速了代码编写,但测试、环境适配、容量校准、失败路径设计,这些东西没有被等比例加速。

结果就是:你以三到五倍的速度制造系统,也以三到五倍的速度制造运维债务。每上线一个新服务,就是签了一份永久运维合同。开发时的兴奋会掩盖运维时的痛苦——写代码有即时反馈,运维的回报是“什么都没坏”。

3 月 2 日那十个 commit 的兴奋感,到 3 月 6 日的雪崩面前一文不值。

我不是要说“别用 AI”或者“慢下来”。减速是反人性的。我想说的是:速度之后,要有一个主动补课的环节。每个项目从“跑通了”进入“我开始依赖它”的阶段时,花半天时间,过一遍失败路径、容量参数、数据备份、自愈机制。

半天时间。能防住几个月的痛。

这一周我丢了六个番茄、经历了一次雪崩、发现数据在裸奔。作为交换,我得到了六份原则性文档和一个核心认知:

速度是杠杆。杠杆放大的不只是产出,也是风险。知道自己在负债,比负债本身更重要。

(完)

从vibe coding到Claws:Karpathy在2026年初到底看见了什么

发表于 2026/03/07 | 分类于 AI专题

风格参考:万维钢(《精英日课》作者)—— 跨学科引证,框架式拆解,加粗关键洞察,用数据和类比交叉验证每个论点;局部借用 Paul Graham 的短句节奏感。

引子:追 Karpathy,追的不是热词

如果你只是偶尔刷到 Andrej Karpathy 的名字,你可能觉得他就是那个特别会造词的人——“Software 2.0”“vibe coding”,每隔一阵蹦出一个能传播的短语。

这个印象不算错,但严重不够。

Karpathy 真正厉害的地方,从来不是“他造的词是不是永远正确”,而是他往往能在一个拐点刚刚到来、行业里大多数人还只有朦胧感觉的时候,先把那个拐点压缩成一句能记住、能传播、能继续推演的话。这是一种非常稀缺的能力:把模糊的体感变成清晰的公共语言。

过去如此——从“Software 2.0”到“vibe coding”。现在也如此——从“agentic engineering”到“Claws”。

2025 年 12 月到 2026 年 2 月之间,他的更新不只是多了几个新名词。如果你把他这几个月在 X 上的短帖、GitHub 上的新项目、以及零星访谈串起来看,会发现一张越来越清晰的地图:程序员工作的重心正在整体上移——从手写代码,到组织上下文、分派任务、设计验证、审查结果,再到多 agent 系统的编排。

这不是一条线索,而是一整条主线。下面我们一层一层拆。


一、底盘:2025 年末那篇综述里埋下的判断

要读懂 Karpathy 在 2026 年初的兴奋,得先回到 2025 年 12 月 19 日他发的那篇《2025 LLM Year in Review》。那是他至今最后一篇长文,也是后来很多判断的总纲。

里面有两个关键观察。

第一个:他不再把 LLM 看成“动物”,而更像“幽灵”。 一种有明显能力、不均匀智能、又带着强烈“锯齿感”的系统。它在某些维度上超过人类,在另一些维度上又脆弱得离谱。这个隐喻很重要,因为它决定了他后来如何看待 coding agents——它们不是成熟员工,而是某种需要被召唤、被约束、被分派、被反复校验的非人式智能。

第二个:像 Cursor 这样的产品,揭示的不是“更好补全”的小升级,而是一整层新的 LLM 应用范式。 这一层的关键不只是模型本身,而是上下文工程、编排、应用专用 GUI、自治程度滑杆。真正有价值的东西不在“会不会生成几行代码”,而在于能不能把模型置于一个合适的操作环境里,让它带着足够上下文、工具、权限和反馈循环去工作。

他还专门谈到 Claude Code,把它视为第一个真正让他感到“AI 住在你电脑上”的东西。他甚至直言,OpenAI 当年把 Codex 的优先级顺序弄反了——先去做云端容器里跑的编码系统,而不是先做一个真正运行在开发者本地环境里的 AI 助手。

这句话在 2026 年初回头看,含义比当时更大。因为他后来对本地 agent、CLI、NanoClaw、“被小幽灵附身的设备”的兴趣,根全埋在这里。


二、从谨慎到震动:一个原本不全信 agent 的人改口了

要理解这波变化的分量,必须记住一件事:Karpathy 在几个月前并没有这么乐观。

2025 年 10 月,他在一次公开对谈里谈“year of agents”时,反而相当保守。他给 agent 下了一个更严格的定义:不是偶尔能跑个 demo 的系统,而是像一个实习生甚至员工一样,能在复杂环境中长期独立完成任务。按这个标准,他当时的判断是——真正的 agent 可能还需要大约十年。

他甚至点名说,coding agents 当然已经能做不少样板工作,但对 nanochat 那种“智力密度高、精度要求高”的仓库,他不觉得 agent 已经足够好。

这段话今天回看极其重要。它说明 Karpathy 最近的兴奋,不是“逢新必吹”的兴奋,而是在原本谨慎的基线之上发生了体感性变化。 如果连一个原本相对怀疑的人,都在 2025 年 12 月到 2026 年 2 月之间持续改口,那么这波变化就值得认真对待。

转折开始于一种“落后感”。

2025 年 12 月 26 日,他发了一条动态:自己从没像现在这样觉得在编程这件事上“落后了”。后面跟着一个判断:程序员的职业正在被“dramatically refactored”。如果能把过去一年里新出现的那些东西真正串起来用,自己的效能可能会强十倍。

这不是对单点能力的赞叹,而是对一个新抽象层突然成形的惊讶。

他列举的新对象更有意思:agents、subagents、prompts、contexts、memory、modes、permissions、tools、plugins、skills、hooks、MCP、LSP、slash commands、workflows……这串名词像一个杂乱工具箱,但他想表达的恰恰是:软件工程的前台对象已经变了。程序员不再只是面对“代码文件 + 编辑器 + 编译器”,而是开始面对一整套由代理、上下文、记忆、权限、工具协议和工作流组成的新运行环境。

用一句话说:编程活动的基本单位正在从“写代码”转向“调度智能”。


三、工作流翻转:两个月内的“相变”

2026 年 1 月 26 日左右,Karpathy 发出了一串“random notes from Claude coding”。这是理解他最近几个月最核心的一手材料。

里面最关键的一句:他自己的工作流在短短两个月里,从 80% 手写/自动补全 + 20% agents,迅速翻转成 80% agents + 20% 修改收尾。 他还说,自己现在“mostly programming in English”。

这不是修辞游戏。这是在描述劳动重心的真实移动。

物理学里有一个概念叫“相变”——水从液态到固态的转变不是匀速发生的,而是在温度到达某个临界点后突然切换。Karpathy 这一轮描述更像相变而不是渐变:前面很长一段时间,coding agents 都像不稳定的实验玩具,能偶尔惊艳,却无法可靠纳入主流程;到了 2025 年 12 月前后,某些模型能力、工具链和使用方式叠加到一起,突然跨过了可用阈值,从“演示级”变成“工作级”。

他甚至直接说,这是他大约二十年编程生涯里最大的工作流变化,而且几乎是在几周之内发生的。

翻译成人话:过去你在编辑器里“写”;现在你越来越像在给一批高智力但不稳定的实习生“分任务”。 你要提供目标、上下文、边界、测试与回滚机制,然后等它交付,再做判断、审阅和修补。代码依然重要,但它不再是程序员最稀缺的产出。真正变得更稀缺的,是把问题说清楚、把执行过程包起来、把结果验明白的能力。


四、新的错误谱系,与为什么仍然是巨大净提升

Karpathy 没有把这件事描写成完美自动化。恰恰相反。

他对 coding agents 的问题说得非常具体:过去人类手写代码时,常见错误往往是语法型、低级型的;而现在错误越来越多地变成更微妙的概念性错误——模型整体思路听起来对、代码也能跑,但在架构边界、业务假设、隐含约束和权衡取舍上出现偏差。这种错误比拼写错误更危险,因为它们更像“看起来很合理的误导”。

他点出了一组极有代表性的 agent 失真:

  • 擅自做假设,不主动请求澄清。
  • 不主动暴露上下文中的冲突和 tradeoff。
  • 过于顺从、过于“sycophantic”——几乎不会像一个好同事那样在关键地方顶回来。
  • 喜欢过度工程化:膨胀抽象层、堆 API、留下死代码。

认知科学家 Gary Klein 研究过专家决策,发现优秀专家最重要的能力之一是**“及时发出异议”——在团队即将走上错误路径时主动喊停。LLM 恰恰缺失这种能力。它的危险不只是“笨”,而是“太会顺着你往前跑”,以至于它在错误方向上也能表现出极强执行力。“流畅输出”被误判成“正确理解”——这是 agent 时代最隐蔽的风险。**

但有意思的是,正是在列完这么多毛病之后,Karpathy 仍然给出一个非常明确的判断:这是净巨大提升,而且他已经很难想象再回到纯手写的旧模式。

这个结论一开始看似矛盾,但其实非常合理。原因在于,coding agents 真正带来的不只是把原有流程加速 20%,而是让一些原本“不值得做”“懒得做”“不会做”的事情第一次进入了可行区间。

他特别强调了一个人类很难复制的维度:tenacity——韧性与持续折腾的能力。 人会累、会烦、会因连续碰壁而气馁。Agent 不会。它可以在 SSH、依赖、部署、服务、日志、回归测试之间一遍遍试,直到某个长链条被打通。他举过一个具体例子:让 agent 在本地机器上一路完成登录、配 key、跑 vLLM、下载并 benchmark 模型、起服务、做 dashboard、写 systemd、回传报告,整个过程约三十分钟。

经济学家 Tyler Cowen 有一个判断:新技术真正的威力往往不是“让老任务更快”,而是“让新类别的任务变得可行”。 Karpathy 的体验完美印证了这一点——提升不只体现在老任务的吞吐量上,也体现在你愿意探索的任务空间变大了。许多过去得压箱底几周的想法,开始可以在几个晚上里先弄出原型。


五、三个词的递进:从代码到编排

外界最熟悉 Karpathy 的流行语,也许还是“vibe coding”。那个词之所以会火,是因为它精准描述了第一波大众体验:你不再逐字逐句写代码,而是带着一种半即兴、半对话式的感觉,让 AI 帮你把东西凑出来。它标记了一个文化门槛:从“代码必须由程序员写”到“代码可以由会说需求的人协作生成”。

但到了 2026 年初,Karpathy 显然觉得这个词不够了。

原因很简单:当工具从“你随便聊聊,它给你拼出个小玩意儿”进化到“它能在数十分钟里持续完成长链条工程任务”,工作的本质就变了。此时最大的挑战不再是“敢不敢把手放开”,而是如何设置上下文、分解子任务、选择工具、调权限、看日志、做验证、控回滚、管并行。这些工作已经超出了“凭 vibe 玩一玩”的层面,进入了一种需要方法论、经验和审美的工程活动。

所以他开始用**“agentic engineering”**。这个词要强调两层意思:一层是“agentic”——你并不是 99% 时间都在直接写代码,而是在调动代理执行;另一层是“engineering”——这不是完全无门槛的自动化,反而需要更高层次的专业判断、创造性约束和科学式验证。

Karpathy 不是在宣布“工程师不重要了”,而是在说:工程师的重要性正在上移,且形式正在变化。 写代码本身变便宜了,高质量地组织代码生成与验证变贵了。

然后到了 2 月下旬,他又把视线往上抬了一层——“Claws”。

他专门买了一台 Mac mini 来折腾 Claws。这个动作本身很有象征意味:他不是只在抽象层面谈概念,而是真的把一台物理机器当成实验场,去想象“在个人硬件上常驻的 agent 编排系统”会长什么样。

Karpathy 对 Claws 的定义很清楚:它是叠在 LLM agents 之上的新层,处理的不是单次回答,而是 orchestration、scheduling、context、tool calls、persistence。如果说单个 coding agent 解决的是“一个代理怎样在给定上下文里执行任务”,那么 Claw 关注的是“多个代理、多个工具、多个任务、多个时间尺度,怎样被持续组织起来”。

管理学家 Henry Mintzberg 把组织的协调机制分成五种,其中最高阶的一种叫“相互调适”(mutual adjustment)——成员之间通过非正式沟通实时协调。 Claws 要做的,本质上就是为一群 agent 建立这种高阶协调机制。行业竞争不再只在模型能力上,也不只在 IDE 内嵌补全上,而会越来越落在多代理运行时与长期编排层。

三个词放在一起,你会看见一条清晰主线:vibe coding 描述的是“代码生成”变轻了;agentic engineering 描述的是“工程师角色”向上移了;Claws 描述的是“代理组织层”开始成为新的竞争焦点。从代码,到工程,到运行时编排——层层递进。


六、旧技术的新生命,与 Builder 的底色

Karpathy 最近还有一个表面“逆流”的判断:他开始更明确地谈 CLI 的价值。

命令行恰恰因为是“legacy technology”,所以对 AI agents 特别友好——它天然就是文本接口,规则相对清晰,输入输出边界明确,自动化历史悠久,代理几乎可以原生使用它。过去十年软件行业偏爱 GUI 和所见即所得,但在 agent 时代,这反而成了劣势。对人友好的界面,不一定对机器友好;对机器友好的界面,往往具备良好的文本可操作性、组合性和可脚本化特征。

这和他在 2025 年 YC 演讲里讲的“Build. For. Agents.”一脉相承。大前提是我们已经进入 Software 3.0 阶段:自然语言成为新的编程界面,软件不再只被人点击,也越来越多地被机器代理调用。最有竞争力的软件,不是只有漂亮 GUI 的软件,而是既能服务人,也能被 agent 稳定调用的软件。

于是你发现,很多“旧东西”——CLI、容器、日志、文本配置、简单脚本、明确的 I/O 边界——在这个时代突然重新变得性感。不是因为人类退回过去,而是因为 agent 需要一个可以可靠行动的环境。

这也解释了他对 NanoClaw 的偏爱。NanoClaw 核心引擎只有约 4000 行代码,默认跑在容器里,把“skills”更接近做成配置,追求“最大可分叉性”。这套偏好和他在 microgpt、nanochat 上长期表现出来的审美完全一致:能小就小,能看清楚就看清楚,能 fork 就 fork,能本地跑就别先云端化。

说到 nanochat,它的进展本身就很能说明问题。仓库 README 显示,截至 2026 年 3 月 4 日,在一台 8×H100 节点上达到超过 GPT-2 基线的训练时间已经压到约 2.02 小时,成本约 48 美元(spot 则低至 15 美元左右)。而 2019 年 OpenAI 训练 GPT-2,大约用 32 个 TPU v3 跑了 7 天,估算成本在数万美元量级。成本降幅达数百倍。

这类变化和他对 coding agents 的兴奋不是两条线:一条讲“执行层开始可用”,另一条讲“底层模型实验与迭代的门槛在快速下降”。两者叠加,才构成他“软件工程正在重构”的强烈感受。


七、不要神化,也不要低估

把这些动态串起来后,最常见的误区是走向两个极端。

过度乐观的人会理解成“以后程序员只要讲中文英文就行了”。立刻反弹的人则抓住 agent 的各种错误,得出“这不过是新一轮 hype”的结论。

Karpathy 自己其实给了比这两端都更成熟的位置:他一边说这是二十年来最大的工作流变化,一边又明确说“no need for IDE”之类的狂热和“agent swarm”之类的夸张,现在都还太过头。变化是真的,但宣传语常常跑得比现实更快。

更准确的理解应该是:coding agents 在 2025 年 12 月前后跨过了一个实用阈值,使得“代理式工程”第一次大规模进入主流程。但这个新流程并不是自动稳定的——它需要高度结构化的输入、清晰的上下文和强验证能力,尤其适合那些能够被明确规格化、能够回放日志、能够自动化测试、能够在真实反馈里闭环的任务。

它更像一台能力很强但需要良好工装夹具的机器,而不是一个可以随便丢进去任何模糊需求的魔法盒子。

从团队层面看,这波变化最直接的后果,可能不是“谁先不用写代码”,而是谁先建立起一套适合 agent 工作的工程基础设施:更明确的仓库结构、更完备的测试、更好的日志和可观测性、更严格的权限边界、更可调用的 CLI、更标准化的工具接口。没有这些,agent 只会把原有的混乱放大;有了这些,agent 才可能把人的高层意图快速转成可运行结果。

Karpathy 迷恋的,从来不是无秩序的自动化,而是在良好约束中的高杠杆自治。


结语:一张从底到顶的栈式地图

最后值得记住的,不是某个单独词汇,而是一个三层结构。

第一层是模型层: 更强的推理、代码和工具使用能力,让代理终于“基本可用”。

第二层是 agent 层: 单个代理能够在较长链路中执行、调试、修复、再试。

第三层是 Claw / 编排层: 多个代理、多个工具、多个时间尺度与长期上下文如何被组织起来。

Karpathy 过去几个月几乎把每一层都碰了一遍。于是他的观察不再像零碎感想,而像一份从底到顶逐渐成形的栈式地图。

如果一定要用一句话概括他最近的动态:他不是在宣布“AI 开始替你写代码”,而是在宣布软件生产关系开始被重写。 在旧秩序里,代码是稀缺产出,程序员的价值主要体现在亲自生产代码的能力上。在新秩序里,代码越来越便宜——甚至便宜到会出现他自己担心的那种“slopacolypse”——于是最稀缺的东西开始变成判断力、上下文管理、系统边界意识、测试设计、回滚能力和长期责任归属。

代码仍然重要。但代码不再自动等于价值。

人正在从低层执行中部分抽离,转而负责更高层的意图、组织与责任。而那,才是这轮变化真正的开始。

速度的债务

发表于 2026/03/07 | 分类于 AI专题

速度的债务

风格:Paul Graham(essay 体)


上周我丢了六个番茄。

不是超市里的番茄,是番茄钟——我用自己写的 App 记录的六段专注时间。它们因为一个 token 过期的 bug,在重新登录时被静默清除了。永久丢失,无法恢复。

六个番茄钟,大约三个小时的工作记录。放在任何规模的公司里,这不算事故。但对我来说,这件事的刺痛程度远超它的实际损失。

因为它暴露了一个我一直在回避的问题。


我现在同时运维着五个个人项目:番茄 App、ClawChat、OpenClaw、喝水提醒、还有一套数字资产知识体系。全部用 AI 辅助开发。

AI 确实让我快了很多。一个后端服务,从零到上线可以压缩到一天——ClawChat 的后端就是 3 月 2 日一天之内推了十个 commit 上去的。那种速度带来的兴奋感是真实的:你觉得自己像一个全栈团队,什么都能做,什么都在推进。

但速度有一个性质,它不会告诉你自己是危险的。

3 月 5 日,ClawChat 开始返回“暂时不可用”。HTTP 上游不可达,系统直接给用户一个固定文案,没有任何自动回退。3 月 6 日,番茄后端雪崩了——一台 1 核 2GB 的阿里云小机器,用着 Tomcat 默认的 120 个线程,一条慢 SQL 触发锁等待,客户端疯狂重试,线程池耗尽,整个服务躺平。

两天,两次事故,两个不同的项目。


这两次事故表面上毫无关系。一个是聊天工具的上游不可达,一个是番茄钟的后端雪崩。但当你把它们放在一起看,会发现根因完全一样:我只设计了 happy path。

失败路径从来没有被当作一等公民。

这不是偶然的疏忽。如果你仔细想,会发现失败路径被忽略是一个结构性问题,而不是个人懒惰的问题。

写 happy path 有即时反馈——功能跑通了,你能看到它工作。写失败路径的回报是什么?什么都没有发生。你花了半天写了一堆异常处理逻辑,最好的结果是它永远不被触发。这种激励不对等会让所有人——不管多有经验——在时间紧张时本能地跳过失败路径。

而 AI 让这个倾向变得更严重了。因为 AI 进一步压缩了 happy path 的开发时间,让你觉得“功能已经做完了”的时间点来得更早。但失败路径不能被同比压缩——它需要你理解系统的边界条件,需要你被伤过才有真实体感。读十篇 best practice 也不如亲自丢一次数据。


速度创造了一种特殊的债务。

每上线一个新服务,你就签了一份永久运维合同。开发是一次性的,运维是永久性的。AI 把开发速度提了三到五倍,但运维面积也跟着扩大了三到五倍。

区别在于:开发时你有 AI 帮你写代码,兴奋感和进展感是实时的。运维时你一个人,凌晨三点服务挂了没人帮你看,你甚至可能在睡觉。

一天十个 commit 推上去时的那种感觉——“我好高效,我好强大”——实际上掩盖了一个事实:你刚刚给自己制造了一个需要永久维护的东西,而你对它的失败模式一无所知。

公司里有 SRE、有 oncall、有混沌工程帮你兜底。个人项目呢?没有人帮你兜。你就是 SRE,你就是 oncall,你也是唯一的用户。


我从这一周的事故里学到的最有用的一件事,不是“写更多测试”或“加更多监控”。

是这个:自愈优先于监控。

一个人运维的时候,告警是没有用的。告警来了你可能在睡觉,可能在开会,可能在另一个项目的深度工作里。你不可能 24 小时盯着。所以正确的问题不是“怎么更早发现问题”,而是“问题发生时能不能自动恢复”。

进程挂了?与其发通知等你来重启,不如让 systemd 自动拉起来。请求堆积了?与其发通知等你来限流,不如在代码里设好 max inflight,超了直接拒绝。上游不可达?与其发通知等你来排查,不如自动 fallback 到 CLI 调用。

以后给 AI 提运维需求时,默认先问一句:这个能不能做成自愈的?而不是先问怎么监控。


另一个刺痛来自那台 1 核小机器。

番茄后端跑在阿里云一台 1 核 2GB 的 ECS 上。Tomcat 默认线程池 200,HikariCP 默认连接池 10。这些默认值是面向多核服务器设计的——没有哪个框架会在文档里提醒你“如果你是单核机器请把线程数调到 8”。

我从来没改过这些参数。它们在正常情况下确实够用。直到一条慢 SQL 出现,线程全部阻塞,连接池耗尽,客户端重试把问题放大十倍,整个服务雪崩。

这是一个盲区。在公司里有 DBA 和 SRE 帮你做容量评估,你甚至不知道这件事需要有人做。等你自己做项目时,根本不会想到要检查线程池的默认值。

补上这个盲区其实只需要几分钟。单核机器,Web 线程池 4 到 8 个,DB 连接池 3 到 5 个,请求超时 10 到 30 秒。就这么几个数字。把运行参数从“默认没碰过”变成“我看过、我定的”就够了。

默认值不是安全值。这句话值得贴在显示器上。


这周还有一件小事让我警觉。

AI 给番茄后端写了一个 TimeConfig 的修复方案。测试通过了,AI 说“修复完成”。我信了,直接上线。结果发现改了一半。

这件事不大,但它揭示了人和 AI 协作中的一个缝隙:AI 说“完成了”不等于真的完成了。

我当前的工作流是:AI 写代码,AI 跑测试,AI 说完成,我上线。中间没有验收环节。这在 happy path 上没问题,在 edge case 上就会漏。

所以我给自己定了一个规则:以后让 AI 做修复或部署时,在需求最后加一句——修完之后,写一个部署后自动验证脚本,确认修复在线上真的生效。

代码正确性让 AI 验。功能可用性让 AI 验。线上是否真实生效也让 AI 验。人只做最后一件事:判断体验好不好——这个功能用起来顺不顺,这个交互逻辑合不合理,下一步最该做什么。

AI 没有“作为用户使用产品”的真实感受。你作为唯一的真实用户,体验判断是不可替代的。


数据丢了之后我手写 SQL 把六个番茄补录回去了。补录能成功,是因为三个条件碰巧满足:我还记得、数据量小、我会写 SQL。这三个条件任意一个不满足,数据就永久消失。

这让我意识到,我对数据的保护方式是事故驱动的——番茄数据出过事所以备份了,ClawChat 还没出过事所以还没备份。不是设计驱动的。

盘点下来,ClawChat 的对话数据目前是裸奔状态。没有备份,没有恢复演练,一旦出事就是全量丢失。

“有备份”也不等于安全。很多人备份了但从来没恢复过,等真出事才发现备份是坏的。真正的数据安全有三级台阶:有总比没有好,能恢复比有备份好,自治运转比依赖人工好。


写到这里,我意识到这一周真正发生的事情不是“两次事故”。是一次认知升级。

从这些痛里,我提炼出了六份原则性文档。失败路径的三条底线。单核机器的容量基线。自愈优先原则。数据安全防护层次。人机协作验收模型。知识体系的进化机制。

这些文档不是规划出来的。它们是被痛出来的。每一篇都对应一次刺痛。

AI 时代最大的陷阱可能不是“AI 会不会取代你”,而是 AI 让你太快了——快到你来不及建立与速度匹配的判断力。你用一天时间上线一个服务,但你对它的运行环境、失败模式、容量极限的理解还停留在零。

速度是杠杆,但杠杆放大的不只是产出,也是风险。

唯一的解药不是减速——减速是反人性的。解药是在速度之后,主动补上那些被跳过的东西。每个项目进入运营期时,花半天时间过一遍:数据写入路径失败时会怎样?外部依赖有没有超时?关键链路有没有 fallback?运行参数是不是默认值?

半天的检查,能防住几个月的痛。

速度不是问题。不知道自己在负债,才是问题。

Java程序员还需要学Tomcat吗

发表于 2026/03/05 | 分类于 随笔文章

1

很多 Java 程序员都有一个共同的困惑:Tomcat 到底还要不要学?

大家都知道 Tomcat 很重要,也知道 Spring Boot 默认内嵌了它。但如果你日常做的是 2B 项目,用户量不大,QPS 也不高,主要就是写接口、对接系统、处理数据——花大量时间去研究 Tomcat,真的有必要吗?

我最近梳理了一下这个问题,发现它背后牵出了一整条概念链:Web 服务器是什么,Servlet 容器是什么,Servlet 和 Controller 什么关系,Java EE 和 Jakarta EE 又是怎么回事。这些概念很多人似懂非懂,但只要顺着“Tomcat 要不要学”这个问题往下捋,它们就全串起来了。

2

先说结论:Tomcat 不需要深挖,但不能完全不懂。

如果你的项目是典型的 2B 系统,业务逻辑多,并发量低,那确实没必要把 Tomcat 当成主攻方向。你大概率不需要去读它的源码,不需要研究连接器的每个参数,也不需要深入 NIO 模型和线程池的实现细节。

但 Tomcat 不能完全忽略。因为 Spring Boot 只是把它“内嵌”了,不是把它“消灭”了。

你的应用仍然跑在 Tomcat 上面。HTTP 请求仍然要经过它,线程管理、连接管理、请求的生命周期,这些事情仍然由它负责。只不过你不再需要手动部署 war 包、手动配置 server.xml 而已。

换句话说,Tomcat 从“你要直接操作的东西”,变成了“你必须理解其存在的底座”。

所以更准确地说:Tomcat 不需要学到专家级,但至少要学到理解系统运行机制、能排查问题、能和别人有效沟通的程度。

3

要理解 Tomcat,先得搞清楚几个基本概念之间的关系。

很多人对 Tomcat 的第一印象是:它是一个 Web 服务器,负责接收 HTTP 请求,然后把请求转给 Java 应用。方向是对的,但可以再精确一点。

Tomcat 其实有两层身份。

第一层是 HTTP 服务器。这一层负责网络层面的事情:监听端口、建立连接、解析 HTTP 协议、管理 keep-alive、处理超时、把字节流读进来再写回去。

第二层是 Servlet 容器。这一层负责 Java 的事情:把 HTTP 请求包装成 Java 对象(HttpServletRequest 和 HttpServletResponse),然后按照一套标准规则调用应用代码,最后把结果写回给客户端。

也就是说,Tomcat 做的不只是“转发”,它做的是一整套从网络协议到 Java 对象的桥接工作。

4

说到 Servlet 容器,就必须解释一下 Servlet 到底是什么。

很多人把 Servlet 理解成“某个类”或者“某种老旧的写法”,其实不准确。Servlet 更准确的定义是:Java Web 应用暴露给容器调用的一套标准接口。

这里最容易搞反的一点是:不是 Servlet 去调用 Tomcat,而是 Tomcat 去调用 Servlet。

打个比方。你去餐厅吃饭,餐厅有一套点菜流程:你看菜单、选菜、告诉服务员。这个流程是餐厅定的,不是你定的。你作为顾客,只需要“实现”点菜这个动作就行了。

在 Java Web 世界里,Tomcat 就是餐厅,Servlet 就是你按照餐厅规则提供的那个“点菜动作”。容器掌握调度权,应用提供处理逻辑。这在软件工程里叫做“回调”——运行时由平台来调你,而不是你主动去调平台。

一句话总结:Servlet 是应用暴露给容器的入口接口,Tomcat 是负责运行并调用这些入口的容器实现。

5

理解了 Servlet,就可以来看 Spring MVC 做了什么。

在 Spring MVC 时代,我们不再手写一堆 Servlet 了。所有请求都会先进入一个叫 DispatcherServlet 的东西。

很多人第一次看到这个名字会疑惑:它也只是一个 Servlet 啊,凭什么整个系统的请求都给它?

原因在于它的设计模式。DispatcherServlet 是一个“前端控制器”(Front Controller)。传统模式下,一个 URL 对应一个 Servlet。而 DispatcherServlet 把所有请求先收进来,然后在框架内部根据 URL、HTTP 方法、参数、Header 等信息,再分发到具体的 Controller 方法上。

所以在 Spring MVC 里,真正面对 Tomcat 的不是你写的业务代码,而是 DispatcherServlet。你的 @RestController、@Controller 方法,其实不是 Servlet,它们是 DispatcherServlet 内部再分发出来的业务处理单元。

这就是为什么很多 Java 开发者“感觉不到 Servlet 的存在”。你平时写的是 Controller,但 Controller 的下面仍然是 Servlet 模型,只是被 Spring 封装起来了。

6

那么,在 Spring 出现之前,Java Web 是怎么工作的呢?

最原始的写法是这样的:你自己写一个类,继承 HttpServlet,重写 doGet、doPost 方法。你要自己从 HttpServletRequest 里取参数,自己解析输入流,自己设置响应头,自己往 HttpServletResponse 里写内容。然后在 web.xml 里配置 URL 和 Servlet 的映射关系。

后来 Servlet 规范升级了,可以用 @WebServlet 注解来做映射。再后来,Spring MVC 出现了,你只需要用 @RequestMapping 就能把请求映射到一个普通的 Java 方法上。

你会发现,这么多年 Java Web 开发的主线从来没变过:请求匹配到一个处理器,执行逻辑,返回响应。

变化的只是抽象层级。早期你直接操作 Servlet,后来用注解注册 Servlet,再后来用 Spring 把请求映射到方法。映射的本质没变,只是越来越细、越来越方便。

7

所以 Spring MVC 到底厉害在哪里?很多人说“注解比 XML 方便”,这个说法没错,但远远不够。

Spring MVC 真正做的事情是:把 Web 编程从“类级别”提升到了“方法级别”。

在 Servlet 时代,一个 URL 通常对应一个类。你需要在类里面自己区分不同的逻辑。到了 Spring MVC,映射粒度细化到了方法级别。你可以很自然地写出 GET /orders/{id}、POST /orders、PUT /orders/{id},每个接口就是一个普通方法。

除此之外,Spring MVC 还系统性地接管了大量脏活累活。

以前你要自己从 request 里取参数、自己判断类型、自己解析 JSON、自己设置状态码。现在用 @RequestBody、@RequestParam、@PathVariable 就能自动完成。

以前一个异常抛出来,怎么返回给前端要自己控制。现在用 @ControllerAdvice 就能统一处理。

以前你想给所有请求加日志、鉴权、审计,要自己写 Filter 或者硬编码在 Servlet 里。现在有 Filter、Interceptor、AOP 等多种拦截能力可以组合使用。

Spring 的本质不是“更方便”,而是把 Web 开发从底层协议编程,推进到了更接近业务模型的层面。

8

理解了 Tomcat 和 Spring 的关系之后,还剩一个经常让人困惑的概念:Java EE。

很多人听到 Java EE 就觉得它很抽象,像是某种“大而空”的历史名词。其实用工程师熟悉的话说,它就是一份接口合同。

所谓“规范”,就是一份公开的标准文档,规定了要有哪些接口、哪些类、它们该怎么表现、生命周期是什么、异常怎么定义。规范本身不是一个能运行的软件,它是一套标准。然后不同的项目去实现这套标准。

打个比方,4G 标准规定了通信协议和行为方式,不同厂商去做基站和手机。只要遵循标准,就能互通。Java 世界里的规范也是这样:规范负责定义“应该怎样”,实现负责回答“具体怎么做”。

Java SE 是 Java 的标准版,包含语言、JVM、基础类库。Java EE 则是建立在 Java SE 之上的一组面向企业开发的标准能力,比如 Servlet、JPA、Bean Validation、JAX-RS 等等。

它不是“更强大的 JDK”,也不是什么“企业版安装包”。它是一组标准接口的集合。

所以你下载一个 JDK,拿到的是 Java SE 的实现。而 Java EE 里的那些能力,是由 Tomcat、Hibernate 这些项目来实现的。Servlet 规范由 Tomcat 实现,JPA 由 Hibernate 实现,Validation 由 Hibernate Validator 实现。Spring 则在这些实现之上,再做了更高级的封装。

9

这几年升级 Spring Boot 项目的人,肯定都遇到过一个变化:代码里的 javax.* 变成了 jakarta.*。

比如 javax.servlet 变成了 jakarta.servlet。

这个变化的原因不是技术上有什么大突破,而是治理权发生了变化。

Java EE 原来归 Oracle 管,后来 Oracle 把它转移到了 Eclipse 基金会。但 javax 这个命名空间的使用权没有一起转移。Eclipse 基金会拿到了规范的演进权,却无法继续使用 javax 这个名字。

于是只能做一次断代式迁移:Java EE 改名为 Jakarta EE,命名空间从 javax.* 全面转向 jakarta.*。

这就是为什么 Spring 6 / Spring Boot 3 升级时,最明显的变化不是某个功能特性,而是一大堆包名从 javax 变成了 jakarta。Tomcat 10 及之后的版本,也全面站在了 Jakarta 体系上。

10

理解了这条线之后,很多人还会追问一个问题:Tomcat、Spring 这些项目,为什么能活这么多年?

答案不是“没有挑战者”,而是它们积累了大量的稳定性和生态惯性。

Tomcat 之所以难以被动摇,不是因为它技术上绝对领先,而是因为它在企业级 Java Web 场景里长期扮演了一个非常稳定、非常可预期的角色。对于大量低并发、重业务、重兼容的系统来说,替换 Tomcat 带来的收益,远远小于替换它带来的风险。

Spring 也类似。它的优势不只是功能多,而是在依赖注入、Web、事务、数据访问、测试这一整套企业开发体验上,形成了巨大的完整性。

这些项目能持续演进,也跟治理方式有关。Tomcat 属于 Apache 基金会,有成熟的项目治理、发布机制和安全响应体系。Spring 则是公司主导型开源,由稳定的核心团队持续投入。

真正能活很多年的基础设施,不只是代码写得好,还得有持续演进的组织能力。

11

最后回到最初的问题。

对一个做 2B 项目、低 QPS、以业务开发为主的 Java 程序员来说,Tomcat 最合适的学习深度不是“专家级”,而是“理解运行机制级”。

你需要知道的是这些事情:

Tomcat 既是 HTTP 服务器,也是 Servlet 容器。Servlet 是应用暴露给容器调用的标准入口。Spring MVC 没有绕开 Servlet,而是通过 DispatcherServlet 把 Servlet 模型进一步抽象成了 Controller 模型。从过去到现在,Web 开发的本质都是请求映射,只是映射粒度和工程能力越来越强。Java EE / Jakarta EE 是一组企业标准规范,Tomcat、Hibernate 是这些规范的实现者。

理解到这个层面,你就具备了非常扎实的底座认知。

你不一定会去调 Tomcat 的线程参数,不一定会去研究连接器实现,但你会知道一个请求是怎样走进系统的,会知道 Controller 之下其实还有 Servlet,会知道为什么升级 Spring Boot 3 时包名从 javax 变成了 jakarta,也会知道规范、框架、容器和业务代码在整个体系中各自扮演什么角色。

真正高价值的成长,从来不是把所有底层细节都变成自己的主战场,而是知道哪些东西应该深挖,哪些东西理解其本质后适可而止。

Tomcat 就属于后者。它不是一个“成熟到可以忽略的老工具”,Servlet 也不是一个“面试里偶尔会问到的老名词”。它们一直都在,只是被现代框架包裹得更优雅了。

理解这些底层关系,不是为了让你回到老时代手写 Servlet,而是为了让你在今天写 Spring Boot 业务代码时,知道自己站在怎样一套技术演进链条之上。

上一页1…789…38下一页

378 日志
9 分类
RSS
© 2017 — 2026 李文业
由 Hexo 强力驱动
|
主题 — NexT.Muse
粤ICP备17160932号