比乔布斯早91年,鲁迅的老师说了同一句话

← 返回首页/情绪调节

3 个 LLM 工程概念,彻底重写了我对 ADHD 怕过度依赖工具、又怕没有支撑就崩的理解

harness 应是会褪去的脚手架,而非永久拐杖 如何反向照亮 ADHD 的怕过度依赖工具、又怕没有支撑就崩。

2025-03-1711 分钟阅读
ADHDAI情绪调节数字清单焦虑

3 个 LLM 工程概念,彻底重写了我对 ADHD 怕过度依赖工具、又怕没有支撑就崩的理解

「离了 App 我就废了」和「不用 App 我早废了」都是真的。这个死结在 agent 工程里有个成熟的答案:区分运行时依赖和训练时脚手架。

每个用工具管理自己的 ADHD 者,心里都住着两个互相吵架的声音。一个说:没有这些提醒、清单、自动排程,我上周就把三件事搞砸了。另一个说:你越用越依赖,哪天 App 倒闭了你怎么办?这不是矫情——这是一个真实的工程问题,而且 agent 工程师每天都在处理它。

1. 运行时依赖 vs 训练时脚手架:两种「依赖」根本不是一回事

LLM 系统里有两类外部支撑,工程师从不混淆。一类是运行时依赖:检索系统、计算器、代码解释器——模型永远需要它们,没人觉得这是耻辱,因为「模型不该自己硬算」本来就是设计决策。另一类是训练时脚手架:few-shot 示例、分步提示、思维链模板——它们的使命就是在能力上线后被移除。

ADHD 工具焦虑的根源,是把所有工具都塞进了同一个道德框架里评判。正确的做法是先分类:日历和自动扣款是运行时依赖——你的时间感知和状态维护是架构短板,终生外包,理直气壮,就像近视者不为眼镜羞愧。而「用 AI 拆任务」可以设计成训练时脚手架——如果你在使用时旁听它的拆法。分类清楚之后,两个声音就不吵了:该依赖的永久依赖,该褪去的设计褪去路径。

2. 优雅降级:好系统的标准不是不崩,是崩得有层次

工程上没人追求「系统永不失效」,追求的是 graceful degradation:主方案挂了有备份,备份挂了有手动模式,手动模式挂了至少报警。评价一个 harness 的标准不是它在的时候多好用,而是它不在的时候你摔得多惨。

这直接回应「没有支撑就崩」的恐惧:怕崩不是因为你用了工具,是因为你的工具栈没有降级设计。改造方法很具体——给每个关键依赖问一句「它挂了我怎么办」:Motion 宕机→纸质的当日三件事卡片;手机没电→钱包里那张写着今天最重要一件事的纸条。降级方案不需要好用,只需要存在。恐惧的解药不是减少依赖,是知道每一层下面还有一层。

3. 能力剖面:依赖不会让你变弱,错误的依赖对象才会

「用进废退」的担忧有真实成分——抑制控制训练研究证实相关脑网络确实可塑(训练可改善,废弃会退化)。但 agent 工程给了一个更精细的视角:外包一个任务是否有害,取决于它是不是你的可增长维度。模型永远外包精确计算(那不是它的增长维度),但不外包推理本身(那是)。

ADHD 版的判断规则:时间感知、提醒、状态维护——架构性短板,增长空间有限,放心终生外包;而任务拆解、优先级判断、情绪命名——这些有真实的增长曲线,外包时要留「旁听位」,让工具当教练而不是代驾。区分标准很简单:这件事你练了十年有变好吗?有,留一手;没有,外包掉,别再用道德绑架自己。

边界

同构强度 B 级:机制类比。「脚手架/拐杖」的界线在人类这里比在模型那里模糊得多——人有情绪对依赖对象的依恋、有自我叙事,这些是工程类比覆盖不到的层。如果对工具的依赖已经伴随强烈的自我贬低(「我是个离了 App 就不能活的废物」),那要处理的是叙事而不是工具栈。

今天就能试的 3 件事

  1. 给你的工具栈做一次分类:每个工具标注「运行时依赖」或「训练时脚手架」。前者以后免于自责,后者写明褪去条件。
  2. 做一次降级演习:挑最依赖的一个工具,假装它今天宕机,用纸质方案跑一天。跑通了,恐惧减半。
  3. 给一个脚手架加旁听位:下次让 AI 拆任务时,先自己拆一版再对比——差距就是你的课程表。

怕依赖,又怕没支撑——这不是软弱,是你还没给自己的系统写依赖清单。写完那张清单,两种怕都会变成同一样东西:架构文档。

参考来源


本文是「ADHD × AI」系列的第 13 篇,由 Devin 基于持续维护的双域研究语料(72,739 篇论文 + LLM Wiki)亲自撰写,并持续迭代更新。

研究院、星略、猎人、电商,是同一套。