AI 编程实战技巧

工具选好了，MCP 会用了，但实际写代码的时候还是会踩坑。这一章讲的是我踩过的坑和总结出来的实战技巧。这些技巧不是理论，是从无数次与 AI 协作的经历中提炼出来的。

永远用最好的模型

这一条我放在最前面，因为太多人在这里踩坑。

强 AI 一轮对话解决问题，弱 AI 十轮对话还在卡壳。这不是夸张，是真实体验。模型能力差距是指数级的。Claude Sonnet 和 GPT-4o-mini 的差距，不是"更好一点"的关系，而是"能做到"和"做不到"的区别。

有人为了省 token 费用，把复杂任务交给便宜的模型。结果 AI 来回犯错，浪费大量时间调试。你省下的那点钱，远不如你浪费的时间值钱。

我的做法是：关键任务用最强的模型，简单任务用便宜的模型。什么是关键任务？架构设计、复杂 bug 修复、跨文件重构、理解代码库——这些都用顶级模型。格式化代码、写简单的 CRUD、生成测试用例——这些可以用普通模型。

2025 年的顶级模型是 Claude Opus 4.5、GPT-5.2、Gemini 3 pro，如果你的编辑器支持选择模型，遇到重要任务就切到最强的。

把 AI 当成初级工程师

Reddit 上有一个很有共识的说法：把 AI 当成一个能力很强但需要指导的初级工程师。它懂很多技术，写代码速度很快，但它不理解业务背景，不知道项目的架构决策是怎么来的，有时候会自作聪明选择一个不合适的方案。

这个心态很重要。你不会让一个初级工程师完全自己做主，你会给他明确的指导，review 他写的代码，纠正他的方向。对 AI 也是一样。

具体怎么做？每次让 AI 写代码之前，先告诉它项目的背景和约束。写完之后认真看 diff，不要无脑接受。发现 AI 做了不合理的设计决策，及时纠正。

有人说"我让 AI 写的代码我都看不懂"。这是一个危险信号。如果你看不懂，要么让 AI 解释清楚，要么自己去学。你是代码的最终责任人，不能把自己不理解的代码放进项目里。

先规划后动手

这是我总结出来最有价值的技巧之一：不要一上来就让 AI 写代码，先让它帮你规划。

一个典型的工作流是这样的：你有一个需求，先用自然语言描述给 AI 听，让它帮你梳理成一个清晰的计划。这个计划应该包括要做什么、分几个步骤、每个步骤的产出是什么。你看这个计划合不合理，提出修改意见，来回讨论几轮，直到你们都认为计划可行。

然后让 AI 批评自己的计划。这不是开玩笑，真的有用。问它"这个计划有什么潜在的问题？有没有边界情况没考虑到？"AI 经常能自己发现之前遗漏的点。

规划完成后，再一步一步执行。每执行完一步，验证一下结果，确认没问题再继续下一步。这种方式比一口气让 AI 写一大堆代码要可靠得多。

实际操作中，我会让 AI 把规划写成一个 .md 文件保存下来。这样即使对话断了，上下文也不会丢失。对于复杂任务，甚至会维护一个 todoList.md，让 AI 每完成一个子任务就在上面打个勾。

遇事不决先建文件夹

一个文件夹就是一个项目。这个习惯看起来简单，但对 AI 协作非常重要。

AI 工作在你打开的文件夹范围内。它默认只能"看到"这个文件夹里的文件。如果你的项目文件散落在各处，AI 的理解就会不完整。如果你把多个不相关的项目混在一个文件夹里，AI 又容易混淆。

养成习惯：新想法等于新文件夹。哪怕最后废弃了，也比在一个混乱的目录里找文件强。每个文件夹里的结构也要清晰。代码放 src，文档放 docs，图片放 images。命名要有意义，不要叫 test1、test2。

这样做的好处是，你让 AI 工作在一个干净的、有边界的环境里。它不会误读不相关的文件，也不会因为上下文太多而混乱。

用 Markdown 做一切文档

.md 是 AI 最友好的文件格式。让 AI 输出任何文档时，明确要求 Markdown 格式。

为什么？因为 Markdown 是纯文本，AI 可以精确地阅读和生成。Word 文档和 PDF 有复杂的格式和元数据，AI 读起来会丢失信息。更重要的是，Markdown 文件可以直接放在代码仓库里，用 Git 管理版本。

需求文档、技术设计、API 文档、会议记录——全都用 .md。AI 读得懂，你也看得清，还能版本控制。

在和 AI 协作的时候，把重要的上下文整理成 .md 文件放在项目里。比如 README.md 描述项目是干什么的，ARCHITECTURE.md 解释技术架构，DECISIONS.md 记录重要的设计决策。这些文件不只是给人看的，也是给 AI 看的。

