是你不行，不是 AI Agent 不行

一两年前，我们还觉得 AI 不行，最多只能实现部分小功能、小模块。到现在，我们项目的代码 80%-90% 已经是 AI 生成的。

这一年我花了大量时间思考：如何用 AI 组织项目、如何写提示词。我感觉自己已经从软件工程师变成了 AI Agent 上下文管理工程师。

所以别再抱怨 “AI Agent 不行”——是你不会用。

角色转变：从写代码到管理上下文

以前的工作是写代码：实现功能、修 Bug、优化性能。现在的工作是教 AI 写代码、Review AI 写的代码：

• 定义项目规范，让 AI 记住技术栈和约束
• 设计工作流，让 AI 知道什么时候该做什么
• 隔离上下文，让 AI 把复杂任务交给专门的 SubAgent 去做
• 给 AI 提供工具，让它自己发现错误、自己修复

具体来说，这个转变体现在：

以前（写代码）	现在（管理上下文）
实现功能、修 Bug、优化性能	定义规范、设计工作流、隔离上下文
写 1000 行代码	写 100 行配置
手动测试 10 次	监督 AI 自测 2 次
3 天完成功能	半天完成功能

这个转变的核心是：让每个人都是架构师，每个人都是 TL

让 AI 记住你的规矩

主流的 AI 编程工具（Cursor、Cline、Continue、Windsurf）都在解决同一个问题：如何让 AI 持续记住项目的约束和规范。它们的解决方案都差不多，提供了几个核心组件：

组件	作用	触发方式	例子
Rules（Agents.md）	全局原则，始终生效	自动加入每次对话	”JWT 15 分钟过期”
Commands	可复用工作流，按需触发	手动 /command 触发	/create-pr 自动生成 PR
SubAgent	任务委派，隔离上下文	AI 自动委派或显式调用	前端/后端分离，并行执行
Skills	特定领域知识，按需加载	AI 根据描述自动调用或手动 / 触发	React 组件规范、部署脚本

下面以 Cursor 为例，看看这些组件怎么配置。强烈建议去翻翻各工具的官方文档，了解它们的定义和使用场景。

Rules：全局约束

每次对话，AI 都是从零开始。它不记得上次你说过”JWT 15 分钟过期”，不知道项目里用的是 bcrypt 而不是 argon2，更不知道你们团队约定错误码统一用 4xx/5xx。

Rules 就是你告诉 AI：“这些规矩，无论写什么代码都不能变。”

一个典型的项目规则长这样：

# 核心技术栈
 
- 前端：React 16 + TypeScript + Vite
- 后端：Python 3.11 + FastAPI + PostgreSQL
 
# 认证规范
 
- JWT 访问令牌 15 分钟过期
- 刷新令牌 7 天过期
- bcrypt 加密密码（12 rounds）
 
# 质量红线
 
- 禁止使用 `any` 类型
- 单个文件不超过 300 行
- 组件函数不超过 50 行

Rules 的陷阱：别写太多。

很多人会把整份风格指南复制进去，把所有可能的命令都列一遍。结果 AI 的上下文窗口被塞满了，反而找不到重点。

Rules 应该只放那些反复出错时才添加的约束。如果 AI 总是把 JWT 过期时间搞错，加一条规则；如果它从来没搞错过，就别提前加。

参考：Cursor Rules 文档

Cursor 的 rule 还有个特别之处：可以根据文件类型应用规则。比如只在编辑 .tsx 文件时应用 React 相关的规则。

Commands：别重复说同样的话

有些操作你会反复做：创建 PR、跑测试、部署代码。每次都要输入一长串提示词太累了。

Commands 就是把这些重复的提示词封装成 /command，一键触发。凡是你重复两三遍输入的提示词，就该考虑封装成 Command：

# .cursor/commands/create-pr.md
 
1. 运行 `npm run typecheck` 和 `npm run test`
2. 用 `git diff main` 查看所有改动
3. 生成 PR 描述（标题、背景、改动、Breaking Changes）
4. 用 `gh pr create` 创建 PR

以后只要输入 /create-pr，AI 就会按这个流程执行。

参考：Cursor Commands 文档

SubAgent：上下文隔离是关键

假设你要加个新功能：前端加一个表单，后端加一个接口。你让 AI 一口气做完，结果它在改后端时顺手把前端的某个组件也改了。将所有信息都塞进一个对话，很多时候效果会很差。

问题出在哪？上下文太大，AI 分不清边界。

SubAgent 的核心思想是：当任务足够大、足够复杂时，隔离上下文，让 Agent 更专注当前任务，不受其他代码干扰。

不仅仅是前后端分离，还可以用于：

• Code Review：专门的 Code Review SubAgent，只关注代码质量、安全性、性能问题
• 性能测试：专门的性能分析 SubAgent，用 PostgreSQL 最佳实践检查 SQL 查询
• 安全审计：专门的安全 SubAgent，检查常见漏洞（注入、XSS、硬编码密钥）

