第一次打开 agent 工具的人，几乎都卡在同一个地方：把它当成一个会写代码的 ChatGPT—— 问一句、答一句，惊艳三天，然后放回抽屉。这份手册来自 Greg Isenberg 的一期视频， 他开场那句话很不客气：很多人用 Claude Code 的方式是错的。 而他给的解法一点都不玄——你想让它像员工一样干活，就得给它一个员工该有的东西。
新人入职你会给什么？一个工位、一份背景交代、一次开工前的沟通、一张明确的工单、 一双能自己检查成果的眼睛、一道复核、一份排班表、一套权限。九块拼图，一块都不能少， 外加一层让它越用越像你的装备。后面附一份七天上手计划、一张 「把这套换到你自己身上」的映射表，以及我自己踩过的三个坑—— 手册照抄能到 80 分，剩下 20 分全在「第八天你还会不会打开它」。
这个词现在被用得很脏，所以先把它钉死。一个数字员工不是一个更聪明的对话， 也不是一句「你现在是我的助理」的角色扮演咒语。它是一个很朴素的判断： 如果一个真人明天来上班，你要给他什么，才让他能干活？ 逐条列出来，就是这份手册的全部结构。
一个它能进去、能读能写的文件夹。产品和资料都在这儿。
你在做什么、客户是谁、现在什么最重要、什么叫做好了。
动手之前先说一遍打算怎么做，你点头它才改东西。
一件具体的事，带一条你看得见的终点线。
做完自己打开看一眼、点一遍、跑一次，而不是交完就走。
改动照着你的标准过一遍，分成必须改 / 该改 / 可以发。
每天早上、每周五那些固定要做的事，自动发生。
三件不相干的事，三个会话同时推，互不污染。
能自己做的、要先问的、只有人能拍板的，分清楚。
Greg 的原话是：一旦这样搭起来，Claude Code 就不再像一个一次性的聊天工具， 更像你这摊事的一层操作系统。这句听着像宣传，但它其实是可证伪的—— 判据在文末：如果这个东西明天消失，你会不会难受？
my-first-employee），
在 app 里把它选成项目目录。这一步之后，Claude 才有「地方」可去。plan mode（先出方案不动手）· diff（改动前后对照）·
routines（定时任务）。后面每一节都会用到，现在只要知道它们存在。这不是那期视频的翻译，是重构：骨架、九块拼图的顺序、七天计划都来自视频， 提示词按视频里念出来的意思重写成了可以直接粘贴的中文版； 视频里的案例是一个软件产品（给医美诊所做的「漏单追回」小工具）， 而这篇的落点是你自己的分身——所以第 12 节专门做了一张换算表。
另外两处我按今天的实际情况校正过：视频里说的 ultra review，
现在的命令是 /code-review ultra（/ultrareview 是旧别名，还能用但已不是正名）；
视频里提到的模型是 Opus 4.8 与 Fable 5，现在最新一代是 Opus 5 这一家族。
产品界面每季度都在变，但「员工该有什么」这个骨架不会变——记骨架，别记按钮。
在开发者的世界里这个地方叫 repo（仓库），但你完全可以就把它理解成 一个文件夹——产品在里面、资料在里面、它的笔记也在里面。 重点不在于用什么词，而在于结构：一个新人走进一间东西乱堆的办公室， 第一周的产出一定是零。Claude 也一样。
Greg 给的骨架是五个文件夹加三个根文件。这套结构的可贵之处在于它不是按技术分的， 是按「一个生意有哪些部分」分的：
my-first-employee/ ├── CLAUDE.md ← 它怎么工作：工作方式、业务背景、质量线 ├── ROADMAP.md ← 这周什么最重要（以及什么明确不做） ├── REVIEW.md ← 什么才算做完：交付前的验收清单 │ ├── app/ ← 产品本体。代码、文件、真正的东西 ├── context/ ← 业务大脑。你是谁、买家是谁、承诺是什么 ├── customers/ ← 客户原话。通话记录、支持工单、被反驳的那些话 ├── demos/ ← 演示流程、录屏脚本、截图 └── routines/ ← 反复要跑的那些提示词
customers/ 是这套结构里最被低估的一格。
它的作用是让 Claude 不再从「你的意见」出发，而是从客户真正说过的字出发——
同一句卖点，用客户的原词写和用你的行话写，转化率不是一个量级。
这一格后面还会在第 10 节以 skill 的形式再出现一次。
你可以手动建这些文件夹，但没必要——让它自己建，顺便让它先问你缺什么。
帮我把这个仓库设置成一个「AI 员工工作区」。 创建或更新以下内容： CLAUDE.md、ROADMAP.md、REVIEW.md， 以及 /app、/context、/customers、/demos、/routines 五个目录。 用下面这段业务背景： · 产品：（一句话说清你在做什么） · 买家：（谁会为它付钱／谁真正在用） · 痛点：（他现在为什么难受） · 承诺：（你要替他解决的那一件事） · 当前目标：（这一周要做出来的东西） 在动手写之前，先问我任何会实质改变这套结构的缺失信息。 第一版保持简单。
最后那两行是整段里最值钱的。「先问我缺什么」把一次生成变成了一次面试—— 它会反过来问你三五个高杠杆问题，而那些问题往往正是你自己还没想清楚的地方。 Greg 演示时它的回应是：我先问你几个高杠杆的问题，答案会改变我怎么组织 demo 流程和客户资料这两格，其余我用合理的默认值填，并且保持 V1。
「第一版保持简单」是另一道闸。不加这句，你会得到一个二十个文件的漂亮骨架， 然后一个都不会用。
.md 只是纯文本，用记事本就能打开，别被后缀吓到。
这三个文件分工非常干净，而且顺序不能乱：先定「怎么工作」，再定「这周做什么」，
最后定「什么才算做完」。缺了第三个，你会收到很多看起来很努力的垃圾。
如果你招了一个初级同事，你一定会说一句「我希望你这样干活」。这个文件就是那句话的书面版。 三段就够：工作方式 · 业务背景 · 质量线。
优化 CLAUDE.md，让它更像一份「员工操作手册」。 【工作方式】 · 改动要小、要能被我一眼读完 · 涉及产品行为的改动，先讲计划再动手 · 一次只改一件事，不要顺手重构 · 沿用现有的代码风格与命名 · 改完跑一遍相关的检查 · 每次收尾都要总结三件事：改了什么、测了什么、哪里需要人来看 【业务背景】 · 这个产品在帮谁解决什么问题 · 买家是谁 · 我们对他的承诺是什么 【质量线】 · （例：落地页要让人在 5 秒内看懂） · （例：手机和电脑上都要能用） · （例：用客户真正说过的词，不要用行话）
「改完总结改了什么、测了什么、哪里需要人来看」——这一行会在接下来三个月里替你省下几十小时。 它把每一次交付都变成一份带自查的交接单，而不是一句「已完成 ✅」。
这个文件只回答一个问题：本周做什么。 但真正让它生效的，是另一半：明确写出「不做什么」。
更新 ROADMAP.md。 当前目标：（一句话，本周要做出来的那个东西） 这周聚焦四件事： 1. … 2. … 3. … 4. … 明确列为「本周不做」： · （例：支付） · （例：CRM 对接） · （例：后台管理页） · （例：多用户权限）
Greg 说他写「不做什么」的动机很直接：他想让它在 MVP 上使劲， 而不是把力气摊到二十个功能上。 这也是新手最容易漏的一段——你不划边界，它就会热情地帮你把边界撑到天上去。
这个文件是你的品味的书面化。它存在的意义只有一句：不许交垃圾。 而且它会在第 6 节被反复调用——你现在写的每一条，后面都会自动变成一次体检项。
这是我的验收清单，写进 REVIEW.md。交付之前逐条自查： 【通用】 · 这次改动符合当前 ROADMAP 吗 · 改动是否小到我能读完 · 主流程是否还能正常走通 · 手机上排版有没有问题 · 表单报错处理对不对 · 有没有碰到权限、支付或生产数据的风险 · 有没有引入不必要的复杂度 【这个项目特有的】 · （例：第一次来的人 5 秒内能看懂我们在卖什么吗） · （例：主按钮显眼吗） · （例：文案是不是对着买家说的） · （例：用的是客户真会说的词吗）
Greg 的说法值得一字不改地记住：模型越强，越需要护栏。 最新一代模型的执行力已经足够把一个模糊的要求做成一个精致的错误方向—— REVIEW.md 是唯一能把「精致」和「对」区分开的东西。
你交给一个真人一件重要的事，不会把任务从墙那头扔过去就指望他懂。 你会先聊：我想达成什么、什么最重要、有哪些限制、什么样才算不白干。 plan mode 就是这场对话的位置。
它的机制很简单：Claude 先四处看一看、读上下文、把活想一遍， 把打算怎么做摆给你看，然后停住，等你点头才碰文件。 老话说 measure twice, cut once——这一步就是那个「量第二遍」。
用 plan mode。
我要做的事：（一句话，具体到能验收）
先去看现在的实际情况，读 CLAUDE.md、ROADMAP.md、REVIEW.md。
然后给我：
1. 需要改动哪些文件
2. 最小、最干净的实现方式
3. 用户实际会经历什么
4. 有哪些风险
5. 我们怎么验证它真的成立
6. 第一版你打算「故意不做」的是什么
在我批准之前不要修改任何文件。
「先去读那三个文件」必须明说。不说的话它会凭一般常识给你一个通用方案， 那些你辛苦写下的业务背景和质量线就白写了——这是新手最常见的浪费。
第 6 条「故意不做什么」是我最喜欢的一条：它把 AI 从一个讨好型执行者， 变成一个会替你做减法的同事。而最后一行「批准之前不要改」是整段的闸门。
拿到计划之后你有三个选择：接受、否掉、或者改一改再来—— 「前端做就行，这只是个 demo」「表单太复杂了，名字邮箱公司三项就够」「先别碰登录和支付」。 它不需要一次到位，你只需要有个东西可以反驳。
这一节是新手把 Claude 用废的头号原因。它很擅长干活， 但它必须知道「干完」长什么样。 如果你带一个真人，你不会说「去把产品搞好」，你会说一件具体的事。
差别不在长度，在有没有终点线。 「更好」没有终点线，所以它只能猜；一旦它开始猜，你就不是在管理工作，你是在收拾工作。
按刚才那个计划实现，作为「一次聚焦的改动」。 改动幅度要小到我能在 diff 里读完。 改完之后： · 跑一遍相关检查 · 在预览里把这个页面打开 · 总结改了什么 · 告诉我你测了什么 · 告诉我还有什么需要人来判断
diff 就是「改动前后对照」——哪一行被加了、哪一行被删了，一眼看得见。 桌面版里它是可视化的：你能点进被改的文件、逐处翻、留言、让它改回去。
所以工单大小直接决定你能不能真的复核。 小工单你能读完；大工单交回来是一座看起来很壮观、但你没法信任的山。 规则就一句：一次一个工单，一条终点线，一份能读完的改动。
这是整份手册里最被忽略、性价比却最高的一节。 「眼睛」不只是打开浏览器看看——一个靠谱的员工做完事会： 自己打开、自己点一遍、跑一次测试、看看有没有报错、想一想客户走这条路会是什么感受。
为什么这件事非做不可：能跑起来 ≠ 好用。 页面能加载，但看不懂；表单能提交，但过程别扭；按钮在那儿，但没人注意到； 标题说清了产品，却没说中买家的痛。这些问题只有「打开看一眼」才会暴露。
把应用跑起来，检查（这条流程）。 在预览里打开页面， 用一个第一次见到它的（你的目标客户）的视角走一遍， 然后再从实现层面验证一次。 告诉我： · 前 5 秒他能看懂什么 · 哪里让人困惑、哪里让人不太敢信 · 表单到底能不能提交 · 提交之后发生了什么 最后，只针对影响最大的那一个问题，做一次聚焦的改进。
「只改影响最大的那一个」是关键约束。不加这句，你会收到十二处同时改动， 又变回了那座没法复核的山。
Greg 演示时它跑完给出的结论很能说明问题： 这个页面在要一个陌生人交出邮箱，却完全没告诉他这个候补名单是什么、会不会被骚扰—— 这是整页最大的摩擦点。然后它自己动手在按钮旁边补了一句预期说明。 这就是一个好员工会讲的话，不是一个代码生成器会讲的话。
同一个道理适用于任何工作：让它跑一遍测试、看一眼报错日志、 真的填一次那张表、核对一遍导出的数据对不对。 如果你的活不是网页，这一节请自己翻译一次——「做完之后，它凭什么相信自己做对了？」 这个问题一定有答案，只是需要你写出来。
这一节是让整套东西真的能用的那块拼图。因为一旦交付速度上去了， 问题就不再是「做得完吗」，而是：它解决的是对的问题吗？改的是对的文件吗？ 有没有制造一个奇怪的边界情况？对客户来说真的更清楚了吗？
复核分两层，缺一层都不行。
打开改动对照，翻一遍它碰过的文件，问自己三个问题：
这符合我给的工单吗？
这符合刚才批准的计划吗？
有没有什么让我意外的东西？——意外的地方，就是风险所在。 说好只加一个表单，结果登录、路由、数据库都被动了，你要在它上线之前知道。
第 2 节写的 REVIEW.md 在这里开始还本金。
用 REVIEW.md 作为标准，复核当前这批改动。 重点看：生产环境风险、被漏掉的边界情况、会让用户困惑的流程。 把问题分成三类： · 必须改（must fix） · 应该改（should fix） · 可以先发（okay to ship） 特别检查：bug、用户困惑点、安全风险、不必要的复杂度、 改到了工单范围之外的文件、以及任何违反 ROADMAP 的东西。
「必须 / 应该 / 可以」这个三分法是这段的灵魂。 它把一份让人焦虑的问题清单，变成一个可以当场做的决定—— 你只需要处理第一类，第二类记下来，第三类放行。
日常复核可以直接用 /code-review。
碰到真正有风险的东西——登录、支付、要上生产的大功能——用
/code-review ultra：它会开一场云端的多 agent 深度复核。
（视频里叫它 ultra review；/ultrareview 是旧别名，现在的正名是前者。）
到这里为止，所有事都发生在「你坐在它旁边」的时候。 而一个员工真正值钱的地方，是那些不用你在场也会发生的事。 每家生意都有这种活：有人得看一眼客户反馈、有人得注意到哪些问题在反复出现、 有人得把待办翻一遍说「这条今天该做了」。 不体面，但公司就是靠这些活在往前挪。
Claude 把这个叫 routines（定时任务）。 第一个定时任务，千万别让它改产品。 不要一上来就让它趁你睡觉往生产环境发代码——从一件「只读不写、有产出物」的事开始。
每个工作日早上 7 点： 读 /customers 和 /context， （如果连了 GitHub，也看一眼当前的开放 issue） 然后创建或更新 /context/morning-brief.md，写四件事： 1. 最新记录里最突出的那个客户痛点 2. 一个产品风险 3. 今天建议做的一件事 4. 今天我该去问客户的一个问题 不要改动生产代码，不要开 PR，全文控制在 500 字以内。
这个任务好在有用但可控：它不碰产品、不碰生产、不乱加功能， 只是把你的生意读一遍，然后给你一个更锋利的起点。
而「写进一个文件」这件事本身也很重要——原因见第 13 节的第二个坑。
每周五下午 3 点： 复核开放的 issue 和最近的客户记录， 把相关的问题归成一组，指出其中重复的， 提出这一周「杠杆最高的那一个修复」， 把总结写到 /context/weekly-ops.md。 不要改代码。
它真正的价值不是省时间，是看见模式： 三个客户在同一个环节卡住、同一个抱怨换了三种说法出现过—— 这些你一条条看的时候是看不出来的。它在这儿的角色更像一个参谋长。
每当有一个 PR（代码合并请求）被打开： 用 REVIEW.md 复核它。 只在这几类问题上留言：可能造成 bug、破坏用户流程、 安全隐患、行为让人困惑。 然后发一条简短总结：哪里做得好、哪里需要注意、 以及这个 PR 是否已经可以让人来看了。
这三个任务加起来，就是所谓「7×24 的员工」的真身： 每天早上有人告诉你什么最重要，每周有人替你找出重复的模式， 每次交付都有人拿着你的标准先过一遍。 不是它在替你写代码，是它在替你维持秩序。
到这里你有了一个员工。下一个问题很自然：能不能同时有五个、十个？ 能。桌面版里可以开多个独立会话，每个会话有自己的上下文、自己的一堆改动； 配上工作区隔离（worktree），这些改动不会互相污染。
心法只有一句：一个会话 = 一个人 = 一份明确的任务。 比如某个早上你想同时推三件完全不同的事：
邮箱验证之后跳转错了页，需要有人查清楚再修掉。 它该交回来：根因、改了哪些文件、跑了什么检查、我该在 diff 里重点看哪儿。
首屏标题太虚，要让目标客户在 5 秒内看懂价值。 它该交回来：改前改后对照、用了哪些客户原词、为什么新版本更清楚。
把一堆客户记录变成一份更锋利的演示脚本。 它该交回来：脚本本身、它想化解的那条异议、我录之前该先确认什么。
三件事互不相干，放在过去你只能一件接一件做。现在它们可以同时在跑， 共享同一份项目上下文，各自交回一个格式固定的小包裹。
不要在第一周就开五个会话。并行的前提是「任务切得干净」—— 如果三件事会改到同一批文件，你得到的不是三倍产能，是一场需要你手工调解的合并冲突。 先把一条链跑顺，再开第二个窗口。
这一节关系到你会不会某天早上醒来发现一场灾难。 把它当成带人来想就很清楚：有些事他可以自己做，有些事得先问一声， 有些事永远只能你来。
| 档位 | 包含什么 | 为什么 |
|---|---|---|
| 自由去做 | 读文件 · 通读项目 · 提方案 · 跑本地测试 · 在小分支上改一个功能 · 更新文档 · 开一个草稿 PR | 全部可逆，出错的代价是几分钟 |
| 先问我 | 装依赖 · 改数据库结构 · 碰登录鉴权 · 改支付逻辑 · 删文件 | 能恢复，但要花时间，而且可能悄悄坏掉别的地方 |
| 只有人能做 | 发布到生产 · 客户数据的处置 · 花钱的决定 · 安全相关的改动 | 就算你已经有十个 AI 员工，这一档还是人的。 |
桌面版里可以选权限模式。建议的路径是：一开始保守，大改动一律走 plan mode， 学习期全部手动确认；等到项目大脑、验收清单和任务边界都长结实了，再逐步放开。 Greg 的说法是：给 AI 施展的空间，同时给它边界；一上来就 YOLO 模式，风险太大了。
这也是为什么权限排在第 9 而不是第 1——放权的额度，是你前面八块拼图挣来的。
前面九块拼图搭出来的是一个通用员工。这一层让它只属于你。
判据只有一条：同一段提示词你敲到第三遍，它就该变成一个 skill。 Greg 在那个案例里做了三个，每一个都值得抄走思路：
落地页体检 — 每次调用，它就用目标客户的眼睛看这一页： 5 秒能不能看懂、哪句话是空话、缺哪些让人放心的信号、主按钮行不行，然后只提一个改进。
客户原话 — 读最新的通话和支持记录，抽出客户真正用的词、反复出现的异议、 以及触发购买的那些瞬间。之后写文案、写广告，都从这一份出发，而不是从你的想象出发。
演示脚本 — 把当前产品状态 + 最新客户记录，变成一段 「痛点 → 产品瞬间 → 收益」的三段式脚本。这一个每周就能省几小时。
连上 GitHub、Google Drive、Slack、Linear 这类地方， 让它不必等你把资料复制粘贴过去。本质上是在扩大它的「记忆」那一格。
Hook 是「每次发生 X 就自动做 Y」的规则：改完代码自动格式化、 提交前自动跑测试、上线前自动跑那几项该跑的检查。 skill 让工作可复用，connector 让上下文更全，hook 让流程更安全。
Greg 说这份计划你可以用 7 小时跑完，也可以用 70 分钟、7 天、31 天—— 取决于你有多少时间、多熟。但顺序建议别改。
| Day | 做什么 | 做完你手上有什么 |
|---|---|---|
| Day 1 | 建大脑。 三个 .md + 五个文件夹。写清楚客户是谁、问题是什么、当前目标、什么叫做完 | 一个能自己解释自己的工位 |
| Day 2 | 跑一次 plan mode。 挑一件小事，逼它先读项目再开口 | 一份计划、一张改动文件清单、风险、验证方式 |
| Day 3 | 做一处看得见的改进。 小到能复核，真到能给人看 | 一个真实的改动，和一份「改了什么/测了什么」 |
| Day 4 | 用眼睛那一环。 让它自己打开、点一遍、看手机端、改清楚一处 | 一份来自客户视角的体检报告 |
| Day 5 | 复核。 自己读 diff，再让它照 REVIEW.md 分出必须/应该/可以 | 一次没有惊吓的交付 |
| Day 6 | 发给 10 个真人。 演示、录屏、页面，什么都行；把他们的回复原样丢进 /customers | 第一批不是你想象的真实语料 |
| Day 7 | 建第一个定时任务。 从晨报开始，让它读客户记录，推荐今天做的一件事 | 一个会自己转起来的循环 |
前五天都在跟机器打交道，第六天要去跟人打交道，所以它天然让人想跳。
但跳掉它，你的 /customers 就永远是空的——
而那一格空着的话，第 2、5、7、10 节里所有依赖「客户原话」的机制全部退化成你的自言自语。
整套系统的输入口只有这一个。
上面所有例子都长着「软件创业」的样子——落地页、候补表单、PR。 但大多数第一次接触 agent 的人不是要做一个 SaaS，是想让一个东西替自己干那些 「只有我会做、而且我每周都要做一遍」的事。
好消息是：九块拼图一块都不用换，只用换填进去的内容。 整份手册真正的通用结构，就是下面这张换算表：
| 手册里的 | 换成你自己的 | 具体长什么样 |
|---|---|---|
| app/ | 你真正交出去的东西 | 那份每月要发的报表、那批要回的邮件、那个总在改的表格、你在写的稿子 |
| context/ | 只有你脑子里有的背景 | 这摊事的规矩、哪些人在意什么、去年为什么放弃了那个方案、哪些坑不能再踩 |
| customers/ | 别人对你说过的原话 | 邮件原文、会议纪要、群里那条抱怨、上一次被打回来时对方的措辞 |
| demos/ | 你「做得好的那次」的样本 | 上一份被夸过的报告、那封回得漂亮的邮件——这是它模仿你的唯一素材 |
| ROADMAP.md | 这周你真正要交的三件事 | 加上「这周不碰的东西」，比要做的那半更重要 |
| REVIEW.md | 什么叫「这活干得像我」 | 你的口气、你不会说的话、你一定会核对的那三处、你的底线 |
| routines/ | 你每周都要做、但总是忘的那件事 | 周五的复盘、月初的对账、每两周该发的那次跟进 |
注意 demos/ 这一行——在产品语境里它是录屏脚本，
在分身语境里它是整套东西里最重要的一格：你「做得好的那一次」的样本。
风格是学不来的，但风格是抄得到的。你给它三份自己满意的旧作，它的输出会立刻不一样。
如果你完全不知道从哪件事开始，用这个判据挑： 过去三个月里，你重复做过至少四次、每次都要花 30 分钟以上、 而且做完之后没有人会夸你的那件事。 不是最难的事，也不是最重要的事——是最像「常规运营」的那件事。 那就是第一个数字员工该接的活。
帮我把这个文件夹设置成一个「数字分身工作区」。 创建：CLAUDE.md、ROADMAP.md、REVIEW.md， 以及 /work（我真正交出去的东西）、/context（背景与规矩）、 /voices（别人对我说过的原话）、/samples（我做得好的那几次）、 /routines（每周固定要做的事）。 背景： · 我的角色：（一句话） · 我要它替我干的第一件事：（那件重复了四次以上的事） · 这件事做得好的标准是：（说人话，不要写 KPI） · 这件事做砸的样子是：（同样具体） · 有哪些事它绝对不能自己做：（发出去、删掉、替我答应别人……） 动手之前先问我任何会实质改变这套结构的缺失信息。 第一版保持简单。
多了一行 「做砸的样子」。做产品时质量线可以写成正面清单， 做分身时不行——你对自己的活最清楚的部分，往往是「什么样绝对不行」。 把这一行写具体，抵得过十条正面标准。
上面十二节照抄，你能到 80 分。剩下的 20 分不在提示词里， 在「第八天你还会不会打开它」这件事上。 这三个坑我全踩过，而且不止一次。
我给自己搭过五六个不同职能的 agent 格子，结构齐整、文档漂亮。 去年做过一次盘点，其中两个从建成那天到盘点那天的真实使用次数，是零。
搭建的过程本身太爽了——它像在做一件正经事，还看得见进度。 但一个从没接过真活的数字员工，不是员工，是一份文档。 补救办法只有一个：建完当天，就丢一件明天真的要交的事给它。 不是测试用例，是真事。
我的定时任务停摆过整整一个月，我才发现。 没有任何东西会告诉你「你的 agent 今天没上班」—— 它不像一个人那样会缺席得很明显，它就是安静地不再出现。
所以第 7 节那句「写进一个文件」不是随口一提，是防呆设计： 让每个定时任务都在固定位置留下一个带日期的产出物。 你扫一眼文件夹，最新那份是哪天的，一目了然。 能被一眼看出死掉的循环，才是活的循环。
我最容易犯的错，是想把九块拼图全部设计完美，再让第一件真事进来。 于是三周过去了，系统很完整，产出是零。
正确的顺序是反的：先让一件真事从头到尾走完一遍， 哪怕另外八块拼图都还空着。 缺口会自己告诉你该补哪一块——而且它指出来的那一块， 几乎从来不是你原本打算先建的那一块。
搭完之后，隔两周问自己一句：如果这个数字员工明天彻底消失，我会不会难受？
会难受——恭喜，它已经接住了一件真事，接下来的问题只是给它更多权限。 不会——那它还只是一个漂亮的文件夹，问题不在提示词，在你还没敢把一件真事交给它。
这份手册里有十二段可以照抄的提示词，但它们不是重点。 重点是那个被换掉的比喻：从「我要怎么问它」，换成「我要怎么带它」。 前者永远在追新技巧，后者是一套一年后还成立的手艺。
一旦你这样搭起来，Claude Code 就不再是一个聊天框了—— 产品、客户反馈、文档、演示、复核、那些每周都要做的事， 全部住进同一个会自己转的循环里。 它不会一开始就好用，需要你不停地修； 但你一旦这样建过一次，就再也回不去从前那种建法了。
所以第一天不要贪多。建一个文件夹，写三个 .md，挑一件你重复了四次的事， 然后在第七天给它排第一个班。 七天之后你手上不会有一个惊艳的 demo—— 你会有一个循环。而循环是会自己长大的东西。
/code-review ultra（/ultrareview 为旧别名）；视频里提到的模型是 Opus 4.8 / Fable 5，当前最新一代为 Opus 5 家族。