用Claude Code从零搭建宠物生命周期管理App：AI编程全流程实操

如果你也想试试让AI从零搭一个完整的项目，而不是只写几个零散函数，这篇文应该能帮到你。我最近用Claude Code完整做出了一个宠物生命周期管理App，从建目录、设计数据库、写接口、做页面到联调测试，全程在终端里靠自然语言对话推进，中间没手写过一行完整代码，代码全是AI生成、我来审查和纠正的。

宠物生命周期管理App解决的是养宠人一个很实在的问题：疫苗、驱虫、体检、洗澡这些事件的时间分散在纸质本子和聊天记录里，时间一长就分不清上次什么时候做的、下次又该什么时候做。我把它做成一个集中管理工具，能维护宠物档案、记录生命周期事件、自动算提醒，顺带把体重趋势画成曲线，这样宠物健不健康、该不该去体检，打开页面扫一眼就清楚。

整篇文会讲清楚三件事：第一，如何把一个中型项目拆成AI能理解的子任务；第二，每一阶段跟Claude Code的对话思路和产出效果；第三，实际跑下来之后，哪些环节AI很强、哪些环节必须人来把关。内容有点长，但每一步都是真实的实操记录，直接照着做就能复现。

1. 需求拆解与技术选型：先想清楚再让AI动手

1.1 宠物生命周期管理到底管理什么

很多人一上来就急着让AI写代码，这是一个大坑。我自己第一版就是这么干的，让Claude Code"做一个宠物管理App"，结果它给我生成了一堆花里胡哨但根本连不起来的页面，数据库表也缺字段。后来我强制自己先花半小时把需求写成文档，再喂给AI，效果立竿见影。

宠物生命周期管理App的核心需求，拆开看其实就三大块：

第一是宠物档案。每只宠物要有名字、物种（猫/狗/其他）、品种、性别、出生日期、领养日期、毛色、当前体重、头像和备注。出生日期和领养日期必须分开，因为很多宠物是领养的，出生日期往往只能估个大概，领养日期才是主人最确定的那个时间点。这个字段设计一开始我没注意到，是AI在需求梳理阶段反问我"是否需要区分出生日期和领养日期"时提醒了我，这个细节对后面的年龄计算影响很大。

第二是生命周期事件。这是整个App的核心，也是"生命周期"四个字的落点。每只宠物会持续产生疫苗、驱虫、体检、美容、纪念日这几类事件。每个事件要有事件类型、事件日期、下次事件日期、备注。为什么一定要有"下次事件日期"？因为猫狗打疫苗、做驱虫是有固定周期的，比如幼猫第一年要打三针猫三联，每针间隔21到28天，之后每年一针加强。把下次日期记下来，后面做提醒功能才能直接算。

第三是成长记录与提醒。成长记录主要是体重历史，每次体检或在家称重都记一条，最后在详情页画成曲线。提醒功能则是把每条事件的下次日期跟当前日期比，逾期没做的标红，未来7天内要做的标黄，这样主人打开页面就知道最近该干什么了。

我把这些需求整理成了三页纸的文档，包括每个页面上要显示什么、每个按钮点了之后发生什么、数据之间什么关系。然后才打开Claude Code，让它通读这份文档，先输出技术方案，而不是直接写代码。

1.2 技术栈选型的三个考量

技术栈这块，我是带着预判去让AI选的，结果它也给出了接近的方案。最终用的是这么一套：

后端Node.js + Express，数据库SQLite，前端Vite + React + Tailwind CSS，图表用Recharts。

选这套方案的逻辑值得展开说一下。这个App本质上是一个典型的CRUD应用（增删改查），数据实体就三个：宠物、事件、体重记录，实体间关系非常简单。对这种项目，Node.js + Express + SQLite是性价比最高的组合，没有之一。

为什么不用Python FastAPI？不是不行，但Claude Code对JavaScript生态的训练语料覆盖最充分，生成Express代码的可靠度明显高于冷门框架。换句话说，与其挑战AI的短板，不如顺着它的长项走。这就好比做木工请了个熟练的帮工，你递电钻他顺手，递一个外语说明书的老式刨子，他就只能在那里瞎猜了。

