StreamSparkAI

核心概览

本期对话聚焦AI编码进入真正可用阶段后的变化。西蒙·威利森认为，2025年Anthropic与OpenAI把训练重点集中在代码生成与推理能力后，编码代理在11月跨过了关键门槛：它们不再只是偶尔写出可运行代码，而是大多数时候能按要求完成任务。这让软件开发的核心瓶颈，从写代码本身转向测试、验证、产品判断、安全控制与团队流程重构。他明确区分了适合原型和个人玩具项目的氛围式编程，与面向生产环境、依赖测试和审查流程的代理式工程。与此同时，他对安全风险非常警惕，尤其是提示注入与由私有数据、恶意指令、数据外传组成的致命三要素，并预测行业可能遭遇一次AI版挑战者号灾难。对职业层面，他认为AI会显著放大资深工程师能力、加快新人上手，但中层工程师位置最不确定。

关键议题与详细总结

2025年的变化：编码代理跨过了可用性门槛

• 西蒙的主判断：

  • 2025年，Anthropic与OpenAI逐渐意识到代码就是AI最强、最容易变现的应用场景。
  • 他提到Claude Code在2025年初推出后迅速流行，甚至让不少人愿意支付每月200美元订阅费，说明市场已经验证了这类工具的价值。
  • 与此同时，带有显式推理过程的模型在2024年底后迅速普及，这类能力在代码场景中表现尤其好，因为它们更擅长定位Bug、推演逻辑和改动结构。

• 11月拐点的含义：

  • 西蒙把某一批新模型的出现称为11月拐点。他提到GPT-5.1与Claude Opus 4.5到来后，虽然看似只是渐进改进，但实际跨过了关键阈值。
  • 关键不在于模型从差变好，而在于它从需要全程盯防，变成了多数时候能把事情做对。
  • 这种变化直接改变了工作方式：开发者可以直接让代理去构建一个桌面应用、实现一个功能或修改一个系统，而不再默认它会产出一堆完全不可用的垃圾代码。

• 最重要的影响：

  • 软件工程成为其他知识工作的先行样本。
  • 西蒙认为，代码之所以最先被AI大幅改变，是因为代码相对容易验证：程序能运行还是不能运行，通常较容易判断。
  • 相比之下，法律文书、报告、研究综述等文本型知识工作更难验证正确性，因此未来它们受到冲击时，治理难度可能更大。

这东西现在真的能用了（This actually works now.）

氛围式编程与代理式工程：不是一回事

• 西蒙对氛围式编程的界定：

  • 氛围式编程指的是：不看代码、不关心代码，甚至不理解代码，只通过自然语言来回迭代，让模型产出一个能用的原型或小工具。
  • 他认可这种方式的积极意义：它让非程序员也能做自动化、做个人工具、做原型演示，降低了让计算机替人做事的门槛。

• 他设定的责任边界：

  • 如果只是给自己用，出Bug伤害的只有自己，那么可以大胆尝试。
  • 一旦是给别人使用、可能伤害别人、涉及第三方网站、支付、权限、安全等场景，就不能再把这种方式当成负责任的开发方法。

• 为什么他坚持区分概念：

  • 很多人把所有AI辅助编程都叫氛围式编程，西蒙反对这一点。
  • 他认为，专业软件工程师使用编码代理、审查产出、运行测试、确保可上线，这种工作更适合叫代理式工程。
  • 他的核心观点是：真正高质量、可大规模上线的软件开发，依然需要深厚经验，不会因为AI而变得轻松或肤浅。

• 最终目标不是更快，而是更好：

  • 他不满足于AI让团队只是更快地产出同样质量的软件。
  • 更值得追求的是：借助代理后，软件应当变得缺陷更少、功能更多、整体质量更高。

暗黑工厂：不写代码，甚至不读代码的开发实验

• 主持人的追问：

  • 当AI逐步吞掉开发中间环节后，团队的机会是不是会前移到想法、策略、产品定义这一端？
  • 他顺着西蒙提出的暗黑工厂概念继续追问：如果连代码都不读了，软件到底如何被可靠地构建出来？

• 西蒙给出的框架：

  • 第一层变化已经开始发生：一些公司正在尝试不允许工程师手写代码。
  • 西蒙坦言，六个月前他也觉得这很疯狂，但现在他自己写出的代码里，大约95%都不是亲手键入的。
  • 第二层变化更激进：没人读代码。这才是暗黑工厂真正有挑战的地方。

我今天产出的代码里，大概95%不是我亲手敲的（Today, probably 95% of the code that I produce, I didn’t type it myself.）

