第 7 章　通用设计框架与模式

结构回答“怎么组织”，框架回答“想全了没有”。面对一个全新任务，背景、目标、风格、受众、输出格式这些要素怎么一次想齐，靠灵感不可靠，靠清单才稳，这正是通用设计框架要解决的问题。这一章拆解三个经过大量实践检验的框架，均衡全能的 CO-STAR、重背景洞察的 CRISPE、执行纪律严明的 RISEN，逐个看设计意图与适用场景，再看不同模型对框架的偏好差异，最后用三种框架重构同一个 Prompt 做一场对照实验。读完这一章，手里会多几套拿来即用的设计框架。

7.1 为什么需要固定清单

先聊一个很多程序员都经历过的现象。很多刚入行的程序员，初学编程时特别讨厌甚至鄙视“框架”。他们觉得 Spring Boot、Django、React 这些东西条条框框太多，束手束脚，限制了他们的“创造力”。他们更崇尚“自由”，喜欢从一个空白的 main 函数开始，一口气写到底，觉得那样才叫“功夫”，才叫“硬核”。

结果呢？十有八九，他们写出来的代码质量很差。逻辑互相纠缠，变量随意命名，函数一个比一个长，过两个月别说让同事接手了，连自己都看不懂当初写的是个啥。最后，在 Bug 把人折磨到深夜、经历一次次推倒重构之后，大多数人会醒悟过来，乖乖地回去 npx create-react-app，然后承认：“真香！”

写 Prompt，也是一模一样的道理。

上一章学会了用分隔符、用 LangGPT 这样的范式给 Prompt 建立基本结构，但这只解决了“怎么组织”，还没解决“想全了没有”。当面对一个全新的、棘手的、毫无头绪的复杂任务时，很可能不知道从哪里下手，因为脑子里没有一份明确的要素清单。

此刻心里可能在想：“又来了，是不是又要给我灌输一套复杂的方法论？我就想简单点写个 Prompt 不行吗？”

完全理解这种抵触。但接下来要聊的东西，不是为了把简单问题复杂化，恰恰相反，是为了给复杂问题提供一个思维的脚手架（Scaffolding）。

通用设计框架，就是这个脚手架。它不是要取代思考，更不是要禁锢创造力，核心价值在于引导思考，在大脑一片混沌的时候，给出一条清晰的路径。它把一个经验丰富的老工程师会问的问题列成了清单：“背景搞清楚了吗？”、“目标是什么？”、“给谁看的东西想好了吗？”……它提供了一套固定的“思考模板”或者说“问题清单”，用一种近乎强制的方式，确保设计 Prompt 时不会遗漏任何一个关键要素。

可能有人会觉得：“这不就是‘八股文’吗？太死板了！”

没错，它在形式上确实非常像“八股文”。但换个角度想，正是这套固定结构，让 Prompt 变得可以对照评估。拿到别人写的 Prompt，不用逐段猜测设计意图，只需要按照固定结构逐项核对，就能高效地、相对客观地判断出，哪一份的逻辑更严谨、要素更完备、知识储备更扎实。

在 Prompt Engineering 这个全新的领域里，框架的作用也是如此，甚至更为重要。

它能帮助避免遗漏，兜住下限。对着一个框架（比如后面要讲的 CO-STAR）的清单逐项思考，Context、Objective、Style、Tone、Audience、Response……就很难遗漏前几章反复强调的那些核心要素。它提供的就是一份检查清单（Checklist），一项一项确认过去，保证写出来的 Prompt 下限不会太低。

它能极大地提升效率。不再需要每次都从一个空白的文本框开始，痛苦地、毫无头绪地冥思苦想，而是有了一个固定的起点、一条清晰的路径。先按框架把要素填齐，正式编写时就有条不紊，不用来回返工。

它为团队协作与知识传承提供了可能。当团队里所有人都使用同一个框架来设计和文档化 Prompt 时，沟通成本会大大降低，拿到同事写的 CO-STAR 格式的 Prompt，立刻就能明白设计意图，知道去哪里找核心逻辑、去哪里修改约束规则。这套固定格式，成了团队的“通用语言”，让 Prompt 第一次拥有了作为“工程资产”来管理和传承的潜力。

还有最重要的一点，一个好的框架，会逼着人做更深度的思考，去想一些平时凭“直觉”容易忽略的问题。比如 Audience（受众）这个要素，很多工程师写 Prompt 时根本不会考虑，但框架把它作为一个必填项，不写完这一项就过不去。仅仅是多这一层思考，可能就会让 Prompt 效果产生质的飞跃。

所以，请暂时放下对“条条框框”的抵触。框架不是用来捆住手脚的，它汇总的是前人的经验，给出的是处理复杂问题的现成路径。它们不能代替思考，但能让人想得更全、更稳、更快。

7.2 没有万能框架，只有场景匹配

好了，既然框架这么重要，市面上有哪些主流的框架？到底该选哪个？是不是有一个“最好”的框架，学会了就能一劳永逸？

这就像是问：“我该学 Python、Java 还是 Go？”答案永远是：“看场景。”

不同的框架有不同的设计哲学，侧重点也各不相同，各有各的适用场景，选错了框架，效果会打折扣。

这里介绍三个目前在社区里比较流行、也经过了大量实践检验的框架：CO-STAR、CRISPE 和 RISEN。目标不是死记硬背，而是理解每个框架背后的“设计意图”，这样在实际工作中，才能根据任务类型，选出最合适的那个框架。

