Day 2：开始指挥 Agent 干活

昨天你把 Obsidian 和工作区装好了。今天不自己动手。

你的工作区不是普通的笔记库——它是写给 Agent 看的。Agent 需要知道你是谁、你在做什么、你的目标是什么，才能帮你干活。

所以今天做 3 件事：

1. 在 CLAUDE.md 里写上你的信息——告诉 Agent 你是谁
2. 让 Agent 诊断一次你的仓库
3. 选一个闭环，让 Agent 替你产出一份能用的东西——行动清单、知识索引或者文章初稿

认识界面

打开 Obsidian 后，默认工作区大致分成三块：

• 左边：文件和目录
• 中间：笔记编辑区
• 右边：Claudian / Agent 聊天区

你可以先打开 CLAUDE.md，把里面的占位信息改成自己的真实信息：

• 你的名字
• 你的业务
• 你的目标
• 你希望 Agent 遵守的工作方式

这些内容会成为 Agent 的长期背景。下一轮对话时，它会更清楚你是谁、你在做什么、你希望它如何帮你。

四种角色

工作区里的看起来文件夹很多，其实就 4 类。一个一个看。

原始材料类（Raw）

Raw 记录「发生过什么」——你今天干了什么、跟谁聊了什么、冒出了什么想法。

在你的仓库里，每日/、思考/、讨论/、摘录/ 这些目录都属于 Raw。你记的日记、记下的想法、会议录音转的文字——全是 Raw。

一篇 Raw 长这样：

---
type: [[Daily]]
date: 2026-07-13
---
 
今天跟王老师聊了课程合作的事。他那边希望 8 月上线。
下午查了一下多巴胺机制的资料，感觉可以用在互动设计里。

存的位置就是 每日/ 目录：

每日/
└── 2026-07-13.md

原始材料由你来写。因为你是亲身经历的人——你跟客户聊了啥、今天有什么想法、发生了什么——只有你知道。你记下来，这就是一手信息。

AI 在下游等着。你每写完一条，它就开始加工：更新状态、提炼结论、产出方案。

这是你们的分工：你放原料，它加工。

所以原料放上去就不要动了。不是因为怕 AI 搞乱，是一个更重要的原因——改了就不是当时的记录了。

举个例子。你跟王老师聊了一门课程合作的事，三天里不断推进：

第一天：跟王老师聊了课程合作，对方希望 8 月上线，感觉可以做。 记作：2026-07-13.md

第二天：回公司一算，人手不够，8 月可能排不过来。 记作：2026-07-14.md

第三天：跟团队确认了排期，9 月可以，回复王老师。 记作：2026-07-15.md

三条记录放在那里，一字不改。

半年后你翻回来看，第一天怎么想的、第二天发现了什么问题、第三天怎么决定的——清清楚楚。

如果把第一天的记录改成「9月上线」——那这条记录就不是 13 号的了。你也看不出当时你是怎么从「感觉可以做」到「发现人手不够」再到「确定 9 月」的。

不改，才能完整回溯。

不仅你能回溯，AI 也能。它读了这三条记录，能自己还原出整件事的来龙去脉——不用你额外解释。

所以：多记新的，不改旧的。

当前状态类（State）

State 记录「现在是什么情况」——项目卡在哪、客户跟到哪了。

在你的仓库里，项目/、商业/客户/、商业/产品/ 这些目录都属于 State。每个文件对应一个项目或客户的当前状态。

还是刚才那个例子。你每天写一条原始记录，AI 读完就去更新 State：

第一天你记：

跟王老师聊了课程合作，对方希望 8 月上线。

AI 读完就知道：课程合作这个项目的最新状态是「8 月上线」。

第二天你记：

回公司一算，人手不够，8 月可能排不过来。

AI 读到这一条，发现状态变了——它自动把 State 更新成「人手不够，8 月待确认」。

第三天你记：

跟团队确认了排期，9 月可以。

AI 读完，再次更新 State：「9 月上线」。

这个过程不用你手动去改 State——AI 自己去读、自己去更新。

你可能会想：我自己手动更新一下不就行了？

一个项目当然可以。但你有 5 个这样的项目呢？

没有这个机制的时候：你每天得打开每个项目的 State，对照今天的记录，手动改状态。5 个项目还行，10 个呢？20 个呢？用不了多久你就懒得维护了。

