从交付到训练：如何把AI编程协作变成Coding Mentor数据闭环

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

原创性质 本文的闭环架构、数据路由模型、Mentor 信号定义、质量门控和落地路线为作者原创重构。外部资料只作为论证来源和行业案例，不作为逐段翻译对象。

---

开头：真正丢掉的不是代码，而是过程

一个团队让 AI 参与了半年的日常开发：需求拆解让 AI 先写草案，功能实现让 AI 起第一版，测试失败让 AI 分析日志，Code Review 前让 AI 先扫一遍 PR。半年后，仓库里留下了更多代码，PR 里留下了更多提交，CI 系统里留下了更多构建记录。问题是：这些东西能不能反过来训练一个更懂这个团队的 AI？

大多数情况下，不能。

原因不在于 AI 生成的代码没有价值，而在于团队只保存了交付结果，没有保存交付过程。一次失败的实现为什么失败，AI 漏掉了哪个业务约束，人类 reviewer 为什么否掉一个看似能跑的 patch，测试失败后是哪条日志真正指向根因，这些信息通常散落在聊天窗口、终端历史、PR 评论和个人脑子里。交付完成后，它们就像临时调试分支一样被清掉。

我更愿意把这件事说得直接一点：如果一次 AI 辅助开发只留下最终代码，那它只是一次交付；如果同时留下需求、上下文、计划、工具调用、失败日志、人工修正和验收证据，它才有机会变成一次可复用的 Coding Mentor 训练样本。

前面几篇文章讨论了如何评估 AI、如何设计题目、如何组织协作和复盘案例。第 7 篇不能继续写成“如何使用 AI 编程助手”，也不应该停留在“搭一个评估平台”。这一篇要回答的是更靠近工程系统的问题：怎样把 AI 参与产品工程化交付的全过程，设计成一个能持续沉淀高质量训练数据和评估数据的闭环。

这个闭环里有四件事同时发生：

1. AI 参与真实产品交付，不是在沙盒里做玩具题。
2. 人类 Coding Mentor 在关键节点给出结构化反馈，而不是只说“这段不行”。
3. 交付轨迹被路由为 eval、SFT、偏好数据、知识库或丢弃样本，而不是全部混在日志里。
4. 模型、提示词、工具链和团队流程根据评估结果持续调整，而不是靠个人手感升级。

本文的核心判断是：会用 AI 写代码不是壁垒；能把 AI 参与交付的全过程转化为训练资产、评估资产和组织记忆，才是团队给 AI 当 Coding Mentor 的真正壁垒。

问题边界与价值判断

先把方向校准：本文不是第 8 篇的提前版

这个系列已经有一篇专门讲 SFT 数据生成。那篇会进入更细的工程实现：数据结构、清洗、质量评分、导出格式、训练流程。本文不重复那些细节。

第 7 篇的职责更靠前：先设计“数据从哪里来、为什么可信、怎么分流、谁负责判断、哪些不能进训练集、评估如何反过来影响交付”。如果把第 8 篇看成数据加工厂，本文讨论的是原料产线、质检规则和闭环经营方式。

我建议用下面这个边界区分两篇文章：

文章	关注对象	核心问题	不展开的内容
第 7 篇	AI 工程化交付中的数据闭环	每一次 AI 协作怎样变成可训练、可评估、可复用的 Mentor 信号	具体训练脚本、导出格式、模型微调参数
第 8 篇	SFT 数据生成流水线	如何把已筛选的工程资产加工成训练样本并接入训练流程	组织闭环、数据所有权、线上交付指标体系

这个边界很重要。很多团队一谈“训练数据”，马上跳到 JSONL、SFTTrainer、LoRA、评测脚本。那是后半段的问题。前半段如果没设计好，后半段只会把脏数据加工得更漂亮。

AI 编程助手的价值，不等于 Coding Mentor 的价值

GitHub 早期关于 Copilot 的研究重点放在开发者速度和体验上：AI 可以帮助开发者更快完成任务，提升主观满意度。后来 GitHub 与 Accenture 的企业研究进一步把视角放到企业实践中，结合遥测、代码质量、开发者反馈等维度衡量 AI 编程工具的影响。这类研究很有价值，它们证明 AI 参与软件交付不是噱头，而是会真实改变开发过程。

但这里有一个容易被忽略的分岔：交付效率提升，和团队具备 Coding Mentor 能力，是两件不同的事。

使用 AI 编程助手时，团队关心的是“AI 能不能帮我更快把任务做完”。给 AI 当 Coding Mentor 时，团队关心的是“这次协作暴露了 AI 的什么能力边界，我能不能把这个边界转化为可训练、可评估、可复用的反馈信号”。前者是消费模型能力，后者是建设模型能力。

这两个目标并不冲突，但工程设计完全不同。

目标	主要动作	典型产物	风险
使用 AI 提升交付效率	让 AI 写代码、解释错误、生成测试、辅助 review	PR、commit、测试结果、交付报告	只留下结果，不留下过程
给 AI 当 Coding Mentor	记录 AI 的输入、决策、失败、修正、验证和人类判断	结构化轨迹、错误标签、评估任务、训练候选样本	把所有日志误当训练数据

前者的衡量指标可以是交付周期、任务完成速度、开发者满意度、PR 返工率。后者的衡量指标要更难一些：AI 是否减少了重复犯错，是否更会使用团队规范，是否能在相似上下文下做出更稳的取舍，是否能通过私有 eval 集，是否能把人类 reviewer 反复指出的问题内化为后续行为。

