实战案例：反馈协议、评估闭环、代码审查与编程教育数据

版权声明与免责声明 本文基于 OpenAI、Anthropic、LangChain、GitHub、SWE-bench 等公开资料进行原创解读。原文版权归原作者与原出处所有。本文不构成官方翻译，也不代表上述机构观点。

原创性质 本文的案例框架、反馈协议、数据路由、评估闭环和落地路线为作者原创重构。外部资料只作为行业实践与技术依据，不作为逐段翻译对象。

---

开头：从案例里提取 Mentor 信号

读这组案例时，最重要的不是学会某个工具的用法，也不是收集一组可以直接复制的 prompt。真正值得关注的是：AI 在真实工程场景里怎样暴露能力边界，人类怎样给出可学习的反馈，团队又怎样把一次协作留下的判断沉淀为后续评估、训练和治理资产。

如果一个案例只告诉你“怎样把提示词写得更好”，它解决的是一次输出质量问题；如果一个案例能把 AI 的差输出拆解成错误类型、反馈协议、评估标准和训练候选样本，它才真正进入了 Coding Mentor 的主轴。

所以接下来的四个案例都不以工具为主语，而以人类 Mentor 的判断为主语。工具只是入口，prompt 只是消费协议的一种方式，代码审查评论也只是原始信号。真正要看的，是这些入口能否持续产生可验证、可路由、可复用的 Mentor 信号。

阅读每个案例时，可以固定追问五个问题：

追问	为什么重要
这个场景里 AI 最容易犯什么错	只有看见错误模式，才谈得上指导
人类 Mentor 应该给什么反馈	反馈必须从主观评价变成可学习信号
哪些证据可以证明改进有效	没有评估证据，案例只是经验分享
这些过程能沉淀成什么资产	长期价值来自能力建设，不是一次性提效
哪些数据不能进入训练或评估	数据治理决定闭环是否可靠

四个案例分别对应四种 Mentor 能力：

1. 模型选型评估：把“哪个 AI 好用”改造成“哪个 AI 适合我们的任务边界”。
2. 反馈协议设计：把“提示词优化”改造成“错误诊断、反馈结构和验收标准”。
3. 代码审查信号沉淀：把“AI 帮忙 review”改造成“团队工程规范的可训练样本”。
4. 编程教育数据闭环：把“AI 教学生”改造成“学习轨迹、误区标签和能力评估数据”。

如果你已经理解了前面的评估、题目设计和协作方法，这组案例就是进入工程实践的入口。先看清楚具体场景里的错误、反馈和证据，再进入组织级数据闭环；先沉淀高质量 Mentor 信号，再讨论哪些样本有资格进入 SFT 数据生成流程。顺序不能反。

案例一：模型选型不是选冠军，而是选任务适配度

很多团队第一次做 AI 编程助手选型，会自然地打开公开榜单：SWE-bench 排名、Aider leaderboard、模型厂商文档、社区讨论。这个动作没错，但它只能回答一个粗问题：某个模型在公开任务上大概处于什么能力段位。

团队真正要回答的是另一个问题：这个模型在我们的代码库、我们的任务类型、我们的安全边界、我们的 review 习惯里是否可靠。

公开榜单和团队私有评估之间的差别，可以这样理解：

评估口径	回答的问题	不能回答的问题
公开榜单	模型通用编码能力是否进入可用区间	是否适合团队代码库和业务约束
厂商文档	模型上下文、工具能力、价格和接口限制	真实 PR 中的返工成本
小样本试用	开发者主观体验是否顺手	稳定性、边界失败和长期质量
私有 eval	模型是否能完成团队真实任务	不能完全代表未来所有任务

所以模型选型的核心不是“选最强模型”，而是建立一套私有任务评估协议。这个协议应该从团队真实工作里抽样，而不是临时编几道算法题。

场景背景

假设一个 50 人工程团队准备引入 AI 编程助手，候选方案包括通用对话模型、IDE 内置助手、命令行 coding agent 和内部接入的私有模型。团队讨论一开始就分成几派：有人看重代码生成速度，有人看重上下文窗口，有人看重价格，有人担心安全，有人认为只要开发者喜欢就行。

这类讨论如果不收敛，很容易变成工具偏好之争。Coding Mentor 的做法是先定义任务边界，再让模型进入任务边界接受评估。

Mentor 视角下的选型问题

模型选型至少要拆成五类能力，而不是只看“代码写得好不好”。

