AICoding实战：从Prd到代码生成

提示

本文从以下几个模块实现最终的Coding能力：

• 构建AICoding标准workflow，实现端到端生码
• 扩充模型上下文，增强对仓库知识的理解能力
• 沉淀流程数据，评测能力效果，优化AI生码质量

1. 框架

[图示已省略]

2. 扩充业务知识，增强模型能力

a. 业务知识体系化

面对庞杂的业务代码内容以及复杂的业务背景知识，需要从安全业务wiki、安全代码wiki、通识wiki、需求wiki多维度结构化补充背景知识，支撑跨仓库、跨业务链路、跨技术栈等复杂场景的生码能力。

• **安全业务wiki：**涵盖各业务领域知识、风控通识和稳定性知识，确保生成的代码符合安全研发规范（如三板斧、熔断），且充分理解了安全业务语义。
• **安全仓库wiki：**包括仓库级wiki、文件级wiki和调用链路wiki，提供全面的安全侧代码库知识，协助需求拆解和生码过程，快速定位需要修改/依赖的仓库代码内容。
• **通识wiki：**基于研发中间件知识和全站研发通用知识，确保需求拆解和生码符合蚂蚁研发规范。
• **需求wiki：**基于prd、系分和关联代码内容，构造需求和领域模型的关联背景知识，从实际需求扩充领域模型实际业务语义内容。

b. 上下文知识扩充，增强业务理解能力

ⅰ. RAG检索业务知识

对于大模型不理解特有业务场景的问题，使用业界通用方案，RAG在线检索相关的业务语义文档做代码生成的增强上下文。但是使用RAG知识库召回数据过程，会存在以下问题：

【召回准确率低】

提示

当前RAG知识检索能力，普遍存在的召回率低问题，采用以下方式去优化：

• **提取业务实体：**增加需求实体提取阶段，避免整个需求文档直接搜索召回，提升准确率。
• **增加搜索标签：**针对二方包跨仓库调用场景，在需求描述时，指定需要的bundle，提升知识库召回率。
• **分应用召回：**核心h1h2应用使用geamker（支持业务三元组知识图谱和向量数据库），确保召回准确率；其他应用使用grt（仅有向量数据库搜索能力），保证可用性。

【支持库存储&检索耗时成本高】

提示

为了增强用户体验，同时考虑到大规模数据存储的成本，从以下几个角度进行多维优化：

• **优化查询流程：**在知识库召回wiki过程中，剔除最后模型总结步骤，在只做文本搜索召回和倒排流程，节省98%耗时（3min->3s）。
• **精炼知识内容：**只保留代码总结中涉及业务语义的部分，降低知识库的初始化解析和存储成本。

ⅱ. 知识图谱能力扩充

在实践过程中，发现现有知识库都是以markdown格式做初始召回文本，但这也会存在一个通用问题：在语义检索时只会命中md文档的某一个chunck块，导致召回结果完整性缺失。

针对此问题，使用知识图谱能力，基于“文件路径+仓库”节点索引标签，定向检索知识库召回文档，扩充wiki内容。

同时，考虑到知识图谱的存储召回耗时成本，简化图谱结构，仅保留必要的文档、仓库、bundle、需求、rpc、drm节点，剔除扩散比大的方法、属性等节点。最终在不降低语义质量前提下，将知识图谱规模从10亿+节点，简化到100万+节点。

c. 模型能力强化

除了RAG+知识图谱方式扩充背景知识外，模型自身的需求拆解和业务理解能力也需要不断增强。

• **持续预训练：**基于Qwen-base model，在离线使用语料库，通过持续预训练方式，让需求拆解基模提前学习业务知识。
• **强化学习：**通过强化学习手段，让需求拆解模型拆解出的子任务有三板斧和鲁棒性考虑，从而实现风险左移。

整体流程如下：

[图示已省略]

• **训练语料：**基于pr的codediffs，先反向生成需求list，再反向合成原始需求。其中会用LLM进行多次扩充。以及原始prd提供反向生成上下文。
• **训练方式：**基于sllmworks框架，使用GRPO方式，设计多个维度奖励（输出格式、拆解任务个数、变更三板斧、鲁棒性、任务依赖准确性）增强模型拆解能力。同时利用agent提取高可用历史AAR经验，总结成关键词词库，及时更新prompt。
• **训练评测：**按照手动评测 + 自动评测，阶段性评测（需求拆解评测）+ 端到端评测（生码评测）相结合的方式对后训练后的需求拆解模型进行评测。
• **应用：**需求拆解后的子任务列表用于最终生码，同时还在探究在其他方向的落地（如：系分生成）。

在当前的强化学习训练过程中，我们主要面临数据质量的挑战，并已制定相应的改进思路与落地计划。

【训练集数据质量】

• **现状与做法：**现阶段采用“PR → 子任务列表 → 需求”的逆向工程链路构造训练样本，能够在数量上保证数据的充足。

同时对数据进行初步清洗：过滤掉代码改动行数在20以下或1000以上的PR，避免过于简单或过于复杂的样本带来的噪音与偏差；

在数据生成链路中引入两轮agent进行校验与补全（第一轮用于子任务完善、第二轮用于需求完善），在一定程度上提升了样本的可用性和一致性。

• **问题与不足：**自动化生成的数据仍可能存在语义偏差、场景不匹配、标签不够细致等问题；数据分布与真实生产场景不完全一致，容易导致训练过程中的偏拟合或泛化能力不足。

改进计划：

