跳到主要内容

Harness 工作流怎么快速搭起来

最近在想一个问题：如果 harness 的价值是把一次工作沉淀成可重复执行、可检查、可改进的流程，那么我们真正卡住的地方，可能不是“执行”，而是“搭建”。

一个工作流从出现到闭环，大概会经历这样一条链路：

工作流搭建
  -> 工作流执行
  -> 执行过程中发现问题
  -> 解决问题
  -> 将问题解决的经验总结回工作流
  -> 完成闭环

现在看下来，除了第一步“搭建”还需要很多人工参与，后面的执行、发现问题、解决问题、总结经验，都已经可以比较多地交给大模型完成。

所以真正值得解决的问题变成了：如何降低 harness 工作流搭建过程中的人工参与？

为什么还要搭建新的 harness？​

一个很自然的疑问是：现在写代码的 harness 工作流已经不少了，为什么还要继续搭建？

原因是，现有 harness 大多围绕 coding 场景设计。它们擅长处理需求、改代码、跑检查、修问题、总结经验，但工作中的流程远不止写代码。

比如：

  • 页面迁移
  • 组件迁移
  • 设计稿还原
  • 组件参数梳理
  • 跨项目规范同步
  • 文档、配置、资产迁移

这些流程也有明确的输入、步骤、检查点和沉淀方式，也应该被 harness 化。否则每次都靠人临场组织流程，最后还是会变成经验散落在聊天记录、脑子里、临时文档里。

能不能用一个工作流来创建工作流？​

另一个问题是：如果做一套“创建工作流的工作流”，让开发者通过和 AI 对话来生成特有 workflow，这件事是否可行？

我觉得方向是可行的，但它不能只是让 AI 随便写一份流程文档。

更合理的方式应该是让 AI 先做几件事：

  1. 追问这个流程的目标和边界。
  2. 识别流程的输入、输出和完成标准。
  3. 拆出关键阶段和每个阶段的检查点。
  4. 调研已有流程、工具、页面、组件、历史任务。
  5. 生成初版 workflow、校验规则和沉淀规则。
  6. 用一个小样本任务试跑。
  7. 根据试跑中暴露的问题反向修 workflow。

也就是说，“创建工作流的工作流”本身也需要闭环。它不应该只产出一份静态文档，而应该产出一套能跑、能查、能改的流程骨架。

这里的关键不是让 AI 一次性写对，而是让 AI 能够调研、试跑、校验、修正。

校验不能只靠 lint，也不能只靠截图​

工作流能不能成立，很大程度取决于校验是否可靠。

coding 场景里，校验相对容易标准化：lint、typecheck、unit test、build、e2e test 都是比较明确的检查方式。

但页面迁移、组件迁移这类任务就复杂得多。它们不是简单跑一个 lint 就能证明正确，也不应该退化成“截一张图让 AI 看看像不像”。

更合理的校验应该分层：

结构校验​

先确认迁移对象是不是对的。

  • 组件名是否匹配
  • 引用路径是否正确
  • 依赖是否齐全
  • 文件结构是否符合目标项目约定
  • 是否遗漏样式、资源、配置或国际化文案

行为校验​

再确认组件或页面的关键交互是否还在。

  • props 是否完整传入
  • 默认态、加载态、错误态是否存在
  • 用户交互是否触发预期事件
  • 表单、弹窗、跳转、回调是否仍然可用
  • 边界数据下是否表现正常

视觉校验​

最后再看视觉是否达标，但截图只能作为证据之一。

  • 布局是否稳定
  • 间距、字号、颜色是否符合预期
  • 响应式断点是否正常
  • 关键 DOM 或样式 token 是否被正确使用
  • 截图 diff 是否只作为辅助判断，而不是唯一判断

迁移语义校验​

页面和组件迁移还需要确认“为什么这样迁”。

  • 新旧组件能力是否等价
  • 不等价的地方是否有明确取舍
  • 业务参数是否被正确映射
  • 旧逻辑是否有废弃或替代方案
  • 迁移结果是否符合目标框架或设计系统的约定

所以，对非 coding harness 来说，校验不应该只有一个结果，而应该是一组可解释的证据链。

AI 控制浏览器的问题​

这个问题和校验强相关。

在组件迁移过程中，AI 可能需要根据组件名去浏览器里搜索相关参数、文档、示例和历史用法。理论上这很适合自动化，但现在体验还有明显问题。

一个很具体的痛点是：当 AI 需要使用浏览器时，可能会在我做其他事情的时候突然弹出一个浏览器页面，还要求我点击同意外部控制浏览器。这个体验很差，也会打断当前工作流。

这里需要解决的不是“AI 能不能打开浏览器”，而是“AI 应该如何以更合理的方式使用浏览器”。

可能的方向是：

  1. 浏览器控制应该尽量运行在隔离环境，而不是抢占用户正在使用的浏览器。
  2. 授权应该前置完成，而不是在任务中途突然弹窗。
  3. AI 浏览器动作应该有明确的任务边界，比如只访问指定文档站、组件平台或测试页面。
  4. 浏览器产物应该被结构化保存，比如页面 URL、关键截图、DOM 摘要、参数表、失败原因。
  5. 校验不应该依赖“我看到了页面”，而应该依赖浏览器动作留下的可复查证据。

换句话说，浏览器不应该只是 AI 的眼睛，也应该是工作流证据采集器。

一个更理想的搭建流程​

如果把上面这些问题合起来，一个理想的 harness 搭建流程可能是这样的：

开发者描述场景
  -> AI 追问目标、输入、输出、完成标准
  -> AI 调研已有流程和历史样本
  -> AI 生成 workflow 草案
  -> AI 生成校验清单和证据要求
  -> 用一个小任务试跑
  -> 记录执行过程中的失败点
  -> 修正 workflow 和校验规则
  -> 沉淀为可复用 harness

这条路的重点不是“让 AI 自动写一切”，而是把工作流搭建本身也变成一个可执行、可验证、可迭代的流程。

当前最值得继续追的问题​

后面可以继续沿着几个方向拆：

  1. 工作流描述需要哪些最小字段，才能让 AI 稳定执行？
  2. 页面迁移和组件迁移的标准校验清单应该怎么设计？
  3. 浏览器控制如何做到不打扰用户，同时又能留下足够证据？
  4. “工作流生成工作流”是否可以先从组件迁移这种高频场景试点？

如果这些问题能解决，harness 就不只是 coding agent 的辅助工具，而会变成一套把各种重复性知识工作流程化、自动化、可沉淀的基础设施。