迎接编程的新纪元

如果你一直觉得每出现一个新工具，只不过是让生产力略微提高一点，那么现在该换个问题问了。眼下发生的变化不是简单的自动化，而是在改写开发者把时间花在哪里。这篇文章记录了过去几个月里，我如何切身感受到这种变化，以及我是依据什么标准开始接受它的。

问题不在速度，而在角色的迁移。

3个月前的我#

就在3个月前，我还把生成式 AI 只当成一个非常聪明的自动补全工具。

第一次用 GitHub Copilot 时，我确实惊叹过。写下函数名或留一段注释，它就能补出一份像模像样的实现，减少重复劳动这点也很明确。但也仅止于此。我认为它最多只是一个稍微提升生产力的工具，还不足以改变开发者这个角色本身。

之后我又试了 Gemini CLI。在终端里像对话一样生成和修改代码，这种体验相当新鲜。它看起来比 Copilot 交互更自然，对上下文的理解也更好。即便如此，我的判断依然差不多。我仍然相信，它终究只是更进化了一步的工具，真正的设计和关键判断依旧是我的责任。

后来我接触到了 Cursor。整个 IDE 与 AI 融合在一起的体验，确实和之前不同。看着它跨文件修改代码、一定程度上把握项目结构、甚至提出重构建议，我感觉它又往前迈了一步。即便如此，我还是认为，复杂的业务逻辑和架构设计最终仍要由人牢牢握在手里。坦白说，我也相信自己的位置不会被轻易撼动。

现在回头看，那时的我把变化的速度看得太浅了。真正的转折点，其实是从 2025 年 11 月底 Opus 4.5 发布开始的。

被狠狠打醒#

让我改观的契机并不戏剧化。这个博客本身的开发和运营，就是证据。

博客服务本身并不是最高难度的实现。可如果放在以前，从规划、做页面、整理部署形态，到梳理各种细碎的连接工作，少则几天，多则几周，都是我会预估的时间。可现在，这类工作在很短的时间里，大约一天之内，就能搭起来。

只靠几次 prompt，就把设计、实现、收尾和发布准备一路推到可发布阶段，这种体验比我预想的要激进得多。

现在，编程代理带给我的感受是恐惧。

因为我切身感受到，自己多年积累的熟练度，可能会比想象中更快地被压缩成另一种形式。过去我一直以线性的方式理解 AI 编程工具的发展。从 Copilot 到 Gemini CLI，再到 Cursor，我以为它们只是一步步变得更好。可到了某个时刻，这种变化却像是一下子填平了原本空洞而遥远的那道鸿沟。

对那些还没有真正体验过 Claude Code 与 Opus 4.5 组合的人来说，这篇文章可能听起来有些夸张。几个月前的我，大概也会这么想。但现在回头看，这已经不是写代码稍微更方便了一点而已，而更像是在重新定义，开发者究竟应该把时间花在哪里。

从恐惧到标准#

我觉得没有必要刻意掩饰，最先涌上来的情绪就是恐惧。因为实现速度越快，就越容易让人感觉开发者的价值在缩水。

事实上，行业里一直在谈一个时代正在到来：个人，尤其是更接近 application builder 的角色，也能做出产品；更少的人，也能做出更大的结果。以前我听到这些话，会觉得多少有些夸张。但在亲身感受到之后，这些话的分量完全不一样了。

但结论并没有那么简单。我并不认为人的角色会消失。恰恰相反，随着更少的人能做更大的事，单个人的判断力和审查标准反而变得更重要。

以前，实现速度往往是团队最大的约束。现在，更重要的问题变成了：要做什么、按什么顺序验证，以及要在哪里控制风险。

在这个节点上，我抓住的标准有三条。

• 清晰地定义问题
• 设计出 AI 能理解的上下文
• 由人对最终结果负责

技术越快，这三条反而越重。

工具的进化，以及 Claude Code#

如果把我体感到的这条演进路线简单总结一下，大概是这样。

• Copilot 更接近自动补全。你先定方向，它负责迅速把下一步接上。
• Gemini CLI 更接近对话式助手。通过提问和回答，逐步把结果做出来。
• Cursor 像一个聪明的结对程序员。它会尝试理解项目上下文，并和你一起把实现往前推。

相比之下，Claude Code 给我的感觉更像是又往前迈了一步的代理。你给它一个目标，它会查看相关文件、理解结构、串起必要的改动，并一路思考到那些需要确认的节点。

当然，结果并不总是完美。但关键差别在于，我会迅速从亲手写每一行的人，转向负责定方向、给标准、审结果的人。

所以现在，我的角色已经不只是实现者，而更接近架构师和审阅者。比起代码打得多快，更重要的是决定把什么目标拆成什么粒度去委托，什么可以自动化，什么必须由我一直亲自确认到最后。

现在的我#

现在我会积极使用 AI 来开发。仅仅说生产力提高了，已经不足以描述工作方式变化有多大。以前要花好几天的功能，如今一天之内就勾勒出轮廓，也并不罕见。

但这并不意味着人的角色变小了。恰恰相反，安全、异常处理、数据一致性、结构一致性，以及产品判断，都以更重的责任回到了人身上。

一个很有意思的变化是，开发速度本身已经不再是瓶颈。以前，核心约束是这个功能要花几天才能做出来；现在，更重要的是这个功能到底有没有必要、要用什么标准去实验和验证，以及产品的第一版做到什么程度就算成立。比起技术极限，判断质量对结果的影响正在变得更大。

所以最近，我会在开始之前先把功能的目的、成功条件和排除范围写成句子。然后把工作拆成更小的单元，最后再把必须由人直接审查的项目分离出来。我越来越觉得，用好 AI 不是模糊地提出更多请求，而是先建立更明确的标准。

接下来#

我的目标很明确。我要在更短的时间里做出生产级的服务，并把这个过程变成一种可重复的方法。

对现在的我来说，开发已经不只是写代码，而是把产品拉到一个即使放进真实运行环境也能站得住的水平。我想亲自看看，这种变化究竟能走到多远。

所以我会继续写这个博客。它不会只是一个整理结果的空间，而会成为一份记录：记录我如何接受这些工具、在哪些地方改变了视角，以及我正以什么标准去适应它。无论成功还是失败，我都相信，这个时期的想法和试错都值得留下来。

编程的新时代不是在抹去开发者的角色，而是在把它压缩得更集中、更清晰。重心正在从亲手写下每一行代码的时代，转向定义正确的问题并验证结果的时代。

我认为，未来的差距，不会取决于谁能产出更多代码，而会取决于谁能更快地反复做出更好的判断，并生成真正具备可运营性的成果。