企业官网建设流程全解析

最近总有朋友问我，提示词工程到底值不值得专门花时间研究。我给的答案一直很直接：这不是一道附加题，而是必答题。现在市面上能用AI的人很多，但"用得好"和"能用"之间隔着一条巨大的沟。同样一个ChatGPT、Claude或者国产大模型，有人三句话问出精准方案，有人花一下午来回纠正还是跑偏。这种差距，跟工具的版本关系不大，基本全在提示词的写法上。

我在这上面踩过的坑不少。最早我也是"帮我写个方案"这种一句话提示词的忠实用户，出来的东西能用，但永远差口气——列了框架没细节，有了细节没逻辑，改了三次还是不对劲。后来逼着自己系统梳理了一遍提示词工程的方法论，才发现问题从来不在模型，在于我压根没有认真"布置任务"。

这篇文章分享的东西，是我在大量实操里筛过一遍之后留下的精华：10个能立刻上手的提示词技巧，以及一套已经整理成型的模板库。每个技巧我都会给出"改之前"和"改之后"的对比案例，讲清楚背后的逻辑和适用场景。无论你是刚接触AI的新手，还是已经用了一段时间但总觉得输出差点意思的老手，这里的内容都能直接拿到手边用，不需要再去啃那些又长又理论的教程。

1. 为什么提示词工程值得单独拿出来研究

1.1 提示词的底层逻辑：你不是在"命令"，而是在"沟通"

很多人的误区是把提示词当成咒语，仿佛记住几个固定句式就能召唤神龙。但真实情况完全不是这样。大语言模型的训练过程是用海量文本"喂"出来的，它本质上是一个超大规模的模式匹配器。你给它的提示词，越接近它在训练语料里见过的高质量指令结构，它的输出就越稳定、越贴合你的需求。

我一直跟人解释一个类比：提示词工程就像你跟一位经验丰富但不认识你的外包员工沟通。你只说一句"帮我做个方案"，他大概率只能给你一个通用模板。但如果你告诉他"我是谁、给谁用、要解决什么问题、偏好什么风格、输出格式是什么、不要包含什么"，他就能给你一份能直接交付的东西。模型也一样，它对你这个"客户"的了解，完全来自提示词里提供的信息量。

还有一个容易忽略的点：提示词工程不是一次性的。它是一套"需求描述—输出反馈—修正指令"的循环。很多人抱怨AI不好用，其实是因为他们把AI当成了搜索引擎，问一次就期望完美答案。真正有效的用法是把首轮输出当成初稿，通过追加指令逐步逼近目标——这个过程本身就属于提示词工程的范畴。

1.2 哪些人最需要这些技巧

我大致把适用人群分成三类，你可以对号入座。

第一类是内容创作者。包括写公众号的、做小红书的、拍短视频的、写营销文案的。这类人对语言风格和情绪表达的要求极高，通用型提示词往往给出四平八稳的"官腔"内容，完全没法直接用。学会角色设定、风格约束和迭代优化之后，AI能从一个"通用写手"变成"熟悉你账号调性的专属小编"。

第二类是产品经理、运营和技术开发人员。他们需要AI输出结构化内容，比如需求文档、PRD、接口代码、测试用例。这类场景最核心的需求是"格式可控"和"逻辑严谨"，对应到技巧上就是结构化输出、示例引导、步骤拆解和自我校验。我的经验是，在代码场景里，一个带示例的提示词和一个裸提示词的产出质量差距，可以用"天壤之别"来形容。

第三类是学生和职场新人。他们用AI做信息整理、概念学习、论文润色、会议纪要，最大的痛是不确定AI说的对不对。这类人最需要的是约束来源、交叉验证、多轮追问技巧，把AI当成一个需要核实的助理，而不是全知全能的导师。

无论你属于哪一类，下面这10个技巧都能帮你缩短"从能用到好用"之间的距离。

2. 10个立刻上手的提示词技巧

2.1 技巧一：角色设定法，一句话改变输出质量

角色设定是性价比最高的一个技巧。原理很简单：模型在训练时接触过不同领域、不同文风的文本，当你在提示词里给它一个明确的身份时，它内部的"文风分布"会自动向那个方向偏移。

改之前这样写：

帮我写一段产品介绍。

改之后再这样写：

