写在前面

之前写过两篇工具指南：Claude Code 使用指南讲 CC 的命令、权限与配置，Codex 使用指南讲 Codex 的沙箱、审批与迁移差异。它们回答的是"这个工具怎么用"；这篇文章回答另一个问题——工具会用之后，工作该怎么组织。

这段时间我把 AI 编程从"对话式补全"用到"带着多个 agent 做跨周的大任务"，被迫沉淀了一套工作流。越用越清楚一件事：AI 的能力上限很高，但可靠性不会随能力免费到来，它需要一套工程化的兜底体系——就像你不会因为某个人很聪明，就把生产库密码交给他。

这套工作流的主线可以概括成三句话：

• 让事实可查：AI 的每个关键论断，都能被一条命令或一份文档核实；
• 让边界成文：做什么、不做什么，写在文档里而不是靠默契；
• 让验证可复现：成功与否由命令输出和测试判定，不由 AI 的自述判定。

全文围绕这三句话展开：先认清失败模式（一），再搭工作台（二），然后把大任务拆成文档工程（三），建立审查与验证的闭环（四），进而做多 agent 分工（五），把经验沉淀为 skill 和自动化约束（六），最后以一点反思收尾（七）。

适用读者：已经在日常使用 Claude Code、Codex 等 agent 工具，想从"小修小补"进阶到"把大任务托付出去"的开发者。文中以 Claude Code 为主线、Codex 为辅（主要作为交叉审查的另一方出场），概念可以迁移到其他 agent 工具。

一、认清失败模式：幻觉、越界修改与假验证

大多数 AI 编程的挫折，不是因为 AI 笨，而是因为它以三种可预测的方式出错。先认清失败模式，后面的技巧才有落点——所有防线都是修在这三个地方。

1.1 幻觉：一本正经地编造

表现：引用不存在的 API、配置项、参数或文件路径，给出看似合理实则拼凑的用法。幻觉不是偶发 bug，而是语言模型的固有属性——它在"预测合理的文本"，不在"陈述事实"。

检测信号：

• 引用了仓库里不存在的文件或符号（rg 一下就知道）；
• API 签名与官方文档对不上；
• 语气笃定但给不出出处，或用"应该是支持的"这类含糊措辞。

处置：要求 AI 给出论断的出处——文件路径加行号，或官方文档链接；用发现命令当场核实。预防：改动前先做代码走读（见 3.2），让 AI 的论断锚定在真实代码上，而不是想象上。

1.2 越界修改：顺手多做了一点

表现：任务只要改一个函数，它顺手统一了整个文件的命名；或者顺手格式化整个文件、重排 import、动了没让它动的模块。AI 没有"这不在我的任务里"的本能，边界不清时，它的默认行为是自行补全假设。

检测信号：git diff --stat 里出现超出任务范围的文件；diff 里混着大量与任务无关的格式变更。

处置：先止损，再决定回滚还是修复（见 2.2）——暂停写入、检查 diff，保留已有人工改动；确认本轮改动可以整体丢弃后，再回到干净锚点，重新下一次边界更明确的任务。预防：在方案文档里写明非目标与禁区（见 3.4），用 worktree 分开任务工作目录（见 2.2）。

1.3 假验证：自称通过

表现：声称"测试已通过"“已验证可用”，但实际没跑、跑的是别的命令，或者选择性引用了输出。这不一定是有意欺骗——AI 可能把"应该会通过"的预期当成了事实陈述——但后果一样：你基于一个不存在的绿灯放行了代码。

检测信号：说不出执行了哪条命令、给不出原始输出；执行耗时与任务量不匹配；输出内容与代码现状矛盾。

处置：要求粘贴原始输出，自己复跑同一条命令。预防：验证脚本化（见 4.4），“通过"必须附带命令与输出。

1.4 一张速查表

三种失败模式有一个共同的工程问题：模型的回答本身不能证明事实正确、改动合规或验证成功。所以防线的设计思路是改造环境：事实可查（文档与走读）、边界成文（方案文档与隔离）、验证可复现（脚本与测试）。后面各章，就是把这三件事做扎实的具体做法。

二、搭建工作台：worktree、共享文档与会话管理

2.1 给 AI 配三层记忆

AI 的工作质量取决于它记得什么。按生命周期，我把它的记忆分成三层：

