企业官网建设流程全解析

• 文档
• 教程
• 知识库

导读

AI 工具正在改变软件的构建方式：传统"从零手写代码"的模式正在被一种新范式取代——你从需求出发生成一个可运行的产品，交给真实用户测试，再通过反复的迭代循环不断打磨，直到它可以正式交付。本文以 developer-roadmap 仓库中 ai-product-builder 路线图的核心节点 AI Product Creation Cycle 为骨架，结合仓库内各阶段文档，系统讲解"原型 → 生成 → 迭代 → 协作 → 部署"这一完整创建周期。读完本文，你将掌握每个阶段的目标、关键动作与可复用的判断标准，并能直接用它指导自己的 AI 产品开发流程。

范式转变：从手写代码到"生成—测试—迭代"

路线图开篇就点明了核心命题：AI 工具正在改变软件被构建的方式。传统的开发路径是"写代码 → 编译 → 发布"的线性流程；而新的范式是循环式的：

1. 生成：基于你的需求描述，由 AI 工具产出可运行的产品；
2. 测试：把产品交给真实用户使用，收集反馈；
3. 迭代：根据反馈反复精炼，直到产品准备好交付（ready to ship）。

这个循环式的创建周期取代了"一次性写完整套代码"的旧思路。它的价值在于：把不确定性前置——早期用低成本的生成和验证替代后期昂贵的返工，每一次循环都让产品更贴近用户真实需求，而不是停留在开发者的假设里。

创建周期的五阶段总览

ai-product-builder 路线图将整个创建周期拆分为五个可独立学习、可循环执行的阶段，对应的仓库文档如下：

这五个阶段并不一定是严格单向的——迭代阶段的反馈会驱动新一轮生成，部署后的用户数据又会进入下一轮迭代，形成一个持续循环。

第 0 步：定义与范围——写任何 prompt 之前先回答"为什么"

虽然定义与范围不在五阶段编号中，但路线图把它放在了最前面：Definition & Scope 明确指出：在写第一行 prompt 之前，你必须知道自己要构建什么、为什么构建。这包括三个动作：

• 定义问题：Problem Definition 建议用一两句话描述"你的应用解决什么问题、为谁解决"。如果连问题都说不清，生成结果必然失焦——这是整个流程中最重要的输入。
• 识别核心功能：明确哪些功能是必须的，防止 AI 生成你不需要的东西。
• 设定技术边界：划定项目的技术约束与范围，一个清晰的 scope 能节省大量时间。

从仓库文档的表述看，这一步的产出质量直接决定后续所有环节的上限："如果无法清晰地解释问题，生成的结果就会缺乏重点。"

阶段一：原型（Prototyping）——先验证意图，再花生成成本

1-prototyping 给出了原型的定义与价值：

原型是任何代码生成之前应用的可视化呈现。它帮助你与利益相关方对齐、尽早发现缺失的功能，并为生成工具提供具体的参考。它不需要很详细，只要足够清晰以传达意图即可。

原型的关键特性：

• 不需要精细：清晰到能传达意图即可，避免过早陷入实现细节；
• 三重复用价值：对齐干系人预期、提前暴露缺失功能、作为生成工具的"实物参考"。

原型工具的选择：从设计工具走向 AI 原型工具

choose-a-prototype-tool 记录了开发者工作方式的迁移：越来越多的人正从 Figma、Miro 这类传统设计工具，转向能直接从文字描述生成可点击原型的 AI 工具（如 Lovable、Replit、Bolt）。这类工具能让你在几分钟内从想法到可点击的东西，从而在投入完整的生成周期之前低成本验证概念。选择依据是你的熟悉程度与构建内容的复杂度。

原型阶段的验证：Feedback & Validation

Feedback & Validation 强调：在生成完整产品之前，先把原型分享给团队和潜在用户，寻找设计中的明显缺口与误解。在原型阶段发现这些问题，比生成之后修复要便宜得多——这正是循环范式"把不确定性前置"的具体体现。

阶段二：生成（Generation）——输入质量决定输出质量

2-generation 是这个周期的核心执行环节：

这一步由 AI 工具把你的原型与需求转成可运行的代码库。输出应包含前端、后端、数据库 schema 和 API 层。输出质量直接取决于你输入（prompt）的清晰度。

这意味着生成阶段的"完整交付物"有四个组成部分：

1. 前端（Front End）：用户直接交互的部分；
2. 后端（Back End）：处理业务逻辑的部分；
3. 数据库 schema：数据存储结构；
4. API 层：连接前端与后端的接口。

理解应用解剖：如何审查 AI 的产出

要审查生成结果、并在出问题时提出好问题，你需要理解应用的基本构成。App Anatomy 指出：每个应用都有相同的基本部件——用户交互的前端、处理逻辑的后端、存储数据的数据库、连接它们的 API。理解这一结构，你才能：

• 判断 AI 生成的前后端与数据库是否各司其职；
• 定位问题出在哪一层（界面、逻辑还是数据）；
• 向生成工具或团队成员提出更精确的问题。

