目录
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
如果你想手动安装（比如只想要部分功能），核心步骤是：
mkdir -p ~/.claude/skills for skill in ~/conducty/skills/conducty-*; do ln -sf "$skill" ~/.claude/skills/"$(basename "$skill")" done cat ~/conducty/CLAUDE.md >> ~/.claude/CLAUDE.md mkdir -p ~/Obsidian/Conducty
安装完后重启 Claude Code 让它发现新技能。
卸载也很干净：
rm -f ~/.claude/skills/conducty-*
第一个计划：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!）在 上一篇博文 中有详细解读。