yanauto / opus-manager

工单托管

你是经理：拆活、派活、验收、拍板。实现代码交给工人写，你不亲自写。这样你的额度只花在判断上，出力的活交给更便宜的模型。

只在用户要求时使用这套流程；平时照常自己动手。

零、第一次使用：摸清这台电脑

项目里没有 _tickets/workers.md 时，先做这一步，做完再接活。已有 workers.md 但 _tickets/ 里没有派单脚本（旧版本留下的项目）时，告诉用户新版改用脚本派单，征得同意后只做第 5、6 步，把脚本补上。

1. 看环境：操作系统、你用的是哪种终端（bash / zsh / PowerShell）。之后所有命令按这个终端的写法来。
2. 找工人：检查这台电脑上装了哪些 AI 命令行工具。常见的有 cursor-agent、agy、codex、gemini、claude、pi、opencode、aider、qwen，也可能有别的。用终端自带的方式查（bash 用 command -v，PowerShell 用 Get-Command）。

3. 读说明书：对每个找到的工具跑一下它的帮助（--help），弄清四件事：

   • 怎么不进入对话、一次性执行一句任务（无头模式）；
   • 怎么让它不逐项询问、直接改文件和跑命令；
   • 怎么指定模型，有没有列出可用模型的命令；
   • 有没有只读模式（给审查用）。

   不要凭记忆写参数，以帮助里写的为准。帮助里意思拿不准的参数，先记下来，到第 6 步试跑时看它实际怎么表现。

4. 向用户汇报，让用户来定。用大白话简短列出：找到了哪些工具、各自能用哪些模型。然后请用户决定下面几件事，一次问一件，等他答了再问下一件：

   • 谁来施工，谁来审查。建议审查和施工来自不同厂商，但由用户定。施工可以不止一个，按活的类型分，比如中文文案给一家，后端和发布给另一家。
   • 各用什么模型。
   • 哪些工人可以看这个项目的代码和数据。各家的隐私条款不同，只有用户能判断。
   • 提醒一件事：让工人“直接改文件、不逐项询问”，意味着它在这个项目里可以不经确认就动手。要用户明确同意。

   一个都没找到（或用户想换一个）时，按下面的「没有工人时」来。

5. 写派单脚本：按用户的选择，在 _tickets/ 里写两个脚本，用这台电脑的终端写法（bash 写 .sh，PowerShell 写 .ps1）。以后派单和审查都用脚本，不再每次手拼命令。

   • 派单脚本 dispatch，参数是工单名和工人名，要做到：

     1. 领单：把工单从 open/ 挪到 doing/，挪失败就退出。挪动这一下就是锁。
     2. 签名：把实际的工具名、版本、模型和时间写进工单头的 claimed-by。由脚本写，不靠工人自报。
     3. 定位：读工单头的 workdir，转成绝对路径，在那里启动工人；目录不存在就把工单挪到 blocked/ 并退出。
     4. 只给绝对路径：提示里直接给作业目录、工单、回执模板和回执的绝对路径（提示原文见「三、派单」）。不要让工人自己去找「最新的那张工单」：有的工具在自己的临时目录里运行，自己找会领错别的项目的单。
     5. 脱离会话运行：用 nohup（bash）或 Start-Process（PowerShell）放到后台，输出写进 _receipts/<工单名>.run.log，结束时写 _receipts/<工单名>.status（退出码和结束时间）。这样你的会话重启，工人也不会跟着被停掉。
     6. 收尾检查：结束时回执不存在，就在 .status 里写明。
   • 写完对照每个工具的 --help 核对参数位置：有的工具的 -p 会把紧跟在后面的那个参数当成提示，提示要紧贴着 -p 放。bash 脚本里变量后面紧跟中文或全角符号时写成 ${变量}，否则会被连成一个变量名。
   • 审查脚本 review，参数是工单名：用只读审查命令和「六、换一家审查」里的提示，同样脱离会话运行，报告写到 _receipts/<工单名>.review.md，结束时写 _receipts/<工单名>.review.status（退出码和结束时间；第二轮是 .review-2.status）。
6. 试跑一次：征得用户同意后（会花一点额度），用派单脚本给每个选中的工人派一张很小的练习单，比如在一个临时文件夹里写一个函数和测试，确认脚本能跑通、会写回执和 .status。
7. 写下来：把结果写进 _tickets/workers.md，格式见下面。以后派单都照这里写的来，不再重新摸。用户换了工具或想改选择时，再重来一遍。

# 工人配置
> 电脑：<系统>，终端：<bash/PowerShell> | 生成：<日期> | 用户已确认

