メニュー
定义一个 AI 功能的用户任务、输入、输出、质量标准和 fallback。适用于把模糊 AI 点子整理成可讨论方案的场景。
用结构化输入定义或调整定价与套餐结构，明确目标客户、价值指标、免费层边界、套餐层级、升级触发点与风险取舍。适用于定价新建、改版、AI 增值包或商业化实验前的推演。
在正式交付前用结构化关口审查方案、文档或分析结果。适用于避免局部正确但整体跑偏、避免草率交付的场景。
把一个较大的 PM、AI PM 或商业化任务拆成可快速验证的执行步骤。适用于任务过大、容易失控、需要先把执行顺序和检查点想清楚的场景。
把一个 AI 产品想法整理成问题定义、功能定义、评估方案和风险评审。适用于 roadmap 前的产品定义场景。
诊断转化漏斗的阶段、掉点、可能原因和下一步核查方向。适用于获客、激活或付费转化出问题的场景。
为 AI 功能定义离线与线上评估方案，包括样本、指标和阻断阈值。适用于上线前需要明确质量标准的场景。
| name | ai-feature-brief |
| description | 定义一个 AI 功能的用户任务、输入、输出、质量标准和 fallback。适用于把模糊 AI 点子整理成可讨论方案的场景。 |
| type | component |
| best_for | ["定义 AI 功能","在写完整 PRD 前先把 AI 能力说清楚","减少模糊的 AI 想法"] |
| scenarios | ["定义一个 AI 访谈总结功能","把 AI copilot 点子整理成产品 brief"] |
在团队真正投入开发前，先把 AI 功能定义清楚。
一个 AI feature brief 至少要说明：
AI feature brief 不是在描述“模型能做什么”，而是在判断“这件事值不值得以 AI 方式交付”。
在成文前先检查：
优先区分：
模型会不会做用户会不会用产品应不应该把它做成一个正式功能如果一个想法只能证明“模型能演示”，不能说明：
则不要把它写成正式 feature。
在把一个 AI 点子写成 brief 前，先问：
## AI Feature Brief
### User Job
[用户任务]
### Trigger
[触发点]
### Inputs
- [输入]
### Outputs
- [输出]
### Quality Bar
- [什么算好]
### Failure Modes
- [最重要的失败方式]
### Fallback Behavior
- [低置信度时怎么办]
### Why This Should Exist As A Product Feature
- [为什么值得做成正式功能，而不是 demo / prompt / 内部工具]
好：
差：
template.md../llm-evaluation-plan/SKILL.md../ai-risk-review/SKILL.md