1. 从零到一为什么我会用AI助手独立搭建一个完整App先交代一下背景这个项目是我给自己出的一个压力测试。平时做技术方案评审看别人提交的代码多自己动手从零搭一个成体系的、能跑通的完整应用少。这次我选的目标是宠物生命周期管理App不是因为宠物赛道有多热门而是这个业务领域天然覆盖了全栈开发的大部分核心环节用户系统、数据建模、状态流转、消息提醒、文件上传、后台任务还有移动端和Web端的适配问题。用AI辅助从零搭建这种项目比做技术Demo更有说服力因为它逼着你把脚手架和业务逻辑两件事都做完而不是停留在能跑Hello World的程度。我用的主力工具是Claude Code配合它内置的MCP支持来做工具链扩展。这里先给没接触过的读者解释一下MCPModel Context Protocol它本质上是给AI助手开了一扇操作电脑的窗口。没有MCP的时候AI只能跟你对话你要把代码复制来复制去有了MCPAI可以直接读写项目文件、执行终端命令、调用外部API等于把顾问变成了能动手的同事。我的整个项目流程——从初始化仓库、写后端接口、建数据库表到写前端页面、联调接口、跑测试——全部通过对话式指令完成中间几乎没有手写代码。这个过程里最大的体会是AI不是替你省掉了思考而是替你省掉了打字和翻文档的时间。你反而需要比平时更清楚自己想要什么因为AI的执行力太强了一个含糊的指令它会给你一个含糊的实现最后排查成本全在你这边。这篇文章我不想讲太多概念直接拆解我在这个项目里踩过的坑、验证过的思路以及最终沉淀下来的AI辅助全栈开发的通用工作流。无论你是想用AI做内部工具还是想快速做出MVP去验证想法这套流程应该能帮你少走不少弯路。2. 开工之前需求拆解和项目架构的AI辅助设计先说结论AI最适合做的不是从0到1的创意设计而是把模糊想法翻译成可实现的技术方案。前提是你得先自己把业务边界划清楚。2.1 我如何用对话把模糊想法变成可落地的需求文档我对Claude Code的第一条指令不是帮我做一个宠物App而是给了一段完整的业务描述用户需要记录宠物的基本信息、疫苗接种、驱虫记录、体重变化、日常照片还需要根据宠物的出生日期和疫苗周期自动生成提醒。然后我要求它输出一份可以作为开发依据的需求说明书包含角色划分、核心实体、状态流转、提醒规则。这个步骤非常关键。你给的信息越结构化AI输出的方案就越接近可执行的规格说明。我得到的需求文档里AI自动把实体拆成了User、Pet、VaccineRecord、WeightRecord、PhotoAlbum、ReminderTask六个核心对象并且设计了Pet.status健康/观察/生病和ReminderTask.status待处理/已完成/已过期两个状态机。这里有一个它做得比我预期好的地方它主动建议把疫苗提醒做成可配置的模板而不是硬编码每种疫苗的间隔天数这样用户以后添加新疫苗种类时不用改代码。但也有一个它做得不够的地方它默认所有数据都存在云端数据库没有考虑本地优先、离线可用的场景。这就是AI辅助开发的第一个经验AI倾向于给你一套最标准、最互联网化的解决方案但你的真实场景可能需要的是最合适而不是最标准。我复盘时发现国内很多宠物家庭其实有多人共用一个账号、需要离线记录的情况这些东西AI不会替你想到得你自己在需求阶段就提出来。所以我手动补充了两条约束一是支持多主人共享同一只宠物的档案二是核心记录支持离线写入联网后自动同步。这两条后来直接影响了我对数据层和API的设计。2.2 技术选型为什么我只给了大方向让AI去填细节技术选型上我没有完全放手让AI决定而是给它划了一个框后端用Python系前端用Web优先数据库要支持全文检索和地理位置查询部署要简单。在这个约束下它给出的方案是后端FastAPI SQLAlchemy 2.0 Alembic数据库迁移数据库PostgreSQL主存储 Redis提醒任务的队列和缓存前端React Vite Ant Design组件库移动端策略响应式Web应用先不做原生App这套选型我整体是认可的尤其是FastAPI它对异步支持和自动生成API文档的能力都很突出配合AI生成代码非常顺手。但有一个细节让我意外AI主动提议用Pydantic的model_validate来做DTO层的数据校验还说这样可以在API入口就把非法数据挡住。这确实是个好设计不过它也埋了个雷——后面对DTO和ORM模型的字段映射因为命名不一致让我在联调阶段花了不少时间排查。2.3 项目结构设计AI给的目录和我想的不一样AI给出的项目目录分成了backend/、frontend/、shared/、docs/四个顶层目录。其中shared/目录是它自己加进去的里面放前后端共享的常量定义和类型定义比如疫苗类型枚举、提醒周期配置。这个设计比我预想的要好因为前后端各自维护一套常量很容易出现前端改了疫苗名称后端还留着旧的这种隐性问题。实际编码中我只需要在shared/里改一处前后端的类型检查都能感知到变化。那一开始有没有不理想的地方有。AI生成的目录为了整洁把所有工具函数都塞进了utils/一个文件夹结果不到两周这个目录里就有三十多个文件命名也五花八门。后来我分三次重构才把utils/拆成了date_utils/、file_utils/、notification_utils/。我的建议是你在第一轮对话里就明确要求AI按模块分目录而不是按工具类分目录不然中后期维护会很难受。3. 核心功能实现从数据库建模到提醒引擎的完整链路这一章是整个项目最硬核的部分。我会把从建表、写CRUD、做提醒引擎到联调前端的过程完整捋一遍也会告诉你每一步我让AI干了什么、我自己补了什么。3.1 数据库建模让AI生成迁移脚本时我加了哪些约束我让AI按照需求文档中的实体关系生成SQLAlchemy模型和Alembic迁移脚本。它生成的初始版本挺规整每张表都有id、created_at、updated_at公共字段外键约束也建得完整。但我在审查时发现三个必须手动改的地方第一软删除问题。宠物档案这种数据用户误删后是有恢复诉求的。AI默认用的是硬删除我要求所有核心表增加deleted_at字段查询默认过滤已删除记录。这里有个坑Alembic迁移脚本生成时不会自动帮你改查询默认过滤这个逻辑你得在模型层加一个BaseQuery类或者给每个模型加一个常驻filter条件。AI在这一点上没有主动考虑全靠我在审查时提出来。第二时区存储策略。提醒任务最怕时区混乱。我要求数据库统一存储UTC时间所有返回给前端的时间都转换成用户的本地时区。AI生成的初始模型直接用DateTime(timezoneTrue)这个选择是对的但它没有考虑用户时区这个字段该放哪。我最后是在users表加了timezone字段提醒任务生成和查询时都围绕用户时区来算。第三索引设计。AI给外键都建了索引但是没有给高频查询字段建复合索引。比如用户最常用的场景是查看某只宠物最近一年的体重记录那weight_records表应该建(pet_id, recorded_at)复合索引。我让AI重新生成迁移脚本时明确列出了三组高频查询组合。这一步极其重要因为数据量一旦上去没有复合索引的表就是慢查询的重灾区。3.2 后端CRUD的边界哪些接口交给AI哪些必须手写CRUD接口是AI最擅长生成的代码没有之一。我让它按照Restful风格生成/pets、/users、/weight-records、/vaccine-records这套接口它连分页、排序、异常处理都一并写好了返回结构统一为{code, message, data}格式。这一部分基本是逐字审核即可用的水平。但有两类接口我没让AI碰自己动手写一是涉及多人共享宠物档案的权限校验二是需要事务跨多张表的操作。前者是因为权限逻辑涉及业务规则的前后依赖AI生成代码容易看上去对但边界漏;后者是因为事务回滚和异常处理的顺序用代码生成的代码经常会丢失一些边界分支。我的做法是给AI描述清楚输入输出让它先生成一版基准代码然后我手动修正事务边界和权限上下文。这里也验证了我的一个判断AI工具的正确用法是让它写80分的代码你把它补到95分而不是追求它一次性写到100分。3.3 提醒引擎这个模块我用对话迭代了五轮才稳定提醒引擎是整个项目的核心难点。业务规则很绕同一种疫苗可能只需要接种一次比如狂犬病首针也可能需要按年加强比如每年一次还可能是首次接种后间隔一个月再接种第二针。如果逻辑写死了后面每加一种疫苗类型都要改代码。所以我把这个模块单独拎出来和AI进行了五轮迭代对话。第一轮让AI设计提醒规则的存储结构。它给出了一张reminder_templates表字段包括vaccine_type、base_days、interval_days、repeat_type单次/重复、remind_before_days。这个结构基本合理。第二轮让AI设计下一次接种日期的计算逻辑。它生成了针对repeat_typeyearly和single两个分支的函数。但我发现它没有处理如果用户已经打了第二针提醒任务应立刻失效这个状态迁移。它说漏了我要求补上。第三轮我要求把提醒任务的生成和通知渠道解耦先接入站内信后续接微信模板消息和邮件。这一步AI表现很好它自动设计了一个NotificationChannel的抽象基类后续扩展时不需要修改已有的提醒生成逻辑。第四轮测试提醒任务的并发和重复生成问题。AI写了一个后台定时任务每隔一小时扫描一次需要生成提醒的记录。这里有个经典问题——多个worker同时跑的时候同一只宠物可能被生成多条重复提醒。AI给方案是加unique_constraint但我坚持用Redis分布式锁来保证任务幂等性。跟它解释清楚为什么unique_constraint不够之后它很快给出了基于SETNX的锁实现。这一步一定不能省重复提醒对用户体验的伤害是灾难性的。第五轮我把提醒文案模板化了不同的疫苗类型有不同的提醒话术还支持按用户偏好的语言展示。到这一步提醒引擎才算真正稳定下来。3.4 文件上传和图片处理AI最常忽略的坑宠物照片上传涉及图片压缩和缩略图生成。AI在处理文件上传接口时常规方案是直接把文件存到服务器本地或对象存储。我明确了需求原图会很大App内展示必须走压缩图。AI的初始方案上传后同步处理图片在小文件场景没问题但大图并发上传时接口延迟会很高。我让它改成了异步处理接口上传成功后就立即返回图片压缩和缩略图生成放到后台任务队列里用Celery Redis来实现。这个改动很关键实际测试中一张5MB的照片同步压到200KB耗时约1.2秒这在移动端弱网环境下是不可接受的但异步处理之后接口响应稳定在300毫秒以内。图片存储这块我踩了一个小坑AI默认用的文件名是UUID4但它没有保留原始文件的扩展名导致后来在前端img标签里无法正确渲染。我检查后才发现它存的图片后缀全是.bin。这个问题的根因就是AI生成代码时没有结合前端如何消费这个文件来思考。后来我手动加了一步从原始文件名中提取扩展名并和白名单比对再拼到UUID后面。这种细节问题就是典型的AI生成、人类兜底的案例。4. 前端开发与联调AI写页面有多快排坑就有多酸爽后端大概花了两天时间跑通前端联调又花了一天半。整体来说AI生成前端代码的速度比后端更快但看起来能用和真的能用之间存在巨大的鸿沟。4.1 用对话直接生成业务页面效率确实惊人我的做法是给AI描述每个页面的业务逻辑和数据字段然后要求它基于Ant Design组件库生成React页面。比如宠物档案页我给的描述是展示宠物基础信息、当前状态标签有编辑档案添加疫苗记录添加体重记录三个按钮疫苗记录按时间倒序排列最近一条显示醒目的下次接种时间提示。AI生成这个页面大概只花了几分钟布局、表单校验、接口调用都齐全我只需要微调样式间距。这种速度在传统开发模式里是不可想象的——以前写一个带表格、带表单、带状态标签的页面怎么着也得半天。但问题也出在这里。AI生成的组件虽然能跑但它倾向于把所有数据请求都放在组件内部导致页面加载时发四五个API请求。我审查网络面板时看到/pets、/vaccine-records、/weight-records、/photo-albums同时在请求每个都带了自己的loading状态页面会出现表格先出来标签后出来照片墙再出来的撕裂感。这不符合我对页面整体性的要求。后来我要求AI把所有列表页改成基于react-query的useQueries并发请求再统一合并成一个isLoading状态页面的稳定感立刻好了很多。4.2 联调阶段最容易翻车的三件小事联调阶段永远比你想的更漫长。我总结了这个项目里翻车的三个典型问题给后面参考的人提个醒时间格式的时区错位。后端返回的时间是ISO8601格式的UTC时间AI生成的格式化函数虽然正确但我漏看了它在体重记录列表里没有做时区转换导致前端展示的时间比实际晚了8小时。排查过程倒不难但这种事最容易发生在你觉得它肯定没问题的地方。枚举值的两端一致性。宠物状态这个字段后端定义的是healthy/observing/sick三个值前端组件里AI写成了健康/观察/生病三个中文文案。一次接口返回的英文值直接被塞进了Select组件结果渲染时选项全部为空。后来我把共享枚举挪到了shared/目录前后端都从那里引用就彻底解决了这类问题。文件上传的Content-Type校验。前端上传组件允许拖拽文件但AI生成的代码没有校验文件的MIME类型导致用户拖个.exe进去也能通过前端校验最后被后端拒绝报错信息还不友好。我让AI在前端加了beforeUpload钩子限制图片类型且大小不超过10MB并在后端也做了同样的校验。凡是涉及用户输入的地方前后端双重校验是底线。4.3 移动端适配的取舍最初规划是响应式Web不单独做原生App。实际开发中发现AI生成的响应式布局在手机端浏览器上表现可以接受但有两个交互细节需要单独优化一是照片上传在手机端要调用相机二是提醒消息要支持浏览器通知。这两个点AI都帮我处理了。相机调用直接走input typefile acceptimage/*不需要额外插件浏览器通知走Web Notifications API但需要用户授权权限。我在设置页加了权限引导逻辑并且通过HTTP协议的Vapid方案网页推送协议实现了提醒推送这样即使用户关闭网页系统也能推送通知到他们的设备。这里的坑是网页推送必须走HTTPS协议否则浏览器会拒绝授权。本地开发环境可以用localhost绕过但一旦上到测试环境就必须保证域名证书是有效的。5. 联调之外的进阶能力代码检索、自动补全和重构到了这个阶段项目主体功能已经能跑通但我发现AI的价值远不止生成代码。以下几个能力在后期维护中才是真正的效率杀手锏。5.1 用MCP做代码库级检索而不是靠记忆力项目大了之后传统聊天式AI的一个痛点就出来了上下文窗口装不下整个项目。你想让它改一个接口但它根本不记得这个接口在哪个文件、有没有被其他地方调用。MCP解决这个问题的思路是把项目文件系统暴露给AI。我配置好之后AI可以直接执行grep、ls、cat这样的命令。这意味着我可以直接问它这个项目中所有引用Pet.status的地方分别有哪些它会自己去全仓库搜索并给出一个清单而不是靠我给它贴代码。这个方法在重构和排查bug时节省了大量时间。我第一次体会到这个能力的价值是在排查删除宠物档案时未清理疫苗记录和照片记录这个问题时。我问AI整个项目里删除宠物会走到哪些代码路径它很快搜出了三处删除逻辑一处是后台管理接口一处是用户自助删除接口还有一处是定时清理任务。三处各自如何关联子表的逻辑都不一样。如果没有代码库级检索能力这种问题至少要花二十分钟自己翻代码用MCP大概三分钟就定位完了。5.2 让AI接手重构从直改到先聊方案项目中期我把PetService类里的一个方法从300行瘦身到80行全程只跟AI对话。我先是让它分析这个方法里的职责边界再让它用策略模式拆分成四个子模块最后让它执行重构。它拆得干净利落连测试用例都更新了。不过这里有一条血的教训重构之前必须让AI先生成一份测试用例清单并且确认清单里每一项都能跑过再动手。我第一次没做这步直接让AI开拆结果它把方法签名改掉了导致调用方全部报错。后来我要求它先写测试再用测试驱动重构整个过程才顺畅起来。这是一个典型的、值得所有人记住的AI辅助开发原则改动之前先定义怎么算改对了。5.3 自动补全不能省但也不能迷信Claude Code的Tab自动补全在写单元测试和重复性样板代码时效率极高——比如要给六个模型各写一份CRUD测试按传统方式要复制粘贴改好多遍现在只要把第一个模型写清楚后面的几乎可以直接生成。但我建议不要去迷信自动补全生成的业务逻辑。凡是涉及条件分支和状态流转的代码我都会多读一遍。这不是不信任而是我在这个项目里至少遇到过三次补全出来的代码能编译通过、但业务含义不对的情况。比如给疫苗记录做排序时它补全成了按created_at排序而不是按vaccinated_date排序——这俩在某些场景结果一样但在用户手动补录历史数据时就会出错。6. 测试与部署我用AI补齐了我最不擅长的环节测试和部署是我的短板传统开发时我往往靠能跑就行来敷衍。这回用AI我对这个环节的容忍度明显提高了。6.1 自动生成单元测试和集成测试我给AI的指令是基于pytest为所有核心service层写单元测试要求覆盖每种状态流转和异常分支。它生成了一百多个测试用例覆盖了CRUD、提醒引擎、权限校验、文件上传类型校验等模块并且全部能跑通。最让我惊喜的是它能主动构造一些边界值比如体重记录传-1公斤、疫苗记录时间早于宠物出生日期、提醒任务重复生成等。这些测试用例如果让我自己手写我大概率会漏掉一半。真正花时间的是集成测试。AI依赖测试数据库自动初始化的能力我让它用Testcontainers的PostgreSQL容器来做集成测试环境。这一步对CI很重要——每次代码提交流水线都会自动启一个临时数据库跑完整测试不会碰到测试环境里脏数据的问题。6.2 容器化部署与CI/CD流水线部署方案我用的是Docker Compose包含四个服务前端Nginx容器、后端FastAPI容器、PostgreSQL容器、Redis容器。AI生成了完整的docker-compose.yml和Dockerfile还自动配置了健康检查。我第一次把整个环境一键拉起时所有服务都顺利启动这个环节几乎没有卡壳。CI/CD我用的GitHub Actions。AI生成的流水线包含三个Joblint、test、build-and-push。最后一个Job只会在main分支的push和tag事件触发。流水线跑通的第一次我盯着绿色对勾看了很久——对于一个平时不太碰运维的人来说这种自动完成的体验确实有点上头。要提醒的是不要在本地开发环境直接依赖Docker里的数据库改表结构。Alembic迁移脚本在本地执行和容器内执行环境的差异会导致迁移失败。我的做法是开发环境统一用一个独立的PostgreSQL实例只在集成测试和部署时使用容器化数据库。这个区分帮我省掉了大量环境相关的抓狂时刻。6.3 部署之后的监控和日志这个环节容易被人忽略但一个App上线后的第一批问题几乎全得靠日志和监控来发现。AI帮我配置了基于Python logging的日志体系把请求日志、SQL慢查询日志、异常堆栈分开存储并且接入了集中式日志平台。上线第一天我就从日志里发现了一个真实的线上问题某个用户的timezone字段是空的导致提醒时间显示成了UTC时间。日志平台里对应的一行错误让我三分钟定位了根因。我的建议是从第一天开发就要求AI在关键业务入口埋结构化日志不要等到上线后再补。因为你永远不知道哪条日志会在事后帮你救命。7. 复盘这套AI辅助全栈的工作流最后沉淀下了什么写到这里项目本身已经完整跑完。最后我想把这些天反复迭代下来的一些判断和原则认真梳理一遍给同样在尝试这条路的人做个参考。第一AI辅助开发不是自动驾驶而是智能副驾。传统开发是自己握方向盘AI是帮你踩离合换挡的那只手但你仍然要盯着路况和目的地。在这个项目里需求边界、业务规则、权限设计、时区策略这些方向盘全在我手里AI做的是把每个操作执行得更快更稳。你越清楚自己的业务AI给你的价值就越大。第二明确的验收标准和迭代边界是关键。和AI对话时每个阶段都要说清楚成功长什么样。比如提醒引擎我定义的是同一宠物同一疫苗类型不能生成重复的待处理提醒比如前端页面我定义的是首屏加载只发一批并发请求。只要标准清晰AI的表现就非常稳定标准模糊AI就会给你一堆看起来挺对但经不起推敲的代码。第三代码审查仍然是不可省的环节。AI生成代码的速度快但它的训练数据来自大量普通项目它会默认你面临的也是一个普通项目。时区处理、软删除、事务边界、文件扩展名、复合索引这些问题AI不会主动替你考虑必须在审查时逐条过。我把审查重点列成一个清单权限、事务、时区、软删除、索引、文件格式、枚举一致、重复任务、日志埋点。每一项都是这次项目里真实踩过的坑。第四MCP让AI从聊天工具变成了项目协作者。代码库级检索、自动补全、自动重构、一键测试这些能力叠加起来改变的表面上是效率本质上是我作为开发者的工作习惯——我可以把更多精力放在业务判断和架构决策上而不是陷在文件里第几行有个bug这种琐碎里。这个项目的完整代码量加起来大概一万多行包含后端、前端、测试和部署配置。我从拆解需求到跑通全部测试再到部署上线总共用了四天。说实话按我自己之前的经验这个规模和完成度的工作量保守估计要两个星期。效率提升是实实在在的但前提是你得先成为一个心中有数的开发者。如果你也想尝试这套流程我的建议是拿一个你足够熟悉的业务场景不要拿AI生成一个商城这种没营养的Demo。找一个你真正在意的、有业务细节的小项目把需求写到你能讲清楚每个状态怎么流转的程度然后让AI陪你把它完整建出来。你会在这个过程里重新理解写代码这件事的边界在哪里。最后再分享一个小技巧把每次和AI的关键对话历史保存成项目内的docs/decisions.md文件。为什么这么建议因为AI生成的代码会不断演化几天后你回头看一段逻辑可能已经完全想不起来当初为什么这样设计。有了决策记录不管是自己维护还是交给别人接手都能少很多考古时间。我的下一个项目还会继续用这套工作流但已经打算从一开始就把这个文档目录建好。