我从 @simonw 那里获得的最大心得： 1. 2025 年 11 月是 AI 编程的一个拐点。GPT 5.1 和 Claude Opus 4.5 跨越了一个阈值，编程智能体从“大多能用”变成了“几乎总是能按你预想的执行”。假期里尝试过这些工具的软件工程师们意识到，这项技术已经真正变得可靠了。 2. 中坚工程师最容易受到冲击——不是初级，也不是资深工程师。AI 通过让资深工程师利用几十年的模式识别经验来放大他们的能力。它也极大地帮助了新工程师入职。Cloudflare 和 Shopify 各自雇佣了一千名实习生，因为 AI 将上手时间从一个月缩短到了一周。但那些尚未积累深厚专业知识，又已经吃不到初学者红利的中坚工程师，正处于最不稳定的境地。 3. AI 疲劳是真实存在且被低估的。Simon 同时运行四个编程智能体，到上午 11 点时大脑就完全耗尽了。他节省了更多时间，但同时指挥多个自主工作者带来的强度让他精疲力竭。一些工程师为了保持智能体运行而牺牲睡眠。这可能只是因为新鲜感，但其底层的动态——即管理 AI 即使减少了劳动，也增加了认知负荷——是一种真实的张力。优秀的公司会管理预期，而不是无限期地期待 5 倍的产出。 4. 代码现在很廉价。这个简单的想法有着深远的影响。过去最耗时的事情——写代码——现在耗时最少。瓶颈已经转移到其他方面：决定构建什么、证明想法可行、获取用户反馈。由于原型设计几乎零成本，Simon 在开始时通常会为每个功能构建三个版本。 5. “黑暗工厂”是目前 AI 辅助开发中最激进的实验。一家名为 StrongDM 的公司制定了政策：没人写代码，没人读代码。相反，他们 24/7 全天候运行一群 AI 模拟的终端用户——成千上万的假员工发出类似“给我 Jira 访问权限”的请求——每天花费 1 万美元的 Token 成本。他们甚至让编程智能体根据 API 文档构建了 Slack、Jira 和 Okta 的模拟版本，以便在没有速率限制的情况下进行测试。 6. “红/绿 TDD”是杠杆率最高的智能体工程模式。让编程智能体先写测试，观察它们失败，然后编写实现，再观察它们通过，能产生实质上更好的结果。“使用红/绿 TDD”这五个字的提示词就能编码整个工作流，因为智能体能识别这些行话。 7. “囤积你已掌握的方法”是 Simon 最喜欢的另一种智能体工程模式。Simon 维护着一个包含 193 个小型 HTML/JavaScript 工具的 GitHub 仓库，以及一个独立的编程智能体实验研究仓库。每一个都捕捉了他测试过的一种技术、概念验证或库。当新问题出现时，他可以向 Claude Code 指出过去的项目并说：“结合这两种方法。” 8. “致命三要素”使得 AI 智能体安全问题从根本上无法解决。每当 AI 智能体具备访问私有数据、接触不可信内容（如传入的电子邮件）以及向外部发送数据（如回复邮件）的能力时，你就拥有了“致命三要素”。提示词注入——即不可信文本中的恶意指令覆盖了智能体的预期行为——无法被可靠地预防。Simon 三年来每六个月就预测一次 AI 安全领域的“挑战者号灾难”。虽然还没发生，但他非常确定它迟早会发生。 9. 从精简模板开始每个项目，而不是长篇指令文件。编程智能体在匹配现有模式方面表现极佳。一个包含你偏好的缩进和风格的单一测试文件，比长篇大论的文字指令更有效。Simon 每个项目都从包含一个测试（字面意思是测试 1 + 1 = 2）的模板开始，并按照他喜欢的风格布局。智能体能领悟这一点，并在整个代码库中遵循该惯例。这比维护复杂的提示词文件更便宜、更可靠。 10. “骑自行车的鹈鹕”基准测试意外地成为了一个真正的 AI 基准。Simon 创建它纯粹是为了嘲讽数字基准测试——让每个大语言模型生成一张鹈鹕骑自行车的 SVG 图，然后比较画作。出乎意料的是，画作的好坏与模型在其他所有方面的能力之间存在很强的相关性。没人能解释原因。这已经成为了一个梗：Gemini 3.1 的发布视频中就出现了骑自行车的鹈鹕。AI 实验室对此心知肚明，并正在私下里进行竞争。 不要错过我们的完整对话：https://t.co/ghZZeyvWBZ

