OX
OPEN-OX

// docs / pipeline

AI 生成流水线

下表为主路径步骤索引(含启动校验与可选意向引导);checkpoint 恢复时会跳过已完成阶段。 页面代码由多路 page_implement_agent 并行落地;修改阶段仍走独立 Modify Agent。

全部步骤

00
validate_skill_promptsverify

启动前校验 ai 流程技能 Markdown 的 frontmatter;失败则中止,避免运行中途才发现技能损坏。

01
project_intent_guidellm

可选(默认开启)。澄清建站意向;若需用户补充信息则提前结束并返回引导文案(不进入生成)。可用 enableIntentGuide=false 关闭。

02
analyze_project_requirementllm+tool

解析 ProjectBlueprint,配备 web_search。与步骤 03 并行。

03
infer_design_intentllm

独立风格/技术关键词推理;产物合并进设计系统输入与 blueprint.keywords。与步骤 02、03b 并行。

03b
extract_user_provided_contentllm+tool

从用户 query 整理 userProvidedContent(地址、图片 URL、菜单等),写入 content/user-provided.md。与步骤 02、03 并行;Plan 之前合并进 blueprint。

04
plan_projectllm

扩展为 PlannedProjectBlueprint(pages、sections、pageDesignPlan)。

05
generate_project_design_systemllm

根据 infer 文本 + 可选用户 styleGuide 生成 Style Reference 格式的 design-system.md。

06
apply_project_design_tokensllm

设计系统 Markdown + 当前 app/globals.css → LLM 产出完整 globals.css(保留模板结构意图)。须先于 Chrome / Page Agent。

07
architect_scaffold_agentllm+tool

Chrome 搭壳 Agent:快速落盘 app/layout.tsx 与 components/chrome/**(结构完整,Nav 链接可占位),供 Page Agent 只读。

08
page_implement_agent ×Mllm×M

每页一个工具闭环(读写文件、generate_image、page_implementation_complete 等),多页并行;不得修改 layout/chrome/globals。单页主区块须带 section id。

09
chrome_optimize_agentllm+tool

Chrome 精修 Agent:全部页面落盘后,用工具勘察真实路由与锚点,校正 Nav/Footer 并 polish chrome。

10
await_images ∥ install_dependenciesmixed

等待 Agent 触发的异步生图落盘;并与依赖扫描安装并行(npm),保证构建前图片与 node_modules 齐备。

11
typecheck_generatedverify

默认开启:对生成范围内的 TS/TSX 做语言服务级检查(非全仓 tsc)。失败时可触发 repair_build 打补丁。DISABLE_PREBUILD_TSC=1 跳过。

12
run_build (+ TS codeFix 内循环)build

本地 next build;编译错误时可反复尝试 TypeScript code-fix 再构建(与 repair 轮次配合)。

13
repair_build ×0-5llm+tool

构建仍失败时进入 Agent 修复循环(最多 5 轮);定位错误日志相关文件并增量修改。

并行策略

当前编排里与耗时相关的并行阶段大致如下:

// 第一层:analyze + infer_design_intent + extract_user_provided_content(当前实现)
await Promise.all([
  stepAnalyzeProjectRequirement(userInput),
  stepInferDesignIntent(userInput),
  stepExtractUserProvidedContent({ userInput }),
]);

// 第二层:plan_project → generate_project_design_system(串行;截图复刻时中间插入 analyze_screenshot_layout)
await stepPlanProject(...);
// 可选:stepAnalyzeScreenshotLayout(...)
await stepGenerateProjectDesignSystem(...);

// 第三层:apply_project_design_tokens 必须单独先完成(写 globals.css,避免与 Agent 写文件竞态)

// 第四层:Architect 先于 generatePages —— layout/chrome 落盘后再启动各 page_implement_agent,
//        第一轮 prompt 中的 layout.tsx 快照与磁盘一致。
await runArchitectStep({ blueprint, designSystem, ... });
const { files, pendingImages } = await generatePages({
  blueprint,
  designSystem,
  runtimeContext,
  ...,
});
Architect 仍是 chrome 的「单一拟定者」(layout + components/chrome/**);Page Agent 不得修改这些路径。 Page Agent 在 Architect 完成之后启动,第一轮预读上下文中的 layout 与落盘版本对齐;墙钟时间上该段约等于 Architect 耗时加上与「最慢的 Page Agent」并行段之和。

Skill 系统

风格技能是 public/skills/ 目录下的 Markdown 文件。每个文件描述一种视觉方向 — 字体规则、色彩哲学、组件风格。

public/skills/
├── minimal.md       # 极简:大量留白,单色调,字体主导
├── bold.md          # 大胆:高对比度,超大字体,强烈色彩
├── glassmorphism.md # 玻璃拟态:毛玻璃效果,半透明层次,纵深感
└── brutalist.md     # 野兽派:原始网格,强烈对比,反精致

运行时 Skill 发现

每个 section 在生成时自行发现并选择 skill(不再有全局 preselect 步骤)。 先用 LLM 从候选列表中选择,失败时降级到 score-based 关键词匹配。 完整的 Markdown 内容只在 section 实际生成时才加载。

// Runtime discovery — per section
const candidates = discoverSkillsBySectionType(root, section.type);
// LLM selection → fallback: scoreSkillFallback(candidates, haystack)
const skillPrompt = loadSelectedSkillPrompt(selectedSkillId);

Prompt 分层

page_implement_agent 的 system 由 frontend + steps/pageImplementAgent.md + shared/agentRuleBundles.ts 中列出的 prompts/rules/*.mdloadGuardrail 按序拼接)组成。architect_scaffold_agent / chrome_optimize_agent 同理,另含 section.navigation 等。 可按环境变量 PAGE_IMPLEMENT_AGENT_EXTRA_RULES / ARCHITECT_AGENT_EXTRA_RULES(逗号分隔 id)追加规则。

system prompt =
  frontend.md
  + steps/pageImplementAgent.md
  + rules from agentRuleBundles (e.g. tailwindMappingGuide, section.default, outputTsx…)

user message (page agent) =
  design-system.md
  + pre-read layout.tsx / globals.css / trees
  + page design plan + project context
  + optional hero skill body

构建修复

next build 失败后,修复步骤从错误输出中提取文件名, 只将相关文件发送给 LLM 修复 — 而非整个代码库。

const maxRepairAttempts = 5;
for (let repairRound = 0; repairRound <= maxRepairAttempts; repairRound++) {
  const buildResult = await stepRunBuild();
  if (buildResult.success) return { verificationStatus: "passed" };

  if (repairRound < maxRepairAttempts) {
    await stepRepairBuild({
      blueprint,
      buildOutput: buildResult.output,
      generatedFiles,
    });
    await autoInstallDependenciesForFiles(/* touched files */);
  }
}
最多 5 轮修复。如果构建仍然失败,verificationStatus 设为failed,项目标记为包含未验证文件。