CO-STAR 框架：均衡通用的首选

先从 CO-STAR 聊起。如果只需要精通一个框架，那毫无疑问是它。CO-STAR 来自新加坡政府科技局（GovTech）的数据科学与 AI 团队，2023 年 GovTech 办首届 GPT-4 提示工程大赛时，参赛者 Sheila Teo 用这套框架拿了冠军，赛后把方法论整理成文章，这个框架才流传开来。它是目前应用最广泛、最均衡、也最贴近工程师思维的一个框架，不一定在某一项上做到极致，但无论什么类型的任务交给它，都能得到稳定可用的结果。

来看看它的构成。Context（上下文）问的是任务的背景信息是什么；Objective（目标）问的是需要完成的具体任务是什么。再往下，Style（风格）问的是写作的风格是怎样的；Tone（语气）问的是语气是怎样的；Audience（受众）问的是这份输出是给谁看的；Response（响应格式）问的是输出的格式是什么。

CO-STAR 本质上是一份通用的任务清单，没有太多务虚的、哲学层面的东西，而是非常关注“怎么做”的每一个具体细节。它把 Style（风格）和 Tone（语气）单独拎出来，强调文本风格的重要性；把 Audience（受众）作为一个核心要素，强制思考沟通对象；用 Response（响应格式）明确输出格式，完美契合了把 Prompt 当工程组件来用的需求。

CO-STAR 几乎适用于所有类型的任务。无论是写一封商务邮件、生成一段符合规范的代码、从财报里提取数据，还是做点简单的内容创作，用 CO-STAR 来组织思路，都不会出错。它就像一份详尽的“需求规格说明书”，确保模型在动工前清楚地知道每一个细节要求，给出稳定、可靠的输出。

CRISPE 框架：重洞察与创意的框架

CO-STAR 虽然可靠，但有些任务要的不是按部就班的执行，而是有深度的分析和创意。这时候，就该请出 CRISPE 框架了。

来看看它的构成。Capacity and Role（能力与角色）先问角色是谁、能做什么；Insight（洞察）问的是背景知识是什么、为什么这个任务重要；Statement（指令）问的是具体要做什么；Personality（个性）问的是说话风格和语气是怎样的；Experiment（实验）最直接，要求一次给出几个不同方案供挑选。

仔细看 CRISPE 的侧重点，是不是和 CO-STAR 完全不同？它非常强调前期的思考和背景铺垫，Insight（洞察）是它最核心的要素，不仅告诉模型“做什么”，还要花大量的篇幅告诉它“为什么要做”。

这就像给一个战略顾问布置任务，不能只丢一句“给我写个市场分析报告”，得花时间把背景讲清楚：“王老师，我们公司最近遇到了增长瓶颈，用户活跃度连续三个月下滑，我们怀疑是新出的那个竞品‘快信’抢了我们的市场份额。管理层现在很焦虑，需要您这份报告来帮我们看清局势，找到破局点，这份报告直接关系到我们下个季度的战略投入方向。”

把 Insight 讲得如此透彻，模型就能更好地理解任务的来龙去脉和真实诉求，给出的分析报告不会是网上抄来的数据罗列，而是真正有深度、能切中要害的策略建议。

同时，Experiment（实验）这个要素也很有特色。它要求模型不要只给一个“标准答案”，而是提供多种可选方案。这在需要创意的场景下，往往能带来意外的收获。

所以，CRISPE 特别适合那些开放式的、需要深度思考和创造性的任务。比如制定一份商业计划书、构思一个全新的产品功能，或者为一场重要的发布会写一篇演讲稿时，用 CRISPE 框架，得到的可能不仅仅是一个答案，更是一份灵感。

一句话总结，CO-STAR 像是在和一个“高级工程师”对话，给他提需求；而 CRISPE 则像是在和一个“策略顾问”对话，希望他不仅能执行，还能给出判断和建议。

RISEN 框架：重步骤与约束的执行框架

均衡型和创意型都有了，那如果接到的活是“按规程办事”呢？比如处理一批退款工单，先核什么、后查什么、什么情况必须转人工，每一步都是规定动作，越界就是事故。这时候，需要的是把步骤和边界都明确写死的 RISEN 框架。

来看看它的构成。Role（角色）设定 AI 扮演的身份和专长；Instructions（指令）写清核心任务，并把任务相关的关键信息一并给到；Steps（步骤）把完成任务的流程拆成有序步骤；End Goal（终点目标）定义任务完成时应达成的状态，写清做到什么程度算合格；Narrowing（约束收窄）划定禁区，写明哪些事不许做、哪些内容不许出现。

RISEN 这个框架，最突出的特点就是执行纪律。它不太管风格和文采，把重点都放在了 Steps 和 Narrowing 这两个要素上，前者替模型把执行顺序排好，一步不乱；后者把不许做的事列清楚，一条不让。社区里拿它写 Agent 系统提示的工程师，把这样的 Prompt 称为一份“行为契约”，模型收到的不只是一个任务，还有路线和禁区。

