最近读到一篇在推特上传播很广的长文，作者 SysLS 是一个从 AI 编程助手还写不好代码的时代就开始用的老玩家。他用 Claude Code 和 Codex CLI 搭建过信号系统、基础设施和数据管道，都是跑在生产环境里的真实项目。这篇文章的标题叫《How To Be A World-Class Agentic Engineer》，翻译过来就是如何成为世界级的 AI 编程工程师。

文章很长，但核心想说的事情其实可以用一句话概括：你之所以觉得 AI 编程助手不好用，大概率不是工具的问题，是你用的方式有问题。

下面我把他的核心观点一个一个拆出来聊聊。

1、别折腾那些花里胡哨的插件了

这是全文最核心的一个观点，也是作者反复强调的。

很多人用 AI 编程助手的第一反应是：我是不是需要装更多插件？是不是需要换一个更好的终端？是不是需要用某个新出的框架？于是他们装了一堆工具，[CLAUDE.md](http://t.cn/AXLo0vJd) 写了两万六千行，各种记忆系统、子代理、技能包堆了一层又一层。

结果呢？越装越乱，AI 反而越来越不听话。

作者说，他试过市面上几乎所有的工具和框架，最后回到了最基础的 CLI 命令行。就是最朴素的 Claude Code 和 Codex，没有任何花哨的外挂。反而是在这种极简配置下，他做出了最好的成果。

为什么会这样？因为每一代 AI 模型都在变强，每次升级都会改变你跟它协作的最佳方式。你今天花大力气搭建的那套复杂工作流，可能下个月模型一更新就不需要了。那些真正有用的功能，比如技能系统、记忆管理、子代理，最终都会被 Claude 和 Codex 官方吸收进产品里。你自己搭的那些第三方方案，迟早会被官方实现替代。

所以他的建议很直接：把那些依赖全卸了，定期更新一下你的 CLI 工具，看看官方加了什么新功能，这就够了。

这个道理放到任何领域其实都成立。工具永远在迭代，与其追逐每一个新工具，不如把基本功练扎实。一个厨师如果连基本刀工都不行，给他再好的厨房设备也做不出好菜。

2、上下文就是一切

作者说了一句很精辟的话：你要给 AI 恰好够用的信息，多一点都不要。

这就是所谓的上下文管理。AI 编程助手的工作原理，简单说就是你给它一堆信息，它根据这些信息来理解你的意图，然后生成代码。问题是，如果你给的信息太多太杂，它就会被淹没。

想象一下，你让一个新来的实习生帮你写一段代码。你跟他说：帮我写个登录功能。然后你又递给他一本 500 页的公司技术手册，一份 26 次会议的记录，还有上个月处理过的 71 个 bug 的日志。这个实习生大概率会懵掉，不知道该从哪里开始。

AI 也是一样的。当你装了一堆插件，每个插件都往 AI 的上下文里塞信息，最后 AI 面对的就是一锅大杂烩。你让它写一个简单的小游戏，它脑子里却装着怎么管理内存、怎么处理子进程崩溃、怎么写会议纪要这些完全不相关的东西。

所以，精简上下文是提升 AI 表现最直接的办法。你给它的每一条信息，都应该跟当前任务直接相关。

3、把研究和执行分开

这是作者给出的最实用的一条建议。

很多人用 AI 的方式是：帮我搭一个认证系统。然后 AI 就得自己去研究什么是认证系统，有哪些方案，各有什么优缺点，选哪个好。等它研究完一圈，上下文已经塞满了各种方案的细节，真正开始写代码的时候，反而容易搞混，把 A 方案的细节混进 B 方案里。

更好的做法是分两步走。第一步，让 AI 去调研各种方案，给你一个对比报告。你看完之后做决定，或者让另一个 AI 来帮你做决定。第二步，开一个全新的对话，把你选定的方案告诉一个干干净净的 AI，让它专心去实现。

比如你不说「帮我搭一个认证系统」，你说「用 JWT 认证，bcrypt-12 做密码哈希，refresh token 7 天过期，实现 token 轮换机制」。这样 AI 不需要做任何调研，直接进入执行模式，效率和准确率都会高很多。

这个思路其实特别值得借鉴。我们在日常工作中也经常犯类似的错误，把调研和执行混在一起做。结果调研的时候想着执行，执行的时候又忍不住回头调研，两头都做不好。把这两件事拆开，先想清楚再动手，看起来慢了一步，实际上快了很多。

4、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 各自在讨好你的驱动下互相制衡，最终输出的结果准确率非常高。

这种思路放到管理上也很有启发。与其要求每个人都客观中立，不如设计一个机制，让不同立场的人互相检验，最终得到一个更接近真相的结论。

5、给 AI 定义清楚什么叫「做完了」

作者指出了一个很多人忽略的问题：AI 知道怎么开始一个任务，但不知道什么时候该结束。

这会导致一个很常见的情况。你让 AI 实现一个功能，它写了一半，觉得差不多了，就停下来交差。留下一堆空壳函数和占位代码，看起来结构很完整，但其实什么都没跑通。

解决办法是给 AI 设定明确的完成标准。最好用的标准就是测试。你提前写好测试用例，告诉 AI：除非这些测试全部通过，否则任务没有完成，而且你不许改测试本身。

这样 AI 就有了一个清晰的终点线。它会一直工作，直到所有测试都跑通为止。

作者还提到了一个更新的技巧：截图验证。让 AI 实现完功能之后，自己截一张图，然后检查截图上的界面是否符合预期。如果不符合，继续改，直到截图验证通过为止。

你甚至可以把这些完成标准打包成一个「合同」文件。比如叫 TASK_CONTRACT.md，里面写清楚：要通过哪些测试，要截图验证哪些页面，要满足哪些具体条件。AI 读了这个合同，就知道自己必须做到什么程度才算完成。

这个思路对日常工作也很有参考价值。很多时候我们觉得一件事做得不好，往往是因为一开始就没有定义清楚什么叫「做好了」。标准模糊，结果自然模糊。

6、不推荐 24 小时不间断运行

很多人好奇那些让 AI 跑 24 小时不停的人是怎么做到的。作者的回答出乎意料：他不推荐这么做。

原因还是上下文问题。如果你让一个 AI 在同一个会话里连续工作 24 小时，处理几十上百个任务，它的上下文会越来越臃肿。前面任务的残留信息会干扰后面的任务，整体质量会持续下降。

更好的做法是每个任务开一个新的会话。你可以搭一个编排层来管理这些会话，当有新任务需要处理的时候，自动创建一个新的合同文件，然后启动一个全新的 AI 会话去执行。每个会话的上下文都是干净的，只包含当前任务需要的信息。

这就像一个团队的工作方式。你不会让同一个人从早到晚不停地切换完全不同的项目，那样效率会越来越低。更好的做法是让每个人在一段时间内专注做一件事，做完再切换到下一件。

7、像培养助理一样培养你的 AI

作者在文章最后给出了一个很形象的比喻。

你新招了一个行政助理，你不会指望他第一天就知道你几点吃饭、喜欢喝什么咖啡、开会喜欢坐哪个位置。这些偏好是随着时间慢慢积累的。

用 AI 也是一样。一开始就保持最简配置，用最基础的 CLI，不装任何额外的东西。然后在使用过程中，你会发现 AI 有些行为你不喜欢，有些事情你希望它按特定方式来做。这时候，你就把这些偏好写成规则。

比如 AI 老是在写代码之前不看已有的代码结构，你就写一条规则：每次写代码之前，先读一下 [coding-rules.md](http://t.cn/AXVhGx6L)。如果是写测试，就读 [coding-test-rules.md](http://t.cn/AXVhGx6U)。如果测试跑不过，就读 [coding-test-failing-rules.md](http://t.cn/AXVhGx6y)。这些规则可以嵌套，可以有条件分支，AI 会很乐意遵守。

你的 [CLAUDE.md](http://t.cn/AXLo0vJd) 应该像一个目录，告诉 AI 在什么情况下去哪里找对应的规则和技能。它本身要尽可能精简，只包含这些条件判断和路径指引。

除了规则之外，还有技能。规则是告诉 AI 不要做什么、要注意什么，技能是告诉 AI 遇到某类问题该怎么一步一步解决。如果你有一套特定的做事方法，就把它写成技能文件，然后在 [CLAUDE.md](http://t.cn/AXLo0vJd) 里告诉 AI：遇到这类场景，去读这个技能。

随着你不断添加规则和技能，AI 会越来越懂你，越来越像一个跟你磨合了很久的搭档。

但这里有一个坑。规则和技能加多了之后，它们之间可能会互相矛盾，或者总量太大导致上下文又臃肿了。这时候你需要做一次清理，让 AI 帮你整合规则，去掉重复和矛盾的部分，问你哪些偏好还有效、哪些已经过时了。

清理完之后，又会恢复到那种丝滑的状态。

作者说，这就是全部的秘密了。保持简单，用规则和技能来塑造你的 AI，把 [CLAUDE.md](http://t.cn/AXLo0vJd) 当作一个精简的目录，时刻注意控制上下文的大小。

8、最后一句话

作者在文章结尾说了一句很实在的话：今天没有任何 AI 是完美的。你可以把大量的设计和实现工作交给 AI，但你必须为最终的结果负责。

这句话放在更大的背景下来看，其实说的是一个关于人和工具之间关系的永恒命题。工具再强大，使用工具的人才是决定结果的那个变量。AI 编程助手让每个人都有了一个能力极强的队友，但能不能把这个队友的能力发挥出来，取决于你怎么跟它协作，怎么给它布置任务，怎么定义什么是好的结果。

说到底，最好的工具，永远是那个你真正理解并且能驾驭的工具。

#科技先锋官##How I AI#