我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

openai 今天发布「 ChatGPT o1-preview」，是会尝试主动思考的 ai 语言模型，chatgpt Plus 订阅用户现在就可使用。

根据 OpenAI 的说法：「我们训练这些模型〔ChatGPT o1-preview〕在回应前花更多时间思考问题，就像人类一样。通过训练，它们学会精炼思考过程、尝试不同策略，并能察觉自己的错误。」「如果您正在解决科学、程序设计、数学和相关领域的复杂问题，这些增强的推理能力可能特别有用。」

我自己在讲 ChatGPT 提升工作效率的相关课程时，常常强调一个设计指令的重点：「如果我们写 AI 指令〔 prompt、提示语〕时，可以让 AI 写出自己在想什么、怎么处理任务，通常生成的内容结果会相对更好。」

从用户端的角度来看「ChatGPT o1-preview」，就是在 AI 生成内容前，会先展开一步一步的思考流程，它可能会选择思考的策略与切入点，有时会提出一些批判思考，也会更仔细的分析资料细节来做深入处理。

在这个过程中，「ChatGPT o1-preview」生成内容的速度其实比 GPT-4o 要慢上不少，可能需要 30~60 秒的思考时间〔或者更久〕，才会开始一步一步的生成内容。

也因为这样的「思考」过程需要耗费更多运算资源，所以即使是 ChatGPT Plus 用户，在使用「ChatGPT o1-preview」时也有一些限制：

也就是说，目前「ChatGPT o1-preview」比较像是「GPT-4o」的辅助，在进行一些需要深入分析资料、产出有逻辑结果的任务，或者像是科学、数学、程序代码相关领域时，可以运用。

今天这篇文章，我就从自己日常惯用的几个 AI 辅助需求：翻译、摘要、企划思考、文案，以及有时用代码写个小工具的角度，以实际案例测试看看，「ChatGPT o1-preview」的效果如何，并和「GPT-4o」同样指令下的结果作比较。

当然，如果能从科学、数学与代码的角度来验证更好，不过从我个人常用角度出发，也想验证看看 ChatGPT o1-preview 是否能满足我的日常工作需求，也提供大家参考。

下面，先提供大家下面测试案例的快速心得比较表格。

翻译结果更简洁有力，文句白话流畅。

用语更符合台湾惯用词汇。

在「白话流畅度」与「专业用语」间平衡得更好。

翻译结果相对较弱，文句不如 o1-preview 流畅。

能计算分数并回馈对错。

无需修改即可使用。

需要多次反复调整才能达到可用程度。

提供具体、逻辑分明的建议步骤和文章架构。

深入分析资料细节。

缺乏深入的分析和明确的建议。

能整理出详细的步骤和操作要点。

细节完整程度略有不足。

缺乏社交贴文所需的流畅性和吸引力。

更注重安全性和准确性，避免使用版权材料。

可能在细节上不够精准。

首先来试试看翻译〔英翻中〕，我通常会用下面指令来要求 ChatGPT 翻译文章：「把下面这篇 XXX 主题的文章，翻译成中文，请一段一段翻译，尽量在维持原文语意，主题风格的情况下，让上下文的语句更自然通顺，遇到专有名词时附注英文原文，并在第一遍基本翻译后，用台湾惯用词汇与语气进行最后修饰。」

下图「左方」，是「ChatGPT o1-preview」翻译的结果。下图「右方」，是「GPT-4o」翻译的结果。

结论是，「ChatGPT o1-preview」花了 57 秒完成一整篇文章的翻译〔文章是 OpenAI「ChatGPT o1-preview」官方公告〕，但是翻译的结果比「GPT-4o」优异不少。

例如，大多数时候，「ChatGPT o1-preview」翻译的文句更加简洁有力〔相对「GPT-4o」〕，可以在许多段落看到这样的差别。

「ChatGPT o1-preview」翻译的结果也更白话，相对流畅，用语更符合我指定的中文用语。

「ChatGPT o1-preview」在「白话的流畅度」与「专业用语」之间也相对更能拿捏得当，会让人更容易看懂，但又保持专业用语的明确性。

我让「ChatGPT o1-preview」测试直接写一个九九乘法表小工具。o1 同样会先思考撰写工具的逻辑，然后才开始写出程序代码。

我提供的指令是：「我的小孩正在练习记忆数学的 99 乘法表 ，你可以设计一个协助她练习的小游戏吗？

请一步一步分析，从简单的 2 与 5 的乘法表开始，然后练习 3、4、6、7、8、9 的乘法表，根据每一个乘法表设计一个记忆游戏，游戏一开始可以选择要练习哪一个乘法表，进入后可以随机考验该乘法表的熟练度，最好设计有游戏机制。」