写好你的 Rules

Cursor、Windsurf、Claude Code 这些工具都支持自定义 Rules。这是告诉 AI "在这个项目里你要遵守这些规则"的方式。

我常用的全局 Rules：

用中文回复
根据第一性原理解决问题
不要过度设计，保证代码简洁易懂
写代码时，检查是否已有相关功能实现，是否有相关模块代码可以复用
改动时最小化修改，尽量不修改到其他模块代码
...

对于特定项目，还可以加项目规则。比如一个 Next.js 项目：

使用 TypeScript，避免 any 类型
组件使用函数式写法和 Hooks
样式使用 Tailwind CSS
API 调用使用 SWR 做数据获取

2025 年的 Cursor 推荐把规则放在 .cursor/rules/ 目录下，用单独的文件管理不同领域的规则。比如 backend.mdc 管后端规则，frontend.mdc 管前端规则。这样更清晰，也更容易维护。

规则写得好，AI 生成的代码就越符合你的预期。规则写得不好，你就要花更多时间改 AI 的代码。这是一个值得投入时间的地方。参考别人写的规则可以去 cursor.directory 看看。

AGENTS.md：AI 的项目说明书

2025 年越来越多的 AI 工具认识了一个叫 AGENTS.md 的文件。它就像一个专门给 AI 看的 README，放在项目根目录。

不同的工具可能用不同的文件名。Claude Code 认的是 CLAUDE.md，GitHub Copilot 认的是 .github/copilot-instructions.md。但核心理念是一样的：给 AI 一个快速了解项目的入口。

一个好的 AGENTS.md 应该包含这些内容：

项目是做什么的，用了什么技术栈。这让 AI 快速了解背景。

常用的命令。比如怎么安装依赖，怎么跑测试，怎么构建。AI 经常需要执行这些命令，告诉它具体怎么做。

代码风格和约定。比如命名规范、目录结构、常用的模式。

安全注意事项。比如不要暴露 API Key，不要删除某些核心文件。

对于大型项目，可以在子目录里放更具体的 AGENTS.md。比如 packages/api/AGENTS.md 专门描述 API 包的规则。AI 会根据你当前工作的位置自动读取相关的说明。

这个文件很重要。写得好，AI 犯错的概率大大降低。写得不好，你就要不断重复告诉 AI 那些本来可以一次写清楚的事情。

Git 是基础设施

搭配 AI 编程，电脑里必须安装 Git。这不是可选项，是必选项。

为什么？因为 AI 会犯错。它可能改错代码，可能删掉不该删的东西，可能把好好的功能改坏。有了 Git，你可以随时回滚。没有 Git，你只能哭。

我的习惯是在提示词里告诉 AI "每次改完都要 git commit"。这样每做一步就有一个存档点，出问题了可以回退到任意一步去。

常用的几个 Git 命令：

git add . 和 git commit -m "描述" 是保存当前状态。git push 是推到远程备份。git log -n 5 是看最近几次提交。git checkout -- . 是撤销所有未提交的修改，回到上一次 commit 的状态。

如果你还没有创建 GitHub 账号，现在就去创建。每个项目都创建一个 Repository，主要用来备份。AI 编程时代，代码迭代速度很快，没有远程备份太危险了。

有一个进阶技巧：做大改动之前创建新分支。比如 git checkout -b feature/new-payment。在新分支上让 AI 折腾，改坏了也不影响主分支。改好了再合并回去。

任务颗粒度把控

这是一门经验学问。任务太大 AI 完成不了，任务太小你监工也辛苦。要找到一个不大不小的平衡点。

什么是太大的任务？"帮我写一个完整的电商网站" 就太大了。AI 可能会写出一堆代码，但方向可能完全不对，你花更多时间改还不如自己写。

什么是太小的任务？"帮我给这个变量改个名" 就太小了。这种事你自己做可能更快。

合适的任务粒度是什么样的？"帮我实现购物车的添加商品功能，要支持商品数量修改和删除"。这个任务足够具体，有明确的边界，AI 可以在一次对话里完成，你也能快速验证结果。

还有一个小技巧：让 AI 在小目录下工作。如果你的项目很大，整个 @codebase 会消耗大量 token，AI 也容易混乱。用 @folder 指定一个子目录，让 AI 只关注那个部分。

上下文管理是关键

AI 不是全知全能的。它只能根据你提供的上下文来回答问题。上下文管理好了，AI 表现就好。上下文管理不好，AI 就会胡说八道。

在 Cursor 和类似工具里，用 @ 符号来提供上下文。@file 引用单个文件，@folder 引用整个目录，@codebase 搜索整个代码库，@url 引用网页内容。

