90% 的人还在把 Agent 当 ChatGPT 用，难怪又慢又贵还老翻车。

---

前几天，同事跑来问我：

“为什么你用 Agent 半小时就搞完的需求，我折腾了一整天还没跑通？”

说实话，这个问题我半年前也问过别人。

刚开始用 AI Agent 的时候，我和大多数人一样——打开对话框，丢一段 prompt，然后等着看结果。运气好就一次性搞定，运气不好就反复修改，最后发现还不如自己写。

但问题不在 Agent，而在你不会用。

经过 3 个月的高强度使用，从 Claude Code、Codex 到 Cursor、OpenClaw，我踩了无数坑，也总结出了一套真正有效的 Agent 使用方法论。今天就把这些技巧全部分享出来。

---

先看一组真实数据

在分享技巧之前，先看一组我自己统计的数据：

使用方式	平均完成时间	Token 消耗	一次成功率	你的心情
❌ 随手写 prompt	45-90 分钟	💰💰💰💰💰	~30%	😤
⚠️ 简单结构化 prompt	20-40 分钟	💰💰💰	~55%	😐
✅ 本文方法论	5-15 分钟	💰	~85%	😎

差距就是这么离谱。

---

技巧一：永远不要从零开始——给 Agent 喂上下文

这是 最多人犯的第一个错误。

大多数人打开 Agent 就直接问：

帮我写一个用户登录模块

Agent 会怎么写？它会按照自己的理解随便写一个，大概率不符合你的项目规范、代码风格和技术栈。

正确的做法：先喂上下文。

请先阅读以下文件，了解项目的技术栈和代码规范：
- package.json（技术栈）
- src/middleware/auth.ts（现有认证逻辑）
- AGENTS.md（编码规范）

然后按照相同风格，实现一个支持 JWT + Refresh Token 的用户登录模块。

📊 实际效果对比

方式	生成的代码能用吗	需要修改几轮
零上下文	❌ 基本要重写	5-8 轮
喂了上下文	✅ 稍微微调即可	1-2 轮

记住一个原则：Agent 的输出质量 = f(上下文质量)。 你给的上下文越精准，输出就越好。

💡 Pro Tip： 在项目根目录放一个 AGENTS.md 或 CONVENTIONS.md 文件，把编码规范、命名约定、禁止事项都写进去。大多数 Agent 工具（Claude Code、Codex、Cursor）都会自动读取。

---

技巧二：别一次性提需求——学会拆解任务

第二个最常见的错误：把所有需求一股脑丢给 Agent。

帮我做一个完整的电商系统，包括用户注册登录、商品管理、购物车、
订单系统、支付接口、后台管理面板，要求用 Next.js + Prisma + PostgreSQL，
要支持国际化，要有 SEO 优化，要部署到 Vercel……

你猜 Agent 会怎样？它会给你一个看似完整但处处是坑的东西，每个模块都是半成品。

问题根源：Agent 的注意力是有限的。

上下文越长，Agent 就越容易：

• 🔴 遗漏细节
• 🔴 前后矛盾
• 🔴 丢失之前的约定
• 🔴 生成低质量代码

✅ 正确做法：把大任务拆成 3-5 个明确的子任务

我们分步来完成这个功能：

第一步：先设计数据库 Schema（用户表 + 订单表）
第二步：实现用户注册和登录 API
第三步：实现订单 CRUD
第四步：添加单元测试
第五步：写 API 文档

请先完成第一步，我确认后再继续。

🎯 为什么有效？

1. 每一步的上下文都很短，Agent 注意力集中
2. 你可以逐步验证，发现问题及时纠正
3. 避免"滚雪球式"的错误积累
4. Agent 每次只处理一个小问题，质量显著提升

📊 我的实际数据

策略	最终代码质量	总耗时	Bug 数量
一次性全部需求	60 分	3 小时	15+
拆分成 5 个子任务	90 分	1.5 小时	2-3

总耗时反而更短，因为不需要反复返工。

---

技巧三：善用"角色设定"——让 Agent 进入专家模式

很多人觉得给 Agent 设定角色是"玄学"，但我实测下来，效果差异非常明显。

❌ 普通 prompt：

帮我优化这个 SQL 查询

✅ 角色设定 prompt：

你是一位有 10 年经验的数据库工程师，精通 PostgreSQL 查询优化和索引设计。
请从性能角度分析以下 SQL 查询，给出优化建议：
1. 指出性能瓶颈
2. 给出优化后的 SQL
3. 建议需要添加的索引
4. 预估优化后的性能提升

📊 对比测试结果（基于同一个慢查询）

方式	建议数量	可用建议	性能提升
无角色设定	3 条	1 条	~20%
设定 DBA 角色	7 条	6 条	~85%