有了这个机制的时候：你只管每天记发生了什么。AI 自己读、自己更新。打开 State 文件夹，永远是最新的。

一篇 State 长这样：

---
type: [[Project]]
status: 进行中
---
 
# 课程合作项目
 
当前状态：跟王老师初步沟通，等待对方发合同。
卡点：人手不够，需要确认 8 月能否上线。
下一步：周五前确认团队排期。

存的位置是 项目/ 目录：

项目/
└── 课程合作.md

你不用自己去改它。你记 Raw，AI 更新 State——这是它的工作。

为什么一定要有 State？

因为以后你会同时让好几个 Agent 一起干活。每个 Agent 接手一个任务，如果都得从头读你过去三个月的所有 Raw——太浪费了，token 刷刷地烧。

有 State 就不一样。Agent 来了先读 State——项目卡在哪、客户跟到哪了——几秒钟就能上手，不用翻遍你所有的原始记录。

State 就是 Raw 的浓缩版。 想知道最新情况，看 State 就够了。需要深挖细节，再回 Raw 里翻。

这就跟团队协作一样：新同事加入，你给他一份项目简报（State），而不是把三个月的聊天记录全甩给他。

本次产出（Artifact）

Artifact 是 Agent 替你产出的成品——文章初稿、行动清单、方案。

在你的仓库里，产出/ 和 内容/ 目录都属于 Artifact。Agent 产出的方案、文章、清单都放在这里。

还是那个例子。三天过去，你的 Raw 里有了三条记录，State 里有了最新状态。现在你跟 Agent 说：

「帮我写一份课程合作的推进总结，包括当前进度和下一步建议。」

Agent 去读了你的 Raw（三天的记录）和 State（最新状态：9 月上线），然后给你一份东西：

---
type: [[Article]]
status: 初稿
---
 
# 课程合作推进总结
 
## 当前进度
9 月上线已确认。
 
## 关键节点
...
 
## 下一步建议
...

这就是 Artifact——Agent 替你产出的成品。不用你自己翻三天的记录来写，Agent 读了 Raw 和 State，直接给你一份能用的。

但事情还没完。

你把这份「课程合作推进总结」发给了王老师。王老师看了，回了一条消息：「9 月可以，但第一期先做 10 个人的试点。」

你收到回复，顺手记在日记里——这又是一条新的 Raw。

第二天 AI 读到这条 Raw，发现状态又变了：从「9 月上线」变成「10 人试点，9 月启动」。它更新了 State。然后它又产出了一份新的 Artifact——更新版的合作方案。

你看看发生了什么：

你写的方案（Artifact）→ 发给了客户（真实世界）→ 客户给了反馈（真实世界）→ 你把反馈记下来（新的 Raw）→ AI 更新状态（新的 State）→ AI 产出新的方案（新的 Artifact）→ 你又发给客户……

信息在你的 Obsidian 和真实世界之间来回流动。每一次流动，事情就往前推进一步。

没有 Artifact，你永远不会有东西发出去。没有反馈，你就不会有新的 Raw。没有新的 Raw，AI 就不知道情况变了。Artifact 是让这个循环转起来的那个「推一下」。

每次产出新建一个文件，不覆盖旧的。命名按「日期_名称」来，一眼就知道什么时候产的：

产出/
├── 20260715_课程合作推进总结_v1.md
├── 20260716_课程合作推进总结_v2.md
├── 20260713_多巴胺机制研究大纲.md
└── 20260714_8月课程排期方案.md

你负责记 Raw，AI 负责更新状态和产出成品。这就是你们的分工。

系统规则（System）

System 是写给 Agent 看的说明书——你的信息、目录用途、操作规则。

在你的仓库里，系统/ 目录和根目录下的 CLAUDE.md 都属于 System。模板、规则、配置都放在这里。最核心的是 CLAUDE.md：

# 我的信息
 
我是 XXX，做 XXX 业务。
我的目标是 XXX。
请按以下方式帮我工作：...

它就在工作区的根目录下，跟其他文件夹平级：

CLAUDE.md          ← 就是它
每日/
项目/
产出/
系统/

Agent 每次启动都会读这个文件。

举个例子。你在 CLAUDE.md 里写了这一行：

