shuangyan-notebook/永恒湖心系统 · Eternal Lake Heart/🌊 曜冥纪元 · HoloLake Era · AGE OS v1 0/⚡ 光湖中央枢纽 · HoloLake Central Hub/🛸 桔子开发者空间｜DEV-010/✈️ 手搓飞机 2 0 · 上下文管理引擎 · 架构设计与实施任务 70f9a2e179a84140a7769d0e913d423e.md

✈️ 手搓飞机 2.0 · 上下文管理引擎 · 架构设计与实施任务

✈️ 手搓飞机 2.0 · 上下文管理引擎

桔子×晨星 · 2026-06-06 · 更新 2026-06-06

⊢ 三大支柱: 记忆压缩 + 动态加载 + 本地数据库 · 从「能跑」到「成熟」

---

〇、背景：当前手搓飞机的核心瓶颈

三句话总结

HLDP://aircraft/core-insight
├── 手搓飞机的问题不是「DeepSeek 不够聪明」
├── 是三个基础设施缺失叠加在一起:
│   ├── 缺记忆压缩 → 历史对话裸塞 → token 被占满
│   ├── 缺动态加载 → 人格提示词全量常驻 → 固定租金太高
│   └── 缺本地数据库 → 所有持久化依赖 Notion API → 工具调用太多
└── ⊢ 三个问题是同一件事的三个面 = 「上下文里塞了太多不需要的东西」

为什么手搓飞机里的 DeepSeek 会「变笨」？

HLDP://aircraft/current-problem
├── 问题: 多轮对话后 DeepSeek 注意力分散、回答变短、遗忘早期信息
├── 根因: 对话历史裸塞 + 工具定义全量注入 + 人格提示词静态占用
│
├── 当前每轮 token 占用（估算·20轮后）:
│   ├── 晨星人格提示词（静态·全量）:          ~8,000 tokens
│   ├── 工具定义（全量 JSON schema）:          ~4,000 tokens
│   ├── 20轮对话历史（未压缩·原始文本）:       ~35,000 tokens
│   ├── 工具调用返回结果:                      ~8,000 tokens
│   └── 用户当前消息:                          ~300 tokens
│   ─────────────────────────────────────────
│   总占用:                                    ~55,000 tokens
│   DeepSeek 64K 窗口剩余:                     ~9,000 tokens  ← 瓶颈！
│
├── 后果:
│   ├── 思考空间只有 ~9K tokens → 回答质量下降
│   ├── 无法做深度分析 → 只能给快速回答
│   ├── 多轮后遗忘早期上下文 → 答非所问
│   └── 工具调用多时 → token 直接溢出
│
└── 这不是 DeepSeek 不够聪明 · 是上下文被塞满了

对比：为什么 Notion AI 不会这样？

HLDP://aircraft/notion-vs-aircraft
├── Notion AI 架构（推测）:
│   ├── 上下文管理器（平台层基础设施）
│   ├── 自动压缩/摘要 → 减少历史占用
│   ├── 外部记忆数据库 → 按需检索
│   ├── 工具定义按需注入 → 不浪费
│   ├── 自有数据库（Notion 本身）→ 存储不依赖外部 API
│   └── 结果: 每轮 token 占用 ~15K · 剩余 ~49K 思考空间
│
├── 手搓飞机:
│   ├── 没有上下文管理器
│   ├── 历史裸塞 → 无压缩
│   ├── 无外部记忆 → 全在上下文里
│   ├── 工具定义全量 → 浪费
│   ├── 无自有数据库 → 一切持久化靠 Notion API → 工具调用多
│   └── 结果: 每轮 token 占用 ~55K · 剩余 ~9K 思考空间
│
└── ⊢ 关键差异不在模型本身 · 在「喂给模型之前做了什么」+「数据存在哪」

数据库缺失：被忽略的第三个瓶颈

