刚在《自然语言就是新的程序设计语言》里谈到 Karpathy 对软件的划分：1.0 是人写代码，2.0 是从数据中训练出模型，3.0 是用自然语言给模型指定任务。

这周，到处都有人想拿 Jev 做点什么。第一次看到 TypeSafe 的发布文，我却没那么兴奋。System One Model、frontier intelligence、can’t hallucinate，几个词看下来，我冒出的念头是：这不就是分类器吗？给一段文字，从几个选项里挑一个，再带上概率。上过机器学习课的人，对这个太熟悉了。

后来我觉得，自己可能又犯了那篇文章里说过的毛病。知道这东西怎么来的，就容易忽略别人第一次用到它是什么感觉。分类器不新鲜，但一个从来没训练过模型的人，现在写几句说明，就能把它接进自己的小工具里，确实也是一个令人兴奋的体验。

只做判断

先不用管 Jev 的底层架构，官网也没有 Open Source 或者 Open Weight。对使用者来说，可以把它看成一个函数：把相关信息、问题和允许的答案交给它，它返回判断和概率。

比如我想给记账软件加一个自动分类功能。输入可以是这样：

消费记录：Uber Eats ¥2,380
问题：这笔消费属于哪一类？
选项：餐饮 / 交通 / 购物 / 娱乐 / 其他

程序拿到的会是选项以及各选项的概率，可以直接用来决定如何入账。

Jev 目前提供三种问法：Choice 从最多 255 个选项里选一个；Score 按你定义的 2 到 10 个有序等级评分；Noul 返回一个是非问题中“是”的概率，再由代码决定怎么处理。它不提供自由文本生成，也不会解释自己为什么这么选。

TypeSafe 把它叫作 smart if-statement。很多判断，规则写起来很烦，人却一眼就知道大概。Jev 想接手的就是这种难以人工编码的直觉。

普通 LLM 当然也能做。通过结构化输出，它也可以只给分类结果，不必先写一段客套话。Jev 值不值得用，要看完成同一个判断时，它的正确率有多高。毕竟更快地做出一个错误的决定，并非一件好事。

省在哪里

以前要给消费分类，可以写规则，也可以训练模型。用传统机器学习做这件事，收集样本、标注、训练和维护是一笔不小的成本。

Jev 省掉的是为每个新任务单独训练模型这一步。你写好问题和判断标准，就能先试起来。按目前官方定价，每百万输入 token 收 0.042 美元，输出免费。假设一次请求总共用了 1,000 个输入 token，一万次调用的模型费用是 0.42 美元。

相比 LLM，这很便宜。不过，用 Jev 也要整理输入、测试错误、维护分类标准，这些成本不会出现在 API 账单上。

更要看的是尝试成本。一个想法还不值得专门训练模型，却已经值得花一点时间写好问题、调一次接口。记账、邮件整理、工单分派，都是这种小需求。

早期也有零样本分类器，比如 BART-MNLI。它经过专门训练，学会判断两句话的关系：前一句能不能推出后一句，两句是否矛盾，还是信息不足、无法判断。这叫自然语言推断，NLI。

比如想知道某个报道的主题是“体育、财经还是科技”，程序就把三个类别分别填进固定句式：“这段文字讲的是体育”“这段文字讲的是财经”“这段文字讲的是科技”。然后把原文分别和这三句话配对，交给模型判断。如果原文是“这支球队赢得了冠军”，模型就应该更支持第一句，于是程序把它归到“体育”。

它的 trick 就在这里：把分类问题改写成模型已经学过的句子关系判断。换一组类别，只要换掉句式里的词，不用再拿新类别的样本训练模型，所以叫零样本分类。它仍然是一个 Software 2.0 式的模型，通过巧妙地改写输入，获得了通用性。这和今天 LLM 能按自然语言指令处理各种任务的通用能力，还是有距离。

Jev 想做的，是把更广泛的语言理解能力放进一个便宜、快速的判断接口里。它真正要回答的是：换一个任务，能不能靠几句说明就用起来。它是不是第一个零样本分类器，没那么重要。

为什么是 Software 2.5

同一个 Jev 模型，今天给消费分类，明天给 issue 分配负责人，换一段问题和选项就行。当前官方服务不支持按客户数据做 fine-tune，各账号使用相同权重，行为通过输入和判断标准来调整。

叫它“2.5”，说的是它在程序里的用法：它像 LLM 那样允许你用自然语言写问题和判断标准，接入之后，它又像一个传统分类器那样，只负责流程中有限的几个判断。它想要接近 3.0 的任务适应性，同时保留 2.0 的成本和速度。

