Claude Code 接入 CrazyRouter 连载 24：AICoding实战：从Prd到代码生成

本文为 CrazyRouter 站内连载稿，已统一清洗为 CrazyRouter 接入口径。

Claude Code / Anthropic 原生客户端：ANTHROPIC_BASE_URL=https://cn.crazyrouter.com，不要追加 /v1

OpenAI 兼容 SDK、HTTP 请求、前后端应用：base_url=https://cn.crazyrouter.com/v1

API Key 使用 CrazyRouter 控制台创建的 sk-... Token

完整配置说明见 https://docs.crazyrouter.com/integrations/claude-code，一键配置脚本见 https://github.com/xujfcn/crazyrouter-claude-code

Claude Code 接入 CrazyRouter 连载 24：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 自动生成系分#

【方案】

给出统一的系分文档，扩充业务流程、状态转换、权限约束规范等必要细节。
使用agent自动生成标准化文档，开发人员只需介入修订，减少人工撰写成本。

Markdown

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

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

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

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

### 业务流程说明

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

3.2 需求拆解子任务#

【方案】

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

|-|-|

3.3 仓储生码规范生成#

【方案】

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

3.4 分层生码#

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

A：

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

考虑到流程规范性，约束按照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编码实际使用情况#

CodeFuse 用户提交代码 AI 占比：43.25%	全部提交代码AI占比:36.01%

下一步#

如果你准备把 Claude Code、国产模型或自己的应用统一接入 CrazyRouter，建议按这个顺序操作：

在 CrazyRouter 控制台创建一个单独的 API Token。
Claude Code 使用根域名：https://cn.crazyrouter.com。
OpenAI 兼容 SDK 或应用接口使用：https://cn.crazyrouter.com/v1。
需要一键配置 Claude Code 时，使用 GitHub 仓库：https://github.com/xujfcn/crazyrouter-claude-code。
遇到 /v1/v1/messages、/v1/v1/models 这类错误时，回到 API Endpoint 说明检查 Base URL 是否多写了路径。

Claude Code 接入 CrazyRouter 连载 24：AICoding实战：从Prd到代码生成