大家好，我是蓝戒。本篇我们来聊聊：“折叠AI废话与认知投降”。
不知道正在团队里写代码的你，最近几个月在审阅同事提交的代码合并请求（Pull Request，简称 PR）时，有没有产生过一种深深的无力感：
点开一个其实只改了三十几行逻辑的 PR，迎面扑来的却是一篇排版工整、辞藻华丽、足足有八百字长的“AI 标准小作文”——从“背景与动机”、“核心架构变更”、“边缘情况考量”到“未来扩展建议”，大标题套着小标题，无一处不精致，无一处不周全。
但你盯着屏幕看了三秒钟，心里冒出来的真实念头却只有五个字：“太长不想看。”
为什么明明是字字通顺的详细总结，反而让人一眼都不想多看？更要命的是，当这种“看起来无懈可击的 AI 长文”配上一片绿油油的测试通过图标时，审代码的程序员往往会下意识地放弃深究，随手点下“Approve（批准合并）”——直到两周后生产环境半夜炸出一个隐蔽的事务死锁，全组人面面相觑才发现：当时提交代码的人和审代码的人，居然没有一个真正看懂了 AI 到底改了什么！
就在 11 月 8 日至 9 日，开源界极具影响力的先驱人物、Datasette 与 LLM 工具作者 Simon Willison，与身在 Anthropic 负责打造 Claude Code 的明星工程师 Addy Osmani，一前一后针对这一现象发出了两篇引爆全网的深度反思。
今天咱们就把这两位一线大神指出的“职场 AI 废话泛滥（Workslop）”与“程序员认知投降（Cognitive Surrender）”放在一起拆解，并给你一套今天下午就能直接搬进团队代码仓库的防坑模版。
一、Simon Willison 的犀利吐槽：AI 写的 PR 描述不是太差，而是“好得让人反胃”
在 11 月 9 日发布的题为《把你那些 AI 废话 PR 描述藏进 <details><summary> 后面》的博文里，Simon Willison 先承认了一个事实：如今他自己项目里绝大多数的代码改动，都是由 Claude Code 或 Codex 替他发起 PR 完成的。
既然连大神自己都在天天用智能体提 PR，他为什么还要吐槽 AI 写的 PR 描述？
因为现在的编程智能体“太擅长写总结了”。它写的描述往往既准确又全面，把问题描述、解法细节、验证步骤列得滴水不漏。但问题恰恰出在人类的阅读心理上——正如 Willison 一针见血指出的那样：
“不管里面的信息有多准确、多有用，只要我一想到**‘我读完这篇长文花的时间，比提交者让 AI 生成它花的时间还要长’**，我就会立刻产生本能的排斥感……哪怕那个提交者就是我自己！”
这话简直说到了所有程序员的心坎里！
在软件工程里，同事花宝贵的注意力来审你的 PR，最迫切想知道的不是“你改了哪几个变量名”，而是需要人类的编辑判断力（Human Editorial Judgment）——即用最短的两句话告诉我：“以前有什么毛病？这次怎么修的？值不值得我花二十分钟去抠细节？”
可是如果你为了图省事，又把 AI 生成的那几百行实现细节直接删掉，等半年后有人想查当初为什么这么改时，又会丢失宝贵的历史档案。
怎么做到既不拿 AI 长文糊同事一脸，又能完整保留智能体的推理记录？Simon Willison 给出了一个零成本、且 GitHub/GitLab 原生支持的绝妙习惯：用 HTML 的 <details><summary> 折叠标签，给 AI 的长篇大论加一道“卷帘门”！
1. 三步改造法：人工写两句“门面”，AI 长文统统折起来
GitHub/GitLab 的 Markdown 编辑器其实一直原生支持 <details> 和 <summary> 这对折叠标签。Willison 制定的新规矩非常清爽：
- 第一部分（门面担当，限 1~2 句话）：PR 的最开头，必须是由你（人类作者）亲自写下、或者从 AI 草稿里精挑细选出来的两句话核心摘要。这是你对审阅者做出的承诺：“这两句话经过了我的人脑确认，值得你花 5 秒钟读完。”如果是界面改动或命令行改动，顺手贴一张效果截图或一段
--help终端输出。 - 第二部分（折叠标签标明模型身份）：紧接着放上
<details><summary>模型名称与思考档位</summary>（比如写上Claude Opus 5.5 Medium或Codex GPT-6），把智能体生成的几百行长篇说明全部包在里面默认收起。
来看看他在自己的开源项目里是怎么写的，直接套用下面这段格式即可：
Markdown
以前单行详情页会把整行数据渲染成一张横向表格；遇到像 GitHub 仓库表这样足足有 46 列的宽表时，页面会远远滑出屏幕右侧，留下大片空白。现在将其重构为垂直排列的字段列表。
[此处附一张直观的修改后界面截图]
<details>
<summary>Claude Opus 5.5 Medium</summary>
### 详细变更说明（由智能体生成）
- 重构了 `row.html` 模板结构，将原本的单行 `<table>` 替换为垂直键值对布局...
- 新增针对移动端窄屏的响应式折行处理与单元测试用例...
</details>
你看，改成这样之后，审代码的同事点开页面，只需 3 秒钟 看完开头那两句话和一张截图，瞬间就抓住了核心意图；如果他想深究某个实现细节，点一下那个小三角就能展开 AI 的完整报告。
2. 永远不会写反标签顺序的“发音小窍门”
很多程序员平时不用这对标签，是因为老记不清到底是 <details> 在外还是 <summary> 在外。Willison 在文末分享了一个极其好记的顺口溜：
永远在嘴里把它们连起来念作 “details-summary”（两个音节接三个音节，读起来比颠倒过来的“summary-details”顺口得多）；同时记住 <summary> 的字面意思就是“摘要标题”，也就是展示在小三角旁边让人点击的那一行字，而外面的 <details> 自然就是包裹全文的大框子了。
二、比“废话刷屏”更危险的隐形危机：Claude Code 工程师警告“认知投降”
如果说 Simon Willison 解决的是“怎么别让 AI 废话淹没人类注意力”的表层问题，那么 Anthropic 旗下 Claude Code 团队的核心工程师 Addy Osmani 近日发出的警告，则直接捅破了那层最危险的窗户纸——“认知投降（Cognitive Surrender）”。
作为亲手打造全球最顶尖编程智能体的内部工程师，Osmani 在文中说了一句极其坦诚的自我剖析：
“随着我日常越来越多的工作都交由智能体去跑，我发现现在的日常工作里，已经几乎没有任何环节会强迫我进行批判性思考了。”
他引用了沃顿商学院（Wharton School）研究人员针对 1,372 名受试者进行的三项推理实验数据：实验发现，仅仅是因为手边多了一个 AI 助手，人类就会迅速放弃独立思考——在 AI 给出错误答案的测试题里，高达 73% 的人会不假思索地直接采纳 AI 的错误结论！更讽刺的是，哪怕 AI 的答案有一半是故意设定的错题，使用了 AI 的受试者反而对自己的错误答案表现出了更高的自信心——因为人类不知不觉中“借用了大模型说话时那种斩钉截铁的自信语气”。
在日常软件开发里，Osmani 将人与 AI 的协作划分成了三个截然不同的阶段，你可以立刻对号入座看看自己正处于哪一层：
| 协作阶段 | 你的大脑在干什么 | 代码质量与长期后果 |
| 1. 认知卸载（Cognitive Offloading） | 把苦力活甩给 AI，但脑子牢牢抓着方向盘：你知道该怎么设计，只是让 Agent 替你写样板代码、跑测试，并对结果负全责 | 健康高效：生产力翻倍，且你完全清楚系统每一处的工作原理 |
| 2. 认知顺延（Deferral） | 把 AI 给出的初步方案当成自己下一步思考的输入素材，边改边推进 | 中规中矩：适合探索性原型，但需警惕顺着 AI 的错误前提一路跑偏 |
| 3. 认知投降（Cognitive Surrender） | 彻底缴械，把 AI 的输出当成标准答案：看到代码能编译通过、测试全绿、PR 说明写得头头是道，看都不仔细看就点合并 | 极度危险：不断累积**“理解债（Comprehension Debt）”**，最终没人能修线上 Bug |
Osmani 指出了四个程序员最容易发生“认知投降”的高危瞬间：
- 把“盖章”当成“审代码”：Agent 交上来一个 600 行的 PR，变量命名很规范，单元测试也是绿的，你在 30 秒内点了通过，却根本没注意到它悄悄改掉了数据库事务的边界范围——“你那不叫审查代码（Review），你那只是在给 AI 盖章画押（Ratify）！”
- 报错贴进去能跑通就翻篇：遇到一个看不懂的堆栈报错，直接复制粘贴喂给 Agent，它三下五除二改好了，你紧接着就去干下一件事。结果两周后相似的故障再次爆发，你依然对底层原因一无所知。
- 架构选型被 AI 的自信语气牵着鼻子走：Agent 用一段逻辑严密的排比句建议使用消息队列而不是直接调用，你看着觉得很有道理就照办了，却从头到尾没自己在脑子里推演过吞吐量、失败重试和消息积压怎么处理。
- 学新技术时只让 AI 生成代码，导致理解力倒退 17%：根据 Anthropic 自己做过的一项技能形成研究，在学习一个新代码库时，直接让 AI 代写代码的工程师，在随后的理解力小测验中得分比对照组低了足足 17%；而那些用 AI 来提问概念、弄懂原理的工程师，理解力则稳稳保持在高位。
当一个团队长期处于“认知投降”状态时，代码库里就会欠下巨额的“理解债”——项目里的代码行数每个月都在暴涨，但团队里真正理解这套系统是怎么转起来的人类大脑，却在以更快的速度萎缩。检验自己有没有投降的标准其实只有一条：“如果在架构评审会上，别人问你这段代码为什么要这么写，你连借着智能体的提示都解释不清楚背后的取舍，那你其实早就交出了代码的所有权。”
三、怎么既享受 Agent 的十倍速，又不把脑子废掉？
当然，无论是 Simon Willison 还是 Addy Osmani，他们写文章的目的都绝不是劝大家退回到手敲每一行代码的石器时代。毕竟在低风险、纯体力的杂活上，大胆交给 Agent 去跑本来就是天经地义的事。
真正拉开顶尖工程师与普通“提示词复读机”差距的，是在工作流里人为设置几道“防投降护栏”。结合两位大神的实战经验，我们整理了一套今天就能在团队里落地的 6 步清醒工作流：
- 动手前：先在纸上写 3 行“我预期的解法” 在敲回车让
Claude Code或Codex改一个核心模块之前，先花 30 秒写下你预判需要改哪两个文件、大概用什么思路。等 AI 改完拿出来一对比，如果它的做法跟你想的完全不一样，你就迎来了一次真正的思考机会：到底是你想漏了，还是它在瞎绕弯子？ - 执行中：逼智能体自己交出“验证底牌” 别只看它汇报“任务已完成”，在对话里多追问它一句：“在刚才的修改里，有哪些行为是你已经通过运行测试亲手验证过的？有哪些是你没法在当前环境验证、纯靠推测写出来的？” 这一问，瞬间就能把那些“看似能跑实则没测过”的盲区全诈出来。
- 生成后：让大模型“自己跟自己吵一架” 为了打破人类容易被 AI 自信语气催眠的毛病，在采纳它的架构设计前，发一句简单的反问指令：“现在请你站在反对者的立场上，狠狠挑一下刚才这套方案的刺，并告诉我哪一个核心假设一旦在生产环境不成立，这套方案就会崩盘？”
- 提 PR 时：强制推行 Willison 的“两句话人工门面 +
<details>折叠”规范 在团队的 GitHub 仓库里规定：严禁不经大脑直接把 AI 生成的千字长文粘进 PR 顶层！每个提交者必须亲手在最上方写出 2 句话的人工摘要并附上运行证据（测试日志或截图），其余 AI 写的细节一律收进<details><summary>折叠框里。这既逼着提交者自己先过一遍脑子，也救了审代码同事的眼睛。 - 审代码时：拆分百行以内的小 PR，当成“刚入职实习生”写的来审 人类大脑对代码的理解极限就在 100 到 200 行左右。一天里的第一个 PR 你可能还会认真看，到了下午第五个 800 行的巨型 PR，神仙也会走神。把大改动拆成小块，并且时刻提醒自己：“这是个很会写漂亮格式、但经常搞错业务边界的实习生写的”，哪怕它编译全过，也要重点盯紧权限校验、事务边界和异常处理。
- 每周复盘：刻意保留一项“不愿意废掉的手艺” 正如 Osmani 所提醒的：“任何一项你不再亲自练习的技能，退化的速度都会比你想象的快得多。”每周问自己一句：“这周有哪些核心基本功是我完全没动脑子全推给 AI 的？” 挑出那项你作为工程师安身立命的核心手艺（比如系统架构推演、核心算法排错或复杂性能调优），定期亲手练一练，别让自己的大脑在舒适区里彻底生锈。
说到底，工具越强大，使用工具的人就越需要定力。今晚提交你手头的下一个 Pull Request 时，不妨就从敲下那一对 <details><summary> 标签、亲手写好最上面那两句人话总结开始，把属于工程师的判断力与掌控权，稳稳握在自己手里！
文章评论