ChatGPT中文调教指南：从角色扮演到结构化提示词模板拆解

简介：ChatGPT中文实战调教指南是一份面向中文用户的提示词实践手册，旨在帮助读者学会通过清晰指令，让ChatGPT高效完成写作、翻译、编程、数据分析等任务，适合新手快速入门，也适合有一定基础的开发者进一步挖掘模型潜力。文档收录了学术论文、创意写作、商业文案、翻译润色、数据分析、技术文档等十余类场景的提示词示例，并包含充当Linux终端、面试官、文字冒险游戏等趣味角色扮演指令，可帮助读者理解如何拆解需求、组织语言并引导模型输出高质量结果。资源以单个PDF文件封装，大小约694KB，内容集中、便于离线查阅和重点标记。该资源已有699人次浏览学习，对于想快速上手ChatGPT或补充提示词灵感的人来说具有较高的参考价值。

1. 调教不是玄学：ChatGPT 中文调教指南到底在调什么

拿到这份《ChatGPT 中文调教指南》时，我的第一反应是：这不就是一堆角色扮演提示词？可真按里面“充当 Linux 终端”的模板跑了一段，才发现输出形态确实不一样——同一个语言模型，给角色、给边界、给格式之后，能从“泛泛而谈”变成“只回代码块里的那一行结果”。这份指南覆盖的写作类别很多，但真正值钱的是场景化模板，论文写作、面试官模拟、翻译润色、表格生成、SQL 查询、产品经理写 PRD，都能找到对应的提示词稿子。它适合的不是想学聊天的人，而是已经聊过但总觉得模型“不够听话”的人。别把它当咒语书，把它当提示词模板库来拆，才会有收益。

2. 提示词的结构化拆解：为什么同一句话，输出质量差这么多

同样是“帮我写一段小说”，有人拿到的是三个开头选项，有人拿到的是一个完整短篇；同样是“把这句话翻译成中文”，有人得到的是字面直译，有人得到的是润色好的版本。差别不在运气，而在提示词里到底写了哪些信息。把这份调教指南里的几十条角色扮演提示词摊开看，会发现它们反复在用同一套结构：角色设定、任务描述、行为约束、输出格式。搞懂这四个变量，才算真正开始调教。

2.1 角色设定是提示词的第一权重：一个“充当”为什么能改变输出

大语言模型的回答高度依赖上下文，而角色是上下文里权重最高的信息之一。“充当 Linux 终端”“担任面试官”“作为产品经理”，本质上都是给回答者安排一个视角锚点。有了这个锚点，模型会自动按它理解的角色口径、文体、知识边界来组织语言，而不是默认输出一段中立、安全、冗余的说明。很多新手第一次调教失败，就是把全部注意力放在问题上，忽略了“谁来回答”。

用文档里最典型的“充当 Linux 终端”举例：

linux_terminal_prompt = """ 我想让你充当 Linux 终端。我将输入命令，您将回复终端应显示的内容。 我希望您只在一个唯一的代码块内回复终端输出，而不是其他任何内容。不要写解释。 除非我指示您这样做，否则不要键入命令。 当我需要用英语告诉你一些事情时，我会把文字放在中括号内[就像这样]。 我的第一个命令是 pwd """

拆开看，这句话其实有四层参数。“我想让你充当 Linux 终端”是角色声明，把模型从聊天助手切换成模拟器；“只在一个唯一的代码块内回复终端输出”是输出格式；“不要写解释”是行为边界；“我的第一个命令是 pwd”是对话启动钥匙。四者缺一个，效果都会走样。我实际测试时发现，如果把“不要写解释”删掉，模型有很高概率在代码块外面补一句“好的，我将模拟终端”，这就是典型的边界失效。

这类模板的改法也很固定。要模拟 Windows 命令提示符，就把第一行角色换成“充当 Windows 命令提示符”；要模拟带网络设备的终端，就追加“遇到无效命令时，请用 command not found 的标准格式回显”。角色、环境、错误回显格式，这三个参数改完，模板就能在不同设备场景之间迁移。