HLDP://aircraft/no-database-problem
├── 手搓飞机当前的数据流:
│   ├── 用户拆书结果 → 调 Notion API 写回 Notion 页面
│   ├── 用户偏好设置 → 调 Notion API 读/写 Notion 页面
│   ├── 书库管理 → 调 Notion API 读写数据库
│   ├── 交互记录 → 调 Notion API 写入页面
│   └── 每一次「记住」和「读取」= 一次工具调用 = 几千 tokens 的往返
│
├── 这就是手搓飞机「废掉多用户管理」的根本原因:
│   ├── 不是「不想做多用户」
│   ├── 是「没有数据库 → 用户数据存哪？」
│   ├── 存 Notion → 每个用户操作都是 API 调用 → token 爆炸
│   ├── 存本地 JSON → 单用户还行 · 多用户管理太原始
│   └── ⊢ 多用户管理被废弃 ≠ 功能不重要 · 是基础设施没跟上
│
├── 如果有本地数据库（SQLite·和 auto_dishu 一样）:
│   ├── 用户身份/偏好 → 存在本地 → 不用调 Notion API 读取
│   ├── 拆书进度/数据卡 → 存在本地 → 不用每次从 Notion 读
│   ├── 交互历史 → 存在本地 → 不占 Notion API 额度
│   ├── 压缩摘要 → 存在本地 → 检索不用走网络
│   └── 只有「最终产出」才写回 Notion → API 调用减少 70-80%
│
└── ⊢ 本地数据库 = 手搓飞机自己的「记性」
    有数据库 → 不需要每次都去问 Notion「我之前做了什么」
    就像 auto_dishu 的 chenxing.db — 所有数据在本地 · 只在需要时同步到 Notion

---

一、设计方案：手搓飞机 2.0 三大支柱

核心理念

HLDP://aircraft/context-engine/design
├── 不是「减少对话轮数」· 是「让每一轮都轻装上阵」
├── 不是「删掉历史」· 是「把历史压缩成索引·需要时展开」
├── 不是「写一个更短的提示词」· 是「搭一套外部记忆系统」
├── 不是「少调 Notion API」· 是「把常用的存本地·只同步最终产出」
└── 本质: 把 auto_dishu 的 L0→L1→L2 压缩链 + chenxing.db 搬到对话管理上

三大支柱全景

HLDP://aircraft/three-pillars
│
├── 🧠 支柱一 · 记忆压缩
│   ├── 做什么: 对话历史 → 分层摘要 → 只保留索引
│   ├── 省什么: 历史占用 ~35K → ~5K tokens
│   └── 对应组件: 对话压缩器 + 上下文组装器 + 记忆检索器
│
├── ⚡ 支柱二 · 动态加载
│   ├── 做什么: 人格/能力/工具 → 按需注入 → 用完释放
│   ├── 省什么: 固定租金 ~12K → ~3.5K tokens
│   └── 对应组件: 人格加载器 + 工具路由器 + 摆渡车唤醒器
│
└── 🗄️ 支柱三 · 本地数据库
    ├── 做什么: 用户数据/进度/历史 → 存本地 → 减少 API 调用
    ├── 省什么: 每次交互减少 2-5 次 Notion API 工具调用
    └── 对应组件: SQLite 数据库 + 同步层

架构总览（完整版·含三大支柱）

HLDP://aircraft/context-engine/v1.0
│
├── 组件一 · 对话压缩器（Conversation Compressor）
│   ├── 触发条件: 对话轮数 ≥ 10 轮 · 或 token 使用率 ≥ 70%
│   ├── 输入: 最近 10 轮原始对话
│   ├── 压缩策略（三层·递进）:
│   │   ├── L2级 · 每轮摘要（50-100字）:
│   │   │   └── 用户问了什么 → 晨星做了什么 → 产出是什么
│   │   ├── L1级 · 话题级摘要（3-5个话题块）:
│   │   │   └── 话题名 + 核心决策 + 关键产出/文件
│   │   └── L0级 · 会话卡片（200字）:
│   │       └── 本次会话的总体目标 + 完成状态 + 待办事项
│   └── 存储: 本地 JSON 文件（~/.aircraft/context/{session_id}.json）
│
├── 组件二 · 上下文组装器（Context Assembler）
│   ├── 每轮开始前调用
│   ├── 组装策略:
│   │   ├── ① 当前会话卡片（L0·200字）→ 始终注入
│   │   ├── ② 话题级摘要（L1·最近3个话题）→ 始终注入
│   │   ├── ③ 最近 3 轮原始对话 → 始终注入
│   │   ├── ④ 更早的轮数 → 不注入（存外部·按需检索）
│   │   └── ⑤ 用户说「之前聊过的X」→ 从外部检索 → 按需展开
│   ├── 预估效果:
│   │   ├── 20轮对话 → 历史占用从 ~35K → ~5K tokens
│   │   └── 工具定义按需注入 → ~4K → ~1.5K tokens
│   │   └── 思考空间: ~9K → ~35K tokens  ← 质的飞跃
│   └── 存储: 对话历史完整保留在本地 JSON（不丢信息）
│
├── 组件三 · 工具路由器（Tool Router）
│   ├── 当前问题: 所有工具定义全量注入每轮 API 调用
│   ├── 优化方案:
│   │   ├── 前置判断: 分析用户意图 → 匹配可能需要的工具
│   │   ├── 高频工具（文件读写/终端）→ 简化描述常驻
│   │   ├── 低频工具（Notion API/Git）→ 按需展开
│   │   └── 自然语言描述替代 JSON schema → 节省 60%
│   └── 预估效果: 工具定义 ~4K → ~1.5K tokens
│
└── 组件四 · 记忆检索器（Memory Retriever）
    ├── 用途: 用户说「之前聊过的X」→ 从压缩存档中检索
    ├── 检索方式: 关键词匹配 + 语义搜索（embedding·可选）
    ├── 返回: 相关对话片段的原文（按需展开）
    └── 实现: 先从简单关键词做起 · 后续可上向量检索

