企业官网建设流程全解析

如果你最近关注AI编程，一定听说过Claude Code。我第一次系统性地用它完整跑一个新项目，是做一个宠物生命周期管理App——从数据库设计、后端接口，到前端页面、定时提醒，全程让它生成代码，我只负责提需求、做决策、修bug。整个过程走下来，一个很真切的感受是：Claude Code的价值不在于替你秒杀一切，而在于把“我想做一个App”这种模糊念头，快速转成一个结构清晰、能跑、能改的项目雏形。

这篇文章就用这个宠物项目当案例，把从零搭建的全流程拆开讲：每个环节怎么向Claude Code下指令、怎么验收它生成的代码、遇到典型问题怎么排查。适合正在琢磨怎么把AI编程工具用到实际项目里的人，也适合想快速启动一个全栈小项目的独立开发者。即使你之前没碰过Claude Code，跟着把思路理顺，也能少走不少弯路。

1. 项目定位与需求拆解：宠物生命周期管理到底在管什么

1.1 为什么选这个项目：它天然适合检验AI全流程开发

宠物生命周期管理App，核心用户是养猫养狗的人。大家嘴上说爱宠物，实际行动往往滞后：疫苗什么时候该打下一针、驱虫药是不是过期了、体重从上次记录到现在涨了多少、家里的猫满7岁之后体检频率要不要提高——这些事靠脑子记很难不出错，尤其宠物从幼年到老年，健康管理的重点一直在变。

从开发角度，这类App有一个很适合AI生成的特点：它的业务规则清晰、边界明确。所谓生命周期，就是按年龄阶段划分，每个阶段对应不同的健康建议和提醒频率；所谓管理，就是围绕宠物档案、健康记录、提醒事项做增删改查。CRUD占大头，但又有少量逻辑判断（阶段判定、提醒时间计算）。这种项目让Claude Code来做全流程搭建，比我之前拿它写纯CRUD时要健壮得多，因为它需要AI同时处理数据结构设计、业务规则编码和前端交互，正好能暴露出AI编程的真本事和真毛病。

还有一个现实原因：我不需要接入任何真实的宠物医院或外部支付系统，MVP阶段所有数据都可以存在本地。这样既避免第三方接口的不可控变量，又能把注意力集中在AI协作流程本身上。

1.2 功能边界划定：MVP版本只做四件事

做项目先砍需求，我对Claude Code说的第一件事不是“给我做一个功能齐全的App”，而是明确MVP范围。宠物生命周期管理这个概念可以无限延伸，但要在一个新项目里通过AI快速落地，我只保留了四个模块：

• 宠物档案：记录基本信息，包括名字、物种（猫/狗）、品种、性别、出生日期或预估年龄、绝育状态、当前体重。
• 生命周期阶段展示：根据物种和当前日期自动算出宠物处于幼年期、成年期、中年期还是老年期，同时给出对应阶段的文案建议。
• 健康记录：疫苗、驱虫、就医、体重四种记录，每一条记录关联到具体宠物，疫苗和驱虫可以设置下次到期日。
• 提醒表格：根据到期日倒推，自动列出“即将到期”和“已过期”的提醒项，并按天展示。

一次绝育手术要不要记录进去？多宠家庭要不要支持共享？AI图片识别判断品种？这些我全部放进“后续扩展”清单，不进入第一版。功能砍到只剩核心后，Claude Code每次生成代码时上下文都会更聚焦，生成结果的可用率明显提升。你如果也想用AI搭项目，这个思路值得先定下来：先给它一个足够小的目标，再让它在小目标上做到位。

1.3 用Claude Code代替脚手架：从“写代码”到“编需求”的转变

传统做法是找一个脚手架模板，要么用命令行生成器，要么克隆一个开源项目再改。但模板往往带着大量用不到的代码，改起来反而费劲。Claude Code的方式本质不同：它不给你灌一个固定框架，而是根据你描述的数据模型和页面交互直接生成贴合需求的文件结构。