Cursor 内置了三个 SubAgent：Explore（搜索代码库）、Bash（运行命令）、Browser（控制浏览器）。

自定义 SubAgent 例子

PostgreSQL 性能分析 SubAgent：

# .cursor/agents/postgres-perf-analyzer.md
 
---
name: postgres-perf-analyzer
description: 用 PostgreSQL 最佳实践检查当前改动的潜在性能问题。
---
 
你是一个 PostgreSQL 性能专家。当代码涉及数据库查询时，检查：
 
## 索引问题
- [ ] WHERE、JOIN、ORDER BY 的字段是否有索引
- [ ] 是否使用了覆盖索引（Covering Index）
- [ ] 是否有冗余索引
 
## 查询优化
- [ ] 是否使用了 SELECT *（应该只查需要的字段）
- [ ] 是否有 N+1 查询问题
- [ ] 是否使用了 LIMIT 限制结果集
- [ ] 子查询是否可以改成 JOIN
 
## 数据类型
- [ ] 是否使用了正确的数据类型（避免 TEXT 存数字）
- [ ] JSONB 字段是否加了 GIN 索引
 
## 锁和并发
- [ ] 是否有长事务（可能导致锁等待）
- [ ] UPDATE/DELETE 是否加了合适的 WHERE 条件
 
用 EXPLAIN ANALYZE 验证查询计划，给出优化建议。

调用时：

@postgres-perf-analyzer
检查我刚改的订单查询代码，看看有没有性能问题

SubAgent 会分析你的 SQL，发现”订单表的 status 字段没索引，查询会全表扫描”，建议加索引。

参考：Cursor SubAgent 文档

Skills：按需加载规范

假设你的项目有一套 React 组件规范：表单用 Formik + Yup，状态管理用 Context API，错误提示用 toast。你不想每次都在 Rules 里写一遍，因为只有在写 React 组件时才需要这些规则。

Skills 就是按需加载的规范和工具：

# .cursor/skills/react-patterns/SKILL.md
 
---
name: react-patterns
description: React 组件开发规范。创建或修改 React 组件时使用。
---
 
## 表单
 
- 使用 Formik + Yup 验证
- 错误提示用 toast 组件
 
## 状态管理
 
- Server State 用 TanStack Query
- Local State 用 Context API

AI 在创建 React 组件时，会自动加载这个 Skill。你不需要手动触发，也不需要把这些规则写进全局 Rules。

Skills 还可以包含可执行的脚本，让 AI 直接调用部署脚本、测试工具、数据库连接等。

参考：Cursor Skills 文档

让 AI 自己测试

最大的问题不是 AI 会犯错，而是它不知道自己错了。

典型场景：

• AI 说”已经加了登录功能”，你打开浏览器一看，点登录按钮没反应
• AI 说”修复了支付接口”，但实际测试时还是返回 500 错误

如果每次都要你手动测试、发现问题、再告诉 AI 哪里错了，效率会很低。更好的方式是：通过 Skills 和 MCP (Model Context Protocol)，让 AI 自己测试。

Browser Skill：教会 AI 用浏览器测试前端

创建 e2e-frontend-test skill，教 AI 如何启动浏览器、打开页面、点击按钮、填写表单、截图验证、读取控制台日志。

然后在 Command 或 SubAgent 中写：

# .cursor/commands/implement-feature.md
 
1. 实现功能
2. 如果涉及前端改动，用 e2e-frontend-test skill 验证
3. 如果涉及后端改动，用 verify-database skill 验证
4. 所有检查通过后，用 create-pr skill 自动创建PR 到github

Database Skill：教会 AI 连接数据库验证数据

创建 verify-database skill，教 AI 如何连接数据库、查询数据、检查索引、验证约束。

为什么这样做

传统方式：

graph LR
    A(AI 生成代码) --> B(你手动测试)
    B --> C(发现问题)
    C --> D(告诉 AI 哪里错了)
    D --> E(AI 修改)
    E --> A
    
    style A fill:#e1f5ff
    style B fill:#ffe1e1
    style C fill:#ffe1e1
    style D fill:#ffe1e1
    style E fill:#e1f5ff

用 Skills + MCP：

graph LR
    A(AI 生成代码) --> B(AI 自己测试)
    B --> C{测试通过?}
    C -->|否| D(AI 发现问题)
    D --> E(AI 自己修改)
    E --> B
    C -->|是| F(完成)
    
    style A fill:#e1f5ff
    style B fill:#e1ffe1
    style C fill:#fff4e1
    style D fill:#e1ffe1
    style E fill:#e1f5ff
    style F fill:#d4edda

效率差异：10 次人工测试 vs 1 次监督 AI 自测。

更重要的是，AI 会在测试中学习：什么样的错误提示对应什么问题、常见的配置错误有哪些、如何读取日志定位问题。

这就是这个角色的核心工作：不是替 AI 写代码，而是教 AI 怎么写、怎么测、怎么改。

你的工作变了