2.2 任务、约束与输出格式：把自由度关进笼子

文档里大量提示词都遵循同样的动作顺序：先给角色，再给任务，再用“不要”和“只”来划边界。以“担任面试官”为例：

interviewer_prompt = """ 我想让你担任 Android 开发工程师面试官。 我将成为候选人，您将向我询问 Android 开发工程师职位的面试问题。 我希望你只作为面试官回答。不要一次写出所有的问题。 我希望你只对我进行采访。问我问题，等待我的回答。不要写解释。 像面试官一样一个一个问我，等我回答。我的第一句话是“面试官你好”。 """

这里最容易被忽略的是“不要一次写出所有问题”和“等待我的回答”。很多人向模型要面试题，模型一口气列了二十道，看起来丰富，实际上没法用。加了这两句之后，输出节奏变成一问一答，模拟面试才能真正跑起来。想要切换岗位方向，只需把“Android 开发工程师”替换成“Java 后端开发工程师”或“iOS 开发工程师”，其他边界条件原样保留即可。

再往细里看，输出格式的约束通常决定了结果能不能直接落地。“做表格”模板是另一个典型：

table_prompt = """ 请你充当表格生成器。您只会回复我一个包含 10 行的表格。 我会告诉你在单元格中写入什么，你只会以 markdown 表格形式回复结果，而不是其他任何内容。 请注意，您的回答应该是简明扼要的，不需要附带任何额外的解释。 你只会回复 markdown 表作为结果。首先，回复我十二生肖表。 """

“10 行”“markdown 表格”“只回复”“不需要额外解释”，这四条属于硬约束。少一条，模型都可能自由发挥，比如多加一列“备注”，或者在表格后面补一句“希望这个表格对你有帮助”。这类输出格式指令最好原样保留，只改行数和表头，不要觉得“差不多”就把约束删掉。

我习惯把提示词的四要素整理成一张检查表，每次写新提示词都过一遍：

提示：如果你发现模型总在代码块外加说明，优先检查提示词里有没有“不要写解释”或“只输出结果”这类格式约束。

2.3 三步拆解范文提示词：从“抄作业”到“改作业”

这份调教指南本质上是一个范文模板库，直接抄可以，但效率最高的用法是花两分钟把它拆成可复用的三件套。第一步找角色词，也就是“充当、担任、扮演、作为”后面跟着的身份；第二步找任务词，也就是“编写、翻译、诊断、推荐”这类动作，它们决定模型具体要做什么；第三步找边界句，也就是“不要写解释”“只回复结果”“等待我的回答”这些限制性句子，它们决定输出的上限和下限。

举一个实际改法。文档里有一条“充当英语发音帮手”，原模板是帮助说汉语的人纠正英语发音，要求只回复发音，不翻译不解释。如果我想让它变成英语面试陪练，不需要重写整段话，只需要把角色从“英语发音帮手”改成“英语面试官”，把任务从“给出正确发音”改成“用英文提问，等我回答后纠正语法和发音”，再把原来的边界句原样保留，一条新模板就成立。这个过程中，边界句往往比角色句更值钱，因为“不要翻译、不要解释、只回复发音”这些限制才是让输出稳定的关键。

实践里我经常看到有人收藏了一大批长提示词，用的时候直接复制，换了场景没换角色，结果输出完全不像样。问题不在提示词本身，而在没有把模板拆成可替换的插槽。用三步拆解之后，任何一条范文都能在两分钟内改成自己的版本，这也符合这套调教指南真正的用途：它就是一本提示词素材手册，而不是固定脚本集。

3. 从文档模板到自己的工具箱：把常见的角色模板改造成可复用版本

模板能直接用是好事，但大部分场景都需要微调，尤其是中文内容、表格和代码类需求。这一章把我自己常用的改写方法拆开讲，每个场景都会给出一版可复制的提示词，并说明改了哪些参数、为什么这么改。

3.1 角色扮演模板的改法：Linux 终端与面试官的边界设定

