夜雨聆风
当你费尽心思整理了详细的项目文档，却发现 AI 完全"无视"它们时，你会感到沮丧。但这不是 AI 的"傲慢"，而是技术原理的必然结果。今天我们来揭开这背后的科学原理。
一、故事开始：一个令人困惑的现象
场景重现
你花了一整天时间：
• 创建了完整的 GDL 开发规范文档 • 整理了详细的项目目录结构 • 编写了清晰的开发模板 • 保存了所有重要的参考材料
满怀期待地打开 OpenClaw，输入：
"帮我创建一个窗户对象，按照我的 GDL 规范来"
然而，AI 的回复却像是从另一个平行宇宙来的：
• 完全不提及你的规范 • 按照通用模式编写代码 • 命名风格和你文档中的完全不同 • 仿佛你的工作空间根本不存在
为什么？ 明明文件就在那里，文档那么详细，AI 却"视而不见"？
二、真相揭秘：AI 的"工作台"有多大
什么是上下文窗口（Context Window）？
想象一个场景：
你有一张工作台，上面可以放各种资料：
• 项目文档 • 代码规范 • 历史对话 • 当前的用户请求
但这张工作台的大小是有限的。
每次你与 AI 对话，系统都会把以下内容"搬"到这张工作台上：
1. 系统提示词（告诉 AI 它是谁、要做什么） 2. 历史对话记录（你们之前的交流） 3. 你的工作空间文档（如果选择加载） 4. 你当前的请求
然后 AI 基于这张"工作台"上的所有内容来思考和回答。
关键点：工作台大小有限！放不下的东西就会被"挤掉"。
7B 参数的模型工作台有多大？
让我们用数据说话：
| Qwen 2.5 7B | 7B（70亿） | 32K tokens | 约 2.5 万汉字 |
看到了吗？
你的 7B 模型能"搬上工作台"的内容，只有 GPT-4 的四分之一！
一个生动的类比
想象一下：
GPT-4 就像 一个拥有超大书桌的教授，可以同时铺开几十本书，随时查阅任何细节。
Qwen 7B 就像 一个小书桌的助教，书桌只能放下几本关键书，其他书必须"按需"去书架取。
现在，你的工作空间：
• 7 个 GDL 规范文档（每个 3000 字） • 项目 README（2000 字） • 开发模板（1500 字） • 代码示例（2000 字） • 历史对话记录（几千字）
总字数：可能超过 5 万字！
结果就是：你的 7B 模型的"小书桌"根本放不下这么多资料。
三、OpenClaw 如何与模型互动？
互动流程图解
┌─────────────────────────────────────────────────────────┐│ 你：发送请求 │└────────────────────────┬────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────┐│ OpenClaw（中间管理层） ││ ││ 1. 收集上下文： ││ - 系统提示词 ││ - 历史对话 ││ - 工作空间文档（如果启用） ││ - 你的请求 ││ ││ 2. 上下文管理： ││ - 优先级排序 ││ - 截断策略 ││ - RAG（按需检索，如果启用） ││ ││ 3. 调用模型： ││ - 发送上下文到模型 ││ - 等待回复 │└────────────────────────┬────────────────────────────────┘ │ ▼┌─────────────────────────────────────────────────────────┐│ 本地模型（ollama） ││ ││ - 接收上下文 ││ - 思考和生成 ││ - 返回回复 │└─────────────────────────────────────────────────────────┘关键决策点：上下文如何组织？
OpenClaw 面临一个艰难的选择：
选项 A：全部加载
上下文 = 系统提示词 + 历史对话 + 全部工作空间文档 + 当前请求结果：
• ✅ AI 能看到所有信息 • ❌ 但 7B 模型的上下文窗口可能爆满 • ❌ 系统提示词被截断，AI 不知道自己是谁 • ❌ 历史对话被截断，失去上下文连贯性 • ❌ 文档被截断，AI 只看到碎片
选项 B：选择性加载
上下文 = 系统提示词 + 历史对话（最近）+ 部分关键文档 + 当前请求结果：
• ✅ 上下文可控，不会爆满 • ⚠️ 但 AI 可能看不到你想要它看的文档 • ⚠️ 如果"部分关键文档"选错了，AI 就会"无视"你的规范
四、为什么 7B 模型"不理会"你的文档？
三个原因
原因 1：上下文窗口容量不足
计算示例：
系统提示词：2000 tokens历史对话：8000 tokens（最近几轮）你的请求：1000 tokens剩余容量：32000 - 2000 - 8000 - 1000 = 21000 tokens你的 GDL 规范文档（7 个文件 × 3000 tokens = 21000 tokens）刚好！但如果有一个文档多一点，就会被截断。如果被截断的是最重要的那个文档，AI 就完全不知道你定义的命名规范。
原因 2：信息密度过高
GDL 技术文档的特点：
• 信息密集（每句话都是关键规范） • 互相关联（一个规范引用另一个规范） • 细节繁多（参数命名、文件格式、代码风格等）
结果：即使文档被部分加载，AI 也可能：
• 没看到完整上下文 • 理解片段产生偏差 • 遵循通用规则而非你的特定规范
原因 3：模型"理解能力"限制
7B 参数的模型（70 亿参数）：
• 推理能力有限 • 复杂任务容易"遗忘"细节 • 更倾向于使用"训练中学到"的通用模式 • 而不是 "刚刚看到的"特定规范
类比：
• 教授（大模型）看过 10000 本书，能融会贯通 • 助教（7B 模型）看过 1000 本书，更容易照搬课本例子
五、一个科学术语：RAG 是救星吗？
什么是 RAG（Retrieval-Augmented Generation）？
RAG 是一种技术，不把所有文档都放上下文里，而是"按需检索"。
传统方式（Non-RAG）：用户请求 → 全部文档 + 请求 → 模型 → 回复 ↑ 大量文档可能爆满上下文RAG 方式：用户请求 → 检索相关文档片段 → 片段 + 请求 → 模型 → 回复 ↑ ↑ 只加载几KB的精确定位片段RAG 能解决 7B 模型的问题吗？
理论上可以，但实践中：
优点
• ✅ 只加载相关的少量内容 • ✅ 上下文不会爆满 • ✅ 可以处理巨大的知识库
局限性（特别是对 7B 模型）
1. 检索准确性 • 搜索关键词可能不完全匹配 • AI 理解语义的能力有限 • "检索错误"会导致"幻觉回答" 2. 片段整合能力 • 7B 模型阅读长文档的能力较弱 • 拼接多个片段的逻辑可能出问题 • 容易产生不一致 3. 本地 RAG 的技术门槛 • 需要向量数据库（如 Chroma、FAISS） • 需要嵌入模型（embedding） • 配置复杂
结论：RAG 对大模型（GPT-4、Claude）效果很好，但对 7B 本地模型，效果可能不理想。
六、解决方案：如何让 7B 模型"听话"？
方案 1：精简上下文（推荐）
策略：
• 减少历史对话保留长度 • 只加载最关键的文档 • 使用文档摘要而非全文
示例：
不加载：- 7 个完整 GDL 规范文档（21000 tokens）改为加载：- 1 个快速参考表（2000 tokens）- 1 个命名规范摘要（1000 tokens）节省：18000 tokens！方案 2：分而治之（Skill 机制）
这正是 OpenClaw 的 Skill 设计原理！
思路：
• 不把所有文档塞进上下文 • 而是定义"触发条件" • 只有需要时才加载相应文档
示例：GDL 开发 Skill触发条件：- 用户提到 "GDL"、"ArchiCAD"、"窗"、"门"加载内容（仅触发时）：- GDL 规范（按需）- 快速参考- 代码模式结果：- 上下文平时很干净- 需要 GDL 知识时才加载- 即使 7B 模型也能处理方案 3：提示词工程
在系统提示词中明确指令：
不推荐："你是一个 AI 助手，帮助用户开发 GDL 代码。"推荐："你是一个 GDL 开发专家。用户有一个 GDL 项目，位于 /Users/ren/GDL-Library。项目中有详细的规范文档，当用户提到 GDL 时：1. 先读取 /Users/ren/GDL-Library/docs/GDL_00_Index.md2. 按需查阅其他规范文档3. 严格遵循项目命名规范和代码风格"效果：
• AI 知道何时去读文档 • 形成条件反射 • 减少盲目搜索
方案 4：升级模型（终极方案）
如果预算允许，升级到更大的模型：
| GPT-4 |
权衡：
• 本地优势：隐私、免费、可控 • 云端优势：能力强、上下文大、稳定
七、总结：这不是 AI 的错，是物理学的必然
核心原理
1. 上下文窗口是物理限制 • 就像人脑的"工作记忆"有限 • 模型越大，工作台越大 • 7B 模型的工作台很小 2. 信息过载导致"忽略" • 当工作台被填满，新信息会挤掉旧信息 • 文档被截断，AI 只看到碎片 • 无法形成完整理解 3. 解决方案是管理，而非抱怨 • Skill 机制：按需加载 • RAG 检索：精准定位 • 模型升级：更大的工作台 • 提示词优化：明确指令
给你的建议
针对 7B 本地模型：
1. **接受现实**：上下文有限，不要指望它记住所有文档2. **主动引导**：明确告诉它去读什么 > "请读取 /path/to/doc.md 中的命名规范，然后..."3. **使用 Skill**：让 OpenClaw 按需加载知识 > Skill: gdl-developer > Trigger: 当提到 GDL 相关任务时4. **分步请求**：不要一次性要求太多 > 不推荐："创建一个复杂的窗户，遵守所有规范" > 推荐："先创建基础框架，然后添加细节"5. **升级模型**：如果项目重要，考虑云端大模型一个生动的比喻
想象你有一个7 平板书桌的小助手：
• 它的能力：能帮你整理文件、写代码 • 但书桌很小：只能放下几本关键书 • 你的要求："帮我整理这间书房，有 100 本书要按我的标准分类"
结果：
• 小助手只能看到桌上的 3 本书 • 其他 97 本书在书架上 • 它按照桌上的 3 本书的标准整理 • 你觉得它"无视"你的标准
不是小助手不听话，是书桌太小放不下！
结语
AI 的"记忆力"不是无限的魔法，而是受物理原理约束的工程系统。
理解这些原理，我们就能：
• 更好地管理 AI 的上下文 • 选择合适的模型规模 • 设计更有效的交互方式 • 避免"为什么 AI 不听话"的沮丧
这不是 AI 的问题，是我们需要一起学习的协作方式。
本文首发于 [你的公众号名称]，欢迎分享和讨论。
