Conducty用一套文档把你变成靠谱产品经理和DDD设计大师！这个开源Conducty（点击标题）用备忘录和说明书给AI当导航，解决它记不住项目、容易迷路的问题，让开发变得靠谱又省心。
Conducty的原理是用一套结构化文档系统把项目变成AI能随时翻看的说明书，让AI从记性差但聪明变成稳定又靠谱的协作伙伴。
Conducty是针对Claude Code的系统级AI智能体编排，背后用一个Obsidian知识库作为上下文引擎。
只计划一次，然后并行执行，接着审查并发布，最后把之前做的事再读回来，融入下一次计划。
大多数AI编程会话是这样的：输入提示词，等着，走神，检查结果，修修补补，再重复。在这个循环里，瓶颈不是模型能力，而是人类自己安排任务的低效，以及之前会话里的经验教训直接消失不见了。
Conducty把这个流程变成一个结构化的、每个计划一个循环的方式：批量做计划，通过Claude Code的子智能体并行执行提示词，带着证据来审查和发布，并且把所有内容（计划、设计、上下文、改进点、失败模式、指标数据）都写进一个Obsidian知识库，形成一个用维基链接串联起来的知识网络。下一次做计划时，直接读取这个网络，结果会越来越精准。
在底层，它基于被验证过的工程思维：Shape Up里“需求驱动规划”、丰田Kata的改进循环、《程序员修炼之道》里的“追踪弹”，以及《Release It!》中的精准严谨。最后得到的，是一个能持续积累、越用越强的学习系统。
Conducty系统级AI智能体编排技术：基于Obsidian知识库实现Claude Code并行计划与持续学习
Conducty循环周期流程
Conducty周期：从塑造到交付的完整闭环开发流程，包含代码审查与反馈改进
塑造 → 规划 → 追踪 → 执行 → 验证 → 改进 → 代码审查 → 交付 |
- 塑造Shape — 设定投入规模，定义边界和禁止区域，输出一份设计说明
- 规划Plan — 将设计分解为有时限的提示词，并带有追踪标记和校准过的审查级别
- 追踪 — 每组运行一个提示词作为追踪子弹，验证规划的假设
- 执行 — 通过Claude Code的任务工具分发剩余的提示词，审查严格程度与风险匹配
- 验证 — 在组之间设置检查点，检查健康指标和进度图
- 改进 — 提取失败模式，执行改进套路，塑造下一个规划
- 代码审查（周期后） — 对整个分支的规划累积差异进行整体审查
- 交付（周期后） — 合并前关卡：代码格式检查、类型检查、测试、密钥检查、漏洞检查、代码审查结论
Conducty周期是一个从塑造到交付的完整开发流程，包含规划、追踪、执行、验证、改进、代码审查和交付七个阶段，并通过反馈闭环持续优化。
快速上手——你的第一个计划
安装完成后，在任意项目目录下打开 Claude Code，然后输入：
set up Conducty
这会触发 conducty-bootstrap 技能，它会带你完整走一遍一个小范围的首个计划，让你在实际投入工作之前先感受整个循环。
实战例子：对话长这样
你：set up Conducty
Claude：Conducty 知识库在 ~/Obsidian/Conducty。可以继续吗？
你：可以
Claude：我们从哪个项目开始？
你：~/code/my-app
Claude：[运行 conducty-context — 生成了7条知识库笔记：
上下文 我的应用 + 架构/编码规范/不可变规则/热点区域/测试/术语表]
发现4个DDD限界上下文：认证、计费、API、数据库。
测试命令是：npm test。选一个小目标吧。
你：用TDD方式添加一个日期格式化的辅助函数
Claude：[运行 conducty-plan，30分钟需求预算，单个提示词，仅验证，不用并行]
计划笔记已写入：Plan 2026-04-27 1430 日期辅助函数.md
在 Obsidian 中打开它 — 把提示词复制到一个全新的 Claude Code 会话中（在 ~/code/my-app 目录下）。
你：[粘贴提示词 → 执行者先写测试，再写代码 → 验证]
你：搞定了
Claude：[运行 conducty-checkpoint → conducty-review → conducty-improve。更新计划索引、指标、提示词日志；写入 Improvement 2026-04-27 1500.md]
第一个计划完成。通过率：100%。要不要看看知识库里的内容？
到这一步，你就有了一个能工作的知识库，里面每个项目有七条笔记，还有你的第一条改进记录。之后的每一次会话都是从 conducty-plan 开始。
下一次计划：
plan this work: 重构计费模块，让它用上新的税率引擎
conducty-plan 会读取你之前的计划、最新的改进记录、失败模式、my-app 项目的上下文子图，然后给你一个结构化的计划，里面带追踪标记和校准好的审查等级。你确认之后，就可以执行这个计划了。
在分支结束、准备合入之前：
review my changes
ship it
conducty-code-review 会生成整个分支的审查笔记。conducty-ship 会跑六个检查项，输出绿灯/黄灯/红灯的结论。
上下文引擎——一个Obsidian知识库
Conducty 的状态不是存放在 ~/.conducty/ 下面的一个平淡无奇的日志文件里，而是一个 Obsidian 知识库。里面每一个计划、每一个设计、每一个项目上下文、每一次改进、每一条失败模式、每一行指标数据、每一条提示词日志，都是一个独立的笔记，而且每个笔记都通过维基链接和相关的笔记连在一起。一个计划会链接到它用到的设计、加载的上下文笔记、正在测试的改进实验，以及上一个计划里延续下来的工作。下一个计划读取这个知识网络，就能继承所有这些信息。
知识库位置：$CONDUCTY_VAULT（环境变量）→ 如果没有设置则用 ~/Obsidian/Conducty/。如果你想用已有的知识库，设置这个环境变量指向它就行。
命名规则：每次实例的笔记都带时间戳——一天内有多个计划是很正常的。
知识库按类别分目录存放——每个实例笔记在专门的目录里；每个项目的上下文放在 Context/{项目名}/ 下面；累积型笔记放在 Accumulators/ 下面。维基链接按文件名在所有子文件夹中解析，所以目录结构只是为了整理，不影响链接。
完整的知识库规范请查看 skills/conducty-obsidian/SKILL.md：包括前置元数据、链接规则、索引规范和启动引导。
这个代码仓库本身也是一个支持 Obsidian 的目录——技能文件使用了前置元数据 + [[维基链接]]，所以你可以直接把整个仓库作为知识库打开，浏览技能之间的连接关系。
每个计划的工作流程
1、启动计划：塑形和计划
在任何项目里，让 Claude Code 启动一个计划。conducty-plan 技能会：
- 从知识库中读取最新的计划、最新的改进笔记，以及失败模式和指标
- 加载缓存的项目上下文（Context {项目名}.md）
- 询问目标和本次计划的需求预算（时间预算）
- 对非简单的目标进行塑形：中/高复杂度的目标会走 conducty-shape 流程，做需求驱动的设计，明确不做什么以及如何控制跑偏
- 生成一个计划笔记，里面包含并行组、追踪标记和校准好的审查等级
- 在最终定稿前，检查每个提示词有没有常见的"坏味道"
- 分配审查等级：仅验证（低风险）、规格审查（中风险）、完整审查（高风险）
2、执行：追踪和执行
- 自动化方式（推荐）：使用 conducty-execute 通过 Claude Code 的任务工具来运行提示词。每组里的追踪提示词先跑——如果它失败了，说明计划本身需要修改，而不是简单修一下代码就行。剩下的提示词作为子智能体执行，审查严格度根据复杂度来调整。
- 手动方式：打开计划笔记，复制提示词，在单独的 Claude Code 会话中运行。所有提示词都包含时间预算、不做什么的范围、以及升级处理的状态。
如果多个并行提示词要改同一个代码仓库，使用 conducty-worktrees（或者直接用任务工具里 isolation: "worktree" 参数）来创建隔离的工作树。
3、组与组之间：检查点
每组完成后，conducty-checkpoint 计算健康指标（首次尝试通过率、重试率、阻塞数量），更新每个目标的山形图进度位置，并检测系统性故障（出现2个以上相关联的失败，说明是计划层面出了问题，而不是单个代码bug）。
修复提示词会在正确的杠杆点上生成：计划层面、提示词层面、或代码层面。同一个提示词失败三次，会触发熔断机制——升级给用户处理。
4、计划结束：审查和改进
conducty-review 带着基于证据的结论来审计所有改动，把内容追加到知识库里的失败模式、指标、提示词日志中，并为下一次计划准备好可以传承的情报。
conducty-improve 执行改进流程：对比目标和实际成果、找出障碍、为下一次计划设计具体的实验。每次改进流程会写入一个新的 Improvement YYYY-MM-DD HHmm.md 笔记。这就是让 Conducty 成为一个学习系统的原因——如果不改变行为，历史记录就只是一堆日志。
5、计划之后：代码审查和发布
conducty-code-review 读取当前分支相对于主分支的累积改动，从五个维度做整体审查（规格对齐、正确性、安全性、架构/耦合度、测试/可维护性）。发现的问题按严重程度分为"关键/重要/次要"，并写入 Code Review YYYY-MM-DD HHmm.md。关键级别的问题会回流到失败模式中，让下一次计划能预防它们。
conducty-ship 是合入之前的关卡。六个检查项：代码审查结论、代码格式、类型检查、完整测试套件、密钥扫描、依赖项漏洞检查。输出一个结论（绿灯/黄灯/红灯），写入 Ship Report YYYY-MM-DD HHmm.md。ship 命令永远不会自动合入代码——结论只是建议，合入操作由用户自己执行。
质量原则
十个基于工程实践的原则，贯穿每一次会话：
- 原则：需求预算先于计划；来源：Shape Up；实践方式：时间预算约束计划，而不是计划反过来要求更多时间
- 原则：追踪弹先于批量执行；来源：程序员修炼之道；实践方式：第一个提示词先验证假设，再执行剩下的
- 原则：提示词质量是高杠杆点；来源：系统思维；实践方式：在上游投入精力——坏的提示词会浪费下游所有东西
- 原则：有证据才能下结论；来源：Release It!；实践方式：先跑验证、读输出，再下结论（conducty-verify）
- 原则：根治原因先于修修补补；来源：系统思维；实践方式：在最高杠杆点修复：计划 > 提示词 > 代码
- 原则：设计先于实现；来源：Shape Up；实践方式：非简单的目标必须先塑形，再写提示词
- 原则：描述先于修改；来源：修改代码的艺术；实践方式：改之前先验证现有行为
- 原则：深模块，不要走形式；来源：软件设计哲学；实践方式：技能要减少复杂度，而不是增加一堆复选框
- 原则：根据风险调整严格度；来源：程序员修炼之道；实践方式：低风险 = 仅验证；高风险 = 完整审查
- 原则：不学习就会重复犯错；来源：丰田Kata；实践方式：每天做改进流程，提取经验并做实验
技能依赖图
conducty-system (philosophy, language) |
Obsidian Vault
{vault}/ |