# kimi-tide 定位与维护策略

> 一份诚实的自我定位声明：这个项目是什么、不是什么、哪些部分会被时间淘汰、哪些部分值得长期投入。
> **适用范围**：本声明基于 kimi-tide v0.1.3（已发布）与 DSH 0.1.0-rc.7（本机实机验证）；0.2.x 路由器/面板与 0.3.0 能力评分路由均已在 main 分支落地（未发布；路由器失效已于 2026-08-18 commit 71b1d18 修复；带图会话锁存 fcbf421 存在已知死锁限制，见 §5），定位研判按此更新。**0.4.x「API key 直连」已实施（v0.4.0 已发布）——自研 OAuth 接入层退役，kimi-tide 收敛为「纯分工层 + 方法层」（见 §3/§5）。****0.5.0 规则驱动路由已发布（2026-08-21，tag `v0.5.0`）：评分引擎退役，分工层收敛为「命名预设 + 有序规则」的预设层（见 §3.1）。****0.6.0 协作编排已发布（2026-08-23，tag `v0.6.0`）：预设层之上新增「协作流」维度——规则目标可指向预置流（图像转述/评审），分工层从「模型路由」升维为「模型+流程编排」（见 §3.2）。**
> **2026-08-31 更新**：v1.0.0 大版本已发布（关键词匹配 + 规则体系/effort + 品牌主题化 + 多 plan 配额）；本文 §3 层次框架与 §5 退役计划继续有效；竞争地图 v2 待 0.8.5-T5。
> 写于 2026-08，背景是项目发布后的第一次战略审视（对照 Open Design 等生态项目）。

---

## 1. 一句话定位

> 白话版：月汐给 DSH 装上「每一步自动选对模型」的能力——装的、选的、为什么选，全是你说了算，全看得见。

**kimi-tide 是 DSH 生态的模型接入与互补分工层，不是应用。**

- Open Design 是**应用**（回答"怎么用 AI 做设计"），kimi-tide 是**基础设施**（回答"怎么在 DSH 里用 Kimi、怎么让两个模型分工"）
- 两者不竞争，**可共存/互补**：Open Design 把 DSH 当运行后端，而 kimi-tide 让 DSH 里多一个 Kimi 模型可选（该推演基于公开架构，未实机验证；Open Design 未来也可能经官方 ACP 直接调用 Kimi，绕过模型接入层）
- 与 `dsh-kimi-bridge` 的分工（**历史——2026-08-23 归档退役**）：bridge 曾把 Kimi CLI 当**外部进程**调（独立 agent 会话），kimi-tide 把 Kimi 作为**功能上在 DSH 模型选择器中可用的 provider**（与 DeepSeek 平级可切换；0.4.x 起经官方 pi-ai 原生 `kimi-coding` 路由 + Console API Key，非自研 token workaround）。bridge 的「独立 Kimi 会话/审查」角色已由 @kimi 子代理经 kimi-tide 路由承接，vendored fork 已移出仓库（git 历史保留）

## 2. 与 Open Design 的区别（对照表）

| 维度 | Open Design | kimi-tide |
|------|-------------|-----------|
| 层次 | 应用层（垂直：设计/原型/PPT/视频） | 分工层（路由/护栏/观测，接入层已退役） |
| 用户 | 做设计工作流的人 | 在 DSH 里做任何事的人 |
| Kimi 的角色 | 26 个可选引擎之一，外部子进程（`kimi acp`） | 功能上作为 DSH 可选 provider |
| DSH 的角色 | 运行后端（经自定义 stdio 帧协议驱动） | 宿主平台 |
| 合规性 | ✅ 官方 ACP 协议 | ✅ 官方 API Key 路径（0.4.x 起） |
| 核心问题 | 设计产物生成 | 模型接入 + 互补分工 |

## 3. 项目价值的三层拆解（按"官方替代性"排序）

