先把判断说清楚

如果你最近已经开始一边让 AI 帮你写点脚本、补点测试、改点前端，一边又总觉得心里不太踏实，这篇文章就是写给这种状态的。

原因很简单。现在最让普通开发者困惑的，早就不是“要不要用 AI”，而是另外几件更具体的事：到底该学什么，哪些东西可以放心交给 agent，哪些地方必须自己盯着，以及自己会不会慢慢被训练成只会点按钮的人。

Andrej Karpathy、Simon Willison、Jeremy Howard 与 swyx 值得放在一起，正是因为他们刚好分别守住了这几件事。把他们放在一篇里看，比单独记住几个名字更有用。对开发者真正重要的，也不是他们有多有名，而是他们各自到底帮我们看清了什么。

为什么是这四个人

过去一年，AI 圈最容易刷屏的是模型升级、融资速度和大公司发布会。那些当然重要，但如果你是每天真要写代码、改系统、背线上责任的人，真正影响你工作的变化往往不在发布会舞台上，而在更细的地方。

  • 谁在重新定义“学 AI”到底学什么。
  • 谁在把模型体验翻译成可复用的工程常识。
  • 谁在提醒大家不要把 agent 系统做成不可审计的黑箱。
  • 谁在把零散 demo、工具与创业方向，组织成一个更长期的生态叙事。

Karpathy、Willison、Howard 与 swyx，刚好分别踩住了这四个问题的交叉点。

Karpathy 的贡献，是把 AI 从研究名词重新翻译回软件问题与学习问题。Simon Willison 的贡献，是把前沿模型世界里最容易飘起来的话题，重新压回软件工程与开放网络。Jeremy Howard 的贡献，是一直坚持把 AI 能力向普通人和小团队开放，同时提醒大家保留自己的判断。swyx 的贡献，则是把“AI 工程师”从一个松散标签，推成了更像产业角色与创业方向的东西。

这四条线放在一起，恰好能解释一件事：为什么到 2026 年春天，优秀开发者越来越不像只会调 API 的人，而更像能同时处理学习、验证、协作、工具链与组织问题的人。

第一种原型：Karpathy 把 AI 重新翻译成学习问题和软件问题

很多普通开发者第一次真正“听懂”大模型，不是从论文开始的，而是从 Karpathy 这类人开始的。你会发现他总能把那些原本只属于研究圈的话，改写成工程师能跟得上的语言。

很多人提到 Andrej Karpathy，先想到的会是深度学习早期课程、在 OpenAI 和 Tesla 的经历，或者他长期扮演的“最会讲清楚复杂技术的人”这个角色。但这还不够。Karpathy 真正重要的地方，在于他几乎每隔一个阶段，都会把前沿技术重新翻译成普通开发者能吸收的语言。

早年他把卷积神经网络、表征学习和生成式模型讲成了工程师能跟上的课程。后来他又把大模型、token、上下文窗口、预训练与微调，讲成了新一代开发者共同的入门语法。到了今天，他的影响力已经不只来自“讲清楚”，而来自他总能把技术热潮重新翻译成更底层的问题：软件到底会怎样变化，人到底该怎样与这种系统协作。

这条线在过去半年变得更鲜明。2025 年 11 月 12 日，他写了《Verifiability》。这篇文章最值得注意的，是它把今天 agent 工程里最难的一件事说得特别直：能不能验证。如果结果无法快速判定对错，那么自动化链路就会变脆，系统也会更难稳步迭代。很多人现在做 agent，还停在“它终于自己跑起来了”的兴奋里；Karpathy 盯的已经是下一步：你到底能不能判断它做对了。

这个判断一旦放回普通开发者的日常，立刻就有感觉了。比如你让 AI 帮你给一个老接口补单测，如果结果是测试通过、覆盖率上升、接口行为没变，这件事通常比较容易验。可如果你让它“顺手把这个模块重构得更优雅一点”，事情马上就模糊了。代码也许变了，文件也许更短了，但到底有没有把原来的边界条件弄丢，往往得靠你自己重新读一遍、跑一遍、甚至补一轮回归。Karpathy 的价值，就在于他把这种大家都隐约知道、但没说透的难点，提到了桌面上。