SQLite的选择也是基于同一个逻辑：零配置文件型数据库，整个数据库就是一个文件，备份就是复制粘贴。项目规模就三张表，根本不需要单独装PostgreSQL服务。等哪天数据量大到SQLite扛不住，再迁移也不迟，但至少现阶段别给自己加戏。

前端用Vite + React + Tailwind，一是React的组件化思路跟这个App的页面结构天然契合，二是Tailwind写样式速度快，AI生成代码的时候不容易出现CSS类名冲突。图表选了Recharts，它在React项目里接入最简单，API友好，AI生成的代码出BUG的概率也低。

技术栈定完之后，我在项目根目录建了一个CLAUDE.md文件，把这个技术栈选择、目录结构约定、数据命名的规范全部写进去。这一步非常关键，因为Claude Code每次会话会先读这个文件，里面的约定就成了它后续写代码的"宪法"，避免它今天用fetch明天用axios、今天叫petId明天叫pet_id这种精分行为。

2. 环境准备与Claude Code初始化：第一轮对话决定了后面一半的成败

2.1 安装与首次配置

Claude Code本身的安装非常简单。前提是机器上装了较新的Node.js LTS版本，然后打开终端，执行官方提供的安装命令，把CLI工具装到全局。安装完成后，在任意目录输入claude就会进入交互式终端界面。

首次启动会有一个授权流程。它需要读取本机的用户配置来完成账号验证，这一步跟着提示走就行，没什么可说的。唯一要提醒的是工作目录：一定要在项目的根目录启动Claude Code，因为它是基于当前目录来读文件、写文件的，你在错误目录启动，它就会在错误目录里创建项目，后面挪起来非常麻烦。

进入交互界面后，可以先输入/help看一下内置命令。我实际用下来，最高频的几个是/init（让AI分析当前项目并生成CLAUDE.md）、/compact（压缩上下文，后面讲）、/review（让AI自己审查最近的改动）。这些命令不是摆设，尤其是/compact，项目写到后期上下文很长的时候，它能救命。

一个有用的初始化技巧：第一次启动时，我会直接跟Claude Code说"这是一个空目录，我们准备从零搭建一个XX项目，请先阅读我的需求文档，输出你的理解和分阶段计划，先不要写代码"。这一句话就把这次会话的基调定住了：先规划、后实现、分阶段。它输出的计划会成为整次项目的"蓝图"，后面每一步都可以拿这个蓝图对照，防止AI跑偏。

2.2 项目初始化的第一轮对话

我的第一轮对话是这样发的：

"这个目录是空的，我们要做一个宠物生命周期管理App。需求文档在project/requirements.md里，你先读一遍。请输出三样东西：你的理解、数据模型设计（包括每张表的字段和关系）、分阶段的开发计划。先不要写代码。"

Claude Code会先读文件，然后输出一段结构化理解。我对它的要求是"不要写代码"这一步非常关键——如果没说这句话，它大概率会在回答里直接开始生成文件，计划还没对齐就开始动手，后面返工概率很高。

第一轮的产出质量还不错。它给出的数据模型跟我在需求文档里写的基本一致，差别在于它额外建议了"在events表里增加next_date字段用于提醒计算"，并在宠物表里增加一个"是否绝育"的布尔字段。绝育这个字段我在需求文档里没写，但确实合理，因为绝育后的宠物在饮食控制和体重管理上跟未绝育的有明显差异，这个字段后续可以支撑更细致的建议功能。这种"AI主动补全需求"的体验贯穿了整个项目，也让我意识到，把AI当成纯粹的代码生成工具其实是浪费，让它先当个需求评审人更有价值。

分阶段计划它列了五步：项目脚手架、数据库层、后端API、前端页面、联调测试。我确认之后，它就开始执行第一阶段。整个初始化过程大概十来分钟，它自己创建了package.json、入口文件、目录结构，跑了依赖安装命令。我全程没写一条命令，只是看着终端里的输出，偶尔问一句"这一步在做什么"。

这里要给一个极其重要的建议：项目脚手架完成后，立刻创建一个CLAUDE.md文件，把技术栈、目录结构、数据模型约定、API命名规则写进去，让Claude Code自己保存一份"工作手册"。我大概在第一次会话结束后才补的这一步，后面的会话明显稳定很多，不再反复出现低级的不一致问题。

3. 核心功能实现：档案、事件、提醒的计算逻辑

3.1 数据库表结构设计

