AI 赋能编程，Coding新范式

技术分享 9个月前 (06-13) 0 999+

关注

我们是袋鼠云数栈 UED 团队，致力于打造优秀的一站式数据中台产品。我们始终保持工匠精神，探索前端道路，为社区积累并传播经验价值。

本文作者：佳岚

前言

AI 的大趋势： 24、25 年是 AI 应用大爆发的两年，随着 LLMs 越来越智能化，越来越多的应用实践被挖掘。

我们可以留意到我们使用的主流软件都或多或少集成了AI应用，如 Microsoft Edge 内置了 copilot，钉钉最近更新了AI助理，语雀、Notion 支持了 AI 帮写等等。

AI应用不光是在软件行业有着广泛应用，在游戏行业有着很大革新，例如：

从18年不断发展至今的 DLSS 或 FSR 技术，使画面以低分辨率渲染，再通过 AI 超采样至高分辨率画质，实现提高帧率性能同时尽可能的保留原有画质。

英伟达最近发布的 Nvidia ACE 技术，通过将游戏中的 NPC 集成小模型，使 NPC 或者 AI 队友能感知世界并拥有自主意识。

同样的，在编程领域，AI 技术也为我们程序员的开发带来了很大的变革

作为程序员，我们在开发中往往会遇到以下问题：

重复性工作，对于一些已有需求的变体，如新增一个带有搜索筛选的表格页面，展示一个详情页的 Drawer ，都是基于已有的步骤重复代码操作，长久以此，开发工作会越来越枯燥。
复杂功能设计，要完成复杂的功能设计，往往需要我们做长时间的技术调研
在不熟悉的领域不自信，需要花费大量时间翻阅文档
and so on...

一、 AI 编程工具

选对的工具能让你事半功倍！

功能篇

AI 编程工具的功能大致可以分为以下三个主要功能模块

智能补全

智能补全是 AI 编程开发中最先被发掘出也是最基础的功能。即在当前光标位置后通过行内补全的形式（灰色的代码块）提供后续可能的代码。

智能补全在实际开发中能极高的提高效率，它能够根据上下文信息来获取补全内容，不局限于以下上下文信息：

当前文件或打开的 tab 编辑器中的代码上下文
最近修改的代码记录
剪切板中的代码内容

在进行重复代码编写或者具有上下文关联的代码编写时，具有 context-aware 能力的智能补全往往能带来不错的效率收益，并且不少工具会记忆最近的代码变更内容，让开发者感觉到越用越智能。

以我们的开源项目 dt-sql-parser 为例，每新增一种功能或者 bug 修复都要支持多种 SQL 语言，在补充单测时显得尤为枯燥与乏力，相似的工作做了N遍。基于智能补全的上下文感知，只需在一种语言中编写一次代码，在其他语言中就能直接一路 Tab 到位完成不同语言的单测编写。

智能补全形态的进化

早期的智能补全只能补齐光标后面的内容（利用 inlineCompletion 实现的），而不能修改或者删除已有代码。为了打破这个限制，更多形态的智能补全被挖掘出来。

智能删除，当出现冗余代码时，提示用户删除, 常常在变量名写错、改名或者出现重复代码块时出现提示

已有内容修改，通过小浮窗的形式展示更改后代码

Next Tab 预测，自动预测下一个需要修改的位置，通过 Tab 快速定位

基于补、改、删、跳的交互的有机结合，智能补全已成为实际业务开发中最不可或缺的一部分。

行内编辑

直接在代码块中快速唤起一个弹窗以针对当前选中的代码进行修改, 提供轻量级的上下文，并且是没有对话记忆的，往往做一些非常明确的工作，如针对某个函数进行优化或者国际化翻译。

Chat 模式

Chat 模式也是最开始被发掘的功能之一，相比网页端的大模型对话，Chat 模式可以快捷的提供上下文。

起初最传统的 Chat 模式的上下文需要手动引用，否则被传递的上下文非常有限，一般对话中只会将项目目录结构与当前打开的文件名作为上下文传递给大模型，常见支持的上下文引用如下：

@file - 指定具体文件
@code - 指定具体代码块
@folders - 指定具体文件夹

在使用传统的 Chat 模式下，你会感觉到你需要过渡的引导大模型，大模型的最终输出效果与使用者手动提供的上下文有很大关系，且生成的代码也需要开发人员手动应用到对应位置。

在传统 Chat 模式下我们面临两个痛点：

需要手动提供充足的上下文
需要手动应用输出结果

Agent 模式

Agent这个词我们经常听到，它的释义是"代理人"，在编程领域指能够自主的分析、决策并执行的程序或系统。

在编程工具中的 Agent 模式非常强大，它能像人一样独自完成一系列任务而不需要人工的介入。

