AI 产品开发生命周期(CC/CD)

AI 产品开发生命周期（CC/CD 框架）

同样是"上线一个 AI 功能"，为什么传统软件的版本规划、测试、发布节奏全都不灵了？需求文档写清了功能边界，上线后用户却问出意料之外的问题；测试用例全绿，生产环境却时而正常、时而"发疯"。原因在于：AI 产品不能照搬传统软件的开发方式——AI 天然带有非确定性，且必须在"代理权（agency）与控制（control）"之间做权衡。正确的做法是用 CC/CD 循环（持续校准 / 持续开发）代替一次性的规划与发布，让系统一步步"赚取"代理权。

本文按「为什么不一样 → 循环总览 → CD 各阶段可操作清单 → CC 各阶段运营 → 成熟度模型 → 完整走查」展开。每个阶段都给出清单、表格与模板，可以直接抄进你的立项文档和 PRD。

为什么 AI 产品不一样

非确定性：两端都不可控

传统软件是确定的：输入可枚举（点击、提交、调 API），行为可预期，出了问题能追溯到具体代码。AI 产品两端都不可控：

• 用户侧：开放式提示、语音等自然输入，难以验证、容易误解、表达差异大
• 系统侧：模型按模式生成"合理"回答，不守固定规则；同一请求因措辞、上下文、模型不同而结果不同

影响是什么？我们不再是为"可预期的用户流程"设计，而是为"大概率行为"设计，全程持续校准预期与现实。设计评审里那句"这个功能谁会这么用"在 AI 产品里必须换成"这个输入模型会怎么错"。

代理权与控制权的权衡

Agency（代理权）指系统替用户行动、做决策的能力——订机票、执行代码、全程处理工单。它与控制权此消彼长，扩权路上的每一步都绕不开这组权衡：

• 每多给系统一分代理权，就少一分控制。 建议式回复可以覆写；自动发送就必须确保正确
• 常见错误：系统还没证明自己"犯错时可控"，就直接跳到全代理。后果是失去可见性、失去用户信任，而且系统已经做出无法追溯的动作，无从调试
• 原则：代理权要靠表现逐步赚取，而不是一次性授予

关于代理权与人工交接的实操细节，可参考站内 Agent 产品。

AI 产品形态分层

「是不是 AI 产品」在实操上没有意义，真正要紧的是产品以什么形态替用户做事。形态决定了能力假设、失败半径、产品责任和人工接管方式，也决定了评测与灰度该怎么做。按自主程度从低到高分为五层：

三层以下（辅助生成、工作流嵌入）绝大多数场景是确定性的工作流：Anthropic 官方建议先找最简单的方案，只在确有收益时增加复杂度，很多应用优化单次 LLM 调用就够了（Building Effective Agents）。四层以上（多步 Agent、自主执行）才需要考虑 Agent 特有的成本与失败恢复问题，详见 Agent 产品。产品经理在立项时先问一句：这个功能到底需要哪一层？答不上来就按低一层做。

一张表看懂差异

CC/CD 循环总览

借 CI/CD 的名字，它适用于"行为非确定、代理需赚取"的系统。开发（CD，Continuous Development）与校准（CC，Continuous Calibration）构成持续循环：

每轮循环的输入与产出：

循环节奏没有固定天数，由「拿到多少可信行为信号」决定：灰度样本不足就继续观察，指标稳定就升级。这也和站内 项目管理与迭代 的迭代节奏互相补充——CC/CD 回答"每一轮做什么、怎么算好"，项目管理回答"怎么排期、怎么跟"。

适用边界：什么时候不需要 CC/CD

框架不是万能咒语，以下情况不要套 CC/CD，直接走传统流程更便宜：

• 纯规则系统：输入可枚举、行为确定（表单校验、权限控制），传统测试就够
• 单次调用工具：一次请求一次返回、无持续运营（一次性翻译、单次摘要），没有"循环"可跑
• 无真实用户：没有线上行为信号，CC 阶段无米下锅——先用 spike 和原型验证需求（见 需求分析）
• 短命活动：三天后下线的活动页，不值得建评测体系