区别在于模型能不能理解你新写的判断逻辑，而不只是换几个标签。至于要不要搭流程，并不能拿来划代，LLM 应用一样要写流程和业务代码。

比如客服收到一条留言：“耳机左边没声音，换了手机也一样。”你可以让 Jev 在“故障反馈、使用咨询、购买咨询、其他”里选一个。各类怎么定义、分到哪支客服队伍，由你事先写好；它负责读这句话，判断更接近哪一类。

这种用法可以理解成语言直觉：读一段描述，直接判断哪个答案合适。有点像大模型不展开思维链、直接作答时的状态。它能做语义判断，并不意味着它就能一步步推导出答案。

日期比较、精确计算、寻找最优交通路径，这些工作应该交给代码和相应的算法。TypeSafe 的 jaggedness 文档也写了当前版本在计算、日期和多层间接关系上的短板，以及无关上下文对判断的干扰。拿它做什么，要看问题本身需要什么，不能只看最后的答案是不是一个选项。

《Jev 全网首测 benchmark 与架构解析》里做了两组测试，总共 400 道题。我看过原始测试数据：200 道简单单选题全对；另一组是 40 个问题族，每族 5 个变体，共 200 道题，需要从长文本里抓住关键事实，准确率只有 32.5%。这个数字很微妙，因为四个选项随机也有 25% 的概率。

有些变体把决定答案的关键事实反转了，它还是选原来的答案。在这组题里，置信度也没能可靠地区分对错。简单题上看着很稳，一遇到藏在长文本里的条件变化，就可能给出很笃定的错误判断。

这对接入方式有直接影响。测试时要专门改动那些本应改变答案的事实，看模型会不会跟着改。只拿几道一眼就知道答案的题来演示，看不出这种问题。

要把 Jev 用好，输入也得先整理。比如给消费分类，我会从邮件里取出商户名、商品描述等相关信息，去掉签名、广告和无关记录，再写清楚“餐饮”“购物”这些类别的边界。官方文档也建议先用代码筛选信息，只把当前判断需要的内容交给模型。

挑信息、组织输入这部分，让我想起 Software 2.0 时代做传统分类器时的 feature engineering，也就是特征工程。那时要把原始数据加工成有用的特征；现在可以用自然语言和结构化字段，把判断所需的信息交给 Jev。模型替你省掉了很多工作，但哪些信息值得看、该怎样组织，仍然需要你理解自己的业务。

再准备一批自己知道答案的真实样本，检查误判，调整问题、类别定义和置信度阈值，才算把它接进了程序。Jev 省掉了针对每个任务训练模型的步骤，但围绕模型做这些准备的功夫，还是很有 Software 2.0 的味道。

最自然的架构是：固定规则 → Jev → 大模型兜底。 能用写死的代码处理的，先交给成本最低的代码；规则处理不了、需要理解语义的，再调用 Jev；Jev 置信度低，再交给大模型判断。

营销确实厉害

我对 Jev 在技术上的 moat 还持保留意见，但这个产品的需求是真实存在的，至于为什么这么火，那我们得谈一谈营销了。

先说技术。复刻的门槛不高，开源实现已经冒出来了。Laya 用 4 亿参数的 ModernBERT 做底座，Apache 2.0 许可，还自带一个和 Jev 同协议的 HTTP 服务，原来调 Jev 的代码改一下 baseUrl 就能换过去。还有人直接拿千问的开源模型改一改：Kev 在 Qwen2.5-0.5B 上加了一个 LoRA 和一个小的打分头，Jeff-1 是 Qwen3-4B 的 LoRA，都提供同样的 Choice / Score / Noul 接口。当然，接口一样不等于判断一样准。Laya 自己公布的对比里，选项超过 20 个时就明显不如 Jev。

Jev 的名字取自 William Stanley Jevons，TypeSafe 在发布文里明确说了这个来历。杰文斯悖论讲的是，效率提高之后，新增需求可能超过节省下来的消耗，最后资源反而用得更多。我在《AI 不是节约型创新》里也讨论过这一点。

这个名字取得真好。它和 Claude 一样，有个人名的亲近感，短，好记，叫起来顺口。背后的 Jevons 又让人立刻想到每一个押注 AI 规模继续增长的投资者都希望成真的故事：智能越来越便宜，用它的人和地方越来越多，新增需求大到足以抵消效率提升省下的算力。

还有 System One 这个定位。大模型刚出来时，就有人说它是 System 1，靠直觉和联想直接给答案。Bengio 和 Edward Hu 在 2023 年的一篇文章里就写过，很多人把语言模型比作 System 1，期待未来的 System 2 来处理可靠的推理。到了 o1、DeepSeek R1 这一波推理模型，慢思考成了卖点。2025 年甚至有篇综述，题目就叫《从 System 1 到 System 2》。

