企业官网建设流程全解析

1. 为什么提示词值得当成一门手艺来练

我接触AI提示词这件事，最早是从帮朋友写产品文案开始的。那时候我以为提示词就是“把话说清楚”，结果第一次让模型写一段电商详情页，它给我返回了一篇四平八稳、毫无购买欲的说明文。后来我花了大概三个月时间，反复拆解自己写过的每一条提示词，对比输出质量的差异，才慢慢摸到一点门道：提示词不是“提问”，而是“设计任务”。你给模型的不是一句话，而是一份隐形的需求文档。

这个认知转变非常关键。很多人觉得提示词就是“你问它答”，跟搜索引擎差不多。但实际用下来你会发现，搜索引擎给你的是链接列表，而大语言模型给你的是“它理解之后重新组织的内容”。这意味着，你输入的每一个词、每一个标点、每一处语序，都会影响它理解的方向。提示词写得好，模型就像一个经验丰富的执行者；写得含糊，它就像一个刚入职、不敢多问的新人，只能靠猜。

这篇文章想解决的问题很具体：怎么从“随便问问”进化到“稳定产出可用结果”。我会把提示词拆成三个层面来讲——框架、模板、实战。框架解决的是“怎么想”的问题，模板解决的是“怎么写”的问题，实战解决的是“怎么调”的问题。适合谁看？如果你已经用过一段时间AI工具，但输出质量时好时坏，或者你刚开始接触提示词，想少走弯路，那这篇内容应该能帮到你。

我自己的经验是，提示词能力提升最快的阶段，不是看了多少教程，而是开始用固定框架去约束自己的表达。下面我从整体设计思路开始拆。

2. 提示词的整体设计思路与框架选型

2.1 提示词的本质：把模糊需求翻译成可执行指令

很多人写提示词失败，根本原因不在“词”上，而在“需求本身就没想清楚”。你让模型“写一篇好文章”，它不知道“好”的标准是什么；你让模型“优化这段代码”，它不知道优化目标是性能、可读性还是兼容性。提示词的第一道工序，其实是自我追问：我到底要什么？

我习惯把提示词设计分成三层：目标层、约束层、格式层。目标层回答“做什么”，约束层回答“不做什么、优先做什么”，格式层回答“以什么形式交付”。这三层缺一层，输出就容易跑偏。比如“写一封辞职信”是目标层，“语气温和但坚定，不抱怨公司”是约束层，“300字以内，分三段”是格式层。三层齐全，模型才有明确的执行边界。

这个思路和软件工程里的“需求规格说明书”很像。你不会跟开发说“做个好用的App”，你会说“做一个面向老年人的天气App，首页只显示温度和降水概率，字体不小于18px”。提示词也是一样，颗粒度越细，返工越少。

2.2 三大经典框架的适用场景与取舍逻辑

市面上流传的提示词框架很多，我实际用下来，真正高频使用的就三个：CRISPE、CO-STAR、思维链。它们不是互斥的，而是针对不同任务类型的“工具箱”。

CRISPE适合需要模型扮演特定角色、并且对背景信息依赖较强的任务。它的结构是：Capacity（角色）、Request（请求）、Insight（背景洞察）、Statement（具体指令）、Personality（风格）、Experiment（多版本尝试）。我一般用CRISPE来写需要“专业口吻”的内容，比如行业分析、技术方案、法律文书草稿。它的优势是角色和背景分离得很清楚，模型不容易把“你是谁”和“你要做什么”搞混。

CO-STAR更适合内容创作类任务，尤其是需要控制语气和受众的场景。它的结构是：Context（上下文）、Objective（目标）、Style（风格）、Tone（语气）、Audience（受众）、Response（响应格式）。我写社交媒体文案、产品介绍、邮件模板时用得最多。CO-STAR的好处是它强迫你思考“谁在看”，这一点在内容创作里经常被忽略。