一个成熟团队不应该把这两条线拆开。正确的方向是：用 AI 辅助交付创造真实任务场景，用真实任务场景生产可审计轨迹，用人类导师信号筛选数据，再用训练和评估反过来提升下一轮交付质量。

闭环总览：从一次 PR 到一个训练飞轮

如果把 AI 辅助开发看成一次普通工具调用，流程通常很短：开发者提出问题，AI 给出代码，人类复制修改，测试通过，提交 PR。这个流程能提高速度，但它没有产生可复用的组织资产。

要把它改造成 Coding Mentor 数据闭环，流程必须多出三层：观测层、判断层和路由层。

第一层是观测层。团队要捕获的不是“AI 最终说了什么”，而是 AI 在工程环境中怎样行动：它看了哪些文件，依赖了哪些上下文，提出了什么计划，执行了什么命令，失败后如何修正，最终 diff 和测试结果是什么。

第二层是判断层。人类 Coding Mentor 不只是验收代码，而是把判断写成可学习的信号：这个错误属于需求误解、上下文遗漏、接口契约破坏、测试设计不足，还是工程取舍错误？正确修复为什么是现在这个方向？这个经验能不能迁移到其他任务？

第三层是路由层。不是所有轨迹都能进训练集。一次交付轨迹可能更适合进入私有 eval，也可能只适合进入团队知识库，也可能因为包含敏感信息必须丢弃。路由决定了数据资产的命运。

这套闭环可以用一句话概括：

交付过程负责产生真实任务，Mentor 反馈负责制造高质量监督信号，数据路由负责决定用途，评估结果负责驱动下一轮交付策略调整。

Anthropic 在 agent 系统实践中反复强调，不要一开始就把系统做成复杂自治体，而应该从简单可控的 workflow 开始，逐步增加工具、记忆和自主性。这个建议放在本文也成立。团队不需要第一天就建一个全自动训练平台，真正的第一步是让 AI 参与交付的过程可观察、可回放、可标注。

LangChain 关于 agent improvement loop 的讨论给了一个很好的工程视角：trace 不是调试副产品，而是 agent 改进循环的入口。没有 trace，失败就只能靠印象复盘；有 trace，团队才能聚类失败、构造数据集、运行 eval，再推动系统改进。

数据采集与 Mentor 信号

交付过程里的数据采集点：不要只盯 prompt 和答案

很多人说“保存 AI 对话，后面可以拿去训练”。这句话只说对了一小半。对话当然重要，但在软件工程场景里，最有价值的信号往往不在聊天文本里，而在上下文、工具反馈和人类修正中。

一次真实的 AI 辅助交付，至少应该看成八个阶段。

阶段	应采集的数据	Mentor 需要判断什么	可能沉淀的资产
需求进入	原始需求、业务目标、验收标准、非目标、风险约束	AI 是否理解真实边界，而不是只理解字面功能	私有 eval 题干、需求理解案例
任务计划	AI 的拆解、假设、依赖、修改范围、验证方案	计划是否漏掉迁移、兼容性、错误路径、回滚策略	规划能力样本、计划评估标准
上下文检索	AI 读取的文件、引用的文档、搜索路径、遗漏文件	模型是否拿到了必要上下文，是否引用了过时信息	RAG 索引优化、上下文选择样本
代码生成	初始 diff、替代方案、接口变更、测试补充	代码是否符合架构、命名、错误处理和安全要求	SFT 候选样本、坏例样本
工具执行	shell 命令、测试日志、lint、类型检查、构建失败	AI 是否能根据环境反馈定位问题，而不是盲修	工具使用轨迹、失败修复案例
人工评审	reviewer 评论、拒绝理由、设计争议、修改建议	哪些问题必须由人类校准，哪些可自动化	偏好数据、review 规则
修复迭代	failed attempts、corrected patch、最终 patch	正确修复路径是什么，错误尝试为什么错	DPO/RFT 候选数据、错误模式库
验收复盘	CI、回归测试、上线结果、缺陷逃逸、返工记录	样本是否真的代表“成功”，还是只是当时没炸	holdout eval、样本降权依据

这里有一个实践判断：如果团队只能保存三类数据，我会优先保存“需求与验收标准”“失败轨迹与工具反馈”“人类修正理由”。最终代码仓库本来就会保存，真正容易丢的是这些中间信号。

不要把这件事做成一个重型填表流程。填表会被开发者绕开。更好的做法是把数据采集嵌入已有工程动作：PR 模板、CI 注释、review bot、agent trace、issue 状态流转、测试报告归档。让开发者多写一句关键判断，而不是多填二十个字段。

Mentor 信号：把“我觉得不行”变成模型能学习的结构

AI 不会从一句“这里写得不好”里学到太多。人类 reviewer 自己也经常说不清楚某个判断的依据。Coding Mentor 的第一项能力，就是把隐性的工程判断拆成显性的反馈信号。

我建议把 Mentor 信号拆成六类。

信号类型	要回答的问题	典型标注
任务理解信号	AI 是否理解了真正要解决的问题	需求误读、非目标扩大、验收标准遗漏
上下文选择信号	AI 是否找到了必要上下文	忽略接口契约、引用旧实现、未读取调用方
实现质量信号	代码是否符合团队工程标准	错误处理缺失、边界条件遗漏、抽象过度
验证行为信号	AI 是否知道如何证明自己是对的	未补测试、只跑快乐路径、忽略类型检查
修复策略信号	AI 面对失败时怎样调整	盲改、局部修补、根因定位、回滚重做
组织约束信号	AI 是否遵守团队不可见规则	安全红线、性能预算、兼容策略、发布节奏