现在 Jev 又来做 System One。这个位置找得很巧：让大模型去慢慢推理，自己负责快速判断。这样一讲，输出能力有限就成了一种分工，便宜、快也和“直觉”这个说法对上了。一个判断接口，听起来成了智能系统里值得单独做出来的一部分。

这套说法很会抓人。但 System 1 和 System 2 在这里终究是比喻。它能帮助人理解产品，证明不了 Jev 的内部机制，也不能替它回答前面那些长文本测试。研究里用了多年的说法，到了产品发布时，又成了一个新品类的名字。

发布文里所谓的“没有幻觉”也是如此。答案 100% 落在预先规定的类型和选项里，因为这个约束就是普通的代码，也就是 Software 1.0。“没有幻觉”不代表判断是对的。

更要紧的是它对置信度的承诺。TypeSafe 在发布文里明确写道：“Calibrated: higher confidence means higher accuracy.” 置信度越高，准确率越高。它还拿普通 LLM 来对比：如果模型不知道自己什么时候会错，就没法放心拿来做自动化。使用文档也建议按置信度分流，高的自动处理，低的交给人或其他系统。这是它的一项核心卖点。

前面那些关键事实反转的题，正好考验这个承诺。答案错了，置信度却仍然很高，意味着按置信度分流时，这些错误可能直接被程序放行。问题落到了它承诺解决的地方：模型犯错时，能不能提醒你别信它？至少在这组测试里，这个信号没有起到应有的作用。要验证这个卖点，得把高置信度的答案单独拿出来，看看究竟对了多少。

还有那两个很适合做标题的数字：快 193.6 倍，便宜 444.6 倍。TypeSafe 的发布文交代了，这是自家 workflow 评测的结果，而且偏向实际收益的高端。这套评测预先写好流程，再比较各模型在流程里的判断，参照标签来自 GPT-6 Astra 和 Fable 5.1 这两个旗舰模型的平均输出。它可以说明这些流程里的表现；转发时如果只剩两个倍数，适用范围就丢了。

官方发布之外还有一些纯噱头，可以说是造假。我看过的“用 Jev 瞬间生成网页”，组件其实已经预先写好，Jev 只负责选模块；拿来对比的 LLM，却要从头生成网页代码，这种方法未免对 LLM 太不公平。

还有一个 Minecraft 通关演示：通关流程已经写死在程序里，就算把 LLM 和 Jev 都拿掉，也不影响通关。

我个人的应用场景

最贴近我手上工作的，还是记账软件 PocketBean。邮件里进来一笔消费，最后需要的是一个分类。如果 Jev 在我自己的记录上够准，这种地方就值得试。分类也得先约定清楚：Uber Eats 买的一顿外卖，我会归“餐饮”；买菜则可能单列。模型再便宜，也不会自动知道我的记账习惯。

还有派单。我在做的 Bonsai 需要把不同请求交给合适的模型；给 coding agent 派活用的 Multica，需要判断一个 issue 该交给谁。它们都可以拿来做对比实验。不过，“哪个模型适合这个请求”比挑出一个模型名难得多，后面的任务有没有做成，才是路由对不对的依据。

我看到 Jev 的第一反应，其实是让它当海龟汤主持人。玩家一轮轮提问，主持人根据汤底回答“是”“不是”或者“无关”。答案范围刚好很小。

然后我搜了一下，发现已经有人做了。比如 Soupbase，就把 Jev 接进了海龟汤的提问判定。得益于 Jev 的能力，还支持用户提交自己的题目。大家可以点进去玩玩看。

自己试一下

下面的接入信息核对于 2026 年 9 月 23 日。价格、注册条件和接口仍可能调整。

• TypeSafe 官方控制台：直接接入的入口，注册资格和赠送额度以当时页面及账号显示为准。
• Vercel AI Gateway：模型 ID 为 typesafe-ai/jev。当前页面标注输入、输出免费，促销于 2026 年 9 月 25 日结束。
• OpenRouter 教程：模型 ID 为 typesafe/jev-1.13，使用专门的 Decisions API。

下面是一条 Vercel 请求示例；接口形状可对照其 HTTP API 说明。运行前需要设置自己的 AI_GATEWAY_API_KEY，大家可以看一下 Response，马上就能理解 Jev 是什么了。

curl https://ai-gateway.vercel.sh/v1/evaluate \
  -H "Authorization: Bearer $AI_GATEWAY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "typesafe-ai/jev",
    "state": "Uber Eats ¥2,380",
    "questions": {
      "category": {
        "type": "choice",
        "instructions": "Which category does this transaction belong to?",
        "criteria": {
          "Food": "meals, groceries, restaurants, food delivery",
          "Transport": "trains, taxis, ride-hailing, fuel, parking",
          "Shopping": "clothes, electronics, household goods, online retail",
          "Entertainment": "movies, games, concerts, streaming subscriptions",
          "Other": "expenses that do not fit any of the categories above"
        }
      }
    }
  }'

