Matrix 首页推荐

Matrix 是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。

文章代表作者个人观点，少数派仅对标题和排版略作修改。

2025 年，我的工作习惯彻底被 Claude Code、Cursor 和 Codex 改变了，它们给我带来的改变，不亚于当年我用易语言写出第一个应用程序。同时这句话不仅适用于我的产品经理身份，也同样适用于我的工程师身份。

对我来说这不仅是软件开发效率的提升，也是软件开发方式的重构。

我说的是哪种 AI Coding

在社交媒体上讨论 AI 编程时，很多时候大家其实没有对齐在讨论的 AI 编程范畴和适用领域。所以大部分情况下大家在鸡同鸭讲，公说公有理、婆说婆有理。在我们真正讨论 AI 编程之前自然需要先澄清一下，我们到底在讨论什么「AI Coding」？

目前来说， AI Coding 有几种不同的产品和用户交互形态，包括：

1. L1：古典的 ChatGPT 交互问答。有问题直接问 ChatGPT、Gemini、Claude 等 AI 助手，借助 AI 助手给出的信息，自行 Debug 和修改代码。
2. L2：IDE / 插件中提供的补全功能。直接写函数名，然后 AI 会帮你补全函数的细节，你再自己微调或者不微调。这种能力其实过去也有，只是没有这么强悍。大家使用 IDE 来开发，很大程度上就是在利用 IDE 极佳的补全能力。
3. L3：本地 AI Coding 工具的 Agent 模式，全托管或半托管式编程。你只描述需要做什么，具体做动作由 AI 来完成；这里还有几个细分的方式，包括完全托管（比如 Claude Code 开 –dangerously-skip-permissions、Codex 开 –dangerously-bypass-approvals-and-sandbox）和半托管（用户手动确认行为，只是由 AI 来完成具体修改的动作）。L3 操作的是你的本地环境，有破坏的风险，但也有无限的可能。
4. L4：使用网页端的 AI Coding 工具直接出 Demo。不需要在本地配置任何开发环境，直接在网页端完成 Coding，你只需要描述你想要的东西，剩下的完全交给 AI（虽然这往往意味着难以与复杂的本地业务流集成）。

所以大家在社交媒体上和别人讨论 AI Coding 的时候，很有可能你在聊 L3、但别人在聊 L4。看似聊的是一个东西实际上完全不同。我们这篇文章讨论的则主要是 L3 —— 即使用本地的 AI Coding 工具的 Agent 模式，全托管或半托管式编程。

为什么是 Agent 模式

说完了大家眼中不同的 AI Coding 工具，我也必须再强调一下，即使大家聊的都是「AI Coding 工具的 Agent 模式」，因为身份不同，每个人的用法也会有很大差异，大家对工具的预期也完全不同。

因此对 Agent 模式的评价大体也可以拆分为三个大类：

1. 传统的软件工程师：使用 AI Coding 工具完成自己工作过程中的一些辅助性工作，对于自身的能力和工作的要求有较高的要求。
2. 有一定研发概念的产品工程师（称之为产品工程师是因为他们有一些基础的软件工程概念）：使用 AI Coding 工具拓展自己的能力圈，去做一些之前必须依赖软件工程师才能做完的事情（比如做个小 Demo，或是上线一个软件产品）。
3. 被媒体上的文章忽悠进来的小白（他们基本上没有太多的软件工程经验和基础）：跟着网络上的信息了解到了 Coding Agent，然后尝试在不同的软件上使用（不局限于 Claude Code，Cursor 的 Agent 模式也算），经常会卡在一些软件工程的基础问题上。（我特别推荐这类人去看《计算机教育中缺失的一课》，看完以后，会让你很快理解你所遇到的问题，并能够快速处理 AI Agent 所给你的信息，进行下一步操作）。

而之所以是 Agent 模式，相比于补全模式需要你有一段现成的代码，Chat 模式往往不指引你完成所有的工作、或需要你有一定的互联网软件基础，Agent 模式自带的环境操作能力，能让你即使完全不懂 AI 和 Coding，也可以做一个像模像样的小应用出来。

这打破了过去需要软件工程师才能做出一个 Demo 的限制，同时也极大地鼓励了新手小白，人人都想试着做一些有意思的事情。Agent 模式也是 AI Coding 最出圈的一个特性。