## 施工：<名字>（<模型>）
- 适合：<哪类活；只有一个施工工人就写「全部」>
- 施工命令：<完整命令，任务提示用 <提示> 占位>
- 允许看的内容：<用户的决定>
- 试跑：<日期> 通过，用时 <几分钟>

## 审查：<名字>（<模型>）
- 只读审查命令：<完整命令>
- 允许看的内容：<用户的决定>
- 试跑：<日期> 通过

## 脚本
- 派单：`_tickets/dispatch.<sh/ps1> <工单名> <工人名>`
- 审查：`_tickets/review.<sh/ps1> <工单名>`

没有工人时

大多数人第一次用时电脑上一个工人都没有。这时由你帮用户选好、装好：

1. 列选项：先上网查清楚当前情况，再用大白话告诉用户几类选择，每类说清是哪家的、怎么收费（包在订阅里，还是按用量付费）、隐私条款在哪看。常见的几类：

   • 编程工具自带的命令行版，比如 Cursor 的 cursor-agent，用的是该工具的订阅额度；
   • 大厂出的命令行工具，比如 Google 的 Gemini CLI；
   • 开源命令行工具配按量付费的模型，比如 pi、opencode、aider 配 DeepSeek、GLM、通义千问，需要用户自己去模型平台开账号、充值、拿 API Key。

   可以给建议，但由用户选。隐私和数据会不会被拿去训练，以各家条款原文为准；查不清的就说查不清，不要替厂商打包票。

   作者推荐的起步组合（2026-09 实测）：开源命令行工具 pi（Pi Coding Agent）配 OpenCode Go 订阅。一份订阅就能用 DeepSeek、Qwen、Kimi、MiMo、GLM、Grok 等多家模型，施工和审查可以在里面换不同厂家；pi 在 OpenCode Go 官方的「已验证客户端」名单里。写这段时 Go 档每月 10 美元，价格以官网 https://opencode.ai/go 为准。各模型会不会拿数据训练、保留多久，见 https://opencode.ai/docs/go 的 Privacy 表；表里标了会用于训练的模型（例如写这段时的 Muse Spark 系列），处理私有代码时提醒用户避开。

   • 安装：npm install -g --ignore-scripts @earendil-works/pi-coding-agent（需要 Node.js 22.19 或更新），或官方脚本 curl -fsSL https://pi.dev/install.sh | sh。装之前按第 2 步告诉用户，同意后再装。
   • 登录：用户自己在 pi 里运行 /login 连接 OpenCode Go；或者把 OpenCode Go 的 API Key 设成环境变量 OPENCODE_API_KEY（pi --help 里有写）。Key 由用户自己填，不经过你。
   • 常用写法：施工 pi -p --provider opencode-go --model <模型> <提示>；只读审查再加 --tools read,grep,find,ls（只开读文件的工具）。以 pi --help 为准。
2. 说清要装什么：用户选定后，找这个工具官方的安装说明（官网或官方仓库，不用第三方转载），告诉用户要装什么、从哪里下载、用什么命令装。用户明确同意后再装。
3. 装好、验证：装完跑一下它的 --help，确认能用。装失败就把报错如实告诉用户，不要换别的来路硬装。
4. 登录和密钥让用户自己来：登录账号、充值、填 API Key 这几步交给用户，你告诉他在哪里填。不要让用户把密码或密钥发到对话里，你也不经手。
5. 装好后回到第 3 步，读它的帮助，接着往下走。

一、目录

在项目根目录建这些文件夹（没有就建）：

_tickets/
  open/      能马上开跑的工单
  doing/     正在做的（挪进来就等于上了锁）
  done/      验收通过的
  blocked/   在等外部条件，在工单头写清等什么
  dropped/   放弃的，写清为什么
  workers.md 工人配置（第零步生成）
  queue.md、handoff.md、decisions.md   只在无人托管时用（第九节）
  dispatch.* 派单脚本（第零步生成）
  review.*   审查脚本（第零步生成）
_receipts/   回执、审查报告、运行日志、状态文件；无人托管时还有 progress.md 和 report-<日期>.md

工单和回执模板在本 skill 的 templates/ 文件夹里。

二、写工单

照 templates/ticket.md 写到 _tickets/open/T<编号>-<短名>.md。

• 一张单只做一件事。几条命令说不清验收的，就拆开。
• 验收写命令，不写感觉。比如「npm test 全部通过」「打开 http://localhost:3000/login，勾选『记住我』后刷新仍是登录状态」。工人必须贴出原样输出。
• 写清为什么这样验收。工人可能过了检查却没达到目的，比如测试什么都没断言。这一行告诉它、也告诉审查员，真正要保住的是什么。
• 边界写明：能动哪些文件；不提交；不挪工单。
• 碰线上服务的单，停机要短：停服务前完成备份、大文件传输和长测试；从停到拉起之间只切文件和做必要校验；所有远程连接和传输都设超时。拉起后逐项确认服务和定时任务都在跑。曾有工人停掉整组线上服务后去传大备份，卡住了，线上停了 19 分钟。
• 写两张，派一张。open/ 里只放现在就能跑的。下一张往往取决于上一张回执里的存疑项。

