企业官网建设流程全解析

创意工具别把生成结果直接交给用户

创意工具接入 AI 后，设计、提示词和前端实现往往有不同诉求：设计希望输出有变化，工程需要稳定结构，产品则关心用户能否编辑和交付。模型生成排版 JSON 时可能带有额外文本或不符合预期的字段，因此不能让原始输出直接进入组件渲染。

冲突在所难免。设计师觉得“AI 生成的内容不够有灵感”，工程师抱怨“类型不安全根本无法上线”。如果只靠在 Slack 里互相指责，或者机械地把 Prompt 改了又改，产品很快就会陷入发布停滞。

1. 排查现场：从一连串解析报错日志找根因

线上日志告警群突然弹出数十条JSON.parse error异常。我们调取生产环境的流式响应日志，用命令行过滤排查：

# 提取最近 100 条 LLM 生成结果并过滤不符合 Schema 的异常记录 tail -n 500 /var/log/creative-agent/generation.log \ | grep "RAW_LLM_OUTPUT" \ | jq -r '.output' \ | grep -v '^{"version":' \ | head -n 10

常见问题包括 JSON 外包裹说明、缺失必填字段、类型不符或版本不兼容。排查时记录脱敏后的原始输出、解析错误和请求版本，以便区分模型输出、Schema 演进和前端兼容问题。

最初 Prompt 工程师提出在 Prompt 结尾加上“绝对不要输出额外解释”的警告。但在实际测试中，当请求并发量陡增或者上下文接近上限时，大模型依然有 3% 到 5% 的概率打破这一承诺。试图用非确定性的自然语言去约束非确定性的模型，本质上是在撞大运。

2. 冲突根源：角色之间的目标错位

跨角色协作的冲突并非来自个人恩怨，而是来自于不同岗位的核心诉求差异：

• UX 设计师追求视觉表达的自由度与多样性，讨厌过于呆板的固定模版；
• Prompt 工程师倾向于调整温度参数（Temperature）与系统指令，让生成效果更精彩；
• 前端/后端工程师关注的是生产环境的绝对稳定性、类型安全与组件渲染的低延迟。

过去大家各干各的：设计师交稿后，Prompt 工程师盲改提示词，工程师写了一堆复杂的正则表达式来提取 JSON。结果只要 Prompt 微调一个字段，前端页面就集体崩塌。

3. 确定性网关：用 Schema 契约治理非确定性生成

解决冲突的突破口在于解耦。我们不再强求 LLM 输出百分百完美的 JSON，而是在 LLM 与前端组件之间搭建一层确定性的契约拦截网关。

网关的核心原则只有两条：

1. 强 Schema 约束：所有创意数据应通过 Zod 校验，字段缺失立刻补全默认值。
2. 容错修复策略：对畸变文本进行正则清洗与结构重建，超过上限才执行平滑降级。

以下是我们在生产环境中使用的 Schema 校验与自动修复拦截器代码：

import { z } from "zod"; // 1. 定义创意排版模版的强类型契约 export const CreativeLayoutSchema = z.object({ version: z.string().default("1.0.0"), title: z.string().min(1).max(50), themeColor: z.string().regex(/^#([A-Fa-F0-9]{6})$/).default("#1E293B"), cards: z.array( z.object({ id: z.string(), header: z.string(), body: z.string(), layoutType: z.enum(["hero", "feature", "quote"]).default("feature"), }) ).min(1), }); export type CreativeLayout = z.infer<typeof CreativeLayoutSchema>; // 2. 自动修复畸变 JSON 的确定性解析器 export function parseAndRepairLayout(rawOutput: string): CreativeLayout { let cleaned = rawOutput.trim(); // 清理 Markdown 代码块包裹 if (cleaned.startsWith("```")) { cleaned = cleaned.replace(/^```(?:json)?\s*/i, "").replace(/\s*```$/, ""); } // 提取首个大括号截取的有效 JSON 区间 const firstOpen = cleaned.indexOf("{"); const lastClose = cleaned.lastIndexOf("}"); if (firstOpen !== -1 && lastClose > firstOpen) { cleaned = cleaned.substring(firstOpen, lastClose + 1); } try { const rawJson = JSON.parse(cleaned); // 使用 Zod 进行数据清洗与默认值注入 const validated = CreativeLayoutSchema.safeParse(rawJson); if (validated.success) { return validated.data; } // 如果缺少次要字段，使用降级逻辑补全 console.warn("[Schema Guard] 部分字段校验失败，注入默认补丁:", validated.error.format()); return { version: "1.0.0-fallback", title: rawJson.title || "未命名创意草稿", themeColor: "#1E293B", cards: Array.isArray(rawJson.cards) && rawJson.cards.length > 0 ? rawJson.cards.map((c: any, idx: number) => ({ id: c.id || `card-${idx}`, header: c.header || "创意点", body: c.body || "", layoutType: "feature", })) : [{ id: "default-1", header: "系统默认提示", body: rawOutput.slice(0, 100), layoutType: "hero" }], }; } catch (err) { console.error("[Schema Guard] 严重 JSON 语法解析错误，触发兜底模版", err); return getEmergencyFallbackLayout(); } } function getEmergencyFallbackLayout(): CreativeLayout { return { version: "1.0.0-emergency", title: "创意内容生成中", themeColor: "#64748B", cards: [ { id: "fallback-card", header: "提示", body: "当前样式布局正在调整，请稍后刷新重试。", layoutType: "hero", }, ], }; }

4. 跨角色协作的落地方案

搭建完拦截网关后，我们在团队内部建立了三条具体的协作规则，消除了过去推诿扯皮的现象：

第一条：Schema 变更是唯一合法沟通语言

设计师和 Prompt 工程师如果想新增一种排版组件，不能直接改提示词，应先提交 Pull Request 修改CreativeLayoutSchema。只有 Schema 通过了前端的类型检查，Prompt 工程师才能在系统提示词里追加对应字段说明。

第二条：建立 Prompt 断言回归测试集

工程师编写自动化测试脚本，把过去生产环境中攒下的 200 多个畸变 Prompt 输出样本做成基准测试套件（Benchmark Suite）。任何 Prompt 的微调都应通过测试脚本的校验，确保修复成功率达到 99% 以上。

# 每次修改 Prompt 后运行断言测试 npx tsx scripts/test-prompt-schema.ts --dataset=test/fixtures/raw_outputs.json

第三条：数据监控透明化与指标共担

告警群里的日志不再只抄送给开发。我们在 Grafana 上建立了专门的监控大盘，展示SchemaParseSuccessRate（Schema 解析成功率）与AutoRepairRate（自动修复率）。系统会自动提示 Prompt 工程师优化结构描述；当解析失败率低于 0.1% 时，开发团队不再干涉 Prompt 的创意调优。

跨角色协作的实质不是谁说服谁，而是用确定性的工程防线为各自的创意探索兜底。有了确定性的 Schema 校验与容错修复策略，设计师和 Prompt 工程师可以大胆尝试新的创意模式，而前端工程师也能睡个安稳觉。