# the authoring pipeline 原则

the authoring pipeline 是判断生产界面。它帮助人类将隐性专业知识转化为显式、结构化、可测试、可版本化的判断资产。

它不是域生成器。它不是判断的 AI 自动驾驶仪。它是领域作者发现、表达、挑战、锁定和导出其判断的工坊。

---

## 核心原则

### 1. 人类判断是源头

AI 可以访谈。AI 可以挑战。AI 可以编译和测试。但判断本身来源于人类领域专家。

the authoring pipeline 在工作流中明确这一点：
- 作者说出自己的判断。
- AI 提出澄清问题和生成反例。
- 作者精炼、拒绝或确认。
- 只有经过人类判断锁定后，判断才进入正式域。

Studio 不替代人类专业知识。它让专业知识提取变得结构化、高效、可复现。

### 2. Studio 不是生成器

the authoring pipeline 不会"帮你写 KDNA"。它提供：
- 挖掘隐性判断的访谈流程
- 基于卡片的判断要素组织（公理、边界、场景）
- 对每个判断进行反例挑战的压力测试
- 导出前捕获结构错误的验证
- 针对新兴域运行评估的测试实验室
- 导出为带版本号、签名的 `.kdna` 包

成功标准不是"是否导出了 `.kdna` 文件？"而是"用户是否说出、拒绝、修改、补充、复述、测试并持续迭代了自己的判断？"

没有"一键生成域"按钮。

### 3. AI 协助，不做决定

在 Studio 内，AI 扮演四种辅助角色：

| 角色 | AI 做什么 | 人类做什么 |
|------|-----------|------------|
| **访谈者** | 提出问题以挖掘隐性判断 | 回答、澄清和纠正 |
| **挑战者** | 生成反例和边缘案例 | 评估反例是否是有效关切，并精炼判断 |
| **编译者** | 将表达出的判断转化为结构化 KDNA JSON | 审核结构的准确性和完整性 |
| **评估者** | 运行评估套件并报告通过/失败/缺口 | 解读结果并决定质量是否足够导出 |

AI 在任何时刻都不决定判断应该是什么。

### 4. 导出前的人类判断锁定

Studio 在任何判断进入正式域文件前强制执行严格的锁定：

1. 判断表达（访谈或手动输入）
2. AI 辅助挑战（生成反例）
3. 人工审核和精炼
4. 人类判断锁定（作者明确确认）
5. 结构验证
6. 行为验证（测试实验室）
7. 版本升级、签名和导出

这个锁定确保 `.kdna` 文件中的每条公理、边界和价值都经过了人类确认。

### 5. Studio 生产受治理的资产

Studio 的产物不只是文件。它是**受治理的判断资产**：
- 使用作者的 Ed25519 密钥签名
- 用 semver 和 judgment_version 双版本化
- 附带验证其行为的评估案例
- 用 Scope / Out-of-Scope 声明记录
- 准备好发布到 registry 并被 Agent 消费

### 6. Studio 是生产层，不是治理层

the authoring pipeline 处理**判断资产如何被创建**。

**KDNA Governance Console**（一个独立的未来产品）处理**判断更新如何在组织内被批准、发布、回滚和审计**。

| 关注点 | Studio（生产端） | Governance Console（审批端） |
|--------|------------------|------------------------------|
| 创建新域 | 是 | 否 |
| 编辑公理和边界 | 是 | 否 |
| 审核来自 Agent 的改进提案 | 否 | 是 |
| 批准/拒绝提议的变更 | 否 | 是 |
| 审计谁改了什么及原因 | 否 | 是 |
| 管理 registry 晋升管道 | 否 | 是 |
| 回滚已发布的域版本 | 否 | 是 |

Studio 可以*提交*域到 Governance Console。它不*治理*组织审批流程。

---

## Studio 工作流

### 阶段 1：发现

作者识别出一个自己持有但从未明确表达过的判断。

- AI 访谈者问："关于 X，你知道什么新手会弄错？"
- 作者用自然语言回答
- AI 识别候选判断要素（潜在公理、边界、误解）

