Brian Douglas：把智能体纠正记录变成可复用的审查知识

我是 Brian Douglas，我想看看工程师纠正编程智能体时发生了什么。这些时刻可能包含原本只留在私人会话里的知识。

即使我缺少专业 Rust 经验，也能用智能体生成 Rust。但初级工程师传统上通过反复实践学习，把这些练习交给智能体可能留下判断力的缺口。

我的开源项目 Tapes 会记录智能体会话。其他遥测工具和编程工具也能做到；重点是保存交互数据，而不是一定要用某个产品。我还使用运行环境来重现智能体的工作环境。

我曾用并行智能体处理文档、测试和清理等定义清晰的工作。这有助于完成重复任务，但不会自动赋予我判断每个 Rust 生成结果的经验。

团队集中保存会话并添加标签。其中一个标签是“纠正”：工程师对智能体提出反对时使用。我会寻找同事解释 API 约定或指出某个服务已经存在的地方。

代码即使能够编译，也可能违背团队已经作出的设计决定。由于我不一定能在生成的 Rust 中看出这些选择，我可能会先接受，直到人工审阅者在拉取请求中指出问题。

我把标注过的轨迹收集成数据集，并在一个拉取请求上演示 Twin Review 原型。它尝试根据同事此前的纠正给出类似的评论；示例来自记录的智能体会话。

我起初说原型是开源的，随后纠正：由于数据敏感，Twin Review 并未公开。更一般的做法可以用其他工具和合适的数据集实现。

有用的标签包括纠正、成功的会话和回归问题。一个反复出现的例子是智能体重新实现已有库；经验丰富的同事可能马上发现，不熟悉的人则可能没有注意到。

我的建议是先把这些轨迹转成技能或指令，再建立评估。通过评估判断技能是否反映团队约定，然后再决定是否值得投入模型适配。

我也尝试过适配较小的模型和偏好优化。这些方法对算力的要求不同；对大多数团队，我建议先尝试更简单的技能，并使用已有的会话记录工具。

实际起点是保存开发过程中已经产生的纠正和结果。这些记录可以成为审查流程、技能或评估的示例，而不是在会话结束时消失。