Appearance
Part 5: 风险、陷阱与心智模型 (15-20 min)
核心思路：不是要吓唬大家不用 AI，而是让大家知道边界在哪里
5.1 Vibe Coding 的具体风险
text
┌─────────────────────────────────────────────────────────────────────┐
│ Vibe Coding 的四大风险 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 安全漏洞 │ │ 调试困难 │ │
│ │ 🔓 │ │ 🐛 │ │
│ │ │ │ │ │
│ │ 40% 的 AI 代码 │ │ regenerate │ │
│ │ 存在安全问题 │ │ until it works │ │
│ │ │ │ │ │
│ │ Lovable 事件: │ │ 「复杂 bug 时 │ │
│ │ 170+ 应用泄露 │ │ 完全失效」 │ │
│ └────────┬────────┘ └────────┬────────┘ │
│ │ │ │
│ ▼ ▼ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ 技术债务 │ │ 技能退化 │ │
│ │ 💸 │ │ 📉 │ │
│ │ │ │ │ │
│ │ 「两个工程师能 │ │ 调试能力是肌肉 │ │
│ │ 创造 50 人的 │ │ 不用会萎缩 │ │
│ │ 技术债」 │ │ │ │
│ │ │ │ 见 5.2 节详述 │ │
│ │ 代码重复率 8x↑ │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘| 风险 | 说明 | 数据/案例 |
|---|---|---|
| 安全漏洞 | SQL 注入、XSS、权限绕过 | 研究显示 36-40% 的 AI 生成代码存在安全漏洞 [1] |
| 调试困难 | 「regenerate until it works」 | 不理解代码，复杂 bug 时完全失控 |
| 技术债务 | 代码膨胀、架构混乱 | GitClear: 代码重复率增加 8 倍 [2] |
| 技能退化 | 调试能力是肌肉，不用会萎缩 | METR 研究：实际效率下降 19%（详见 5.2） |
专家观点 — Simon Willison
背景：独立开发者、数据新闻先驱、Django 核心贡献者、LLM 工具 Datasette 作者 来源：2025 年 3 月博文《Will the future of software development run on vibes?》[3]
「Vibe coding your way to a production codebase is clearly risky. Most of the work we do as software engineers involves evolving existing systems, where the quality and understandability of the underlying code is crucial.」
5.1.1 案例：Lovable 安全事件（2025 年 5 月）
这是 Vibe Coding 风险的典型案例。Lovable 是一个「用自然语言描述就能生成完整 Web 应用」的工具，正是 Vibe Coding 的代表产品。
事件经过 [4]：
text
┌─────────────────────────────────────────────────────────────────────┐
│ Lovable 安全漏洞时间线 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 2025.03.20 Replit 员工 Matt Palmer 发现漏洞 │
│ │ └─ 在一个 Lovable 生成的应用中发现权限问题 │
│ │ │
│ ▼ │
│ 扫描 1,645 个 Lovable 应用 │
│ │ │
│ ▼ │
│ 发现 170+ 应用存在同样漏洞 (CVE-2025-48757) │
│ │ └─ 303 个接口暴露，可未授权访问 │
│ │ └─ 泄露：用户名、邮箱、支付信息、API Key │
│ │ │
│ ▼ │
│ 2025.04.24 Lovable 发布 2.0，添加「安全扫描」功能 │
│ │ └─ 但扫描器只检查 RLS 是否存在，不检查是否有效 ⚠️ │
│ │ │
│ ▼ │
│ 2025.05.29 安全研究员公开披露漏洞 │
│ └─ Lovable 仍未有效修复 │
│ │
└─────────────────────────────────────────────────────────────────────┘漏洞根因：
Lovable 生成的代码缺少正确的 Row Level Security (RLS) 策略。攻击者只需要：
- 找到应用前端代码中嵌入的
anon_key（公开的） - 直接向 Supabase 数据库发送查询
- 绕过所有权限检查，读取/写入任意数据
研究者甚至成功修改了某应用的 payment_status 字段为 paid，绕过了整个 Stripe 支付流程。
更严重的问题：
Lovable 还被发现是「最容易被滥用来做钓鱼网站」的 AI 工具 [5]。安全公司 Guardio Labs 报告：
- 2025 年 2 月以来，每月检测到数十万个恶意 Lovable URL
- 6 月发现一个伪装 UPS 的钓鱼活动，发送了近 3,500 条消息
- 钓鱼网站模板在 Lovable 上是公开可复用的
教训：
AI 生成的代码「能跑」不代表「安全」。没有安全审查的 Vibe Coding，就是在给攻击者留后门。
5.1.2 技术债务的真实代价
专家观点 — Kin Lane
背景：API 布道师、Postman 首席布道师、35 年技术从业经验 来源：2025 年文章 [6]
「在我 35 年的技术生涯中，从没见过这么短时间内产生这么多技术债务。」
数据支撑：
| 指标 | 变化 | 来源 |
|---|---|---|
| 代码重复率 | 增加 8 倍 | GitClear 2024 研究 |
| 新增代码占比 | 46%（正常应更低） | GitClear |
| 重构代码占比 | 显著下降 | GitClear |
行业预测
Forrester 预测：未来 2 年将迎来 AI 编程导致的技术债务海啸。
text
┌─────────────────────────────────────────────────────────────────────┐
│ 技术债务的恶性循环 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ AI 快速生成代码 │
│ │ │
│ ▼ │
│ 开发者不完全理解 │
│ │ │
│ ▼ │
│ 出 bug → 让 AI 修 → 引入更多不理解的代码 │
│ │ │
│ ▼ │
│ 代码库膨胀、逻辑混乱 │
│ │ │
│ ▼ │
│ 维护成本指数上升 │
│ │ │
│ ▼ │
│ 「看起来很快」的团队实际上「在原地打转」 │
│ │
│ CodingIT (2025.03): │
│ 「一个过度依赖 AI 的团队可能一开始看起来很高效，但如果他们 │
│ 不断回头修复 AI 生成的烂摊子，他们其实并没有在前进——只是在 │
│ 原地打转。」 │
│ │
└─────────────────────────────────────────────────────────────────────┘5.2 技能退化：最重要的风险
行业警示
「今天跳过『艰难方式』的初级开发者可能会过早触及天花板，缺乏成长为高级工程师的深度。如果整整一代程序员『从未体验过真正靠自己解决问题的满足感』，从未经历过与 bug 搏斗数小时后的深刻理解，我们最终可能得到一批只能在 AI 指导下工作的按钮操作员。」
5.2.1 METR 2025 研究：感知 vs 现实
METR（一个 AI 安全研究机构）在 2025 年 7 月发布了一项严谨的随机对照实验 [8]：
研究设计：
- 招募了 16 名经验丰富的开源开发者
- 来自大型开源项目（平均 22K+ stars，100 万+ 行代码）
- 平均在项目上有 5 年、1500+ commits 的经验
- 随机分配任务：一半允许用 AI，一半不允许
- AI 工具主要是 Cursor Pro + Claude 3.5/3.7 Sonnet
惊人发现：
text
┌─────────────────────────────────────────────────────────────────────┐
│ METR 研究：感知 vs 现实 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 开发者的感知 实际测量结果 │
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ │ │ │ │
│ │ 预期 AI 能 │ │ 实际上用 AI │ │
│ │ 加速 24% │ │ 慢了 19% │ │
│ │ │ │ │ │
│ │ ▲ │ │ ▼ │ │
│ │ │ +24% │ │ -19% │ │ │
│ │ │ │ │ │ │ │
│ │ └────────────│ │───────────┘ │ │
│ │ 预期 │ │ 实际 │ │
│ │ │ │ │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
│ 任务完成后，开发者仍然认为 AI 帮他们加速了 20% │
│ │
│ 感知与现实的差距：39 个百分点 │
│ │
└─────────────────────────────────────────────────────────────────────┘为什么会这样？
研究者给出了几个假设：
- 过度乐观：开发者高估了 AI 的帮助，在本可以更快完成的任务上使用 AI
- 清理成本：很多开发者报告「花了大量时间清理 AI 生成的代码」
- 专家效应：这些开发者对自己的项目非常熟悉，本来就很快——AI 反而拖慢了
重要提醒：
这是 2025 年初 AI 能力的快照，不代表 AI 永远无用。但它说明：「感觉有用」和「实际有用」是两回事。
5.2.2 年轻开发者的就业困境
Stanford 数字经济研究 [9]：
| 指标 | 数据 |
|---|---|
| 22-25 岁软件开发者就业率 | 比 2022 年峰值下降近 20% |
| 2024 年入门级技术岗招聘 | 同比下降 25% |
| AI 高暴露岗位（含软件工程）就业变化 | 22-25 岁下降 6%，35-49 岁上涨 9% |
实习市场同样严峻：
- Indeed: 各行业实习岗位同比下降 11%
- Handshake: 技术类实习岗位自 2023 年下降 30%
- 与此同时，实习申请量上涨 7%
失业率对比（2025 年 6 月）：
| 群体 | 失业率 |
|---|---|
| 全国平均 | 4.2% |
| 22-27 岁 | 7.4%（近两倍） |
| 计算机工程毕业生 | 7.5% |
| 计算机科学毕业生 | 6.1% |
| 美术专业毕业生 | 7.5%（和计算机工程持平） |
讽刺的是：美术专业毕业生的就业率和计算机工程师一样了。
5.2.3 技能退化的四个征兆
根据多个信源总结 [7:1]：
text
┌─────────────────────────────────────────────────────────────────────┐
│ 技能退化的四个征兆 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 调试恐惧 (Debug Avoidance) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 以前：看报错 → 分析 → 定位 → 修复 │ │
│ │ 现在：看报错 → 复制粘贴给 AI → 不管它说什么都试一下 │ │
│ │ │ │
│ │ 后果：遇到 AI 也搞不定的问题时，完全不知道从哪下手 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2. 无脑复制粘贴 (Blind Copy-Paste) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 「代码能跑就行，不需要理解为什么」 │ │
│ │ │ │
│ │ 后果：代码改动时不知道会影响什么，改一处崩三处 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. 架构思维丧失 (Lost System Thinking) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 只会问「这个功能怎么写」 │ │
│ │ 不会问「这个功能应该放在哪里、怎么和其他模块配合」 │ │
│ │ │ │
│ │ 后果：系统越写越乱，最后只能推倒重来 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 4. 基础记忆衰退 (Memory Atrophy) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ API 语法忘了 → 问 AI → 下次还是忘 → 再问 AI │ │
│ │ │ │
│ │ 类似：长期用计算器，心算能力退化 │ │
│ │ │ │
│ │ 后果：没有网络/AI 时完全无法工作 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘一个 12 年老工程师的自白：
「不再阅读文档、调试能力下滑、变成人形剪贴板。」
他描述自己陷入了「依赖加深循环」——痛点在于失去了逐个 Bug 学习的机会。
5.2.4 物联网开发中的具体场景
作者观点
以下是针对物联网开发团队的场景分析，基于我的实践经验总结。
针对我们团队的工作，这些场景特别值得警惕：
| 场景 | 危险信号 | 后果 |
|---|---|---|
| 协议调试 | 串口数据解析不对，直接问 AI | 不理解协议细节，下次换个设备还是不会 |
| 硬件通信 | I2C/SPI 时序问题，让 AI 改延时 | 不理解时序原理，换个芯片又卡住 |
| 中断处理 | 中断丢失，让 AI 加锁 | 不理解竞态条件，埋下更隐蔽的 bug |
| 低功耗设计 | 功耗过高，让 AI 改休眠参数 | 不理解功耗模型，上线后电池很快耗尽 |
| 网络栈 | MQTT 断连，让 AI 加重试逻辑 | 不理解网络状态机，重试风暴打爆服务器 |
作者经历
Home Assistant 项目中，我让 AI 写了大量的设备通信代码。功能是跑起来了，但当某个设备返回异常数据时，整个系统卡死。我花了两天才定位到问题——如果当初自己写，可能一开始就不会犯这个错误，因为我会边写边想边界情况。
AI 写代码太快了，快到你来不及思考。
5.3 葵花宝典比喻：心智模型
text
┌─────────────────────────────────────────────────────────────────────┐
│ 葵花宝典心智模型 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 葵花宝典的特点： │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ ✓ 立刻获得巨大的能力提升 │ │
│ │ ✗ 代价是「自宫」—— 永久失去某些东西 │ │
│ │ ✗ 无法逆转 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ AI 编程的类比： │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ ✓ 立刻提升「出活」速度 │ │
│ │ ✗ 代价是「成长性」—— 失去深入理解的机会 │ │
│ │ ？ 是否可逆？—— 取决于你怎么用 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 关键区别： │
│ 葵花宝典是「练或不练」的二元选择 │
│ AI 编程是「怎么用」的光谱选择 │
│ │
└─────────────────────────────────────────────────────────────────────┘什么时候是「练葵花宝典」？
| 行为 | 为什么危险 |
|---|---|
| 完全不理解就部署的代码 | 出问题时无法调试，只能删掉重来 |
| 绕过基础知识直接实践 | 遇到边界情况没有判断能力 |
| 依赖 AI 做所有技术决策 | 失去架构能力，永远停留在执行层 |
| 从不阅读文档原文 | 只知道「怎么做」，不知道「为什么」 |
| 报错直接丢给 AI | 调试能力萎缩，没有 AI 就瘫痪 |
什么时候不是？
| 行为 | 为什么安全 |
|---|---|
| 错字检查、标点符号修正 | 机械性工作，不涉及核心理解 |
| 编码一致性检查 | Lint 工具本来就该做的事 |
| Best Practice 提醒 | 相当于有个资深同事提醒你 |
| 「让人从 1 写到 10000」 | 你理解逻辑，只是让 AI 执行重复 |
| 文档草稿生成 | 你会审核和修改 |
| 探索不熟悉的 API | 前提是之后你会理解它 |
专家观点 — Simon Willison [^55]
「如果 LLM 写了你代码的每一行，但你审查、测试、并理解了所有代码——那不叫 Vibe Coding，那是把 LLM 当打字助手。」
「我的黄金法则是：我不会提交任何我无法向别人解释的代码。」
text
┌─────────────────────────────────────────────────────────────────────┐
│ 判断标准：能不能向别人解释？ │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ ┌─────────────────┐ ┌─────────────────┐ │
│ │ ❌ 葵花宝典 │ │ ✅ 正常使用 │ │
│ │ │ │ │ │
│ │ 「这段代码是 │ │ 「这段代码做 │ │
│ │ AI 写的， │ │ 的是 XXX， │ │
│ │ 我也不太懂」 │ │ 原理是 YYY， │ │
│ │ │ │ 这样设计是 │ │
│ │ │ │ 因为 ZZZ」 │ │
│ └─────────────────┘ └─────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘5.3.1 另一个心智模型：模拟器而非实体
葵花宝典比喻讲的是「代价」，这里补充另一个心智模型，讲的是「本质」。
专家观点 — Andrej Karpathy
背景：前 Tesla AI 总监、OpenAI 联合创始人、斯坦福 CS231n 课程讲师 来源：2025 年 12 月 X 推文 [10]
「不要把 LLM 当作实体（Entity），要当作模拟器（Simulator）。」
为什么这个心智模型重要？
很多人把 AI 当成一个「有想法的人」来对话，问它「你怎么看」「你觉得呢」。但问题是：根本不存在「你」。
当你强行用「你」来提问时，模型会采用一个「人格嵌入向量」（personality embedding vector）——这是微调数据统计出来的「平均人格」，然后戴着这个「大众脸」的面具来回答你。
text
┌─────────────────────────────────────────────────────────────────────┐
│ 「你怎么看」的问题 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 你问：「你觉得 Rust 和 Go 哪个更适合写后端？」 │
│ │
│ 模型内部发生了什么： │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 1. 检测到「你觉得」→ 需要表达「观点」 │ │
│ │ 2. 但我没有真正的观点（我只是 token 预测器） │ │
│ │ 3. 于是采用微调数据中「被问这类问题时的平均回答模式」 │ │
│ │ 4. 输出一个「两边都说点好话」的平衡答案 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 结果：你得到的是「训练数据中最常见的回答方式」，不是深思熟虑的观点 │
│ │
└─────────────────────────────────────────────────────────────────────┘更好的问法：
不是问「你怎么看」，而是问「什么样的人适合回答这个问题？他们会怎么说？」
| 场景 | ❌ 实体思维 | ✅ 模拟器思维 |
|---|---|---|
| 技术选型 | 「你觉得该用哪个框架？」 | 「一个有 10 年后端经验的架构师会怎么评估这两个框架？」 |
| 代码审查 | 「这段代码有什么问题？」 | 「Google 的代码审查标准会指出哪些问题？」 |
| 学习建议 | 「你觉得我该学什么？」 | 「对于想转 AI 方向的后端工程师，业内专家通常建议的学习路径是什么？」 |
这和葵花宝典比喻的关系：
- 葵花宝典讲的是：不要跳过理解（代价是成长性）
- 模拟器心智讲的是：不要把 AI 当人（否则得到的是「平均意见」）
两者结合起来就是：把 AI 当成一个能模拟各种专家的工具，但最终判断和理解还是要靠你自己。
5.4 什么时候该用 / 不该用 AI
text
┌─────────────────────────────────────────────────────────────────────┐
│ AI 使用场景光谱 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 放心用 谨慎用 最好别用 │
│ ◄─────────────────────────────────────────────────────────────► │
│ │
│ · 拼写检查 · 业务逻辑实现 · 安全关键代码│
│ · 格式化 · 不熟悉的领域 · 架构决策 │
│ · 样板代码 · 性能优化 · 加密实现 │
│ · 文档草稿 · 并发代码 · 认证授权 │
│ · 单元测试 · 数据库设计 · 支付处理 │
│ · 代码解释 · API 设计 · 合规代码 │
│ · 重构建议 · 错误处理策略 · 你不打算 │
│ · 命名建议 · 第三方集成 理解的代码 │
│ │
│ 你完全理解 你需要仔细审查 你必须亲自写 │
│ AI 只是加速 AI 是参考意见 或深度审查 │
│ │
└─────────────────────────────────────────────────────────────────────┘详细对照表：
| 场景 | 推荐度 | 原因 |
|---|---|---|
| 拼写/语法检查 | ✅ 放心用 | 机械性，AI 很擅长 |
| 代码格式化 | ✅ 放心用 | 有确定性答案，容易验证 |
| 样板代码生成 | ✅ 放心用 | 模式固定，你知道应该长什么样 |
| 单元测试编写 | ✅ 放心用 | 逻辑由你定义，AI 只是实现 |
| 文档/注释草稿 | ✅ 放心用 | 你会审核修改 |
| 代码解释 | ✅ 放心用 | 帮助理解，不是替代理解 |
| 业务逻辑实现 | ⚠️ 谨慎 | 需要仔细审查边界情况 |
| 不熟悉的技术栈 | ⚠️ 谨慎 | 可以用来学习，但要验证 |
| 并发/多线程代码 | ⚠️ 谨慎 | 竞态条件很难测试出来 |
| 数据库 Schema 设计 | ⚠️ 谨慎 | 影响长期，需要深思熟虑 |
| 安全关键代码 | ❌ 最好别 | AI 经常引入漏洞 |
| 加密/认证实现 | ❌ 最好别 | 错一点就全错 |
| 架构决策 | ❌ 最好别 | 需要全局视角和权衡 |
| 你不打算理解的代码 | ❌ 绝对别 | 这就是葵花宝典 |
企业实践 — Oxide 公司
背景：硬件+软件公司，由多位前 Sun/Joyent 资深工程师创办 来源：RFD 576: Using LLMs at Oxide [11]
Oxide 在 RFD 576 中详细讨论了如何在工程团队中使用 LLM。核心价值观：
| 原则 | 解释 |
|---|---|
| 责任 (Responsibility) | 人类判断始终在环内，对所有输出负责 |
| 严谨 (Rigor) | LLM 应该锐化思考而非替代思考 |
| 同理心 (Empathy) | 考虑内容创作者（训练数据来源）和消费者（代码的维护者） |
| 团队合作 (Teamwork) | 保持真诚的沟通，不隐瞒 AI 参与 |
| 紧迫感的平衡 | 不为速度牺牲质量 |
他们特别强调的一点：
「LLM 不应该用于任何需要创造性或深度推理的核心工程任务。它更适合用于加速已经清晰的工作，而不是替代思考过程。」
5.5 成本意识
「效率 ≠ 用得多」
5.5.1 Token 使用的真实数据
通过 npx ccusage@latest monthly 可以查看 Token 使用统计。
值得注意的是，并不是 Token 用的越多就代表能力越强，Token 的效率才是关键。
Prompt Caching（2024 年 8 月起）
上图中的 Cache Create 和 Cache Read 是 Anthropic 2024 年 8 月推出的 Prompt Caching 功能 [12]：
- Cache Create：首次写入缓存，计费约 1.25x 普通输入价
- Cache Read：读取已缓存内容，计费约 0.1x（便宜 90%）
在 Claude Code 场景下，CLAUDE.md、项目文件等 context 会被缓存。第一次发送是 cache create，后续对话如果这些文件没变，就会 cache read。这就是为什么 Cache Read 比 Cache Create 多很多——同样的 context 被重复利用了。
5.5.2 为什么越聊越贵？
text
┌─────────────────────────────────────────────────────────────────────┐
│ 对话累积的成本问题 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 第 1 轮对话 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 你的问题 (500 tokens) → AI 回复 (1000 tokens) │ │
│ │ 输入成本: 500 tokens │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 第 2 轮对话 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 历史 (1500 tokens) + 新问题 (500 tokens) → AI 回复 │ │
│ │ 输入成本: 2000 tokens ← 包含了第 1 轮的全部内容 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ 第 3 轮对话 │
│ ┌─────────────────────────────────────────────────────────────┐ │
│ │ 历史 (3500 tokens) + 新问题 (500 tokens) → AI 回复 │ │
│ │ 输入成本: 4000 tokens ← 雪球越滚越大 │ │
│ └─────────────────────────────────────────────────────────────┘ │
│ │
│ ... │
│ │
│ 第 10 轮对话 │
│ 输入成本可能已经是第 1 轮的 20 倍 │
│ │
│ 这就是为什么 Claude Code 有 /clear 命令 —— │
│ 定期清空对话历史，重新开始 │
│ │
└─────────────────────────────────────────────────────────────────────┘5.5.3 Token 效率优化建议
| 建议 | 说明 |
|---|---|
定期 /clear | 任务完成或对话偏离时，清空重新开始 |
| 精简 CLAUDE.md | 不要塞太多内容，60 行以内最佳 |
| MCP 不要装太多 | 每个 MCP Server 的工具定义都占 Context |
| 具体的 prompt | 一次说清楚，避免来回澄清 |
| 分任务处理 | 大任务拆成小任务，每个任务独立对话 |
| 善用 Subagent | 让 Subagent 处理探索性任务，不污染主对话 |
5.6 七条实践建议：如何避免技能退化
综合多个信源 [7:2][11:1]，这是我总结的实践建议：
text
┌─────────────────────────────────────────────────────────────────────┐
│ 避免技能退化的七条建议 │
├─────────────────────────────────────────────────────────────────────┤
│ │
│ 1. 验证并理解 (Verify & Understand) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 对 AI 输出进行「红队」测试，逐行理解代码 │ │
│ │ 问自己：「这段代码为什么这样写？有没有更好的方式？」 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 2. 适度挣扎 (Struggle a Little) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 实施「无 AI 时段」，定期手写代码保持技能 │ │
│ │ 比如：每周抽一天不用 AI，或者新学技术先自己摸索 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 3. 先思考再求助 (Think Before Asking) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 花 15-30 分钟自己排查问题后才问 AI │ │
│ │ 这段时间的思考是技能成长的关键 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 4. 代码审查把关 (Code Review Gate) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 将 AI 生成代码纳入团队审查流程 │ │
│ │ 审查时问：「为什么选择这个方案？考虑了哪些替代方案？」 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 5. 积极迭代学习 (Active Learning) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 追问 AI 的设计方案背后逻辑 │ │
│ │ 「为什么用这个算法？」「有什么权衡？」「有什么缺点？」 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 6. 记录知识盲区 (Track Blind Spots) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 建立「AI 介入清单」识别薄弱环节 │ │
│ │ 如果某类问题总是要问 AI，说明你需要系统学习这块 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
│ 7. 结对编程心态 (Pair Programming Mindset) │
│ ┌─────────────────────────────────────────────────────────┐ │
│ │ 与 AI 互动而非单向使用 │ │
│ │ 把它当作会写代码的同事，而不是代码生成器 │ │
│ └─────────────────────────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────────────────┘5.7 我的亲历视角：找到自己的平衡点
作者观点
以下内容是我个人的经历和观点，不代表普遍情况。请结合你自己的实际情况做判断。
说实话，写这个 Part 的时候我有点心虚——因为我自己也在摸索这个平衡点。
我犯过的错误：
- Part 3 讲的 Home Assistant 项目，就是典型的「练葵花宝典」
- 有段时间几乎每个报错都直接丢给 AI，调试能力确实在退化
- 有些技术决策完全听 AI 的，事后发现它选了一个过度复杂的方案
我现在的做法：
- 新技术先自己摸索 30 分钟：哪怕看不懂也先硬着头皮看，有了基础认知再问 AI
- 每次 commit 前自问：「这段代码我能解释给别人听吗？」
- 保持一个「AI 帮我跳过了什么」的意识：如果发现某块知识完全是 AI 填的，会找时间补课
- 复杂 bug 先自己查 15 分钟：这段时间的痛苦是成长的代价
我的观察：
AI 编程最危险的地方不是「它会犯错」，而是「它太顺畅了」。
传统编程：遇到问题 → 卡住 → 查资料 → 尝试 → 失败 → 再尝试 → 成功 → 深刻理解
AI 编程：遇到问题 → AI 解决 → 下一个问题 → AI 解决 → ... → 什么都没学到
卡住的那段时间，恰恰是学习发生的时候。
AI 让我们跳过了这段时间。短期看是效率提升，长期看可能是成长的代价。
关键是找到平衡：用 AI 加速你已经理解的工作，而不是用它跳过你应该学习的过程。
[!TODO] 素材准备
- [ ] Token 使用统计截图（对比高效/低效的使用模式）
- [ ] 「AI 帮我跳过了什么」清单示例
- [ ] 团队层面的成本预估
参考资料
🔬 L1 | CCS researchers find GitHub Copilot generates vulnerable code 40% of the time | NYU - NYU 网络安全中心研究，另见 Vibe coding security risks | IT Pro 报道 36% 的 AI 生成代码存在安全漏洞。 ↩︎
📰 L2 | How AI generated code compounds technical debt | LeadDev - GitClear 2024 研究发现 AI 工具导致代码重复率增加 8 倍，重构代码占比显著下降。 ↩︎
📝 L3 | Will the future of software development run on vibes? | Simon Willison - Simon Willison 关于 Vibe Coding 的深度分析，提出「黄金法则：不提交任何无法向别人解释的代码」。 ↩︎
📰 L2 | Lovable Vulnerability Explained: How 170+ Apps Were Exposed | Superblocks - CVE-2025-48757 漏洞详解，170+ 应用数据泄露事件。另见 Semafor 报道。 ↩︎
📰 L2 | Lovable AI Found Most Vulnerable to VibeScamming | The Hacker News - Guardio Labs 报告 Lovable 最易被滥用于钓鱼攻击，每月检测到数十万恶意 URL。 ↩︎
📝 L3 | Vibe Coding and Technical Debt | Prodyssey - API 布道师 Kin Lane：「35 年技术生涯中从没见过这么短时间内产生这么多技术债务」。 ↩︎
📝 L3 | 如何避免在 AI 时代技能退化 | 宝玉的分享 - 中文译文，原文详述技能退化的四个征兆和七条实践建议。 ↩︎ ↩︎ ↩︎
🔬 L1 | Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity | METR - METR 2025 年 7 月发布的随机对照实验，发现开发者感知 AI 加速 20%，实际慢了 19%。另见 arXiv 论文。 ↩︎
📰 L2 | AI vs Gen Z: How AI has changed the career pathway for junior developers | Stack Overflow - Stanford 数字经济研究数据，22-25 岁软件开发者就业率比 2022 年峰值下降近 20%。 ↩︎
💬 L4 | Don't think of LLMs as entities but as simulators | Andrej Karpathy - 2025 年 12 月 7 日推文，提出「LLM 是模拟器而非实体」的心智模型，解释 personality embedding vector 概念。 ↩︎
🔬 L1 | Oxide RFD 576: Using LLMs at Oxide - Oxide 公司关于企业级 LLM 使用的详细策略文档，强调责任、严谨、同理心等核心价值观。 ↩︎ ↩︎
🔬 L1 | Prompt Caching | Anthropic - Anthropic 于 2024 年 8 月推出，可降低重复 context 的成本达 90%。 ↩︎