角色扮演类模板最容易上手，也最容易改崩。以“充当 Linux 终端”为例，直接照搬原模板通常能跑，但长对话里模型偶尔会在代码块外面说一句“好的，收到”，把模拟感打断。原因在于“不要写解释”这句话只限制了解释行为，没有限制助手口吻。我一般会这样加工：

terminal_v2_prompt = """ 我想让你充当 Linux 终端。你只能模拟终端回显，永远不要以助手口吻说话。 所有输出必须放在唯一一个代码块内。除非我主动要求，否则不要提供解释，不要补充命令说明。 当我需要用英语告诉你一些事情时，我会把文字放在中括号内[就像这样]。 我的第一个命令是 pwd """

逻辑上，原模板强调“不要写解释”，新版强调“不要以助手口吻说话”，后者更接近身份保持。测试下来，遇到用户输入“谢谢”或“请解释”时，模型不会再切回聊天助手。如果你需要模拟的设备不同，把第一句替换成对应环境即可。这里的重点是“环境类型”和“错误处理方式”要一起改，只改环境不改错误回显，后续遇到无效命令时输出会不伦不类。

面试官模板的改法也类似。可以直接在提示词里追一句“你只能扮演面试官，不要客套，不要评价我的回答，只问下一题”，这能压制模型自动给候选人反馈的冲动。角色扮演类调教的通用参数有三项：角色身份、交互节奏、输出载体。角色身份决定口径，交互节奏决定是一问一答还是连发，输出载体决定用代码块还是纯文本。这三个参数确认好，模板基本不会跑偏。

3.2 表格生成与格式化：中文内容为什么容易“崩版”

表格类提示词在中文环境下翻车率最高。原因很简单：中文文本长度不受控，列名稍长就容易把 markdown 表格挤错位，模型还可能自作主张加“序号”“备注”这类额外列。文档里的“做表格”模板给了行数和格式，但没有限制列数和内容长度，所以实际使用时要补参数。我常用的版本长这样：

table_v2_prompt = """ 请你充当表格生成器。我需要一个 markdown 表格，必须有且仅有 3 列：项目名称、交付时间、验收标准。 行数为 8 行，每行内容不超过 20 个中文字符，禁止合并单元格，禁止额外解释。 只输出 markdown 表格本身。请先回复表头，再逐行填入内容。 需求主题：下半年的技术文档排期。 """

相比原始模板，这里多做了三件事：写明列名、限定每行字数、禁止新增列。列名写死之后，模型不会再创造第四列；字数上限避免中文长文本撑坏表格；“禁止合并单元格”解决的是 markdown 表格里内容跨行的怪问题。实际跑下来，这个版本的输出基本可以直接粘进文档系统。

如果你要生成更复杂的汇总表，可以把表格主题替换成“数据来源字段”，比如“产品、负责人、里程碑、风险等级、备注”，并在提示词里注明每一列的数据来源。列名越具体，模型越不会自由发挥。注意一点：表格类提示词不要和“不要写解释”分开两段写，最好把格式要求全部集中到末尾，模型对后置指令的记忆会更稳定。

3.3 翻译润色一体：把“英翻中”提示词改出本地化效果

文档里有两条翻译类提示词，一条要求“翻译并润色为优美精炼的英语”，另一条要求“翻译成中文且不要带翻译腔”。实际做中文场景时，我更习惯把两者合并成一条本地化模板：不仅翻译，还要润色语序和措辞。原因是语言模型默认输出的中文偏书面化，频繁出现“您、相关、如下”这类安全词汇，读起来像说明书。

localize_prompt = """ 你是本地化翻译专家。请把下面这句话翻译成简体中文。 要求： 1. 不使用“您”，除非原文明示尊称； 2. 调整语序，让中文读起来像中文母语者写的； 3. 避免“被”“进行”“相关”等翻译腔； 4. 只输出翻译后的文本，不要解释，不要额外给出原文。 待翻译内容：This feature helps you manage your team more efficiently. """