判断标准两条：有没有非确定性（模型行为不可精确断言）+ 有没有持续迭代闭环（能拿到真实反馈并回灌）。两者缺一，CC/CD 就是过度工程。此外，CC/CD 与 产品设计与原型 的发现流程是先后关系：先用原型验证"用户要不要"，再用 CC/CD 把"怎么持续变好"跑起来。

持续开发（CD）：从 0 到 1

CD 0：问题与可行性定义

动工前先把"这个 AI 功能到底能不能做、值不值得做"用一张表说清楚。逐项检查：

把"模型能不能做到"拆成可验证的 spike 清单——每个 spike 是带时间盒的小实验，回答一个具体的「能不能」：

spike 的产出不是"模型很厉害"的感慨，而是一串可复现的数字：准确率、召回率、延迟、成本、失败率。这些数字直接成为 PRD 能力边界与评测通过线的第一版依据。

CD 1 划定能力范围 + 整理参考数据

能力范围与代理权阶梯

版本不再按功能集划分，而是按代理权层级划分：v1 = 高控制低代理，v2 逐步放开，v3 高代理。把宏大终态拆成可评测、可迭代、可叠加的早期行为：

• 客服自动化：v1 只做工单路由 → v2 建议解决方案 → v3 自动解决（带人工兜底）
• 营销助手：v1 起草文案 → v2 搭建并执行多步 campaign → v3 自动上线、A/B、跨渠道自动优化
• 编程助手（GitHub Copilot / Cursor 实际走的路径）：v1 行内补全 → v2 生成大块代码供人审 → v3 自主改代码并开 PR

每一级代理权都要写明准入信号、护栏、回退机制、退出条件。参考 Claude Code 的权限模型（Manual 模式逐次征求批准、Auto 模式由分类器拦截风险操作、沙箱限定边界，见 Claude Code 安全文档）与 Building Effective Agents 的「先简单后复杂」原则，可整理成一张通用阶梯：

用户只看到当前版本，但底层是逐级爬上来的。每个版本停留多久，取决于拿到多少行为信号——目标是把系统在真实噪声下的表现搞清楚。放行下一级前先回答两个问题：错误是否被约束在可回滚范围内？有没有评测证据证明当前级达标？（代理权与信任的展开见 Agent 产品）。

参考数据集治理

参考数据集（reference dataset）打破冷启动：比如客服路由版需要"用户 query + 应路由部门 + 决策元数据"。可从历史日志取，或按预期行为生成，起步 20~100 条即可。数据集一旦开始积累，就要按工程资产治理，六件事缺一不可：

• 代表性：覆盖真实场景分布，而非只挑好例子；用线上日志统计场景占比，按占比抽样
• 隐私脱敏：入库前去除可识别个人信息（姓名、手机号、工号、地址），脱敏要在写入日志时做，而不是评测时
• 版本管理：每个数据集有版本号与变更记录；标注修正要产生新版本，禁止原地改旧版本
• 标注协议：标注指南先行（"什么是正确"的判定规则 + 正反例），标注人需培训并试标；写明"可接受的答案范围"而非唯一答案
• 分歧仲裁：双人标注、计算一致性（如 Cohen's κ），分歧条目由权威角色（客服主管、领域专家）仲裁
• 边界/对抗样本与漂移监控：持续补充边界与对抗样本；定期对比线上输入分布与数据集分布，分布明显偏移时重采样

种子评测集的最小 schema（可直接抄用）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

id: INT-0001              # 唯一编号
input: 用户原始输入（已脱敏）
context: 业务上下文（渠道、历史会话摘要，可选）
expected: 期望行为（答案要点或禁止行为）
category: 场景分类（退款/物流/投诉/咨询）
difficulty: typical | boundary | adversarial   # 典型 / 边界 / 对抗
labeler: 标注人 ID
labeler_role: 标注人角色（客服主管/PM/标注员）
agreement: 双标注一致性（可选，记录分歧仲裁结果）
updated_at: 2026-08-24    # 最后变更日期（版本化依据）

CD 2 搭建应用