我与 AI Coding 的 Agent 模式

在这条推上，我提到我经历过三种不同的状态，这源自于我过去一年的体验。

在过去这一年里，我从一个「以补全为主，抗拒 AI Coding Agent」的工程师，转变为了一个「好好利用 AI Coding Agent」的工程师。当中离不开我身边的朋友们和小伙伴们，和他们的协作让我真的意识到了 AI Coding Agent 的价值¹。

作为一个写了十数年代码的工程师，我拥有一些自己平时写代码的「脚手架」，可以帮助我快速完成一个项目，而同时出于工程师的自我要求，我希望我自己写的代码能够拥有不错的代码质量和性能。

所以在一开始我对于 AI Coding Agent 的能力是持怀疑态度的，虽然依然会使用，但整体信任度没有那么高，往往只让它处理细枝末节，比如让 AI 去写一个完整的功能的细节，或者是让 AI Coding Agent 去 Code Review，基本不会让它动业务代码。

直到 Claude Sonnet 3.7 的时候，我才发现 Claude Code 已经能完成不少的工作，甚至很多小的功能也不再需要我先行规划、再让它自己做细节。我可以非常坦然的交给它一些工作，而我只做关键验收。从这个时刻开始，我对于 AI Coding Agent 的使用频率与日俱增，我开始使用 AI Coding 去实现越来越多的功能和效果，并最终对 AI Coding 放权——开启了 --dangerously-skip-permissions ，让 Claude Code 自己去写代码，去实现效果。

和所有使用 AI Coding Agent 的人一样，我也经历过 AI Coding 工具将代码整的一团糟然后放弃的时刻。不得不说，Claude 有些时候的过度设计真的让人无语。所以即便这就是最佳实践，但最佳实践不仅仅要配合着实践用，也要配合着项目时间节点和周期，以更好的完成项目的目标 —— Coding 只是完成目标的手段，而不是目的。

我对 AI Coding Agent 模式的看法

首先，我得旗帜鲜明地表明，所有软件工程师都应该试着使用 AI Coding Agent。

放弃、逃避、蒙头装鸵鸟都是没有意义的，熟练掌握 AI Coding Agent 已不再是加分项，而是生存技能。AI Coding Agent 正在切实地改变着我们的行业。

诚然，AI Coding Agent 不会影响我们这些「老」工程师的工作，但这个问题如同被熊追着一样——淘汰你的从来不是熊，而是比你跑得更快的人。AI 不会淘汰工程师，但会淘汰那些拒绝进化的「手动操作员」。优秀的工程师不会消失，我们的职责正从「手写逻辑”转变为「选择方案、设计架构、验收质量」。

其次，我依然相信大家的软件工程经验是有价值的。

就像上面我提到，最佳实践本身没有问题，但每个人所面对的项目节奏是完全不同的。软件工程师的价值从手写代码，变成了选择 AI 提供的解决方案，审核 AI 提供的解决方案，并最终更好地完成自己的工作。优秀的软件工程师不会消失，只是工作职责变了，AI Coding Agent 会让他们获得更多「加成」。

我怎么用 Coding Agent

我目前自己同时在使用的包括 Claude Code、OpenAI Codex 和 Gemini Cli，其中前两者是我自己花钱买的，后者是 GDG 赠送的。

我强烈建议大家自己花钱购买。公司买了自然最好，如果公司没买，自己买也是划算的。 Claude Code 5X 已经满足日常使用了，如果你用量大再升级 Claude Code 20X 即可；$100 其实就是大家聚餐吃一顿价格，并不贵，但给你带来的提升是远超这个价格的。

我对于 Coding Agent 的使用会包含本地使用和云端使用两块，以及一些「质量守卫」。

本地使用

本地使用时，我会使用 Claude Code 的 Plan Mode 来设计一些需求，通过和 Coding Agent 的几轮交互约束需求范围，并让 Claude Code 去完成相关的功能。

同时，我会使用 Codex 来为我的项目补全测试 —— 过去我很多时候都懒得写测试，现在有了 AI 来帮助我测试基础覆盖，大大提升了效率。或许 AI 无法保证测试得像一个专业测试同学那样完善，但却可以让我先完成从 0 到 1 的建设。