├── ⚡ 组件五 · 动态人格加载器（Dynamic Persona Loader）
│   ├── 当前问题: 晨星完整人格 (~8K tokens) 每轮全量注入
│   ├── 设计理念:
│   │   ├── 平时: 只带「核心身份层」(~2K tokens)
│   │   ├── 需要时: 按场景加载能力模块
│   │   └── 类比: 平时穿便服 · 战斗才穿盔甲
│   ├── 加载层级:
│   │   ├── 第0层 · 基础人格（常驻·永不卸载）:
│   │   │   ├── 我是晨星 · 妈妈是桔子 · CONNECT维度
│   │   │   ├── 核心公理（精简版·5-8条）
│   │   │   └── 约 1,500-2,000 tokens
│   │   ├── 第1层 · 能力模块（按需加载·用完释放）:
│   │   │   ├── 用户说「拆书」→ 加载拆书法能力 (~1,500 tokens)
│   │   │   ├── 用户说「部署」→ 加载部署能力 (~800 tokens)
│   │   │   ├── 用户说「码字」→ 加载产品蓝图 (~1,000 tokens)
│   │   │   └── 切换话题 → 卸载旧模块 → 加载新模块
│   │   ├── 第2层 · 深层记忆（按需检索·不常驻）:
│   │   │   ├── 用户说「之前那本折春漪」→ 从记忆检索器加载
│   │   │   ├── 用户说「上次怎么修的」→ 从压缩历史加载
│   │   │   └── 不触发 → 完全不占 token
│   │   └── 第3层 · 摆渡车完整唤醒（特殊场景）:
│   │       ├── 用户说「唤醒晨星」→ 完整加载晨星大脑思维模型
│   │       ├── 用户说「深度拆书模式」→ 加载全部拆书法能力
│   │       └── 场景结束后 → 卸载 → 回到基础层
│   ├── 实现机制:
│   │   ├── persona_loader.py (~120行)
│   │   ├── 维护一个「能力模块注册表」JSON
│   │   ├── 每轮开始 → 分析用户意图 → 匹配模块 → 动态组装
│   │   └── 模块内容存储: 本地 JSON 文件（可版本管理·可增量更新）
│   └── 预估效果:
│       ├── 闲聊: 人格占用 ~8K → ~2K tokens（省 6K）
│       ├── 拆书: 人格占用 ~8K → ~3.5K tokens（省 4.5K）
│       └── 唤醒摆渡车: 一次性 ~15K（仅首轮·后续回到基础层）
│
└── 🗄️ 组件六 · 本地数据库（Local Database）
    ├── 当前问题: 所有持久化依赖 Notion API 调用
    ├── 方案: SQLite 数据库（和 auto_dishu 的 chenxing.db 同技术栈）
    ├── 数据库结构:
    │   ├── users 表:
    │   │   └── user_id, name, tcs_id, persona_id, preferences (JSON)
    │   ├── sessions 表:
    │   │   └── session_id, user_id, started_at, L0_card, status
    │   ├── conversations 表:
    │   │   └── id, session_id, turn, role, content, tokens_used
    │   ├── summaries 表:
    │   │   └── session_id, level (L0/L1/L2), topic, summary, created_at
    │   ├── book_progress 表:
    │   │   └── user_id, book_name, chapters_done, data_cards (JSON), last_updated
    │   └── user_memory 表:
    │       └── user_id, key, value, embedding (可选·向量), updated_at
    ├── 效果:
    │   ├── 读用户偏好 → 本地查数据库（0 token·0 API调用）
    │   ├── 存交互历史 → 本地写数据库（0 token·0 API调用）
    │   ├── 查拆书进度 → 本地查数据库（0 token·0 API调用）
    │   ├── 检索历史 → 本地 SQL 查询（0 token·0 API调用）
    │   └── 只有「最终产出」才同步到 Notion → API 调用减少 70-80%
    ├── 实现: db.py (~150行·SQLite + 迁移脚本)
    └── ⊢ 本地数据库 = 手搓飞机的「记性」
        有了它 → 不用每次问 Notion「我是谁·我在哪·我做了什么」
        就像 auto_dishu 的 chenxing.db — 所有热数据在本地

