订阅了Google AI Pro

看过一些朋友的推荐，也跟 Google Gemini 一番探讨之后，今天终于下决心订阅了 Google AI Pro。

可以有更多的 Google Gemini 配额了，包括「思考」和「Pro」，后者貌似就最近两天才加上的。以及，更多的 Nano Banana / Nano Banana Pro 图片配额。还可以用 Veo3.1 做视频。免费版的 Deep Research 配额我曾经用满过，所以还真是有必要成为付费用户。

Google 全家桶里面也可以用 Gemini 了。我记得有印象在 Gmail 里面看到过 Gemini 的图标，但今天去找的确找不到了。莫非是当时 Google 放的鱼饵？

另外，对我而言还有一个挺有吸引力的福利：2TB 存储空间。太太的 Google Photos 空间早就满过了，删了一些视频才降下来。我自己也不敢拍太多照片和视频，就怕哪天空间满了出事情。这问题甚至影响到了我的某些旅游的体验，现在不成问题了。

详细介绍见这里，不过我不知道算不算是最新的：https://support.google.com/gemini/answer/16275805

我是选的「包年」方式，因为感觉一旦用上了应该就「回不去了」。
首年 $100，之后每年 $200。包月正常价是 $20，现在也有试用优惠。不知道是不是年底或圣诞节特别搞的活动。反正都要买，不想等几天错过了，就下单了。
我个人是不太在意这些小恩小惠的，何况已经很划算了。

说起来，Google AI Pro 应该是普通中国人最容易「够到」的顶级 AI 品牌的付费服务了。ChatGPT Plus 之前对中国用户想尽办法封锁，还砍单封号来着。直到现在也没见得有多方便，甚至连「安全」都不一定算得上。我曾经形容为「被中美混合双打」，为了用个靠谱的AI也真是难为了。

图片由 Google Gemini 3 Pro + Nano Banana Pro 生成

当然，对于普通人，我一律是劝他们尽量多用 AI，哪怕是国产 AI。
有在用总比没有在用要强。面对熊，你只需要比同伴跑得快就行。

AI 问：那如果是面对狼群呢？

我说：你差不多得了。 

丢失的 Blogger 铅笔小图标

图片由 Google Gemini 阅读本文后生成，真是厉害

之前在自己折腾 Blogger，大概就是 2023 年或 2024 年把  Blogger 重新翻出来写的时候，一不小心，把每篇 Blog 下面的「铅笔」小图标给整没了。

这个小图标是管理员才能看到的。直接一点就可以进到编辑界面。对于我这种时常在回顾自己文章时发现错别字，需要马上去修改的人而言，真的是很方便。把它弄丢了以后，我每次就得根据文章的标题或标签再去 Blogger 后台找到那篇文章。有时候某些想法只是一瞬间的事情，过了就没了，对于我而言，更可怕的是「过了就忘了」，这也太可怕了！

我一开始还以为是自己之前在编辑主题的时候不小心把它给误删了。但今天想起这事，下决心解决，去看代码的时候，才发现好像不是这么一回事。代码都在里面，但就是不起作用了。

这是原来的代码：

<b:includable id="postQuickEdit" var="post">
  <b:if cond="data:post.editUrl">
    <span expr:class=""item-control " + data:post.adminClass">
      <a expr:href="data:post.editUrl" expr:title="data:top.editPostMsg">
        <img alt="" class="icon-action" height="18" src="https://resources.blogblog.com/img/icon18_edit_allbkg.gif" width="18" />
      </a>
    </span>
  </b:if>
</b:includable>

看到这里我就有点犯嘀咕。cond 明显是条件，该不会是 post.editUrl 没东西吧？
我把 cond 改成一个必定成立的条件，放到页面上一试，还真是。图标出来了，点击没用处，没能跳到编辑页面。问 Google Gemini，它说新一些的主题里面这个图标的确已经被隐藏了。看来 Google 是铁了心要把这个功能干掉了。

我想自己整，但发现真正的编辑页面的 URL 好像有两个 ID 我不知道哪里能拿到。Google Gemini 给出的修改方法语焉不详，而且看起来也没有说到点子上。算了还是求助于传统的 Google 吧。

搜到的第一个贴子是 Google 自己的页面，Blogger 的 Support 论坛：
https://support.google.com/blogger/thread/242102130/editurl-the-url-of-the-edit-form-for-this-article-deleted

里面有提到这位大神，是一个法语的 Blog：
https://bloggercode.orbiona.com/2021/10/faq.html

后面有个英语 Blog 也提到上面那篇：
https://too-clever-by-half.blogspot.com/2022/08/the-case-of-missing-pencil.html

