Claude 使用的 48 条方法：从单次提问到多模型工作流
48 Laws of Claude
这封 newsletter 以“48 Laws of Claude”为题，给出一组偏实操的 Claude 使用方法。正文片段覆盖了前 17 条，核心不是单个神奇提示词，而是如何按任务难度选择模型、如何让 Claude 在项目空间中长期继承上下文、如何用样例和完成标准约束输出，以及如何要求模型质疑用户观点、引用原始资料、避免编造缺失数字。对 AI builder 来说，最值得注意的是它把 Claude 当作一个可编排的工作系统：Haiku 处理低成本批量任务，Sonnet 承担日常写作和分析，Opus 用于复杂决策和高风险判断。
这篇文章最值得精读的地方，在于它把 Claude 的使用从“我该怎么问”转成“我该如何设计一套稳定的 AI 工作流程”。开头的核心判断是：不要把最强模型用于所有事情。作者把 Claude 新模型分成三类角色：Sonnet 5.5 适合日常写作、分析和办公；Opus 5.5 用于复杂商业问题、风险识别和多方案决策；Haiku 5.5 则作为便宜、快速、重复性任务的执行者。这个分层对 builder 很重要，因为 AI 成本和质量不是线性关系，真正有效的产品往往需要在不同任务节点使用不同模型。文章给出的多模型例子很直接：先让 Haiku 给 100 条客户消息分类，再让 Sonnet 回复重要消息，最后把困难投诉交给 Opus。它本质上是在描述一个轻量 agent pipeline，而不是一次性聊天。另一条主线是“把上下文产品化”：用 Projects 为业务、研究、写作、个人任务建立独立工作区，写入项目指令、上传文件、保存写作风格指南，让 Claude 在后续对话中继承偏好和约束。质量控制部分同样有价值：要求 Claude 先问关键问题，明确什么才算完成，基于原始文件回答，并在找不到价格、日期、来源或数字时写“Not found”。这些规则都指向同一个隐含判断：AI 的产出质量主要取决于任务边界、证据来源、验收标准和迭代机制，而不只是模型本身。
这篇文章把模型选择、成本控制、上下文管理和输出验收放在同一个操作框架里。它对正在做 AI 产品、内部自动化或个人工作流的人，比普通提示词清单更有参考价值。
builder 可以直接借鉴其中的分层思路，把复杂任务拆成分类、生成、审核、决策等节点，并为不同节点选择不同模型。产品团队也可以把“完成标准”“缺失信息不编造”“引用来源”等规则内置到 AI 功能中，降低错误输出带来的业务风险。
- 01不要默认使用最强模型：Sonnet 负责日常任务，Opus 负责复杂判断，Haiku 负责低成本批处理。
- 02Haiku 可用于邮件分类、常见问题回答、文档标注和信息抽取等重复任务。
- 03多模型工作流可以降低成本：便宜模型先筛选，中档模型生成，强模型处理困难案例。
- 04Claude Projects 可作为长期工作区，保存项目文件、指令、写作风格和偏好。
- 05重要任务要明确完成标准，并要求 Claude 在信息缺失时标记“Not found”。
- 06让 Claude 主动提问、批判首稿、挑战用户观点，有助于提升决策和输出质量。
- — 哪些任务真的需要 Opus，哪些只是因为默认习惯而浪费了强模型成本？
- — 如果把这套方法产品化，哪些规则应该写进系统提示词，哪些应该由用户在项目层配置？
- — 多模型工作流中的路由标准是什么：复杂度、风险、金额、客户等级，还是人工反馈？
- — 如何在不增加太多操作负担的情况下，让模型始终基于原始文件和可追溯证据回答？