企业官网建设流程全解析

1. 项目概述：一条推文引发的Prompt工程实践反思

最近刷到 Boris Cherny 发的一条推文，标题就叫“Prompt”，没加任何解释，没配图，没链接，就两个字。但这条推文在开发者圈子里被反复转发、截图、讨论，甚至有人专门建了文档整理它被引用的上下文。我一开始也纳闷：一个词而已，凭什么？后来翻遍他过去三年的公开分享、技术博客和开源项目文档，才意识到——这根本不是随手一发的标题党，而是一次高度凝练的“认知锚点”式表达。Boris Cherny 是一位深耕前端工程化与开发者工具链十多年的资深工程师，参与过多个被广泛采用的 CLI 工具设计，也长期在一线带团队做代码生成、AI 辅助编程落地。他从不写“Prompt Engineering 入门指南”这类泛泛而谈的内容，所有输出都带着明确的工程约束：必须可集成、可测试、可版本控制、可协作复现。所以当他说“Prompt”，你得立刻反应过来——这不是在聊怎么哄大模型，而是在说：如何把提示词当作一段需要被编译、调试、部署、监控的程序来对待。这个视角转换，直接决定了你后续用 AI 写代码是“临时凑合用”，还是能真正嵌入 CI/CD 流水线、成为团队标准开发动作的一部分。适合正在尝试将 AI 编程能力产品化、流程化、标准化的中高级前端/全栈工程师，也适合那些已经用熟 Copilot 但总觉得“卡在某个临界点上”的技术负责人。如果你还在手动复制粘贴提示词、靠记忆调用不同场景模板、或者每次让模型重写都要重新描述上下文——那这条推文就是给你敲的警钟。

2. 核心思路拆解：为什么“Prompt”二字值得单独成文？

2.1 不是教你怎么写提示词，而是定义它的工程身份

很多人看到“Prompt”第一反应是去搜“10个万能提示词模板”“如何让 GPT 写出专业代码”。但 Boris 的推文恰恰反其道而行之：他不提供模板，而是先划清边界。在他过往的分享中反复强调一个观点：“Prompt 不是自然语言对话，它是人机协议（Human-Machine Protocol）的请求载荷（Request Payload）。” 这句话听着拗口，但实操意义极强。举个最典型的例子：你在 VS Code 里用 Copilot 生成一个 React Hook，输入的是“create a custom hook that fetches data and handles loading/error states”，这看起来是自然语言；但当你把这个需求写进一个自动化脚本，让 AI 在 PR 提交时自动补全测试用例，你就不能再依赖这种模糊描述——你必须明确指定：输入格式（JSON Schema）、输出约束（必须返回 TypeScript 接口定义 + Jest 测试骨架）、错误兜底行为（当 schema 解析失败时返回空数组而非抛错）。这就是“协议”意识：Prompt 必须携带可解析的元信息，而不仅是语义意图。Boris 在某次内部分享中演示过一个对比实验：同样让模型生成“防抖函数”，一组用自由文本提示，另一组用结构化 Prompt 模板（含 language: "typescript", style: "functional", constraints: ["no side effects", "must accept leading/trailing options"]），后者生成结果的 API 一致性达标率从 63% 提升到 98%，且无需人工二次校验类型签名。这个差距不是模型能力问题，而是输入载荷的设计质量差异。

2.2 Prompt 即代码：可版本控制、可 diff、可回滚

另一个常被忽略的关键点是可追溯性。大多数团队现在用 AI 写代码，Prompt 都散落在聊天窗口、笔记软件甚至口头沟通里。但 Boris 坚持把 Prompt 存在代码仓库里，路径通常是/ai/prompts/，文件名遵循feature-name.version.json规范（如>{ "id": "data-fetching-v2", "version": "2.0.1", "schema": { "input": { "type": "object", "properties": { "endpoint": { "type": "string" } } }, "output": { "type": "object", "properties": { "hookName": { "type": "string" } } } }, "payload": "You are a senior TypeScript developer... [完整提示文本]" }