• StrongDM的实验案例：

  • 西蒙重点讲了StrongDM的做法。
  • 这家公司在尝试一种极端路径：不依赖人工逐行读代码，而是用大量自动化验证来证明系统可靠。
  • 他们不是做低风险玩具产品，而是在做与访问控制、权限分配、企业安全相关的软件，因此案例更具冲击性。

• 它具体怎么做：

  • 他们构造了一个模拟的企业环境，其中有模拟员工、模拟Slack频道、模拟Jira和其他集成系统。
  • 这些模拟员工会24小时不停地提出真实用户风格的请求，例如申请访问Jira、请求开通权限等。
  • 代理系统在这种高频、持续、不间断的环境里接受测试，相当于一个永不下班的虚拟QA部门。

• 为什么要自己造Slack和Jira的模拟器：

  • 直接拿真实Slack等服务做高并发模拟会撞上速率限制。
  • 所以他们用API文档和开源客户端库，再让编码代理自己构建一套可控、低成本、可无限测试的模拟环境。
  • 这让西蒙印象非常深，因为它展示了AI不仅能写业务代码，还能反过来搭建测试基础设施。

• 西蒙的态度：

  • 他把这看作下一代软件开发的前沿探索，而不是成熟答案。
  • 即便测试做得很强，也不自动意味着系统就是安全的、可靠的、无漏洞的，只是说明团队开始找到一种替代传统人工读代码的方法。

开发流程被重写：瓶颈从写代码转向判断与验证

• 西蒙的核心逻辑：

  • 过去，工程流程里最耗时的部分是把规格转成代码。
  • 现在这一步骤被大幅压缩后，瓶颈开始出现在其他地方，例如：
    • 如何定义问题
    • 如何比较多个方案
    • 如何验证方向是否正确
    • 如何做真实用户测试
    • 如何控制质量与风险

• 原型几乎免费：

  • 他现在经常把同一功能先做三个不同原型，再实际比较。
  • 原因不是他更擅长猜对，而是因为原型成本已经低到可以把过去只想不做的方案快速做出来。

• AI在产品构思中的位置：

  • 西蒙认为，AI很适合做脑暴前半段，也就是快速吐出大量显而易见的想法。
  • 真正有价值的部分，是人类拿这些想法继续组合、筛选、质疑、验证。
  • 他还举例说明，AI适合做跨领域联想，比如让它从海洋生物学里找营销灵感，虽然大部分结果很糟，但有时能提供方向上的启发。

• 什么仍然离不开人类：

  • 他并不认为用AI模拟用户点击产品，就能替代真实可用性测试。
  • 在他看来，最可信的方法仍是让真实用户上手、共享屏幕、观察其困惑点和行为路径。
  • 这意味着人类价值正在从执行端，更多转向判断、验证、设定目标和理解人。

人类价值与职业影响：资深工程师被放大，中层最不确定

• 资深工程师为什么反而更强：

  • 西蒙明确表示，编码代理并没有削弱他25年的经验，反而把这些经验全部放大了。
  • 他能快速判断什么问题适合一句提示解决，什么问题背后可能隐藏更深结构性复杂度。
  • 这种能力并非来自打字速度，而来自长期积累的系统设计、调试、判断与工程语言。

• 新人工程师为什么也可能受益：

  • 他引用一次ThoughtWorks组织的讨论：许多工程负责人认为AI对新人也有帮助，因为它显著降低了入职上手成本。
  • 他提到，Cloudflare和Shopify都说过，实习生过去可能要一个月才能产生明显价值，而现在可能一周内就能做出有用工作。

• 最难判断的是谁：

  • 按这场讨论的结论，最受冲击、最不确定的是中层工程师。
  • 这部分人既没有足够深的经验可被AI强力放大，也不像新人那样能凭借AI快速补足最基础的入门障碍。

• 西蒙给中层从业者的建议：

  • 不要回避工具，而要主动进入这个新工作流。
  • 关键不是把工作全交给AI，而是有意识地用它放大技能、补齐短板、扩大野心。
  • 如果担心技能退化，就要主动设计使用方式，让AI成为学习与扩展能力的工具，而不是思考的替代品。

• 他对人的最终判断：

  • 他反复强调一个词：能动性。
  • 在他看来，AI没有真正的人类动机，也没有真正的自主目标，它不会像人一样知道自己为什么要解决某个问题。
  • 因此，未来仍然高度重要的不是单次执行，而是选择什么问题、为何做、如何承担后果。

效率悖论：更高产，也更累

