Claude Opus 5.5 的消息一出，很多群里都在讨论，但讨论最热闹的不是 benchmark 数字，而是“焚诀”这个词。说白了，焚诀不是什么官方名词，对应的是大家最关心的一件事：新模型到底怎么用才能榨出真实力。这代 Opus 在指令跟随、长上下文和结构化输出上的表现，确实值得单独写一篇使用心得。这篇文章就直接从实操出发，聊聊我拿到 Opus 5.5 之后测试出来的提示词写法、任务拆分方法、结构化输出方案，以及踩过的几个坑。适合正在用 Claude 写代码、做分析、跑内容流水线的朋友参考，当然如果你只是偶尔问问问题，也能从中找到一套更省力的提问框架。
我一直觉得，模型再强，提示词写不对，等于开着跑车挂一档。这篇文章的核心就是把“焚诀”还原成一套可以落地的操作流程：需求怎么写、任务怎么拆、输出怎么校验、报错怎么查。顺着这个思路走下来，你会发现 Opus 5.5 的能力冗余会被明显激活，而不是只用来写写周报。
1. 新版本发布，先搞清楚它解决什么问题
1.1 这次升级到底值得关注什么
从使用者的角度去看 Opus 5.5，这次最值得关注的不只是“变聪明了”这种模糊感受，而是几个直接改变工作方式的能力点。
第一个是复杂指令的跟随能力明显变强了。以前写多步骤提示词，模型经常会在中间某一步“跑偏”，比如你要求先分析再建议，它可能直接跳到建议，把分析压缩成一行字。5.5 在长指令链上的稳定性好了很多，我测试过一个包含 9 个约束条件的任务，它基本能按顺序执行完，这在之前是比较吃力的。
第二个是长上下文的利用效率。它对于“淹没在长文档里的信息”的提取能力提升明显。我之前拿一份 40 页的项目复盘报告去问它某个指标的推导逻辑，它能准确引用到具体章节，而不是含糊其辞。这个能力对做研究、审合同、读代码库的人来说非常关键。
第三个是结构化输出的成功率。只要求“输出 JSON”和给出明确 Schema 之后强制输出，两者的成功率差距依然存在，但在 5.5 上这个差距明显缩小了。也就是说，你给它的约束越清晰，它越能稳定返回合法格式，这对跑自动化流程的人来说等于少写很多解析容错代码。
1.2 哪些人适合现在直接上手
先泼一盆冷水：如果你只是偶尔问“帮我写个请假邮件”，那 5.5 带来的感知提升不会太明显。这个版本的真正价值集中在需要“多轮深度处理”的场景里。
具体来说，适合现在上手的有三类人。第一类是程序员，用它的代码解释、重构、Review 和测试用例补全能力，提效最直接。第二类是做数据分析的人，它能同时处理数据解读、图表描述和结论撰写，把它当作一个能沟通的分析助理来用。第三类是内容生产团队，用它的长文规划、资料整合、多版本改写能力，可以把选题到初稿的流程压缩一大截。
不适合的也有，比如希望它 100% 不出错、不产生幻觉的人。任何大模型都会有“自信地胡说”的时候，Opus 5.5 也一样，只是概率更低。你要把它当成一个“能力很强但需要检查的下属”，而不是“全知全能的神”。
2. 焚诀入门：把提示词当“需求规格说明书”来写
2.1 低质量提示词的症状和根源
我见过太多人把 Claude 当搜索框用，上来就是一句“帮我写个方案”。这个写法的核心问题在于：需求里的“隐含条件”太多了。什么叫好的方案？预算多少？给谁看？需要多详细？你什么都没说，模型只能按照它训练数据里最常见的“通用方案”来生成。结果就是你拿到一份看起来没毛病、但没有任何针对性的内容。
这种低质量提示词通常有几种症状。第一种是万金油回答，放之四海而皆准，比如“加强团队协作”“优化流程”“提升效率”这类正确的废话。第二种是结构货不对板，你要的是项目排期，它给你写成了指导思想。第三种是细节完全缺失，没有数据、没有时间线、没有责任人。
根源就是你的需求描述不够“规格化”。想想看，你让一个外包开发给你做系统，会不会只丢一句“做个商城”？肯定不会。你会告诉他商品怎么管理、订单怎么流转、支付对接哪家。提示词也一样，它就是你的需求规格说明书。
2.2 高质量提示词的三段式结构模板
我自己写提示词的习惯，是严格按“角色-目标-约束-输出格式”四块来组织，可以合并成三段式：
- 角色与背景：告诉模型它站在什么立场，面对什么情况。
- 目标与任务：明确要完成什么，以及优先级。
- 约束与输出格式：说清楚不能做什么、必须输出什么结构。
这里给一个可以直接套用的模板：
你是一个有10年经验的【行业角色】。 背景：我们正在【项目描述】，目前遇到【具体问题】，需要你帮我们【任务目标】。 要求： 1. 先做【动作A】，再输出【结果B】。 2. 【需要遵守的限制条件】。 3. 如果信息不足，明确列出需要补充的内容，不要自行假设。 输出格式： - 第一部分：一句话结论 - 第二部分：按要点的详细分析，每个要点不超过50字 - 第三部分：下一步行动清单，使用有序列表这个模板不是死规矩，核心是“把话说完整”。你每次写提示词前花 30 秒自检几个问题：模型知道自己的角色吗？知道用户是谁吗？知道成功标准是什么吗？知道格式长什么样吗？四个问题都能回答，产出的质量至少提升一个档次。
我在实测 Opus 5.5 时发现一个有意思的现象：它对“角色设定”的响应比旧版本更稳定。以前你设定“资深数据分析师”它可能只在开头提一句，后面就忘光了。现在它会在整个回答里保持专业口吻和数据思维。这说明角色提示词和模型能力是叠加效应，值得认真写。
2.3 Few-shot 示例的精确校准价值
如果说三段式结构是方向正确，那 Few-shot 示例就是把“方向正确”升级成“结果可靠”。原因很简单：模型对抽象描述的理解可能有偏差，但你对示例的理解一定没偏差。
举个例子，我要它写一个 SQL 查询的解读说明。我不会只写“请用通俗语言解释这段 SQL”，我会给它一个参考示例：
【示例】 SQL：SELECT user_id, COUNT(*) FROM orders GROUP BY user_id HAVING COUNT(*) > 5 输出： - 目的：找出下单超过5次的用户 - 关键操作：按用户分组，统计每个用户的订单数量，过滤出大于5的用户 - 潜在用途：识别高活跃用户，做定向运营然后我再丢给它真正要解释的 SQL，并要求“按上述格式输出”。这样出来的结果不止是内容准确，连详略程度、口吻、结构都是你想要的。
这里有个边界：Few-shot 示例不是越多越好。两三个高质量示例就够用了，放太多反而会让模型陷入对示例形式的过度模仿。我自己在 5.5 上的经验是：一个对比型示例（好/坏各一个）加一个标准型示例，效果最好。
3. 焚诀进阶：复杂任务要拆成流程，而不是一口气怼给模型
3.1 任务树的拆分法则
很多人用大模型做复杂任务失败，根本不是模型能力问题，而是“任务颗粒度”问题。你让它“写一份市场调研报告”，它确实能写，但大概率是一份空泛、没有真实数据、缺乏深度的内容。这不是模型笨，是你给的任务太大、太模糊。
我的经验是：任何超过 1000 字的产出任务，都应该拆成多个子任务，分步交给模型。原则很简单：一个提示词只解决一个核心问题。
比如“写一份市场调研报告”可以拆成这些子任务：
- 明确调研目标和目标读者，输出调研框架。
- 针对竞品、用户需求、市场趋势三个维度，分别收集信息和分析。
- 基于分析结果形成核心结论。
- 把结论组织成完整的报告结构，填充细节。
这样做的逻辑是：每拆一层，模型的注意力就越集中，上下文里的无关信息越少，输出质量越稳定。这就像你带新人，一次性交代十件事他肯定做不好，但分五次每次交代两件事，效果会好很多。我把这个经验用 Opus 5.5 测试过，拆解后再汇总的版本，内容深度明显优于一次性生成的版本。
3.2 用 Plan-Act-Check 循环驾驭长任务
任务拆完之后，执行过程也需要节奏管理。我常用的方式是“计划-执行-检查”三步循环，放在多轮对话里跑。
具体操作是这样：
- Plan（计划）：第一轮让模型基于任务目标输出执行计划，包括步骤、每步输出物、需要的信息。
- Act（执行）：确认计划没问题后，按步骤逐个执行。每执行完一步，把结果精简后传给下一步，而不是把整个历史都堆积在上下文里。
- Check（检查）：全部执行完后，让模型自己检查一遍，找逻辑漏洞和遗漏点，然后再补充修正。
用一个例子说明。假设我要让模型写一个产品功能上线方案，我的第一轮提示词可能是：
我们需要为【某SaaS产品】设计一个“工作台自定义布局”功能的上线方案。 请先给出执行计划，包括：目标拆解、用户场景分析、功能范围界定、开发阶段划分、上线检查清单。 计划里需要说明每个阶段的输入和输出，以及你认为需要我补充的信息。 先不要开始写方案正文。拿到计划后，我再逐步推进。每轮对话之间我会手动做一次“信息精简”，把前一轮的核心结论整理成一段摘要，再传给下一轮。这个习惯对长任务特别关键，因为上下文窗口再大也有边界，而且模型对距离较远的早期信息容易“注意力衰减”。
3.3 上下文管理细节：防止模型“中途失忆”
说到注意力衰减，这是长对话里最常见的隐性坑。你前五轮对话里提到的某个关键约束，到第十轮它可能已经不再遵守了。这不是 5.5 独有的问题，所有基于 Transformer 的模型都有类似现象，只是程度不同。
三个可落地的防“失忆”方案：
定期重述关键约束。每轮对话末尾或开头，把最关键的 3-5 条约束再写一遍。这看起来冗余，实测对防止跑偏很有效。这也是为什么人工作的时候要反复对需求。
让模型产出阶段性小结。每完成一个子任务，让模型用 100-200 字总结当前结论、未决问题、下一步计划。这个小结会成为下一轮对话的“结构化记忆”，比把整段历史对话全量保留更省 token，也更能抓住重点。
用外部记录兜底。重要信息不要只存在于对话里，我会单独维护一个项目说明文件，每轮对话之前把最新的文件内容粘贴给模型，然后才发起新任务。这样即使模型“断片”，我也能通过重新输入把信息拉回来。
在 Opus 5.5 上，这个“摘要驱动”的写法提升很明显。它阅读短摘要的能力更强，也更愿意基于摘要做延伸，而不是被历史的细枝末节带偏。建议大家今天就开始试。
4. 焚诀高阶：结构化输出、工具调用与结果校验
4.1 严格输出 JSON 的正确姿势
如果你的下游是自动化流程，那“让 Claude 输出 JSON”这件事就不能靠祈求，得靠定义。定义分三层：字段名、字段类型、字段约束。
先看一个反例。提示词里写“请以 JSON 格式返回，包括标题、摘要、关键词”。模型大概率会输出一个合法的 JSON，但字段名可能是title、summary、keywords，也可能写成article_title、brief、tags，类型也可能不一致。这对解析代码来说就是灾难。
正确做法是给出显式 Schema，就像接口文档一样：
请严格按以下 JSON Schema 输出，不要包含额外字段和解释文字： { "title": string, // 文章标题，不超过30字 "summary": string, // 摘要，50-80字 "keywords": string[], // 关键词列表，3-5个 "sections": [ // 章节列表 { "heading": string, // 章节标题 "content": string // 章节正文 } ] }加一句“不要包含额外字段和解释文字”也有用，否则模型经常在 JSON 外面包一层废话。这类约束在 5.5 上执行得更干净，我测试连续生成 20 次，解析失败率接近零。
4.2 用后处理校验兜底，别信任任何一次输出
哪怕 5.5 的稳定度已经很高，我在生产环境里依然不会直接信任原始输出。校验逻辑通常分两层。
第一层是格式校验，用代码检查 JSON 是否合法、字段是否存在、类型是否正确。第二层是业务校验，比如关键词数量是否在范围内、摘要长度是否满足要求、章节是否为空。前者用json.loads就能做，后者需要写一点业务逻辑。
如果校验不通过怎么办？不是直接抛错，而是把校验错误反馈给模型，让它修正。这是一个非常高效的做法，因为它利用了模型自身的纠错能力。我常用的提示词是这样的：
你刚才的输出不符合要求： - 期望字段：title, summary, keywords, sections - 错误原因：缺少字段 "keywords" 请根据上述原因重新生成完整 JSON，不要输出其他内容。在高频调用场景下，这个“校验-反馈-重试”循环可以把最终成功率拉到 99% 以上。我的建议是把它封装成一段通用的函数代码，每次调用模型后自动执行。
4.3 长文生成的安全带方案
长文生成最容易出现的问题是：写了一半开始重复观点、结构失衡、开头详实结尾草率。针对这个问题，我用的是“大纲先行-分段生成-统一润色”的三段路径，在这里分享给读到这里的各位。
第一步，先让模型基于主题生成大纲，大纲要细化到二级标题，并标明每节大概字数和核心观点。第二步，按大纲逐节生成内容，每节单独发一次请求，上下文里只放大纲和该节要点，不放已经写好的其他章节。第三步，全部生成后，把所有章节拼到一起，让模型做一次统一润色，重点检查过渡是否自然、是否有重复内容。
这个方法的好处有三点：单次生成的长度可控、模型能保持对当前小节的专注力、汇总后风格更容易统一。配合 Opus 5.5 的较长上下文和指令跟随能力，这个流程跑起来非常顺。我个人用它写一篇 6000 字左右的分析文章，时间能压缩到 20 分钟以内，质量也远高于一口气生成的版本。
5. 常见问题速查表与排错思路
下面这几个问题是我自己测试和网友反馈中出现频率最高的，直接整理成速查表，方便遇到问题时对照处理。
| 现象 | 可能原因 | 排查思路 | 预防方案 |
|---|---|---|---|
| 输出内容正确但格式不规范 | 提示词里只有格式指令没有 Schema 示例 | 检查提示词是否给了显式字段定义和示例 | 用代码块给出完整 JSON Schema + 示例 |
| 长对话进行到后面忘了前面的约束 | 上下文距离太远，注意力衰减 | 将关键约束在最新一轮重述 | 每轮开头重述关键约束，或使用摘要机制 |
| 给出的回答太泛泛而谈 | 提示词缺少背景和角色定位 | 补充行业背景、目标读者、上下文信息 | 完整使用“角色-目标-约束-输出格式”模板 |
| 单次生成内容过长导致逻辑松散 | 任务颗粒度过大 | 拆分为多个子任务逐步完成 | 先大纲后分段生成，每段聚焦一个子主题 |
| 模型自信地说出错误事实 | 知识时效性/训练数据限制 | 对关键数据要求它提供来源，二次验证 | 关键事实用检索工具或人工核对，不轻信单次输出 |
| 中文输出有“翻译腔”或AI味 | 提示词没有限定语言风格 | 要求使用具体、口语化表达，禁用特定词汇 | 在提示词中加入风格约束和正面/反面示例 |
| 输出中途被截断 | 单次输出长度达到上限 | 分多次生成，或使用“继续”指令 | 长文采用分段生成策略，控制单次输出字数 |
排错的通用思路也很简单：先判断是“没听懂”还是“没做到”。没听懂就去改提示词，补充上下文和示例；没做到就去加约束和校验，压缩自由度。这两个方向搞反了，会一直做无效调试。
另外一个容易忽略的点是让模型自己解释原因。当你发现输出明显不合理时，可以追问一句：“你为什么这么判断？依据是什么？”它给出的推理过程往往能帮你定位是提示词里的哪个信息引起了误解。这个技巧在 Opus 5.5 上效果不错，因为它的推理链路更完整、更容易被检查。
最后再说说成本与配额的感受。Opus 5.5 的性能更强，但调用成本也不低。我的做法是区分场景：简单任务用轻量模型处理，只有复杂推理、长文生成、精细分析才用 Opus 5.5。别拿着牛刀杀鸡，这不是模型的问题，是用法的问题。需要频繁调试的时候，先用历史对话和缓存减少重复请求，等提示词稳定了再批量调用，钱能省下不少。
我个人在实际操作中最受用的一条经验是：永远把“模型输出”当成第一版草稿，而不是最终结果。哪怕是 Opus 5.5 这样强的模型，它输出的内容也需要经过你的业务判断。你可以让它帮你省掉检索、列提纲、写初稿这些高耗时环节，但“审核、决策、定稿”这个闭环一定要攥在自己手里。把这套“焚诀”记下来，多跑几遍，你自己会慢慢形成一套更顺手的招式。
