企业官网建设流程全解析

Vibe Coding 工程化最佳实践：从 Prompt 到可用应用

作者用大量惨烈的代价，总结的经验

文章地址：https://developer.volcengine.com/articles/7584760695427301439

1. 三大黄金法则

🛡️ GitHub 是底裤：在写第一行代码前，先初始化 Git。这是你唯一的后悔药。

🎨 前端决定后端：先画出界面，用 Mock（模拟） 数据跑通交互。UI 怎么长，决定了后端数据库怎么建。

👮 治理大文件：当 AI 行代码时，立刻提醒拆分。不要让 AI 试图吞下一头大象。

2. 核心流程图

3. 四大核心原则

• 清晰具体 (Be Clear and Specific)：直白描述目标用户和核心功能。
  正例：“我想要一个帮助个人健身教练管理客户训练计划和追踪每周进展的应用。”
• 聚焦用户旅程 (Focus on the User’s Journey)：描述用户交互的关键步骤，帮助 AI 构建结构。
  正例：“用户注册后，可以创建新项目，为项目设定里程碑，并每日追踪进度。”
• 关注“是什么”，而非“怎么做” (What, not How)：专注于功能体验，不限制技术实现（如数据库设计）。
  正例：“应用需要能存储用户数据，加载速度快，并且设计风格要简洁现代。”
• 迭代和优化 (Iterate and Refine)：Prompt 只是起点，通过对话不断微调。

聚焦用户旅程：就是把用户体验描述更清楚一点

4. 三大提示词框架

• Who/What/Why 框架（经典起点）：
  示例：“WHO：独立咨询顾问。WHAT：管理客户项目和合同的仪表盘。WHY：节省时间，不错过交付。”
• 用户故事框架 (User Story)：
  示例：“作为一个自由设计师，我想要发送带有品牌标识的发票给客户并追踪支付状态，以便于我更好地管理我的现金流。”
• 功能分解框架 (Feature Breakdown)（适用于功能迭代）：
  示例：“1. 添加和组织潜在客户；2. 追踪联系状态；3. 添加备注和跟进提醒。”
  比如：

1. Who / What / Why​ WHO：后端开发工程师、运维人员、项目管理者 WHAT：一个基于 Golang 的任务调度与监控平台，支持定时任务、依赖编排、执行日志查询 WHY：Golang 在并发处理、编译部署和资源占用方面表现优秀，适合高吞吐、低延迟的调度场景；同时系统需要长期运行，Golang 的稳定性和跨平台编译能力能显著降低运维成本2. 用户故事​ 作为一个运维工程师，我想要在系统中创建和配置定时任务，以便于自动执行常规的数据备份和日志清理工作。 作为一个后端开发者，我想要定义任务之间的依赖关系，以便于在多个步骤之间自动串联执行流程。 作为一个项目管理者，我想要查看每个任务的历史执行记录和耗时统计，以便于分析系统瓶颈和优化资源分配。3. 功能分解​ 任务注册中心：支持任务的 CRUD 操作、参数校验、YAML/JSON 配置导入（涉及技术：Gin 路由、结构体校验、配置解析） 调度引擎：基于时间轮或cron表达式触发任务，支持并发控制和失败重试（涉及技术：robfig/cron 库、goroutine 调度、channel 通信） 依赖编排模块：定义任务间的 DAG 依赖关系，支持条件触发和并行执行（涉及技术：图数据结构、拓扑排序、状态机） 执行日志与监控：记录任务运行状态、耗时、输出内容，提供实时日志查看和告警通知（涉及技术：WebSocket、logrus、Prometheus 指标暴露） API 与前端接入层：提供 RESTful API 供管理界面调用，支持 Token 鉴权和 RBAC 权限控制（涉及技术：JWT、中间件、Swagger 文档）

5. 前端优先

5.1 视觉定调与设计规范 (Visual Style & Design System) <-- 新增关键步骤