这个结构带来的直接好处是：当某天发现 v2 版本生成的 Hook 在 SSR 场景下报错，你可以直接git checkout v1.5切换回旧版，同时用git diff v1.5 v2.0.1精准定位是哪句约束被修改导致行为漂移（比如 v2 新增了must support React Server Components要求，但模型尚未适配）。我在某次实际项目中就遇到类似问题：团队升级了 LLM 版本后，原有 Prompt 生成的组件测试覆盖率骤降 40%。如果没有版本化管理，我们只能凭记忆猜测哪里出了问题；而有了清晰的 diff，三分钟就定位到是constraints字段里一句 “prefer inline styles over CSS modules” 被误删，导致模型开始生成外部样式文件引用——这根本不是模型问题，而是 Prompt 的契约被破坏了。

2.3 从单点调用到系统集成：Prompt 是服务接口的前置契约

Boris 最核心的洞见在于：Prompt 不是终点，而是新服务的起点。他参与设计的某内部 AI 编程平台，所有用户侧的“智能补全”“自动注释”功能，背后都不是直连大模型 API，而是先经过一个 Prompt Router 服务。这个服务接收用户操作上下文（当前文件语言、光标位置、选中文本、Git 分支名），动态组合预存的 Prompt 模板，注入运行时变量（如{{currentBranch}}），再调用模型。Router 的配置文件长这样：

routes: - id: "test-generation" trigger: "on-save" condition: "file.endsWith('.tsx') && !file.includes('__tests__')" prompt_ref: "react-component-test.v3.json" inject: component_name: "{{filenameWithoutExt}}" export_name: "{{defaultExportName}}"

看到这里你应该明白了：所谓“Prompt”，在这里已演变为一种轻量级的 API 描述语言。它定义了服务的输入契约（什么条件下触发）、输出契约（期望返回什么结构）、以及上下文契约（需要注入哪些变量）。这种设计让团队可以像维护 REST API 文档一样维护 AI 能力——产品经理提需求时不再说“让 AI 帮我们写测试”，而是提交一个 PR 修改routes.yaml，新增一条规则并关联对应版本的 Prompt 文件。整个过程可评审、可测试、可灰度发布。这才是 Boris 用单个单词“Prompt”想传递的真正重量：它不是一个功能按钮，而是一套新的软件工程基础设施的命名空间。

3. 实操细节解析：如何把 Prompt 当作程序来编写与维护

3.1 Prompt 文件的最小可行结构与字段设计逻辑

既然要当代码管，就得有代码的严谨性。Boris 团队沉淀出一套经过生产验证的 Prompt 文件最小结构，所有字段都非可选，且每个字段都有明确的工程目的。我们逐个拆解：

• id: 唯一标识符，用于日志追踪和 A/B 测试。不能用中文或空格，推荐kebab-case。例如api-client-generation。注意：这个 ID 会出现在所有监控埋点中，当某条 Prompt 调用失败率突增，运维可以直接按 ID 查看全链路日志。

• version: 严格遵循语义化版本（SemVer）。主版本号（MAJOR）变更表示输出结构不兼容（如从返回单个对象改为返回数组）；次版本号（MINOR）变更表示新增约束但不破坏旧契约；修订号（PATCH）仅用于修正提示文本中的笔误或歧义。版本号不是摆设——Router 服务会根据prompt_ref中的版本精确加载对应文件，避免“最新版”带来的不可控漂移。

• schema: 这是最容易被忽视却最关键的部分。它用 JSON Schema 描述 Prompt 的输入输出契约。input.schema定义模型需要哪些上下文变量（如{{filePath}},{{gitBranch}}），output.schema定义期望模型返回的 JSON 结构。Boris 强调：没有 output.schema 的 Prompt 就是裸奔。因为后续所有自动化处理（如自动生成类型定义、插入代码块、提取测试用例）都依赖这个 schema 做解析。如果模型返回了不符合 schema 的内容，Router 服务会立即标记为invalid_output并触发 fallback 逻辑（如降级到静态模板），而不是把错误内容直接插入代码。

• payload: 真正的提示文本。但它不是纯文本，而是支持 Mustache 语法的模板字符串。所有变量必须来自schema.input定义的字段，且在 Router 渲染时强制校验。例如payload中写了{{gitBranch}}，但schema.input里没声明gitBranch字段，Router 启动时就会报错拒绝加载。这种设计杜绝了“变量名拼错导致提示失效”的低级错误。

