最近我用 Claude Code 从零搭完了一个宠物生命周期管理 App，整个过程从需求梳理、工程初始化、功能开发到模块联调，基本都是在 AI 辅助下完成的。这篇文章就顺着这个项目讲讲全流程是怎么跑的，哪些地方顺畅，哪些地方踩了坑，以及如果你也想让 Claude Code 接手一个全新项目，最应该注意什么。
这个项目本身不复杂——宠物档案、生命周期阶段判断、疫苗/驱虫提醒、健康记录查询，但正因为“麻雀虽小”，它特别适合拿来验证 AI 辅助开发能不能真正落地。带过新项目的人都懂，工程搭建最烦人的不是写业务代码，而是基础设施、目录结构、类型定义、测试环境这些杂活；Claude Code 最擅长的恰恰是这一类有标准化答案的工作。适合谁看？想尝试 AI 编程但还没系统性跑通全流程的人，已经在用 AI 写代码但觉得“生成的东西不敢直接上”的人，以及想做个人项目却总卡在冷启动阶段的朋友。下面展开说。
1. 项目前夜：为什么选“宠物生命周期管理”当新项目练手
1.1 身边养宠朋友的痛点从哪来
我身边养宠物的朋友不算少，但几乎所有人的宠物信息都散落在聊天记录、备忘录、体检报告照片里。疫苗什么时候打的？下次驱虫该什么时候？猫咪从幼猫过渡到成年猫、再到中老年，喂养标准要不要调整？这些问题没有人能一下子答全。我本来只想给自家那只猫做个简单的记录工具，后来发现“生命周期”这个概念可以做成一个真正有价值的产品方向——不同年龄段的宠物，疫苗频率、食物热量、体检间隔、常见病风险都不一样。如果一个 App 能根据宠物生日自动判断当前处于哪个生命周期阶段，再给出对应的提醒和知识卡片，它就是一个真的能用的工具，而不是一个演示 Demo。
这个需求还有一层好处：它离我足够近。自己做使用者，就意味着我能清楚地判断哪些功能是多余的、哪些逻辑是错的，不会像外包项目那样需求全靠猜。对 AI 辅助开发来说，一个你能亲自验收的项目，迭代闭环才会真正跑起来。
1.2 为什么这个项目适合验证 AI 辅助开发
选择这个项目还有更深一层的考虑：它功能边界清晰，又不缺复杂度。边界清晰意味着我可以放心地把相当一部分工作交给 AI 去生成；复杂度则来自生命周期规则、提醒逻辑、数据关联，这些刚好需要人把逻辑讲清楚，AI 才能写对。换句话说，它是“人类定义规则、AI 负责编码”的典型场景，比纯粹的多表 CRUD 能暴露更多问题，又不至于像大规模分布式系统那样难以收尾。
我见过不少朋友一上来就想用 AI 搭一个“全栈电商平台”或“社交应用”，结果生成到一半，需求本身已经膨胀得无法维护，AI 根本不知道该按哪条线走。宠物生命周期管理 App 的体量刚刚好：三五个核心模块，一两条关键业务规则，一个人在一周内能完成从零到一的全部工作。这种体量的项目，最适合观察 Claude Code 到底能帮你省多少时间、在哪些环节会拖后腿。
1.3 Claude Code 能替你做什么、不能替你做什么
先说清楚工具本身。Claude Code 是一款运行在终端里的 AI 编程助手，它能读取项目结构、创建和修改文件、执行终端命令、运行测试，本质上是一个能直接跟代码仓库“对话”的智能体。跟你在网页对话框里让它“写一段代码”然后复制粘贴不一样，它可以直接改你磁盘上的文件，这种深度集成才是效率的关键。
但它是极大的误解来源。它不是万能外包，更不是“我说要什么，它就自动变出什么”。它能帮你快速生成脚手架、写类型定义、补单元测试、解释报错信息；它不能替你决策业务规则，也不能在你需求一团糟的时候自动变出清晰的产品定义。后面我会反复强调一个观点：花在需求整理上的时间，直接决定 AI 产出的质量。你把规则讲到七分，它大概能给你做到八分；你只讲两分，它大概率给你做出一堆用不上的东西。
2. 需求定义与整体设计：先让 AI 听懂人话
2.1 “生命周期”这个概念怎么落地成功能
我一开始最纠结的问题是：所谓“宠物生命周期”，到底是一组知识卡片，还是一个硬性的计算规则？后来我决定把它拆成可执行的功能点，让 AI 按功能点实现。
- 宠物档案：种类、品种、生日、性别、绝育状态、当前体重、头像
- 生命周期阶段：幼年期、成年期、中老年期，按物种和体型区分
- 提醒能力：疫苗、驱虫、体检、剪指甲等周期性任务，自动计算下次时间
- 健康记录：体重变化、进食情况、症状记录、就诊历史
- 阶段知识卡：根据当前生命周期阶段，展示对应的喂养和护理建议
生命周期阶段不能随便写死。猫和狗的时间跨度完全不同；狗还要继续按体型区分，小型犬、中型犬、大型犬进入中老年的时间差异很大。这部分我整理成了一张规则表，作为核心需求直接扔给 AI。我的原则是：凡是能用表格说清楚的规则，绝不用自然语言模糊描述。
2.2 技术栈选择：为什么是 Node.js + TypeScript + SQLite
技术栈的选择我也做了刻意收敛。最终方案是：Node.js + TypeScript + Express 做后端，Prisma 管理数据库 Schema，SQLite 做本地持久化，前端先用 React 写一个移动端友好的 Web 页面，后续需要的时候再考虑包壳成原生 App。
选这个组合有几个现实原因。第一，Claude Code 在 TypeScript 生态里生成的代码质量通常最高，类型系统能兜住 AI 经常犯的“字段名拼写不一致”“对象结构对不上”这类低级错误。第二，Express + Prisma + SQLite 是信息密度最高的主流组合，没有 Kafka、没有 Redis，没有微服务，一个个人项目能把闭环跑通比什么都重要。第三，SQLite 对“单机个人工具”来说是完全正确的选择，零运维，备份就是复制一个文件。等用户量真的大到需要换数据库了，再迁移也不迟。
2.3 数据模型设计：四张表就够了
数据模型我控制在四张核心表：
- pet：宠物主表，存种类、品种、生日、性别、绝育状态、体重
- vaccine_record：疫苗记录，关联 pet，存疫苗名称、接种日期、下次接种日期
- reminder：提醒任务，关联 pet，存任务类型、上次执行日期、下次执行日期、周期规则
- health_record：健康记录，关联 pet，存记录类型、体重、症状描述、就诊日期
这里一个小插曲是，我最初还想设计一张“品种标准表”，用来按品种查平均寿命和常见病。后来发现数据量撑不起来，就砍掉了，改成在知识卡里直接内置静态文案。设计上做减法的原则，对 AI 辅助开发尤其重要——每多一张表，就意味着多一倍的生成代码量和多一倍的出错概率。
2.4 给 Claude Code 的第一份任务书：Prompt 到底该怎么写
很多人问 AI 编程的第一步是“写一个神奇的 Prompt”，其实没有秘密，就是一份结构化的任务书。我给 Claude Code 的第一份任务书是这样的，你可以直接抄：
我需要你帮我从零搭建一个 Node.js + TypeScript 的后端项目，用于宠物生命周期管理 App。要求如下：
- 使用 Express 框架，目录按 domain / service / controller / repository 分层；
- 数据层先用 SQLite，通过 Prisma 管理 schema 和迁移；
- 提供宠物档案的 CRUD 接口，以及一个根据生日自动计算生命阶段的接口；
- 所有接口返回统一结构，错误处理集中处理，不要散落在每个 controller 里；
- 测试用 Vitest，至少给生命周期计算写单元测试；
- 暂时不需要用户注册登录、不需要社交分享、不需要权限系统。 请先创建项目结构，然后逐步实现。每完成一个模块就告诉我当前状态，不要一次性输出全部代码。
这份任务书的关键词是“先创建结构”“逐步实现”“不要一次性输出全部代码”。我踩过一次教训：如果不加这句，AI 会把几十个文件全部倒进终端，你根本没法审查，出错后也不知道从哪查起。分步输出、每步反馈，才能把 AI 开发变成可控流程，而不是一次大型抽奖。
3. 从零到一：用 Claude Code 搭项目的完整实测
3.1 初始化工程：让 AI 先搭骨架再填肉
在终端里进入空目录，输入claude命令并确认启动后，我把上面那份任务书原封不动粘进去。它做的第一件事是列出当前目录结构，确认这是空项目，然后开始创建package.json、tsconfig.json、src目录以及各个分层文件夹。
这里有个实操要点：一定要让 AI“先创建结构，再填充代码”。我让它分两步走，先输出目录树并解释每个目录的职责，我确认无误后再让它生成 Prisma Schema 和第一个模块的代码。实测下来，这样做的返工率远低于“一把梭”。结构先行还有一个好处，你能在早期发现 AI 对“分层”的理解是否和你一致——如果它把 repository 和 service 混在一个文件里，这时候纠正成本最低。
3.2 宠物档案模块：字段校验是重点
项目骨架搭完后，我继续对话：请帮我实现宠物档案模块，字段包括种类、品种、生日、性别、绝育状态、体重，接口支持创建、查询、更新、删除。
它很快生成了对应的 controller、service、repository，以及 Prisma 模型。我 review 了一遍，发现两个问题。第一，它默认把所有字段都设为必填，但实际场景里“品种”和“绝育状态”是允许为空的；第二，生日的校验只做了“是否为合法日期”，没有做“是否在合理范围”。我追加了一句：birthday 必须早于今天，且不能早于 50 年前，否则返回业务错误码。它就老老实实改了。
这个小插曲说明一件事：AI 生成的 CRUD 看着能用，但业务校验规则它默认只给最低配置。你必须像带初级工程师一样，把校验规则一项项列清楚。不然线上的脏数据，最后还得自己擦。
3.3 疫苗、驱虫、体检提醒模块：周期规则是核心
实现提醒模块时，我特意要求 AI 把“提醒计算”做成独立服务，而不是在 Controller 里顺手算。因为提醒规则后面会跟着生命周期阶段联动变化，独立出来将来好改。
我的提醒规则很简单：每种任务类型有一个基础周期，比如体内驱虫默认 3 个月一次，疫苗按具体疫苗种类确定间隔，体检按生命周期阶段调整频率。AI 生成的ReminderService里有一个computeNextDueDate方法，接收上次执行日期和周期，返回下一次执行日期。这里我盯着它写了一条核心逻辑：如果上次执行日期加上周期已经早于今天，说明用户已经逾期了，下一次执行日期应该以今天为基准重新计算，而不是返回一个过去的时间。这个规则是我提出的，AI 最初生成的版本没有考虑逾期场景。
3.4 生命周期阶段判定与提醒联动
生命周期 stage 是全部模块里最需要人类定义清楚的部分。我给了 AI 一张表：
| 物种 | 幼年期 | 成年期 | 中老年期 |
|---|---|---|---|
| 猫 | 0-12 个月 | 13-84 个月（约 1-7 岁） | 85 个月以上（约 7 岁以上） |
| 小型犬 | 0-12 个月 | 13-96 个月（约 1-8 岁） | 97 个月以上（约 8 岁以上） |
| 中型犬 | 0-12 个月 | 13-84 个月（约 1-7 岁） | 85 个月以上（约 7 岁以上） |
| 大型犬 | 0-18 个月 | 19-72 个月（约 1.5-6 岁） | 73 个月以上（约 6 岁以上） |
AI 根据这张表生成的 TS 实现很清晰：
export type Species = 'cat' | 'dog'; export type DogSize = 'small' | 'medium' | 'large'; export type LifeStage = 'young' | 'adult' | 'senior'; const DOG_THRESHOLDS: Record<DogSize, { adultAtMonths: number; seniorAtMonths: number }> = { small: { adultAtMonths: 12, seniorAtMonths: 96 }, medium: { adultAtMonths: 12, seniorAtMonths: 84 }, large: { adultAtMonths: 18, seniorAtMonths: 72 }, }; export function getLifeStage(species: Species, ageInMonths: number, dogSize?: DogSize): LifeStage { if (species === 'cat') { if (ageInMonths < 12) return 'young'; if (ageInMonths <= 84) return 'adult'; return 'senior'; } const size = dogSize ?? 'medium'; const thresholds = DOG_THRESHOLDS[size]; if (ageInMonths < thresholds.adultAtMonths) return 'young'; if (ageInMonths < thresholds.seniorAtMonths) return 'adult'; return 'senior'; }生命周期 stage 算出来后，提醒模块就自动获得了联动能力：幼年期驱虫周期按 1 个月算，成年期按 3 个月算，老年期再追加体检提醒。整个项目最核心的“生命周期”概念，到这里才算真正在产品里跑通了。
4. 关键决策复盘：为什么这样设计、这样写
4.1 生命周期计算用“月龄”而不是“年龄”的细节
在设计getAgeInMonths的时候，AI 第一次给出的实现是直接拿两个日期相减除以毫秒数。这个做法在大多数月份没问题，但遇到闰年、月底这种边界日期就会出错。我强迫它改成基于年月向量的计算方式：
export function getAgeInMonths(birthday: Date, now: Date = new Date()): number { let months = (now.getFullYear() - birthday.getFullYear()) * 12; months += now.getMonth() - birthday.getMonth(); if (now.getDate() < birthday.getDate()) { months -= 1; } return Math.max(0, months); }这个函数的逻辑是：先算完整年份折算成的月份，再加上当前月份和生日的月份差，如果今天的“日”还没到生日的“日”，说明这个月还没满，就减 1。不要小看这几行代码——这是整个生命周期判断的地基，地基歪了，后面所有提醒全都不准。这种边界情况，AI 不会主动替你考虑，你必须作为“产品规则负责人”去提问、去修正。
4.2 数据持久化与提醒触发：为什么选“懒计算”
关于提醒触发方式，AI 一开始给我设计了一个后台定时任务，每隔一小时扫描所有宠物，检查哪些提醒到期，然后推送通知。我把它否了。个人项目没有常驻服务器，引入定时任务意味着架构复杂度直接上一个台阶。
我的方案是“懒计算”：每次进入宠物详情页或首页时，根据当前日期和该宠物最近一条执行记录，现算“下一次该做什么”。简单说，把提醒从“系统推给你”改成“你打开 App 时它告诉你”。这对单机工具形态的产品是完全正确的选择，少一个定时器进程，少无数排查烦恼。
这一点我认为是 AI 辅助开发中最有价值的部分：AI 擅长把你想清楚的方案写出来，但它自己选方案时容易“镀金”——总想做得更复杂更全面。人要做减法，AI 负责加法，这才是合理的分工。
4.3 怎么审 AI 生成的代码：三条原则
我 review AI 生成的代码主要靠三条经验。第一，先跑测试再读逻辑，测试如果跑不过，先看测试断言是不是在瞎写；第二，重点看边界条件和异常路径，AI 生成的代码“正常路径”通常没问题，“异常路径”容易裸奔；第三，警惕过度设计，AI 很爱给简单 CRUD 加缓存、加权限中间件、加事件总线——这些对个人项目完全是负担，必须删。
我还踩了一个具体案例：AI 在 Prisma Schema 里自动给pet表加了一个status枚举，包括HEALTHY、SICK、RECOVERING三种状态。问它为什么，它说“为了后续健康状态追踪”。需求里根本没有这个字段。多余的状态字段只会让前端多三个分支判断。我直接让它删掉，把健康状态做成health_record表里的一条记录，而不是宠物表上的一个字段。这件事让我更确定：AI 的“创造欲”需要被需求文档严格约束。
5. 全流程中的坑：报错、返工与上下文管理实录
5.1 Prompt 太模糊导致整个模块跑偏
我最初跟 AI 说“实现一个提醒功能”，结果它设计了一个包含REMINDER_STATUS_PENDING、REMINDER_STATUS_SENT、REMINDER_STATUS_DISMISSED的完整状态机，还有一套消息队列接口。这不是我要的，我要的只是“记录上次执行时间和周期，计算下次时间”。
被这个跑偏教训之后，我在任务书里加了明确禁止项：不需要状态机、不需要消息队列、不需要通知推送。实践下来，Prompt 里的“要什么”重要，“不要什么”同样重要。给 AI 划出边界，它才不会自由发挥到失控。
5.2 长对话上下文漂移：AGENTS.md 就是我的救星
开发到第三天，对话轮次超过几十轮之后，我发现 Claude Code 开始忘记最开始的 schema 约束，比如它会创建一个新的字段名，跟已有的另一张表外键对不上；甚至重新定义了一个和 map 表里同名的枚举。原因很简单：长对话窗口里，早期的信息被后面的内容稀释了。
我的解决方案是把它写进项目根目录的AGENTS.md文件。这个文件专门记录项目的关键约定：技术栈、目录结构、数据模型版本、命名规范、当前已完成的模块列表、已知约束。每完成一个里程碑，我就让 Claude Code 更新一次AGENTS.md。后续每次开新会话，第一句话就是“请先读 AGENTS.md 再开始工作”。这相当于给 AI 建立了一个持久化的项目记忆库，从此不用担心上下文漂移。
5.3 测试是信任 AI 代码的边界
我要求 AI 每写一个服务，就同步写完对应的单元测试并用 Vitest 跑通。实测下来这个要求非常值钱：AI 自己写测试的过程中，能发现自己代码里约三分之一的低级错误。比如生命周期函数里，它构造测试数据时发现 getAgeInMonths 在生日当月的初始化状态算错了，于是主动回头修了实现。
但别完全依赖 AI 自己测试。我会人工补两个边界用例，比如闰年 2 月 29 日出生的宠物，在非闰年的 3 月 1 日应该算满一岁，而不是差两天。这种反直觉的边界，AI 的测试用例通常覆盖不到。人工补的测试，才是你对 AI 产出的最终信任锚点。
5.4 常见问题速查表
| 现象 | 原因 | 解决办法 |
|---|---|---|
| 生成的日期逻辑在月底/闰年出错 | 用毫秒差直接算月份 | 用年月向量计算月龄，写边界用例 |
| Schema 改了但类型定义没同步 | AI 上下文漂移 | 及时更新 AGENTS.md，要求类型同步 |
| 接口错误返回格式不一致 | 没有统一定义响应结构 | 先定义统一响应类型，再写 controller |
| AI 自动增加多余功能 | 过度设计倾向 | 在 Prompt 里写清楚“不要做什么” |
| 一个文件塞了几百行代码 | 没有要求分步实现 | 要求先建结构，按模块逐步填充 |
| 长对话后忘记核心约束 | 上下文长度稀释早期信息 | 用 AGENTS.md 做持久化约定 |
这张表我建议你保存下来，很可能你第一次用 Claude Code 就会命中其中两三条。我最初几乎每条都踩过。
6. 效率真相：从搭完到敢上线，到底需要多少人力
6.1 时间账：省掉的是冷启动，不是思考
这个项目的核心功能全部搭完，我前后用了大约 3 天，每天投入 1 到 2 小时，合计不到 6 个小时。如果完全手写，按我正常的效率，光搭 Express + Prisma + TypeScript 环境加上四张表的 CRUD，可能就需要一个整天，更别提生命周期规则的设计和测试。所以 Claude Code 的价值不用怀疑，它把“从零到一”的冷启动成本压得非常低，尤其把建目录、装依赖、定框架、写类型样板这类重复劳动基本消掉了。
但这里我要说一句大实话：省掉的是时间和杂活，省不掉的是思考和决策。三天里的大部分纯脑力工作——生命周期规则表、提醒的逾期策略、哪些字段可以为空、要不要定时任务——都是我自己想清楚的。AI 是把我的决策转成代码的执行者，不是替我拿主意的人。你不能指望 AI 模糊地替你决定“宠物提醒应该怎么设计”，它只会把你模糊的输入变成模糊的代码。
6.2 哪些任务适合交给 Claude Code，哪些不适合
适合交给它的任务，通常都有明确的标准答案：项目初始化脚手架、CRUD 接口、类型定义、单元测试、简单重构、报错分析、给已有代码补注释。
不适合交给它的任务，是那些需要业务判断和经验权衡的东西：模块拆分的粒度、技术方案选型、缓存与一致性取舍、数据模型设计的上限。你可以让它列方案做对比，但最终决策必须自己做。我见过最糟糕的用法，是让 AI“帮忙设计一个提醒系统的架构”，然后对着它生成的消息队列方案目瞪口呆。
6.3 一套可以直接复用的工作流
最后分享我现在跑得很顺的工作流，分五步。
第一步，写需求任务书。不用追求格式漂亮，但要覆盖：模块清单、技术栈、目录要求、明确的禁止项。第二步，让 AI 先建项目结构并逐模块实现，别允许一次性灌完所有代码。第三步，每个模块完成后立刻跑测试，并让人工补 2 到 3 个边界用例。第四步，把项目关键约定写进 AGENTS.md，每完成一个里程碑更新一次。第五步，全部完成后开人工 review，重点看数据模型和异常分支。
这套流程不一定是最优解，但它解决了 AI 辅助开发里最大的两个问题：不可控和不可信。结构拆分解决不可控，测试兜底解决不可信。流程跑顺之后，Claude Code 就不是一个玩具，而是真正能交付软件的生产工具。
根据我个人体验，Claude Code 最有价值的部分不在代码生成，而在它迫使我把需求想得更清楚。以前我写代码可以边写边想，让模糊的需求在代码里慢慢“长出来”。但现在我必须在提需求时就把规则讲明白，这个习惯反而让整个项目更健康。它把开发者从“打字员”角色里解放出来，推到一个更接近架构师和产品经理的位置上。
最后再分享一个小技巧：如果你刚开始用 Claude Code，不要急着拿它写业务逻辑，先让它帮你生成项目的 AGENTS.md，并且每隔几轮对话就要求它更新一次。这个文件是长期记忆的核心，也是你应付上下文漂移最可靠的工具。我就是靠这一招，把原本容易失控的长任务，拆成了若干个独立、可靠、随时可以恢复开局的小会话。
