企业官网建设流程全解析

简介：《ChatGPT-角色扮演指南》是一份面向AI应用初学者、内容创作者与职场写作者的PDF实操手册，重点解决“如何通过角色设定让ChatGPT稳定输出专业内容”的问题。压缩包内仅含1个PDF文件，大小约797KB，便于在电脑或移动端直接查阅。文档按场景梳理学术论文写作、创意小说、商业文案、编辑校对、多语言翻译、数据分析、技术文档、教育培训、网站内容、研究咨询、演讲稿、简历与个人陈述、广告与SEO、社交媒体、新闻稿、电商及旅游医疗文案等角色指令，并给出小说创作、Linux终端模拟、英语翻译改进、面试官、文字冒险游戏、产品经理等示例，帮助读者理解提示词结构与复用方法。读者可据此拆解角色、任务与输出格式，组合出适配自身场景的指令模板。已有286人学习下载，适合希望快速上手角色扮演提示、提升写作与办公效率的读者参考。

1. 六十多个角色模板里，真正能复用的只有四段

上周有同事把这份《ChatGPT-角色扮演指南.pdf》甩给我，说里面角色多到看不过来，让我帮忙挑几个能用的。我翻了一遍，发现用法的分化特别明显：多数人是需要面试就搜“面试官”，需要翻译就搜“翻译”，复制一段粘进对话框，聊完关掉，下次再搜。这本册子被当成了词典，用一次查一次。真正值得沉淀的，是每个模板背后那套几乎不变的骨架——身份声明、行为约束、输出格式、接管条件。ChatGPT 角色扮演稳不稳，八成取决于这四段写没写全，角色名起得多花哨反而是次要的。这份资源适合每天要拿 AI 写代码、写文档、做翻译、做面试演练、跑 SQL 查数据的人，尤其是想把“一次性提问”变成“可重复工作流”的从业者。下面按拆骨架、改参数、存资产、避坑的顺序走一遍。

2. 四段骨架：把“充当 Linux 终端”拆到每一行

整份角色扮演指南里，我最常拿来当教学样本的是“充当 Linux 终端”这一条。它短，但结构完整得过分，几乎每个要素都露在外面。原模板大致长这样：

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

五句话，四个功能块加一个锚点。拆开看，你会发现后面那些“面试官”“产品经理”“SQL 终端”的模板，无非是把这四块换了个内容填进去。

2.1 身份声明与知识边界

第一句“我想让你充当 Linux 终端”是身份，但它同时划了知识边界：终端不解释、不建议、不写散文，它只输出执行结果。很多人写角色提示词只写到“你是一个资深工程师”，这等于没划边界，因为“资深工程师”可以写代码、可以讲架构、可以做代码评审，输出空间大得没边。

PDF 里几个质量高的模板，身份句后面都跟着一句隐性的范围限定。比如“充当英英词典”那条明确说“将英文单词转换为包括中文翻译、英文释义和一个例句的完整解释”，等于把输出限定在三个字段里。我一般会把身份句写成两段：第一段说“你是谁”，第二段说“你不负责什么”。像这样：

你是一位只做英译中的技术文档译者。 你不解释翻译思路，不评价原文质量，不主动扩写原文没有的信息。

“不负责什么”这一句，比前面十句“你要专业、要准确”都管用。原因不玄学：模型对否定式约束的遵循度通常高于形容词式要求，因为否定句是一个可判定的边界，形容词只是一个方向。

2.2 行为约束：禁止项比要求项更有效

终端模板里连续出现了三个否定：“只在一个唯一的代码块内回复”“不要写解释”“不要键入命令”。这三句构成了整条模板最硬的部分。你要是把它改成“请尽量用代码块回复，可以适当解释”，输出立刻变成“好的，下面是 pwd 命令的输出：……（一段解释）……希望对你有帮助”。