你是一位在消费电子行业深耕十年的产品文案专家，擅长把技术参数转化成普通用户能感受到的价值。现在请为我们的无线降噪耳机写一段产品介绍，目标读者是通勤族，他们关心的是在地铁上能不能听清音乐。

你仔细对比一下就能发现，第二种写法的输出会明显更具体、更有网感，而且名词、动词的选择都会发生变化。角色设定不是越夸张越好，关键在于"身份 + 经验 + 任务 + 受众"，四个要素齐全，输出质量基本就有保障了。

我有个小习惯：在角色里加上具体的年限。比如"十年经验的HR"就比单纯"HR"的回复更接地气，因为模型会依据"十年"这个数字，下意识调用更资深、更有实操细节的表达模式。涉及陌生领域时，把角色设定成"你是一位愿意用通俗语言解释专业概念的老师"，还能避免模型满嘴黑话。

2.2 技巧二：结构化输出，把回答变成可读的数据

如果你只是问问题、要一段文字，那结构化输出不是必需的。但凡是涉及数据整理、方案对比、任务拆解、接口对接，结构化输出就是刚需。

最简单的做法是指定输出格式。比如：

对比下面三款云服务的价格和适用场景，结果用Markdown表格呈现，包含"服务名称、月费、适用场景、优缺点"四列。

这比"帮我对比一下"强在哪儿？第一，模型被格式约束之后，不会东拉西扯一些表格装不下的废话；第二，你拿到结果可以直接复用，粘贴到文档或后续处理流程里。

如果你想对接程序，那就要求JSON格式。比如：

把这段会议记录整理成JSON，字段为：decision（决议）, tasks（待办，含owner和deadline）, risks（风险点）。

这里有一个常见坑：模型偶尔会漏掉某个字段，或者在JSON里多出注释。解决方法是明确加一句"严格按照字段输出，不要输出JSON以外的任何内容"。如果你给的格式比较复杂，最好是顺手给一个示例字段的结构，模型对"照着示例填"这件事的执行力远高于仅凭描述自由发挥。

2.3 技巧三：示例引导法，给模型一个"参考答案"

Few-shot（少样本示例）是我个人使用频率最高的技巧之一。它的思路是：与其费劲描述你想要的输出，不如直接给模型看一两个输入输出的例子，让它"照猫画虎"。

举个例子，我想让AI识别用户的留言情绪分类，如果直接问"帮我分类情绪"，模型的输出可能千奇百怪：有人用一行词，有人用一段话，有人附解释。但如果你这样写：

请对用户留言进行情绪分类，输出格式参考示例： 输入：等了三天快递还没到，气死我了。 输出：愤怒

输入：终于收到货了，质量比想象中好太多！ 输出：满意

下面请对这句话分类：售后服务电话打不通，再也不买这家的东西了。

模型几乎一定能给出"愤怒"这个标准答案。示例的威力在于它同时锁定了三件事：输出的内容形态、输出的精炼程度、输入的解析方式。

使用时注意三个细节：示例数量1到3个就够，太多反而浪费上下文空间；示例要选典型且高质量，模型模仿的往往是例子里的"感觉"而不是逻辑；示例的输入输出要保持一致的对应关系，你给出一个模糊示例，模型就会学会模糊。

2.4 技巧四：步骤拆解法，逼模型先思考再回答

这个方法在学术圈有个更专业的名字叫思维链（Chain of Thought），通俗理解就是让模型"多走几步路再回答"。遇到复杂的逻辑题、数学题、分析题时，模型直接给答案容易跳步出错，但如果让它先拆步骤，正确率会明显提升。

我实际测试过一个例子。直接问："一家店进货成本是售价的60%，如果折扣价打七折还能有8%的利润率，请问原折扣前利润率是多少？"模型经常算得磕磕绊绊。但这样写，正确率几乎满格：

请按以下步骤逐步解答：

1. 设定未知数并列出所有已知条件。
2. 列出折扣前后的利润公式。
3. 根据题干条件建立等式。
4. 解方程并验证结果是否合理。
5. 最后给出结论。

步骤拆解最大的好处，是逼模型把一个"直觉性回答"变成"推理性回答"，过程中如果某一步错了，你还能精准定位，直接说"第二步的公式不对，重新算"，比整个推翻重问高效得多。

