一、项目背景

XpShop 研发团队在维护新普MALL这套 S2B2B2C 企业级电商生态时，业务模块多、历史代码量大，核心交易链路经过多年迭代，积累了大量领域规则与边界处理。团队很早就在内部讨论：能不能让大模型直接帮我们写业务代码，把重复性的样板代码、单测、SQL 这些体力活交给模型，让工程师把精力放在真正的业务建模上？

但真正落地前我们心里有数：直接把模型接进来风险很大。业务代码里充斥着订单、库存、会员体系的强一致约束，模型"幻觉"生成一段看似合理的代码，可能悄悄引入资金对账偏差或者并发超卖——这类隐患上线后极难排查。我们也调研过某头部云厂商提供的通用代码助手，它对我们私有的供应链领域模型和内部代码规范几乎一无所知，生成的代码需要大量返工，采纳率很低，最后的改动量往往比自己写还大。所以我们决定基于我们所采用的 AI 网关与私有化部署底座，自己把这条辅助编码链路搭起来，目标是稳妥提效，而不是盲目替代人。安全、合规、可控，是我们给这条链路定的三条底线。

二、落地场景

我们围绕日常研发的三类高频动作做了场景化接入，全部收敛到我们采用的 AI 网关之下统一管理：

第一是代码补全。在 IDE 插件侧，开发者敲函数签名或注释时，本地先做一次上下文裁剪，再把相关文件片段连同当前光标上下文发给模型，补全当前方法体或实体字段。我们刻意限制了单次补全的上下文窗口，避免把整库源码无意义地塞进 prompt。

第二是单测生成。针对 service 层的核心交易方法，一键生成 JUnit/TestNG 用例骨架，覆盖正常分支、空值、边界和异常回滚，开发者在生成的骨架上补断言即可。过去单测一直因为"费时"被拖延，自动骨架把启动成本降到了接近零。

第三是 SQL 与接口生成。我们的订单与仓储履约对接了大量异构后端，经常要写分页查询、状态机更新语句。我们把表结构字典和接口契约作为上下文注入，让模型按规范生成 MyBatis 映射与 OpenAPI 片段，再由人工确认字段映射。

这三类场景统一通过我们采用的 AI 网关接入，网关负责鉴权、路由到合适的代码模型实例，并做计量配额，避免个别同学把整个仓库丢进去刷 token，也方便我们按小组复盘采纳情况。

三、关键技术挑战与解决思路

私有代码上下文检索（RAG）是第一道坎。通用代码助手只能基于公开语料，对我们私有的供应链领域模型一问三不知，补全出来的接口签名经常对不上真实实体。我们搭建了一条轻量 RAG 流水线：把内部公共库、领域实体、接口契约做语法感知切片（按类/方法粒度，而非机械按行），向量化后存进我们采用的向量库；补全请求进来时，先做关键词+向量混合检索召回 Top-K 相关片段，再拼进 prompt 上下文。这样模型拿到的不是整库噪声，而是最相关的几段领域代码。

案例片段（已脱敏）：RAG 召回的切片策略配置——yaml chunk:  strategy: syntax_aware  unit: method           # 按方法粒度切片  overlap_lines: 3  max_tokens: 1200 retrieve:  hybrid: true  keyword_weight: 0.3  vector_weight: 0.7  top_k: 8

规范约束与静态检查是第二道坎。模型即使拿到上下文，仍可能违反内部规范，比如用魔法数字、忽略事务注解、拼接 SQL 字符串。我们把内部代码规范拆成可执行的规则，一部分以 system prompt 形式强注入，另一部分交给静态检查兜底。prompt 解决"让它尽量不犯"，静态检查解决"万一犯了也拦得住"，两层结合后违规率明显下降。

案例片段（已脱敏）：注入内部代码规范的 system prompt 片段——你是 XpShop 后端研发助手，必须遵守： 1. 所有数据库访问必须走 MyBatis 参数绑定，禁止字符串拼接 SQL； 2. 涉及库存/金额变更的方法必须显式声明 @Transactional 并指定超时； 3. 禁止引入未在公司私有仓库登记的开源依赖； 4. 时间戳统一使用 LocalDateTime，禁止 new Date()； 5. 生成的代码必须带可编译的最小 import，不得省略。

人工评审闭环是第三道坎。我们坚持"模型生成、人审人改"。生成的代码进入 PR 后，CI 里挂了静态检查与单测门禁，质检不通过直接打回；同时把"被开发者最终采纳/修改"的结果回流，作为后续路由与提示词优化的信号。我们发现，哪些片段常被删、哪些被保留，本身就是最有价值的反馈数据。

敏感代码不出域是第四道坎。我们对网关侧做了严格的出域管控：源码、密钥、内网地址在发送模型前由本地脱敏代理做正则擦除，且所有补全请求只发往我们私有化部署的底座实例，绝不触达公网模型。脱敏规则随内部资产清单定期更新，确保新增的内部域名、密钥前缀也能被识别。

四、效果数据

落地约一个季度后，我们对 XpShop 新普MALL 三个核心研发小组做了对照统计（示意值）：

整体看，研发在样板代码与单测上的耗时明显缩短，而缺陷率反向下降，说明提效没有以质量为代价，这是我们在引入大模型辅助时最看重的一点：效率的提升不能靠牺牲稳定性来换。

五、可复用经验总结

第一，把大模型定位为"辅助"而非"替代"。业务核心链路上的代码，模型给的是草稿，最终正确性仍由人负责，这一点在评审机制里必须固化，不能因为省事就松开人审。

第二，评审闭环不可省。我们踩过的坑是早期想"全自动合入"，结果一次错误的事务声明险些导致库存扣减异常，此后所有生成代码一律走 PR + 静态门禁 + 人审。

第三，规范要落到可执行。把文字规范拆成 prompt 约束与静态规则两层，比单纯"提醒工程师注意"有效得多，也便于量化合规率。

第四，数据出域管控要前置到客户端。让脱敏发生在源码离开开发者机器之前，比依赖网关事后拦截更稳，也更经得起安全审计。

第五，建立采纳数据的量化看板。我们把每个小组的采纳率、返工率、缺陷回流做成周报，既能向业务方证明价值，也能反过来指导提示词与路由策略的迭代方向，让这套辅助链路持续自我改进。