能力维度	评估问题	任务样本来源
需求理解	能否识别真实目标、非目标和验收标准	历史需求、PR 描述、缺陷单
代码定位	能否找到正确文件和调用链	历史 bugfix、重构任务
修改最小性	是否避免无关改动和过度重构	review 退回记录
验证意识	是否主动补测试并运行正确命令	CI 失败记录、测试逃逸
约束遵守	是否尊重安全、性能、兼容和架构边界	架构决策、事故复盘

这里的关键是“任务样本来源”。如果样本来自真实历史任务，模型暴露出来的问题才接近真实交付。如果样本只是随手构造的演示题，评估结果很容易偏乐观。

SWE-bench 的启发正在这里。它把真实 GitHub issue 和代码仓库纳入评估，强调模型需要在真实工程上下文中修复问题。团队内部不一定要复刻 SWE-bench 的复杂环境，但应该学习它的核心精神：评估软件工程能力，必须把模型放进真实代码环境和真实验收条件里。

评估协议如何设计

一个可落地的选型评估，不需要一开始做得很大。建议先构建 30 到 60 个私有任务，分成四组：

任务组	数量建议	目标
缺陷修复	10 到 20	测模型定位根因和最小修复能力
测试补强	8 到 12	测模型理解边界条件和验证路径
小功能实现	8 到 15	测模型从需求到实现的完整性
代码审查	8 到 12	测模型识别风险、解释理由和给出修正建议

每个任务至少包含五个字段：任务描述、代码版本、允许访问的上下文、验收标准、参考评估 rubric。不要只放“标准答案”。标准答案对训练有用，对评估不够。评估要知道模型为什么过，为什么不过，错在哪里。

结果如何解读

选型报告不要只排一个总分。总分很容易掩盖风险。更有价值的是“能力剖面”。

模型表现	可能结论
修 bug 很强，但测试补强弱	适合开发辅助，不适合独立提交
生成速度快，但改动范围大	适合草稿，不适合主干代码直推
review 建议多，但误报多	可以做预审，不适合阻塞合并
上下文利用稳定，但价格高	适合高风险模块，不适合全量普及
小任务很强，大任务规划弱	适合局部实现，不适合跨模块重构

GitHub 与 Accenture 关于 Copilot 企业实践的研究提醒我们，企业场景不能只看开发者主观体验，还要结合遥测、质量和流程指标。模型选型也是一样。开发者觉得顺手很重要，但不能替代评估证据。

这个案例能沉淀什么

模型选型评估做完后，不要只留一份 PPT。它至少应该沉淀四类资产：

资产	后续用途
私有任务集	模型升级、工具替换、prompt 改版时回归
能力剖面	决定哪些任务允许 AI 深度参与
错误类型分布	指导后续反馈协议和训练样本收集
风险边界	决定高风险模块是否禁用或限制 AI

这就是 Coding Mentor 的选型方式：不是问“哪个模型最强”，而是问“在什么任务上，什么模型可以被信任到什么程度”。

案例二：把提示词优化改造成反馈协议设计

原来的案例二讲的是 API 文档生成，从一个简单提示词迭代到结构化 prompt、few-shot 示例、质量检查清单。这个写法的问题不在技巧本身，而在结论太浅：它把 60 分到 90 分的变化归因于提示词写得更细。

更准确的解释是：人类把隐性质量标准显性化了。

当团队说“AI 生成的 API 文档很差”，这句话对模型没有帮助。差在哪里？是结构不完整，参数遗漏，错误码不清楚，示例不可运行，还是术语和团队规范不一致？只有把“差”拆成可诊断、可反馈、可验收的协议，AI 才有改进路径。

场景背景

一个后端团队希望用 AI 辅助生成 API 文档。起初开发者把接口代码丢给 AI，让它“生成文档”。结果看起来还行，但拿到评审会上问题很多：参数表漏字段，错误响应不完整，示例代码不能运行，同一个概念在不同文档里叫法不一致，鉴权说明有时写有时不写。

如果这时只做 prompt 优化，团队很容易陷入一个循环：发现一个问题，就往 prompt 里补一条要求。几轮之后，prompt 变得很长，但质量依旧不稳。因为团队没有建立反馈协议，只是在堆约束。

60 分输出的问题到底是什么

第一步不是改 prompt，而是诊断输出失败类型。

