为什么你的 AI Coding Agent 越用越笨？这款工具能帮到你！

最近用 SDD （ Spec-Driven Development ）方法实践 AI 辅助开发，遇到了一个诡异的问题：

和 AI 协作写了详细的技术规范（ 2000 行），让 Cursor/Copilot 基于这些规范工作，上下文窗口完全够用。但 AI 开始：

• 建议我在规范中明确排除的方案
• 反复问已经回答过的问题
• 生成与设计决策矛盾的代码

问题不在上下文大小，而在上下文质量。

研究数据很残酷

• Databricks 研究：即使远未达到上限，长上下文也会导致性能显著下降
• 伯克利函数调用排行榜：给 AI 更多选项 = 更多困惑 = 更低准确性
• 实际结果：2000 行规范比 300 行规范的处理成本高 6 倍，但输出质量更差

讽刺的是：你写详细规范帮助 AI ，但细节却让 AI 变笨。

解决方案：上下文工程（ Context Engineering ）

四个实用策略：

1. 分区（ Partition ） - 拆分大文档，只加载需要的部分

specs/dashboard/README.md          (200 行 - 概述)
specs/dashboard/DESIGN.md          (350 行 - 架构)
specs/dashboard/IMPLEMENTATION.md  (150 行 - 计划)
# AI 只读它需要的，不是全部 1200 行

2. 精简（ Compact ） - 删除重复和可推断内容

# 之前：300 行解释 JWT 的好处
# 之后：使用 JWT 令牌（无状态，无会话存储）

3. 压缩（ Compress ） - 总结已完成的工作

# 之前：50 行详细步骤
# 之后：✅ 第 1 阶段完成（见提交 abc123 ）

4. 隔离（ Isolate ） - 将独立功能拆分为单独的规范

实战结果

我们用这套方法构建了 LeanSpec 本身：

• 10 天从零到生产（ CLI + MCP 服务器 + 文档站）
• 实现了 60+ 个规范

中途违反了自己的原则：规范增长到 1166 行

• AI 开始破坏规范
• 代码生成不可靠
• 响应速度变慢

应用上下文工程后：拆分为 378 行以下

• AI 再次可靠
• 更快迭代
• 准确输出

开始使用

npm install -g lean-spec
cd your-project
lean-spec init
lean-spec create user-authentication

LeanSpec 提供：

• 源于真实约束的方法论
• 检测和修复上下文问题的工具
• 从个人到企业的扩展能力

底线：你的 AI 工具只有你给它们的上下文好。2000 行规范即使装得下，也会比 300 行规范产生更差的结果。

---

GitHub: https://github.com/codervisor/lean-spec
文档: https://lean-spec.dev

对 LeanSpec 和 SDD 感兴趣的小伙伴，欢迎加微信 tikazyq1（请注明 lean-spec ）进讨论群交流 👇