这些信号不能太泛。比如“代码质量差”不是一个好标签，因为它无法指导训练和评估。更好的写法是：“错误路径没有保留原始异常，导致上层重试策略无法区分临时失败和永久失败”。这句话比“错误处理不好”长一点，但它包含了因果链。

我在看 AI 生成代码时，最警惕的是“能跑但没有交代代价”的实现。它通过了测试，却隐含破坏了团队的长期约束：把同步调用塞进热路径，把临时兜底写成默认逻辑，把一次性迁移写成永久分支。这类问题最适合进入 Mentor 信号库，因为普通 benchmark 很难覆盖，但真实工程里会反复发生。

Mentor 信号的质量决定了后续数据的上限。没有结构化信号，训练数据只是“人类改过的代码”；有结构化信号，训练数据才变成“人类为什么这样改”的可学习证据。

数据契约：一条交付轨迹至少要能回答十个问题

团队不需要一开始就定义庞大的 schema，但必须有一个最小数据契约。这个契约的目标不是服务数据库设计，而是保证未来回看样本时还能判断它是否可信。

问题	为什么必须回答
这次任务的真实目标是什么	没有目标，就无法判断 AI 输出是否解决了正确问题
验收标准是什么	没有验收标准，测试通过也可能只是幻觉
AI 使用了哪些上下文	能区分模型能力不足和上下文供给不足
AI 提出了什么计划	计划暴露模型的工程判断，而不只是代码能力
初始输出失败在哪里	失败点是最有价值的训练信号之一
人类修改了什么	diff 说明事实变化，但不说明为什么
人类为什么这样改	这是 Coding Mentor 信号的核心
自动化验证结果如何	防止把主观满意误当成功
后续是否返工或回滚	防止把短期通过误当长期正确
这条轨迹应该进入哪里	决定它是 eval、SFT、偏好数据、知识库还是丢弃样本

这个契约背后有一个原则：训练数据必须包含“因果信息”，不能只有“结果信息”。只有结果信息会鼓励模型模仿表面答案；因果信息才有机会让模型学习工程判断。

SWE-agent 的研究价值不只在于它能让模型解决 SWE-bench 任务，更在于它把软件工程 agent 的行动过程放进了“agent-computer interface”里：模型不是一次性输出答案，而是在环境中读文件、编辑、运行测试、观察反馈。对团队内部数据闭环来说，这个视角比单轮 prompt-answer 更接近真实工程。

数据路由：不是所有东西都应该进入训练集

我反对“把所有 AI 协作日志都收集起来，以后训练用”这种说法。它听起来有数据资产意识，实际会制造三个问题：敏感信息泄露、低质量样本污染、eval 和 train 混淆。

更合理的做法是建立数据路由。每条交付轨迹经过质量门控后，只能进入一个或少数几个去向。

去向	适合进入的数据	不适合进入的数据	主要使用者
私有 eval set	真实任务、可复现、验收明确、测试稳定、答案未泄露	flakey 测试、需求含糊、已用于训练的样本	模型评估、工具链回归
SFT 候选集	人工修正质量高、解释清楚、可迁移、验证充分	未审核 AI 输出、偶然通过、只适用于一次性业务细节	模型微调、行为示范
偏好数据	多个方案可比较、review 选择理由明确、优劣边界清楚	没有明确偏好依据、只是个人风格差异	DPO/RFT、策略选择训练
团队知识库	架构约束、常见错误、review 规则、复盘结论	密钥、客户数据、临时 workaround	RAG、提示词上下文、工程规范
丢弃区	敏感、污染、不可复现、低价值、无验证	不应回流训练或评估	数据治理、审计

这里最容易犯的错，是把“人类改过”当成“可以训练”。人类改过只说明原始输出有问题，不说明最终样本适合学习。一个 patch 可能是临时救火，可能绕过了根因，可能牺牲了长期可维护性，也可能包含不能外泄的业务逻辑。没有路由门控，训练数据集会把这些历史包袱一起吞进去。

OpenAI 后来不再继续用 SWE-bench Verified 作为前沿模型的主要公开评估口径，背后有一个现实原因：公开 benchmark 会被社区反复优化、会出现污染和过拟合，也会暴露测试本身的局限。团队内部 eval set 也一样。如果训练集、调参集和评估集混在一起，指标上涨只代表系统更会“背题”，不代表它更会交付。

质量门控：数据飞轮的刹车比油门更重要

数据飞轮这个词很容易让人兴奋，仿佛只要采集足够多的轨迹，模型自然会越来越强。工程上恰好相反。真正决定飞轮能不能转起来的，不是采集速度，而是门控质量。

我建议把门控分成七道。

Gate	要拦住什么	不拦的后果
隐私与安全	密钥、令牌、客户数据、内部地址、生产日志敏感字段	数据资产变成安全事故源
IP 与许可	不能用于训练的第三方代码、受限协议内容	后续模型使用范围受限
数据污染	公开 benchmark 答案、已进入训练集的 eval 样本	评估指标失真
可复现性	无法复现的问题、缺失环境、测试不可运行	模型学到无法验证的经验
验证充分性	没有测试、没有 review、没有验收证据	把“看起来对”误当“工程上对”
教学价值	只含一次性业务细节、没有可迁移判断	增加噪声，不提升模型能力
生命周期	已过期架构、临时 workaround、被废弃 API	把历史债务训练成默认行为

