企业官网建设流程全解析

1. 为什么我决定用 AI 编程助手从零搭一个宠物生命周期管理 App

先说说这个项目的来龙去脉。我手上一直有个想法：做一个宠物生命周期管理 App，覆盖从领养/购买、疫苗接种、驱虫、体检、发情/绝育、配种/繁育、日常喂养记录，到老年护理、临终关怀、离世纪念的完整链路。市面上大多数宠物类 App 只做单点功能，比如只做疫苗提醒，或者只做社区晒图，真正把"一只宠物从进家门到离开"这条时间线完整串起来的产品非常少。而这条时间线恰恰是养宠人最真实的需求——你养一只猫十五年，这十五年里所有关键节点如果有一个工具能帮你记住、提醒、归档，价值是巨大的。

但问题也很现实：我一个人，既要做产品设计，又要写前后端，还要处理数据模型和提醒调度，传统开发方式下这个项目至少拖三个月。所以这次我换了个思路——用 AI 编程助手（Claude Code 这类终端里的智能编码工具）作为主力开发伙伴，我负责定架构、做决策、验收结果，它负责把大量重复性、模板化的代码写出来。整个项目从空目录到能跑起来的第一版，我实际投入的纯编码时间压缩到了几天级别。

这篇文章就是把这套"从零搭建新项目全流程 AI 实现"的完整过程拆开讲。我会讲清楚：项目整体怎么设计、数据模型为什么这么定、AI 助手在每个环节怎么用、哪些地方它靠不住必须自己兜底、以及踩过的那些坑。适合两类人看：一是想用 AI 助手提效但不知道怎么下手的开发者，二是想做宠物类工具但被工作量劝退的独立开发者。哪怕你完全没用过 AI 编程工具，跟着思路也能复现。

需要先说明一点：AI 助手不是"你说一句话它给你一个 App"，它的价值在于把你从"打字"里解放出来，让你专注在"想清楚"上。想不清楚的地方，它只会更快地帮你写出错误的代码。所以下面我会花不少篇幅讲设计决策，这些才是项目能不能成的关键。

2. 项目整体设计与技术选型拆解

2.1 核心需求拆解：宠物生命周期到底包含哪些阶段

在动手写第一行代码之前，我做的第一件事是把"宠物生命周期"这个词拆成可落地的功能模块。这一步如果偷懒，后面数据模型一定返工。我按时间轴把一只宠物的一生分成几个阶段，每个阶段对应不同的数据实体和提醒逻辑：

• 入门阶段：宠物档案建立（品种、生日、性别、绝育状态、芯片号、来源）、主人信息绑定。
• 幼年阶段：疫苗接种计划（多联苗、狂犬苗，按周龄排期）、驱虫计划（体内/体外，按月/季度）、体重曲线记录。
• 成年阶段：年度体检、发情周期记录、绝育手术记录、日常喂养与体重管理。
• 繁育阶段（可选）：配种记录、孕期跟踪、产仔记录。
• 老年阶段：慢性病用药记录、复诊提醒、护理日志。
• 终末阶段：临终关怀记录、离世日期、纪念页。

拆完之后我发现，这里面真正有技术难度的不是 CRUD，而是时间驱动的提醒系统。疫苗要按周龄算，驱虫要按周期滚动，体检要按年提醒，用药要按天多次。这些全是"基于某个基准日期 + 规则"推导出来的未来事件。所以整个 App 的核心其实是一个"事件调度引擎"，而不是一个简单的记录本。这个判断直接决定了后面的架构。

提示：做任何"生命周期""计划""跟踪"类产品，先问自己一句——这个产品的核心是存储还是调度？如果是调度，那你的数据模型必须围绕"规则 + 基准时间"来设计，而不是围绕"记录"来设计。这是最容易返工的地方。

2.2 技术选型：为什么选这套组合

技术选型我遵循一个原则：AI 助手越熟悉的栈，生成质量越高。主流、文档多、社区大的技术，AI 训练数据里覆盖得充分，写出来的代码越靠谱。所以我刻意避开了小众框架。

最终选型如下：

