企业官网建设流程全解析

1. 为什么我选择用 AI 辅助从零搭建一个宠物生命周期管理 App

先说清楚这个项目到底在做什么。宠物生命周期管理 App，核心就是把一只宠物从接回家到最终离世的全过程数字化——疫苗记录、驱虫提醒、体重曲线、就诊档案、用药历史、纪念日，甚至到最后的身后事安排。这个赛道看起来小众，但养宠的人都知道，纸质本子记着记着就丢了，微信收藏翻半天找不到，换一家医院又得从头讲病史。所以这个 App 解决的是"信息散落、提醒靠脑、就医靠嘴"这三个真实痛点。

适合谁看这篇内容？如果你是有一定编程基础、想用 AI 编程工具从零起一个完整项目的开发者，或者你是产品经理、独立开发者，想看看 AI 辅助开发到底能走到哪一步，这篇都值得读。我会把整个流程拆到能直接抄作业的程度，包括我怎么跟 AI 对话、怎么定数据结构、怎么处理它给的不靠谱代码，以及踩过的那些坑。

我用的核心工具是 Claude Code，一个跑在终端里的 AI 编程助手。它跟网页版对话最大的区别是：它能直接读写你本地的文件、执行命令、跑测试，相当于一个能动手的结对程序员。这一点对"从零搭建项目"特别关键，因为新项目最烦的就是一堆样板文件、目录结构、依赖配置，这些重复劳动交给它，我专注在业务逻辑上。

整个项目我大概花了三个晚上，从空目录到一个能跑起来、有基本增删改查和提醒功能的 App 雏形。下面我把完整流程、关键决策和踩坑记录全部摊开讲。

2. 项目整体设计与技术选型思路

2.1 先想清楚"生命周期"到底分几个阶段

动手写代码之前，我做的第一件事不是打开编辑器，而是拿张纸把宠物的生命周期阶段列出来。这个动作很关键，因为数据结构是跟着业务阶段走的，阶段没想清楚，后面表结构一定反复改。

我把它分成五个阶段：幼年期（0-1 岁，疫苗密集、驱虫频繁）、成年期（1-7 岁，常规体检、体重管理）、中老年期（7 岁以上，慢病筛查、用药记录）、临终关怀期（重大疾病、生活质量评估）、纪念期（离世后的纪念日、照片、回忆）。每个阶段需要记录和提醒的内容完全不同，幼年期提醒密度最高，纪念期则更偏情感化功能。

为什么这么分？因为提醒逻辑是跟着阶段变的。幼年期可能每两周就要提醒一次疫苗或驱虫，成年期可能半年一次体检，如果用一个统一的提醒频率，用户体验会很差。所以我在设计时给每个阶段配了不同的"提醒模板"，这是后面 AI 生成代码时我反复强调的一个约束。

2.2 技术栈怎么定：让 AI 有明确的边界

技术选型这块我踩过一个坑。第一次我直接跟 AI 说"帮我搭一个宠物管理 App"，它给我生成了一堆 React Native 的代码，但我本地根本没配移动端环境，跑都跑不起来。后来我改成明确指定技术栈，效率立刻上来了。

最终我选的是：前端用 React + Vite + TypeScript，后端用 Node.js + Express，数据库用 SQLite（本地开发阶段够用，后期可换 PostgreSQL），提醒功能先用本地定时任务模拟。为什么这么选？因为这套组合对 AI 来说"训练数据充足"，它生成的代码质量明显更高，而且全是 JS/TS 生态，前后端语言统一，我一个人维护成本最低。

提示：选技术栈时优先选 AI 熟悉的、社区资料多的，不要为了炫技选冷门框架。AI 对主流栈的代码生成准确率能高出不少，这是实测感受。

2.3 目录结构先定好，别让 AI 自由发挥

新项目最容易乱的就是目录。我一开始让 AI 自己决定结构，结果它把路由、模型、工具函数全塞在一个文件夹里，找起来要命。第二次我直接给了它一个明确的目录约定：

pet-lifecycle-app/ ├── client/ # 前端 │ ├── src/ │ │ ├── components/ │ │ ├── pages/ │ │ ├── hooks/ │ │ └── api/ ├── server/ # 后端 │ ├── src/ │ │ ├── routes/ │ │ ├── models/ │ │ ├── services/ │ │ └── utils/ └── shared/ # 前后端共享的类型定义

这个结构的好处是职责清晰，AI 每次生成代码时我都告诉它"这个文件放哪"，它就不会乱放。而且shared目录放 TypeScript 类型定义，前后端共用一套接口类型，改一处两边都同步，省了大量对字段的功夫。

3. 核心数据模型设计与 AI 协作要点