这就像给运维工程师派活排查线上故障，不能只在群里 @ 一下，说“网站崩了，快去修”，得把一份标准的“派工单”发过去：Role（你是负责订单服务的 SRE）、Instructions（处理这批 502 报警，报警时间、监控截图和最近上线记录都附在单子上）、Steps（先看变更记录，再查依赖服务，最后定位根因）、End Goal（给出根因结论和恢复方案）、Narrowing（只分析本服务，不猜测其他团队的问题，不给未经验证的结论）。有了这份派工单，他照单执行就行，不用边修边猜。

所以，RISEN 特别适合那些流程明确、约束繁多、出错代价高的执行型任务。比如，故障排查、工单处理、合规检查、批量数据清洗。在这些场景下，创造力不重要，风格不重要，每一步都对、每一处都不越界，才是压倒一切的。

总结与建议：先精通一个，再按需切换

讲完了这三种定位不同的框架，可能有点晕，感觉选择困难。别担心，不需要把它们都背下来。

给出的建议是，先精通一个、了解其他。把 CO-STAR 作为主力框架，用它处理 80% 的日常工作，练到滚瓜烂熟。日常之外再按需切换，遇到需要深度分析的策略类任务时，换 CRISPE 补足背景洞察；处理一个步骤多、约束杂的执行型任务时，用 RISEN 的清单检查一下步骤排全了没有、禁区列全了没有。

而最高级的用法是融合与定制。把这些框架的优点融合起来，甚至根据具体的业务场景，定制出一套自己的框架。比如在 CO-STAR 的基础上，增加一个 CRISPE 的 Insight 模块，让日常任务也带上背景铺垫；或者增加一个 RISEN 的 Narrowing 模块，给任务划清禁区边界。

最终，框架应该内化成思维习惯，而不是变成负担。是人在用框架，不是框架在用人。

7.3 CO-STAR 框架的实战拆解

在所有的框架里，CO-STAR 最适合初学者和工程师首先掌握，因为它足够全面、足够通用，而且足够简单直观，先掌握它，再学其他框架会容易得多。

这一节就把 CO-STAR 从里到外拆开来讲，看看每一个字母背后对应哪些前面章节提过的核心原则，实战中该怎么填充，又有哪些常见的坑。

还是用一个具体的场景来贯穿始终。

场景是这样的。团队开发了一款新的笔记软件，叫“思流笔记”，现在需要利用 AI，为这款软件在手机应用商店的详情页写一段吸引人的介绍文案。

不用框架的话，可能会直接写：“帮我写个‘思流笔记’的应用商店介绍文案。”结果可想而知，大概率是一段平平无奇、毫无吸引力的文字。

现在，按 CO-STAR 的六个要素一步步来填，看看最后能得到什么。

C - Context (上下文)：交代任务的背景信息

Context 是整个 Prompt 的基础，要在这里把背景信息讲清楚，回答一个核心问题：“我们现在在哪？发生了什么？为什么要做这件事？”

很多新手在写 Context 时，容易犯两个错误，要么写得太少，信息不足，要么写得太多，全是废话。

一个好的 Context，应该像一篇优秀新闻报道的导语，简洁、精准，直击要害。填充 Context 时，可以从这几个角度去思考。先想产品/业务背景，这是个什么东西？它的核心价值主张是什么？它最与众不同的地方在哪里？再想市场环境/用户痛点，它解决了用户的什么“切肤之痛”？它的主要竞争对手是谁？和竞品的核心差异是什么？还有当前状况，为什么要做这件事？是为了拉新？还是为了宣传新功能？

对于“思流笔记”这个场景，一个精心打磨过的 Context 可能是这样的：

C (Context): 我们即将发布一款名为“思流笔记”的全新笔记软件。它的核心设计理念是“卡片式笔记”和“双向链接”，旨在帮助用户摆脱传统线性笔记的束缚，构建一个真正属于自己的、网状的知识图谱。目前市面上的主流笔记软件（如印象笔记、有道云笔记）大多还是基于传统的“文件夹-文件”模式，这导致用户的知识被割裂在一个个孤岛里，难以发现深层的联系。我们的目标用户是那些对知识管理有更高要求的学生、研究人员和终身学习者，他们渴望一种能激发思考、促进知识内化的新工具。

来分析一下这段话。它虽然不长，但信息量很大。产品名是“思流笔记”；核心卖点“卡片式”、“双向链接”、“知识图谱”，这些都是后面写文案时可以用的关键词；市场定位通过与传统笔记软件的对比，清晰地定义了产品的差异化优势。用户痛点“知识被割裂”、“难以发现深层联系”，这能让模型在文案中更好地与用户产生共情；目标用户是高知群体、终身学习者，这直接决定了后面文案的语言风格和深度。

有了这样一段扎实的 Context 打底，模型在后面发挥的时候才不容易跑偏，写出来的每一段都能贴着产品的真实卖点走。

O - Objective (目标)：明确交付物与验收标准

Objective 是整个 Prompt 的核心，是“指令”的精确化、工程化表达。在这里要用最清晰、最没有歧义的语言告诉模型：“你具体要做什么？交付物是什么？验收标准是什么？”

在填充 Objective 时，要时刻牢记第 3 章讲过的“清晰度原则”，尤其是其中对动词精确性的要求，并且学会任务拆解。

一个糟糕的 Objective：“写个介绍。” 一个稍微好一点的 Objective：“写一段应用商店的介绍文案。” 一个优秀的 Objective：

