印 岳峙亭渊 DIGITAL STUDIO

ESSAY

用 n8n + DeepSeek + Obsidian 打造决策疲劳终结者：从想法到落地的完整实践

随笔 Obsidian n8n DeepSeek 自动化 效率系统

“工具的价值，不是替代思考，而是释放认知资源。”

核心观点 / 起源

每天早上打开笔记，看着昨天留下的待办清单，你是否也有过这样的困扰：

  • 要不要花时间深入学习 Claude Code 来提升开发效率？
  • 要不要现在就申请海外 PM 职位，还是继续积累经验？
  • n8n 工作流优化和产品文档，哪个更紧急？

这些问题的共同点是：它们都很重要，但你不知道该先做哪个。

这就是典型的“决策疲劳”——不是缺少选项，而是缺少一个清晰的评估框架。当大脑需要在多个“看起来都重要”的事项之间反复权衡时，认知资源被大量消耗，最终的结果往往是：拖延、焦虑，或者随机选一个开始做。

更糟糕的是，这种决策疲劳每天都在发生。作为一个科技出海方向的产品人，我每天要面对技术学习、职业规划、项目优先级、内容创作等多个维度的决策。每次纠结 30 分钟后，即使做出了选择，也会怀疑“是不是应该先做另一个”。

有没有办法把这个评估过程自动化？

答案是：有。通过 n8n、DeepSeek 与 Obsidian，我构建了一个“决策助手”，它能在 3 秒内给出基于 ICE 模型的优先级建议，并自动把最高优先级的任务追加到我的待办清单里。

这篇文章记录的，不只是一个自动化小系统的搭建过程，更是一次把“纠结”转换成“结构化判断”的实践。

细节展开

在开始动手之前，我先明确了三个核心需求：

  1. 决策事项的记录：我习惯在 Obsidian 日记里用 #decision 标签标记需要决策的事项。
  2. 自动化编排：需要一个工具把“提取任务 → 调用 AI → 返回结果”串起来。
  3. AI 分析能力：需要一个能理解中文、支持结构化输出的 LLM。

基于这三个需求，我选择了：

  • Obsidian：我的日记系统，决策事项的源头。通过 Templater 插件可以执行 JavaScript 脚本，实现与外部 API 的交互。
  • n8n：开源的自动化工具，本地部署免费，支持复杂的工作流编排。相比 Zapier 或 Make.com，n8n 的优势是完全可控、无隐私顾虑、支持自定义代码节点。
  • DeepSeek：国产 LLM，API 价格便宜，中文理解能力强，支持结构化输出。

整个决策框架依赖的是 ICE 模型：

  • Impact（影响力）：这件事做成后的价值有多大？
  • Confidence（可行性）：我有多大把握能做成？
  • Ease（容易度）：执行起来有多容易？

ICE 总分 = I + C + E，分数越高，优先级越高。

相比复杂的决策矩阵，ICE 模型更适合个人系统：维度足够少，标准足够清晰，也更容易让 AI 理解并稳定执行。

过程 / 推演

整个系统的工作流程可以概括为四步：在 Obsidian 里写下带 #decision 标签的事项；由 Templater 脚本提取这些任务并拼接成完整 prompt；将请求发给 n8n webhook；再由 n8n 调用 DeepSeek 分析、返回表格，并把最高优先级任务自动追加回当前笔记。

Obsidian 日记
  ↓
Templater 脚本提取任务并拼接 Prompt
  ↓
n8n Webhook 接收请求
  ↓
DeepSeek 按 ICE 模型输出结果
  ↓
返回 Markdown 表格 + 自动回写最高优先级任务

这里最关键的设计点有三个。

第一，Fan-out 架构。n8n 的 LLM Chain 输出后，同时走两条分支：一条立即把结果返回给 Obsidian，让用户马上看到表格；另一条在后台提取 TASK_DATA 并通过 Obsidian Local REST API 追加任务。这样副流程失败也不会影响主流程显示。

第二，降级处理。如果 DeepSeek 没有按预期输出 TASK_DATA: 行，IF 节点会直接跳过追加任务步骤，避免整个链路因为格式偏差而中断。

第三，Prompt 在客户端拼接。这是整个系统稳定下来的关键转折。最初我尝试在 n8n 里用表达式拼接 prompt，但很快踩到了表达式求值的坑。后来我把 prompt 拼接完全放回 Templater 脚本，用 JavaScript 模板字符串直接构建，再把完整结果 POST 给 n8n，问题就消失了。

Templater 脚本的核心逻辑并不复杂：读取当前笔记、提取带 #decision 标签的行、去重、拼接 prompt、发起请求、再解析返回结果中的表格和 TASK_DATA。核心代码如下：

<%*
const decisionTag = '#decision';
const webhookUrl = 'http://localhost:5678/webhook/decision-fatigue';

const file = app.workspace.getActiveFile();
const content = await app.vault.read(file);
const lines = content.split('\n');
const targetLines = [...new Set(
  lines
    .map(line => line.trim())
    .filter(line => line && line.includes(decisionTag))
)];

if (targetLines.length === 0) {
  new Notice('没有找到需要处理的决策任务！');
  return '';
}

