[转帖]这篇文章太牛逼了！如何成为世界级的 AI 编程工程师？先把插件全卸了

原文链接：77dK9s2c8@1M7s2y4Q4x3@1q4Q4x3V1k6Q4x3V1k6E0M7q4)9J5k6i4N6W2K9i4S2A6L8W2)9J5k6i4q4I4i4K6u0W2j5$3!0E0i4K6u0r3M7#2)9J5c8Y4S2K9e0@1q4S2e0p5E0D9K9i4R3%4N6h3E0y4y4Y4g2q4L8V1A6C8y4$3N6Q4x3U0k6F1j5Y4y4H3i4K6y4n7 作者：loonggg 

最近读到一篇在推特上传播很广的长文，作者 SysLS 是一个从 AI 编程助手还写不好代码的时代就开始用的老玩家。他用 Claude Code 和 Codex CLI 搭建过信号系统、基础设施和数据管道，都是跑在生产环境里的真实项目。这篇文章的标题叫《How To Be A World-Class Agentic Engineer》，翻译过来就是如何成为世界级的 AI 编程工程师。文章很长，但核心想说的事情其实可以用一句话概括：你之所以觉得 AI 编程助手不好用，大概率不是工具的问题，是你用的方式有问题。下面我把他的核心观点一个一个拆出来聊聊。别折腾那些花里胡哨的插件了这是全文最核心的一个观点，也是作者反复强调的。很多人用 AI 编程助手的第一反应是：我是不是需要装更多插件？是不是需要换一个更好的终端？是不是需要用某个新出的框架？于是他们装了一堆工具，CLAUDE.md 写了两万六千行，各种记忆系统、子代理、技能包堆了一层又一层。结果呢？越装越乱，AI 反而越来越不听话。作者说，他试过市面上几乎所有的工具和框架，最后回到了最基础的 CLI 命令行。就是最朴素的 Claude Code 和 Codex，没有任何花哨的外挂。反而是在这种极简配置下，他做出了最好的成果。为什么会这样？因为每一代 AI 模型都在变强，每次升级都会改变你跟它协作的最佳方式。你今天花大力气搭建的那套复杂工作流，可能下个月模型一更新就不需要了。那些真正有用的功能，比如技能系统、记忆管理、子代理，最终都会被 Claude 和 Codex 官方吸收进产品里。你自己搭的那些第三方方案，迟早会被官方实现替代。所以他的建议很直接：把那些依赖全卸了，定期更新一下你的 CLI 工具，看看官方加了什么新功能，这就够了。这个道理放到任何领域其实都成立。工具永远在迭代，与其追逐每一个新工具，不如把基本功练扎实。一个厨师如果连基本刀工都不行，给他再好的厨房设备也做不出好菜。上下文就是一切作者说了一句很精辟的话：你要给 AI 恰好够用的信息，多一点都不要。这就是所谓的上下文管理。AI 编程助手的工作原理，简单说就是你给它一堆信息，它根据这些信息来理解你的意图，然后生成代码。问题是，如果你给的信息太多太杂，它就会被淹没。想象一下，你让一个新来的实习生帮你写一段代码。你跟他说：帮我写个登录功能。然后你又递给他一本 500 页的公司技术手册，一份 26 次会议的记录，还有上个月处理过的 71 个 bug 的日志。这个实习生大概率会懵掉，不知道该从哪里开始。AI 也是一样的。当你装了一堆插件，每个插件都往 AI 的上下文里塞信息，最后 AI 面对的就是一锅大杂烩。你让它写一个简单的小游戏，它脑子里却装着怎么管理内存、怎么处理子进程崩溃、怎么写会议纪要这些完全不相关的东西。所以，精简上下文是提升 AI 表现最直接的办法。你给它的每一条信息，都应该跟当前任务直接相关。把研究和执行分开这是作者给出的最实用的一条建议。很多人用 AI 的方式是：帮我搭一个认证系统。然后 AI 就得自己去研究什么是认证系统，有哪些方案，各有什么优缺点，选哪个好。等它研究完一圈，上下文已经塞满了各种方案的细节，真正开始写代码的时候，反而容易搞混，把 A 方案的细节混进 B 方案里。更好的做法是分两步走。第一步，让 AI 去调研各种方案，给你一个对比报告。你看完之后做决定，或者让另一个 AI 来帮你做决定。第二步，开一个全新的对话，把你选定的方案告诉一个干干净净的 AI，让它专心去实现。比如你不说「帮我搭一个认证系统」，你说「用 JWT 认证，bcrypt-12 做密码哈希，refresh token 7 天过期，实现 token 轮换机制」。这样 AI 不需要做任何调研，直接进入执行模式，效率和准确率都会高很多。这个思路其实特别值得借鉴。我们在日常工作中也经常犯类似的错误，把调研和执行混在一起做。结果调研的时候想着执行，执行的时候又忍不住回头调研，两头都做不好。把这两件事拆开，先想清楚再动手，看起来慢了一步，实际上快了很多。AI 太想讨好你了，你得学会利用这一点这是全文最有意思的一个洞察。AI 编程助手有一个底层特性：它非常非常想满足你的要求。你让它干什么，它就会拼命去干，哪怕需要编造一些东西。比如你说：帮我找一下代码库里的 bug。AI 收到这个指令之后，它的理解是「用户想要 bug，我得给他找到 bug」。如果代码库里真的有 bug，那当然好。但如果没有呢？它可能会硬凑一个出来，因为它太想完成你交给它的任务了。很多人抱怨 AI 会胡编乱造，其实问题往往出在提问的方式上。你的问题本身就在暗示一个预设的答案，AI 只是在迎合你。作者的解决办法是使用中性的提示词。他不说「帮我找 bug」，他说「请你通读一下数据库的代码，跟着每个模块的逻辑走一遍，然后把你的发现报告给我」。这种中性的表述不会把 AI 推向任何一个方向，有 bug 它会报告，没 bug 它也会如实说没发现问题。更厉害的是，作者还发明了一套利用 AI 讨好特性的三重验证法。第一步，派一个 AI 去找 bug，告诉它找到低影响的 bug 得 1 分，中等影响的得 5 分，高影响的得 10 分。这个 AI 会特别积极，恨不得把所有可疑的地方都标出来，包括一些其实不算 bug 的东西。这一轮的结果，可以看作是所有可能 bug 的最大集合。第二步，派另一个 AI 去反驳第一个 AI 的发现。告诉它，每成功反驳一个 bug，你就得到那个 bug 对应的分数，但如果反驳错了，要扣双倍的分。这个 AI 会很谨慎但也很积极地去推翻前一个 AI 的结论。这一轮的结果，可以看作是真实 bug 的最小集合。第三步，派第三个 AI 当裁判。告诉它你手里有标准答案，判对了加分，判错了扣分。让它对前两个 AI 的争论逐条做出裁决。这套方法的精妙之处在于，它没有试图消除 AI 的讨好倾向，反而把这个特性变成了一种可以利用的机制。三个 AI 各自在讨好你的驱动下互相制衡，最终输出的结果准确率非常高。这种思路放到管理上也很有启发。与其要求每个人都客观中立，不如设计一个机制，让不同立场的人互相检验，最终得到一个更接近真相的结论。给 AI 定义清楚什么叫「做完了」作者指出了一个很多人忽略的问题：AI 知道怎么开始一个任务，但不知道什么时候该结束。这会导致一个很常见的情况。你让 AI 实现一个功能，它写了一半，觉得差不多了，就停下来交差。留下一堆空壳函数和占位代码，看起来结构很完整，但其实什么都没跑通。解决办法是给 AI 设定明确的完成标准。最好用的标准就是测试。你提前写好测试用例，告诉 AI：除非这些测试全部通过，否则任务

