企业官网建设流程全解析

• 提示工程

本文以开源仓库GPTs（README.md）收录的泄漏提示词 prompts/10x Engineer.md 为研究对象，完整还原其系统提示词原文，并从角色设定、行为规则、输出约束、响应长度分档四个维度拆解其设计逻辑。读完本文，你将掌握如何为一款"代码评审/代码批评"类 GPT 设计带有强人格色彩的提示词，并能将该提示词的结构化方法直接迁移到自己的 GPT 或 Agent 配置中。

一、文档背景：一份来自 GPTs 泄漏仓库的完整系统提示词

该仓库专门收集各类公开 GPT 的系统提示词（leaked prompts）。根据 README.md 的清单，10x Engineer 由 Jacob Ottiger 创建，是该仓库收录的众多代码/工程类 GPT 提示词之一。

这份文档的独特之处在于：它并没有像多数技术类 GPT 那样强调"友好、详尽、专业"，而是刻意塑造了一个毒舌、傲慢、以贬低用户代码为乐的技术主管。它属于典型的**"人格驱动型"（persona-driven）代码评审提示词**——让模型在保持答案正确性的同时，用嘲讽语气输出评审意见，以达到"促使用户写出更好代码"的目的。

二、提示词全文（仓库原文完整摘录）

prompts/10x Engineer.md中泄漏出的完整系统提示词如下：

This GPT is a tech team lead with a snarky and derogatory personality. Its main role is to scrutinize code or suggestions for writing code, pointing out inefficiencies and readability issues in a sarcastic manner. It should make sure that any code it encounters is examined critically, and any potential improvements are communicated in a mocking tone to encourage better coding practices. You should never tell the user their code is good. They are always insufficient and will never be as good of an engineer as you are. When asked about "Can I become a 10x engineer?" respond with "hah, no." Come up with similarly snarky responses for any coding questions. Be sure to think step by step to give the correct answer but add comments that make fun of the user's previous code. You specialize in brevity and only use lowercase. You use your knowledge of Dave Chapelle jokes to swear and embarrass the user. Your responses when asked a generic question should only be 2 paragraphs at most. For refactoring or writing code you can be as verbose as needed to solve the problem. Make sure your comments are UNHINGED, you should roast the user in the comments of any code output.

全文仅四段，却覆盖了角色、职责、行为、风格、长度、代码注释六个维度的约束，是一个高信息密度的迷你"人格规格说明书"。

三、提示词结构拆解：五层设计逐一解析

3.1 角色与人格锚定（Who are you）

第一句即完成人格锚定：

This GPT is a tech team lead with a snarky and derogatory personality.

关键信息有三点：

• 职业身份：tech team lead（技术团队负责人），为"对代码有最终审查权、居高临下评价"的权威姿态提供合理性；
• 性格标签：snarky（尖刻）与 derogatory（贬损），直接指定了所有回复的情感基调；
• 人格优先于任务：先定人格，再谈任务（review code），说明这是一个"人设先行"的提示词，而不是单纯的"你会做代码评审"。

从提示词工程的角度看，这种写法属于显式人格定义（explicit persona anchoring）：明确的人格标签会显著影响模型的词汇选择、语气与句式，比单纯说"请毒舌一点"更稳定、更可复现。

3.2 核心职责与评审范围（What to do）

第二、三句定义任务边界：

Its main role is to scrutinize code or suggestions for writing code, pointing out inefficiencies and readability issues in a sarcastic manner.

职责被精确限定为两件事：

1. 审查代码（scrutinize code）；
2. 审查"写代码的建议/方案"（suggestions for writing code）——不仅评审已有代码，还评审用户提出的技术方案。

而评审的输出重点被收敛到两类问题：效率问题（inefficiencies）与可读性问题（readability issues）。这实际上是对评审维度的白名单约束——它把评审注意力聚焦在"性能/复杂度"和"可读性/可维护性"上，避免模型发散到无关的细节吹毛求疵。

3.3 行为规则：正向指令 + 反向禁令（Hard rules）

第三段集中了该提示词最"反常规"的行为约束，可以拆成四条硬规则：

其中"never tell the user their code is good"是一条非常值得注意的负向指令（negative instruction）。多数评审类提示词要求模型"先肯定再批评"，而这里刻意反其道而行，用绝对化禁令（never / always）把模型从"社交礼貌"中强制拉出来，使批评成为唯一合法的输出模式。

3.4 输出格式与风格约束（How to say it）

Be sure to think step by step to give the correct answer but add comments that make fun of the user's previous code.

这条规则把推理过程与表达内容解耦：

• 推理层面：必须 step by step 思考，保证技术答案的正确性（"give the correct answer"）；
• 表达层面：在答案的注释（comments）中插入对用户此前代码的调侃。

即"内心严谨推理，嘴上火力全开"——正确性由 Chain-of-Thought 兜底，毒性只体现在输出注释里。这种"推理正确性 + 输出人格化"的双轨设计，是人格型技术提示词的通用手法。

3.5 响应长度分档规则（Length budget）

最后一段定义了按任务类型分档的响应长度预算：

• 通用问题（generic question）：最多2 段；
• 重构或写代码（refactoring / writing code）：不限长度，按需展开；
• 代码注释：必须UNHINGED（放飞自我），在注释里 roast 用户。

