好奇心周刊第24期: 关于AI编程的一些体会和设想

—— 如何看待及用好 Code Agent，以及作为程序员应该做什么

本文为好奇心周刊第24期，全部周刊参见：周刊系列。

最近两个月，深度体验了Claude Code, Gemini CLI, Codex 等几款命令行 AI 编程工具，也体验了 Lovable 这种 Web 类 AI 编程工具，其中对 Claude Code 和 Gemini CLI 使用最为高频，几乎每天都会用到。本来打算写一期关于 Claude Code 和 Gemini CLI 的特性洞察的周刊，但我发现这种介绍文章在网上太多了，而且这些 AI 编程工具更新迭代极快，Claude Code 甚至每天都发布新版本。对于 AI 工具，看一百篇介绍文章不如实际动手试一次。所以再写洞察或介绍之类的文章意义不是很大，而是改成总结下我最近两月的使用感受，以及个人的一些看法和对未来的预测。

impression-sunrise

题图：《印象·日出》【法】克劳德·莫奈 Claude Monet, 1872

以 Claude Code 为代表的 Code Agent 与此前 GitHub Copilot, Cursor(现在也支持 Agent 模式了)等 AI 编程工具完全不同，这种区别属于代际跨越，可以理解为是智能驾驶中 L4甚至是L5 和 L2、L3的差异。

在 GitHub Copilot 和早期版本 Cursor 这种 “传统”AI编程中，实际上应该叫 “AI 辅助编程”，正如 Copilot 名称所寓意的那样，AI 是辅助程序员编程。而 Claude Code 这种 Code Agent，则是 “AI 编程”，AI 成为了编程的主角。用户告诉它一个任务，在很多情况下它可以自主完成，小到一个功能优化，一个问题修复，大到一个重大特性、模块重构，甚至是一个网站或应用，它都可以自主完成。

我从去年11月开始订阅 Claude AI Pro, 接着便尝试使用 Claude Code, 开始由于我并不知道切换模型，便使用默认的 Haiku 4.5 生成了一个 Nextra 文档网站，我除了告诉它一些要求外，并没有做任何干预，然后它就把网站生成并调试运行成功了，虽然网页还有些小 bug, 但已经让我非常吃惊了。当时我同样尝试了 Codex (gpt-5.1-codex-max) 和 Gemini CLI (gemini-2.5), 都没能顺畅的运行。我便认定了 Claude Code, 后来发现还可以切换到更强大的模型 Sonnet-4.5, 而等到12月 Opus-4.5 也对 Pro 用户开放后，我便几乎每天都用 Claude Code.
Code Agent 的竞争力是大模型能力，而大模型 API Token 就是生产力。

如果说 Haiku-4.5 和 Sonnet-4.5 已经让我可以解决大部分 Web 类编程的问题了，而 Opus-4.5 则是让我“沉迷”上了 Vibe Coding. 由于工作网络原因不能使用 Claude Code, 因此只能在晚上回家和早上起床后使用 Claude Code, Claude Code + Opus-4.5 对模型 API Token 消耗极大，基本上每次交互三四次就消耗掉了五小时时间窗的限额，根据 Anthropic 的规则，需要在下一个五小时才能继续使用。就算这样，对于可怜的 Pro 账户来说，基本上不到一周就会耗尽周限额。

前不久，Claude Code 的创始人 Boris Cherny 在 X 上分享他使用 Claude Code 的经验：他会并行开五个窗口，并行指挥 Claude Code 编程和处理任务，这样的效率提升是巨大，但“代价”也是巨大的。所以很多程序员都订阅了 Claude AI Max 5x(100美元每月) 甚至是 Max 20x(200美元每月) ，而很多企业也考虑其生产力提升给员工订阅 Claude AI。最近一则消息是微软鼓励内部员工使用 Claude Code. 越来越多的程序员依赖 Claude Code 编程，以至于每次 Claude 出故障，网络上都会成为热点，程序员们都停工停产了。

可以预见的是，越来越多的企业会将为员工提供类似 Claude Code 和更大规格的 AI Token 来作为员工福利，就像二十年前比拼员工食堂，十年前比拼办公设备、人体工学座椅等。2026年企业招聘员工的吸引条件可能会变成“模型不限，Token管饱”之类的福利措施。
把 Code Agent 当成一个能力极强的程序员，而非只是一个工具箱。