O (Objective): 请为“思流笔记”这款应用，撰写一段用于苹果 App Store 详情页的介绍文案。这份文案必须包含三个明确的部分：一个能够瞬间抓住用户眼球的标题（Slogan），一段大约 150 字的核心功能介绍（Feature Introduction），以及一个能够有效引导用户点击下载按钮的行动指令（Call to Action）。

看到区别了吗？优秀的 Objective 把一个模糊的“写介绍”任务，拆解成了三个具体、可执行，甚至可量化的子任务。这不仅让模型的工作更有条理，也让评估结果时有了明确的标准，可以逐项检查：Slogan 够不够吸引人？功能介绍字数达标了吗？行动指令有没有引导性？

这样一来，三个子任务写得清清楚楚，模型照着逐项完成即可。

S - Style (风格)：定文体与参照对象

Style 决定输出文本的文体。它是偏向文学性还是技术性？是叙事体还是议论文？

填充 Style 时，可以想象一下，希望这段文字出现在哪里？是一本严肃的学术期刊，还是一篇活泼的公众号推文？是政府的红头文件，还是朋友间的微信聊天？

应用商店的文案需要一种特殊的风格，既要传达信息，又要勾起欲望。一个合适的 Style 可能是：

S (Style): 整体写作风格要求简洁、有力，富有科技感和启发性。要像苹果官网的文案一样，多使用短句和并列结构，避免使用复杂的从句和生僻词汇。可以适当使用排比、设问等修辞手法来增强文案的节奏感和感染力，但要避免过度浮夸和空洞的形容词。

这里不仅定义了大的风格方向（“科技感”、“启发性”），还给出了一个非常具体的参照物，“像苹果官网的文案一样”。这对模型来说是一个明确的参照，它会调用自己见过的苹果文案写法，模仿那种“苹果体”。同时还给出了具体的、可操作的指示（“多使用短句”、“避免复杂的从句”），“风格”这个抽象的概念就变得可以让模型精确执行了。

T - Tone (语气)：定情绪色彩与态度

Tone 决定文字带有什么样的情绪色彩，传递出什么样的态度。

Tone 和 Style 很容易混淆。Style 更偏向于“结构和文体”，是客观的；而 Tone 更偏向于“情感和态度”，是主观的。

比如，“新闻报道”是一种 Style，它的 Tone 应该是“客观中立”的。“情书”也是一种 Style，它的 Tone 应该是“深情款款”的。

对于这款笔记软件，希望传递一种什么样的情绪呢？不希望它是一个冷冰冰的工具，而希望它是一个能激发用户思考的伙伴。

T (Tone): 语气要充满自信和热情，同时要体现出对知识的尊重和对用户的共情。要让用户感觉到，我们不是在居高临下地推销一个工具，而是在像一个志同道合的朋友一样，真诚地邀请他加入一场激动人心的知识探索之旅。避免使用命令式的语气（如“你必须”），多使用邀请式的语气（如“让我们一起”）

看到没？一个好的 Tone 描述，本身就写明了情绪方向。模型读到“激动人心的知识探索之旅”、“志同道合的朋友”，选择词汇时就会下意识地偏向那些更积极、更有温度、更能拉近与用户距离的词。

A - Audience (受众)：明确写给谁看

这是 CO-STAR 框架里工程师最容易忽略、却至关重要的部分。工程师总是习惯于从自己的视角出发，用自己熟悉的“行话”去描述事物，而忘记了接收信息的人是谁。

明确了 Audience，模型就能自动地调整它的“话术”、用词的“颗粒度”和知识的“深度”。

对于“思流笔记”，Audience 是这样写的：

A (Audience): 主要受众是中国的大学生、研究生、科研人员、程序员、作家等知识工作者。他们对“卡片笔记”、“知识图谱”、“第二大脑”等概念有一定了解，普遍存在“信息过载”和“知识焦虑”的痛点。他们在选择工具时，不仅看重功能，更看重其背后的设计哲学。请在文案中使用他们能够理解并产生共鸣的语言，可以适当引用一些他们圈子里流行的梗，但要避免过于晦涩。

这段话告诉了模型几件关键的事。用户画像方面，是高知群体，而且特别指出了是“中国的”用户，这会影响模型的用词习惯；专业背景方面，他们了解“第二大脑”等概念，这意味着文案里可以直接使用这些词，而不需要解释，能瞬间拉近距离；核心痛点是“信息过载”、“知识焦虑”，这是文案可以猛戳的痛点；价值观方面，他们看重“设计哲学”，这意味着文案可以拔高一个层次，不只谈功能，更要谈理念。

如果没有这一段，模型可能会写出“让记笔记像聊天一样简单”这种更偏向大众用户的文案，那就完全打偏了，无法吸引到核心用户。

R - Response (响应格式)：定死输出模板，防止格式漂移

最后一步，也是保证工程化可用的关键一步。在这里要用最严格、最不容置疑的语言，定义好输出标准。

R (Response): 请严格按照以下 Markdown 格式输出，不要在最终结果的开始或结束部分，包含任何额外的解释、问候或总结性文字。你的输出必须是一个可以直接复制粘贴的完整 Markdown 片段。

# [这里填写你的 Slogan，要求简洁、响亮，不超过 15 个字]

**别再堆文件夹，让知识连成网。**

[这里填写你的核心功能介绍，总字数控制在 150-200 字之间。需要用 2-3 个段落，清晰地介绍“卡片式笔记”和“双向链接”如何帮助用户构建知识网络。]

---

