最近大家都在聊 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 说："做一个登录页。"现在，应该把任务变成："做一个登录页，并且必须满足：
- 桌面和移动端布局都正常。
- 表单校验错误态完整。
- Playwright 的核心用例通过。
- Lighthouse 性能评分大于 85。
- 视觉回归测试无明显差异。"
这样，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 做法是：
- 补一个能复现该问题的测试用例。
- 为弹窗组件补一个自动化的交互测试。
- 在文档中补充一条"弹窗行为约束"。
- 让后续 AI 修改弹窗代码时，能自动跑这条检查。
5. 让 AI 改"小而清晰"的模块，而不是整坨业务
OpenAI 的实践反复强调：可读性、模块化、结构化的知识，以及清晰的边界，是让 agent 高效工作的前提。
前端最怕看到的是"屎山"代码：一个页面文件 3000 行，状态、请求、视图全写在一起，组件没有职责边界。这种代码人难改，AI 更容易改坏。
更适合 AI 的前端结构，应该遵循清晰的职责划分：
- 页面层：只负责组装。
- 容器层：负责数据和状态管理。
- 展示组件：纯 UI，接收 props。
- Hooks：逻辑单独抽离。
- Schema / Types / API：独立管理。
- 测试：贴近模块放置。
这样，当 AI 接到一个修改任务时，它的上下文更小，误改范围也更可控，准确率自然更高。
适合前端的实际落地方案
从轻量级开始，我们分四个阶段：
第一阶段：先把"护栏"补起来
- TypeScript 严格模式
- ESLint / Prettier
- Storybook
- Playwright
- 基础 CI
第二阶段：把团队规范文档化
- 组件使用规范
- 页面结构规范
- 状态管理规范
- 样式规范
- 无障碍规范
第三阶段：把 AI 接进固定流程每个任务都要求 AI：
- 先读相关文档
- 只改指定目录
- 先补测试或补场景
- 生成代码
- 跑 lint / test / build / e2e
- 输出变更说明和风险点
第四阶段：积累可复用 harness把常见任务模板化：
- "新增表单页"
- "新增列表页"
- "修复响应式问题"
- "改造旧组件到设计系统"
- "补一个 Storybook 场景"
- "给页面加埋点和性能检查"
久而久之，你的产出就不再是"一次次 prompt"，而是一套越来越稳的前端工作流。
总之，下一个阶段前端工程师的价值更多在于：
- 定义系统边界
- 设计组件和规范
- 搭建验证机制
- 控制质量门槛
- 把经验沉淀成流程
我们要从"页面实现者"，慢慢升级成"前端生产系统的设计者"。把前端项目变成一个 AI 很难写歪、写错了也会立刻被发现的系统。