AI 建站最佳实践：分阶段评审而非一次性生成

我以前也做过和大家一样的糟糕演示。

打开 v0、OpenClaw，或者一个定制好的 GPT-5 Agent。

然后提示词写："给我建一个现代 SaaS 网站。"

首页看起来还行。定价页出了问题。文档页听起来像是有人猜出来的产品功能。页脚自己发明了一个你根本没上线的功能。

到这一步，"AI 网站生成"就停止了它的魔力，开始变成调试。

读完一堆关于基于 Agent 的网站工作流的讨论之后，我得出了一个不那么令人兴奋的观点：

网站的最佳 Agent 工作流不是一条巨大提示词。它是一个分阶段 Review 循环。

先起草一页。Review 它。修订它。审批它。然后再进入下一页。

这也是我用过的第一个感觉足够安全、可以真正用在生产网站上的工作流。

一次性网站提示词是一个花招

一次性生成并非没用。

如果你需要一个临时用的着陆页、一个粗糙的模型，或者一个快速的内部原型，一次提示词往往就够了。

但生产环境网站不是一项任务。

它们是一堆不同的任务伪装成了一件事：

信息架构、视觉设计、前端实现、文案撰写、SEO 优化。当你在一次交互中让一个 Agent 处理所有这些时，你得到的不是简单，而是糟糕的观测性失败。

如果结果错了，哪里出了问题？是产品定位不对？是 CTA 逻辑不一致？

用一条巨大提示词，所有东西都压缩成一个黑盒。这让输出难以信赖，更难修复。

这就是为什么更好的模式是：

先计划，再改动，合并前先 Review。

那些正经的 Agent 产品实际上在做什么

一旦我停止看营销视频，开始观察产品行为，这个模式就变得显而易见了。

有用的 Agent 产品都在收敛到同一件事：

plan first，change second，review before merge。

这不是"网站精灵"行为。这是可 Review 的工作者行为。

GitHub Copilot 有用，是因为它的行为更像一个有护栏的初级工程师，而不是一个老虎机。

Replit Agent 暴露 Plan 模式告诉你的也是同样的故事。如果一次性提示词就够用了，就没有理由停下来先审批任务列表了。

即便是 v0，虽然很擅长快速的首版起草，也在持续推动用户去迭代。那才是真正的产品界面。

生成是开局走法。Review 才是实际的工作流。

为什么 Reviewer Agent 比 Builder Agent 更好用

因为有边界的批判比从头到尾的连贯创作要容易得多。

Agent 通常更擅长 Review 一个东西，而不是一次通过就发明出整个正确的东西。

一个好的 Reviewer 提示词是具体的。

Make this page better.

有用的 Reviewer 提示词：

Review this pricing page.

Check for:
1. Claims not supported by product docs
2. CTA mismatch with plan limits
3. Accessibility issues in the JSX
4. Weak or vague plan differentiation
5. SEO problems in heading structure

Return only issues.
Rank them by severity.
Do not rewrite the whole page unless asked.

这给了你一个可操作的结果。它也很容易组合。

你可以为不同维度运行独立的 Reviewer：

事实准确性、CTA 逻辑、无障碍访问、前端代码质量、文案清晰度。

这比一个超级 Agent 同时试图扮演设计师、前端工程师、产品营销、文案编辑和法务审查员要理智得多。

Review 步骤可以很小

很多人听到"流水线"就想象一个有着 40 个节点、12 次重试、每 8 秒发一条 Slack 通知的 n8n 噩梦流程。

它不必那么复杂。

一个 Review 步骤可以只是一个额外的模型调用。

这里是一个使用 OpenAI 兼容客户端模式的最小 Node 示例：

import OpenAI from "openai";

const client = new OpenAI({
  apiKey: process.env.OPENAI_API_KEY,
});

const draft = `
<h1>Unlimited AI for every team</h1>
<p>Use the world's best model with no limits.</p>
<a href="/pricing">Start now</a>
`;

const reviewPrompt = `
You are reviewing a SaaS homepage draft.

Check for:
1. Unsupported claims
2. Vague value proposition
3. CTA clarity
4. Accessibility issues
5. Overpromising language

Return a JSON array of issues with:
- severity: low | medium | high
- type
- message
`;

const response = await client.responses.create({
  model: "gpt-5",
  input: [
    { role: "developer", content: reviewPrompt },
    { role: "user", content: draft },
  ],
});

console.log(response.output_text);

重要的不是确切的 SDK 调用方式。重要的是关注点分离。

一次调用起草。一次调用 Review。另一次调用只修订失败的部分。

一个理智的网站 Agent 工作流

这是一个我真正信任的、用于真实营销网站或文档中心的 workflow。

