聊聊 AI Coding 的最新范式：从 Vibe Coding 到 Harness Engineering
最近在看AI 辅助编程的演进，发现咱们熟悉的工作模式Vibe Coding正在经历一次范式变迁。
一、什么是 Harness Engineering？
简单来说，Harness Engineering 就是给 Agent 盖一座"全自动工厂"。
- Vibe Coding（结对编程）： 是你和 AI 坐在电脑前，你说一句它改几行代码，靠"感觉"对齐。这是目前大家用 Cursor 的主流方式，需要人高度参与。
- Harness Engineering（治具工程）： 是你退后一步，不直接碰代码，而是去设计规则、约束、检查点和自动化循环（Loop），让 Agent 自主跑完流程。
"Harness" 最原始的意思是"马具"。Agent 不是在旷野上自由奔跑的野马（容易跑丢产生幻觉），而是被套上了"马具"，只能在你设计的轨道上、按照你的验收标准全力拉车。
在咱们工程语境里，最贴切的翻译是**"约束环境"或 "测试治具"**。想象一下工厂的生产线：检测电路板时，工人不会拿万用表一根根线去量，而是把电路板放进一个专用的"治具"架子上，一通电就能自动测出所有结果。我们现在要做的，就是为 Agent 打造这个"写代码的治具"。
二、AI 编程范式的三个阶段
| 阶段 | 模式 | 咱们程序员的角色 | 工具代表 |
|---|---|---|---|
| 1.0 辅助编程 | AI 是插件 | 搬砖工（你写代码，AI 递砖） | Copilot |
| 2.0 Vibe Coding | 结对编程 | 监工（看 AI 写代码，实时干预纠偏） | Cursor |
| 3.0 Harness Engineering | 环境设计 | 架构师/工艺工程师（设计全自动生产线） | Claude Code, Codex, 内部自研 Agent 平台 |
三、核心思维转变：从"改代码"到"改环境"
在 Harness 范式下，我们的核心技术点和做事方式需要发生根本性转变：
- 修复环境，而非修复代码： 当 AI 写出 Bug 时，低级做法是直接告诉它"这行写错了"；高级做法是思考**"为什么咱们的测试没抓到这个 Bug？"或者 "是不是目录结构误导了它？"**。然后，通过修改
AGENTS.md规范或增加 Linter 来"修复环境"。 - 极端的语义化约束： 文件路径、代码分层（如 Types -> UI）必须极度规范。不要再用
utils/这种模糊的目录，因为清晰的工程结构就是 Agent 的"认路地图"。 - 理解模型的"审美偏好"： 提示词工程不再是写长作文，而是精准预判模型的倾向。比如某个模型倾向于某种特定的 UI 风格或逻辑范式，你就必须在约束环境里加上量化指标，防止它跑偏。
- Skill（技能）的模块化与递归： 别把 Agent 当成万能黑盒。把它的能力拆解成一个个带有"Use when..."触发条件的微服务（Skill）。复杂的动作（如"修复 PR"）封装成 Skill，Skill 甚至可以生成新的 Skill，并配上单元测试。
四、咱们未来的核心工作流是什么？
作为高级开发者，我们的精力将从"写业务逻辑"转移到"设计软件生产的数字宪法"。具体分为以下五个维度：
1. 需求与上下文治理（最上游的防线）
- 构建"需求验证治具"： 现实中的需求常有逻辑漏洞。在 Agent 进入编码循环前，要增加一环：让 AI 扮演"杠精产品经理"推演边缘场景，强制推行 BDD（行为驱动开发），直到需求本身逻辑闭环。
- 建立"项目知识图谱"： Agent 每次跑任务都是"临时工"，不知道历史踩坑记录。除了写
AGENTS.md，我们还要建立动态的DECISIONS.md。每次 PR 合并后，自动提炼"核心逻辑"存入向量库，作为 Harness 的长期记忆。
2. 定义数字化架构约束 (The Architect)
AI 就像极速狂奔但没方向感的劳动力，我们要为它修路建围栏。
- 推行严格的 DDD 与单向依赖： 规定 UI 只能调 Service，Service 只能调 Repo。Agent 只要确认当前任务在哪一层，就能快速圈定上下文。
- 语义化命名体系： 当前后端模型（如
Order和OrderDTO）命名严格对齐时，Agent 跨端理解的幻觉会大幅降低。
3. 设计确定性的反馈循环 (The Feedback Loop Designer)
Harness 的核心是 Loop。AI 写代码不重要，重要的是它如何知道自己写错了。
- 建立"可观测性"治具： 写脚本自动捕获编译器的报错、Console 的异常，结构化地喂给 Agent，让它自己排查。
- 自动化测试矩阵（TDD 2.0）： 我们不再"写代码"，而是"写验收标准"。在 Agent 动手前先定义好 E2E 测试，不通过测试就不能提 PR。这就是用"法治"代替"人治"。
4. 异构模型编排 (The Model Orchestrator)
不同模型各有所长（如写逻辑用 Claude，搞 UI 用 Gemini，修 Bug 用 Codex）。
- 设计 Skill 路由： 写一个编排 Skill，根据任务标签自动将工作分发给最适合的模型。
- 解决"上下文雪崩"： 当项目变大，我们要设计"上下文裁剪算法"，只提取 Agent 当前需要的 Types 和 Schema，而不是把整个仓库塞给它。
5. 掌控演进生命周期 (The Lifecycle Manager)
- 设计契约（Contract）： 在后端接口就绪前，先定义好 JSON Schema。告诉 Agent 基于契约写 Mock 逻辑。以后真实接口上线，代码几乎无需重写。
- 环境隔离机制： 设计从 Mock 环境到生产环境的平滑切换（如环境变量控制），这是 AI 难以自发想周全的全局配置。
五、结语：重新定义咱们的身份
在古法编程时代，我们是伐木工 （手写每一行代码）； 在 Vibe Coding 时代，我们是带班组长 （看着 AI 写代码）； 在 Harness Engineering 时代，我们将是自动化林场的总设计师。
大家现在可以立刻尝试落地的 3 件事：
- 编写你的
AGENTS.md： 这不是给同事看的，而是给 AI 看的"宪法"，写清楚你们项目的目录流转和依赖关系。 - 构建核心"验收包"： 跑通一套自动化的 lint + build + test 脚本，作为 Harness 的第一道检查点。
- 沉淀"元 Skill"： 把日常工作中诸如"将 UI 图转为组件代码"、"根据 TS 接口生成 Mock 数据"等高频重复动作，封装成独立的原子能力。