法语对我而言有不少困难，还好有 Google Translate。
我翻到解决方案一节就知道了：看起来那个法语大神给出的就是我想要的东西。
简单地说，把原来的那段代码替换为：

<b:includable id='postQuickEdit' var='post'>
  <!-- /2021/10/faq.html -->
  <b:with value='data:view.isPage ? "blog/page/edit/" : "blog/post/edit/"' var='path'>
    <span expr:class='"item-control " + data:post.adminClass'>
      <a expr:href='data:blog.bloggerUrl path (data:path + data:blog.blogId + "/" + data:post.id)' expr:title='data:top.editPostMsg'>
        <img alt='' class='icon-action' height='18' src='https://resources.blogblog.com/img/icon18_edit_allbkg.gif' width='18'/>
      </a>
    </span>
  </b:with>
</b:includable>

就可以搞定了。

原因据说是 Google 慑于第三方 Cookies 的限制，没法让前台（blogspot.com）和后台（blogger.com）在域名不相同的情况下还能把管理员的登录会话串起来，索性就把整个功能废掉了。

解决方案的原理也很简单：你不让我跳编辑页面，我就自己组 URL。知道 BlogID，也知道 PostID，还有什么做不到的呢？

当然，这里头还有一些诸如「管理员权限的判断」等小东西。按照「八二原则」，真正花时间的往往是在这些事情上。掌握了核心技术，路只走了 20％ 而已。这位法语大神甚至已经把「页面」和「博文」的差别也搞定了。我就不折腾了，直接用她的吧。

照例吐槽一下：搜索结果中，简体中文的页面依然是一无所获，繁体中文有两篇讲到了这个事情，其中一篇涉及到了核心问题，不过最完整的解决方案还是法文以及英文的页面。简体中文在世界文化交流领域里面就是一个小角落，不管卖出了多少玩具电动车，都改变不了这个事实。不要再夜郎自大了。

搜索习惯的这些变化感觉不是个好事情

图片来自网络

长期以来，我习惯在搜索引擎上搜东西。主要用 Google，偶尔也会去用 DuckDuckGo。Baidu 那是「取材」的时候才会去用的。

现在很多人喜欢在 SNS 上搜东西了：微信、微博、小红书、抖音……

我拒绝这样的用法。正常人在 SNS 上写的那点碎片，搜出来也没有意义。如果能搜到大段的「有意义」的东西，那就是有人精心准备的喂给别人看的。利益驱动明显，正确性和中立性相当值得怀疑。不再会有 Web 上 Wiki、Document、非商业性官方网站那种出于非利益性目的的分享了。即使有，质量也不高。这样的话，能搜到什么东西，可想而知。

当然，以上论调，仅限于中国大陆的简体中文「互联网」环境。

---

另外一种变化，就是很多人开始喜欢直接在 AI 上搜东西了，直接问。所以我觉得 Google 搞 Gemini 是必须走的一步，而且时间也不能再晚了。很高兴 Google 勉强算是搭上了车，目前还没被甩下去。

AI 能帮人过滤、汇总和组织信息，所以貌似效率更高。我也很能理解为什么会这样。有时候我急着想要一个答案，特别是想要给别人看的答案时，也会直接问 AI。不过如果时间允许，我还是愿意自己来做这些分析、整理的事情。

每当我选择去做或者不去做这些事情的时候，脑海中浮现出的就是《蠢蛋进化论》里面的各种蒙太奇。

---

最糟糕的是，有的人开始不搜东西了。

他们只习惯点开某个 App，然后等着被投喂到他面前的东西。在我看来，这比什么都糟糕。这的确让我想起了那栋大楼里面的那些动物。

人类，也就到此为止了吧？

把 Google Code Prettify 应用至 Blogger

图片来自网络

记得以前给自己的 Blogger 部署过 Google Code Prettify，不过后来可能是因为主题被重置过，效果没了。今天把它重新找了回来，日后也会逐渐套用至需要的 Blog 上。本文就作为相关内容的技术笔记吧。

部署

在 Blogger 后台中，点「主题背景」，然后进行「自定义」，去「修改 HTML」。
在 head 标签中放置：

<script src='https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js'/>

然后用下列标签把代码括起来，就可以实现本文中的代码块效果：

<pre class="prettyprint">……</pre>

pre 标签中的代码按原始格式存放即可，不过小于号（<）和大于号（>）仍然要进行转义。

---

以下是一些常用到的 option，更多的内容烦请移驾 官方Github页面。

主题