• 不要过度工程化（"过早优化是万恶之源"）——只建当前版本需要的东西
• 埋好日志：记录系统看到什么、返回什么、用户怎么交互，形成实时交互数据集
• 面向终端用户必须做好 guardrails 和合规
• 关键设计：控制交接（control handoff）——出错时人类能无缝接管。比如 v1 工单被错路由，接收的客服要能一键改路由；这个修正会被记录，既改进系统又保住体验。信任和可恢复性从这一步开始

系统搭建

最小可用系统的组件清单（每项都可替换、可降级，不要一开始就追求完美架构）：

「客服工单助手」v2 的端到端示意图（文本版）：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16

[入口层] 鉴权 · 输入校验 · PII 脱敏 · 限流
    │
    ▼
[分类路由层] 意图分类 + 知识库检索（RAG） ──低置信度 / 敏感内容──▶ 直接转人工
    │
    ▼
[生成层] 主模型：路由建议 + 解决方案建议（记录模型 / prompt 版本与置信度）
    │
    ▼
[输出护栏] 内容安全过滤 + 格式校验 ──拦截失败──▶ 降级话术 / 转人工
    │
    ▼
[人工接管层] 客服采纳 / 修改 / 拒绝，修改写回日志 → 评测数据回填
    │
    ▼
[观测层] 全链路日志 · 成本看板 · 预算熔断 · feature flag 灰度开关

日志 schema 建议最少包含这些字段（每行日志都可回放成一次完整交互）：

CD 3 设计评测

Evals 相当于传统软件的测试，但输入输出不固定、正确性非二元，专门回答"非确定性的任务做得好不好"。设计要点：

• 完全应用相关：客服 v1 用路由准确率；v2 做 SOP 检索，评测改为检索质量（建议是否贴合工单）
• 最佳实践：先用参考数据集跑评测，验证评测设计本身、提前调优；追求关键用例的广覆盖，不追求完美

评测体系

评测不是"跑个分"，而是五层结构各司其职：

LLM-as-judge 可以大幅降低人工评测成本，但必须校准：先检查位置偏差、长度偏差、自我偏好三类系统偏差，再用一小批人工标注样本验证 judge 与人工的一致性达到阈值（如 80%）才可批量使用（详见 评估与评测）。Judge 是过滤器和初筛，不是最终裁判。

指标公式要写清分子、分母、样本、观测周期和行为含义，否则"提升 5%"无法解释也无法复现：

评测必须连接业务结果：路由准确率涨 3% 不是目标，目标是"工单平均处理时长从 6 小时降到 4 小时"。如果只有基准分上涨、业务指标不动，那评测体系本身就该被质疑——只涨基准分的指标是幻觉指标。

部署与灰度（过渡）

不是终点，是进入校准阶段的过渡。带日志、人工接管、评测指标上线后，先部署到小范围人群观察。灰度路径按风险递增：

所有灰度开关必须用 feature flag 承载（代码级开关，不用发版控制）；同时挂预算熔断——日成本超阈值自动降级或停用，防止放量时成本失控。放量前定好升级/停止/回滚责任表：

所有阈值都是示例——具体数字必须按自身风险承受度与基线数据调整，不要拿别人的阈值当行业标准。

灰度对比的统计纪律：对照分组要随机，排除时间因素（节假日、大促、活动引流）；观测期至少覆盖一个完整业务周期（如 7 天）；改路由率这类小分母指标样本量不足时先看置信区间再谈升降，不要拿三天数据下结论（统计方法见 评估与评测 的线上评估一节）。

持续校准（CC）：让系统"赚取"代理权

CC 4 运行评测

收集足量实时交互数据后跑评测：数据小（2000~3000 条）就全量跑，否则按代表性抽样。

抽样信号示例：客服 v1 可以用"是否被人工改路由"作为路由准确率的代理指标；复杂系统看对话轮数、赞/踩等。跑评测要固定"评测集版本 + 模型版本 + prompt 版本 + 采样日期"四元组，否则分数之间不可比。

CC 5 分析错误模式

从评测最弱的环节入手做人工审查：每个部门抽 20~50 条低分工单，看用户说了什么、系统做了什么、结果如何。归纳重复错误模式并文档化，据此划定下一版范围：

错误分类学与抽样策略

