跳转到正文
莫尔索随笔
返回

AI 编程工具生态与协作:深度解析 IDE、Terminal、Cloud 模式

预计 12 分钟

第一时间捕获有价值的信号

将昨天晚上直播(聊聊 AI 编程工具生态和 AI 编码协作技巧)的一些观点整理成文字稿,因为直播时间有限且主要是一个 QA 的方式,所以很多观点没有补充足够的上下文,可能让听众听起来有些跳脱。

本文将系统拆解当前 AI Coding 工具的主流产品形态,探讨它们的演进方向,并结合实际协作经验,分享如何借助 Claude Code 等工具构建高效的开发工作流,迈向”人协作 AI”的下一阶段。

当前 AI Coding 工具的不同产品形态

ai-coding-tool-ecosystem-and-agent-collaboration-1

严格来说产品形态是 5 种,但是可以合并为 3 种,分别是:

  1. 独立 IDE(及 IDE 插件)
  • 国外:Cursor、Github Copilot、Windsurf、Cline、Augment Code
  • 国内:文心快码、通义灵码、腾讯 CodeBuddy、Trae
  • 开源版:RooCode、Zed

IDE 能力基本就是三大块:自动补全(Autocomplete):这是最基础、最高频的能力,它以实时、行内代码建议的形式存在;聊天(Chat):这是交互式的对话层,开发者可以通过自然语言提问、解释代码、生成代码片段;智能体(Agent):这是自主执行层。AI 不再被动响应,而是能够主动规划、执行跨越多个文件和步骤的复杂任务,如完成一个功能开发或修复一个 bug。

  1. Terminal
  • 国外:Claude Code、Codex Cli、Gemini Cli
  • 国内:Qwen Code、Kode 等
  1. Cloud(及 Github bot 模式)
  • Codex、Devin、OpenHands(有开源版本)

当然还有一些小众玩家:Amp、Aider、Kilo Code 等

在 Github CI/CD 流程上通过指定 Agent,实现自动 bug 修复、冲突处理或 Code Review 功能,在流程上和 Cloud 模式一致的,还是启动了一个云端隔离环境(做糙一点的只读取当前 issue 的上下文,这种我觉得不靠谱 🙂‍↔️),下载仓库,读取项目进行操作,下面是当前的一个数据情况(PR 总提交数与成功合并数)。

Github Agent 模式PR提交情况

我目前就是 Github Copilot + Claude Code 固定组合,其他都是尝鲜后日抛了。

更看好哪种发展路径?理想的 AI Coding 工具形态是怎样的?

理想状态肯定是纯 Cloud 模式,现在的 IDE、Terminal 情况下,人和 AI 还是在同一个界面下做同步协作,一点都不优雅,Cloud 模式同时启动多个,分配完任务,自己干就完了,那肯定是未来,上限更高。 Cloud 模式第一个吃螃蟹的肯定是 Devin,虽然现在大家不讨论了,但是人家 B 端营收增长很猛(两周前刚以 102 亿美元估值完成 4 亿美元 C 轮融资),妥妥数字员工,10 倍生产力路线。

但是程序员大多很挑剔,需要有掌控感,短期内肯定是三种形态并存的,而且把三种形态的产品状态打通是最好的,目前就 OpenAI 的 codex 做到了,在同步(人机协作)和异步(云端自运行)模式无缝切换。 ai-coding-tool-ecosystem-and-agent-collaboration-3

但是 IDE (对标 Cursor)和 Terminal(对标 Claude Code)形态产品体验比较拉垮,完全是眼红竞品的 KPI 产物。

AI 在编码过程中的主要发力点

不同细分任务,需要的能力有差异。 ai-coding-tool-ecosystem-and-agent-collaboration-4