几周之后，在 2025 年 11 月 30 日的《The Space of Minds》里，他又把讨论从单一模型能力，推向更大的“心智空间”。这个视角很重要，因为它提醒我们：模型不只是一个更会答题的机器，而是不同心智风格、不同工作方式、不同推理习惯的组合。对普通用户来说，这听起来像哲学；对 AI Agent Engineer 来说，它其实是在说一件非常现实的事：未来的系统设计，不会只是“选最强模型”，而会更像为不同任务挑选不同心智风格的 worker。

你把它想成团队协作就很容易懂了。真实开发里，本来就不是所有任务都交给同一种人做。有人适合先把文档啃明白，有人适合快速扫日志定位问题，有人适合小心翼翼地改数据库迁移。模型也会越来越像这样。以后你手上的 agent 系统，很可能也不是一个万能 worker，而是一组分工不同的 worker。有人负责查资料，有人负责生成草稿，有人负责最后一轮严格校验。这个思路一旦建立起来，你对“怎么选模型”这件事就不会只剩排行榜思维。

Karpathy 最近几年的另一条线，是把 AI 教育本身做成产品。Eureka Labs 的方向并不只是再做一个课程平台，而是试图把老师、课程、模型与交互重新组织成一种更适合 AI 时代的学习体验。这里最值得重视的，也不是它现在规模有多大，而是 Karpathy 一直没有放弃那个最基础的问题：技术浪潮来了之后，普通人如何真正学会，而不只是围观。

如果用一句话概括 Karpathy 这条线，我会说：他最强的地方，不只是判断前沿会往哪走，而是总能把前沿重新翻译成“今天的开发者该怎样学、怎样做、怎样验”的问题。

第二种原型：Simon Willison 把 agent 讨论重新拉回软件工程

如果你团队里有那种人，总能在大家一股脑冲新工具时提醒一句“先看看日志、许可证和维护成本”，那种人往往平时不最显眼，但出事时最值得信。Simon Willison 很像这种角色。

Simon Willison 的价值，长期都很容易被低估。因为他既不像明星创业者，也不像前沿实验室负责人，更多时候像一个不停写、不停试、不停记录的人。但正是这种持续记录，慢慢让他成了今天开发者世界里最可靠的 AI 观察者之一。

他的长期贡献，不只是写 blog 勤奋，而是建立了一种非常稀缺的公共技术写作方法：亲自试，公开记，尽量给出可复现的例子，同时把短期热闹和长期规律分开。你如果长期读他的东西，会发现他几乎总在做同一件事：把“这波 AI 看上去很强”翻译成“对真实软件系统到底意味着什么”。

过去半年里，这条线进一步收束成了更完整的 agent 工程方法论。2026 年 2 月到 3 月，他连续整理了一套 Agentic Engineering Patterns。里面最有价值的，未必是某个花哨技巧，而是他反复强调的工程纪律：少做脆弱的自动化，尽量产出更好的代码，优先把那些你自己已经知道怎样做的任务交给 agent。这个判断看上去保守，实际上很稳。因为它正面承认了 agent 当前的边界，同时给了团队一套能逐步扩大的实践顺序。

这里最容易代入的场景，是你第一次把 AI 真正放进团队工作流的时候。比如你已经很熟悉项目里的测试框架，那先让 agent 帮你补测试、整理失败用例、生成 review 备注，通常是稳的。可如果一上来就让它全权接手一个陌生服务的重构、顺便改掉权限逻辑和部署脚本，那很容易从“节省时间”变成“最后大家一起擦屁股”。Simon Willison 的方法厉害就厉害在，他不是在泼冷水，而是在帮你安排一个更像工程实践的上手顺序。

