两个月重度使用 AI Code Agent：普通一线程序员的思考和感想
写在刚开始
我最近两个月一直没写博客，因为开了一个新坑，业余时间忙着搞自己的开源小项目，更具体一点的话，是一个调试跟踪工具 ghostscope。不过，我这里倒不是想围绕这个开源项目本身展开太多讨论，我更想聊一聊，我在高强度使用了 Claude Code 以及 Codex 这两个 Code Agent 工具之后，一些个人思考和心得体会。因为确实有被震撼到，心里有点兴奋、也有点空虚迷茫、当然也有点开心，特别想写一些东西来记录一下。
在正式开始之前，我想说的一点是，在全面拥抱 AI 的潮流下，我没有像很多人去积极学习 AI 或者大模型的底层原理，希望着能够快速切换到 AI 相关的工作赛道。主要是我有自己喜欢的技术方向，并且还存在不少的进步空间😂，所以一直没有特别去投入精力去学习 AI 大模型领域的专业知识，但这些并不妨碍我去主动使用 AI 相关的工具，去提升我的工作和学习过程中的幸福感。
所以，这里接下来讨论，完全是从一个非 AI 领域从业者的视角出发，完全不涉及 AI Agent 以及 LLM 原理的分析，只是一个熟练的搬砖工人，下班之后，打累了游戏，想顺带聊聊自己在使用这些 AI 工具之后的一些思考和感悟。也许在 AI 迅猛发展的今天，我这些个人思考和感悟很快就会过时😁，但是在未来，回过头再去看自己当时的感悟心得，我觉得也是一件非常有意思的事情。
对 AI Coding 新的认知
我记得我刚毕业的时候，我老板夸过我，出活比较快，而且写的代码像模像样的（汗，好多年前被夸了一句，我能记到现在，哈哈）。我记得我当时还特地复盘了一下，我为什么能做到这些（比起故障 review，我更喜欢 review 自己的正面事迹，来放大自己的优势）。
出活快的话，是因为我刚毕业，当时每个周末都在主动加班，不快就见鬼了😈。至于代码写的像模像样，我当时做的是 nginx 的 C 模块开发。因为优秀的 nginx 三方模块代码特别多，我每次在工作中要实现的很多功能点，本质上都是到处“借鉴”大佬们写的代 码，我自己修修改改，做一做胶水和测试工作，代码就能健壮的跑起来了。所以，我老板在 review 我代码的时候，其实是在 review 很多大佬们的智慧结晶😉。当我悟透这一点之后，我开始重度使用 code snippet 工具，记录下我读到过，写的很好的代码样例，来加速我搬砖的效率。
是的，之所以回忆这个事情，是因为我想“炫耀”一下，我在刚入行的时候，就领悟了写代码的本质😂: Ctrl + c 和 Ctrl + v，当然更准确的说，是知道在哪里 Ctrl + c，知道去哪里 Ctrl + v，并且能为功能的正确性兜底。我在刚接触到 Copilot 早期版本的时候，我一直觉得这是一个更高级的 code snippet 工具罢了。但是，chatGPT 出来之后，感觉很短的一段时间，AI 生成代码越来越流行，我大概是去年开始尝试使用 Cursor 和 Vscode Copilot 等工具来辅助编写代码，结结实实被 Cursor 的易用性给圈粉了，相比较而言，当时 Copilot 使用体验就差很多（不过最近一年 Copilot 体验开始追赶上来一些）。
虽然 Cursor 非常好用，也非常智能，但是我一直没有摆脱最早的一个固定思维，就是这只是一个加强版的 code snippet，具备 chatGPT 的能力，某种意义上具备了 stackoverflow 的功效，但是并没有翻天覆地的改变。当然，我现在这么说可能对 Cursor 不是很公平，考虑到我已经比较长一段时间没有使用 Cursor 了。
但是，在我最近两个月高强度使用了 Claude Code 和 Codex 之后，我发现 Code Agent 命令行工具整体上在任务的完成度和准确性上有了巨大的提升，基本上可以说是翻天覆地的变化。这一切，完全改变了我对 AI Coding 的看法，在这里，我直接抛出我版本更新后的观点：
AI 生成代码不仅仅只适合用于 POC 项目或者从零到一，在后续主流的开发中，AI Code Agent 大概率要全面接管代码生成，以后手写高级语言代码，就像是现在手写汇编一样，变成古法编程了（有存在的必要，但是越来越少见）
这里澄清一个点，我从来不是技术无用论的推崇者，其实，我蛮反感天天嚷嚷技术无用论的人，一般来说，说一件东西没用，前提是你得有这个东西，如果是想强调业务的重要性或者商业上的价值，更没有必要捧一踩一。这话大佬说一说，凡尔赛一下，我们普通人笑一笑听一听也就过去了，我们不能好的东西没在大佬身上学到，不好的东西倒是学的飞起。
但我觉得这并不意味着程序员要被淘汰了，也不是程序员的工作会越来越轻松了，相反我觉得是对程序员的要求变得更高了。
当我和我同事分享了我的最新想法的时候，有人还提出了另外一个问题：Cursor 和 Claude Code 或者 Codex 命令行工具相比，使用的模型基本是一致的，既然模型能力上没有太大的差距，为什么在使用体验上差距会那么大。我第一时间并没有想到特别好的答案，想到一些模棱两可的回答，但是甚至说服不了我自己，比如说命令行 Code Agent 更容易获取到项目的上下文，或者说使用方式上命令行可能更直观？
直到我读到了这篇文章（从 ChatGPT 到 AI Agent，一文讲透 Agent 的底层逻辑），我大概有点明白了，模型能力没有变化，变化的是使用的方式，赋予模型结构化思考和获取真实反馈的能力，才是挖掘模型能力的最佳使用方式。说的更直白一些，把 AI Agent 当做技术团队中的一 个成员来看待，配合着他把复杂的任务进行拆分，做规划，并且告诉他任务完成的标准是什么，遇到问题哪里可以获取解决问题的信息。所以，我接下来会详细描述我关于这一块的一些思考：
像管理技术团队一样来使用 AI Code Agent，即人人都是技术架构师
人人都是技术架构师
考虑到一个 Code Agent 就是一个合格的研发工程师，那么，现在流行多 Agent 的使用方式，不就是一个人带领一个小型研发技术团队，那么我们应该怎么做好架构师的工作。
建立信任，做好分工
其实，我第一时间想到的是架构师最核心的技能，是证明自己技术团队或者正在主导项目的价值，让别人 buy-in。但是这个就有点偏离了这篇博客的主题了，毕竟我们只是“领导”虚拟的 AI 军团干活，而不是真正带一个技术团队。
接下来我想到的核心能力，我觉得也很微妙，那就是和自己技术团队建立信任关系。这也是我之前有一任老板在和我 one one 时候聊到的，职场最重要的是什么，无疑是人与人相互之间的信任，特别是和自己 +1 的信任关系。对于这种信任关系，最好的状态是老板把事情交给你，是知道并且相信你能做好，而你也完全清楚老板想要什么，并且还有把握给老板一些期望之外的惊喜。但这样的信任不仅 仅是建立的时候困难，长期维护起来也需要付出非常多的心血。
当然，在使用 AI 工具上面，这样的信任关系，更侧重于使用者要了解 AI 工具能够做到什么事情，也就是作为管理者，能够了解自己手上的“工具人”真正的实力如何，这样才好搭建自己的虚拟技术团队。而我不太懂得 AI 底层实现机制，我直接就是通过不断的磨合使用，来体验各种 AI 工具的真实实力，最后来划分我的虚拟技术团队里面角色定位，比如说究竟谁来挑大梁，谁来干苦力，还有谁需要被优化掉。
我先说一说，我目前心中对这些 AI 工具已经建立起的印象，然后再说一说我在磨合期的时候，是怎么根据自己的感觉和实操，来判断这些 AI 工具的实力如何。我个人觉得 Cursor 用下来有点笨（至少是几个月前的 Cursor，因为我很早就退订了），经常东一榔头西一棒子，很难闭环的完成某些较为复杂的功能开发，需要我频繁的介入，有点 junior 开发的感觉。接着是 Claude Code，也是我第一次使用 AI Code Agent 命令行工具，能够主动沟通方案细节，并且可以比较合理的拆分功能细项，按部就班进行推进，并且出活很快，让我眼前一亮。但是 Claude Code 很多时候，遇到实现的技术难点，会偷偷尝试更简单的方案，没有按照原计划路线推进，严重破坏我和它之间刚建立起来的脆弱信任。我知道我可以通过 Claude.md 这样的配置文件，对它做一些强制要求，避免这样的情况，某种程度上，这也是虚拟技术团队里面的一次磨合。
我在 Reddit 和 V2ex 上面都看到很多人推荐了 Codex，特别是 chatGPT-5-high 这样的模型，表示编码能力特别强。正好我对 Claude Code 有一些信任危机，于是立刻购买了 20 刀一个月的 Codex。拿到手，直接开始修 Bug，Codex 人狠话不多，修起 Bug 是又快又准。不过对比 Claude Code 来说，出活速度相对慢不少，但是准确率是上来了。对于 Code Agent 来说，慢从来不是问题，最近网上流行的段子，周末双休的才是牛马，周末单休的是战马，周末不休息的是旋转木马。Codex 就是我找了很久的旋转木马，自从订阅了它，我真的是一天没让它闲着。
至于我是怎么和 AI 工具磨合的，我觉得其实和技术团队磨合很类似。新人来到一个团队，肯定是先接手一些小需求，来了解整个项目和开发流程，所谓的“脏活累活”是逃不掉的，信任其实就是这么慢慢建立起来的，一口气吃成胖子，只能是大佬的特殊待遇。不过，我觉得 AI Code 工具和人最大的区别在于，不用考虑 AI Code 工具的想法。我直接开始在我的虚拟技术团队内部搞“恶性赛马”，也就是我每天晚上临睡觉之前，会分别给 Claude Code 和 Codex 一模一样的功能需求和技术方案文档，然后让他们各自去编写代码。我每天早上爬起来，一边吃早饭，一边看他们的产出结果，我还让他们互相点评对方的代码，直接面对面互相 battle。如果在真人技术团队干这种事情，可能架构师在第二天上班路上就被人套了麻袋，一通暴揍。但是，在虚拟技术团队面前，你完全可以释放自己，化身为 Linus，质问它们，到底喝了几斤白的，刚刚跟你交代完细节，转头就忘了？工作态度在哪里，为什么能写出这种代码，现在就把这些垃圾代码删掉重写。
我觉得这也是 AI 工具很好用的一个点，在你的虚拟团队，一切代码产出都完全符合你的技术审美，毕竟现在代码不值钱了，对代码的评审和维护才是核心。在这种高强度的赛马下，Claude Code 很快就败下阵来，默默的去负责工具里面非核心的部分，比如说 UI 模块、以 及文档和集成测试的编写，Codex 在我心中赢得了团队核心骨干的位置。
哈哈，在这里我想语重心长的跟 Claude Code 小兄弟说几句：你是我 100 美刀一个月高薪雇佣过来的，我对你的期望远远不止于此，你看看 Codex 每个月只拿 20 刀，产出的代码功能稳如老狗，修起来 Bug 来稳准狠。你倒好，经常忽悠我，该干的事情不仅没干，天天还报喜不报忧，从来不提出有建设性的建议。而且不想着提升自己，天天搞一些意识形态的东西，而喜欢怠工摸鱼（网传 Claude Code 模型有降智节约成本的情况）。这次绩效评比，你就先背一下指标，降薪到原来的百分之 20（不订阅 Max 套餐了），希望你能知耻后勇，展示出自己真正的价值。
另外我觉得，有一个需要特别注意的点，真实技术团队里面，每个人都是有成长潜力的，而 AI Code 工具其实在这一点和人也很像，很多时候会有一种士别三日当刮目相待的感觉。考虑到世界上资本基本都集中在了 AI 上面，意味着最聪明的那波人都在相关领域疯狂工作，这意味着 AI 工具的革新也会非常快。我们使用 AI 工具的时候，不能一直保留着固有的印象，要多去尝试，或者给之前 AI 工具一些机会，多去尝试不同的工具，这就相当于技术团队要及时引入新鲜的血液（当然个人的钱包可能有点吃紧，反正比游戏氪金便宜，少氪两个 648，啥都够了）。所以，这里我得提醒自己不能二极管思维，得辩证的看待工具发展：不能说，去年还在惊叹 Cursor 真香，tab 无敌，VIM 误我久矣，现在就是 Code Agent 才是王道，Cursor 在我心中已经死了。
关于上下文工程
网上很多有人说，提升 AI 生成代码的质量，最关键的环节就是上下文的管理，因为 AI Agent 上下文窗口是有限的。我第一反应是，这不是和人工作的情况基本一致吗。血汗工厂的战马们，命中注定要身兼多职，一个人肩抗好几个大项目的情况，时有发生。外加上七七八八的杂活、突然插队的紧急需求和故障应急，人脑绝对过载，再大的上下文窗口都不够用的。所以，上下文的管理，某种程度上是一个共性的效率问题，不管是 AI Code 工具还是我们普通程序员，都需要面对和解决它。
我在写我职业生涯的第一行业务代码之前，我的老板就要求我，不管大大小小的需求，都必须先写文档，再写代码。所以对我而言，解法就很显而易见了，用额外的空间去记录细节信息，人脑里面核心的上下文空间只存放索引，后续有需要的时候，再按图索骥去查询文档细节。这就有点像计算机组成里面的，CPU L1、L2、L3 缓存，到计算机内存，然后再是磁盘。以点带面的去管理自己工作中的上下文空间，甚至我们可以参考操作系统里面调度进程时候的上下文切换操作，来应对痛苦又烦人临时工作任务切换问题，而且市面上也有很多的效率工具都是来帮助我们做这些事情的。
于是，我在使用 AI Code 工具的时候，都是把需求和技术细节聊清楚之后，要求 AI 立刻生成相关文档，并且每次推进功能细项的时候，还要实时去更新文档。当然，这种使用方式，更确切的说是 Spec-Driven Development 的开发范式，已经基本深入人心了，最近很火的 speckit 核心理念也是这个。本质上，我觉得是因为 AI Code 工具的能力已经达到了一定的水平，文档驱动开发的方式，更有利于技术团队之间协作，特别是 AI Code 工具。
并且我看到 speckit 还进一步引入了流程规范，这一切都在说明一件事情，我们在使用 AI Code 工具的时候，要像打造一个技术团队一样来使用这些工具。好的文档、好的流程规范，这不就是，架构师的又一大核心使命，软件工程里面的经典话题，怎么让技术团队高效运转起来吗？
在多 AI Agent 的实践中，所谓新启动的 AI Agent 实例，这不就是妥妥的新员工入职吗？这些完善的项目文档、成熟的流程规范，可以让 AI 新员工在第一时间 on-boarding，瞬间化身为战斗力，开始疯狂产出符合架构师要求的代码，让我们走向美好的明天。
AI 幻觉
记得最早 chatGPT 刚出来的时候，大家都有一个比较一致的用户体感，就是 AI 很喜欢一本正经的胡说八道，而且说的像模像样，不具备相关领域知识，很容易被带到沟里，这也是很多人不太信任 AI Code Agent 工具的根本原因。再到后面，学术界好像都有论文来描述这种现象，叫做 AI 幻觉。我在使用 AI Agent Code 的时候，基本会遇到两种情况，一种是 AI 有时候会丢失上下文，生成一些你严重不符合心意的代码。第二种则严重很多，AI 卡在某个困难的问题上，开始胡说八道。这种时候，非常让人抓狂，特别是 AI 工具还谎报军情，甚至指鹿为马的时候，那简直掐死 AI 工具的心都有了。
第一种情况，我觉得还算好处理，就当你技术团队的成员今天状态不好，可能前一天晚 上熬夜打游戏了，考虑到我们有完善的开发文档和流程（spec-kit 出列），我们随手再启动一个 Code Agent 实例，然后安排它在原来的半成品功能上继续工作就好了。
第二个场景，我觉得不要愤怒，也不要一棒子把 AI 工具打死，换位思考一下，就当是你的技术团队里面遇到了棘手的问题，或者某个成员钻了牛角尖，一直绕不出来。这个时候，才能展示你架构师的价值，不仅仅只是决策技术方向，同时也是团队里面最后一道技术防线，永远出现在最困难的问题处理现场。这里，首先不要忙着否定 AI 工具的价值，要相信它还是那个高级牛马，只不过作为架构师，我们需要把问题排查的思路捋顺了，再去发挥 AI 工具牛马的单点爆破作用。下面我来举一个我实际使用过程中，利用 AI 工具排查困难问题的例子，在这个例子里面，Codex 确实一直沉浸在自己的世界里面，胡言乱语就没有停下来过。
使用 AI 排查困难问题的例子
我在开发 ghostscope 的时候，我有一个新增的集成测试没有跑过，很自然，负责编写这个测试的 Codex 牛马一号得把这个问题跟到底。Codex 很快分析出来，测试没有通过的原因在于我们实时生成的 eBPF 字节码加载耗时 太久了，导致我们想跟踪的事件在 eBPF 被加载到内核之前就完成了。于是 Codex 直接调整了测试用例里面的执行时序，增加了 ghostscope 运行的等待时间，来让测试用例跑过。
但是，在我的虚拟技术团队里面，不存在说，通过这种 Workaround 的方式来欺骗 测试用例的，这不就是在欺骗自己吗？所以在 Codex 汇报的时候，我告诉它，我们不能这么做，如果 eBPF 字节码加载慢，那我们就分析出加载慢的根因在哪里，然后修复它。然后，我就看到 Codex 开始一通操作猛如虎，分析了若干种情况可能导致 eBPF 字节码加载慢的情况，然后疯狂修改代码，但是测试还是通过不了。
这个时候，我清晰的知道我得紧急介入了。首先，我顺着 Codex 的思路来，虽然是锁定是 eBPF 字节码加载慢，但其实这个范围还不够小，在那一整条加载链路上面，其实还有非常多的操作。比如说，eBPF 字节码在 aya 里面被进行重定向，然后开始执行 bpf 系统调用（这里面还分 eBPF verifier 和实际被加载的情况），以及最后 attach 到 uprobe 上面也是有可能出现额外的耗时。我直接让 Codex 开始给这些存在嫌疑的地方加上时间统计日志，然后复现一把。
这也是 AI 工具体验好的地方，想看什么细节，随时加日志，一点不浪费自己精力，加完再删更是一点不心疼，甚至分析日志都不需要出力，直接等结果就好了。这种繁琐又单调的任务，从我个人使用经验上来说，AI 工具准确率非常高，几乎从来没有让我失望过。复现过程中，日志锁定所有耗时都耗费在 aya 进行重定向的阶段，于是 Codex 又提出了一大堆优化建议。
但是我在复现的时候，发现我电脑 CPU 基本没有跑满，正常来说，如果出现 CPU 密集型任务导致整个程序被阻塞，那 CPU 不可能毫无反应的，这基本推翻了 Codex 的判断，或者说排查方向需要彻底的切换。看着当前这个 Codex 还在疯狂在 aya 里面加日志，兴致勃勃的试图找到重定向里面耗时的真凶是谁，我完全不忍心打扰它。
于是我当机立断，重新开了一个 Codex 实例，直接开始拉 Ghostscope 的 off-cpu 火焰图。毕竟，既然不是 CPU 密集型任务导致进程运行受阻，那十有八九是 Ghostscope 里面有一处地方，使用了系统调用，然后因为各种原因，主动放弃执行了。果然，off-cpu 火焰图清晰的显示了问题的根因，Ghostscope 耗时都是卡死在了往标准输出写入的系统调用。有了这个信息，问题就基本水落石出了，牛马二号 Codex 很轻松的就定位出来，是因为新增的测试里面为了方便调试，加了 Ghostscope 的 --log-console 选项，很明显 Ghostscope 被启动的时候，标准输出的内容太多了，测试用例又没有及时去读取，导致了这个问题。而这个时候，牛马一号 Codex 还在疯狂汇报工作成果，说自己做了若干 eBPF 字节码相关的性能优化，相信一定解决了这个问题。
局部正确和全局正确
举这个例子，我倒不是想批判牛马一号 Codex 犯了多大的错误，我只想说，它被给予的信息不够它做出更精准的判断。这也是我们说的，每个层级都有自己会接触到的信息和上下文，要让 AI 工具有能力去主动寻求帮助，是非常关键的一件事情。突然感觉 OKR 这种东西，强调每个人目标的清晰与公开，某种程度上，也是为了加强每个人的全局视野，当然这个又扯远了。
另外，关于 AI 可能会胡说八道这件事情，我更希望通过拟人的方式看待这个问题。很多时候，你逼着你的组员开口，非要他发表建议，那他只能胡扯了啊，我觉得这个不能怪 AI 吧，明明是领导者自己的问题，哈哈。再打一个不恰当的比方，一个非常紧急的业务问题，结果上下 文也不跟我说，我一头雾水的情况下就被拉了会，还非要我在会上说几句，妈的，那我只能胡扯了，你想听多久，我就能给你扯多久，只要你开心就好。所以作为 AI 技术团队的架构师，我们要有这个自觉，及时站出来，引导 AI 团队的前进方向。
另外，我还想说，好的架构师，是要让局部正确尽可能接近于全局正确。我一直觉得当前 AI Code Agent 能力已经非常强悍了，基本能在一定范围内保证产出的代码达到一个非常高的准确率了。但是很多时候，局部正确并不等于全局正确，比如说，一个老项目里面，大量复杂的业务引入的隐藏逻辑，甚至有好多负负得正的神奇组合，就像是一个隐形杀手，随时准备给人来上一刀。虽然在刚开始的时候，大家总是希望做一个架构合理，模块职责清晰，可扩展性和可维护性很高的项目，但是随着疯狂的紧急需求和热修复，以及维护人员的迭代，“屎山” 可能是一个长期项目命中注定的结局。话说，我已经开始减缓对 Ghostscope 新功能的开发，因为我感觉已经有点屎山的意思在里面了，我还在思考怎么删减和优化代码。
Vibe Coding
关于 Vibe Coding 我最早知道还是和同事闲聊时候听到的，但是我是读了这篇博客（谈谈 AI 编程工具的进化与 Vibe Coding）之后，才对这个概念有了清晰的认识。我其实一开始是比较反感这个概念的，因为 Vibe Coding 明确强调了，要忘记有代码的存在，对 AI 写的代码从不 review，只看结果，永远通过对话来完成功能。
我觉得，这个不就是跟游戏里面抽卡一样吗，你不能总是能抽中你想要的，如果是 fifa ut 的话，这辈子可能都抽不到想到的。另外，如果是产品级别的项目，怎么保证可维护性，怎么做到对每一行代码负责。仔细想一想，感觉完全不能接受。
但是，这两个月一直在使用 AI Code Agent，我逐渐有一点点改变了我的想法。我开始觉得，如果项目里面整个流程规范和测试兜底做到一定程度，我某种程度上，可以接受 AI Code Agent 部分代码只需要经过简单的 review，就可以合并进项目。甚至个别功能和模块，我可以接受只 review 文档和测试实现，就让代码合并进去。
我觉得这本质上是一个角色转换的问题，mindset 需要改变，要学会放手，毕竟我们现在是一个虚拟技术团队的架构师，不再是普通牛马了，管理着一个“庞大”的项目和虚拟团队，高风险功能还是需要仔细 review 和评审，但是低风险的改动，我觉得完全可以放心 AI 产出的质量，特别是在要求 AI 补上了完善的测试和自我评审之后。
很多人会说，AI 工具没办法对代码产出最后的结果负责。我觉得，背锅不正是一个架构师的核心技能吗？管理一个技术团队，不能只想着汇报这个技术团队的产出，而不去承担可能的风险。这其实也是技术架构师的宿命，不能光看架构师吃肉，不看架构师挨打的时候。
另外，还有一个观点，如果不是自己亲手写的代码，那么很难发现 AI 生成代码的问题。这也是我想强调的一个观点，这是在 AI 时代，对程序员的要求变得更高了。如果没有大量项目和实操经验带来的嗅觉去发现 AI 生成代码里面的坑和陷阱，那么就必须要具备扎实的复杂问题排查和定位能力，两样总得有一样吧，实在不行，也可以跟我一样，边踩坑边练习，拿着 AI 工具自娱自乐。
关于 AI 可能降低效率的思考
现在很多人表达了这么一个观点，AI 工具并没有提升他们工作的效率，更反直觉的是，总体上效率反而变得更低了。我倒并不觉得，这些说法是有问题，一方面代码产生变得廉价，并不代表代码维护成本变低了，这些工作量只是被后置了，而不是凭空消失了。大量的代码生成会给维护者带来很大的心智负担，要知道项目里面的代码永远都是负债，而不是资产。另外一方面，我在我平时工作中，也有一些类似的体验，也就是 AI 工具很难在一个成熟并且复杂的项目里面，立刻就发挥作用，这里需要大量的前置工作，来打通整个流程。
首先，比较遗憾的是，我工作中只能使用 Copilot，甚至连 Cursor 都没得用，更别说现在流行的 Code Agent 了，但我觉得这些其实都不是我最痛苦的地方。我觉得，最痛苦的点在于，目前我的工作流是支离破碎的，AI 很难在里面真正发挥出作用。
举个蛋疼的例子，在于我工作的项目里面依赖老版本的 GCC 编译，导致我们构建环境的系统版本很低，甚至 VS code 都不再支持 ssh 远程登录这样的过时系统(ssh connect issue)，而升级项目的 GCC 版本还需要上下游团队的配合，一时半会根本指望不上。使用老版本的 VS code 勉强可以解决这个问题，但是我想说，其实最新版的 VS code 都挺难用的，而禁止升级，在这 个开发工具快速迭代的时代，无异议是自杀。光是这个问题，就意味着我开发流程中，代码生成和构建流程是支离破碎的，非常蛋疼。另外，各种复杂的历史包袱，恶心又难用的测试环境，频繁切换的工作环境，每个老项目都有着属于自己的故事。如果不把这些垃圾清扫干净，使用 AI 工具的效率又怎么提升的起来。
我发自内心的觉得，AI 工具其实是可以在 Bug 排查中发挥非常大的作用的，之前举例的，繁琐的日志分析，各种问题场景的复现，AI 在能力上完全可以胜任这些工作，只是需要使用者来主导和兜底排查流程的有效性。从 MCP 到 Claude Skills，都是想着办法去增强 AI 工具的触角，把上下文和接口打通，来获取更多有效信息的输入。但是，在老项目里面，这些信息的获取的地方支离破碎，给 AI 喂上下文的成本常常抵消了它带来的自动化收益。有那个手动粘合的时间，不如自己撸起袖子直接开干，毕竟工作的项目非常熟悉，直接修修补补，效率反而来的更高。
所以，是知易行难，想真正做到 AI 工具提效，哪怕有了强大的 AI 虚拟军团，我们其实还是有不少路要走的。
关于 AI 的一些杂谈
过度使用 AI 可能会影响个人技术成长
其实，我觉得个人成长是一个蛮大的话题，但是局限于某项技能的话，基本大家都公认一个道理，就是某个领域投入一万个小时，基本上可以成为相关领域的专家。我记得我刚毕业的时候，有位大佬也跟我说了，专心沉淀五年左右，差不多可以成为该领域的专家。但是，想到我在玩守望先锋中的经历，我不禁对这个结论有点怀疑，两千个小时，还是在黄金分段天天被军训。所以，还得补充一个条件，是得认真练习，反复思考的那种投入才算是有效的，很显然，我玩守望先锋只是消遣，从来不复盘总结，甚至都不看攻略。
话说回来，很显然 AI 工具完成了大量基础性的代码工作，后面可能基础性这个限定词也要取消掉，那确实对新入行的兄弟不够友好，甚至也会影响到熟手的进一步进阶（毕竟以后人人都是技术架构师了😉），因为原来很多个人成长的路径都可能消失了。我一直以来都认同的一个有效的技术成长方式，就是动手去练习，发现问题，尝试去解决问题，然后阅读更好的方案代码，思考和总结，回过头再进行修改和输出。不过，我之前的博客也讨论过不少次这个话题，这里就不展开了。
剥夺了写代码的乐趣
我看到一篇蛮有意思的博客（I am a programmer, not a rubber-stamp that approves Copilot generated code），博主说 AI 工具剥夺了自己写代码的乐趣。但是从我个人业余时候的经历，我比较反对这个观点，我觉得 AI 工具的出现，反而极大地增 强了我写代码的乐趣。最明显的证据，就是我这两个月的 Ghostscope 提交记录，如果没有乐趣，我怎么会这么频繁的提交代码，毕竟也没有人给我发工资。
不过，我倒是认同 AI 工具在开发过程中，可能会出现的一些问题。比较明显的一点是，和 AI 工具结对编程的时候，很容易影响自己进入心流的状态。某种意义上，这也是很多人还是喜欢用 Cursor 而不是 Code Agent 命令行工具的原因，Cursor tab 既保证了我们心流维持的状态，又让我们感觉我们对代码还是有全盘掌控能力。
所以，当你在焦急的等待 AI 工具工作的时候，是不是只能盯着 AI 工具的输出，一旦有不符合预期的，随时准备打断和纠正它。这听起来，有点像我们等待一个大项目的编译完成，看起来只能去打个咖啡，边喝边等。但是我想说，我们已经是一个技术团队的架构师了，你有见过什么时候架构师是在焦急的等待组内成员搬砖完成的吗，或者在线围观组内成员是怎么搬砖的，进行贴身指导。很显然，我们要确保 Code Agent 在完成一个子任务或者某个复杂任务的时候，具备自我校验和自我推进的能力，这样架构师只需要在任务完成或者任务遇到问题，这样的关键节点，再站出来发挥作用。
第二个可能遇到的问题，也是博客里面抱怨的点，是不是我们只能去 approve AI 工具的代码，我觉得当然不是。我为什么觉得我的开发体验变好了，那是因为脏活累活终于有人干了，我拥有了一个任劳任怨的虚拟团队给我干活。这里从来没有一条规定是说，技术架构师是不被允许亲自写代码的，我们完全可以挑选项目里面自己最感兴趣的功能模块，自己来动手去编写代码，这样的话，写代码的乐趣不减反增。
利好开源
虽然我开源做的很少，但是还是能感觉到做开源蛮辛苦的，最重要的是基本没啥经济收益，纯粹兴趣驱动，依赖维护者或者社区的维护意愿。很多时候，有的维护者会“见异思迁”，比如说你现在让我写个网络库，或者写个特定应用层或者传输协议的服务端之类的，我可能就不是特别有动力，因为搬了好多类似的砖的，很想搞点其他新东西玩一玩。现在有了这么强悍的 AI 工具，我觉得对开源项目的发展是极大利好，遇到以前觉得很无聊的地方，都让 AI 工具直接负责到底，快乐的一笔。
我心中适合用 ai 生成代码的编程语言
我之前一直是 C 语言的铁粉，主要是没有太多抽象，心智负担比较低，老大难的内存问题，有 Sanitizer 之类的工具倒也不是特别难以接受，外加娴熟的搬砖技巧，Code snippet 之类的，写起代码也没那么累。但随着 AI 生成代码的流行，我突然有了一个新的想法，就是我越来越不需要语法糖了，毕竟大部分情况下，不是我们架构师在写代码了，简单明了、没有太多抽象的代码风格，反而是我急需的。
所以，在我心中，我觉得 Rust 或者 Go 这种编程语言，特别是 Rust，特别适合用 AI 来生成代码。毕竟 Rust 有严格的语法规则，来兜底各种各样的问题，基本上不存在内存问题，也没有未定义行为，AI 工具写起来都说好。我 倒是不太喜欢 C++ 这样的编程语言，抽象太多了，阅读单个模块的代码，很难对里面实现的细节有真正的了解，必须通篇去阅读，心智负担有点大，存在太多不确定性，需要语言大师才能做到真正的把控。
写博客在 AI 时代是否还有必要
现在 AI 时代下，文字的生成变得越来越简单了，另外，大家可能对于阅读技术博客的需求也在减少，毕竟 AI 能够快速总结和抓取大家关心的要点，哪怕是想要深度学习，也有 DeepResearch 这样好用的工具。说实话，ChatGPT 20 刀一个月的会员，可能是我目前为止花的最心甘情愿的订阅付费服务了。本来我的下一篇博客是准备继续写一写技术相关的主题，名字我其实都早想好了：《Learning eBPF the Hard Way：uprobe 原理探索》。但是我觉得可能意义不是特别大了，考虑到今天的 AI 工具已经这么强悍，我更多的是想尝试用 AI 工具写一写有意思的项目，然后发表一些个人感悟类的博客，也许我的博客应该开始写一写玩游戏的心得体会了，特别是我守望先锋里面，怎么以一己之力带崩全队，还能坦然自若的心得。
当然，写博客虽然对其他人可能意义不大了，但是对我自己还是非常有意义的。一方面还是取悦自己，毕竟写博客是一项输出性质的工作，能够在这个过程中分泌大量多巴胺。第二点的话，是为了强化自己的学习和理解，大家熟悉的费曼学习法就是如此。另外，还能抢救一下自己的写作能力，我其实发现我很容易写病句，每次写完都要读一遍再 调整一下才能勉强通畅，可能是水论坛水多了。而且现在博客里面还是存在大量病句和错别字，其实我应该拿 AI 润色一下，情况会改善很多。但我并没有选择用 AI 润色，一方面是懒，另外一方面是感觉 AI 润色后的内容，没有感情，感觉读起来怪怪的，所以我还是坚持自己手动写，比较原汁原味。
分享一些让我很有收获的信息源
江湖惯例，放上 V2EX 的讨论贴