下面是 ChatGPT o1-preview 第一次生成的 99 乘法表小游戏，我没有做任何的修改，但是正确性、界面美化、操作流畅度都已经达到可用的程度，还会计算分数与回馈对错。

下面是旧版 GPT-4o 第一次生成的小游戏，基本界面可操作，但有一些明显错误〔如下图〕，可能还需要多几次的反复问答，才能调整正确。

我也很常跟 ChatGPT 一起讨论沟通企划案，下面是新旧版本生成的结果比较。

我提供了许多参考资料，请 AI 帮我做产品的企划报告。

「ChatGPT o1-preview」在生成过程中，会主动做一些反向思考，与探索不同的报告呈现方式，并且提供一些具体的、逻辑分明的建议步骤，这些不一定有出现在我的指令中。

下面是 ChatGPT o1-preview 生成的版本，我举出其中一部分，它提出了一个撰写初稿的建议方案，并指出了一些明确的试写步骤、文章架构方向。

下面是 GPT-4o 类似段落的版本，虽然也提出了撰写初稿的建议，但整体的说明就比较一般，少了一些明确的、深入的分析与建议。

我也测试了用两个版本去摘要同一篇文章。

下面是 ChatGPT o1-preview 的版本，可以看到文章细节整理得更深入、完整、有条理。

下面是 GPT-4o 版本摘要的结果，基本架构也相似，但细节的完整程度就有一点落差。

不过，ChatGPT o1-preview 也有他不擅长的内容，目前看起来它撰写流畅文案的效果，反而没有 GPT-4o 好〔现在写文案相对效果最好的可能是 Claude 3.5 Sonnet 〕。

下面我请 AI 根据参考资料写出社交贴文上的文案。

ChatGPT o1-preview 版本，AI 会思考撰写过程，撰写时会进行更多安全性、准确性的思考，例如避免使用版权材料。

但是多次尝试后，发现 ChatGPT o1-preview 版本目前的结果，比较像是把参考资料更有结构、更有逻辑的分析整理，不太像是社交贴文。

相较之下， GPT 4o 的版本，可能细节没有那么精准，但文案比较流畅。〔如下图〕

以上就是我的初步测试案例与心得，提供大家参考。

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

n.eko 是一款多合一的浏览器工具，可以本地运行，也可以在 Docker 中运行。

n.eko 满足几乎一切都运行在浏览器里面的需求。因为运维需要，有些内部服务需要透传一下，单纯的服务没问题，但是一些厂商设备没有命令行。只可以用网页操作。这个项目甚至支持远程音视频，WebRTC 技术，还有验证登录。

Neko 可以让你在虚拟环境中运行功能齐全的浏览器，可以像在常规浏览器上一样浏览网页、运行应用程序，所有这些都在安全且隔离的环境中进行。

另外，还支持多用户同时使用。Neko 这样写着：

借助 Neko，您可以轻松、安全地与其他人共享浏览器的访问权限，而不必担心维护单独的配置或设置。无论您需要在项目上进行协作、访问共享资源，还是只是想与朋友或家人共享浏览器的访问权限，Neko 都能轻松实现。

听起来很不错啊：

Neko 也是举办观看派对和互动演示的绝佳工具。凭借其虚拟浏览器功能，Neko 允许您举办可从任何地方访问的观看聚会和演示，而无需亲自聚会。即使您无法亲自见面，也可以轻松地与朋友和同事保持联系。借助 Neko，您可以轻松举办观看聚会或进行互动演示，无论是休闲还是工作。只需邀请您的客人加入虚拟环境，您就可以共享屏幕并与他们实时互动。

N.eko 针对不同浏览器提供了不同的镜像：

推荐配置为 1280×720@30、4 核、3gb 内存，当然越搞越好。

docker-compose.yml 文件：

然后 docker-compose up -d 运行即可，使用 IP:8080 访问。

N.eko 甚至还有一个 VLC 版本…可以用来看剧

详细的可阅读文档。

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

Bookmarklet 本质上只是一次性的 Javascript 代码，不能持续运行、实时监控，固然远不及正式的浏览器插件，且不论 chrome 上的添翼利器，即便是戴着镣铐蹒跚而行的 Safari 插件，当然也比 Bookmarklet 更强大。不过，普通人毕竟不太可能自己开发插件，然而制作一个 Bookmarklet 则很有可能。