• 主持人指出的矛盾：

  • 如果AI提升生产率，按常识人应该更轻松。
  • 但现实却是，越站在AI前沿的人，常常越忙、越累、越像在超负荷工作。

• 西蒙的亲身感受：

  • 他现在可以同时启动4个代理处理不同问题，但往往到上午11点就已经脑力耗尽。
  • 原因不是他在亲手写更多代码，而是他要同时维持多个任务、多个上下文、多个判断链条。

• 他担心的风险：

  • 有些人会因为代理还能继续工作，就不断延长工作时间，睡前还想再多派几个任务。
  • 这种状态让他联想到某种赌博式、上瘾式的使用模式，短期很刺激，长期不可持续。

• 但他也强调，这是好玩的：

  • 很多人多年来积压的个人项目，在短短几个月内被快速做完。
  • 所以这个阶段既有疲惫，也有一种非常强的创造快感。

质量标准正在变化：测试、文档已不再是充分信号

• 西蒙提出的新问题：

  • 以前，一个仓库如果测试齐全、文档完整、代码结构清晰，通常就足以让人相信它质量不错。
  • 现在这些信号都可能被AI快速补齐，因此它们不再像过去那样具有强证明力。

• 他更看重什么：

  • 他越来越看重的是使用证明，也就是作者是否真的长期使用过这套软件，是否在真实环境里经历过问题与修正。
  • 因此他会把一些虽然做得很完整、但自己还没真正使用过的软件标成alpha，提醒别人这还不是经过实践打磨的稳定产品。

• 他对未来的一个判断：

  • 随着AI让生产变得容易，手工打磨感和长期使用积累，反而可能成为更稀缺、更有价值的品质。
  • 主持人也补充了一个现象：有数据标注公司正在购买2022年前的人类手写旧代码仓库，用来训练模型。

代理式工程的实践方法：怎么把AI真正接入生产流程

代码便宜了，流程必须重构

• 西蒙的主张：
  • 最大冲击不是模型会写代码，而是写代码这件事突然变便宜了。
  • 一旦代码成本下降，整个团队的工作方式都要重想：怎样避免产出大量技术债，怎样让便宜代码仍然是好代码。

建立自己的知识仓库

• 他的方法：

  • 长期积累自己做过的实验、功能片段、原型、研究记录。
  • 他在GitHub上维护了多个仓库：一个放各种小工具，一个放由编码代理完成的技术研究。
  • 重点不只是保存笔记，而是保存已经写过代码并运行验证过的成果。

• 为什么这比单纯做深度研究更有价值：

  • 如果只是让模型搜网页、写一份看起来完整的报告，价值有限。
  • 只有当代理真的写过代码、跑过实验、画过图、测过性能，这些资料才更接近可重用资产。

测试先行，尤其是红绿TDD

• 西蒙强调的第一原则：

  • 既然是编码代理，就必须让它运行测试。
  • 如果不运行测试，本质上还是在复制粘贴聊天机器人的代码，然后碰运气。

• 他推荐的做法：

  • 尽量让代理先写测试，再让测试失败，再去实现代码，最后让测试通过。
  • 这个流程可以用简短术语触发：红绿TDD。

• 为什么这在AI时代更重要：

  • 测试不仅验证当前功能，也保护旧功能不被新改动破坏。
  • 过去可能担心测试太多、维护成本太高；现在因为修改测试也能交给代理，所以他对大量但有效的测试更宽容了。

从好模板开始，而不是从空白开始

• 西蒙的经验：

  • 编码代理特别善于沿用现有代码风格。
  • 所以新项目最好不要从零开始，而是从一个很薄的模板启动：哪怕只有一个最简单的测试、固定的目录结构和一点样板代码，也足以让代理稳定沿着这套模式工作。

• 这比长篇说明更有效：

  • 有些人会用专门的说明文件告诉模型自己喜欢什么风格。
  • 西蒙更偏好用代码样板表达偏好，因为代理对已有模式的模仿能力往往比对文字说明的遵循更可靠。

工具栈与使用习惯

• 当前主力工具：

  • 西蒙目前主要使用Claude Code，也会用托管在云端、能在手机上操作的版本。
  • 他喜欢这套方式的原因之一是安全边界更清楚：如果代理在云端乱来，损失在对方服务器上；如果在本地乱来，风险更直接。

• 关于不安全模式：

  • 他认为很多人没真正体验到编码代理的能力，是因为一直卡在反复确认权限的保守模式里。
  • 一旦进入更高自治模式，代理才真正像代理，而不是一个不断打断你的烦人助手。