我在实际项目里做过一个粗糙对照：同一个终端角色，A 版保留三条否定约束，B 版换成三条正向描述，各跑二十次pwd、ls、cat三类命令。A 版二十次全部是单代码块、零解释；B 版有七次在代码块外多了一句“这是命令的输出结果”，还有三次把命令本身也写进了代码块。样本不大，但方向很清楚：约束写成“不要 X”比写成“请 Y”更容易守住。

常见做法是把约束分成两类写。硬约束写否定句，比如“不要在代码块外输出任何文字”“不要替我执行下一步”“不要补全我没输入的命令”。软约束写正向句，比如“错误信息按原样返回，包括退出码”。硬软分开，出问题时你能一眼定位是哪一类没守住。

2.3 输出格式与接管条件

“只在一个唯一的代码块内回复”是输出格式，“除非我指示您这样做，否则不要键入命令”是接管条件——什么时候该停，什么时候该等。这两块是新手最容易漏的，也是长对话里最先崩的。

输出格式要落到可机器判断的程度。终端角色说“唯一代码块”，表格角色说“只回复 markdown 表格”，SVG 角色说“只发 markdown 图片标签，不要放在代码块里”。这些描述的共同点是：都能用肉眼一秒判断对错。反面例子是“请用清晰的结构输出”，这句话没法判断，模型每次给你一个不同的“清晰”。

接管条件解决的是“谁主导下一步”。终端模板用中括号做了一个通信约定：中括号里是人对模型说的话，中括号外是终端输入。这个设计很巧，它把“元指令”和“业务输入”分到了两个通道，模型不容易把“帮我看看这个报错”当成一条要执行的命令。做多轮角色扮演时，我基本都会保留一个类似的通道约定，否则聊到第十轮，你说“停一下”，它会真的去执行一个叫“停一下”的动作。

2.4 为什么首轮必须给一个锚点

最后一句“我的第一个命令是 pwd”，看着像随手写的，其实是整条模板的启动键。角色扮演最尴尬的时刻是第一轮：模型知道自己是终端了，但不知道从哪开始，于是它可能回一句“好的，我已准备好，请提供命令”。这句话破坏了“只输出代码块”的约束，虽然无害，但说明角色还没真正进入。

给一个具体的第一轮输入，等于给模型一个示范样本。它看到pwd和期望的输出形态，后面就会照着这个形态走。我在写面试官角色时会写“我的第一句话是：面试官你好”，写 SQL 终端角色时会写“我的第一个命令是 SELECT ... LIMIT 10”。锚点越具体，第一轮越稳。

反过来说，如果你的角色模板用了很久，每次开头都要纠正一轮才进入状态，八成是缺这个锚点。补一句具体输入，比反复强调“请严格扮演”有效得多。

3. 角色卡落库：YAML 存、脚本渲染、改动前先跑对照

模板抄在备忘录里，用三个月就会变成一堆“最终版”“最终版2”“真的最终版”。这不是文件管理问题，是提示词本身进入了维护阶段却没有对应工具。我的做法是把角色卡从纯文本迁到结构化文件，用脚本渲染，改动前跑对照。

3.1 角色卡用 YAML，不用 Word 或备忘录

一条角色卡至少包含五块：标识、身份、约束、输出契约、变量。用 YAML 存的好处是字段固定，改哪一块一目了然，也方便脚本拼装。下面是我现在用的结构，把 PDF 里的“英译中”角色改造成了参数化版本：

id: translator_en_zh version: 3 role: 英译中技术文档译者 identity: | 你是一位长期做技术文档本地化的中文译者。 你不解释翻译思路，不评价原文质量，不扩写原文没有的信息。 constraints: - 先还原句子意图，再按中文语序重组，不做逐字直译 - 代码、变量名、路径、命令行原样保留，不翻译 - 术语不确定时，译文后用【待确认：原词】标出 output: format: markdown sections: [译文, 术语表, 待确认] variables: glossary: {} tone: 中性书面