易于制作只是一方面，在硬币的另一面，则深深刻印着通用二字。只要不用特别晦涩的代码，几乎所有现代浏览器都可以跑 Bookmarklet，Chrome、firefox 和 Edge 自不待言，Vivaldi、Arc 和 Brave 也可以，甚至常常被讥为「当 IE」的 Safari 都能用。我个人还特意先为 Safari 编写 Bookmarklet，由俭入奢易，通常写出来的东西在更先进的浏览器中可以直接运行。如果愿意，就连手机浏览器也可以用 Bookmarklet。

所有设备都能使用 Bookmarklet

在 2024 年重谈 Bookmarklet，还有着现实原因。一方面，Safari 和主流手机浏览器令传统插件生存艰难，这是 Bookmarklet 势在必行的历史背景；另一方面，GPT 拆除了代码——至少是简单代码——的门槛，让自制 Bookmarklet 不再显得凡尔赛。此外，即便在插件生态完善的浏览器中，若能借助最新的人工智能技术随意自制工具以供己用，也是一种对 Home Made Tool 的呼应。

某种程度上，本文所谓的 Bookmarklet 制作更像是用预拌粉制作蛋糕，技术难度不高，但原材料的压力就随之上升——必须先获得可以运行的 Javascript 代码。这曾经是 Bookmarklet 的阿喀琉斯之踵：既然某人有能力自己写 Javascript，他为何不再接再厉做个浏览器插件（并通过闭源大赚一笔）呢？Bookmarklet 不温不火，自然有这层原因。

好在 GPT 彻底颠覆了编程，至少是简短的代码。Nielsen Norman Group 精辟地指出，人工智能将交互范式从命令式推动到目的式，不少任务无需指挥计算机，只需告诉他你最终想要的效果，通常就能得到不优雅但有效的代码。而控制网页的 Javascript 通常都不会太复杂，非常适合让 GPT 去写，而且如果一次不行，大不了多生成几个回答，就像摇彩蛋一样——而且基本不花钱、不限量。我曾突发奇想把网页搞成灰色，免受花花绿绿图像的干扰，问了 GPT 后马上获得答案。

找 GPT 讨 Javascript 代码

此外，现成 Javascript 代码也是宝贵资源。例言之，Keyboard Maestro 论坛中有不少用 Javascript 控制网页的讨论，很多其实就是纯 Javascript 套壳，并不囿于 Keyboard Maestro，你可以复制过来当成 Bookmarklet 的素材。

一旦获得 Javascript 代码，之后的工作将势如破竹，各种 Bookmarklet 生成工具一抓一把。在技术上，从 Javascript 到 Bookmarklet 无非是一系列文本替换，把代码修整为超链接的形式。我考虑过编写本地自动化工具，不过也愿意直接用在线服务，最常用的是 Bookmarklet Creator。惟需注意，GPT 生成的代码中有大量双斜杠 // 开头的注释，转换为 Bookmarklet 前需要删除，否则 Bookmarklet 不生效。

用在线工具将 Javascript 转换为 Bookmarklet 注意：如需使用在线服务，建议确保您上传的 Javascript 代码中不包含敏感信息，例如个人信息或 Token。

转换成功的 Bookmarklet 应当以 javascript: 开头，呈现以下格式。

获得 Bookmarklet 的代码（链接），很多不熟悉 Bookmarklet 的人都卡在后续的安装步骤。不同于正式的插件，Bookmarklet 不是独立的按钮，而是一枚书签，使用时通常需要在浏览器地址栏或搜索栏——在现代浏览器中，两者往往融合了——中启用，这种操作确实反直觉，毕竟点击一个书签时，第一反应肯定是跳到新页面。好在尝试几次之后，这种操作反而更有优势：连没有插件栏或工具栏概念的移动端浏览器，也能用 Bookmarklet。

安装 Bookmarklet，其实和添加普通网页书签无异。以 Safari 为例，首先随便收藏一个网页（快捷键是 ⌘Command-D，然后在新空白标签页中编辑它，换上 Bookmarklet 的代码。之后，这个书签就成了一颗轻量级的浏览器插件，浏览网页时按下去即可触发 Javascript 代码。

编辑书签并换上 Bookmarklet 代码

接下来的问题就是：如何在网页上使用 Bookmarklet？如果你一直显示收藏夹栏，就直接点击其中的 Bookmarklet；如果不习惯持续显示——可能是为了节省屏幕空间——则点击浏览器地址栏或搜索栏，在弹出的收藏夹项目中点 Bookmarklet，若没有看到，则可能需要在 Safari 设置中勾选“Show Favorites”。

