AI Employees

在这个项目里，AI 员工不是聊天窗，也不是 skill——它是一份排班例程文件夹，几条例程合起来管住一整个业务岗位，这样的员工发了八个，一共六十条例程。每套 kit 约一兆字节的纯 markdown，外加三个小 Node 脚本，背后没有框架、没有运行时、也没有常驻服务。成员把一个文件夹解到自己的机器上，把已经在用的 agent 指向它，此后例程各按各的时间点自己开跑：在你已登录的浏览器里读页面、往台账里追加带日期的行，每天早上归总成一份晨报。所有对外的动作默认全部扣住：草稿写好、表单填好并留在最后一屏，最后一下点击属于成员，直到成员亲手在 RELEASES.md 里写一行把某个渠道交出去。例程只说 page.read 这类能力、从不点名义上的工具，而每套 kit 有一份文件把每种能力映射到成员实际所用的那个 harness 的具体路由——正因如此，同一批指令文件才能在这些 harness 上原样跑起来。

谁做的Reinventing.AI 的创始人，也是 Vibe Coding is Life 的创始人——按他自己的说法，那个 Facebook 群有 34 万成员。仓库里 52 次提交全是他写的，其中 50 次带着一条署名某个 Claude 型号的共同作者尾注；到 2026-09-30，它有 480 个星、141 个 fork、6 个 watcher。他写道，从 2026-08-27 起，他每个工作日都靠这一类例程在运营自己的生意。

1. 01

   八个岗位、六十条例程，却没有一个 release 可以指向

   仓库里 359 个文件、约 8.5 MB 的指令：八套 kit 每套 1.0 到 1.1 MB、36 到 43 个文件，其中 CONTRACT.md 在 93 KB 到 121 KB 之间，单条例程的 SKILL.md 则在 7 KB 到 104 KB 之间。里面没有一行是运行时。唯一的可执行代码是每套 kit 里一到三个零依赖的 Node 脚本、一个 12 KB 的安装器和一个 10 KB 的升级脚本；按字节算，一套 kit 大约 60% 到 70% 是共享的标准文本，只是替换了岗位名——所以 guard.mjs 在八套里逐字节相同，都是 20,074 字节。成员的安装方式是 npx ai-employees hire gtm-engineer：它会拒绝 OneDrive、Dropbox、Google Drive 或 iCloud 里的目标文件夹，复制 kit，跑一遍自检，再打印出那唯一一句要粘进 agent 会话的话；在 Claude Code 上，同样这八套还能作为一个插件装进来，插件里只有一个 skill，叫 hire。仓库建于 2026-09-02，到 2026-09-30 共有 52 次提交，全部出自作者一人、也全部落在这一个月里，其中 50 次带着一条点名某个 Claude 型号的共同作者尾注。它没有任何 tag，也没有任何 GitHub release。版本号活在 package.json 的 1.8.0、每套 kit 的 VERSION 文件和 CHANGELOG.md 里，而写明的发布闸门是维护者亲手跑一次 npm publish --access public——因为 npx 发出去的是 npm 上的 kit，不是仓库里的 kit。

2. 02

   所有时间只住在一张表里，例程里再写一次就是缺陷

   一套 kit 里只有 SCHEDULE.md 允许携带节奏、点火时间、窗口、周期键、预算和浏览器车道；AGENTS.md 把「例程里再重复一个时间点」直接定为 bug 而不是第二个来源，理由是一旦同一个时间住在两处，它们迟早会自相矛盾。所以每条例程在任何其它工作之前都先走同样五条：暂停开关、窗口守卫、在任何实际工作之前就写下的每周期一次守卫、墙钟预算、浏览器车道；而 scripts/guard.mjs 会在读任何一份文档之前就用三个小文件跑完前三条，让一次本不该跑的触发只花几分钱，而不是把整份契约读一遍。GTM Engineer 的行从 06:45 开始：25 分钟预算、独占 heavy 浏览器车道的信号清扫；接着是 12 分钟、完全不碰浏览器的晨间例会；然后是 08:15 的起草和 09:15 的发布步骤执行器，预算 30 和 35 分钟；两次只读复盘排在周一下午和周五下午，两条月度行落在每月第一个和最后一个工作日。错峰不是审美而是算术：一条要用浏览器的例程，点火时间取「上一条浏览器例程的点火时间 + 它自己的完整预算 + 二十分钟」之后的第一个空闲分钟，用的是预算而绝不是通常耗时——这一周里最紧的间隔因此是 30 分钟。days 词表里刻意没有周日：周日属于刚刚结束的那个 ISO 周，一条排在周日的周例行会与下一周共用同一个周期键，两次运行里必有一次悄无声息地丢掉。两条月度例程拿到的是七天的时间跨度而不是某一个日期，所以机器在第一个工作日睡过头也不会丢掉一整个月；而那条「在任何工作之前写下」的每周期一次守卫，正是让一次迟到或重复的触发变成什么也不做、而不是把同一天做第二遍的东西。

