从 20 万到 100 万：Claude Opus 4.6 如何在一夜之间改变我的 AI 开发工作流
Source: Dev.to
A follow‑up to 我实际使用的 AI 开发工作流
我在几周前写过我的 AI 开发工作流。使用 Task Master 处理结构化任务，使用 Context7 查看当前文档，在新聊天之间交接文档，在编码前获取多个 AI 视角。该工作流已经交付了可运行的软件。
今天，这个工作流中一个重要部分变得可选了。
Claude Opus 4.6 于 2026 年 2 月 5 日 在 Cursor 中发布，拥有 100 万 token 的上下文窗口。我已经使用 Opus 4.5（其 20 万 token 限制）好几个月了。一次性跳到 100 万并不是一个渐进的改进——它改变了单次对话中可能实现的内容。
下面是我在真实项目中测试时发生的情况。
项目：ironPad
ironPad 是一个 本地优先、基于文件的项目管理系统，我在使用 AI 构建它。这是一个真实的应用，而非演示。
| 层 | 技术 |
|---|---|
| 后端 | Rust, Axum 0.8, Tokio, git2, notify（文件监视） |
| 前端 | Vue 3, Vite, TypeScript, Pinia, Milkdown（所见即所得编辑器） |
| 数据 | 普通 Markdown 文件，带有 YAML 前置元数据 |
| 实时 | WebSocket 同步 UI 与文件系统之间 |
代码库包含 ≈ 80 个文件，分布在后端和前端——足以超过 200 K 令牌的上下文限制。
Source: …
旧方式：200 K 上下文
使用 Opus 4.5（200 K 令牌）时，我的工作流程如下：
- 将大型功能拆分为 3‑5 个任务——AI 一次只能处理少量文件。
- 在每次聊天之间编写交接文档——这样下一次会话就能了解之前发生了什么。
- 仔细挑选要展示的文件——无法一次加载全部，我会挑选最相关的 3‑5 个文件。
- 每次会话都重复上下文设置——粘贴交接文档、重新解释架构、指向正确的文件。
它能工作；我也成功交付了功能。但交接系统增加了摩擦——这是受限于上下文容量的权宜之计。
Image: AI context
Source: …
新方式：1 M 上下文
今天我打开了一个全新的 Opus 4.6 对话，并说：
“把整个代码库加载到你的上下文中并进行分析。”
仅此而已——没有挑选文件，没有交接，没有前言。AI 随即：
- 列出整个项目结构——每个目录、每个文件。
- 读取每个源文件——所有 Rust 后端代码、所有 Vue 组件、store、配置、文档。
- 同时持有全部内容——约 80 个文件、数千行代码、两种语言、多种框架。
随后我问：
“有什么 bug 或者可以改进的地方吗？”
它发现了什么
AI 在整个代码库中识别出 16 条问题——需要理解多个组件交互的深层跨文件 bug。
真正的 bug
| # | 描述 |
|---|---|
| 1 | 自动提交静默失效——后台任务检查 pending_changes 标志，但从未有代码将其设为 true。自动提交从不触发。需要阅读 main.rs、git.rs 以及所有路由处理器。 |
| 2 | JavaScript 运算符优先级 bug——remote.value?.ahead ?? 0 > 0 先计算 0 > 0，导致推送/拉取按钮始终显示错误状态。 |
| 3 | 端口绑定竞争条件——服务器检查端口是否可用后丢弃连接，再次尝试绑定。期间其他进程可能抢占该端口。 |
| 4 | 自己的保存会触发 “外部编辑” 对话框——八条写入路径中只有一条调用 mark_file_saved()。文件监视器检测到应用自身的保存后弹出 “文件已在外部更改，是否重新加载？” 对话框，影响任务和项目的保存。 |
架构改进
- 三个路由文件中非原子写入可能导致数据损坏。
confirm()阻塞 UI 线程。- WebSocket 重连使用固定延迟，而非指数退避。
- 任务解析逻辑重复 120 行。
- 缺少 CORS 中间件。
- 资产接口缺少路径遍历验证。
- 生产代码中残留
console.log调试语句。
它修复了什么
我说：
“请把这些都修好。”
在一次会话中，AI：
- 将自动提交系统改写为每 60 秒尝试一次提交（现有的
commit_all()已能优雅处理“无更改”情况）。 - 通过直接返回
TcpListener而不是先丢弃再重新绑定，修复了端口绑定问题。 - 将
atomic_write()设为公共并让所有写入路径使用它（这也自动解决了mark_file_saved()的问题）。 - 添加了 front‑matter 辅助函数并去除任务解析代码的重复。
- 用非阻塞的通知横幅替代了阻塞的
confirm()。 - 添加了 CORS、路径校验以及 WebSocket 重连的指数退避。
- 修复了运算符优先级 bug。
图：Bug‑fixes 图表
结果： cargo check 通过。前端零 lint 错误。共修复 14 条问题；另外 2 条故意延后（一次大型库迁移以及跨文件的一个小常量重复）。
所有这些都在 一次对话 中完成——在旧的 200 K‑token 限制下，这本需要数十次交接才能实现。
实际改变了什么
之前：交接成本
在 200 K token 的上下文中，每个更大的任务或更改都会产生额外开销，我们必须将其拆分为多个独立任务。该开销是约束的代价。良好的交接系统可以让它变得可管理，但从来不是免费的。
之后：直接工作
在 1 M token 的上下文中，完整的代码库审计如下所示：
Time for entire audit + fixes:
Loading codebase: ~2 min (AI reads all files)
Analysis: ~3 min (AI identifies 16 issues)
Fixing all issues: ~15 min (AI applies all fixes)
Verification: ~1 min (cargo check + lint)
Total: ~20 min
Overhead: ~0 min如果使用 200 K 的上下文，同样的工作将需要 5+ 次独立会话，每次都需要自己的交接，并且只能看到一次性可见的文件。一些跨文件的 bug（例如自动提交问题）可能永远也找不出来，因为没有任何一次会话能够同时拥有 main.rs、git.rs 以及所有路由处理程序的上下文。
这会终止交接工作流吗？
不。 它只是根据需要改变时间。
仍然有价值
- 与需要了解你所做工作的合作伙伴协作
- 为未来的自己记录决策
- 超过 1 M 令牌的项目
不再必要
- 为了适应上下文而将功能拆分为人为的微任务
- 在紧密相关的任务之间编写交接文档
- 精心挑选 AI 能看到的文件
- 每次会话都重新解释架构
交接系统从“每个任务都必需”转变为“在会话边界上有用”。这是一个巨大的转变。
更广泛的模式
我在构建 ironPad 时注意到，每一次 AI 能力的跃迁不仅让已有任务更快，还能实现之前不切实际的任务。
- 完整代码库审计 在 200 K 时并不实际。你可以审计单个文件，但要找出跨整个系统的 bug 需要人工手动追踪文件间的关联，然后把它们描述给 AI。现在 AI 能看到所有内容。
- 跨切面重构 在 200 K 时并不实际。要在六个文件中更改原子写入的方式，同时更新文件监视器集成并确保 front‑matter 辅助函数在所有地方可用，当你能看到所有文件时，这是一项统一的改动。在 200 K 时则需要 3‑4 次会话，且有不一致的风险。
- 架构层面的推理 在 200 K 时并不实际。auto‑commit bug 就是一个完美的例子：
AutoCommitState在main.rs中创建，mark_changed()方法存在于git.rs，但没有任何路由处理器能够访问它。完整地理解从 HTTP 处理器到服务层的请求流在加载整个代码库时变得轻而易举。
ironPad 的下一步计划
该项目是开源的；我在 GitHub 上 30 分钟前 发布了它。
我们还将采用 开放方法——不仅是代码，还是整个过程：每个功能是如何使用 AI 构建的、哪些提示有效、哪些无效，以及工作流是如何从 200 K 上下文演变到 1 M 上下文的。
因为工具在不断变得更好，但正确使用它们的过程仍然很重要。如果你不知道该提出什么请求，1 M 的上下文窗口也帮不上忙。
亲自尝试
今天有效的核心要点：
- 加载全部。 不要挑选文件。让 AI 看到完整的全貌。
- 先提开放性问题。 先问“哪里出错了？”再问“修复这个具体问题”。AI 发现了我之前不知道的 bug。
- 让它分批工作。 AI 在一次会话中修复了 14 个问题，因为它能看到它们之间的所有依赖关系。
- 机械化验证。
cargo check和 lint 工具比逐行阅读更快地确认正确性。 - 在会话边界保持结构化工作流。 交接和 PRD 对于小任务和大项目仍然重要；但现在不需要在每个微任务之间都进行。
上下文窗口从一个需要规避的限制，变成了可以填满整个项目的空间。这改变了游戏规则。
ironPad 正在公开构建。关注 GitHub 上的项目：