**立即下载“思流笔记”，开启你的知识网络构建之旅！**
[App Store 下载链接]

这个 Response 格式，不仅用自然语言提了要求（“严格按照”、“不要包含”），还给出了一个带占位符和约束条件的模板。

这对于模型来说，是约束力最强的指令之一。模板把每个位置该填什么、有什么限制都写死了，模型要做的就是把内容填进对应位置。这能极大地降低它随意发挥、最终导致格式错误的概率。

拼装与执行：组合并检验效果

好了，现在把这六个模块按顺序拼在一起，就得到一个完整、强大、逻辑清晰的 CO-STAR Prompt。把这个 Prompt 发给模型，输出的文案质量和最开始那个“帮我写个介绍”的 Prompt 相比，差距非常大。

最重要的是，这个 Prompt 是可维护、可迭代、可协作的。如果老板觉得 Slogan 不够响亮，只需要修改 Objective 和 Style 部分，不用动其他地方；如果市场部通过用户调研，发现目标用户定位有偏差，只需要修改 Audience 部分；如果应用商店的排版规则变了，需要输出成 JSON 方便前端动态渲染，也只需要修改 Response 部分。

每一个模块各司其职，高内聚，低耦合。这就是框架带来的工程价值。

7.4 不同模型的偏好与格式敏感性

一个很有趣、也很有实践价值的问题。是不是所有的大模型，都同样“吃”这一套框架？比如，把上面那个精心设计的 CO-STAR Prompt 分别发给 GPT-4 系列、Claude 4 系列和国内主流模型，效果会完全一样吗？

绝对不会。

不同的模型，由于其训练数据的来源、模型架构的细微差异，以及其中最重要的因素，人类对齐策略（Alignment，也就是训练时给模型立的规矩，教它什么该做、什么不该做）的不同，会对不同的指令结构、不同的语气风格，产生微妙的“偏好”。有的模型对明确指令响应最好，有的模型对格式变化更敏感，同一个 Prompt 换一个模型，效果可能明显不同。

先把证据和经验分开。有两件事是有官方或论文背书的。一件是 OpenAI 官方指南的提醒，不同类型的模型可能需要不同的提示方式才能拿到最好的效果，连同一家族里不同的模型快照，表现也可能不一样。另一件是关于格式敏感性的定量研究，同一道代码翻译题，只换提示模板的格式（纯文本、Markdown、JSON、YAML），GPT-3.5 的成绩波动可以高达 40%，而 GPT-4 这个量级的模型对格式变化稳健得多。

至于下面这些“性格画像”，则是社区经验的浓缩，基于 2024 年中前后的 GPT-4 和 Claude 3 世代。模型迭代飞快，各家的新版本都在拼命补自己的短板，这些描述是用来建立直觉的，不是一劳永逸的结论，手感要跟着模型版本一起更新。

先看 GPT 系列（如 GPT-4）的特点，偏向严谨执行。GPT 系列的模型，尤其是 GPT-4，长处是逻辑严谨、知识渊博。它对“明确指令”响应最好。OpenAI 官方指南对 GPT 系列的定性是“受益于更明确的指令”。把任务拆成清晰的步骤、把输出格式写明白，它执行得最稳，特别适配 LangGPT 和 CO-STAR 这种逻辑层次分明的框架。指令结构越清晰，它的输出越稳定。

格式的影响可以量化，而且越小的模型越敏感。前面那项研究发现，同样的提示内容换成不同格式，对 GPT-3.5 的扰动远大于 GPT-4。这给了一个反直觉的启示，模型越强对格式越“宽容”，预算有限只能用小模型时，才越需要把结构写得一清二楚。

它的角色扮演出色，但这不是它的专利。给它一个专业角色设定，比如“你是一个精通明朝历史的故宫研究员，请用《万历十五年》的笔触分析一下魏忠贤”，它模仿知识储备和说话口吻的效果确实一流，因为它训练数据里这类语料多。但别把这条记在 GPT 名下，Anthropic 官方同样建议给 Claude 设角色，说哪怕一句话的角色设定，也能让行为和语气更聚焦。角色扮演是各家模型通吃的技巧。

再看 Claude 系列（如 Claude 3）的特点，偏向长文本与沟通。Claude 系列的模型，长处在于长文本处理和对话沟通。长文本任务上，官方文档建议将长材料放在提示词顶部、问题和指令放在末尾，社区用例显示这种安排能显著提升回复质量。至于社区里流传的 Claude 做长文摘要、阅读理解和创意写作“特别丝滑”，那属于经验之谈，在自己手头的任务上验证过才算数。

对 XML 标签，它也有官方背书。Anthropic（Claude 的开发公司）的官方文档明确建议用 XML 标签（<tag></tag>）包裹不同部分的内容，理由是 XML 能帮 Claude 更无歧义地解析复杂提示、减少误解。实践也证明，Claude 对这种格式的解析和遵循度确实出色。

默认长度因模型而异，长度约束要显式写。这里要修正一个流传很广的印象，很多人觉得 Claude 天生“话痨”，但官方文档的口径恰恰相反，最新世代的 Claude 整体比前代更简洁直接，最新的 Opus 系列型号，官方文档明确说默认回复偏长，调整”努力程度”也未必能改变可见的回复长度，建议在提示词里显式写明”要简洁”。工程结论不受影响，不写长度约束，输出有多长就由模型的默认值说了算。

