有条件的工具选择

工具怎么选：先看任务，再看迁移成本

按真实交付任务比较设计、笔记、部署、AI、编程、云存储与 PDF 方案。先选择需要比较的工具，再看看它们分别适合哪些任务、有哪些使用限制，以及如何判断哪个更适合你。

先确认无法妥协的条件，再比较候选工具的适用场景、交接方式和限制。选择一组对比后，可以直接在下方记录自己的判断。

Canva 与 Figma：内容设计还是产品界面？

如果交付物是活动海报、社媒配图、简单演示文稿，而且主要由非设计人员修改，通常先从 Canva 入手。若要维护应用界面、跨屏组件、交互原型，并与开发一起讨论布局与状态，Figma 更切合工作流程。

判断维度	Canva 更合适的情况	Figma 更合适的情况
最终交付	宣传图、简报、社媒素材	界面稿、组件库、交互原型
主要使用者	运营、营销、需要快速改稿的团队	产品设计、设计系统维护、研发协作
重复修改	以模板和尺寸变体为主	组件状态、响应式布局和页面之间的关系
交接风险	需要确认品牌素材与导出文件能否被下一位编辑	需要维护组件命名、权限和设计交付规范

容易选错的情况：把简单宣传图做成一套复杂 UI 组件，会增加学习成本；把大型产品的交互稿散落在海报模板中，则会使开发交接很困难。可以先用一份真实交付物试做，不要只看模板数量。

了解 Canva · 了解 Figma · 查看图片制作路线

要交付一组社媒图片，而不是 App UI

一个三人运营小组要连续发布 12 张不同尺寸的宣传图，后续由非设计人员替换文案。先测试模板编辑、共享权限、导出尺寸；不必因为 Figma 的组件能力更丰富，就把它当成默认首选。若要交付开发人员可复用的界面状态和交互规格，再测试 Figma 的组件与交接方式。

验收：其他同事能在不重新设计的情况下修改文字并正确导出。

Notion 与 Obsidian：共享工作空间还是本地知识库？

Notion 更适合多人维护项目资料、数据库和共享文档；Obsidian 更适合以本地 Markdown 为核心、由个人长期组织知识的方式。二者不是严格替代品：团队项目管理和个人研究笔记完全可以分开处理。

判断维度	Notion 优先考虑	Obsidian 优先考虑
主要目标	团队文档、任务信息、多人协作	长期笔记、知识链接、文件可控
内容组织	页面与数据库视图	Markdown 文件、内部链接与文件夹
协作	多人共同维护是核心需求	以个人编辑为主；协作需另行设计
迁移重点	数据库关系、权限、附件与导出格式	文件路径、插件依赖、图片附件和同步方案

先做一个小样：将同一组会议纪要、研究链接和待办分别整理一次。检查找回旧资料是否顺手、附件是否容易管理、别人能否继续维护。不要把“功能更多”直接等同于“更适合”。

了解 Notion · 了解 Obsidian · 查看笔记工具指南

知识库是给团队共同维护，还是给个人长期积累？

需要跟踪负责人、会议结论和共享表格时，先用一个小团队项目试 Notion；重点测试权限与成员离开后的交接。积累多年个人笔记时，可用 Obsidian 建立一个本地 Markdown 样本库，检查链接、图片附件以及导出后是否仍可读。

验收：换电脑或换人接手后，资料结构和关键附件仍然完整。

查看知识管理任务

离线编辑不是二选一的唯一标准

Notion 已支持在桌面和移动应用中将页面标记为离线可用，并在恢复连接后同步修改；需要提前下载页面，数据库行和子页面也有离线范围限制。Obsidian 的核心是本地 Markdown 文件，但多人同步、插件依赖和数据迁移仍需检查。不能再用“Notion 完全无法离线”作为选择理由。

从 Notion 迁往 Obsidian 时，官方 Importer 提供账号连接和 ZIP 文件两种路径；两种方式对数据库结构的保留不同，迁移前应先试一个含附件和数据库的小样。Notion 离线功能说明 · Obsidian 导入说明

Vercel 与 Netlify：先看构建方式，而不是平台名气

纯静态 HTML/CSS/JS 站点在两种平台上都可以考虑部署，优先检查发布目录、自定义域名、预览与回退。遇到框架服务端渲染、Serverless 函数、后台任务或数据存储时，应先确认项目实际要求，再查看平台当前文档。

项目情况	建议比较的关键问题	不要忽略
纯静态展示站	上传方式、构建输出目录、重定向、版本回退	ZIP 根目录、资源相对路径、404 响应
基于框架的站点	框架适配、服务端运行方式、环境变量	构建与预览行为是否与正式环境一致
带 API / 数据的应用	运行时、函数限制、数据库连接、日志	不要假设静态托管能替代长期运行的服务

选择办法：用当前项目在候选平台分别完成一次构建和回退，把需要手工配置的步骤、团队成员权限以及运维负担记录下来。没有这一步，就不应该给出哪个平台“更快”“更稳定”的绝对排名。

了解 Vercel · 了解 Netlify · 查看网站发布路线

纯静态网站不必先争论平台排名

已有 index.html、CSS 和图片的宣传站，可以分别在候选平台做一次预览部署。比较发布目录设置、环境变量需求、域名接入、构建日志与回退操作。若项目依赖服务端运行、队列或持久数据库，先列出后端依赖，再确认平台对该运行模式是否适用。

验收：预览链接、资源路径、404 页面与版本回退都能按预期工作。

使用网站发布清单

Next.js 项目要比较服务端适配方式

