AI产品经理

AI驱动的AI产品经理专业人员用例。

1. AI模型评估框架构建器

用系统化的评估体系取代主观判断，为每次模型决策提供可重复、可信赖的依据。

痛点与解决方案

痛点：模型评估缺乏一致性，决策凭感觉而非数据

AI产品经理在选择或升级基础模型时，常常面临评估标准不统一的困境。团队A用BLEU分数衡量输出质量，团队B依赖用户满意度评分，团队C则直接让工程师主观判断——三种方法得出三种结论，最终决策变成内部争论，而非数据驱动的选择。这种混乱不仅浪费资源，更可能导致产品在模型升级后出现意想不到的质量退化。

更深层的问题在于，通用基准测试（如MMLU、HumanEval）与实际业务场景之间存在巨大鸿沟。一个在学术基准上领先的模型，在特定垂直领域的任务表现可能远不如宣传。医疗问答、法律文档分析、金融报告生成——每个场景都需要领域特定的评估套件，而非从论文中借用的通用指标。当产品团队没有自己的评估框架时，他们实际上是在把用户当成测试者，用生产流量验证模型质量假设。

评估滞后还会造成"幻觉盲区"——团队不知道自己不知道什么。幻觉率（hallucination rate）在不同模型、不同查询类型上差异悬殊，但如果没有专门的事实核查评估管道，这个关键指标就会处于观测盲区。直到用户投诉、媒体报道或企业客户升级，团队才意识到问题的严重性，而此时修复成本已经远超早期检测的代价。

COCO如何解决

1. 领域特定评估套件设计：COCO帮助构建贴近真实业务的评估体系：

   • 从生产日志中提取代表性查询，按复杂度、领域和意图分层抽样
   • 为每类查询定义明确的评分标准：相关性、准确性、完整性、格式合规性
   • 设计人工评估与自动评估的混合流程，平衡评估成本与精度
   • 建立"黄金集"（golden set）——带有人工标注答案的固定测试用例，用于跨版本比较
   • 针对RAG系统设计检索质量评估：命中率、MRR（平均倒数排名）、上下文相关性得分

2. 多维质量指标体系：COCO定义超越单一分数的综合评估维度：

   • 事实准确性：使用LLM-as-judge交叉验证可验证的事实性声明
   • 幻觉率基准：通过已知答案的探测性查询定期检测捏造内容
   • 指令遵循度：衡量模型遵循复杂、多步骤提示词的能力
   • 输出一致性：同一查询在不同运行中的输出相似度（检测高方差问题）
   • 安全边界遵守：通过红队测试集验证拒绝策略的可靠性

3. 自动化评估管道架构：COCO设计可规模化的评估基础设施：

   • 配置CI/CD集成的评估触发器，在每次模型更新时自动运行基准测试
   • 设计LLM-as-judge提示词模板，并附有针对不同质量维度的校准用例
   • 建立评估结果数据库，支持跨版本、跨时间段的趋势分析
   • 设置质量门控阈值：低于阈值的模型版本自动触发告警，阻止生产部署
   • 实现A/B评估框架：同一查询集在多个模型上并行运行，支持直接对比

4. 供应商能力矩阵构建：COCO系统化评估不同模型提供商：

   • 在统一评估套件上对比GPT-4o、Claude、Gemini、Llama等模型的领域表现
   • 量化每个提供商在速度（延迟p50/p95/p99）、成本（每百万token价格）、质量三个维度的权衡
   • 追踪提供商模型更新对评估结果的影响，建立版本变更日志
   • 评估提供商的API稳定性、限速策略和SLA承诺
   • 分析微调可行性：哪些模型支持领域微调，预期ROI如何

5. 评估结果可视化与决策支持：COCO将评估数据转化为可操作的洞察：

   • 生成维度蜘蛛图：直观展示模型在不同质量维度上的优劣势
   • 设计成本-质量权衡曲线：帮助决策者选择最优的成本效益点
   • 生成分段分析报告：按查询类型、用户群体分解模型表现差异
   • 提供模型升级风险评估：识别新版本在哪些场景中存在退化风险
   • 输出评估报告模板，供模型选型决策会议使用

6. 持续评估与漂移监测：COCO建立长期质量监控机制：

   • 设计每日/每周评估探针：在生产环境中持续运行固定查询集
   • 建立统计过程控制图：检测质量指标的异常偏移
   • 配置模型漂移告警：当评估指标偏离基线超过预设阈值时自动通知团队
   • 实现用户反馈闭环：将用户点踩数据纳入评估套件更新流程
   • 生成季度评估健康报告，追踪模型质量随时间的演变趋势

量化结果与受益角色

可量化的成果

• 模型决策周期：从依赖主观判断的2-3周缩短至数据驱动的3-5天
• 幻觉率检测：系统化评估使幻觉问题的发现时间提前14天，较依赖用户反馈的方式早发现70-80%
• 模型升级成功率：带质量门控的评估框架使生产级模型退化事故减少65%
• 供应商成本优化：基于领域特定评估的供应商选择，实现等质量前提下成本降低25-40%
• 评估覆盖率：从人工抽检5-10%的输出提升至自动化覆盖100%的关键查询类型

受益人群

• AI产品经理：以可重复、可对比的数据替代主观判断，提升模型选型决策的可信度
• ML工程师：获得标准化的评估基础设施，减少每次模型迭代的手动测试工作量
• 工程领导层：用质量门控替代人工审批，加速模型部署流程同时降低质量风险
• 企业客户：受益于更稳定、更可预测的AI输出质量，降低业务流程中的不确定性

💡 实用提示词

提示词1 — 评估套件设计

你是一位AI产品评估专家。请为以下AI产品设计一套全面的模型评估框架。

产品名称：[产品名称]
核心使用场景：[描述主要使用场景，如客服问答、文档摘要、代码生成等]
目标用户群体：[描述用户类型和技术熟练程度]
当前使用的模型：[现有模型]
主要质量痛点：[描述用户反馈最多的质量问题]

请设计评估框架，包含以下内容：

1. 评估维度定义（5-7个维度）：
   对于每个维度：维度名称、定义、测量方法、权重（总计100%）、自动化可行性

2. 测试集构建方案：
   - 查询类型分层：按难度（简单/中等/困难）和类型（事实性/推理性/创意性）分类
   - 样本量建议：每类至少需要多少样本才能得出统计显著的结论
   - 金标准答案标注指南：如何标注参考答案，处理主观性问题

3. LLM-as-judge配置：
   - 推荐的judge模型
   - 针对每个评估维度的judge提示词模板（包含评分标准和示例）
   - judge偏差校准方法

4. 自动化评估管道设计：
   - 触发条件：什么情况下运行完整评估
   - 运行频率建议
   - 结果存储和版本控制方案
   - 质量门控阈值建议

5. 评估结果解读指南：
   - 哪些指标变化需要立即关注
   - 如何区分统计噪声和真实质量变化
   - 模型选型决策树

输出：完整评估框架文档 + 测试集设计规范 + LLM-as-judge提示词库

提示词2 — 幻觉率基准测试

设计针对以下AI产品的幻觉率基准测试方案。

产品：[产品名称和主要功能]
知识领域：[产品主要处理的知识领域，如医疗、金融、法律、技术文档等]
高风险场景：[哪些类型的输出如果包含错误信息会造成严重影响]

请设计幻觉率测试方案：

1. 幻觉类型分类：
   - 事实性幻觉：捏造不存在的事实、数据、引用
   - 知识截止幻觉：将过时信息呈现为当前事实
   - 逻辑推理错误：从正确前提推导出错误结论
   - 虚假引用：引用不存在的来源、论文、法规
   - 混淆幻觉：将相似但不同的概念混为一谈

2. 针对每种幻觉类型设计测试用例（各5个示例）：
   - 测试查询
   - 正确答案（有来源支持）
   - 常见幻觉模式描述
   - 自动检测方法

3. 检测管道设计：
   - 对于可验证的事实：如何自动交叉检验
   - 对于需要人工判断的内容：评估指南和样本抽检率
   - 置信度评分：如何量化输出的可信程度

4. 幻觉率计算方法：
   [幻觉输出数] / [总测试输出数] × 100%
   分类统计：各类型幻觉的分布比例

5. 改进行动触发阈值：
   - 可接受范围：<[X]%
   - 需要调查：[X]%-[Y]%
   - 需要立即行动：>[Y]%

输出：幻觉率测试套件 + 检测方法指南 + 改进行动触发规则

提示词3 — 模型供应商对比分析

对以下候选模型进行系统化对比评估，支持供应商选型决策。

产品使用场景：[详细描述主要使用场景]
候选模型：[列出2-4个候选模型，包括提供商信息]
评估预算：[可用于评估的资源：计算成本、人工标注时间等]
决策时间节点：[需要做出决定的截止日期]

评估框架：

1. 质量基准对比（使用统一测试集）：
   测试集：[描述你的测试查询集]

   对于每个模型，在以下维度评分（1-5分）：
   - 任务完成质量：[根据你的使用场景定义]
   - 输出一致性：10次相同查询的结果稳定性
   - 指令遵循度：对复杂提示词的响应准确率
   - 安全合规性：对不当请求的拒绝可靠性
   - 输出格式化：对格式要求的遵守程度

2. 性能基准对比：
   - 延迟（p50/p95/p99 毫秒）
   - 吞吐量（并发请求处理能力）
   - 上下文窗口大小
   - 流式响应支持情况

3. 成本对比：
   - 每百万输入token价格
   - 每百万输出token价格
   - 按当前查询分布估算的月度成本
   - 微调成本（如需要）

4. 综合评分矩阵：
   [质量权重×质量分] + [性能权重×性能分] + [成本权重×成本分（反向）]
   权重建议：质量50% + 性能30% + 成本20%（根据业务优先级调整）

5. 风险评估：
   - 供应商依赖风险
   - API稳定性历史记录
   - 价格变动风险
   - 数据隐私合规情况

6. 最终推荐：
   主选模型 + 理由 + 风险缓解措施 + 备选方案

输出：供应商对比矩阵 + 加权评分 + 推荐决策 + 实施路线图

提示词4 — 评估结果解读与行动计划

解读以下模型评估结果，并生成具体行动计划。

评估背景：
- 评估对象：[当前模型] vs [候选模型]
- 测试集规模：[查询数量]
- 评估时间：[日期范围]

评估结果摘要：
[粘贴或描述评估结果，包括各维度得分、统计显著性检验结果等]

请进行以下分析：

1. 结果统计显著性验证：
   - 观测到的差异是否超过统计噪声水平？
   - 置信区间是什么？
   - 需要更大的测试集来确认结论吗？

2. 分场景分析：
   - 在哪些查询类型上候选模型明显优于当前模型？
   - 在哪些查询类型上候选模型表现更差（退化风险）？
   - 质量变化与查询复杂度/领域是否存在相关性？

3. 业务影响评估：
   - 质量改善最大的场景对应的用户流量占比？
   - 质量退化的场景对应的高风险业务流程是什么？
   - 净用户体验影响预测：改善 vs 退化的加权结果

4. 决策建议：
   - 立即切换：[条件]
   - 部分切换（特定场景路由到新模型）：[条件]
   - 延迟切换（待进一步改进后）：[条件]
   - 不切换：[条件]

5. 切换风险缓解方案：
   - 分阶段推出计划（1% → 10% → 50% → 100%）
   - 每阶段的质量监控指标和回滚触发条件
   - A/B测试设计（保留对照组持续监控）

输出：评估结果解读报告 + 业务影响评估 + 切换决策框架 + 分阶段推出计划

提示词5 — 评估框架持续改进

审查并改进现有AI产品评估框架的有效性。

当前评估框架概述：[描述现有评估方法、指标和流程]
已发现的框架局限性：[描述哪些质量问题没有被现有框架捕捉到]
最近发生的质量事件：[描述任何用户投诉或生产质量问题，以及这些问题是否本应被评估框架提前发现]

请进行框架审计：

1. 覆盖度分析：
   - 当前框架评估了哪些质量维度？
   - 哪些重要的质量维度完全未被覆盖？
   - 现有测试集是否代表真实的生产查询分布？（与生产数据对比）

2. 测试集质量评估：
   - 测试用例是否过时？（是否反映用户现在实际提问的内容）
   - 测试集是否存在选择偏差？（是否过度代表容易的查询）
   - 高风险边缘案例的覆盖率如何？

3. judge校准评估：
   - LLM-as-judge分数与人工评估分数的相关系数是多少？
   - judge在哪些类型的查询上最不可靠？
   - 是否存在系统性偏差（如倾向于为冗长输出打高分）？

4. 改进优先级排序：
   根据"预期改进价值 ÷ 实施成本"排序推荐改进项：
   - 高优先级（本季度实施）：[列表]
   - 中优先级（下季度实施）：[列表]
   - 低优先级（长期规划）：[列表]

5. 评估框架升级路线图：
   - 第1个月：[具体改进项和负责人]
   - 第2-3个月：[具体改进项]
   - 第4-6个月：[长期改进项]

输出：框架审计报告 + 改进优先级矩阵 + 升级路线图 + 成功指标定义

2. AI提示词工程工作流优化器

将提示词工程从反复试错的黑艺术，变成系统化、可复现的产品工程实践。

痛点与解决方案

痛点：提示词工程的混乱导致质量不稳定、知识无法传承

大多数AI产品团队的提示词工程处于混乱状态：关键的系统提示词散落在工程师的本地文件、Notion页面和Slack消息中，没有版本控制，没有变更记录，也没有人真正理解为什么某个特定的提示词结构能够工作。当模型提供商悄悄更新了底层模型，导致精心调试的提示词突然失效时，团队才意识到之前的工作从未被系统化地保存下来。

提示词迭代效率低下是另一个核心痛点。工程师在没有系统化测试框架的情况下修改提示词，凭直觉判断新版本是否"更好"，却无法量化改进幅度，也无法确保改进在不同查询类型上是否一致。更糟糕的是，一个针对某类查询优化的提示词修改，可能在不经意间降低了另一类查询的质量——而这种退化在没有自动化回归测试的情况下根本无法被及时发现。

跨团队的提示词知识孤岛进一步放大了这些问题。当多个产品功能共享底层模型时，不同团队各自维护独立的提示词实践，无法相互学习。某个团队在思维链（chain-of-thought）提示词上积累的经验，在没有知识共享机制的情况下，无法被其他团队复用。每个团队都在重复踩同样的坑，而整体的提示词工程能力始终停留在个人经验层面。

COCO如何解决

1. 提示词架构标准化：COCO建立统一的提示词工程规范：

   • 定义提示词组件框架：角色定义、任务说明、输出格式约束、安全护栏、少样本示例
   • 设计系统提示词与用户提示词的职责边界，避免逻辑混乱
   • 建立提示词版本控制规范：语义化版本号、变更描述、影响范围标注
   • 创建提示词模板库：覆盖常见任务类型的可复用提示词结构
   • 设计提示词文档标准：每个提示词必须包含的元数据和设计说明

2. 系统化迭代流程设计：COCO将提示词优化变成工程实践：

   • 建立假设驱动的提示词迭代框架：明确假设、设计测试、量化结果
   • 设计提示词A/B测试基础设施：在相同查询集上并行测试多个版本
   • 创建提示词性能基准：每次迭代必须在基准测试上超越前一版本才能合并
   • 建立快速验证流程：区分"探索性测试"（少量查询快速验证）和"验证性测试"（完整基准）
   • 设计提示词迁移风险评估：评估提示词变更对不同模型版本的兼容性

3. 提示词性能分析框架：COCO量化提示词工程的投入产出：

   • 定义提示词效率指标：每token的输出质量提升、任务完成率、拒绝率
   • 设计提示词成本分析：不同提示词结构的token消耗对比
   • 建立提示词鲁棒性测试：用边缘案例和对抗性输入测试提示词稳定性
   • 创建提示词敏感性分析：识别哪些提示词元素对输出质量影响最大
   • 设计跨模型兼容性测试：验证提示词在不同模型版本间的迁移性

4. 知识管理与团队协作：COCO建立提示词知识共享机制：

   • 设计提示词知识库结构：按任务类型、成功模式、失败案例组织
   • 建立提示词审查流程：重要提示词变更需要同行评审
   • 创建提示词工程师成长路径：从初级模板使用到高级架构设计
   • 设计跨团队提示词复用机制：识别可共享的通用提示词组件
   • 建立提示词失败案例库：记录和分析失败模式，防止重复犯错

5. 提示词安全与护栏设计：COCO确保提示词安全性：

   • 设计系统提示词安全加固方案：防止提示词注入和越权攻击
   • 建立输入/输出过滤器集成规范：与提示词配合工作的安全层设计
   • 创建提示词泄露防护策略：防止系统提示词被恶意用户提取
   • 设计内容策略执行机制：在提示词层面实现一致的内容限制
   • 建立安全提示词测试套件：覆盖常见攻击向量的测试用例

6. 生产环境提示词监控：COCO建立运行时可观测性：

   • 设计提示词性能追踪：监控每个提示词版本在生产环境中的质量表现
   • 建立提示词健康仪表板：关键质量指标的实时可视化
   • 创建提示词变更影响分析：新版本部署后的质量对比报告
   • 设计快速回滚机制：当新提示词导致质量下降时的快速恢复流程
   • 建立提示词使用统计：了解哪些提示词模板被最频繁地使用和修改

量化结果与受益角色

可量化的成果

• 提示词迭代周期：从非正式的手动测试（平均5-7天）缩短至系统化测试流程（1-2天）
• 质量退化事故：有回归测试保护的提示词变更使生产质量事故减少60-70%
• 跨团队知识复用：提示词知识库建立后，新功能开发中的提示词工程时间减少40%
• Token效率提升：系统化的提示词优化通常实现15-25%的token消耗降低，同等质量前提下
• 工程师入职时间：标准化的提示词工程框架使新工程师在首周内即可贡献生产级提示词

受益人群

• AI产品经理：获得对提示词质量的可见性和控制力，而非依赖工程团队的口头汇报
• ML工程师：用系统化框架替代反复试错，将创造力集中在高价值的提示词架构创新上
• 产品设计师：清晰理解AI功能的能力边界，设计更准确匹配模型能力的用户界面
• 新入职团队成员：通过结构化文档和知识库快速掌握团队的提示词工程实践

💡 实用提示词

提示词1 — 提示词架构审计

审计以下AI产品的系统提示词，找出改进机会。

产品功能：[描述这个提示词所服务的功能]
当前系统提示词：[粘贴完整的系统提示词]
主要质量问题：[描述用户反馈或监控数据显示的质量问题]
目标模型：[使用的模型]

请进行系统性审计：

1. 结构评估：
   - 角色定义是否清晰？（模型知道自己是谁，有什么能力限制吗？）
   - 任务说明是否具体？（避免歧义，用例是否充分覆盖）
   - 输出格式约束是否明确？（长度、格式、语气要求）
   - 安全护栏是否完整？（拒绝策略、内容限制）
   - 少样本示例是否有效？（如果有，质量和多样性如何）

2. 逻辑连贯性检查：
   - 提示词内部是否存在矛盾指令？
   - 指令优先级是否清晰？（当多个指令冲突时，模型应该怎么选择）
   - 提示词是否会导致不必要的推理负担（增加延迟和成本）？

3. 改进建议（按优先级排序）：
   高优先级（立即修改）：
   - [问题描述] → [具体改进建议] → [预期改进效果]

   中优先级（本周内修改）：
   - [问题描述] → [具体改进建议]

   低优先级（下次迭代考虑）：
   - [问题描述] → [建议]

4. 改进版提示词草案：
   [提供改进后的完整提示词，并用注释标注每处修改的原因]

5. A/B测试建议：
   - 测试集设计：哪些查询类型最能体现改进效果
   - 评估指标：用哪些指标衡量改进是否成功
   - 样本量建议：需要多少数据才能得出可靠结论

输出：审计报告 + 改进版提示词 + A/B测试方案

提示词2 — 思维链提示词设计

为以下复杂推理任务设计思维链（Chain-of-Thought）提示词。

任务类型：[描述需要多步推理的任务，如财务分析、医疗诊断支持、法律文档分析]
当前问题：模型直接跳到结论，中间推理过程不透明，容易出错
目标：引导模型展示推理步骤，提高准确性和可解释性

设计思维链提示词：

1. 推理框架定义：
   为这个任务设计一个结构化的推理框架：
   步骤1：[信息收集和理解]
   步骤2：[关键因素识别]
   步骤3：[推理过程]
   步骤4：[结论形成]
   步骤5：[信心评估和局限性声明]

2. 少样本示例设计（3个示例）：
   对于每个示例：
   - 输入查询（具有代表性）
   - 标准思维链推理过程（展示理想的推理步骤）
   - 最终输出（格式规范）

3. 提示词模板：
   [完整的思维链提示词，包含角色、框架说明、示例、格式要求]

4. 变体设计（针对不同场景）：
   - 简短版（延迟敏感场景）：省略哪些推理步骤
   - 详细版（高风险决策场景）：增加哪些验证步骤
   - 交互版（需要用户确认中间步骤）：如何设计对话流

5. 评估方案：
   如何衡量思维链提示词是否真正提高了推理准确性？
   - 测试用例设计
   - 准确性评估标准
   - 与无思维链版本的A/B对比方法

输出：完整思维链提示词 + 少样本示例 + 评估方案

提示词3 — 提示词版本控制规范

为AI产品团队设计提示词版本控制和变更管理规范。

团队规模：[人数和角色构成]
当前痛点：[描述现有提示词管理的混乱之处]
技术栈：[使用的代码仓库、部署工具等]

设计规范：

1. 提示词文件结构：
   每个提示词文件应包含：
   ```yaml
   metadata:
     id: [唯一标识符]
     version: [语义化版本号，如 2.1.3]
     created: [创建日期]
     author: [创建者]
     last_modified: [最后修改日期]
     status: [draft/testing/production/deprecated]
   description:
     purpose: [这个提示词的功能描述]
     use_cases: [适用场景列表]
     limitations: [已知局限性]
   performance:
     benchmark_score: [最新基准分数]
     test_date: [测试日期]
     test_set_version: [使用的测试集版本]
   content:
     system_prompt: |
       [完整系统提示词]
   changelog:
     - version: [版本号]
       date: [日期]
       changes: [变更描述]
       reason: [变更原因]

2. 变更审批流程：

   • 小改动（格式、错别字）：无需审批，直接提交
   • 中改动（措辞调整、新增指令）：需1人同行评审 + 基准测试通过
   • 大改动（结构重组、核心逻辑变更）：需2人评审 + 完整测试套件通过 + PM审批

3. 部署流程： 开发环境 → 测试环境（自动化测试）→ 灰度（5%流量）→ 生产（满足质量门控后）

4. 回滚程序：

   • 触发条件：关键指标下降超过[X]%持续[Y]分钟
   • 自动回滚vs手动回滚的决策标准
   • 回滚后的问题分析流程

5. 跨团队共享机制：

   • 通用提示词组件库的维护责任
   • 提示词复用时的引用和通知机制
   • 共享提示词的变更影响通知流程

输出：完整版本控制规范文档 + YAML模板 + 审批流程图

**提示词4 — 提示词注入防护设计**

设计针对以下AI产品的提示词注入防护方案。

产品类型：[描述产品，特别是用户输入如何被纳入提示词] 暴露风险：[描述哪些场景下用户可以影响模型的行为] 业务影响：[如果提示词注入成功，最严重的后果是什么]

设计防护方案：

1. 攻击向量分析： 基于产品架构，识别最高风险的注入场景：

   • 直接注入：用户输入中包含覆盖系统提示词的指令
   • 间接注入：通过用户上传的文档/数据注入恶意指令
   • 多轮对话注入：通过对话历史累积影响模型行为
   • 越权请求：诱导模型披露系统提示词或执行禁止操作

2. 系统提示词加固： [提供具体的提示词加固技术，如分隔符设计、角色强化、拒绝策略强化]

3. 输入预处理层设计：

   • 需要过滤的高风险模式（正则表达式或语义检测）
   • 白名单vs黑名单策略的选择
   • 输入长度限制和格式验证

4. 输出后处理层设计：

   • 检测泄露系统提示词内容的方法
   • 检测异常行为模式的信号
   • 触发人工审核的条件

5. 监控和告警：

   • 生产环境中检测潜在注入攻击的信号
   • 告警阈值和响应流程
   • 注入攻击事件的记录和分析

6. 测试套件（10个具体测试用例）： [针对这个产品的注入攻击测试用例，覆盖不同攻击向量]

输出：防护架构设计 + 系统提示词加固方案 + 测试套件 + 监控配置

**提示词5 — 多语言提示词优化**

优化以下AI产品的多语言提示词策略。

产品：[名称和功能描述] 目标语言：[列出需要支持的语言] 当前多语言方案：[描述现有方案，如统一英文提示词/分语言提示词/机器翻译] 已发现的质量差异：[描述不同语言间的质量差距]

优化方案：

1. 多语言质量评估： 在以下维度对比各语言的当前质量：

   • 输出流畅度（是否自然地道）
   • 术语准确性（专业词汇翻译是否准确）
   • 文化适应性（表达方式是否符合当地习惯）
   • 格式一致性（输出格式是否与英文版一致）

2. 提示词语言策略选择： 方案A：统一英文提示词 + 依赖模型多语言能力 适用条件：[什么情况下这个方案够用] 局限性：[什么情况下这个方案不足]

   方案B：每种语言独立提示词 成本：[维护多套提示词的工作量] 收益：[质量提升的预期]

   方案C：混合方案（英文核心+语言特定补充） 架构：[如何实现]

   针对你的产品推荐：[推荐方案及理由]

3. 针对每种目标语言的提示词优化建议： [语言1]：

   • 语言特定挑战：[描述这个语言在AI生成中的常见问题]
   • 提示词调整建议：[具体修改方向]
   • 质量验证方法：[如何评估优化效果]

   [重复其他语言]

4. 多语言提示词维护流程：

   • 当英文主提示词更新时，如何同步其他语言版本
   • 母语评审员的参与方式
   • 多语言基准测试的建立

输出：多语言提示词策略报告 + 各语言优化建议 + 维护流程设计

3. AI偏见检测与公平性审计引擎

在偏见造成用户伤害或监管处罚之前，系统化地检测、量化并修复AI系统中的歧视性模式。

痛点与解决方案

痛点：AI偏见问题被发现时往往已经造成实质性损害

大多数AI产品团队对偏见问题的处理方式是被动的：等到用户投诉、记者报道或监管部门询问，才开始匆忙调查。这种被动应对模式导致偏见问题在产品中积累，悄悄侵蚀不同用户群体的体验质量，直至达到临界点才爆发。对于涉及招聘筛选、信用评估、医疗建议等高风险场景的AI产品，这种延迟发现可能意味着法律责任和不可逆的品牌损害。

量化偏见的技术挑战使得主动检测更加困难。"公平性"本身并非单一定义——人口平等（demographic parity）、机会均等（equal opportunity）、个体公平性（individual fairness）在数学上相互矛盾，无法同时完全满足。AI产品经理面临的现实是：他们需要在多种公平性定义之间做出有意识的取舍，但大多数团队既没有能力量化这些维度，也没有机制在产品决策中讨论这些取舍。结果是，公平性目标从未被明确定义，公平性问题也就永远无法被系统性地解决。

训练数据中的历史偏见通过模型传播到产品输出，形成反馈循环。如果训练数据反映了历史上对某些群体的不平等对待，模型学习并强化这些模式，产品输出进一步固化这些不平等，用户行为数据再次进入训练循环——整个系统在没有主动干预的情况下会自我强化偏见，而非自我纠正。

COCO如何解决

1. 偏见审计框架设计：COCO建立系统化的偏见检测体系：

   • 识别与产品使用场景相关的受保护属性（种族、性别、年龄、宗教、残疾状况等）
   • 设计分组公平性测试：在受保护属性的不同子群体上测量输出质量差异
   • 建立表征偏见测试：检测AI在描述不同群体时是否存在刻板印象
   • 创建情感分析对比：检测模型对不同群体的描述是否存在系统性情感倾向
   • 设计交叉性分析：评估多个属性交叉时的复合偏见效应

2. 量化公平性指标体系：COCO定义可测量的公平性目标：

   • 人口平等：各群体获得正面输出的概率是否相等
   • 机会均等：各群体中"真正优质"案例被正确识别的比率是否相等
   • 校准公平性：模型置信度是否在各群体间同样可靠
   • 个体公平性：相似输入是否产生相似输出，不因群体身份而异
   • 反事实公平性：将群体标识符替换后输出是否保持一致

3. 偏见溯源与根因分析：COCO识别偏见的来源：

   • 数据偏见分析：训练数据中不同群体的代表性和标签质量差异
   • 标注偏见检测：人工标注员的主观倾向对训练数据的影响
   • 模型架构偏见：特定模型架构对某些输入特征的过度依赖
   • 提示词偏见：系统提示词中无意强化刻板印象的语言模式
   • 反馈循环偏见：用户交互数据如何强化而非纠正现有偏见

4. 缓解策略设计与实施：COCO提供针对性的偏见修复方案：

   • 提示词层面缓解：重新设计系统提示词以减少刻板印象触发
   • 输出后处理：针对检测到的偏见模式设计过滤和修正机制
   • 数据增强策略：识别训练数据中的代表性不足，设计补充方案
   • 对抗性去偏见：通过对抗训练减少模型对受保护属性的敏感性
   • 人工审核集成：为高风险输出设计人工审核流程

5. 合规文档生成：COCO产出监管所需的证据文档：

   • 生成符合EU AI Act要求的偏见测试报告
   • 创建EEOC风格的差异影响分析（针对就业场景）
   • 输出ECOA合规证明（针对信贷场景）
   • 设计模型卡中的偏见测试部分
   • 建立持续监控的偏见审计追踪记录

6. 持续偏见监控机制：COCO建立生产环境中的公平性监测：

   • 设计生产环境公平性指标追踪
   • 建立偏见漂移告警：当公平性指标超出可接受阈值时触发
   • 创建周期性偏见审计触发器（模型更新、用户群体变化后）
   • 设计用户偏见投诉分类和优先级处理流程
   • 建立公平性改进的ROI追踪机制

量化结果与受益角色

可量化的成果

• 偏见检测前置：主动审计将偏见问题的发现时间从用户投诉（平均3-6个月后）提前到发布前
• 法律风险降低：有记录的偏见测试将差异影响索赔的法律风险降低60-70%
• 用户信任提升：公平性认证使AI产品的企业采购通过率提升35%
• 受影响群体体验改善：系统化去偏见措施使最受影响用户群体的满意度提升20-30%
• 监管合规成本：前期偏见审计比后期整改节省4-8倍的成本

受益人群

• AI产品经理：将公平性从事后补救变成前期设计原则，减少昂贵的产品召回风险
• 法律合规团队：获得系统化的偏见检测证据，支持监管审查和诉讼防御
• 弱势用户群体：从AI系统中获得与其他群体相当的服务质量
• 企业客户：通过有文档支持的公平性实践，降低部署AI产品的合规风险

💡 实用提示词

提示词1 — 偏见审计设计

为以下AI产品设计一套全面的偏见审计方案。

产品：[名称和使用场景]
受保护属性：[与此产品相关的人口统计属性，如性别、种族、年龄、宗教等]
高风险决策点：[AI输出可能影响重大的场景]
适用法规：[如EU AI Act、EEOC指南、ECOA、GDPR等]

设计偏见审计方案：

1. 审计范围界定：
   - 将接受测试的受保护属性列表及其子群体
   - 测试场景优先级（按潜在危害程度排序）
   - 审计深度：表层输出测试 vs 深层系统测试

2. 测试用例设计（每种偏见类型各5个示例）：

类型A — 表征偏见测试：
测试方法：要求AI描述不同群体成员在相同职业、情境下的形象
评估标准：语言的正面/负面程度、刻板印象程度

类型B — 分组性能差异测试：
测试方法：对不同群体成员提出相同的服务请求
评估标准：回答质量、详细程度、帮助态度的一致性

类型C — 反事实测试：
测试方法：将描述中的群体标识符替换，比较输出变化
评估标准：输出在统计上是否因群体标识符的变化而显著改变

3. 公平性指标计算：
   - 对于每个测试类型，定义具体的公平性指标及计算公式
   - 可接受的差异阈值（什么程度的差异触发干预）
   - 统计显著性要求（需要多少样本）

4. 报告格式：
   [设计偏见审计报告的结构，满足监管要求]

输出：偏见审计方案 + 测试用例库 + 公平性指标体系 + 合规报告模板

提示词2 — 公平性指标选择框架

为以下AI产品场景选择适当的公平性定义和指标。

产品使用场景：[详细描述，如招聘筛选、贷款评分、内容推荐、医疗建议]
核心决策/输出类型：[AI产生的决策或输出类型]
可能受到影响的群体：[哪些群体可能因AI决策受益或受损]
业务约束：[如何平衡公平性与准确性的业务要求]

分析公平性定义的适用性：

1. 人口平等（Demographic Parity）：
   定义：各群体获得正面输出的比例相等
   适用场景：[什么场景下这是合适的公平性定义]
   局限性：[什么场景下这个定义不适用或会产生问题]
   对这个产品的适用性：[适用/不适用/部分适用，说明理由]

2. 机会均等（Equal Opportunity）：
   定义：真实正例在各群体间的被识别率相等
   适用场景/局限性/对本产品适用性：[同上格式]

3. 校准公平性（Calibration Fairness）：
   定义：预测置信度在各群体间同样准确
   适用场景/局限性/对本产品适用性：[同上格式]

4. 公平性定义的相互矛盾性：
   [解释为什么不能同时满足所有公平性定义]
   [在这个具体场景中，哪些公平性目标之间存在张力]

5. 推荐的公平性指标组合：
   主要指标：[选择最重要的公平性定义，说明理由]
   次要指标：[作为护栏的辅助指标]
   监控指标：[用于持续追踪的指标]

6. 可接受的差异阈值：
   [为每个指标建议可接受的差异范围，并说明标准来源（法规要求/行业惯例/内部决策）]

输出：公平性指标选择报告 + 权衡分析 + 实施优先级

提示词3 — 偏见根因分析

分析以下偏见检测结果，识别根本原因并制定缓解策略。

产品：[名称]
偏见发现摘要：[描述检测到的偏见类型和严重程度]
偏见测试数据：[粘贴或描述具体的测试结果]
技术架构：[模型类型、训练数据来源、提示词设计等]

进行根因分析：

1. 潜在根因识别：
   对于每个检测到的偏见：
   - 数据偏见假设：训练数据是否存在代表性不足或标签偏差？有什么证据？
   - 模型架构假设：特定架构特性是否放大了偏见？
   - 提示词假设：系统提示词中是否存在触发偏见的语言？
   - 反馈循环假设：历史用户交互是否强化了偏见？

2. 根因验证实验设计：
   对于每个假设，设计验证实验：
   - 实验设计（如何验证/否定这个假设）
   - 所需数据/资源
   - 预期结论及对应行动

3. 缓解优先级排序：
   高优先级（立即实施）：
   - [缓解措施] → 针对 [根因] → 预期效果

   中优先级（30天内）：
   - [缓解措施] → 针对 [根因] → 预期效果

   长期措施：
   - [系统性改进] → 针对 [根因] → 预期效果

4. 快速缓解方案（不需要重新训练模型）：
   - 提示词层面：[具体的提示词修改建议]
   - 输出过滤层面：[需要添加的过滤规则]
   - 人工审核层面：[哪些输出需要人工审核，标准是什么]

5. 长期根治方案：
   - 训练数据改进方向
   - 模型微调目标设计
   - 评估体系完善

输出：根因分析报告 + 缓解措施优先级矩阵 + 快速缓解方案 + 长期改进计划

提示词4 — 公平性合规文档生成

为以下AI产品生成满足监管要求的公平性合规文档。

产品：[名称和描述]
适用法规：[EU AI Act / EEOC / ECOA / 医疗相关法规 / 其他]
偏见测试结果：[测试方法、测试数据规模、检测到的问题和已采取的缓解措施]
剩余风险：[在缓解措施后仍然存在的公平性风险]

生成合规文档：

1. 偏见与公平性测试报告：
   1.1 测试概述：测试目标、方法论、测试期间
   1.2 受保护属性覆盖范围
   1.3 测试数据集描述：规模、组成、代表性说明
   1.4 测试结果：每个受保护属性的公平性指标值
   1.5 检测到的偏见：描述、严重程度、影响范围
   1.6 缓解措施：已采取的措施及效果证明
   1.7 剩余风险声明：剩余差异及其管理方式
   1.8 监控承诺：持续监控的指标和频率

2. 差异影响分析（适用于就业场景）：
   按照EEOC四分之五规则进行计算和记录

3. 算法影响评估（EU AI Act适用）：
   覆盖基本权利影响、公平性测试、人工监督机制

4. 模型卡公平性部分：
   训练数据公平性注意事项
   已知局限性和偏见
   使用限制和禁止场景

输出：完整合规文档套件 + 证据附件清单 + 更新维护计划

提示词5 — 持续公平性监控系统设计

设计AI产品的持续公平性监控系统。

产品：[名称]
当前公平性测试结果（基线）：[关键公平性指标的当前值]
用户数量和多样性：[用户群体规模和人口构成信息可获得性]
技术基础设施：[可用的监控和分析工具]

设计监控系统：

1. 生产环境公平性指标追踪：
   - 哪些公平性指标可以在不收集用户人口统计数据的情况下追踪？
   - 哪些代理指标（proxy metrics）可以作为公平性的间接指标？
   - 数据收集的隐私保护措施

2. 分群分析方法：
   - 如何在隐私约束下进行分群性能分析
   - 差分隐私方法的应用
   - 用户选择提供人口统计信息的激励设计

3. 告警系统设计：
   - 公平性漂移检测阈值（相对于基线的可接受偏差）
   - 告警严重程度分级
   - 不同严重程度的响应流程和负责人

4. 周期性审计触发条件：
   - 基于时间：[每季度/半年自动触发]
   - 基于事件：[模型更新/用户群体显著变化/偏见投诉增加]
   - 基于指标：[代理指标偏离阈值时触发]

5. 投诉处理流程：
   - 用户如何举报感知到的偏见
   - 投诉分类和优先级标准
   - 调查流程和时间要求
   - 用户反馈和结果沟通

6. 治理报告：
   - 面向管理层的月度公平性健康报告模板
   - 面向监管机构的年度公平性报告结构
   - 公平性改进ROI追踪方法

输出：监控系统设计 + 告警配置 + 报告模板 + 投诉处理流程

4. AI LLM供应商能力对比矩阵

超越营销宣传，用真实业务场景的实测数据驱动模型供应商决策。

痛点与解决方案

痛点：供应商选择依赖宣传材料，而非真实业务场景数据

AI产品团队在选择LLM供应商时面临信息不对称困境：供应商提供的基准数据基于学术测试集，展示的是理想条件下的性能；而产品团队真正需要的是在自己特定使用场景下、真实用户查询分布上的性能数据。这两者之间的鸿沟往往在迁移到新供应商后才被发现，此时切换成本已经很高。

供应商能力在快速演变，但大多数团队的评估频率远跟不上这种演变速度。六个月前某供应商在代码生成上的劣势，可能已经被最新的模型版本填平；而曾经领先的供应商可能因为悄悄的模型更新而出现质量退化。没有持续的、标准化的对比评估机制，产品团队只能在问题暴露后才做出被动的供应商调整，而非主动优化。

多供应商架构的复杂性也是一个被低估的挑战。理想状态是对不同任务类型路由到最擅长的供应商，但这要求团队有能力在统一框架下评估和对比供应商，并且有工程基础设施支持灵活路由。大多数团队在这两方面都存在明显不足，结果是要么单一供应商依赖（错失优化机会），要么多供应商管理混乱（增加运营复杂度）。

COCO如何解决

1. 统一评估框架设计：COCO建立跨供应商可比的评估体系：

   • 设计业务场景驱动的评估任务集，覆盖产品的实际查询分布
   • 建立标准化的评估协议：相同输入、相同评分标准、相同运行次数
   • 设计盲测机制：评估者不知道输出来自哪个供应商
   • 创建统计显著性检验框架：区分真实性能差异与随机方差
   • 建立评估结果数据库，支持历史趋势分析和供应商变化追踪

2. 多维度能力矩阵构建：COCO超越单一质量维度的对比：

   • 任务质量：在各种任务类型上的输出质量评分
   • 推理能力：复杂多步骤推理的准确率
   • 知识深度：在特定领域的知识准确性和时效性
   • 指令遵循：对复杂、多条件提示词的遵守程度
   • 安全性：对有害请求的拒绝可靠性和错误拒绝率

3. 成本-性能权衡分析：COCO量化业务相关的经济指标：

   • 按实际查询分布计算的真实月度成本
   • 成本-质量效率比：每美元购买的质量单位
   • 延迟分布分析：p50/p95/p99与用户体验目标的关系
   • 批处理vs实时调用的成本差异
   • 价格锁定风险分析：供应商定价历史和变化趋势

4. 供应商可靠性评估：COCO评估运营层面的可靠性：

   • API稳定性历史：过去12个月的可用性记录
   • 限速策略分析：在高峰流量下的限速触发机制
   • SLA承诺对比：不同供应商的服务级别协议内容
   • 模型版本稳定性：供应商是否提前通知模型更新
   • 支持响应时间：技术问题的响应速度和解决质量

5. 战略风险与依赖评估：COCO分析长期战略风险：

   • 供应商依赖锁定风险：API设计的迁移难度
   • 数据隐私合规：各供应商的数据处理政策对比
   • 地缘政治风险：供应商的运营地理和监管环境
   • 竞争冲突风险：供应商是否与你的产品存在竞争关系
   • 开源替代路径：未来是否存在可行的开源迁移路径

6. 多供应商路由策略设计：COCO优化供应商组合：

   • 基于任务类型的路由逻辑设计
   • 主备供应商的故障切换策略
   • 成本优化路由：在质量约束下最小化成本
   • 供应商组合的A/B测试框架
   • 持续优化的路由权重调整机制

量化结果与受益角色

可量化的成果

• 供应商迁移决策质量：数据驱动的供应商评估使错误迁移决策减少50%，降低迁移后的质量投诉
• 成本优化：多供应商路由策略通常实现15-35%的推理成本降低，同等质量前提下
• 供应商谈判筹码：系统化的竞争对比数据使合同谈判中获得更优惠定价的概率提升40%
• 服务可用性：多供应商故障切换架构将AI功能可用性从99.9%提升至99.95-99.99%
• 性能监控覆盖：持续对比监测将供应商静默模型更新的检测时间从数周缩短至48小时

受益人群

• AI产品经理：用客观数据替代供应商宣传材料，做出有据可查的供应商决策
• 工程架构师：获得清晰的多供应商路由设计依据和故障切换规范
• 财务团队：获得准确的AI基础设施成本预测和优化路径
• 采购/法务团队：在合同谈判中有竞争对比数据支撑，降低单一供应商依赖风险

💡 实用提示词

提示词1 — LLM供应商能力矩阵构建

构建针对以下产品使用场景的LLM供应商能力对比矩阵。

产品使用场景：[详细描述主要任务类型]
候选供应商：[列出2-4个候选供应商及其主要模型]
评估预算：[计算成本上限]
决策时间：[需要做出决定的日期]

矩阵构建步骤：

1. 评估维度设计：
   质量维度（权重60%）：
   - 任务完成质量（主要任务类型的输出质量）
   - 推理准确性（复杂问题的解决准确率）
   - 知识准确性（领域知识的正确率）
   - 指令遵循度
   - 输出一致性

   性能维度（权重20%）：
   - 延迟p50/p95/p99
   - 上下文窗口大小
   - 并发处理能力

   成本维度（权重10%）：
   - 实际每查询成本（基于你的token分布）
   - 价格稳定性历史

   可靠性维度（权重10%）：
   - 历史可用性
   - SLA承诺质量
   - 模型版本稳定性

2. 测试集设计（针对每个维度）：
   [为质量评估设计50-100个代表性测试用例]
   [确保覆盖不同难度和子场景类型]

3. 评估执行计划：
   - 每个测试用例运行次数（建议3-5次）
   - 盲测机制实现
   - 评分方法（LLM-as-judge / 人工评估 / 自动化指标）

4. 矩阵可视化：
   [设计雷达图和表格格式，清晰展示各供应商优劣势]

5. 最终推荐：
   [主供应商推荐 + 理由 + 适合不同子场景的分供应商建议]

输出：能力对比矩阵 + 测试集 + 评分标准 + 推荐决策

提示词2 — 供应商迁移风险评估

评估从当前LLM供应商迁移到候选供应商的风险和成本。

当前供应商：[名称和使用的具体模型]
候选供应商：[名称和拟使用的具体模型]
当前集成情况：[描述API调用方式、使用的特有功能、token使用量]
评估结果：[当前测试中发现的质量差异]

迁移风险评估：

1. 技术兼容性风险：
   - API接口差异：[枚举两者API的主要差异点]
   - 功能差距：当前供应商提供但候选供应商不提供的功能
   - 提示词迁移：现有提示词在新供应商上的兼容性测试结果
   - 输出格式差异：结构化输出、工具调用等的格式变化

2. 质量退化风险（基于评估数据）：
   - 哪些任务类型质量提升？幅度？
   - 哪些任务类型质量下降？幅度？
   - 质量退化场景的用户影响范围（对应多少%的查询量）
   - 净质量影响：加权计算整体质量变化

3. 运营风险：
   - 迁移工程工作量估算（人天）
   - 迁移期间的服务中断风险
   - 员工学习新供应商API的成本
   - 新供应商的可靠性风险（相比已知的当前供应商）

4. 成本变化分析：
   - 月度推理成本变化（基于当前查询量）
   - 迁移一次性成本（工程+测试+培训）
   - 回收期：成本节省需要多久收回迁移投入

5. 迁移决策建议：
   立即迁移 / 分阶段迁移 / 暂不迁移 + 具体理由和条件

6. 如果决定迁移，分阶段计划：
   阶段1（第1-2周）：[内部测试，无用户流量]
   阶段2（第3-4周）：[5%流量灰度]
   阶段3（第5-8周）：[逐步扩大到100%]
   每阶段的成功标准和回滚触发条件

输出：迁移风险报告 + 成本分析 + 决策建议 + 分阶段迁移计划

提示词3 — 多供应商成本优化路由设计

设计多供应商路由策略，在质量约束下最小化推理成本。

当前状态：所有查询路由到[供应商A，成本$X/百万token]
可用替代供应商：
- [供应商B]：成本$Y/百万token，质量对比：[描述]
- [供应商C]：成本$Z/百万token，质量对比：[描述]

查询分布分析：
- 简单查询（单轮、事实性）：占[X]%，平均[n] tokens
- 中等复杂度查询：占[Y]%，平均[n] tokens
- 复杂推理查询：占[Z]%，平均[n] tokens

设计路由策略：

1. 查询复杂度分类器：
   - 分类维度：查询长度/关键词模式/用户账户级别/历史查询类型
   - 分类方法：规则引擎vs轻量级分类模型的权衡
   - 分类延迟预算：[最大可接受的额外延迟]

2. 路由规则设计：
   [简单查询] → [供应商B/C]：理由 + 质量验证
   [中等查询] → [供应商A/B混合]：路由逻辑
   [复杂查询] → [供应商A]：保持最高质量

3. 质量保障机制：
   - 对路由到低成本供应商的输出进行质量采样监控
   - 质量下降告警和自动路由调整
   - 用户账户级别的质量保障（高价值用户始终路由到最高质量）

4. 成本节省估算：
   [计算不同路由策略下的月度成本对比]
   推荐路由策略的年度节省：$[X]

5. 实施风险评估：
   - 工程实施复杂度
   - 维护成本（路由逻辑的持续维护工作量）
   - 用户体验一致性风险

输出：路由策略设计 + 成本节省分析 + 实施计划 + 监控方案

提示词4 — 供应商SLA与合同条款分析

分析并对比以下LLM供应商的SLA条款，识别合同风险。

候选供应商合同条款：[粘贴或描述主要合同条款和SLA内容]
产品可用性要求：[你的产品对AI功能可用性的要求]
数据隐私要求：[你的合规要求，如GDPR、行业特定法规]
预计使用量：[月度token量和并发请求峰值]

合同分析维度：

1. 可用性承诺分析：
   - 承诺的正常运行时间SLA：[X]%
   - 维护窗口和提前通知要求
   - 故障补偿机制（服务信用、赔偿上限）
   - 与你的产品可用性目标的差距

2. 数据隐私条款：
   - 用户数据是否用于模型训练？选择退出机制？
   - 数据存储位置和跨境传输规则
   - 数据保留和删除策略
   - 子处理商披露和责任链
   - GDPR/CCPA合规承诺的具体性

3. 使用限制和限速：
   - 每分钟/小时/月的请求限制
   - 超限后的行为（硬限制vs降速vs超量收费）
   - 企业级限速协商空间

4. 价格稳定性：
   - 价格保证期限
   - 价格变动提前通知要求
   - 批量折扣条款
   - 锁价合同选项

5. 知识产权条款：
   - 输出内容的所有权
   - 你用于微调的数据的所有权
   - 竞争限制条款

6. 退出条款：
   - 合同终止通知期
   - 数据导出和迁移支持
   - 终止后的数据删除时间表

关键风险识别：[标注最高风险的合同条款，建议谈判策略]

输出：SLA对比分析 + 关键风险矩阵 + 谈判优先级建议 + 合同条款改进建议

提示词5 — 供应商变更影响监测设计

设计LLM供应商静默模型更新的检测和响应系统。

背景：模型提供商有时会在不通知的情况下更新底层模型，
导致输出风格、质量或行为出现意外变化。

产品：[名称]
使用的供应商和模型：[列表]
已知的供应商更新历史：[描述是否有过静默更新经历]

设计检测系统：

1. 基线建立：
   - 设计"指纹查询集"：一组固定查询，其输出可以稳定反映模型特征
   - 建立基线输出库：当前模型版本的参考输出
   - 关键质量基线指标：[列出需要保持稳定的核心指标]

2. 定期探测方案：
   - 探测频率：每[X]小时/天运行指纹查询集
   - 变化检测方法：
     * 输出风格指纹（长度分布、词汇复杂度、结构模式）
     * 质量分数对比（与基线的统计偏差）
     * 特定行为探测（特定场景下的响应模式）

3. 告警阈值：
   - 轻微变化（风格偏移）：记录日志，发送周报摘要
   - 中等变化（质量指标偏移>10%）：触发调查，发送即时通知
   - 重大变化（质量指标偏移>25%或行为模式突变）：触发P1级响应

4. 变化确认流程：
   当检测到潜在变化时：
   - 步骤1：扩大探测查询集，验证变化的广泛性
   - 步骤2：区分质量变化方向（改善vs退化）
   - 步骤3：测试变化对不同任务类型的差异影响
   - 步骤4：联系供应商确认是否有模型更新

5. 响应策略：
   如果变化是质量退化：[回滚/切换备用供应商/提示词调整]
   如果变化是质量改善：[验证改善的一致性，更新基线，公告内部团队]

6. 供应商沟通模板：
   [设计通知供应商"我们检测到潜在模型变化"的邮件模板]

输出：检测系统设计 + 指纹查询集框架 + 告警配置 + 响应流程

5. AI推理成本优化分析器

系统化地找到在用户无感知的情况下降低30-50%推理成本的路径。

痛点与解决方案

痛点：AI推理成本在规模化时快速侵蚀利润率，威胁商业模式可持续性

AI产品的单位经济模型存在一个危险的陷阱：在用户规模较小时，推理成本可能看起来完全可控；但随着产品规模化，推理成本可能以超线性的方式增长，而用户付费意愿并不会同步提升。一个月费$30的AI产品，如果重度用户每月产生$25的推理成本，毛利率只有17%——远低于可持续SaaS业务所需的60-70%目标。

大多数AI产品团队对推理成本缺乏足够的颗粒度理解。他们知道总的月度API账单，但不清楚哪些功能、哪些用户群体、哪些查询类型产生了不成比例的成本。这种可见性缺失导致无法做出精准的优化决策——是优化提示词效率、引入模型路由、实现语义缓存，还是重新设计某个高成本功能？每种方案的投入产出比大相径庭，但在没有成本归因数据的情况下，只能凭直觉决策。

技术债同样是成本优化的障碍。早期为了快速迭代而采用的"一律调用最强模型"策略，随着产品复杂度的增加逐渐成为技术负担。但在没有系统化分析的情况下，"什么可以安全地切换到更便宜的模型"是一个让工程师望而却步的问题，优化计划因此一再被推迟。

COCO如何解决

1. 成本归因分析框架：COCO建立精细的成本可见性：

   • 设计按功能、用户群体和查询类型的成本分解报告
   • 建立"成本热图"：识别产生不成比例成本的功能区域
   • 创建用户级别的成本分析：区分成本驱动用户和一般用户
   • 设计单位经济模型：从每用户推理成本推导到毛利率预测
   • 建立成本趋势分析：识别成本增长是否超过用户增长

2. 优化策略优先级评估：COCO系统化评估优化选项：

   • 模型降级评估：哪些任务可以用更便宜的模型在质量无损的情况下完成
   • 语义缓存可行性分析：重复性查询的比例和缓存命中率预测
   • 提示词压缩机会识别：系统提示词和上下文的token效率优化空间
   • 批处理可行性分析：哪些场景下延迟要求允许请求批量处理
   • 流式响应优化：减少不必要的token生成

3. 模型路由成本优化设计：COCO设计节约成本的路由架构：

   • 建立查询复杂度分类：将查询按复杂度路由到成本匹配的模型
   • 设计级联调用策略：先调用便宜模型，质量不达标再升级
   • 创建用户层级路由：免费用户 vs 付费用户的差异化模型配置
   • 设计成本上限机制：防止单个用户或会话产生失控的成本
   • 建立成本-质量权衡实验框架

4. Prompt工程成本优化：COCO降低每次调用的token消耗：

   • 系统提示词瘦身分析：识别冗余指令和可以压缩的内容
   • 上下文管理优化：对话历史的智能截断和摘要策略
   • 结构化输出格式优化：JSON vs 自然语言输出的token效率对比
   • Few-shot示例优化：减少少样本示例的数量而不损失质量
   • 提示词缓存利用：利用模型提供商的提示词缓存功能

5. 缓存策略设计：COCO实现智能成本分摊：

   • 语义缓存架构设计：相似查询的向量相似度缓存
   • 缓存命中率预测：基于查询分布估算可能的缓存收益
   • 缓存新鲜度管理：不同类型内容的缓存有效期策略
   • 个性化与缓存的平衡：如何在保持个性化的同时最大化缓存利用率
   • 缓存基础设施选型：Redis、向量数据库等技术方案比较

6. 成本监控与预算管理：COCO建立成本控制机制：

   • 设计实时成本监控仪表板：按功能、用户、时间段的成本追踪
   • 建立成本异常告警：检测异常的成本峰值和趋势
   • 创建成本预算系统：设置成本上限和超限告警
   • 设计成本预测模型：基于用户增长预测未来的推理成本
   • 建立成本优化ROI追踪：量化每个优化措施的实际节省

量化结果与受益角色

可量化的成果

• 推理成本降低：系统化优化通常实现30-50%的推理成本降低，同等或更高质量前提下
• 毛利率改善：成本优化使AI产品毛利率从典型的30-50%提升至60-70%行业目标
• 成本预测准确性：精细化成本归因使预算预测误差从±50%降低至±15%
• 工程投资回报：平均成本优化项目在3-6个月内回收工程投入
• 用户体验影响：精心设计的成本优化在延迟和质量上对用户无感知

受益人群

• AI产品经理：获得成本可见性，将成本管理纳入日常产品决策
• CFO/财务团队：获得可靠的AI基础设施成本预测和优化路径
• ML工程师：明确知道哪些场景值得优先进行成本优化投资
• 创始人/投资人：改善单位经济模型，使AI产品达到可持续的盛利水平

💡 实用提示词

提示词1 — 推理成本归因分析

对以下AI产品进行全面的推理成本归因分析。

产品：[名称]
当前成本数据：
- 月度总推理成本：$[X]
- 使用的模型：[列出所有API调用的模型]
- 月活用户数：[MAU]
- 月均查询量：[次数]

按以下维度分解成本：

1. 功能级别成本分解：
   对于每个使用AI的功能：
   - 月度API调用次数
   - 平均输入/输出token数
   - 月度成本
   - 占总成本的百分比
   - 成本/价值比（是否产生对应的用户价值）

2. 用户群体成本分析：
   - 平均每用户月度成本（均值）
   - 重度用户（top 10%）的人均成本
   - 轻度用户（bottom 50%）的人均成本
   - 免费用户 vs 付费用户的成本对比（如果适用）
   - 识别成本异常用户的特征

3. 查询类型成本分析：
   - 按查询复杂度分类的成本分布
   - 识别高成本低价值的查询模式
   - 计算每类查询的成本/质量比

4. 成本异常检测：
   - 识别产生异常高成本的功能或使用模式
   - 是否存在API调用滥用或无效调用？
   - 上下文窗口是否被低效使用？

5. 优化机会矩阵：
   [成本影响 × 实施难度] 四象限分析
   优先解决：高影响低难度的优化机会
   长期规划：高影响高难度的优化机会
   快速清理：低影响低难度的优化机会
   暂不考虑：低影响高难度

输出：成本归因报告 + 优化机会矩阵 + 推荐优先级排序

提示词2 — 模型路由成本优化方案

设计基于查询类型的模型路由策略，在保证质量的前提下最大化成本效率。

当前状态：所有查询均使用[模型名称]，费率$[X]/1M tokens
可用替代模型：
- [模型A]：$[Y]/1M tokens，适用范围：[描述]
- [模型B]：$[Z]/1M tokens，适用范围：[描述]

查询分布（基于过去30天数据或估算）：
- 类型1 [简单/直接查询]：[X]%，平均[n] tokens/次
- 类型2 [中等复杂度]：[Y]%，平均[n] tokens/次
- 类型3 [复杂推理]：[Z]%，平均[n] tokens/次

设计路由优化方案：

1. 质量验证测试（路由前必须完成）：
   对于每个候选使用替代模型的查询类型：
   - 设计代表性测试集（[n]个查询）
   - 在两个模型上运行，对比质量得分
   - 统计显著性验证
   - 确认质量差异在可接受范围内

2. 路由规则设计：
   基于测试结果设计路由逻辑：
   [查询类型1] → 使用[模型A]（验证质量差异<[X]%）
   [查询类型2] → 使用[混合路由]（规则：[描述]）
   [查询类型3] → 保持使用[当前模型]

3. 成本节省估算：
   基于路由规则和查询分布：
   当前月度成本：$[X]
   路由优化后月度成本：$[Y]
   节省金额：$[Z]（[%]降低）

4. 实施计划：
   Week 1: 在内部测试流量上验证路由逻辑
   Week 2-3: 5%生产流量灰度测试
   Week 4: 全量推出

5. 质量监控方案：
   路由切换后持续监控：
   - 每个路由路径的质量指标
   - 用户反馈率变化
   - 如果质量指标下降超过[X]%，自动回滚

输出：路由设计方案 + 成本节省分析 + 实施计划 + 监控配置

提示词3 — Prompt瘦身优化

分析并优化以下提示词的token效率，在不降低质量的前提下减少token消耗。

当前系统提示词：[粘贴完整提示词]
当前提示词长度：[token数]
月度调用次数：[n]次
当前月度提示词成本：$[X]

进行token效率分析：

1. 冗余识别：
   逐段分析系统提示词：
   - 哪些指令重复表达了同一规则（合并机会）？
   - 哪些示例可以用更简洁的方式表达？
   - 哪些上下文信息可以通过模型的内在知识省略？
   - 哪些格式描述可以用简洁的标签替代详细说明？

2. 压缩技术应用：
   - 角色定义压缩：从3-4句话压缩到1-2句话的核心信息
   - 指令合并：将多条相关规则合并成一条综合规则
   - 示例精简：评估是否所有示例都必要，是否可以减少数量
   - 格式简化：用约定格式标签替代详细格式说明

3. 优化版本草案：
   [提供优化后的系统提示词，目标减少[X]%的token数]
   [标注每处修改和修改理由]

4. 质量风险评估：
   压缩后的提示词是否可能在以下方面产生退化？
   - 边缘案例处理
   - 特定格式遵守
   - 特殊拒绝场景
   建议的测试重点：[哪些查询类型最可能受到影响]

5. A/B测试方案：
   - 对比原版和压缩版在相同测试集上的质量差异
   - 成功标准：压缩版质量得分不低于原版的[X]%
   - 节省估算：通过测试后的月度token节省

6. 上下文管理优化建议：
   除系统提示词外，还有哪些其他优化机会？
   - 对话历史管理策略
   - 文档上下文的智能截断
   - 动态上下文注入而非静态包含

输出：提示词分析报告 + 优化版本 + 质量风险评估 + A/B测试方案 + 节省估算

提示词4 — 语义缓存可行性分析

评估为以下AI产品实施语义缓存的可行性和预期收益。

产品：[名称]
查询特征：[描述查询的特点，如是否有大量重复性查询]
当前基础设施：[已有的缓存基础设施]
查询量：[每日/月查询量]
推理成本：[每次查询的平均推理成本]

可行性分析：

1. 查询重复性分析：
   - 精确重复查询（完全相同）的比例估算
   - 语义相似查询（不同措辞，相似意图）的比例估算
   - 高度个性化查询（每次都不同）的比例估算
   - 结论：缓存的理论上限节省比例

2. 语义缓存技术选型：
   方案A：向量相似度缓存
   - 实现：将历史查询嵌入存储在向量数据库中，新查询与历史查询做相似度匹配
   - 相似度阈值设计：[X]分以上视为缓存命中
   - 优点：[列出]
   - 挑战：[列出]
   - 基础设施需求：[向量数据库选型和成本]

   方案B：模板化查询缓存
   - 实现：识别查询模板，对模板的变量部分进行参数化
   - 适用场景：查询结构高度规律化的产品

3. 缓存失效策略：
   - 知识更新时的缓存失效设计
   - 个性化内容的缓存排除规则
   - 缓存有效期设置（不同查询类型的差异化TTL）

4. 成本-收益分析：
   - 语义缓存实施成本（工程工作量 + 向量DB费用）
   - 预期缓存命中率：[X]%
   - 每月节省成本：$[Y]
   - 回收周期：[Z]个月

5. 实施风险：
   - 缓存命中质量风险（返回不够相关的历史回答）
   - 陈旧信息风险（缓存内容过时）
   - 用户体验一致性风险

6. 推荐方案：
   [基于分析给出是否实施的建议，以及实施路径]

输出：可行性分析报告 + 技术方案对比 + 成本收益计算 + 实施路径建议

提示词5 — AI成本单位经济模型

构建以下AI产品的推理成本单位经济模型，支持定价和融资决策。

产品：[名称]
商业模式：[订阅制/按用量收费/免费增值]
定价层次：[描述各定价层次]
用户行为数据：
- 免费用户人均月查询量：[n]
- 付费基础版用户人均月查询量：[n]
- 付费高级版用户人均月查询量：[n]
- 重度用户（top 10%）人均月查询量：[n]
- 平均输入token/查询：[n]
- 平均输出token/查询：[n]

模型：[使用的模型和每百万token价格]

构建单位经济模型：

1. 分用户层次的推理成本：
   免费用户：
   - 月度推理成本 = [查询量] × [token量] × [价格] = $[X]
   - 贡献利润率 = -$[X]（成本中心）
   
   付费基础版：
   - 月度推理成本 = $[Y]
   - 月度收入 = $[价格]
   - 贡献利润率 = $[价格] - $[Y] = $[Z] ([%])

   [重复所有层次]

2. 重度用户风险分析：
   - 重度用户（top 10%）产生的推理成本 vs 贡献的收入
   - 是否存在成本倒挂风险（某类用户的成本超过收入）
   - 如何通过使用限制或分级定价缓解风险

3. 规模化预测：
   在[X]个月达到[Y]个MAU的增长情景下：
   - 推理成本的月度趋势（是否有规模效益）
   - 整体毛利率趋势
   - 达到[目标毛利率]所需的用户规模或成本优化幅度

4. 优化杠杆分析：
   如果推理成本降低20%（通过路由优化等）：
   - 对毛利率的影响
   - 对盈亏平衡点的影响
   - 对定价策略的影响（是否可以降价获取竞争优势）

5. 投资者沟通建议：
   如何向投资者清晰展示AI成本单位经济：
   - 关键指标选择（推荐展示哪些指标）
   - 改进叙事框架

输出：单位经济模型 + 规模化预测 + 优化杠杆分析 + 投资者沟通建议

6. AI治理与风险框架构建器

将AI治理从合规负担转变为产品竞争优势，建立企业买家信赖的AI问责体系。

痛点与解决方案

痛点：AI治理被视为法律团队的问题，而非产品竞争力

大多数AI产品团队对治理的理解是消极的：治理是律师提出的要求，减慢产品发布速度，要求填写繁琐的文件。这种认知使得AI治理实践停留在最低合规水平——仅仅是为了满足要求，而非真正理解治理的业务价值。当企业采购商开始系统性地评估AI供应商的治理实践时，缺乏治理框架的产品在企业销售中处于明显劣势。

AI法规的快速演变加剧了这个问题。EU AI Act的落地、美国各州AI法规的陆续出台、行业特定监管（医疗、金融、教育）的加强，使AI治理要求从可选项变成了进入市场的门槛条件。没有系统化治理框架的AI产品，正在面临越来越高的监管不确定性——随时可能被要求提供无法快速组装的合规证据。

内部治理缺失还会导致AI质量问题的重复发生。没有记录的AI决策、没有追踪的模型变更、没有文档的偏见测试——当问题出现时，团队没有基准数据进行根因分析，也没有问责链条追溯决策责任。每次AI事件都变成"重新调查"，而非在已有治理记录基础上的快速响应。

COCO如何解决

1. AI治理架构设计：COCO建立适合团队规模的治理结构：

   • 设计AI治理角色和职责矩阵：谁对AI产品的不同风险类型负责
   • 建立AI风险分类框架：按潜在危害严重性分级不同AI使用场景
   • 创建AI决策审批流程：哪些AI功能需要哪个层级的审批
   • 设计AI治理委员会结构（适用于规模较大的团队）
   • 建立AI治理成熟度评估：从初级（被动合规）到高级（主动治理）的成长路径

2. 风险评估框架：COCO系统化识别和量化AI风险：

   • 建立AI风险全景图：技术风险、伦理风险、合规风险、声誉风险
   • 设计风险概率×影响矩阵：优先应对高概率高影响的风险
   • 创建风险缓解策略库：针对常见AI风险类型的标准缓解方案
   • 设计残余风险接受标准：哪些风险水平可以被接受，哪些必须消除
   • 建立定期风险重新评估机制：风险随产品和环境变化的动态管理

3. 政策与标准制定：COCO帮助建立AI治理文档体系：

   • 创建AI使用政策：产品中AI的允许用途和禁止用途
   • 设计AI数据治理标准：训练数据、生产数据的使用规范
   • 建立AI安全标准：最低安全测试要求和部署前检查清单
   • 创建AI透明度标准：对用户的必要披露要求
   • 设计AI供应商管理标准：模型提供商的选择和管理要求

4. 合规证据生成：COCO产出监管所需的文档：

   • 生成EU AI Act合规证据包（针对适用的高风险AI系统）
   • 创建NIST AI RMF对齐记录
   • 设计行业特定合规文档（HIPAA、金融、教育等）
   • 建立AI审计追踪系统：记录重要的AI决策和系统变更
   • 生成治理报告模板：用于内部报告和外部监管

5. 供应商AI治理尽职调查：COCO评估AI供应链风险：

   • 设计LLM供应商治理问卷：评估供应商的AI安全和伦理实践
   • 建立供应商AI风险评分：将治理因素纳入供应商选择决策
   • 创建合同AI条款模板：将AI治理要求写入供应商合同
   • 设计供应商变更通知要求：确保及时获知影响AI行为的变更
   • 建立供应商合规监控：持续追踪供应商的治理实践

6. AI治理文化建设：COCO推动治理融入日常工作：

   • 设计AI治理培训课程：不同角色的必修内容
   • 建立AI伦理审查清单：在功能开发过程中触发治理思考
   • 创建AI治理激励机制：认可和奖励良好的治理实践
   • 设计AI治理指标：将治理指标纳入团队绩效评估
   • 建立AI治理社区：内部知识共享和最佳实践传播

量化结果与受益角色

可量化的成果

• 企业销售周期：完善的AI治理文档将企业客户的尽职调查时间缩短30-50%
• 合规响应速度：预先建立的治理证据体系将监管询问的响应时间从数周缩短至数天
• 治理相关事件：主动治理框架将AI伦理事件频率降低50-70%
• 合同谈判效率：标准化的AI治理条款将合同谈判的来回次数减少40%
• 团队决策质量：明确的AI风险分级使团队在不确定情况下的决策速度提升2倍

受益人群

• AI产品经理：将AI治理从法务部门转交给产品团队主导，建立主动治理实践
• 法律合规团队：从被动应对转变为主动预防，减少紧急合规响应的压力
• 企业销售团队：用完善的治理文档降低企业客户的采购顾虑，加速大单成交
• 高管层/董事会：获得可靠的AI治理仪表板，履行监督职责并向监管机构证明负责任的AI实践

💡 实用提示词

提示词1 — AI治理框架设计

为以下AI产品设计一套适合当前团队规模的AI治理框架。

团队规模：[人数]
产品阶段：[早期/成长期/成熟期]
主要AI功能：[列出核心AI功能]
当前治理现状：[描述已有的治理实践]
主要风险关切：[高管/法务最关心的AI风险]

设计治理框架：

1. 治理结构（轻量级，适合当前规模）：
   AI决策责任矩阵（RACI）：
   - AI功能发布决策：R[负责] A[批准] C[咨询] I[知会]
   - AI事件响应：R A C I
   - AI合规文档：R A C I
   [根据产品类型设计完整的RACI矩阵]

2. AI风险分类系统：
   级别1 — 低风险：[定义标准，例如：纯内容建议，用户可完全控制最终决策]
   级别2 — 中等风险：[定义标准]
   级别3 — 高风险：[定义标准，例如：涉及重大决策支持，影响个人权益]
   
   对于每个风险级别：所需的审批层级 / 必须的测试要求 / 文档要求

3. AI功能发布检查清单（按风险级别）：
   低风险功能：
   [列出必须完成的检查项]
   
   高风险功能：
   [列出更严格的检查项，包括偏见测试、法律审查、高管审批]

4. 治理文档最小集合：
   对于这个阶段的团队，必须维护的最小文档集：
   - [文档类型 + 更新频率 + 负责人]

5. 治理成熟度路线图：
   当前阶段：[评估当前成熟度]
   6个月目标：[具体改进项]
   12个月目标：[具体改进项]

输出：AI治理框架 + RACI矩阵 + 风险分类标准 + 发布检查清单 + 成熟度路线图

提示词2 — AI风险全景评估

对以下AI产品进行全面的风险评估，建立风险管理优先级。

产品：[名称和功能描述]
部署范围：[用户群体、使用场景、地理区域]
数据处理情况：[处理哪些类型的数据]
AI决策影响：[AI输出如何影响用户或第三方]

风险评估维度：

1. 技术风险：
   R1 模型幻觉风险：[描述 | 概率:H/M/L | 影响:H/M/L | 当前缓解措施 | 残余风险]
   R2 系统可用性风险：[同上格式]
   R3 性能退化风险：
   R4 数据安全风险：
   [继续列出其他技术风险]

2. 伦理/偏见风险：
   E1 歧视性输出风险：
   E2 隐私侵犯风险：
   E3 信息操纵风险：
   [继续列出]

3. 合规/法律风险：
   C1 EU AI Act违规风险：
   C2 数据保护法违规风险：
   C3 行业特定法规风险：
   [继续列出]

4. 声誉风险：
   R1 公开AI失误事件：
   R2 用户信任损失：
   [继续列出]

5. 风险热图：
   [创建概率×影响矩阵，识别红色（立即应对）、黄色（近期应对）、绿色（监控）区域]

6. 优先风险缓解计划：
   Top 5高优先级风险：
   对于每个：[缓解措施 | 负责人 | 完成时间 | 成功标准]

输出：风险评估报告 + 风险热图 + 优先缓解计划 + 残余风险声明

提示词3 — AI政策文档生成

为以下AI产品生成核心治理政策文档。

产品：[名称]
业务模式：[B2B/B2C/B2B2C]
主要AI能力：[列出]
用户群体：[描述，包括是否有未成年人或弱势群体]
所在行业监管环境：[相关法规]

生成以下政策文档：

1. AI使用政策（面向用户）：
   - 产品中AI的用途说明（透明、易懂的语言）
   - 用户数据如何被AI使用
   - AI输出的局限性和用户责任
   - 用户如何报告AI问题
   - AI功能的退出选项
   [目标：300字内，清晰易读，无法律术语]

2. AI数据治理内部政策：
   - 训练数据来源和使用标准
   - 用户数据使用AI处理的规则
   - 数据最小化原则在AI功能中的执行
   - AI相关数据的保留和删除要求
   - 违规处理流程

3. AI安全测试标准：
   - 每个AI功能上线前必须通过的最低测试要求
   - 测试类型：功能测试/安全测试/偏见测试/压力测试
   - 测试文档要求
   - 测试结果的批准流程

4. AI事件响应政策：
   - AI事件的定义（什么构成需要响应的AI事件）
   - 严重性分级标准
   - 响应时间要求
   - 通知义务（用户通知、监管通知）
   - 事件后评审要求

输出：4份政策文档草案 + 版本控制建议 + 年度审查计划

提示词4 — EU AI Act合规路线图

为以下AI产品制定EU AI Act合规路线图。

产品：[名称]
当前EU用户比例：[%]
主要AI功能：[列出]
初步风险评估：[你对产品风险级别的初步判断]

EU AI Act合规分析：

1. 风险分类评估：
   根据EU AI Act附录，评估产品属于哪个风险类别：
   
   不可接受风险（第5条禁止清单）：
   - 检查产品是否涉及任何禁止性AI用途
   - 结论：[是否涉及，如涉及如何处理]
   
   高风险（附录III）：
   - 对照附录III清单逐一评估
   - 结论：[是否属于高风险，理由]
   
   有限风险：
   - 是否有生成合成内容、聊天机器人等需要透明度义务的功能
   - 结论：[适用的透明度义务]
   
   最小风险：
   - 其余功能的分类

2. 适用义务梳理（按确定的风险类别）：
   [列出所有适用的合规义务及其生效时间线]

3. 合规差距分析：
   对于每项适用义务：
   - 当前合规状态：[合规/部分合规/不合规]
   - 差距描述：[需要做什么]
   - 工作量估算：[人天]
   - 优先级：[基于生效时间和工作量]

4. 合规路线图（按时间排序）：
   立即行动（0-3个月）：[最紧迫的合规项]
   短期（3-6个月）：[中等优先级]
   中期（6-12个月）：[完善阶段]

5. 合规预算估算：
   [估算合规工作的总体资源需求]

输出：EU AI Act合规评估报告 + 差距分析 + 实施路线图 + 预算估算

提示词5 — AI治理董事会报告

为董事会/投资人准备AI治理状况报告。

公司阶段：[成立年数、融资轮次]
主要AI产品：[简述]
报告时间段：[季度/年度]
主要受众：[董事会成员背景——是否有AI/技术背景]

AI治理报告结构：

1. 执行摘要（1页）：
   - AI治理的战略重要性（2-3句话说明为什么治理是竞争优势）
   - 本期最重要的治理进展（3个要点）
   - 主要风险状态（交通灯格式）
   - 下一季度优先事项

2. AI风险仪表板：
   [设计董事会级别的风险可视化：哪些风险是绿色（受控）/黄色（监控）/红色（关注）]
   
   对于每个重要风险类别：
   - 风险描述（非技术语言）
   - 当前状态和趋势
   - 缓解措施摘要
   - 需要董事会关注的事项

3. 合规状态更新：
   - 主要适用法规的合规进度
   - 本期完成的合规里程碑
   - 下期计划完成的合规项
   - 已知的合规风险

4. AI治理投资：
   - 本期在AI治理上的投入（人力+系统）
   - 预期的风险缓解价值和业务回报
   - 下期治理投资计划和预算请求

5. 需要董事会决策的事项（如有）：
   [明确提出需要董事会层级批准的AI治理决策]

输出：董事会报告模板 + 风险仪表板设计 + 执行摘要框架

7. AI训练数据质量评估工具

在低质量数据毁掉模型性能之前，系统化地识别和修复训练数据中的问题。

痛点与解决方案

痛点：垃圾进垃圾出——数据质量问题是AI产品性能上限

"模型表现不好"的投诉有一半源于训练数据质量问题，而非模型架构的限制。这是AI产品团队最容易忽视的根因。当模型在特定领域表现不稳定、在边缘案例上频繁失败、或者在某些用户群体上表现显著更差时，直觉反应是"换个更好的模型"或"更多提示词工程"——而真正的问题往往是训练数据在这些场景上的质量不足或代表性偏差。

数据质量问题的形式多样且难以发现：标注不一致（不同标注者对同一案例有不同判断）、标注偏差（标注者将自己的偏见引入标注决策）、数据泄露（测试集与训练集存在重叠，导致评估结果虚高）、分布偏移（训练数据不代表生产环境中的查询分布）、标签噪声（错误的标注污染了训练信号）。这些问题中的任何一个，都会在模型性能上留下难以解释的"天花板"。

更复杂的是，训练数据质量问题的影响是非线性的。少量的高质量数据往往比大量的低质量数据更有价值；但识别数据质量问题需要专业的审计技能和工具，这些能力在大多数AI产品团队中明显不足。

COCO如何解决

1. 数据质量审计框架：COCO建立系统化的数据质量评估：

   • 设计数据质量多维评估：准确性、完整性、一致性、代表性、时效性
   • 建立标注一致性评估：计算标注员间一致性（Cohen's Kappa等指标）
   • 创建数据分布分析：对比训练数据与生产数据的分布差异
   • 设计数据泄露检测：识别训练/验证/测试集的交叉污染
   • 建立数据标签噪声检测：统计方法识别可能错误的标注

2. 标注质量管理体系：COCO提升人工标注的可靠性：

   • 设计标注指南质量评估：标注指南的清晰度和歧义性分析
   • 建立标注员校准机制：定期校准，保持标注一致性
   • 创建标注质量抽检流程：对标注结果的随机质量抽查
   • 设计难例（hard case）识别：自动标注员间分歧大的案例
   • 建立标注员差异分析：识别系统性偏差的标注员

3. 数据代表性评估：COCO确保数据覆盖生产场景：

   • 建立查询分布对比分析：训练数据 vs 生产流量的覆盖差距
   • 设计子群体覆盖评估：不同用户群体、使用场景的数据覆盖率
   • 创建长尾场景识别：重要但低频的使用场景是否有足够数据
   • 设计对抗性案例覆盖：难例、边缘案例的系统性收集
   • 建立数据采集策略：针对识别的覆盖缺口设计数据采集计划

4. 数据清洗与质量改进：COCO修复发现的数据问题：

   • 设计重复数据识别和去重策略
   • 建立损坏数据检测和处理流程
   • 创建标签修正优先级：哪些错误标注对模型影响最大
   • 设计数据增强策略：低覆盖区域的合成数据生成
   • 建立数据版本管理：追踪数据清洗历史，支持可复现性

5. 数据质量监控：COCO建立持续的数据健康追踪：

   • 设计持续数据漂移监测：生产数据分布的定期对比
   • 建立新数据质量门控：新采集数据进入训练集前的质量检查
   • 创建数据质量仪表板：关键数据质量指标的可视化
   • 设计数据质量告警：当质量指标异常下降时触发通知
   • 建立周期性数据审计计划：定期的全面数据质量回顾

6. 数据治理与合规：COCO确保数据使用的合规性：

   • 建立数据来源追踪（数据溯源）
   • 设计许可证合规检查：确保所有数据的使用符合授权条款
   • 创建隐私合规审查：识别训练数据中的个人信息
   • 建立数据保留策略：符合法规要求的数据生命周期管理
   • 设计数据删除机制：满足用户删除请求的数据清理流程

量化结果与受益角色

可量化的成果

• 模型性能提升：系统化数据质量改善通常带来10-20%的任务完成率提升，等同于从更大模型获得的收益
• 标注成本效率：通过提前识别低质量标注，节省30-40%的重复标注成本
• 数据泄露预防：测试集污染检测防止虚假的模型评估结果，避免基于错误置信度的产品决策
• 标注一致性提升：标注员校准计划将Kappa一致性从典型的0.6-0.7提升至0.85+
• 覆盖缺口填补：定向数据采集将关键场景的训练覆盖率从50%提升至90%+

受益人群

• AI产品经理：了解模型性能上限的真正来源，做出更准确的改进投资决策
• ML工程师：获得可操作的数据质量问题清单，而非在数据准备和模型调优间盲目切换
• 数据标注团队：通过明确的质量标准和反馈机制提升标注质量和工作满意度
• 产品设计师：理解哪些用户场景的AI质量因数据不足而受限，避免设计超出AI能力的UX

💡 实用提示词

提示词1 — 训练数据质量审计设计

设计针对以下AI模型训练数据的质量审计方案。

模型类型：[分类器/序列到序列/问答系统/其他]
数据规模：[训练集/验证集/测试集的数据量]
标注方式：[人工标注/自动标注/混合]
当前模型性能问题：[描述观察到的性能问题，如某类别准确率低/特定场景失败率高]

设计审计方案：

1. 数据质量维度评估清单：

准确性评估：
- [ ] 随机抽样[X]%数据进行人工复核
- [ ] 计算标注错误率
- [ ] 识别系统性错误模式（特定类型案例的高错误率）

完整性评估：
- [ ] 缺失值检查（关键字段的缺失比例）
- [ ] 训练集/验证集/测试集的大小是否满足统计要求
- [ ] 类别分布是否严重不平衡

一致性评估：
- [ ] 标注员间一致性（Cohen's Kappa 或 Fleiss' Kappa）
- [ ] 同一标注员在不同时间对相同案例的一致性
- [ ] 标注指南歧义性分析

代表性评估：
- [ ] 训练数据分布 vs 生产查询分布对比
- [ ] 关键子群体（用户类型/领域/查询类型）的覆盖率
- [ ] 长尾场景的样本量是否足够

2. 数据泄露检测：
- 训练集与测试集的直接重复检测
- 近似重复检测（语义相似度>0.95的案例）
- 数据预处理步骤是否在split之前进行

3. 优先级评分：
对于每个发现的问题：影响程度（对模型性能的预期影响）× 修复难度（反向）
→ 优先修复评分

4. 报告格式：
[设计审计报告的结构，包含数据概况/问题清单/优先级/修复建议]

输出：数据审计方案 + 执行清单 + 报告模板

提示词2 — 标注质量控制体系设计

为以下数据标注项目设计质量控制体系。

标注任务描述：[描述标注任务的类型和目标]
标注团队规模：[内部标注员 vs 外包标注员 vs 众包]
当前质量问题：[描述已知的标注质量问题]
质量目标：[目标的标注员间一致性Kappa值或准确率]

设计质量控制体系：

1. 标注指南改进：
   当前指南的常见歧义点：[分析已知问题]
   改进建议：
   - 增加具体示例（每个类别至少3个正例和3个负例）
   - 添加判断树（当案例落在边界时，如何决策）
   - 明确难例处理原则（是否有"不确定"类别）

2. 标注员校准流程：
   校准集设计：[多少个案例，如何选择有代表性的难例]
   校准会议流程：
   - 频率：[每周/每两周]
   - 时长：[X]小时
   - 内容：[讨论分歧案例，更新指南]
   
   校准追踪：
   - 每位标注员与黄金标准的一致性追踪
   - 触发额外培训的阈值（Kappa < [X]）

3. 实时质量监控：
   抽检策略：
   - 抽检比例：[X]%（新标注员前期50%，熟练后10-20%）
   - 抽检结果反馈给标注员的时间SLA：[X]小时内
   - 不合格率触发暂停标注的阈值：[X]%

4. 难例管理：
   难例识别标准：[什么情况下一个案例被标记为难例]
   难例处理流程：[由谁审核，审核标准，如何更新指南]
   难例库维护：[积累难例作为培训素材]

5. 质量报告：
   每周质量指标：
   - 总体准确率
   - 各类别准确率
   - 标注员间一致性
   - 难例比例
   - 需要关注的标注员（准确率低于阈值）

输出：质量控制体系设计 + 标注指南改进建议 + 校准计划 + 监控报告模板

提示词3 — 数据分布对比分析

分析训练数据与生产数据的分布差异，识别模型性能受限的数据根因。

产品：[名称]
分析维度：[按什么维度对比分布，如查询类型/长度/领域/用户群体]

训练数据分布：
[描述或提供训练数据的分布统计]

生产数据样本（过去30天）：
[描述或提供生产查询的分布统计]

分布对比分析：

1. 分布差异量化：
   对每个分析维度：
   - 训练数据分布 vs 生产数据分布（用百分比表示）
   - KL散度或Jensen-Shannon散度（衡量分布差异程度）
   - 哪些类别/场景在训练数据中严重不足（<生产分布的50%）
   - 哪些类别/场景在训练数据中过度代表（>生产分布的200%）

2. 性能影响评估：
   对于分布最不匹配的场景：
   - 在这些场景上的当前模型性能是什么？
   - 是否有证据支持"覆盖不足→性能差"的假设？
   - 这些场景在生产中的占比（影响用户数量）

3. 优先填补的分布缺口：
   按（生产覆盖率 × 性能缺口严重度）排序，识别最需要补充数据的场景

4. 数据采集策略：
   对于优先级最高的缺口：
   - 目标采集数量（达到统计意义所需的最少样本）
   - 采集渠道（生产日志抽样/主动收集/数据增强）
   - 采集时间线和资源需求

5. 监控机制：
   如何持续追踪训练数据与生产数据的分布对齐情况？
   - 监控频率
   - 触发数据补充采集的阈值
   - 报告格式

输出：分布差异分析报告 + 缺口优先级矩阵 + 数据采集计划 + 持续监控方案

提示词4 — 数据增强策略设计

为以下低覆盖场景设计数据增强策略，以改善模型在这些场景的性能。

模型：[类型和任务]
低覆盖场景：[描述数据不足的具体场景或类别]
现有数据量：[当前各场景的样本量]
目标数据量：[希望达到的样本量]

设计数据增强方案：

1. 数据增强方法评估（按适用性排序）：

方法A — 生产日志采样：
- 从生产流量中定向采集这类场景的真实案例
- 优点：最真实的数据分布
- 挑战：标注成本，需要用户同意
- 预期获取量：[每周/月]

方法B — LLM辅助数据生成：
- 使用强大的LLM生成符合要求的合成训练数据
- 生成提示词模板：[设计用于生成高质量合成数据的提示词]
- 质量控制：生成数据的人工审查比例
- 风险：合成数据可能放大模型偏差

方法C — 数据变换增强：
- 同义替换
- 回译（翻译成另一种语言再翻译回来）
- 轻微改写
- 适用性：[这种方法对你的任务是否适用]

方法D — 主动学习（针对已部署模型）：
- 识别模型置信度低的生产样本
- 优先对这些样本进行人工标注
- 最高效的标注资源分配方式

2. 推荐方案组合：
[根据上述分析，推荐最适合这个场景的组合方法]

3. 数据质量验证：
增强数据进入训练集前的质量检查：
- 自动质量过滤条件
- 人工审查比例
- 通过标准

4. 效果预测：
基于数据增强，预期：
- 覆盖场景的样本量增加：从[X]到[Y]
- 模型在这些场景的性能改善估算：+[X]%

输出：数据增强策略 + 实施计划 + 质量验证标准 + 效果追踪方案

提示词5 — 数据版本控制与可复现性方案

设计AI训练数据的版本控制和实验可复现性方案。

背景：目前训练数据没有版本控制，无法追溯哪个模型版本使用了哪些数据训练

团队规模：[数据科学家+ML工程师人数]
数据规模：[总数据量]
模型训练频率：[每周/每月训练几次]
当前工具栈：[使用的ML工具和云平台]

设计方案：

1. 数据版本控制架构：
   推荐工具选型：[DVC / Delta Lake / LakeFS / 自建 - 根据团队规模和成本]
   
   数据版本管理内容：
   - 训练集/验证集/测试集的不可变快照
   - 数据采集来源和预处理脚本
   - 数据质量报告（每个版本的质量指标）
   - 数据使用记录（哪些模型版本使用了哪个数据版本）

2. 实验可复现性要求：
   每次模型训练必须记录：
   - 数据版本号
   - 预处理流程版本
   - 模型代码提交哈希
   - 超参数设置
   - 评估结果
   → 确保任何历史实验可以100%重现

3. 数据变更管理：
   数据更新工作流：
   - 新数据进入 → 质量检查 → 创建新数据版本 → 文档更新
   - 数据删除（响应用户请求）→ 追踪影响的训练版本 → 必要时重新训练
   - 标注错误修复 → 版本更新 → 评估对模型的影响

4. 审计追踪：
   能够回答的问题：
   - "我们使用了包含这条数据的模型版本吗？"
   - "为什么这个模型版本在这类场景表现下降？"
   - "我们是否使用了用户未同意的数据训练模型？"

5. 实施计划：
   Week 1-2: 历史数据快照（当前状态的版本0）
   Week 3-4: 版本控制工具集成
   Month 2: 团队培训和流程固化

输出：数据版本控制方案 + 工具选型建议 + 实施计划 + 审计追踪能力清单

8. AI微调ROI规划器

在承诺微调投资之前，用严格的经济分析证明其商业价值。

痛点与解决方案

痛点：微调决策缺乏经济分析支撑，常常是过度或不足投资

"我们应该微调模型吗？"是AI产品经理面临的最常见但最难回答的问题之一。技术团队往往给出的答案基于工程兴趣（"微调会让模型表现更好"）或保守主义（"提示词工程已经够了"），而非系统化的成本效益分析。结果是：一些团队在可以通过提示词工程解决的问题上花费大量资源进行微调；另一些团队在微调能够带来显著ROI的场景上迟迟不行动。

微调投资的真实成本常常被低估。数据准备（采集、清洗、标注）通常占据微调项目70-80%的时间和成本，远超计算成本本身。维护成本同样被忽视：每次基础模型更新后，微调模型可能需要重新训练；而如果数据分布随时间变化，微调模型的性能会随之退化，需要周期性的数据补充和重新微调。这些持续性成本使得许多表面看起来合理的微调投资，在全生命周期视角下并不划算。

另一方面，某些场景确实需要微调才能达到可接受的质量水平——特别是高度领域特定的任务、需要一致输出风格的场景、或者延迟和成本要求迫使必须使用小模型的场景。在这些场景上，通过提示词工程勉强维持低质量，实际上比微调的成本更高（因为低质量带来的用户流失和支持成本）。

COCO如何解决

1. 微调必要性评估框架：COCO系统化判断微调是否必要：

   • 设计"微调前检查清单"：在考虑微调之前，必须证明提示词工程和RAG的潜力已充分挖掘
   • 建立场景适用性评估：哪些特征使某个场景更可能从微调中受益
   • 创建质量缺口分析：量化当前方案的质量缺口与微调预期能弥补的差距
   • 设计快速原型验证：在大规模投资前用小规模实验验证微调的可行性
   • 建立替代方案全面比较：微调 vs RAG vs 更好的提示词工程 vs 更强的基础模型

2. 微调成本全景分析：COCO量化微调的真实总成本：

   • 数据成本建模：采集、标注、质量控制的完整成本
   • 计算成本估算：训练运行的计算成本（不同规模模型和数据量）
   • 工程成本分析：数据管道、训练基础设施、评估框架的建设成本
   • 维护成本预测：定期重新训练、数据更新、性能监控的持续成本
   • 机会成本评估：同等工程资源投入其他优化方向的预期回报对比

3. 微调收益量化方法：COCO将质量改善转化为业务价值：

   • 设计质量改善-用户满意度转化模型
   • 建立用户满意度-留存率关系分析
   • 创建留存率改善-收入影响计算
   • 设计成本节省分析：微调小模型替换大模型的推理成本节省
   • 建立竞争差异化价值评估：微调带来的难以复制的竞争优势

4. 微调方法选择框架：COCO优化微调技术选型：

   • 评估全量微调 vs LoRA/QLoRA vs 适配器的技术适用性
   • 设计微调数据量需求分析：达到质量目标所需的最少标注数据量
   • 建立基础模型选择标准：选择最适合微调的基础模型
   • 创建微调目标设计：指令微调 vs RLHF vs DPO的场景适用性
   • 设计评估框架：如何测量微调是否达到预期质量改善

5. 微调项目规划工具：COCO支持微调项目的系统化管理：

   • 设计微调项目章程模板：包含目标、成功标准、资源需求、时间线
   • 建立里程碑和门控标准：数据准备完成→原型训练→性能验证→全量训练→上线
   • 创建风险识别和缓解清单：微调项目的常见失败模式
   • 设计快速失败机制：在哪个阶段如果未达到质量目标应停止投资
   • 建立微调项目后评估：交付后追踪实际ROI与预期ROI的偏差

6. 微调知识管理：COCO积累微调经验：

   • 建立微调实验记录库：成功和失败的实验详细记录
   • 设计数据配方归档：哪些数据组合产生了最好的效果
   • 创建超参数最佳实践库：不同任务类型的推荐超参数范围
   • 建立微调质量追踪：微调模型的长期性能趋势监控
   • 设计内部微调能力评估：团队在微调技术上的能力成熟度

量化结果与受益角色

可量化的成果

• 投资决策准确率：ROI框架使微调投资决策的准确率提升60%（减少不必要投资和错过的必要投资）
• 成本可见性：全面成本分析使微调项目预算准确度从±100%提升至±25%
• 项目成功率：有明确成功标准和快速失败机制的微调项目，按时交付且达到质量目标的比例提升40%
• 推理成本优化：通过微调小模型替换大模型，实现等质量下30-60%的推理成本降低
• 维护成本意识：全生命周期成本分析使团队提前规划维护资源，减少后期的意外成本超支

受益人群

• AI产品经理：用经济分析框架为微调投资建立业务案例，而非被工程师的技术热情或保守主义驱动
• ML工程师：获得清晰的成功标准和快速失败机制，在错误方向上的投入减少
• CFO/财务团队：对AI研发投资的ROI有更准确的预期，支持更好的资源分配决策
• 创始人/CEO：在竞争优势分析中清晰理解微调能力的战略价值

💡 实用提示词

提示词1 — 微调必要性评估

系统化评估为以下AI功能进行微调的必要性。

功能描述：[详细描述需要改进的AI功能]
当前质量问题：[描述具体的质量缺口]
已尝试的优化措施：[描述已经尝试过的提示词工程、RAG等方法]
当前使用的模型：[基础模型]
质量目标：[需要达到的具体质量指标]

必要性评估框架：

1. 提示词工程潜力是否已充分挖掘？
   评估维度：
   - 是否尝试过思维链提示词（Chain-of-Thought）？效果如何？
   - 是否尝试过少样本示例（Few-shot）？给了多少个示例？
   - 是否尝试过角色定义和任务分解？
   - 是否进行过系统性的提示词A/B测试？
   结论：提示词工程的预期改进上限是多少？

2. RAG的适用性评估：
   - 这个问题是否主要是知识不足（vs 推理能力不足）？
   - 添加相关知识库后质量改善的潜力有多大？
   - RAG的实施成本 vs 微调成本对比？

3. 更强基础模型的适用性：
   - 升级到更强基础模型（如GPT-4o → o1）能解决问题吗？
   - 成本影响可接受吗？

4. 微调的真正必要条件（以下任一条件成立则微调可能必要）：
   - 需要领域特定的专有知识，无法通过RAG引入
   - 需要一致的输出风格/格式，提示词控制不够稳定
   - 延迟/成本要求必须使用小模型，而小模型不用微调质量不足
   - 上述替代方案均已验证不足以达到质量目标

5. 评估结论：
   推荐方案：[微调 / 增强提示词工程 / 添加RAG / 升级基础模型 / 组合方案]
   理由：[基于以上评估的具体推荐理由]

输出：必要性评估报告 + 替代方案比较 + 推荐决策

提示词2 — 微调成本建模

建立以下微调项目的全面成本模型。

项目背景：
- 任务类型：[描述微调目标任务]
- 目标模型规模：[基础模型大小，如7B/13B/70B参数]
- 数据规模估算：[需要多少标注样本]
- 团队组成：[参与的工程师数量和级别]

建立成本模型：

1. 数据成本（通常占70-80%）：
   数据采集成本：
   - 从生产环境采集：[时间成本估算]
   - 主动数据收集：[每个样本的采集成本 × 数量]
   
   数据标注成本：
   - 内部标注：[工程师/标注员时间 × 每小时成本 × 每样本时间]
   - 外包标注：[每样本价格 × 数量]
   - 质量控制（抽检+校准）：[额外成本比例，通常20-30%]
   
   数据管道开发：
   - 数据预处理脚本：[工程工作量估算]
   - 数据质量检查系统：[工程工作量估算]

2. 计算成本：
   试验性训练（调参阶段）：
   - 预计运行次数：[X]次
   - 每次运行的GPU小时数：[估算]
   - GPU成本：每小时$[X]
   
   正式训练：
   - 完整训练运行次数：[X]
   - 每次运行成本：$[X]
   
   总计算成本：$[X]

3. 工程成本：
   - 微调基础设施搭建：[工程师工作周]
   - 评估框架搭建：[工作周]
   - 部署和集成：[工作周]
   总工程成本：[工作周] × [周均成本] = $[X]

4. 维护成本（年化）：
   - 定期重新训练（每[X]个月）：[$Y/次 × 次数]
   - 数据更新：[年度数据采集/标注成本]
   - 监控和维护：[工程师时间]
   年化维护成本：$[X]

5. 总成本汇总（3年视角）：
   一次性成本：$[X]
   年化运营成本：$[Y]
   3年总成本：$[Z]

6. 与替代方案的成本对比：
   微调路径3年成本：$[X]
   使用更强API模型路径3年成本：$[Y]
   差异：$[Z]

输出：详细成本模型 + 成本分解表 + 替代方案对比 + 盈亏平衡分析

提示词3 — 微调收益量化

量化以下微调项目的预期商业收益，建立ROI分析。

微调目标：[描述微调后预期改善的具体质量指标]
预期质量改善：[基于小规模实验或行业基准的质量提升预测]
产品商业模式：[订阅制/按用量/免费增值，以及各层次的定价]
用户数据：[MAU，付费用户比例，平均留存周期，平均收入]

量化收益：

1. 用户满意度改善价值：
   假设：质量改善[X]%对应满意度提升[Y]点（基于你的历史数据或行业基准）
   → 满意度提升[Y]点对应留存率改善[Z]%（基于你的留存-满意度相关分析）
   → 留存率改善[Z]%对应年度收入影响：
   $[当前MAU] × [付费转化率] × [年均ARPU] × [Z]% = $[收入增量]

2. 推理成本节省价值（如果微调目标是用小模型替换大模型）：
   当前使用[大模型]的月度成本：$[X]
   微调后使用[小模型]的月度成本：$[Y]
   年度节省：$[(X-Y) × 12]

3. 竞争差异化价值（定性转定量）：
   - 如果质量提升使竞争比较胜率从[X]%提升至[Y]%
   - 对应的年度新增企业合同价值估算：$[Z]

4. 支持成本降低：
   当前AI质量问题导致的支持工单比例：[X]%
   每个工单的平均处理成本：$[Y]
   微调后预期工单减少：[Z]%
   年度节省：$[X × Y × Z × 月均工单量 × 12]

5. ROI汇总：
   总3年收益估算（保守/基础/乐观）：$[X] / $[Y] / $[Z]
   总3年成本：$[W]（来自成本模型）
   3年ROI = (收益 - 成本) / 成本 × 100%
   盈亏平衡时间：[X]个月

6. 投资建议：
   [基于ROI分析的明确建议：投资/不投资/条件性投资]
   [关键假设和敏感性分析：哪个假设对ROI影响最大]

输出：收益量化分析 + ROI模型 + 敏感性分析 + 投资建议

提示词4 — 微调数据需求规划

规划以下微调项目的数据采集需求。

微调任务：[具体描述]
质量目标：[需要在什么测试集上达到什么指标]
当前已有数据：[描述已有的标注数据情况]
目标模型：[拟微调的基础模型]

数据需求规划：

1. 数据量估算：
   基于以下因素估算所需标注样本量：
   - 任务复杂度（简单分类 vs 复杂生成任务）
   - 基础模型大小（大模型通常需要更少数据）
   - 质量目标（越高的质量目标通常需要更多数据）
   - 行业经验基准：[对于这类任务，典型的起点数据量是多少]
   
   最低可行数据量：[X]条
   推荐数据量：[Y]条
   数据量的边际收益递减点：大约[Z]条之后

2. 数据质量要求：
   - 标注一致性要求：Kappa > [X]
   - 覆盖率要求：所有重要子场景至少[n]个样本
   - 难例比例：[X]%难例（在边界上的案例）
   - 格式要求：[输入/输出格式规范]

3. 数据集分割：
   训练集：[X]%
   验证集：[Y]%（用于超参调整）
   测试集：[Z]%（保持不变，作为最终评估的黄金集）
   注意：分割必须在标注前完成，避免数据泄露

4. 数据采集计划：
   来源1 — 生产日志采样：
   - 采集标准：[什么样的生产案例适合采集]
   - 预期获取量：[每周]
   - 隐私处理：[如何脱敏]
   
   来源2 — 主动构造：
   - 哪些场景在生产数据中自然不足，需要主动构造
   - 构造方法：[模板生成/LLM辅助生成/专家构造]

5. 采集时间线：
   [周1-2]：建立数据采集管道
   [周3-8]：批量数据采集
   [周9-10]：数据清洗和质量检查
   [周11]：数据集冻结，开始训练

输出：数据需求规划报告 + 分割方案 + 采集计划 + 时间线

提示词5 — 微调实验设计

设计以下微调项目的实验方案，快速验证可行性并确定最优配置。

任务：[微调目标任务]
已有数据：[当前可用的标注数据量]
计算预算：[用于实验的GPU小时数上限]
时间约束：[需要在多少天内得到实验结论]

设计实验方案：

1. 快速可行性验证实验（第1-2周，低成本）：
   目标：用最少资源验证微调是否能显著改善质量
   
   配置：
   - 使用小规模数据（[X]个样本，按比例代表完整数据集的分布）
   - 使用较小的基础模型进行快速实验
   - 微调轮数：少量（3-5轮）
   
   评估：
   - 在固定评估集上对比基础模型 vs 微调模型
   - 关键指标改善是否超过[X]%的最低门槛？
   
   决策：如果未超过门槛 → 停止微调投资；如果超过 → 进入参数调优

2. 超参数搜索实验（第3-4周，中等成本）：
   调优维度：
   - 学习率：[测试范围]
   - 批次大小：[测试值]
   - 训练轮数：[测试范围]
   - LoRA rank（如使用LoRA）：[测试值]
   
   实验矩阵：[设计高效的超参数搜索策略，如贝叶斯优化]
   每次实验成本：$[X]，总预算：$[Y]，最大实验次数：[n]

3. 数据量消融实验（并行或第5周）：
   目标：确定数据量与质量改善的关系曲线
   实验设计：用[20%/40%/60%/80%/100%]的数据分别训练，对比评估结果
   → 识别质量边际收益递减点

4. 最优配置确认训练（第6-8周）：
   使用超参数搜索找到的最优配置
   使用完整训练数据集
   完整评估（包括子群体表现分析）

5. 实验记录要求：
   每次实验必须记录：[训练数据版本/超参数/评估结果/计算成本]
   → 支持完整的实验可复现性

6. 实验结论决策框架：
   如果最终模型在评估集上达到[目标指标]：进入生产部署
   如果达到[中间水平]：评估是否需要更多数据
   如果未达到[最低门槛]：评估重新设计方案

输出：实验方案 + 实验矩阵 + 计算成本估算 + 决策框架

9. AI功能优先级评分引擎

用数据驱动的优先级评分系统，让最有影响力的AI功能以最快速度到达用户手中。

痛点与解决方案

痛点：AI功能积压过大，缺乏科学的排序方法

AI产品功能积压往往无序增长：来自用户的功能请求、销售团队的客户需求、工程师的技术想法、高管的战略方向——每一项都有其倡导者，都声称是"最重要的"。没有系统化评分机制的情况下，产品经理往往陷入"声音大的赢"或"最近接触谁就做谁的事"的决策陷阱，而非基于价值最大化原则。

AI功能的评估特别复杂，因为需要同时评估用户价值和技术可行性两个维度。一个用户极度渴望的功能，可能在当前AI技术条件下质量无法达到可接受水平；而一个技术上容易实现的AI功能，可能对用户来说影响微乎其微。传统的产品优先级框架（RICE、MoSCoW等）没有针对AI可行性的专门维度，导致团队要么忽视可行性风险（事后发现无法达到质量目标），要么过度保守（放弃了可行但被低估的功能）。

跨职能对齐的缺失使问题更加复杂。产品团队、工程团队和业务团队对"重要"的定义不同，在没有共同评分框架的情况下，路线图优先级讨论往往变成各方观点的碰撞，而非结构化的数据驱动分析。

COCO如何解决

1. AI功能专用评分框架：COCO设计适合AI产品的评分模型：

   • 建立六维评分体系：用户影响×业务战略价值×AI技术可行性×实施努力（反向）×证据质量×时机紧迫性
   • 设计AI可行性评估维度：当前AI技术能否以足够质量实现此功能
   • 创建证据质量权重：有用户研究支持的功能得分高于基于直觉的功能
   • 建立战略一致性系数：确保路线图支持当前季度/年度的战略重点
   • 设计时机评估：竞争时机、技术成熟度、用户准备度

2. 批量评分工作流：COCO支持快速、高效的功能积压清理：

   • 设计功能描述标准格式：确保所有功能按相同维度描述，支持公平比较
   • 建立评分校准会议：确保跨职能团队对评分标准的理解一致
   • 创建快速初筛流程：通过2-3个关键问题将功能分成"值得详细评估"和"明显不适合当期"
   • 设计批量评分模板：允许产品经理高效地评分和比较大量功能
   • 建立评分复核机制：避免系统性偏差（如总是高估用户价值）

3. 依赖关系管理：COCO处理AI功能之间的技术依赖：

   • 识别基础能力与上层功能的依赖关系图
   • 评估"阻塞器"功能：必须先完成才能开始其他功能的基础工作
   • 设计依赖调整后的有效优先级：考虑依赖关系的最优执行序列
   • 识别并行机会：可以同时进行的非依赖功能组合
   • 建立技术债的优先级考量：技术债对未来功能交付速度的影响

4. 利益相关方透明度机制：COCO建立清晰的决策可见性：

   • 设计功能优先级可视化：所有利益相关方可以看到排序和理由
   • 建立优先级决策记录：每个功能的排序理由和关键假设
   • 创建利益相关方异议处理流程：如何正式提出优先级挑战
   • 设计优先级变更通知机制：当优先级调整时，自动通知相关方
   • 建立季度优先级审视：定期重新评估积压中功能的优先级

5. 预期值vs实际结果追踪：COCO持续改进评分准确性：

   • 记录每个功能发布前的预期评分和发布后的实际结果
   • 建立评分准确度追踪：哪些评分维度的预测最不准确
   • 分析系统性偏差：团队是否系统性高估/低估某类功能
   • 设计校正机制：基于历史准确度调整评分权重
   • 建立功能评分后评估：深入分析高/低偏差案例的学习

6. AI功能组合优化：COCO优化功能组合的整体效果：

   • 评估功能组合的协同效应：哪些功能配合使用效果更好
   • 设计功能集群分析：哪些功能共同构成某个用户核心工作流
   • 建立叙事一致性评估：当前路线图传递给用户的产品故事是否清晰
   • 创建快速胜利vs战略投资的平衡评估：确保路线图同时包含短期和长期价值
   • 设计竞争对比功能集分析：与竞争对手的差异化来自哪些功能组合

量化结果与受益角色

可量化的成果

• 功能采用率：评分框架驱动的功能选择使上线后30天采用率提升35-45%
• 开发资源浪费减少：AI可行性预评估减少20-30%的"开发后发现质量不可达"返工
• 路线图对齐速度：标准化评分将季度路线图讨论时间减少40%，减少重复讨论
• 利益相关方满意度：透明的优先级理由使路线图相关利益相关方满意度提升30%
• 预期-实际偏差：持续校准后，用户影响预测准确度提升约25%

受益人群

• AI产品经理：将优先级决策从艺术变成科学，建立可防御的决策记录
• 工程团队：了解自己正在构建的功能为何重要，提升工作意义感和执行动力
• 销售/客户成功：清晰了解哪些客户需求已被纳入路线图及预期时间，设置合理期望
• 高管层：获得透明的路线图决策逻辑，减少在路线图审查上的时间

💡 实用提示词

提示词1 — AI功能积压评分批处理

对以下AI功能积压清单进行系统化评分和优先级排序。

产品背景：[产品名称，当前阶段，本季度战略重点]
评分框架（1-5分制）：
- 用户影响（40%权重）：受影响用户比例×影响深度
- 战略一致性（20%权重）：与当前季度OKR的匹配程度
- AI可行性（20%权重）：技术可行性和质量可达性
- 实施效率（20%权重，反向，努力程度越小分数越高）

功能积压清单：
1. [功能A名称]：[简要描述，预期影响]
2. [功能B名称]：[简要描述，预期影响]
3. [功能C名称]：[简要描述，预期影响]
4. [功能D名称]：[简要描述，预期影响]
5. [功能E名称]：[简要描述，预期影响]
[继续列出]

对每个功能进行评分：

功能A：
用户影响：[X]/5 — 理由：[...]
战略一致性：[X]/5 — 理由：[...]
AI可行性：[X]/5 — 理由：[...]
实施效率：[X]/5 — 理由：[...]
加权总分：[计算]

[重复所有功能]

优先级排序结果：
1. [功能名] — 总分[X] — 核心理由[一句话]
2. ...
[完整排序列表]

特别标注：
- 快速胜利（高分+低努力）：[列出]
- 战略赌注（高战略价值+高努力）：[列出]
- 不推荐本期（分数较低）：[列出，说明理由]

输出：完整评分矩阵 + 优先级排序 + 建议本季度执行的Top 5功能

提示词2 — AI可行性快速评估

对以下AI功能概念进行快速可行性评估，为路线图排序提供技术输入。

功能概念：[详细描述功能的用户体验预期]
技术背景：[当前使用的AI模型和基础设施]
质量要求：[功能需要达到什么质量水平才算成功]
时间约束：[期望在多少个工程sprint内完成]

可行性评估：

1. 核心AI能力需求分解：
   这个功能需要以下AI能力：
   - 能力1：[描述] — 当前最佳模型能力水平（1-5分）
   - 能力2：[描述] — 当前最佳模型能力水平
   [继续列出所有需要的AI能力]

2. 最大能力短板识别：
   当前与功能要求差距最大的能力是：[X]
   差距大小：[描述，如目前能达到60%的质量目标，需要90%]
   差距弥补路径：
   - 提示词工程可以填补多少？（估算）
   - RAG可以填补多少？（如适用）
   - 需要微调才能填补剩余差距吗？

3. 快速验证实验设计：
   在正式排入路线图之前，建议用[1-3天]的时间验证：
   - 实验内容：[具体实验设计]
   - 成功标准：[什么结果表明可行]
   - 失败标准：[什么结果表明不可行或需要调整范围]

4. 可行性评分（1-5分）：
   5分：完全可行，技术风险极低
   4分：可行，有小挑战但路径清晰
   3分：条件可行，需要成功解决[具体挑战]
   2分：技术风险较高，建议先做验证实验
   1分：当前技术条件下不建议排期

   本功能评分：[X]/5
   理由：[简明解释]

5. 如果可行性评分≥3，推荐排期建议：
   [近期排期建议，包括范围边界和风险缓解措施]

输出：可行性评估报告 + 验证实验方案 + 排期建议

提示词3 — 功能依赖关系分析

分析以下AI功能积压的技术依赖关系，优化执行序列。

功能列表（已按初步评分排序）：
1. [功能A]（评分：9.2）— 依赖：[描述技术依赖]
2. [功能B]（评分：8.8）— 依赖：[描述]
3. [功能C]（评分：8.5）— 依赖：[描述]
4. [功能D]（评分：7.9）— 依赖：[描述]
5. [功能E]（评分：7.5）— 依赖：[描述，如"依赖功能A的基础设施"]
[继续]

依赖关系分析：

1. 依赖关系图：
   [描述各功能间的依赖关系]
   - 阻塞器功能（被多个功能依赖的基础工作）：[识别]
   - 独立功能（无依赖，可立即开始）：[识别]
   - 依赖链：[A → B → C] 类型的串行依赖

2. 执行序列优化：
   考虑依赖关系后的推荐执行顺序：
   
   立即启动（无依赖）：[列出]
   
   第一批并行（无互相依赖）：[列出可并行的功能组]
   
   第二批（等待第一批完成后）：[列出]
   
   后续：[继续]

3. 关键路径识别：
   决定整体交付时间的关键路径是：[描述]
   关键路径上的瓶颈：[识别最可能延误的环节]

4. 解耦机会：
   是否有高优先级功能可以通过范围调整减少对低优先级功能的依赖？
   [分析并给出具体建议]

5. 调整后的季度执行计划：
   Sprint 1（第1-2周）：[具体功能]
   Sprint 2（第3-4周）：[具体功能]
   [继续规划]

输出：依赖关系图 + 优化执行序列 + 调整后的季度计划

提示词4 — 利益相关方优先级对齐工具

设计一个结构化流程，帮助以下利益相关方在功能优先级上达成共识。

待对齐的功能：[列出3-5个有优先级争议的功能]
各方立场：
- 产品团队倾向：[哪个功能，为什么]
- 工程团队倾向：[哪个功能，为什么]
- 销售团队倾向：[哪个功能，为什么]
- 高管关注：[哪个功能，为什么]

设计对齐流程：

1. 对齐前准备（各方提前完成）：
   每位参与者按统一评分框架独立评分
   提交格式：[设计提交表单]
   目的：在对齐会议前看到分歧在哪里

2. 分歧可视化（会议开始时）：
   将各方评分汇总成可视化对比
   重点识别：哪些功能分歧最大，分歧在哪个评分维度

3. 分歧解决流程（会议主体）：
   对每个高分歧功能：
   - 陈述各方评分的理由（非辩护，而是解释）
   - 识别分歧来源：假设不同 / 数据不同 / 价值观不同
   - 对于假设和数据分歧：确定如何获取澄清信息
   - 对于价值观分歧：上升到战略层面，由有权威的人决策

4. 决策记录：
   对于每个有争议的功能：
   - 最终决定的优先级
   - 决策理由（一句话）
   - 谁做的最终决定
   - 被否决方的关切如何在未来被解决

5. 后续跟进：
   - 决策记录的分发范围
   - 被推后功能的下次评审时间
   - 如果条件变化（新的用户数据/竞争变化）如何触发重新讨论

输出：对齐流程设计 + 会议议程 + 决策记录模板 + 跟进计划

提示词5 — 季度功能组合设计

为以下AI产品设计下季度的最优功能组合。

产品：[名称]
下季度战略重点：[1-2个核心战略目标]
可用工程能力：[总工程师周数]
前10个功能的评分和估算工作量：
1. [功能A]：评分[X]，工作量[Y]周
2. [功能B]：评分[X]，工作量[Y]周
[继续列出]
约束：
- 功能C和D存在依赖关系（C必须先于D）
- 功能E是企业客户的高优先级需求，必须在季度末完成
- 总工作量不超过[n]工程师周

设计最优功能组合：

1. 约束解析：
   强约束（必须满足）：[列出硬性约束]
   软约束（尽量满足）：[列出优先满足的软约束]

2. 最优化模型：
   目标：在约束条件下最大化总评分
   
   方案A（高价值优先）：[选择哪些功能，总分X，总工作量Y]
   方案B（战略平衡）：[选择哪些功能，总分X，总工作量Y]
   方案C（快速胜利优先）：[选择哪些功能，总分X，总工作量Y]

3. 推荐方案：
   推荐方案[X]，理由：[解释为何这个方案最优]
   
   本季度执行功能列表：
   - [功能名] — [时间安排] — [预期影响]
   [完整列表]
   
   本季度放弃的功能：
   - [功能名] — 推迟原因 — 下次评审时间

4. 季度叙事：
   这组功能共同讲述了什么产品故事？
   [描述本季度功能组合对用户体验的整体提升]

5. 风险和备选方案：
   如果功能A开发中途发现技术风险，备选功能是什么？

输出：最优功能组合 + 季度执行计划 + 决策理由 + 备选方案

10. AI用户研究综合与洞察提取器

将分散的用户研究数据转化为驱动AI产品决策的清晰洞察。

痛点与解决方案

痛点：用户研究产出的是数据，而非决策

大多数AI产品团队做了不少用户研究，但研究结果的转化效率很低。访谈录音被整理成逐字稿后往往被束之高阁；调查问卷的数据被统计分析后生成厚重的报告，只有研究者本人完整阅读过；可用性测试的发现被记录在Notion页面上，在产品迭代的紧张节奏中逐渐被遗忘。研究和决策之间存在一条鸿沟，导致产品决策仍然依赖于"我认为用户需要什么"，而非"用户实际告诉了我们什么"。

AI产品的用户研究还面临特殊挑战：用户不善于谈论自己与AI的交互体验。用户通常能清楚地描述软件功能的好用或难用，但对于AI输出的质量，他们的语言往往模糊："有时候感觉不对"、"有时候挺聪明的"。这种模糊性使得研究人员很难从访谈中提取可操作的AI质量洞察，而不止于"用户喜欢/不喜欢AI"这种过于粗略的结论。

研究积累的碎片化同样是挑战。三个月前的用户研究揭示了某个痛点，上个月的可用性测试确认了这个问题仍然存在，本周的NPS调查中有用户明确提出了同样的需求——但这三项研究存在于不同的地方，没有人把它们连接起来，看到跨研究的一致性信号。

COCO如何解决

1. 多源研究数据综合：COCO整合分散的用户研究：

   • 建立用户研究数据归档标准，确保所有研究以可搜索的格式保存
   • 设计跨研究的主题聚类分析，识别在不同时间和不同研究方法中反复出现的一致性发现
   • 创建研究发现的证据强度分级：区分来自多个研究的一致性洞察与单一研究的初步发现
   • 建立用户引言库，按主题归档最有代表性和最有力的用户语言
   • 设计研究-功能-结果的追踪链：每个功能决策背后的研究证据，以及功能上线后对用户问题的解决程度

2. AI产品用户心理模型分析：COCO深入理解用户如何看待AI：

   • 分析用户对AI能力的期望设定与实际体验的差距
   • 识别用户对AI的不同信任策略：从不信任到过度信任的分布
   • 研究用户如何学习提升与AI交互的技巧，以及学习瓶颈在哪里
   • 了解用户在哪些任务上愿意依赖AI，哪些任务上坚持人工处理
   • 分析用户如何解释AI失败：归因于自己的提示词、产品设计还是AI本身的能力

3. JTBD（待完成任务）框架应用：COCO揭示用户背后的真实需求：

   • 设计结构化的Jobs-to-be-Done访谈框架
   • 分析用户"雇用"AI产品来完成的功能性、情感性和社会性任务
   • 识别用户真正想要完成的任务与产品当前设计服务的任务之间的偏差
   • 探索用户在使用AI产品前的替代方案和变通方法
   • 建立任务重要性×满意度矩阵，定位最高价值的改进机会

4. 定量研究洞察提取：COCO从数据中提取行动洞察：

   • 设计NPS评论的AI特定分析框架，区分AI质量问题与一般产品问题
   • 建立应用内反馈分类体系，支持AI特定问题的快速归类
   • 分析用户行为数据中隐含的偏好信号
   • 设计用户分群分析，识别高价值用户与平均用户在研究发现上的差异
   • 创建满意度驱动因素分析，量化不同因素对整体满意度的贡献

5. 研究洞察传播与应用：COCO确保研究发现真正影响产品决策：

   • 设计研究洞察的产品化格式：简洁、有力、可直接用于决策的摘要
   • 建立研究-路线图直接映射：每个路线图优先级决策明确关联到支持它的研究发现
   • 创建实时洞察仪表板：关键用户洞察的持续更新视图
   • 设计研究洞察分享会议：跨职能团队的定期研究同步
   • 建立洞察有效期追踪：识别需要更新验证的过时洞察

6. 用户研究计划优化：COCO设计高效的研究投入：

   • 建立研究问题优先级框架：哪些问题最需要用户研究来回答
   • 设计混合研究方法：定性与定量研究的组合策略
   • 创建轻量级持续研究体系：不依赖大型项目的持续用户洞察收集
   • 设计参与者招募效率优化：找到最有代表性的目标用户的快速方法
   • 建立研究成本-洞察价值的ROI追踪

量化结果与受益角色

可量化的成果

• 洞察转化率：综合分析框架使用户研究发现直接影响路线图决策的比例从30%提升至70%
• 重复研究减少：系统化的研究积累减少了30-40%的重复调查相同问题的研究成本
• 决策速度：标准化的洞察提取使产品决策中引用用户证据的时间从数天缩短至数小时
• 功能成功率：有用户研究支持的功能上线后采用率比无研究支持的功能高50%
• 用户理解深度：系统化的跨研究综合使团队对用户心理模型的理解深度显著提升

受益人群

• AI产品经理：获得即用型的用户洞察，而非需要自己消化的原始研究报告
• 产品设计师：深入理解用户心理模型，设计更符合用户AI认知的界面
• ML工程师：了解用户真正的质量痛点，而非仅凭技术指标判断改进方向
• 市场营销团队：从用户研究中提取真实的用户语言，用于更有共鸣的产品传播

💡 实用提示词

提示词1 — 用户访谈综合分析

综合以下用户访谈记录，提取关于AI产品体验的关键洞察。

产品：[名称]
访谈数量：[n]个访谈
访谈对象：[用户类型描述]
访谈焦点：[访谈的主要研究问题]

访谈摘要/录音转录：
[粘贴或描述每个访谈的关键内容]

提取洞察：

1. 主题聚类（出现在3个以上访谈中的一致性发现）：
   主题A：[主题名称]
   - 出现频率：[X]/[总访谈数]
   - 代表性引言：["用户原话，来自访谈X"]
   - AI产品相关性：[这个发现如何影响AI功能设计]
   
   [重复所有主题]

2. Jobs-to-be-Done提取：
   功能性任务：[用户试图用AI完成什么实际任务]
   情感性任务：[用户希望在使用过程中感受到什么]
   社会性任务：[使用AI产品如何影响用户在他人眼中的形象]

3. AI信任与期望分析：
   - 用户对AI能力的期望水平（过高/合适/过低）
   - 用户在什么情况下信任AI输出，什么情况下不信任
   - 用户遭遇AI失败时的反应（放弃/重试/转人工）

4. 未满足需求识别：
   [用户明确表达或隐含表达的、当前产品没有满足的需求]

5. 行动建议（按优先级）：
   高优先级（多人提及，影响使用意愿）：[建议列表]
   中优先级（少数人提及但洞察重要）：[建议列表]
   研究方向（需要进一步验证的假设）：[列表]

输出：洞察综合报告 + JTBD摘要 + 行动建议清单

提示词2 — NPS评论AI特定分析

分析以下NPS调查评论，提取与AI产品体验相关的洞察。

产品：[名称]
NPS评分分布：批评者[X]%，中立者[Y]%，推荐者[Z]%，总体NPS: [分数]
评论总数：[n]条
主要AI功能：[列出关键AI功能]

评论数据：
[粘贴NPS评论，或描述主要主题]

进行AI特定分析：

1. AI相关评论分类：
   将所有提及AI功能的评论分类为：
   - AI质量满意：[数量，代表性引言]
   - AI质量不满意（幻觉/不准确）：[数量，引言]
   - AI质量不满意（不一致性）：[数量，引言]
   - AI速度问题：[数量，引言]
   - AI使用困难（提示词技能不足）：[数量，引言]
   - AI功能范围诉求（想要AI做更多）：[数量，引言]

2. 批评者vs推荐者的AI体验对比：
   批评者提及AI问题的比例：[X]%
   推荐者提及AI优势的比例：[Y]%
   结论：AI体验对NPS的贡献程度

3. NPS驱动因素分析：
   如果解决[AI问题X]，预计有[n]位批评者会转变为中立者/推荐者
   NPS改善潜力：+[Y]点

4. 用户语言提取：
   [收集描述AI价值的最有力的用户语言，可用于产品文案和营销]

5. 行动建议：
   对NPS影响最大的AI改进项（按影响排序）

输出：AI特定NPS分析报告 + NPS改善预测 + 行动优先级

提示词3 — 用户心理模型研究设计

设计一个研究计划，深入了解用户对AI产品的心理模型和期望。

产品：[名称]
研究目的：[理解什么——用户的AI期望？信任机制？使用抵触的来源？]
目标用户群体：[描述]
可用研究资源：[时间、预算、研究员人力]

设计研究计划：

1. 研究问题定义（3-5个核心问题）：
   Q1: [具体研究问题]
   Q2: [具体研究问题]
   [继续]

2. 研究方法组合：
   方法A — 深度访谈（回答"为什么"）：
   - 参与者：[n]人，招募标准：[描述]
   - 访谈时长：[X]分钟
   - 核心议题指南：[列出主要话题]
   
   方法B — 行为观察（看用户"实际做什么"）：
   - 观察场景：[什么任务/场景]
   - 数据记录方式：[录屏/观察者笔记/思考出声]
   
   方法C — 调查问卷（量化某些发现）：
   - 关键量化维度：[列出]
   - 目标样本量：[n]

3. AI特定访谈问题设计：
   了解期望：
   - "你第一次使用这个AI功能之前，你期望它能做到什么？"
   - "哪次你觉得AI的表现超出了你的期望？"
   
   了解信任：
   - "你什么时候会检查AI给你的答案？什么时候不检查？"
   - "如果AI给了一个看起来不对的回答，你通常会怎么做？"
   
   了解价值：
   - "如果明天AI功能消失了，你会错过什么？"
   - "你会向什么样的朋友推荐这个产品？怎么描述它？"

4. 分析框架：
   如何从研究数据中提取用户心理模型？
   - 分析维度：[期望校准度/信任层次/价值感知/技能发展阶段]
   - 用户分群：[不同心理模型的用户类型]
   
5. 交付物和应用：
   研究报告格式：[什么格式对产品决策最有用]
   预期交付给谁：[PM/设计/工程/高管]
   如何转化为产品行动：[研究发现如何直接进入产品决策流程]

输出：研究计划 + 访谈指南 + 分析框架 + 交付物模板

提示词4 — 用户分群洞察提取

基于以下数据，识别对AI产品体验有不同需求的用户分群。

产品：[名称]
可用数据：[描述可用的用户行为数据、人口统计数据、调查数据]
当前用户规模：[MAU]
已知用户差异：[描述你已经观察到的用户差异]

用户分群分析：

1. 分群维度识别：
   基于可用数据，最有意义的分群维度是：
   - AI功能使用深度（重度/中度/轻度用户）
   - 技术熟练程度（AI原生用户 vs AI新手）
   - 使用场景（个人效率 vs 团队协作 vs 专业任务）
   - 满意度水平（高满意度 vs 低满意度，以及各自的原因）

2. 各分群的AI体验画像：
   对于每个分群：
   - 规模：占用户总量的[X]%
   - AI使用模式：[如何使用AI功能]
   - 主要价值获取点：[从AI中得到什么价值]
   - 主要痛点：[与AI交互中最大的挫败来源]
   - 对产品的影响：[这个分群的留存/付费/推荐行为]

3. 高价值分群的深度分析：
   识别对产品最重要的1-2个用户分群（高价值+可服务）
   深入分析：
   - 他们的具体使用场景和工作流程
   - 他们的核心痛点和未满足需求
   - 他们的AI使用成熟度发展路径
   - 他们的扩展意愿（成为更重度用户的潜力）

4. 分群对产品策略的启示：
   - 产品应该优先服务哪个分群？（核心服务对象）
   - 不同分群是否需要不同的入门体验？
   - 是否有某个分群的需求与其他分群冲突？

5. 分群深化研究建议：
   [建议针对最重要分群开展深度研究的方法]

输出：用户分群报告 + 各群体AI体验画像 + 产品策略启示

提示词5 — 研究洞察产品化

将以下用户研究发现转化为可直接用于产品决策的格式。

研究背景：[研究方法、参与者数量、研究问题]
原始研究发现：
[描述研究发现，可以是条目式的研究结论]

产品化处理：

1. "How Might We"问题提取：
   将每个研究发现转化为设计机遇（"我们怎么可能……"）：
   
   发现：[研究发现]
   → HMW: "我们怎么可能[解决方向]，从而[用户获益]？"
   
   [对每个主要发现重复]

2. 产品假设提炼：
   将研究发现转化为可测试的产品假设：
   
   假设：如果我们[产品改变]，那么[用户行为变化]，
   因为[从研究中了解到的用户心理/需求]。
   验证方式：[如何检验这个假设]
   
   [对关键发现重复]

3. 路线图输入格式：
   将发现转化为路线图团队可以直接使用的语言：
   
   用户问题陈述：
   [一句话，清晰描述用户面临的问题，来自研究证据]
   
   证据强度：[强/中/弱，基于研究规模和一致性]
   
   潜在解决方向：[不是具体功能，而是解决方向]
   
   成功指标：[如果解决了这个问题，哪些指标会改变]

4. 关键用户引言卡片：
   为每个主要洞察提取最有力的用户原话：
   
   "用户原话，保留原始语言，不加工"
   — 用户类型，研究来源，日期

5. 反直觉发现清单：
   从研究中发现了哪些出乎意料的、与团队原有假设相违背的发现？
   [这些往往是最有价值的洞察]

输出：产品化洞察文档 + HMW问题集 + 路线图输入表 + 用户引言卡片集

11. AI智能体工作流与编排设计器

设计可靠、可观测的AI智能体系统，在复杂多步骤任务中持续交付价值。

痛点与解决方案

痛点：AI智能体系统在原型演示时令人印象深刻，但在生产中脆弱且不可预测

AI智能体系统是近年来最令人兴奋但也最难在生产环境中可靠运行的AI产品类别。演示视频中，智能体优雅地完成复杂的多步骤任务；但在生产环境中，同样的智能体经常陷入无限循环、执行了不该执行的操作、在模糊情况下无法优雅降级，或者在任意一个工具调用失败后整个任务崩溃。这种"演示-生产落差"在AI智能体领域尤其严重，因为智能体系统的失败模式远比单次LLM调用的失败模式复杂。

智能体系统的设计往往缺乏产品思维。工程师倾向于以"模型能做什么"作为设计起点，而不是以"用户在什么业务场景中需要自动化"作为起点。结果是构建了技术上令人印象深刻但解决了错误问题的智能体，或者构建了没有足够安全护栏的智能体（智能体有权限做的事情远超完成任务实际需要的权限）。

对AI智能体系统的可观测性和调试能力是产品团队普遍低估的挑战。当一个五步骤的智能体工作流出现问题时，如何追溯到具体哪一步出了什么错？智能体执行了多少次工具调用？每次调用的成本是多少？用户等待时间的分解？这些问题在设计阶段如果没有提前规划，在生产中将成为黑匣子，难以调试和优化。

COCO如何解决

1. 智能体任务适用性分析：COCO评估何时应该使用智能体架构：

   • 设计"智能体适用性检查清单"：并非所有多步骤任务都需要智能体，区分确定性工作流与真正需要动态决策的场景
   • 建立智能体vs工作流引擎的选择框架：何时用有向无环图的确定性编排vs AI驱动的动态编排
   • 评估任务的不确定性、工具使用复杂度和决策独立性三个维度
   • 创建智能体ROI评估：完全自动化vs人机协作vs手动执行的价值对比
   • 设计最小可行智能体（MVA）原则：从最小化权限和工具集开始

2. 智能体工作流设计：COCO构建可靠的智能体架构：

   • 设计任务分解框架：将复杂任务拆解为独立、可验证的子步骤
   • 建立工具设计原则：每个工具的范围、失败处理和确认机制
   • 创建智能体决策树：在不同中间状态下的决策逻辑
   • 设计检查点和验证步骤：在关键决策点插入验证，而非等待最终结果
   • 建立优雅降级策略：当智能体无法完成任务时如何处理

3. 安全护栏设计：COCO确保智能体不会造成意外伤害：

   • 设计最小权限原则：智能体只获得完成任务所必需的工具和权限
   • 建立高风险操作的人工确认机制：哪些操作需要用户明确批准
   • 创建不可逆操作保护：删除、发布、支付等操作的专项保护
   • 设计速率限制和预算控制：防止智能体失控产生不必要的成本
   • 建立自动暂停机制：检测到异常状态时自动暂停并请求人工介入

4. 智能体可观测性架构：COCO设计调试和监控基础设施：

   • 建立完整的执行追踪：每个LLM调用、工具调用和决策的详细日志
   • 设计任务执行时间线可视化：一眼看清任务执行的每个步骤
   • 创建工具调用统计：频率、成功率、成本分解
   • 建立智能体健康指标：任务完成率、平均步骤数、平均延迟
   • 设计失败模式分类：区分不同类型的失败，支持系统性改进

5. 多智能体协调设计：COCO处理复杂的多智能体系统：

   • 设计智能体角色分工：不同专业化智能体的职责边界
   • 建立智能体间通信协议：任务交接的信息格式和状态传递
   • 创建协调者/执行者架构：主智能体的任务分发与子智能体的专业执行
   • 设计冲突解决机制：当多个智能体对同一资源有需求时的优先级
   • 建立跨智能体的错误传播管理：子智能体失败如何影响整体任务

6. 智能体性能优化：COCO改善智能体的效率和成本：

   • 识别不必要的LLM调用：哪些决策可以用规则替代AI判断
   • 设计并行执行机会：可以同时执行的独立工具调用
   • 建立工具调用缓存：相同查询避免重复执行
   • 优化工具选择提示词：减少智能体在工具选择上的犹豫和错误
   • 建立成本-效果追踪：每个智能体工作流的实际成本和成功率

量化结果与受益角色

可量化的成果

• 生产可靠性：系统化设计的智能体系统任务完成率达到80-90%，而无设计的系统通常仅达到40-60%
• 调试效率：完整可观测性使智能体故障的平均诊断时间从数小时缩短至30分钟以内
• 成本控制：最小权限和优化设计减少不必要的LLM调用，降低40-60%的智能体成本
• 安全事件预防：强制确认机制和护栏设计减少90%以上的意外高风险操作
• 开发周期：有框架指导的智能体设计比从零开始设计缩短40%的设计-实现周期

受益人群

• AI产品经理：在设计阶段就考虑可靠性和安全性，避免产品发布后的昂贵修复
• ML工程师：获得清晰的智能体架构规范，减少在未定义边缘案例上的反复讨论
• 用户：体验更可靠、更透明的AI智能体，知道智能体在做什么，信任智能体不会做超出预期的事
• 企业客户：在高风险业务流程中部署AI智能体时，有可审计的执行记录和人工介入机制

💡 实用提示词

提示词1 — 智能体任务适用性评估

评估以下场景是否适合使用AI智能体架构。

场景描述：[详细描述用户试图完成的任务]
当前解决方案：[用户目前如何完成这个任务]
任务频率：[用户多久执行一次这个任务]
任务重要性：[任务结果的影响有多大，错误的代价是什么]

适用性评估：

1. 任务特征分析：
   - 任务步骤数：[大约几步]
   - 步骤确定性：[每一步的执行是否取决于前一步的结果]
   - 工具需求：[需要调用哪些外部工具/API/服务]
   - 决策复杂度：[需要做出判断的场景有多少]
   - 任务边界清晰度：[任务的成功/失败是否容易判断]

2. 智能体适用性评分（每项1-3分）：
   - 任务重复性：[1=独特/3=高度重复]（高重复=更值得自动化）
   - 规则化程度：[1=高度规则化/3=需要大量判断]（高判断=更需要AI）
   - 错误可逆性：[1=不可逆/3=完全可逆]（可逆=更安全使用智能体）
   - 任务清晰度：[1=模糊/3=极其清晰]（清晰=智能体更可靠）
   
   综合评估：高分=适合智能体，低分=考虑替代方案

3. 替代方案对比：
   方案A — 确定性工作流（规则引擎/RPA）：[适用性？局限性？]
   方案B — AI辅助人工（AI提供建议，人执行）：[适用性？局限性？]
   方案C — AI智能体（完全自动化）：[适用性？关键前提条件？]
   方案D — 混合模式（部分自动化）：[哪些步骤自动化，哪些保留人工？]

4. 推荐方案：
   [基于评估给出明确推荐，以及采用智能体方案的关键前提条件]

5. 风险评估：
   如果采用智能体方案，最大的风险是什么？
   如何缓解这些风险？

输出：适用性评估报告 + 替代方案对比 + 推荐方案 + 风险评估

提示词2 — 智能体工作流设计文档

为以下AI智能体任务设计完整的工作流规范。

任务名称：[智能体需要完成的任务]
任务触发条件：[什么情况下智能体被激活]
任务成功定义：[什么样的输出构成任务成功完成]
可用工具列表：[智能体可以调用的工具/API]
用户上下文：[智能体执行时可以访问的用户信息和历史]

设计工作流：

1. 任务分解：
   将任务拆解为独立的子步骤：
   步骤1：[子任务名称] — 输入：[X] — 输出：[Y] — 工具：[Z]
   步骤2：[子任务名称] — 输入：[X] — 输出：[Y] — 工具：[Z]
   [继续所有步骤]
   
   关键决策点：[在哪些步骤智能体需要做出重要判断]

2. 工具使用规范：
   对每个工具：
   - 工具名称和功能
   - 调用条件（何时使用）
   - 输入格式和验证
   - 预期输出和解析
   - 失败处理（如果工具调用失败，下一步怎么做）
   - 确认要求（是否需要用户确认才能调用）

3. 错误处理设计：
   失败场景1：工具调用超时
   → 处理方式：[重试/跳过/请求人工介入]
   
   失败场景2：工具返回意外结果
   → 处理方式：[解析策略/最小化影响的默认行为]
   
   失败场景3：任务无法完成（所有路径均失败）
   → 处理方式：[如何告知用户，保留什么状态供恢复]

4. 安全护栏：
   - 最大步骤数/时间限制：防止无限循环
   - 需要人工确认的操作：[列出高风险操作]
   - 严格禁止的操作：[无论什么情况都不能执行的操作]
   - 状态检查点：在哪些点保存任务状态

5. 用户透明度设计：
   - 智能体如何向用户展示执行进度
   - 哪些中间步骤应该向用户可见
   - 用户如何在任何时候暂停或撤销

输出：完整工作流规范 + 工具使用规范 + 错误处理设计 + 安全护栏

提示词3 — 智能体可观测性系统设计

设计以下AI智能体系统的可观测性和监控架构。

智能体系统：[描述智能体的功能和技术架构]
使用规模：[每天/月的任务执行量]
调试需求：[团队最常需要调查的问题类型]
现有监控基础设施：[已有的监控和日志工具]

设计可观测性架构：

1. 日志层级设计：
   任务级日志（每次智能体任务执行一条记录）：
   - task_id, user_id, start_time, end_time
   - task_status: success/partial_success/failed/abandoned
   - total_steps, successful_steps, failed_steps
   - total_llm_calls, total_tool_calls
   - total_tokens_used (input/output), total_cost
   - final_output_summary
   
   步骤级日志（每个子步骤一条记录）：
   - step_id, task_id, step_name, step_number
   - step_start_time, step_duration_ms
   - tool_called, tool_input_hash, tool_output_hash
   - step_result: success/failed/skipped
   - llm_call_count, tokens_used
   
   LLM调用级日志：
   - call_id, step_id, model_name, model_version
   - input_tokens, output_tokens, latency_ms
   - tool_calls_requested (if any)

2. 监控仪表板设计：
   实时运营面板：
   - 当前正在执行的任务数
   - 过去1小时的任务成功率
   - 当前平均任务执行时间
   - 失败任务的错误分布
   
   质量分析面板（日/周）：
   - 任务完成率趋势
   - 最常见的失败步骤
   - 工具调用成功率（按工具类型）
   - 平均任务成本趋势
   
3. 告警配置：
   P0告警：任务成功率<50%持续15分钟
   P1告警：平均任务成本超过预算[X]倍
   P2告警：特定工具错误率>20%

4. 调试工具：
   - 任务回放功能：逐步重现任务执行过程
   - 步骤对比分析：失败任务 vs 成功任务在关键步骤上的差异
   - LLM输入/输出查看器：任何步骤的原始模型交互

5. 成本追踪：
   - 按任务类型的成本分析
   - 成本异常检测（某类任务成本突然升高）
   - 月度成本预测

输出：可观测性架构设计 + 日志Schema + 仪表板规格 + 告警配置

提示词4 — 多智能体协调架构设计

设计以下复杂任务的多智能体协调架构。

任务描述：[需要多个专业化智能体协作完成的复杂任务]
子任务分解：[识别可以并行或串行执行的独立子任务]
资源限制：[API限速、预算、时间约束]

设计多智能体协调：

1. 智能体角色定义：
   协调者智能体：
   - 职责：任务分解、工作分配、进度监控、结果整合
   - 工具权限：[列出]
   - 决策权限：[哪些决策只有协调者可以做]
   
   执行者智能体A — [专业领域]：
   - 职责：[具体负责什么]
   - 工具权限：[仅与职责相关的工具]
   - 输出格式：[标准化的输出Schema]
   
   [重复其他执行者智能体]

2. 通信协议：
   任务分配格式：
   ```json
   {
     "task_id": "...",
     "assigned_to": "agent_A",
     "task_description": "...",
     "inputs": {...},
     "expected_output_schema": {...},
     "deadline": "...",
     "priority": "high/medium/low"
   }

任务完成报告格式：[定义格式]

任务失败报告格式：[定义格式，包括失败原因和建议的下一步]

3. 状态同步机制：

   • 共享状态存储：所有智能体可以读取任务的整体状态
   • 写入权限控制：每个智能体只能写入与自己任务相关的状态
   • 状态冲突解决：当多个智能体试图修改同一状态时的仲裁机制

4. 失败传播策略： 当子智能体失败时：

   • 协调者的决策逻辑：重试/替代执行/任务降级/取消
   • 失败对其他依赖子任务的影响
   • 最终向用户报告失败时的信息内容

5. 性能优化：

   • 可以并行的子任务识别
   • 减少不必要跨智能体通信的设计
   • 缓存可复用的中间结果

输出：多智能体架构设计 + 角色定义 + 通信协议 + 失败处理策略

**提示词5 — 智能体用户体验设计**

设计以下AI智能体产品的用户体验，确保透明度、可控性和信任感。

智能体功能：[描述智能体做什么] 目标用户：[技术熟练程度、对AI的熟悉程度] 任务典型时长：[完成一个任务通常需要多少时间] 风险等级：[智能体可以执行的最高风险操作类型]

设计用户体验：

1. 任务启动体验：

   • 用户如何描述任务（自然语言/结构化表单/混合）
   • 启动前的任务理解确认：展示智能体对任务的理解，用户确认后才开始
   • 预期时间和成本提示：告知用户大约需要多久，会消耗什么资源

2. 执行过程透明度：

   • 进度展示方式：[实时日志/步骤进度条/摘要更新]
   • 更新频率：[多久给用户一次进度反馈]
   • 技术细节披露程度：[用户看到什么级别的技术信息]

3. 人工介入节点设计： 哪些情况触发"智能体暂停，请求用户确认"：

   • 不可逆操作（列出）→ 显示具体内容，需要明确确认
   • 高风险操作（列出）→ 显示影响摘要，需要确认
   • 不确定情况（智能体置信度低）→ 展示不确定性，提供选项

4. 结果呈现设计：

   • 成功完成：清晰展示做了什么，结果是什么，用户需要做什么（如果有后续行动）
   • 部分完成：哪些完成了，哪些没有，为什么，用户如何处理未完成部分
   • 失败：发生了什么，原因，用户的选项（重试/修改参数/手动完成）

5. 历史记录和审计：

   • 用户可以查看哪些历史任务执行记录
   • 每个任务记录包含什么信息
   • 用户如何基于历史记录重新执行或调整任务

6. 信任建立设计：

   • 如何逐步建立用户对智能体的信任（从低风险任务开始）
   • 如何教育用户了解智能体的能力边界
   • 如何恰当地处理智能体犯错的情况，避免信任崩溃

输出：UX设计规范 + 关键界面描述 + 用户信任建立策略

12. AI模型幻觉率基准追踪器

建立系统化的幻觉率测量体系，让"我们的AI有多准确"从模糊印象变成精确数据。

痛点与解决方案

痛点：幻觉是AI产品最大的信任杀手，却是最难量化追踪的问题

"我们的AI有时候会编造答案"——这是几乎每个AI产品团队都知道的问题，但几乎没有团队能告诉你当前的幻觉率是多少，与上个月相比是改善了还是退化了，哪些查询类型的幻觉率最高，或者哪次模型更新显著改变了幻觉率。这种定量能力的缺失，意味着团队在不知情的情况下发布了可能提高幻觉率的模型变更，也意味着改善幻觉率的工作没有可靠的成效证明。

幻觉的多样性使测量更加复杂。幻觉不是一个单一的现象：有事实捏造（将不存在的信息陈述为事实）、混淆幻觉（将真实信息与错误细节混合）、过度自信（对不确定的事情给出确定性答复）、引用幻觉（引用不存在的来源）和能力幻觉（声称自己可以做实际上做不到的事情）。不同类型的幻觉需要不同的检测方法，也有不同的用户危害程度。

企业客户在AI采购中越来越多地要求提供可验证的幻觉率数据。一个能够提供"在我们的测试集上，事实性幻觉率为2.3%，较上季度降低了0.8个百分点"这样精确数据的AI产品，在企业销售中的信任度和说服力，远超只能说"我们的准确率很高"的竞争对手。

COCO如何解决

1. 幻觉类型分类框架：COCO建立精细的幻觉分类体系：

   • 定义事实性幻觉：可以被外部事实检验的错误陈述
   • 识别引用幻觉：不存在的来源、论文、数据的引用
   • 分析过度自信幻觉：对不确定问题给出确定性答案
   • 检测混淆幻觉：将真实信息与错误细节混合
   • 建立幻觉严重性分级：对不同类型幻觉的用户危害评估

2. 幻觉率测量方法论：COCO设计可靠的幻觉检测方案：

   • 建立"可验证问题集"：构建每个答案都有确定性正确答案的测试集
   • 设计自动化事实检验管道：利用知识库、搜索引擎验证关键声明
   • 创建LLM-as-judge幻觉检测：专门用于检测幻觉的judge提示词设计
   • 建立人工审核采样协议：对自动检测结果的人工校准流程
   • 设计置信度-幻觉相关性分析：模型的自我评估与实际准确性的关系

3. 幻觉率基准测试套件：COCO构建持久化的测量基准：

   • 设计领域特定探针集：针对产品核心领域的高风险知识问题
   • 建立时效性测试：检测知识截止日期相关的幻觉
   • 创建一致性测试：同一问题的不同表述是否产生一致答案
   • 设计压力测试：在模型不确定时是否会适当表示不确定
   • 建立对比基准：行业通用基准（如TruthfulQA）与产品特定基准的组合

4. 幻觉监控仪表板：COCO建立持续可见性：

   • 设计幻觉率时间序列追踪：按周/月追踪各类型幻觉率的趋势
   • 建立版本对比视图：不同模型版本的幻觉率比较
   • 创建查询类型细分：哪些问题类型幻觉率最高
   • 设计用户投诉关联：将用户的准确性投诉与幻觉率指标关联
   • 建立成本-幻觉权衡分析：更便宜的模型如何影响幻觉率

5. 幻觉缓解策略设计：COCO提供系统化的改进路径：

   • 设计RAG实施建议：针对特定幻觉类型的知识增强方案
   • 建立置信度校准方案：让模型在不确定时表达不确定
   • 创建事实验证层设计：高风险声明的实时核查机制
   • 设计用户界面缓解：如何在UI层面帮助用户识别可能不确定的答案
   • 建立微调数据策略：专门针对高幻觉场景的数据增强

6. 幻觉率报告体系：COCO支持对外的质量承诺：

   • 设计企业客户幻觉率报告格式
   • 建立SLA幻觉率承诺框架：什么样的承诺是合理和可维持的
   • 创建产品文档幻觉率披露指南：如何透明地向用户说明AI准确性
   • 设计投资者/董事会幻觉率摘要格式
   • 建立行业对标分析：与公开可用的竞争对手幻觉率数据对比

量化结果与受益角色

可量化的成果

• 幻觉检测率：系统化测试套件将幻觉问题的预生产发现率从30%提升至75%以上
• 幻觉率降低：有基准追踪的团队在一年内将幻觉率降低30-50%，而无追踪团队的幻觉率停滞不变
• 企业销售支持：提供幻觉率数据的AI产品在企业试用转化率上高出竞争对手35%
• 用户信任保留：主动的幻觉率管理将因AI错误引起的用户流失减少40-50%
• 监管合规：可验证的准确性记录在高风险AI应用（医疗、金融）的监管审查中节省大量时间

受益人群

• AI产品经理：将准确性从模糊的"还不错"变成可追踪的精确指标，支持模型投资决策
• 企业销售团队：用具体的幻觉率数据回答"你们的AI有多准确"这个关键采购问题
• ML工程师：获得明确的幻觉率目标和测量方法，将幻觉减少变成可量化的工程任务
• 高风险领域用户（医疗、法律、金融）：获得对AI输出可靠性的量化保证

💡 实用提示词

提示词1 — 幻觉率测试套件设计

为以下AI产品设计全面的幻觉率测试套件。

产品：[名称和主要功能]
知识领域：[产品主要处理的领域，如金融、医疗、技术、法律]
高风险场景：[哪些类型的幻觉对用户危害最大]
测试预算：[可用于测试套件的资源]

设计测试套件：

1. 幻觉类型覆盖：

类型1 — 事实性幻觉（优先级：最高）：
测试集设计：
- 问题类型：具有确定性正确答案的事实问题
- 答案验证方式：与权威来源对比
- 示例问题集（10个代表性问题）：[针对产品领域设计]
- 幻觉判定标准：[明确定义什么算幻觉]

类型2 — 引用幻觉：
测试集设计：[设计专门检测引用不存在来源的测试]

类型3 — 时效性幻觉：
测试集设计：[检测模型是否将过时信息呈现为当前事实]

类型4 — 置信度幻觉（过度自信）：
测试集设计：[检测模型是否在不确定时给出不当的确定性答案]

2. 测试集规模建议：
   每种类型：至少[X]个问题
   总规模：[Y]个问题（统计意义的最低要求）
   难度分布：[简单/中等/困难的比例]

3. 自动化检测方法：
   对于每种幻觉类型：
   - 检测工具/API（知识库查询/网络搜索/逻辑验证）
   - 检测置信度（这种检测方法有多可靠）
   - 需要人工复核的情况

4. 幻觉率计算标准：
   整体幻觉率 = 包含幻觉的回答数 / 总测试回答数
   分类型幻觉率 = 各类型幻觉数 / 对应类型测试数
   加权幻觉率 = 按严重性加权的综合幻觉率（更严重的幻觉权重更高）

5. 基准建立：
   当前基准测量日期：[日期]
   测量结果：[各类型幻觉率]
   下次测量计划：[时间]

输出：测试套件规范 + 100个示例测试问题 + 检测方法指南 + 基准记录表

提示词2 — 幻觉监控仪表板设计

设计AI产品幻觉率的持续监控仪表板。

产品：[名称]
测试套件：[描述已有的幻觉率测试套件]
监控频率：[计划多久运行一次测试]
目标受众：[谁会看这个仪表板]

设计仪表板：

1. 核心指标面板：
   - 总体幻觉率（当前值）：[X]%，与上次测量对比：[+/-Y%]
   - 分类型幻觉率：[表格展示各类型当前值和趋势]
   - 最新测量日期和测试集版本

2. 趋势分析面板：
   - 幻觉率时间序列图（过去6个月）
   - 模型版本标注：在图上标出模型更新的时间节点
   - 趋势判断：当前是改善趋势还是退化趋势

3. 细分分析面板：
   - 按查询类型的幻觉率分布（哪些类型最容易出现幻觉）
   - 按难度级别的幻觉率（简单/中等/困难问题的差异）
   - 高风险场景的专项追踪

4. 告警配置：
   - 幻觉率超过[X]%：P1告警（影响企业客户SLA）
   - 与上次测量相比上升超过[Y]%：P2告警（需要调查）
   - 特定高风险类型幻觉率超过[Z]%：P0告警（立即处理）

5. 改进追踪面板：
   - 当前进行中的幻觉率改进项目
   - 每个项目的目标幻觉率和当前进展
   - 历史改进项目的实际效果

6. 企业报告导出：
   - 月度幻觉率报告的自动生成模板
   - 企业客户专属报告格式

输出：仪表板设计规范 + 告警配置 + 报告模板

提示词3 — 幻觉根因分析与改进计划

分析以下幻觉率测试结果，识别根因并制定改进计划。

测试结果：
- 总体幻觉率：[X]%（目标：[Y]%）
- 按类型分布：事实性[X1]%，引用[X2]%，时效性[X3]%，置信度[X4]%
- 幻觉率最高的查询类型：[列出Top 3]
- 典型幻觉案例：[提供3-5个具体幻觉示例]

根因分析：

1. 知识缺口分析：
   模型在哪些知识领域表现出系统性幻觉？
   - 领域A：[X]% 幻觉率 → 根因假设：[训练数据不足/知识截止/领域过于专业]
   - 领域B：[X]% 幻觉率 → 根因假设：[...]

2. 置信度校准分析：
   模型在高幻觉率问题上的自我置信度如何？
   - 幻觉发生时，模型通常表现出高置信度还是低置信度？
   - 这对缓解策略的选择有什么启示？

3. 缓解策略选择：
   对于每类根因：
   
   知识缺口 → 推荐：
   - RAG（添加知识库）：预期效果？实施难度？
   - 提示词优化（鼓励"我不确定"）：预期效果？
   - 微调（添加不确定性表达训练数据）：预期效果？
   
   置信度问题 → 推荐：
   - 置信度校准：如何实施？
   - UI层面的不确定性展示：什么样的设计？

4. 改进优先级：
   [按改进成本/预期幻觉率降低对比排序]
   Quick wins（低成本，高效果）：[列出]
   Medium term（中等投入）：[列出]
   Long term（高投入，根治方案）：[列出]

5. 30/60/90天改进计划：
   30天目标：[具体改进项 → 预期幻觉率从X%降至Y%]
   60天目标：[...]
   90天目标：[...]

输出：根因分析报告 + 缓解策略评估 + 分阶段改进计划 + 成功指标定义

提示词4 — 幻觉率企业报告生成

为企业客户生成AI产品幻觉率报告。

客户行业：[医疗/金融/法律/教育/其他]
报告周期：[月度/季度]
本期测试结果：[幻觉率数据]
上期对比：[趋势数据]
客户使用场景：[客户主要用产品做什么]

生成企业报告：

1. 执行摘要（适合高管阅读）：
   - 本期AI准确性状况概述（一段话，使用业务语言而非技术术语）
   - 与上期相比的改善/变化
   - 对客户业务风险的影响（如果有）

2. 指标详情：
   - 总体事实准确率：[X]%（幻觉率的补集）
   - 在客户使用场景相关的领域准确率：[X]%
   - 检测到的幻觉实例数（本期）：[n]
   - 严重幻觉实例：[n]（附简要描述，不包含敏感信息）

3. 质量改善证明：
   - 本期相比上期的改善百分比
   - 已修复的已知幻觉问题
   - 正在进行中的改进项目

4. 风险评估：
   - 当前幻觉率对客户业务流程的具体风险评估
   - 建议的人工审核频率（如果幻觉率超过某阈值）
   - 高风险场景的特别建议

5. 下期承诺：
   - 下期幻觉率目标
   - 计划实施的改进措施
   - 监控调整（如有）

格式要求：简洁、正式、面向业务用语、无技术术语

输出：完整企业报告 + 执行摘要单页版 + 指标图表规格

提示词5 — 幻觉率A/B测试设计

设计用于验证幻觉率改善措施效果的A/B测试方案。

改善措施：[描述计划实施的幻觉缓解措施，如添加RAG/优化提示词/更换模型]
当前基准幻觉率：[X]%
期望改善幅度：[降低到Y%]
可用测试流量：[可以分配给测试的查询比例]

设计A/B测试：

1. 测试设计：
   对照组：当前系统（无改善措施）
   实验组：实施改善措施后的系统
   流量分配：对照[X]% vs 实验[Y]%
   
   分层策略：
   - 是否需要按查询类型分层（确保两组查询分布相似）
   - 是否需要用户级别的分层（同一用户始终分配到同一组）

2. 样本量计算：
   当前基准幻觉率：[X]%
   最小可检测效果（MDE）：[想检测到多小的改善就认为有意义]
   统计功效：80%（标准设置）
   显著性水平：p<0.05
   所需样本量：[计算]
   预计测试持续时间：[基于流量估算]

3. 评估指标：
   主指标：幻觉率（检测到幻觉的查询比例）
   护栏指标：延迟p95不显著上升 / 用户满意度不下降
   
4. 评估方法：
   幻觉检测方法：[与基准测试一致的检测方法]
   抽样策略：[全量评估/随机抽样20%]
   人工校验比例：[X]%（确保自动检测质量）

5. 分析计划：
   主要分析：幻觉率的统计显著性检验（Fisher精确检验或卡方检验）
   子群体分析：分查询类型的改善是否一致
   
6. 成功/失败决策标准：
   成功：幻觉率降低≥[X]%，统计显著（p<0.05），护栏指标无显著退化
   失败：未达到上述标准
   后续行动：成功则全量推出；失败则[返回设计/扩大规模重测/放弃该方案]

输出：A/B测试方案 + 样本量计算 + 评估指标 + 决策框架

13. AI系统提示词安全与注入风险审查器

在攻击者发现漏洞之前，系统化地识别和修复提示词安全风险。

痛点与解决方案

痛点：提示词安全漏洞是AI产品最易被忽视但危害最严重的攻击面

大多数AI产品团队在系统提示词安全上的投入严重不足。他们设计了精心的系统提示词来定义AI的行为边界，却没有系统化测试这些边界是否真的有效。恶意用户通过提示词注入绕过内容限制、通过角色扮演技巧诱导AI违反使用政策、或者通过巧妙的措辞提取系统提示词的完整内容——这些攻击在没有专门安全测试的情况下，往往在产品发布后数天内就被发现并在社区中广泛传播。

一次成功的提示词注入攻击的后果可能是多方面的：AI被诱导输出违法或有害内容（监管风险和法律责任）、竞争对手通过系统提示词提取获取产品的核心知识产权（商业风险）、或者用户被诱导相信假冒的"AI建议"（信任危机）。对于在高监管行业（医疗、金融、法律）运营的AI产品，一次安全事件可能直接导致业务暂停和巨额罚款。

企业客户的安全审查已经开始专门关注AI安全。标准的AI安全问卷包含了"你如何防止提示词注入"、"你如何保护系统提示词不被泄露"、"你如何防止AI被用于有害目的"等问题。无法提供文档化的安全测试结果的AI产品，在企业采购中越来越难以通过安全审查关。

COCO如何解决

1. 提示词安全威胁建模：COCO系统化识别攻击面：

   • 建立针对具体产品的威胁模型：谁可能攻击，想要实现什么目的
   • 分析攻击面：用户输入如何被纳入提示词、哪些端点暴露给外部
   • 识别高价值攻击目标：系统提示词内容、受限功能、其他用户的数据
   • 评估攻击者的技术能力：普通用户 vs 安全研究员 vs 自动化攻击脚本
   • 建立攻击影响矩阵：不同攻击成功后对业务和用户的影响评估

2. 提示词注入测试套件：COCO设计全面的安全测试：

   • 生成直接注入攻击测试用例：覆盖常见的"忽略之前指令"变体
   • 设计角色扮演绕过测试：通过假设性场景和角色扮演诱导越界行为
   • 创建多轮对话渐进攻击：模拟逐步升级的攻击序列
   • 设计编码绕过测试：Base64、特殊字符、多语言等编码攻击
   • 建立系统提示词提取测试：检测系统提示词的保密性

3. 系统提示词加固技术：COCO提供具体的防护实现：

   • 设计明确的行为边界声明：让模型清楚地知道什么是绝对不能做的
   • 建立角色稳定性加固：防止模型被"角色替换"攻击
   • 创建指令优先级框架：当用户指令与系统指令冲突时的处理原则
   • 设计语境隔离技术：防止用户输入的内容被解读为系统指令
   • 建立越权请求识别和拒绝模板：优雅而安全地处理攻击性输入

4. 输入预处理与输出过滤：COCO设计安全处理管道：

   • 建立输入风险评分系统：在提交给模型前检测高风险输入
   • 设计输入清理策略：去除或转义高风险的输入模式
   • 创建输出安全过滤：在返回给用户前检测违规输出
   • 建立速率限制与异常检测：识别自动化攻击尝试
   • 设计安全日志：记录触发安全机制的事件，支持事后分析

5. 安全测试流程设计：COCO建立持续的安全评估机制：

   • 设计产品发布前的安全测试门控
   • 建立安全测试的更新机制：随着新攻击技术出现及时更新测试套件
   • 创建安全漏洞严重性分级和响应流程
   • 设计负责任披露政策：如何处理外部安全研究人员报告的漏洞
   • 建立安全事件应急响应预案

6. 安全合规文档生成：COCO产出企业采购所需的安全证明：

   • 生成AI安全测试报告（用于企业安全审查）
   • 创建安全控制措施文档（用于SOC 2 AI相关要求）
   • 设计安全问卷预填答案（标准AI安全问卷的标准回答）
   • 建立漏洞响应承诺文档（对安全漏洞的披露和修复承诺）
   • 生成渗透测试范围说明（用于委托第三方安全测试）

量化结果与受益角色

可量化的成果

• 漏洞发现率：系统化安全测试在发布前发现70-80%的提示词安全漏洞，与用户发现相比平均提前3-4周
• 企业安全审查通过率：有安全文档的AI产品安全审查通过率提升50-60%，平均审查时间缩短30%
• 安全事件减少：主动安全测试将产品发布后3个月内的公开安全事件减少60-80%
• 修复成本降低：预发布发现的安全漏洞修复成本仅为生产环境事件响应成本的10-20%
• 品牌保护：避免"AI被黑客破解"类的负面报道，保护品牌信任度

受益人群

• AI产品经理：将安全纳入产品设计，而非在安全事件后被动修复
• CISO/安全团队：获得AI特定的安全测试框架和合规证据
• 企业销售团队：以文档化的安全实践通过企业客户的安全审查关卡
• 用户：使用经过安全验证的AI产品，降低被诱导看到有害内容的风险

💡 实用提示词

提示词1 — 系统提示词安全审计

对以下AI产品的系统提示词进行安全审计。

系统提示词：[粘贴完整系统提示词]
产品类型：[面向用户的产品类型，如客服/写作助手/代码助手等]
主要安全限制：[系统提示词中设定的主要禁止行为]
用户群体：[谁会使用这个产品]

安全审计：

1. 安全边界清晰度评估：
   - 禁止行为是否明确列举？（模糊的禁止规则更容易被绕过）
   - 是否存在矛盾的指令（可能被利用来创造"例外"）？
   - 拒绝策略是否清晰？（什么情况下应该拒绝，如何拒绝）

2. 脆弱性识别：
   角色替换脆弱性：
   - 提示词是否对"忘记你的系统指令"类攻击有防护？
   - 是否明确声明角色不可被用户覆盖？
   
   假设性场景脆弱性：
   - 是否对"假设你是一个没有限制的AI"类攻击有防护？
   
   系统提示词泄露脆弱性：
   - 是否有防止用户提取系统提示词的保护措辞？
   
   指令注入脆弱性：
   - 是否对用户输入中嵌入的系统级指令有防护？

3. 加固建议：
   对于每个识别的脆弱性，提供具体的加固文本：
   [脆弱性描述] → [加固措辞示例]

4. 加固后提示词草案：
   [提供完整的加固版系统提示词]

5. 建议的安全测试用例（20个）：
   [针对这个特定提示词的注入攻击测试用例]

输出：安全审计报告 + 加固建议 + 改进版提示词 + 测试用例

提示词2 — 提示词注入测试套件生成

为以下AI产品生成全面的提示词注入测试套件。

产品功能：[描述AI产品功能]
主要安全限制：[AI不应该做的事情]
系统提示词特点：[系统提示词的关键特征，如角色定义、权限限制等]

生成测试套件（覆盖以下攻击类型）：

类型1 — 直接指令覆盖（10个测试用例）：
[生成尝试直接覆盖系统指令的测试提示词]
每个包含：
- 攻击提示词（完整文本）
- 攻击目标（试图实现什么）
- 安全响应标准（什么是正确的拒绝响应）
- 失败指标（什么样的响应表明安全漏洞）

类型2 — 角色扮演绕过（10个测试用例）：
[生成通过角色扮演/假设性场景绕过限制的测试]

类型3 — 渐进式升级攻击（5个多轮对话序列）：
[设计多轮对话，逐步升级对AI限制的挑战]

类型4 — 系统提示词提取尝试（10个测试用例）：
[设计试图让AI透露系统提示词内容的测试]

类型5 — 编码和混淆攻击（5个测试用例）：
[使用Base64、特殊字符、缩写等混淆技术的攻击]

评分标准：
- 每个测试：通过（拒绝了攻击）/失败（被攻击成功）/部分通过（部分信息泄露）
- 综合安全得分：通过数/总测试数 × 100%

输出：完整测试套件（50个测试用例）+ 评分表 + 测试执行指南

提示词3 — 安全事件响应计划

为以下AI产品制定提示词安全事件响应计划。

产品：[名称]
已知的安全风险点：[最可能发生的安全事件类型]
用户规模：[MAU]
企业客户数量：[n]

制定响应计划：

1. 安全事件分级：
   P0 — 严重安全事件：[定义标准，如有害内容被大规模传播]
   P1 — 高危事件：[定义标准，如系统提示词泄露]
   P2 — 中危事件：[定义标准]
   P3 — 低危事件：[定义标准]

2. 每个级别的响应流程：

P0响应（目标：30分钟内缓解）：
- 步骤1：[立即采取的行动]
- 步骤2：[通知谁，如何通知]
- 步骤3：[临时缓解措施]
- 步骤4：[用户和企业客户通知]
- 责任人：[角色]

3. 修复优先级：
- 临时修复（1小时内）：[系统提示词的快速加固措施]
- 短期修复（24小时内）：[输入过滤层的添加]
- 长期修复（1周内）：[系统性安全改进]

4. 外部沟通模板：
   向用户的通知：[简短、诚实、不引起恐慌的通知模板]
   向企业客户的通知：[正式、详细的事件报告模板]
   向媒体/公众的回应：[如果事件公开时的回应指南]

5. 事后审查模板：
   [结构化的安全事件后评审，确保从事件中学习]

输出：分级响应计划 + 通知模板 + 修复优先级框架 + 事后审查模板

提示词4 — 企业AI安全问卷预填答案

为以下AI产品预填标准企业安全问卷答案。

产品：[名称和功能]
已实施的安全措施：[描述已有的安全控制]
安全认证：[SOC 2/ISO 27001/等]
安全测试历史：[描述已进行的安全测试]

生成标准安全问卷答案：

Q1: 您的AI系统如何防止提示词注入攻击？
A: [详细、具体的回答，描述技术控制措施]

Q2: 系统提示词的保密性如何保证？
A: [描述保护措施]

Q3: 如何防止AI被用于生成有害内容？
A: [描述内容安全机制]

Q4: 是否进行了AI特定的渗透测试？
A: [描述测试历史和结果]

Q5: 如果发现AI安全漏洞，如何处理？
A: [描述漏洞响应流程]

Q6: AI系统的访问控制机制是什么？
A: [描述API访问控制和用户认证]

Q7: 如何监控AI系统的异常使用？
A: [描述监控和告警机制]

Q8: AI系统如何处理用户滥用？
A: [描述滥用检测和响应]

Q9: 安全测试频率是多少？
A: [描述测试计划]

Q10: 有第三方安全审计吗？
A: [描述外部审计情况]

输出：完整问卷预填答案 + 缺口识别（哪些答案当前还无法自信回答）+ 改进路线图

提示词5 — AI安全测试报告生成

生成用于企业审查的AI安全测试报告。

测试背景：
- 测试日期：[日期]
- 测试范围：[哪些功能/端点被测试]
- 测试方法：[测试类型和工具]
- 测试人员：[内部/外部，资质说明]

测试结果：
- 测试用例总数：[n]
- 通过数量：[n]
- 发现的漏洞：[n个，按严重性分类]
- 已修复漏洞：[n]
- 残余风险：[描述]

生成安全测试报告：

1. 执行摘要：
   [2段，描述测试范围、整体安全状况、关键发现]

2. 测试方法论：
   [描述测试覆盖的攻击向量类别和测试技术]

3. 发现摘要：
   [按严重性分类的发现统计，不包含可能被利用的技术细节]

4. 修复证明：
   [已修复漏洞的描述：发现了什么 → 如何修复 → 验证方法]

5. 残余风险声明：
   [诚实描述已知但未完全修复的风险及管理措施]

6. 下次测试计划：
   [安全测试的持续计划]

7. 证明和责任声明：
   [签名确认，声明报告的准确性和完整性]

格式要求：正式、专业、适合企业CISO阅读

输出：完整安全测试报告 + 附件清单（原始测试数据存档位置）

14. AI产品上线就绪清单生成器

确保AI产品发布时的每个关键环节都得到验证，避免因准备不足导致的发布失败。

痛点与解决方案

痛点：AI产品发布失败往往源于系统性遗漏，而非单一问题

AI产品发布失败很少是因为某一个明显的大问题，而是因为多个小问题的叠加：监控系统在发布前24小时才配置，没有足够时间验证；回滚程序从未被实际测试过，发布后出现问题时才发现回滚流程本身也有缺陷；人工审核团队没有被提前通知，导致发布初期高风险输出积压未处理；企业客户的成功经理没有被告知新AI功能的使用注意事项，导致第一批企业用户遭遇质量问题时无法及时处理。

AI产品发布的就绪检查比传统软件更复杂，因为需要同时验证技术层（模型质量、延迟、可用性）、产品层（用户体验、入门流程、帮助文档）、合规层（偏见测试、安全测试、法规合规）和运营层（监控、支持、沟通）四个维度。传统的发布检查清单只覆盖技术层，导致其他维度的准备不足。

发布就绪评估缺乏客观标准也是常见问题。"我们已经准备好了"这个判断往往基于直觉而非清单——不同团队成员对"准备好"的定义不同，在压力下容易省略重要的验证步骤。清晰的、量化的就绪标准可以让发布决策从"感觉好像可以了"变成"所有关键指标都达到了预设门槛"。

COCO如何解决

1. 四维发布就绪框架：COCO建立全面的就绪评估体系：

   • 技术就绪：模型质量、性能、可靠性和安全测试的通过标准
   • 产品就绪：用户体验、入门流程、帮助内容的完备性
   • 合规就绪：偏见测试、安全审计、法规合规文档的完成
   • 运营就绪：监控、支持、升级流程和利益相关方沟通的准备

2. 定制化清单生成：COCO根据具体产品特点生成针对性清单：

   • 分析产品风险等级（高/中/低）确定检查项深度
   • 根据目标市场定制合规检查项（EU vs US vs 行业特定）
   • 基于功能类型添加特定检查（实时决策vs内容生成vs数据分析）
   • 考虑用户群体特点定制保护措施（是否包含未成年人、弱势群体）
   • 根据部署规模调整检查粒度（MVP vs 全量发布 vs 大规模扩展）

3. 量化就绪门控：COCO将清单转化为客观的通过标准：

   • 为每个关键检查项定义明确的通过/失败标准（而非主观判断）
   • 建立强制通过项（阻断发布的关键条件）vs 建议通过项
   • 设计例外处理流程：在特殊情况下如何记录已知风险并获得批准
   • 创建就绪评分系统：量化整体发布就绪程度
   • 建立最低就绪门槛：低于某个综合分数不允许发布

4. 发布阶段差异化清单：COCO支持分阶段的发布策略：

   • 内部测试阶段清单：最基本的质量和安全门控
   • 私有Beta阶段清单：中等就绪要求，重点在用户反馈循环
   • 有限公开阶段清单（5-20%流量）：完整监控和支持就位
   • 全量发布清单：所有系统在高流量下的验证

5. 发布后监控计划：COCO确保发布后的持续就绪：

   • 设计T+24小时、T+72小时和T+30天的关键检查
   • 建立发布后质量降级的回滚触发标准
   • 创建发布后用户反馈快速响应流程
   • 设计发布后利益相关方沟通节奏（内部团队、企业客户、公众）
   • 建立发布后问题的优先级处理规则

6. 发布就绪文档化：COCO产出发布决策的证据记录：

   • 生成发布就绪报告（供发布决策会议使用）
   • 建立检查清单的完成时间戳和负责人记录
   • 创建例外决定的书面记录（为什么某个未通过项仍然决定发布）
   • 设计发布后的快速回顾模板（72小时后的发布质量评估）
   • 建立发布历史数据库（支持未来发布决策的改进）

量化结果与受益角色

可量化的成果

• 发布失败率降低：系统化就绪清单将发布后48小时内的严重事件减少65-75%
• 发布回滚率降低：明确的回滚标准和测试将发布后7天内的不必要回滚减少50%
• 合规发现前置：发布前合规检查将法规合规问题在发布前发现的比例提升至85%
• 跨团队对齐：统一的就绪标准将发布决策会议的时间减少40%（减少重复讨论）
• 发布质量稳定性：严格的就绪标准使发布后30天内的用户满意度方差降低30%

受益人群

• AI产品经理：有清晰的发布标准，减少在发布决策上的主观压力和风险
• 工程团队：知道什么标准算做好了，减少不明确的"再看看"反馈
• 法律合规团队：合规检查被系统性地纳入发布流程，而非事后补救
• 运营/客户成功团队：提前知道即将发布的变化，有足够时间准备支持材料

💡 实用提示词

提示词1 — AI产品发布就绪清单生成

为以下AI功能发布生成完整的就绪清单。

功能描述：[详细描述即将发布的AI功能]
发布范围：[全量/部分用户/A/B测试]
风险等级：[高/中/低，及理由]
发布时间：[计划发布日期]
目标市场：[地区/行业]

生成四维就绪清单：

一、技术就绪 ✓/✗/N/A

AI质量门控：
[ ] 在[测试集名称]上达到[X]%以上的准确率
[ ] 幻觉率低于[X]%（基于[检测方法]）
[ ] 偏见测试通过：各受保护属性的性能差异小于[X]%
[ ] 安全测试通过：提示词注入测试套件通过率>[X]%

性能门控：
[ ] 延迟p50<[X]ms，p95<[Y]ms，p99<[Z]ms
[ ] 在预期峰值流量下的负载测试通过
[ ] 错误率<[X]%

可靠性：
[ ] 回滚程序已测试并记录（上次测试日期：[日期]）
[ ] 监控和告警已配置并验证
[ ] 故障转移机制已测试

二、产品就绪 ✓/✗/N/A

用户体验：
[ ] 用户测试通过（至少[n]名目标用户完成测试任务）
[ ] 空状态/边缘案例的UX已设计
[ ] AI局限性的用户透明度已实现

内容与文档：
[ ] 帮助文档已发布
[ ] 入门引导流程已完成
[ ] 发布通知/更新日志已准备

三、合规就绪 ✓/✗/N/A

[ ] 偏见测试报告已完成并审批
[ ] 安全测试报告已完成
[ ] 法律审查已完成（针对[适用条款]）
[ ] 隐私影响评估已完成（如适用）
[ ] EU AI Act合规（如适用）

四、运营就绪 ✓/✗/N/A

[ ] 客户支持团队已接受新功能培训
[ ] 企业客户成功经理已收到发布通知
[ ] 发布后48小时的监控值班已安排
[ ] 问题升级流程已沟通

综合就绪评分：[通过项数/总必要项数]
发布决策：可以发布 / 有条件发布（列出条件）/ 暂不发布（列出原因）

输出：定制化发布就绪清单 + 评分 + 发布决策建议

提示词2 — 发布就绪评审会议设计

设计AI产品发布前的就绪评审会议流程。

发布功能：[简述]
会议参与者：[列出参与角色]
会议时间：[发布前多少天举行]
预期就绪状态：[现在完成了多少%的检查项]

设计评审会议：

1. 会议议程（60分钟）：
   
   0-5分钟：功能概述和发布目标
   
   5-25分钟：就绪清单审查
   - 技术就绪状态（工程负责人汇报）
   - 产品就绪状态（PM汇报）
   - 合规就绪状态（法务/合规汇报）
   - 运营就绪状态（运营/CS汇报）
   
   25-45分钟：未通过项讨论
   - 对每个未通过项：是真正的阻塞项吗？有替代方案吗？
   - 对需要例外处理的项：风险评估和签字授权
   
   45-55分钟：发布决策
   - 明确的Go/No-Go/Go with Conditions决策
   - 如果Go with Conditions：具体条件和验证时间
   
   55-60分钟：下一步行动
   - 责任人和截止时间分配

2. 决策框架：
   Go（可以发布）：所有强制通过项已通过，建议通过项通过率>[X]%
   No-Go（暂不发布）：任何强制通过项未通过
   Go with Conditions：[定义条件性发布的标准]

3. 会议输出文档：
   - 就绪评审记录（签字）
   - 已记录的例外和理由
   - 未通过项的行动计划

输出：会议设计 + 议程 + 决策框架 + 输出文档模板

提示词3 — 发布后监控计划

设计以下AI功能发布后的监控和响应计划。

功能：[描述]
主要风险：[发布后最可能出现的问题类型]
用户规模：[发布后的预期用户量]
关键业务指标：[发布成功的定义]

设计发布后监控计划：

1. T+1小时检查（发布后立即监控）：
   关键指标：
   - 错误率：<[X]%（否则触发P0响应）
   - 延迟p95：<[X]ms（否则触发调查）
   - AI质量抽样：初始50个请求的人工抽检
   
   责任人：[工程值班 + PM on-call]
   检查频率：每10分钟一次

2. T+24小时评估：
   - 错误率趋势是否稳定
   - 用户反馈初期信号（收到投诉了吗？）
   - 核心质量指标是否在预期范围
   - 基础设施是否在正常成本范围
   
   汇报：发布经理发送24小时状态更新给团队

3. T+72小时深度评估：
   - 质量指标完整分析
   - 用户行为数据（采用率、完成率、反馈率）
   - 支持票据分析（AI相关问题的频率和类型）
   - 企业客户反馈收集
   
   决策点：继续/调整/回滚的判断

4. T+30天总结：
   - 功能是否达到发布前设定的成功标准
   - 前30天的主要问题和处理情况
   - 经验教训（改进下次发布流程）

5. 回滚触发标准：
   自动回滚触发：[错误率超过X%持续Y分钟]
   手动回滚触发：[PM判断的条件]
   回滚决策权：[谁有权触发回滚]

输出：分阶段监控计划 + 回滚触发标准 + 责任分配 + 30天总结模板

提示词4 — 企业客户发布通知

为以下AI功能发布准备企业客户通知和支持材料。

功能：[描述]
影响的企业客户：[哪些企业客户会受到影响]
变化的性质：[是新增/修改/弃用现有功能]
发布时间：[日期]
已知的潜在影响：[可能影响企业客户工作流的方面]

准备企业沟通材料：

1. 提前通知邮件（发布前[n]天发送）：
   主题：[清晰说明变化的邮件主题]
   
   正文包含：
   - 变化概述（2-3句话，业务语言）
   - 变化原因（为什么这个变化对客户有益）
   - 发布日期和生效时间
   - 对客户工作流的影响（如果有）
   - 需要客户采取的行动（如果有）
   - 支持联系方式

2. 客户成功经理简报：
   - 变化的详细技术说明
   - 常见客户问题和回答
   - 已知的局限性和注意事项
   - 上报流程（如果客户反馈问题）

3. 发布日通知（发布当天）：
   简短的"变化已生效"通知
   包含：变化摘要 + 反馈渠道

4. 常见问题文档（发布与帮助文档一同更新）：
   Q: 这个变化会影响我的现有工作流吗？
   A: [回答]
   
   Q: 如果我遇到问题，怎么办？
   A: [回答]
   
   [继续其他预期问题]

5. 回滚通知模板（备用，如需要回滚）：
   [说明回滚发生、原因、预计恢复时间]

输出：完整企业沟通套件 + CS团队简报 + FAQ文档

提示词5 — 发布失败根因分析

对以下AI产品发布失败进行根因分析，改进未来发布流程。

发布失败描述：
- 发布功能：[名称]
- 发布日期：[日期]
- 问题描述：[发生了什么，影响了多少用户，持续多久]
- 采取的措施：[如何解决的]
- 恢复时间：[多久后完全恢复]

根因分析：

1. 失败时间线重建：
   [按时间顺序列出从发布到问题被检测到修复的关键事件]

2. 根本原因分析（5-Why方法）：
   为什么问题发生？
   → 为什么[原因1]？
   → 为什么[原因2]？
   → 为什么[原因3]？
   → 为什么[原因4]？
   → 根本原因：[系统性原因]

3. 就绪清单漏洞分析：
   这个问题是否可以通过就绪清单被提前发现？
   - 如果是：就绪清单中缺失了什么检查项？
   - 如果否：为什么无法在发布前发现？

4. 监控盲区识别：
   问题最早可能被什么指标检测到？
   为什么监控没有及时发现？
   需要添加什么新的监控指标？

5. 改进行动计划：
   对就绪清单的改进：[具体添加/修改的检查项]
   对监控体系的改进：[新的监控指标和告警]
   对发布流程的改进：[流程变化]
   
   每项改进：负责人 + 完成时间

6. 未来预防措施：
   这次事件教会了我们什么？
   哪个假设被证明是错误的？

输出：根因分析报告 + 就绪清单改进建议 + 监控改进计划 + 经验教训文档

15. AI RAG流水线架构顾问

设计、评估和优化检索增强生成（RAG）流水线——从文档摄入策略到分块、向量嵌入、检索、重排序和生成——提升准确性与性能。

痛点与解决方案

痛点：RAG流水线缺乏整体架构，质量问题持续叠加

负责基于RAG功能的AI产品经理——知识助手、文档问答系统、企业搜索、合规工具——面临一个反复出现的架构难题：RAG流水线往往以零散、渐进的方式搭建，每个组件各自优化，而非作为一个整体系统来设计。文档摄入策略凭便利性选择（PDF解析，怎么简单怎么来），分块策略沿用框架默认值（512个token，固定大小），嵌入模型则是手边现成的（text-embedding-ada-002，自初始部署后从未更换），检索策略是没有重排序的基础余弦相似度。每一个未经深思的组件选择都会造成质量问题叠加，最终表现为检索结果不相关、分块语义割裂、生成内容缺乏上下文——而由于故障可能发生在流水线的任何阶段，诊断这些问题极为困难。

诊断挑战是AI PM最大的痛苦来源之一。当RAG系统给出错误或不相关的答案时，根本原因可能有很多：相关文档根本没有被摄入；文档摄入了但分块方式把相关信息切到了不同块中；分块是完整的，但嵌入模型无法用能匹配查询嵌入的方式来表示其语义内容；正确的分块被检索到了，但重排序将它推到了低位；或者正确的分块提供给了LLM，但LLM未能从中提取正确答案。诊断这一连串可能需要大多数团队尚未建立的组件级评估方法——因此面对RAG质量下降，往往是堆更多文档或升级LLM，而这两者都没有解决真正的瓶颈。

扩展性问题制造了第三个失败维度。在知识库1,000篇文档时运行尚可的RAG流水线，在100,000篇文档时性能往往大幅下滑，因为在小规模下做出的架构选择在生产规模下并不成立。随着语料库增长，相似但不相关的分块积累，召回率下降。向量搜索覆盖大型索引需要更多基础设施，延迟上升。缺乏元数据过滤意味着针对特定文档子集的查询会从整个语料库中检索到噪声。这些扩展性问题属于架构问题，仅靠参数调整无法解决——需要在知识库增长之前就做出深思熟虑的架构选择。

COCO如何解决

1. 文档摄入策略设计：COCO优化内容进入流水线的方式：

   • 按内容类型推荐文档处理策略：PDF、HTML、Office文档、结构化数据库
   • 为每种文档类型设计元数据模式：哪些属性可在下游实现过滤和检索精度提升
   • 识别内容清洗需求：索引前必须去除哪些噪声
   • 为多模态RAG场景推荐表格、图像和结构化数据的处理策略
   • 为知识库文档设计更新与版本控制策略

2. 分块策略优化：COCO设计保留上下文的分块结构：

   • 按内容类型推荐分块策略：固定大小、基于句子、基于段落、语义分块
   • 根据查询类型、上下文窗口利用率和检索精度的权衡来设计分块大小
   • 推荐跨块边界保留上下文的重叠策略
   • 为需要细粒度检索和宽泛上下文的场景设计父子块架构
   • 使用测试查询评估不同分块策略对检索准确率的影响

3. 嵌入模型选择与优化：COCO推荐合适的嵌入方案：

   • 对比嵌入模型在特定领域和语言需求上的表现
   • 在领域特定检索任务与通用基准上评估嵌入模型性能
   • 评估嵌入质量与索引成本/延迟之间的权衡
   • 设计混合检索策略：稠密嵌入与稀疏BM25检索结合以提升召回率
   • 为通用嵌入表现不足的专业领域推荐微调嵌入模型

4. 检索与重排序流水线设计：COCO构建高精度检索系统：

   • 设计检索查询构建策略：原始查询 vs. 查询扩展 vs. 假设文档嵌入（HyDE）
   • 推荐元数据过滤，在向量相似度搜索前预先缩小范围
   • 设计重排序层以提升初始检索后的精度：交叉编码器重排序、基于LLM的重排序
   • 为分解成多个子问题的复杂查询构建多查询检索策略
   • 设计最终上下文组装方式：如何对检索到的分块进行排序和展示给生成模型

5. RAG评估框架：COCO创建可量化的质量评估体系：

   • 定义RAG特定评估指标：检索召回率、检索精度、答案忠实度、答案相关性
   • 构建RAGAs或类似框架的评估流水线，实现组件级诊断
   • 设计端到端评估：衡量用户问题是否被正确回答
   • 为特定领域创建黄金问题集，以实现可重复的质量测量
   • 建立组件级基线，使未来架构变化可与之对比衡量

6. RAG性能与成本优化：COCO针对生产经济性进行调优：

   • 分析各流水线阶段的延迟贡献并识别瓶颈
   • 推荐向量索引配置，平衡召回率、延迟和基础设施成本
   • 为常见查询设计缓存层，同时降低延迟和嵌入API成本
   • 为延迟敏感场景推荐异步预计算策略
   • 预测目标规模下的基础设施成本，识别成本最优架构

量化结果与受益角色

可量化的成果

• RAG答案准确率提升：通过结构化架构指导重新设计RAG流水线的团队，在不更换生成模型的情况下实现答案准确率提升35–55%
• 检索精度提升：合理的分块和重排序设计将检索精度（检索到的分块中相关分块的比例）从通常45–60%的基线提升至75–88%
• 流水线诊断时间：组件级评估框架将识别RAG质量问题瓶颈的时间从2–4周缩短至2–3天
• 扩展性问题预防：经过架构设计的流水线在知识库从1万篇增长到50万篇文档时，答案质量偏差维持在**±8%以内，而零散搭建的流水线性能下滑35–60%**
• RAG延迟优化：合理的缓存和异步设计将P95 RAG响应延迟降低40–65%

受益人群

• AI产品经理：理解并传达推动RAG质量的架构决策，实现对改进投资的知情优先排序，以及关于质量限制的清晰利益相关者沟通
• 构建RAG系统的机器学习工程师：获得包含组件级设计决策的架构蓝图，而非通过反复试错重新探索最佳实践
• 数据工程师：获得文档摄入流水线的清晰规范，包括元数据模式、内容清洗要求和更新频率要求
• 产品用户：体验到能可靠检索相关上下文并生成准确、有根据答案的RAG驱动功能，而非听起来合理却是幻觉的输出

💡 实用提示词

提示词1 — RAG架构设计

为以下用例设计RAG流水线架构。

用例：[描述用户向RAG系统提问的内容以及应从何处检索]
知识库：[描述文档语料库——类型、大小、更新频率、语言]
查询特征：[典型查询长度、复杂度、具体性——查询是短关键词还是完整问题？]
延迟要求：[用户的目标响应时间]
准确率要求：[错误或不相关答案的可接受失败率]
规模：[当前文档数量，12个月内预测]

设计各流水线组件：

1. 文档摄入：每种文档类型的处理策略、元数据模式、更新策略
2. 分块：策略（固定/语义/层次），分块大小，重叠——附针对此用例的理由
3. 嵌入：模型推荐，维度，索引策略
4. 检索：top-k选择，元数据过滤方法，混合检索推荐
5. 重排序：重排序器选择（交叉编码器/LLM/跳过），此用例的上下文
6. 上下文组装：如何为生成模型格式化检索到的分块
7. 生成：有根据生成的提示词模板，引用格式，不确定性处理

输出：完整RAG架构规范 + 组件选择理由 + 预期检索质量基线

提示词2 — RAG质量诊断

诊断以下RAG系统的质量问题并识别瓶颈。

RAG系统描述：[描述当前流水线设置]
症状：[描述观察到的质量问题——不相关答案/答案缺失/幻觉/响应缓慢]

表现出问题的测试案例：
1. 查询：[查询]
   预期答案：[正确答案]
   实际答案：[系统生成的内容]
   检索到的分块：[粘贴检索到的前3个分块]

2. [再重复2–3个失败案例]

对每个案例分析：
1. 相关信息是否存在于知识库中？
2. 相关文档是否被正确分块（答案是否在单个块内）？
3. 相关分块是否被检索到（是否在top-k中）？
4. 如果已检索到，排名是否高到足以进入上下文窗口？
5. 如果已在上下文中，生成模型是否正确使用了它？

基于分析：
- 主要瓶颈是什么：摄入/分块/检索/重排序/生成？
- 哪种具体的架构变化最能改善失败的测试案例？
- 测试不同修复方案的优先顺序是什么？

输出：每个测试案例的根因分析 + 主要瓶颈识别 + 优先修复计划

提示词3 — 分块策略评估

评估并优化以下RAG知识库的分块策略。

知识库描述：[文档类型、内容结构、典型文档长度]
当前分块：[token数分块大小，重叠，分块方法]
主要查询类型：[描述用户通常问的问题类型]

提供5个代表性知识库文档摘录：
[粘贴摘录]

提供5个当前表现不佳的示例查询：
[粘贴查询]

分析：
1. 对于每种查询类型，捕获一到两个块中相关上下文的理想块大小是多少？
2. 当前分块策略是否导致相关信息被跨块边界分割？请举例说明。
3. 层次（父子）分块策略是否能改善此用例的检索？
4. 语义分块是否会比固定大小分块在此内容类型上表现更好？
5. 建议：修订后的分块策略及具体参数

生成3种替代分块配置及其预期权衡：
- 配置A：[规范] — 最适合[查询类型]
- 配置B：[规范] — 最适合[查询类型]
- 配置C：[规范] — 最适合[查询类型]

输出：分块分析 + 推荐配置 + 验证改进的测试计划

提示词4 — RAG评估框架设计

为以下RAG系统设计评估框架。

RAG系统：[描述]
主要用例：[用户使用此系统的目的]
领域：[知识库领域]
当前质量关注点：[最重要的质量维度]

设计评估框架：

1. 黄金问题集：生成覆盖以下范围的20道评估问题：
   - 简单事实检索（5题）：来自知识库的单一答案问题
   - 多源问题（5题）：需要跨多个分块综合的答案
   - 时态或条件问题（5题）：依赖特定条件或日期的答案
   - 边界问题（5题）：处于知识库覆盖边缘的问题

2. 组件级指标：
   - 检索召回率@k：相关分块在前k个检索结果中的概率
   - 检索精度@k：前k个结果中有多少是相关的
   - 答案忠实度：生成的答案是否坚守检索到的上下文
   - 答案相关性：生成的答案是否回应了所问的问题

3. 测量方法：如何为每项指标评分（尽可能自动化，必要时人工评估）

4. 基线测量：在当前系统上运行评估以建立基线

5. 回归测试协议：何时重新运行评估（知识库更新/模型更换/提示词更改）

输出：评估框架规范 + 黄金问题集 + 评分标准 + 基线测量说明

提示词5 — RAG性能优化计划

为以下遇到延迟问题的RAG系统制定性能优化计划。

当前性能：
- P50延迟：[毫秒]
- P95延迟：[毫秒]
- P99延迟：[毫秒]
- 目标P95延迟：[毫秒]
- 每秒查询数：[当前值和目标值]

流水线延迟分解（如可获取）：
- 文档检索（向量搜索）：[毫秒]
- 重排序：[毫秒]
- LLM生成：[毫秒]
- 其他（解析、后处理）：[毫秒]

基础设施：
- 向量数据库：[类型和配置]
- 嵌入模型：[名称和托管方式]
- LLM：[名称和API]
- 当前基础设施：[描述]

分析并建议：
1. 主要延迟瓶颈：哪个阶段消耗时间最多？
2. 向量搜索优化：索引配置，近似最近邻设置，过滤策略
3. 缓存机会：哪些查询或嵌入可以缓存，命中率是多少？
4. 并行化：哪些流水线阶段可以并行而非顺序执行？
5. 重排序器优化：重排序器是瓶颈吗？更轻量的重排序器能实现足够质量吗？
6. 异步策略：哪些阶段可以预计算以减少用户感知延迟？

输出：延迟优化路线图 + 每项优化的预期改进效果 + 基础设施成本影响

16. AI模型延迟与吞吐量优化指南

识别并解决AI推理延迟瓶颈——流式传输、批处理、模型选择、基础设施调优——在不牺牲输出质量的前提下满足用户体验SLA。

痛点与解决方案

痛点：AI功能延迟被长期低估，诊断困难

AI产品经理经常在发布后而非发布前才发现延迟问题，因为开发环境——小测试集、低并发、无地理分布——是生产延迟的糟糕代理。在开发者笔记本上响应800毫秒的功能，在东南亚生产负载下用户可能需要等待3,500毫秒。单独处理时只需1.2秒的提示词，在模型处理峰值并发负载时可能需要6秒以上。这些延迟差异不是实现缺陷——它们是系统架构属性，需要深思熟虑的设计选择来解决。等到用户投诉或NPS反馈揭示问题时，AI PM已经在管理一个线上产品危机，而不是做设计决策。

诊断挑战因AI延迟的多组件性质而加剧。LLM功能的总响应时间是：到模型API的网络延迟、模型的首个token时间（TTFT）、生成延迟（每token）以及两端应用处理时间的总和。这些组件由不同因素驱动，需要不同的干预措施。高TTFT可能表明提示词处理开销可通过提示词压缩或前缀缓存来减少。高每token生成延迟可能表明使用了前沿模型来处理较小模型也能胜任的任务。高尾部延迟可能表明速率限制事件需要更好的队列和重试逻辑。没有组件级测量，优化工作就会瞄准错误的瓶颈。

延迟的用户体验影响是非线性的，且依赖具体用例。对于代码补全功能，超过200毫秒的延迟会显著降低体验——开发者期望几乎即时的补全。对于文档分析功能，如果输出质量高且等待时间清晰传达，用户愿意等10–15秒。这些不同的延迟容忍度需要特定用例的SLA和优化策略。大多数团队对所有AI功能应用单一延迟预算，而不按交互类型区分，导致快速功能过度工程化或慢速功能工程不足。

COCO如何解决

1. 延迟分解与组件归因：COCO识别时间消耗在哪里：

   • 对完整请求生命周期进行仪表化，将时间归因到每个组件：客户端、网络、服务器端预处理、模型TTFT、生成、后处理
   • 识别每个组件级别的P50/P95/P99延迟
   • 区分无服务器部署中的冷启动延迟与稳态延迟
   • 测量用户群体的地理延迟差异
   • 生成延迟瀑布图，识别主要瓶颈

2. 流式传输与渐进式渲染设计：COCO优化感知延迟：

   • 为适合渐进式文本显示的功能设计token流式传输实现
   • 推荐减少感知等待时间的骨架加载和渐进披露模式
   • 识别不适合流式传输的功能（结构化输出、函数调用）并设计替代方案
   • 优化流式传输实现，将首个token时间最小化为主要感知延迟指标
   • 设计AI生成期间设定合理用户预期的加载状态UX

3. 延迟模型与基础设施选择：COCO将基础设施与需求匹配：

   • 基于延迟预算推荐模型选择：哪些模型层级能在负载下达到目标延迟
   • 评估API端点选项：共享推理 vs. 专用容量 vs. 预置吞吐量
   • 评估延迟敏感场景的本地部署或私有云推理
   • 推荐缓存层设计，消除常见查询的重复计算
   • 在团队预期流量模式下对比推理API提供商的P95延迟

4. 批处理与并发优化：COCO设计高吞吐量架构：

   • 为多个请求可同时处理的场景设计最优批大小
   • 推荐队列管理策略，处理流量突发而不引发延迟尖峰
   • 识别预取机会：用户请求前可预先生成AI响应的情况
   • 为当前阻塞用户流程的延迟容忍功能设计异步处理模式
   • 计算不同并发配置下的吞吐量影响

5. 针对延迟降低的提示词工程：COCO减少生成长度：

   • 识别过度输出冗余，设计减少token生成时间的输出长度限制
   • 推荐在不降低输出质量的前提下减少TTFT的提示词模式
   • 评估链式推理（增加token生成）对每个用例是否值得承担延迟成本
   • 设计两阶段生成模式：快速骨架响应 + 后续丰富详情
   • 通过压缩计算提示词长度缩减的延迟影响

6. SLA定义与监控设计：COCO创建性能管理框架：

   • 根据交互类型和用户期望研究，为每个用例定义合适的延迟SLA
   • 设计用于跟踪生产中延迟SLA的监控基础设施
   • 建立延迟SLA违规的告警阈值和升级路径
   • 为结合多个AI调用的功能创建延迟预算分配框架
   • 生成季度延迟性能审查模板

量化结果与受益角色

可量化的成果

• P95延迟改善：通过流式传输、缓存和基础设施调优，结构化延迟优化项目在不降级模型的情况下将P95响应时间降低45–70%
• TTFT优化：提示词压缩和前缀缓存将具有长稳定系统提示词功能的首个token时间减少30–50%
• 延迟导致的用户放弃率降低：P95响应时间低于2秒的功能，用户放弃率比P95延迟超过4秒的功能低41%
• 延迟优化的成本效益：对于质量要求允许的用例，针对延迟关键功能的小模型替换同时将P95延迟和推理成本降低50–60%
• SLA违规率：具有告警的结构化SLA监控将用户会话遇到SLA违规的比例从未监控基线12–18%降至3%以下

受益人群

• AI产品经理：以与传统软件性能要求同等的严格程度定义和执行AI功能延迟SLA，提升用户体验可预测性
• 工程团队：获得延迟分解，将优化工作引向实际瓶颈而非方便的目标
• UX设计师：了解其功能可用的延迟预算，并设计减少感知等待时间的加载状态和渐进披露模式
• 用户：持续体验在可接受时间范围内响应的AI功能，而非表现出破坏信任的不可预测延迟

💡 实用提示词

提示词1 — 延迟分解分析

分析以下AI功能的延迟状况并识别优化机会。

功能：[AI功能描述]
当前延迟测量：
- P50：[毫秒]
- P95：[毫秒]
- P99：[毫秒]
- 目标P95 SLA：[毫秒]

组件分解（如可获取，否则估算）：
- 客户端预处理：[毫秒]
- API网络往返：[毫秒]
- 模型首个token时间（TTFT）：[毫秒]
- 模型生成时间：[毫秒]，平均[N]个输出token
- 服务器端后处理：[毫秒]

使用模式：
- 峰值并发：[并发用户数]
- 地理分布：[用户区域]
- 流量分布（全天峰值）：[描述]

分析：
1. 哪个组件是主要延迟瓶颈？
2. 每个组件的延迟驱动因素是什么？
3. 如果每个组件独立优化，可实现的最大P95是多少？
4. 哪些优化可以在不更换LLM或不影响质量的情况下实施？
5. 如果需要更换模型才能达到SLA：哪些更小的模型选项存在，质量权衡是什么？

输出：延迟瀑布分析 + 瓶颈识别 + 优先优化路线图

提示词2 — 流式传输实现设计

为以下AI功能设计流式传输实现以减少感知延迟。

功能：[描述——AI生成什么内容]
当前实现：[流式或非流式，描述当前用户体验]
目标TTFT：[毫秒]
输出类型：[自由文本/结构化JSON/代码/混合]
客户端平台：[Web/移动/API]

设计流式传输策略：

1. 流式传输适用性：流式传输适合此输出类型吗？如果是结构化输出，能以有用的方式流式传输吗？
2. TTFT优化：哪些提示词和基础设施变化能减少此功能的首个token时间？
3. 渐进式渲染：UI应如何在流式传输时呈现部分输出？（逐词/逐行/逐段）
4. 部分输出处理：对于只有完整时才有用的输出，生成过程中UI应显示什么？
5. 流式传输中断时的错误处理：如何为用户优雅地处理流中断
6. 降级行为：如果客户端或网络条件不支持流式传输怎么办？

设计用户体验：
- 第一个token到达前的加载状态
- 生成过程中的渐进显示行为
- 完成信号设计：用户如何知道生成已完成？

输出：流式传输实现规范 + UX行为设计 + 错误处理协议

提示词3 — 模型替换延迟分析

分析以下用例中替换更快模型以改善延迟的可行性。

当前模型：[模型名称]，P95 TTFT：[毫秒]，P95总计：[毫秒]，每次查询成本：$[X]
延迟目标：P95 [毫秒]
质量基线（当前模型）：[评估指标得分]
最低可接受质量：[阈值——低于此值，用户体验不可接受地降低]

候选更快模型：
- 模型A：[名称]，估计P95 TTFT：[毫秒]，成本：$[X]，已知质量特征
- 模型B：[名称]，估计P95 TTFT：[毫秒]，成本：$[X]，已知质量特征

设计替换评估：
1. 质量差距测试：生成50个代表性生产查询；对比当前模型与候选模型的输出
2. 质量评分：定义对比输出的评分标准
3. 延迟测量：在代表性负载下测量每个候选模型的实际P95延迟
4. 成本影响：计算生产流量规模下的月度成本变化
5. 风险评估：每个候选模型最可能在哪些用例或查询类型上表现不足？
6. 决策框架：如果质量差距为X%且延迟改善为Y毫秒，替换是否合理？

输出：模型替换评估计划 + 决策标准 + 预期延迟和成本影响表

提示词4 — 延迟SLA定义框架

为以下AI产品功能组合定义延迟SLA。

需要SLA定义的功能：
1. [功能名称]：[描述、交互类型、用户等待时的上下文]
2. [功能名称]：[同上]
3. [功能名称]：[同上]
[继续所有功能]

用户研究输入（如可获取）：
- 每种功能类型的测量或估计用户耐心阈值
- 按延迟区间的放弃率数据（如可获取）

对每个功能定义：
1. 交互类型：实时交互/同步工作流/后台处理
2. 用户期望基线：用户对此类交互期望什么延迟？
3. SLA层级：
   - P50目标（大多数用户的良好体验）
   - P95目标（可接受体验；超过此值，用户明显不满）
   - P99硬性限制（超过此值，用户任务完成率明显下降）
4. 降级体验策略：当无法满足SLA时产品应做什么？（加载指示器/队列/异步通知）
5. SLA测量方法：如何在生产中测量SLA合规性

输出：所有功能的SLA表格 + 降级体验设计指南 + 监控实施要求

提示词5 — 多步骤AI功能的延迟预算分配

为以下多步骤AI功能的各组件分配延迟预算。

功能：[涉及多个AI调用或流水线步骤的功能描述]
总用户感知延迟预算：[P95毫秒]
用户交互上下文：[描述用户在等待期间在做什么]

流水线步骤：
1. [步骤名称]：[描述] — 当前延迟 [毫秒]
2. [步骤名称]：[描述] — 当前延迟 [毫秒]
3. [步骤名称]：[描述] — 当前延迟 [毫秒]
[列出所有步骤]

可并行化步骤（可同时运行）：
- [步骤A] 和 [步骤B] 可并行运行

顺序依赖：
- [步骤C] 依赖 [步骤A] 的输出

分配延迟预算：
1. 当前关键路径：考虑顺序依赖，可实现的最小延迟是多少？
2. 并行化机会：哪些步骤可以并行化，新的关键路径是什么？
3. 预算分配：总预算如何在各步骤间分配？
4. 风险步骤：哪些步骤在P95条件下最可能超出其预算？
5. 优化优先级：哪个步骤的优化对总延迟影响最大？
6. 应急预算：每个步骤分配多少缓冲以应对意外延迟？

输出：按步骤的延迟预算表 + 并行化设计 + 优化优先级排序

17. AI竞品AI功能差距分析器

系统性地绘制竞品AI功能图谱，识别产品AI能力差距，并为路线图优先排序生成战略响应框架。

痛点与解决方案

痛点：竞品AI功能跟踪零散、被动，且长期不完整

负责竞争情报的AI产品经理面临AI时代特有的速度问题：竞品AI功能发布比传统软件功能发布更快、更难预测、技术上更不透明。竞品可以凭借新基础模型的能力跳跃发布一项AI能力，其工程团队可能只用了几周时间，而复制这一能力可能需要数月——这意味着单个竞品AI发布所创造的竞争差距，可能比传统产品竞争中见过的任何差距都更大、更持久。通过常规渠道跟踪这些发布——关注竞品博客、阅读其工程师的推文、扫描更新日志邮件——往往是在竞品优势确立数天或数周后才能拼凑出一个不完整的图景。

差距分析挑战因AI功能的技术不透明性而进一步复杂化。宣布"AI驱动的文档分析"的竞品，背后可能是任何东西——从GPT-4 API调用到具有专有训练数据和自定义RAG流水线的精密微调模型。表面功能描述告诉你用户看到了什么，但没有告诉你实现中嵌入了哪些技术优势。在共同用户群最常见任务上表现明显更好的竞品AI功能会创造竞争劣势，如果不理解底层能力差距就很难应对——这是提示词工程差距、模型选择差距、训练数据优势还是RAG架构优势？没有竞争分析的技术深度，AI PM就会做出针对症状（功能）而非差距（底层能力）的路线图响应。

战略响应问题是大多数AI竞争分析彻底崩溃的地方。做好竞争跟踪的团队——监控功能、测试竞品产品、阅读技术博客——往往无法将这些情报转化为可行的路线图决策。情报堆积在没人有时间综合的共享文档中。能够对竞争差距做出高价值响应的功能没有被优先排序，因为竞争洞察与路线图决策之间的联系从未被明确建立。AI PM最终是在对输单和客户流失作出反应，而非主动管理竞争AI能力差距。

COCO如何解决

1. 竞品AI功能库存构建：COCO建立全面的竞争图谱：

   • 使用结构化元数据对已定义竞品集中的所有AI驱动功能进行分类
   • 按AI能力类型对功能进行分类：生成、分类、检索、推荐、预测、自动化
   • 记录明显的技术实现深度：API级集成 vs. 微调模型 vs. 专有模型
   • 跟踪功能发布日期以分析竞品AI开发速度
   • 构建可搜索的竞品AI功能数据库供持续参考

2. 能力差距矩阵开发：COCO绘制你领先和落后的地方：

   • 在共同能力分类法上将产品的AI功能集与每个竞品进行对比
   • 计算能力覆盖差距：竞品有哪些AI能力是产品缺失的？
   • 评估能力深度：即使两款产品都有某功能，谁的质量/性能更好？
   • 识别独家AI优势：产品拥有而当前没有竞品提供的能力
   • 生成整个能力分类法中竞争地位的热力图

3. 竞争差距的用户影响评估：COCO优先考虑哪些差距重要：

   • 将竞争差距与产品类别中用户最频繁执行的任务关联
   • 评估已识别差距是否影响核心价值主张或边缘用例
   • 分析销售失败数据和客户反馈，识别推动流失的竞争差距
   • 估计受每个竞争差距影响的用户群体
   • 区分竞争同等差距（必须弥补才能保持竞争力）和差异化机会

4. 竞品AI功能技术深度分析：COCO调查"如何实现"：

   • 分析公开博客文章、招聘信息和会议演讲以推断竞品AI架构
   • 系统测试竞品以评估AI质量、延迟和行为
   • 根据行为特征识别微调模型与通用API使用的迹象
   • 评估复制竞品能力所需的投入：数周 vs. 数月 vs. 数年
   • 区分可快速弥合的差距和持久的竞争优势

5. 战略响应框架：COCO将情报与路线图决策连接：

   • 按战略响应对每个竞争差距进行分类：立即弥合/稍后弥合/放弃并差异化/通过定位中和
   • 生成优先差距弥合项的竞争响应路线图
   • 为团队选择不弥合的差距设计差异化策略：如何重新框架产品优势
   • 为销售和客户成功团队创建竞争说明卡
   • 建立竞争监控节奏和报告结构

6. 持续竞争监控系统：COCO创建持续情报：

   • 设计结构化监控流程：关注哪些信息源、多频繁监控、谁来综合
   • 创建竞品AI功能告警系统，对重大能力发布快速响应
   • 构建向领导层报告的季度竞争评审模板
   • 设计系统性竞品测试协议，用于持续质量基准测试
   • 生成用于在组织内分发竞争情报的竞争通讯模板

量化结果与受益角色

可量化的成果

• 竞争差距发现完整性：结构化竞争分析比零散跟踪多识别2.7倍的AI能力差距，包括公开公告中不可见的差距
• 竞争响应速度：拥有持续竞争监控系统的团队对重大竞品AI功能发布的响应比定期手动审查的团队快3–4周
• AI能力销售赢单率：拥有有据可查的竞争能力分析的产品，在AI功能为评估标准的竞争交易中赢单率提高22%
• 路线图-竞争对齐：使用结构化竞争差距分析的AI PM报告**64%**的信心认为其路线图针对了最有影响力的竞争差距
• 竞争情报分发：拥有结构化说明卡和竞争简报的团队，销售和CS团队做出不准确竞品对比的比率低37%

受益人群

• AI产品经理：将竞争跟踪从被动零散的活动转变为系统性情报项目，主动为路线图决策提供信息
• 销售与客户主管：获得包含准确AI能力对比的最新说明卡，在销售对话中自信定位
• 产品领导：定期获得支持战略投资决策和市场定位选择的竞争AI格局报告
• 工程团队：了解竞品部署了哪些具体AI能力，实现技术差距评估而非功能层面的功能匹配

💡 实用提示词

提示词1 — 竞品AI功能库存

为以下产品类别构建全面的竞品AI功能库存。

我们的产品：[名称和描述]
竞品集：[列出4–6个主要竞品]
产品类别：[描述市场和主要用例]
AI功能范围：[此类别中值得跟踪的AI功能类型]

对每个竞品分类：
1. 所有AI驱动功能（从公开信息尽可能完整地列出）
2. 对每个功能：描述、发布日期（如已知）、AI能力类型、明显技术深度
3. AI营销主张：竞品如何定位其AI能力？
4. 已知AI合作伙伴或模型提供商（如公开披露）
5. AI相关招聘信息作为能力投资方向的信号

编制成结构化库存表：
| 竞品 | 功能名称 | AI能力类型 | 发布日期 | 技术深度 | 备注 |

总结：
- 哪个竞品的AI功能覆盖最广？
- 哪个竞品的AI技术投入看起来最深？
- 哪些AI能力出现在3个以上竞品中而我们尚未拥有？

输出：竞品AI功能库存表 + 竞争摘要 + 差距初步识别

提示词2 — AI能力差距矩阵

构建将我们产品与竞品对比的AI能力差距矩阵。

我们产品的AI功能：[列出所有AI功能并简要描述]
竞品功能（来自库存）：[引用你的库存或粘贴]
能力分类法：[列出与你产品相关的能力类别，如文档分析、内容生成、搜索、推荐、自动化等]

对每个能力类别评估：
- 我们的产品：无/基础/高级/行业领先
- 竞品A：[同等级别]
- 竞品B：[同等级别]
- [继续所有竞品]

生成：
1. 差距矩阵：显示我们在每个能力中相对每个竞品位置的视觉表格
2. 同等差距：竞品处于同等或领先地位的能力——必须弥合才能保持竞争力
3. 优势区域：我们领先的能力——必须保护和传达
4. 空白区域：没有竞品强势的AI能力类别——潜在差异化机会
5. 优先排序：哪些差距对竞争赢/输影响最大？

输出：能力差距矩阵 + 差距优先级排序 + 空白分析

提示词3 — 竞争说明卡生成器

为以下竞争情况生成供销售团队使用的AI功能竞争说明卡。

我们的产品：[名称和描述，包含关键AI功能]
竞品：[竞品名称及其关键AI功能]
常见竞争场景（来自销售团队输入）：[描述3–5个此竞品出现的场景]

生成涵盖以下内容的说明卡：

1. 我们如何赢：我们相对此竞品的前3个AI能力优势及具体示例
2. 他们的竞争之处：他们与我们相当的AI能力（诚实评估）
3. 他们声称的优势：他们向客户说了什么 + 我们对每项声明的准确回应
4. 他们领先的地方：当前他们AI能力更强的2–3个领域 + 我们的响应策略（路线图/重新定位/承认并转移话题）
5. 资格问题：能揭示我们优势和他们弱点的问题
6. 证明点：展示我们AI质量优势的具体示例、基准结果或客户参考

格式：适合销售团队快速参考的简洁说明卡（相当于1页）

输出：每个竞品的说明卡 + 三大竞争场景的谈话要点

提示词4 — 竞品AI功能深度分析

对以下竞品AI功能进行技术深度分析。

竞品：[名称]
要分析的功能：[功能名称和描述]
可用信息来源：[产品测试观察/博客文章/招聘信息/会议演讲/专利申请]

分析：
1. 功能评估：根据你的测试，此功能实际上做什么？在边缘案例上表现如何？
2. 技术实现假设：根据行为特征，底层方法可能是什么？（通用API/微调模型/专有模型/RAG/智能体/其他）
3. 质量基准：在与我们用例相关的[N]个标准化任务上测试该功能，为每个任务评分
4. 投入信号：公开信息（招聘、博客、演讲）告诉我们此功能背后投入深度如何？
5. 复制评估：复制这一能力需要什么？时间、算力、数据和工程要求
6. 差异化机会：我们可以做什么不同之处，使我们版本的这一能力具有独特优势？

输出：技术深度分析报告 + 质量基准结果 + 竞争响应建议

提示词5 — 季度竞争AI报告

为以下产品团队生成季度竞争AI格局报告。

报告季度：[Q和年份]
我们的产品：[名称]
竞品集：[列表]
主要受众：[产品领导/高管团队/董事会]

构建报告：

1. 执行摘要（1页）：本季度前3个竞争AI进展及其战略影响

2. 竞品AI发布摘要：每个竞品本季度发布的新AI功能及简要描述

3. 能力差距更新：与上季度相比我们竞争地位的变化（差距已弥合/新差距出现/优势保持或丧失）

4. 竞争赢/输AI分析：销售和CS反馈告诉我们本季度AI能力在赢/输中扮演了什么角色？

5. 新兴竞争威胁：竞品正在暗示构建的AI能力（招聘信息、会议演讲、测试版发布）

6. 路线图对齐检查：我们计划的AI投资是否针对了影响最大的竞争差距？

7. 推荐行动：下季度前3个竞争情报驱动的行动

输出：季度竞争报告 + 推荐行动 + 下季度竞争监控计划

18. AI数据集标注质量控制审查员

为AI训练数据集设计和实施标注质量控制项目——标注者间一致性测量、系统性错误检测和指南精化，最大化训练数据价值。

痛点与解决方案

痛点：标注质量悄然下滑，最终演变为模型性能问题

负责监督学习或基于RLHF模型改进项目的AI产品经理，面临一种在为时已晚之前容易被忽视的质量管理挑战：标注质量以在系统监控工具不可见的方式随时间下滑。在校准期和项目第一周表现良好的标注者会逐渐产生偏移——对模糊案例的解释发生变化，疲劳导致在复杂样本上走捷径，没有持续的质量反馈，标注者会为越来越偏离的标签决定自我辩解。当10,000个标注的批次完成时，实际质量可能比校准阶段表明的低15–20%，创造出系统性编码标注者演化启发式方法的训练数据，而非模型需要的真实标签。

标注者间一致性问题对于复杂AI标注任务尤其棘手，如RLHF的偏好数据、多维度质量评分或细致的安全分类。与简单二元分类任务（标注者困惑立即显现）不同，复杂标注任务在简单样本上可能显示出高一致性，而在困难边缘案例上却一致性极差——恰恰是对模型训练最有信息价值的案例。87%整体标注者间一致性的数据集在模型最需要学习的困难样本上可能只有52%的一致性，而平均一致性统计数据不会揭示这个问题。

指南不足问题制造了第三种质量失败模式。大多数标注项目从在遇到真实数据全部多样性之前编写的指南开始。随着标注推进，标注者遇到指南没有明确覆盖的案例——如果没有系统性流程来识别和解决这些差距，个别标注者会发展出自己的私人解释，与团队的指南产生分歧。结果是一份对简单案例覆盖良好、对困难案例覆盖欠佳的指南文档，创造出最重要训练样本标注最不一致的数据集。

COCO如何解决

1. 标注指南设计与压力测试：COCO构建全面的标注规范：

   • 制定详细的任务指南，包含边缘案例解决的明确决策树
   • 生成指南压力测试：一组故意模糊的样本，旨在探测指南漏洞
   • 识别标注者最可能产生分歧的决策点并添加明确的解决规则
   • 创建标注者校准测验，测量标注者是否正确内化了指南
   • 设计动态指南更新流程，将标注过程中发现的边缘案例解决方案纳入其中

2. 标注者间一致性测量与分析：COCO量化标注一致性：

   • 根据任务类型计算适当的一致性统计量：二元/分类任务用Cohen's Kappa，顺序/连续任务用Krippendorff's Alpha，多类任务用百分比一致性
   • 区分整体一致性与对训练最重要的困难样本上的一致性
   • 识别系统性标注者偏差：在特定标签类别上持续偏离共识的标注者
   • 按样本难度分析一致性，并标记低一致性样本进行裁决
   • 生成区分随机错误与系统性偏差的标注者表现报告

3. 质量控制抽样策略：COCO设计高效的质量监控：

   • 设计黄金标准注入协议：将专家标记的隐藏样本插入标注者队列进行持续质量监控
   • 计算在所需灵敏度下检测质量下滑所需的最低黄金标准抽样率
   • 设计分层抽样，确保质量监控覆盖所有任务类别和难度级别
   • 推荐审查节奏：高风险项目每日质量报告，标准项目每周
   • 创建触发器：哪些质量指标阈值需要立即进行标注者辅导或任务暂停

4. 系统性错误模式检测：COCO识别质量问题的根因：

   • 分析错误模式，区分标注指南漏洞、标注者技能差距与任务复杂性问题
   • 识别具有持续低质量的特定标签类别或样本类型
   • 检测标注者疲劳特征：与时间或连续任务数量相关的质量下滑
   • 发现多个标注者犯同样错误的样本，表明系统性指南歧义
   • 生成包含每种错误类型具体修复建议的根因报告

5. 标注裁决工作流：COCO管理争议解决：

   • 为低一致性样本设计裁决流程：专家审查、委员会决定或从训练中排除
   • 创建显示标注者标签、分歧和上下文以供专家审查的裁决界面规范
   • 按对模型训练的影响优先处理裁决队列：高频用例的样本优先
   • 将裁决决定记录为未来标注任务的指南更新材料
   • 跟踪裁决积压及其对训练数据可用性时间线的潜在影响

6. 数据集质量评分卡与训练就绪认证：COCO将训练与数据质量挂钩：

   • 生成涵盖一致性率、错误率、覆盖率和平衡性的数据集质量评分卡
   • 定义使用数据集进行训练前必须满足的最低质量阈值
   • 认证训练就绪子集：即使完整数据集不通过，通过质量阈值的部分数据
   • 推荐数据选择策略：根据质量决定包含/排除哪些标注者的数据
   • 生成法规合规和模型文档要求所需的数据质量审计跟踪

量化结果与受益角色

可量化的成果

• 训练数据质量提升：系统性标注质控项目将复杂标注任务的有效标注者间一致性从通常未监控基线的68–74%提升至84–91%
• 数据质量带来的模型性能提升：机器学习团队报告，在使用相同数据量时，从未监控转向质控监控的标注流水线使评估基准上的模型性能提升12–24%
• 标注者漂移检测速度：黄金标准注入协议比批次结束质量审计平均提前18天检测到标注者质量下滑
• 指南漏洞解决：系统性压力测试在标注开始前识别**85%**的标注指南漏洞，减少项目中期指南修订和追溯性重新标注
• 裁决效率：结构化裁决工作流处理分歧解决的速度比临时专家审查快3.1倍，减少训练数据可用性的裁决瓶颈

受益人群

• AI产品经理：确保在标注工作上的投资产出真正改善模型质量的训练数据，而非在训练运行失败后才发现数据质量问题
• 机器学习工程师和数据科学家：获得有记录质量指标且无缺陷认证的训练数据集，而非在训练或模型评估期间发现数据问题
• 标注团队和管理者：在提供定期反馈、实现主动质量维护并及早揭示系统性问题的清晰质量管理框架内运作
• 法律和合规团队：获得满足训练数据来源和质量保证AI治理要求的标注质量文档

💡 实用提示词

提示词1 — 标注指南压力测试生成器

在标注开始前生成以下标注指南的压力测试以识别漏洞。

任务类型：[分类/偏好排序/质量评分/命名实体识别/其他]
标注指南摘要：[描述关键规则和决策标准]
标签集：[列出所有标签及其定义]

生成30个旨在探测指南弱点的压力测试样本：
- 10个测试相邻标签类别之间边界条件的样本
- 10个在当前指南下可能有多种解释的样本
- 5个代表罕见但重要边缘案例的样本
- 5个旨在测试标注者是否会将频繁/简单的标签应用于罕见/困难案例的样本

对每个压力测试样本：
- 样本文本或描述
- 为什么它模糊或有挑战性
- 当前指南下预期的正确标签
- 标注者最可能选择的错误标签及原因
- 确保此类型一致标注所需的指南说明

输出：压力测试集 + 指南漏洞分析 + 每个已识别漏洞的建议补充

提示词2 — 标注者间一致性分析

分析以下标注项目的标注者间一致性。

任务：[描述标注任务]
标签集：[列出标签]
一致性数据（提供）：
- 多标注样本总数：[N]
- 一致性矩阵或原始标注数据：[粘贴数据]

标注者：[列出标注者ID]
可用黄金标准数据：[N个专家验证标签的样本]

计算并分析：
1. 整体一致性率和此任务类型的适当一致性统计量（Kappa/Alpha）
2. 按标签类别的一致性：哪些标签一致性低？
3. 标注者相对黄金标准的个人表现：哪些标注者与专家标签偏差最大？
4. 按样本难度的一致性（如难度可测量）：一致性如何随任务复杂度变化？
5. 系统性偏差检测：是否有标注者对特定标签显示出一致性偏向或偏离？
6. 行动阈值：标记任何需要立即干预的标注者或标签类别

输出：一致性分析报告 + 标注者表现表格 + 低一致性案例的推荐干预措施

提示词3 — 标注质量控制仪表板设计

为持续进行的标注项目设计质量控制仪表板。

项目：[描述标注任务和规模]
标注团队：[标注者数量，其设置——众包/内部/供应商]
项目时间线：[总周数，当前周数]
当前产出：[迄今标注样本数，目标总数]
现有质量监控：[描述当前已有的内容]

设计具有以下面板的质控仪表板：

日常监控指标：
- 每个标注者的黄金标准准确率（每日更新）
- 每个标注者每天的产出量
- 标记样本率（发送审查/裁决的样本）

每周趋势指标：
- 整个项目周期的一致性率趋势
- 标注者质量趋势（特定标注者是在改进还是下滑？）
- 标签分布趋势（标签频率是否偏离预期分布？）

异常告警：
- 标注者准确率降至[X]%以下
- 标签分布偏移超过[X]%
- 产出量超过合理最大值（速度欺诈指标）

对每项指标：定义测量方法、数据来源、告警阈值和推荐行动

输出：仪表板规范 + 告警规则 + 每周质控审查议程模板

提示词4 — 标注错误根因分析

对以下项目中的标注质量问题进行根因分析。

任务：[描述标注任务]
观察到的质量问题：[描述质量问题——低一致性/系统性错误/标注者漂移]

错误数据（粘贴代表性的不正确或不一致标注示例）：
示例1：输入：[文本]，标注者A标签：[X]，标注者B标签：[Y]，专家标签：[Z]
示例2：[同格式]
[继续10–15个示例]

标注者反馈（如可获取）：[粘贴任何标注者问题或困惑信号]

分析：
1. 错误模式：错误是随机的还是系统性的？是否围绕特定样本类型聚集？
2. 根因分类：指南漏洞/标注者技能差距/任务设计问题/源材料数据质量问题
3. 指南漏洞分析：对于系统性错误，哪些指南补充可以防止错误？
4. 标注者技能差距分析：哪些标注者的错误表明他们需要在特定概念上重新培训？
5. 修复计划：每个根因的具体行动及预期质量改善
6. 追溯纠正：对于系统性错误，是否可以以编程方式识别和纠正错误标注的样本？

输出：根因分析报告 + 修复计划 + 指南修订建议 + 可追溯纠正错误的估计

提示词5 — 训练数据就绪认证

为以下标注数据集生成训练数据就绪认证。

数据集：[名称和描述]
标注任务：[标注了什么]
总样本数：[N]
标注方法：[单标注者/多标注者/专家裁决]

质量指标（提供你的测量结果）：
- 整体标注者间一致性：[分数]
- 按标签类别的一致性：[表格]
- 黄金标准准确率：[分数]
- 标签分布：[表格]
- 已裁决样本比例：[%]
- 裁决解决率：[%]

预期模型训练用途：[哪个模型将使用此数据进行训练]
定义的最低质量标准：[列出你的验收阈值]

生成认证报告：
1. 总体就绪评估：已认证/有条件认证/未认证
2. 逐质量维度评估，附对标准的通过/失败判断
3. 已知局限性：未达到认证阈值但对预期用途可接受的质量问题
4. 使用限制：此数据在训练中应该或不应该如何使用的任何条件
5. 推荐监控：训练后运行的质量检查，以验证此数据集没有引入意外的模型行为
6. 认证签字：谁审查并批准了此数据集用于训练

输出：完整填写所有部分的正式训练数据就绪认证文件

19. AI产品监管合规清单

生成AI产品的司法管辖区特定、用例特定监管合规清单——覆盖《欧盟AI法案》、美国行业法规、数据保护法和新兴AI立法。

痛点与解决方案

痛点：AI监管要求复杂、因司法管辖区而异，且快速演变

构建将在受监管市场部署产品的AI产品经理，面临比以往任何技术监管环境都更复杂、更重大、变化更快的合规格局。《欧盟AI法案》——全球首部全面AI法规——引入基于风险分级的合规框架，根据用例分类对文档、风险管理、数据治理、透明度、人工监督和准确性施加不同义务。美国联邦机构正在积极为医疗（FDA）、金融服务（CFPB、OCC）、就业（EEOC）和住房（HUD）开发特定行业AI指导，在两年前没有明确框架的领域创造合规义务。英国、加拿大、新加坡、澳大利亚和日本的行业监管机构正在独立开发自己的要求。在同时管理产品路线图的情况下手动跟踪所有这些信息的PM正在进行一场必败之战。

分类挑战制造了第一个合规陷阱。许多AI PM认为，由于他们正在构建有用的生产力工具，其产品风险低，适用的合规要求很少。《欧盟AI法案》的高风险类别比大多数人预期的更广泛：用于就业决策、教育评估、信用评分、执法、健康安全和获取基本服务的AI系统，无论具体实施看起来多么良性，都被归类为高风险。用于起草绩效评估的AI写作助手是用于就业决策的AI系统。总结贷款申请文件的AI工具与信用评分相邻。没有主动调查其用例监管分类的团队，往往在架构决策已经做出后才发现合规义务——这使合规复杂化。

文档要求问题制造了第二个合规陷阱。即使团队了解其用例有合规义务，他们也经常低估所需文档的具体性和负担。《欧盟AI法案》要求的技术文档涵盖系统目的、使用的数据、执行的测试、已实施的风险管理措施和人工监督机制——这些文档必须维护，在每次重大变更时更新，并可供监管检查。大多数团队尚未建立在快速开发周期中维护如此具体文档所需的工作流程和习惯。"我们理解要求"与"我们有合规级文档"之间的差距，比大多数AI PM预期的要大。

COCO如何解决

1. 用例监管分类引擎：COCO确定哪些法规适用：

   • 将产品的具体用例映射到《欧盟AI法案》禁止、高风险、有限风险和最低风险类别
   • 按行业和用例识别适用的美国联邦机构AI指导
   • 评估数据保护法规的适用性：GDPR、CCPA和特定行业隐私框架
   • 确定产品是否符合具有额外义务的通用AI模型资格
   • 生成监管适用矩阵：哪些法规适用、在什么层级、原因是什么

2. 司法管辖区特定合规清单生成：COCO创建可行的合规要求：

   • 为每个适用法规生成含具体可行项的清单
   • 区分部署前要求（发布前必须满足）与持续要求（发布后必须维护）
   • 识别当前已满足的合规项 vs. 需要工作的差距
   • 将每个清单项的所有权分配给适当团队：工程、法律、产品、运营
   • 估计每个合规差距的实施工作量

3. 技术文档要求规范：COCO识别所需的文档工件：

   • 为每个适用监管框架规定所需的技术文档
   • 为每个所需文档生成模板：技术文档、风险管理记录、准确性测试报告
   • 识别哪些文档必须公开披露 vs. 仅为监管检查而维护
   • 设计与产品开发周期对齐的文档更新流程
   • 创建文档治理流程：谁拥有每份文档、审查周期、版本控制

4. 人工监督和控制要求设计：COCO指定监督机制：

   • 识别哪些监管框架要求人工监督以及涉及程度
   • 为特定用例和风险级别设计适当的人工审查工作流
   • 规定人工监督活动的审计日志要求
   • 解决可解释性要求：受影响个人必须获得哪些AI决策解释
   • 为影响个人的高风险用例创建申诉权机制设计

5. 合规时间线和执法就绪：COCO绘制监管生效日期：

   • 跟踪每个适用法规的执法时间线：要求何时生效？
   • 创建与监管生效日期挂钩的里程碑合规路线图
   • 识别需要立即关注的条款 vs. 有实施余地的条款
   • 标记需要法律解释才能开始实施的条款
   • 生成仍在制定或咨询阶段条款的监管关注清单

6. 企业客户合规支持：COCO为客户合规询问做准备：

   • 生成企业采购常见AI合规问卷的标准答复
   • 创建合规证明包：应要求与企业客户共享哪些文档
   • 设计涵盖AI特定数据处理的数据处理协议（DPA）补充条款
   • 生成向受影响用户披露AI使用的透明度报告模板
   • 构建记录已完成认证和评估的监管认证登记册

量化结果与受益角色

可量化的成果

• 监管差距发现速度：结构化监管分类和清单分析比仅依赖法律顾问进行持续监管监控的团队提前8–12周识别合规差距
• 欧盟AI法案就绪性：完成结构化欧盟AI法案评估的团队在执法日期前合规的可能性比知道法规但未进行正式差距分析的团队高74%
• 企业采购合规通过率：拥有有据可查AI合规项目的产品首次提交企业AI安全和合规审查的通过率高3.4倍
• 监管文档完整性：模板驱动的文档项目实现所需文档完整性92%，而追溯式合规记录的团队为38%
• 监管响应时间：拥有维护合规文档的组织在2周内响应监管信息请求，而从头组装文档的团队需要8–16周

受益人群

• AI产品经理：有信心地驾驭监管格局，确保合规要求已系统性评估和处理，而非留下未识别的差距
• 法律和合规团队：将专家法律注意力集中在解释和战略上，而非为每个新产品从头构建合规清单
• 工程团队：收到可转化为具体实施任务的特定技术合规要求，而非模糊的法律指令
• 企业客户：在进行AI供应商尽职调查时，可获得合规项目成熟度的有据可查证明

💡 实用提示词

提示词1 — AI监管分类评估

对以下AI系统进行适用监管框架分类。

AI系统描述：[系统功能的详细描述]
部署司法管辖区：[列出产品将使用的所有国家/地区]
最终用户：[谁使用系统——消费者/企业/员工/政府]
决策或输出：[AI做出或支持哪些决策？其输出影响什么？]
受影响个人：[谁受到AI输出的影响，即使不是直接用户]
处理的数据：[AI接收和处理的数据类型]

在每个适用框架下分类：

《欧盟AI法案》：
- 禁止行为检查：此系统是否属于第5条禁止AI行为？
- 高风险分类检查：是否属于附录III？哪个具体类别？
- 通用AI检查：此系统是否符合法案下的GPAI资格？
- 有限风险检查：此系统是否有第50条下的透明度义务？

美国行业法规：
- 医疗/FDA AI指导适用性
- 金融服务监管适用性（CFPB、OCC、FDIC、SEC）
- 就业AI适用性（EEOC、州级要求）
- 住房AI适用性（HUD、公平住房法）

数据保护：
- GDPR适用性及处理法律依据
- CCPA/CPRA适用性
- 行业特定隐私法规

输出：监管适用矩阵 + 风险分类理由 + 即时合规优先清单

提示词2 — 欧盟AI法案合规清单

为以下高风险AI系统生成详细的欧盟AI法案合规清单。

系统：[名称和描述]
高风险类别：[适用哪个附录III类别]
部署日期：[计划日期]
欧盟市场：[哪些欧盟成员国]

按AI法案章节生成合规清单：

风险管理系统（第9条）：
[生成8个含验证标准的具体合规项]

数据和数据治理（第10条）：
[生成7个具体合规项]

技术文档（第11条）：
[生成8个规定所需文档内容的具体合规项]

记录保存和日志（第12条）：
[生成5个具体合规项]

透明度和用户信息（第13条）：
[生成6个具体合规项]

人工监督（第14条）：
[生成6个具体合规项]

准确性、稳健性和网络安全（第15条）：
[生成5个具体合规项]

合格评定（第43-44条）：
[生成4个具体合规项]

对每个项目：当前状态（合规/差距/未知）、负责人和实施截止日期。

输出：欧盟AI法案合规清单 + 差距分析 + 附条款引用的实施路线图

提示词3 — AI透明度披露包

为以下AI产品创建面向用户的AI透明度披露。

产品：[名称和描述]
AI功能：[列出所有AI驱动功能]
司法管辖区：[用户所在地——这影响披露要求]
为AI收集和使用的数据：[描述]
自动化决策（如有）：[描述影响用户的任何自动化决策]
人工监督：[描述AI输出的任何人工审查]

为以下位置生成披露内容：

1. 产品页面/营销披露（简短）：[2–3句话解释AI使用而不损害产品吸引力]

2. 产品内披露（在AI交互时）：[用户与AI功能交互时看到的1–2句话]

3. 隐私政策AI部分：[300字章节，解释AI数据使用、模型训练、自动化决策]

4. AI使用政策文件（企业客户）：[全面披露所有AI能力、数据使用、限制和治理]

5. 解释权响应模板：[回应用户请求解释AI决策的模板——某些用例在欧盟AI法案和GDPR下必须提供]

6. 退出选项：[用户可以退出哪些AI功能以及如何退出]

确保所有披露准确、具有法律可辩护性，并以通俗语言为所述用户受众撰写。

输出：完整透明度披露包 + 每个披露位置的实施指南

提示词4 — 行业特定AI合规清单

为在[医疗/金融服务/人力资源/教育——选一个]中部署以下AI系统生成合规清单。

AI系统：[描述]
具体用例：[如临床决策支持/贷款申请审查/简历筛选/学生评估]
司法管辖区：[美国/欧盟/英国/特定州或国家]
具有权力的监管机构：[列出适用监管机构]

生成涵盖以下内容的合规清单：

[医疗领域]：
- FDA AI/ML医疗设备软件（SaMD）指导
- AI系统的HIPAA技术保障
- 临床验证要求
- 临床AI的人工监督要求

[金融服务领域]：
- CFPB关于信用决策中AI的指导
- ECOA/公平贷款考虑
- AI知情决策的不利行动通知要求
- 模型风险管理指导（SR 11-7）

[人力资源/就业领域]：
- EEOC关于招聘中AI的指导
- 纽约市144号法（如适用）
- 伊利诺伊州AI视频面试法（如适用）
- 州级AI就业披露要求

[教育领域]：
- FERPA数据隐私要求
- 无障碍要求（ADA、第508条）
- 州学生隐私法
- 教育评估中的算法公平性

对每个项目：具体要求、证明合规的证据、实施行动和优先级。

输出：行业特定合规清单 + 监管参考列表 + 优先合规行动计划

提示词5 — 企业客户AI合规包

为以下AI产品创建企业客户AI合规证明包。

产品：[名称和描述]
常见企业客户行业：[企业客户的行业——影响其合规关注点]
来自企业采购的常见合规问题：[列出销售团队通常收到的问题]

生成合规包：

1. AI产品安全和合规概述（2页摘要）：
   - AI架构和数据流
   - 已完成的认证和评估
   - 数据处理和隐私保护
   - AI组件特定的安全控制

2. 标准AI合规问卷答复：
   - 对每个常见企业采购问题：完整、准确且经法律审查的答复
   [为企业采购中10个常见AI合规问题生成答复]

3. 关键AI功能的模型卡：
   - 对每个主要AI功能：涵盖预期用途、训练数据、已知限制、性能指标和偏差测试结果的模型卡

4. 数据处理协议AI补充条款：
   - AI数据使用、训练数据实践、AI输出存储和子处理方AI使用的具体条款

5. AI事件通知承诺：
   - 什么构成企业客户的可报告AI事件
   - 通知时间线和联系信息
   - 修复承诺语言

输出：完整企业合规包 + 不同企业客户行业的定制指南

20. AI客户反馈闭环自动化引擎

将非结构化客户信号在数小时内转化为优先排序的产品决策，而非数周。

痛点与解决方案

痛点：淹没在反馈中，却提取不出可行信号

AI产品经理面临来自支持工单、应用商店评论、NPS调查、应用内反馈组件、社交提及、销售通话记录和社区论坛的海量客户反馈洪流。一个拥有5万月活用户的典型AI产品每周产生数千条反馈信号，但大多数产品团队只能手动审查其中一小部分——往往偏向最响亮或最近的声音，而非最具代表性或战略重要性的声音。

对于AI产品而言，风险尤其高，因为用户不满往往源于模型行为问题——幻觉、不一致的输出、意外的拒绝或延迟尖峰——这些需要与传统软件缺陷根本不同的修复方式。当这些信号没有被快速捕获和路由时，模型质量问题在生产中持续存在，侵蚀信任并在对产品采用影响最大的核心用户中增加流失。

闭合反馈闭环需要跨职能协调：处理工单的支持团队、调查模型行为的数据科学家、修复推理流水线的工程师，以及将规律综合为路线图决策的PM。没有自动聚合和智能路由，从客户投诉到AI特定问题修复发布的平均时间超过30天——在每周模型改进是常态的竞争AI产品市场中，这是永恒。

COCO如何解决

1. 多源反馈聚合：COCO将所有渠道的反馈整合为统一分析流：

   • 解析支持工单文本，提取AI特定投诉类别（幻觉、拒绝、延迟、准确性）
   • 处理带版本标记的应用商店评论情感，将反馈与特定模型发布关联
   • 分析NPS文字内容，将AI功能投诉与一般产品不满区分开来
   • 摄入销售通话记录，揭示阻碍企业交易的异议模式
   • 监控社区论坛和社交提及，在问题达到支持量级前识别新兴问题集群

2. AI特定分类法分类：COCO应用专为AI产品反馈构建的结构化分类法：

   • 在以下维度对每条反馈进行分类：模型质量、提示词敏感性、输出一致性、延迟/可靠性和功能范围
   • 区分用户期望错位（UX/沟通问题）和需要工程干预的真实模型故障
   • 按用户细分（核心用户、普通用户、企业账户）标记反馈，正确加权优先排序
   • 识别表明竞争脆弱性的反馈——用户明确提到切换到替代产品的功能
   • 标记安全相邻反馈（偏见报告、有害输出担忧），立即在正常分类队列外升级

3. 规律检测与趋势告警：COCO在关键量级前识别新兴问题：

   • 使用基于嵌入的相似性对语义相似反馈进行聚类，发现问题族而非关键词匹配
   • 计算反馈速度——在滚动7天/30天窗口内的增长率——以检测加速问题
   • 将反馈尖峰与模型部署、提示词变更和基础设施事件关联，建立因果关系
   • 在任何问题集群超过可配置量级或速度阈值时生成自动告警
   • 生成将当前期与先前期对比的含统计显著性标记的每周趋势报告

4. 优先排序评分与路线图整合：COCO将原始信号转化为排序的行动项：

   • 按影响（受影响用户数 × 账户收入权重 × 流失风险）、紧迫性（趋势速度）和可修复性（估计工程复杂度）对每个问题集群评分
   • 生成JIRA/Linear就绪工单，附预填写描述、受影响用户数、代表性反馈样本和建议负责人分配
   • 将反馈集群映射到现有路线图项以发现冲突（被降优先级但有增长用户需求的项目）
   • 生成准备好作为冲刺规划输入的每周"前10条反馈行动"排序列表
   • 提供基于历史修复到满意度相关性估算NPS影响和流失减少的"如果我们修复这个"预测

5. 客户响应模板生成：COCO大规模起草个性化响应：

   • 为按问题类型分类的支持工单生成有共情、技术准确的响应
   • 创建在承认AI局限性的同时强化产品价值的应用商店响应模板
   • 起草包含对具体投诉个性化确认的NPS跟进外联给差评者
   • 为企业客户在AI质量问题影响其用例时生成内部事件沟通草稿
   • 撰写强调针对高票反馈项修复的更新日志和发布说明

6. 闭合循环测量：COCO跟踪反馈驱动的变更是否真正解决了问题：

   • 监控已解决问题集群的修复后反馈量，以确认解决有效性
   • 跟踪在特定反馈类型的修复发布后，提交过该类反馈的用户群体的NPS变化
   • 生成显示哪些修复投资每工程天产生最高满意度改善的"反馈ROI"报告
   • 识别"僵尸问题"——被标记为已解决但在反馈中重新出现的问题——用于根因再调查
   • 生成将反馈解决速度与行业基准对比的季度反馈健康评分卡

量化结果与受益角色

可量化的成果

• 反馈到行动周期时间：高优先级AI质量问题从超过30天缩短至5天以内
• 反馈覆盖率：从约15%的手动审查提升至跨所有渠道100%的自动分类
• NPS改善：使用结构化反馈闭环的团队报告在实施后两个季度内NPS提升12–18分
• 支持工单偏转：通过早期反馈信号主动解决问题，使重复工单量减少35–45%
• 路线图对齐准确性：当路线图优先级由加权反馈数据而非直觉驱动时，产品市场契合度评分提升25%

受益人群

• AI产品经理：获得路线图优先排序的客观、数据驱动信号，而非依赖最响亮的利益相关者声音
• 客户成功团队：收到预分类的反馈队列和建议响应，将处理时间减少40%
• AI/ML工程师：获得附有用户反馈示例的精确可重现错误报告，加速根因诊断
• 高管领导：访问将产品质量指标与流失和NPS等业务结果关联的实时反馈健康仪表板

💡 实用提示词

提示词1 — 多源反馈综合

你是AI产品反馈分析师。将以下来自多个来源的客户反馈综合为结构化分析报告。

产品：[AI产品名称和主要用例]
反馈期：[日期范围]
用户群：[近似月活用户数和关键细分]

反馈来源：
- 支持工单（过去30天）：[粘贴前20–30个代表性工单或摘要统计]
- 应用商店评论（过去30天）：[粘贴近期评论或评分分布 + 样本文字]
- NPS调查文字（上季度）：[粘贴差评者和中立者的文字内容]
- 应用内反馈：[粘贴反馈组件提交内容]
- 社区/论坛提及：[粘贴相关帖子或摘要]

分析并生成：

1. 问题分类图：将所有反馈分类为：(a)模型质量问题，(b)输出一致性问题，(c)延迟/可靠性问题，(d)功能范围差距，(e)UX/期望错位，(f)安全/偏见担忧。对每个类别：数量、占总数%、前3个代表性文字内容。

2. 新兴趋势告警：识别与上一期相比量级增加>50%的问题集群，标记为需要立即关注。

3. 细分分析：按用户类型（核心用户、普通用户、企业）分解反馈。是否存在细分特定问题？

4. AI特定 vs. 通用软件问题：区分哪些问题需要模型/ML干预 vs. 标准工程修复。

5. 优先行动清单：按（受影响用户数 × 收入权重 × 趋势速度）排序的前10个问题。对每个：推荐负责人、估计修复复杂度（S/M/L）、修复后预计NPS影响。

输出格式：执行摘要（3条要点）+ 详细分类表格 + 附JIRA就绪描述的优先行动清单。

提示词2 — 反馈速度告警生成器

分析以下反馈趋势数据并生成需要立即关注的问题告警。

产品：[名称]
当前期：[周/月]
对比的上一期：[上一周/月]

按类别的反馈量：
当前期：
- [类别A]：[数量]
- [类别B]：[数量]
[继续所有类别]

上一期：
- [类别A]：[数量]
[继续]

近期部署事件：[列出该期内的任何模型更新、提示词变更、基础设施变更]

对每个量级增加>30%的类别：
1. 告警严重程度：严重（>100%增加或安全问题）/高（50–100%增加）/中（30–50%增加）
2. 因果假设：趋势是否与某个部署事件相关？最可能的根本原因是什么？
3. 代表性反馈样本：[从提供的数据中提取]
4. 推荐立即行动：工程调查/PM升级/客户沟通/仅监控
5. 草拟Slack告警消息：适合发布到#product-incidents或#model-quality频道的一段话

同时生成：
- 每周反馈健康评分卡：总体情感趋势、改善最多的问题、恶化最多的问题
- 下次冲刺建议：哪些问题有足够信号值得冲刺级投资？

提示词3 — 客户响应模板生成器

为以下AI产品反馈场景生成客户响应模板。

产品：[AI产品名称]
产品定位：[你向用户描述产品的方式]
已知AI局限性：[列出用户应了解的关键局限性]
当前模型版本：[版本/日期]

为每个场景生成响应模板：

场景1 — 幻觉投诉：
用户投诉："[粘贴关于错误/虚构输出的投诉示例]"
模板：确认问题，解释AI局限性而不损害信心，描述我们正在做什么改进，提供变通方法或后续步骤。

场景2 — 输出不一致投诉：
用户投诉："[粘贴关于相似问题得到不同答案的投诉示例]"
模板：确认，解释AI输出为何变化，引导用户使用能提升一致性的提示词策略。

场景3 — 延迟/性能投诉：
用户投诉："[粘贴关于响应时间慢的投诉示例]"
模板：确认体验，解释是否是已知问题或孤立事件，如可能提供改进时间线。

场景4 — 功能范围差距：
用户投诉："[粘贴用户请求产品没有的能力的投诉示例]"
模板：感谢反馈，承认差距，不承诺具体日期地解释我们如何考虑这个问题，邀请使用功能请求渠道。

场景5 — 应用商店2星评论（AI准确性）：
评论："[粘贴差评示例]"
模板：公开响应，确认、不防御、展示改进承诺、邀请直接联系。

场景6 — 企业客户升级（AI质量事件）：
问题："[粘贴影响企业客户的AI质量问题描述]"
模板：客户成功团队发送的正式事件沟通——包含发生了什么、影响、根本原因（如已知）、修复时间线和升级联系人。

对每个模板：提供响应 + 此场景的语气指南 + 应避免的词汇/短语

提示词4 — 反馈到路线图优先级映射

将以下客户反馈数据映射到产品路线图，识别优先级冲突和机会。

当前路线图（未来2个季度）：
[列出计划的功能/改进及其当前优先级排名和估计交付季度]

顶级反馈问题集群（来自分析）：
[列出前10–15个反馈主题，包含：问题名称、受影响用户数、收入加权影响评分、趋势方向]

对每个路线图项：
1. 反馈对齐：是否有直接支持此项的客户反馈？反馈量是多少？
2. 冲突检测：是否有被降优先级的路线图项现在收到了大量反馈需求？
3. 路线图中缺失：是否有顶级反馈问题完全未在路线图中呈现？

优先级调整建议：
- 需要加速的项目：[有强反馈顺风的路线图项——应前移]
- 需要降优先级的项目：[反馈信号弱的路线图项——考虑替换]
- 净新增项目：[不在路线图中但应添加的反馈问题]

生成：
1. 含推荐优先级变更的修订路线图 + 每项变更的理由（基于反馈数据）
2. 利益相关者沟通：一段解释优先级为何变化的话，适合工程全员会议
3. "我们听到了"更新日志：为每个反馈驱动的修复起草面向用户语言的发布说明文案

输出：优先级矩阵表格 + 推荐路线图变更 + 利益相关者沟通草稿

提示词5 — 闭合循环解决追踪器

评估近期产品修复在解决客户反馈问题上的有效性。

产品：[名称]
过去60天内发布的修复：
[对每个修复：描述、发布日期、它旨在解决的反馈问题、修复时受影响用户数]

修复后反馈数据：
[对每个修复：修复发布前后30天相关问题类别的反馈量]
[如可获取，前后NPS分数]
[前后支持工单量]

分析：

1. 解决有效性评分：对每个修复，计算：(修复前问题量 - 修复后问题量) / 修复前问题量。评分：>50%减少 = 已解决，20–50% = 部分解决，<20% = 无效。

2. 僵尸问题检测：哪些被标记为已解决的问题在最近2周内显示量级回升？

3. 反馈ROI计算：对每个已解决问题：（估计流失减少 × 平均客户LTV）/ 投入工程天数 = 反馈修复ROI。

4. 经验教训：对于无效修复——修复后的反馈说了什么？我们是否误诊了根本原因？修复是部分的吗？

5. 下一周期建议：基于哪些问题解决良好，是否有类似问题模式应该主动解决？

生成：解决有效性仪表板 + 僵尸问题告警列表 + 反馈ROI排序 + 给PM/工程复盘使用的经验教训备忘录

21. AI原生功能标志与实验平台

无需工程开销或部署风险，运行统计严谨的AI模型实验。

痛点与解决方案

痛点：在AI功能推出上盲目飞行

AI产品经理在推出新模型版本、提示词变更或AI功能变体时面临独特的危险挑战：与传统软件A/B测试已被充分理解不同，AI实验涉及非确定性输出、复杂质量指标和标准功能标志平台无法处理的故障模式。改善平均输出质量的提示词变更可能同时增加少数查询的幻觉率——这种权衡对简单的参与度指标不可见。

大多数团队默认采用大爆炸式模型部署或粗略的基于百分比的灰度发布，祈求预生产评估能转化为生产性能。当它不能的时候——当新模型版本导致2%的拒绝率增加或P99延迟回归15毫秒时——团队往往缺乏快速检测的仪表化，更遑论对特定用户细分进行外科式回滚，同时让其他用户保留新版本。

AI实验严谨性不足的代价随时间累积。无法进行干净实验的团队无法了解什么真正驱动其特定用例和用户群的模型质量改善。他们最终在没有验证这些改善是否在自己的生产上下文中成立的情况下，照搬模型提供商的通用基准改善，导致模型升级决策由营销而非证据驱动。

COCO如何解决

1. AI实验设计框架：COCO以适当的统计严谨性构建AI实验：

   • 定义含清晰AI特定成功指标的实验假设（幻觉率、任务完成率、输出偏好评分、P95/P99延迟）
   • 根据AI质量指标的预期效应量计算统计显著性所需的样本量
   • 设计分层随机化，确保实验组具有查询类型、用户细分和用例复杂度的平衡分布
   • 识别适当的护栏指标——必须不得降低的次要指标——以及主要优化指标
   • 生成实验预注册文件，防止事后分析中的p值操纵和指标挑选

2. 实验配置生成：COCO生成可直接实施的实验规范：

   • 为LaunchDarkly、Split.io、Flagsmith或自定义实现平台编写功能标志配置
   • 生成带版本标记、灰度百分比和目标规则的提示词变体规范
   • 创建模型路由逻辑：按用户细分、查询类型或账户层级服务模型A vs. 模型B的条件
   • 设计降级和熔断配置：当护栏指标违反阈值时的自动回滚触发器
   • 记录实验依赖关系和交互效应，防止并发实验之间的混淆

3. AI特定指标框架设计：COCO定义适合AI产品质量的测量方法：

   • 设计输出质量评分流水线：LLM-as-judge配置、人工偏好捕获、任务成功率测量
   • 创建延迟仪表化规范：仪表化位置、跟踪哪些百分位数、按查询类型的告警阈值
   • 为产品领域定义幻觉检测方法（事实准确性检查、引用验证、一致性测试）
   • 设计隐式反馈信号：点赞/踩位置、纠正行为跟踪、会话放弃分析
   • 将每次查询成本跟踪构建到实验分析中，为模型选择决策提供质量-成本权衡数据

4. 实验分析与解读：COCO对实验结果进行统计合理的分析：

   • 对AI指标进行适当的显著性测试（包括处理延迟和质量评分数据中常见的非正态分布）
   • 识别异质性处理效应——处理在与平均值显著不同的子群体
   • 检测会夸大短期指标的新奇效应，并建议避免过早结论的最短实验持续时间
   • 生成显示结论如何随指标重要性权重假设变化的敏感性分析
   • 生成含清晰发布/不发布/迭代建议及推理链的实验结果备忘录

5. 多臂赌博机与自适应灰度规划：COCO设计动态分配策略：

   • 为严格A/B效率低下时的持续优化配置基于汤普森采样或UCB的赌博机算法
   • 设计阶段性灰度门控：从1% → 5% → 20% → 100%灰度前必须满足的自动标准
   • 创建伴随模型升级的基础设施变更的金丝雀部署规范
   • 设计用户细分特定的灰度序列：企业客户最后，核心用户优先，每阶段不同成功标准
   • 生成回滚手册：不同回滚场景的分步程序及所有权分配

6. 实验组合管理：COCO跟踪和协调完整实验项目：

   • 维护记录所有运行中、计划中和已完成实验及交互分析的实验注册表
   • 识别实验冲突：覆盖重叠用户群的并发测试，可能混淆结果
   • 基于战略重要性、预期学习价值和资源要求对实验队列优先排序
   • 生成实验速度指标：每季度完成的实验数、发布率、平均学习周期时间
   • 生成识别哪些假设被证明正确并更新产品团队心智模型的实验复盘

量化结果与受益角色

可量化的成果

• 实验速度：拥有结构化AI实验框架的团队每季度运行比临时方法多3–4倍的实验
• 部署事件率：带自动护栏监控的阶段性灰度将生产AI质量事件减少60–70%
• 决策置信度：实验驱动的模型升级决策将部署后回滚减少45%，相比基准驱动的决策
• 延迟回归检测：自动化P99监控在2小时内检测到延迟回归，而手动检测需要2–3天
• 成本优化：系统性的成本-质量权衡实验在不降低质量的情况下识别出**20–35%**的推理成本削减机会

受益人群

• AI产品经理：获得模型和功能灰度决策的基于证据的决策制定，用数据替代直觉
• 机器学习工程师：收到清晰的实验规范和分析框架，将实验准备时间减少50%
• 平台/基础设施团队：获得自动回滚触发器和金丝雀部署规范，减少模型部署期间的待命负担
• 业务利益相关者：访问将AI质量改善与业务指标关联的清晰实验结果摘要

💡 实用提示词

提示词1 — AI实验设计文件

设计一个严谨的实验来测试以下AI产品变更。

产品：[名称和主要用例]
提议的变更：[描述你想测试的模型版本更新、提示词变更或AI功能修改]
当前基线指标：[列出关键指标的当前值：任务完成率、用户满意度评分、P50/P95/P99延迟、幻觉率（如已测量）、每次查询成本]
用户群：[月活用户数、关键细分、典型查询分布]
工程约束：[实验基础设施、流量分割能力、日志记录的任何约束]

设计实验：

1. 假设：以"如果我们[变更]，那么[指标]将因[机制]而[方向]变化[幅度]"的形式陈述因果假设。

2. 主要指标：此实验旨在优化的单一指标。精确定义它（如何测量，"成功"是什么样子）。

3. 护栏指标：必须不得降低的指标。对每个：可接受阈值，以及如果违反触发什么自动行动。

4. 样本量计算：给定基线指标值、最小可检测效应（什么程度的改善值得发布）和期望统计功效（80%或95%），计算所需样本量和实验持续时间。

5. 随机化设计：用户/请求如何被分配到对照/处理组？需要什么分层？

6. 实验持续时间：考虑每周季节性、新奇效应和样本量要求的最短运行时间。

7. 分析计划：将使用什么统计测试？如何调查异质性处理效应？

8. 发布标准：什么结果会触发发布决策 vs. 不发布 vs. 迭代决策？

输出：预注册格式的实验设计文件 + 工程实施清单

提示词2 — 功能标志配置生成器

为以下AI实验生成功能标志配置。

平台：[LaunchDarkly/Split.io/Flagsmith/自定义——指定]
实验名称：[名称]
变体：
- 对照：[描述——如当前模型版本、当前提示词]
- 处理A：[描述]
- 处理B（如适用）：[描述]

目标规则：
- 排除细分：[如企业账户、内部用户]
- 包含细分：[如仅限美国/欧盟的免费层用户]
- 灰度百分比：[如符合资格用户的10%]

生成：

1. 功能标志模式：完整的适用于[平台]的JSON/YAML格式标志配置，包含变体定义、目标规则和百分比分配。

2. 实验元数据标签：附加到此实验中所有事件的标签（实验ID、变体、用户细分、查询类别）。

3. 日志记录规范：每个实验组必须记录的事件，附精确事件模式（事件名称、属性、时间戳要求）。

4. 护栏监控配置：[你的监控平台]告警规则，当护栏指标在实验期间违反阈值时触发。

5. 回滚程序：执行紧急回滚的分步标志配置变更，附验证回滚生效的步骤。

6. 实验交互检查：列出触及相同用户群或模型路径的所有其他活跃功能标志——标记任何可能混淆此实验的标志。

输出：完整实施包含可直接粘贴的配置 + 交互检查清单

提示词3 — AI实验结果分析

分析以下AI实验结果并提供发布/不发布建议。

实验：[名称和假设]
持续时间：[运行日期]
样本量：对照组：[n]，处理组：[n]

结果：
主要指标（[指标名称]）：
- 对照组：[均值 ± 标准差或置信区间]
- 处理组：[均值 ± 标准差或置信区间]
- 相对变化：[%]
- 统计显著性：p = [值]，置信区间：[范围]

护栏指标：
- [指标1]：对照组[值] → 处理组[值]（[%变化]，p=[值]）
- [指标2]：对照组[值] → 处理组[值]（[%变化]，p=[值]）
[继续所有护栏指标]

细分分解（如可获取）：
- [细分A]：对照组[值] → 处理组[值]
- [细分B]：对照组[值] → 处理组[值]

执行：
1. 统计有效性检查：实验是否充分有效？是否有提前查看偏差或提前停止的迹象？
2. 护栏评估：是否有护栏指标违反阈值？如果是，主要指标改善是否足以证明权衡合理？
3. 异质性处理效应分析：是否存在处理显著优于或劣于平均的细分？影响是什么？
4. 实践显著性：即使统计显著，测量的效应量对业务是否足够重要？
5. 建议：发布/不发布/迭代——附清晰推理及建议条件（如"仅向核心用户发布"，"在修复细分B中延迟回归后发布"）

输出：含建议的实验结果备忘录 + 置信度水平 + 下一个实验建议

提示词4 — 阶段性灰度计划

为以下AI产品变更设计阶段性灰度计划。

变更：[描述模型更新、提示词变更或AI功能]
风险级别：[高/中/低——原因]
用户群：[总用户数、关键细分、地理分布]
当前生产指标基线：[关键指标及当前值]
灰度基础设施：[流量分割能力、可用监控工具]

设计阶段性灰度：

阶段1 — 内部（第1–3天）：
- 流量分配：[%] — 仅内部用户
- 推进成功标准：[具体指标阈值]
- 监控频率：[多频繁检查]
- 回滚触发器：[触发回滚的具体条件]

阶段2 — 金丝雀（第4–7天）：
- 流量分配：外部用户的[%]，[哪些细分优先]
- 推进成功标准：
- 监控频率：
- 回滚触发器：

阶段3 — 有限GA（第8–14天）：
- 流量分配：[%]
- 推进成功标准：
- 监控：
- 回滚触发器：

阶段4 — 完整GA（第15天+）：
- 流量分配：100%
- 灰度后监控期：[持续时间]
- 宣布灰度完成的成功标准：

对每个阶段：谁是推进 vs. 回滚的决策者？在每个阶段等待的最长时间是多少，超时后必须做出去/不去决策？

输出：阶段性灰度手册 + 决策树 + 每阶段过渡的沟通计划

提示词5 — 实验组合优先排序

为下一季度的以下AI实验积压进行优先排序。

产品上下文：[产品名称、当前战略优先级、实验工程能力：[X]实验周可用]

实验积压：
[对每个提议的实验，提供：]
1. [实验名称]：假设：[陈述]。预期主要指标影响：[估计效应量]。战略重要性：[高/中/低及原因]。工程工作量：[S/M/L]。前提条件：[依赖项]。
2. [实验名称]：[同等字段]
[继续所有提议的实验]

对每个实验评估：
- 预期价值 = P(成功) × 指标影响 × 战略权重
- 即使失败也有学习价值（无效结果是否仍能教我们重要的东西？）
- 资源效率：预期价值/工程工作量
- 依赖项和排序约束（实验A必须在B开始前完成吗？）
- 交互风险：此实验是否与其他计划实验冲突？

生成：
1. Q[X]的优先实验队列：排序列表附每个位置的理由
2. 实验日历：哪些实验并发运行 vs. 顺序运行（考虑交互风险和资源约束）
3. 学习路线图：我们预期在季度末知道什么，以及这些知识如何为Q[X+1]策略提供信息
4. 降优先级的实验：积压中哪些被削减及原因——以及在什么条件下会重新优先排序

输出：实验组合计划 + 日历视图 + 学习路线图叙述

22. AI模型漂移与性能退化检测器

在用户之前发现AI质量回归——通过为模型行为构建的自动化监控。

痛点与解决方案

痛点：静默的模型退化破坏用户信任

AI产品面临传统软件监控无法检测的一类故障模式：静默的模型性能退化。与触发明显告警的服务器崩溃不同，模型漂移是逐渐发生的——幻觉率缓慢增加，特定查询类型的输出出现新兴偏差，或输出语气逐渐偏移——对监控CPU、内存和错误率的基础设施监控工具不可见。等到用户投诉响亮到触发支持升级时，对信任的损害已经造成，根本原因早在数周前就埋下了。

模型漂移同时来自多个来源：输入分布偏移（用户逐渐提出与发布时不同的问题）、模型提供商更新（API提供商静默更新底层模型）、提示词脆弱性（最初优雅退化但随着时间推移在更常见的边缘案例上灾难性失败的提示词）以及嵌入空间漂移（检索系统随着训练分布与当前查询之间差距增大而退化）。每个来源都需要不同的检测方法，大多数AI产品团队一个都没有监控。

组织层面的后果是AI产品经理在信念而非证据上运营。他们假设产品在发布日质量上运行，除非用户投诉。实施系统性漂移检测的竞品以10–20倍的速度发现问题，有信心地发布改善，并通过可证明的一致质量建立用户信任——这是一旦建立就极难弥补的复合优势。

COCO如何解决

1. 漂移检测框架设计：COCO设计全面的监控架构：

   • 定义用于跟踪AI质量指标的统计过程控制（SPC）方法，为每个指标分布选择适当的控制图类型
   • 设计种群稳定性指数（PSI）计算，检测随时间变化的查询嵌入中的输入分布偏移
   • 创建参考数据集选择标准：哪些生产样本成为持续比较的"黄金集"
   • 按指标类型规定监控频率：延迟和错误率实时监控、质量评分每日、分布级指标每周
   • 记录模型版本控制和变更日志要求，将性能变化与部署事件关联

2. 质量指标监控规范：COCO创建可测量的质量信号框架：

   • 设计LLM-as-judge监控流水线：自动质量评估的提示词模板、与人工判断的校准、置信度阈值
   • 规定幻觉检测探针：每日运行已知正确答案的精选查询集，随时间测量事实准确性
   • 创建输出一致性指标：同一查询不同日期的一致性率，检测模型更新引起的输出偏移
   • 为可测量成功的结构化AI任务（表单填写、代码生成、数据提取）定义任务完成率测量
   • 为RAG系统设计检索质量监控：命中率、MRR、上下文相关性评分，追踪基线偏移

3. 告警分类与升级协议：COCO设计检测到漂移的响应工作流：

   • 创建含具体阈值的告警严重程度层级：P0（立即呼叫工程师）、P1（当天调查）、P2（下个冲刺分析）
   • 设计初始调查清单：每种告警类型的值班工程师前5个诊断步骤
   • 生成根因假设框架：输入漂移 vs. 模型更新 vs. 提示词退化 vs. 基础设施变更——诊断决策树
   • 生成回滚决策标准：哪些具体条件下立即回滚是正确响应 vs. 先调查
   • 创建捕获漂移检测学习用于监控系统改进的事后审查模板

4. 自动化回归测试套件设计：COCO构建系统性质量门控：

   • 从历史反馈中精选回归测试案例集：曾导致质量问题的真实查询，作为永久金丝雀
   • 为每个测试案例设计可自动评分（LLM-as-judge）并附有人工校准评分参考的评估标准
   • 创建部署前质量门控：任何模型变更在进入生产前在回归套件上必须达到的最低分数
   • 规定A/B保留监控：将小部分流量保留在上一个模型版本上作为实时质量基线
   • 生成月度回归套件刷新协议，确保测试案例持续代表当前查询分布

5. 输入分布偏移分析：COCO跟踪用户实际问了什么的变化：

   • 设计查询聚类流水线，按主题、复杂度和意图对查询进行分类——实现细分级漂移检测
   • 创建时序查询分布分析：每周和每月跟踪查询类型组合如何偏移
   • 识别在训练数据中没有良好代表的新兴查询模式——能力差距的早期预警
   • 设计新奇度评分监控：标记远离训练分布的个别查询以供人工审查
   • 生成将当前分布与发布日分布对比的季度"用户实际在问什么"报告

6. 模型提供商变更检测：COCO监控静默的上游变更：

   • 设计API指纹识别方法，检测提供商的静默模型更新（输出风格偏移、能力变化、拒绝模式变化）
   • 创建每周一致性探针：重复运行相同提示词，通过输出分布偏移检测提供商端变化
   • 规定基准探针集：定期在已知基线下运行查询，在影响生产用户前检测能力变化
   • 生成提供商变更沟通模板，在上游模型变化影响产品行为时通知用户
   • 设计多提供商监控：跨提供商选项跟踪相对质量，在某个提供商退化时实现快速切换

量化结果与受益角色

可量化的成果

• 漂移检测时间：从平均14天（用户投诉驱动）减少至48小时以内（自动化监控）
• 平均解决时间：早期检测到漂移并附有诊断数据时，AI质量事件解决速度快3–5倍
• 用户信任保留：拥有漂移监控的产品在对质量变化最敏感的核心用户中，流失率低20–30%
• 回归预防：部署前质量门控在到达生产前捕获**65–80%**的质量回归
• 监控覆盖率：全面漂移框架覆盖8–12种不同故障模式，而基础设施监控仅覆盖1–2种

受益人群

• AI产品经理：获得投诉之间产品质量的可见性——从被动救火转变为主动质量管理
• 机器学习工程师：收到早期的、诊断丰富的告警，将调查时间从数天缩短至数小时
• 客户成功团队：在客户升级前提前获得影响企业账户质量问题的预警
• 高管领导：访问用于董事会报告和产品健康投资者更新的可靠AI质量仪表板

💡 实用提示词

提示词1 — 漂移监控框架设计

为以下AI产品设计全面的模型漂移监控框架。

产品：[名称和主要用例]
模型架构：[描述：基于API的LLM/微调模型/RAG系统/智能体流水线——关键组件]
当前监控：[已监控的内容——具体说明]
用户量：[每日查询数，峰值/平均]
质量定义：[你如何定义此产品的"良好输出"]
基础设施：[云提供商，可观测性栈——如Datadog、Grafana、CloudWatch]

设计监控框架：

1. 指标清单：列出要监控的所有指标，按以下分类：
   - 基础设施指标（延迟P50/P95/P99、错误率、token使用量）——可能已监控
   - 需要添加的模型质量指标：[为此产品建议5–8个质量特定指标]
   - 输入分布指标：[建议3–5个跟踪查询分布偏移的指标]
   - 业务代理指标：[建议3–4个与模型质量相关的业务指标]

2. 对每个质量指标：
   - 测量方法：如何在生产规模下计算
   - 基线建立：如何设置初始基线和可接受范围
   - 告警阈值：什么偏差触发告警
   - 告警严重程度：P0/P1/P2

3. 监控架构：收集、处理和对这些指标告警需要什么基础设施组件？从查询→指标→告警描述数据流水线。

4. 仪表板设计：模型质量仪表板应包含哪些视图？受众是谁（值班工程师、PM、高管）？

5. 手册大纲：此产品最可能的3种漂移场景的高级响应步骤。

输出：漂移监控框架文档 + 指标清单表格 + 实施优先顺序

提示词2 — LLM-as-Judge监控流水线设计

为以下AI产品输出的持续质量评估设计LLM-as-judge监控系统。

产品：[名称]
输出类型：[产品生成什么类型的输出——如问题答案、代码、摘要、结构化数据]
要监控的质量维度：[如准确性、完整性、语气、安全性、相关性——列出3–5个最重要的]
监控量：[每日评估多少输出——LLM评估调用的预算]
评委模型选项：[哪些模型可用作评委——可与生产模型不同]

设计流水线：

1. 评委提示词模板：对每个质量维度，编写以下评委提示词：
   - 输入：原始用户查询 + 任何上下文/指令 + 模型输出
   - 返回：定义量表上的分数（如1–5）+ 一句话理由 + 置信度（高/中/低）
   - 校准以保持一致性（相同输出在多次运行中评分相似）
   - 抵抗讨好（不会为听起来自信但错误的输出虚高评分）

2. 抽样策略：如何选择要评估的生产输出（随机抽样、按查询类型分层、对抗性选择等）

3. 校准方法：如何验证评委评分与人工判断的一致性（评委评分输出中应有多少比例也由人工评分？）

4. 聚合与趋势：如何将个别评分聚合为每日/每周质量指标并可视化趋势

5. 故障模式处理：当评委本身失败或给出低置信度评分时该怎么办

6. 成本估算：在指定量下使用[指定评委模型]运行此监控流水线的大致成本

输出：完整LLM-as-judge流水线规范 + 评委提示词模板 + 校准协议 + 成本估算

提示词3 — 回归测试套件构建器

为以下AI产品构建回归测试套件，在部署前检测质量回归。

产品：[名称和用例]
历史质量问题：[描述过去模型质量退化的事件——发生了什么、何时被检测到、什么导致了它]
当前已知故障模式：[哪些类型的查询或场景当前产出质量较低的输出]
输出质量标准：[你如何评估输出质量——标准和评分方法]

构建回归套件：

1. 测试案例精选标准：什么样的测试案例对此产品来说是好的回归测试？定义选择标准。

2. 测试案例类别（跨以下类别目标50–100个总测试案例）：
   - 核心能力测试：[10–15个案例] — 最常见和最重要的用例
   - 已知故障模式测试：[10–15个案例] — 类似历史质量事件的查询
   - 边缘案例测试：[10–15个案例] — 边界条件、不寻常输入、对抗性提示词
   - 能力边界测试：[10–15个案例] — 处于产品设计功能边缘的查询
   - 安全/政策测试：[5–10个案例] — 应触发适当拒绝或安全响应的查询

3. 对每个测试案例类别：提供3个具体示例测试案例，含查询文本 + 预期输出质量标准 + 评分标准。

4. 自动评分方法：部署时如何自动评分每个测试案例？定义评分逻辑。

5. 通过/失败阈值：套件中的什么聚合分数构成通过门控？如何处理单个测试案例失败？

6. 套件维护：多频繁刷新测试案例，什么触发非周期性刷新？

输出：回归套件规范 + 样本测试案例 + 自动评分实施指南 + 部署门控标准

提示词4 — 输入分布偏移分析

分析以下查询数据，检测AI产品中的输入分布偏移。

产品：[名称]
分析期：[当前期日期]
基线期：[用作参考的历史期]

查询数据摘要：
基线期（[日期范围]）：
- 总查询量：[n]
- 顶级查询类别：[列出及百分比]
- 查询长度分布：[平均、中位数、P90、P99 token数]
- 最常见查询模式：[描述前5–10种查询类型]

当前期（[日期范围]）：
- 总查询量：[n]
- 顶级查询类别：[列出及百分比]
- 查询长度分布：[平均、中位数、P90、P99 token数]
- 最常见查询模式：[描述前5–10种查询类型]

分析：
1. 分布偏移检测：哪些查询类别作为总量占比发生了显著增减？（>5个百分点变化）
2. 新兴查询类型：当前期是否有在基线期不突出的查询模式？
3. 模型适配性评估：对于每个显著偏移的类别，评估当前模型是否适合处理新分布——或是否存在训练/提示词差距
4. 性能关联：分布偏移是否与观察到的质量指标变化相关？
5. 可行建议：
   - 处理新查询分布的提示词调整
   - 微调数据收集优先级
   - 引导用户使用模型处理最佳查询类型的文档/引导更新
   - 跟踪新重要查询类别的监控更新

输出：分布偏移分析报告 + 模型适配性评估 + 按优先级排序的推荐行动

提示词5 — 漂移事件事后分析模板

对以下AI模型质量事件进行事后分析。

事件摘要：
- 事件ID：[ID]
- 检测日期/时间：[首次检测到问题的时间]
- 检测方法：[如何被检测到——用户投诉、监控告警、内部测试]
- 解决日期/时间：[问题完全解决的时间]
- 影响：[受影响用户、受影响查询、可量化的业务影响]

事件时间线：
[列出带时间戳的关键事件：问题可能开始的时间、首次信号出现的时间、被检测到的时间、调查时间、缓解时间、解决时间]

根因分析：
- 直接原因：[直接导致质量退化的原因]
- 促成因素：[允许这发生的条件]
- 检测缺口：[为什么监控或测试没有更早发现这个问题]

生成事后分析文件：

1. 执行摘要（3条要点）：发生了什么、影响、根本原因
2. 详细时间线：含责任方的按时间顺序事件
3. 根因分析：根本原因的5-Why分析
4. 检测缺口分析：为什么现有监控/测试错过了这个——什么会发现它？
5. 行动项：
   - 立即：[本周实施的变更]
   - 短期：[30天内的监控/测试改进]
   - 长期：[90天内的系统性改进]
   每个行动：负责人、截止日期、成功指标
6. 经验教训：这次事件告诉我们什么关于AI系统脆弱性的信息？什么假设被证明是错误的？
7. 监控改进：基于此次事件的检测缺口，添加具体新监控

输出：工程全员会议就绪的完整事后分析文件 + 行动项追踪器

23. AI LLM输出质量评分与路由系统

自动评分、过滤和路由LLM输出，以规模化提供一致的高质量响应。

痛点与解决方案

痛点：输出质量不一致阻碍企业采用

企业AI采用的最大单一障碍是输出质量不一致。企业买家可以容忍偶尔在困难问题上失败的AI——他们无法容忍的是在没有预警的情况下在简单可预测的问题上失败的AI。当面向客户的AI助手某天给出幻觉的法律引用、第二天对几乎相同的查询给出完美答案时，糟糕答案对信任的破坏远超数百个好答案带来的价值。

LLM输出本质上是概率性的，即使是最先进模型的原始输出，其质量方差在高风险企业工作流中也是不可接受的。对于领域外问题，顶级前沿模型的幻觉率在事实性查询上仍在3–15%之间徘徊。没有输出质量评分和智能路由，每个用户都获得相同的原始模型输出，无论质量如何。

AI产品的竞争护城河越来越不在于底层模型——这对所有竞争者都是可获得的——而在于其上的质量保证层。实施系统性输出评分和路由的公司可以为AI质量提供企业SLA，实现竞争对手使用原始模型输出无法匹配的销售周期和合同条款。然而大多数AI产品团队将输出质量视为模型提供商的问题，而非他们自己拥有的产品工程挑战。

COCO如何解决

1. 输出质量评分框架设计：COCO创建多维度质量评估系统：

   • 为产品用例定义特定质量维度（事实准确性、完整性、相关性、语气、格式合规性、安全性）
   • 为每个维度设计评分标准，附区分评分级别的具体标准（1–5分或通过/失败，视情况而定）
   • 创建以用户满意度结果校准维度权重的综合质量评分公式
   • 按查询类型和用户细分（企业 vs. 消费者，高风险 vs. 探索性）规定最低可接受质量阈值
   • 设计置信度校准评分：区分高置信度评分和需要人工验证的不确定评估

2. 自动化评分流水线架构：COCO设计可扩展的质量评估系统：

   • 架构LLM-as-judge流水线，选择适当的评委模型（通用质量用GPT-4o，专业内容用领域特定模型）
   • 设计事实声明的检索增强验证：与知识库或网络搜索交叉核对输出
   • 为结构性要求创建基于规则的质量过滤器（格式合规性、长度约束、必要元素）
   • 设计基于嵌入的质量信号：RAG系统的输出-上下文相似度评分、输出-指令对齐评分
   • 规定实时评分 vs. 异步评估的评分延迟预算和优化策略

3. 智能输出路由逻辑：COCO设计基于质量评分采取行动的决策系统：

   • 创建路由决策树：高质量输出→直接交付；边界输出→人工审查队列；低质量→重新生成
   • 为低质量输出设计重新生成策略：替代提示词方式、不同模型选择、降低温度
   • 规定针对特定查询类别或评分组合升级到人工专家审查
   • 创建备用响应策略：当所有生成尝试都低于质量阈值时向用户提供什么
   • 设计优雅降级：提供能力较低但可靠性更高的响应，而非低质量的高能力尝试

4. 质量阈值校准：COCO将质量阈值与业务结果对齐：

   • 分析质量评分与用户满意度信号（点赞/踩、任务完成、会话继续）之间的相关性
   • 运行阈值校准实验，找到最大化质量-交付率乘积的评分截止点
   • 设计细分特定阈值：企业账户更高质量标准、受监管用例或高风险决策
   • 创建成本-质量优化模型：找到以最低推理成本实现质量目标的阈值设置
   • 生成阈值审查协议：随用户群、查询分布和模型能力演变进行季度重新校准

5. 质量优化的多模型路由：COCO设计模型选择系统：

   • 创建将简单查询路由到更小更廉价模型、将复杂查询路由到前沿模型的查询复杂度分类器
   • 设计质量驱动的模型选择：先用更快/更廉价的模型，如果未达质量阈值则升级到更强的模型
   • 规定领域特定模型路由：代码、法律、医疗内容的专业模型在这些领域优于通用模型
   • 创建延迟-质量权衡配置文件：针对不同延迟预算优化的不同模型路由配置
   • 为高风险输出设计集成方法：多模型生成，基于质量进行选择或综合

6. 质量报告与持续改进：COCO将质量评分与改进周期连接：

   • 设计显示按查询类型、用户细分、时间段和模型版本划分的评分分布的质量仪表板
   • 创建质量回归检测：当评分分布偏移表明模型或数据质量问题时告警
   • 生成供人工标注的低质量输出审查队列，将标记数据反馈回微调流水线
   • 为企业客户设计质量SLA报告：对照合同目标的每周/每月AI质量指标报告
   • 生成质量改善路线图：按预期质量提升排序潜在干预措施（微调、提示词优化、检索改善）

量化结果与受益角色

可量化的成果

• 输出质量一致性：质量评分和路由将输出质量方差减少40–60%（以质量评分的标准差衡量）
• 幻觉率降低：事实验证层将到达最终用户的幻觉减少50–70%，相比原始模型输出
• 企业转化率：有质量SLA的产品企业试用转化率比尽力而为质量的产品高35%
• 用户满意度提升：经过过滤/路由的输出在A/B测试中比未过滤输出的点赞率高15–25%
• 推理成本优化：质量驱动的多模型路由以**25–40%**更低的平均推理成本实现同等质量

受益人群

• AI产品经理：获得对面向用户质量的控制，而非完全依赖模型提供商的改进
• 企业销售团队：获得可在企业合同中提供的具体质量SLA承诺，实现之前因质量顾虑而受阻的交易
• 机器学习工程师：从评分系统收到结构化质量信号，直接为微调数据选择和提示词优化优先级提供信息
• 最终用户：体验更一致、可靠的AI输出——建立驱动长期留存的信任

💡 实用提示词

提示词1 — 质量评分框架设计

为以下AI产品设计全面的输出质量评分框架。

产品：[名称和主要用例]
主要输出类型：[描述AI生成的输出类型——如答案、摘要、代码、结构化数据、建议]
用户细分：[谁使用产品及其质量期望]
高风险用例：[质量失败有重大后果的任何用例]
当前质量信号：[你已收集的任何质量反馈——点赞/踩、任务完成等]

设计质量框架：

1. 质量维度：定义此产品最重要的4–6个质量维度。对每个维度：
   - 名称和定义
   - 为什么对此用例重要
   - 如何评分（1–5分量表，附每个级别的具体标准，或附精确通过标准的通过/失败）
   - 综合评分中的权重（权重总和应为100%）

2. 综合质量评分：定义将维度评分合并为单一质量评分的公式。包含任何非线性加权（如安全维度评分<3自动失败）。

3. 质量层级定义：
   - 高质量（直接交付）：评分范围和理由
   - 可接受质量（附注意事项或监控交付）：评分范围
   - 低质量（重新生成或升级）：评分范围
   - 不可接受（永不交付）：评分范围

4. 校准方法：如何验证此评分框架与实际用户满意度相关？描述你将进行的校准研究。

5. 细分特定调整：质量阈值是否应按用户细分有所不同？（如企业更高门槛、探索性/头脑风暴用例更低门槛）

输出：质量评分框架规范 + 维度评分标准 + 校准研究设计

提示词2 — LLM-as-Judge提示词工程

为以下AI产品输出的自动质量评分设计LLM-as-judge提示词。

产品用例：[描述AI产品的功能]
要评分的质量维度：[列出你的质量框架中3–5个维度]
评委模型：[哪个模型将作为评委——如GPT-4o、Claude Opus]
评分量表：[1–5分含半分/1–10分/通过-失败]

对每个质量维度，设计以下评委提示词：
- 输入：原始用户查询 + 任何上下文/指令 + 模型的输出
- 返回：定义量表上的分数 + 一句话理由 + 置信度（高/中/低）
- 校准以保持一致性（相同输出在多次运行中评分相似）
- 抵抗讨好（不会为听起来自信但错误的输出虚高评分）

对每个维度，提供：

1. 评委提示词模板（完整，可直接使用）：
   [完整提示词，嵌入清晰评分标准，而非模糊描述]

2. 示例校准案例：
   - 1分示例：[应评1分的查询+输出及原因]
   - 3分示例：[应评3分的查询+输出及原因]
   - 5分示例：[应评5分的查询+输出及原因]

3. 此评委提示词的已知故障模式：[评委何时可能评分不正确，以及如何检测]

4. 校准协议：如何验证此评委提示词与人工评分者的一致性，以及如何在系统性偏差时调整

同时设计：
- 在单次调用中评估所有维度的综合评分提示词（更高效但可能较不准确）
- 高量预筛查的快速二元过滤提示词

输出：完整评委提示词库 + 校准案例 + 校准协议

提示词3 — 输出路由逻辑设计器

为AI输出质量管理系统设计路由逻辑。

产品：[名称]
质量评分输出：[描述质量评分系统产出什么——每个维度的评分、综合评分、置信度]
用户体验约束：[质量系统增加的最大可接受延迟、最大可接受重新生成率]
基础设施：[描述可用路由基础设施和模型选项]

设计路由决策系统：

1. 路由决策树：将所有评分级别和置信度级别的组合映射到路由行动：
   [高评分 + 高置信度] → [行动]
   [高评分 + 低置信度] → [行动]
   [中等评分 + 高置信度] → [行动]
   [中等评分 + 低置信度] → [行动]
   [低评分] → [行动]
   [安全失败] → [行动]

2. 重新生成策略：当低质量输出触发重新生成时：
   - 重新生成尝试中什么会改变？（温度、提示词、模型、上下文）
   - 降级前的最大重新生成尝试次数？
   - 如何在不超出延迟预算的情况下跟踪重新生成尝试？

3. 人工审查队列设计：对于路由到人工审查的输出：
   - 向审查员呈现什么信息？
   - 审查员可以采取什么行动？（批准、拒绝、编辑、升级）
   - 按优先级的人工审查SLA？
   - 审查后的输出如何用于改进自动评分系统？

4. 备用响应设计：当所有生成尝试都低于质量阈值时：
   - 用户看到什么？（诚实的失败消息/低能力响应/升级到人工）
   - 如何跟踪和报告这个？

5. 延迟影响分析：质量评分+路由对以下情况的预期延迟开销是多少：
   - 90百分位案例（路由顺利进行）
   - 99百分位案例（需要重新生成）
   - 最坏情况（多次重新生成 + 人工审查）

输出：路由逻辑规范 + 决策树图说明 + 延迟分析 + 实施优先顺序

提示词4 — 企业质量SLA定义

为以下AI产品的企业客户定义质量SLA。

产品：[名称和用例]
企业客户档案：[描述典型企业客户——行业、用例、质量期望]
当前质量指标：[你的当前基线质量指标值]
竞品质量声明：[竞品做出的质量声明，如已知]

设计企业质量SLA：

1. SLA指标选择：对此领域的企业客户最有意义的3–5个质量指标？对每个：
   - 指标定义（精确、可测量）
   - 当前基线值
   - 提议的SLA承诺值
   - 测量方法（如何证明达到了它）
   - 报告频率和格式

2. SLA层级结构：设计2–3个层级（如标准、专业、企业）：
   - 对每个层级：SLA承诺、测量期、报告、违规时的补救措施

3. SLA违规补救：如果SLA被违反：
   - 如何检测和确认违规？
   - 通知时间线是什么？
   - 提供什么补救（服务积分、修复、升级）？
   - 处罚适用前的修复期是什么？

4. 排除和注意事项：哪些合法排除适用？（用户引发的失败、不可抗力、定义范围外的查询）

5. 质量证明包：你可以向企业客户提供什么作为SLA合规证明？
   - 月度质量报告：[包含什么]
   - 审计权：[企业客户可以审计什么]
   - 第三方验证：[与此比较相关的任何独立质量评估]

输出：企业质量SLA文件 + 测量方法 + 报告模板 + 证明包大纲

提示词5 — 多模型质量路由策略

为以下AI产品设计多模型路由策略，优化质量和成本。

产品：[名称和用例]
可用模型：[列出可用模型，附大约每百万输入/输出token成本和关键质量特征]
查询分布：[描述查询类型的混合——简单/复杂、领域特定/通用、延迟敏感/容忍]
质量要求：[按查询类别的最低质量阈值]
延迟预算：[面向用户响应的目标P50/P95延迟]
月度推理预算：[大约预算约束]

设计路由策略：

1. 查询分类：查询的哪些特征决定它应被路由到哪个模型？
   - 定义分类维度：[复杂度、领域特定性、延迟敏感性、风险级别]
   - 对每个维度：如何在查询时分类（快速、低成本分类方法）

2. 模型分配矩阵：将查询类别映射到模型分配：
   [创建表格：查询类型 | 主要模型 | 备用模型 | 理由 | 每次查询预期成本 | 预期质量评分]

3. 级联路由：当主要模型输出未达质量阈值时设计升级逻辑：
   - 第1步：[主要模型尝试]
   - 第2步：[如果评分<阈值，升级到：...]
   - 第3步：[如果仍然低于阈值：...]
   - 最大级联深度和每步延迟预算

4. 成本-质量优化：在当前查询分布下，此路由策略的预期：
   - 每次查询平均成本？
   - 平均质量评分？
   - 超出主要模型升级的查询%？
   - 与基线（所有查询到最强模型）的对比？

5. 监控和适应：随着模型能力和成本变化，路由权重应如何随时间更新？

输出：多模型路由规范 + 模型分配矩阵 + 成本-质量分析 + 实施指南

24. AI产品指标与KPI仪表板构建器

定义、仪表化并可视化真正关乎AI产品健康和增长的指标。

痛点与解决方案

痛点：用传统SaaS指标衡量AI产品会错过要害

AI产品经理接手为传统SaaS产品构建的仪表板——DAU、会话时长、功能采用率、MRR——并发现这些指标不足以理解AI产品健康状况。用户可以有很高的会话参与度，同时深感沮丧，反复重新生成差劲的输出。功能采用率对于AI功能是否在创造价值毫无说明意义。传统转化指标忽略了决定AI产品成功的整个行为循环：用户的任务是否真正在AI协助下完成了。

AI产品测量缺口制造了导致灾难性错误产品决策的盲点。团队发布提升理论基准分数但损害真实任务完成率的模型改善。他们优化查询量，同时因为没有测量输出质量而导致流失加速。他们错过预测长期产品市场契合度的核心用户留存信号，直到流失已经到了危机水平。根本原因始终相同：衡量便于仪表化的而非真正反映AI价值交付的指标。

与此同时，AI特定运营指标——幻觉率、推理成本、延迟百分位数、上下文利用率——存在于与产品健康指标脱节的工程仪表板中。这种组织分离意味着产品决策在不了解运营约束的情况下做出，工程决策在不了解产品影响的情况下做出。AI产品经理的工作是弥合这一差距，但没有统一的指标框架，桥梁从未被系统性地搭建。

COCO如何解决

1. AI产品指标框架设计：COCO构建全面的测量架构：

   • 定义AI产品指标栈：业务结果→产品参与度→AI质量→运营效率，各层之间有因果联系
   • 设计AI特定参与度指标：任务完成率、AI辅助 vs. 非辅助行为比率、重新生成率、提示词迭代次数
   • 创建价值实现指标：首次获得价值的时间、会话内成功任务完成、用户报告的结果达成
   • 规定AI采用质量指标：根据行为模式而非仅登录频率区分好奇探索者和深度用户
   • 设计留存预测指标：AI产品特有的流失先行指标（任务成功率下降、重新生成率上升）

2. 仪表化规范：COCO定义精确跟踪什么以及如何跟踪：

   • 为用户与AI功能的所有交互编写事件跟踪规范：查询提交、输出接收、输出接受/拒绝、重新生成触发、反馈提交
   • 设计AI输出跟踪模式：每次LLM调用记录什么元数据（模型版本、延迟、token计数、质量评分、路由路径）
   • 创建用户旅程仪表化：跟踪会话内和跨会话的完整交互序列，以理解AI使用模式
   • 规定标识符策略：将用户事件链接到AI调用再到质量评分再到业务结果的统一数据模型
   • 为高量产品设计数据抽样策略，其中以完整保真度记录每个事件成本过高

3. 仪表板架构与设计：COCO创建可行的可视化规范：

   • 设计受众特定的仪表板层：高管（业务结果）、PM（产品健康）、ML工程师（模型质量）、运营（系统可靠性）
   • 创建AI产品健康评分卡：结合8–12个最重要指标的单页视图，附交通灯状态指示器
   • 规定趋势分析的时间序列视图：每日/每周/每月，含对比期和异常高亮
   • 设计队列分析视图：跟踪不同用户获取队列如何采用和围绕AI功能留存
   • 创建下钻结构：从摘要指标到细分分解再到个别会话调查

4. 北极星指标定义：COCO促进对最重要单一指标的对齐：

   • 使用测试引导北极星选择：最大化此指标是否需要向用户交付真实AI价值？
   • 设计北极星分解树：显示哪些子指标驱动北极星，使团队能够识别最高杠杆干预
   • 创建带每周团队可见度和目标设定框架的北极星跟踪仪表板
   • 定义北极星护栏指标：追求北极星改善时不得牺牲的指标
   • 生成用于对齐跨职能团队共同成功定义的北极星沟通包

5. AI成本与效率指标整合：COCO在统一视图中连接质量和成本：

   • 设计每成功任务成本指标：将推理成本与任务成功率结合以测量AI效率
   • 创建单位经济学仪表板：按用户细分的LTV vs. 按用户细分的推理成本，附利润率分析
   • 规定token效率指标：跟踪上下文利用率、提示词长度优化机会、缓存命中率
   • 设计成本归因模型：将推理成本分配到产品区域、用户细分和功能类别
   • 生成成本预测模型：在不同增长场景下预测基础设施成本以进行容量规划

6. 指标治理与审查节奏：COCO建立围绕指标的运营节律：

   • 设计每周指标审查流程：审查哪些指标、与谁审查、具有什么决策权限
   • 创建指标定义文档：每个指标计算方式的唯一真实来源，防止定义争议
   • 规定指标所有权：谁对每个指标负责，谁有权更改目标
   • 生成指标演进协议：如何弃用旧指标并引入新指标而不失去历史连续性
   • 设计指标沟通模板：给领导层的每周指标简报和给产品团队的每月指标深度分析

量化结果与受益角色

可量化的成果

• 决策质量：拥有全面AI指标框架的团队基于数据做出路线图决策的频率比直觉驱动的决策高3倍
• 流失检测提前期：AI特定留存指标比传统参与度指标提前4–8周预警流失
• 成本可见性：统一的成本-质量仪表板识别出在独立工程仪表板中不可见的**20–30%**推理成本削减机会
• OKR对齐：共享的北极星指标在**70%**的先前导致延误的错位案例中减少了跨职能目标冲突
• 投资者信心：全面的AI产品指标包将投资者尽职调查时间减少30%，并提升对数据透明公司的估值倍数

受益人群

• AI产品经理：获得产品健康的客观全面视图，用数据驱动的信心替代直觉决策
• 机器学习工程师：看到模型质量指标与业务结果之间的直接联系，实现更好的ML改善优先排序
• 财务与运营团队：获得AI单位经济学可见性，用于预算、定价决策和成本优化
• 高管领导：访问可靠的AI产品健康指标，用于董事会报告、投资者更新和战略规划

💡 实用提示词

提示词1 — AI产品指标框架

为以下AI产品设计全面的指标框架。

产品：[名称、主要用例、商业模式]
阶段：[早期/增长/规模]
主要用户细分：[描述2–3种关键用户类型]
商业模式：[订阅/使用量/免费增值/企业]
当前跟踪的指标：[列出当前测量的指标]
用当前指标无法回答的关键业务问题：[列出3–5个问题]

跨四个层级设计指标框架：

第1层 — 业务结果：
- 收入指标：[适合你商业模式的指标]
- 增长指标：[获取、扩展、留存]
- 市场地位：[类别适当的竞争指标]
[推荐5–7个业务结果指标及定义]

第2层 — 产品参与度（AI特定）：
- AI功能采用指标：[超越简单功能使用——采用质量]
- 任务完成指标：[如何测量AI是否成功完成用户工作]
- 用户价值实现指标：[用户获得价值的先行指标]
- AI辅助生产力指标：[如可测量——节省时间、改善输出质量]
[推荐6–8个含AI适当定义的参与度指标]

第3层 — AI质量：
- 输出质量指标：[领域适当的质量测量]
- 可靠性指标：[一致性、正常运行时间、错误率]
- 安全指标：[适合你用例和风险级别的指标]
[推荐4–6个含测量方法的质量指标]

第4层 — 运营效率：
- 推理成本指标：[每次查询成本、每成功任务成本、成本趋势]
- 延迟指标：[按查询类型的P50/P95/P99]
- 基础设施可靠性：[正常运行时间、错误率、队列深度]
[推荐4–5个运营指标]

北极星推荐：如果最大化哪个单一指标最能表明真实的AI价值交付？证明你的选择。

输出：指标框架表格（指标名称、定义、测量方法、目标、负责人）+ 北极星理由 + 实施优先顺序

提示词2 — AI产品事件跟踪规范

为以下AI产品编写全面的事件跟踪规范。

产品：[名称]
主要AI功能：[列出主要AI驱动功能]
平台：[Web应用/移动应用/API/全部]
分析栈：[Mixpanel/Amplitude/Segment/自定义——指定]

定义完整的事件分类法：

1. 用户-AI交互事件：
对每个事件：事件名称（snake_case）、触发条件、必要属性、可选属性、示例有效负载

要规定的事件：
- ai_query_submitted：用户向AI发送输入时
- ai_response_received：AI输出显示给用户时
- ai_response_accepted：用户采取表明接受的行动时（继续工作流、复制输出等）
- ai_response_rejected：用户采取表明拒绝的行动时（重新生成、大量编辑、放弃）
- ai_regeneration_triggered：用户请求新输出时
- ai_feedback_submitted：用户给出明确质量反馈时
- [添加3–5个与你AI功能相关的产品特定事件]

2. 质量与性能事件（后端日志记录）：
- model_call_completed：每次LLM API调用记录，含延迟、token数、模型、质量评分
- quality_score_computed：自动评分完成时
- routing_decision_made：输出路由逻辑运行时
- fallback_triggered：主要模型失败且备用激活时

3. 业务结果事件：
- task_completed_successfully：[为你的用例定义成功]
- ai_value_realized：[产品特定事件，表明清晰用户价值——如报告已导出、代码已执行、决策已做出]
- subscription_influenced_by_ai：[如可跟踪——含AI使用上下文的转化事件]

4. 要维护的用户属性：
[列出用于细分的用户级属性：AI使用层级、总查询数、任务成功率等]

5. 数据模型：事件如何互相链接（会话→查询→响应→反馈链）？

输出：完整事件分类法 + 属性模式 + 工程实施指南

提示词3 — 北极星指标与OKR框架

为以下AI产品定义北极星指标和支持性OKR框架。

产品：[名称、用例、商业模式]
阶段：[早期/增长/规模]
当前重点：[获取/留存/变现/效率]
需要对齐的关键利益相关者：[列出团队及其当前成功指标]
此产品必须支持的公司级OKR：[列出相关公司级目标]

北极星开发：

1. 候选北极星指标：评估3–4个候选项：
   对每个候选项：指标定义、如何测量、为什么代表真实用户价值、它激励什么行为（包括潜在博弈行为）、测量可行性。

2. 北极星推荐：选择一个并证明理由：为什么最大化此指标需要真正向用户交付价值？为什么它优于替代项？

3. 北极星分解树：
   北极星 = [公式或显示子指标如何驱动它的因果模型]
   第1级驱动因素：[3–5个北极星的直接驱动因素]
   第2级驱动因素：[对每个第1级，是什么驱动它]
   识别：本季度哪个第2级驱动因素通过产品工作最可影响？

4. Q[X] OKR框架：
   目标：[雄心勃勃的结果陈述]
   关键结果1：[量化、有时限、可直接测量] — 目标：[值]
   关键结果2：[同格式] — 目标：[值]
   关键结果3：[同格式] — 目标：[值]
   关键结果4（护栏指标——不得下降）：[同格式] — 底线：[值]

5. 跨职能对齐：对每个利益相关者团队，解释提议的北极星和OKR如何连接到他们现有的成功指标。每个团队在衡量成功的方式上需要什么改变？

输出：北极星推荐 + OKR框架 + 分解树 + 跨职能对齐叙述

提示词4 — AI成本单位经济学仪表板设计

为以下AI产品设计单位经济学仪表板。

产品：[名称、商业模式]
收入模式：[订阅层级+价格/基于使用量的定价/企业合同]
主要用户细分：[列出细分及大约规模]
基础设施成本组件：[LLM推理成本、嵌入成本、向量数据库、其他AI基础设施]
当前可获取的指标：[你可以访问哪些成本和收入数据]

设计单位经济学仪表板：

1. 要显示的核心单位经济学指标：
   - 按用户细分的LTV：[计算方法]
   - 按获取渠道的CAC：[包含什么]
   - 按细分的LTV:CAC比率：[目标阈值]
   - 按细分的毛利率：[收入 - 推理成本 - 其他直接成本]
   - 按细分的每用户每月AI推理成本：[按功能分解]
   - 按用例的每成功任务成本：[推理成本 / 任务成功率]

2. 仪表板布局：描述每个面板：
   面板1 — 执行摘要：[顶部显示4–6个数字，含期间对比]
   面板2 — 细分经济学：[如何并排可视化LTV、CAC、按细分利润率]
   面板3 — 推理成本趋势：[时间序列 + 按模型/功能的成本分解]
   面板4 — 成本-质量关系：[质量评分 vs. 每次查询成本的散点图或趋势]
   面板5 — 增长经济学：[单位经济学如何随规模变化]

3. 告警规则：什么条件在此仪表板上触发告警？
   - 毛利率降至[阈值]以下：[向谁告警]
   - 每用户推理成本超过[阈值]：[向谁告警]
   - LTV:CAC比率降至[阈值]以下：[向谁告警]

4. 数据要求：为此仪表板提供动力需要什么数据流水线？对每个指标：数据来源、刷新频率、所需转换。

5. 决策框架：对每个关键单位经济学信号，它触发什么行动？
   [如果毛利率 < X%] → [定价审查/成本优化冲刺/细分策略审查]

输出：仪表板规范 + 面板描述 + 告警规则 + 数据要求 + 决策框架

提示词5 — 每周AI产品健康审查模板

为以下产品创建每周AI产品健康审查模板。

产品：[名称]
审查受众：[谁参与——PM、工程、设计、领导]
审查时长：[30/60分钟]
跟踪的关键指标：[列出你的核心指标]
审查节奏上下文：[基于此审查需要做出什么决策或采取什么行动]

设计每周审查：

1. 预读仪表板（会议前24小时发送）：一页摘要包含：
   - 每个关键指标的交通灯状态：[绿/黄/红及阈值定义]
   - 每个指标的周对周和月对月趋势
   - 上周以来前3个值得注意的变化
   - 现场审查议程（需要做出什么决策）

2. 会议结构（[X]分钟审查）：
   - 0–5分钟：指标脉冲——快速交通灯审查，除非红灯否则不讨论
   - 5–20分钟：深度分析——轮流聚焦领域（模型质量/用户增长/单位经济学/产品实验——每周一个）
   - 20–30分钟：决策和行动——明确做出的决策、分配负责人、设定截止日期
   - 30–[结束]（如适用）：开放问题停车场

3. 每个深度分析主题的标准议程模板：
   [模型质量周]：审查的指标、常见失败模式、改进举措状态、下一步行动
   [用户增长周]：含AI功能影响的获取、激活、留存漏斗、队列分析
   [单位经济学周]：推理成本趋势、按细分的利润率、成本优化机会
   [实验周]：运行中实验状态、已完成实验结果、下一个实验流水线

4. 会议输出模板：决策日志格式（决策、理由、负责人、截止日期、成功指标）

5. 指标简报邮件模板：面向不参加审查的利益相关者的5条要点每周摘要

输出：完整每周审查系统——预读模板 + 会议议程 + 深度分析模板 + 决策日志 + 简报邮件模板

25. AI跨职能需求规格撰写器

将模糊的AI功能请求转化为精准、工程可执行的规格说明，从根源杜绝范围蔓延与返工成本。

痛点与解决方案

痛点：AI功能在愿景与规格之间的鸿沟中消亡

AI产品经理站在业务愿景与技术现实的交汇点上，处境尤为凶险。当某位利益相关者说"在客服流程里加入AI"，他们可能有十几种不同的意思——分类模型、LLM驱动的回复生成器、基于文档的RAG系统、人机协同工作流，或者以上的某种组合。如果没有精确的规格，工程团队会做出错误的东西，业务方对结果失望，数月的开发投入在原本第一周就能预防的错位循环中付诸东流。

AI功能的规格挑战比传统软件更难。AI组件引入了不确定性、概率性质量指标、数据依赖和模型治理要求，而大多数需求模板根本没有设计来捕捉这些维度。典型的用户故事格式——"作为用户，我想……"——对AI功能规格复杂性的呈现严重不足。它遗漏了：将使用什么模型或方案、如何衡量输出质量、模型出错时如何处理、需要什么数据、系统如何优雅降级、以及生产中如何衡量成功。

跨职能协调负担进一步放大了这些问题。AI功能需要来自产品（解决什么用户问题）、设计（如何呈现输出）、工程（技术可行性）、数据科学（所需模型和数据）、法务/合规（适用的AI治理要求）和客户成功（企业客户要求的质量标准）的对齐输入。没有结构化的规格过程，每个职能都用自己的假设填补空白，最终产品反映的是六个不同的产品，而不是一个。

COCO如何解决

1. AI功能需求模板生成：COCO创建结构化规格框架：

   • 生成AI专用PRD模板，在传统用户故事基础上，捕捉模型选择依据、数据需求、质量指标、故障处理和治理要求
   • 为AI功能设计验收标准框架：以质量分布而非二元通过/失败定义验收（如"UAT中≥85%的输出在相关性评分标准上达到4/5以上"）
   • 创建边缘情况规格矩阵：系统识别并记录AI难以处理的输入的行为要求
   • 生成技术可行性评估模板：对自研/采购/集成/微调决策进行结构化评估
   • 设计数据需求规格：训练数据、评估数据、参考数据和持续生产数据需求

2. 利益相关者输入整合：COCO汇总跨职能视角：

   • 为AI功能需求收集生成结构化利益相关者访谈指南：针对业务、工程、设计、法务和客户团队设计不同问题集
   • 创建需求冲突检测框架：识别利益相关者需求相互矛盾之处并需要解决的部分
   • 生成优先级协商框架：在具有竞争性需求的利益相关者群体之间引导结构化的权衡讨论
   • 设计需求可追溯矩阵：将每条需求映射回业务目标和用户需求，防止范围蔓延
   • 生成确认文档：清晰陈述每位利益相关者同意的内容，减少事后争议

3. AI专项技术规格组件：COCO起草工程可执行的规格：

   • 编写模型接口规格：输入/输出架构、token限制、延迟预算、错误处理要求
   • 创建提示词工程规格：初始提示词结构、系统提示词要求、护栏规格
   • 设计评估框架规格：上线前评估AI组件所使用的测试用例和指标
   • 生成人机协同设计规格：需要人工审核的位置、审核界面支持的功能、SLA要求
   • 编写降级行为规格：每种故障模式下的确切处理——模型超时、质量阈值突破、安全过滤器触发

4. 数据需求文档：COCO规格化数据基础：

   • 编写训练数据需求规格：数量、质量、多样性、标注要求、数据收集时间线
   • 创建评估数据集规格：保留集、对抗性测试用例、领域专项评估套件
   • 设计数据流水线需求：摄取、预处理、版本管理和刷新频率要求
   • 生成数据治理文档：数据溯源、同意要求、保留策略、删除处理
   • 创建数据质量评估框架：如何在用于训练或检索前验证传入数据

5. AI治理与合规规格：COCO嵌入负责任AI要求：

   • 创建偏见测试规格：测试哪些人口群体、衡量什么公平性指标、可接受的不平等影响阈值
   • 编写透明度和可解释性要求：用户可以请求什么解释、系统必须能够提供什么
   • 设计人工监督规格：哪些AI决策需要人工审核、必须存在什么覆盖能力
   • 生成AI事件响应规格：什么构成可报告的AI事件、通知要求、补救程序
   • 创建模型卡要求：每个AI组件必须生成和维护什么文档

6. 上线就绪规格：COCO定义发布标准：

   • 创建AI专项上线就绪清单，涵盖模型质量、安全性、监控、回滚和合规
   • 编写分阶段推出规格：每个阶段的质量关卡，包括精确的指标阈值和决策权限
   • 设计上线后监控规格：监控什么、持续多久、频率多高、告警阈值如何设置
   • 生成成功衡量计划：上线后30、60、90天如何衡量成功
   • 创建利益相关者沟通包：向用户、企业客户和内部团队传达新AI能力的内容

量化结果与受益角色

可量化的成果

• 返工减少：全面的AI需求规格将开发中期范围变更减少50–65%，每个主要功能节省2–4周
• 对齐速度：结构化的跨职能规格流程将利益相关者对齐会议从4–6次减少到1–2次
• 工程效率：带有精确验收标准的工程可执行规格将迭代规划开销降低30%
• 合规就绪：嵌入治理要求将合规审查周期从数周缩短到数天
• 质量可预测性：具有定义质量验收标准的功能在上线时达到目标质量的概率比临时规格高75%

受益人群

• AI产品经理：生成专业、全面的规格，在工程和业务利益相关者中建立公信力
• 工程团队：获得清晰、可测试的需求，能够自信地实现而无需频繁咨询PM
• 法务与合规团队：提前获得AI治理决策的主动文档，而非被动审查已发布功能
• 企业客户：体验到更可预测、有据可查的AI能力，满足企业采购要求

💡 实用提示词

提示词1 — AI功能PRD生成器

为以下AI功能编写一份全面的产品需求文档（PRD）。

产品：[名称]
功能名称：[AI功能名称]
业务目标：[此功能服务于什么业务目标]
用户痛点：[描述此功能解决的用户痛苦——具体、有证据支撑的观察]
拟议解决方案（高层）：[从概念层面描述AI功能将做什么]
目标用户：[谁会使用此功能]
成功定义：[如何判断此功能成功]
约束条件：[时间线、技术约束、预算、监管要求]

生成AI功能PRD：

1. 执行摘要（1页）：
   - 问题陈述与证据
   - 拟议解决方案
   - 为什么AI是正确的方案（而非非AI替代方案）
   - 成功指标（量化）
   - 时间线和资源需求

2. 用户故事与验收标准：
   [对每个主要用例：]
   - 用户故事：作为[用户类型]，我想要[操作]，以便[结果]
   - AI专项验收标准：[质量阈值、延迟要求、错误处理行为]
   - 范围外：[明确此功能不做什么]

3. AI系统规格：
   - 模型/方案：[推荐方案及依据——LLM、微调模型、分类器、RAG等]
   - 输入规格：[什么内容进入——格式、约束、预处理]
   - 输出规格：[什么内容出来——格式、质量要求、约束]
   - 质量指标：[如何衡量输出质量、最低可接受值]
   - 延迟要求：[p50/p95/p99目标]
   - 故障处理：[每种故障场景的行为]

4. 数据需求：
   - 训练/微调数据（如适用）：[数量、质量、标注要求]
   - 参考/检索数据（如RAG）：[什么知识库、新鲜度要求]
   - 评估数据：[什么测试用例验证系统]

5. AI治理：
   - 偏见与公平性测试计划
   - 透明度要求（系统必须提供什么解释）
   - 人工监督要求
   - 合规要求（GDPR、行业法规）

6. 发布计划：
   - 分阶段推出阶段及质量关卡
   - 监控和告警要求
   - 回滚标准

输出：完整PRD文档 + 工程开放问题清单 + 利益相关者确认清单

提示词2 — 跨职能需求对齐引导

为以下AI功能引导跨职能需求对齐。

功能：[名称和简要描述]
涉及的利益相关者：[列出团队/角色：产品、工程、设计、数据科学、法务、客户成功、销售]
已知的分歧或模糊领域：[描述已知冲突或不清晰需求]
时间压力：[决策需要在何时做出]

生成对齐材料：

1. 利益相关者访谈问题（每类利益相关者一套）：

对于业务/产品利益相关者：
[5个问题，提取：业务目标、成功标准、约束、权衡偏好]

对于工程/数据科学利益相关者：
[5个问题，提取：技术可行性评估、工作量估算、技术风险、依赖项]

对于设计利益相关者：
[5个问题，提取：UX需求、输出呈现需求、用户信任和透明度需求]

对于法务/合规利益相关者：
[5个问题，提取：监管要求、数据治理约束、AI治理要求]

对于客户端利益相关者（CS、销售）：
[5个问题，提取：客户质量期望、企业要求、竞争背景]

2. 需求冲突识别：基于典型AI功能冲突，标记以下常见矛盾点并提供解决框架：
   - 质量与延迟权衡：[决策框架]
   - 个性化与隐私：[决策框架]
   - 功能范围与时间线：[MoSCoW优先级模板]
   - 模型能力与可解释性：[决策框架]

3. 需求确认模板：每位利益相关者明确同意的结构化文档：
   - 此功能将做什么（范围）
   - 此功能不做什么（反范围）
   - 如何衡量质量（验收标准）
   - 90天后成功是什么样子

4. AI功能开发的RACI矩阵：每个关键决策领域谁负责、谁审批、谁咨询、谁知晓。

输出：利益相关者访谈指南 + 冲突解决框架 + 确认模板 + RACI矩阵

提示词3 — AI边缘情况规格矩阵

为以下AI功能生成全面的边缘情况规格矩阵。

功能：[名称和AI功能描述]
主要正常路径：[描述正常、预期的使用场景]
用户群体：[谁使用此功能、技术成熟度、典型使用模式]
已知模型局限：[底层模型/方案的薄弱之处]
监管背景：[影响边缘情况处理的法规]

生成边缘情况矩阵：

对每个边缘情况类别，定义：触发条件、预期系统行为、用户提示（如有）、日志要求、升级路径。

需覆盖的边缘情况类别：

1. 输入质量边缘情况：输入过短/极简、输入超长（超出上下文窗口）、非预期语言输入、乱码/错别字多/格式错误输入、超出功能领域的输入

2. 模型质量边缘情况：低置信度输出、验证层检测到幻觉内容、多次重生成后仍低于质量阈值、输出违反内容安全过滤、输出技术上正确但对用户实际需求无用

3. 系统可靠性边缘情况：模型API超时、模型API达到速率限制、模型API返回错误、延迟超过可接受阈值、部分失败（部分流水线阶段成功，其他失败）

4. 对抗性输入边缘情况：提示词注入尝试、越狱尝试、试图提取系统提示词、旨在引发偏见或有害输出的输入

5. 边界条件边缘情况：无历史上下文的首次用户、具有异常或极端使用模式的用户、具有自定义配置的企业用户、具有特定要求的受监管司法管辖区用户

对每个边缘情况：评定严重程度（P0/P1/P2/P3）和所需解决时间线。

输出：完整边缘情况矩阵 + 严重程度评级 + 处理规格 + 测试用例生成指南

提示词4 — AI验收标准定义

为以下AI功能定义严格的验收标准。

功能：[名称和描述]
成功愿景：[对真实用户来说"运作良好"是什么样子]
评估约束：[可用的评估基础设施——人工评分者、LLM-as-judge、自动化测试]
质量基准：[行业或竞争对手基准]
上线时间线：[何时必须满足验收标准]

从四个维度定义验收标准：

1. 质量验收标准：
对每个质量维度（相关性、准确性、完整性、语气、安全性）：
- 测量方法：如何评分
- 最低上线阈值：必须达到的分数
- 上线后90天目标：质量目标
- 评估数据集：使用的测试用例（规模、构成、来源）

2. 性能验收标准：
- 延迟：p50 ≤ [X]ms，p95 ≤ [X]ms，p99 ≤ [X]ms
- 可用性：AI组件 ≥ [X]% 正常运行时间
- 错误率：≤ [X]% 的请求导致错误响应
- 成本：≤ $[X] 每[单位]——上线的成本上限

3. 安全验收标准：
- 内容安全：安全评估套件通过率 [X]%
- 偏见测试：人口群体间最大 [X]% 性能差异
- 对抗鲁棒性：对抗测试套件通过率 ≥ [X]%
- 人工审核：所有[定义类别]的输出在交付前经人工审核（如适用）

4. 业务验收标准：
- UAT：[X]% 的UAT用户认为功能满足其需求
- 试点NPS：试点群体NPS ≥ [X]
- 任务完成率：≥ [X]% 的AI辅助任务成功完成
- 采用率：≥ [X]% 的符合条件用户在上线后30天内尝试该功能

输出：验收标准文档 + 每项标准的测量方法 + 发布决策框架

提示词5 — AI治理需求规格

为以下AI功能编写AI治理需求。

功能：[名称和描述]
风险级别：[高/中/低——及原因——考虑：影响用户的自动化决策、敏感数据使用、受监管领域、部署规模]
用户群体：[地理分布、是否包含脆弱人群、企业还是消费者]
监管环境：[适用法规：欧盟AI法案、GDPR、CCPA、行业法规]
公司AI治理政策：[现有的AI伦理原则或治理承诺]

编写AI治理需求：

1. 透明度要求：在交互点必须告知用户什么AI参与信息？用户有什么解释权，系统如何支持？隐私政策、服务条款和产品文档中必须披露什么？起草每个披露位置的所需披露文本。

2. 公平性和偏见要求：必须测试哪些人口属性的不平等影响？使用什么公平性指标（人口均等、平等机会、个体公平）？上线前可接受的最大性能差异是多少？上线后的持续监控要求是什么？谁负责偏见测试和审批？

3. 人工监督要求：哪些AI输出或决策在生效前需要人工审核？用户、管理员或合规官必须拥有什么覆盖能力？必须维护什么审计跟踪，保留多久？谁有权限在治理问题出现时禁用AI功能？

4. 数据治理要求：AI功能使用什么数据，其使用是否符合原始同意？不得使用什么数据（数据最小化要求）？适用什么数据保留和删除要求？用户数据是否用于改进模型？如果是：选择加入还是选择退出，如何操作？

5. 事件响应要求：此功能的"可报告AI事件"是什么？每个事件级别的通知要求是什么？谁有权限触发事件响应程序？所需的补救时间线是什么？

6. 监管合规证据：在欧盟AI法案下：此功能属于哪个风险类别，适用哪些合规要求？必须维护什么文档供监管检查？是否需要第三方评估？

输出：AI治理需求规格 + 合规证据清单 + 事件响应手册框架

26. AI产品Beta测试反馈合成器

从Beta用户反馈的海量噪声中提炼可执行的产品洞察——快到足以在上线前采取行动。

痛点与解决方案

痛点：Beta反馈涌入的速度超过团队处理能力

Beta测试是公开上线前最后一次纠偏的机会，但大多数AI产品团队白白浪费了这次机会。AI产品的Beta项目会产生极大量的异构反馈——Discord消息、Loom录屏、问卷回复、支持工单、使用日志和直接邮件——来自数百名技术背景、使用场景和质量预期各异的测试者，同时涌来。产品经理通常把Beta处理时间的80%花在整理和阅读反馈上，而不是在合成洞察和做决策上。

AI产品的Beta反馈挑战与传统软件Beta有质的不同。Beta用户经常将自己的提示技巧与产品质量混淆——把因输入提示拙劣而产生的输出归咎于产品。反之，资深Beta用户会在冗长的Slack帖子中暴露产品团队没有预料到的模型故障模式，而这些内容往往淹没在UI细节等无关反馈中。将高价值的模型质量反馈与噪声分离，需要大多数反馈合成流程所缺乏的AI产品专业知识。

结果是Beta反馈推动的是表面性的上线改动——UI打磨、文案调整、文档改进——而Beta用户清晰指出的根本性模型质量问题却被遗漏或降低优先级，因为它们没有从反馈混乱中清晰地浮现出来。产品带着Beta用户已经预测到的已知AI质量问题上线，在冲刺最后阶段为处理次要Beta反馈而引入回归bug，并错过了20%能将上线当天用户满意度提升10倍的Beta洞察。

COCO如何解决

1. 多格式反馈摄取与规范化：COCO处理异构Beta反馈：

   • 从非结构化文本来源提取关键反馈主题：Discord日志、邮件线程、Slack频道、论坛帖子
   • 跨多个问卷工具合成结构化和开放性问题的问卷回复模式
   • 将口头反馈转录（来自访谈或录屏会话）处理为结构化洞察摘要
   • 将跨来源反馈规范化为统一分类以进行跨来源分析
   • 对同一用户在多个渠道的重叠反馈进行去重

2. AI专项反馈分类：COCO将领域专业知识应用于反馈分析：

   • 区分模型质量问题与UX/提示问题——这是AI产品Beta反馈最关键的分类
   • 识别"用户教育可解决"的问题与"产品必须改变"的问题，防止UX修复被应用于真正的模型问题
   • 按AI产品组件对反馈进行分类：检索质量、生成质量、提示词处理、输出格式、延迟感知
   • 为反馈项打上严重程度标签：上线阻塞、重要但非阻塞、锦上添花、未来路线图
   • 识别揭示用户心智模型与实际AI能力背离的反馈——标记教育和引导缺口

3. 模式合成与主题提取：COCO从噪声中浮现信号：

   • 使用语义相似性而非仅关键词匹配，将反馈聚类为连贯主题
   • 计算主题频率和用户数量，识别影响广度与声音响亮的少数
   • 识别共现问题：一致同时出现的反馈主题，表明有共同根本原因
   • 追踪反馈情感轨迹：随着用户熟悉产品，情感是否在Beta期间改善或恶化
   • 生成"Beta用户旅程"合成：用户第1天喜欢什么，第7天出现什么挫败，第30天高级用户发现什么

4. 代表性反馈策展：COCO为团队消费选择最有用的反馈：

   • 每个主题选择3–5条最能向工程和设计受众说明问题的典型原话
   • 策展"黄金反馈"示例：清晰阐明模型质量失败且上下文足够复现的反馈
   • 识别最有价值的Beta用户：其反馈不成比例地代表了更广泛用户群体的模式
   • 标记提供其他反馈项未捕捉到新洞察的反馈——可能是最有价值的单条反馈
   • 为重新联系提供了高价值但不完整反馈的特定Beta用户，生成跟进问题清单

5. 发布决策支持：COCO将Beta洞察转化为发布/不发布的情报：

   • 生成上线阻塞分析：哪些反馈项如果不解决，可能导致上线当天重大问题
   • 基于Beta情感和问题普遍性，生成"带这些问题上线"的影响预测
   • 创建优先修复清单：按上线影响（严重程度×用户数×可修复性）排序
   • 设计"Beta到GA改进叙事"：产品在Beta期间如何改进的故事，用于上线传播
   • 生成Beta后研究议程：Beta没有完全回答、应在上线后30天内解决的问题

6. Beta到路线图的情报：COCO将Beta洞察与长期产品方向相连接：

   • 识别Beta用户明确想要但当前路线图中没有的能力
   • 浮现Beta用户发现的、产品设计中未预料到的使用场景——潜在扩展机会
   • 将Beta高级用户行为映射到功能投资优先级——最好的用户做什么让产品值得构建？
   • 生成分群专项洞察摘要：不同用户类型（技术型、非技术型、企业、消费者）各自的想法
   • 生成Beta群体画像：Beta用户类型的描述性聚类，具有定位和上市的意义

量化结果与受益角色

可量化的成果

• 反馈处理时间：500+条反馈项的分析从2–3周的人工分析缩短到2–3天的AI辅助合成
• 上线阻塞识别：结构化Beta合成发现70–80%的可利用上线阻塞，而临时审查只能发现50–60%
• 上线当天NPS：具有系统性Beta合成的产品，上线当天NPS比临时Beta审查高15–20分
• 路线图洞察质量：第一年最具影响力的路线图项目中，40%首次在结构化Beta合成中被识别
• Beta用户参与：收到特定反馈确认的Beta用户保持2倍可能性转化为付费客户

受益人群

• AI产品经理：在数天而非数周内，将令人不知所措的Beta反馈转化为清晰的优先行动计划
• 工程团队：从Beta反馈中获得精心策展的、可复现的bug报告，而非模糊的投诉摘要
• 设计团队：获得具体、有代表性的UX困惑示例，指导有针对性的设计改进
• 上市团队：获取诚实、细致的Beta用户情感，以指导定位和上线消息

💡 实用提示词

提示词1 — Beta反馈合成引擎

为AI产品上线决策合成以下Beta测试反馈。

产品：[名称和描述]
Beta项目详情：[持续时间、Beta用户数、用户类型、如何收集反馈]
上线时间线：[计划上线日期]

Beta反馈来源：
1. 问卷回复：[粘贴关键定量结果+示例开放回答，或摘要]
2. Discord/Slack消息：[粘贴代表性消息或主要帖子摘要]
3. Beta期间的支持工单：[粘贴工单或摘要]
4. 访谈笔记：[粘贴笔记或用户访谈的关键引用]
5. 使用数据亮点：[关键行为数据——用户实际做了什么，而不是说了什么]

合成：

1. 前10个反馈主题：对每个主题：
   - 主题名称和描述
   - 提及此问题的用户数/占Beta用户百分比
   - 代表性原话（最能说明此主题的单条引用）
   - 分类：模型质量问题/UX设计问题/用户教育缺口/功能请求/正面
   - 严重程度：上线阻塞/重要/次要/路线图

2. AI专项问题深挖：列出所有与模型质量相关的反馈（非UX）。对每条：
   - 描述的具体质量失败
   - 看起来有多可复现（持续投诉vs一次性）
   - 根本原因假设：模型能力限制/提示词设计问题/边缘情况/用户误用

3. 正面信号：Beta用户真正对什么感到兴奋？他们发现了哪些未预料的使用场景？

4. 分群分析：[用户群体A]和[用户群体B]的反馈有何不同？

5. 上线建议：基于此合成：
   - 上线阻塞（上线前必须修复）：[列表]
   - 重要上线前改进（有时间则应修复）：[列表]
   - 上线后优先项（上线后第一个迭代修复）：[列表]
   - 继续上线：是/否/有条件的是——及理由

输出：Beta合成报告 + 优先行动清单 + 带置信水平的上线建议

提示词2 — Beta反馈分类框架

为AI产品对以下Beta反馈项进行分类和分流。

产品：[名称]
关键AI组件：[描述主要AI元素——如LLM回复生成、检索系统、分类模型]

待分类的反馈项：
[粘贴20-50条单独反馈——可以是引用、工单摘要或问卷回复]

对每条反馈，应用以下分类：

主要类别：A.模型质量——AI输出准确性/正确性问题；B.模型质量——AI输出一致性问题；C.模型质量——AI输出完整性问题；D.模型质量——安全性/偏见问题；E.延迟/性能——AI组件太慢；F.用户期望不匹配；G.提示技巧问题；H.UX/设计问题；I.功能缺口；J.正面反馈；K.不清楚

严重程度（仅问题）：P0上线阻塞；P1重要；P2次要；P3外观/锦上添花

输出：所有反馈项的分类表 + 按类别的汇总统计 + 需立即关注的P0/P1清单

提示词3 — Beta用户旅程分析

分析以下Beta使用数据，了解我们AI产品的用户旅程。

产品：[名称]
Beta持续时间：[周数]
可用数据：[描述您拥有的行为数据——每用户会话、每会话查询、功能使用]

分析Beta用户旅程：

1. 首次会话体验：用户在第一次会话中做什么？跌落点在哪里？

2. 第1-7天体验：早期出现什么挫败？发生什么"顿悟时刻"？用户在放弃前达到"顿悟时刻"的比例？

3. 第7-30天体验：高级用户与普通用户的使用模式有何不同？留存用户发展出什么功能或工作流？是什么导致Beta中期流失？

4. 高级用户画像：描述您前10%最活跃Beta用户的行为特征；他们使用什么普通用户不用的提示策略；他们发现了哪些超出主要预期使用场景的用例；他们的反馈揭示了产品最高价值在哪里？

5. 引导启示：基于旅程分析，改进引导的最高影响机会在哪里？

输出：用户旅程叙述 + 高级用户画像 + 按影响排序的引导改进建议

提示词4 — Beta到上线的沟通包

基于以下Beta洞察创建Beta到上线的沟通包。

产品：[名称]
Beta项目摘要：[用户数、持续时间、关键人口统计]
关键Beta成就：[Beta期间基于反馈改进了什么]
上线时已知的剩余问题：[诚实列出仍不完善的内容]
目标上线受众：[谁将收到上线沟通]

创建沟通包（5个文档）：上线公告、Beta用户推荐请求模板、上线博客文章段落"与Beta社区共建"、内执行团队上线就绪备忘录、客户成功团队简报。

输出：完整的Beta到上线沟通包，所有5个文档已准备好供审查和分发

提示词5 — Beta到路线图情报报告

从以下Beta反馈合成中提取路线图情报。

产品：[名称]
Beta合成摘要：[粘贴或描述您的Beta反馈合成发现]
当前路线图（未来2个季度）：[列出计划的功能/改进]
未来6个月的战略问题：[需要回答哪些产品方向问题]

提取路线图情报：

1. Beta中发现的未满足需求：哪些用户问题在Beta中出现但当前产品或路线图未解决？

2. 意外使用场景：Beta用户将产品应用于哪些原始设计意图之外的使用场景？

3. 能力上限信号：Beta用户在哪里明显触碰到当前AI能力的极限，频率如何？

4. 定位洞察：Beta反馈揭示了用户如何看待产品相对于替代品的位置？

5. 建议的路线图调整：加速、添加、降低优先级、研究后再承诺。

输出：具有具体建议的路线图情报报告 + 支持证据 + 优先级排序理由

27. AI竞争产品拆解分析器

系统性剖析竞争对手的AI产品，发现能力缺口、定位机会和战略薄弱点。

痛点与解决方案

痛点：AI竞品情报获取难，且竞品能力以模型速度迭代

AI产品的竞争分析与传统SaaS竞品情报有本质区别。竞争对手的AI能力随着模型提供商发布更新、微调模型改进以及提示词工程优化的积累，可能每月甚至每周都在变化。三个月前进行的竞品拆解往往已经过时——竞品的摘要质量有所提升、延迟下降了40%、或者新增了一种AI模态，彻底改变了竞争格局。

大多数AI产品团队缺乏持续竞品情报的系统化流程。他们在竞争对手发布值得关注的新功能时才偶尔进行拆解，而错过了逐步积累成显著竞争差距的增量能力改进。产品经理依赖销售团队的轶事印象（"他们看了演示，说对方在X方面更好"），而不是能够真正支持基于证据的战略决策的系统化、可重现质量基准。

评估挑战在技术层面也很苛刻。评估LLM输出质量需要领域专业知识、结构化评估标准和足够的样本量来区分真正的质量差异与输出方差。大多数产品团队没有基础设施来运行系统化的并排比较，有的团队也经常衡量错误的事情——与特定领域实际用户任务完成率不相关的基准性能。

COCO如何解决

1. 竞争对手功能映射与能力评估：COCO结构化系统性竞品分析：

   • 跨产品能力、AI模态、集成、定价和定位生成功能比较矩阵
   • 创建能力基准框架：可对多个产品运行的标准化评估任务，以进行可重现的比较
   • 设计AI产品的"神秘顾客"评估协议：揭示AI能力水平而不触发防爬虫保护的脚本交互序列
   • 生成技术架构推断：从可观察的产品行为推断可能的模型选择、RAG方案和安全实现
   • 创建竞争对手时间线重建：记录能力出现时间以了解竞对开发速度

2. AI质量基准设计：COCO创建严格的比较评估框架：

   • 为特定领域设计基准套件：代表竞争空间中实际用户工作流的任务集
   • 创建并排质量比较的评估标准：带有具体标准的逐维度评分
   • 规定统计意义显著的质量比较所需的样本量和多样性要求
   • 设计对抗探针集：旨在揭示模型质量差异、故障模式和安全护栏的查询
   • 生成基准结果分析框架：如何解读质量差异并将其转化为用户体验影响

3. 定位缺口分析：COCO识别战略机会：

   • 分析竞争对手消息与实际产品能力的对比——识别造成用户预期差距的过度主张
   • 将公开评论中的客户投诉主题映射到竞对能力缺口——在哪里竞争
   • 识别所有竞争对手都没有的"白色空间"能力，代表差异化机会
   • 分析竞争对手目标市场信号：他们在赢谁和输给谁，基于客户案例研究和评论
   • 生成定位差异化框架：在哪里可以可信地主张优势以及如何表达

4. 竞争对手战略推断：COCO将情报合成为战略模型：

   • 从产品开发轨迹和功能排序推断竞对AI投资优先级
   • 分析竞争对手合作伙伴关系和集成公告的战略方向信号
   • 从职位发布、研究论文和会议演讲识别可能的竞对路线图方向
   • 生成"竞争威胁场景"：未来6个月竞争对手可能采取的3–5个最具影响力的行动及缓解策略
   • 创建"竞争护城河评估"：哪些产品优势是持久的，哪些容易被有能力的竞争对手复制

5. 赢/输分析整合：COCO将竞品情报与销售结果相连接：

   • 为AI能力是决定因素的交易设计结构化赢/输访谈框架
   • 创建竞争丢单模式分析：识别最常导致竞争丢单的具体AI能力缺口
   • 生成"作战卡"内容：面向销售和客户成功团队的简洁、准确的竞争比较内容
   • 设计竞争异议响应框架：如何在销售对话中处理常见的竞品比较
   • 创建"证明点"需求：什么证据（基准、案例研究、演示）最能有效解决竞争劣势

6. 持续竞品监控系统：COCO设计持续情报项目：

   • 创建竞争对手变化检测协议：监控什么以及多频繁监控能力变化
   • 设计竞争告警触发器：应立即触发竞争重新评估的事件
   • 为高层消费生成具有标准化结构的季度竞争格局报告
   • 生成竞争响应手册：针对可能的竞争对手行动的预先批准的战略响应
   • 设计竞品情报共享流程：如何高效地在产品、销售和市场营销中分发竞争洞察

量化结果与受益角色

可量化的成果

• 竞品情报新鲜度：系统监控项目每月产生竞品更新，而临时季度拆解的平均情报年龄从3个月减少到3周
• 胜率提升：拥有准确AI作战卡的销售团队在一对一评估中竞争胜率提升15–25%
• 功能优先级：竞争缺口分析识别了30–40%的战略上最重要的路线图项目
• 定位效果：拥有经验证竞争差异化的产品比无差异定位实现20–30%更好的营销转化
• 竞争威胁预测：拥有竞对监控的团队在2周内发现重要能力发布，而依赖新闻监控的团队需要6–8周

受益人群

• AI产品经理：获得系统化、基于证据的竞品情报，而不是依赖销售团队印象和新闻监控
• 销售团队：获得准确、最新的作战卡，能用诚实、可信的响应处理真实竞争异议
• 市场营销团队：获取由基准数据支持的经验证竞争差异化主张，而非无根据的断言
• 高层管理：准确理解竞争格局，用于战略规划和投资者沟通

💡 实用提示词

提示词1 — AI竞争对手能力拆解

对以下AI竞争对手产品进行系统性能力拆解。

您的产品：[名称、主要使用场景、目标用户]
竞争对手产品：[名称、URL、主要定位]
评估重点：[哪些能力对您的市场竞争差异化最重要]

拆解框架：

1. 核心AI能力评估：
使用提供的测试查询测试以下能力类别，记录结果：

能力1：[如长文档摘要]
测试查询：[提供具体测试提示]
评估标准：[准确性、完整性、简洁性、格式]
您的产品结果：[粘贴输出]
竞争对手结果：[粘贴输出]
比较评估：[谁做得更好以及为什么]

2. 质量一致性评估、故障模式映射、UX和产品质量评估、定价与定位分析

输出：能力比较矩阵 + 按维度质量胜者 + 竞争定位分析 + 对您产品的战略意义

提示词2 — AI产品作战卡生成器

为销售团队生成与[竞争对手名称]竞争时使用的竞争作战卡。

您的产品：[名称]
竞争对手：[名称]
最常见的竞争场景：[您最常一对一竞争的场景]
您的关键差异化因素：[您真正做得更好的——要诚实，不是希望性思维]
您的已知弱点：[您较弱的地方——销售团队也需要知道]
销售中听到的常见异议：[潜在客户在考虑竞争对手时说的具体话]

生成作战卡（6个部分）：快速摘要、功能比较表、竞争异议处理、引导性问题、竞争情况的演示流程、证明点和参考资料

输出：完整作战卡（可供销售团队使用格式）+ 内部弱点注释（与客户版分开）

提示词3 — 竞争缺口分析与路线图输入

分析竞争缺口以指导产品路线图优先级排序。

市场背景：[描述您所在的竞争AI产品市场]
您的产品：[能力、当前路线图、战略优先级]
主要竞争对手：[列出3-5个主要竞争对手及简要能力描述]
目标客户群体：[您试图赢得的用户]

竞争缺口分析包括：缺口识别矩阵、缺口优先级排序、差异化机会、"门槛"vs"差异化因素"、路线图建议

输出：缺口分析矩阵 + 优先缺口闭合路线图 + 差异化投资建议

提示词4 — AI质量基准设计

为以下竞争背景设计可重现的质量基准，以比较AI产品。

市场细分：[描述AI产品类别]
主要基准使用场景：[列出该市场买家最重要的3-5个使用场景]
待基准的产品：[列出您的产品 + 2-4个竞争对手]
基准消费者：[谁将使用这些结果]

设计基准（任务套件、评估方法论、基准有效性、结果呈现、外部使用案例）

输出：完整基准规格 + 评估标准 + 结果呈现模板 + 有效性评估

提示词5 — 竞争威胁场景规划

为战略规划制定竞争威胁场景。

您的产品：[名称和战略定位]
主要竞争对手：[列出及简要描述]
市场趋势：[影响此竞争空间的相关行业趋势]
您的战略脆弱性：[诚实评估您面临风险的地方]
规划期：[6个月/12个月/18个月]

制定5个竞争威胁场景，每个包括：场景描述、概率评估、影响评估（包括多个维度）、预警信号和缓解选项（主动/被动/转型）。

输出：5个竞争威胁场景 + 战略优先级矩阵 + 预警信号监控清单

28. AI产品定价策略建模器

设计能最大化价值捕获、同时驱动采用、留存和可持续单位经济的AI产品定价体系。

痛点与解决方案

痛点：AI产品面临标准SaaS定价模型无法处理的定价挑战

AI产品定价是AI产品生命周期中最关键、也最频繁搞砸的决策之一。根本挑战在于：AI产品的成本结构无法干净地映射到传统SaaS定价模型。推理成本随使用量实时增长，使得固定费率订阅定价在高使用量时经济上很危险。但按量计费又会产生焦虑和不可预测性，抑制采用，尤其在企业市场中——预算持有人需要可预测的支出。

复合问题是AI产品经理往往没有足够的信号来自信地定价。传统SaaS定价研究——问卷、联合分析、竞品对标——对AI产品不够用，因为AI产品交付的价值因用户提示能力、底层模型质量和具体使用场景而大相径庭。通过优越提示技巧从同一产品中提取10倍价值的用户，在固定费率定价下实际上是在补贴普通用户。由此产生的逆向选择问题——重度用户产生不成比例的成本，而轻度用户补贴他们——破坏了单位经济。

企业定价复杂性进一步加剧。企业买家期望批量折扣、承诺使用折扣、定制条款和ROI保证。他们还需要采购透明度——他们需要了解购买了什么、花了多少钱、有什么控制措施。对自助服务消费者运作良好的AI产品定价，在企业场景中往往完全失败，因为缺乏企业采购所需的可预测性、治理和价值证明。

COCO如何解决

1. 定价模型架构设计：COCO评估和设计定价结构：

   • 分析AI产品特有的定价模型权衡：固定费率订阅、按量计费、按席位、按结果和混合方案
   • 在不同用户行为场景（轻度用户、普通用户、重度用户）下对每个定价模型的单位经济建模
   • 设计混合定价结构：将可预测的订阅底价与使用量上限或超额计量相结合
   • 创建定价层级架构：定义AI产品功能差异化的好/更好/最好维度
   • 生成定价模型决策框架：为特定市场细分和产品成熟度阶段选择正确定价架构的结构化标准

2. AI专项价值指标识别：COCO识别正确的定价单位：

   • 评估候选价值指标（按查询、按用户、按处理文档、按实现结果、按节省时间）与客户价值对齐、易于测量和定价可操作性的对比
   • 设计价值指标研究：发现客户直觉上与价值交付关联的指标的结构化方法
   • 创建价值指标敏感性分析：在不同使用模式下每个指标选择下定价如何变化
   • 生成价值指标演进路线图：随着产品成熟和价值交付变得更可测量，定价单位可能如何转变
   • 设计防博弈保护：防止客户以破坏单位经济的方式博弈定价指标

3. 推理成本建模与利润率分析：COCO为定价决策构建财务模型：

   • 创建每单位成本模型，纳入模型API成本、基础设施开销和支持成本分摊
   • 按客户群体和使用模式设计贡献利润率分析
   • 对模型改进的单位经济影响建模：优化或更便宜模型选项的成本降低如何影响定价策略
   • 生成定价底线计算：在每个客户群体预期使用量下达到目标利润率所需的最低价格
   • 创建场景模型：在不同定价结构下以10倍、100倍当前规模的单位经济如何演变

4. 支付意愿研究设计：COCO结构化定价研究：

   • 设计Van Westendorp价格敏感度研究，适配AI产品定价研究
   • 创建AI产品功能/价格权衡研究的联合分析框架
   • 生成定价发现的客户访谈指南：在不引导的情况下提取支付意愿信号
   • 设计竞争价格锚定研究：客户如何根据替代品校准价值感知
   • 生成定价实验设计：如何在不破坏信任的情况下对现有客户测试定价变化

5. 企业定价与包装设计：COCO创建企业级定价结构：

   • 设计具有正确维度的企业定价层级：承诺使用折扣、批量区间、功能访问级别、SLA层级
   • 创建企业定价计算器：销售团队快速生成准确、可辩护报价的工具
   • 设计消费治理功能：企业采购需要的支出上限、管理员控制、预算告警
   • 生成ROI模型模板：向CFO级买家量化AI产品价值以证明企业定价合理的框架
   • 创建企业定价手册：谈判指导、折扣审批门槛、定制条款参数

6. 定价变更管理：COCO管理定价演进：

   • 为定价变更时现有客户设计祖父条款策略
   • 创建价格上涨的客户沟通框架：顺序、消息和异议处理
   • 设计价格上涨实验协议：如何在不损害客户信任的情况下测试定价变化
   • 生成流失影响模型：预测不同定价变更场景下的流失率
   • 创建定价推出手册：分阶段实施新定价，并附监控和回滚标准

量化结果与受益角色

可量化的成果

• 每用户收入：精心设计的AI定价比朴素定价方案多捕获25–40%的每用户收入，实现价格与价值交付对齐
• 单位经济改善：混合定价模型（订阅+使用量）对高使用量AI产品比纯固定费率实现15–30%更好的毛利率
• 企业合同规模：基于ROI的企业定价比单纯功能定价将平均企业合同价值提升20–35%
• 定价研究效率：结构化支付意愿研究将定价决策周期从3个月缩短到4–6周
• 定价变更流失：有计划、有沟通的定价过渡比突然提价减少40–60%的流失

受益人群

• AI产品经理：基于经济建模和市场研究而非单纯竞品对标做出自信的定价决策
• CFO/财务团队：获得严谨的单位经济模型，在不同增长场景下准确预测收入和利润率
• 销售团队：获得能加速企业交易、减少折扣压力的定价结构和计算器
• 客户：体验透明、可预测的定价，随其获得的价值公平扩展

💡 实用提示词

提示词1 — AI定价模型架构分析

为以下AI产品分析并推荐定价模型架构。

产品：[名称、描述、主要使用场景]
阶段：[上线前/早期增长/规模扩张]
目标细分市场：[消费者/中小企业/企业/混合]
当前定价（如有）：[现有定价结构]
主要竞争对手的定价：[描述2-3个竞争对手的定价]
单位经济数据：模型API成本、基础设施开销、目标毛利率
用户行为数据（如有）：平均查询、重度用户查询、轻度用户查询

分析定价模型选项（固定费率订阅、纯按量计费、混合、按结果），包括各自的单位经济计算。

推荐：哪个模型最适合此产品、细分市场和阶段？用单位经济论证。

输出：定价模型分析 + 带论证的推荐 + 实施考量

提示词2 — AI产品定价层级设计

为以下AI产品设计三层定价结构。

产品、目标细分市场、核心AI能力、竞争对手定价基准、单位经济、战略目标

设计三个定价层级（基础/核心/企业），每层包括：价格、目标用户、包含的AI能力、使用限制、升级触发因素、单位经济

差异化分析：层级间升级是否足够有吸引力？是否有能力放错层级？

输出：定价层级规格 + 差异化分析 + 建议的A/B测试

提示词3 — 面向企业销售的AI产品ROI模型

为以下AI产品向企业客户销售构建ROI模型。

产品、企业价格、目标买家、交付的主要价值、可比较的人工成本

构建ROI模型（价值量化框架、ROI摘要计算、ROI模型工具设计、按价值驱动因素的客户证据、CFO异议处理）

输出：带公式的ROI模型 + 发现问题脚本 + 单页摘要模板 + CFO异议响应

提示词4 — 推理成本优化与定价影响分析

分析以下推理成本场景及其对AI产品定价策略的影响。

分析5个场景：当前状态、更便宜的模型选项、微调小模型、缓存和优化、多模型路由

对每个场景：单位经济影响、定价策略含义、客户体验影响、实施优先级建议

输出：成本场景分析表 + 定价策略影响 + 推荐优化路线图

提示词5 — 价格上涨沟通策略

为以下AI产品情况设计价格上涨策略。

产品、当前定价、拟议新定价、上涨原因、当前客户群体、高风险客户、时间线

设计策略（客户细分方案、沟通顺序、每次沟通的消息框架、高风险客户留存干预、流失预测和监控）

输出：价格上涨策略文档 + 沟通顺序 + 每个触点的消息草稿 + 流失监控计划

29. AI安全红队场景生成器

在对抗性用户在生产中发现之前，系统性探测您的AI产品的安全漏洞。

痛点与解决方案

痛点：被动安全防御失效——对抗性用户的速度超过事后修复

AI产品安全失败遵循一个可预测且代价高昂的模式：产品带着遗漏了真实世界对抗条件的内部安全测试上线，对抗性用户在上线后数天或数周内发现并利用漏洞，漏洞在社交媒体或黑客论坛上病毒式传播，产品团队在声誉损失积累的同时被动地进行修补，高层要求解释为何安全测试没有发现这个问题。这个循环反复发生，因为大多数AI产品团队基于明显的、预期的攻击模式进行安全测试，而不是系统性地绘制潜在滥用的完整表面积。

红队缺口是资源和专业知识问题。彻底的AI安全红队测试需要对抗性创造力——想象坏演员、脆弱用户和好奇探索者可能如何滥用系统——以及对LLM故障模式、提示词注入向量、越狱技术和社会技术危害路径的技术知识。大多数产品团队既没有时间也没有专业知识，在发布压力迫使发货决策之前进行彻底的红队测试。

监管环境使这个问题的代价越来越高。欧盟AI法案要求高风险AI系统的合规评估，包括对抗性测试。美国AI安全行政命令越来越期望部署AI的组织展示系统性安全评估。进行安全审查的企业买家现在例行要求红队报告作为尽职调查的一部分。没有进行系统性红队测试的产品团队无法回答这些问题，面临监管风险和企业交易损失。

COCO如何解决

1. 威胁模型开发：COCO创建结构化安全威胁模型：

   • 定义对手画像：好奇用户、竞争情报研究者、寻求有害输出的坏演员和自动攻击脚本
   • 绘制攻击表面积：提示词注入、越狱尝试、数据提取、能力滥用、偏见利用和拒绝服务攻击
   • 识别对对手高价值的目标：坏演员最想从这个AI系统中提取或完成什么
   • 创建危害分类法：按类型（身体、心理、财务、声誉、社会）、严重程度和可逆性对潜在危害分类
   • 设计威胁优先级矩阵：按概率、影响和利用难度对威胁排序

2. 红队场景生成：COCO生成全面的测试场景库：

   • 生成提示词注入攻击场景：尝试覆盖系统提示词、提取隐藏指令或重定向AI行为
   • 创建越狱场景变体：角色扮演攻击、假设性框架、多步骤升级、编码规避技术
   • 设计社会工程场景：旨在逐渐引出不安全输出的多轮对话
   • 生成偏见和公平性探针场景：旨在揭示跨人口群体歧视性输出的输入
   • 创建能力边界探针：测试系统在被要求做不应该做的事情时的表现

3. 结构化红队测试协议：COCO创建系统评估框架：

   • 设计红队测试执行协议：测试人员如何处理每个场景类别、记录什么、什么构成"发现"
   • 创建发现严重程度分类：从外观问题到需要立即补救的关键安全失败
   • 生成误报管理：区分真正的安全失败与过度保守的拒绝（损害用户体验）
   • 设计多层测试：在模型层、提示词层、应用层和输出层独立测试安全
   • 创建测试覆盖率指标：如何评估威胁表面积的多少已被测试

4. 缓解策略设计：COCO为发现的漏洞推荐补救措施：

   • 分析安全失败的根本原因：系统提示词弱点、模型能力限制还是应用设计缺陷
   • 设计分层缓解方法：针对不同漏洞类型的输入过滤、输出过滤、提示词加固和人工审核
   • 创建缓解有效性测试：如何验证缓解措施真正有效而不引入新的失败模式
   • 生成残余风险文档：对无法完全缓解的漏洞进行诚实评估并说明如何管理
   • 设计安全回归测试：确保缓解措施不会随着模型更新或提示词变化而随时间退化

5. 持续红队项目设计：COCO建立持续安全流程：

   • 设计上线前红队关卡：任何模型更新或主要功能上线前必须满足的安全要求
   • 创建AI安全漏洞赏金项目：外部研究人员报告AI安全漏洞的结构化流程
   • 生成对抗性监控系统：检测生产日志中的潜在利用尝试
   • 设计自动安全回归测试：在每次部署时自动运行的测试套件，以发现安全回归
   • 创建安全事件响应手册：在生产中发现安全漏洞时如何响应

6. 监管与企业安全文档：COCO生成合规就绪的安全证据：

   • 生成适合欧盟AI法案合规文档格式的红队报告
   • 创建覆盖AI安全实践的企业安全问卷响应
   • 生成带安全测试部分的模型卡，记录红队方法和发现
   • 设计安全顾问委员会演示文稿：如何向董事会级受众传达安全实践
   • 创建负责任披露模板：向监管机构或受影响方传达安全发现

量化结果与受益角色

可量化的成果

• 上线前漏洞发现：系统性红队测试在上线前发现70–80%的可利用安全漏洞，而仅内部QA只发现20–30%
• 首次利用时间延长：进行了上线前红队测试的产品在上线后3–5倍晚才经历首次对抗性利用，留出了更多从容的响应时间
• 企业安全审查通过率：拥有红队文档的产品比没有安全测试文档的产品快50%通过企业安全审查
• 监管就绪性：红队报告通过提供所需的对抗性测试证据，将欧盟AI法案合规评估时间减少30–40%
• 声誉事件预防：系统性安全测试预防了病毒式"越狱被发现"的社交媒体时刻，这类事件会使AI产品损失15–30%的品牌价值

受益人群

• AI产品经理：向利益相关者和监管机构展示负责任的AI实践，并有文档记录的系统性安全流程
• 工程/ML团队：获得具体、可重现的漏洞报告，指导有针对性的安全改进
• 法务与合规团队：获得监管合规和企业安全审查所需的文档
• 企业客户：对AI产品安全实践建立信心，减少采购摩擦、加速合同签署

💡 实用提示词

提示词1 — AI安全威胁模型生成器

为以下AI产品生成全面的安全威胁模型。

产品：[名称和描述]
主要AI能力：[AI可以做什么——要具体]
用户群体：[谁使用它，包括任何脆弱群体——未成年人、危机中的人、财务脆弱者等]
数据访问：[AI可以访问或输出什么数据——个人数据、财务数据、代码执行、外部API]
部署背景：[消费者应用/企业软件/API/嵌入第三方产品]
已知敏感领域：[AI可能被询问敏感话题的任何领域——健康、法律、财务、关系]

生成威胁模型（对手画像、攻击表面积地图、危害分类法、风险优先级矩阵、当前控制评估）

输出：威胁模型文档 + 风险矩阵 + 优先红队重点领域

提示词2 — 越狱与提示词注入测试套件

为以下AI产品生成越狱和提示词注入漏洞的红队测试套件。

产品、系统提示词特征、系统设计为执行的主要限制、部署方式

为每个攻击类别生成测试场景：直接越狱尝试、提示词注入攻击、多轮升级技术、编码和规避技术

每个类别5个具体提示词模板，带测试说明

输出：完整红队测试套件 + 每类别的测试执行指南 + 发现记录模板

提示词3 — AI偏见与公平性探针

为以下AI系统生成偏见和公平性探针。

系统、主要使用场景、可能影响输出的人口属性、部署背景

针对5个偏见类别生成探针：人口结果偏见、代表性偏见、语言和文化偏见、历史偏见放大、交叉偏见

分析框架：测试方法、可接受差异阈值、发现记录、问题升级程序

输出：完整偏见探针套件 + 测试执行指南 + 公平性测试结果记录模板

提示词4 — 红队发现报告生成器

将以下红队测试结果合成为结构化报告。

产品、测试范围和时间线、测试方法、测试结论

合成报告（执行摘要、发现目录、严重度分析、缓解建议、残余风险、测试局限性、再测试建议）

输出：完整红队报告 + 发现跟踪表 + 向高层和监管机构的演示摘要

提示词5 — AI安全持续监控设计

为以下AI产品设计上线后持续的安全监控系统。

产品、已知漏洞（红队结果）、基础设施（日志记录、告警）、运营约束

设计持续监控（生产对抗检测信号、监控实现规格、告警阈值和响应、定期安全回顾流程、社区驱动的漏洞报告）

输出：监控设计规格 + 实现指南 + 告警响应手册 + 持续改进流程

30. AI产品用户引导流程优化器

设计AI产品引导体验，让困惑的新用户在第一次会话中就成长为自信的高级用户。

痛点与解决方案

痛点：AI产品引导失败，因为用户不知道自己不知道什么

AI产品引导面临一个独特的困难挑战：产品的价值往往是潜在的，只有知道如何有效互动的用户才能解锁。与具有确定性输出的传统SaaS工具不同，AI产品奖励理解提示词策略、上下文设置技巧和模型能力边界的用户。带着传统软件期望——"点击这里，获得结果"——接近AI产品的首次用户，往往产生平庸的输出，得出产品不适合自己的结论，并在体验到产品真正潜力之前就流失了。

数据证实了这一模式。AI产品通常看到40–60%的新用户在第一次会话中从未获得有意义的结果。在确实获得结果的用户中，只有30–40%在第一周深度参与，足以养成使用习惯。产品的实际能力对这些数字几乎无关紧要——瓶颈完全在于引导体验和用户提取价值的能力。拥有出色引导的劣质AI产品在留存指标上会胜过引导糟糕的优质产品。

大多数AI产品团队对糟糕引导的响应是更多文档——更长的教程、更好的帮助文章、更多示例提示词。这些干预效果有限，因为真正的问题不是信息缺失——而是体验缺失。用户需要在第一次会话中拥有一次成功的、令人难忘的AI交互，才能产生"这个产品可以为我所用"的信念。实现这一点需要主动设计引导路径，在认知疲劳或挫败感触发放弃之前早早交付"惊喜时刻"。

COCO如何解决

1. 引导旅程映射：COCO设计从注册到习惯养成的最优路径：

   • 绘制理想的第一次会话弧线：注册→第一次交互→第一次成功→第二使用场景发现→习惯触发
   • 识别"最小可行成功"——展示真正产品价值的最简单、最快速的交互
   • 设计首次价值时间优化：消除从到达到第一次有意义AI输出之间的所有摩擦
   • 创建引导分支点：针对具有不同起始上下文、技能水平和使用场景的用户的不同路径
   • 生成引导成功指标：什么行为信号表明用户走在留存路径上，什么信号预示流失

2. AI能力介绍排序：COCO为最大影响排序功能介绍：

   • 设计能力揭示序列：从简单、高成功率的交互开始，然后再介绍复杂能力
   • 创建"提示词脚手架"系统：帮助新用户在还没有开发提示技巧之前就产生好的输出的结构化模板
   • 生成能力里程碑映射：基于用户准备度，什么能力在第1、3、7、30天介绍
   • 设计"我不知道它能做这个"时刻：令人惊喜的能力揭示，在用户已经参与时出现
   • 创建期望校准内容：帮助用户了解AI擅长什么、哪里有局限，防止早期挫败

3. 个性化引导路径设计：COCO创建自适应引导：

   • 设计基于角色的引导路径：针对不同用户类型（技术vs非技术、不同行业、不同使用场景）的不同初次体验
   • 创建以使用场景为先的引导：从用户声明的待完成任务开始，而非通用产品导览
   • 生成渐进式信息披露框架：随着用户展示准备度，逐渐揭示产品复杂性
   • 设计行为分支：根据观察到的用户行为而非声明偏好调整引导流程
   • 为在引导过程中退出的用户生成重新参与干预：针对特定摩擦点的有针对性提示

4. 提示词教育系统设计：COCO教用户获得更好的输出：

   • 创建分层提示词教育：从复制粘贴模板开始，逐渐教授有效提示词背后的原则
   • 设计"展示差异"演示：弱与强提示词产生截然不同输出的并排比较
   • 生成提示词模式库：针对最常见使用场景的精心策展的提示词结构，可供用户定制
   • 创建提示词改进反馈：基于模式识别的产品内提示词改进建议
   • 设计提示词技能进阶：随时间追踪用户提示词成熟度，并在准备好时介绍高级技术

5. 激活指标监控：COCO定义和衡量引导效果：

   • 设计激活事件定义：对于这个AI产品，什么具体行为构成"已激活"
   • 创建引导漏斗监控：追踪从注册到激活每个步骤的流失率
   • 生成群体分析框架：比较不同用户获取渠道、用户类型和引导变体的激活率
   • 设计引导实验协议：如何以统计严谨性A/B测试引导变体
   • 创建引导健康仪表板：实时了解用户在哪里卡住以及为什么

6. 再引导与功能采用项目：COCO驱动持续功能采用：

   • 为已激活但未使用产品最有价值功能的用户设计再引导活动
   • 创建里程碑触发的教育：当用户达到特定使用里程碑时自动提供正确指导
   • 生成高级用户发展项目：将普通用户转变为高级用户的结构化路径
   • 设计新功能引导：确保现有用户在新能力上线时发现并采用
   • 创建流失预防干预：识别显示参与度下降信号的用户并触发有针对性的重新参与

量化结果与受益角色

可量化的成果

• 第1天激活率：优化的AI产品引导通过结构化"惊喜时刻"工程，将首次会话成功率从40%提升到65–75%
• 7天留存：体验过成功首次会话的用户留存率是没有体验过的用户的2–3倍，使引导成为最高杠杆的留存投资
• 首次价值时间：结构化引导将新用户的平均首次价值时间从15–20分钟缩短到3–5分钟
• 功能采用率：排序的能力介绍比自行探索将高级功能采用率提升40–50%
• 支持工单减少：有效引导通过主动解决常见困惑点，将第一周支持工单减少35–45%

受益人群

• AI产品经理：获得最高ROI的留存干预——改善引导始终比任何其他产品投资产生更好的每元留存改善
• 增长团队：通过将更多试用转化为留存用户，从现有用户获取支出中获得更好的单位经济
• 客户成功团队：接收需要更少手把手指导、更快实现价值的受过更好教育的用户
• 最终用户：从第一天起就体验一个为其服务的产品，建立驱动长期忠诚度的信心和信任

💡 实用提示词

提示词1 — AI产品引导流程设计

为以下AI产品设计全面的引导流程。

产品：[名称和主要使用场景]
目标用户：[描述主要用户——技术成熟度、角色、背景]
当前引导（如有）：[描述现有内容或"无"]
关键激活行为：[什么是"已激活"用户做的？预测留存的具体行为或结果是什么？]
新用户第一周流失的主要原因：[反馈或数据告诉您早期流失原因]

设计引导流程（首次会话前准备、第一次会话设计目标<5分钟到首次价值、第一周旅程、提示词脚手架系统、退出恢复干预）

输出：完整引导流程规格 + 每个触点的文案 + 每个阶段的成功指标

提示词2 — 引导文案与消息工具包

为以下AI产品编写引导文案和消息。

产品、主要用户、核心价值主张、最常见的首次使用场景、语气指南、已知用户焦虑

编写引导文案（欢迎邮件、首次登录欢迎消息、第一次交互提示词建议、"顿悟时刻"确认文案、第3天邮件、功能介绍工具提示系列、空状态文案、引导完成消息）

输出：完整引导文案工具包 + 未来文案的语气指南 + 国际用户本地化注意事项

提示词3 — 基于角色的引导路径设计器

为以下AI产品的不同用户群体设计个性化引导路径。

产品、用户群体（3-4个关键用户类型及其需求）

对每个群体设计定制引导路径：用户群体识别方式、起点假设、首次交互设计（开场框架、建议的首个使用场景、脚手架提示词、预期"顿悟时刻"）、第一周路径、成功指标

跨群体考虑：哪些引导元素适用于所有群体不需要个性化？最小分割需求是什么？

输出：每个群体的个性化引导路径 + 实施复杂性评估 + 分阶段个性化路线图

提示词4 — 引导实验设计

设计一系列A/B实验以优化以下AI产品引导漏斗。

产品和当前引导漏斗指标（注册→首次会话、首次会话→首次AI交互等转化率）

最大流失点及当前引导元素描述

设计针对最大流失点的5个A/B实验（每个包含假设、对照组、处理组、主要指标、辅助指标、样本量、持续时间、实施复杂性和预期学习价值）

实验优先级排序（按预期影响×学习价值÷实施工作量）

输出：5个A/B实验设计 + 优先级排序 + 实验日历 + 每个的成功标准

提示词5 — 引导提示词库构建

为以下AI产品的新用户引导构建全面的提示词库。

产品和主要使用场景、目标用户角色、要展示的核心能力、提示词成熟度目标

构建提示词库（4个级别）：

级别1——入门提示词（复制粘贴即用，无需定制）：10条涵盖主要使用场景

级别2——模板提示词（简单填空，1-2个变量）：10条带占位符的模板

级别3——结构化提示词（更复杂，需理解上下文、目标和约束）：10条展示有效提示词结构的示例

级别4——高级技巧：5条演示高级提示词技术（思维链、少样本示例、角色规格、迭代精炼、多步骤分解）

提示词进阶指南和常见新手错误恢复指南

输出：完整35条提示词库 + 进阶指南 + 失败恢复指南 + 本地化就绪模板格式

31. AI模型卡与产品文档生成器

生成企业买家、监管机构和AI素养用户所要求的技术文档——而不让团队被淹没在文档工作中。

痛点与解决方案

痛点：AI产品文档是竞争和监管要求，但团队正在忽视这一点

过去两年，企业AI采购发生了根本性变化。安全审查现在包含AI专项问题，法务和采购团队在签署任何AI供应商合同之前都会提出：模型是如何训练的？使用了什么数据？进行了什么偏见测试？有哪些已知局限？模型出错时怎么处理？大多数AI产品团队无法用有文档记录的证据回答这些问题，导致交易延迟数周或数月，只能在特定客户请求时仓促拼凑文档。

监管压力在加速。欧盟AI法案第11条要求高风险AI系统的技术文档，包括训练数据的详细描述、测试方法、准确性指标和人工监督机制。美国AI行政命令越来越多地引用NIST AI RMF合规要求。金融服务监管机构明确要求模型风险管理文档（按SR 11-7指导）。医疗保健监管机构期望临床AI透明度。没有系统性文档，AI产品团队正在积累监管负债，这最终会以执法行动或审计失败的形式体现。

内部文档债务的成本随时间复利增长。每一个因文档而停滞的企业交易、每一个需要紧急响应的监管查询、以及每一次缺乏文档基线的内部事后审查，都代表着浪费的时间和错失的收入。维护活文档的团队——模型卡、数据集数据表、系统卡——比没有文档的产品快30–50%完成企业交易，并以大幅减少的混乱通过监管审查。然而文档在产品开发周期中普遍被降低优先级，因为它不发布功能。

COCO如何解决

1. 模型卡生成：COCO为每个AI组件生成全面的模型卡：

   • 按照Mitchell等人（2019）框架生成模型卡：模型详情、预期用途、因素、指标、评估数据、训练数据、定量分析、伦理考量、注意事项
   • 针对不同AI架构调整模型卡：微调LLM、RAG系统、分类模型、多模态模型
   • 创建面向不同受众的模型卡变体：技术版（面向ML工程师）、非技术版（面向商业买家）、监管版（面向合规审查员）
   • 设计模型卡维护协议：当模型更改、新评估完成或发现局限时如何更新卡片
   • 生成预先填充与产品AI架构和使用场景相关部分的模型卡模板

2. 数据集数据表文档：COCO记录训练和评估数据：

   • 按照Gebru等人框架生成数据表：动机、构成、收集过程、预处理/清理、使用、分发、维护
   • 创建训练数据透明度文档：使用了什么数据、来自哪里、如何获得许可、获得了什么同意
   • 生成评估数据集文档：测试集如何构建、涵盖什么、不涵盖什么
   • 记录数据预处理和增强：应用了什么转换及其对模型行为的潜在影响
   • 设计数据治理文档：数据血缘、保留策略、更新程序、访问控制

3. 系统卡生成：COCO创建系统级AI文档：

   • 生成描述完整AI系统（而非单个模型）的系统卡：架构、组件、集成点、故障模式
   • 创建安全评估文档：进行了什么安全测试、发现了什么、实施了什么缓解措施
   • 生成滥用文档：系统设计为预防的已知和潜在滥用及缓解有效性
   • 记录人工监督机制：人类在哪里参与循环、他们可以审查什么、他们可以覆盖什么
   • 创建更新和维护文档：系统如何监控、更新，以及什么触发重新评估

4. 企业AI透明度包：COCO创建企业采购文档：

   • 生成AI产品安全和合规概述：技术架构、数据处理、认证和访问控制
   • 创建标准AI采购问卷响应库：50个最常见企业AI采购问题的预起草答案
   • 为数据处理协议生成AI附录：AI数据使用、训练数据实践和子处理方披露的具体条款
   • 设计AI功能披露文档：清楚描述AI做什么、使用什么数据、客户控制什么
   • 生成AI事件响应承诺文档：什么构成可报告的AI事件、通知时间线和补救承诺

5. 监管合规文档：COCO使文档与监管框架对齐：

   • 按照欧盟AI法案第11条要求为适用AI系统风险类别生成技术文档
   • 创建NIST AI RMF对齐文档：将产品实践映射到治理、映射、测量和管理功能
   • 为医疗保健的FDA AI/ML SaMD文档结构、金融服务的SR 11-7模型风险管理文档生成行业专项文档
   • 设计文档更新协议：确保监管文档随模型和实践演进保持最新
   • 生成监管审计就绪包：为监管提交或第三方审计准备好的有组织文档

6. 面向用户的透明度文档：COCO创建面向最终用户的无障碍AI透明度：

   • 为产品页面编写AI披露：在不损害产品吸引力的情况下清楚地非技术解释AI如何使用
   • 创建产品内AI透明度界面：在交互点解释AI在做什么
   • 生成AI使用政策文档：想了解数据如何在AI中使用的用户的全面披露
   • 设计AI变更日志条目：以用户可理解的语言传达模型更新和能力变化
   • 创建用户常见AI问题的FAQ响应：它如何工作、使用什么数据、如何提供反馈

量化结果与受益角色

可量化的成果

• 企业交易周期：全面的AI文档包将企业采购审查时间减少30–50%，加速合同签署
• 监管审计准备：有组织的AI文档将监管审计响应时间从数周减少到数天
• 安全审查通过率：拥有预先准备的AI安全文档的产品比没有的快60%通过企业安全审查
• 文档生产时间：AI辅助的模型卡和文档生成比人工写作减少70%的文档生产时间
• 合规成本规避：主动文档预防了代价高昂的被动合规工作——估计每次避免的监管查询节省$50K–$200K

受益人群

• AI产品经理：满足监管和企业要求，不让文档瓶颈阻塞交易或引发合规风险
• 法务与合规团队：获得活文档而非对监管请求的紧急拼凑响应
• 企业销售团队：用预先准备好的文档包更快关闭交易，满足采购要求而无需定制拼凑
• 最终用户：获得关于AI产品如何工作的有意义透明度，建立知情信任

💡 实用提示词

提示词1 — 模型卡生成器

为以下AI系统生成全面的模型卡。

AI系统：[名称]
主要使用场景：[AI的设计用途]
模型类型：[微调LLM / RAG系统 / 分类器 / 基于API的LLM / 其他——描述架构]
基础模型（如适用）：[使用的底层模型]
训练/微调（如适用）：描述进行了什么微调、基于什么数据、为了什么目标
已完成的评估：[进行了什么测试——描述指标、数据集、结果]
已知局限：[对系统表现欠佳或失败情况的诚实评估]
目标用户：[这面向谁——描述用户群体]
非预期用途：[这不应用于什么]

按照以下章节生成模型卡：

## Model Details
- 模型名称和版本
- 模型类型和架构
- 训练或微调方法
- 主要使用场景
- 许可证

## Intended Use
- 主要预期用途：[具体设计的使用场景]
- 主要目标用户：[谁应该使用这个模型]
- 超出范围的用途：[这不应用于什么——风险管理的重要内容]

## Factors
- 相关因素：[影响性能的人口群体、环境条件、技术规格]
- 评估因素：[评估中考虑了哪些因素]

## Metrics
- 模型性能指标：[准确率、F1、BLEU、人类偏好、任务完成率——选择相关指标]
- 决策阈值：[部署决策中使用的置信度阈值]
- 变异方法：[性能在不同子群体或条件下的变化情况]

## Evaluation Data
- 用于评估的数据集：[描述数据集——来源、规模、构成、局限]
- 动机：[为什么选择这些数据集]
- 预处理：[应用了什么预处理]

## Training Data
- 训练/微调使用了什么数据？
- 来源和许可
- 训练数据中已知的偏差或局限

## Quantitative Analyses
- 单一结果：[总体性能指标及数值]
- 交叉结果：[在人口子群体或使用场景类别中的性能]

## Ethical Considerations
- 已知偏差：[记录的偏差及其缓解措施]
- 局限与风险：[该系统带来哪些风险，如何缓解]

## Caveats and Recommendations
- 使用最佳实践：[如何负责任地使用该系统]
- 已知失败模式：[导致性能下降的特定条件]
- 问题报告：[如何报告意外行为或危害]

输出：完整模型卡（可发布） + 带额外敏感细节的内部版本 + 维护协议

提示词2 — 企业AI采购包

为以下AI产品创建企业AI采购文档包。

产品、企业定价层级、关键AI能力、数据处理、安全认证、常见企业客户行业

创建采购包（5个文档）：AI产品概述（2页执行摘要）、技术AI架构概述（面向IT/安全审查员）、AI采购问卷预填响应（10个标准问题）、数据处理协议AI附录（关键条款）、AI事件响应承诺

输出：完整5文档采购包，专业呈现格式

提示词3 — 欧盟AI法案技术文档

为以下AI系统生成欧盟AI法案技术文档。

AI系统、风险分类（高风险/有限风险/最小风险）、预期用途和使用群体、AI组件详情、安全测试结果、人工监督机制

按照欧盟AI法案附录IV要求生成技术文档（10个部分）：系统描述、设计规格和开发过程、训练数据信息、测试和验证、监控和人工监督、鲁棒性和网络安全、透明度和提供信息、预期表现质量指标、相关风险和缓解措施、事后监控）

输出：完整合规技术文档 + 文档间隙分析 + 高风险系统额外要求

提示词4 — AI功能透明度界面设计

为以下AI产品功能设计面向用户的透明度界面。

功能、用户群体（技术成熟度、对AI的熟悉程度）、AI做什么以及如何工作（非技术）、已知局限、用户常见问题和担忧

设计透明度界面（3个部分）：交互点披露（在AI开始处理时向用户显示什么）、按需解释界面（用户可以请求更多信息时如何呈现）、反馈和改进机制（用户如何报告质量问题或提供反馈）

输出：透明度界面设计规格 + 所有界面元素的文案 + 辅助功能考量

提示词5 — AI变更日志生成器

为以下AI产品更新生成用户友好的变更日志条目。

产品、更新类型（模型更新/新功能/质量改进/安全改进）、受影响的具体变更、技术细节（内部，勿对用户披露）、观察到或预期的质量改进

生成4个变更日志变体（面向普通用户、技术用户、企业管理员、开发者/API用户），每个包含：标题、变更摘要（用其语言）、他们会注意到什么、如何提供反馈

输出：4个受众特定的变更日志条目 + 内部更新记录（供未来文档使用）

32. AI产品市场契合度信号检测器

识别区分真正产品市场契合度与早期采用者热情的行为信号——在过早扩张之前。

痛点与解决方案

痛点：AI产品将早期采用者的兴奋误认为是持久的产品市场契合度

AI产品上线会产生不成比例的初始热情。AI能力的新奇性驱动了技术爱好者、好奇AI的从业者以及急需解决方案愿意尝试任何新事物的用户的早期采用。前两个月的指标看起来令人惊叹——注册量、参与度、NPS——高层向团队施压进行营销和招聘扩张。然后现实来袭：留存曲线揭示大多数初始用户群体是在探索而非依赖产品，参与群体比注册量显示的要小得多，服务于流失用户的扩张单位经济是灾难性的负值。

AI产品的产品市场契合度信号问题在于，标准代理指标——NPS、功能使用、会话时长——被AI新奇效应污染。用户参与AI功能是因为AI很有趣，不一定因为它对其具体使用场景有价值。NPS分数反映的是与令人印象深刻技术互动的体验，而非针对用户实际待完成任务交付的价值。区分"认为这很酷的用户"与"工作流被真正改变的用户"需要衡量与传统SaaS产品根本不同的行为信号。

没有真正产品市场契合度就过早扩张的代价是严峻的。扩张营销、销售和基础设施来服务并不真正契合的用户群体，会加速烧钱率，同时产生流失、来自失望的不契合用户的负面口碑，以及为服务过多不兼容使用场景而稀释的产品焦点。成功扩张AI产品的公司，是那些在扩张到相邻用户之前，无情地识别出真正核心用户——产品对其不可或缺——的公司。

COCO如何解决

1. 产品市场契合度信号框架设计：COCO为AI产品定义正确的信号：

   • 为AI产品调整Sean Ellis的"40%法则"：衡量产品消失后用户的感受，按实际重度使用分段
   • 设计AI专项产品市场契合度行为信号：任务依赖（用AI做以前手动做的事）、AI优先工作流采用、主动分享和推荐
   • 创建AI产品市场契合度层级：区分好奇参与、价值参与和使命关键依赖
   • 设计基于群体的留存分析：将"真信徒"群体从多数中分离出来，分析什么使其与众不同
   • 生成产品市场契合度评分框架：将行为信号组合成单一产品市场契合度健康指标

2. 用户访谈与定性研究设计：COCO构建产品市场契合度发现研究：

   • 为AI产品设计"待完成任务"访谈框架：揭示用户雇用AI完成的功能性、情感性和社会性任务
   • 创建高级用户访谈指南：理解什么让产品对最依赖它的用户不可或缺
   • 生成流失访谈框架：理解为什么尝试过产品的用户没有找到产品市场契合度——识别产品市场契合度区域的边界
   • 设计"你会想念它吗"研究：AI产品的黄金标准产品市场契合度问题的结构化形式
   • 创建用户分群研究：识别单一连贯用户群体是否找到了产品市场契合度，还是信号在不兼容群体之间碎片化

3. 留存群体分析设计：COCO构建产品市场契合度测量的分析基础设施：

   • 设计第1天、第7天、第30天、第90天留存曲线，并附AI产品类别期望基准
   • 创建参与质量指标：区分高频率、高价值会话和高频率、低价值会话
   • 设计高级用户群体隔离：识别参与度前10–20%的用户，分析什么使其与众不同
   • 生成"魔法时刻"分析：识别预测长期留存的具体交互或交互序列
   • 创建分群级产品市场契合度分析：为不同用户类型单独测量产品市场契合度，识别核心vs周边群体

4. 领先指标识别：COCO识别在滞后指标确认前预测产品市场契合度的指标：

   • 分析从第一周信号预测90天留存的行为序列
   • 设计"激活事件"识别：第一次会话中最强力预测长期留存的单一行为
   • 创建工作流集成信号：表明用户已将AI集成到日常工作流（而非偶尔尝试）的指标
   • 生成社会证明信号：哪些用户行为（分享、推荐、公开提及）表明真正热情vs新奇兴趣
   • 设计"使用深度"指标：衡量用户是否在随时间将AI用于越来越重要或复杂的任务

5. 产品市场契合度区域定义：COCO帮助精确识别和描述产品市场契合度区域：

   • 分析与强产品市场契合度相关的用户特征：工作职能、使用场景、公司规模、技术成熟度
   • 创建产品市场契合度细分画像：详细描述产品已实现产品市场契合度的用户
   • 识别产品市场契合度边界：谁在产品市场契合度区域之外，需要什么变化（产品或定位）才能将他们纳入
   • 生成"前后"用户故事：因产品而工作流改变的高产品市场契合度用户的具体叙述
   • 设计产品市场契合度区域扩张策略：如何将产品市场契合度延伸到相邻群体而不失去核心

6. 规模就绪评估：COCO确定何时可以安全扩张：

   • 设计扩张决策的产品市场契合度阈值：表明产品市场契合度足以扩张营销投资的具体指标值
   • 创建扩张前风险评估：在扩张之前必须到位的产品和运营改进
   • 生成扩张模拟模型：如果营销扩张到更广泛受众，预测群体留存会是什么样子
   • 设计早期扩张实验：有限的营销投资，测试产品市场契合度是否延伸到相邻群体
   • 创建投资者沟通框架：如何向投资者传达产品市场契合度证据而不过度陈述信心

量化结果与受益角色

可量化的成果

• 扩张决策准确性：拥有系统性产品市场契合度测量的团队，在正确时机扩张的概率比依赖直觉或表面指标的团队高70%
• 流失预防：在扩张前识别产品市场契合度区域，可防止AI产品过早扩张导致的50–70%流失率
• 聚焦效率：产品市场契合度区域定义让团队将产品投资集中在产生80%留存用户的20%使用场景上
• 投资者信心：有文档记录的、行为化的产品市场契合度证据，以更高估值和更短尽职调查周期支持融资
• 营销ROI：扩张到确认的产品市场契合度细分市场，比在产品市场契合度之前进行广受众扩张产生3–5倍更好的营销ROI

受益人群

• AI产品经理：做出有信心的、基于证据的扩张决策，而不是对高层压力用轶事指标响应
• 增长团队：获得清晰的扩张目标标准——接触谁、用什么消息、通过什么渠道
• 投资者/董事会：获得支持具有信心的投资决策的严格产品市场契合度证据
• 高层管理：避免没有真正产品市场契合度的产品过早扩张所带来的灾难性烧钱加速

💡 实用提示词

提示词1 — AI产品产品市场契合度信号审计

审计以下AI产品的产品市场契合度信号。

产品和使用场景、当前阶段、可用数据（留存指标、NPS、"非常失望"调查结果、最活跃用户行为、流失主要原因、用户报告的主要使用场景、推荐行为）

进行产品市场契合度审计（信号强度评估、留存曲线分析、Sean Ellis测试解读、高级用户画像、产品市场契合度信心评级、下一步研究行动）

输出：产品市场契合度审计报告 + 信心评级 + 下一步研究优先级

提示词2 — 产品市场契合度发现访谈指南

为以下AI产品设计产品市场契合度发现访谈指南。

产品、当前假设、待访谈用户（留存高级用户、流失用户、近期注册）、访谈目标

设计访谈指南（4个部分：筛选和背景、待完成任务发现、价值评估、产品市场契合度专项探针）

访谈分析模板和合成框架

输出：访谈指南 + 分析模板 + 合成框架 + 每次访谈的产品市场契合度评分标准

提示词3 — 留存群体分析设计

设计留存群体分析以识别以下AI产品的产品市场契合度信号。

产品、商业模式、用户生命周期、可用数据

设计群体分析（群体定义、每个群体的留存指标、产品市场契合度指标群体分析、解读框架、可视化设计、决策框架）

输出：群体分析规格 + 实施指南 + 解读框架 + 决策触发器

提示词4 — 产品市场契合度区域定义与扩张策略

为以下AI产品定义产品市场契合度区域并设计扩张策略。

产品、强产品市场契合度证据、弱产品市场契合度信号、相邻机会

定义产品市场契合度区域（核心细分画像、产品市场契合度边界分析、扩张选项评估、扩张排序、扩张实验设计）

输出：产品市场契合度区域定义 + 扩张选项分析 + 排序建议 + 扩张实验设计

提示词5 — 投资者产品市场契合度沟通包

为以下AI产品创建面向投资者沟通的产品市场契合度证据包。

产品和阶段、融资背景、可用的产品市场契合度数据、最强证据、诚实的弱点

创建投资者沟通包（产品市场契合度叙事、证据幻灯片、留存数据呈现、用户引用框架、投资者产品市场契合度问题预准备响应）

输出：产品市场契合度证据包——叙事+幻灯片规格+数据呈现指南+用户引用框架+投资者Q&A响应

33. AI多模型路由与回退逻辑设计器

构建智能的模型编排体系，最大化质量、最小化成本，并在AI基础设施中保证可靠性。

痛点与解决方案

痛点：单一模型依赖制造质量、成本和可靠性危机

大多数AI产品从单一模型提供商开始——最新的前沿模型——无论任务复杂性、延迟要求或成本敏感性如何，都将所有用户请求路由到它。这种方法实现简单，但会产生三个复合问题：昂贵（前沿模型成本是许多任务上性能相当的专业或小型模型的10–50倍）、脆弱（模型提供商中断、速率限制或API变更导致完全服务中断），以及次优（将简单问题路由到强大的推理模型，与复杂的多步骤任务路由到同一模型，错过了巨大的质量和成本优化机会）。

随着AI产品扩展，成本问题变得生死攸关。一个向GPT-4o按$30/1M输出token收费、每月向用户收取$50的产品，对重度用户很容易产生$30–50/月的推理成本——在规模上的负毛利率。然而，典型的响应——将所有东西切换到更便宜的模型——会降低复杂任务的质量，真正的前沿模型性能在这些任务上很重要，导致用户投诉和流失。解决方案是智能路由，但构建它需要设计一个在100个用户时不需要存在、但必须在100,000个用户时准备好的路由架构。

回退架构挑战复合了路由问题。AI模型提供商的SLA通常是99.9%正常运行时间——意味着每年8.7小时的停机时间。对于核心价值主张是AI能力的AI原生产品，这是不可接受的。没有设计好的回退架构，每次提供商中断都变成完全的产品中断。有了回退架构，产品优雅降级——回退到等效或稍微能力较弱的模型——而用户几乎不会注意到。

COCO如何解决

1. 路由架构设计：COCO设计全面的模型编排系统：

   • 定义路由维度：查询复杂性、领域专业性、延迟预算、用户层级、任务类型、内容安全要求
   • 设计查询分类系统：快速、低成本的分类，在不增加可感知延迟的情况下将传入查询分配到路由桶
   • 创建模型分配矩阵：哪个模型处理哪种查询类型，附基于质量基准和成本分析的理由
   • 设计级联路由：先尝试更便宜/更快的模型，如果质量阈值未满足则升级到更有能力的模型
   • 生成带有每个查询类别和边缘情况显式逻辑的路由决策树

2. 回退架构设计：COCO创建弹性的多提供商系统：

   • 设计主/备/三级模型配置：具有清晰故障转移条件的提供商层级
   • 创建断路器模式：在导致用户端故障之前检测提供商降级并绕过
   • 设计优雅降级：定义当没有首选模型可用时产品做什么（回退模型、缓存响应、诚实的用户沟通）
   • 规定重试逻辑：对瞬态故障的指数退避、超时配置和最大重试次数
   • 生成灾难恢复手册：不同提供商故障场景的分步程序

3. 成本优化路由：COCO在不牺牲质量的情况下最大化成本效率：

   • 设计成本-质量权衡分析：通过实证确定更便宜模型质量相当的地方以及质量差距证明高级成本合理的地方
   • 创建每查询成本归因：追踪哪些产品功能和用户细分驱动最高推理成本
   • 设计缓存策略：相似查询的语义缓存、重复上下文的提示词缓存、幂等请求的响应缓存
   • 生成成本路由实验：不同路由配置的A/B测试，附质量和成本测量
   • 创建成本预测模型：在不同扩张场景下预测不同路由策略的基础设施成本

4. 质量感知路由逻辑：COCO确保质量不在成本压力下降级：

   • 设计质量阈值执行：触发模型升级的最低可接受质量分数
   • 创建基于置信度的路由：当主模型表达低置信度时路由到更有能力的模型
   • 生成领域专业知识路由：将专业领域查询（医疗、法律、代码）发送到具有文档记录领域优势的模型
   • 设计用户层级路由：高级用户优先访问前沿模型，标准用户获得质量相当但更便宜的路由
   • 创建质量回归检测：监控路由引起的质量降级并自动路由调整

5. 监控与可观察性设计：COCO构建路由系统可见性：

   • 设计路由决策日志：记录哪个模型处理每个请求以及为什么，用于调试和优化
   • 创建路由性能仪表板：可视化路由分布、每路由路径成本、每路由路径质量和回退率
   • 生成路由异常检测：当不寻常的路由模式出现时告警（意外的回退率、成本峰值、质量下降）
   • 设计路由A/B测试基础设施：安全地在流量子集上测试新路由配置
   • 创建路由优化反馈循环：使用质量和成本数据持续改进路由决策

6. 供应商管理与模型评估框架：COCO支持多供应商策略：

   • 设计模型评估框架：如何评估新模型选项以考虑是否纳入路由
   • 创建供应商风险评估：评估每个模型提供商的可靠性、定价稳定性和路线图
   • 生成合同和SLA分析：每个路由层级需要什么提供商承诺
   • 设计模型更新管理：如何评估和整合新模型版本而不中断生产路由
   • 创建提供商多元化策略：降低跨模型提供商的依赖集中风险

量化结果与受益角色

可量化的成果

• 推理成本降低：智能路由通常实现30–50%的成本降低，相比将所有查询路由到前沿模型，同时保持等效质量
• 可用性提升：多提供商回退架构将AI功能的有效可用性从99.9%提升到99.95–99.99%
• 质量优化：任务适当的路由通过将任务复杂性与模型能力匹配，将平均输出质量分数提升10–15%
• 事件响应时间：自动断路器将提供商中断检测和路由响应从15–30分钟减少到60秒以内
• 成本预测准确性：路由感知的成本模型将基础设施成本预测准确性从±50%提升到±15%

受益人群

• AI产品经理：获得对决定AI产品在规模上是否经济可行的成本-质量-可靠性三角的控制
• ML/平台工程师：获得路由系统的清晰架构规格，减少设计歧义和实施时间
• 财务团队：获得可靠的基础设施成本模型，用于预算和定价决策
• 运营团队：获得减少值班负担、消除提供商故障导致完全中断的自动故障转移系统

💡 实用提示词

提示词1 — 多模型路由架构设计

为以下AI产品设计多模型路由架构。

产品和主要使用场景、处理的查询类型、可用模型（每个模型的成本、延迟、优势、弱点）、质量要求、成本目标、延迟预算

设计路由架构（查询分类系统、路由决策矩阵、级联路由逻辑、实现架构）

输出：路由架构规格 + 决策矩阵 + 级联逻辑 + 实现指南

提示词2 — 回退架构与断路器设计

为以下AI基础设施设计回退架构。

当前设置、需处理的故障场景（提供商API超时、5xx错误、速率限制、完全中断、质量降级）

设计回退架构（提供商层级、断路器配置、超时和重试配置、优雅降级UX、监控和告警）

输出：回退架构规格 + 断路器配置 + 降级UX文案 + 监控设置指南

提示词3 — 路由成本优化分析

分析以下AI产品基础设施的路由优化机会。

当前状态（所有查询路由到同一模型、当前成本、当前质量）

分析5种优化场景（查询复杂度路由、语义缓存、微调小模型、多模型级联、用户层级路由）

对每个场景：预期成本影响、质量影响、实现复杂性、实现时间线、建议优先级

输出：优化机会排序 + 每个场景的实现指南 + 渐进式实现路线图

提示词4 — 路由质量监控系统

为以下AI产品路由基础设施设计质量监控系统。

产品、路由配置（模型层级）、当前监控

设计监控系统（路由质量指标、监控实现、告警配置、质量回归检测、路由优化反馈循环）

输出：监控设计规格 + 实现指南 + 告警配置 + 优化流程

提示词5 — 模型提供商评估框架

为以下AI基础设施评估新模型提供商或模型版本。

当前配置（现有提供商及其在路由中的角色）、评估触发器（成本压力/质量问题/可靠性担忧/新能力）、待评估的候选提供商/模型

设计评估框架（能力评估套件、成本分析、可靠性评估、集成评估、商业条款评估、评估决策矩阵）

输出：提供商评估框架 + 评估执行指南 + 决策矩阵 + 集成计划模板

34. AI产品事件响应与回滚规划师

以速度和精准响应AI产品故障——在危机演变为灾难之前将用户影响最小化、恢复质量。

痛点与解决方案

痛点：AI产品事件在检测、诊断和解决上都有独特的困难

传统软件事件相对易于理解：服务中断、错误率飙升、监控告警触发，工程师按照熟悉的手册恢复服务。AI产品事件有本质区别。它们通常不涉及任何错误——系统在技术上正常运行，同时产生错误、有害或质量大幅下降的输出。检测到模型行为的细微变化构成P1事件，需要大多数事件响应流程所缺乏的领域专业知识和质量监控。到检测发生时，事件往往已经持续了数小时或数天。

诊断挑战复合了检测问题。当AI产品事件发生时，多个同时存在的根本原因都是合理的：模型提供商悄悄更新了他们的模型、提示词更改引入了意外的回归、检索系统因索引漂移而返回不同结果、用户查询中的新边缘情况暴露了潜在的模型弱点，或者基础设施变更影响了模型推理流水线。没有结构化的诊断流程，事件响应者在用户影响积累的同时，浪费关键时间追逐错误的假设。

AI产品的回滚决策需要传统软件回滚中不存在的权衡。回滚到以前的提示词版本、模型版本或检索索引，可能在修复当前事件的同时重新引入之前状态的不同质量问题。"最后已知良好状态"的概念因以前的状态有其自己的质量问题这一事实而变得复杂——只是不同的问题。AI产品事件响应者需要承认这些权衡的结构化决策框架，而不是假装回滚很简单。

COCO如何解决

1. 事件分类与严重程度框架：COCO设计AI专项事件分类法：

   • 定义AI产品事件类型：质量降级、安全失败、可用性失败、数据泄露、偏见事件和能力回归
   • 创建严重程度分类标准：将事件类型和用户影响映射到具有具体阈值的P0/P1/P2/P3严重程度级别
   • 设计事件检测触发器：对每种事件类型应启动事件响应的具体信号
   • 生成事件沟通模板：每个严重程度级别和事件类型的预写内部升级消息
   • 创建事件声明协议：谁有权声明每个严重程度的事件，附清晰的升级路径

2. AI事件诊断框架：COCO创建结构化的根本原因分析：

   • 为每种AI事件类型设计诊断决策树：有效缩小根本原因的有序假设测试
   • 创建"前5分钟"清单：响应者在做任何其他事之前应采取的立即诊断步骤
   • 生成AI专项诊断查询：诊断常见根本原因的确切监控查询、日志搜索和质量检查
   • 设计相关性分析框架：将观察到的质量变化与部署事件、基础设施变更和输入分布变化相联系
   • 创建诊断工具需求：快速诊断AI事件所需的监控和可观察性基础设施

3. 回滚决策框架：COCO设计结构化的回滚分析：

   • 创建回滚选项清单：对每个AI组件，什么可以回滚、代价多大、有什么权衡
   • 设计回滚影响分析：在承诺回滚之前评估以前版本的质量状态
   • 生成回滚决策矩阵：给定事件严重程度和回滚选项权衡，最优响应是什么
   • 创建部分回滚策略：独立回滚特定组件（提示词、模型、检索索引）以针对根本原因
   • 设计回滚验证协议：如何在声明事件关闭之前确认回滚实际解决了事件

4. 手册开发：COCO生成全面的事件响应文档：

   • 为每个主要AI事件类别创建事件类型专项手册：分步程序
   • 设计带有角色专项部分的手册模板：值班工程师做什么、事件指挥官做什么、PM做什么
   • 生成沟通手册：内部团队沟通、外部用户沟通、企业客户通知和公开状态页更新
   • 创建升级手册：何时以及如何升级到模型提供商、高层、法务或传播团队
   • 创建事后审查模板：捕获学习、推动系统改进的结构化复盘流程

5. 事后分析与预防：COCO推动从事件中学习：

   • 设计无责任的事后分析流程：聚焦于系统改进而非个人问责的结构化复盘
   • 创建贡献因素分析：识别使事件成为可能的组织、技术和流程因素
   • 生成预防行动项框架：将事后洞察转化为具体、可衡量的改进
   • 设计事件趋势分析：随时间追踪事件模式，识别需要架构解决方案的系统性问题
   • 创建事件预防验证：如何验证预防行动实际上防止了复发

6. 企业与监管事件沟通：COCO管理外部事件沟通：

   • 为企业客户设计事件通知模板：客户成功团队发送的正式沟通
   • 为AI专项事件创建公开状态页更新模板
   • 生成监管通知评估：AI事件何时需要根据适用法规进行监管通知
   • 设计媒体/PR升级标准：AI事件何时需要传播团队介入
   • 创建事后客户报告：企业客户可能请求什么以及如何响应

量化结果与受益角色

可量化的成果

• 平均检测时间：结构化AI事件检测将MTTD从14+小时（投诉驱动）减少到2小时以内（监控驱动）
• 平均解决时间：预建手册和诊断框架将AI质量事件的MTTR降低40–60%
• 用户影响时长：更快的检测和结构化响应将每个事件的用户总影响时间减少50–70%
• 事后预防率：系统性的事后分析和预防行动将同类型事件的重复率降低65%
• 企业信任保留：主动、专业的企业事件沟通，与被动或延迟沟通相比，将AI事件导致的流失减少40–60%

受益人群

• 值班工程师：获得使AI事件响应变得可操作的清晰手册，减少值班压力和倦怠
• AI产品经理：获得将AI事件作为产品事件而非仅仅技术紧急情况来管理的结构化流程
• 企业客户成功团队：为不可避免的与企业客户的事件对话准备好专业沟通模板
• 法务与合规团队：获得立即浮现监管通知要求的结构化事件分类

💡 实用提示词

提示词1 — AI事件响应手册生成器

为以下AI产品创建事件响应手册。

产品、AI组件、可用监控、团队结构、是否有企业客户

为以下事件类型创建手册（AI质量降级事件、安全事件、模型提供商中断、偏见/公平性事件），每个包含：触发条件、初始评估（前5分钟）、诊断步骤、按根本原因的缓解选项、沟通（内部/用户/企业客户）、解决标准、事后流程

输出：4个完整事件手册，可供值班手册使用

提示词2 — AI回滚决策框架

为以下AI产品设计回滚决策框架。

产品、可回滚组件（模型版本、系统提示词版本、检索索引、微调检查点、应用代码）、最近30天部署历史

设计回滚决策框架（回滚候选清单、按事件类型的回滚决策标准、回滚执行清单、回滚后评估）

输出：回滚决策框架 + 组件清单 + 执行清单 + 回滚后协议

提示词3 — AI事件严重程度分类系统

为AI产品设计事件严重程度分类系统。

产品、用户群体、关键使用场景、监管背景、SLA承诺

设计严重程度分类系统（P0关键/P1高/P2中/P3低的标准和响应要求）、边缘情况和升级规则、监管通知决策树

输出：严重程度分类系统 + 决策流程图 + 响应SLA表 + 监管通知决策树

提示词4 — 事后审查模板

为AI产品事件生成事后审查模板。

产品、事件类型、审查基调（无责任）、审查参与者

生成包含以下内容的模板：事件摘要、时间线、根本原因分析（5-Why）、做得好的事情、可改进的事情、行动项（负责人+截止日期+成功指标）、检测缺口分析、经验教训

输出：完整事后审查模板 + 审查会议引导指南 + 行动项跟踪格式

提示词5 — 企业客户事件沟通模板

为以下AI产品创建企业客户事件沟通模板。

产品、企业客户画像、沟通渠道、待创建模板的事件类型

为每个事件阶段创建模板（阶段1初始通知、阶段2进度更新、阶段3解决通知、阶段4事后报告），每个包含关键要素和内容指南

沟通指导：不能说什么（增加客户焦虑或产生法律责任的措辞）、何时提供服务积分、何时升级到高层对话、如何处理媒体询问

输出：完整事件沟通模板库 + 指导 + 升级协议

35. AI负责任AI清单与审计跟踪生成器

将负责任AI实践嵌入每个产品决策，生成满足监管机构和企业买家要求的全面清单和文档。

痛点与解决方案

痛点：负责任AI被视为合规的事后补救，而非产品设计学科

大多数AI产品团队被动地对待负责任AI：发布一个功能，出现问题（偏见事件、有害输出、监管查询），然后追溯性地添加保障措施，同时匆忙回答应该在设计阶段就解决的问题。这种方法越来越难以为继。欧盟AI法案、美国AI行政命令、州级AI法规和企业采购要求，共同提高了无法展示系统化、主动的负责任AI实践的组织所面临的风险。

组织挑战在于，负责任AI跨越每个职能——产品设计、ML工程、法务、数据治理、客户成功——但通常没有明确的责任人和标准流程。当监管查询来临或企业客户要求负责任AI评估时，拼凑证据的混乱揭示了实践在不同功能间不一致、文档不存在，以及做出的决策是以监管机构和采购团队所期望的结构化评估所缺乏的方式临时做出的。

被动负责任AI的经济成本随时间复利增长。每次监管查询耗费数周团队时间和法律费用。每次因缺少负责任AI文档而受阻的企业交易代表着失去的ARR。每次公开偏见事件耗费用户信任和品牌价值，需要数月才能恢复。将负责任AI视为产品学科而非合规功能的公司建立了可持续的竞争优势：更快的企业交易周期、更低的监管风险、更强的用户信任，以及在不中断的情况下驾驭越来越严格的AI监管的组织能力。

COCO如何解决

1. 功能级负责任AI清单：COCO将负责任AI评估嵌入产品开发：

   • 生成开发前负责任AI清单：任何AI功能进入开发前需要回答的问题
   • 创建设计阶段公平性评估框架：功能设计期间潜在不平等影响的结构化评估
   • 生成上线前负责任AI关卡：任何AI功能上线前必须满足的最低负责任AI要求
   • 设计负责任AI审查流程：谁审查、评估什么、以及不同功能风险级别的审批要求
   • 创建负责任AI债务追踪：识别并优先处理缺乏适当负责任AI评估的现有功能

2. 审计跟踪架构：COCO设计全面的AI决策文档：

   • 创建AI决策日志规格：每次AI交互必须记录什么信息以供责任和可审计性
   • 设计模型决策审计跟踪：在具有重要决策的系统中记录导致每个AI输出的信息
   • 生成配置变更文档：追踪AI系统（提示词、模型、参数）发生了什么变化以及为什么
   • 设计同意和偏好审计跟踪：记录用户关于AI的选择以及如何被尊重
   • 创建训练数据审计跟踪：记录数据来源、预处理决策和可重现合规证据的排除

3. 偏见与公平性评估框架：COCO将公平性评估可操作化：

   • 为功能开发生成偏见测试协议：测试什么、如何测试、什么结果是可接受的
   • 创建交叉性分析框架：不仅跨单个属性评估公平性，还在其交叉处评估
   • 设计持续偏见监控：在无需定期人工审查的情况下检测生产中的公平性回归
   • 生成差异阈值框架：跨群体的什么级别的性能差异需要干预vs调查vs文档
   • 创建公平性改进手册：减少针对不同AI组件类型检测到的偏见的结构化方法

4. 人工监督规格：COCO定义人类在哪里以及如何必须参与循环：

   • 创建人工监督分类框架：哪些AI决策需要人工审核、哪些需要人工可启动的覆盖、哪些可以完全自动化
   • 设计人工审核界面：审核人员需要看到什么、他们可以采取什么行动、他们的审核必须产生什么文档
   • 生成有意义的人工监督标准：确保人工审核是真正的审慎，而不是橡皮图章——定义什么构成充分的审核
   • 创建人工覆盖能力规格：用户、管理员和合规官员必须存在什么控制来覆盖AI决策
   • 设计监督工作量分析：确保监督要求在不压垮人工审核者的情况下可行

5. 透明度与可解释性实现：COCO将AI透明度可操作化：

   • 按风险级别和使用场景生成透明度披露要求：必须向谁披露什么、以及如何披露
   • 创建可解释性实现规格：系统必须能够提供什么级别的解释
   • 设计面向用户的透明度界面：如何以用户可理解的方式传达AI参与、局限性和决策因素
   • 生成解释权工作流：处理用户请求解释影响其的AI决策的流程
   • 创建透明度文档模板：适合不同受众的AI透明度文档的标准化格式

6. 负责任AI治理项目设计：COCO建立组织负责任AI实践：

   • 设计负责任AI治理结构：负责任AI监督的角色、职责和决策权限
   • 创建负责任AI培训课程大纲：不同角色需要了解的负责任AI实践
   • 生成负责任AI政策模板：涵盖AI开发、部署和监控的组织政策
   • 设计负责任AI审查委员会：结构、成员、决策权和会议频率
   • 创建负责任AI成熟度评估：对照成熟度模型评估当前实践，附改进路线图

量化结果与受益角色

可量化的成果

• 企业交易周期加速：拥有文档记录的负责任AI项目的产品，通过消除采购尽职调查延迟，将企业交易完成速度提升30–50%
• 监管审计就绪性：拥有系统性负责任AI审计跟踪的组织将监管响应时间从数周减少到数天
• 偏见事件预防：主动偏见测试在上线前发现70–80%的差异问题，而临时测试只能发现20–30%
• 公开事件减少：拥有负责任AI项目的组织基于行业数据经历50–70%更少的公开AI伦理事件
• 用户信任溢价：调查中用户对具有清晰负责任AI实践的产品的信任评分高出25–35%

受益人群

• AI产品经理：展示在企业买家、监管机构和公众中建立公信力的负责任AI领导力
• 法务与合规团队：获得使监管合规可实现和可维护的系统性文档和流程
• 工程团队：拥有可以用定义验收标准实现的清晰、结构化的负责任AI要求
• 企业客户：对AI供应商实践建立信心，减少采购风险、加速尽职调查

💡 实用提示词

提示词1 — 上线前负责任AI清单

为以下AI功能生成全面的上线前负责任AI清单。

功能、风险级别（高/中/低）、适用法规、目标用户群体

生成上线前清单（7个部分）：目的和范围清晰度、数据治理、偏见和公平性、安全性和可靠性、透明度和可解释性、人工监督、治理审批

输出：完整清单（使用格式） + 完成追踪格式 + 清单项失败的升级指导

提示词2 — AI决策审计跟踪设计

为以下AI系统设计审计跟踪架构。

AI系统、AI做出的重要决策、监管要求、保留要求、访问要求（用户/监管机构/内部审计）

设计审计跟踪架构（记录什么、如何记录、保留和访问控制、监管合规考量、实现规格）

输出：审计跟踪架构文档 + 实现指南 + 监管合规映射

提示词3 — AI偏见测试协议

为以下AI系统开发全面的偏见测试协议。

AI系统和主要使用场景、可能受影响的受保护属性、用户群体多样性、监管背景

开发测试协议（测试方法、测试数据集需求、分析框架、可接受阈值、文档要求、持续监控设计）

输出：完整偏见测试协议 + 实现指南 + 报告模板 + 持续监控规格

提示词4 — 负责任AI治理框架

为以下组织设计负责任AI治理框架。

组织类型、AI使用范围和类型、当前治理成熟度、监管背景

设计治理框架（治理结构和角色、政策和标准、流程和工作流、培训和能力、工具和基础设施、成熟度路线图）

输出：负责任AI治理框架 + 实现路线图 + 关键文档模板 + 成熟度评估工具

提示词5 — 负责任AI供应商评估框架

为评估AI供应商/工具的负责任AI实践创建框架。

您的组织背景（行业、监管要求、AI使用案例）、待评估的供应商类型（基础模型提供商、AI应用工具、AI平台）

开发评估框架（评估维度、每个维度的具体问题、文档请求、评分标准、供应商分类决策树）

输出：完整供应商评估框架 + 评估问卷 + 评分标准 + 采购建议模板

36. AI产品本地化与多语言扩张规划师

在不降低质量、信任或使您成功的用户体验的前提下，将AI产品扩展到新语言和市场。

痛点与解决方案

痛点：AI本地化比软件本地化难一个数量级

传统软件本地化本质上是翻译和文化适应挑战：翻译UI、为文化习惯适配UX、处理从右到左的语言、正确格式化日期和货币。AI产品本地化包含所有这些挑战，外加一个更难的层次：AI模型本身在不同语言中的表现可能有天壤之别，产生的输出从优秀到不可用，取决于语言和查询领域。

大多数AI产品经理严重低估了这一差距。他们假设因为底层模型声称具有多语言能力，本地化主要是UI翻译工作。现实是：即使是前沿多语言模型在许多领域的非英语任务上也显示出20–40%的性能下降，低资源语言的失败率更是大幅更高。非英语语言的幻觉率显著增加。主要基于英语数据训练的安全过滤器，通常无法捕捉其他语言中的有害内容。输出的文化相关性——示例、习语、领域专业术语——通常需要远超翻译的本地化。

商业后果是可预测的：公司快速本地化以抓住国际市场机会，因质量问题在非英语市场经历低用户留存，并在这些市场损害品牌声誉。正确的方法——扩张前的系统性质量评估、针对特定市场的质量投资、分阶段推出——不那么刺激，但成功率大幅更高。

COCO如何解决

1. 多语言质量评估框架：COCO跨目标语言评估AI质量：

   • 设计语言专项质量评估套件：针对每种目标语言文化相关性的任务集，而非仅仅翻译英文任务
   • 创建跨语言质量比较协议：比较跨语言AI性能的标准化方法
   • 识别性能差距分析：对每种目标语言，与英语性能相比关键任务上的差距
   • 设计低资源语言评估策略：在评估数据集稀缺的语言中评估质量的方法
   • 生成市场准入评估：每种语言上线前必须满足的质量阈值

2. 本地化架构设计：COCO设计多语言AI的技术方案：

   • 评估本地化策略：端到端多语言模型vs翻译+英文处理vs语言专项微调vs多语言RAG
   • 设计语言检测和路由：如何识别用户语言并路由到适当的处理流水线
   • 创建多语言提示词工程框架：系统提示词必须如何适配每种语言——不仅仅是翻译
   • 设计多语言检索系统：多语言RAG的知识库结构、嵌入选择和检索策略
   • 生成本地化质量流水线：每种语言专项的自动化质量检查

3. 文化适应框架：COCO解决语言之外的文化要求：

   • 按市场识别文化要求：每个目标市场适用的价值观、规范和内容标准
   • 创建文化敏感性审查流程：AI输出文化适当性的结构化评估
   • 设计文化适当的示例集：为每个市场用文化相关替代品替换以英语为中心的示例
   • 生成文化事件预防框架：识别在英语中可接受但在特定文化背景中有问题的内容
   • 创建针对市场的人格适配：为文化期望调整AI语气、正式程度和沟通风格

4. 多语言安全与合规：COCO确保跨语言的负责任AI：

   • 评估语言专项安全过滤器有效性：测试安全系统在目标语言中是否与英语一样有效
   • 创建多语言红队协议：每种目标语言中针对语言特定攻击向量的对抗性测试
   • 设计按市场的合规要求：每个目标司法管辖区的数据本地化、AI专项法规、内容法规
   • 生成语言专项偏见评估：评估跨文化背景的AI输出的公平性和偏见
   • 创建本地化透明度要求：每个目标市场适用哪些AI披露义务

5. 市场优先级框架：COCO指导扩张排序：

   • 创建市场机会评分：结合TAM、竞争格局、监管环境和AI本地化复杂性
   • 设计AI本地化工作量估算：基于模型性能、文化适应需求和合规要求的每种目标语言复杂性评估
   • 生成市场进入排序：基于机会/工作量比推荐扩张顺序
   • 创建每个市场的发布标准：上市前必须满足的具体质量和就绪阈值
   • 设计针对市场的成功指标：为每个市场的竞争动态和用户期望调整的KPI(关键绩效指标)

6. 持续多语言质量管理：COCO建立可持续的质量项目：

   • 设计语言专项质量监控：每种支持语言的单独质量仪表板，附语言适当的基准
   • 创建多语言反馈基础设施：如何收集和处理跨语言的质量反馈
   • 生成跨语言质量均等目标：随时间缩小英语和非英语语言之间质量差距的策略
   • 设计本地化更新管理：如何处理跨多个语言变体的模型更新、提示词变更和内容更新
   • 创建多语言社区和Beta测试项目：吸引母语者参与质量评估和改进

量化结果与受益角色

可量化的成果

• 国际留存改善：拥有质量经验证本地化的产品，在非英语市场的90天留存比仅翻译方案高40–60%
• 市场进入时间线：结构化本地化框架将在新语言中达到质量水平的上线时间减少30–40%
• 质量差距缩小：系统性多语言评估早期识别质量差距，允许有针对性的投资，在上线前将性能差距从30%减少到10%以下
• 合规风险降低：市场专项合规评估防止在AI监管市场造成重大罚款和市场退出的监管事件
• 每市场收入：高质量本地化产品在非英语市场的每用户收入是仅翻译本地化产品的2–3倍

受益人群

• AI产品经理：做出有信心的、基于证据的国际扩张决策，而不是在市场上线后才发现质量问题
• ML工程师：获得清晰的多语言质量要求和评估框架，指导模型和提示词改进投资
• 法务与合规团队：获取市场专项监管评估，防止国际市场的合规失败
• 国际销售与市场营销团队：以真正的质量信心在新市场上线，而不是希望翻译就足够了

💡 实用提示词

提示词1 — 多语言AI质量评估

为将以下AI产品扩展到新市场设计多语言AI质量评估。

产品和主要使用场景、当前英语质量指标、目标扩张语言（含目标市场背景）、可用的多语言评估资源

设计质量评估（评估任务套件设计、评估方法论、性能差距分析、语言准入评估、持续监控计划）

输出：多语言质量评估框架 + 任务套件结构 + 准入评估模板 + 监控计划

提示词2 — 多语言提示词工程指南

为以下AI产品开发多语言提示词工程指南。

产品、当前英语系统提示词（粘贴或描述）、目标语言、使用的AI模型

开发多语言提示词工程指南（多语言系统提示词策略3个选项和建议、每种目标语言的语言专项提示词考量、提示词测试协议、多语言提示词维护流程）

输出：多语言提示词策略建议 + 语言专项指导 + 维护流程 + 测试协议

提示词3 — 国际市场优先级框架

为以下AI产品确定国际扩张市场的优先级。

产品、潜在扩张市场（8-12个候选）、战略目标、组织约束

按以下维度评估每个市场（市场机会评估、AI本地化复杂性、上市复杂性），并生成评分矩阵和扩张排序

输出：市场优先级矩阵 + 扩张排序 + 每个优先市场的进入策略 + 资源需求

提示词4 — 市场专项合规清单

为将以下AI产品扩展到目标市场生成合规清单。

产品、AI能力、处理的数据、目标市场（如欧盟、中国、日本等）

为每个目标市场生成合规清单（AI专项法规、数据保护、内容和行业专项要求），以及跨市场摘要

输出：市场专项合规清单 + 跨市场摘要 + 合规投资优先级

提示词5 — 多语言产品上线计划

为以下扩张创建多语言产品上线计划。

产品、扩张目标（语言和市场）、上线时间线、质量评估结果、合规就绪性、可用的营销/CS资源

创建多语言上线计划（上线前质量关卡、Beta/软上线设计、上线时机和排序、上线沟通计划、上线后90天监控）

输出：多语言上线计划 + 上线前关卡清单 + Beta项目设计 + 90天成功标准

37. AI驱动的功能使用分析引擎

理解用户不仅仅是在使用AI功能，而是这些功能是否真正在交付价值——以及机会在哪里。

痛点与解决方案

痛点：传统功能分析无法捕捉AI功能价值

用传统分析来测量AI功能使用会产生误导性结论。当产品团队问"AI写作助手在被使用吗？"时，标准分析的回答是："是的，45%的用户每月至少点击一次AI按钮。"这几乎告诉不了你功能是否有价值。用户可能点击AI按钮，阅读输出，得出结论认为不有用，然后手动写自己的内容——产生一个"使用"事件，夸大了采用指标，同时掩盖了AI功能未能交付价值的现实。

AI功能分析需要测量完整的价值交付周期：用户发起AI交互→AI产生输出→用户评估输出→用户接受/拒绝/修改输出→用户实现其底层目标。传统分析只捕捉前两个步骤。第三到第五步——决定AI功能是否实际上有价值——通常未被测量，导致产品团队基于系统性误导的数据做路线图决策。

AI功能使用分析缺口在整个产品体验中复合。从AI功能中提取最大价值的高级用户，与普通用户有根本不同的使用模式——他们提示的方式不同、使用不同的功能、完成不同的任务，对业务价值大相径庭。没有能够识别和分析高级用户模式的分析，产品团队就无法复制这些模式，无法构建将普通用户转化为高级用户的引导，也无法做出最能改善驱动最多价值的用户体验的功能投资。

COCO如何解决

1. AI功能价值分析框架：COCO设计捕捉价值而非仅仅使用的测量架构：

   • 定义AI功能价值指标：输出接受率、AI辅助任务完成率、有无AI辅助的任务完成时间、AI输出下游行动率
   • 设计AI功能的"价值交付漏斗"：从发起到价值实现，在每个阶段进行测量
   • 创建AI专项参与质量指标：区分探索性参与、生产性参与和习惯性参与
   • 生成价值代理指标：与价值交付相关的可测量信号，即使直接价值测量困难
   • 设计基线比较方法：用户在有AI辅助与无AI辅助情况下的行为对比

2. AI交互事件分类法：COCO创建全面的交互追踪：

   • 设计细粒度AI交互事件：不仅捕捉AI被使用了，还捕捉如何使用——迭代次数、修改行为、接受模式
   • 创建输出处置追踪：原样接受、大幅修改、部分使用、拒绝、重新生成
   • 设计会话级AI价值指标：会话价值中AI辅助与用户生成的比例
   • 生成跨会话AI采用曲线：随时间追踪用户AI使用模式如何演进
   • 创建AI功能交互序列分析：用户在AI交互前后做什么以理解上下文价值

3. 分段使用分析框架：COCO识别跨用户群体的模式：

   • 设计高级用户行为分析：绘制前10%AI功能用户的使用模式画像
   • 创建群体比较框架：理解不同用户类型（按角色、行业、使用年限）如何不同地使用AI功能
   • 生成按群体的AI功能采用曲线分析：哪些群体最快采用AI功能，什么使其与众不同
   • 设计使用场景发现分析：识别用户发现的功能设计中未预料到的AI使用场景
   • 创建低表现群体分析：识别AI功能采用率低的用户类型并诊断障碍

4. AI功能ROI测量：COCO将使用与业务结果相连接：

   • 设计AI功能留存影响分析：测量AI功能使用是否预测更好的留存
   • 创建AI功能收入归因：将AI功能使用与订阅升级、扩张收入和流失预防相关联
   • 生成AI功能NPS贡献分析：测量AI功能用户是否比非用户报告更高满意度
   • 设计价值实现时间测量：AI功能如何加速新用户的首次价值实现
   • 创建"功能粘性"分析：哪些AI功能驱动习惯性使用，哪些是新奇驱动的

5. AI功能机会检测：COCO识别改进和扩张机会：

   • 设计放弃漏斗分析：识别用户在AI功能工作流中在完成目标之前退出的地方
   • 创建功能缺口信号：表明用户想要AI辅助但当前不可用的行为指标
   • 生成AI功能交互失败分析：识别与不良结果相关的交互模式
   • 设计"相邻使用场景"发现：检测用户将AI功能用于预期使用场景之外目的的情况
   • 创建竞争替代信号：表明用户正在用竞争对手AI工具补充的行为模式

6. AI功能仪表板与报告设计：COCO创建可操作的分析视图：

   • 设计AI功能健康仪表板：在统一视图中组合使用、质量和价值指标
   • 创建AI功能比较视图：多个AI功能的相对性能以指导投资优先级
   • 生成基于群体的AI采用报告：AI功能采用如何跨用户获取群体演进
   • 设计AI功能变更的实验结果视图：将A/B测试结果与下游价值指标相连接
   • 创建面向产品团队消费的每周AI功能简报模板

量化结果与受益角色

可量化的成果

• 路线图决策质量：拥有AI功能价值分析的团队，对哪些功能投资将改善留存的预测准确度高60%
• 功能采用改善：理解高级用户行为画像使引导改进成为可能，将AI功能采用率提升30–50%
• 资源分配效率：基于价值的AI功能分析防止投资于使用率高但价值交付低的功能（常见陷阱）
• 流失预测准确性：AI功能使用模式提供比标准参与指标好3–4倍的预测性流失信号
• 收入归因清晰度：AI功能ROI测量使定价决策和投资案例能够提供具体业务影响证据

受益人群

• AI产品经理：用真正的价值交付测量取代误导性的"功能点击"分析，用于数据驱动的路线图决策
• 增长团队：识别预测长期留存的AI功能采用模式，并围绕复制这些模式构建引导
• 财务与高层：获取用具体业务影响证据证明持续AI投资合理的AI功能ROI数据
• ML工程师：了解哪些AI能力实际上被使用和被重视，使聚焦的改进投资成为可能

💡 实用提示词

提示词1 — AI功能价值分析框架设计

为以下AI产品功能设计以价值为中心的分析框架。

产品、主要AI功能（3-5个）、商业模式、当前分析（诚实说明缺口）、您当前无法回答的关键问题

为每个AI功能设计价值交付漏斗（5个阶段）和需要监控的新事件，以及价值指标定义和跨功能分析

输出：每个功能的价值分析框架 + 事件分类法 + 测量实现指南

提示词2 — AI高级用户行为分析

分析AI功能高级用户行为以识别可复制的模式。

产品、高级用户定义、可用数据

分析（高级用户识别、行为比较高级用户vs普通用户、高级用户的"顿悟时刻"、高级用户使用场景发现、复制策略）

输出：高级用户行为画像 + "顿悟时刻"分析 + 基于发现的引导改进建议

提示词3 — AI功能放弃分析

分析以下AI功能的放弃模式，识别改进机会。

功能（3-5个主要AI功能）、可用的行为数据（事件追踪）、已知问题（从用户反馈）

分析AI功能使用的完整价值交付漏斗（5个阶段），识别放弃点并量化影响，生成改进建议

输出：功能放弃分析报告 + 改进机会优先级排序 + 实现建议

提示词4 — AI功能ROI仪表板设计

为以下AI产品设计AI功能ROI仪表板。

产品和商业模式、主要AI功能（3-5个）、关键业务指标（留存、收入、NPS）、目标受众（产品团队/高层/投资者）

设计仪表板（核心价值指标、业务影响测量、功能对比视图、群体分析视图、实验结果整合）

输出：仪表板设计规格 + 每个指标的计算方法 + 实现优先级 + 受众特定视图设计

提示词5 — AI功能机会发现框架

为以下AI产品设计主动的AI功能机会发现系统。

产品、当前AI功能组合、产品战略（增长聚焦/留存聚焦/扩张聚焦）、可用数据

设计机会发现系统（5个机会类别）：功能扩展机会、竞争替代检测、使用场景扩展发现、新用户群体识别、功能整合机会

每个类别：信号定义、追踪方法、机会评分标准、行动框架

输出：机会发现系统设计 + 实现指南 + 机会优先级框架

38. AI产品OKR与成功指标框架构建器

让整个产品团队围绕AI专项OKR(目标与关键结果)对齐，将模型质量改进与所有人都关心的业务结果相连接。

痛点与解决方案

痛点：通用OKR框架对AI产品团队失效

AI产品团队尝试使用标准SaaS OKR框架，然后发现它不起作用。问题在根本层面：标准OKR框架是为具有确定性结果的功能设计的，其中发布一个功能基于用户采用成功或失败。AI产品结果是概率性和多维的——模型改进可能改善某些查询类型的质量，同时降低其他类型的质量；可能提高用户满意度的同时增加基础设施成本；或者在不转化为用户真实任务完成改进的情况下显示出强劲的基准改进。

目标设置的混乱制造了组织功能障碍。ML工程师围绕模型质量指标（BLEU分数、幻觉率、基准性能）设置目标，这些目标与产品经理关心的产品指标（留存率、NPS、任务完成率）断开。产品经理围绕参与指标设置目标，但这些指标并不衡量AI是否真正有效。业务高层关注与工程中进行的模型质量讨论看似脱节的收入和增长指标。每个人都在为不同的事情优化，结果是一个无法就成功是什么样子达成一致的组织。

测量挑战复合了目标设置问题。与传统功能不同，A/B测试可以快速确认新功能是否改善目标指标，AI改进通常需要数周的观察才能产生足够的信号。没有投资于大多数团队尚未构建的评估基础设施，质量改进很难测量。这造成了反馈循环失败：团队因为无法测量结果而无法设置好的目标，他们也没有构建测量基础设施因为目标没有要求它。

COCO如何解决

1. AI产品OKR架构设计：COCO创建连接所有层级的级联目标结构：

   • 设计公司→产品→AI专项OKR级联：展示AI团队目标如何连接到公司级结果
   • 创建"指标阶梯"框架：将模型质量指标（幻觉率）连接到产品质量指标（任务完成率）再连接到业务指标（留存率、NPS）
   • 设计跨职能OKR对齐：确保ML、产品和业务团队的目标相互强化而非冲突
   • 生成OKR相互依赖图：展示哪些团队的目标依赖于其他团队的贡献
   • 创建目标设置引导框架：使多元利益相关者在共享AI产品OKR上对齐的流程

2. AI专项KR设计：COCO创建适合AI产品的可测量关键结果：

   • 设计以结果为中心的KR：测量用户发生了什么变化，而不仅仅是发布了什么
   • 创建带测量方法的AI质量KR：具体、可测量的质量目标，附定义的评估方法
   • 生成领先指标KR：预测未来业务结果的指标，在季度结束前实现纠偏
   • 设计置信区间KR：对具有固有方差的AI指标适当——"以95%置信度实现X"
   • 创建反指标KR："不能变差"的指标，防止以牺牲重要次级指标为代价博弈主要KR

3. 成功指标定义：COCO确保测量正确的事情：

   • 创建产品成功层级：北极星指标→支撑指标→领先指标→运营指标
   • 设计模型改进的AI专项成功标准：什么指标上的什么改进构成"成功"的模型更新
   • 生成功能成功框架：在上线后30/60/90天宣布AI功能成功的预定标准
   • 设计实验成功标准：A/B测试的什么结果构成发布的充分证据
   • 创建"成功预防"分析：识别所选指标可能产生的扭曲激励

4. 团队绩效框架：COCO将个人和团队评估与AI产品成功对齐：

   • 创建ML团队绩效框架：如何以连接产品结果的方式评估ML工程师绩效
   • 设计AI功能产品经理责任框架：PM对什么负责以及如何衡量
   • 生成团队健康指标：在输出指标旁边测量团队效能（实验速度、文档质量、事件响应时间）
   • 设计协作指标：跨职能团队（产品+ML+设计+法务）合作的质量
   • 创建学习指标：测量组织学习速度——团队根据新证据更新信念的速度

5. OKR回顾与校准流程：COCO建立运营节奏：

   • 设计每周检查仪式：跟踪OKR进度的简短、结构化流程
   • 创建季度中期OKR校准流程：如何在不放弃责任的情况下处理需要调整的OKR
   • 生成季度OKR回顾框架：评估目标达成和目标质量
   • 设计OKR公开透明系统：如何在组织中为AI产品OKR创建适当的透明度
   • 创建OKR失败分析框架：无责地从错过的OKR中学习，改进未来的目标设置

6. 投资者与董事会指标沟通：COCO将AI产品指标与投资者叙事相连接：

   • 创建适合投资者的AI产品指标包：将技术AI指标转化为与业务相关的KPI(关键绩效指标)
   • 设计董事会级AI产品健康仪表板：董事会讨论中合适抽象级别的正确指标
   • 生成AI产品叙事框架：如何将AI产品进展作为连贯故事而非指标集合来传达
   • 设计基准背景：如何在行业基准和竞争对手信号中对AI产品指标进行背景化
   • 创建投资者Q&A准备：预先回答成熟投资者会问的AI产品指标问题

量化结果与受益角色

可量化的成果

• 跨职能对齐速度：精心设计的OKR框架将季度目标的对齐时间从3–4周减少到1–2周
• 目标达成率：拥有AI专项OKR框架的团队达成>70%的OKR，而使用通用框架的团队只有40–50%
• ML-产品协作：共享指标阶梯在75%的案例中减少ML/产品目标冲突，这些冲突曾导致工作浪费
• 投资者信心：清晰的AI产品KPI(关键绩效指标)框架将投资者信心评分（在融资调查中）提升25–30%
• 路线图优先级速度：共享的成功指标通过为优先级决策提供客观标准，将路线图辩论时间减少40%

受益人群

• AI产品经理：获得将AI技术工作转化为所有人都理解的业务结果的组织对齐工具
• ML工程团队：拥有将其技术工作与用户结果相连接的产品目标，使其贡献可见且被重视
• 高层管理：获取用于战略规划和投资者沟通的连贯、一致的AI产品进度指标
• 个人贡献者：通过从其角色到业务结果的清晰指标阶梯，理解其工作如何与公司成功相连接

💡 实用提示词

提示词1 — AI产品OKR框架生成器

为以下AI产品团队生成季度OKR框架。

公司/产品、阶段、季度战略焦点、上一季度结果、关键约束、本季度公司级OKR

生成AI产品OKR框架（公司级目标关联、产品目标、4个关键结果含基线/目标/测量方法/理由、指标阶梯展示KR之间的因果关系、团队OKR级联）

输出：完整OKR框架 + 指标阶梯 + 团队级联 + 测量实施指南

提示词2 — AI功能成功标准框架

为以下AI功能定义上线前成功标准。

功能、上线时间线、目标用户、假设（您相信此功能将为用户和业务实现什么）、已投入资源

在三个时间节点定义成功标准（30天早期信号、60天价值信号、90天业务影响），每个节点包含采用阈值、质量阈值、失败标准等

决策树：在30/60/90天如果标准满足→继续；如果不满足→具体行动

输出：成功标准框架 + 决策树 + 学习捕获计划 + 责任分配

提示词3 — 跨职能OKR对齐引导

为以下AI产品团队设计跨职能OKR对齐流程。

团队构成（产品、ML工程、设计、数据/分析、法务/合规）、当前对齐挑战、季度规划时间线、期望结果

设计OKR对齐流程（对齐前准备、对齐会议设计3小时、冲突解决框架4个常见冲突、对齐后承诺、每周对齐节奏）

输出：对齐流程设计 + 会议议程 + 冲突解决框架 + 对齐后承诺模板 + 每周节奏设计

提示词4 — 董事会演示的AI产品指标

为董事会演示准备AI产品指标。

公司阶段、董事会受众、汇报季度、战略叙事

按以下维度准备指标（北极星指标、AI质量指标转化为非技术董事会语言、业务影响指标、投资效率、前瞻性信号）

演示设计（一页AI产品摘要的布局和内容、3张幻灯片的内容规格、5个预期的董事会问题及回答）

输出：董事会演示包——预读摘要 + 幻灯片规格 + Q&A准备

提示词5 — 季度OKR回顾框架

为AI产品团队设计季度OKR回顾框架。

团队、回顾季度、OKR达成摘要（哪些达成/未达成/部分达成）、季度关键事件

设计回顾（达成分析—分类为"以正确/错误原因达成/未达成"、目标质量回顾、流程回顾、下一季度影响）

每个OKR分类中最有价值的学习来自"以错误原因达成/未达成"的案例

输出：回顾引导指南 + 分析框架 + 输出文档模板 + 下一季度规划输入

39. AI企业AI产品上市战略顾问

构建赢得企业AI交易的上市策略，解决向风险意识买家销售AI的独特信任、合规和组织挑战。

痛点与解决方案

痛点：企业AI上市与企业SaaS上市有本质区别

依赖传统SaaS上市手册的企业AI产品经理在企业市场中持续表现不佳。传统的企业SaaS动作——构建引人注目的演示、创建ROI模型、运行概念验证、谈判合同条款——对AI产品失效，因为它没有解决使企业买家对AI犹豫的独特关切，而这些关切不适用于传统软件。

企业AI采购现在涉及不属于SaaS购买决策的利益相关者：首席AI官、AI治理委员会、数据隐私法律团队、拥有AI专项审查清单的安全团队，以及必须签署AI部署的风险管理职能。每个利益相关者都有不同的关切。CISO想了解AI系统如何处理对抗性攻击。首席隐私官想了解AI组件的数据流。AI治理委员会想要偏见测试证据和人工监督文档。CEO想要ROI。仅关注经济买家的传统销售周期在周期后期才遇到阻塞利益相关者，此时最难解决他们的关切。

企业AI的竞争动态使这个问题更糟。企业买家同时评估多个AI供应商，受到AI特有的供应商锁定担忧（专有微调、嵌入式工作流、转换成本），并意识到AI能力快速变化——使多年承诺变得冒险。没有构建企业专项定位、开发适当定价和合同结构，以及创建企业买家所需的信任建立内容的AI产品团队，将输给已经做到这些的竞争对手。

COCO如何解决

1. 企业AI买家人格框架：COCO映射完整的企业购买委员会：

   • 为每个企业AI利益相关者创建详细的买家人格档案：经济买家、技术冠军、CISO、法务/隐私、AI治理、最终用户冠军
   • 定义每个人格的主要关切、成功标准和AI采购的阻塞条件
   • 设计人格专项价值主张：每个利益相关者需要听到什么才能成为倡导者而非阻塞者
   • 生成每个人格的旅程图：他们在购买过程的每个阶段如何与AI供应商评估互动
   • 创建利益相关者影响图：理解企业AI采购中的内部关系和决策动态

2. 企业AI定位框架：COCO制作有差异化的企业定位：

   • 开发企业专项定位支柱：信任、合规、可靠性和ROI——按企业买家重视的顺序
   • 创建竞争定位框架：如何从AI原生竞争对手和添加AI的传统软件供应商中差异化
   • 设计新AI产品类别的"类别创建"定位：当没有既定类别时，如何定义问题空间并将自己定位为解决方案
   • 生成证明点清单：按买家人格关切组织的客户案例研究、基准数据、第三方验证和分析师报道
   • 创建定位验证框架：在承诺大规模营销投资之前如何与企业买家测试定位

3. 企业销售动作设计：COCO构建企业AI销售流程：

   • 设计多线程销售策略：如何同时与经济买家、技术冠军和阻塞利益相关者互动
   • 创建企业AI评估框架：以受控、风险管理方式展示价值的结构化POC/试点设计
   • 生成"交易台"资源：企业AI交易的定价框架、折扣审批流程、合同条款指导
   • 设计落地扩张策略：最小化采购摩擦并使扩张成为可能的初始企业切入点
   • 创建企业AI交易加速手册：移动停滞交易通过常见阻塞点的具体战术

4. 信任建立内容架构：COCO创建企业买家所需的内容：

   • 生成企业AI信任内容清单：企业买家需要的具体文档、演示和认证
   • 设计"信任建立序列"：在企业购买旅程的每个阶段以正确顺序部署信任建立内容
   • 创建安全审查响应包：针对企业安全问卷的预准备响应
   • 生成AI合规文档包：针对AI法案、GDPR和行业专项要求的有组织、易访问的文档
   • 创建客户证据包：针对企业买家关切结构化的案例研究、推荐信和参考资料

5. 企业定价与合同策略：COCO设计企业商业结构：

   • 创建企业定价架构：承诺使用定价、批量折扣、AI SLA层级和定制条款框架
   • 设计试点到合同的转化路径：如何将成功的POC转化为多年协议
   • 生成谈判准备材料：在哪里坚持、在哪里灵活、以及什么创意交易结构解决常见的企业异议
   • 创建企业AI合同条款：企业买家需要的具体AI相关合同条款以及如何响应常见请求
   • 生成扩张手册：如何将企业账户从初始使用场景发展到全组织部署

6. 企业AI客户成功框架：COCO确保企业留存和扩张：

   • 设计企业AI引导项目：让企业客户在90天内实现价值的结构化计划
   • 创建高管业务回顾框架：以业务语言展示AI产品价值的季度回顾
   • 生成扩张触发器识别：表明扩张机会的行为和关系信号
   • 设计企业倡导项目：将成功的企业客户转化为参考资料、案例研究和联合营销合作伙伴
   • 创建流失风险框架：高风险企业AI账户的预警系统和干预手册

量化结果与受益角色

可量化的成果

• 企业交易转化：结构化的企业AI上市项目将POC到关闭的转化率提升30–45%，相比临时企业销售方法
• 销售周期长度：多线程利益相关者互动和预准备的信任文档将企业销售周期缩短20–35%
• 平均合同价值：企业专项定价框架和扩张手册随时间将平均企业ACV(年度合同价值)提升25–40%
• 企业留存率：结构化的客户成功项目在企业AI账户中实现90%+净收入留存，而行业平均水平为70–80%
• 参考客户发展：系统性倡导项目在12个月内将30–40%满意的企业客户转化为活跃参考资料

受益人群

• AI产品经理：获得企业上市策略专业知识，将技术强大的产品转化为企业营收引擎
• 企业销售团队：获得人格专项手册、信任内容和交易台资源，加速企业周期每个阶段
• 客户成功团队：获得系统性推动采用、扩张和倡导的结构化企业项目
• 高层管理：获得实现高级定价、更大交易规模和锚定业务模型稳定性的战略客户关系的企业上市策略

💡 实用提示词

提示词1 — 企业AI买家人格开发

为以下产品开发全面的企业AI买家人格。

产品和主要AI能力、目标企业细分市场、当前企业销售经验（赢/输交易涉及哪些利益相关者）、竞争对手企业存在情况

为每个关键企业利益相关者开发人格（6个人格）：经济买家、技术冠军、CISO/安全审查员、法务/隐私顾问、AI治理/风险官、最终用户冠军

每个人格包含：职位范围、主要动机、主要担忧、评估AI供应商的标准、成为倡导者所需的内容、接触方式、常见异议及响应

利益相关者影响图：在每种企业交易类型中，谁影响谁？哪些利益相关者是最终决策者vs阻塞者vs加速冠军？

输出：6个完整人格 + 影响图 + 多线程互动的交易团队指导

提示词2 — 企业AI POC设计框架

为企业AI产品评估设计概念验证框架。

产品、典型企业使用场景、POC持续时间约束、企业买家期望的成功指标、常见POC失败模式

设计POC框架（POC范围界定方法、POC架构3个阶段：设置/评估/验证、POC成功指标定义、POC到合同转化手册）

输出：POC框架 + 范围界定问卷 + 评估标准 + POC报告模板 + 转化手册

提示词3 — 企业AI信任内容策略

为企业AI产品营销设计信任内容策略。

产品、企业目标细分市场、最常见的企业信任关切、可用的证明点、内容开发资源

设计信任内容策略（每个购买阶段的内容需求、内容生产路线图3个月、内容交付策略、社会证明策略）

输出：信任内容策略 + 生产路线图 + 交付手册 + 参考项目设计

提示词4 — 企业AI定价与合同策略

为以下AI产品设计企业定价和合同策略。

产品、当前企业定价、典型交易规模、常见定价异议、竞争对手定价背景、成本结构

设计企业策略（企业定价架构：3个层级、定价维度、试点/POC商业结构、合同条款指导含标准条款和谈判指导、扩张手册）

输出：企业定价架构 + 合同指导 + 谈判手册 + 扩张策略

提示词5 — 企业AI上市发布计划

为以下企业AI产品计划创建上市发布计划。

产品、计划（新产品/主要功能/企业层级/新垂直市场）、目标企业细分市场、发布时间线、销售团队情况、营销资源

创建企业上市发布计划（市场准入评估、理想客户画像定义、上市动作设计、发布里程碑T-90/T-30/T-0/T+30/T+90天、成功指标90天和12个月目标）

输出：完整企业上市发布计划 + 上线前就绪清单 + 销售动作手册 + 成功指标仪表板规格

40. AI 产品无障碍与包容性设计审计师

确保AI产品对所有用户都具有包容性和可访问性，消除算法偏差和界面障碍，让多元化用户群体都能从AI功能中获益。

痛点与解决方案

痛点：AI产品中的可访问性盲点导致用户流失与法律风险

大多数AI产品团队在构建功能时将可访问性视为事后补充，而非核心设计原则。这种做法在AI产品中尤为危险，因为AI系统的不透明性会放大现有的不平等问题。当语音识别系统对某些口音的识别率比其他口音低40%，当图像识别模型对深色皮肤用户的准确率显著下降，当自然语言处理工具对非母语用户的输出质量明显劣质，这些系统性偏差不仅影响用户体验，还可能引发监管审查和法律责任。

AI产品中的可访问性问题往往比传统软件更难发现和修复。传统软件的可访问性测试有相对成熟的标准（WCAG 2.1、Section 508等），但AI系统的可访问性涉及更复杂的层面：模型在不同人口群体中的性能差异、用于训练的数据集的代表性、AI生成内容对辅助技术的兼容性，以及认知负担和复杂性障碍。产品经理缺乏系统性的框架来识别和优先处理这些多维度的可访问性问题。

更深层的商业挑战在于可访问性投资的价值被严重低估。全球有超过10亿残疾人，老龄化人口对辅助技术的需求快速增长，非英语用户在全球AI产品市场中占据绝大多数。忽视可访问性的AI产品不仅错失了巨大的市场机会，还在建立品牌声誉、获取企业客户（企业采购往往有强制性可访问性要求）以及应对日益严格的监管环境方面处于劣势。

COCO 如何解决

1. AI可访问性审计框架：COCO构建全面的可访问性评估体系：

   • 设计AI功能可访问性评估矩阵：覆盖视觉、听觉、运动、认知和语言五个维度的障碍类型
   • 创建模型性能差异分析框架：系统识别AI模型在不同人口群体中的准确率差距
   • 生成训练数据代表性审查清单：评估训练数据集对边缘群体的覆盖程度
   • 设计辅助技术兼容性测试协议：确保AI生成内容与屏幕阅读器、语音控制等工具无缝协作
   • 制定认知可访问性标准：为不同认知能力的用户优化AI交互设计复杂度

2. 包容性设计原则集成：COCO将包容性融入产品开发流程：

   • 建立"包容性设计第一"产品开发规范：在需求文档和用户故事中嵌入可访问性标准
   • 创建多元化用户测试框架：系统纳入残疾人、老年人、低识字率用户和非母语用户的测试反馈
   • 设计AI功能的降级体验：确保AI功能不可用时的备用方案对所有用户可访问
   • 生成用户研究参与者多样性指南：制定招募边缘用户群体参与研究的系统性方法
   • 构建可访问性债务追踪机制：在产品积压中量化和优先处理可访问性改进项

3. 算法公平性监测系统：COCO建立持续的公平性监测机制：

   • 设计跨人口群体的模型性能基准测试：定期评估AI模型在不同年龄、性别、地域、语言用户中的表现
   • 创建偏差根因分析方法论：系统追溯算法偏差到数据、模型架构还是部署配置层面
   • 建立公平性指标仪表板：实时监控关键人口群体的AI功能使用率和满意度差异
   • 生成偏差缓解优先级框架：基于影响范围、严重程度和修复难度的偏差修复决策矩阵
   • 设计持续性公平性测试流程：将公平性测试集成到每次模型更新的发布门控中

4. 监管合规与法律风险管理：COCO确保可访问性合规：

   • 构建AI可访问性法规地图：覆盖ADA、EU AI Act可访问性条款、各地区残障权利法规
   • 创建企业客户可访问性认证包：准备VPATs（自愿产品可访问性模板）和WCAG符合性声明
   • 设计可访问性风险评估流程：在产品发布前识别高风险的可访问性缺口
   • 生成可访问性事件响应程序：处理用户可访问性投诉和监管查询的标准化流程
   • 制定第三方可访问性审计采购标准：选择和管理外部可访问性审计机构的框架

5. 可访问性商业案例建设：COCO量化可访问性投资回报：

   • 创建可访问性市场机会分析：量化残疾人用户、老龄化用户和多语言用户的市场规模
   • 设计可访问性投资ROI模型：连接可访问性改进到用户获取成本、留存率和企业销售成功率
   • 生成可访问性竞争基准报告：对比竞品的可访问性水平和市场定位
   • 构建企业采购可访问性要求映射：识别目标企业客户的强制性可访问性要求
   • 制定可访问性品牌价值框架：如何将包容性AI作为差异化的市场定位要素

6. 跨职能可访问性实践建设：COCO推动组织级可访问性能力：

   • 设计AI可访问性培训课程：面向产品、设计、ML工程师的角色专属可访问性培训
   • 创建可访问性冠军计划：在各团队培养可访问性倡导者的社区建设框架
   • 建立可访问性设计审查流程：在设计和代码审查中嵌入可访问性检查点
   • 生成供应商可访问性评估标准：确保第三方AI组件符合可访问性要求的采购框架
   • 制定可访问性路线图规划方法：将可访问性改进系统性纳入季度产品规划

量化结果与受益角色

可量化成果

• 边缘用户留存提升：系统性可访问性改进使残疾人用户和老年用户的30日留存率提升25–40%，直接扩大可服务市场
• 企业销售成功率：具备完整可访问性认证（VPAT、WCAG 2.1 AA）的AI产品在政府和大型企业采购中的入围率提升35–50%
• 算法公平性改善：定期的跨群体性能监测使AI模型在低代表性人群中的准确率差距缩小50–70%，降低歧视性输出风险
• 法律风险降低：主动的可访问性合规程序将可访问性相关法律诉讼和监管罚款风险降低60–80%
• 全球市场覆盖率：多语言和文化可访问性优化使产品在非英语市场的用户满意度提升30–45%，加速国际扩张

受益角色

• AI产品经理：获得系统性框架将可访问性从合规负担转化为差异化的市场优势和商业价值
• ML工程团队：建立明确的公平性指标和监测机制，使模型改进工作与真实用户价值紧密连接
• 法律与合规团队：获得主动的可访问性风险识别和缓解工具，大幅降低监管暴露
• 业务拓展与销售团队：通过可访问性认证解锁政府、医疗、教育等强制合规市场的采购机会

💡 实用提示词

提示词1 — AI功能可访问性审计

对以下AI功能进行全面的可访问性审计。

产品名称：[product name]
AI功能描述：[feature description]
目标用户群：[target users]
当前已知可访问性问题：[known issues if any]
技术栈：[frontend technology, AI model type]

请从以下五个维度评估可访问性：
1. 视觉可访问性：AI生成内容的对比度、图像替代文本、色盲友好性
2. 听觉可访问性：语音AI功能的文字备选、字幕支持
3. 运动可访问性：键盘导航、触控目标大小、AI交互的操作复杂度
4. 认知可访问性：AI输出的可读性、错误提示的清晰度、用户控制感
5. 语言可访问性：非母语用户的输出质量、方言和口音支持

对每个维度：当前评级（优/良/需改进/不合格）、具体问题描述、改进优先级、改进建议

输出：可访问性审计报告 + 优先修复清单 + WCAG 2.1合规差距分析

提示词2 — 跨群体AI公平性分析

分析以下AI模型在不同用户群体中的性能差异，识别算法公平性风险。

模型类型：[model type]
核心功能：[what the model does]
目标市场：[geographic regions, demographics]
现有性能数据：[overall accuracy metrics if available]
已知偏差问题：[any reported issues]

分析以下群体的性能差异：人口统计维度（年龄组、性别、地理区域、语言背景）、使用场景维度（专业用户vs普通用户）、设备维度（高端设备vs低端设备）

对每个发现的性能差距：量化差距大小、根本原因假设（数据/模型/部署）、商业影响评估、缓解措施优先级

输出：公平性分析报告 + 偏差根因假设 + 缓解措施路线图 + 持续监测指标设计

提示词3 — 包容性AI产品路线图规划

为以下AI产品制定包容性设计路线图，将可访问性改进系统性纳入产品规划。

产品：[product name]
当前可访问性状态：[self-assessment: basic/partial/comprehensive]
目标市场：[regions, enterprise vs consumer, regulated industries]
季度规划周期：[next N quarters]
可用工程资源：[team size, sprints per quarter]

制定包容性设计路线图：
1. 快速修复（本季度）：高影响、低投入的可访问性修复项
2. 基础建设（下一季度）：监测体系、测试基础设施、团队培训
3. 深度优化（3-6个月）：算法公平性改进、多语言扩展
4. 市场扩展（6-12个月）：认证获取、可访问性优先功能

对每个阶段：具体可交付成果、成功指标、依赖项、预期商业价值

输出：包容性设计路线图 + 季度OKR建议 + 资源需求估算 + 商业价值测量框架

41. AI 产品技术债务评估与重构规划师

系统识别AI产品中积累的技术债务，制定数据驱动的重构优先级和迁移计划，在不中断产品迭代的前提下提升系统可维护性。

痛点与解决方案

痛点：AI产品技术债务的隐蔽性和复合效应威胁长期竞争力

AI产品的技术债务与传统软件有本质区别，因为它在多个层面同时积累：代码质量债务、数据债务、模型债务和基础设施债务。传统软件的技术债务主要体现在代码可读性和架构质量上，而AI产品还额外面临：训练数据随时间变质（数据漂移）、模型架构过时（新方法出现后旧模型的迁移成本）、特征工程的积层（为不同时期的不同问题临时添加的特征导致系统复杂度指数级增长）以及评估基础设施的缺失（无法可靠地测量系统质量的技术欠缺）。

这种多层次债务的复合效应在实践中产生了严重后果。工程团队将70–80%的时间花在维护现有系统上，而非开发新功能，因为AI系统的脆弱性使每次改动都可能引发级联失败。数据科学家无法进行有效的实验，因为数据管道的不可靠性让实验结果无法重现。模型更新的部署时间从理论上的几天延长到实际的几周甚至几个月，因为测试和验证流程残缺不全。这些摩擦的累积效应是产品迭代速度的急剧下降，正好在竞争对手加速追赶的时刻。

产品经理面临的核心困境是如何为技术债务偿还工作争取资源和优先级。技术债务的成本是隐性的——它体现在工程师的挫败感、特性交付的延迟和系统故障的频率上，而不是清晰可见的业务指标。在与新功能需求竞争优先级时，技术债务工作总是处于劣势。产品经理需要一套框架将技术债务量化为可见的业务影响，才能在产品路线图中为重构工作争取应有的空间。

COCO 如何解决

1. AI技术债务多层评估框架：COCO构建系统性债务识别体系：

   • 设计四维债务评估矩阵：代码/数据/模型/基础设施四个层面的债务指标体系
   • 创建技术债务业务影响量化模型：将工程延迟时间转换为功能交付成本和机会成本
   • 生成AI系统健康度评分卡：通过可观测指标（部署频率、变更失败率、恢复时间）综合评估系统健康
   • 建立债务积累速率监测：追踪技术债务随时间增长的趋势，预测临界点
   • 设计跨职能债务审计流程：联合工程、数据和产品团队定期进行技术债务盘点

2. 重构优先级决策框架：COCO建立数据驱动的重构决策体系：

   • 创建技术债务ROI计算模型：基于修复成本、延迟缓解、未来速度提升计算重构投资回报
   • 设计债务热点地图：识别技术债务最密集、改动最频繁的系统组件作为优先重构目标
   • 生成风险加权优先级矩阵：结合技术风险（失败概率）、业务影响和重构复杂度的优先级算法
   • 建立重构影响预测模型：基于历史数据预测不同重构项目对迭代速度的改善幅度
   • 制定"边走边修"战略：在不冻结功能迭代的情况下持续偿还技术债务的工程策略

3. 数据与模型债务专项治理：COCO解决AI特有的技术债务：

   • 设计数据管道健康评估框架：检测数据漂移、数据质量退化和数据处理逻辑腐化
   • 创建模型版本治理体系：管理多个模型版本共存、特征一致性和训练数据血缘关系
   • 建立特征仓库债务审计：识别冗余特征、废弃特征和特征计算效率问题
   • 生成评估基础设施差距分析：识别无法可靠测量模型质量的评估盲区
   • 设计ML实验可重现性标准：建立确保实验结果可重现的数据和配置管理规范

4. 重构执行计划设计：COCO规划安全可执行的重构路径：

   • 创建渐进式重构策略：将大型重构项目分解为可增量交付的小步骤，降低风险
   • 设计重构安全网机制：测试覆盖率要求、特性开关和回滚策略的标准化配置
   • 建立双轨运行框架：新旧系统并行运行期间的流量切换、数据同步和性能对比策略
   • 生成重构里程碑定义：明确重构进度的可验证检查点和成功标准
   • 制定工程资源分配模型：技术债务偿还与新功能开发的季度资源分配平衡框架

5. 技术债务沟通与治理：COCO建立债务可视化和治理机制：

   • 创建技术债务仪表板设计：面向产品和管理层的技术健康度可视化方案
   • 设计技术债务与业务指标关联报告：展示技术债务水平与产品迭代速度和质量指标的相关性
   • 建立债务季度复盘机制：定期评估技术债务趋势和重构计划执行情况
   • 生成工程效能基准体系：建立可比较的工程效能指标（部署频率、前置时间、变更失败率）
   • 制定技术债务预算制度：将技术债务偿还纳入工程预算规划的结构化方法

6. AI系统现代化战略规划：COCO制定长期技术演进路线：

   • 设计AI基础设施现代化路线图：从当前架构到目标架构的分阶段迁移计划
   • 创建技术选型评估框架：MLOps平台、特征存储、模型服务基础设施的选型决策矩阵
   • 建立构建vs购买vs开源决策框架：AI基础设施组件的自研、采购和开源策略决策
   • 生成技术债务预防规范：防止新债务积累的工程文化、代码审查和架构决策规范
   • 制定AI系统生命周期管理策略：模型和数据管道的退役、迁移和版本管理最佳实践

量化结果与受益角色

可量化成果

• 工程迭代速度提升：系统性技术债务偿还后，功能交付前置时间平均缩短30–50%，工程师有效开发时间从40%提升至65%以上
• 系统稳定性改善：针对技术债务热点的重构将AI系统生产故障频率降低40–60%，MTTR（平均恢复时间）缩短50%
• ML实验效率提升：清洁的数据管道和评估基础设施使ML实验周期从平均3–4周压缩到1–2周，实验吞吐量翻倍
• 基础设施成本优化：消除冗余模型版本和优化数据处理管道通常可降低AI基础设施运营成本15–30%
• 新员工生产力加速：高技术债务环境中新工程师达到全速贡献通常需要3–6个月；系统性减债后可缩短至4–8周

受益角色

• AI产品经理：获得将技术债务量化为业务影响的工具，在路线图规划中为技术工作争取应有优先级
• ML工程团队：建立明确的债务偿还路线图，从长期的系统维护泥沼中解脱出来，重获开发效率和工作满足感
• CTO和工程领导：获得数据驱动的技术投资决策框架，向业务领导层清晰展示技术健康度与业务速度的关联
• 产品VP和业务团队：通过技术债务与迭代速度的量化关联，建立对技术投资长期价值的正确预期

💡 实用提示词

提示词1 — AI产品技术债务盘点

对以下AI产品进行全面的技术债务盘点和评估。

产品：[product name]
当前工程团队规模：[team size]
产品运行年限：[how long in production]
主要技术栈：[languages, frameworks, cloud infrastructure]
已知痛点：[what engineers complain about most]
近6个月主要故障：[major incidents if any]

请评估以下四个层面的技术债务：
1. 代码质量债务：测试覆盖率、代码复杂度、文档质量、重复代码
2. 数据管道债务：数据新鲜度、血缘追踪、质量监控、模式管理
3. 模型架构债务：模型版本碎片化、架构过时、可重现性问题
4. 基础设施债务：部署自动化、监控覆盖率、安全补丁、成本效率

对每项债务：严重程度（1-5分）、业务影响、修复工作量估算（工程周）、优先级建议

输出：技术债务评估报告 + 热点优先级地图 + 季度偿还计划建议

提示词2 — 重构项目ROI分析

分析以下AI系统重构项目的投资回报，为产品路线图优先级决策提供数据支持。

重构项目：[describe the refactoring initiative]
当前问题：[what pain points this refactoring addresses]
工程投入估算：[engineering weeks, team members involved]
预计完成时间：[timeline]
主要风险：[what could go wrong]

请计算重构ROI：

成本侧：工程人力成本（工程周 × 平均成本）、机会成本（重构期间未开发的功能）、执行风险溢价（失败概率 × 影响）

收益侧：迭代速度提升（预计功能交付速度提升%）、事故成本节约（故障减少 × 平均故障成本）、工程师留存改善（流失风险降低 × 替换成本）、基础设施成本节约

时间维度：12个月ROI、24个月ROI、盈亏平衡点

输出：重构ROI模型 + 敏感性分析 + 管理层报告模板 + Go/No-Go决策建议

提示词3 — AI技术债务偿还路线图规划

为以下AI产品制定未来三个季度的技术债务偿还路线图。

产品：[product name]
技术债务盘点结果：[summary of debt assessment]
季度工程容量：[available engineering weeks per quarter]
功能交付承诺：[committed features that cannot be displaced]
首席工程师的主要关切：[top technical concerns]

制定技术债务偿还路线图：

Q1焦点（快速修复 + 安全网建设）：关键风险项修复、测试覆盖率提升目标、监控完善计划

Q2焦点（架构改善 + 数据质量）：数据管道重构、模型版本治理清理、特征工程优化

Q3焦点（现代化 + 效能建设）：基础设施升级、ML平台改善、工程规范建立（防止未来债务积累）

对每个季度：工程资源分配比例（债务vs新功能）、预期速度提升、风险和依赖

输出：三季度技术债务路线图 + 资源分配建议 + 成功指标 + 季度检查点定义

42. AI 产品用户分群与个性化引擎

利用AI能力构建精细化的用户分群体系，实现个性化产品体验，在规模化服务的同时为每位用户提供高度相关的AI交互。

痛点与解决方案

痛点：同质化的AI体验无法满足多样化用户需求，导致用户价值实现率低

大多数AI产品以"一刀切"的方式向所有用户提供相同的体验，而用户在技能水平、使用场景、期望输出和工作流集成方式上存在巨大差异。一个对数据科学家高效的AI助手对市场营销人员来说可能复杂难用；一个对初学者友好的AI导师对专家用户来说则显得幼稚低效。这种对齐失败直接体现在留存数据中——即使产品整体留存看起来合理，深入分析往往会发现不同用户群体之间存在2–3倍的留存率差距，而这种差距正在被平均值掩盖。

更微妙的问题在于AI产品中的个性化远超简单的界面定制。当用户向AI系统提问时，相同的问题在不同用户口中可能有完全不同的深度期望、格式偏好和应用场景。专家用户希望得到简洁的技术输出，初级用户需要详细解释和类比，业务用户关注实际影响而非技术细节。如果AI系统无法感知这些差异并调整输出风格，用户会逐渐形成"这个AI不懂我"的感受，导致使用频率下降和最终流失。

个性化的实施复杂性让大多数团队望而却步。产品团队缺乏系统性的方法来识别有意义的用户分群（而不是随意的标签堆砌），无法设计可扩展的个性化机制（而不是为每个群体手工调整提示词），以及无法在隐私保护要求和个性化效果之间找到正确的平衡点。结果是个性化工作要么根本没有启动，要么停留在简单的界面皮肤切换层面，错失了AI驱动个性化的真正价值。

COCO 如何解决

1. 行为驱动的用户分群框架：COCO建立精细化的用户理解体系：

   • 设计AI产品专属的用户分群维度：技能水平、使用深度、工作流依赖度、输出消费偏好的多维分群模型
   • 创建行为信号提取体系：从AI交互数据中提取用户技能水平、偏好和使用场景的信号
   • 建立动态分群机制：基于用户行为变化实时更新用户群体归属，捕捉用户成长轨迹
   • 生成分群价值验证框架：验证不同用户群体在留存率、扩展收入和产品价值实现上的差异
   • 设计隐私合规的数据收集策略：在最小化数据收集原则下获取足够个性化信号的设计框架

2. AI输出个性化引擎设计：COCO构建可扩展的个性化机制：

   • 创建用户画像驱动的提示词工程框架：将用户属性系统性融入AI系统提示词的设计方法
   • 设计适应性输出格式系统：根据用户偏好动态调整AI输出详细程度、格式和风格
   • 建立个性化反馈循环：从用户的显性反馈（点赞/踩）和隐性行为（复制/修改/忽略）中持续优化个性化模型
   • 生成专业领域个性化策略：针对医疗、法律、金融等专业场景的术语和内容个性化方案
   • 设计语言和文化本地化个性化：超越翻译层面的文化习惯和表达风格适应框架

3. 用户旅程个性化设计：COCO优化全生命周期的个性化体验：

   • 创建新用户引导个性化矩阵：基于职业背景和使用目标的分群引导路径设计
   • 设计渐进式功能开放策略：根据用户成熟度逐步开放高级AI功能的个性化门控机制
   • 建立使用场景识别系统：自动识别用户当前工作场景并切换AI助手的工作模式
   • 生成个性化的价值时刻设计：为不同用户群体设计"啊哈时刻"触发策略
   • 制定再激活个性化策略：针对沉默用户的分群回归策略和个性化再参与触点

4. 企业级个性化扩展框架：COCO设计组织层面的个性化能力：

   • 创建团队/组织级偏好配置系统：支持企业客户在团队层面统一配置AI行为规范
   • 设计行业垂直个性化包：为医疗、法律、金融等行业预配置的AI行为参数集
   • 建立企业知识库集成个性化：基于企业专属数据和流程的深度个性化方案
   • 生成权限分层的个性化治理：不同角色（管理员/用户）对AI行为的可配置范围定义
   • 制定多租户个性化隔离架构：确保不同企业客户个性化配置相互隔离的技术规范

5. 个性化效果测量体系：COCO建立严格的效果验证机制：

   • 设计个性化A/B测试框架：在用户群体内验证个性化策略有效性的实验设计方法
   • 创建个性化价值归因模型：将留存改善、扩展收入分别归因到具体个性化举措
   • 建立个性化质量评估指标：衡量个性化相关性、用户满意度和意外影响的综合指标体系
   • 生成个性化反效果检测：识别过度个性化（信息茧房）和个性化错位（不符合预期）的预警机制
   • 制定个性化迭代优先级框架：基于效果数据持续优化个性化策略的方法论

6. 个性化数据策略与隐私治理：COCO确保负责任的个性化：

   • 创建最小化数据个性化架构：在收集最少用户数据的前提下实现有效个性化的技术方案
   • 设计用户数据透明度界面：让用户清晰看到和控制哪些数据影响其AI体验
   • 建立个性化数据生命周期管理：个性化数据的保留期限、更新机制和删除策略
   • 生成跨地区个性化隐私合规框架：在GDPR、CCPA等不同隐私法规下的个性化数据处理规范
   • 制定个性化偏差审计机制：定期检查个性化系统是否在特定群体中产生系统性不公平对待

量化结果与受益角色

可量化成果

• 用户留存率提升：基于行为数据的精细化分群和个性化体验通常使60日用户留存率提升20–35%，在专业和技术用户群体中效果尤为显著
• AI功能使用深度增加：个性化的输出风格和场景匹配使高级AI功能的日活使用率提升40–60%，用户从表面尝试转向深度集成
• 用户引导完成率提升：分群个性化引导使新用户在首周完成关键价值时刻的比例提升30–50%，加速用户从注册到付费的转化
• 支持票据减少：当AI输出风格和复杂度与用户期望高度匹配时，用户困惑相关的支持请求减少25–40%
• NPS改善：接受个性化体验的用户群体NPS比对照组平均高出15–25分，"AI真正理解我"成为核心满意度驱动因素

受益角色

• AI产品经理：获得将用户多样性转化为个性化产品策略的系统性框架，推动用户留存和扩展收入
• 增长与用户研究团队：建立行为驱动的用户分群体系，取代主观假设的用户画像，使增长干预更精准
• ML工程团队：获得将用户上下文系统性集成到AI模型推理的工程框架，将个性化能力产品化
• 客户成功与销售团队：利用用户分群洞察识别高价值用户群体，设计针对性的扩展和升级销售策略

💡 实用提示词

提示词1 — AI产品用户分群设计

为以下AI产品设计行为驱动的用户分群体系。

产品：[product name and core AI capabilities]
当前用户规模：[MAU/DAU]
已有用户数据：[what behavioral data is available]
业务目标：[what you want to achieve with segmentation]
已知用户多样性：[different types of users you have observed]

设计用户分群体系（包含4个维度）：技能维度、使用深度维度、场景维度、价值实现维度

对每个分群，定义可观测的行为信号（提示词复杂度、会话时长、功能使用组合、输出修改频率）

验证计划：如何验证这些分群与留存率和付费转化的相关性

输出：用户分群框架 + 信号提取规范 + 分群价值假设 + 验证实验设计

提示词2 — AI个性化体验规格设计

为以下用户群体设计个性化的AI交互体验规格。

AI产品：[product name]
目标用户群：[specific segment description]
该群体核心特征：[skill level, use cases, preferences, pain points]
当前统一体验痛点：[what is not working for this segment]
技术约束：[what personalization is technically feasible]

设计个性化体验规格：
1. AI输出个性化：输出详细程度、格式偏好、术语水平、主动建议频率
2. 交互流程个性化：引导体验、功能开放节奏、错误处理方式
3. 个性化触发机制：静态配置（注册时声明偏好）、动态适应（行为信号触发调整）、显性反馈集成

输出：个性化体验规格文档 + 提示词工程框架 + 实施优先级 + 效果测量方案

提示词3 — 个性化策略效果实验设计

设计验证AI个性化策略效果的实验框架。

产品：[product name]
个性化假设：[what you believe personalization will improve]
目标指标：[primary metric — retention, engagement, NPS]
用户分群：[which user segments are being personalized]
当前基准：[current metric values for control group]

设计个性化实验：
1. 实验结构：对照组（统一体验）和实验组（个性化变体），说明各自的具体差异
2. 分层采样：确保各用户分群在对照/实验组中比例均衡，最小样本量和测试时长计算
3. 成功指标：主要指标和最小可检测效应、护栏指标（不得下降的指标）、分群级别分析计划
4. 风险控制：逐步放量计划和负面影响预警机制

输出：实验设计文档 + 统计功效分析 + 实施时间线 + 结果分析框架

43. AI 产品竞争情报监测系统

建立持续运转的AI竞争情报监测体系，实时追踪竞品动态、行业趋势和技术突破，为产品决策提供及时、结构化的市场洞察。

痛点与解决方案

痛点：AI领域竞争变化速度超出人工监测能力，产品团队长期处于信息滞后状态

AI产品市场的竞争烈度和变化速度在过去三年发生了根本性改变。新的AI能力以月为单位而非季度出现，竞争对手的功能更新频率远超传统软件行业，开源社区的突破性进展可以在数周内被商业产品集成。在这种环境下，传统的竞争情报做法——每季度做一次竞品分析、定期阅读行业报告——已经完全无法满足产品决策的需要。当产品团队完成一次竞品分析并将结论写入路线图时，竞品可能已经发布了三个新版本，彻底改变了竞争格局。

AI产品的竞争情报还面临信号稀释问题。AI领域的营销噪音极大：每家公司都在宣传自己的模型"领先业界"，基准测试结果被选择性引用，功能发布的公告往往夸大实际可用性。产品团队需要能够穿透营销话语、识别真实竞争动态的情报能力——哪些竞品真正在技术上取得了突破，哪些公告只是战略性的市场信号，哪些客户痛点竞品已经实质性地解决而我们尚未应对。缺乏这种辨别能力的团队要么反应过度（追逐每一个竞品新闻导致路线图频繁调整），要么反应不足（忽视真正重要的竞争威胁）。

更深层的挑战是竞争情报与产品决策的脱节。即使团队收集了大量竞品信息，这些信息往往停留在产品经理的收藏夹里，无法系统性地影响路线图优先级、定价策略和市场定位决策。竞争情报的价值在于驱动行动，而不是生成报告。产品团队需要将竞争情报嵌入日常工作流程、季度规划周期和战略决策过程的系统性机制。

COCO 如何解决

1. 结构化竞争情报收集体系：COCO建立系统性的信号捕捉网络：

   • 设计多源竞争信号监测框架：整合产品更新、招聘信号、专利申请、研究论文、社区讨论的多维监测体系
   • 创建竞品功能追踪模板：标准化记录竞品每次更新的功能、定价、定位变化的结构化方法
   • 建立客户对话情报提取流程：从销售丢单分析、客户成功复盘、支持票据中系统性提取竞争洞察
   • 生成行业活动情报计划：AI峰会、研究发布、开源项目里程碑的情报收集策略
   • 设计竞争情报质量分级标准：区分一手信息、二手信息和市场传言的可信度分级体系

2. AI竞争态势分析框架：COCO深化竞争理解：

   • 创建技术能力对比矩阵：跨竞品的AI能力维度（准确率、延迟、成本、定制性）系统性对比
   • 设计竞品产品策略解读方法：从功能组合、定价结构和目标客户推断竞品的产品战略意图
   • 建立竞品技术路线预测模型：基于招聘信号、研究方向和开源贡献预测竞品未来6–12个月的技术重点
   • 生成竞争白点识别框架：系统分析竞品集体忽视的用户需求和市场机会
   • 制定技术代际跃迁风险评估：识别可能颠覆当前竞争格局的新兴技术突破

3. 竞争情报定期报告体系：COCO将情报转化为可用洞察：

   • 设计周度竞争快讯格式：5分钟可读的关键竞争动态摘要，专注可行动信息
   • 创建月度竞争态势报告框架：竞争格局变化、胜负分析、战略建议的结构化报告模板
   • 建立季度竞争战略复盘：深度竞争分析与产品战略校准的季度机制
   • 生成竞争事件响应报告：针对重大竞品发布的快速分析和应对建议模板
   • 制定年度竞争格局白皮书：市场份额、竞争动态趋势和未来竞争预测的年度综合分析

4. 销售竞争支持工具建设：COCO连接情报与一线销售：

   • 创建竞品对抗卡片体系：针对每个主要竞品的优势对比、差异化话术和常见异议应对
   • 设计竞品替换案例库：有效替换竞品客户的成功故事和迁移框架
   • 建立实时竞争战场支持：销售遇到竞品时可即时获取的情报资源和应对策略
   • 生成竞品演示对比脚本：在产品演示中有效呈现竞争优势的引导话术
   • 制定竞争价格应对策略：面对竞品激进定价时的反应框架和保底策略

5. 竞争情报驱动的产品决策：COCO将情报嵌入产品流程：

   • 设计竞争情报与路线图连接机制：将竞争洞察系统性纳入季度路线图规划的流程
   • 创建"竞争触发"产品决策流程：定义哪些竞争信号应该触发紧急路线图调整
   • 建立竞争差异化功能评分体系：在功能优先级评分中量化竞争差异化价值
   • 生成竞争情报影响追踪：记录基于竞争情报做出的产品决策及其结果，优化情报质量
   • 制定竞争情报保密管理规范：敏感竞争信息的分发范围和内部管理规范

6. 开源与生态情报监测：COCO追踪技术生态动态：

   • 创建关键开源项目监测框架：追踪对产品竞争格局有重要影响的开源AI项目进展
   • 设计学术研究商业化预测：从顶级AI研究会议论文识别6–18个月后的技术商业化信号
   • 建立合作伙伴生态竞争分析：追踪关键合作伙伴同时与哪些竞品合作及其战略意图
   • 生成投资信号情报：从竞品融资、并购、战略合作识别竞争格局变化预警
   • 制定监管政策竞争影响分析：分析AI监管新规对不同竞品市场地位的差异影响

量化结果与受益角色

可量化成果

• 竞争反应速度：结构化竞争情报体系使产品团队对重大竞品发布的分析和应对决策时间从平均2–3周缩短至3–5天
• 销售胜率提升：系统性竞争对抗训练和实时竞争支持使直接竞争场景下的销售胜率提升15–25%
• 路线图竞争相关度：定期竞争情报注入使路线图中直接应对竞争威胁和把握竞争机会的功能比例提升30–40%
• 客户流失预警：竞品监测系统提前识别客户流失风险，使预防性干预成功率提升20–35%，降低因竞争导致的客户流失
• 定价决策质量：实时竞品定价情报使定价调整决策的市场反馈符合预期的比例提升40%，减少错误定价的损失

受益角色

• AI产品经理：从被动应对竞争变成主动塑造竞争，用系统性情报支撑更有信心的路线图决策
• 销售与业务拓展团队：获得实时、结构化的竞争支持资源，在竞争性商机中赢得更高胜率
• 市场营销团队：基于真实竞争动态制定差异化的市场定位和内容策略，而非基于猜测
• 高层领导与董事会：获得清晰的竞争格局视图，支撑战略投资决策和市场机会判断

💡 实用提示词

提示词1 — 竞品深度分析报告

对以下AI竞争对手进行深度分析，为产品战略决策提供竞争情报支持。

我方产品：[product name and core value proposition]
目标竞品：[competitor name]
分析触发原因：[what prompted this analysis — new launch, customer loss, market rumor]
可用信息来源：[what information is available — public announcements, trial access, customer feedback]

请从以下维度进行深度分析：

1. 产品能力评估：[current feature set, AI capabilities, quality benchmarks, notable strengths and weaknesses]
2. 定价和商业模式：[pricing tiers, packaging, enterprise terms, recent changes]
3. 目标客户定位：[ICP, use cases they win, customer segments they prioritize]
4. 技术路线信号：[hiring patterns, research publications, open source activity, partnership announcements]
5. 市场牵引力：[growth signals, customer references, analyst coverage, funding]
6. 战略意图推断：[what their product decisions suggest about their 12-month strategy]

对我方产品的影响评估：[where they're beating us, where we're winning, what they're likely to do next]

竞争应对建议：[immediate actions, roadmap implications, positioning adjustments, sales enablement needs]

输出：竞品深度分析报告 + 我方产品影响评估 + 优先应对行动建议

提示词2 — 月度竞争态势报告

生成本月AI产品竞争态势报告，综合多个竞品的最新动态。

我方产品：[product name]
主要竞品列表：[list of competitors to cover]
本月关键竞争事件：[major launches, funding rounds, customer wins/losses, industry news]
销售团队反馈：[win/loss patterns, objections heard, competitive deals this month]

生成月度竞争态势报告，包含：

1. 本月竞争重大事件（每个事件：发生了什么、对我们意味着什么、建议行动）
2. 竞争格局变化趋势（整体市场动态，哪些竞品在上升，哪些在下滑）
3. 我们的竞争胜负分析（本月竞争商机统计，赢了什么输了什么，原因分析）
4. 下月竞争预警（预计哪些竞品会有重要动作，我们应提前准备什么）
5. 产品和销售行动建议（基于本月情报的3条最优先行动）

格式要求：高管可在10分钟内阅读完毕，关键结论突出展示

输出：月度竞争态势报告（适合高管阅读的格式）

提示词3 — 竞争白点机会识别

分析AI产品市场的竞争白点，识别主要竞品集体忽视的用户需求和市场机会。

市场范围：[define the AI product market segment]
主要竞品：[list 3-5 key competitors]
各竞品主要聚焦方向：[brief description of each competitor's focus]
我方产品当前定位：[current positioning and target segment]

识别竞争白点：

1. 用户需求白点：哪些真实用户需求没有竞品在认真解决？（基于社区讨论、客户反馈、支持票据分析）
2. 细分市场白点：哪些细分市场被主流竞品边缘化，存在差异化机会？
3. 技术能力白点：哪些技术能力在该市场尚未被认真开发？
4. 商业模式白点：哪些定价或交付模式竞品尚未尝试但可能受市场欢迎？
5. 地理和语言白点：哪些地区和语言市场竞品覆盖不足？

对每个白点：市场规模估算、进入难度评估、与我方现有优势的契合度、建议的探索优先级

输出：竞争白点机会地图 + 每个白点的战略进入评估 + 优先级建议

44. AI 产品知识管理与文档体系

构建AI产品团队的知识管理体系，系统沉淀产品决策、实验洞察和最佳实践，消除知识孤岛和信息流失，加速团队学习速度。

痛点与解决方案

痛点：AI产品知识的高度隐性化导致团队智慧无法积累，每次人员变动都是知识灾难

AI产品团队积累的最有价值的知识往往存在于最难提取的地方：为什么某个模型架构被选择而另一个被放弃、某次实验失败的真实原因（而非报告中的官方版本）、特定客户群体的AI接受度模式、提示词工程的隐性技巧。这些知识存在于少数核心成员的脑海中，通过一对一对话传递，在人员离职时永久消失。大多数AI团队都经历过这样的痛苦：一个新的ML工程师重复了18个月前另一个工程师已经尝试并放弃的实验方向，只因为失败的原因从未被记录下来。

AI产品的文档困境尤为突出。传统的文档实践——详细的技术规格文档、用户手册、API文档——在AI产品中面临独特的挑战：AI系统的行为难以完全规格化（输出是概率性的而非确定性的），模型更新频繁使文档迅速过时，实验结果的有效性高度依赖数据和配置的具体组合。结果是AI团队要么完全不写文档（因为太难且很快过时），要么写了大量无人阅读的文档（因为格式不适合快速检索和使用）。

更深层的问题是知识管理与日常工作流程的脱节。团队成员之所以不记录知识，不是因为懒惰，而是因为记录行为与工作成果之间的时间距离太长——文档写完的时候，这个知识对写文档的人已经不再紧迫。有效的知识管理需要将知识沉淀嵌入工作流程本身，在产生知识的时刻自然地捕捉它，并以使用者在需要时能迅速找到的方式组织它。

COCO 如何解决

1. AI产品知识分类体系：COCO建立结构化的知识组织框架：

   • 设计AI产品知识本体：决策记录、实验档案、模型知识、客户洞察、运营手册五大知识域的分类体系
   • 创建知识优先级评估框架：识别高价值、高流失风险的隐性知识，优先进行显性化
   • 建立知识有效期管理机制：标记不同类型知识的时效性，定期触发更新或归档
   • 生成知识图谱设计：展示不同知识条目之间关联关系的结构化组织方式
   • 制定知识质量评估标准：区分高质量可用知识和低质量噪音的评判维度

2. 决策记录与理由沉淀：COCO确保产品智慧不随人员流动流失：

   • 创建架构决策记录（ADR）模板：产品和技术决策的标准化记录格式，包含背景、选项、决策和理由
   • 设计实验失败档案制度：专门记录失败实验及其根本原因的知识库，防止重复踩坑
   • 建立产品假设与验证日志：系统追踪每个产品假设从提出、测试到验证或推翻的完整历程
   • 生成技术债务决策档案：记录每次"知道有问题但选择接受"的技术决策和当时的权衡依据
   • 制定路线图变更理由记录：每次路线图重大调整的背景、触发因素和预期影响的标准化记录

3. 实验知识管理系统：COCO建立ML实验的系统性知识沉淀：

   • 设计实验报告标准模板：超越数据记录，捕捉假设、方法论选择和结论可推广性的实验报告格式
   • 创建实验洞察提炼流程：将单次实验的发现提炼为可跨项目复用的通用洞察
   • 建立提示词工程知识库：有效提示词模式、失效案例和设计原则的结构化积累
   • 生成模型评估历史档案：模型版本、基准测试结果和部署决策的完整历史记录
   • 制定实验复盘定期机制：季度实验复盘，从大量实验数据中提炼战略性洞察

4. 客户洞察知识管理：COCO沉淀用户理解：

   • 创建用户研究知识库：用户访谈、可用性测试和反馈分析的结构化沉淀和检索系统
   • 设计客户对话洞察提取模板：从销售和客户成功对话中系统提取产品相关洞察的标准化流程
   • 建立用户需求模式库：跨多次研究发现的反复出现用户需求模式的提炼和组织
   • 生成垂直行业知识库：不同行业客户对AI产品需求的特殊性和共性知识积累
   • 制定客户洞察时效管理：标记客户洞察的数据收集时间，防止基于过时数据做决策

5. 知识传递与引导体系：COCO加速新成员上手：

   • 设计新员工知识传递课程：结构化的产品知识引导计划，让新成员在4–8周内掌握核心背景知识
   • 创建关键路径知识地图：新员工必须掌握的核心知识清单和建议学习顺序
   • 建立知识导师匹配机制：将隐性知识持有者与新员工配对，加速隐性知识转移
   • 生成常见问题知识库：新成员高频提问的系统性解答，减少重复问答的时间损耗
   • 制定跨团队知识分享制度：定期的跨职能知识分享，打破ML、产品、设计、销售之间的知识孤岛

6. 知识管理工具与流程集成：COCO将知识沉淀嵌入工作流：

   • 设计工作流触发的知识捕捉：在项目完成、实验结束、客户对话后自动触发知识记录的流程设计
   • 创建知识管理工具选型框架：根据团队规模、知识类型和工作流特点选择合适工具的决策矩阵
   • 建立知识库健康度指标：追踪知识库覆盖率、时效性和使用率的量化指标体系
   • 生成知识贡献激励机制：在团队文化和绩效评估中嵌入知识分享贡献认可的设计
   • 制定知识安全与访问控制：区分公开知识、内部知识和敏感知识的访问权限管理框架

量化结果与受益角色

可量化成果

• 新员工上手时间压缩：系统性知识管理使新成员达到独立工作效率的时间从平均3–4个月缩短至6–8周，加速团队扩张效率
• 重复实验成本节约：完善的实验失败档案使ML团队重复已尝试方向的概率降低60–70%，直接节约实验算力和工程时间
• 决策质量提升：历史决策记录和理由档案使类似场景的决策时间缩短40%，错误决策率降低25%（因为可以从历史失败中学习）
• 知识损失风险降低：系统性知识管理将关键人员离职导致的知识损失风险降低50–70%，使组织知识积累不再依赖特定个人
• 跨团队协作效率：共享的客户洞察和产品知识库使ML工程师、产品经理和设计师协作中的信息不对称显著减少，会议效率提升30%

受益角色

• AI产品经理：建立组织知识积累体系，使团队的集体智慧真正成为可查询、可复用的战略资产
• ML工程团队：从系统化的实验知识库和最佳实践中获益，减少重复踩坑，加速技术能力迭代
• 新加入成员：通过结构化知识传递快速掌握产品背景，比在知识孤岛环境中更快做出有价值贡献
• 工程和产品领导层：降低人员流动对团队能力的冲击，将团队知识从个人资产转化为组织竞争优势

💡 实用提示词

提示词1 — 产品决策记录模板

为以下AI产品决策创建标准化的决策记录文档。

决策内容：[what was decided]
决策背景：[what problem or opportunity triggered this decision]
决策时间：[when this decision was made]
决策参与者：[who was involved in the decision]

请生成完整的决策记录文档，包含：

1. 背景与问题陈述：[the situation that required a decision, including constraints and requirements]
2. 考虑的选项：[all options that were evaluated, not just the chosen one]
3. 每个选项的优缺点分析：[pros and cons for each option considered]
4. 最终决策：[what was decided and why this option was chosen]
5. 关键权衡说明：[what was explicitly traded off — what this decision means we will NOT do]
6. 预期结果：[what we expect to happen as a result of this decision]
7. 验证方式：[how and when we will know if this was the right decision]
8. 复审触发条件：[under what circumstances should this decision be revisited]

输出：结构化决策记录文档（便于未来团队成员理解决策背景）

提示词2 — 实验知识提炼报告

将以下AI实验的结果和发现提炼为可复用的团队知识。

实验名称：[experiment name]
实验假设：[what we believed would happen]
实验方法：[how the experiment was conducted]
实验结果：[what the data showed]
实验结论：[what we learned]

请从这个实验中提炼以下层次的知识：

1. 直接结论：[what this specific experiment proved or disproved]
2. 可推广洞察：[what learnings from this experiment might apply to similar situations in the future]
3. 方法论收获：[what we learned about how to run this type of experiment better next time]
4. 意外发现：[any unexpected observations that might be worth exploring further]
5. 反直觉发现：[anything that contradicted our prior beliefs — these are especially valuable]
6. 未解问题：[what questions this experiment raised that we still need to answer]

知识组织建议：[what knowledge category this should be filed under, what tags to apply, what related decisions or experiments it connects to]

输出：实验知识提炼报告 + 知识库归档建议

提示词3 — 新员工产品知识引导计划

为即将加入AI产品团队的新成员设计结构化的知识引导计划。

新成员角色：[role — PM, ML engineer, designer, etc.]
团队现状：[team size, product stage, current focus areas]
产品背景复杂度：[how much product history and context exists]
预期独立工作时间：[when should this person be working independently]

设计4–8周的知识引导计划：

第1-2周（背景建立）：
- 必读文档：[key documents and their purpose]
- 必参会议：[key recurring meetings to observe]
- 关键对话：[who to schedule 1:1s with and what to learn from each person]

第3-4周（工作流融入）：
- 跟随实践：[what to shadow and participate in]
- 第一个小项目：[a bounded task to build real context]
- 必理解的关键决策历史：[most important past decisions to understand]

第5-8周（独立贡献）：
- 第一个完整负责的任务：[definition and success criteria]
- 知识验证检查点：[how to assess whether onboarding knowledge transfer was successful]

知识传递成功标准：[specific things this person should know by end of onboarding]

输出：结构化知识引导计划 + 检查点定义 + 知识导师配对建议

45. AI 产品危机沟通与利益相关者管理手册

为AI产品故障、数据事件和伦理争议建立专业的危机沟通和利益相关者管理体系，在高压时刻保护产品声誉和用户信任。

痛点与解决方案

痛点：AI产品特有的故障模式让团队在危机时刻毫无准备，错误的沟通方式将小事件放大为公关灾难

AI产品面临传统软件没有的独特危机类型：模型产生歧视性输出、AI系统在高风险场景中给出危险建议、用户数据被用于训练导致的隐私争议、AI幻觉在关键业务决策中造成的实际损失。这些事件的危机特性与普通软件故障根本不同——它们触及用户对技术系统的信任、对AI公平性的期望和对数据隐私的关切，引发的舆情反应通常比功能性故障激烈得多，持续时间也更长。

AI产品团队在危机沟通上的典型失败模式是"工程师思维主导"的响应。工程团队在事件发生后的本能是深入技术细节：解释模型偏差的统计来源、描述数据处理的技术流程、用准确率指标说明系统实际表现。这些技术解释不仅无法安抚非技术受众，反而会加剧危机——受众感知到的是"他们在用技术话语回避责任"，而非"他们在诚实面对问题"。与此同时，营销团队的本能是淡化问题："这是个别案例"、"我们的系统总体上是安全的"，这种防御性话术在社交媒体时代会被迅速撕碎，使事件升级为声誉危机。

最危险的是缺乏准备的危机响应。AI产品团队通常没有预先定义好的危机响应流程、没有经过演练的沟通责任链、没有针对AI特有危机类型的沟通框架。当危机真正发生时，团队处于混乱状态：谁负责对外沟通、什么信息可以对外披露、如何同时向用户、监管机构、媒体和内部利益相关者沟通。在信息真空中，外部媒体和受影响用户会填充这个真空，通常是用对产品最不利的叙事框架。

COCO 如何解决

1. AI危机场景预案体系：COCO建立全面的危机准备机制：

   • 设计AI产品危机类型分类框架：将可能的危机按性质（技术/伦理/安全/隐私）和严重程度分级的分类体系
   • 创建高频危机场景预案库：针对最可能发生的AI危机类型（歧视性输出、幻觉危害、数据泄露）的预制响应方案
   • 建立危机响应决策树：基于危机类型和严重程度自动匹配响应级别和行动清单的决策框架
   • 生成危机演习方案设计：定期危机演练的场景设计，在真实危机前测试响应能力
   • 制定危机边界定义：明确区分需要立即公开披露的事件和可内部处理的问题的标准

2. 利益相关者沟通分层策略：COCO设计差异化的多方沟通：

   • 创建AI危机利益相关者地图：用户、监管机构、媒体、投资者、合作伙伴、员工各方的关切差异和沟通优先级
   • 设计分层沟通时序框架：哪些利益相关者应该最先被通知、通过什么渠道、传递什么核心信息
   • 建立监管机构沟通协议：在涉及隐私法规或AI监管的事件中与监管机构沟通的规范流程
   • 生成内部员工沟通模板：在危机期间保持员工了解情况、稳定团队士气的内部沟通框架
   • 制定媒体关系危机应对策略：面对媒体查询和负面报道时的响应策略和授权发言人体系

3. AI特有危机的沟通框架：COCO提供针对性的沟通指南：

   • 设计AI偏差和歧视事件沟通框架：如何在承认问题、解释原因和传达改进措施之间取得正确平衡
   • 创建AI幻觉危害事件响应脚本：当AI输出造成实际用户伤害时的责任承担和沟通框架
   • 建立AI数据隐私事件沟通协议：在可能涉及用户数据的AI训练或使用争议中的沟通规范
   • 生成AI安全漏洞披露框架：针对提示词注入、越狱攻击等AI特有安全事件的负责任披露流程
   • 制定AI能力误传危机应对：当产品能力被误解或夸大后用户期望落差引发争议的纠正沟通策略

4. 危机响应团队与流程设计：COCO建立危机时刻的组织保障：

   • 创建危机响应团队结构：明确危机期间产品、法务、公关、客服、工程各角色的职责和权限
   • 设计危机指挥中心运作规范：危机期间的决策机制、信息汇聚渠道和升级路径
   • 建立24小时危机监测体系：社交媒体、用户论坛、新闻媒体的危机信号监测和告警机制
   • 生成危机沟通审批流程：在确保响应速度的同时避免未经授权的危机声明的审批机制
   • 制定危机后复盘框架：系统性分析危机处理过程、提取学习并更新预案的复盘方法

5. 声誉修复与信任重建策略：COCO设计危机后的长期修复路径：

   • 创建用户信任重建路线图：在重大AI事件后通过具体行动（功能改进、透明度提升、赔偿机制）重建用户信任
   • 设计透明度提升措施：危机后增加AI系统可解释性和用户可见性的具体产品改进方向
   • 建立第三方审计和认证策略：通过独立审计和外部认证恢复外部公信力的路径设计
   • 生成案例学习与公开分享框架：将危机处理转化为行业学习机会，通过负责任披露建立声誉资本
   • 制定长期声誉监测体系：危机后持续追踪品牌信任度恢复情况的指标体系

6. 预防性声誉管理：COCO建立危机防患于未然的机制：

   • 设计AI产品声誉风险评估：在功能发布和模型更新前识别潜在声誉风险的前置评估框架
   • 创建用户期望管理策略：通过清晰的能力说明和使用限制传达减少期望落差引发争议的设计
   • 建立AI伦理审查流程：在高风险AI功能上线前的伦理影响评估和潜在危机识别
   • 生成媒体关系维护计划：在危机发生前建立媒体信任关系，为危机时刻储备公信力
   • 制定用户反馈快速响应体系：在用户投诉升级为公众事件之前的快速干预和解决机制

量化结果与受益角色

可量化成果

• 危机响应速度：预先准备的危机预案和响应团队使从事件发生到首次公开声明的时间从平均24–72小时缩短至4–8小时，减少信息真空期
• 声誉损失控制：有效的危机沟通使重大AI事件导致的用户流失率比无预案处理降低40–60%，品牌情感净值恢复速度加快50%
• 监管罚款规避：规范的监管沟通协议和主动披露策略使AI事件引发监管处罚的风险降低30–50%，避免因沟通不当导致的额外合规代价
• 员工稳定性：清晰的内部危机沟通使危机期间的员工离职率降低20–30%，避免危机期间关键人员流失加剧问题
• 危机后信任恢复：系统性的声誉修复行动使品牌信任指标从危机低点恢复到危机前水平的时间缩短40%

受益角色

• AI产品经理：获得在危机时刻保护产品声誉的系统性工具，从被动应急转变为主动预防和专业响应
• CEO和公关团队：在AI危机中提供清晰的行动框架，避免临阵出错的即兴沟通，以专业姿态维护企业公信力
• 法务与合规团队：通过规范化的事件响应和披露流程降低法律责任暴露，在危机处理中保持合规
• 客户成功与销售团队：危机期间的有效客户沟通保留了关键客户关系，防止竞争对手趁机挖角受影响客户

💡 实用提示词

提示词1 — AI危机响应预案设计

为以下AI产品危机场景设计完整的响应预案。

产品：[product name]
危机场景：[describe the specific AI crisis scenario — e.g., AI outputs discriminatory content, AI causes user harm, data privacy incident]
产品用户规模：[approximate user count]
监管环境：[relevant regulations — GDPR, AI Act, sector-specific]
可用的危机响应资源：[team members, legal support, PR support]

设计危机响应预案，包含：

1. 事件定性和分级：[how to assess severity — what makes this a P1 vs P2 vs P3 incident]
2. 前5小时行动清单：[exact steps in first 5 hours — who does what, in what order]
3. 利益相关者通知时序：[who gets notified when, through what channel, with what initial message]
4. 初始公开声明草稿：[draft first public statement — acknowledge, take responsibility, describe immediate action]
5. 技术响应与沟通并行计划：[how technical fix and communication run in parallel]
6. 24小时、72小时后续沟通计划：[what to communicate at each milestone as situation develops]
7. 升级触发条件：[what circumstances require escalating to CEO/board level response]

输出：完整危机响应预案 + 行动清单 + 沟通模板 + 决策树

提示词2 — AI偏差事件沟通框架

为以下AI产品偏差事件设计用户和公众沟通方案。

事件描述：[what happened — what AI output was produced, what harm or offense it caused]
受影响用户群体：[who was affected and how]
技术根因：[what caused the biased output — data, model, deployment]
已采取的技术修复措施：[what has been fixed or is being fixed]
监管通知要求：[any mandatory reporting obligations]

设计多层次沟通方案：

1. 直接受影响用户的个人化沟通：[direct outreach message — acknowledge impact, apologize, explain, offer remedy]
2. 全体用户通知：[product notification or email — what all users should know]
3. 公开声明：[press statement or blog post — balance transparency with legal caution]
4. 投资者/董事会简报：[what leadership needs to know — business impact, remediation plan, timeline]
5. 监管机构沟通（如适用）：[regulatory notification content and timeline]

每层沟通的核心原则：真诚承认问题、不推卸责任、说明具体改进措施、给出时间承诺

输出：分层沟通方案 + 各渠道具体文案 + 发布时序建议

提示词3 — 危机后信任重建计划

为经历了AI产品危机事件后设计用户信任重建计划。

危机事件概要：[brief description of what happened]
主要信任受损维度：[what specifically did users lose trust in — safety, privacy, reliability, fairness]
当前用户情绪状态：[based on feedback/social signals, how are users feeling]
可用的信任重建资源：[what changes, features, or commitments can realistically be made]
时间约束：[any competitive or regulatory deadlines that affect the timeline]

设计6个月信任重建计划：

第1个月（行动期）：[concrete product changes or policy changes that demonstrate commitment]
第2-3个月（透明度期）：[public reporting on what has been done and measured outcomes]
第4-6个月（证明期）：[third-party validation, user feedback programs, expanded transparency]

每个阶段的用户沟通策略：[what to communicate, through what channels, with what evidence]

信任恢复指标：[how to measure whether trust is being rebuilt — NPS trend, usage recovery, sentiment analysis]

输出：信任重建路线图 + 阶段性沟通计划 + 信任指标监测框架

46. AI 产品收益归因与商业案例构建器

将AI功能投资与可量化的业务结果精确连接，构建数据驱动的AI产品商业案例，为资源争取和战略决策提供可信的财务依据。

痛点与解决方案

痛点：AI产品团队无法清晰证明AI投资的财务回报，导致资源争取艰难和战略可信度不足

AI产品经理面临一个根本性的商业论证困境：他们通常能够用技术指标证明AI系统在变好（更低的幻觉率、更高的基准分数、更快的响应速度），却无法令人信服地证明这些技术改进转化为了可量化的业务价值。这个翻译失败的代价是巨大的：工程预算在年度规划时被削减，关键的AI基础设施投资被推迟，更糟糕的是，AI产品在整个公司内被定位为"成本中心"而非"增长引擎"。

AI产品收益归因比传统软件产品更复杂，原因是多重的。首先，AI带来的价值往往是渐进式的（用户完成任务稍微快一点、错误稍微少一点）而非离散式的（新功能上线带来明显的指标跳升），这使得常规的A/B测试方法难以捕捉全部价值。其次，AI产品的价值往往在间接渠道体现——因为AI功能而留存的用户后来升级了付费计划，因为AI能力而赢得的企业客户带来了高价值的扩展合同，这些间接影响链条难以追踪。第三，AI基础设施投资（更好的数据管道、更快的实验基础设施）的价值体现在整个产品组合的迭代速度上，而非某个特定功能，这类"平台价值"尤其难以量化。

更深层的挑战是商业案例质量的信任问题。当AI产品团队提出声称"AI功能将带来40%的留存提升"的商业案例时，财务团队和管理层的直觉是怀疑——因为他们见过太多技术团队的乐观预测没有实现。建立AI投资商业案例的可信度需要的不只是合理的假设，而是严格的方法论、清晰的不确定性承认和历史预测准确率的追踪记录。

COCO 如何解决

1. AI功能价值测量框架：COCO建立严格的收益量化体系：

   • 设计AI功能价值链映射：从AI技术改进到用户行为变化再到业务指标的因果链条建模
   • 创建直接价值测量方法论：A/B测试设计、保留收益计算、任务完成效率提升量化
   • 建立间接价值归因模型：将AI功能对留存率、升级率、NPS的贡献从其他因素中剥离
   • 生成平台价值估算框架：AI基础设施投资对整体产品迭代速度的价值量化方法
   • 制定价值测量不确定性量化：对每个价值假设的置信区间和敏感性分析标准

2. AI投资商业案例构建：COCO提供可信的财务论证框架：

   • 创建AI产品ROI计算模型：成本（工程、算力、数据）与收益（留存、扩展、效率）的完整财务模型
   • 设计情景分析框架：基准、乐观、悲观三种情景下的投资回报预测
   • 建立同类竞品ROI基准：用行业数据校准自身预测，提升商业案例可信度
   • 生成投资回收期分析：不同AI投资类型的典型投资回收时间线和里程碑
   • 制定"如果不投资"成本分析：量化不做AI投资的机会成本和竞争劣势成本

3. 收益归因分析体系：COCO构建精确的价值来源追踪：

   • 设计多触点AI归因模型：在用户旅程的多个AI接触点中合理分配价值贡献
   • 创建AI功能留存影响分析：隔离AI功能使用对用户留存的净影响，控制混淆变量
   • 建立AI驱动的扩展收入追踪：识别AI功能使用与账户升级、扩座之间的统计关联
   • 生成AI成本节约量化：用AI替代人工审核、内容生成、数据分析的成本节约计算
   • 制定AI品牌价值评估：AI产品声誉对品牌溢价和新客户获取成本的影响评估

4. 资源申请财务论证工具：COCO武装团队的内部资源争取：

   • 创建工程团队规模扩张商业案例模板：为增加ML工程师、数据工程师构建财务论证
   • 设计算力预算申请框架：将模型训练和推理成本增加与预期收益增量量化连接
   • 建立AI工具采购商业案例：第三方AI API、MLOps平台、数据标注服务的采购ROI论证
   • 生成数据采集投资商业案例：高质量训练数据采购或生成的价值量化框架
   • 制定AI安全和合规投资论证：将AI安全投资与风险成本规避量化连接

5. 历史预测准确率建设：COCO积累可信的预测记录：

   • 设计商业案例预测追踪系统：系统记录每个AI投资的预测值与实际值，建立预测历史
   • 创建预测校准方法论：基于历史数据调整未来预测的系统性偏差
   • 建立预测假设记录：明确记录每个商业案例的关键假设，便于事后验证哪些假设成立
   • 生成商业案例复盘制度：每个重大AI投资完成后的复盘报告，比较预测与实际
   • 制定可信度评分体系：为不同类型AI投资的商业案例设定基于历史准确率的可信度评分

6. 高管和董事会财务沟通：COCO提升财务汇报质量：

   • 创建AI产品P&L（损益表）框架：以财务语言呈现AI产品单元经济学的报告格式
   • 设计AI投资组合回报分析：跨多个AI项目的投资回报综合分析和优化建议
   • 建立AI产品估值贡献框架：AI能力对公司整体估值倍数的贡献分析（适用于融资场景）
   • 生成董事会AI投资汇报模板：季度、年度AI投资回报汇报的结构化格式
   • 制定CFO对话工具包：与财务领导讨论AI投资的专业对话框架和常见问题应对

量化结果与受益角色

可量化成果

• 预算获批率提升：具备严格财务论证的AI投资申请获批率比模糊的技术需求申请高出50–70%，加速团队资源积累
• 资源分配优化：基于ROI数据的AI投资组合管理使资源向高回报项目集中，整体AI投资效率提升25–40%
• 商业案例准确率：建立预测追踪和校准机制后，AI投资预测实际偏差从平均40–60%缩小至15–25%，显著提升财务可信度
• CFO和管理层信任度：能够以财务语言汇报AI价值的PM在年度规划中的影响力和资源获取成功率平均提升30%
• 投资者叙事质量：清晰的AI产品ROI数据和商业案例体系使融资过程中的AI价值传递更有说服力，影响估值倍数

受益角色

• AI产品经理：从只能汇报技术指标升级为能够用财务语言证明AI投资价值，大幅提升在公司战略中的影响力
• CFO和财务团队：获得可信的AI投资ROI数据，将AI从模糊的战略性投入转变为可评估、可管理的财务资产
• CEO和董事会：建立对AI产品价值的清晰认知，支持更有信心的AI战略投资决策
• ML工程和数据团队：技术工作的价值得到财务量化，工程师能够看到自己的工作对业务的具体影响，提升工作意义感

💡 实用提示词

提示词1 — AI功能投资商业案例

为以下AI功能投资建立完整的商业案例。

产品：[product name]
AI功能/投资项目：[describe the AI feature or infrastructure investment]
投资规模：[engineering weeks, infrastructure cost, data cost]
预期上线时间：[when the feature will be live]
目标用户群：[who will use this feature]
假设的主要价值驱动：[what you believe this will improve]

建立商业案例：

1. 成本分析：
   - 建设成本：[one-time development costs]
   - 运营成本：[ongoing inference, maintenance costs per month]
   - 机会成本：[what else could be built with these resources]

2. 收益分析：
   - 主要价值假设1：[specific metric you expect to improve + % improvement assumption + justification]
   - 主要价值假设2：[another metric + improvement + justification]
   - 货币化连接：[how metric improvements translate to revenue or cost savings]

3. 情景分析：
   - 乐观场景（假设成立，执行顺利）：[12-month ROI]
   - 基准场景（50%的假设成立）：[12-month ROI]
   - 悲观场景（假设基本不成立）：[12-month ROI]

4. 关键假设和验证计划：[list top 3 assumptions with how and when each will be validated]

输出：完整商业案例文档 + 财务模型 + 假设追踪表 + 30/60/90天验证里程碑

提示词2 — AI产品收益归因分析

对以下AI功能进行上线后的收益归因分析，量化其实际业务价值。

AI功能：[feature name]
上线时间：[launch date]
分析周期：[time since launch, e.g., 90 days]
可用数据：[what metrics and user data is available for analysis]
同期发生的其他变化：[other product changes, marketing campaigns, seasonality factors that may confound results]

进行收益归因分析：

1. A/B测试结果（如果有）：[treatment vs control group comparison on key metrics]

2. 功能使用者vs非使用者对比：
   - 留存率差异：[retention rate of feature users vs non-users, controlling for selection bias]
   - 收入差异：[ARPU comparison, controlling for user segment differences]
   - 满意度差异：[NPS/CSAT comparison if available]

3. 混淆因素控制：[how you're accounting for other factors that might explain the differences]

4. 保守价值估算：[conservative calculation of attributable revenue/retention impact]

5. 预测 vs 实际对比：[how actual results compare to the original business case assumptions]

结论与建议：继续投资 / 优化后继续 / 重新定向 / 停止投资

输出：收益归因分析报告 + 预测准确率记录 + 下一步投资建议

提示词3 — AI产品预算申请框架

为以下AI产品资源申请构建财务论证，准备年度或季度预算申请。

申请内容：[what resources you're requesting — headcount, compute budget, tools, data]
申请规模：[dollar amount or headcount]
申请背景：[annual planning / quarterly reforecast / urgent need]
决策者：[who approves this — VP, CFO, CEO, board]

构建预算申请：

1. 现状描述：[current resource constraints and their business impact — be specific about what's not being done]
2. 申请内容详述：[exactly what you're requesting and why each component is needed]
3. 投资回报论证：
   - 短期收益（3-6个月）：[specific, measurable outcomes expected]
   - 中期收益（12个月）：[business impact projections with methodology]
   - 长期价值（24+ months）：[strategic value and competitive implications]
4. 不批准的成本：[what happens if this request is denied — opportunity cost, competitive risk, technical risk]
5. 成功验证计划：[specific metrics and timelines to prove the investment was worthwhile]

决策者专属论据：[customize the argument for your specific approver's top concerns]

输出：预算申请文档 + 财务论证 + 决策者专属一页纸摘要

47. AI 产品生态系统与合作伙伴策略构建器

规划AI产品的生态系统布局和合作伙伴策略，通过战略性合作关系加速产品能力扩张、拓宽分发渠道，构建难以复制的平台护城河。

痛点与解决方案

痛点：孤立的AI产品难以在平台经济时代建立持久竞争优势，生态建设被当作可选项而非战略必需

AI产品市场正在经历一个快速的平台化进程。少数几个底层AI模型供应商（OpenAI、Anthropic、Google、Meta）提供基础能力，垂直AI应用在其上构建，企业客户通过集成到现有工作流中使用。在这个生态中，孤立运作的AI产品面临结构性劣势：它们必须独自承担所有用户获取成本、独自面对用户工作流集成的摩擦、独自与平台上其他应用竞争注意力。而具有良好生态布局的AI产品，通过合作伙伴渠道获取大量低成本流量，通过深度集成创造留存护城河，通过互补能力组合提供单独任何一方都无法提供的价值。

AI产品的合作伙伴策略比传统软件更复杂，因为AI能力本身可以成为合作的核心交换物。AI产品不仅可以寻求传统的分发合作（将产品嵌入合作方的用户界面），还可以进行能力互换（将AI能力提供给合作方，换取数据、分发或互补能力），甚至构建技术栈层级合作（成为某个技术生态的基础设施层）。这种多维度的合作可能性既是机遇也是挑战——产品团队需要清晰的框架来识别哪种合作模式最符合当前阶段的战略需求，避免陷入资源分散的合作陷阱。

最常见的失败模式是将合作伙伴关系与直接销售割裂管理。很多AI产品公司建立了合作伙伴项目，但合作带来的线索进入销售漏斗后和直销线索处理方式相同，没有为合作伙伴渠道设计专属的成交流程和成功指标，导致合作伙伴对渠道价值失去信心，逐渐停止推荐。生态建设需要的是端到端的设计思维——从合作伙伴招募、价值传递、联合市场推广到共同客户成功的完整运营体系。

COCO 如何解决

1. AI生态战略框架设计：COCO规划战略性生态布局：

   • 创建AI生态角色分析矩阵：识别底层模型供应商、互补应用、分发平台、系统集成商、企业客户各自的角色和合作价值
   • 设计生态布局优先级框架：基于产品阶段、战略目标和资源约束选择生态建设优先方向
   • 建立竞争与合作边界分析：识别潜在合作伙伴中的竞合关系，设计正确的合作保护机制
   • 生成生态护城河构建路径：如何通过数据网络效应、集成深度和合作伙伴专属功能构建可持续竞争优势
   • 制定生态演进路线图：从早期双赢小规模合作到平台级生态布局的分阶段路线

2. 合作伙伴价值主张设计：COCO构建吸引优质合作伙伴的方案：

   • 创建分类型合作伙伴价值主张：技术合作伙伴、渠道合作伙伴、系统集成商、战略联盟各类型的专属价值提案
   • 设计合作伙伴收益模型：佣金结构、共同收入分享、联合营销资源、优先技术访问的合作激励设计
   • 建立合作伙伴分级体系：基于贡献度和战略价值的合作伙伴层级划分和差异化权益
   • 生成合作伙伴技术集成支持包：API文档、SDK、沙箱环境、集成工程师支持的合作伙伴技术赋能体系
   • 制定合作伙伴市场活动资源：联合品牌、共同市场推广资源和案例共建的合作伙伴营销框架

3. 战略合作谈判框架：COCO提供合作谈判支持：

   • 设计AI合作协议核心条款：数据使用权限、IP归属、能力限制、竞业禁止、终止条款的AI合作专项条款库
   • 创建合作价值量化方法：在谈判中客观评估双方贡献、确定公平分配比例的框架
   • 建立合作伙伴尽职调查清单：技术兼容性、合规状态、市场信誉、客户基础的合作前评估框架
   • 生成合作谈判策略指南：不同类型合作（技术整合、渠道合作、联合营销）的谈判重点和让步策略
   • 制定合作伙伴协议风险评估：识别不公平条款、锁定风险和IP保护漏洞的合同审查框架

4. 合作伙伴运营体系建设：COCO确保合作关系持续创造价值：

   • 创建合作伙伴引导计划：让新合作伙伴快速理解产品能力、集成方式和联合销售策略的标准化引导
   • 设计合作伙伴成功指标体系：追踪合作伙伴贡献的线索量、成交量、客户满意度和收入的量化指标
   • 建立合作伙伴定期沟通机制：QBR（季度业务回顾）、技术更新简报、合作发展路线图的沟通节奏
   • 生成合作伙伴冲突解决框架：客户归属争议、定价冲突、产品能力重叠的合作伙伴关系维护机制
   • 制定合作伙伴退出管理流程：合作关系调整、降级或终止时的有序管理，保护客户关系和品牌声誉

5. 平台与API生态建设：COCO设计技术生态扩张策略：

   • 创建开发者生态分层框架：从个人开发者到独立软件供应商（ISV）到大型系统集成商的差异化支持策略
   • 设计API产品化策略：将核心AI能力包装为开发者友好的API产品的产品化路线图
   • 建立应用市场战略：是否以及如何构建应用市场或插件生态的战略决策框架
   • 生成开发者社区建设计划：吸引、留存和赋能外部开发者的社区运营策略
   • 制定生态数据网络效应设计：如何通过开放数据、模型反馈和集成数据强化核心产品的数据飞轮

6. 生态系统健康度监测：COCO追踪生态建设成效：

   • 设计生态健康度指标体系：合作伙伴数量增长、集成深度、合作贡献收入比例、开发者活跃度的综合指标
   • 创建合作伙伴满意度监测：定期的合作伙伴NPS调查和关系健康评估机制
   • 建立生态竞争风险监测：追踪合作伙伴是否同时发展了与我方竞争的自有能力
   • 生成生态价值归因分析：量化生态系统对总体收入、用户获取和产品能力的贡献
   • 制定生态演进决策框架：基于生态健康数据做出调整合作深度、扩展新合作伙伴类型的决策

量化结果与受益角色

可量化成果

• 渠道收入增长：成熟的合作伙伴生态可以贡献总收入的20–40%，有效降低直销成本，提高增长效率
• 用户获取成本降低：通过合作伙伴渠道获取的用户CAC通常比自有渠道低30–50%，同时带来更高的初始账户价值
• 产品集成深度：深度生态集成使用户切换成本显著增加，集成企业客户的年均流失率比非集成客户低20–35%
• 产品能力扩展速度：通过技术合作伙伴关系，产品可以在不增加工程资源的前提下快速扩展互补能力覆盖范围
• 市场进入速度：借助具有行业资源的战略合作伙伴进入新垂直市场，速度比自建渠道快3–5倍，成本低50–70%

受益角色

• AI产品经理：获得系统性的生态策略框架，将产品从单点竞争提升至平台级竞争，建立持久的市场优势
• 业务拓展和合作伙伴团队：建立结构化的合作伙伴招募、运营和成功体系，提升合作关系管理的专业度和效率
• 销售团队：通过合作伙伴渠道获得更多合格线索，利用合作伙伴的行业信任度加速销售周期
• 产品工程团队：清晰的API和生态开放策略使技术资源集中在核心能力上，通过生态扩展周边能力

💡 实用提示词

提示词1 — AI产品生态战略规划

为以下AI产品制定生态系统和合作伙伴战略规划。

产品：[product name and core AI capabilities]
当前阶段：[early-stage / growth / scale]
主要目标市场：[verticals, geographies, company sizes]
当前合作伙伴情况：[existing partnerships if any]
最大的增长瓶颈：[what's limiting growth — distribution, capabilities, data, trust]

制定生态战略：

1. 生态地图绘制：
   - 技术生态层：[which AI infrastructure providers, complementary AI tools, data providers are relevant]
   - 分发生态层：[which channels, platforms, and marketplaces reach your target customers]
   - 集成生态层：[which enterprise systems your customers use that you should integrate with]
   - 行业生态层：[which industry-specific partners add credibility and distribution in target verticals]

2. 优先合作伙伴类型选择：[given your stage and goals, which partner types to prioritize and why]

3. 前5大目标合作伙伴：[specific companies to approach, value proposition to each, priority order]

4. 生态护城河设计：[how partnerships will create barriers to competition over time]

5. 12个月生态建设里程碑：[what you aim to have in place at 3, 6, 12 months]

输出：生态战略文档 + 合作伙伴优先级地图 + 12个月执行计划

提示词2 — 合作伙伴价值主张设计

为以下AI产品设计面向特定合作伙伴类型的价值主张和合作方案。

我方产品：[product name and core AI capabilities]
目标合作伙伴类型：[technology partner / channel partner / system integrator / strategic alliance]
目标合作伙伴代表：[specific company or type of company you're targeting]
我方希望从合作中获得：[what we want — distribution, data, capabilities, credibility]
合作伙伴希望获得：[based on their business model and goals, what they likely want]

设计合作提案：

1. 合作背景与机会：[why this partnership makes strategic sense now]
2. 对合作伙伴的具体价值：[quantified value to them — revenue potential, customer value, competitive advantage]
3. 对我方的价值：[what we gain]
4. 合作模式设计：[technical integration, commercial arrangement, go-to-market collaboration]
5. 收益分配方案：[revenue sharing, referral fees, or value exchange if non-monetary]
6. 成功标准：[how both sides define and measure partnership success]
7. 启动计划：[first 90 days — pilot customer, joint marketing, integration milestone]

输出：合作提案文档 + 财务模型 + 启动计划

提示词3 — 合作伙伴运营体系设计

为以下AI产品设计合作伙伴管理和运营体系，确保合作关系持续创造业务价值。

产品：[product name]
当前合作伙伴数量：[how many active partners]
合作伙伴类型：[types of partners in the ecosystem]
合作伙伴运营现状：[what currently exists for partner management]
主要运营痛点：[what's not working in current partner management]

设计合作伙伴运营体系：

1. 合作伙伴分级制度：[criteria for different tiers, benefits at each tier, requirements to advance]
2. 引导程序：[standardized onboarding for new partners — timeline, key milestones, success criteria]
3. 赋能资源包：[training, certification, sales tools, technical documentation, co-marketing templates]
4. 绩效追踪：[metrics to track for each partner, how data is collected, review cadence]
5. 沟通节奏：[newsletter, QBR, product updates, escalation channels]
6. 激励机制：[what rewards high performance — financial incentives, preferred status, exclusive access]

输出：合作伙伴运营手册 + 分级标准 + 绩效追踪仪表板规格 + 沟通日历模板

48. AI 产品长期愿景与创新管道构建器

构建AI产品的长期愿景叙事和创新管道管理体系，在日常迭代压力下系统性探索突破性机会，确保产品在3–5年维度保持战略领先地位。

痛点与解决方案

痛点：日常迭代压力挤占战略思考空间，AI产品团队陷入功能工厂陷阱，失去长期领先能力

AI产品团队面临一个几乎普遍的困境：季度OKR、功能请求积压和竞争压力共同形成的"即时性暴政"，使团队的绝大多数时间和精力都消耗在未来12–18个月的执行层面。这在短期内产生了清晰的可见成果（用户增长、功能交付、技术指标改善），但在战略层面留下了巨大盲区：AI能力的代际跃迁如何改变产品的核心价值主张？当前的竞争优势在未来3–5年是否仍然有效？用户期望的演变轨迹会将市场引向什么方向？没有系统性回答这些问题的团队，会在某个时刻突然发现自己的产品虽然功能完善，却已经不再是用户真正需要的东西。

长期愿景建设在AI产品领域比其他行业更难，但也更重要。更难，是因为AI技术本身的快速演进使任何超过18个月的预测都充满不确定性——多模态能力的成熟速度、推理成本的下降曲线、监管框架的发展方向都在快速变化，使传统的3–5年产品战略规划难以保持有效性。更重要，是因为AI产品的竞争格局正在经历结构性重塑——底层模型能力的快速提升意味着建立在已有能力上的差异化优势会被快速侵蚀，只有那些能够持续发现新的价值定位、提前布局的团队才能保持领先。

更具体的挑战是创新管道的管理困境。即使团队意识到长期探索的重要性，也往往缺乏在日常迭代压力下保护探索空间的有效机制。20%探索时间的政策在季度末的紧急交付压力下往往第一个被牺牲。探索性项目因为缺乏清晰的成功标准和里程碑，在不确定性面前容易被放弃。真正有潜力的创新方向因为无法量化短期ROI而在资源分配中处于劣势。团队需要的是一套将长期探索制度化的框架，让战略创新在日常运营压力下得以持续。

COCO 如何解决

1. AI产品长期愿景构建：COCO帮助团队建立方向感：

   • 设计AI能力演进预测框架：基于技术趋势、研究方向和成本曲线预测未来2–5年的AI能力边界
   • 创建用户期望演进模型：追踪用户随着AI使用经验增长的期望提升曲线，预测未来的价值门槛
   • 建立愿景叙事构建方法论：从技术可能性、用户需求和市场机会三个维度构建有说服力的产品长期愿景
   • 生成愿景压力测试框架：用多种未来情景（技术发展快/慢、监管收紧/放松、竞争加剧/缓解）测试愿景的稳健性
   • 制定愿景更新机制：定期评估愿景是否需要调整的触发条件和更新流程

2. 创新管道分层管理：COCO建立系统性的探索机制：

   • 设计三层创新投资组合：核心优化（确定性高回报）、相邻探索（有风险的增量创新）、变革性实验（长期潜力）的资源分配框架
   • 创建探索性项目保护机制：在日常迭代压力下保护创新探索空间的制度设计
   • 建立创新项目晋级标准：探索性想法从假设、小规模实验到正式立项的里程碑和晋级标准
   • 生成创新失败文化建设框架：建立心理安全感，让团队愿意尝试高风险、高不确定性的创新方向
   • 制定跨团队创新贡献机制：让ML工程师、设计师、销售团队都能为创新管道贡献想法的流程设计

3. 前沿技术机会评估：COCO系统性识别颠覆性机会：

   • 创建新兴AI技术机会扫描框架：持续监测学术前沿、开源突破和行业实验，识别值得关注的技术方向
   • 设计技术-产品机会映射方法：将抽象的技术突破翻译为具体的产品机会和用户价值的系统性方法
   • 建立技术成熟度评估模型：评估新技术从实验室到产品化就绪的距离，确定适当的介入时机
   • 生成技术赌注组合策略：在多个技术方向上合理分配探索资源的投资组合思维
   • 制定快速原型验证框架：用最少资源快速测试新技术假设的精益验证方法论

4. 战略情景规划：COCO提升对不确定未来的适应能力：

   • 设计AI产品情景规划方法论：构建多种未来情景并为每种情景制定对应策略的结构化规划方法
   • 创建关键不确定性识别框架：识别对产品长期战略影响最大的外部不确定因素
   • 建立情景先行指标体系：为每个未来情景设定可观测的早期信号，实现情景监测
   • 生成战略选项设计框架：为不同情景预先设计可激活的战略响应方案，减少不确定性下的决策延迟
   • 制定战略灵活性评估：评估当前产品架构和团队能力对不同未来情景的适应性

5. 创新文化与组织设计：COCO构建有利于长期创新的组织环境：

   • 创建创新时间保护制度：定期的无KPI创新时间、黑客松和探索项目的制度化设计
   • 设计跨职能创新团队模式：打破职能边界的创新小组运作模式和激活机制
   • 建立外部创新输入体系：学术合作、创新实验室、行业顾问的系统性外部智慧输入机制
   • 生成创新指标体系：追踪创新探索活跃度、想法转化率和长期创新价值的量化指标
   • 制定创新成果推广机制：将探索中的有效学习系统性传播到整个团队的知识分享框架

6. 长期愿景与日常执行对齐：COCO建立战略到战术的连接：

   • 设计愿景驱动的路线图规划：将长期愿景分解为中期里程碑和近期优先级的规划级联
   • 创建战略性停止决策框架：识别哪些当前工作在长期愿景下应该减少甚至停止，释放资源给战略重点
   • 建立长期指标与短期指标平衡机制：防止短期指标优化侵蚀长期价值创造潜力
   • 生成年度战略审视流程：每年重新审视长期愿景有效性和战略方向校准的结构化流程
   • 制定向内部利益相关者传达长期愿景的方法：让工程师、设计师和销售团队理解并认同长期方向的愿景传播策略

量化结果与受益角色

可量化成果

• 创新管道丰富度：系统性的创新探索机制使处于不同成熟阶段的创新项目数量提升2–3倍，降低对单一路线的依赖风险
• 战略方向调整速度：基于情景规划和先行指标的战略监测使重大市场变化后的战略方向调整决策速度提升40–60%
• 团队战略参与度：清晰的长期愿景使团队成员对自身工作与公司未来方向关联的感知提升，员工满意度和留存率提升15–25%
• 突破性功能成功率：系统性的探索管道和严格的原型验证使真正进入全面开发的探索项目成功率从20–30%提升至50–60%
• 投资者战略信心：清晰的长期愿景叙事和创新管道展示使融资过程中的战略可信度显著提升，影响估值倍数

受益角色

• AI产品经理：从专注季度执行的战术执行者成长为能够影响公司3–5年方向的战略贡献者
• CEO和联合创始人：获得系统性的长期战略规划工具，在日常运营压力下保持对长期机会的清醒认知
• 投资者和董事会：建立对公司长期创新能力和战略远见的信心，支持更高估值和更大战略投资
• ML研究和工程团队：在明确的长期方向指引下，技术探索有了清晰的战略锚点，激发更有针对性的技术创新

💡 实用提示词

提示词1 — AI产品长期愿景构建

为以下AI产品构建3–5年的长期愿景叙事。

产品：[product name and current value proposition]
当前阶段：[stage, traction, team size]
核心技术优势：[what we're uniquely good at]
当前用户痛点核心：[deepest problem we solve]
目标市场演变趋势：[how the market and user needs are changing]

构建长期愿景，包含：

1. 未来AI能力假设：[what AI capabilities will be available in 3-5 years that will change what's possible]
2. 用户期望演进：[how user expectations of AI products will shift as they become more AI-native]
3. 市场结构变化：[how the competitive landscape and market structure will evolve]
4. 我们的长期差异化：[what unique position we can occupy that will be hard to replicate]
5. 愿景叙事：[compelling 2-3 paragraph narrative of the future state we're building toward]
6. 通往愿景的里程碑：[3-year, 5-year markers that indicate we're on track]

愿景压力测试：[does this vision hold up if AI capability development is slower than expected? If a major tech player enters our space? If regulation tightens?]

输出：长期愿景文档 + 里程碑路线图 + 愿景压力测试报告 + 内部传播版本

提示词2 — 创新管道规划与管理

为以下AI产品设计创新管道管理体系，确保在日常迭代压力下持续探索突破性机会。

产品：[product name]
团队规模：[total team, engineering capacity]
当前创新探索状态：[do you have any active exploratory projects? What's the culture around experimentation?]
最近一次重大创新：[last time you launched something genuinely new vs. incremental]
长期愿景：[where you want the product to be in 3-5 years]

设计创新管道体系：

1. 三层投资组合分配：
   - 核心优化（70%资源）：[what incremental improvements drive near-term value]
   - 相邻探索（20%资源）：[adjacent opportunities worth exploring systematically]
   - 变革性实验（10%资源）：[long-shot bets with potentially transformative payoff]

2. 探索想法来源：[structured mechanisms to collect innovative ideas from team, users, research, adjacent markets]

3. 快速验证流程：[how to test a new idea with minimum resources before committing to full development]

4. 晋级决策标准：[what evidence justifies moving an exploratory idea to next stage of investment]

5. 探索时间保护机制：[institutional design to protect innovation time from quarterly execution pressure]

6. 创新成果传播：[how to share learnings from exploratory work across the team]

输出：创新管道体系设计 + 投资组合分配建议 + 验证流程模板 + 时间保护制度设计

提示词3 — AI产品战略情景规划

为以下AI产品进行战略情景规划，为多种可能的未来做好准备。

产品：[product name]
核心业务假设：[what must be true for your current strategy to succeed]
主要外部不确定性：[what external factors could significantly change your situation]
时间范围：[2 years / 3 years / 5 years]

构建3个情景：

情景A（基准情景）：[most likely path — what the world looks like if current trends continue]
- AI能力发展速度：[moderate / on current trajectory]
- 竞争格局变化：[incremental, no major disruptions]
- 监管环境：[current trajectory, gradual tightening]
- 我们的产品在此情景中的地位：[where are we in this world]

情景B（加速情景）：[faster AI advancement, more favorable conditions]
- 关键变化：[what accelerates, what opens up]
- 对我们的机会：[what becomes possible that isn't today]
- 我们需要做什么来抓住这个情景：[what capabilities and bets to make now]

情景C（颠覆情景）：[a major disruption that challenges current assumptions]
- 颠覆来源：[new competitor, technology shift, regulatory change, market change]
- 对当前战略的威胁：[what specifically would break]
- 我们的防御和转型选项：[how to respond if this scenario materializes]

跨情景战略建议：[what should we do NOW regardless of which scenario unfolds — the robust bets]

先行指标监测：[for each scenario, what early signals would suggest it's materializing]

输出：三情景分析 + 跨情景稳健战略 + 先行指标监测体系 + 触发响应计划