# Cognitive Surrender
**作者**: Addy Osmani
**日期**: 2026-05-06T20:34:31.000Z
**来源**: [https://x.com/addyosmani/status/2052124873208799378](https://x.com/addyosmani/status/2052124873208799378)
---
Cognitive offloading is delegating to the AI and still owning the answer. Cognitive surrender is when the AI's output quietly becomes "your" output and there is nothing you feel is left to check. For software engineers the line between the two moves under your feet most days, and most of us are crossing it without noticing.
There's a term I heard yesterday that I wanted to discuss: cognitive surrender. It comes from a recent paper out of the @Wharton School at UPenn - Steven Shaw and Gideon Nave’s "Thinking - Fast, Slow, and Artificial: How AI is Reshaping Human Reasoning and the Rise of Cognitive Surrender."
The phrase has older theological roots, but the AI framing is new and it lands hard for anyone shipping code with an agent at their elbow.
Their distinction is the part worth memorising:
- Cognitive offloading is the calculator, the search engine, the GPS. You hand off the how and keep the what. You still judge whether the result is sensible, and you intervene when it isn't.
- Cognitive surrender is what happens when you stop constructing the answer at all. The AI's output becomes "your" output. There’s nothing to override, because you never formed an independent view to compare it against.
Across three experiments and 1,372 participants, Shaw and Nave found that simply having an AI available was enough for people to surrender. On trials where the AI was wrong, 73% of the time participants accepted the wrong answer. Worse: their confidence went up when AI was available, even though half the answers were deliberately incorrect. They were borrowing the model’s confidence (which is always quite high) and treating it as their own.That borrowed-confidence effect is where this stops being a general cognition story and starts being a software engineering one.
## Where surrender shows up in our work
Most of us don’t surrender on the easy stuff. We notice when an agent invents an API or fabricates an import. The surrender happens further down the stack, in the moments where the cost of forming an independent view feels disproportionate to the task.A few places I’ve watched it happen, mostly to me:
Reading the diff. The agent produces a 600-line PR. You scan it. The variable names are reasonable. The tests are green. You approve. Somewhere in the middle there’s a subtle ordering change in a transaction boundary, or a default that flips for an edge case you didn’t think to look at. You didn’t review the code. You ratified it. The surrender was the absence of a decision.
Debugging an error you don’t fully understand. The stack trace looks scary. You paste it into the agent. It returns a fix. The fix works. You move on. Two weeks later a related symptom resurfaces and you realise you never actually understood the original bug. You only removed its visible expression. The system’s mental model in your head is now wrong in a place you can’t even point to.
Making a design call. You're not sure whether to use a queue or a direct call between two services. You ask the agent. It picks one with a confident-sounding paragraph of justification. You go with it. You didn’t reason about your throughput, your failure modes, your replay semantics. You took the model’s framing of the problem and the model’s answer in the same gesture.
Learning something new. This is the one the Anthropic skill-formation paper puts numbers on. Engineers who used AI to generate code while learning a new library scored 17% lower on a follow-up comprehension quiz than the control group. Engineers who used AI for conceptual inquiry (asking questions, exploring tradeoffs) held their ground.
The thread running through all of these is the same I think: the model offered a complete answer, and we accepted it instead of constructing a parallel view of our own. Sometimes that’s correct. Sometimes that’s surrender. The two feel identical from the inside.
## The connection to comprehension debt
I’ve written before about comprehension debt - the growing gap between how much code exists in your system and how much of it any human genuinely understands.
Cognitive surrender is the mechanism by which comprehension debt accumulates. Each act of surrender is a tiny loan. The codebase grows by another patch you don’t fully understand. The architecture absorbs another decision you didn’t make. The test suite gains a test you didn’t think to specify. None of these feel like a problem on the day they happen. They compound.
@MIT's Your Brain on ChatGPT paper showed the same pattern at the neural level: writers leaning on AI exhibited measurably reduced neural connectivity, weaker memory of what they’d just produced, and difficulty reconstructing their own reasoning. The authors called it cognitive debt, borrowed from technical debt - short-term gain, compounding long-term cost.Put the two frames together.
Cognitive surrender is how you take on cognitive debt. Comprehension debt is the bill, denominated in lost mental model. The interest gets paid the next time something goes wrong and nobody on the team can reconstruct the system from first principles.
The AI doesn't create the debt. The posture you bring to it does. The same model that hollows out one engineer’s mental model can sharpen another's, depending on whether they’re using it to think or instead of thinking.
## Why software engineers are unusually exposed
A few features of our work make us more vulnerable than the average knowledge worker.
Surface signals look correct by default. Generated code compiles. It passes the linter. It runs. It looks like the rest of the file. Most domains don’t have such a strong "looks plausible" filter for the AI's output. Ours does, and it's the wrong filter. Surface correctness is not systemic correctness, and the gap between them is exactly where surrender hides.
Throughput is the visible metric. PRs merged, features shipped, tickets closed. None of these distinguish between "I built this and understand it" and "the agent built this and I approved it." The org rewards both equivalently in the short run. Surrender is invisible to the dashboard.
Confidence transfers cleanly. Models speak in declaratives. Code reviews tend to read declaratives as authority. When the agent writes "we use a debounce of 300ms here to avoid jank" it sounds like institutional knowledge, even if the model invented the number on the spot. You inherit its certainty without inheriting its (nonexistent) reasoning.
The work composes. Each surrender enables the next one. Once you've accepted a chunk you don’t fully understand, the next change to that chunk is almost guaranteed to be another act of surrender, because forming an independent view now requires reconstructing the part you skipped. Surrender is path-dependent.I’m not arguing against AI coding tools. The posture matters more than the tool, and we don’t have many of the habits we need yet.
## The calibration question
Shaw himself is careful not to be alarmist about this. His framing is the one I'd repeat back to anyone using these tools seriously:
> Cognitive surrender is not the same as saying AI is bad or that using AI is irrational; in many settings, AI can improve judgment. The key issue is calibration: knowing when AI is helping you think and when it is quietly doing the thinking for you.
The question to keep asking yourself: am I forming an independent view of this answer, or just adopting the agent’s view wholesale? Those are different psychological acts that look identical from the outside.
A few heuristics I've started using to keep myself on the offloading side of the line:
Construct an expectation before reading the output. Before I run the agent on a non-trivial task I write down (even just in my head) what I think the answer should look like. Three lines or fifty. A queue or a direct call. Whether the bug is in this module or that one. When the agent’s answer matches my expectation, I’m calibrated. When it doesn't, I have a real choice to make: am I wrong, or is it? That choice is the thing surrender skips.
Read the diff like the AI didn’t write it. Pretend a junior engineer on your team submitted the PR. Would you merge it on the strength of "the tests pass"? You wouldn’t. The same standard should apply when the author is a model. The job hasn’t changed; the author has. “Seems right” is still not a review.
Ask the model to argue against itself. Most models will produce a confident answer and then, when prompted, produce an equally confident counter-argument. That second pass is cheap and it breaks the borrowed-confidence effect. If you can’t reason about which of the two answers is right, you've found a place where you were about to surrender.
Notice when you're tired. Surrender is a fatigue phenomenon. The first PR of the day gets a real review; the fifth one gets a glance. Senior engineers I trust have all converged on some version of "stop letting the agent generate when I'm too tired to evaluate." That self-knowledge is part of the job now.
Watch where the confidence is coming from. If you find yourself defending a design choice in a meeting and you can’t actually reconstruct why it was made, only that the agent suggested it and it seemed reasonable, you’ve inherited the model’s confidence without any of the reasoning underneath it. That's a surrender artifact. Go back to the code and rebuild the why before the conversation continues.
## Engineering moves that resist surrender
The personal heuristics matter, but there's a structural version of this too. Most of what I’ve been writing about over the past few months (Agent Skills, agent harness engineering, the comprehension debt post) is about building scaffolding that makes surrender harder.
A short list of moves that hold up:
Verification as a hard exit criterion. Every agent-completed task should terminate in concrete evidence: a test that runs, a screenshot, a log, a runtime trace, a reviewer signoff. “It looks done” is the surrender-friendly exit. “Here is the evidence it works” is the surrender-resistant one. Bake the evidence requirement into the workflow and you remove the easiest path to surrender.
Anti-rationalization tables. The most distinctive design choice in Agent Skills is to pair each common excuse for skipping a workflow step with a written rebuttal. That doubles as a surrender-resistance mechanism. “This task is too simple to need a spec.” → “Acceptance criteria still apply.” You're pre-writing the rebuttal to the rationalization the model (or your tired Friday-afternoon self) hasn't yet produced. Models are exceptional at generating plausible reasons to skip the rigorous step. Anti-rationalization tables refuse to argue with them on the day.
Smaller scope, smaller PRs. Surrender scales with size. A 50-line change you can actually read; a 600-line change you cannot. Google's ~100-line PR norm exists for human reasons but it works against AI surrender for the same reasons. The unit of review is the unit of comprehension. Make the unit small enough to actually comprehend.
Conceptual inquiry over generation, when learning. This is the skill-formation paper’s finding restated as a habit. When you're new to a library or a system, ask the agent to explain before you ask it to generate. The same tool, used to interrogate rather than to produce, builds rather than erodes your mental model. The data is unambiguous on this and the cost of switching modes is trivial.
Friction by design. The @arxiv "Cognitive Agency Surrender" paper proposes Scaffolded Cognitive Friction: deliberately introducing moments of resistance to interrupt heuristic acceptance. In engineering terms: a required design doc before generation, a confirmation step before merge, a checklist before deploy. Friction has a bad reputation in productivity discourse. It’s also exactly what stands between offloading and surrender.
Solo time at the keyboard. Write some code without the agent, every week. Not as a moral exercise; as a calibration exercise. The day you can’t comfortably build something simple without AI assistance is the day the offloading became surrender and you didn’t notice.
## Mutual amplification, not delegation
The frame I want to leave on isn’t the bleak one. Andy Clark, quoted in Time on this research, draws the right distinction: there’s a difference between delegating to an AI system and cooperating with it. Delegation produces surrender. Cooperation produces what he calls mutual amplification: a loop where your prompts sharpen the model’s output, which sharpens your next prompts, which sharpens your model of the problem.
You can feel the difference. With mutual amplification you catch yourself learning the domain through the conversation, not in spite of it. You end the session with a sharper mental model than you started with, not a fuzzier one. You can still build the thing yourself; you’ve just chosen a faster path. The agent is the second engineer in the room, not the only one.
The surrender posture is the inverse. The agent ends with a sharper model of the problem than you do. You can’t reconstruct the design. You can’t debug the code without the agent’s help. You’ve outsourced the part of the work that was supposed to be making you better.
Both postures use the same tools. Both produce code that ships. From the outside, on a single sprint, they look identical. The difference shows up six months in, when something breaks and one of the two engineers can fix it from first principles and the other can’t.
## What I most want this post to do
Not to scare anyone off these tools. I use them every day. I’ve shipped more in the last twelve months than in any previous twelve, and I think the people sitting this out are making a much bigger mistake than the people leaning in. But the posture matters, and we don’t talk about it nearly enough. The conversation is mostly about what models can do. It needs to be at least as much about what we’re doing with them, and whether the answer is thinking with or not thinking at all.
Cognitive offloading is a superpower. Cognitive surrender is the failure mode of using it without noticing the line between them. The job, increasingly, is to stay calibrated about which side of that line you’re standing on at any given moment.
If your code is shipping and your understanding of the system is shrinking, you’re paying with cognitive debt. If your code is shipping and your understanding of the system is growing, you’re doing the actual job, just faster than before.
The tools are the same in both cases. The posture is what differs. That's the part still entirely yours.
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [96K](https://x.com/addyosmani/status/2052124873208799378/analytics)
- [recent paper](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646)
- [@Wharton](https://x.com/@Wharton)
- [Anthropic skill-formation paper](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [comprehension debt](https://addyosmani.com/blog/comprehension-debt/)
- [@MIT](https://x.com/@MIT)
- [Your Brain on ChatGPT](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)
- [Agent Skills](https://addyosmani.com/blog/agent-skills/)
- [agent harness engineering](https://addyosmani.com/blog/agent-harness-engineering/)
- [comprehension debt](https://addyosmani.com/blog/comprehension-debt/)
- [Agent Skills](https://github.com/addyosmani/agent-skills)
- [skill-formation paper’s](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [@arxiv](https://x.com/@arxiv)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:34 AM · May 7, 2026](https://x.com/addyosmani/status/2052124873208799378)
- [96.9K Views](https://x.com/addyosmani/status/2052124873208799378/analytics)
- [View quotes](https://x.com/addyosmani/status/2052124873208799378/quotes)
---
*导出时间: 2026/5/7 17:51:26*
---
## 中文翻译
# 认知投降
**作者**: Addy Osmani
**日期**: 2026-05-06T20:34:31.000Z
**来源**: [https://x.com/addyosmani/status/2052124873208799378](https://x.com/addyosmani/status/2052124873208799378)
---
认知卸载是指将工作委托给 AI，但你仍然对答案负责。认知投降则是指 AI 的输出悄悄地变成了“你的”输出，而你感觉没有什么需要再去检查的了。对于软件工程师来说，大多数日子里，这两者之间的界线都在你脚下移动，而我们大多数人都在毫无察觉的情况下越过了它。
昨天我听到了一个术语，我想讨论一下：认知投降。它来自宾夕法尼亚大学沃顿商学院最近的一篇论文——Steven Shaw 和 Gideon Nave 的《思考——快、慢与人工：AI 如何重塑人类推理及认知投降的崛起》。
这个词源于较古老的神学根源，但 AI 的语境是全新的，对于任何有一个 AI 代理在肘边辅助提交代码的人来说，它都直击痛点。
他们做出的区分值得铭记：
- **认知卸载**就像计算器、搜索引擎、GPS。你把“怎么做”交出去，保留了“做什么”。你仍然会判断结果是否合理，并在不合理时进行干预。
- **认知投降**是指你根本不再构建答案。AI 的输出变成了“你的”输出。没有什么可以推翻的，因为你从未形成独立的观点来与之比较。
在三项实验和 1,372 名参与者中，Shaw 和 Nave 发现，仅仅是有 AI 可用就足以让人们选择投降。在 AI 给出错误的测试中，73% 的次数参与者接受了错误答案。更糟的是：当 AI 可用时，他们的信心上升了，尽管有一半的答案是故意设置错误的。他们借用模型的信心（模型总是显得很高），并将其视为自己的。这种“借用信心效应”就是这不再是一个普遍认知问题，而变成软件工程问题的转折点。
## 投降在我们工作中如何显现
大多数人在简单的事情上不会选择投降。我们会注意到代理何时编造了一个 API 或伪造了一个导入。投降发生在更底层，在形成独立观点的成本与任务相比显得不成比例的时刻。我看过它发生的地方有几个，主要是在我自己身上：
**阅读 Diff（代码差异）。** 代理生成了一个 600 行的 PR。你扫描了一遍。变量名看起来很合理。测试通过了。你批准了。在中间的某个地方，事务边界有一个微妙的顺序变化，或者针对你没想到的边缘情况的默认值翻转了。你没有审查代码。你只是批准了它。投降即是决策的缺席。
**调试一个你不完全理解的错误。** 堆栈跟踪看起来很吓人。你把它粘贴到代理中。它返回了一个修复方案。修复奏效了。你继续工作。两周后，一个相关症状重新浮出水面，你意识到你从未真正理解原始 Bug。你只是移除了它的可见表现。你脑海中关于系统的心理模型现在在某个无法指出出了问题的地方出错了。
**做出设计决策。** 你不确定在两个服务之间是使用队列还是直接调用。你询问代理。它选择了一个，并附上一段听起来很自信的论证。你采纳了它。你没有推敲你的吞吐量、你的失败模式、你的重放语义。你在同一个手势中接受了模型对问题的框架和模型的答案。
**学习新东西。** 这正是 Anthropic 技能形成论文中量化的一点。在学习新库时使用 AI 生成代码的工程师，在随后的理解测验中得分比对照组低 17%。使用 AI 进行概念性探究（提问、探索权衡）的工程师则守住了阵地。
贯穿所有这些的主线我认为是一样的：模型提供了一个完整的答案，我们接受了它，而不是构建我们自己的平行观点。有时这是正确的。有时这是投降。从内部感受来看，这两者感觉完全相同。
## 与理解债务的联系
我之前写过关于理解债务——你系统中存在的代码量与任何人类真正理解其中的多少代码之间的日益扩大的差距。
认知投降是理解债务积累的机制。每一次投降都是一笔微小的贷款。代码库增加了一个你不完全理解的补丁。架构吸收了一个你没有做出的决定。测试套件增加了一个你没想到要指定的测试。这些在发生的当天都不像是个问题。它们会不断累积。
麻省理工学院（MIT）的《你的大脑在 ChatGPT 下》论文在神经层面展示了同样的模式：依赖 AI 的写作者在神经连接方面表现出可测量的衰退，对他们刚刚生成的内容记忆较弱，并且难以重构他们自己的推理。作者称之为认知债务，借用自技术债务——短期收益，复利式的长期成本。将这两个框架结合起来。
认知投降是你承担认知债务的方式。理解债务是账单，以失去的心理模型计价。利息在下一次出现问题时支付，而团队中没有人能从第一性原理重构系统。
AI 并不会创造债务。你使用它的姿态会。同样的模型，根据工程师是用它来思考还是用它代替思考，可能会掏空一个人的心理模型，也可能会锐化另一个人的模型。
## 为什么软件工程师的风险异常高
我们工作的几个特征使我们比普通知识工作者更脆弱。
**表面信号默认看起来是正确的。** 生成的代码可以编译。它通过 Linter 检查。它能运行。它看起来像文件中的其他代码。大多数领域没有针对 AI 输出的如此强大的“看起来合理”的过滤器。我们有，而且它是错误的过滤器。表面的正确性不是系统的正确性，而它们之间的差距正是投降隐藏的地方。
**吞吐量是可见的指标。** 合并的 PR、发布的特性、关闭的工单。这些都无法区分“我构建了这个并理解它”和“代理构建了这个而我批准了它”。组织在短期内对两者的奖励是同等的。投降在仪表盘上是不可见的。
**信心得体地转移。** 模型用陈述句说话。代码审查倾向于将陈述句解读为权威。当代理写道“我们在这里使用了 300 毫秒的防抖以避免卡顿”时，这听起来像是机构知识，即使模型是当场编造了这个数字。你继承了它的确定性，却没有继承其（不存在的）推理过程。
**工作是可组合的。** 每一次投降都会促成下一次。一旦你接受了一个你不完全理解的代码块，对该代码块的下一次更改几乎注定是另一次投降行为，因为现在要形成独立观点需要重构你跳过的部分。投降是路径依赖的。我并不是在反对 AI 编码工具。姿态比工具更重要，而我们还没有养成许多我们需要的好习惯。
## 校准问题
Shaw 本人对此保持谨慎，并不危言耸听。他的框架是我会向任何认真使用这些工具的人重复的：
> 认知投降并不等同于说 AI 是坏的，或者说使用 AI 是非理性的；在许多场景下，AI 可以提高判断力。关键问题在于校准：知道 AI 何时在帮助你思考，以及何时它悄悄地代替你进行了思考。
你需要不断问自己的问题是：我是对这个答案形成了独立的观点，还是全盘采纳了代理的观点？这是不同的心理活动，但从外部看它们看起来一模一样。
我开始使用几个启发式方法让自己保持在这条线的卸载一侧：
**在阅读输出之前构建预期。** 在让代理处理一项非平凡任务之前，我会写下来（甚至只是在脑子里）我认为答案应该是什么样的。三行还是五十行。队列还是直接调用。Bug 是在这个模块还是那个模块。当代理的回答符合我的预期时，我就校准了。当它不符合时，我必须做出一个真正的选择：是我错了，还是它错了？这个选择正是投降所跳过的环节。
**就像 AI 没写它一样去阅读 Diff。** 假装是你团队中的一位初级工程师提交了这个 PR。你会仅仅因为“测试通过了”就合并它吗？你不会。当作者是模型时，应该适用同样的标准。工作内容没有变；作者变了。“看起来对”仍然不是审查。
**让模型反驳自己。** 大多数模型会给出一个自信的答案，然后在被提示时，给出一个同样自信的反驳。第二次检查的代价很低，并且能打破借用信心效应。如果你无法推理出哪个答案是正确的，你就找到了一个你即将投降的地方。
**注意你何时感到疲惫。** 投降是一种疲劳现象。当天第一个 PR 会得到真正的审查；第五个 PR 只会被扫一眼。我信任的高级工程师们都达成了某种共识：“当我累得无法评估时，停止让代理生成代码。”这种自我认知现在是工作的一部分。
**观察信心来自哪里。** 如果你在会议中发现自己正在为某个设计选择辩护，而你实际上无法重构做出该选择的原因，只记得代理建议过它，而且它看起来很合理，那么你就继承了模型的信心，却没有任何底层的推理。那就是投降的遗留物。在对话继续之前，回到代码中重建“为什么”。
## 抵抗投降的工程行动
个人启发式方法很重要，但这也存在一个结构性的版本。过去几个月我写的大部分内容（Agent Skills、代理工具工程、理解债务那篇文章）都是关于建立脚手架，使投降变得更困难。
值得坚持的简短行动清单：
**验证作为硬性退出标准。** 每个代理完成的任务都应以具体的证据结束：运行的测试、截图、日志、运行时跟踪、审查者的签字。“看起来做完了”是投降友好的退出。“这是它有效的证据”是抵抗投降的。将证据要求融入工作流程，你就消除了通往投降的最简单路径。
**反合理化表。** Agent Skills 中最独特的设计选择是将每一个跳过工作流步骤的常见借口与书面反驳配对。这也兼作投降抵抗机制。“这个任务太简单了，不需要写规格。” → “验收标准仍然适用。”你预先写好了反驳，针对模型（或你疲惫的周五下午的自我）尚未产生的合理化借口。模型非常擅长生成跳过严谨步骤的合理理由。反合理化表拒绝在当天与它们争辩。
**更小的范围，更小的 PR。** 投降随规模扩大。你可以真正阅读 50 行的变更；你无法阅读 600 行的变更。谷歌约 100 行的 PR 规范存在是基于人类原因，但出于同样的原因，它也对抗 AI 投降。审查的单位就是理解的单位。让单位足够小，以便真正理解。
**学习时，概念探究优先于生成。** 这是技能形成论文的发现，转化为一种习惯。当你对一个库或系统不熟悉时，让代理在你要求生成之前先解释。同样的工具，用于 interrogation（探究）而不是 production（生产），会建立而不是侵蚀你的心理模型。数据对此很明确，切换模式的成本微不足道。
**设计摩擦。** @arxiv 的《认知代理投降》论文提出了“脚手架式认知摩擦”：故意引入阻力时刻以打断启发式接受。用工程术语来说：生成之前的设计文档，合并之前的确认步骤，部署之前的检查清单。摩擦在生产力话语中名声不佳。但这也正是区分卸载和投降的关键。
**键盘前的独处时间。** 每周在没有代理的情况下写一些代码。不是作为道德操练，而是作为校准操练。当你在没有 AI 辅助的情况下无法轻松构建简单东西的那一天，就是卸载变成投降而你并未察觉的那一天。
## 相互放大，而不是委托
我想留下的框架并不是那个悲观的。Andy Clark 在《时代》周刊关于这项研究的采访中做出了正确的区分：委托给 AI 系统与与它合作是有区别的。委托导致投降。合作产生了他所称的相互放大：一个循环，你的提示锐化了模型的输出，进而锐化了你的下一个提示，进而锐化了你对问题的模型。
你可以感觉到这种差异。在相互放大的情况下，你会发现自己通过对话学习领域知识，而不是放弃学习。当你结束会话时，你的心理模型比开始时更敏锐，而不是更模糊。你仍然可以自己构建那个东西；你只是选择了一条更快的路径。代理是房间里的第二位工程师，而不是唯一的一位。
投降的姿态则恰恰相反。代理结束时，它对问题的模型比你更敏锐。你无法重构设计。没有代理的帮助你无法调试代码。你把那本该让你变得更好的那部分工作外包了出去。
这两种姿态使用相同的工具。两者都能产生可发布的代码。从外部看，在单个冲刺中，它们看起来一模一样。差异会在六个月后显现，当东西坏了，两个工程师中有一个能从第一性原理修复它，另一个却不能。
## 我最希望这篇文章能起到什么作用
不是为了吓跑任何人不使用这些工具。我每天都在使用它们。我在过去十二个月里发布的东西比以往任何十二个月都多，我认为那些置身事外的人比那些积极拥抱的人犯了大得多的错。但是姿态很重要，而我们对此谈论得远远不够。对话主要集中在上模型能做什么上。它需要至少同样多地关注我们在用它们做什么，以及答案是“一起思考”还是“根本不思考”。
认知卸载是一种超能力。认知投降是在没有注意到两者之间界线的情况下使用它的失败模式。工作，越来越多地，是关于在任何特定时刻保持对自己站在那条线哪一侧的校准。
如果你的代码在发布，而你对系统的理解在萎缩，你正在用认知债务支付代价。如果你的代码在发布，而你对系统的理解在增长，你正在做实际的工作，只是比以前更快了。
在这两种情况下，工具是一样的。区别在于姿态。那是完全属于你自己的部分。
## 相关链接
- [Addy Osmani](https://x.com/addyosmani)
- [@addyosmani](https://x.com/addyosmani)
- [96K](https://x.com/addyosmani/status/2052124873208799378/analytics)
- [recent paper](https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6097646)
- [@Wharton](https://x.com/@Wharton)
- [Anthropic skill-formation paper](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [comprehension debt](https://addyosmani.com/blog/comprehension-debt/)
- [@MIT](https://x.com/@MIT)
- [Your Brain on ChatGPT](https://www.media.mit.edu/publications/your-brain-on-chatgpt/)
- [Agent Skills](https://addyosmani.com/blog/agent-skills/)
- [agent harness engineering](https://addyosmani.com/blog/agent-harness-engineering/)
- [comprehension debt](https://addyosmani.com/blog/comprehension-debt/)
- [Agent Skills](https://github.com/addyosmani/agent-skills)
- [skill-formation paper’s](https://www.anthropic.com/research/AI-assistance-coding-skills)
- [@arxiv](https://x.com/@arxiv)
- [Upgrade to Premium](https://x.com/i/premium_sign_up)
- [4:34 AM · May 7, 2026](https://x.com/addyos)