为什么？角色设定本质上是在激活模型中特定领域的知识。当你说"你是数据库专家"，模型会倾向于调用更多数据库相关的训练知识。

💡 几个经过验证的角色模板：

# 代码审查
你是一位资深代码审查员，请从安全性、性能、可维护性三个维度审查以下代码。

# 架构设计
你是一位系统架构师，擅长分布式系统设计。请在给出方案时考虑 CAP 定理和实际运维成本。

# Bug 排查
你是一位有丰富经验的调试专家。请像排查犯罪现场一样，逐步分析问题的根因。

# 技术文档
你是一位技术文档工程师，擅长用简洁的语言解释复杂概念。请同时给出代码示例。

---

技巧四：学会"约束式 Prompt"——告诉 Agent 什么不能做

大多数人只会告诉 Agent 要做什么，却从来不告诉它 不能做什么。

这就像招了一个新员工，你只告诉他"做一个登录页面"，但不告诉他：

• 不能用某个 UI 框架
• 不能改现有的数据库结构
• 不能用某种认证方式

结果当然是一团糟。

✅ 约束式 Prompt 模板：

请实现用户注册功能。

要求：
- 使用 Express.js + TypeScript
- 密码用 bcrypt 加密，salt rounds = 12
- 返回 JWT token

禁止：
- ❌ 不要修改现有的 User model
- ❌ 不要添加新的 npm 依赖（已有的除外）
- ❌ 不要使用 any 类型
- ❌ 不要在 controller 里直接写 SQL

🎯 效果对比

不加约束 → Agent 自由发挥，经常引入你不想要的东西
          - 加了奇怪的依赖
          - 改了不该改的文件
          - 用了不一致的代码风格

加了约束 → Agent 在"围栏"内工作
          - 代码风格一致 ✅
          - 没有多余依赖 ✅
          - 不需要手动清理 ✅

⚠️ 关键原则：约束越具体，输出越可控。 模糊的约束等于没有约束。

---

技巧五：善用"验证-迭代"循环——别指望一次完美

这个技巧听起来简单，但 90% 的人做错了。

错误的做法是：拿到 Agent 的输出后，不满意就直接重新提问，把之前的上下文全部丢掉。

✅ 正确的做法是在同一个对话中迭代

第 1 轮：给出初始需求
第 2 轮：指出具体问题，要求修正
第 3 轮：补充边界条件
第 4 轮：要求添加测试
第 5 轮：微调细节

为什么要在同一个对话中迭代？

因为 Agent 有"记忆"。它能理解你之前说了什么、改了什么、为什么改。每次迭代都是在修正，而不是从头开始。

📊 两种策略对比

策略	轮次	最终质量	Token 消耗
❌ 不满意就重开	每次从头开始	原地踏步	💰💰💰💰💰
✅ 同对话迭代	逐轮优化	稳步提升	💰💰

💡 迭代话术模板：

# 修正方向
这个方案基本可行，但有两个问题需要修正：
1. xxx 不符合我们的规范，请改为 yyy
2. 缺少对 zzz 的错误处理

# 增加测试
请为上面的代码补充单元测试，覆盖以下场景：
- 正常输入
- 空输入
- 超长输入
- 并发请求

# 代码审查
请审查上面生成的代码，检查：
- 安全漏洞（SQL 注入、XSS 等）
- 性能问题
- 错误处理是否完整

---

技巧六：用好文件系统——让 Agent 自己读代码

这是很多人忽略的一个 杀手级功能：让 Agent 直接读取你的项目文件。

大多数 Agent 工具（Claude Code、Codex、Cursor）都支持文件系统访问。这意味着你不需要手动复制粘贴代码，Agent 可以自己去看。

❌ 低效做法：

我的代码是这样的：
[粘贴 200 行代码]
请帮我找出 bug

✅ 高效做法：

请阅读以下文件，找出导致用户重复注册的 bug：
- src/controllers/userController.ts
- src/services/userService.ts
- src/models/User.ts
- src/routes/user.ts

🎯 为什么这样更好？

1. Agent 能看到完整上下文——不只是你粘贴的部分
2. Agent 能发现你注意不到的问题——比如跨文件的依赖问题
3. 节省你的时间——不用手动选择和复制代码
4. 减少信息损失——复制粘贴经常会丢失缩进和格式

💡 进阶用法：让 Agent 先调研再动手

在开始编码之前，请先：
1. 阅读 src/ 目录下的所有 service 文件，了解现有的业务逻辑
2. 查看 package.json，了解可用的依赖
3. 阅读 .eslintrc.js，了解代码规范
4. 查看最近的 3 个 git commit，了解团队的工作方向