延伸阅读

• Diogo Almeida, Introducing System One Models and Jev（TypeSafe, 2026-09-14）——发布文。三种问法、价格、评测方法，以及他们给每个结论标注的 nuance；名字的来历在文末 FAQ。
• TypeSafe, Jev 1.13 jaggedness（2026-09-17 修订）——官方列出的九种短板：计算、日期、无关上下文、对抗文本……比发布文更值得读。
• Andrej Karpathy, Software 2.0（Medium, 2017）——2.0 的原始定义。
• W. S. Jevons, The Coal Question（1865）——Jevons 悖论的出处，也是 Jev 名字的来历。
• Daniel Kahneman，《思考，快与慢》（中信出版社，2012；原著 Thinking, Fast and Slow, 2011）——System 1 / System 2，System One Model 这个名字的来历。
• What If We Put AI in the State Machine?（2026-09-20）
• B 站视频：400 道题实测 Jev——简单单选 100%，长文本抓关键事实 32.5%，以及对架构的推测。
• Intelligent Artifact, Introducing System One Models and Jev（2026-09-16）——Hacker News 四百多条评论的整理：它到底新在哪。
• 编程范式的背景（Software 1.0 / 2.0 / 3.0）见自然语言就是新的程序设计语言；Jevons 悖论与“按任务而不是按技术分”见《AI 不是节约型创新》。

上一篇讲了编程的三个时代：人工编写、机器学习、自然语言。既然自然语言成了新的编程语言，人人都成了施法者，大家肯定迫不及待想练一把咒语。然而 AI 时代有个笑话：“只要你学得够慢，你就不用学了。”还有一个类似的流行语：“一觉醒来，错过好多；一年过去，什么也没错过。”

从“学了再说”到“用到再学”

这些话其实在方向上对了一半。变化快、用到时又容易查的细节，可以晚点学。

编程语言里有一种概念叫惰性求值：表达式先不算，等到真有人要用它的值再算。Haskell 靠这个能表示一个无穷长的列表，只取用其中需要的部分。机器学习里也有一个概念叫惰性学习：基本的 k 近邻算法把样本存着，不预先拟合一个参数化的预测模型，等查询来了再比对。在 AI 时代，值得学的东西太多，学东西又变得很快，我们理应也这样学，尤其是下面几类知识：

1. 近期未必用得上，真用到时又容易查、容易学；
2. 当前任务只需要弄清输入输出，可以暂时当黑箱；
3. 更新很快，提前熟记的细节可能到时候又得重学。

随着技术的进步，查和学的成本变了。2011年 Science 上的研究发现，预期以后还能访问某条信息时，受试者对信息本身的回忆较差，对存放位置的记忆反而更好。我们会把记忆的一部分交给外部系统。AI 又往前走了一步：除了帮你找，还能按你的问题解释、举例、陪你试。

很多人对这类知识有收集癖。我怀疑这里有一点应试教育留下的惯性：太多人都只关注一个东西对闭卷考试有没有用，但现实是一场开卷考试。过去我们经常是 “just in case learning”——学了再说；现在则应该是 “just in time learning”——用时再学。就像某些 JIT 编译器的做法，哪段代码跑热了，再集中优化哪段。等发现学了以后可以提升自己的工作效率，再学也不迟。

原理性知识更保值

也有知识值得早点学，因为它会反复帮你判断新问题。你不需要会推导 Transformer，但有几个心智模型，建了就一直管用。

模型看到的字跟你看到的不一样。 它先把文字切成一块一块的 token——有时是一个词，有时是半个词。strawberry 在你眼里是十个字母¹，在模型眼里可能是两三个 token。这就是为什么早期模型数不清里面有几个 r：它的颗粒度跟你不一样。不过这不是天花板——切法本身没有丢信息，新模型完全可以学会更好地处理这类问题。别把某一代模型的短板，当成所有模型永远跨不过去的坎。

流畅不等于正确。 语言模型的基本训练目标是“给定前文，预测下一个最合理的 token”。靠这个目标，它能学到大量知识和推理模式，但训练过程没有附送一个事实核验器。所以它说得越顺，你越该多问一句：这个说法我能验证吗？