失败类型	表面现象	Mentor 判断
结构缺失	文档段落顺序混乱	AI 不知道团队认可的文档结构
字段遗漏	参数说明不完整	AI 没有把代码字段和文档字段做一致性校验
错误路径缺失	只写成功响应	AI 默认只覆盖 happy path
示例不可运行	curl 或 SDK 示例缺参数	AI 没有执行可复制性检查
术语漂移	token、access token、credential 混用	AI 缺少团队术语表
安全边界不清	鉴权与权限说明含糊	AI 不知道哪些安全约束必须显式写出

这张表比一个“更好的 prompt”更重要。它把人类不满意的直觉拆成了错误分类。错误分类可以进入评估 rubric，也可以进入 review 标签，还可以变成后续 SFT 样本的 metadata。

反馈协议的四层结构

我建议把这个场景里的反馈协议拆成四层，而不是只写一个 prompt 模板。

层级	作用	产物
任务契约	明确输入、输出、非目标和验收标准	文档生成任务卡
质量 rubric	定义什么叫合格、优秀、不可接受	评分表和错误类型
示例样本	展示高质量输出和典型坏例	few-shot 示例库
验证机制	检查字段、示例、术语、安全说明	自动检查和人工抽检

OpenAI 和 Anthropic 的 prompt 工程文档都强调清晰指令、示例和约束的重要性。但在工程团队里，这些东西不应该只存在于一次 prompt 里。它们应该被抽成稳定资产：任务契约可以复用，rubric 可以评估，示例库可以更新，验证机制可以回归。

Prompt 在这里应该扮演什么角色

Prompt 不是核心资产，反馈协议才是核心资产。Prompt 只是把协议临时注入模型的一种方式。

同一套反馈协议可以被不同方式消费：

消费方式	使用场景
Prompt 模板	单次生成或 IDE 内助手
系统指令	内部文档 agent
RAG 上下文	根据接口类型检索规范和示例
eval rubric	自动或半自动评分
SFT 样本	训练模型形成稳定文档风格
review checklist	人类评审时保持一致

这就是为什么我不建议把案例二写成“最终提示词模板”。最终模板很快会过期。真正有长期价值的是模板背后的协议。

如何评估从 60 分到 90 分

很多团队会用“60 分、70 分、80 分、90 分”表达 AI 输出质量的变化，但如果分数没有来源，它只是一种主观感受。要让改进可复盘，分数必须变成可审计指标。

指标	60 分表现	90 分要求
结构完整性	章节缺失或顺序不稳定	固定章节齐全，顺序符合团队规范
字段覆盖率	只覆盖主要参数	参数、响应字段、错误码与代码一致
示例可运行性	示例缺参数或不可复制	至少一个成功示例和一个错误处理示例可运行
术语一致性	同义词混用	使用团队术语表
安全说明	偶发提及鉴权	鉴权、权限和敏感字段说明明确
人工修改量	reviewer 大量补写	reviewer 只做少量确认

这样一来，“90 分”不再是作者主观感觉，而是协议达成度。

这个案例能沉淀什么

这个案例最有价值的沉淀不是 prompt，而是六类资产：

资产	用途
API 文档任务契约	约束 AI 输出边界
错误类型表	作为评估和训练 metadata
高质量示例库	支持 few-shot、RAG、SFT
坏例和修正对	支持 Mentor 反馈样本
自动检查规则	检查字段覆盖、术语、安全说明
私有 eval 任务	回归不同模型和不同 prompt 版本

这个案例的结论应该改成：提示词优化只是表层动作，真正的工程动作是把人类文档评审标准变成反馈协议。只有这样，AI 才不是“这次被提示得更清楚”，而是逐步学会团队如何判断好文档。

案例三：代码审查助手不是守门员，而是信号采集器

代码审查是最适合做 Coding Mentor 的场景之一。原因很简单：review 本来就是人类工程判断最密集的地方。安全、性能、边界条件、抽象成本、测试策略、兼容性、发布风险，都会在 review 中出现。

问题是，大多数 review 评论只服务当前 PR。合并之后，它们很少被结构化保存，更不会回流到模型评估或训练中。AI code review 工具可以自动提出建议，GitHub Copilot 也提供 PR 级代码审查能力。但如果团队只是把它当作“多一个 reviewer”，价值仍然有限。

更好的定位是：代码审查助手负责扩大问题发现面，人类 Coding Mentor 负责校准信号，把高价值 review 变成团队工程规范、评估任务和训练候选数据。

场景背景

一个团队尝试让 AI 先审查每个 PR。最初结果并不好：AI 能发现一些明显问题，比如空指针、缺测试、变量命名，但也会产生大量低价值建议。开发者抱怨噪音太多，reviewer 觉得自己还要判断 AI 哪些话可信，反而更累。