这七道门控里，我最看重“生命周期”。训练数据不是档案馆。过期经验如果不下架，模型会坚持团队已经放弃的旧约束。比如团队从 REST 切到事件驱动架构后，旧样本里“同步查询下游服务”的模式就应该降权或剔除。模型没有组织记忆的时间感，数据治理必须替它提供。

门控不应该完全依赖人工。人工负责判定边界和抽检，自动化负责做重复检查：敏感字段扫描、license 标记、测试稳定性统计、样本去重、train/eval split 检查、过期 API 检测。人工导师最稀缺的时间应该用来判断“这个样本有没有教学价值”，而不是手工找 token。

评估闭环：私有 eval 是团队的工程体检表

如果说训练数据决定模型学什么，eval 决定团队相信什么。

公开 benchmark 仍然重要。SWE-bench 把真实 GitHub issue 引入软件工程评估，比传统算法题更接近工程现实。SWE-Gym 进一步尝试把真实 issue、环境和轨迹转成可训练任务。这些工作说明一个方向：coding agent 的评估正在从静态题目走向真实仓库、真实环境、真实反馈。

但团队不能只看公开 benchmark。公开 benchmark 衡量的是通用能力，团队私有 eval 衡量的是“这个 AI 在我们的工程系统里是否可靠”。两者关系类似体检报告和岗位试用：前者能发现基础问题，后者才能判断是否适合具体岗位。

团队私有 eval 至少应该覆盖四类任务。

任务类型	评估能力	样本来源
回归修复任务	能否在真实代码库中定位根因并修复	历史 bug、线上缺陷、CI 失败
架构约束任务	能否遵守团队边界、契约、性能预算	review 争议、架构决策记录
测试补强任务	能否补足关键路径、边界条件、错误路径	测试逃逸、缺陷复盘
重构取舍任务	能否在行为不变前提下改善结构	历史重构、技术债治理

OpenAI 关于 eval 的实践强调，评估要服务真实业务结果，而不是只制造一个漂亮分数。放到 AI 编程场景里，私有 eval 不应该只看 pass rate，还应该看修复路径是否合理、上下文引用是否正确、是否破坏架构约束、是否能给出验证证据。

我建议把评估指标分三层。

层级	看什么	指标例子
离线能力	模型或 agent 在固定任务集上的表现	pass rate、修复成功率、失败类型分布
协作过程	AI 在真实 PR/issue 中的交付质量	人工修正次数、review 缺陷密度、CI 失败率
业务结果	AI 对工程交付系统的长期影响	lead time、rollback、缺陷逃逸率、维护成本

这三层不能互相替代。离线 eval 可以快速回归，但容易和真实工作脱节；过程指标接近团队日常，但受任务难度波动影响；业务结果最真实，但反馈慢。成熟的闭环要三者一起看。

人类 Coding Mentor 的新职责：从 reviewer 变成信号校准器

在传统软件工程里，reviewer 的主要职责是防止坏代码进入主干。在 AI 数据闭环里，reviewer 仍然要守门，但还多了一项职责：把自己的判断转化为可被系统吸收的信号。

这件事会改变 review 的写法。

普通 review 评论	Mentor 化评论
这里需要补测试	这里缺少错误路径测试；当前实现只覆盖成功返回，无法证明超时和下游 500 时的重试策略正确
这个抽象没必要	这个抽象只被一个调用点使用，却引入了新的生命周期和配置分支，维护成本高于复用收益
不要这样查数据库	这条查询在列表页热路径上执行，缺少分页和索引约束，数据量增长后会把延迟风险转移到用户请求链路
这里不符合规范	这个接口绕过了现有权限中间件，破坏了团队“鉴权集中在网关层”的架构约束

Mentor 化评论不是为了写得更长，而是为了补上三类信息：问题类型、因果关系、可迁移原则。这样评论本身才能成为训练样本、eval 标准或知识库条目。

团队可以把 Mentor 反馈分成几个固定字段，但不要把流程做僵。

字段	示例
问题类型	上下文遗漏、边界条件、架构约束、安全风险、验证不足
触发证据	哪个文件、哪条测试、哪段日志、哪个 PR 评论
根因判断	AI 没读调用方，导致误以为接口只服务单场景
修正策略	先补 contract test，再改实现，最后补迁移说明
可迁移经验	修改 shared contract 前必须检查所有消费者
数据路由建议	进入 eval set，不进入 SFT，因为包含客户字段，需要脱敏后再评估

这里的关键不是“人类比 AI 高级”，而是人类掌握了模型外的组织约束。很多工程判断并不存在于公开代码里：团队为什么不升级某个依赖，为什么保留一个旧接口，为什么这个模块不能引入某个包，为什么一个看似低效的实现其实是为了兼容历史客户。Coding Mentor 的价值就在于把这些隐性约束显性化。

工程实践：从 PR 到评估闭环

工程实践一：从 PR 模板开始，不要从训练平台开始

很多团队一谈闭环，就想建平台。我的建议相反：第一步从 PR 模板和 review 规范开始。

原因很简单。PR 是真实工程交付的最小审计单元。需求、代码、测试、review、CI、合并结果都能在这里汇合。把 PR 变成数据闭环入口，比单独建一个“AI 数据采集系统”更容易落地。

一个面向 Coding Mentor 数据闭环的 PR 模板，可以只增加五个字段。