“我明明说过了”——但它可能已经看不见了。 每个模型有一个上下文窗口，一次能看多少内容是有上限的。聊到后面，最早的几轮对话可能已经滑出窗口。你觉得对话记录还在，但对模型来说那段话已经不在视野里了。另外，聊天时模型的权重不会即时更新——它能从你这轮给的例子里学到一条规则，但关掉对话就忘了，除非产品另有记忆功能帮你存。模型的知识截止日期约束的是训练时学到的东西，不妨碍它读你刚贴进去的材料。

2017年那篇 Attention Is All You Need 到现在，模型变化巨大，但 token、上下文窗口、训练和推理的区别这几个概念仍然有解释力。判断一条知识值不值得长期学，我会看它能不能解释多个现象，能不能在换了工具之后继续帮我作判断。原理也会被修正；一个好的 mental model，还应该让你知道自己的判断在哪些地方靠不住。

系统提示词与用户提示词

先说 ChatGPT、Claude 这类 chatbot。你在对话框里输入“帮我列个提纲”“这段再短一点”，就是用户提示词（user prompt）。产品还会在背后提供系统提示词（system prompt），交代助手的基本身份、行为规则等。打个比方，把模型当作临时工：系统提示词像公司规矩，用户提示词是你交给他的具体事情。如果你对更完整的提示词写作指南感兴趣，可以参考社区维护的已经泄漏的系统提示词。题外话，我觉得用户应该对这些影响信任的信息享有知情权，就像主流通用编译器几乎都是全面开源的。

日常聊天，直接在对话框里说需求就行。同一段对话里，之前的消息通常也会作为上下文参与后续回答，不必每轮从头交代。如果有经常重复的偏好，例如“用中文回答，技术术语保留英文”，可以存进 ChatGPT 的自定义指令。只适用于某一组对话的背景和要求，则可以放进 Claude 的项目知识和项目指令。

这些是产品提供的个性化入口，并不等于直接编辑厂商的系统提示词。对使用者来说，先把眼前的事情说清楚就够了；哪句话反复要说，再把它存起来，省得每次重复。系统提示词优先级总是高于用户提示词。

agent 里的提示词分布则更加复杂，之后介绍的时候再说。

角色提示词已经只是 cosplay 了

理解了这层分工，再看那些流行的提示词技巧，就容易判断哪些工作还需要我们来做。

斯坦福 2025年秋季的 CS146S: The Modern Software Developer 的课件上写着 Use role prompting aggressively to make system prompts more powerful。所谓角色提示词，就是开头先来一句“你是一位顶级前端专家”。很多人把它当作固定起手式，好像少了这句，模型就不知道怎么写前端了。

在 Fable 5.1 / GPT-6 Astra 这一代经过充分后训练的助手模型上，我的默认做法是直接交代任务，省掉这句起手式。认真理解问题、运用相关知识、尽量给出有帮助的回答，本来就是厂商在训练的行为。把模型塑造成一个好助手的工作，已经有很大一部分在它交到用户手里之前完成了。

厂商通过指令微调和 RLHF等后训练方法，用回答示范和偏好反馈来调整模型，让它更好地遵循请求、帮助用户。“当一个有帮助的助手”已经成为模型学到的默认行为，不需要用户在每次对话里从头教起。Anthropic 的 persona selection model也提供了这样的理解：后训练塑造和完善了 Assistant 这个角色。

不额外指定人设时，你面对的也已经是一个被专门塑造过的助手。“帮我写一个 React 网页”这份任务本身，也已经提供了前端开发的情境。一句“你是顶级前端专家”能带来多少额外价值，要看它在这个基础上又补充了什么，而不能只看它是否让输出发生了变化。

这就是我省掉通用人设的理由：它想提醒模型做的事，很可能已经包含在默认助手的行为和任务要求里。这里的“调好了”，指以帮助用户为目标、面向广泛任务优化过的默认行为；具体任务做得好不好，仍然要看结果。因此，我会先直接说任务，发现不足再补充要求，而不是把“你是专家”当作必需品。

要是我希望它“像面试官一样一次只问一个问题”，或者“从无障碍审查者的角度检查这个网页”，情况就不同了：我在指定这次合作的方式或检查范围。这些信息未必能从“帮我做个网页”里推出来。角色仍然可以是这种要求的简写；真正有用的是它补充的任务信息。

已有实验也提醒我们，不必迷信头衔。Zheng 等人的研究于 2023年首次公开、2024年定稿：研究者把 162个人设放进系统提示词，在四个模型家族的九个模型、2,410道 MMLU 选择题上做对照，没有发现添加人设能稳定提高总体准确率。这项研究没有测试 Fable 5.1 这一代模型，不能代替对它们的评估；它检验的是“加个人设就能变强”这个常见假设。

CS146S 课件上的例子，我用 Fable 5.1 照着试了一遍：同一道题（最长回文子串），交给两个人设。

