我排查过一个典型的认知冲突：团队里两位工程师用同一个 AI 编程工具，产出质量天差地别。一个还在写“请帮我实现一个用户登录功能”，另一个已经开始在 prompt 里嵌入类型定义和测试框架。这背后的差异，其实反映了 AI 编程的范式转变——从 Prompt 工程转向 Agent 原生交互。
Claude Code 是 Anthropic 推出的终端 AI 编程工具，和 Cursor、Copilot 不同，它直接在命令行运行，能读写文件、执行命令、管理 git。过去半年我重度使用它重构了三个中型项目，踩了不少坑，也总结出一些真正有效的用法。
核心转变：别再写“指令”，写“上下文”
传统 Prompt 工程的核心是“告诉 AI 做什么”，而 Agent 原生交互的核心是“让 AI 理解它面对的是什么”。
反模式：
请帮我修复这个 bug
正确做法：
当前目录是 /src/core，我遇到了一个 NPE，堆栈在 worker.go:145。
这个方法的预期行为是：当队列为空时返回空切片而非 nil。
请阅读 worker.go 文件，定位问题并修复。
区别在哪？后者提供了：工作目录 + 问题现象 + 预期行为 + 具体文件。Claude Code 不需要猜测上下文，直接进入解决阶段。
实际项目中，我会在 prompt 开头固定放一段“上下文声明”：
项目：微服务网关
语言：Go 1.22
框架：gin + redis
当前文件：middleware/ratelimit.go
问题：令牌桶算法在高并发下漏桶
预期：每个 IP 的请求间隔至少 100ms
这样 Claude Code 的回复准确率从 40% 提升到 80% 以上。
实战技巧一：用 / 命令管理对话状态
Claude Code 内置了 / 命令，很多人只用 /help。但真正有用的命令是这几个：
/clear：清空对话历史。当 Claude 开始重复之前的错误推理时，直接清空重来，比继续纠正更高效。我平均每 3-5 轮对话用一次。
/compact：压缩上下文。对话长了之后 token 消耗大，用这个命令让 Claude 自动总结关键信息，保持上下文新鲜。
/review：让 Claude 审查当前文件的变更。我每次提交前都跑一遍，能发现不少遗漏的边界情况。
/init：初始化项目时用。Claude 会扫描项目结构，生成一份“项目理解文档”，后续对话直接基于这个理解，不用每次都重复上下文。
实战技巧二：分阶段 prompt 策略
我不写一个长 prompt 让 Claude 一次性做完，而是拆成三个阶段：
阶段一：探索（Exploration）
请阅读 src/ 目录下的所有文件，列出当前项目的模块划分和依赖关系。
重点关注 database/ 和 api/ 这两个目录。
阶段二：方案（Proposal）
基于上面的分析，我需要重构用户认证模块。
当前问题是 JWT 过期后没有刷新机制。
请给出 2-3 种实现方案，对比优缺点。
阶段三：实现（Implementation）
我选择方案二（双 Token 机制）。
请按以下步骤实现：
1. 在 auth/ 目录下创建 refresh_token.go
2. 修改 middleware/auth.go 添加刷新逻辑
3. 更新路由注册
每完成一步请确认。
这样每个阶段 Claude 的上下文都很干净，不会因为长对话而“失忆”。而且分阶段的好处是——如果方案不合理，我在第二阶段就能纠正，不用等全部代码写完才发现方向错了。
实战技巧三：测试驱动 prompt
我发现 Claude Code 写代码时经常漏掉边界情况，所以现在强制在 prompt 里先写测试：
请先写单元测试，再实现功能。
测试文件放在 auth_test.go，覆盖以下场景：
- 正常登录
- 密码错误
- 账号被锁定
- Token 过期
- 并发登录
Claude 会先生成测试桩，然后写实现让测试通过。这样产出的代码质量明显更高，而且测试覆盖率自动就上来了。
有一次我让 Claude 实现一个限流中间件，它先写了测试，测试里包含了一个我没想到的场景——当 Redis 连接超时时的降级策略。这个测试帮我堵住了一个生产环境的潜在 bug。
实战技巧四：用 git 做安全网
Claude Code 可以直接执行 git 命令，我把它当作“安全网”来用：
请先 git stash 当前未提交的改动。
然后创建一个新分支 feature/rate-limit。
实现完成后 git commit，并 push 到远程。
这样即使 Claude 写错了，切回主分支就恢复原样。而且每次 prompt 开始前，我习惯先让 Claude 确认当前 git 状态：
请检查 git status，确认没有未提交的改动。
如果有，先 stash。
然后开始下面的任务。
踩坑记录：别让 Claude 改它不该改的
有一次我让 Claude 优化数据库查询性能，它发现 ORM 生成的 SQL 效率低，直接改了模型层的字段类型。这导致数据迁移脚本全部失效。
教训：给 Claude 划定边界。
请优化 user_repository.go 中的查询方法。
注意：不允许修改：
- 数据库表结构
- 模型定义
- 其他 repository 文件
你只能修改 user_repository.go 中的查询逻辑。
边界声明让 Claude 的改动范围可控，避免“好心办坏事”。
效果数据
经过三个月实践，我整理了一些数据：
| 指标 | 传统 Prompt | Agent 原生交互 |
|---|---|---|
| 一次通过率 | 35% | 72% |
| 平均对话轮数 | 8.2 | 3.5 |
| 代码质量评分 | 6.5/10 | 8.3/10 |
| 调试时间 | 45 分钟 | 18 分钟 |
数据来自同一个项目的三个模块重构，样本量不大但趋势很明显。
真正值得投入的方向
与其花时间琢磨"怎么写 prompt 才能让 AI 听懂"，不如把精力放在"怎么让 AI 理解我的项目和意图"。Claude Code 的优势不在于它有多强的推理能力，而在于它能直接操作你的代码库。当你把它当作一个能读写文件、执行命令的工程师，而不是一个问答机器人时，产出效率才会真正提升。
不是 Prompt 工程不重要，而是 Agent 时代的 Prompt 工程不再是"写指令"，而是"搭上下文"。上下文越完整，AI 的理解越准确，产出的代码越接近你的预期。这比任何花哨的 prompt 模板都管用。
我踩过的坑是花太多时间研究 prompt 格式和措辞，其实效果远不如把项目的目录结构、接口定义、测试用例一起喂给 Claude。回头看，Agent 编程的本质不是提示词的技巧比拼，而是工程师对系统的理解深度——你能把多精确的上下文构建出来，Claude 就能回报多高质量的输出。这才是值得投入的方向。