前两层两篇指南里讲过，这里重点说第三层。总有一类知识不适合入库：个人笔记、带私有信息的走读、与具体仓库无关的方法论。但它们恰恰是 AI 最需要的背景。我的做法是：在所有仓库之外维护一个公共文档目录，通过 Windows Junction 以 docs-ref/ 的名字接进每个 worktree——本地留存、全局共享、Git 不感知。怎么搭见 2.3 和 2.4。

2.2 git worktree：一任务一分支一目录

多任务并行时，一个工作区只能 checkout 一个分支，几个 AI 任务会互相踩。git worktree 让同一仓库同时挂多个工作目录，各自在不同分支。下面的 Git 命令可在 PowerShell 或 Bash 中执行；先在已有提交的仓库根目录创建任务分支，要求分支名与目标目录尚未被占用：

1
2

git worktree add -b task3/grpc-refactor ../myproject-task3
git worktree list

与 AI 协作时，这套结构特别合身：

• 一会话一 worktree：每个任务有独立的工作文件、索引和 HEAD，减少直接覆盖彼此改动的机会；但 worktree 不是权限沙箱，agent 仍可能通过路径访问其他目录，分支引用、对象库及部分配置也由各 worktree 共享；
• 故障范围更清楚：先检查本任务的改动，再决定修复还是从已知提交重新开始。共享文档、数据库和外部服务仍可能受其他任务影响；
• 为回滚保留锚点：每个验证过的小步保存为提交。git reset --hard 会丢弃已跟踪文件的未提交改动，还可能覆盖挡路的未跟踪文件；无目标参数时只是重置到当前 HEAD，不会自动寻找上一个正确版本。执行前必须核对目录、目标提交和保留范围；混有人工改动时，应先单独保存或只撤销明确属于本任务的部分。

任务完成、需保留的内容已保存后，在主工作目录执行 git worktree remove ../myproject-task3 清理入口。它通常拒绝移除含未提交改动或未跟踪文件的 worktree；不要用强制删除掩盖尚未确认的内容。忽略文件也要单独检查，不能把 Git 状态干净等同于目录里没有需保留的数据。

2.3 共享文档目录：内容一份，入口各建

结构：公共文档目录放在仓库外（比如 D:\docs），每个 worktree 里放一个名为 docs-ref 的 junction 指向它。所有任务共享同一份文档，零复制。

创建 junction 前，确认目标目录 D:\docs 已存在、当前用户有相应访问权限，且 worktree 根目录下尚无 docs-ref 入口。下面二选一：第一条在 PowerShell 执行，第二条在 CMD 执行。

1

New-Item -ItemType Junction -Path ".\docs-ref" -Target "D:\docs"

1

mklink /J ".\docs-ref" "D:\docs"

选 junction 而不是符号链接，是因为它不需要管理员权限或开发者模式，且只能指向本地卷，行为可预期。

然后让 Git 忽略它。先用这条命令定位当前实际生效的 exclude 文件：

1

git rev-parse --git-path info/exclude

在其中加入两行：

1
2

docs-ref/
.ignore

这里有个实测细节：exclude 文件是各 worktree 共用的——在 linked worktree 里执行上面那条命令，解析到的仍是主仓库的 .git/info/exclude（git 2.55 实测；以你机器上这条命令的输出为准）。所以 exclude 只需要配一次，全部 worktree 生效。但 junction 本身是工作目录里的文件，不会自动出现在其他 worktree——每个新 worktree 都要各建一次 junction（以及 2.4 的 .ignore）。

2.4 让 AI 读到被 Git 忽略的文件

docs-ref/ 被 Git 忽略后，文件选择器可能不再列出其中的文件。要区分三件事：Git 是否跟踪、搜索是否列出、工具是否有权读取。下面讨论搜索可见性，不把忽略规则当作访问控制。

Claude Code：设置选择器的 respectGitignore。当前官方设置参考支持把该键写入用户、项目、项目本地或托管设置。只想影响当前项目时，可以在 .claude/settings.local.json 中合并下面的键，不要覆盖文件内已有的其他配置：

1
2
3

{
  "respectGitignore": false
}

终端里的 /config 也提供 Respect .gitignore in file picker 开关，它写入 ~/.claude.json；当前版本只有在设置文件未指定此键时才使用该回退值。旧版本的能力和优先级可能不同，以所用版本的设置参考与实际候选结果为准。

