我用 Claude Code 将一周任务压缩到两天：复杂表单实战复盘

一个复杂的多步骤表单，原本需要我一到一周半的时间完成，使用 Claude Code 两天就上线了。关键不在于 AI 写代码更快——而是我能够专注于问题本身，把实现工作交给它。

我接到的任务是一个多步骤设置表单，包含流程分支和向后兼容性：需求文档描述了各条流程以及最终预期结果。前端技术栈是标准的 React 和 TypeScript，但这部分只在 Electron 应用内部运行。

设计稿已经由设计师提前准备好，并与产品经理确认。有几件事让这个任务看起来比实际上更复杂：

必须保留与现有流程的向后兼容性；

其中一个步骤包含一张功能运作图，它不是普通的图片或 SVG，而是页面上的一组元素及其相互之间的连线；

弹窗和表格区块需要从另一个功能中复用。粗略估计，这个任务看起来需要一周的工作量，再加上几天的检查和修复。

我首先分析了任务本身。我把准备好的需求文档复制到项目仓库根目录下的一个 markdown 文件中，然后写了一个 prompt 引用该文档，并对 AI 做了几点说明：

@docs/task.md 让我们规划一下实现方案。启动一个独立的 Explore agent 来研究代码库，如果你在代码中找不到答案，我希望你向我提问。

这花了一些时间，之后我开始实际讨论需要构建什么以及如何构建。当我不满意某个提议的答案时，我会切换到聊天模式，更深入地讨论问题。在此过程中，它问了一些最初并不明显的问题，这让我能够回头去找产品经理确认额外的需求。

当一切都澄清清楚、AI 真正理解了预期结果后，我让它把计划写成项目目录中的一个 markdown 文件——包含需求以及它对实现的看法。

为什么要这样做？因为到那时，AI 已经做了大量工作：它澄清了实现细节和边界情况，而且——不幸的是——也填满了当前上下文的大部分内容。从那里直接进入实现是不可行的。

那么，上下文的实际问题到底是什么？

上下文是 AI 一次性能够容纳的"记忆"信息量。一些当前的模型——例如支撑 Claude Code 和 Codex 的模型——起步就是 20 万 token，目前已扩展到 100 万。接近上限时，上下文需要被清除或压缩（例如，只提取接下来需要的关键点）。

填满 100 万 token 需要大量代码和很长的对话，所以听起来很让人安心。但有一个陷阱：上下文分为聪明区和糊涂区。聪明区不言自明。糊涂区是 AI 开始更多出现幻觉、犯更多错误、偶尔忘记被问了什么的地方。当你写代码时，这很重要——你不想把上下文推到那个程度，所以需要管理它。

从 AI Coding for Real Engineers 课程我了解到，糊涂区大约从 10 万 token 开始。一旦一个会话超过这个标记，出错和幻觉的概率就开始上升，而且待得越久，情况越糟。

所以任务必须被分解以适应这 10 万 token。我的规划大致就是这个思路——我稍微超了一点，最终到了约 12.5 万 token，这就是为什么我把代码库研究委托给了一个独立的 agent，而不是消耗自己的上下文。

把计划写下来并保存意味着分析不会丢失——它成为任务清单的来源，我可以用它和 AI 一起实现。

在新的会话中，我让它读取计划并准备任务清单，有一个约束条件：每个任务都必须足够完整，以至于我可以拿到正在运行的应用中去测试它。我之前文章中提过这个方法——叫做垂直切片，即单个任务触及应用的每一层：后端、数据库、UI。这就是 agent 完成后可以复现的原因。

这产生了 11 个任务，其中两个我合并到了其他任务里——它们共享一个领域层，而且足够小，不值得拆分出来。每个任务都有自己带编号和标题的 markdown 文件。

我的估计是每个任务 2-3 小时：从 Figma 读取设计、标记、对比设计稿修复、业务逻辑、遵循项目的组合和代码风格规则，再加上视觉测试以及随之而来的修正。这样加起来整个项目需要 2-3 天。

我在 Claude 的默认模式下工作，每个编辑都需要开发者审查和批准。这样我控制着每个文件编辑和每个文件创建——对照项目需求和代码风格，同时留意潜在的 bug。

每个任务我都启动一个新的干净会话：

以 @docs/task-1.md 作为任务描述并实现它。

当我不满意它的方案时，我会切换到"聊聊这个"，解释我不满意的地方以及应该怎么做。有几次 Claude 给翻译 key 起的格式不对，所以我指出来，并告诉它在后面的任务中记住这个规则，让它留在项目记忆中。

发现 Claude Code 的错误

在第五个任务中，我需要复用另一个表单的代码，那个表单在应用中创建相似的操作。我注意到 Claude 在复制部分代码，同时从另一个 feature 的私有文件夹导入组件和工具——过深地耦合了另一个功能的目录。

我中途叫停它，让它把相关文件夹和文件提升到共享层，使一切符合项目的架构。我还指出有些功能在两个地方都存在，并要求它把弹窗调用及其配置提取到一个共享文件中，让两者都能复用。

因为我是一步一步来的，所以我及早发现了这个问题——赶在需要重写大量已完成代码之前。

每个任务完成后，我都可以对照设计视觉检查表单步骤，确认它正常工作。Claude 第一次没有把间距做对，有几个地方选错了字体大小。为此，在 Figma 中启用 dev mode 并让 Claude 通过 MCP 连接到选中的节点重新检查设计会很有用——我明确告诉它间距和步骤标题的字体不匹配。

一旦我满意了，表单也按要求正常运作，我就提交所有内容，既是为了有回滚点，也是为了避免丢失已完成的工作。

每个任务的上下文使用量在 8 万到 13.5 万 token 之间。是的，有超限，部分是因为第五个任务中两个功能的重构——但总体来说这个方法效果很好。

我完成了全部 9 个任务，而且比计划略快——两天。第九个任务收尾了收尾工作：为每种语言准备翻译 key、运行测试、lint 和类型检查，以及对照任务文档中的清单过一遍几个在设计和需求中被标记的边界情况。

Code review 回来的意见很少，大部分是小的修改或者略微影响到应用其他部分的地方。总体来说代码质量保持住了。

对我来说，这是一次真正有用的体验——让 AI 全程深度参与构建，我主要扮演导师和审查者的角色。它给了你对代码的信心。AI 帮助对任务进行了扎实的分析，挖掘出特定于代码库的实现细节和细节差异。作为开发者，你设定方向并做检查，而 AI 承担工作量——这大大加快了速度。