思维链严格来说不算一个完整框架，而是一种推理策略。它的核心是让模型“先想再答”，通过显式要求模型展示推理步骤，来提升复杂任务的准确率。我一般在数学计算、逻辑推理、多条件决策这类任务里用它。比如让模型做预算分配、排期规划、方案对比，加上“请逐步分析”之后，输出质量会有明显提升。

这三个框架的关系可以这样理解：CRISPE和CO-STAR是“任务描述框架”，思维链是“推理增强策略”。你可以用CO-STAR写一个任务描述，然后在具体指令里加入思维链要求。我自己的常用组合是：CO-STAR搭骨架，思维链补逻辑。

2.3 框架不是越多越好：什么时候该放弃框架

这里要泼一盆冷水。框架是给复杂任务用的，不是所有提示词都需要套框架。我见过有人连“今天天气怎么样”都要写一段CO-STAR，这就属于过度设计。判断标准很简单：如果任务本身没有歧义、不需要特定风格、不涉及多步推理，直接问就行。

我自己的经验法则是：任务涉及三个以上约束条件，或者输出需要直接用于正式场景，才值得上框架。日常查资料、简单改写、快速翻译，用自然语言直接说反而效率更高。框架的价值在于“防遗漏”，而不是“显专业”。

还有一个容易被忽略的点：框架用久了会形成思维惯性。我有一段时间所有提示词都套CO-STAR，结果写出来的东西越来越模板化，缺乏灵活性。后来我刻意练习“无框架写作”，强迫自己用最朴素的语言把需求说清楚，反而发现了很多框架覆盖不到的细节。框架是拐杖，最终目标是能扔掉拐杖走路。

3. 七类通用模板的拆解与实操要点

3.1 角色扮演类模板：让模型“入戏”的正确姿势

角色扮演是提示词里最常用的技巧，但很多人用错了方向。常见的错误写法是：“你是一个资深程序员，帮我写代码。”这句话的问题在于，“资深程序员”这个角色太宽泛，模型不知道你是要写算法、写接口还是写脚本。

我常用的角色扮演模板结构是这样的：

你是一位在[具体领域]有[具体年限]经验的[具体职位]，你的日常工作包括[具体任务1]、[具体任务2]。你擅长用[具体方法/工具]解决[具体问题]。现在你需要帮我完成[具体任务]，要求是[具体要求]。

举个例子，同样是写代码，我会这样写：

你是一位在电商行业有5年经验的后端工程师，日常负责订单系统和支付网关的维护。你擅长用Python和PostgreSQL处理高并发场景下的数据一致性问题。现在你需要帮我写一个订单超时自动取消的定时任务，要求考虑分布式锁、幂等性和失败重试。

这样写的好处是，模型不仅知道“你是谁”，还知道“你平时怎么干活”，输出的内容会更贴近真实工作场景。我实测下来，加了具体工作背景之后，代码的工程化程度明显提升，不再是教科书式的示例代码。

还有一个细节：角色扮演类提示词里，不要给模型戴高帽。比如“你是世界顶级专家”“你是最厉害的设计师”，这种描述对输出质量几乎没有帮助，反而可能让模型过度自信，忽略细节。具体的工作经验比空洞的头衔有用得多。

3.2 结构化输出类模板：让结果直接可用

结构化输出是我用得最多的一类模板，因为它的回报最直接：模型返回的内容可以直接粘贴到表格、文档、代码里，不需要二次整理。这类模板的核心是明确指定输出格式，包括字段名、字段顺序、分隔符、空值处理方式。

我常用的结构化输出模板长这样：

请按照以下格式输出，不要添加任何额外说明：

字段1：[内容] 字段2：[内容] 字段3：[内容]

如果某个字段无法确定，填写“待确认”，不要留空。

如果是表格类输出，我会更具体：

请以Markdown表格形式输出，表头为：| 方案名称 | 核心思路 | 适用场景 | 实施难度 | 预期效果 | 共输出3个方案，按实施难度从低到高排列。