在哪些场景下体验流畅?在哪些场景下会遇到瓶颈或感到挫折?

  • 流畅体验:
    • 简单任务和原型开发: 不懂代码的产品经理和设计师也能借助 AI 编程工具制作 demo 或简单工具。
    • 结构化、小规模的任务: AI 在结构化的开发模式中能发挥更大价值,例如测试驱动开发(TDD)。Claude Code 在处理具体且结构化的任务时表现出色,如实现用户资料编辑功能或执行 Git 工作流自动化。
    • 上下文充分的场景: 生成高质量代码的关键在于提供充分的上下文信息,而优秀的现有代码就是最好的上下文来源。
  • 瓶颈与挫折:
    • 复杂的架构设计和需求分析: AI 辅助编程仍有其局限性,无法胜任需求分析、复杂架构设计和调试等核心任务。只要需求足够复杂,就需要程序员的介入。
    • 上下文长度受限: AI 编程面临上下文长度受限、缺乏环境感知能力等挑战。对于大型代码库(比如文件数超过 10 万行),需要采用分层或增量分析等策略。
    • 安全漏洞: 曾有 AI 编程工具被发现存在严重的安全漏洞,攻击者可通过提示注入修改配置文件,实现恶意代码执行。
    • 指令碎片化: 不同的 AI 工具自带一套独特的指令配置方法,导致开发者不得不学习和维护大量专有格式的配置文件,增加了在不同工具间切换的成本。

AI Coding 的能力与局限

只要写好提示需求文档Prompt Requirements Document, PRD ,一条指令可以生成一个数万行代码的完整前端项目,比如我利用 nano banana 模型 API 实现的一个制作漫画的工具,支持脚本创作、分镜设计和角色风格控制和一致性。

但是语料和数据决定模型能力,各家擅长编码的旗舰模型,在 TypeScript 和 Python 语言上效果出众,但在 C++和 Swift 等语言上就表现很差,而且让这些模型去写 Linux 内核代码,即使你的提示词强调了模仿 Linus 代码哲学,但是模型写出来的东西也是邯郸学步,我认为这是在架构理解上的注意力分配问题,资深的基础设施工程师能一眼看出问题在哪,也能意识到系统的脆弱点,模型做不到,即使你把大量的文档塞给它,它给出的解决方案也平平无奇。

流程 > 工具 > 模型

Coding 协作流程设计 > Coding Agent 工具设计 > 模型选择

这是我和其他老师看法完全相左的一个观点,旗舰模型层面 Claude 4.1,Gemini 2.5 Pro,GPT-5-Codex 等之间写代码差距不是很大,而且各有所长,我觉得更关键的是 Agent 工具和 Coding 协作流程设计。

  1. 前端审美:Claude 4 > DeepSeek 3.1 >= Claude 3.7 > GLM-4.5 > K2
  2. Gemini 2.5 Pro:debug 能力强;长上下文处理好;设计算法无敌;写代码容易过度设计,废话多。
  3. Claude 4:适合新项目初始化,结构搭建和功能完成度高;准确度较高;bug 修复能力一般,容易陷入复杂化;精确且语言为英语的指令响应的更好。
  4. DeepSeek 3.1:后端开发不行,训练数据旧,对国外常用框架支持不足。

我自己的日常习惯是 Claude Code 额度使用完后,借助 Claude Code Route 项目,前端页面使用 DeepSeek 3.1 写,后端 API 使用 Gemini 2.5 Flash 写,算法和 debug 以及重构用 Gemini 2.5 Pro。

Coding Agent 工具设计层面 Claude Code 依然是最优雅有效的,而且生态极为繁荣(我在这篇详细介绍过十几个项目),Kiro 自带 spec 流程也可圈可点,但是也可以 DIY 集成到 CLaude Code。

最后再说下流程,在 Agent 设计里强调上下文工程,同样在 AI Coding 协作里也需要一套科学规范的上下文工程。我维护了大概 30 多个提示词,构成了从工具、项目、模块、角色、编程语言、任务、执行七个层次,然后按需提取组成一个操作的完整提示词,大多数时候是可以获得稳定的预期结果的。

ai-coding-tool-ecosystem-and-agent-collaboration-5

在多 Agent 协调方面,我专门设计了面向 Coding Agent 的任务管理系统,首先由人主导(借助 spec kit 这类工具)把需求拆分为一条条任务写入全局任务状态表,每条任务的备注字段是依赖的上下文(包括 issue 的链接,文档等,主要是方便人回溯),同时将任务分为并行(无依赖,可以有效 scale)和串行的,串行的任务和任务之间都通过状态更新,触发相应事件,然后进行下一个 Agent 执行周期,每个 Agent 执行过程的关键变更都需要向我确认,如下图所示。