错误模式要有统一的分类学，否则复盘会变成各说各话。建议按"错误发生的位置"分类：

抽样策略：分层抽样优于随机抽样——按场景分类、置信度区间、时段分层，保证每个弱势群体都有样本；低置信度段全量抽，高置信度段随机抽。

根因分解、修复优先级与效果归因

拿到错误样本后按「数据 / 检索 / prompt / 模型 / 工具 / UI」六个方向做根因分解，每个方向对应不同的修复手段与回归方式：

修复优先级 = 影响面（出错频率 × 单次代价）× 修复成本倒数。不要按"哪个好修"排序，按"哪个最痛"排序。

效果归因的纪律：一次只改一个变量；改前改后在同一评测集版本上对照；线上指标要区分混杂因素（节假日、活动、流量变化）；改完必须回到 CC 4 重跑，不靠"感觉变好了"。

「错误模式 → 证据 → 修复 → 回归」模板

每次 CC 迭代都按这个模板记录，沉淀为团队的迭代档案。每个结论都要有证据支撑，下结论前同类错误样本至少积累 10 条，避免拿个例当模式：

CC 6 应用修复

• 修复手段取决于坏了什么：prompt 调整、换更好的模型、改进检索质量、拆分任务加组件
• 这是该工程化的时候（对应 CD 2 的"别过度工程化"），但必须由数据驱动，不靠猜
• 迭代节奏：改 → 重跑评测 → 再改，有数据就不必每次重新部署
• 评测本身也常失效（基于"预期用户行为"设计，而真实行为非确定），重做评测完全正常，通常要跑多轮

模型与供应商变更

"换模型"在传统软件里约等于换数据库驱动，在 AI 产品里等同于改产品范围：能力边界、失败模式、成本结构、延迟、评测基线全部会变。必须按变更管理对待：

判断标准一句话：任何模型变更都要有"评测集分数 + 在线指标 + 成本 + 失败模式迁移"四张对照表，缺一张不许上线。

安全、合规与组织流程

• 敏感场景审批：高风险功能（金融、医疗、未成年人、自动分发）上线前走审批链，审批依据是评测报告 + 责任表，不是"感觉没问题"
• 人类监督职责：每个代理权层级写明"谁盯、盯什么、值班表"；全自主执行必须有值班与升级路径
• 事故响应：按严重度分级（P0 数据泄露/资金损失 → P1 大面积错误 → P2 局部异常），每级有响应时限、责任人、复盘模板
• 模型卡/系统卡：参考大厂披露做法（OpenAI / Anthropic 的系统卡），为每个模型+产品组合维护一张卡：能力、已知限制、风险、缓解措施
• 审计留痕：prompt、模型版本、阈值、数据集的每次变更都留记录——这是"出错可追溯"的底线

生成式内容自带合规风险，具体红线（隐私、内容安全、算法备案、跨境传输）见 出海与合规；涉及 Agent 权限与护栏的安全设计见 Agent 产品 的清单。

成熟度模型：从 Demo 到可审计系统

同一个 CC/CD 循环，不同组织阶段跑出来的味道完全不同。用五级成熟度给团队定位，每级有明确的进入条件与退出信号：

从 L2 升 L3 最常见的卡点是"评测指标与线上指标不一致"——说明评测集代表性不足，先回去修评测，不要硬升。成熟度升级和代理权升级一样，要拿证据换，不是拿 PPT 换。

一个完整走查：客服工单助手

把框架套到一个具体场景，六步走一遍：

1. CD 1：把"智能客服"拆成代理权阶梯——v1 只做工单路由，v2 在路由之外建议解决方案，v3 才自动解决。参考数据集用历史工单整理出 50 条"用户 query + 应路由部门 + 决策元数据"
2. CD 2：v1 只搭路由模型 + 路由界面。日志记下"模型把工单分到了哪个部门、置信度多少"；客服界面放一个"一键改路由"按钮，修正结果写入日志——控制交接就落地了
3. CD 3：评测指标定为路由准确率。先用参考数据集跑一遍，确认评测设计合理（比如人工标注的"应路由部门"是否与真实客服判断一致）
4. 部署：先只给 10% 的工单开"路由建议"（不自动转派），观察真实使用
5. CC 4：累积 2000~3000 条真实工单后全量跑评测，代理指标是"是否被人工改路由"
6. CC 5：从最弱环节（比如"投诉类工单路由准确率最低"）抽 30 条人工审查，发现用户常把"退款"说成"退钱"，文档化成错误模式
7. CC 6：修复方式是给路由规则补同义词（或换检索方式），重跑评测确认提升后进入下一轮——此时 v2 的"建议解决方案"才有资格开工

