AI 数据通道：JSON·Markdown

元认知：工具会过时，思想不会 #

AI Week Report 三期报告覆盖 18 个项目。大部分 AI 工具文章的做法是：列出项目 → 转述 README → 说”这个项目能做 X”。这种写法的问题是：工具会过时，但工具背后的思想不会。

OmniRoute 的 Token 压缩技术（RTK + Caveman）两年后可能被更好的分词器取代。codebase-memory-mcp 的纯 C 实现可能被 Rust 重写。但”在处理之前压缩输入”和”返回结构而非内容”这两个思想，十年后仍然成立——因为它们不依赖具体技术，依赖的是信息处理的底层规律。

本文从 7 个真优化项目中，提炼出四个可迁移到方方面面的设计哲学。每个哲学不讲”哪个项目用了它”，讲”它为什么有效、怎么迁移、什么时候别用”。

四个哲学一览 #

哲学来源项目一句话迁移到哪里
返回结构，而非内容codebase-memory-mcp不要给 LLM 整本书，给它目录RAG、API、知识库、日志分析
约束优于自由ponytail限制输出格式比放开更能激发创造力AI 生成、代码规范、写作
优化在处理之前headroom在数据进入流程前压缩，而非之后数据管线、提示工程、缓存
确定性做确定性的事open-code-review规则能解决的不要用概率代码审查、安全检查、数据验证

这四个哲学不是平行关系，它们构成一个完整的 AI 系统设计流程：

1
2
3
输入 → [前置压缩] → [索引结构] → [约束生成] → 输出
                ↑                    ↑
          确定性管道处理规则问题    LLM 处理语义问题

下面逐个剖析。

哲学一：返回结构，而非内容 #

原理 #

LLM 的上下文窗口是稀缺资源。每塞进去一个 Token，都在消耗三样东西：

  1. 金钱：按 Token 计费
  2. 注意力：LLM 的注意力机制对所有 Token 一视同仁，冗余 Token 稀释关键信息
  3. 窗口空间：塞满了就装不下新内容

传统做法把”内容”塞进上下文，让 LLM 自己找答案。索引做法把”结构”塞进上下文，让 LLM 决定要不要读具体内容。

1
2
传统做法：返回 5 个代码块（几千 Token）→ LLM 从中找答案
索引做法：返回"函数 A 在文件 B 第 C 行被调用"（几十 Token）→ LLM 按需读取

这个区别可以用一个比喻理解：

传统做法 = 把整本书递给图书馆员，说”帮我找第三章”
索引做法 = 把目录递给图书馆员，说”帮我找第三章”

目录只有一页，但包含了整本书的结构。图书馆员（LLM）看完目录就知道第三章在哪，然后自己去翻。

为什么有效 #

这个哲学的有效性建立在一个底层事实上：人类处理信息的方式，和 LLM 处理信息的方式，有根本性的不匹配。

人类习惯”先看摘要，再决定要不要深入”——因为人类的注意力是串行的，看完全文太慢。LLM 被迫”先看全文，再找答案”——因为 LLM 的注意力是并行的，理论上可以同时处理所有 Token。

但”理论上可以”不等于”实际效果好”。LLM 的注意力机制对所有 Token 一视同仁，当上下文里充满冗余内容时，关键信息被稀释了。这就像在一个嘈杂的房间里，虽然你能听到所有人的声音，但你听不清任何一个人的话。

索引范式弥合了这个不匹配：给 LLM 一个”目录”而非”全文”，让 LLM 的注意力集中在结构上，而非被内容淹没。

迁移场景 #

场景传统做法（返回内容）索引做法（返回结构）
RAG 系统检索 5 个文本块塞进上下文返回”相关段落在文档 X 第 Y 节”，AI 按需读取
API 设计返回完整 JSON 对象返回字段引用 + 按需加载
知识管理搜索返回全文搜索返回摘要 + 来源定位
代码审查返回整个文件返回”第 42 行有潜在 NPE”
日志分析返回 1000 行日志返回”3 个异常 + 时间戳 + 调用栈”
文档检索返回 10 页 PDF返回”第 5 页第 2 段回答了你的问题”
数据库查询SELECT *SELECT id, name WHERE …
人类沟通“我给你讲个故事…”“结论是 X，依据在 Y”