落到工程师手上，这些“性格”差异指向同一个结论，Prompt Engineering 没有“一招鲜，吃遍天”的银弹。这不是社区的自说自话，OpenAI 官方指南自己也提醒，不同类型的模型可能需要不同的提示方式。不能指望写一个 Prompt，就能在所有模型上都达到最佳效果。

为一个项目选择基础模型时，就应该把它的“性格偏好”考虑进去。如果应用是一个需要严格遵循格式、执行复杂逻辑、输出 JSON 的数据处理 Agent，那么 GPT-4 这种偏严谨执行的模型可能是更稳妥的起点；如果应用是一个需要进行长文本理解、与用户进行有深度、有情感的对话的聊天机器人或创意写作助手，那么 Claude 3 这种偏长文本沟通的模型可能更合适。

更重要的是，当发现 Prompt 在某个模型上效果不佳时，不要立刻否定 Prompt 本身，可以尝试针对模型的偏好，对框架进行微调。

比如，为 GPT-4 设计的基于 Markdown 标题的 CO-STAR Prompt，迁移到 Claude 4 系列时，发现它总是在 JSON 外面加一些废话。这时候可以尝试把 ### Context 这样的标题，换成 <context></context> 这样的 XML 标签。这个小小的改动，把标题式的结构标记换成了 XML 的显式边界标记，Claude 对后者的解析更稳定。

这种针对不同模型的调整，是高级 Prompt 工程师必备的“手感”。要通过大量的实践，去掌握不同模型之间的偏好差异，然后根据所用模型，灵活地调整 Prompt 框架。

7.5 用三种框架重构同一个 Prompt

纸上得来终觉浅，绝知此事要躬行。

这一节就来实际演练一下，用这一章学到的三种框架，CO-STAR、CRISPE、RISEN，来“重构”同一个糟糕的 Prompt，并深入对比它们之间的差异，以及可能产生的不同效果。

先把原始的“糟糕” Prompt 摆出来。假设任务是为一个面向公司内部程序员的技术分享会，写一封邀请邮件。

一个新手，或者一个急着下班的工程师，可能会这么写： “帮我写一封邮件，邀请大家参加下周三下午三点在公司大会议室举办的技术分享会，主题是关于‘大规模微服务架构下的稳定性保障’，主讲人是资深架构师张伟。让大家踊跃报名。”

这个 Prompt 有什么问题？信息是全的，但缺了关键的设计要素。缺乏上下文和动机，模型不知道这次分享会为什么重要，所以写出来的文字也无法传递出重要性。没有风格和语气要求，模型大概率会生成一封干巴巴的、像系统通知一样的邮件。没有明确受众，模型不知道该用什么样的“黑话”或者痛点来吸引程序员这群特殊的读者。

现在，用三大框架分别把它重写一遍。

版本一：CO-STAR 框架重构（要素全覆盖）

先用最通用、最稳妥的 CO-STAR 来构建。它的思路接近一份写得完整的需求文档（PRD），要素齐全，覆盖全面。

# [PROMPT - 技术分享会邀请邮件 V1 (CO-STAR)]

## C - Context (上下文)
我们公司技术部正在全力推动一个名为“磐石计划”的年度技术能力提升项目，旨在系统性地提升全体工程师的架构设计能力和解决复杂线上问题的能力。本次技术分享会是“磐石计划”的第一场，是整个计划的“开营仪式”，其成功与否直接关系到后续活动的参与度和大家的士气，因此非常重要，希望能一炮打响。

## O - Objective (目标)
撰写一封内部邮件，正式邀请技术部的所有工程师（包括前端、后端、测试、运维）参加本次技术分享会。邮件的核心目标不仅仅是“通知”，更是要“激发”，需要清晰地传达分享会的所有关键信息（主题、主讲人、时间、地点），并有效地点燃大家的参与兴趣和报名意愿。

## S - Style (风格)
邮件整体风格应为“专业”与“轻松”相结合。既要通过专业的术语和问题，体现出技术分享的硬核与干货，又要避免官僚化的、冷冰冰的通知口吻。可以适当使用一些程序员群体喜闻乐见的梗或比喻（例如：代码、Bug、架构等），但要点到为止，避免油腻。

## T - Tone (语气)
语气应是“热情”、“诚恳”和“略带极客风”的。要让工程师们感觉到，这不是一次领导安排的、必须参加的强制性任务，而是一次由技术委员会精心准备的、能学到真东西、解决真痛点的“技术盛宴”。

## A - Audience (受众)
邮件的接收者是公司技术部的全体工程师。这个群体普遍比较务实，讨厌空话套话；对能够解决实际问题的”干货”技术内容非常感兴趣；对”高并发”、”稳定性”、”分布式”、”架构”等话题有天然的关注度。

## R - Response (响应格式)
请直接输出邮件的标题和正文，格式为纯文本。
- 邮件标题需要有足够的吸引力，能够在一堆未读邮件中脱颖而出，例如可以采用提问式或痛点式标题。
- 邮件正文需要分段，逻辑清晰，建议包含“为什么你应该来”、“你会听到什么”、“活动信息”等模块。
- 在邮件末尾，需要明确给出报名方式和截止日期。
- 关键信息（如时间、地点、主讲人）可以使用星号 `*` 或其他符号进行突出，方便快速阅读。