我实际体验下来，这种方式的优势有两个。第一，项目结构是“长”出来的，不是“搬”过来的。我需要什么表就让它建什么表，页面也只生成我要的那几个，不会有残留示例代码。第二，Claude Code能跨文件修改——我让它在宠物列表中加一个阶段标签，它会自己去改数据库查询语句、前端渲染逻辑和样式文件，这个能力是单文件代码补全工具做不到的。

但相应地，开发者角色要从“写代码的人”转变成“讲需求的人”。讲需求不是随便说一句“做一个宠物管理App”，而是要能拆出数据字段、说清页面流转、定义异常输入。也就是说，你得先有一个大致蓝图，Claude Code才能帮你把它落到代码里。这个转变需要刻意练习，我下面会详细讲一套我和它协作时的提问模板。

2. 环境准备与项目初始化：AI编程协作的基础设施

2.1 技术栈选择：为什么我选了这套组合

AI生成的代码能不能可靠运行，很大程度上取决于你选的技术栈是不是AI训练语料里最密集的那些。Claude Code生成小众框架和冷门语言的代码，出错率明显升高，它更擅长人人都在用的主流技术路线。所以我在选型上做了一个偏向“保守”的决策：

• 后端：Node.js + Express。生态成熟，中间件丰富，处理简单的JSON请求非常契合。
• 数据库：SQLite（通过better-sqlite3驱动）。数据库文件就是一个本地文件，零配置，不需要单独起服务。宠物管理App的数据量远未达到需要独立数据库服务的程度。
• 前端：纯HTML/CSS/JavaScript + Vite开发服务器。没有引入重型前端框架，页面数量少、交互不复杂，原生JS足够。这样AI生成代码时不会在框架语法上浪费上下文。
• 定时提醒：node-cron。每天跑一次检查，把即将到期的提醒状态更新一下。

这套组合的好处是，整个项目跑起来只需要一个Node环境，依赖数不超过十个，Windows和macOS上都能跑。数据库在文件里，换机器直接拷项目目录就行，对App类的本地优先项目非常省心。Claude Code对这套主流技术栈的掌握程度很高，我在后续生成代码时很少遇到“不知道怎么写的API”，更多时候是它生成了但我发现逻辑理解错了。

2.2 安装与初始化：让Claude Code先理解项目目录

Claude Code的安装很简单，装完以后在项目根目录启动会话，它会读当前目录下的文件，把已有代码纳入上下文。我第一次用的时候犯了个错误：空目录还没建好就急着告诉它“生成整个项目”，结果它在不清楚全局结构的情况下先写了七八个文件，后来为了调整目录结构折腾不少时间。

正确的初始化流程是这样：

• 先手动创建项目根目录，比如pets-lifecycle-app。
• 在根目录里启动Claude Code，第一条指令让它初始化npm项目，生成package.json，明确写入“type”: "module"，方便后续用ES Module规范。
• 第二条指令让它先输出整个项目的目录结构，不写代码，只列文件和文件夹。这一步非常关键，相当于先得到一张地图，验证目录规划是否合理。
• 目录结构确认后再逐个模块让它生成代码。

Claude Code在初始化阶段表现稳定，它生成的package.json基本不用改，scripts字段里通常已包含dev和start命令。你以后自己搭项目也可以沿用这个节奏：先有地图再施工，比让AI一上来就全量生成要稳得多。

2.3 第一次关键对话：一份合格的需求描述长什么样

很多人用AI编程工具的感受是“生成的代码离我想要的很远”，原因往往不是AI不行，而是需求描述不行。我在让Claude Code写第一版代码之前，给它的需求描述大致是这样一个模板：

• 项目背景：一个宠物生命周期管理App，核心用户是宠物主人。
• 功能范围：第一版只做宠物档案、健康记录、提醒列表三个模块。
• 技术约束：后端Express + better-sqlite3，前端原生JS + Vite，前后端分离，后端提供REST API。
• 数据字段：我直接列出需要的字段名和类型，不让它自由发挥。比如宠物表要有name、species、breed、birth_date、gender、neutered、weight。
• 交互方式：说清楚页面有哪些路由、列表页点击某项后跳到哪里。

