第1873篇：AI原生产品的迭代节奏——快速实验与稳定发布的平衡

我在不同公司见过两种极端。

一种是：产品说我们要快，每周上线，敏捷。结果每周都在改Prompt，模型行为飘忽不定，用户投诉"为什么上次能用现在不能用了"，最后工程师把一半时间花在解释"AI的行为为什么不一样"上。

另一种是：为了稳定，任何AI相关改动都要经过三轮评审，走完整的发版流程。结果一个Prompt优化要两个月才能上线，竞争对手早就迭代了十几个版本。

AI原生产品的迭代节奏，确实和传统软件产品不一样，需要专门设计。今天讲我的思考和实践。

AI产品迭代的特殊性

传统软件的行为是确定的：给同样输入，永远返回同样输出。你改了代码，可以通过单测和集成测试确认行为符合预期，然后发布。

AI产品不是这样。就算你没改任何代码，模型提供商可能悄悄更新了模型版本，你的Prompt可能在新版本下行为发生了变化。更别说你主动修改Prompt——同样的语义修改，在不同query下可能有完全不同的影响。

这带来了三个核心挑战：

要解决这些挑战，你需要一套专门为AI产品设计的发布体系。

核心架构：把AI能力从业务逻辑中解耦

第一步是架构上的解耦。很多团队的问题是把Prompt直接硬编码在业务代码里，每次改Prompt都要走完整的代码发布流程。

正确的做法是把AI能力层独立出来：

// Prompt版本管理系统
@Entity
@Table(name = "prompt_versions")
public class PromptVersion {
    
    @Id
    private String id;           // 格式：capability_name:v1.2.3
    
    private String capabilityName;  // 能力名称，如：requirement_analysis
    private String version;          // 语义化版本
    
    @Column(columnDefinition = "TEXT")
    private String systemPrompt;     // 系统提示词
    
    @Column(columnDefinition = "TEXT")  
    private String userPromptTemplate;  // 用户消息模板（含占位符）
    
    private String modelName;        // 使用的模型
    private String modelVersion;     // 模型版本（固定防止自动升级）
    
    @Column(columnDefinition = "JSON")
    private String parameters;       // temperature、top_p等参数
    
    private PromptStatus status;     // DRAFT/CANARY/STABLE/DEPRECATED
    private Double canaryWeight;     // 金丝雀流量比例（0.0-1.0）
    
    private LocalDateTime createdAt;
    private String createdBy;
    private String changeReason;     // 这次改动的原因
    
    @Column(columnDefinition = "TEXT")
    private String testSuiteId;      // 关联的测试套件ID
}

@Service
public class AICapabilityRouter {
    
    @Autowired
    private PromptVersionRepository versionRepo;
    
    @Autowired
    private ExperimentAssignmentService experimentService;
    
    /**
     * 路由到合适的Prompt版本
     * 支持金丝雀发布和A/B测试
     */
    public PromptVersion route(String capabilityName, String userId) {
        List<PromptVersion> activeVersions = versionRepo
            .findActiveVersions(capabilityName);
        
        if (activeVersions.size() == 1) {
            return activeVersions.get(0);
        }
        
        // 多版本时，根据金丝雀权重分配
        return experimentService.assignVersion(userId, activeVersions);
    }
}

@Service
public class ExperimentAssignmentService {
    
    /**
     * 基于userId的一致性哈希分配版本
     * 确保同一用户在一段时间内体验同一版本
     */
    public PromptVersion assignVersion(String userId, 
                                        List<PromptVersion> versions) {
        // 用一致性哈希确保分配稳定
        int hash = Math.abs(userId.hashCode()) % 100;
        
        double cumulative = 0;
        for (PromptVersion version : versions) {
            cumulative += version.getCanaryWeight() * 100;
            if (hash < cumulative) {
                return version;
            }
        }
        
        // 兜底返回稳定版本
        return versions.stream()
            .filter(v -> v.getStatus() == PromptStatus.STABLE)
            .findFirst()
            .orElseThrow(() -> new IllegalStateException("No stable version found"));
    }
}

这个架构让你可以独立管理Prompt版本，不需要每次都走代码发布流程，也支持金丝雀发布。

自动化评估：让你敢改Prompt

架构解耦解决了发布机制，但还有一个更根本的问题：怎么知道改了之后效果更好？

我的做法是为每个AI能力维护一个评估套件：

@Entity
@Table(name = "evaluation_cases")
public class EvaluationCase {
    
    @Id
    private String id;
    
