CASE STUDY 01AI IDE · DEVELOPER EXPERIENCE
AI IDE 研发助手
把不可靠的模型输出，变成开发者敢用的研发工具。
核心结果 / KEY IMPACT
约 40% → 约 80%代码生成评测中，结果直接送编译器、无 error 计通过；RAG 与编译验证闭环上线后，编译通过率从约四成提升至约八成。WORKFLOW / 工作流程
- 01理解任务与代码上下文
- 02检索与生成修改建议
- 03编译验证与差异审查
- 04人工确认与反馈迭代
本页目录
问题背景
项目面向企业内部软件研发流程，服务写代码、读旧代码、查编译报错和修复 Bug 等高频任务。早期产品只是一个直接调用模型的 VS Code demo，生成结果难以进入真实研发环境。
核心障碍不在于模型会不会生成，而在于它不了解企业内部代码库、API 与开发规范；一旦编造接口或违反规范，开发者就需要返工。产品命题因此从“生成更多代码”转为“让开发者敢用、能验证、可控地采用”。
我的角色
作为产品侧唯一的 AI 产品经理，负责从场景定义、上下文策略与验收口径，到 MVP、灰度、版本迭代和推广的完整产品闭环。
- 01
拆解五类高频研发任务，定义入口、输入上下文、预期输出与人工确认边界。
- 02
定义企业代码库、内部 API 文档和开发规范的知识边界、清洗切分规则、权限范围与更新机制。
- 03
设计 Prompt 硬约束、Agent 工具调用顺序、自动修复终止条件与失败降级表达。
- 04
建立分任务评测集、验收线与检索层／提示词层／工作流层／模型层的 Bad Case 归因机制。
- 05
协同算法、研发与内部使用团队，推进从 demo 到部门推广的版本节奏。
关键决策
这里保留问题、判断与取舍，呈现产品推进中的真实决策过程。
从“直连模型”改为“私有上下文 + 客观验证”闭环
- 01 /当时的问题
- 早期模型直接生成的代码经常调用不存在的内部 API，开发者需要额外验证和返工，工具无法进入生产研发流程。
- 02 /我怎么判断
- 先用 RAG 将代码库、API 文档与开发规范引入上下文；再规定只允许使用检索到的接口；最后接入编译器，将报错回灌到自动修复流程，用非模型的客观信号校验结果。
- 03 /取舍了什么
- 没有把希望放在更强模型或一次性微调上。内部知识更新快，微调成本高且容易过期；多一层检索和编译会增加响应时间，但换来更高的可验证性与可用性。
用可执行的验收口径替代主观判断
- 01 /当时的问题
- 产品面向开发者，单靠“看起来像一段好代码”的主观评价既无法稳定验收，也无法指导版本优化。
- 02 /我怎么判断
- 按生成、补全、检索解释、Bug 定位和编译修复拆分评测；建立真实用例评测集，并以编译通过、单测、采纳率、幻觉率等口径联动灰度反馈。
- 03 /取舍了什么
- 不追求单一漂亮的总分。严格采纳率只计算未修改直接接受的建议，指标更难看，但能避免把“生成量”误当成用户价值。
把“最终决定权”保留给开发者
- 01 /当时的问题
- 开发者对 AI 改动天然谨慎；一旦系统自动写入错误代码，信任会迅速归零。
- 02 /我怎么判断
- 所有变更以 diff 逐块展示，由开发者确认后生效；当上下文不足或重试达到上限时，明确提示边界并提供人工排查建议。
- 03 /取舍了什么
- 放弃了看似更自动化的“直接落盘”。确认动作会增加一步操作，却让产品能在高风险研发场景中逐步建立使用信任。
结果
代码生成评测中，结果直接送编译器、无 error 计通过；RAG 与编译验证闭环上线后，编译通过率从约四成提升至约八成。
离职前的严格口径采纳率：仅统计开发者在 diff 面板未修改、直接接受的代码块。
编译报错定位从开发者访谈中的翻文档、反复试错量级，缩短到系统埋点记录的两三分钟量级；两者采集方式不同，因此只表达量级变化。
产品从 demo 发展为覆盖五类研发场景的 1.0，并在离职前推广至整个部门；评测集由首轮约 50 条扩展至 200 条真实用例。
复盘
企业级 AI 的关键不只是让模型“会答”，而是用私有上下文、客观校验和人工确认，把不可靠的生成能力包装成可被信任的工作流。下一阶段会更早把真实使用数据与风险分级纳入版本优先级，而不是只从功能完整度出发。
脱敏说明：基于个人在职经历整理，已省略内部代码、接口、组织细节与未公开技术实现；数据仅保留可公开说明的口径与量级。