Claude Code对这类结构化描述的理解精度很高。我举一个对比：你说“给宠物加年龄计算”，它会生成一个简单函数；你说“根据物种和出生日期计算当前生命阶段，猫和狗要不同规则，前端在档案卡片上展示对应标签和一句建议文案”，它就知道要写独立模块、暴露API、并在页面绑定数据。描述里信息密度越高，生成结果越接近可运行状态。沟通成本低的人，不是因为他运气好，而是因为他先想清楚了。

3. 核心功能模块的AI实现实录

3.1 数据库设计与建模：让AI生成表结构时要盯住三件事

数据库表是整个项目的根基，字段定错了后面全是返工。我让Claude Code设计了三张表，核心结构如下：

• pets表：id、pet_name、species、breed、birth_date、gender、neutered、weight、avatar_color（用于前端卡片显示）、created_at、updated_at。
• health_records表：id、pet_id、record_type（枚举值：vaccine、deworm、medical、weight）、record_date、note、next_due_date、created_at。
• reminders表：id、pet_id、reminder_type、due_date、status（pending/done/expired）、message、created_at。

在让Claude Code执行建表SQL和数据访问层代码时，我总结出必须人工盯住的三件事。

第一，外键关系的级联删除。Claude Code默认生成的外键没有明确指定ON DELETE行为，导致删除宠物时健康记录残留成为孤儿数据。我要求它给所有外键加上ON DELETE CASCADE，并且用一条明确指令把数据完整性补齐。

第二，日期字段的存储格式。SQLite本身没有真正的日期类型，它经常生成TEXT存储日期字符串。这在逻辑上是对的，但格式前后必须一致。AI如果在一个地方用YYYY-MM-DD，另一个地方存ISO时间戳，排序和比较就会出问题。我的处理方式是在需求里直接规定：所有日期字段统一存YYYY-MM-DD字符串，时间相关字段存ISO字符串。

第三，枚举字段的取值不能靠AI脑补。它可能会给record_type想出appointment这类不在计划内的值。我在指令里明确限定取值范围，并让它用于校验的常量数组，前端下拉框也读取同一个常量数组，避免魔法字符串。

3.2 后端API开发：把业务规则拆成AI能理解的最小单元

后端接口设计，我让Claude Code按资源维度拆文件：pets.js、healthRecords.js、reminders.js、lifecycle.js。每一批指令只让AI完成一个资源的路由，减少它同时处理多种业务逻辑时的混淆。

以宠物档案接口为例，我给的指令大概是：

• GET /api/pets：返回宠物列表，每条宠物附带id和通过生命周期函数计算出的阶段标签。
• GET /api/pets/:id：返回宠物详情，同时包含最近五条健康记录。
• POST /api/pets：新增宠物，校验所有字段，birth_date格式必须符合YYYY-MM-DD。
• PUT /api/pets/:id：更新宠物，体重字段变化时自动追加一条type为weight的健康记录。
• DELETE /api/pets/:id：级联删除所有关联记录。

这里最有价值的点是体重自动追加记录。这个规则是我主动提出的业务逻辑：称过体重之后，主人不用再手动记一笔历史。Claude Code最初生成的PUT接口只改pets表，完全没有考虑体重记录。我补充了一条指令：“当更新后的weight与旧值不同时，在health_records表中插入一条记录，然后更新宠物表中的当前体重。”它随即补上了事务处理，用一个transaction包裹了两次数据库写入，避免中途失败造成数据不一致。这种业务规则，AI不会替你想全，但你把规则说清楚之后，它的实现方式通常还挺规范。

3.3 生命周期阶段判定逻辑：AI擅长领域规则，前提是你先定义它

宠物生命周期阶段判定是这个App区别于普通宠物记录工具的地方。Claude Code对“猫狗不同年龄段”的常识有一定了解，但它不可能替你定义产品策略。我在编写这部分之前，先把规则表格明确写下来。

