解决什么问题
Agent 模式确实快，但很多团队的体感是”改得快、错得也快”：让它加个接口，它顺手重构了半个模块；让它修个 bug，它改错了文件；让它写个组件，它自己发明了一套项目里根本不存在的规范。一轮轮返工下来，效率反而不如自己写。
这些返工绝大多数不是模型能力问题，而是三个缺口：上下文没给够（它只能猜）、目标没定清（它自由发挥）、验收没约定（错了也没人拦）。本文给一套可落地的补法：用 User Rules 定纪律，用项目规则定规范，用四段式提示词定单次任务，再把验收命令交给它自己跑。
一个背景事实：主流模型的上下文窗口已到 10 万 token 量级，但注意力不是无限的——塞得越满、会话越长，早期约束越容易被稀释。所以下面所有做法的共同思路是：把”必须永远成立的事”固化到规则文件里，把”这一次要做的事”在对话里说精确。
环境与版本
- 系统：Windows 11，其他系统步骤一致，仅路径写法不同
- Cursor：版本【待补：Help → About 查看并填写】。至少从 Cursor 1.0 起，新建对话的默认面板就是 Agent，本文不依赖具体小版本
- 规则体系：项目规则目录 .cursor/rules/（旧的根目录 .cursorrules 单文件写法仍兼容，但已不推荐）；全局规则在 Settings 的 Rules 里配置
- 示例项目：pnpm monorepo，前端 React、后端 NestJS、数据库层用 Drizzle
分步骤：从单条提示词到规则体系
第一步：把通用纪律写进 User Rules
全局生效的纪律放在 Settings 的 Rules 里（纯文本，对所有项目生效）：
- 始终用中文回复，代码注释用中文
- 动手前先给一个不超过 5 行的改动计划，我确认后再写代码
- 只修改任务直接相关的文件，禁止顺手重构无关代码
- 需要新增第三方依赖时，先停下来问我
- 每次改完运行 pnpm lint 和相关测试，把结果贴在最后这五条解决的是”每次都要重复说”的问题：范围控制、计划先行、依赖审批、自我验收。写成纪律之后，每条提示词里就不用再带。
第二步：项目规则按目录生效
团队规范放进 .cursor/rules/ 目录，每个文件是一段 Markdown 加 frontmatter，用 globs 控制作用范围。按目录拆分规则文件，比一个巨型文件有效得多——模型只会加载与本次改动相关的规则：
---
description: 后端 API 开发规范
globs:
- "apps/server/**/*.ts"
alwaysApply: false
---
- 路由层只做参数校验和编排，业务逻辑放 service 层
- 错误统一抛 ApiError，由全局过滤器转换成响应体
- 涉及数据库的改动必须走 packages/db 的迁移脚本，禁止裸 SQL
- 新增接口必须补对应的 e2e 测试文件frontmatter 三个字段的分工：description 是这段规则的用途说明；globs 决定哪些文件被改动时规则才生效；alwaysApply 设为 true 则注入每一次对话——适合放仓库导览这类全局知识，不适合放领域规范。
第三步：单条提示词用四段结构
上下文、目标、约束、验收，四段给全。先看反例：
反例：
"帮我加个导出功能"
——没有范围（改哪些文件）、没有约束（用什么库、什么转义规则）、
没有验收（怎么算完成）。Agent 只能猜，猜错的部分就是返工。再看同一条需求的正例：
上下文：@apps/server/src/routes/report.ts @packages/db/src/schema.ts
目标：新增 GET /reports/:id/export，输出 CSV，复用 reportService 的查询逻辑
约束：不新增依赖；CSV 转义遵循 RFC 4180；不改现有接口行为
验收：pnpm --filter server test report，必须全部通过要点名文件就 @ 点名，别让 Agent 全库检索去猜。你多花十秒找文件，它少走十分钟弯路。
第四步：先对齐方案，再放手执行
大改动别直接让 Agent 动手。先用提问模式（Plan/Ask，入口名称随版本略有差异【待补：填当前版本的入口名】）对齐：让它列出要改的文件清单和每处的改动思路，你确认或纠偏之后，再切到 Agent 模式执行。大批量改动分批推进，每批对应一个可独立验收的里程碑——错了也只错一批。
第五步：给 Agent 一份代码地图
新会话对仓库一无所知，每次都靠它自己探索就是在赌运气。在仓库根目录放一份导览，Cursor 会读取 AGENTS.md【待补：核对当前版本的读取规则与优先级后补充】：
# 仓库导览
- apps/server：NestJS 后端，入口 src/main.ts，模块按领域划分在 src/modules/
- apps/web：React 前端，路由集中在 src/routes.tsx
- packages/db：Drizzle schema 与迁移，数据库改动只在这里
- 常用命令：pnpm dev（本地启动）/ pnpm test / pnpm lint
- 改后端代码后必须跑：pnpm --filter server test也可以把它写成 .cursor/rules/ 里 alwaysApply: true 的规则文件，效果等价，好处是能和 frontmatter 体系统一管理。
第六步：把验收交给它自己跑
提示词里写明验收命令，并允许它执行终端命令。它跑完测试贴出结果，你只看结论和 git diff——审查产出物，而不是盯着过程。会话结束前让它自己总结改动清单，review 的起始成本又低一截。
常见坑
坑一：规则文件写了不生效。三种常见原因：文件后缀不是 .mdc；frontmatter 字段名拼错（是 alwaysApply，不是 always_apply）；globs 路径写错导致永远匹配不上。验证办法：新开一个对话，直接问它”列出你当前加载的项目规则”，看写的内容在不在列表里【待补：补一张不生效时的排查截图或报错信息】。
坑二：一条提示词塞三个任务。改 A 功能、修 B bug、升级 C 依赖互相干扰，出一个错就全链路返工。拆成串行小任务，每任务一次会话、一个验收命令。
坑三：只有”不许做什么”，没有”照着什么做”。告诉它”不要过度设计”几乎没有用；@ 一个符合团队标准的样板文件让它参照，比十条禁令都有效。
坑四：重要约束只存在于聊天记录里。会话一长，早期约束被稀释；新开会话，约束干脆全丢。纪律要么进 User Rules，要么进项目规则文件，聊天里只放本次任务的上下文。
最终效果
规则体系搭好之后的变化：Agent 的第一轮产出就能对齐团队规范，返工从”方向性重做”降为”细节微调”；新同事 clone 仓库就获得全部纪律，不再需要口口相传。同一类任务试点前后的返工对比【待补：用你的试点数据填充，建议口径为单个任务从提需求到验收通过的对话轮数】。
还有一个副产品：你对 AI 说清楚的东西，人也能看懂。很多团队的 .cursor/rules 目录最后成了事实上的开发规范文档——这大概是设规则时没想到的收益。