注意第 6~7 步的顺序：先有数据证明"犯错可控"，才拿到下一级代理权。

完整阶段表（覆盖数据、评测、UI、人工接管、指标、风险与下一版门槛）：

核心原则

• 别用技术引领（Never lead with the tech）。让问题、评测、数据决定下一步加什么，复杂方案只在真正解决实际问题时引入。太多团队只追最新工具框架，却在错误方向上浪费大量成本
• 像带新同事。再聪明的新人也不会第一天就接手最高风险项目——从小事开始，观察、建立信任、逐步扩权。AI 系统同理：先让它给建议，再让它执行动作，最后才让它独立做决定
• 评测是信任额度。放权给系统的每一级，都对应一份评测证据；没有证据的放权是赌博（信任基线的展开见 Agent 产品）
• 上线是校准的开始，不是结束。发布即完成的思维在 AI 产品里直接等于放弃观察窗口
• CC/CD 的底层是判断力：发什么、出错时怎么保护用户、何时交还控制、何为"足够好"。框架只是给优秀的产品直觉一个循环、节奏和共同语言——比如用它来校准 项目管理与迭代 里提到的迭代节奏

常见误区

• 一上来就全代理：还没证明"犯错时可控"，就直接让系统自动执行。正确做法是 v1 先给建议，用数据换代理权
• 先选技术，再找问题：模型、框架、Agent 编排都不该是起点；问题、评测、数据才决定下一步
• 评测建完就不管：真实行为非确定，评测集会随使用变化而失真；评测失效要重做，这是正常节奏，不是失败
• 把部署当终点：上线不是交付完成，而是校准阶段的开始；不带日志和人工接管上线，等于放弃观察窗口
• 只涨基准分：评测指标与业务结果脱钩，分数好看、业务不动——这是评测体系失效的信号，先修评测
• 换模型不重测：把模型升级当普通依赖升级，不做行为 diff 和回归；"换模型 = 改产品范围"，必须走变更流程
• 数据集不治理：无版本、无标注协议、无脱敏，评测集沦为"谁的记忆好谁说了算"

求职与面试视角

面试 AI 产品设计题时，可以用 CC/CD 框架回答"如何从 0 设计一个 AI 功能"：先按代理权拆 v1 → v2 → v3，再讲参考数据、评测指标、人工兜底——比直接堆功能清单高级得多。

一个可复用的答题骨架：

1. 切版本：按代理权层级拆 v1/v2/v3，每级说清"系统能做什么、不能做什么"
2. 定评测：离线评测集（20~100 条种子，典型/边界/对抗）+ 线上行为指标（采纳率、改路由率）+ 人工抽检
3. 设计兜底：控制交接（一键改路由/转人工）、降级路径、成本护栏
4. 讲灰度：影子模式 → 白名单 → 比例放量，每档的升级与回滚条件
5. 闭环：badcase 回流 → 错误模式 → 修复 → 回归 → 下一级代理权

记住两句金句："代理权要赚取，不要授予"；"Never lead with the tech"。

该框架也能反哺日常判断：任何"直接上全自动"的方案，都值得先问一句"能不能先做成可覆写的建议"。面试追问"换模型怎么评估"或"评测失效怎么办"时，用本文的"模型与供应商变更"和"CC 阶段运营"两节回答，能体现真正的实操深度。

总结

下次设计 AI 功能，你能先画出一张代理权阶梯吗？

发现错误？想一起完善？ 在 GitHub 上编辑此页！
本页面贡献者：AI-PM Wiki Team
本页面的全部内容在 CC BY-SA 4.0 和 SATA 协议之条款下提供，附加条款亦可能应用