AI 产品 CC-CD 框架

CC/CD = Continuous Calibration / Continuous Development（名字致敬 CI/CD），为 AI 产品的两个现实设计：非确定性需要被压制或密切监控；agency 必须逐步挣得而非一次性授予。开发(CD)与校准(CC)构成持续循环，每一轮循环让系统多挣得一点 agency，最终形成飞轮。

CD 侧（发布前）：

1. Scope capability & curate data：按 agency 等级切版本而非按功能集（详见 agency-based-versioning--reganti-badam）；为当前版本建 reference dataset（用户输入 → 正确输出 → 决策所需元数据），从历史日志提取或构造样例，冷启动先攒 20-100 条。它既用于评估，也告诉你系统需要什么上下文。
2. Set up application：多数人跳过第 1 步直接陷在选型里——如果能力范围切好了，搭建应该很直接。此阶段别过度工程（"premature optimization is the root of all evil"），只建当前版本所需的最简系统；从第一天记录日志（系统看到什么、返回什么、用户如何交互），形成 live interaction dataset 的基础；设计 control handoffs——人能无缝接管纠正（如误路由的工单可被轻松改派），纠正动作被记录，既保用户体验又成为改进信号；对外暴露就把 guardrails 与合规基础打好。
3. Design evals：评估指标完全依应用与所切能力而定（v1 路由 → 路由准确率；v2 检索 SOP → 检索质量），是"非确定性系统的测试"，判断的是做得多好而非跑没跑通。先在 reference dataset 上跑，既校准系统也校验 eval 本身设计是否合理；目标是覆盖关键用例，不是完美。

Deploy（过渡）：小流量 cohort 上线。部署不是终点线，是进入校准环的过渡——你已有日志、有人工接管通道、有评估指标，不是 "vibe deploying"。

CC 侧（发布后）： 4. Run evals：在 live interaction data 上跑评估。数据量小（2000-3000 条）可全量；否则按系统特有信号采样（人工改派记录作为路由准确率代理、对话轮数、点赞点踩等）。control handoff 日志是特别宝贵的评估信号。 5. Analyze behavior & spot error patterns：人工审数据是被低估但必要的环节。从 eval 分数最弱处开始（信号最多），如每个落后部门抽 20-50 条低分工单；看用户说了什么、系统做了什么、结果如何；把重复出现的错误模式沉淀成表格，指导下一版的范围。 6. Apply fixes：这时才该加工程复杂度——改 prompt、换模型、提升检索、拆分任务组件，由数据驱动而非猜测。eval 本身也可能失准（它基于"预期行为"设计，真实行为可能很不同），重建 eval 属正常环节。有数据在手，修复迭代无需每次重新部署。