工作和生活里，遇到问题先问AI，已经成了习惯，但它默认给出的回复，质量可能不符合预期，很多回答根本不是在说人话，可读性非常差，什么A3B4C5D6，还有一大堆简写，看起来跟汇编代码一样。从AI的角度可以强行解析，但人根本没法判断。在先前的文章里，笔者也聊过Agent和Skill工程化的一些思考，但是面向通用的问答场景，还是无法系统性解决。
所以，今天这篇文章，提出一类系统性解决这类问题，并且保证AI工程可持续迭代的方法，那就是构建一套自己专属的AI Native Harness。AI回复的内容，与其回一段汇编代码，还不如一直闷头执行下去。靠换一个更强的模型，或者多写几句prompt，很难系统性解决。只有构建一套自己的AI Native Harness，把日常的经验、规则、资料和工具沉淀下来，才能够让AI的交付成果符合自己的预期。
首先，为什么要这么做。我们分一下日常对话的场景，日常和AI对话，本质上都是一次性的，每次都要把背景、约束、要求重新讲一遍，这个时候我们可能会想，有memory或者rules可以记住这些事情。但是，memory解决的是记住的问题，不是组织的问题，记住不等于会用。memory越积越多，最后还是一堆零散的碎片，换个工具、换台机器，之前攒的东西就归零，当年踩过的坑，还得再踩一遍。
那么不妨把这件事情工程化，让AI在一个稳定的环境里工作，通过构建harness，决定AI的工作环境，保障AI产出的下限。具体harness的方式，其实有一个私有repo就够了。repo本身一是适合迁移，换机器clone下来就能用；二是可执行，AI工程的第一要义是可执行性，有一个固定的repo，把可执行的东西全部往里放，那么得到具体任务的时候，AI一分析就知道需要引用repo里面哪些资源，就知道该怎么做。用两句话表示，就是repo AS skill，commit AS checkpoint。
对于这件事情，可以换一种角度想。传统的方式，是把每个SKILL都当成独立的东西，SKILL少的时候还行，一多就维护不过来了。很多reference和脚本是可以复用的，每个SKILL都复制一份，维护成本只会更高。而且SKILL越原子化，AI越难发现它们之间的关联。更好的方式，是把SKILL都放到harness仓库里。每个SKILL还是独立模块，但公共的参考资料、脚本、知识放在仓库里共享。AI自己去仓库里找，要细节就读reference，要执行就调脚本。从这点来看，单纯的积累SKILL已经无法满足复杂工作场景的需要，怎么把这些知识资源做更好的整合，才是harness的关键。
之后就是怎么保障AI的回复质量，笔者的做法是强化AI做交流和汇报的规范。像deepseek-v4.1-flash-1017这类模型，长程任务的完成能力已经不错了，但在业务私域知识和交流汇报方面，能力非常薄弱。单个任务完成度可能很高，实际效果却达不到业务预期。不是它没干活，而是干的活跟业务想要的东西对不上，关键信息也没讲清楚。笔者的做法，是在rules里加一套汇报规范，用金字塔汇报的方式要求AI做反馈：结论先行，再给关键依据，最后给细节。目标对不上就先停下来，不要为了完成任务而完成任务；没有验证过的东西，不要标记成已完成。任务完成不等于问题解决，这一点得写进rule，不靠AI自觉。
以上AI Native Harness的经验，就是笔者根据自身需求还有现有资源，总结出来的一套适合长期可持续的玩法。尤其是repo AS skill的哲学，能够保障AI工程可复用、可迁移，而且可持续生产。同一套repo，放到不同环境里，能衍生出不同的branch，长出不同领域的harness。这跟古法编程是一个道理，构建镜像做土壤，不同的harness是种子，最后打包出各式各样的产物，应付不同的工作场景。要做规模化工程化，AI Native Harness的思路跟古法编程是吻合的。关键是有没有这个sense，没有的话，就只能被AI的浪潮淹没。
总之，在当下这个AI爆炸的年代，探索不到一套可持续的玩法，就会被版本淘汰掉。不妨构建一套自己的harness，让一切尽在掌握。