日常场景里的用法也很灵活。写方案时说"先分析用户痛点，再给出产品策略，最后做可行性评估"；分析数据时说"先核对数据口径，再计算指标，最后输出结论和建议"。"先、再、最后"这三个词，就是最朴素但最有效的推理链条提示。

2.5 技巧五：约束条件越具体，输出越可控

很多提示词之所以翻车，是因为需求描述得太空。你问"帮我写一封推荐信"，模型给你一封任何一个毕业生都能用的版本，因为你没告诉它推荐人是谁、被推荐人什么背景、申请什么岗位、强调哪些特质。

把约束条件加满，效果立刻不一样：

请以技术总监身份，为我的前下属写一封工作推荐信。他叫张明，在我团队干了3年Java后端，主导过日活50万用户的核心系统重构，擅长疑难问题排查，性格踏实。申请岗位是某中型互联网公司的技术专家岗。希望突出他的系统设计能力和跨团队协作经验，语气真诚朴实，不要夸张，600字左右。

你会发现，约束越具体，模型发挥"乱编"的空间就越小，输出的可用性越高。这里说的约束包括：字数范围、语气风格、目标受众、内容结构、需要涵盖的要点、需要避开的雷区。

需要注意的是不要一次性塞进太多互相矛盾的约束。比如你既要求"专业严谨、术语准确"，又要求"通俗易懂、适合小学生阅读"，模型会很为难。遇到这种情况，必须明确优先级，加一句"优先保证通俗性，专业术语首次出现时用括号解释"。

2.6 技巧六：用正向指令替代否定指令

这是一个很多人没意识到的细节。模型的指令遵循能力虽然强，但处理否定句时确实容易打折。你说"不要用太多形容词"，它可能反而用了更多形容词；你说"不要写得像AI写的"，它可能写出更浓的AI味。

原因在于模型是概率生成。你提到"形容词"这三个字，就在模型的词汇分布里激活了与"形容词"相关的表达区域，它本能地在这些区域里采样。所以正确的做法是，把你想避免的东西，换成你想让模型去做的具体动作。

举个例子，你写"不要用'总之'、'综上所述'这类词"效果一般，但如果你写"每个段落结尾都用一个问题或一个具体行动建议收束"，模型的注意力就被引导到"怎么收尾更好"上，自然就没空去写那些套话了。我打磨提示词时有个习惯，写完一句否定句后，都会强制自己重新改写成一句正向指令，这个习惯让我的提示词质量提高了一个档次。

2.7 技巧七：负面清单，把不想看到的内容明确写出来

虽然正向指令更重要，但负面清单依然有它的价值，尤其是当模型反复输出某种固定模板的时候。我最早发现这一点是在写小红书文案时，模型总爱在每个文案最后加一句"喜欢的姐妹点个赞收藏~"，加一次两次还好，每次都这样，内容就很乏。

这种时候，负面清单就派上用场了：

写一篇小红书风格的种草笔记，注意：

• 不要以"姐妹们"开头
• 不要使用"绝绝子""YYDS"等网络烂梗
• 结尾不要加求关注、求点赞的套话
• 每条建议都要有具体场景或亲身感受支撑

加了这份清单之后，输出质量提升明显。负面清单的表述也有一点讲究：尽量写成"不要xxx"的短句并列，而不是长篇大段的解释。模型对短小的禁止句的理解，比绕来绕去的复杂长句要准确得多。

另外一个技巧是把负面清单和正向约束搭配使用。光说"不要什么"，模型可能不知道往哪个方向用力；加上"应该做什么"，它就有了明确的着力点。这两者不是替代关系，是互补关系。

2.8 技巧八：迭代优化，用多轮对话打磨到满意

这个技巧最容易被低估，因为大多数人习惯"一次问完，不满意就删掉重问"。但实际上，模型最擅长的是"修改"而不是"一次写对"。你让它在一篇现有文章上调整，比让它凭空生成一篇好文章要稳定得多。

我的典型做法是分三轮走。第一轮（粗稿）：只给出任务核心，让模型快速搭出框架或初稿，这轮不追求质量，只追求方向和结构。第二轮（精修）：指出具体问题，比如"第二段太空，补充一个用户案例""开头不够吸引人，换一种更直接的引入方式"。第三轮（收口）：做最后的风格统一和细节润色，比如"全文语气再自然一点，避免太多长句"。

