企业官网建设流程全解析

1. 为什么我选择用对话式AI工具从零搭一个宠物生命周期管理App

宠物生命周期管理这个需求，乍一听好像挺小众，但真正养过宠物的人都知道，从接回家第一天到最终告别，中间涉及的事情极其琐碎：疫苗记录、驱虫周期、体重曲线、发情期、配种或绝育、老年病用药、临终关怀，甚至走失后的信息发布。市面上大部分宠物App只做了其中一两个环节，要么是单纯的疫苗提醒，要么是社区晒图，真正能把“生命周期”串起来的工具少之又少。

我决定自己动手做一个。但问题在于，我不是全职开发者，日常还有别的工作要处理，如果按照传统方式从需求文档、原型设计、数据库建模、前后端开发一路走下来，保守估计要两三个月。于是我把目光投向了对话式AI编程工具——也就是标题里提到的Claude Code。这类工具的核心价值在于：你用自然语言描述需求，它直接帮你生成可运行的项目骨架、数据模型、接口逻辑甚至前端页面，你只需要在关键节点做决策和调试。

这篇文章要讲的就是我完整走一遍的流程：从一个空文件夹开始，到最终跑起来一个能用的宠物生命周期管理App。我会把每个阶段为什么这样选、AI在哪些地方靠谱、哪些地方必须人工介入、踩了哪些坑，全部摊开来讲。适合有基础编程概念但不想从零手写所有代码的人，也适合完全没做过全栈项目、想借AI工具入门的读者。全文涉及的关键词包括宠物生命周期管理、对话式AI编程、数据模型设计、全栈项目搭建、AI辅助开发流程。

先说结论：AI能帮你省掉大约60%到70%的重复劳动，但剩下30%到40%的架构决策、数据关系梳理、边界条件处理，仍然需要你自己想清楚。如果你指望一句话就生成一个完美App，那大概率会失望；但如果你把它当成一个执行力极强但需要明确指令的初级开发搭档，效率提升会非常明显。

2. 动手之前先把“生命周期”拆成数据模型

2.1 宠物生命周期到底包含哪些阶段

在打开任何工具之前，我强迫自己先用纸笔把宠物的完整生命周期列了一遍。这一步非常关键，因为AI工具再强，也没法替你决定业务逻辑。我最终梳理出的阶段如下：

• 幼年期：出生日期、品种、初始体重、第一针疫苗、驱虫记录、断奶时间
• 成年期：体重变化曲线、年度疫苗、驱虫周期、发情周期（未绝育）、绝育手术记录
• 繁育期（可选）：配种日期、孕期记录、产仔数量、幼崽去向
• 中老年期：慢性病用药、体检频率增加、关节问题、牙齿护理
• 临终与善后：临终关怀记录、安乐死决策、遗体处理方式、纪念日提醒

把这些阶段映射到数据模型上，核心实体其实只有几个：宠物（Pet）、事件（Event）、提醒（Reminder）、健康记录（HealthRecord）、用户（User）。事件是一个通用表，通过类型字段区分疫苗、驱虫、体检、用药、发情、配种等。这样设计的好处是扩展性强，以后想加新类型的事件不需要改表结构。

2.2 为什么我选择关系型数据库而不是文档型

很多人做这类小项目第一反应是用MongoDB或者Firebase，因为schema灵活。但我实测下来，宠物生命周期管理的数据关系其实非常明确：一只宠物属于一个用户，一只宠物有多个事件，一个事件可能关联多条健康记录。这种一对多、多对一的关系用关系型数据库表达最自然，查询也最方便。

我最终选了SQLite作为开发阶段的数据库，原因是零配置、单文件、AI生成SQL和ORM代码时不容易出错。后期如果要上云，换成PostgreSQL只需要改连接字符串和少量方言差异。表结构大致如下：

CREATE TABLE pets ( id INTEGER PRIMARY KEY AUTOINCREMENT, user_id INTEGER NOT NULL, name TEXT NOT NULL, species TEXT NOT NULL, breed TEXT, birth_date DATE, weight_kg REAL, is_neutered BOOLEAN DEFAULT 0, created_at DATETIME DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE events ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL, event_type TEXT NOT NULL, event_date DATE NOT NULL, notes TEXT, next_due_date DATE, FOREIGN KEY (pet_id) REFERENCES pets(id) );

