我用Claude Code开发踩过的坑：一套防止AI「失忆」

我用Claude Code开发踩过的坑：一套防止AI「失忆」的项目管理SOP

一、一个真实的踩坑故事

今天让Claude Code做了3个前端样式，选了第三个开始开发。开发到一半，我发现对话框的签文无法显示，debug了6个小时。

回来后让Claude继续开发，结果它说：「请告诉我需要开发什么功能。」

我当时整个人都懵了。这才意识到，Claude的「记性」真的有限。

二、核心问题：依赖AI的「记忆力」

Claude 3.5 Sonnet有20万token上下文，听起来很多。

但实际上包含了所有对话历史、代码文件、系统提示词。几轮对话下来，token消耗飞快。

我最大的问题：太依赖AI的「记忆力」了。所有讨论细节都散落在对话里，没整理到文档里。

一旦上下文丢失，AI就不知道之前要做什么了。

三、解决方案：轻量级项目管理流程

用Markdown+AI工具就能搞定：

MRD → 产品定义&demo → PRD（最关键）→ UI设计 → 技术方案 → roadmap → 迭代

别被这些名词吓到，其实就是用文档把每一步都记下来。

四、PRD怎么写（重点！）

我之前踩坑，就是因为PRD写得太简单，没把所有讨论细节都写进去。

现在我用的模板：

## 功能概述一两句话说明这是什么功能## 功能详细说明包含所有讨论的细节，越详细越好## 交互流程用户怎么操作，系统怎么响应## 边界情况异常情况怎么处理## 迭代记录（重要！）- [日期] 发现XXX问题，调整方案为YYY- [日期] 用户反馈XXX，新增需求ZZZ

迭代记录这个章节，特别重要。

案例1：交互逻辑调整

开发到一半，我发现应该先显示签文再输入内容，而不是先输入再显示。

如果不更新PRD，下次对话AI还会按旧逻辑理解。

更新PRD后，在「迭代记录」里写： 「[2025-01-22] 发现先输入内容再显示签文的逻辑不符合用户预期，改成先显示签文再输入，原因是用户想先看签文再决定怎么回应」

案例2：边界情况处理

用户测试后发现，签文接口偶尔会返回空数据。

在PRD里补充：「签文接口可能返回空，需要加loading状态和错误提示」

案例3：技术方案优化

原来用localStorage存储，后来数据量大时性能有问题，改成了IndexedDB。

在迭代记录里写： 「[2025-01-22] localStorage在签文数据超过100条后性能下降，改成IndexedDB，原因是...」

核心原则：

PRD不是写完就固定的活文档，每次有调整想法，立即让AI更新PRD。

我现在养成了个习惯，每次和AI讨论完，都会问一句：「这个要更新到PRD吗？」

五、省时省token的技巧

核心原则：把决策从对话里捞出来，存到文档里。

对话管理

完成一个功能后，让AI总结一下当前状态，这个checkpoint很重要。

下次继续时，直接让AI读checkpoint。

文档迭代管理

所有文档放在一个地方：

/docs /mrd.md /prd.md /technical-design.md /roadmap.md /changelog.md

每次调整方案，立即更新MRD/PRD。维护一个「决策日志」，记录为什么改、改成什么样。

任务拆分

大任务拆成小任务，每次对话只关注一个任务。

不要一次对话里聊太多主题，不然上下文会乱。

养成「写文档」的肌肉记忆

每次对话结束前，问AI三个问题：

1. 「这次讨论有什么关键决策要记录吗？」
2. 「需要更新哪个文档？」
3. 「帮我生成更新内容，我确认后修改文档」

长期来看，这样反而更省token。不用每次重新讨论，AI能快速恢复上下文。

六、开发roadmap怎么拆

不要一次给AI太多任务，按版本拆分：

v0.1：核心功能MVP

• 每日抽签功能
• 签文带入对话框

v0.2：次要功能

• 签文收藏
• 历史记录

v0.3：优化和完善

每个版本独立开发，避免上下文混乱。

v0.1完成后，保存checkpoint，让AI总结完成的状态。

开始v0.2时，让AI先读取完整文档，再开始新的开发。

七、实施效果

之前：经常忘记要做什么，功能遗漏，重复讨论，浪费大量token。

之后：每个版本的进度都很清晰，讨论结果都有记录，AI能快速恢复上下文。

虽然前期花时间写文档，但后期真的省心很多。

八、核心心得

AI很强，但不是万能的。

项目管理不是负担，是vibecoding的基础设施。

轻量级文档加上AI工具，开发效率能翻倍。

说白了，vibecoding不是让AI替你写代码，而是让你和AI协同工作。

协同就需要共同的语言和记忆，文档就是这个语言和记忆的载体。