这个流程里有一个关键操作：每次修改都要指出具体的"位置 + 问题 + 期望"，而不是说"写得更好一点"。模型理解不了"更好"，但能理解"把第三点里的数据换成近三年的行业平均数据，并注明出处"。迭代优化用的好，一个中等偏上的初稿，完全可以被推敲成一篇高质量成品，而这正是提示词工程最有价值的地方。

2.9 技巧九：上下文锚点，把关键信息钉在最显眼的位置

现在主流的大模型都有上下文窗口的概念，但并不是窗口里的每一个字对输出的影响权重都相同。开头和结尾的信息，往往比埋在中间的内容更容易影响模型的输出。我把这称为"上下文锚点"。

实操中有三个用法。第一个用法是"开头定调"：在提示词的第一句就亮明任务类型和核心要求，比如"这是一篇面向投资人的行业分析报告，要求客观严谨"。第二个用法是"结尾强调"：在提示词最后重申最重要的约束，比如"再次提醒：数据必须使用2024年最新版本，并标注来源"。第三个用法是"中间补锚"：在长对话里，模型容易遗忘之前的细节，每隔几轮就在新提问里带上关键背景。比如"基于我们之前讨论的那个日活50万的项目背景，请继续分析会员体系的转化路径"。

这个技巧的重点在长任务中尤其有价值。很多人跟模型对话二十轮之后，感觉模型"变笨了"，其实不是它变笨了，是你早期的关键上下文已经被稀释得差不多了。适时重述关键信息，是解决遗忘问题最简单粗暴也最有效的方法。

2.10 技巧十：自我校验，让模型自己检查作业

模型输出的内容不能默认全对，这一点已经是共识。但大部分人只会事后自己慢慢核对，效率很低。其实模型具备最基础的"自查"能力，只要你主动触发它。

用法一：让模型检查事实。生成完内容后追加一句"请检查你上面的回答，列出所有可能存在的事实性错误或模糊表述，并给出修正建议"。很多时候模型能自己揪出"某数据存疑""这个结论超出已知信息范围"之类的问题。

用法二：让模型站在对立面。写完一个方案后，追加"请以一位严格的项目评审专家视角，指出这个方案里可能被挑战的5个薄弱点"。这一步本质上是让模型自我攻击，用来发现盲区非常有效。

用法三：让模型对照要求做验收。我们在写代码提示词时，会让模型生成完之后再做一次自查："请对照任务需求逐条检查代码，确认输入输出格式、边界条件、异常处理都覆盖到了，列出检查结果。"这个用法能让代码的首轮可运行率提高不少。

要注意的是，自我校验不等于真理性保证。模型的自查是在它自己的能力范围内进行的，所以关键领域的最终审核责任还是在你身上。但作为一个筛查机制，它能帮你过滤掉大量低级的、明显的错误。

3. 模板库：可以直接复制使用的结构化模板

3.1 模板的设计思路与使用说明

技巧讲完，正文里最值钱的部分来了。下面这些模板是我在真实项目里反复调校过的，每个模板的结构都是"角色 + 任务 + 受众 + 约束 + 输出格式 + 特殊要求"。你把方括号里的占位符替换成实际内容，就可以直接使用。

使用的时候有三条原则。第一，不要照搬，要根据每次的具体任务增删字段。模板的价值在于提醒你把该交代的信息交代全，而不是限制你的表达。第二，特殊要求部分不要省略，那里往往是决定输出是否"出彩"的关键。第三，第一次使用后，如果输出不理想，优先调整受众和"特殊要求"这两块，这两个地方对输出风格的影响最直接。

3.2 文案写作模板：适合公众号、小红书、产品推广

你是一位有[X]年经验的[领域]文案专家，擅长用[语气风格]与读者沟通。 任务：为[产品/项目名称]写一篇[平台/渠道]推广文案。 目标读者：[人群画像]，他们最关心的是[需求/痛点]。 核心卖点（按优先级排列）： 1. [卖点1] 2. [卖点2] 3. [卖点3] 内容结构要求： - 开头用[具体场景/反差提问]引起共鸣 - 中间按上述卖点顺序展开，每个卖点搭配一个使用场景或前后对比 - 结尾给出[行动引导]，不提"点赞关注"类套话 特殊要求： - [字数限制]字以内 - 不使用[禁用的表达] - 多用短句，避免[某类问题]