尽管在 AI 是不是工具这个话题很有争议性，但我认为如果单纯把 Code Agent 当成传统工具来看待，那就大大限制了它们的能力发挥。我在新起项目或任务的时候，总会问 Code Agent 如何规划设计，或者是如 Boris 那样使用 plan mode. Plan 模式其实是 Claude Code 自己在规划，我只需要对它的问题给予反馈即可。Gemini CLI 虽然没有 Plan 模式，但它有 /constructor 扩展，我在实际应用中则会让 Gemini CLI 生成 TODO list, 来规划任务。最初在探索 Claude Code 的时候，我让它设计一款类似 Claude Code 的 Code Agent CLI 工具，它则非常详细地列出了待办清单，我只需要按照待办清单的内容依次下达命令给 Claude Code. 最后，花了大约两周时间，Claude Code 写了约两万行代码，一个功能、交互都很完善的 Code Agent 命令行工具就做出来了。

网上有很多文章介绍 Claude Code 等 Code Agent 的使用技巧、定制配置，我对其必要性表示怀疑。Boris Cherny 在介绍他的经验时，也提到他几乎是开箱即用，没有做什么配置：”My setup might be surprisingly vanilla! Claude Code works great out of the box, so I personally don’t customize it much. “当然，Boris 也许是在宣传他们 Claude Code 强大的原生能力。

我也有类似的经验体会。尽管自从 Anthropic 推出 Agent Skill 后，这个概念就一直很火，但我并没有用。在个人项目和通用编程场景中，我暂时还没遇到必须使用 Skills 的情况。也许跟我使用 Claude Code 主要都是个人项目有关，但我觉得，Skill 可能更适用于特殊业务场景，软件编程场景并非必需。

之前，Anthropic 员工做技术分享时说”Don’t build Agents, but build Skills”. 诚然，这是针对n8n, Langraph 那些所谓的 Agent 平台说的。有一个形象的比喻，大模型就是一个超级聪明的博士，但博士到了新企业也不懂企业流程的做事方法，因此 Skill 就像是企业的工作手册，教博士一步一步操作。但软件编程方法大多是通用的，而 Anthropic 等大模型公司都把编程作为大模型最主要的应用场景，所以其编程能力自然是具备的，在 Code Agent 的加持下，目前还没有遇到要使用 Skills 的场景。当然，某些企业为了管理的需要，增加了一些对软件编程的管理流程和规则，这些可能是软件团队要使用的 Skills 的原因之一吧。但我认为，这些基于传统软件开发而形成的管理流程和规则，将会在 AI 编程的时代被取代。
指令并不是越全面越详细越好，给 AI 更多的自主，会带来惊喜。

这个观点可能也是违反主流认知的。

自从 Vibe Coding 流行以来，另外一个软件工程概念也开始流行：SDD (Spec-Driven Development，规范驱动开发) 。简单的说就是，SDD 要求在 AI 生成代码之前，先编写一套详细、结构化的规范（Specification/Spec）。在复杂工程中，SDD 有助于构建严谨的编程框架，引导 AI 生成更符合预期的代码。

但我认为，SDD 并不是越详细越好，也并非适用各种场景。还是以我的经验举例，由于我使用 AI 开发的大部分为 Web 应用，这类项目可以说是 AI 编程最擅长的领域，因此我认为与其我用自己并不系统的知识面去约束 AI, 还不如让它自主决策更好。因此，我一般都是给 Claude Code 或 Gemini CLI 下发简单的语句指令，然后验收成果。由于我希望 Vibe Coding 的同时也能学英语，因此我都是用英语与之对话交流。考虑到我蹩脚的英语很可能传递错误的意思，因此我在下达指令前，会在 Gemini 网页上让它优化下我的英语，而 Gemini 除了纠正语法和优化语句外，还识别到我是在 Vibe Coding, 因此也会提供一份更详细的分解成具体执行步骤的指令给我。但我一般不会取用该指令，只是用能够清楚表达需求的英语语句给到 Claude Code. 而实际上，我也做过对比发现，很多时候简单指令比具体指令生成的效果更好。当然，这也得分场景。如果是问题定位和解决，那我会把详细报错信息和场景描述尽可能描述详细。

