惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

Security Latest
Security Latest
量子位
博客园 - 三生石上(FineUI控件)
小众软件
小众软件
S
SegmentFault 最新的问题
The GitHub Blog
The GitHub Blog
AWS News Blog
AWS News Blog
T
Threat Research - Cisco Blogs
博客园 - Franky
Vercel News
Vercel News
H
Help Net Security
Martin Fowler
Martin Fowler
Security Archives - TechRepublic
Security Archives - TechRepublic
L
LINUX DO - 热门话题
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
L
Lohrmann on Cybersecurity
Cyberwarzone
Cyberwarzone
W
WeLiveSecurity
V2EX - 技术
V2EX - 技术
C
CERT Recently Published Vulnerability Notes
S
Secure Thoughts
C
Cyber Attacks, Cyber Crime and Cyber Security
B
Blog RSS Feed
H
Hacker News: Front Page
P
Proofpoint News Feed
博客园 - 聂微东
N
News and Events Feed by Topic
C
Cybersecurity and Infrastructure Security Agency CISA
D
Docker
博客园_首页
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
人人都是产品经理
人人都是产品经理
The Hacker News
The Hacker News
S
Security @ Cisco Blogs
博客园 - 【当耐特】
F
Fortinet All Blogs
The Register - Security
The Register - Security
A
About on SuperTechFans
D
Darknet – Hacking Tools, Hacker News & Cyber Security
S
Schneier on Security
NISL@THU
NISL@THU
Attack and Defense Labs
Attack and Defense Labs
Help Net Security
Help Net Security
Cisco Talos Blog
Cisco Talos Blog
月光博客
月光博客
IT之家
IT之家
有赞技术团队
有赞技术团队
Know Your Adversary
Know Your Adversary
Hugging Face - Blog
Hugging Face - Blog

暗无天日