这里有个坑要注意：模型对“不要添加额外说明”的执行并不总是严格。它有时候会在表格前后加一句“以下是我为您整理的方案”。如果你需要纯数据，可以在提示词末尾加一句：“只输出表格，不要有任何前后缀文字。”我试过多次，加上这句话之后，纯净度会高很多。

另外，结构化输出模板特别适合批量任务。比如你有一批用户评论需要分类，可以写一个固定模板，然后把评论逐条填入。这样每次输出的格式完全一致，后续用脚本处理也很方便。

3.3 分步推理类模板：复杂问题的拆解利器

分步推理类模板的核心是“把大问题拆成小问题”，让模型一步一步来。这类模板特别适合方案对比、决策分析、故障排查这类需要逻辑链条的任务。

我常用的分步推理模板结构是：

请按以下步骤分析这个问题： 第一步：列出所有已知条件和约束。 第二步：分析每个条件对结果的影响。 第三步：提出至少3个可行方案。 第四步：对比每个方案的优缺点。 第五步：给出推荐方案及理由。

这个模板的关键在于步骤之间要有逻辑递进，不能是简单的罗列。第一步的输出应该是第二步的输入，第二步的输出应该是第三步的输入。如果步骤之间没有依赖关系，模型很容易在每个步骤里重复同样的内容。

我踩过的一个坑是：步骤太多。有一次我写了八步，结果模型在第五步就开始敷衍，后面的步骤明显质量下降。后来我控制在五步以内，每个步骤的要求写具体，输出质量就稳定了。如果任务确实复杂，我会拆成两轮对话，第一轮做前几步，第二轮基于第一轮的结果继续。

3.4 风格控制类模板：让输出“像那么回事”

风格控制类模板解决的是“内容对但味道不对”的问题。比如你让模型写一篇科技评论，内容没问题，但读起来像说明书；你让模型写一段品牌文案，信息都全，但语气像公告。这时候就需要风格控制模板。

我常用的风格控制模板会从三个维度描述风格：语感、节奏、用词。

请用以下风格写作： 语感：轻松但不随意，像朋友之间聊专业话题。 节奏：短句为主，每段不超过4行，段落之间用过渡句衔接。 用词：避免“赋能”“抓手”“闭环”等套话，多用具体动词和名词。

如果是模仿特定风格，我会提供一段参考文本：

请参考以下文本的风格，写一段关于[主题]的内容。注意模仿其句式结构、用词习惯和段落节奏，但不要照抄内容。

[参考文本]

这里要注意：风格模仿的参考文本不宜过长，200到300字就够了。太长了模型会倾向于复制原文，而不是学习风格。另外，如果参考文本本身质量不高，模型也会学偏。我一般会选自己写的、风格稳定的段落作为参考。

3.5 迭代优化类模板：把“改稿”变成可复用的流程

迭代优化类模板是我最近半年用得越来越多的类型。它的思路是：不指望一次输出就完美，而是设计一个“生成-反馈-修改”的循环。这类模板特别适合写作、设计、方案策划这类需要反复打磨的任务。

我常用的迭代优化模板分两轮：

第一轮：

请根据以下要求生成[内容类型]： [具体要求] 生成后，请自行评估三个维度：信息完整性、逻辑连贯性、语言流畅度。对每个维度打分（1-10分），并指出最需要改进的一个点。

第二轮：

根据你上一轮的自我评估，请针对最需要改进的点进行修改，输出修改后的版本。修改时保持其他部分不变，只调整你指出的问题。

这个方法的妙处在于，它让模型自己发现问题，而不是等我指出问题。我实测下来，经过一轮自我评估和修改，输出质量平均能提升20%到30%。而且这个过程可以重复多轮，直到满意为止。

不过要注意：不要让模型无限迭代。一般两到三轮就够了，再多的话，模型可能会为了“改而改”，把原本正确的内容改错。我一般会在第三轮之后人工介入，判断是否继续。