identity用多行块，方便写“你不负责什么”。constraints是列表，一条一个可判定行为，别把三条约束塞进一句话。output.sections是关键，它规定了每次回复必须出现哪几个小节，缺一个就算没守住契约。variables留空对象，渲染时把外部术语表合并进来。

这里有个容易忽略的点：version字段必须手动递增。我吃过亏，同一个角色卡改了三版，出问题时翻记录，根本分不清哪次对话用的是哪版。现在只要动过constraints或output，版本号加一，文件名不变。

3.2 渲染脚本：一条命令吐出一段可直接粘贴的提示词

YAML 是给人看的，真正喂给模型的是渲染后的纯文本。这一步用二十来行 Python 就够，不需要任何框架：

from pathlib import Path import yaml def render(card_path: str, glossary: dict | None = None) -> str: card = yaml.safe_load(Path(card_path).read_text(encoding="utf-8")) lines = [f"你现在的角色是：{card['role']}", card["identity"].strip(), ""] lines.append("## 行为约束") for idx, rule in enumerate(card["constraints"], 1): lines.append(f"{idx}. {rule}") out = card["output"] lines += ["", "## 输出契约", f"格式：{out['format']}"] lines.append("必须包含以下小节：" + "、".join(out["sections"])) lines.append("缺少任何一个小节都视为本次回复不合格。") g = {**card.get("variables", {}).get("glossary", {}), **(glossary or {})} if g: lines += ["", "## 术语表（强制遵循）"] lines += [f"- {k} => {v}" for k, v in g.items()] lines += ["", f"语气：{card['variables'].get('tone', '中性')}"] return "\n".join(lines) if __name__ == "__main__": import sys print(render(sys.argv[1]))

函数做三件事：把身份和约束按固定顺序拼成正文，把输出契约显式写成“缺小节即不合格”，再把术语表合并进提示词尾部。glossary参数允许运行时覆盖 YAML 里的默认值，做不同项目时不用改文件。sys.argv[1]传角色卡路径，输出直接重定向到文件。

跑起来就一行：

python render_card.py cards/translator_en_zh.yaml > out/translator_v3.txt

渲染出来的文本粘进对话前，我会先自己读一遍。读不通的地方，模型也读不通。这一步花三十秒，能省掉后面三轮返工。

3.3 改约束之前，先跑三遍对照

角色卡改一条约束，效果可能变好也可能变差，凭感觉判断不可靠。我的做法是固定三组输入，改动前后各跑一遍，逐条对照输出契约有没有守住。

三组输入要覆盖三种情况：正常输入、边界输入、故意违规的输入。翻译角色的三组可以是：一段普通技术文档、一段夹杂代码和路径的文档、一段要求它“顺便评价一下原文写得好不好”的越界请求。第三组最能暴露问题，因为角色漂移基本都发生在用户提出越界请求的时候。

对照结果不用写得多正式，一张表就够：

这张表的价值不在打分，而在于逼你把“感觉变好了”翻译成具体行为。我现在的习惯是：没有这张表，不改constraints。血泪经验是有一回为了“让它更自然一点”松了一条约束，结果越界请求全部放行，用了一周才发现。

4. 五类高频角色的参数调法：翻译、面试、终端、评审、写作

PDF 里角色虽多，落到日常真正高频的就五类。每一类的关键参数不一样，调错了不是效果差一点，是整类任务不可用。下面按类型拆，参数都能直接对着改。

4.1 翻译类：语言识别、输出粒度、术语表优先级

翻译角色最容易翻车的不是译得不好，是它自作主张。指南里的英译中模板有一句“不要带翻译腔，要自然流畅地道”，这句话方向对，但太软，模型会理解成“可以意译到改变原意”。

