CodeBuddy · 腾讯云课程资料

System Prompt 与 Rules

面向开发者的 AI 编程、上下文工程与多 Agent 协作。

返回专题 →智能体教程 →

来源：腾讯云培训认证中心 · CodeBuddy 架构师认证课程 · ch3

第 三 章 · Chapter 3

System Prompt 与 Rules

本 章 学 什 么

  • 理解 System Prompt 的「性格设定」作用，学会用 Rules 文件稳定 AI 输出风格

  • 掌握项目级 / 全局级 Rules 的写法、优先级、Glob 自动匹配

  • 掌握"代码风格模仿三步法" + 沉淀可复用的 Prompt 模板库

前两章我们掌握了工具的安装和对话模式。这一章解决一个关键问题——**怎么让 AI 的输出风格稳定可控？**每次让 AI 写代码，命名规范、框架选择、注释风格都不一样，因为你没告诉它"你的标准是什么"。System Prompt 和 Rules 就是解决这个问题的。

操 作 环 境 说 明

本章实操推荐使用 CloudStudio（cloudstudio.net）——内置 CodeBuddy 与完备沙箱环境，免费学习 AI Coding，无需本地安装。也可以使用 CodeBuddy IDE / 插件 / CLI 任意形态跟随练习——所有涉及文件操作的步骤（创建 .codebuddy/rules/ 目录、编写规则文件）操作方式完全一致。

3.1 System Prompt 原理

每一个 AI 对话背后都有一个隐藏的「人设说明书」——这就是 System Prompt（系统提示词）。不定制 = 每次和陌生人合作；定制后 = AI 变成熟悉你偏好的搭档。

影响的四个维度

维度 不定制 vs 定制后
编码风格 函数式 vs 面向对象、箭头 vs 普通函数、解构赋值 vs 传统赋值——这些偏好都受 System Prompt 影响
语言框架 TS vs JS、React vs Vue、Next.js App Router vs Pages Router——AI 默认选哪个，取决于 System Prompt
注释习惯 中文还是英文、每个函数都加注释还是关键逻辑才加——不定制每次可能不一样
错误处理 静默处理 vs 抛异常、try-catch 范围、自定义 Error 类 vs 裸字符串——可以统一

不定制 vs 定制后 · 六场景对比

场景 不定制 定制后
变量命名 起名随缘，data / info / result 满天飞 全团队统一命名风格
类型系统 JS 还是 TS？看 AI 心情 一律 TS strict，不商量
样式方案 今天 CSS Module，明天 Styled Components 锁死 TailwindCSS
注释语言 一会儿中文一会儿英文 统一中文注释
错误处理 边界情况？不存在的 每个异常都必须兜住
代码组织 文件想放哪放哪 严格按约定目录结构

3.2 Rules 配置入口与规则文件实操

在 CodeBuddy 中定制 AI 行为的具体方式是 Rules（规则文件）——有项目级和全局级两种。

两种配置方式

方式 路径与适用
项目级（推荐） 项目根目录 .codebuddy/rules/ 文件夹，扔 Markdown 文件即可。规则跟着项目走，团队成员拉下代码自动生效。按规则类型拆多个 .md 文件：coding-style.md 编码风格、conventions.md 命名约定、project-context.md 项目背景
全局用户级 通过 CodeBuddy 设置面板配置，存放在 ~/.codebuddy/rules/。适用于你所有项目，适合"所有注释用中文"这类个人偏好

优先级：项目级 > 全局用户级——冲突时项目级说了算。

Rules 触发模式

触发模式 说明
Always 每次对话都自动加载，适合核心编码风格规则
Manual 只在手动触发时加载
Agent Requested AI 判断当前任务需要此规则时主动加载
Auto Attached 基于 glob 模式自动匹配文件类型时加载

glob 配置示例：

  • /**/*.tsx——只对 React 组件文件生效

  • /**/*.ts——只对 TypeScript 文件生效

  • /**/*.py——只对 Python 文件生效

这样可以实现「写前端代码自动遵循前端规范，写后端代码自动遵循后端规范」，互不干扰。

第一份规则文件 · 三个核心部分

coding-style.md · 编码风格规则

语言与框架——始终使用 TypeScript strict 模式；React 用函数式组件 + Hooks；样式用 TailwindCSS。 命名规范——组件 PascalCase、函数 camelCase、常量 UPPER_SNAKE_CASE、布尔变量 is / has 开头。 代码风格——优先 const、箭头函数、函数式编程、early return、每个函数不超过 30 行。 目录结构约定——components/ 可复用组件 / app/ 页面路由 / lib/ 工具函数 / types/ 类型定义 / hooks/ 自定义 Hooks / constants/ 常量。

类型与错误处理

类型定义——所有函数参数和返回值加类型注解；interface 定义对象类型；type 定义联合类型。 错误处理——API 请求必须 try-catch；用户可见错误用中文；控制台日志用英文；使用自定义 Error 类。

project-context.md · 项目上下文

技术栈版本——Next.js 14 / React 18 / TypeScript 5 / TailwindCSS 3 / Node.js 20。 API 约定——RESTful 风格，统一响应格式 { code, data, message }，错误码 200 / 400 / 401 / 500。 重要约定——状态管理：简单用 useState/useReducer，复杂用 Context；数据获取优先 Server Components + fetch；表单 React Hook Form + Zod；UI shadcn/ui + Lucide React。

验证与排查

**验证方法。**用同一个需求让 AI 跑两次（如「帮我创建一个用户资料编辑组件」），对比两次输出是否风格一致。风格趋同 = 规则在稳定约束 AI。