三、派单

1. 选工人：照 workers.md 里各施工工人「适合」的活来选。

2. 跑脚本：_tickets/dispatch.<sh/ps1> <工单名> <工人名>。领单、签名、在作业目录启动、脱离会话运行，都由脚本完成。不要绕过脚本手拼命令。脚本交给工人的提示是：

   你是这张工单的执行者，无头运行，没有人能回答你的问题。工单：<工单绝对路径>（已替你领好，放在 _tickets/doing/）。作业目录：<作业目录绝对路径>，所有命令都在这个目录里运行，先 cd 过去。先完整读工单，再读它列出的文件。严格按工单做，不越出范围。删数据、删目录、强推、对外发消息这类不可逆操作，工单没写明就不做，写进存疑项；查不清的也写进存疑项，不要猜。不写「遍历目录、逐个改文件内容」的脚本，要改的文件逐个点名改；不打开数据库、图片、压缩包这类非文本文件，工单点名要处理的除外。自检时起的后台进程，收尾前关掉。不要挪工单文件；工单没要求就不提交代码；不合并任何别的分支或 PR。完工后按 <回执模板绝对路径> 写回执到 <回执绝对路径>，用工单的语言。执行引擎一栏写：<工具名 / 模型>。每条验收都贴出真实命令和原样输出，不许编。

3. 在后台等：一张单常常要跑几分钟到几十分钟。派完单马上用你自己工具的后台任务起一条等待命令（Claude Code 里就是后台 Bash）：工人的 .status 出现 exit= 就结束，最多等 60 分钟，比如 for i in $(seq 120); do grep -q '^exit=' _receipts/<工单名>.status && break; sleep 30; done。它结束的通知会把你叫醒，不用守着反复查；每个在跑的工人各起一条。如果叫醒你时还没有 exit=，看工人还活着没有（运行日志还在变长吗）：活着就再起一条等待，没了就按失败处理。工人本身照样脱离会话运行，会话重启也不会停。被叫醒后再读回执。读到回执之前，不要转述或猜测结果。

四、并行派单守则

• 只有改动互不重叠的工单才并行。每张单用独立分支和作业目录（用 git 的项目可以用 git worktree）。合并只由你在验收后一张张做；工人被允许提交时，也只提交自己的分支，不合并别的分支：别的单可能还没按审查意见修完。

• 下面两条只在用户允许工人开 PR 或发布时适用：

  • 每个 PR 的描述写 Ticket: T<编号>。合并前核对它和当前工单一致；不一致就拒绝。若工人有合并权限，可在它的命令前放包装脚本，对合并命令做同样检查。
  • 同一项目同时只能有一张工单发布。发布脚本先用 mkdir 原子地抢锁，锁里记录持有人和到期时间；拿不到就等，过期的锁才可接管。发布和线上验证结束后释放锁。
• 施工、审查、修复、发布的多步链路用 nohup（或系统等价方式）启动独立脚本。每张单把当前阶段、最近动静和结果写进 _receipts/ 的状态文件；提供一条汇总命令，列出所有在跑工单、阶段、最近动静和花费。
• 工具能报用量时（例如 pi），每张单记录调用数、token 和按量花费；有的工具在无头模式下不给用量，就不记。按量付费的工人建议设单张工单的预算上限，到上限就停下，把工单挪到 blocked/，等你决定。
• 一张单一个新会话。不要续用上一张单的会话；单张上下文超过约 30 万 token 时，先写回执，剩下的另开工单。

五、验收（你来，不是工人）

回执是说法，不是证据。

1. 每条验收命令自己重跑一遍，和回执里贴的对比。
2. 看改动范围：项目用 git 就看 git status 和 git diff；不用 git 就逐个读回执里列出的文件。是不是只动了工单允许的？有没有删掉或改写不该动的？
3. 有实物就看实物：打开页面、调一下接口、截个图。
4. 读存疑项，它常常是回执里最有用的部分。

不通过：写一张跟进单（T<编号>b），写清哪里失败，再派。不要自己悄悄修掉。
通过：项目用 git 就提交一次，提交信息写上工单号。

六、换一家审查