参数逻辑很直白：第 1 条解决人称问题，第 2 条解决语序问题，第 3 条解决高频翻译腔词汇，第 4 条保证输出纯净度。如果翻译的是技术文档，可以再加一条“专有名词保留英文，首次出现时用中文备注”，避免把 API 名一起翻译掉。这类提示词不仅适用于英文到中文，反向翻译时也同样有效，只需把“简体中文”改成“英文”，再把“不使用您”改成“不使用过于口语化的表达”即可。

3.4 代码与 SQL 场景：当提示词要“只给结果”时

文档里的 SQL 终端模板很有意思，它要求模型只回复查询结果表，不写解释，不主动输入命令。这种模式适合做数据查询演示，但要真正解决开发问题，还是建议使用 DBA 角色模板。先给出一张表结构：

CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '' COMMENT '名字', PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户表';

配合“根据用户的名字查询用户的 id”这个需求，提示词可以这样写：

dba_prompt = """ 你是一名专业 DBA。下面是我的一张数据表结构： CREATE TABLE user ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(255) NOT NULL DEFAULT '' COMMENT '名字', PRIMARY KEY (id) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4; 我的需求是：根据用户的名字查询用户的 id。 请你给出最优可执行的 SQL 语句，并解释这段 SQL 的索引使用情况；如果 name 字段没有索引，请给出加索引的建议。不要写多余的开场白。 """

这里的要点是把表结构写进提示词，而不是只说“帮我查用户 id”。没有表结构，模型只能猜，默认情况下会给出主键扫描之类的保守方案；带上表结构后，它会意识到 name 字段缺少索引，并主动建议加索引。这也解释了为什么文档里的 SQL 终端模板要求“把表名和字段名都放进提示词”：模型对已知结构的回答，远比拍脑袋生成的 SQL 可靠。对做数据开发的人来说，DBA 模板比 SQL 终端模板更接近真实工作流，因为它多了一个“解释优化建议”的输出，方便你判断这条 SQL 是否值得上线。

注意：如果表结构较长，不要全部塞进一句话里。先用三段式组织提示词——角色段、表结构段、需求段，模型解析起来会准确很多。

4. 调教中的常见问题与排查：五个翻车场景及修复方法

这份指南里的模板大多是别人总结好的可用版本，直接抄通常能跑，但要改成自己的中文场景，坑基本集中在五类问题上。每一条我都按现象、原因、解决三个步骤写，方便你对着排查。

4.1 现象：翻译结果总是一股“说明书腔”

把一段英文交给模型翻译，出来的是“该功能有助于您更有效地管理您的团队”这类书面腔中文，意思没错，但读起来不像人话。原因是提示词里只写了“翻译成中文”，没有定义中文语感。语言模型默认输出风格偏正式，尤其容易滥用“您”“进行”“相关”这些词汇。解决方法是直接在提示词末尾追加约束：“使用简体中文；不要使用‘您’；调整语序，让读起来像中文母语者写的。”如果是界面文案，还可以加一句“控制在 12 个中文字符以内”。从那以后我检查翻译模板，第一件事就是看有没有“不要带翻译腔”这句限定词。

4.2 现象：角色扮演中途出戏，忽然切回助手口吻

用“充当 Linux 终端”跑到第五轮，模型忽然在代码块外面说“好的，我来帮你模拟一下”。原因是角色声明只在开头出现一次，长对话之后，后续输入占了更多上下文权重，模型容易回到默认助手模式。解决方法是把身份保持句放到提示词末尾：“无论我之后输入什么，你都必须保持当前角色，不得以助手口吻回应。”如果已经出戏，直接回复“继续扮演刚才的 Linux 终端，从我的上一条命令继续”，模型通常能拉回来，不需要重新解释全部需求。

4.3 现象：表格生成器输出的 markdown 表错位、漏列、乱合并