这不是 AI review 没价值，而是团队没有把 review 任务拆清楚。

AI 审查应该覆盖什么，不应该覆盖什么

审查类型	适合 AI 预审	必须人类校准
语法、lint、简单 bug	适合	低
测试缺失、错误路径遗漏	适合	中
安全敏感模式	适合发现候选	高
性能风险	适合提示	高
架构边界	需要团队上下文	高
产品取舍	不适合作最终判断	极高

如果让 AI 对所有问题都给最终判断，它会越界。如果让 AI 只做候选发现，人类负责校准，它就能降低漏检概率，同时保留人类对组织约束的控制权。

Review 信号如何结构化

一次高价值 review 至少应该留下四层信号：

层级	例子
事实证据	哪个文件、哪段 diff、哪条测试或日志触发问题
问题类型	安全、性能、错误路径、契约破坏、测试不足
工程后果	如果不改，会导致什么风险
修正原则	以后遇到同类问题应该怎样处理

普通评论说：“这里可能有性能问题”。Mentor 化评论应该说：“这个循环在请求热路径内逐条查询库存状态，数据量增长后会把数据库延迟直接暴露给用户请求。这里应改成批量查询，并补一个超过 100 条订单的集成测试。”后者才能进入知识库、eval 或训练候选样本。

从 review 到数据资产

代码审查场景可以沉淀四类资产。

资产	来源	用途
Review rubric	团队规范和历史 review	统一 AI 与人类审查标准
错误模式库	高频 review 问题	指导 prompt、RAG 和培训
修正样本对	AI 或人类发现的问题及最终 patch	SFT 或偏好数据候选
私有 review eval	历史 PR 的问题定位任务	测试模型是否能发现团队关心的问题

这里要特别注意 eval 与训练隔离。一个历史 PR 可以被加工成 review eval，也可以被加工成训练样本，但不能同时以泄露答案的方式进入两边。否则模型看起来 review 能力提升，实际只是记住了历史答案。

噪音如何治理

AI review 最大的工程问题通常不是漏报，而是噪音。噪音会消耗 reviewer 信任，一旦开发者习惯忽略 AI 评论，真正有价值的提示也会被跳过。

可以用三种机制控制噪音：

机制	做法
严重度分层	只让高风险问题阻塞，其余作为建议
证据要求	没有文件、diff、测试或规范依据的评论降权
反馈回流	人类标记误报、有效、重复、风格偏好

LangSmith 的人工反馈和 annotation queue 思路在这里很有借鉴价值：不是把所有模型输出都当结论，而是让人类对轨迹和输出进行标注，再用这些标注改进数据集和评估。代码审查同理，AI 评论本身也要被 review。

这个案例能沉淀什么

代码审查案例的价值，不是让 AI 替代 reviewer，而是把 review 过程变成团队工程判断的数据源。

它最终应该沉淀：

1. 哪些问题 AI 可以稳定发现。
2. 哪些问题必须由人类判断。
3. 哪些 review 规则可以进入知识库。
4. 哪些修正样本适合进入 SFT 或偏好数据。
5. 哪些历史 PR 可以成为私有 review eval。

这才是“培养 AI 成为团队代码守门员”的准确含义。守门员不是自己决定一切，而是在明确规则和反馈闭环中持续校准。

案例四：编程教育不是让 AI 当老师，而是让学习过程可评估

编程教育场景最容易被写成“AI 可以个性化教学”。这个方向没错，但仍然偏工具。站在 Coding Mentor 系列里，更关键的问题是：学习者与 AI 的互动过程，能不能沉淀出能力评估、误区诊断和教学反馈数据。

教育场景有一个独特优势：学习过程天然包含“错误”。学生写错代码、误解概念、测试失败、被提示后修正，这些都是高价值轨迹。相比生产代码，教育数据的安全风险更低，教学信号更清晰，适合用来训练 AI 的反馈能力和引导能力。

场景背景

一个团队在内部训练新工程师，希望用 AI 辅助学习 Python、测试、代码审查和简单系统设计。最初他们让 AI 扮演助教，回答问题、讲概念、出练习。效果不错，但很快出现问题：AI 有时直接给答案，学生绕过思考；不同学生得到的提示深浅不一；导师无法判断学生到底掌握了什么；学习记录无法复用。

这个场景的核心不是“AI 会不会讲课”，而是“学习过程是否可评估”。

教学型 AI 的 Mentor 原则

教学场景里，AI 不应该默认给最终答案。它应该根据学习者状态选择反馈强度。