这里重点说两个决策。第一，为什么用 Prisma 而不是手写 SQL。因为宠物生命周期的表关系比较复杂（宠物、疫苗记录、提醒、用户多对多），手写 SQL 和迁移脚本很容易出错，而 Prisma 的 schema 是声明式的，我只要把实体关系描述清楚，AI 助手就能生成对应的查询代码和迁移，出错率大幅下降。第二，为什么提醒不用消息队列。很多人一上来就上 Redis + 延迟队列，但第一版用户量根本撑不到那个规模，node-cron 每分钟扫一次待触发事件表，简单、可调试、可回溯，等真有性能问题再换也不迟。

2.3 用 AI 助手做架构设计：怎么问才有用

很多人用 AI 编程助手的方式是"帮我写个宠物 App"，然后得到一堆没法用的代码。正确的用法是把大问题拆成有明确输入输出的决策问题。我实际用的提问模式是这样的：

我要设计一个宠物生命周期管理系统的数据模型。 核心实体：用户、宠物、疫苗记录、驱虫记录、提醒事件。 约束： 1. 一只宠物属于一个用户，但支持转移 2. 疫苗记录要能推导出下一次接种时间 3. 提醒事件要能关联到具体宠物和具体类型 请给出 Prisma schema，并说明每个字段的设计理由。

注意我给了约束条件。AI 助手在没有约束时会给你一个"通用但没用"的答案，给了约束它才会认真设计。而且我要求它"说明设计理由"，这样我能判断它的设计是否合理，而不是盲目接受。这一步产出的 schema 我改了三轮才定稿，但每一轮都是我在做判断，AI 在提供选项，这个分工是对的。

3. 核心数据模型与提醒引擎的实现细节

3.1 数据模型设计：围绕"规则 + 基准时间"

前面说了核心是调度，所以数据模型分两类：事实表（已经发生的事，比如打了一针疫苗）和规则表（应该发生的事，比如每 21 天打下一针）。事实表记录历史，规则表推导未来。两者通过宠物 ID 关联。

宠物主表的关键字段设计如下：