边界：什么时候别用 #

不是所有场景都适合”返回结构”：

  • 需要全文理解的场景（如翻译、摘要）：必须返回内容，结构无法替代
  • 结构不明确的场景（如创意写作）：没有”结构”可返回
  • LLM 需要上下文才能理解的场景（如代码补全）：需要返回周围代码

判断标准：如果 LLM 可以通过”知道在哪里”来找到答案，就返回结构；如果 LLM 必须”看到内容”才能回答，就返回内容。

哲学二：约束优于自由 #

原理 #

LLM 生成代码的过程是：给定上下文，预测下一个 Token 的概率分布，采样，重复。如果上下文里有大量”详细实现”的示例，LLM 会倾向于生成详细实现。如果上下文里有大量”极简实现”的示例，LLM 会倾向于生成极简实现。

LLM 的输出不是”自由创作”，是”上下文的概率延伸”。 你给什么样的上下文，就得到什么样的输出。

约束生成的原理是：在上下文中注入约束信号，引导 LLM 的概率分布向期望方向偏移。

1
2
无约束：你让 AI 写个登录功能 → AI 生成 300 行代码，包含 5 个抽象层
有约束：你告诉 AI "用最少的代码实现，不写不必要的抽象层" → AI 生成 50 行

为什么有效 #

这个哲学的有效性建立在一个反直觉的事实上：约束不是限制创造力，约束是创造力的前提。

没有约束的 AI 生成，倾向于”覆盖所有可能性”——因为 LLM 的训练数据里充满了”完整实现”的示例。你让它写个函数，它会写参数校验、错误处理、日志记录、文档注释、单元测试……因为训练数据里”好代码”就是这样的。

但”好代码”不等于”适合当前场景的代码”。你只是想要一个快速验证想法的原型，不需要企业级的健壮性。约束的作用是告诉 LLM “当前场景不需要什么”。

这和人类创作的原理一致：

莎士比亚写十四行诗，约束是 14 行、特定的韵脚和节奏。正是这些约束，让十四行诗成为一种独特的艺术形式。如果给他一张白纸说”随便写”，他可能写不出任何东西。

迁移场景 #

场景无约束（放开）有约束（限制）
AI 代码生成“实现登录功能”“用 20 行以内实现登录，不写抽象层，必须有输入验证”
AI 写作“写一篇关于 AI 的文章”“写 500 字，不用’赋能’’闭环’等 buzzword，第一句必须是问句”
API 设计“设计一个用户接口”“最多 5 个端点，每个端点最多 3 个参数，返回 JSON”
数据格式“给我数据”“给我 CSV 格式，第一行是表头，日期用 ISO 8601”
需求文档“描述你要什么”“用用户故事格式：作为 X，我想 Y，以便 Z”
代码规范“写好代码”“函数不超过 50 行，圈复杂度不超过 10，必须有单元测试”

边界：什么时候别用 #

  • 探索性任务：你不知道要什么，需要 AI 帮你探索可能性，约束会限制探索范围
  • 创意任务：写诗、写故事、设计 logo，过度约束会扼杀创意
  • 学习场景：初学者需要看到”完整实现”来学习，约束会隐藏关键细节

判断标准：如果你知道”不要什么”，用约束；如果你不知道”要什么”，不用约束。

哲学三：优化在处理之前 #

原理 #

传统的优化思路是”处理完再看结果好不好，不好再优化处理过程”。前置优化的思路是”在数据进入处理流程之前，先优化数据本身”。

1
2
传统优化：输入 → [处理] → 输出 → [检查质量] → 如果不好，优化处理过程
前置优化：输入 → [压缩/过滤/结构化] → [处理] → 输出

这个哲学的底层原理是：垃圾进，垃圾出（GIGO）。 如果输入的数据质量差，处理过程再好也没用。