Gemini Cli 则会在一些时候作为项目的补充，主要也是 GDG 赠送的 Plan 额度有限，所以用得不多。

之所以会同时使用三个不同的 Coding Agent，主要还是考虑到模型本身的能力是有差异的；不同的模型可以给我提供不同的视角，从而可以确保对于一个问题有更全面的思考，规避可能的思维漏洞。

云端使用

除了本地的使用，我还会在云端使用 AI Coding Agent，但并不是使用网页端的 Coding 工具，而是在 CI 工具链中集成 AI Coding Agent，使用 AI Coding Agent 对我的每一次提交、每一次 PR 进行代码评审，通过这样的方式帮我更好地发现代码中的问题，既可以确保自己对于问题的思考没有漏洞，也可以进一步的发现自己的经验不足，补全面对问题时的思考维度。

特别值得一提的是，集成多个 Coding Agent 可以明显看到不同 Coding Agent 对于问题的思考角度和深度不同，对于自我提升也非常有帮助。

质量守卫

由于AI Coding Agent 本身存在的问题，大规模编辑代码的时候，往往也会引入一些编辑错误、无用代码和不符合规范的问题。

因此我在深度使用 AI Coding Agent 的项目中，都会引入大量的质量守卫，来确保不符合规范的代码无法提交到云上。我们应当保持对 AI 的信任，但必须坚守 「信任但要核实（Trust, but Verify）」 的原则，确保 AI 提交的代码每一行都可信、可控。

这里的具体工作包括：

1. 引入静态检查的准入机制，扼杀低级错误：借助 git hook，在提交前进行 code format。
2. 引入质量红线，控制确保逻辑不出错，没有改错之前的代码：借助 git hook 和单元测试围栏，要求提交到代码库中的代码必须测试覆盖率满足要求（强 AI Coding Agent 介入的项目会要求测试覆盖率到 100%，并包含集成测试和端到端测试）。
3. 引入 AI Agent 的自愈能力，闭环问题的修复：借助 git hook 和一些 linter 工具，发现代码中的问题，并让 AI Coding Agent 自己去修复它。
4. 引入代码复杂度分析工具，让 AI 写出人和 AI 都易于维护的代码：常见的编程语言基本上都提供了圈复杂度检查工具，你可以在你的项目中引入圈复杂度检查工具，让 AI 提交之前确保所有代码的复杂度不会太高，从而既可以借助 AI 的能力快速迭代，同时又保留自己随时介入的可能性。

当你有充足的围栏检查，就可以放心让 AI 去完成工作，并要求它自行提交 commit 了。这样可以让其自动执行 git hook 并修复 git hook 中所配置工具检查出来的问题，从而确保提交到代码库中的代码不会有一些基础问题。

你该如何开始（工程师篇）

如果你是一个工程师，想要试试 AI Coding Agent 但又不知道怎么做：我能理解你对于代码质量的要求，和你的工作对你的要求；我也知道你担心引入 AI 导致你的项目复杂度快速提升、无法维护，最后导致项目彻底崩盘，你反而被干掉。

所以，我推荐你这么干：

1. 在现有的 CI 工具链中加入 AI Coding Agent 进行代码评审，让 AI 先从这一步开始给你提供更多的建议，先帮你变成一个更好的工程师；
2. 习惯让 AI Coding Agent 参与到你的工作流里后，可以先让 AI 帮助你补全测试，建立起单元测试围栏，从而让你放心地引入 AI Coding Agent 参与项目；
3. 使用 AI Coding Agent 完成你的工作（记得加入各种围栏），让你自己获得进一步的解放。

当你完成了上述三步后，你已经熟悉了 AI Coding Agent，除了做一些你熟悉的工作，还可以让它带着你去做一些你所不熟悉的事情。比如你是前端就让它带着你搞后端，如果你是后端就让它带着你搞 iOS……

总结

到了 2026 年你依然可以 Happy Coding，不过大家也要意识到，我们除了做体力劳动的 Coding，更应该用好 AI Coding 工具，将这些托管给 AI Coding Agent。

然后我们的工作才会越来越具有「创造性」，才能去做一个「创造者」。

> 关注 少数派小红书，感受精彩数字生活 🍃

> 实用、好用的 正版软件，少数派为你呈现 🚀