Claude Code在第二阶段生成了三张表的建表SQL。打磨之后，核心结构是这样的：

CREATE TABLE pets ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, species TEXT NOT NULL DEFAULT 'cat', breed TEXT, gender TEXT CHECK(gender IN ('male','female','unknown')), birth_date TEXT, adoption_date TEXT, avatar_path TEXT, current_weight REAL, is_neutered INTEGER DEFAULT 0, notes TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP, updated_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL, type TEXT NOT NULL CHECK(type IN ('vaccine','deworm','checkup','grooming','memorial')), title TEXT NOT NULL, event_date TEXT NOT NULL, next_date TEXT, notes TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP, FOREIGN KEY (pet_id) REFERENCES pets(id) ON DELETE CASCADE ); CREATE TABLE weight_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL, weight REAL NOT NULL, measured_at TEXT NOT NULL, notes TEXT, FOREIGN KEY (pet_id) REFERENCES pets(id) ON DELETE CASCADE );

三张表的关系很简单：一只宠物有多条事件记录，有多条体重记录。外键都加了ON DELETE CASCADE，删除宠物时自动清掉关联数据，这个细节是我让AI加的，它默认生成的版本没有级联删除，直接删宠物会导致一堆孤儿数据。

值得说的是event_date和next_date两个字段同时存在的作用。event_date是"这次事件的发生日期"，next_date是"下次应该做的日期"。比如2025年3月1日给猫打了猫三联第一针，next_date设为2025年3月22日；等3月22日打了第二针，电脑自动把event_date改成3月22日，next_date改成4月12日。这样每次打开详情页，看到的永远是最新状态。用冗余字段做提醒，代价是每次新增事件要同时维护两个日期，但对这个规模的项目来说，简单直接比规范化设计更好用。

建表语句生成后，我让Claude Code写了一个seed脚本，塞进了三组模拟数据：一只成年猫、一只幼年猫、一只成年犬，每只都带三到五条历史事件和十来条体重记录。有了这批模拟数据，后面做前端页面和联调测试就不用对着空表瞎猜了。

3.2 后端接口实现

后端接口按RESTful风格写的，Claude Code一口气生成了十几个接口，我整理出来的核心清单是：

这里我特别把GET /api/reminders单独列出来。这是整个App里最有价值的一个接口，它一次性把每只宠物未来7天到期和已逾期的事件拉出来，首页的提醒面板全靠它。Claude Code实现这个接口时用了SQLite的date函数，在SQL里直接算日期差，而不是把数据全部拉到内存再用JS算。这个选择是对的，数据量小归小，但让数据库干它擅长的事，语义更清晰。

一段我后来跟AI一起打磨过的提醒查询逻辑大概是这样的：查events表关联pets表，过滤条件是next_date不为空，然后拿当前日期去比对，逾期的事件标'due'，7天内的标'upcoming'，其他标'normal'。前端拿到这个状态字段直接把标签颜色渲染出来，不用前端再算一遍。把计算逻辑推给后端的好处是，以后增加邮件或消息推送时，可以直接复用同一套状态判断。

生成接口的过程中，我注意到一个细节：Claude Code生成的POST接口通常不做参数校验，比如创建宠物时name传空字符串它也会照单全收。这个问题我在审查代码时发现了，让它加上了必填校验。不要默认AI生成的代码有防御性，它写的是"理想输入"的代码，脏数据进来能不能扛住，得人来把关。

3.3 提醒计算逻辑的前后两端配合

提醒功能是贯穿前后端的核心逻辑，这里单独拎出来讲。Claude Code在后端实现了状态计算，前端只负责展示。那前端怎么知道一条事件是逾期还是即将到期？后端接口返回的数据里，每个事件对象带一个reminder_status字段，值为due、upcoming或normal中的一个。

这个设计比前端自己算好在哪里？最大的好处是口径统一。如果前端自己拿本地时间跟next_date比，不同设备的时间设置、时区差异会导致同一个数据在不同手机上显示不同的状态。后端统一算出状态，前端只信接口，就不会走样。

