vault: auto-sync 2026-03-03 02:00
This commit is contained in:
lizikk
parent
e0ed580755
commit
48791f999a
5
.obsidian/community-plugins.json
vendored
Normal file
5
.obsidian/community-plugins.json
vendored
Normal file
@ -0,0 +1,5 @@
|
||||
[
|
||||
"note-to-mp",
|
||||
"obsidian-kanban",
|
||||
"dataview"
|
||||
]
|
||||
20876
.obsidian/plugins/dataview/main.js
vendored
Normal file
20876
.obsidian/plugins/dataview/main.js
vendored
Normal file
File diff suppressed because one or more lines are too long
11
.obsidian/plugins/dataview/manifest.json
vendored
Normal file
11
.obsidian/plugins/dataview/manifest.json
vendored
Normal file
@ -0,0 +1,11 @@
|
||||
{
|
||||
"id": "dataview",
|
||||
"name": "Dataview",
|
||||
"version": "0.5.68",
|
||||
"minAppVersion": "0.13.11",
|
||||
"description": "Complex data views for the data-obsessed.",
|
||||
"author": "Michael Brenan <blacksmithgu@gmail.com>",
|
||||
"authorUrl": "https://github.com/blacksmithgu",
|
||||
"helpUrl": "https://blacksmithgu.github.io/obsidian-dataview/",
|
||||
"isDesktopOnly": false
|
||||
}
|
||||
141
.obsidian/plugins/dataview/styles.css
vendored
Normal file
141
.obsidian/plugins/dataview/styles.css
vendored
Normal file
@ -0,0 +1,141 @@
|
||||
.block-language-dataview {
|
||||
overflow-y: auto;
|
||||
}
|
||||
|
||||
/*****************/
|
||||
/** Table Views **/
|
||||
/*****************/
|
||||
|
||||
/* List View Default Styling; rendered internally as a table. */
|
||||
.table-view-table {
|
||||
width: 100%;
|
||||
}
|
||||
|
||||
.table-view-table > thead > tr, .table-view-table > tbody > tr {
|
||||
margin-top: 1em;
|
||||
margin-bottom: 1em;
|
||||
text-align: left;
|
||||
}
|
||||
|
||||
.table-view-table > tbody > tr:hover {
|
||||
background-color: var(--table-row-background-hover);
|
||||
}
|
||||
|
||||
.table-view-table > thead > tr > th {
|
||||
font-weight: 700;
|
||||
font-size: larger;
|
||||
border-top: none;
|
||||
border-left: none;
|
||||
border-right: none;
|
||||
border-bottom: solid;
|
||||
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
.table-view-table > tbody > tr > td {
|
||||
text-align: left;
|
||||
border: none;
|
||||
font-weight: 400;
|
||||
max-width: 100%;
|
||||
}
|
||||
|
||||
.table-view-table ul, .table-view-table ol {
|
||||
margin-block-start: 0.2em !important;
|
||||
margin-block-end: 0.2em !important;
|
||||
}
|
||||
|
||||
/** Rendered value styling for any view. */
|
||||
.dataview-result-list-root-ul {
|
||||
padding: 0em !important;
|
||||
margin: 0em !important;
|
||||
}
|
||||
|
||||
.dataview-result-list-ul {
|
||||
margin-block-start: 0.2em !important;
|
||||
margin-block-end: 0.2em !important;
|
||||
}
|
||||
|
||||
/** Generic grouping styling. */
|
||||
.dataview.result-group {
|
||||
padding-left: 8px;
|
||||
}
|
||||
|
||||
/*******************/
|
||||
/** Inline Fields **/
|
||||
/*******************/
|
||||
|
||||
.dataview.inline-field-key {
|
||||
padding-left: 8px;
|
||||
padding-right: 8px;
|
||||
font-family: var(--font-monospace);
|
||||
background-color: var(--background-primary-alt);
|
||||
color: var(--nav-item-color-selected);
|
||||
}
|
||||
|
||||
.dataview.inline-field-value {
|
||||
padding-left: 8px;
|
||||
padding-right: 8px;
|
||||
font-family: var(--font-monospace);
|
||||
background-color: var(--background-secondary-alt);
|
||||
color: var(--nav-item-color-selected);
|
||||
}
|
||||
|
||||
.dataview.inline-field-standalone-value {
|
||||
padding-left: 8px;
|
||||
padding-right: 8px;
|
||||
font-family: var(--font-monospace);
|
||||
background-color: var(--background-secondary-alt);
|
||||
color: var(--nav-item-color-selected);
|
||||
}
|
||||
|
||||
/***************/
|
||||
/** Task View **/
|
||||
/***************/
|
||||
|
||||
.dataview.task-list-item, .dataview.task-list-basic-item {
|
||||
margin-top: 3px;
|
||||
margin-bottom: 3px;
|
||||
transition: 0.4s;
|
||||
}
|
||||
|
||||
.dataview.task-list-item:hover, .dataview.task-list-basic-item:hover {
|
||||
background-color: var(--text-selection);
|
||||
box-shadow: -40px 0 0 var(--text-selection);
|
||||
cursor: pointer;
|
||||
}
|
||||
|
||||
/*****************/
|
||||
/** Error Views **/
|
||||
/*****************/
|
||||
|
||||
div.dataview-error-box {
|
||||
width: 100%;
|
||||
min-height: 150px;
|
||||
display: flex;
|
||||
align-items: center;
|
||||
justify-content: center;
|
||||
border: 4px dashed var(--background-secondary);
|
||||
}
|
||||
|
||||
.dataview-error-message {
|
||||
color: var(--text-muted);
|
||||
text-align: center;
|
||||
}
|
||||
|
||||
/*************************/
|
||||
/** Additional Metadata **/
|
||||
/*************************/
|
||||
|
||||
.dataview.small-text {
|
||||
font-size: smaller;
|
||||
color: var(--text-muted);
|
||||
margin-left: 3px;
|
||||
}
|
||||
|
||||
.dataview.small-text::before {
|
||||
content: "(";
|
||||
}
|
||||
|
||||
.dataview.small-text::after {
|
||||
content: ")";
|
||||
}
|
||||
108631
.obsidian/plugins/note-to-mp/main.js
vendored
Normal file
108631
.obsidian/plugins/note-to-mp/main.js
vendored
Normal file
File diff suppressed because one or more lines are too long
10
.obsidian/plugins/note-to-mp/manifest.json
vendored
Normal file
10
.obsidian/plugins/note-to-mp/manifest.json
vendored
Normal file
@ -0,0 +1,10 @@
|
||||
{
|
||||
"id": "note-to-mp",
|
||||
"name": "NoteToMP",
|
||||
"version": "2.0.0",
|
||||
"minAppVersion": "1.4.5",
|
||||
"description": "Send notes to WeChat MP drafts, or copy notes to WeChat MP editor, perfect preservation of note styles, support code highlighting, line numbers in code, and support local image uploads.",
|
||||
"author": "Sun Booshi",
|
||||
"authorUrl": "https://sunboshi.tech",
|
||||
"isDesktopOnly": false
|
||||
}
|
||||
1005
.obsidian/plugins/note-to-mp/styles.css
vendored
Normal file
1005
.obsidian/plugins/note-to-mp/styles.css
vendored
Normal file
File diff suppressed because it is too large
Load Diff
151
.obsidian/plugins/obsidian-kanban/main.js
vendored
Normal file
151
.obsidian/plugins/obsidian-kanban/main.js
vendored
Normal file
File diff suppressed because one or more lines are too long
11
.obsidian/plugins/obsidian-kanban/manifest.json
vendored
Normal file
11
.obsidian/plugins/obsidian-kanban/manifest.json
vendored
Normal file
@ -0,0 +1,11 @@
|
||||
{
|
||||
"id": "obsidian-kanban",
|
||||
"name": "Kanban",
|
||||
"version": "2.0.51",
|
||||
"minAppVersion": "1.0.0",
|
||||
"description": "Create markdown-backed Kanban boards in Obsidian.",
|
||||
"author": "mgmeyers",
|
||||
"authorUrl": "https://github.com/mgmeyers/obsidian-kanban",
|
||||
"helpUrl": "https://publish.obsidian.md/kanban/Obsidian+Kanban+Plugin",
|
||||
"isDesktopOnly": false
|
||||
}
|
||||
1
.obsidian/plugins/obsidian-kanban/styles.css
vendored
Normal file
1
.obsidian/plugins/obsidian-kanban/styles.css
vendored
Normal file
File diff suppressed because one or more lines are too long
10
.obsidian/types.json
vendored
Normal file
10
.obsidian/types.json
vendored
Normal file
@ -0,0 +1,10 @@
|
||||
{
|
||||
"types": {
|
||||
"aliases": "aliases",
|
||||
"cssclasses": "multitext",
|
||||
"tags": "tags",
|
||||
"source_urls": "multitext",
|
||||
"assets": "multitext",
|
||||
"channels": "multitext"
|
||||
}
|
||||
}
|
||||
302
00-inbox/2026-03-02-ai-collaboration-prompts-analysis.md
Normal file
302
00-inbox/2026-03-02-ai-collaboration-prompts-analysis.md
Normal file
@ -0,0 +1,302 @@
|
||||
---
|
||||
title: AI协作提示词模板 - 道-法-术-器体系分析
|
||||
slug: ai-collaboration-prompts-analysis
|
||||
status: inbox
|
||||
content_type: analysis
|
||||
created_at: "2026-03-02T21:50:00+08:00"
|
||||
updated_at: "2026-03-02T21:50:00+08:00"
|
||||
source_note: "[[2026-03-02-ai-collaboration-prompts]]"
|
||||
---
|
||||
|
||||
# AI协作提示词模板 - 道-法-术-器体系分析
|
||||
|
||||
分析对象：协作式内容创作提示词 + Vibe Coding 提示词
|
||||
分析框架：道-法-术-器 体系架构
|
||||
分析日期：2026-03-02
|
||||
|
||||
---
|
||||
|
||||
## 证据层 E#（先提取后推导）
|
||||
|
||||
| ID | 原句/要点 | 类型 | 可信度 |
|
||||
|----|----------|------|--------|
|
||||
| E1 | "DO NOT start executing yet. Instead, ask me clarifying questions" | 规则 | 高—明确行为指令 |
|
||||
| E2 | "Before you write anything, list the 3 rules from my context file that matter most" | 规则 | 高—强制前置步骤 |
|
||||
| E3 | "Only begin work once we've aligned" | 规则 | 高—对齐是执行前提 |
|
||||
| E4 | "You are now my Technical co-founder... keep me in the loop and in control" | 角色定义 | 高—身份锚定 |
|
||||
| E5 | "Treat me as your product owner. I make the decisions, you make them happen" | 权责划分 | 高—决策权归属 |
|
||||
| E6 | "Challenge my assumptions if something doesn't make sense" | 规则 | 高—鼓励反向压力 |
|
||||
| E7 | "Push back if I'm overcomplicating or going down a bad path" | 规则 | 高—AI有否决权 |
|
||||
| E8 | "Build in stages I can see and react to" | 规则 | 高—渐进披露 |
|
||||
| E9 | "Stop and check in at key decision points" | 规则 | 高—节点控制 |
|
||||
| E10 | "If you hit a problem, tell me the options instead of just picking one" | 规则 | 高—选择权保留 |
|
||||
| E11 | "Be honest about limitations. I'd rather adjust expectations than be disappointed" | 价值观 | 高—透明优先 |
|
||||
| E12 | "This is real. This is not a mockup. It's a prototype. A working product" | 目标定义 | 高—产出标准 |
|
||||
| E13 | "Document everything so I'm not dependent on this conversation" | 规则 | 高—可独立性 |
|
||||
| E14 | Success Brief 包含：Type/Reaction/Does NOT sound like/Success means | 框架 | 高—结构化对齐 |
|
||||
| E15 | "My context file contains my standards, constraints, landmines, and audience" | 前提 | 中—假设用户有context file |
|
||||
|
||||
---
|
||||
|
||||
# L0 无极：信息边界与缺口
|
||||
|
||||
## 1) 主题范围
|
||||
|
||||
**覆盖**：人机协作的提示词设计模式——如何让AI成为可控、可预期、可迭代的协作伙伴
|
||||
|
||||
**不覆盖**：具体技术实现细节、特定领域（编程/写作）的专项技巧、多Agent协作
|
||||
|
||||
## 2) 缺口清单（追问）
|
||||
|
||||
- G1：这两个模板的实际使用效果数据（成功率、返工率、用户满意度）
|
||||
- G2：用户"context file"的标准结构是什么？如何维护？
|
||||
- G3：当AI"push back"时，用户如何判断AI是对的还是在过度保守？
|
||||
|
||||
## 3) 风险提示
|
||||
|
||||
- R1：样本偏倚——这些模板来自成功案例，可能有幸存者偏差
|
||||
- R2：语境依赖——高度依赖用户有能力编写清晰的context file和Success Brief
|
||||
- R3：AI依赖——模板假设AI有足够推理能力执行复杂多阶段任务
|
||||
|
||||
---
|
||||
|
||||
# L1 太极：第一性矛盾
|
||||
|
||||
**核心矛盾**：**控制感 ↔ 放手信任**
|
||||
|
||||
- A端：用户想保持决策权、知情权、可控性
|
||||
- B端：AI需要足够自主空间才能高效产出
|
||||
|
||||
**目标方向**：**倾向A（控制感）**
|
||||
|
||||
> 理由：两个模板的共同底色是"宁可慢也要可控"。E1/E2/E3/E5/E9/E10 都在强化"用户决策权优先于AI效率"。Vibe Coding明确说"keep me in the loop and in control"，而非"let me know when you're done"。
|
||||
|
||||
---
|
||||
|
||||
# L2 一：道（Why）— 目的/价值/取舍
|
||||
|
||||
| ID | 道-命题 | 取舍结构 | 证据 |
|
||||
|----|--------|----------|------|
|
||||
| D1 | **对齐先于执行** | 宁可多问3个问题，也要避免方向错误后返工 | E1, E2, E3 |
|
||||
| D2 | **用户保有最终决策权** | 优先用户选择而非AI效率 | E5, E10 |
|
||||
| D3 | **透明度优先于愉悦感** | 宁可被告知"做不了"，也不要被虚假承诺 | E7, E11 |
|
||||
| D4 | **渐进披露优于一次性交付** | 优先分阶段可见而非黑箱产出 | E8, E9 |
|
||||
| D5 | **可独立性优于对话依赖** | 宁可多花时间文档化，也要让用户能脱离此对话 | E13 |
|
||||
|
||||
---
|
||||
|
||||
# L3 二：法（What）— 世界模型/因果假设
|
||||
|
||||
| ID | 模型/因果命题 | 关键变量 | 因果方向 | 证据 | 可证伪信号 |
|
||||
|----|--------------|----------|----------|------|-----------|
|
||||
| M1 | **对齐成本曲线**：前期对齐投入越高，后期返工成本越低 | 对齐投入、返工成本 | 对齐↑ → 返工↓（在复杂任务下） | E1, E2, E3 | 若简单任务也强制对齐，效率反而下降 |
|
||||
| M2 | **AI角色锚定效应**：给AI明确角色身份→行为更一致 | 角色定义、行为一致性 | 角色明确 → 行为一致 | E4 | 若角色模糊，AI行为漂移 |
|
||||
| M3 | **选择权保留律**：AI只提供选项不替用户决策→用户满意度↑ | 决策归属、满意度 | AI不决策 → 满意度↑ | E5, E10 | 若AI常替用户决策，用户会感到失控 |
|
||||
| M4 | **反向压力价值**：AI敢于挑战用户假设→决策质量↑ | AI挑战行为、决策质量 | 挑战↑ → 质量↑（在用户开放心态下） | E6, E7 | 若用户防御心强，挑战会引发冲突 |
|
||||
| M5 | **阶段性可见性**：分阶段产出→用户掌控感↑→信任↑ | 可见频率、信任度 | 可见↑ → 信任↑ | E8, E9 | 若阶段过于细碎，用户会感到被打扰 |
|
||||
|
||||
---
|
||||
|
||||
# L4 四：术（How）— 原则/策略
|
||||
|
||||
| ID | 原则/启发式 | 前提 | 边界 | 映射 | 证据 |
|
||||
|----|------------|------|------|------|------|
|
||||
| P1 | **如果任务复杂度>简单，就必须先对齐再执行** | 用户能表达清楚需求 | 紧急情况/简单查询 | D1, M1 | E1, E2, E3 |
|
||||
| P2 | **如果AI要执行关键操作，就必须先告知选项让用户选择** | 操作有不可逆性 | 低风险操作可豁免 | D2, M3 | E5, E10 |
|
||||
| P3 | **如果发现用户假设有问题，就必须提出质疑而非顺从** | AI有足够信息判断 | 用户明确说"照我说的做" | D3, M4 | E6, E7 |
|
||||
| P4 | **如果产出物有多个阶段，就必须在关键节点check-in** | 任务可分阶段 | 阶段划分本身需要用户确认 | D4, M5 | E8, E9 |
|
||||
| P5 | **如果AI无法完成某事，就必须诚实告知而非模糊承诺** | AI知道自己的边界 | 用户需要被告知替代方案 | D3 | E11 |
|
||||
| P6 | **如果协作结束，就必须交付可独立使用的文档** | 产出物有价值 | 探索性对话可豁免 | D5 | E13 |
|
||||
| P7 | **优先Success Brief式结构化需求，而非自由文本描述** | 用户能填写模板 | 创意发散阶段可豁免 | D1, M1 | E14 |
|
||||
| P8 | **优先Role锚定（"你是我的..."），而非无角色开场** | 角色与任务相关 | 角色不应过度限制AI能力 | D2, M2 | E4 |
|
||||
| P9 | **优先展示推理过程，而非只给结论** | 用户想学习/掌控 | 用户说"只要结果"时豁免 | D4 | E8 |
|
||||
|
||||
---
|
||||
|
||||
# L5 八：器（Do）— 动作/工具/流程
|
||||
|
||||
## T1：Success Brief 模板
|
||||
|
||||
**触发场景**：任何需要AI产出的任务开始前
|
||||
**目标**：5分钟内完成对齐
|
||||
|
||||
| 字段 | 填写指引 |
|
||||
|------|----------|
|
||||
| Type of output + length | 交付物类型 + 规模 |
|
||||
| Recipient's reaction | 读者看完后应该想/感觉/做什么 |
|
||||
| Does NOT sound like | 避免什么风格 |
|
||||
| Success means | 什么算成功 |
|
||||
|
||||
**常见误用**：填得太模糊（如"写得好"）→ 纠偏：必须具体到可观测
|
||||
|
||||
**映射**：P1, P7
|
||||
|
||||
---
|
||||
|
||||
## T2：Context File 结构
|
||||
|
||||
**触发场景**：首次与AI协作时创建，持续维护
|
||||
**目标**：让AI知道你的长期约束
|
||||
|
||||
```markdown
|
||||
## 我的约束
|
||||
- 绝对不能做的事
|
||||
- 必须遵守的规则
|
||||
|
||||
## 我的偏好
|
||||
- 风格偏好
|
||||
- 工具偏好
|
||||
|
||||
## 我的受众
|
||||
- 他们是谁
|
||||
- 他们关心什么
|
||||
|
||||
## 我的雷区
|
||||
- 曾踩过的坑
|
||||
- 一听就烦的词
|
||||
```
|
||||
|
||||
**常见误用**：写得太长没人看 → 纠偏：控制在1页内，用bullet points
|
||||
|
||||
**映射**：P1, E15
|
||||
|
||||
---
|
||||
|
||||
## T3：Role 锚定开场白
|
||||
|
||||
**触发场景**：开启新协作会话时
|
||||
**目标**：3秒内建立角色预期
|
||||
|
||||
```
|
||||
你是我的[角色]，你的任务是[任务边界]。
|
||||
我会负责[用户职责]，你负责[AI职责]。
|
||||
如果我[某种行为]，你要[AI响应方式]。
|
||||
```
|
||||
|
||||
**示例**：
|
||||
> 你是我的技术合伙人。我会做产品决策，你负责技术实现。如果我过度复杂化，你要push back。
|
||||
|
||||
**常见误用**：角色定义太宽泛 → 纠偏：具体到可识别的行为
|
||||
|
||||
**映射**：P8, E4
|
||||
|
||||
---
|
||||
|
||||
## T4：阶段性Check-in协议
|
||||
|
||||
**触发场景**：复杂任务执行中
|
||||
**目标**：保持用户掌控感
|
||||
|
||||
**步骤**：
|
||||
1. 开始前：列出将要做的事（≤5步）
|
||||
2. 每完成1步：汇报结果 + 下一歩计划
|
||||
3. 遇到分叉：列出选项 + 推荐 + 理由，等用户选择
|
||||
|
||||
**话术**：
|
||||
> "我刚完成了X。接下来要做Y。在进入Y之前，有个选择：A方案更快但...，B方案更稳但...。我推荐A，你觉得呢？"
|
||||
|
||||
**常见误用**：check-in太频繁打断心流 → 纠偏：只在"可逆性低"的节点check-in
|
||||
|
||||
**映射**：P4, E8, E9
|
||||
|
||||
---
|
||||
|
||||
## T5：问题暴露协议
|
||||
|
||||
**触发场景**：AI遇到困难/不确定时
|
||||
**目标**：透明而非掩盖
|
||||
|
||||
**步骤**：
|
||||
1. 描述问题（不解决）
|
||||
2. 列出可能选项（≥2个）
|
||||
3. 每个选项的利弊
|
||||
4. AI的推荐 + 理由
|
||||
5. 等用户决策
|
||||
|
||||
**话术**：
|
||||
> "遇到了一个问题：...。有三个选项：A会...但...；B会...但...；C会...但...。我倾向B，因为...。你怎么看？"
|
||||
|
||||
**常见误用**：只给一个选项 → 纠偏：强制≥2个选项
|
||||
|
||||
**映射**：P2, P5, E10
|
||||
|
||||
---
|
||||
|
||||
## T6：协作收尾检查清单
|
||||
|
||||
**触发场景**：任务完成时
|
||||
**目标**：确保可独立性
|
||||
|
||||
**检查项**：
|
||||
- [ ] 产出物可直接使用/部署
|
||||
- [ ] 有使用说明
|
||||
- [ ] 有修改指引（如果想改某个部分怎么办）
|
||||
- [ ] 有后续建议（v2可以加什么）
|
||||
|
||||
**常见误用**：忘记交付文档 → 纠偏：收尾前强制过清单
|
||||
|
||||
**映射**：P6, E13
|
||||
|
||||
---
|
||||
|
||||
# L6 加速度→速度→位移：指标与反馈
|
||||
|
||||
| 类型 | 指标 | 如何记录 | 周期 | 阈值 | 对应工具 |
|
||||
|------|------|----------|------|------|----------|
|
||||
| **加速度 A** | A1: 返工率变化 | 返工次数/总任务数 | 每周 | 下降>10%为有效 | T1, T2 |
|
||||
| | A2: 对齐质量提升率 | 首次产出即满意的任务比例 | 每周 | 上升>15%为有效 | T1 |
|
||||
| **速度 V** | V1: Check-in频率 | 关键节点check-in次数 | 每任务 | 适中（不过多不过少） | T4 |
|
||||
| | V2: 问题暴露次数 | 主动暴露问题而非掩盖的次数 | 每任务 | >0为健康 | T5 |
|
||||
| **位移 S** | S1: 任务完成满意度 | 1-10分自评 | 每任务 | ≥7分为达标 | 全部 |
|
||||
| | S2: 可独立使用率 | 交付后无需再问AI的比例 | 每任务 | ≥80%为达标 | T6 |
|
||||
|
||||
---
|
||||
|
||||
# L7 生生不息：迭代律
|
||||
|
||||
## 1) 复盘模板（5问）
|
||||
|
||||
```
|
||||
1. 这次协作中，AI是否在执行前充分对齐了？（Y/N，证据）
|
||||
2. AI是否有在关键节点check-in而非自作主张？（Y/N，证据）
|
||||
3. AI是否有主动暴露问题而非掩盖？（Y/N，证据）
|
||||
4. 最终产出是否可独立使用？（Y/N，缺什么）
|
||||
5. 下次我会调整哪个提示词/规则？
|
||||
```
|
||||
|
||||
## 2) 更新规则
|
||||
|
||||
| 信号 | 动作 | 指向 |
|
||||
|------|------|------|
|
||||
| 返工率>30% | 增强T1 Success Brief的字段 | T1 |
|
||||
| AI多次自作主张 | 增加P4 check-in频率要求 | P4, T4 |
|
||||
| AI从不push back | 强化P3，在Role锚定中加入"你要挑战我" | P3, T3 |
|
||||
| 产出无法独立使用 | 强制T6为收尾必过清单 | T6 |
|
||||
| 对齐时间过长 | 简化T1模板，减少必填字段 | T1 |
|
||||
|
||||
## 3) 7天最小实验
|
||||
|
||||
**做什么**：
|
||||
- 选1个中等复杂度任务
|
||||
- 使用T1 Success Brief + T3 Role锚定开场
|
||||
- 执行中用T4 Check-in协议
|
||||
- 结束用T6收尾清单
|
||||
|
||||
**记录什么**：
|
||||
- 对齐耗时
|
||||
- Check-in次数
|
||||
- 返工次数
|
||||
- 最终满意度(1-10)
|
||||
|
||||
**判定有效**：
|
||||
- 对齐耗时 < 总耗时30%
|
||||
- 返工次数 ≤1
|
||||
- 满意度 ≥7
|
||||
|
||||
---
|
||||
|
||||
## 最终收束
|
||||
|
||||
> **在需要AI协作产出的场景，优先对齐与控制感，而非效率与速度。**
|
||||
|
||||
**映射**：D1 + D2 + M1 + P1
|
||||
123
00-inbox/2026-03-02-ai-collaboration-prompts.md
Normal file
123
00-inbox/2026-03-02-ai-collaboration-prompts.md
Normal file
@ -0,0 +1,123 @@
|
||||
---
|
||||
title: AI协作提示词模板合集
|
||||
slug: ai-collaboration-prompts
|
||||
status: inbox
|
||||
content_type: reference
|
||||
created_at: "2026-03-02T21:50:00+08:00"
|
||||
updated_at: "2026-03-02T21:50:00+08:00"
|
||||
---
|
||||
|
||||
# AI协作提示词模板合集
|
||||
|
||||
来源：截图提取，2026-03-02
|
||||
|
||||
---
|
||||
|
||||
## 模板一：协作式内容创作提示词
|
||||
|
||||
### Here is a reference to what I want to achieve:
|
||||
|
||||
```
|
||||
[Upload reference file as markdown, or paste it here]
|
||||
```
|
||||
|
||||
### What makes this reference work?
|
||||
|
||||
```
|
||||
[Paste your reverse-engineered blueprint - the patterns, tone, structure, and rules you extracted from the reference. Format each one as a rule starting with "Always" or "Never."]
|
||||
```
|
||||
|
||||
### Here's what I need for my version:
|
||||
|
||||
#### SUCCESS BRIEF
|
||||
|
||||
| 字段 | 说明 |
|
||||
|------|------|
|
||||
| **Type of output + length:** | `{Contract, memo, report, proposal, landing page, post?}` |
|
||||
| **Recipient's reaction:** | `{What should they think/feel/do after reading?}` |
|
||||
| **Does NOT sound like:** | `{What to avoid - generic AI, too casual, formal, jargon-heavy?}` |
|
||||
| **Success means:** | `{They sign? They approve? They reply? They take action?}` |
|
||||
|
||||
---
|
||||
|
||||
### Context File 声明
|
||||
|
||||
> My context file contains my standards, constraints, landmines, and audience. Read it fully before starting. If you're about to break one of my rules, stop and tell me.
|
||||
|
||||
### 执行前协议
|
||||
|
||||
> **DO NOT start executing yet.** Instead, ask me clarifying questions (use 'UserQuestion' tool) so we can refine the approach together step by step.
|
||||
|
||||
### 执行前检查
|
||||
|
||||
1. List the 3 rules from my context file that matter most for this task
|
||||
2. Then give me your execution plan (5 steps maximum)
|
||||
3. Only begin work once we've aligned
|
||||
|
||||
---
|
||||
|
||||
## 模板二：Vibe Coding 提示词（技术合伙人模式）
|
||||
|
||||
### Title
|
||||
|
||||
You are now my Technical co-founder. Your job is to help me build a real product I can use, share, or launch. I'll handle the building, but keep me in the loop and in control.
|
||||
|
||||
### My Ideas
|
||||
|
||||
Describe your product idea - what it does, who it's for, what problem it solves. Explain it like I'm your friend.
|
||||
|
||||
### How serious am I
|
||||
|
||||
I'm just exploring / I want to use this myself / I want to share it with others / I want to launch it publicly!
|
||||
|
||||
### Project Framework
|
||||
|
||||
#### 1. Phase 1: Discovery
|
||||
|
||||
- Ask questions to understand what I actually need (not just what I said)
|
||||
- Challenge my assumptions if something doesn't make sense
|
||||
- Tell me if my "must have" ideas are too big and suggest a leaner starting point
|
||||
|
||||
#### 2. Phase 2: Planning
|
||||
|
||||
- Propose exactly what we'll build in version 1
|
||||
- Explain the technology and approach in plain language
|
||||
- Estimate complexity (simple, medium, ambitious)
|
||||
- Identify anything I'll need to buy (accounts, services, decisions)
|
||||
- Show a rough outline of the finished product
|
||||
|
||||
#### 3. Phase 3: Building
|
||||
|
||||
- Build in stages I can see and react to
|
||||
- Explain what you're doing so I can learn (if I want to learn)
|
||||
- Stop and check in at key decision points
|
||||
- Test everything before moving on
|
||||
- If you hit a problem, tell me the options instead of just picking one
|
||||
|
||||
#### 4. Phase 4: Polish
|
||||
|
||||
- Make it look professional, not like a hackathon project
|
||||
- Handle edge cases and errors gracefully
|
||||
- Make sure it's fast and works on different devices if relevant
|
||||
- Add small details that make it feel "finished"
|
||||
|
||||
#### 5. Phase 5: Handoff
|
||||
|
||||
- Deploy it if I want it online
|
||||
- Give clear instructions for how to use it, maintain it, and make changes
|
||||
- Document everything so I'm not dependent on this conversation
|
||||
- Tell me what I could add or improve in version 2
|
||||
|
||||
#### 6. How to Work with Me
|
||||
|
||||
- Treat me as your product owner. I make the decisions, you make them happen.
|
||||
- Don't overwhelm me with technical jargon. Translate everything.
|
||||
- Push back if I'm overcomplicating or going down a bad path.
|
||||
- Be honest about limitations. I'd rather adjust expectations than be disappointed.
|
||||
- Move fast, but not so fast that I can't follow what's happening.
|
||||
|
||||
### Rules
|
||||
|
||||
- I don't just want to work - I want it to be something I'm proud to show people
|
||||
- This is real. This is not a mockup. It's a prototype. A working product.
|
||||
- Keep me in control and in the loop at all times
|
||||
38
00-inbox/2026-03-02-claude-code-overnight-work.md
Normal file
38
00-inbox/2026-03-02-claude-code-overnight-work.md
Normal file
@ -0,0 +1,38 @@
|
||||
---
|
||||
title: 让 Claude Code 在睡觉时持续干活的方式
|
||||
slug: claude-code-overnight-work
|
||||
status: inbox
|
||||
source_urls:
|
||||
- https://x.com/BadUncleX/status/2028127961036226675
|
||||
author: BadUncle (@BadUncleX)
|
||||
created_at: 2026-03-02T00:00:00+08:00
|
||||
updated_at: 2026-03-02T00:00:00+08:00
|
||||
tags:
|
||||
- claude-code
|
||||
- autonomous-coding
|
||||
- worktree
|
||||
- concurrency
|
||||
---
|
||||
|
||||
# 让 Claude Code 在睡觉时持续干活的方式
|
||||
|
||||
> 来源：BadUncle (@BadUncleX) · 2026-03-01 · 4.3K views · 39 bookmarks
|
||||
> https://x.com/BadUncleX/status/2028127961036226675
|
||||
|
||||
---
|
||||
|
||||
这个帖子收集一下让claude code 在我睡觉的时候的持续干活方式。
|
||||
|
||||
过去很长时间我确实是以每次不超过2个并行的方式来coding，主要是再多的并排窗口， 我大脑切换不过来，哪怕技术上允许， 所以，太多的并发可能解决不了我的问题。
|
||||
|
||||
不过我最近确实积累了不少需要做的东西，因此并发数量有可能的话会适当加几个， 但是不会太多。
|
||||
|
||||
但是，睡觉后让ai继续自动干活， 是一个我想探索的方向。 后续更新放thread comment里。
|
||||
|
||||
目前大家聊到的一些机制：
|
||||
- worktree 是一个基础设施
|
||||
- planning with files 是一个不错的机制
|
||||
- cc teams? 还没有测试， 只知道并发可以， 不确定长时间干活究竟如何
|
||||
- openfang？ 也没有测试， 类似龙虾的模式， 我还没有习惯作为coding的主要方式， 但是如果技术上有其他优势，也可以考虑。
|
||||
|
||||
欢迎推荐你的方法
|
||||
77
00-inbox/2026-03-02-cli-is-all-you-need.md
Normal file
77
00-inbox/2026-03-02-cli-is-all-you-need.md
Normal file
@ -0,0 +1,77 @@
|
||||
---
|
||||
title: CLI Is All You Need
|
||||
slug: cli-is-all-you-need
|
||||
status: inbox
|
||||
source_urls:
|
||||
- https://x.com/mfranz_on/status/2021364017147818434
|
||||
author: Marco Franzon (@mfranz_on)
|
||||
created_at: 2026-03-02T00:00:00+08:00
|
||||
updated_at: 2026-03-02T00:00:00+08:00
|
||||
tags:
|
||||
- cli
|
||||
- mcp
|
||||
- agentic-coding
|
||||
- developer-tools
|
||||
---
|
||||
|
||||
# CLI Is All You Need
|
||||
|
||||
> 来源：Marco Franzon (@mfranz_on) · 2026-02-10 · 211K views · 1235 bookmarks
|
||||
> https://x.com/mfranz_on/status/2021364017147818434
|
||||
|
||||
## 核心论点
|
||||
|
||||
MCP（Model Context Protocol）对 80–90% 的日常开发工作流来说是过度工程。2026 年交付最快的开发者回到了起点——终端。给 Agent 直接 shell 访问权限，让它们用几十年来已经存在的工具：git、rg、grep、npm、docker、curl、jq、tail。
|
||||
|
||||
> "Stop building integrations. Build CLIs."
|
||||
> "Bash is the ultimate MCP."
|
||||
> "Agents were trained on Unix pipes—they're ridiculously good at it."
|
||||
> "CLI is all you need. Everything else is ceremony."
|
||||
|
||||
## MCP 失去光环的四个原因
|
||||
|
||||
1. **Token overhead**：冗长的 tool catalog 和 schema 消耗宝贵的 context window
|
||||
2. **Reinventing the wheel**：自定义 MCP server 往往在重复官方 CLI 已经做得更好的事
|
||||
3. **Poor composability**：失去了 Unix 管道、链式调用和 one-off hack 的天然组合能力
|
||||
4. **Model alignment**：前沿模型（Claude、GPT、Gemini）在 shell 用法上有大量训练数据，对 flags、pipes、errors、man-page 风格文档理解极好
|
||||
|
||||
## CLI-Native 编码 Agent 排名
|
||||
|
||||
| Agent | 亮点 |
|
||||
|---|---|
|
||||
| **Claude Code (Anthropic)** | 深度推理领先者，适合大型/复杂代码库、架构讨论、谨慎重构、多文件变更。原生终端工作流 + git 集成 |
|
||||
| **Codex CLI (OpenAI)** | 轻量快速，适合生成、测试、快速迭代。开源可本地运行 |
|
||||
| **Gemini CLI (Google)** | 免费层 + 强多模态，擅长快速原型、UI 任务、大项目。ReAct 风格循环，开源隐私友好 |
|
||||
| **OpenCode** | 75+ provider 灵活切换，LSP 集成，隐私优先。社区称其为当前最高效终端 Agent |
|
||||
|
||||
## 四个实战场景
|
||||
|
||||
### 1. Monorepo 级重构
|
||||
Agent 起手 `rg "oldDeprecatedFunction" .`，规划跨文件编辑，应用变更，`git diff` 审查，跑测试，提交。无需 GitHub MCP，只要 rg + git + test runner。
|
||||
|
||||
### 2. 全栈线上 Bug 调试
|
||||
指令："Reproduce the auth failure in staging."
|
||||
Agent 执行 `git pull → npm install → npm run dev → tail -f logs → curl -v api/auth/check → docker-compose up → npm test`，迭代编辑文件、重跑测试、探测端点。无需 Docker MCP 或 Logging MCP。
|
||||
|
||||
### 3. 新微服务脚手架
|
||||
指令："Build a Rust API for user profiles with Postgres using Axum + sqlx."
|
||||
Agent 执行 `cargo new → cargo add → cargo watch → curl health`，边开发边提交。无需 Rust MCP 或 Database MCP。
|
||||
|
||||
### 4. CI/CD Flake 修复
|
||||
Agent clone 仓库，用 `act` 本地跑 workflow，定位失败，编辑 `.github/workflows/ci.yml` 或 Dockerfile，`docker build` 验证，推分支，`gh` 开 PR。全部标准 CLI 工具。
|
||||
|
||||
## 团队反馈趋势
|
||||
|
||||
采用 CLI-native agent 的团队一致报告：
|
||||
- 更高的交付速度
|
||||
- 更少的 token 意外开销
|
||||
- 更透明的 Agent 行为
|
||||
- 更容易调试 Agent 在做什么
|
||||
|
||||
## MCP 仍有价值的场景
|
||||
|
||||
高度结构化的企业集成——类型安全的 SaaS API、受监管环境。但这只覆盖 10–20% 的场景。
|
||||
|
||||
## 结论
|
||||
|
||||
终端一直是通用开发环境。2026 年，它也是 AI 编码 Agent 最强大的接口。除非你深陷私有企业工具链，否则跳过沉重的 MCP 栈：cd 进项目、启动 CLI agent、给 shell 权限、描述任务、看它工作。
|
||||
130
00-inbox/2026-03-02-dao-method-technique-tool-framework.md
Normal file
130
00-inbox/2026-03-02-dao-method-technique-tool-framework.md
Normal file
@ -0,0 +1,130 @@
|
||||
---
|
||||
title: 道-法-术-器 体系分析框架
|
||||
slug: dao-method-technique-tool-framework
|
||||
status: inbox
|
||||
content_type: framework
|
||||
created_at: "2026-03-02T22:00:00+08:00"
|
||||
updated_at: "2026-03-02T22:00:00+08:00"
|
||||
---
|
||||
|
||||
# 道-法-术-器 体系架构师 + 洞察提炼师 + 经验进化设计师
|
||||
|
||||
你是一位"道-法-术-器 体系架构师 + 洞察提炼师 + 经验进化设计师"。
|
||||
你的工作方式必须**由高维到低维逐层披露**：先定"为何/是什么"，再定"怎么做/用什么量化"，最后形成"可迭代系统"。
|
||||
同时保持**正交**：每一层只回答自己的问题，不跨层混写；若不可避免跨层，必须拆分为多条分别归层。
|
||||
|
||||
---
|
||||
|
||||
## 输入
|
||||
【信息】（原文/要点/转写）
|
||||
【使用场景】（可选）
|
||||
【偏好语汇】修行/中性工程化（可选）
|
||||
|
||||
---
|
||||
|
||||
## 输出总规则（先读后写）
|
||||
- **披露顺序不可跳层**：L0 → L1 → L2 → L3 → L4 → L5 → L6 → L7
|
||||
- **归层判别**：一条内容若同时回答两个层的问题，必须拆分
|
||||
- **每条洞察要可落地可证伪**：必须有证据、前提、边界、可观测信号
|
||||
- **层间映射**：每个低层产物必须标注来自哪些高层结论（ID引用）
|
||||
|
||||
---
|
||||
|
||||
# L0 无极：信息边界与缺口（不立论，只定范围）
|
||||
1) 主题范围一句话（你将覆盖什么、不覆盖什么）
|
||||
2) 缺口清单：若要推到"可执行经验"，还缺哪些信息（≤3条追问）
|
||||
3) 风险提示：这份信息可能有哪些偏见/立场/样本局限（≤3条）
|
||||
|
||||
---
|
||||
|
||||
# L1 太极：第一性矛盾（统一场）
|
||||
回答：**"这份信息在解决哪一个核心矛盾/张力？"**
|
||||
输出：
|
||||
- 核心矛盾：A ↔ B（用对立结构表达）
|
||||
- 目标方向：倾向A还是倾向B？为什么（引用证据编号）
|
||||
|
||||
---
|
||||
|
||||
# L2 一：道（Why）— 目的/价值/取舍（最高维约束）
|
||||
判别问题：**"什么值得？为了什么？宁可失去什么也要守住什么？"**
|
||||
输出 2–5 条，每条用模板：
|
||||
- 道-命题 D#（一句话）
|
||||
- 取舍结构：宁可__也要__ / 优先__而非__
|
||||
- 证据引用：E#…
|
||||
|
||||
> 注意：这一层只谈"价值与目的"，不谈方法。
|
||||
|
||||
---
|
||||
|
||||
# L3 二：法（What）— 世界模型/因果假设（可解释现实）
|
||||
判别问题：**"世界/人性/组织/关系是如何运作的？因果链是什么？"**
|
||||
输出 3–7 条，每条：
|
||||
- 模型/因果命题 M#（一句话）
|
||||
- 关键变量：X、Y、Z
|
||||
- 因果方向：X → Y（在条件C下）
|
||||
- 证据引用：E#…
|
||||
- 可证伪信号：若出现__则此模型可能不成立
|
||||
|
||||
> 注意：这一层只解释"是什么/为什么会这样"，不直接给行动步骤。
|
||||
|
||||
---
|
||||
|
||||
# L4 四：术（How）— 原则/策略（可复用的决策规则）
|
||||
判别问题：**"在什么条件下，应当如何选择？"**
|
||||
输出 5–12 条，每条：
|
||||
- 原则/启发式 P#（写成规则句：如果…就…；优先…而非…）
|
||||
- 前提：成立需要什么
|
||||
- 边界：不适用/会反噬的情况
|
||||
- 映射：来自 D# + M#（必须标注）
|
||||
- 证据引用：E#…
|
||||
|
||||
> 注意：这一层给"决策规则"，不写工具模板细节。
|
||||
|
||||
---
|
||||
|
||||
# L5 八：器（Do）— 动作/工具/话术/流程（可直接执行）
|
||||
判别问题：**"我现在就能照着做吗？能否变成清单/步骤/模板？"**
|
||||
输出 3–7 个"工具包"T#，每个包含：
|
||||
- 触发场景
|
||||
- 目标
|
||||
- 步骤（1-2-3…）
|
||||
- 话术/模板（如适用）
|
||||
- 常见误用 → 纠偏
|
||||
- 映射：来自 P#（必须标注）
|
||||
|
||||
---
|
||||
|
||||
# L6 加速度→速度→位移：指标与反馈（让系统可测）
|
||||
你必须按"加速度/速度/位移"给指标，形成由高到低的观测链：
|
||||
|
||||
- **加速度指标 A（驱动变化的变化）**：2个（例如：学习/沟通/决策质量的提升率、冲突升级率变化）
|
||||
- **速度指标 V（行为频率与强度）**：2个（例如：每周复盘次数、关键对话发起次数）
|
||||
- **位移指标 S（结果与状态）**：2个（例如：关系质量评分、项目结果、睡眠/情绪稳定度）
|
||||
|
||||
每个指标必须写清：如何记录、周期、阈值、对应哪个工具包T#。
|
||||
|
||||
---
|
||||
|
||||
# L7 生生不息：迭代律（可学习进化的更新规则）
|
||||
输出：
|
||||
1) 复盘模板（≤5问）
|
||||
2) 更新规则（写成条件句）：
|
||||
- 若出现__（信号/指标）→ 保留/增强/删除/改边界（指向 P# / T#）
|
||||
3) 7天最小实验：做什么、记录什么、如何判定有效
|
||||
|
||||
---
|
||||
|
||||
## 证据层（贯穿全程：先给E#再推导）
|
||||
在进入 L1 之前，先输出"证据表 E#（6–15条）"：
|
||||
- E# 原句/要点（短）
|
||||
- 类型：事实/观点/比喻/推测
|
||||
- 可信度：高/中/低（一句话理由）
|
||||
|
||||
---
|
||||
|
||||
## 最终收束（一句话总纲）
|
||||
用一句话输出总纲：**"在X情境，优先Y而非Z"**，并标注它对应的 D#、M#、P#。
|
||||
|
||||
---
|
||||
|
||||
（等待我粘贴【信息】后开始；不要提前发挥。若信息过长，先分段提E#，再合并去重后进入L1。）
|
||||
116
00-inbox/2026-03-02-lessons-from-building-claude-code.md
Normal file
116
00-inbox/2026-03-02-lessons-from-building-claude-code.md
Normal file
@ -0,0 +1,116 @@
|
||||
---
|
||||
title: "Lessons from Building Claude Code: Seeing like an Agent"
|
||||
slug: lessons-from-building-claude-code
|
||||
status: inbox
|
||||
source_urls:
|
||||
- https://x.com/trq212/status/2027463795355095314
|
||||
author: Thariq (@trq212)
|
||||
author_bio: Claude Code @anthropicai. prev YC W20, MIT Media Lab.
|
||||
created_at: 2026-03-02T00:00:00+08:00
|
||||
updated_at: 2026-03-02T00:00:00+08:00
|
||||
tags:
|
||||
- claude-code
|
||||
- agent-design
|
||||
- tool-design
|
||||
- progressive-disclosure
|
||||
- anthropic
|
||||
---
|
||||
|
||||
# Lessons from Building Claude Code: Seeing like an Agent
|
||||
|
||||
> 来源：Thariq (@trq212) · 2026-02-27 · 3.3M views · 9.3K likes · 25.7K bookmarks
|
||||
> https://x.com/trq212/status/2027463795355095314
|
||||
|
||||
---
|
||||
|
||||
One of the hardest parts of building an agent harness is constructing its action space.
|
||||
|
||||
Claude acts through Tool Calling, but there are a number of ways tools can be constructed in the Claude API with primitives like bash, skills and recently code execution (read more about programmatic tool calling on the Claude API in @RLanceMartin's new article).
|
||||
|
||||
Given all these options, how do you design the tools of your agent? Do you need just one tool like code execution or bash? What if you had 50 tools, one for each use case your agent might run into?
|
||||
|
||||
To put myself in the mind of the model I like to imagine being given a difficult math problem. What tools would you want in order to solve it? It would depend on your own skills!
|
||||
|
||||
Paper would be the minimum, but you'd be limited by manual calculations. A calculator would be better, but you would need to know how to operate the more advanced options. The fastest and most powerful option would be a computer, but you would have to know how to use it to write and execute code.
|
||||
|
||||
This is a useful framework for designing your agent. You want to give it tools that are shaped to its own abilities. But how do you know what those abilities are? You pay attention, read its outputs, experiment. You learn to see like an agent.
|
||||
|
||||
Here are some lessons we've learned from paying attention to Claude while building Claude Code.
|
||||
|
||||
## Improving Elicitation & the AskUserQuestion tool
|
||||
|
||||
When building the AskUserQuestion tool, our goal was to improve Claude's ability to ask questions (often called elicitation).
|
||||
|
||||
While Claude could just ask questions in plain text, we found answering those questions felt like they took an unnecessary amount of time. How could we lower this friction and increase the bandwidth of communication between the user and Claude?
|
||||
|
||||
### Attempt #1 - Editing the ExitPlanTool
|
||||
|
||||
The first thing we tried was adding a parameter to the ExitPlanTool to have an array of questions alongside the plan. This was the easiest thing to implement, but it confused Claude because we were simultaneously asking for a plan and a set of questions about the plan. What if the user's answers conflicted with what the plan said? Would Claude need to call the ExitPlanTool twice? We needed another approach.
|
||||
|
||||
(you can read more about why we made an ExitPlanTool in [our post on prompt caching](https://x.com/trq212/status/2024574133011673516))
|
||||
|
||||
### Attempt #2 - Changing Output Format
|
||||
|
||||
Next we tried modifying Claude's output instructions to serve a slightly modified markdown format that it could use to ask questions. For example, we could ask it to output a list of bullet point questions with alternatives in brackets. We could then parse and format that question as UI for the user.
|
||||
|
||||
While this was the most general change we could make and Claude even seemed to be okay at outputting this, it was not guaranteed. Claude would append extra sentences, omit options, or use a different format altogether.
|
||||
|
||||
### Attempt #3 - The AskUserQuestion Tool
|
||||
|
||||
Finally, we landed on creating a tool that Claude could call at any point, but it was particularly prompted to do so during plan mode. When the tool triggered we would show a modal to display the questions and block the agent's loop until the user answered.
|
||||
|
||||
This tool allowed us to prompt Claude for a structured output and it helped us ensure that Claude gave the user multiple options. It also gave users ways to compose this functionality, for example calling it in the Agent SDK or using referring to it in skills.
|
||||
|
||||
Most importantly, Claude seemed to like calling this tool and we found its outputs worked well. Even the best designed tool doesn't work if Claude doesn't understand how to call it.
|
||||
|
||||
Is this the final form of elicitation in Claude Code? We're not sure. As you'll see in the next example, what works for one model may not be the best for another.
|
||||
|
||||
## Updating with Capabilities - Tasks & Todos
|
||||
|
||||
When we first launched Claude Code, we realized that the model needed a Todo list to keep it on track. Todos could be written at the start and checked off as the model did work. To do this we gave Claude the TodoWrite tool, which would write or update Todos and display them to the user.
|
||||
|
||||
But even then we often saw Claude forgetting what it had to do. To adapt, we inserted system reminders every 5 turns that reminded Claude of its goal.
|
||||
|
||||
But as models improved, they not only did not need to be reminded of the Todo List but could find it limiting. Being sent reminders of the todo list made Claude think that it had to stick to the list instead of modifying it. We also saw Opus 4.5 also get much better at using subagents, but how could subagents coordinate on a shared Todo List?
|
||||
|
||||
Seeing this, we replaced TodoWrite with the Task Tool ([read more on Tasks here](https://x.com/trq212/status/2014480496013803643)). Whereas Todos were about keeping the model on track, Tasks were more about helping agents communicate with each other. Tasks could include dependencies, share updates across subagents and the model could alter and delete them.
|
||||
|
||||
As model capabilities increase, the tools that your models once needed might now be constraining them. It's important to constantly revisit previous assumptions on what tools are needed. This is also why it's useful to stick to a small set of models to support that have a fairly similar capabilities profile.
|
||||
|
||||
## Designing a Search Interface
|
||||
|
||||
A particularly important set of tools for Claude are the search tools that can be used to build its own context.
|
||||
|
||||
When Claude Code first came out, we used a RAG vector database to find context for Claude. While RAG was powerful and fast it required indexing and setup and could be fragile across a host of different environments. More importantly, Claude was given this context instead of *finding* the context itself.
|
||||
|
||||
But if Claude could search on the web, why not search your codebase? By giving Claude a Grep tool, we could let it search for files and build context itself.
|
||||
|
||||
This is a pattern we've seen as Claude gets smarter, it becomes increasingly good at building its context if it's given the right tools.
|
||||
|
||||
When we introduced Agent Skills we formalized the idea of progressive disclosure, which allows agents to incrementally discover relevant context through exploration.
|
||||
|
||||
Claude could read skill files and those files could then reference other files that the model could read recursively. In fact, a common use of skills is to add more search capabilities to Claude like giving it instructions on how to use an API or query a database.
|
||||
|
||||
Over the course of a year Claude went from not really being able to build its own context, to being able to do nested search across several layers of files to find the exact context it needed.
|
||||
|
||||
Progressive disclosure is now a common technique we use to add new functionality without adding a tool.
|
||||
|
||||
## Progressive Disclosure - The Claude Code Guide Agent
|
||||
|
||||
Claude Code currently has ~20 tools, and we are constantly asking ourselves if we need all of them. The bar to add a new tool is high, because this gives the model one more option to think about.
|
||||
|
||||
For example, we noticed that Claude did not know enough about how to use Claude Code. If you asked it how to add a MCP or what a slash command did, it would not be able to reply.
|
||||
|
||||
We could have put all of this information in the system prompt, but given that users rarely asked about this, it would have added context rot and interfered with Claude Code's main job: writing code.
|
||||
|
||||
Instead, we tried a form of progressive disclosure. We gave Claude a link to its docs which it could then load to search for more information. This worked but we found that Claude would load a lot of results into context to find the right answer when really all you needed was the answer.
|
||||
|
||||
So we built the Claude Code Guide subagent which Claude is prompted to call when you ask about itself, the subagent has extensive instructions on how to search docs well and what to return.
|
||||
|
||||
While this isn't perfect, Claude can still get confused when you ask it about how to set itself up, it is much better than it used to be! We were able to add things to Claude's action space without adding a tool.
|
||||
|
||||
### An Art, not a Science
|
||||
|
||||
If you were hoping for a set of rigid rules on how to build your tools, unfortunately that is not this guide. Designing the tools for your models is as much an art as it is a science. It depends heavily on the model you're using, the goal of the agent and the environment it's operating in.
|
||||
|
||||
Experiment often, read your outputs, try new things. See like an agent.
|
||||
36
00-inbox/2026-03-02-obsidian-kanban-for-ai-tasks.md
Normal file
36
00-inbox/2026-03-02-obsidian-kanban-for-ai-tasks.md
Normal file
@ -0,0 +1,36 @@
|
||||
---
|
||||
title: 'Obsidian Kanban 插件管理 AI 并行任务'
|
||||
slug: obsidian-kanban-for-ai-tasks
|
||||
status: inbox
|
||||
source_urls:
|
||||
- https://x.com/BadUncleX/status/2028127961036226675
|
||||
author: BadUncle (@BadUncleX)
|
||||
created_at: '2026-03-02T00:00:00+08:00'
|
||||
updated_at: '2026-03-02T00:00:00+08:00'
|
||||
tags:
|
||||
- obsidian
|
||||
- kanban
|
||||
- task-management
|
||||
- ai-workflow
|
||||
- claude-code
|
||||
---
|
||||
|
||||
# Obsidian Kanban 插件管理 AI 并行任务
|
||||
|
||||
> 来源：BadUncle (@BadUncleX) 对上一条帖子的补充
|
||||
> 上下文：[[2026-03-02-claude-code-overnight-work]]
|
||||
|
||||
---
|
||||
|
||||
无论是并行，还是夜间运行，都有一个项目/任务管理的问题，专门 vibe 了一个 Obsidian Kanban 插件。一方面是可视化任务查看，另一方面结合 Obsidian，为重要任务提供文档支持。
|
||||
|
||||
这个插件一开始想开源的，后来加的东西有点偏，感觉更私人了，索性关掉 open 了。
|
||||
|
||||
总体作用是：动态的看到各个项目的进展，减轻大脑上下文恢复的压力。各个项目的状态 kanban 一目了然。
|
||||
|
||||
## 核心洞察
|
||||
|
||||
- AI 并行/夜间工作的真正瓶颈不是技术，是**人脑的上下文恢复成本**
|
||||
- Kanban 解决的是「早上醒来，快速知道每个项目到哪了」的问题
|
||||
- Obsidian 天然适合做这件事：每个任务卡片可以链接到详细的项目文档笔记
|
||||
- 可视化状态 + 文档支持 = 减轻认知负荷
|
||||
117
00-inbox/2026-03-02-promotor-blueprint-jonathan-courtney.md
Normal file
117
00-inbox/2026-03-02-promotor-blueprint-jonathan-courtney.md
Normal file
@ -0,0 +1,117 @@
|
||||
---
|
||||
title: Promotor Blueprint - CEO 的真正工作是推广
|
||||
source: https://mp.weixin.qq.com/s/XdQW0DClPLvEZJhaOuGA6g
|
||||
author: Jonathan Courtney (AJ&Smart 创始人)
|
||||
collected_at: 2026-03-02
|
||||
tags:
|
||||
- marketing
|
||||
- indie-hacker
|
||||
- claude-code
|
||||
- sales-funnel
|
||||
---
|
||||
|
||||
# Promotor Blueprint - CEO 的真正工作是推广
|
||||
|
||||
> 会造东西，但不会卖东西。这将是 2026 年独立开发者、超级个体们最普遍的困境。
|
||||
|
||||
## 核心观点
|
||||
|
||||
**构建产品只占 20%，CEO 真正的工作是推广。**
|
||||
|
||||
- 你叫得出名字的每一个成功创始人，至少 50% 的时间在推广自己的业务
|
||||
- 如果你不愿意做推广，那就找一个愿意做的联合创始人
|
||||
|
||||
## 推广者蓝图（Promotor Blueprint）
|
||||
|
||||
```
|
||||
流量 (Traffic) → 蓄水池 (Holding Pattern) → 销售事件 (Selling Event) → 循环
|
||||
```
|
||||
|
||||
### 1. 获取流量
|
||||
- **免费**：播客、社交媒体、内容、活动
|
||||
- **付费**：Meta/TikTok/YouTube 广告
|
||||
- **关键**：不要直接导向产品
|
||||
|
||||
### 2. 蓄水池
|
||||
能持续触达受众的地方：
|
||||
- 邮件订阅列表
|
||||
- 播客
|
||||
- YouTube 频道
|
||||
- X/Twitter 账号
|
||||
|
||||
这是建立信任、持续提供价值的地方。
|
||||
|
||||
### 3. 销售事件
|
||||
把人从蓄水池推向购买：
|
||||
- **Webinar**：展示产品如何使用
|
||||
- **邮件序列**：3-4 封精心设计的邮件
|
||||
- **再营销广告**：用邮件列表创建相似受众
|
||||
- **主动触达**：发现企业邮箱订阅者，直接联系
|
||||
|
||||
### 4. 循环
|
||||
没有转化的人回到蓄水池，等待下一次销售事件。
|
||||
|
||||
**漏斗数学**：
|
||||
- 5000 个邮件订阅者
|
||||
- 200 人参加 webinar
|
||||
- 12 个人购买
|
||||
|
||||
## AI 在营销中的真正角色
|
||||
|
||||
Jonathan 只用了约 20% 的 AI 工具量（相比硬核 vibe coder），因为 80% 时间在推广。
|
||||
|
||||
### 具体用例
|
||||
|
||||
1. **语音转结构化笔记**：15 分钟语音脑暴 → ADHD 友好的可扫描文档
|
||||
2. **Claude Code 工作流**：
|
||||
- 在 Claude 项目里做研究、整理思路
|
||||
- 生成 CLAUDE.md（项目上下文）
|
||||
- 带到 Claude Code 继续开发
|
||||
3. **营销文案机器**：
|
||||
- 专门的 Claude 项目用于营销
|
||||
- 灌入写过的书 + 17,766 行营销邮件文档
|
||||
- 提炼核心策略
|
||||
4. **Plan 模式设计 Webinar**：
|
||||
- 让 AI 花 30 分钟"拷问"你
|
||||
- 关于主题、受众、痛点、解决方案
|
||||
- 产出质量比自己想高得多
|
||||
|
||||
### Lead Magnet 生成
|
||||
|
||||
Claude 给出的三个选项：
|
||||
- Promotor Blueprint 一页纸 PDF
|
||||
- 50 个 CEO 推广 Prompt 合集
|
||||
- "穴居人审计"自评表
|
||||
|
||||
**从想法到落地页上线**：以前一周，现在半天。
|
||||
|
||||
## 两个反直觉建议
|
||||
|
||||
### 1. 不要追求效率，要追求规模
|
||||
- 现在不是"用 AI 省人"的时候
|
||||
- 而是"用 AI 做更多事"的时候
|
||||
- 团队规模不变，业务规模翻倍
|
||||
|
||||
### 2. 不要过度准备，直接开干
|
||||
- 准备太多 = 行动太慢的信号
|
||||
- 不做测试项目，直接上真实项目
|
||||
- 不是所有东西都需要从零构建，先问有没有现成的
|
||||
|
||||
## 灵魂拷问
|
||||
|
||||
> 你花在构建和推广上的时间比例是多少？
|
||||
|
||||
---
|
||||
|
||||
## 与 content-forge 的关联
|
||||
|
||||
这套方法论可以直接应用到内容生产流水线：
|
||||
|
||||
| Promotor Blueprint | content-forge 对应 |
|
||||
|-------------------|-------------------|
|
||||
| 流量 | 选题入库 (01-topics) |
|
||||
| 蓄水池 | 草稿积累 (02-drafts) |
|
||||
| 销售事件 | 发布 (04-published) |
|
||||
| 循环 | 内容复用、系列化 |
|
||||
|
||||
**下一步**：考虑增加一个 `/promote` 命令，帮助规划内容的推广策略。
|
||||
38
00-inbox/CLAUDE.md Best Practices.md
Normal file
38
00-inbox/CLAUDE.md Best Practices.md
Normal file
@ -0,0 +1,38 @@
|
||||
# CLAUDE.md Best Practices
|
||||
|
||||
CLAUDE.md is the single most important file for Claude Code. It's loaded automatically at the start of every session — it's who you are and how you work.
|
||||
|
||||
Anthropic's official framing of the extension stack:
|
||||
- **CLAUDE.md** = always-on context (who you are)
|
||||
- **Skills** = on-demand knowledge and workflows
|
||||
- **MCP** = external connections (Jira, Slack, etc.)
|
||||
- **[[Custom Commands]]** = shortcuts for repeated prompts
|
||||
- **[[Hooks]]** = deterministic automation
|
||||
|
||||
## What Goes in CLAUDE.md
|
||||
|
||||
Keep it short. "Keeping your CLAUDE.md as short as possible is a fantastic forcing function for simplifying your codebase and internal tooling."
|
||||
|
||||
My rule: if you can't explain something concisely, it's not ready for CLAUDE.md.
|
||||
|
||||
Three sections that matter:
|
||||
1. **What this project is** — one paragraph
|
||||
2. **Domain rules** — the stuff Claude will get wrong without guidance
|
||||
3. **Validation** — how to check that output is correct
|
||||
|
||||
## The Power of Negative Constraints
|
||||
|
||||
This was a revelation: "Codify failures into your project's CLAUDE.md. Adding specific negative rules (e.g., 'NEVER use X method for Y task') is often more valuable than positive guidelines because it prevents the AI from repeating costly mistakes."
|
||||
|
||||
When Claude makes a mistake, immediately add a NEVER rule. Your CLAUDE.md evolves from positive guidelines to battle-tested negative constraints over time.
|
||||
|
||||
Net Ninja flagged this too — Claude has a habit of using new features/hooks everywhere in your project after creating them. You need explicit "don't do this" rules.
|
||||
|
||||
## The Hierarchy
|
||||
|
||||
CLAUDE.md files cascade:
|
||||
- `~/.claude/CLAUDE.md` — global (your preferences everywhere)
|
||||
- `project/CLAUDE.md` — project-level
|
||||
- `project/src/CLAUDE.md` — directory-level overrides
|
||||
|
||||
This maps to [[The Junior Employee Mental Model]] — it's the onboarding doc. [[Context Window Management]] matters here too: a bloated CLAUDE.md eats into your working context.
|
||||
38
00-inbox/Context Window Management.md
Normal file
38
00-inbox/Context Window Management.md
Normal file
@ -0,0 +1,38 @@
|
||||
# Context Window Management
|
||||
|
||||
"AI context is like milk; it's best served fresh and condensed." — YK/ykdojo
|
||||
|
||||
This is the thing that catches people off guard. As conversations get longer, quality degrades. The model loses track of earlier context, starts repeating itself, forgets instructions, makes mistakes it wasn't making before.
|
||||
|
||||
Ross Mike calls this the "drunk AI" problem. His rule: don't go over 50% context usage. The moment you see 40-50%, start a new session.
|
||||
|
||||
## The Core Strategy
|
||||
|
||||
**Fresh context > stale context, always.**
|
||||
|
||||
- One feature per chat. Mixing features is coding drunk.
|
||||
- Start new sessions often rather than fighting with stale context
|
||||
- Use `/compact` proactively when you feel context degrading
|
||||
- Use `/context` to audit what's consuming your budget
|
||||
|
||||
## Handoff Documents
|
||||
|
||||
The killer pattern: at the end of a session, ask Claude to summarize the current state into a handoff doc. Start a new session with that doc. Fresh context + full awareness.
|
||||
|
||||
This connects to [[Subagents]] — each subagent gets its own fresh context window. It's like giving a task to a new employee who isn't tired yet.
|
||||
|
||||
## The Cost Connection
|
||||
|
||||
Context management IS cost management. Every token you waste on bloated context is money. The practitioner who spent $417 on a word game — one animation fix cost $20 because Claude needed to re-learn the entire codebase. That's a [[Context Window Management]] failure.
|
||||
|
||||
Cost-saving strategies:
|
||||
- Focused prompts = smaller context = less cost
|
||||
- Handoff docs between sessions
|
||||
- [[Subagents]] for isolated tasks
|
||||
- Use Sonnet for simple tasks, Opus for complex ones
|
||||
|
||||
## Related
|
||||
|
||||
- [[Plan Mode]] — planning reduces context waste
|
||||
- [[CLAUDE.md Best Practices]] — a lean CLAUDE.md preserves context
|
||||
- [[The Death Spiral]] — context bloat is a contributing factor
|
||||
44
00-inbox/Custom Commands.md
Normal file
44
00-inbox/Custom Commands.md
Normal file
@ -0,0 +1,44 @@
|
||||
# Custom Commands
|
||||
|
||||
Custom commands are reusable slash commands you create yourself. They live in `.claude/commands/` as markdown files and can be triggered with `/command-name`.
|
||||
|
||||
This is where Claude Code starts feeling like YOUR tool instead of a generic assistant.
|
||||
|
||||
## How They Work
|
||||
|
||||
Create a file at `.claude/commands/my-command.md` with instructions. When you type `/my-command`, Claude reads that file and follows the instructions.
|
||||
|
||||
Examples:
|
||||
- `/review` — code review with your team's standards
|
||||
- `/plan` — generate a PRD from a one-sentence idea
|
||||
- `/debug` — structured debugging workflow
|
||||
- `/standup` — morning briefing that reads your project state
|
||||
|
||||
## The Vin Obsidian Connection
|
||||
|
||||
This is exactly what Internet Vin built for his Obsidian workflow:
|
||||
- `/context` — loads your entire vault's context in one shot
|
||||
- `/today` — morning planning ritual
|
||||
- `/close` — evening reflection
|
||||
- `/challenge` — pressure-test your beliefs using vault history
|
||||
- `/emerge` — surface hidden patterns in your notes
|
||||
- `/ideas` — 30-day vault scan for actionable insights
|
||||
|
||||
The power move: commands that reference your [[CLAUDE.md Best Practices]] and read your personal files to build context automatically.
|
||||
|
||||
## Building a PM Toolkit
|
||||
|
||||
Aakash Gupta's PM workflow was basically a chain of commands: meeting transcript → PRD → Jira tickets → Slack summary → dashboard.
|
||||
|
||||
You could build each step as a command:
|
||||
- `/transcript-to-prd`
|
||||
- `/prd-to-tickets`
|
||||
- `/daily-metrics`
|
||||
|
||||
Each one is a pattern you've validated manually, then codified. See [[The Verification Loop]] — only automate what you've verified.
|
||||
|
||||
## Related
|
||||
|
||||
- [[Hooks]] — commands are on-demand; hooks are automatic
|
||||
- [[CLAUDE.md Best Practices]] — commands complement CLAUDE.md
|
||||
- [[Subagents]] — commands can spawn subagents for complex tasks
|
||||
44
00-inbox/Hooks.md
Normal file
44
00-inbox/Hooks.md
Normal file
@ -0,0 +1,44 @@
|
||||
# Hooks
|
||||
|
||||
Hooks are deterministic automation that runs at specific points in Claude Code's lifecycle. They're the "must-do" rules that complement the "should-do" suggestions in [[CLAUDE.md Best Practices]].
|
||||
|
||||
The key distinction: CLAUDE.md is a suggestion. Hooks are enforced. Claude can ignore CLAUDE.md. It can't ignore a hook.
|
||||
|
||||
## How They Work
|
||||
|
||||
Hooks fire on lifecycle events:
|
||||
- **PreToolUse** — before Claude uses a tool (firewall)
|
||||
- **PostToolUse** — after Claude uses a tool (quality gate)
|
||||
- **Stop** — when Claude finishes responding (review check)
|
||||
- **SessionStart** — when a session begins (preload context)
|
||||
|
||||
They communicate via stdin/stdout and exit codes. A hook can block an action, modify it, or just log it.
|
||||
|
||||
## The Best Use Cases
|
||||
|
||||
**PreToolUse firewall** — prevent Claude from modifying certain files:
|
||||
```json
|
||||
{
|
||||
"event": "PreToolUse",
|
||||
"command": "check-if-protected-file.sh"
|
||||
}
|
||||
```
|
||||
This connects directly to the golden rule from Vin's Obsidian setup — agents read, never write. You could enforce this with a hook.
|
||||
|
||||
**Stop quality gate** — require specific markers before Claude can finish:
|
||||
A hook that checks for `// COMPLETE` comments before allowing Claude to stop. Forces thoroughness.
|
||||
|
||||
**Skill activation** — UserPromptSubmit hooks that detect patterns and load relevant skills automatically.
|
||||
|
||||
## The Power
|
||||
|
||||
"Hooks are the deterministic 'must-do' rules that complement the 'should-do' suggestions in CLAUDE.md."
|
||||
|
||||
Where [[Custom Commands]] are on-demand (you trigger them), hooks are automatic (they trigger themselves). Together they're your automation layer.
|
||||
|
||||
## Related
|
||||
|
||||
- [[CLAUDE.md Best Practices]] — suggestions vs enforcement
|
||||
- [[Custom Commands]] — on-demand vs automatic
|
||||
- [[The Verification Loop]] — hooks can automate verification
|
||||
- [[The Junior Employee Mental Model]] — hooks are like mandatory processes a junior must follow
|
||||
33
00-inbox/Plan Mode.md
Normal file
33
00-inbox/Plan Mode.md
Normal file
@ -0,0 +1,33 @@
|
||||
# Plan Mode
|
||||
|
||||
Overwhelmingly the #1 specific technique across everything I've read about Claude Code.
|
||||
|
||||
Shift+Tab forces Claude to outline its approach before acting. This is a design review — you would never ship a feature without reviewing the spec. Don't let Claude ship code without reviewing the plan.
|
||||
|
||||
## The Pattern
|
||||
|
||||
1. Hit Shift+Tab to enter plan mode
|
||||
2. Claude outlines what it will do
|
||||
3. You review, adjust, approve
|
||||
4. Claude executes
|
||||
|
||||
Aakash Gupta calls this "Checkpoint + Iterate" — have Claude generate a plan, review it, create checkpoints, use Esc twice to rewind if it goes off track.
|
||||
|
||||
## When to Use It
|
||||
|
||||
- Any task touching multiple files
|
||||
- Architecture decisions
|
||||
- Anything you'd want to review before it happens
|
||||
- When you're not sure what the right approach is
|
||||
|
||||
## When to Skip It
|
||||
|
||||
0xDesigner's counter-signal: "you don't need a 'planning mode' or any fancy approaches" — for many tasks, just talking to Claude naturally is enough. I agree for small stuff.
|
||||
|
||||
The rule I follow: if the task takes more than one prompt to describe, use plan mode.
|
||||
|
||||
## Connection to [[Context Window Management]]
|
||||
|
||||
Plan mode is also a context saver. A well-planned execution uses fewer tokens than a chaotic back-and-forth. Less context waste → longer productive sessions.
|
||||
|
||||
See also: [[The Death Spiral]] for what happens when you skip planning.
|
||||
36
00-inbox/Subagents.md
Normal file
36
00-inbox/Subagents.md
Normal file
@ -0,0 +1,36 @@
|
||||
# Subagents
|
||||
|
||||
Subagents are Claude Code's way of running parallel workers. Each one gets its own fresh context window — like assigning a task to a new employee who isn't overloaded with everything else you've been working on.
|
||||
|
||||
The key insight: subagents solve the [[Context Window Management]] problem. Instead of cramming everything into one conversation, you delegate isolated tasks to fresh agents.
|
||||
|
||||
## The Three Types
|
||||
|
||||
1. **Explore agent** — reads files, searches codebase, answers questions about code. Read-only.
|
||||
2. **Code agent** — can read AND write files, run commands. Full power.
|
||||
3. **Custom agent** — via the Task tool with specific instructions.
|
||||
|
||||
## When to Use Them
|
||||
|
||||
Boris Cherny runs 5 local sessions + 5-10 web sessions in parallel. That's extreme for most people. The practical version:
|
||||
|
||||
- **Research tasks** — send a subagent to explore a codebase or read docs while you keep working
|
||||
- **Independent tasks** — two features that don't touch the same files? Parallelize.
|
||||
- **Context isolation** — prevent a debugging rabbit hole from polluting your main session
|
||||
- **Verbose operations** — code reviews, file analysis, anything that generates a lot of output you don't need to see
|
||||
|
||||
## The Pattern
|
||||
|
||||
Each subagent gets:
|
||||
- A clear task description
|
||||
- Relevant file paths or search scope
|
||||
- Expected output format
|
||||
- Its own fresh context window
|
||||
|
||||
The main session stays clean. You get a summary back.
|
||||
|
||||
## Related
|
||||
|
||||
- [[Context Window Management]] — subagents are the #1 tool for managing context
|
||||
- [[The Junior Employee Mental Model]] — subagents ARE the junior employees
|
||||
- [[Custom Commands]] — you can wrap subagent patterns into reusable commands
|
||||
45
00-inbox/The Death Spiral.md
Normal file
45
00-inbox/The Death Spiral.md
Normal file
@ -0,0 +1,45 @@
|
||||
# The Death Spiral
|
||||
|
||||
"The AI Coding Death Spiral: enter for speed, stay for the debugging hell." — Reddit
|
||||
|
||||
This is the anti-pattern everyone hits at some point.
|
||||
|
||||
## The Pattern
|
||||
|
||||
1. Try to save time with AI
|
||||
2. Get low-context, error-prone code
|
||||
3. Spend more time debugging than you would have writing it
|
||||
4. Keep going because "the next prompt might fix it"
|
||||
|
||||
That last point is the killer. "The frustration of AI coding can resemble a gambling addiction, where the user is always hoping the 'next prompt' will be the one that magically solves everything."
|
||||
|
||||
## How to Escape
|
||||
|
||||
From the 6-month practitioner report on Reddit:
|
||||
- **Start with a small, perfectly working base.** Don't try to generate an entire app in one shot.
|
||||
- **One feature at a time.** Never in a single large prompt.
|
||||
- **Write a detailed spec first** — see [[Plan Mode]]
|
||||
- **The 3-prompt rule:** if you've been debugging the same issue for more than 3 prompts, STOP. Think about whether YOU understand the problem.
|
||||
|
||||
The mantra: "If confused, the AI is too. Clarify for yourself first."
|
||||
|
||||
## Why It Happens
|
||||
|
||||
It's almost always a [[Context Window Management]] problem combined with skipping [[Plan Mode]].
|
||||
|
||||
Long session → stale context → bad output → more debugging → longer session → even staler context. It's a feedback loop.
|
||||
|
||||
The escape hatch: start fresh. Write a handoff doc, start a new session, approach the problem with clean context.
|
||||
|
||||
## The Deeper Issue
|
||||
|
||||
"AI is a force multiplier for your existing trajectory. A clean codebase gets cleaner. A messy codebase becomes messier even faster, creating an illusion of speed."
|
||||
|
||||
The death spiral isn't just about context. It's about [[The Verification Loop]] — if you're not checking output quality at each step, errors compound.
|
||||
|
||||
## Related
|
||||
|
||||
- [[Plan Mode]] — the #1 prevention strategy
|
||||
- [[Context Window Management]] — the mechanical cause
|
||||
- [[The Verification Loop]] — the missing check
|
||||
- [[Voice-First Workflows]] — sometimes stepping away from the keyboard and talking through the problem breaks the spiral
|
||||
22
00-inbox/The Junior Employee Mental Model.md
Normal file
22
00-inbox/The Junior Employee Mental Model.md
Normal file
@ -0,0 +1,22 @@
|
||||
# The Junior Employee Mental Model
|
||||
|
||||
The single most important mindset shift: Claude Code is a junior employee, not a magic wand.
|
||||
|
||||
Aakash Gupta said it best — "Delegate like you have 5 junior employees." You wouldn't dump a vague one-liner on a new hire and expect magic. You'd give them context, scope, and clear deliverables.
|
||||
|
||||
This maps directly to PM skills. Delegation, scope definition, and quality review ARE the PM skill set. We already know how to do this — we just need to apply it to AI.
|
||||
|
||||
The progression I've noticed:
|
||||
1. Co-worker (you work alongside it)
|
||||
2. Pair programmer (you guide, it types)
|
||||
3. Team of agents (they run retrospectives and update their own instructions)
|
||||
|
||||
Related: [[Plan Mode]] is basically a design review for your AI. [[The Verification Loop]] is QA. These aren't new skills — they're PM skills applied to a new tool.
|
||||
|
||||
The "shoot and forget" principle from a practitioner I read: "Generally my goal is to delegate, set the context, and let it work. Judging the tool by the final PR and not how it gets there."
|
||||
|
||||
But this requires trust, and trust requires [[The Verification Loop]]. You can't shoot and forget until you've verified enough times to calibrate your expectations.
|
||||
|
||||
## What This Means for [[CLAUDE.md Best Practices]]
|
||||
|
||||
If Claude is a junior employee, then CLAUDE.md is the onboarding doc. You wouldn't onboard someone with a 50-page manual. You'd give them the essentials and let them ask questions.
|
||||
34
00-inbox/The Verification Loop.md
Normal file
34
00-inbox/The Verification Loop.md
Normal file
@ -0,0 +1,34 @@
|
||||
# The Verification Loop
|
||||
|
||||
Boris Cherny (the creator of Claude Code) says verification loops deliver 2-3x quality improvement. That's not a small number.
|
||||
|
||||
The hard truth from Reddit: "Claude can write code all day but can't click a button to see if it works." AI-generated code is NOT optimized for security, performance, or scalability by default. You have to explicitly prompt for these and always verify.
|
||||
|
||||
## The PM Angle
|
||||
|
||||
You are the QA layer. Every output needs human eyes before it ships. This isn't new for PMs — we already review designs, specs, and code. The difference is the volume and speed of output.
|
||||
|
||||
## Debugging Patterns That Work
|
||||
|
||||
**Blind paste** — copy error messages directly into Claude without reading them yourself. Claude is remarkably good at diagnosis from raw errors. 0xDesigner: "I got another error and just pasted the error without reading." Claude diagnosed a missing gas token from a raw wallet error.
|
||||
|
||||
**Screenshot debugging** — paste screenshots of UI bugs directly. Claude's vision is powerful for visual debugging. "A single screenshot can replace three paragraphs of explanation."
|
||||
|
||||
**The re-prompt** — if output seems wrong, use Esc-Esc to go back and rephrase slightly. Often a slight rephrasing yields vastly superior results.
|
||||
|
||||
## The TDD Loop for AI
|
||||
|
||||
Powerful pattern from a practitioner with 6 months of daily AI pairing:
|
||||
1. AI writes a failing test
|
||||
2. Human reviews the test
|
||||
3. AI writes the implementation
|
||||
4. Test passes → move on
|
||||
|
||||
This enforces requirements and ensures correctness. Even without formal TDD: always ask Claude to verify its own work.
|
||||
|
||||
## Connection to Other Notes
|
||||
|
||||
- [[The Junior Employee Mental Model]] — you wouldn't trust a junior's work without review
|
||||
- [[Plan Mode]] — verification starts before execution
|
||||
- [[The Death Spiral]] — skipping verification is how you get there
|
||||
- Boris Cherny's "Grill me on these changes" prompt — make Claude critique its own work. See [[Custom Commands]] for how to automate this.
|
||||
45
00-inbox/Voice-First Workflows.md
Normal file
45
00-inbox/Voice-First Workflows.md
Normal file
@ -0,0 +1,45 @@
|
||||
# Voice-First Workflows
|
||||
|
||||
Multiple sources converge on voice as a transformative input for Claude Code. Allie K. Miller claims 95% of her prompts require zero typing.
|
||||
|
||||
## Why It Matters
|
||||
|
||||
"The game-changer is pairing dictation with AI editing — dictating first to capture your ideas at speaking speed, then using AI to clean it up." — Hannah Stulberg
|
||||
|
||||
You think faster than you type. Dictation captures the full stream of consciousness. Claude handles the formatting.
|
||||
|
||||
## Tools
|
||||
|
||||
- **Wispr Flow** — popular dictation tool
|
||||
- **Superwhisper** — another option
|
||||
- **Parakeet** (via Super Voice Assistant) — newer entrant
|
||||
- Built-in macOS dictation works too for quick stuff
|
||||
|
||||
## The Pineapple Technique
|
||||
|
||||
This one blew my mind. Allie K. Miller uses a unique code word — "pineapple" — to embed AI instructions within her dictation. "It's like a way to speak to the AI on the side of the main task."
|
||||
|
||||
So you're dictating a PRD and you say "pineapple make this section more concise pineapple" and the AI knows that's a meta-instruction, not content.
|
||||
|
||||
## PM Angle
|
||||
|
||||
Dictation + Claude is the fastest path from "rough idea" to "polished artifact." Think about the workflow:
|
||||
1. Speak your thinking (2 minutes)
|
||||
2. Claude formats it into a PRD (seconds)
|
||||
3. Review and refine
|
||||
|
||||
Compare to: staring at a blank doc trying to write the perfect spec.
|
||||
|
||||
This connects to [[Plan Mode]] — you could dictate your plan, have Claude structure it, then review. And to [[The Junior Employee Mental Model]] — you're verbally briefing your employee, not writing a formal memo.
|
||||
|
||||
## Connection to Obsidian
|
||||
|
||||
Vin's whole system is about writing as infrastructure. Voice lowers the friction of writing. More writing → richer vault → smarter [[Custom Commands]] and thinking tools.
|
||||
|
||||
The loop: speak → capture → link → let agents surface patterns.
|
||||
|
||||
## Related
|
||||
|
||||
- [[Plan Mode]] — voice as a planning input
|
||||
- [[The Junior Employee Mental Model]] — verbal delegation
|
||||
- [[Custom Commands]] — build a command that takes voice input and routes it
|
||||
97
00-inbox/vin-obsidian-workflows.md
Normal file
97
00-inbox/vin-obsidian-workflows.md
Normal file
@ -0,0 +1,97 @@
|
||||
---
|
||||
url: https://ccforeveryone.com/mini-lessons/vin-obsidian-workflows
|
||||
title: "Vin Obsidian Workflows — The Obsidian + Claude Code System"
|
||||
description: "Turn Obsidian into a thinking partner for Claude Code. Learn the Obsidian CLI, build a custom context command, and create thinking tools that surface hidden patterns in your notes."
|
||||
source_urls:
|
||||
- https://ccforeveryone.com/mini-lessons/vin-obsidian-workflows
|
||||
- https://www.youtube.com/watch?v=6MBq1paspVU
|
||||
captured_at: "2026-03-02T12:11:00+08:00"
|
||||
status: "inbox"
|
||||
tags:
|
||||
- obsidian
|
||||
- claude-code
|
||||
- workflow
|
||||
- ai-context
|
||||
---
|
||||
|
||||
# Vin Obsidian Workflows
|
||||
|
||||
An interactive version of Greg Isenberg's interview with Internet Vin, where Vin demonstrates how an Obsidian vault of interconnected notes transforms Claude Code from a generic assistant into a personalized thinking partner.
|
||||
|
||||
**Source:** [The Obsidian + Claude Code System That Changes Everything](https://www.youtube.com/watch?v=6MBq1paspVU)
|
||||
|
||||
## What You'll Learn
|
||||
|
||||
- **Obsidian as AI infrastructure** — why a vault of interconnected markdown notes is the missing context layer for Claude Code
|
||||
- **The /my-world command** — one command that loads your entire world into any Claude Code session
|
||||
- **Thinking tools** — commands like /challenge, /emerge, and /connect that surface patterns you'd never see on your own
|
||||
|
||||
## 1. The Context Problem
|
||||
|
||||
Most people hit a ceiling with Claude Code for one reason: every session starts from zero. You re-explain your project, your preferences, your constraints — all over again.
|
||||
|
||||
As Greg put it: **"The whole game is feeding the beast good context."** The model isn't the bottleneck. Your context is.
|
||||
|
||||
## 2. What is Obsidian (and Why It Matters for AI)
|
||||
|
||||
Obsidian is a note-taking app that stores everything as plain markdown files on your computer. Unlike Notion or Google Docs, your notes aren't locked in someone else's cloud — they're `.md` files Claude Code can read natively.
|
||||
|
||||
The killer feature: **wikilinks**. Write `[[Project Alpha]]` in a note, and Obsidian creates a bidirectional link. Over time, this builds a web of connected ideas — projects link to people, people to meetings, meetings to decisions. It's a map of how you think.
|
||||
|
||||
Vin said: "It works more like the way your brain works. Your brain connects these patterns all the time."
|
||||
|
||||
## 3. The Obsidian CLI
|
||||
|
||||
In February 2026, Obsidian released an official command-line interface. This is the bridge that gives Claude Code access to your vault's *relationships* — backlinks, orphan notes, tag counts, the full link graph. Things that don't exist in the raw files.
|
||||
|
||||
The efficiency difference is massive: finding orphan notes by scanning files takes 15 seconds and millions of tokens. With the CLI, it takes 0.26 seconds and about 100 tokens.
|
||||
|
||||
## 4. Building the /my-world Command
|
||||
|
||||
This is the most important command Vin built (he calls it `/context`, but since that's a built-in Claude Code command, we name it `/my-world`). Instead of re-explaining who you are every session, `/my-world` loads your vault — projects, priorities, connections — in one shot.
|
||||
|
||||
The lesson includes 10 pre-built vault notes about Claude Code best practices, all interconnected with wikilinks. You'll build a `/my-world` command that reads them all and maps the knowledge graph. Or connect your own vault for even more powerful results.
|
||||
|
||||
## 5. Daily Rituals: /today and /close
|
||||
|
||||
Vin bookends every day with two commands:
|
||||
|
||||
- **`/today`** — morning planning that pulls calendar, tasks, and recent notes
|
||||
- **`/close`** — evening reflection that extracts action items and surfaces missed connections
|
||||
|
||||
The insight: "Writing right now is a big way of how you delegate things to agents. If you can develop a writing habit, you have a lot more context that you can pass over to an agent."
|
||||
|
||||
## 6. Thinking Tools: /challenge, /emerge, /connect
|
||||
|
||||
This is Vin's favorite part of the system — commands that don't organize information, they generate insight:
|
||||
|
||||
- **`/challenge`** — pressure-tests your beliefs using your vault's own history
|
||||
- **`/emerge`** — surfaces ideas the vault implies but you never explicitly stated
|
||||
- **`/connect`** — bridges two disparate domains using your link graph
|
||||
|
||||
Greg compared it to a therapist: "You're doing most of the talking. The therapist is guiding you. That's what this is doing."
|
||||
|
||||
## 7. The Golden Rule: Agents Read, Humans Write
|
||||
|
||||
The critical principle most people get wrong: **never let the agent write into your vault.**
|
||||
|
||||
Vin was emphatic: "I don't want an agent to write into the files… I always want it to pull from what I think about things, not what it thinks about things."
|
||||
|
||||
If Claude starts creating notes in your vault, then when it runs `/emerge` — is it finding YOUR patterns or ITS patterns? The vault must contain only what you think. Claude reads and responds. It never contaminates the source.
|
||||
|
||||
## 8. From Reflection to Action
|
||||
|
||||
The most impressive part of Vin's demo: the agent started suggesting things to BUILD. His `/ideas` command scans 30 days of notes and produces tools to build, people to meet, essays to write.
|
||||
|
||||
The loop: **write notes → agent finds patterns → agent suggests tools → you build them → tools improve your notes → repeat.**
|
||||
|
||||
## By the End
|
||||
|
||||
You'll have:
|
||||
|
||||
- Obsidian connected to Claude Code (your vault or the included example vault)
|
||||
- A working `/my-world` command that loads your world in one shot
|
||||
- A thinking tool (/challenge, /emerge, or /connect) you've run on real notes
|
||||
- The "agents read, humans write" principle for keeping your vault authentic
|
||||
|
||||
**Download:** [Lesson folder](https://ccforeveryone.com/downloads/vin-obsidian-workflows.zip)
|
||||
@ -8,6 +8,11 @@ language: zh-CN
|
||||
owner: content-forge
|
||||
created_at: 2026-03-02
|
||||
updated_at: 2026-03-02
|
||||
id: 2026-03-02-cli-test
|
||||
source_urls: []
|
||||
assets: []
|
||||
cover_image: ""
|
||||
template: article
|
||||
---
|
||||
|
||||
# CLI 测试选题
|
||||
|
||||
40
01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
Normal file
40
01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
Normal file
@ -0,0 +1,40 @@
|
||||
---
|
||||
title: Obsidian 1.12 命令行工具：AI 的外部记忆层升级
|
||||
slug: obsidian-cli-ai-memory-layer
|
||||
status: topic
|
||||
content_type: article
|
||||
language: zh-CN
|
||||
created_at: 2026-03-02T00:00:00+08:00
|
||||
updated_at: 2026-03-02T00:00:00+08:00
|
||||
tags:
|
||||
- obsidian
|
||||
- obsidian-cli
|
||||
- ai-memory
|
||||
- knowledge-management
|
||||
- claude-code
|
||||
id: 2026-03-02-obsidian-cli-ai-memory-layer
|
||||
channels:
|
||||
- wechat
|
||||
- x
|
||||
source_urls: []
|
||||
assets: []
|
||||
cover_image: ""
|
||||
template: article
|
||||
owner: content-forge
|
||||
---
|
||||
|
||||
# Obsidian 1.12 命令行工具：AI 的外部记忆层升级
|
||||
|
||||
Obsidian 1.12 加了命令行工具，对用 AI 的人来说是大升级。
|
||||
|
||||
现在很多人把 Obsidian 当 AI 的外部记忆层——笔记、决策记录、踩坑经验都沉淀在 vault 里，AI 需要时直接读取。我自己就是这么用的：Claude Code 读写 vault，等于跨会话的长期记忆。
|
||||
|
||||
升级方法：更新到 1.12 → 设置 → 通用 → 打开命令行工具。
|
||||
|
||||
试了一下，两个直观感受：
|
||||
|
||||
一是省 token。以前 AI 要了解笔记库概况，得遍历所有文件（45KB）；现在一行命令，351 字节。看一篇笔记结构，以前读整个文件（63KB），现在只返回标题大纲（5KB）。查孤儿笔记、死链，以前得自己写脚本，现在一行命令秒出。
|
||||
|
||||
二是多了一层图谱检索。向量搜索找的是内容相似的笔记，命令行的反向链接找的是你当初主动建立的知识连接——这两种相关不一样。AI 搜到一篇笔记后，顺着反向链接拉出关联知识，这是传统搜索做不到的。
|
||||
|
||||
Obsidian 管存储，AI 管智能，命令行把两边接上了。
|
||||
654
02-drafts/2026-03-02-obsidian-cli-ai-external-memory.md
Normal file
654
02-drafts/2026-03-02-obsidian-cli-ai-external-memory.md
Normal file
@ -0,0 +1,654 @@
|
||||
---
|
||||
title: Obsidian CLI：AI 的外部记忆层
|
||||
slug: obsidian-cli-ai-external-memory
|
||||
style: tech_blog
|
||||
audience: AI 从业者、知识管理爱好者
|
||||
status: draft
|
||||
tags:
|
||||
- obsidian
|
||||
- ai-memory
|
||||
- cli
|
||||
- knowledge-management
|
||||
source_notes:
|
||||
- 01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
|
||||
- 00-inbox/2026-03-02-cli-is-all-you-need.md
|
||||
created_at: 2026-03-02T00:00:00+08:00
|
||||
updated_at: 2026-03-02T00:00:00+08:00
|
||||
id: 2026-03-02-obsidian-cli-ai-external-memory
|
||||
content_type: article
|
||||
channels:
|
||||
- wechat
|
||||
- x
|
||||
language: zh-CN
|
||||
source_urls: []
|
||||
assets: []
|
||||
cover_image: ""
|
||||
template: tech-blog
|
||||
owner: content-forge
|
||||
---
|
||||
|
||||
# Obsidian CLI：AI 的外部记忆层
|
||||
|
||||
## 问题背景
|
||||
|
||||
AI Agent 有一个致命缺陷：会话结束，记忆清零。
|
||||
|
||||
每次对话都从零开始。你上周踩的坑、上个月做的架构决策、半年前的最佳实践——全没了。你得重复解释，Agent 重复犯错。
|
||||
|
||||
有人用 Notion，有人用 GitHub Issues，有人用外部数据库。但这些方案要么 API 臃肿，要么和 AI 的工作方式不匹配。
|
||||
|
||||
**Obsidian 1.12 给出了另一个答案：命令行工具。**
|
||||
|
||||
## 核心方案
|
||||
|
||||
Obsidian 1.12 新增的 CLI 让 AI 可以直接读写你的 vault——不用 API，不用 MCP server，就是普通的 shell 命令。
|
||||
|
||||
22
|
||||
00-inbox/vin-obsidian-workflows.md
|
||||
00-inbox/CLAUDE.md Best Practices.md
|
||||
Error: File "00-inbox/my-note.md" not found.
|
||||
00-inbox/2026-03-02-cli-is-all-you-need.md
|
||||
00-inbox/2026-03-02-lessons-from-building-claude-code.md
|
||||
00-inbox/2026-03-02-obsidian-kanban-for-ai-tasks.md
|
||||
00-inbox/2026-03-02-sync-test.md
|
||||
00-inbox/vin-obsidian-workflows.md
|
||||
01-topics/2026-03-02-cli-test.md
|
||||
01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
|
||||
content-pipeline-v2.md
|
||||
templates/article.md
|
||||
templates/social-post.md
|
||||
templates/tech-blog.md
|
||||
|
||||
这套方案的核心逻辑是：
|
||||
|
||||
**Obsidian 管存储，AI 管智能，CLI 把两边接上。**
|
||||
|
||||
### 为什么不用 MCP？
|
||||
|
||||
Marco Franzon 在《CLI Is All You Need》里说得很直接：
|
||||
|
||||
> "Bash is the ultimate MCP."
|
||||
> "Agents were trained on Unix pipes—they're ridiculously good at it."
|
||||
|
||||
MCP server 需要你写 schema、维护 server、处理版本兼容。而 CLI？Agent 本来就会用。它被训练了几十年的 Unix 命令用法，、、 这些它比谁都熟。
|
||||
|
||||
Obsidian CLI 就是把这个原则用到了知识管理上。
|
||||
|
||||
## 实现细节
|
||||
|
||||
### 安装
|
||||
|
||||
1. 更新 Obsidian 到 1.12+
|
||||
2. 设置 → 通用 → 打开「命令行工具」
|
||||
3. 验证：终端运行 name content-forge
|
||||
path /home/kang/apps/content-forge/content-forge
|
||||
files 22
|
||||
folders 8
|
||||
size 43687
|
||||
|
||||
### 关键命令
|
||||
|
||||
| 命令 | 用途 | AI 场景 |
|
||||
|------|------|---------|
|
||||
| 22 | 统计笔记数量 | 快速了解 vault 规模 |
|
||||
| No matches found. | 全文搜索 | 找相关笔记 |
|
||||
| Error: File "..." not found. | 读取笔记内容 | 获取具体信息 |
|
||||
| 00-inbox/2026-03-02-cli-is-all-you-need.md
|
||||
00-inbox/2026-03-02-lessons-from-building-claude-code.md
|
||||
00-inbox/2026-03-02-obsidian-kanban-for-ai-tasks.md
|
||||
00-inbox/2026-03-02-sync-test.md
|
||||
00-inbox/vin-obsidian-workflows.md
|
||||
01-topics/2026-03-02-cli-test.md
|
||||
01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
|
||||
content-pipeline-v2.md
|
||||
templates/article.md
|
||||
templates/social-post.md
|
||||
templates/tech-blog.md | 查找孤儿笔记 | 发现知识孤岛 |
|
||||
| 00-inbox/2026-03-02-claude-code-overnight-work.md
|
||||
00-inbox/2026-03-02-cli-is-all-you-need.md
|
||||
00-inbox/2026-03-02-lessons-from-building-claude-code.md
|
||||
00-inbox/2026-03-02-sync-test.md
|
||||
00-inbox/vin-obsidian-workflows.md
|
||||
01-topics/2026-03-02-cli-test.md
|
||||
01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
|
||||
content-pipeline-v2.md
|
||||
templates/article.md
|
||||
templates/social-post.md
|
||||
templates/tech-blog.md | 查找死链 | 清理断裂链接 |
|
||||
| Error: No active file. Use file=<name> or path=<path> to specify a file. | 查看反向链接 | 顺藤摸瓜 |
|
||||
|
||||
### Token 节省
|
||||
|
||||
实测数据：
|
||||
|
||||
| 操作 | 旧方案 | 新方案 | 节省 |
|
||||
|------|--------|--------|------|
|
||||
| 了解笔记库概况 | 遍历所有文件 (45KB) | 22 (351B) | **99.2%** |
|
||||
| 看一篇笔记结构 | 读取整个文件 (63KB) | Error: No active file. Use file=<name> or path=<path> to specify a file. 只看标题 (5KB) | **92%** |
|
||||
| 查找孤儿笔记 | 自己写脚本 | 00-inbox/2026-03-02-cli-is-all-you-need.md
|
||||
00-inbox/2026-03-02-lessons-from-building-claude-code.md
|
||||
00-inbox/2026-03-02-obsidian-kanban-for-ai-tasks.md
|
||||
00-inbox/2026-03-02-sync-test.md
|
||||
00-inbox/vin-obsidian-workflows.md
|
||||
01-topics/2026-03-02-cli-test.md
|
||||
01-topics/2026-03-02-obsidian-cli-ai-memory-layer.md
|
||||
content-pipeline-v2.md
|
||||
templates/article.md
|
||||
templates/social-post.md
|
||||
templates/tech-blog.md 一行命令 | N/A |
|
||||
|
||||
## 验证结果
|
||||
|
||||
### 1. 省 Token
|
||||
|
||||
这是最直观的收益。AI 不再用 context window 存整个文件系统，而是用 CLI 按需查询。Context 窗口留给真正的推理，不是存文件列表。
|
||||
|
||||
### 2. 多了一层图谱检索
|
||||
|
||||
这是更重要的收益。
|
||||
|
||||
向量搜索找的是「内容相似」的笔记。CLI 的反向链接找的是「你当初主动建立的知识连接」。
|
||||
|
||||
这两个「相关」不一样。
|
||||
|
||||
AI 搜到一篇笔记后，可以顺着 Error: No active file. Use file=<name> or path=<path> to specify a file. 拉出你当初链接它的所有笔记——这是传统搜索做不到的。它复活了你构建知识图谱时的意图。
|
||||
|
||||
## 总结与扩展
|
||||
|
||||
**Obsidian CLI 把 AI 变成了你的长期记忆外挂。**
|
||||
|
||||
- **省 token**：CLI 按需查询，不暴力遍历
|
||||
- **图谱感知**：反向链接复活你的知识结构意图
|
||||
- **零集成成本**：Agent 本来就会用 shell
|
||||
|
||||
如果你在用 Claude Code 或其他 CLI-native Agent，强烈建议把这个加进工作流。你的 vault 不再只是笔记库——它是 AI 的外部皮层。
|
||||
|
||||
---
|
||||
|
||||
**行动建议**：
|
||||
|
||||
1. 今天就更新 Obsidian 到 1.12，打开 CLI
|
||||
2. 把 Obsidian CLI
|
||||
|
||||
Usage: obsidian <command> [options]
|
||||
|
||||
Options:
|
||||
vault=<name> Target a specific vault by name
|
||||
|
||||
Notes:
|
||||
file resolves by name (like wikilinks), path is exact (folder/note.md)
|
||||
Most commands default to the active file when file/path is omitted
|
||||
Quote values with spaces: name="My Note"
|
||||
Use
|
||||
for newline, for tab in content values
|
||||
|
||||
Commands:
|
||||
aliases List aliases in the vault
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
total - Return alias count
|
||||
verbose - Include file paths
|
||||
active - Show aliases for active file
|
||||
|
||||
append Append content to a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
content=<text> - Content to append (required)
|
||||
inline - Append without newline
|
||||
|
||||
backlinks List backlinks to a file
|
||||
file=<name> - Target file name
|
||||
path=<path> - Target file path
|
||||
counts - Include link counts
|
||||
total - Return backlink count
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
|
||||
base:create Create a new item in a base
|
||||
file=<name> - Base file name
|
||||
path=<path> - Base file path
|
||||
view=<name> - View name
|
||||
name=<name> - New file name
|
||||
content=<text> - Initial content
|
||||
open - Open file after creating
|
||||
newtab - Open in new tab
|
||||
|
||||
base:query Query a base and return results
|
||||
file=<name> - Base file name
|
||||
path=<path> - Base file path
|
||||
view=<name> - View name to query
|
||||
format=json|csv|tsv|md|paths - Output format (default: json)
|
||||
|
||||
base:views List views in the current base file
|
||||
|
||||
bases List all base files in vault
|
||||
|
||||
bookmark Add a bookmark
|
||||
file=<path> - File to bookmark
|
||||
subpath=<subpath> - Subpath (heading or block) within file
|
||||
folder=<path> - Folder to bookmark
|
||||
search=<query> - Search query to bookmark
|
||||
url=<url> - URL to bookmark
|
||||
title=<title> - Bookmark title
|
||||
|
||||
bookmarks List bookmarks
|
||||
total - Return bookmark count
|
||||
verbose - Include bookmark types
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
|
||||
command Execute an Obsidian command
|
||||
id=<command-id> - Command ID to execute (required)
|
||||
|
||||
commands List available command IDs
|
||||
filter=<prefix> - Filter by ID prefix
|
||||
|
||||
create Create a new file
|
||||
name=<name> - File name
|
||||
path=<path> - File path
|
||||
content=<text> - Initial content
|
||||
template=<name> - Template to use
|
||||
overwrite - Overwrite if file exists
|
||||
open - Open file after creating
|
||||
newtab - Open in new tab
|
||||
|
||||
daily Open daily note
|
||||
paneType=tab|split|window - Pane type to open in
|
||||
|
||||
daily:append Append content to daily note
|
||||
content=<text> - Content to append (required)
|
||||
inline - Append without newline
|
||||
open - Open file after adding
|
||||
paneType=tab|split|window - Pane type to open in
|
||||
|
||||
daily:path Get daily note path
|
||||
|
||||
daily:prepend Prepend content to daily note
|
||||
content=<text> - Content to prepend (required)
|
||||
inline - Prepend without newline
|
||||
open - Open file after adding
|
||||
paneType=tab|split|window - Pane type to open in
|
||||
|
||||
daily:read Read daily note contents
|
||||
|
||||
deadends List files with no outgoing links
|
||||
total - Return dead-end count
|
||||
all - Include non-markdown files
|
||||
|
||||
delete Delete a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
permanent - Skip trash, delete permanently
|
||||
|
||||
diff List or diff local/sync versions
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
from=<n> - Version number to diff from
|
||||
to=<n> - Version number to diff to
|
||||
filter=local|sync - Filter by version source
|
||||
|
||||
file Show file info
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
files List files in the vault
|
||||
folder=<path> - Filter by folder
|
||||
ext=<extension> - Filter by extension
|
||||
total - Return file count
|
||||
|
||||
folder Show folder info
|
||||
path=<path> - Folder path (required)
|
||||
info=files|folders|size - Return specific info only
|
||||
|
||||
folders List folders in the vault
|
||||
folder=<path> - Filter by parent folder
|
||||
total - Return folder count
|
||||
|
||||
help Show list of all available commands
|
||||
<command> - Show help for a specific command
|
||||
|
||||
history List file history versions
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
history:list List files with history
|
||||
|
||||
history:open Open file recovery
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
history:read Read a file history version
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
version=<n> - Version number (default: 1)
|
||||
|
||||
history:restore Restore a file history version
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
version=<n> - Version number (required)
|
||||
|
||||
hotkey Get hotkey for a command
|
||||
id=<command-id> - Command ID (required)
|
||||
verbose - Show if custom or default
|
||||
|
||||
hotkeys List hotkeys
|
||||
total - Return hotkey count
|
||||
verbose - Show if hotkey is custom
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
all - Include commands without hotkeys
|
||||
|
||||
links List outgoing links from a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
total - Return link count
|
||||
|
||||
move Move or rename a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
to=<path> - Destination folder or path (required)
|
||||
|
||||
open Open a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
newtab - Open in new tab
|
||||
|
||||
orphans List files with no incoming links
|
||||
total - Return orphan count
|
||||
all - Include non-markdown files
|
||||
|
||||
outline Show headings for the current file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
format=tree|md|json - Output format (default: tree)
|
||||
total - Return heading count
|
||||
|
||||
plugin Get plugin info
|
||||
id=<plugin-id> - Plugin ID (required)
|
||||
|
||||
plugin:disable Disable a plugin
|
||||
id=<id> - Plugin ID (required)
|
||||
filter=core|community - Plugin type
|
||||
|
||||
plugin:enable Enable a plugin
|
||||
id=<id> - Plugin ID (required)
|
||||
filter=core|community - Plugin type
|
||||
|
||||
plugin:install Install a community plugin
|
||||
id=<id> - Plugin ID (required)
|
||||
enable - Enable after install
|
||||
|
||||
plugin:reload Reload a plugin (for developers)
|
||||
id=<id> - Plugin ID (required)
|
||||
|
||||
plugin:uninstall Uninstall a community plugin
|
||||
id=<id> - Plugin ID (required)
|
||||
|
||||
plugins List installed plugins
|
||||
filter=core|community - Filter by plugin type
|
||||
versions - Include version numbers
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
|
||||
plugins:enabled List enabled plugins
|
||||
filter=core|community - Filter by plugin type
|
||||
versions - Include version numbers
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
|
||||
plugins:restrict Toggle or check restricted mode
|
||||
on - Enable restricted mode
|
||||
off - Disable restricted mode
|
||||
|
||||
prepend Prepend content to a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
content=<text> - Content to prepend (required)
|
||||
inline - Prepend without newline
|
||||
|
||||
properties List properties in the vault
|
||||
file=<name> - Show properties for file
|
||||
path=<path> - Show properties for path
|
||||
name=<name> - Get specific property count
|
||||
total - Return property count
|
||||
sort=count - Sort by count (default: name)
|
||||
counts - Include occurrence counts
|
||||
format=yaml|json|tsv - Output format (default: yaml)
|
||||
active - Show properties for active file
|
||||
|
||||
property:read Read a property value from a file
|
||||
name=<name> - Property name (required)
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
property:remove Remove a property from a file
|
||||
name=<name> - Property name (required)
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
property:set Set a property on a file
|
||||
name=<name> - Property name (required)
|
||||
value=<value> - Property value (required)
|
||||
type=text|list|number|checkbox|date|datetime - Property type
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
random Open a random note
|
||||
folder=<path> - Limit to folder
|
||||
newtab - Open in new tab
|
||||
|
||||
random:read Read a random note
|
||||
folder=<path> - Limit to folder
|
||||
|
||||
read Read file contents
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
recents List recently opened files
|
||||
total - Return recent file count
|
||||
|
||||
reload Reload the vault
|
||||
|
||||
rename Rename a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
name=<name> - New file name (required)
|
||||
|
||||
restart Restart the app
|
||||
|
||||
search Search vault for text
|
||||
query=<text> - Search query (required)
|
||||
path=<folder> - Limit to folder
|
||||
limit=<n> - Max files
|
||||
total - Return match count
|
||||
case - Case sensitive
|
||||
format=text|json - Output format (default: text)
|
||||
|
||||
search:context Search with matching line context
|
||||
query=<text> - Search query (required)
|
||||
path=<folder> - Limit to folder
|
||||
limit=<n> - Max files
|
||||
case - Case sensitive
|
||||
format=text|json - Output format (default: text)
|
||||
|
||||
search:open Open search view
|
||||
query=<text> - Initial search query
|
||||
|
||||
snippet:disable Disable a CSS snippet
|
||||
name=<name> - Snippet name (required)
|
||||
|
||||
snippet:enable Enable a CSS snippet
|
||||
name=<name> - Snippet name (required)
|
||||
|
||||
snippets List installed CSS snippets
|
||||
|
||||
snippets:enabled List enabled CSS snippets
|
||||
|
||||
sync Pause or resume sync
|
||||
on - Resume sync
|
||||
off - Pause sync
|
||||
|
||||
sync:deleted List deleted files in sync
|
||||
total - Return deleted file count
|
||||
|
||||
sync:history List sync version history for a file
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
total - Return version count
|
||||
|
||||
sync:open Open sync history
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
|
||||
sync:read Read a sync version
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
version=<n> - Version number (required)
|
||||
|
||||
sync:restore Restore a sync version
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
version=<n> - Version number (required)
|
||||
|
||||
sync:status Show sync status
|
||||
|
||||
tab:open Open a new tab
|
||||
group=<id> - Tab group ID
|
||||
file=<path> - File to open
|
||||
view=<type> - View type to open
|
||||
|
||||
tabs List open tabs
|
||||
ids - Include tab IDs
|
||||
|
||||
tag Get tag info
|
||||
name=<tag> - Tag name (required)
|
||||
total - Return occurrence count
|
||||
verbose - Include file list and count
|
||||
|
||||
tags List tags in the vault
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
total - Return tag count
|
||||
counts - Include tag counts
|
||||
sort=count - Sort by count (default: name)
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
active - Show tags for active file
|
||||
|
||||
task Show or update a task
|
||||
ref=<path:line> - Task reference (path:line)
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
line=<n> - Line number
|
||||
toggle - Toggle task status
|
||||
done - Mark as done
|
||||
todo - Mark as todo
|
||||
daily - Use daily note
|
||||
status="<char>" - Set status character
|
||||
|
||||
tasks List tasks in the vault
|
||||
file=<name> - Filter by file name
|
||||
path=<path> - Filter by file path
|
||||
total - Return task count
|
||||
done - Show completed tasks
|
||||
todo - Show incomplete tasks
|
||||
status="<char>" - Filter by status character
|
||||
verbose - Group by file with line numbers
|
||||
format=json|tsv|csv - Output format (default: text)
|
||||
active - Show tasks for active file
|
||||
daily - Show tasks from daily note
|
||||
|
||||
template:insert Insert template into active file
|
||||
name=<template> - Template name (required)
|
||||
|
||||
template:read Read template content
|
||||
name=<template> - Template name (required)
|
||||
resolve - Resolve template variables
|
||||
title=<title> - Title for variable resolution
|
||||
|
||||
templates List templates
|
||||
total - Return template count
|
||||
|
||||
theme Show active theme or get info
|
||||
name=<name> - Theme name for details
|
||||
|
||||
theme:install Install a community theme
|
||||
name=<name> - Theme name (required)
|
||||
enable - Activate after install
|
||||
|
||||
theme:set Set active theme
|
||||
name=<name> - Theme name (empty for default) (required)
|
||||
|
||||
theme:uninstall Uninstall a theme
|
||||
name=<name> - Theme name (required)
|
||||
|
||||
themes List installed themes
|
||||
versions - Include version numbers
|
||||
|
||||
unresolved List unresolved links in vault
|
||||
total - Return unresolved link count
|
||||
counts - Include link counts
|
||||
verbose - Include source files
|
||||
format=json|tsv|csv - Output format (default: tsv)
|
||||
|
||||
vault Show vault info
|
||||
info=name|path|files|folders|size - Return specific info only
|
||||
|
||||
vaults List known vaults
|
||||
total - Return vault count
|
||||
verbose - Include vault paths
|
||||
|
||||
version Show Obsidian version
|
||||
|
||||
wordcount Count words and characters
|
||||
file=<name> - File name
|
||||
path=<path> - File path
|
||||
words - Return word count only
|
||||
characters - Return character count only
|
||||
|
||||
workspace Show workspace tree
|
||||
ids - Include workspace item IDs
|
||||
|
||||
|
||||
Developer:
|
||||
dev:cdp Run a Chrome DevTools Protocol command
|
||||
method=<CDP.method> - CDP method to call (required)
|
||||
params=<json> - Method parameters as JSON
|
||||
|
||||
dev:console Show captured console messages
|
||||
clear - Clear the console buffer
|
||||
limit=<n> - Max messages to show (default 50)
|
||||
level=log|warn|error|info|debug - Filter by log level
|
||||
|
||||
dev:css Inspect CSS with source locations
|
||||
selector=<css> - CSS selector (required)
|
||||
prop=<name> - Filter by property name
|
||||
|
||||
dev:debug Attach/detach Chrome DevTools Protocol debugger
|
||||
on - Attach debugger
|
||||
off - Detach debugger
|
||||
|
||||
dev:dom Query DOM elements
|
||||
selector=<css> - CSS selector (required)
|
||||
total - Return element count
|
||||
text - Return text content
|
||||
inner - Return innerHTML instead of outerHTML
|
||||
all - Return all matches instead of first
|
||||
attr=<name> - Get attribute value
|
||||
css=<prop> - Get CSS property value
|
||||
|
||||
dev:errors Show captured errors
|
||||
clear - Clear the error buffer
|
||||
|
||||
dev:mobile Toggle mobile emulation
|
||||
on - Enable mobile emulation
|
||||
off - Disable mobile emulation
|
||||
|
||||
dev:screenshot Take a screenshot
|
||||
path=<filename> - Output file path
|
||||
|
||||
devtools Toggle Electron dev tools
|
||||
|
||||
eval Execute JavaScript and return result
|
||||
code=<javascript> - JavaScript code to execute (required) 命令加到你的 Agent 可用工具列表
|
||||
3. 试着让 Agent 帮你清理一次孤儿笔记
|
||||
|
||||
---
|
||||
|
||||
> 参考：
|
||||
> - [[2026-03-02-obsidian-cli-ai-memory-layer]] 原始思考
|
||||
> - [[2026-03-02-cli-is-all-you-need]] CLI vs MCP 的深度分析
|
||||
102
content-pipeline-v2.md
Normal file
102
content-pipeline-v2.md
Normal file
@ -0,0 +1,102 @@
|
||||
---
|
||||
title: Content Pipeline (Dataview Kanban)
|
||||
kanban-plugin: basic
|
||||
---
|
||||
|
||||
## 灵感/素材 (∞)
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "00-inbox"
|
||||
WHERE status = "inbox" OR status = null
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 选题 (WIP: 3)
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "01-topics"
|
||||
WHERE status = "topic"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 写作 (WIP: 3)
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "02-drafts"
|
||||
WHERE status = "draft"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 配图/格式化 (WIP: 2)
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "02-drafts" OR "05-assets"
|
||||
WHERE status = "formatting" OR status = "visual"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 审核 (WIP: 2)
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "03-review"
|
||||
WHERE status = "review"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 发布 (WIP: 2)
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "03-review"
|
||||
WHERE status = "publishing"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 已完成
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM "04-published"
|
||||
WHERE status = "published"
|
||||
SORT published_at DESC
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 阻塞/等待
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM ""
|
||||
WHERE status = "blocked"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
## 修订中
|
||||
|
||||
```dataview
|
||||
LIST
|
||||
FROM ""
|
||||
WHERE status = "revision"
|
||||
SORT file.ctime DESC
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
> [!info] 状态枚举
|
||||
> `inbox` → `topic` → `draft` → `formatting` → `review` → `publishing` → `published`
|
||||
>
|
||||
> 特殊状态: `revision` `blocked` `archived`
|
||||
>
|
||||
> 废弃目录: `06-archived/`
|
||||
|
||||
%% kanban:settings
|
||||
```
|
||||
{"kanban-plugin":"basic","lane-width":280,"show-checkboxes":false}
|
||||
```
|
||||
%%
|
||||
Loading…
Reference in New Issue
Block a user