Agent 模式是如何做到的？

Agent 的实现本质上是建立在大模型的 function_call 或者 tools_call 的能力上的。

主流的大模型基本都支持工具调用，当客户端在调用大模型的 API 接口时，客户端侧定义一系列的内置工具，告诉大模型客户端能做到什么。

例如要我们自己实现 AI 编辑器的 Agent 模式，就需要定义大概以下工具:

read_file -读取某个文件
write_file - 写入某个文件
delete_file - 删除某个文件
create_file - 新建某个文件
list_files - 列出目录信息
run_commond - 运行shell脚本

在定义tools时需要详细的说明 description ，大模型会根据该字段信息并且经过意图识别后来决定调用哪个 tool

大模型识别到了意图并返回结构化消息, 以此与客户端进行交互。

Agent下的自我修正

自我修正能减少需要程序员的介入情况，例如 Agent 自主帮我们修改代码后，ts类型报错了或者产生了幻觉引用了不存在的方法，那么 Agent 在感知到报错信息后会自行去尝试修复，最终解决问题，整个流程中我们只需要做好一开始的提示词输入工作即可。

Codebase Indexing

全局代码库索引是一个非常重要的功能，它能实现语义化检索来帮助大模型获取整个代码库信息。
像 deepseek 上下文窗口大小只有 64k ，换算成代码行数大概时 2000-3000 行，将整个代码库作为上下文传递显然是不合理的，所以需要尽可能过滤出有用的代码信息。

与 RAG (检索增强生成) 技术相似，建立代码库索引大致分为以下步骤:

将代码库中的所有代码使用大模型的向量化功能生成嵌入向量( embedding )

将生成的 embeddings 写入服务器端的向量数据库
在用户进行提问时，大模型进行意图识别是否需要调用代码库检索工具，客户端检索向量数据库找到与用户提问相关联的代码，并将其作为上下文的一部分发送给大模型
代码更新后，立马同步更新代码库索引

使用 codebase 前：

使用 codebase 后：

语义化检索以快速的定位到相关的文件：

:::info
Notice: 像 Cursor、Windsurf 等 IDE 已不需要在 Chat 模式下显式引用 @codebase 了, Chat 模式下也能做到自主的上下文感知。

:::

插件系列：

github copilot

copilot 作为老大哥，已经内置进了 vscode 中，现在每次的 vscode 更新，都是大量针对 copilot 进行的迭代。但不可否认的是，copilot 现在已经落后于 cursor、windsurf。

另外我比较反感的是，copilot 的智能补全太懒惰，经常一次性只给你补全一行，并且速度相对较慢。

优点：

内置，背靠微软，IDE原生支持, 各种交互 UI 设计比较精致。

缺点：

free用户每月仅有 2000 个自动补全，且付费版本的功能并没用什么突出领先功能，像 Agent 功能与跨行补全也最近 4 月才刚发布正式版，没有足够的吸引力。
基于 GPT-4 小模型的智能补全体验上并没有 cursor、windsurf 等自研补全模型出色

Windsurf plugin (原 codeium )

拥有完全免费的智能补全功能, 支持几乎所有的智能补全形式, 补全的速度和质量非常理想

Cline、Roo Code

Cline 是一款开源的支持用户自定义 Agent 工作流的插件, 它实现了大模型与编辑器之间的交互流程，我们只需要提供大模型服务商的API地址，就能实现属于自己的 Agent。

Roo Code 是 Cline 的 fork 增强版本, 我们以 Roo Code 进行介绍。

使用 Roo Code 你可以接入本地部署的大模型以避免安全问题

在 Roo Code 中，你可以自定义各种提示词，例如在问答模式下，允许大模型自主读取上下文，但不允许修改文件，你可以看到所有的系统提示词。
AI 赋能编程，Coding新范式
我们可以直接看到请求时携带的上下文信息，清晰的知道是如何与大模型交互的

基于Roo Code我们可以很轻松的将 deepseek 集成进IDE中, 配合 Windsurf plugin 能够搭建一套自己的AI编程平台。

但是, Roo Code 对上下文大小优化比较有限，缺少对代码库索引的支持，没几次对话可能就超出上下文大小了。

在中大型项目中，建议配置文件读取行数截断，否则会将整个文件的代码都传给大模型。

通义灵码

一般后端配合IDEA插件使用，前端使用比较少，不过多赘述。

IDE系列：

Cursor

Cursor, the world's best IDE.

作为最广为人知的AI IDE, 其综合体验下来像个五边形战士, 其拥有最好的 Agent 交互体验。

这体现在以下几个方面：

工具调用的成功率高，很少出现 edit_file 等工具调用失败的情况
优秀的 UI 交互设计与充足的可配置项
优雅的对话内 diff 查看与变更总结

