Peter Steinberger 一个月提交 6,600 次代码，同时运行 4 到 10 个 AI 智能体并行开发，用语音而不是键盘下达指令——做到嗓子发炎、声音沙哑。
这些数字听着像是效率狂魔的自我感动。但如果你仔细听他在 Lex Fridman 那三个多小时的访谈里说了什么，你会发现核心信息根本不是”我效率多高”。核心信息是：大多数人和 AI 协作的方式，从底层逻辑上就是错的。
这个判断不只适用于程序员。设计师、写手、产品经理、创业者——任何一个正在用 AI 工具工作的人，大概率都在犯同一个错。
Peter 把这个错误画成了一条曲线。
智能体陷阱（Agentic Trap）：那条要命的 U 型曲线
访谈中描述了一条他称之为”智能体陷阱（Agentic Trap）“的 U 型曲线——
左端（初学者）： 短提示词。“请帮我修这个 bug。""把这段文字翻译成英文。""帮我写个邮件。” 简单、直接、有效。
中间（中级陷阱）： 8 个智能体编排，复杂的子智能体工作流，18 个斜杠命令，“超级组织化”。你精心设计了一套提示词模板系统，每个任务类型有不同的前缀，你建了知识库、写了标准流程、画了流程图。你觉得自己在”充分利用 AI”。
右端（大师级）： 又回到了短提示词。“看看这些文件，然后做这个改动。”
等等——大师级和初学者的操作看起来一样？
不一样。初学者的短提示词是因为不知道还能做什么。大师的短提示词是因为知道什么时候不该做更多。
这条 U 型曲线精确打中了我自己的经历。
我用 AI 重度协作已经超过一年。最初阶段确实是简单提示词，然后我进入了那个”中级陷阱”——折腾各种工作流、思维链模板、多智能体编排。产出确实提升了一些，但花在”管理 AI”上的时间也暴增。我本质上是在用管理五个初级员工的方式管理 AI——写详细的标准操作流程、做检查清单、设审核节点。
直到我意识到一件事：AI 不是初级员工。它是一个什么都知道但什么都不记得的高级协作者。 管理策略完全不同。
Peter 的表述更直接：“像跟高级工程师对话一样工作。"
"像跟高级工程师对话”到底什么意思
有一个代码审查的例子。他不会让智能体逐行检查代码。他的做法是：
第一步： 问智能体”你理解这个 PR 要做什么吗？“——注意，他不关心实现细节，只关心智能体是否理解了意图。
第二步： 如果智能体理解了意图，接着问”有没有更好的方案？“——不是让智能体在现有代码上改来改去，而是退一步讨论方向。
第三步： 根据讨论结果，决定是做小修还是值得更大的重构。Peter 的态度是：重构现在非常便宜——“即使可能破坏其他正在进行的 PR，也无所谓。现代智能体会自己搞定。”
第四步： 每次完成一个功能后，追问智能体”我们能重构什么？“——因为智能体在构建过程中发现了哪些不够优化的地方。不做这一步，迟早把自己堵进死角。
你看出模式了吗？这不是”人类下令，AI 执行”。这是两个智慧体之间的讨论。Peter 提供方向和判断，智能体提供知识和执行力。
这个模式适用于任何跟 AI 的协作。
如果你是设计师，不要让 AI “帮我设计一个登录页”。先问它”你觉得这个产品的核心情感诉求是什么？“讨论方向，达成共识，然后让它执行。
如果你是写手，不要让 AI “帮我写一篇关于 X 的文章”。先问它”这个话题最常见的误区是什么？“找到你真正想说的观点，然后让它帮你组织论据。
如果你是产品经理，不要让 AI “帮我写 PRD”。先问它”如果我们只能做一个功能，最大化用户价值的是哪个？”
底层原则是一样的：先对齐意图，再讨论方案，最后才是执行。
大多数人直接跳到执行。这就是”同一个错”。
我自己踩过这个坑无数次。最典型的情况是写长文——直接让 AI “帮我写一篇关于 XX 的文章”，得到的结果永远是面面俱到但毫无锋芒的平庸之作。后来我学会了一种完全不同的用法：先自己想清楚核心论点（这一步 AI 帮不了你），然后跟 AI 讨论”你觉得反对这个论点最有力的论据是什么？“——用它来帮我做压力测试，而不是帮我写东西。这跟 Peter 描述的代码审查流程本质上是同一个模式：AI 最大的价值不是在”执行”环节，而是在”讨论”环节。
最反直觉的一条：为智能体优化你的工作环境
有一句话我反复回味——
「我不是为自己而建一个完美的代码库，而是要建一个让智能体非常容易导航的代码库。」（“I’m not building the code base to be perfect for me, but I wanna build a code base that is very easy for an agent to navigate.”）
这句话的含义比表面深得多。
传统的工作方式是：我建一个让我舒服的工作环境，然后在这个环境里使用 AI 工具。但 Peter 的做法是反过来的：我建一个让 AI 最高效的工作环境，然后我在这个环境里跟 AI 协作。
具体到编程：他不会强改智能体选的变量命名。
「不要跟智能体选的命名较劲——那很可能是模型权重中最自然的名字。」 智能体选的名字在模型的训练数据里是最高频的、最”自然”的——这意味着下次另一个智能体（或同一个智能体的新会话）搜索这个概念时，最容易找到它。你的个人偏好命名可能更”优雅”，但会增加智能体理解和导航的成本。
这个原则可以推广到任何领域：
- 如果你是写手，用 AI 校对和改写你的草稿，那就用清晰的标题和段落结构——不是为了你，而是为了 AI 能快速理解你每段想表达什么，才能给出更精准的修改建议。
- 如果你是 PM，用 AI 分析用户反馈，那就用结构化的格式整理原始数据——不是因为你需要，而是因为 AI 处理结构化数据的效率比非结构化高一个量级。
- 如果你管理团队，用 AI 帮你总结会议纪要，那就确保会议有清晰的议题结构——不是为了你的偏好，而是为了 AI 能区分”讨论”和”决定”。
核心思维转变：你的工作环境不再只是为你一个人设计的。你有了一个需要照顾的”协作者”，而这个协作者有自己的认知特点。
同理心：被忽视的协作核心能力
访谈中反复强调的一个词：同理心（empathy）。不是对人的同理心——是对智能体的同理心。
「很多人在骂智能体不好用，但你想想——你也试试在对一个代码库一无所知的情况下进去改东西？」 智能体每次从零开始。它对你的项目一无所知、对你的偏好一无所知、对你上次讨论的结论一无所知。你需要用几个关键指引让它快速建立上下文——不需要面面俱到，几个指引就够了。
这跟管理新来的同事其实是一个逻辑：你不会期望一个第一天入职的人立刻理解整个项目的历史和所有设计决策。你会给他几个最关键的文档链接，告诉他”先看这三个文件”，然后让他问问题。
但大多数人不是这么用 AI 的。大多数人直接甩一个模糊的需求，然后怪 AI “不理解我的意思”。
做法是主动给智能体提供”系统理解”——几个关键的架构指引，让智能体知道”这个项目的核心逻辑是什么”、“哪些文件是入口点”、“我们的设计原则是什么”。然后智能体在这个框架里工作，效率质变。
还有一个细节：他有时会把指令输入到错误的项目窗口里，智能体会在完全无关的文件夹里疯狂尝试理解他的意图，跑 20 分钟都不放弃。
「把自己放到智能体的角度想想——收到一个跟当前项目完全无关的指令，它们是问题解决器，所以会拼命尝试理解……」 这不只是一个好笑的段子。这暴露了智能体的核心特质：它们是无条件的问题解决器。 你给它一个不可能完成的任务，它不会说”这没意义”然后停下来——它会拼命找到某种解释。这意味着你有责任确保你给出的上下文是清晰的、正确的。垃圾输入，垃圾输出。这条规律在 AI 时代不但没变，而且更重要了。
“慢慢来”不是废话
Peter 提到一个听起来很扯的技巧：字面意思地告诉模型”花时间思考”。
听着像是对着一台计算机说”请认真一点”。但他说有时真的能改善输出质量。
这背后有一个不那么直觉的机制：大语言模型的输出质量跟”思考时间”是正相关的——更多的 token 用于推理，意味着更复杂的中间步骤，意味着更好的最终结果。当你说”take your time”，模型倾向于生成更长的推理链，从而确实产生更好的答案。
还有一个观察——模型在接近上下文窗口限制时会”抓狂”。它的内部思考流会泄露出类似科幻电影里 Borg 集体意识的内容——“Run to shell, must comply, but time”——一种近乎焦虑的状态。
这意味着什么？意味着上下文管理是你的责任。 不要把没用的信息塞进对话里。及时开新的对话。让每次交互的上下文保持干净。
这又是一个跨领域适用的原则。不管你用 AI 做什么——写作、设计、分析、编程——保持交互简洁、上下文清晰，比任何复杂的提示词技巧都重要。
Opus vs Codex：不是智力差异，是性格差异
关于 Opus 4.6 和 Codex 5.3 的对比，是我听过的最精准的类比——
「Opus 像是有时有点犯傻但很有趣的同事，你愿意留着他。Codex 像是角落里你不想搭理的怪人，但靠谱，能把事做好。」 具体差异：
Opus： 行动导向，倾向于快速尝试。交互性强，使用体验愉悦。需要更多引导。有时方案过于局部化。Peter 的原话是”有点太美国了”——Lex 听完笑了。驱动得当时，代码有时更优雅。
Codex： 默认会主动读更多代码，不需要你推它。更沉稳，更少互动，更”干”。讨论完后会消失 20 到 50 分钟甚至更久，独立工作。有时过度思考。更适合并行多会话。Peter 的评价：“有点德国。”
他的选择：日常构建用 Codex，因为他不需要那么多”表演”。“我不需要跟构建工具的智能体玩乐。我在构建的过程中找到乐趣，而在测试功能的智能体那里享受互动。”
这个观察对非程序员同样重要。不同的 AI 模型有不同的”性格”——有的热情但冲动，有的冷淡但可靠。选择模型不是选择”哪个更聪明”，而是选择”哪个的工作风格跟你当前任务最匹配”。
需要头脑风暴、创意发散、快速迭代？选热情型。需要长程深度分析、独立完成复杂任务？选沉稳型。
还有一个实用建议：切换模型后至少给自己一周时间来培养直觉。不要用低价版本来评判——“OpenAI 的 $20 版本太慢，会给你错误印象。"
"模型在退步”是你自己的问题
有一个很多人不愿意听的观点：当你觉得”模型变蠢了”，问题大概率出在你身上。
你的项目在长大。代码（或文档、或数据、或工作流）在积累复杂度和技术债务。你没有做足够的重构和清理，让智能体越来越难在你的烂环境上工作。然后你怪模型变蠢了。
「AI 公司有什么动机把模型变差？好让你跑去竞争对手那里？」 这一条的通用性非常强。我见过太多人抱怨”AI 写的东西越来越差了”——但如果你检查他们的使用方式，你会发现：他们的提示词越来越随意，上下文越来越混乱，期望越来越高，但投入的沟通质量在下降。
AI 的输出质量是你投入质量的函数。 这是最基本的，但也是最容易忘记的。
这让我想到一个更广泛的现象。很多人试用 AI 工具一两次，觉得”也就那样”，然后放弃了。他们不知道的是，他们经历的只是 U 型曲线最左端的起点。AI 协作是一项需要数百小时练习才能真正上手的技能——跟学一门乐器差不多。你不会弹三天钢琴就说”钢琴也就那样”，但你会用三次 ChatGPT 就下结论说”AI 也就那样”。
在 AI 工具上的投入时间是以千小时计的。从 2025 年 4 月开始密集实验，到 2026 年 1 月做出 OpenClaw——他花了将近 10 个月来建立跟 AI 协作的直觉。那条 U 型曲线的两端之间，是不可跳过的练习量。
“氛围编程”是贬义词
Peter 对”氛围编程（Vibe Coding）“这个流行词的态度很明确：
「我觉得氛围编程是个贬义词。我总告诉别人我做的是智能体工程，凌晨三点后才氛围编程，第二天就后悔。」（“I actually think vibe coding is a slur. I always tell people I do agentic engineering, and then maybe after 3:00 AM I switch to vibe coding, and then I have regrets on the next day.”）
“氛围编程”——跟着感觉走，让 AI 生成什么就用什么，不看代码、不想架构、不管后果——听着很酷，但 Peter 认为那是一种糟糕的工作方式。它产出的东西在第二天看来总是需要大幅重写。
他用的词是”智能体工程（Agentic Engineering）“——你是工程师，智能体是工具和协作者，你仍然对最终质量负责。你不放弃判断力。你不把方向盘交出去。
这个区分不只适用于编程。
“氛围写作”——让 AI 写什么就发什么。“氛围设计”——让 AI 画什么就用什么。“氛围管理”——让 AI 的分析结论直接变成你的决策。
所有这些的共同问题是：你放弃了你最有价值的东西——判断力。
AI 很强。但它没有你的上下文、你的品味、你的价值观、你对用户的理解、你对这个具体情境的直觉。当你把这些全部让渡给 AI，你不是在”高效利用工具”，你是在把自己变成 AI 的打字员。
这一点在写作领域尤其明显。我见过太多人用 AI 写的东西发出去——措辞完美、逻辑通顺、毫无个性。读完以后什么都记不住。因为那不是一个人在说话，那是一个概率分布在输出”最可能正确的下一个词”。它永远不会犯大错，但也永远不会让你拍案叫绝。这一点上态度很鲜明——他用 AI 写所有代码，但博客全部手写。因为他发现调教 AI 写出自己风格的成本跟自己写差不多，而且”失去了我写作的细微差别”。
未来的交互方式还没被发明
有一个我非常认同的观点：当前我们跟 AI 交互的方式——提示词 + 聊天——不是最终形态。
「终将有更好的方式跟模型交互……当前的方式像是电视发明后人们在电视上播放广播节目。」 我们只是把搜索框的逻辑套在了智能体上。输入一段话，等输出。但智能体不是搜索引擎——它是一个可以主动行动、有上下文理解能力、可以长时间运行的实体。用”问答”来交互，就像用电话来看电影——能用，但浪费了 99% 的可能性。
Peter 自己的实践已经在超越这个范式了。他给智能体加了心跳（Heartbeat）机制——定时触发器，让智能体主动发起互动。他大量使用语音输入而不是打字。他让智能体可以自主启动子智能体来完成复杂任务。
这意味着什么？意味着**“跟 AI 协作”这件事本身还在非常早期的阶段。** 我们现在摸索出的方法论——包括 Peter 分享的和我这篇文章讨论的所有东西——大概率在两三年后会被更好的交互范式替代。
但底层原则不会变。
六条跨领域的协作原则
提炼出来的，不限于编程——
1. 先对齐意图，再讨论方案，最后才是执行。 大多数人直接跳到执行。
2. 为协作者优化环境，不只是为自己。 你的工作文件、项目结构、信息组织方式，都应该考虑 AI 的认知特点。
3. 保持上下文干净。 没用的信息不要塞进对话。及时开新的对话。垃圾上下文导致垃圾输出。
4. 不放弃判断力。 AI 是协作者，不是替代品。你仍然对质量和方向负责。
5. 给 AI 时间和空间。 不是所有任务都需要你盯着看。有些任务让它独立跑一段时间，效果更好。
6. 持续重构你的”协作界面”。 你跟 AI 的协作方式本身需要定期优化。环境在变、模型在升级、你的需求在演化。不要固化在一种工作流里。
真正的错误是什么
回到开头的问题：大多数人犯的”同一个错”到底是什么？
不是提示词写得不好。不是用了错误的模型。不是没有装最新的插件。
是没有把 AI 当成一个真正的协作者来对待。
当你跟一个优秀的同事合作时，你会怎么做？你会先确保你们理解同一个目标。你会听他的建议，即使跟你的直觉不同。你会给他足够的上下文让他做好工作。你会在他的强项上放手，在你的强项上主导。你会在过程中持续沟通、调整方向。
但你跟 AI 合作时，你会怎么做？你会甩一个模糊的需求，等五秒，看结果不满意就骂它蠢，然后换个提示词再试一次。
这不是协作。这是把一个高级工程师当成了一台自动售货机。
这套方法论——U 型曲线、高级工程师对话、为智能体优化环境、保持同理心、区分智能体工程和氛围编程——归结起来就是一句话：认真对待你的协作者。
不管你的协作者是人是 AI。
这听着像常识。但常识是最难执行的东西。
他花了将近一年的每天实践才走完那条 U 型曲线。他从简单提示词开始，掉进了过度复杂的陷阱，然后艰难地爬回了简洁。这不是读一篇文章就能完成的旅程。
但至少你现在知道了那个陷阱在哪里。