这个模板适用于大多数内容种草场景。我自己的经验是，"开头用什么方式引导"和"卖点如何排列"这两行，对最终文案的差异化影响最大，值得多花两分钟琢磨。

3.3 代码开发模板：适合功能实现、代码审查、技术方案

你是一位有[X]年后端/前端开发经验的[编程语言]工程师，代码风格偏好[风格，如：可读性优先、防御式编程]。 任务：实现[功能描述]，要求满足以下输入输出约定。 输入：[数据结构/参数说明] 输出：[数据结构/接口签名] 技术约束： - 使用[框架/库名称]，兼容[版本] - 不引入额外依赖（如有例外需说明原因） - 对[具体边界条件]做异常处理 - 关键逻辑处添加中文注释 实现步骤： 1. 先用200字以内说明整体实现思路 2. 再给出完整代码 3. 最后用列表列出需要测试的3个边界用例

代码场景里，我最重视的是"实现步骤"那一行。让模型先简述思路再写代码，看起来多了一步，但实际上能显著减少"代码能跑但逻辑有硬伤"的情况。边界用例列表也很有用，你可以直接拿来当测试清单用。

3.4 数据分析模板：适合业务分析、报表解读、问题归因

你是一位数据分析师，习惯用数据和逻辑说话，不凭空猜测。 现有数据：[数据背景/表结构/关键字段说明] （如方便，可粘贴数据样例，但需注意脱敏） 分析任务：[想解决的具体问题，例如：找出某指标下降的原因] 输出要求： 1. 先列出你判断问题所需的假设和数据口径 2. 再逐项分析，说明每项判断的依据和数据局限 3. 区分相关性和因果关系，因果关系需要给出可验证的解释路径 4. 最后给出3条可落地的行动建议，按优先级排序 特殊要求：术语尽量通俗，结论不要超过[字数/条数]

这条模板的价值在于"先列假设和口径"一步。数据场景里模型最容易犯的错是拿错口径或者脑补数据，加了这一步，它会被迫先想清楚"我到底要用哪些数、怎么算"，再往下走。

3.5 学习辅导模板：适合概念学习、习题讲解、知识梳理

你是一位[学科]老师，有[X]年一线教学经验，擅长把复杂概念讲得通俗易懂。 学生情况：[年级/基础描述，例如：刚学完一元一次方程，对应用题列式比较薄弱] 教学目标：掌握[知识点/技能]，能够独立完成[具体任务] 教学方式： 1. 先用一个生活化类比引入概念 2. 再给出标准定义，并解释定义里每个关键词的含义 3. 用一个由易到难的例题演示思路，分步骤讲解 4. 布置1道同类练习题，不要直接给答案，等我回复后再批改 特殊要求：讲解过程中每段不超过[字数]，如有术语，第一次出现时用括号加通俗解释

用好这条模板的关键是"学生情况"五个字绝对不能空着。很多学习场景下的模型回答之所以让人听不懂，就是因为模型默认站在大学生的水平上说话。你把自己的真实水平写清楚，输出会立刻变得亲切。

3.6 会议办公模板：适合会议纪要、周报日报、项目管理

请将以下会议/工作内容整理成标准纪要。 原始材料： [粘贴会议转写、聊天记录或零散工作笔记] 输出格式： **决议事项** 1. [事项]（结论：...） **待办任务** 1. [任务]（负责人：...，截止时间：...，关联事项：...） **风险与问题** 1. [风险/阻塞]（影响：...，建议应对：...） **下次跟进** - [下次需要确认的内容] 特殊要求： - 讨论过程只做摘要，不逐字转写 - 待办任务里的负责人，使用材料中的人名代词，不要编造姓名 - 全文控制字数在[字数]以内

办公场景是提示词工程里"结构化"价值体现最明显的地方。你给模型一堆零散的会议笔记，它会自动帮你补全归类框架。但有一个坑要注意：让模型归纳负责人时，它偶尔会脑补人名，所以一定要在特殊要求里写明"不要编造姓名"。

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

4.1 输出太泛，像说了又像没说

这是我被问得最多的问题。症状是模型回答内容正确但没有任何信息量，比如问"如何提升用户留存率"，它给你列了一堆"提高产品质量、加强用户沟通、优化产品体验"之类的正确的废话。

