AI 圈每个月都会冒出一打新工具。从网页套壳、聚合客户端，到各类号称自动搞定一切的 Agent 平台，试过一圈后发现，大多数工具的寿命只有两个周末。工具越多，配置、同步和排障占用的时间反而越长。

现在我把日常工具压到只剩几款。它们各有明确分工，彼此之间不重叠，也能长期稳定工作。

留在桌面上的清单

编程与仓库维护：OpenCode 与 Cursor

我在处理代码时只用两个工具，分工界限非常清晰。

OpenCode：项目级维护

写博客、改配置、跑测试和推送代码，我全部交给 OpenCode。它直接跑在终端里，具备完整的文件树读写能力、命令行调用能力，还能结合 Skills 保持稳定的项目规范。

它的长处在于连贯执行完整链路：

1. 扫描博客现有文章，寻找标题或标签命名冲突。
2. 按照给定的规则新建 Markdown 或 MDX 文件。
3. 检查文章引用的封面图片是否存在于 src/assets/images/。
4. 调用 bun run build:site 检验 Astro 页面是否生成成功。
5. 查看 git status 与 git diff，执行 git commit 并推送到远程仓库。

这一套动作如果放在普通网页聊天框里，我需要来回复制粘贴五六次代码，还要在终端手动跑命令。OpenCode 把这一层手动搬运省掉了。

Cursor：单文件细致雕琢

当我需要手动调整一个复杂的 Svelte 5 动画组件，或者微调某些 CSS 布局时，Cursor 更趁手。它的视觉反馈直接嵌在编辑器里，点击代码行就能唤出行内编辑，比起纯文字描述改动要快得多。

我不让 Cursor 去接管整个项目的自动化运维，也不用 OpenCode 去一字一句手调 CSS 像素。工具各自守在最适合的位置。

本地模型：RTX 5060 8GB 上的 Ollama

我的台式机装了一张 RTX 5060 8GB 显卡。8GB 显存很诚实：它跑不了大模型，但跑小型量化模型刚刚好。

我使用 Ollama 管理本地模型：

# 运行 7B/8B 量化模型
ollama run qwen3:8b

# 运行轻量代码模型
ollama run qwen2.5-coder:7b

在本地跑模型，我有三个固定的规则：

• 只选 Q4_K_M 或 Q5_K_M 量化：显存占用控制在 5.5GB 到 6.5GB 之间，留出 1.5GB 给显示器和操作系统。
• 不强上 14B 模型：14B 模型在 8GB 显存下必须把部分层卸载到 CPU 和系统内存，速度会从 45 tokens/秒暴跌到 8 tokens/秒以下，体验并不实用。
• 只派发合适任务：本地模型负责文本格式转换、草稿错别字初筛、不联网的代码小片段生成。需要复杂推理或最新世界知识时，直接调用云端模型。

本地模型最大的价值不是性能多强，而是离线可用、零 API 成本，并且不产生任何数据出境隐私问题。

资料检索与事实查验：Perplexity 与 NotebookLM

很多人习惯直接问通用聊天模型“某某显卡首发价格是多少”，然后得到一个张冠李戴的答案。语言模型是概率文本生成器，不是带审计追踪的搜索引擎。

Perplexity：核查外部事实

只要涉及具体的发售日期、法规文件、公司公开财报或历史事件，我一律转去 Perplexity。它的特点是每一句话都带标注引用来源：

• 可以直接点击角标查看原网站。
• 能一眼分辨信息来自官方公告还是论坛灌水。
• 能够把矛盾信源摆在同一个回答里供用户对比。

写科技观察或产品对比文章时，Perplexity 是我查验事实的第一站。

NotebookLM：封闭材料精读

当你手头有五份产品的官方 PDF 手册、三篇长技术文档，想搞清楚它们在某项技术规范上的差异时，开放网页搜索帮不上忙。

NotebookLM 的逻辑是“只依据我上传的文件回答”：

• 上传指定材料后，它不会从互联网上胡乱检索无关信息。
• 回答中给出的引文直接定位到 PDF 的页码和段落。
• 不会把别的产品参数硬塞进当前文档的结论里。

这把大模型的注意力严格限制在可靠证据内部，彻底避开了开放域幻觉。

写作与构思：Claude 与 ChatGPT

构思一篇两三千字的文章时，我主要借助 Claude。

我不让它替我生成整篇文章然后直接发布，那样产出的文章全是空话套话。我用它的方式是三步走：

1. 碰撞提纲：我抛出原始经历、争议点和核心观点，让它从反面挑刺，检查论证有没有漏洞。
2. 提取细节：让它帮我列出该话题下容易被遗漏的技术指标或常见误区。
3. 自己动笔与收敛：我自己把控文章结构和语言节奏，遇到过长或者逻辑绕弯的段落，再交给它进行单段润色。

让模型当批判者和反光镜，比让它当打字员更有价值。

我主动淘汰掉的工具

1. 各类套壳聊天客户端

市面上有很多套壳客户端，界面花哨，号称支持几百个模型。用了一阵子后我全删了。它们的主要问题是版本更新后经常断流、配置项繁杂易丢、很多甚至不支持流式传输的断点恢复。换回官方 Web 或标准 CLI，稳定性高出几个量级。

2. 重型本地个人知识库

我曾花几天时间搭建过包含向量数据库、切片清洗、BM25 重排的完整自托管 RAG 系统，试图把平时的日记和笔记全存进去。最后发现维护成本远大于实用价值：每次写了新 Markdown 都要重新切片嵌入，检索出来的段落经常脱离上下文。现在我只保留清晰分类的本地 Markdown 目录，配合编辑器的全局搜索，反而比向量检索又快又准。

3. 全自动自媒体生成平台

“一键输入主题生成短视频”“一键爬取热点生成文章”的工具，产出内容充斥着机器腔调和陈词滥调。这种内容既没有个人思考，也经不起读者推敲，只制造信息垃圾。

工具组合的四条原则

折腾了一大圈，我总结出四条筛选工具的原则：

• 只解决具体断点：如果一个工具不能把某个具体的痛点（如编译验证、事实查证）时间缩短一半以上，就不装。
• 数据保留在纯文本中：我的所有文章和笔记都是标准 Markdown 文件。任何把数据锁在私有数据库或私有格式里的工具一律不用。工具可以随时换，文章数据必须一直属于自己。
• 本地硬件不逞强：8GB 显存就老老实实跑 7B 模型，绝不折腾超出硬件负荷的架构。
• 发布环节必须人工把关：不论工具链自动化程度多高，代码提交、文章上线、数据引用的最后一步，永远由我自己眼睛看一遍。