30 个建站提示词，让需求具体到字段
这套以 CC0 授权的提示词覆盖多个 AI 建站工具，强调明确业务名称、页面顺序、表单字段、视觉风格与数据存储位置。作者建议每轮只调整一个需求，减少生成结果空泛或后端实现不完整的问题。
AI 深度解读
AI 建站工具经常交出同一种页面：顶部大图、三张功能卡片，再塞一堆占位文案。作者给出的解法是把业务、页面顺序、交互和数据去向写具体，并整理成了 30 条采用 CC0 授权的提示词，供不同建站工具使用。
这份清单适合拿来检查需求有没有写清楚。不过，原文没有提供生成结果或对照测试，「能做出可用网站」目前仍是作者的主张，不能直接当成效果保证。
页面千篇一律，可能是你把决定都留给了 AI
作者整理的提示词库叫 veloxahost/veloxa-build-prompts，声称可用于 Lovable、Bolt、v0、Replit 和 Veloxa Build。它覆盖小企业网站、个人页面、SaaS、迷你应用和社区网站。
这些提示词背后有六条规则：
- 写出具体的商家或产品名称。作者认为，「Rise & Crumb bakery」比「一家面包店」更容易引导模型生成具体文案。
- 按顺序列出页面区块，让 AI 沿着指定结构搭建。
- 逐项写明表单字段，例如姓名、电话、取货日期和商品。
- 给出两三种颜色、一个氛围描述，并明确「mobile first」。
- 说明数据存在哪里，迷你应用可以要求保存在浏览器。
- 每次追加修改只处理一件事，避免把所有要求堆进一条 2,000 词的提示词。
有用的细节，是能减少模型猜测的细节。
例如，原文的水管维修公司案例明确要求「Call now」按钮、24/7 紧急服务标识、服务地区、支持照片上传的报价表单，以及资质和评价区块。它给出的已经是业务页面清单，AI 不必自行猜测一家维修公司应该展示什么。
但名称只能帮助文案围绕具体对象展开，不能证明文案里的事实。经营年限、资质、评价仍需要真实材料，不能让模型补齐。
从展示页面到小应用，关键是把行为写出来
下面这条 SaaS 提示词既规定页面顺序，也要求注册后显示成功消息，解决了「只有一个表单外观」的问题：
Build a landing page for a SaaS product "ShipNote" that turns git commits into release notes. Sections: hero with a headline, subheadline and email waitlist form, a 3-feature grid with icons, a 'how it works' diagram in 3 steps, pricing teaser (Free, Pro), FAQ and footer. Show a success message after signup. Modern, purple accent.
要注意 Show a success message after signup：它明确了界面反馈，却没有交代邮箱提交到哪里。因此，生成成功提示不能证明候补名单已经保存。
费用分摊应用则进一步写出了输入、计算结果、存储位置和导出能力：
Build an app to split group expenses. Create a group, add people, add expenses (who paid, amount, who shares it, equal or custom split), and show balances plus the minimum set of payments to settle up. Mobile first, save in the browser, export a summary as text.
这里最关键的是 save in the browser。按作者的思路，把存储范围限定在浏览器，可以减少后端搭到一半的情况。
另一个需要认真验收的要求是 the minimum set of payments，即用最少的转账次数结清账目。提示词提出了目标，但原文没有给出算法、测试用例或生成结果，不能因为页面显示了结算建议，就认定它满足「最少」。
我的判断
我认可这六条规则的方向：它们把模糊愿望整理成了可以检查的需求。相比只写「现代、好看、专业」，明确区块、字段、反馈和存储位置，更方便前端开发者判断生成结果缺了什么。
不过，「小步修改优于一条长提示词」仍是经验之谈。作者没有提供不同提示词长度、不同工具或不同任务的对照数据；30 条模板能否稳定产出可用网站，也没有实测材料支撑。
作者同时披露，他们开发了 Veloxa Build。CC0 授权和面向多个工具的设计方便复用，但这篇文章也带有产品推广目的。
这套提示词适合作为需求起点，交付质量仍要靠验收。
能拿来做什么
- 做产品落地页原型时，先写清产品名称、区块顺序、表单字段和提交反馈，再让 AI 生成页面，减少第一轮返工。
- 做浏览器内的小工具时，明确写出本地保存和导出要求；如果需要跨设备使用，就要补充数据同步需求，不能沿用模板里的存储假设。
- 修改 AI 生成的页面时，每次只提出一个可检查的改动，例如调整移动端表单布局，完成后再继续下一项。
- 遇到费用分摊这类计算功能时，用具体账目核对结果，把「界面能操作」和「计算符合要求」分别验收。