Claude Opus 5.5 实战技巧：5个提效方法
缘起：一个让我崩溃的重构任务
上个月我接手了一个祖传 Java 项目，8万行代码，注释基本没有，而且文档停留在三年前。我需要把它的一部分业务逻辑迁移到 Go。第一周我纯手工读代码，每天下班眼睛发直，进度约等于零。
后来我开始认真地把 Claude Opus 5.5 当成日常工具来用，而不是偶尔问一问的聊天机器人。用了三周之后，同样的迁移工作进度直接翻倍。中间踩了不少坑，也摸出了几个真正提效的方法。下面这 5 个技巧，全是我实战里反复验证过的。
技巧一：先给上下文，再提要求
我最开始犯的典型错误是这样提问：
“帮我写一个订单超时自动取消的逻辑”
结果拿到的代码用了我项目里不存在的消息队列，命名风格也和现有代码完全不一致，改起来比重写还累。
后来我改成“三段式”提问，效果天差地别：
第一段：贴真实代码片段（不是伪代码，就是你现在项目里的样子）
第二段：说明约束条件
约束：
- 用 RabbitMQ，别用 Kafka（公司基建只有前者）
- 命名遵循 camelCase，日志用 SLF4J
- 订单状态机在 OrderStatus enum 里，不要新增状态
第三段：才提需求
“在这个基础上，实现订单创建后 30 分钟未支付自动取消，要求取消失败可重试。”
前后对比非常明显：之前我要花 20 分钟改 AI 的输出，之后基本贴进去微调变量名就能跑。一句话总结：模型不知道你的项目长什么样，你喂多少它才能还多少。
技巧二：让它先出方案，确认后再写代码
这是我吃过最大亏之后学会的。有一次让它直接改一个涉及缓存一致性的模块，它一次性输出了 300 行，我粗看没问题就合了，结果线上出了缓存击穿。
现在我固定的流程是：
- 先说：“不要写代码。先给我 2-3 个实现方案的对比，包括各自的优缺点和风险。”
- 它列出方案后，我指出偏好，并追问边界情况：“方案 B 在 Redis 挂掉时行为是什么？”
- 方案敲定后：“好，按方案 B 实现，注意刚才提到的降级逻辑。”
这样做的核心好处是：错误发生在讨论阶段，成本是一分钟；发生在代码阶段，成本是几小时的排查。 而且看方案比看代码快得多，特别适合大改动。
技巧三：用增量迭代代替“一步到位”
新手最常见的幻觉是：一个 prompt 塞进全部需求，期望拿到完美产出。我试过让它在一次对话里写一个完整的权限系统——输出看似完整，实际上角色继承那块逻辑是错的，而且错得很隐蔽。
有效的做法是拆成小步：
第 1 步：定义 RBAC 的数据模型（表结构 + 实体类）
第 2 步：实现权限校验的核心函数
第 3 步：加上角色继承
第 4 步：写单元测试覆盖上面三步
每一步完成，我都跑一下测试或编译，确认没问题再进下一步。如果第 2 步出问题，回退成本就是一步，而不是推倒重来。
另外一个关键动作：发现问题时直接贴报错原文。我经常看到有人自己总结“好像是数据库连接的问题”，结果模型往错误方向修半天。直接把完整的 stack trace 贴进去，它基本一次就能定位。
技巧四：长对话会“漂移”，要主动拉回和总结
长会话有个隐蔽问题：聊了十几轮之后，模型会开始“忘记”早期的约束。我遇到过一次，开头明确说了“不要引入新依赖”，聊到第 15 轮时它悄悄用上了一个新库，而且语气自然得我都差点信了。
我的对策有两个：
1. 关键约束写在开头，隔几轮重申一次。 尤其是技术栈限制、代码风格这类容易被“优化”掉的东西。
2. 阶段性让它总结。 比如做完一个模块后说：
“总结一下我们目前确定的架构决策和已完成的模块，以及待办事项。”
它的总结本身就是一次上下文校准——如果总结里出现和你记忆不符的内容，说明漂移已经发生了，立刻纠正。这个总结还能直接存进项目文档，一举两得。
技巧五：把它当 Reviewer，而不只是 Writer
这是我觉得被低估最厉害的用法。自己（或同事）写完代码后，我习惯这样让它审：
请以严格的 code reviewer 身份审查这段代码，重点关注：
1. 并发安全问题
2. 异常处理的漏洞
3. 潜在的性能问题（这段在高频路径上）
不要泛泛而谈，每个问题给出具体行号和修改建议。
实测它找出过我自己漏掉的整型溢出、一个没加锁的共享 Map，还有一处 SQL 拼接注入风险。当然它也会报一些“假警”——比如偶尔会把理论上不可能到达的分支标成严重问题——所以我把它当成提高我 review 覆盖率的工具，而不是最终裁决者。
类似的还有让它写测试用例，尤其是边界情况：“帮我列出这个函数可能出错的 10 个输入”，往往能想到我没想到的。
诚实的局限性
最后说几句实话，免得你期望过高：
- 它对超长上下文里“埋”的信息会漏。 你贴了 5000 行代码，它可能只抓住和问题直接相关的部分，周边的隐含依赖需要你自己指出来。
- 它对最新框架版本的 API 有时会自信地说错。 涉及刚发布的大版本，一定要对照官方文档验证。
- 复杂业务规则的正确性它保证不了。 它懂“怎么写”，但不懂“你公司为什么这么规定”。涉及钱的逻辑，逐行自己过。
- 它倾向于顺着你说。 如果你问“这样做对吧”，它大概率说对。想听到真话，就问“这个方案有什么问题”。
一句话总结：把 Claude Opus 5.5 当成一个知识面很广、但需要你给方向和把关的资深同事——方向给得越清楚，产出越好；全程放养，摔的坑都是你的。