想让 AI 真正提速，先把公司变成 AI 能工作的地方
我最近在做 harness，越来越觉得，很多人对 AI 提效的想象从一开始就错了。
他们以为，所谓 AI 提效，就是给每个人发一个聊天窗口，再买几个模型账号，然后让员工把原本要做的事情交给 AI。写方案的时候问一下，写代码的时候问一下，做分析的时候再问一下。最后发现速度没有明显变快，结果还经常出错，于是得出结论：AI 还不够成熟，我们的业务太复杂，暂时用不起来。
这套说法听起来合理，实际上一点也不负责任。你不能把一个什么都不知道的模型扔进一个混乱的组织里，然后期待它像一个工作多年的老员工一样，自己找到资料、理解上下文、调用系统、判断结果，最后把事情稳稳地做完。人类员工至少还可以到处问人，可以观察办公室里的气氛，可以凭经验知道哪个文件不能信、哪个同事说话要打折。AI 没有这些条件，它只能使用你给它的上下文、工具和规则。
如果这些东西根本不存在，AI 当然干不好。
AI 提效的前提，是把工作环境搭出来
harness 这个词很有意思。它不是单纯给 AI 加一个提示词，也不是换一个更大的模型。它更像是在 AI 外面搭一套可以工作的环境，让它知道自己是谁、能做什么、资料在哪里、遇到什么情况要停下来，以及什么样的结果才算完成。
一个真正能工作的 AI，不能只会回答问题。它得能读取项目资料，找到相关数据，调用工具，修改文件，运行测试，检查结果，再根据反馈继续调整。如果它做完这些以后还要人类重新把所有内容复制出来、手动检查一遍、再把结果整理成另一种格式，那它只是帮你节省了一点输入时间，谈不上真正提速。
所以，技术栈是不是 AI 友好，区别非常大。代码能不能被快速启动，项目结构是否清晰，命令是否统一，数据接口有没有明确说明，错误信息够不够具体，测试是否可以自动运行，部署流程有没有标准入口，这些听起来像传统工程问题，却直接决定了 AI 能不能参与执行。一个结构混乱、资料散落、命令各不相同、环境无法复现的项目，就算接入最强的模型，AI 也只能在里面摸索。它每走一步，都得重新猜。
让 AI 工作，靠的是可调用的信息
很多团队以为自己已经把业务资料准备得很充分了。会议纪要有，产品文档有，培训材料也有，公司的知识库看起来塞得满满当当。可真正让 AI 干活的时候，才发现里面大量内容过期、重复、互相矛盾，重要的信息散落在聊天记录、邮件、个人笔记和某几位员工的脑子里。
人可以勉强应付这种环境。一个老员工知道哪份文档比较新，知道某个流程虽然写着这样，实际操作却要多一步，也知道遇到特定客户时应该绕开正常规则。AI 没有这种默认经验，它只能根据能找到的内容做判断。如果你给它三份互相冲突的资料，它不会天然知道哪份才是真的。
这就要求团队重新整理自己的信息。不是把所有资料一股脑塞进知识库，而是要让必要的信息有明确的位置、稳定的格式和可被调用的入口。项目的背景是什么，目标是什么，当前状态是什么，能使用哪些工具，哪些操作需要确认，输出应该包含什么，失败后应该怎么办，这些都应该变成 AI 可以直接使用的上下文。
Skill 和模板，才是团队经验的可执行版本
我现在越来越喜欢把 skill 理解成一种“可执行的经验”。一篇文档只是告诉你某件事情是什么，一个 skill 则要告诉 AI 在什么情况下使用这套经验，需要准备什么输入，应该按照什么步骤执行，什么结果算合格，什么时候必须停下来找人确认。它不一定很长，甚至可以很短，但必须足够明确。
比如“发布一个前端项目”这件事，普通文档可能只写：构建项目、运行测试、发布到线上。一个真正有用的 skill 则会告诉 AI，先检查当前分支和未提交修改，再安装依赖，运行哪些测试，构建失败时看什么日志，发布前要确认哪些环境变量，发布后访问哪些页面，出现什么情况不能继续。
它把一个人的工作习惯，变成了一套机器可以执行、也可以被人检查的流程。模板也是一样。好的模板不是为了让所有输出看起来整齐，而是为了减少每次重新思考的成本。一个项目启动模板，可以让 AI 知道需要收集哪些信息；一个代码修改模板，可以让它先说明影响范围和验证方式；一个内容生产模板，可以让它在动笔之前先确认受众、目标和发布渠道。
这些东西越清楚，AI 能承担的执行范围就越大。反过来，如果每次都要先花半小时向 AI 解释项目背景，再手动告诉它工具在哪里、文件怎么打开、结果该交付成什么样，那你其实还没有建立 AI 工作流。你只是比以前多了一个需要培训的实习生，而且这个实习生不会主动观察环境，也不会因为犯过一次错就自然记住教训。
人负责判断，AI 负责把事情往前推
这并不意味着以后所有事情都交给 AI，人类只坐在旁边看。人仍然要负责方向、边界和最后的判断。这个需求该不该做，风险能不能接受，用户到底想解决什么问题，哪个结果虽然看起来正确但不适合发布，这些事情不能简单地交给模型决定。尤其在涉及真实用户、真实数据和真实业务后果的时候，人必须保留监督和验收的权力。
但人的工作方式会发生变化。以前人可能要亲自搜资料、改文件、整理结果、反复执行命令，再把各个环节串起来。以后更合理的方式，是人负责发布指令和检查结果，AI 负责在确定的工作环境里连续执行。人告诉它要达成什么目标，AI 自己去找相关信息、调用工具、完成中间步骤；人不需要盯着每一次鼠标点击，但要知道它做了什么，为什么这么做，最后的结果有没有达到标准。
监督不是站在旁边看 AI 打字，验收也不是最后扫一眼输出有没有错别字。真正的监督，需要有可见的过程、明确的检查点和可以复现的结果。你要知道 AI 使用了哪些资料，调用了什么工具，改了哪些文件，跑了哪些测试，哪里出现过不确定，哪些地方是它自己推断的。只有这样，人类才能在效率提高的同时，继续对结果负责。
AI 负责把事情往前推，人负责决定这件事情是否值得继续往前推。
“我们业务复杂”常常是在回避真正的问题
当然，很多业务确实复杂。有些流程很难标准化，有些判断必须依赖经验，有些地方充满了例外情况。可这并不代表什么都不能整理，也不代表 AI 只能停留在聊天和生成文本这一步。
至少可以先把稳定的部分找出来。哪些资料是固定的，哪些步骤每天都重复，哪些检查每次都要做，哪些工具可以统一调用，哪些错误总是反复出现，哪些经验其实已经被团队重复使用了很多次。把这些部分先做成 AI 能理解、能调用、能验证的基础设施，效率自然会一点一点长出来。
最不负责任的做法，就是面对一堆混乱，最后只说一句：“我们业务复杂，AI 搞不定。”
这句话把所有问题都推给了业务本身，却不承认真正的麻烦可能来自技术栈不友好、资料没有整理、流程没有标准化、经验没有沉淀、工具没有接入、结果没有验收机制。你甚至没有给 AI 一个工作的环境，却要求它证明自己值得被使用。
这和招聘一个人进来以后不给权限、不提供资料、不介绍同事，最后再说“这个人能力不行”，没有什么区别。
AI 提效从来不只是模型的问题。它更像一次对组织基础设施的检查：你的代码能不能被理解，数据能不能被找到，经验能不能被调用，流程能不能被执行，结果能不能被验证。
如果这些事情都做不好，AI 当然只能陪你聊天。
如果这些基础设施真的搭起来了，人就不需要再把时间耗在重复搬运信息、手动执行流程和不断解释背景上。人可以把精力放到目标、判断和责任上，AI 则在一个足够清晰的 harness 里，把那些原本拖慢所有人的事情，一件一件往前推。
