Harness Engineering 前端开发的下一个阶段

最近大家都在聊 OpenAI 提出的 Harness Engineering（驾驭工程）。刚看到这个词时，我以为是又一套 AI 编程方法论，详细了解了一下，发现它说的其实是工作方式的底层转变：

当开发者的主要工作不再是亲手写代码，而是设计环境、明确意图、搭建反馈回路，让智能体可靠完成工作时，工程方式就变了。

对前端来说，天然有一套"可视化验证 + 组件约束 + 自动检查"的体系，只是以前用来约束人，现在可以用来约束 AI。

和普通 AI 辅助开发有什么区别？

• 普通用法：“我给 AI 一个 prompt，让它帮我写个组件。”
• Harness Engineering 的思路：“我先把项目整理成 AI 不容易犯错的样子，再让 AI 干活。”

两者的核心区别，是焦点从“提示词”转向了“约束系统”，除了上下文工程，Harness Engineering 更强调架构约束和持续清理代码库的“熵管理”。

那么，作为前端开发者，我们具体可以怎么做？

1. 把设计系统做成让 AI 也看得懂

前端最常见的问题不是“写不出页面”，而是“写出来不一致”。因此，第一步不是让 AI 更自由，而是让它更难犯错。

我们可以这样做：

• 统一组件入口：例如，通过路径别名强制从 @/components/ui 引用组件。
• 明确组件 API：为按钮、表单、弹窗等组件建立清晰、稳定的接口。
• 提供正反示例：在每个组件文档中，写明“允许”和“禁止”的用法。
• 机器可检查的约束：将设计 token、间距、字号等规则，写成可以被 ESLint 等工具自动检查的代码。
• 建立“模仿”目录：在项目中创建 patterns/ 或 examples/ 目录，存放标准用法，供 AI 直接学习和模仿。

这样一来，AI 生成页面时，不是在“自由发挥”，而是在“走轨道”。一句话总结就是：先把组件库工程化，再把 AI 接进来。

2. 把“页面正确”，从主观审美变成可执行验证

Harness Engineering 的核心是建立“反馈回路”，要让智能体能读取 DOM、截图、日志和指标，自行验证和修复问题。

在前端，最适合建立反馈回路的方式就是各种自动化测试：

• Playwright / Cypress：端到端测试，模拟真实用户操作。
• 视觉回归测试：确保 UI 变更不会产生意外的视觉效果。
• Storybook + 交互测试：隔离组件，验证其功能和交互。
• 多层校验体系：ESLint + TypeScript + 单元测试 + E2E 测试，层层把关。

过去，我们可能会对 AI 说：“做一个登录页。”现在，应该把任务变成：“做一个登录页，并且必须满足：

1. 桌面和移动端布局都正常。
2. 表单校验错误态完整。
3. Playwright 的核心用例通过。
4. Lighthouse 性能评分大于 85。
5. 视觉回归测试无明显差异。”

这样，AI 才有了清晰的“完成标准”，而不是“生成了一堆看似合理的代码”。

3. 把 PR 审查标准写死，不要靠口头经验

把大量知识和规则放进结构化的文档中，而不是一个臃肿的 AGENTS.md。短的索引文件只是入口，真正的规则体系存放在代码库的文档里。

我们可以可以借鉴Open AI的实践：

• docs/frontend-architecture.md：项目整体架构。
• docs/component-guidelines.md：组件设计和使用指南。
• docs/accessibility-rules.md：可访问性标准。
• docs/state-management.md：状态管理方案。
• docs/page-checklist.md：页面开发的检查清单。

这些文档应包含明确的决策和规则，例如：

• 遇到表单优先用哪个方案？
• 哪些页面必须用 SSR / SSG / CSR？
• 网络请求如何统一封装？
• 错误提示、空状态、loading 怎么处理？

当这些规则被“写死”，无论将来是人还是 AI 参与开发，都将遵循同一套标准，保证产出一致性和高质量。

4. 把“前端调试”变成 AI 可复现的流程

前端 bug 的痛点往往不是不会修，而是难以复现。Harness Engineering 的一个重要思想是：每次 agent 犯错，不只是修这一次，而是补一个机制，让它下次不再这么错。

前端可以这样落地：

• 为每个 bug 配复现步骤：能录屏就录屏，能保留请求/响应样本就保留。
• 为典型缺陷补测试：为重现的 bug 补充 E2E 用例，为复杂组件补充 Storybook 场景。
• 强化监控：为线上异常补充更完善的前端监控和日志埋点。

例如，遇到一个“Modal 打开后页面还能滚动”的 bug。修完代码只是开始。真正的 Harness 做法是：

1. 补一个能复现该问题的测试用例。
2. 为弹窗组件补一个自动化的交互测试。
3. 在文档中补充一条“弹窗行为约束”。
4. 让后续 AI 修改弹窗代码时，能自动跑这条检查。

5. 让 AI 改“小而清晰”的模块，而不是整坨业务

OpenAI 的实践反复强调：可读性、模块化、结构化的知识，以及清晰的边界，是让 agent 高效工作的前提。

前端最怕看到的是“屎山”代码：一个页面文件 3000 行，状态、请求、视图全写在一起，组件没有职责边界。这种代码人难改，AI 更容易改坏。

更适合 AI 的前端结构，应该遵循清晰的职责划分：

• 页面层：只负责组装。
• 容器层：负责数据和状态管理。
• 展示组件：纯 UI，接收 props。
• Hooks：逻辑单独抽离。
• Schema / Types / API：独立管理。
• 测试：贴近模块放置。

这样，当 AI 接到一个修改任务时，它的上下文更小，误改范围也更可控，准确率自然更高。

适合前端的实际落地方案

从轻量级开始，我们分四个阶段：

第一阶段：先把"护栏"补起来

• TypeScript 严格模式
• ESLint / Prettier
• Storybook
• Playwright
• 基础 CI

第二阶段：把团队规范文档化

• 组件使用规范
• 页面结构规范
• 状态管理规范
• 样式规范
• 无障碍规范

第三阶段：把 AI 接进固定流程每个任务都要求 AI：

1. 先读相关文档
2. 只改指定目录
3. 先补测试或补场景
4. 生成代码
5. 跑 lint / test / build / e2e
6. 输出变更说明和风险点

第四阶段：积累可复用 harness把常见任务模板化：

• “新增表单页”
• “新增列表页”
• “修复响应式问题”
• “改造旧组件到设计系统”
• “补一个 Storybook 场景”
• “给页面加埋点和性能检查”

久而久之，你的产出就不再是"一次次 prompt"，而是一套越来越稳的前端工作流。

总之，下一个阶段前端工程师的价值更多在于：

• 定义系统边界
• 设计组件和规范
• 搭建验证机制
• 控制质量门槛
• 把经验沉淀成流程

我们要从"页面实现者"，慢慢升级成"前端生产系统的设计者"。把前端项目变成一个 AI 很难写歪、写错了也会立刻被发现的系统。