Simon 最近的另一个高价值动作，是把看似边缘、实则会在组织里爆炸的问题提早说清楚。2026 年 3 月 5 日，他写了关于编码 agent 与开源许可证的文章，用一个具体案例提醒大家：当 agent 参与代码生成和移植时，法律与版权问题不会自动消失，团队不能只沉浸在“它已经写出来了”的兴奋里。到了 2026 年 3 月 9 日，他又写到“也许无聊技术并不无聊”，继续强调那些看起来朴素的基础设施、老派工程习惯和稳健选型，反而在 agent 时代更重要。

这件事对普通开发者也不是遥远话题。你今天让 AI 参考某个老库改一段解析逻辑，或者让它把一个 Python 工具“顺手移植”成 TypeScript，看起来只是省了几个小时，但背后到底参考了什么、继承了什么、有没有引进不该碰的东西，其实都可能在以后变成真实问题。很多团队现在还没吃过这个亏，所以容易觉得这类提醒过于谨慎；可一旦代码真的进仓库、进产品、进客户环境，这些“边角料”就会变成本体。

Simon Willison 最值得普通开发者学习的，也正是这一点。他不是在教大家如何追每一波热点，而是在示范一种更成熟的姿势：面对新能力，先想复现性，再想维护性，再想法律和组织后果，最后才是演示效果。

如果 Karpathy 的贡献更像“把未来讲清楚”，那么 Simon 的贡献更像“把未来落回工程地面”。这件事在 2026 年已经非常值钱，因为行业里最稀缺的从来不是新口号，而是能让团队少走弯路的公共方法。

第三种原型：Jeremy Howard 把 AI 使用权重新交还给普通人

Jeremy Howard 这条线，看上去和 Karpathy 有点像，因为他们都很会教，也都长期在帮更多人进入 AI 世界。但两个人真正的重心并不一样。Karpathy 更像在解释范式变化本身，Jeremy Howard 更像在不断追问：这些能力到底怎样才能真正被普通人、小团队和非顶级实验室拿到手里。

这件事对普通开发者特别有亲近感。因为很多人现实里的状态并不是“我要训练下一个前沿模型”，而是“我手上只有一点时间、有限预算和一个真问题，AI 到底能不能帮我把活干得更好一点”。

也正因为这样，fast.ai 和后来 Answer.AI 的意义一直不只是“做了课程”那么简单。Jeremy Howard 长期做的一件事，是把原本属于少数研究实验室的能力，尽量压成普通开发者可以理解、可以操作、可以复用的方法。他不是单纯做知识普及，而是在持续降低进入门槛。

过去半年里，这条线最值得注意的动作之一，是 2025 年 10 月 1 日推出的 Solveit。Solveit 不是那种靠夸张口号吸引人的产品，它更像一套学习与问题求解方法的重建。它强调的不是“让 AI 代替你思考”，而是怎样在 AI 时代保留主动拆解问题、自己推导、自己判断的能力。这个方向很重要，因为过去一年越来越多人学 AI 的方式，已经开始滑向另一个极端：工具会用，但脑子用得越来越少。

这类问题你在日常开发里其实很常见。比如你把报错一贴给 AI，它立刻回你一段看起来很完整的修复方案；你再追问两轮，它甚至能顺手把补丁也写出来。问题是，如果你从头到尾没搞明白根因到底是依赖版本、线程模型、环境变量还是数据本身，那下次同类问题换个壳子再来，你还是会卡住。Jeremy Howard 这条线的重要性，就在于他不断提醒大家，AI 可以帮你提速，但不能替你长出判断力。

