别再让AI裸写代码了！一套Harness规矩，想全程AI Coding的开发者都能用

“AI Coding 不是拼谁的模型强，也不是拼谁的提示词花，而是拼你有没有把 怎么干活 写成规矩。“

大家是不是经常看到网上有人晒“用AI十分钟写个网页”、“一句话生成个爬虫”，心里痒痒的，恨不得马上把自己手头那个大项目也 丢给AI全程搞定 ？

先别急，前段时间就有朋友找我，说他公司想搞一个“从设计稿到落地”的全程AI Coding实践，领导要求 全程让AI写代码 ，让他总结经验，问我有啥好工具。

我当时没急着推工具，先反问了一句： 你们项目多大？

他愣了一下。因为这里头藏着一个 全网都没人讲明白的真相 —— Harness不是越强越好，小项目别用，大项目必须用。 用错地方，要么白烧token给自己添堵，要么“改一个崩一个，改完项目编译都报错”。

这话不是我拍脑袋想的，是我2025年3月从Vibe Coding一路踩坑、又在 3个项目里实测 出来的真心话。这一年多摸下来，我把踩过的坑和尝到的甜头，全在这篇文章里掏给你。

📌 本文看点

01 Harness不是越强越好

02 自定义手撸胜过一键生成

03 踩一次坑补一条规矩

01 PITFALL

我的翻车史：从“几轮搞定”到“改完编译都报错”

2025年3月，我用Cursor配Claude Sonnet 3.5开始搞Vibe Coding。那时候的感觉怎么说呢？真的 有点上头 。

写个简单的HTML页面、做个小游戏， 几轮对话就完事 ，AI那叫一个听话。我一度以为，编程这事儿被AI拿捏了。

直到我想搞一个 A股智能分析系统 。

那种感觉怎么说呢？就像你雇了个助理，简单活干得漂亮， 一上大项目就原形毕露 。

刚开始我没用任何MD规范，就是纯聊天。聊了很多个回合，开了多轮会话， 框架就是搭不起来 ，更别提后续迭代了。AI的问题很典型：

1 偶尔定位问题不准，方向跑偏；

2 代码越写越乱；

3 改一个崩另一个，改完项目编译都报错。

最折磨人的是第三点。你刚改完A功能，B功能莫名其妙挂了；等你修好B，C又报错。一晚上就在这个“打地鼠”的循环里耗着， 进度卡在原地 。

那一刻真的有点破防。简单页面它“几轮搞定”，复杂系统它 “几轮崩盘” ，落差大得让人想摔键盘。

也正是这次翻车， 逼着我去找出路 。

02 AWAKEN

开窍：从社群文章抄来几份MD

说实话，转机来得挺偶然。在一个社群里，有人分享了一篇Vibe Coding的文章。我照着 抄了几份MD ——prd、dev、rule那套。

神奇的事儿发生了：还是同一个模型，AI的 回复一下子变得规范了 ，考虑也更细了。

「问题不在AI笨，在我没给它规矩。」

其实最早用 rule.md 、 dev.md 、 prd.md 这些文件，就是Harness的雏形。人们就是在一次次翻车里，慢慢打磨出了Harness这套现在的最佳实践。说白了， AI Coding就是面向文档编程。

03 FRAMEWORK

什么是Harness，我为啥只走“自定义手撸”路

Harness是啥？一句话：用外部化的结构约束，替代对模型内在能力的依赖。模型你改不了（那是Anthropic、OpenAI的活），但你能给AI配一套运行环境--规矩、技能、流程、反馈，让它在 可控的框架里干活 。

搭Harness有两条路：

1 捷径：装个Harness Creator skill，让Claude Code照着一键生成；

2 自定义：相当于我们以前手撸源码的过程，自己搭。

说实话，第二条路我一直在走，第一条路我到现在都没用过。原因很简单-- 我想自己掌控细节 。

我的做法是 “用AI治AI” ：

1 先把Harness需要的skill准备好（我是让AI从superpowers skill里挑所需的skill）；

2 下一步让AI搭Harness需要的其他MD文件（你也可以让它直接读阿里那篇深度文章，提取出搭建SOP，再照着搭）。

这背后的逻辑是：既然能让AI干活，那搭Harness这事儿， 也完全可以丢给AI 。

光说不练假把式。拿我 “图个简单”小程序 的搭建过程，给你看看这套方法到底怎么跑。

这是个微信小程序，功能不少，但没测试框架、没CI。我让AI读了本地的Harness落地SOP，它第一件事不是闷头写文件，而是跑去GitHub拉了superpowers仓库当前真实的14个skill清单--不凭记忆， 拿事实说话 。

拉回来之后，AI对照SOP要求的9项技能，逐个判断适配度，最后给我一张表：

📊 映射到 Harness 阶段四的 9 项（含本项目适配判断）

砍掉的那3项特别关键--单元测试、CI验证、CI配置生成。原因很实在：我这项目没测试框架、没CI，照搬TDD那套红绿循环没地方跑，硬上就是 走形式 。

AI自己都点出来了：「无测试基建，照搬会变形式主义。」

这就是自定义比一键生成强的地方： 它会根据你项目的真实情况，告诉你哪些该用、哪些别用。 一键生成的skill可不会管你有没有CI，一股脑全塞给你。

定好范围，AI就开始落文件：8个skill、4份Rules、1个调度大脑Agent，外加变更管理模板，全落在 .harness/ 目录下。关键是，每个skill都不照搬原文，而是锚定我项目的真实结构去改--我这小程序有20个云函数、14个工具函数、30个页面，AI把这些都摸清了，才动手改造成 项目专属的精简SOP 。

