这是一个创建于 41 天前的主题，其中的信息可能已经有所发展或是发生改变。
最近用 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 ）进讨论群交流
目前尚无回复
Select Language