1. 为什么要让两个 CLI 编码助手同时干活
1.1 单打独斗的编码助手到底卡在哪
用 Claude Code 或者 Codex CLI 写代码有一段时间的朋友，大概都经历过这样一个阶段：一开始觉得一个终端里跑一个 AI 助手已经很爽了，补全、重构、写测试、解释报错，基本能覆盖日常七八成的工作。但用得越深，越会发现单实例模式有几个绕不过去的坎。
第一个坎是上下文窗口的争夺。你让 Claude Code 帮你重构一个模块，它读了十几个文件，上下文塞得满满当当，这时候你突然想让它顺手把旁边那个测试文件也改了，它要么忘了前面的约定，要么开始胡编。第二个坎是任务串行。一个任务在跑，你就只能干等，想并行开另一个任务，得再开一个终端窗口，然后两个窗口之间复制粘贴上下文，来回切换，效率反而更低。第三个坎是模型偏好差异。有些重构任务 Claude 的代码风格更合你意，有些算法推导 Codex 给的思路更清晰，但你没法在一个对话流里同时调度两者。
我自己的实际感受是，当项目进入中后期，单实例助手带来的心智负担开始超过它节省的时间。你会花大量精力在“这个任务该给谁”“上下文怎么搬过去”“刚才那个结论在哪”这些元问题上，而不是写代码本身。
1.2 双 CLI 并行的核心价值在哪
让 Claude Code 和 Codex 一起用，本质上是把“一个助手干所有事”变成“两个助手分工协作，由一个统一入口调度”。这个思路的价值体现在三个层面。
分工层面，Claude Code 擅长长上下文理解、多文件重构、遵循复杂指令链；Codex 在算法推导、单文件精修、快速生成候选实现上响应更利落。让它们各干各擅长的，比逼着一个模型硬扛所有任务要靠谱得多。
并行层面，两个 CLI 进程可以同时跑，一个在后台跑耗时的全量重构，另一个在前台响应你的即时提问。你不需要等一个跑完再开另一个，时间利用率直接翻倍。
隔离层面，这是最容易被忽略但最关键的一点。两个助手如果同时改同一个工作目录，冲突几乎是必然的。所以必须引入工作区隔离机制，让每个助手在自己的沙箱里干活，最后由你来决定哪些改动合并回主干。git worktree在这里就是那个隔离层。
1.3 这套方案适合谁，不适合谁
先说适合的。如果你满足下面任意两条，这套方案值得花时间搭：日常在终端里写代码，对 CLI 工具不陌生；项目有一定规模，单文件几百行以上，多文件联动频繁；手头有需要并行推进的任务，比如一边重构一边写新功能；对两个模型的输出风格有明确偏好，想按任务类型分流。
不适合的情况也得说清楚。如果你只是偶尔写写脚本，单实例完全够用，搭这套纯属给自己找事。如果你对终端操作比较陌生，光是git worktree的概念就得消化一阵，建议先把单个 CLI 用熟再说。还有就是机器资源紧张的话，两个 CLI 进程加上各自的索引和上下文，内存占用不小，8G 内存的机器会比较吃力。
提示：这套方案的核心不是“装两个工具”，而是“设计一套调度和隔离机制”。工具安装只是第一步，真正花时间的是工作流的设计和踩坑后的调整。
2. 整体架构设计与关键选型考量
2.1 一个对话指挥两个助手的架构长什么样
整套架构可以拆成四层来理解。最上层是统一对话入口，也就是你实际敲命令、看输出的那个终端会话。中间层是调度层，负责解析你的意图，决定这个任务派给 Claude Code 还是 Codex，或者两个都派。再往下是执行层，两个 CLI 各自在自己的进程里跑，互不干扰。最底层是工作区隔离层，用git worktree给每个助手分配独立的工作目录。
这个分层的好处是职责清晰。调度层不关心具体怎么改代码，执行层不关心任务从哪来，隔离层不关心上面跑的是什么模型。任何一层出问题，排查范围都很明确。
实际落地时，调度层可以做得轻量一些。不一定非要写一个复杂的路由程序，很多时候一个 shell 函数加几个约定好的目录命名规则就够了。我见过有人上来就想搞个全自动路由，结果调试成本远超收益。先用半自动的方式跑通，再逐步加自动化，这个节奏更稳。
2.2 为什么选 git worktree 做隔离而不是复制目录
隔离方案有好几种，直接复制整个项目目录、用软链接、用容器，都能实现。但git worktree有几个别人替代不了的优势。
共享对象库。git worktree创建的新工作区跟主仓库共享同一个.git对象库，不会把整个历史复制一遍。一个几 G 的仓库，复制目录要等半天占双倍空间，worktree 几乎是秒建，只多出一个工作区目录的体积。
分支天然隔离。每个 worktree 绑定一个独立分支，两个助手各改各的分支，提交历史清清楚楚。合并的时候用标准的git merge或git rebase，冲突处理走你熟悉的流程，不需要学新东西。
清理干净。任务做完，git worktree remove一条命令就把工作区删了，分支该合并合并该删删，不留垃圾。复制目录的方案经常留下一堆忘记删的副本，时间长了磁盘就满了。
切换成本低。你可以在主工作区继续做自己的事，两个助手在各自的 worktree 里跑，互不打扰。想看看某个助手的进度，cd过去就行，不需要切换什么环境。
2.3 调度策略：什么任务给谁
这是整套方案里最需要经验的部分。我踩过的坑是，一开始想搞一套“智能路由”，根据任务描述自动判断给谁，结果准确率惨不忍睹。后来改成基于任务类型的固定规则，反而好用得多。
下面这张表是我自己总结的分流规则，你可以直接参考，也可以按自己的习惯调整。
| 任务类型 | 推荐助手 | 理由 |
|---|---|---|
| 多文件重构、跨模块改动 | Claude Code | 长上下文理解强，能记住多个文件的约定 |
| 单文件算法实现、候选方案生成 | Codex | 响应快，单点问题给得利落 |
| 写测试、补文档 | 两者皆可 | 看哪个当前空闲就派哪个 |
| 复杂指令链、多步骤任务 | Claude Code | 遵循多步指令的稳定性更好 |
| 快速验证想法、试错 | Codex | 迭代快，试错成本低 |
| 需要读大量上下文的任务 | Claude Code | 上下文窗口管理更成熟 |
这张表不是死的。用一段时间后你会形成自己的直觉，哪个任务给哪个助手更顺手，那时候就可以抛开表格了。
2.4 通信机制：两个助手怎么“知道”对方在干嘛
这是很多人忽略的一环。两个助手并行跑，如果完全不知道对方在做什么，很容易出现重复劳动或者互相覆盖。解决办法是引入一个轻量的共享状态文件。
我的做法是在项目根目录放一个.ai-workspace/status.md，每个助手在开始任务前先读这个文件，了解当前有哪些任务在进行、改了哪些文件、有什么约定。任务开始和结束时更新这个文件。这个文件不需要多复杂，几行 Markdown 就够。
# 当前任务状态 ## Claude Code - 分支: refactor/auth-module - 任务: 重构认证模块，拆分 token 校验逻辑 - 涉及文件: src/auth/*.ts - 状态: 进行中 ## Codex - 分支: feat/payment-api - 任务: 实现支付接口的签名校验 - 涉及文件: src/payment/sign.ts - 状态: 进行中 ## 约定 - 公共类型定义在 src/types/，改动前先在 status 里登记 - 不要直接改 main 分支这个文件的价值在于，它把隐式的协作变成了显式的约定。两个助手读同一个文件，就知道边界在哪，不会越界改对方的文件。
3. 环境准备与两个 CLI 的安装配置
3.1 安装前的环境检查清单
动手之前先把环境过一遍，能省掉后面一堆莫名其妙的报错。下面这几项是必须确认的。
- Node.js 版本：两个 CLI 都依赖 Node 运行时，建议 18 LTS 以上，20 更稳。用
node -v确认，版本太低先升级。 - git 版本：
git worktree需要 git 2.5 以上，实际建议 2.20 以上，老版本有些子命令行为不一致。git --version看一眼。 - 终端环境：macOS 用 iTerm2 或系统终端都行，Windows 建议用 Windows Terminal 配合 WSL，纯 PowerShell 下有些交互会有问题。
- 磁盘空间：worktree 虽然省空间，但两个 CLI 各自的缓存和索引还是要占地方，留出至少 5G 余量。
- 网络：两个 CLI 首次运行都要拉取一些资源，网络不通会卡在初始化。
注意：如果你在 Windows 上遇到
unable to locate the codex cli binary or required runtime components这类报错，八成是 PATH 没配好或者运行时组件缺失。先确认 Node 装好，再用npm root -g看看全局包目录在不在 PATH 里。
3.2 Claude Code 的安装与首次配置
Claude Code 的安装走 npm 全局包最省事。
npm install -g @anthropic-ai/claude-code装完用claude --version确认。首次运行claude会引导你完成认证配置，按提示走就行。认证信息会存在本地配置目录，后续不用重复登录。
配置上有几个点值得调。一是模型选择，默认模型够用，但如果你有特定偏好可以在配置里指定。二是工作目录，Claude Code 默认以当前目录为工作区，建议在项目根目录启动，让它能读到完整的项目结构。三是权限模式，首次用建议开确认模式，每个文件改动都让你过一眼，用熟了再考虑放宽。
如果你在 macOS 上想用第三方模型的 key，配置方式是在环境变量里指定对应的 endpoint 和 key，具体变量名看官方文档。这里不展开，因为不同版本配置项会变，以你装的那个版本的文档为准。
3.3 Codex CLI 的安装与登录
Codex CLI 同样走 npm。
npm install -g @openai/codex装完codex --version验证。首次运行codex会走登录流程，按提示完成认证。如果遇到codex auth token is unavailable这类提示，通常是登录态过期或者配置文件损坏，删掉本地配置目录重新登录一般能解决。
Codex 的配置里，模型选择和审批模式是两个关键项。审批模式建议先用默认的，让它每次改动前问你一下，避免它自作主张改一堆文件。等信任度上来了再调。
Windows 用户如果装完发现命令找不到，检查一下 npm 全局 bin 目录有没有加到 PATH。npm config get prefix能看到全局目录位置，把它下面的 bin 目录加进 PATH 就行。
3.4 验证两个 CLI 能独立跑通
装完之后别急着搞联动，先分别验证两个 CLI 能独立工作。这一步很重要，因为联动出问题时，你得先排除是单个 CLI 本身的问题。
验证方法很简单，建一个测试目录，分别用两个 CLI 做一个小任务，比如“创建一个 hello.txt 写入当前时间”。两个都能正常完成，说明基础环境没问题。如果某个 CLI 报错，先把它单独修好，别带着问题往下走。
我见过有人跳过这步，直接上联动，结果两个 CLI 都报错，排查了半天发现是 Node 版本问题，白白浪费时间。基础验证花不了五分钟，但能省掉后面几小时的困惑。
4. 用 git worktree 搭建隔离工作区
4.1 worktree 的基本操作与目录规划
git worktree的核心命令就几个，记住就够用。
# 创建一个新工作区，绑定新分支 git worktree add ../project-claude -b refactor/auth-module # 查看当前所有工作区 git worktree list # 删除一个工作区 git worktree remove ../project-claude目录规划上，我习惯把 worktree 建在主仓库的同级目录，用项目名加助手名做后缀。比如主仓库在~/code/myproject，两个工作区就是~/code/myproject-claude和~/code/myproject-codex。这样一眼就能看出哪个目录是给谁用的，cd的时候也好敲。
分支命名上，建议带上助手标识和任务类型，比如claude/refactor-auth、codex/feat-payment。这样git branch一看就知道每个分支是谁在改、改的是什么。
4.2 给每个助手分配独立工作区的实操
完整流程走一遍。假设主仓库在~/code/myproject，当前在 main 分支。
cd ~/code/myproject # 给 Claude Code 建工作区 git worktree add ../myproject-claude -b claude/refactor-auth # 给 Codex 建工作区 git worktree add ../myproject-codex -b codex/feat-payment # 确认 git worktree list输出应该能看到三个工作区：主仓库、claude 工作区、codex 工作区，各自绑定不同分支。
然后在各自的目录里启动对应的 CLI。Claude Code 在myproject-claude里跑，Codex 在myproject-codex里跑。两个进程互不干扰，各自改各自分支的文件。
这里有个细节要注意：依赖安装。如果项目有node_modules之类的依赖目录，新 worktree 里是没有的，需要各自装一遍。或者用软链接指向主仓库的依赖目录，省空间也省时间。软链接的做法是ln -s ~/code/myproject/node_modules ~/code/myproject-claude/node_modules，两个工作区都这么处理。
4.3 工作区之间的同步与合并策略
两个助手各改各的，最终要合并回主干。合并策略取决于任务之间的关系。
如果两个任务互不相关，比如一个改认证模块一个改支付模块，那各自合并到 main 就行，顺序无所谓。用git checkout main && git merge claude/refactor-auth依次合并。
如果两个任务有依赖，比如 Codex 的实现依赖 Claude 重构后的接口，那就得先合并 Claude 的，再让 Codex 基于新主干 rebase 一下，解决冲突后再合并。git rebase main在 codex 工作区里跑。
如果两个任务改了同一个文件，冲突不可避免。这时候别指望自动合并，老老实实手动解决。我的习惯是先把两个分支都合并到一个临时分支，在临时分支上解决冲突，验证通过后再合回 main。这样 main 始终保持干净。
提示：合并前先在各自工作区跑一遍测试，确保每个分支单独是能跑的。带着失败的测试去合并，冲突和 bug 混在一起，排查难度翻倍。
4.4 清理工作区的正确姿势
任务做完，工作区要清理干净，不然攒多了磁盘和分支列表都会乱。
# 先切回主仓库 cd ~/code/myproject # 删除工作区 git worktree remove ../myproject-claude # 删除已合并的分支 git branch -d claude/refactor-auth如果工作区里有未提交的改动，git worktree remove会拒绝执行，防止你误删。确认不要了可以加--force。但加 force 之前一定想清楚，删了就找不回来了。
分支删除用-d而不是-D，-d会检查分支是否已合并，没合并会拒绝，这是一道安全网。确实要强删再用-D。
5. 统一对话入口的实现
5.1 用 shell 函数做轻量调度
统一入口不一定要写复杂的程序，几个 shell 函数就能搞定。核心思路是：你敲一个命令，带上任务描述和目标助手，函数负责切到对应工作区、启动 CLI、把任务传进去。
# 加到 ~/.zshrc 或 ~/.bashrc cc_task() { local task="$1" cd ~/code/myproject-claude || return claude "$task" } codex_task() { local task="$1" cd ~/code/myproject-codex || return codex "$task" }用的时候就是cc_task "重构认证模块"或者codex_task "实现支付签名"。简单直接，不需要额外的调度程序。
想再进一步，可以加一个both_task函数，把同一个任务同时派给两个助手，让它们各自给一版实现，你再挑。这在需要对比方案的时候特别有用。
both_task() { local task="$1" (cd ~/code/myproject-claude && claude "$task") & (cd ~/code/myproject-codex && codex "$task") & wait }&让两个任务后台并行，wait等两个都结束。这样你敲一条命令，两个助手同时开工。
5.2 状态文件的读写约定
前面提到的.ai-workspace/status.md，需要约定好读写规则，不然两个助手各写各的会乱。
规则可以定得简单点：任务开始前读，任务结束后写。读是为了了解当前有哪些任务在进行，避免撞车。写是为了留下记录，让另一个助手和未来的你知道发生了什么。
具体到操作上，可以在 shell 函数里加一步，启动 CLI 前先把 status 文件内容打印出来，让你和助手都看到当前状态。任务结束后，手动或让助手更新 status 文件。
cc_task() { local task="$1" cd ~/code/myproject-claude || return echo "=== 当前工作区状态 ===" cat ~/code/myproject/.ai-workspace/status.md echo "======================" claude "$task" }这样每次启动任务前，你都会看到当前的整体状态，心里有数。
5.3 让两个助手互相“看见”对方的工作
光有状态文件还不够，有时候一个助手需要读另一个助手改过的代码。这时候 worktree 的隔离反而成了障碍，因为两个工作区的文件是分开的。
解决办法是按需同步。如果 Codex 需要看 Claude 改的接口，就在 Codex 工作区里git merge claude/refactor-auth或者git cherry-pick相关的提交。这样 Codex 就能看到 Claude 的改动，同时保持自己的分支独立。
另一种做法是共享只读目录。把公共的类型定义、接口约定放在主仓库的一个固定目录，两个工作区都软链接过去。这样任何一方改了公共部分，另一方立刻能看到。但要注意，公共部分改动要谨慎，最好先在 status 文件里登记，避免两边同时改。
5.4 一个对话里切换助手的实操演示
假设你在一个终端会话里，想先让 Claude 分析一下代码结构，再让 Codex 基于分析结果实现一个函数。流程大概是这样。
先派 Claude 做分析：
cc_task "分析 src/auth 目录的结构，列出主要模块和依赖关系，输出到 .ai-workspace/auth-analysis.md"等它跑完，你去看分析结果。然后派 Codex 基于分析实现：
codex_task "参考 .ai-workspace/auth-analysis.md，在 src/auth/token.ts 里实现 token 校验函数"注意这里 Codex 要能读到 Claude 写的分析文件。如果两个工作区是隔离的，这个文件得先同步过去。可以在 Codex 工作区里软链接.ai-workspace目录到主仓库的对应目录，这样两边共享同一份分析文件。
ln -s ~/code/myproject/.ai-workspace ~/code/myproject-codex/.ai-workspace这样 Claude 写的分析，Codex 立刻能读到，不需要手动复制。
6. 常见问题与排查技巧实录
6.1 两个 CLI 同时跑时的资源冲突
最常见的冲突是端口占用。有些 CLI 会在本地起一个服务端口用于通信，两个实例同时跑可能抢同一个端口。表现是第二个启动的 CLI 报端口被占用或者直接卡住。
解决办法是给每个实例指定不同的端口。具体怎么指定看 CLI 的配置项，一般在配置文件或环境变量里能设。如果 CLI 不支持自定义端口，那就错开启动时间，等一个完全起来再起另一个。
另一个冲突是文件锁。两个助手如果同时改同一个文件，git 层面会有锁冲突。这就是为什么前面强调工作区隔离，隔离做好了，这个冲突基本不会出现。
内存和 CPU 占用也值得关注。两个 CLI 同时跑大任务，机器会明显变卡。我的经验是，如果机器配置一般，别让两个都跑重任务，一个跑重的，另一个跑轻的，错开资源高峰。
6.2 认证失效与登录态问题
两个 CLI 各自有独立的认证体系，互不影响。但各自都可能遇到登录态过期的问题。
Claude Code 如果报认证相关错误，先检查本地配置目录里的凭证文件是否还在、是否过期。删掉重新登录通常能解决。Codex 遇到auth token is unavailable，同理，清掉本地配置重新走登录流程。
有个坑要注意：别把两个 CLI 的配置目录搞混。它们各自的配置存在不同目录，清理的时候看清楚是哪个的，别把好的那个也删了。清理前先备份一下配置目录，出问题能恢复。
6.3 worktree 相关的典型报错
git worktree add报fatal: '<branch>' is already checked out，说明这个分支已经在某个工作区里了。要么换个分支名，要么先把那个工作区删掉。
git worktree remove报contains modified or untracked files，说明工作区里有未提交的改动。确认不要了加--force，或者先把改动提交/暂存再删。
git worktree list显示的工作区路径不对，或者删了目录但 list 里还在，用git worktree prune清理一下失效的记录。这个命令会扫描并移除已经不存在的 worktree 记录。
6.4 助手改错文件或改乱代码怎么回滚
这是最让人头疼的情况。好在有 git，回滚不难，关键是及时。
如果改动还没提交，在工作区里git checkout -- <file>或者git restore <file>就能还原单个文件。全部还原用git restore .。
如果已经提交了，用git revert <commit>生成一个反向提交，或者git reset --hard <commit>回退到某个提交。注意reset --hard会丢弃之后的改动，用之前确认清楚。
我的习惯是，让助手干活前先确保当前分支是干净的，所有改动都提交了。这样出问题随时能回退到干净状态。助手每完成一个阶段性任务就提交一次，提交粒度小一点，回滚的时候损失也小。
6.5 常见问题速查表
| 现象 | 可能原因 | 处理方式 |
|---|---|---|
| 第二个 CLI 启动卡住 | 端口占用 | 指定不同端口或错开启动 |
| 认证报错 | 登录态过期 | 清理配置重新登录 |
| worktree add 失败 | 分支已存在 | 换分支名或删旧工作区 |
| worktree remove 失败 | 有未提交改动 | 提交或加 --force |
| 助手改乱代码 | 上下文理解偏差 | git restore 回滚，缩小任务粒度 |
| 两个助手改同一文件 | 隔离没做好 | 检查 worktree 是否独立 |
| 合并冲突频繁 | 任务边界不清 | 明确文件归属，更新 status 文件 |
| 机器变卡 | 资源占用高 | 错开重任务，或升级硬件 |
这张表建议存下来，遇到问题先查一遍，大部分常见情况都能覆盖。
7. 实操心得与效率提升技巧
7.1 任务粒度控制：别让助手一次干太多
这是我踩过最大的坑。一开始图省事，给助手一个大任务，比如“重构整个认证模块”，结果它改了一堆文件，改到一半上下文不够了，开始胡编，最后产出没法用，还得全部回滚。
后来我把任务粒度压小，一次只让助手干一件事，比如“把 token 校验逻辑从 auth.ts 抽到 token.ts”。任务小了，助手能完整理解，产出质量高，出问题也好回滚。多个小任务串起来，整体效率反而比一个大任务高。
判断粒度是否合适的标准：如果任务描述超过三句话，或者涉及超过五个文件，就该拆了。
7.2 上下文管理：怎么让助手记住关键约定
助手记不住约定是常态，别指望它自己记住。解决办法是把约定显式化，写进文件里，让助手每次都能读到。
我的做法是在项目根目录放一个CONVENTIONS.md，写清楚代码风格、命名规则、目录结构约定、禁止事项。每次启动助手任务前，让它先读这个文件。这样它干活的时候就有据可依，不会跑偏。
另一个技巧是在任务描述里带上关键上下文。比如“参考 src/auth/token.ts 里的 validateToken 函数风格，实现一个新的 refreshToken 函数”。把参考对象明确指出来，比让它自己找要靠谱得多。
7.3 什么时候该人工介入
助手不是万能的，有些情况必须人工介入，硬让助手干只会浪费时间。
涉及业务逻辑判断的，助手不知道你的业务规则，让它猜只会猜错。涉及外部系统交互的，比如调第三方 API，助手不知道对方的实际行为，容易写出想当然的代码。涉及安全敏感的，比如认证、加密、权限，这些地方出错代价大，人工把关更稳妥。
我的原则是，助手负责“怎么写”，我负责“写什么”和“对不对”。把机械性的编码工作交给助手，把判断和决策留给自己。
7.4 长期使用的配置沉淀
用久了会形成一套自己的配置和习惯，把这些沉淀下来，换项目或者换机器的时候能快速复用。
值得沉淀的东西包括：shell 调度函数、status 文件模板、CONVENTIONS 模板、常见问题的处理命令。这些可以放在一个 dotfiles 仓库里，新环境一键部署。
另外，两个 CLI 的配置文件也值得备份。认证信息虽然会过期，但模型选择、审批模式这些偏好设置是长期有效的，备份下来省得每次重配。
7.5 一个真实项目的完整流程复盘
拿我最近做的一个项目举例。项目是一个中等规模的 TypeScript 后端，需要重构认证模块同时新增支付功能。
第一步，建两个 worktree，分别给 Claude 和 Codex。Claude 负责认证重构，Codex 负责支付实现。两个任务文件重叠少，隔离效果好。
第二步，写 status 文件，登记两个任务的分支、涉及文件、约定。特别注明公共类型定义在src/types/，改动前先登记。
第三步，Claude 先开工，重构认证模块。它改了src/auth/下的几个文件，抽出了 token 校验逻辑。跑完测试通过，提交。
第四步，Codex 开工实现支付。它需要用到认证模块的 token 校验，但此时 Codex 工作区还是旧代码。于是把 Claude 的分支合并到 Codex 工作区，Codex 基于新代码实现支付签名。
第五步，两个任务都完成后，先合并 Claude 的分支到 main，再把 Codex 的分支 rebase 到 main 上，解决少量冲突，合并。
第六步，清理两个 worktree，删除已合并的分支。
整个流程走下来，两个任务并行推进，总耗时比串行少了将近一半。中间出过两次小问题，一次是 Codex 改了一个 Claude 也改过的类型定义文件，靠 status 文件的约定提前发现了；一次是合并时有个小冲突，手动解决花了十分钟。整体可控。
这套流程不是一次就顺的，前几次用的时候踩了不少坑，比如任务粒度太大、隔离没做好、合并策略不对。用了几次之后，流程就固化成上面这样了。你要是刚开始用，别指望一次就顺，多跑几次，把踩过的坑记下来，慢慢就形成自己的节奏了。
