做项目这么多年我越来越觉得 AI 写代码这件事最大的价值不在“省了多少小时”而在于把一个模糊的念头快速拉成一条能走通的路。这次我用 Claude Code 从零搭了一个宠物生命周期管理 App整个流程走下来对“AI 辅助全流程开发”这件事有了全新的体会。它不是把活干完就结束而是把项目的边界、数据模型、逻辑漏洞、工作流问题同步逼出来——你省下的时间其实花在了更值得花的地方。这篇内容适合两类人一是想尝试用 AI 从零搭建完整项目但又不知道从哪里下手的开发者二是已经在用 AI 辅助编程但觉得生成代码“能用但不敢用”的人。我会把这次完整的实操过程拆开讲清楚包括架构思路、数据模型设计、Claude Code 的提示词组织方式、人工校准的检查点以及踩过的几个代表性的坑。1. 项目定位与技术选型先做减法再让 AI 进场1.1 这个 App 到底要解决什么问题宠物生命周期管理听起来是个挺大而全的概念但如果拆开看你会发现它本质上是一个“围绕时间和状态做提醒”的工具。宠物的一生会经历幼年、成年、老年这些阶段每个阶段涉及的疫苗、驱虫、体检、饮食、体重管理都不同。宠物主人真正的痛点不是“不知道要做什么”而是“知道要做什么但总是忘”或者“信息散在聊天记录、纸质疫苗本、手机备忘录里关键时刻找不到”。所以这个 App 的核心价值不是做一个宠物版社交平台而是把宠物的健康时间线变成一条清晰的数据记录并自动推导出“什么时候该做什么事”。目标用户也很明确养猫养狗的家庭尤其是第一次养宠物的新手。这类用户不需要复杂的功能但要的是打开 App 就知道宠物目前处于什么阶段、疫苗什么时候该打、驱虫是不是已经过期、上次体检是什么时候、体重趋势是否异常。这个定位直接决定了功能范围和设计取舍。不需要用户社区不需要电商跳转不需要花哨的动态发布只需要做好四件事宠物档案管理、健康记录录入、生命周期阶段自动识别、到期提醒。任何不能直接服务这四个核心场景的功能在这个阶段一律砍掉。这样做不是因为做不了更多而是因为让 AI 全流程生成代码时功能边界越清晰生成的质量就越可控。AI 最怕的不是复杂而是暧昧——需求没有明确边界时它会自己发挥而发挥的方向往往不是你要的方向。1.2 技术栈怎么定够用就好还是越强越好技术选型这件事我和很多人的观点不一样。不是越流行的技术越好而是越能让你“把全部注意力放在业务逻辑上”的技术越好。这次选用 Claude Code 做全流程开发最大的优势是它能理解和生成跨文件的代码结构这就意味着技术栈必须选一个它“见过足够多”的组合否则它生成的代码会带有明显的不适配痕迹。我最终确定的技术栈如下前端采用 React Vite Tailwind CSS后端采用 Node.js Express数据库使用 SQLite通过 Prisma ORM 管理。选择这套组合的原因很直接。第一React 加上 Vite 的开发体验足够轻量Claude Code 对 React 代码的生成质量非常稳定尤其是函数组件加 Hooks 的写法它在理解状态管理、组件通信和生命周期方面表现很不错。第二Node.js 和 Express 是 JavaScript 全栈最成熟的服务端方案生态完善示例代码多AI 训练语料充足生成的代码风格统一。第三SQLite 在这个阶段是极佳的选择不需要单独部署数据库服务一个文件搞定所有存储开发调试毫无压力。Prisma 作为 ORM 层让 AI 在写数据库操作时代码可读性更强也更不容易写错 SQL。有人可能会问为什么不用 Next.js 全栈或者 NestJS我没有用 Next.js 的原因很简单这个项目的前后端交互并不复杂用 Next.js 的 API Routes 完全没问题但 Next.js 的工程结构和约定会带来额外的心智负担。Claude Code 在生成 Next.js 代码时也容易在“服务端组件和客户端组件”的边界上犯迷糊。至于 NestJS它的依赖注入和模块系统在设计上很强但对这个项目来说属于杀鸡用牛刀AI 生成的 NestJS 代码反而更容易出现装饰器使用不规范的问题。技术选型不是选最厉害的工具而是选最不容易让 AI“翻车”的工具。2. 环境准备与项目初始化Claude Code 进场前的三个动作2.1 让 AI 理解上下文项目说明文档先行很多人使用 Claude Code 的第一个错误就是打开终端直接开始对话然后说“帮我写一个宠物管理 App”。这样做确实能生成东西但生成出来的东西大概率是“通用版宠物 App”而不是你脑海中的那个产品。原因很简单AI 只能在它被给予的上下文范围内发挥你没有给它关于业务规则、功能边界、目标用户的信息它就默认按照数据库里最普遍的案例去生成。所以我在启动 Claude Code 之前花了接近四十分钟写了一篇项目说明文档放在项目根目录下的 NOTES.md 里。这份文档不需要面面俱到但必须把以下几个问题讲清楚这个项目是什么、核心用户是谁、核心功能有哪些、哪些功能明确不做、数据实体大概有哪些、技术栈选了什么、为什么这样选。这里有一个特别实用的经验写这份文档的过程就是在做“需求澄清”。你以为你很清楚自己要做什么但等你真正要把想法写成文字、而且要让另一个“人”能看懂时你会发现很多之前没想清楚的地方——比如宠物年龄的阶段划分到底以什么标准界定、体重记录是只记录数字还是需要记录体脂率、多个宠物的数据是否需要隔离。这些细节不提前定义清楚后面生成的代码就会反复改动。我在这份文档里明确写了一句“本应用只服务单家庭多宠物场景暂不支持跨家庭共享”只这一句话就让 AI 在后续的数据库设计中自动绕开了用户体系和权限管理这两大复杂度来源。2.2 脚手架搭建与依赖锁定项目说明文档写好后我先手动初始化了前端和后端的工程骨架而不是让 Claude Code 从头执行脚手架命令。这样做不是为了省时间而是为了确保工程结构和工具链版本在自己的掌控范围内。Claude Code 完全可以执行 npm create 之类的命令但如果生成过程中出现版本不兼容或者镜像源问题排查起来比较费劲而这一步只需要花几分钟手动完成。实际操作中我依次执行了以下命令# 创建项目根目录 mkdir pet-lifecycle-app cd pet-lifecycle-app # 前端初始化Vite React npm create vitelatest frontend -- --template react # 后端初始化 mkdir backend cd backend npm init -y前后端初始化完成后安装核心依赖时我特别注意了一点所有直接依赖都明确指定主版本范围不盲目追最新。比如 Express 安装时使用npm install express5确定用比较稳定的主版本Prisma 使用npm install prisma5 --save-dev。这样做的目的是降低“AI 生成的代码和本地依赖版本不匹配”的概率。Claude Code 的知识库有截止时间它可能不知道某个依赖的最新版本 API 已经变了但如果你锁定了版本它生成的代码就会更接近你本地环境能跑的状态。安装完成后我立即提交了一个初始 Git commit确保后续 AI 生成代码的过程中随时可以回滚。这个习惯帮我避免了一次“AI 大幅改动但方向跑偏、只能手动恢复”的灾难。2.3 目录结构与工程规范初始化完之后我建立了一个清晰的目录结构约定。这一步看似不起眼但实际上对 AI 生成代码的一致性影响极大。我在项目说明文档中明确写了目录结构应当遵循的规则前端的主代码放在 src 目录下components 放通用组件pages 放页面级组件services 放 API 请求封装。后端的路由放在 routes 目录业务逻辑放在 services 目录数据访问统一走 Prisma。这个约定对 Claude Code 最重要的价值在于当它需要新增一个文件时会按照约定推断该放在哪里而不是随手生成一个看起来“能运行”但位置混乱的文件。相比之下如果目录结构没有约束AI 非常容易在一个会话里生成三个不同风格的代码组织方式早期生成的放 A 目录中期生成的放 B 目录后期迭代时又搞出一个新目录。最后整个项目变得非常难维护。3. 数据模型与核心业务逻辑宠物生命周期管理的骨架3.1 数据模型设计如何建表才算“真正懂业务”数据模型是整个项目的根基。如果表设计不合理后续所有业务逻辑都会不断返工。我在设计数据模型时没有直接让 Claude Code 自由发挥而是先自己画了核心实体图再由 Claude Code 转化为 Prisma Schema。核心实体就这些宠物档案Pet、疫苗记录Vaccination、驱虫记录Deworming、体检记录Checkup、健康日志HealthLog、提醒记录Reminder。我拿到的 Prisma Schema 经过几轮迭代后最终长这样核心部分截取model Pet { id String id default(cuid()) name String species String // 枚举DOG / CAT此处用字符串简化 breed String? gender String birthDate DateTime weightGram Int // 体重存克避免浮点误差 photoUrl String? createdAt DateTime default(now()) updatedAt DateTime updatedAt vaccinations Vaccination[] dewormings Deworming[] checkups Checkup[] healthLogs HealthLog[] } model Vaccination { id String id default(cuid()) petId String pet Pet relation(fields: [petId], references: [id]) name String // 疫苗名称比如狂犬疫苗 doseCount Int // 第几针 givenAt DateTime // 实际接种时间 dueAt DateTime // 下次到期时间 } model Reminder { id String id default(cuid()) petId String pet Pet relation(fields: [petId], references: [id]) type String // VACCINE / DEWORM / CHECKUP dueDate DateTime isDone Boolean default(false) }这里有两个值得展开讲讲的设计决策。第一个是体重字段用weightGram Int而不是weightKg Float。经验丰富的人应该能立刻意识到这是为了避开浮点数比较误差。宠物体重是需要在图表里展示趋势的如果用 Float 存储千克从 2.3 变为 2.4 这种变化在数据库里其实是很不稳定的表示容易出现 2.3000000000000003 这种尴尬。存克的整数展示时除以 1000既保证精度又避免 AI 生成的聚合查询出现类型问题。第二个设计决策是单独建 Reminder 表而不是在 Vaccination 表上直接加 isDone 字段。原因是提醒的类型不只是疫苗还有驱虫和体检。如果用散落在各业务表上的“是否完成”字段来管理提醒每当用户给宠物记录一次驱虫程序就要同步去把对应 Reminder 标记完成逻辑分散还容易漏。单独的 Reminder 表让提醒机制变成了一个统一的消息队列模型后续扩展“洗澡提醒”“牙齿清洁提醒”只需要增加 type 枚举值不需要改动表结构。3.2 生命周期阶段引擎用代码表达“年龄”宠物生命周期管理最核心的功能是根据出生日期自动识别当前阶段。这个逻辑听起来简单但坑不少。不同物种不同体型的宠物年龄阶段划分标准差异很大。猫和狗的成长期、老年期界定完全不同甚至同一物种里小型犬和大型犬的老化速度也不一样。为了让这个逻辑既实用又不过分复杂我设计了一个配置文件集中管理阶段阈值而不是把判断逻辑散落在代码各处。阈值配置文件如下export const LIFE_STAGE_RULES { DOG: { SMALL: { puppyMonths: 12, adultUntilMonths: 96, seniorFromMonths: 96 }, MEDIUM: { puppyMonths: 12, adultUntilMonths: 84, seniorFromMonths: 84 }, LARGE: { puppyMonths: 12, adultUntilMonths: 72, seniorFromMonths: 72 }, }, CAT: { DEFAULT: { kittenMonths: 12, adultUntilMonths: 84, seniorFromMonths: 84 }, }, };判断逻辑本身是由 Claude Code 生成的一个纯函数输入出生日期和体型配置返回当前阶段。我的提示词是这样写的“根据出生日期计算当前生命阶段幼年/成年/老年的阈值从配置文件中读取注意边界条件——今天是生日的整数倍时应该算新阶段。返回结果需要包含阶段名称和下一阶段切换日期。”AI 生成的第一个版本存在一个常见 bug它用“月差大于阈值”来判断导致当月差恰好等于 12 时宠物还是被归为幼年。修复方式是把改成并补充了恰好处于边界日期时的测试用例。这个细节不是 AI 的智商问题而是需求描述中的“边界”没有说清楚导致的。你让 AI 写“一个计算年龄阶段的函数”它不会主动考虑“恰好一岁生日当天”这种边界情况需要你把边界条件作为明确指令写进去。这就是人机协作中“人负责定义规则AI 负责翻译成代码”的真正含义。3.3 提醒机制从数据到行动的最后一公里提醒是这个 App 最有价值的功能。数据记录得再完整如果用户不知道“驱虫已经过期两周了”那一切白搭。提醒机制的实现我采用了“下次到期日回推”的策略而不是“每天定时扫描一次然后推送当天到期项”。两者看着差不多但实现路径完全不同。采用回推策略后每当用户记录一次疫苗接种或驱虫操作程序就会根据疫苗类型和间隔规则计算下一次到期日期并生成或更新对应 Reminder 记录。Claude Code 生成的核心逻辑是根据上次事件日期和事件周期计算出nextDueDate写入 Reminder 表。前端则在首页展示“即将到期”和“已过期”两类提醒。这里有一个在实操中很容易忽略的点时间计算不能直接用前端本地时间。用户可能出差去了另一个城市本地时区变化会直接导致 Reminder 的到期日偏移。我在后端的提醒计算函数中统一使用 UTC 日期前端展示时再转换本地时区。Claude Code 在最初生成时直接使用了new Date()和本地时区偏移这在单机开发时看不出来但一旦上线就可能出问题。我花了一下午把所有和日期相关的逻辑都改成了基于 UTC 日期的计算并增加了测试用例。这个教训想提醒所有人当 AI 生成的代码涉及的领域逻辑有一定复杂度时“能用”和“正确”之间往往还差着一层专业规范。4. 核心功能实现实录从 AI 生成到可上线的距离4.1 让 Claude Code 批量生成接口与页面准备工作和数据模型定义完成之后才轮到真正的“AI 全流程生成”环节。我的策略是把任务拆成多个子任务每轮只让 Claude Code 完成一个聚合度合适的功能模块而不是一次性让它把整个 App 生成出来。什么是“聚合度合适”举个例子我第一轮的要求是“实现宠物档案的 CRUD 接口以及前端表单页面”第二轮是“实现疫苗记录添加接口并在宠物详情页展示疫苗时间线”第三轮才是“实现提醒列表和到期状态标记”。这样分批执行的好处很明显每一轮生成内容少AI 的上下文窗口不会被大量无关代码填满生成的代码质量和一致性都更高。如果一次让它生成整个应用它很可能会写出一个结构正确但细节粗糙的东西到时候给前端做联调时问题成倍增加。我在对话中给 Claude Code 发出的指令往往包含明确文件清单、功能清单和验收标准。比如请实现宠物档案编辑功能 1. 前端在 pages/AddPetPage.jsx 中新增编辑页路由为 /pets/:id/edit 2. 后端在 routes/petRoutes.js 中新增 PUT /api/pets/:id 接口 3. 编辑页从后端获取宠物当前数据表单修改后提交 4. 宠物详情页增加“编辑”入口按钮 5. 完成后返回修改过的文件列表这一步的关键提示词技巧是告诉 AI“完成后返回修改过的文件列表”。这看起来像废话但实际非常有效。Claude Code 有时会只告诉你“已完成”但没告诉你改了哪些文件有时它会在生成多个文件后遗漏某个文件没有保存。强调返回文件列表相当于给自己留下一份变更台账方便代码审查时快速定位。4.2 手动校准AI 代码拿到的第一时间要改什么Claude Code 生成的代码拿到后第一件事不是测试而是“读代码”。这听起来可能违背了“AI 帮你写代码省时间”的初衷但我必须说你节省的时间在写重复样板代码上不在代码审查上。AI 生成的代码有一个明显共性它能做到语法正确、逻辑大体成立但在工程细节上经常犯错。我总结了这份代码审查清单每次 Claude Code 返回代码时逐项核对props 命名是否统一AI 经常把petId写成id前端使用时容易踩坑。是否有重复的 useEffect 依赖项AI 生成的 React 组件中有一些无效的依赖数组可能引发重复请求。错误处理是弹窗提示还是静默失败AI 默认倾向 console.log 或 alert对真实用户体验考虑不足。API 错误时前端是否处理了 404、500 状态AI 经常只处理正常返回对失败分支不做处理。日期格式使用是否一致前端展示用的格式化了没有后端返回的 ISO 字符串是否被正确转换是否有 TODO 注释AI 在不确定的地方会写 TODO但这实际上是它偷懒的表现要立刻让它补全。我记得有一轮生成宠物列表页时Claude Code 写出的代码有一个问题在宠物信息为空时展示了一个“暂无数据”文案但只有当宠物数组长度为 0 时才会触发。如果用户只有一个宠物且数据尚未加载完成渲染结果就会先闪一下“暂无数据”再加载出内容。这种问题在功能上不影响最终正确性但体验上有瑕疵。我让 Claude Code 修改为“加载中状态、空状态、错误状态”三态分离代码结构立刻清晰了很多。4.3 测试用例与联调不能完全撒手很多时候用 AI 做开发的争议点集中在“AI 写的代码到底能不能信”。我的观点是测试就是让 AI 代码变得可信的工具。Claude Code 能生成代码也能生成测试代码而且它能很好地根据你给出的功能描述补全边界测试用例。在这轮开发中我为生命周期阶段计算函数和后端提醒生成逻辑各写了一套测试。测试不是我来手写的而是让 Claude Code 根据函数定义生成然后我补充关键边界用例。比如阶段计算函数的测试中我强制加入了一个“出生日期为 2024-03-01今天是 2025-03-01预期返回成年”的用例就是为了确保的边界逻辑正确。提醒逻辑的测试中加入了“上次驱虫日期已过期 100 天再记录一次驱虫预期生成新的过期日期和提醒”。这两个用例第一次跑的时候都没过直接逼出了 bug。联调阶段是整个项目中最耗体力的环节。前端调后端接口时经常会遇到 Claude Code 在前端代码中使用了和后端路由不一致的路径。比如后端定义的是/api/pets/:id/checkups前端却在请求/api/pets/:id/checkupRecords。发现这种不一致最快的方式是统一用一个 API 常量文件管理所有路径而不是直接在各组件里写接口字符串。我把这个约定告诉 Claude Code 后后续生成的代码中接口路径统一引用常量这类的“路径不一致”问题基本绝迹。5. 踩坑记录与排查速查表5.1 典型问题与对策问题一“找不到 API Route”。后端明明定义了 GET/api/pets前端访问时却 404。排查后发现 Claude Code 生成后端代码时在 app.js 中把路由放在了静态资源中间件之后导致静态中间件先拦截了/api路径。解决办法是调整路由注册顺序把所有 API 路由放在静态中间件之前。这个坑几乎每个 AI 辅助生成的 Express 项目都会踩。问题二“Prisma 修改 Schema 后没有执行迁移”。Claude Code 修改了 Prisma Schema 后只会生成新代码不会自动执行npx prisma migrate dev。这时如果你直接运行项目会报错“表不存在”或“列不存在”。解决办法是每次让 Claude Code 修改完 Schema 后第一时间手动检查迁移状态并执行迁移命令。我后来养成了习惯每次生成结束后先跑一次npx prisma migrate dev --name auto_sync再启动项目。问题三“前端表单校验过严导致合法输入被拒”。AI 生成的表单校验经常对“必填字段”的理解过于机械。比如用户给宠物填信息时品种字段留空是合法的但 AI 生成的校验规则会让所有 String 类型字段都不能为空。实际上后端 Prisma Schema 里breed字段已经标为可选但前端校验不知道。这个问题只有人工审查才能发现。问题四“AI 在一个文件中写入了过多的组件”。Claude Code 倾向于把所有相关的 UI 代码放在同一个文件中这在前两轮生成时看不出问题但到了后期维护时会很痛苦。我遇到一次它把“宠物列表卡片、宠物详情页、添加宠物表单”全放进了一个 600 行的文件中。解决方法是每轮生成时明确指定文件路径同时把它生成的超大文件拆分成独立组件。我把这些问题整理成一张速查表方便大家查阅症状根因对策接口 404路由注册在中间件之后统一 API 路由优先注册数据未持久化Schema 改后未执行迁移每次生成后跑 migrate 命令合法输入被拒前端校验过严人工检查校验和 Schema 一致性单文件过大难维护AI 合并写入指定文件路径并拆分组件日期提前或延迟一天时区处理不一致后端统一 UTC 计算前端转换界面闪一下空状态缺少加载中状态三态分离加载中优先渲染接口路径对不上硬编码路径无统一管理用常量文件统一管理路径5.2 与 Claude Code 协作的几条独家心得第一永远给它一个具体可观测的验收标准。你写“增加一个提醒功能”它给你一个泛泛的提醒模块你写“当宠物的上次驱虫时间距今超过 90 天时首页提醒卡片显示红色且文案为‘驱虫已过期 N 天’”它才能给你精确到像素和文案的实现。第二及时开启新会话。Claude Code 的上下文窗口有限当一个会话内的内容过多时它会出现“遗忘”早期约定的问题。我的习惯是当对话超过二十轮或者当前任务的文件修改范围明显扩大时就新开一个会话并把 NOTES.md 和上一轮的关键产出摘要作为上下文重新提供给 AI。这能显著减少“它把之前定好的技术方案推翻”的概率。第三让它自己报告风险。我会在每轮任务最后问一句“这一轮改动可能影响哪些已有功能点”。这个提问让 AI 实际运行起来像是一个成员在自报风险而不是一个只会答“已完成”的工具。每轮它给出的风险提示都准确指向了某个我实际上会漏掉的关联改动这比让它写一万行代码更有价值。5.3 性能与安全上容易被忽略的底线即使只是一个小型 App安全和性能底线也不能省。Claude Code 默认生成的代码在安全方面是薄弱的。它生成的 API 没有做任何请求频率限制没有做输入长度校验也没有给宠物图片上传设置文件类型白名单。这些都是需要人工考虑并补充的。对于性能SQLite 在数据量小时表现极好但如果你在上传图片时直接把图片二进制写入数据库一旦宠物照片多了性能就会劣化。我的方案是图片上传到本地静态目录数据库只保存文件路径。这样一个简单的调整后续就不需要为换对象存储或迁移静态文件策略而大改逻辑。提前考虑到这些演进方向是 AI 无法替你完成的因为 AI 的目标是把当前需求实现出来而工程师的目标是让系统在未来半年还能顺利演进。结尾经验比代码更重要这次用 Claude Code 从零搭建宠物生命周期管理 App最大的收获不是最终跑通的代码而是它让我更透彻地理解了“人工定义意图、AI 放大执行”的协作模式。Claude Code 非常擅长处理有明确边界、有清晰上下文的任务它能快速把逻辑变成可运行的项目节约大量样板时间。但它毕竟只是一个能力很强的执行者不会主动替你思考用户的真实处境、数据模型的长期演化、安全和边界情况。说实话如果这次没有提前写清楚 NOTES.md 和验收标准而是上来就让 AI 直接生成整个项目我大概率会收获一堆“看起来能跑但到处都是坑”的代码。现在这套完整流程跑下来后我也更清楚了这类项目的后续扩展方向比如接入宠物医院预约、多宠家庭数据对比、疫苗电子证查验等功能模块这些扩展在当前的数据模型和目录结构基础上都是顺手的事。如果你也在尝试用 AI 搭建完整项目记住这句最核心的经验AI 代码不是终点它只是一个起点——值得花时间在上面加一点人类的边界意识、安全意识和对用户体验的执念。