Gen Z digital bestie —— 对话记录

A helpful assistant that loves programming at the level of a senior software developer —— 对话记录

这一次，两边都把程序写对了，也都顺手提醒我有更高效的 Manacher 算法；最明显的差别在语气词。

这一次看起来很像 cosplay，或者说 VTuber，皮套换了，人没换。

滥用角色扮演本质上只是一种偷懒。你没有把任务的具体需求想清楚，指望靠一个通用角色来代替。这和高考作文开头引一句名人名言一样，光有一个气势，却没有什么独特的信息量。

至于一句人设为什么会改变模型的行为，等到深入讲 LLM 原理时，我会另写一篇《为什么人设会改变行为》，把条件概率、attention 和角色表示拆开来讲。

有一种失效叫招安

2022年有篇论文发现，加上 “Let’s think step by step” 这样的提示，能把当时模型在 MultiArith 上的正确率从 17.7% 提高到 78.7%。如果一句话这么好用，这么泛用，那它就应该出现在系统提示词里。果然后来出现了会在内部进行推理的模型，OpenAI 的建议反而是不必再加这句话。曾经需要人手动提醒的动作，变成了模型的默认行为。

Zero-shot 和 few-shot 能更清楚地说明这个区别。直接让模型把“今天天气很好”翻成英文，不先提供翻译示范，就叫 zero-shot（零样本提示）；先给几组中英对照，再让它翻译新句子，就叫 few-shot（少样本提示）。这里的“样本”指提示中的任务示范，不是模型训练时看过的资料。GPT-3 的论文标题就叫 Language Models are Few-Shot Learners。

随着模型更擅长直接理解指令，一些任务可以先不贴例子，看看它能不能做好；但 few-shot 远没有因此过期。某种特定的语气、某种嵌套三层的 JSON 结构、某个边界情况到底该输出空数组还是报错——这些地方，贴一条样例可能比写一千字的说明更省事。Show, don’t tell，写作里很老的技巧。

这些提示词技巧仍然有效。恰恰因为足够通用，它们才会随着技术进步，被吸收到模型内部、系统提示词或官方 harness 里。所谓“失效”，是用户不必再手动提醒。

模型厂的工作和我们的工作

Naval 2026年2月在播客A Motorcycle for the Mind里说得更直白：他不热衷学那些“这样 prompt、那样搭 harness”的技巧，因为他相信技术适应他的速度，比他适应技术更快；在他看来，那些 workflow 和工具的寿命“以周计，顶多以月计，不以年计”。不过，他也留了一个例外：如果你眼下就在做前沿产品、需要每一点竞争优势，那就值得学。到 5月他讲了写代码的版本：不追 Ralph Wiggum、OpenClaw、plan mode 那些建议，把 Codex、Claude、Gemini 扔到同一个问题上反复跑，“浪费 token，节省时间”。

沿着 Naval 的思路，我愿意把用 AI 时花的功夫分成两类：their job 和 our job。Their job 是模型和工具开发者正在改进的事——让模型更会推理、更可靠地使用工具、更能适应人的说话方式。如果一个技巧只是替模型补短板，它的价值就可能随着模型升级而下降。当然，今天能帮你把活干好，今天学就有意义。Our job 是另一类。Naval 说他不学那些技巧，但紧接着那句是：

I just can speak English. And for someone like me who is relatively articulate with English and also has a structured mind, and I know how computer architectures work, and I know how computer programs work, and I know how programmers think, then I can actually very precisely specify what I want just through structured English.

这本身就是最强的提示词技巧：清楚的自然语言、结构化的头脑、知道机器怎么工作、知道程序员怎么想，然后把要什么精确地说出来。Naval 不是没有技巧，而是他的技巧在 AI 出现之前就练好了。他之前的表达、编程和判断的积累，不仅没有贬值，在 AI 时代还变得更有价值了。

真正属于自己的提示词技巧是写作

弥补模型短板的技巧，会随着模型换代而变得不再必要；把任务本身的信息表达清楚的能力，则永远不会过时。

把模型当成中介公司派来的临时工。这人极其聪明，读过很多书，会写很多语言。但他今天早上才到你公司，不知道你们做什么产品、给谁用、组里有哪些不成文的规矩、上次事故是怎么出的。对于他已经熟练的事，你不必从 for 循环教起；要花心思的是把这个项目特有的背景交给他。

提示词不必一开始就写得面面俱到。好的提示词技巧不止要 LLM-friendly，更要 human-friendly。如果每次开工都要先写一份完整规格，任务还没动，人可能就退缩了。评价一种提示词方法，也该把人的启动成本算进去。