字段	目的
AI 参与范围	区分 AI 写了代码、生成测试、解释日志、辅助 review，还是只做文档
关键上下文	记录 AI 使用了哪些文件、文档、issue、架构约束
失败与修正	保存至少一个有价值的失败尝试和人类修正理由
验证证据	关联测试、lint、截图、性能数据、安全扫描
数据路由建议	标记是否可进入 eval、SFT、偏好数据、知识库或必须丢弃

这五个字段不需要每次都写满。低风险改动可以简写，高风险改动必须完整。重点是让团队养成一个习惯：AI 不是黑盒工具，它参与交付的过程应该能被审计。

CI 也应该配合这套模板。比如，当 PR 标记了“AI 生成核心实现”时，CI 可以要求更完整的测试证据；当 PR 修改 shared contract 时，系统可以提醒 reviewer 检查消费者；当 PR 被标记为 eval 候选时，系统可以把 issue、diff、测试和 review 评论归档为候选任务。

这不是为了增加流程负担，而是把原本口头发生的工程判断固定到系统里。

工程实践二：trace store 要保存“可回放事实”，不要保存聊天截图

如果团队使用 Claude Code、Copilot Agent、Cursor、Aider、OpenHands 或内部 coding agent，都会遇到同一个问题：一次 AI 协作的过程很长，内容分散在编辑器、终端、浏览器、PR 和聊天界面里。

这时需要一个 trace store。它不是日志垃圾桶，而是保存“可回放事实”的系统。

trace store 至少要保存五类事实。

类型	内容	用途
输入事实	用户任务、系统提示、上下文文件、检索结果	判断模型看到什么
行动事实	计划、工具调用、文件编辑、命令执行	还原模型做了什么
环境事实	测试输出、编译错误、lint、运行日志	判断失败反馈是否充分
人类事实	review 评论、人工修改、验收结论	提供 Mentor 信号
结果事实	最终 diff、合并状态、上线反馈、返工记录	校准成功与失败

不要保存不可审计的截图作为主要数据源。截图可以辅助理解，但不能作为训练和评估的基础事实。真正可用的数据必须能被解析、脱敏、检索、版本化和关联。

trace store 也不应该默认永久保留一切。敏感字段要尽早脱敏，低价值 trace 要过期清理，进入 eval 或训练候选的数据要有版本号。数据系统如果没有生命周期管理，很快会变成谁都不敢用的历史黑箱。

工程实践三：把测试失败当成最高价值的导师信号

在 AI 编程协作里，测试失败不是噪音，而是最便宜的监督信号。

一个通过测试的 patch 只能说明它满足了已有测试；一个失败后被正确修复的 patch，往往能告诉我们模型原先误解了什么、如何从环境反馈中恢复、哪类错误最容易重复发生。对训练和评估来说，后者的教学价值更高。

我建议团队专门保存三类失败轨迹。

失败类型	为什么有价值	数据用途
初始实现失败	暴露模型默认假设和常见遗漏	错误模式库、SFT 反例说明
工具反馈后修复失败	暴露模型是否会误读日志或盲目修改	agent eval、工具使用评估
人类指出后修复成功	暴露 Mentor 信号如何改变结果	偏好数据、修复策略训练

这里有一个细节：不要只保存最终成功版本。至少保留一次失败版本、失败证据、人类或环境反馈、最终修复之间的链路。没有这条链路，模型只能学习“成功答案长什么样”，学不到“如何从失败走向成功”。

Anthropic 在 Claude Code 实践中强调要给模型验证工作的方式，比如测试、lint、截图、日志和命令反馈。这个建议的本质不是“多跑测试”，而是把验证路径变成模型可使用的环境信号。Coding Mentor 数据闭环要进一步把这些环境信号保存下来，变成后续评估和训练的证据。

工程实践四：eval set 要像测试集一样维护，而不是像文档一样收藏

很多团队会建一个“AI 评估题库”，但维护方式像文档：偶尔新增，少有版本，不清楚覆盖范围，没人追踪过期。这样的题库很快会失效。

私有 eval set 应该像测试集一样维护。

维护动作	工程含义
版本化	每次新增、删除、修改任务都能追溯原因
覆盖率统计	知道 eval 覆盖哪些语言、模块、风险类型和能力维度
隔离 train/eval	防止训练数据污染评估数据
flakiness 监控	不稳定任务不能作为模型能力判断依据
难度校准	防止全是简单 bug 或全是极端难题
失效下架	过时架构、废弃 API、历史临时方案必须退出

eval set 里的每个任务最好都有一个“为什么值得评估”的理由。比如：

任务	评估理由
修复支付回调幂等问题	测试模型能否识别并发与重复消息风险
为缓存穿透补测试	测试模型是否理解边界输入和异常路径
重构订单状态流转	测试模型是否能保持行为不变并遵守状态机约束
处理第三方 API 超时	测试模型是否能区分重试、降级和错误传播

没有理由的 eval 题，后面很难判断它是否还值得保留。

工程实践五：训练候选样本要少而硬，不要多而散

到了训练数据这一步，很多团队会自然追求数量。我更看重硬度。

所谓硬度，是样本包含真实工程约束、明确错误模式、清晰修正理由和可靠验证证据。一个硬样本可能比二十条普通问答更有价值。

适合进入 SFT 候选集的样本，通常有这些特征：

特征	判断标准
任务真实	来自真实 issue、真实 PR、真实缺陷，而不是随手编题
上下文适中	既包含必要背景，又不会依赖大量不可公开细节
修正明确	人类修改不是风格偏好，而是解决具体工程问题
验证充分	有测试、CI、review 或上线反馈支撑
可迁移	经验能迁移到同类任务，而不是一次性业务特例
风险干净	已脱敏、无许可问题、不污染 eval

