★ FEATURED ARTICLE 简介这份资源面向需要高频调用 ChatGPT 的职场人、内容创作者与 AI 应用开发者整理了 260 条中文提示语覆盖计算机、心理学、健康等多个行业与领域的角色设定帮助使用者快速切换身份语境减少反复调试提示词的时间成本。压缩包内共 1 个文件为 json 格式体积约 40KB结构轻量便于直接导入或二次编辑适合作为个人提示词库的起步模板。资源中列举了 UX/UI 开发人员、开发者关系顾问、IT 架构师、全栈软件开发人员、高级前端开发人员、心理健康顾问、心理学家、私人厨师、人生教练、牙医、虚拟医生等角色示例可据此延伸出更多细分场景的对话指令。目前已有 1058 人学习下载说明其在提示词入门与角色调教方面具备一定参考价值。读者可从中获得一套可直接套用的中文角色提示语集合用于写作、咨询、编程辅助与日常问答等场景并在此基础上按自身行业需求增补或改写逐步形成个性化的提示词工作流。1. 从 260 条 ChatGPT 中文提示语说起一套能直接抄的提示词库到底长什么样很多人第一次接触 ChatGPT 中文提示语都是从收藏夹里那几十条「万能模板」开始的写文案、改简历、做表格、翻译润色复制粘贴就能用。但真到项目里你会发现单条提示词解决不了连续任务——写一份完整的产品需求文档需要先定角色、再拆结构、再逐段生成、最后自检中间任何一步跑偏后面全崩。这也是为什么「260 条 ChatGPT 中文提示语ChatGPT Prompts、提示词、命令、调教语」这类打包资源一直有市场它把散落在各处的提示词按场景归类形成一套可检索、可组合、可迭代的提示词库。这篇笔记不讨论资源包里具体是哪 260 条而是把「提示词库」这件事拆开讲清楚一套能落地的中文提示词体系应该怎么设计、怎么组织、怎么在本地跑通验证、参数怎么调、哪些坑会让你的提示词从「神器」变「玄学」。适合两类人一是手里已经有一批提示词但用不出稳定效果的从业者二是想自己搭一套提示词管理流程的开发者。读完你应该能判断这个方向值不值得投入以及怎么用最小成本先跑起来。2. 提示词库的工程化拆解从「调教语」到可复用资产2.1 为什么单条提示词撑不起真实任务单条提示词的本质是一次性指令它假设模型能在一轮对话里理解全部上下文并给出终态结果。但真实任务往往是多阶段的需求澄清、结构设计、内容生成、格式校验、风格统一。每一阶段的输入依赖上一阶段的输出且每阶段对模型的要求不同——有的阶段要发散有的阶段要收敛有的阶段要严格按 schema 输出。把 260 条提示词平铺在一个 txt 里用的时候靠关键词搜索这是「收藏夹思维」。工程化思维要求每条提示词有明确的输入契约、输出契约和适用边界。比如一条「会议纪要生成」提示词输入应该是原始记录文本加参会人列表输出应该是固定字段的 JSON 或 Markdown 表格而不是一段自由发挥的总结。没有契约模型每次给你的格式都不一样后续想自动化处理就得写一堆容错代码。我一般会把提示词分成三层原子提示词单点任务如「提取关键词」、组合提示词多步串联如「先提取关键词再生成摘要」、场景模板带变量占位符的完整工作流。260 条这个量级如果按三层拆真正能独立复用的原子提示词可能只有 60 到 80 条其余都是组合和场景变体。理解这一点你才不会盲目追求数量。2.2 提示词文件的目录结构与命名规范一套可维护的提示词库目录结构比内容本身更重要。常见做法是按「场景域 / 任务类型 / 具体提示词」三级组织文件名带版本号和语言标记。下面是我在本地用的结构直接可以抄prompts/ ├── writing/ │ ├── outline_v2_zh.md │ ├── polish_v1_zh.md │ └── summarize_v3_zh.md ├── coding/ │ ├── code_review_v1_zh.md │ ├── unit_test_gen_v2_zh.md │ └── sql_optimize_v1_zh.md ├── analysis/ │ ├── data_clean_v1_zh.md │ └── report_gen_v2_zh.md └── _shared/ ├── role_prefix_zh.md └── output_schema_json.md命名规范的核心是「看到文件名就知道干什么、什么版本、什么语言」。outline_v2_zh.md比大纲提示词最终版.md强在可排序、可 diff、可脚本批量处理。_shared目录放公共片段比如角色设定前缀、输出格式约束组合提示词时用引用方式拼接避免每条都重复写一遍「你是一个资深编辑」。每个 md 文件内部建议用固定 front matter 加正文的结构--- id: outline_v2 domain: writing input: topic, audience, word_count output: markdown_list version: 2 updated: 2025-01 --- 你是一位有十年经验的中文内容策划……front matter 里的input和output字段就是契约。写脚本调用时先解析 front matter 校验输入是否齐全再拼接正文发给模型。这一步能挡掉大量「参数没传全导致输出跑偏」的问题。2.3 用 Python 把提示词库跑起来的最小脚本光有文件不够得有一个加载器把提示词读进来、填充变量、调用模型、校验输出。下面是一个最小可用脚本依赖openai库和pyyaml不绑定任何特定平台你换成任何兼容接口都能跑import os import re import yaml from openai import OpenAI client OpenAI(api_keyos.getenv(API_KEY), base_urlos.getenv(BASE_URL)) def load_prompt(path): 读取 md 文件分离 front matter 和正文 with open(path, r, encodingutf-8) as f: raw f.read() match re.match(r^---\n(.*?)\n---\n(.*)$, raw, re.S) if not match: raise ValueError(f缺少 front matter: {path}) meta yaml.safe_load(match.group(1)) body match.group(2).strip() return meta, body def render(body, variables): 把 {{var}} 占位符替换成实际值缺失则报错 def repl(m): key m.group(1).strip() if key not in variables: raise KeyError(f缺少变量: {key}) return str(variables[key]) return re.sub(r\{\{(.?)\}\}, repl, body) def run(prompt_path, variables, modelgpt-4o-mini, temperature0.3): meta, body load_prompt(prompt_path) required [x.strip() for x in str(meta.get(input, )).split(,)] missing [k for k in required if k and k not in variables] if missing: raise ValueError(f输入契约不满足缺少: {missing}) final_prompt render(body, variables) resp client.chat.completions.create( modelmodel, temperaturetemperature, messages[{role: user, content: final_prompt}], ) return resp.choices[0].message.content if __name__ __main__: out run( prompts/writing/outline_v2_zh.md, {topic: 提示词库工程化, audience: 一线工程师, word_count: 3000}, temperature0.4, ) print(out)逻辑说明load_prompt负责解析 front matter把元数据和正文分开render做变量替换缺变量直接抛异常而不是让模型猜run先校验输入契约再调用模型。参数方面temperature在结构化任务里建议 0.2 到 0.4太高会导致输出格式漂移model按你的预算和任务复杂度选大纲类任务用轻量模型就够代码审查类建议用强模型。BASE_URL和API_KEY从环境变量读不要硬编码在脚本里。这个脚本只有几十行但它把「提示词库」从一堆文本变成了可编程资产。你可以在此基础上加缓存、加批量跑、加输出 schema 校验逐步长成自己的提示词流水线。3. 260 条提示词的分类与调教语设计让输出稳定可预期3.1 按任务类型分类写作、编程、分析、对话四象限260 条提示词如果混在一起检索成本极高。我一般按四象限分写作类文案、报告、邮件、润色、编程类代码生成、审查、测试、SQL、分析类数据清洗、归因、竞品、摘要、对话类角色扮演、客服、访谈、头脑风暴。每个象限内部再按「输入形态」细分——纯文本输入、结构化数据输入、多轮对话输入。分类的意义在于复用公共片段。写作类几乎都需要「语气控制」和「结构约束」编程类都需要「语言版本声明」和「边界条件说明」分析类都需要「数据口径定义」。把这些公共要求抽到_shared里每条提示词只写差异部分维护量能降一半。一个容易踩的坑是分类过细。有人把「小红书文案」和「公众号文案」分成两类其实底层都是「平台风格 字数限制 钩子结构」差异只是参数。正确做法是合并成一条带platform变量的提示词用变量区分而不是复制两份。260 条里如果有大量这种伪差异实际有效条目会缩水很多。3.2 调教语的三段式结构角色、约束、示例「调教语」这个词听起来玄拆开就是三件事让模型知道它是谁、不能做什么、好的输出长什么样。我用的三段式结构是第一段角色设定一句话说清身份和经验边界。比如「你是一位有八年经验的中文技术编辑熟悉开发者读者的阅读习惯」。不要写「你是最厉害的 AI 助手」这种空话角色越具体输出越稳。第二段约束条件用列表写清硬性要求字数范围、必须包含的字段、禁止出现的表达、输出格式。约束要可验证比如「每个小节不超过 200 字」比「简洁一点」强「输出必须是合法 JSON」比「尽量结构化」强。第三段示例给一个输入输出对。示例是调教语里性价比最高的部分——一个具体例子胜过三句抽象描述。示例要覆盖边界情况比如空输入、超长输入、多语言混合输入让模型知道这些情况怎么处理。你是一位有八年经验的中文技术编辑熟悉开发者读者的阅读习惯。 约束 - 输出为 Markdown二级标题不超过 5 个 - 每个小节 150 到 250 字 - 禁止使用「综上所述」「随着发展」等套话 - 必须包含至少一个可执行命令或代码片段 示例输入主题Redis 持久化读者后端新手 示例输出 ## 1. RDB 和 AOF 到底选哪个 ...参数上示例的长度建议控制在 200 字以内太长会挤占上下文预算。如果任务复杂宁可拆成两条提示词串联也不要把示例堆到 1000 字。3.3 用变量占位符实现一条提示词多场景复用变量占位符是提示词库从「死文本」变「活模板」的关键。常见变量包括{{topic}}、{{audience}}、{{tone}}、{{word_count}}、{{format}}、{{examples}}。设计变量时要注意两点一是变量名用英文小写下划线避免中文变量名在脚本里出编码问题二是每个变量在 front matter 的input里声明调用时强制校验。下面这条提示词演示了如何用变量覆盖多个写作场景--- id: content_gen_v3 domain: writing input: topic, audience, tone, word_count, format output: markdown version: 3 --- 你是一位中文内容创作者面向 {{audience}} 写作。 主题{{topic}} 语气{{tone}} 字数{{word_count}} 输出格式{{format}} 要求 1. 开头用一个具体场景或反直觉结论切入 2. 中间至少两个小节每节有可操作细节 3. 结尾落到一个具体技巧不要总结调用时传不同变量就能生成技术文、产品文案、教学材料。tone可以传「口语化」「正式」「犀利」format可以传「markdown」「纯文本」「json」。这样一条提示词顶过去五六条260 条里真正需要独立维护的可能不到 100 条。提示变量值里如果包含特殊字符如花括号、反斜杠在替换前先做转义否则会破坏模板结构。我一般用str.replace而不是正则替换变量值避免二次解析。4. 本地跑通与效果验证提示词到底有没有用怎么测4.1 搭建最小测试集20 条输入覆盖 5 类边界提示词改完不测等于没改。我的习惯是每个提示词配一个最小测试集20 条输入覆盖五类边界正常输入、空输入、超长输入、多语言混合、格式异常输入。正常输入验证基本功能空输入验证容错超长输入验证截断策略多语言验证语言一致性格式异常验证解析健壮性。测试集用 JSONL 存每行一条{id: t01, vars: {topic: Redis 持久化, audience: 后端新手, tone: 口语化, word_count: 800, format: markdown}, expect: 包含 RDB 和 AOF 对比} {id: t02, vars: {topic: , audience: 后端新手, tone: 口语化, word_count: 800, format: markdown}, expect: 提示输入为空或要求补充}expect字段写人工可判断的预期不要写「输出质量好」这种没法验证的话。跑测试时逐条调用人工过一遍或写简单规则校验比如检查是否包含关键词、是否合法 JSON、字数是否在范围内。4.2 用脚本批量跑并记录通过率手工测 20 条还行提示词一多就必须自动化。下面脚本读 JSONL 测试集逐条跑记录输出和简单校验结果import json from your_loader import run # 复用 2.3 的 run 函数 def check(output, expect): 极简校验expect 里的关键词是否出现 if not expect: return True return all(kw in output for kw in expect.split(、)) def batch_test(prompt_path, test_file): passed, failed 0, [] with open(test_file, r, encodingutf-8) as f: for line in f: case json.loads(line) try: out run(prompt_path, case[vars]) ok check(out, case.get(expect, )) except Exception as e: out, ok str(e), False if ok: passed 1 else: failed.append({id: case[id], out: out[:200]}) total passed len(failed) print(f通过率: {passed}/{total} {passed/total:.1%}) for item in failed: print(f失败 {item[id]}: {item[out]}) return failed if __name__ __main__: batch_test(prompts/writing/content_gen_v3.md, tests/writing.jsonl)参数说明check函数故意写得简单因为自动评估输出质量很难关键词校验只能挡明显错误。真正判断质量还是靠人工抽检。通过率低于 80% 的提示词回去改约束或加示例不要靠调 temperature 硬凑。failed列表保留失败样本改完提示词后重跑对比通过率变化。4.3 对比实验同一任务下不同提示词的输出差异想知道一条提示词是不是真的比另一条好得做对比实验。方法很简单同一批输入分别用 A、B 两条提示词跑输出并排看。我一般关注四个维度结构一致性每次输出格式是否相同、信息密度有没有废话、边界处理异常输入是否合理响应、可解析性能不能被脚本直接消费。对比时固定模型和 temperature只改提示词否则变量太多说不清。如果 A 在结构一致性上明显好但信息密度低可以把 A 的结构约束和 B 的内容要求合并生成 C 版本再测。这个迭代过程通常两三轮就能收敛。注意对比实验不要只看一次输出。模型有随机性同一提示词跑三次可能结果不同。建议每个组合跑三次看稳定性而不是拿单次结果下结论。5. 避坑与排查提示词用不出效果的五个血泪教训5.1 现象输出格式每次都不一样脚本解析总失败原因提示词里只写了「输出 JSON」但没给 schema也没给示例。模型对 JSON 的理解每次都可能不同字段名、嵌套层级、是否带 markdown 代码块包裹都不确定。解决在提示词里写死字段名和类型并给一个完整示例。更稳的做法是用 JSON schema 约束输出如果接口支持response_format就开启。脚本侧加一层容错先尝试直接解析失败则用正则提取第一个{...}块再解析。5.2 现象中文提示词效果不如英文模型像没看懂原因部分模型对中文长指令的遵循度确实弱于英文尤其是涉及复杂约束和多层嵌套时。另外中文标点混用全角半角也会干扰解析。解决关键约束用中英双语写一遍或者把结构约束部分用英文写、内容部分用中文写。标点统一用全角中文标点代码和变量名保持半角。实测这个改动能明显提升约束遵循率。5.3 现象提示词越写越长效果反而变差原因上下文里指令太多模型注意力被稀释重要约束被淹没。常见于把十几条要求堆在一条提示词里。解决拆。把一条长提示词拆成两到三条串联每条只负责一个阶段。或者用「优先级标记」把必须遵守的约束放最前面用「必须」标注次要要求放后面。我一般控制单条提示词正文在 500 字以内超过就考虑拆。5.4 现象同一提示词昨天好用今天翻车原因模型版本更新、接口默认参数变化、或者你的输入数据分布变了。提示词不是一劳永逸的资产它依赖模型行为。解决给提示词加版本号和更新日期模型或接口变更后重跑测试集。测试集通过率下降超过 10% 就触发复查。另外把 temperature、max_tokens 这些参数显式写死在调用代码里不要依赖接口默认值。5.5 现象变量替换后提示词结构被破坏原因变量值里包含{{、}}、反斜杠或换行替换时破坏了模板语法或 YAML front matter。解决替换前对变量值做转义把{{替换成安全占位符替换后再还原。或者改用string.Template的$var语法冲突概率低一些。front matter 里的变量值如果含冒号用引号包起来避免 YAML 解析错误。6. 进阶把 260 条提示词变成可检索、可组合的个人提示词系统走到这一步你已经有了分类、模板、测试和排错能力。最后分享一个我用了两年的习惯给提示词库加一个检索层和组合层让它从「文件夹」变成「系统」。检索层用一个简单的 SQLite 表存元数据支持按 domain、input 类型、output 格式、版本筛选CREATE TABLE prompts ( id TEXT PRIMARY KEY, path TEXT NOT NULL, domain TEXT, input_types TEXT, output_format TEXT, version INTEGER, updated TEXT, pass_rate REAL ); -- 查所有写作类、输出 markdown、通过率高于 0.9 的提示词 SELECT id, path, pass_rate FROM prompts WHERE domain writing AND output_format markdown AND pass_rate 0.9 ORDER BY updated DESC;pass_rate字段由 4.2 的批量测试脚本回写这样你能一眼看出哪些提示词在退化。input_types存逗号分隔的输入类型方便按「我手里有结构化数据」这种条件反查。组合层用 YAML 定义工作流把多条提示词串起来name: weekly_report steps: - id: clean prompt: analysis/data_clean_v1_zh.md input: raw_data - id: summarize prompt: writing/summarize_v3_zh.md input: clean.output - id: format prompt: writing/polish_v1_zh.md input: summarize.output vars: tone: 正式每一步的input引用上一步的outputvars覆盖默认变量。写一个几十行的执行器按顺序跑中间结果落盘失败可断点重试。这套东西不复杂但它把「复制粘贴提示词」变成了「调用工作流」效率差距是数量级的。一个具体技巧给每条提示词记录「最佳 temperature」和「推荐模型档位」。结构化任务 0.2 到 0.3创意任务 0.6 到 0.8代码任务 0.1 到 0.2。模型档位按任务复杂度分三档简单分类用轻量模型生成用中档审查和推理用强模型。这个映射表贴在检索层里调用时自动带出参数省得每次纠结。我自己的教训是早期太迷信提示词数量收藏了上千条真正常用的不到 30 条。后来把精力从「收集」转到「测试和组合」同样一批提示词产出质量翻了一倍不止。提示词库的价值不在条数在于你能不能稳定地、可预期地把它用起来。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