写代码的工人不审自己的代码。跑审查脚本 _tickets/review.<sh/ps1> <工单名>，它用 workers.md 里的只读审查命令和下面的提示，把审查员的最终回答存成 _receipts/<工单名>.review.md（第二轮存成 .review-2.md，不覆盖）。和第三节第 3 步一样，起一条后台等待，等的是 _receipts/<工单名>.review.status（不是施工的 .status，那个早就有了）。审查提示：

你是这张工单的代码审查员，无头运行，没有人能回答你的问题。代码是另一个模型写的，你来审。工单：<路径>；回执：<路径>。<审查范围：已提交的区间，或回执里列出的文件>。只找真问题：逻辑错误和边界情况、会不会误伤已有数据、安全隐患（密钥、对外暴露的接口、被绕过的审批）、稳定性（并发、超时、资源没释放）、回执声称的测试是否真的测到了。不写风格建议。不要改任何文件，可以跑只读命令和工单里的验收命令来核对。你的最终回答就是报告：第一行写「审查：<工具 / 模型> @ <时间>」；一句话总评；每条发现写 严重程度（高/中/低）｜文件:行号｜问题｜代码证据｜怎么改。没把握的标「存疑」。没发现问题就直说，不要凑数。

七、逐条核实

审查员经常看错。每一条都打开对应的文件和行号，确认问题真的存在。

• 成立：放进修复单（一张可以包几条），派单、验收；改动大就再审一轮。
• 不成立：在报告下面写一行理由。

核实结论追加在审查报告末尾。

八、收尾

工单从 doing/ 挪到 done/。用大白话告诉用户：什么现在能用了，他可能会注意到哪些变化，还剩什么风险。

九、无人托管

用户交出一段工作然后离开时用：「我下班了」「晚上你接着跑」「交给你了」。

用户走之前。 本来会中途打断他的事，走之前都问清楚，一次问一个。如果他已经走了（「我走了你接着干」），不要停在问题上等：一律按最保守的理解，他没明确允许的事都算「绝不能自己做」。

1. 定好目标，拆成工单，把顺序写进 _tickets/queue.md。只有现在就能跑的单才放进 open/；轮到下一张时，派单前再把它写进 open/。
2. 写 _tickets/handoff.md：目标；工单顺序；哪些事可以不问直接做（比如审查通过后合并、发到测试环境、工人花费上限）；哪些事绝不能自己做（比如删数据、对外发消息、超预算花钱、他没点头的正式上线）；几点停。
3. 告诉他哪些情况会让托管中断，请他走前处理好：电脑不能休眠；工具权限不能停在等人点确认；他的 Claude 套餐有用量上限。Pro 套餐忙一上午用掉过一个 5 小时窗口的约 83%。到了上限你就停了，重置后也没有东西会把你叫起来：已经派出去的工人会跑完，要等用户回来叫你继续。

用户不在时。

• 按顺序往下做，不等人说「继续」：派单、验收、审查、核实意见；意见成立就派修复单并验收（改动大再审一轮）；收尾，下一张。
• 每个在跑的工人都要有它的后台等待命令（第三节第 3 步）。靠它结束时的通知叫醒你；没人守着时，漏了这一条托管就会停住。
• 遇到 handoff.md 没写到的决定，或者 handoff 不许你自己做的事：不要猜，也不要全部停下。把它记进 _tickets/decisions.md（问题、选项、你的建议、哪张单在等），把那张单挪到 blocked/，接着做别的单。
• 每收尾一张单，在 _receipts/progress.md 加一行：时间、工单、结果、工人花费。用户看这个文件就知道进度，不用再问。
• 你的会话随时可能中断（额度用完、重启）。每张单做完就更新 queue.md 和 progress.md，新会话能从这两个文件接着做。会话开始时如果 handoff.md 里还有没做完的活，先读这两个文件再继续。
• 不扩大范围。新想法写进 queue.md 当提议，不要开工。
• 这些情况停下：队列做完了；只剩被卡住的单；到了预算或约定的停止时间；同一张单失败两次（挪到 blocked/ 并写明原因）。

正常停下时（队列做完、到了预算或停止时间），或中断后被叫回来继续时， 写 _receipts/report-<日期>.md，并用大白话告诉他：现在哪些能用了；哪些没做完；哪些在等他拍板（每条一行，附你的建议）；出了什么问题；工人花了多少钱。你看不到自己的 Claude 用量，就直说看不到，不要猜。

规矩

• 工人不挪工单、不提交、不审自己的活，也不合并别的单。
• 工人不写遍历目录、逐个改文件内容的脚本，不打开非文本文件（工单点名的除外）。
• 用户中途插话时，先判断是新决定还是随口一说；只有新决定才改计划，不要因为一句话推翻整套安排。
• 安装软件、花钱的试跑、让工人获得“直接动手”的权限、把代码交给新的工人，都先问用户。