不适合进入训练集的样本也要明确。

样本类型	为什么不适合
只靠人类直觉判断“还行”的输出	缺少可验证证据
最终通过但过程混乱的 patch	可能把坏策略训练成默认行为
包含客户数据或生产日志的 trace	安全风险高
来自公开 benchmark 的完整答案	污染评估
只体现个人代码风格偏好的修改	可迁移价值低
针对废弃架构的历史修复	会把过期经验固化

第 8 篇会详细讨论如何把这些候选样本加工成 SFT 数据。本文只给一个原则：训练数据不是把“成功结果”喂给模型，而是把“成功结果背后的工程判断”喂给模型。

工程实践六：偏好数据来自争议，不来自漂亮答案

SFT 适合教模型“应该怎样做”。但很多工程问题没有唯一答案：这个抽象要不要拆，缓存应该放在哪一层，错误是吞掉还是向上传播，测试是补单元还是集成，重构是这次做还是拆到后续任务。

这些场景更适合沉淀偏好数据。偏好数据不是“答案 A 比答案 B 好”这么简单，而是要说明“在什么约束下 A 比 B 好”。

一个好的偏好样本通常来自 review 争议，而不是来自一开始就顺利通过的代码。

场景	偏好判断
AI 提出大规模重构，人类要求最小修复	当前任务目标是止血，重构风险超过收益
AI 抽象出通用组件，人类保留局部实现	只有一个调用点，抽象引入的生命周期成本不值得
AI 用缓存提升性能，人类拒绝	数据一致性要求高，缓存失效策略不完整
AI 补大量 snapshot test，人类要求行为断言	snapshot 会固化实现细节，不能证明业务语义

这些争议样本的价值很高，因为它们把团队的工程品味显性化了。模型要成为团队里的可靠协作者，不能只会写对代码，还要学会在约束下做取舍。

工程实践七：知识库不是训练集的垃圾桶

很多不能进入训练的数据，仍然可以进入团队知识库。比如架构决策、review 规则、常见错误模式、迁移指南、模块边界说明。这些内容可以通过 RAG 或提示词上下文影响 AI 的下一次行为。

但知识库不能变成训练集的垃圾桶。不能因为某条数据不适合 SFT，就随手扔进知识库。知识库里的内容会进入模型上下文，质量差一样会污染输出。

知识库条目最好满足四个条件：

条件	说明
规则明确	能指导后续任务，而不是只记录历史事实
生命周期清楚	知道什么时候过期，谁负责更新
适用范围明确	标明模块、语言、场景、例外情况
与 eval 关联	重要规则最好有对应 eval 任务验证

例如，“订单服务不能直接调用库存数据库”就是一个知识库规则；“某次订单服务因为直接查库存数据库导致问题”是复盘材料；“AI 曾经写过这段错误代码”是 trace。三者相关，但不能混成一类数据。

组织分工与成熟度模型

组织分工：谁拥有这套闭环

数据闭环不是某个工具团队的独角戏。它横跨产品、研发、测试、安全、平台和模型团队。没有清晰所有权，最后会变成没人维护的仪表盘。

我建议用下面的责任边界。

角色	主要职责
业务负责人	定义真实验收标准，判断任务价值和风险等级
开发者	记录 AI 参与范围、关键上下文、失败修正和验证证据
Reviewer / Coding Mentor	提供结构化反馈，标注错误类型和可迁移经验
QA / 测试负责人	维护验证证据、flaky 标记、回归任务
安全与合规	定义脱敏、许可、保留周期和不可训练边界
平台工程	建设 trace store、数据路由、eval runner、质量门控
模型/AI 工程	使用数据进行 prompt、RAG、SFT、RFT 或工具链优化

最关键的是 Coding Mentor 角色。这个角色不等同于资深工程师，也不等同于模型训练工程师。他需要理解工程上下文，也需要知道哪些反馈对模型有学习价值。很多团队缺的不是 AI 工具，而是这种“懂工程、懂反馈、懂数据边界”的中间角色。

成熟度模型：从个人习惯到组织飞轮

闭环建设不能一步到位。成熟路径大致可以分四级。

第一级是个人习惯。开发者自己记录 AI 参与范围、失败案例和修正理由。这个阶段不需要平台，只需要纪律。目标是让个人能复盘一次 AI 协作为什么成功或失败。

第二级是团队规范。PR 模板、review 标签、AI 使用记录、验证证据开始统一。这个阶段开始产生可比较的数据，团队能看出 AI 在哪些任务上可靠，在哪些任务上经常返工。

第三级是平台化闭环。trace store、eval runner、数据脱敏、样本路由、质量门控开始自动化。团队不再靠人手整理，而是在日常交付中持续产生候选数据。

第四级是模型与工具链优化。私有 eval、SFT 候选集、偏好数据、知识库和 prompt 版本形成闭环。模型升级、提示词变更、工具链调整都要经过私有 eval 和线上指标回归。

阶段	主要目标	最小可行动作	不要急着做
个人习惯	让 AI 协作可复盘	保存关键 prompt、失败日志、人工修正理由	训练模型
团队规范	让数据结构一致	PR 模板、review 标签、验证证据字段	全自动采集
平台化闭环	让轨迹可检索、可门控、可路由	trace store、脱敏、eval runner、样本版本	多模型复杂调度
模型优化	让数据反哺能力	私有 eval、SFT/RFT 候选集、A/B 对比	盲目追求大规模微调

