从任务和付费主体开始

成熟平台已经聚集用户、数据、工作流和交易，也留下许多没有被主产品细致处理的任务。模板、插件、开源项目和垂直应用都可以从这些缝隙进入。平台的用户很多，只能说明潜在人群上限较高；一个具体机会能否成立，还要看目标任务、付费主体、现有替代、接口能力、分发位置、维护成本和退出路径。^[1][2][3]

选择入口时，先回答一个简单问题：哪一类用户正在平台里反复完成什么任务，当前方法为什么仍然费时、容易出错或无法衡量？答案越具体，越容易判断该做模板、插件、服务、开源项目，还是一款独立的垂直应用。

生态研究常从「Notion 有多少用户」「Shopify 有多少商家」「Chrome 有多少安装」开始。这些数字适合描述背景，无法直接证明可达市场。真正需要测量的是多层交集：

平台活跃用户 × 目标角色 × 高频任务 × 当前摩擦 × 付费意愿 × 可触达方式

ReadNotion 的案例很清楚。这个产品连接用户已有的 Notion database，在 iOS 上改善稍后阅读和快速记录体验。潜在人群只包括同时使用 iOS、已经把内容保存进 Notion、又确实存在移动阅读摩擦的那部分用户。若用户原本不用 Notion，还要先说服他采用底层平台，再说服他使用 ReadNotion，获客难度会明显增加。^[4]

因此，平台依附型产品应先区分两种路径：

• 改善既有行为：用户已经在平台完成任务，只是步骤太多、速度太慢或结果不稳定；
• 创造新的前置行为：用户要先采用底层平台、迁移数据或改变团队流程，才能获得产品价值。

前一类通常更容易验证。后一类未必不能做，但需要把教育、迁移和组织阻力计入成本。

付费主体也要单独确认。使用插件的员工、批准安装的管理员、承担费用的公司和受到结果影响的客户可能是四类人。模板购买者可能是个人，咨询项目的决策者可能是团队负责人，Shopify App 的操作者可能是运营人员，付费者却是商家老板。产品页面只说服使用者，往往不足以完成交易。

五种经营形态对应五套责任

平台生态里常见的经营形态可以放在一张表中比较：

技术门槛较低的产品也可能需要大量经营工作。模板减少了服务器和代码维护，仍要承担选题、示例、说明、版本兼容、客户教育、内容获客和退款。插件交付更自动化，却要持续处理 API 变化、权限、错误状态和客服。咨询客单价可能更高，但可复制性和交付容量受人力限制。^[2]

判断「轻」或「重」时，应把构建、交付、获客、支持和退出分别核算。只比较开发时间，很容易低估后面四项。

用一张机会卡筛选平台缝隙

每个候选机会都可以按九项记录：

1. 核心用户：谁每天或每周遇到这个问题；
2. 任务频率：问题多久发生一次；
3. 现有替代：表格、人工、平台原生功能和竞品分别怎么处理；
4. 可量化结果：节省时间、增加订单、减少错误、提高转化或降低成本；
5. 付费主体：谁批准、谁付款、预算从哪里来；
6. 接口条件：需要哪些 API、权限、数据和审核；
7. 分发入口：应用市场、模板市场、搜索、社区、伙伴或直接销售；
8. 持续成本：支持、托管、模型、数据、退款和平台更新；
9. 退出路径：平台变化或产品停止时，用户怎样导出数据、取消权限和迁移。

成熟类目还要加一项：迁移阻力。评价、积分、物流、邮件等大类往往已有深度嵌入的产品。新产品即使功能更多，商家也可能因为历史数据、工作流、员工培训和风险而不迁移。资源有限时，可以按品类、经营阶段、地区或某条工作流继续收窄，但「窄」仍需验证容量和持续性。^[3]

模板适合先验证结构化结果

模板适合输入和输出相对稳定、用户能够自行完成配置的任务。例如个人记账、项目管理、内容日历或客户跟进，可以先把字段、视图和操作顺序做成一套可复制结构。

一名创作者最初经营 Notion Converter，解决从 Notion 向公众号复制和排版的问题。早期他按少数用户的要求增加自定义 CSS、图片等能力，后来重新聚焦每天发布内容、真正被排版效率困扰的号主，把差异集中到「普通人直接可用、样式清楚」。这个复盘说明，用户请求应先记录，再用核心用户的频率、差异价值和维护成本决定是否实现。^[2]

随后他从插件转向模板，原因包括技术与合作依赖、插件客服和维护负担，以及希望把更多时间用于内容和分发。这个选择适合他的能力和目标，不构成「模板一定优于插件」的结论。^[2]

模板验证可以先做四件事：

• 找三到五名目标用户，观察他们怎样完成任务；
• 用真实样例填满模板，检查空状态、异常输入和长期使用；
• 让用户在没有陪同的情况下复制、设置并得到结果；
• 记录从获取到使用、完成核心任务、求助和退款的每一步。

截至 2026 年 8 月，Notion Marketplace 已支持模板、创作者和咨询伙伴。当前 Marketplace 条款要求发布者拥有必要权利、提供真实准确的信息，并对付费模板提供持续且商业上合理的支持；Notion 也保留审核、安全与隐私检查以及移除作品的权利。平台内销售、支付、费用和外部引流限制属于动态规则，实际发布前需要逐项核对。^[5]

模板减少的是一部分技术维护，没有消除经营责任。

插件要解决平台原生能力之外的动作

插件或 Extension 更适合模板难以完成的任务：跨页面采集、批量处理、实时同步、自动触发、权限控制或多个系统之间的数据连接。

插件立项前应画出一条完整路径：

触发位置 → 授权 → 读取数据 → 处理 → 写回 → 用户确认 → 错误恢复 → 卸载

每个箭头都可能产生支持成本。只演示成功路径，会遗漏授权失效、字段变化、限流、重复写入、网络中断和第三方数据删除。

一个适合早期验证的方法，是先从主产品拆出一个完整可用的免费任务。例如浏览器 Extension 可以帮助用户在当前页面完成一次压缩、提取、保存或格式转换，再把确有后续需求的人带到主产品。免费工具必须来自真实任务，并且自身能够完成承诺；若只是为了制造商店页、关键词或程序化页面，用户很快会发现它没有独立价值。^[6]

Chrome Web Store、Notion Marketplace 或其他商店的关键词、评论和竞品页面可以用于研究。购买账号、刷假评论、隐藏链接、绕过审核和操纵评分应排除。分发效率不能建立在账户和品牌风险上。^[6]

API 可用不代表产品能够稳定经营

API 文档说明「可以调用什么」，产品还要处理权限、限流、版本、删除、审计和成本。进入某个平台前，至少做一次技术风险清点：

• 最小必要权限是什么；
• 用户是否理解授权范围；
• 哪些数据会进入自己的服务器；
• API 是否有频率、分页、大小或历史范围限制；
• 平台怎样发布破坏性版本；
• Webhook 丢失、重复或乱序怎样处理；
• 用户撤销授权或卸载后怎样停止任务和删除数据；
• 核心接口关闭后是否还有降级方案。

Notion 当前 API 文档显示，连接存在请求频率和参数大小限制，遇到 429 时应遵守 Retry-After；SDK 和 API 会进行版本升级，较新的 major SDK 可能不再兼容旧 API 版本。具体限制和版本会继续变化，因此队列、退避、契约测试和升级窗口应从第一版进入设计。^[5]

平台依赖还包括审核和市场可见性。即使 API 继续工作，应用可能因列表规则、权限要求、性能或支持问题失去分发。技术可行性和渠道可持续性要分别评估。