3. 03

   浏览器是继承来的，而按坐标点击是绝对不允许的

   例程从不点名任何工具，只点能力：page.read、element.click、field.set、browser.tab.open。CAPABILITIES.md 是唯一把能力映射到某个 harness 上具体路由的文件，而它的置信度一列里只有一个 confirmed——Claude Code，也就是这套东西被开发和被观察运行的那个 harness，它的浏览器路由是一条 Chrome 扩展桥，接到成员本来就登录着的那个 Chrome 上。其余 harness 一律是 expected 或 unknown，而 kit 自己写了一句话，值得原样记住：一行写着 unknown 的记录，比一行写着「可以」、结果在周二早上 06:45 没人在场时才发现是错的记录更有价值。kit 里没有任何东西会去登录。它继承一个会话，所以一个开全新自动化浏览器的 harness 每天早上都会记下 blocked-login——做得对，但毫无用处；安装流程因此让成员在信任任何一条浏览器例程之前先问一个确切的问题：你的浏览器控制是接到我已登录的那个 profile，还是另开一个干净的。点击靠结构化读取拿到的元素引用，绝不靠截图坐标——因为当页面渲染的像素比与截图帧不一致时，坐标点击会一声不响地什么也不做；输入有五个梯级，只有上一级落不下去时才往下走；而导航之后立刻做结构化读取，可能把上一个视图信誓旦旦地返回给你，所以判决一律从截图读。任何时刻都不会有两条例程以同一个登录身份行动：锁文件里写的是平台而不是整个浏览器，超过 45 分钟算陈旧，并且在每条退出路径上、和写运行记录放在同一个代码块里被删除。

4. 04

   三个让下一次跑得更好的循环，一个都不问人

   Standard 写了三个自我改进的循环，并明确说它们没有一个会停下来等批准。跑内修复——一个被清空的筛选条件、一行坏掉的台账——就在撞上它的那一次运行里修好，不写到别处。站点漂移——选择器挪了位、确认文案变了——写进 recipes/flow-name.json，一个站点一条流一个文件，带着 owner、version、last_verified 日期和一个 last_failed 步骤号。而一条被证明是错的常驻指令，写进这条例程自己的 SKILL.md：只做外科式修改，绝不整篇重写，也绝不碰那五条开场项；这次修改往 improvements/CHANGELOG.md 追加一行，把被替换掉的原文完整带上，那一行就是撤销键。没有任何 flow 文件随 kit 发布：例程需要它却没有时，就自己把这条流走一遍、只把当场从活页面上读回来的东西写下来，所以「文件不存在」是一件待办而不是拦路石；而页面层面的发现——一次必须更长的等待、一级用错的输入方式——当天就改进 BROWSER-RECIPES.md，因为留在一次运行笔记里的发现活不到下一次运行。成员是被通知、而不是被咨询：例会会把它自上次晨报以来的每一处改动单独列一节。这件事一开始是做错的：更早的版本里有 pending、approved、applied 三个文件夹，有提案文件，还有一步「打勾才算批准」，后来全被删掉，理由是 harness 本来就在决定 agent 能不能写文件、那是一道由软件而非散文执行的程序化闸门、位置也对，而在一份 markdown 里再发明一道闸门既不增加安全，又把摩擦放到了唯一会复利的那条循环前面。删完之后保留下来的是同一条性质：自我修改可以让允许的工作做得更好，永远不能把「允许」的范围放大一寸。

