先说几个核心判断。

豆包 MarsCode 编程助手的落地，不是那种追求炫技的产品体验，而是一整套围绕“让开发者真正写得更快、改得更顺”的系统工程。这篇文章主要聊聊它在实践中的技术路线、迭代逻辑和未来方向。

01 豆包 MarsCode 编程助手起源

IDE 智能化探索

早年 IDE 所谓的“智能”，更多是靠静态代码分析来实现。那时候的补全基于语法树骨架，有预测性，但说不上聪明。后来 Machine Learning 和 Deep Learning 进场，IDE 开始能给出智能推荐和优化建议。

真正让一切质变的，是近年大模型给力了一把。AI 助手做内嵌式代码生成、智能化调试，都大幅压缩了从敲键盘到跑通代码的流程。

核心价值是什么？过去程序员要把很多精力耗在重复劳动、查文档、调框架上。现在 AI 编程助手把编码速度拉上去，把学习门槛降下来。普通开发者也可以借助工具去做跨语言、跨框架的工作，真正做到把更多精力集中在业务逻辑上。

开发者对 AI Coding 的诉求

根据 Stack Overflow 的调研数据，开发者对 AI 编程助手的核心需求，其实是很务实的——不是要什么“碘伏式创新”，而是覆盖全流程开发周期：写代码、查 bug、写注释、做文档。

具体拆解下来，开发者最关心的功能集中在三条线：

• 代码生成：自动补全、模板填充，这是最直接的生产力提升点。
• 代码理解与解读：希望 AI 即时解释代码含义，帮助快速定位和理解逻辑，尤其是接手老旧项目时。
• 自动修复：像 Auto Debug、Link Fix 这类能力，能主动识别并帮开发者扫清 bug，减少人工调试的时间消耗。

豆包 MarsCode 进化

时间线拉回到 2022 年，豆包 MarsCode 从代码补全这条赛道切进去。当时团队意识到，离线评测提供不了真实的用户反馈，所以从一开始就在搭建完整的工程链路和在线评估平台，做策略与模型校验闭环。

最初的产品形态只做代码补全，但很快发现单一工具无法覆盖真实开发过程中的各种场景。于是引入了对话式编程助手，补全不了的就用对话来兜底。到了近期，团队把重点放在更高阶的自动化上——推出代码补全 Pro，力求预判用户意图，及时推送更精准的代码建议。

豆包 MarsCode 的产品演进逻辑始终围绕一个核心命题：如何让代码编写和修改的过程，做到真正“无缝衔接”。

02 豆包 MarsCode 的现状与发展

1. 代码补全

代码补全是 AI 辅助编程最基础的组件。它的底层逻辑不难理解：让模型理解你当前写的代码、理解工程的上下文环境，从而精准猜出你下一步想做什么。传统做法是下拉菜单给你挑，微软后来引入了“幽灵文本”（Ghost Text），直接在编辑器里展示推荐，只需要按一个 Tab 键就能确认。这个设计更符合“人在流中”的体验——即时响应、即时代码补上。

代码补全的核心挑战，在于高性能模型要在极短的推理时间里，抓取到细微的编码语境，准确匹配开发者意图。理解上下文、预测续写字符、适配个人风格，每一项都绕不开“精准性”这个瓶颈。

工程

Prompt 工程的核心目标，说白了就是“怎么准确定位开发者的意图”，然后给出他真正需要的东西。

整体工作流程是这样：IDE 捕获代码的属性（比如语言类型、文件信息等），组装成一个完整的 prompt，带着上下文一起提交给模型做补全。模型推理后把结果返回，然后需要做“后处理”环节：过滤掉重复和不正确的内容，以及敏感词，最后才呈现出补全建议。

上下文对推理性能的影响尤为关键。团队探索了一套基于编码行为的优化策略：当用户写代码、调用函数时，常常要打开相关文件看定义和注释——打开的文件与当前代码的相关性其实很高。因此就把打开文件的上下文收集到 prompt 里面。同时编辑器中的历史内容也会作为上下文传递给模型。但 prompt 长度有限制，所以还需要对上下文进行排序、裁剪、过滤和完善，才能进入模型推理阶段。

科学的评测体系

除了工程技术，还需要一套科学的评测体系来支撑迭代。早期团队用“采纳率”（采纳次数/推荐次数）做评估指标。不过单一指标容易产生误导——比如有时候减少推荐次数反而提升了采纳率，但这并不代表实际效果变好了，也不方便做归因分析。

后来团队引入了更综合的指标 CPO（Characters Per Opportunity），它的核心思路是衡量“每次触发补全机会，用户平均能获得多少个字符”。公式拆解下来包含：尝试率 × 反馈率 × 采纳率 × 每次采纳平均 token 数 × token 平均字符长度。