极致优秀的上下文管理，能够自动压缩大文件代码
原生支持索引外部文档

缺点：

免费用户不友好，智能补全与 Agent 基本要订阅才能有完整体验

Windsurf

Windsurf，Cursor 的最强竞品，基本上紧追着 Cursor 的步伐，功能迭代很频繁，基本上该有的功能都有。

优点：

拥有最好的智能补全（个人使用感受），补全速度极快，并且完全免费！
可以免费无限次使用 Agent 中的自研模型 SWE
功能迭代频繁，创新力很强，未来可期
最近被 Open AI 收购，可靠性保障（不过被 anthropic 断供 Claude 了）
订阅较 Cursor 更便宜

缺点：

会经常出现工具调用错误，如文件修改失败等，比较影响体验
Agent 交互体验上稍差 Cursor ，如会过度的输出工具调用信息，导致整个对话有点杂乱
小bug有点多
可以引用的上下文项目没有Cursor丰富，如 Rencent Changes, 不支持自定义外部文档

Trae

Trae (The Real AI Engineer), 由字节开发的第一个国产 AI IDE ，基于 vscode , 内置 deepseek 和豆包，由于起步时间太晚，25年初才开启 beta 测试，很多功能还不成熟，还不足以当主力开发使用。

优点：

完全免费，针对国内版目前没有任何收费项目（可能暂时）
可完全自定义接入第三方大模型
信创（也许是最大的优点）

缺点：

功能不健全，如智能补全只支持最基本的补全后缀
Agent 高峰期需要排队
对 Agent 的调教还不太成熟，经常工具或服务出错

:::info

如何选择？

:::

笔者在接近一年的实际使用体验下来，AI编辑器的集成度与交互体验是远胜于插件的，且目前三个主流 IDE 都是基于 vscode 的，可以直接无缝切换，强烈推荐直接使用 AI 编辑器作为主力开发工具。

如果你是一个 Agent 重度使用用户，选择 Cursor
如果你是一个免费用户，则选择 Windsurf

此外，除 Cursor 与 Windsurf 外，智能建议 Widget 与行内智能补全共用了Tab快捷键，导致当有提供智能建议时，行内智能补全的前缀必须与当前建议列表所选择项的前缀一致才会展示，如下 vscode 中的表现：

而在Windsurf、Cursor中， Tab仅用于接受行内补全，智能建议需要使用回车接受：

Windsurf、Cursor中的做法更好，智能补全触发会更及时与频繁。

模型选择

如何选择一个正确的模型？

在使用 Agent 时，选择一个正确的模型往往能决定生成结果的好坏。

模型的上下文长度，这决定大模型能记忆多少的对话内容，常见的 Claude3.7, gpt4 等为120K左右的上下文长度，这大约为4000行代码。
模型的思考模式，thinking 模型会先进行任务拆解，再进行任务执行，在复杂任务的解决或者重构时优先选择 thingking 模型会有更好的结果，但相对的可能会花更多的时间完成任务。
模型的个性，如是否容易产生幻觉代码，工具调用适配性（deepseek对工具调用就很不友好），擅长的领域（如Claude对代码领域有专门的训练、 gpt4适合翻译）等。

其实大多数情况下我们只需要按照自己的使用习惯来选择就好，这是我的使用习惯, 仅供参考：

优先级	模型名称	场景
第一优先	claude-3.7（4.0）-sonnet	绝大多数日常任务
第二优先	claude-3.7（4.0）-sonnet-thinking	复杂任务，从零开始设计或完成某个功能
第三优先	gemini-2.5-pro-thinking	当3.7-thingking的结果不理想时考虑使用

当然，你也可以参考 Cursor 的 Guide 中定义的一样，按照任务类型选择合适的模型

Rules

Rules 定义了大模型应该遵守的行为准则或可重复利用的上下文，如以什么语言回答用户，用什么风格的回答回应用户，Rules 会作为上下文在一开始对话时传递给大模型。

Rules 分为User Rules与项目Project Rules，在Project Rules中定义一些跟项目有关的编码规范，如：

小技巧

受限于上下文大小，不要在一个对话中完成过多的任务，将大任务拆成小任务，在多个对话上下文中完成，再通过@Past Chats引用其他对话的结果
智能补全(CursorTab 与 WindsurfTab)可以开启 Fast 模式，更快更主动。

二、将 AI 应用于实际业务开发

在业务开发中，往往需要提供更多的业务相关上下文，如数据表结构、内部业务文档等等信息，而利用MCP我们可以实现这些。

MCP

MCP (Model-Context-Protocal, 模型上下文协议), 主要用于扩展大模型的上下文获取能力。

它为何出现？

