AI让编程提速，却为何让我感觉技术变差了？

一位资深开发者的自述在技术社区引发共鸣：他用 AI 辅助学习 Svelte 和 Go，几天内就完成了一个个人仪表盘项目。功能全都跑通了，但当他回头看代码时，却发现自己几乎看不懂。速度的提升，是否正在悄悄侵蚀开发者的核心能力？

一个实验：用 AI 学新框架

这位开发者有多年 React、Node.js 和 Python 经验，日常工作并不需要接触新东西。出于好奇，他决定用 AI 辅助上手 Svelte 和 Go，目标是做一个整合 Jira 工单、PR、构建状态和会议信息的个人仪表盘。

他采用逐功能推进的方式，每个模块完成后测试 UI，让 Copilot 补充文档，遇到报错就贴日志让 AI 帮忙修复。几天后，仪表盘顺利完工。表面上看，这是一次高效的学习实验。

Svelte 是一个编译型前端框架，与 React 在运行时处理虚拟 DOM 不同，它在构建阶段就把组件编译成高效的原生 JavaScript，因此运行时开销更小、包体积更轻。其核心特色是响应式声明和较少的样板代码，开发者只需声明状态与视图的依赖关系，框架会自动追踪更新。

Go（Golang）是 Google 推出的静态类型、编译型语言，以简洁语法、原生并发（goroutine 与 channel）和快速编译著称，常用于后端服务、CLI 工具和云基础设施。

这两个技术栈的定位差异很大：Svelte 面向界面层，Go 面向服务端逻辑。对于长期使用 React/Node.js/Python 的开发者来说，两者的心智模型都与既有经验不同——Svelte 的编译期响应式不同于 React 的运行时重渲染，Go 的显式错误处理与并发模型也不同于 Node 的事件循环。这正是 AI 辅助学习容易让人“跳过理解、只拿结果”的典型场景。

功能跑通了，但代码不属于我

问题出现在他仔细阅读代码的那一刻。他理解整体架构，因为架构决策是他和 Copilot 讨论出来的；但具体到 Svelte 和 Go 的实现细节，他发现自己几乎无法独立追踪。

如果现在要他修一个 bug 或加一个小功能，他得先把整个代码库调试一遍——而这恰恰是他启动这个项目的初衷。

他总结道：“我并没有真正学会 Svelte 和 Go，我学会的是如何让 Copilot 用 Svelte 和 Go 来构建东西。”这两者之间的差别，远比想象中重要。

效率提升背后的隐性代价

让这位开发者不安的，不只是技术上的陌生感。他发现自己失去了那种“卡住—挣扎—最终解决”的满足感。过去，一个难题可能耗费数小时甚至数天，但解决后的成就感源于对问题真正理解。而这次，他拿到了完成品，却几乎没有经历这个过程。

更微妙的是，他产生了一种奇怪的 FOMO——即使刚完成一个项目，也在焦虑自己“用 AI 用得不够多”。同时他开始怀疑：让 AI 处理每一个困难环节，自己究竟放弃了多少练习机会？

FOMO（Fear of Missing Out，错失恐惧）指因担心错过他人正在经历的有价值体验而产生的焦虑。在 AI 编程语境中，这种焦虑表现为：即便刚完成一个项目，仍担心自己“AI 用得不够多、不够快”，从而不断把更多环节交给 AI 处理。

它的风险在于，决策依据从“我是否真正理解并掌控这段代码”悄悄滑向“我是否跟上了 AI 的节奏”。前者关乎工程质量和长期能力，后者只关乎速度与同侪比较。当 FOMO 主导选择时，开发者会主动放弃那些进度慢但收益高的环节——比如手动调试、逐行阅读、独立设计——最终形成“用得多、懂得少”的循环。识别这种情绪，是把 AI 放回工具位置的第一步。

保持参与感的七个实践

为了在效率和理解之间找到平衡，他调整了自己的工作方式：

• 理解交付物：速度固然好，但不想拥有一个离开聊天窗口就不敢碰的代码库。
• 拆分小工单：把功能拆成可管理的任务，向 AI 提供上下文，而不是“这是我的想法，等应用做完再见”。
• 编码前讨论：利用 plan mode 让 AI 反问澄清问题，质疑不合理的建议，有时用另一个模型审查计划。
• 遇到陌生概念就暂停：比如 AI 建议使用断路器模式时，先去学习它是什么、是否真的需要。
• 实现后审查：在合适场景用更便宜的模型，有时让规划模型检查实现。
• 自己读代码并测试：不懂就问或单步调试，改动越小越容易理解。
• 提交后进入下一个工单。

这套流程比让 AI 全自动慢不少，但仍快于他过去的工作方式，而且没有跳过他想学习的部分。

plan mode（计划模式）是指在使用 AI 编码工具时，先让模型输出实现方案、步骤拆解与潜在风险，而非直接生成代码的模式。它把交互重心从“产出代码”前移到“对齐思路”，让开发者有机会在动手前质疑假设、补充约束、否决不合理设计。

与直接生成相比，plan mode 的价值在于：一是暴露 AI 的推理过程，使隐藏的误解提前浮现；二是保留开发者的架构决策权；三是便于用另一个模型或人工审查计划。许多 AI 编码工具（如 Cursor、Copilot、Claude Code 等）都提供类似机制。它本质上是一种“先讨论、后编码”的纪律，也是把 AI 从代笔者转变为协作者的关键开关。

断路器模式（Circuit Breaker Pattern）是一种容错设计：当某个外部依赖（如远程服务、数据库）连续失败达到阈值时，系统会“跳闸”，在设定时间内直接拒绝请求，而不是持续等待超时或反复重试。

它有三个状态：闭合（正常放行）、断开（快速失败，不调用依赖）、半开（放行少量请求探测依赖是否恢复）。好处是防止故障级联、减少资源浪费、给下游恢复时间。它在分布式系统和微服务中非常常见。

对学习者而言，这个模式值得被当作“陌生概念暂停”的典型：AI 可能在不需要的场景也建议引入它。先理解它解决什么问题、当前系统是否真的存在该风险，再决定是否采用，而不是照单全收。

在 AI 时代重新定义“开发者”

这位开发者的经历触及了一个行业性矛盾：AI 工具确实在加速交付，但速度的代价可能是开发者对代码库的深层理解。当生产环境出问题时，需要向团队解释的仍然是开发者本人——Copilot 不会参加故障复盘会。

他并不打算放弃 AI，但希望在流程中保持足够的参与度，让代码真正属于自己。这种平衡或许正是 AI 辅助编程时代最值得练习的技能：不是拒绝工具，而是在工具的加速中守住理解力。