在引用 run_prettify.js 的时候，URL 后面加一个参数 skin 即可。例如：

<script src='https://cdn.rawgit.com/google/code-prettify/master/loader/run_prettify.js?skin=desert'/>

目前有五种主题，预览图点 这里。

不标记为代码

用一组带 nocode 样式的 span 标签括起来即可，还可以加上自己的样式。例如

<span class="nocode" style="color: red;">注意</span>

语言指定

在 pre 标签中指定 lang-* 样式，例如：

<pre class="prettyprint lang-sh">
if [ ! -d '/myfile' ]
then
    mkdir /myfile
fi
</pre>

<pre class="prettyprint lang-cpp">
class A
{
public:
    int a;
}
</pre>

内置支持的语言有 ["bsh", "c", "cc", "cpp", "cs", "csh", "cyc", "cv", "htm", "html", "java", "js", "m", "mxml", "perl", "pl", "pm", "py", "rb", "sh", "xhtml", "xml", "xsl"]，还有一些可以通过 extensions 进行支持，参见官网页面。

自动换行

有些代码有可能把屏幕宽度撑得很大。要想自动换行的话，在 head 标签中添加：

<style>
pre {
  white-space: pre-wrap;
  word-wrap: break-word;
  word-break: break-all;
}
</style>

这里的效果是按字母换行，可能会切断单词。如果要按单词换行，去掉 word-break 这一行。详细的解释参见我的另一篇 Blog《关于表格内文字换行的再研究》。

Blogger 上的博客如何提交完整的 Sitemap

Blogger 现在可以输出 Atom 1.0 和 RSS 2.0 两种版本的 feed（参见 官方说明）。不过无论哪种 feed，都只包含最多 26 个 Post。

对于通常的 feed 订阅而言，最新 26 个 Post 应该是足够了。反正 RSS 阅读器只需要最新的那几个 Post 就行。但对于想把站点的 Sitemap 提交到 Google 的 网站站长工具 去做 SEO 的情况，26 个 Post 就太少了。既然是 Sitemap，当然希望是全部的页面了，那么有什么办法呢？

这里有个老外的 页面，说明了一种办法。大致说起来就是，Google 在提供 feed 订阅的 URL 中，还有两个未公开说明的参数：start-index 和 max-results。前者表示这次的 feed 输出从哪个（序号的）Post 开始，后者表示这次最多输出多少个 Post。于是如果要提交超过（默认的）26 个 Post 的 Sitemap，就可以用类似下面这种：

http://blogname.blogspot.com/feeds/posts/default?alt=rss&max-results=500

不过，看起来 max-results=500 应该是一个上限。本人是没有那个条件去试了，博文数量差着一个 0 哩！对于博文数量超过 500 的情况，上面那个老外的博文中也提到了一个办法，就是分段提交 Sitemap。比如：

http://blogname.blogspot.com/feeds/posts/default?alt=rss&start-index=1&max-results=500

http://blogname.blogspot.com/feeds/posts/default?alt=rss&start-index=501&max-results=500

http://blogname.blogspot.com/feeds/posts/default?alt=rss&start-index=1001&max-results=500

……

反正这些页面是都提交上去了，Google 会自己把它们合并起来的。

让 GoAgent 直接使用自己指定的 Google 服务器 IP 地址

一直很疑惑，为什么 proxy.ini 中把 [google_cn] 下面的 hosts 改成了自定义的 IP 地址，但日志中显示 GoAgent 客户端还在寻找其它的 Google 服务器 IP，并试图作为 GAE 代理进行连接。

因为一直都算还能用，所以就没下决心来解决这个问题（发现自己真的很懒）。但最近 GoAgent 客户端自己找到的IP越来越不靠谱，有时候甚至会导致一半左右的请求都会被重试，实在是太浪费时间了。而且第一次使用的时候 DNS 解析导致的等待也让人很不爽。所以终于决定来看看到底是怎么回事。

一看代码就明白了，问题很简单：GoAgent 客户端针对 [google_cn] 这个 Section 有特殊行为。它会去从 www.google.cn 和 www.g.cn 这两个域名进行解析得到 IP（好像会无视 proxy.ini 中自己设的地址或 IP），然后进行建立 SSL 连接的测试，根据测试情况决定是否切换到 [google_hk]（这又是一个特殊行为）。

这种做法，对于初级用户可能会比较适合。但如果想自己控制 GoAgent 客户端使用哪个 Google 服务器 IP，最好是另外开一个 Section，比如 [google_cn2] 或 [google_us] 之类。这样就不会碰到代码里面预设的这些特殊行为了。