计算逻辑本身不复杂：next_date减去当前日期，小于0就是due，0到7就是upcoming，大于7就是normal。但有一个容易被忽略的点——next_date只精确到天，而SQLite的date("now")返回的是UTC日期，如果用户的本地时区偏东，凌晨那段时间会出现"今天已经到期但系统还显示未到期"的错觉。踩过这个坑之后，我让Claude Code在接口层把日期格式化统一成YYYY-MM-DD，并且显式传本地日期参数进去，而不是让数据库自己在SQL里算now。这个修正很值得记下来，很多日期相关的"灵异事件"都是时区造成。

体重曲线的实现相对简单：后端返回按时间排序的体重记录数组，前端扔给Recharts画折线图。唯一要注意的是要让AI处理"同一只宠物多个体重记录时间戳相同"的情况，不然图上的点会重叠。我在审查时发现了这个问题，跟Claude Code说"体重记录允许按时间倒序排列，相同时间的保留最近一条"，它很快就改了。

4. 前端界面与交互实现：让AI写页面但不让它放飞

4.1 页面结构规划

前端这块，我在跟Claude Code对话前先自己画了四个页面的线框草稿：首页、宠物详情页、添加/编辑页、提醒页。别小看这一步，线框草稿不需要多精细，但要把页面包含的信息块和操作入口写清楚，AI照着实现才不会跑偏成它自己想象中的样子。

首页是宠物卡片列表。每张卡片显示头像、名字、物种、年龄，以及"最近事件"和"下次提醒"两行小字。页面顶部有一个全局的提醒汇总条，显示"3只宠物有临近事件"这种摘要。右下角悬浮一个添加按钮。这个布局我直接描述给Claude Code，它用Tailwind一行一行写出来，整体还原度很高。

宠物详情页是整个App信息密度最高的页面。从上到下依次是：宠物基本信息卡（头像、档案、编辑按钮）、事件时间线（按日期倒序，每个事件用一个带图标的小卡片展示，逾期事件红色边框）、体重曲线图、操作按钮区（添加事件、记体重）。这个页面的信息层次如果AI自己发挥，很容易把所有东西平铺成上下滚动的一长条，毫无重点。所以我在对话里明确按优先级排了序：基本信息卡最重要，事件时间线其次，曲线图再次。

添加/编辑页就是表单页，宠物和事件各一套。宠物表单包括名字、物种（单选）、品种、性别（单选）、出生日期、领养日期、绝育状态（开关）、头像上传、备注。事件表单包括类型（下拉）、标题、事件日期、下次日期（可选）、备注。这些表单字段必须跟后端接口的字段名一一对应，否则联调就是灾难。

提醒页最简单，就是把GET /api/reminders的返回结果分成两栏：已逾期和未来7天。每一条显示宠物名、事件类型、原定日期、距离天数。这个页面其实可以并入首页，但单独拎出来做成一个Tab，更符合"打开App先看提醒"的使用习惯。

4.2 关键页面实现细节：宠物详情页与事件时间线

宠物详情页是AI生成代码最多、返工也最多的地方。第一版Claude Code把整个页面写成了一个大组件，包含信息卡、时间线、图表、弹窗、表单，一共六百多行。功能是能跑，但你让AI改一个弹窗的样式，它就得重新读这六百多行代码，改起来小心翼翼，有一次还改崩了一块。

后来我让它按组件拆分：PetInfoCard、EventTimeline、WeightChart、EventFormModal、WeightFormModal五个文件。拆分之后每个文件控制在两百行以内，维护成本直线下降。这也是跟AI协作的一个重要经验：AI生成代码时，你得主动提出组件边界的要求，它不会自己想到这么细的粒度，但只要你提了，它执行拆分做得又快又干净。

事件时间线的实现也值得一说。我"抄作业"的时候让Claude Code参考了主流时间线组件的交互：中间一条竖线，左右两侧交替排列事件卡片。事件图标按类型显示不同颜色——疫苗蓝色、驱虫绿色、体检橙色、美容紫色、纪念日粉色。这个视觉设计纯靠我口头描述，它用Tailwind完成得八九不离十。逾期的事件会加一个红色"已逾期X天"的角标，这个角标的数据源就是后端返回的reminder_status和days_overdue字段，前端只做展示。

头像上传这块是前端相对复杂的部分。我没有单独搞对象存储，而是让后端提供一个接收文件、保存到本地上传目录的接口，数据库存相对路径。Claude Code用的是multer这个中间件处理的，代码量不大，但上传后的文件访问权限和路径校验需要人来确认——如果路径没做校验，用户是可以通过构造路径读取服务器上其他文件的。这个安全点是我重点审查的，发现AI默认版本里没有做文件名白名单校验，我要求它加上了。