Jeremy Howard 最近半年另一件更有工程含金量的事，出现在 2026 年 1 月 20 日关于《The Unauthorized Tool Invocation Problem》的文章里。这个问题的表面是工具调用安全，底层其实是 agent 系统设计纪律。文章指出，如果模型可以通过特定方式诱导系统调用未授权工具，那么你以为自己做的是“会用工具的智能体”，实际做出来的可能是“边界不清、权限脆弱的自动化系统”。这里最值得记住的，不只是漏洞本身，而是他们反复强调的处理思路：尽量使用薄而可审计的封装，让系统边界清楚，让人类能看懂发生了什么。

你把这个问题放进企业里的常见场景，会更有压迫感。比如一个内部 agent 本来只该读工单系统和知识库，结果因为工具封装过宽、权限边界没收好，它顺手又能碰到用户目录、计费接口甚至生产配置。平时演示时大家只会看到“哇，它真能自己查好多东西”，出事时才发现真正的问题根本不是模型聪不聪明，而是系统一开始就没有把手伸多远这件事设计清楚。

Jeremy Howard 的价值，恰好就在这里。他总能把 AI 讨论拉回“人是否还保有主动权”这个问题。不管是教学、开源工具、Solveit 这种学习产品，还是对工具调用边界的讨论，他真正坚持的都是同一件事：AI 不该把人训成依赖按钮的操作者，而应该放大人的判断、行动和持续学习能力。

对普通开发者来说，这条线特别重要。因为它提醒我们，AI 的门槛下降，并不自动等于真正获得能力。只有当你还保留问题拆解、验证结果、审计过程的习惯时，那些更强的模型和 agent 才会真的变成你的能力，而不是你的幻觉。

第四种原型：swyx 把 AI 工程师推成一种产业角色

如果前面三个人更像在帮你把手上的活想清楚，那么 swyx 更像在帮你看清整个牌桌。你未必会天天点开他的每篇内容，但只要你关心 AI 工程师这个角色会怎么变化，迟早会碰到他搭出来的那套语境。

swyx 可能是这四个人里最不像传统“技术权威”的一个，但他恰恰代表了另一种今天非常关键的影响力：他未必直接发明模型，也不一定亲自做底层框架，却一直在持续定义产业语言、汇聚开发者网络，并把零散变化组织成一个可行动的生态叙事。

如果回看他过去几年的轨迹，会发现他几乎一直在做一件事：把新工具、新模式和新创业机会，翻译成开发者和创始人都能迅速理解的框架。从 “AI Engineer” 这个身份标签，到大量访谈、峰会、newsletter 与生态观察，他做的其实是行业组织工作。很多人只看见“传播”，但真正厉害的地方是，他传播的不是热闹，而是结构。

这条线在最近半年非常明显。2025 年 9 月 23 日，他在 AI Engineer World's Fair 2025 的 keynote 里，直接把过去一年的变化压成了一次面向开发者的总复盘。更重要的是，2025 年 11 月 18 日，Latent Space 发出的《Agent Labs》进一步把方向收紧：下一阶段值得重视的，不再只是一个能跑起来的 agent demo，而是那些既研究 agent、又评估 agent、还真正把 agent 卖给客户的团队。这个判断之所以重要，是因为它把“agent 作为功能点”推进成了“agent 作为组织能力与商业单元”。

这和很多开发者当下看到的现实非常接近。过去一年我们看过太多 demo：几分钟搭一个客服 agent，十分钟做一个研究助手，半小时拼一个自动写代码流程。它们都不算假，但很多东西停在 demo 阶段就结束了。真正难的是，客户愿不愿意天天用，团队能不能稳定维护，评估是不是跟得上，出了错谁来接管。swyx 强调 Agent Labs，本质上是在说，下一阶段拼的不是谁先做出一个会动的东西，而是谁能把它做成一个能交付、能运营、能反复卖的东西。

到了 2026 年 1 月 23 日，《Scaling without slop》又把另一层现实说得更明白：AI 时代并不是团队越大越强，真正危险的常常不是能力不够，而是组织开始长出沟通冗余、流程冗余和判断冗余。对很多创业团队和新一代 AI 工程师来说，这个提醒非常及时。因为 agent 带来的一个幻觉，是“既然模型能做更多，组织就该做得更大”；而 swyx 更像在反过来提醒大家，正确的问题是怎样在更小、更快、更清晰的团队里做出更强系统。

