需求

稣是驱动开发，所以使用的 Windows 几乎都处于测试模式。测试模式会在桌面右下角显示 Testing Mode 字样的水印。这水印只有在首次进入测试模式时有用，其它时候十分多余，所以，把它去掉吧！

理论

这水印是 explorer.exe 调用 SHELL32!CDesktopWatermark::s_DesktopBuildPaint 画的。

所以，只要在这个函数开头写一个 ret 指令，即可使其不画任何东西。

实践

1. 附加到 explorer.exe

打开 WinDbg，按 F6，或者点菜单 File - Attach to a Process...，然后找到 explorer.exe，使用非入侵方式附加。

可以按进程名排序，比较容易找到哦！

注意：需勾选 Noninvasive，否则退出调试时，explorer.exe 也跟着重启了。

2. 确认目标函数的地址

输入命令：

1
2

x SHELL32!CDesktopWatermark::s_DesktopBuildPaint

稣机器上的输出为：

1
2

00007ffa`38bdfcc8 SHELL32!CDesktopWatermark::s_DesktopBuildPaint (private: static void __cdecl CDesktopWatermark::s_DesktopBuildPaint(struct HDC__ *,struct tagRECT const *,struct HFONT__ *,bool))

可见目标地址为：00007ffa`38bdfcc8。注意：您的机器上很可能不是这个地址！在下个步骤使用时，需要替换为您机器上的地址。

3. 修改目标函数

在 x64 上，ret 指令的机器码为一个字节 0xC3，所以修改的指令为：

1
2

