Conducty：给 Claude Code 加上项目记忆和并行执行能力

Conducty 是一个开源的 Claude Code 技能包（skill pack），它解决两个问题：第一，每次开新的 Claude Code session，AI 对你项目的了解从零开始，之前 session 里踩过的坑、积累的经验全部丢失；第二，如果你想让多个 AI 子智能体并行处理不同的任务，缺少一个结构化的执行和审查框架。Conducty 的方案是用一个 Obsidian 知识库（vault）作为"项目记忆"，把计划、设计、上下文、失败模式、指标数据都写成互相链接的笔记，下次 AI 做计划时直接读取这些笔记，越用越精准。

本文是一篇实操指南：怎么装、怎么用、第一个计划怎么跑、进阶怎么玩。

安装

前提条件：已安装 Claude Code 和 Git。

Conducty 的安装做了三件事：把技能文件（skill）链接到 Claude Code 的技能目录，把工作流规则追加到 Claude Code 的全局配置，创建一个 Obsidian 知识库并填充索引笔记。

git clone https://github.com/conducty/conducty.git ~/conducty
cd ~/conducty
export CONDUCTY_VAULT="$HOME/Obsidian/Conducty"  # 可选，默认就是这个路径
chmod +x install-claude-code.sh
./install-claude-code.sh

如果你想手动安装（比如只想要部分功能），核心步骤是：

# 1. 链接技能文件
mkdir -p ~/.claude/skills
for skill in ~/conducty/skills/conducty-*; do
    ln -sf "$skill" ~/.claude/skills/"$(basename "$skill")"
done

# 2. 追加规则到 CLAUDE.md（install 脚本会自动处理，手动方式直接 cat）
cat ~/conducty/CLAUDE.md >> ~/.claude/CLAUDE.md

# 3. 创建知识库目录
mkdir -p ~/Obsidian/Conducty

安装完后重启 Claude Code 让它发现新技能。

卸载也很干净：

rm -f ~/.claude/skills/conducty-*
# 然后从 ~/.claude/CLAUDE.md 中删除 "# --- Conducty Rules ---" 到 "# --- End Conducty Rules ---" 之间的内容

第一个计划：Bootstrap

安装完成后，在任意项目目录下打开 Claude Code，输入：

set up Conducty

这会触发 conducty-bootstrap 技能，带你走一遍完整的计划周期。下面是一个实际的对话例子：

你：set up Conducty
Claude：Conducty vault 在 ~/Obsidian/Conducty。继续吗？
你：可以
Claude：从哪个项目开始？
你：~/code/my-app
Claude：[运行 conducty-context，生成 7 条知识库笔记：
        Context My App + Architecture/Conventions/Invariants/
        Hotspots/Tests/Glossary]
        发现 4 个限界上下文：auth、billing、api、db。
        测试命令：npm test。选一个小目标吧。
你：用 TDD 方式添加一个日期格式化辅助函数
Claude：[运行 conducty-plan，30 分钟需求预算，单个提示词，
        仅验证，不并行]
        计划笔记已写入：Plan 2026-04-27 1430 Date Helper.md
        在 Obsidian 中打开它，把提示词复制到一个新的 Claude Code 会话中。
你：[粘贴提示词，执行者先写测试再写代码，验证通过]
你：搞定了
Claude：[运行 conducty-checkpoint → conducty-review → conducty-improve。
        更新计划索引、指标、提示词日志；
        写入 Improvement 2026-04-27 1500.md]
        第一个计划完成。通过率：100%。

走完这一遍，你就有了：一个能工作的知识库，每个项目 7 条笔记，以及第一条改进记录。之后每次会话都从 conducty-plan 开始。

每个计划的工作流

Conducty 把一个计划拆成六个阶段，形成一个闭环：

Shape → Plan → Trace → Execute → Verify → Improve
  ↑                                     |
  └────────── feedback ─────────────────┘

Shape（塑形）

设定时间预算（appetite），定义做什么和不做什么，产出一份设计笔记。中高复杂度的目标才会走这一步，简单任务直接跳到 Plan。

Plan（规划）

把设计拆成带时间预算的提示词（prompt），每组标记一个追踪弹（tracer），并根据风险分配审查等级：低风险只验证，中风险做规格审查，高风险做完整审查。

Trace（追踪）

每组先跑一个追踪弹提示词，验证计划的假设是否成立。追踪弹失败说明计划本身有问题，需要改计划而不是改代码。

Execute（执行）

剩余的提示词通过 Claude Code 的 Task 工具作为子智能体并行执行。如果多个提示词要改同一个代码仓库，Conducty 会用 Git worktree 创建隔离的工作副本。

Verify（验证）

每组完成后设检查点，计算健康指标（首次通过率、重试次数、阻塞数），检测系统性故障（2 个以上关联失败说明是计划层面的问题）。

Improve（改进）

对比目标和实际结果，提取失败模式，设计下一个实验。写入一条改进笔记，这就是 Conducty 成为"学习系统"的关键：不改变行为的记录只是日志。

计划之外还有两个收尾步骤：