• **人工精标与优选：**建立小规模的“黄金集”，由领域专家人工审核与精标，作为训练与评测的对照基准；对自动生成数据进行抽样复核，沉淀高质量样本。
• **分类与分层：**根据实际应用场景对数据进行分类（如修复类、优化类、重构类、文档类等），并按难度分层（简单/中等/复杂），确保训练时的分布与使用时一致。
• **去重与一致性：**对近似或重复样本进行去重；提升一致性与可控性。 [已移除：营销/导流内容]

3. 标准化workflow，端到端生码

3.1 自动生成系分

# 各模块说明## 模块名## **业务实体**| 实体 | 属性及类型<br/>（默认varchar类型） | 索引键 | 字段值说明 || --- | --- | --- | --- |

### **领域功能**
| 领域 | 领域服务 | 领域功能 | 功能描述 | 规则约束 || --- | --- | --- | --- | --- |

### **应用服务**
| 服务域 | 服务接口 | 服务方法 | 方法流程描述 | 校验约束 || --- | --- | --- | --- | --- |

# 业务流程与状态机说明### 状态机说明#### 实体名| 实体 | 当前状态 | 事件/操作 | 下一状态 | 校验约束 || --- | --- | --- | --- | --- |

### 业务流程说明

# 与其他bundle或系统的交互
| 交互方 | 交互方式 | 触发时机 | 主要接口/消息 | pom信息 | 业务目的/说明 | 出入参说明 || --- | --- | --- | --- | --- | --- | --- |
# 高可用相关能力
| 能力 | 是否需要 | 待补充内容 || --- | --- | --- |

3.2 需求拆解子任务

【方案】

• **目标：**将需求模块内容拆解为主要执行任务流程清单，包含详细描述和实现方案，并根据任务之间的依赖关系进行排序。
• 拆分标准：
• 确保子任务单一职责明确。
• 根据业务影响评估优先级。
• 维持与提供的业务背景知识、领域模型等的语义一致性。

[图示已省略]

3.3 仓储生码规范生成

【方案】

利用模型和codefuse具有的仓库索引能力，增加通用指令，以现有仓储具体场景为例，初始化生码规范（.project_rule），实现不同仓库的架构兼容规范。并在后续生码过程中将该规范内容作为生码上下文约束内容。例如以下是针对实际生产itask仓库自动生成的项目规范：

[图示已省略]

3.4 分层生码

Q：为什么不按照纵向分模块拆分生码，而是横向分层生码

A：

1. 在系分和需求拆解阶段，已经按照模块拆分，且根据模块间依赖问题，排序生码子任务。

2. 考虑到流程规范性，约束按照mvc分层生码，不仅能避免模块生码过程，模型偶尔丢失controller层代码问题，也能避免不同接口依赖同一个表或者接口、方法，导致merge冲突问题。

【方案】

• 固化生码指令，设计mvc三层各自的生码workflow。
• 优化生码指令，增加统一的命名规范、鲁棒性处理、可读性等质量要求。

3.5 自动review需求效果

【方案】

通过自定义prompt，固化需求实现效果总结指令，从变更代码结构、功能覆盖范围、稳定性需求、代码实现方案等多维度总结，降低cr难度。

[图示已省略]

4. 评测与数据更新，持续增强能力

a. 动态更新知识库，确保数据准确性

[图示已省略]

b. 能力评测

【评测重点】

• RAG+知识图谱：评测知识召回能力
• **召回率：**实际命中文件数/目标召回文件数据，目前运行时核心链路能完全召回。
• **准确率：**实际命中文件数/实际召回文件总数。
• 模型训练：评测需求拆解偏好
• 总计1分，按照奖分方案，不扣分。
• **输出格式：**严格按照json格式、根据需求复杂度合理规划任务列表个数。
• **业务逻辑：**拆解任务列表需要满足三板斧、鲁棒性、任务依赖顺序合理等要求。

[图示已省略]

需求拆解能力：评测agent+上下文作用

• 拆解prompt优化效果：简单prompt vs 复杂prompt
• 拆解上下文作用：优化背景知识召回能力

[图示已省略]

端到端AICoding能力评测

评测数据覆盖标签范围

• **业务类别：**业务风控相关需求、反洗钱相关需求、高可用相关需求、处罚相关需求、终端相关需求、流量风控相关需求、内容风控相关需求、其他外包小二需求。业务相关核心场景占比63%，高可用占比14%。
• 需求场景：管理时需求(MVC类型服务架构，涉及接口、Controller等)占比34%；运行时需求（纯业务逻辑实现，不涉及Cotroller接口实现）占比66%。
• **需求类别：**新增、修改、新增+修改（占比77%）。
• **需求复杂度：**从拆出的需求任务个数和可能实现代码行数评估。简单10%、中等50%、困难40%。

评测重点

• **完整性：**需求是否覆盖prd文档中领域模型、业务流程和状态机相关内容，其他内容做参考。
• **一致性：**需求内容是否与PRD描述的领域模型、业务流程和状态机相关内容，其他内容做参考，领域模型属性描述不完全不影响需求列表的准确性。
• **依赖合理性：**需求间的依赖关系是否符合技术实现顺序。
• **覆盖范围：**拆分的需求列表是否包含prd以外的内容。如果包含，对于合理的额外内容，比如线程锁、单元测试等属于正常范围的合理扩展。其他额外内容，如增加prd不涉及的接口，此类占比超过整个需求列表的20%，则视为拆解不准确。
• **鲁棒性：**需求拆解过程是否考虑到包括数据、业务逻辑、安全、资源、外部依赖等各维度鲁棒性。
• **高可用能力：**可监控、可灰度、可应急

5. 通过AIcoding编码实际使用情况

内嵌表格