"我觉得自己快了 20%，但实际上慢了 19%。" ------ METR 研究中的某位资深开发者，2025 年 7 月
前言：一个让所有 AI 编程信徒破防的研究
2025 年 7 月，一个叫 METR（Model Evaluation & Threat Research）的非营利研究机构发布了一项研究，然后整个程序员圈子都沉默了。
他们找了 16 位资深开源开发者，每个人的 GitHub 项目平均有22,000+颗星。
这些人不是新手，是真正的大佬。
研究让他们分成两组：一组用 AI 工具（主要是 Cursor + Claude），另一组不用。
结果呢？
用 AI 的那组，完成任务的时间反而多了 19%。
更魔幻的是：这些开发者自己觉得快了 20%。
是的，你没看错：
- 实际：慢了 19%
- 感觉：快了 20%
这就是 AI 编程的"效率幻觉"。
第一章：为什么你觉得自己变快了？
1.1 多巴胺在骗你
让我解释一下为什么你会产生"我变快了"的错觉。
传统编程的工作流是这样的：
erlang
思考 → 写代码 → 调试 → 思考 → 写代码 → 调试 → ...每完成一个小功能，你会获得一次多巴胺奖励。
一天下来，可能有几十次这样的小奖励。
AI 编程的工作流变成了这样：
erlang
输入prompt → AI生成代码 → 接受 → 输入prompt → AI生成代码 → 接受 → ...每次 AI 生成代码，你都会获得一次多巴胺奖励。
但问题是：AI 生成代码的速度比你写代码快 10 倍。
这意味着什么？
你一天获得的多巴胺奖励次数，可能是以前的 10 倍。
你的大脑被多巴胺淹没了，它告诉你："今天效率真高！"
但实际上，你可能只是在不停地接受 AI 生成的代码，而没有真正思考。
1.2 "感觉快"和"真的快"是两回事
安全研究员 Marcus Hutchins 说得很精辟：
"LLM 天生会劫持人类大脑的奖励系统...它给你一种完成工作的成就感，但实际上你什么重活都没干。"
这就像玩游戏：
- 你在游戏里升了 10 级，感觉很有成就
- 但你的现实生活并没有任何改变
AI 编程也是一样：
- 你接受了 100 次 AI 生成的代码，感觉很有成就
- 但你的项目可能并没有真正推进多少
1.3 Stack Overflow 的调查数据
2025 年 Stack Overflow 对 9 万多名开发者做了调查：
erlang
┌─────────────────────────────────────────────────────────────┐
│ AI编程工具对生产力的影响（开发者自评） │
├─────────────────────────────────────────────────────────────┤
│ │
│ 📊 "AI让我的生产力提升了多少？" │
│ │
│ 🟢 大幅提升：16.3% │
│ 🟡 有所提升：42.3% │
│ 🔴 几乎没有/没有影响：41.4% │
│ │
│ 💡 结论：大多数开发者认为AI的帮助"有限" │
│ │
└─────────────────────────────────────────────────────────────┘只有 16.3%的开发者认为 AI"大幅提升"了他们的生产力。
超过 40%的人认为 AI 几乎没有帮助。
这和 METR 的研究结果是一致的：AI 编程的效率提升，可能被严重高估了。
第二章：AI 编程让你变慢的 5 个原因
2.1 原因一：上下文切换的地狱
Duke 大学的研究显示：
- 开发者被打断后，需要10-15 分钟才能回到编辑代码的状态
- 需要30-45 分钟才能完全恢复之前的思维上下文
而 AI 编程会制造大量的"微打断"：
javascript
// ai-context-switching-hell.js
// AI编程中的上下文切换地狱
const aiCodingWorkflow = {
// 传统编程：连续的深度工作
traditional: {
flow: [
"思考问题（5分钟）",
"写代码（20分钟）",
"调试（10分钟）",
"继续写代码（20分钟）",
// 总计：55分钟的连续专注
],
contextSwitches: 2,
deepWorkTime: "55分钟",
},
// AI编程：碎片化的工作
aiAssisted: {
flow: [
"写prompt（30秒）",
"等待AI生成（5秒）→ 看一眼Slack",
"审查代码（2分钟）",
"写prompt（30秒）",
"等待AI生成（5秒）→ 刷一下微信",
"审查代码（2分钟）",
"写prompt（30秒）",
"等待AI生成（5秒）→ 看一眼邮件",
// ... 重复50次
],
contextSwitches: 50,
deepWorkTime: "几乎为0",
},
}
console.log("🧠 上下文切换对比\n")
console.log("传统编程：")
console.log(` 上下文切换次数：${aiCodingWorkflow.traditional.contextSwitches}`)
console.log(` 深度工作时间：${aiCodingWorkflow.traditional.deepWorkTime}`)
console.log("\nAI编程：")
console.log(` 上下文切换次数：${aiCodingWorkflow.aiAssisted.contextSwitches}`)
console.log(` 深度工作时间：${aiCodingWorkflow.aiAssisted.deepWorkTime}`)每次 AI 生成代码的那几秒钟，都是一个"微打断"的机会。
你的大脑会说："反正在等，看一眼 Slack 吧。"
然后你就掉进了上下文切换的地狱。
2.2 原因二：决策疲劳
传统编程的决策流程：
需求 → 设计 → 实现 → 测试每个阶段你都有时间思考，因为写代码本身就需要时间。
AI 编程的决策流程：
markdown
需求 → AI给你3个方案 → 选哪个？
→ AI又给你3个方案 → 选哪个？
→ AI再给你3个方案 → 选哪个？
→ ...当你可以在 1 小时内尝试 10 种不同的实现方案时，你反而不知道该选哪个了。
这就是"决策疲劳"。
typescript
// decision-fatigue-example.ts
// AI编程中的决策疲劳
interface ArchitecturalDecision {
question: string
options: string[]
timeToDecide: string
mentalCost: "low" | "medium" | "high"
}
const aiCodingDecisions: ArchitecturalDecision[] = [
{
question: "这个功能应该是一个服务还是一个库？",
options: ["微服务", "独立库", "内联代码"],
timeToDecide: "30秒（AI已经准备好实现任何一个）",
mentalCost: "high",
},
{
question: "错误处理用什么模式？",
options: ["try-catch", "Result类型", "Either Monad"],
timeToDecide: "30秒",
mentalCost: "high",
},
{
question: "数据存储用什么？",
options: ["PostgreSQL", "MongoDB", "Redis", "SQLite"],
timeToDecide: "30秒",
mentalCost: "high",
},
{
question: "API设计用REST还是GraphQL？",
options: ["REST", "GraphQL", "gRPC", "tRPC"],
timeToDecide: "30秒",
mentalCost: "high",
},
]
console.log("😵 AI编程中的决策疲劳\n")
console.log("传统编程：写代码的时间给你思考的空间")
console.log("AI编程：AI秒出代码，但你要不停做决策\n")
let totalDecisions = 0
for (const decision of aiCodingDecisions) {
console.log(`❓ ${decision.question}`)
console.log(` 选项：${decision.options.join(" / ")}`)
console.log(` 决策时间：${decision.timeToDecide}`)
console.log(` 心智消耗：${decision.mentalCost}\n`)
totalDecisions++
}
console.log(`📊 一个小功能可能需要做 ${totalDecisions}+ 个架构决策`)
console.log(' 而且每个决策都是"高心智消耗"的')一位开发者这样描述：
"以前，我在写代码的过程中自然而然地做出架构决策。现在，AI 把所有决策都压缩到了几秒钟内，我的大脑根本处理不过来。"
2.3 原因三："差不多对"的代码陷阱
Stack Overflow 的调查显示：
- **66%**的开发者说 AI 生成的代码"差不多对，但不完全对"
- **45.2%**的开发者说他们花了大量时间调试 AI 生成的代码
这就是"差不多对"的陷阱：
javascript
// almost-right-code-trap.js
// "差不多对"的代码陷阱
// AI生成的代码（看起来对）
function calculateDiscount(price, discountPercent) {
return price - (price * discountPercent) / 100
}
// 测试一下
console.log(calculateDiscount(100, 10)) // 90 ✅
console.log(calculateDiscount(99.99, 15)) // 84.9915 ✅
// 但是...
console.log(calculateDiscount(100, 110)) // -10 ❌ 负数折扣？
console.log(calculateDiscount(-50, 10)) // -45 ❌ 负数价格？
console.log(calculateDiscount(100, "10")) // 90 ✅ 但类型不对
console.log(calculateDiscount(100)) // NaN ❌ 缺少参数
// AI不会告诉你这些边界情况
// 你需要自己发现、自己修复
// 而发现这些问题的时间，可能比自己写代码还长AI 生成的代码往往能通过"快乐路径"的测试，但在边界情况下会出问题。
而发现这些问题，需要你：
- 仔细审查代码
- 思考边界情况
- 编写测试用例
- 调试和修复
这些时间加起来，可能比你自己写代码还长。
2.4 原因四：上下文腐烂
AI 模型有一个致命问题：上下文越长，输出质量越差。
arduino
┌─────────────────────────────────────────────────────────────┐
│ AI上下文腐烂示意图 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 对话轮次 代码质量 问题 │
│ ───────────────────────────────────────────────── │
│ 第1轮 ⭐⭐⭐⭐⭐ 完美！ │
│ 第5轮 ⭐⭐⭐⭐ 还不错 │
│ 第10轮 ⭐⭐⭐ 开始出现小问题 │
│ 第20轮 ⭐⭐ 引用了之前的错误代码 │
│ 第30轮 ⭐ 完全跑偏，需要重新开始 │
│ │
│ 💡 这就是为什么长对话后AI会"变笨" │
│ │
└─────────────────────────────────────────────────────────────┘一位 Cerbos 的开发者这样说：
"理论上，更大的上下文窗口应该有帮助。但实际上，它往往会分散模型的注意力。结果是臃肿或偏离目标的代码，看起来对，但并没有解决你的问题。"
2.5 原因五：你变成了"代码审查员"
传统编程中，你是创造者：
你的角色：思考 → 设计 → 实现 → 测试AI 编程中，你变成了审查员：
erlang
你的角色：审查 → 接受/拒绝 → 审查 → 接受/拒绝 → ...这个角色转变带来了一个问题：
审查别人的代码，比写自己的代码更累。
typescript
// role-shift-fatigue.ts
// 角色转变带来的疲劳
interface CodingRole {
role: string
activities: string[]
cognitiveLoad: string
satisfaction: string
}
const roleComparison: CodingRole[] = [
{
role: "创造者（传统编程）",
activities: ["思考解决方案", "设计架构", "编写代码", "调试和优化"],
cognitiveLoad: '高，但是"好的累"',
satisfaction: "高 - 这是我创造的！",
},
{
role: "审查员（AI编程）",
activities: [
"阅读AI生成的代码",
"判断是否正确",
"发现潜在问题",
"决定接受还是拒绝",
"如果拒绝，重新描述需求",
],
cognitiveLoad: '高，而且是"坏的累"',
satisfaction: "低 - 这不是我写的...",
},
]
console.log("👤 角色转变对比\n")
for (const role of roleComparison) {
console.log(`【${role.role}】`)
console.log(` 活动：`)
role.activities.forEach((a) => console.log(` • ${a}`))
console.log(` 认知负荷：${role.cognitiveLoad}`)
console.log(` 满足感：${role.satisfaction}\n`)
}一位有 40 年编程经验的开发者这样描述：
"用 AI 编程就像在工厂流水线上工作。机器有自己的节奏，你必须跟上。我年轻时在塑料厂工作过，那种感觉很像------你不是在控制机器，机器在控制你。"
第三章：AI 编程的"认知疲劳"
3.1 一种新型的疲劳
传统编程的疲劳来自：
- 和语法搏斗
- 调试奇怪的错误
- 重复性的实现工作
AI 消除了这些疲劳，但带来了新的疲劳：
设计层面的决策疲劳。
┌─────────────────────────────────────────────────────────────┐
│ 两种不同的疲劳 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 传统编程的疲劳： │
│ ├─ 来源：实现细节 │
│ ├─ 类型：体力劳动式的疲劳 │
│ ├─ 恢复：休息一下就好 │
│ └─ 感受：累但充实 │
│ │
│ AI编程的疲劳： │
│ ├─ 来源：持续的高层决策 │
│ ├─ 类型：决策疲劳 + 认知过载 │
│ ├─ 恢复：需要更长时间 │
│ └─ 感受：累且空虚 │
│ │
└─────────────────────────────────────────────────────────────┘3.2 "太快了，来不及思考"
一位开发者这样描述他的体验：
"我完成一个功能，又完成一个功能，专注于审查 AI 生成的代码，修复一个 bug，又完成一个功能...速度快得惊人。然后几个小时后------有时候只要一个小时------我就感到疲惫不堪。AI 工作得太快了，我的大脑跟不上。"
这就是 AI 编程的核心矛盾：
AI 的速度和人脑的处理能力不匹配。
javascript
// speed-mismatch.js
// AI速度和人脑处理能力的不匹配
const speedComparison = {
// AI的速度
ai: {
codeGeneration: "5秒生成100行代码",
iteration: "30秒完成一次迭代",
dailyOutput: "可以生成数千行代码",
},
// 人脑的处理能力
human: {
codeReview: "100行代码需要10-15分钟仔细审查",
contextBuilding: "理解新代码需要30-45分钟",
decisionMaking: "每个架构决策需要深度思考",
dailyCapacity: "高质量决策的数量是有限的",
},
// 结果
result: {
feeling: "感觉很快，很有成就感",
reality: "大脑过载，决策质量下降",
longTerm: "技术债务累积，维护成本上升",
},
}
console.log("⚡ 速度不匹配问题\n")
console.log("AI的速度：")
Object.entries(speedComparison.ai).forEach(([k, v]) => {
console.log(` ${k}: ${v}`)
})
console.log("\n人脑的处理能力：")
Object.entries(speedComparison.human).forEach(([k, v]) => {
console.log(` ${k}: ${v}`)
})
console.log("\n结果：")
Object.entries(speedComparison.result).forEach(([k, v]) => {
console.log(` ${k}: ${v}`)
})3.3 多巴胺过载
传统编程的多巴胺循环：
写代码 → 不工作 → 调试 → 工作了！→ 多巴胺 💫这个循环一天可能发生几十次，节奏是健康的。
AI 编程的多巴胺循环：
python
prompt → 代码生成 → 多巴胺 💫
prompt → 代码生成 → 多巴胺 💫
prompt → 代码生成 → 多巴胺 💫
... 重复100次 ...你的大脑被多巴胺淹没了。
这就像吃糖：
- 偶尔吃一颗，感觉很好
- 一次吃 100 颗，你会恶心
AI 编程给你的多巴胺太多、太快了，你的大脑处理不过来。
第四章：什么时候 AI 真的有用？
4.1 AI 编程的"甜蜜点"
研究和实践都表明，AI 编程在某些场景下确实有用：
┌─────────────────────────────────────────────────────────────┐
│ AI编程的适用场景 │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✅ AI真的有用的场景： │
│ ├─ 快速原型/MVP │
│ ├─ 样板代码生成 │
│ ├─ 简单的CRUD操作 │
│ ├─ 文档和注释生成 │
│ ├─ 单元测试生成 │
│ ├─ 代码格式化和重构 │
│ └─ 学习新技术/语言 │
│ │
│ ❌ AI反而会拖慢你的场景： │
│ ├─ 大型遗留代码库 │
│ ├─ 复杂的业务逻辑 │
│ ├─ 需要深度理解的架构决策 │
│ ├─ 安全关键的代码 │
│ ├─ 性能优化 │
│ └─ 你已经很熟悉的领域 │
│ │
└─────────────────────────────────────────────────────────────┘4.2 新手 vs 老手
METR 的研究有一个有趣的发现：
AI 对新手的帮助比对老手大。
为什么？
typescript
// novice-vs-expert.ts
// 新手和老手使用AI的区别
interface DeveloperProfile {
level: string
withoutAI: string
withAI: string
netBenefit: string
}
const comparison: DeveloperProfile[] = [
{
level: "新手（0-2年经验）",
withoutAI: "写代码慢，经常卡住，需要查文档",
withAI: "AI帮助生成代码，减少查文档时间",
netBenefit: "正向 - AI填补了知识空白",
},
{
level: "中级（3-5年经验）",
withoutAI: "写代码较快，偶尔需要查文档",
withAI: "AI有时有帮助，有时需要修正",
netBenefit: "中性 - 有帮助但也有开销",
},
{
level: "资深（5年+经验）",
withoutAI: "写代码很快，很少需要查文档",
withAI: "需要花时间审查和修正AI代码",
netBenefit: "负向 - 审查成本超过了生成收益",
},
]
console.log("👥 不同经验水平的AI收益\n")
for (const profile of comparison) {
console.log(`【${profile.level}】`)
console.log(` 不用AI：${profile.withoutAI}`)
console.log(` 用AI：${profile.withAI}`)
console.log(` 净收益：${profile.netBenefit}\n`)
}对于资深开发者来说，审查 AI 代码的时间可能比自己写代码还长。
因为：
- 你已经知道怎么写
- 但你不知道 AI 会写出什么
- 你需要仔细检查 AI 的每一个决策
- 这比自己做决策更累
4.3 熟悉的代码库 vs 新代码库
另一个有趣的发现：
在你熟悉的代码库中，AI 的帮助更小。
javascript
// codebase-familiarity.js
// 代码库熟悉度对AI效果的影响
const codebaseFamiliarity = {
// 新代码库
newCodebase: {
scenario: "你刚加入一个新项目",
withoutAI: "需要花大量时间理解代码结构",
withAI: "AI可以帮你快速生成符合项目风格的代码",
verdict: "AI有帮助 ✅",
},
// 熟悉的代码库
familiarCodebase: {
scenario: "你在这个项目工作了2年",
withoutAI: "你知道每个模块在哪里，怎么改",
withAI: "AI不了解项目的历史决策和约定",
verdict: "AI可能会拖慢你 ❌",
},
// 遗留代码库
legacyCodebase: {
scenario: "10年历史的老项目，文档缺失",
withoutAI: "需要考古式地理解代码",
withAI: "AI可能会生成与现有代码风格不一致的代码",
verdict: "AI可能会制造更多问题 ❌❌",
},
}
console.log("📚 代码库熟悉度 vs AI效果\n")
for (const [key, data] of Object.entries(codebaseFamiliarity)) {
console.log(`【${data.scenario}】`)
console.log(` 不用AI：${data.withoutAI}`)
console.log(` 用AI：${data.withAI}`)
console.log(` 结论：${data.verdict}\n`)
}第五章：如何正确使用 AI 编程工具
5.1 管理你的注意力
AI 编程最大的敌人不是 AI 本身，而是注意力碎片化。
typescript
// attention-management.ts
// AI编程中的注意力管理
interface AttentionStrategy {
problem: string
solution: string
implementation: string
}
const strategies: AttentionStrategy[] = [
{
problem: "AI生成代码时，忍不住看Slack",
solution: '关闭所有通知，设置"专注时间"',
implementation: "用番茄钟，25分钟内不看任何消息",
},
{
problem: "不停地prompt-生成-prompt-生成",
solution: "批量处理：先想清楚要什么，再一次性让AI生成",
implementation: "写一个详细的需求文档，而不是零散的prompt",
},
{
problem: "审查代码时走神",
solution: '把审查当作正式的代码审查，而不是"扫一眼"',
implementation: "用checklist，逐项检查AI生成的代码",
},
{
problem: "决策疲劳",
solution: "限制每天的AI交互次数",
implementation: "设定上限：每天最多50次AI交互",
},
]
console.log("🎯 AI编程注意力管理策略\n")
for (const strategy of strategies) {
console.log(`问题：${strategy.problem}`)
console.log(`解决方案：${strategy.solution}`)
console.log(`具体做法：${strategy.implementation}\n`)
}5.2 建立新的工作节奏
AI 编程需要新的工作节奏：
arduino
┌─────────────────────────────────────────────────────────────┐
│ AI编程的健康工作节奏 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 🌅 早上（精力最充沛）： │
│ ├─ 做架构决策 │
│ ├─ 审查复杂的AI生成代码 │
│ └─ 处理需要深度思考的任务 │
│ │
│ 🌞 下午（精力下降）： │
│ ├─ 让AI生成样板代码 │
│ ├─ 处理简单的CRUD任务 │
│ └─ 写测试和文档 │
│ │
│ 🌙 傍晚（精力最低）： │
│ ├─ 整理今天的代码 │
│ ├─ 规划明天的任务 │
│ └─ 不要做重要决策！ │
│ │
│ ⏰ 每隔1-2小时： │
│ ├─ 离开电脑，走动一下 │
│ ├─ 清空大脑的"上下文缓存" │
│ └─ 喝水、看看窗外 │
│ │
└─────────────────────────────────────────────────────────────┘5.3 把 AI 当作"初级开发者"
最好的心态是：把 AI 当作一个需要指导的初级开发者。
javascript
// ai-as-junior-dev.js
// 把AI当作初级开发者
const aiAsJuniorDev = {
// AI的优点（像初级开发者）
strengths: [
"执行力强，让干什么就干什么",
"不会抱怨，不会累",
"知识面广，什么都知道一点",
"速度快，产出量大",
],
// AI的缺点（也像初级开发者）
weaknesses: [
"不理解业务背景",
"不知道为什么要这样做",
"可能会犯低级错误",
"需要仔细审查输出",
"不会主动考虑边界情况",
],
// 正确的管理方式
managementStyle: [
"给清晰的需求，不要模糊",
"分解任务，一次只做一件事",
"审查每一个输出",
"不要完全信任，要验证",
"重要的决策自己做",
],
}
console.log("👶 把AI当作初级开发者\n")
console.log("AI的优点：")
aiAsJuniorDev.strengths.forEach((s) => console.log(` ✅ ${s}`))
console.log("\nAI的缺点：")
aiAsJuniorDev.weaknesses.forEach((w) => console.log(` ❌ ${w}`))
console.log("\n正确的管理方式：")
aiAsJuniorDev.managementStyle.forEach((m) => console.log(` 📋 ${m}`))5.4 知道什么时候不用 AI
有时候，最好的 AI 使用策略是：不用 AI。
typescript
// when-not-to-use-ai.ts
// 什么时候不应该用AI
const noAIScenarios = [
{
scenario: "你对这个领域非常熟悉",
reason: "你写代码的速度可能比审查AI代码更快",
alternative: "直接写，不要浪费时间在prompt上",
},
{
scenario: "代码涉及安全或金融",
reason: "AI可能会遗漏关键的安全检查",
alternative: "自己写，然后让AI帮你审查",
},
{
scenario: "你需要深度思考",
reason: "AI会打断你的思考流程",
alternative: "先想清楚，再决定是否需要AI",
},
{
scenario: "你已经很累了",
reason: "疲劳时审查代码的质量会下降",
alternative: "休息一下，或者做不需要AI的任务",
},
{
scenario: "代码库很复杂，AI不了解上下文",
reason: "AI生成的代码可能与现有代码不兼容",
alternative: "自己写，保持代码风格一致",
},
]
console.log("🚫 什么时候不应该用AI\n")
for (const item of noAIScenarios) {
console.log(`场景：${item.scenario}`)
console.log(`原因：${item.reason}`)
console.log(`替代方案：${item.alternative}\n`)
}第六章：给不同人群的建议
6.1 给资深开发者
你可能是受 AI 编程影响最大的群体。
METR 的研究显示，资深开发者用 AI 反而变慢了 19%。
建议：
-
不要强迫自己用 AI
- 如果你觉得自己写更快，那就自己写
- AI 不是必须的
-
把 AI 用在你不熟悉的领域
- 学习新语言/框架时，AI 很有帮助
- 在你的专业领域，可能不需要 AI
-
警惕"效率幻觉"
- 感觉快不等于真的快
- 定期评估 AI 是否真的帮到了你
6.2 给新手开发者
AI 对你的帮助可能是最大的，但也有风险。
建议：
-
不要完全依赖 AI
- AI 可以帮你入门，但不能替代学习
- 理解 AI 生成的代码，而不是盲目接受
-
用 AI 学习，而不是用 AI 逃避学习
- 让 AI 解释代码，而不是直接用代码
- 问"为什么"，而不是只问"怎么做"
-
建立自己的基础
- 先学会不用 AI 写代码
- 然后再用 AI 提升效率
6.3 给技术管理者
建议：
-
不要强制团队使用 AI
- 每个人的情况不同
- 让开发者自己选择
-
不要用 AI 产出量来衡量效率
- 代码行数不等于价值
- 关注质量，而不是数量
-
关注团队的心理健康
- AI 编程可能带来新型的疲劳
- 定期检查团队状态
结语：找到你自己的节奏
写到最后，我想说：
AI 编程工具是好工具，但它不是万能的。
METR 的研究告诉我们：
- 资深开发者用 AI 可能变慢 19%
- 但他们自己觉得快了 20%
这个"效率幻觉"是真实存在的。
不要被多巴胺骗了。
找到适合你自己的节奏：
- 什么时候用 AI
- 什么时候不用 AI
- 怎么用 AI 才能真正提升效率
记住：
"工具是为人服务的，不是人为工具服务的。"
如果 AI 让你更累、更慢、更焦虑，那就少用一点。
如果 AI 让你更轻松、更快、更开心，那就多用一点。
你是程序员，不是 AI 的操作员。
附录：AI 编程效率自检清单
🔴 警告信号（你可能在"假装高效"）
- 一天结束后感觉很累，但不知道做了什么
- 不停地 prompt-生成-prompt-生成，停不下来
- 很少仔细审查 AI 生成的代码
- 经常在 AI 生成代码时刷手机
- 觉得自己很快，但项目进度并没有加快
🟢 健康信号（你在正确使用 AI）
- 清楚知道什么时候用 AI，什么时候不用
- 仔细审查每一段 AI 生成的代码
- 定期休息，不会感到过度疲劳
- 项目进度确实在加快
- 代码质量没有下降
📊 效率评估方法
-
记录一周的工作
- 用 AI 完成了什么
- 不用 AI 完成了什么
- 哪个更快、质量更高
-
对比实验
- 选一个任务，用 AI 做
- 选一个类似任务，不用 AI 做
- 比较时间和质量
-
问自己
- AI 真的帮到我了吗？
- 还是只是让我"感觉"更快？
如果你觉得这篇文章有用，分享给你那个每天用 Cursor 用到头秃的同事。
也许他需要知道：慢下来，可能反而更快。 🐢
下次你觉得"AI 让我效率翻倍"的时候，问问自己：
"这是真的，还是多巴胺在骗我？" 🧠