你有没有经历过这种落差？刚开新对话时 AI 写出的代码干净利落，但随着对话变长，它开始犯低级错误、重复之前已修复的问题，甚至提出明显不合理的方案。
这不是你的错觉。Matt Pocock 用一句话解释了这个现象：LLM 存在「聪明区间」和「笨拙区间」。理解这个机制，是高效使用 AI 编程的前提。
核心机制：聪明区间 vs 笨拙区间
对话开始阶段。上下文干净，注意力关系清晰，模型能做出精准判断，代码质量最高。
对话后期。上下文膨胀，注意力关系呈平方级增长，模型判断力显著下降，容易做出愚蠢决策。
无论模型宣称支持 200k 还是 1M 上下文，关键转折点始终在 约 100k tokens 附近。超过这个阈值，增加更多上下文不会带来更好结果，反而会让模型更「糊涂」。
「每增加一个 token，就像往足球联赛里增加一支球队——比赛场次呈平方级增长。注意力关系也是如此。」
这对工作流意味着什么
知道了衰减规律，行动策略就清晰了：
规划优先于执行
把需求拆分成独立小任务，每个任务单独开对话完成，保持全程处于聪明区间。
工程基本功依然关键
AI 不是魔法。模块化、单一职责、清晰接口——这些原则对 AI 和人类同样重要。
上下文管理是核心技能
学会精简上下文、及时开启新对话、用文件而非对话传递信息，这比提示词技巧更重要。
具体做法
- 任务拆分：将大功能拆成可独立实现的小模块
- 对话轮换：一个任务完成后，开新对话处理下一个
- 文件中转：用 spec 文档和代码文件传递状态，而非在对话里累积
- 及时重置：感觉 AI 开始「犯糊涂」时，果断开新对话
关键洞察
这场工作坊的核心论点可以概括为一句话：AI 编程的瓶颈不在模型能力，而在我们如何组织工作。
软件工程 fundamentals——抽象、封装、模块化、清晰接口——这些帮助我们与人类协作的原则，同样适用于与AI协作。甚至更为重要，因为 AI 不会疲惫，但也无法像人类那样主动澄清模糊之处。
Pocock 提出的工作流框架包含三个层次：
- Planning：写 spec，定义范围，拆分任务
- Execution：在聪明区间内快速实现
- Production：代码审查、测试、部署
其中 Execution 阶段最容易陷入「速度幻觉」——让 AI 狂写代码看起来很高效，但如果缺乏前期规划，后期在笨拙区间修复问题的成本会吞噬所有节省的时间。
行动清单
保持短小
单个对话控制在 100k tokens 以内
先规划后编码
写 spec 再动手，避免反复返工
善用新对话
任务完成就重置，别拖长战线
最后记住这三件事
别把长对话当资产
很多人舍不得重开，是因为觉得上下文越多越值钱。Pocock 的判断正好相反，长对话常常是质量开始下滑的信号。
真正的提效，不是让 AI 一口气写更多
真正的提效，是把问题切小、把接口讲清、把高质量判断留在前半程。速度只是结果，不是方法。
软件工程基本功没有过时，反而更值钱了
当 AI 成为协作者后，模块化、边界感、清晰契约不再只是“代码整洁”，而是决定协作质量的底层设施。
如果只带走一句话，那应该是：别把 AI coding 理解成“让模型替你写更多代码”，而要把它理解成“重新设计你的工作流，让模型长期停留在聪明区间”。