### 阶段 2：表达

候选判断被转换为结构化卡片。

- 每张卡片有类型：公理、边界、场景、误解等
- 作者直接编辑卡片
- AI 基于跨域模式识别建议精炼

### 阶段 3：挑战

AI 为每张卡片生成反例和压力测试。

- "这个公理什么时候会是错的？"
- "什么情况违反了这个边界但应该被允许？"
- "这个误解没有捕获到什么？"

作者决定：保留、修改或丢弃。

### 阶段 4：人类判断锁定

作者明确锁定每张卡片。

- 锁定记录：谁、何时、确认声明
- 锁定的卡片成为正式域的一部分
- 未锁定的卡片保留在草稿中

### 阶段 5：测试实验室

新兴域针对真实输入进行测试。

- 将域加载到沙盒 Agent
- 运行评估案例
- 对比有/无 KDNA（`kdna compare`）
- 作者基于结果迭代

### 阶段 6：导出

域被验证、签名并导出。

- `kdna dev validate` — 结构检查
- `kdna verify --judgment` — 行为评分
- 应用 Ed25519 签名
- 生成 `.kdna` 包
- 准备好 `kdna publish`

---

## Studio 不是什么

| 误解 | 现实 |
|------|------|
| "写 KDNA 文件的 AI" | Studio 是生产工坊。人类表达判断。AI 只协助。 |
| "提示词工程工具" | Studio 处理结构化判断资产，而非一次性提示词。 |
| "无代码域构建器" | 域创建需要领域专业知识。Studio 结构化该专业知识，不替代它。 |
| "Agent 行为的自动更新器" | 没有自动判断更新。每个判断要素都在导出前经过人类锁定。 |
| "治理仪表盘" | 治理、审计和审批工作流属于 KDNA Governance Console，不属于 Studio。 |
| "Registry 浏览器" | 虽然 Studio 可以导入 registry 域进行混编，但其主要目的是生产，而非发现。 |

---

## Studio 与生态

| 组件 | 角色 | Studio 关系 |
|------|------|-------------|
| **KDNA CLI** | 协议控制平面 — 验证、比较、发布 | Studio 调用 CLI 命令进行测试实验室和导出 |
| **Registry** | 域发现和分发 | Studio 导出准备好发布到 registry 的包 |
| **Agent 运行时** | 加载 KDNA 并生成判断 | Studio 的测试实验室使用沙盒运行时进行验证 |
| **评估套件** | 测试判断质量 | Studio 在测试实验室阶段运行评估 |
| **KDNA Governance Console** | 组织审批、审计、回滚 | 从 Studio 接收域进行治理审核 |
| **a KDNA-compatible client** | 内置 Studio Beta 的面向消费者的 Agent | a KDNA-compatible client Studio Beta 是第一个嵌入式实现 |

---

## 设计后果

这些原则对 Studio 实现有具体影响：

1. **没有"生成域"按钮。** 主要动作是"锁定判断"和"运行测试实验室"，不是"自动生成"。
2. **锁定优先工作流。** 每个判断要素必须在导出前显式锁定。
3. **挑战模式是默认。** Studio 应主动生成反例，而不是等用户要求。
4. **测试实验室集成。** 验证和比较是一等 UI 功能，不是事后想法。
5. **身份绑定。** 每个导出的域都使用作者的身份密钥签名。不允许匿名导出。
6. **以迭代为中心。** UI 应让修订锁定判断、重新运行测试和重新导出变得容易 — 判断是迭代的，不是一次性的。

---

## 总结

the authoring pipeline 的存在是因为人类判断是 Agent 时代的稀缺资源。

Studio 不替代人类判断。它让人类判断变得**可表达、可挑战、可测试、可在 Agent 生态中传递**。

Studio 生产资产。Governance Console 治理其生命周期。CLI 为两者提供动力。三者共同构成人类判断治理的自我改进型 Agent 的完整基础设施。
