同样的话，每天都要说一遍
用 Claude Code 久了，很多人会发现自己在重复同样的提示：「先看一下改动范围，再按我们的规范审查」「补测试时只用项目现有的测试框架」「发版前把版本号、更新日志、构建结果都核对一遍」。每次手打不但慢，而且这次漏一句、下次换个说法，结果就不稳定。
Claude Code 本身提供了两种把流程固定下来的办法：
- 子代理（subagents）：一个有独立系统提示、独立上下文、可以限定工具范围的「专职助手」，比如专门做代码审查的、专门写测试的。主会话把任务交给它，它做完把结论交回来，中间的大量读文件过程不会塞满主会话的上下文。
- 自定义斜杠命令：把一段常用提示存成文件，之后在会话里输入
/命令名就能调用，还可以带参数。
这两样东西都是普通的 Markdown 文件，放在项目的 .claude/ 目录里，跟代码一起进 git。把它们放在一台常开的 Mac mini 上，你从任何地方连进去，用的都是同一套流程。下面按步骤搭一遍。
准备清单
- 一台常开、不休眠的 Mac mini，已安装 Claude Code 并用你自己的 Claude 账号登录（账号由你自己开通，不共享给别人用）。
- 能用 SSH 或 UU 远程连接登录这台机器，终端里装好 tmux。
- 一个要长期维护的 git 仓库，已经克隆到 Mac mini 上，例如
~/work/app。
步骤一：先规划要固化哪几件事
不要一上来就写十几个子代理。先挑出你每周至少做三次、而且要求比较固定的事，通常是这几类：
- 代码审查：看本次改动有没有明显缺陷、风格问题、遗漏的错误处理。
- 补测试：给新改的函数补单元测试，只用项目已有的测试框架。
- 发版前检查：核对版本号、更新日志、构建和测试是否全部通过。
一件事一个子代理或一个命令，职责单一，后面才好调整。
步骤二：写第一个子代理
在仓库里新建 .claude/agents/code-reviewer.md。文件开头是一段用三条短横线包起来的配置，常用字段有：
name：子代理的名字，例如code-reviewer。description：写清楚「什么时候该用它」，Claude Code 会根据这句话判断是否把任务交给它，所以要具体，比如「在完成一次代码修改后，用于审查本次 git 改动」。tools：允许它用的工具，审查类子代理只给Read, Grep, Glob, Bash就够了，不给写文件的工具，避免它在审查时顺手改代码。model：可选，不写就跟主会话一致。
配置下面是正文，也就是它的系统提示。写法建议：
- 第一步先运行
git diff看改动范围，只审查改动涉及的部分。 - 按「必须修改 / 建议修改 / 可以忽略」三级列出问题，每条附上文件名和行号。
- 不确定的地方明确写「不确定」，不要猜。
- 不修改任何文件，只输出审查结论。
也可以在 Claude Code 会话里输入 /agents，按界面提示创建，生成的文件同样落在 .claude/agents/ 下，之后再手动细化。
步骤三：再写一个会改代码的子代理
补测试的子代理需要写文件，所以单独建 .claude/agents/test-writer.md，tools 里加上编辑类工具。正文里把边界写死：
- 只在测试目录里新增或修改文件，不动业务代码。
- 只用项目现有的测试框架和断言风格，先读两三个已有测试文件模仿写法。
- 写完必须运行测试命令，失败就如实报告失败原因，不要为了让测试通过去改业务逻辑。
读写范围最好再用项目 .claude/settings.json 里的 allow / deny 规则兜一层底，比如禁止读取 .env 和密钥目录。子代理的提示是「软约束」，权限规则才是「硬约束」，两者配合更稳。
步骤四：把常用提示做成斜杠命令
有些流程不需要独立上下文，只是一段固定提示，用斜杠命令更轻。新建 .claude/commands/release-check.md，正文写发版前要核对的清单：
- 读取版本号文件，确认已经比上一个标签高。
- 检查更新日志里有没有这个版本的条目。
- 运行构建和全部测试，汇总结果。
- 任何一项不通过就停下，列出原因，不要自动打标签或推送。
之后在会话里输入 /release-check 就会执行这段流程。命令文件里可以用 $ARGUMENTS 接收参数，例如做一个 /review-file，正文写「审查 $ARGUMENTS 这个文件」，调用时输入 /review-file src/api/order.ts。文件开头同样可以加 description 等配置，在命令列表里显示用途。
如果有些命令和子代理你在所有项目里都想用，就放到用户目录下的 ~/.claude/agents/ 和 ~/.claude/commands/；只和某个项目有关的，放在项目的 .claude/ 里。
步骤五：纳入 git，让整套流程跟着仓库走
把 .claude/agents/、.claude/commands/ 和 .claude/settings.json 提交进仓库。这样做有三个好处：
- 每次修改流程都有记录，改坏了可以回退。
- 团队里其他人拉下代码就能用同一套子代理和命令，用各自的 Claude 账号即可。
- 换机器、重装系统时，流程不会丢。
个人偏好的设置放在 .claude/settings.local.json，并加进 .gitignore，不要和团队共享的配置混在一起。
步骤六：在 Mac mini 上常驻使用
在 Mac mini 上用 tmux new -s app 开一个会话，进入仓库目录启动 claude。日常用法大致是：
- 让主会话完成一个功能修改。
- 说一句「用 code-reviewer 审查这次改动」，或者等 Claude Code 根据描述自动交给它。
- 根据审查结论修改后，再让 test-writer 补测试。
- 准备发版时输入
/release-check。
人离开时按 Ctrl-b d 把会话挂在后台，之后从笔记本或手机用 SSH 连回来，tmux attach -t app 就能接着看结果；需要看图形界面时，用 UU 远程连接进桌面。
用一段时间后，记得回头调
- 子代理经常没被自动调用，多半是
description写得太泛，改得更具体。 - 审查结论太啰嗦，就在正文里限制输出条数和格式。
- 某个命令一个月都没用过，删掉，保持清单短小。
为什么放在一台常开的新加坡整机上
子代理和命令解决的是「流程一致」，但前提是运行它们的环境本身也一致：同一台机器、同一套工具链、同一份配置，随时能连上。笔记本合盖、换电脑、临时用别人的机器，都会让这套流程断掉。Zumac.Ai 提供新加坡家庭宽带接入的 Mac mini M6，整机独享、一人一台物理机，适合把 Claude Code、仓库和这些 .claude/ 配置长期放在上面，作为一个稳定合规的使用环境。你用 SSH 或 UU 远程连接随时进去调用，实际连接体验取决于你本地的网络线路。
小结
把重复的要求写成文件，而不是每天重新说一遍：需要独立上下文、限定工具的工作交给子代理，固定的一段流程做成斜杠命令，再用权限规则兜底、用 git 管理版本。整套东西放在一台常开的新加坡 Mac mini 上，Claude Code 每次都按同一套标准干活，你只需要连进去说一句话。