这两张表是整个App的骨架。events表里的next_due_date字段是实现提醒功能的关键——每次记录一个事件时，如果这个事件有周期性（比如疫苗每年一次），就自动计算出下次到期日，提醒模块只需要扫描这个字段即可。

2.3 用AI生成模型代码时我踩的第一个坑

我把上面的表结构描述给AI工具，让它生成对应的ORM模型和迁移脚本。第一次生成的代码里，它把event_type做成了枚举类型，看起来没问题，但枚举值只覆盖了我提到的几种。问题在于，宠物生命周期里还有很多边缘事件，比如“走失”“找回”“寄养”“美容”，这些不属于健康范畴但同样需要记录。

我的处理方式是：把event_type改回纯文本字段，但在应用层维护一个常量列表，同时允许用户自定义事件类型。这个决策AI不会主动帮你做，因为它默认你会把所有可能性都列全。实际项目中，永远要留一个“其他”的口子。

提示：让AI生成数据模型时，一定要明确告诉它“哪些字段需要保留扩展性”，否则它倾向于把一切枚举化，后期加类型会很痛苦。

3. 用对话式AI工具生成项目骨架的完整过程

3.1 项目初始化的第一句话该怎么写

很多人用AI编程工具时，第一句话就写“帮我做一个宠物管理App”，然后抱怨生成的东西不能用。问题在于，这句话信息量太低，AI只能靠猜。我的做法是给出一段结构化的描述，包含技术栈、核心功能、数据实体、目标平台。

我实际用的初始指令大概是这样的：

创建一个宠物生命周期管理App，技术栈如下： - 后端：Python FastAPI + SQLite + SQLAlchemy - 前端：React + Vite + TailwindCSS - 功能：用户注册登录、添加宠物、记录事件、设置提醒、查看时间线 - 数据实体：User, Pet, Event, Reminder - 先搭建项目目录结构，生成依赖文件，不要写具体业务逻辑

注意最后一句“不要写具体业务逻辑”。这是经验之谈：如果一上来就让AI把所有代码写完，它会生成大量你还没想清楚的实现，后期改起来比重新写还麻烦。正确的节奏是分层推进——先骨架，再模型，再接口，再页面。

3.2 目录结构生成后我做了哪些调整

AI生成的目录结构大致是标准的FastAPI项目布局：

backend/ app/ models/ schemas/ routers/ services/ main.py requirements.txt frontend/ src/ components/ pages/ api/ App.jsx package.json

这个结构本身没问题，但我做了两处调整。第一，在backend/app下增加了一个core/目录，用来放配置、数据库连接、安全相关的东西，避免main.py变得臃肿。第二，在frontend/src下增加了hooks/目录，因为后面会发现很多数据获取逻辑需要复用。

这两处调整AI不会主动做，因为它默认按最小可用原则生成。但项目稍微长大一点，没有这些分层就会乱。

3.3 依赖安装阶段的版本冲突处理

AI生成的requirements.txt里写的版本号往往是它训练数据里的版本，直接pip install大概率会遇到冲突。我实测下来，最稳妥的做法是：不写死版本号，只写包名，让pip自己解析最新兼容版本，跑通之后再pip freeze锁定。

前端这边同理，package.json里的依赖版本如果和当前Node版本不匹配，会出现各种奇怪的报错。我的处理方式是先用npm create vite@latest生成一个干净的基础项目，再让AI往里面填业务代码，而不是让AI从头生成package.json。

注意：AI生成的依赖清单只能作为参考，实际安装时以包管理器解析结果为准。这一步不要偷懒，否则后面调试环境问题会浪费大量时间。

4. 核心功能模块的AI实现与人工修正

4.1 用户认证模块：为什么我放弃了AI生成的JWT方案

AI默认生成的认证方案是JWT，逻辑上没问题，但对于一个个人项目来说，JWT的刷新机制、过期处理、前端存储策略都太复杂了。我最终改成了简单的session-based认证，后端用itsdangerous签名一个token放在cookie里，前端只需要带上cookie即可。