读:AI Agent 安全日志——从可见性与隐私的两难说起 - 暗无天日 读:AI Agent 生产化——一份从原型到上线的速查清单 - 暗无天日 AI写作的语言指纹——如何让文字不那么像机器 - 暗无天日 读:50 条 Claude Code 技巧——一个工程经理的六个月使用心得 读:AI 辅助开发为什么让 E2E 测试更有价值 - 暗无天日 读:在Emacs中使用Claude Code(Spacemacs适配版) - 暗无天日 Claude Code 背后的工程哲学——读 Agent Harness Engineering 读:Agent Harness Engineering——AI 智能体不只是模型,还有套件 - 暗无天日 browser-harness:让 AI 直接接管你的浏览器 - 暗无天日 读:Security-First CI/CD —— DevSecOps 自动化实践指南 TIL: 数字小键盘的小数点陷阱与行内算术求值 - 暗无天日 读:Immutability 不是万能药,它是一种权衡 - 暗无天日 读 — GitHub Trending 里的 Claude Code 技能包 读 — Prompt Caching 省钱指南 TIL: Emacs 中那些跟鼠标配合的冷门快捷键 - 暗无天日 读:Anvil——把 Emacs 变成 AI 的工具服务器 读:Emacs 代码折叠终极指南 - 暗无天日 读:Clojure 搭车客指南 - 暗无天日 git推送失败后恢复仓库损坏的完整记录 - 暗无天日 多智能体系统的两个有效模式——以及对 Claude Code 用户的启示 - 暗无天日 用 Org Babel 写 Literate 博文:扩展执行 + 定制导出 proced:Emacs 内置的进程查看器 - 暗无天日 从 proced 定制中学到的 Elisp 模式 读:让 Emacs proced 在 macOS 上显示 CPU 和内存 异步编程的函数着色税 - 暗无天日 链式调用的代价:JavaScript 和 Clojure 的共同教训 - 暗无天日 hyperfine:命令行基准测试工具 - 暗无天日 管道中的变量去哪了?——子 shell 作用域陷阱 - 暗无天日 开源包装器的信任陷阱:四个危险信号 - 暗无天日 程序员愿意为 AI 写文档,却不愿为同事写 - 暗无天日 mktemp: Shell 脚本中临时文件的安全陷阱与最佳实践 - 暗无天日 WSL9x —— 在 Windows 9x 里跑 Linux 内核 6.19 用 ox.el 做你想做的事 —— org-export 高级编程指南 读:Hot-wiring the Lisp Machine —— 用纯 Elisp 构建零依赖的 Org 静态站点生成器 Elisp 性能优化的六个实战教训 - 暗无天日 fcitx5 下 Emacs 无法切换输入法的排查 - 暗无天日 ERT 测试交互命令的三种方式 - 暗无天日 SEM Assistant: 当 Elisp 守护进程遇上 LLM 用 dmsg 给 Elisp 加上结构化调试日志 用 org-habit 追踪非每日习惯 - 暗无天日 Clojure X-Men:当编程语言特性变成超能力 - 暗无天日 TIL: 用 diff-hl 在 fringe 中显示 git 变更 读:llm-test —— 用 LLM agent 驱动 Emacs 测试 TIL: AI 时代的橡皮鸭调试 - 暗无天日 fcitx 启动后键盘输入卡顿的排查 - 暗无天日 TIL: 早期网页的图片热区导航 - 暗无天日 读 Seeing the Whole System 用 Emacs 自动生成每周链接推荐 - 暗无天日 读:ASCII control characters in my terminal 读 What to learn - 暗无天日 Lisp 的括号之痛——一个愚人节玩笑揭开的老伤疤 - 暗无天日 一本书该"线性读"还是"并行读" - 暗无天日 读 How to Monetize a Blog:一篇伪装成变现指南的讽刺文 Python Mock 第三方依赖的四种策略 - 暗无天日 Emacs Lisp 热重载实用指南 - 暗无天日 Prot 的 Emacs 配置哲学 - 暗无天日 TIL: 从直播对谈中学到的三个 Emacs 技巧 - 暗无天日 TIL: 自动使用项目虚拟环境的 Python - 暗无天日 TIL: 让 Help buffer 自动获得焦点 一条命令让本地开发用上 HTTPS —— slim 工具介绍 用 fsck 检查和修复 Linux 文件系统 排查Linux进程"卡死"实战:从strace到gdb全流程 - 暗无天日 PostgreSQL 索引:从基础到你可能不知道的高级用法 - 暗无天日 用 .pdbrc 自定义 Python 调试器 ANSI 转义码的标准化现状 - 暗无天日 终端程序的潜规则 - 暗无天日 PARA Org-mode 测试配置 - 暗无天日 AI越强越辣鸡?控制论说这是必然的 - 暗无天日 AI 越强越需要你盯着——反馈循环实操指南 - 暗无天日 你的AI代理正在偷你的密钥——四种你没想到的泄露通道 - 暗无天日 LLM 在 DevOps 中的三种角色 - 暗无天日 写作风格的反建议 - 暗无天日 反驳本质复杂性——Dan Luu 论为什么《没有银弹》错了 - 暗无天日 文件充满了危险——Dan Luu 谈文件系统的可靠性陷阱 - 暗无天日 AI 时代的 PARA 方法:用 Org-mode 和 AI 打造个人知识管理系统 Linux 数据去重学习笔记 - 暗无天日 创建跨平台 ZIP 文件的隐藏陷阱:Extra Field - 暗无天日 X11 Forwarding 排障指南 - 暗无天日 IP欺骗端口扫描:当别人冒充你去扫描别人 - 暗无天日 Linux 输入栈全景解析:从硬件按键到屏幕响应 - 暗无天日 Unix 系统中那些被埋没的配置开关——以 FontConfig 为例 - 暗无天日 在Linux上限制儿童使用电脑 - 暗无天日 GIF不仅仅是一种图片格式——用GIF流做些奇怪的事 - 暗无天日 Leiningen 学习笔记:Clojure 项目构建与管理从入门到实战配置 - 暗无天日 Google SRE Book 读书笔记 - 暗无天日 yes 管道 head 发生了什么 - 暗无天日 为什么 nohup 在 crontab 中不起作用 Bash中的Indirection与Nameref - 暗无天日 Linux PAM 简介 - 暗无天日 从Linux ISO文件启动计算机 - 暗无天日 用 Bash 打造一个Screen Locker 用GitHub Actions自动构建EGO博客 - 暗无天日 blocking I/O 的作用 - 暗无天日 mobileog 手机端同步提示Error:2 No such file 的解决方法 回收 WSL2 VHDX 文件占用空间 使用 org-mode columnview 生成任务列表 - 暗无天日 Emacs 作为 MPD 客户端 - 暗无天日 移动文件路径却不破坏org file link的方法 - 暗无天日 如何合理的导出help link 成HTML - 暗无天日 笑话理解之Biology - 暗无天日
Conducty:给 Claude Code 加上项目记忆和并行执行能力 - 暗无天日
2026-04-29 · via 暗无天日

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 PatternsMetricsPrompt 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!)在 上一篇博文 中有详细解读。