提示：Boris 团队严禁在payload中使用任何未在schema中声明的变量。他们用 ESLint 插件实现了自动化检查——只要payload里出现{{xxx}}，就必须在schema.input.properties中找到对应定义，否则 CI 直接失败。这看似严苛，但换来的是 100% 可预测的提示行为。

3.2 从自由文本到结构化提示：三步重构法

很多工程师第一次接触这种结构化 Prompt 会觉得“太重了”。但 Boris 的经验是：所有高价值 Prompt 都经历过从自由文本到结构化模板的必然演化。他总结出一套可复用的三步重构法，我在三个不同项目中实测有效：

第一步：捕获高频模式（Pattern Capture）
不急着改结构，先做数据采集。在团队 Slack 频道建一个#ai-prompt-log，要求所有成员每次用 AI 生成关键代码时，必须把原始提示词、模型返回结果、是否满意（👍/👎）发到频道。坚持两周，你会得到一份真实的“提示词热力图”。我们当时发现，73% 的高质量生成都集中在四类提示上：组件测试生成、API Client 封装、错误边界处理、国际化文案提取。这些就是你的 MVP 范围。

第二步：抽象变量与约束（Variable Abstraction）
针对每类高频提示，列出所有可能变化的要素。以“组件测试生成”为例，我们提炼出六个必变变量：componentName（组件名）、exportName（导出名）、propsSchema（Props 类型定义）、initialState（初始状态）、userActions（模拟用户操作序列）、expectedResults（预期断言）。然后把这些变量全部塞进schema.input，并为每个变量写明类型和业务含义。这一步完成后，原来的自由文本提示就变成了带占位符的模板：“为 {{componentName}} 组件生成 Jest 测试，覆盖 {{userActions}} 场景，断言 {{expectedResults}}”。

第三步：定义输出契约与容错机制（Output Contracting）
这是区分业余和专业的分水岭。不要满足于“返回测试代码”，要定义：返回内容必须是 JSON 对象；必须包含testCode（字符串）、setupCode（字符串）、assertions（字符串数组）三个字段；testCode必须是合法的 TypeScript 代码片段，不能包含任何 Markdown 语法；当模型无法生成有效断言时，assertions字段必须为空数组而非 null。这些约束全部写进schema.output，Router 服务据此做结构校验。我们在重构前，测试生成失败率是 28%（多为模型返回带解释文字的混合内容）；重构后降到 1.2%，且所有失败都可精准归因到propsSchema解析异常等明确原因。

3.3 版本管理实战：如何避免 Prompt “越改越差”

Prompt 版本管理最大的陷阱不是“不更新”，而是“乱更新”。Boris 团队踩过最深的坑是：某次优化 Prompt 时，为了提升生成速度，删掉了原提示中一句关键约束 “do not use experimental React features”，结果新版本大量生成了useTransition和useOptimistic调用——而团队当前 React 版本根本不支持。这个事故直接导致上线前紧急回滚。从此他们建立了严格的 Prompt 变更 SOP：

1. 所有变更必须关联 Issue：在 Jira 或 GitHub Issues 创建卡片，标题格式为[PROMPT] <id> - <简述变更目的>，例如[PROMPT] api-client-generation - 支持 Axios 1.6+ 的拦截器语法。卡片里必须填写：变更前行为、变更后行为、预期收益、潜在风险、回滚方案。

2. 强制 A/B 测试：Router 服务支持按百分比分流。新版本发布时，先设置 5% 流量走新 Prompt，95% 走旧版。监控指标包括：成功率（返回符合 schema 的 JSON）、平均延迟、人工审核通过率（抽样 100 条结果请资深工程师盲评）。只有当新版本在所有指标上持续 24 小时优于旧版，才逐步提升流量比例。

3. 回滚不是删除，而是冻结：当某版本被弃用，不是从仓库删掉文件，而是在文件头部添加deprecated: true字段，并注明弃用日期和原因。Router 服务会拒绝加载deprecated为true的文件，但保留历史记录供审计。我们至今保留着 v0.1 到 v2.3 的所有 Prompt 文件，它们共同构成了团队 AI 能力演进的“化石记录”。