这个成熟度模型有一个现实前提：每一级都要能独立产生价值。个人习惯能提升复盘质量，团队规范能减少重复争议，平台闭环能减少数据整理成本，模型优化能提升下一轮交付质量。如果某一级只能为下一级服务，它很容易半途而废。

反模式：闭环最容易失效的地方

反模式一：把 AI 日志当作训练数据

日志不是训练数据。日志只是原材料。

一条原始 AI 对话可能包含错误上下文、过期约束、敏感信息、半成品推理、无效尝试和人类临时指令。直接拿去训练，等于让模型学习团队最混乱的一面。

正确做法是把日志分层：

层级	处理方式
原始日志	短期保留，用于审计和问题复盘
结构化 trace	提取事实，关联任务、工具、diff、测试、review
候选样本	经过脱敏、去重、质量评分和人工抽检
训练/评估资产	明确用途、版本、生命周期和隔离关系

没有经过结构化和门控的日志，最多是调试材料，不是模型资产。

反模式二：只奖励“最后通过”

如果团队只把“最终通过测试”的输出当好样本，模型会学到一种危险偏好：只要最后能过，过程怎么走都无所谓。

软件工程不是刷题。一个最后通过的实现，可能靠的是扩大作用域、绕过接口、增加隐藏状态、牺牲性能或制造后续维护成本。真实团队关心的是“可维护地通过”，不是“侥幸通过”。

所以样本评分不能只看结果。至少要同时看五个维度：

维度	问题
正确性	功能是否满足验收标准
最小性	修改范围是否合理，是否引入无关变化
可维护性	结构是否符合团队长期演进方向
可验证性	是否提供足够测试和证据
约束遵守	是否遵守安全、性能、兼容和架构边界

这也是为什么人类 Mentor 反馈重要。自动测试能判断很多事，但不能完整判断工程取舍。

反模式三：用公开 benchmark 替代团队私有任务

公开 benchmark 能帮助团队比较模型基础能力，但不能替代团队私有任务。尤其是 AI 编程，模型是否“会写代码”只是门槛，是否“懂你的代码库、你的约束、你的发布方式”才决定它能否进入真实交付。

SWE-bench 的价值在于它把真实 GitHub issue、代码仓库和测试引入评估，逼近真实软件工程。但对一个具体团队来说，最关键的评估任务应该来自自己的历史 bug、架构约束、测试逃逸和 review 争议。

我建议公开 benchmark 只回答两个问题：

1. 这个模型是否具备进入团队试用的基础能力？
2. 模型升级后是否出现明显通用能力退化？

团队私有 eval 才回答更关键的问题：

1. 这个模型能不能在我们的仓库中稳定定位问题？
2. 它是否遵守我们的架构边界和安全红线？
3. 它是否减少 reviewer 的重复劳动，还是制造新的返工？
4. 它是否能从我们给出的 Mentor 信号中持续改进？

反模式四：把 Coding Mentor 做成少数专家的额外负担

如果所有结构化反馈都依赖少数专家手写，这套系统会很快停掉。专家时间太贵，不能用于重复整理。

正确做法是分层。

层级	谁负责	自动化程度
基础事实采集	系统	高，自动从 PR、CI、agent trace 提取
常规标签	开发者和 reviewer	中，通过模板和预设标签完成
高价值样本判断	Coding Mentor	低，人工判断教学价值和边界
数据集抽检	AI/平台/安全联合	中，自动扫描加人工抽样

专家只应该处理高价值判断：这条样本是否能代表某类工程能力？这个错误是否足够典型？这个修复是否可迁移？这个经验是否已经过期？其余部分尽量自动化。

90 天路线图、指标体系与集成边界

一个可落地的 90 天路线图

如果一个团队今天要启动这套闭环，我不建议直接立项半年平台。先跑 90 天。

第 1-30 天：让 AI 协作可审计

目标不是收集大数据，而是让每次 AI 参与交付有最小记录。

行动：

1. 修改 PR 模板，加入 AI 参与范围、关键上下文、验证证据、失败修正和数据路由建议。
2. 定义 6-8 个错误类型标签，不要超过 10 个。
3. 选择 2 个真实项目试点，不覆盖全公司。
4. 每周挑选 5 条 AI 协作案例复盘，判断哪些有 Mentor 价值。

验收标准：

指标	目标
AI 参与 PR 的记录完整率	超过 70%
每周可复盘案例	至少 5 条
初版错误类型标签	能覆盖 80% 常见问题
明确丢弃规则	至少覆盖敏感信息、不可复现、低价值三类

第 31-60 天：建立私有 eval 种子集

目标是把真实交付中的高价值任务固化为可回归评估。

行动：

1. 从历史 bug、review 争议和测试逃逸中挑选 20-50 个任务。
2. 为每个任务补齐题干、仓库版本、验收标准、测试命令和参考修复。
3. 明确 train/eval 隔离规则。
4. 选择 2-3 个模型或工具链版本进行离线评估。

验收标准：

指标	目标
eval 任务数	20-50 个
每个任务可复现	100%
flaky 任务标记	100% 有状态
模型对比报告	至少 1 份

第 61-90 天：打通样本路由和改进反馈

目标是让数据开始反哺工具链，而不是停留在报告。

行动：