3.6 约束排除类模板：用“不要什么”来定义“要什么”

约束排除类模板的思路是：当正面描述很难说清楚时，用反面描述来缩小范围。这在创意类任务里特别有用，因为“好创意”很难定义，但“烂大街的创意”很容易识别。

我常用的约束排除模板：

请为[主题]生成5个创意方案。要求：

• 不要使用“科技感”“未来感”“沉浸式”这类已经被用烂的概念。
• 不要出现“赋能”“颠覆”“革命性”等词汇。
• 不要采用“问题-解决方案”的经典叙事结构。
• 每个方案用一句话概括，不超过30字。

这种“负面清单”式的约束，往往比正面要求更能激发模型的多样性。我试过让模型写产品slogan，正面要求写“简洁有力”，输出都很平庸；换成“不要用形容词，不要用感叹号，不要超过8个字”，出来的东西反而更有意思。

约束排除类模板还有一个变体：优先级排序。当多个约束条件冲突时，明确告诉模型哪个优先。比如：“如果简洁性和完整性冲突，优先保证简洁性。”这样模型在取舍时就有依据，不会左右摇摆。

3.7 多轮对话类模板：把一次问答变成一次协作

多轮对话类模板适合那些“一次说不清”的任务。它的核心是设计一个对话流程，每一轮解决一个子问题，逐步逼近最终目标。这类模板在复杂咨询、方案设计、学习辅导场景里特别有用。

我常用的多轮对话模板会预设对话路线：

我们将分三轮对话来完成[任务]。 第一轮：请你先了解背景，我会提供[背景信息]，你只需要复述你理解的关键点，不要给出建议。 第二轮：基于你理解的背景，提出3个初步方向，每个方向用两句话说明。 第三轮：我会选择一个方向，你针对这个方向给出详细方案。

这个模板的关键是每一轮的任务要单一。如果一轮里让模型既理解背景又提方案，它很容易顾此失彼。分开之后，每一轮的质量都会更高。

我自己的使用心得是：多轮对话模板特别适合“我自己也没想清楚”的情况。通过让模型先复述、再发散、再聚焦，我往往能在对话过程中理清自己的思路。有时候模型第二轮提出的方向，会触发我想到更好的方向，这是单轮问答很难实现的。

4. 六个实战案例的完整拆解

4.1 案例一：用CO-STAR写一篇产品发布文案

这个案例来自我帮一个朋友的新产品写发布文案。产品是一款面向自由职业者的时间管理工具，核心卖点是“自动识别任务优先级”。我一开始直接写“帮我写一篇产品发布文案”，输出很平淡，像新闻稿。后来改用CO-STAR框架：

Context：一款面向自由职业者的时间管理工具，核心功能是自动识别任务优先级，目标用户是同时接多个项目的设计师、开发者、写作者。 Objective：写一篇发布文案，让读者产生“这个工具能解决我时间混乱的问题”的认知。 Style：第一人称，像产品创作者在分享自己的痛点。 Tone：真诚、不夸张，承认工具不是万能的。 Audience：25到35岁的自由职业者，有3年以上独立工作经验。 Response：800字左右，分四段：痛点场景、现有方案的不足、这个工具的做法、适合谁用。

输出质量比第一版好很多，尤其是“承认工具不是万能的”这个语气设定，让文案读起来不像广告。我后来只改了两个地方：把“自动识别”改成了“帮你判断”，把“提升效率”改成了“少做无用功”。这两个改动让文案更口语化，更贴近目标用户的表达习惯。

这个案例给我的启发是：CO-STAR里最容易被忽略的是Tone和Audience。很多人只写Context和Objective，结果输出要么太正式，要么太随意。把语气和受众写清楚，模型才知道“对谁说话、用什么姿态说话”。

4.2 案例二：用CRISPE生成一份技术方案对比

