我用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三个问题：
- 「这次讨论有什么关键决策要记录吗？」
- 「需要更新哪个文档？」
- 「帮我生成更新内容，我确认后修改文档」
长期来看，这样反而更省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协同工作。
协同就需要共同的语言和记忆，文档就是这个语言和记忆的载体。
热门跟贴