先说结论。这个 Obsidian 创作插件工作台，不是从"我要做一个插件"开始的，也不是手工一点点敲出来的。

它是从一篇写不下去的文章开始的。

最早只是一个视频选题：有人把 Claude Code 放进 Obsidian，用一套面板管理自己的笔记、任务和创作。

看起来很带感，因为里面集成了这名视频博主的一些数据，例如笔记数量、订阅数量、粉丝数量等等。

我倒是想写一篇文章介绍一下这个插件。

但写到一半，我发现这篇文章没法发。视频的作者怎么配置 Obsidian、装了哪些插件、终端怎么摆、命令怎么跑，在视频里都没说。

所以真正的转折点是这个问题：

能不能不是简单的给读者介绍一个复杂面板，而是直接把面板做出来，让他安装后就能用？

也就是从"写教程"，变成"做产品"。

真正执行这件事的，是 Codex。

我不是让它给几个建议就结束，而是让它读本地知识库、读工作流规范、写 Obsidian 插件、改脚本、跑检查、同步到本机 Obsidian，最后打包并推到 GitHub。

这篇文章讲的不是"我怎么想了一个工具"，而是"我怎么用 Codex 把一个想法落成了工具"。

CC Note Ops 主工作台

1. 一个工作台，先要解决重复动作

我最开始想做的东西很简单：给 Obsidian 一个控制中心。

它不是知识库首页，不是装饰仪表盘，也不是漂亮的 Dashboard。它应该像一个操作台，打开当前笔记后，能围绕这篇笔记做几个内容创作者高频动作。

这些动作，说实话并不是我自己想的，这是 Codex 在插件建设规划的时候想的。

我并不是一个 Obsidian 笔记的重度应用者，其实我也不是很了解很多高深的 Obsidian 笔记用法。

但是 Codex 给我了这六个建议，我最初的想法是，先把这 6 个做出来，肯定是有用的。

这个插件按钮的意义就在这里。

最初是问了一句能不能行

Codex 的建议不是让 AI 变神奇，而是把稳定动作固化下来。

如果你心中有想法，可以直接说需求。

这一步给 Codex 的提示词可以这样写：

请在当前项目中帮我设计并实现一个 Obsidian 当前笔记内容操作台。

目标不是写建议，而是落地一个最小可用版本：
1. 能识别当前笔记路径
2. 能提供 6 个高频内容动作
3. 输出类动作生成新文件，不改原文
4. 修改类动作必须先备份
5. 所有结果都写回 Obsidian vault
6. UI 要像工作台，不像说明书

请先读项目规范和现有目录，再给产品结构、文件结构和实现步骤。
确认后直接创建文件、写代码、跑最小检查。

注意这里不是问"怎么做一个好看的 Obsidian 面板"。那样 AI 很容易给你一堆装饰。

我们问的是：当前笔记、动作、输出、备份、工作台。

这几个词把产品锚住了。

好看的前提，是它真的能干活

中间我走过一次弯路。

第一版面板看起来还可以，但很多按钮只是皮。点了没有真实动作，或者需要用户自己再配置很多东西。这种东西最危险，因为它会给人一种"我好像已经有工作流了"的错觉。

但真的开始写东西时，它帮不上忙。

所以我们很快把标准改掉了：

外表可以参考，但不能做花架子。

Obsidian 工作台必须接住三件事。

• 第一，能调用 Claude Code。
  按钮不是本地假动作，而是通过脚本调用本机的 claude -p。
  这意味着它能真的把当前笔记交给 Claude Code 处理，然后把输出写回 vault。

• 第二，能和 Terminal 插件配合。
  按钮适合处理固定动作，比如公众号改写、小红书拆条；Terminal 适合深度修改和连续对话。
  于是工作台里保留"给 Claude"的复制入口：复制相对路径、完整路径、改写提示词。
  用户可以把这些粘到 Obsidian 里的 Claude Code 终端继续接管。

• 第三，能保护源笔记。
  一开始有个很细的体验问题：点"公众号选题"后，工作台生成了一个结果文件；用户一打开结果文件，工作台就以为"当前笔记"变成了结果文件。
  接下来再点按钮，操作对象就跑偏了。

