我们应该比模型更“疲惫”

背景

近期，随着基于代理（Agentic）的代码生成工具的普及，许多开发者开始感到一种失控感。这种工具虽然能迅速产出代码，但开发者往往只获得了代码的“外在形式”，却失去了手工编写代码时大脑内部发生的认知加工过程。

作者指出，这种失控感源于人类记忆机制与当前 AI 交互模式之间的错位。人类的记忆系统分为短期记忆（类似 RAM，快速处理临时信息）、长期记忆（类似数据库，存储已学知识）和工作记忆（结合前两者进行综合处理以解决问题）。在传统的编程工作中，阅读和理解代码需要这些记忆系统协同工作，从而构建对编程环境的深刻理解。

然而，默认的 AI 代码生成模式在用户体验上类似于“老虎机”：拉动拉杆（输入提示），获得奖励（解决方案）。这种即时反馈机制不仅阻碍了技能的保留，甚至被作者比作用“Token 流”取代了社交媒体信息流。这种缺乏摩擦力的交互方式，导致开发者在会话结束后感到“脑雾”（brain fog），即虽然完成了任务，但认知层面并未获得实质性的成长。

核心内容

作者深入剖析了 AI 辅助编程中“效率”与“学习”之间的悖论，并分享了一系列旨在重建认知深度、增加开发摩擦力的具体实践方法。

认知机制的冲突

作者强调，代码生成的默认模式与技能保留是背道而驰的。当我们手工编写或阅读代码时，大脑同时在调动短期、长期和工作记忆来解析编程环境。这种高强度的认知参与是技能内化的关键。相反，AI 代理往往直接给出答案，剥夺了开发者进行这种综合处理的机会，导致知识无法从短期记忆转化为长期记忆。

从“生成答案”到“刻意使用”

作者承认，从被动接受 AI 生成的答案转变为刻意、有意识地使用工具，需要付出额外的努力。受到 X 平台（原 Twitter）上 Oz 的建议启发——即在感到“脑雾”时，尝试手动重写部分代码，作者开始探索如何为开发过程增加“摩擦力”。

增加摩擦力的具体实践

为了对抗 AI 带来的认知惰性，作者尝试了以下策略，这些策略的核心在于通过增加短期内的操作成本，来换取长期的能力巩固：

1. 先写后审：由开发者自己编写初始实现，然后让 AI 代理审查代码。接着，逐条评论地手动进行修改，而不是直接接受 AI 的修改建议。
2. 追问与溯源：利用 AI 针对不理解的部分代码不断提问，并要求其调取相关的文档和 Pull Requests (PRs)，以此加深理解而非直接获取答案。
3. 多方案对比与批判：要求 AI 思考两种不同的实现方案，选择其中一种，并批判另一种方案的优缺点。这迫使开发者参与决策过程。
4. 人际讨论：与同事或他人讨论 AI 提出的实现方案，通过社交互动强化认知。
5. 延迟介入：在遇到问题时，先独立思考并尝试解决 20 分钟，然后再引入 AI 代理。
6. 回归基础：重新阅读书籍和学术论文，夯实理论基础。
7. 手动重构：手动重新实现基础数据结构，以强化底层逻辑的理解。

核心观点：我们应该比模型更“疲惫”

所有这些方法的共同点是：它们在短期内抵消了 LLM 生成代码带来的速度优势，增加了摩擦。但从长远来看，它们通过巩固开发者自身的基础知识体系，而非依赖模型的基础，使开发者能够更有效地使用工具。

作者总结道：“We should be more tired than the model.”（我们应该比模型更疲惫。）这意味着，如果 AI 在后台处理了所有繁重的认知工作，而开发者轻松坐享其成，那么开发者的技能将会退化。真正的成长来自于那些让开发者感到“累”的过程——那些需要调动工作记忆、进行批判性思维和手动重构的时刻。

关键要点

• AI 交互的“老虎机效应”：默认的 AI 代码生成 UX 类似于老虎机，提供即时奖励（代码解决方案），这种机制阻碍了技能的长期保留，并可能导致认知上的“脑雾”。
• 记忆机制的重要性：编程能力的提升依赖于短期、长期和工作记忆的协同运作。AI 直接给出答案剥夺了这一过程，导致知识无法内化。
• 刻意增加摩擦力：为了保持技能增长，开发者需要主动在开发流程中引入“摩擦力”，例如先手动实现再让 AI 审查，或延迟 AI 的介入时间。
• 从被动接受到主动批判：不应直接接受 AI 的代码，而应要求 AI 提供多种方案并进行批判性分析，或手动重写 AI 的建议以加深理解。
• 长期收益优于短期效率：虽然上述方法在短期内降低了编码速度，但它们通过巩固开发者自身的基础知识，提升了长期使用 AI 工具的能力。
• 认知负荷的再分配：理想的 AI 辅助编程状态是，AI 处理了计算和检索任务，而开发者承担了理解、决策和整合的认知负荷，因此开发者应感到比模型更“疲惫”。

意义与影响

这篇文章对当前 AI 辅助编程（AI-Augmented Programming）的实践提出了深刻的反思。在追求极致效率的行业氛围中，它提醒开发者警惕“认知外包”带来的隐性成本。

1. 重新定义“生产力”：文章挑战了以代码行数或生成速度为单一指标的生产力观念，指出如果缺乏认知参与，这种“生产力”可能是虚假的，甚至会导致开发者核心技能的退化。
2. 教育与实践的指导：对于技术团队和开发者而言，文章提供了一套可操作的“反惰性”指南。它建议将 AI 视为导师或审查者，而非代笔者。这种转变有助于培养更具韧性和深度的工程能力。
3. 人机协作的新范式：文章暗示了未来人机协作的理想状态并非“人指挥，机器执行”，而是“人思考，机器辅助”。开发者需要保持足够的认知活跃度（即“疲惫感”），以确保在复杂系统中拥有最终的判断力和架构能力。
4. 对工具设计的启示：对于 AI 编程工具的设计者来说，这一观点具有参考价值。未来的工具或许不应仅仅追求“一键生成”，而应设计更多促进理解、提问和反思的交互模式，帮助用户在享受效率的同时保持技能的成长。

总之，这篇文章呼吁开发者在拥抱 AI 的同时，保持对认知过程的掌控，通过主动增加学习曲线上的摩擦，确保自己在技术演进中始终处于主导地位。