4.3 前后端联调的常见摩擦点

联调阶段，前后端是分开跑在两个端口上的，前端Vite默认5173，后端Express默认3000，所以第一步要解决跨域。Claude Code在后端用cors中间件解决了这个问题，一行代码的事，但你要是忘了提，浏览器控制台会报一堆红色错误，新手很容易卡在这。

第二个高频摩擦点是字段命名的对齐问题。AI有时候会在后端返回petId，前端代码里却写pet_id，字段对不上，页面显示就是undefined或者空白。避免这个问题有两个办法：一是最初的数据模型阶段，把字段命名规范写进CLAUDE.md；二是我在实际中用的更笨但更有效的办法——让AI生成一个共享的类型定义文件（前端叫apiTypes.js），所有接口的请求和响应形状都定义在那里，前端组件只从这份文件读字段名。联调报错时，先看apiTypes.js，再看后端代码，基本都是字段不一致。

第三个问题是React组件的useEffect依赖数组。AI生成的代码里，经常出现"进入页面时请求一次数据"这样直接挂一个空依赖数组的情况。如果这个页面接收路由参数（比如宠物ID），空依赖数组会导致从宠物A切到宠物B时，页面不重新请求数据，显示的还是A的信息。我在联调时发现这个Bug，让Claude Code把petId加进依赖数组，才彻底修好。凡是有路由参数、要按参数拉数据的页面，都得检查这个点。

5. 常见问题与排查技巧：实测下来的翻车现场与补救办法

5.1 五个典型翻车场景速查表

整个项目做下来，我发现跟Claude Code配合的坑基本集中在五个场景。整理成一张表，方便后面照着排查：

第一个场景几乎必然会遇到。项目做到后半段，我还想加功能时，发现Claude Code已经开始"遗忘"最初数据模型的约束，比如它新生成的一个查询接口用了inner join，但早期定的是left join。这个很好理解——上下文窗口再大也有上限，一开始的对话细节太久远了。我把关键约束写进CLAUDE.md之后，这种遗忘现象大幅减少。

第二个场景也很典型。有一次我让它"优化一下首页的卡片布局"，它顺手把详情页的一个组件也改了，理由是"复用卡片组件，改了样式两边一起更新"。听起来挺合理，但结果就是首页样式调整了，详情页的卡片也跟着变了，我本来没想改那边。从那以后，每次提任务我都会补一句"只修改与任务直接相关的文件，不要顺手改无关模块"。AI的执行力很强，但它的"顺手"有时候会让人头大。

5.2 让AI自己Debug的高效提问法

用Claude Code跑这个项目，最爽的不是让它生成代码，而是让它自己修Bug。但"让AI修Bug"和"高效地让AI修Bug"完全是两回事。踩了几次坑之后，我总结出一个三步提问法，实测定位准确率大幅提升。

第一步：贴原始报错信息，不要自己先翻译一遍。直接Copy控制台的完整错误堆栈给Claude Code，它比你更擅长从堆栈里找线索。如果你只给一句"页面报错了"，它能做的只有瞎猜。

第二步：告诉它"最后一次改动是什么"。这一步信息量极大。AI会对比最近的改动和报错信息，很多Bug就是上一轮改动引入的，差别一目了然。我一般在提Bug时会附带一句"我刚刚改了A文件的B函数，之后再刷新就报这个错"，它基本能在几次定位内找到问题。

第三步：明确要求"先复现，再修复，最后自测"。如果AI理解了Bug但没复现就直接改，经常会出现改了一个地方、另一个地方又坏了的情况。我要求它先写出能复现问题的命令或操作路径，然后修复后自测给我看。这有点像你带新人，光告诉他答案没用，让他自己走一遍排查流程，出错率才会真正降下来。

5.3 上下文管理的经验

跟Claude Code做这种完整项目，上下文管理是决定体感的核心。它再好用，也不可能在一个会话里无限记住所有事情。