来分析一下这个版本。经过 CO-STAR 的逐项梳理，这个任务的所有细节都考虑到了。它就像一份完整的 PRD，模型拿到手之后，几乎没有任何产生歧义的空间。它生成的邮件，大概率会是一封结构清晰、信息完整、风格和语气都非常得体的邀请函。它可能不会有特别出彩的文采，但它是一封“不会出错”的、高质量的职业邮件。对于绝大多数企业内部沟通场景，这已经足够好了。

版本二：CRISPE 框架重构（重洞察与感染力）

现在换个思路。假设这次分享会不仅仅是一次技术培训，更是一次“文化建设”，希望点燃大家的技术热情。这时候 CO-STAR 可能就有点“平”了，需要更有煽动性的 CRISPE 框架。

# [PROMPT - 技术分享会邀请邮件 V2 (CRISPE)]

## C - Capacity and Role (能力与角色)
你是一位在硅谷顶级科技公司（如 Google, Netflix）工作多年的技术布道师（Tech Evangelist）。你不仅技术功底深厚，更是一位演讲和沟通大师，非常擅长用富有激情和感染力的语言，向工程师们传递复杂的技术理念，并激发他们内心深处对技术卓越的渴望。

## I - Insight (洞察)
当前，我们团队的工程师们日常大多被繁重的业务需求压得喘不过气，很多人陷入了“CRUD”的循环，对技术的思考逐渐局限于“功能实现”，而对“系统稳定性”、“架构优雅性”等更深层次的追求有所下降。这导致线上偶尔会出现一些本可避免的“低级”故障，团队士气也有些低落。我们举办这次分享会的深层目的，不仅仅是分享知识，更是希望像一声“惊雷”一样，唤醒大家对“卓越工程文化”的追求，让大家重新思考：我们究竟是想做个“码农”，还是想成为一名真正的“工程师”？

## S - Statement (指令)
请以你的角色，撰写一封极具煽动性的技术分享会邀请邮件。分享会的核心信息如下：主题为“别让你的微服务‘死’在上线后——大规模架构下的稳定性保障之道”，主讲人是亲历过多次“双十一”洪峰的资深架构师张伟，时间是下周三下午三点，地点在公司大会议室。

## P - Personality (个性)
你的行文个性应该是：
- **激情四射，充满力量**：字里行间要充满对技术的热爱和对未来的信念。
- **直击痛点，引发共鸣**：能够一针见血地指出工程师们在日常工作中遇到的“痛”与“痒”。
- **高屋建瓴，提升格局**：能够从更高的视角，阐述技术分享对于个人成长和团队发展的长远价值。

## E - Experiment (实验)
为了达到最佳的宣传效果，请为这封邮件提供两种不同风格的开场白方案，让我选择：
1. **方案A（痛点切入）**：以一个所有工程师都经历过的、半夜被报警电话叫醒的场景作为开头。
2. **方案B（愿景切入）**：以一个关于构建“坚如磐石”的系统的理想主义愿景作为开头。

再来分析这个版本。看到区别了吗？CRISPE 版本的 Prompt，几乎没有提具体的格式、受众的技术背景这些细节，而是花了大量的笔墨在 Insight（洞察）和 Personality（个性）上。与其说它是在给模型下达一个“执行任务”，不如说是在把任务背后的动机和情绪完整地交代给模型。

它期望模型能理解这次分享会背后的用意，然后以一个“技术布道师”的角色，去写一封真正能打动工程师的邮件。最后 Experiment 的要求，更是体现了它“策略先行”的特点。

用这个 Prompt 生成的邮件，可能在信息组织的规整性上不如 CO-STAR，但它的内容深度、情感感染力，以及对程序员群体心理的把握，很可能会更胜一筹，更有可能成为一封在公司内部广泛转发和讨论的邮件。

版本三：RISEN 框架重构（信息零差错）

设想一个极端情况。这次分享会是强制性参加的，目的不是“激发”，而仅仅是“确保通知到位，信息无误”。这时候，任何花里胡哨的文采都是多余的，准确和清晰是唯一的要求，执行纪律最严明的 RISEN 框架正适合这种任务。

# [PROMPT - 技术分享会邀请邮件 V3 (RISEN)]

## R - Role (角色)
你是一位高效、严谨的工程项目经理（Engineering Program Manager），负责技术部内部重要活动的通知和组织工作。你的沟通风格是：信息精准、零废话、指令清晰。

