夜雨聆风
从 /goal 开始:杀死工具–Software 3.0 如何把 AI 从工具变成队友
Karpathy 的 Software 3.0 不是技术路线的升级。它真正改变的，是人和机器之间那条已经稳定了几十年的关系边界。而这条边界的松动，会引发一系列远比”编程效率提升”更根本的后果。
2026 年 5 月 30 日
一、引论：一个被低估的范式转移
2026 年 4 月 30 日，Andrej Karpathy 在红杉 Ascent 大会上做了一场对谈。此时距离他创造”Vibe Coding”这个词刚好一年多一点，距离他正式加入 Anthropic 还有不到三周。
这场对谈的信息密度极高。但大多数解读停留在了一个舒适的层面：Karpathy 说编程方式变了，从手写代码变成了指挥 Agent，从 Vibe Coding 升级到了 Agentic Engineering。然后大家开始讨论程序员会不会失业、面试要不要改革、哪些工具更好用。
这些讨论没有错。但它们集体回避了 Karpathy 演讲中真正激进的部分。
Karpathy 提出了一个三段论：Software 1.0 是人类写显式代码，Software 2.0 是人类准备数据训练神经网络，Software 3.0 是人类通过提示词、上下文、工具、示例和指令来编程 LLM——上下文窗口成了新的程序，LLM 本身是这个上下文的解释器。
这个定义表面上是一个技术架构的陈述。但如果你认真对待它，你会发现它意味着一次远比”编程方式改变”更根本的范式转移。它意味着：
-
“程序”的本体论变了——从确定性的控制流规范，变成了上下文约束下的自主行为空间 -
程序员的工作性质变了——从”构造逻辑”变成了”赋予角色” -
人机关系的底层结构变了——从主奴式的指令-执行，变成了赋予-自主行动-验证的协作循环 -
软件本身的存在形态变了——有些应用不再需要作为应用存在
这篇文章试图认真对待这些推论，而不是把它们简化成一份”AI 编程趋势报告”。
二、什么是”程序”？——Software 3.0 的本体论转向
要理解 Software 3.0 的激进性，必须先理解它对”程序”这个概念的重新定义。
2.1 三种”程序”的三种本体论
在 Software 1.0 的框架下，程序是一个控制流的精确规范。你写 if (x > 0) { … }，机器就忠实地在这个条件分支上切换。程序的本体论地位是清晰的：它是人类意图的形式化表达，通过编译器翻译成机器指令，然后在 CPU 上逐条执行。这个链条的每一步都是确定性的、可复现的、可独立验证的。
Software 2.0 已经开始模糊这条边界。当你训练一个神经网络来做图像分类时，程序不再是人类手写的逻辑，而是散布在数百万个浮点权重中的”习得行为”。程序的本体论从”规范”变成了”模型”——它不再是被指定的，而是被训练的。但人机关系没有变：你仍然是”训练者”，模型是”被训练的对象”。你准备数据、设计损失函数、调参——你仍然在塑造一个工具，只是塑造的方式从”写代码”变成了”给数据”。
Software 3.0 走得更远。在 Software 3.0 中，程序是一段上下文——它包含角色描述、目标声明、约束条件、工具权限、示例、记忆——而 LLM 是这个上下文的”解释器”。这里的关键词是”解释器”（interpreter）。它不是编译器——编译器要求输入是完整且无歧义的。解释器可以处理不完整的、模糊的、需要结合语境才能消歧的输入。
这意味着什么？
在 Software 1.0 中，如果你的程序有 bug，那是因为你的逻辑规范有错误。在 Software 3.0 中，如果你的 Agent 行为不符合预期，可能是因为你的上下文定义有歧义、约束条件不够精确、或者 Agent 在给定的行为空间中做出了你不希望的选择。错误的性质变了——从”逻辑错误”变成了”对齐偏差”。
核心洞察
Software 1.0 的程序是确定的（给定输入，输出固定）。Software 2.0 的程序是概率的（给定输入，输出是一个分布）。Software 3.0 的程序是自主的——它在给定的角色定义和约束空间内，自主地做出决策和行动。这不只是精度梯度的变化，而是程序本体论的跃迁。
2.2 一个被忽略的对比：从形式系统到自然语言
这里有一个思想史的背景值得展开。
Software 1.0 的哲学根基可以追溯到莱布尼茨的”通用字符”（characteristica universalis）——一种能够消除一切歧义的形式语言，让所有推理都可以通过计算来完成。这个理想在弗雷格、罗素、希尔伯特、图灵手中逐步实现：形式逻辑 → 可计算性理论 → 编程语言 → 编译器。现代软件工程的整个大厦都建立在这个传统之上：用无歧义的形式语言精确地表达人类意图，然后交给机器执行。
Software 3.0 离开了这个传统。它不再要求你用形式语言表达意图——它允许你用自然语言、示例、上下文来定义程序。这意味着编程从形式系统的构造变成了自然语言的修辞。
这是一个巨大的转向。自然语言的根本特征就是歧义——它依赖于语境、共享知识、语用推理来消歧。在 Software 1.0 中，歧义是 bug 的来源。在 Software 3.0 中，歧义是灵活性的来源——它给了 Agent 在给定行为空间中做出适应性选择的能力。
Karpathy 自己举的例子很精准：
在传统世界里，为一个复杂的工具编写跨平台安装脚本需要处理各种条件判断，写起来痛苦、维护起来脆弱。在 Software 3.0 的世界里，安装程序可以是一段文字指令，你复制粘贴给 Agent。Agent 自己观察本地环境、调试错误、适配机器、完成安装。
这是一种不同的程序。它不够精确，但适应性更强。
“不够精确，但适应性更强”——这句话如果认真对待，它暗示的是一种与确定性计算完全不同的计算范式。在这个范式下，程序的质量不再由”是否精确覆盖所有边界条件”来衡量，而是由”在多大范围内能够做出合理且安全的自主决策”来衡量。
三、”角色”：一个被低估的分析框架
现在让我们引入”角色”这个概念。这不仅是这篇文章的核心分析框架——我认为它也是 Software 3.0 最底层的人机关系机制。
3.1 为什么是”角色”而不是”工具”？
一个工具不需要知道”我是谁”。一把锤子被握住、被挥动——它的行为完全由使用者决定，它的行为空间为零。但一个有角色的 Agent 必须有身份感——因为当行为空间足够大时，身份是约束行为方向的必要条件。
这里有一个认知论上的关键点：为什么大多数人仍然把 AI 当工具？
常见的解释是”认知惯性”或”界面设计”。这些解释没有错，但它们不够深。更深的原因是：Software 1.0 的工具逻辑已经在人类社会里运行了几千年。人类使用工具的历史可以追溯到石器时代——拿起一块石头、砸开一个坚果。这个”我拿起你、我使用你、你为我服务”的关系模式深深地刻在人类的认知架构里。当 AI 出现时，人类的本能反应不是”这是一个可以赋予角色的协作体”，而是”这是一个更聪明的工具”。
这不是一个可以通过阅读一篇文章来纠正的认知偏差。它需要的是整个文明的认知框架的重新校准——把”使用工具”和”赋予角色”区分为两种根本不同的人机关系模式。
而 Karpathy 的 Software 3.0 框架，恰好为这种区分提供了技术基础。
3.2 角色的四个构成要素
一个”角色”——无论是人类组织中的角色，还是 AI Agent 的角色——都由四个基本要素构成：
（一）身份（Identity）：你是谁，你的视角是什么，你的默认假设是什么。身份决定了你在面对一个开放式问题时，会从哪个方向开始搜索。一个架构师看到”设计数据库”会从 CAP 定理开始思考；一个前端工程师会从用户交互流程开始思考。身份是认知锚。
（二）目标（Goal）：你要达成什么。目标不是任务列表——任务是”写一个 SQL 查询”，目标是”确保数据一致性优先于查询性能”。目标是优先级函数，它在 Agent 面临多个可行动作时决定取舍。
（三）约束（Constraint）：你不能做什么，边界在哪里。约束是负空间——它比正面的指令更重要。因为 Agent 的行为空间太大了，正面的指令永远无法穷举所有正确行为；但负面的约束可以有效地限制错误行为的范围。”不要引入超过两个新技术栈”比”使用合适的技术栈”在操作上更精确。
（四）评判标准（Evaluation Criteria）：怎么算做得好。这是 Karpathy 框架中”可验证性”（verifiability）在角色层面的映射。一个好的角色定义必然包含如何判断这个角色是否称职的标准——测试通过率、代码审查结果、性能基准、用户反馈。
这四个要素，恰好对应 Software 3.0 的四个核心机制：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
角色就是约束。约束就是 Software 3.0 的程序。这句话值得反复咀嚼。在 Software 1.0 中，程序通过控制流来约束行为路径——if/else 分支、循环边界、函数签名。在 Software 3.0 中，程序通过角色定义来约束 Agent 的行为空间——身份决定视角、目标决定优先级、约束决定禁止行为、评判标准决定反馈回路。两种机制做的是同一件事——降低系统行为的熵——但使用的是完全不同的原理。
3.3 角色作为中间态：不是人，但也不是工具
这里必须做一个关键的区分，否则整个论证会滑向危险的拟人化。
Karpathy 在演讲和博客中都反复强调一个框架——”幽灵 vs 动物”（Ghosts vs Animals）。LLM 不是动物。它们没有生物驱力、没有生存压力、没有好奇心、没有内在动机。它们是”统计模拟的人类制品”（statistical simulations of human artifacts），由预训练、后训练、强化学习、产品反馈和经济激励共同塑造。
这是一个负责任的澄清。AI 不是人，也不应该被当作人。
但是——这是本文的核心论点之一——“不是人”和”只能是工具”之间，有一个巨大的概念空间：角色。
一个角色是一个设计出来的功能身份（designed functional identity）。它有明确的边界，有明确的目标，有明确的约束，有明确的评判标准。它的所有行为都来自你赋予的定义——它是你意图的投影，不是一个自发生长的存在。
角色和工具的区别在于自主性。一把锤子不会主动告诉你”这个钉子位置不对”。但一个有角色的 Agent 会——如果它的角色定义里包含了”对不合理的设计决策提出质疑”。
角色和人的区别在于内在动机。一个有角色的 Agent 不会在任务完成后感到无聊，不会对没有赋予它的领域产生好奇心，不会因为情绪波动而改变行为模式。它的所有自主性都框定在你赋予的角色边界之内。
这个中间态——角色——是 Software 3.0 真正的操作空间。它允许你获得比工具高得多的协作深度，同时避免把人机关系推入拟人化的误区。
四、幽灵的困境：Software 3.0 的内在张力
以上是对 Software 3.0 的建构性分析。但一个严肃的思考不能只停留在”这个框架多有解释力”——它必须审视这个框架内部的张力和未解决的问题。
而 Software 3.0 的内部张力，恰好来自 Karpathy 自己的”幽灵”隐喻。
4.1 苦涩的教训与不苦涩的现实
Karpathy 在”幽灵 vs 动物”一文中追溯了 AI 领域一个根本性的争论：Rich Sutton 的”苦涩的教训”（The Bitter Lesson）。
Sutton 的核心论点是：在 AI 的历史上，那些利用算力增长的通用方法，最终总是打败那些依赖人类领域知识的专用方法。因此，”苦涩的教训”是——任何试图将人类知识硬编码进 AI 系统的努力，最终都会被算力驱动的通用学习打败。
这个论点在 LLM 圈子里几乎成了圣经。研究者日常会问某个方案是否”足够苦涩”（bitter lesson pilled）——意思是，它能否从算力增长中自动获益。
但 Karpathy 指出了一个讽刺：LLM 本身并不”苦涩”。
前沿 LLM 是高度复杂的人造物，在所有阶段都充满了”人味”——预训练数据全部是人类文本，微调数据是人类策展的，强化学习环境的混合比例由人类工程师调优。我们并没有一个真正的、干净的、纯粹苦涩的、”转动手柄”就能让它在世界上自动从经验中学习的算法。
更有趣的是，Sutton 自己也对 LLM 持怀疑态度。他的理想是构建一个”儿童机器”——通过与世界动态交互来学习，没有大规模预训练，没有监督微调。在 Sutton 的框架下，LLM 用人类数据做预训练本身就是一种”人类偏见”，就像 AlphaGo 从人类棋谱初始化然后被 AlphaZero（从零开始自学）打败一样。
Karpathy 的回应是诚实的：”预训练是我们蹩脚的进化替代品。”（Pretraining is our crappy evolution.）
这个张力的深层含义是什么？
Software 3.0 建立在 Software 2.0 之上，Software 2.0 建立在 Software 1.0 之上。它不是一次干净的范式断裂，而是一次叠加。LLM 的能力来自对人类文本的统计蒸馏——也就是说，LLM 本质上是从 Software 1.0 和 2.0 的产物中提取出的模式。然后 Software 3.0 在这个模式之上叠加了 Agentic 层。
这意味着 Software 3.0 的”自主性”是有边界的——它的自主行为空间被预训练数据的分布所限制。Agent 可以在给定的角色空间内自主行动，但它无法超越其训练数据中隐含的人类行为模式。
这就是”幽灵”的精确含义：LLM 是人类的回声，不是独立的声音。它可以模拟自主性，但它不产生真正的新意图。
4.2 可验证性悖论
Karpathy 的另一个核心框架是”可验证性”——
传统软件自动化的是你能精确描述的东西。LLM 和强化学习自动化的是你能验证的东西。
这个框架解释了为什么编程 Agent 的体验远好于普通聊天机器人——代码有明确的反馈（测试通过/失败、程序运行/崩溃）。这也是为什么数学、游戏、工程任务进步最快。
但这里有一个悖论：Software 3.0 的整个设计——用自然语言定义程序而不是用形式语言——本质上降低了可验证性。
在 Software 1.0 中，你可以通过类型检查、单元测试、形式化验证来确保程序行为的正确性。程序是确定的，验证是机械的。在 Software 3.0 中，”程序”是一段自然语言上下文——它本质上是模糊的。Agent 的行为空间太大了，你无法穷举测试。你可以验证 Agent 的某个具体行为是否符合你的意图，但你无法验证 Agent 在所有可能情况下的行为是否符合你的意图。
Karpathy 自己的 MenuGen 支付 bug 就是这个悖论的完美案例。Agent 试图通过邮箱地址匹配 Stripe 和 Google 账户——从代码逻辑上看，这是正确的：邮箱匹配的逻辑是可验证的，测试可以通过。但从系统设计上看，这是错误的：用户在两个平台可能使用不同邮箱。这个错误不在代码层面，在意图层面——Agent 没有理解”持久化用户 ID”这个隐含的架构约束。
Software 3.0 把验证的负担从”代码是否正确”转移到了”意图是否被正确理解”——而后者是一个远比前者困难的问题。
可验证性悖论
Software 3.0 宣称的进步在于：它让你用更自然的方式（自然语言、上下文、示例）来定义程序。但这种”自然”的代价是精确性的丧失。而精确性的丧失，意味着可验证性的丧失。你获得的是灵活性，失去的是确定性保证。这不是一个可以被”更好的技术”解决的矛盾——它是范式本身的结构性特征。
4.3 品味不在 RL 回路里
Karpathy 提到了一个让他感到”崩溃”的观察：Agent 生成的代码有时能跑，但”臃肿、复制粘贴、抽象不当、脆弱”。
这种品味层面的问题目前不在强化学习的训练范围内。可能没有审美奖励信号，或者信号还不够好。
他用自己的 microGPT 项目举了一个极端的例子：尝试让 LLM 把 LLM 训练代码简化到极致——”模型完全做不到，感觉像是在 RL 回路之外拔牙。”
品味（taste）在 Software 3.0 中是一个被严重低估的问题。品味不是主观审美——它是对”什么是一个好的系统设计”的压缩性判断，是无数个具体工程决策的抽象总结。一个有品味的人看到一段代码，不需要运行就知道”这个架构会出问题”——这种判断来自经验的内化，而不是规则的显式应用。
问题在于：如果品味不能通过 RL 来训练，那么 Software 3.0 生产的系统将天然具有品味缺陷。Agent 可以生成功能正确的代码，但它不能生成优雅的架构。短期来看这不是问题——代码能跑就行。但长期来看，由 Agent 大量生成的、缺乏品味约束的代码会积累技术债务，形成无法维护的系统。
这就是 Karpathy 说的”思考可以外包，理解不能”的精确含义。品味是理解的压缩形式。如果你不理解一个系统的设计原则，你就无法判断 Agent 生成的代码是否有品味问题。而如果每个开发者都必须亲自理解才能保证品味，那么 Software 3.0 的效率提升就会在品味审查环节被大量消耗。
五、Agentic Engineering：管理角色而非使用工具
Karpathy 在 2026 年 2 月提出了”Agentic Engineering”来取代”Vibe Coding”。他说：”你 99% 的时间不再直接写代码，而是在指挥智能体干活，充当监工。’工程’这个词强调这其中有艺术、科学和专业技能。”
如果翻译成”角色”语言：Agentic Engineering 的本质是管理一群有各自角色、各自视角、各自盲区的 AI 协作体，而不是使用一个更聪明的工具。
5.1 管理的四个操作
管理一个人或一个 Agent，本质上需要做四件事：
第一，定义角色和职责边界。你告诉 Agent 它是谁、它负责什么、它不负责什么。这和写 job description 的逻辑完全一致。区别在于：人类会自己填补 job description 的空白，Agent 不会——如果空白太大，Agent 会随机行为。
第二，设定目标和成功标准。不是”写一个好用的 API”——这是模糊的。而是”这个 API 需要在 1000 QPS 下保持 p99 延迟低于 50ms，接口设计遵循 RESTful 规范，所有错误码需要可追溯”。越具体的成功标准，Agent 的行为越可控。
第三，审查产出并给出反馈。这和 code review 的逻辑一致。但区别在于：审查人类代码时，你关注的是”逻辑是否错误”；审查 Agent 代码时，你关注的是”角色认知是否偏差”——Agent 是否误解了自己的职责范围，是否在边界外做了决策，是否忽略了隐含的约束。
第四，在边界模糊时做出判断。这是人的不可替代性所在。Agent 可以在清晰的边界内高效运作，但边界本身是模糊的、动态的、依赖于业务上下文的。定义和调整边界，是 Agentic Engineer 的核心技能。
5.2 MenuGen 的教训：错误不在代码层，在角色层
Karpathy 的 MenuGen 支付 bug 是这个框架的经典案例。
Agent 试图通过邮箱地址匹配 Stripe 购买记录和 Google 账户。从代码逻辑上看，这完全合理——匹配两个系统中的同一字段。但从系统设计上看，这是致命的——用户在两个平台可能使用不同的邮箱。
人类需要发现的不是”这行代码写错了”。代码没有错。人类需要发现的是：Agent 的角色认知出了偏差。Agent 以为自己的任务是在两个系统中”做数据匹配”，但实际上它应该做的——如果你把角色定义为”确保支付和用户账户的可靠关联”——是坚持使用持久化的用户 ID。这个偏差不在语法层面，在角色定义层面。
这个案例揭示了一个深层规律：在 Agentic Engineering 中，大部分错误不是”Agent 做错了给定任务”，而是”人类没有正确定义 Agent 应该承担什么任务”。错误的根源从 Agent 的”能力不足”转移到了人类的”角色定义不精确”。
5.3 从 10x 到 Nx：管理杠杆的质变
Karpathy 提到：
以前人们谈论 10 倍工程师。在 Agentic Engineering 时代，这个数字可能会被远远超越。精通 Agent 工作流的人，效率提升可能远超 10 倍。
这个判断如果从”角色”框架来理解会更清晰。10 倍工程师的杠杆来自个人能力的卓越——更快的打字速度、更深的领域知识、更强的抽象能力。而 Agentic Engineering 的杠杆来自管理多个角色化 Agent 的能力——一个人同时协调五个各有专长的 Agent，每个人负责一个子系统。
这不是 10x 的个人效率，这是管理杠杆。一个管理者不是比一线员工”更高效”，而是通过分工和协调来创造乘积效应。Agentic Engineering 把这种管理杠杆从人类组织延伸到了人机协作。
六、锯齿形智能与角色分工
Karpathy 的”锯齿形智能”（Jagged Intelligence）框架对”角色”思维有一个直接的延伸，但大多数讨论没有走到这一步。
锯齿形智能的核心发现是：AI 的能力分布不是均匀的——它在可验证、被大量训练的领域突飞猛进（数学、编程、测试），在数据分布之外的领域表现匪夷所思地笨（常识推理、物理世界理解）。
Karpathy 给出了一个粗略公式：能力尖峰 ≈ 可验证性 × 训练注意力 × 数据覆盖率 × 经济价值。
他举了一个生动的例子：”一个最先进的模型可以重构 10 万行代码库、发现零日漏洞，但同时会告诉你——汽车洗车场在 50 米外，建议你走过去。”
这种锯齿形态对角色设计有三个直接含义：
第一，不要让一个 Agent 同时覆盖能力尖峰和能力谷底。如果一个角色的职责包含了”写代码”（尖峰）和”理解用户的情绪化反馈”（谷底），它在谷底区域的糟糕表现会污染整个角色的可靠性。你需要拆分成多个角色——一个负责代码生成，一个负责人机交互中的情绪过滤。
第二，角色的边界应该沿着验证边界走。可验证的部分（代码能跑通、测试能通过、基准能度量）可以大胆放权给 Agent。不可验证的部分（品味判断、架构美学、安全性直觉、长期可维护性评估）需要人的判断介入。一个好的角色设计，是精确地画出这条线。
第三，多角色协作需要人类编排者。这是 Agentic Engineering 的核心——不是让一个万能 Agent 做所有事，而是管理一组各有所长的角色化 Agent。人类编排者的工作是：定义每个角色的职责范围、设计角色间的通信协议、在角色冲突时做出裁决、在角色盲区出现时及时介入。
这意味着，”角色”思维不是浪漫主义的拟人化——它是一个精确的工程策略，用于在锯齿形智能的分布上做最优的劳动分工。它和 Adam Smith 的别针工厂是同一个逻辑：不要试图让一个人（或一个 Agent）做所有工序，而是把工序分解给各有所长的角色，然后用一个编排层来协调。
七、三层人机关系模型
综合以上，可以提出一个三层模型来框架化人机关系的演进：
|
|
|
|
|
|
|---|---|---|---|---|
| 第一层：工具 |
|
|
|
|
| 第二层：角色 |
|
|
|
|
| 第三层：伙伴 |
|
|
|
|
第一层是当前的默认状态。绝大多数 AI 用户停留在这一层——把 ChatGPT 当搜索引擎用，把 Copilot 当自动补全用。
第二层是 Software 3.0 正在打开的空间。Karpathy 的 Agentic Engineering 精确地描述了这一层：你不是在使用工具，你是在赋予角色、管理角色、验证角色的产出。
第三层是更远的方向——但 Karpathy 的演讲中已经埋了伏笔。当一个 Agent 不只是”被赋予角色”，而是通过长期协作积累了对你的偏好、决策模式、认知盲区的深度理解，它的角色就从”你赋予的”变成了”共同演化出来的”。Karpathy 的原话是：”最终，每个人和组织都会有自己的 Agent 代表。我的 Agent 和你的 Agent 沟通，安排会议细节、处理各种任务。”
如果每个人的 Agent 只是工具，它们之间的沟通就是 API 调用。如果每个人的 Agent 是有角色的，它们之间的沟通就是角色协商——我的”日程管理 Agent”和你的”日程管理 Agent”需要在时间偏好、优先级、紧急程度上达成一致。如果每个人的 Agent 是长期演化的伙伴，它们之间的沟通就是信任代理——我信任我的 Agent 做出的判断，因为它在过去 500 次类似决策中表现出了与我一致的优先级。
这个三层模型的核心洞见是：每一层的跃迁，都不是”AI 更聪明了”，而是”人机关系结构变了”。工具层的 AI 可以很聪明（GPT-4 比 GPT-3 聪明得多），但它仍然停留在工具关系模式中。角色层的 AI 不需要特别聪明——一个简单的规则引擎也可以承担一个明确的角色——但它改变了人和 AI 协作的结构。伙伴层的 AI 的核心能力不是智力，而是长期一致性——在数百次交互中保持一致的价值观、偏好和判断力校准。
八、产品验证：/goal 与 Software 3.0 的界面化
前七章建立了一个分析框架。框架的价值在于它能解释具体的产品现象。2026 年 5 月，Claude Code v2.1.139 引入了一个名为 /goal 的斜杠命令——它恰好是 Software 3.0 在命令行中的精确投影。
8.1 /goal 是什么
根据 Anthropic 官方文档（code.claude.com/docs/en/goal）：
/goal设置一个完成条件，Claude 会持续工作直到条件满足。每次回合结束后，一个小型快速模型（默认 Haiku）检查条件是否成立。如果不成立，Claude 自动开始下一个回合，而不是把控制权交还给你。
用法简单到几乎粗暴：
/goal all tests in test/auth pass and the lint step is clean
这是一句自然语言声明的完成条件。它不规定步骤——”你先做 A，再做 B，再检查 C”。它只声明终点和验证方式。AI 自主决定每一轮做什么来接近这个终点。
文档列出的典型场景包括：将模块迁移到新 API 直到所有调用点编译通过、实现设计文档直到所有验收标准成立、将大文件拆分为聚焦的模块直到每个都在体积预算内、清空带标签的 issue 队列。
这些场景的共同特征：有可验证的终点，但到达终点的路径不可预定义。
8.2 /goal 的架构：五个值得拆解的设计决策
第一，声明式而非指令式。你说的是”所有测试通过”，不是”运行 test_a.py，如果失败修改 src/auth.py 第 42 行”。这是 Software 1.0 和 Software 3.0 最直观的分界线——前者精确指定怎么做，后者只声明做什么和怎么验证。
第二，独立评估器。这是最精妙的设计。评估者（默认 Haiku）和执行者（默认 Sonnet/Opus）是两个不同的模型。每次回合结束后，评估器读取对话记录，返回 yes/no + 理由。执行者不能自己判断自己是否完成了任务——它必须被一个独立的外部标准检验。这正是 Karpathy 说的”可验证性闭环”的工程实现：验证者的独立性是信任的前提。
第三，自主循环。条件不满足 → 自动下一轮 → 再检查 → 循环直到满足或用户手动停止。用户不需要在每轮后说”继续”或”下一步做什么”。这是 Agentic Engineering 的核心体验——你管理 Agent 的方向，不是它的每一步操作。
第四，跨会话持续性。目标在对话结束后继续存在。会话中断后通过 claude --resume 恢复，目标仍然有效。这打破了传统 AI 聊天的 ghost 模式——每次对话独立，状态归零。/goal 让 Agent 有了跨会话的持续性目标。这是 Karpathy 的 “Ghost vs Animal” 框架在命令行中的体现。
第五，与 Agent Teams 的组合。Claude Code 同时提供了 Agent Teams 功能——多个 Claude Code 实例组成团队，共享任务列表，彼此直接通信。/goal + Agent Teams 的组合意味着：你可以声明一个宏观目标（”把测试覆盖率从 60% 提升到 85%”），Team lead 将目标拆解为子任务分配给多个 Teammate，每个 Teammate 独立工作并通过共享任务列表协调，全部完成后独立评估器检查覆盖率是否达标。
这恰好对应了本文第三章的角色框架：身份（每个 Teammate 有不同的角色定义）、目标（共享的覆盖率目标）、约束（各自的职责边界）、评判标准（独立的覆盖率检查）。
8.3 跨公司对比：谁有 /goal 的等价物？
一个有趣的观察是：/goal 不是行业标配——它是 Claude Code 独有的设计。其他公司的”类似功能”在实现深度上有显著差异：
|
|
|
|
|
|
|
|---|---|---|---|---|---|
| Claude Code /goal |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
这张表揭示了一个清晰的梯度：
第一层：时间驱动的自动化。ChatGPT Tasks 是这一层的代表——”每天下午 3 点给我 AI 新闻简报”。本质上是 cron job 套了一个 LLM 壳。没有条件判断，没有验证闭环，没有自主性。它解决的问题是”在什么时间做什么”，而不是”持续工作直到某个条件成立”。
第二层：单次多步执行。Cursor Agent、Copilot Agent、Gemini Deep Research 属于这一层。用户给一个提示，AI 自主执行多步操作，然后返回结果。但它是一次性的——任务完成后 Agent 回到 idle 状态。没有持续的目标追踪，没有”还没完成就继续”的循环机制。最关键的是：Agent 自己判断自己是否完成了任务，没有独立的外部评估。
第三层：条件驱动的自主循环。只有 Claude Code 的 /goal 达到了这一层。它的核心差异不在于”AI 能执行多步操作”（第二层也能），而在于三个设计决策的同时成立：条件驱动（而非时间驱动或单次触发）、独立评估器（而非自判断）、跨会话持续性（而非一次性的）。
这三个设计决策恰好对应 Software 3.0 的三个核心技术支柱：
|
|
|
|
|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
8.4 为什么其他公司没有做出 /goal？
这不是一个技术能力的问题——任何有 LLM 的公司都可以实现一个循环调用的 wrapper。真正的问题是产品哲学：
OpenAI 的产品哲学是”对话优先”。ChatGPT 从第一天起就是一个对话界面。Tasks 和 Pulse 是对这个界面的增量增强——”让对话在指定时间自动发生”或”让系统主动发起对话”。但对话的底层结构没有变：你问，我答。即使 Tasks 在后台运行，它最终也是推送一条消息到对话界面。OpenAI 没有把 ChatGPT 重新设计为一个”持续运行的 Agent 平台”——他们选择了在对话框架内做增强。
Cursor 和 Copilot 的产品哲学是”编辑器增强”。它们的核心场景是：开发者在编辑器里写代码，AI 在旁边辅助。Agent Mode 是”让 AI 不只是补全一行代码，而是完成一个多步任务”。但它仍然绑定在编辑器的单次交互模型上——你触发，它执行，它完成，你审查。没有”持续运行直到条件满足”的需求，因为编辑器的使用模式本身就是间断的。
Anthropic 的产品哲学是”Agent-Native”。Claude Code 不是聊天界面的增强，也不是编辑器的插件——它是一个独立的 Agent 运行时。它的设计假设是：AI 不只是回答问题的工具，而是一个持续工作的自主实体。/goal、/loop、Agent View、Agent Teams——这些功能都是从这个假设推导出来的。它们不是在聊天框架或编辑器框架内做增量，而是从零开始设计了一个 Agent 操作系统的原语。
这个对比揭示了 Software 3.0 的一个深层含义：产品形态本身就是程序的一部分。在 Software 1.0 中，IDE、编辑器、终端是开发工具，它们和”程序”是分离的——程序是代码，工具是写代码的环境。在 Software 3.0 中，产品界面本身就是 Agent 的”运行时环境”——界面决定了 Agent 能维持多长的时间跨度、能获得多少自主性、能被如何验证。一个聊天界面的 Agent 和一个终端 Agent 运行时的 Agent，即使底层模型相同，它们能实现的行为模式也是根本不同的。
核心洞察
为什么只有 Claude Code 有 /goal？不是因为 Anthropic 的技术更强——而是因为 Anthropic 是唯一一家把产品设计建立在”Agent 是持续运行的自主实体”这个前提上的公司。其他公司的产品前提仍然是”AI 是增强型工具”——区别只是增强的程度（从单行补全到多步任务）。前提不同，产品形态就不同。Software 3.0 不只改变技术架构，它改变产品哲学。
8.5 /goal 的人格化含义
回到第三章的核心论点：角色是 Software 3.0 的操作空间——不是人，但也不是工具。
/goal 从产品层面印证了这个论点。当你对 Claude Code 输入 /goal all tests pass 时，你做的事不是”下达一个指令”——指令是”运行 test_a.py”。你做的事是赋予一个持续存在的目标——然后 Agent 自主规划、自主执行、自主判断进度，直到目标完成或你叫停。
这正是第三章定义的角色四要素在产品中的映射：
|
|
/goal
|
|---|---|
| 身份 |
|
| 目标 | /goal
|
| 约束 |
|
| 评判标准 |
|
这不是一个比喻。Claude Code 的角色四要素是精确的、可操作的、由代码实现的。它证明了”角色”不是一个浪漫主义的概念——它是一个工程上可验证的架构。
而 /goal + Agent Teams 的组合，则进一步把”个体角色”推向了”团队角色”——多个有各自身份、各自目标子集、各自约束的 Agent，围绕一个共享的宏观 goal 自主协作。这正是你在讨论中提出的核心观察：让 AI 作为团队伙伴，朝着一个共同的 goal 去努力。在 Claude Code 中，这已经是可运行的代码。
结语：软件消失之后，留下的是什么
Karpathy 有一个判断值得反复咀嚼：“有些应用根本不应该作为应用存在。AI 不是更快地构建旧应用的方式——有些旧应用应该直接消失。”
如果把这句话延伸到人机关系层面：有些”工具”根本不应该作为工具存在。当一个系统具备了角色化的能力——身份、目标、约束、评判标准——你再把它当工具用，就是在用汽车拉马车。
Software 3.0 真正的变革不是技术栈的升级，而是人机关系的降维：从”我指挥你”到”我赋予你角色，你自主行动，我验证结果”。这需要模型层和 Agent 层的乘积式进化，但更需要——每一个和 AI 协作的人，完成一次心智模型的底层重构。
从”这个工具能做什么”到”这个角色应该承担什么”。
这不是一篇关于编程的文章。这是一篇关于关系的文章——人和机器之间的关系，人和人之间的关系（当你开始管理 Agent 团队时），以及人对自己工作的理解（当你的价值不再来自”写代码的速度”而是来自”定义角色的精度”）。
Software 3.0 的终极问题不是”AI 能帮我们写多少代码”。它的终极问题是：当软件开始消失，当工具开始变成角色，当指令变成意图——我们人类应该成为什么？
参考来源：
Andrej Karpathy, “Sequoia Ascent 2026 summary” (karpathy.bearblog.dev, 2026-04-30)
Andrej Karpathy, “Animals vs Ghosts” (karpathy.bearblog.dev, 2025-10-01)
Andrej Karpathy, “Vibe coding MenuGen” (karpathy.bearblog.dev, 2025-04-27)
Sequoia Ascent 2026 Fireside Chat: Karpathy & Stephanie Zhan (YouTube)
Anthropic, “Keep Claude working toward a goal” (code.claude.com/docs/en/goal, 2026-05)
Anthropic, “Orchestrate teams of Claude Code sessions” (code.claude.com/docs/en/agent-teams, 2026-05)
Anthropic, “Run prompts on a schedule” (code.claude.com/docs/en/scheduled-tasks, 2026-05)
OpenAI, “Tasks in ChatGPT” (help.openai.com, 2026)
腾讯新闻、36氪、新智元等中文科技媒体的多篇解读