关键词：大模型上下文窗口、200K、1M Context、Figma to Code、AI 编排、长任务、幻觉、注意力稀释
作者：一个每天和 AI 一起写业务代码的前端 er
更新时间：2026-07
前言：这不是一篇技术布道文，而是一份"苦主"证言
如果你和我一样，是一个把 Claude Code、Cursor、Copilot 深度嵌入日常工作流的开发者，那你一定或多或少遇到过下面这些场景：
- 让 AI 跑一个"流程性"任务（比如从 Figma 生成一个完整页面），跑到一半开始胡编乱造，凭空出现设计稿里没有的组件；
- 让 AI 连续修改 5 个文件，改到第 3 个的时候，它已经忘了第 1 个文件里定义的变量名，直接自己"发明"了一个；
- 一个稍微复杂点的重构任务，AI 前面还在遵循你的约定，后面就开始放飞自我，把项目里禁止的写法一股脑写回来；
- 更离谱的是：明明上下文窗口标称 200K tokens，但你会发现，跑到 30%~50% 的时候，AI 就已经开始失忆了。
作为一个每天靠 AI 提效的开发者，我不得不承认一件事：
200K 上下文，对于"长任务、连贯任务"来说，是远远不够的。
这篇文章想聊三件事：
- 200K 上下文到底困扰了我们什么？
- 我目前的"人肉编排"解法长什么样？
- 已经出现的 1M（以 M 为单位）大模型，会解决长任务的困局吗？
一、被"200K"困住的日常：三个真实场景
场景一：Figma to Code —— 越到后面越像"抽象派"
Figma 生成代码是我用得最频繁、也是翻车最频繁的场景。
一个中等复杂度的页面，Figma 节点树 + 设计变量 + 组件映射 + 项目约束（比如我们项目要求 750 设计稿 + px 自动转 vw、antd-mobile v2、MobX 只在页面级使用等），随随便便就把上下文吃到 100K+。
于是就出现了非常经典的翻车链路：
| 阶段 | AI 表现 |
|---|---|
| 开始阶段（0~30%） | 严格按设计稿 1:1 还原，规范全部遵守 |
| 中段（30%~60%） | 开始"简化"设计稿，说是"合理省略" |
| 后段（60%~90%） | 凭空发明组件、忘掉字体权重、颜色开始瞎编 |
| 收尾（>90%） | 直接"我给你写个骨架，剩下你自己补完" |
最气人的是最后一步：AI 不是不会写，是"记不住"要写了。
它记得任务的开头（页面结构），记得任务的结尾（要输出代码），但中间那些设计稿的具体像素、颜色、字号、间距，就在长上下文里被"稀释"掉了。
这不是模型能力问题，这是注意力在长序列上被摊薄的问题。
场景二：流程性任务 —— 前面严丝合缝，后面全线崩塌
我们项目有一套非常严格的开发规范（团队沉淀在 CLAUDE.md + .claude/rules/ 里，大概 3~5K tokens），比如：
- 禁止使用 class 组件
- 禁止业务组件用 MobX
- 禁止 antd-mobile 5.x
- 禁止手写 vw
- 命名必须小驼峰 + Container 后缀
单文件任务下，AI 遵守得非常好。
但一旦你让它做一个多步骤、流程性任务——比如"帮我把 A 模块从旧架构迁移到新架构"——就会看到很典型的"规范衰减"：
- 第 1 个文件：完美，教科书级规范；
- 第 2 个文件：还行，偶尔有一两个小瑕疵；
- 第 3 个文件：开始出现 class 组件、observer HOC；
- 第 4 个文件：直接引入项目不存在的依赖，命名风格换成了中划线。
我一度怀疑是模型能力退化，后来才意识到：是规范文本在长上下文里的"权重"被后面的代码内容压低了。
模型不是不知道规则，而是"想不起来"规则。
场景三：Debug 长链路 —— 越 Debug 越乱
调试一个复杂 Bug，往往需要贴：
- 报错栈
- 相关的 3~5 个文件
- 相关的接口定义
- 相关的业务背景
一路读下来，很快 100K+。
然后你让 AI 修，它会给你一个看起来很合理、但完全没抓住重点的方案。
因为在这么长的上下文里，AI 已经没法精确地把"这一行报错"和"那个文件里的某个 useEffect"关联起来了。
它记得"有这个东西"，但记不清"这个东西在哪、长什么样"。
二、我目前的"人肉编排"解法：领域拆分 → 宏观编排 → 原子任务拆分
既然 AI 在长任务上会失忆，那能不能不让它做长任务？
这就是我目前主要在做的事——人工任务编排（Human-in-the-loop Orchestration）。
不同于"把大任务简单切成小任务"的朴素思路，我在实践中沉淀出的是一套三层递进的编排方法：
领域拆分 → 宏观编排（人工控制领域的执行步骤） → 原子任务拆分
一句话概括：先按"领域"划出边界，再由人来控制领域之间的推进节奏，最后每个领域内部再拆成 AI 一次能吃下的原子任务。
2.1 第一层：领域拆分（Domain Split）
领域拆分做的是空间维度上的解耦——把一个大任务按"业务边界"切成几块，每一块自成上下文。
以 Figma 生成一个完整页面为例，我不会把整页当作一个"领域"，而是按页面模块把它切开，每个模块就是一个独立领域。
一个典型的金融理财详情页，我会拆成这样几个模块：
- 头部导航模块：Header、返回、标题、右上角操作
- 产品信息模块：产品名、收益率、风险等级、标签
- 收益图表模块：走势图、时间维度切换
- 交易操作模块：买入 / 卖出 / 定投按钮、金额输入
- 底部说明模块：风险揭示、协议、客服入口
关键原则：不同模块不共享上下文。
- 做"收益图表模块"的会话里，只加载图表相关的 Figma 节点、图表相关的组件库、图表相关的数据结构；
- 做"交易操作模块"的会话里，完全不需要知道图表是怎么画的、颜色是什么。
这一步的价值在于——让每个模块的上下文都保持"干净"，避免 AI 在做 A 模块的时候被 B 模块的信息干扰、稀释、甚至串味。
⚠️ 一个反直觉但很重要的点：模块拆分要按 "AI 能一次吃下" 的粒度来切，而不是按 "设计稿分了几个 Frame" 来切。 有时候设计稿是一个大 Frame，但里面有 5 个模块——你要自己再切；有时候设计稿分了 10 个 Frame，但其中 3 个可以合并——你也可以合。拆分粒度的判断权在你手上，不在设计稿手上。
2.2 第二层：宏观编排（Macro Orchestration）—— 由人来控制
领域拆分之后的排序层，只回答一个问题：
这些领域模块，先做什么？后做什么？
它不产出任务描述，只产出顺序。是连接"领域拆分"与"原子任务喂给 AI"之间的调度层。
排序原则
- 基础先行 —— 规范、路径别名、通用工具、Service 封装
- 公共优先 —— 全局 Store、公共组件、公共 Hooks（被多处依赖的先做）
- 业务后置 —— 具体业务模块按依赖顺序推进
- 风险前置 —— 高不确定性 / 高风险模块提前验证，降低返工成本
三层边界
| 层级 | 关注点 | 输出物 |
|---|---|---|
| ① 领域拆分 | 有哪些模块 | 模块清单（横向切分） |
| ② 宏观编排 | 先后顺序 | 有序施工路线（纵向排序） |
| ③ 原子任务 | 每步做什么 | 可喂给 AI 的最小任务单元 |
典型编排（Figma to Code）
Phase 1 基础层 → 设计规范落地 / vw 转换 / 路径别名 / Service 封装
Phase 2 公共层 → 全局 Store 骨架 / 公共组件 / 公共 Hooks / 业务组件
Phase 3 业务层 → 头部导航 → 产品信息 → 收益图表 → 交易操作 → ...
为什么由人来排？ AI 的规划能力不足以稳定地跨领域调度：让它自己决定顺序会一把梭，让它自己传递中间态会在长上下文里丢关键约束。所以我扮演"调度器"，AI 扮演"工作节点"。
每完成一个模块就清空上下文，下一个模块从零开始。跨模块之间只传"接口契约"，不传实现细节。这样即使跑 10 个模块，AI 也不会"越跑越糊涂"。
代价是——开发者从"甩需求的人"变成了"控制流水线的人"。这是当前 200K 时代下，我认为唯一能稳定产出的方式。
2.3 第三层：原子任务拆分（Atomic Task Split）
即使切到了单个领域，一次任务往往还是太大。所以在每个领域内部，我会再做一层时间维度上的切分——把领域任务拆成"原子任务"，喂给 AI 时一次只做一件事。
原子任务的三条判定标准：
- 单次上下文控制在 30K 以内（经验值，超过就开始明显衰减）；
- 有明确的输入 / 输出契约（比如"输入 Figma 节点 A，输出 JSX 文件 A"）；
- 产出可独立验证（不依赖后续任务才能判断对错）。
例如在"收益图表模块"内部，我会继续拆成：
原子 1: 生成图表容器骨架（只关心结构，不关心样式）
原子 2: 时间维度切换 Tab（独立子组件，一次会话）
原子 3: 图表本体（对接 ECharts / 项目已有图表组件）
原子 4: 样式对齐（只看样式，不看逻辑）
原子 5: 该模块的 MobX Store（只看状态，不看视图）
每一个原子任务的上下文都在可控范围，AI 的表现直接从"薛定谔"变成了"稳定输出"。
2.4 我的编排工具箱
支撑上面这三层的具体工具：
- Sub Agent：承载"领域"这一层，每个 Agent 有独立上下文，职责单一（前端开发、代码审查、安全审计、性能分析各一个）；
- Skill / Slash Command：承载"原子任务"这一层，把高频原子操作沉淀为可复用 Prompt（
/figma-to-code、/dev、/review、/audit）； - 规范常驻：
.claude/rules/*.md通过CLAUDE.md常驻上下文，保证每次对话都遵守团队规范（约 3~5K tokens，一次性成本换全局一致性）； - 决策外置：
FADR.md（技术） /BADR.md（业务），按需 Read； - 代码索引（CodeGraph 等）：把"读一堆文件"变成"查一个索引"，一次调用替代 N 次 Read。
2.5 这套方法的收益与代价
收益：
- AI 幻觉率显著下降（每个原子任务上下文都在可控区间）；
- 规范遵守率显著提升（规范只在需要的领域加载，权重不会被稀释）；
- 出问题时定位极快（哪个领域出问题就回炉哪个，不用重跑整个任务）。
代价：
- 我作为开发者，花了大量时间在做编排、做 Prompt、做工具链；
- 需要前期投入建立 Agent / Skill / 规范外置的基础设施；
- "AI 帮我一键搞定"的幻想，变成了"AI 是我流水线上的一个工位"的现实。
但坦白讲——这是目前 200K 时代下，我找到的最稳的解法。
三、当 M 时代来临：1M 上下文会是银弹吗？
截止到 2026 年 7 月，市面上已经有一批标称 1M（1,000,000 tokens） 上下文的模型陆续放出：
- Claude / GPT 系列的长上下文版本也陆续跟进；
- 国内厂商也在快速推进百万级上下文。
但普及度远远谈不上。原因很直白：
- 贵：Token 数量翻 5 倍，成本不是线性增长，是服务端 KV Cache + 显存的指数级压力；
- 慢：长上下文的 Prefill 阶段耗时肉眼可见地增加；
- 未必"真长"：很多模型标称 1M，但有效注意力窗口远达不到 1M（业内俗称"上下文虚标"）。
3.1 1M 上下文能解决"长任务困局"吗？
先说结论：能缓解一部分，但不能根治。
✅ 能解决的部分
- 一次性塞入整个项目规范 + 决策文档 + 代码库切片 变得可行；
- Figma 大文件 + 完整设计系统 + 项目组件库 可以一次性喂进去；
- 多文件重构不再需要来回切换上下文；
- 长对话记忆得到显著改善。
❌ 不能解决的部分
- **"注意力稀释"**是 Transformer 架构的固有问题。即使窗口是 1M，模型对"上下文中段"的信息利用率依然远低于头尾。这就是著名的 "Lost in the Middle" 问题；
- 规范衰减依然存在：当代码内容占 900K，规范占 5K 时，规范的"注意力权重"被稀释得更严重；
- 幻觉在长任务尾部依然高发：越靠后生成的 token，累积的偏差越大；
- 成本决定使用频率：一个每次调用要付 5 倍成本的模型，你会舍得用它做日常代码任务吗？
3.2 我的判断：M 时代 ≠ 编排消失，而是编排升级
上下文窗口从 200K 涨到 1M，不是让开发者不再需要编排，而是让编排的粒度变粗。
- 200K 时代：每个子任务 30K，一个页面拆 5~10 步；
- 1M 时代：每个子任务 200K，一个页面拆 1~3 步；
- ∞ 时代（如果有）：整个项目一次性喂进去？—— 但这时候瓶颈不在窗口，而在模型的规划能力和自我纠错能力。
换句话说：上下文长度只是解决了"记得住"，但没解决"想得清"和"做得对"。
四、给开发者的三条实用建议
不管你现在用的是 200K 还是 1M，下面这三条经验都值：
1. 把"规范"从对话上下文里剥离出去
- 项目规范放
.md文件，让 AI 按需读取； - 用 Slash Command / Skill 封装高频流程，Prompt 里只写差异部分；
- 用 Sub Agent 做职责隔离，每个 Agent 只加载自己领域的规范。
2. 把"长任务"当成"流水线"，不是"一次调用"
- 明确每一步的输入 / 输出；
- 中间态落盘（JSON、Markdown、代码文件），不要靠对话记忆；
- 每一步的上下文尽量控制在 30K~50K，即使你用 1M 模型也是这样。
3. 把"代码上下文"从 Read 换成"索引查询"
- CodeGraph、Sourcegraph、Serena 之类的代码索引工具，能把"读 10 个文件"变成"查一次符号"；
- 不仅省 Token，还省时间，还更准。
五、结语：我们不是在等待更长的窗口，而是在等待更聪明的编排
这几年 AI Coding 工具的进化史，某种程度上就是上下文管理的进化史：
- 从最初的单文件补全（Copilot）；
- 到多文件对话（Cursor / Claude Code）；
- 到长上下文 + Agent 编排（现在）；
- 再到未来的 M 时代 + 深度规划能力。
上下文窗口的增长会持续，但"如何用好上下文"永远是开发者的能力体现。
200K 的困扰不会因为 1M 消失，只会换一种形式出现。而作为开发者，最有价值的资产，永远是你对任务的拆解能力、对上下文的组织能力、对 AI 输出的判断能力。
模型会不断变强，但**"人工编排"这件事，短期内不会失业**。
甚至我想说：一个懂编排的开发者 + 一个 200K 模型，往往比一个只会甩需求的开发者 + 一个 1M 模型跑得更快、更稳。
附：我目前的日常工作流截图（文字版）
┌──────────────────────────────────────────────────────┐
│ 用户需求（自然语言） │
└──────────────┬───────────────────────────────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 主 Claude（调度层） │
│ - 判断任务类型 → 路由到对应 Agent / Skill │
│ - 只做编排，不写业务代码 │
└──────────────┬───────────────────────────────────────┘
▼
┌────────────┬─────────────┬────────────┬──────────────┐
│ 前端 Agent │ 审查 Agent │ 性能 Agent │ 安全 Agent │
│ (改代码) │ (只读评审) │ (只读分析)│ (只读审计) │
└────────────┴─────────────┴────────────┴──────────────┘
▼
┌──────────────────────────────────────────────────────┐
│ 外置知识源（按需加载） │
│ - .claude/rules/*.md （团队规范） │
│ - FADR.md / BADR.md （技术/业务决策） │
│ - CodeGraph 索引 （代码结构） │
└──────────────────────────────────────────────────────┘
如果你也有类似的踩坑经历、或者更好的编排思路，欢迎评论区交流。
