如果你丢给 AI 的每个任务，都有一整个团队帮你看——而不是只有一个声音？
OPC (One Person Company) 会根据每个任务动态组建合适的专家团队。安全审计？它会拉一个安全工程师进来。新功能？PM、设计师、新用户视角同时上场。需要自定义专家？扔一个 markdown 文件进去——你的团队随时扩展。
一个斜杠命令，覆盖整个产品生命周期。/opc review、/opc analyze、/opc brainstorm。
但它真的比直接问 Claude 好吗？
诚实的对比测试
同一个代码库（OPC 自己的 repo），两种方式：
直接让 Claude review：找到了 14 个问题。变量 shadowing、DRY 违反、exit code 缺失。细致、精准、聚焦代码层面。
OPC（3 个 agent：新用户、安全、DevOps）：找到了 9 个问题。代码 bug 更少。但抓到了 5 个 Claude 完全看不到的东西：
- 新用户会在 terminal 里直接跑
opc review（以为是 CLI 命令），结果只看到帮助信息，不知道要在 Claude Code 里用 - README 里的 symlink 命令假设你在父目录——但正常人 clone 完会 cd 进去，symlink 就断了
- postinstall 失败的提示信息没告诉你失败长什么样
- Claude Code 的链接指向营销页，不是安装文档
这些不是代码 bug，是视角 bug — 只有当你切换到某个特定角色的思维时才会发现。
OPC 的价值不是找更多 bug，是找你想不到要去看的 bug。
OPC 到底是什么
说白了：
- 11 个 markdown 文件 — 每个定义一个专家角色，包括专业领域和 anti-patterns（“不要在本地工具上标记缺少认证”）
- 并行 Claude 调用 — 2-5 个 agent 同时跑，各有不同 system prompt
- Coordinator 验证 — 检查 agent 输出的事实、质疑严重程度、去重、过滤误报
Agent 之间不互相通信。没有真正的”协作”。我不会假装这是什么 multi-agent 突破。
但它解决了一个真实问题：/opc review 10 个字符，比每次手写”从安全、新用户、DevOps 角度 review”的 prompt 省事太多。省事 = 会真正用起来。
真正有用的设计
Anti-patterns：每个角色文件定义了”不要做什么”。安全 agent 不会对本地 CLI 工具标记”缺少认证”。新用户 agent 不会对开发者工具要求”新手引导”。这个设计避免了 AI review 工具最大的问题——generic checklist。
Verification gate：Coordinator 不只是合并输出。它有明确的检查项：“这个 finding 有 file:line 引用吗？严重程度和实际影响匹配吗？agent 真的读了 scope 里的文件吗？” 这能抓住 agent 偷懒的输出。
结构化输出：每次 review 存 JSON 到 ~/.opc/reports/，可以用 npx @touchskyer/opc-viewer 在浏览器里看——像 Slack 频道一样回放你的 AI 团队是怎么讨论的。
试试
npm install -g @touchskyer/opc
# 在 Claude Code 里：
/opc review零依赖，30 秒搞定。