在 Safari 浏览器设置中勾选「Show Favorites」

我常常需要下载裁判文书，而默认的打印效果非常差，夹杂了大量无关元素，而正文反而被压到一边了。最初我写了一段 Javascript 并包装成 Keyboard Maestro 解决此问题，结果同事见后都羡慕不已，于是我顺手做了一个 Bookmarklet 版，不仅不依靠 Keyboard Maestro，连操作系统和浏览器也没有什么要求，从 Safari、Chrome 到 360 用户都能正常下载裁判文书。

用 Bookmarklet 重新排版裁判文书

熟悉用户自动化的读者，大概也能想到替代方案，然而像 Bookmarklet 这样获于此而得于彼的通用工具，却不多见。在自制 Bookmarklet 难度骤降的当下，诸位也不妨将其作为备用方案。

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

当想通过 RSS 订阅一些人的文章时，却发现只提供微信订阅和邮件订阅（News Letter）。为了解决这个问题，找到了一个 Kill the Newsletter! 服务，它可以替你接收邮件并转化为可供 RSS 阅读器订阅的地址。

Kill the Newsletter! 允许用户将订阅邮件转换为 Atom 订阅源。对于需要验证的订阅源，也会将确认邮件转换为订阅源条目，只要进入转换的地址，就可以获取并点击确认链接。

暂不支持通过回复邮件来验证订阅，可以尝试联系发布者手动验证，或使用邮件设置转发作为解决方案。

另外，有些 Newsletter 的发布者可能会将 Kill the Newsletter! 的电子邮件地址拉黑，同样需要转发之类的绕过。

由于订阅源包含用户的电子邮件标识符，因此不建议分享订阅源，以防止他人取消订阅或发送垃圾邮件。

通过以上步骤，你就可以把原本只能通过邮件接收的内容转化为 RSS 订阅，方便在各种 RSS 阅读器中统一管理和阅读。

我们还年轻，可不想看到这个世界处在毫无自由、隐私的边缘。

使用云服务时，一个常被忽视的成本就是数据流出费。这指的是将数据从云服务提供商的网络发送到公共互联网的费用。

这里整理了常用服务的流量费用，可以快速了解不同云服务的流量费用差异，这不仅是单纯 VPS 比较，而是各类的云服务都拿出来比，像是存储类的以及 CDN 类的都有放进来。

如果超出了免费流量，每家供应商收取的 1TB 数据流出费用如下:

小提醒: 实际价格可能因地区和其他本文未列出的因素而有所不同。为方便比较，这里选择了最靠近北弗吉尼亚(美国)或法兰克福(德国)的区域，并根据统一的使用情况假设估算出这些价格。请务必查看供应商的定价页面以获取最新信息。

数据流出是指数据离开某个网络，更确切地说，是数据离开你的云服务提供商网络进入公共互联网。这可能是从云服务商到用户的数据传输，或是从一家云服务商到另一家的数据传输。

云服务商通常根据从其网络流出的数据量按 GB (1 GB等于1024 MB)或 TB (1 TB等于1024 GB) 计费收取每月数据传输费用。

从云服务商的角度来看，有两种数据传输类型:

实际操作中，可能是这样的:

要下载文件，用户设备需要从云服务商网络请求数据，而云服务商则需要将数据发送给用户(或内容分发网络等中间商)。这就会产生数据流出费用。

云服务商之所以收取数据流出费，是因为从其网络传输数据需要成本。他们需要为传输数据所需的基础设施和带宽付费。

不过，数据流出费也可能是为了阻止某些使用场景，比如跨云服务商大量传输数据。

大多数云服务商都提供一定的免费流出数据量，比如整个账户每月 100GB 的免费流量，或者每台服务器每月 1TB 的免费流量。

因此，根据你的使用情况和选择的云服务商，你可能完全不用为数据流出付费。

在尝试降低数据流出费用时，可以考虑以下几个因素:

Backblaze 的带宽费用算法颇有趣，每个月给数据量的三倍大小当作免费带宽，没记错的话因为 Cloudflare 是 Backblaze 的官方合作伙伴，两边的传输费用不计费，如果数据是可以公开的，可以通过这个方式免费链接出来；如果真的走一般的流量输出，收费是 US$0.01/GB (所以换算后是 US$10/TB)。

三家常被摆在一起的 VPS (Linode、DigitalOcean、Vultr) 的带宽也都是 US$10/TB。

以前没注意到的是 OVH Cloud 与 Scaleway 的带宽费用是免费的？另外 Hetzner 虽然要收费但也很低？有机会可以测试看看，看一下质量如何？