产品设计与原型验证
确定 WebpageToPDF 的产品方向、首版范围和 PDF 转换方案。
这一篇从市场调研开始，逐步确定产品范围，再通过技术原型验证实现方案。
市场调研
做产品不能只凭一个模糊的想法就开始写代码。至少要先弄清楚：谁会用、在什么情况下用，以及现有产品还有哪些问题没有解决。
从域名也能看出来，这次要做的产品是一个网页转 PDF工具：用户输入网页地址，服务端完成转换，然后提供 PDF 文件下载。
我先看了“webpage to pdf”这个关键词的搜索结果。这个词有一定的搜索量，但并不好做。排在前三的都是经营多年的大站，外链多，域名权重也高。一个新站短期内基本没有机会和它们争前三，能先进入前十就已经不错了。
前十名包括 Reddit 帖子、两个 Chrome 扩展、一款应用程序以及三个在线转换工具。这说明用户搜索“webpage to pdf”时，找的未必只是在线工具，也可能更想要一个浏览器扩展或桌面应用。
webtopdf
我分别试用了排名靠前的几个产品。Webtopdf 提供的选项最丰富，整体使用体验也不错。
它的转换结果基本可用，而且似乎会主动处理 Cookie 同意弹窗之类的干扰元素。不过，生成结果偶尔会变成移动端布局：
上图右侧的菜单在桌面页面中默认并不会出现，可能是转换时页面还没加载完，正好截到了中间状态。除此之外，有些页面还会出现排版错乱。
ilovepdf
iLovePDF 提供的转换选项同样比较完整。它有一个很实用的功能：转换前可以预览当前页面的效果。这个预览看起来更像是浏览器截图，用户只能查看，不能直接编辑页面。
从转换结果来看，iLovePDF 对原网页的额外处理比较少，基本是按页面原样生成 PDF，Cookie 同意弹窗等无关元素也可能被一并保留下来。
web2pdfconvert
Web2pdfconvert 是这几个产品里最让我意外的一个。它的页面很简洁，选项却不少，还支持把文件保存到第三方网盘。更重要的是，它生成 PDF 的效果最稳定，也是这次测试中表现最好的。
它更像是 ConvertAPI 的在线演示页，页脚也写明转换功能由 ConvertAPI 提供。如果自研效果不理想，服务端直接接入它确实省事，但商业授权不便宜，长期使用会明显抬高单次转换成本。
我也试了几个排名更靠后的产品，整体效果差距很大。把这些产品放在一起比较后，可以得到三个比较有用的结论：
- 导出的 PDF 基本都能选中文字，说明主流产品并不是先把网页截成图片，再把图片塞进 PDF。我最初考虑过这种方案，但它会丢失文本选择、复制和搜索能力，不适合作为主要实现方式。
- 很少有产品主打批量转换，这可能是一个值得继续验证的方向。
- 纸张大小、横竖方向、背景和页边距已经是常见功能，只靠增加这些选项很难形成差异。相比之下，转换前预览以及对结果的调整，更有可能改善实际体验。
从商业角度看，网页转 PDF 并不是一个特别理想的方向。排名靠前的网站都已经做了很多年，域名老、外链多、权重高，转换效果也不错，很难超过。更麻烦的是，这个关键词非常垂直，搜索量并不大：
即使做到第一名，能够获得的流量也比较有限。目前排名第一的网站已有 20 年左右的域名历史，月访问量也只有约 40 万。
也就是说，这个方向既难做，流量上限又不高，不能指望它赚多少钱。不过，我做这个项目本来也不是为了赚钱，而是想完整展示如何用 Saavo 开发并上线一款真实产品。域名已经买了，那就继续做，只是别抱太高的预期。
我还把相关关键词导出来交给 AI 做了一轮分析，它给出的判断比较乐观，我个人持怀疑态度，这些关键词的平均 DR 大约在 40～55，新站上线后很难快速看到效果。
产品设计
真实的市场调研肯定比我上面的更详细更完整，我们这里就不进一步展开了。市场调研决定了做不做这个产品，以及产品的大致方向，如果这是一个充分竞争的市场，那么你的那些竞争对手的网站不管从功能上还是设计上，都比你做得好，那么你做这个产品可能就没有什么意义了。
你要考虑自己能否在这些竞争对手中脱颖而出，不仅仅是功能上的突破和完善，更重要的是设计上的创新和用户体验的提升，这些都很重要。因为这些网站不管是在建立时间，又或者是用户基础上都比你强出几个量级，所以你短时间很难从排名上压制它们，甚至有可能连前十都进不去。即使你的网站功能更强，设计更美观，用户体验更好，你也需要时间来积累用户和品牌影响力，这是不可避免的。
在做市场调研的时候你就应该考虑到这些问题，如果你在功能上做得还不如它们又或者和它们差不多，基本上就可以直接放弃了。只有你比它们做得更好，才有可能在这个市场上取得一席之地，也才需要进一步考虑如何设计你的产品。
产品设计的核心其实就是决定你这个产品要做什么，以及怎么做，第一版又应该做到什么程度。
在目前的 Google 搜索结果中，Web2pdfconvert 的使用体验明显好于 Webtopdf，排名却不如后者。原因肯定不只一个，但页面内容多少应该也有影响。Web2pdfconvert 的页面太干净，文字内容很少，搜索引擎很难判断它到底提供了哪些功能。Webtopdf 的介绍更完整，看起来也更专业，接下来我的网站可以参考这个思路来设计。
网站初期只做一个首页。页面上半部分直接放转换工具，让用户打开就能用。下半部分再介绍产品功能、使用场景和常见问题，补充 SEO 需要的文字内容。配色尽量简单，不要抢工具的风头。参考的网页布局是 ahrefs 的那些免费工具页面。
搜索结果中出现了两个 Chrome 扩展，也说明一部分用户更希望在浏览网页时随手完成转换。后续可以考虑做一个扩展，既方便使用，也能给网站引流。不过，第一版先不做，免得一下子把摊子铺得太大。
功能上的差异化，我更想从交互体验入手。基础选项必须齐全，但真正值得投入的是实时预览：用户调整纸张、方向或页边距后，可以立即看到大致效果，而不是等文件生成后再反复重试。
再往后，还可以尝试两个方向。一是加入 AI 对话，让用户通过自然语言隐藏网页元素、修改内容或调整版式；二是支持批量转换，满足现有产品很少照顾到的批量处理需求。这两项都需要先验证，尤其要继续研究批量转换相关的关键词，不能只因为竞品没做，就觉得这里一定有机会。
想法可以很多，但第一版必须收住范围。WebpageToPDF 最核心的任务只有一个：用户输入公开网页地址，选择纸张和版式，然后生成并下载 PDF。
第一版只做这条完整路径：
输入网址 → 设置 PDF → 提交任务 → 等待转换 → 下载文件首版只支持公开的 HTTP/HTTPS 网页，以及 A4/Letter、横向/纵向、打印背景和页边距这些基础选项，登录用户可以查看自己的转换记录。
需要 Cookie 的私有页面、Chrome 扩展、批量转换、API、团队空间、AI 调整和网页编辑器暂时都不做，第一版先把最核心的功能做好。Chrome 扩展仍然值得放进后续计划，因为它可以读取用户已经登录的页面，解决服务端无法访问会员内容的问题，但这不属于首版范围。
在产品设计阶段，你完全可以和 AI 进行讨论，让它出几个设计原型图。这一步只出设计稿，目标是确定产品的核心 UI、交互流程和功能列表。不过这并不绝对，我个人喜欢在产品设计和技术原型探索中反复修改。
本质上任何一个阶段的划分，都不是定死的，当你有了新的想法，又或者有什么其它的改进方案时，都可以回到之前任何一个阶段进行调整，只有这样不断迭代，才能最终找到最适合你的产品。你也可以在产品设计阶段就确定所有功能的设计，然后直接进入技术原型探索阶段，这取决于你自己的习惯和偏好。
在产品设计阶段 AI 帮我生成了几个版本的 UI 设计稿，我迭代了几次，最终确定了下图的版本：
技术原型探索
在实现真正的产品之前，我个人习惯先探索一下技术实现方案，这样可以避免在开发过程中走弯路。实现 webpage to pdf 的技术并不复杂，一共有两种常见的方案：
-
把网页截图转换成 PDF
这种方案是先对网页截图，再把图片塞进 PDF。它的优点是实现简单，效果也不错，缺点是会丢失文本选择、复制和搜索能力，不适合作为主要实现方式。
-
直接使用浏览器生成 PDF
这种方案本质上就是使用浏览器打开目标网页，然后执行
page.pdf()，浏览器会自动生成 PDF 文件。它的优点是效果最好，缺点是网页的结构多种多样，直接渲染为 PDF 可能存在一些布局或者渲染上的问题。
页面转换为 PDF 的核心难点不在于最终的 PDF，而在于前期网页的排版和渲染。PDF 对应的是传统的印刷品，而网页的布局天然是流式的，这就导致网页的布局和 PDF 的布局之间存在很大的差异。好的产品应该在前期就对网页进行处理，例如隐藏首页的同意弹窗，隐藏侧边的菜单栏，隐藏页脚的版权信息等等。
对于不同的网页，很难有统一的答案，所以我就准备研究如何让用户来决定具体渲染哪部分内容，最好是具备很好的互动性。这也是我目前区分于其他同类产品的主要差异点。
我一开始考虑的创新点有两个，一个是引入 AI，用户可以通过对话的方式来决定具体渲染哪部分内容，例如用户可以输入“请隐藏首页的同意弹窗”“请隐藏侧边的菜单栏”“请隐藏页脚的版权信息”等等。另一个方案就是我刚刚说的，实现真正的远程实时浏览器，用户可以看到真实的浏览器实时画面，通过鼠标交互，做到和本地 Web 调试一样的效果。
想法很美好，但是效果并不理想。首先，对于第一个想法，我尝试了几个原型，功能上是可以做到的，但是我发现意义不大，成本不小。用户真正想要的其实并不是交互，而是当网页上出现广告、弹窗、悬浮窗等干扰元素时，能够自动隐藏它们，或者当网页上出现一些需要用户操作的元素时，能够自动执行这些操作。这些功能大部分并不需要 AI，并不是 AI 不能做，而是 AI 的准确率并不高，而且成本不低，建立明确的规则库可能才是更合理的方案。
对于远程实时浏览器，我发现还真的有不少做这方面的产品，大部分效果都不错，但这不是我想要的。还是那句话，我要做的是把网页转换成 PDF，而不是让用户远程调试网页。Cloudflare 的 Browser Run 其实是可以实现类似功能的，我做了一些原型测试，效果不太理想，很卡，而且成本不低，并不是一个很合理的方案。
不过，我最终还是对第二个方案进行了改造，不直接使用远程浏览器，而是通过截图的方案来实现实时预览。这种模式对于网页转换成 PDF 来说，更加简洁方便，成本更低，而且实现起来也并不复杂。
经过原型验证，我调整了最初的首版范围：将 Visual Editor 纳入首版，但仍然不做 AI 调整、批量转换和 API。截图方案也保留下来，作为优先还原网页外观的快捷模式；需要选择、复制和搜索文字时，则使用浏览器导出方案。后续教程都以这次调整后的范围为准，产品聚焦三种核心模式：
- Quick Convert，该模式使用截图的方案快速生成最终的 PDF，好处就是生成的 PDF 最接近原始网页，缺点就是 PDF 中的文字无法选择、复制和搜索。
- Custom，该模式就是传统的浏览器导出 PDF 的方案，用户可以自己选择要导出的纸张、方向、背景、页边距等选项，好处就是 PDF 中的文字可以选择、复制和搜索，缺点就是生成的 PDF 可能和原始网页存在差异。
- Visual Editor，该模式是基于 Custom 模式的升级版，除了包含 Custom 模式的功能外，还提供了额外的交互方式，用户可以隐藏网页中指定的元素，或者改变某些元素节点的默认样式，导出的结果更加灵活和可控。
上面的内容是我在实际开发和探索过程中的一些想法，具体的产品代码并没有详细展开。这是因为不同产品的实现方式差异很大，而本系列教程主要介绍如何使用 Saavo 模板完成一个真实产品，具体的业务代码并不是重点。
特别是有了 AI 之后，技术原型探索本质上就是为 AI 准备的试验场。在这里，你可以先让 AI 自行实现产品功能，等原型通过验收后，再把代码拆开，逐步迁移到 Saavo 模板中。迁移过程最好由人工把关。
一方面可以趁机捋清整个产品逻辑，另一方面也可以继续调整 AI 生成的代码。代码写得不够好、逻辑比较乱都不要紧，只要把修改范围控制在一个函数或一个文件内，后面发现问题时仍然容易定位和重构。核心还是边界要清楚。
本篇检查
完成这一篇后，应明确三种转换模式及各自的适用场景，并准备好用于迁移的原型。