我先当了用户，才去翻仓库。
如果先读 README，你会看到「个人 IT 助理」「先诊断再动手」。那是广告。你先被它服务一遍，才知道这句话是不是真写进工序里。
上门的人叫 Jones。他看桌面、看下载、看备份盘接没接上，摊开一张绿黄红的表，让我选。我选了归类下载。他先预览：287 个文件会动，14 个收藏夹不动。我说正式归类，他先写撤销对照表，再移动。做完用同一套检查再跑——待移动变成 0。离开时告诉我清单在哪。
证件照、电子书、特斯拉图册，他不整包当垃圾。清单外的东西，哪怕看起来像垃圾，也不顺手清。
我当时想的不是「AI 会聊天」。是：这像一个靠谱的人在干活。进门、看、清单、你选、动手、验收、留下对照表再走。少一环，就不像那么回事。
然后我去翻仓库。作者李笑来，项目 mac-it-guy-pro。34 次提交，2026 年 7 月 29 日傍晚到 31 日下午，大约 46 小时。提交说明写得像设计笔记：错在哪、试过什么、为什么否决。
体感和提交对上了。这篇给正在做 Skill 的人。不教安装，不教斜杠。只讲那条脊椎，以及它怎么从「写给模型的愿望」变成「模型跳了也会被挡住」。
人叫不出的，不要问
第一版提交里，十律已经在：先诊断再动手、进废纸篓、先预览、移动前写撤销表、修完用同一套检查再跑。你摸到的节奏不是后来包装的。
但第一版上门是四道问卷：用电脑干什么、哪些事烦、技术舒不舒服、电脑没了会不会丢东西。
一个小时后整段推翻。提交里写：
机器才是面试。旧的四问假设用户能自我报告习惯和备份——他们不能，而且
tmutil答得更好。
不是少问一点更友好。是：人叫不出的东西，不要问，去量。
同一刀后来又砍了两回。用户叫不出「世上还有这种自动化」，就不要等他说「帮我做个工具」，用他机器上的数字提一件。用户叫不出该学什么，就不要等他点课程名，从刚发生的访问里长出题目。
三件事一句潜台词：识别，不是回忆。
做 Skill 最容易犯的，就是第一版那种专业。一上来问「你的工作流是什么」「你最烦哪一步」。问得越完整，越像调研。其实是把认知负担推回去。用户要是能准确叙述，往往根本不需要这个 Skill。
我自己这周就打过一次数字。下载第一次报 24 GB，对着文件夹复测是 4.4 GB。整家目录一层统计，不能直接当成「下载有多大」。连「看」都会看错。会打自己的数，观察才算数。
读者会拍桌子：我的领域没有 tmutil，不问用户问谁？
问得对。原则不是「闭嘴去黑盒里猜」。是去找可验证的痕迹。Mac 上是备份命令的输出、桌面上的截图、下载里超过三个月没改过的文件。换到你的 Skill，痕迹通常已经在：失败日志、上次真正跑通的命令、仓库里反复改的同一个文件、用户昨天点过又取消的选项。那些是 tmutil。问卷是你懒得去找痕迹。
我也写过一篇跟这相反的现场：朋友给的提示词里，领域是空的。不该猜，先问「你想了解哪个领域」。那次该问。空位没有痕迹，猜了后面全废。该问的是「机器答不了、痕迹还不存在」的那一句；不该问的是用户其实答不好、但电脑或日志答得好的那些。
判断能做成规则的，就不要交给模型
仓库里最陡的一条线，是怎么把人叫出来。
当天 18:45，名字就是扳机，比如 warren_。身份等于触发器。
6 分钟后整盘反转，改成所有人一样的 _it。常见人名当扳机会误触；每人一个词，又没法一句话教会所有人。
第二天凌晨，名字请回来，扳机仍是 _it。理由不是功能，是关系：他叫用户的名字，自己却匿名，不对称。
再过大约 20 分钟，光名字也能叫他。于是要判断：Alan, check my backup 是叫他，Alan Turing 是提及。作者写：这是判断，不是规则。含糊时不要猜。
再过 9 分钟，否决自己：
光名字当扳机，意味着要读意图。原则上对，实践上脆。
改成 _alan。和 _it 同一套机械装置，只是穿着你选的名字。句子里提到 Alan，没有下划线，叫不出来。教学放在起名那一刻：被告知的人记得住，要自己发现的人记不住。
我现在敲 _jones，就是这 9 分钟否决留下来的。
人设可以有。Jones 有名字，会进门，会交代撤销表。叫他出场的方式必须是硬的。 下划线不是卖萌。是作者不肯把「叫我还是谈别人」交给模型。
你如果在设计一个会打断用户的助手，先问：触发是一条能测的规则，还是一次理解？理解会漂。规则可以写测试。
写在 SKILL.md 里的「必须」，模型忙的时候会跳
后两天作者几乎只在做一件事：把十律从散文变成挡得住的东西。
记忆那一刀写得很干净。档案有十个写手，没有收割机。按行数删最老的一条，是反的：可能仍成立的旧事实被扔掉，已经解决的新事实留着。他改成：每条事实写明怎么来的；推断必须带「何时再验」。验不上的搬进历史，不删——删掉就解释不了当初为什么那样修。
检查脚本随后跟上。然后出现最吓人的一种失败：脚本打印了 CRITICAL，退出码却是 0。管道在子进程里计数，父进程以为没事。按退出码分支的调用者都以为干净。作者的说法是：向安全方向撒谎的检查。
护栏那边更像自己咬自己。用插件开发插件，钩子分不清「危险命令」和「讨论危险命令的文字」。最倒过来的一次：
rm -f $HOME/Documents/*.pdf → 拒绝
rm -f "$HOME"/Documents/*.pdf → 放行
细心的人会加引号。护栏对马虎最强，对认真最弱。挡住，误伤提交说明；开口子，bash -c 里的删除被当成引号里的散文放行。再收。咬痕写成测试。断言从 33 条涨到 159 条。
还有一笔，解释了我为什么觉得他在说话，不是弹菜单。旧文案把召唤写成「路由到对应工作流」。一句「电脑慢吗」会去开火修理。改成：先说话；真要动手，先说跑哪条、为什么。一次召唤以零条命令收场，是常态。
做 Skill 的人常把「记住用户」「千万别乱删」写进说明书，就以为焊住了。那是愿望。真要焊，得回答：模型跳了这一步，谁挡？挡的东西会不会自己撒谎？钩子如果会进别人的会话，默认只护不可恢复的文件，别把整台机器的政策强加给没为这件事投过票的人。
46 小时连轴改，不可复制。可复制的是习惯：每次打脸写成说明，说明里写否决项，否决项写成测试。
带走三条
- 人叫不出的，去找痕迹。 痕迹还不存在，才问那一句。问卷往往是懒。
- 触发写成规则，人设写成口气。 理解会漂，规则可以测。
- 说明书里的必须不算数。 跳了会出祸的地方，要有钩子或测试。向安全方向撒谎的检查，比没有更糟。
我自己的土办法：做完一次会改文件的事，离开时有没有留下对照表，并告诉对方它在哪。有，像一次访问。没有，还是一次对话。
专业不是态度好，是工序不许跳。
第一版里已经有这套访问。46 小时里作者不是发明节奏，是把节奏焊到模型跳了也会碰壁——然后发现焊的过程会咬到自己，再把牙印编进测试。
仓库在这里：xiaolai/mac-it-guy-pro。提交说明本身比 README 更值得当教材。不必先装。