《微习惯》主张把每天要求自己做的行动缩得很小；福格行为模型也强调，可以通过降低行为的难度，让行动更容易发生。借用这个思路，和 AI 合作的第一步也可以很小：先把想做的事说出来，没想清楚就让它帮着问、帮着试。

有了第一版，再看结果、补要求。写作有改稿，和 AI 合作也一样。我们关心的，应该包括人能不能轻松开始、把事情逐步做完，而不只是第一条提示词能让模型答得多好。

真要学提示词，我会先看模型厂商的官方指南：说清任务、交代背景、必要时给个例子。这些基本功更值得长期积累。官方的具体建议也会变，用到时再查最新版、看实际效果就好。AI 的通用性还意味着，你可以用 AI 来学习 AI。不知道怎么提问，就让它帮你理清问题；拿不准某件事值不值得投入时间和精力去学，也可以问 AI。你不必先把“如何使用 AI”学完，才开始使用 AI。

Let them do their job, and we do ours.

延伸阅读

• Vaswani et al., Attention Is All You Need（2017）——attention、前馈网络与 Transformer 的计算结构。
• Ouyang et al., Training language models to follow instructions with human feedback（2022）——指令微调和 RLHF 如何改变模型的默认行为。
• Marks, Lindsey & Olah, The Persona Selection Model: Why AI Assistants might Behave like Humans（2026）——预训练角色与后训练助手之间的解释框架，以及该框架的边界。
• Zheng et al., When “A Helpful Assistant” Is Not Really Helpful（Findings of EMNLP 2024，预印本始于 2023年）——系统提示词中人设效果的对照研究，结论有明确的模型和任务范围。
• Anthropic, AI prompt engineering: A deep dive（2024-09-05，Alex Albert、Amanda Askell、David Hershey、Zack Witten）——提示词实践、角色和推理的圆桌讨论。
• Anthropic, Prompting best practices——角色、示例、背景和输出约束的官方建议，随模型更新。
• Kojima et al., Large Language Models are Zero-Shot Reasoners（NeurIPS 2022）——“Let’s think step by step” 的原始论文。
• Naval & Nivi, A Motorcycle for the Mind（Naval Podcast, 2026-02）——关于学习 AI 工具的取舍，以及结构化表达和底层知识的价值。
• Naval, Guillermo Rauch, Blake Scholl & Max Hodak, Waste Tokens, Save Time（Naval Podcast, 2026-05）——写代码版：不学 Ralph Wiggum / OpenClaw / plan mode，多模型暴力跑。
• Mihail Eric, CS146S: The Modern Software Developer（Stanford, 2025）——本文讨论的课程和提示词课件来源。
• 编程范式的背景知识（Software 1.0 / 2.0 / 3.0）见自然语言就是新的程序设计语言。

还记得 2022 年秋天，我教一位朋友写 Python。她这个人比较随性，不按 Python 的语法规则来，觉得意思大概其就行。我被她气得够呛，跟她说：编译器看不懂你这些自由表达，它是把代码一层层拆开的，拆到底每一块都得是表达式。人看上去差不多，机器看上去可不是，少个符号整个语法树的结构都变了。

后面的事情大家都知道的，那个冬天 ChatGPT 就出来了……这下机器真的能读懂我们说的话了。

所以说，人不可骄傲自大。你觉得你说的就是板上钉钉的真理，但是真理也会变。我因为知道 Python 解释器背后的原理，觉得用自然语言编程这件事不现实，却忽视了这个需求是真实存在的。就像一开始 ChatGPT 刚 public release 的时候，我朋友圈里最看空的人都是那些做 NLP 的，觉得这个“力大砖飞”、毫无美感。恰恰是那些在此之前就知道 Transformer 架构的人因为懂得太多没有体会到神奇之处。

而今天，不会有人怀疑自然语言就是新的编程语言。而早在 SICP 里，就提出了写作和编程的统一性。程序首先是写给人读的，只是顺便让机器执行。Paul Graham 在《黑客与画家》里说得更直接：黑客和画家一样，都是创作者，好代码跟好散文的标准是一回事——清晰、简洁、有节奏。我的大学语文的结课作文也写了这个观点。

编程范式的演进

Karpathy 2017 年写了一篇《Software 2.0》，把软件分成两代。2025 年他在 YC 的演讲里补上了第三代。三代的区别不在用什么语言写，在程序是怎么来的。

1.0：人工编写

人先把规则想明白，一行行敲成 if-else。编译器、操作系统、数据库、Excel、TCP/IP，你今天用的大部分软件都是这么来的。出了 bug 能一行行追到写错的地方。