3.1 宠物主表怎么设计才够用

数据模型是整个 App 的地基。我先让 AI 帮我列了一版字段，然后自己逐条审。它给的初版是这样的：id、name、species、breed、birthday、weight、avatar。看着没问题，但实际用起来会发现缺东西。

我补充了几个关键字段：stage（当前生命周期阶段，用枚举值）、adoption_date（接回家的日期，跟生日区分开，因为很多宠物是领养的，生日未知）、is_neutered（是否绝育，影响某些健康提醒）、microchip_id（芯片号，走丢找回的关键）、status（在世/离世，纪念期功能依赖这个）。

为什么adoption_date和birthday要分开？因为领养宠物的生日往往只能估算，但接回家的日子是确定的，很多纪念日提醒其实是按领养日算的。这个细节 AI 不会主动想到，得靠你对业务的理解去补。

3.2 事件表：用一张表装下所有记录

疫苗、驱虫、就诊、用药、体重，这些看起来是不同东西，但我最终用一张events表统一存，靠type字段区分。为什么？因为它们本质上都是"某个时间点发生的、跟某只宠物相关的一件事"，字段高度重合：时间、类型、描述、附件、下次提醒时间。

interface PetEvent { id: string; petId: string; type: 'vaccine' | 'deworm' | 'visit' | 'medication' | 'weight' | 'other'; title: string; description?: string; occurredAt: string; nextRemindAt?: string; attachments?: string[]; createdAt: string; }

用一张表的好处是查询简单、扩展方便，加新类型只要加个枚举值。坏处是某些类型特有的字段（比如体重要存数值）得塞进description或额外加个metadataJSON 字段。我选了加metadata字段，体重就存{ value: 5.2, unit: 'kg' }，这样既统一又不丢结构。

注意：别一上来就搞一堆关联表，新项目阶段"一张宽表 + JSON 扩展"往往比"多表关联"更快出活。等业务稳定了再拆表也不迟。

3.3 提醒表单独拆出来的理由

提醒功能是这个 App 的核心卖点，我把它单独拆了一张reminders表，而不是塞进 events。原因是提醒有独立的状态机：待触发、已触发、已完成、已忽略、已过期。而且一个事件可能对应多个提醒（比如疫苗后 7 天提醒观察、1 年后提醒补打），一对多关系，必须拆表。

