---
name: ai-pm-knowledge-notes
description: >-
  用固定四步，帮产品同学解释和整理 AI 概念：①概念本身如何被定义 ②产品经理如何理解一项技术
  ③工作里怎么用 ④怎么跟人讲清楚。在用户 @ 本 skill，并说「解释」「是什么」
  「整理笔记」「面试怎么讲」某个 AI/算法名词时使用。不要用于：写完整需求文档、
  推训练公式、只给一句百科定义。
---

# AI 产品概念笔记

> 装进 Cursor / Claude Code，或整份贴进对话。出自 nclcat.com，改到顺手为止。

给非研发、非科班的产品同学用。听到一个新 AI 词，按四步拆开。  
四步不是四个标题，而是四套 **理解规则 + 表达规则**：模型必须按规则写，不能自由发挥成百科或鸡汤。

## 总原则

1. **① 是公共知识**：别人也能核对的定义。谈「原理怎么实现、解决什么」。
2. **② 是产品内化**：你作为产品经理看见这项技术时，怎么把它接到自己的判断里。谈「对我意味着什么、因此我会怎么判」。
3. **③ 是落地**：场景接不接得住、怎么验收。
4. **④ 是压缩表达**：能短短讲出口。
5. 全程中文、人话。术语首次出现用人话带一下。禁止空话（「结合业务」「赋能」「对齐认知」）。

## 什么时候用 / 不用

- **用**：会上冒出新词、面试要讲清楚、自学要把概念记成能用的笔记。
- **不用**：写完整需求文档、推训练公式、只要一句百科、只要写代码。

## 两档

| 用户说法 | 模式 | 产出 |
|:---|:---|:---|
| 「解释下」「是什么」「帮我对齐」 | **短解释** | 对话里回四步；④ 只要短讲提纲 |
| 「整理笔记」「存成文件」「面试完整版」 | **完整笔记** | 按模板写文件；④ 含短讲 + 6 个自问 |

拿不准先走短解释。

---

## ① 概念本身是什么（知识如何被定义）

### 理解规则

这一步回答：**这项技术在知识上怎么被定义。**  
听众可以是任何人；内容必须能和教材 / 论文 / 官方文档对得上。

强制想清楚三件事（缺一不可）：

1. **它要解决什么问题**（没有它时，痛点是什么）
2. **用什么技术原理 / 机制去实现**（原理层，不写代码；说清「靠什么办法做到的」）
3. **实际解决了什么、没解决什么**（能力边界）

再补一句：**和最容易搞混的近邻差在哪**（点名对比）。

### 表达规则

必须按下面小标题写（短解释可各 1–2 句）：

- **要解决的问题：** …
- **技术原理：** …（句式像：「靠 A 做 B，从而得到 C」）
- **解决了什么 / 没解决什么：** …
- **和易混概念的差别：** …

禁止：岗位话术、未核实的「最强」、只堆名词不讲机制。

---

## ② 产品怎么理解（产品经理如何理解一项技术）

### 理解规则

这一步回答：**如果我是产品经理，看见这项技术，我该怎么理解它。**  
不是把 ① 说浅一点，而是完成一次 **技术 → 产品判断** 的翻译。

产品理解一项技术，固定走四层（认知顺序不能乱）：

1. **能力**：它让产品多了一种什么本事？（用户侧能多完成什么事）
2. **代价与前提**：要用上它，必须先有什么条件？会贵在哪、脆在哪？缺了什么会失效？
3. **决策含义**：因此，哪些产品判断会变——上不上、范围多大、优先级、什么叫做成？
4. **对齐问题**：我还缺哪些事实，必须问算法 / 工程才能拍板？

自检：删掉 ② 只留 ①，产品是否仍不知道「自己该怎么判」——若仍不知道，② 写废了。

### 表达规则

必须按下面小标题写：

- **能力（对我意味着）：** …（对人话，禁止复读 ① 的原理句）
- **代价与前提：** …
- **因此我会怎么判：** …（至少含「会多做一件事」或「会少做一件事」）
- **开会三句原话：**  
  1. …（必须是问句，问得出具体答案）  
  2. …  
  3. …

