# 中文 KDNA 编写指南

## KDNA 是什么（人话版）

> **KDNA 不是让 AI 背更多资料。是把专家判断问题的方式，变成 AI 可以加载的结构。**

你给 AI 扔一个 PDF，它只是"知道了"。你给 AI 写一段 Prompt，它只是"会说了"。但当你需要 AI 像一个有十年经验的销售、一个有判断力的管理者、一个懂老人心理的服务者那样思考问题时——你需要的不再是知识或指令，而是**判断结构**。

KDNA 做的就是这个：把专家判断问题的**公理（相信什么）、边界（区分什么）、误区（避免什么）、自查清单（检查什么）**做成一个可以验证、可以版本化、可以组合的结构化文件。

### 用一句话说给不同的人听

| 对象 | 怎么说 |
|------|--------|
| 开发者 | "一个 JSON Schema，定义了 Agent 在某个领域怎么思考，而不是说什么。" |
| 产品经理 | "一套能跨 Agent 复用的判断力文件。换了底层模型，判断力还在。" |
| 创始人 | "让你的 AI 产品不再因为缺少领域判断而犯低级错误。" |
| 公众号读者 | "Prompt 管输出。Skill 管执行。KDNA 管思考。" |
| 小红书/即刻 | "你给 AI 写了一堆要求它还是不懂客户。因为你没给判断结构。" |

### 传播句式

这几句话可以直接用于公众号、即刻、掘金、小红书：

- "AI 能做事了，但还会犯傻——因为能行动不等于能判断。"
- "同一个问题'太贵了'，普通 AI 说'给折扣'，加载了销售 KDNA 的 AI 说'先诊断是哪种不确定'。"
- "KDNA 不是 Optimize wording，是 Change reasoning trajectory。"
- "工具让 AI 能行动。KDNA 让 AI 不乱行动。"

## 1. 从窄领域开始

不要试图一次性编码整个职业。

错误：`产品管理`
正确：`产品方案评审`、`需求优先级排序`、`上线决策`

## 2. 写出领域句

模板：

```text
这个领域帮助 AI Agent 判断 ______，以便 ______。
```

示例（产品决策）：

```text
这个领域帮助 AI Agent 判断产品方案是否应该推进，
以便在有限信息下做出可逆、可验证的产品决策。
```

## 3. 提取公理

中文语境下的好公理往往是对"中国式做法"的纠正性假设。好的公理不是口号，它应该改变 Agent 的响应方式。

示例（产品决策）：

- **问题先行，方案后置** —— 没有先定义用户问题就开始讨论方案的产品决策，失败率极高。
- **决策速度 > 决策完美度** —— 两周后做出的完美决策，不如今天做出的大致正确决策。
- **用户价值 > 老板意见** —— 用"老板说要做"替代用户价值论证，是最常见的决策陷阱。

## 4. 定义概念边界

中文产品术语常常被滥用而失去精确含义。每个重要概念都需要一个明确的边界。

示例：

| 概念 | 是什么 | 不是什么 |
|------|--------|----------|
| MVP | 验证核心假设的最小功能集 | 不是砍掉非核心功能的第一版 |
| 数据驱动 | 用数据辅助判断，承担决策责任 | 不是等数据替你做决定 |
| 快速试错 | 低成本验证关键假设 | 不是不思考就动手 |

## 5. 捕获中文特有的误解

中文技术社区有一些独特的认知陷阱，应该在 KDNA 中显式捕获：

**"竞品做了"陷阱**

- 错误理解：竞品做了某个功能，所以我们也该做。
- 正确理解：竞品的用户群、阶段、资源与你不同。竞品动作是信号来源，不是决策依据。
- 关键区分：竞品的"做什么"是信息，"为什么做"才是洞见。大多数团队只看到前者。
- 为什么重要：跟风决策是产品同质化的根源。它绕过了用户价值判断，用"别人做了"替代了"用户需要"。

**"数据说了算"陷阱**

- 错误理解：只要有数据支撑，决策就是正确的。
- 正确理解：数据告诉你过去发生了什么，不告诉你未来应该做什么。决策需要判断力来填充数据与行动之间的鸿沟。
- 关键区分：数据是决策的输入，不是决策本身。数据驱动 ≠ 数据决定。

**"完美方案"陷阱**

- 错误理解：方案必须考虑所有情况才能推进。
- 正确理解：方案只需要解决当前阶段已知的核心问题。过度设计是进度杀手。
- 关键区分：完备性追求的是"不犯错"，可逆性追求的是"犯错后能改"。产品决策需要后者。

## 6. 禁用词要贴合中文语境

中文产品讨论中有一些高频但有害的表述：

| 禁用词 | 为什么 | 替换为 |
|--------|--------|--------|
| "老板说的" | 用权力替代论证，扼杀产品思考 | "用户需要 X，因为 Y 数据表明 Z" |
| "竞品做了" | 跟风思维，绕过用户价值判断 | "竞品可能观察到 X 需求，我们需要验证这个需求是否适用于我们的用户" |
| "我觉得" | 观点伪装成直觉洞察，缺乏可验证性 | "我的假设是 X，可以通过 Y 方式验证" |
| "先做出来再说" | 鼓励无假设的行动，浪费工程资源 | "我们先定义核心假设，用最小成本验证它" |
| "大而全" | 把功能数量当作产品优势 | "聚焦核心场景，在关键路径上做到极致" |

## 7. 自查项要可操作

每个自查项必须能用"是/否"回答，并捕获最常见的判断失误。

好的自查项：

- 这个决策如果错了，我们能在多长时间内发现并修正？
- 我是否区分了我知道的（事实）和我猜测的（假设）？
- 这个方案解决了谁的什么问题？我有没有见过那个用户？

差的自查项：

- 这个产品决策好吗？（太模糊）
- 我考虑周全了吗？（无法用是/否回答）

## 8. 场景信号要可观测

不要用抽象标签描述场景，要用可观测的行为信号。

错误：`当用户对需求不清晰时。`

正确：`当用户说"先做出来看看效果"、跳过用户验证直接讨论技术方案、或用"老板说要这个功能"作为需求来源时。`

## 9. 推理链必须有 so_what

中文里的"所以呢"是推理链的灵魂。没有实践后果的推理只是评论。

格式：

```json
{
  "id": "reasoning_speed_over_perfection",
  "one_sentence": "产品决策的速度比完美度更重要，因为在信息不完整时推迟决策并不会获得更多信息。",
  "logic": [
    "大多数产品决策的信息不会随时间自动增加。",
    "推迟决策的成本是失去市场时机和团队动量。",
    "可逆的决策可以在执行中获得反馈进行修正。"
  ],
  "so_what": "面对信息不完备的产品决策，优先选择可逆的方案快速推进，设定明确的验证节点，而不是等待更多信息。"
}
```

## 10. 行为级验证

对比有 KDNA 和没有 KDNA 的 Agent 响应。如果差别只是用了更多中文术语，KDNA 是无效的。

有效 KDNA 的表现：
- Agent 在收到"老板说要做这个功能"时，会追问用户价值而非直接讨论实现
- Agent 在讨论 MVP 时，会追问"你要验证的核心假设是什么"
- Agent 在收到竞品分析时，会追问"我们的用户和竞品用户的关键差异是什么"