注意：Boris 特别强调，Prompt 的“好”不是由单次生成效果决定的，而是由长期稳定性、可维护性和协作效率决定的。一个让你单次惊艳但三个月后没人敢改的 Prompt，远不如一个平庸但清晰、可预测、易调试的 Prompt。

4. 核心环节实现：搭建你的第一个可版本化 Prompt 系统

4.1 技术选型：轻量级但不失扩展性的方案

不用追求大而全。Boris 团队的生产环境只用了三个核心组件，总代码量不到 500 行：

• Prompt 存储层：纯静态文件（JSON/YAML），放在 Git 仓库/ai/prompts/下。理由极其务实：Git 天然支持版本、diff、分支、权限控制；所有工程师都熟悉；无需额外运维成本。他们试过数据库存储，结果发现 80% 的查询都是get by id + version，用文件系统反而更快更稳。

• Prompt Router 服务：用 Node.js + Express 编写，核心逻辑只有两个函数：resolvePrompt(id, version)从文件系统加载并校验 Prompt；renderPayload(prompt, context)用mustache库安全渲染模板。整个服务启动时间 < 100ms，内存占用 < 30MB。关键设计是：所有文件读取都带缓存（LRU Cache，最大 1000 个 Prompt），且监听文件系统变更自动刷新缓存——这意味着你git pull更新 Prompt 后，服务无需重启即可生效。

• 客户端集成层：VS Code 扩展。它不直接调用模型，而是向本地运行的 Router 服务发 HTTP 请求。请求体包含：{ "promptRef": "data-fetching.v2.json", "context": { "filePath": "...", "gitBranch": "main" } }。响应体是标准 JSON，结构由schema.output保证。扩展收到后，只做一件事：把testCode字段内容插入编辑器光标位置。这种解耦设计让客户端极度轻量，且 Router 服务可随时替换为其他模型提供商（如从 OpenAI 切到 Anthropic），客户端零修改。

这套方案的优势在于：所有复杂度都集中在 Router 层，而这一层是完全可控、可测试、可监控的。我在某次迁移中，把 Router 服务从 Node.js 重写为 Rust（用 Axum 框架），只花了两天，客户端扩展一行代码没动，用户无感知。如果当初把 Prompt 渲染逻辑写死在 VS Code 扩展里，这种底层替换根本不可能。

4.2 Router 服务核心代码详解

下面是你能直接抄作业的 Router 核心逻辑（已脱敏，保留全部关键设计）：

// router.ts import * as fs from 'fs'; import * as path from 'path'; import * as mustache from 'mustache'; import { LRUCache } from 'lru-cache'; // Prompt 缓存，key 为 `${id}@${version}` const promptCache = new LRUCache<string, Prompt>({ max: 1000 }); interface Prompt { id: string; version: string; schema: { input: Record<string, any>; output: Record<string, any>; }; payload: string; } // 从文件系统加载 Prompt，带完整校验 function loadPromptFromFile(id: string, version: string): Prompt { const filePath = path.join(__dirname, '..', 'prompts', `${id}.v${version}.json`); try { const content = fs.readFileSync(filePath, 'utf8'); const prompt = JSON.parse(content) as Prompt; // 强制校验：id 和 version 必须匹配文件名 if (prompt.id !== id || prompt.version !== version) { throw new Error(`ID/version mismatch in ${filePath}`); } // 强制校验：payload 中所有变量必须在 schema.input 中声明 const variablesInPayload = [...content.matchAll(/{{([^}]+)}}/g)].map(m => m[1].trim()); for (const varName of variablesInPayload) { if (!prompt.schema.input.properties[varName]) { throw new Error(`Undefined variable '${varName}' used in payload of ${filePath}`); } } return prompt; } catch (e) { throw new Error(`Failed to load prompt ${id}@${version}: ${e.message}`); } } // 主渲染函数：安全注入上下文，返回结构化结果 export function renderPrompt( id: string, version: string, context: Record<string, any> ): { success: true; result: any } | { success: false; error: string } { try { // 1. 从缓存或文件加载 Prompt const cacheKey = `${id}@${version}`; let prompt = promptCache.get(cacheKey); if (!prompt) { prompt = loadPromptFromFile(id, version); promptCache.set(cacheKey, prompt); } // 2. 校验 context 是否满足 schema.input const ajv = new Ajv(); const validateInput = ajv.compile(prompt.schema.input); if (!validateInput(context)) { return { success: false, error: `Context validation failed: ${ajv.errorsText(validateInput.errors)}` }; } // 3. 渲染 payload const renderedPayload = mustache.render(prompt.payload, context); // 4. 调用模型 API（此处简化为占位符，实际对接 OpenAI/Anthropic） const modelResponse = callModelAPI(renderedPayload); // 伪代码 // 5. 校验模型输出是否符合 schema.output const validateOutput = ajv.compile(prompt.schema.output); if (!validateOutput(modelResponse)) { return { success: false, error: `Model output validation failed: ${ajv.errorsText(validateOutput.errors)}` }; } return { success: true, result: modelResponse }; } catch (e) { return { success: false, error: e.message }; } }