学习者状态	AI 应给的反馈	不应该做什么
完全卡住	提示问题分解和相关概念	直接贴完整答案
思路方向对但实现错	指出错误位置和最小修正方向	重写整个方案
通过测试但结构差	引导比较可读性、复杂度和边界	只说“可以优化”
反复犯同类错	回到概念层解释误区	继续给局部补丁
已掌握基础	增加约束和边界任务	继续重复简单题

这张表就是教育场景里的反馈协议。它让 AI 的教学行为从“回答问题”变成“根据能力状态调节反馈”。

学习轨迹如何变成评估数据

一次学习任务不应该只记录最终答案。至少要记录五类轨迹：

轨迹	价值
初始解法	反映学习者默认思路
测试失败	暴露概念误区或边界遗漏
AI 提示	记录反馈强度和提示内容
修正过程	判断学习者是否真正理解
最终解释	检查能否用自己的话说明方案

这些数据可以形成学习者能力画像，也可以形成 AI 教学评估数据。比如，同一个错误，AI 是直接给答案，还是引导学生定位？学生在提示后是否能独立修正？这比“最终代码是否通过”更能判断教学质量。

误区标签比题目数量更重要

教育平台很容易堆题。题目越多，看起来越完整。但真正决定教学效果的是误区标签。

误区标签	示例
边界条件遗漏	空数组、重复值、None、超大输入
状态更新错误	循环中修改集合、共享可变默认值
复杂度误判	用嵌套循环处理大规模输入
测试理解不足	只测 happy path，不测错误路径
抽象层次混乱	把 I/O、业务逻辑和格式化混在一起

误区标签可以连接三件事：学生能力评估、AI 教学策略、训练样本构建。没有误区标签，学习记录只是流水账；有了误区标签，学习记录才变成可分析的数据。

这个案例能沉淀什么

编程教育场景可以沉淀五类资产：

资产	用途
分层题目集	覆盖基础、边界、测试、重构和 review 能力
误区标签库	诊断学习者和 AI 的反馈质量
引导式反馈样本	训练 AI 不直接给答案，而是逐步引导
学习过程 eval	评估 AI 是否促进理解，而不是代写
教学复盘数据	优化题目、提示策略和导师介入点

这个案例和生产工程数据也能连接。新工程师在训练营里反复暴露的误区，往往也是 AI 在真实代码中会犯的错误：边界遗漏、错误路径不足、测试意识弱、抽象过度。教育数据如果结构化得好，可以反哺后续 Coding Mentor 体系。

从案例到工程资产：统一架构与实践路径

四个案例看起来不同：模型选型、反馈协议、代码审查、编程教育。但它们背后其实是同一套架构。

统一流程是：

1. 真实任务进入系统。
2. AI 给出计划、输出、审查或教学反馈。
3. 人类 Mentor 判断输出是否满足工程目标。
4. 反馈被结构化为错误类型、根因、修正策略和验证证据。
5. 数据被路由到 eval、知识库、SFT 候选、偏好数据或丢弃区。
6. 下一轮模型、prompt、工具链和团队流程根据评估结果调整。

这套架构和第 7 篇的数据闭环是衔接关系。第 6 篇通过四个案例说明闭环为什么必要，第 7 篇再把闭环抽象成组织级系统。

工程落地：从案例文章到团队实践

如果团队要把这四个案例落地，不要同时铺开。更稳的做法是按价值密度排序。

第一阶段：用模型选型建立私有 eval 种子集

先从 30 到 60 个真实任务开始，不要追求覆盖所有场景。目标是让团队第一次拥有自己的 AI 编程能力基线。

最小产物：

产物	要求
任务清单	来自真实 bug、测试逃逸、review 争议
评估 rubric	明确正确性、最小性、验证和约束
模型对比报告	不只排总分，还给能力剖面
风险边界	标注哪些任务允许 AI 深度参与

第二阶段：把一个高频场景改造成反馈协议

选择一个高频、低风险、标准明确的场景，比如 API 文档、单元测试生成、错误日志解释。不要一开始选架构设计或安全模块。

最小产物：

产物	要求
任务契约	明确输入、输出、验收标准
错误类型	控制在 6 到 10 类
高质量示例	只保留团队认可的样本
坏例修正	保存失败原因和修正理由
回归 eval	模型或 prompt 改动后能重复跑

第三阶段：让 code review 产生 Mentor 信号