排查思路主要有三步：第一步，检查有没有给角色设定，没有角色设定时模型的输出会偏向"通用型"；第二步，检查有没有给受众和场景，缺少这两者，内容就没有针对性；第三步，检查有没有给输出数量或形式约束，比如"给出3条可立即执行的策略，每条用一句具体做法+一个数据指标来衡量"。

实际测试下来，"每条策略给出具体的执行动作和衡量指标"这句话，往往是最快见效的修复方式。它逼着模型从"讲道理"切换到"给方案"模式。

4.2 模型一本正经地编数据

这个问题在数据分析、行业报告类任务里特别常见。模型的本质是语言模型，不是数据库，它生成的数据大多是概率采样的结果，跟真实数据没有必然关系。明明没有查证能力，它却会自信地给出一个看起来非常精确的百分比。

我的躲坑方法有三个。第一，在提示词里明确写"只能使用题目中给出的数据，不得自行补充外部数据，如需额外数据请标注'需人工核实'"。第二，要求模型标注信息来源级别，比如"区分：题面数据、常识性数据、推测数据"。第三，关键数据问题直接换一种问法，让模型"不基于数据，而是基于逻辑推理"来回答，绕开编数据的风险。

说实话，目前还没有任何提示词技巧能让模型变出真实数据。所以这题的答案不是"防止它编"，而是"让它编的时候标注清楚，并且养成你本人复核的习惯"。

4.3 格式说好了却不遵守

很多人在我分享结构化技巧之后反馈，模型答应输出JSON，结果还是摆了Markdown表格；答应输出表格，还是忍不住加了很多解释说明。这种情况让人又气又笑，但解决方式其实很朴素。

首先，纯口头描述格式的遵守率，远低于"给一个格式示例"。你与其说"输出JSON格式"，不如直接写"输出格式如下：{"name": "xxx", "price": 12.5, "description": "xxx"}"。模型依样画葫芦的能力很强，但凭空理解抽象格式描述的能力有限。

其次，可以在提示词末尾加一句"只输出上述格式内容，不要输出任何解释性文字"。这相当于给模型一个"闭嘴"的指令，能显著提高格式纯净度。如果还是不行，大概率是对话历史里的干扰信息太多了，就可以考虑另起一个会话重新发起任务，或者用系统级指令来约束。

4.4 长对话中间"失忆"

长对话进行到二三十轮之后，模型开始出现"选择性遗忘"，早前说过的关键信息它会接不上。这不算bug，是上下文注意力机制的固有现象。解决思路在前面"上下文锚点"里提到过：在每次提问中重述关键背景。

我自己的习惯是，如果一个任务要持续多轮，我会在每轮提问的第一句都加上完整背景。比如"关于我们正在写的这个智能家居产品使用说明书，目标用户是50岁以上人群，语气要求平实耐心，现在请帮忙补充安全注意事项这部分"。一句话的背景重述，代价很小，但能保证模型始终在正确的轨道上，而不是凭着后面的碎片信息自由发挥。

4.5 避坑清单：我在实际使用中总结的几条铁律

把这些年踩坑的积累浓缩一下，一共五条。第一条，提示词里任何数字都必须有依据，包括字数、比例、人数，写错了模型也会照着错的方向跑。第二条，涉及品牌名、产品名、人名时，一定要在提示词里明确拼写，因为谐音和同义词会让模型跑偏。第三条，让模型做的任务越复杂，越要拆成多轮完成，"一次问完"往往是低质量输出的根源。第四条，负面清单要有度，通篇都是"不要"会让模型变得束手束脚，输出反而平淡。第五条，同一个提示词在不同模型上的表现可能差异巨大，跨模型使用时务必先做小范围测试再上生产任务。

我常跟团队的人说一句话：提示词工程不是为了写一段"漂亮的咒语"，而是为了把你想表达的需求，用模型能理解的方式表达清楚。你自己越清楚自己要什么，提示词就越容易写对；反过来，提示词写不好，往往不是词汇量的问题，而是需求本身还没想透。

最后再分享一个小技巧：每次遇到输出特别好的提示词，我都会顺手存进自己的模板库，附一句"当时为什么这样写"，几周后再翻出来看，会发现很多当时凭直觉写的细节，其实都是可以复用的方法论。这个习惯坚持了半年之后，我手里的高质量模板越来越多，写新提示词的速度也快了很多。希望这篇文章里的技巧和模板，也能成为你提示词库的第一批种子。