从零开始独立开发AI产品的过程中，作者发现单纯依靠AI生成代码的效率远低于预期。直到接触到Harness Engineering理念后，通过建立系统化的开发框架——包括项目手册、任务规格和权限体系——将AI代码贡献率从30%提升至90%。这一实践不仅揭示了AI辅助开发的核心方法论，更为产品经理设计AI产品提供了全新视角：关键在于构建让AI'知道自己要做什么'的环境体系。

今年年初从公司离职之后，我开始自己做项目。一个体育AI平台、一个黑胶唱片收藏小程序，都是从零开始。没有研发团队了，就我一个人，设计、开发、测试全包。

我不是程序员出身。做了三年AI产品经理，PRD写了一堆，代码真正自己动手写的很少。离职之后决定试试用AI辅助开发，毕竟天天给别人设计AI产品，也该自己吃一下狗粮了。

刚开始那段时间挺痛苦的。打开Cursor，跟Claude说”帮我写一个唱片收藏页面”，它刷刷刷生成一大坨代码，看着像那么回事。一跑，页面出来了但数据没存进去。补一句”数据要存到数据库”，它又生成一版，这次数据存了但字段对不上。再补一句”字段用这个Schema”，它改了，但把之前写好的样式搞丢了。改来改去，一个下午过去了，一个页面还没弄完。

体感上，我大概有30%的代码是AI写的，剩下70%要么是自己写的，要么是AI写了之后我改得面目全非的。跟那些”AI帮我一天做了一个App”的说法差距太大了。我一度怀疑是不是自己太菜。

转折发生在三月底。我在社区里看到有人聊一个概念：**Harness Engineering**。

这个词最早是Mitchell Hashimoto在2026年2月提出来的，然后OpenAI发了那个百万行代码实验报告也用了这个词，一下子就火了。社区里有人基于Claude Code的源码写了本书叫《驾驭工程》，把这套理念拆得很细。Claude Code的官方说法是：Claude Code serves as the agentic harness around Claude——它提供工具、上下文管理和执行环境，把一个语言模型变成一个能干活的编码Agent。

harness这个词特别形象。套在马身上的那整套装备——缰绳、嚼子、胸带——就叫harness。不是让马跑得更快，是让马往你想让它去的方向跑，同时确保你不会摔下来。

我看了一晚上相关的东西，有点坐不住了。突然意识到自己之前的问题不是AI不够聪明，是我从来没给AI搭过一套像样的harness。说白了就是：我一直在换马，没想过换缰绳。

然后我拿黑胶唱片小程序这个项目做了个实验。花了一周时间，用Harness Engineering的思路重新来过。

先说我之前的工作方式。打开Claude Code或者Cursor，直接跟它说”帮我做收藏管理功能”。它开始写，写完我看一眼，发现不对——它把唱片字段设计成了五六个通用字段，但我的Schema有二十多个专业字段：厂牌、版次、母带编号、压片国家这些。AI不知道这些，它只能猜。补一句纠正，它改了这里又漏了那里。一来一回，半小时过去了，生成了三四个版本，最后可能还是得我自己上手改一半。

问题出在哪？AI根本不知道它在干什么。它不知道这个项目是给黑胶唱片爱好者做的、不知道字段结构长什么样、不知道标签体系有风格/厂牌/年代/版本四个维度、不知道前端用的什么框架。它每一轮只能看到你当下给它的那一小块上下文，相当于蒙着眼在一个陌生的房子里摸索。你说”往左走”，它走了，但它不知道左边是墙还是门。

Harness Engineering解决的就是这个问题：你不用每次都告诉AI该怎么做，你把”该怎么做”写进环境里，让它随时能自己查到。

我做的第一件事是写CLAUDE.md。

这个文件是Claude Code的一个机制——放在项目根目录下，AI每次启动都会自动读取。相当于你给它一份”工作手册”。我在里面写了：这是一个微信小程序，给黑胶唱片爱好者做收藏管理的；技术栈是什么；目录结构长什么样；唱片数据的完整Schema（20多个字段每个是什么意思）；标签体系怎么分层；四个核心功能模块（收藏、愿望清单、标签筛选、花费统计）之间怎么联动；UI风格参考；以及最重要的——哪些东西不能动，比如数据库的Schema结构一旦定了就不许AI自作主张改。

写这个文件花了我大半天。很烦。这些东西平时都在我脑子里——调研了8个黑胶爱好者得来的需求、竞品分析的结论、我自己作为收藏者的使用习惯——逼自己把它们全部结构化地写出来比想象中难。

但写完之后效果立竿见影。AI开始生成代码的时候，不再瞎猜了。它知道这是微信小程序不是H5网页，知道唱片有”首版””再版””限量版”的区分，知道标签筛选要支持多维交叉，知道花费统计要按币种分。这些事情以前每次对话都得说一遍或者等它写错了再纠正，现在它直接就知道了。

第二件事是拆任务的方式变了。

以前我会直接说”帮我做收藏管理功能”，这是一个大任务。AI接到这种大任务，会试图一口气搞定，然后在中间某个地方翻车。Harness Engineering的做法是：写spec。就是开始干活之前先写一份简单的任务规格——目标是什么、边界是什么、验收标准是什么、依赖什么、不能改什么。

我后来养成了一个习惯：每个稍微复杂一点的功能，先花五分钟写一个spec。这五分钟绝对不是浪费。因为spec写清楚了，AI一次成功率极高；spec没写清楚，AI生成三四版还在原地打转。