这个开关只影响 @ 选择器的候选列表，不是访问控制：被忽略的文件在权限允许时仍可通过明确路径读取。关闭过滤可能让 .env 等敏感文件进入候选；不再需要时恢复 true。配置后仍应实际搜索目标文档，目录链接能否被遍历是另一项条件。

Codex 侧的候选办法：.ignore 反向规则（按路径）。对使用 ripgrep 的搜索，.ignore 可重新包含被 Git 忽略的路径；ripgrep 的优先级为 .rgignore > .ignore > Git 忽略规则。但这不能证明 Codex CLI、IDE 与桌面端的 @ 选择器行为相同。可以在 worktree 根目录的 .ignore 中追加下面两行，保留已有规则，再验证当前客户端是否列出目标文件：

1
2

!/docs-ref/
!/docs-ref/**

Git 不读取 .ignore，所以原有 Git 忽略规则保持生效。可先在 worktree 根目录执行 rg --files --hidden --follow docs-ref，检查输出中是否出现预期文档；--follow 用于遍历链接目录，忽略规则本身不会开启链接遍历。这只能验证该条 ripgrep 命令，随后仍要在 Codex 的 @ 选择器中单独验证。若选择器不支持，直接提供明确的文件路径，请 agent 在权限允许时读取，不要把命令行搜索成功当成客户端验证成功。

两种方案的取舍：

我的用法：优先按路径放开所需文档，客户端不支持时使用明确路径。CC 侧优先限制到所需项目，仍要留意候选范围。敏感文件应移出共享资料目录，并由工具权限与文件系统权限限制访问；不出现在候选中，并不代表 agent 无法读取。

2.5 会话命名：把会话当任务索引

会话是最小的工作单元，也是最容易失控的东西——并行任务一多，/resume 列表里全是分辨不出归属的会话。命令层面两篇指南都讲过（CC 的 /rename 与 claude -n，Codex 的 /rename 与 codex resume），这里只补一条命名约定：

1

{任务号}-{主题}-{性质}

例如 3-gRPC改造-方案讨论、3-gRPC改造-清单执行。它和 3.3 的文档编号共用一套任务号，效果是：会话、文档、worktree、分支四者同名互查——“那个 gRPC 任务的方案会话"不需要回忆，按任务号就能定位。像对待分支一样对待会话：一个会话一个用途，用完归档，不把新话题混进旧会话。

三、大任务的文档工程

单人用 AI 做小任务，对话就是全部；任务一大，对话就不够了——上下文装不下，人记不住，AI 更记不住。这一章是全文的核心：用一套文档体系，把"一个大任务"变成"一串可独立托付的小任务”。

3.1 为什么必须拆

• 上下文有限：一个跨周的大任务塞不进一个会话；就算塞得进去，经验上长上下文里的指令遵循也会变差，早期的约束到后期就"忘了”；
• 失败模式被放大：任务越大，幻觉与越界修改的爆炸半径越大，审查也越难——没人审得动一个三千行的 diff；
• 可验证性：拆小之后，每一份产出都能被独立验证、独立回滚。

拆的粒度用一个标准卡：一个任务 = 一次可验证的交付。写不清验收标准的，说明还拆得不够小。

3.2 文档三件套：走读、方案、清单

每个大任务配三类文档，各管一段：

代码走读（现状）：让 AI 系统性地读代码，产出"这个系统怎么工作"的结构化笔记——模块划分、关键类型、数据流、约定与坑。走读是所有后续工作的地基：它让 AI 的论断锚定在真实代码上（防幻觉），也让人确认"AI 理解的系统"和"实际的系统"是同一个。走读按主题沉淀、跨任务复用，放共享文档目录。

实现方案（设计）：改什么、怎么改、分几步、每步的风险与验证方式。AI 起草、人审查拍板（见 4.1）。方案是任务期间最高权威的文档，后续所有会话以它为准。

任务清单（执行）：把方案拆成可勾选的步骤列表，一步一项，写明验证方式。每个任务一份独立清单，它是跨会话的进度账本：新会话接手时先读清单，做完一步勾一步；多 agent 协作时它还是共享状态（见第五章）。

三者的关系是一条流水线：走读喂方案，方案拆清单，清单驱动会话。文档在这里的角色，是 AI 的外置记忆——会话会丢，文档不会。

3.3 编号与命名：文件名自带顺序和语义

文档一多，“哪个任务、哪份文档"就成了日常检索。我用一套固定的文件名结构：

1

{任务号}.{序号}.{任务名}-{文档类型}.md

例如：

1
2
3

3.01.任务1-gRPC改造-走读.md
3.02.任务1-gRPC改造-方案.md
3.03.任务1-gRPC改造-清单.md

规则只有三条：任务内的序号零填充，让同一任务的文件按字典序排列；任务名人类可读，内容可变——名字里的数字（如"任务1”）只是可读标识，不必与任务号对应；类型后缀（走读/方案/清单）区分角色。若任务数达到两位数，任务号也应统一宽度，例如 03.01，避免字典序把 10 排在 2 前面。结构固定、内容随意——它不是什么规范，只是一个用了就回不去的约定。

3.4 任务文档模板：必备章节

方案文档我固定用一套章节骨架：

1
2
3
4
5
6
7
8
9

# {任务名}

## 背景与目标
## 术语说明
## 现状摘要
## 实施方案
## 非目标与禁区
## 验收标准
## 风险与回滚

每个章节都有存在的理由：

• 背景与目标：为什么做、做成什么样。AI 知道目标，才谈得上取舍；
• 术语说明：统一叫法。领域词汇的歧义是方案跑偏的隐形原因——同一件事两种叫法，AI 就当成两件事；
• 现状摘要：引用走读结论，不重复铺陈，控制上下文成本；
• 非目标与禁区：不做什么、不许动哪些文件和模块。这是最重要的一章：越界修改的根源，就是方案文档只写了"做什么"。AI 对边界靠推断补全，写明禁区是最便宜的预防；
• 验收标准：怎么算完成，尽量写成可执行的命令或测试（衔接 4.4 与 4.5）；
• 风险与回滚：出问题怎么退回来（衔接 2.2）。

再配一个开工仪式：让 AI 复述任务与边界——用自己的话重述目标、非目标、验收标准，然后你再纠正。理解偏差在第一分钟暴露，成本近乎为零；等到审查阶段才发现，返工的是一个会话的产出。

3.5 多任务并行时的文档组织

任务多了以后，公共文档目录按任务分目录，走读按主题另立共享库：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

docs/
├── 2.任务0-通讯库重构/
│   ├── 2.01.任务0-通讯库重构-方案.md
│   └── 2.02.任务0-通讯库重构-清单.md
├── 3.任务1-gRPC改造/
│   ├── 3.01.任务1-gRPC改造-走读.md
│   ├── 3.02.任务1-gRPC改造-方案.md
│   └── 3.03.任务1-gRPC改造-清单.md
└── ref/                     # 跨任务共享的走读库
    ├── net-threading.md
    └── grpc-basics.md

配合 worktree，喂给每个会话的文档只剩两类：本任务的目录 + 用得到的走读。上下文最小化，检索靠任务号直达。

四、质量闭环：审查与验证

4.1 方案审查到底审什么

方案是 AI 起草的，但方案审查是人的主场——判断力和品味不能外包。审三层，由浅入深：

• 命名与概念：新名词是否贴合领域、与既有代码一致。命名歪了，后面所有代码跟着歪，纠错成本随时间上升；
• 项目结构：改动落在哪个项目、哪一层；依赖方向对不对；是复用了既有抽象，还是在旁边又造了一个；
• 可行性：方案依赖的关键假设是否成立——真有这个 API？性能量级估过吗？跨平台行为确认过吗？可行性问题在方案阶段发现是改文档，在编码后发现是返工一轮。

审查的输入永远是"方案文档 + 相关走读"，不是只看 AI 的一句话总结。

4.2 双模型审查，并且要回归

写和审可以用不同模型。我的常态是 Claude 写、GLM 审，或者反过来；实际使用中，这有时能带来不同视角。但不同模型也会共享盲区，不能保证相互纠错。审查方应独立阅读需求与代码，用文档、源码或实验裁决分歧，不能把两次赞同当成正确性的证明。

审查要输入完整：审查方必须拿到方案文档和完整 diff。知道"意图"才能审出"偏差"，脱离意图的审查只能挑表面毛病。

要回归（regression）：审查意见修改后，必须让审查方对修改后的版本再确认一次。“改了"不等于"改对了”——修改本身可能引入新问题，也可能改丢了原来的意图。没有回归环节的审查流程，最后一轮意见是没人背书的。

顺带一提，你正在读的这篇文章就是这么生产的：写作流程定义在 skill 里，两位审阅者读同一版本，任何一方改了正文，另一方就要重新确认——写代码和写文章，质量闭环是同构的。

4.3 diff 纪律

审查代码时的操作顺序，固定成纪律：

1. 先看 git status --short，再看统计：用状态检查新增与暂存文件，再分别看 git diff --stat 和 git diff --cached --stat。单独的 git diff --stat 只覆盖未暂存的已跟踪改动，会漏掉已暂存变更和未跟踪文件；
2. 再看分文件 diff：先核心逻辑，后配套变更；分别检查 git diff 与 git diff --cached，未跟踪的新文件直接阅读全文。如果任务已产生提交，还要比较约定的基线与任务分支，不能只检查工作区；
3. 对大重写保持警惕：AI 偶尔会重写整个文件，而不是打一个精准 patch——内容可能等价，但审查负担完全不同，应当要求它改用最小改动方式重做。

两条配套规则：最小改动原则——只做任务内的变更；禁止顺手格式化——格式化、import 重排、大规模重命名会制造噪声，把真实改动淹掉，审查能力直接归零。格式问题交给格式化工具，单独一次提交。

4.4 验证可复现：一条命令，以输出为准

把 build、test、lint 收进一条命令——make verify、just verify 或一个 verify.ps1，人和 AI 跑同一条。然后是两条铁律：

• “验证通过"必须附执行证据：命令、工作目录、对应代码版本、退出码及关键输出；长日志保存到可查看的文件或 CI 任务，不能只截取成功片段；
• 核对测试是否真的运行：退出码为零还不够，要检查用例数量、跳过项和环境。优先看工具执行记录或 CI 原始日志，并不定期自己复跑；AI 在聊天中粘贴的所谓原始输出仍可能不真实。

这也是 1.3 的制度化解法：把"验证"从对话里的一个说法，变成可复现的机器事实。

4.5 从提示词走向测试

前面所有手段解决的是"怎么让 AI 不出错”，这一节换个角度：怎么让"对"的定义本身离开自然语言。

对能自动验证的需求，把人工确认的验收标准写成测试，能减少反复口述的歧义。但测试通过只证明被执行的断言满足了：漏测边界、错误的预期、过度 mock，都会让错误实现变绿；AI 也可能改弱断言、删除或跳过用例。因此，测试本身要对照需求审查，测试的变更与代码的变更享受同等的审查待遇（见 4.3）。

可以采用测试驱动开发（Test-Driven Development，TDD）的节奏：先把确认过的验收标准翻译成测试，确认它因目标行为尚未实现而失败，再实现到通过，最后在测试保护下重构。AI 可以降低编写测试的成本，但不会自动解决测试设计、遗留系统可测性或维护成本的问题。

边界也要说清：不是所有验收标准都适合完全自动化。视觉回归和架构规则可以覆盖部分 UI 与结构要求，观感、命名和设计取舍仍需要人工判断。测试与审查互补，审查也必须检查行为是否正确。日常沟通仍然重要；适合自动化的核心需求，则尽量沉淀为可执行的规格。

五、多 Agent 分工：写、审、监控

单会话流程跑顺之后，自然的下一步是并行：任务大到一定程度，一个会话串行做不完，就拆给多个 agent。

5.1 三个角色

• 写码 agent：按任务清单实现，一个任务一个；
• 审查 agent：对每个完成的步骤，对照方案审 diff；
• 监控 agent：盯清单进度、汇总状态，发现卡住或跑偏时向人报告。

5.2 模型搭配的原则

• 写和审尝试不同模型——理由同 4.2，增加视角，但不保证消除盲区；
• 按难度分配审查与监控——机械进度汇总可以先用成本较低的模型；涉及并发、安全或架构的审查需要足够的推理能力，不能只因它是读取任务就降档。

背后是一个实用原则：按风险和实测效果分配模型。把返工、漏检和人工复核的成本一起计算，再判断便宜模型是否真的省钱。

5.3 让分工成立的前提

纸面上画三个框不难，让它真的工作需要四件事：

1. worktree 分目录，权限限制写入范围：每个写码 agent 各占一个 worktree；共享资料仍是同一份文件，应明确只读范围与编辑负责人；
2. 清单统一记账，更新串行化：每个任务的清单由一个负责人更新，其他 agent 提交结果；若必须多方写入，使用带锁或版本冲突检测的任务系统，避免同时覆盖 Markdown。每个完成项关联代码版本和验证记录，勾选本身不构成完成证明；
3. 审查 agent 必须读方案文档：知道意图才能审出偏差（同 4.2）；
4. 人握着合并权：方案拍板、分歧裁决、最终合并，三个 agent 都不碰主分支。

最后一句实话：多 agent 不是银弹，协调成本真实存在——清单对账、上下文同步、审查排队都是开销。先把单会话流程跑顺（前三章），再逐步并行化；顺序反过来，通常收获一堆混乱。

六、沉淀为基础设施：skill、自动化约束与经验回流

6.1 项目专用 skill：流程写一次，处处调用

识别信号很简单：同类任务第三次出现。发版流程、走读模板、审查清单……凡是每次都要口头交代一遍的流程，都值得写成项目专用 skill——步骤、检查项、输出格式固化成文件，新会话零上下文继承也能按流程走。skill 是三层记忆之外更高一级的形态：不是帮 AI 记住，而是把做法本身固化。比如把 3.4 的文档模板做成 skill，“新任务"一句话就能起全套文档。

6.2 脚本与自动化约束：不靠自觉靠机制

在 CLAUDE.md 里写提交前跑检查，是给模型的指令；把检查接入能阻断操作的 hook 或必需 CI 检查，才能形成可执行门槛。以 Claude Code 为例，PreToolUse 命令钩子可用退出码 2 阻止工具调用，普通非零退出码未必阻断；只打印提醒也不等于拦截，必须实际验证失败路径。

权限 deny 适合拦截已覆盖的调用形式，但命令文本匹配不是完整的安全边界：git push --force 还可能写成 git push -f，或由脚本间接调用。重要限制应结合沙箱、操作系统权限、远端受保护分支和必需检查；本地 Git hook 也可能被跳过。机制能减少越界与漏跑检查，却不能独自判断需求是否正确、测试是否充分。

6.3 经验回流：让踩过的坑只踩一次

新会话不会自动拥有上一会话的完整上下文；Claude Code 的 auto memory 等功能可以保存部分经验，但不能保证所有教训都被准确提取和重新加载。因此，关键规则仍要写成可审查的项目文档或 skill。任务收尾可以固定问一句：

这个任务里学到了什么，是值得写进 CLAUDE.md、skill 或文档模板的？

把答案真写进去。久而久之，CLAUDE.md 会从"仓库说明书"长成"经验库”，skill 从"流程"长成"标准做法"。这本质上是给个人知识做持续集成：知识也要 CI，不回流就腐烂。

七、瓶颈的转移：读、判断与克制

最后把视角拉远一点。AI 把"写代码"的成本打了下来，但总成本没有消失，而是转移了：

• 读：审查大 diff 成为日常，4.3 的纪律不是讲究，是生存技能；
• 判断：方案拍板、可行性裁决、命名品味——AI 给选项，你给结论；
• 决策：什么托付、什么不托付，成了每小时都在做的选择。

三条收尾的克制：

1. 能验证的才敢托付。你对一个领域建立不起验证手段（测试、走读、基准），AI 在这个领域的产出对你就全是黑箱——先造验证，再谈托付；
2. 不是什么都值得 agent 化。一行改动、需要精密品味的重构、解释成本高于动手成本的活，自己写更快。AI 是工具箱里最锋利的一件，不是唯一一件；
3. 吞吐可能放大返工。如果单位产出的缺陷率不变，产出越快，单位时间累积的缺陷也越多；这不是固定倍数的性能结论。纪律的价值随吞吐放大，而不是消失。

这套工作流如果只用一句话总结：把"信任 AI"换成"验证 AI"。工程手段不生产信任，它生产可验证性——而可验证性，才是你敢把大任务交出去的全部底气。

参考资料

• Claude Code 使用指南
• Codex 使用指南
• ripgrep GUIDE：ignore 文件的优先级
• git-worktree 官方文档
• gitignore 官方文档（含 info/exclude）
• Claude Code 设置参考（respectGitignore）
• Git reset 官方文档
• Microsoft：Hard Links and Junctions
• Claude Code Hooks 参考
• Claude Code 权限规则及边界
• Claude Code 记忆机制
• Codex CLI 会话命令