conducty-code-review ：对整个分支做五维审查（规格对齐、正确性、安全性、架构耦合、测试可维护性）
conducty-ship ：合并前的关卡，跑六个检查项（代码审查结论、lint、类型检查、测试、密钥扫描、依赖漏洞检查），输出绿灯黄灯红灯

日常使用时，你的操作只有三步：

plan this work: 重构计费模块，用新的税率引擎
review my changes
ship it

知识库：项目的长期记忆

这个思路和 Karpathy 的 LLM Wiki 一脉相承。Karpathy 的核心洞察是：与其每次提问时让 AI 去 RAG 检索文档（一次性的、没有积累），不如让 AI 维护一个 wiki（每次编辑都会留下痕迹，知识复利增长）。Conducty 把同样的道理用在了编程工作流上：与其每次 session 让 AI 从零理解你的项目，不如让它维护一个知识库，每次计划的成败都写进去，下次直接读取。关于 Karpathy 的 LLM Wiki 设计，见这篇博文的解读。

Conducty 不把状态存在一个平淡无奇的日志文件里，而是一个 Obsidian 知识库。每个计划、每个设计、每次改进都是一条独立笔记，笔记之间用维基链接（ [[Plan 2026-04-27]] 这种格式）串联。下一个计划读取这个知识网络，继承之前所有信息。

知识库的目录结构：

~/Obsidian/Conducty/
├── Conducty Index.md           # 根入口
├── Indexes/
│   ├── Plans Index.md          # 所有计划的索引
│   ├── Designs Index.md        # 所有设计的索引
│   ├── Context Index.md        # 所有项目上下文的索引
│   └── Improvements Index.md   # 所有改进记录的索引
├── Accumulators/
│   ├── Failure Patterns.md     # 失败模式（持续累积）
│   ├── Metrics.md              # 指标数据（每个计划一行）
│   └── Prompt Log.md           # 提示词日志
├── Plans/                      # 计划笔记（带时间戳命名）
├── Designs/                    # 设计笔记
├── Improvements/               # 改进笔记
├── Code Reviews/               # 代码审查笔记
├── Ship Reports/               # 发布报告
└── Context/
    └── my-app/                 # 每个项目一个子目录
        ├── Context my-app.md   # 项目中心笔记
        ├── Context my-app Architecture.md
        ├── Context my-app Conventions.md
        ├── Context my-app Invariants.md
        ├── Context my-app Hotspots.md
        ├── Context my-app Tests.md
        └── Context my-app Glossary.md

有两个值得注意的设计。第一，累积型笔记（Accumulators）： Failure Patterns 、 Metrics 、 Prompt Log 不是每次创建新文件，而是在同一个文件里持续追加。这意味着 AI 读取时只需要打开一个文件就能看到所有历史。第二，每个项目的上下文拆成 7 个维度（架构、编码规范、不变量、热点区域、测试、术语表、模块），而不是一个笼统的 README。这让 AI 在做计划时可以精确加载它需要的信息，而不是把整个项目文档塞进 context window。

进阶：推荐学习路径

Conducty 的 README 建议了一个渐进式的学习路径：

前 1 个计划

只用手动模式，不用 conducty-execute （自动子智能体）。复制计划笔记里的提示词到新 session 中手动运行，目的是理解每个步骤在做什么。

第 2-3 个计划

开始用 Medium 复杂度目标，这会触发 conducty-shape （塑形流程），学习怎么设需求预算和排除区。低复杂度的提示词可以开始用自动执行。

第 4-5 个计划

全部用自动执行。观察追踪弹策略怎么提前捕获错误的假设。打开 Improvements Index ，看改进实验是否真的在影响后续计划。

几个计划之后

看 Accumulators/Metrics.md 里的数据。如果首次通过率低于 70%，说明提示词质量需要提升。如果某个失败模式反复出现，那就是最高杠杆的改进点。

高级技能

conducty-dialectic ：六角色结构化辩论，用于有真正权衡取舍的架构决策（不要用在简单选择上）
conducty-worktrees ：当 3 个以上提示词要改同一个仓库时，用 Git worktree 做隔离
自定义提示词模板：在 skills/conducty-plan/prompt-templates/ 下新建 .md 文件，覆盖 Conducty 没有内置的工作类型

总结

Conducty 的核心卖点不是某个具体功能，而是三个设计决策的组合：

第一，把 AI 的工作状态存在一个可浏览、可链接的知识库里，而不是让它在 session 结束时消失。这让 AI 能从过去的经验中学习，而不是每次从零开始。

第二，用工程方法论（Shape Up 的需求预算、追踪弹、丰田 Kata 的改进循环）约束 AI 的工作方式，而不是给 AI 一个开放式的任务然后祈祷它做对。

第三，根据风险调整审查力度。低风险改动只验证能跑就行，高风险改动走完整审查流程，不浪费精力也不埋隐患。

这三个决策都不依赖 Obsidian 或任何特定工具。Conducty 选择 Obsidian 做实现，是因为维基链接和图谱视图天然适合知识网络。工具不同，方法论相通。

Conducty 背后的工程原则（Shape Up、丰田 Kata、程序员修炼之道、Release It!）在上一篇博文中有详细解读。