这段代码体现了 Boris 的核心哲学：用最少的代码，做最确定的事。所有校验（变量存在性、上下文合法性、输出结构）都在 Router 层完成，客户端只负责传参和展示。callModelAPI函数是唯一需要对接外部服务的地方，但它被完全隔离，不影响整体架构。我在实际部署时，把callModelAPI封装成了可插拔的 Adapter，支持 OpenAI、Claude、本地 Ollama 模型，切换只需改一行配置。

4.3 VS Code 扩展集成：零侵入式接入

客户端扩展的核心原则是：绝不碰模型调用，只做协议转换。以下是关键代码片段（TypeScript）：

// extension.ts import * as vscode from 'vscode'; import axios from 'axios'; // 注册命令：当用户按下快捷键时触发 vscode.commands.registerCommand('myai.generateTest', async () => { const editor = vscode.window.activeTextEditor; if (!editor) return; // 1. 构建上下文对象 const context = { filePath: editor.document.fileName, gitBranch: await getGitBranch(), // 自定义函数，获取当前分支 fileName: path.basename(editor.document.fileName), fileContent: editor.document.getText(), cursorPosition: editor.selection.active.line }; try { // 2. 调用本地 Router 服务 const response = await axios.post('http://localhost:3000/render', { promptRef: 'react-component-test.v3.json', context }); if (response.data.success) { // 3. 安全插入结果（只取 testCode 字段） const testCode = response.data.result.testCode; const edit = new vscode.WorkspaceEdit(); const position = new vscode.Position(editor.document.lineCount, 0); edit.insert(editor.document.uri, position, `\n${testCode}\n`); await vscode.workspace.applyEdit(edit); vscode.window.showInformationMessage('Test generated successfully!'); } else { vscode.window.showErrorMessage(`Prompt failed: ${response.data.error}`); } } catch (e) { vscode.window.showErrorMessage(`Router service unreachable: ${e.message}`); } });

这个集成方式的好处是：所有 AI 能力都变成一个 HTTP 接口调用，和调用任何后端服务无异。你可以用 Postman 测试它，可以用 curl 脚本批量验证，可以在 CI 中跑 E2E 测试。更重要的是，当你要升级模型、调整 Prompt、甚至更换整个 AI 栈时，VS Code 扩展永远是那个最稳定的“哑客户端”，它只认 JSON 协议，不关心背后是哪个大模型在干活。

5. 常见问题与排查技巧实录：从真实故障中提炼的避坑指南

5.1 故障现象：模型返回内容格式正确，但插入代码后报语法错误

典型场景：react-component-test.v3.json生成的testCode字段内容，在 VS Code 中插入后，编辑器立刻标红，提示SyntaxError: Unexpected token 'const'。

排查思路：

1. 首先确认testCode字段值是否真的是纯代码字符串。用console.log(JSON.stringify(response.data.result.testCode))打印出来，你会发现开头多了几个不可见字符（如 BOM 或零宽空格）。
2. 进一步检查 Router 服务的callModelAPI返回值，发现模型返回的是 Markdown 格式代码块：typescript\nconst test = ...，而我们的schema.output要求的是纯字符串，没有约定去除 Markdown 包裹。
3. 根本原因：schema.output定义不严谨。我们只写了"type": "string"，但没约束字符串内容格式。