这个案例是我自己工作中遇到的：需要对比三种数据库方案，用于一个中等规模的SaaS产品。我用CRISPE框架写提示词：

Capacity：你是一位有8年经验的后端架构师，经历过从单体到微服务的迁移，熟悉PostgreSQL、MongoDB和TiDB的优缺点。 Request：对比这三种数据库方案，用于一个日活5万、数据量500GB的SaaS产品。 Insight：团队只有3个后端，运维能力有限，希望尽量减少运维复杂度。预算中等，可以接受云托管方案。 Statement：从数据模型、查询性能、扩展性、运维成本、团队学习成本五个维度对比，给出推荐方案。 Personality：务实、不堆术语，每个结论都要有依据。 Experiment：先给一个简版对比表，再展开详细分析。

输出结果很扎实，尤其是“团队只有3个后端”这个约束，让模型在推荐时明显偏向运维简单的方案。最后推荐的是云托管PostgreSQL，理由写得很清楚：团队熟悉、运维托管、扩展性够用。这个结论和我自己的判断一致，但模型补充了一些我没想到的细节，比如“TiDB的分布式事务在中小规模下收益不明显，反而增加调试成本”。

这个案例的关键在于Insight部分要写真实约束。如果你写“预算充足、团队技术强”，模型就会推荐更复杂但更“先进”的方案。约束写得越真实，推荐越接地气。

4.3 案例三：用思维链做一次预算分配

这个案例是我帮一个社群做年度预算分配。总预算12万，需要分配到内容创作、活动运营、工具采购、储备金四个方向。我用了思维链提示词：

请按以下步骤帮我分配预算： 第一步：列出每个方向的必要支出项。 第二步：估算每个支出项的最低成本和理想成本。 第三步：根据“保证核心产出、控制固定成本、留有余量”的原则，给出分配比例。 第四步：检查分配后每个方向是否满足最低成本，如果不满足，调整比例。 第五步：输出最终分配表和一句话说明。

模型在第三步给出的比例是内容40%、活动30%、工具20%、储备10%。第四步检查时发现工具的最低成本需要2.8万，而20%只有2.4万，于是自动调整到内容38%、活动28%、工具23%、储备11%。这个自我检查的步骤是我特意加的，效果很好，避免了“分完才发现不够”的问题。

这个案例让我意识到：思维链的价值不在于“让模型想”，而在于“让模型按你指定的方式想”。如果你不指定步骤，模型也会推理，但推理路径不可控。指定步骤之后，推理过程变得可预期、可检查。

4.4 案例四：用结构化模板批量处理用户反馈

这个案例是我帮一个做独立产品的朋友处理用户反馈。他收集了200多条用户留言，需要分类整理。我设计了一个结构化模板：

请对以下用户反馈进行分类，按以下格式输出：

反馈原文：[原文] 分类：[功能建议/体验问题/内容需求/其他] 紧急程度：[高/中/低] 关键词：[不超过3个] 建议处理方式：[一句话]

只输出结果，不要任何额外说明。

然后我把200条反馈分成10批，每批20条，逐批处理。输出结果直接粘贴到表格里，半小时就完成了原本需要一整天的工作。分类准确率我抽查了30条，只有2条需要手动调整，准确率超过90%。

这里有个细节：分类标准要提前定义清楚。我在模板里没有详细解释“功能建议”和“内容需求”的区别，导致有几条反馈被分错了。后来我加了一句：“功能建议指对产品功能的增加或修改，内容需求指对产品内提供的信息或素材的需求。”加上之后，分类准确率明显提升。

4.5 案例五：用风格控制模板改写一段技术文档

这个案例是我把自己写的一段技术文档改写成面向非技术读者的版本。原文是：

系统采用事件驱动架构，通过消息队列实现服务间异步通信，确保高并发场景下的最终一致性。

我用的风格控制模板：