这个决策的理由是：宠物管理App的用户量级很小，不需要分布式认证，session方案更简单、更安全、更容易调试。AI不会帮你做这种取舍，它倾向于用“业界标准”方案，但标准方案不一定适合你的场景。

修改后的认证流程：

1. 用户注册时，密码用bcrypt哈希后存入数据库
2. 登录成功后，后端生成一个签名token，写入HttpOnly cookie
3. 前端每次请求自动携带cookie，后端中间件验证token有效性
4. token有效期设为7天，过期后重新登录

4.2 事件记录与时间线展示的实现细节

事件记录是这个App最核心的功能。用户添加一只宠物后，应该能看到一条按时间倒序排列的时间线，每个事件显示类型、日期、备注，如果有下次到期日则高亮显示。

AI生成的初始版本是把所有事件一次性返回给前端，前端做排序和分组。这个方案在事件数量少的时候没问题，但宠物养几年后事件可能上百条，一次性加载会变慢。我改成了后端分页，每页20条，前端滚动加载。

时间线的分组逻辑也做了调整。AI默认按日期分组，但实际使用中，用户更关心的是“这个月需要做什么”，所以我把分组维度改成了“即将到期”“本月”“更早”。这个改动需要在后端加一个计算字段，根据next_due_date和当前日期的差值来分类。

def categorize_event(event): if event.next_due_date: days_left = (event.next_due_date - date.today()).days if days_left <= 7: return "即将到期" elif days_left <= 30: return "本月" return "更早"

4.3 提醒功能：从简单轮询到本地通知的演进

提醒功能我迭代了三个版本。第一版是AI生成的：后端定时任务扫描next_due_date，到期时发邮件。这个方案的问题是需要配置邮件服务，而且用户不一定看邮件。

第二版改成了前端轮询：页面加载时请求后端接口，获取即将到期的事件，在页面上显示红点。这个方案简单，但用户不打开App就看不到提醒。

第三版我加上了浏览器本地通知。用户授权后，前端在页面加载时检查即将到期的事件，如果距离到期日小于3天，就弹出系统通知。这个方案不需要后端定时任务，也不需要邮件服务，对于个人项目来说足够用了。

if (Notification.permission === 'granted') { const dueSoon = events.filter(e => daysUntil(e.next_due_date) <= 3); dueSoon.forEach(e => { new Notification(`宠物提醒：${e.pet_name}`, { body: `${e.event_type} 即将到期`, }); }); }

提示：浏览器通知只在页面打开时有效，如果要做真正的后台推送，需要Service Worker和推送服务，复杂度会上升一个量级。个人项目建议先用本地通知，够用就好。

5. 前端页面搭建中的AI协作技巧

5.1 组件拆分：让AI一次只做一个组件

前端部分我最大的体会是：不要让AI一次性生成整个页面。正确做法是一个组件一个组件地生成，每个组件给明确的props定义和状态说明。

比如时间线组件，我的指令是：

创建一个Timeline组件，接收events数组作为prop， 每个event包含id, event_type, event_date, notes, next_due_date。 按日期倒序排列，每个事件显示为一个卡片， 如果next_due_date在7天内，卡片左边框显示为橙色。 使用TailwindCSS，不要用任何UI库。

这样生成的组件质量明显高于“帮我做一个时间线页面”。原因是AI在单一职责的组件上表现最好，一旦涉及多个组件交互，它就开始编造不存在的接口。

5.2 表单处理：AI生成的验证逻辑为什么不够用

添加宠物的表单，AI生成的验证逻辑只检查了必填项。但实际使用中，我发现几个必须加的校验：

• 出生日期不能晚于今天
• 体重必须是正数，且范围在0.1到100公斤之间
• 品种字段如果选了“其他”，必须填写具体品种
• 宠物名字长度限制在20个字符以内

这些边界条件AI不会主动加，因为它不知道你的业务规则。我的做法是：先让AI生成基础表单，然后自己逐条补充验证规则，再让AI根据规则生成错误提示的UI。

5.3 状态管理：什么时候该用全局状态

