简介这份《ChatGPT中文调教指南》面向希望系统掌握提示词技巧的中文用户无论是初次接触大模型的职场人、内容创作者还是想提升效率的程序员与研究者都能从中找到可复用的实战思路。资源以PDF形式交付压缩包内共1个文件体积约694KB轻量便携适合随时查阅。文档围绕中文环境下的有趣应用展开涵盖学术论文写作、创意小说、商业文案、翻译润色、数据分析、技术文档、教育培训、简历求职、广告营销、SEO优化、社交媒体运营等丰富场景并给出角色扮演、充当Linux终端、英翻中、英英词典、前端思路助手、面试官、文字冒险游戏等具体调教范例帮助读者理解如何通过精准提示词引导模型输出所需内容。目前已有699人学习下载可作为提示词模板与素材库帮助读者快速上手并迁移到自身工作流中。1. 一份被低估的提示词工程素材库很多人第一次打开 ChatGPT 中文调教指南会以为它只是网上流传的“角色扮演提示词合集”翻两页就关掉。但如果你正在做提示词工程、AI 应用开发或者内容生产流程搭建这份文档的价值恰恰在于它把大量可复用的提示词结构摊开给你看——从充当 Linux 终端、SQL 终端这类需要严格约束输出格式的场景到充当面试官、产品经理、DBA 这类需要多轮交互的角色设定再到正则表达式生成器、SVG 设计师这种对输出格式有硬性要求的工具型提示词覆盖面相当广。它解决的核心问题是你不需要从零去猜“怎么跟模型说话才能让它稳定输出我想要的东西”而是可以直接拿现成的模板改参数、换场景。适合谁适合已经能正常使用 ChatGPT、想进一步提升输出稳定性和复用率的从业者也适合刚接触提示词、想通过模仿快速上手的新手。这份文档不是教程是一份素材库关键在于你怎么拆它、怎么用。2. 提示词模板的骨架从角色设定到输出约束2.1 为什么这些模板能稳定生效翻完文档里几十个示例你会发现它们能稳定生效不是靠“咒语”而是靠一套可拆解的骨架。最常见的结构是四段式角色定义、任务描述、约束条件、首轮输入。以“充当 Linux 终端”为例角色定义是“我想让你充当 Linux 终端”任务描述是“我将输入命令您将回复终端应显示的内容”约束条件是“只在一个唯一的代码块内回复终端输出不要写解释”首轮输入是“pwd”。这四段缺一不可尤其是约束条件——它决定了模型输出的格式边界。再往深一层看约束条件又分三类格式约束用代码块、用 markdown 表格、只回复列表、行为约束不要写解释、不要一次问完所有问题、不要破坏角色、内容约束只回答发音、只回复推荐项目、只回复 SQL 结果。文档里那些看起来“效果好”的模板约束条件都写得非常具体。比如“充当英英词典”要求“包括中文翻译、英文释义和一个例句”这就是格式约束“担任面试官”要求“不要一次写出所有的问题只对我进行采访”这是行为约束“充当正则表达式生成器”要求“不要写正则表达式如何工作的解释或例子只需提供正则表达式本身”这是内容约束。理解这个骨架之后你就不需要死记硬背每个模板而是可以按需拼装。我一般会先确定输出格式再倒推需要哪些约束条件最后补上角色和任务描述。这个顺序比从头写更高效因为格式约束是最容易翻车的部分。2.2 拆解一个模板并改造成自己的工具拿文档里的“充当 SQL 终端”做改造示范。原始模板设定了数据库表结构Products、Users、Orders、Suppliers要求“在单个代码块中使用查询结果表进行回复仅此而已不要写解释”。假设你要把它改成一个针对自己业务库的 SQL 助手需要改三个地方表结构描述、输出格式约束、首轮输入。# 改造后的 SQL 终端提示词模板 prompt 我希望你在示例数据库前充当 SQL 终端。 该数据库包含以下表 - customers (id, name, email, created_at) - orders (id, customer_id, amount, status, created_at) - products (id, name, price, stock) 我将输入查询你回复终端显示的内容。 要求 1. 只在单个代码块中回复查询结果表 2. 不要写解释 3. 除非我指示否则不要键入命令 4. 当我需要用英语说明时会用大括号{like this} 我的第一个命令是 SELECT * FROM customers LIMIT 5 这段代码的关键改动在表结构部分——原文用的是通用示例表你必须替换成自己真实的表名和字段名否则模型会按它“想象”的表结构返回结果看起来像那么回事但完全不能用。输出约束部分保留了“单个代码块”“不要写解释”这两条核心规则这是保证输出可直接复制粘贴的关键。首轮输入建议用一条你已知结果的简单查询用来验证模型是否理解了表结构——如果返回的字段名对不上说明表结构描述有问题需要调整。参数方面表结构描述越精确越好字段类型和约束比如 NOT NULL、AUTO_INCREMENT可以省略但字段名和表名必须准确。如果你用的是 MySQL可以在提示词里注明“使用 MySQL 语法”否则模型可能返回 PostgreSQL 或 SQL Server 的方言。这个细节在文档原始模板里没有强调但实际用起来差别很大。2.3 角色扮演类模板的复用逻辑文档里角色扮演类模板占比最大从“充当中国亲妈”到“担任心理医生”从“扮演脱口秀喜剧演员”到“担任牙医”。这类模板的复用逻辑和工具型模板不同——它们更依赖“角色知识范围”和“交互节奏”这两个变量。角色知识范围决定了模型回答的深度和用词。比如“担任哲学老师”要求“用通俗易懂的方式解释概念”而“充当哲学家”要求“深入研究概念提出新想法”。同一个领域老师角色和哲学家角色的输出完全不同。交互节奏则决定了对话是单轮还是多轮。文档里“担任面试官”明确要求“一个一个问我等我回答”这就是多轮交互设计而“充当花哨的标题生成器”是单轮输入输出给关键词就返回标题。复用这类模板时我一般会先问自己两个问题这个角色需要多轮对话还是一次性输出这个角色的知识边界在哪里回答完这两个问题再去找文档里结构最接近的模板改比从头写快得多。比如你要做一个“代码审查助手”文档里没有完全对应的模板但“充当前端智能思路助手”和“作为技术审查员”可以拼装——前者提供代码问题分析的结构后者提供审查维度的框架。3. 把模板接进实际工作流三个可落地的场景3.1 用“表格生成器”模板批量处理结构化数据文档里“做表格”这个模板看起来简单但实际工作中很实用。原始模板要求“只回复一个包含10行的表格以 markdown 表格形式回复不需要附带任何额外解释”。这个约束条件让它可以直接嵌入数据处理流程。假设你有一批产品信息需要整理成对比表格手动做费时费力。用这个模板把产品参数按行输入让模型输出 markdown 表格再粘贴到文档或导入表格软件。关键是要把“10行”改成你实际需要的行数并且明确列名。# 批量生成产品对比表格的提示词 prompt 请你充当表格生成器。你只会回复我一个 markdown 表格。 我会告诉你在单元格中写入什么你只会以 markdown 表格形式回复结果。 不要附带任何额外解释。 请生成一个包含以下列的产品对比表 产品名称 | 价格 | 核心功能 | 适用场景 | 优缺点 产品信息如下 1. 产品A299元自动数据同步个人日常使用优点是便宜缺点是不支持团队协作 2. 产品B899元团队协作权限管理中小企业优点是功能全缺点是学习成本高 3. 产品C1999元私有化部署API接入中大型企业优点是数据可控缺点是价格高 这段代码的逻辑是先用约束条件锁定输出格式只回复 markdown 表格、不加解释再用列名定义表格结构最后按行提供数据。参数方面列名用竖线分隔数据行用编号列表模型会自动对齐。如果你需要调整列顺序或增减列直接改列名那一行就行不需要动其他部分。实际用的时候有个坑如果某行数据里包含竖线字符比如“支持 A|B 两种模式”模型可能会把它当成列分隔符导致表格错位。解决办法是在提示词里加一句“数据中的竖线请用斜杠代替”或者提前把数据里的竖线替换掉。3.2 用“翻译改进”模板做本地化内容生产文档里“充当英语翻译和改进者”这个模板的约束条件写得很细“请仅回答更正和改进的部分不要写解释”“将简单词汇替换成更优美和高雅的表达方式确保意思不变”。这个模板可以直接用在内容本地化流程里。我一般会把它改造成中英双向的版本并且加上术语表约束。比如做技术文档翻译时某些术语必须固定译法不能让模型自由发挥。# 带术语表约束的翻译改进提示词 prompt 我希望你能担任英语翻译、拼写校对和修辞改进的角色。 我会用中文和你交流你会将其翻译并用更为优美和精炼的英语回答我。 请将简单词汇和句子替换成更优美和高雅的表达方式确保意思不变。 请仅回答更正和改进的部分不要写解释。 术语约束 - 接口 统一翻译为 API endpoint - 部署 统一翻译为 deployment - 调优 统一翻译为 fine-tuning 我的第一句话是这个接口部署之后需要做性能调优。 逻辑说明术语约束部分是可选的但做技术内容时强烈建议加上否则同一个词在不同段落可能被译成不同英文后期统一很麻烦。输出约束“仅回答更正和改进的部分”保证了输出干净不会夹杂“这句话的翻译是……”之类的废话。参数方面术语表用“中文 → 英文”的格式写每行一条模型能准确识别。这个模板的边界在于它适合短句和段落的翻译改进不适合整篇长文档一次性丢进去。长文档建议分段处理每段不超过 500 字否则模型可能在中途“忘记”前面的术语约束。3.3 用“提示生成器”模板做模板的模板文档里“充当提示生成器”这个模板比较特殊——它是用来生成其他提示词的。原始模板的逻辑是你给一个标题它返回一个完整的提示词并且要求“提示应该是不言自明的并且适合标题不要参考我给你的例子”。这个模板适合什么场景当你需要批量生成提示词时。比如你要为十个不同的业务场景各写一个提示词手动写太慢可以用这个模板先生成初稿再逐个调整。# 批量生成提示词的元提示词 prompt 我希望你充当提示生成器。 首先我会给你一个标题然后你给我一个提示。 提示应该是不言自明的并且适合标题不要参考我给你的例子。 提示应该包含角色定义、任务描述、输出格式约束、首轮输入示例。 我的第一个标题是充当代码审查助手 逻辑说明我在原始模板基础上加了“提示应该包含”这一条明确要求生成的提示词必须包含四个核心要素。这样生成的初稿结构完整后续只需要填充具体参数。参数方面标题越具体越好——“充当代码审查助手”比“帮我写代码”好得多因为前者限定了角色和任务类型。这个模板的局限是它生成的提示词是通用框架不包含你的业务细节。所以流程应该是“生成框架 → 手动填充业务参数 → 测试 → 调整约束条件”不能指望一步到位。4. 避坑与排查模板用不对的五个典型症状4.1 输出格式飘忽不定现象明明要求“只回复 markdown 表格”模型却在表格前后加了“好的以下是表格”之类的废话或者表格列数对不上。原因约束条件不够强硬或者约束条件的位置太靠后。模型对提示词开头和结尾的内容更敏感如果约束条件埋在中间容易被忽略。解决把格式约束放在提示词的最后一段并且用“只”“仅”“不要”这类强约束词。如果还是飘加一句“如果违反上述格式要求请重新生成”。我一般会把格式约束单独成段前后各空一行让模型更容易识别。4.2 角色扮演中途“出戏”现象让模型扮演面试官问了三个问题之后它突然开始解释“作为 AI 我建议你……”或者直接给出所有问题的答案。原因多轮对话中模型的角色记忆会衰减。尤其是对话轮次超过五轮之后原始角色设定在上下文中的权重会下降。解决在每轮对话开头重复关键约束。比如每轮都加一句“请继续保持面试官角色一次只问一个问题”。另外文档里“担任面试官”模板明确写了“不要一次写出所有的问题”这个约束在首轮有效但后续轮次需要重复强调。如果对话很长建议每五轮重新粘贴一次完整提示词。4.3 表结构或数据描述被“脑补”现象用 SQL 终端模板时模型返回的字段名和你给的不一样或者查询结果明显是编造的。原因表结构描述不够精确或者模型在“填充”它认为合理的字段。大语言模型倾向于生成“看起来合理”的内容而不是严格遵循输入。解决表结构描述用代码块包裹字段名用反引号标注并且在提示词里加一句“如果查询涉及不存在的表或字段请回复‘表不存在’而不是猜测”。这个约束能有效减少脑补。另外首轮输入用一条简单查询验证表结构是否被正确理解确认后再进行复杂查询。4.4 翻译改进模板“过度发挥”现象用翻译改进模板时模型不仅改了语法还改了原意或者把技术术语替换成了文学化表达。原因约束条件里“更优美和高雅的表达方式”这个要求被过度执行了。模型分不清“改进表达”和“改变意思”的边界。解决加一条约束“确保技术术语和专有名词不变”并且在术语表里明确列出不能改的词。如果还是过度发挥把“更优美和高雅”改成“更准确和简洁”降低模型的发挥空间。文档原始模板里“确保意思不变”这句话很关键不能省略。4.5 批量生成时格式不统一现象用表格生成器批量处理数据时前几行格式正常后面几行开始出现列数不一致、缺少表头等问题。原因输入数据太长模型在后半段“忘记”了格式要求。或者输入数据里包含了特殊字符干扰了表格解析。解决控制单次输入的数据量建议不超过 20 行。如果数据量大分批处理每批都重新粘贴完整提示词。另外输入数据里的竖线、换行符等特殊字符提前替换掉。我一般会在批量处理前先跑一条测试数据确认格式没问题再跑全量。5. 进阶用法把模板改造成可调参的提示词函数5.1 用变量替换让模板可复用文档里的模板是静态的但实际工作中同一个模板往往需要反复使用只是每次填入不同的参数。把模板改造成带变量的函数是提升复用率的关键一步。def build_sql_terminal_prompt(table_schema, first_query): 构建 SQL 终端提示词 table_schema: 表结构描述字符串 first_query: 首轮查询语句 return f 我希望你在示例数据库前充当 SQL 终端。 该数据库包含以下表 {table_schema} 我将输入查询你回复终端显示的内容。 要求 1. 只在单个代码块中回复查询结果表 2. 不要写解释 3. 除非我指示否则不要键入命令 4. 如果查询涉及不存在的表或字段回复表不存在 我的第一个命令是 {first_query} # 使用示例 schema - customers (id, name, email, created_at) - orders (id, customer_id, amount, status) prompt build_sql_terminal_prompt(schema, SELECT * FROM customers LIMIT 5) print(prompt)这段代码的逻辑是把表结构和首轮查询抽成参数每次调用时传入不同的值。参数说明table_schema是表结构描述建议用列表格式每行一个表first_query是首轮查询建议用简单查询验证表结构。这个函数可以进一步扩展比如加上数据库类型参数MySQL/PostgreSQL在提示词里动态插入“使用 MySQL 语法”的约束。5.2 用输出校验做闭环模板用多了会发现即使约束条件写得很细模型偶尔还是会跑偏。加一层输出校验能大幅降低翻车率。比如 SQL 终端场景可以校验返回内容是否在代码块内、是否包含表头。import re def validate_sql_output(output): 校验 SQL 终端输出是否符合格式要求 返回 (是否通过, 原因) # 检查是否在代码块内 if not re.search(r, output): return False, 输出未包含代码块 # 检查是否包含解释性文字 explain_keywords [解释, 说明, 注意, 提示] for kw in explain_keywords: if kw in output: return False, f输出包含解释性文字{kw} # 检查是否有表格结构至少包含表头分隔线 if --- not in output and | not in output: return False, 输出未包含表格结构 return True, 通过 # 使用示例 test_output | id | name | email | |----|------|-------| | 1 | 张三 | zsexample.com | passed, reason validate_sql_output(test_output) print(f校验结果{passed}原因{reason})逻辑说明这个校验函数检查三个关键点——是否在代码块内、是否包含解释性文字、是否有表格结构。参数方面explain_keywords列表可以根据实际场景调整比如翻译场景可以加上“翻译为”“意思是”等词。校验不通过时把原因拼进下一轮提示词让模型重新生成。这个闭环能把格式错误率降到很低。5.3 一个我踩过的坑刚开始用文档里的模板时我直接复制粘贴结果发现同一个模板在不同对话里效果不一样。后来才意识到模板的效果和对话历史有关——如果当前对话里已经有很多轮无关内容模型的注意力会被分散约束条件的权重会下降。从那以后我每次用模板都强制开新对话并且把完整提示词作为第一条消息发出去。这个习惯看起来简单但能避免很多玄学问题。另外文档里的模板是通用版本直接用在生产环境前一定要做小批量测试。我一般会跑 10 条测试数据统计格式正确率和内容准确率确认稳定后再接入流程。希望这些经验帮到你。本文还有配套的精品资源点击获取