• 模型选择：

  • 他表示最近也在更多使用OpenAI的新模型，因为质量接近Claude且成本更低。
  • 他预计未来会在不同模型之间来回切换，因为它们会不断互相超越。

• 搜索与记忆功能：

  • 现在他大量通过Claude、ChatGPT、Gemini做搜索，已经很少直接使用Google搜索。
  • 但他会尽量关闭长期记忆功能，因为他不希望模型基于私人上下文给出只有自己能复现的结果。

安全风险：提示注入、致命三要素与挑战者号灾难

• 提示注入是什么：

  • 西蒙强调，这不是模型本身的一个小毛病，而是基于大模型构建应用时的系统性漏洞。
  • 本质问题在于：模型很难稳定地区分开发者的指令与外部输入里夹带的恶意指令。

• 他举的核心案例：

  • 大家都想要一个能读邮件、回邮件的个人助理。
  • 但只要攻击者给你发一封邮件，在内容里写进恶意指令，模型就有可能把那段文字当成高优先级命令执行，从而泄露你的隐私数据。

• 致命三要素：

  • 西蒙后来用另一个术语来帮助大家理解真正危险的场景：
    1. 系统能接触私有数据
    2. 外部攻击者能把恶意指令送进系统
    3. 系统有能力把数据发回攻击者
  • 这三个条件同时出现时，风险最高。

• 为什么单靠规则拦不住：

  • 主持人问：为什么不能直接告诉AI不要被骗、不要泄露数据？
  • 西蒙回答：哪怕检测系统能做到97%有效，在安全上也仍然是失败，因为剩下的3%足以造成严重后果。
  • 恶意指令可以换语言、换写法、换上下文，不存在一张能彻底列完的黑名单。

• 他的安全原则：

  • 不要幻想把提示注入彻底堵死，更现实的做法是限制爆炸半径。
  • 最常见的做法，是切断致命三要素中的一环，尤其是尽量限制数据外传能力。

• 为什么他预测会有AI版挑战者号灾难：

  • 他引用航天史中的偏差常态化概念：一次次侥幸成功，会让组织越来越相信自己做法没问题。
  • 在AI代理领域，大家正在越来越大胆地把模型接入高风险工作流，但至今还没出现一个足够震撼全行业的大事故。
  • 他认为这不会永远持续，迟早会有一次重大事件把问题暴露出来。

我们会看到AI领域的挑战者号灾难（My prediction is that we’re going to see a Challenger Disaster.）

• 是否有缓解路径：
  • 他提到Google DeepMind提出过一种思路：把系统拆成高权限代理与隔离代理两层，让接触不可信内容的部分没有直接执行高风险动作的能力。
  • 再配合只在高风险节点触发的人类审批，可能是更现实的安全设计方向。
  • 但他明确说，这类方案复杂、尚未成熟、缺少令人信服的大规模实现。

OpenClaw：高风险，但说明市场极度渴望数字助理

• 为什么它重要：

  • 在西蒙看来，OpenClaw几乎就是他最不愿意见到的那类东西：一个能访问邮箱、执行动作、处理个人事务的代理系统。
  • 从安全角度看，它天然危险。

• 但它为什么迅速爆红：

  • 他提到，这个项目从2025年11月25日写下第一行代码，到几个月后已经能出现在超级碗广告相关场景中，扩张速度惊人。
  • 这说明用户对真正的个人数字助理需求极强，强到愿意忍受安装复杂、权限危险和不成熟状态。

• 西蒙的判断：

  • Anthropic与OpenAI不是没能力做，而是它们知道这类产品很难安全地做出来。
  • 独立开发者没有同样的约束，因此更容易把产品先推向市场。

• 他的态度并非全盘否定：

  • 他承认OpenClaw是个令人震惊的项目，功能上也确实展示了巨大吸引力。
  • 如果有人能做出一个安全版OpenClaw，那会是AI领域极大的机会。

• 两位发言人的实际做法：

  • 西蒙自己只会在隔离环境里运行这类系统。
  • 主持人则提到自己为它单独买了一台Mac mini，并尽量限制其权限范围。

西蒙自己的工作重点：数据新闻、博客连载与实验文化

• 数据新闻方向：

  • 西蒙的核心工作仍然是为数据新闻和调查报道做开源工具。
  • 他近一年开始把AI与新闻工作结合起来，例如从警察报告PDF中抽取结构化信息、生成表格、辅助查询。
  • 他认为，新闻行业虽然要求真实性，但记者本来就擅长面对不可靠来源，因此只要把AI视作不可靠但可利用的线索来源，它未必与新闻天然冲突。

