xiaohack's Blog - 软件开发
type: channel
link: https://blog.xiaohack.org/tag/%E8%BD%AF%E4%BB%B6%E5%BC%80%E5%8F%91/
items: 分享一个编程 AI 实测项目 — You
items: 前端没有实际的必要了？结合今年工作内容，谈谈我的看法
items: 科技爱好者周刊（第 382 期）：独立软件的黄昏
items: 智能体对软件 / 互联网开发行业的冲击
items: Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
items: 把你的需求告诉我，我来免费帮你实现！
items: AI 狂热的冷思考
items: 当前关于 Vibe Engineering 的所有认知都会在 1 个月内严重过时
items: AI Coding与单元测试的协同进化：从验证到驱动
items: Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局

分享一个编程 AI 实测项目 — You
type: item
date: 2026-01-25T08:05:30+08:00
description: 我和同事们目前正在利用 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

前端没有实际的必要了？结合今年工作内容，谈谈我的看法
type: item
date: 2026-01-23T16:17:43+08:00
description: 今天被一张《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 期）：独立软件的黄昏
type: item
date: 2026-01-23T09:38:43+08:00
description: 这里记录每周值得分享的科技内容，周五发布。本杂志开源，欢迎投稿。另有《谁在招人》服务，发布程序员招聘信息。合作请邮件联系（[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、雪宝机器人人形机器人何必一定做成人形。迪斯尼最近发布了一个机器人，样子就是电影《冰雪奇缘》的雪宝。它用来在迪斯尼乐园…

智能体对软件 / 互联网开发行业的冲击
type: item
date: 2026-01-22T16:32:30+08:00
description: 摘要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…

Node.js 之父宣判“手写代码时代结束”！DHH 明确反对“结束论”：大模型还差口气，手写更有竞争力
type: item
date: 2026-01-21T16:34:55+08:00
description: 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——因为删掉…

把你的需求告诉我，我来免费帮你实现！
type: item
date: 2026-01-21T13:23:59+08:00
description: 首先声明这个不是推广帖，也不是引战贴，标题不是噱头 帖子省流版： 对这段时间做的事情做了一些总结 大家提痛点需求，一起做一款让大家觉得爽的开源 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 狂热的冷思考
type: item
date: 2026-01-20T21:01:06+08:00
description: 我真的很反感有些人一边无脑吹捧 ai 编程，一边说手写代码是“古法编程”。大语言模型确实是一项划时代的技术，它的技术边界也在不断的被突破，但是任何技术都是有边界的。 那些无脑吹捧 AI 编程的人，我很怀疑，他们是不是陷入一种“盲目的狂热”或者“拜 AI 教”。一、编程的本质，计算机的范式（冯诺依曼架构）并没有发生改变。有人将其类比为汇编到高级语言的进化，这是完全错误的。编程语言具备正交性，你的每次运行，结果是一致的。而大语言模型的结果是非正交性的，初始值的一点微小的改变，都会对结果产生巨大的影响。编程和大语言模型在我看来，具有外在的相关性，但是本质上两者解决的是完全不同的两个问题，是求精确解和模糊解的的区别。另外，现有的所谓代码生成，从本质上看，其实不过是将过去的 ctrl+c 、ctrl+v 自动化了，仍然是对现有解决方案的“复刻”。二、从工程角度来看，ai 编程并没有降低开发的复杂度，而是从编码转移到了设计、验证等环节。有人幻想，通过 ai 可以极大的降低软件开发的复杂度，这完全是幻想。软件开发本质是对真实世界的投射和抽象，ai 编程可以降低一定的编码复杂度，但是它不可能降低真实世界的复杂度。软件开发的真正复杂的地方也从来不是编码。那些希望通过 ai 减轻码农负担的想法，终究是不现实的。别人花钱雇佣你，就是希望你来减轻复杂度的，如果你无法减少这种复杂度，或者有更廉价的方案，那别人雇佣你干什么呢？当然，我不是建议大家不要学 ai,我反对的是那些只会简单的使用，却自鸣得意的。我认为，应该从编写 agent 开始，真正的业务结合起来，而不是简单跑个页面，然后陷入一种虚假的自我满足。

当前关于 Vibe Engineering 的所有认知都会在 1 个月内严重过时
type: item
date: 2026-01-20T18:23:25+08:00
description: 过去几周，我对于 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。大概上个月我主要用着 o…

AI Coding与单元测试的协同进化：从验证到驱动
type: item
date: 2026-01-19T21:55:46+08:00
description: 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 pu…

Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局
type: item
date: 2026-01-19T20:03:41+08:00
description: 整理 | 华卫、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 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常…