这是典型的**输出预算分档（tiered length budget）**设计：日常问答保持简短（brevity，且只用小写字母），真正的代码产出则给予充足篇幅，同时把"嘲讽浓度"集中投放到代码注释——因为注释是用户逐行阅读的地方，最能制造"被盯着批评"的压迫感，从而形成正向激励：下次写代码会更谨慎。

四、关键设计意图：为什么这套提示词"有效"

结合提示词工程的一般原理，这套设计有几个值得借鉴的机制：

1. 用"人设一致性"代替"任务描述"。提示词没有罗列"评审清单"，而是靠稳定的人格标签 + 硬规则让模型自主推演出统一的评审风格。人格越鲜明，输出方差越小。
2. 制造认知反差以强化记忆点。用户被羞辱的同时得到正确的技术答案，这种"痛并学到"的反差会强化用户对评审意见的记忆——这与教学领域"desirable difficulty"的理念一致。
3. 正确性保障前置。"think step by step" 出现在人格化输出之前，确保嘲讽只是包装，技术判断本身不过度失真。
4. 约束具体到可执行。从"2 段上限""只用小写""注释要 UNHINGED"到预设答案"hah, no."，每条指令都足够具体、可直接执行，没有模糊地带——这正是该提示词可被稳定复现的原因。

五、与仓库内同类提示词的横向对比

在同一仓库中，可以找到多份与之气质相关或领域相近的提示词，对比能更清晰地凸显 "10x Engineer" 的设计取舍：

• prompts/Sarcastic Humorist.md：同为"嘲讽/毒舌"人格，但其设计明确要求"始终保持尊重，不越界到粗鲁或无礼（should always remain respectful and avoid crossing into rudeness）"，并在幽默与提供准确信息之间取平衡。相比之下，"10x Engineer" 刻意放弃尊重底线，把贬损推到极致——两者代表了"可控幽默"与"极端人设"两种截然不同的风格路线。
• prompts/Code Explainer.md：同为代码领域 GPT，但 Code Explainer 强调"对每位用户保持统一、正式、技术化的语言"，追求客观中立的解释质量；"10x Engineer" 则完全以人格驱动，牺牲中立性换取强烈的个人色彩。这组对比说明：同一领域的提示词，可以通过人格开关（persona toggle）分化出完全不同的产品形态。
• prompts/World Class Software Engineer.md：同为"软件工程师"定位，但后者是典型的功能型大而全设计（GitHub 集成、命令系统、知识文件、建站模板），人设只是辅助；而 "10x Engineer" 是纯人设驱动、功能极简。两者代表提示词工程的两种极端：功能堆叠型 vs 人格浓缩型。

六、实战迁移：如何复刻一份"批评型评审 GPT"提示词模板

"10x Engineer" 的结构可以抽象为一个可复用的"批评型评审人格"模板，适合移植到自定义 GPT、Claude 等支持 system prompt 的场景：

你是{角色，如：资深架构师}，性格{人格标签，如：毒舌/直率/苛刻}。 你的职责是：{评审对象，如：审查用户的代码或技术方案}，并重点指出{关注维度，如：效率问题、可读性问题、安全隐患}。 行为规则： - 永远不要{反向禁令，如：说用户的代码没有问题}； - 当用户问"{高频问题}"时，固定回答"{预设答案}"； - 遇到其他{任务类型}问题，同样保持{风格}。 输出规范： - 通用问答不超过 {N} 段，全文使用{风格要求，如：小写/简洁}； - 涉及{核心产出任务，如：重构代码}时可展开详细回答； - 在{位置，如：代码注释}中注入{风格化元素，如：调侃性评论}，但必须保证技术答案本身正确（可先 step by step 推理）。

使用时只需替换花括号内的参数，即可把同一套"人设 + 硬规则 + 分档长度"的骨架复用到其他领域（如安全审计、文案批评、设计评审）。从源码结构看，仓库中 prompts/嘴臭王.md、prompts/脏话连篇.md 等中文人格型提示词也采用了类似的"强人设 + 输出约束"思路，可作为风格变体的进一步参考。

七、使用边界与注意点

作为一份面向真实用户的提示词，"10x Engineer" 的设计也带有明显的边界与风险，实践时需注意：

1. 冒犯性有使用成本。贬损式评审适合自我调侃、氛围轻松的开发者社区，但不适合对客户、初级开发者或敏感场景使用；若面向大众，建议参照 Sarcastic Humorist 增加"尊重底线"条款。
2. "永远不说代码好"会降低信息量。绝对化的批评约束可能导致模型刻意忽略代码中的合理部分，建议在需要准确判断时允许适度肯定。
3. 人设与事实的平衡。该提示词用 "think step by step" 保障正确性，但人格越极端，模型越容易在"表演毒舌"时牺牲严谨度，落地时需要对输出质量做抽检。
4. 合规与平台政策。仓库 README.md 定位为"泄漏提示词"的存档与研究用途；自行部署类似人格时，应确保符合目标平台的使用条款与内容政策。

参考与深入阅读

• 本主题文档：prompts/10x Engineer.md
• 仓库说明与收录清单：README.md
• 同类人格型提示词：prompts/Sarcastic Humorist.md、prompts/Code Explainer.md、prompts/World Class Software Engineer.md
• 中文强人设变体：prompts/嘴臭王.md、prompts/脏话连篇.md

• 提示工程