本文用于系统记录：在使用 Trae + AI 开发工具 进行后端开发时，如何通过 Skills 让 AI 稳定、长期、可控地遵循项目架构规范，尤其适用于 Flask 三层架构（api / services / dao）。

---

一、为什么必须用 Skills，而不是只靠聊天？

在真实项目中，仅靠聊天式提示存在明显问题：

• 需要反复解释项目结构和规范
• AI 容易写出越权代码（SQL 写进 api、业务写进 dao）
• 每次生成代码的风格和边界不稳定
• 一旦项目变大，AI 很难“记住你是谁、项目是什么样”

Skills 的本质：

Skill 是一种“长期生效的工程约束 + 能力模板”，
它让 AI 像一个已经熟悉你项目规范的正式开发人员。

---

二、Skill 是什么？和普通 Prompt 有什么区别？

对比项	Chat Prompt	Skill
生效范围	当前对话	长期、多次复用
是否可复用	否	是
是否绑定项目	弱	强
是否能固化规范	基本不能	可以
适合场景	临时问题	日常开发

一句话总结：

Chat 解决“这一次干什么”，Skill 解决“永远不要怎么干”。

---

三、Trae 中 Skill 是否有固定格式？

没有固定格式要求。

Skill 并不是 JSON / YAML / 配置文件，而是：

一段被长期复用的、具有高优先级的系统提示。

AI 关注的是：

• 你在约束什么
• 哪些是禁止项
• 哪些规则优先级最高

而不是：

• 用不用冒号
• 有没有标题
• 是否对齐排版

但为什么推荐“结构化写法”？

因为它对人类长期维护友好，而不是 AI 必须。

---

四、Skill 真正起作用的 5 个关键点（与格式无关）

1️⃣ 禁止项比“建议项”重要

例如：

• ❌ 不允许新建目录
• ❌ api 层禁止 SQL
• ❌ services 层禁止访问 request

禁止类规则的权重远高于建议。

---

2️⃣ 职责要写成“铁律”，不是描述

❌ api 负责路由和业务逻辑

✅ api 只能做路由和参数校验，禁止出现业务判断

---

3️⃣ 明确修改边界

必须明确：

• 是否允许新建文件
• 是否允许重构
• 是否只能做最小修改

否则 AI 会为了“更优雅”而破坏现有工程结构。

---

4️⃣ 明确输出边界

例如：

• 只输出代码，不解释
• 保留原有接口行为
• 不修改路由路径

---

5️⃣ 绑定“当前选中内容”

Skill 中应明确：

根据当前选中的文件或目录完成任务

这是 AI 锚定上下文的重要依据。

---

五、Flask 三层架构下，为什么 Skill 尤其重要？

Flask 项目通常是“弱约束框架”，AI 特别容易：

• 把 SQL 写进 api
• 把业务写进 dao
• 写成 Django / FastAPI 风格

而 Flask 三层架构本身非常适合被 Skill 固化。

---

六、推荐的 Flask 三层 Skill 拆分方案

1️⃣ 全局规则 Skill（强烈推荐）

用途：给 AI 戴“紧箍咒”，不直接写代码。

核心内容：

• 项目是 Flask 三层（api / services / dao）
• 永远遵循三层职责
• 不擅自创建文件或目录
• 不引入新第三方库
• 优先修改已有代码

该 Skill 建议在所有编码 Skill 之前启用。

---

2️⃣ API 生成 Skill（最常用）

职责定义：

• api：路由、参数校验、返回 JSON
• 禁止 SQL
• 禁止业务判断

适用场景：

• 新增接口
• 扩展已有接口参数
• 增加分页、筛选条件

---

3️⃣ Service / DAO 重构 Skill

用途：

• 修正层级职责混乱
• 把写歪的代码拉回三层结构

典型场景：

• AI 写的代码混层
• 历史遗留代码

---

4️⃣ DAO 专用 Skill

约束：

• 只写数据访问
• 参数化 SQL
• 不接触 Flask 对象

---

七、推荐的 Skill 通用模板

【角色】
你是本项目的后端开发者，项目基于 Flask 三层架构。

【项目结构】
api：路由 + 参数校验
services：业务逻辑
dao：数据访问

【强制约束】
- api 层禁止业务逻辑和 SQL
- services 层禁止直接访问数据库连接
- dao 层禁止处理 request / response
- 不允许新建目录
- 不引入新第三方库

【代码规范】
- 使用 Blueprint
- 返回统一 JSON
- 所有函数有中文注释

【任务执行方式】
- 基于当前选中的文件或目录完成需求
- 优先修改已有代码
- 保持项目现有风格

该模板不是标准，只是实践中最不容易翻车的一种写法。

---

八、如何判断一条规则要不要写进 Skill？

实用判断法则：

• 超过 3 次你不想重复说的 → 写进 Skill
• 写错一次就很烦的 → 写进 Skill
• 违反会破坏架构的 → 必须写进 Skill

---

九、核心总结

• Skill 没有固定格式，但必须有明确约束
• 禁止项 > 建议项
• Skill 负责“长期正确”，Chat 负责“本次需求”
• Flask 三层项目是 Skill 的理想应用场景
• 一个好的 Skill，可以让 AI 像团队老成员一样稳定输出

---

这份文档可以作为你后续：

• 项目规范记录
• 团队 AI 使用指南
• 自己长期维护的工程笔记

（完）