给团队建一个 Prompt 库，比教每个人写 Prompt 有用

摘要：个人 Prompt 写得再好，也只提升一个人的效率。GitHub 研究显示，有共享 Prompt 库的团队，AI 代码采纳率比每人自己写 Prompt 的团队高 35%。本文给出团队 Prompt 库的目录结构、文件格式标准、七个 Prompt 组件模板，以及 7 天落地计划。

经常有朋友问我：

"我们团队都用 AI 写代码，但每个人写出来的东西质量差距太大了。有人写的 Prompt 能直接跑，有人写的代码 Controller 里塞 SQL。我是不是该给团队搞个 Prompt 培训？"

我的回答是：培训当然有用，但效果最多持续两周。

两周之后，每个人又回到自己的习惯上去了。有人开始偷懒，有人忘了规范，有人自以为"这段代码 AI 写得还不错"实际上全是隐患。

对团队来说，一个人写得好 Prompt 是偶然事件，所有人写得好 Prompt 才是工程问题。工程问题的解法不是培训，是基建。

---

不是教怎么写，是建一个"团队 Prompt 库"

GitHub 内部做过一项 Copilot 采用率的研究（Kalliamvakou et al., 2024）。他们发现：有共享 Prompt 库的团队，AI 生成的代码被直接采纳的比例比每人自己写 Prompt 的团队高 35%。

35% 是什么概念？一个 6 人的团队，每人每天让 AI 写 5 个功能点——有共享库的团队一天多采纳 10 个正确的功能点，一个月多 200 个。这些本来都要靠人工去改、去补、去重写。

为什么共享库能提这么高？因为高质量的 Prompt 不再锁在某个人的聊天记录里。新同事入职第一天，打开 Prompt 库，复制一条模板，就能写出跟团队老手同等质量的代码。

个人 Prompt 技巧是木桶里最长的那块板，团队 Prompt 库是把木桶整体抬高。

---

Prompt 库的目录结构

不需要复杂平台。一个 Git 仓库里的 .team-prompts/ 目录就够了。

.team-prompts/
├── README.md              # 使用说明 + 贡献指南
├── templates/             # 可复用的 Prompt 模板
│   ├── crud-backend.md    # 后端 CRUD 接口生成
│   ├── mapper-join.md     # MyBatis 多表关联查询
│   ├── unit-test.md       # 单元测试生成
│   ├── debug.md           # Debug 问题定位
│   ├── refactor.md        # 老旧代码重构
│   └── code-review.md     # AI 辅助 Code Review
├── examples/              # 每个模板挂一个"好的输出长什么样"
│   ├── crud-example/
│   └── mapper-example/
└── rules/                 # 团队共享的编码规范（可替代六工具的碎片 rules）
    ├── style.md
    ├── security.md
    └── testing.md

关键设计原则有两层：

templates/ 放的是"怎么让 AI 写对"。
每条模板是你在 07-18 那篇里讲的六要素 Prompt，填好留空位——新同事只改三个字段就能用。比如 crud-backend.md：

你是一个资深 Java 后端工程师。
技术栈：Spring Boot [版本] + MyBatis-Plus [版本] + MySQL 8.0。
业务需求：为 [实体名] 生成完整 CRUD 接口。
- 表结构如下：[贴 DDL]
- 校验规则：[贴字段规则]
项目规范：[包结构 / 分层约束 / 统一返回体 / 异常处理]
输出要求：Entity、Mapper（接口+XML）、Service、ServiceImpl、Controller
禁止项：Controller 禁止写业务逻辑、禁止硬编码、禁止编造不存在的类

新同事把 [版本]、[实体名]、[DDL] 换成自己项目的，就能让 AI 生成符合团队规范的分层代码。

examples/ 放的是"什么算写对了"。
这是 Prompt 库里最被低估的部分。一个模板挂一个"好的输出长什么样"的示例，比写 500 字的说明文档更有用——因为人对"对的标准"来自视觉比对，不是文字理解。

rules/ 放的是团队编码底线。
你在 07-14 文章里写的 AI_RULES.md 作用域是单个项目——但这个 rules/ 目录是跨项目通用的基线（安全底线、代码风格、测试要求），新项目拷过去直接用。

---

一个 Prompt 文件里该放什么

光有目录结构不够，每个 Prompt 文件得有标准格式。我参考了 aior.com 和 pandev-metrics.com 两家的实践，整合成 7 个必填字段：

