我如何在 30 天内使用 Claude Code 交付 3 个生产 SaaS 后端（避免上下文丢失导致一切崩溃）
Source: Dev.to
我已经使用 Claude Code 4 个月来构建 SaaS 后端。很喜欢它。直到我不再喜欢。
你一定熟悉这个模式。
| 天数 | 发生了什么 |
|---|---|
| 1 | Claude 编写了漂亮的认证逻辑。你很受惊。 |
| 3 | 你让它添加 Stripe Webhook。 |
| 5 | 认证出错。根本不知道哪里改了。 |
| 7 | 上下文窗口已满 → 开启新会话。 |
| 8 | “等一下，我们到底用了什么数据库模式？” |
每一次。都是如此。
我最终花的时间比实际构建项目还多，都在重新解释我的项目。“健忘的天才同事” 这个比喻真的太贴切了。
上下文丢失问题
会话中漂移
Claude 从 async/await 开始，随后在 200 行后随机切换到 .then() 链。为什么？上下文退化——模型在对话增长时“忘记”了之前的模式。
模式失忆
我在第5条消息中定义了一个带有特定列的 users 表。到了第40条消息，Claude 开始建议查询不存在的列。
安全回退
在第1阶段精心设置的行级安全策略，在第3阶段添加功能时被完全忽视。
土拨鼠效应
周五合上笔记本 → 周一打开 → 在 Claude 能写出第一行代码前，需要花 30 分钟重新解释整个项目。
我尝试过的（但失败了）
- 使用完整上下文的更长提示 – 超出 token 限制；质量仍然下降。
- 自定义指令 – 过于模糊，无法在会话间持久化。
- 为每个功能单独聊天 – 丢失整体视图，破坏依赖关系。
- 手动“记忆转储” – 疲惫且容易出错。
根本问题在于：LLM 只有工作记忆，没有长期记忆。它们在当下表现出色，却在保持状态方面糟糕。
实际解决问题的办法：多‑代理编排
问题不在于 AI，而在于工作流。人类开发者也不会把整个代码库全记在脑子里。我们使用：
- 文档
- 设计文档
- 数据库模式
- API 规范
- 持久化的外部引用。
我构建了一个系统，通过 专用代理 来编排 Claude，每个代理都有全新的上下文窗口和特定的任务。
维护状态的四个文件
| 文件 | 目的 |
|---|---|
| PROJECT.md | 愿景文档 – 要解决的问题、目标用户与工作流、核心价值主张、成功标准。 |
| REQUIREMENTS.md | 可追溯的功能定义 – 唯一 ID（例如 AUTH-01、PAY-02）、v1 范围、v2 范围、超出范围、验收标准。 |
| ROADMAP.md | 分阶段执行计划 – 第 0 阶段（基础设施）、第 1 阶段（核心）、第 2 阶段（支撑）、第 3 阶段（打磨）；每个需求映射到相应阶段。 |
| STATE.md | 活文档 – 已完成的阶段（锁定）、当前阶段（可修改）、精确的数据库 DDL、API 路由（路径、方法、业务逻辑）、架构决策。 |
每个文件的大小控制在避免上下文退化的范围内（小于 10 k tokens），并且充当人类和 AI 的唯一真实来源。
Source: …
多代理系统
与其进行一次冗长的 Claude 对话，系统会生成 专门的并行代理。
研究代理（在编码前并行运行）
- Stack researcher – 为你的领域寻找最佳技术。
- Features researcher – 区分基本需求与差异化特性。
- Architecture researcher – 提出系统设计模式。
- Pitfalls researcher – 列出需要避免的常见错误。
执行代理
| 代理 | 角色 |
|---|---|
| Planner | 创建经过验证的任务计划。 |
| Executor | 通过原子提交执行计划。 |
| Verifier | 进行测试并自动调试。 |
| Mapper | 分析现有代码库。 |
每个代理都拥有全新的上下文——没有退化，也没有漂移。
工作流循环
1. INITIALIZE
• Describe vision → AI creates PROJECT.md, REQUIREMENTS.md, ROADMAP.md
2. DISCUSS (each phase)
• Shape implementation preferences before committing
3. PLAN
• Research domain patterns → create verified execution plan
4. EXECUTE
• Run plans in parallel waves with fresh contexts → atomic git commits
5. VERIFY
• User acceptance testing with automatic debugging
Repeat steps 2‑5 for each phase.关键规则： 已完成的阶段被 锁定。AI只能在 当前 阶段修改代码，彻底消除“添加支付会破坏认证”问题。
Source:
基于模板的智能
AI 知道模板中已经内置了哪些功能（认证、Stripe、Razorpay、Supabase、多租户、电子邮件、管理面板）。它只规划您领域的定制部分，这意味着：
- 零时间将认证连接到数据库
- 零时间设置支付 webhook
- 零时间构建管理面板
- 完全专注于您独特的业务逻辑
结果（我为何分享这些）
在过去的 30 天里，我使用该系统构建了 三个生产级 SaaS 后端。
| 项目 | 花费时间 | 亮点 | 早期用户增长 |
|---|---|---|---|
| 分析仪表盘 | 13 小时（4 次会话） | 自定义分析模式、带验证的数据摄取 API、时间序列计算、支持日期过滤的 CSV 导出 | 8 位付费用户 → $96 / 月 |
| 反馈小部件 | 11 小时（3 次会话） | 包含元数据的反馈模式、部件嵌入 API（iframe + script）、带过滤的管理员 CRUD、邮件通知、用于集成的 webhook 系统 | 首周 5 位注册用户 |
| 内容日历 | 9 小时（2 次会话） | 包含排期的内容模式、带基于角色访问的 CRUD API、处理时区的发布逻辑、日历视图后端 | 正在向生产环境推进 |
全部已达生产就绪，全部使用 AI 编排构建，且跨周使用持久状态。
运行它的命令
/propelkit:new-project此主命令：
- 提示 Claude 生成四个状态文件（
PROJECT.md、REQUIREMENTS.md、ROADMAP.md、STATE.md）。 - 启动研究和执行代理。
- 自动锁定已完成的阶段。
- 提供一个 CLI，用于在工作流循环中迭代。
随意将此方法适配到你自己的 LLM 驱动开发工作流中。
关于你的项目的深入问题
- 为你的领域生成研究代理
- 创建 PROJECT.md、REQUIREMENTS.md、ROADMAP.md
- 生成分阶段执行计划
- 将你交给逐阶段构建
然后对每个阶段执行
/propelkit:discuss-phase 1 # 形成你的偏好
/propelkit:plan-phase 1 # 研究 + 创建执行计划
/propelkit:execute-phase 1 # 使用并行代理进行构建
/propelkit:verify-work # 自动调试测试进入全屏模式
退出全屏模式
系统会自动维护 STATE.md。合上笔记本，几天后再回来，能够准确从上次离开的地方继续。
PropelKit – 打包系统
在第三个项目之后，我将其产品化。
您将获得
Production Next.js boilerplate（节省 100 多小时）：
- 认证（电子邮件、OAuth、会话）
- Stripe + Razorpay 支付
- Supabase（带 RLS 的 PostgreSQL）
- 多租户（组织、团队、角色）
- 积分系统（基于使用量的计费）
- 邮件模板（8 个预构建）
- 管理面板（用户管理、分析）
- 26 条 AI PM 命令
Stack: Next.js 16, TypeScript, Supabase, Stripe, Razorpay
一次性购买。 您拥有代码。构建无限产品。
AI PM 使用上述精确的多代理编排系统：持久状态、并行研究、了解模板的特性、原子提交。
Demo:（观看 AI 提问、研究、路线图生成和执行）
为什么这种方法有效
- 上下文工程 – 将文件分离，使其保持在降级阈值以下，而不是一个庞大的聊天。
- 多代理编排 – 为每个代理提供新鲜的上下文，避免漂移累积。
- 模板意识 – AI 知晓已有内容，仅构建自定义部分。
- 原子提交 – 每次提交只包含一个功能，精确回滚。
- 阶段锁定 – 已完成的代码保持不变，避免随机重写。
- 领域研究 – AI 在编写代码前先了解您的行业。
您在 AI 代码上下文丢失方面有什么经验？有没有发现其他有效的系统？