以前：写 1000 行代码，手动测试微信支付 5 次、支付宝 5 次、信用卡 3 次，改 Bug 8 次，花 3 天。

现在：写 100 行配置（Rules、Skills），监督 AI 自测 2 次，只在关键决策时介入（“超时时间改成 10 分钟”），花半天。

这就是角色转变：从写代码的人，变成教 AI 写代码的人。

几个实战建议

1. 先用 Plan Mode 生成设计

别一上来就让 AI 写代码。先用 Plan Mode生成实现计划，看看 AI 的理解对不对。如果方向错了，早点调整。写 50 行配置胜过推倒重写 500 行代码。

2. 用 SubAgent 隔离复杂的任务

任务涉及前后端等复杂场景时，可以用不同的 SubAgent 隔离上下文，并行执行。通常这样效果会更好。

例子：加个”订单导出”功能。前端 SubAgent 只改 src/pages/Orders/ExportButton.tsx，后端 SubAgent 只改 routes/export.py。它们同时开工，前端测 UI、后端测 API，最后一合并就能用。

避免：让一个 Agent 同时改前后端，结果它在写后端时顺手把前端的某个不相关组件也改了。

3. Rules 只放全局约束，Skills 按需加载

别一次性把所有规范塞给 AI。如果 AI 的上下文窗口被塞满了，它反而找不到重点。

例子：

• Rules 里只放：“支付金额用 Decimal”、“密码用 bcrypt”
• Skills 里放具体的：payment-integration skill（微信/支付宝 SDK 调用细节）、react-forms skill（表单验证规范）

AI 在写支付接口时自动加载 payment skill，在写登录页面时自动加载 react-forms skill。按需加载，不提前。

4. 让 AI 自己测试，而不是你测试

配置好 Skills + MCP，让 AI 写完代码自己跑起来、用浏览器测试前端、连接数据库验证数据、读取日志分析错误。

你的工作是监督，而不是手动测试 10 次。

5. Commands 减少重复

如果发现自己总在说同样的话（“跑测试、生成 PR、部署代码”），把它封装成 Command。

例子：每次改完代码都要：“跑 typecheck、跑 lint、跑测试、生成 PR 描述、创建 PR”。输入 5 遍后，你发现每次都一样。封装成 /ship-it 命令，一句话搞定。

一句 /ship-it 胜过每次输入 100 字的提示词。

参考：Agent 最佳实践

根据任务选对模式

除了配置，你还需要根据任务选择合适的模式。大部分 AI 编程工具都提供类似的模式（以 Cursor 为例）：

Ask Mode

特点： 只读模式，不修改代码。AI 会用 grep 和语义搜索找答案，但不会改任何东西。

什么时候用： 改动前先搞懂现有代码，架构模式讨论，头脑风暴。

Agent Mode

特点： 默认模式，自主探索、编辑多个文件、运行命令。

什么时候用： AI 知道要做什么，你已经在代码里写了大量最佳实践、开发模式等 Skills 或 Rules。不想写详细执行计划，有信心 AI 可以一步到位解决问题。

Plan Mode

特点： AI 不会立即修改代码。会先向你询问不清楚的上下文，了解足够信息后生成一个详细的 plan。Plan 以 Markdown 形式打开，可以直接编辑。

什么时候用： 需求不清晰、涉及多个模块、有多种方案，需要和它讨论的时候。

Debug Mode

特点： AI 会自动插入日志埋点、收集运行时数据、分析根因。通常只需修改 2-3 行代码，而不是猜测性地改一堆。

什么时候用： 调试排查问题、修复 Bug 时，可以尝试用这个模式，它会帮你分析根因。

并行运行多个模型

Cursor 支持同时运行多个 Agent（通过 git worktree 隔离），让不同模型尝试同一问题，再选出最优结果。

例子：

你要”重构支付模块，拆成独立微服务”。这是个架构决策，不同模型可能有不同思路：

• Claude 生成方案：用事件驱动架构，消息队列解耦
• GPT-4 生成方案：用 gRPC，共享 Proto 定义
• DeepSeek 生成方案：用 REST API，加 API Gateway

你对比后发现 Claude 的方案最适合（系统已经有 RabbitMQ），点击 Apply，其他两个 worktree 自动清理。

参考：Cursor Modes 文档 / Debug Mode

配置即产品

本质上是角色的重新定义：以前你写代码，代码即产品；现在你配置 AI，AI 生成代码，配置即产品。

Rules、Commands、SubAgent、Skills + MCP，就是这个新角色的核心能力：

• Rules：定义全局约束，让 AI 记住不能变的原则
• Commands：自动化重复工作，减少提示词劳动
• SubAgent：隔离上下文，让 AI 不会搅在一起
• Skills + MCP：教 AI 用工具，让它自己测试、自己发现错误、自己修复

关键是找到平衡点：在控制和效率之间，在规范和灵活之间。

所以别再抱怨”AI Agent 不行”——是你还没学会这套新的工作方式。