---
name: "Spring Boot CRUD 生成器"
description: 生成标准分层 CRUD 接口
version: 1.0.0
author: 张三
model: Claude-4 / GPT-4o
category: backend/crud
last_updated: 2026-07-15
---

## 适用场景
需要为新实体快速生成标准 REST CRUD 接口。

## 输入要求
- 实体名（中文+英文）
- 表 DDL
- 字段校验规则

## Prompt 模板
[六要素 Prompt]

## 输出示例
[贴一个"好的输出"：Controller/Service/Mapper 全齐、分层正确、校验到位]

## 已知坑点
- 多表关联不要用这个模板，请用 `mapper-join.md`
- Java 8 用户把 record 改成 class + final 字段

其中 输出示例 是最关键的字段。没有示例的 Prompt 库，三个月后一定变成没人维护的垃圾堆——因为新同事不知道"用了这个模板后的正确结果长什么样"，试一次效果不对就不再用了。

---

Prompt 的七个组件：大多数人只填了两个

来自 pandev-metrics.com 对多个开发团队的调研——一个高质量的代码生成 Prompt 有七个组件：

#	组件	作用	大多数人
1	Context	告诉 AI 在什么环境下工作	✅
2	Task	要干什么	✅
3	Role	设定 AI 的行为预期	部分
4	Constraints	不能干什么	❌
5	Output Format	按什么结构给答案	❌
6	Examples	锚定风格（few-shot）	❌
7	Refine	"如果不确定，先问别猜"	❌

前两项所有人都会写，中间三项是团队 Prompt 库的核心价值。特别是 Constraints——你的项目有特定的禁止项（"不用 HashMap 存数据""不直接 new 线程而是用线程池""不吞异常不记日志"），这些靠个人记忆力保证不了，靠 Prompt 模板里的禁止项字段保证。

约束和示例，是团队 Prompt 库跟个人私藏的本质区别。

---

什么共享、什么留给自己

不是所有 Prompt 都适合往库里塞。分成两组：

共享（进 Git，团队维护）：

内容	例子
代码风格约定	命名规则、注释语言、缩进风格
测试模式	用什么框架、断言风格、Mock 方式
架构约束	Controller 不写业务、Service 不拼 SQL
安全规则	输入校验、密钥管理、认证授权

个人保留（不共享）：

内容	原因
认知风格	有人要 AI 步步推理，有人要一次出结果——这是个人偏好，不是团队标准
调试专用上下文	"我在修公司 A 客户的工单同步问题"这种一次性场景
个人快捷别名	你自己习惯的简写，别人用不到

一个简单的判断标准：这个 Prompt 换个人用，能不能得到同等质量的输出？ 能 → 进共享库；不能 → 留给自己。

---

7 天落地计划

不需要成立"Prompt 标准化委员会"。sensecentral.com 给了一份 7 天落地计划，非常务实：

天	动作	产出
1	列出团队最常用的 3-5 个 AI 场景	一张场景清单
2	确定 Prompt 库放哪（Git 仓库 / Notion / 飞书知识库）	一个空目录
3	创建第一批 3-5 个 Prompt 模板	第一版 templates/
4	找 1-2 个同事实际跑一遍，反馈修改	修改后 v1.1
5	补上每个模板的"输出示例"	一条模板一个示例
6	全员 15 分钟 walkthrough	团队知道了这个库在哪、怎么用
7	确定月度 review 节奏（谁维护、怎么删过期模板）	一个 owner + 一个 review 提醒

关键：第一天不要建 20 个模板。 3-5 个最高频的，跑通了再扩。太多的初始模板会让人觉得"这东西靠不住"——因为第一批肯定有不合适的地方。先让最常用的三个场景稳了，团队自然就会加新的。

---

本篇 Prompt 库：让全团队 AI 产出质量对齐（基建）

规则管住底线，Prompt 提高上限，Prompt 库让上限不只属于一个人。

我建了一套开源的团队 Prompt 模板库，在 Gitee 上：https://gitee.com/tangyuewei/AI_PROMPTS 。目前包含后端 CRUD、MyBatis 多表查询、代码审查、安全扫描四套模板，每套都带了输出示例。你可以直接 Fork 到自己的团队仓库，按技术栈和业务场景修改后使用。

作者：唐悦玮 | 从后端出发，用 AI 拓展到全栈的工程师。