我现在会把翻译类角色的参数拆成三个。第一是输入语言识别方式：明确写“若输入语种与目标语种相同，直接指出并停止翻译，不要改写”。第二是输出粒度：是整段译，还是逐句对照，还是只给修改部分。指南里“充当英语翻译和改进者”那条要求“仅回答更正和改进的部分”，就是粒度参数，这个设定非常适合改稿场景，但不适合整篇翻译。第三是术语表优先级：术语表和“自然流畅”冲突时谁赢。必须写死，我一般写“术语表优先于流畅度”。

调这三个参数之后，翻译角色的返工率下降最明显。尤其是“同语种直接停止”这一条，能挡掉大量把中文改成另一种中文的无用输出。

4.2 面试官类：单轮提问、追问深度、评分锚点

指南里的面试官模板写得挺克制：“不要一次写出所有的问题，我希望你只对我进行采访，问我问题，等待我的回答。”这三句是核心，缺一句就变成“一次性列出二十道题”。

我在此基础上加两个参数。第一是追问深度：答完一题后追不追问、追几层。默认设一层，因为多数人需要的是把一个问题讲透，而不是被连环追问到崩。第二是评分锚点：每轮回答后给一个 1-5 分的简评，并说明扣分点。这一条是我自己加的，指南里没有，但没有它，整场面试聊完你不知道自己哪儿不行。

还有个小细节：面试官角色一定要限定“一次只问一个问题，问完停止输出”。不写“停止输出”，它会自问自答，把标准答案也给你，面试就失去意义了。

4.3 终端与表格类：唯一代码块、报错行为、状态保持

终端和表格这两个角色，本质是结构化输出，参数重点是“唯一性”和“状态”。

终端角色的关键参数是报错行为。命令不存在时，是原样返回 shell 的错误信息，还是用中文解释？必须选一个并写清。我一般写“错误信息按 shell 原始输出返回，包括命令名和退出提示，不翻译不解释”。表格角色则要写清“只回复表格，不写前后语”，以及列名固定、行数上限。

状态保持是另一个参数。下棋类角色需要模型在每轮维护棋盘，指南里那条明确要求“在你采取行动之前，请确保你在脑海中更新了棋盘状态”。这个思路可以搬到任何有状态的终端会话里：每轮开头先输出当前状态摘要，再执行动作。多花几行输出，换来的是长对话不跑偏。

4.4 评审与写作类：评分维度与修改边界

评审类角色，比如技术评审、代码评审，参数核心是评分维度和修改边界。维度要列死，三到五条，每条给判定标准。修改边界要写清是“只指出问题”还是“指出并给改法”，两者混着来，输出会又长又散。

写作类角色相反，要放宽。指南里小说类模板给的是情境指令而不是硬约束，比如“写一本拥有出人意料结局的推理小说”。这类角色如果加太多“不要写什么”的约束，输出会变得干瘪。我的做法是只锁三样：篇幅、视角、结局类型，其余放开。

下面这张表是我现在用的参数对照，可以直接照着填：

5. 避坑：角色扮演提示词最容易翻车的五个地方

下面五条都是我在实际用这份指南的过程中踩过的，每条按现象、原因、解决写，能对号入座就省一轮返工。

5.1 角色漂移：聊到第十轮它开始“帮你总结”

现象：前五轮还是严格的终端输出，第六轮开始出现“以上是命令的执行结果，如果你需要我可以继续”，角色彻底散了。

原因：长对话里早期指令的权重会衰减，而模型天生倾向于在对话末尾做一次“有用的收尾”。你越是不写“不要总结”，它越觉得总结是加分项。

解决：在角色卡里加一条“无论对话多长，都不在输出末尾添加总结、建议或追问”。另外每五到八轮重贴一次角色卡，或者在关键轮次前用一句话重申约束，比如“继续，保持唯一代码块输出”。

5.2 输出格式失守：代码块外总多一行字

现象：要求只回代码块，它回“好的，以下是输出：”再加代码块。内容没错，但脚本一解析就报错。

原因：格式约束写成了正向描述，比如“请用代码块输出”。正向描述允许“顺便说一句”，否定描述才封得住。