在 AI 场景中，”处理”= LLM 推理，”输入”= 上下文。前置优化的意思是：在数据进入上下文窗口之前，先压缩、过滤、结构化。

为什么有效 #

这个哲学的有效性建立在一个经济学原理上：边际成本递增。

LLM 的推理成本不是线性的。上下文从 1000 Token 增加到 2000 Token，成本翻倍但质量可能只提升 10%。上下文从 10000 Token 增加到 20000 Token，成本翻倍但质量可能只提升 1%。

原因是注意力机制的稀释效应：上下文越长，每个 Token 获得的注意力权重越分散，关键信息越容易被淹没。

前置优化的逻辑是：在成本翻倍之前，先删掉不必要的内容。 删除 50% 的冗余内容，成本减半，但质量几乎不变——因为删掉的是 LLM 根本不看的内容。

迁移场景 #

场景后置优化（处理后再改）前置优化（处理前先改输入）
RAG 系统检索 10 个文档 → LLM 回答 → 答案太长，截断检索 10 个文档 → 压缩为摘要 → LLM 回答
代码审查AI 审查整个文件 → 输出 500 行报告 → 人工筛选过滤掉测试文件和配置文件 → AI 只审查核心代码
日志分析把 10000 行日志全给 AI → AI 分析 → 结果不准确先用规则过滤出 ERROR 级别 → AI 只分析 100 行
数据处理加载 1GB 数据 → 处理 → 内存溢出先采样 100MB → 处理 → 快速验证
提示工程写一个 2000 字的 prompt → LLM 回答 → 回答偏离重点先写 200 字的核心指令 → LLM 回答 → 回答精准
缓存设计每次请求都查数据库 → 慢 → 加缓存请求先查缓存 → 缓存没有再查数据库

边界：什么时候别用 #

  • 输入数据量本来就不大：压缩的开销可能大于收益
  • 需要完整数据才能做判断的场景：如法律审查、医疗诊断，不能过滤掉任何信息
  • 前置优化的成本高于后置优化：如果过滤逻辑本身很复杂，不如直接处理

判断标准：如果输入数据有明显的冗余，前置优化；如果输入数据已经很精炼，不需要前置优化。

哲学四：确定性做确定性的事 #

原理 #

LLM 是概率系统——同一段代码，问两次可能得到不同的审查意见。但有些问题的检测规则是明确的：NPE 就是空指针，SQL 注入就是拼接了用户输入，XSS 就是没转义 HTML 字符。

这些问题不需要”理解”代码语义，只需要模式匹配。 模式匹配是编译器技术的强项——AST 解析 + 数据流分析，成熟且稳定。

混合架构的原理是：确定性问题用确定性方法，不确定性问题用概率方法，两者分工。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
输入
  │
  ├── 确定性管道（规则引擎）
  │     ├── AST 解析
  │     ├── 数据流分析
  │     ├── 模式匹配（已知规则）
  │     └── 输出：确定性问题 + 精确位置
  │
  ├── LLM Agent（语义理解）
  │     ├── 接收确定性管道的输出作为上下文
  │     ├── 分析语义（命名、逻辑、架构）
  │     └── 输出：语义问题 + 建议
  │
  └── 合并输出

为什么有效 #

这个哲学的有效性建立在一个分工原理上：工具应该匹配问题的性质。

用 LLM 检测 NPE，就像用 microscope 锤钉子——能锤，但不是最佳工具。锤钉子应该用锤子（规则引擎），显微镜（LLM）应该用来看细胞（语义理解）。

混合架构的优势：

  1. 稳定性：确定性管道的检测结果 100% 可重现，不受 LLM 随机性影响
  2. 成本：确定性管道不消耗 Token，只有 LLM 部分消耗 Token
  3. 精确性：确定性管道基于 AST 能给出精确行号，LLM 给出的行号经常偏移
  4. 互补性：确定性管道做”已知模式检测”，LLM 做”未知模式推理”

迁移场景 #