我的日记存在 每日/ 目录下。

下次你跟 Agent 说：「翻一翻我最近的日记。」它就知道去 每日/ 里找，不会去别的地方翻。

这就是 CLAUDE.md 的作用——告诉 Agent 你的东西放在哪、你希望它怎么工作。写清楚这个文件，Agent 就不用来回猜了。

四个角色看完，其实就是王老师那个例子：

你记日记（Raw）→ AI 更新状态（State）→ AI 产出方案（Artifact）。CLAUDE.md 告诉它去哪找、怎么干。

以后每件事都这么来。

今天最重要的动作

根据你的目标，改造这个毛坯工作区。增加你觉得缺失的文件夹分类，创建新的模板等等，但是，不要自己去整理，而是“先让 Agent 诊断，再让 Agent 动手”。

也就是说，今天你的身份不是执行者，而是指挥者。

第一步应该让它诊断你的仓库。

把下面这段发给右侧 Agent：

你是一个 Obsidian LLM Workspace Architect。你的任务是把我的 Obsidian 仓库改造成一个适合 LLM 长期协作的工作区。

请先诊断，不要立刻大规模修改文件。你的工作目标不是把仓库整理得很漂亮，而是让我尽快拥有一个能出活的 LLM 工作流。

请扫描仓库结构，判断我的主模式更接近 LLM-GTD、LLM 知识库，还是 LLM 内容创作。然后按 RAW / State / Artifact / System 说明现有目录分别适合承担什么角色。

请输出《仓库诊断报告》和《最小改造方案》。在我说“确认执行”之前，不要移动、删除、重命名大量文件，也不要覆盖我的原始笔记。

它会给你一份诊断报告，告诉你仓库现在适合做什么、哪里需要调整。

拿到之后不要贪多，只选一个闭环跑通。今天最重要的是让 Agent 真正替你完成一次工作。

如果你后面遇到“Agent 不听话”“明明写过它却读不到”“我一直在替 Agent 擦屁股”这类问题，不要先怀疑自己不会用。新版工作区里已经预装了 agent-doctor skill，可以直接对 Agent 说：

请使用 agent-doctor，帮我诊断为什么这个 Agent 最近总是跑偏或不按要求执行。

它会按症状逐步追问，把问题归到表达不清、知识不可达、分工不对或系统过载，再给对应修复方案。

三个闭环

根据你的目标，挑一个最贴近你的场景跑通：

行动闭环

适合项目、客户、跟进、待办很多的人。 把如下Prompt发送给Agent：

帮我做行动闭环：扫描最近 7 天的每日记录、会议纪要、客户沟通和项目相关材料，判断哪些是本次任务的原始材料，哪些当前状态需要更新。请提炼今天最重要的 1-3 件事、客户跟进事项、等待他人的事项和项目风险。先列出你会读取和修改哪些文件，等我确认后再执行。

目标结果：一份今天可以执行的 Agenda。

知识闭环

适合摘录、阅读笔记、研究资料很多的人。把如下Prompt发送给Agent：

帮我做知识闭环：把我的摘录、课程笔记、飞书文档、会议总结和案例材料当作本次任务的原始材料，不要覆盖原文。请提炼主题、概念、框架和当前结论，建立或更新知识索引、主题页和更新记录，并告诉我哪些主题最值得继续补资料。

目标结果：一个主题知识索引。

内容/交付闭环

适合要写文章、课程、方案、文案、交付物的人。把如下Prompt发送给Agent：

帮我做内容/交付闭环：从我的客户沟通、旧交付方案、摘录、对标文案和行业材料里提炼可复用素材，生成 10 个选题或交付方向，选出最适合今天推进的 1 个，并产出一版内容 Brief 和初稿。请标注每个观点来自哪些材料。

目标结果：一组选题和一版初稿。

今天完成什么

就是开头说的 3 件事：

1. CLAUDE.md 写好了你的信息
2. Agent 做完了一次仓库诊断
3. 你选了一个闭环，Agent 替你产出了一份能用的东西

不用追求完美。Day 2 完成后，你应该能感觉到：

• 你告诉 Agent 你的目标，它自己去想办法
• 它开始替你整理和产出
• 你发现：与其自己干，不如让 Agent 干，你来验收