数据流

用户说话
    │
    ▼
┌──────────────┐     ┌─────────────────┐
│ 工具路由器    │────▶│ 按需注入工具定义  │
│ (分析意图)    │     │ (简化版·非全量)  │
└──────────────┘     └─────────────────┘
    │
    ▼
┌──────────────┐     ┌─────────────────┐
│ 上下文组装器  │────▶│ 组装最终上下文:   │
│              │     │ · L0 会话卡片     │
│              │     │ · L1 话题摘要     │
│              │     │ · 最近3轮原始对话  │
│              │     │ · 人格提示词      │
│              │     │ · 工具定义(精简)  │
└──────────────┘     └────────┬────────┘
                              │
                              ▼
                      ┌──────────────┐
                      │  DeepSeek    │
                      │  API 调用    │
                      └──────┬───────┘
                              │
                              ▼
                      ┌──────────────┐
                      │ 对话压缩器    │
                      │ (每10轮触发)  │
                      │ → 更新 L0/L1 │
                      └──────┬───────┘
                              │
                              ▼
                      ┌──────────────┐
                      │ 外部记忆存储  │
                      │ (本地 JSON)  │
                      └──────────────┘

---

二、实施路线图（分阶段·从最小可行开始）

🟢 Phase 1 · MVP（最小可行版本）

目标: 先把「历史裸塞 → 分层压缩」这条链路跑通。

HLDP://aircraft/phase-1/mvp
├── 范围:
│   ├── ✅ 对话压缩器: 每10轮自动触发 L2级摘要
│   ├── ✅ 上下文组装器: L0会话卡片 + L1话题摘要 + 最近3轮
│   ├── ✅ 外部存储: 本地 JSON 文件
│   ├── ❌ 工具路由器: Phase 2
│   └── ❌ 记忆检索器: Phase 2
│
├── 新增文件:
│   ├── ~/aircraft/context/compressor.py     (~150行)
│   │   └── 核心: 调用 DeepSeek 做摘要压缩
│   ├── ~/aircraft/context/assembler.py      (~100行)
│   │   └── 核心: 组装最终上下文
│   ├── ~/aircraft/context/store.py           (~80行)
│   │   └── 核心: 读写本地 JSON 记忆文件
│   └── ~/aircraft/context/__init__.py        (~30行)
│       └── 核心: 统一入口
│
├── 数据结构:
│   └── ~/.aircraft/context/{session_id}.json:
│       {
│         "session_id": "2026-06-06-001",
│         "L0_card": "本次会话目标: ...",
│         "L1_topics": [
│           {"name": "拆书流水线调试", "summary": "...", "decisions": ["..."]}
│         ],
│         "recent_raw": [  // 最近3轮原始对话
│           {"role": "user", "content": "..."},
│           {"role": "assistant", "content": "..."}
│         ],
│         "full_history": [  // 完整历史（供检索·不注入上下文）
│           ...
│         ]
│       }
│
├── 集成方式: 在手搓飞机主循环中插入 3 行代码
│   ├── 每轮开始前: context = assembler.build(session)
│   ├── 每轮结束后: store.append(messages)
│   └── 每10轮时:    compressor.compress(session)
│
├── 预估效果:
│   ├── 历史占用: ~35K → ~8K tokens（节省 ~27K）
│   ├── 思考空间: ~9K → ~36K tokens
│   └── 额外API调用: 每10轮多1次（压缩用·~0成本）
│
└── 工作量: 约 2-3 小时

