AI 编程助手又“翻车”了？是时候给它套个“脚手架” (Harness) 了
过去这一年，大家都用上了各种 AI 编程助手（Cursor, GitHub Copilot Workspace, 各种 CLI Agent 等等）。说实话，刚开始用的时候真的觉得“这就是未来”，写个单测、写个小脚本、查查 API，简直不要太爽。
但是，蜜月期一过，大家应该都发现了：这玩意儿好像处理不了复杂业务啊？
只要需求涉及到跨好几个模块，或者代码仓库有点历史包袱，AI 就很容易开始“发癫”。今天就想和大家聊聊，为什么我们在让 AI 写复杂代码时总是一地鸡毛，以及我为了不被 AI 气死，是怎么倒腾出一个开源的“防翻车”框架的。
吐槽大会：为什么 AI 总是越写越乱？
我们在实操中经常被 AI 坑的点，其实总结下来就那么三个。这背后的原因还真不全是因为大模型变“笨”了，主要是工程化约束没跟上。
1. 让人头疼的“金鱼记忆” (上下文漂移)
刚开始丢需求进去，AI 分析得头头是道，俨然一个资深架构师。结果聊了二十个回合之后，它就开始放飞自我了。它能把前十分钟刚说过的变量名又改回去，或者莫名其妙引入一个完全不需要的新库。
2. 野马脱缰式改代码 (需求范围膨胀)
有时候你只是想让它修一个输入框边界条件的小 Bug。好家伙，它觉得你原来的底层类写得不够优雅，顺手给你来了一波大重构。结果引发了一连串的类型报错，为了修这些报错，它又开始修改更多的文件……最后修了一个小 Bug，制造了十个大 Bug。
3. “不懂规矩”的职场新人 (隐藏约束丢失)
每个团队多少都有点“潜规则”：比如业务逻辑绝对不能写在视图层，跨服务调用必须经过某个特定的网关。这种东西往往没有写在明面上，但大家都心照不宣。AI 作为一个刚来的“新人”，看到局部代码，就只会写出看起来很标准、但实际上完全不符合你们团队规矩的代码。
怎么治？别光聊天了，上“规矩”吧
想让 AI 真正在复杂项目里干活，我们就不能再像以前那样，打开个聊天框就开始“念咒语”了。指望 AI 在几万字的聊天记录里把各种约束记得清清楚楚，是不现实的。
我们得给 AI 套上一个 Harness（脚手架/安全带） 。一句话总结就是：把你们团队的规矩、上下文和工作流程，全都老老实实写到文件里。
- 规矩写在纸上： 把不能碰的边界写成文件，强制 AI 每次改代码前先读一遍“员工手册”。
- 留存知识，而不是索引代码： 建立专门的架构文档记录设计思路。
- 关键节点强制打卡 (Review Gates)： 绝不让它一口气瞎写，每写完一小步必须等你确认。
我的应对之策：Universal AI Harness Framework
为了让这套流程能轻松在各个项目里用起来，我开源了这个框架： GitHub 地址： pandaria75/universal-ai-harness-framework
这不是教你写某一种业务，也不是绑定某个大模型的插件。它就是一个极其轻量级的文件框架，可以装进你现有的任何项目里。
这东西能干嘛？
-
自带“员工培训手册” (Skills & Rules)： 内置
AGENTS.md和好用的 Agent Skills（比如教它怎么拆解任务的implementation-slicer）。AI 读到它们，瞬间就知道该怎么守规矩地干活了。 -
把大任务切得细碎 (Context Pack)： 遇到复杂任务，逼着 AI 先生成
.task/context-pack.md，把任务拆成极小的切片。每次只改那一小块，坚决防止乱改。 -
一个听话的 CLI 工具：
harness init：一键初始化规则文档。harness sync：框架升级时，一键同步核心规则，且绝对不会覆盖你团队辛辛苦苦写的本地业务文档。
实际用起来啥感觉？
装了 Harness 之后，你和 AI 结对编程的画风就变了：丢个大需求过去，AI 第一反应不是马上生成代码，而是调起 task-intake 技能，盘清楚需求并给出分步实施计划。在你的允许下，它开始写第一步代码。写完这一步立刻停下进行边界审查，问你：“大哥，你看这步改得行不行？行的话我再往下走。”
这大半年折腾下来，最大的感触是：大模型越强，破坏力也越大。给它套上这个 Harness，其实就是为了让它在咱们划好的、安全可控的道上飙车。
如果大家平时也被 AI 的“放飞自我”气到过，或者对怎么管好这帮“赛博牛马”有点想法，非常欢迎来 Repo 里逛逛，提提意见，顺手点个 Star ⭐️ 鼓励一下！
