AI？纯💩山制造机
最近 TRAE 越来越火了！兄弟们！你们有没有遇到过这样的情况：
用着 TRAE 写代码，一开始感觉挺爽的，毕竟生成代码的速度比手写快多了，一拉一大把。但是... 写着写着就发现不对劲了！
每次问AI写代码，它都有自己的"小心思"：
- 第一次让写用户登录功能：用React函数组件实现，用户信息变量叫
userInfo，登录状态用isLogin表示，错误信息存在loginError里第二次让加个注册功能：还是函数组件，但用户信息突然叫userData，登录状态变成hasLoggedIn，错误信息又换成regError第三次让整合登录注册为auth模块：变量命名更混乱了，userDetail、isAuthenticated、errorMessage混着用，明明是同一个含义的状态，却在三个地方用了三种不同的命名更让人崩溃的是TypeScript类型定义：
- 写个人中心组件时，AI定义了
UserProfile接口，包含userName、userAge字段写用户列表组件时，AI又定义了UserInfo接口，同样的用户名称字段写成name，年龄写成age后来加消息通知功能，需要显示发送者信息，AI直接在组件里写了{ name: string; age?: number }的匿名类型最绝的是处理用户状态时，同一个"在线/离线"状态，在登录组件里是'online' | 'offline'字面量类型，在列表组件里变成UserStatus枚举，在设置页面又成了0 | 1数字类型结果就是同一个项目里，不仅变量命名混乱，连最该严谨的TypeScript类型都成了"各自为政"的重灾区，想复用类型时发现根本兼容不了，只能靠类型断言强行"缝合"，堪称现代版"屎山"制造机！
最后项目是完成了，但是代码风格五花八门：左边一坨右边一坨，每一坨单独看都很精致，但整体看起来就是一座💩山！！！
这种感觉就像是让10个不同的厨师给你做菜，每道菜都很好吃，但放在一起就是一桌奇怪的满汉全席... 🤮
真恼火！
解决方案：把AI训练成"服服帖帖的小女仆"
那咋办？今天，我就来教教大家怎么把AI调教成听话的服服帖帖的"白毛白丝萝莉小女仆"！
第一步：摆正心态 - 我他喵就是老板
重点来了！ 你要把自己放在老板的位置上，去"CPU"这些AI！
把AI当成什么？老油条员工！
那怎么管理老油条员工？就是要狠狠的规范化！！！
"你不干？有的是AI干！""三千块的程序员找不到，300块钱的AI一大把！"现在AI这么发达，你这个AI迟早要被淘汰嘞！还不努力？好好干，年底给你发奖金！
让AI必须严格按照你的团队规范写代码，不准有任何"创新"！
第二步：制定铁一般的编码规范
下面举个栗子🌰，教你如何让AI写出最优雅的代码。比如，我要让AI规范化的编写API代码
2.1 以AI制AI的神操作
既然AI喜欢自由发挥，那我们就用AI来对付AI！
找个AI助手（比如豆包、GPT等），跟它说：
"请你帮我生成一个前端 API 代码编写规范，要求优雅符合工程化，统一风格、提升协作效率"经过几轮调教，你就能得到一个完美的规范文档：
# 前端 API 代码编写规范## 一、总则1. 本规范仅适用于本项目前端团队内部 API 相关代码编写，旨在统一风格、提升协作效率，与后端接口设计无强制关联。2. 所有 API 相关代码需遵循“清晰可读、见名知意”原则，避免模糊命名或冗余逻辑。## 二、类型定义规范1. **文件位置**：所有与 API 相关的类型定义必须集中在 `src/api/types.ts` 中，禁止在业务组件、工具函数等其他文件中单独定义。2. **命名规则**： - 类型命名统一遵循 PascalCase 命名法。 - 基础共享数据结构需以 `Base` 为前缀。 - 接口请求参数类型命名格式为 `[接口名]Req`。 - 接口响应数据类型命名格式为 `[接口名]Res`。 - 枚举类型需以 `Enum` 为后缀，明确语义。3. **结构要求**：新增接口类型时，需按业务模块分组存放，保持 `types.ts` 文件结构清晰。## 三、接口函数命名规范1. **命名格式**：按“操作类型+业务模块”的规则命名，采用 camelCase 命名法。2. **操作类型对应命名**： - 获取分页列表：`get[模块]PageList` - 获取全量列表：`get[模块]List` - 获取单条详情：`get[模块]Detail` - 新增资源：`create[模块]` - 更新资源：`update[模块]` - 删除资源：`delete[模块]`## 四、参数命名规范1. 分页查询参数统一使用 `params` 作为参数名。2. 单个 ID 参数直接使用 `id` 作为参数名。3. 表单提交或完整数据对象使用 `data` 作为参数名。4. 其他参数按语义化命名，采用 camelCase 命名法。## 五、文件组织规范1. API 接口函数按业务模块拆分文件，存放于 `src/api` 目录下，每个模块对应一个文件。2. 类型定义集中在 `src/api/types.ts`，按业务模块划分代码块。## 六、注释规范1. 类型定义需添加注释，说明其用途及核心字段含义。2. 接口函数需添加注释，说明功能、参数含义及返回值信息。3. 复杂业务逻辑需补充注释，说明设计思路或特殊处理原因。## 七、代码示例### 1. 枚举使用\`\`\`typescript// ❌ 错误：直接使用原始值而不通过枚举// 问题：语义不清晰，修改时需全局替换if (product.status === 1) { // 无法直观判断1代表什么状态}// ❌ 错误：使用字符串联合类型而非枚举// 问题：缺少语义化标识，IDE无自动提示type ProductStatus = 1 | 2 | 3;if (product.status === 2) { // 需查文档才知2代表什么状态}// ❌ 错误：枚举命名不规范// 问题：不符合PascalCase+Enum后缀的命名规则enum productStatus { Available = 1, Unavailable = 2}\`\`\`\`\`\`typescript// ✅ 正确：使用规范枚举关联后端数字状态// 优势：键名承载语义，值对应后端实际传输值enum ProductStatusEnum { Available = 1, // 键名说明含义 Unavailable = 2, // 值对应后端定义的数字 Maintenance = 3}// ✅ 正确使用场景if (product.status === ProductStatusEnum.Available) { // 无需注释也能理解业务逻辑 showAvailableLabel();}// ✅ 优势：后端值变更时只需修改枚举映射enum ProductStatusEnum { Available = 10, // 仅修改这里，业务代码无需变动 Unavailable = 20, Maintenance = 30}\`\`\`说明：枚举的核心价值是建立"语义标识"与"实际传输值"的映射关系，无论后端使用字符串还是数字作为状态值，前端都应通过规范命名的枚举（PascalCase+Enum后缀）进行关联，既保证代码可读性，又降低后端值变更时的维护成本。第三步：让AI强制遵守规范
3.1 创建规范文档
把上面的规范保存到 src/api/README.md 文件中。
3.2 调教AI的终极大招
方法一：添加到AI知识库在AI IDE的知识库中添加这个README.md文件作为记忆。
方法二：每次提问时提醒每次问AI写代码时，加上这句话：
"请帮我完成XXX开发，在编写代码的时候，请详细阅读各个模块下面的README.md文件"
第四步：验证效果
现在再让AI写代码，你会发现：
✅ 代码风格统一了：不管问多少次，都是同一套规范
✅ 命名规范了：见名知意，不用猜
✅ 结构清晰了：文件组织有条理
✅ 维护简单了：后续修改不头疼
下面是我用上面的规范让AI生成的代码，优雅！太优雅了！
/** * API 类型定义文件 * * 规范说明： * 1. 所有与API相关的类型定义必须集中在此文件中，禁止在其他业务文件中单独定义 * 2. 类型命名遵循 PascalCase 命名法，使用清晰的业务名称 * 3. 接口请求参数命名为 [接口名]Req * 4. 接口响应数据命名为 [接口名]Res * 5. 共享数据结构提取为独立类型，使用 Base 前缀（如 BaseResult） * 6. 枚举类型使用 Enum 后缀，保持语义明确 * 7. 新增接口类型时，请按业务模块分组，保持文件结构清晰 */// ========================= 基础通用类型 =========================/** * 基础响应结果泛型 * 所有API响应都应遵循此结构 */export type BaseResult<T = any> = { code: number; // 状态码，200表示成功 msg?: string; // 响应消息，成功时可能为空 total?: number; // 总记录数，分页场景下返回 data?: T; // 响应数据主体};/** * 分页查询基础参数 */export type BasePageReq = { page: number; // 当前页码，>=1 limit: number; // 每页数量，>=1};// ========================= 知识库模块 =========================enum KbEnum { Available = "available", // 可用 Unavailable = "unavailable" // 不可用}/** * 知识库分页查询请求参数 * 接口地址: POST /api/v1/knowledge_base/kb_page_with_doc_count */export type KbPageReq = BasePageReq & { name?: string; // 名称关键词（模糊匹配，可选）};/** * 知识库分页查询响应结果 * 接口地址: POST /api/v1/knowledge_base/kb_page_with_doc_count */export type KbPageRes = BaseResult< { id: number; // 知识库唯一标识 name: string; // 知识库名称 token: string; // 知识库访问令牌 create_time: string; // 创建时间，格式为datetime字符串 update_time: string; // 更新时间，格式为datetime字符串 status: KbEnum; // 知识库状态，available表示可用，unavailable表示不可用 document_count: number; // 该知识库下的文档数量 }[]>;/** * 知识库管理相关API接口 * * 本模块提供知识库的增删改查等操作接口 */import { http } from "@/utils/http";import type { KbPageReq, KbPageRes } from "./types";/** * 获取知识库分页列表（包含文档数量） * @param params 分页查询参数 * @returns 知识库分页数据 */export const getKbPage = (params: KbPageReq) => { return http.request<KbPageRes>("post", "/api/v1/knowledge_base/kb_page_with_doc_count", { data: params });};总结一下
- 建立权威：你是老板，AI是员工制定规范：详细到每个命名规则强制执行：每次都要提醒AI遵守持续优化：规范不合理就改进
记住：AI很聪明，但也很"散漫"。只有给它戴上"紧箍咒"，就像牛马套上了车架，这样，它才能写出真正优雅的代码！
最后问一句：你学会了吗？
如果学会了，赶紧去调教你的TRAE吧！记住，一句话，你不干有的是 AI 干！
💡 小贴士：觉得文章有用的话，记得点赞收藏哦～ 让更多程序员摆脱💩山困扰！
