一、真正的门槛，从来不在“会不会写代码”
过去很长一段时间，软件开发的门槛主要卡在代码本身：语法、框架、数据库、接口、部署、调试，每一层都需要经验堆出来。现在不一样了。Claude Code、Codex 这类工具出现后，写代码这件事正在被迅速压缩。一个想法，只要描述得足够清楚，AI 很快就能给你搭出页面、写出接口、生成脚本，甚至把一整套功能跑起来。
于是很多人自然会产生一个错觉：既然 AI 能写代码，那是不是人人都能从 0 到 1 做出一个成熟软件产品？
我的答案是：可以更快地做出东西，但不等于可以直接做出产品。这里的差别非常大。
一个小脚本、一个一次性页面、一个临时工具，AI 确实能让你在很短时间内完成。但一个专业成熟的软件产品，背后不是“代码能跑”这么简单。它还包括需求判断、产品边界、技术取舍、数据结构、异常处理、权限设计、交互一致性、可维护性、测试验证、上线策略、迭代节奏，以及出现问题后能不能快速定位和修复。
这些东西，AI 可以参与，但不能替你负责。
这也正是 Harness Engineering 变得重要的原因。
二、AI 是跑车，不是司机
我最近越来越强烈地感受到，AI 编程工具的能力已经像一辆性能极强的跑车：加速快、马力足、响应直接，稍微给一点油门，速度就上来了。
但跑车有一个前提：你得会开。
会开的人，能把它开进赛道，拿下漂亮的成绩；不会开的人，可能刚起步就冲出护栏。车本身没有错，错在驾驶者没有掌握方向、速度和边界。
AI 编程也是一样。它不是一个会自动替你做出好产品的神奇按钮，而是一种被放大后的执行力。你给它清晰目标，它可以狂奔；你给它模糊目标，它也会狂奔，只是可能越跑越偏。
很多人对 Vibecoding 的误解，就出在这里。他们以为“凭感觉描述一下”，AI 就能把一个完整产品做出来。事实上，Vibecoding 更像是一种高密度的人机协作方式，而不是放弃工程判断。你越懂产品、越懂工程、越懂边界，AI 给你的回报越大；你什么都不懂，AI 放大的往往不是你的能力，而是你的混乱。
三、Harness Engineering 的本质：给高速执行力装上控制系统
Harness 这个词很有意思，它既有“马具、缰绳”的意思，也有“利用、驾驭”的意思。放在 AI 编程里，Harness Engineering 可以理解为：围绕 AI 的高速执行能力，建立一套目标、边界、路线、验证和交接机制，让 AI 不只是写代码，而是在可控范围内持续推进项目。
它不是简单地写提示词，也不是多加几条规则。它更像一种工程化的“驾驶系统”。
如果说 AI 是野马，是跑车，是高性能发动机，那么 Harness Engineering 做的是三件事：
- 第一，明确要去哪里。
- 第二，限定不能去哪里。
- 第三，设计一条尽量稳、尽量短、尽量可验证的路线。
这三件事听起来朴素，但几乎决定了 AI 编程的上限。
没有目标，AI 会变成聊天工具；没有边界，AI 会变成事故制造机；没有路线，AI 会变成勤奋但低效的实习生。
四、清晰目标：不要让 AI 猜你的终点
我最近使用 Codex 的一个明显变化，是越来越多地使用它的 /goal 模式，而不是像以前那样一问一答、一步一步慢慢推进。
这个变化很大。过去你需要不断盯着 AI：写一个文件，解释一次；改一个 bug，再确认一次；跑一次测试，再追问一次。整个过程像牵着人走路，你不说下一步，它就停下来。
/goal 模式的价值在于，你可以把一个更完整的目标交给它，让它围绕目标长期推进，直到完成或遇到阻塞再停下。这样一来，人从“逐条指挥”变成了“定义目标、审核&查验结果、修正方向”。
这听起来只是一个交互方式的变化，但背后其实是工作方式的变化。
当 AI 具备持续执行能力后，最重要的就不再是“下一句提示词怎么写”，而是“目标本身是否清楚”。
一个好的目标，至少应该包含这些信息：
- 要解决什么问题，而不只是要实现什么功能。
- 最终交付物是什么，是页面、接口、脚本、测试，还是完整模块。
- 完成标准是什么，什么情况下可以认为任务结束。
- 哪些地方必须保持不变，哪些地方允许重构。
- 遇到不确定情况时，应该优先保守处理，还是大胆推进。
很多 AI 编程失败，不是 AI 不够聪明，而是人没有给出一个可以被执行的目标。你说“帮我优化一下项目”，它当然不知道优化到什么程度算完；你说“帮我做一个后台系统”，它也不知道后台系统的权限、数据、流程、风格和边界应该是什么。
目标越模糊，AI 越容易用“看起来合理”的方式填空。而成熟产品最怕的，恰恰就是这种看起来合理。
五、严格边界：真正救命的不是提示词，而是护栏
如果只给目标不给边界，AI 就像一辆没有护栏的快车。它也许能开到终点，但一路上可能拆了不该拆的东西，改了不该改的文件，引入了不该引入的依赖，还顺手把原来稳定的逻辑变得面目全非。
所以 Harness Engineering 的第二个核心，是边界。
边界不是一句“不要乱改”。这种话对 AI 来说太虚。真正有用的边界应该具体到项目规则里，比如：
- 只能修改哪些目录，哪些目录禁止触碰。
- 新增依赖必须说明理由，不能为了省事随便引包。
- 接口返回结构不能破坏兼容性。
- 数据库字段不能随意重命名。
- UI 组件必须遵守既有设计规范。
- 每次完成后必须运行指定测试或检查命令。
- 涉及删除、迁移、重构时必须先给计划，再执行。
这类边界就像四驱车的轨道。车可以跑得很快，但必须在轨道里跑。轨道设计得越好，AI 的速度越能释放；轨道越模糊，速度越快越危险。
很多人想让 AI “更聪明”，但在实际项目里，更重要的是让 AI “更受控”。
聪明但不受控，是风险；受控之后的聪明，才是生产力。
六、路线规划：不是让 AI 动手，而是先让 AI 想清楚怎么动手
从 A 点到 B 点，永远不止一条路。
做一个功能，可以先写前端再补接口，也可以先设计数据模型再写页面；可以快速堆出来，也可以先抽象组件；可以引入现成库，也可以基于现有代码扩展。AI 往往会选择一条它最容易生成的路，但这条路未必是最适合项目的路。
所以在真正让 AI 执行之前，我越来越习惯先让它做路线规划。
比如先讨论：
- 这个需求应该放在现有哪个模块里，而不是新建一套重复结构。
- 前端状态应该放本地、URL、服务端，还是全局 store。
- 接口设计应该兼容旧版本，还是可以直接升级。
- 哪些部分可以一次完成，哪些部分应该分阶段上线。
- 哪些测试最关键，哪些边缘场景必须覆盖。
路线规划不是拖慢速度，而是避免后面返工。
真正专业的开发，不是写得最快，而是少走错路。AI 让“写代码”变快了，但如果路线错了，返工也会变快，混乱也会变快，技术债也会变快。
这就是为什么越是使用 AI，越要重视前置设计。
七、AI 可以帮你写代码，但产品判断仍然属于你
这里有一个很容易被忽略的点：AI 编程工具擅长的是实现，不擅长的是取舍。
它可以帮你把按钮做出来，但它不知道这个按钮到底该不该存在；它可以帮你写完整的设置页，但它不知道用户是不是真的需要这些设置；它可以帮你加很多功能，但它不会天然理解一个产品应该保持克制。
软件产品最难的部分，往往不是“能不能做”，而是“该不该做”。
成熟产品不是功能越多越好，而是每一个功能都服务于清晰的用户场景。很多项目越做越臃肿，就是因为执行力太强，而判断力跟不上。AI 出现后，这个问题会更明显：以前加一个功能很麻烦，所以人会犹豫；现在加一个功能太容易，所以人更容易失控。
这时候，产品判断反而更珍贵。
你要知道用户是谁，核心场景是什么，第一版本应该砍掉什么，哪些需求只是看起来高级，哪些细节才真正影响体验。AI 可以参与讨论，可以帮你提出方案，但最后拍板的人必须是你。
把方向盘交给 AI，是偷懒；用 AI 放大自己的判断，才是能力。
八、我理解的最佳实践：先建系统，再让 AI 狂奔
如果要把 Harness Engineering 落到实际工作里，我认为可以从五个层面开始。
1. 写一份项目宪法
每个长期项目都应该有一份清晰的工程约束文档。它不一定很长，但要能回答几个关键问题：这个项目的目标是什么，技术栈是什么，代码风格是什么，目录边界是什么，禁止事项是什么，完成任务前必须做什么检查。
这份文档不是写给人看的门面，而是写给 AI 执行的轨道。
2. 把任务拆成可验证目标
不要把“做一个成熟系统”直接丢给 AI。应该拆成一个个可验证的目标：先完成登录流程，再完成权限校验；先完成核心数据模型，再完成列表页；先保证主链路跑通，再补充边缘场景。
AI 适合冲刺，但不适合在迷雾里奔跑。
3. 每次执行前先要计划
在复杂任务里，不要一上来就让 AI 改代码。先让它读项目、理解现状、给出修改计划、列出影响范围，再决定是否执行。很多事故都能在计划阶段被提前发现。
尤其是数据库、权限、支付、用户数据、核心业务流程这些地方，必须先计划再行动。
4. 把验证写进流程，而不是靠人肉检查
AI 写完代码后，最危险的一句话是：“应该可以了。”
成熟的流程应该要求它运行测试、类型检查、构建命令、关键路径验证，必要时还要补测试用例。没有验证的完成，只是表面完成。
AI 会犯错，但验证系统能把很多错误挡在上线前。
5. 保持小步提交和可回滚
越是让 AI 长时间执行，越要保持可回滚。一次任务不要混入太多不相关修改，不要把重构、功能、样式、依赖升级搅在一起。每一步都应该知道改了什么，为什么改，出了问题能退回哪里。
这不是保守，而是专业。
九、未来的差距，会从“会不会写代码”变成“会不会驾驭系统”
AI 大模型越强，软件开发的门槛表面上会越来越低，但真正的专业门槛并不会消失，只会转移。
过去的差距是：谁更会写代码。
现在的差距正在变成：谁更会定义目标，谁更会设计边界，谁更会规划路线，谁更会验证结果，谁更会把 AI 的能力纳入一个稳定的工程系统。
这就是 Harness Engineering 的价值。
它不是一个时髦概念，而是 AI 编程进入深水区之后必然出现的方法论。因为当执行力变得廉价，判断力、约束力和系统设计能力就会变得更贵。
未来并不是“不会技术的人也能轻松做出专业产品”，而是“懂产品、懂工程、懂协作的人，会因为 AI 获得更大的杠杆”。
AI 可以是一匹烈马，也可以是一辆跑车。它能带你跑得很远，也能让你翻车得很快。
关键不在于马有多烈、车有多快，而在于你有没有缰绳，有没有赛道，有没有路线图。
这就是我现在越来越重视 Harness Engineering 的原因：不是为了限制 AI，而是为了真正释放 AI。
评论