从让AI写代码，到让AI管流程

1. 背景：我想让 AI 接管训练全过程

最近业余时间，我在尝试用 YOLO26 训练一个目标对象识别模型。

一开始的想法很直接：

把本地视频素材交给 AI，让 AI 帮我完成从数据集处理到模型训练的全过程。

这不是单纯让 AI 写一个训练脚本，而是希望它能串起完整链路：

本地视频
  -> 自动抽帧
  -> 图片质量筛选
  -> 去重
  -> 自动标注
  -> 标注质量检查
  -> YOLO 数据集打包
  -> 训练预检
  -> 链路验证
  -> 正式训练
  -> 模型交付

这个流程看起来清楚，但真正做起来，很快就会发现：

这不是一个“让 AI 写代码”的问题，而是一个“让 AI 稳定推进复杂流程”的问题。

2. 遇到的核心痛点

痛点一：项目一大，AI 容易乱

在单点任务上，AI 很好用。

比如写抽帧脚本、解释训练报错、补一个参数校验，这些都很顺。

但流程一长，AI 就容易混乱：

• 上一轮还在处理数据，下一轮就开始改训练参数。
• 看到日志里某个 success，就误以为整个阶段完成。
• 分不清 dry-run、链路验证和正式训练结果。
• 不知道某个问题应该回到数据阶段，还是训练阶段。

痛点二：输出不统一，AI 很难接力

每个阶段如果都用自己的方式输出结果：

• 有的只写日志。
• 有的打印一段文本。
• 有的生成零散文件。
• 有的没有明确下一步建议。

那 AI 每次都要重新理解上下文。

结果就是：它不是不会处理，而是没有稳定标准可读。

痛点三：一个 Skill 根本不够

刚开始很容易想：写一个完整 Skill，把规则全塞进去。

但项目复杂后，一个 Skill 会越来越长：

• 数据处理规则在里面。
• 自动标注规则在里面。
• 训练规则在里面。
• 交付规则也在里面。

最后它更像一份超长说明书。

AI 仍然可能漏读、误读，或者把不同阶段的规则混在一起用。

痛点四：光靠文字约束不够

提示词可以提醒 AI：

不要越界、先检查状态、失败后回退。

但真正执行时，文字约束不够稳定。

判断图片是否达标、标签是否生成、数据集是否可训练、模型是否正式产物，这些都不能靠 AI 主观理解。

这些判断必须交给脚本和验证器。

3. 设计转向

后来我调整了思路。

不再追求让 AI 更自由，而是让整个流程更可控。

AI 负责理解、拆解、协调和解释。 脚本负责执行、验证、记录和裁决。

这句话是整个项目设计的核心。

AI 不再直接凭感觉判断“这一步是不是成功了”，而是：

调用脚本
  -> 读取结构化结果
  -> 判断下一步
  -> 必要时回退到对应阶段

这样，AI 的角色就从“自由操作员”变成了“流程协同者”。

4. 怎么把流程做稳

先拆阶段

我把整个 YOLO26 训练过程拆成几个清晰阶段：

关键不是拆得多细，而是边界清楚。

数据阶段不训练模型。

训练阶段不回头改标签。

总控阶段不直接修图片、标签和模型文件。

再拆 Skill

一个大 Skill 不够，就拆成多个薄 Skill。

每个 Skill 只回答三个问题：

这个阶段负责什么？
入口脚本是什么？
应该读取哪个结果文件？

复杂规则不写进 Skill。

复杂规则放进脚本、验证器和统一报告。

这样 Skill 不会变成冗长提示词，AI 也更容易按边界行动。

统一输出标准

为了让 AI 稳定接力，每个关键阶段都尽量输出同一类字段：

status        当前状态
next_action   下一步动作
blockers      阻塞原因
artifacts     关键产物

这几个字段解决了很多问题。

AI 不需要从长日志里猜状态。

人也可以快速知道：

• 当前完成了吗？
• 卡在哪里？
• 下一步该做什么？
• 关键文件在哪里？

5. 强脚本比强提示词更重要

这个项目里，脚本不是辅助工具，而是流程裁判。

抽帧脚本不仅抽图片，还判断：

• 清晰度是否够。
• 曝光是否正常。
• 是否重复过多。
• 数量是否达标。

数据处理脚本不仅生成标签，还判断：

• 自动标注质量是否可接受。
• X-AnyLabeling 工件是否生成。
• YOLO 数据集结构是否可训练。

训练脚本不仅启动训练，还区分：

• dry-run。
• 链路验证。
• 正式训练。
• 哪个 best.pt 才能交付。

这些判断如果只靠 AI 看日志，非常不稳。

放进脚本后，每一步都有明确结论：

能继续
需要等待
已经阻塞
应该回退

AI 只需要读取结论，再协调下一步。

6. 总控 Agent 的作用

当阶段拆开以后，需要一个角色把它们串起来。

这就是总控 Agent。

它不直接处理图片。

它不直接改标签。

它不直接改模型结果。

它只做几件事：

• 记录当前运行状态。
• 调用对应阶段脚本。
• 读取统一 JSON 报告。
• 根据 blocker 判断问题归属。
• 决定下一步继续、等待还是回退。

总控 Agent 更像一个流程调度者。

项目越大，越不能让它随意发挥。

要给它轨道，让它沿着轨道推进。

7. 这件事对团队有什么启发

这个 YOLO26 项目只是一个例子。

真正有价值的是背后的 AI 协作方式。

过去我们用 AI，更多是点状提效：

写一段代码、查一个报错、生成一份配置。

但当任务变成长流程时，只会写代码不够。

还需要设计：

• 阶段边界。
• 输出标准。
• 状态恢复。
• 质量门禁。
• 责任回退。
• 最终验收。

这套方式的价值在于：

把 AI 从“靠提示词提醒”变成“靠工程机制约束”。

这比写更长、更复杂的提示词更可靠。

8. 结论

这次 YOLO26 训练实践给我的最大启发是：

AI 在复杂项目里出问题，很多时候不是能力不够，而是缺少流程设计。

如果没有边界，AI 会乱。

如果没有统一输出，AI 会猜。

如果只有一个大 Skill，AI 会被长文本拖住。

如果只靠文字约束，AI 仍然可能越界。

更可行的方式是：

多个薄 Skill 负责引导
强脚本负责执行和判断
统一 JSON 负责状态交接
总控 Agent 负责协调