我的规则定义如下：猫的年龄阶段分为0-1岁（幼年）、1-7岁（成年）、7-10岁（中年）、10岁以上（老年）；狗的阶段依据体型进一步细分，10kg以下的小型犬，10岁以上算老年；10-25kg的中型犬，8岁以上算老年；超过25kg的大型犬，6岁即算老年。

这个规则表我直接在对话里传给Claude Code，并让它抽离成一个lifecycle.js模块，向外暴露一个calculateLifeStage(species, weightKg, birthDate)函数，返回值为stage对象，包括阶段名称和对应的健康建议文案。为了避免AI在if/else里层层嵌套写出难以维护的代码，我特别加了约束：用配置对象存储阈值，代码里不许出现魔法数字。它最终生成的是一个包含speciesRules配置和纯函数判定的模块，可读性不错。

前端拿到阶段标签后展示的颜色和文案，我让Claude Code在宠物卡片上做了一个统一映射：幼年用绿色，成年用蓝色，中年用橙色，老年用紫色。整体交互靠这个模块引出来，后续调整阈值只需要改配置，不需要在业务代码里翻找。

3.4 提醒系统实现：定时任务与到期判断，这里容易踩时区坑

提醒系统是这个项目里最容易踩坑的部分。宠物疫苗有到期日，驱虫有周期，常规体检根据不同生命阶段有新建议。我最初的设计是在reminders表里直接存next_due_date，然后每天跑一次cron任务，把所有明天到期的提醒找出来，状态改成pending。

Claude Code在node-cron的使用上写得很顺，七位cron表达式、每天凌晨两点跑一次，这部分几乎没费功夫。真正的问题出在时区处理上。它第一次生成的日期比较逻辑是用new Date()拿到服务器当前时间，再和数据库里的YYYY-MM-DD字符串做比较。这就有两个隐患：一是如果用new Date().toISOString()拿到的是UTC时间，在中国时区凌晨零点到八点之间会算出错误的“今天”；二是字符串和日期对象比较时会因为隐式转换产生隐性问题。

我的修正方案是：所有日期操作全部落在“日期字符串”层面。从数据库读出next_due_date字符串后，用JavaScript的Date对象解析，再用本地时区格式化当天日期。比较是否到期时，只比较日期字符串的字典序，不直接拿时间戳比。Claude Code按这个思路改写之后，提醒逻辑的确定性高了很多。你以后让AI写任何涉及日期计算的代码，都要主动追问一句“这里用的是什么时区规则”，AI主动处理时区的概率并不高。

前端提醒列表同时展示“已过期”“即将到期”“正常”三种状态。即将到期的提前天数我做成可配置项，目前设为7天。列表项点击后可标记为完成，完成时追加一条对应的疫苗或驱虫健康记录。这个联动逻辑在Claude Code生成时容易遗漏，我在验收时专门检查了一遍状态流转。

3.5 前端页面开发：列表、详情、表单和状态展示

前后端分离模式下，前端我让Claude Code生成三个页面：宠物列表页、宠物详情页、新增/编辑宠物表单页。页面用原生JS操作DOM，用fetch请求后端接口。

宠物列表页的核心是卡片式布局。每张卡片显示宠物头像（用首字母和随机背景色代替图片，规避图片上传需求）、名字、物种、生命阶段标签、当前体重和最近一次健康记录日期。Claude Code对CSS布局和响应式处理的能力让我比较意外，它生成的网格布局在手机宽度下自动变单列，代码量不大但效果可用。头像用一个圆形div加背景色实现，贴近实战的取舍。

宠物详情页是这个App信息密度最高的页面。它需要同时展示基本信息、生命周期阶段建议、健康记录时间线、提醒事项列表。Claude Code对时间线的处理方式是用一个纵向列表实现，每条记录显出记录类型图标、日期和备注，疫苗记录额外显示到期日。这些生成内容的问题集中在字段名映射上：它有时会用API返回里不存在的属性，比如把next_due_date误写成dueDate。这类问题在验收前端代码时要格外留意，直接用后端实际返回的数据结构去核对它写的DOM模板。