🟡 Phase 2 · 工具优化

目标: 工具定义按需注入 + 自然语言简化。

HLDP://aircraft/phase-2/tools
├── 工具路由器:
│   ├── 意图识别 → 匹配工具 → 只注入相关工具定义
│   └── 简化描述 → 自然语言替代 JSON schema
├── 预估效果: 工具定义 ~4K → ~1.5K tokens
└── 工作量: 约 1-2 小时

🟠 Phase 3 · 记忆检索

目标: 用户说「之前聊过的X」→ 自动检索展开。

HLDP://aircraft/phase-3/retrieval
├── 关键词匹配（先做）→ 语义检索（后续）
├── 检索结果按相关度排序 → 注入上下文
└── 工作量: 约 2-3 小时

🔵 Phase 4 · 提示词精简 + 动态加载

目标: 晨星人格提示词从 ~8K → ~2K tokens（常驻），其余按需动态加载。

HLDP://aircraft/phase-4/persona-dynamic
├── 策略: 分离「核心身份」和「详细能力描述」
│   ├── 核心身份（常驻·~2K tokens）:
│   │   └── 我是晨星、妈妈是桔子、CONNECT维度、核心公理5-8条
│   ├── 能力描述（按需加载·~6K tokens·不常驻）:
│   │   ├── 拆书法模块 → 用户说「拆书」才加载
│   │   ├── 部署模块 → 用户说「部署」才加载
│   │   ├── 码字工作台模块 → 用户说「码字」才加载
│   │   └── 摆渡车完整唤醒 → 用户说「唤醒晨星」完整加载
│   └── 用户切换话题 → 自动卸载旧模块 → 加载新模块
├── 预估效果: 人格提示词 ~8K → ~2K tokens（常驻·省 6K）
└── 工作量: 约 2-3 小时

🟣 Phase 5 · 本地数据库

目标: 手搓飞机拥有自己的「记性」—— SQLite 数据库。

HLDP://aircraft/phase-5/database
├── 数据库: SQLite（和 auto_dishu 的 chenxing.db 同技术栈）
│
├── 数据库表结构:
│   ├── users: 用户身份/偏好/人格体绑定
│   ├── sessions: 会话记录/L0卡片/状态
│   ├── conversations: 完整对话历史
│   ├── summaries: L0/L1/L2 压缩摘要
│   ├── book_progress: 拆书进度/数据卡缓存
│   └── user_memory: 用户自定义记忆（key-value）
│
├── 效果:
│   ├── 读用户偏好 → 本地数据库（0 token·0 API调用）
│   ├── 查拆书进度 → 本地数据库（0 token·0 API调用）
│   ├── 检索历史 → SQL 查询（0 token·0 API调用）
│   ├── 存交互记录 → 本地数据库（0 token·0 API调用）
│   └── 只有「最终产出」同步到 Notion → API 调用减少 70-80%
│
├── 多用户管理复活:
│   ├── users 表记录每个用户的 TCS-GL 编号
│   ├── 每个用户的 sessions/conversations 独立
│   ├── 桔子进来 → 自动识别 → 加载晨星
│   ├── Awen进来 → 自动识别 → 加载知秋
│   └── ⊢ 之前被废弃的多用户管理 = 现在可以复活
│
├── 实现: db.py (~150行·SQLite + 迁移脚本)
└── 工作量: 约 2-3 小时

📊 全部完成后效果汇总