这个提醒放到团队日常里也很好懂。你原本只需要两个人和一个周末就能做完的内部工具，如果因为“AI 时代要专业一点”转眼变成四层评审、三套平台、五个同步会，最后常常不是更强，而是更慢。很多 agent 团队后面最大的敌人，也不是模型落后，而是自己先长出了太多流程和自我感动。swyx 的价值，是一直提醒大家别把组织复杂度误认成能力本身。

swyx 这条线的核心价值，不在某一篇文章，而在于他持续把散乱趋势压缩成行业可执行语言。你可以不同意他的某些判断，但很难否认，他对“AI 工程师”这类身份和创业路径的成形起到了非常实际的推动作用。

把这四条线合起来看，真正变化的是什么

如果只分开看这四个人，你会觉得他们分别在做教育、写 blog、做课程、办峰会或写生态观察。可一旦把四条线叠在一起，变化就变得很具体了。

Karpathy 在强调可验证性和“心智空间”，等于提醒我们别把 AI 简化成一个更强问答机。Simon Willison 在强调工程模式、许可证和无聊技术，等于提醒我们别把 agent 工程做成炫技拼装。Jeremy Howard 在强调学习主动权与可审计工具边界，等于提醒我们别把 AI 普及误解成黑箱依赖。swyx 在强调 Agent Labs 和去除组织臃肿，等于提醒我们别把 agent 创业理解成单点 demo 的堆叠。

这四个人最近半年的共同主题，其实高度一致：下一阶段最重要的，不是再追逐一次“更像魔法”的体验，而是把 AI 真正纳入长期系统。所谓长期系统，指的是它能被学会，能被验证，能被审计，能被协作，能被组织持续维护，也能被商业现实承载。

很多团队现在仍在问“要不要上 agent”。这个问题本身已经有点落后了。更值得问的是：你有没有验证办法，有没有审计办法，有没有逐步扩大使用范围的方法，有没有让团队不被工具反过来牵着走的组织设计。

给普通开发者的启发

如果你不是在做模型研究，也不是在带前沿实验室，这四个人仍然和你高度相关。因为他们的共同作用，是把 AI 时代真正要学的东西，从“会不会写 prompt”重新推回了更扎实的位置。

更现实一点说，如果你最近常见的工作状态是这样几种，那这部分就尤其有用：让 AI 帮你补单测，帮你读陌生代码库，帮你搭个内部脚本，帮你起草 PR，或者帮你先做一轮方案比较。你会明显感觉到它很有用，但又不敢完全信。这种“想用，又怕失控”的状态，正是这四个人都在回应的现实。

  • 第一，学习不能只停在会用工具。Karpathy 和 Jeremy Howard 都在提醒一件事：你必须保留解释问题、拆解问题和验证结果的能力，否则再强的模型也只会让你更快地产生错觉。最典型的例子，就是 AI 能帮你把正则、SQL 或测试样例先写出来，但真正决定你能不能把它接进生产的，还是你自己对上下文的理解。
  • 第二，选工具时不要只看演示视频里那几分钟。Simon Willison 最近半年的工作，几乎都在教开发者把眼光放到维护性、边界条件、许可证和复现性上。真正能长期帮到你的工具，往往不是最花哨的那个，而是那个出了错以后你还知道该怎么查、怎么改、怎么收口的工具。
  • 第三，要开始把“可验证”当成新的基础素养。以后更吃香的开发者，不只是写代码快，而是能设计检查点、对照组、评估脚本和人工复核流程的人。比如你让 AI 帮你批量改文案、补测试、改接口文档时，能不能顺手设计一套验收办法，会直接决定这件事是提效还是埋雷。
  • 第四，要有一点产业感。swyx 这条线提醒大家，技术判断不是孤立发生的。你理解生态怎么组织、角色怎么分工、团队怎么避免臃肿，也会直接影响你在 AI 时代的成长速度。一个很现实的例子是，同样做内部 agent，有的团队在做产品，有的团队其实只是在堆 demo，这两者的路径从一开始就不一样。