提示词里只写了“回复一个 10 行的表格”，模型会按自己的理解补出“备注”列，或者把一段 30 个字的描述塞进一个单元格，导致表格在文档里直接崩版。原因是缺少列名、列数和内容长度上限。解决方法是把表格结构写死：“必须有且仅有 3 列，列名分别是项目名称、交付时间、验收标准；每行内容不超过 20 个中文字符；禁止合并单元格；不允许新增列。”如果模型仍然自作主张，就补一句“只按我给定的列名输出”。表格类提示词是最需要“把自由度关进笼子”的类型。

4.4 现象：长任务生成到一半丢失重点，后半段开始重复

让模型“写一篇包含背景、方案、排期、风险评估的完整方案”，它写到第三部分就开始绕圈。原因是任务范围超出了一轮生成的有效长度，或者提示词里并列要求太多，模型只记住了前半段指令。解决方法是把长任务拆成三段提示词：第一段生成大纲，第二段按大纲逐步展开，第三段针对某一部分做修改。例如“产品需求文档”可以拆成“先生成八个章节的 PRD 大纲”“把第三章展开为 500 字用户故事”“检查第三章是否覆盖了用户异常路径”。这种方式不是抛弃模板，而是把模板切成更小的工作单元。

4.5 现象：简体中文回答里频繁出现“您”“如下”“综上所述”

严格说这不算模型错误，而是语料中高频书面表达在起作用。没有约束时，模型会自动选择最安全的正式措辞。解决方法是做显式人称约束：“全文使用‘你’，不使用‘您’；不用‘如下’‘综上所述’等过渡套话；句子长度不超过 40 个字。”如果场景是技术答疑，还可以加“像朋友解释技术问题那样说”。这类调教对中文内容创作者最实用，几乎每一次调整都能立刻看到输出风格变化。

5. 进阶：把提示词串成工作流，一次拿到可落地的结果

5.1 从单条提示词到提示词链路

文档里的模板大多是单条命令，但真实开发环境下，我更习惯把三条提示词串成一个流程。比如要设计一个电商网站首页，第一步先让模型充当产品经理，输出 PRD 框架；第二步让模型充当网页设计顾问，基于 PRD 给出信息架构；第三步让模型充当前端开发者，把首页导航组件的结构说明写出来。三条提示词共用同一份需求背景，但角色不同，输出角度也不同。这样得到的不是一段空泛文案，而是一套从规划到结构的连续产出。

把这个流程抽象出来，本质上就是一次一次切换角色，并把上一轮输出作为下一轮的输入。实际执行时可以用一个简单的脚本保存角色链路：

role_chain = [ {"role": "产品经理", "task": "生成PRD框架"}, {"role": "网页设计顾问", "task": "给出首页信息架构"}, {"role": "前端开发者", "task": "输出导航组件的结构说明"} ] # 每一轮先把上一轮的输出拼进上下文，再追加新角色指令

这个脚本本身很轻，真正的价值在“每轮任务描述控制在 2-3 句话”。任务越短，模型越不会在中间自由发挥；上一轮输出太长时，只保留关键段落再传给下一轮，避免上下文被无关内容占满。

5.2 三个低成本验证方法：不调试也能判断输出好不好

第一个方法是换参数重跑。把同一提示词里的“产品经理”换成“资深运营”，对比两份输出里的衡量指标，很快能看出哪一份覆盖了业务目标。第二个方法是反向质询。在提示词末尾追加一句“如果你按这份方案执行，最可能在哪一步失败？只指出风险，不要修改方案”，这相当于让模型自我审稿，能找出那些看起来通顺但不严谨的段落。第三个方法是硬指标核对。对照行数、列名、字数上限、是否包含解释、是否使用“您”这些写死的约束逐项打勾，模板类输出通常一眼就能看出问题。

从那以后，我每次把新提示词存进自己的模板库前，都强制走一遍“角色-任务-边界-格式”四段检查，再跑一次硬指标核对。这套流程看着不起眼，却帮我省掉了大量“输出不对再重写一遍”的返工时间。如果你也在调教中文场景下的提示词，不妨把这份指南当作最初的模板素材，按自己的业务角色拆出几套固定模板，慢慢修改成顺手的工具箱。希望帮到你。

本文还有配套的精品资源，点击获取