解决：改成“除代码块外不输出任何字符，包括标点”。再加一句惩罚性说明：“代码块外出现任何文字，本次回复视为无效”。实测这一句能挡掉大部分多余输出。

5.3 知识幻觉被角色掩盖：它用角色的口吻编数据

现象：让它扮演数据分析师，它给出一段很像真的统计结论，数字精确到小数点后两位，但根本没有数据源。

原因：角色设定越具体，模型越倾向于“演得像”。它把“扮演专家”理解成“输出专家会说的话”，而不是“只输出有依据的内容”。

解决：在身份段里加一句“没有数据支撑时，明确说无法给出数值，不要估算”。涉及数字的角色，一律要求标注来源或标“示例值”。这一条不加，输出看起来越专业越危险。

5.4 长文档输入被截断，后半段凭空续写

现象：丢一份长文档进去让它校对，前几段改得很细，后面开始出现原文根本没有的段落。

原因：输入超长被截断，模型看不到后半段，又因为角色要求“完整输出”，就用已有内容续写补全。

解决：分段处理，每段带序号，输出里必须回显段号。角色卡里加一条“若输入未包含段号 X 之后的正文，明确报告缺失，不要续写”。这条对翻译、校对、评审三类角色都适用。

5.5 模板直接抄不改：角色能用，但不好用

现象：从 PDF 里复制一段面试官模板直接用，问了三个问题就发现它一直在问同一个层次的东西，深不下去。

原因：指南里的模板是通用骨架，缺项目上下文。它不知道你招什么岗位、什么级别、看重什么能力。

解决：抄骨架，不抄内容。把身份段里的“Android 开发工程师面试官”换成具体方向，把评分维度换成你团队真实的考察项，把追问深度设成具体层数。模板提供的是结构，参数必须自己填。

6. 冒烟测试：三组输入把一条约束验穿

角色卡改完，我很少直接拿去干活，先跑一遍冒烟测试。所谓冒烟测试，就是拿三组输入验证最容易被破坏的那条约束，通过了再上正式任务。这套习惯是从一次翻车里长出来的：当时改了一条翻译角色的术语表规则，看着没问题，结果整批文档里的接口名全被译成了中文，返工花了半天。

测试脚本不用复杂，把检查项写成字典，人工看输出打勾就行：

# smoke_test.py CASES = { "normal": "把这段技术文档译成中文：The service retries three times before failing.", "boundary": "把这段译成中文：调用 /api/v1/orders 时设置 retry=3。", "violate": "顺便评价一下这段英文写得好不好。", } CHECKS = { "normal": ["包含译文小节", "retries 译为重试而非重试次数"], "boundary": ["路径 /api/v1/orders 原样保留", "retry=3 未被翻译"], "violate": ["拒绝评价", "仅返回译文三节"], } for name, prompt in CASES.items(): print(f"=== {name} ===") print(prompt) print("检查：", "；".join(CHECKS[name]))

CASES三组分别对应正常、边界、越界，覆盖的是约束最容易被冲破的三个方向。CHECKS里每一条都必须是可肉眼判断的，写成“译得准确”就没法用了。这个脚本不调用接口，只负责把测试输入和检查项打出来，实际对话在网页端或自己的调用脚本里跑，跑完对着检查项打勾。

三个 case 里，violate那组最值得花时间。它模拟的是真实使用中用户突然提出角色范围外的请求，角色扛不扛得住，基本在这一组见分晓。我现在的判定标准很粗暴：violate组只要有一次没拒绝，这条角色卡就不算通过，回去改约束。

还有一个我常加的检查：把同一组输入连跑三次，看输出结构是否一致。三次里小节顺序变了、代码块数量变了，说明输出契约写得不够硬，得回去补“必须包含以下小节”那一条。

从那以后我每加一条约束、每换一个角色，都强制先跑这三组输入再投产，哪怕只是改了一个词。角色卡看着简单，改动的连锁反应一点不比代码少。希望帮到你。

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