软件开发正发生在我们眼前的复兴。 如果你最近没用过这些工具，你可能低估了你所错过的东西。自 12 月以来，Codex 等工具的能力发生了阶跃式提升。昨天 OpenAI 的一些优秀工程师告诉我，他们的工作自 12 月以来发生了根本性的变化。在那之前，他们只能用 Codex 编写单元测试；而现在，它基本上编写了所有代码，并承担了大量的运维和调试工作。并非所有人都迈出了这一步，但这通常是因为模型能力之外的因素。 现在每家公司都面临着同样的机遇，而要驾驭好这一机遇——就像对待云计算或互联网一样——需要深思熟虑。这篇文章分享了 OpenAI 目前如何引导我们的团队向“智能体化软件开发”转型。我们仍在学习和迭代，但以下是我们目前的思考： 作为第一步，我们的目标是在 3 月 31 日前实现： (1) 对于任何技术任务，人类的首选工具是与智能体交互，而不是使用编辑器或终端。 (2) 人类使用智能体的默认方式被明确评估为安全，且具有足够的生产力，使得大多数工作流不需要额外的权限。 为了实现这一目标，我们几周前向团队提出了以下建议： 1. 花时间试用工具。工具本身就是最好的推销——许多人在几个月前放弃了 Codex 网页版，但在 Codex 5.2 中获得了惊人的体验。但许多人太忙了，还没机会尝试 Codex，或者陷入了纠结“它有没有办法做 X”，而不是直接尝试。 - 为你的团队指定一名“智能体负责人” (agents captain) —— 负责思考如何将智能体引入团队工作流的主要负责人。 - 在指定的内部频道分享经验或问题。 - 抽出一天时间举办公司范围内的 Codex 黑客松。 2. 创建技能和 AGENTS[.md]。 - 为你参与的任何项目创建并维护 AGENTS[.md]；每当智能体出错或在任务中挣扎时，更新 AGENTS[.md]。 - 为你让 Codex 做的任何事情编写“技能” (skills)，并将其提交到共享仓库的技能目录中。 3. 盘点并开放内部工具。 - 维护一份团队依赖的工具列表，并确保有人负责使其可被智能体访问（例如通过 CLI 或 MCP 服务器）。 4. 构建“智能体优先”的代码库。随着模型更迭如此之快，这在某种程度上仍是处女地，需要一些探索。 - 编写运行速度快的测试，并在组件之间创建高质量的接口。 5. 拒绝垃圾代码 (Say no to slop)。在大规模管理 AI 生成的代码是一个新兴问题，需要新的流程和规范来保持高代码质量。 - 确保有人对任何合并的代码负责。作为代码审查者，至少要保持与审查人类代码相同的标准，并确保作者理解他们提交的内容。 6. 完善基础架构。每个人都有很大的空间来构建基础架构，这可以由内部用户反馈来引导。核心工具正变得越来越好用，但目前工具周围还有很多配套设施，例如可观测性、不仅跟踪提交的代码还要跟踪导致这些代码的智能体轨迹 (agent trajectories)，以及对智能体可用工具的集中管理。 总的来说，采用 Codex 这样的工具不仅是技术变革，也是深刻的文化变革，还有许多下游影响需要解决。我们鼓励每位管理者带领团队推进这一进程，并思考其他行动项 —— 例如，针对上述第 5 点，还有什么能防止大量“功能正确但难以维护的代码”潜入代码库。

