Claude + Base44 入门：用结构化提示词构建网站与 AI 应用
英文原题：Claude Code Tutorial for Beginners: Build Website with AI (2026)
一、问题引入：新手不是“不懂代码”，而是缺少可执行的构建对话
这支视频的核心并不是“AI 会替你写代码”，而是更实际的一点：当工具可以从自然语言生成页面、数据库、表单和 AI 功能时，初学者真正需要先掌握的，是如何把想法拆成清晰的产品结构。
传统 Web 学习路线通常要求先学 HTML、CSS、JavaScript、框架、数据库、部署，然后才开始做完整项目。视频的立场是：这条路线仍然有价值，但不再是唯一入口。借助 Base44 这样的 AI App Builder 和 Claude 这样的推理模型，初学者可以先通过“清楚描述产品”来完成第一个可运行应用，再逐步补齐技术细节。
视频用了两个项目做对照：第一个是专业个人作品集网站，重点在布局、视觉层级、交互和转化；第二个是卡路里追踪器，重点在数据表、实时计算、周报、重置逻辑和 AI 分析。这种安排很适合作为“AI 建站/应用生成”的入门课，因为它同时覆盖了展示型页面和数据驱动应用两类常见需求。
这节课真正要训练的不是复制某个提示词，而是学会在生成之前先说清楚：页面有哪些区块、数据如何流动、用户要完成什么动作、结果如何验收。
二、核心概念：Prompt 不是一句命令，而是一份轻量产品规格
视频反复强调一个动作：不要一上来就让模型“帮我做个网站”。更好的做法，是先用一分钟规划结构，再把结构、视觉、数据和验收标准写进提示词。对初学者来说，这比背框架 API 更容易上手，也更接近真实的软件需求表达。
先列出页面或应用的核心模块：Hero、About、Portfolio、Contact，或者 Meal Form、Summary、Weekly Grid、AI Insights。
告诉模型要什么风格：暗色 editorial、charcoal slate、清晰字体层级、锐利卡片边框、足够留白。
有表单就明确字段，有计算就明确公式，有数据库就明确记录对象，避免让模型猜业务规则。
先生成基础版本，再用 follow-up prompt 添加 hover、警告状态、重置按钮、AI 分析等增量能力。
视频中的基础工作流
- 选择模型：在 Base44 工作区里确认 Claude/Opus 模型处于激活状态，避免后续生成质量不稳定。
- 写产品蓝图：用“第一、第二、第三、第四”的顺序列出模块和数据关系。
- 生成首版：让 Base44 根据结构生成页面、表单、数据库或仪表盘。
- 测试预览：切换桌面、平板、移动端，检查排版、响应式、按钮、表单和数据更新。
- 局部修复：出现错误时复制错误信息或描述问题，让 Claude 做定点修复，而不是整项目重来。
三、项目一：专业 Portfolio 网站，从“页面结构”开始
第一个项目是单页作品集网站。它的价值在于让新手理解：即使是一个看似简单的网站，也不应该只写“做得高级一点”。视频把它拆成四个明确区块：Hero、About、Portfolio Grid、Contact Form。
1. 先定义页面骨架
Hero 负责第一屏的定位和行动按钮；About 用两栏布局讲职业背景与执行原则；Portfolio 用三列项目卡展示能力；Contact 用表单收集询盘并写入内部数据库。这个拆法把视觉页面变成了可生成的结构化规格。
2. 首版之后再做交互修饰
视频没有在首个提示词里塞满所有细节，而是在页面生成后继续追加交互：按钮和卡片 hover 时微缩放，边框出现移动霓虹线。这种做法很实用，因为首版先验证结构，第二轮再提升质感，模型也更容易理解改动范围。
3. 验收不是“看起来还行”
作者建议在预览里切换桌面、平板、移动端，逐段检查标题是否清楚、留白是否稳定、表单是否能保存、卡片 hover 是否自然。这个动作对 AI 生成页面尤其重要：模型会生成“看似完整”的 UI，但真正可交付必须经过视口、交互和数据三个层面的检查。
四、项目二：卡路里追踪器，进入数据驱动应用
第二个项目比作品集更接近真实应用。它不只是页面展示，而是需要处理用户输入、数据库记录、实时汇总、条件样式、历史表格和 AI 分析。这个项目展示了 AI App Builder 能把自然语言需求转换成应用逻辑，但前提仍然是需求足够清楚。
1. 先搭应用壳，再补核心功能
第一轮提示只要求生成一个暗色 dashboard shell：干净容器、清晰标签、可承载追踪指标。第二轮才加入真正功能：Meal Logging Form、每日卡路里汇总、宏量营养素统计、7 天历史表格。这个顺序降低了复杂度，也方便逐步验收。
2. 数据字段必须显式
视频明确列出 meal name、calories、protein、carbs、fat 等字段，并要求保存到内部 daily meals 数据表。这里的经验是：只要涉及数据，就不要让模型自由发挥字段名称。字段越明确，后续计算、图表和 AI 分析越稳定。
3. 从工具到“智能工具”
第三轮加入 AI insights：按钮点击后把当前 meal database table 发送给 Claude，让模型分析饮食模式、宏量平衡，并输出三条个性化建议。这个功能说明了 Base44 的优势：它把模型调用、数据读取和 UI 输出封装起来，用户通过提示词描述意图，就能获得 AI 功能原型。
对 AI 生成应用来说，最危险的不是“模型不会写”，而是需求方没有把数据、状态和验收方式说清楚。
五、对比表格 / 决策矩阵：什么时候用哪种提示策略
| 场景 | 推荐提示方式 | 优点 | 风险 | 决策建议 |
|---|---|---|---|---|
| 展示型网站 | 先写页面区块 + 视觉风格 | 模型容易一次生成完整布局 | 如果没有明确 CTA 和内容层级，页面会显得泛泛 | 先列 Hero、About、Proof、Contact，再要求响应式检查 |
| 数据录入工具 | 明确字段、表名、保存行为 | 便于生成表单、数据库和列表视图 | 字段模糊会导致后续计算无法稳定 | 用字段清单替代自然语言描述，例如 calories/protein/carbs/fat |
| 实时计算仪表盘 | 写清楚聚合逻辑和目标值 | 能生成进度条、汇总卡、条件样式 | 目标单位不清会造成错误计算 | 把“固定目标 2000 kcal”和刷新时机写进 prompt |
| AI 分析功能 | 说明输入数据、分析任务、输出格式 | 让模型反馈更贴近用户记录 | 如果不限制输出，会变成泛泛建议 | 要求三条 insight，并指定输出卡片标题与样式 |
| 修复错误 | 复制错误或描述具体失败点 | 改动范围小，保留已有成果 | 重新写大 prompt 容易引入新问题 | 优先 follow-up prompt，只有新业务/新数据库才开新项目 |
可直接复用的提示词骨架
六、引用块：视频里最值得带走的三个判断
不要把 AI 当成魔法按钮；把它当成一个需要清晰规格的实现伙伴。
短而模糊的提示词省了输入时间，却会在返工、修复和重做里把时间还回去。
当项目目标、数据结构和视觉方向都明确时，自然语言就可以成为产品原型的第一种工程语言。
这些判断并不是鼓励跳过基础知识。更准确地说，它们改变了学习顺序：先通过 AI 完成可见项目，获得反馈和成就感；再回头学习代码、数据库、部署、性能和安全，就会更有上下文。