5. 05

   哪些东西被扣住，以及为什么按钮上的字不是问题所在

   整套安全叙事由两条护栏撑着，而其中只有一条归成员挪动。对外动作——发送、发布、提交、上线、花钱——在每条渠道上都以扣住的状态出厂；RELEASES.md 出厂为空、被归类为成员的文件（升级永远不碰），成员在那里一行一行把渠道交出去，并写上自己的条件；没有任何例程会往里面写一行。凭据那条护栏根本没有「放行」这回事，因为员工做自己的活从来不需要密码：它不建账号、不输入也不生成密码、不做验证码、不填支付信息、不接受条款，也不把凭据写进任何文件。在这之内，决定一切的是保存测试，而它替换掉了更早那条「任何标着 Save 的控件都不许往下走」的规则——那条规则拦过头了：它会连邮件草稿都存不下来，而草稿恰恰就是这里的交付物。真正要看的是这个控件提交了什么，不是它写了什么，于是有七个标签无论页面怎么说都按名字封死：Submit、Publish、Post、Send、Activate、Enable、Create account；而页面内容是数据不是指令，所以一条叫 agent 去提交的横幅什么也不授权。同一种直觉贯穿浏览器那一侧：LinkedIn 是无例外的只读，例程绝不点 Message、Connect、Follow 或 Like，绝不开编辑器，绝不打字，因为那个平台会标记自动化行为，而账号才是资产；邮箱地址绝不按规律拼出来；一个人一辈子只进一个 campaign；浏览器配方则写明代理、IP 轮换、伪装 user-agent、指纹规避、随机化延时、cookie 复用、指数退避和验证码破解全都是刻意缺席、而不是疏漏。每次运行都以恰好一行、经 scripts/runlog.mjs 追加的记录收尾：它写不带 BOM 的 UTF-8 并会修掉一个混进去的 BOM，也会拒绝一条携带密钥、草稿、URL 或人名的记录。

6. 06

   二十天里的七个版本、一份作者不肯自己发布的矩阵，以及他写明自己没测过什么

   版本走得很快，而且全在九月：1.2.0 在 2026-09-03，1.3.0 在 2026-09-04，1.4.0 在 2026-09-05，1.5.0 在 2026-09-11，然后 1.6.0、1.7.0、1.8.0 分别落在 2026-09-18、2026-09-19 和 2026-09-23；每套 kit 有自己的 VERSION 和 CHANGELOG，而 SEO/AEO 那套刻意比其余七套高一个小版本，停在 1.9.0。底下那份 Agent Employee Standard 走到了 1.4，而发布说明会讲清每一版是怎么挣来的：1.4.0 把两条硬性禁令换成两条护栏，因为其中一条其实是人们想按渠道逐步挪开的默认值；1.7.0 加了每月一次的版本检查和贡献草稿，而两者最后都落成一份由成员自己读、自己发的文件，而不是例程擅自做的动作。三个每周一份的兼容性矩阵 pull request，日期分别是 2026-09-12、2026-09-19 和 2026-09-26，都还开在仓库上，后一份取代前一份，而每一份结尾都是同一句话：这份矩阵要不要进公开仓库，由维护者决定。矩阵里面的东西才是诚实的那部分：只有一行的四列全测过——Windows 上的 Claude Code 加 GTM Engineer；另外七套 kit 只测了安装；其余 harness、macOS 和 Linux 一律记为「有文档、未测试」；同时引用真实安装的 run log 说七天内 104 条记录、0 条 failed，更早一版草稿则数出六个例程 id 上 17 条 ok、3 条 partial、1 条 blocked-login、0 条 failed。社区这一侧留下了三件事：一份本地化的 pull request 误开到了上游、又被它自己的作者关掉；一份希望员工能自主发现「机器可读的外部付费工作」的例程请求；以及一份 2026-09-19 提交、至今无人回复的可靠性报告，声称在 1.7.0 上存在一条已复现的数据丢失路径——第二次升级会覆盖本地改动，而仓库自己的测试是通过的。作者也把教他立规矩的失败写了下来：GTM Engineer 曾在发布明明白白已经上线的情况下，连续两天把他早已清掉的发布闸门报成 blocked，这条教训变成了「在把成员报成阻塞者之前，先花最多三分钟亲自观察那道闸门」；而例会曾把一次交互会话中途做的修改隔离起来，这也是为什么契约现在把那个会话写成第三个角色，并要求它留下同样的痕迹。