    private String capabilityName;
    
    @Column(columnDefinition = "TEXT")
    private String inputTemplate;    // 输入模板（含变量）
    
    @Column(columnDefinition = "JSON")
    private String inputVariables;   // 模板变量的具体值
    
    @Column(columnDefinition = "JSON")
    private String evaluationCriteria;  // 评估标准（JSON定义）
    
    private String caseType;        // HAPPY_PATH/EDGE_CASE/REGRESSION
    private Integer priority;       // 优先级（越高越重要）
    private String addedBy;
    private String addedReason;     // 这个case为什么加进来
}

@Service
public class PromptEvaluationService {
    
    /**
     * 对比两个Prompt版本在评估套件上的表现
     */
    public EvaluationComparisonResult compare(String capabilityName,
                                               String baselineVersionId,
                                               String candidateVersionId) {
        List<EvaluationCase> cases = evaluationCaseRepo
            .findByCriticalityOrder(capabilityName);
        
        List<ComparisonItem> results = new ArrayList<>();
        
        for (EvaluationCase evalCase : cases) {
            // 分别用两个版本运行
            AIResponse baselineResponse = runWithVersion(evalCase, baselineVersionId);
            AIResponse candidateResponse = runWithVersion(evalCase, candidateVersionId);
            
            // 用LLM做评判（LLM-as-Judge）
            EvaluationScore baselineScore = judge(evalCase, baselineResponse);
            EvaluationScore candidateScore = judge(evalCase, candidateResponse);
            
            results.add(ComparisonItem.builder()
                .caseId(evalCase.getId())
                .caseType(evalCase.getCaseType())
                .priority(evalCase.getPriority())
                .baselineScore(baselineScore)
                .candidateScore(candidateScore)
                .build());
        }
        
        return buildComparisonReport(results, baselineVersionId, candidateVersionId);
    }
    
    /**
     * LLM-as-Judge：用一个专门的评判Prompt来打分
     */
    private EvaluationScore judge(EvaluationCase evalCase, AIResponse response) {
        EvaluationCriteria criteria = parseCriteria(evalCase.getEvaluationCriteria());
        
        String judgePrompt = """
            你是一位严格的AI输出质量评审员。
            
            评估任务：%s
            
            输入：%s
            
            AI输出：%s
            
            评估标准：
            %s
            
            请对该输出按每个标准打分（1-5分），并给出简短理由。
            
            输出JSON：
            {
              "scores": {
                "标准名": {"score": 4, "reason": "..."}
              },
              "overall": 4.2,
              "critical_failures": ["严重问题列表，如有"]
            }
            """.formatted(
                criteria.getTaskDescription(),
                evalCase.getRenderedInput(),
                response.getContent(),
                criteria.toCriteriaText()
            );
        
        return parseScore(judgeClient.call(judgePrompt));
    }
}

有了评估套件，Prompt改动的流程就变成了：

这个流程让你对每次Prompt改动都有量化依据，而不是靠感觉说"感觉好多了"。

三速迭代：不同改动走不同通道

实践中，不是所有改动都需要走完整的评估流程。我把改动分成三类：

快速通道（小时级）

适合：Prompt的措辞微调、示例更换、不影响核心逻辑的优化。

条件：评估套件通过率>95%，且没有P0级回归。

@Component
public class FastReleaseGate {
    
    public ReleaseDecision evaluate(EvaluationComparisonResult comparison) {
        // 必须满足：无P0级别失败
        boolean hasP0Regression = comparison.getResults().stream()
            .filter(r -> r.getPriority() >= 9)  // P0优先级
            .anyMatch(r -> r.getCandidateScore().getOverall() < 
                         r.getBaselineScore().getOverall() - 0.5);
        
        if (hasP0Regression) {
            return ReleaseDecision.BLOCKED("P0 regression detected");
        }
        
        // 整体通过率>95%
        double passRate = comparison.calculatePassRate(3.5); // 分>3.5算通过
        if (passRate < 0.95) {
            return ReleaseDecision.BLOCKED(
                String.format("Pass rate %.1f%% < 95%%", passRate * 100));
        }
        
        // 整体分数不能下降超过0.1分
        double scoreDelta = comparison.getAverageScoreDelta();
        if (scoreDelta < -0.1) {
            return ReleaseDecision.BLOCKED(
                String.format("Average score dropped %.2f", scoreDelta));
        }
        
        return ReleaseDecision.APPROVED_FAST_TRACK;
    }
}

标准通道（天级）