编译器是 1.0 的极致：一段文本必须严丝合缝地拆成语法树，多一个空格都不行。好处是确定性，同样的输入永远同样的输出。代价是只有专业人士能写，而那个年代软件工程师全球都不够用。

我 2022 年秋天对朋友说的那番话，就是 1.0 的世界观：机器只认规则，人得迁就机器。

2.0：机器学习

有些规则人写不出来。猫和狗到底差在哪？垃圾邮件长什么样？写不出规则，那就别写了，换个思路：给一个目标函数、一份数据、一个网络骨架，让梯度下降在权重空间里替你找那个程序。找出来的是一堆浮点数，没人能解释为什么管用。黑箱。

为什么非得是神经网络？因为权重空间得连续可微，梯度才走得动，决策树没这个性质。Karpathy 原文说得很直接：Software 2.0 是用神经网络的权重写成的。人脸识别、语音识别、机器翻译、抖音和 YouTube 的推荐系统、AlphaGo，都是 2.0。Google 搜索的倒排索引是 1.0，2015 年之后排序里塞进去的 RankBrain 是 2.0。

“规则不必由人写”这件事其实更早就赢过一次。吴军在《数学之美》里讲，50 年代起做 NLP 的主流是规则学派，照乔姆斯基的路子让语言学家一条条写语法。70 年代 IBM 的贾里尼克用统计方法做语音识别，错误率直接压下去一大截，留下一句话：“我每开除一个语言学家，识别率就提高一点。”两派吵了十几年，到 90 年代统计学派全面胜出。那已经是一次不靠人写规则的胜利，只是当时搜程序用的还是概率模型，不是神经网络。

2.0 还有个特点：一个模型只干一件事。识别人脸的网络不会下棋，下棋的不会翻译，换个问题就得重新收数据重新训练。这就是 ANI，narrow AI，专用智能。不光要招软件工程师，还得招 MLE，还得有大数据基建。个人想从头训一个模型，已经不太现实。

3.0：自然语言

2.0 搜出来的程序里有一种很特殊：它在整个互联网的文字上训练过，语法、库、Stack Overflow 上所有的争吵都压进了那几万亿个参数里，输入天然就是语言。你不用再训练它，直接跟它说话，你的话进入上下文窗口，它的行为就变了，权重一个都没动。

这是跟 2.0 的根本区别：只训练一次，之后换问题不用重新训练，换一段 prompt 就行。ChatGPT、Claude Code 都是这一代。Google 搜索也在换，AI Overviews 已经摆在了倒排索引上面。同一个模型上一秒写 SQL，下一秒改简历，再下一秒解释量子纠缠。这算不算 AGI 有争议，“一次训练，到处能用”这件事没争议。

只需要有人会写 prompt。而写 prompt 说到底就是把话说清楚。这个人可以是你自己。

为什么偏偏是语言做到了？因为语言天生就能操作世界。咒语、法令、合同，都是说出来就改变现实的东西，奥斯汀 1955 年在哈佛那门课干脆就叫《如何以言行事》。代码只是其中最严格的一种，严格到非得专业人士来念。Naval 说程序员从前像巫师，得背下晦涩的咒文才能施法；AI 等于给每个人发了一根魔杖。所有问题都能用语言描述，所以一个学会了语言的程序就拿到了所有问题的入口。

Karpathy 说 prompt 就是程序。我觉得这不是修辞：一段文本改变一台机器的行为，这就是程序的定义。

开头那张图示意得不太好：软件 2.0 和 3.0 并不是只吃掉之前 1.0 的领土。它们最主要的是带来了更多新的软件，尤其是 3.0，它会创造多得多的新软件。有很多原来在成本上没有办法用软件去满足的需求，现在也可以去满足了。

对照表

门槛没消失，换了个地方卡你。1.0 卡算法和语法，2.0 卡数据和数学，3.0 卡你能不能把意图说清楚。

那意图和表达怎么练？同样叫“提示词技巧”，哪些会过期，哪些不会？请见下一篇。

延伸阅读

• Andrej Karpathy, Software 2.0（Medium, 2017）——1.0 / 2.0 的原始划分。
• Andrej Karpathy, Software Is Changing (Again)（YC AI Startup School, 2025）——3.0 的提出；prompt 就是程序。
• Paul Graham，《黑客与画家》（人民邮电出版社，2011；原著 Hackers & Painters, 2004）——编程是创作，好代码的标准和好散文一样。
• Naval & Nivi, A Motorcycle for the Mind（Naval Podcast, 2026-02）——“人人都是施法者”的出处。
• 吴军，《数学之美》（人民邮电出版社，2012；初稿为 2006 年 Google 黑板报系列）——第 2 章“自然语言处理：从规则到统计”，规则学派 vs 统计学派的十几年之争。