新增和编辑宠物共用一个表单页，提交时根据URL参数判断调用POST还是PUT接口。表单校验除了HTML5自带的必填和格式校验，还需要前端handleSubmit里做一层自定义校验：birth_date不能晚于今天，weight必须大于0。这些校验逻辑Claude Code会写，但需要你明确提出“在提交前和提交后各做一次校验”的要求，否则它可能只在后端做一次。

4. 生命周期模块的算法细节与提醒联动扩展

4.1 不同物种不同体型的阈值配置化

生命周期阶段判定看起来像一长串if/else，实际上应该是一份可配置的数据字典。我让Claude Code把猫犬规则放到lifecycleConfig对象里，结构大概是这样的：

const stageThresholds = { cat: [ { maxAgeMonths: 12, stage: 'kitten', label: '幼年', advice: '免疫力建立阶段，注意疫苗接种和营养配比' }, { maxAgeMonths: 84, stage: 'adult', label: '成年', advice: '保持规律体检，注意体重控制' }, { maxAgeMonths: 120, stage: 'senior', label: '中年', advice: '建议每年两次常规体检，关注肾脏和牙齿' }, { maxAgeMonths: Infinity, stage: 'geriatric', label: '老年', advice: '重点关注慢性病筛查和关节健康' } ], dog: { small: [ ... ], medium: [ ... ], large: [ ... ] } }

这里一个容易被忽略的点是：计算“年龄几个月”时，要用当前日期减去出生日期计算实际月数，而不是简单用年份乘以12，否则闰年误差和未满周年时的判断都会出错。Claude Code在我明确提示用“天数差值除以30.44得到月数”之后，生成的计算结果才稳定。

这个模块做好后，App里所有关于“当前处于什么阶段的宠物”的判断都有了单一数据源。前端展示阶段标签、后端计算提醒频率、未来要增加每个阶段的专属建议反馈，都可以从这一份配置派生出来。我后来让Claude Code增加了一个/API接口，根据阶段返回对应的健康建议列表，前端详情页的“阶段建议”区域直接改为调用这个接口，改动成本很低。

4.2 提醒频率如何随生命阶段变化：规则引擎带来的优势

生命周期阶段不只是标签展示，它直接影响提醒频率。我的产品设计里有一条联动规则：幼年期的猫狗，疫苗提醒频率比其他阶段更高；老年期宠物体检提醒的提前天数更长。

这些规则如果硬编码在cron任务里，后续调整会非常痛苦。我让Claude Code把提醒生成逻辑做成一个独立性较强的函数，输入是宠物当前阶段和对应的到期日，输出是下一次到期日的周期建议。例如猫的初始疫苗套餐三针到期后，自动生成一年后的加强针提醒；大型犬进入老年期后，常规体检提醒提前14天触发，而幼年狗提前7天即可。

Claude Code在生成这种规则引擎风格的代码时表现不错，关键在于我先把规则写成了“如果宠物处于某阶段，则使用某提前量和间隔”的条件表。AI对表格化的规则理解远比散文描述好，它生成的代码几乎就是规则表的直接翻译。这也算是一个经验：想让AI写出可维护的代码，你要先提供可维护的规则结构。

4.3 宠物档案完整性与数据验证

宠物档案字段里，物种和性别是有明确枚举范围的，出生日期有上限（不能晚于今天），体重有合理范围。Claude Code默认只处理必填校验，不会主动考虑合理性。我在后端增加了一个validatePetPayload函数，专门做字段级校验，然后让AI接在POST和PUT接口的最前面。

校验规则包括：species只接受cat或dog；gender只接受male/female/unknown；birthDate格式正则判断；weight限制在0.1kg到100kg之间；breed不允许空字符串，但允许填“中华田园猫”这样的非标准品种。Claude Code生成了校验错误的对象结构，每个字段返回友好提示，前端展示在表单对应输入框下方。这个模块让App的数据质量上了一个台阶，后续做任何统计功能时不用反复清洗脏数据。

5. 调试、测试与上线前检查：AI生成代码不等于能用

5.1 AI代码的常见错误类型与验收清单