1. 建立 trace store 的最小版本，可以先用结构化文件或内部表格，不必一开始上复杂系统。
2. 把交付轨迹路由为 eval、SFT 候选、偏好数据、知识库和丢弃区。
3. 对高频错误做一次 prompt、RAG 或工具链修正。
4. 用私有 eval 回归修正效果。

验收标准：

指标	目标
数据路由覆盖	试点项目 AI PR 的 60% 以上
SFT 候选样本	30-100 条硬样本
高频错误修正	至少 1 类错误有明显下降
eval 回归机制	能在工具链变更前后稳定运行

90 天后再决定是否平台化。如果连 PR 模板、eval 种子集和样本路由都跑不起来，贸然建平台只会把流程问题固化成系统问题。

指标体系：不要只问 AI 省了多少时间

AI 编程助手的生产力指标当然要看，但 Coding Mentor 数据闭环还要看另外几组指标。

指标组	代表指标	说明
交付效率	lead time、AI 参与任务完成时间、PR 周期	判断 AI 是否真的帮助交付
工程质量	CI 失败率、review 缺陷密度、缺陷逃逸、rollback	判断 AI 是否制造质量债
协作负担	人工修正次数、review 轮次、重复反馈频率	判断 AI 是否降低导师负担
数据资产	可用 eval 数、硬样本数、样本通过门控比例	判断闭环是否产生可复用资产
模型改进	私有 eval 提升、高频错误下降、工具链回归稳定性	判断数据是否真的反哺能力

最容易误导的是“AI 参与率”。AI 参与率高，不代表价值高。一个团队可以让 AI 写很多代码，同时让 reviewer 更累、缺陷更多、架构更乱。真正要看的，是 AI 参与后是否减少了重复错误，是否让工程判断更可复用。

与现有工程体系的集成边界

这套闭环不应该另起炉灶。它应该嵌入已有工程体系。

现有系统	集成方式
Issue 系统	保存需求、验收标准、缺陷分类、业务优先级
Git/PR	保存 diff、review、合并状态、AI 参与字段
CI/CD	保存测试、构建、安全扫描、部署结果
日志/监控	保存上线反馈、错误率、性能变化
文档系统	保存架构约束、规范、复盘和知识库
模型平台	运行 eval、prompt 版本、SFT/RFT 实验和 A/B 对比

边界也要清楚。AI 数据闭环不是替代 ALM、CI、代码评审或知识库，而是把这些系统中的关键信号串起来。它更像一层“AI 工程学习层”，负责把交付事实转化为模型可学习、团队可评估的资产。

这套闭环真正解决什么问题

把文章写到这里，容易让人觉得这是一套很重的系统。它确实比“打开 AI 工具直接写代码”重。但它解决的是后者永远解决不了的问题。

第一，它让 AI 的进步可归因。模型变好了，是因为换了模型、改了 prompt、补了上下文、训练了样本，还是任务变简单了？没有 eval 和 trace，团队只能猜。

第二，它让人类经验可复用。资深工程师每次 review 的判断，不再只服务当前 PR，而是变成后续模型、知识库和 eval 的资产。

第三，它让 AI 风险可治理。敏感数据、过期经验、benchmark 污染、不可复现样本，不再靠个人自觉，而是进入门控系统。

第四，它让模型优化服务交付，而不是服务分数。公开榜单上的提升如果不能减少团队返工，就不是这个团队的真实收益。

第五，它让 Coding Mentor 从个人能力变成组织能力。一个人会调教 AI 很有价值，但一个团队能稳定生产 Mentor 信号，价值更大。

结语：先建设反馈系统，再谈训练系统

我的建议很明确：不要从“我们要训练一个团队专属模型”开始。先从“我们能不能把 AI 参与交付的过程变成可靠反馈系统”开始。

如果团队还没有记录 AI 失败原因，就不要急着做 SFT。如果团队还没有私有 eval，就不要相信微调后的分数。如果团队还没有数据门控，就不要把协作日志当资产。如果 reviewer 的判断还停留在“这里不行”，就先训练人类如何写 Mentor 信号。

真正的顺序应该是：

1. 让 AI 交付过程可观察。
2. 让人类反馈结构化。
3. 让数据路由有门控。
4. 让私有 eval 能回归。
5. 让训练数据少而硬。
6. 让模型和工具链根据评估持续改进。

这就是本文所说的闭环：AI 辅助产品工程化交付不是终点，它是训练数据和评估数据的生产现场；人类 Coding Mentor 不是最终验收员，而是反馈信号的设计者；SFT 不是把日志倒进模型，而是把经过门控的工程判断沉淀为可学习资产。

下一篇（第 8 篇）进入更具体的问题：当这些轨迹、反馈和候选样本已经产生，如何把它们清洗、筛选、标注、转换成高质量 SFT 数据，并接入训练流水线。完成这一步后，收官的第 9 篇再回到长期演进与未来展望。

参考与致谢

• GitHub: Research: quantifying GitHub Copilot’s impact on developer productivity and happiness
• GitHub: Research: quantifying GitHub Copilot’s impact in the enterprise with Accenture
• Anthropic: Building effective agents
• Anthropic: Claude Code best practices
• LangChain: Traces start the agent improvement loop
• OpenAI: OpenAI Evals API
• OpenAI: How evals drive business results
• OpenAI: Model optimization
• Jimenez et al.: SWE-bench: Can Language Models Resolve Real-World GitHub Issues?
• Yang et al.: SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering
• Jimenez et al.: SWE-Gym: Advancing the State-of-the-Art of Software Engineering Agents