请将以下技术描述改写为面向非技术读者的版本： 语感：像在给朋友解释，不用比喻，直接说人话。 节奏：一句话说清楚一件事，不超过25个字。 用词：避免“架构”“异步”“一致性”等术语，用日常词汇替代。

原文：[技术描述]

输出是：

系统里各个部分不直接互相等待，而是通过一个“中转站”传递消息。这样即使同时有很多人使用，系统也不会卡住，数据最终会保持一致。

这个改写我直接用了，因为目标读者是产品经理和运营，他们不需要知道“事件驱动”和“消息队列”，只需要知道“系统不会卡、数据不会乱”。这个案例让我体会到：风格控制的核心是“换位思考”，你得先想清楚读者是谁、他们关心什么，然后用他们的语言写出来。

4.6 案例六：用多轮对话模板做一次方案策划

这个案例是我帮一个线下活动做策划。活动主题是“城市漫步”，目标人群是25到35岁的上班族。我用了三轮对话：

第一轮我提供了背景：活动目的、目标人群、预算范围、场地限制。要求模型只复述关键点，不提建议。模型复述得很准确，还主动问了一个我没提到的问题：“活动是周末还是工作日晚上？”这个问题提醒了我，后来我把时间定在周六下午。

第二轮我让模型基于背景提出3个方向。模型给了“主题路线型”“任务挑战型”“社交匹配型”三个方向。我选了“任务挑战型”，因为目标人群是上班族，他们更需要“有目标感的放松”，而不是“随便走走”。

第三轮我让模型针对“任务挑战型”给出详细方案，包括路线设计、任务设置、时间安排、物料清单。输出很完整，我基本直接用了，只调整了任务难度，把“寻找指定店铺”改成了“拍摄指定颜色的门”，降低了执行门槛。

这个案例的关键在于第一轮的“只复述不建议”。如果第一轮就让模型提建议，它会在背景理解不充分的情况下给出泛泛的方案。先复述、再发散、再聚焦，每一步的质量都更高。

5. 常见问题与排查技巧实录

5.1 输出太泛：怎么让模型“说具体”

这是最常见的问题。你问“怎么写好提示词”，模型给你一堆“要清晰、要具体、要有结构”的正确废话。排查思路是：检查你的提示词里有没有“可验证的具体要求”。

“要具体”本身不具体。你得告诉模型“具体到什么程度”。比如：

• 不要写“给出建议”，写“给出3条建议，每条不超过20字，必须包含一个动词”。
• 不要写“分析优缺点”，写“列出2个优点和2个缺点，每个用一句话说明，必须引用具体数据或案例”。
• 不要写“写一段介绍”，写“写一段100到150字的介绍，第一句是结论，后面三句是支撑理由”。

我自己的经验是：凡是能用数字约束的，都用数字约束。字数、条数、比例、时间范围，这些数字会逼着模型给出更具体的内容。

5.2 输出太长：怎么控制篇幅

模型默认倾向于“多写”，因为训练数据里长文本居多。控制篇幅的方法有三个层次：

第一层：在提示词里明确字数范围。比如“300到400字”，而不是“简短一点”。模型对具体数字的遵守程度远高于模糊描述。

第二层：指定结构。比如“分三段，每段不超过5行”。结构约束比字数约束更有效，因为模型会优先满足结构要求。

第三层：如果还是太长，在末尾加一句：“如果超出字数，优先删除例子和重复说明，保留核心结论。”这句话给了模型一个“删减优先级”，它知道该砍哪里。

我实测下来，三层叠加之后，篇幅控制成功率在90%以上。剩下10%的情况，我会直接说“压缩到一半，只保留核心信息”，模型一般都能做到。

5.3 输出不稳定：同样的提示词为什么结果不一样

这个问题困扰过我很长时间。同样的提示词，早上跑和下午跑，结果质量不一样。后来我总结出三个主要原因：

原因一：上下文污染。如果是在同一个对话窗口里连续提问，前面的对话内容会影响后面的输出。解决方法很简单：重要任务开新对话。

