欢迎来到卷 6 的最后一篇，这也是本教程除“安全卷”和“实战卷”之外，最重磅的收官之作。
当你一个人玩 AI 时，你可以随意修改 Prompt，随意调试接口。但如果现在你们部门有 20 个人，老板说：“我们要全面拥抱 AI 编程和 Agent 化！”
这 20 个人如果各写各的 Prompt，各接各的大模型，不用一个月，系统就会变成一座无法维护的“屎山”。
AI 从“个人玩具”升级为“团队武器”，最大的鸿沟在于协作规范。
本篇我们将探讨：在 AI 时代，团队的角色该怎么分配？Prompt 怎么做代码审查（Code Review）？那些写得好的“神级提示词”该如何作为资产沉淀下来？
1. 角色分工：真的需要“提示词工程师”吗？
前两年行业里炒作一个新岗位叫“提示词工程师（Prompt Engineer）”，号称年薪百万。但在真实的工业界落地中，这其实是个伪命题。
写 Prompt 并不是一种独立的职业，而是一种基本素养。就像“会用 Google 搜索”一样，所有人都得会。
在一个成熟的 AI 团队里，真正的角色分工是这样的：
- 不写代码，只负责一件事：提供金标（Gold Standard）。
- 他们是唯一知道“退款政策到底该怎么解释最合规”的人。他们负责提供正确的问答样例，作为评测系统好坏的绝对标准。
- 负责搭架子。搭建 RAG 的向量库、搞定多路召回、接通大模型 API、配置好限流和监控系统（我们卷 3 到卷 6 讲的全是他们的活儿）。
- 在架构师搭好的架子上，编写具体的 Prompt、实现具体的 Tool 工具逻辑，并组装成业务所需的 Agent。
结论：懂业务的人写金标，懂底层的人搭管道，懂逻辑的人写 Prompt 和工具。
2. 针对 AI 的代码审查（Code Review for AI）
在传统的开发团队里，你提交了一段 Java 代码，资深同事会进行 Code Review，看看有没有内存泄漏。
在 AI 时代，你提交了一段 Prompt 或者一个 JSON Schema，同样必须经过极其严苛的 Review！
审查一个 Prompt，到底在审什么？
- 是否足够收敛？ 有没有规定好“拒答条件”和“停止条件”？（防止发散和幻觉）
- 上下文是否过载？ 废话多不多？能不能精简掉 30% 以节省 Token 成本？
- 输出格式是否鲁棒？ 是否强制要求输出了带包裹的 JSON 或 Markdown，方便下游代码解析？
- 有没有过回归测试？ 最重要的一点！你改了这一版 Prompt，跑过那 50 个金标错题本了吗？分数是升了还是降了？如果没分数报告，直接打回！
3. 知识沉淀：把个人手艺变成团队基建
张三花了一周时间，写出了一个极度好用的“自动排查 MySQL 慢查询”的 Agent Skill（技能）。如果他不分享，他离职后这个能力就消失了。
这就是为什么我们在卷 3 的第 28 篇里反复强调 “技能注册表（Skill Registry）”。
- Prompt 模板库：团队应该有一个共享的 Git 仓库，里面分门别类存着各个场景验证过最好用的 Prompt 模板（如 翻译类模板.md、数据抽取类.json）。
- 工具/组件超市：李四写了一个 query_erp_system 的好用工具，必须提交到内部的组件超市。王五在写新 Agent 时，直接从超市里把这个工具拖过来用，绝不重复造轮子。
- 失败复盘库：我们上一篇讲的《线上事故复盘报告》，必须全员可查。别人踩过的“没写重试导致系统崩溃”的坑，新员工入职第一天就该去学习。
4. 本篇产出：团队 AI 开发规范（最小可行版）
如果你们团队明天就要开始 AI 项目开发，请把下面这份规范贴在开发群的置顶公告里。这是防止团队开发走向失控的“定海神针”：
# 团队 AI 研发协作规范 v1.0
## 一、 资产管理与版本控制
1. **Prompt 即代码 (Prompt-as-Code)**：所有生产环境的 Prompt 严禁在后台或数据库直接手写。必须以 `.txt` 或 `.md` 文件形式提交至 Git 仓库，统一接受版本控制。
2. **工具共享优先**：在开发新的 Agent 工具（Tools/Skills）前，必须先在内部组件库检索是否已有现成工具。如需新开，需确保单一职责，方便他人复用。
## 二、 Code Review (针对 AI)
提交包含 Prompt 或工具调用的 PR（Merge Request）时，Reviewer 必须核对以下三项：
– [ ] 该 Prompt 是否明确定义了【拒答边界】与【系统底线】？
– [ ] 该工具调用是否实现了【幂等性】，能否安全地被重试多次？
– [ ] 提交 PR 时，是否附带了本次修改后的【自动化评测打分报告】？（得分下降的 PR 严禁合并）
## 三、 评测与发布
1. **测试驱动 (Eval-Driven)**：任何新 AI 功能开发的第一步，必须是联合业务专家产出至少 20 条【金标数据集】。
2. **必须灰度**：核心业务 Agent 上线新版 Prompt 时，严禁 100% 全量发布。必须遵循 `5% -> 20% -> 100%` 的灰度观察原则。
## 四、 事故与复盘
1. **紧急止血**：赋予任何工程师在一线发现 AI 发疯时，直接操作配置中心【切断高危工具开关】或【降级模型】的权力。
2. **闭环管理**：所有线上发生的 AI 幻觉/越权事故，必须在 48 小时内转化为自动化测试的边界用例（Edge Cases），补充进全量回归测试集。
卷 6 结语与复盘
到这里，整个 卷 6：评测、可观测、成本与上线 就全部结束了。
在这极其硬核的 7 篇文章里，我们完成了 AI 工程化最艰难的闭环：
下一步去哪儿？
理论部分和工程基建部分，到这里已经接近大成了。
但在把 AI 放出去和真实世界（特别是黑客）接触之前，我们还剩最后一道护城河没建——这也是无数大公司翻车的重灾区。
接下来的 卷 7：安全与合规，我们将带你换上黑客的视角，看看他们是如何用几句话就能把你的 Agent 骗得团团转的，以及你该如何进行防御！