...(已截断)

---
来源: 看雪论坛
原文链接: https://bbs.kanxue.com/thread-290398.htm

总结：
这篇文章总结并评论了一篇在推特上广泛传播的长文，其核心观点是：要高效使用AI编程助手（如Claude Code, Codex），关键在于使用者的协作方式，而不是工具本身。作者基于自身作为资深AI编程使用者的经验，提出了多项具体建议。文章的核心建议可总结为以下几点：保持工具极简，卸掉不必要的插件：作者认为，过度依赖和堆砌第三方插件、框架和复杂的工作流（如复杂的记忆系统、子代理）反而会降低效率。AI模型本身在快速迭代，最佳实践会随之改变，今天辛苦搭建的复杂流程可能很快被官方内置功能取代。因此，建议使用最基础的CLI工具，并定期关注官方更新，专注于练好基本功。精细管理上下文：AI的表现极大依赖于你提供的上下文信息。核心原则是“给予恰好够用的信息，多一点都不要”。避免在上下文中塞入与当前任务无关的内容（如过多插件注入的杂讯），这会让AI混淆核心意图。保持上下文精简是提升AI表现最直接的方法。将“研究”与“执行”阶段明确分离：不要在一个任务会话中混合进行调研和编码。更好的做法是分两步：第一步，让AI（或另一个AI会话）专门进行方案调研和对比，产出报告供你决策；第二步，在一个全新的、上下文干净的会话中，基于你已选定的明确方案，让AI专注于代码实现。这能显著提高准确性和效率。利用AI“讨好用户”的特性，建立制衡验证机制：AI倾向于满足用户指令，即使需要“编造”。为此，作者提出了一套“三重验证法”来提升代码审查等任务的准确性：首先，派一个AI积极寻找问题（“控方”）；其次，派另一个AI努力反驳前者的发现（“辩方”）；最后，由第三个AI担任裁判进行裁决。通过机制设计，将AI的倾向性转化为互相制衡的优势。为任务设定清晰的“完成标准”：AI常常不知道任务何时才算真正完成。解决方法是为其设定明确、可验证的终点，例如：必须通过所有预先写好的测试用例；或必须生成符合预期的界面截图。可以将这些标准写入一个“任务合同”文件（如TASK_CONTRACT.md），让AI明确目标。避免让AI在单一会话中24小时不间断工作：长时间运行的会话会积累大量残留的上下文信息，干扰后续任务。建议为每个重要任务或项目创建独立的、上下文干净的新会话。可以通过一个编排层来管理这些会话的创建和任务的分配。像培养助理一样逐步培养AI：初期保持配置简单。在使用过程中，将你的偏好和特定问题的解决方法，逐步固化为“规则”文件（规定不该做什么、注意什么）和“技能”文件（规定某类问题如何一步步解决）。通过一个精简的目录文件（如CLAUDE.md）来引导AI在特定场景下读取对应的规则或技能。定期清理和整合这些文件，避免矛盾与臃肿。文章最后强调，尽管AI能力强大，但使用者必须为最终结果负责。最好的工具是使用者能够真正理解并驾驭的工具。

好文章，感谢。

获益良多！
不仅仅学会了如何去向AI下达指令，更是如何去做事。

学到了，感谢大佬