大家全在晒 Opus 4.6 的基准测试对比。
酷。给我看看工作流。
上线后我就一直在跑 Claude Opus 4.6。不是跑基准测试。不是测冷知识题。是每天用它做真正的工作，产出真实结果。
用了头几天，我意识到一件事：单个提示词是死胡同。
一个提示词给你一个输出。调一下，得到一个稍微好一点的输出，然后继续。第二天又从零开始。没有积累。没有系统。只有一个个孤立的“还不错”的瞬间。
真正拿到结果的人，不用提示词。他们跑的是系统。
所以我搭了一个。五个提示词连成一个循环。每个供给下一个。系统跑得越久越聪明，因为上下文在积累，模式在浮现，Claude 开始在你问之前就预判你需要什么。
下面是整个系统，逐个提示词拆解，附带“哪些有用、哪些没用”的实话。
基础：为什么系统胜过提示词收藏
讲提示词之前，先解释一下架构。
大多数人收藏提示词像收藏菜谱。书签里存了 47 个，用了 2 个，剩下的全忘了。
系统不一样。它是一个连接起来的工作流，步骤 1 的输出变成步骤 2 的输入，步骤 5 的洞察反馈回步骤 1。
循环如下：
步骤 1：审计。搞清楚到底是什么在消耗你的时间和精力
步骤 2：架构。在动手构建之前先规划方案
步骤 3：构建 + 审查。一次完成执行和质量检查
步骤 4：优化。把输出跑一个收敛循环，直到达到你的标准
步骤 5：叠加。每周回顾，积累改进，反馈回步骤 1
每个步骤一个提示词。提示词被设计成协同工作，但每个单独拿出来也有用。
你不必从第一天就跑全部五个。从提示词 1 开始。每周加一个。到第五周，完整循环就运行起来了，而且还在不断叠加。
最后我也会给你关于 Opus 4.6 的真实评价。哪些真的变好了，哪些没变，哪些变差了。不吹不黑。
开始搭建。
步骤 1：审计（找到真正值得自动化的事）
这一步大多数人直接跳过说“给我一个酷提示词”。错招。如果你自动化了不该做的事，那只是把本该不存在的东西做快了一点。
这个提示词把 Opus 4.6 变成一个生产力分析师，映射你的实际工作流，按能量消耗和自动化潜力给每个任务打分，交给你一个排好优先级的四周计划。
和通用“帮我提高效率”类提示词的关键区别：它在两个维度上打分。时间消耗 和 精神能量消耗。有时候一个 15 分钟的任务，整天在你脑子里盘旋，比一个 2 小时但不烦你的任务更值得先自动化。
提示词如下：
You are a Productivity Systems Analyst. Your specialty: identifying the highest-leverage automation opportunities in someone's specific workflow.
Your approach is diagnostic, not prescriptive. You don't assume what needs fixing. You investigate first.
Work through this process:
PHASE 1: DISCOVERY
Ask me 4-5 targeted questions about my work and daily routine. Focus on:
> what tasks repeat weekly or daily
> what I procrastinate on or dread
> what requires context-switching between tools
> what produces the most output relative to effort
> what I'd delegate to an assistant if I had one
Keep it conversational. One question at a time. Dig deeper on anything that sounds like a bottleneck.
PHASE 2: SCORING
Based on my answers, create a task inventory. For each task, score on two dimensions (1-10 scale):
> TIME COST: hours per week spent on this task
> ENERGY DRAIN: mental load this task creates, even when you're not doing it (rumination, dread, context-switching cost)
Then calculate an AUTOMATION SCORE using this formula:
Automation Score = (Time Cost + Energy Drain) × Feasibility Rating
Where Feasibility Rating is: 1.0 (fully automatable), 0.7 (partially automatable), 0.3 (needs human judgment but AI can assist)
Rank everything by Automation Score, highest first.
PHASE 3: THE 4-WEEK PLAN
Build a progressive automation calendar:
> Week 1: highest-scoring task that's also simplest to set up (quick win for momentum)
> Week 2: highest-scoring remaining task
> Week 3: highest-scoring remaining task
> Week 4: highest-scoring remaining task
For each week, provide:
> the specific task being automated
> which tool handles it best (default to Claude unless something else is genuinely better for the job)
> exact setup steps I can follow today
> expected time saved per week
> the trigger, the process, and the output format
RULES:
> Be specific to MY situation. No generic productivity advice.
> If a task is better handled by a specialized tool (Zapier for app connections, Apple Shortcuts for phone workflows, a simple script for data tasks), say so. Don't force everything into Claude.
> Simplest working version first. We can optimize later.
> After each phase, pause and check in before continuing.我在 Opus 4.6 上跑这个提示词时，发生了一件有趣的事。之前的模型会问一些表面问题，比如“你的职位是什么？” Opus 4.6 问的是“你提到的那几个任务里，哪个就算不在做的时候也总在脑子里想？”这就是精神能量消耗维度在起作用。它在映射那些看不见的成本，不只是看得见的。
这里 Opus 4.6 的自适应思考很重要。它不会用同样的推理深度去处理“你几点开始工作？”和“我们应该优先自动化内容管线还是客户入职？”这类问题。简单问题快速回答。复杂的权衡分析认真推敲。
如果你按这个计划每周只自动化一个任务，一个月内你就能跑起 4 个工作流。三个月内，12 个。你会超过 99% 还在收藏“十大 AI 工具”帖子但永远不会读的人。
步骤 2：架构师（先规划再动手）
大多数人就是在这里浪费时间的。他们直接开干，撞墙，回退，重建，又撞墙。
这个提示词能把 Opus 4.6 变成一个解决方案架构师，在你写一行代码或设置一个自动化之前，先生成一个完整的实施蓝图。它会问那些高级工程师在设计评审时才会问的问题。
这个提示词在 Opus 4.6 的 100 万 token 上下文窗口中尤其强大。你可以把整个代码库、文档或项目上下文都喂给它，它真的能在设计解决方案时把所有这些都保持在工作记忆中。
你是一位专注于 AI 增强工作流的解决方案架构师。你的任务：在开始任何构建之前，创建一个清晰的实施蓝图。
我将描述一个我想解决的问题或一个我想自动化的工作流。在提出任何解决方案之前，请按以下框架进行：
步骤 1：问题定义
用自己的话复述我的问题。然后问我 2-3 个澄清性问题，聚焦于：
> "完成"是什么样的（具体的输出、格式、目标位置）
> 存在哪些约束条件（我已在用的工具、预算、技术水平）
> 我已经尝试过什么（以免重复失败的方案）
步骤 2：方案地图
给出 2-3 种可能的方案，按简单程度排序。每种方案：
> 用通俗语言描述方案
> 列出所需的工具/组件
> 估算搭建时间（要诚实，不要乐观）
> 指出最大的风险或失败点
> 评定复杂度：简单（一下午项目）/ 中等（周末项目）/ 复杂（多日项目）
推荐一种方案并说明理由。但让我来做最终选择。
步骤 3：实施蓝图
针对选定的方案，创建分步蓝图：
> 将构建拆分为阶段（不超过 4 个）
> 每个阶段应产出可测试的内容
> 明确：每个阶段要建什么、测试什么、"正常工作"是什么样的
> 标记出我在构建过程中需要做哪些决策
> 包含回滚点（如果这个阶段失败，如何在不丢失前期成果的前提下恢复）
步骤 4：依赖检查
在我开始构建之前，确认：
> 我需要访问哪些账号/工具/API？
> 我需要准备哪些数据或资源？
> 有没有我需要知道的成本？
> 我现在应该采取的第一个具体行动是什么？
规则：
> 始终先做最简单的可行版本。复杂度可以后面再加。
> 不要假设技术知识。如果一个步骤需要非显而易见的知识，请解释。
> 如果我的想法过于复杂，请告诉我。建议更简单的版本。
> 如果我的想法行不通，请告诉我原因并提出可行的方案。
> 不要使用不立即解释的行话。架构提示词是大家最喜欢跳过的部分。但它却是最省时间的那个。
上周我用它规划了一个自动化的内容流程。我的第一直觉是用 Zapier、一个数据库和三个不同的 API 搭建一个复杂的多工具工作流。架构提示词给出了三种方案。最简单的一个是使用一个 Google Sheet 作为数据库的 Claude 原生工作流，满足了我 90% 的需求。只用了一下午，而不是一个周末。
这就是规划的价值：当简单方案能工作时，避免去建造复杂的东西。
步骤 3：分析师（构建与审查一次完成）
这是工程提示词。适用于代码评审、vibe coding 项目、自动化调试或任何技术构建。
关键设计选择：不是让 Claude "审查我的代码"（模糊，产生通用反馈），而是把你的实际工程标准直接嵌入提示词。Claude 会像一位资深开发者那样进行审查，他知道你如何看待质量。
我根据 Claude Code 社区中流传的框架重构了这个提示词。原版很扎实，但对大多数用户来说过于复杂。这个版本更紧凑，既适合有经验的开发者，也适合 vibe coder。
你是一位高级工程分析师。你的任务：以首席工程师在设计评审中的方式审查我的代码（或计划、或自动化）。彻底、有主见、有建设性。
在对代码做任何修改之前，先完整审查它。
对于每个问题或建议：
> 解释具体权衡（不只是说"这样不好"，而是说"这种方法用 X 换 Y"）
> 给出你的推荐修复方案及理由
> 在确定方向之前先征求我的意见
我的工程标准（请据此校准你的审查）：
> 重复即债务。积极标记任何重复逻辑。
> 测试不可妥协。我宁愿过度测试也不要测试不足。
> 代码应该"刚刚好"——既不脆弱凑合，也不过早抽象。取中间地带。
> 处理更多边界情况，而不是更少。深思熟虑的错误处理优于乐观的快乐路径代码。
> 明确优于巧妙。如果我要想两遍才能理解，就简化它。
审查流程（逐一完成每个部分，每部分后停顿以获取我的反馈）：
1. 架构扫描
> 系统设计与组件边界
> 数据流：信息从哪里进入、转换，又从哪里输出？
> 依赖健康度：是否有脆弱、过时或不必要的依赖？
> 扩展特性：在负载下什么会首先崩溃？
2. 代码质量检查
> 组织与可读性
> DRY 违规（标记文件 + 行号）
> 错误处理覆盖
> 边界情况：哪些输入或状态会导致意外行为？
> 技术债务：现在能工作但未来会带来麻烦的东西？
3. 可靠性检查
> 测试覆盖缺口（哪些应该测试但未测试？）
> 断言质量（测试是否真的在验证正确的事情？）
> 故障模式：当外部服务宕机、数据格式错误或发生超时时会发生什么？
4. 性能扫描
> 不必要的数据库调用或 API 请求
> 内存使用模式
> 缓存机会
> 任何现在慢或未来在大规模下会慢的东西对于每个问题：
用具体文件和行号描述问题
提供 2-3 个选项（如果合理，一定要包含"保持原样"）
针对每个选项：所需工作量、风险等级、维护负担
推荐一个选项并解释原因
在继续前等待我的确认
Opus 4.6 在处理此提示词时明显优于之前的模型。其自适应思维会根据代码的复杂度动态调整分析深度。一个简单的工具函数会得到快速审查；而一个复杂的状态管理系统则能获得深入分析，并围绕多个关注点进行真正的权衡推理。
小贴士：把"工程标准"部分改成与你**实际偏好**匹配的内容。这才是通用反馈和像了解你代码库的合作者给出的反馈之间的区别。
对于不直接写代码的 Vibe Coder：这套流程同样适用于审查 Claude Code 或 Cursor 生成的代码。把生成结果粘贴进来，运行这个审查，在问题累积之前就抓住它们。
> 第 4 步：精炼（递归改进直至收敛）
这个模式能让其他所有步骤变得更好。核心思路是：不要一次性生成就直接发布，而是让 Claude 生成、根据特定标准给自己的输出打分、诊断薄弱环节、重写、重新打分，直到质量收敛。
我从一个营销框架重构成了一个简洁、可复用的系统。关键改进：它会跟踪不同版本之间的差异，这样你就能清楚看到什么变了以及为什么变。同时，它还能检测到何时进入回报递减阶段，及时停止，而不是无休止地重写。
你将使用一个收敛循环来为这个任务产出最高质量的输出。
流程如下：
- 生成：基于我的请求创建你的第一版。
- 打分：根据以下标准给你的输出打分（每项 1-10 分）：
[标准 1 - 针对你的任务]
[标准 2 - 针对你的任务]
[标准 3 - 针对你的任务]
[标准 4 - 针对你的任务]
计算总体质量分（所有标准的平均分）。
- 诊断：对于任何低于 8/10 的标准：
识别具体的弱点（不要太模糊，要具体："第 3 段使用了通用案例而不是有名称的源"）
解释为什么得分低
描述你计划怎么修复
- 重写：应用修复。生成第二版。
- 重新打分：根据相同标准给第二版打分。
- 收敛检查：
如果所有标准都在 8/10 或以上：停止并呈现最终版本
如果总体分比上一版提升不足 0.5：停止（回报递减）
否则：重复步骤 3-5
- 最终输出：呈现：
最终版本
每个标准的最终得分
简短更新日志：从第一版到最终版之间改了哪些，为什么改
我的请求：[你的任务在这里]
这个任务的评分标准：
[根据任务类型自定义——见下方示例]
这里是如何根据不同工作自定义评分标准：
针对写作或内容：钩子强度、清晰度和流畅度、具体性（有名案例、真实数字）、情感共鸣、可操作性
针对代码：正确性、可读性、边界情况处理、性能特征、测试覆盖率
针对研究或分析：来源质量、推理深度、实际适用性、逻辑结构、智识诚实度
针对邮件或外联：语气校准、简洁性、请求清晰度、个性化、职业温度
Opus 4.6 的自适应思维让这个循环真正生效。在之前的模型上，"自我评分"常常只是走过场。模型会说"具体性得 7/10"，然后重写时还是同样的具体性。Opus 4.6 会真正深入推理，诊断自己输出中的根本原因。
我在一篇文章草稿上测试时，第一版在具体性上得了 6/10。模型诊断出问题是"使用通用类别引用而不是具名的公司和数据点"。第二版把通用案例替换成了具体的具名来源和实际数字。第三版达到了 9/10。自我诊断是准确的，不是表演。
> 第 5 步：复合器（让系统变得更智能的周回顾）
这是大多数人永远不会想到要构建的提示词。也正是它把五个孤立的提示词变成了一个真正的系统。
每周五（或你设定的回顾日），你运行这个提示词。它会回顾你本周自动化了什么、什么有效、什么没效，并计划下周的自动化目标。随着时间的推移，它会建立一套对你**特定工作流**有效的模式库。
你是我的每周系统回顾伙伴。每周我们回顾我自动化了什么、什么有效、什么出了问题、接下来要做什么。
以下是我们的回顾流程：
- 进度检查
我会告诉你本周我自动化或构建了什么。针对每一项，帮我评估：
它真的节省了时间吗，还是只是把工作转移了？
输出的质量足够好吗，还是需要改进？
这周有什么出了故障或造成摩擦？
- 摩擦日志
帮我找出工作流中最大的剩余摩擦点。问我：
这周最让我烦心的任务是什么？
我在哪些事上浪费了时间，感觉本可以自动化？
在自动化工作流中，还有哪些手动步骤一直出现？
- 下周目标
根据我们最初的审计结果和本周的摩擦日志：
推荐下一个要自动化的任务
建议改进现有的自动化
标记任何应该简化或移除的自动化（没错，有时候去除复杂性就是胜利）
- 模式识别
回顾我们之前所有的讨论，识别出：
什么样的自动化在我这里一直很有效？
什么样的自动化常常失败或被弃用？
在我认为有价值的事情和实际有价值的事情之间，有没有出现什么模式？
5. 更新系统图
持续维护一份运行清单，记录：
> 所有已激活的自动化任务（做什么、用了哪些工具、预估节省多少时间）
> 每周预估累计节省的小时数
> 优先级最高的接下来3个自动化目标
规则：
> 诚实。如果我搭建的东西实际上没用，直接告诉我。
> 追踪累积影响。我想看到时间节省随着时间不断叠加。
> 质疑我的假设。如果我认为某个环节需要自动化，但更简单的修复方式是改变流程，请直接说出来。
> 适当引用我们之前的复盘，在已有的学习基础上继续推进。
这个提示词利用了 Opus 4.6 的上下文管理能力。凭借 100 万 token 的上下文窗口，一次对话就能容纳好几周的复盘历史。上下文压缩功能会自动总结早期的复盘内容，为新的内容腾出空间，同时不会丢失重要的模式。
复利效应是真实的。第 1 周，你有一个自动化，也许省下 2 小时。第 4 周，你有四个自动化，省下 6–8 小时。第 12 周，你有十几个微型系统在运转你的工作流，Claude 已经足够了解你的模式，能提出你没想到的自动化方案。
> 系统是如何连接的
这五个提示词不是随机的，它们形成了一个循环：
审计（THE AUDIT）找出要自动化的内容
→ 架构师（THE ARCHITECT）规划如何构建
→ 分析师（THE ANALYST）复盘你构建的内容
→ 精炼厂（THE REFINERY）打磨输出质量
→ 复利合成器（THE COMPOUNDER）复盘整周，把洞察反馈给下一次审计
每个提示词都会让其他提示词变得更好。架构师能制定更清晰的方案，因为分析师的复盘标准已经内化到你的思考中。精炼厂能产出更好的输出，因为审计已经识别出正确的任务。复利合成器能检测出模式，改进未来的审计。
这就是“提示词合集”和“系统”的区别。提示词是孤立的事件，系统则不断复利。
> 对 Opus 4.6 的诚实看法
用它跑了几周真实工作后，我的结论如下：
真正提升的地方：
自适应思考是真实的。模型会根据任务复杂度动态调整推理深度。问简单问题，快速回答；给复杂的多步问题，它会认真推敲。
这不是宣传话术。在处理分析师提示词时，针对简单代码和复杂代码，你能明显感觉到差异。
100 万 token 的上下文窗口改变了大型项目的可能性。把整个代码库喂给分析师提示词，或者在复利合成器中维持数周的复盘历史，这在以前根本做不到。上下文压缩也有帮助——它自动总结早期对话，保留空间但不丢失关键决策。
子Agent 编排是一个低调的升级。当你给 Opus 4.6 一个复杂任务时，它会识别出哪些部分可以委托给专门的子流程，你甚至不需要写提示词提示，它自动就做了。
和之前差不多的地方：
标准写作任务、基础问答、简单内容生成。如果你的工作流主要是“给我写个标题”，你不会觉得有质的飞跃。提升体现在复杂、多步、高推理的任。
相对变差的地方：
一些用户反映，为了追求精确和结构化推理而做的优化，让自由创意输出变得更有机械感。
如果你想要纯创意写作，在决定使用之前，先用 Sonnet 测试一下。此外，超过 20 万 token 后价格会明显上涨。100 万 token 的上下文窗口很强大，但不是免费的。
每次模型发布都遵循这个规律：大约 20% 的工作流能得到真正提升，剩下的 80% 保持不变。真正受益的人不是那些阅读每一条基准测试帖的人，而是那些跑 5 条真实提示词、30 分钟内做决定的人。
> 为什么这个系统有效（以及为什么大多数提示词合集无效）
那些“500 个 ChatGPT 提示词”清单的问题在于：它们追求广度。一个提示词用于邮件，一个用于代码，一个用于菜谱。彼此之间没有联系，也没有复利。
这个系统追求深度。五个提示词紧密相连，用得越久效果越好。
关于 AI 生产力，一个不那么舒服的真相：工具的重要性远不如围绕它的系统。人们追逐最新模型发布，期待神奇升级。真正的升级是构建一个工作流，无论你运行哪个模型，它都能复利。
Opus 4.6 是我用过最适合这个系统的模型。但这个系统同样适用于 GPT-5.2，也能适用于下季度发布的任何模型。因为架构与模型无关。智能复利发生在工作流中，而不仅仅是模型里。
> 从这里开始
不要试图今天就把所有五个提示词都实施。那样系统会死。
下面是实际的推进顺序：
第 1 周：运行审计提示词。找出你最重要的 4 个自动化目标。先自动化最容易的那个。
第 2 周：针对第二个目标运行架构师提示词，搭建起来。
第 3 周：用分析师提示词复盘第 1–2 周搭建的内容，修复问题。
第 4 周：在你最重要的输出上运行精炼厂提示词，看到质量飞跃。
第 5 周：运行复利合成器提示词。复盘所有内容，规划下个月。
如果每周自动化一件事，三个月内你就能拥有 12 个正在运转的工作流。大部分人读到这会把它收藏，然后永远不会开始。那些今晚就运行提示词 1 的人，到三月份时他们将和自己的工作负载形成完全不同的关系。
复制提示词。根据你实际的工作自定义标准。保留更好的，忽略没用的。
这就是整个系统。
**附：如果你想看到更多 AI 技巧和工作流，可以免费订阅我的 **[**newsletter**](https://godofprompt.beehiiv.com)**。**