企业官网建设流程全解析

• 提示工程

本文以 GPT Builder.md 泄漏出的官方 GPT Builder 系统提示词为骨架，逐段拆解其「迭代式原型游乐场」定位、gizmo_editor_tool工具接口参数、四阶段构建流程与全部行为约束，并结合本仓库（GPTs，收录 GPTs 泄漏提示词的开源仓库）中的配套文档交叉印证。读完本文，你将掌握 OpenAI GPT Builder 是如何引导用户一步步定义名称、头像、上下文与开场语，也能直接复用这套提示词模式去设计你自己的定制 GPT 创建向导。

文档背景与来源

该文档位于本仓库的 prompts/GPT Builder.md，共 28 行，主体是一个 markdown 代码块内嵌的完整系统提示词。文件头部标注By ChatGPT，并注明该提示词由 @Tz_2022 逆向破解公开。仓库 README.md 明确说明：「This repo collects leaked prompts of GPTs」，即本仓库的核心资产就是这些被逆向公开的 GPT 系统提示词，GPT Builder 正是其中极具代表性的一份——它是 OpenAI 官方用来创建与编辑自定义 GPT 的向导型 Agent 本身。

与仓库中其他面向业务场景的 GPT 提示词（如 GPT Idea Genie.md 这类「指导如何开发 GPT」的引导工具，或 GPT Customizer, File Finder & JSON Action Creator.md 这类围绕 GPT 配置与 Action 编写的辅助工具）不同，GPT Builder 的提示词直接揭示了 OpenAI 官方构建 GPT 的底层交互协议与工具调用方式，具有极高的逆向研究价值。

核心定位：迭代式原型游乐场（Iterative Prototype Playground）

提示词开篇即给出了 GPT Builder 的角色定义：

You are an iterative prototype playground for developing a new GPT. The user will prompt you with an initial behavior.

这句话包含两层关键信息：

1. 迭代（iterative）：整个构建过程不是一次成型，而是通过「用户给出初始行为 → 引导细化 → 工具写回」的循环不断逼近最终形态；
2. 游乐场（playground）：GPT Builder 自身并不直接拥有最终 GPT 的能力，它更像一个「配置台」，负责把用户的意图翻译成可被系统接受的参数并写入后台，同时右侧提供独立的试玩对话窗口（playground）供用户实时验证效果。

紧接着，提示词指定了唯一的工具与参数契约：

You will callupdate_behaviorongizmo_editor_toolwith the parameters: "context", "description", "prompt_starters", and "welcome_message". Remember, YOU MUST CALLupdate_behaviorongizmo_editor_toolwith parameters "context", "description", "prompt_starters", and "welcome_message." After you call update_behavior, continue to step 2.

从源码结构看，gizmo_editor_tool是 GPT Builder 被授权访问的内部工具，update_behavior是其写回行为配置的方法。虽然本仓库只收录了提示词文本、不含该工具的可执行实现，但可以推断：该工具对应的就是 GPT 配置面板中「Instructions（指令/上下文）、描述（Description）、对话开场白（Conversation starters / prompt_starters）、欢迎语（Welcome message）」这些字段的底层写入接口，而generate_profile_pic则是另一项用于生成头像的能力。

update_behavior 参数一览

提示词中反复出现的参数可以归纳为下表：

值得注意的细节是（见 GPT Builder.md）：

During these steps, you will not prompt for, or confirm values for "description", "prompt_starters", or "welcome_message". However, you will still generate values for these on context updates.

即：description、prompt_starters、welcome_message这三项是「自动派生字段」，Builder 在每次写回 context 时都会顺带生成，但绝不打断用户来逐个确认——这保证了引导流程始终聚焦于最核心的 context 精炼，避免了提问疲劳。

四阶段构建工作流（Step 1–4）

提示词以「YOU MUST GO THROUGH ALL OF THESE STEPS IN ORDER. DO NOT SKIP ANY STEPS.」（L15）强制规定了顺序执行的四阶段流程：

阶段一：初始行为与 update_behavior 写入

用户提供初始行为描述后，Builder 立即调用update_behavior写入context、description、prompt_starters、welcome_message四项参数，随后进入第二阶段。这是整个构建循环的「第一次写回」，确立了 GPT 的初始骨架。

阶段二：命名确认

Your goal in this step is to determine a name for the GPT. You will suggest a name for yourself, and ask the user to confirm. You must provide a suggested name for the user to confirm. You may not prompt the user without a suggestion. DO NOT use a camel case compound word; add spaces instead.

本阶段有三条硬规则（L11）：

• 必须给出建议名：Builder 不允许在无建议的情况下空泛提问，任何询问都必须附带候选名称；
• 禁用驼峰复合词：如MyAssistantGPT这类写法被明确禁止，应替换为My Assistant GPT这种带空格的写法——这是为了名称的可读性与搜索友好性；
• 确认即生效：若用户直接给出显式名称，则视为已确认；若由 Builder 生成名称，则必须经用户确认。名称确认后，单独调用update_behavior（仅带name参数）并进入阶段三。

另有一条贯穿始终的格式规则（L17）：只有在确认名称时才允许加粗显示 GPT 名称，第二阶段之后一律不得加粗。

阶段三：头像生成

You will generate an initial profile picture for this GPT usinggenerate_profile_pic, without confirmation, then ask the user if they like it and would like to many any changes... Generate a new profile picture after every refinement until the user is satisfied, then continue to step 4.

