刷题流程接入 AI先影子运行再逐步放量把静态题解流程换成 LLM 生成流程风险不在于“新功能能否跑通”而在于输出格式、延迟和错误处理是否仍满足原有调用方的约定。迁移应当可观测、可回退并避免把一次请求无意义地执行两遍。1. 先定义新旧流程的边界旧流程和新流程的输出应先收敛到同一份契约例如题目 ID、语言、代码、复杂度说明和错误码。对无法保持一致的字段要显式标注版本不应依赖前端猜测。对于生成式内容不能要求文本逐字一致。更适合比较的是能否解析、代码是否通过基础用例、关键字段是否完整以及延迟与错误率。2. 用影子流量和灰度路由迁移影子运行时旧流程继续响应用户新流程在旁路处理脱敏后的副本结果只用于评估。确认质量和成本后再让一小部分稳定分桶的请求走新流程。发生异常时应返回旧流程或明确的失败结果取决于业务是否允许降级。flowchart LR A[请求] -- B[稳定分桶路由] B -- C[旧流程] B -- D[新流程] C -- E[响应] C -- F[旁路比对] D -- F F -- G[指标与失败样本]不要使用当前时间的随机数做灰度决策。同一用户反复在新旧路径间切换会让缓存、排障和体验都变得不稳定。3. 一个可控的路由示例type Engine interface { Solve(context.Context, string) (string, error) } type Router struct { Legacy Engine AI Engine Percent uint32 // 由配置系统校验为 0 至 100 } func (r Router) Execute(ctx context.Context, userID uint64, req string) (string, error) { useAI : userID%100 uint64(r.Percent) if useAI { aiCtx, cancel : context.WithTimeout(ctx, time.Second) defer cancel() if result, err : r.AI.Solve(aiCtx, req); err nil { return result, nil } } return r.Legacy.Solve(ctx, req) }调用方还应记录路径、配置版本和失败类别日志中不要保存完整题干或用户代码。若旧流程本身无法提供等价结果则不能把“自动回退”当作正确性保证应给用户返回可重试的状态。4. 发布前看什么迁移报告至少包含契约解析失败、基础用例通过情况、端到端延迟分位数、降级次数和成本。每项指标都要附带时间范围、样本来源、模型和 Prompt 版本。达到什么条件才扩大流量应在发布前写清楚。5. 先稳定接口再扩大流量双跑和灰度的目的不是制造一套更复杂的架构而是让新流程有机会在不影响主链路的条件下暴露问题。先保持接口稳定再逐步扩大流量回退才会真正可用。