Claude Code 如何成为最佳设计伙伴

Published on August 18, 2025

当我最初开始使用 Claude Code 时，我采用了一种幼稚的方式与其协作。我会直接在提示中描述任务，按下 Enter，然后祈祷。如果 agent 出错，我就告诉它如何修复。对于小任务来说这可能足够了，但随着任务复杂度的增加，这种方法会暴露出几个重大缺陷。

简单方法的局限

第一个问题是对话成为了关于任务的唯一真实来源。这意味着一条新消息可以覆盖旧消息中的指令，但并不总是清楚这何时会发生，这可能导致 agent 出错。

此外，agent 的上下文大小是有限的。对话越长，开头的信息就越容易被"遗忘"，即使 Claude Code 有"压缩"对话的能力来改善这个问题。

出于这些原因，我开始尝试一种我听说过的方法：让 Claude Code 从编写计划文档开始。这个文档成为真实的来源，而不是冗长的对话。当我认为计划文档足够好时，我养成了清空对话的习惯，仅用计划作为上下文重新开始。

创建初始计划

我的第一个提示通常是给 Claude Code 一个功能描述（或者它应该修复的 bug，或者应该进行的重构），包含我脑中的所有细节。如果我已经有了实现的想法，我可以给它一些指向现有文件的指针供参考。不过，我尽量不给它太多实现指令，因为我希望它提出建议并参与设计过程。

我想实现一个查询生成器。页面将分两列显示。第一列中，第一个框让用户选择一个视图（目前只有一个视图："Volume Metrics"），第二个框选择字段（"field 1"、"field 2"、"field 3"），第三个框添加筛选条件（先不填充）。右列将首先以人类可读的形式显示查询，然后显示包含查询结果的表格。（待续）

我也尽量参考以前实现的功能的现有计划。我没有正式的模板，但只要我有其他计划可以作为示例参考，我就不需要。

（继续）查看 @plans/chat-playground.md 中的前一个计划，了解路由和架构细节。（待续）

我期望在文档中看到几个关键要素。首先，对我给它的功能描述的重新表述，这有助于确保我们在需求上对齐。其次，关于功能如何实现的细节——通常它包含一些代码或伪代码，无需我明确要求。最后，要运行的命令以确保代码质量可接受，包括类型检查、linting 和测试。

（继续）在 @plans/query-builder.md 中编写计划，让我在开始实现前验证它。

协作设计过程

有时候，我对建议的实现不满意。在这种情况下，我不是更新计划，而是告诉它为什么是错的，期望它改变方法。

页面应该是 /explore 的子路由，而不是 /review。此外，它应该只对具有"admin"角色的用户可访问。

有时候经过几次来回交流后，我意识到最初建议的方法比我想到的更好。这个过程比我自己开始写代码、后来才发现方法错误要高效得多。

这有点像每次我要开始一个新功能时都在与同事讨论计划。更具体地说，这像是用一位初级同事（或对代码库了解不够的同事）来挑战我的实现计划，这位同事会质疑我的选择。这种动态让我想起了"橡皮鸭调试"技术，其中解释你的方法可以帮助你思考问题。不过，除非我特别要求，否则它不会建议根本不同的方法，而我从未尝试过这样做。

但计划文档不仅仅是实现的蓝图。我发现当 Claude Code 把它看作一份活文档时，效率会高得多。

活文档方法

关键是我不仅仅要求 Claude Code 编写计划——我还要求它在实现功能时将其作为活文档维护。我明确要求它在实现过程中更新计划，因为实现过程，特别是类型检查、linting 或测试过程，可能会发现原始计划的某些部分是不正确的。

我养成了每次提交代码时都要求它检查计划是否最新的习惯，对待计划更新的方式与运行质量检查相同。

确保计划是最新的，并提交更改。

这种活文档方法解决了 AI 开发的一个基本问题：上下文限制。有了最新的计划文档，我可以开始一个新对话，只需要求 Claude Code 继续实现。这通常效果很好——仅仅这份文档通常足以让新会话准确地从前一个会话停下的地方继续。

继续实现在 @plans/query-builder.md 中记录的内容。

当实现开始时，我会沿途审查更改以确保一切进展正确。不过，如果我对进展满意，我可以让它继续而不需要经常检查。在审查最终代码时，更新的计划文档给了我关于实现过程中所做技术选择的有用提示。

令人惊讶的是，我认为在仓促实现之前需要仔细规划我的功能这一事实让我总体上成为了一个更好的开发者。这仅仅是因为它迫使我在跳入代码之前记录实现并思考它。我也发现自己的推理表述更清楚了，因为我必须为 AI 写下来，而与同事交流时我通常是面对面或通过视频通话讨论。

这个工作流系统地解决了我在幼稚方法中遇到的基本问题：它创建了清晰的真实来源，消除了上下文限制问题，并强制进行更好的架构思考。活文档既成为规范，也成为实现日志，创建了一份完整的记录，不仅记录了构建的内容，还记录了为什么以及如何构建的。

结果是一个更深思熟虑、更有文档记录、更可靠的开发过程。

AI 不仅仅是作为实现者。

它成为了一个协作的设计伙伴。