ed 00007ffa`38bdfcc8 c3

回到桌面，确认右下角的水印是否消失，可能需要刷新才会消失。

确认没问题后，输入 q 退出调试，大功告成。

限制

当 explorer.exe 重启后，水印会再出现。

需求

• 想把自己写的 MarkdownEditor 移植到 Debian，同时尽可能少改代码。
• 想在 Debian 用几个惯用的 Windows 软件。

思考

改代码太不划算了，又没人给钱！虚拟机太重，为几个小应用使用虚拟机也不划算。用 wine 才是正道！

都用 Debian Testing 了，怎么也得装个 winehq-devel 吧！

安装

注意：现在是 2026-05-25，目前 testing 是 forky，将来变为其它时，需要相应更改部分命令。

1. 添加仓库公钥

1
2
3

sudo mkdir -pm755 /etc/apt/keyrings
wget -O - https://dl.winehq.org/wine-builds/winehq.key | sudo gpg --dearmor -o /etc/apt/keyrings/winehq-archive.key -

2. 添加源文件

1
2

sudo wget -NP /etc/apt/sources.list.d/ https://dl.winehq.org/wine-builds/debian/dists/forky/winehq-forky.sources

3. 【可选】使用国内镜像

这步是为了网络提速，不是必须的。

方法一：手动编辑，保险应对将来风险：

1
2

sudo vim /etc/apt/sources.list.d/winehq-forky.sources

把 Host（通常为 dl.winehq.org）改为 mirror.nju.edu.cn。

方法二：无脑替换（将来有可能失败！）

1
2

sudo sed -i 's|dl.winehq.org|mirror.nju.edu.cn|g' /etc/apt/sources.list.d/winehq-forky.sources

3. 安装 WineHQ 软件包

1
2

sudo apt install --install-recommends winehq-devel

额外

可以安装 PortableApps，里面的软件大部分能在 wine 环境运行，比如著名的 Notepad++。

注：提到 Notepad++，是因为它是著名的 Windows Only 软件，并不代表稣推荐它。

论点

• 升级 C++ 版本或找个好库都能提升性能

定义

字符串拼接，除了典型的多个 std::string 拼接，还涉及到其它类型先转为字符串再拼接。

分析

实际上，其它类型“转为字符”还挺复杂的，不是简单写几行代码能搞定。凡是复杂的东西，就有很大优化空间。

当然，单纯几个 std::string 拼接，也有优化空间，这步可以先解决！假设变量 a、b、c 都是 std::string，先看两种做法：

1
2

a = a + b + c;  // method 1
a.append(b).append(c);  // method 2

这是在做 In-place 拼接，第二行才是正规的做法，而第一行在不同 C++ 版本下内部做法并不一样。古典 C++ 会产生更多的复制，当然稣已经完全无视 C++ 20 之前的版本，并不打算解释它们有多烂。在现代 C++ 下，第一行大致做了如下操作：

1. a + b 产生一个临时对象（设为 x）；
2. 把 c 追加到 x；
3. 把 x move 给 a。

注意到：里面新增了一个临时变量，因为 std::string 的实例还挺大的（大于 3 个机器字/指针），所以第二行是有优化效果的。

然而，由于在追加的过程中，可能需要扩容，追加两次，最多就可能扩容两次，所以实际上以上两种做法都不够极致，还应该先 reserve 足够内存：

1
2

a.reserve(a.size() + b.size() + c.size());
a.append(b).append(c);

有位大佬觉得这么写也太麻烦了，咱们应该发明一个高能的 concat 方法，它足够快，快到只有 AI 手动对特定场景进行优化才有可能打败它。没错，这个方法叫做——fastio::concat！

您可以先试试这里的各种拼接方法：https://github.com/cppfastio/fast_io/tree/master/benchmark/0009.concatstring

总之，fastio 最快。由于我们是先注意到 fastio 最快，所以下面的分析哪怕很简陋，也没关系了……

1. 可能是最慢的 std::ostringstream

1
2
3
4
5
6

std::ostringstream sst;
for (std::size_t i{}; i != 1000000; ++i) {
  sst.str("");
  sst << "hello" << test_i << test_s;
  re = sst.str();
}

这个方法本应是专门做“字符串拼接”的，但其实现确实很慢。稣给优化了一下：

1
2
3
4
5

std::ostringstream sst;
for (std::size_t i{}; i != 1000000; ++i) {
  sst << "hello" << test_i << test_s;
  re = std::move(sst).str();
}

代码少一行，而且少一次复制。稍微快了一点点，但还是垫底的存在。

2. std::format

1
2
3

for (std::size_t i{}; i != 1000000; ++i) {
  re = std::format("hello{}{}", test_i, test_s);
}

使用 std::format 的问题在于 formatter 支持的语法还挺多，对它进行解析有一定损耗。

另外，std::format 刚出来时，稣拿它和 fmt::format 比较过，MSVC 上的实现比 fmt::format 明显慢很多。所以，换成 fmt::format 可能更快一些。

3. std::to_string + 拼接

1
2
3

for (std::size_t i{}; i != 1000000; ++i) {
  re = "hello" + std::to_string(test_i) + test_s;
}

std::to_string 可以说是一种特定场景的优化，它比前面两种方法快是很自然的事。

3. fast_io::concat

毫无疑问的冠军。它之所以快，是因为在转换和拼接这两步都做到极致：一次性预计算总长度、只分配一次内存、无临时字符串、全内联、零冗余复制……问 AI 吧，稣冰冷的文风不合适夸。

对了，在稣的机器上，最快比最慢的差别是：10 倍以上。

需求

公司的开发机，硬盘只有 1T，编译了几个版本的 Chromium 之后，可用容量告急。经过分析之后，vcpkg 目录居然有几百 GB……直觉告诉稣，这里面有很多擸𢶍。

分析

vcpkg 目录里有这几个子目录是非 Git 跟踪的：

1
2
3
4

/buildtrees/
/downloads/
/installed/
/packages/

很明显，/installed/ 是实际被使用的，所以不能删。

1. /downloads/ 里是下载的代码压缩包和补丁等。这里可能有很多文件是旧版本，只要不再使用是可以删的。当前版本的文件，可以留着。理由是：万一另一台开发机需要，可以直接复制过去，加快 vcpkg install 速度，毕竟从 GitHub 下载通常比较慢，还容易失败。

2. /buildtrees/ 里是构建中间文件、日志等临时文件。只要不开发 port，几乎没有价值。

3. /packages/ 里是构建完成后的“待安装文件”。如果删了，就不能增量构建。举例说明它的作用：比如说 A 库依赖 B 库，而 B 库曾经被安装过，它会被缓存在 /packages/B/目录里，当安装 A 库时，B 库就不需要再编译一遍了。要是把 /packages/ 里面的文件全部删除，则 B 库需要再次编译。这会带来一些副作用，比如说 B 的二进制程序文件会和上次编译的不一样，但实际上它们的版本没变化，下次打包会引入一些版本没变化，但文件内容变化的文件（这并不致命，只是显得不太专业，如果是编译机建议别删，开发机比较无所谓）。

结论

稣先把 /buildtrees/ 里的文件全删了。下次再告急就删 /packages/，毕竟这是开发机。

需求

1. 稣希望保持手指的健康，尽量少敲击。

2. 面对“这样可以，那样也可以”的规范，稣希望能贯彻某种原则，以减少内耗。

思考

以上两条在多数情况下是不矛盾的，所以就可以把第一条作为原则：尽量少敲击！

但要注意的是，本文讨论的是编码风格里最低级的议题——格式。所以它不涉及如何命名，比如说变量、函数的命名，应该贯彻可读性好的原则，别乱缩写。

“敲击少”的原则仅用于信息量完全一样的场景！

具体规则

1. 缩进 2 个空格即可

在视觉上 2 个空格已经足够分辨。

著名风格中，使用 2 个空格缩进的有：LLVM、Google、Chromium、GNU、Mozilla，用 4 个的只有：Microsoft 和 WebKit。可见 2 个才是主流。

ClangFormat 配置为：

1

IndentWidth: 2

2. 左对齐节省空格

2.1 指针左对齐（PointerAlignment）

C++ 不像 Go、Rust 那样有“官方的”格式化风格，所以指针符号怎么对齐就有四种样式：

• 左：int* p;
• 右：int *p;
• 中：int * p;
• 哦不：int*p;

著名风格主要分为两派：Google、Chromium、Mozilla、WebKit 使用左对齐，而 LLVM、GNU、Microsoft 使用右对齐。

作为规范制定者，淘汰掉最后一种是极其容易的——因为 ClangFormat 的 PointerAlignment 没有这个选项！而 Middle，则是因为没有著名风格使用，也应该被淘汰！

接下来，稣便利用“敲击少”的原则在“左”和“右”中二选一！注意到：在类型转换中，两者是不同的：

1
2

void*p{};
auto i = static_cast<int*>(p);

在左对齐时，被格式化为：

1
2

void* p{};
auto i = static_cast<int*>(p);

而使用右对齐，则被格式化为：

1
2

void *p{};
auto i = static_cast<int *>(p);

可见右对齐在类型转换场景下会比左样式多出一个空格，这违反了“敲击少”的原则，所以稣愉快地选择了左对齐。

同理，ReferenceAlignment 应该和 PointerAlignment 一样，所以可以把其值设为 Pointer 或 Left。

em，本条还没完……还有一个 DerivePointerAlignment 应该设为 false。如果是 true，ClangFormat 会分析格式化文件，以确定最常见的 & 和 * 对齐方式。指针和引用对齐样式将根据文件中找到的首选项进行更新。然后，PointerAlignment 仅用作后备。

指针对齐一直是争议比较大的，左对齐的反对者常会举出一行定义多个变量的例子：

1

int* p, q;

然后说左对齐，容易产生 q 也是指针的错觉。实际上这例子的说服力不大，毕竟那是新手才容易产生的幻觉。而且，通常不建议一行定义多个变量。

一份 .clang-format 的相关部分参考：

1
2
3

DerivePointerAlignment: false
PointerAlignment: Left
ReferenceAlignment: Pointer

2.2 AlignEscapedNewlines 左对齐

在转义的换行符中对齐反斜杠的选项。可能的值：

• DontAlign：不要对齐转义的换行符。（难看）
• Left：将转义的换行符尽可能左对齐。
• Right：将转义的换行符尽可能右对齐。（最好看，但空格更多）

AlignEscapedNewlines 使用 Left 的著名风格有：Google、Chromium，使用 Right 的有：LLVM、GNU、Microsoft、Mozilla、WebKit。

3. 在不影响可读性时，尽量少换行

通常来说，在语句块之间插入换行或注释，可以提高可读性。比如说：

1
2
3
4
5
6
7
8
9
10

render_log_init();

struct render_context_args ctx_args;
bool ok = render_server_main(argc, argv, &ctx_args);

/* this is a subprocess */
if (ok && ctx_args.valid)
   ok = render_context_main(&ctx_args);

return ok ? 0 : -1;

如果把空行都去掉，就比较难一眼看清这些代码做了几件事。当然，如果每个语句块的开头都有注释，其实也可以不要空行，只不过注释可不是人人都爱写，并且，一些通过命名自注释的语句块，再写注释确实显得重复啰嗦。

但是，反转来了——有些地方换不换行不影响可读性。比如说 { 之前的换行、函数返回值类型后的换行……

3.1 BraceWrapping

事实上，缩进已经能保证可读性，{ 有没有和 } 垂直对齐，已经不重要。（每行不要太长更重要点！）

所以，在 .clang-format 的 BraceWrapping 节下面，应该越多 false/Never 越好，比如 Google 和 Chromium 都是：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

BraceWrapping:
  AfterCaseLabel:  false
  AfterClass:      false
  AfterControlStatement: Never
  AfterEnum:       false
  AfterExternBlock: false
  AfterFunction:   false
  AfterNamespace:  false
  AfterObjCDeclaration: false
  AfterStruct:     false
  AfterUnion:      false
  BeforeCatch:     false
  BeforeElse:      false
  BeforeLambdaBody: false
  BeforeWhile:     false
  IndentBraces:    false
  SplitEmptyFunction: true
  SplitEmptyRecord: true
  SplitEmptyNamespace: true

在著名风格里，论 { 之前省换行，Google 和 Chromium 是并列第一名。

3.2 BreakAfterReturnType

这个选项有 5 个可选样式值：

• None：自动
• All：总是在返回类型之后换行，包括定义和声明。
• TopLevel：总是在顶级函数的返回类型之后换行，包括定义和声明。
• AllDefinitions：总是在函数定义的返回类型之后换行。
• TopLevelDefinitions：总是在顶级定义的返回类型之后换行。

主流的著名风格使用 None，比如 LLVM、Google、Chromium、Microsoft、WebKit，只有两个例外：

• Mozilla 采用 TopLevel
• GNU 采用 AllDefinitions

结论

在“敲击少”原则的筛选下，著名风格里只有 Google、Chromium 生存下来。

扩展

1. 《指针判空》时，应该省略和 nullptr 比较。

2. 从机器的角度看“少”，应该把换行符指定为 LF，毕竟在 UTF-8 编码时，每行能省一字节。参考：《Git 换行符设置终极指南》

跨平台用 pwsh 写脚本？认准原生 Cmdlet 才是王道

作为常年同时使用 Linux、macOS、Windows 的开发者，稣对 pwsh（PowerShell 7+）的跨平台一致性情有独钟——只需写一套 .ps1 脚本，就能在三大系统运行。但最近踩了个 mkdir 的小坑，才发现看似通用的命令背后，藏着平台差异的玄机，也让稣更坚定了「优先用原生命令」的原则。

意外发现：mkdir 居然不是 alias

一直以为 Windows 版 pwsh 上的 mkdir 是个 alias，直到某次在 Windows 上执行 Get-Alias mkdir 时，居然报错，这才意识到，它在不同平台下是不同实现。

用 Get-Command mkdir 一查，差异瞬间清晰：

• Windows：mkdir 是一个 Function，本质是 New-Item -ItemType Directory 的封装，用 (Get-Command mkdir).Definition 就能看到其代码；

• Linux/macOS：mkdir 是 Application，直接调用系统自带的 /bin/mkdir。

这就导致了关键差异：Linux/macOS 上的 mkdir 支持 -p 参数创建多级目录，但 Windows 上的 Function 版 mkdir 并没有 -p 参数（即加不加 -p 都是一样的），它都是能“创建多级目录”的语义。

顺着这个思路查了 rmdir，发现它同样存在差异：

• Windows：rmdir 是 Alias，指向 Remove-Item -ItemType Directory，本质还是 pwsh 原生 Cmdlet；

• Linux/macOS：rmdir 依然是系统 Application（/bin/rmdir）。

同一个「看似通用」的命令，在不同平台可能是 Function、Alias 或系统应用，这正是跨平台脚本踩坑的核心原因——依赖系统级命令，必然受底层平台规则约束。

跨平台脚本的核心解法：认准 pwsh 原生命令

想要一套脚本跑遍所有平台，关键就是抛弃系统命令/别名，优先使用 pwsh 原生 Cmdlet（动词 + 名词格式，如 New-Item）。这些 Cmdlet 是 pwsh 统一封装的，不依赖底层系统，行为和参数在所有平台完全一致。

留言请到：https://mp.weixin.qq.com/s/iE4cPVCP6rRHLG1Neg-8Ew

需求

1. 减少冲突，尤其跨平台协作时。
2. 现代化
3. 提高性能

思考

1. “达成一致”是冲突最少的，然而在跨平台协作时，正是因为过去的 OS 非要搞出 CR、CRLF、LF 三种换行符，才会有“不一致导致的冲突”。macOS 已经早早妥协，由 CR 改为 LF。2026 年的 Windows 也基本投降了。所以目前来说，“达成一致”是比较容易的。

2. 2026 年的 Windows 10/11 依然是最好的 Linux 发行版，是现代化的 OS，“几乎”完美兼容 LF。稣常用的软件也都支持 LF，所以稣个人单方面宣布：世界上只有 LF 这一种换行符。

3. 为了提高性能，autocrlf 必须关掉，因为——世界上只有 LF 这一种换行符！

推论

1. 由于“世界上只有 LF 这一种换行符”，稣在 Windows 上使用 WSL 时，都能保证文本文件的换行符是统一的，不会出现“在原生 Windows 下 clone 的 bash 脚本是 CRLF 换行符，到 WSL 运行它，却发现换行符不对”这样的问题。如果您也常在原生环境和 WSL 下使用同一个仓库，那么把 core.autocrlf 设为 input 就不是个好的方案。

2. LF 比 CRLF 节约硬盘，在 SSD 这么贵的 2026 年，这样的设置对穷稣来说简直是救命。

3. 稣在 Windows 上 clone 的仓库，可以直接复制到 Debian下用，反之亦然。这可太重要了，因为稣经常在 Windows 上 clone 仓库，然后 Debian 那边如果也要用，就不想再从外网慢慢 clone 一遍了，直接内网复制过去更快。

具体操作

在 Windows 安装 Git 时，CRLFOption 这步有三个选项：

• CRLFAlways
• LFOnly
• CRLFCommitAsIs

对应如图：

请选择第三个，即 CRLFCommitAsIs。

如果已经安装好了，不记得之前选哪个，则可以显式设置一下，在 Windows Terminal 管理员模式下：

1
2

git config --system core.autocrlf false
git config --system core.safecrlf true

以上针对本机生效，如果您机器上有多个用户，建议这样做。如果没有管理员权限，那就只能针对当前用户设置了，相应的命令为：

1
2

git config --global core.autocrlf false
git config --global core.safecrlf true

core.safecrlf 的默认值就是 true，这里也显式设置，是建议您不要关掉它。

例外

Windows 上还是有些软件对某些文本文件只支持 CRLF 的，所以需要使用 .gitattributes 来排除它们，比如说：

1
2
3
4
5
6
7
8
9
10

* text=auto eol=lf

*.rc                text eol=crlf
*.inf               text eol=crlf
*.sln               text eol=crlf
*.slnx              text eol=crlf
*.vcxproj           text eol=crlf
*.vcxproj.filters   text eol=crlf
resource.h          text eol=crlf
packages.config     text eol=crlf

注意第一行，它是设置默认换行符为 LF，这符合“世界唯一”的设定，要牢记。

定义

• ESP: EFI System Partition.

问题

稣的 ESP 只有 100MB，前几天更新 BIOS 失败，看日志说是 ESP 剩余空间不足！看来这次的 BIOS 文件比较大！

思考

观测 ESP 剩余 29.9MB，而更新值需要 24.39MB，实际运行却失败，说明更新的文件逻辑上是 24.39MB，但占用的硬盘空间不止，因为实际占用是以簇为单位的，文件内容不一定刚好填满，都会有一定空间被浪费。

但这也说明相差的空间应该差不多，只需要把用不上的 mui 删掉应该能解决。

解决

由于稣的硬盘都开了 BitLocker，所以操作十分谨慎——二话不说，直接删掉。只保留 en-US 和 zh-CN 目录，其余都删除。

具体操作请问 AI。

留言请到：https://mp.weixin.qq.com/s/bFIUyDBqsRb9KnurdcCK_A

观点

几年前就发现 Linux 桌面作为远程桌面服务体验远不如 Windows，今天是 2025 年的最后一天，情况依然如此。

限定

请注意本文只讨论 Terminal Service/RDP 那样【安全】的远程桌面，即本地不能看到远程的操作，远程不能看到本地的操作。VNC 之流或像 VNC 那种本地和远程都能看到同一个本地会话的就算了。

论证

1. 现在大部分发行版都默认采用 Wayland，然而 Wayland 下的远程桌面，都必须在用户已经在本地登陆后才能提供服务。不管是 gnome 的，还是 KDE 的，都是如此，这是由 Wayland 的特性决定的。

2. xrdp 等基于 X11 的方案通过启动独立的 X 会话来支持远程登录，能够在无需本地显示器或未登录时工作，但该会话与本地的 Wayland 会话体验不一致。想要一致的体验，则需要放弃 Wayland，这真是令人惋惜！

3. 使用 xrdp，还会遇到一些问题：如果本地已经登录，则远程登录后，远程会话里部分桌面环境无法正常工作。比如 KDE 会卡在初始化界面，轮子转一段时间后就黑屏了。只能跑一些轻量级的窗口管理器，比如 i3。相反的登录顺序，若在远程已经登录 xrdp 后，想本地登录，也会发生类似的困境——本地 Wayland 会话里的 KDE 卡在初始化界面！本地的桌面环境甚至不能用了！

再来看看 Windows 的 Terminal Service 是多么优秀！体验好还安全。

1. 当本地已经登录，可以远程登录，本地会话被切到远程会话，之前在本地打开的应用，在远程会话里都在，能直接使用。

2. 当远程登录在前，则在本地输入用户密码，可以把远程会话抢到本地，并踢掉远程连接。

3. 经过一定配置，可以让 Windows Server 能够同时运行多会话，即本地和远程不需要抢夺唯一的会话，可以同时登录并使用各自会话。

1. 《八哥之神》到底在说啥？

简单地说，是人类的一生。但是很多人看不懂，比如：

• 有人看了前两篇，就说猜不到这到底是哪种题材的。
• 有人看了里面的恋爱故事，说作者本人肯定没谈过恋爱，自己瞎编的。
• 还有人觉得，这就是作者本人的真实故事，只是故意把情节改得像假的。

其实，只要稣正正规规地写，那么肯定只要是人类就应该能看懂，这真的就是普通人类的一生——莫名其妙得到，又无可奈何失去。但问题是，稣故意写得很不正经。

不过其中有一个很正经的中心思想：爱情诚可贵，自由价更高。若有长生术，两者皆可抛。

它还有以下特点：

• 真假莫测，处于叠加态。但有个原则：剧中每个人都可能在说谎，听剧中角色说的，未必是真。只有上帝模式的旁白才是真的。当然剧中是真的，对作者的视界来说也可能是假的。总之每个人都可能吹牛，都可能在混淆视听。比如：稣明明是想泡学妹（八哥之神后传【11】），却先讲学姐（《八哥之神后传【10】》）。

• 常见的套路是：先说一个离奇的故事，然后吓醒，接着开始一本正经聊宇宙观、人生观，说着说着吹起牛，顺势谈起恋爱，喂狗粮的同时，又暗示这些爱情故事不像真的。如此循环。

• 时间线是错乱的。八哥系列只有写作顺序，没有所谓“最佳阅读顺序”。必须把《八哥之神》的四个系列都看了，才是完整版。其中最先写作的《八哥之神》说的是 2018 年 9 月 11 日开始的故事，而接下来的《八哥之神前传》其实应该叫《后传》，写的主要是更后面的时间，但也有部分是比 2018 年更早的。所以又引出《八哥之神后传》在写最早的时间段，其实它叫《前传》更正确。但是作者为了不让观众轻易看懂，故意写反。

• 《外传》里会有隐藏情节，有辟谣，也有迷惑性的辟谣式造谣。

2. 写这种难懂的故事，意义何在？

男人一生的意义就是谈恋爱，赚钱只是为了能谈恋爱、更好地谈恋爱，您不会以为还有其它意义吧？

女人一生的意义就是谈恋爱，自己赚钱，还要求男人赚钱只是为了能谈恋爱、更好地谈恋爱，您不会以为还有其它意义吧？

鲸神链就是人生最大的意义。《八哥之神》写的就是鲸神链。

AI 只能学会谈恋爱的套路，它根本无法明白进入十界的秘密就藏在鲸神链里。

3. 为何不描述人物的长相？

这也是故意留给读者自己想象的。技术上说，稣不是很看重长相，不过稣比较喜欢菩萨相的异性。所谓的菩萨相就是：

• 真正的菩萨相就是无性别。
• 有菩萨相的男人，内心平静，外表会有些像女人，但不娘不基。
• 有菩萨相的女人，内心平静，外表会有些像男人，但不是男人婆、不是野蛮女友。

若以貌取人，很多时候会带来误会。比如这段隐藏剧情：

讲诉人模式，圣小开对 JC 的评价

JC 虽然看上去又酷又飒，颇有智慧相，其实，是个笨蛋。有一次，稣开启话题说她是单眼皮，她似乎以为稣在说单眼皮不好看，但她又不太服气地说自己可以变成双眼皮，然后竟然当场给稣表演起来，用手遮住眼睛，然后再打开，真的短时间变内双了……

其实，稣想说的是——稣喜欢单眼皮的女生。

要不要告诉她呢？算了，暗恋就好，说破了不就是早恋吗？

记住：不要评价异性的长相如何是好、如何是坏，您就说自己喜不喜欢就得了！

4. 细说菩萨相？

人们常说“菩萨畏因，众生畏果”，剧中身为文殊菩萨转世的稣，其实一直都不愿沾染别人的因果，不是自己的转身就放弃，只有自己的“因”才去参与。

虽然六舅给稣安排了 18 个女朋友，但不是稣真心喜欢的，自己送上门来也不要，和自己真正喜欢的才会有故事。虽然这样随时高冷无情，又随时嘻嘻哈哈的稣，有些渣男的潜质，但请注意——稣是鲸神链。

稣喜欢菩萨相的女人，那种一眼看上去就是特别女人的女人，稣是一点都不喜欢……

有菩萨相的女人剧中有两位，按写作顺序是：秦阳和 JC。其中，秦阳这个名字一看就是男名，就是赤裸裸地暗示了。而 JC 是有明确交代的。

5. 据说有巨量遗留的八哥？

显然的，八哥怎么可能没有八哥？最明显的就是《八哥之神【27】》没写！偷偷地说，有人认为 27 是“爱妻”的谐音，所以故意不写。其实，这是不对的，27 是“二妻”的谐音，所以是被迫不写。

还有一个大八哥是——六舅安排稣有 18 个女朋友，实际远远没达标。em，虽然这个故事是从稣大学时就开始写的，但当时写了一点点就写不下去，后来听了周边人很多狗血故事才于 2019-01-19 开始写，当时六舅要求稣把他也写进去。稣想到六舅是个预言家，恐怕会对八哥宇宙产生巨大影响，就安排他一出场就被动车撞飞了，至今还在飞，还没安排啥时候落地。

说回 18 个女朋友。这是在说剧中的圣小开，但由于作者也叫圣小开，在现实视界中也常常自称稣，所以确实引来一些误解。其实稣更喜欢有些读者的评价：

程序员懂啥爱情！都是编的，而且编得很中二。

em，稣确实不是很懂爱情，但《八哥之神》说的是鲸神链啊！爱情是什么狗屁，一点都不想懂……

好吧，补齐一下 18 个女朋友的故事：

女友 A：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 B：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 C：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 D：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 E：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 F：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 G：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 H：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 I：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 J：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 K：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 L：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 M：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 N：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 O：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 P：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 Q：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

女友 R：《八哥之神》写完告诉我，到时候我连着看。
稣：还早，说不定还没写完，稣已经吓醒，你也就消失了。

6. 认识 JC 的时候她几岁了？后来怎么了？

14 周岁，这个没八哥。后来的事情，不方便透露，【正经】因为现实视界中她还活着。但肯定的是：

• 转世后她不记得稣了，稣也不知道她现在叫什么。
• 她现在很有钱，因为稣曾经在梵天寺的每尊佛面前都许愿要让她发大财。

7. 这是最后一篇了吗？

不太确定，八哥系列故事一写就写了六年，说明稣并不擅长编故事。后续还得和六舅商量一下还能怎么编。

也许等 AI 能分析明白全剧的时候，并能把《八哥之神【27】》补出来，出个 pdf 版吧。现在喂给 AI，出来的完全没有高冷的灵魂，没有平静无奇的逼格。可能 AI 太卖力了！而稣只是随时随地分享随意编造的故事。