Cursor 等客户端提供了 read_file、list_directory 等内置 tools 使大模型能够意图识并调用这些 tools 以访问额外的上下文信息，但大模型所能获取上下文也仅限于 Cursor 提供的这些内置 tools，而 MCP 的出现使用户能自定义工具，让大模型能够做到任何事情，如连接数据库、操作浏览器、登录服务器获取日志等等。

MCP的架构：

MCP Server类型分为：tools、resources、prompts等等，但目前绝大多数应用只支持到了tools，所以这边以tools为示例介绍。

如何创建一个MCP Server ?

只需要三步：

安装对应语言的 sdk, 初始化一个MCP服务器，并指定一个名称
通过server.tool注册工具，包含工具名称，描述与工具调用时的入参格式等信息
通过 Transport 定义与客户端间的通讯方式

一个非常简单的MCP Server：**ZentaoBugSearch **实现示例：

// 创建MCP服务器 const server = new McpServer({   name: "ZentaoBugSearch",   version: "1.0.0" });  // 添加搜索禅道的工具 server.tool(   "search_zentao",   "用于搜索禅道bug",   { p: z.string().describe("搜索关键词，可以是Bug号、标题关键词等") },   async ({ p }) => {     const searchResults = await searchZentaoBugs(p);          // 格式化结果     if (searchResults.length === 0) {       return {         content: [{ type: "text", text: "未找到匹配的Bug结果。" }]       };     }          const strictMatch = !isNaN(Number(p));      const filteredResults = strictMatch ? searchResults.filter((bug: any) => bug.id === Number(p)) : searchResults;          // 生成文本格式的搜索结果     const formattedResults = filteredResults.map((bug: any, index: number) => {       return `Bug #${index + 1}:n` +         `ID: ${bug.id}n` +         `标题: ${bug.标题}n` +         `状态: ${bug.状态}n` +         `类型: ${bug.类型}n` +         `链接: ${bug.禅道地址}n` +         `内容: ${bug.内容}n`;     }).join('n');          return {         content: [             {                 type: "text",                 text: `找到 ${filteredResults.length} 个结果:nn${formattedResults}`,             },         ],     };   } );   const transport = new StdioServerTransport(); await server.connect(transport);

在 Cursor 中添加MCP Servers

一些应用案例

禅道bug修复

编写一个获取禅道bug信息的MCP Server，以让大模型帮我们修复bug。
AI 赋能编程，Coding新范式

外部知识库增强

本地搭建 dify 知识库，通过 MCP 对接 dify 提供的 API，增强大模型业务理解

获取内部值班信息

根据 PRD 生成代码

利用大模型的图像识别，直接根据 PRD 截图内容生成前端代码，完成一整个页面的基本布局与表格等UI内容，由于敏感信息过多，这里就简单描述下。

国际化语义化翻译排查

在进行产品国际化进程时，需要对产品中现有的所有中文进行提取，但基于AST提取出来的中文可能由于字符串拼接等原因，完整的语句会被拆分到多个子片段中，导致翻译困难，而所有需要排查的文案多达3000行，因此需要借助大模型进行不符合语义化的内容排查。

三、AI开发的潜在风险与应对

1. 代码安全与隐私

风险：源码泄漏风险，敏感代码上传云端
应对：开启隐私模式，使用 .cursorignore文件忽略敏感文件避免被索引, 但隐私模式仅针对的是客户端，如Cursor 等能保证你的代码不会在其服务器上保存，而对于大模型本身是否会拿你代码去训练等等仍是一个需要考虑的问题。

2. 质量隐患

问题：AI 生成代码的可维护性
应对：严格 Review 所有 AI 生成代码, AI生成代码添加水印标识，提交MR时备注上提示词。

3. 开发者能力演化

问题：过度依赖 AI 导致基础编码能力退化

AI 工具可以快速生成代码，但如果开发者在学习和工作中只依赖 AI，而不理解底层逻辑，会导致调试能力、架构设计能力和算法思维逐渐减弱。特别是初学者，在还未建立扎实基础前频繁使用自动化工具，容易形成“拿来主义”的惯性思维。

建议：

学习阶段多使用 Chat 代替 Agent，Agent 会让人变懒，先思考后再去问大模型问题。Agent 更偏向“全自动执行”，会剥夺开发者主动思考的过程。而 Chat 形式的互动可以促使开发者提出问题、验证思路，自己编写，从而提升认知能力。建议在编码前先自己构思思路和解决方案，再借助 AI 进行验证和优化。
开发者应具备“质疑 AI”的意识，对生成的代码进行评估和重构，逐渐培养自己的架构设计能力和代码品味。AI生成的代码并不是最好的，很多时候会进行过多的考虑与设计。
去了解 Agent 的基本运作原理，知己知彼才能更好的适应AI Coding。