适合：新增功能、较大的Prompt结构变化、新模型版本切换。

需要：完整评估套件通过 + 人工review + 金丝雀观察24小时。

慎重通道（周级）

适合：涉及核心用户体验的重大改变、安全相关调整、对话策略根本性改变。

需要：评估套件 + 人工评审 + 内部用户测试 + 金丝雀观察1周。

线上监控：发现你评估套件没覆盖到的问题

再好的评估套件也不能覆盖所有真实用户行为。线上监控是最后一道防线：

@Service
public class AIProductionMonitor {
    
    // 关键指标
    private final Counter errorCounter;
    private final Histogram latencyHistogram;
    private final Counter userFeedbackCounter;  // 用户点踩/点赞
    
    @EventListener
    public void onAIResponse(AIResponseEvent event) {
        String versionId = event.getPromptVersionId();
        
        // 记录延迟
        latencyHistogram.record(event.getLatencyMs(), 
            Tags.of("version", versionId, "capability", event.getCapabilityName()));
        
        // 检测输出异常（过短、包含明显错误格式等）
        if (isAnomalousOutput(event.getResponse())) {
            errorCounter.increment(Tags.of("type", "anomalous_output", 
                                           "version", versionId));
            alertService.sendAlert(buildAnomalyAlert(event));
        }
        
        // 记录token用量（成本监控）
        costTracker.record(event.getInputTokens(), event.getOutputTokens(), versionId);
    }
    
    private boolean isAnomalousOutput(AIResponse response) {
        String content = response.getContent();
        
        // 输出过短（可能是模型拒绝回答）
        if (content.length() < 50) return true;
        
        // 包含明显的模型报错特征
        if (content.contains("I cannot") || 
            content.contains("I'm unable to") ||
            content.contains("As an AI language model")) {
            return true;
        }
        
        // 期望JSON但输出不是JSON
        if (response.getExpectedFormat() == ResponseFormat.JSON) {
            try {
                objectMapper.readTree(content);
            } catch (JsonProcessingException e) {
                return true;
            }
        }
        
        return false;
    }
    
    /**
     * 自动回滚：当异常率超过阈值时
     */
    @Scheduled(fixedDelay = 60000) // 每分钟检查
    public void checkForAutoRollback() {
        List<PromptVersion> canaryVersions = versionRepo
            .findByStatus(PromptStatus.CANARY);
        
        for (PromptVersion canary : canaryVersions) {
            double errorRate = calculateRecentErrorRate(canary.getId(), 10); // 最近10分钟
            
            if (errorRate > 0.05) {  // 错误率超过5%
                log.warn("Auto-rollback triggered for version {}: error rate {}",
                    canary.getId(), errorRate);
                rollbackVersion(canary);
                alertService.sendRollbackAlert(canary, errorRate);
            }
        }
    }
}

踩过的坑：快速迭代的代价

说几个真实踩过的坑：

坑一：Prompt改了，忘了更新评估套件

这是最常见的问题。改了Prompt的行为，但评估套件还是按照旧行为评分，导致评估结果虚高。解决方案：任何改变期望输出格式的Prompt改动，必须同时更新评估套件，这是发布的前置条件。

坑二：金丝雀流量太小，看不出问题

5%的金丝雀流量，如果日活是1000人，只有50人用新版本，某些边缘case可能一直触发不到。解决方案：根据流量规模调整金丝雀比例，低流量产品直接跑30-50%。

坑三：LLM-as-Judge本身也会漂移

用来评判的LLM如果本身版本变化了，打分标准也会变，历史评分就没有可比性了。解决方案：评判模型的版本要固定，不能随意升级；同时对评判结果做人工抽样校验。

坑四：快速迭代导致Prompt版本失控

上了100多个版本之后，没人知道哪些版本还活着、各版本之间的区别是什么。解决方案：定期做版本归档，STABLE版本只保留3个，过时的自动标记为DEPRECATED并在90天后清理。

一个适合AI产品的迭代节奏

综合下来，我推荐这样的迭代节奏：

• 每日：小幅Prompt微调走快速通道（如果评估通过）
• 每周：中等改动走标准通道，含金丝雀观察
• 每月：模型升级评估、评估套件更新、大功能迭代
• 每季度：完整的Prompt工程审查，清理冗余版本，更新评估标准

这个节奏不是固定的，要根据产品阶段调整。产品早期探索阶段可以激进一些，用户规模大了之后就要稳健一些。

核心原则只有一个：每次改动都要有数据支撑，不能凭感觉说"这次应该更好"。