model Pet { id String @id @default(cuid()) name String species String // cat / dog / other breed String? birthday DateTime? gender String neutered Boolean @default(false) chipNo String? ownerId String status String @default("active") // active / deceased createdAt DateTime @default(now()) records Record[] reminders Reminder[] }

这里有几个设计点值得说。birthday允许为空，因为很多领养宠物不知道确切生日，只能估算，所以后面所有基于年龄的计算都要处理"生日未知"的情况。status字段用字符串而不是布尔值，是为了将来扩展（比如"送养中"），布尔值扩展性太差。chipNo是芯片号，用于唯一标识，但允许为空因为不是所有宠物都植入了。

疫苗记录表我设计成"一次接种一条记录"，而不是"一个疫苗计划一条记录"。因为实际中疫苗可能延迟、可能换品牌、可能补打，用计划表去覆盖这些情况会非常别扭。每条记录包含疫苗类型、接种日期、下次建议日期、批次号、接种机构。下次建议日期可以由规则推导，也允许手动覆盖——这一点很重要，因为兽医有时会根据宠物具体情况调整间隔。

3.2 提醒引擎：从基准日期推导未来事件

提醒引擎是整个项目最核心也最容易写错的部分。我的实现思路是：不预先存储所有未来提醒，而是存储规则，运行时按需展开。为什么？因为如果用户改了宠物的生日，或者补录了一条疫苗记录，所有预生成的提醒都要重算，维护成本极高。而存规则的话，只需要在读取时重新推导即可。

核心推导逻辑用伪代码表示：

function generateVaccineReminders(pet: Pet, lastVaccine: Record): Reminder[] { if (!lastVaccine.nextDueDate) return []; const dueDate = lastVaccine.nextDueDate; return [{ petId: pet.id, type: 'vaccine', title: `${pet.name} 疫苗接种提醒`, dueAt: dueDate, advanceDays: [7, 1], // 提前 7 天和 1 天各提醒一次 status: 'pending' }]; }

advanceDays这个设计是我踩坑之后加的。一开始我只存一个到期日，结果用户反馈"到期当天才提醒太晚了，我根本约不到兽医"。所以改成支持多个提前提醒点，到期日当天再提醒一次。这个字段用数组存储，读取时展开成多条通知任务。

驱虫提醒的逻辑类似，但周期不同：体外驱虫通常每月一次，体内驱虫每季度一次。我用一个intervalDays字段统一表达，体外填 30，体内填 90。这样一套引擎能覆盖多种周期型提醒，不用为每种类型写一套逻辑。

注意：时间计算一定要用 UTC 存储、按用户时区展示。我第一版直接用本地时间存，结果跨时区测试时提醒全乱了。所有DateTime字段统一存 UTC，展示层再转换，这是铁律。

3.3 用 AI 助手写核心逻辑：怎么保证它不跑偏

提醒引擎这种有明确规则、有边界条件的逻辑，是 AI 助手最擅长的。但我不会直接说"帮我写提醒引擎"，而是先让它写测试用例，再让它写实现。顺序很重要。

我实际的做法是：先描述清楚规则，让 AI 生成一组测试用例（比如"生日未知时不应生成年龄相关提醒""疫苗记录被删除后对应提醒应消失"），我审核测试用例是否覆盖了我关心的场景，确认后再让它写实现去通过测试。这样做的原因是，测试用例是需求的具象化，审核测试比审核代码容易得多。如果直接审代码，很容易被一堆实现细节带偏，漏掉需求层面的问题。

实测下来，这套"先测试后实现"的流程让 AI 生成的提醒逻辑一次通过率从大概一半提升到了八成以上。剩下两成是边界情况，比如闰年、月末日期（1 月 31 日加一个月是几号），这些我会手动补测试再让它修。

4. 完整实操流程：从空目录到可运行的第一版

4.1 环境初始化与项目骨架搭建

第一步是建项目骨架。我没有手动一个个建文件，而是让 AI 助手根据我的技术选型生成目录结构和基础配置。我给的指令大意是：用 React + TypeScript + Express + Prisma 搭一个 monorepo，前端在apps/web，后端在apps/api，共享类型放packages/shared。

这里有个经验：monorepo 对 AI 助手特别友好，因为前后端共享类型定义，AI 在写前端调用后端接口时能直接引用共享类型，不会出现字段名对不上的低级错误。我第一版没做 monorepo，前后端类型各写各的，结果接口字段改了前端没同步，调了半天。

初始化完成后，我让 AI 生成了一份README，写清楚每个目录的职责和启动命令。这份 README 后面成了我给 AI 的"上下文锚点"——每次开新会话，我先把 README 贴给它，它就能快速理解项目结构，不用我反复解释。

4.2 数据库迁移与种子数据

骨架搭好后，先做数据库。我把前面定稿的 Prisma schema 交给 AI，让它生成迁移脚本和种子数据。种子数据这一步很多人会跳过，但我强烈建议做，因为没有种子数据你没法验证提醒引擎。我让 AI 生成了三只测试宠物：一只有完整疫苗记录的成年猫、一只生日未知的领养狗、一只进入老年期的猫。这三只覆盖了主要的边界情况。

种子数据生成后，我跑了一次迁移，然后用 Prisma Studio 打开数据库肉眼检查了一遍。这里发现一个问题：AI 生成的种子数据里，疫苗的下次接种日期是写死的，而不是根据接种日期和规则推导的。这会导致测试数据和真实逻辑不一致。我让它改成调用推导函数生成，这样种子数据本身就是对引擎的一次验证。

4.3 后端接口实现与联调

后端接口我按资源划分：宠物 CRUD、记录 CRUD、提醒查询。每个接口我都让 AI 先生成路由和控制器，再生成对应的请求校验（用 zod）。校验这一步不能省，因为前端传参不可信，而且 AI 生成的校验规则经常漏字段，我会对照 schema 逐个核对。

联调阶段我用了一个小技巧：让 AI 生成一份 HTTP 请求集合（类似 REST Client 的.http文件），每个接口一个示例请求。这样我不用打开前端就能测后端，改完接口直接点一下请求看结果，效率比来回切前端高很多。这份请求集合后来也成了回归测试的基础。

4.4 前端页面与提醒展示

前端我做了三个核心页面：宠物列表、宠物详情（时间轴视图）、提醒中心。时间轴视图是重点，它把宠物的所有记录按时间倒序排列，让用户一眼看到"这只宠物经历了什么"。这个视图的数据来自后端一个聚合接口，把疫苗、驱虫、体检记录合并后按时间排序返回。

提醒中心展示所有待触发和已触发的提醒，支持标记完成和稍后提醒。这里我让 AI 生成了一个提醒卡片组件，但它的第一版设计把"到期日"和"提前提醒日"混在一起显示了，用户看了会困惑。我改成主显示到期日，提前提醒作为副信息用小字标注，清晰多了。AI 生成的 UI 往往功能对但信息层级乱，这部分必须人来调。

5. 常见问题与排查技巧实录

5.1 AI 助手用起来最坑的几个地方

用 AI 编程助手做完整项目，我踩的坑集中在几类。第一类是上下文丢失：会话太长之后，AI 会忘记前面定好的约定，比如字段命名规范、错误处理方式。解决办法是定期开新会话，并把关键约定写进一个CONVENTIONS.md，每次开新会话先贴给它。第二类是过度设计：你让它写个简单函数，它给你整出一堆抽象层和设计模式。这时候要明确说"用最简单直接的实现，不要引入额外抽象"。第三类是幻觉 API：它会调用一些不存在的库方法。这个只能靠跑起来验证，所以小步快跑、频繁运行比一次性写一大堆再调试要稳得多。

5.2 时间与提醒相关的典型 Bug 速查

提醒系统的时间 Bug 特别多，我整理了一张速查表：

这张表是我实际调试中一条条攒出来的。其中"月末日期计算错误"最隐蔽，比如 1 月 31 日加一个月，手写new Date(y, m+1, 31)会得到 3 月 3 日而不是 2 月 28 日。用成熟的日期库（如 date-fns 的addMonths）能自动处理，别自己算。

5.3 让 AI 助手帮你排查 Bug 的正确姿势

遇到 Bug 时，很多人直接把报错丢给 AI 说"帮我修"。这样效果一般，因为 AI 看不到上下文。我的做法是提供三样东西：完整的报错堆栈、触发报错的最小复现步骤、相关代码片段。有了这三样，AI 定位问题的准确率会高很多。另外我会要求它"先解释原因再给修复方案"，这样我能判断它是不是真的理解了问题，而不是碰运气改代码。有几次它给的修复方案能跑通但治标不治本，我追问原因后才发现它没理解根本问题，及时纠正了方向。

6. 我在这套流程里真正学到的东西

做完这个项目，我最大的体会是：AI 编程助手的价值不在于"替你写代码"，而在于"替你承担试错成本"。以前我改一个数据模型要手动改十几处代码，现在改 schema 让 AI 同步，几分钟搞定，于是我更愿意去尝试不同的设计，最终方案反而更好。但前提是你自己得想清楚要什么——想不清楚，AI 只会让你更快地走进死胡同。

另一个体会是关于"验收"。AI 生成的代码你必须真的跑一遍、点一遍、看一遍，不能只看它说"已完成"。我养成了一个习惯：每个功能做完，先自己手动走一遍主流程，再让 AI 补自动化测试。手动走一遍能发现 AI 和测试都覆盖不到的体验问题，比如提醒卡片信息层级乱这种，测试是测不出来的。

最后分享一个我一直在用的小技巧：把项目里所有"约定"和"踩过的坑"记在一个NOTES.md里，每次开新会话先贴给 AI。这个文件越攒越厚，AI 的表现也越来越稳。它本质上是你和 AI 之间的"团队记忆"，比任何提示词技巧都管用。这个宠物 App 后面我还想加多宠物家庭共享、兽医端只读视图、纪念页导出这些功能，有了这套流程和记忆文件，扩展起来心里有底。