「大文件排查」是开发团队的高频任务。它的输入通常是仓库，期望得到的是大文件清单。这类有固定流程、又需要一点判断力的工作，很适合封装成智能体 Skill。

“感觉好用”不足以说明技能有效。下面给出一套轻量的评估方法，用来判断「大文件排查」是否达标，以及每次修改后是变好还是变坏。

1. 建一个样例集

收集 10～20 份有代表性的仓库（已脱敏），覆盖常见情况、困难情况和边界情况。为每份样例写下“合格输出应该包含什么”。

2. 定义评分维度

维度0 分1 分2 分
完整性缺少主要部分缺少次要部分大文件清单结构完整
准确性有编造或明显错误有小瑕疵内容都能在输入中找到依据
流程遵循跳过多个步骤跳过一步按步骤执行
边界处理缺信息时编造部分提问先提问或明确标注
可用性需要大改需要小改基本可直接使用

3. 打分方式

  • 人工打分最可靠，两人独立打分取平均
  • 可以让另一个模型按评分表初评，但要人工抽查，不要完全依赖
  • 记录每个样例的得分和问题描述

4. 回归测试

每次修改技能后，跑一遍完整样例集，比较总分与各维度变化。某个维度下降时，回看是哪条修改导致的。

5. 关注真实使用

离线样例之外，留意真实使用中被人工大幅修改的输出，把它们补进样例集。

每一步可以单独检查

  • 扫描历史中的大对象：是否完成、是否有依据
  • 标出路径与大小：是否完成、是否有依据
  • 建议迁移到 LFS：是否完成、是否有依据
  • 提醒改写历史的风险：是否完成、是否有依据

提醒

评分表是工具，不是目标。属于中等风险：结果会影响业务判断，建议在输出前设置人工审核点。不要为了分数好看而让技能输出冗长内容。相关：测试用例、故障排查。

领域注意事项

「大文件排查」属于Git 与协作领域，使用者多是开发团队，工作环境通常是Git 仓库与代码托管平台。这个领域最重要的一条底线是：改写历史、删除分支类操作只给建议，不直接执行。

建议把这条底线原样写进技能的约束部分，而不是指望智能体自己意识到。同时，在团队内部明确：智能体给出的大文件清单只是初稿或建议，最终由谁签字确认、出了问题由谁负责。

常见变体

同一个技能可以按使用场景派生出几个变体：

  • 简版：只保留核心步骤（扫描历史中的大对象、提醒改写历史的风险），适合快速过一遍
  • 详版：每一步都写出理由与依据，适合交给他人复核或留档
  • 批量版：一次处理多份仓库，输出汇总表，适合定期集中处理

变体之间共享同一套约束，只在步骤详略和输出格式上有差异。可以在一个技能里用参数区分，也可以拆成几个名称明确的技能。

延伸阅读

说明：文中的配置、代码与目录结构均为示意，用于说明思路；各平台的入口、字段名与能力会更新，落地前请以对应官方文档为准。示例中的数据与场景为虚构，不代表真实案例。