1. 先审批站点地图

在生成页面之前，让 Agent 提出结构方案。

Propose a sitemap for a developer-focused AI API product.
Include:
- homepage
- pricing
- docs
- integrations
- FAQ
- contact

For each page, explain its job in one sentence.
Do not write page copy yet.

如果结构错了，下游一切都会变差。

2. 一次只生成一个页面

不要让 Agent 生成整个网站。要求一个页面，并附带真实约束。

Generate the pricing page.

Constraints:
- audience: developers and automation engineers
- product: OpenAI-compatible API with flat monthly pricing
- avoid unsupported claims
- mention integrations with n8n, Make, Zapier, OpenClaw
- output: React + Tailwind

这保持了上下文在本地且可 Review。

3. 运行专门的 Review 通道

运行独立的 Reviewer，而不是一个模糊的"质量检查"。

示例 shell 脚本伪代码：

review_copy pricing.tsx
review_accessibility pricing.tsx
review_factuals pricing.tsx
review_seo pricing.tsx

或者在一个简单的 JS orchestrator 中：

const reviewers = [
  "factual accuracy",
  "accessibility",
  "frontend code quality",
  "conversion clarity",
];

4. 只修订失败的部分

这一步比人们想象的更重要。

不要因为一个 section 较弱就重新生成整个页面。

那样会丢失好的工作，并制造新问题。只修补具体问题。

Revise only the hero section.
Fix the unsupported claim about model access.
Keep the rest of the page unchanged.

5. 审批并提交

只有在 Review 通过之后，页面才能向前推进。

git checkout -b ai/pricing-page-v2
npm test
npm run lint
git add .
git commit -m "Revise pricing page after review pass"

真正的 Agent 工作流以无聊的方式失败

这实际上是我在阅读 OpenClaw 讨论时注意到的最有用的东西。

人们谈论 Agent 时把它们当作创意合作者。

实际上，很多失败只是基础设施层面的失败：

provider 配置错误、环境变量问题、源内容中有不支持的声明。

无聊的失败是可测试的。神奇的失败不是。

很多时候，工作流中最有用的步骤仍然是：

openclaw configure

这也是我更喜欢可 Review 的流水线而非一次性生成的另一个原因。它们更贴合实际的失败模式。

成本才是让这一切变得真实的东西

Draft-Review-Revise 循环会乘以模型调用次数。

这意味着更好的质量通常意味着更高的成本和更长的时间。

如果你在以下场景中做这件事：

每个页面 3 次 Review 通道、代码 + 文案 + 无障碍检查……

token 定价很快就不再是理论问题了。

这是很多团队在使用 Agent 工作流时遇到的相同问题：

工作流终于变好的时候，账单开始变得烦人了。

如果你在 n8n、Make、Zapier、OpenClaw 或自定义脚本中围绕 Agent 构建自动化，那就更是如此。一旦你开始添加 Reviewer、重试和迭代通道，用量增长很快。

这就是为什么定价模式和模型质量一样重要。

如果你的流程依赖重复调用、Review 循环和大量小型 Agent 任务，按 token 计费就会产生奇怪的激励：

跳过 Review 通道以省钱、即使输出很弱也避免重试、过度优化提示词而不是改进工作流、盯着用量而不是发版。

对于这种工作负载，固定费率的 API 访问更有意义。

这就是 Standard Compute 的吸引力：它为你提供 OpenAI 兼容 API 和可预测的月度定价，这样你就可以运行 Reviewer 密集型的 Agent 工作流，而不必把每次迭代都变成成本计算。

如果你的 Agent 整天都在做真实工作，这种定价模式比 token 焦虑要好相处得多。

什么时候一次性提示词仍然可以用

我不是在说永远不要用一次提示词。

在缺点低的时候使用一次性生成：

粗糙的启动原型、可丢弃的原型。

但是一旦网站变得重要起来——真实流量、真实声明、真实文档、真实的所有权——一次性工作流就开始看起来像一个糟糕的工程习惯了。

它相当于让 GitHub Copilot 直接合并到 main。

实际要点

如果你正在用 Agent 建网站，别再让它们当魔术师了。

让它们做可 Review 的工作。

一个简单版本是这样的：

1. Propose sitemap
2. Approve structure
3. Generate one page
4. Run reviewers
5. Patch specific issues
6. Commit only after approval

这个工作流没有演示版本那么花哨。但它也有用得多。

而且如果你在规模化运行这种循环，基础设施问题和提示词问题一样重要。

因为一旦 Agent 从新奇玩意儿变成流水线，可预测的算力就成了产品质量的一部分。

这才是真正的转变。

不是"AI 能建整个网站"。

当你把 AI 当作需要 Review 的工作者时，它才有用。