为什么大型规范会让你的 AI 代理变笨（以及如何解决）
你的规范能装进上下文窗口。那为什么你的 AI 代理会犯错、忽略指令、产出更差的代码呢？
你把一份详细的 2,000 行架构文档粘贴到 Cursor 中。上下文窗口能处理——20 万令牌，空间足够。但有些不对劲。AI 建议了一种你在第 3 页明确排除的方法。它问了你已经回答过的问题。它生成的代码与你记录的设计决策相矛盾。
问题不在上下文大小。而在上下文质量。
真正的问题：性能下降
现代 AI 模型有巨大的上下文窗口——Claude 有 20 万令牌，GPT 有 12.8 万，更新的模型正在推向 100 万以上。但营销不会告诉你的是：即使远未达到上限，AI 性能也会随着上下文增长而显著下降。
研究结果很清楚：
Databricks 发现长上下文性能显著下降，即使在理论限制内。较小的模型下降得更早。
伯克利的函数调用排行榜 证实，当给出更多工具或选项时，所有模型的性能都会下降。更多上下文 = 更多困惑 = 更低准确性。
研究显示（arXiv:2505.06120）当模型需要跨多个上下文轮次处理信息或面对增加的复杂性时，性能会显著下降。
为什么会这样
这归结于基本约束：
-
注意力稀释 - Transformer 注意力有 N² 的复杂度。更多令牌 = 更难专注于重要内容。
-
上下文衰退 - 在大型上下文中，模型开始忽略训练，只是重复上下文历史中的模式。它们变得不那么智能，而不是更智能。
-
选项过载 - 太多选择（工具、模式、方法）导致错误的选择。这不是 AI 独有的——这是一种认知约束。
-
令牌经济学 - 每个额外的令牌都需要金钱和时间。一个 2,000 行的规范比一个 300 行的规范处理成本高 6 倍。
这对你意味着什么
当你使用 AI 编码助手时：
- Cursor、Copilot、Claude 开始犯基本错误，在较小上下文下不会犯这些错误
- 代码生成变得不太准确，更容易与你的需求相矛盾
- 响应速度变慢，因为模型处理更多无关信息
- 成本线性增长，与上下文大小成正比
- 你花更多时间修复 AI 错误，而不是从 AI 协助中节省时间
讽刺的是：你写详细的规范来帮助 AI，但细节却让 AI 变差。
解决方案：上下文工程
上下文工程是管理 AI 工作记忆以最大化效果的实践。它不是关于压缩到上下文限制内——而是关于在任何规模下保持 AI 性能。
以下是四种实际有效的策略，有研究和实际使用的支持：
1. 分区（Partition）- 拆分并选择性加载
它是什么：将内容分解为集中的块，只加载当前任务所需的内容。
示例：
# 不是一个 1,200 行的规范：
specs/dashboard/README.md (200 行 - 概述)
specs/dashboard/DESIGN.md (350 行 - 架构)
specs/dashboard/IMPLEMENTATION.md (150 行 - 计划)
specs/dashboard/TESTING.md (180 行 - 测试)
# AI 只加载它需要的内容
# 做架构？只读 DESIGN.md
# 编写测试？只读 TESTING.md
好处：AI 处理 200-350 行而不是 1,200 行。更快、更集中、更少错误。
2. 精简（Compact）- 去除冗余
它是什么：消除重复或可推断的内容。
之前：
## 身份验证
身份验证系统使用 JWT 令牌。JWT 令牌是
行业标准，提供无状态身份验证。JWT
令牌的好处是它们不需要服务器端
会话存储...
## 实现
我们将实现 JWT 身份验证。选择 JWT 是因为...
[重复相同的理由]
之后：
## 身份验证
使用 JWT 令牌（无状态，无会话存储）。
## 实现
[链接到身份验证部分获取理由]
好处：更高的信噪比。AI 专注于独特信息，而不是重复。
3. 压缩（Compress）- 总结已完成的工作
它是什么：压缩已完成的工作，同时保留关键决策。
之前：
## 第 1 阶段：基础设施设置
设置项目结构：
- 创建 src/ 目录
- 创建 tests/ 目录
- 使用 tsconfig.json 配置 TypeScript
- 使用 .eslintrc 设置 ESLint
[50 行详细步骤...]
之后（完成后）：
## ✅ 第 1 阶段：基础设施（完成于 2025-10-15）
建立了 TypeScript、测试和 CI 的项目结构。
详情见提交 abc123。
好处：保留项目历史，无需臃肿。AI 知道发生了什么，而不会淹没在细节中。
4. 隔离（Isolate）- 分离无关关注点
它是什么：将独立功能移动到单独的规范中，并建立清晰的关系。
之前：一个 1,200 行的规范涵盖仪表板 UI、指标 API、健康评分算法和图表库评估。
之后：四个集中的规范，每个少于 400 行：
dashboard-ui- 用户界面和交互metrics-api- 数据端点设计health-scoring- 算法详情chart-evaluation- 库比较（决策后可归档）
好处：独立演进。当算法改变时，UI 规范保持不变。
关键洞察
保持上下文密集（高信号），而不仅仅是小。
这不是关于任意的行数限制。这是关于删除任何不直接影响当前决策的内容。每个不帮助 AI 做出更好选择的词都在让它变差。
从实践中获得的真实结果
我们使用 LeanSpec 本身来构建 LeanSpec——这是对这种方法论是否真正有效的终极测试。
速度：从零到生产 10 天
- 具有 15+ 命令的功能齐全的 CLI
- 用于 Cursor，GitHub Copilot 集成的 MCP 服务器
- 带有综合指南的文档网站
- 编写并实现了 60 多个规范，使用 AI 代理
然后我们违反了自己的原则：一些规范增长到 1,166 行。我们遇到了我们正在解决的确切问题：
- AI 代理在编辑期间开始破坏规范
- 代码生成变得不太可靠
- 响应速度明显变慢
- 我们花更多时间修复错误
我们应用了上下文工程：拆分大型规范，精简冗余内容，压缩历史部分。
- 最大的规范从 1,166 行 → 378 行（最大分区）
- AI 代理再次可靠工作
- 更快的迭代，准确的输出
- 可以自信地说："我们实践我们所宣扬的"
你将看到的具体好处
当你将上下文工程应用到你的规范时：
- ✅ 更少的 AI 错误 - 集中的上下文产生准确、一致的输出
- ✅ 更快的迭代 - 每次 AI 请求的处理时间更少
- ✅ 更低的成本 - 更少的令牌 = 更便宜的 API 调用（2,000→300 行减少可节省 6 倍）
- ✅ 更好的理解 - AI 实际遵循你的需求，而不是幻觉
- ✅ 人类可维护 - 5-10 分钟内可以阅读的规范与代码保持同步
适用于你的工具
这不是关于特定的 AI 工具——而是关于所有基于 transformer 的模型如何处理上下文：
- Cursor - 读取 markdown 规范作为上下文
- GitHub Copilot - 使用工作区文件进行建议
- Claude - 通过 MCP 服务器集成
- Aider - 处理项目文档
- Windsurf - 分析代码库上下文
任何 AI 编码助手都受益于精心设计的上下文。
开始使用
LeanSpec 为你提供方法论和工具，将上下文工程应用到你的规范中。
方法论
五个原则指导决策：
- 上下文经济 - 适合工作记忆（人类 + AI）
- 信噪比 - 每个词都传达决策信息
- 渐进式披露 - 在需要时添加结构
- 意图优于实现 - 捕获为什么，而不仅仅是如何
- 弥合差距 - 人类和 AI 都能理解
这些不是任意的规则——它们源于真实的约束（transformer 注意力、认知限制、令牌成本）。
工具
CLI 命令帮助你检测和修复上下文问题：
# 安装
npm install -g lean-spec
# 在你的项目中初始化
cd your-project
lean-spec init
# 检测问题
lean-spec validate # 检查问题
lean-spec complexity <spec> # 分析大小/结构
# 修复问题
lean-spec split <spec> # 引导式拆分工作流
# 跟踪进度
lean-spec board # 所有规范的看板视图
从简单开始，根据需要增长
个人开发者？ 只使用 status 和 created 字段。保持规范集中。
小团队？ 添加 tags 和 priority。使用 CLI 获得可见性。
企业？ 添加自定义字段（epic、sprint、assignee）。与你的工作流集成。
结构适应你的需求——你永远不会"以防万一"添加复杂性。
今天就试试
npm install -g lean-spec
cd your-project
lean-spec init
lean-spec create user-authentication
你的 AI 编码助手会感谢你。
底线
你的 AI 工具只有你给它们的上下文好。
一个 2,000 行的规范即使适合上下文窗口，仍然会产生比具有相同基本信息的 300 行规范更差的结果。这不是关于限制——而是关于性能。
上下文工程不是优化。它是让 AI 辅助开发可靠工作的基础。
LeanSpec 是一种用于人类-AI 协作的软件规范上下文工程方法论。它为你提供：
- 源于真实约束的原则
- 从个人到企业扩展的模式
- 检测和防止上下文问题的工具
- 使用方法论构建工具的证明
选择：继续写大型规范并与不可靠的 AI 输出作斗争，或者为你实际使用的工具设计你的上下文。
了解更多：
- GitHub: github.com/codervisor/lean-spec
- 文档: lean-spec.dev
- 研究: 上下文工程指南
参考资料：