1. 为什么我选择用 AI 编程助手从零搭建这个宠物生命周期管理 App
宠物生命周期管理这个需求，最早是我在一个养了三只猫的朋友身上看到的。他家老大从接回家到去年走完最后一程，整整十二年，疫苗记录散落在三四个不同的本子里，驱虫时间靠手机日历提醒，体检报告拍完照片就沉在相册最底下，等到真需要查某次血常规数据的时候，翻了整整一个下午。这件事让我意识到，宠物管理类 App 市面上不少，但绝大多数只做"记录"这一层，真正把"生命周期"这条线串起来的很少。
所谓宠物生命周期管理，核心是把一只宠物从接回家、幼年期、成年期、老年期到离世这整条时间轴上的所有关键事件结构化。它和普通的备忘录式宠物记录 App 最大的区别在于：数据之间是有因果和时序关系的。比如幼年期的疫苗完成情况，会直接影响成年期能否办某些手续；老年期的体检频率，应该根据品种和既往病史动态调整。这种"状态机 + 时间轴"的模型，用传统方式手写代码，光是数据模型设计就够折腾好几天。
这次我决定换个思路，全程用 AI 编程助手来驱动开发，从零搭一个完整可跑的新项目。选它的理由很直接：这类 App 的业务逻辑清晰但琐碎，字段多、状态多、边界条件多，正好是 AI 擅长的"结构化生成"场景。而我自己只需要把控架构方向、数据模型和关键决策，把大量重复性的 CRUD、表单校验、状态流转代码交给它生成，效率能提升一大截。
这篇文章我会把整个流程完整拆开：从项目初始化、技术选型、数据模型设计，到核心功能实现、踩坑排查，全部是我实际操作下来的记录。适合两类人看——一类是想用 AI 助手做完整项目但不知道从哪下手的朋友，另一类是想做宠物类工具、对生命周期建模感兴趣的朋友。哪怕你完全没用过 AI 编程助手，跟着走一遍也能跑通。
2. 项目整体设计与技术选型思路拆解
2.1 先想清楚"生命周期"到底怎么建模
动手写代码之前，最值钱的一步是把数据模型想明白。我见过太多人一上来就让 AI "帮我写个宠物 App"，结果生成一堆零散的表单，字段之间毫无关联，后期想加个"根据年龄自动推荐体检项目"的功能，发现根本接不上。
我的做法是先自己画一遍核心实体关系，再把这个设计喂给 AI。宠物生命周期管理的核心实体其实就四个：
- Pet（宠物）：基础档案，包含品种、出生日期、性别、绝育状态、芯片号等
- Event（事件）：时间轴上的一个点，比如接种疫苗、驱虫、体检、洗澡、体重记录、离世
- EventType（事件类型）：定义每类事件的元数据，比如疫苗需要"疫苗名称+批号+下次接种时间"，体检需要"医院+报告附件+各项指标"
- Reminder（提醒）：由事件派生出来的待办，比如"距离下次驱虫还有 3 天"
这里有个关键设计决策：Event 用统一表 + 类型扩展字段，而不是每类事件建一张表。原因是生命周期管理最核心的操作是"按时间轴展示全部事件"，如果分表，每次查询都要 union 五六张表，性能和代码复杂度都上去了。统一表 + JSON 扩展字段的方案，查询简单，扩展也灵活。这个决策我明确告诉了 AI，让它按这个模型生成，而不是让它自由发挥。
提示：让 AI 生成代码前，一定要先把数据模型和关键约束讲清楚。你给的信息越结构化，它生成的代码越接近可用状态，返工越少。
2.2 技术栈选择：为什么是这套组合
技术选型我遵循一个原则：AI 助手对主流技术栈的生成质量最高，冷门框架容易生成过时或错误的 API。所以我没有追求新奇，而是选了生态成熟、文档丰富的组合。
| 层级 | 选型 | 选择理由 |
|---|---|---|
| 前端框架 | React + TypeScript | AI 对 TS 类型推导支持好，能生成带完整类型的组件 |
| 状态管理 | Zustand | 比 Redux 轻，AI 生成样板代码少，不易出错 |
| 本地存储 | SQLite（通过 ORM） | 宠物数据敏感且需离线可用，本地库最稳 |
| 后端（可选同步） | Node.js + 轻量框架 | 与前端同语言，AI 上下文连贯 |
| UI 组件 | 主流组件库 | 组件 API 稳定，AI 生成不易踩废弃 API |
这里重点说下为什么用 TypeScript 而不是 JavaScript。宠物生命周期管理里，事件类型和字段的组合非常多，用 TS 的联合类型和判别联合（discriminated union）能把"疫苗事件一定有批号、体检事件一定有报告"这类约束在编译期就卡住。AI 生成 TS 代码时，只要我把类型定义给全，它生成的业务逻辑基本不会出现字段拼写错误这种低级问题。实测下来，TS 项目的 AI 生成可用率比 JS 高出不少。
2.3 用 AI 驱动开发的整体节奏
我把整个开发分成五个阶段，每个阶段给 AI 的输入和期望输出都不一样：
- 脚手架阶段：让 AI 生成项目结构、依赖清单、基础配置
- 数据层阶段：基于我给的实体模型，生成 ORM 定义、迁移脚本、基础 CRUD
- 业务逻辑阶段：生成生命周期状态流转、提醒计算、统计聚合
- UI 阶段：生成页面组件、表单、时间轴视图
- 联调与修复阶段：把报错信息喂给 AI，让它定位并修复
这个节奏的核心是分阶段、小步验证。千万不要一次性让 AI 生成整个项目，那样出来的东西你根本不知道哪里对哪里错，排查成本极高。每完成一个阶段，我都会本地跑一遍，确认没问题再进入下一阶段。
3. 核心细节解析与实操要点
3.1 项目初始化：给 AI 的第一条指令怎么写
第一条指令决定了整个项目的骨架质量。我实际用的指令大致是这样的结构：先说明项目类型和技术栈，再给出目录结构要求，最后明确约束。
# 我实际让 AI 生成的项目结构（简化版） pet-lifecycle/ ├── src/ │ ├── db/ # 数据库定义与迁移 │ ├── models/ # 实体类型定义 │ ├── services/ # 业务逻辑 │ ├── stores/ # 状态管理 │ ├── components/ # 通用组件 │ ├── pages/ # 页面 │ └── utils/ # 工具函数 ├── tests/ └── package.json关键点在于，我没有让 AI 直接开始写业务代码，而是先让它只生成目录结构和空的类型定义文件。这一步看起来多余，实际上非常值。因为目录结构一旦定下来，后面所有生成的代码都会往这个框架里填，不会出现"文件到处乱放"的问题。
注意：AI 助手很容易"过度热情"，你让它建项目，它可能一口气把登录、首页、设置页全写了。一定要在指令里明确"本阶段只做 X，不要生成 Y"。我一般会加一句"只输出目录结构和类型定义，不要生成任何业务逻辑代码"。
3.2 数据模型定义：类型先行，逻辑后补
数据模型是整个项目的根。我先把前面想好的四个核心实体写成 TypeScript 类型，再让 AI 基于这些类型生成 ORM 定义。
// 核心类型定义（我手写后交给 AI 扩展） type PetSpecies = 'cat' | 'dog' | 'other'; interface Pet { id: string; name: string; species: PetSpecies; breed: string; birthDate: string; // ISO 日期 gender: 'male' | 'female'; neutered: boolean; chipId?: string; adoptedAt: string; status: 'active' | 'deceased'; } type EventCategory = | 'vaccine' | 'deworming' | 'checkup' | 'weight' | 'grooming' | 'memorial'; interface PetEvent { id: string; petId: string; category: EventCategory; occurredAt: string; note?: string; payload: Record<string, unknown>; // 类型专属字段 }这里有个我踩过的坑：一开始我把payload定义成any，结果 AI 生成业务代码时到处乱塞字段，后期完全失控。改成Record<string, unknown>后，虽然还是要手动断言，但至少强制了"先想清楚再塞"的习惯。更好的做法是用判别联合，把每类事件的 payload 类型都定义清楚，这样 AI 生成的代码类型安全度会高很多。
3.3 生命周期状态流转：最容易出错的地方
宠物生命周期里，"状态"这个词有两层含义。一层是宠物本身的status（在世/离世），另一层是各类事件的"到期状态"（比如疫苗是否过期）。这两层状态的计算逻辑完全不同，混在一起写必出 bug。
我的处理方式是：宠物状态是显式存储的字段，事件到期状态是实时计算的派生值。为什么这么设计？因为宠物状态变更频率极低（一生就变一两次），存下来查询快；而事件到期状态每天都在变，存下来就要写定时任务去刷新，反而复杂。实时计算虽然每次查询都要算，但逻辑简单、不会出现"数据不一致"。
// 事件到期状态计算（AI 生成后我调整过） function getEventStatus(event: PetEvent, now: Date): 'valid' | 'due-soon' | 'overdue' { const nextDue = event.payload.nextDueAt as string | undefined; if (!nextDue) return 'valid'; const diffDays = daysBetween(now, new Date(nextDue)); if (diffDays < 0) return 'overdue'; if (diffDays <= 7) return 'due-soon'; return 'valid'; }这段逻辑看着简单，但 AI 第一版生成的时候把diffDays < 0写成了diffDays <= 0，导致当天到期的疫苗被判定为已过期。这种边界问题非常典型，AI 生成的日期比较逻辑一定要手动核对，尤其是<和<=这种。
3.4 提醒系统：别用轮询，用派生
提醒功能我一开始想得很复杂，打算做个后台任务定时扫描。后来想明白了：提醒本质上就是"到期状态为 due-soon 或 overdue 的事件集合"，完全可以在读取时实时派生，根本不需要后台任务。
这个决策省掉了整个定时任务模块，代码量少了一大半，而且不会出现"任务没跑导致提醒丢失"的问题。唯一的代价是每次打开 App 要算一遍，但宠物的事件数量通常就几十条，计算量可以忽略。
实操心得：能用派生解决的问题，就不要引入存储和定时任务。每引入一个后台任务，你就多了一个可能出故障、需要监控、需要处理并发的地方。宠物类 App 的数据量小，实时计算完全扛得住。
4. 实操过程与核心环节实现
4.1 数据库层：让 AI 生成迁移脚本的正确姿势
数据库层我用的 ORM 支持声明式 schema 和自动迁移。给 AI 的指令是："基于以下类型定义，生成 ORM schema 和初始迁移脚本，字段类型映射要准确，日期统一用 ISO 字符串存储。"
AI 生成的 schema 大体没问题，但有几个细节需要我手动修正：
- 索引缺失：AI 默认不建索引。但
PetEvent表按petId和occurredAt查询极其频繁，必须建复合索引。我手动加了index(['petId', 'occurredAt'])。 - 外键约束：AI 生成的 schema 里
petId只是个普通字段，没有外键约束。我补上了级联删除，避免删除宠物后留下孤儿事件。 - 日期字段类型：AI 一开始用了数据库原生日期类型，但跨时区处理麻烦，我统一改成 ISO 字符串存储。
// 修正后的 schema 片段 const petEvents = sqliteTable('pet_events', { id: text('id').primaryKey(), petId: text('pet_id') .notNull() .references(() => pets.id, { onDelete: 'cascade' }), category: text('category').notNull(), occurredAt: text('occurred_at').notNull(), note: text('note'), payload: text('payload', { mode: 'json' }).notNull(), }, (table) => ({ petTimeIdx: index('pet_time_idx').on(table.petId, table.occurredAt), }));索引这一条特别值得说。我实测过，一万条事件数据下，没索引的时间轴查询要 200ms 以上，加了复合索引后降到 5ms 以内。宠物 App 虽然数据量不大，但用户对流畅度的感知很敏感，这个优化性价比极高。
4.2 业务逻辑层：状态流转与统计聚合
业务逻辑层是整个项目最考验设计的地方。我把它拆成三个 service：PetService、EventService、StatsService。
PetService负责宠物档案的增删改查和状态变更。这里有个业务规则：宠物标记为离世后，不允许再新增普通事件，但允许新增纪念类事件。这个规则我明确写进了给 AI 的指令里，它生成的校验逻辑基本正确。
EventService负责事件的增删改查和到期状态计算。这里 AI 帮了大忙——它自动帮我处理了"新增疫苗事件时，如果 payload 里带了 nextDueAt，自动生成一条对应的提醒记录"这种联动逻辑。不过它第一版把联动写在了数据库触发器里，我改成了应用层处理，因为触发器调试困难，应用层逻辑更透明。
StatsService负责统计聚合，比如"过去一年体重变化曲线""疫苗完成率""各类型事件数量分布"。这部分 AI 生成得相当不错，尤其是聚合查询的 SQL，比我自己写还规范。
// 体重趋势统计（AI 生成，我微调了排序） async function getWeightTrend(petId: string, months: number) { const since = subMonths(new Date(), months).toISOString(); const events = await db.query.petEvents.findMany({ where: and( eq(petEvents.petId, petId), eq(petEvents.category, 'weight'), gte(petEvents.occurredAt, since), ), orderBy: asc(petEvents.occurredAt), }); return events.map(e => ({ date: e.occurredAt, weight: (e.payload as { weight: number }).weight, })); }4.3 UI 层：时间轴视图是灵魂
宠物生命周期 App 的 UI 灵魂是时间轴视图。用户打开 App 第一眼要看到的就是"这只宠物从到家到现在，所有重要事件按时间排列"。这个视图做好了，整个 App 的体验就立住了。
时间轴我用的是虚拟列表 + 分组渲染。按年份分组，每组内按时间倒序排列事件卡片。AI 生成这个组件时，我给了它明确的结构要求：每个事件卡片要显示图标、标题、日期、到期状态徽章，点击展开详情。
这里有个性能细节：事件卡片不要一次性全渲染。我一开始没注意，测试数据塞了 500 条事件，页面直接卡死。后来改成虚拟列表，只渲染可视区域内的卡片，瞬间流畅。AI 生成虚拟列表代码时容易漏掉"动态高度"的处理，如果你的卡片高度不固定，一定要提醒它用支持动态高度的虚拟列表方案。
注意：AI 生成的 UI 组件往往"能用但不好看"。我的做法是让它先保证功能正确，样式我自己调。指望 AI 一次生成精美 UI 不现实，但让它生成结构正确、逻辑无误的组件，它做得很好。
4.4 联调阶段：把报错喂给 AI 的正确方式
联调阶段是 AI 助手价值最大的地方。我的做法是：报错信息 + 相关代码 + 我的猜测，三样一起喂给它。
单纯丢一句"报错了"给 AI，它只能瞎猜。但如果你把完整的错误堆栈、出错的代码片段、以及你怀疑的方向都给它，它定位问题的准确率会高很多。我实测下来，这种"带上下文"的提问方式，一次修复率能到七八成。
举个真实例子：有次时间轴渲染报Cannot read property 'weight' of undefined。我把错误、getWeightTrend函数、以及"我怀疑是 payload 里没有 weight 字段"一起发给 AI，它立刻指出：体重事件如果用户没填数值，payload 里就没有 weight，需要在 map 时做空值过滤。这个判断非常准。
5. 常见问题与排查技巧实录
5.1 AI 生成代码的典型问题速查表
用 AI 助手做完整项目，踩的坑其实很有规律。我整理了一张速查表，基本覆盖了我遇到的大部分问题：
| 问题类型 | 典型表现 | 排查与解决 |
|---|---|---|
| 边界条件错误 | 日期比较用错<和<= | 手动核对所有比较逻辑，补测试用例 |
| 索引缺失 | 查询慢，数据量大后卡顿 | 检查高频查询字段，手动补索引 |
| 类型过宽 | 用any导致字段失控 | 强制用具体类型或判别联合 |
| 过度设计 | 引入不必要的后台任务 | 能用派生解决就不存储 |
| API 过时 | 用了废弃的库方法 | 核对官方文档，让 AI 按最新版重写 |
| 空值未处理 | 可选字段直接访问报错 | 所有可选字段访问前做空值判断 |
| 并发问题 | 同时写入导致数据错乱 | 关键写操作加事务 |
5.2 三个我踩过的真实坑
第一个坑：日期时区。我一开始用本地时间存occurredAt，结果用户跨时区使用时，事件日期全乱了。后来统一改成 UTC 存储、展示时转本地时区。这个坑 AI 不会主动帮你避，因为它在生成代码时默认不考虑时区，你得自己提。
第二个坑：级联删除。删除宠物时，AI 生成的代码只删了宠物记录，没删关联事件，导致数据库里堆了一堆孤儿数据。后来补了外键级联删除才解决。这个问题的隐蔽性在于，它不会立刻报错，而是慢慢积累脏数据。
第三个坑：提醒重复。我让 AI 生成"新增疫苗事件时自动生成提醒"，结果它每次保存事件都生成一条新提醒，编辑一次事件就多一条提醒。后来改成"先删旧提醒再生成新提醒"，才解决重复问题。这类"幂等性"问题，是 AI 生成代码的高发区。
实操心得：AI 生成的写操作逻辑，一定要问自己一句"这个操作重复执行会怎样"。如果答案不是"结果一样"，那就有幂等性问题，需要加去重或先删后插。
5.3 让 AI 帮你写测试，但别全信
AI 生成单元测试的效率很高，尤其是边界条件的测试用例，它列得比我还全。但我发现一个问题：AI 生成的测试有时会"迎合"它自己写的错误代码。也就是说，如果它的业务逻辑写错了，它生成的测试可能也是按错误逻辑写的，测试全绿但功能是错的。
我的应对方法是：关键业务逻辑的测试用例，我自己先写一遍预期结果，再让 AI 补全测试代码。这样测试的"预期"是我定的，AI 只负责实现测试，就不会出现"自己测自己"的问题。
6. 这套流程跑下来的一些个人体会
整个项目从零到能跑，我大概花了三个晚上。如果纯手写，保守估计要一周以上。AI 助手省下的主要是重复劳动——表单、CRUD、类型定义、测试骨架这些，但架构决策、数据模型、边界处理这些真正费脑子的地方，还是得自己扛。
我最大的体会是：AI 助手不是"帮你写代码"，而是"帮你把想法快速变成可运行的草稿"。草稿的质量取决于你给它的输入质量。你数据模型想得越清楚，它生成的代码越可用；你需求描述得越模糊，它给你的东西越像"看起来对但用不了"的样板。
另外一点，宠物生命周期管理这类 App，真正的难点从来不在技术，而在对"生命周期"这个业务概念的理解。你得真的养过宠物、或者跟养宠物的人聊过，才知道哪些事件重要、哪些提醒有用、哪些数据用户真的会看。AI 能帮你实现，但帮不了你理解用户。这部分，还是得靠人。
后续如果继续扩展，我打算加两个方向：一是多宠物对比视图，让养多只宠物的用户能横向看数据；二是数据导出，把整条生命周期导出成一份可打印的纪念册。这两个功能都不难，有了现在这套数据模型，加起来的成本很低。