我们后来做了"锁定源笔记"。

工作台打开时先记住原始笔记。后面就算你查看生成结果，按钮仍然默认作用于最初那篇素材。

这个设计看起来小，其实是产品和玩具的分界线。

需要不停的测试和反馈

这也是 Codex 参与开发时很关键的一点：它不只是在生成一个 UI，而是在替我们拆清楚两条链路。

• 按钮链路负责固定动作，后台跑 claude -p。
• Terminal 链路负责人工接管，用户把路径和提示词复制给 Codex 继续聊。

这两条链路如果混在一起，用户就会疑惑：“为什么我点按钮了，底部 Claude 没反应？”

拆开之后，产品才讲得清楚。文件结构要替用户收拾干净。

另一个真实反馈是：安装后右侧多出一堆文件夹，看着很乱。

最初安装以后，一堆默认的文件夹

这句话很重要。

开发者容易觉得"文件都在那里，多透明"。普通用户看到的是"我的 Obsidian 被污染了"。尤其是创作者的 vault，本来就是长期积累的资产，不应该因为一个插件被塞进一堆脚本、模板、配置。

所以后来结构变成三层：

.obsidian/plugins/cc-command-center/    # 插件本体
.cc-command-center/                     # 隐藏运行配置
控制中心/                               # 可见结果和工作台

用户需要看的，只有 控制中心/。

脚本、动作模板、文风模板、代理配置，都放进隐藏目录 .cc-command-center/。这就是一个小技巧：能不暴露给用户的复杂度，就不要暴露。

如果要让 AI 帮你设计安装结构，可以这样问：

请重新设计这个 Obsidian 插件的安装结构。

目标：
1. 用户文件树尽量干净
2. 用户需要看的内容放到"控制中心"
3. 脚本、模板、配置放到隐藏目录
4. 插件本体放到 Obsidian 标准插件目录
5. 必须提供 install.sh 和 uninstall.sh
6. 卸载时默认保留用户生成结果，可选彻底删除

请输出目录结构和安装/卸载脚本策略。

这里真正的设计点不是脚本怎么写，而是默认保留用户结果。

卸载插件，不等于删除用户资产。

2. Prompt 不该写死，要变成模板

项目被网友看到后，最有价值的反馈之一是：

你这六个动作的 prompt 是写死的吗？

这个问题一下打到了核心。

如果公众号改写、小红书拆条、口播润色全用同一套提示词，那输出很快会变成平均味。AI 内容最怕的不是写不出来，而是越写越像同一个模型吐出来的。

所以我们加了两层模板。

• 第一层是动作模板，放在：

.cc-command-center/actions/

比如 公众号改写.md、小红书拆条.md、摘要路标.md。它定义"这次任务要做什么"。

• 第二层是文风模板，放在：

.cc-command-center/profiles/

比如"均衡清晰"“不滑锅观点流”“上镜口播”“专业教程”。它定义"用什么表达方式做"。

这也是一个很值得复用的判断：

只要任务目标是"表达"，就让它吃文风；只要任务目标是"整理"，就让它保持稳定。

对应的提示词可以这样写：

请在当前 Obsidian 工作台项目里，重构 prompt 模板体系。

要求：
1. 区分"动作模板"和"文风模板"
2. 动作模板定义任务目标
3. 文风模板定义表达方式
4. 只有表达型任务读取文风
5. 结构化任务不受文风影响
6. 每个按钮要在 UI 上显示当前使用的文风，避免用户误解

请直接修改插件配置、动作模板、文风模板和执行脚本。
完成后同步到本机 Obsidian 插件目录，并跑最小验证。

2.1. 长文处理，要把约束写进系统里

还有一个网友问得很具体：

Claude Code 处理中文长文时，上下文保持稳吗？超过 3000 字会不会漏前半部分？

这不是杠。

这是中文内容工作流最常见的坑。

