AI辅助开发实战：从零搭建宠物生命周期管理应用

1. 项目缘起与整体设计思路1.1 为什么选宠物生命周期管理这个方向宠物生命周期管理这个选题乍一看像是个小众赛道但实际拆开来看它覆盖的需求密度非常高。一只宠物从被领养或购买进入家庭到日常喂养、疫苗驱虫、体检记录、行为训练再到生病就医、老年照护最后到离世后的纪念与情感处理整条链路涉及的时间跨度可以长达十几年。这中间产生的数据是碎片化的、跨平台的、且高度个人化的。我之所以拿这个方向来跑一遍从零搭建的全流程是因为它天然具备几个适合验证AI辅助开发能力的特征。第一业务逻辑不复杂但数据模型有层次宠物、主人、事件、提醒、健康记录之间是一对多和多对多的关系足够检验AI对领域建模的理解。第二它需要前端交互、后端接口、数据持久化、定时任务、消息推送等多个技术模块协同能比较全面地测试AI在跨模块协作时的表现。第三这个场景对普通开发者来说足够陌生不像电商、博客那种被做烂了的题目AI没法直接套用训练数据里的模板代码必须真正理解需求才能给出合理方案。我给自己定的目标是不写一行手写代码全程通过自然语言描述需求让AI逐步生成项目骨架、数据模型、接口逻辑和前端页面我只负责审查、调整提示词和做关键决策。这个过程记录下来对想了解AI辅助开发边界在哪的人应该有帮助。1.2 技术选型的取舍逻辑在正式动手之前我先花了一个下午做技术选型的推演。这里有个原则AI辅助开发的项目技术栈要尽量选主流、文档丰富、社区活跃的方案。原因很简单AI生成代码的质量和它训练数据里该技术的覆盖密度正相关。你选一个冷门框架AI生成的代码可能连语法都对不上你还得花大量时间去纠错反而比手写还慢。后端我最终选了Node.js配合Express框架。理由有三一是JavaScript生态里AI生成的代码质量普遍较高因为训练语料充足二是Express的中间件模式非常适合快速搭建RESTful接口AI对这类模式的生成准确率很高三是前后端同语言减少上下文切换成本AI在生成前端请求代码时也能保持一致性。数据库选了SQLite起步后期可平滑迁移到PostgreSQL。这个选择可能有人会质疑觉得SQLite太轻量。但我的考虑是项目初期数据量小SQLite零配置、单文件存储的特性让AI生成的数据库操作代码更简洁出错概率更低。而且通过ORM层抽象后后期换数据库只需要改配置不影响业务代码。我用的ORM是Prisma它的schema定义文件结构清晰AI能很好地根据我的自然语言描述生成对应的模型定义。前端选了React配合Tailwind CSS。React的组件化思维和AI的生成逻辑很契合你描述一个组件的行为AI就能给出对应的JSX结构。Tailwind则解决了AI生成CSS时经常出现的类名混乱问题它的原子化类名让样式代码更可预测。定时任务用node-cron消息提醒先做站内通知后期可扩展邮件或短信。整个技术栈没有引入任何重型框架保持轻量可控。1.3 项目模块的拆解方式我把整个应用拆成了六个核心模块这个拆解过程本身就是和AI对话完成的。我先向AI描述了宠物的完整生命周期让它帮我梳理出功能模块然后我再根据实际开发难度做了调整。最终确定的模块是用户与宠物档案管理、健康事件记录、提醒与日程、成长时间线、数据统计看板、多宠物切换。每个模块下面再细分具体功能点。比如健康事件记录下面又分疫苗、驱虫、体检、用药、就诊、体重记录等子类型。这种拆解方式的好处是每个模块可以独立开发和测试AI在生成代码时上下文更聚焦不容易出现跨模块的逻辑混乱。我在实际操作中发现如果你一次性让AI生成整个应用的所有代码它会在模块边界处产生大量不一致比如用户模型里叫userId宠物模型里叫ownerId后期统一起来非常痛苦。分模块推进每个模块开始前先确认接口契约能规避掉大部分这类问题。2. 环境搭建与项目初始化实操2.1 开发环境的准备清单环境准备这一步看起来简单但实际踩坑不少。我用的是一台普通的开发笔记本操作系统是macOS但整个流程在Windows和Linux上同样适用差异只在个别命令上。需要提前装好的东西有Node.js 18以上版本、npm或pnpm包管理器、Git版本控制、一个趁手的代码编辑器。我用的编辑器是VS Code配合AI编程插件使用。数据库客户端我装了SQLite的图形化工具方便直接查看数据。这里有个细节值得说Node.js的版本一定要选LTS版本不要追最新版。我在测试时用了某个奇数版本结果Prisma的某个依赖编译报错换成LTS后问题消失。AI生成代码时默认假设你用的是稳定版本用非LTS版本会引入很多不必要的兼容性问题。安装完基础环境后我建议先跑一个简单的Node脚本验证环境是否正常比如打印一下版本号、测试一下文件读写。这一步花不了两分钟但能避免后面出问题时在环境层面浪费时间排查。2.2 用AI生成项目骨架的完整对话过程项目初始化我是完全通过AI对话完成的。我的第一条提示词是这样的“我要创建一个宠物生命周期管理的Web应用后端用Node.js Express Prisma SQLite前端用React Tailwind CSS请帮我生成项目目录结构和初始化命令。”AI给出的目录结构大致是前后端分离的monorepo形式根目录下分client和server两个文件夹各自有独立的package.json。这个结构我认可因为前后端依赖分开管理部署时也灵活。但AI给出的初始化命令里有个问题它用了npx create-react-app来创建前端项目。这个命令现在已经不推荐了官方建议用Vite。我手动把这条命令替换成了npm create vitelatest client -- --template react。这就是AI辅助开发的一个典型场景AI给的方案大方向对但细节可能滞后需要你用最新知识去校正。后端初始化相对顺利npm init -y然后安装express、prisma、cors、dotenv等依赖AI给的依赖列表基本完整。我额外加了nodemon作为开发依赖实现热重载。初始化完成后我让AI生成了一个最简单的健康检查接口跑起来验证前后端能通。这个“先跑通再开发”的习惯非常重要很多新手喜欢先把所有代码写完再运行结果一出错就是几十个问题混在一起排查成本极高。2.3 数据库模型的第一版设计数据模型是整个项目的地基我在这上面花的对话轮次最多。第一版我让AI根据功能模块直接生成Prisma schema结果它给出了一个过于理想化的设计把宠物、事件、提醒、用户之间的关系搞得很复杂还引入了很多当时用不上的字段。我的调整策略是先做减法只保留核心实体和必要关系等业务跑起来再逐步加字段。最终第一版schema包含四个模型User用户、Pet宠物、HealthEvent健康事件、Reminder提醒。User和Pet是一对多关系一个用户可以有多只宠物。Pet和HealthEvent是一对多一只宠物可以有多个健康事件。Reminder比较特殊它既可以关联到Pet比如疫苗提醒也可以关联到具体的HealthEvent比如用药后复查提醒所以设计成了可选关联。这里有个经验AI生成schema时特别喜欢加createdAt和updatedAt字段这本身没错但它有时会忘记加default(now())和updatedAt注解导致插入数据时报错。每次生成完schema我都会逐字段检查默认值和更新策略。还有一点Prisma的枚举类型在SQLite上支持有限AI有时会生成SQLite不支持的语法。遇到这种情况要么换成字符串加校验要么换数据库。我选择了前者用字符串存储事件类型在应用层做枚举校验。3. 核心功能模块的开发实录3.1 宠物档案模块的增删改查实现宠物档案是用户进入应用后最先接触的模块它的体验直接影响用户留存。我向AI描述的需求是用户可以添加宠物填写名字、品种、性别、生日、绝育状态、头像可以编辑和删除列表页要显示每只宠物的头像、名字、年龄和最近一次健康事件。AI生成的CRUD接口基本可用但有几个地方需要调整。第一年龄计算它写成了简单的年份相减这不对宠物的年龄应该精确到月而且要根据生日动态计算。我让AI重新生成了一个工具函数用日期差算出年月。第二删除宠物时它没有处理级联删除导致关联的健康事件变成孤儿数据。我在Prisma schema里给关联字段加了onDelete: Cascade这个问题才解决。头像上传这块AI最初建议用Base64直接存数据库。这个方案在小规模下能用但宠物头像图片体积不小存数据库会让备份和查询变慢。我改成了存文件路径图片文件放在服务器的uploads目录数据库只存相对路径。AI很快就根据我的要求调整了代码。前端表单部分AI生成的React组件结构清晰但表单校验逻辑比较薄弱。我补充了必填校验、日期格式校验和图片大小限制。这里有个小技巧让AI生成表单时明确告诉它用哪个表单库。我用的react-hook-formAI对这个库的生成质量明显高于它自己手写的受控组件方案。3.2 健康事件记录的多样化处理健康事件模块是整个应用最复杂的部分因为事件类型多每种类型需要记录的字段还不一样。疫苗要记录疫苗名称、接种日期、下次接种时间驱虫要记录药品名称、驱虫类型体内/体外、下次时间体检要记录体重、体温、各项指标就诊要记录医院、医生、诊断结果、用药清单。我最初想让AI生成一个统一的HealthEvent模型用JSON字段存不同类型的数据。但AI建议用单表加类型字段加可选字段的方案我采纳了。原因是JSON字段虽然灵活但查询和统计时很麻烦而且SQLite对JSON的支持不如PostgreSQL完善。最终的表结构是HealthEvent有type字段标识类型然后有一组通用字段日期、备注、费用和一组可选字段疫苗名称、药品名称、体重、体温等不同类型的事件填写不同的可选字段。这种设计有一定冗余但查询效率高AI生成代码时也更容易处理。这里踩过一个坑AI生成的创建事件接口没有做类型和字段的匹配校验导致可以创建一条“疫苗”类型的事件却不填疫苗名称。我后来加了一个校验中间件根据type字段动态校验必填字段。这个中间件AI写了个初版但校验规则是硬编码的我改成了配置化方便后续加新事件类型。3.3 提醒与定时任务的落地细节提醒功能的核心是定时任务加消息通知。我用的node-cron让AI生成一个每天凌晨跑一次的定时任务扫描所有Reminder记录把当天需要提醒的找出来生成通知。AI生成的初版代码有个严重问题它把定时任务写在了Express的主入口文件里而且没有做错误处理。一旦任务执行出错整个进程可能崩溃。我把它拆成了独立的service文件加了try-catch包裹并且用cron的时区参数确保执行时间准确。通知这块我先做了站内通知就是往Notification表里插一条记录前端轮询获取。AI建议用WebSocket做实时推送但我评估后觉得初期没必要轮询实现简单、调试方便等用户量上来再换也不迟。这个决策帮我省了不少时间WebSocket的连接管理和断线重连逻辑比想象中复杂。提醒的触发时间计算也有讲究。疫苗提醒通常是提前几天通知不是当天才提醒。我让AI加了一个advanceDays字段用户创建提醒时可以设置提前几天。定时任务扫描时用提醒日期减去提前天数等于当天就触发。这个逻辑AI一次就写对了但边界情况没处理比如提前天数大于提醒日期本身时会算出负数。我补了一个校验确保提前天数不超过合理范围。3.4 成长时间线的数据聚合成长时间线是把宠物的所有健康事件按时间倒序排列形成一个可视化的记录流。这个功能技术上不难但数据聚合的逻辑需要仔细设计。AI最初生成的接口是直接查HealthEvent表然后返回。但时间线上不仅要显示健康事件还要显示用户手动添加的成长记录比如“第一次学会握手”“第一次出门散步”这类非健康事件。所以我加了一个GrowthRecord模型然后时间线接口要合并两张表的数据再排序。合并查询AI给了两个方案一是分别查两张表然后在应用层合并排序二是用数据库的UNION查询。我选了应用层合并因为两张表的字段不完全一样UNION需要对齐字段反而麻烦。应用层合并虽然多一次查询但代码可读性好后期加新类型的时间线数据也容易扩展。分页处理上AI生成的代码用了offset分页这在数据量大时性能不好。我改成了基于游标的分页用最后一条记录的ID作为游标。这个改动AI很快就理解了生成的代码质量不错。4. 前后端联调与问题排查4.1 接口契约的确认与调整前后端联调阶段暴露了很多前期没注意的问题大部分都跟接口契约有关。比如后端返回的日期是ISO格式的字符串前端直接显示出来是一长串带时区的字符用户体验很差。我后来统一在后端做格式化返回YYYY-MM-DD格式的日期字符串。还有字段命名不一致的问题。后端Prisma生成的字段是驼峰命名但AI生成前端代码时有时会写成下划线命名导致取不到数据。我后来在项目里加了一个约定所有接口返回的字段一律用驼峰命名前端也统一用驼峰。这个约定写进了给AI的提示词模板里后续生成代码时就没再出过这个问题。错误处理也是联调时的重点。AI生成的后端接口在出错时直接返回500和一堆堆栈信息前端拿到后不知道怎么展示。我让AI统一了错误返回格式所有错误都返回{ code, message }结构前端根据code做不同处理。这个改动虽然小但让前端的错误提示友好了很多。4.2 常见报错与排查思路开发过程中遇到的报错不少我挑几个有代表性的说说排查思路。第一个是Prisma的迁移报错。有次我改了schema后跑迁移提示字段已存在。原因是之前手动改过数据库导致迁移记录和实际表结构不一致。解决办法是删掉数据库文件重新迁移开发阶段数据不重要直接重置最省事。这个坑提醒我开发阶段尽量用迁移管理表结构不要手动改数据库。第二个是跨域问题。前端跑在5173端口后端跑在3000端口浏览器请求被拦截。AI生成的代码里其实加了cors中间件但配置不对只允许了特定来源。我改成开发环境允许所有来源生产环境再收紧。这里要注意cors配置要在路由之前注册否则不生效。第三个是定时任务不执行。排查后发现是时区问题服务器时区和我预期的不一样导致任务在错误的时间触发。解决办法是在cron表达式里显式指定时区并且在部署文档里注明服务器时区要求。第四个是前端图片不显示。原因是后端返回的是相对路径前端直接拿去当src用但前端的域名和后端不一样相对路径解析错了。改成后端返回完整URL或者前端拼接后端地址问题解决。4.3 性能优化的几个实际动作项目跑起来后我做了几项性能优化都是AI建议加我实际验证的。第一项是数据库索引。HealthEvent表的petId和date字段查询频率很高我让AI加了复合索引。加之前查一只宠物一年的健康事件要200多毫秒加之后降到20毫秒以内。第二项是接口缓存。宠物列表和统计看板的数据变化不频繁我加了内存缓存设置5分钟过期。这个改动让页面加载速度明显提升。AI生成的缓存代码用了Map实现简单够用后期要分布式部署再换Redis。第三项是前端懒加载。时间线数据量大时一次性加载很慢我改成了滚动加载每次加载20条。AI生成的无限滚动组件基本可用但我调整了触发阈值避免用户还没滚到底就开始加载。第四项是图片压缩。用户上传的宠物头像动辄几MB我在后端加了sharp库做压缩统一压到200KB以内。这个改动让上传速度和页面加载速度都快了不少。5. 实操心得与避坑指南5.1 提示词工程的实战技巧用AI辅助开发提示词的质量直接决定生成代码的质量。我总结了几个实用技巧。第一给AI设定角色。我每次对话开头都会说“你是一个有五年经验的Node.js后端工程师”这样AI生成的代码风格会更专业注释也更到位。不设定角色时AI有时会生成教学性质的代码注释过多不适合生产。第二提供上下文。生成新模块代码前我会把相关的schema定义和已有接口的代码片段贴给AI让它知道现有的数据结构。不提供上下文时AI会自己臆造字段名导致前后不一致。第三分步骤要求。不要一次性让AI生成整个模块而是拆成“先设计数据模型”“再生成接口”“再写业务逻辑”“最后加错误处理”这样的小步骤。每步确认无误后再进行下一步返工成本低。第四要求AI解释。生成代码后我会让AI解释关键逻辑这样能快速发现它的理解偏差。有次它生成的提醒逻辑把提前天数算反了解释时我才发现及时纠正。第五善用“重写”指令。AI生成的代码不满意时不要在原代码上让它改直接说“重新生成要求是……”这样得到的代码更干净。在原代码上改容易越改越乱。5.2 代码审查的重点检查项AI生成的代码不能直接上线必须经过审查。我整理了一份检查清单每次生成代码后逐项过。安全性方面检查SQL注入防护Prisma本身有防护但原生查询要注意、用户输入校验、权限校验确保用户只能操作自己的宠物数据、敏感信息是否硬编码。数据一致性方面检查事务使用涉及多表写入的操作要包在事务里、级联删除配置、唯一约束、外键约束。错误处理方面检查所有异步操作是否有try-catch、错误是否被正确传递、是否有兜底处理。性能方面检查是否有N1查询、是否加了必要索引、是否有不必要的全表扫描、大文件是否做了流式处理。代码规范方面检查命名是否一致、是否有重复代码、注释是否准确、是否有未使用的变量和导入。这份清单帮我拦下了不少问题比如有次AI生成的删除接口没有校验宠物归属任何登录用户都能删别人的宠物这是严重的安全漏洞。5.3 项目后续扩展的方向这个项目目前跑通了核心流程但还有不少可以扩展的方向。功能层面可以加宠物社交让用户分享宠物动态、互相评论。可以加健康数据分析根据历史数据给出喂养建议。可以加多语言支持方便不同地区的用户使用。可以加数据导出让用户把自己的数据导出成PDF或Excel。技术层面可以把SQLite换成PostgreSQL支持更高并发。可以把定时任务拆成独立服务用消息队列解耦。可以加日志系统方便排查线上问题。可以加自动化测试保证代码质量。AI辅助开发这个方向本身也在快速演进。我实际用下来AI在生成标准CRUD代码、写工具函数、做数据转换这些任务上已经非常可靠能省下大量时间。但在业务逻辑设计、边界情况处理、性能优化这些需要经验判断的地方还是得人来把关。把AI当成一个执行力很强但经验不足的初级工程师来用这个定位比较准确。最后分享一个我踩过的坑不要过度依赖AI生成的代码而不理解它。有次AI生成了一个复杂的日期处理函数我没细看就用了结果上线后发现跨月计算有bug。后来我养成了习惯AI生成的每一段核心逻辑我都要能自己讲清楚它为什么这么写讲不清楚就重写。这个习惯虽然慢一点但能避免很多线上事故。