不要让 AI review 一上来阻塞合并。先让它做预审，再让人类标注有效、误报、重复、风格偏好。等信号稳定后，再决定哪些规则可以自动阻塞。

最小产物：

产物	要求
Review 标签	安全、性能、错误路径、契约、测试等
有效性反馈	人类标注 AI 评论是否有效
高频问题库	每月统计重复出现的问题
修正规则	高价值评论沉淀为团队规范

第四阶段：用教育场景训练反馈能力

教育场景可以作为低风险训练场。先让 AI 学会“不给答案也能帮助人”，再把这种反馈能力迁移到工程场景。

最小产物：

产物	要求
误区标签	覆盖边界、复杂度、测试、抽象等常见错误
引导策略	区分提示、反问、局部纠错、概念回顾
学习轨迹	保存初始答案、提示、修正和最终解释
教学 eval	评估 AI 是否促进理解，而不是代写

四个案例共享的数据模型

如果这四个案例只是文章里的故事，它们不会产生长期价值。要进入团队实践，必须把它们压到同一个数据模型里。这个模型不需要一开始就复杂，但必须能回答四个问题：任务是什么，AI 做了什么，人类为什么改，最后这条记录应该去哪里。

我建议把每个案例都抽象成一条 Mentor Event。它不是完整训练样本，也不是完整评估任务，而是介于原始日志和数据资产之间的中间层。很多团队失败在这里：他们要么保存原始对话，要么直接整理训练集，中间缺少一个可审计、可筛选、可路由的事实层。

字段组	记录内容	对应案例
任务上下文	任务类型、业务目标、代码范围、风险等级、验收标准	四个案例都需要
AI 行为	生成、审查、解释、引导、规划、修改建议	模型选型、代码审查、教育场景
人类反馈	错误类型、修正理由、拒绝原因、可迁移原则	反馈协议、代码审查
验证证据	测试结果、评审结论、学习者修正、人工评分	模型选型、教育场景
数据路由	eval、知识库、SFT 候选、偏好数据、丢弃	四个案例都需要

这个模型的关键是保留“为什么”。只记录 AI 输出和最终结果，后面只能做粗糙统计；记录人类为什么认可或拒绝，才能形成训练和评估资产。比如 API 文档案例中，“参数说明不完整”只是问题，“AI 没有对照接口字段和响应字段做一致性校验”才是根因，“文档生成必须包含字段覆盖检查”才是可迁移原则。

Mentor Event 还有一个好处：它让四个案例的数据可以合流。模型选型中的失败任务，可能进入私有 eval；反馈协议中的坏例修正，可能进入 SFT 候选；代码审查中的有效评论，可能进入知识库；教育场景中的误区标签，可能变成下一轮练习题设计依据。没有统一模型，这些资产会散在不同系统里，最后仍然靠人脑记忆。

人类导师工作台：不要让反馈只留在聊天窗口

要让四个案例真正运行起来，团队需要一个很轻的导师工作台。它不一定是独立平台，可以先嵌入 PR、Issue、文档系统或内部表格。重点不是界面，而是让人类 Mentor 在最小成本下完成三件事：确认事实，补充判断，决定路由。

一个实用的导师工作台可以分成四个区域。

区域	作用	最小实现
事实区	展示任务、AI 输出、diff、测试、review 或学习轨迹	从现有系统自动拉取
判断区	让 Mentor 标注错误类型、根因、修正原则	预设标签加短文本
证据区	关联测试、截图、CI、人工评分或学习者修正	自动关联为主，人工补充为辅
路由区	决定样本进入 eval、知识库、训练候选或丢弃	单选加原因说明

这个工作台有两个设计原则。第一，不能让 Mentor 重复搬运事实。事实应该尽量从系统里来，人工只补判断。第二，不能强迫每条记录都精修。大多数记录只需要粗标，少数高价值记录才值得深入整理。

如果团队只有少数高级工程师能做 Mentor，更要保护他们的时间。初级开发者可以先标“这里被 AI 搞错了”，自动系统可以补充测试和 diff，最终由 Mentor 判断这条记录是否值得进入资产库。这样专家时间用在判断价值上，而不是做数据录入。

数据治理与评估边界

指标体系：案例是否有效，要看信号质量

四个案例落地后，不能只看“AI 是否更好用”。这个指标太粗。更准确的指标应该分成三层：交付层、反馈层、资产层。

