CASE STUDY 01CODING AGENT · DEVELOPER EXPERIENCE
Coding Agent · IDE AI 研发助手
把不可靠的模型输出，变成开发者敢用的研发工具。
核心结果 / KEY IMPACT
约 40% → 约 80%端到端编译通过率，基于 200 例离线评测集；基线为通用大模型直接调用。WORKFLOW / 工作流程
- 01理解任务与代码上下文
- 02检索与生成修改建议
- 03编译验证与差异审查
- 04人工确认与反馈迭代
本页目录
问题背景
面向公司内部开发人员的 IDE 插件，帮助开发者理解陌生代码、编写重复代码、定位编译报错与修复 Bug。MVP 直接调用通用大模型，端到端编译通过率仅约 40%，生成结果常因缺少企业代码、内部接口和开发规范而无法编译或不符合规范。
评测归因显示，企业上下文缺失是主要失败原因。产品优化聚焦模型之外的 harness 层：组织上下文、编排工具、验证产物，并把最终控制权留给开发者。
我的角色
负责 Coding Agent 的场景定义、产品形态与验收标准，以及评测、协同落地和迭代。算法与模型实现、Runtime 执行环境隔离和会话状态管理由算法团队负责。
- 01
围绕代码生成、代码解释、编译报错分析、Bug 修复四类高频任务，定义触发入口、上下文、输出与人工介入节点。
- 02
与算法团队共同定义上下文策略，采用索引式检索（RAG）接入企业代码仓、接口文档与开发规范；在提示词中约束只使用检索到的真实接口。
- 03
设计企业语料检索 Tool 的入参 Schema 与返回结构，通过 Function Calling 接入；编译验证复用 Bash 执行能力，以通过或报错作为客观反馈。
- 04
采用 diff 分块呈现改动，由开发者逐块确认；牵头将评测集从 50 例扩展至 200 例，定义编译通过、修复成功、采纳与幻觉等维度。
- 05
按检索、提示词、工作流、模型四层归因 Bad Case，协同算法、研发和内部使用团队推进 MVP、灰度与正式版本迭代。
关键决策
这里保留问题、判断与取舍，呈现产品推进中的真实决策过程。
用企业上下文检索解决主要失败原因
- 01 /当时的问题
- 直接调用通用模型时，企业代码与接口上下文缺失，导致生成内容无法编译或不符合规范。
- 02 /我怎么判断
- 采用 RAG 检索企业语料，并约束模型仅使用检索上下文中存在的接口；通过四层归因确定以检索层为主攻方向。
- 03 /取舍了什么
- 采用索引式检索而非让模型自主遍历仓库；优先定向优化上下文，避免盲目更换或微调模型。
让编译反馈和分块确认进入交付链路
- 01 /当时的问题
- 生成的代码需要客观验证；整文件重写还可能误伤原有内容或遗漏代码。
- 02 /我怎么判断
- 复用 Bash 执行编译，以编译结果驱动后续流程；将改动以 diff 分块展示，由开发者确认。
- 03 /取舍了什么
- 保留验证与人工确认步骤，以增加的交互成本换取可检查的改动和明确的最终控制权。
让评测归因指导每一轮优化
- 01 /当时的问题
- 只看最终结果，难以区分失败来自检索、提示词、工作流还是模型。
- 02 /我怎么判断
- 建设 200 例离线评测集，按四层定位 Bad Case；以约两周为一轮，累计完成 4–5 轮定向优化。
- 03 /取舍了什么
- 把迭代资源投入已定位的问题，而不是仅凭生成效果主观判断或持续尝试新模型。
结果
端到端编译通过率，基于 200 例离线评测集；基线为通用大模型直接调用。
离职时的建议采纳率；核心能力进入正式研发工具版本后持续迭代 5 个小版本。
开发者定位单个编译错误或 Bug 的耗时；全部 AI 改动仍以 diff 交由开发者逐块确认。
由小范围试点扩展至全部门，覆盖代码生成、代码解释、智能问答、报错分析与 Bug 修复五类场景。
复盘
企业 Coding Agent 的可用性，取决于模型之外的产品设计：上下文能否补齐、工具能否连接真实环境、反馈能否验证结果，以及开发者能否掌握最终决定权。评测归因让这些改进有据可循。
脱敏说明：基于个人项目经历整理，仅呈现项目职责、产品方法与成果口径。