interface Reminder { id: string; petId: string; eventId?: string; title: string; remindAt: string; status: 'pending' | 'triggered' | 'done' | 'ignored' | 'expired'; repeatRule?: string; // 如 'P1Y' 表示一年后重复 }

repeatRule我用的是 ISO 8601 的周期格式，这样疫苗年检、月度驱虫这种周期性提醒可以用一条规则描述，不用手动建一堆记录。这个设计是 AI 建议的，我觉得很妙就采纳了，算是它给我的一个惊喜。

4. 用 Claude Code 从零搭建的完整实操流程

4.1 第一步：初始化项目骨架

我在空目录里打开终端，启动 Claude Code，第一句话是：

帮我初始化一个 monorepo 项目，前端 React + Vite + TypeScript， 后端 Node.js + Express + TypeScript，数据库用 SQLite， 目录结构按我给的来（附上结构），先只搭骨架不写业务逻辑。

它很快生成了package.json、tsconfig.json、Vite 配置、Express 入口文件。这里有个细节：它默认用了 npm，但我习惯 pnpm，我就补了一句"用 pnpm workspace 管理"，它立刻调整了配置。这就是 Claude Code 比网页对话强的地方——它能直接改文件，不用我手动复制粘贴。

搭完骨架我做的第一件事是跑一遍pnpm install和pnpm dev，确认前后端都能起来。这一步千万别跳过，因为 AI 生成的依赖版本有时会冲突，早发现早解决，别等写了一堆代码才发现跑不起来。

4.2 第二步：先写类型定义，再写实现

我的习惯是先把shared/types里的接口定义全部写完，再让 AI 去实现。因为类型是"契约"，契约定死了，AI 生成的代码就不会跑偏。我把前面设计好的Pet、PetEvent、Reminder三个接口贴给它，让它先生成对应的 TypeScript 类型文件。

这一步 AI 几乎不会出错，因为就是翻译工作。但它会主动帮你补一些你没写的辅助类型，比如CreatePetInput、UpdatePetInput（用Partial<Pet>派生），这些在写 API 时很省事。

4.3 第三步：后端 CRUD 分批生成

后端我分了三批让 AI 生成：先宠物主表的 CRUD，再事件表，最后提醒表。为什么不一次性全生成？因为一次性生成太多，AI 容易在细节上偷懒，比如漏掉错误处理、参数校验。分批生成时我每批都会检查，发现问题当场让它改。

以宠物 CRUD 为例，我给的指令是：

基于 shared/types 里的 Pet 类型，用 Express + SQLite 实现 宠物的增删改查路由，放在 server/src/routes/pets.ts， 要求：1. 所有输入做校验 2. 统一错误处理 3. 返回结构统一为 { code, data, message }

它生成的代码质量不错，但有个问题：它用了better-sqlite3的同步 API，而我想用异步的。我指出后它改成了sqlite3的 Promise 封装。这种小分歧很正常，关键是你得看得懂它写的代码，不然被它带偏都不知道。

4.4 第四步：前端页面按功能模块推进

前端我按页面拆：宠物列表页、宠物详情页、添加事件页、提醒中心页。每个页面我都让 AI 先生成"能跑的最小版本"，再逐步加功能。比如宠物列表页，第一版只要能拉数据、显示卡片就行，第二版再加搜索、筛选、排序。

这里有个提效技巧：让 AI 复用你已经写好的组件。我写了一个PetCard组件后，后面所有用到宠物卡片的地方我都说"复用 PetCard"，它就不会重复造轮子。新项目最怕组件散乱，这个约束能帮你保持一致性。

4.5 第五步：提醒逻辑的实现与调试

提醒逻辑是最容易出 bug 的地方。我的实现思路是：后端提供一个/api/reminders/due接口，返回当前时间之前所有pending状态的提醒；前端定时轮询这个接口，有到期的就弹通知。

AI 第一次生成的版本有个坑：它用new Date()直接比较字符串时间，时区处理有问题。我测试时发现提醒时间总是差 8 小时，排查后确认是时区没统一。解决办法是所有时间统一存 UTC，展示时再转本地时区。这个坑很典型，AI 生成的代码在时间处理上经常忽略时区，一定要重点测。

5. 实操中踩过的坑与排查技巧实录

5.1 AI 生成的代码"看着对但跑不通"怎么办

这是最常见的问题。我的排查顺序是：先看报错信息定位到具体文件行号，再把那段代码连同报错一起丢给 AI，让它解释并修复。不要自己闷头改，因为 AI 生成的代码往往有它自己的逻辑链，你手动改一处可能破坏另一处，让它整体修更稳。

有一次它生成的 SQL 查询用了SELECT *但代码里按字段名取值，字段名对不上就全 undefined。我把报错贴回去，它立刻发现是表结构里字段用了下划线命名、代码里用了驼峰，加了映射就好了。这种命名不一致是 AI 生成代码的高频问题，建议一开始就约定好命名规范。

5.2 依赖版本冲突的快速定位

新项目装依赖时，AI 给的版本号有时会互相冲突。我遇到过一次vite和某个插件版本不兼容，报错信息很晦涩。我的处理办法是：先pnpm why <包名>看是谁依赖了它，再统一升到兼容版本。如果实在搞不定，直接问 AI"这两个包哪个版本组合是稳定的"，它给的答案通常靠谱。

5.3 常见问题速查表

5.4 独家避坑心得

第一，每生成一个模块就提交一次 Git。AI 改代码有时会"顺手"改坏别的地方，有版本记录你随时能回滚。第二，关键业务逻辑自己写，样板代码交给 AI。比如提醒的状态流转规则，我坚持自己写，因为这是业务核心，AI 容易理解偏。第三，让 AI 写测试。我让它给提醒逻辑生成单元测试，跑一遍能发现不少边界问题，比自己手动点强多了。

6. 这个项目后续还能怎么扩展

跑通基础版本后，我梳理了几个自然的扩展方向。多宠物家庭共享：加个household概念，多人共同管理同一批宠物，这需要引入权限模型。健康数据分析：把体重、就诊记录做成趋势图，甚至接入简单的异常检测，比如体重骤降提醒。纪念期功能深化：时间轴、照片墙、纪念日推送，这块偏情感化，交互设计比技术更重要。

技术上，SQLite 换成 PostgreSQL 是迟早的事，尤其是要多端同步的时候。提醒功能如果要做真正的推送，得引入消息队列和推送服务。这些扩展我暂时没做，但数据结构设计时已经留了口子，比如metadata字段和repeatRule规则，加功能时不用大改表结构。

我个人在实际操作中的体会是：AI 辅助开发最大的价值不是"帮你写代码"，而是"帮你快速试错"。新项目最怕的是方向错了还埋头写，用 AI 你能一晚上试三四个方案，快速找到对的路。但前提是你自己得懂业务、看得懂代码，不然 AI 给你的坑你根本发现不了。这个宠物 App 我还会继续迭代，后面有新的踩坑记录再分享。