优雅！太优雅！斯巴拉西！怎么让AI写出最优雅的代码

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 });
};

总结一下

1. 建立权威：你是老板，AI是员工
2. 制定规范：详细到每个命名规则
3. 强制执行：每次都要提醒AI遵守
4. 持续优化：规范不合理就改进

记住：AI很聪明，但也很"散漫"。只有给它戴上"紧箍咒"，就像牛马套上了车架，这样，它才能写出真正优雅的代码！

---

最后问一句：你学会了吗？

如果学会了，赶紧去调教你的TRAE吧！记住，一句话，你不干有的是 AI 干！

---

💡 小贴士：觉得文章有用的话，记得点赞收藏哦～ 让更多程序员摆脱💩山困扰！