解决方案：

• 在schema.output中为testCode字段增加pattern约束："pattern": "^const\\s+|import\\s+|describe\\s+"（简单匹配常见 JS 关键字开头）。
• 更彻底的方案：在 Router 渲染后、返回前，增加一道清洗步骤：result.testCode = result.testCode.replace(/```(?:typescript)?\n([\s\S]*?)\n```/g, '$1').trim();。这个正则专门剥离 Markdown 代码块包裹。

实操心得：Boris 团队规定，所有schema.output字段，如果值是代码字符串，必须配套pattern或format约束。他们甚至写了个 ESLint 规则，扫描所有 Prompt 文件，对type: "string"且字段名含code/snippet的字段，强制要求存在pattern。

5.2 故障现象：A/B 测试显示新 Prompt 成功率更高，但工程师反馈“生成质量下降”

典型场景：v4 版本 Prompt 在自动化测试中成功率 99.2%，v3 是 98.5%，但三位资深工程师在盲测中给 v4 的平均分只有 2.3/5，认为它生成的代码“过度工程化，引入了不必要的抽象”。

排查思路：

1. 不是技术问题，是评估维度错位。自动化测试只校验schema.output结构，但工程师评价的是代码的可读性、可维护性、是否符合团队规范。
2. 检查 v4 Prompt 的payload，发现新增了一句约束：“prefer composition over inheritance, use higher-order components where applicable”。这句话本身没错，但团队当前代码库中 90% 的组件都是函数组件，根本没有继承场景，模型为了满足“composition”要求，强行把简单逻辑包装成 HOC，反而增加了理解成本。

解决方案：

• 立即回滚 v4，但不是简单删掉文件，而是在deprecated: true字段中注明原因：“violates team's functional-component-first principle”。
• 建立“人类评估指标”：每周随机抽取 20 条生成结果，由三位工程师盲评（不告知版本号），评分维度包括：可读性、简洁性、可维护性、与现有代码风格一致性。只有当人类评分均值 ≥ 4.0 且自动化成功率 ≥ 98% 时，新版本才允许发布。
• 在payload中加入风格约束：“generate code that matches the style of the current file: if the file uses hooks, use hooks; if it uses class components, use class components”。

5.3 故障现象：Router 服务 CPU 使用率飙升，响应延迟超 5s

典型场景：某天下午，Router 服务监控告警，CPU 持续 95% 以上，所有请求超时。重启服务后暂时恢复，但几小时后又复发。

排查思路：

1. 查看日志，发现大量Failed to load prompt错误，错误信息是Cannot find module 'ajv'。
2. 进入服务器，执行npm list ajv，发现版本是8.12.0，但package-lock.json中锁的是8.11.0。原来是有同事在服务器上手动执行了npm install ajv@latest，导致版本不一致。
3. AJV v8.12.0 有一个已知 bug：当compile一个非常复杂的 schema（如包含深层嵌套oneOf的 Props Schema）时，会进入无限循环，吃光 CPU。

解决方案：

• 立即回滚 AJV 版本：npm install ajv@8.11.0 --no-save（--no-save避免污染package.json）。
• 在 CI 流程中加入强制校验：npm ci后执行npm list ajv --depth=0，确保版本与package-lock.json严格一致。
• 对所有schema字段增加大小限制：Router 启动时扫描所有 Prompt 文件，拒绝加载schema.input或schema.output字节数 > 10KB 的文件（超过此大小的 Schema 几乎肯定是设计失误）。

注意：这个故障暴露了一个关键原则——Prompt 系统的稳定性，极度依赖其依赖项的确定性。Boris 团队现在所有生产环境都用npm ci（而非npm install）部署，且package-lock.json严格纳入 Git 管理，任何依赖变更都必须走 Code Review。

5.4 故障现象：不同分支的 Prompt 行为不一致，导致 PR 检查结果混乱

典型场景：main分支上api-client-generation.v2.json生成的客户端代码正常；但在feature/auth分支上，同样的 Prompt 调用却返回空对象{}。

