AI Coding 工作流：从规划到生产

许多人使用 AI 编程时都有相似体验：刚开始的对话质量极高，模型似乎"理解一切"；但随着对话深入，它开始做出愚蠢决定、重复错误、甚至遗忘之前确认过的需求。Matt Pocock 认为，这不是模型能力问题，而是上下文管理问题。

Smart Zone

聪明区

对话初期，注意力关系最不紧张。模型能建立清晰的 token 间关联，做出高质量决策。

~0-100k tokens

Dumb Zone

笨拙区

随着 token 累积，注意力关系呈指数级复杂化。模型开始"变笨"，做出次优甚至错误决策。

~100k+ tokens (约 40% 衰减点)

核心洞察：上下文即认知预算

Pocock 借用 Dex Hy 的"Human Layer"概念，指出 LLM 存在一个关键认知边界。每次添加 token，就像往足球联赛增加一支球队——比赛场数呈二次方增长。注意力机制需要维护的 token-to-token 关系急剧膨胀。

~100k 衰减点

新对话（高质量）长对话（质量衰减）

有趣的是，这个边界与模型宣称的上下文窗口大小无关——无论是 200k 还是 1M tokens，质量衰减都发生在约 40% 处（约 100k tokens）。这是架构层面的固有限制，而非工程问题。

在 Smart Zone 内完成架构规划和关键决策，不要浪费高质量认知预算在琐碎实现上。

软件工程的核心原则——模块化、接口设计、单一职责——在 AI 时代反而更加关键，它们是上下文管理的基石。

未来的开发者竞争力不在于提示词技巧，而在于如何设计对话结构、何时重启对话、如何组织代码以降低认知负载。

当我们谈论 AI 是一个新范式时，我们忘记了软件工程基础——那些对人类协作至关重要的原则——在 AI 协作中同样有效，甚至更加重要。

— Matt Pocock

在打开 AI 工具前，先用传统方法梳理需求、边界条件和验收标准。清晰的输入是高质量输出的前提。

用全新的对话窗口讨论高层设计。此时模型处于 Smart Zone，最适合处理抽象问题和权衡取舍。产出：接口定义、模块边界、数据流图。

为具体模块开启独立对话，携带精简后的上下文（仅接口定义，无关实现细节）。保持每个对话在 Dumb Zone 之前结束。

用新鲜对话审查代码，不带实现时的历史包袱。模型能发现之前"看不见"的问题。

关键原则： 每个对话都有"保质期"。当感觉模型开始"变笨"——重复错误、遗忘约定、提出明显糟糕的解决方案——就是开启新对话的信号。不要试图在长对话里"修复"它的状态。

这种工作流对代码组织提出了新要求：

如果模块间耦合严重，就无法在独立对话中实现它们。AI 友好的代码结构首先是人类友好的结构。

清晰的接口定义是跨对话协作的基础。TypeScript 类型、API 契约、数据 Schema 成为比注释更重要的沟通媒介。

传统文档面向未来维护者，AI 工作流中的"文档"首先面向当下的 AI 协作者——需要更高的精确性和完整性。