## I - Instructions (指令)
根据公司技术委员会决议，技术部将举办“磐石计划”系列技术分享，本次为第一场。请撰写一封清晰、准确的邮件，通知技术部工程师参加，并引导必须参加的人在截止时间前完成报名。邮件涉及的全部信息如下，不得有任何出入：
- **活动名称**: “磐石计划”技术分享第一期
- **分享主题**: 大规模微服务架构下的稳定性保障
- **主讲人**: 张伟（资深架构师）
- **时间**: 2023年10月25日（下周三），下午 3:00 - 5:00
- **地点**: 公司一楼，大会议室
- **参与要求**: T5 及以上后端工程师必须参加，其他感兴趣的同学欢迎自愿报名。
- **报名方式**: 请在 2023年10月24日（周二）18:00 前，通过内部“活动报名”系统链接 [http://internal.example.com/signup] 完成报名。未按时报名的必须参加人员，将由各组 Leader 单独沟通。

## S - Steps (步骤)
1. 逐条核对上述七项信息，确认时间、地点、人名、链接无任何笔误。
2. 按“标题 → 关键信息速览 → 参与要求 → 报名方式”的顺序组织邮件正文。
3. 把必须参加的人员范围和报名截止时间放在邮件最显眼的位置。
4. 自查一遍信息与措辞，输出邮件终稿。

## E - End Goal (终点目标)
必须参加的工程师读完邮件，不需要再向任何人询问，就知道自己要不要去、什么时候去、怎么报名；邮件中的每一项信息，都能在上面的信息清单里找到出处。

## N - Narrowing (约束收窄)
- 不使用任何修辞、比喻、感叹和煽动性表达。
- 不添加信息清单之外的任何内容，包括活动意义、公司愿景等延伸描述。
- 标题直接陈述事件，不追求吸引力。
- 不省略任何一项信息，也不改写其中的措辞。

效果也不难预判。RISEN 版本的 Prompt，画风同样很“干”，甚至有点“冷酷”，但它“干”的方式很有辨识度。Steps 模块把生成过程拆成了四步，等于替模型排好了“先核对、再组织、后自查、最后输出”的执行顺序；Narrowing 模块把修辞、加戏、省略这几类最容易出的错，提前一条条堵死。

它设定的角色还是“工程项目经理”，这个角色本身就暗示了它的工作风格，纪律导向、流程驱动、准确、高效、不出错。

用这个 Prompt 生成的邮件，可能读起来不会让人有任何兴奋感，但它一定是一封信息最准确、权责最清晰、最不会让人产生误解的通知。在很多严肃的、需要明确指令的企业场景下，这种“零废话”的风格反而是最专业、最合适的。

对比与反思：框架即思维

好了，三种框架重写出了三封风格迥异的邮件。CO-STAR 要素全覆盖，面面俱到，产出均衡，是大多数情况下的最优选，能保证 80 分的稳定输出；CRISPE 重洞察和创意，更注重“为什么”和“可能性”，适合需要创造力和情感深度、追求 95 分上限的任务；RISEN 纪律驱动，先排步骤、先列禁区，适合那些流程一步不能乱、边界一寸不能越的执行型任务。

这个案例说明，框架本身没有好坏之分，只有适合与不适合。框架，本质上是思维方式的外化。

在开始一个新任务时，花五分钟时间，问一问： “这次的核心目标，是追求内容的创造性与感染力？还是追求执行的准确性与零失误？还是追求各方面都不得罪的均衡与稳妥？” 这个问题的答案，会直接指向最合适的那个“思维脚手架”。

---

本章总结　从套用框架到内化方法

这一章讲了通用设计框架的价值。

回头看，框架确实不是束缚手脚的”八股文”，而是对抗复杂度、避免遗漏、提升效率的”思维脚手架”，大脑混乱的时候，它就是一份现成的思考清单。三个框架定位各不相同。CO-STAR 走均衡全能路线，CRISPE 重背景洞察，RISEN 执行纪律严明。按任务选型。那一封邀请邮件的三次”重构”应该能让人摸到感觉，同一件事，换一个框架，产出的效果连气质都不一样。

还有一层认知也值得带走。不同模型各有偏好。顶级的 Prompt 工程师不只会用框架，还会按模型的特点微调框架，把框架调整到贴合那个模型的偏好。

学习框架的过程，都是从遵守固定格式开始的。这个阶段，框架是一份必须逐项对照的清单，帮人把要素补全，不至于漏掉关键的背景或约束。

但随着写出的 Prompt 越来越多，踩过的坑、解决过的 Bug 越来越多，经验越来越丰富，这些框架会慢慢地、不知不觉地内化于心，成为下意识的思维习惯。到那个时候，就不再需要刻意地套用 C-O-S-T-A-R 的每一个字母了。

慢慢地，会达到不翻清单也能想全要素的状态。面对任何一个问题，脑海里会自然而然地浮现出那些关键的思考维度，背景是什么？目标是什么？受众是谁？风险在哪？……

到那时，框架就不再是一份要逐项对照的外部清单，而是变成了固定的思维习惯。

这就是从会用框架到用好框架的差别。

参考资料

1. Teo, S. (2023). How I Won Singapore's GPT-4 Prompt Engineering Competition. Towards Data Science（作者为 2023 年新加坡政府科技局 GovTech 举办的首届 GPT-4 提示工程大赛冠军，文中说明 CO-STAR 框架出自 GovTech 数据科学与 AI 团队，并逐项给出 Context、Objective、Style、Tone、Audience、Response 六要素）. https://towardsdatascience.com/how-i-won-singapores-gpt-4-prompt-engineering-competition-34c195a93d41/
2. sourcingdenis. CRISPE — ChatGPT Prompt Engineering Framework. Medium（CRISPE 五组要素的通行展开）. https://sourcingdenis.medium.com/crispe-prompt-engineering-framework-e47eaaf83611
3. Gunnar Grosch. Writing System Prompts That Actually Work: The RISEN Framework for AI Agents. dev.to. https://dev.to/gunnargrosch/writing-system-prompts-that-actually-work-the-risen-framework-for-ai-agents-4p94
4. Anthropic. Use XML tags（官方文档建议使用 XML 标签组织提示词，Claude 对该格式解析与遵循效果好）. https://platform.claude.com/docs/en/build-with-claude/prompt-engineering/use-xml-tags