1. 为什么AI写代码总爱“自作聪明”1.1 一个让所有开发者血压升高的场景你让AI帮你写一个用户登录接口它给你返回了整整两百行代码。你仔细一看它顺手帮你加了JWT刷新逻辑、加了Redis缓存、加了请求频率限制、加了邮箱验证甚至还贴心地引入了一个你项目里根本没装的第三方库。你只是想让它写个登录它却给你造了一整套用户中心。这不是段子这是每天都在发生的事情。AI写代码时最大的毛病不是写不出来而是写太多、写太偏、写太“聪明”。你让它修一个空指针异常它把整个模块重构了一遍你让它加一个字段它把数据库表结构改了你让它写个工具函数它给你整了个设计模式全家桶。我见过最离谱的一次同事让AI帮忙写一个简单的日期格式化函数AI返回的代码里包含了时区处理、夏令时判断、闰年校验、国际化适配还附带了单元测试和文档注释。代码本身没毛病但问题是——项目里已经有现成的日期工具库了而且团队规范明确要求统一使用那个库。这种“自作聪明”带来的后果很直接代码审查时间翻倍、引入不必要的依赖、破坏项目一致性、增加维护成本。更可怕的是有些AI生成的代码看起来逻辑自洽实际上隐藏着微妙的bug你不仔细看根本发现不了。1.2 问题的根源在哪里AI之所以会“自作聪明”核心原因有三个层面。第一个层面是训练数据的偏差。AI模型在训练时接触了大量的开源项目、技术博客和教程代码。这些内容天然带有“展示性”——作者写教程时总想把功能做完整、把代码写漂亮于是各种设计模式、边界处理、扩展性考虑全都堆上去。AI学到的就是这种“教科书式”的写法它不知道你的真实项目里可能只需要一个能跑的最简实现。第二个层面是缺乏项目上下文。当你打开一个对话窗口粘贴一段需求描述AI看到的只是这段文字。它不知道你的项目用了什么框架、遵循什么规范、有哪些现成的工具类、团队的技术栈偏好是什么。在信息缺失的情况下AI会倾向于“过度补偿”——既然不知道你的约束条件那就把所有可能的情况都考虑进去。第三个层面是提示词本身的模糊性。大多数人给AI下指令时说的是“帮我写一个登录功能”而不是“在我现有的Express项目里使用已有的User模型和bcrypt库写一个POST /api/login路由处理函数只做密码校验和token签发不要引入新依赖”。前者给了AI无限的发挥空间后者才是有效的工程指令。1.3 解决思路的整体框架要彻底治好AI的“自作聪明”不能靠反复抽卡碰运气而是要从三个维度同时下手约束输入、规范输出、持续校准。约束输入指的是在给AI下指令之前先把项目上下文、技术约束、代码规范这些信息准备好让AI在明确的边界内工作。规范输出指的是通过配置文件、提示词模板、代码审查清单等手段让AI生成的代码符合项目要求。持续校准指的是在AI生成代码后通过自动化检查和人工审查及时发现偏差并反馈修正。这三个维度对应到具体操作上就是本文要重点讲的几个核心工具和方法用AGENTS.md文件给AI建立项目认知、用结构化Prompt约束AI的输出范围、用代码规范检查工具做自动化兜底、用多轮对话策略逐步收敛结果。2. AGENTS.md给AI装上一本项目说明书2.1 AGENTS.md到底是什么AGENTS.md是一个放在项目根目录下的Markdown文件它的作用是告诉AI这个项目的基本信息、技术栈、代码规范、目录结构、常用命令等。你可以把它理解成“给AI看的README”——README是给人看的告诉人类开发者怎么上手这个项目AGENTS.md是给AI看的告诉AI在这个项目里写代码要遵守什么规则。这个文件本身没有任何技术门槛就是一个普通的文本文件。但它的存在与否对AI生成代码的质量影响巨大。没有AGENTS.md的时候AI只能根据你的对话内容来猜测项目情况有了AGENTS.md之后AI在每次生成代码前都会先读取这个文件了解项目的约束条件从而避免“自作聪明”。我自己的项目里加上AGENTS.md之后AI生成代码的“跑偏率”大概从百分之六七十降到了百分之十几。剩下的百分之十几通过后续的Prompt约束和代码审查也能兜住。2.2 AGENTS.md应该写什么内容一个实用的AGENTS.md不需要写得多漂亮但必须包含以下几类信息。第一类是项目概述。用两三句话说明这个项目是做什么的、面向什么用户、当前处于什么阶段。比如“这是一个面向中小企业的SaaS库存管理系统目前处于MVP阶段优先保证功能可用暂不考虑大规模并发”。第二类是技术栈声明。列出项目使用的前端框架、后端框架、数据库、缓存、消息队列、部署方式等。关键是要写明版本号因为不同版本的API差异很大。比如“后端使用Express 4.18数据库使用PostgreSQL 15ORM使用Prisma 5.x不要使用Sequelize或TypeORM”。第三类是代码规范。这部分要写得具体不能只说“遵循最佳实践”。要明确缩进用几个空格、字符串用单引号还是双引号、是否使用分号、函数命名用驼峰还是下划线、文件命名用短横线还是下划线。如果项目有ESLint或Prettier配置直接说明“遵循项目根目录下的.eslintrc和.prettierrc配置”。第四类是目录结构说明。告诉AI哪个目录放路由、哪个目录放模型、哪个目录放工具函数、哪个目录放测试。这样AI在生成新文件时就知道该往哪里放不会把路由文件扔到utils目录里。第五类是禁止事项。这是最重要的一部分。明确告诉AI不要做什么比如“不要引入新的npm依赖如需使用新库请先询问”、“不要修改数据库schema所有变更通过migration文件处理”、“不要使用any类型所有TypeScript代码必须有明确的类型标注”、“不要写console.log使用项目统一的logger工具”。第六类是常用命令。列出启动开发服务器、运行测试、执行lint、构建生产包的命令。这样AI在需要验证代码时就知道该跑什么命令。2.3 一个真实的AGENTS.md示例下面是我在一个Node.js后端项目里实际使用的AGENTS.md文件做了脱敏处理你可以直接参考这个结构。# 项目说明 这是一个面向企业内部使用的工单管理系统后端API。 ## 技术栈 - Node.js 20 LTS - Express 4.18 - PostgreSQL 15 Prisma 5.x - Redis 7.x仅用于session存储 - Jest 29测试框架 - ESLint Prettier代码规范 ## 代码规范 - 缩进2个空格 - 字符串单引号 - 分号必须写 - 函数命名驼峰式camelCase - 文件命名短横线式kebab-case - 类型TypeScript严格模式禁止any ## 目录结构 - src/routes/路由定义 - src/controllers/业务逻辑 - src/models/Prisma模型封装 - src/middlewares/Express中间件 - src/utils/工具函数 - src/types/TypeScript类型定义 - tests/测试文件 ## 禁止事项 - 不要引入新的npm依赖如需使用请先说明理由 - 不要直接操作数据库所有查询通过Prisma Client - 不要修改prisma/schema.prisma如需变更请提供migration方案 - 不要使用console.log使用src/utils/logger.ts - 不要写超过50行的函数超过请拆分 ## 常用命令 - 开发npm run dev - 测试npm test - Lintnpm run lint - 构建npm run build这个文件大概一百多行写一次之后后续所有AI对话都会受益。你可以在对话开始时直接把AGENTS.md的内容粘贴给AI或者如果使用的工具支持自动读取项目文件AI会自动加载。2.4 让AGENTS.md真正生效的技巧光写一个AGENTS.md文件还不够关键是要让AI在每次生成代码时都参考它。不同的AI编程工具对这个文件的支持程度不一样。有些工具会自动读取项目根目录下的AGENTS.md有些需要你手动在对话中引用。我的做法是在每次对话的第一条消息里先粘贴AGENTS.md的内容然后加上一句“请先阅读以上项目说明后续所有代码生成都必须遵守这些约束”。这样相当于给AI设定了一个“系统提示”后续的对话都会在这个框架内进行。另外AGENTS.md不是写完就一劳永逸的。项目在演进技术栈在升级规范在调整AGENTS.md也要跟着更新。我一般每个月review一次把最近踩过的坑、新增的约束补充进去。比如有一次AI反复在代码里写console.log我就在禁止事项里加了一条“禁止使用console.log”之后这个问题就再也没出现过。还有一个细节AGENTS.md里的禁止事项要写得具体不能太笼统。说“不要写烂代码”没用AI不知道什么叫烂代码。要说“不要写超过50行的函数”、“不要嵌套超过3层的if语句”、“不要使用for循环用map/filter/reduce替代”。越具体AI越容易遵守。3. Prompt工程把“帮我写代码”变成“按规范写代码”3.1 为什么你的Prompt总是被AI误解大多数人给AI写Prompt的方式就像在餐厅点菜时说“随便来点好吃的”。厨师只能根据自己的理解做一道菜端上来你可能不满意但问题不在厨师在于你没说清楚想吃什么。AI编程也是同样的道理。“帮我写一个用户注册功能”这句话包含了太多的模糊地带。注册需要哪些字段密码要不要加密要不要发验证邮件要不要做频率限制返回什么格式错误怎么处理这些AI都不知道它只能按照自己的理解来补全。而AI的理解往往来自那些“教学性质”的开源代码于是各种边界处理、扩展性设计全来了。有效的Prompt应该像一份需求规格说明书把输入、输出、约束、异常处理都说清楚。你不需要写得很长但关键信息不能少。3.2 结构化Prompt的五个核心要素我总结了一个在AI编程场景下比较通用的Prompt结构包含五个要素角色设定、上下文、任务描述、约束条件、输出格式。角色设定是告诉AI以什么身份来写代码。比如“你是一个有五年经验的Node.js后端开发者熟悉Express和Prisma”。这个设定会影响AI的代码风格和技术选型偏好。上下文是告诉AI当前项目的情况。如果你已经提供了AGENTS.md这部分可以简化只需要补充本次任务相关的特殊背景。比如“当前项目已经有一个User模型包含id、email、passwordHash、createdAt字段”。任务描述是具体要做什么。要写得具体但不要写成伪代码。比如“实现一个POST /api/register接口接收email和password校验邮箱格式和密码强度检查邮箱是否已注册创建用户记录返回用户ID和创建时间”。约束条件是告诉AI不要做什么。这是防止“自作聪明”的关键。比如“不要发送验证邮件”、“不要引入新的依赖”、“不要修改现有的User模型”、“密码哈希使用项目已有的bcrypt工具函数”。输出格式是告诉AI返回什么。比如“只返回路由处理函数的代码不要包含路由注册代码不要包含测试代码不要包含注释”。把这五个要素组合起来一个完整的Prompt大概长这样你是一个有五年经验的Node.js后端开发者。 当前项目使用Express 4.18 Prisma 5.x PostgreSQL 15。 已有的User模型包含字段id, email, passwordHash, createdAt。 已有的工具函数src/utils/hash.ts 提供 hashPassword 和 verifyPassword。 已有的中间件src/middlewares/validate.ts 提供请求体校验。 任务实现POST /api/register接口。 - 接收email和password - 校验邮箱格式使用项目已有的validator工具 - 校验密码强度至少8位包含字母和数字 - 检查邮箱是否已注册 - 创建用户记录 - 返回用户ID和创建时间 约束 - 不要发送验证邮件 - 不要引入新的npm依赖 - 不要修改User模型 - 不要写console.log - 错误处理使用项目统一的AppError类 输出只返回controller函数的代码不要包含路由注册不要包含测试。这个Prompt大概两百字但信息密度很高。AI拿到这样的指令基本不会跑偏。3.3 用“负面清单”锁死AI的发挥空间在Prompt里负面约束往往比正面描述更有效。因为AI的“自作聪明”主要表现为“多做了不该做的事”而不是“少做了该做的事”。你告诉它要做什么它可能会漏但你告诉它不要做什么它一般都会遵守。我习惯在Prompt里加一个“禁止事项”段落把常见的“自作聪明”行为都列出来。比如不要添加额外的错误处理除非我明确要求不要写注释除非逻辑特别复杂不要重构现有代码只做我要求的最小改动不要引入新的依赖不要修改函数签名不要添加日志输出不要写单元测试除非我要求不要使用设计模式用最直白的写法这个清单可以根据项目情况调整。比如有些项目要求必须写测试那就把“不要写单元测试”去掉。有些项目鼓励使用设计模式那就把最后一条去掉。关键是让AI知道在这个项目里“少做”比“多做”好“直白”比“优雅”好“能跑”比“完美”好。3.4 多轮对话的收敛策略即使Prompt写得再好AI第一次生成的代码也可能不完全符合要求。这时候不要直接放弃或者手动改而是通过多轮对话逐步收敛。第一轮让AI生成初版代码。不要期望一次就完美先看整体方向对不对。第二轮指出具体问题。不要说“写得不好”要说“第15行的错误处理不需要请删除”、“第23行引入的lodash依赖项目里没有请用原生方法实现”、“第30行的console.log请删除”。第三轮让AI根据反馈重新生成。这时候AI已经知道了你的偏好生成的代码会明显更贴近要求。第四轮如果还有小问题继续微调。一般三到四轮就能得到可用的代码。这个过程中最重要的是反馈要具体。说“第15行”比说“错误处理部分”更有效说“删除console.log”比说“不要写日志”更有效。AI对具体的行号和操作指令理解得最准确。我自己的经验是第一轮生成后大概需要两到三轮修正才能达到可提交的状态。虽然看起来多花了时间但比起自己从头写或者反复抽卡效率还是高很多。而且随着你对Prompt的打磨第一轮的质量会越来越高修正轮次会越来越少。4. 代码规范检查让机器做最后的守门人4.1 为什么AI生成的代码必须过Lint不管Prompt写得多好AGENTS.md多完善AI偶尔还是会写出不符合规范的代码。这不是AI故意捣乱而是概率问题——大语言模型的输出本质上是概率采样即使约束很明确也有一定概率“采样”到不符合要求的token。所以AI生成的代码在提交之前必须过一遍自动化检查。这不是不信任AI而是工程上的必要防线。就像即使是最资深的开发者代码也要过CI一样。Lint工具在这里扮演的是“守门人”角色。它不关心代码是谁写的只关心代码是否符合规则。AI写的代码和人类写的代码在Lint面前一视同仁。这恰恰是我们需要的——用统一的、客观的标准来约束AI的输出。4.2 ESLint Prettier的配置要点对于JavaScript和TypeScript项目ESLint负责代码质量检查Prettier负责代码格式化。两者配合使用基本能覆盖大部分规范问题。ESLint的配置重点在于规则的选择。默认的recommended规则集太宽松了很多AI常犯的问题它不管。我建议在recommended基础上额外开启以下规则no-console禁止console.logAI特别爱写这个no-unused-vars禁止未使用的变量AI经常定义了一堆变量但没用no-undef禁止使用未定义的变量防止AI引用不存在的全局变量max-lines-per-function限制函数最大行数防止AI写出超长函数max-depth限制嵌套深度防止AI写出多层嵌套complexity限制圈复杂度防止AI写出过于复杂的逻辑no-new-dependencies这个不是ESLint内置规则但可以通过自定义规则或CI检查来实现Prettier的配置相对简单主要是缩进、引号、分号、行宽这几个选项。关键是团队要统一不要有的人用两个空格有的人用四个空格。配置好之后在package.json里加一个lint脚本{ scripts: { lint: eslint src/ --ext .ts,.js, lint:fix: eslint src/ --ext .ts,.js --fix, format: prettier --write src/**/*.{ts,js,json} } }每次AI生成代码后先跑npm run lint看看有没有报错。有报错就让AI根据报错信息修正或者手动修正。修正完再跑npm run format统一格式。4.3 用Git Hook做提交前检查Lint脚本需要手动跑容易忘记。更可靠的方式是通过Git Hook在提交前自动执行。使用husky lint-staged可以在每次git commit时自动对暂存区的文件执行lint和format。配置方式如下npm install --save-dev husky lint-staged npx husky install npx husky add .husky/pre-commit npx lint-staged然后在package.json里配置lint-staged{ lint-staged: { *.{ts,js}: [ eslint --fix, prettier --write ] } }这样每次提交代码时ESLint和Prettier会自动对修改的文件进行处理。如果ESLint报错且无法自动修复提交会被阻止。这就强制保证了进入仓库的代码包括AI生成的代码都符合规范。我自己的项目里加上这个Hook之后AI生成的代码基本不会出现console.log、未使用变量、格式混乱这些问题了。因为AI在生成代码时如果写了console.log提交时会被ESLint拦下来然后我会让AI修正修正后的代码就干净了。4.4 自定义规则拦截“自作聪明”行为除了ESLint内置规则还可以通过自定义规则来拦截一些项目特有的“自作聪明”行为。比如有些AI特别喜欢引入lodash。你可以在ESLint配置里加一条no-restricted-imports规则{ rules: { no-restricted-imports: [error, { paths: [lodash, underscore, ramda], message: 项目禁止使用工具库请用原生方法实现 }] } }再比如有些AI喜欢用any类型。可以加一条typescript-eslint/no-explicit-any规则{ rules: { typescript-eslint/no-explicit-any: error } }还有有些AI喜欢写console.log、debugger、alert这些调试语句。ESLint的no-console、no-debugger、no-alert规则可以全部开启。这些规则加上之后AI在生成代码时如果触发了这些规则Lint会报错你就知道AI又“自作聪明”了可以针对性地修正。5. 实操全流程从需求到可提交代码5.1 完整流程概览把前面讲的几个模块串起来一个完整的AI辅助编程流程大概是这样的第一步准备AGENTS.md文件放在项目根目录。如果项目还没有花半小时写一个。第二步在AI对话开始时粘贴AGENTS.md内容并说明“请遵守以上项目规范”。第三步用结构化Prompt描述任务包含角色、上下文、任务、约束、输出格式五个要素。第四步AI生成代码后先肉眼扫一遍看整体方向对不对。第五步把代码粘贴到项目里跑npm run lint检查规范问题。第六步如果有Lint报错把报错信息反馈给AI让它修正。第七步修正后的代码再跑一次Lint确认通过。第八步跑npm test确认功能正常。第九步提交代码Git Hook会自动做最后的格式检查。这个流程看起来步骤多但实际操作起来很快。熟练之后从下指令到代码可提交一个中等复杂度的函数大概五到十分钟就能搞定。5.2 一个完整的实操案例假设我们要在一个Express项目里实现一个“获取当前用户信息”的接口。项目已经有JWT认证中间件User模型包含id、email、nickname、avatar、createdAt字段。第一步准备Prompt你是一个有五年经验的Node.js后端开发者。 项目使用Express 4.18 Prisma 5.x PostgreSQL 15。 已有JWT认证中间件 src/middlewares/auth.ts会在req.user中注入用户ID。 已有User模型包含字段id, email, nickname, avatar, createdAt。 任务实现GET /api/me接口返回当前登录用户的信息。 - 从req.user中获取用户ID - 查询用户记录 - 返回id、email、nickname、avatar、createdAt - 如果用户不存在返回404 约束 - 不要返回passwordHash字段 - 不要引入新依赖 - 不要写console.log - 错误处理使用项目统一的AppError类 - 不要写注释 输出只返回controller函数的代码。第二步AI生成代码AI返回了如下代码import { Request, Response, NextFunction } from express; import { prisma } from ../lib/prisma; import { AppError } from ../utils/AppError; export async function getCurrentUser( req: Request, res: Response, next: NextFunction ): Promisevoid { try { const userId req.user?.id; if (!userId) { throw new AppError(Unauthorized, 401); } const user await prisma.user.findUnique({ where: { id: userId }, select: { id: true, email: true, nickname: true, avatar: true, createdAt: true, }, }); if (!user) { throw new AppError(User not found, 404); } res.json({ data: user }); } catch (error) { next(error); } }第三步代码审查肉眼扫一遍整体没问题。没有引入新依赖没有console.log没有返回passwordHash错误处理用了AppError。select里明确列出了要返回的字段没有用select: { passwordHash: false }这种写法更安全。第四步Lint检查把代码放到src/controllers/user.controller.ts跑npm run lint。没有报错。第五步测试跑npm test已有的测试用例通过。手动用Postman测一下接口返回数据正确。第六步提交git addgit commitGit Hook自动跑Prettier格式化提交成功。整个流程从写Prompt到提交大概花了八分钟。如果不用AGENTS.md和结构化PromptAI可能会返回一个包含分页、缓存、字段过滤等额外功能的版本审查和修正的时间至少要翻倍。5.3 不同场景下的Prompt模板根据任务类型的不同Prompt的侧重点也不一样。下面给出几个常见场景的模板。场景一新增接口重点是明确输入输出、错误处理、权限校验。约束里要强调不要添加额外的业务逻辑。场景二修改现有函数重点是明确修改范围。约束里要强调“只修改指定的部分不要重构其他代码”。场景三修复Bug重点是提供错误信息和复现步骤。约束里要强调“只修复Bug不要顺便优化代码”。场景四写测试重点是明确测试框架、测试范围、断言风格。约束里要强调“不要测试框架本身的代码”。场景五重构重点是明确重构目标和保持行为不变。约束里要强调“不要改变函数签名和返回值”。每个场景的模板都可以在AGENTS.md的基础上做调整。核心原则不变给足上下文、明确约束、指定输出格式。6. 常见问题与排查技巧实录6.1 AI反复引入不需要的依赖怎么办这是最常见的问题。你明明说了“不要引入新依赖”AI还是写了import _ from lodash。排查思路首先确认AGENTS.md里有没有明确写“禁止引入新依赖”。如果没有加上。如果有检查Prompt里有没有重复强调。如果都有那就是AI的“惯性”太强了需要在Lint层面做拦截。解决方法在ESLint里配置no-restricted-imports规则把常见的工具库都列进去。这样即使AI写了Lint也会报错你就能及时发现并让AI修正。另外可以在Prompt里加一句“如果你认为需要引入新依赖请先停下来询问我不要直接写import语句”。这样AI在想要引入依赖时会先问你而不是直接写。6.2 AI生成的代码总是“过度设计”怎么办AI特别喜欢用设计模式。一个简单的数据转换它要给你搞个策略模式一个普通的CRUD它要给你搞个Repository模式。排查思路检查Prompt里有没有明确说“用最直白的写法”。如果没有加上。同时检查AGENTS.md里有没有“禁止使用设计模式”的约束。解决方法在Prompt里加一句“用最直白的写法实现不要使用任何设计模式不要为了扩展性而抽象”。另外可以在Lint里加max-lines-per-function和complexity规则函数太长或太复杂就报错逼着AI写简单代码。我自己的经验是加上“不要使用设计模式”这条约束后AI生成的代码明显简洁了很多。以前一个函数动辄上百行现在基本都在三十行以内。6.3 AI写的代码能跑但不符合项目风格怎么办比如项目用单引号AI用双引号项目用两个空格缩进AI用四个空格项目用驼峰命名AI用下划线。排查思路检查AGENTS.md里有没有写清楚代码规范。如果只写了“遵循ESLint配置”AI可能不知道具体规则是什么。要把关键规则明确写出来。解决方法在AGENTS.md里把代码规范写具体不要只说“遵循项目规范”要说“缩进2空格、单引号、必须写分号、函数名用驼峰”。另外Prettier配置要放在项目根目录AI生成代码后跑一次npm run format就能统一格式。如果AI反复在某个格式问题上出错可以在Prompt里单独强调。比如“字符串必须用单引号不要用双引号”。强调几次之后AI一般就能记住。6.4 AI生成的代码有隐藏Bug怎么发现有些Bug很隐蔽比如边界条件处理错误、异步操作没有await、变量作用域问题。这些Bug Lint查不出来测试也可能覆盖不到。排查思路对于关键逻辑不要完全信任AI。自己逐行读一遍特别是条件判断、循环边界、异步操作这些容易出错的地方。解决方法让AI自己解释代码。在生成代码后加一句“请逐行解释这段代码的逻辑特别是边界条件的处理”。AI在解释的过程中往往会自己发现一些问题。另外可以让AI生成测试用例通过测试来验证逻辑正确性。我自己的习惯是对于涉及金额计算、权限判断、数据过滤这些关键逻辑AI生成的代码一定要自己读一遍。其他不太关键的代码跑通测试就行。6.5 常见问题速查表问题现象可能原因排查方法解决措施AI引入新依赖AGENTS.md未声明禁止检查AGENTS.md和Prompt加no-restricted-imports规则代码过度设计Prompt未限制写法检查Prompt约束条件加“用最直白写法”约束格式不符合规范规范未写具体检查AGENTS.md代码规范部分写具体规范Prettier格式化函数过长未限制函数行数检查Lint配置加max-lines-per-function规则有console.log未禁止调试语句检查Lint配置加no-console规则返回多余字段Prompt未明确字段检查Prompt输出描述明确列出要返回的字段错误处理不一致未指定错误处理方式检查AGENTS.md明确使用项目统一错误类异步未awaitAI疏忽人工审查加require-await规则6.6 几个我踩过的坑第一个坑AGENTS.md写得太长。一开始我把所有能想到的规范都写进去结果文件有五百多行。AI读取的时候反而抓不住重点效果不好。后来精简到一百行左右只保留最关键的约束效果反而更好。第二个坑Prompt里约束太多。有一次我写了一个很长的Prompt列了二十多条约束。结果AI顾此失彼满足了这条忘了那条。后来我把约束分成“必须遵守”和“尽量遵守”两档必须遵守的放在前面尽量遵守的放在后面效果好很多。第三个坑完全信任AI的测试代码。有一次让AI写测试它写的测试全部通过但后来发现测试本身有问题——断言写得太宽松根本没测到关键逻辑。后来我要求AI写测试时必须包含边界条件的测试用例并且断言要具体。第四个坑忘记更新AGENTS.md。项目从JavaScript迁移到TypeScript后AGENTS.md里还写着“使用JavaScript”。结果AI生成的代码全是JS跟项目不匹配。后来养成了习惯每次技术栈变更后第一件事就是更新AGENTS.md。7. 让AI成为听话的助手而不是自作聪明的“专家”7.1 心态上的调整很多人对AI编程有一个误区觉得AI应该“懂我”应该能自动理解项目情况。但现实是AI没有读心术它只能根据你给的信息来工作。你给的信息越少它就越需要“猜”而猜的结果往往就是“自作聪明”。所以与其抱怨AI不听话不如把精力花在如何给AI提供更好的上下文和更明确的约束上。这其实和带新人的逻辑是一样的——你不能指望一个新来的同事自动了解项目规范你得写文档、做培训、Code Review。AI也是一样AGENTS.md就是它的入职文档Prompt就是它的任务工单Lint就是它的Code Review。7.2 持续优化的循环治好AI的“自作聪明”不是一次性的工作而是一个持续优化的循环。每次AI生成代码后如果发现“自作聪明”的行为就把它记录下来。如果是AGENTS.md没写清楚的补充进去如果是Prompt没约束到的下次加上如果是Lint没拦截的加条规则。这样循环几轮之后你会发现AI生成代码的质量越来越高需要修正的地方越来越少。我自己的项目大概经过两个月的迭代现在AI生成的代码有百分之七八十可以直接用剩下的百分之二三十稍微改改就行。7.3 一个实用的小技巧最后分享一个我最近在用的技巧在AGENTS.md里加一个“最近踩坑记录”段落把最近AI犯过的错误记下来。比如“2024-01-15AI在生成用户查询时没有过滤已删除用户导致返回了软删除的数据。所有查询必须加where: { deletedAt: null }”。这个段落不用很长每次踩坑后加一行就行。AI在读取AGENTS.md时会看到这些记录从而避免重复犯错。实测下来这个技巧对减少重复性错误非常有效。另外如果你用的是支持多轮对话的AI工具可以在对话结束时加一句“请总结本次对话中我强调的所有约束以便后续对话参考”。AI会把这些约束整理出来你可以直接复制到AGENTS.md里。这样相当于让AI帮你维护项目规范文档省了不少事。
