★ FEATURED ARTICLE 一个人接活儿的时候最磨人的不是某个算法想不明白也不是页面样式调不出来而是从零启动一个项目的那些琐碎事初始化目录、装依赖、配环境、起服务、建数据库。这些事不难但极其消耗耐心尤其你想快速验证一个产品想法到底值不值得做的时候。我最近用 Claude Code 完整走了一遍「从零搭建新项目」的流程目标是一款宠物生命周期管理App从空目录到能跑、能测、能部署全程 AI 深度参与。这篇内容就是想把这套流程原原本本记录下来我是怎么拆需求的怎么让 Claude Code 干活哪些地方它能干得又快又好哪些地方它给的东西必须返工以及最终的落地形态是什么。如果你也准备用 AI 编码工具从零搭一个项目或者对「AI 到底能在全流程里承担多少」很好奇这篇应该能给你一些实在的参考。1. 为什么选Claude Code来干这件事AI编码的真实边界先说结论Claude Code 不是一个替你思考的工具它是一个替你执行的手脚。这两者的区别决定了你用它做事的上限。1.1 一个终端里的结对程序员到底什么是Claude Code你可以把 Claude Code 理解成住在终端里的 AI 结对编程搭档。它和你在 IDE 里常用的 AI 补全插件的核心区别是补全插件只能感知你当前打开的文件Claude Code 看到的是整个项目目录。它可以在终端里读取文件、创建文件、修改代码、执行命令甚至在你允许的情况下跑测试和部署脚本。这意味着什么意味着它能把「跨文件的脏活累活」揽下来。比如我要给宠物管理 App 新增一个「提醒已读」功能以前我需要自己找到列表组件、找到状态管理、找到接口层、找到数据库表改四五个文件。现在我可以直接说帮我把提醒列表加上已读状态点击后更新数据库并刷新视图。它会自己定位相关文件改完告诉我改了哪些地方。但这个能力是有边界的。它擅长的是「在有明确上下文的情况下做工程化操作」而不是「替你做产品决策」。我在后面几节会反复提到这个边界因为所有翻车都源于我越过了这条线。1.2 我给它划定的工作边界能放权与不能放权在实际动手前我给 Claude Code 划了三条边界这个动作我认为比任何技术选型都重要。能放权的项目脚手架搭建、依赖安装、通用组件编写、接口 CRUD 代码生成、单元测试编写、报错排查。这些任务目标明确、规律性强AI 的速度是手写的数倍。能放权但必须复查的数据库 Schema 设计、状态管理方案、组件划分。它能给出合理方案但往往不是最适合你这个项目的方案需要人来做最终判断。不能放权的产品需求定义、生命周期阶段的业务规则、提醒策略的体验设计。这些是「凭什么这么做」的问题只有了解用户的人能定。我把这个边界写进第一轮对话里相当于给它一个「工作守则」。之后每一轮协作它都会遵循这个守则执行。事实证明这个过程很省心。2. 开工之前把「宠物生命周期管理」拆成可落地的需求文档很多人用 AI 写代码失败不是因为工具不行而是因为需求本身是糊的。我在开始写任何代码之前先用两个晚上把产品定义梳理清楚。2.1 需求原型的「一页纸」MVP功能清单宠物生命周期管理 App 这个名字听起来很宽泛落到功能层面其实是五件事宠物档案添加/编辑多只宠物记录姓名、种类、品种、生日、性别、绝育状态、头像。体重记录与曲线定期记录体重能看到一条随时间变化的曲线这是健康判断的基础数据。健康日历统一管理疫苗接种、驱虫、体检、用药等事件记录时间、下次时间、间隔周期。提醒系统根据健康日历自动生成「该打疫苗了」「该驱虫了」这类的提醒。生命周期阶段根据宠物种类和年龄自动推算当前处于幼年、成年还是老年阶段并给出对应的关怀建议。这些东西如果一开始全做项目周期会拖得没头没尾。我明确圈定 MVP 范围档案 体重曲线 健康日历里的疫苗记录 提醒列表。至于生命周期阶段展示作为首页的一个模块先做出来但不做复杂的推送。2.2 技术选型的取舍为什么是Web AppPWA对于「App」这个词常规思路是 React Native 或者 Flutter。我最终选择了 Web 技术栈React Vite Tailwind CSS 做前端Express 做后端SQLite 做数据库最终通过 PWA 方式让它可以「安装」到手机桌面。理由很朴素一个人做项目时间是最稀缺的资源。Web 全栈的迭代速度最快调试工具最成熟SQLite 零运维成本。PWA 虽然不如原生 App 能调用系统级能力但对于「记录宠物健康信息」这个场景桌面图标、离线可用、本地通知这几个能力已经足够。Claude Code 在 Web 技术栈上的训练数据也最充足生成的代码质量最高。2.3 让AI反向输出TODO用Claude Code验证需求完整性需求清单列完我没有直接让它写代码而是先把需求描述喂给它要求它「反向输出一份开发任务分解清单并指出需求中模糊、可能产生歧义的地方」。这一步的价值被严重低估。它输出的 TODO 里有两条确实是我没想清楚的一是「幼年/成年/老年」的定义没有明确标准不同物种不同体型差异很大二是提醒的「跳过逻辑」——如果用户漏打了一次疫苗下次提醒应该按原计划顺延还是重置周期这两个问题如果不提前定义开发时必然返工。我把这两条拍板生命周期阶段按物种和体型分档定义具体规则下一节讲漏打后的提醒按「重置为新的起始日」处理。需求到这里才算真正可执行。3. 从空目录到首版可运行Claude Code的项目初始化实操需求定了接下来就是让 Claude Code 发挥长项的第一个环节搭骨架。3.1 从空目录到前后端骨架一次会话搞定我的操作方式是在一个空目录里启动 Claude Code 会话然后给它一段完整的任务描述——我要做什么项目、用哪些技术栈、目录结构希望怎么组织。它很快就开始执行创建文件、生成配置、安装依赖整个过程我可以实时看到它操作的每一步。最终生成的骨架大概是这个样子pet-lifecycle-app/ ├── client/ # React Vite Tailwind 前端 │ ├── src/ │ │ ├── components/ # 各功能组件 │ │ ├── pages/ # 路由页面 │ │ ├── api/ # 后端接口封装 │ │ └── App.tsx │ └── package.json ├── server/ # Express 后端 │ ├── routes/ # 路由定义 │ ├── db/ # 数据库初始化与迁移脚本 │ ├── utils/ # 工具函数生命周期计算、日期处理等 │ └── index.js ├── package.json # 根目录脚本一键启动前后端 └── README.md这一轮它干得干净利落。我在验证后做了一件值得提倡的事要求它生成一份「项目启动说明」写进 README避免第二天自己都忘了怎么跑起来。3.2 第一次「npm run dev」后的连锁问题骨架生成不等于能跑。第一次执行启动命令问题一个接一个冒出来。第一个问题是 Node 版本不匹配。我本机的 Node 版本比较旧而它生成的 Vite 模板要求更高的版本。这不是代码问题是环境问题。解决方式很简单升级本机 Node 环境然后重新安装依赖。第二个问题是client里的开发服务器与server的 API 服务端口不一致前端请求后端需要跨域。Claude Code 给出的方案是在 Vite 配置里添加代理规则把前端的/api请求转发到后端的启动端口。这个方案是可行的但我在 review 时要求它解释为什么这样做——它说明了代理路径避免浏览器跨域限制的原理。我确认逻辑合理后才让它落地。第三个问题是它自动生成的 TypeScript 检查比较严格几个接口的类型没有对齐导致编译报错。这类问题很适合丢给它「编译报错了你看下怎么修」通常一轮就能解决。3.3 首版代码的人工体检清单跑通之后我没有着急进入功能开发而是做了一轮人工体检。我的体检清单大概是这样依赖版本是否过新或过旧Claude Code 倾向生成最新的依赖写法有些 API 已经变化需要按实际情况调整。目录结构是否真的符合项目体量对于一个小型 MVP它的分层刚好没有过度设计。启动脚本和说明是否完整确保换一台电脑也能五分钟跑起来。是否有无关的样板内容生成的模板里自带了一些 Demo 组件全部清理掉。这一步虽然花了一个多小时但避免了代码地基不稳导致全盘返工。看似「慢」其实是快。4. 宠物管理App的数据模型设计AI建模过程的完整记录骨架跑通后最核心的一件事来了数据模型。宠物生命周期管理 App 的所有功能都建立在这几张表之上这里的设计好坏直接决定后面能不能顺畅迭代。4.1 五张表的设计宠物档案、健康记录、体重日志、提醒与生命周期事件我在需求阶段就想好了核心实体然后把这个粗框架交给 Claude Code让它生成第一版 Schema。我告诉它的实体有宠物pet、体重记录weight_log、健康记录health_record、提醒reminder、生命周期事件lifecycle_event。它生成的表结构基本覆盖了我的需求但有几个地方需要推敲。比如它最初把「下一次到期时间」直接存在健康记录表里这初看合理但一旦用户漏打、重置周期这个字段就要连同提醒一起联动更新。我决定健康记录表存「本次发生日期」和「推荐间隔天数」下一次到期时间通过计算得出不落库。这样保持了单一数据源避免多份数据相互矛盾。4.2 AI生成的Schema与我修正的细节最终的数据库结构经过了几轮修正核心表的要点如下CREATE TABLE pets ( id INTEGER PRIMARY KEY AUTOINCREMENT, name TEXT NOT NULL, species TEXT NOT NULL, -- cat | dog breed TEXT, birthday TEXT NOT NULL, -- YYYY-MM-DD gender TEXT, neutered_flag INTEGER DEFAULT 0, avatar_path TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP, updated_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE health_records ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL REFERENCES pets(id) ON DELETE CASCADE, record_type TEXT NOT NULL, -- vaccine | deworm | checkup | medication title TEXT NOT NULL, occurred_date TEXT NOT NULL, interval_days INTEGER, -- 距下一次该事项的建议间隔可为空 note TEXT, created_at TEXT DEFAULT CURRENT_TIMESTAMP ); CREATE TABLE reminders ( id INTEGER PRIMARY KEY AUTOINCREMENT, pet_id INTEGER NOT NULL REFERENCES pets(id) ON DELETE CASCADE, health_record_id INTEGER REFERENCES health_records(id), type TEXT NOT NULL, title TEXT NOT NULL, remind_date TEXT NOT NULL, -- 到期日 status TEXT DEFAULT pending, -- pending | done | expired created_at TEXT DEFAULT CURRENT_TIMESTAMP );我修正的最重要的三个细节外键都加了ON DELETE CASCADE删除一只宠物时它的健康记录、体重、提醒全部自动清理不会留下孤儿数据。所有日期都用TEXT存储、格式统一为YYYY-MM-DD这和时区问题直接相关后面我会专门讲。reminders表里的status字段必须加索引因为用户打开 App 首页时最频繁的查询就是「今天到期的待处理提醒」。4.3 生命周期阶段的业务规则猫狗不同、体型不同这个规则是整款 App 里唯一需要「产品判断」的地方AI 不能替我做但可以把规则翻译成代码。我定义的规则是猫不满 1 岁为「幼猫」1 到 7 岁为「成年猫」7 岁以上为「熟龄猫」。狗不满 9 个月为「幼犬」之后按体型区分——小型犬10kg 以下9 个月到 8 岁算成年8 岁以上算老年中型犬10-25kg9 个月到 7 岁算成年大型犬25kg 以上9 个月到 6 岁算成年。这个划分肯定有争议不同机构的标准不同。但产品必须有明确规则后续如果要做精准化可以把品种差异做得更细。关键是这种判断不该由 AI 生成而应该由产品拥有者确认。我把规则文档写好然后让 Claude Code 按规则实现一个纯函数输入物种、体重、出生日期输出当前阶段标签。这个函数也成了后面首页「阶段卡片」的数据来源。5. 核心功能开发实录提醒、健康日历、生命周期事件是怎么一步步长出来的数据模型落地后功能开发进入正题。我没有一次性丢给 AI 一个巨型需求让它一口气写完而是拆成三个迭代每轮聚焦一个能独立验证的功能。5.1 迭代一宠物档案的增删改查第一轮迭代做档案 CRUD。我给 Claude Code 的任务是「实现宠物列表页、新增页面、详情页和编辑功能表单包含所有 pets 表字段姓名和种类必填生日用日期选择器性别用单选保存成功后跳转详情页」。这一轮它在 20 分钟内给出了完整的前后端代码。但我在 review 时发现它犯了一个典型错误表单里的「体重」字段直接放了一个文本输入框。这会导致用户填入任意文本脏数据流向后端。我不能接受这个设计。我要求它改成专门的数字输入组件并加一个联动逻辑用户在新增宠物时填写初始体重系统自动生成一条体重记录并作为体重曲线的起点。它修改后的逻辑是对的这个例子也说明AI 生成的代码可以很快但「产品交互的合理性」仍需要人来盯。5.2 迭代二健康日历与间隔提醒这一轮的核心是健康记录和提醒的联动。业务逻辑是用户在健康日历里新增一条疫苗记录填写接种日期和推荐间隔天数系统自动在「接种日期 间隔天数」生成一条待办提醒。这里涉及一个隐藏条件如果用户给同一只宠物添加了同类型的第二条记录比如第二次疫苗那么之前那条记录对应的未完成提醒应该被自动标记为「过期」然后新生成一条提醒。这个逻辑很容易被忽略我用自然语言描述了这个需求Claude Code 很好地理解了「旧提醒过期、新提醒生成」的事务关系并且把它实现在同一个数据库事务里保证了数据不会出现「两条疫苗提醒同时 pending」的情况。5.3 迭代三生命周期事件的时间线最后一轮是生命周期事件。这里的体验点在于与其冷冰冰地显示「你的狗处于成年期」不如把阶段变化做成有温度的时间线。我在首页设计了一个「生命阶段进度条」按照当前宠物所属物种和体型把生命周期拆成几个阶段用进度环展示当前走到哪个阶段旁边显示一句文案比如「奶狗期结束进入叛逆期」「要开始注意关节健康了」。同时宠物满岁、转阶段时生成一条「里程碑事件」记录展示在时间线页里。Claude Code 在实现时间线组件和里程碑生成逻辑上表现不错。但我后来又手动加了一个细节转阶段的历史事件没有回填也就是说一条宠物从幼年成为成年时时间线上能看到「成年」这个里程碑但看不到一条「幼年结束」的记录。我让它补了一个逻辑计算阶段转换点在时间线上是否应该展示。这类细节是人更容易察觉的AI 默认只会按你描述的需求做描述得越细成品越完整。5.4 协作心法怎么给AI下达清晰任务三轮迭代下来我发现一个规律我给 Claude Code 的任务描述质量直接决定代码产出质量。我的任务描述模板是四段式背景先说清楚当前项目的上下文。例如「我们已经有 pets 表和 health_records 表结构如下……」目标一句话说清这次要实现什么功能解决什么问题。约束明确技术栈、命名规范、需要遵守的既有代码风格。验收方式说清楚「我期望看到的效果」必要时举例。这样它输出的东西几乎不需要风格统一性的大改我只需要关注业务逻辑是否正确。6. 前端体验打磨AI做界面时的通病与我的修正方案因为要保证整体完成度我专门留了一轮给前端体验。这一轮的主角不再是写功能而是「挑毛病」。6.1 AI界面产品的三个典型毛病当 Claude Code 首轮生成的界面跑起来时我看到了三个典型的通病。第一个是「模板感」。因为 AI 的生成逻辑倾向于「按常见模式套」所有页面都是顶部导航加内容区、卡片加按钮的通用布局功能上没问题但缺少产品想要的情感层次。宠物管理这种偏生活化的产品界面应该更温暖、更有「陪伴感」而不是一个表格后台。第二个是空状态缺失。第一次使用 App 的用户的宠物列表是空的、健康日历是空的。AI 默认会在这种时候渲染一个空白页面用户完全不知道下一步该干嘛。这是产品体验的大缺口。第三个是移动端适配粗糙。虽然用了 Tailwind 的响应式类但组件在窄屏下的换行、间距、列表滚动表现明显不佳。既然目标是 PWA 安装到手机用这个必须重做。6.2 把首页改造成「驾驶舱」宠物卡片、今日提醒、阶段进度我的修正方案是重新设计首页信息架构让它变成「一打开就能看到最重要的三件事」的驾驶舱页面顶部是当前选中宠物的头像卡片看一眼知道是哪只宠物。中间是一个大号的今日提醒卡片今天到期的疫苗、驱虫事项有「标记完成」按钮直接操作。下方是生命周期阶段进度条和一句阶段寄语。再往下才是健康日历的最近记录入口。这个重构让 Claude Code 擅长和不擅长的部分都充分暴露了让它实现布局、响应式、进度条组件很快但「信息优先级判断」是我的职责。我给它的关键指令是「首页只保留一个主要行动点其余都做成入口」它执行的正是这个判断。6.3 PWA与移动端适配的落地操作把 Web 应用变成可安装的 PWA需要做三件事配置 manifest 文件、注册 Service Worker、准备合适的图标。Claude Code 完成了 manifest 和 Service Worker 的基础版本但我发现 Service Worker 的缓存策略有问题——它默认做了「网络优先」的缓存结果开发环境下修改代码后页面一直显示旧版本。我让它改成「网络优先、缓存兜底」的策略并且在后端接口请求上配置了排除规则避免 API 响应被错误地缓存。移动端适配方面我要求所有主要页面在 375px 宽度下走一遍逐屏截图检查。发现的问题包括日期选择器被键盘遮挡、宠物卡片图片在窄屏下变形、表格类内容在手机上横滚。这些问题说不上是 AI 的错它们只存在于「认真用真机/模拟器过一遍」这个环节。7. 测试与上线前检查AI生成的代码不能直接上生产功能全部跑通后我意识到一件事Claude Code 生成的代码如果直接发布风险极高。它在写代码时目标是「实现功能逻辑」而不是「覆盖所有边界情况」。用户不会按你预期的路径操作数据也不会总是干净的。7.1 测试策略只测核心不追覆盖率对于这类小项目追求测试覆盖率不现实也不划算。我的策略是只对两类逻辑写单元测试一类是生命周期阶段计算函数另一类是提醒到期日期计算。比如生命周期阶段函数输入不同的物种、体重、出生日期必须稳定输出正确的阶段和对应的文案。这类纯函数测试起来成本低收益高。提醒日期计算则要覆盖间隔跨月、跨年的场景。UI 层面我不做单测但做了两轮手动验收第一轮按正常流程走一遍新增宠物到标记提醒完成第二轮故意走「反人类」流程空着必填项提交、重复点击保存按钮、同一只宠物快速添加多条疫苗记录。第二轮抓出的 bug 比第一轮多得多。7.2 三次实测翻车与根因必须承认测试阶段翻车不少我挑了三个典型的说说。第一个是日期偏移。这个问题在提醒计算里暴露。当时 Claude Code 生成的逻辑里用了new Date(YYYY-MM-DD)这种方式代码在其本机环境里跑没问题但部署到服务器后由于服务器时区设置不同部分日期被解析成前一天。根因是「把日期字符串当成了时间戳来处理」。修复方式是所有日期处理逻辑都统一用「年月日拆分计算」不经过new Date()的时区转换。这也是我在数据模型设计时坚持日期用TEXT存储的原因。第二个是 SQLite 的并发写入问题。本地开发时通常只有我一个连接但上线后有多个用户同时写入提醒时SQLite 会报「database is locked」。这个问题不是 AI 能单独解决的它源于选型。我的处理思路是所有写数据库的操作强制经过同一个连接串行执行并且把单次事务时间压到最短。对一个小型 MVP 来说这个方案代价最低。第三个是提醒重复触发。标记为「已完成」的提醒在列表重新渲染后偶尔会变回待办。排查后发现前端更新状态时只是改了本地内存里的对象没有同步调用后端接口导致刷新后数据还是旧的。修复方式很简单把状态更新改为「乐观更新 后端确认回写」。这也提醒了我AI 改前端交互逻辑时不太会自动补齐「数据一致性」的闭环需要人去推演数据流。7.3 上线前的安全与部署清单部署之前我自查了三件事环境变量全部外置数据库路径、接口密钥、监听端口不能写死在代码里。Claude Code 生成的基础代码里隐藏了一个「默认口令」配置这类硬编码必须清理。输入校验覆盖后端前端校验可以提升体验但后端必须自己再做一层校验。我要求它在所有写接口上加了字段校验非法数据一律 400 拒绝。依赖安全扫描运行依赖检查命令确认没有高危漏洞有的话逐项升级或处理。部署路径上我最终选择的是前端构建后部署到支持静态资源的托管平台后端 Express 部署到一个支持 Node 的托管服务SQLite 数据库文件存放在后端的持久化存储目录里。为了演示方便整个部署过程也是让 Claude Code 配合执行的但每一步生成的环境配置我都先看懂、再执行。这轮做完项目就到了一个「可以真正用起来」的状态。从有这个想法到跑通全流程花了大约两周的业余时间其中大量琐碎工作由 AI 分担我在其中的角色更像产品经理加代码审查员。最后再分享一个小技巧多轮协作之后Claude Code 会积累大量上下文。每次让它完成一个大阶段我会让它顺手把这个阶段的改动要点、涉及文件、尚未解决事项写进项目里的一个开发日志文档。这个习惯帮了大忙——因为我发现它对自己的操作是有短期记忆的但「周一来、周五用」中间的决策过程可能就模糊了。让 AI 把工作留痕在项目里相当于给自己的工程流程加了一个「思维备份」。
阅读完成 · 觉得有帮助？