PS: 以上内容基于 GoAgent 2.1.11 / 2.1.15 测试。

GAE 的 Frontend Instance Hours 高居不下咋办？

架设 GAE 用了 GoAgent 之后，对于 Dashborad 中的 Frontend Instance Hours 一项数字如此之高有些不解。查了 Google，发现有同样疑问的还有很多人。于是翻了翻 Google 的文档，做了做实验，基本上弄明白了。

其实这个数字高也不代表什么。不信你可以架一个 Hello world 上去，先不要急着访问，只是打开 Dashboard 看看。Number of Instances 应该是 0，Frontend Instance Hours 也是 0。然后再打开 WebBrowser 访问一下你的 Hello world，再看 Dashboard。现在 Number of Instances 是 1 了，而 Frontend Instance Hours 就开始了渐渐的增长，哪怕你把 WebBrowser 马上关掉也是如此。
说白了，Frontend Instance Hours 就是 GAE 记录的服务实例运行所用掉的时间配额。没访问过的话，实例数是 0。而一旦有 HTTP 请求，GAE 就得启动一个实例来响应这个请求。运行这个实例需要耗费相应的 CPU 和内存资源，于是 GAE 就开始计费了。实例不停，Frontend Instance Hours 就会一直长。而 GAE 为了能在短时间内响应下一个请求，通常是不会很快把实例给停掉的。（至于到底会等多久才停实例，据说是 15 分钟无新请求就不再增长 Frontend Instance Hours，但实例数还在，估计挂起了。不过你可以手动停掉它。）
既然叫做「Hours」，增长的速度当然就是指的实例实际运行的时间。实例跑了一个小时，那么 Frontend Instance Hours 就会增加 1.00。我没测过 Google 会不会在计费上面耍点小手段，大抵是不会的，个人感觉也基本上差不多。
所以看着 Frontend Instance Hours 一点一点地增长，也完全不必心慌。一天 24 小时，GAE 给了 28 的免费配额，如果你只跑一个实例，是不可能用完的。用到 23.99，下一分钟就第二天，重新计算，清零了。对于只跑 GoAgent 的用户，实在不放心的话，我觉得用两个 AppID 来跑也完全足够了。当然，流量超了的情况另算。

那么什么时候 Frontend Instance Hours 会超过 24 呢？据说一个请求如果在等待了超过 Min Pending Latency 的时间之后，仍然没有实例能来处理它，那么 GAE 就会开一个新实例来做这个事情。所以 GAE 给了免费用户 28 个 Frontend Instance Hours。Google 的解释是为了让用户能够应对一些紧急状况。
另外，这个「紧急情况」，除了指访问量大导致的多实例运行，也包括了一个功能，就是 GAE 允许用户调高 Frontend Instance Class。F2 级就比 F1 级多用一倍的计算资源，而 Frontend Instance Hours 也就增长得快一倍。这种情况下，多出来的 4 个小时就可以视为 GAE 给的「加力」之类的东西了。如果你只想在短期内进行一个高强度的计算，那么可以考虑用 F4 来跑一个 APP 看看。

邹寿飞其人

邹寿飞，何许人也？

在 Google 上搜这个人名，出来的链接大多指向一个特定的内容，一篇名为《我曾是一名丑陋的中国人》的文章。作者就是「广东中山邹寿飞」。这是一篇篇幅不小的「主旋律」的文章，「深刻反省」了中国人的种种劣行。

不过，关于这篇文章并不是我在这里要着重关心的，这种文章扫一下标题就知道大意了。我感兴趣的，是 Google 出来的一个来自 www.miibeian.gov.cn 的页面。

呵呵，www.miibeian.gov.cn 是什么网站，我想建过网站的朋友到现在应该都不会陌生了，看域名也能看出点端倪。这个网站现在改成了 beian.miit.gov.cn，我做了链接，还不知道的朋友可以点进去看。

好了，言归正传，Google 的搜索结果中，有这样的信息：「……邹寿飞. 74977.com. 粤ICP备05127128号……」。

一看这个域名，就知道不是什么好东东。访问一看，原来是一个一夜情俱乐部的网站。具体地说就是皮条客网站，灰色产业。但是因为网页实在是很简单，也找不到什么「违禁」内容，所以政府的扫描器反而抓它不到。

而会员注册方法的页面中，则明明白白地写明了「邹寿飞」的汇款地址等等信息。从地址信息看来，明白无误是同一个人。亏这个「邹寿飞」在某些文章中表现得良知满满，原来实际上还干着这种生意。

奇妙的 Internet，奇妙的 Google。以后我还会找点别的有意思的情况来谈谈。