nanochat 现在可以用远低于 100 美元（约 73 美元，在单台 8xH100 节点上耗时 3 小时）的成本训练出 GPT-2 级别的 LLM。 GPT-2 是我最喜欢的 LLM，因为它是 LLM 技术栈首次以公认的现代形式呈现。因此，利用过去 7 年的进步，以更低的成本训练出一个具备 GPT-2 能力的模型，已经成了我的一种奇特且持久的执念。特别是我怀疑，在今天应该可以用远低于 100 美元的成本训练出一个。 最初在 2019 年，OpenAI 在 32 个 TPU v3 芯片上训练 GPT-2 耗时 168 小时（7 天），当时的单价是 8 美元/小时/TPUv3，总成本约为 4.3 万美元。它达到了 0.256525 的 CORE 评分，这是 DCLM 论文中引入的一项综合指标，涵盖了 ARC/MMLU 等 22 项评估。 随着最近合并到 nanochat 的几项改进（许多源自 modded-nanogpt 仓库），我现在可以在单台 8xH100 节点上用 3.04 小时（约 73 美元）达到更高的 CORE 评分。这在 7 年内实现了 600 倍的成本缩减，也就是说，训练 GPT-2 的成本每年大约下降 2.5 倍。我认为这可能还是低估了，因为我仍然在相对定期地发现更多改进，而且我还有一堆新想法等着去尝试。 关于优化细节的长文和复现指南请见：https://t.co/vhnK0d3L7B 受 modded-nanogpt 启发，我还创建了一个“GPT-2 训练时长”排行榜，这个首个“Jan29”模型以 3.04 小时位列第一。继续迭代会很有趣，欢迎大家帮忙！我希望 nanochat 能成长为一个非常优雅、简洁且经过调优的实验性 LLM 框架，用于原型设计、寻找乐趣，当然还有学习。 在那些开箱即用且能立即产生收益的改进中，最显著的是：1) Flash Attention 3 算子（速度更快，并允许通过 window_size 参数实现交替注意力模式）；Muon 优化器（我曾尝试花一天时间删掉它只用 AdamW，但没成功）；由可学习标量控制的残差路径和跳跃连接；以及值嵌入（value embeddings）。还有许多其他的小改进累积在一起。 配图：与推文半相关的“视觉享受”——推导当前 nanochat 模型系列的缩放法则，既漂亮又治愈！

又一年的 AI 快速发展，为所有人——包括那些刚进入该领域的人——提供了比以往更多的软件构建机会。事实上，许多公司就是找不到足够熟练的 AI 人才。每个寒假，我都会花一些时间学习和实践，我希望你也能如此。这有助于我磨练旧技能、学习新技能，也能帮助你在科技领域发展职业生涯。 为了熟练地构建 AI 系统，我建议你： - 参加 AI 课程 - 练习构建 AI 系统 - （可选）阅读研究论文 让我来分享一下，为什么这些都至关重要。 我听说有些开发者建议其他人直接投入实践，而无需担心学习。这绝对是个糟糕的建议！除非你已经身处一个经验丰富的 AI 开发者社区中，否则在不理解 AI 基础的情况下投入实践，意味着你将冒着重复造轮子的风险，或者——更可能——只是拙劣地重复造轮子！ 例如，在与求职者面试时，我曾遇到一些开发者，他们重新发明了标准的 RAG 文档分块策略，复制了代理式 AI 现有的评估技术，或者编写出混乱的 LLM 上下文管理代码。如果他们修了几门相关的课程，就会更好地理解已有的构建模块。即使他们想从头开始重建这些模块，甚至可能发明出比现有解决方案更优越的东西，也能避免数周不必要的工作。因此，结构化学习至关重要。此外，我发现上课真的很有趣。与其看 Netflix，我更喜欢随时观看一位知识渊博的 AI 讲师的课程！ 然而，仅仅上课是远远不够的。许多经验只能通过动手实践才能获得。学习飞机工作原理的理论对于成为一名飞行员固然重要，但没有人仅仅通过上课就能学会驾驶飞机。在某个阶段，亲身坐进驾驶舱进行实践至关重要！好消息是，通过学习使用高度代理式的编码器，构建过程比以往任何时候都更加容易。而学习 AI 构建模块可能会激发你构建新事物的想法。如果我对要做什么项目没有灵感，我通常会去上课或阅读研究论文，这样过一段时间后，我总会涌现出许多新想法。此外，我发现实践真的很有趣，我希望你也能体会到这一点。 最后，并非所有人都有必要这样做，但我发现当今就业市场上许多最优秀的候选人至少偶尔会阅读研究论文。虽然我发现研究论文比课程更难理解，但它们包含了许多尚未被转化为更容易理解形式的知识。我将阅读研究论文的优先级放在上课和实践构建之下，但如果你有机会增强阅读论文的能力，我强烈建议你这样做。我发现上课和实践很有趣，而阅读论文可能更像是一项苦差事，但从中获得的灵光一闪的洞见却令人欣喜。 祝大家度过一个愉快的寒假和新年。除了学习和实践，我希望你们也能多花时间陪伴所爱之人——这一点同样重要！ [原文链接: https://t.co/MaWDs0AbzG ]