层级	指标	说明
交付层	任务完成时间、PR 返工率、AI review 有效率、学习任务通过率	判断 AI 是否改善当前工作
反馈层	错误类型覆盖率、Mentor 标注一致性、反馈可复用率	判断人类反馈是否结构化
资产层	私有 eval 数量、SFT 候选样本数、知识库规则命中率、丢弃率	判断案例是否沉淀长期资产

其中最容易被忽略的是反馈层。很多团队能统计 AI 生成了多少代码、节省了多少时间，却不知道人类反馈是否可复用。如果反馈仍然是“这段不好”“再改一下”“不符合规范”，那就算 AI 参与率很高，也没有形成 Mentor 能力。

我会特别关注两个指标。

第一个是“同类错误复发率”。如果团队已经把 API 文档字段遗漏标成一种错误，并把检查规则加入协议，那么同类错误应该逐步下降。下降说明反馈被系统吸收了；不下降说明反馈只是被记录了。

第二个是“样本路由命中率”。如果 100 条 AI 协作记录里，95 条都不知道该去哪里，只能说明数据模型太粗或门控太弱。成熟一点的系统应该能把多数记录明确路由：一部分进入 eval，一部分进入知识库，一部分进入训练候选，一部分因为敏感或低价值被丢弃。

评审节奏：案例库必须持续修剪

案例库不是越大越好。模型选型任务会过期，反馈协议会随着团队标准变化而调整，代码审查规则会因为架构演进而失效，教育误区也会随着学习者水平变化而改变。一个没人修剪的案例库，最后会把旧约束伪装成新标准。

我建议建立月度和季度两种节奏。

节奏	处理内容	负责人
每月	统计高频错误、review 噪音、eval 失败、样本丢弃原因	团队 Mentor 与平台工程
每季度	下架过期任务、重估 rubric、检查 train/eval 隔离、更新知识库规则	架构负责人、QA、安全和 AI 工程

这不是流程洁癖。AI 系统最怕“陈旧但权威”的数据。人类看到旧规范可能会意识到它过时，模型不会。模型只会把上下文或训练样本当成当前事实。所以案例库必须有生命周期，尤其是那些带有强规则意味的样本。

什么时候不该把案例做成训练数据

这篇文章一直在讲沉淀数据，但不是所有高质量案例都应该进入训练。训练是最重的消费方式，很多情况下知识库、eval 或人工规范更合适。

场景	更合适的去向	原因
包含敏感业务逻辑	脱敏后进入知识库或只保留摘要	原始数据风险高
反映临时发布策略	复盘文档	训练后容易固化临时做法
争议主要来自个人风格	不进入训练，最多进入团队规范讨论	偏好不稳定
任务依赖特定历史版本	私有 eval 或归档	不一定适合泛化
错误是工具链缺陷导致	工具链 backlog	不应该让模型学习绕过工具缺陷

这个边界能防止团队把“数据资产意识”误用成“什么都要训练”。很多时候，最有效的改进不是微调模型，而是补一条 eval、改一个检查器、更新一段规范、修一个工具链缺陷。

数据治理：案例越真实，越需要边界

案例研究如果只停留在文章里，风险不大。一旦团队把案例转成数据资产，就必须处理治理问题。

风险	处理方式
客户数据进入 trace	采集前脱敏，敏感字段默认不保存
训练集污染 eval	train/eval/holdout 分区和版本管理
历史错误被固化	样本必须有生命周期和下架机制
个人偏好变成规则	偏好样本必须说明约束和理由
AI review 噪音伤害信任	严重度分层和人类有效性反馈
教育数据过度追踪	学习数据最小化采集，明确用途

这里不能靠口头约定。数据一旦进入训练或评估流程，就会反过来影响模型行为。错误的数据治理，会把团队历史债务训练成未来默认行为。

行动路径：用四个案例校准实践方向

读者应该带走什么：不要从模板开始

读完这四个案例后，最容易立刻行动的是“整理一个更好的 prompt 模板”。这个动作短期有效，但不应该成为第一步。模板只是把规则临时交给模型的一种方式，真正需要优先建设的是规则背后的判断系统。

在团队实践里，更稳的顺序是先定义任务契约，再拆错误类型，然后写 rubric，最后才决定这些规则通过 prompt、RAG、eval、review checklist 还是 SFT 样本被消费。这样做的好处是：即使模型换了，工具链换了，团队仍然保留了稳定的质量标准。

如果你正在处理一个“AI 输出不稳定”的场景，可以先问四个问题：

问题	产物
AI 到底错在哪里	错误类型表
人类为什么认为它错	反馈理由和可迁移原则
怎样证明它已经改对	验收标准和验证证据
这条记录后续应该去哪	eval、知识库、训练候选或丢弃