• 尝试率：用户每敲一下键盘，就是 AI 补全的机会。如果因为延迟、触发策略不合理等原因没有尝试，尝试率就会下降。比如用户敲了 10 次按键，只有 6 次触发了请求，尝试率就是 6/10。
• 反馈率：即使触发了补全请求，如果延迟太高导致用户继续操作，或者模型因置信度不够、触发了过滤器而没有反馈，以上情况都会影响反馈率。比如 6 次补全请求只有 3 次被展示，反馈率就是 3/6。
• 低值预警：尝试率和反馈率一旦偏低，用户的体验就会明显下降，这时候就需要审视链路的延迟策略和触发规则是否合理。
• 采纳率则直观反映推荐质量。
• 每次采纳平均 token 数：较长的代码推荐与较短代码推荐，价值差异很大。Token 数越大，单次推荐的实际“信息量”就越大。
• Token 平均字符数：不同分词器会有差异。如果模型每个 token 能生成更多字符，它实际上就能写出更多代码。

有了 CPO 指标，还需要一个 A/B 测试系统来快速验证模型和 prompt 策略的变化。所以团队的做法是：先做离线评测，验证模型和 prompt 的基础效果；然后上线 A/B 系统，用线上的核心指标来检验真实用户表现。

2. 代码补全 Pro

代码补全在“写全新代码”时表现不错，但研发过程中还有大量场景是在“修改已有代码”。因此团队在模型训练语料中加入了带有时间序列的操作数据，帮助模型理解代码编辑的逻辑顺序。

代码补全 Pro 要解决的问题很明确：准确识别用户意图，预测下一次光标位置、下一步操作是新增、编辑还是替换，以及具体需要修改的内容。

概述

举个典型的场景：打印日志时，开发者已经实现了一个 log 函数，并且在 do_something 和 do_something_else 两个函数中调用了它。

现在为 log 函数增加了 sourceMethod 和 level 两个参数，用于记录日志触发时的方法和日志级别。需要同时修改 do_something 和 do_something_else 两个函数。智能解决方案是由 AI 识别这个需求，自动帮开发者完成所有参数的添加和函数调用的修改。

数据构建

Git 仓库中沉淀了大量用户的编辑行为数据，也包含了大量噪音。团队需要建立一系列启发式规则，从中提取出有关联的编辑信息。用 CT 和 SFT 两种格式帮助模型精准理解数据，优化推理和训练效果。

03 未来展望

编程助手业界趋势观察

编程助手这个领域迭代速度相当快。模型方面，指令遵循和语义理解能力越来越强，一些模型已经具备代码编辑能力，并且支持更长的上下文（甚至达到百 K 甚至 M 级别）。一个直观的变化是：过去你让它把中文转成 Unicode 编码，模型可能只给一段长长的代码解释；现在可以直接给你 Unicode 编码。

产品方面，IDE 原有的交互开始和 AI 深度集成。比如在编辑器中支持直接输入自然语言生成代码。同时模型具备更强的代码编辑能力，可以支持更长、更多代码片段的修改和应用。

未来 AI 编程助手的走向，本质上是让软件开发更顺畅、更高效。模型持续迭代，技术壁垒持续降低，普通程序员也能借助工具释放更强的创造力。

产品形态展望

NL2Code 能力与编辑器深度集成

当前编程助手已经具备了 Inline Chat 能力：用户通过快捷键唤起输入框，输入自然语言，模型生成对应代码。

JetBrains 已经支持在编辑器中用自然语言直接生成代码，VSCode 的 Inline Chat 也支持 NL2Code 的能力。

Sketch then Generate

Sketch then Generate 想体现的，是一种迭代式的代码生成与修改方式。特别适用于需求动态调整的场景。通过增量式交互，用户可以获取即时反馈，并且直接在已有代码基础上做调整。

大模型生成速度慢、稳定性不足是常态。Sketch then Generate 的思路是：根据用户注释或 prompt 引导模型生成中间态的伪代码。模型增量式生成，用户可以实时调整，不需要等完整结果。伪代码会作为上下文反馈，模型据此迭代修改。用户只需发送，伪代码与输入直达模型，即时更新结果。

04 总结

这次分享重点介绍了豆包 MarsCode 编程助手的起源与发展，它背后包含一整套评测体系 CPO，以及代码补全 Pro 如何高效辅助用户编码、预测并推荐下一步动作。

趋势上看，未来会进一步强化模型的追踪能力、编辑能力，以及产品的自动化程度；AI 会更深层地嵌入到 IDE 和各种编辑器中，实现类似 Sketch then Generate 的增量式互动。

05 问答环节

Q：豆包 MarsCode 的定位与未来发展方向是怎样的？

A：豆包 MarsCode 是基于豆包大模型打造的智能开发工具，提供编程助手和云端 IDE 两种形态，覆盖代码补全、错误修复、AI 刷题等多种能力。面向的用户群从新手到资深开发者，协助提升开发效率。

编程助手目前兼容 VSCode 和 JetBrains，提供即时编程支持；云端 IDE 更侧重场景定制来提升效率。长期规划是 AI 深度集成，提高代码自动编辑能力，使用户体验做到全方位、低门槛。

面向未来，豆包 MarsCode 会同时走两条线：一条是场景定制，一条是专业 IDE 建设。短期内在场景优化上发力，长期则瞄准 AI 驱动的高度自动化解决方案，逐步增强产品力。