• 他给自己设定的目标：

  • 希望未来某次普利策奖级别的报道里，他的软件能贡献哪怕很小的一部分价值。

• 写作与收入：

  • 他正在把有关代理式工程的内容按章节发布在博客上，不急于做成传统意义上的正式书。
  • 他还提到，博客最近开始通过赞助与通讯赞助带来真实收入，终于不再只是纯投入的副项目。

• 轻量咨询模式：

  • 他喜欢的是零交付咨询：客户买他的思考时间，而不是报告、代码或长期项目。
  • 这与他当前以开源、博客、研究和实验驱动的工作方式一致。

对话中的轻松插曲：鹈鹕基准与鸮鹦鹉好消息

• 鹈鹕骑自行车基准：

  • 西蒙曾设计一个有趣的模型测试：让语言模型直接生成鹈鹕骑自行车的SVG图。
  • 这原本是半开玩笑地反讽传统基准分数，但他意外发现：模型画得越像样，往往整体能力也越强。
  • 这个测试后来甚至被不少AI实验室注意到，并成了一个圈内玩笑。

• 收尾的好消息：

  • 西蒙在结尾分享了与AI无关的正面消息：新西兰珍稀鸟类鸮鹦鹉在2026年迎来很好的繁殖季。
  • 这是他特意带来的少见好消息，也让整场以风险和变革为主的讨论有了一个轻松落点。

数据与统计信息汇总

• 代码占比：西蒙称自己当前约95%代码并非手打。
• 产能变化：开发者如今一天可生成约1万行代码。
• 并行负荷：他可同时跑4个代理，但常到上午11点已脑力耗尽。
• 测试投入：StrongDM曾为模拟测试花费每天1万美元Token。
• 安全能力：Anthropic曾向Mozilla报告约100个Firefox潜在漏洞。

决策与建议

• 工程实践建议：

  • 把AI用于原型、多方案试错、重复性实现，但不要把面向他人的高风险产品仅建立在氛围式编程之上。
  • 在代理式工程里，把自动化测试视为底座，而不是可选项。
  • 尽量让代理执行先写测试、先看失败、再实现、再回归验证的流程。
  • 用薄模板启动新项目，让代理沿着既定风格和结构扩展，而不是从空白仓库开始。

• 知识管理建议：

  • 建立自己的可搜索知识仓库，优先保存已运行、已验证、可复用的实验结果，而不只是文字笔记。
  • 让这些仓库成为AI可以读取和组合的上下文资产，以提高后续开发效率和稳定性。

• 安全建议：

  • 对能访问私有数据的代理系统，优先切断致命三要素中的至少一环，尤其是限制数据外传。
  • 高风险代理尽量运行在隔离环境中，不给不必要权限，不把敏感资料随手暴露给代理。
  • 不要因为模型拦截率提高就误以为问题已经解决，提示注入应按长期存在的系统性风险对待。

• 职业建议：

  • 资深工程师应主动把经验转化为与代理协作的能力。
  • 中层和其他知识工作者更应尽快上手这些工具，避免只站在观望位置。
  • 使用AI时要关注过劳、技能退化与上瘾式使用风险，主动重建个人工作边界。

• 已形成的个人行动方向：

  • 西蒙将继续在博客连载代理式工程相关书稿。
  • 他计划尝试自己构建一个Claw类系统。
  • 他会继续把AI能力引入数据新闻工具链，推动新闻场景中的真实应用。

不确定性与待确认点

• 其他知识工作是否像编程一样适合代理闭环：西蒙明确把这视为开放问题，尚无定论。
• 暗黑工厂能否稳定产出安全、可上线的软件：现有案例更像前沿实验，不足以证明其已成熟。
• 中层工程师的长期位置：这是西蒙认为当前最不确定的人群，未来走向未明。
• AI对整体就业的真实冲击：裁员新闻、岗位增长、招聘噪音同时存在，宏观影响仍难判断。
• 提示注入能否被彻底解决：目前只有缓解思路，没有被西蒙认可的严格解决证明。
• 个别模型版本与产品名称：转录中出现GPT-5.1、GPT-5.4、Claude Opus 4.5、Claude Opus 4.6、OpenClaw等表述，个别细节可能受机器转录误差影响。

结论回顾

• AI编码已跨过可用性阈值，软件开发的核心工作正在从手写代码转向验证、测试、判断与治理。
• 真正重要的不是让AI代写代码本身，而是把代理纳入负责任、可验证、可控的工程体系。
• 当前最危险的短板不在生成能力，而在安全边界与行业对风险的侥幸心理。