AI默认会用Redux或者Zustand做全局状态管理。但对于这个App，真正需要全局共享的状态只有两个：当前登录用户和当前选中的宠物。其他状态都是页面级的，用React的useState就够了。

我最终只引入了一个轻量的Context来存用户信息，宠物列表在每个页面单独请求。这样代码更简单，调试也更容易。AI倾向于过度设计状态管理，这一点需要人工压制。

6. 联调、测试与部署上线的实操记录

6.1 前后端联调时最常见的三个问题

第一个问题是跨域。开发阶段前端跑在5173端口，后端跑在8000端口，浏览器会拦截请求。解决方案是在FastAPI里加CORS中间件，允许http://localhost:5173。

第二个问题是日期格式。前端传过去的日期是ISO格式，后端SQLite存储的是DATE类型，中间需要做一次转换。我统一约定：所有日期在传输层用ISO 8601字符串，在数据库层用DATE类型，在应用层用Python的date对象。

第三个问题是错误处理。AI生成的接口在出错时直接抛异常，前端收到500错误但不知道具体原因。我加了一个全局异常处理器，把所有业务异常转成统一的JSON格式：

{ "code": "PET_NOT_FOUND", "message": "宠物不存在", "detail": null }

6.2 我写了哪些测试用例来验证核心逻辑

AI会生成测试代码，但覆盖的往往是happy path。我手动补充了以下几类测试：

• 添加宠物时缺少必填字段，应该返回400
• 查询不属于当前用户的宠物，应该返回403
• 事件的下次到期日计算是否正确（比如疫苗间隔365天）
• 提醒分类逻辑在边界日期（正好7天、正好30天）的表现

这些测试用pytest写，跑一遍只需要几秒钟，但能挡住大部分低级bug。

6.3 部署方案的选择与踩坑

部署我选了最简方案：后端用Uvicorn跑在云服务器上，前端构建后扔到静态托管服务。数据库直接用SQLite文件，定期备份。

踩过的坑有两个。第一，SQLite在并发写入时会锁库，虽然个人项目并发很低，但还是要设置check_same_thread=False并加一个简单的写入队列。第二，前端构建后的路由需要配置fallback到index.html，否则刷新页面会404。

注意：如果后期用户量增长，SQLite需要换成PostgreSQL，这一步的迁移成本主要在于SQL方言差异和连接池配置，建议提前把数据库操作封装在单独的模块里，方便替换。

7. 这套AI辅助开发流程的真实效率复盘

7.1 哪些环节AI确实省了时间

数据模型生成、CRUD接口编写、前端组件骨架、测试用例模板，这四个环节AI的帮助最大。粗略估算，这些重复性工作如果手写大概需要40到50个小时，AI辅助下压缩到了15个小时左右。

特别是CRUD接口，FastAPI的写法很模板化，AI生成的代码基本可以直接用，只需要改改字段名和验证逻辑。前端组件也是，TailwindCSS的类名组合AI写得很熟练，比我自己查文档快。

7.2 哪些环节AI反而拖了后腿

架构决策、边界条件处理、联调排错，这三个环节AI基本帮不上忙，甚至有时候会误导。比如它默认生成的JWT认证方案，我花了两个小时才改成session方案；它生成的全局状态管理，我花了一个小时才拆掉。

还有一个隐形成本是“理解AI生成的代码”。如果AI生成了一个你没见过的写法，你需要花时间去读懂它，这个时间不一定比你自己写少。所以我的原则是：只让AI生成我能看懂的代码，看不懂的就让它换一种写法。

7.3 如果重新来一遍我会怎么调整

第一，更早地确定数据模型，不要边写边改。第二，前端不要用AI生成的路由配置，自己手写更可控。第三，测试用例从一开始就写，不要等到联调时才发现问题。第四，部署方案提前想好，不要等到最后一天才折腾服务器。

这套流程的核心逻辑是：AI负责执行，你负责决策。决策的质量决定了最终产品的质量，而决策能力来自你对业务的理解，不是来自工具。宠物生命周期管理这个App我到现在还在用，每次给宠物记录一次疫苗，看到时间线上自动算出下次到期日，就觉得这套折腾是值得的。