你有没有过这种经历刚用上 AI 写代码的时候爽到飞起 —— 输入一句话几百行代码就出来了原来要写一天的功能俩小时就搞定了。结果没过多久你就发现不对了 项目越做越大AI 开始 “忘事”第一天用user\_id第三天突然改成uid AI 写的代码架构乱得一批这个功能用这个库那个功能用那个库后来要改底层整个项目都得重写 改一个 bugAI 给你冒出俩新的到最后你发现AI 写的垃圾代码你重写都比改它快。这就是现在大家都在说的 “Vibe Coding”—— 开局爽到爆中期乱成麻后期直接崩。直到我们把 Harness Engineering 这套规范落地到团队才发现原来 AI 不是不能用在团队项目里你只是没给它套上 “缰绳”。Vibe Coding 的陷阱爽是爽就是越写越乱没约束的 AI Coding就像你开着一辆没有方向盘、没有刹车的超跑。一开始你爽疯了百公里加速 2 秒风在耳边呼啸你觉得自己开到了全世界最快。但是开着开着你就慌了路有点弯你控不住方向前面有个坑你踩不住刹车 —— 你只想着快却忘了快的前提是你能控得住。我们团队一开始也是这样 小脚本用 AI没问题又快又好 但是一上团队项目问题全出来了架构混乱AI 为了省事什么库都敢用好好的分层架构被它搞成了一锅粥上下文雪崩项目超过 50 个文件AI 就开始忘事改着改着就把之前的规则忘了可维护性为 0AI 写的代码只有它自己懂我们接手的时候看几千行垃圾代码还不如重写这时候我们才明白AI 的能力本身从来都不是问题。问题是你怎么让它的能力变成团队可控的生产力而不是脱缰的野马。nullHarness这个词本来是马术里的词——就是马具缰绳、马鞍、马镫。一匹没驯服的野马力量超大但是你没法让它耕地、拉货、上战场它只会乱跑。 但是你给它套上 harness 之后它的力量就变成了你的生产力 —— 你让它往哪走它就往哪走你让它拉多少它就拉多少。AI 也是一样的LLM 模型本身就是那匹野马它有超强的智能但是它没有状态、没有工具、没有记忆它不知道你的业务规则不知道你的团队规范它只会乱跑。 而 Harness Engineering就是给 AI 套上的马具 —— 给它装上手脚、装上记忆、装上规则让它的智能变成你团队可控的生产力。OpenAI 早就验证过这个方法他们一个 7 个人的小团队完全禁止手写代码只用 AI5 个月写了超过 100 万行代码合并了 1500 个 PR效率直接翻了 10 倍。靠的就是 Harness不是让 AI 瞎写而是给它套上约束让它在规则里干活。6大支柱把AI的能力锁在笼子里很多人觉得Harness就是写几个规则约束AI太简单了。其实不是它是一整套完整的体系靠6大支柱把AI从一个“什么都懂一点的通用模型”变成“懂你业务、守你规则的团队专属开发助手”。这就像你带一个新人 你不能只扔给他一堆代码就让他干活你得告诉他项目的上下文什么能做什么不能做给他配好工具让他能碰数据库、看文档给他定好流程让他按步骤来别乱来让他记住项目的规则别干两天就忘了检查他的工作看看有没有做错的给他划好红线做错了能及时拉回来Harness 的 6 大支柱干的就是这个事1. 上下文管理别让 AI 忘事AI 的上下文窗口有限还贵你不能把几千行的规范一次性丢给它。 我们的做法是做分层的文档写个 100 行的AGENTS\.md当目录告诉 AI 项目的基本情况细分的规范、架构拆成单独的文件AI 需要的时候自己去看把团队的 Wiki、业务文档都挂载成知识库AI 随时能调 就像你给新人一个目录告诉他要查什么去哪找不用一次性把所有东西都塞给他脑子。2. 工具系统让 AI 能触到真实世界原来的 AI只能看你给它的代码碰不到你的数据库看不到你的接口文档所以它经常瞎写。 现在我们用 MCP给 AI 装上“触手”让它能实时读数据库的 Schema再也不会写不存在的字段读你的 Wiki 文档懂你的业务术语读接口定义微服务联调的时候不会写错参数 还有 Skills把我们团队的专家经验打包进去比如怎么接我们的配置中心怎么写符合我们规范的 CRUD让 AI 从 “通用模型”变成 “懂我们业务的专家”。3. 执行编排让 AI 按步骤来别乱来原来的 AI拿到需求就直接写代码经常写着写着就偏了。 现在我们定了 “31 Phase” 的流程先计划AI 先把需求拆解成结构化的方案你审核过了再动手再编码AI 按方案写代码再验收AI 自己先检查一遍合不合规范能不能跑最后归档把这次的需求存起来更新知识库 就像你带新人先让他写方案你看完没问题再让他动手最后做完了把经验存起来下次就会了。4. 状态与记忆让 AI 跨会话也能记住原来的 AI聊完天就忘了下次你再找它它又得重新问一遍项目的情况。 现在我们把记忆存起来短期的当前会话的上下文中期的跨会话的AI 记住你的编码习惯长期的存在 Git 里的 Spec 文件项目整个生命周期都不会忘 就像新人来了我们把项目的经验都存起来他什么时候来都能拿到最新的信息不用每次都重新问。5. 评估与观察检查 AI 写的东西对不对AI 写的东西不能直接用得检查。 我们做了四层检查语法能不能编译过Lint 过了没逻辑单元测试过了没规范有没有符合我们的团队规则架构有没有破坏原来的设计 就像新人写完代码你得给他做 Code Review看看有没有错有没有符合规范。6. 约束与恢复给 AI 划红线错了能拉回来最后给 AI 划好红线什么能做什么不能做硬性红线比如 Controller 不能写业务逻辑所有查询必须走 Repository软性约束比如优先用我们已有的工具类安全策略比如改数据库之前先备份高风险操作要确认 而且所有的变更都存在 Git 里做错了随时能回滚就像你给新人定规矩做错了没关系我们能改回来。3阶段落地团队照着做就行不用一步到位很多团队一听这么复杂是不是要搞很久完全不用我们把落地拆成了 3 个阶段一步步来不用一步到位第一阶段基础建设1-2周先把最基础的搞定让所有人装上 AI Coding 工具配好基础的配置建团队的规范仓库把基础的 Rules、模板放进去配好基础的知识库让 AI 能拿到团队的文档 这个阶段你只要花 1-2 周就能让所有人先把工具用起来有最基础的约束不会乱来了。第二阶段工具接入2-4 周基础搞定了再搞深度集成接入 MCP让 AI 能碰数据库、工蜂、TAPD 这些沉淀 Skills把团队的专家经验打包进去跑通 Spec 驱动的开发流程先写方案再写代码 这个阶段你就能让 AI 真正懂你的业务能帮你干更多的活了。第三阶段持续优化长期最后就是持续迭代做知识飞轮建度量看板看看 AI 用的怎么样Bug 率有没有降效率有没有升定期更新 Rules 和 Skills把新的经验沉淀进去让知识库自己迭代越用越聪明 就像你开车先学会怎么开再学会怎么开好最后越开越熟练越来越快。用了这套规范团队到底爽在哪落地了这套规范之后整个团队的变化真的太大了。原来我们做一个功能要花 6 小时 1 小时写代码3 小时改 bug2 小时写规范、对齐标准。 现在呢同样的功能只要 1 小时 AI 帮你写代码帮你检查规范你只要审核一下就搞定了咖啡还没凉。对个人来说你不用再反复跟 AI 解释项目的规则不用再改 AI 写的垃圾代码AI 写完的东西拿来就能用你只要管最核心的设计就行效率直接翻了好几番。对团队来说所有人的代码风格都统一了架构都一致了再也不会出现 “这个人写的代码那个人看不懂” 的情况新人来了照着规范配置一下一天就能上手不用你天天带。对项目来说再也不会出现 “项目越做越乱最后重写” 的情况所有的经验都沉淀下来了项目越大AI 越聪明而不是越蠢。别踩这些坑团队用 AI 最容易犯的 8 个错最后给大家提个醒我们踩过的这 8 个坑你千万别再踩了巨型 Prompt别一次性把几千字的需求丢给 AI先拆解先写 Spec一步步来跳过审核直接编码别觉得需求简单就不写方案直接让 AI 写代码半天以上的需求一定要走 Plan 模式Rules 写了不维护Rules 写完就放那不管半年后就和实际规范脱节了定期 Review 更新MCP 过度接入别什么 MCP 都接接一堆没用的Token 消耗暴增只接你真的需要的Skill 不原子化别一个 Skill 塞一堆功能一个 Skill 就解决一类问题这样 AI 才会用盲目信任 AI 输出别 AI 写的代码你看都不看就合入所有的代码必须经过人工 ReviewChat 历史当文档别把需求都存在聊天记录里需求和决策一定要存到 Spec 文件里持久化一个 PR 改所有别让 AI 一次性改一堆不相关的功能一个 PR 就解决一个问题好查好改最后想说的话AI Coding 不是洪水猛兽也不是万能的银弹。它是一匹超强的野马你要是不给它套上缰绳它只会带着你乱跑最后撞得头破血流但是你给它套上 harness它就能拉着你跑得比谁都快。我们做这套规范的目的从来都不是束缚大家而是给大家一个共同的底线让 AI 真正变成团队的生产力倍增器而不是麻烦制造者。毕竟我们要的从来都不是 “写代码快”我们要的是 “写好代码稳而且快”。 聊聊你的经历 你团队用 AI Coding 的时候有没有遇到过 “越写越乱” 的情况是怎么解决的评论区聊聊你的经历
