用两个 Claude 构建 Lexio：一套真正可行的流程

开始构建 Lexio——一个个人词汇学习工具——时，我做了个刻意的选择：以两种完全不同的方式使用 Claude，而且绝不混用。

一个 Claude 负责思考，一个 Claude 负责编码。

这不仅仅是工作流上的怪癖，而是一种让开发过程保持清晰的分离。

“让 Claude 包办一切”的问题所在

用 AI 做开发最直接的方式就是把所有事情都丢给 Claude Code：描述一个功能，让它生成代码，然后重复。这确实有效，但仅限于一定程度。

不过我很快就遇到了摩擦点。写代码的时候，我不想停下来争论复习算法该用 SM-2 还是 Leitner。决策循环和实现循环在认知上是不同的任务。把它们混在同一个 Claude Code 会话里，结果就会零散而缺乏重点。

所以我把它们拆开了。

两个 Claude，两种角色

Claude Project：思考伙伴

我为 Lexio 建了一个专门的 Claude Project。所有架构和产品层面的思考都在这里进行——在写任何一行代码之前。

这个 Project 拥有完整上下文：技术栈（Rails、Inertia.js、React、shadcn/ui）、数据模型、功能路线图、我的偏好和约束。当我想弄清楚下一步该做什么时，我就来这里。

典型的对话长这样：

“我想加一个复习会话功能。针对每个词汇单独排程的 SM-2，正确的数据模型是什么？”
“这个场景下，Telegram Bot 应该用 webhook 还是长轮询？”
“我在考虑加一个审计日志。考虑到用户与词汇的交互方式，哪些字段是合理的？”

Project 会给我一个建议——不是一堆选项，而是一个带有推理过程的实际决策。一旦我同意方向，我还会再要一样东西。

关键一步：生成提示词

让这套流程真正运转起来的关键在于：我让 Claude Project 写出我接下来要在 Claude Code 里用的提示词。

不是“这是你应该构建的东西”——而是一个精确、限定范围的提示词，让 Claude Code 能毫无歧义地执行。比如这样：

“添加一个 review_sessions 表，包含以下列：[...]。创建一个 ReviewSession 模型，带有 belongs_to :user 和 started_at/completed_at 生命周期。服务对象 ReviewSession::Creator 应基于现有的 vocabularies 表实现 SM-2 调度。”

我直接将那段提示词复制进 Claude Code，不做任何改写或重述。

Claude Code：执行者

Claude Code 拿到清晰、范围明确的任务后直接执行。它负责写迁移、模型、服务对象和测试。我审阅输出，然后提交。

因为决策早已完成，我在审阅代码时不需要评估架构，只需确认实现与意图一致。

实际应用中的样子

构建 Lexio 的 OCR 功能就是一个很好的例子。该功能让用户拍摄文字照片，并通过 Claude 的视觉 API 从中提取词汇。

在项目阶段，我们讨论了集成方式：OCR 应该是同步的 Rails 控制器操作，还是异步任务？最终我们决定 MVP 阶段采用同步方案——更简单，而且对个人工具来说延迟可以接受。项目阶段还提出了合适的抽象：一个封装 Claude API 调用的 VocabularyExtractor 服务，让控制器保持精简。

在 Claude Code 阶段，我粘贴了生成的提示词：构建具有特定接口的 VocabularyExtractor，将其集成到 PhotosController#create 操作中，并优雅处理 API 错误。Claude Code 一次就生成了可运行的代码。

我在阅读代码时不需要思考架构问题，架构工作已经完成了。

诚实的权衡

这套工作流并非毫无摩擦。有几件事值得了解：

代码风格不会是你自己的。 Claude Code 写出的代码干净、功能完整——但它有自己的风格。变量命名、服务对象的结构、验证逻辑的放置位置。有时符合我的偏好，有时不符合。我已经学会接受这一点，只去修正那些长期来看真正重要的问题。

它比看起来要慢。 “项目 → 提示词 → 代码 → 审阅”这个循环比直接自己写代码步骤更多。速度的提升来自不会卡住，而不是原始的编码速度。对于时间有限的独立开发者来说，这个权衡是值得的。

你仍然需要理解你在构建什么。 Claude Code 不能替代工程判断。项目中的思考步骤不是可选的——它是在你花时间实现之前验证方法的地方。如果你跳过它，让 Claude Code 也来搞定架构，你会得到不一致、拼凑起来的代码。

为什么要把它们分开？

有人可能会合理地问：为什么不直接用 Claude Code 做所有事情？它也能讨论架构。

诚实的回答是，我发现上下文混合会降低质量。当 Claude Code 正在写迁移时，我不希望它同时重新考虑数据模型。保持一个独立的项目，包含完整的产品上下文，意味着“思考”的 Claude 拥有它所需的一切来好好推理——功能历史、设计约束、我的偏好。“编码”的 Claude 得到一个狭窄、精确的任务。

这和优秀工程团队将规划与执行分开是同一个原因。不是因为同一个人不能两者兼顾，而是因为中途切换模式代价高昂。

我会对刚开始的人说什么

如果你正在用 AI 辅助构建个人项目：

先设置一个项目。给它关于你的技术栈、数据模型和偏好的上下文。把它当作一个你可以与之大声思考的技术联合创始人。

当你准备好构建某样东西时，不要直接去找 Claude Code。在项目中花十分钟：你在构建什么，为什么，以及它的正确形态是什么？然后让项目为你写一个提示。

把那个提示复制到 Claude Code。根据规格审查输出，而不是凭直觉。

这种分工听起来像是额外开销。实际上，它是连贯代码和上下文切换拼凑之间的区别，后者会让你花几周时间理清。

---

*Lexio 是我用 Rails、Inertia.js 和 React 构建的个人词汇学习工具。这篇文章是关于用 AI 辅助构建个人项目的持续系列的一部分。*