Claude Code生成的第一个可运行版本，我粗略数了一下，能直接跑通主流程，但细看下来仍有不少隐患。我归纳出五类高频错误，你在验收AI生成代码时可以直接对照：跨文件属性名不一致、缺少错误处理分支、数据库事务缺失、时区和日期格式混用、以及前端没有加载状态导致接口慢时白屏。

我实际遇到的一个典型问题：宠物详情页的接口返回字段是lifeStage，但前端模板里用的是stage。Claude Code在独立生成前后端时产生了命名漂移。原因在于上下文窗口有限，它在生成前端时不一定还记得后端定义的确切字段名。解决办法是验收时让AI把后端返回的JSON示例拿出来，再要求它以前端实际读取字段为准做一遍对齐。这种问题如果靠人工逐行查，效率很低，而让AI自己对比文件修改，反而几分钟就搞定。

错误处理是另一个重灾区。AI生成的Express接口经常是try/catch之后直接res.status(500)，没有把具体错误信息返回给前端，也没有做日志输出。我让Claude Code增加统一的错误处理中间件，日志打印错误堆栈，返回给前端时只暴露可读信息。这一步不复杂，但能明显提升调试效率。

5.2 核心功能测试：跑通主流程比追求覆盖率更重要

我没有让Claude Code去做单元测试全覆盖，那对MVP阶段不划算。我让它写的是一个端到端测试脚本，用真实SQLite数据库文件跑一遍核心场景：创建宠物、记录疫苗、修改体重触发健康记录、生成提醒、查看列表。

这个脚本用Node内置的node:test模块实现，不需要额外测试框架。Claude Code在mock数据生成方面比较熟练，它能快速造出五六个宠物样本，覆盖不同物种、不同年龄段、不同阈值边界。测试执行过程中，我发现了一处边界问题：一只刚满13个月的猫，按规则应该已经进入成年期，但阶段判定函数把它归为幼年，因为计算月数时用的是整数年差值。我带着这个失败用例反馈给Claude Code，它很快修复了月数计算的精度问题。这类测试用例才是真实价值所在，它不是给领导看的覆盖率数字，而是抓住AI逻辑盲区的捕鼠夹。

5.3 本地运行与部署注意事项

本地运行阶段，我让Claude Code在README里写清楚启动步骤。由于数据库是文件型SQLite，首次启动需要运行一个初始化脚本，创建表结构并注入基础的阶段配置数据。这个脚本要在安装依赖后执行，否则直接跑服务会报“no such table: pets”的错误。

Claude Code在这方面容易犯的疏漏是：它默认你在开发环境里一切都能自动创建，但真实流程里初始化脚本和启动命令必须分开。把npm run init-db加到package.json里，并在README显著位置标注，是值得做的收尾工作。部署方面，这类型本地优先的App可以方便地用进程管理器托管，也可以先不需要传统服务器，直接跑Node进程即可。

6. 常见问题与实操避坑

6.1 指令粒度：给Claude Code的任务要拆到多细最合适

我实际操作后得出的经验是：任务粒度要控制在“一个对话能讲清楚、生成代码量不超过两百行”的级别。让Claude Code一次生成十个接口，它生成的代码质量会明显下降，因为要遵循的约束太多，它在细节处容易顾此失彼。把大需求拆成单文件单模块的增量任务，每次生成后人工检查或让其自检，我不会因为多几轮对话而焦虑，因为每一轮对话的质量都在提升。

另一个方向上，也不能把事情拆得过于细碎，比如让它只写一个utility函数，然后自己手动装配。这样会丧失AI整体的上下文优势。理想的粒度是独立功能点：一个数据访问模块、一条路由、一个前端组件，这些是Claude Code最舒服的单元。

6.2 上下文窗口管理：如何让AI记住前面的决策

Claude Code在一个长会话里可以跨文件引用之前生成的内容，但上下文窗口终究有限。项目推进到前端阶段时，我明显感觉它对数据库字段细节的记忆开始模糊，有时会在新生成代码里引用一个不存在的列名。

