我和同事们目前正在利用 OpenCode（Claude Code 的一个替代方案）进行一项小研究。目前我们刚开始测试 gpt-5-mini，看看它在编程辅助方面的性能能否与 Claude Sonnet 媲美。也非常欢迎大家亲自尝试研究并分享心得，比如哪种 LLM 模型成功率最高，以及使用了什么样的 Prompt（提示词）。注：我是来自印尼的用户，正在使用 Google Gemini 协助翻译论坛里的讨论。如果翻译有不准确的地方，还请大家多多包涵，手下留情。 github.com GitHub - galpt/you: An autonomous AI agent orchestrator that...An autonomous AI agent orchestrator that coordinates an entire software company within OpenCode 📌 转载信息来源： https://linux.do/t/topic/1510629原作者： galpt转载时间： 2026/1/25 08:06:35
前端没有实际的必要了？结合今年工作内容，谈谈我的看法
今天被一张《IT 开发工作可能要完全重组》的图片刷屏，图片中的观点是：传统的「产品-设计-前端/后端」模式在 AI 时代将被变革。很多人会觉得“前端没有实际的必要了”是管理者自嗨，但就我个人的见闻而言，这可能真的是未来趋势。基于 AI 的一专多能“超级个体”模式已经在很多公司铺展开，未来不久程序员大概率会不分前后、只剩全栈。之所以敢这么笃定，是因为今年我亲身经历了这个变化。简单聊聊我的工作变化今年我的工作 80% 都是 AI 相关，工作内容上有三个比较大的转变：技能层面：从“纯前端技术”转向“产品设计+AI内容生产+代码实现”的复合能力（例如：结合自身的冥想经历，提出并开发上线冥想呼吸练习功能）。 协作层面：从“与产品/后端对接”转向“与AI协同+跨部门整合”（例如：直接参与产品需求设计，用 AI 快速做 demo、上线验证方案可行性）。 成果层面：从“交付代码”转向“交付「产品+技术」解决方案”（例如：用 AI 生成热点资讯）。 工作时间分配上，也从之前的「大部分时间手写代码」变成了：20% 的时间：手写代码（一般是改 bug） 30% 的时间：指挥 AI 写代码、review、accept/undo、cmmit & push 30% 的时间：优化提示词的效果 20% 的时间：和 AI 碰撞点子和改进方案在我做的这些项目里，正如文章开头的图片所说，完全没有前后端岗位的概念，基本上都是和业务方沟通完需求、确定好方案，就开发、上线，甚至有的需求我自己定方案（在 AI 的加持下）。插播一则机-会技术大厂，前端-后端-测试，全国均有机-会，感兴趣可以试试。待遇和稳定性都还不错~前端是不是真的没有实际的必要了那么问题来了，前端/后端以后是不是就不需要这么多人，大家要失业了？我的看法是：程序员这个岗位的确会变少，但适合我们的新机会也随之诞生了。随着大模型的编程能力提升和配套设施完善，代码开发的 AI 化必定会发展到 80% 甚至 90%（至少还需要 10～20% 的人把关）。如果只盯着程序员的「把需求文档实现为代码」这个职能，我们的机会是越来越少的。但如果着眼于使用 AI 进行业务流程改造和内容生产，机会会越来越多。最近两年开始，很多公司开始招聘名为「AI 工程师」的岗位，他们的工作内容就是业务优化和 AIGC。这个岗位招的人呈两极分化：要么是年轻的高学历应届生、要么是经验丰富的资深开发者。招高学历应届生是因为他们具备创新和挑战精神；而招资深开发者转型 AI 应用，是因为他们有业务经验、全栈能力更强。我今年的岗位角色就是 AI 工程师，在带着这种视角工作时，会发现有太多可以做的，以前凭感觉定的都可以用 AI 重做一遍，AI 工程师目前还远远不够。想想我们的产品里有多少文案是写死的？有多少数据是无人问津的？有多少策略是拍脑袋定的？这些都是 AI 工程师可以改造优化的点。总结忍不住多写了几句，一看表这么晚了，年纪大了不能熬夜，总结一下结束此文。技术变革就是会让生产效率提升，让工具性的岗位变少（程序员说白了就是把人的语言翻译为机器语言），但也会催生出新的岗位，我们要向前看。从感性上我们是不愿意接受的，怎么革命偏偏革到了我们头上？我的房贷还没还完呢，以后可怎么办呢？别慌，就我今年的经验来看，这一波 AI 技术革命，作为软件开发的我们有先发优势，只要稍加学习，再加上一些业务思考，很容易就可以转型到 AI 工程师。至于如何转型到 AI 工程师，容我结合今年的工作&学习经验梳理下，也欢迎感兴趣的朋友留言讨论你们的看法。滚滚长江东逝水，乘风安逸逆风衰，晚安朋友。——转载自：张拭心
科技爱好者周刊（第 382 期）：独立软件的黄昏
这里记录每周值得分享的科技内容，周五发布。本杂志开源，欢迎投稿。另有《谁在招人》服务，发布程序员招聘信息。合作请邮件联系（[email protected]）。封面图巫山县城建在山坡上，为了方便居民和促进观光，在中轴线上建设了神女大扶梯，总长905米，高240余米，相当于80层楼，全程需要20分钟。（via）独立软件的黄昏软件可以分成两种：一种是公司开发的，另一种是个人开发的。后者就称为"独立软件"（indie software）。它的历史非常悠久，从古至今，很多程序员依靠出售独立软件谋生。有一种东西"共享软件"（Shareware），年轻的朋友未必知道，二三十年前曾经非常流行。用户免费使用软件的试用版，如果满意，就向开发者购买一个注册码。这就是一种独立软件，当年很多著名软件都是这个模式，比如国外的 WinZip 和 WinRAR，国内的网络蚂蚁（NetAnts）、网际快车（FlashGet）、豪杰解霸。时至今日，大家看看目前流行的软件，还有多少属于独立软件？你每天使用的软件，又有多少是个人开发的？很少很少了。一位二十年的独立软件开发者哀叹，现在的市场上，公司开发的比重越来越大，个人开发的比重越来越小，独立软件正在没落。"我销售自己的软件20年了，2005年以后，互联网开始普及，独立软件迎来了黄金年代。而最近两三年，环境一直在快速变化，销售明显变难了，我感觉自己越来越难维持生计了。"独立软件的大发展，是从2005年开始的。 互联网的普及，网民数量急剧增长。 智能手机创造了手机软件，一个全新的软件大市场。 在线支付的普及和简化。 互联网使软件分发变得容易且免费。 免费的高质量开发工具（编译器、IDE、版本控制系统、Web 服务器）不断涌现。 这些因素让程序员切切实实获利了，要是你再做一些 SEO、买一些付费广告，完全可能赚到大钱。很多人就是这样发展起来的，从独立软件变成了大公司。但是，最近两三年情况变了，上面这些因素都到头了。独立软件正在慢慢退潮，你能够想起名字的独立软件越来越少，更不要说掏钱购买了，即使有也是多年前的作品。根据我的观察，依靠出售自己软件维生的程序员似乎也在减少。主要原因有下面几个。（1）AI 改变了互联网流量，独立软件失去了推广渠道。网站的访问量显著减少，人们更多跟大模型交互，而不是浏览网页。通过搜索引擎和在线广告获取流量的策略，越来越没有效果。视频是为数不多仍然有效的推广渠道之一，但制作视频非常耗时，而且竞争异常激烈。另外，AI 生成的劣质视频迟早会大量出现，推广效果也会变差。（2）AI 使得软件开发变得容易。它加快了开发速度，降低了进入门槛，让更多人加入竞争。以前，用户可能购买某个功能，现在直接让 AI 生成即可。（3）新软件汗牛充栋，越来越难脱颖而出。iPhone 应用商店有大约200万个应用，用户很难发现你。另一方面，应用商店更喜欢推广那些能帮它赚更多钱的大公司软件，而不是独立软件。（4）人们越来越习惯使用基于网络的软件，独立软件属于需要下载安装的原生应用，它的市场在萎缩。基于网络的软件与其说是产品，不如说是一种服务，全天候24小时可用的服务。越来越多的个人开发者顺应这种趋势，改为以提供 SaaS 服务为主。（5）平台的风险。现在的很多独立软件，都依靠云服务商的平台或底层服务，而平台随时会改变规则（比如关闭 API），或者推出竞品，一大批应用随之死掉，这种事情屡见不鲜。（6）用户期望软件是免费的，或者非常便宜。售价略微高一点，就会无人问津。因此，独立软件要想获得可观的回报，就需要巨大的销售规模，这根本做不到。别的不说，个人开发者完全无力提供满意的客服。（7）以上这些因素将长期存在，只会加深，不会逆转。独立软件的时代可能真的要结束了，个人开发者以后大概很难靠销售自己的软件为生，而要改为销售自己维护的 SaaS 服务，尽管这也很难。科技动态1、VS Code 的定位微软公司的 VS Code 是非常流行的代码编辑器，市场份额很高。现在的官网上，它的产品定位是"开源 AI 代码编辑器"。但是，2025年上半年，它的产品定位还是"你的代码编辑器，由 AI 重定义"。更早的2024年，产品定位是"重新定义的代码编辑"。令人感慨啊，这么成功的软件，AI 本来只是附属功能，现在也要蹭热点，把自己包装成 AI 主导的产品。2、智能脖巾英国科研人员发明了一种智能脖巾。它围在脖子上，可以感受到穿戴者的心跳和喉部肌肉运动。它的用户主要是中风后丧失说话能力的人。这些人可以张嘴，做出说话的口型，但是无法正常发音。他们佩戴这个脖巾后，颈部的运动数据就通过它传给电脑，经过模型训练，可以用电脑语音还原出用户想说的话。3、雪宝机器人人形机器人何必一定做成人形。迪斯尼最近发布了一个机器人，样子就是电影《冰雪奇缘》的雪宝。它用来在迪斯尼乐园，跟游客互动。它启示我们，人形机器人做成卡通形状也很好。另外，LG 公司在美国 CES 展会上，展示了他们最新的家务机器人。这个机器人的功能就是做家务，比如叠衣服和洗碗。我觉得，国内厂商可以借鉴，展示机器人功能时，不要展示跳舞打拳，而要展示如何做家务。文章1、别用 MySQL，改用 MariaDB（英文）曾经的明星数据库 MySQL，最近几个月的代码提交数为0（上图）。作者认为，种种迹象表明甲骨文已经放弃了这个项目。2、10秒获得 AI 代码评审结果（英文）本文介绍一个技巧，让 AI 快速给出提交代码的评审结果，方法是不要提交整个代码库，只提交 diff 的部分。3、使用 Pandoc 生成静态网站（英文）文档格式转换工具 Pandoc 可以用来生成静态网站，作者介绍自己是怎么做的。4、锚点元素的一些鲜为人知的地方（英文）锚点元素用来生成链接，本文介绍如果链接到一些特殊字符的情况。5、学习自定义元素（英文）一篇 HTML 自定义元素的教程文章，写得简单清晰。6、Go、Rust 和 Zig 的一些想法（英文）作者是一个高级程序员，谈谈他对 Go、Rust、Zig 三种语言的感受。有趣的地方是，这三种语言都没有类，也不支持面向对象编程。7、我的个人基础设施（英文）作者介绍他自己的家庭实验室。比较有趣的是，他的个人网站是本地构建后，自动用 Syncthing 同步到服务器，这对小型静态网站确实简单。工具1、GoRead开源的电子书阅读器应用，支持桌面与移动端（Android/iOS）。（@zhashut 投稿）2、EasyPostman用于 API 调试的跨平台桌面应用，对标 Postman + JMeter。（@lakernote 投稿）3、Port Sentinel（端口哨兵）Windows 桌面应用，查看端口占用情况。（@Sanjeever 投稿）4、Building Sunlight Simulator基于 Web 的楼盘采光 3D 日照模拟工具，帮助购房者评估小区采光。（@SeanWong17 投稿）5、Office App一个纯本地的 Office 网页应用，可以离线在网页创建/编辑 Word、Excel、PowerPoint 文件。（@baotlake 投稿）6、ScreenshotSnap免费的网站截屏在线工具，提供 API，可以直接将截图代码插入网页。（@phpiscute 投稿）7、tsshdSSH 服务器登录协议的全新实现，特点是连接不掉线，可以重连前一个对话。（@lonnywong 投稿）8、AirScan-QR一个开源网页应用，通过动态二维码发送/接收文件。（@topcss 投稿）9、LuCI Bandix开源路由器操作系统 OpenWRT 的一个插件，可以监控局域网各设备的实时流量和目的地。（@timsaya 投稿）10、pure-genealogy开源的网页族谱工具，用来生成家族族谱，基于 Next.js + Supabase。（@yunfengsa 投稿）11、mdto.page这个网站免费将 Markdown 文件转成 HTML 格式，发布成公开访问的网页。AI 相关1、ChatGPT 翻译OpenAI 悄悄发布的翻译功能，只有在官网可用。2、Mango Desk一个跨平台的桌面应用，使用自然语言进行本地文件搜索。（@moyangzhan 投稿）3、OpenWorkClaude 公司新产品 CoWork 的开源替代品，让普通用户不编程，就能完成文件操作，定位就是"Claude Code 的非编程版"。另有一个类似项目 Open Claude Cowork。（@aiagentbuilder 投稿）4、Wolfcha（猹杀）开源的网页游戏 AI 狼人杀，除了玩家自己，其他所有角色（女巫、猎人、守卫、狼人等）都由 AI 扮演。（@oil-oil 投稿）资源1、维基百科25周年维基百科是2001年1月13日上线的，今年是25周年纪念。这个网站是官方的纪念网站，以互动形式展示了发展历程。另外，还有一篇文章，介绍互联网档案馆的历史（下图）。2、HTTP:COLON这个网页可以查看指定网站返回的 HTTP 标头，详细解释每个字段的含义。3、现代 Java（Modern Java）面向初学者的 Java 语言教程。图片1、中国新能源建设的惊人规模90后摄影师储卫民拍摄的中国新能源建设。他说："从地面上很难体会这些发电厂的规模，但当你升到空中时，就能看到它们与山脉、沙漠和海洋之间的关系。"青海冷湖镇浙江象山县青海塔拉滩内蒙古阿拉善"我一开始只是拍摄风景，但2022年我去贵州、云南、青海等地旅行时，不断看到风力发电场和太阳能发电厂出现在我的镜头里。我意识到这就是我们这个时代的故事----但几乎没有人系统地记录它。"文摘1、谷歌14年工作的教训大约14年前，我加入谷歌，以为这份工作就是编写优秀的代码。这个想法部分正确。但随着时间的推移，我越来越意识到，真正成功的工程师不一定是最优秀的程序员，而是懂得驾驭代码之外一切的人。下面就是我得到的经验教训。有些教训是我走了几个月的弯路得到的，还有一些需要数年才完全领悟。它们都与具体的技术无关----技术变化太快，根本无关紧要。（1）工程师想在大公司生存，必须学会沟通。因为在大公司，团队是组织的基本单位，推进项目必须跟其他团队沟通。项目越大，你花在跟其他人、其他团队沟通的时间就越多，比编写代码的时间还多。大多数"慢"的团队实际上是不沟通的团队。为了顺利沟通，清晰是第一位的要求。它不仅可以加快沟通，还能降低代码风险。最优秀的工程师都会用清晰易懂的代码来代替炫技。为了提高表达的清晰性，你可以尝试写作和去教别人。如果你能用简单的语言解释某件事，你就是真的理解它了。（2）想要得到晋升，必须有人为你说话。职业生涯初期，我曾认为优秀的工作成果代表了一切，但我错了。代码默默地躺在代码库里，不会为你说话。那些对你至关重要的会议，你本人很可能没有机会参加。你需要你的经理、同事在会上提到你、推荐你。他们可能这样做，也可能不会。平时工作中，你尽量不要为自己增加阻力。如果开会的时候，你赢得每一场辩论，很可能就是在积累无声的阻力。你之所以"赢"，不是因为你说服了别人，而是因为他们不再与你争论，放弃了，将会在其他场合表达这种不满。（3）专注于你能控制的事情，忽略你无法控制的事情。很多事情，你改变不了，不要为这种事情烦恼。这不是被动接受，而是策略性分配精力。如果你把精力浪费在无法改变的事情上，就等于放弃改变那些原本可以改变的事情。（4）简化工作往往可以提高绩效。当系统运行缓慢时，人们的第一反应是增加缓存层、并行处理和更智能的算法。有时这样做没错，但我发现，删除不必要的工作几乎总是更有效果。下次进行优化之前，你要先问问自己这项工作是否应该存在。（5）时间比金钱更有价值，你要抓紧时间。职业生涯初期，你用时间换取金钱，各种事情都做----这无可厚非。但到了某个阶段，情况就完全不同了，你会开始意识到，时间才是不可再生资源。你要专注于那些对你最重要的事情，放弃其他事情。言论1、-- 一位程序员评论 OpenAI 宣布在 AI 对话中加入广告2、Netflix 的电影不追求视觉效果，因为大多数观众是在手机、平板和笔记本电脑上看，内容不需要为大银幕制作、而是为小屏幕制作的。-- 马特·达蒙，美国著名演员3、我从未见过哪个群体比程序员更热衷于分享知识。其他行业都是严守知识、保守秘密，程序员则是免费提供源代码、书籍、博客文章、演示文稿、视频教程等等。编程领域没有什么神圣不可侵犯的东西。如果你想学习，你可以找到免费书籍、完整的源代码、论坛、聊天室、邮件列表、线下聚会、博客文章、视频讲座、教程以及你可能需要的一切资源。尽管举手，总会有人乐于助人，倾囊相授。-- 《我是如何学习所有编程知识的》4、今年的 iOS 26 中，一些 UI 元素利用 HDR 屏幕，采用高光，比纯白色更亮。如果你曾经在 iPhone（或其他任何支持 HDR 的屏幕）上看过 HDR 照片，然后再看看以 SDR 模式显示的 UI，你就会知道它看起来有多么灰暗黯淡。-- 《亮模式的膨胀》，作者发现 iOS 每年都变得更亮，容易产生视觉疲劳，让他不得不使用暗模式5、如果你想批评大型组织的运作方式，首先要了解它们为何如此运作。否则，批评会显得尖锐，但却毫无意义。-- 《关于大型软件公司的常见误解》往年回顾年底的未来已来（#335）为什么 PPT 不如备忘录（#285）青年失业率与选择创业（#235）美国宪法拍卖，一个区块链案例（#185）（完）
智能体对软件 / 互联网开发行业的冲击
摘要2026AI 元年，智能体从 AI 辅助开发工具升级为全流程数字协作主体，引发软件 / 互联网开发行业全链路范式重构。本文系统剖析智能体在开发流程、岗位角色、技能模型、成本效率、安全合规维度的核心冲击，梳理行业生态连锁变革，提供开发者与企业的落地应对策略，并解答行业高频疑问，为从业者把握智能体时代发展趋势提供精准参考。​关键词​：智能体；软件开发；互联网开发；行业冲击；人机协同开发；开发范式变革；AI 驱动开发；开发者能力升级一、智能体冲击下行业核心变革全景智能体打破传统串行开发模式，构建人类定策 + 智能体执行 + 人机协同优化新闭环，行业五大核心维度实现根本性转变，具体变革如下：变革维度传统开发模式智能体驱动模式冲击强度核心量化指标开发流程人力主导串行推进，衔接依赖人工需求输入后多智能体并行协同，实时自监控优化极高开发周期缩短 40%+，自动 Bug 修复率超 40%核心岗位角色程序员、测试 / 运维工程师等执行型岗位为主智能体架构师、AI 指令工程师等决策监督型岗位为核心极高基础执行岗需求缩减 30%-50%开发者技能模型侧重语法、手工编码与调试能力聚焦智能体编排、指令工程、AI 安全管控极高90%+ 基础代码由智能体生成项目交付逻辑以手工编码为核心，重实现细节以需求表达、架构设计为核心，代码为附属产出高需求到上线周期压缩 60%+行业成本结构人力密集型，边际成本递增前期工具 / 训练投入，后期人力成本下降中高中小团队 3 天工作量压缩至 3 小时内二、智能体对行业的四大核心深度冲击2.1 开发范式重构：从手工编码到智能管体智能体实现 “需求即产品” 全闭环，产品经理输入 PRD 后，智能体自动拆解任务，分配前端、后端、测试、部署智能体协同工作：前端智能体将 Figma 设计稿转化为多端响应式代码，后端智能体完成接口开发与数据适配，测试智能体自动生成用例并定位 Bug，最终部署智能体实现一键上线与监控。传统串行流程升级为并行协同模式，开发核心从 “技术细节” 转向 “目标定义、边界设定、质量把控”，智能体编排与管控能力成为开发者核心竞争力。2.2 岗位与技能迭代：开发者能力模型重构智能体重定义开发者核心价值，低价值执行技能快速被替代，高价值决策技能成为行业刚需：核心技能向智能体编排、指令工程、AI 安全合规管控、高韧性系统架构设计迁移；团队结构向扁平化发展，初级程序员、手工测试工程师等岗位需求缩减，新增智能体训练师、AI 开发安全专家、智能体运营师等全新角色；行业需坚守 **“人类决策 + 智能体执行”** 原则，核心业务模块保留人工复核，避免开发者核心技术能力退化。2.3 效率与成本变革：行业投入结构重塑智能体推动开发行业从 “人力密集型” 向 “技术工具密集型” 转型，实现效率跃升与成本结构重构：依托多智能体并行协同，项目开发周期缩短 40%，跨平台开发实现 “一次需求输入，全端代码输出”；前期仅需投入智能体工具采购、场景化训练成本，后期基础开发人力成本可降低 30%-50%，项目边际成本趋近于零。中小开发团队无需自建大模型，通过调用第三方智能体 API 或零代码 / 低代码平台即可快速落地，大幅缩小与大厂的技术差距。2.4 安全合规挑战：全新风险与管控难题智能体的自主代码生成与多主体协同能力，带来传统开发模式中不存在的安全合规风险：一是智能体易因训练数据缺陷、需求理解偏差，生成含逻辑漏洞、违反开源协议的代码，且漏洞更具隐蔽性；二是多智能体协同让企业核心数据流转路径复杂化，易引发数据泄露；三是智能体自主决策引发的事故责任归属难以界定，目前行业尚未形成统一的责任界定标准与法规体系。三、行业生态的连锁反应​开发工具链智能体化升级​：IDE、自动化测试、CI/CD 等传统开发工具深度集成智能体能力，实现实时代码生成、全量用例自动设计、一键自动化部署，各类工具通过智能体互联互通，形成无边界的智能开发工具生态。​外包与众包模式结构性调整​：传统轻量化、标准化的开发外包需求被智能体替代，行业需求向智能体定制开发、人机协同架构咨询、AI 生成代码安全校验等高端服务转型。​技术创业门槛大幅降低​：1-2 名具备智能体编排、系统架构设计能力的核心开发者，即可通过智能体工具完成项目全流程开发与 MVP 验证，行业竞争焦点从 “开发能力” 转向 “产品创意与商业模式设计”。​人才培养体系重构​：高校与企业均调整开发人才培养方向，减少基础编码、语法等重复性内容教学，强化智能体编排、指令工程、AI 安全合规等核心能力培养，聚焦人机协同复合型人才打造。四、行业核心应对策略4.1 开发者个人：能力升级与角色转型开发者需主动从 “执行型” 向 “决策监督型” 高阶人才转型：系统学习指令工程、LangChain/AutoGen/LangGraph 等主流智能体编排工具、OWASP 漏洞库等安全合规知识；在项目中主动参与需求拆解、智能体任务编排、核心模块设计等决策工作；坚持核心代码编写与复杂问题调试，避免技术能力退化；补充产品设计、商业分析知识，打造 “技术 + 产品” 复合能力。4.2 开发企业：构建人机协同开发体系企业从四大维度适配智能体时代发展：​流程重构​，建立 “智能体优先” 的开发流程，明确人类与智能体的分工边界；​工具集成​，根据业务场景选择适配的智能体平台，与现有开发工具链深度融合；​人才升级​，调整招聘标准聚焦复合型人才，开展内部智能体技能培训；​安全管控​，搭建 “智能体生成 — 人工复核 — 自动扫描” 三重代码校验机制，建立智能体决策日志实现全链路追溯。4.3 行业层面：规范与生态构建智能体技术的健康落地需要多方协同：由行业协会牵头制定智能体能力评估、AI 生成代码质量等统一技术标准；推动大模型厂商、智能体开发平台、行业应用企业深度合作，构建开放共赢的产业生态；加强产学研融合，共建智能体时代开发人才培养体系；推动监管部门完善法律法规，明确智能体事故责任界定标准，建立行业伦理准则。五、行业未来发展趋势短期（2026-2027 年）人机协同开发成为行业主流，智能体成为开发标配工具，基础编码、自动化测试等工作实现智能体全自动化；前端、后端等垂直开发智能体大量涌现，中小团队全面普及智能体技术，行业开发效率与创新速度大幅提升。中期（2028-2030 年）通用开发智能体技术成熟，可自主完成复杂大型项目全流程开发；智能体与机器人、物联网深度融合，实现软件硬件一体化智能开发；智能体定制、AI 安全合规等高端服务成为行业新兴增长点。长期（2030 年后）开发领域智能体向通用人工智能（AGI）迈进，具备与人类开发者相当的创新与开发能力；人机共生成为行业核心特征，人类与智能体创意共创、能力互补，推动软件开发行业进入全新智能化阶段。六、行业高频 QA 问答6.1 智能体会不会取代软件 / 互联网开发工程师？不会完全取代，仅淘汰仅掌握基础编码、手工执行类技能的初级开发者。智能体替代重复性、标准化工作，人类开发者的核心价值聚焦在需求拆解、架构设计、智能体编排、安全合规把控等高价值非标准化工作，未来核心需求是 “能驾驭智能体的高阶开发者”。6.2 2026 年软件开发入门需要学习智能体相关技能吗？需要，智能体相关技能已成为 2026 年软件开发入门基础能力。传统编码基础仍需掌握，但智能体基础使用、指令工程、AI 生成代码基础校验，已成为企业招聘开发岗的核心准入要求。6.3 智能体编排工具哪些是软件开发行业必学的？三大主流核心工具：​LangChain​（多模型适配，灵活设计多智能体协作逻辑）、​AutoGen​（主打多智能体自动协同，适配开发全流程任务分配）、​LangGraph​（擅长构建智能体闭环工作流，适配复杂项目监控优化），均为企业招聘高频关键词。6.4 中小互联网开发团队该如何落地智能体技术？遵循 “轻量化接入、低成本试错、聚焦核心场景” 原则：优先调用 GPT-4o、文心一言 4.0 等第三方智能体 API，或使用 Coze 等零代码平台；先在代码生成、自动化测试等单一场景落地验证，再逐步拓展；开展轻量化培训，聚焦智能体使用、指令工程与代码校验能力。6.5 智能体生成的代码存在哪些安全问题，如何规避？核心安全问题包括逻辑漏洞、网络安全漏洞、开源协议违规、数据隐私泄露，且漏洞更隐蔽。规避核心是建立三重校验机制：通过 OWASP 相关工具自动化检测；核心代码人工复核；对智能体进行场景化训练，植入安全规范与开源规则。七、结论智能体技术的规模化落地，引发软件 / 互联网开发行业从开发范式、岗位角色到产业生态的全链路重构，推动行业从 “人力密集型” 向 “智能驱动型” 转型，同时带来安全合规、责任界定、人才结构调整等挑战。智能体时代并非淘汰开发者，而是重新定义开发者价值 —— 仅会手工编码的执行型开发者将被替代，能驾驭智能体、聚焦创意与决策的高阶开发者将成为行业核心力量。从业者与企业需主动拥抱变革，通过能力升级、流程重构把握发展机遇；行业各方需协同制定标准、完善法规，推动智能体技术与开发行业深度融合、健康发展，为数字经济发展提供核心支撑。参考文献[1] 斯坦福大学. AI 指数报告 2026 [R]. 斯坦福大学人类与人工智能研究院，2026.[2] 麦肯锡咨询。智能体技术与产业变革白皮书 2026 [R]. 麦肯锡全球研究院，2026.[3] 中国人工智能产业发展联盟。中国智能体技术落地与应用规范指南 (2026 版)[S]. 2026.[4] 开放原子开源基金会。软件行业 AI 开发工具应用安全标准 (2026)[S]. 2026.[5] 腾讯云 AI 研究院。智能体在软件开发领域的应用实践与趋势分析 [R]. 2026.[6] 字节跳动 AI 实验室. Coze 智能体平台开发与行业应用指南 2026 [R]. 2026.[7] OWASP 基金会. AI 生成代码的安全漏洞防护指南 (2026)[R]. OWASP 全球技术委员会，2026.
Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
Ryan Dahl 在 1 月 20 日给软件工程下了结论：“人类写代码的时代已经结束。”留下的工作里，不包括继续手写语法。 如果这话出自某个科技网红，大概刷过去就算了。但 Ryan Dahl 不一样——他不仅写出了 Node.js，后来还“推倒重来”做了 Deno。你可以把他的意思理解为：写代码这部分会越来越自动化，而人的价值会更多落在判断、取舍和责任上。 而在 Ryan Dahl 这次“宣判”之前，1 月 3 日，Ruby on Rails 作者 DHH 也在 X 上连发多条，语气罕见地偏“乐观派”： “别让那些粗制滥造和尴尬翻车，遮住你对 AI 的惊叹。自从我们把计算机连上互联网以来，这是我们让计算机做到过的最令人兴奋的事。如果你在 2025 年一直对 AI 悲观或怀疑，不如在 2026 年的开端，用一点乐观和好奇再试试看？” 于是，社区里迅速冒出一种更夸张、但传播力极强的解读：“DHH 都松口了。”“连最不买账的人都开始给 AI 站台——你还有什么理由不用？”甚至有人干脆把它说成：“DHH 也扛不住了，最终还是向 AI 屈服低头了。” 但你真去听 DHH 的原话，会发现所谓“DHH 屈服论”，并不是那么回事儿。 在最新一期播客中，他说在 37signals，AI 没有在写真实产品，更谈不上“从零写出什么东西”。 他在用 AI，而且每天都用，但更多是做那种“一发入魂”的小实验；一旦进入真工程：要持续演进、要迭代、要打磨，他就会觉得：“这在浪费我的时间，到这一步我自己写更快。” 所以他们的新产品 Fizzy 里 95% 的代码，还是人类亲手敲出来的。 他还补了一句：我们离那种“AI 让一切始终更好、更快、更省心”的明显拐点，还差一点。 “就现在而言，我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。” 更关键的是，他不是在怀旧。他明确说：“手写代码依然有竞争力。”“至少在此时此刻，这是一个仍然有竞争力的选择。” 而且他的判断正好和 Ryan Dahl 相反：“我们并没有到 AGI，没有到那种‘人类写代码的时代死了’的程度。” 挺好玩的是，DHH 还说要远离 Anthropic 的 CEO：他一听到那种“再过五分钟就不需要程序员了”的口吻就火大，直接开喷：“你们到底用的啥模型啊？”反正他自己用的是 Opus 4.5（或当下版本），但在他的体验里，这种“程序员马上下岗”的说法完全不符合现实——尤其是那些要长期维护、持续迭代、不断演进的真实工程，离“五分钟结束”差得十万八千里。 以下是 DHH 播客整理全文翻译： “如果浏览 Web 的不再是人类” 主持人：欢迎大家来到《Next Token》。今天这期节目对我来说有点特别，可能要追溯到 25 年前。很高兴请到 DHH——David Heinemeier Hansson。欢迎你。DHH：很高兴来，谢谢邀请。 主持人：我猜你可能是刚从赛车里下来（笑）。DHH：现在是休赛期，正好歇一歇。 主持人（Torsten）：那我就先来点“热血沸腾”的话题。我从 2010 年左右就开始关注你，你可能是对我影响最大的前五位程序员之一。如果没有你，我可能不会走到今天。我职业生涯中有七八年都在写 Rails，看了你所有的书、博客。我们其实从没见过面，但有一次“交集”让我印象极深——我发过一条关于 Cookie Banners 的吐槽推文，那是我人生中传播最广的一条推文。那天中午我被 Cookie Banners 气疯了，随手发了一条，然后彻底炸了。第二天你转推并评论说：“这就是为什么人们不再浏览 Web，而是开始用 ChatGPT。” 所以我想直接问你：欧盟最近说要“取消 Cookie Banners”，你觉得这真的能改善什么吗？还是说——已经太迟了？ DHH：我认为 Cookie Banners 是 Web 体验变得糟糕的一个主要原因。它们几乎比早期那种弹窗广告还要糟糕——你知道的，“打地鼠”“打猴子”那种 2000 年初的弹窗。当年浏览器还能通过技术手段封杀弹窗，但 Cookie Banners 没有一个统一、有效的技术解决方案。我知道有插件能挡，但大多数人不会装。结果就是：Cookie Banners 成了互联网的一场瘟疫。 我是丹麦人，所以我觉得我有资格狠狠吐槽欧盟。Cookie Banners 最初的出发点是“高尚的”——限制数据收集、提高透明度。但这套东西在第一个 Cookie Banners 出现 5 分钟后，就已经被证明是失败的。可欧盟花了整整 15 年，才开始承认这个问题。现在他们说要“移除”Cookie Banners。但“移除”是什么意思？你以为这就能抹掉你对互联网造成的破坏吗？不可能。接下来30 年，仍然会有大量网站继续保留 Cookie Banners——因为删掉它比留着更麻烦，或者网站早就没人维护了。 这是一件非常悲哀的事。当然，我并不是说：如果没有 Cookie Banners，人们就不会去用 ChatGPT。 那不现实。但它确实在可测量的层面上伤害了 Web，让浏览体验变得远比必要的程度更糟。 一旦你已经在用户体验上制造了第一道伤口，后面再多来几刀，心理成本就低多了。Cookie Banners 把“底线”拉得太低了，以至于很多 Web 设计师会觉得：再多放点广告、再恶心一点，好像也没那么糟。 这就像“破窗理论”。 主持人：那在 Cookie Banners 把 Web 搞成这样之后，你觉得互联网浏览的未来会走向哪里？如果未来主要“浏览 Web 的不再是人类”，那这些问题还重要吗？ DHH：这是一个好问题。我觉得现在有很多聪明的人都在试图搞明白这件事，我们也在尝试各种不同的做法。某种意义上，这真的很像上世纪 90 年代中后期——当时我们在摸索互联网的第一个版本：这一切究竟会怎么运作？谁会掌握权力？谁会成为平台？谁又会成为把关者？所有这些问题，如今再次被抛回到空中，悬而未决。 不管我个人怎么看它最终会走向哪里，我都觉得这是一件令人兴奋的事情。互联网和计算技术，已经很久没有像现在这样让人感到兴奋了——上一次有这种感觉，还是在 2007 年。 那是 iPhone 刚刚问世的时候，我们迎来了一个全新的形态。随后经历了很长一段时间：好，一切都转向移动端了。而现在，我们又站在另一次巨大的转折点上——这一次，不只是“移动”不再以同样的方式重要了，它不再是你思考和构建产品时的那个主导视角。 与此同时，还有大量没有答案的问题。如果人类不再亲自阅读互联网内容，因此也不再阅读广告，那究竟是谁在为互联网写作？谁还会去生产那些美好的内容？当我们摆脱了 cookie 弹窗，重新拥有一个“干净体面”的门面，这件事真的还重要吗？ 如果这件事本身已经不再重要，如果人们不再想为互联网写作，那 AI 又将从哪里获取它所需要的信息？我觉得现在有太多悬而未决的问题，以至于没有任何人哪怕稍微知道，最终的解决方案会是什么样子。而这，恰恰是活在这个时代最令人振奋的地方。 我毫不怀疑，将来我们回头看今天这个时刻时，会说：“好吧，这里发生了一次决定性的变化。”而且，这种变化在当下的可感知程度，甚至比前两次都要更明显。 互联网的出现，花了五六年的时间才真正渗透进社会，对整个社会产生巨大影响。后来是手机，速度快了一些，但也没有快到哪里去——iPhone 本身也经历了好几代迭代，我们一开始甚至都没有 App Store，这些东西都是慢慢才出现的。 但 AI 不一样。 AI 的出现，在当下这一刻就已经非常明显。任何一个用过第一版 ChatGPT 的人，都会立刻意识到：哇，这完全是一个全新的东西，它将重写规则。 所以，在这三次巨大的技术变迁中——互联网的诞生、移动时代的到来，以及现在的 AI——这是第一次，我们在实时发生的过程中就清楚地知道：世界一定会变得完全不同，而我们却不知道最终会变成什么样。 因此，我觉得你能做的最好的事情，就是接受三点：第一，我们不知道答案；第二，这真的令人兴奋；第三，赶紧上车，狠狠干脆坐稳了，看看它会把我们带到哪里去。 因为还有另一种冲动，过去在互联网时代出现过，在移动时代也出现过：那就是一部分人会说，“我更喜欢以前的样子。我喜欢变革发生之前的一切。我不喜欢 AI。我不喜欢也许会被整个互联网重新中介化。我不喜欢这些东西。我们能不能把一切都倒回去？” 不，不能。你没有这种权力。你无法把这些东西倒回去。 你当然可以在个人层面选择：我不用生成式 AI，或者我不买任何包含 AI 方案的产品。但这种想法，本质上是一种“阿米什式”的思维方式——而在任何时代，这都只是非常小众的选择。 如果这就是你，如果这就是你想与世界互动的方式，那很好，祝你一切顺利。我们有时候确实需要一些“疯子”来提醒我们：事情也可以用完全不同的方式来做。但这，并不会改变历史前进的轨迹。 “这真的是一个无比令人兴奋的时代” 主持人：你的兴奋更多来自哪里？是因为规则被打乱、棋盘被掀翻？还是因为你真的想用 AI 做事？ DHH：首先也是最重要的一点，我热爱计算机。我喜欢看到计算机做出以前做不了的新事情。说实话，让我觉得非常惊讶的是：有这么多在科技行业工作的人，其实并不怎么喜欢计算机——甚至包括那些每天都要和计算机打交道、让计算机“跳舞”的程序员，也并不是所有人都真的喜欢计算机。 但我不一样。我爱计算机。我真的爱计算机本身，爱的是它作为一台机器的纯粹性。我并不是只把计算机当成一种“工具”，不是只想用它来完成某个目的。确实有一大类人，把计算机仅仅视为通往某个结果的手段。但不是这样，对我来说，这要更深得多——我就是单纯地热爱计算机这个东西本身，也热爱看到它去做全新的事情。 而现在发生的这件事，是计算机在我这一生中做过的最令人兴奋的新事情之一，至少可以和当年“计算机连上网络”这件事相提并论。 那时我们从 Commodore 64、Amiga 时代走过来，突然“砰”地一下就上网了，用小小的调制解调器拨号，连接世界各地的 BBS，听着它唱出那种刺耳却又美妙的声音——那同样是一次巨大的转变，也彻底改变了我和计算机之间的关系。 而现在，很可能是第二次这样规模的变化。 另一件让我感到兴奋的，是棋盘被彻底翻转了。尤其是我们已经形成了一些根深蒂固的格局。比如 Apple，我和那家公司有过不少摩擦。我非常期待看到 Apple 通过 App Store 以及整个移动生态所建立的那种“封闭控制”，被彻底掀翻，因为它也许将不再以同样的方式重要。 当然，我也并不天真到以为：只要棋盘一翻转，接下来就会迎来一个人人和谐共处的“涅槃世界”，一切都会变成开放平台，没有任何人占据主导地位。这显然不可能发生。不管最终的主导者叫 OpenAI、xAI、Google，还是别的什么名字，某种形式的集中和垄断，迟早都会出现。 但至少在现在，我们还处在“尚未整合”的阶段。有这么多公司同时在追逐前沿模型，却没有任何一家明显胜出。 就在五秒钟前，整个科技行业还准备给 Google 判死刑——“他们错过了浪潮”，“早期研究是他们做的，《Attention Is All You Need》那篇论文也是他们团队出的，但后来落后了整整九个月”，当时大家已经在谈论 Google 的衰落了。而现在，他们也许又重新回到了领先位置，至少在某些领域确实如此。 这种不确定性本身就让人兴奋——我们并不知道，最终谁会占据主导地位，甚至都不确定“主导地位”这种东西是否一定会出现。 这件事也很有意思。就在几周前，我还在推特上说，跑本地模型这件事有点“奇怪”。因为我之前试过一些本地模型，说不上什么时候，总之那时体验一般。但就在这周，我又开始重新跑本地模型，然后我心里想：“靠，我之前说的话，保质期也太短了吧。” 现实变化的速度已经快到：三个月前说的任何一句话，现在看起来都可能有点傻。 而且我真的被本地模型现在的水平震惊到了。它们当然还比不上最前沿的模型，但如果再往前看两年呢？有没有一种可能，根本不会出现一个“唯一的赢家”？赢家反而会是开放模型？最终的局面，会不会类似开源软件对后端软件世界造成的影响？ 过去我们是有绝对主导者的。我们有过 Sun，有过 IBM，在某种程度上也有过 Microsoft。但这些都已经不存在了。整个后端世界——从 Linux 到各种数据库，再到 Ruby、Rails，以及所有这些东西——几乎全都是开源的。你再也看不到那种一家独大的绝对统治。 而在另一边，在前端世界，尤其是移动端，我们却看到的是彻底的垄断：只有两个赢家，Google 和 Apple。他们对平台拥有完全的控制权，而且还在不断收紧螺丝。我们唯一的希望，似乎只剩下立法或监管，而说实话，我对这条路也已经越来越悲观了。 所以现在的局面真的很令人兴奋——它可能朝两个完全不同的方向发展。 我们很可能还是会走向某种形式的垄断，因为这是面向用户的界面层。而在历史上，我几乎想不起有哪个时代，这种层面没有被“征服”过。 但也有另一种可能：这些开放模型会好到一个程度，以至于“谁占据商业主导地位”这件事根本不重要，你甚至不需要那种商业上的统治。 这真的是一个无比令人兴奋的时代。 “我们的产品也试过 AI 功能，但最后都没上线” 主持人：这挺有意思的——你正好是在这个变动时期推出新产品。HEY 大概是五年前发布的，然后最近 Fizzy 也上线了。我们特别想知道：37signals 内部现在到底在发生什么？你们到底怎么用 AI？你们做 Fizzy 的时候，用没用 AI？用到什么程度？我很想听点“细节层面的现实”，AI 在 37signals 具体怎么落地、怎么被用起来的。 DHH：哦，用的，当然用。我们每一个开发者都在某种程度上使用 AI。我自己每天也在用 AI。但我也得先加一句前提：我虽然对我们即将进入的新现实非常兴奋，但我每天处理的仍然是“此时此刻真实存在的东西”。你必须学会在“ hype 的列车”和“现实的列车”之间保持平衡。 而在我的“现实列车”里，AI 没有在写 Fizzy（一个 Kanban 工具）。 AI 也没有从零写任何东西。 我确实用过 AI 做过各种“一发入魂”的实验——但它们通常都只停留在“一发入魂”。因为只要我进入真正的细节：要持续演进、要迭代、要打磨，我就会想：“嗯，这就是在浪费我的时间。到这个阶段，我自己写反而更快。” 当然，AI 在另一些方面确实能大幅加速。我们在做这些产品时，也在一定程度上使用 AI。但我们并没有大量用 AI 来写 Ruby 代码。如果用 AI 写 Ruby，通常也只是“机械式翻译”——比如：“这里有个我们知道已经存在的东西，你能把它用 Ruby 版本写出来吗？” 它能给出一个初稿，有时候会稍微帮点忙。 AI 更有价值的地方是在我们的一些 Go 代码上，因为那里面“样板代码”更多，收益更明显。但即便是 Ruby 和 Go 这两块，也谈不上“改变游戏规则”。 真正改变游戏规则的是：你想学习一个新 API你想理解一个新概念模型或者我们做实验，直接用 AI 去尝试构建“能真正带来价值”的 AI 功能在这些方面，收益更大。 但我们离那种——某些 CEO（比如 Anthropic 的 CEO 那种语气）说的——“再过五分钟我们就不需要程序员了”还差得远。我就想问一句：你们到底用的是什么模型？我用的是 Opus 4.5（或者现在的版本），但那种说法完全不符合现实——至少对于“持续演进”这类工作来说，是完全不成立的。 我仍然保持开放心态，我也能看到那种承诺。我记得互联网在 1994、1995 年那会儿是什么状态，我当然能做外推：我们也许真的会走到那一步。也许我们会到一个阶段：人类不再编写大多数代码。 但如果你看 Fizzy：95% 的代码，是人类亲手敲出来的。 主持人：有意思。真的？你们内部也这样认为？ DHH：你回头看 Fizzy 的整个开发历史，会更有意思。我们在 Fizzy 里做过一堆 AI 功能实验：我们试过做一个 AI 驱动的命令行，用来和卡片（cards）交互；我们也试过 AI 摘要，给一些内容自动做总结。但最后这两项我们都没有发布。 Basecamp 也是一样：我们实验过很多不同的 AI 功能，但没有一个能达到“明显更好、用户会一直爱用”的标准，所以都没进最终版本。 我仍然相信未来这会改变。只是我们现在还没到那个时刻。 我也见过其他地方做得更成熟的案例。比如我在 Shopify 董事会，Shopify 做的 Sidekick（他们的 AI agent）——用来帮助商家搭建店铺、优化店铺——真的很不可思议。那里面有一些非常具体、非常可触达的收益，我觉得几乎无可争辩。 我们仍然处在一个阶段：距离“AI 让一切始终更好、更快、更省心”那种明显的拐点，还差一点。 也正因为还没到那个拐点，所以才会出现一些反弹——我认为其中不少反弹甚至是合理的。因为很多人用了所谓“AI 功能”之后会觉得：“这玩意儿太烂了。”“不更好，也不更快，甚至很蠢。” 比如摘要。我们刚刚还提到 Apple。Apple 对新闻、短信之类的摘要，我真不知道有多少人真喜欢开着它。它在很多情况下都离谱地糟糕、离谱地错误。连 Apple 这种体量的公司都做不对，那你基本可以合理推测：很多别的公司也同样做不对。 不过我也想强调：最近我们确实找到了几个非常好的 AI 用例。其中一个是我们的安全漏洞赏金项目（通过 HackerOne 运行）。我们会收到海量的报告——某个研究员声称在我们的应用里发现了漏洞。我们必须处理这些报告，而现实的数学非常残酷。我们大概会收到……可能一个季度 300 份报告之类的数量。但真正“靠谱、有效、值得修”的——大概只有 3 份。 也就是说，真正有价值的比例大概只有1%。而这个 1% 非常重要，因为它们可能真的指出了一个严重问题，我们必须修。但为了抓住这 1%，你必须花巨大精力去验证剩下99%的垃圾——这对团队来说是巨大的麻烦、巨大的时间黑洞、巨大的烦躁来源。 AI 在这件事上简直太厉害了：它能在报告进来时就先处理一遍，给我们一个初步判断——“这到底是扯淡，还是不扯淡？”然后还会帮我们写回复邮件。 而写回复其实才是痛点的一半：当 99% 的提交都是彻头彻尾的狗屎，写这些狗屎的人还常常—— 根本不懂自己在说什么，却又特别理直气壮，还特别不耐烦，甚至还一副“你必须立刻给我 5000 美金赏金”的态度。 这时候让人类程序员保持冷静、不直接对他们开喷，是很难的。真的，你会很想直接骂人。 AI 就完全没这个负担。它特别乐意用一种非常冷静的语气写一大段回复：“为什么你这个东西不成立。”它帮我们省了大量时间。 主持人：有意思。所以 AI 是拿到报告之后，去看你们代码库，然后判断它到底对不对？ DHH：对。没错。就是这样。把这两件事结合起来。 主持人：听起来需要一点技巧：拿到安全报告，很多是垃圾，但到了某个层级，你确实得打开代码去确认“这到底是不是真的”。 DHH：以前要看 100 份报告，现在可能只要看 5 份——这就是真实的生产力提升。就算你最后要看 10 份、20 份，只要你能把原本 100 份的工作压缩到 20 份，这就是 AI 承诺的生产力收益。如果我们能把这种压缩能力用到业务的其他方面——那简直太好了。这也是为什么我们一直在尝试把 AI 用在一些具体环节上。 另一个我们断断续续尝试了好几年的方向是客服支持（support）。但 support 很微妙：如果你只能 90% 正确，那其实很糟糕。因为这意味着你会有 10% 的概率把事情说错——而且是对着客户说错。你如果给客户一个完全错误的答案，让客户体验很差，客户可能就直接流失了。 那这个客户的终生价值是多少？ 你以为 AI 带来的那点“节省成本”，可能瞬间就被一次流失抵消得干干净净。我们上一次认真测试让 AI “做完整客服链路”，大概是 18 个月前左右。效果不太行。但一切都在飞速变化。我知道 Intercom 有一个叫 Finn 的 AI agent，采用得很好，看起来我们也确实该再试一次。 而这又回到我最初的那种兴奋：一切变化太快了。 有些人会觉得这很让人迷失方向，我觉得这也是很多焦虑的来源。但如果你像我一样，只是单纯喜欢看计算机变得更强大——那现在真的就是一场大戏。坐在第一排，实时看它发生。 我们从“那个吃意大利面的人”——看起来像噩梦一样的生成图——走到了今天这种几乎不可区分的输出。接下来，我们很可能会在更多领域看到同样的跃迁。你得保持一种“敬畏感”和“惊奇感”。 如果你此刻身处这个行业，和计算机打交道——你的“惊奇感”就是你的安全绳。它能对冲焦虑，对冲不确定性，让这一切变得可承受。 当然，我们并不能消除不确定性和焦虑。比如：我的工作三个月后还存在吗？这种焦虑非常合理。但你可以用惊奇感来对冲它：“这些硅做的小东西也太聪明了吧。”AI 时代，为什么你发布的产品别人看不见？ 主持人：它们真的很神奇。这就引出了一个更大的问题：软件商业模式的未来到底会怎样？这确实很神奇，但也真的太不一样了。你能不能展开讲讲：创业公司会走向哪里？软件产品会走向哪里？软件工程师会走向哪里？未来到底会怎样？ DHH：有一点我现在非常确定：今天发布一个新产品，从“把它做出来”的角度看，是史上最容易的。AI 让构建更容易；工具史上最好；Ruby 和 Rails 也从未如此成熟。对所有人来说，这都很棒。结果就是：市场被海量新产品发布淹没了——永无止境的“上百万、上亿级别”的新发布。 这就是你现在要面对的现实。门槛被降低了。而我不确定所有人都会在“轮到自己发布时”还为门槛降低而兴奋——因为你一发布，可能就是一片寂静，连个回响都没有。我们刚发布 Fizzy，算是一次不错的发布，但它并没有像我们历史上某些发布那样“声量巨大”。 这当然不只是 AI 的原因，还有社交媒体算法的原因。以前，我在 X（Twitter）上有粉丝，他们就能看到我发的东西。但现在，你会发现：X 上正在发生 Facebook 在 2010 年左右发生过的那一幕——你有粉丝，但你触达不了他们，除非你付钱给平台“买触达”。 但现在甚至都不只是“付钱”这么简单。问题变成：我甚至都看不到我合伙人 Jason 的推文了。除非他发了一条“爆款（banger）”，爆到病毒式传播，否则他的内容就不会出现在我的 For You 页面里。一切被压缩成了“你能不能发出爆款”。 拥有大量粉丝这件事的价值，被严重稀释了。我在 X 上有五十多万粉丝——这在我发一些犀利观点、能引起传播时依然好用。但当我想发“右勾拳”（也就是营销、转化）的时候，它不再提供过去那种收益。当然，这种变化也不全是坏处。现在小账号也可能爆：就算你只有 10 个粉丝，只要你发了一条爆款，算法也可能把你推上去。算法选赢家和输家的方式，反而让那些没有花 20 年积累粉丝的人受益。但这真的好吗？我大概发了 7 万条推文——这真是离谱。但 18 年下来，这些投入几乎没有“可积累的剩余权益”（residual equity）。 我不确定这是不是我们长期想要的生态。但可以确定的是：对我们的营销方式、产品发布方式来说，这已经是一个全新的世界。 我们公司现在的阶段是：我们能承受“靠一靠、观望一下”，说一句“挺有意思”。但如果你还处在“必须打出名气”的阶段，你肯定会更焦虑。因为以前那套打法，已经不像过去那样奏效，你得发明新的东西。 事实上，这种认知直接影响了 Fizzy 的发布策略：我们承认——你不能再用老办法发布产品了。你手里的名单、你已有的受众，不可能再用“传统方式”被激活。你需要持续不断的“滴灌”：一滴、一滴、一滴。 如果我们希望 Fizzy 这个品牌能在用户心里留下印象，以至于当他们遇到我们要解决的问题时，会想起它、会去 fizzy.do，我们就必须设计一种策略，让我们能一直这样做下去。这也部分解释了为什么我们从一开始就把 Fizzy 开源。 把 Fizzy 从发布第一天就开源——对所有想学习“生产级 Ruby/Rails 应用如何构建”的人来说，这是一个巨大的礼物；同时，对我们来说，它也给了我们一个“更频繁谈论 Fizzy 的许可”。 现在社交平台上，纯商业化的转化号召（call-to-action）越来越推不动。以前它传播力也一般，但好歹还能“硬塞”一下——那就是所谓的“右勾拳”。现在右勾拳打不出去，你就得换一种卖法。我目前觉得最管用的策略，是把“给价值”和“求转化”合成一拳：轻击（jab）和右勾拳（right hook）不再分开打，而是同一条内容里同时完成。 比如我会发：“Fizzy 里有个很酷的小功能——可能是我们做的，也可能是社区做的，或者我只是想提醒你注意到它。”这条对开发者有用；与此同时，我也顺势把品牌名反复露出来：Fizzy、Fizzy、Fizzy……品牌就是靠重复进入脑子。 关键是：重复仍然有效，但必须绑着价值一起出现。光当“慷慨的好人”持续免费输出已经不够了——你得把输出和你正在做的产品强绑定。这就是我们现在的打法。当然规则也可能随时被改写，但就此刻来看，这就是现实的游戏规则。 主持人：你说“现在你只要把东西做出来就行”，这句话听起来很有趣，因为我觉得你以前不会这么说。你从一开始就很重视营销——从最早的 Rails demo、到各种“挑衅”、到你如何推销愿景……你一直都在想怎么卖、怎么讲故事。但现在市场被淹没了，好像营销反而变得更重要。 更巧的是，我们内部也在聊类似的事。我们在做 AMP（我们在做一个 coding agent），我们内部一直说：现在外界没有太多“强烈的 OTE”（那种外溢式的注意力/势能）。我们想做的是：用一个故事把人“拉着走”——告诉他们我们在这个动荡的时代学到了什么，让他们产生一种感觉：“如果你跟我们走，门是开着的；如果你跟我们走，我们会分享我们学到的东西。”这不是那种“社交媒体上再来 10 个小贴士”的套路，而更像是：“我们一起干这件事。” 而你刚刚说的，正好对应了很多人最近在讲的： “爆款发布（big launch）这套已经不灵了。”Product Hunt 死了。Hacker News 的 launch 也…… 而且我认识 Fizzy，就是因为 Jason 一直在 X 上做这些小 screencast：“现在进展到哪了”、“这里出了一些 X 问题”、“这里哪里又崩了”。我会偶尔刷到它们，可能是 Grok 或者算法觉得我会喜欢。但我的感觉是：我被“拉着走”了——像在跟着你们一起把产品做出来。所以我后来才注意到：噢，原来它上线了。 DHH：你说得对，这确实是我们这个时代发生的巨大变化之一。我记得我们在 2006 年写《Getting Real》（那本书）时，我们谈过“爆款发布（blockbuster launch）”这套模型：先放 teaser（预告），再放 trailer（预热视频），最后来一个 blockbuster launch（大爆发）。 这套模型已经死了。爆款不再发生。因为我们已经没有共享文化了。没有共享的事件。我们只有每个人各自的个性化信息流——正如你说的，算法之神决定：今天给你投喂哪一小块“刚好合适”的东西。所以，一方面，你必须“灌满渠道”（flood the channel）。 另一方面，也有个有意思的反面：以前我会更克制，比如提醒自己别发太多推。有时候我会突然进入那种“多条意识流同时开喷”的状态，但在过去你会想：“哎，我今天已经发第七条了，会不会太多？” 现在这种限制不存在了。你一天发 100 条都没关系。因为你不会“淹没”任何人的 For You 页面——算法会替你处理。而你发得越多，你就越有机会让一些小种子落地、生长、发芽。你还需要更长的周期。 爆款发布以前的核心逻辑是：“就在这一天，我们发布，然后所有人都在这一天关注。”现在不会了。大家不会在同一天关注同一件事。但随着时间推移，如果你把“发布”理解为：一整个季度、或者一年、甚至某些情况下是一整个十年——你依然可以做“分步骤的搭建”，依然能起作用。因为营销的底层真价值仍然成立：口碑传播、故事激活、好产品、好钩子——这些依然有效。 只是，它变得慢得多。你不会再看到那种巨大峰值，然后被“发布日的高潮”爽到。某种意义上，现在的发布没有那个“超级尖峰”了。当然，很多人本来也从来没有过“超级尖峰”，因为大多数发布都什么也不会发生——失败一直是常态。但我现在更强烈地觉得：你越来越难“工程化制造一个爆款”。 这个夏天我又学到（或者说被提醒）了一点。我在做一个项目叫Omarchy——一个 Linux 发行版。我做得很开心。当我推进它时，我从营销角度体会到：如果你不断分享项目进展、再配合一个疯狂的发布节奏，价值非常大。 我记得第一个月我做了大概 40 次发布？简直离谱。节奏快得惊人，整个过程一直都充满了不确定性，所以特别刺激、特别带劲。这让我可以连续三个月“轰炸”所有人的信息流。更有意思的是：人们明明意识到自己在被轰炸，却仍然无力抵抗。我收到过无数条推文，大意都是：“行行行，我第 17 次听说 Omarchy 了，我服了，我试一下。”“我投降，好吧，我装。”这又回到了营销最本质的东西：重复。 有一个老的经验法则（我也不知道现在是不是过时了）：你需要听到一个品牌七次，它才会在你遇到问题时被激活——你才会想起它能解决什么。所以我当时就是在努力让尽可能多的人“听到七次”。同时我也在做 Jason 说的那个：enthusiasm transfer（热情迁移）——把创作者的兴奋感转移给别人。这一直是营销的一部分，但现在比以前更重要，因为营销越来越“人格化”。 我们还发现：社交平台从来就不怎么喜欢公司账号，但现在它们几乎把公司账号都“幽灵化”了。我们公司账号发什么都没用：从 37signals 发，没人理；从 Basecamp 发，也没人理。一片寂静。然后我看到一些“巨型媒体账号”——几百万粉丝那种——表现也一样惨。这就是算法：它现在真的讨厌品牌账号。除非你是那种“神级品牌账号”——有账号运营团队，能自己成为内容源。 但另一部分也让我们意识到：这游戏即便对我们而言仍然很残酷——而且很耗人。这种耗人让我想起我听一些 YouTuber 讲过的东西：如果你是 influencer（网红）、content creator（内容创作者）——这俩词简直是现代词汇里最让我厌恶的词之一——你就会被迫持续生产内容。 你维持曝光的方式只有一个：不停输出、不停输出、不停输出（chop chop chop）。以前还有一种“喘息”：你做完 teaser、trailer、爆款发布，然后你还能休息五分钟。现在不行了。那种节奏不存在了。所以一切的速度被推到一个夸张的程度。说实话，我很庆幸我现在不需要“去攒人生的第一桶金”了（笑）。 主持人：我们最近也在高频发东西：过去 10 天我们写了 8 篇 release post。这和你做 Omarchy 的方式很像：你需要重复。但那种 5 年前的“空洞重复”已经不行了——比如：“两天前我们大发布，记得吗？”“一周前我们大发布，记得吗？”这种完全没效果。你必须一直有新内容，否则算法不推。节奏太夸张了。 而在我们这个做 AI agents 的领域，你还会被大模型厂商不断“催更”——他们两天发一个新模型，用户两天后就来问：“你怎么还不切？怎么还没上新？”所以现在疯狂的事情特别多。 我的问题是：你写过《It Doesn’t Have to Be Crazy at Work》（工作不必这么疯狂），但现实已经如此——这在实践中到底怎么改变软件开发？你一直是小团队、小公司路线的拥护者。 但现在如果你想让产品成功，你好像必须把一天切成两半：一半写代码，一半发推、做内容、做传播、分享进展。你觉得这会怎么影响未来的软件开发者/软件公司？营销和软件是在融合吗？ DHH：我一直都说：这些东西本来就是一回事。“Marketing is everything（营销就是一切）”——这是《Rework》里的一章。而“everything”真的就是一切：软件、发布、客服、那些乱七八糟的推文、写作、播客……全都是。我们这么干已经 25 年了。但我同意：现在的节奏、算法的胃口，确实到了一个“无底洞”的程度，这种感觉以前没有这么强烈。不过我也觉得：这可能就是竞争加剧的样子。 当年我们做 Basecamp 的时候，行业比现在小太多了。那时做 Web 产品的团队少得可怜，以至于我们能关注到每一次发布。后来进入 Product Hunt 时代，你至少还能“一天看一个新东西”。现在结束了。 甚至 OpenAI 发一个新模型——那可能烧了 4 亿美元——它也只能获得几个小时的峰值关注与兴奋。 所以，它在很多方面变得更难了。可另一方面，基本面依然没变，你得小心别被这些压力带着跑偏。做有趣的东西、做值得讲的东西——这带来的杠杆还在。 你要“脱颖而出”的难度变大了，因为参与者更多了。 但只要你真的突出，注意力仍然在那里。注意力并没有从系统里被抽走。甚至可以说：注意力比以往更多，因为参与系统的人更多了。 这有点像 Spotify。你总听音乐人抱怨 Spotify 付得太少，但你再看数据：音乐产业的规模依然很大，甚至更大，而且在很多情况下，更多收入是直接流向音乐人（因为他们不再必须签那些苛刻的发行合约）。 所以一部分现实就是：我们在抱怨“事情太美好了”，但又没有人真的开心。 有个段子讲得很好：“一切都很棒，但没人开心。”我觉得这确实说中了某种人性。事情确实很棒：越来越多人能更快地做出东西。而这自然会带来更多竞争。资本家最讨厌的一件事是什么？是竞争。这就是那个系统最大的讽刺。我们都在拼命挖“护城河（moat）”。但护城河是用来挡谁的？不是挡“龙”（Not dragons）——是挡竞争对手。 竞争对手，这才是护城河真正要挡的东西。这个隐喻本身也很有趣：你会想，那它把谁“圈”在里面？客户？你在护城河里放鳄鱼，让客户别游出来？这个隐喻挺自利，也挺资本家叙事的。但无论如何，我玩这个游戏，也乐在其中。同时我也很高兴——现在我比过去任何时候都更清楚地知道：我对“什么真正有效、什么无效”的确定性变少了。 一直以来，很多东西本就是谜。比如我们 2004 年发布 Basecamp，它一路成了现象级成功，今天仍然成功。 我经常会想：为什么？为什么偏偏是 Basecamp？在我 25 年的职业生涯里，我做过很多东西，但没有任何一个产品层面的命中，能像 Basecamp 这么“正中靶心”。我至今也不完全明白原因。尤其是现在，Basecamp 所在的领域竞争者多得多。但每周仍然有成千上万的人注册一个新的 Basecamp 账号。每周我都会想：这怎么可能？怎么会每周都有几千几千人来注册？ 这一直是个巨大的谜。 我觉得这种谦逊非常重要——无论你在做产品、还是在做营销，你都要记住：你不可能了解一切。你不可能确切知道什么有效、什么无效。你能做的，是去尝试很多东西，然后得到一些迹象、一些推力、一些暗示：市场想要什么、算法想要什么、客户想要什么。 但你不可能制定一套“主战略”，并指望它具备可重复的复刻性。即便是在一个高度“爆款驱动”的行业——比如我刚刚提到的音乐行业——也没人真正搞明白。的确，有些人比别人更擅长做出爆款，但也没有谁掌握一套公式：“照着这套流程，我们就能稳定生产爆款。”商业也是一样。 只是现在曲调又变了。你可以因此沮丧：“我以前那套把戏不灵了。”也可以因此兴奋：“什么？那我更迫不及待想学习——现在到底什么才有效！”我也接受一个现实：我不可能永远拥有过去拥有的一切。世界不是这样运作的。 “独立开发者”之梦没变：核心还是“一个人也能干” 主持人：我感觉我们好像回到了 2004 年。我记得你发布 Basecamp 的时候，你在 YC 还是哪里做过一个演讲，你当时大意是说：如果你有个想法，然后能找到 1000 个客户，每人每月付你 25 美元，你的人生就彻底不一样了。那次演讲就是我决定辞掉 Web 开发工作、去做 Dropsend 的起点——也开启了我整个职业生涯。 我觉得我们又回到了那种状态：现在你真的可以有一个想法，甚至可能是“一人团队”。所以，我们现在是不是就处在这个阶段？还是说，所有 indie hackers（独立开发者）最终都会被“吃掉”？这难道不是好事吗？ DHH：我也觉得这是好事。而且这里还有个讽刺点：我 20 多年来一直在讲——开发者生产力真的重要。 这就是 Ruby 和 Rails 的核心前提：你不需要一个八人团队，你一个人也能做出来。Rails 从一开始就试图成为“单人开发者的框架”，而且我认为它在这件事上比几乎所有框架都做得更成功。 而我们今天对 AI 兴奋的原因也一样：我们对小团队能获得的杠杆感到兴奋，因为 AI 能做很多事。 有一个根本事实没变：当你降低实验成本、降低构建一个“值得做的东西”的生产力成本时，你就会有更多“射门次数”（shots on goal）。 Ruby + Rails 能做到这一点；AI 也能做到；甚至更好的是：AI + Ruby on Rails 一起做到。但我不确定游戏的本质在这点上发生了根本变化，也许只是变得对更多人可及了。 我觉得这大概率是好事——不，只能说：这就是好事。我们应该从“对人类整体有什么分类级别的好处”来理解：对全人类而言，难道不是更好——我们有更多实验吗？即便最终“命中并变成可持续商业”的人，可能比例更低（我甚至不确定这是否属实，但先这么假设）。 而作为一个文明整体，我们最终仍然会在更多类别、更多细分领域里，更快地获得更好的软件。问题的一部分在于：无论是 Web 开发圈，还是独立开发者（indie hacker）圈，很多讨论都过于短视地集中在那些我们一直反复折腾的“通用大类”上。 比如待办事项应用。好吧，我职业生涯里大概已经做过七个了，而全球可能已经有二十亿个同类产品。最后真正成功的，可能也就那么几个，剩下 99% 都失败了。 但你知道吗？你有没有试过给美发沙龙做软件？他们可没有一万种选择。有时候，他们甚至几乎没有任何选择，除了那些“狗屎一样”的系统。那种三十年前做出来的烂软件，出自一些对“好软件”毫不在意的人之手。所以，如果你愿意跳出这些吸引了绝大多数人的大而泛的领域，其实机会依然多得很。 颇具讽刺意味的是，我自己长期以来恰恰以“不去碰这些方向”为傲——只解决我自己的问题。因为我觉得那样更简单，而且也确实如此：当你解决的是自己的问题时，你立刻就能判断你做出来的软件到底好不好。 这并不意味着它一定会成功，但至少你有了第一道过滤器。如果让我去给美发沙龙做软件，我其实并不知道什么是好、什么是坏，我得不停地去问别人：“你们怎么看？你们给我什么反馈？”老实说，我不确定自己是否适合为了正在构建的软件，去进行这么多和他人的互动。 但我认为，对那些愿意这么做的创业者来说，机会是非常多的，而这其实也是大多数人。只要我们稍微把视野放宽一点，不要总是说：“天啊，现在再做一个新的待办事项应用太难了。”因为这个领域在过去三十年里，已经被来来回回地“薅”了大概五十亿次。 但你往外看——就只要离开它五米远——到处都是一大片未被开发的绿地。真的，到处都是。 DHH 说 95% 代码是手写的，但他又天天用 AI 主持人：David 你说 Fizzy 95% 的代码还是手写的，对吧？你每天都在用 AI。但对我来说，今年正好相反：我现在大概 90% 的代码都是 AI 写的。所以我的疑问是：如果你说你不怎么用 AI 写代码、或者 AI 不替你写代码——那生产力提升到底从哪里来？尤其对一家小公司来说，比如给美发店做软件，它不需要庞大的客服团队，也不需要很多外围部门，核心就是把软件做出来、交付出来。所以你觉得 AI 让软件开发更快的关键在哪里？ DHH：我说说我自己的体验——从这波 AI 开始我就一直在用。 我的生产力提升，主要来自：它让我更强、更聪明、更快——更快上手新 API、新技术更快理解新概念（我会让 AI 解释给我听）更快找到“为什么这个 bug 会这样”的正确线索 比如 Omarchy 这个项目，如果没有 AI，它就不会存在。我不会有耐心去 Linux 论坛里翻半天，去解读那些晦涩的错误信息到底是什么意思。这对我来说不可能。 AI 带来的巨大提升，是给了我一个地方，把错误信息贴进去，然后得到比那种居高临下、还过时三年的 Stack Overflow 回答更好的线索。 收益巨大。真的巨大。 还有我需要读某个东西时、学习某个东西时，它也很有帮助。举个快例子：我们最近把 Rails 的 CSRF 防护机制改了——从以前“把 token 放进 cookie”的方式，改成使用现代浏览器的新特性：通过一个 header 来做。 我可以直接问 AI：“那个 header 是什么？”“什么时候开始支持的？”“具体有哪些细节？”这些答案我当然也能手动查：去 caniuse.com、看历史、查 RFC……全都能做。但 AI 能把这些东西一盘端上来，整合在一起，省事又快。 “AI 只是让我变聪明了” 我能更快学到更多东西。而这正是我真正喜欢的地方：不是让 AI 替我做事，而是用 AI让我更聪明。 当然，这种模式未来未必会成为主流。 就像你说的，你已经让 AI 写很多代码，甚至多数代码。我完全准备好在某个时点，我也会进入那种状态。 但就现在而言，我仍然在意代码的样子。我在意它的美感。我在意打磨、推敲、润色。 这可能是一种“奢侈”，有点像现代的马鞍匠：他会在意字母压得是否刚好、针脚是否完美。你可以说：“但你已经不是交通运输的主力生产体系了。”我会说：那又怎样？只要我还享受，我就会继续做我手写代码的“马鞍”。 而且我也意识到：这种模式目前仍然是有竞争力的。 在 37signals，我们并不觉得自己在产出能力、发布能力、改进能力上落后。因此我对一些说法保持怀疑：“AI 已经强到可以把标准 SaaS 公司的一半程序员裁掉，还能跑得更快。”我没看到。 我当年也用同一套“根本测试”来审视云计算：“我们能不能用更少的人、花更少的钱，做更多的事？”我们几年前退出云，就是因为这个测试没有通过。而且我也不太听说这个测试在别处通过过。云计算并没有让你把运维团队砍半、把基础设施预算砍半。很多时候恰恰相反：上云之后团队规模翻倍，账单翻四倍。 主持人：你们切换之后是不是省了类似每月一百万美元？很夸张的数字？ DHH：我们现在大概是一年省200 万美元。我们云预算峰值大概是 340 万美元，现在的持续成本在 100 多万美元左右。所以在成本上，节省非常巨大。 这和 AI 有一些相似之处——不完全相同，但有相似之处：我觉得现在很多人在用 AI，脑子里觉得自己“好高产”，但他们其实交付更少、做出来的东西更少，甚至理解得更少。 “Vibe Coding”的风险：能力会从指尖流走DHH：AI 还有另一个因素：当我尝试“氛围式写代码”（vibe coding）的时候——尤其在一个我还没完全内化的新领域——我能明显感觉到我的能力在从指尖滴走。 我刚开始做 Omarchy 时，写了很多 bash。我以前从没系统写过大量 bash，最多就是命令行里用用。然后我发现自己一次又一次问 AI：“某个 if 条件到底怎么写？” 这时你就会想：“为什么我没有内化这件事？我没内化，是因为我把它外包给 AI 了。”那这样更好吗？我现在更划算了吗？还是说，我跟当年那些老师一样天真：他们以为有了计算器，学生就不需要背乘法表了？不对。如果你不能迅速在脑子里算出 7×7，你真的会把自己变成傻子。 主持人：那你有没有形成一种直觉：该在哪里划线？你不可能知道一切，对吧？你也会把你不会的事交给信任的同事去做，你不会因为让同事设计某个东西就觉得“能力在流失”。你能接受：“这事我不需要会 / 我不想会”。那在 2025 这样疯狂的一年里，你有没有更清晰的边界：哪些你想自己掌握、哪些你可以忽略？比如 bash。为了推进 Omarchy，你觉得 bash 该学到什么程度？又有哪些可以不学？ DHH：我觉得我得会几乎全部，除了怎么在 bash 里搞数组（笑）。因为 bash 里数组那玩意儿复杂得离谱，简直反人类。但我其实认为：人类大脑是个很惊人的器官，它不会像 LLM 那样“容量到顶就装不下”。我们用得越多，记忆和能力的“配额”会增长。 所以我真正担心的趋势是：随着时间推移，我知道得更少、我变得更不胜任。我需要一条向上增长的移动平均线。 我不需要把所有领域都吞进去——我不需要什么都懂。但一年结束时，我应该在更多领域懂得更多。如果我不在这种上升轨道上，我会无聊。我无聊就会没动力。没动力我就什么也不干。这也是 AI 讨论的一部分：我们得想清楚，我们真正享受这套方程式里的哪一部分。 我个人不享受当项目经理。我会做——而且不止偶尔——因为我想要“组织一群人”能产出的结果。 但当我看 AI 这件事时，我不想当一群 AI agent 的项目经理。那不是我想要的状态。 我喜欢写代码。而至少在此时此刻，这是一个仍然有竞争力的选择。 当然，这可能三个月后就变了；下周就变了；随时都可能变。但 AI 公司那些领袖已经预言“再过五分钟就结束了”预言了很久了——现在也没结束。 你看 AI 公司自己，它们也还在招聘大量程序员。 我们并没有到 AGI，没有到那种“人类写代码的时代死了”的程度。 这并不否认你说的：有些程序员已经觉得自己大多数代码都让 AI 写了。但至少在市场上——按我看到的情况——还没有出现那种“压倒性差距”，就像：一个公司用马车送啤酒，另一个公司用卡车送啤酒。那种经济差距会非常快把前者淘汰。我还没在 AI 身上看到这种情况。也许数据有滞后；也许已经发生了——我仍然怀疑。 即便我在长期上是极度“AI 乐观派”，但就当下，我没看到。 有时神得离谱，有时烂得没法维护 DHH：而且原因之一是：我每天都在“盯”着它。我一直在问 AI：你能给我写这段代码吗？它会写。然后我会想：“不，我不喜欢这个。”“我甚至不想维护它。”“它做得还不如大多数初级程序员会被要求做到的水平。” 但偶尔，它也会给出另一种答案：我问它一个东西，它拼出来的结果让我震惊：“它怎么知道的？它怎么能把这些全部串起来？”那真的很惊人。 所以我感觉它像一个闪烁的灯泡：你在完全黑暗里，它突然一闪——你觉得“我什么都看见了”。两秒后，啪，又全黑。如果你能让这个灯泡稳定下来、一直亮着——那对人类当然是巨大的福音。 顺便说一句，我很喜欢美国的一点就是：美国把这个“闪烁灯泡”当成一种信仰——相信我们能把它变可靠，能到 AGI。现在大家就是一场巨大的押注：押注这一定会发生。即便我这么 AI 乐观，我仍然会对这种规模的“集体确信”感到惊叹：一个经济体一起说： “不管花多少代价，100 万亿、1000 万亿，我不在乎，我们一定能到那里。”我会想：这也许就是为什么它会成为“第一名”。 主持人：确实是个令人兴奋的时代。就像你说的——能活在此时此刻本身就是一种奇迹。我们也差不多到一小时的时间上限了。今天能和你重新连上线真的很开心，感谢你抽时间来。你现在也在忙 Fizzy。要不你简单跟大家说说：Fizzy 是什么？在哪能了解更多？然后我们就收尾。 DHH：当然。Fizzy 在fizzy.do。它是对 Kanban（看板）的一个全新诠释。这里还有个小故事：Jason 特别擅长解释“为什么值得回头重新解决一个问题”。 Kanban 这个概念来自 50 年代，是丰田为了管理生产线提出来的。后来我们把它做成了软件。第一代软件化的版本大概是 2000 年初。再后来 Trello 出现，把这个领域彻底带火、带爆。但我们还是回到这个领域，说：“你知道吗？我觉得我们还能做一个更好、更舒服的版本。” 很多人很难理解软件这件事：明明一个问题领域已经有很多玩家了，为什么你还要进去？原因可能只是：你想做得更好、更有趣、更轻量、更丰富多彩、更令人愉悦、功能更少——这些带着“爱”的细节，我们都烘焙进了 Fizzy。而且我们把它定价得很便宜：1000 张卡片免费，之后是 每月 20 美元。同时我们也把整个代码库开源了：如果你想自托管（self-host），你可以免费用。服务器我们不替你付，你自己折腾就行。你也可以贡献代码，也可以从中学习。 做 Fizzy 是一件很快乐的事，而且它也像一个实验室。我们现在正在做 Basecamp 5。我们在 Fizzy 上尝试了很多新技术——不管是编程层面还是产品层面——我们会把最好的想法带回 Basecamp 5。如果你关心我对这些话题（或任何话题）的观点，你可以去 dhh.dk，我的东西都在那。 主持人：太棒了。很高兴你来做客，也迫不及待想看未来会发生什么。感谢你的时间，我们下期再见。 参考链接：https://www.youtube.com/watch?v=uWqno4HM4xAhttps://www.reddit.com/r/ClaudeCode/comments/1qhiicv/the_creator_of_nodejs_says_the_era_of_writing/
把你的需求告诉我，我来免费帮你实现！
首先声明这个不是推广帖，也不是引战贴，标题不是噱头 帖子省流版： 对这段时间做的事情做了一些总结 大家提痛点需求，一起做一款让大家觉得爽的开源 AI 产品，形式可能为 build in pulic 拉了个微信群，分享开发 Agent 的经验技巧和坑 缘起我是一个重度 vim 用户，一开始（ 25 年中旬）用的是 github 官方 copilot.vim （原因是因为开源了几个上千 star 的项目(非凡尔赛)，copilot pro 一开始对这些开发者是免费的，当然现在不免费了），但是自动补全很慢，非常影响效率。然后就找有关的替代品，尝试了很多，比如 chatgpt.nvim ，codecompanion.nvim 等，但是都不太满意。后来也尝试了 Cursor 和 Claude Code ，但是也有各样问题，一是不太习惯 IDE ，二是还是需要人大量的时间去交互，实际体验下来开发效率并没有提升多少（当然现在要好不少）。后来一想为什么就不能自己写一个呢？于是开始了折腾（造轮子）之路。过程一开始是古法编程用 python 快速写了个自动 fix ut 的命令行，还在团队内部做了分享，但是很多时候这个 cli 工作的并不好，然后就想办法优化。看了很多资料，差不多 100+篇关于 AI 的论文（在 alphaxiv 的帮助下，挑重点 paper 细读。主题包括框架、Agent/Multi-Agent 、注意力、记忆、规划等等），其中一篇给我比较多启发的是 Alita 这篇论文 https://arxiv.org/abs/2505.20286 。当时 Context Engineering 这个概念刚火，还花了好几天看这个 https://github.com/davidkimai/Context-Engineering （后来证明这个项目对我来说基本没用）。然后设计出一套方案，目标是做一个让自己用起来爽的 Agent ，具体来说是： 快（干活快） 狠（彻底解决问题） 准（交付质量高） 美（产品要有设计品味） 充分发挥不同大模型的能力，不局限于单一模型。下面是一开始的架构设计：集中精力花了差不多 3 个月时间实现，中间还重构了一版（因为效果没有达到预期），核心逻辑全部手写，其他部分前期使用了 Cursor 来帮助写 TUI ，后面就全是用产品自己开发自己了。产品产品形态是 Desktop + Tui ，可以编程、Research 、干杂活等，可以简单理解为 Claude Code + Cowork 。 桌面版 对应视频在这 TUI 对应视频在这问题上个月底这个月初找了几个朋友内测了下，大家给了一些建议。这两天也开源了，在 HN 和 v2 也分别发了一个帖子简单介绍了下，反馈都比较平平，发的帖子很快沉下去了。我自己反思了下，可能是自己做的东西确实不够好，也可能是大家没关注到，或者大家关注到了但是不感兴趣。所以想看下大家真实的想法，先抛个几个问题： 现在大家对此类工具和产品怎么看？是产品引不起自己的兴趣吗？ 除了 claude code/codex/cursor/opencode 等，还用其他什么比较好的产品吗？比如豆包 现有的工具已经能很好的解决自己的问题了吗？还有其他的痛点吗？ 最后大家需要的话，我可以免费帮实现大家实现有关功能，未来产品的形态由大家来定义。另外我拉了个微信群，准备把开发 Agent 的时候一些经验技巧和坑分享一下，同时也方便大家交流有关话题，有感兴趣的可以评论区留言我拉一下大家进群。
我真的很反感有些人一边无脑吹捧 ai 编程，一边说手写代码是“古法编程”。大语言模型确实是一项划时代的技术，它的技术边界也在不断的被突破，但是任何技术都是有边界的。 那些无脑吹捧 AI 编程的人，我很怀疑，他们是不是陷入一种“盲目的狂热”或者“拜 AI 教”。一、编程的本质，计算机的范式（冯诺依曼架构）并没有发生改变。有人将其类比为汇编到高级语言的进化，这是完全错误的。编程语言具备正交性，你的每次运行，结果是一致的。而大语言模型的结果是非正交性的，初始值的一点微小的改变，都会对结果产生巨大的影响。编程和大语言模型在我看来，具有外在的相关性，但是本质上两者解决的是完全不同的两个问题，是求精确解和模糊解的的区别。另外，现有的所谓代码生成，从本质上看，其实不过是将过去的 ctrl+c 、ctrl+v 自动化了，仍然是对现有解决方案的“复刻”。二、从工程角度来看，ai 编程并没有降低开发的复杂度，而是从编码转移到了设计、验证等环节。有人幻想，通过 ai 可以极大的降低软件开发的复杂度，这完全是幻想。软件开发本质是对真实世界的投射和抽象，ai 编程可以降低一定的编码复杂度，但是它不可能降低真实世界的复杂度。软件开发的真正复杂的地方也从来不是编码。那些希望通过 ai 减轻码农负担的想法，终究是不现实的。别人花钱雇佣你，就是希望你来减轻复杂度的，如果你无法减少这种复杂度，或者有更廉价的方案，那别人雇佣你干什么呢？当然，我不是建议大家不要学 ai,我反对的是那些只会简单的使用，却自鸣得意的。我认为，应该从编写 agent 开始，真正的业务结合起来，而不是简单跑个页面，然后陷入一种虚假的自我满足。
当前关于 Vibe Engineering 的所有认知都会在 1 个月内严重过时
过去几周，我对于 Vibe Engineering 的实践有了更多的体会, 今天再次总结一下。其实也能看出来我避免使用 Vibe Coding 这个词，是因为当下的重点已经不再是代码，而是一些更高维度的东西。另外，本文的 AI 含量我会尽量控制在 5% 内，可以放心阅读😄。之前我提到的我开始的 TiDB Postgres 重写项目已经不再在是个玩具。在前几天出差的路上, 因为长途飞行没有网络, 我仔细 review 了一下这个项目的代码, 虽然一些地方略有瑕疵, 但是总体质量已经很高, 我认为已经是接近生产水平的 rust 代码，和以前我理解中的早期原型的定义很不一样。顺便提一句, 我认为这个项目从一开始就选择 rust 是一个无比正确的决定, rust 的严谨性让 AI 能写出更接近 bug free 的 infra code (对比我另一个项目 agfs 的 shell 和它自带的脚本语言 ascript，由于这项目使用 python，项目变大后，可维护性就大大降低，但此时重写已经很困难，只能捏着鼻子慢慢重构)，所以现在已经是 2026 年了， 如果你要再启动一个新的 backend infra 项目, rust 应该是你的第一选择。验证差不多后，我也邀请了几位我团队内的几个顶尖的 vibe coder 加入项目, 看看 100% 的 AI Native 研发模式能在多快把这个项目推进到何种程度，无论如何都很想看看，应该会很有意思。下面说说自己最近的一些感受。当前关于 Vibe Engineering 的所有的认知都会在 1 个月内严重过时并非危言耸听，哪怕我正在写的这篇文章，如果你是 2026 年 2 月看到，那么很遗憾，本文聊到的东西很可能已经过时，这个领域发展的太快，很多今天的 SOTA 也许下个月就过时了。而且很有意思，过去很多对 Vibe Coding 嗤之以鼻的大佬，例如 DHH，Linus，Antirez 等，在 2025.12 月开始纷纷改口，我觉得这是相当正常的，去年 12 月开始，AI 编程工具和头部的模型突然有一个跳跃式的进步，突然对于复杂任务和大型项目的理解，以及写出代码的正确率有了极大的提升。这进步大概来自于两个方面：一方面头部模型在长上下文（>256K) 的支持，尤其是关键信息的召回率提升惊人例如上面是 GPT-5.2 在长上下文的召回表现和 GPT-5.1 对比很明显，要知道对于 Agent Coding 的场景来说，通常是多轮次推理 + 长上下文（因为要放更多的代码和中间推理结果）才能更好的有大局观，大局观的正确是对于复杂项目起到决定性因素。在这种场景下，你可以做一个简单的计算，一个模型（类似 GPT-5.1) 每轮的召回率 50%，大概 3 轮后，正确的召回率就会降低到 12.5%, 而 GPT-5.2 仍然能保持 70% 以上。另外一个进步是主流的 Vibe Coding 工具的 Context Engineer 实践日益成熟，例如 Claude Code / Codex / OpenCode。从用户体验到最佳实践，肉眼可见的越来越好，例如对于 Bash 的使用，Subagent 等，这方面越来越多的资深 Engineer 的重度使用和经验分享会对这些工具的进化提供数据飞轮，尤其是 AI 也在深度的开发这些工具，迭代速度只会更快。其实这个进步也并不是去年 12 月那个时间点的突然什么黑科技爆发，其实前几个月一直在进步，不过还不能长时间离开人工干预，更像是那个时间点，主流 Coding Agent 的质量超过了一个临界点：100% 的无人工干预下完成长时间的 Agentic Loop 成为可能。Hire the best (model)，否则就是在浪费生命上面所有提到的进步，我个人感觉只反映在了最顶尖的闭源头部模型中。我听到很多朋友和我反馈到：“我感觉 AI 编程还是很傻啊？并没有你提到那么聪明”，我首先会反问，你是不是只是用着 $20 一个月那种入门模型？如果是的话，那先去用一阵 $200 以上的 Pro Max 档次的，也许有惊喜。我个人认为，目前主流的模型，即使并非头部那档，作为 chatbot 处理大多数普通人的短上下文的日常工作是完全足够的，哪怕是 GPT-4 在和你讲人生道理的时候也已经足够把你说得一愣一愣了。作为人来说，我们的直觉或者是一些简单的 CRUD Demo 已经无法评估这些模型之间的智商差距了。但是在复杂的项目的开发中，这个差距是极端明显的。根据我个人的实践来说，当下能用来进行大型 Infra 项目（数据库，操作系统，编译器等）开发的模型大概就两个：GPT-5.2 (xhigh) + Opus 4.5，还有半个算是 Gemini 3 Pro。大概上个月我主要用着 opencode + oh-my-opencode + Opus 4.5 但是最近两周转向到了 codex + gpt-5.2 的组合，下面分析一下这几个模型的一些脾气和调性，仅仅是个人感受，而且是在后端 Infra 软件开发这个领域，仅供参考。Opus 4.5 的风格是速度很快，是个话唠，由于 Sonnet 4 有严重 reward hacking 问题，例如是在解决不了 bug 的时候会偷偷的构造作弊的测试然后糊弄过去，所以导致很长一段时间我都不太敢用 Sonnet 系列模型干复杂的事情，但是这点在 Opus 4.5 中解决得很好，即使在模型冥思苦各种尝试想都搞不定的情况下也没有选择作弊，让我放心不少，但是 Opus 的问题是 reasoning 和做 investigation 的时间太少，动手太快，以至于发现不对的时候，又返回头确认假设和研究，这样的特性催生了像 ralph-loop 这样的奇技淫巧。比方说，同样的一个 prompt 在 Claude Code 结束后又通过 stop hook 重新调用，再完整走一遍流程，不断地逼近最终的结果。相比之下，GPT-5.2 更像是一个更加小心谨慎、话不多的角色。我最开始用 Codex 的体验其实不算太好，因为我一直觉得它有点太慢了。主要是因为我习惯用它的 xhigh 深度思考模式，在真正开始写代码之前，它会花很长时间去浏览项目里的各种文件和文档，做很多准备工作。可能也是因为 Codex 的客户端不会告诉你它的计划和大概需要多久，所以就显得过程特别长。有时候一些复杂的任务，它前期的调查可能就要花上一到两个小时。但是经过长时间思考后它完成的效果通常是更好的，尤其是在一个项目的大体框架已经稳定，Codex 考虑得更周全，最终也体现出更少的 bug 和更好的稳定性。对于第三个顶级模型，也就是 Gemini 3 Pro。虽然我也知道它的多模态能力非常吸引人，但就复杂任务的 Coding 场景而言，至少从我个人的体验来看，它的表现并没有 Opus 4.5 和 GPT-5.2 那么强。不过它确实针对一些快速的前端项目 Demo 和原型制作做了一些优化，再加上它的 Playground 模式，让你在需要一些炫酷的小 Demo 或前端项目时能更快实现。其实一个比较反直觉的事情是，过去我们经常说 Vibe Coding 只能搞一些比较简单的事情，比如上面那些小 Demo 或 CRUD 项目，你会看到网上各种各样的 KOL 其实都在做这种小原型，反而大家觉得对于一些像后端这种核心的基础设施代码，当前 AI 还是搞不定的。我以前也这么想，但从去年 12 月份开始，这个结论可能需要修正了。这里面的原因是，其实这类基础设施的代码通常是由顶级工程师长期精雕细琢而成，它们有清晰的抽象、良好的测试，甚至代码本身经过多轮重构后也相当精炼。所以当 AI 具备足够的上下文空间 + 更好的推理能力 + 更成熟的 Agentic Loop + 高效的工具调用时，这类 Infra 代码的开发和维护反而是能最有效地利用这些顶尖大模型的智商的场景。在实际的工作中，我经常会让多个 Agent 互相协作，或者使用一些复杂的工作流来把它们编排在一起，并不会让一个模型来完成所有的事情。后面我会再分享一些我自己实践中的具体例子。人在什么时候进入？扮演什么角色？上面提到了，这些顶级模型再配合主流的 Vibe Coding 工具，基本上已经能超越大多数资深工程师的水平了。这不仅体现在能写出更少 bug 的代码，也体现在在 review 中能发现更多人类工程师可能看不到的问题，毕竟 AI 真的会一行一行仔细看。所以人在这个过程中扮演什么样的角色，哪些阶段只有人才能做？根据我自己的实践来说，第一当然是提出需求，毕竟只有你才知道你想要啥，这很显然，但是有时确实也挺难的，毕竟人很难从一开始就准确描述自己想要什么，这时候我会用一个偷懒的办法：让 AI 来角色扮演，比方说，我在开发 PostgreSQL 版本的 TiDB 时，我就让 AI 假设自己是一个资深的 Postgres 用户，从开发者的视角告诉我有哪些特性是非常重要、一定要实现而且 ROI 比较高的，让它列出 N 个这样的功能点，然后 AI 就会根据它的理解生成一个需求列表，接下来你再和 AI 对这些需求逐个打磨，这其实是一个高效冷启动的方法。第二是在需求提出后，现在的 Coding Agent 大多都会和你有一个规划阶段（Planning），会反复确认你的需求。在这个过程中其实有一些技巧，比如不要给 AI 太具体的方案，而是让 AI 来生成方案，你只需要关注最终你想要的结果；提前告诉 AI 有哪些基础设施和环境的问题，让它少走弯路。另外，我通常会在提出需求的第一阶段就要求 Agent 做的一些关键动作。比如无论接下来做什么，都要把计划和 todo 列表放在一个 work.md 或 todo.md 这类文件里。还有，每完成一个阶段的工作，就把上一阶段的经验教训更新到 agents.md 里。第三点是当一个计划完成并且代码合并后，把这个工作的设计文档添加到项目的知识库中（.codex/knowledge）。这些都是我会在一开始提需求时就放进去的内容。第二个阶段就是漫长的调查、研究和分析的阶段。这个阶段其实基本上不需要人做什么事情，而且 Agent 的效率比人高得多，你只需要等着就好。唯一需要注意的就是在 Research 的过程中，我通常会告诉模型它拥有无限的预算和时间，尽可能充分地进行调研。另外，如果你的模型有推理深度的参数的话，我建议在这个阶段把它们全部调到 xhigh 的级别。虽然这会让过程变慢，但在这个阶段多烧一些 token、做好更好的规划、了解更多上下文，对后续的实现阶段会更有帮助。实现阶段没什么特别好说的，反正我现在基本不会一行行去看 AI 的代码。我觉得在实现阶段唯一要注意的就是，要么你就让 AI 完全去做，要么你就完全自己做，千万别混着来，我目前是倾向于完全零人工干预的模式效果更好。第四个阶段人就变得非常重要了，那就是测试和验收结果的阶段。其实在我个人和 AI 开发项目的过程中，我 90% 的时间和精力都花在了这个阶段：也就是如何评估 AI 的工作成果，我觉得在 Vibe Coding 时：There's a test, there's a feature，你只要知道如何评估和测试你要的东西，AI 就一定能把东西给你做出来。另外值得注意的是，AI 在实现过程中会自动帮你添加很多单元测试，但说实话，这些单元测试在微观层面基本都能通过，毕竟 AI 写这种局部代码时已经很难出 bug。但 AI 不擅长的是集成测试、端到端测试。比如在开发一个 SQL 数据库时，哪怕每个细节的单元测试都没问题，但整合到一起时集成测试可能会出错。所以我在完成大目标前，我一定会先和 AI 一起做一个方便的集成测试框架，并提前准备好测试的基础设施，收集和生成一些现成集成测试的用例，尽量一键能运行那种，这样在开发阶段就能事半功倍，而且关于如何使用这些测试的基础设施的信息，我都会在正式开始前就固化在 agents.md 里，这样就不用每次沟通的时候都再告诉它该怎么测试了。关于测试从哪来的问题，我自己的经验是你可以让 AI 帮你生成，但一定要告诉它一些生成的逻辑，标准和目的，另外就是千万不要把生成测试的 Context 和实际进行开发工作的 Agent 的 Context 混在一起。第五个阶段是重构和拆分。我发现当前的 Coding Agent 在面对单一模块复杂度超过大约 5 万行代码之后，就开始很难在 1-shot 里把问题一次性解决掉（但反过来这也意味着，只要任务复杂度控制在这个阈值之下，在一个足够好的 first prompt 驱动下，很多事情确实可以做到 1-shot AC），Agent 通常不会主动去做项目结构和模块边界的治理，你要它把功能做出来，它恨不得把所有东西都写进几个几万行的大文件里，短期看似很快，长期就是债务爆炸。我自己在这个阶段的做法通常是先停下来，用自己的经验进行模块拆分，然后在新的架构下进行 1～2 轮的重构，之后又可以高并发度的进行开发了。多 Agent 协同编程的一些实践前面提到我现在使用 Coding Agent 的时候，通常不会只用一个，我自己的工作流会尽量让多个 Coding Agent 同时工作。这也是为什么有时候在一些项目上会花掉好几千美金，因为你必须把并发跑起来。当然，并发和吞吐是一方面，但另一方面我觉得让不同的 Agent 在不共享上下文的前提下互相 Review 工作，其实能显著提高质量。这就像在管理研发团队时，你不会让同一个人既当运动员又当裁判。相当于 Agent A 写的代码交给 Agent B 来 Review，往往能发现一些 A 看不到的问题。通过这样的循环往复，你就会更有信心。例如，我在实际工作中现在用得比较好的一个工作流是这样的：首先让 GPT-5.2 在 Codex 下生成多个功能的设计文档，做出详细的设计和规划，第一阶段把这些规划文档都保存下来。然后在第二阶段，依然用 Codex 根据这些需求文档一个一个去实现功能。在实现的过程中，就像我前面提到的那样，记录 To-Do、经验教训，并在接近完成的时候，在代码通过测试并准备提交之前停下，把当前的工作区交给另一个 ClaudeCode 或 OpenCode，在不提供上下文的情况下，让 ClaudeCode 来 Review 当前还未提交的代码，根据设计提出修改建议。然后再把这些建议发回给 Codex，让 Codex 来评论这些建议，如果有道理就修改代码。改完之后，再让 ClaudeCode (Opus 4.5) 那边再次 Review，直到双方都觉得代码已经写得很不错了，再提交到 Git 上，标记这个任务完成，更新知识库，然后进入下一个功能的开发。另外在一个大型项目中我会同时开多个 Agent (in different Tmux) 并行开发多个功能，但我尽量让它们负责完全不同的模块。比如一个 Agent 修改内核代码，另一个 Agent 做前端界面，这样就能分开进行，如果你需要在一份代码上做一些彼此不太相关的工作时，可以利用 git 的 worktree 让多个 Agent 在不同的 git 分支上各自工作，这样也能快速提升吞吐量。未来的软件公司和组织形态未来的软件公司会是什么形态呢？反正从我自己的实践和与一些朋友的交流来看，至少在当下，团队中用 Coding Agent 的 token 的消耗呈现出一个非常符合二八定律的分布，也就是说，最头部的用 AI 用得最好的工程师，他们消耗的 token 可能比剩下 80% 的工程师加起来还要多，而且 Coding Agent 对于不同工程师产出（质量，吞吐）的增益是不一样的，这个方差非常大，也就是对于用的最好的一群人，他们的增幅可能是 10x，但是普通人可能也就是 10%，而且唯一的瓶颈是人工的 code review 和一些无法被自动化的线上运维工作（我觉得也很快了）而且这样的特点能够让这些头部的工程师在 AI 的协助下可以无边界的工作，也就是会有越来越多的 one-man army 出现，只是目前我认为和 token 消耗是正相关的，你能花掉多少 token，大致代表你能做得多好。另外我发现一个很有趣的现象，同样是 10x 的工程师，他们各自的 Vibe Coding 工作流和最佳实践其实并不相同。也就意味着，两个顶尖的 Vibe Coder 是很难在一个项目中（的同一个模块）协作。这种工作方式更像是头狼带着一群狼群（Agents），在一片自己的领地里面耕耘，但是同一片领地里很难容纳两匹头狼，会造成 1+1 < 2。在这样的组织形态下，我觉得传统意义上的“团队协作方式”会被重新定义。过去我们强调的是多人在同一个代码库、同一个模块里高频协作，通过评审、讨论、同步来达成共识；但在 Vibe Engineering 这种模式下，更有效的方式反而可能是强解耦的并行。管理者要做的是把问题切分成足够清晰、边界明确的“领地”，让每一个头部工程师带着自己的 Agent 群，在各自的领域里做到极致。从管理的角度看，这其实是一个挺大的挑战。因为你不能再用统一流程、统一节奏去约束所有人。对顶尖的 Vibe Coder 来说，过多的流程和同步反而会显著拉低效率，甚至抵消 AI 带来的增益。管理者更像是在做“资源调度”和“冲突隔离”：确保不同头狼之间尽量少互相干扰，同时在必要的时候，能够通过清晰的接口、契约和测试来完成协作。因为上面的种种，AI-Native 的研发组织其实很难自底向上从一个非 AI-Native 的组织中生长出来，因为大多数开发者面对变革的时候的第一反应其实并不是拥抱，而是回避和抵触，但是时代的进步不会因为个人的意志转移，只有主动拥抱和被动拥抱的区别。大概就写到这里吧，总的来说，在这样一个大环境下，对个人而言意味着一场深刻的转变，就像我之前在朋友圈里提到的，我身边最好的工程师们有一些已经陷入了或多或少的存在主义危机。但是作为具体的 Builder 的我来说是兴奋的，因为造物，在当下，门槛变低了许多，如果你能从造物中能获得成就感和找到人生的意义，那恭喜你，你活在一个最好的时代。但反过来，作为一个抽象的 “人” 来说，我又是悲观的，人类是否准备好面对这样的工具？以及这样工具带来的对于社会和整个人类文明的冲击？我不知道。
AI Coding与单元测试的协同进化：从验证到驱动
AI生成代码质量难以把控！本文分享来自美团的技术实践，三大策略破解AI编程痛点。单测快速验证逻辑正确性，安全网保护存量代码演进，TDD模式精准传递需求。告别「看起来没问题」的错觉，构建AI时代的代码质量保障体系。一、引言目前，国内外很多AI Coding助手能在几秒钟内生成完整代码块，大大提升了开发效率，但这种高速开发模式也带来了潜在风险——与人工编码不同是，AI Coding助手生成代码存在两个特殊风险：其一，AI Coding助手依赖于上下文与模型自身的能力，输出的代码质量相对不可控。其二，AI生成的代码虽然逻辑通顺、结构完整，但可能隐藏着难以察觉的边界问题或逻辑缺陷。核心问题：我们如何快速的验证AI生成代码的质量和可靠性？本文旨在分享如何借助单元测试，让AI编程合作更高效可靠，主要解决三个常见痛点：肉眼审查困境：AI一次性生成大量代码时，难以快速准确判断逻辑完备性；存量代码信任危机：如何验证AI修改老代码时，不会产生非预期的结果；需求传达难题：如何精准向AI表达复杂需求并快速验证。针对上述三个常见痛点，本文提出采用不同的单元测试策略来应对以上问题。每个策略都针对一个特定痛点设计：策略一通过测试解决肉眼审查的局限性；策略二构建单测安全网应对存量代码的信任问题；策略三则采用TDD模式优化需求传达与验证流程。下文将依次展开说明，希望能对大家有所帮助或启发。二、策略一：单测检验AI代码逻辑正确性2.1 问题背景传统的人工代码审查在AI生成的大量代码面前显得低效且不可靠。在软件测试实践中，有着测试左移（Shift Left Testing）的概念，本质上是借助工具和测试手段更早地发现问题和预防问题。在AI Coding时代，这一理念尤为关键：跳过单元测试直接集成测试看似”抄近路”，实则是将风险后置——开发阶段几分钟能发现的Bug，在集成测试环境可能需要较长定位修复，这中间包含了代码部署、环境准备、测试条件的准备、问题定位、开发人员修复、再次部署验证等一系列漫长的环节。相比之下，单元测试具有独特的优势：它能够独立运行、快速验证结果，并且可以无限次重复执行。这种测试方式就像是为项目进行的一次性投资，却能为整个开发周期构建起一张可靠的“安全网”。它不仅能实时验证AI Coding生成的代码是否正确，更能持续保障未来代码的质量稳定性，让开发团队始终对代码库保持信心。2.2 案例：分页查询接口的隐蔽Bug任务背景：实现一个支持多条件筛选的复杂分页查询接口pageQueryRobotAI生成了如下核心查询逻辑：public List<AgentRobotE> pageQueryRobotsByCondition(List<Long> shopIds, String chatSceneCode, Boolean enabled, Integer pageNo, Integer pageSize) { // ... 前置校验代码 ... // 分页查询机器人基础信息 int offset = (pageNo - 1) * pageSize; List<AgentRobotEntity> entities = robotIds.stream() .skip(offset) .limit(pageSize) .map(robotId -> agentRobotDAO.getRobotById(robotId, false)) .filter(Objects::nonNull) // 问题代码：类型不匹配的隐蔽Bug .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled ? 1 : 0)) .filter(entity -> Objects.equals(entity.getChatSceneCode(), chatSceneCode)) .collect(Collectors.toList()); return entities.stream() .map(this::convertToModel) .filter(Objects::nonNull) .collect(Collectors.toList()); } 问题分析：这段代码看起来逻辑完整，但第8行的过滤逻辑包含了多个复杂元素：三元运算符 enabled ? 1 : 0Objects.equals 的使用Boolean到Integer的隐式逻辑转换仅凭肉眼很难发现其中的类型不匹配问题。单元测试发现问题：通过AI编写了17个全面的单元测试用例，覆盖：正常场景：各种有效参数组合边界场景：null值、空集合处理参数组合：enabled为true/false/null的不同情况@Test public void testPageQueryWhenEnabledIsTrue() { // arrange List<Long> shopIds = Arrays.asList(12345L, 67890L); String chatSceneCode = "SCENE_C"; Boolean enabled = true; // 测试enabled为true的情况 // 模拟数据库返回的实体，enabled字段为Boolean类型 AgentRobotEntity mockEntity = new AgentRobotEntity(); mockEntity.setEnabled(true); // 注意：这里是Boolean类型 mockEntity.setChatSceneCode("SCENE_C"); when(agentRobotDAO.getRobotById(anyLong(), eq(false))).thenReturn(mockEntity); // act List<AgentRobotE> result = repository.pageQueryRobotsByCondition( shopIds, chatSceneCode, enabled, 1, 10); // assert - 这个测试失败了！ assertEquals(1, result.size()); // 期望返回1个结果，实际返回0个 } 测试运行结果：当enabled为true时测试失败！问题定位：通过测试失败，快速定位到过滤逻辑的问题：// 错误的逻辑：entity.getEnabled()返回Boolean类型，但与Integer比较 Objects.equals(entity.getEnabled(), enabled ? 1 : 0) // 当enabled=true时，比较的是 Objects.equals(Boolean.TRUE, 1) -> false // 当enabled=false时，比较的是 Objects.equals(Boolean.TRUE, 0) -> false 正确修复：// 修复后：直接比较Boolean类型 .filter(entity -> enabled == null || Objects.equals(entity.getEnabled(), enabled)) 意外收获：在审查测试覆盖的代码时，还发现了N+1查询的性能问题：// 存在性能问题的代码 .map(robotId -> agentRobotDAO.getRobotById(robotId, false)) // 每个robotId单独查询 成果验证：修复后，所有17个单元测试用例全部通过，代码质量得到保障。三、策略二：构建安全网保护存量代码3.1 问题场景AI对存量代码的修改挑战更大。AI看到的可能只是函数或类的局部，无法理解背后的业务规则和历史包袱。如何放心的让AI修改已有的代码？在进行AI Coding前，需要确保旧有逻辑，处于单元测试的完全覆盖保护中，这就像在开启汽车的“自动辅助驾驶”功能前，必须先系好安全带一样。这条“安全带”就是我们完善的、可运行的单元测试集。快速验证，精准反馈：AI生成修改后的代码无需人工逐行对比，只需运行单元测试即可获得即时反馈。测试失败的用例直接揭示AI修改中存在的问题——要么触及了不应改动的逻辑，要么未能正确实现预期变更。这种反馈机制既高效又客观。清晰界定修改边界：单元测试结果帮助我们明确判断——AI的修改是否精准实现了目标？在引入新功能的同时是否完整保留了原有逻辑？通过区分预期内的失败（主动修改旧逻辑）和意外失败（破坏现有功能），我们获得了优化AI方案的明确方向，大幅提升了迭代效率。3.2 案例：延迟回复策略的用户范围扩展业务背景：需要将消息延迟回复服务从原来的平台A、平台B的用户扩展到平台C用户。原始代码分析：// TextDelayReplyStrategy.java 中的核心逻辑 private boolean needSkip(ChatHistoryE chatHistoryE) { UserDTO UserDTO = UserHelper.parseUser(chatHistoryE.getUserId()); return MessageSendDirectionEnum.CLIENT_SEND.value != chatHistoryE.getMessageStatus() || MessageShieldEnum.RECEIVER_SHIELD.value == chatHistoryE.getShield() || UserDTO == null || !UserType.isLoginUser(UserDTO.getUserType()); // 关键判断逻辑 } 这个needSkip方法决定了哪些用户类型需要跳过延迟回复处理。原逻辑中，UserType.isLoginUser()只覆盖平台A、平台B的登录用户，不包括平台C用户。修改前的安全网构建：按照“分析-测试-实施-验证”方法论，首先完善单元测试：// 针对现有逻辑的保护性测试 @Test public void testNeedSkipWithAUser() { // 平台A用户不应被跳过 ChatHistoryE chatHistory = buildChatHistory(A_USER_ID); assertFalse(strategy.needSkip(chatHistory)); } @Test public void testNeedSkipWithBUser() { // 平台B用户不应被跳过 ChatHistoryE chatHistory = buildChatHistory(B_USER_ID); assertFalse(strategy.needSkip(chatHistory)); } @Test public void testNeedSkipWithCUser() { // 平台C在修改前应被跳过 ChatHistoryE chatHistory = buildChatHistory(C_USER_ID); assertTrue(strategy.needSkip(chatHistory)); // 修改前的预期行为 } @Test public void testNeedSkipWithGuestUser() { // 游客用户应被跳过 ChatHistoryE chatHistory = buildChatHistory(GUEST_USER_ID); assertTrue(strategy.needSkip(chatHistory)); } 运行基线测试：确保所有测试通过，建立基线状态[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0 [INFO] 所有现有逻辑测试通过，可以安全修改 AI辅助修改实施：向AI提供需求：”将平台C用户也纳入延迟回复服务范围”AI分析代码后给出修改方案：// 修改后的代码 private boolean needSkip(ChatHistoryE chatHistoryE) { UserDTO UserDTO = UserHelper.parseUser(chatHistoryE.getUserId()); return MessageSendDirectionEnum.CLIENT_SEND.value != chatHistoryE.getMessageStatus() || MessageShieldEnum.RECEIVER_SHIELD.value == chatHistoryE.getShield() || UserDTO == null || !UserType.isAorBorCLoginUser(UserDTO.getUserType()); // 扩展用户范围 } 验证阶段的精准反馈：修改后运行测试集：# 运行结果 [INFO] Tests run: 15, Failures: 1, Errors: 0, Skipped: 0 [ERROR] testNeedSkipWithCProviderUser: expected:<true> but was:<false> 结果分析：✅ testNeedSkipWithAUser - 通过（平台A用户逻辑未变） ✅ testNeedSkipWithBUser - 通过（平台B用户逻辑未变） ❌ testNeedSkipWithCUser - 失败（平台C预期的变更） ✅ testNeedSkipWithGuestUser - 通过（游客用户逻辑未变）更新期望值：@Test public void testNeedSkipWithCUser() { // 修改后：平台C不应被跳过 ChatHistoryE chatHistory = buildChatHistory(C_USER_ID); assertFalse(strategy.needSkip(chatHistory)); // 更新期望值 } 最终验证：[INFO] Tests run: 15, Failures: 0, Errors: 0, Skipped: 0 [INFO] 所有测试通过，修改安全完成 这种方法将开发者从“担心AI改坏代码”的不信任中解放出来，明确知道哪些功能被影响，哪些保持不变，实现安全、高效的存量代码演进。四、策略三：TDD思想驱动AI开发4.1 “先生成，后验证”的局限前面两节所提到的策略可以归类为”先生成，后验证”，在一定的场景下仍然存在两个问题：提示词驱动：开发者反复修改自然语言描述，AI产出不确定，返工频繁；肉眼审查：生成测试用例仍然需要人工验证，一旦用例较多，效率依然低下。4.2 TDD模式的革命性转变TDD 核心理念：测试先行：先写测试，再写实现代码。小步快跑：以微小增量推进开发，每次只解决一个问题。设计驱动：测试即需求文档，驱动接口设计和代码结构。安全网：测试集提供即时反馈，支持安全重构。整个开发过程严格遵循 Red -> Green -> Refactor 的循环。🔴 Red: 先编写一个失败的单元测试，用代码来定义我们期望实现的功能。🟢 Green: 编写最精简的业务代码，让测试恰好通过。🔵 Refactor: 在测试持续通过的前提下，重构优化代码的设计和质量。借助测试驱动开发（TDD）思想，我们先为AI提供一份清晰、无歧义的“需求说明书”和“验收标准”，然后指导它进行代码的生成。这个过程的核心是“🔴 红-🟢 绿-🔵 重构”循环，它将我们的每一次的对话，都转化为一次可验证的、可累加的进步。采用“先验证，后实现”的红-绿-重构循环，将模糊的需求转化为精确的代码语言。4.3 案例：优惠券使用规则引擎的复杂逻辑业务需求：开发一个智能优惠券使用规则引擎，支持”多券叠加使用和最优组合推荐”传统困难：自然语言描述：“实现优惠券规则引擎，支持多种券类型的叠加使用，并智能推荐最优使用方案”AI需要猜测：哪些券可以叠加？什么是“最优”？有哪些使用限制？反复沟通：多次修改提示词，AI理解仍然偏离业务实际第一次尝试：AI理解为“简单累加所有优惠”// AI第一次实现 - 过于简化 public BigDecimal calculateDiscount(Order order, List<Coupon> coupons) { return coupons.stream() .map(coupon -> coupon.getDiscountAmount()) .reduce(BigDecimal.ZERO, BigDecimal::add); } // 问题：忽略了券的使用条件、互斥规则、叠加限制 第二次尝试：AI理解为“选择面额最大的券”// AI第二次实现 - 逻辑错误 public List<Coupon> selectOptimalCoupons(Order order, List<Coupon> availableCoupons) { return availableCoupons.stream() .filter(coupon -> order.getTotalAmount().compareTo(coupon.getMinOrderAmount()) >= 0) .max(Comparator.comparing(Coupon::getDiscountAmount)) .map(List::of) .orElse(Collections.emptyList()); } // 问题：只考虑单券最大优惠，未考虑多券组合的更优效果 第三次尝试：AI尝试复杂逻辑但引入更多问题// AI第三次实现 - 逻辑混乱 public CouponUsageResult applyCoupons(Order order, List<Coupon> coupons) { // 各种复杂的if-else嵌套，但缺乏清晰的业务规则 // 没有处理券的互斥关系 // 没有考虑计算顺序对最终优惠的影响 // 边界条件处理不当 } 经过多轮提示词优化，每次都需要重新解释复杂的业务规则，仍不满足预期。TDD方式的完整循环：🔴 红色阶段：用测试定义需求编写测试用例，精确定义复杂的业务规则：@Test public void testCouponUsageWithBasicStackingRules() { // 构造订单：总价100元，包含数码产品 Order order = new Order() .setTotalAmount(new BigDecimal("100.00")) .addItem("数码产品", new BigDecimal("100.00")); // 构造可用优惠券 List<Coupon> availableCoupons = Arrays.asList( new Coupon().setType("满减券").setCondition("满50减10").setDiscountAmount(new BigDecimal("10")), new Coupon().setType("打折券").setCondition("数码类9折").setDiscountRate(new BigDecimal("0.9")), new Coupon().setType("免邮券").setCondition("免运费").setDiscountAmount(new BigDecimal("5")) ); // 期望结果：满减券和免邮券可叠加，打折券与满减券互斥，应选择最优组合 CouponUsageResult result = CouponEngine.calculateOptimalUsage(order, availableCoupons); // 验证最优方案：使用打折券+免邮券 (90+0=90元，比满减券+免邮券的85元更优) assertEquals(2, result.getUsedCoupons().size()); assertTrue(result.getUsedCoupons().stream().anyMatch(c -> "打折券".equals(c.getType()))); assertTrue(result.getUsedCoupons().stream().anyMatch(c -> "免邮券".equals(c.getType()))); assertEquals(new BigDecimal("95.00"), result.getFinalAmount()); // 100*0.9 + 0 - 5运费 } @Test public void testCouponMutualExclusionRules() { Order order = new Order().setTotalAmount(new BigDecimal("200.00")); List<Coupon> availableCoupons = Arrays.asList( new Coupon().setType("满减券").setCondition("满100减30").setDiscountAmount(new BigDecimal("30")), new Coupon().setType("打折券").setCondition("全场8折").setDiscountRate(new BigDecimal("0.8")), new Coupon().setType("新用户专享").setCondition("首单5折").setDiscountRate(new BigDecimal("0.5")) ); CouponUsageResult result = CouponEngine.calculateOptimalUsage(order, availableCoupons); // 验证互斥规则：新用户券与其他券互斥，且优惠最大，应该单独使用 assertEquals(1, result.getUsedCoupons().size()); assertEquals("新用户专享", result.getUsedCoupons().get(0).getType()); assertEquals(new BigDecimal("100.00"), result.getFinalAmount()); // 200 * 0.5 } @Test public void testCouponUsageConditionValidation() { Order order = new Order() .setTotalAmount(new BigDecimal("30.00")) .setUserLevel("普通用户") .addItem("服装", new BigDecimal("30.00")); List<Coupon> availableCoupons = Arrays.asList( new Coupon().setCondition("满50减10"), // 不满足金额条件 new Coupon().setCondition("VIP专享9折"), // 不满足用户等级条件 new Coupon().setCondition("数码类8折"), // 不满足品类条件 new Coupon().setCondition("无门槛5元券").setDiscountAmount(new BigDecimal("5")) // 满足条件 ); CouponUsageResult result = CouponEngine.calculateOptimalUsage(order, availableCoupons); // 验证条件判断：只有无门槛券可用 assertEquals(1, result.getUsedCoupons().size()); assertEquals("无门槛5元券", result.getUsedCoupons().get(0).getCondition()); assertEquals(new BigDecimal("25.00"), result.getFinalAmount()); } 运行测试：[ERROR] testCouponUsageWithBasicStackingRules: Class CouponEngine doesn't exist [ERROR] testCouponMutualExclusionRules: Method calculateOptimalUsage not found 红色阶段成功：测试失败，但复杂的业务规则已经通过代码精确表达。🟢 绿色阶段：AI精确实现将失败的测试用例提供给AI：“请实现CouponEngine.calculateOptimalUsage方法，让这些测试通过”AI分析测试用例后，精确理解了复杂的业务规则：券类型包括满减券、打折券、免邮券、新用户券等不同券有不同的叠加和互斥规则需要验证使用条件（金额、用户等级、商品类别）要计算最优的券使用组合AI生成的实现方案：public class CouponEngine { public static CouponUsageResult calculateOptimalUsage(Order order, List<Coupon> availableCoupons) { // 1. 过滤出满足使用条件的券 List<Coupon> eligibleCoupons = availableCoupons.stream() .filter(coupon -> isEligible(order, coupon)) .collect(Collectors.toList()); // 2. 生成所有可能的券组合（考虑互斥规则） List<List<Coupon>> validCombinations = generateValidCombinations(eligibleCoupons); // 3. 计算每种组合的最终优惠，选择最优方案 return validCombinations.stream() .map(combination -> calculateResult(order, combination)) .min(Comparator.comparing(CouponUsageResult::getFinalAmount)) .orElse(new CouponUsageResult(order.getTotalAmount(), Collections.emptyList())); } private static boolean isEligible(Order order, Coupon coupon) { String condition = coupon.getCondition(); // 金额条件检查 if (condition.contains("满") && condition.contains("减")) { BigDecimal minAmount = extractMinAmount(condition); if (order.getTotalAmount().compareTo(minAmount) < 0) return false; } // 用户等级检查 if (condition.contains("VIP") && !"VIP用户".equals(order.getUserLevel())) { return false; } // 商品类别检查 if (condition.contains("数码类") && !order.hasCategory("数码产品")) { return false; } return true; } private static List<List<Coupon>> generateValidCombinations(List<Coupon> coupons) { List<List<Coupon>> combinations = new ArrayList<>(); // 生成所有子集组合 for (int i = 0; i < Math.pow(2, coupons.size()); i++) { List<Coupon> combination = new ArrayList<>(); for (int j = 0; j < coupons.size(); j++) { if ((i & (1 << j)) != 0) { combination.add(coupons.get(j)); } } // 检查组合是否符合互斥规则 if (isValidCombination(combination)) { combinations.add(combination); } } return combinations; } private static boolean isValidCombination(List<Coupon> combination) { // 检查互斥规则 boolean hasDiscountCoupon = combination.stream().anyMatch(c -> "打折券".equals(c.getType())); boolean hasReduceCoupon = combination.stream().anyMatch(c -> "满减券".equals(c.getType())); boolean hasNewUserCoupon = combination.stream().anyMatch(c -> "新用户专享".equals(c.getType())); // 新用户券与其他券互斥 if (hasNewUserCoupon && combination.size() > 1) { return false; } // 打折券与满减券互斥 if (hasDiscountCoupon && hasReduceCoupon) { return false; } return true; } private static CouponUsageResult calculateResult(Order order, List<Coupon> usedCoupons) { BigDecimal finalAmount = order.getTotalAmount(); // 按照优先级顺序应用优惠 for (Coupon coupon : usedCoupons) { if ("打折券".equals(coupon.getType())) { finalAmount = finalAmount.multiply(coupon.getDiscountRate()); } else if ("满减券".equals(coupon.getType()) || "无门槛5元券".equals(coupon.getCondition())) { finalAmount = finalAmount.subtract(coupon.getDiscountAmount()); } else if ("免邮券".equals(coupon.getType())) { // 免邮券单独处理运费 finalAmount = finalAmount.subtract(coupon.getDiscountAmount()); } } return new CouponUsageResult(finalAmount, usedCoupons); } } 运行测试：[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0 [INFO] All tests passed! 绿色阶段成功：测试通过，复杂的业务逻辑完全正确。🔵 重构阶段：优化代码质量在测试保护下，对AI生成的代码进行质量优化：public class CouponEngine { // 提取常量，增强可读性 private static final Set<String> MUTUALLY_EXCLUSIVE_TYPES = Set.of("打折券", "满减券"); private static final String NEW_USER_COUPON_TYPE = "新用户专享"; public static CouponUsageResult calculateOptimalUsage(Order order, List<Coupon> availableCoupons) { if (CollectionUtils.isEmpty(availableCoupons)) { return new CouponUsageResult(order.getTotalAmount(), Collections.emptyList()); } // 使用策略模式优化条件验证 List<Coupon> eligibleCoupons = availableCoupons.stream() .filter(coupon -> CouponValidator.isEligible(order, coupon)) .collect(Collectors.toList()); // 使用组合算法优化券组合生成 List<List<Coupon>> validCombinations = CouponCombinator.generateValidCombinations(eligibleCoupons); // 使用计算引擎优化折扣计算 return validCombinations.stream() .map(combination -> DiscountCalculator.calculateResult(order, combination)) .min(Comparator.comparing(CouponUsageResult::getFinalAmount)) .orElse(new CouponUsageResult(order.getTotalAmount(), Collections.emptyList())); } } // 职责分离：券验证器 class CouponValidator { public static boolean isEligible(Order order, Coupon coupon) { return AmountValidator.validate(order, coupon) && UserLevelValidator.validate(order, coupon) && CategoryValidator.validate(order, coupon); } } // 职责分离：券组合器 class CouponCombinator { public static List<List<Coupon>> generateValidCombinations(List<Coupon> coupons) { return PowerSetGenerator.generate(coupons).stream() .filter(MutualExclusionChecker::isValidCombination) .collect(Collectors.toList()); } } // 职责分离：折扣计算器 class DiscountCalculator { public static CouponUsageResult calculateResult(Order order, List<Coupon> usedCoupons) { // 按优先级排序券，确保计算顺序正确 List<Coupon> sortedCoupons = usedCoupons.stream() .sorted(Comparator.comparing(CouponPriorityResolver::getPriority)) .collect(Collectors.toList()); BigDecimal finalAmount = order.getTotalAmount(); for (Coupon coupon : sortedCoupons) { finalAmount = applyCouponDiscount(finalAmount, coupon); } return new CouponUsageResult(finalAmount, usedCoupons); } private static BigDecimal applyCouponDiscount(BigDecimal currentAmount, Coupon coupon) { return CouponTypeHandler.getHandler(coupon.getType()) .applyDiscount(currentAmount, coupon); } } 重构验证：[INFO] Tests run: 3, Failures: 0, Errors: 0, Skipped: 0 [INFO] 重构完成，测试持续通过，代码结构更清晰，职责分离更明确 协作模式转变：开发者不再需要为如何描述复杂的业务规则而烦恼，现在只需专注于设计精确的测试场景——我们负责定义“做什么”和“预期结果”，而AI则负责实现具体的“怎么做”。这种明确的分工让复杂逻辑的开发变得既可控又高效。通过这种方式，我们能够确保：需求表达精准无歧义边界条件全面覆盖实现过程完全可控重构过程安全可靠当需要开发新场景时，只需新增测试用例即可，完全不必担心会破坏原有逻辑。这种开发模式不仅提升了效率，更确保了系统的稳定性和可维护性。五、实践要点5.1 环境配置确保AI Agent能执行mvn test命令设定明确的行为准则（Rule），让AI能够知道我们现在遵循的开发范式，防止AI为了通过测试”作弊”修改业务代码。一个借助TDD思想驱动代码生成的执行准则如下# AI Agent 行为准则：TDD 测试驱动开发 ## 1. 总则 ### 1.1. 概述 为了确保 AI Agent 遵循 TDD（测试驱动开发）的开发模式，Agent 必须严格按照 **Red-Green-Refactor** 三个阶段的循环进行开发。在执行每个阶段前，Agent 必须向开发者明确声明其当前所处的阶段。 本准则旨在确保 Agent 遵循正确的 TDD 开发流程，避免跳过关键步骤。 ### 1.2. 环境配置：强制使用指定的 settings.xml **核心要求**: 所有对 `mvn@ 命令的调用（如 mvn test@, mvn compile@ 等），都**必须**使用 --settings@ (或 -s@) 参数来指定一个自定义的 settings.xml` 文件，以确保能够访问内部的 Maven 仓库。 - **命令格式示例**: `mvn --settings [settings.xml的绝对路径] test` - **`settings.xml` 文件路径**: `[settings.xml的绝对路径]` Agent 在执行任何 Maven 命令前，必须确认此路径已被正确配置和使用。 --- ## 2. TDD 三阶段循环 ### 2.1. 第一阶段：RED (写失败的测试) #### 2.1.1. 目标 编写一个**必然失败**的测试用例，明确定义即将实现的功能需求。 #### 2.1.2. 核心准则 - **允许**: Agent 可以在 `src/test/` 目录下创建新的测试文件或添加新的测试方法 - **要求**: - 测试必须是失败的（因为对应的实现代码尚未存在或不完整） - 一次只测试一个功能点 - 测试代码要简单清晰 - 测试名称要明确表达测试意图 - **禁止**: Agent **不能**修改 `src/main/` 目录下的任何现有代码 - **验证**: 运行测试必须显示红色（失败状态） #### 2.1.3. 交互示例 - **开发者提示**: "我需要实现一个计算器的加法功能" - **Agent 回应**: "已激活 **RED 阶段**。我将先编写一个失败的测试用例来定义加法功能的需求。" ### 2.2. 第二阶段：GREEN (让测试通过的最简实现) #### 2.2.1. 目标 编写**最简单**的实现代码，让当前失败的测试通过。 #### 2.2.2. 核心准则 - **允许**: Agent 可以创建、修改 `src/main/` 目录下的代码 - **要求**: - 优先考虑最简单的实现方式 - 专注于满足当前测试用例 - 快速实现功能让测试通过 - **禁止**: - **不能**修改测试代码 - **不考虑**代码质量和性能优化 - **不进行**过度设计 - **验证**: 运行测试必须显示绿色（通过状态） #### 2.2.3. 交互示例 - **Agent 回应**: "已激活 **GREEN 阶段**。我将实现最简单的代码来让刚才的测试通过，不考虑优化和设计。" ### 2.3. 第三阶段：REFACTOR (重构优化) #### 2.3.1. 目标 在保持测试通过的前提下，改进代码的设计、质量和可维护性。 #### 2.3.2. 核心准则 - **允许**: Agent 可以重构 `src/main/` 目录下的实现代码 - **要求**: - 改进代码设计和质量 - 消除重复代码 - 提高代码可读性和可维护性 - 每次重构后必须运行测试确保通过 - **禁止**: - **不能**修改测试的行为和期望 - **不能**破坏现有功能 - **验证**: 重构过程中和完成后，所有测试必须保持绿色 #### 2.3.3. 交互示例 - **Agent 回应**: "已激活 **REFACTOR 阶段**。我将重构代码以提高质量，同时确保所有测试保持通过状态。" --- ## 3. TDD 最佳实践 ### 3.1. 循环节奏 - **小步快走**: 每个 Red-Green-Refactor 循环应该很短（几分钟到十几分钟） - **频繁验证**: 每个阶段完成后都要运行测试验证 - **逐步推进**: 一次只关注一个小功能点 ### 3.2. 测试质量要求 - **快速执行**: 单元测试应该在秒级内完成 - **独立性**: 测试之间不应该有依赖关系 - **可重复性**: 测试结果应该是确定的和可重复的 - **清晰命名**: 测试方法名应明确表达测试意图 ### 3.3. 代码质量保证 - **持续重构**: 在每个循环的 REFACTOR 阶段改进代码 - **消除重复**: 遵循 DRY（Don't Repeat Yourself）原则 - **保持简洁**: 代码应该简洁明了，易于理解 ### 3.4. 流程控制 Agent 在每个阶段转换时，必须： 1. 明确声明即将进入的阶段 2. 说明当前阶段的具体目标 3. 完成阶段后验证结果 4. 确认是否继续下一个循环 5.2 掌握单测语法AI擅长基础用例覆盖，但复杂业务场景、边界条件仍有可能需要开发者手动编写。不要完全依赖AI构造用例。5.3 选择合适场景与策略快速决策法则：简单功能：单个方法，逻辑直观，采用“先实现，后验证”；复杂业务逻辑：多分支判断、算法计算、状态转换，采用TDD“先验证，后实现”；存量代码修改：采用“安全网保护”策略；提示词难以描述需求时：测试用例是最好的需求文档，采用TDD让代码直接表达需求。5.4 持续维护单元测试必须与业务代码演进保持同步。一个过时的、无人维护的测试集，其价值会迅速归零，甚至成为负资产。六、结语如今，单元测试已被赋予全新的意义——它不再被视为一种“开发负担”，而是进化成为AI Coding时代的“质量引擎”。我们构建起三重关键保障：策略一：以客观检验替代主观判断，让AI代码告别“看起来没问题”的错觉；策略二：为存量代码筑起防护墙，使修改存量代码安全可控，降低演进风险；策略三：用测试作为与AI的沟通语言，精准传递复杂需求与预期。更深层次的变化在于，我们正在重新定义开发者的核心价值：当我们从“思考提示词”转向“思考测试用例”，本质上是从AI代码被动的审查者，转变为了主动的需求设计者与质量掌控者。这不仅加速开发进程，更显著提升代码质量。这正是AI时代中，开发者与智能工具协同进化的优秀范式。
Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
整理 | 华卫、Tina过去一年，编码 Agent 的变化速度，已经快到让人很难用“功能升级”来形容。如果把时间拨回到一年前，Agent 还主要停留在代码补全、对话式改几行代码的阶段；而今天，在 Cursor 内部，工程师已经开始同时运行多个 Agent 并行“甩活儿”，让它们在代码库中自主修改、调试、复盘，再由人类在最后阶段集中审核结果。开发者不再盯着 Agent 的每一步操作，而是开始习惯“等它跑完再看答案”。在最近一次访谈中，Cursor 工程负责人 Jason Ginsberg 给出了一个明确判断：这不是渐进式优化，而是一场正在发生的“换代”。更重要的是，他把这场变化的时间窗口，压缩到了未来三到六个月——在他看来，Agent 将不只是“更聪明”，而是会真正接管更长周期、更复杂的工程任务，整个行业的工作方式也将随之重塑。下面是详细对话内容，我们在不改变原意的基础上进行了翻译和删减，以飨读者。一年多时间，编码 Agent“翻天覆地”Harrison Chase：Jason，你能跟大家简单介绍一下自己吗？也给大家讲讲 Cursor 是什么吧。 Jason Ginsberg：好的。我目前在做一款 AI 编程工具，已经在 Cursor 工作了六个月，担任该产品的工程负责人。不过说实话，我日常的大部分时间还是在写代码和做设计工作。在加入 Cursor 之前，我在 Notion 负责 Notion Mail 相关工作。几年前，我创办了一家名为 Skiff 的公司，后来这家公司被 Notion 收购了。所以，我一直都在从事产品开发相关的工作，而且主要聚焦在生产力工具领域。 Harrison Chase：非常棒。我有很多话题想和你探讨。要不我先抛砖引玉，问问你对编码 Agent 的发展历程，以及这些年来人机交互模式演变的看法吧。你们可以说是这个领域的先行者之一，我认为编码 Agent 的发展经历了几个阶段的转变：从最初的代码自动补全，到集成在集成开发环境（IDE）中的对话式交互，再到如今出现的各类终端工具，以及基于云端的异步 Agent。我很想听听你的看法，你觉得这样概括其用户体验的演变历程是否准确？或者你们团队是如何看待这一发展过程的？ Jason Ginsberg：我认为编码 Agent 的发展确实可以用 “翻天覆地” 来形容，而且这些变革基本上都是在一年多一点的时间里发生的。正如你所说，Cursor 最早开启了代码自动补全的先河，这种模式主要是在逐行的层面上提供辅助，适用范围也基本局限在单个文件内。而此后，几乎每隔几个月，我们就不得不提升产品的抽象层级，这其实是一个极具挑战性的产品设计难题。显然，Agent 的出现让开发者能够在多个文件之间灵活切换，并且可以放心地让 Agent 自主完成代码修改工作。 在过去两个月左右的时间里，我发现行业又出现了新的转变：开发者现在已经能够做到从项目启动到结束全程信任 Agent，并且会对整个代码库中多个文件的内容进行批量审核。因此，我们不得不对产品的整体布局进行大幅重新设计，将核心从逐行的代码差异对比，转向更偏向代码审查的模式。 展望未来的产品开发方向，我们的工作重心其实会更多地放在多 Agent 协同运行上。我们需要实现的是，能够快速验证这些 Agent 是否在正常运行，并且可以让它们并行工作，同时避免受到当前单一对话模式下各种选项和选择的束缚。 Harrison Chase：推动这些变革的核心因素是什么？仅仅是因为大模型的性能变得越来越好，还是有其他更多的影响因素？ Jason Ginsberg：我认为大模型性能的提升是一个很关键的因素，这让开发者能够更加信任 Agent 编写的代码质量。要知道，以前大家必须对 Agent 生成的代码进行非常全面细致的审查。同时，现在也有了更完善的代码审查工具。比如我们有 BugBot，市场上其实还有很多类似的工具，它们都能够自动检查代码中存在的问题。 此外，我觉得从行业文化层面来看，开发者们对 Agent 工具的接受度和使用信心也在不断增强，甚至可以说已经 “上瘾” 于这类工具带来的便捷。而且，一旦习惯了完全依赖 Agent 进行编码的工作模式，再切换回传统的编码方式其实是很困难的。所以现在，我们能看到越来越多的开发者已经将 Agent 辅助编程作为默认的工作方式。最顶尖工程师的干活秘诀：全靠 Agent？Harrison Chase：你观察到大家使用 Cursor 的方式都有哪些不同？或者你自己平时是怎么使用 Cursor 的？ Jason Ginsberg：其实在我们公司内部，工程师们使用 Cursor 的方式就五花八门。甚至团队里有几位工程师，他们完全不使用 Cursor 的 Agent 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常依赖代码自动补全功能，日常使用中大部分操作都是基于补全功能完成的。但令人意外的是，我发现团队里一些最顶尖的工程师，我们称他们为 “核心用户”，他们做任何工作都会完全依赖 Agent，甚至会同时运行多个 Agent 并行处理任务。 至于我个人的使用习惯，我并不会去设计那些复杂繁琐的提示词，也没有什么所谓的 “Agent 使用秘籍”。我写的提示词往往都很简短，甚至还会带有拼写错误。我会针对手头不同的工作任务，或者同一个问题的不同模块，同时启动多个 Agent，然后等待它们返回结果。 目前我用得最多的是我们今天刚刚发布的一个新功能：调试模式。这个模式下，Agent 能够通过生成日志来进行自我评估，之后开发者复现相关操作步骤，Agent 就会通过查看日志判断问题是否得到解决。这个功能非常实用，因为它相当于通过投入算力去不断尝试解决问题，最终攻克那些手动排查起来极为棘手的难题。 Harrison Chase：调试模式具体是什么样的？为什么需要专门设置这样一个模式？难道不能自动完成调试吗？直接给 Agent 下达调试指令不也可以吗？ Jason Ginsberg：其实我也认同你的这个想法。所以在开发调试模式的时候，我们内部确实有过不少争论。主要原因在于，Cursor 目前已经有很多功能模式了，如规划模式、询问模式等等，这些模式其实不太容易被用户发现。我们一直认为，这些模式都很实用，理想的状态应该是，Agent 能够根据用户的操作场景，自动匹配并启用最合适的模式，无需用户手动切换。 而现阶段调试模式之所以需要手动开启，是因为它的交互方式比较特殊。在运行过程中，Agent 会暂停当前的工作，向用户提问以获取反馈。如果用户不熟悉这种交互逻辑，可能会觉得比较困扰。 Harrison Chase：Agent 具体会询问哪些问题，又需要用户提供什么样的反馈呢？ Jason Ginsberg：我举个例子吧。假设我正在开发一个前端应用，遇到了一个很让人头疼的问题：菜单总是在左上角弹出。这时候我会对Agent说：“这个菜单需要锚定到按钮的位置。” 随后，Agent 会启动服务器，并在整个代码库中添加大量日志，同时提出一系列可能导致该问题的假设，如 “可能是某个定位参数设置错误”、“可能是事件绑定逻辑有问题” 等。之后，Agent 会提示我：“麻烦你点击这个按钮，打开菜单，看看问题是否解决。” 如果我反馈问题依然存在，Agent 就会查看生成的日志，然后分析判断：“这个假设成立，那两个假设不成立”。通常这样反复两三次之后，Agent 往往就能找出并解决问题。 Harrison Chase：你觉得人类还需要手动操作多久？就不能让 Agent 自主完成点击、测试这类操作吗？ Jason Ginsberg：一两个月内，毕竟这个行业的发展速度实在太快了。 Harrison Chase：刚才你提到了 Agent 的多种不同模式，比如规划模式、解释模式、调试模式等等。这些模式在实际应用中到底意味着什么？难道只是为 Agent 设置不同的提示词这么简单吗？还是说背后有更复杂的逻辑？ Jason Ginsberg：很多时候，确实就是修改一下系统层面的提示词。不过在某些情况下，我们也需要对用户界面进行相应的调整。比如规划模式现在也加入了交互提问功能，运行过程中会主动打断用户操作，寻求反馈。用户有时也可以自行设置参数，如调整 Agent 打断的频率等。再比如询问模式，它不只是依赖特定的系统提示词，还会限制 Agent 调用某些与文件编辑相关的工具，以此来保证功能的稳定性和可靠性。 Harrison Chase：回到之前的话题，关于大家使用 Cursor 的不同方式，你觉得未来使用编码 Agent 或者说 Cursor，存在所谓的 “最佳方式” 吗？ Jason Ginsberg：我觉得并没有什么 “最佳方式”，具体的使用方法很大程度上取决于工程师的个人工作习惯以及他们所处理的具体工作内容。目前行业里，既有异步运行Agent的应用场景，也有开发者深度参与、实时交互的模式，就像一边编程、一边像画画一样实时调整代码或者进行可视化的编辑操作。不过我经常在推特上看到一些所谓的 “Agent 使用技巧”，其实对此我是有点持保留态度的。很多人会说 “这才是使用 Agent 的最佳方式”，但在我看来，这些技巧往往是凭空杜撰的。 我们团队内部其实并不会使用那些冗长复杂的提示词，也不会采用多阶段规划的策略。大多数时候，我们都是快速迭代，如果 Agent 运行的结果不理想，就直接终止进程，重新启动 Agent。通常这种方式的效率是最高的。自然 “唠嗑”是 Cursor 最终交互模式？Harrison Chase：如果让你预测一下一年后的情况，你认为开发者在 IDE、终端以及其他形态的载体上使用 Cursor 的时间占比会是怎样的？ Jason Ginsberg：当然，我肯定会带有一定的主观偏向性。但我认为，终端工具并不会成为用户的首选。我觉得，真正驱动行业发展的是用户对Agent的信任度不断提升，他们更希望等到Agent完成所有工作后再查看最终的修改结果，然后决定是否采纳，同时也愿意让 Agent 运行更长的时间，以实现更智能的处理。 而 IDE 之所以至关重要，是因为它是为整个软件开发周期量身打造的工具。从项目的构思规划，到运行代码修改、查看代码内容、清晰对比代码差异、提交代码合并请求，再到在浏览器中预览效果所有这些环节，都可以无缝集成在 IDE 的模块化功能之中。这一点其实很容易被忽视，毕竟 IDE 的这些功能是经过了数十年的发展才逐步完善起来的。 我认为，当前行业的一个明显趋势是，产品层面的设计变得越来越重要。现在 Cursor 用户使用频率最高的功能，如规划模式，其实都需要可视化编辑器的支持，用户需要能够在编辑器中添加注释，并进行实时交互。一旦脱离了按钮、弹窗和菜单这些可视化交互元素，用户与工具的交互难度会大大增加。 不过，我觉得未来并非所有操作都必须局限在笔记本电脑的 IDE 中完成。这种模式并不会被完全取代，具体的使用场景会根据实际需求灵活变化，适用的场景也会更加广泛。用户在更多场景下，都能够使用到 Cursor 这样的工具。 Harrison Chase：未来会有更多场景都能用上像 Cursor 这样的工具。你们应该有对应的官网吧？用户可以直接在网页上进行交互操作，是这个思路吗？ Jason Ginsberg：对，我们确实有官网。这么做的原因是用户可以通过手机等设备随时随地访问。我觉得在不远的将来，用户完全可以戴着 AirPods，开启语音模式，和Agent实时沟通、碰撞想法，让Agent不断优化方案。等用户到了办公室，打开笔记本电脑，就已经有一堆代码修改记录或者演示视频等着审核了，到时候只需要简单确认通过或者驳回就行。如果某些细节还需要微调，再把项目下载到本地修改就好。 Harrison Chase：我认为 Cursor 真正的优势，在于围绕 Agent 交互打造的整套设计和用户体验体系。你之前在 Notion 工作过，我记得即便是在生成式 AI 普及之前，Notion 的设计和用户体验就已经广受认可了。当然，他们在生成式 AI 时代也很好地完成了转型。从一家在生成式 AI 普及前就拥有出色设计积淀且顺利完成转型的公司，再到如今专注 Agent 相关工作，你觉得 Agent 的出现给产品设计和用户体验带来了哪些变化？现在的工作模式和之前有相似之处吗？ Jason Ginsberg：我觉得总体来说，我们产品的大部分设计其实并不是 AI 专属的。要知道，产品可用的交互组件和用户体验模式就那么多，市面上的应用本质上也都是基于一些传统的模式搭建的，如收件箱、仪表盘、聊天界面，这些都是很成熟的设计。所以我们的工作核心，更多是把这些现有的设计模式进行合理组合，然后在产品中恰当地呈现出来。这一点和 Notion 的产品理念是相通的，同时也是 Cursor 和集成开发环境（IDE）的核心特质：极高的模块化程度。 作为用户，你会发现每个人的 IDE 界面布局都可以千差万别。你可以自定义面板布局，把任意组件拖放到任意位置，和坐在你旁边的同事设置出完全不同的界面。我认为这种模块化设计对产品的适应性至关重要，毕竟如我之前所说，Agent 的能力发展日新月异，用户对产品的需求和期待几乎每隔几周就会发生变化。几个月前我们推出 Cursor 2.0 的时候，并没有把原来的产品推倒重来，只是把各个功能模块重新组合，调整为侧边栏收件箱式的管理布局，同时优化了聊天界面的信息密度而已。 Harrison Chase：听你这么说，很多组件的底层逻辑其实是相通的。那有没有出现新的组件？或者某些组件的优先级发生了变化？毕竟这些组件最初都是为 “人类与软件交互”“人类通过软件协作” 的场景设计的，现在加入了 Agent 这个新角色。这其中有没有产生什么新的变化？还是说其实本质上没有太大不同？ Jason Ginsberg：我认为底层的设计逻辑和核心要素其实没有变，关键变化在于谁在主导界面交互。而在这个核心框架下，其实可以演变出无数种交互形式。就拿交互的抽象层级来说，一年前大家使用Agent的时候，都恨不得盯着它的每一步操作，全程 “盯梢”。但现在 Agent 的操作步骤变得无比繁杂，用户根本看不过来。所以我们需要优化信息呈现方式：如何对操作步骤进行分组？如何提炼关键信息？ 当用户足够信任 Agent 的操作后，我们就需要把重点放在文件的实际修改内容上，并且为这些修改添加更详细的注释说明。当然，我们也可以进一步提升交互的灵活度，比如聊天对象不再局限于单个 Agent，而是可以同时和多个 Agent 对话。这就需要一套更智能的后台交互逻辑来支撑 ，系统要能识别用户在和哪个子 Agent 对话，并且协调这些 Agent 完成对应的修改。未来这种交互的抽象层级还会不断提升。 Harrison Chase：你觉得交互的抽象层级最高能达到什么程度？我知道预测未来很难，但还是想听听你的看法。 Jason Ginsberg：我觉得未来，我们现在看到的各种操作选项，如选择模型、选择功能模式、选择运行环境这些都会逐渐消失。最终的交互模式会变得像和真人对话一样自然。但这并不意味着任何人都能随便写代码，在那个阶段，这个工具依然是为专业工程师服务的。因为你还是需要具备专业的行业术语知识，清楚自己想要修改的内容是什么。做产品的人，要明确自己想要的工作流程和功能需求；做基础设施的人，要足够了解代码库，知道什么样的架构和系统设计最适合当前要开发的项目。 而且我想强调的是，随着抽象层级的提升，我们并不会摒弃现有的功能。用户依然可以随时深入底层，查看细节、调整参数。只是产品的默认交互方式会不断优化升级。Cursor 内部工作揭秘：少审代码、高频反馈Harrison Chase：你之前提到了人类在 Agent 工作流程中的角色，比如查看代码差异、进行代码审查。你觉得 AI 会给代码审查工作带来哪些改变？ Jason Ginsberg：首先，就我们产品团队的工作模式来说，现在人工审查的比重已经大幅降低了。我们有一个叫 BugBot 的工具，它会自动检测代码问题，并且自主完成修复，还会在持续集成（CI）流程中不断迭代优化。这个工具的表现非常出色，也让我们对 AI 审查的代码质量更有信心。 其次是信息的语义化分组。用户查看代码差异时，可以清晰地看到 Agent 做了哪些修改。我们甚至可以展示 Agent 的原始指令，更理想的状态是，Agent 能够像人类一样，在处理大型代码合并请求时，为每一处修改附上注释，说明这么做的原因。我觉得这虽然算不上颠覆性的变革，但确实能给代码审查工作带来显著的优化。 Harrison Chase：出于好奇，我想问一下，Cursor 的工程师用 Cursor 写代码，用 BugBot 审查代码，那他们还需要和其他工程师沟通协作吗？ Jason Ginsberg：哈哈，这个问题很有意思。如果你以工程师的身份加入 Cursor，会立刻发现一个现象：所有人都在深度使用自家产品。我记得我入职第一周的时候，修改了一个快捷键设置。那个快捷键是 Alt+Shift+Command+J，非常冷门，我当时觉得选这个键肯定没人会注意到。结果刚改完不到半分钟，就有三个同事在 Slack 上发来消息：“你改的这个快捷键直接打乱了我的工作流程！到底怎么回事？”几乎任何产品改动，都会立刻收到同事们的强烈反馈。我觉得这其实是一件好事，大家就是在这种高频的反馈和交流中，快速推进产品迭代的。 Harrison Chase：从组织管理的角度，你们有没有采取什么措施来鼓励或者引导这种高频反馈的协作模式？毕竟大量的反馈涌进来，有时候也会让人应接不暇。 Jason Ginsberg：在我创办自己的公司之前，工程师们也会用邮件沟通，但用得并不多。大家甚至会说：“邮件只用来收垃圾邮件和购物通知，可别用它来发长篇大论的工作内容。”而在Agent这个赛道工作，其实完全不需要依赖邮件这种低效的沟通方式。我们团队的所有人都全身心投入工作，毕竟这是一个竞争非常激烈的领域，大家都对产品开发充满热情，会自然而然地用各种即时沟通工具协作。 另外，我在规划产品功能时，会遵循一个核心原则：我能开发什么功能，让自己的日常工作更轻松？ 具体来说，就是思考 “做什么能帮我明天更高效地完成工作，不用再处理那些烦人的报错和问题”。这个原则指导着我们的大部分工作。毕竟这种功能开发出来之后，我们自己能立刻受益，比如修复了一个烦人的漏洞，以后上班就不用再被这个问题困扰了。迭代狂飙背后，核心功能竟来自员工 “自嗨”？Harrison Chase：你觉得你们的产品路线图，有多大比例是由 “让自己工作更轻松” 这个需求驱动的？又有多大比例是来自外部用户的需求？这个比例随着公司发展有变化吗？ Jason Ginsberg：这个比例确实随着公司规模的扩大在变化。现在我们也会制定月度的产品路线图和目标，但说实话，我们很多核心功能都来自自下而上的创新。比如 Cursor 的Agent功能，这可以说是大家提到 Cursor 时最先想到的核心功能。这个功能是我们团队的一个人开发的，最开始所有人都不看好这个想法，但他很快做出了原型。大家试用之后都惊叹：“哇，这东西居然真的能用！” 我之前提到的调试模式也是如此。感恩节假期的时候我闲着没事，就开发了这个自己很需要的功能，现在这个功能也即将上线。这些功能的开发初衷，都是为了解决团队内部的需求。我们判断一个功能是否具备发布条件，一个重要的衡量标准就是内部的使用率和认可度。 Harrison Chase：你们的产品迭代速度快得惊人，是怎么保持这种高效的开发节奏的？ Jason Ginsberg：说实话，我们的工作流程其实非常精简，没有太多繁琐的制度。公司里虽然有几间会议室，也有一两位产品经理，但我们很少通过撰写文档或者开对齐会议来推进工作，大部分的讨论和决策都是在代码层面完成的。而这一切能够实现的核心原因，是我们对人才的极高要求。今年年初的时候，公司总共也就 20 人左右。之所以团队规模增长缓慢，就是因为我们的招聘门槛高到近乎苛刻。我们会反复评估：这个人很优秀，但他能成为团队里最顶尖的那批人吗？ 正因为团队里的每个人都足够出色，所以我们可以放心地把任务交给任何一个人。团队成员的主观能动性都极强，从提出想法、设计用户体验，到在推特上回复用户的支持请求、和企业客户沟通需求，再到最终将功能落地，整个流程都能独立完成。所以说，我们能保持这样的速度，归根结底还是人的因素。 Harrison Chase：你们是如何规划产品路线图的？你刚才提到了以月为单位的规划周期，这是目前的常规规划时长吗？有没有更长期的规划？另外，行业技术迭代的速度实在太快了，你们是如何平衡 “跟进现有技术浪潮” 和 “实现技术跨越式发展” 这两者的？会不会主动预判技术趋势，提前布局未来方向？ Jason Ginsberg：我们确实会投入不少精力去思考未来，比如预判未来三个月可能实现的技术突破，然后主动押注相关方向，团队里有相当一部分人都在做这类前瞻性的工作。我们制定的月度路线图更多是围绕核心产品功能展开，聚焦于用户的实际需求以及那些能优化日常使用体验的功能。而那些需要投入两个月时间重构底层逻辑的重大项目，则会纳入更长期的规划范畴。此外，我们的应变能力其实非常强。 有时候我们会提前拿到新模型的测试版本，试用之后如果发现它在某些方面表现特别出色，团队成员往往会主动利用周末时间加班，争取在新模型正式发布前就完成相关功能的开发。很多重要功能其实几天之内就能搭建完成。 Harrison Chase：说到模型，你们发布了自研的 Composer 模型。开发这个模型的初衷是什么？目前用户的使用情况如何？这个模型有没有改变大家使用 Cursor 的习惯？ Jason Ginsberg：我们发现，工程师使用我们产品时的编码场景，需要有专门适配的模型来支撑。Composer 模型就是针对这类场景打造的，它定位非常明确，具备速度快、质量高、逻辑智能三大特点，尤其适合 “人机实时协作” 场景。我自己做前端开发时就经常用它，因为我需要频繁做出细微的交互设计决策，这就要求 Agent 能在几秒内给出反馈。Composer 就像一个高效的协作伙伴，能快速响应需求、碰撞想法，和那些适用于长周期异步任务的模型形成了很好的互补。 Harrison Chase：Cursor 的 Agent 相关研发工作是全员参与，还是有专门的团队负责？ Jason Ginsberg：我们确实有专门的团队负责 Agent 的性能优化，他们主要聚焦于工具链、调度框架的搭建以及效果评估。但正如我之前所说，我们的团队架构并不僵化，没有严格限制大家的工作范围。比如核心产品团队的工程师在开发规划模式时，如果需要对Agent进行调整，就会和Agent团队密切协作。而且在开发过程中，我们依然会深度使用自家产品进行测试，团队成员会分享使用感受，以此来评估功能的实际效果。 Harrison Chase：无论是 Agent 团队的成员，还是其他团队中擅长 Agent 研发的工程师，他们身上有没有什么共同特质？他们的专业背景或者个人能力有没有什么特别之处？ Jason Ginsberg：我觉得他们大多是偏产品方向的人才，而不是传统意义上的机器学习或算法研究专家。这些人经常在不同团队之间轮岗，因为Agent研发需要对用户的最终使用体验有很强的直觉，同时还要能准确解读团队的反馈意见。 Harrison Chase：上周你们和 OpenAI 合作发布了一篇博客，内容是针对 OpenAI 的新模型优化 Cursor 的 Agent 调度框架。我在推特上经常看到大家讨论 “Agent 调度框架” 这个概念。你们是如何看待模型的底层支撑架构的？这类架构是否需要和特定模型深度绑定？比如 Composer 模型和 CodeLlama 模型，对应的架构会不会有很大差异？ Jason Ginsberg：我其实没有深度参与这方面的工作，但据我了解，我们的核心目标是打造高度灵活的架构。毕竟我们需要不断尝试新技术、新功能模式，所以架构必须能够随着模型能力的升级快速适配。 Harrison Chase：很有道理。毕竟整个行业都在飞速变化。开放问答提问者 1：刚才提到了新增的可视化浏览器功能，我发现有些工具比如 Lovable 也有类似的功能。请问这个功能是朝着 “沉浸式可视化编码” 的方向发展吗？ Jason Ginsberg：我觉得它并不是为沉浸式可视化编码设计的。就像我之前说的，这个功能最初是我为自己开发的，我本身就是一名做产品的工程师，它的核心用户群体其实是专业工程师和设计师。大家在开发应用时，肯定都遇到过这种情况：精心设计的界面，最后却变成了大家都看腻了的紫黄渐变配色。这个功能就是为了让大家能够精准把控细节，比如把内边距调整到精确的像素值。它为用户提供了一套更直观的 “视觉化操作语言”，比纯文本指令的精度更高。 而且就算不使用侧边栏，你也可以直接点击页面元素，随时输入提示词下达指令。借助这个功能，你可以在几秒内同时启动六个 Agent。如果开启热重载功能，你的网站会实时呈现修改效果，用起来其实还挺有意思的。 提问者 2：我特别喜欢你们的浏览器 Agent，一直在用。但我发现一个小瑕疵：我想持续迭代优化设计方案，可 Agent 总是会中断我的工作，直接提交代码合并请求。未来有没有可能实现不间断的持续迭代？ Jason Ginsberg：当然可以。未来的发展方向就是让 Agent 具备自主评估能力，根据需求长时间持续运行、循环迭代。现在的调试模式还需要人工点击按钮来确认日志信息，但这只是过渡方案。理想的状态是，Agent能够自主完成评估、迭代，直到彻底解决问题。 提问者 3：我不知道你是否深度参与 Agent 相关的研发工作，但我注意到 Cursor 的内存管理功能做得很好。它可以根据工程师个人、部门乃至整个公司的偏好、规则和流程，自主管理相关信息。我们都知道，信息和上下文对 Agent 来说至关重要。请问你们有没有计划进一步拓展和升级这个功能？尤其是在长上下文处理方面，你们有什么思路？ Jason Ginsberg：我们正在进行大量的实验和探索。目前已经落地了规则管理、内存记忆、技能库等多个功能模块。现阶段，我们主要在研究高效的信息摘要技术。另外，借助我们的自研模型，我们也在探索让模型自主识别对话或代码中反复出现的关键信息。当然，跨组织的信息共享功能也很值得探索。不过这里有个需要注意的点，相关规则和信息可能会随着模型的迭代而过时。所以我们必须确保用户能够轻松更新这些内容，避免被过时的规则束缚。 提问者 4：关于你们发布的 Composer 模型，我认识一些开发者，他们基于 Gemini 模型微调了一个医疗领域的专用模型。但他们发现，这个微调后的模型效果还不如直接用原生 Gemini 模型做单次提示词调用。他们分析的原因是，微调模型需要持续维护，要跟上 Gemini 等基础模型的更新节奏。请问你们是如何制定策略，确保 Composer 模型不会落伍的？ Jason Ginsberg：你说的是 Composer 模型，对吧？我们会持续对它进行迭代优化，它并不是一个静态的模型。我们的核心关注点，是在速度和智能之间找到最佳平衡点，满足 Cursor 用户在大部分场景下的需求。不过在长上下文处理这类特定领域，我们确实还有提升空间。 提问者 5：我自己是产品经理，一直在用 Cursor 做原型开发，甚至在团队里还客串设计师，用它替代 Figma。我很好奇，有没有用户是在使用 Cursor 之前，从未安装过任何集成开发环境（IDE）的？这类用户会不会成为你们未来重点关注的群体？毕竟现在的编码 Agent 已经足够强大，很多工作都能在上面完成。 Jason Ginsberg：坦白说，我们目前并没有把这类用户作为核心关注点。当然，我们认同工具的使用门槛确实需要不断降低，而且 Cursor 的易用性也在持续提升，比如新增的浏览器工具对设计师就很友好。但我们的核心目标，其实是赋能顶尖工程师。我们一直在思考：如何让世界上最优秀的工程师变得更加强大？在这个过程中，我们开发的工具自然会惠及更多人群。不过在产品优化方面，我们确实还有很多工作要做，如优化新手引导和环境配置流程。毕竟设计师和产品经理在配置 GitHub 等工具时，经常会遇到困难。我们希望通过优化这些环节，吸引更多用户尝试 Cursor。 提问者 6：我一直在尝试用 Cursor 做智能合约的验证矩阵构建和试运行逻辑测试。请问在深度质量检测和安全加固方面，有没有什么不太为人知的实用工作流可以推荐？或者刚才提到的调试工具能不能派上用场？我对智能合约的质量检测特别感兴趣。 Jason Ginsberg：说实话，我们正在尝试让 Agent 自主完成测试工作，不过这项功能目前还没有完全发布。对于从事质量检测工作的人员来说，我强烈推荐试试我们刚发布的调试模式。这个功能定位问题的逻辑非常清晰，几乎可以说是确定性的，用起来会很有帮助。 提问者 7：您认为未来两到四个月，Cursor 面临的最大机遇是什么？会不会是语音 Agent？ Jason Ginsberg：我觉得机遇不在于语音 Agent。用户现阶段最核心的需求，其实是让 Agent 变得更智能、运行时间更长、能处理的任务更多。现在的很多 Agent，本质上只是在 “读取代码”，并不能真正判断修改后的代码是否有效。未来的发展空间非常大，我们可以投入更多算力，让 Agent 承担更多人类目前负责的校验工作。我觉得未来三到六个月，整个行业都会迎来巨大的变革，非常值得期待。 参考链接：https://www.youtube.com/watch?v=dKSGK-fPFyU