两个平台都可运行 Next.js，但不是完全相同的部署运行时。Vercel 使用自家的原生 Next.js 集成，Netlify 通过 OpenNext 适配器运行相关服务端功能。遇到中间件、缓存、后台任务和函数区域等需求，先按当前框架版本核对支持情况，再试一次预览构建与回退。纯静态 HTML 项目通常无须为这些服务端差异增加复杂度。

Next.js 平台适配比较（Vercel 官方资料，2026 年 7 月更新）。该资料由 Vercel 发布，对自家平台的评价应视作厂商立场，而非独立测评。

AI 对话：ChatGPT、Claude 与 Gemini

先分清是写作讨论、长文档整理，还是需要接入自己已在使用的 Google 工作流。三者都不能代替事实核验。

判断维度	ChatGPT	Claude	Gemini
起点与工作流	适合把需求拆成多轮对话、逐步修改文本或方案	适合整理较长资料并针对文档提出追问	适合先测试与既有 Google 工作流程的衔接
共同限制	答案可能不准确；文件及工具能力取决于当前账号和配置	长上下文不代表自动理解全部细节；需要抽查遗漏	集成范围及地区、账号限制可能变化，使用前应核对
测试方法	用同一份材料输出提纲、问题清单和风险点	比较能否保留材料中的重要数字、例外和出处	检查是否确实减少在现有工具间切换的步骤

ChatGPT · Claude · Gemini · AI 对话专题

查看研究资料路线

同一材料做有出处的事实提取

准备样本：准备不含隐私信息的会议纪要，故意加入两处未决定事项、一处没有负责人的任务和两组不同日期。给候选工具相同提示词。

记录结果：逐条核对输出是否把“讨论”误写为“决定”、是否凭空指派负责人、是否遗漏相互矛盾日期。将每条输出对应到原文段落。

不要误判：语言更流畅并不代表提取更准确；联网搜索和提供文件内证据也不是同一个任务。

AI 编程：Copilot、Cursor 与代理式开发

不要再把 Copilot 简化成“只会补全”

Copilot 已支持在 IDE 内通过 Agent 模式跨文件修改、执行命令。因此选型时应实际比较权限控制、代码差异、命令确认、测试通过情况以及与当前编辑器的配合，而不是按“Copilot 只补全、其他工具才有代理”划分。

GitHub Copilot 官方文档 ↗

这三类并非互斥。区分编辑器内辅助、跨文件修改与将任务委托给代理，比笼统问“谁最强”更有用。

判断维度	编辑器内辅助	仓库级编辑	代理式任务执行
适合的任务	日常补全、解释局部代码、编写测试草稿	理解已有仓库并修改多处关联文件	拆分并执行较完整的开发任务
前提	已有代码基础与现成编辑器工作流	明确仓库范围，能审查变更 diff	隔离执行环境，限制密钥、终端和外部访问权限
最关键的检查	建议是否通过测试和代码审查	是否改动无关文件、破坏接口或依赖	是否提供过程记录、测试结果和可回滚提交

AI 编程工具专题 · GitHub · VS Code · 交付检查清单

查看网站开发路线

用同一段真实代码衡量可维护性

准备样本：准备一个不含密钥的小型仓库：包含一个失败测试、两个有关联的模块和简短 README。给每个候选方案相同的任务：“修复失败测试，不改变公开接口，解释修改原因”。

记录结果：先记录基线提交与失败日志；分别保存工具生成的差异文件、执行的命令及测试输出。最后由同一位审查者按“功能正确、改动范围、可解释性、需要人工修复”四项评估。

不要误判：不要使用不同难度的任务进行横向比较；代理能自动运行更多步骤，也意味着应额外检查审批和执行边界。

云存储：Google Drive 与 Dropbox 的选择

不要只看免费空间。先搞清楚你需要在线协作文档、跨设备同步文件，还是可独立恢复的备份。同步删除不等于备份。

判断维度	Google Drive	Dropbox	本地/独立备份
任务倾向	已有 Google 文档、表格和共享协作流程	以文件同步和跨设备共享为核心	需要在误删、勒索软件或账号丢失后恢复
风险点	共享链接和组织权限需反复确认	版本历史及可恢复期限应检查当前方案	须有独立存储与恢复演练，不能只保留一份副本
试用办法	测试团队接手和权限撤销	测试大文件同步冲突与离线恢复	随机恢复一份文件并记录所需时间

Google Drive · Dropbox · 云存储专题 · 同步与备份指南

使用工具迁移清单

用共享文件夹检验交接与恢复

准备样本：建立测试目录：一份普通文档、一张图片、一份不同成员可编辑的文件。让第二位参与者以外部账户访问，测试编辑和只读两种权限。

记录结果：记录链接是否需要登录、权限撤销后是否还能访问、离线改动是否产生冲突。独立删除一个测试文件，从明确的备份副本恢复并确认内容完整。

不要误判：共享文件的历史版本、同步冲突与灾难恢复是三个不同能力；不要用“上传成功”代替恢复验证。

PDF 工具：在线操作、桌面处理与转换平台

PDF 的“压缩”“转 Word”“OCR”“合并”是不同任务。真正决定工具选择的还有文件敏感度、是否需要批量处理、结果是否可校对。

判断维度	在线 PDF 工具	格式转换平台	本地处理
适合情况	少量普通文件的合并、拆分或压缩	在 PDF、Office、图片格式间转换	机密文件、可审计流程或大量重复操作
首要风险	上传前确认服务的文件处理条款	复杂版式和公式、表格可能变化	安装与更新、输出格式检查由使用者承担
完成判断	页序、方向、签章与附件未丢失	抽查版面、数字、可复制文字与字体	保留原件并能复现同样处理结果