| 层 | 内容 | 官方会替代吗 | 策略 |
|----|------|-------------|------|
| **接入层**（0.1.x token 方案） | pi-ai 适配 + OAuth token 轮换 | **会**——当 DSH 原生提供 Kimi 官方 provider（含适配器与合法鉴权）时即退役 | **已退役（0.4.x）**：pi-ai 原生 `kimi-coding` 路由 + API key 接管，自研接入层整体删除 |
| **分工层**（0.2.x 路由器已接线 → 0.3.0 能力评分 → 0.5.0 规则驱动 → 0.6.0 协作编排，v0.6.0 已发布 2026-08-23） | 预设/规则路由、能力缺口补偿；0.5.0 起为命名预设（省钱/能力/可自建）+ 有序规则（带图/关键词组）+ 全量候选池枚举；0.6.0 起规则目标泛化为「模型 | 协作流」（预置图像转述流/评审流） | **短期内被替代的概率低**，但非绝对——官方/社区可能推出通用路由选择器；需持续跟踪机制演进 | **长期投入**：项目当前的核心价值 |
| **方法层**（协作闭环文档） | 审查-修复-复检流程、踩坑档案、模板 | 不会，且与项目存亡无关 | **持续沉淀**：独立价值；方法论的独立研究见 [kimi-tide-research](https://github.com/tafcear/kimi-tide-research)（tafcear × Kimi，架构/损耗/可行性） |

**一句话策略**：别在租来的时间上盖楼，把砖都铺到自己的地上。

### 3.1 0.5.0 差异化定位：预设层，而非「又一个关键词路由器」

关键词/规则路由在 DSH 社区已是红海——`superboy911/dsh-model-router` 已实现「默认模型 + 有序关键词规则、first-match、未命中不动」，同类还有 dsh-auto-gearbox、dsh-omni-router 等。0.5.0 的规则核心（有序规则 + 关键词组 + first-match）与它们逐条重合是**有意为之的收敛**（规则是用户能读懂的形态），差异化在规则之外的**预设层**：

- **命名预设**：内置「省钱」「能力」双预设（默认模型 + 各自规则集），一键全局切换——同一套规则引擎服务两种相反的使用策略；
- **用户自建命名预设**：新建/复制/删除，预设即数据，与内置同构；
- **打底语义**：未命中规则 ≠ 不动，而是路由到预设默认模型（社区路由器多为「未命中不动」）；
- **全量候选池**：provider 无关的全量目录枚举（无白名单），未接入目标自动降级跳过 + UI 标灰。

此组合（预设层 × 规则集 × 全局切换 × 全量池）在社区无先例。边界声明：我们不做「又一个关键词规则表」；规则匹配逻辑保持刻意简单（子串、大小写不敏感），复杂性全部上移到预设管理与可观测层。

### 3.2 0.6.0 升维：协作流（编排层），而非「又一个路由器」

0.6.0 把规则目标从「模型」泛化为「模型 | 协作流」——预设层之上新增一层可编程协作：

- **预置流注册但不绑定**：`transcribe`（vision-exp 读图转文字，eager/lazy 双时态）与 `review`（一模型产出、另一模型评审，P2 触发）随版本内置，用户把 image 规则改挂流即启用；
- **按图三态 + imageFallback**：布尔锁存退役，每张图独立跟踪 native/transcribed/blind，预设级兜底三态（锁存/盲答/懒转述）用户可选；
- **智能投影**：`llm/stream` 拦截器把已转述图块替换为转述文字——文本模型凭文字接力看图，这是「图片不进主历史」根解的落地形态（T4 门实测通过）。

边界声明：这是**双模型协作的通用编排器雏形**，不是 N 模型流水线（不立项）；review 流默认 manual、rounds 上限、评审消息不触发评审——防额度失控是编排层的硬约束。

## 4. 诚实清单（项目的边界与灰区）

- ⚠️ ~~token 方案是条款灰色地带~~（0.1.x 历史项，0.4.x 退役）：现默认走 Console API Key 官方路径，个人使用安心
- ⚠️ **兼容 DSH ^0.1.0-rc.6**（本机 rc.7 实机验证通过）：事件/适配器契约在 rc 快速迭代中可能变更，升级 DSH 可能导致插件失效
- ⚠️ ~~依赖 Kimi CLI 的内部协议~~（0.1.x 历史项，0.4.x 退役）：接入层改走 pi-ai 原生 `kimi-coding` 路由 + Console API Key，不再依赖 Kimi CLI 登录态
- ⚠️ 高频调用可能触发官方限流或条款 enforcement（Console Key 仍请勿高频批量调用/共享密钥）
- ⚠️ **单人维护，无 SLA**：问题响应取决于维护者的可用时间
- ✅ 代码与构建流程可复现；**运行时**需要用户自有 Console API Key 与 DSH 环境（0.4.x 起不再需要 Kimi Code 订阅/OAuth 登录态）
- ✅ 不依赖任何闭源组件、凭据零入库

## 5. 维护策略与退役计划

| 事件 | 行动 |
|------|------|
| 日常 | 接入层已退役，投入分工层、沉淀方法层 |
| **DSH 原生提供 Kimi 官方 provider（含适配器与合法鉴权）** | ✅ **已发生（0.4.x）**：pi-ai 原生 `kimi-coding` 路由 + API key 接管，token 接入层退役（README 标注 legacy），分工层保留 |
| DSH 子代理后端注册表开放 opt-in 挂载（实际扩展点 = subagents 命名注册表 + host plane 挂载，先例 codex/claude-code 后端） | **不退役接入层**——子代理后端是"DSH 调用外部 agent"的机制，与原生模型接入不同；路由器可将其列为**分工层扩展路径**（任务路由给独立 Kimi agent；并可实现「子代理图片外包」——子代理读图回传文字、图片不进主历史，同时解决带图会话成本与锁存死锁） |
| DeepSeek V4 后续版本支持多模态 | 路由器的"图片补偿"改为能力检测（前提：DSH 模型元数据暴露 `inputModalities` 且适配器同步支持；否则保留硬编码补偿） |
| Kimi 侧多模态（当前可用能力） | **图片补偿已是现实能力而非纯未来项**——`kimi-for-coding` 图片识别脚本实测通过、`k3` 等目录声明 `text+image`；图片类任务可直接走 Kimi 补偿（0.2.x 图像护栏已接线，方向已于 71b1d18 修正：带图步骤从文本-only primary 改道多模态 premium）。**⚠️ 2026-08-19 实测**：带图会话锁存（fcbf421）在 k3 额度/Key 失效时致整会话死锁——锁存非终态方案，根解=图像转述模式 / 子代理图片外包（0.3.x 规划） |

## 6. 项目的时间观

kimi-tide 是一个**过渡期方案**：它在官方能力到位的窗口里提供真实价值——就本项目所知，它是当前已发布且可用的 DSH 原生 provider 路径之一——并在窗口关闭时把可迁移的资产（路由器、方法论）带走。明确这一点，比任何承诺都更能指导日常取舍：什么值得维护、什么准备退役、什么留给官方。