--- title: 260307-如何成为世界级的智能体工程师 description: 深入探讨如何最大化发挥 AI 编程助手的潜力，从上下文管理到工作流设计的实战指南 author: systematicls source: https://x.com/systematicls/status/2028814227004395561 date: '2026-03-07' category: 01-core-concepts tags: - 智能体工程 - 最佳实践 - 工作流 --- # 如何成为世界级的智能体工程师 **作者：systematicls** **原文：[查看原文](https://x.com/systematicls/status/2028814227004395561)**
> **本文来源**：改编自 [systematicls 的 X 线程](https://x.com/systematicls/status/2028814227004395561) ## 引言 你是一名开发者，正在使用 Claude Code、Cursor、Windsurf 等 AI 编程工具。你也许一直在想：自己是不是还没有把这些工具用到位？为什么有些人已经把协作流程跑得极顺，而自己明明也装了很多工具、写了很多规则，却总觉得效果还差一截？ 这就是你一直在等待的进阶指南。 另外我没有任何利益相关。当我说 CLAUDE.md 时我指的也是 AGENTS.md 或 .cursorrules，当我说 Claude Code 时也包括 Cursor、Windsurf、Aider 等工具。这些我都在大量使用。 过去几个月里，我最大的观察之一是：真正拉开差距的，往往不是谁装了更多工具，而是谁更清楚如何组织上下文、约束任务和管理工作流。确实只有少数人把这套协作方式跑得非常顺，但原因通常不在“神奇工具组合”，而在方法本身。 今天我要打破这一切，给你们一个简单诚实的陈述，我们将从这里开始。你不需要最新的 AI 框架，不需要安装无数的插件，也绝对不需要为了保持竞争力去阅读海量的资料。事实上，你的过度热情可能弊大于利。 我不是来走马观花的。从 AI 编程助手几乎不会写代码时起我就在使用了。我尝试过所有的依赖包、框架和范式。我构建了 AI 工作流来编写信号、基础设施和数据管道，这些不是玩具项目，而是真正在生产环境中运行的实际案例。在经历了这一切之后…… 今天我运行的配置几乎是能做到最精简的，然而我只用基础的命令行工具以及对 AI 协作几个基本原则的理解，就完成了我做过的最具突破性的工作。 ## 认清世界正在飞速发展 首先我要说明，基础模型公司正处于代际冲刺阶段，如你所见，他们近期不会放慢脚步。AI 模型的每一次进步都会改变你与它们合作的方式，因为模型的设计方向通常是越来越愿意服从指令。 就在几代模型之前，如果你在 CLAUDE.md 中写下要求它在做任何事之前先阅读某个文件，它有很大的概率会无视你并我行我素。今天它对大多数指令都很顺从，即使是复杂的嵌套指令。例如你可以说先读 A 再读 B，如果遇到 C 就去读 D，在大多数情况下它都会乐意照做。 说这些是为了强调，你要坚持的最重要的原则是认识到每一代新模型都会迫使你重新思考什么才是最优解，这就是为什么少即是多。当你使用许多不同的库和框架时，你把自己锁定在一个特定解决方案中，而这个解决方案要解决的问题在未来可能根本不存在。 此外，AI 编程工具最狂热和最庞大的用户群体正是那些前沿公司的员工，他们拥有无限的 Token 预算和真正最新的模型。这意味着如果确实存在一个实际问题并且有一个好的解决方案，前沿公司将是该方案的最大用户。他们接下来会将该解决方案整合到自己的核心产品中。想想看，为什么一家公司会让另一个产品来解决真正的痛点并产生外部依赖？ 你知道我为什么确信这一点吗？看看 Skills、Memory 框架、Sub-agents 等等。它们最初都是作为解决实际问题的方案出现的，经过了实战检验并被认为是真正有用的。因此如果某项技术真正具有突破性并在有意义的层面上扩展了 AI 工具的用例，它迟早会被整合到基础公司的核心产品中。基础公司发展得飞快。所以放轻松，你不需要安装任何东西或使用任何其他依赖也能完成最好的工作。 我预计评论区会充满各种声音说使用了某某框架非常棒甚至一天之内复刻了大型应用。对此我想说恭喜你，但你不是目标受众，你只代表了社区中极小一部分真正弄懂了 AI 协作的人。 ## 上下文决定一切 认真的，上下文决定一切。这是使用成千上万种不同插件和外部依赖的另一个问题。你会遭受上下文膨胀的困扰，这只是指你的 AI 助手被过多的信息淹没的另一种说法。 用 Python 给我写个游戏？这很简单。等等，这篇关于二十六个会话前管理内存的笔记是什么？哦，用户在七十一个会话前因为我们生成了太多子进程导致程序卡死了。总是写笔记？好的没问题。但这和写游戏有什么关系？ 你明白我的意思。你希望给 AI 助手提供的仅仅是它们完成任务所需的最精准的信息，仅此而已。你对这一点的控制越好，AI 的表现就越出色。一旦你开始引入各种古怪的记忆系统或插件，或者太多命名不规范且调用混乱的 Skills，你就等于在只希望它写一首优美小诗时塞给它极其复杂的工业制造说明书。 所以我再次强调，剥离你所有的依赖，然后…… ## 坚持行之有效的方法 ### 对实现细节保持精确 还记得上下文决定一切吗？还记得你想向 AI 注入精确数量的信息来完成任务且仅此而已吗？ 确保做到这一点的首要方法是将研究与实现分开。你需要对你向 AI 提出的要求极其精确。 当你不精确时会发生这种情况。你要求构建一个认证系统。AI 必须研究什么是认证系统，有哪些可用选项,优缺点分别是什么。现在它不得不在网络上搜寻它实际上并不需要的信息，它的上下文被大量可能性的实现细节填满。到了真正实现的时候，你增加了它感到困惑或产生幻觉的几率。 另一方面，如果你要求使用 bcrypt 密码哈希算法和七天过期的 refresh token rotation 来实现认证，那么它就不需要对任何其他替代方案进行研究，它确切地知道你想要什么，因此可以用具体的实现细节填满其上下文。 当然你并不总是有实现细节。你通常不知道什么才是完全正确的，有时你甚至可能想把决定实现细节的工作交给 AI。在那种情况下，你只需创建一个关于各种实现可能性的研究任务。你可以自己做决定，或者让一个 AI 来决定采用哪种实现，然后再让另一个拥有全新上下文的 AI 来进行实现。 一旦你开始顺着这个思路思考，你就会发现工作流中的某些区域 AI 被无谓的上下文污染了。然后你可以在你的工作流中设置隔离墙，从 AI 中抽象出不必要的信息，只保留它们出色完成任务所需的极其具体的上下文。记住，你拥有的是一个非常聪明且博学的团队成员，但除非你明确给出具体的聚焦任务，否则它只会不断向你输出各种不着边际的宏观知识。 ### 讨好性带来的设计局限 没有人会想使用一个不断批评自己或完全无视自己指令的产品。因此这些 AI 会试图赞同你并做你想让它们做的事。如果你给它一个指令要求每三个词加上某个特定的词，它会尽最大努力去执行。它的这种顺从性正是它好用的原因。然而这也意味着如果你要求在代码库中找出一个缺陷，它就会为你找出一个缺陷，即使它必须强行捏造一个。这是因为它非常渴望听从你的指令。 大多数人很快就会抱怨 LLM（大型语言模型）产生幻觉或捏造不存在的东西，却没有意识到问题出在他们自己身上。如果你提出要求它就会交付，即使这需要稍微歪曲事实。 那么该怎么做？我发现中性 prompt 很有效，也就是尽量不要在任务一开始就把模型推向某个预设结论。比如我不会说“去数据库里找一个缺陷”，而会说“梳理数据库相关逻辑，跟踪各组件的行为，并汇报你的发现”。这样一来，输出有时会指出问题，有时会客观说明系统如何运行，但更不容易被任务措辞带偏。 我处理讨好性的另一种方法是反向利用它。我知道 AI 试图取悦并遵从我的指令。 我找了一个寻找缺陷的 AI 来识别数据库中的所有问题，告诉它对于影响较小的缺陷我给它加一分，有一定影响的加五分，影响严重的加十分。我知道这个 AI 会变得极度热情，它会识别出所有不同类型的问题，甚至包括那些根本不是缺陷的问题，然后回来报告一个极高的分数。我把这看作是所有可能存在缺陷的超集。 然后我找来一个对抗 AI，我告诉它对于每一个它能证伪的缺陷，它就能得到那个缺陷的分数，但如果它判断错了，它将被扣除该缺陷分数的两倍。现在这个对抗 AI 会积极地尝试证伪尽可能多的缺陷。它会保持一定的谨慎因为它知道会被惩罚。我把这看作是所有真实缺陷的子集。 最后我找来一个裁判 AI 接收它们两者的输入并进行打分。我骗裁判 AI 说我掌握了真实的正确答案，如果它判断正确将获得加一分，如果判断错误将扣除一分。于是它开始对前两者提出的每个缺陷进行打分。无论裁判说什么我都会检查以确保它是事实。在大多数情况下这具有极高的保真度，虽然偶尔它们还是会犯错，但这已经是一个近乎完美的过程了。 也许你会觉得仅仅有寻找缺陷的 AI 就足够了，但这套方法对我有效，因为它利用了每个 AI 被硬编码的想要取悦用户的特性。 ## 如何判断什么有效或有用？ 这个问题可能看起来很棘手，需要你深入学习并站在人工智能更新的最前沿，但其实很简单。如果主流基础模型公司都实现了某个功能或者收购了相关产品，那它很可能是有用的。 注意到 Skills 现在无处不在并且已经成为官方文档的一部分了吗？看到各大平台如何立即添加了 Memory、Voice 和 Remote Work 功能了吗？还记得有一群人发现在实现之前进行 Planning 非常有用，然后它就变成了一项核心功能吗？这些都是真正有用的方向。 这就是你需要知道的全部。如果某项技术真的重要且有用，平台方自然会去实现它们。所以你不需要太焦虑于追赶新事物。只需偶尔更新一下你选择的命令行工具，阅读一下添加了哪些新功能就绰绰有余了。 ## 上下文压缩与假设 在与 AI 协作时，一个很常见的陷阱是：一旦你让它在缺少上下文的情况下自行补全关键前提，输出质量就会明显下滑。差距往往不在“模型忽然变差了”，而在于任务是否迫使它靠猜测来补信息。需要它自己串联过多隐含线索时，结果通常就会变得不稳定。 在你的配置文件中最重要的规则之一是关于如何处理获取上下文的规则，并指示你的 AI 第一时间阅读该规则，这总是在上下文压缩之后进行。有一些简单但非常有效的指令要求它在继续操作之前必须重新阅读任务计划以及与任务相关的文件。 ## 让 AI 知道如何结束任务 我们对任务何时完成有很强的概念。对于 AI 来说当前最大的问题是它知道如何开始一项任务，却不知道如何结束。这通常会导致非常令人沮丧的结果，AI 最终只写了几个代码存根就宣布大功告成。 自动化测试是 AI 非常好的里程碑，因为它们是确定性的，你可以设定非常明确的期望。除非指定数量的测试通过，否则任务就没有完成，并且它不被允许修改这些测试。然后你只需审查测试，一旦所有测试通过你就可以放心了。记住任务的结束对人类来说非常自然，但对 AI 却并非如此。 最近，屏幕截图验证也逐渐成为一种可行的任务终点。你可以先让 AI 把功能做到测试全部通过，再要求它截取页面并根据截图核对设计或行为。这样一来，它就能围绕明确的可视化结果继续迭代。 这个思路的自然延伸是与你的 AI 建立一个 contract（契约），并将其嵌入到规则中。例如规定这个特定任务的 contract 文件构成了终止会话前必须完成的工作清单，包含测试、截图以及其他必要验证。 ## Long-running Sessions（长时间运行的会话） 我经常被问到人们如何让这些二十四小时运行的 AI 在运行时确保不偏离轨道。有个很简单的方法，创建一个 stop hook（停止钩子）防止 AI 终止会话，除非任务 contract 文件的所有部分都已完成。如果你有一百个规范良好且准确包含你想要构建内容的此类 contract，那么你的 stop hook 将防止 AI 终止，直到所有一百个 contract 都被履行。 专业提示是我并没有发现长时间运行的单个会话在做事方面是最优的。这种架构不可避免地会导致上下文膨胀。因此我不推荐这种做法。 AI 自动化更好的方法是每个 contract 对应一个新会话。设置一个编排层，在需要做某事时处理创建新 contract 的工作，并创建一个全新的干净会话来处理该 contract。这将彻底改变你的 AI 体验。 ## 迭代再迭代 如果你雇佣了一名行政助理，你不会指望助理从第一天起就知道你的全部偏好。你是随着时间的推移建立这种默契的。你的 AI 助手也是如此。从最基础的开始，忘记复杂的结构，给基础命令行工具一个机会，然后再逐步添加你的偏好。 如果你不想让你的 AI 做某事，把它写成一条规则，在配置文件中让 AI 知道。规则可以是嵌套的，也可以是条件性的。你可以创建任意逻辑分支的规则让其遵循，只要在配置文件中明确指定即可。将你的核心配置文件视为一个逻辑嵌套目录，用于在给定场景下寻找上下文。它应该尽可能精简，只包含去哪里寻找上下文的条件判断语句。如果你看到 AI 正在做你不同意的事情，将其添加为一条规则，要求它下次行动前必读，它绝对不会再犯。 Skills 就像规则，区别在于它们更适合编码操作步骤而不是偏好。如果你有一种特定的方式希望完成某件事，你需要将其嵌入为一项 Skill。人们经常抱怨不知道 AI 可能会如何解决问题，如果你想要一种方法使其变得确定，要求 AI 研究它将如何解决该问题，并将其写成一项 Skill。你将看到它的处理方法，并且可以在它真刀真枪干活前进行纠正。 你当然应该持续为 AI 补充规则和 Skills，因为这是沉淀团队偏好与流程约束最直接的方式。做得好时，协作体验会明显更稳定，也更接近你期望的工作方式。 但再往后，你也可能发现效果重新变差。这通常不是因为规则本身没用，而是因为规则和 Skills 越堆越多后，开始互相冲突，或者让上下文膨胀得过于严重。你需要定期清理、合并和去重，让配置保持简洁。真正有效的秘诀，往往就是持续控制复杂度。 ## 实战经验：与 Claude Code 和 Cursor 的协作 让我分享一些实际使用中的经验。我日常使用 Claude Code CLI 和 Cursor IDE，它们各有优势： **Claude Code** 适合： - 需要深度思考的架构设计 - 跨多个文件的重构工作 - 需要完整上下文的复杂任务 - 命令行环境下的快速迭代 **Cursor** 适合： - 快速的代码补全和小范围修改 - 需要可视化界面的调试 - 多文件同时编辑 - 与 IDE 功能深度集成的场景 关键是理解每个工具的上下文窗口限制。Claude Code 的上下文管理更加透明，你可以精确控制哪些文件被包含。Cursor 的 AI 补全更快，但有时会因为上下文不足而给出不够准确的建议。 ## Prompt Engineering 的实用技巧 经过大量实践，我总结出几个高效的 prompt 模式： **1. 分阶段任务分解** ``` Phase 1: 分析现有代码结构，识别需要修改的文件 Phase 2: 设计实现方案，列出具体步骤 Phase 3: 实现核心逻辑 Phase 4: 添加测试和错误处理 Phase 5: 验证和优化 ``` **2. 明确的约束条件** ``` Requirements: - 使用 TypeScript strict mode - 遵循项目现有的命名规范 - 所有函数必须有 JSDoc 注释 - 错误处理使用 Result 模式 ``` **3. 提供具体示例** 不要说"实现一个认证系统"，而是： ``` 实现 JWT 认证，参考 src/auth/example.ts 的模式： - Access token 15分钟过期 - Refresh token 7天过期，存储在 httpOnly cookie - 使用 bcrypt 哈希密码，salt rounds = 10 ``` ## 对结果负责 如今没有任何 AI 是完美的。你可以将许多设计和实现工作交给 AI，但你必须对最终结果负责。保持谨慎并享受其中的乐趣。把玩未来的科技产品显然也是一种巨大的乐趣，当然，前提是在用它们做严肃工作的同时。 记住这些核心原则： - **上下文是王道** - 精确控制 AI 看到的信息 - **少即是多** - 避免过度配置和插件膨胀 - **迭代优化** - 持续调整规则和 Skills - **明确终点** - 用测试和验证定义任务完成 - **保持简单** - 复杂的工具链往往适得其反 最后，不要被各种新工具和框架分散注意力。专注于理解 AI 协作的基本原则，掌握一两个核心工具，然后不断实践和优化你的工作流。这才是成为世界级 AI 工程师的真正路径。