| name | xx-ai-feature |
| description | 判断产品里要不要内置 AI 能力。当用户的产品想法已经过需求澄清，在决定要不要给产品加 AI 功能时使用。通过 4 个问题的决策链，15 分钟内给出"加 AI 功能 / 用规则功能 / 混合 / 不加"的结论，附判断标准与 AI 执行约束。 |
产品里要不要内置 AI：一个判断框架
不是所有产品功能都需要 AI。规则能做的别上 AI，再判断 AI 带来的价值能不能盖过成本。
这个技能做什么
帮你在 15 分钟内判断"我的产品某个功能要不要做成 AI 功能"，避免硬塞 AI 导致成本失控和体验下降。
输出一张产品 AI 能力决策卡，明确告诉你：这个功能加 AI、用规则功能、混合、还是不加 AI。
本技能面向"用自然语言提需求、看结果提优化"的用户：你不需要懂技术细节，只需按 4 个问题如实描述功能场景，AI 负责走完决策链并给出结论和风险。
AI 执行约束： 走决策链时必须按 Q1→Q2→Q3→Q4 顺序，前面问题答完能停就停，不要跳过。每个问题的"是/否"必须有场景事实支撑，不能凭感觉给结论。
1. 先问 4 个问题
按顺序回答，前面问题答完就能停。
Q1：这个功能，规则/查表能做吗？
- 是（能枚举、能查表、能用固定模板）→ 做成规则功能，不加 AI，到此结束
- 否（需要理解、生成、开放集合）→ 继续 Q2
为什么先问这个： 规则能搞定的事做成 AI 功能是过度设计，徒增成本和不确定性。
Q2：用户能容忍这个功能偶尔不准吗？
- 要 100% 准确（计算、金额、合规）→ 做成规则功能，到此结束
- 容忍 80-95%（用户能接受偶尔不完美）→ 继续 Q3
为什么问这个： AI 的本质是概率输出，做不到 100%。产品功能要 100% 准确的场景硬上 AI 就是给用户挖坑。
Q3：AI 功能出错，用户能发现吗？
- 错了用户无感知（会静默失败）→ 慎用 AI 功能，必须配强监控，到此结束
- 错了用户能看出来 → 继续 Q4
为什么问这个： 静默失败是 AI 产品功能最大的坑。用户不知道错了，按错的用，最后出大事。
Q4：这个 AI 功能的价值 > 单次调用成本吗？
- 调用成本 > 单次业务价值 → 不加这个 AI 功能，到此结束
- 价值 > 成本 → 可以加 AI 功能
为什么问这个： AI 每次调用都要钱。如果一个功能单次调用成本 5 分钱，但给用户只值 1 分钱价值，用一次亏一次。
怎么粗估成本： 国内主流大模型按 token 计费，输入约 0.5-2 元/百万 token，输出约 1-8 元/百万 token。一次普通调用（输入 200 字 + 输出 100 字）大约几厘到几分钱。图片生成按张计费，约 2-8 分/张。不确定就直接问 AI："我用的 XX 模型，这个功能一次调用大概多少钱？"
判断标准： 4 个问题任一答"否/慎用"且对应结论成立，就按该结论走，不要硬往下走。决策链的价值在于"早停"，不在于走完。
2. 产品里适合加 AI 功能的场景
| 场景特征 | 例子 |
|---|
| 功能输入有大量长尾变化 | 客服问答、内容审核、自由文本分类 |
| 用户容忍 80-95% 准确率 | 起名建议、文案生成、中式色名命名 |
| 错误可被用户发现纠正 | 翻译润色、配色命名、代码补全 |
| 价值高到能覆盖调用成本 | 合同风险识别、医疗影像辅助、海报生成 |
3. 产品里不适合加 AI 功能的场景
| 场景特征 | 替代方案 |
|---|
| 功能规则可枚举、能查表 | 做成规则功能 / 查表功能 |
| 要求 100% 准确 | 规则功能 + 人工校验 |
| 调用成本 > 业务价值 | 不加 AI，或用免费方案 |
| 高频低价值（每次调用都不值） | 规则功能 + 缓存 |
4. 决策流程图
开始：产品某个功能要不要做成 AI 功能
↓
Q1：规则/查表能做？
├─ 是 → 做成规则功能
└─ 否 ↓
Q2：用户容忍 <100% 准确？
├─ 否 → 做成规则功能
└─ 是 ↓
Q3：AI 出错用户能发现？
├─ 否 → 慎用 AI 功能（需强监控）
└─ 是 ↓
Q4：价值 > 成本？
├─ 否 → 不加 AI 功能
└─ 是 → 加 AI 功能
5. 混合模式：AI 功能 + 规则功能
大多数真实产品是混合的：核心功能用规则保证确定性，部分环节加 AI 处理模糊和长尾。
- 规则功能处理确定性环节（转换、校验、模板）
- AI 功能处理模糊和长尾（命名、生成、理解）
- AI 结果用规则做后校验
例子：小象取色
- 规则功能：Hex→HSL 转换、色名库后校验、缓存命中、Canvas 海报拼版
- AI 功能：开放式中式色名生成
- 交接点：AI 生成色名 → 规则去色名库校验 → 库内用库内名，库外降级标注
这种分工让规则保证底线（数字、格式不能错），AI 发挥优势（理解文化语义、生成创意）。
AI 执行约束： 若结论是"混合"，必须明确写出哪部分做成 AI 功能、哪部分做成规则功能、两部分的交接点在哪。不能只说"混合"了事。
6. 常见误判
误判 1：觉得产品加了 AI 功能就高级
真相： 用户不关心你的产品用了什么技术，只关心能不能解决问题。规则功能能解决就用规则功能。
误判 2：觉得 AI 功能一定会取代规则功能
真相： AI 功能和规则功能是互补的。规则功能做确定性的事，AI 功能做模糊性的事。
误判 3：觉得小功能不值得判断
真相： 一个小功能判断错，每次调用都浪费钱，用户量大了累积起来很贵。
误判 4：把"开发用 AI"等同于"产品要加 AI 功能"
真相： 你用 AI Agent 开发产品（开发 AI），不代表产品本身要内置 AI 功能（产品 AI）。记账小程序用 AI 写代码，但记账功能本身可能全是规则。
7. 输出：产品 AI 能力决策卡
## 产品 AI 能力决策卡
### 功能
[要判断的产品功能]
### 4 个问题答案
Q1 规则能做：是/否
Q2 容忍 <100%：是/否
Q3 错误可发现：是/否
Q4 价值 > 成本：是/否
### 结论
[加 AI 功能 / 用规则功能 / 混合 / 不加]
### 如果加 AI 功能，主要风险
- 风险1：[描述] → 应对：[方案]
- 风险2：[描述] → 应对：[方案]
### 如果混合，分工
- AI 功能负责：[任务]
- 规则功能负责：[任务]
- 交接点：[在哪交接]
AI 执行约束： 决策卡中每个"是/否"必须附一句依据（场景里的什么事实支持这个判断）。结论必须和决策链结果一致，不能出现"Q2 答 100% 准确但结论是加 AI 功能"这种矛盾。
验收清单
"产品某功能要不要加 AI"的结论是否可靠：
AI 执行约束： 任意一项不满足，必须明确标注"该项证据不足"，不能补全脑补。
示例：小象取色 两个功能的 AI 决策对比
场景： 小象取色要做"AI 中式命名"和"AI 配色方案生成"两个候选 AI 功能，分别判断要不要加。
功能 A：取色后 AI 中式命名
| 问题 | 答案 | 依据 |
|---|
| Q1 规则能做？ | 否 | 输入是 Hex，但"中式色名"是开放集合无法枚举，且需结合文化语义 |
| Q2 容忍 <100%？ | 是 | 用户能一眼看出命名贴不贴，错了改一下就行，不涉及财务/合规 |
| Q3 错误可发现？ | 是 | 用户看到"故宫红"会对照实物判断，错了能立刻纠正 |
| Q4 价值 > 成本？ | 是 | 单次调用约几厘钱，用户为"高级配色/海报"付费，价值远超成本 |
结论：加 AI 功能。
主要风险与应对：
- 风险1：AI 编造不存在的色名（幻觉）→ 应对：内置中式色名知识库做后校验，库外命名降级为"近义通用名 + 待确认标注"
- 风险2：同一色每次命名不一致 → 应对：对相近 Hex 做分桶，桶内命名固定
- 风险3：调用成本随用户增长失控 → 应对：免费用户命中缓存，付费用户才实时调 AI
功能 B：AI 配色方案生成
| 问题 | 答案 | 依据 |
|---|
| Q1 规则能做？ | 否 | 整套配色需审美和创意，规则枚举不出好方案 |
| Q2 容忍 <100%？ | 是 | 配色是审美判断，用户能挑能改 |
| Q3 错误可发现？ | 是 | 用户看配色丑不丑一眼判断 |
| Q4 价值 > 成本？ | 否 | 生成整套配色需多轮调用、token 多，单次成本约几角；但调研显示大多数用户只要色名就够，愿为"整套配色"付费的少，价值盖不过成本 |
结论：暂不加 AI 功能（先验证需求）。
替代方案：
- MVP 阶段用"色名库 + 经典配色模板（规则功能）"覆盖 80% 场景
- 等手工 MVP 验证到 ≥3/10 人愿意为 AI 配色付费后，再回来重走 Q4
混合决策小结
同一个产品里，AI 中式命名值得加，AI 配色方案生成暂不值得——这就是混合决策。不要因为"一个功能值得加 AI"就给所有功能都上 AI，也不要因为"一个功能不值得"就否定整个产品的 AI 价值。
使用方式
把你的产品功能和候选 AI 能力告诉我，我用这 4 个问题帮你逐个判断。你只需用自然语言描述功能场景，我走完决策链给出结论和风险。
对话示例：
- "我想做个取色工具，要不要加 AI 命名功能" → 我走 4 问决策链，给你产品 AI 能力决策卡
- "我的记账小程序要不要加 AI 功能" → 我先帮你逐个功能走 Q1，大概率大部分功能规则就够
- "我已经决定某个功能加 AI 了，但怕成本失控" → 我帮你识别主要风险和应对
- "我不确定这个功能要不要做成 AI，可能规则就行" → 我们一起填决策卡，重点看 Q1 和 Q4
与其他技能的关系
- 前置： 产品想法已经过
xx-clarify 需求澄清、xx-goal 定目标后 → 用本技能判断"产品功能要不要加 AI"
- 后续： 结论是加 AI 功能 →
xx-business 理商业模式（AI 功能成本要进成本结构），再进 02-build/ 层
- 并行： 决策卡里的"风险与应对"是
xx-track 上线后 AI 质量监控的输入
- 回溯： 上线后若发现成本/质量不达标，回这里重新走决策链，看是不是该改成混合或用规则功能
附录：产品 AI vs 开发 AI 的区别
| 开发 AI（开发工具） | 产品 AI（产品功能） |
|---|
| 是什么 | 你用 AI Agent 帮你写代码、调试、生成方案 | 你的产品内置 AI 能力，终端用户直接用 |
| 谁用 | 你（开发者） | 你的产品用户 |
| 本 skill 管不管 | 不管，始终是 AI Agent | 管，本 skill 只判断这个 |
判断标准： 区分这两个 AI，看"谁在用 AI"——是你开发时用，还是你的产品用户用。前者不讨论，后者才是本 skill 的判断对象。
AI 执行约束： 如果用户问的是"我开发这个产品要不要用 AI Agent"，明确回答"开发工具始终是 AI Agent，这不是本 skill 的范围"，然后把问题转译为"你的产品某个功能要不要做成 AI 功能"再走决策链。
举例：
- 记账小程序：开发时你用 AI Agent 写代码（开发 AI，必然），但产品功能（记账、分类、报表）大多用规则就行，不一定需要内置 AI 功能
- 取色工具：核心取色是规则功能，但"中式色名命名"可以做成 AI 功能（开放集合、文化语义），值得加
方法论来源
- AI 适用性决策链 — 实践总结：结构化、准确率、可发现性、单位经济四问（本技能从"开发工具视角"调整为"产品功能视角"）
- 混合模式 — 规则功能保底线、AI 功能处理长尾的产品架构经验