const tasks = targetLines.join('\n');
const prompt = `请对以下决策事项用 ICE 模型评分（Impact影响力 + Confidence可行性 + Ease容易度，各1-10分）。

决策事项：
${tasks}

---
严格按以下格式输出，不得有任何说明文字：

首先直接输出 Markdown 表格（按 ICE 总分降序，不要"第一部分"等前缀）：
| 决策事项 | ICE评分(I+C+E) | 优先级 | 精力负荷(高/中/低) | 下一步微小行动(<30min) | 导师洞察 |
| :--- | :--- | :--- | :--- | :--- | :--- |

然后空一行，输出（选 ICE 总分最高那条，不要"第二部分"等前缀）：
TASK_DATA: 决策事项名称 的下一步：微小行动`;

const response = await fetch(webhookUrl, {
  method: 'POST',
  headers: { 'Content-Type': 'application/json' },
  body: JSON.stringify({ prompt })
});

const result = (await response.text()).trim();
return result;
%>

对应的 n8n 工作流则负责接收、转发、提取与回写。结构上包含 Webhook、LLM Chain、DeepSeek Chat Model、Respond to Webhook、Code、IF 和 HTTP Request 几个节点。其中最实用的一段，是 Code 节点对 TASK_DATA 的提取：

const aiText = $input.first().json.text || $input.first().json.output || $input.first().json.response || "";
const match = aiText.match(/TASK_DATA:[ \t]*(.+)/);
const extractedTask = match ? match[1].trim() : null;

return [{ json: { extractedTask, hasTask: !!extractedTask } }];

真正耗时的地方，并不是“把节点连起来”，而是让整个系统变得稳定可用。

最先踩到的坑，是 DeepSeek 的格式遵从问题。它很擅长理解意图，但不天然擅长严格遵守格式。最初我把格式要求写在 system message 里，它几乎完全无视；后来把约束写进 user message，再明确要求“不要说明文字”“不要前缀”“空一行再输出 TASK_DATA”，输出才终于稳定下来。这个过程让我意识到：对于 DeepSeek 这类模型，很多时候不是“你有没有说清楚”，而是“你有没有把约束放在模型真正会认真读的地方”。

第二个坑，是 n8n 表达式求值。我一开始试图在 chainLlm 节点里直接拼接字符串，结果模型收到的是字面量变量名，而不是真实任务内容。更糟的是，模型会根据这些变量名自行编造任务，导致结果看起来像在正常工作，实际上完全跑偏。最终的解决方案很简单：别在 n8n 里做复杂 prompt 拼接，把 prompt 构建职责交给 Templater，n8n 只负责转发。

第三个坑，是 Obsidian 的 Markdown 表格渲染。最初我把整段 AI 输出都包在 callout 里，结果表格完全无法渲染，只显示原始管道符。后来才确认，Obsidian 的 callout 会把每行都视作引用块的一部分，而 Markdown 表格在这种结构里不会正常解析。解决方案是：把表格放在 callout 外，只把标题和提示性内容放进 callout。

第四个坑，是 副流程失败时的降级体验。如果 TASK_DATA 提取失败，但系统仍能返回 ICE 表格，那对用户来说其实已经足够有价值。因此我用 IF 节点把“回写任务”设计成可跳过步骤，让整个流程具备一定容错性。

一点补充

为了更直观地说明效果，下面是一次典型输入输出。

输入是日记里几条带 #decision 的任务：

- 基于LLM和n8n的行业情报与职位监控系统 #decision
- 之后可以通过n8n，实现博客到社媒内容的数据分发 #decision
- 利用Claude Code来实现自动化写作（调研—选题—……） #decision
- 写作：AI时代个人开发和团队协作之间的矛盾是不可逾越的吗？ #decision

几秒后，系统会返回一张按 ICE 分数排序的 Markdown 表格，并额外给出最高优先级事项的下一步行动；随后，n8n 还会把这条行动自动追加为待办任务。

这套系统上线后，最明显的变化不是“AI 替我决定了什么”，而是我不再需要把大量精力消耗在反复权衡上。原来可能要盯着列表纠结半小时，现在几秒就能获得一个结构化建议，再由我决定是否采纳。

如果继续扩展，这个系统还可以往几个方向走：

  • 支持更多决策模型，比如 RICE、四象限或 MoSCoW。
  • 接入更多数据源，比如邮件、Slack、GitHub Issues 或日历。
  • 增加决策历史分析，回看“AI 建议”和“实际执行”之间的偏差。
  • 如果更在意成本，还可以切换到本地模型、加入缓存或做批量处理。

也就是说，这个系统的价值并不只在于“做出一次判断”，而在于它可以逐步成长为一个更完整的个人认知辅助层。

结语 / 反思

这个项目的核心不是“让 AI 替我做决策”，而是让 AI 帮我快速完成评估过程，把认知资源留给决策本身。

决策疲劳的本质是：大脑需要在多个选项之间反复权衡，消耗大量认知资源。而 ICE 模型提供了一个结构化的评估框架，AI 可以快速完成这个“打分”过程，让我更快看到哪个任务的综合得分最高。

但最终的决策权仍然在我手里。AI 给出的建议只是一个参考，我仍然可以根据当下的状态、精力和环境做调整。工具的价值，不是替代思考，而是释放认知资源。

在 AI 时代，我越来越相信个人效率工具最重要的不是“大而全”，而是“小而美、可控、可扩展”。这个“决策助手”只是一个起点。未来，我还会继续探索如何用 AI 与自动化工具，为自己构建更多真正减轻认知负担的系统。