^__^ • 5 / 22
Harness 时代，程序员干的事情本质上属于一种元工程：不在工程本身上做加法，在工程的运转环境上做加法。实践过程中，AI翻车的问题基本可以归为五类，每类对应不同的Harness 改进动作。第一类：编码规范违反（Rule + Script） AI用了MessageBox.Show、写了C# 8.0语法、XAML 里出现中文，都属于"有明确对错、可以用正则匹配"的问题。对应的处理方式是Rule 保留核心要点做事前提醒，Script 做事后兜底检测。好处是，流程 Rule 保证 AI 不会忘记要验证（解决注意力衰减的问题），Skill 告诉AI验证怎么操作（封装步骤），Script执行实际的验证（机械化检测）。第二类：操作流程遗漏（Skill） AI改完代码忘了编译、编译完忘了跑测试、或者不知道MSBuild装在哪条路径上。解决方案是封装成 Skill：一个SKILL.md文件描述"做什么、怎么做、看哪个输出文件判断结果"，配一个 .bat脚本做实际执行。AI读完SKILL.md就知道该跑什么命令、去哪看结果。第三类：流程交互混乱（SubAgent 定义）根因是Agent之间的交互规则没定义清楚。修复手段是改SubAgent的定义文档：加回退路由、细化操作流程、明确禁止事项。比如在Code Reviewer的定义里加了"需求实现 Review"维度以后，"主流程做完但边界场景漏了"问题就几乎消失了。第四类：外部能力缺失（MCP 集成）这类问题的解决方式是接入 MCP，通过MCP Server把外部能力暴露给AI。MCP本质上是在扩展AI的"感知范围"，在实际的业务开发中，如果AI拿不到足够的上下文，基本上等于一个聪明的傻福。第五类：系统性的流程缺失（新阶段 / 新 Agent）最少见但影响最大的一类。比如最初没加事后验证，想着编译测试都通过就够了，后来发现并不够，于是加东西。这类问题需要的不是修补现有的某个Rule或Skill，而是往Harness里加一个全新的组件。这个循环跑得越多，系统越健壮。护栏越多，AI能自主完成的任务范围就越大，人需要介入的频率就越低。 Harness这件事本身，其实是一种高度压缩的知识传递。一个资深工程师十年的经验，不可能用一次对话传给AI。但如果这些经验被拆成完善的Rule、Skill、Script检查，AI 就能在秒级时间里"吸收"十年的踩坑经验。如果你想了解更多落地细节，请点击：Harness Engineering实践心得：如何高效驾驭AI？ 各位彦祖亦菲，你们是怎么实践的？欢迎评论区一起讨论，送周边一个。