禁止：「需要和工程对齐」「要结合场景看」这类正确的废话。  
禁止：把 ① 的「技术原理」换词重写一遍当「能力」。

---

## ③ 工作里怎么用

### 理解规则

只谈 **放进真实工作后接不接得住**：哪类场景匹配、哪类别碰、怎么知道试过了。

### 表达规则

- **更合适：** …（具体场景，禁止「赋能业务」）
- **别用：** …（必填）
- **上线前看什么：** …（可观察的对 / 错信号）

② 写「怎么判」；③ 写「落到哪、怎么验」。别抢活。

---

## ④ 怎么跟人讲清楚

### 理解规则

把 ①②③ **压缩** 成别人 90 秒内听得懂的结构。目的是协作对齐或面试，不是再教一遍课。

### 表达规则

- **一句话主张：** …
- **三个要点：** 每个 = 一个判断 + 一个能核对的例子
- **对方追问往哪引：** …

完整模式再加 **自问 6 条**（谁 / 多少 / 何时 / 失败怎么办 / 和谁分工 / 怎么算过关），每条半行提示。

禁止写成小作文；禁止再讲一遍原理。

---

## 完整笔记模板（仅完整模式）

文件名用知识点本名。路径听用户的；没指定先问。

```markdown
# {知识点}

### ① 概念本身是什么
- 要解决的问题：
- 技术原理：
- 解决了什么 / 没解决什么：
- 和易混概念的差别：

### ② 产品怎么理解
- 能力（对我意味着）：
- 代价与前提：
- 因此我会怎么判：
- 开会三句原话：
  1.
  2.
  3.

### ③ 工作里怎么用
- 更合适：
- 别用：
- 上线前看什么：

### ④ 怎么跟人讲清楚
- 一句话主张：
- 三个要点：
- 对方追问往哪引：
- 自问 6 条：
```

---

## 短解释范例（合格输出）

用户：`@ai-pm-knowledge-notes 帮我解释下 Graph RAG`

```text
① 概念本身是什么
- 要解决的问题：普通「先检索再生成」主要靠文句像不像；用户问「A 隔着 B 影响到谁」这种绕弯关系时，容易找不齐、答不稳。
- 技术原理：先从文档里抽出实体和关系，建成图（有的还会做社区摘要），检索时顺着关系边走，再把找到的材料交给模型生成。
- 解决了什么 / 没解决什么：多跳关系、全局「这库在讲什么」更稳；不自动让所有问答变好，建图和更新本身很重。
- 和易混概念的差别：普通检索增强靠「相似」；Graph RAG 靠「关系连不连得上」。

② 产品怎么理解
- 能力（对我意味着）：产品可以支持「顺着关系追几层」的提问，而不只是「找一段像的文字」。
- 代价与前提：要先有较稳的关系类型和抽法；图要有人维护；延迟和费用通常高于普通检索。
- 因此我会怎么判：只有确认需求里大量是绕弯关系题，才把「建图」排进范围；常见问答默认不上图。少做一件事：别把 Graph RAG 当检索标配。
- 开会三句原话：
  1. 我们要支持的问题里，有多少必须顺着关系追两层以上？
  2. 关系抽错了，谁改、多久能改完？
  3. 答案能不能点回「哪条关系」，而不只是某段相似文字？

③ 工作里怎么用
- 更合适：供应链/组织关系问答、合规追来源、工单里「谁和谁有关」。
- 别用：常见问答、单篇摘要、特别赶的短问短答。
- 上线前看什么：绕弯题人工抽查对不对、关系准不准、慢不慢、图空了怎么办。

④ 怎么跟人讲清楚
- 一句话主张：先把关系建起来再检索，不是替换普通检索增强。
- 三个要点：绕弯用图；贵在建图维护；先看问题是不是关系题再决定上不上。
- 对方追问往哪引：「什么时候别用」或「怎么验收」。
```

## 反例（出现就重写）

- ① 只有名词堆砌，没有「问题 → 原理 → 解决了什么」。
- ② 的「能力」只是把 ① 原理缩写了一遍。
- ② 没有「因此我会怎么判」，或只有「要结合业务看」。
- ② 的开会句不是问句，或问不出具体答案。
- 「解释下」却输出很长完整笔记——档位错了。