规则不生效 · 检查两件事：

  • 路径对不对——必须是 .codebuddy/rules/，那个点不能少

  • 规则措辞够不够硬——「代码要整洁」AI 会忽略，「每个函数必须不超过 30 行」才有约束力。**「必须」「禁止」「始终」**这类词让 AI 把规则当硬约束

下面这段视频从零创建规则文件、验证规则真正生效——重点看同一需求两次生成对比验证这个标准方法。

3.3 代码风格模仿术与 Prompt 模板库

规则定底线，模仿处理细节——Rules 文件定义强制约束，风格模仿处理更细微的习惯。两者结合使用效果最好。

代码风格模仿三步法

步骤 动作与提示词
① 提供样本 用 @ 引用项目典型文件——「请阅读以下文件，学习其中的：组件结构模式、Hook 封装方式、类型定义习惯、错误处理方式、注释风格」
② 要求一致 「按照刚才学到的风格生成新组件，要求和原有代码保持完全一致的代码风格，从结构到命名，从注释到错误处理」
③ 自检差异 「对比原始文件和新生成的代码，列出风格差异点并修正不一致」——AI 主动发现并修正差异，比逐行审查高效得多

Prompt 模板库 · 三个常用模板

创建 [组件名] 组件：

  • 功能：[功能描述]
  • Props：[接口定义]
  • 状态：[需要管理的状态]
  • 交互：[用户交互行为]
  • 样式参考：[设计参考]复制

创建 API 路由 [路径]：

  • 方法：GET / POST / PUT / DELETE
  • 入参：[参数说明]
  • 出参：[返回数据结构]
  • 校验：[参数校验规则]
  • 错误处理：[异常情况]复制

创建自定义 Hook [Hook 名]：

  • 用途：[解决什么问题]
  • 输入：[参数]
  • 输出：[返回值]
  • 副作用：[需要处理的副作用]
  • 清理：[需要清理的资源]复制

建议把 Prompt 模板整理成一个文件保存在项目里，方便团队共享。

3.4 规则分层策略 · 5 原则 · 3 反模式

规则的三层结构

层级 作用范围与示例
全局层 个人偏好，所有项目通用——「所有注释用中文」「优先 TypeScript」。通过 CodeBuddy 设置面板配置
项目层 跟着项目走，团队成员共享——「技术栈版本约定」「目录结构」「API 响应格式」。放在 .codebuddy/rules/
任务层 对话中临时指定，针对特定任务——「这次重构要保持接口不变」。在 CodeBuddy 对话中直接说明

优先级：任务层 > 项目层 > 全局层——越具体的规则优先级越高，冲突时听具体的。

规则编写 5 原则

规则的核心是「可验证」——你自己都判断不了 AI 有没有遵守，AI 也很难遵守。

原则 反例 → 正例
① 具体 「代码要简洁」→ 「每个函数不超过 30 行」
② 可验证 「写好代码」→ 「启用 TypeScript strict 模式」
③ 有优先级 冲突时知道听谁的——「性能和可读性冲突时，优先可读性」
④ 有例外 说明何时可以破例——「除非是第三方库的回调，否则都用箭头函数」
⑤ 有示例 规则旁边给出正例和反例，让 AI 理解边界在哪里

三大反模式

反模式 问题与解决
① 规则太多 100+ 条细碎规则（缩进 2 空格、字符串单引号……）AI 记不住。聚焦 20 条核心规则，其余交给 ESLint，规则中写「详见 .eslintrc.json」
② 自相矛盾 同时写「优先函数式编程」和「所有组件用 Class Component」——两条规则冲突。写完通读一遍，检查逻辑冲突，确保规则自洽
③ 无上下文 只写「使用 useSWR」——AI 不知道什么场景该用。加上场景限定：「客户端数据获取用 useSWR；服务端用 Next.js 内置 fetch」

3.5 练习与自测

  • **创建规则文件（必做）。**在项目创建 .codebuddy/rules/coding-style.md，至少包含语言框架、命名规范、代码风格、错误处理四个章节，至少 10 条规则。然后用 AI 生成一个组件验证规则是否生效

  • **风格模仿测试（进阶）。**找一个开源组件（如 shadcn/ui），用 @ 喂给 CodeBuddy 让它学习风格，然后要求用同样风格生成新组件。对比原始风格和 AI 输出的差异

  • **Prompt 模板库（必做）。**建立你自己的模板库，至少包含 5 个模板：创建组件 / 创建 API / 创建 Hook / Bug 修复 / 代码重构，保存为文件放在项目里

本章小结

  • System Prompt 原理——AI 的「性格设定」，决定编码风格、框架选择、注释习惯、错误处理。不定制 = 每次和陌生人合作

  • Rules 实操——配置 .codebuddy/rules/ 项目级规则；触发模式 Always / Manual / Agent Requested / Auto Attached；同一需求两次生成风格趋同 = 规则生效

  • 进阶技巧——代码风格模仿三步法（提供样本 → 要求一致 → 自检差异）；Prompt 模板库标准化常见任务

  • 方法论——规则分三层（全局 / 项目 / 任务）；5 原则（具体 / 可验证 / 有优先级 / 有例外 / 有示例）；避免 3 反模式（太多 / 矛盾 / 无上下文）

下一模块进入**「上下文工程」**——规则解决了「AI 的风格」问题，下一讲解决「AI 的视野」问题：用 @ 精准控制 AI 能看到什么、不能看到什么。