应对办法是主动给AI重建上下文，而不指望它全记住。我采取了两种有效手段。一是在关键文件头部写清楚模块职责注释，让AI读文件时能快速恢复记忆。二是定期让它输出当前项目的README或需求摘要文件，把已经确定的技术决策沉淀进去。每轮大规模修改前，我会让Claude Code阅读这个摘要文件，相当于给它一个压缩版的记忆卡。

6.3 生成代码的安全底线：AI偷懒的地方恰恰是隐患所在

AI生成代码在日常功能上很流畅，但在安全层面经常偷懒：不做SQL参数绑定、不做输入长度限制、不处理文件上传。SQLite场景相对还好，但如果换成PostgreSQL，SQL注入的风险会直接暴露。我在让Claude Code生成数据库查询时，特意要求它使用参数化查询，在代码里能看到问号占位符和传入参数数组，它照做了。我在审查时一条条核对过，没有发现字符串拼接SQL的情况。

还有一个容易被忽略的安全点是依赖安全。Claude Code会建议安装它熟悉的依赖，但版本号可能不是最新的。我让AI在项目初始化时把dependency版本都更新到当前稳定版本，并在完成后用npm audit做一次安全检查。依赖升级后需要回归测试一遍核心流程，因为依赖大版本变更确实存在破坏性风险。我实测下来，把better-sqlite3升级后，旧的初始化脚本里的某些API调用方式需要跟着调整，幸好测试脚本在这一步及时报了错。

6.4 Claude Code效能提升的小技巧

几次实践下来，我总结了一些能直接提升协作效率的小技巧。第一，在项目根目录放一个CLAUDE.md文件，把项目结构和技术约束写进去，Claude Code每次启动时会自动读取这个文件，这是最关键的记忆增强方式。第二，每次对话第一句先说明本次任务的目标文件路径，让它优先聚焦，避免在没有改动需求的文件里反复横跳。

第三，合并同类请求。比如同时调整列表页和详情页的颜色风格，我会放进一条指令而不是分两次下，避免AI重复加载文件。第四，善用“让AI先解释再写代码”。遇到复杂逻辑时，我会先问它打算怎么设计，表示认可后再让它实现，这样能防止它南辕北辙。这个习惯虽然多花了点时间，但返工率真的下降不少。

7. 后续扩展方向：从MVP到完整产品还要做什么

宠物生命周期管理App做到这里，已经是一个能日常使用的本地MVP。如果你想把项目往前推，有几个自然的扩展方向，而且每个我都验证过可以用同样的AI协作方式继续推进。

健康报告的统计可视化是第一个推荐方向。目前体重记录已经自动生成，数据沉淀了一定规模后，可以用图表库把体重趋势画成折线图。Claude Code在接入图表库并绑定数据方面效率很高，重点是要提前告诉它“横轴用记录日期，纵轴用体重”。第二个方向是多宠家庭的成员管理。目前所有宠物都在同一个列表里，如果要分家庭空间，需要加一个family表并调整接口的查询条件。

第三个方向是让健康记录支持附件，比如上传疫苗本照片。这个问题牵涉到文件存储方案，本地优先方案可以把图片存到项目目录，然后用静态路由绑定访问。Claude Code对multer这类上传中间件的用法很熟，但要注意文件类型白名单和大小限制，这两条必须显式写在需求里。最后，如果你熟悉移动端技术栈，可以让Claude Code生成一套移动端适配方案，甚至生成一个用Capacitor包裹的App版本，把现有Web页面跑在手机上。这些扩展让我觉得这个项目的价值还有很大空间，而且每一步都能复用现在这套数据库设计和生命周期规则。

从我这次实践的整体感觉来说，Claude Code最适合的场景就是这种业务规则清晰、技术栈主流、从零开始的全栈项目。它不一定能一次性给你完美的成品，但它是绝佳的结构化编码伙伴：只要你能把业务想清楚、把规则讲明白，它就能把大部分机械性编码工作消化掉，你只需要把精力放在判断和修正上。以后我开新项目时，大概率会先找Claude Code聊一轮需求和架构，再决定要不要从头写代码。