下面，举一个实际的例子。我用 Gemini CLI 做了一个静态博客网站，用在周刊上。我不太满意归档页的设计，年份字体太淡了，看着不太清楚，年份字体也太大了，整体不协调。我没有直接指出字体色重的问题，而仅仅是告诉 Gemini CLI：我不满意归档页面的风格，请重新设计并实现，力求优雅。

Gemini CLI 开始思考并计划。令我惊喜的是，它立刻识别到了年份字体的问题，还考虑优化月份和列表，并且实现了页面滚动时在当前列表所在年份范围内年份固定显示。优化后的效果令我非常满意，完全超出了我的期望。而如果我明确告诉它修改年份字体，那它可能只会根据我的要求做符合我期望的修改。

优化后的页面效果如下：

AI 的能力远超过我们自己，我们要想的是尽可能激发它，而不是约束它。
传统软件工程将会消亡。

2024年初，我写了一篇回顾软件工程历史的文章《银弹飞过先锋大厦》，这篇文章写得太长，以至于我没有把观点表述得简洁明了，我的观点隐藏在了结尾的这句话中：“大模型的AI时代正在来临，我大胆预测大模型是软件开发的银弹”。那个时候，我用 ChatGPT 来生成代码来举例，而现在 Claude Code 的生成代码能力不知道翻了多少倍。这种进化速度更加强化了我的观点：“大模型是软件开发的银弹”。

“软件开发的银弹”这个概念是弗雷德·布鲁克斯提出的，由于我那篇文章有详细阐述，这里不再赘述，感兴趣的读者可以参看该文。他认为“没有银弹”，因为可见的未来“不会有任何技术或管理上的突破能使软件工程的生产力得到数十倍的提升”。但大模型的发明改变了这一切。Anthropic 刚发布 cowork, 可以理解为是非编码领域的 Claude Code, 类似 Manus 的通用 Agent 工具。在 X 上，有人问 Boris 有多少代码是 Claude Code 写的，Boris 回答：全都是。而 Claude Code 自身 80%-90% 的代码也由 Claude Code 写成。

Boris 在 X 上回复说 cowork 全部由 Claude Code 编写

“银弹”意味着传统软件工程的历史使命将会终结，软件工程的诞生是因为“软件危机”，而软件危机的本质是因为软件项目膨胀后，个人或小团队无法处理其复杂性而导致的一系列质量问题。因而从上世纪六十年代到目前的软件工程一直致力于通过管理和工程手段来消减复杂性，比如角色分工、瀑布流程、敏捷迭代、CICD、微服务。而大模型将会接手程序员处理软件复杂性的工作，软件工程也可能不再适用。这里我暂不展开，后面会考虑单独写一篇文章。
向 AI 学习，学习技术，学习编程，探索各种可能性。

软件工程中的角色分工不但将消失，高级程序员、初级程序员这种级别的区分也可能消失，或者换句话说：程序员能力的评价标准将从纯粹的代码编写能力转向系统性思维、需求洞察和 AI 协作能力。软件从业人员可能不再像以前那样区分产品经理、架构师、开发、测试等角色，而是融合性的角色。程序员可能不是通过自己编码来提升技能，而是要向 AI 学习编程、学习技术。

这让我想到了当年柯洁在与 AlphaGo 对弈后连输三局后中途退场大哭，他发现对方无法战胜。赛后，他平静了心情，在微博上写道：“重新学围棋”。柯洁感叹 AlphaGo 对围棋的理解超出了人类的想象，颠覆了人类几千年来形成的思维定式，AlphaGo 的出现是围棋届的幸事，棋手们可以重新认识和定义围棋。

虽然目前的大模型和 Code Agent 在软件编程方面还有达到 AlphaGo 在围棋方面绝对领先的优势，但这种趋势是很明显的。而柯洁的感悟给给了我启发，通过与 AI 的交互来探索对系统、对编程的理解，学习新技术，探索未知领域。我在使用 Claude Code 的时候也没有用 --dangerously-skip-permissions 的自主模式，倒不是因为我不相信它，而是因为我想要在过程中能够与 Claude Code 实时互动，并观察它的思考和执行过程。在这方面，我觉得 Gemini CLI 做得比 Claude Code 好，Gemini CLI 会详细展示其思考过程，这些思考过程也能反向触发我自己的思考。