# KDNA 中文编写指南

中文 KDNA 的编写有其独特的考量——不是简单地把英文翻译过来。

## 为什么中文 KDNA 需要独立编写

直接翻译英文 KDNA 会丢失很多信息：

1. **公理的表达方式不同**。英文公理倾向直接断言。中文公理可能需要更迂回的论证结构。
2. **触发信号必须反映中文真实语境**。"你说的对但是…"和"这不对吧…"在中文里意味着不同的沟通状态，这些细微差异无法从英文翻译获得。
3. **禁用词必须是中文语境中的真实问题**。"赋能""抓手""对齐"——这些是中文商业语境中的高频模糊词，英文没有对应物。

## 中文公理编写原则

- 使用中文的自然逻辑结构，不要硬套英文句式
- 公理应该读起来像一个中国专家在说话，而不是翻译腔
- "一句话公理"应该是中文读者一次性就能记住的表达

## 中文触发信号

中文的语境信号往往比英文更依赖上下文：

- 英文："I'm not sure but..."
- 中文："这个我不太确定，不过你可以参考一下……"
- 英文："That's a great question!"
- 中文："这个问题问得好！"（可能意味着在回避问题）

好的中文 KDNA 需要捕捉中文中特有的交流模式。

## 中文禁用词示例

| 禁用词 | 为什么误导 | 替代 |
|--------|-----------|------|
| 赋能 | 空洞的正面词，掩盖了具体做什么 | "提供工具和授权" |
| 抓手 | 模糊，无法指导行动 | "关键切入点" |
| 对齐 | 可以用来压制不同意见 | "确认我们理解一致" |
| 体感 | 不精确，阻碍量化分析 | "实际体验"或"用户反馈数据" |
| 底层逻辑 | 听起来深刻但通常什么都没说 | 直接解释因果关系 |

## 中文自检问题

中文 KDNA 的自检应该反映中文 Agent 可能犯的错误：

- "我是否被用户的委婉表达误导，而没有抓住真实意图？"
- "回答中是否使用了中文商业语境中的空泛词汇？"
- "我的判断是否基于'听起来有道理'，而不是基于领域公理？"

## 中文 KDNA 的领域命名

建议使用英文 slug（保持技术兼容性），但 `name` 和 `description` 字段使用中文。

```json
{
  "name": "中文写作判断",
  "domain": "writing_zh",
  "description": "中文写作领域的判断结构——关注中文特有的表达问题，如翻译腔、委婉过度、空话连篇等。"
}
```