• 原则：在写业务代码前，先定好“长什么样”，避免后续反复修改样式导致代码混乱。
• 如何定义 (How to Define)：
  关键词法：Modern (现代), Minimalist (极简), Playful (活泼), Brutalism (新丑/粗野主义)。
  对标法 (最佳捷径)：“Design style similar to Notion/Linear/Airbnb” 或 “Apple Human Interface Guidelines”。
  技术选型：明确指定 CSS 框架（推荐 Tailwind CSS）和组件库（如 Shadcn UI, Radix UI），这能极大保证产出的“高级感”。
• Prompt 示例：“请使用 Tailwind CSS 构建一个极简主义风格的 Dashboard。主色调为靛蓝色 (#6366f1)，背景使用柔和的浅灰色，卡片带有轻微的阴影和圆角。整体风格参考 Linear.app 的设计。”

5.2 核心实体建模 (Core Entity Modeling)

• 在动手写 UI 前，先识别业务中的核心对象（如 User, Order, Product）。
• 定义每个对象的关键属性（Attributes）和类型（Types）。
• Prompt 技巧：告诉 AI “请先帮我定义这个页面涉及的 JSON 数据结构（Schema），包含哪些字段和类型，然后再写 UI 代码”。

5.3 界面开发 (UI Construction)

• UI 状态完备性 (UI State Completeness)：拒绝“仅演示可用”。强制要求 AI 实现 Loading (加载中)、Error (加载失败)、Empty (无数据) 三种状态的 UI。
• 自动文件治理机制 (Automated File Governance)：
  痛点：人类常常忘记检查文件长度，直到太晚。
  解决方案：在对话一开始，就植入**“治理指令”**。
  Prompt 模板：“系统规则：请主动监控代码复杂度。当任一文件超过 250 行，或包含多个独立的逻辑块（如同时包含复杂的 Types 定义、Mock 数据和 UI 组件）时，请主动询问我：‘检测到文件复杂度较高，是否需要将其拆分为子组件（如 components/Header.tsx）或提取配置文件？’。”
• 专注于组件布局、CSS 样式、响应式设计。
• 使用基于上述实体定义生成的 Mock Data 填充界面。

5.4 交互逻辑 (Interaction Logic)

• 实现点击、跳转、表单验证、状态切换等前端逻辑。
  *关键点：前端的状态管理（State Management）应直接映射未来后端的数据库状态。

5.5 数据契约定义 (Data Contract Definition)

• 通过编写 Mock Data，实质上是在定义前后端交互的 API 接口文档。
• 产出物：一份清晰的 mock_data.js 或 TypeScript 接口定义 (interfaces.ts)，这将在后续直接作为后端数据库设计和 API 开发的规范。

第一步：先定“长相”​ 用一句话告诉 AI：“我要极简、现代、参考 Linear.app 的风格。” 指定技术：用 Tailwind CSS，主色#6366f1，浅灰背景，卡片圆角+轻阴影。第二步：先定义“数据长什么样”​ 别先写界面。先让 AI 列出这个页面要用到的数据结构，比如： User: id, name, email, avatar Order: id, user_id, total, status, created_at 这一步就是在定义后端的表结构和 API 字段。 第三步：让 AI 写界面 + Mock 数据​ 基于刚才的数据结构生成假数据（Mock Data）来填充页面。 同时要求 AI 必须实现三种状态： 加载中（Loading） 加载失败（Error） 无数据（Empty） 第四步：加上一条“文件治理”规则​ 在对话一开始就告诉 AI： “当任一文件超过250行，或同时包含 Types、Mock 数据和 UI 组件时，主动提醒我拆分。” 这样 AI 会自动帮你保持代码整洁，不会堆成一大坨。 第五步：交互逻辑​ 让 AI 实现点击、跳转、表单验证、筛选排序等前端交互。 前端状态名（如 orderStatus）要和后端字段名保持一致，方便后续对接。 第六步：交付两份“后端规格说明书”​ 一份：interfaces.ts（所有 TypeScript 接口定义） 一份：mock_data.ts（所有假数据） 这两份就是后端写 API 和数据库的“施工图纸”。

这篇心得，让我启发的先做界面的想法，为什么AI能识别界面的意图，是界面本身提供AI正确的选择，还是界面的接口完成这个事情？