排查思路：

1. 检查feature/auth分支的/ai/prompts/目录，发现该分支没有api-client-generation.v2.json文件，只有一个api-client-generation.v1.json。
2. 原来是feature/auth分支是从develop切出来的，而develop分支的 Prompt 文件还没合入main，feature/auth继承了旧版文件。
3. Router 服务默认行为是：当请求v2但文件不存在时，返回 404；但客户端扩展没处理 404，直接用了空响应。

解决方案：

• Router 服务增加“版本降级”策略：当请求v2但文件不存在时，自动查找v1，如果存在则加载并返回X-Prompt-Version: v1 (fallback)响应头，提醒客户端。
• 客户端扩展必须处理X-Prompt-Version响应头，当检测到fallback时，弹窗提示用户：“当前分支 Prompt 版本较旧，建议切换到 main 分支或联系管理员同步 Prompt”。
• 在 Git Hooks 中加入 pre-commit 检查：如果修改了.tsx文件，但/ai/prompts/下没有对应的新版 Prompt 文件，则阻止提交，并提示：“Please update or reference existing prompt for this change”。

这张表总结了我们遇到的最典型故障及应对策略：

6. 实战延伸：如何将这套方法论迁移到其他领域

6.1 从编程到设计：Figma 插件中的 Prompt 管理

这套“Prompt 即代码”的思路，绝不仅限于写代码。我在帮某设计团队落地 AI 设计助手时，直接复用了 Boris 的整套模式。他们用 Figma 插件生成设计系统组件，Prompt 文件结构几乎一模一样：

{ "id": "button-component", "version": "1.2.0", "schema": { "input": { "type": "object", "properties": { "variant": { "type": "string", "enum": ["primary", "secondary", "outline"] }, "size": { "type": "string", "enum": ["sm", "md", "lg"] } } }, "output": { "type": "object", "properties": { "figmaJson": { "type": "string" }, // Figma 节点 JSON "tokens": { "type": "object" } // 设计 Token 定义 } } }, "payload": "Generate Figma JSON for a {{variant}} button in {{size}} size..." }

Router 服务也做了适配：callModelAPI不再调用 OpenAI，而是调用他们自研的视觉模型 API；renderPayload后的清洗步骤，是用figma-json-validator库校验返回的 JSON 是否符合 Figma 节点规范。最大的收获是：设计师现在可以像工程师一样，给 Prompt 提 Issue、写测试用例、做 A/B 测试。他们甚至用git diff对比两个 Button Prompt 版本生成的 Token 输出，直观看到 v1.2 如何修复了 v1.1 中阴影参数单位不一致的问题。

6.2 从技术到业务：销售话术生成系统的 Prompt 工程化

更意外的是，这套方法论在业务侧也爆发出惊人威力。某 SaaS 公司的销售团队，用 AI 生成客户定制化方案书。以前是销售在 ChatGPT 里手动输入：“帮我写一封给电商客户的方案书，突出我们的库存预测模块”。结果千篇一律，缺乏针对性。引入结构化 Prompt 后，他们的sales-proposal.v3.json长这样：

{ "id": "sales-proposal", "version": "3.0.1", "schema": { "input": { "type": "object", "properties": { "customerIndustry": { "type": "string" }, "customerSize": { "type": "string", "enum": ["SMB", "Mid-market", "Enterprise"] }, "painPoints": { "type": "array", "items": { "type": "string" } } } }, "output": { "type": "object", "properties": { "subjectLine": { "type": "string" }, "body": { "type": "string" }, "nextSteps": { "type": "array", "items": { "type": "string" } } } } }, "payload": "You are a sales engineer at [Company]... Write an email proposal for {{customerIndustry}} customers with {{customerSize}} size, addressing pain points: {{#painPoints}}{{.}}{{/painPoints}}" }

CRM 系统集成后，销售在客户详情页点击“生成方案”，系统自动填充customerIndustry（从客户标签获取）、customerSize（从公司员工数映射）、painPoints（从上次通话记录 NLP 提取）。生成的邮件不仅个性化，而且所有字段都可被 CRM 记录、分析、优化。他们现在每月分析nextSteps数组的生成频率，发现“安排产品