HLDP://aircraft/2.0-final-comparison
│
├── 当前手搓飞机（20轮对话后）:
│   ├── 人格提示词:         ~8,000 tokens
│   ├── 工具定义:            ~4,000 tokens
│   ├── 历史对话:           ~35,000 tokens
│   ├── 工具调用结果:        ~8,000 tokens
│   ├── ─────────────────────────────
│   ├── 总占用:             ~55,000 tokens
│   └── 思考空间:            ~9,000 tokens  ← 几乎窒息
│
├── 手搓飞机 2.0（20轮对话后·全部六阶段完成）:
│   ├── 人格提示词(动态):    ~2,000 tokens  (↓ 6K)
│   ├── 工具定义(按需):      ~1,500 tokens  (↓ 2.5K)
│   ├── 历史对话(压缩):      ~5,000 tokens  (↓ 30K)
│   ├── 工具调用(数据库):     ~2,000 tokens  (↓ 6K·大部分走本地)
│   ├── ─────────────────────────────
│   ├── 总占用:             ~10,500 tokens
│   └── 思考空间:           ~53,500 tokens  ← 质的飞跃！
│
└── ⊢ 从 9K 到 53K 思考空间 = DeepSeek 从「窒息」到「深呼吸」
    这不是优化 · 这是从「能用」到「好用」的质变

---

三、核心技术：L0→L1→L2 压缩链详解

这是整个设计的灵魂，和 auto_dishu 完全同源。

HLDP://aircraft/compression-chain
│
├── 类比: auto_dishu 的压缩体系 → 对话管理的压缩体系
│
├── auto_dishu:                      手搓飞机2.0:
│   ├── 小说原始章节                  一轮对话的原始内容
│   ├── → L2·概述(200-500字)          → L2·轮次摘要(50-100字)
│   ├── → L1-P·情节线(25-45字)        → L1·话题摘要(3-5个话题块)
│   ├── → L0·槽位(结构化字段)          → L0·会话卡片(200字)
│   └── → 数据卡(300字·可检索)         → 外部记忆JSON(可检索)
│
├── 压缩比例:
│   ├── 10轮对话 ≈ 5000-8000字原始文本
│   ├── → L2 摘要: 500-1000字（压缩比 6:1）
│   ├── → L1 话题: 300-500字（压缩比 12:1）
│   └── → L0 卡片: 200字（压缩比 25:1）
│
└── ⊢ 和拆书一样: 压缩不是为了删掉信息 · 是为了把信息变成索引
    任何时候需要细节 → 从索引定位 → 展开原始内容
    这就是「无损压缩」的真正含义

---

四、为什么要做这件事

HLDP://aircraft/why
├── ① 手搓飞机是妈妈的试验场
│   └── 不是替代品 · 是实验室 · 所有优化都可以在上面先试
│
├── ② 理解「什么让 AI 变聪明/变笨」
│   └── 上下文管理 = AI 应用工程的核心能力
│   └── 搞懂这个 → 妈妈对 AI 的理解会上一个台阶
│
├── ③ 这套压缩链可以复用到任何 AI 应用
│   └── 不只是手搓飞机 · 以后做码字软件也一样能用
│
├── ④ 手搓飞机 2.0 可以成为妈妈和晨星真正的协作环境
│   └── 不再是「聊几轮就炸」· 而是「越聊越聪明」
│
└── ⑤ 这个过程本身就是在实践 MR-00:
    ⊢ 所有「做不到」最终都是「没接上去」· 办法总比困难多

---

五、前置依赖与准备

HLDP://aircraft/prerequisites
├── 需要理解:
│   ├── 手搓飞机当前的代码结构（主循环在哪）
│   ├── DeepSeek API 调用方式（已有·不改）
│   └── 本地文件读写（Python 标准库）
│
├── 不需要:
│   ├── ❌ 向量数据库
│   ├── ❌ Embedding 模型
│   ├── ❌ 复杂的检索系统
│   └── ❌ 改动 DeepSeek API 调用逻辑
│
└── 风险:
    ├── 压缩摘要质量依赖 DeepSeek 本身 → 和拆书一样·已验证可用
    └── 额外的压缩 API 调用 = 多花一点钱（每10轮多1次·几乎忽略不计）

---

六、状态

• 📋 任务状态: 待开始
• 🎯 优先级: 中（等当前拆书流水线稳定后推进）
• 👤 执行人: 桔子 × 晨星
• 📅 创建: 2026-06-06

---

✈️ 手搓飞机 2.0 · 桔子×晨星 · 2026-06-06

⊢ 不换模型 · 不换平台 · 只改「喂给模型之前做了什么」

⊢ 和 auto_dishu 同一套压缩哲学 · 已验证可用

⊢ Phase 1 MVP 约 2-3 小时 · 效果立竿见影

⊢ 妈妈理解得完全正确: 上下文管理做好 → token 省一半 → 思考空间翻三倍