我为什么想做这个产品
前段时间我陆续看到不少把 Markdown 文档转换成分享卡片的产品，用下来感觉都挺有意思。这个思路本身其实很简单，就是把一段原本普通的信息，变成一个更适合传播、看起来更完整的视觉卡片。
但回到我自己的日常使用场景时，我很快发现了一个错位点：我平时并不只是保存或分享 Markdown，我分享得更多的其实是网页。博客文章、产品介绍页、文档、新闻、还有各种想顺手发给朋友的链接，几乎都是网页。
而网页的默认分享方式，直到今天依然有点过于粗糙。要么就是把一串裸链接直接扔进聊天窗口里，要么就是截一张包含大量无关界面的截图。它们当然也能用，但并不舒服，也不够体面。Bear.Share 最早的出发点其实就这么直接：我想更快地把一个网页，变成一个可以拿去分享的东西。
真正要解决的问题是什么
乍一看，这好像只是一个“美化分享”的小需求。但如果往里拆，会发现它其实是一个挺典型的产品问题：
- 裸链接几乎没有视觉层次。
- 普通截图往往带进太多无关信息。
- 不同网站的结构差异很大，很难靠一种固定布局适配所有网页。
- 当你只是想快速分享时，哪怕流程稍微复杂一点，都会让人懒得用。
所以真正的难点不是“把网页做成卡片”这么简单，而是：怎样从任意网页中提取出足够有用的信息，再把它整理成一个看起来有设计感、信息足够清晰、而且快到让人愿意反复使用的结果。
一开始我给自己设下的限制
这是我第一次正式做浏览器扩展，所以我一开始就告诉自己，范围一定要收紧，不能把项目做成一个越滚越大的东西。最初我给 Bear.Share 设下了几个很明确的限制：
- 它必须是一个轻量的浏览器扩展，而不是一个独立的 Web 应用。
- 交互入口必须足够快，最好接近一键启动。
- 输出结果要能够在风格差异很大的网页之间保持基本一致。
- 功能范围必须小到足够快上线。
- 尽可能保证隐私友好，能本地处理的就不要绕到服务端。
最后这一点我很在意。一个用于分享网页的工具，不应该悄悄演变成收集网页数据的通道。
我是怎么推进这个项目的
这次我没有把它当成一个需要长期打磨的大工程，而是更像一个边界明确的小型产品冲刺。先做一个最小可用的原型，再借助 AI 辅助开发，去加速那些本身并不值得手搓太久的部分，比如工程初始化、重复性的配置、Manifest 调整，以及交互细节上的快速迭代。
整个开发过程大致是这样的：
- 先定义最小可用的分享流程。
- 打通网页信息提取和卡片渲染链路。
- 拿真实网页反复测试。
- 哪里用起来别扭，就继续减阻力。
- 在产品开始失控膨胀之前，先把它发出去。
听起来像是标准流程，但真正花时间的都在中间。真实网页太不统一了，标题有时过长，元信息有时残缺，预览图也不一定好看，而且不同类型的网页适合的布局重点完全不一样。
几个关键的产品决策
1. 模板数量比我最初想象中更重要
一开始我以为只要做出一种足够好看的卡片布局就够了，后来发现并不是。
不同的分享场景需要的重心并不一样。有时标题应该最突出，有时预览图更重要；有时希望整体极简、中性，有时又希望更适合发到社交媒体上。
所以 Bear.Share 最后没有走向“唯一标准模板”，而是做成了多种卡片样式并存。这不是为了让功能看起来更多，而是为了让不同内容都能有一个更合适的呈现方式。
2. 二维码其实比“酷炫”更实用
后来我自己也觉得特别有价值的一个功能，是二维码。
它听起来并不花哨，但实际使用里非常顺手，尤其是桌面端生成内容、移动端扫码查看这种场景。很多时候，真正长期有价值的功能并不是最容易拿来宣传的那个，而是那种一旦出现，你就会觉得“这个就该有”的东西。
3. 个性化必须有边界
我当然希望用户可以加入自己的签名、落款或者一些轻度定制，但我并不想把它做成一个完整的设计编辑器。那样一来，这个产品就会立刻变成另一个类别。
所以我的取舍是：提供有限但足够有用的个性化能力，让结果有“自己的味道”，但又不至于让用户在分享一个网页之前，还得先扮演一轮设计师。
最难的地方反而不是写代码
真正麻烦的其实不是开发本身，而是克制。
这种工具类产品很容易一路膨胀出一个没完没了的功能清单：
- 更多模板
- 更多排版控制
- 更多导出方式
- 更多元信息覆盖能力
- 更多平台定制样式
这些想法单独看都很合理，但问题在于，它们会不断拉高复杂度，让“简单好用”这件事越来越难保住。
因为我想让 Bear.Share 尽快上线，所以我在开发过程中不断反复问自己一个问题：这个功能到底是在强化核心体验，还是只是让产品在纸面上看起来更完整？
这个问题帮我砍掉了不少也许以后可以做、但不适合在第一版就塞进去的东西。
3 天上线，真正有价值的不是“快”
3 天做完并上线，听起来像是一个很戏剧化的时间点，但我后来觉得，真正值得总结的不是“速度本身”，而是为什么能快。
之所以能快，是因为问题足够聚焦，产品边界足够明确，同时我没有把第一版硬做成第五版。
这个短周期反而逼着我做出了更有纪律的决策：
- 主流程优先，边缘情况先放后面。
- 接受“足够好，可以拿出去验证”的状态，而不是理论上的完美。
- 先用真实网页去验证，而不是沉迷于打磨抽象层。
从这个角度看，3 天并不只是一个时间限制，它本身就是产品策略的一部分。
分享入口为什么做成两种
最后 Bear.Share 的分享界面支持两种启动方式：浏览器扩展图标，以及右键上下文菜单。
这件事看起来小，但其实很重要。因为一个功能如果入口太深、步骤太多，再强也很难形成高频使用习惯。很多时候，产品是否“顺手”，决定因素就是这些看上去不起眼的路径设计。
这个项目给我的一些启发
这个小项目虽然不大，但还是让我再次确认了几件事。
好产品常常起点只是一个“默认方案太丑了”
Bear.Share 的机会点，并不是什么特别宏大的技术想象，它只是来自一个很朴素的现实：现在很多网页分享方式，看起来真的不够好。
AI 最有价值的时候，是方向已经清楚的时候
AI 的确帮我加快了开发速度，但它并没有替我决定要解决什么问题，也没有替我划清边界，更没有替我定义这个产品最终应该是什么气质。真正重要的判断，还是得自己来做。
小工具最怕失去边界
我现在越来越觉得，Bear.Share 之所以成立，恰恰是因为它是一个边界清晰的小工具。如果它变成一个大而全的“内容设计平台”，反而会失去现在这个产品最重要的价值点。简单，不只是外观风格，也是一种产品承诺。
接下来我还想继续优化什么
这个产品当然还有不少可以继续打磨的方向：
- 对复杂网页做更聪明的信息提取
- 更好地处理那些不规范的元数据
- 针对不同分享场景做更细的模板设计
- 继续优化导出、复制和分享链路
但即便后面继续增强能力，我也还是希望它保持轻量。这是我最在意的平衡点：让它变得更强，但不要变得更重。
如果你也有分享网页的需求
如果你平时也经常分享网页，觉得裸链接太单调，或者截图又太粗糙，可以试试 Bear.Share：
Chrome 商店地址：
Bear. Share - 网页分享卡片生成器
如果你真的用上了，我其实也很想知道，你最在意的是哪一点：更干净的视觉呈现、二维码这个细节，还是那种“几秒钟就能把网页变成可分享内容”的顺手感。