完全透明
已知
限制
我们相信坦诚的文档。以下是 lean-ctx 擅长的方面--以及它的边界所在。
压缩
压缩 限制
Token 节省因文件类型、内容复杂度和读取模式而异。以下是实际可期待的效果。
各场景预期节省量
| 场景 | 节省量 |
|---|---|
| 首次读取（代码文件） | 60–95% |
| 缓存重读 | 高达 99% |
| 小文件（<10 行） | 极少 |
| 二进制文件 | 跳过 |
| 未知 Shell 输出 | 直接传递 |
依赖内容的节省
实际节省取决于代码密度、注释比例和重复度。结构清晰、签名明确的代码比密集无注释的单行代码压缩效果更好。
缓存重读
当 lean-ctx 已读过某文件且该文件未改变时，重读只需约 13 个 Token，不论文件大小。这就是 99% 数据的来源。
语言
语言 支持
lean-ctx 使用 tree-sitter 进行 AST 感知压缩。覆盖范围因语言而异--以下是完整图景。
18 支持完整 AST 的 Tree-sitter 语言
95+ 已识别的 Shell 工具模式
10 每种文件类型的读取模式
语言支持层级
| 层级 | 语言 | 压缩方式 |
|---|---|---|
| 完整 AST | Rust、TypeScript、Python、Go、Java、C、C++、C#、Ruby、PHP、Swift、Kotlin、Scala、Lua、Zig、Elixir、Haskell、OCaml | 签名感知裁剪 |
| 基础 | 所有其他语言 | 行级压缩 |
基础层级仍能提供有意义的压缩--只是无法提取函数签名或裁剪 AST 节点。通过去重和熵过滤，大多数文件仍可节省 40–70%。
架构
架构 约束
lean-ctx 在特定的架构权衡下设计。理解这些有助于设定正确的期望。
MCP 要求
lean-ctx 作为 MCP 服务器运行。您的 AI 智能体必须支持 Model Context Protocol。
兼容：Claude Code、Cursor、Codex、Gemini CLI 等。
单项目范围
每个 lean-ctx 实例限定于一个项目根目录。多仓库工作流需要单独的实例。
解决方案：在工作区中为每个仓库运行一个实例。
内存扩展
内存缓存随项目增长。超大型 Monorepo（10 万+ 文件）可能需要调整缓存限制。
可通过 lean-ctx 设置配置。
坦诚的上下文
不是 替代品
lean-ctx 优化上下文传递给 LLM 的方式。它不能替代良好工程实践的基础。
重要须知
- 良好的提示实践 - 清晰、具体的指令仍然很重要
- 良好的代码组织 - 结构良好的代码压缩效果更好
- 版本控制 - lean-ctx 不管理代码变更或历史记录
lean-ctx 优化传递，不替代基础。