最近我用 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 管理数据库 SchemaSQLite 做本地持久化前端先用 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: RecordDogSize, { 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要求类型同步接口错误返回格式不一致没有统一定义响应结构先定义统一响应类型再写 controllerAI 自动增加多余功能过度设计倾向在 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并且每隔几轮对话就要求它更新一次。这个文件是长期记忆的核心也是你应付上下文漂移最可靠的工具。我就是靠这一招把原本容易失控的长任务拆成了若干个独立、可靠、随时可以恢复开局的小会话。