说得再直白一点，普通开发者现在最危险的状态，不是学不会 AI，而是太早把自己训练成“只会调用别人的智能”。这四个人共同给出的答案刚好相反：把 AI 用得越深，你越需要保留自己的判断框架。

给 AI Agent Engineer 的启发

如果你已经在做 agent 系统，这篇文章更值得带走的，是一套比“多接几个工具、多串几个节点”更硬的设计标准。

因为很多 agent 项目卡住，往往不是卡在模型不够强，而是卡在更日常的地方：结果没人验，权限没收口，日志看不懂，工作流一长就开始漂，团队里也没人说得清楚哪一步到底该人接管、哪一步可以放心交给机器。

  • 先设计验证，再设计自动化。Karpathy 的可验证性判断，几乎应该成为 agent 系统的第一原则。能不能自动验，决定了你能不能自动扩。比如自动生成测试、结构化抽取、表单填充这类任务通常更适合先自动化；而“把这个模块改得更优雅”这种目标，就要谨慎得多。
  • 先设计边界，再设计能力。Jeremy Howard 关于未授权工具调用的讨论提醒我们，权限模型、工具白名单、审计日志和人类接管机制，不是上线后再补的安全层，而是产品本体。一个只能读工单的 agent 和一个能写配置、发消息、调支付的 agent，根本不是同一种系统。
  • 先设计维护性，再设计 demo。Simon Willison 的方法很适合拿来当团队规范：先从你已经懂的任务开始，把 agent 放进可控工作流里，再逐步放宽边界，而不是一开始就追求“全自动”。最稳的起点，往往是代码搜索、测试补全、文档整理、PR 预审这类可回看、可复核的环节。
  • 先设计组织节奏，再设计系统规模。swyx 最近对 Agent Labs 和组织 slop 的讨论，提醒创业团队和平台团队都要警惕一种错觉：系统复杂度增长，并不天然等于护城河增长。很多时候，它只是债务增长。你是需要一条清楚的交付链路，还是只是多了一层“agent orchestration” 页面，这两件事要早点分清。

把这几条放在一起，你会发现优秀的 AI Agent Engineer 越来越不像“最会写 prompt 的人”，而更像一个同时理解任务分解、验证机制、工具权限、团队协作和产品边界的系统工程师。

我会把这四个人放在同一篇里写，原因也在这里。他们看起来分别在讲不同的事，实际上都在把行业往同一个方向推：让 AI 从一阵令人兴奋的能力展示，变成可以被普通开发者真正掌握、被团队长期维护、被组织稳健放大的生产系统。

结尾：别只记住名字，要记住他们各自守住了什么

技术浪潮里最容易发生的一件事，是大家都记住了最响亮的名字，却忘了这些名字分别守住了什么问题。

Karpathy 守住的是学习与可验证性，Simon Willison 守住的是工程纪律与开放观察，Jeremy Howard 守住的是普通人的主动权与工具边界，swyx 守住的则是生态语言、组织节奏和产业化想象力。

这四种守法没有哪一种可以单独赢下 AI 时代，但缺了任何一种，开发者都很容易走偏。只讲能力，不讲验证，系统会漂。只讲工程，不讲学习，团队会钝。只讲普及，不讲边界，产品会脆。只讲生态，不讲真实交付，叙事会空。

所以这篇文章最后想留下的判断其实很简单：今天最值得普通开发者和 AI Agent Engineer 追的人，不一定是最会制造轰动的人，而更可能是那些在不同位置上，持续把 AI 拉回学习、工程、判断和组织的人。真正长久的竞争力，往往就藏在这些不够喧哗、但非常硬的地方。