有一次我偷懒没写spec，直接让它做标签筛选功能。它做完之后我一看——把标签设计成了扁平的单层结构，所有标签混在一起。但我的设计是四维分层的：风格标签、厂牌标签、年代标签、版本标签，互相独立，支持交叉筛选。AI不知道这个设计意图，它按自己的理解做了一个”够用”的方案。如果我在spec里写一句”标签四维分层，参考CLAUDE.md中标签体系定义”，这个返工根本不会发生。五分钟省两小时，这笔账太划算了。

第三件事是利用好工具链。

Claude Code不只是一个生成文本的模型，它有一堆工具——能读文件、写文件、搜代码、跑命令。Harness Engineering里有个观点：Agent的能力取决于你给它配了什么工具，以及它在什么时候用什么工具。

我在CLAUDE.md里加了一条：”开始任何改动之前，先读取现有相关文件确认当前状态。”就这一句话，AI的行为就变了。它不再上来就动手写新代码，而是先读一遍已有的代码看看现状，搞清楚上下文再动手。这个工作流任何有经验的开发者都知道该这么做，但如果你不告诉AI，它真的不会主动做——它会直接开写，然后跟已有代码冲突。

还有一个很实用的规则：让AI每次改完代码自己做一轮检查。我写了一条”完成修改后检查是否引入了硬编码值或TODO”。这是我之前的痛点——AI为了让代码跑通，经常会塞一个hardcoded的配置进去，比如直接把我的测试用唱片数据写死在代码里。你不仔细看根本发现不了。

第四件事，也是我觉得影响最大的：分清楚哪些事让AI自己跑，哪些事自己盯。

Claude Code有一个设计叫权限系统——哪些操作AI可以自己做，哪些需要人确认。Harness Engineering的理念是：不是所有任务都需要同等程度的监督。写一个展示组件和设计数据库Schema，风险完全不一样。

我把工作分成了三档。低风险的——列表页面、详情页面、简单的UI组件——让AI直接跑，我不一个个看。中等风险的——数据存取逻辑、标签筛选算法、统计计算——AI写完我review一遍。高风险的——Schema设计、数据迁移、核心交互逻辑——我自己主导，AI辅助。

以前我的瓶颈不是AI写得慢，是我看得慢——AI每生成一段代码我都逐行对，因为不确定它会不会在某个不起眼的地方埋雷。分级之后，低风险的跳过，精力集中在高风险的部分。一天能推进的工作量翻了不止一倍。

一周下来体感是这样的：前两天几乎没有代码产出，全在搭harness——写CLAUDE.md、定spec模板、配规则。第三天开始干活，效率立刻就不一样了。到第五天已经进入一种节奏：我把功能拆成一个个明确的包，扔给AI，它去做，我来验收。大部分一次过，偶尔要调整，但很少需要推翻重来。

后面两天在做一些边边角角的体验优化，我突然有一种挺奇妙的感觉——我好像不是在”写代码”了，是在”管理一个写代码的Agent”。我的工作从”实现”变成了”设计”和”验收”。对一个产品经理出身的人来说，这个状态其实反而更自然。

这个体验让我想到一件事。

我之前在公司做企业AI产品的时候，花了很多时间想怎么让AI输出更好——调提示词、优化知识库、升级模型。但Harness Engineering给了我一个完全不同的视角：与其让模型更聪明，不如让模型”知道自己在干什么”。一个知道项目结构、知道数据Schema、知道任务边界的”普通”模型，比一个什么都不知道的”强”模型有用得多。

这不就是我之前做企业AI产品时一直在解决的同一个问题嘛？只不过换了个场景。

在AI Coding里，harness是CLAUDE.md、spec和工具链规则。在企业AI产品里，harness是领域知识库、工作流引擎和人机协作界面。做合同审核产品的时候，我给AI搭的那套——分章节生成、溯源标注、人工复核节点——本质上就是一套产品级的harness。当时不知道这个词，但干的事是一样的。

所以我现在越来越觉得，Harness Engineering不只是一个开发者的话题。它对产品经理也有实际意义。

你设计任何一个AI产品，都要回答几个问题：AI知不知道用户的业务上下文？AI知不知道什么叫”做对了”？AI有没有手段验证自己的输出？哪些环节AI可以自主决策、哪些必须人来确认？这些问题的答案加起来，就是你这个产品的harness。

现在我做新项目的第一件事，不是打开编辑器开始写代码，是先花半天把CLAUDE.md写好。这个文件写得越清楚，后面AI的”自主率”就越高。前两天看起来没在”干活”的准备工作，恰恰是整个项目里杠杆率最高的投入。

当然了，90%这个数字有点讨巧。UI组件、列表页面这种可能95%以上是AI写的，核心的筛选逻辑和数据结构设计可能只有50%。平均下来是个大致的感觉，不是精确统计。而且我这个项目功能比较明确——之前做了完整的用户调研和产品设计，AI只需要”实现”不需要”想”，这会让AI Coding率偏高一些。

但不管怎么说，从30%到90%，中间的差距不是模型升级带来的——用的是同一个Claude。差距全在harness上。

如果你现在也在用AI写代码但感觉效率卡在一个瓶颈上，先别急着换模型或者学更高级的提示词技巧。先看看你的harness——你的CLAUDE.md写了没有？任务拆分清晰吗？你有没有在让AI”蒙着眼睛干活”？

我之前做产品经理的时候，给新人培训永远会说一句话：需求文档写不清楚，研发写出来的东西一定不是你想要的。现在用AI写代码，道理完全一样。CLAUDE.md写不清楚，AI写出来的代码一定不是你想要的。区别只是以前面对的是一个会反问你的研发，现在面对的是一个不会反问你但会自己瞎猜的Agent。所以harness反而更重要了。