很多 AI 改写看起来通顺，但其实只认真处理了后半段。
尤其长口播、长访谈、长笔记，模型容易抓几个显眼观点，然后把其它细节丢掉。

所以我们没有只在文章里提醒用户"注意长文"。
那没用。人会忘。

我们把长文约束追加进按钮执行上下文：

长文处理约束：
1. 先建立全文结构地图，再输出结果。
2. 输出必须覆盖开头、中段、结尾的关键信息。
3. 信息量过大时，优先保留核心论点、关键步骤、案例和限制条件。
4. 不编造原文没有的事实、数据和用户案例。

这类约束不一定保证 100% 不漏，但它能把模型的注意力拉回来。

更关键的是，它被写进系统，而不是写在教程最后。

教程最后的提醒，用户看完就忘。系统里的约束，每次运行都会生效。

2.2. 本土化不是翻译，是处理真实环境

这个工作台后来加了代理配置。

原因也很现实：在国内环境里，很多人使用 Claude Code 会关心网络代理。有人用原厂服务，有人用本地 Ollama，有人终端里写了 proxyon 函数，有人根本不知道 Obsidian 这种 GUI 应用和终端环境变量不是一回事。

这里最容易讲复杂。

我们最后把它拆成一句人话：

Obsidian 后台按钮调用 Claude Code 时，不一定继承你终端里的代理设置。

所以插件支持 .cc-command-center/proxy.env，只读取标准环境变量：

HTTP_PROXY=http://127.0.0.1:7890
HTTPS_PROXY=http://127.0.0.1:7890
ALL_PROXY=socks5://127.0.0.1:7890
NO_PROXY=localhost,127.0.0.1

后来又加了一键启用 7890、启用 7897、关闭代理。

但这里必须说清楚边界：它只影响插件后台调用 Claude Code 的环境变量，不修改系统代理，也不保证账号安全。

工具越贴近真实使用，越要把这种边界讲明白。

不然用户会以为"点了代理按钮就万事大吉"。

这就是事故入口。

3. Codex 还负责把它开源出去

这个项目不是写完本地能用就结束。

后来我直接让 Codex 把它整理成一个可以公开的 GitHub 项目。

这一步很重要。

很多工具停在"我本机能跑"，就永远只是自己的小玩具。真正对别人有用，必须有安装入口、卸载入口、截图、说明、版本和更新记录。

Codex 做得最有价值的地方，不是"写代码快"，而是它能把这些脏活串起来。

写完插件只是 60%。

剩下 40%，是文档、验证、截图、打包和发布。

4. UI 的迭代，几乎都来自真实

工作台的 UI 不是一次设计出来的。

它是被一轮轮真实反馈磨出来的。

主题切换演示

• 一开始按钮太大，工作台很长。改。
• 源笔记区域太松，留白太多。改。
• 亮色主题下有黑块。改。
• 主题色切换后，一键操作和"给 Claude"卡片没有完全适配。改。
• 点击按钮后只显示"正在改写"，用户不知道有没有在跑、跑了多久、是不是卡住。改。

最后加了运行状态条：正在运行、已耗时、最长等待、完成、失败原因。任务运行时禁用其它按钮，避免重复点击。

还有一个很典型的 bug：第一次点击按钮无效，需要点第二次。

原因不是按钮坏了，而是 Obsidian 在从源笔记切到工作台 Pane 时触发了 active-leaf-change，插件立刻重绘，把刚被点击的按钮销毁了。第一次点击就被吞掉了。

另一个 bug 是工作台能向下滑出重复页面。

原因是多个异步 render() 交错执行，旧内容被重复追加。解决方式是加 renderToken，只允许最后一次渲染生效。

你看，这些问题都不是"AI 生成代码"时最容易想到的问题。

它们来自真实用户的手。

一个工具好不好用，最终不是看 README 写得多漂亮，而是看用户点第一下时，有没有被接住。

5. 这套方法可以复用

回头看，这个 Obsidian 工作台真正跑通，不是因为某个提示词特别神，而是因为我们一直在做同一件事：

把脑子里的模糊不舒服，翻译成一个可修改的产品结构。