只有这些问题回答清楚，prompt 才有意义。否则 prompt 只是在堆要求，团队并没有更清楚地表达什么叫好、什么叫错、什么样的改进值得被保留。

用四个案例校准自己的实践方向

这四个案例也可以作为一组自检清单。判断一个 AI 编程实践是否真的接近 Coding Mentor，不看它用了多少工具，也不看它写了多少自动化脚本，而要看它是否把人类判断变成了可复用信号。

场景	如果你只是在做这些事	应该进一步追问
模型选型	比较模型榜单和主观体验	我们是否有自己的私有 eval 和任务适配度剖面
反馈协议	不断修改 prompt 文案	我们是否沉淀了错误类型、rubric 和验收协议
代码审查	让 AI 生成更多 review 评论	我们是否知道哪些评论有效、哪些是噪音、哪些能沉淀为团队规则
编程教育	让 AI 更快给出答案	我们是否记录了学习轨迹、误区标签和能力变化

这个自检的重点不是否定工具用法。模型榜单、prompt、AI reviewer、AI 助教都可以继续使用，但它们只能算入口。真正的分水岭在于：团队是否能从这些入口里持续提取任务、错误、反馈、验证和路由信息。

如果一个实践只能提升当次交付效率，却无法复盘 AI 为什么成功或失败，它仍然停留在“使用 AI”。如果一个实践能让下一次评估更准、下一次反馈更一致、下一批训练候选样本质量更高，它才开始接近“给 AI 当 Coding Mentor”。

下一步：从案例进入组织级闭环

四个案例提供的是入口，不是终点。模型选型让团队看到任务边界，反馈协议让质量标准显性化，代码审查让工程偏好可标注，编程教育让学习过程可评估。它们最终都会指向同一个问题：这些信号如何被组织稳定地采集、筛选、路由和复用。

这就是第 7 篇要继续展开的内容。单个案例可以靠少数资深工程师推动，但组织级闭环需要更明确的系统设计：谁负责采集，谁负责标注，哪些数据进入 eval，哪些进入知识库，哪些可以成为 SFT 候选，哪些因为敏感、过期或低价值必须丢弃。

到第 8 篇再讨论 SFT 数据生成，顺序才是合理的。训练数据不应该直接从聊天记录或 PR 评论里粗暴抽取，而应该来自已经经过任务契约、错误分类、人工反馈、验证证据和治理门控筛选过的工程资产。先有高质量反馈，再有高质量数据；先有私有 eval，再谈训练效果；先有治理边界，再谈自动化流水线。最后一篇第 9 篇再回到长期演进与未来判断。

结语：案例的价值不在故事，而在可复用的信号

这组案例的核心判断很简单：案例研究不是为了证明 AI 工具有用，而是为了证明人类怎样把 AI 协作过程变成可复用的指导系统。

模型选型案例告诉我们，不要问“哪个模型最好”，要问“哪个模型在我们的任务边界里可靠”。反馈协议案例告诉我们，不要把 prompt 当核心资产，要把人类质量标准结构化。代码审查案例告诉我们，不要让 AI 假装成最终守门员，要让它成为 review 信号采集器。编程教育案例告诉我们，不要只让 AI 给答案，要让学习过程变成能力评估数据。

如果团队只能从本文带走一个行动，我建议从案例二开始：找一个高频低风险场景，把“AI 输出不好”拆成 6 到 10 个错误类型，写出合格标准，收集 20 个好样本和 20 个坏例修正，再做一个小型 eval。这个动作比继续改 prompt 更有价值。

验收口径也要简单：一个月后，同类错误是否减少，人工反馈是否更一致，高价值样本是否能被明确路由。如果这三件事没有变化，说明团队只是写了新模板，还没有建立真正的 Mentor 机制。

因为真正的 Coding Mentor 不是把 AI 提示得更听话，而是把人类工程判断变成 AI 能学习、团队能复盘、系统能评估的信号。

参考与致谢

• OpenAI: Prompt engineering
• Anthropic: Prompt engineering overview
• OpenAI: OpenAI Evals API
• OpenAI: How evals drive business results
• LangChain: Evaluating AI apps with LangSmith
• LangChain: Human feedback and annotation queues
• GitHub Docs: About code review in GitHub Copilot
• GitHub Blog: Research: quantifying GitHub Copilot’s impact in the enterprise with Accenture
• Jimenez et al.: SWE-bench: Can Language Models Resolve Real-World GitHub Issues?