ai-coding-tool-ecosystem-and-agent-collaboration-6

上述的全局状态表其实就是一个多维表格,最终可以通过仪表盘形式统计某个 Agent 完成的任务数,单个任务执行次数,时间周期,向我发的状态确认通知次数等,是一个极简版的 AI Coding 协作效能平台。

整个流程的理想状态是要进一步放权,打通研发流程和办公场景活动,实现 Agent 长期委托模式,通过统一配置,某类工作(非一次性任务)长期委托给 Agent,授予 Agent 相关权限后,后续此类工作整体由 Agent 负责,从 “AI 协作人”向”人协作 AI”迭代,毕竟这一套真的跑通,整个系统的瓶颈是人的审核效率。 ai-coding-tool-ecosystem-and-agent-collaboration-7

开发者自身的不变与变

长期使用 AI 编程工具,对开发者的影响。

  • 能力放大器: AI 编程是程序员个人能力的放大器,而非替代者,尤其对经验丰富的开发者更为有利。
  • 技能重心转移: 程序员的价值不再体现在编写代码的速度和数量上,而是体现在对问题的深度理解、系统设计的合理性,以及对 AI 输出结果的判断和优化能力上。
  • 基础技能: 程序员在 AI 时代的最大优势,在于从工具使用者进阶为人机协作系统的架构师。理想的角色演进路径为:代码编写者 → AI 协作者 → 人机系统设计师 → 智能化解决方案架构师。
  • Code Review: 代码审查是程序员不可替代的核心技能之一,无论代码是否由 AI 生成,提交者都必须对其负责。

程序员的核心竞争力正在如何演变?

  • 系统化思维与持续学习: 程序员的核心竞争力已从代码编写能力转向系统化思维持续学习能力。程序员群体普遍具备的持续学习特质,使其能够在高频的技术迭代中快速适应。
  • 人机协作: AI 的引入标志着程序员可以专注于更高层次的角色,如项目经理、系统设计师和软件架构师。核心竞争力不再仅仅是工具熟练度,更在于掌握结构化的 AI 协作方法论(如 PRP、6A、BMAD、ccpm 等),这些方法论能显著提升项目质量与交付结果可靠性。

AI 时代关键字

其他三位老师分别给出了:浪潮、协同、变化

我的答案是不确定性

微观上看,在个人日常生活中,不确定性主要表现为:

  • 输出的准确性/可靠性:AI 系统可能”看起来很自信”但其实错误(比如生成虚假信息、偏差、hallucination),用户很难一眼判断真伪。
  • 行为不一致性:同一个输入可能因为微小变化或内部状态不同,AI 给出不同答案或效果;更新之后模型行为可能改变。
  • 用户体验的不确定性:用户不确定在什么时候 AI 会表现好/坏,比如一款产品中的 AI 功能有时响应迅速准确,有时迟钝或错误。
  • 信任与透明度问题:用户不一定知道 AI 是怎么”思考”的、依据什么样的数据或偏好做出决策。缺少透明度可能让人质疑其行为合理性。
  • AI 产品交互的不确定性

宏观层面,AI 时代带来的社会/结构性变迁使很多传统认知变得模糊或不再适用:

  • Software 3.0(Andrej Karpathy):传统软件的技术栈也许会消失。
  • 政策法规的不确定:AI 技术发展很快,法律、监管往往滞后,难以提前覆盖边界与风险。
  • 经济结构变动:哪些职业被替代、哪些新的岗位被创造、人与机器的协作模式如何重塑,这些都高度不确定。
  • 技术”黑箱”和能力边界不明确:AI 模型极强的能力背后,也有其盲区(例如对新环境的泛化,输入分布转变等),这些会引发社会层面的安全与信任问题。

本文部分观点其实在之前这三篇文章里做过系统阐述,感兴趣的可以去阅读:

从 Cursor 到 Claude Code,我发现了 AI 编程的真正价值

同样用 Claude Code,为什么别人效率是你的 10 倍?答案在这儿!

别再只会用 AI 干活了:真正拉开差距的,是 “系统设计思维”