• "文章看不懂"翻译成：不要写复杂教程，做成安装即用。
• "别只是好看"翻译成：按钮必须真的调用 Claude Code。
• "文件夹太乱"翻译成：可见结果和隐藏配置分层。
• "左侧 Claude 没反应"翻译成：后台按钮和 Terminal 会话是两条路径，要在 UI 里讲清楚。
• "文风模板和复制提示词有什么区别"翻译成：动作模板与文风模板解耦。
• "点击没反应"翻译成：需要运行状态、超时策略、stdin 关闭和按钮禁用。
• "第一次点击无效"翻译成：焦点切换触发重绘，点击事件被吞。

所谓 AI 工作流，不是让 AI 替你想完所有事。

它更像一个高速迭代器。你提出一个不舒服的点，它把这个点变成代码、脚本、配置、文档；你再真实使用，再把新的不舒服丢回来。

一轮一轮，工具就长出来了。

5.1. 最后一组可直接用的 Codex 提示词

如果你也想用 Codex 做一个自己的 Obsidian 工作台，可以从这几组提示词开始。

5.1.1. 产品定义

请在当前工作区帮我设计一个 Obsidian 当前笔记 AI 工作台。

请不要先写代码，先帮我定义产品：
1. 目标用户是谁
2. 当前笔记有哪些高频重复动作
3. 哪些动作应该一键完成
4. 哪些动作应该交给 Terminal 里的 Claude Code 手动接管
5. 哪些结果应该生成新文件
6. 哪些动作会修改原文，修改前如何备份
7. UI 第一屏应该只保留哪些信息

请输出最小可用版本清单、目录结构和实现顺序。

5.1.2. 插件实现

请在当前目录中实现一个无构建步骤的 Obsidian 插件。

要求：
1. 使用标准社区插件结构：manifest.json、main.js、styles.css
2. 能识别当前 Markdown 文件路径
3. 能渲染一个右侧工作台视图
4. 按钮点击后调用 vault 内的 shell 脚本
5. 脚本通过 claude -p 执行 prompt
6. 输出类任务写入"控制中心/运行结果/当前笔记"
7. 修改类任务先备份再改源文件
8. 提供 install.sh 和 uninstall.sh
9. 完成后运行 node --check、jq empty、bash -n 做最小验证

5.1.3. 提示词模板

请为当前 Obsidian AI 工作台实现一套可配置 prompt 模板系统。

背景：
这是一个 Obsidian AI 工作台，围绕当前笔记做内容创作。

要求：
1. actions/ 放动作模板，比如公众号改写、小红书拆条、摘要路标
2. profiles/ 放文风模板，比如专业教程、上镜口播、账号观点流
3. 表达型任务读取文风模板
4. 结构型任务不读取文风模板
5. 所有任务都追加长文处理约束
6. UI 上要显示当前动作和当前文风，避免用户误解

请直接创建或修改对应文件，并说明哪些任务读取文风，哪些不读取。

5.1.4. 体验排错

请从真实用户体验角度审查并修复这个 Obsidian 工作台。

重点检查：
1. 点击后用户是否知道任务已经开始
2. 任务运行多久、最长等待多久是否可见
3. 失败原因是否能被普通用户理解
4. 生成结果是否会抢走源笔记焦点
5. 多次点击是否会重复触发任务
6. 异步渲染是否可能导致重复 UI
7. 亮色/暗色主题是否有硬编码颜色残留
8. 安装后是否污染用户文件树

请按"问题 -> 原因 -> 修改文件 -> 验证方法"输出。
能直接修复的请直接改，并跑最小检查。

这次最有意思的地方，是我们没有停在"怎么复刻别人的 Obsidian 面板"。

复刻只能得到外形。

真正有用的工作台，必须从自己的重复动作里长出来，从自己的报错里长出来，从用户一句"我看不懂"“点了没反应”"这个地方好丑"里长出来。

AI 不是陪你把想法聊漂亮。

它应该把那句"要不我们直接做出来吧"，变成一个能安装、能卸载、能报错、能迭代的东西。

工具到这一步，才算开始干活。