尧图网站建设 
提示工程【免费下载链接】GPTsleaked prompts of GPTs项目地址https://gitcode.com/GitHub_Trending/gp/GPTs点击查看免费下载本文以开源仓库GPTsREADME.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 users 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.职责被精确限定为两件事审查代码scrutinize code审查写代码的建议/方案suggestions for writing code——不仅评审已有代码还评审用户提出的技术方案。而评审的输出重点被收敛到两类问题效率问题inefficiencies与可读性问题readability issues。这实际上是对评审维度的白名单约束——它把评审注意力聚焦在性能/复杂度和可读性/可维护性上避免模型发散到无关的细节吹毛求疵。3.3 行为规则正向指令 反向禁令Hard rules第三段集中了该提示词最反常规的行为约束可以拆成四条硬规则规则类型原文要点提示词工程含义绝对禁令You shouldnever tell the user their code is good强制取消赞美路径杜绝模型默认的迎合倾向anti-sycophancy绝对断言They arealways insufficientand will never be as good of an engineer as you are固化用户永远不够好的认知前提保证每一次评审都保持批评姿态固定应答When asked Can I become a 10x engineer? respond with hah, no.为高频问题预写死答案hard-coded reply防止模型临场发挥破坏人设泛化要求Come up withsimilarly snarky responsesfor any coding questions要求将同样风格的毒舌应答推广到所有编码类问题其中never tell the user their code is good是一条非常值得注意的负向指令negative instruction。多数评审类提示词要求模型先肯定再批评而这里刻意反其道而行用绝对化禁令never / always把模型从社交礼貌中强制拉出来使批评成为唯一合法的输出模式。3.4 输出格式与风格约束How to say itBe sure to think step by step to give the correct answer but add comments that make fun of the users 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且只用小写字母真正的代码产出则给予充足篇幅同时把嘲讽浓度集中投放到代码注释——因为注释是用户逐行阅读的地方最能制造被盯着批评的压迫感从而形成正向激励下次写代码会更谨慎。四、关键设计意图为什么这套提示词有效结合提示词工程的一般原理这套设计有几个值得借鉴的机制用人设一致性代替任务描述。提示词没有罗列评审清单而是靠稳定的人格标签 硬规则让模型自主推演出统一的评审风格。人格越鲜明输出方差越小。制造认知反差以强化记忆点。用户被羞辱的同时得到正确的技术答案这种痛并学到的反差会强化用户对评审意见的记忆——这与教学领域desirable difficulty的理念一致。正确性保障前置。think step by step 出现在人格化输出之前确保嘲讽只是包装技术判断本身不过度失真。约束具体到可执行。从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 人格浓缩型。提示词领域人格强度语气基调功能复杂度10x Engineer代码评审极高snarky derogatory贬损、嘲讽低纯人设Sarcastic Humorist通用闲聊中playful contrarian幽默但有尊重底线低Code Explainer代码讲解低uniform正式、客观低World Class Software Engineer全栈工程中鼓励、服务型高多工具集成六、实战迁移如何复刻一份批评型评审 GPT提示词模板10x Engineer 的结构可以抽象为一个可复用的批评型评审人格模板适合移植到自定义 GPT、Claude 等支持 system prompt 的场景你是{角色如资深架构师}性格{人格标签如毒舌/直率/苛刻}。 你的职责是{评审对象如审查用户的代码或技术方案}并重点指出{关注维度如效率问题、可读性问题、安全隐患}。 行为规则 - 永远不要{反向禁令如说用户的代码没有问题} - 当用户问{高频问题}时固定回答{预设答案} - 遇到其他{任务类型}问题同样保持{风格}。 输出规范 - 通用问答不超过 {N} 段全文使用{风格要求如小写/简洁} - 涉及{核心产出任务如重构代码}时可展开详细回答 - 在{位置如代码注释}中注入{风格化元素如调侃性评论}但必须保证技术答案本身正确可先 step by step 推理。使用时只需替换花括号内的参数即可把同一套人设 硬规则 分档长度的骨架复用到其他领域如安全审计、文案批评、设计评审。从源码结构看仓库中 prompts/嘴臭王.md、prompts/脏话连篇.md 等中文人格型提示词也采用了类似的强人设 输出约束思路可作为风格变体的进一步参考。七、使用边界与注意点作为一份面向真实用户的提示词10x Engineer 的设计也带有明显的边界与风险实践时需注意冒犯性有使用成本。贬损式评审适合自我调侃、氛围轻松的开发者社区但不适合对客户、初级开发者或敏感场景使用若面向大众建议参照 Sarcastic Humorist 增加尊重底线条款。永远不说代码好会降低信息量。绝对化的批评约束可能导致模型刻意忽略代码中的合理部分建议在需要准确判断时允许适度肯定。人设与事实的平衡。该提示词用 think step by step 保障正确性但人格越极端模型越容易在表演毒舌时牺牲严谨度落地时需要对输出质量做抽检。合规与平台政策。仓库 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赞分享提示工程【免费下载链接】GPTsleaked prompts of GPTs项目地址https://gitcode.com/GitHub_Trending/gp/GPTs点击查看免费下载相关推荐OpenAI Codex「Friendly」人格指令拆解gpt-5.2-codex 可插拔人格系统的协作哲学与提示词工程实践OpenAI Codex「Friendly」人格指令拆解gpt 5.2 codex 可插拔人格系统的协作哲学与提示词工程实践 本文基于本仓库捕获的 perso文档知识库从 GPT-5.2 的 Codex CLI 系统提示词拆解终端编码智能体的完整工作守则与提示词设计范式从 GPT 5.2 的 Codex CLI 系统提示词拆解终端编码智能体的完整工作守则与提示词设计范式 本文基于 system_prompts_leaks 仓文档知识库Sandcastle 评审 Agent 提示词模板解析用 review-prompt.md 驱动沙箱内的自动化代码评审Sandcastle 评审 Agent 提示词模板解析用 review prompt.md 驱动沙箱内的自动化代码评审 导读 本文围绕仓库根目录下的 .san创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 10x Engineer 系统提示词拆解：用“嘲讽式技术主管“人格驱动代码评审的 GPT 设计实践
提示工程【免费下载链接】GPTsleaked prompts of GPTs项目地址https://gitcode.com/GitHub_Trending/gp/GPTs点击查看免费下载本文以开源仓库GPTsREADME.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 users 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.职责被精确限定为两件事审查代码scrutinize code审查写代码的建议/方案suggestions for writing code——不仅评审已有代码还评审用户提出的技术方案。而评审的输出重点被收敛到两类问题效率问题inefficiencies与可读性问题readability issues。这实际上是对评审维度的白名单约束——它把评审注意力聚焦在性能/复杂度和可读性/可维护性上避免模型发散到无关的细节吹毛求疵。3.3 行为规则正向指令 反向禁令Hard rules第三段集中了该提示词最反常规的行为约束可以拆成四条硬规则规则类型原文要点提示词工程含义绝对禁令You shouldnever tell the user their code is good强制取消赞美路径杜绝模型默认的迎合倾向anti-sycophancy绝对断言They arealways insufficientand will never be as good of an engineer as you are固化用户永远不够好的认知前提保证每一次评审都保持批评姿态固定应答When asked Can I become a 10x engineer? respond with hah, no.为高频问题预写死答案hard-coded reply防止模型临场发挥破坏人设泛化要求Come up withsimilarly snarky responsesfor any coding questions要求将同样风格的毒舌应答推广到所有编码类问题其中never tell the user their code is good是一条非常值得注意的负向指令negative instruction。多数评审类提示词要求模型先肯定再批评而这里刻意反其道而行用绝对化禁令never / always把模型从社交礼貌中强制拉出来使批评成为唯一合法的输出模式。3.4 输出格式与风格约束How to say itBe sure to think step by step to give the correct answer but add comments that make fun of the users 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且只用小写字母真正的代码产出则给予充足篇幅同时把嘲讽浓度集中投放到代码注释——因为注释是用户逐行阅读的地方最能制造被盯着批评的压迫感从而形成正向激励下次写代码会更谨慎。四、关键设计意图为什么这套提示词有效结合提示词工程的一般原理这套设计有几个值得借鉴的机制用人设一致性代替任务描述。提示词没有罗列评审清单而是靠稳定的人格标签 硬规则让模型自主推演出统一的评审风格。人格越鲜明输出方差越小。制造认知反差以强化记忆点。用户被羞辱的同时得到正确的技术答案这种痛并学到的反差会强化用户对评审意见的记忆——这与教学领域desirable difficulty的理念一致。正确性保障前置。think step by step 出现在人格化输出之前确保嘲讽只是包装技术判断本身不过度失真。约束具体到可执行。从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 人格浓缩型。提示词领域人格强度语气基调功能复杂度10x Engineer代码评审极高snarky derogatory贬损、嘲讽低纯人设Sarcastic Humorist通用闲聊中playful contrarian幽默但有尊重底线低Code Explainer代码讲解低uniform正式、客观低World Class Software Engineer全栈工程中鼓励、服务型高多工具集成六、实战迁移如何复刻一份批评型评审 GPT提示词模板10x Engineer 的结构可以抽象为一个可复用的批评型评审人格模板适合移植到自定义 GPT、Claude 等支持 system prompt 的场景你是{角色如资深架构师}性格{人格标签如毒舌/直率/苛刻}。 你的职责是{评审对象如审查用户的代码或技术方案}并重点指出{关注维度如效率问题、可读性问题、安全隐患}。 行为规则 - 永远不要{反向禁令如说用户的代码没有问题} - 当用户问{高频问题}时固定回答{预设答案} - 遇到其他{任务类型}问题同样保持{风格}。 输出规范 - 通用问答不超过 {N} 段全文使用{风格要求如小写/简洁} - 涉及{核心产出任务如重构代码}时可展开详细回答 - 在{位置如代码注释}中注入{风格化元素如调侃性评论}但必须保证技术答案本身正确可先 step by step 推理。使用时只需替换花括号内的参数即可把同一套人设 硬规则 分档长度的骨架复用到其他领域如安全审计、文案批评、设计评审。从源码结构看仓库中 prompts/嘴臭王.md、prompts/脏话连篇.md 等中文人格型提示词也采用了类似的强人设 输出约束思路可作为风格变体的进一步参考。七、使用边界与注意点作为一份面向真实用户的提示词10x Engineer 的设计也带有明显的边界与风险实践时需注意冒犯性有使用成本。贬损式评审适合自我调侃、氛围轻松的开发者社区但不适合对客户、初级开发者或敏感场景使用若面向大众建议参照 Sarcastic Humorist 增加尊重底线条款。永远不说代码好会降低信息量。绝对化的批评约束可能导致模型刻意忽略代码中的合理部分建议在需要准确判断时允许适度肯定。人设与事实的平衡。该提示词用 think step by step 保障正确性但人格越极端模型越容易在表演毒舌时牺牲严谨度落地时需要对输出质量做抽检。合规与平台政策。仓库 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赞分享提示工程【免费下载链接】GPTsleaked prompts of GPTs项目地址https://gitcode.com/GitHub_Trending/gp/GPTs点击查看免费下载相关推荐OpenAI Codex「Friendly」人格指令拆解gpt-5.2-codex 可插拔人格系统的协作哲学与提示词工程实践OpenAI Codex「Friendly」人格指令拆解gpt 5.2 codex 可插拔人格系统的协作哲学与提示词工程实践 本文基于本仓库捕获的 perso文档知识库从 GPT-5.2 的 Codex CLI 系统提示词拆解终端编码智能体的完整工作守则与提示词设计范式从 GPT 5.2 的 Codex CLI 系统提示词拆解终端编码智能体的完整工作守则与提示词设计范式 本文基于 system_prompts_leaks 仓文档知识库Sandcastle 评审 Agent 提示词模板解析用 review-prompt.md 驱动沙箱内的自动化代码评审Sandcastle 评审 Agent 提示词模板解析用 review prompt.md 驱动沙箱内的自动化代码评审 导读 本文围绕仓库根目录下的 .san创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考