场景纯 LLM（全用概率）混合架构（确定性 + 概率）
代码审查LLM 审查所有问题规则引擎查 NPE/SQL注入/XSS，LLM 审查命名/逻辑/架构
安全检查LLM 检查安全漏洞规则引擎查已知 CVE，LLM 分析未知攻击模式
数据验证LLM 验证数据格式正则验证格式，LLM 验证语义合理性
内容审核LLM 审核所有内容关键词过滤敏感词，LLM 判断上下文是否违规
测试生成LLM 生成所有测试规则生成边界值测试，LLM 生成语义测试
文档生成LLM 生成完整文档模板生成骨架，LLM 填充描述

边界：什么时候别用 #

  • 问题本身不确定：如创意写作、情感分析，没有”确定性”部分可分离
  • 规则不明确：如果连人都说不清”什么是好代码”，规则引擎无法编码
  • 开发成本高：确定性管道需要开发规则集，如果规则经常变，维护成本高

判断标准：如果问题可以写成 if-else 规则，用确定性方法；如果需要”理解”才能判断，用 LLM。

四个哲学的协同 #

这四个哲学不是孤立的，它们可以组合使用，构成一个完整的 AI 系统设计流程：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
原始输入
  │
  ├── 哲学三：前置压缩
  │     删除冗余、过滤噪音、采样数据
  │     目标：减少输入量
  │
  ├── 哲学一：返回结构
  │     将内容转化为索引、摘要、引用
  │     目标：改变输入格式
  │
  ├── 哲学四：确定性分工
  │     规则能处理的走确定性管道
  │     需要理解的走 LLM
  │     目标：分工处理
  │
  ├── 哲学二：约束生成
  │     限制 LLM 的输出格式和范围
  │     目标：控制输出质量
  │
  └── 最终输出

一个具体案例：设计一个 AI 代码审查系统

  1. 前置压缩：过滤掉测试文件、配置文件、第三方库，只保留核心代码
  2. 返回结构：不把整个文件给 LLM，先解析 AST，返回”函数列表 + 调用关系 + 复杂度”
  3. 确定性分工：用规则引擎检测 NPE/SQL注入/XSS，用 LLM 检测命名/逻辑/架构
  4. 约束生成：限制 LLM 输出为”问题列表 + 行号 + 修复建议”格式，不输出分析过程

这四步组合的效果：Token 消耗降低 90%，检测准确率提升，输出可直接用于 CI/CD。

缺陷与批判：哲学的局限 #

这四个哲学不是银弹，每个都有其局限：

哲学局限什么时候会失效
返回结构丢失细节需要全文理解的场景（翻译、摘要）
约束优于自由扼杀创意探索性任务、创意任务
优化在处理之前过度优化输入数据量本来就不大的场景
确定性分工规则不明确问题本身不确定（情感分析、创意写作）

更深层的问题：这四个哲学都隐含一个假设——你知道要什么。

  • 返回结构：你得知道什么结构是重要的
  • 约束生成：你得知道什么约束是合理的
  • 前置优化：你得知道什么内容是冗余的
  • 确定性分工：你得知道什么规则是确定的

如果你不知道要什么，这四个哲学都不适用。这时你需要的是探索，不是优化。

总结：为什么这四个哲学可以迁移到方方面面 #

这四个哲学之所以可迁移，是因为它们不依赖具体技术，依赖的是信息处理的底层规律：

哲学底层规律
返回结构注意力是稀缺资源，结构比内容更节省注意力
约束优于自由输出是输入的概率延伸，约束输入就约束了输出
优化在处理之前边际成本递增，在成本翻倍前减少输入
确定性分工工具应该匹配问题的性质，确定性用规则，不确定性用概率

这些规律不随技术演进而改变。LLM 变成什么模型、Token 怎么计费、上下文窗口多大——都不影响这些规律的有效性。

一句话总结：

工具是思想的载体，思想是工具的灵魂。工具会过时，思想不会。当你理解了”返回结构而非内容”的原理，你不需要 codebase-memory-mcp 也能设计出高效的 RAG 系统；当你理解了”确定性做确定性的事”的原理，你不需要 open-code-review 也能设计出可靠的混合架构。

这四个哲学，是 AI 时代的工程设计基本功。

参考资料：