AI 编程的分水岭，不是模型，而是 Harness
当 AI 越来越会写代码，真正拉开差距的会是工程系统：上下文、工具、任务编排、反馈机制和架构护栏。
过去一段时间，大家聊 AI 编程，很容易先问一个问题：哪个模型更强、效果更好？
这个问题当然重要。模型能力决定了上限的一部分。但慢慢的越来越觉得，真正进入项目之后，差距往往不只有这里。
实际开发里更常见的问题，不是 AI 完全不会写代码，而是它写得太快、太散、太不受控。它可以一口气改完很多文件，也可以很自信地告诉你“已经完成”，但你一跑项目，发现约束忘了、边界穿了、测试没过，甚至原本能工作的地方也被顺手改坏了，这时候会有点气急败坏，说 AI 做的一塌糊涂。
在各大 AI 模型崛起的现阶段， 想让 AI 编程效果更好已经不仅仅是模型的选择问题，更多的变成了一个工程问题。
我的判断
AI 编程真正的门槛，正在从“会不会提示模型”转向“能不能搭起一套让 AI 稳定工作的工程系统”。
这个工程系统，就是所谓的 Harness。
它不是某个神秘的新框架，也不是一个必须安装的工具。它更像一套把 AI 管起来、用起来、验证起来的工作方式：让 AI 知道边界，拿到正确上下文，使用合适工具，按阶段执行任务，并且能在反馈里修正自己。
为什么 Harness 会变重要
AI 编程最容易被低估的一点是：AI 越能干，越容易把混乱放大。
一个能力弱的工具，最多是帮不上忙。一个能力强但没有边界的工具，会把错误扩散得很快。
比如你只是想调一下页面样式，它可能顺手重构了整个组件。你只是让它修一个接口问题，它可能同时改了前端、后端、类型定义和缓存逻辑。它不是故意乱来，而是它没有天然理解这个项目的工程边界。
人类开发者在团队里写代码时，并不是只靠“聪明”工作。我们会看需求、看文档、遵守目录规范、跑测试、提 PR、等 Code Review、用 Git 留检查点。这些流程有时显得麻烦，但它们本质上是在控制复杂度。
AI 加入开发之后，这些东西反而更需要。
因为 AI 的执行速度太快了。过去一个人半天才能制造出来的混乱，现在 Agent 可能几分钟就能制造出来。它能帮你省很多时间，也能更快地消耗掉项目的可维护性。
所以 Harness 的价值，不是让 AI 突然变得更聪明，而是让 AI 的产出更可控、更可验证、更能持续迭代。
能力越强的工具，越需要边界和流程。
Harness 不是新技术，而是工程常识的回归
我会认为 AI 领域的很多新名词都来自于旧秩序的新概念，本质上差别不大。
把 Harness Engineering 拆开看，会发现里面很多东西我们早就在做了：
- 用规则文件约束代码风格和架构边界
- 用设计文档同步背景和方案
- 把大需求拆成小任务
- 用自动化测试验证功能
- 用 Linter 和 Review 控制代码质量
- 用 Git 记录稳定节点，方便回滚
这些都不是 AI 时代才出现的发明。它们原本就是软件工程的一部分。
变化在于，以前这些流程主要是给人用的。现在我们要把它们显式地交给 AI，让它成为 Agent 的运行环境。
过去我们可以默认同事知道某些隐含规则。比如这个项目里请求只能走 services，UI 层不能直接碰数据库，公共组件不能塞页面业务逻辑。可 AI 不知道这些默认值，除非我们把这些东西写下来，或者让 AI 能在正确的时机读到。
过去你可以口头提醒同事“这个功能分两步做，先别动支付逻辑”。可 AI 很容易把“顺手一起优化”当成积极表现。如果不把任务边界拆清楚，它就可能按自己的理解扩大改动范围。
所以 Harness 不是在替代软件工程，而是在把软件工程里的隐性经验转成 AI 能执行的显性结构。
AI Coding 不是消灭软件工程，而是把软件工程的重要性重新抬高了。
我认为 Harness 至少包括五层能力
如果只用一句话解释 Harness，可能会显得太抽象。
我更愿意把它拆成五层能力来看。每一层都解决一个具体问题。
上下文架构：不是塞满，而是给对
很多人给 AI 上下文的方式，是把所有资料都丢进去。
这看起来很充分，但未必有效。上下文太长、太杂，关键约束反而会被淹掉。真正有用的上下文架构，不是“把所有东西都塞给 AI”，而是让 AI 在正确时机读正确资料。
比如根目录放一份简短的 AGENTS.md，只写项目概览、核心约束和文档索引。更详细的前端规范、安全规范、接口说明，再拆到 docs/ 里。AI 需要的时候再读对应文件。
这跟我们自己读项目也一样。没人愿意一上来读一本几百页的总文档。更好的方式是先知道地图，再按任务进入具体区域。
执行能力：AI 只会说还不够
如果 AI 只能输出文本，它最多是一个顾问。
要让它真正参与项目，就得给它执行能力。它需要能读文件、改代码、跑命令、查文档、打开浏览器验证结果。再往外扩展，还可以通过 MCP、Skills 这类机制连接数据库、搜索、设计工具或内部系统。
这里的关键不是“工具越多越好”，而是工具要服务于真实任务。
一个能自己跑测试、读报错、再修复的 Agent，和一个只能告诉你“建议你检查一下日志”的聊天助手，不是一个量级的东西。
任务编排：大任务不能一把梭
很多 AI 生成的烂尾项目，不是第一步就错了，而是中途失控了。
刚开始它知道目标，知道约束，也知道技术栈。可任务越做越长，上下文越来越脏，前面的决策慢慢被冲淡。最后代码看起来写了很多，项目却越来越难收拾。
所以大任务一定要拆。
先让 AI 出方案，再确认边界。确认之后分阶段执行，每个阶段只交付一个可验证结果。多个互不依赖的小任务可以并行，但每个任务都要有清楚的输入、输出和完成标准。
这不是为了仪式感，而是为了避免 AI 把复杂任务变成一次不可审查的大提交。
反馈机制：没有验证，“完成了”不可信
AI 说“已经完成”，只能说明它认为自己完成了。
这句话本身没有太高可信度。真正可信的是测试结果、构建结果、浏览器截图、接口返回、日志和验收断言。
所以反馈机制很重要。写完代码之后，AI 应该自己跑 Linter、跑测试、启动项目、打开页面、操作一遍核心流程。失败了，就把错误信息带回上下文里继续修。
这才像一个闭环。
没有反馈机制的 AI 编程，很容易变成“生成代码，然后靠人肉收拾现场”。这当然也能用，但它只是把写代码变快了，没有把交付变稳。
架构护栏：没有边界，项目会变成 demo
AI 很擅长模仿当前仓库里的代码。
这既是优点，也是风险。如果仓库里已经有重复代码、分层混乱、职责不清，AI 往往会继续放大这些问题。它很少天然停下来问一句：这个模块是不是应该抽象一下？这个依赖方向是不是反了？
所以长期项目一定要有架构护栏。
比如 UI 层不能直接访问数据层，业务逻辑不能散落在组件里，公共模块不能依赖具体页面，新增接口必须补类型和测试。这些规则最好能被 Linter、Pre-commit Hook 或 CI 检查到，而不是只靠人提醒。
Git 检查点也属于护栏。每完成一个稳定功能就提交一次，后面如果 AI 改偏了，至少有地方能退。
没有护栏的项目，很容易被 AI 写成一个“当时能跑”的 demo。短期看效率高，长期看维护成本会慢慢反噬回来。
怎么快速上手 Harness
如果把 Harness 讲得太完整，它很容易变成一套很重的工程体系，让人还没开始就觉得麻烦。
但我觉得真正适合个人开发者的做法，不是上来就追求完整，而是先把最关键的几个动作做起来。只要这些动作能进入日常开发流程，Harness 就已经开始生效了。
第一步，是先写一份最小可用的项目规则。
不需要几千字，也不需要把所有背景都塞进去。先写清楚这个项目用什么技术栈、目录怎么分、哪些事情不能做、改完代码要怎么验证。比如 AGENTS.md 或项目规则文件里，先放 50 到 100 行真正稳定的约束，比写一大篇没人读完的说明更有用。
第二步，是让 AI 先计划，再写代码。
只要需求稍微复杂一点，我都不建议直接说“帮我实现”。更稳的方式是先让 AI 看现状、拆任务、说明会改哪些地方，再决定第一步做什么。
这一步的价值不是让流程变慢，而是提前发现 AI 对需求的误解。很多返工，其实都可以在计划阶段被拦下来。
第三步，是给 AI 配上必要工具。
如果它要写前端，就应该能启动项目、打开页面、看报错。如果它要接 API，就应该能读接口文档、跑请求、看返回。如果它要用某个框架，就应该能查到最新文档，而不是靠旧记忆猜。
工具不是装饰品。工具决定了 AI 能不能从“会说”进入“会做”。
第四步，是让每次改动都有验收动作。
最简单的验收也比没有验收强。可以是跑一次 npm run build，可以是跑测试，也可以是打开页面走一遍核心路径。关键是不要把 AI 的“完成了”当成完成标准。
真正的完成，应该来自可执行的反馈。
第五步，是把稳定节点沉淀下来。
一个功能做完，最好有两件事：文档更新和 Git 提交。文档让下一个上下文能接上，Git 让后续改坏时能退回去。
这也是我觉得 Harness 很现实的一点。它并不要求你一次性搭出完美流程，而是让每一次 AI 协作都留下一点可复用的东西。
最小实践
先从规则、计划、工具、验收、检查点这五件事开始。 这套东西不复杂，但能明显降低 AI 把项目越改越乱的概率。
到这里，Harness 就不再只是一个概念了。
它可以很轻：一份规则文件、一次计划确认、一条构建命令、一次 Git 提交。项目越复杂，再逐步加测试、文档索引、MCP、Skills、架构 Linter 和自动化审查。
我的看法是，Harness 不需要一开始就很重，但一定要有意识地开始搭。
未来更值钱的，不是会不会用 AI，而是会不会管 AI
我觉得 AI 编程的能力差距，会分成几个阶段。
第一层，是会不会写 prompt。能不能把需求说清楚，让模型给出还不错的结果。
第二层，是会不会给上下文。知道什么时候该给代码、什么时候该给文档、什么时候该给错误日志，而不是只会反复说“你再检查一下”。
第三层，是会不会设计 AI 的工作流。也就是能不能把一个模糊目标，拆成 AI 可以稳定执行、可以被验证、可以被回滚的工程流程。
越往后，越接近真正的软件工程能力。
这也是我觉得很有意思的地方：AI 看起来在降低写代码门槛，但它并没有降低工程判断的价值。相反，当写代码这件事越来越便宜，判断什么该写、怎么拆、怎么验收、怎么保持长期可维护，就会变得更重要。
未来更值钱的能力，可能不是“我会让 AI 写一个页面”，而是：
- 我能把需求拆成合理的阶段
- 我能判断方案是不是过度设计
- 我能设计清楚模块边界
- 我能定义可执行的验收标准
- 我能让 AI 在错误反馈里持续修正
- 我能控制项目不会因为高速迭代变得不可维护
换句话说，AI 可以替你写很多代码，但不能替你承担工程判断。