# 信息架构设计原则

## 为什么这样设计

AI 的上下文窗口有限（~200K tokens）。当前架构按人类认知模式设计——详尽文档、全局视角——但 AI 每个读入上下文的字都是成本。这套分层架构的核心思想：**每个角色只加载必要信息，按需展开细节。**

## Token 预算

| 层级 | 预算 | 内容 | 加载时机 |
|------|------|------|----------|
| 角色工作台 (card + today) | < 2K | 身份+今日任务 | 每次会话必读 |
| 阶段上下文 (phase) | < 5K | 目标+范围+架构 | 按需加载 |
| 专题文档 (knowledge) | < 3K | 决策/模式/教训 | 按需加载 |
| 路线图 (ROADMAP) | < 2K | 全局进度 | 需要全局视野时 |

## 信息分层

```
Layer 0: 角色工作台  → AI 每天进来只读这个
Layer 1: 路线图看板  → 人类 + AI 共享进度
Layer 2: 阶段上下文  → 按当前阶段按需加载
Layer 3: 知识沉淀    → 自动积累，永久沉淀
```

## 维护规则

1. **不超预算**：每个文件严格遵守 token 预算，超了就拆分
2. **不重复状态**：状态只在一处记录（dashboard.md），其他地方引用
3. **Git 管历史**：文档只描述"现在是什么"，历史由 Git 负责
4. **一文一答**：每个文件独立回答一个问题，不需要串联阅读
5. **角色无关设计**：任何 AI 模型都能通过读 card.md 快速接管角色

## Arch AI 上下文资源管理（硬约束）

**问题**：Arch AI 每次会话有上下文窗口限制。如果盲目冲刺大任务，到一半触发自动压缩，前面的讨论、决策细节、已排除的选项全部丢失——代价不是「重来」，是「用不完整的记忆做决策」。

**规则**：

1. **任务前评估**：开始一个复杂任务前，先判断能否在自己的有效上下文内完成。如果不能，拆分到多个独立会话
2. **做完一件再开始下一件**：不积累未完成的工作。一个阶段收尾了（commit + push），再启动下一个
3. **决策即记录**：每个重要判断产生后，立即写入对应的 knowledge/ 文件，不要留在对话里。对话是易失的，knowledge 是持久的
4. **接近窗口上限时主动收尾**：感觉上下文开始吃力时，主动做 checkpoint——把已完成的写入文件、commit、告知人类当前进展和下一步。**宁可多开一个会话，不要带着残缺记忆继续**
5. **拆分策略**：大任务（如「重构整个架构」）拆成独立可提交的子任务。每个子任务结束后 git commit，确保即使后续会话压缩，已完成的部分不会丢失

**信号识别**：当出现以下情况时，说明接近上下文上限，应立即执行规则 4：
- 需要反复回看前面的讨论才能做判断
- 开始忘记用户几分钟前说过的话
- Token 用量接近已知窗口限制
- 回复质量出现可感知的下降

**反模式**：「一口气做完再 commit」——做一半触发压缩，前面做的全丢。

## 文件约定

- 角色工作台: `.ai/roles/{role}/`
- 阶段上下文: `.ai/phases/phase-NN-name/`
- 知识沉淀: `.ai/knowledge/`
- 提示词模板: `.ai/prompts/{domain}/`

## 阶段切换检查清单

切换阶段时 Arch AI 必须：
- [ ] 更新所有角色的 card.md（当前阶段字段）
- [ ] 更新 ROADMAP.md（阶段进度条）
- [ ] 生成上一阶段的 completion.md
- [ ] 产出阶段复盘（docs/share/phase-NN/）
- [ ] 审计 token 预算