我不想再写一篇工具教程。
工具教程太容易写，也太容易骗人。
你把按钮顺序抄下来，像拿到一张地图。真上路的时候，发现地图上没有天气，没有塌方，没有你自己那只会发抖的手。
# 楔子：别把神灯当电灯泡
人类第一次看见大模型的时候，很多人脑子里冒出来的不是工具，是神。
不是宗教意义上的神。是那种很古老的、突然把边界往外推开的东西。你问一句，它答一句。你不会的，它会。你卡了三天的错误，它瞄一眼，给你一段能跑的代码。
那一刻很容易让人产生幻觉。
你会以为自己终于得到了一盏神灯。只要把愿望说清楚，灯神就会从烟里出来，把你想要的东西摆在桌上。
后来你用久了，就会发现不对。
神灯不是电灯泡。电灯泡接上电，亮就是亮，不亮就是坏。神灯会解释，会补全，会猜，会为了让你满意而把自己没看见的地方编圆。它最危险的地方不在于无能，而在于它太像有能。它会把一件没想清楚的事，写成一堆看起来已经想清楚的代码。
这就是 AI 编程真正要命的地方。
不是它不会写。它太会写了。
执行正在变成白菜价。以前你一个函数要写半小时，现在一句话能吐三版。以前你改一百个文件要排期，现在一个 agent 能在你泡茶的时候扫完整个仓库。执行便宜到这个程度，问题就换了。
以前的问题是：我怎么把它做出来。
现在的问题是：什么算对。
这五个字，是 OpenCode 这类工具背后真正的门槛。不是安装，不是模型，不是 MCP，不是哪个插件更强。那些都是剑。真正分人的，是握剑的人脑子里有没有一部法。
我这几年反复见到同一种死法：一个人打开 AI 编程工具，把它当一个更聪明的聊天框。他把需求扔进去，看它写，看它改，看它跑命令。刚开始很爽，像坐上高铁。三十分钟后，项目变成一坨他自己也不认识的东西。测试可能还是绿的，界面可能还会动，甚至提交说明还挺像人话。
但他已经失去了系统的所有权。
代码在他机器上。仓库在他账号下。键盘在他手边。可真正决定这套系统长成什么样的，已经不是他了。
他成了一个批准按钮。
这比被 AI 替代更丢人。替代至少说明你还有一个位置被拿走。变成批准按钮，说明你主动把位置让了出去。
我写这篇，不是为了吹 OpenCode。OpenCode 也不是神。OMO 也不是神。它们只是把一件原本藏在老工程师肌肉记忆里的事，做成了可以看见的结构：规则、权限、子代理、模型路由、MCP、hooks、Team Mode、日志、回滚、审查。
这些东西合起来，不叫“更会聊天”。
它叫驾驭。
# 第一章：驾驭不是让马更强，是让骑手不死
我很不喜欢 Harness 这个词。
中文翻成驾驭，差不多。但“驾驭”容易让人误会，以为重点在骑手多厉害。其实 Harness 更冷一点，它是一套连接系统。缰绳，马鞍，脚蹬，护具，口衔。它不提供马的力量，它只决定这股力量最后会不会把你摔死。
AI 模型就是马。
而且是人类造过最奇怪的一匹马：它力气大，速度快，记性短，讨好欲强，有时候聪明得像妖怪，有时候蠢得像刚出生。你不能靠“相信它”骑它。相信不是工程方法。相信是宗教。
工程方法是：把能信的地方写成契约，把不能信的地方关进笼子，把必须由人判断的地方留给人。
OpenCode 的价值，不在于它又给你一个聊天入口。聊天入口已经够多了。它的价值在于，它让 agent 不再只是屏幕里的嘴，而是一个被权限、上下文、工具、规则、日志和审查包住的执行体。
这件事听起来像产品功能。其实是权力结构。
普通聊天框里，权力结构很糊。你说一句，它回一句。它错了，你骂它。它道歉。然后继续错。整个过程像两个没有合同的人在酒桌上谈事，靠情绪维持秩序。
真正的 agent 工程里，权力结构必须硬。谁能读什么，谁能写什么，谁能跑命令，谁必须先问，谁只能研究，谁可以动手，谁来审判，谁负责记账。这些东西不写清楚，AI 就会用它自己的默认值替你写。
而模型的默认值，永远不是你的公司、你的项目、你的审美、你的风险承受能力。它只是互联网上无数平均值的幽灵。
平均值很危险。
平均值能写出能跑的代码。平均值也能把一个有灵魂的项目写成随处可见的外包模板。它不犯罪，它只是把你的东西磨平。
所以驾驭的第一条铁律是：不要让模型替你决定什么重要。
你可以让它执行。可以让它搜索。可以让它比较。可以让它写草稿。可以让它扮演一支小队，替你把你懒得干的脏活干完。
但“什么算对”，必须是你写下来的。
# 第二章：AGENTS.md 不是说明书，是你写给机器看的法
很多人第一次看见 AGENTS.md，会把它当 README 的亲戚。
错了。
README 是写给人看的。它讲项目怎么装、怎么跑、怎么贡献。AGENTS.md 是写给机器看的。它讲这台机器在这个项目里应该怎么活。
这两者的差别很大。
人读文档，会带着常识。机器读规则，只会带着上下文。你在 README 里写“注意不要提交密钥”，人知道这句话背后是什么：别把 .env 推上去，别把 token 写进例子，别在日志里露出真实值。机器不一定知道。你不把边界写实，它就会用“我觉得这样合理”补全。
“我觉得这样合理”，是 agent 事故的祖坟。
一份好的 AGENTS.md，不该像公司文化墙。不要写“追求卓越”“保持简洁”“注重质量”。这类话对人都有点没用，对机器更没用。它需要的是可执行的法条。
在这个目录里，本地规则写得很明白：这里是 AI 工具链运维底座，不处理无关项目；排障先本地后外部；inventory 是版本、路径、端口唯一事实源；凭据绝不入库；logs 只增不改；改完跑健康检查。
这不是文采。
这是边界。
边界的意义在于，它把“聪明”变成次要，把“守法”变成主要。一个模型再聪明，如果它跳过本地知识库直接上网搜，它在这个目录里就是错的。一个模型再能写，如果它把凭据复制进文章，它就是错的。一个模型再会修，如果它没读 inventory 就瞎说版本号，它就是错的。
法的作用，就是让你在它看起来很有道理的时候，仍然有东西能一刀砍下去，说：不行。
我越来越觉得，AI 时代最值钱的人，不是提示词写得最花的人，而是会立法的人。
提示词像口头命令。法典像操作系统。
口头命令会随着会话消失。法典会在每一次新会话里重新加载。口头命令依赖模型这次有没有听懂。法典把“听不听懂”降成一个可以检查、可以修、可以迭代的工程问题。
这也是为什么我不喜欢“AI 小白”这个词。
小白这个词会给人一种许可：我不懂，所以我可以乱来。可 agent 拿到文件写权限之后，你已经不是游客了。你坐在驾驶位上。你可以不懂引擎，但你不能不懂刹车。
AGENTS.md 就是第一块刹车片。
# 第三章：OMO 不是外挂，是军队编制
我以前写过，未来的团队是一支公会，不是一张组织架构图。
OMO 把这句话在工具层面做了一遍。
它没有假装一个模型能当所有人。它把事情拆成兵种：Sisyphus 做编排，Prometheus 做计划，Atlas 执行计划，Oracle 做高难度只读顾问，Librarian 查外部资料，Explore 翻代码库，Momus 挑计划的刺，Metis 找隐藏歧义，Sisyphus-Junior 按 category 去干活。
这不只是“多几个 agent”。
多几个 agent 如果没有编制，就是一群人挤在门口一起喊。真正有用的是编制：谁能动手，谁只读；谁适合视觉，谁适合逻辑；谁负责查资料，谁负责做最终实现；谁的成本高，谁的成本低；谁可以并行，谁必须等前置判断出来。
一个人用 AI 用到后面，最容易犯的错不是不会命令模型，而是舍不得分工。
他什么都让一个会话干。让它读文档，让它查网页，让它写计划，让它改代码，让它跑测试，让它自我审查。听起来省事，实际是把一整支队伍压成一个疲惫的人。上下文越来越胖，判断越来越糊，最后它忘了开头，也忘了谁该负责什么。
这跟现实里的烂公司一样。
老板觉得“大家都是同事，互相帮一下”，于是所有边界都被抹掉。销售写产品方案，产品盯客服，技术去做 PPT，最后每个人都在干别人不该干的活，真正该负责的地方没人负责。
OMO 的 category 系统有意思的地方在这里：它逼你先判断任务性质，而不是先迷信模型名。
UI 和视觉，走 visual-engineering。高难逻辑，走 ultrabrain。自主深度执行，走 deep。小修小补，走 quick。文档写作，走 writing。你不是在问“哪个模型最强”，你是在问“这件事是什么活”。
这才是工程。
一个很强的开发者，不是永远亲自下场敲每一行的人。那是手艺人，不是构架师。构架师的价值在于，他知道什么时候自己下刀，什么时候让别人拆骨，什么时候叫审计，什么时候停工。
AI 时代也是一样。
你不是跟一个模型聊天。你是在调一支机器军团。
军团最怕的不是兵不够强。军团最怕的是没有军法。
# 第四章：模型路由不是炫富，是把马派到它该跑的路上
中文 AI 圈有个毛病：一谈工具，就开始比模型。
谁更强，谁更贵，谁上下文更长，谁跑分更高。像一群刚拿驾照的人在路边比发动机，没人问你要开去哪里。
模型当然重要。不同模型确实有不同脾气。有的适合长文，有的适合代码，有的适合视觉，有的适合硬推理，有的适合便宜快速地跑小任务。但“最强模型包打一切”是穷人突然有钱后的幻觉。
真正的路由，不是把所有事都塞给最贵的马。
是把每匹马派到它最该跑的路上。
本机的路由表里，Sisyphus 走编排优先，Oracle 走高难推理，Explore 走快速代码检索，writing 走专门的文档通道。category 也有自己的模型和 fallback。这个结构真正表达的不是“我有很多模型”，而是：不同判断层的成本、速度、可靠性不一样。
你让最贵的模型改一个错别字，是浪费。你让便宜模型做复杂架构判断，是找死。你让写作模型去改生产配置，是岗位错配。你让视觉模型去做 UI 细节，才是让刀回到刀鞘里。
这里还有一个很多人会读错的点：fallback\_models 不是护身符。
写了 fallback，不等于运行时会自动切。声明候选和启用运行时回退，是两件事。就像你通讯录里存了消防队电话，不等于房子起火时有人自动替你拨出去。要让切换发生，你得把 runtime\_fallback 这层开关打开，还得重启，让进程真的读到它。
这件事很小，但很能说明 AI 工程的本质。
你以为你改的是配置。实际上你改的是运行时世界的法律。法律不被加载，就不存在。你写在磁盘上，进程没读，它就只是纸。
所以我越来越反感那些“万能配置包”。
配置不是符咒。复制过去不会自动保佑你。你得知道它什么时候被读取，谁读取，读取失败会怎样，改完怎么验证，出事怎么回滚。否则你不是在配置系统，你是在贴平安符。
贴符的人，早晚会被机器教育。
# 第五章：MCP 是感官，不是工具栏
MCP 这个东西，很容易被讲成“给 AI 接更多工具”。
这话没错，但太浅。
工具栏的想象，会让人贪多。搜索接一个，文档接一个，GitHub 接一个，浏览器接一个，图片接一个，数据库接一个，Slack 接一个。最后 agent 面前摆了二十把刀，每把刀都能碰真实世界。你以为它变强了，其实你只是把事故面积扩大了。
我更愿意把 MCP 看成感官。
人没有眼睛，看不见图。没有耳朵，听不见声。没有触觉，不知道东西烫不烫。模型本身没有外部世界。它只有上下文窗口里那点东西。MCP 给它接上外部感官：Web search 是远处的望远镜，Context7 是查官方文档的图书馆，grep.app 是看别人真实代码的公共街道，LSP 是语法神经，CodeGraph 是关系神经，视觉工具是眼睛。
感官的价值，不在于多。
在于准。
一个人不是因为全身长满眼睛才强。那叫怪物。真正强的是，该看的时候看，该闭的时候闭，该相信显微镜的时候不相信肉眼，该相信编译器的时候不相信感觉。
本机这套 MCP 七根神经都 connected，这很好。但“都连上”不是终点。终点是你知道什么时候该调哪根神经。
问库怎么用，先查官方文档。问这个项目里某个符号影响谁，先走代码图谱。问 UI 截图有没有崩，走视觉。问一个公开 repo 里别人怎么写，走 GitHub 代码搜索。
最蠢的是让模型凭记忆答。
模型的记忆像酒桌传闻。可能对，可能过期，可能把三个版本混在一起。MCP 的意义，就是把“凭印象”变成“有证据”。
一个强开发者和一个普通用户的差别，在这里特别明显。
普通用户问：你觉得应该怎么写？
强开发者问：证据在哪里？这个版本的文档怎么说？当前代码里谁调用它？跑一次结果是什么？改完有没有诊断？
AI 不怕你粗鲁。它怕你没有判据。
# 第六章：hooks 是传感网，不是装饰品
一个系统真正变强，不是因为它会干更多事，而是因为它能更早知道自己快错了。
这句话适用于身体，也适用于公司，也适用于代码库。
身体有疼痛。疼痛很烦，但疼痛救命。你摸到火缩手，不是因为你道德高尚，是因为神经比你的哲学快。公司有财务报表、客户投诉、事故复盘。代码有编译器、类型检查、测试、日志。
Agent 系统也必须有传感网。
OMO 的 hooks，就是这张网。
它们不是“插件功能”。它们是把某些规则从人的提醒，降到机器的反射。未读就写文件，拦一下。AI 写废话注释，拦一下。todo 没做完就想停，拦一下。关键词触发某种工作模式，自动注入指令。运行时模型失败，按可恢复错误尝试 fallback。
这些东西单看都小。
但工程世界里，真正改变系统命运的，往往就是这些小到没人愿意认真写的东西。
“不要直接改没读过的文件”，人当然知道。可人会忘。agent 更会忘。把它写成 hook，它就不再依赖这一次会话有没有记住。它变成了反射。
这就是判定下沉。
不要把所有判断都留给人。人太贵，也太累。能交给编译器的，交给编译器。能交给 LSP 的，交给 LSP。能交给测试的，交给测试。能交给 hook 的，交给 hook。人只保留那几件机器真的够不着的事：取舍、品味、信任、方向。
这件事讲透了，其实就是薄壳公司的核心。
公司不是人多才强。公司强在有一层薄薄的规则，把人、机器、钱、责任、判断连接起来。壳太厚，官僚。壳太薄，散架。真正好的壳，不抢执行权，只保留治理权。
OpenCode 加 OMO 也是这样。
底下是模型，是 agent，是 MCP，是脚本，是命令，是一堆会跑的东西。上面必须有一层薄壳：规则、权限、路由、传感网、日志、回滚、人工门控。
这层薄壳不写代码，却决定代码会不会变成灾难。
# 第七章：Team Mode 不是热闹，是开团纪律
很多人一听 Team Mode，就兴奋。
多智能体协作。并行。共享任务。邮箱。tmux 可视化。十二个 team\_\* 工具。听起来像终于可以把一群 AI 放出去打仗了。
我反而想先泼冷水。
开团不是新手福利。开团是组织能力考试。
一个人连单 agent 的边界都没写清楚，开 Team Mode 只会把混乱并行化。原来一个模型乱改，现在四个模型一起乱改。原来一个会话忘上下文，现在四个成员互相丢消息。原来你不知道谁负责，现在每个成员都以为别人负责。
这不叫团队。
这叫灾难分布式部署。
真正该开团的场景很少，但很明确：多个互相独立的研究轴，多个不重叠的文件改动，长任务需要共享任务列表，或者你想让不同成员从不同角度互相质疑。比如一个人查官方文档，一个人看本地代码，一个人做安全角度，一个人写实现，一个人做 QA。每个人有边界，有产物，有停机条件。
Team Mode 默认关闭，是对的。
默认关闭不是因为它不强，而是因为它太强。强工具默认不该裸露。你把圆锯放在桌上，不会默认通电。你要用它，先知道手指在哪里。
本机已经把 team\_mode.enabled 打开，tmux\_visualization 关掉。这个选择也很工程：先要能力，不急着要热闹。tmux 可视化很好，能看每个成员怎么跑；但缺了它，不应该影响团队创建。工具的展示层不能绑架执行层。
这句话放大到所有 AI 工程也成立。
不要为了看起来像未来，牺牲系统真正能跑。
# 第八章：新手最该学的不是配置，是验收
我想把话说得难听一点。
很多所谓 AI 教程，教出来的是一群会启动工具、不会验收结果的人。
他们会装，会复制配置，会调用模型，会把终端搞得五颜六色。可你问他：这次改动为什么是对的？证据是什么？失败时从哪一层排？不可逆操作有没有门控？版本事实谁是 owner？他说不上来。
说不上来，就不算会。
AI 时代真正的新手村，不是“如何让 AI 帮你写第一个函数”。那太低了。真正的新手村应该教四件事：
第一，识别权力。这个工具能动什么？能读什么？能删什么？能发什么？
第二，写下法律。这个项目里什么算对，什么禁止，什么必须验证？
第三，建立感官。它需要哪些外部证据？官方文档、代码图谱、LSP、日志、截图、运行结果，各自负责哪一层？
第四，验收执行。改完以后，谁来证明它没错？编译器、测试、构建、手动跑一遍、人工 review，顺序是什么？
这四件事不会过时。
OpenCode 会升级。OMO 会改名。模型会换。今天的路由明天可能被更强的模型替掉。MCP 生态会长出更多工具。Team Mode 以后也可能变得更顺手。
但只要 AI 仍然是那个会执行、会猜、会补全、会把你的含糊变成真实改动的东西，这四件事就不会过时。
因为它们管的不是工具。
它们管的是权力。
# 结尾：你不是要成为 AI 的朋友
别再把 AI 当朋友了。
朋友这个词太软。朋友会被原谅，会被安慰，会因为“态度很好”获得第二次机会。生产系统不吃这一套。一个 agent 删除错文件之后说“我深感抱歉”，没有意义。文件不会因为它道歉长回来。
你也不是要成为 AI 的主人。
主人这个词又太旧。它会让人产生一种帝王幻觉，好像你发号施令，机器跪地执行。现实不是这样。现实里，你的大部分命令都很烂，你的很多需求都没想清楚，你的判断也会疲惫、漂移、被情绪污染。
更准确的关系是：你是立法者，也是最后的验收人。
机器军团负责执行。法典负责约束。传感网负责报警。MCP 负责感知外部世界。模型路由负责给不同任务派不同的马。Team Mode 在需要的时候开团。OpenCode 只是这一切运行起来的壳。
而你，不能把“什么算对”交出去。
这就是整篇的骨头。
AI 时代，执行会越来越便宜。便宜到最后，写代码本身会像打字一样不值钱。真正贵的，是判断；是边界；是验收；是把一群机器和一群人组织成一个能长期不散架的系统。
我为什么一直讲薄壳？因为未来的强公司、强个体、强团队，都不会靠一堵厚墙保护自己。墙会被模型推平。技能会被复刻。经验会被压缩成教程。藏着的井会干。
剩下能护住你的，是一层很薄但很硬的壳。
它不替你干活。
它只保证活不会把你反过来干掉。
下篇再讲怎么从新手村开始，把这层壳一片一片装起来。不要急着开团。不要急着炫模型。不要急着把所有 MCP 都接上。
先学会写法。
再学会验收。
最后，才轮到让军团冲锋。