Multi CLI --- 一种高效的CLI工作方法实践
本文研究多CLI（Claude，GEMINI，OpenCode, iFlow等）协作方法
为了提升工作效率，更好的执行和检查任务，并行运行多个CLI实例，是一个非常 Great 的事情
方案一：一个 Claude 写代码，另一个 iFlow或Claude 审查和测试
通过制订角色分工，类似多工程师协作，分开上下文有时更好：
- 用 Claude 写代码
- 用 /clear 或在另一个终端启动第二个 Claude
- 让第二个 Claude 审查第一个 Claude 的工作
- 再启动一个 Claude（或再次 /clear），读取代码和审查反馈
- 让这个 Claude 根据反馈修改代码
- 可以让 Claude 实例间通过草稿本交流，指定谁写谁读。
这种分工往往比单 Claude 处理所有任务效果更好。
方案二. 多仓库检出
许多 Anthropic 工程师会：
- 创建 3-4 个 git 检出，放在不同文件夹
- 分别在不同终端标签页打开每个文件夹
- 在每个文件夹启动 Claude，分配不同任务
- 轮流检查进度，批准/拒绝权限请求
点击查看具体方法
Anthropic 工程师在多任务并行开发场景下，结合 Git 版本控制、终端操作与 Claude（含 Claude Code 代码辅助功能）的实战工作流，并非 Claude Code 内置的自动执行功能，而是「人工主导 + 工具协同」的实操流程。以下是逐环节拆解的实际执行细节，兼顾可落地性：
一、 核心前提：明确工作流本质
这段操作的核心是通过「多 Git 本地检出（多克隆 / 多工作目录）」实现任务隔离，再配合多终端、多 Claude 实例并行处理不同开发任务，最终人工把控进度与风险。Claude Code 在此过程中承担「代码生成、调试、优化」的辅助角色，每个 Git 检出对应一个独立的任务上下文，避免任务之间的代码冲突与上下文混乱。
二、 逐环节实际执行步骤
步骤 1：创建 3-4 个 Git 检出（多本地文件夹隔离）
「Git 检出」在这里指将同一个远程 Git 仓库，克隆到本地不同的文件夹中（本质是多份本地仓库副本），目的是为不同任务提供完全隔离的开发环境，避免分支切换频繁、代码冲突等问题。
实际操作（终端命令示例）
假设远程仓库为 https://github.com/Anthropic/xxx-project.git，需要分配 4 个任务（接口开发、测试用例、代码重构、文档生成），则在本地执行多次 git clone，指定不同文件夹名称（命名对应任务，方便区分）：
bash
运行
# 检出 1：对应「接口开发」任务，文件夹命名 xxx-project-api
git clone https://github.com/Anthropic/xxx-project.git xxx-project-api
# 检出 2：对应「测试用例」任务，文件夹命名 xxx-project-test
git clone https://github.com/Anthropic/xxx-project.git xxx-project-test
# 检出 3：对应「代码重构」任务，文件夹命名 xxx-project-refactor
git clone https://github.com/Anthropic/xxx-project.git xxx-project-refactor
# 检出 4：对应「文档生成」任务，文件夹命名 xxx-project-docs
git clone https://github.com/Anthropic/xxx-project.git xxx-project-docs
关键细节：每个文件夹都是独立的 Git 仓库，拥有自己的工作区、暂存区、分支记录，修改其中一个文件夹的代码，完全不会影响其他文件夹，实现任务彻底隔离。
可选优化：若无需完整克隆历史，可使用 git clone --depth 1 进行浅克隆，提升速度（适合仅需最新代码的任务）。
步骤 2：在不同终端标签页打开每个文件夹
这一步是为了给每个独立的 Git 仓库分配专属终端环境，方便执行代码运行、Git 提交、依赖安装等命令，同时通过终端标签页快速切换任务。
实际操作（不同系统终端示例）
终端工具选择：
Mac/Linux：常用 iTerm2（支持标签页拆分、命名、颜色区分）；
Windows：常用 Windows Terminal（支持多标签页、自定义配置）。
具体操作：
打开终端，新建 4 个标签页（快捷键：Mac iTerm2 是 Cmd+T，Windows Terminal 是 Ctrl+Shift+T）；
对每个标签页，分别通过 cd 命令进入对应的 Git 检出文件夹（标签页可重命名，对应任务名称，方便识别）：
bash
运行
# 标签页 1（命名：API开发）
cd ~/workspace/xxx-project-api
# 标签页 2（命名：测试用例）
cd ~/workspace/xxx-project-test
# 标签页 3（命名：代码重构）
cd ~/workspace/xxx-project-refactor
# 标签页 4（命名：文档生成）
cd ~/workspace/xxx-project-docs
此时，每个终端标签页对应一个独立的任务文件夹，后续操作互不干扰。
步骤 3：在每个文件夹启动 Claude，分配不同任务
这里的「启动 Claude」并非指在终端中启动 Claude 本地程序（Claude 是云端服务），而是为每个任务环境（终端对应的 Git 文件夹），打开一个独立的 Claude 实例（网页版 / API 调用 / 集成工具），并向 Claude 明确任务范围，同时提供该文件夹的上下文信息，让 Claude Code 精准辅助开发。
实际操作（Claude + Claude Code 实操细节）
打开多 Claude 实例：
网页版：打开 4 个浏览器标签页，每个标签页登录 Claude（Anthropic 官网 / 工作台），对应终端的 4 个任务；
集成工具：若使用 VS Code 等编辑器，可通过 Claude 插件，在每个文件夹对应的编辑器窗口中，启动独立的 Claude Code 会话。
绑定任务上下文，分配专属任务：对每个 Claude 实例，先提供「当前任务文件夹的上下文」，再明确任务需求，让 Claude Code 生成贴合当前环境的代码。示例如下（以「接口开发」任务为例）：
上下文：我当前在 Git 文件夹 xxx-project-api 中，负责开发用户公告查询接口，项目使用 FastAPI 框架，数据来源是 announcement_service.py（文件内容如下：[粘贴该文件代码]），项目目录结构如下：[粘贴目录树]
任务（Claude Code 辅助）：
在 announcement_service.py 第 45 行补充查询逻辑，支持按用户 ID 过滤公告；
生成对应的接口路由（在 routes/announcement.py 中）；
验证代码语法正确性，提供测试命令。
其他 Claude 实例按同样方式，分配不同任务：
测试用例任务：要求 Claude Code 为 API 接口生成 pytest 测试脚本，放在 tests/backend/ 目录下；
代码重构任务：要求 Claude Code 优化 announcement_service.py 的冗余代码，提升执行效率；
文档生成任务：要求 Claude Code 根据接口代码，自动生成 OpenAPI 文档，更新到 docs/api/ 目录下。
Claude Code 的核心操作：每个 Claude 实例根据对应任务的上下文，通过 Claude Code 功能生成代码片段、调试建议、命令行操作等，工程师直接将代码复制到对应终端的 Git 文件夹中，或在编辑器中直接粘贴使用。
步骤 4：轮流检查进度，批准 / 拒绝权限请求
这一步是工程师作为主导者，周期性切换终端标签页和 Claude 实例，监控每个任务的推进情况，并对 Claude 提出的「权限相关请求」进行人工决策（避免 Claude 误操作影响项目安全或其他任务）。
实际操作细节
轮流检查任务进度：
切换终端标签页：依次查看每个 Git 文件夹的开发进度，通过 ls（查看文件是否新增 / 修改）、git status（查看未提交修改）、python xxx.py/pytest（运行代码验证效果）等命令，确认 Claude 生成的代码是否可用；
切换 Claude 实例：查看每个 Claude 实例的任务完成情况，是否有未解决的问题（如代码报错、依赖缺失），是否需要补充上下文信息。
批准 / 拒绝 Claude 的权限请求：
Claude 在辅助开发过程中，可能会提出涉及「权限 / 风险」的请求，工程师需要人工判断并决策：
常见权限请求场景：
文件操作权限：Claude 询问「是否允许删除 xxx-old.py 旧文件」「是否允许修改 config.yaml 配置文件」；
依赖安装权限：Claude 建议「需要安装 requests==2.31.0 依赖，是否执行 pip install 命令」；
Git 操作权限：Claude 询问「是否允许将当前修改 git add + git commit，提交备注为‘补充公告查询逻辑’」；
端口 / 网络权限：Claude 建议「需要启动 8000 端口调试 FastAPI 接口，是否允许占用该端口」；
决策与执行：
批准：工程师在终端中手动执行 Claude 建议的命令（如 pip install requests），或在编辑器中手动删除 / 修改文件（避免 Claude 直接操作本地文件，提升安全性）；
拒绝：向 Claude 反馈拒绝原因，并要求调整方案（如「不删除旧文件，将其重命名为 xxx-old.bak」「不安装该依赖，改用项目已有的 urllib 库」）；
关键细节：Anthropic 工程师不会让 Claude 拥有本地文件 / 系统的直接操作权限，所有高危操作均由人工批准后手动执行，避免误操作风险。
三、 该工作流的核心优势（为何 Anthropic 工程师采用）
任务隔离无冲突：每个 Git 检出对应一个任务，无需频繁切换分支，避免不同任务的代码相互覆盖、冲突；
并行开发提效：多 Claude 实例并行处理不同任务，工程师同步监控进度，相比串行开发大幅提升效率；
上下文精准聚焦：每个 Claude 实例仅对应一个任务的上下文，避免多任务信息混杂导致 Claude Code 生成无效代码；
风险可控：人工审批权限请求，把控核心操作，既利用 Claude Code 的高效辅助，又避免自动化工具的误操作风险。
四、 总结
这是「人工主导 + 多工具协同」的并行开发工作流，非 Claude Code 自动执行功能；
核心链路：多 Git 克隆（任务隔离）→ 多终端标签页（环境专属）→ 多 Claude 实例（任务并行）→ 人工监控 + 权限审批（风险把控）；
Claude Code 在其中承担「代码生成、调试、方案建议」的角色，所有本地操作（文件修改、命令执行）均由工程师手动完成，确保安全可控。
方案三：用 git worktree
适合多个独立任务，是多检出的轻量替代方案。git worktree 允许你将同一仓库的多个分支检出到不同目录。每个 worktree 有独立工作目录和文件，历史和 reflog 共享。
参考：https://wickd.ninja/blog/claude-code-tutorials/part-1-git-worktrees#running-claude-code-in-multiple-worktrees
用 git worktree 可让你同时在项目不同部分运行多个 Claude，每个专注于独立任务。例如，一个 Claude 重构认证系统，另一个构建数据可视化组件。任务互不干扰，各自高效推进，无需等待或处理冲突：
假设创建一个名为feature/new-branch的分支，我命名为：myupdate/new_webui
要先创建一个工作目录mystocks_tree，来放新的分支，它不能在当前的项目mystocks_spec下，只能在它平级：
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# cd ..
(stock) root@Desktop-CLF:/opt/claude# ls
AIstock ashare-mcp mystocks_backup mystocks_spec pybroker shared_workspace watcher
RD-Agent download mystocks_backup_20251020 mystocks_spec1 qlib token_law.md
(stock) root@Desktop-CLF:/opt/claude# mkdir mystocks_tree
# 然后回到主目录，创建并切换到新分支（基于远程main分支，可根据实际情况修改）
git checkout -b feature/new-branch origin/main
# 这里我用的是：
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git checkout -b myupdate/new_webui main
Updating files: 100% (319/319), done.
Switched to a new branch 'myupdate/new_webui'
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git worktree add ../mystocks_tree myupdate/new_webui
Preparing worktree (checking out 'myupdate/new_webui')
fatal: 'myupdate/new_webui' is already used by worktree at '/opt/claude/mystocks_spec'
由于有这个switch提示，我目前已经不在main上工作了，要切换回main，才能继续下一步：
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git checkout main
Switched to branch 'main'
Your branch is ahead of 'origin/main' by 42 commits.
(use "git push" to publish your local commits)
#此时 myupdate/new_webui 分支不再被主仓库占用，可正常关联到工作树
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git worktree add ../mystocks_tree myupdate/new_webui
Preparing worktree (checking out 'myupdate/new_webui')
Updating files: 100% (1188/1188), done.
HEAD is now at ac4c62d Fix DataManager initialization and data access layer API compatibility
#最后查看当前的Tree情况
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git worktree list
/opt/claude/mystocks_spec ac4c62d [main]
/opt/claude/mystocks_tree ac4c62d [myupdate/new_webui]
/root/.claude-squad/worktrees/hello_18733d451fdf5e69 fe81b45 [root/hello]
# 然后， 推送本地分支到远程程，并通过 -u 参数设置 upstream（上游）关联
(stock) root@Desktop-CLF:/opt/claude/mystocks_tree# git push -u origin myupdate/new_webui
Enumerating objects: 1381, done.
Counting objects: 100% (1381/1381), done.
Delta compression using up to 8 threads
Compressing objects: 100% (1305/1305), done.
Writing objects: 100% (1358/1358), 4.14 MiB | 1.87 MiB/s, done.
Total 1358 (delta 214), reused 0 (delta 0), pack-reused 0
remote: Resolving deltas: 100% (214/214), completed with 10 local objects.
remote:
remote: Create a pull request for 'myupdate/new_webui' on GitHub by visiting:
remote: https://github.com/yourname/mystocks/pull/new/myupdate/new_webui
remote:
To github.com:yourname/mystocks.git
* [new branch] myupdate/new_webui -> myupdate/new_webui
branch 'myupdate/new_webui' set up to track 'origin/myupdate/new_webui'.
#推送完毕，最后一句已经提示set up to track，查看一下分支情况：
(stock) root@Desktop-CLF:/opt/claude/mystocks_tree# git branch -vv
001-fix-5-critical f644523 Add temp_docs/ directory to .gitignore for better organization
001-readme-md-md f644523 Add temp_docs/ directory to .gitignore for better organization
002-arch-optimization b2180a8 Add US3 quick reference guide for developers
002-ta-lib-161 f644523 Add temp_docs/ directory to .gitignore for better organization
003-fix-all-broken bbba8f4 Complete Phase 4 - User Story 2: Fix 4 Broken Market Data Panels
003-inside-mystocks f644523 Add temp_docs/ directory to .gitignore for better organization
004-tdx-pytdx-mystocks f644523 Add temp_docs/ directory to .gitignore for better organization
004-ui-short-name 684e246 Complete UI/UX Improvements Feature - All 5 User Stories Implemented
005-tdx-web-tdx f644523 Add temp_docs/ directory to .gitignore for better organization
005-ui a58b635 docs: Add comprehensive login API fix documentation
006-0-md-1 f644523 Add temp_docs/ directory to .gitignore for better organization
006-web-90-1 560f92c note: update bug report log before i create tree
009-integrate-quantitative-trading f644523 Add temp_docs/ directory to .gitignore for better organization
010-integrate-quantitative-trading f644523 Add temp_docs/ directory to .gitignore for better organization
011-create-a-comprehensive f644523 Add temp_docs/ directory to .gitignore for better organization
feature/ml-integration f644523 Add temp_docs/ directory to .gitignore for better organization
+ main ac4c62d (/opt/claude/mystocks_spec) [origin/main: ahead 42] Fix DataManager initialization and data access layer API compatibility
* myupdate/new_webui ac4c62d [origin/myupdate/new_webui] Fix DataManager initialization and data access layer API compatibility
+ root/hello fe81b45 (/root/.claude-squad/worktrees/hello_18733d451fdf5e69) feat(data): Implement Shenwan industry fund flow data (Task 5/7)
root/mystocks_spec 5e74ea3 feat: 完成Web应用开发方法论改进 (006-web-90-1)
(stock) root@Desktop-CLF:/opt/claude/mystocks_tree#
#但是如果是在已经有GIT工作的目录中，需要先抹去原有GIT的痕迹
(stock) root@Desktop-CLF:/opt/claude/mystocks_ui/project-1# rm -rf .git
(stock) root@Desktop-CLF:/opt/claude/mystocks_ui/project-1# rm -f .gitignore .gitattributes
(stock) root@Desktop-CLF:/opt/claude/mystocks_ui/project-1# git status
fatal: not a git repository (or any of the parent directories): .git
(stock) root@Desktop-CLF:/opt/claude/mystocks_tree# git status
On branch myupdate/webui
Your branch is up to date with 'origin/main'.
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git worktree add ../mystocks_tree myupdate/webui
Preparing worktree (checking out 'myupdate/webui')
fatal: '../mystocks_tree' already exists
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# cd ..
(stock) root@Desktop-CLF:/opt/claude# rm -rf mystocks_tree
(stock) root@Desktop-CLF:/opt/claude# cd mystocks_spec
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git worktree add ../mystocks_tree myupdate/webui
Preparing worktree (checking out 'myupdate/webui')
fatal: '../mystocks_tree' is a missing but already registered worktree;
use 'add -f' to override, or 'prune' or 'remove' to clear
(stock) root@Desktop-CLF:/opt/claude/mystocks_spec# git worktree add ../mystocks_tree myupdate/webui -f
Preparing worktree (checking out 'myupdate/webui')
git worktree
自定义示例：使用共享组件进行协调特征开发
让我们探索一个更高级的现实场景：假设您正在开发一个大型应用程序，您需要开发两个相关功能，它们都将使用一些共享组件，但您希望并行开发它们。
方案描述
您正在构建一个电子商务平台，需要开发产品推荐系统和用户偏好设置页面。这两个功能将共享一些 UI 组件和实用程序功能，但您希望在组合它们之前独立开发和测试它们。
实施步骤
步骤 1：创建共享组件分支
首先，我们将为共享组件创建一个分支：
# Start from your main development branch
git checkout develop
# Create a branch for shared components
git checkout -b feature/shared-components
# Create a worktree for this branch
git worktree add ../ecommerce-shared feature/shared-components
步骤 2：创建特定于功能的分支和工作树
# Create recommendation feature branch from shared components
git checkout -b feature/product-recommendations feature/shared-components
# Create worktree for recommendations
git worktree add ../ecommerce-recommendations feature/product-recommendations
# Create preferences feature branch from shared components
git checkout -b feature/user-preferences feature/shared-components
# Create worktree for preferences
git worktree add ../ecommerce-preferences feature/user-preferences
第 3 步：使用 Claude Code 开发共享组件
导航到共享组件工作树，并使用 Claude Code 开发通用元素：
cd ../ecommerce-shared
claude
# In Claude Code session:
Human: I need to create reusable UI components for our e-commerce app.
Specifically, I need:
1. A PreferenceToggle component that can be used for user settings
2. A ProductCard component that can display product information
3. A shared utility function for formatting pricing information
Please help me implement these components in React with TypeScript.
第 4 步：开始对这两个功能进行并行开发
实现共享组件后，提交并推送您的更改：
# In the shared components directory
git add .
git commit -m "Add shared UI components and utilities"
git push -u origin feature/shared-components
现在使用共享组件更新两个功能分支：
# Update the recommendations worktree
cd ../ecommerce-recommendations
git pull origin feature/shared-components
# Update the preferences worktree
cd ../ecommerce-preferences
git pull origin feature/shared-components
第 5 步：使用 Claude Code 同时开发这两个功能
打开两个终端窗口，并在每个工作树中运行 Claude Code：
在第一个终端（建议）：
cd ../ecommerce-recommendations
claude
# In this Claude Code session:
Human: Using our shared components (ProductCard and pricing utils),
help me implement a product recommendation system that shows
personalized product suggestions based on browsing history.
在第二个终端（首选项）中：
cd ../ecommerce-preferences
claude
# In this Claude Code session:
Human: Using our shared PreferenceToggle component,
help me create a user preferences page that allows
users to set their notification settings, theme preferences, and privacy options.
步骤 6：定期更新共享组件
如果需要在开发过程中对共享组件进行更改：
# Make changes in the shared components worktree
cd ../ecommerce-shared
# Make changes with Claude's help
git commit -am "Update shared components with new features"
git push
# Update each feature branch
cd ../ecommerce-recommendations
git merge origin/feature/shared-components
cd ../ecommerce-preferences
git merge origin/feature/shared-components
结果和好处
此工作流程具有以下几个显著优势：
并行开发：您可以同时处理多个功能，而无需上下文切换
隔离环境：Claude Code 可以专注于特定任务，而不会被不相关的代码所迷惑
共享组件：您可以维护集中式组件，同时防止功能分支相互干扰
高效合并：功能准备就绪后，可以独立合并它们
协作潜力：不同的团队成员可以同时在不同的工作树中工作
为什么不复制文件夹？
- 复制存储库文件夹比创建 git-worktree “副本”占用更多空间。
- Git 使您的存储库副本保持同步。（例如，所有工作树上都发生了获取，git 可以防止你两次签出同一个分支）
实施建议
• 命名规范统一
• 每个 worktree 保持一个终端标签页
• Mac 用户用 iTerm2 设置 Claude 需要关注时的通知
• 不同 worktree 用不同 IDE 窗口
• 完成后清理：git worktree remove ../project-feature-a
用无头模式配合自定义脚本
claude -p（无头模式）可将 Claude Code 程序化集成到更大工作流，同时利用其内置工具和系统提示。主要有两种模式：
1，批量处理，适合大规模迁移或分析（如分析数百日志或数千 CSV）：
a. 让 Claude 写脚本生成任务列表。例如，生成 2000 个需从框架 A 迁移到 B 的文件列表。
b. 循环处理任务，程序化调用 Claude，传入任务和可用工具。例如：claude -p “migrate foo.py from React to Vue. When you are done, you MUST return the string OK if you succeeded, or FAIL if the task failed.” --allowedTools Edit Bash(git commit:*)
c. 多次运行脚本，迭代优化提示，直到满意。
2，流水线，将 Claude 集成到现有数据/处理流水线：
a. 调用 claude -p “<你的提示>” --json | your_command，your_command 是流水线下一步
b. 就这样！可选的 JSON 输出便于自动处理。
两种用法都建议用 --verbose 标志调试 Claude 调用。生产环境建议关闭 verbose，输出更简洁。
针对多 CLI（Claude、iFlow 等）协作方式的优化，可以从协作效率、任务协同、流程自动化、反馈闭环四个核心维度入手，结合工具特性和工程实践，提出以下改进意见：
一、角色分工与协作机制的精细化优化
-
明确 “角色契约”，减少上下文模糊性
问题：当前方案仅提到 “写代码 / 审查” 分工，但缺少明确的 “输出标准”，可能导致协作低效（如审查者需反复追问细节）。
优化：为每个 CLI 实例定义 “角色契约文档”（可存在项目根目录的cli_roles.md），包含：
输出格式（如代码需带注释比例、函数命名规范、测试用例模板）；
交互规则（如审查者必须标注 “阻塞性问题” 和 “建议性问题”，修改者需优先响应阻塞项）；
传递物标准（如草稿本交流时，用[发送方角色]::[内容类型]::[时间戳]格式，例：coder::auth_module_code::202510171530）。 -
引入 “元协调者” 角色，解决跨实例冲突
问题：多实例并行时可能出现 “意见分歧”（如两个审查者对同一代码块有不同修改建议），缺乏仲裁机制。
优化：新增一个 “元协调者 CLI 实例”（可专用一个终端），负责：
接收各实例的冲突反馈（如通过脚本监听草稿本中的[conflict]标签）；
基于项目目标（如性能优先 / 可读性优先）输出仲裁结果；
记录冲突类型及解决方案，形成团队协作知识库（如conflict_resolution_log.md）。
二、任务协同与环境隔离的增强方案
-
基于 “任务粒度” 动态分配资源，避免过度并行
问题：当前方案（多仓库检出、git worktree）侧重 “物理隔离”，但未考虑任务复杂度与资源匹配（如简单文档生成和复杂重构任务混在一起并行，可能浪费资源）。
优化：
按 “任务粒度” 分级（如 P0：核心功能开发，P1：文档生成，P2：格式优化）；
为高优先级任务（P0/P1）分配独立 CLI 实例 + 独立 worktree，低优先级任务（P2）可共享实例（通过/clear切换上下文）；
用脚本监控各实例资源占用（如 CPU / 内存），自动提醒 “过度并行导致卡顿”（例：当同时运行≥5 个 CLI 实例时触发警告）。 -
构建 “共享状态池”，替代低效的 “草稿本传递”
问题：依赖草稿本交流时，需手动复制粘贴，且难以追溯历史版本（如 “修改者” 看不到 “审查者” 的历史建议迭代）。
优化：
用轻量数据库（如 SQLite）或文件系统（结构化目录）构建 “共享状态池”：
plaintext
./shared_state/
├─ task_1/ # 任务ID
│ ├─ code/ # 代码生成结果（按版本号命名，如v1.py, v2.py）
│ ├─ review/ # 审查意见（带审查者角色和时间戳）
│ └─ status.json # 任务状态（待审查/修改中/已通过）
为每个 CLI 实例配置 “状态池访问脚本”，支持自动读取最新内容（如审查者实例运行load_latest_code task_1直接获取代码）和写入结果（如save_review task_1 "建议优化异常处理"）。
三、流程自动化与工具链集成的深化
- 基于 “事件触发” 的流水线协作，替代手动轮流操作
问题：当前方案依赖 “人工轮流检查进度”，步骤繁琐（如 “写代码→手动通知审查者→审查者手动读取→手动通知修改者”）。
优化：
用inotifywait（Linux）或fswatch（Mac）监听共享状态池的文件变化，触发自动化流程：
当 “代码生成目录” 新增文件时，自动通知审查者实例（如发送终端通知 + 调用load_code命令）；
当 “审查意见” 标记为 “已完成” 时，自动通知修改者实例，并附带上一版代码和审查要点；
示例脚本（伪代码）：
bash
# 监听代码生成事件，自动触发审查流程
fswatch -o ./shared_state/task_1/code | while read; do
notify-send "审查者：任务1有新代码待审查"
docker exec 审查者CLI实例 load_latest_code task_1
done
- 无头模式（claude -p）的进阶应用：动态任务分发与重试机制
问题：当前批量处理模式缺乏 “任务失败自动重试” 和 “负载均衡”，可能因单个任务阻塞整体流程。
优化：
构建 “任务队列管理器”（可用 Python 脚本实现），将批量任务（如 2000 个文件迁移）拆分为子任务，按 CLI 实例负载动态分配：
每个子任务包含唯一 ID、输入参数、预期输出（如migrate_foo.py::React→Vue::OK/FAIL）；
管理器实时监控各 CLI 实例的执行状态，若某实例返回FAIL，自动将任务分配给其他空闲实例重试；
输出 “任务执行报告”（含成功率、失败原因分类），便于针对性优化提示词（如某类文件迁移失败率高，需调整提示中的迁移规则）。
四、反馈闭环与协作体验的提升
-
建立 “双循环反馈” 机制：任务内反馈 + 协作流程反馈
问题：当前方案侧重 “任务执行”，但缺乏对 “协作方式本身” 的优化（如多次出现同一类沟通问题，却未改进流程）。
优化：
任务内反馈：每个任务结束后，各 CLI 实例输出 “协作自评”（如代码生成者：“本次因未明确输入格式导致 3 次修改，下次需在初始提示中注明”）；
流程反馈：定期（如每日 / 每项目）用一个专用 CLI 实例分析所有任务的协作日志，输出优化建议（如 “发现 70% 的冲突源于参数定义模糊，建议新增参数模板”）。 -
终端环境的可视化与区分化，减少操作失误
问题：多终端标签页运行时，易混淆不同 CLI 实例的角色（如误将 “审查者” 实例当作 “修改者” 使用）。
优化：
为不同角色的终端配置差异化视觉标识：
终端标题：[Coder] task_1_auth、[Reviewer] task_1_auth；
命令提示符（PS1）：用颜色区分（如代码生成者为绿色，审查者为蓝色）；
Mac 用户可在 iTerm2 中为不同角色实例配置 “触发式通知”（如审查者收到代码时，终端标题闪烁 + 系统提示音）；
用tmux或screen的会话命名功能，快速切换和管理实例（如tmux attach -t coder_task1）。
五、安全性与可追溯性强化
-
权限粒度控制：基于角色限制工具调用范围
问题：多实例并行时，若所有实例都开放Edit、Bash等工具权限，可能因误操作导致文件混乱（如两个实例同时修改同一文件）。
优化：
为不同角色分配最小权限：
代码生成者：仅允许Edit工具（且限定在当前 worktree 目录）；
审查者：仅允许Read工具（查看代码）和Bash的git diff（对比版本）；
元协调者：允许Bash的git merge（合并经批准的代码）；
在claude命令中通过--allowedTools严格限制（如claude --allowedTools Edit[../project-feature-a/*]）。 -
完整审计日志：记录所有交互与操作
问题：协作过程中若出现代码丢失、操作错误，难以追溯责任和原因。
优化：
为每个 CLI 实例配置日志输出（如--log-file ./logs/coder_task1.log），记录：
输入提示、输出结果、工具调用命令（如Edit: 修改了login.py第10行）；
时间戳、角色标识、关联任务 ID；
用logrotate定期归档日志，保留至少 30 天（便于问题追溯）。
总结：核心优化方向
从 “物理隔离” 到 “逻辑协同”：用共享状态池和事件触发替代手动传递，减少人为操作成本；
从 “固定分工” 到 “动态适配”：按任务粒度和资源负载分配实例，避免低效并行；
从 “执行导向” 到 “闭环优化”：通过反馈机制持续改进协作流程，同时强化安全性和可追溯性。
这些改进可根据团队规模逐步落地（如先实现 “角色契约” 和 “共享状态池”，再推进自动化流水线），最终目标是让多 CLI 协作从 “人工协调的并行” 升级为 “自组织的高效协同”。
一个外国人的方案 ：The Multi-Agent Revolution
In Parts 1 and 2, we explored Claude's capabilities and hook system. Now, let's tackle the ultimate productivity multiplier: running multiple Claude instances in parallel.
But first, a warning: This is where things get complex. Multiple agents mean:
Resource contention
File conflicts
Coordination challenges
Observability nightmares
Get it wrong, and you'll have chaos. Get it right, and you'll achieve superhuman productivity.
The Architecture That Makes It Possible
Here's the system architecture I use for multi-agent orchestration:
┌─────────────────────────────────────────────┐
│ Orchestrator (Meta-Agent) │
│ Decides what needs to be done │
└──────────────────┬──────────────────────────┘
│ Creates tasks
▼
┌─────────────────────────────────────────────┐
│ Task Queue (Redis) │
│ Stores and distributes work │
└─────┬───────┬───────┬───────┬──────────────┘
│ │ │ │
▼ ▼ ▼ ▼
┌─────────┐ ┌─────────┐ ┌─────────┐ ┌─────────┐
│ Agent 1 │ │ Agent 2 │ │ Agent 3 │ │ Agent N │
│Frontend │ │ Backend │ │ Tests │ │ Docs │
└─────────┘ └─────────┘ └─────────┘ └─────────┘
│ │ │ │
└───────┴───────┴───────┘
│
▼
┌──────────────────┐
│ Observability │
│ Dashboard │
└──────────────────┘
Step 1: The Meta-Agent Orchestrator
The meta-agent is Claude running in a special mode where it doesn't write code - it manages other agents:
# orchestrator.py
import json
import redis
import subprocess
from typing import List, Dict
class MetaAgent:
def __init__(self):
self.redis = redis.Redis(host='localhost', port=6379, db=0)
self.task_queue = 'claude_tasks'
def analyze_project(self, requirements: str) -> List[Dict]:
"""Use Claude to break down requirements into parallel tasks"""
prompt = f"""
Analyze these requirements and break them into independent tasks
that can be executed in parallel by specialized agents:
{requirements}
Return a JSON array of tasks with:
- id: unique identifier
- type: frontend|backend|testing|docs|refactor
- description: what needs to be done
- dependencies: array of task IDs that must complete first
- files: array of files this task will modify
"""
# Call Claude API
response = self.call_claude(prompt)
return json.loads(response)
def distribute_tasks(self, tasks: List[Dict]):
"""Queue tasks for worker agents"""
# Sort by dependencies
sorted_tasks = self.topological_sort(tasks)
for task in sorted_tasks:
# Check dependencies
if self.dependencies_complete(task):
self.redis.lpush(self.task_queue, json.dumps(task))
else:
# Queue for later
self.redis.lpush(f"{self.task_queue}:pending", json.dumps(task))
def spawn_worker_agents(self, count: int):
"""Launch Claude worker agents"""
for i in range(count):
subprocess.Popen([
'claude-code',
'--mode', 'worker',
'--id', f'agent-{i}',
'--config', 'worker-config.json'
])
Step 2: Specialized Worker Agents
Each worker agent has a specific role and configuration:
# worker_agent.py
import os
import json
import redis
import time
class WorkerAgent:
def __init__(self, agent_id: str, specialization: str):
self.id = agent_id
self.specialization = specialization
self.redis = redis.Redis(host='localhost', port=6379, db=0)
def run(self):
"""Main worker loop"""
while True:
# Get task from queue
task_data = self.redis.brpop('claude_tasks', timeout=5)
if task_data:
task = json.loads(task_data[1])
# Check if this agent can handle the task
if self.can_handle(task):
self.execute_task(task)
else:
# Put it back for another agent
self.redis.lpush('claude_tasks', task_data[1])
time.sleep(1)
def execute_task(self, task: Dict):
"""Execute a task with Claude"""
# Acquire file locks
locked_files = self.acquire_locks(task['files'])
try:
# Set up Claude context
prompt = self.build_prompt(task)
# Execute with Claude
os.environ['CLAUDE_SESSION_ID'] = f"{self.id}-{task['id']}"
result = self.run_claude(prompt)
# Report completion
self.redis.hset(f"task:{task['id']}", 'status', 'complete')
self.redis.hset(f"task:{task['id']}", 'result', result)
# Trigger dependent tasks
self.trigger_dependencies(task['id'])
finally:
# Release locks
self.release_locks(locked_files)
def acquire_locks(self, files: List[str]) -> List[str]:
"""Acquire exclusive locks on files"""
locked = []
for file_path in files:
lock_key = f"lock:{file_path}"
# Try to acquire lock with timeout
if self.redis.set(lock_key, self.id, nx=True, ex=300):
locked.append(file_path)
else:
# Couldn't get lock, release all and retry
self.release_locks(locked)
time.sleep(2)
return self.acquire_locks(files)
return locked
Step 3: Real-Time Observability
With multiple agents running, observability becomes critical. Here's my monitoring dashboard:
<!DOCTYPE html>
<html>
<head>
<title>Claude Multi-Agent Command Center</title>
<script src="https://cdn.jsdelivr.net/npm/vue@3"></script>
<style>
.agent-grid {
display: grid;
grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
gap: 20px;
padding: 20px;
}
.agent-card {
border: 2px solid #3498db;
border-radius: 8px;
padding: 15px;
position: relative;
}
.agent-card.active {
border-color: #2ecc71;
box-shadow: 0 0 10px rgba(46, 204, 113, 0.3);
}
.agent-status {
position: absolute;
top: 10px;
right: 10px;
width: 12px;
height: 12px;
border-radius: 50%;
background: #95a5a6;
}
.agent-status.active { background: #2ecc71; }
.agent-status.busy { background: #f39c12; }
.agent-status.error { background: #e74c3c; }
.task-progress {
margin-top: 10px;
height: 20px;
background: #ecf0f1;
border-radius: 10px;
overflow: hidden;
}
.task-progress-bar {
height: 100%;
background: linear-gradient(90deg, #3498db, #2ecc71);
transition: width 0.3s;
}
.conflict-alert {
background: #e74c3c;
color: white;
padding: 10px;
border-radius: 5px;
margin: 10px;
}
</style>
</head>
<body>
<div id="app">
<h1>Claude Multi-Agent Command Center</h1>
<!-- Overall Stats -->
<div class="stats">
<h2>Mission Status</h2>
<p>Active Agents: {{ activeAgents.length }}</p>
<p>Tasks Completed: {{ completedTasks }} / {{ totalTasks }}</p>
<p>Files Modified: {{ modifiedFiles.size }}</p>
<p>Conflicts Detected: {{ conflicts.length }}</p>
</div>
<!-- Conflict Alerts -->
<div v-if="conflicts.length > 0" class="conflict-alert">
⚠️ File Conflicts Detected:
<ul>
<li v-for="conflict in conflicts" :key="conflict.file">
{{ conflict.file }} - {{ conflict.agents.join(' vs ') }}
</li>
</ul>
</div>
<!-- Agent Grid -->
<div class="agent-grid">
<div v-for="agent in agents"
:key="agent.id"
:class="['agent-card', { active: agent.status === 'active' }]">
<div :class="['agent-status', agent.status]"></div>
<h3>{{ agent.id }}</h3>
<p>Type: {{ agent.specialization }}</p>
<p>Current Task: {{ agent.currentTask || 'Idle' }}</p>
<div v-if="agent.currentTask" class="task-progress">
<div class="task-progress-bar"
:style="{ width: agent.progress + '%' }"></div>
</div>
<p>Files: {{ agent.workingFiles.join(', ') || 'None' }}</p>
<p>Tasks Completed: {{ agent.completedCount }}</p>
</div>
</div>
<!-- Activity Stream -->
<div class="activity-stream">
<h2>Live Activity</h2>
<div v-for="event in recentEvents" :key="event.id" class="event">
<span class="timestamp">{{ formatTime(event.timestamp) }}</span>
<span class="agent">{{ event.agentId }}:</span>
<span class="action">{{ event.action }}</span>
</div>
</div>
</div>
<script>
const { createApp } = Vue;
createApp({
data() {
return {
agents: [],
conflicts: [],
recentEvents: [],
totalTasks: 0,
completedTasks: 0,
modifiedFiles: new Set(),
ws: null
};
},
computed: {
activeAgents() {
return this.agents.filter(a => a.status === 'active');
}
},
methods: {
connect() {
this.ws = new WebSocket('ws://localhost:3001/agents');
this.ws.onmessage = (event) => {
const data = JSON.parse(event.data);
switch(data.type) {
case 'agent_update':
this.updateAgent(data.agent);
break;
case 'conflict':
this.conflicts.push(data.conflict);
break;
case 'task_complete':
this.completedTasks++;
break;
case 'event':
this.recentEvents.unshift(data.event);
this.recentEvents = this.recentEvents.slice(0, 50);
break;
}
};
},
updateAgent(agentData) {
const index = this.agents.findIndex(a => a.id === agentData.id);
if (index >= 0) {
this.agents[index] = agentData;
} else {
this.agents.push(agentData);
}
// Track modified files
if (agentData.workingFiles) {
agentData.workingFiles.forEach(f => this.modifiedFiles.add(f));
}
},
formatTime(timestamp) {
return new Date(timestamp).toLocaleTimeString();
}
},
mounted() {
this.connect();
}
}).mount('#app');
</script>
</body>
</html>
Real-World Example: The Frontend Refactor
Last week, I needed to refactor my entire component library from class components to functional components with hooks. Here's how multi-agent orchestration handled it:
The Meta-Agent's Plan:
[
{
"id": "analyze-1",
"type": "analysis",
"description": "Scan all components and create refactoring plan",
"dependencies": [],
"files": []
},
{
"id": "refactor-buttons",
"type": "frontend",
"description": "Convert all Button components to functional",
"dependencies": ["analyze-1"],
"files": ["components/Button/*.tsx"]
},
{
"id": "refactor-forms",
"type": "frontend",
"description": "Convert all Form components to functional",
"dependencies": ["analyze-1"],
"files": ["components/Form/*.tsx"]
},
{
"id": "update-tests-buttons",
"type": "testing",
"description": "Update Button component tests",
"dependencies": ["refactor-buttons"],
"files": ["__tests__/Button/*.test.tsx"]
},
{
"id": "update-tests-forms",
"type": "testing",
"description": "Update Form component tests",
"dependencies": ["refactor-forms"],
"files": ["__tests__/Form/*.test.tsx"]
},
{
"id": "update-docs",
"type": "docs",
"description": "Update component documentation",
"dependencies": ["refactor-buttons", "refactor-forms"],
"files": ["docs/components/*.md"]
}
]
The Execution:
Agent-1 and Agent-2 worked on different component folders in parallel
Agent-3 and Agent-4 updated tests as components were completed
Agent-5 regenerated documentation after all refactoring was done
Agent-6 ran performance benchmarks on the new components
Total time: 2 hours (vs estimated 2 days manual work)
Lines changed: 12,000+
Tests passing: 100%
Conflicts: 0
Handling the Complexity
Challenge 1: Resource Management
Running 10+ Claude instances will max out your system. Here's my resource manager:
# resource_manager.py
import psutil
import docker
class ResourceManager:
def __init__(self, max_agents=10):
self.max_agents = max_agents
self.docker = docker.from_env()
def can_spawn_agent(self) -> bool:
# Check CPU usage
if psutil.cpu_percent(interval=1) > 80:
return False
# Check memory
if psutil.virtual_memory().percent > 85:
return False
# Check active containers
active = len([c for c in self.docker.containers.list()
if 'claude-agent' in c.name])
return active < self.max_agents
def spawn_agent_container(self, agent_config):
"""Spawn agent in Docker container for isolation"""
container = self.docker.containers.run(
'claude-agent:latest',
environment=agent_config,
detach=True,
name=f"claude-agent-{agent_config['id']}",
volumes={
'/project': {'bind': '/workspace', 'mode': 'rw'}
},
cpu_quota=50000, # Limit CPU usage
mem_limit='2g' # Limit memory
)
return container
Challenge 2: Coordination Without Conflicts
The key is smart task distribution and file locking:
# conflict_prevention.py
class ConflictPrevention:
def __init__(self):
self.file_graph = self.build_dependency_graph()
def build_dependency_graph(self):
"""Map file dependencies to prevent conflicts"""
# Analyze imports and exports
graph = {}
for file in glob.glob('**/*.ts', recursive=True):
imports = self.extract_imports(file)
graph[file] = imports
return graph
def can_modify_simultaneously(self, file1: str, file2: str) -> bool:
"""Check if two files can be modified in parallel"""
# Check if files import each other
if file2 in self.file_graph.get(file1, []):
return False
if file1 in self.file_graph.get(file2, []):
return False
# Check if they share common dependencies
deps1 = set(self.file_graph.get(file1, []))
deps2 = set(self.file_graph.get(file2, []))
shared = deps1.intersection(deps2)
# Allow if no shared critical dependencies
return len(shared) == 0 or all(
not self.is_critical(dep) for dep in shared
)
Challenge 3: Quality Control
With multiple agents, quality control becomes critical:
# quality_gate.py
class QualityGate:
def __init__(self):
self.checks = [
self.check_tests_pass,
self.check_type_safety,
self.check_no_conflicts,
self.check_performance,
self.check_security
]
def validate_agent_work(self, agent_id: str, changes: Dict):
"""Validate agent's changes before merging"""
results = []
for check in self.checks:
result = check(changes)
results.append(result)
if not result['passed']:
# Revert changes and reassign task
self.revert_changes(changes)
self.reassign_task(agent_id, result['reason'])
return False
return True
def check_tests_pass(self, changes):
"""Run tests on changed files"""
affected_tests = self.find_affected_tests(changes['files'])
result = subprocess.run(
['npm', 'test'] + affected_tests,
capture_output=True
)
return {
'passed': result.returncode == 0,
'reason': result.stderr.decode() if result.returncode != 0 else None
}
The Economics of Multi-Agent Development
Let's talk ROI. Running 10 Claude agents costs approximately:
API costs: ~$50/day at heavy usage
Infrastructure: ~$20/day for cloud resources
But the productivity gains:
10x faster development on parallelizable tasks
24/7 operation (agents don't sleep)
Consistent quality (no fatigue)
Comprehensive testing (every change, every time)
For a team of 5 developers, this replaces roughly $50,000/month in engineering time for $2,000/month in compute costs.
Getting Started with Multi-Agent
Start small:
Two agents: One for code, one for tests
Add observability: You need to see what's happening
Implement safety: File locks and conflict detection
Scale gradually: Add agents as you understand the patterns
The Future is Distributed
We're entering an era where a single developer can orchestrate an entire team of AI agents. The bottleneck isn't coding speed anymore - it's our ability to coordinate and direct these agents effectively.
Next week, I'm experimenting with 50+ agents working on a complete application rewrite. The meta-agent will manage sub-orchestrators, each controlling their own team of specialized agents.
It's turtles all the way down, and it's beautiful.
我的多CLI实战worktree方式
(官方）什么是worktree: https://git-scm.com/docs/git-worktree
以下是本人使用多CLI总结的宝贵经验，这大概是这篇文章最有价值的Prompt了：
给多CLI协作的开发者（主CLI）的建议：
- 初始化阶段（T+0h）：
- ✅ 创建清晰的worktree命名规范
- ✅ 为每个CLI编写详细的README任务文档
- ✅ 建立自动化监控脚本
- ✅ 设置明确的里程碑时间点 - 执行阶段（T+0h → T+9h）：
- ✅ 每小时检查进度，不干预工作
- ✅ 每2小时生成结构化报告
- ✅ 遇到阻塞问题提供解决方案文档，不直接修改代码
- ✅ 动态调整优先级，消除瓶颈 - 集成阶段（T+9h → T+10h）：
- ✅ 验证所有交付物完整性
- ✅ 按依赖顺序合并分支
- ✅ 运行E2E测试验证
- ✅ 生成最终完成报告 - 清理阶段（T+10h）：
- ✅ 推送main分支到远程
- ✅ 清理所有worktree
- ✅ 删除本地和远程分支
- ✅ 归档项目文档
避免的反模式：
- ❌ 过度干预：主动修改Worker CLI的代码
- ❌ 忽略阻塞：Worker CLI报告问题但不响应
- ❌ 技术强加：指定具体的技术实现方案
- ❌ 缺乏监控：不检查进度，直到最后才发现问题
具体过程
让主CLI创建worktree，分配任务（生成README文档），然后用户打开CLI，进入worktree分支，让AI按README文档执行任务
CLI-1
CLI-2
CLI-3 'phase6-monitoring-verification' 完成
最终提交完成
CLI-4 GIT 提交完成
删除本地Phase 6分支
我更新todo并删除远程分支
● 我已经完成了心得总结和指南更新。让我向您汇报：
📝 完成的工作
- 创建了详细的经验总结文档
文档路径: /opt/claude/mystocks_spec/docs/guides/MULTI_CLI_MAIN_CLI_LESSONS_LEARNED.md
内容包括:
- ✅ 5大核心感悟（"指导但不代替"、Git Worktree价值、进度监控、质量保证、优先级优化）
- ✅ 5个关键成功因素（Manager-Worker模式、优先级优化、完整指导、质量保证、Git最佳实践）
- ✅ 给未来主CLI的详细建议（初始化、执行、集成、清理4个阶段）
- ✅ 需要避免的3个反模式（过度干预、忽略阻塞、技术强加）
- ✅ 完整的量化成果（效率指标、质量指标、CLI效率对比、Git成就）
- 更新了Git Worktree指南文档
更新路径: /opt/claude/mystocks_spec/docs/guides/GIT_WORKTREE_MAIN_CLI_MANUAL.md
新增内容: ⭐ Phase 6实践经验 - 关键成功因素
包含5个关键经验：
🎯 成功经验1: 进度监控的最佳实践
- 发现问题: CLI-2阻塞3小时未被发现
- 解决方案: 自动化监控脚本（每小时检查）
- 监控内容: 最新提交、未提交修改、分支状态、新增提交数量、阻塞问题检测
🎯 成功经验2: 优先级动态调整策略
- 发现问题: CLI-2初始优先级不合理
- 解决方案: 优先级评估模型（Python函数）
- 优化结果: 节省63分钟，杠杆率206.7%
🎯 成功经验3: Git提交的标准化
- 发现问题: 提交信息格式不统一
- 解决方案: HEREDOC格式化模板
- 提交规范: type(scope): description格式
🎯 成功经验4: 合并冲突的预防
- 发现问题: 7个文件冲突
- 解决方案: 文件所有权规则
- 冲突解决: 文档→CLI-4，监控→CLI-1，测试→CLI-2
🎯 成功经验5: 问题响应的SLA标准
- 发现问题: CLI-2阻塞3小时响应太慢
- 解决方案: 3级问题响应机制（🟢信息级、🟡警告级、🔴阻塞级）
- 响应时间: 4h、1h、15min
🎭 我的核心心得（总结）
作为主CLI主持Phase 6多CLI协作，我最深刻的感悟是：
1️⃣ "指导但不代替"的力量
好的管理者不是做所有事情，而是让每个人都能独立做好自己的事情。我提供3次迭代指导文档帮助CLI-2解决13个语法错误，但从未直接修改它的代码。结果CLI-2提前3.1小时完成，效率提升57.4%，还学会了独立解决问题。
2️⃣ Git Worktree是并行开发的完美基础设施
4个CLI同时在不同领域工作（监控、测试、缓存、文档），没有任何Git冲突或文件覆盖问题。这就是worktree的价值——真正的并行开发，而非通过频繁切换分支的伪并行。
3️⃣ 进度监控 = 项目成功
定期监控（每小时检查、每2小时报告）的价值远超预期。没有监控，CLI-2的阻塞问题就不会被发现，项目效率会大幅下降。有监控，我们节省了65.5%的时间（19小时）。
4️⃣ 质量和速度可以兼得
虽然追求速度（并行开发），但质量没有打折。E2E测试100%通过（18/18），Pylint评级9.32/10，TODO清理87.2%。通过并行开发和自动化质量保证，我们同时实现了"更快"和"更好"。
5️⃣ 优先级优化是杠杆
一个简单的优先级调整（4→5→3）节省63分钟，杠杆率206.7%。主CLI的价值在于识别和消除瓶颈，而不是做所有工作。用最小投入获得最大产出，这才是管理智慧。
📊 Phase 6最终成果
- ✅ 4个Worker CLIs 100%独立完成任务
- ✅ 时间节省65.5%（19小时）
- ✅ 质量提升（Pylint 9.32/10，E2E 100%通过）
- ✅ Git历史完整保留（11次提交，4个合并）
核心价值: 多CLI协作不是简单的并行工作，而是通过Manager-Worker模式、Git Worktree隔离、定期监控和优先级优化，实现"1+1>2"的协同效应。
所有经验已经记录在案，希望这些心得和更新后的指南能够帮助未来的开发者更好地使用多CLI进行worktree并行开发！🎉
常见问题
分支未推送到远程
注意: phase6-cache-optimization 分支未推送到远程（在完成报告中已记录），因此只删除了本地分支。
关于"未推送到远程"的完整含义：
- 代码位置：
- ✅ 本地 main 分支 - 所有Phase 6代码都在这里，安全无虞
- ❌ 远程 GitHub 仓库 - 还没有Phase 6的代码（只有Phase 5） - 关于 phase6-cache-optimization 分支：
- 该分支本身从未推送到GitHub（作为一个独立分支）
- 但其代码已合并到本地main（通过提交 0fcf58f）
- 本地main有完整代码 - 我刚才验证了文件都存在 - 为什么没推送？
- 可能是网络问题导致推送中断
- 或者合并后忘记推送main分支
🎯 结论
代码安全性：
- ✅ 本地完全安全 - 所有4个Phase 6分支的代码都在本地main分支中
- ✅ Git历史完整 - 通过4个合并提交完整保留
- ⏳ 远程需要同步 - GitHub仓库还停留在Phase 5
💡 建议操作：推送本地main分支到远程GitHub
这样可以将所有Phase 6的工作（包括缓存优化、文档、E2E测试、监控验证）同步到GitHub，确保：
- 远程仓库有完整备份
- 其他协作者可以获取Phase 6代码
- 建立远程备份
Claude Code 34条使用技巧
From: https://ctok.ai/claude-code-34-tips
一、命令行 (CLI) 技巧 (共7条)
将视为CLI: 从根本上理解 Claude Code 是一个命令行工具，具备其所有基本特性。
传递命令参数: 使用 -P 参数在命令行模式下运行。
使用无模式: 使用 -P 参数在界面前端的模式下运行。
与其他工具联接: 可以将其他命令行工具（bash/CLI工具）连接工作流。
使用管道输入: 通过管道（|）将数据输入到 Claude Code 中。
运行多实例: 可以同时运行多个 Claude Code 实例。
让它启动自己: 可以指令 Claude Code 启动一个新的实例来处理任务的原理。
二、图像处理技巧 (共6条)
拖拽粘贴: 将图像文件直接拖入终端使用。
macOS 截图粘贴: 使用快捷键 Shift+Command+Control+4 将截图复制到剪贴板。
使用 Control+V 粘贴: 用 Control+V（而不是 Command+V）将图片粘贴到终端。
从设计稿生成代码: 粘贴从设计稿图，let Claude Code 构建界面。
建立视觉反馈循环: 截取应用的当前状态，将其反馈给 Claude Code 进行迭代修改。
自动化生成: 使用 Puppeteer MCP 服务自动化生成应用的截图流程。
三、集成与外部数据技巧 (共5条)
充当 MCP 服务器/客户端: Claude Code 本身既可以作为 MCP 服务器，也可以作为客户端连接其他服务。
连接数据库: 使用 Postgres MCP 服务器连接 Claude Code 到你的数据库。
获取最新API文档: 利用 Cloudflare 等公司提供的 MCP 服务器，获取实时更新的文档。
抓取链接内容: 直接粘贴一个 URL，Claude Code 会抓取该网页的内容为上下文。
获取外部知识: 使用 URL 抓取功能获取外部世界的知识（如游戏规则）并应用到代码中。
四、claude.md 配置文件技巧 (共7条)
理解其核心作用: claude.md 是一个在每次请求时都会加载的系统提示文件。
使用 /init 自动生成: 在项目目录中运行 /init 命令，自动生成一份基于项目结构的 claude.md。
用 # 动态更新: 在对话中，使用 # 符号可以将指令直接添加到 claude.md。
设置全局配置: 在用户主目录 ~/.claude/ 中创建 claude.md 以应用于所有项目。
使用子目录配置: 在子目录中添加 claude.md 应用于特定模块。
定期重载: 经常性地优化和精炼你的 claude.md 文件，保持其具体性和高效性。
使用提示优化工具: 可以借助 Anthropic 的提示优化工具来改进 claude.md 的内容。
五、定义斜杠命令技巧 (共6条)
在指定文件夹中定义: 在 .claude/slash_commands 文件夹中创建文件来自定义自己的斜杠命令。
为解决 GitHub 问题创建命令: 创建一个 /solve_github_issue 类似的命令。
为重构创建命令: 创建一个 /refactor 命令。
为代码检查创建命令: 创建一个 /lint 命令。
为 PR 审查创建命令: 创建一个 /review_pr 命令。
向命令传递参数: 你的自定义斜杠命令是提示模板，可以接收命令行参数。
六、UI与工作流技巧 (共3条)
使用 Tab 补全: 用 Tab 键自动补全文件和目录名，以提供更精准的上下文。
果断按 Esc 中断: 当你看到 Claude Code 的输出偏离预期时，立即按 Esc 键打断它。
使用 undo 撤销: 打断后，可以要求它 undo（撤销）上一步的操作。
学习资料
https://dev.to/bredmond1019/series/32756
Claude Code 多层智能代理协调系统 (Claude-Code-Multi-Agent)
https://github.com/Prorise-cool/Claude-Code-Multi-Agent
https://mp.weixin.qq.com/s/Cgy3fgDrVhbQ6AQa_apghg
https://mp.weixin.qq.com/s/bdfZk_E2UtCcy4zbA65uWw
AI中转平台 -- 强烈推荐Claude Code (官方安装 + 中转API + 本地使用无飞机)
首选方法（最快最具性价比，还可以免费试用）：claude-code club
注册和试用网址： https://academy.claude-code.club/ ）
国内：智谱 GLM Coding
🚀 速来拼好模，智谱 GLM Coding 超值订阅，邀你一起薅羊毛！Claude Code、Cline 等 10+ 大编程工具无缝支持，“码力”全开，越拼越爽！立即开拼，享限时惊喜价！
链接：https://www.bigmodel.cn/
国内：MinMax2.1
🎁 MiniMax 跨年福利来袭！邀好友享 Coding Plan 双重好礼，助力开发体验！
好友立享 9折 专属优惠 + Builder 权益，你赢返利 + 社区特权！
👉 立即参与：https://www.minimaxi.com/
浙公网安备 33010602011771号