最后一步是“通电”：在 CLAUDE.md 里加一节入口指向 .harness/ 。因为 CLAUDE.md 是每次会话必读的文件，加了入口，新会话一开始就知道有套Harness体系要加载。 application-owner.md 写得再好， 不通电也是摆设 。

💡 建议在 CLAUDE.md 末尾加一节，例如：

「AI是干活的工人，我是拍板的老板。」

它拉清单、做映射、写文件， 我审范围、定取舍 。

小技巧： 让AI读阿里文章或本地SOP提炼出可执行流程，比你自己琢磨结构省事太多。它读完直接给你一份能照着干的搭建流程，你只管调细节、拍板砍哪些。

搭完了，效果怎么样？ 拿实测说话 。

04 BENCHMARK

3个项目实测：搭Harness前后，AI判若两人

我在自己迭代的项目里挑了三个 做Harness搭建 ：

图片处理小程序 旅游民宿小程序 游戏站点

先说游戏站的对比， 最有说服力 。

这个项目有个“新增游戏”的流程，我之前已经打磨好了 一套新增游戏的提示词 。

搭Harness之前：

每次新增一款游戏，一般要 2～3轮对话 才能完善好。因为AI偶尔会“部分指令要求的效果没执行”，或者执行了质量不过关。来回扯皮，费时费力。

搭Harness之后：

虽然一开始AI会多跟我对话几次，让我选择确认要执行哪些项，但每一段提示词的细节它都能把握，而且 拆得很细 。

这个项目需要适配的skill和流程细节，都准确实现了。整个过程给人一种“思路条理非常清晰”的感觉，输出效果我很满意。原来2～3轮的扯皮， 现在一轮就到位 。

那种感觉怎么说呢？就像从“骑自行车”到“开跑车”， 不是一个量级 。

小技巧： 搭完Harness第一次跑真实需求时，别急着让它一口气干完。它每次找你确认执行项，你就当是在校准方向，确认得越细，后面出错越少。

05 VERDICT

Harness不是越强越好：小项目别用

聊到这儿，你可能会想：既然Harness这么好，那我 每个项目都搭一个 不就完了？

打住。这正是我想掏心窝说的--Harness不是越强越好。

小项目，在强模型面前， 压根不需要Harness 。就拿现在GLM5.2这种级别的模型来说，简单demo它一句话就给你干完了，你非要套一套Harness上去，那些“看起来很规范”的约束反而会增加token消耗， 纯属给自己添堵 。

那到底怎么判断“该不该用”？我给你一个能截图带走的判断标准，三个条件同时满足，才不用：

代码量小，大概几万行这种级别。

对框架和代码规范要求不高

不用考虑长远迭代维护的项目

反过来，只要你的项目代码量大、要长期迭代、规范要求高，那就 很有必要搭Harness 。这时候不搭， “改一个崩一个”就是你的日常 。

实践出真知，这套判断我是 自己一个个项目试出来的 ，不是看文章背的。

06 EVOLVE

Harness是活文档：踩一次坑，补一条规矩

很多人以为搭完Harness就一劳永逸了，错。Harness是活文档，得随时、及时根据项目实际维护。

机制很简单：某类动作或需求如果多次出错，你就要考虑--是不是Harness里 某些MD描述该更新了 。

还是拿我游戏站 “新增游戏”这个流程 说事。

最早没规范时，AI常在两个地方翻车：

1 游戏配置字段类型不统一--同一个“游戏状态”字段，它这次写成"running"字符串，下次写成数字1，导致后续状态判断逻辑反复出错，查bug查到吐；

2 游戏资源文件命名随意--图片、配置文件有的用驼峰、有的用下划线，部署时路径对不上，页面白屏。

前几次我都是手动改，改完就过去了。后来发现这两类问题反复出现，我就在 .harness/rules/项目编码规范.md 里补了 两条硬规矩 ：

1 游戏状态字段统一用枚举常量，禁止裸字符串、裸数字；

2 所有游戏资源文件命名统一用下划线，路径放在assets/games/{游戏id}/下。

打那以后，AI生成新游戏时， 这两类错再没出现过 。

这就是Harness的生长逻辑--每踩一次坑，就给规矩补一条，让它再也犯不了。Harness就这么越长越壮。

∞ THE END

写在最后：别迷信，也别裸奔

回看从2025年3月裸用AI写页面、到现在 用Harness治AI这一路 ，如果有个刚入门的朋友问我“我也想全程让AI写代码，你给我一句最实在的话”，我会说：

「别迷信Harness，也别裸奔。」

小项目，强模型一句话就给你干完了，套上Harness反而白烧token、给自己添堵；可一旦你的项目大了、要长期迭代了，还不搭Harness，那 “改一个崩一个、改完编译都报错”就是你的日常 。

说到底，AI Coding不是拼谁的模型强、也不是拼谁的提示词花，而是拼你有没有把“怎么干活”写成规矩。

规矩不在你脑子里，也不在聊天记录里，得落到MD文件里-- AI只认文件，不认人 。

这就是Harness的真相：

它不是让AI更聪明，而是让AI的错变得可控。

每踩一次坑，就给规矩补一条，让它再也犯不了--Harness就这么越长越壮。

所以别问“我该不该用Harness”， 先问自己 ：

我的项目，值得我用一份规矩去约束它吗？

想清楚这个，比纠结“该不该用Harness” 实在得多 。

END

我是Archer，热衷于分享 AI 独立开发的实战心得。

如果你也在搞 AI Coding，最想拿 Harness 解决哪个“改一个崩一个”的痛点？欢迎评论区聊聊，咱们一起把规矩补全。

也欢迎关注「AI启蒙学习」，用 AI 陪伴成长，用技术创造价值！

如果这篇文章对你有帮助，点个「分享」，让更多想学AI编程的朋友看到。