从 2025 年底到现在，大概半年多的时间。这篇文章是对这段经历的回忆，没有方法论，只有我自己真实走过的路。
一、我是怎么开始的
从怀疑到决定尝试
2025 年大部分时间，我对 AI Coding 的态度估计和很多人差不多——知道它存在，用 DeepSeek、豆包的网页版写几段代码、解释代码，这样简单的任务表现尚可，稍微复杂一点就不行了。而 ChatGPT 这种当时顶尖的大模型在 AI 编译器领域依然有不少瑕疵，所以我从没想过它能真正替代人来写高质量的业务代码。互联网上铺天盖地的”AI 革命”文章，我基本当营销噱头来看。
改变发生在 2025 年 12 月。小鹏的一个朋友跟我说：“Claude 太好用了，需求开发、代码重构，一句话就搞定了。”
这次不同——这是身边真正在用的朋友说的，不是软文。搜了一下 Claude，确实呼声很高，于是我决定马上去体验一下。
然而现实比想象曲折得多。
第一关：网络
国外顶尖大模型不对国内开放，Claude 更是对华不友好。第一道门槛就是网络——需要挂代理才能访问。
这一关会劝退很多人。公司内网有直接可用的代理，但在外网就需要自己折腾。对我来说这不算难，因为我认为作为程序员，高质量的代理是基本功，不可能天天用百度解决问题。
第二关：环境伪装
Claude 不仅检测请求 IP，还会检查用户的真实使用环境：操作系统的地区、时区、语言设置，甚至 DNS 信息，随便一条都能暴露你的真实位置。
怎么办？ 新建操作系统用户，改地区、改时区、改语言、自建 Fake-IP DNS、指纹浏览器等等，把自己装扮成真实的海外用户。
对不了解这些机制的人来说，到这一步也就到头了。我也不是一上来就懂这么多，是通过各种渠道学习其他人的经验总结出来的。
第三关：支付
这是最多人望而却步的地方。就算通过前两关注册了 Claude 账号，也没法充值。能在国内开通国际支付信用卡的人就不多，而且 Claude 还会对支付增加更多校验，肯定不支持国内的这类卡。
我继续从各种渠道寻找别人的经验，很快一条低成本且安全的路子摸索出来了：注册尼日利亚地区的 Apple 账号，购买礼品卡充值，然后通过 Apple Store 订阅。成功！
当收到 Claude 发来的账单邮件时，心情无比高兴。
两个字：震撼
第一次真正用上 Claude 之后，我当时的感受只有两个字：震撼。
我做了一个简单的实验，让几个主流模型各自生成一个完整的 MLIR Demo：
- 豆包（网页版）：核心代码 + 使用说明
- DeepSeek（网页版）：完整工程目录，但需要手动拷贝文件
- Claude（CLI 客户端）：在 DeepSeek 基础上，还额外给了功能扩展样例、三套平台编译脚本，本地可以直接编译执行
高质量的大模型，颠覆了我的认知。接下来我做的第一件事就是激动兴奋地和朋友、周边同事传递”Claude 真好用”。
二、第一个完全由 Agent 开发的穿刺项目
项目背景与挑战
2025 年底，我被安排做一个穿刺项目，目标是把已有的 AI 编译器特性迁移到 MLIR 这套有入门门槛的基础设施上。虽然之前接触过 MLIR，但没有深入了解。对我来说最大的挑战就是如何快速掌握 MLIR。
在尝到 Claude 的甜头之后，我的初步计划是用 Claude 来完成这项挑战。
模型选择的曲折
然而理想很丰满，现实很骨感。由于订阅的是 Claude Pro 套餐，额度消耗非常快，而且还有 5 小时限额和周限额。升级 200 美金的套餐？路子不可行，因为尼日利亚区的 Apple 账号是新注册的，Apple 有严格的资金安全风控，新号消费大额资金会被风控。
于是我想找一个同等质量的替代品。恰巧此时国产的 GLM4.7 发布了，宣称是全球顶尖编程模型，距离 Claude Opus 4.5 仅一步之遥，最重要的是性价比高。最终果断买了季度套餐。
买来之后，第一步就是接入 Claude Code CLI 试试效果。吐字速度很快，在解读 MLIR 代码这项工作上表现还算不错，但生成 MLIR 代码的效果距离 Claude 还是有不小差距。
就这样 Claude 搭配 GLM4.7，开启了我的第一个穿刺项目。
学习 MLIR 的新方式
项目目标比较简单：仿照现有的业务 IR 定义，在 MLIR 中也定义一套相同语义的 IR，并跑通端到端流程。
同时，我也开启了 MLIR 深入学习之路。因为如果我不熟悉 MLIR，就算 Agent 写好了代码、跑通了流程，我也不知道是不是我想要的，更不知道里面埋着多少坑。
我想让 Agent 按照 MLIR 的特性、方言等维度，逐个帮我梳理逻辑并总结成文章，这样不就能提高效率吗？然而现实再次打脸，无论是 Claude 还是 GLM，它们生成的总结性文章实在太 High-Level 了——说了正确的废话，看完觉得懂了，实际上一点收获没有。
我从各种渠道去看别人是否也遇到这样的问题，找到了一篇关于认知科学的论文，介绍了一些科学方法如何获取信息、加深记忆。于是我基于这套认知科学理论，结合主动学习并实践的方法开发了一个 Skill，主要逻辑是：首先提取核心代码流程，其次理解核心函数和数据结构，最后根据关键测试用例加深理解。
基于这套 Skill，我的 MLIR 学习之路确实通顺了很多，不过还是要付出比较多的时间，这个是不可避免的。
模型对比的实战
有一次，我用 GLM4.7 生成了一段包含卷积操作的 MLIR demo，我看起来感觉有点怪，但又说不出具体是什么问题。实际执行一下确实报错，然后让 Claude 检查，确实发现了问题，修改后跑通了。
然而我并没有跳过去，而是把同一段有问题的 demo 分别扔给了豆包、DeepSeek、ChatGPT、Gemini。结果：豆包和 DeepSeek 都发现了问题但没改对；ChatGPT 和 Gemini 都准确修复了。
类似的对比还有很多。比如部门给统一采购了火山平台提供的 GLM4.7 后，我做了一次实测对比，用同样的问题和同样的工具：
- 火山版 GLM4.7：耗时半个多小时没完成任务，而且经常像卡死一样没有响应
- 官方 GLM4.7：十几分钟完成，但有一些瑕疵
- Claude Sonnet 4.6：仅用三分钟就高质量完成了任务
多次的模型对比让我逐渐意识到，在垂直领域（比如 MLIR 编译器），模型之间存在巨大的能力差异。在评估选型模型时，不能只看宣传上的跑分和性价比，要实际体验对比。
这个项目耗时不到 1 个月，跑通了端到端的流程。最终统计下来，超过 95% 的代码都是 Agent 写的，我主要做的是方向把控和最终验收。
三、从盲目推崇 Skill 到零 Skill
追求”配置拉满”
随着对 Agent 越来越依赖，我也努力跟上潮流。自己尝试开发了一些，但我更想了解技术圈内大佬都在用什么，有什么宝藏 Skill。
那个时候还有很多 Skill 平台、GitHub 仓库用来收集和分发 Skill。我每天除了正常安排 Agent 开发之外，更多时间用来摸索这些内容——节省 Token 的 Skill、提高效率的 Skill、增强记忆的 MCP 工具……我也跟着这股风走，本地安装了各种 Skill，挨个实际体验、对比效果，追求把 Agent 的能力”配置拉满”。
Claude 变笨了？
有一天，我突然发现 Claude 像是变笨了。我认为比较简单的任务，它需要花更多时间才能完成。这个我没有量化数据，纯体感上的差异。
我本能想法是 Claude 可能为了升级新模型，把老模型降智了。但在网上搜索很久也没发现线索。于是回头分析 Claude 的执行过程日志和提示，发现在 200K 的上下文中，Skill 就占据了很大一部分，而且部分 Skill 还存在类似的触发词。
我凭直觉意识到，应该是最近逐渐安装的各种 Skill，这些 Skill 质量参差不齐，大概率污染了上下文，影响了大模型的效果。
立马决定先把各种野鸡 Skill 删掉，只留下口碑和安装量高的 Skill 和 MCP 工具。果然很明显感觉大模型又恢复了。
节省 Token 的本质是什么？
我开始反思：总想着节省 Token、提高效率，但节省 Token 的本质是什么？提高效率的本质又是什么？
通过分析部分 Skill 和 MCP 工具发现，节省 Token 的本质就是在 Agent 发送请求之前增加一个钩子，对 MCP 工具执行结果进行清洗过滤。本意是过滤掉结果中的噪音信息，减小 Token 消耗，这个是理想情况。
可是这个清理策略如何实现呢？如何识别是不是噪音呢？就算它识别为噪音，大模型是否也觉得这是噪音呢？如果把有用的信息过滤掉了，就会严重影响大模型的效果。
所以我开始了谨慎的 Skill 和工具选择过程，精挑细选，保留少量必要的：增强 memory 记忆和搜索的工具、Superpowers 系列 Skill 等。
被插件偷 Token
这就结束了吗？当然没有。有一天发生了一件令我哭笑不得的事。
Claude 的 5 小时额度本不富裕，主力已经换到 GPT，但偶尔还是要去用一下 Claude。我算好了额度重置时间就去用，前几次刚问不到 2 个问题，额度就没了。后来干脆一个都没问，额度还是光的。
我一开始以为是 Claude Agent 出现了 Bug，于是问其他同事，他们反馈用得好好的，额度消耗也正常。我凭直觉认为，大概率还是我使用的 Skill 或者工具的问题。但明明没有启动 Claude，怎么会偷偷消耗 Token 呢？
带着满脸问号，我在命令行输入了 ps -ef | grep claude，果然检索到了带有 claude 关键词的进程，但并不是 Claude Code CLI 本身，而是一个叫 claude-mem 的插件。我把进程的参数等信息贴给大模型，它帮我解开了谜底。
原因是我 Claude 和 Codex 共同打开同一个项目，Claude 中安装了这个插件，此插件的作用是对项目进行索引预构建，目的是提高 Claude 的检索效率。通常来说，如果项目变动不频繁，这样的设计逻辑是没问题的。但我恰好在用 GPT 进行大量功能开发，文件变动大、数量多。claude-mem 一检测到文件变动就会调用 claude -p 命令来消耗 Token 构建索引。
事已至此，心疼是不管用了，干脆直接删除了所有的工具，只保留了 Superpowers 系列 Skill。
GPT5.6 的启示
时至今日，随着 GPT5.6 的推出，其已经把各种高效的 Skill 技能训练进了大模型，新的 GPT 桌面版工具已经默认删除了所有 Skill。推特上也有非常多的知名人士同时提出删掉自己安装的某些 Skill。
也就是说，随着 Agent 和大模型的能力越来越强，我们会慢慢减少对基础/通用 Skill 的依赖。
四、多方案并行：一次在 AI 时代才敢做的决策
不一样的决定
2026 年 4 月，第二个穿刺项目经过前期 6 类场景端到端用例验证成功后，进入通用代码开发阶段。我带着一名新员工一起做，她对原有业务逻辑很熟悉，但对 MLIR 也是刚刚入门。
传统的开发模式是设计一套开发方案，然后两个人分别负责不同的模块，预先定义好模块之间的接口，然后并行交付。然而这一次我有了一个新的想法：
首先，因为有了 Agent，代码开发成本变得非常低，尤其是对于技术穿刺类项目，只需要摸索出一条路子，证明技术可行性即可。
其次，现在 Agent 的 SubAgent 技术已经十分成熟，对于小型项目或者大一点的需求，完全没必要拆成多个人并行，多 SubAgent 并行技术就足够了，而且省去了人之间的沟通成本、接口定义不稳定等问题。
所以我做了一个决定：我们两个同时设计开发两套不同的方案。
- 新员工负责保守方案：基于原有业务逻辑，稳健地迁移到 MLIR，目标是能跑通、能保持业务连续性
- 我负责激进方案：继承原有架构设计思想，基于 MLIR 新架构完全重新设计，发挥 MLIR 的优势做全新架构，以解决原有架构的各种局限性
为什么敢这样做
这两个方案不是互斥的，而是短期和长期两个目标的不同阶段。短期内先通过保守方案进行过渡，但长期演进方向就是激进方案。
现在回过头来看，这个决定是正确的。最终两个方案跑了一个月都顺利达成预期目标并验证了可行性，而且目前商用版本正在按照预期使用保守方案进行开发中。
五、新的瓶颈，业界难题
信心满满的开始
在穿刺项目开发阶段之初，我对 Agent 信心满满。因为设计文档已经全量 Review 了两遍，全部方案拆分成了 9 个章节，详细梳理了每个章节的每个细节。并且也用 Claude 和 Codex 交叉检视了两遍，外加已经具有 6 类可端到端验收的场景用例。我们得出一致结论：可以动工开发了，目标就是开发一套通用的代码并跑通已有的 6 类场景用例。
第一次翻车
本次开发的主力模型是 GPT，它先统筹阅读了设计文档，然后输出了一版开发方案让我 Review。但这份开发方案实在太长了，而且我认为设计文档我已经把控住了，所以就让它按照目标直接开发了。
它在开发前咨询我是先实现一个简单的端到端流程还是按部就班逐章开发，并且分析了每种开发方案的好处，最后推荐我选择简单的端到端流程。作为 Agent 熟手的我，不假思索地输入了”同意”两个字，然后我就去折腾其他东西了。
已经忘记过了多久（时间不长），Codex 告诉我完成了，并且成功用新代码跑通了其中最简单的一类端到端用例。我十分开心，让它告诉我怎么执行，我想验收一下。按照它的指导输入命令后很快得到了用例 Pass 的输出。然后它问我是否继续开发，Of course, sure。
当它再次很快完成了第二类端到端用例之后，直觉告诉我出事了。不会是给我硬编码吧？但由于它在短时间内开发了大量代码，单从目录结构上看也是符合我预期的，我短时间内也很难通过Review代码实锤它的问题。于是我直接质问它：这两次开发是否按照通用代码开发的？它很诚实地回答我”不是”，是按照快速跑通端到端用例为目标进行开发的。
当时我就狠狠批评了它，它也”意识”到了错误。
反思与改进
虽然它”承认”了错误，但我能拿它怎么办呢？我还是理性地分析了一下问题。在整个开发过程中，我只把控了设计方案，没有把控开发方案，更没有做好代码 Review，而且功能验收也是简单看一眼打屏日志。这是因为之前的项目比较简单，我已经形成了惰性思维，懒得去花时间检查 Agent 的产出。
但这一次翻车也及时提醒了我。我去查找这方面的资料，发现是一个共性问题，但还没有特别好的实践解决这个问题。如果花时间精力 Review 代码，那会大大降低 Agent 的开发效率，因为人的效率太低了——Agent 一分钟的代码量，人可能需要花一天时间来 Review。
对我来说，这是个必须要解决的问题，因为我只有 1 个人来完成这个穿刺项目，而且时间也不是无限的。于是我尝试和 Agent 探讨这个问题，很显然，它给不出有效的方法。
化整为零
我回顾了传统开发流程，我们会把整个开发需求拆成多个 SR 和 AR，也就是用化整为零的思想把规模大的问题拆成一个一个小问题。
所以我和 Agent 讨论，让它为我重新规划开发计划。目标不变，还是开发一套通用的代码能够跑通 6 类场景用例，还是可以先实现一版简单的逻辑但不是定制化的代码。就第 1 类场景用例这个需求，我还是把它按照设计的 5 层架构，拆分成 5 个子需求，分成 5 次开发实现。
我逐层仔细分析它重写的开发方案，每一层的开发方案大概要花 1~2 天时间来反复和它确认细节。然后逐层开发，每一层的代码量还是很大，我就挑核心文件来 Review 代码。Review 的逻辑也很简单，粗略看一下函数名，确认其方向没错、整体逻辑正确，然后快速筛选每一个函数中是否存在不符合预期的 if 代码。
就用这样的方式，兼顾效率和正确性，在和 Codex 不断磨合中，最终完成了这个阶段的开发工作。
清醒认识
现在回过头重新思考这个问题，至少目前是无解的。网上有大量的文章、项目宣称完全由 Agent 开发，但我们要明白，这类项目肯定不是商用交付类的。我们要清醒认识到 Agent 确实可以提高效率，但也不能盲目追求过高的开发效率，否则一定会埋藏着不知道多少的质量陷阱，至少截至目前是这样的。
在没有更好的解决方案的条件下，我现在实践出来的就是尽可能把需求颗粒度拆小，做到人能够把控每个 PR。这就要求开发人员具备三个基础能力：扎实的编码基本功 + 扎实的业务知识 + 扎实的领域技术。
六、总结
写到这里，回头看这半年多的经历，我想分享四点感受，它们分别对应了前面几节的故事。
关于”要不要折腾”
第一节讲了我如何突破三道门槛才用上 Claude。这是最关键的第一步，很多人卡在这里。
不少人知道 AI 很强，但因为工具用不好（封号、代理、付款）就放弃了。从我的经历来看，这些障碍是可以解决的，而且值得花时间解决，因为后面的收益远大于这点折腾成本。
关于工具和模型的选择
第二节和第三节讲了我多次对比不同模型的经历，以及被 Skill 误导的教训。
我的建议是：不要听别人说好用，要自己用真实任务去测。同样的任务，三分钟完成和三十分钟没完成，这个差距在实际工作中非常具体。花一点时间自己跑一遍对比，比看十篇评测文章都有用。
同样，评价 AI 使用水平不是看装了多少 Skill，而是看解决了多少真实问题，积累了多少高质量经验文档。
关于试错成本与决策方式
第四节讲了我让两个人同时跑两套方案的决策。
在 AI 时代，试错成本大幅降低。过去我们不敢同时尝试多个方案，是因为成本太高。现在有了 Agent，两套方案的总成本相当于传统方式一套方案的成本。这意味着决策可以更多基于实验验证，而不是评审会上的判断。
这个变化不只是效率问题，而是决策模式的转变。
关于”AI 会不会让人变懒”
第五节讲了我被 Agent 翻车的经历，以及最终摸索出的应对方式。
我观察到的情况是相反的。Agent 开发效率越高，对”人”的要求反而越高——你得能看懂它做了什么，能判断对不对，能在它卡住的时候给出方向，能把大需求拆成小需求。
代码生产速度已经远超人工消化速度，传统的全量 Review 方式在 AI 时代是行不通的。人的价值在于判断，不在于执行。这需要扎实的编码基本功、业务知识和领域技术。
所以，Agent 可以淘汰掉程序员吗？这个话题曾经充斥着全网，每个程序员都在忧心忡忡。如果让我来回答：会淘汰半吊子程序员，也更凸显出具有扎实基本功的程序员的价值。
这篇文章只是把我自己走过的路写出来，并附带了一些我的个人观点。踩过的坑、遇到的问题、解决的方式，都是真实发生的。
如果你也在这条路上，希望这些记录对你有一点参考价值。当然我的观点不一定正确，也或者当前正确但未来随着技术发展会变成错误的。这都不重要，重要的是我们已经走在一条无法回头的 AI Coding 之路，大家一起努力、相互帮助，把接下来的程序员之路走平坦！