关于这些部件的系统学习，仓库内提供了对应的专门路线图：前端可参考 frontend 路线图，后端可参考 backend 路线图，接口设计可参考 api-design 路线图。

阶段三：迭代（Refinement）——先判断改动类型，再决定改动方式

生成出代码库之后，你必然需要调整。3-refinement 给出了核心判断：有些改动是小的、局部化的；另一些则要求重新生成应用的大部分。开工前先判断属于哪种改动，能节省时间并降低破坏已有功能的风险。

路线图将改动明确分为两类：

局部改动（Targeted Change）：直接改代码

Targeted Change 的定义：局部改动是小型、局部化的修复——某个组件的 bug、布局调整、逻辑微调。这类改动应使用 AI 辅助编码工具（如 Cursor、Claude Code、Copilot）直接在代码中修改，而不触碰更广泛的架构。仓库中也有对应的独立文档可深入参考：cursor、claude-code、copilot。

结构性改动（New Feature / Structural Change）：回到生成工具

New Feature / Structural Change 的定义：当改动影响应用架构时——例如新增服务、重构数据模型、引入新的用户流程——应回到生成工具重新生成，而不是手动打补丁。这样能保持代码库的一致性，并减少技术债。这是循环范式区别于传统开发的关键点：结构性演进走"生成"通道，而不是在旧架构上叠加手工修改。

迭代驱动的测试体系

迭代阶段的质量保障离不开测试。路线图中为"原型 → 生成 → 迭代"的每一环都准备了对应的测试方法：unit-testing（单元测试）、integration-testing（集成测试）、e2e-testing（端到端测试），分别覆盖不同粒度的回归风险。

阶段四：协作（Collaboration）——引入他人，驱动下一轮迭代

4-collaboration 定义了这一阶段的作用：

在这一阶段，你把其他人带进流程：队友、测试者或早期用户。他们的反馈驱动下一轮迭代。这个节点也覆盖了多人同时工作时保持代码库稳定的工具与实践。

协作阶段包含两个层面：

• 人的层面：队友、测试者、早期用户成为反馈来源；
• 工程层面：多人协作需要版本控制、CI/CD 与托管服务来保持代码库稳定。路线图中为此准备了对应的协作基础设施文档，包括版本控制平台 github、gitlab，以及 CI 平台 azure-devops。

用户测试：观察行为，而非收集意见

协作阶段最重要的反馈来源是真实用户。User Testing 给出了清晰的方法论：

用户测试是把应用放到真实用户面前，观察他们如何使用。你找的不是"意见"，而是他们犹豫、困惑或做出意料之外行为的时刻。每一次测试都为下一轮迭代提供具体输入。

这段描述点出了用户测试的核心要领：关注行为数据（停顿、困惑、异常操作）而非主观评价，每次测试都是下一轮迭代的"具体输入"——这与整个创建周期的循环逻辑完全一致。

阶段五：部署（Deployment）——用最简单的方式起步，随增长扩展

5-deployment 明确了部署的本质与选型原则：

部署是让你的应用对真实用户可用的过程。正确的部署选项取决于你的技术经验、预期流量和预算。从满足需求的最简单选项开始，随着产品成长再逐步扩展。

部署选型的三要素：技术经验、预期流量、预算。路线图按这三要素提供了分层的部署选项：

• 前端/全栈托管平台：vercel、netlify、railway、render、digitalocean；
• 云平台：aws、azure、gcp、cloudflare；
• 数据存储：supabase、mongodb-atlas、postgresql-mysql；

核心原则始终是：从最简单且能满足需求的选项开始，不要为尚未到来的流量提前买单，随着产品成长再平滑升级。

把周期串起来：一份可执行的自检清单

综合 ai-product-builder 路线图的全部节点，一个健康的 AI 产品创建循环应满足以下检查点：

1. 定义清晰：能否用一两句话说清"为谁解决什么问题"？说不清就不该写 prompt；
2. 原型先行：是否已用可点击原型验证过核心概念？原型阶段的反馈是否已吸收？
3. 生成完整：AI 输出的代码库是否覆盖前端、后端、数据库 schema、API 四层？是否符合应用解剖结构？
4. 改动分类：本轮改动是局部修复（用 AI 编码工具直接改）还是结构性变更（回到生成工具重做）？开工前是否已判定？
5. 真实反馈：是否让真实用户在真实场景中测试过？收集到的是行为数据还是主观意见？
6. 最小部署：部署方案是否基于技术经验、预期流量、预算三者权衡？是否从最简单选项起步？

结语：迭代是常态，生成只是起点

developer-roadmap 的 ai-product-builder 路线图用"AI Product Creation Cycle"这一节点点破了 AI 时代软件构建的本质转变：生成不是一次性动作，而是循环中的一个环节。从原型验证意图，到生成完整应用，再到基于真实反馈迭代、协作、部署，每一次循环都让产品向"ready to ship"靠近一步。掌握这个周期，你就掌握了把 AI 生产力转化为真实产品的方法论——而这，正是 ai-product-builder 这条路线图想传递给每个开发者的核心能力。

• 文档
• 教程
• 知识库