我的做法是把整个开发周期分成三个阶段，每个阶段开一个新会话：第一阶段做需求和脚手架，第二阶段做后端和数据库，第三阶段做前端和联调。每个阶段结束时，我会把当前的项目状态、已完成功能、待办事项写进项目里的PROGRESS.md文件。新会话启动时，先让它读这个文件，再继续干活。这样每个会话的上下文都是干净的、聚焦的，不会出现"上上个会话说过的话早就忘了"的问题。

会话中途如果感觉AI开始糊涂了，比如它回答的质量明显下降、开始重复问同样的问题，我就会用/compact把上下文压缩一下。压缩之后它会丢掉一部分对话细节，但是关键的CLAUDE.md和PROGRESS.md里的内容会保留，所以压缩之后它一般能恢复清醒。千万不要硬着头皮在同一个会话里用完整个项目，那样越到后面AI越像"喝醉了的老员工"，看着在干活，实际尽帮倒忙。

6. 实操心得体会：哪些可以放手，哪些必须死守

6.1 AI的强项与人类的底线

走完这个项目，我对AI写代码这件事的认知有了很大变化。Claude Code的强项和弱项非常分明，用对了是十倍效率，用错了是无尽的返工。

强项有三块。第一是生成样板代码和CRUD代码，这个基本零失误，给它一个数据模型，它能把接口、数据库操作、前端表单全部生成出来，虽然不惊艳但挑不出大错。第二是搜索式修改，你告诉它"把所有的alert弹窗换成自定义Modal组件"，它能非常精确地在几十个文件里找到所有alert并替换掉，这种机械性工作在传统开发里最无聊，它做起来又快又稳。第三是报错驱动的Debug，把报错堆栈丢给它，它找Bug的速度通常比人翻代码快，尤其是一些低级但隐蔽的小错误，比如变量名拼错、括号不匹配。

弱项也很明显。第一是真正的架构决策，它不会主动为你权衡"这里用状态机还是事件驱动"，除非你在CLAUDE.md里写了明确方向，否则它会默认选择最常见但未必适合当前场景的方案。第二是安全和边界条件的感知，校验输入、限制上传文件类型、防御SQL注入这些"扫兴的事情"它默认都不做，需要人明确要求。第三是产品感，它不知道什么功能对用户更重要，你让它自由发挥一个页面，它会把所有功能平铺，完全没有主次优先级的概念。

用一句我常跟人说的类比：Claude Code像一个执行力很强但经验不足的实习生。你给它的任务书越清晰、验收标准越明确，它的交付质量就越高。但这不代表你可以放手不管——我是不会把一个生产项目的上线权限交出去的，越到后期，"人来把控方向"这个动作越不能省略。

6.2 下一步扩展方向与快速尝试建议

项目做到这里，基础功能已经完整可用了，但这套架子还能往多个方向扩展，而且每个方向都可以继续用Claude Code辅助开发。

我在代码库里留了几个明显的扩展点。一个是多宠物的横向统计，现在的首页和详情页都是单宠物视角，但可以让Claude Code加一个统计页，展示所有宠物的年龄分布、物种分布、事件完成率，用Recharts做成图表。一个是提醒推送，现在提醒只存在于App内部，下一步可以引入消息队列或者邮件服务，让后端在每日定时任务里检查提醒列表并推送通知。还有一个是导入导出能力，比如把一只宠物的完整生命周期数据导出成PDF或JSON，方便换手机时候的数据迁移。

如果你也想快速尝试这套流程，我的建议是不要从业务复杂的项目开始，先拿一个你自己真正想用的、结构清晰的工具类项目下手。找那种你能清楚说出"这个页面要显示什么、那个按钮点了发生什么"的项目，这样的需求描述最容易被AI理解，也最容易出成果。等跑通一次完整的"需求拆分—AI实现—人工验收"闭环，你就知道后面接更大的项目时该怎么调整了。

最后分享一个小技巧：做这种全流程AI开发，每个阶段结束时让Claude Code自己写一段"变更摘要"，记录这个阶段做了什么、改了哪些文件、下一步计划是什么。我一开始嫌麻烦，后来越发觉得这个环节真省心——到新会话里，把摘要丢给AI，它瞬间就能进入状态，哪怕你隔了一周再回来继续搞，上下文照样接得上。配合CLAUDE.md和PROGRESS.md，每个新会话都像是"同一个AI员工上周刚下班、这周回来继续干活"，比每次重新教一遍省太多事了。