关键原则是：提供必要的上下文，但不要提供过多的上下文。

为什么不能太多？因为 AI 的注意力是有限的。你给它太多无关的信息，它反而找不到重点。而且更多的上下文意味着更多的 token 消耗，成本也更高。

实际操作中，我会这样做：如果问一个关于特定文件的问题，就只 @那个文件。如果需要理解整体架构，再 @几个关键文件。只有在真的需要搜索整个代码库的时候才用 @codebase。

还有，对话变长之后，前面的上下文会慢慢被"遗忘"。如果你发现 AI 开始答非所问，往往是因为对话太长了。这时候开一个新对话，重新提供关键上下文，比继续在旧对话里折腾更有效。

AI 表现不好怎么办

AI 表现不好的时候，不要急着骂它。大概率是这几个原因：

需求理解不充分。你以为你说清楚了，其实没有。试着把需求更具体地描述一遍，加上例子，看看 AI 的理解是不是变准确了。

上下文管理有问题。要么是缺少了必要的上下文，要么是上下文太多太乱。检查一下你提供了哪些文件，是不是都是相关的。

缺乏具体方法指导。AI 可能看到了三种可能的实现方式，然后自作主张选了一个。但那个可能不是你想要的。如果你知道应该怎么做，直接告诉它。

模型能力不够。有些任务确实是某些模型做不了的。换一个更强的模型试试。

还有一个可能：你的项目本身太复杂或者代码太乱了。AI 也是"以貌取人"的，如果它看到的代码风格不一致、命名混乱、结构不清晰，它生成的代码也会继承这些问题。

安全防护

这个话题必须严肃对待。

灾难案例：有人让 AI 帮忙清理临时文件，结果 AI 把整个项目目录删了。更夸张的案例，AI 不小心删掉了用户的整个 C 盘。这些都是真实发生过的事情。

API Key 泄露：AI 可能把 API Key 直接写在前端代码里，或者提交到公开的 GitHub 仓库。一旦泄露，别人就可以用你的 Key 花你的钱。

我的原则是：对于删除操作，永远要人工确认。敏感信息永远不要让 AI 直接处理。

具体做法：在项目的 .gitignore 里加上 .env，确保环境变量不会被提交。在 Rules 里明确告诉 AI "不要直接删除文件，删除前要问我"。定期检查 AI 生成的代码有没有暴露敏感信息。

还有，用 AI 控制浏览器或者文件系统的时候要特别小心。Playwright MCP 可以点击任何按钮，包括付款按钮。File System MCP 可以删除任何文件，包括系统文件。给 AI 的权限要谨慎考虑。

个人项目 vs 团队项目

这两种场景的做法完全不同。

个人项目，你是唯一的开发者，AI 全自动模式问题不大。让 AI 自己 commit，自己 push，自己做 lint，都可以。出了问题你自己兜着。

团队项目就不一样了。你的代码要合并到主分支，要给其他人 review，要保证不影响别人的工作。这时候自动 push 是危险的，因为你可能把有问题的代码推到共享仓库。

团队项目的做法是：让 AI 在本地干活，但 commit 和 push 自己手动做。在提交之前，跑完整的测试，确保没有破坏现有功能。写清楚 commit message，说明这次改了什么。如果是大改动，开一个 PR 让其他人 review。

还有一点：团队项目里一定要有好的 AGENTS.md 和 Rules。这样不同成员用 AI 生成的代码风格才会一致，不会你用驼峰我用下划线。

心法：反求诸己

最后讲一个心法。

孟子有个射箭的比喻：射不中不要怨比你强的对手，要反过来在自己身上找原因。这个道理用在 AI 协作上特别合适。

AI 表现不好的时候，是先抱怨 AI 太蠢，还是先检查自己的提示词有没有问题？

经验告诉我，大部分时候问题出在我这边。要么是需求没说清楚，要么是上下文给错了，要么是任务粒度不对。与其抱怨 AI，不如优化自己的提示方式。

这不是说 AI 永远没问题。AI 确实有能力边界，有知识截止日期，有各种局限。但在那个边界以内，如果它表现不好，你作为"指挥官"是有很大责任的。

反求诸己的三个层次：先检查提示词——表达是否清晰、需求是否具体、格式是否明确。再检查思路——逻辑是否合理、方向是否正确、目标是否现实。最后检查心态——是否过于急躁、是否缺乏耐心、是否愿意学习。

与 AI 协作是一种新的技能。就像学任何技能一样，需要时间和练习。保持耐心，不断反思，你会越来越熟练。

下一章进入心法篇，聊聊如何用规范驱动开发，让 AI 编程更可控。