xiaohack's Blog - AI编程工具
type: channel
link: https://blog.xiaohack.org/tag/AI%E7%BC%96%E7%A8%8B%E5%B7%A5%E5%85%B7/
items: AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
items: codex-session-clone 一个可以在切换供应商时把历史对话复制过去的小工具
items: 35岁危机？不，AI让25岁也成了危机
items: 我这种情况，当下有没有必要入手一个 Mac，求拔草或种草
items: IDEA Java 后端 AI 编程体验
items: 国产口粮模型选择，请投出你的一票
items: 【超详细经验贴】我用这个流程白嫖 5 年 Copilot（Microsoft365），爽用 GPT-5.2！！
items: Agent 不是渐进升级，而是要“换代”了：Cursor 工程负责人放话未来三到六个月，行业将迎来大变局

AI编程实践：从Claude Code实践到团队协作的优化思考｜得物技术
type: item
date: 2026-01-27T14:38:18+08:00
description: 一、开发痛点：为什么我们需要AI编程辅助？核心发现： AI编程工具正在重塑开发流程，但真正的价值不在于替代开发者，而在于构建人机协作的新型开发范式。Claude Code通过精准对话流设计、模块化任务分解和专业化子代理协作，在提升开发效率的同时，也面临着上下文管理、协作边界和质量控制等实际挑战。作为一线开发者，我们每天都在与复杂的业务逻辑和不断迭代的技术栈打交道。不知道你是否也遇到过这些场景：刚理清一个复杂业务流程，被打断后又得重新梳理思路；接手一个老项目，花了半天还没搞懂其中某个模块的设计思路；或者在不同项目间切换时，总要重新适应不同的编码规范和架构风格。日常开发的三个"拦路虎"：上下文切换成本高： 需求理解→技术选型→代码实现→质量验证的切换过程中，每次都要重新构建认知框架。知识传递效率低： 项目规范、架构经验分散在文档和个人经验中，新成员上手或跨模块开发时处处碰壁。开发流程割裂： 需求→设计→编码→审查各环节串行传递，信息易失真且反馈滞后。这些问题不是简单的"加人"或"加班"能解决的。我们需要的是一种新的开发范式，而Claude Code这类AI编程工具正是在这样的背景下进入了我们的视野。它的价值不在于替我们写代码，而在于成为我们的"认知放大器"和"流程协作者"。二、Claude Code核心功能解析：从工具到方法论Claude Code构建了一套完整的AI辅助开发方法论。接下来将结合团队实际使用经验，从功能特性、使用场景和设计初衷三个维度，详细介绍其核心功能：精准对话流设计：控制AI思考的艺术第一次用Claude Code时，就像面对一个热情但经验不足的实习生——如果不明确告诉他要做什么、怎么做、有什么要求，他很可能会给你一个"惊喜"。对话流设计就是解决这个问题的关键。设计初衷： 对话流设计的本质是将人类的编程思维模式转化为AI可理解的结构化交互方式，通过明确的上下文管理和约束条件设置，引导AI生成符合预期的代码结果。核心功能对话流设计通过三个关键机制控制AI的思考过程：上下文聚焦： 要求单次对话仅处理一个功能模块，避免多任务混合导致的AI注意力分散。我们曾经试过在一个对话里同时让AI处理多个模块，结果它把两个模块的错误处理逻辑混在了一起。约束明确化： 通过具体指令减少AI的自由度，比如"仅修改X包下文件"、"必须复用Y工具类"。这些约束要尽可能具体，比如不说"遵循项目规范"，而是说"使用ResultDTO作为统一返回格式，错误码规则参考ErrorCodeEnum"。增量式提问： 采用"先框架后细节"的提问策略，先让AI生成接口定义和整体框架，待确认后再逐步深入实现细节。这种方式很像我们带新人时"先搭骨架再填肉"的指导方法。使用心法启动新功能开发时，我们会创建专用对话线程，并在初始prompt中明确四件事：当前任务的功能边界和目标（做什么，不做什么。）必须遵守的技术约束和规范（用什么技术栈，遵循什么标准。）期望的输出格式和交付物（要代码？要文档？还是两者都要？）分阶段的实现计划（先设计接口，再实现逻辑，最后写测试。）真实踩坑经验处理跨模块依赖时，我们发现AI很容易"忘记"之前设定的约束。后来我们总结出一个技巧：每开始一个新的实现阶段，就简要回顾一下关键约束。比如："现在我们要处理任务交接流程，请记得：1. 使用Redis分布式锁；2. 需要修改商运关系和新商成长任务；3. 异常处理要符合规范。"Plan模式：复杂任务的系统化分解面对"实现一个完整的拜访任务系统"这样的复杂需求，直接让AI生成代码就像让一个刚入行的开发者独立负责整个项目——结果往往是逻辑混乱、漏洞百出。Plan模式就是解决这个问题的"项目管理工具"。现状与问题：我们早期使用Claude Code时，经常犯一个错误：把一个复杂需求一股脑丢给AI，然后期待它给出完美解决方案。结果通常是：实现逻辑不完整，有些边界情况根本没考虑到。模块间接口设计不一致，调用起来磕磕绊绊。技术选型不合理，用了个"看起来很酷但项目中并不适用"的方案。这其实不能怪AI，人在面对过于复杂的问题时也会手足无措。我们需要一种方法把大问题拆分成小问题，而Plan模式正是借鉴了项目管理中的WBS（工作分解结构）思想。我们的解决方案：Plan模式使用三步法分解需求：需求分析与模块划分：把整体需求分解为独立的功能模块。技术方案设计：为每个模块确定实现思路和技术选型。任务优先级排序：根据依赖关系和重要性确定实现顺序。实际操作示例：拜访任务需求拜访任务是一个简单的企业内部任务需求，在实现"拜访任务需求"时，我们通过Plan模式生成的任务清单是这样的：--- 拜访任务线上化 - 模块清单 M1: 任务创建模块 - 功能: 创建拜访任务,包含基本信息、拜访对象、参与人员 - 复杂度: Medium (需要…

codex-session-clone 一个可以在切换供应商时把历史对话复制过去的小工具
type: item
date: 2026-01-24T06:44:32+08:00
description: 简单来说就是最近在折腾 codex 反代，提升 codex 的使用体验，但是从 oauth 登录转到使用 api-key 时，发现以前的历史对话消失了，所以压榨研究出了这个小脚本 github.com GitHub - goodnightzsj/codex-session-cloner: 一个可以在切换供应商时把历史对话复制过去的小工具一个可以在切换供应商时把历史对话复制过去的小工具 一些小思考在现在的 vibe coding 时代，一些小需求真的可以很高效的解决了。这个问题从我产生解决这种需求的想法开始，到在论坛里搜索关键词没找到解决方案，再到我把 codex 仓库克隆下来丢给 antigravity 中的哈基米 3，第一次对话它就定位到了切换 provider 后历史对话消失的原因，后面告诉它用 py 脚本迁移之后就很快的给了我一个可用的版本，再丢给 chatgpt 网页版～～（codex 太慢了，小需求就没找它 debug）~~ 迭代了 2 次之后，整体用时不超过 20 分钟。而在传统古法编程的时代，要解决这个小需求，首先要读 codex 仓库定位问题，光是这一步消耗的时间起码就得在 30 分钟以上…… 对我这样的小菜鸡来说，这个时间更是得翻倍的。 哦，刚注意到 codex 代码基本是用 rust 写的，那花费时间为 0。在我花时间学会 rust 之前，我是看不大懂 rust 代码的，所以我只能等某个大手子出手才能直接无脑使用。但为了这个很小的需求，我是不大可能去学 rust 的，有这时间去玩会不香吗？我会自适应历史对话消失的小问题，又不是不能用📌 转载信息来源： https://linux.do/t/topic/1507194原作者： hello_world1024转载时间： 2026/1/24 06:44:31

35岁危机？不，AI让25岁也成了危机
type: item
date: 2026-01-23T14:53:05+08:00
description: 这两天跟朋友吃饭，又聊到了AI。即使到现在，依然有很多人坚持一个观点：AI永远不可能取代程序员，它只是一个提高效率的辅助工具。他们觉得，有了AI，程序员会变得更强，而不是消失。说实话，这种想法太乐观了，甚至可以说是在自我麻痹。我直接抛出我的结论：AI不仅会淘汰程序员，而且这个过程已经开始了。特别是对于初级和中级程序员来说，倒计时已经响了。咱们别整那些虚头巴脑的比喻，什么“工具论”、什么“驾驶员论”，咱们就实打实地看看现在发生了什么。第一，我们的工作方式彻底变了。回想一下两年前你怎么写代码？遇到不会的API，或者想不起来的语法，你会去谷歌，去百度，去Stack Overflow，去CSDN或者掘金。你会翻看别人的博客，找到解决方案，理解它，然后应用到你的代码里。现在呢？大部分时候，你只需要在IDE里敲一行注释，AI就给你补全了后面的代码。或者你直接把报错信息丢给AI，它直接给你修复后的代码。你甚至都不需要离开编辑器。这个过程省去了什么？省去了“搜索、筛选、理解、尝试”的过程。你直接得到了结果。第二，技术社区正在走向消亡。这是一个很可怕的连锁反应。因为大家都有了AI，遇到问题不再需要去搜索引擎搜了，也不需要去论坛问了。这就导致了技术博客和问答社区的流量断崖式下跌。没人搜，就没人看；没人看，就没人写。原来的技术分享生态是基于“互助”和“展示”的，现在AI把这个需求截断了。以后新的坑、新的Bug解决方案，可能再也不会出现在公开的网络上了，因为AI在它内部的数据库里就已经消化解决了。第三，也是最关键的，需求方变了。以前开发软件，流程是：产品经理 -> 需求文档 -> 程序员理解 -> 编写代码 -> 测试。现在有了像Trae这样的智能IDE，或者是各种Agent（智能体），流程正在变成：人提出需求 -> AI理解需求 -> AI生成代码 -> AI自我修正 -> 人最后确认。注意到了吗？“编写代码”这个环节，正在从人的手里，转移到AI的手里。现在的AI工具，已经不仅仅是补全一行代码那么简单了。你告诉它你要做一个什么样的功能模块，它能直接给你生成整个文件，甚至帮你把相关联的配置文件都改好。以前你需要写几百行代码来实现一个逻辑，现在你只需要用自然语言描述清楚你的逻辑。这就带来了一个残酷的数学题。如果以前一个项目需要5个初级程序员写业务代码，1个高级程序员做架构。现在有了AI，那个高级程序员配合AI，一个人就能把那5个人的活儿干完，甚至干得更快、Bug更少。那剩下的5个人去哪儿？公司是为了赚钱的，不是慈善机构。当效率提升了5倍，老板不会雇佣原来的6个人去干5倍的活，而是会裁掉那5个人，只留1个成本最低、效率最高的人。写在最后所以，别再觉得AI只是个工具了。当一个工具强导致能独立完成大部分工作时，它就成了劳动力本身。未来的软件开发，可能真的不需要那么多“写代码”的人了。我们需要的是能精准描述需求的人，是能设计复杂逻辑的人，是能判断AI生成结果对错的人。纯粹的“代码编写者”，正在消失。这不是焦虑，这是正在发生的现实。

我这种情况，当下有没有必要入手一个 Mac，求拔草或种草
type: item
date: 2026-01-23T14:00:13+08:00
description: 个人情况： Java 、Python 、go 、前端都写过 从未用过 Mac ，家里有台式机作为主力开发，还有 NAS 和轻薄本 Windows ，偶尔外出用笔记本远程家里台式 Windows 下个人开发遇到的问题 AI 总是优先使用 bash 语法，vibe coding 是经常先运行 bash 命令，看到报错再切换成 powershell ，即使增加全局 prompt 告诉它这是 windows 有时还是会失效，写的 powershell 也经常失败 很多 AI 工具对 unix 的支持比 windows 好得多，像 claude code 。一些前沿工具如 bun 也是最近才有 Windows ，而且据说还不完善 使用 wsl2 折腾过，jetbrains 系有些不能很好适配。而且如果代码在 wsl 中，jetbrains 和 vscode 系的相互跳转插件就失效了 如果新增 Mac 作为主力开发工具 考虑鱼上收一个 Mac mini 16+256 ，我有 NAS 可以开 docker ，不太需要内存和存储，也没有跑大模型的需要 有远程需要就用笔记本远程 Mac 主要是想 vibe coding 体验更好些，因为我没用过 mac ，想看看大家的意见

IDEA Java 后端 AI 编程体验
type: item
date: 2026-01-20T14:01:06+08:00
description: 模型角度 T0: claude 默认的、gemini 、chatgpt5.2 国产模型大差不大 在逻辑实现和技术方案制定上，感觉国外的这 3 个更符合我的审美。。。agent白嫖了同学的 claude code ，token 管够的情况下很爽。代码接受率很高，业务屎山也改得动，给的技术方案可落地性也很强。应该是用的国内中转的，速度稍慢。后面换了 glm code plan ，差距挺大的，只能日常处理点简单编码逻辑，尤其在提示词和代码的理解上和原生 claude 差距巨大。需要给特别明确的 prompt 才能做好。windsurf 出了 idea 的插件，自带的 swe1.5 ，感觉水平不比国产的差，速度极快，体验还不错。但是自动补全经常出不来。直接用 windsurf ide 体验更好。trae 整体可用，但用多了排队很烦。JB 家在 AI 时代整体落后了，插件的体验和原生 ide 差距还是有的。不过原生 ai ide 越强，更能体现 JB 在没 AI 时代的强大。windsurf ide 也能写 java ，ai 的配套已经挺强大了，但整个 java+spring 的编码配套还是不如 idea 的。

国产口粮模型选择，请投出你的一票
type: item
date: 2026-01-20T10:48:56+08:00
description: 之前的帖子 这可能是下一个周经帖：国产大模型哪个编程能力最顶？已经过去一段时间，现在不少模型都已经更新了，而且都支持方便的接入 claude code 等 cli 工具或者 cursor 这样的 ide 。那么，在众多的国产模型中，从你的实际体验出发，哪个国产模型才是最佳日常编码的口粮模型呢？量大管饱，能处理大多数场景的需求。来吧，分享一下你的体验！GLM-4.7:目前收集到的信息是，测试的时候效果还不错，能跟 sonet 4.0 有来有回，coding plan 也比较便宜，但是超售严重，订阅后降智严重MiniMax M2.1:也推出了自己的 coding plan ，总的来说反馈还是不错DeepSeek-V3.2：写代码还是不太行，听说 4.0 很强！kimi-for-coding：听说比较蠢，具体请反馈Doubao-Seed-Code：最近新出，还得到了阮一峰推荐 https://www.ruanyifeng.com/blog/2025/11/doubao-seed-code.html

【超详细经验贴】我用这个流程白嫖 5 年 Copilot（Microsoft365），爽用 GPT-5.2！！
type: item
date: 2026-01-20T10:35:23+08:00
description: 继 elsa 佬的免费白嫖 2-5 年 Copilot（Microsoft365），可用 GPT-5.2 - 福利羊毛 / 福利羊毛，Lv1 - LINUX DO 分享一下个人的踩坑流程一、准备材料：1.1 教育邮箱：我用的教育邮箱是美国社区大学.edu（以前薅 cursor 的邮箱留存至今）没有邮箱的佬可以看一下 Mirage 佬的：关于 “免费白嫖 2-5 年 Copilot” 如何获取 edu 邮箱！ - 福利羊毛 / 福利羊毛，Lv1 - LINUX DO关于如何成为美国大学生（bushi）申请 EDU 邮箱的教程 - 福利羊毛 / 福利羊毛，Lv1 - LINUX DO1.2 新申请的 Microsoft 账号 + 美国节点 +Chrome+GoolePay（我绑的是 ypt）ps：我用香港节点 + 支付宝验证后都是 2 年的二、验证流程：2.1 申请一年的个人版（点我直达）：（申请顺序不能变）(https://checkout.microsoft365.com/acquire/purchase?language=zh-us&market=US&requestedDuration=Month&scenario=microsoft-365-student&client=poc&campaign=StudentFree12M) ps: 我的用的是美国节点，链接里是 us（没有改 tw or hk）2.1.1 添加支付方式 GoolePay + 教育邮箱验证 >> 教育邮箱验证链接获取可能得报错（直接重新刷新个人版申请链接即可）2.1.2 添加地址（ai 生成的，地址好像不重要）2.1.3 开始支付 >> 个人版申请成功2.2 申请一月的高级版（点我直达）：（申请顺序不能变） https://checkout.microsoft365.com/acquire/purchase?language=zh-TW&market=US&requestedDuration=Month&scenario=microsoft-365-premium&client=poc&campaign=StudentPremiumFree12M 2.2.1 接着个人版申请（会显示个人版的到期时间）可能得报错（try again 多来几次即可）2.2.2 添加 Goole Pay>> 开始支付可能得报错（持续刷新几次即可）2.2.3 高级版验证成功三、关闭自动续订3.1 点击管理订阅3.2 关闭自动续订以上纯为个人的验证流程，大佬勿喷，请指正！！📌 转载信息来源： https://linux.do/t/topic/1487019原作者： muzhiyang转载时间： 2026/1/20 10:35:21

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 功能，比如负责安全和基础设施的同事。所以，确实有一部分用户非常…

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

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