原因二：提示词里有歧义词。比如“优化一下”可以指性能优化、可读性优化、成本优化。模型每次选的方向可能不同。解决方法：把“优化”替换成具体目标，比如“减少50%的运行时间”。

原因三：温度参数。大多数对话产品不暴露温度参数，但模型本身有随机性。解决方法：在提示词里加一句“请给出你最确定的一个答案，不要提供多个版本”。这句话会降低输出的随机性。

5.4 模型“不听话”：明明说了不要还是出现

这是提示词里最让人头疼的问题。你写了“不要用专业术语”，输出里还是有“赋能”“闭环”。排查下来，通常是因为否定指令的优先级低于肯定指令。模型会优先满足“写一段产品介绍”，然后才考虑“不要用术语”。

解决方法有两个：

方法一：把否定指令改成肯定指令。不要写“不要用术语”，写“用日常词汇，比如‘帮忙’而不是‘赋能’，‘做完’而不是‘闭环’”。给出替代方案，模型更容易执行。

方法二：把否定指令放在最后，并且加粗强调。比如：“再次强调：不要出现‘赋能’‘抓手’‘闭环’这三个词。”位置和强调都会提升指令的优先级。

5.5 常见问题速查表

5.6 我踩过的三个坑

坑一：提示词写得太长。我曾经写过一段800字的提示词，结果模型只关注了最后几句，前面的背景全忽略了。后来我控制在300字以内，把最重要的约束放在开头和结尾，中间放背景信息。这样模型的注意力分配更合理。

坑二：一次让模型做太多事。比如“写一篇文案，同时翻译成英文，再生成三个标题”。模型会把精力分散，每件事都做得一般。后来我拆成三轮，每轮只做一件事，质量明显提升。

坑三：忽略模型的“自我评估”能力。我以前都是自己检查输出，后来发现让模型自己评估更高效。加一句“请检查你的输出是否满足以下要求，如果不满足，请修改后重新输出”，模型的自检能力比我想象的强。

6. 提示词能力的长期修炼路径

提示词这件事，入门容易，精通难。我自己的修炼路径大概分三个阶段：第一阶段是“抄模板”，把别人的好提示词拿来改改用；第二阶段是“拆框架”，理解每个框架为什么这样设计；第三阶段是“忘框架”，根据任务本身设计提示词，不再依赖固定结构。

如果你现在处于第一阶段，我的建议是：先固定用CO-STAR写两周。所有需要模型输出的任务，都套这个框架。两周之后，你会对“上下文、目标、风格、语气、受众、格式”这六个要素形成肌肉记忆。然后再尝试CRISPE和思维链，对比不同框架的输出差异。

如果你已经过了第一阶段，我建议你开始建立自己的提示词库。按任务类型分类：写作类、分析类、代码类、创意类。每类下面存3到5个经过验证的模板。每次用的时候，先选模板，再根据具体任务微调。这样既保证质量稳定，又不会太耗时。

还有一个习惯我坚持了很久：每次输出不满意时，不要直接改提示词，先问自己“我到底哪里没说清楚”。大多数时候，问题不在模型，而在我的需求描述本身就有模糊地带。把这个问题想清楚，提示词自然就改好了。

最后分享一个我最近在用的技巧：让模型帮你写提示词。当你不知道该怎么描述一个任务时，直接问模型：“我想让AI帮我完成[任务]，请帮我写一段提示词，要求包含角色、背景、具体指令和输出格式。”模型给出的提示词往往结构完整，你只需要微调具体内容。这个方法特别适合新手，相当于让模型教你跟模型沟通。

提示词能力不是孤立的，它和你的表达能力、逻辑能力、领域知识都相关。你对自己要做的事理解得越深，提示词就写得越好。反过来，写提示词的过程也在逼你把事情想清楚。这大概是我做这件事最大的收获。