然后基于这些信息，开始实现 xxx 功能。

这相当于让 Agent 先"入职培训"，然后再干活。 效果天差地别。

---

技巧七：建立你的 Prompt 工具箱

最后一个技巧，也是最容易被忽视的：把好用的 prompt 模板存下来，反复使用。

我见过很多高效的 Agent 用户，他们都有一个自己的 prompt 模板库：

prompts/
├── code-review.md        # 代码审查模板
├── bug-investigation.md  # Bug 排查模板
├── feature-impl.md       # 功能实现模板
├── refactor.md           # 重构模板
├── test-generation.md    # 测试生成模板
└── doc-writing.md        # 文档编写模板

📋 分享几个我自己最常用的模板：

1. 新功能实现

请实现 [功能名称]。

背景：
- 项目技术栈：[xxx]
- 相关模块：[列出相关文件]
- 参考实现：[类似功能的文件路径]

要求：
- [具体要求 1]
- [具体要求 2]

禁止：
- [禁止事项 1]
- [禁止事项 2]

请先阅读相关文件了解上下文，然后开始实现。

2. Bug 排查

请排查以下 Bug：

现象：[描述具体表现]
预期行为：[描述应该怎样]
复现步骤：[1, 2, 3...]
相关文件：[列出可疑文件]

请按以下步骤排查：
1. 阅读相关代码
2. 分析可能的根因（列出所有可能性）
3. 确定最可能的原因
4. 给出修复方案
5. 实现修复并添加回归测试

3. 代码重构

请重构 [文件/模块名称]。

目标：
- 提高可读性
- 减少重复代码
- 改善错误处理

约束：
- 不改变外部接口（函数签名保持不变）
- 保持现有测试通过
- 不添加新功能

请先分析当前代码的问题，然后给出重构方案和实现。

---

全面对比：新手 vs 老手

维度	新手用法	老手用法
上下文	什么都不给，直接提问	先喂项目文件、规范和约束
任务粒度	一次性提所有需求	拆分成 3-5 个子任务
角色设定	不用	针对场景设定专家角色
约束条件	只说要什么	同时说什么不要
迭代方式	不满意就重开	在同一对话中逐步优化
文件使用	手动复制粘贴	让 Agent 自己读文件
Prompt 管理	每次从头写	复用模板，持续优化
效率	低	高 5-10 倍
成本	高	低 60-80%
成功率	~30%	~85%

---

常见问题

Q：这些技巧适用于所有 Agent 工具吗？

A：是的。无论你用 Claude Code、Codex、Cursor、Windsurf 还是 OpenClaw，这些原则都通用。核心思路是一致的：给 Agent 更好的上下文，更明确的约束，更小的任务粒度。

Q：prompt 写太长会不会浪费 token？

A：不会。一个精准的 500 token prompt 比一个模糊的 50 token prompt 效率高得多。因为前者能一次生成正确结果，后者需要反复修改，总消耗反而更多。

Q：Agent 生成的代码能直接用吗？

A：用了本文的技巧后，大部分代码可以直接或稍微微调后使用。但无论如何，你永远应该 review Agent 生成的代码。Agent 是你的助手，不是替代品。

Q：怎么判断我的 prompt 写得好不好？

A：一个简单的测试：把你的 prompt 给一个不了解项目的人类同事看。如果他也能理解你要什么，那就是好 prompt。如果他需要反复追问，说明你的 prompt 还需要更具体。

Q：用 Agent 写代码会不会让自己的技术退步？

A：恰恰相反。如果你用对了方法（让 Agent 解释决策、审查它的代码、理解它的实现），你会学到更多。关键在于不要无脑接受输出，而是理解每一行代码。

---

总结

AI Agent 使用技巧的核心可以概括为 7 个要点：

✅ 喂上下文 — 永远不要从零开始，给 Agent 足够的项目信息
✅ 拆解任务 — 大任务拆成小任务，逐步完成逐步验证
✅ 角色设定 — 让 Agent 进入专家模式，激活领域知识
✅ 约束式 Prompt — 同时告诉 Agent 要做什么和不能做什么
✅ 验证-迭代 — 在同一对话中逐步优化，不要推倒重来
✅ 文件系统 — 让 Agent 自己读代码，比你复制粘贴强 10 倍
✅ 模板复用 — 建立你的 prompt 工具箱，持续迭代优化

Agent 不是魔法，它是一把工具。 会用的人效率翻 10 倍，不会用的人只会觉得"AI 不行"。

试试这些技巧，你会发现 Agent 比你想象的强大得多 ⚡

---

💡 如果你觉得这篇文章有用，欢迎点赞、收藏、转发。有问题可以在评论区讨论，我会逐一回复。