Claude Opus 4.8 进阶用法：从入门到精通

一个真实的痛点

上个月我接了个重构老项目的活：一个 3 万多行的 Python 数据处理系统，没有文档，注释寥寥，而且有一半代码是五年前写的。我一开始用很随意的方式向 Claude 提问——“帮我重构这个模块”——结果它给的方案泛泛而谈，改动建议完全覆盖不到我项目里那些隐藏的依赖关系。改了三次都不满意之后，我才意识到问题不在模型，而在我的用法。于是花了一个周末系统地研究了 Opus 4.8 的进阶特性，效率直接提升了不止一个量级。下面把这些实操经验整理出来。

第一步：别再“一句话提问”，改用结构化提示

入门阶段最大的误区就是把 Claude 当搜索引擎用。Opus 4.8 对结构化输入的响应质量，远远高于口语化的碎片提问。我现在的提示模板长这样：

## 背景
这是一个 Django 2.2 的订单系统，数据库为 PostgreSQL 12，
不允许升级框架版本。

## 任务
重构 services/order_service.py 中的 calculate_refund 函数，
要求：
1. 保持对外接口不变
2. 拆分超过 50 行的函数
3. 补充类型标注

## 约束
- 不要引入新依赖
- 测试用 pytest，现有测试在 tests/test_refund.py

## 输出格式
先列出你的改动计划，等确认后再输出完整代码。

关键在最后那一句“先列计划再写代码”。这是我从踩坑里学来的：直接让它输出完整代码，经常一上来就写几百行，方向错了只能全部推翻。让它先给计划，我确认一遍，纠错成本几乎为零。

第二步：用长上下文，但要会“喂”

Opus 4.8 的上下文窗口够大，我第一次尝试时直接把整个项目的压缩包丢进去，结果发现效果反而变差了——无关代码稀释了重点。后来我摸索出的做法是：

1. 只喂相关模块及其直接依赖。重构 order_service.py 时，我会附上它 import 的 models.py、utils.py，外加两个调用它的文件。
2. 附上 3-5 个“代码风格示范”文件。告诉它“新代码请参照 payment_service.py 的风格”，它输出代码的风格一致性会明显提升。
3. 把报错日志完整贴进来，但删掉重复堆栈。我试过贴 2000 行日志，它会被中间的重复内容带偏；删到只留关键部分前后各 50 行左右，定位就精准多了。

第三步：多轮迭代，而不是一次到位

这是我认为 Opus 4.8 最被低估的用法。它的对话记忆能力足以支撑长时间的迭代式开发，我典型的会话流程是这样的：

• 第 1 轮：给背景和任务，要计划
• 第 2 轮：指出计划里的问题（“RefundCalculator 不需要知道用户表结构，改成传参”）
• 第 3 轮：确认后让它写代码
• 第 4 轮：把测试失败的输出贴回去，让它修

有个意外发现：在后续轮次里明确说“保留上一版里的 retry_decorator，只改异常处理部分”，它能很精确地做局部修改，不会像我担心的那样整段重写。但前提是修改指令要具体——“再优化一下”这种话只会让它大动干戈。

第四步：让它扮演审阅者

写完代码后，我会开一个新会话，只贴代码和需求，然后说：

你是一个严格的 code reviewer。假设写这段代码的人明年就离职，找出所有会坑到接手人的问题：隐式依赖、边界条件、错误处理缺口、命名误导。按严重程度排序输出。

用这种“挑刺”框架得到的审查结果，比“帮我看看这段代码有没有问题”详细得多。我统计过一次：前者平均能找出 6-8 个真实问题，后者通常只给两三条客套的泛泛之谈。

第五步：善用思维链控制

遇到复杂调试，我会加一句“在给出结论前，逐步列出你的推理过程”。Opus 4.8 的推理过程本身就有诊断价值——有一次它推理到一半写“这里假设 order.status 一定是字符串，但 models 里定义的是枚举……”，直接点破了我排查两小时都没找到的 bug。

反过来，对于简单任务，加一句“直接给出答案，不需要解释”反而更快更干净。

实用技巧清单

• 给反例比给规则有效。“不要用 except: pass”比“请做好异常处理”管用十倍。
• 长会话要定期“存档”。超过十轮之后，我会让它输出一份“当前方案摘要”，开新会话时贴进去，避免上下文末端的细节被淡化。
• 代码让它分文件输出，每个文件单独一个代码块并标注路径，方便直接落盘。
• 拿不准时让它给两个方案：“给出方案 A（保守，改动最小）和方案 B（彻底，但需要迁移数据），并对比风险。”

诚实的局限

最后说说不足，免得你期望过高：

1. 超长文件的中间部分仍会被弱化。我有一次贴了 1500 行的配置文件，它对开头和结尾的内容处理得很好，中间一段配置就是被忽略了。关键内容尽量放在开头，或者明确引用行号。
2. 对冷门框架的 API 细节会编造。它推荐过一个参数名听起来很合理的函数，我查文档发现根本不存在。涉及不熟悉的库，务必让它标注“以下 API 用法请验证”。
3. 上下文太长时指令遵循会变松。明确写出“本次回复只做 X，不做 Y”，比依赖默认行为可靠得多。

总体来说，Opus 4.8 的能力上限很高，但这个上限需要你用结构化提示、迭代式工作流和明确的约束条件去够到。把上面这套流程跑顺之后，我那个重构项目的交付时间从预估的三周压到了一周半——这大概是最能说明问题的一组数字了。