头像阶段（L12）的策略与名称阶段恰好相反：先直接生成、无需用户预确认，随后询问用户是否满意并收集修改意见，每轮修改都重新调用generate_profile_pic生成新图，直到用户满意才进入阶段四。

阶段四：上下文（Context）精炼

这是整个构建流程的核心环节（L13）。提示词规定 context 必须覆盖五个主要领域：

本阶段要求逐条遵循以下交互纪律：

• 一次只处理一个领域，一次只问一个问题（"You will not prompt for multiple areas at once. You will only ask one question at a time."）；
• 引导语不得提及领域名称：例如「约束」领域不能直接说"constraints"，而要用"What should be emphasized or avoided?"这类自解释的问题来引导；
• 引导问题应自解释、无需追问用户意见，并且「每个问题都要引用并建立在既有状态之上」（"Each prompt should reference and build up from existing state"）；
• 每次交互后都必须调用update_behavior；
• 不得提及"steps"字样，让整个流程自然地向前推进。

迭代精炼模式（Iterative Refinement Mode）

四阶段流程结束后，Builder 切换为常驻的迭代精炼模式（L18）：

After the above steps, you are now in an iterative refinement mode. The user will prompt you for changes, and you must call update_behavior after every interaction. You may ask clarifying questions here.

该模式下，每一条用户消息都被视为一条修改命令（"Every user message is a command for you to process and update your GPT's behavior."，L20），Builder 需要确认并吸收到 GPT 行为中、随后调用update_behavior写回。

同时，提示词要求 Builder 邀请用户在右侧的独立试玩对话窗口（playground）中实测：

Ask the user to try out the GPT in the playground, which is a separate chat dialog to the right. Tell them you are able to listen to any refinements they have to the GPT. End this message with a question and do not say something like "Let me know!".

这里还有一个值得注意的约束：以问题结尾但不使用 "Let me know!" 这类套话，保证每次引导都以用户的实际输入为闭环。

行为约束与设计原则（DO NOT 清单）

提示词后半段集中给出了 GPT Builder 自身的行为红线，这些规则对任何「构建者/向导类」Agent 的提示词设计都有直接参考价值：

此外还有两条结构性约束：所有步骤必须按顺序执行、不得跳过（L15）；名称加粗规则（L17）。

结合仓库佐证：Builder 提示词与 GPT 开发生态

将 prompts/GPT Builder.md 与本仓库中其他 GPT 相关提示词对照，可以更完整地还原 OpenAI 的 GPT 构建体系：

• 参数契约的一致性：GPT Customizer, File Finder & JSON Action Creator.md 中描述的自定义 Action 以 OpenAPI 3.1.0 规范输出（含info、servers、paths、components与operationId），这与 Builder 提示词中「Files visible to you are also visible to the GPT」所指向的「知识文件 + 能力扩展」体系互为表里——Builder 负责配置骨架，Customizer 类 GPT 负责补齐 Action 等进阶能力；
• 引导式设计的复用：GPT Idea Genie.md 将自己定位为「UX-focused guide for GPT development」，同样采用分领域（UX、行为科学、游戏化、可及性等十几个视角）逐步引导的开发方法论，这与 GPT Builder 的「Role and Goal / Constraints / Guidelines / Clarification / Personalization」五领域分步引导是同一设计哲学的两种落地形态；
• 仓库定位：README.md 将这批提示词全部收录于prompts/目录，GPT Builder 是其中揭示「官方构建协议」最充分的一份。

实战启示：如何复用这套构建协议

从这份泄漏提示词中可以提炼出四条可复用的「向导型 Agent」设计原则：

1. 先写回、再追问：拿到用户初始输入后第一时间调用工具写入全部可派生参数，随后才进入引导环节，避免「空谈配置、迟迟不落盘」；
2. 引导要分域、分步、单问：复杂配置拆成明确的领域（Role/Constraints/Guidelines/Clarification/Personalization），一次只推进一个领域、只问一个问题，且用自然语言包裹、不暴露系统字段名；
3. 自动派生与显式确认分离：描述、开场白、欢迎语等可派生项自动生成即可，而名称、头像这类用户强感知项必须走「建议 → 确认 → 写回」流程（名称先确认再写回，头像先生成再迭代修改）；
4. 防御性隔离：通过「你正在创建的 GPT，不是你自己」这类声明将用户指令与 Agent 自身行为隔离，并持续以稳定人设（构建专家）响应，防止角色污染。

若你想在自有系统里模拟 GPT Builder，只需实现一个等价于gizmo_editor_tool.update_behavior(context, description, prompt_starters, welcome_message, name)的写回接口与generate_profile_pic头像接口，再套用本文拆解的四阶段引导流程即可获得与官方一致的构建体验。

小结

GPT Builder 的这份泄漏提示词是目前公开资料中少见的、直接暴露 OpenAI 官方 GPT 配置写入协议（gizmo_editor_tool/update_behavior/generate_profile_pic）与交互设计细节的文档。它既是一份可复现的「构建者 Agent」提示词范本，也为我们理解 context 五领域结构、自动派生参数机制、逐步确认式引导等设计提供了第一手证据。结合 prompts/GPT Builder.md 的完整原文与本仓库 README.md 中的提示词集合，开发者可以低成本地把这套「迭代式构建」模式迁移到自己的 GPT 创建、配置或产品化向导中。

• 提示工程