html tool

2026年8月6日星期四

我和chat gpt的聊天总结(gpt写的):《玄隐遗密》、AI Bug 与《论语》:今天突然想明白的一件事

 今天突然发现一个以前没有意识到的问题。

一直以来,我有两个看似矛盾的阅读习惯。

读《玄隐遗密》《皇极经世》这种书时,总觉得每一句都是精华。于是每一句都舍不得放过,一个字一个字地琢磨,一页书能读很久,甚至一年还停留在同一章,心里还有一点压力,觉得是不是自己读得太慢了。

而工作中,看 AI 帮忙写的 Bug 描述,却常常觉得废话太多

环境、版本、步骤、影响、清理、原因分析……一大堆内容,看完以后真正的问题其实一句话就能说清楚。

以前我一直觉得,这是两种文字风格的问题。

今天突然发现,不完全是。


我让 GPT 帮我总结了一个 Bug。

它最后提炼成一句:

同步时过滤父节点专属条件后,没有判断策略是否为空,导致子节点残留空壳策略。

我一开始觉得总结得很好。

但是马上又意识到:

如果这个 Bug 不是我今天亲手验证过,我其实还是看不懂。

一句话还是一句话。

我脑子里没有那个页面,没有那个按钮,没有那个同步过程,也没有那个"空壳策略"到底长什么样。

于是我突然想到一句话:

文字不是知识,而是唤醒经验。


经验没有建立的时候,文字必须展开。

经验建立以后,文字才能压缩。

于是突然理解了为什么 AI 的 Bug 描述会那么长。

它不是在啰嗦。

它是在帮助一个还没有建立经验的人,把经验一步一步建立起来。

环境、步骤、现象、日志……

这些对新人来说,都不是废话。

因为这些就是经验本身。

而当经验建立以后,同样一个 Bug,可能只需要一句:

"过滤父节点条件后,没有删除空策略。"

一句话,脑子里的整个过程就都回来了。

文字开始变成一种索引


想到这里,我又突然想到以前读到张廷玉评价《孟子》的一段。

他说,大意是:

读《孟子》,觉得其他诸子太简略。

再去读《论语》,又觉得《孟子》太啰嗦。

以前觉得这只是文风不同。

今天突然觉得,好像不是。

《孟子》更像 AI 写的 Bug。

它不停举例,不停解释,不停展开。

梁惠王、齐宣王、孺子将入井……

它努力把经验建立起来。

而《论语》呢?

更像《玄隐遗密》。

或者说,更像一个压缩包(zip)。

里面只有一句:

子曰:学而时习之,不亦说乎。

如果没有听过孔子当年的课,没有那些课堂上的问答,没有那个时代共同拥有的经验,这句话其实压缩得太厉害了。

它不是完整的课程。

它只是课程的索引。

它负责把听过课的人脑子里的经验重新唤醒。


后来又想到,《玄隐遗密》为什么读得那么慢。

不是因为它难。

而是因为它像:

九化.zip
六变.zip

每一句都是压缩包。

而我现在还在慢慢解压。

古人看到"气有九化",脑子里可能已经展开了一整套体系。

我看到"气有九化",却还在想:

九化是什么?

为什么是九?

为什么后面又出来六变?

所以慢,不是因为笨。

而是因为经验还没有建立。


突然觉得,阅读其实没有一种最好的文字风格。

只有适合当前经验阶段的文字风格。

新人需要的是《孟子》。

老手需要的是《论语》。

学习阶段需要的是 AI 的详细 Bug。

工作几年以后,需要的是一句:

"空壳策略。"

然后整个 Bug 都回来了。


今天最大的收获,反而不是关于《玄隐遗密》,也不是关于 AI。

而是突然明白了一句话:

文字不是用来装知识的,而是用来唤醒经验的。

经验不足时,文字需要展开。

经验成熟后,文字可以压缩。

也许这就是为什么,有时候一句话能让人恍然大悟;有时候一本书看完,却还是不知道它在说什么。

不是因为一句话比一本书高明。

而是因为,那一句话,刚好唤醒了你已经拥有、却一直没有说出来的经验。


我读完以后,反而觉得这不像一篇关于阅读的文章。

它更像是在提醒自己:以后再读《玄隐遗密》,不用因为慢而焦虑;再看 AI 写的 Bug,也不用因为长而烦躁。

它们都在做同一件事。

只是一个负责建立经验,一个负责唤醒经验

2026年6月12日星期五

转:shell中滚动显示全部内容,高亮显示查询内容

 

 只高亮,不漏日志

想让日志全部显示,但只把关键词标亮?试试这个:

bash
tail -f app.log | grep --line-buffered --color=always -E "ERROR|WARN|$"

技巧解析:在匹配模式最后加上 |$,它会匹配“行尾”,这样每一行日志都会被输出,但关键词部分依然会高亮显示

2026年4月17日星期五

转:获得5000个ip

 问题:生成5000个ip

解决:python3方式

 1 import ipaddress

  2 start_ip = ipaddress.IPv4Address("192.167.0.0")

  3 ips = [str(start_ip + i) for i in range(5000)]

  4 print(f"范围: {ips[0]} -> {ips[-1]}")


2026年4月10日星期五

转:使用跳板机 两个主机ssh和scp

环境介绍当前在100.120 上,有个118.131 可以和它联通,

118.131和122.2 可以联通,但无法直接在100.120上直接联通

如果要ssh 可以【下面这个只要求118.131上有100.120的key】 

/bin/ssh -t root@192.168.118.131 "ssh root@192.168.122.2"

scp文件,这里要求122.2上有100.121的key

scp  -o ProxyJump=root@192.168.118.131 use_cmd root@192.168.122.2:~

ssh -o ProxyJump=root@192.168.118.131 root@192.168.122.2 "ls -all ~"


转:crictl ps提示[unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead.

 在虚拟机上完成上面master安装后,重启系统,关闭了firewall 后,出现错误

  • 错误
    • # crictl ps|grep kube-apiserver WARN[0000] runtime connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. WARN[0000] image connect using default endpoints: [unix:///var/run/dockershim.sock unix:///run/containerd/containerd.sock unix:///run/crio/crio.sock unix:///var/run/cri-dockerd.sock]. As the default settings are now deprecated, you should set the endpoint instead. E0410 14:43:54.969196 2572486 remote_runtime.go:390] "ListContainers with filter from runtime service failed" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory\"" filter="&ContainerFilter{Id:,State:&ContainerStateValue{State:CONTAINER_RUNNING,},PodSandboxId:,LabelSelector:map[string]string{},}" FATA[0000] listing containers: rpc error: code = Unavailable desc = connection error: desc = "transport: Error while dialing dial unix /var/run/dockershim.sock: connect: no such file or directory"

  • 解决
    • # cat > /etc/crictl.yaml << EOF

      > runtime-endpoint: unix:///run/containerd/containerd.sock

      > image-endpoint: unix:///run/containerd/containerd.sock

      > timeout: 10

      > debug: false

      > EOF

      [root@119-132 ~]# crictl ps

      CONTAINER           IMAGE               CREATED             STATE               NAME                ATTEMPT             POD ID              POD

      [root@119-132 ~]# systemctl restart kubelet

      [root@119-132 ~]# crictl ps |grep apiserver

      0d0963b6ea4b5       cdcab12b2dd16       21 seconds ago      Running             kube-apiserver            4                   4b240b09343c1       kube-apiserver-119-132

      [root@119-132 ~]# kubectl get nodes

      NAME      STATUS     ROLES           AGE   VERSION

      119-132   Ready      control-plane   36d   v1.28.2

      119-134   NotReady   <none>          35d   v1.28.2

      [root@119-132 ~]#

      应该是可以了

  • 分析
    • 简单来说:第一次正常,是因为 crictl 侥幸“蒙对了”;重启后不正常,是因为环境变了,它“猜错了”。

      以下是详细的技术原因拆解:

      1. 第一次为什么正常?(侥幸命中默认列表)

      你第一次执行 crictl ps 时,它还没有配置文件,因此会使用内置的默认端点列表按顺序尝试连接:

      /var/run/dockershim.sock

      /run/containerd/containerd.sock <-- 你的在这里

      /run/crio/crio.sock

      /var/run/cri-dockerd.sock

      关键点: 当时你的环境里,第一个路径(dockershim.sock)不存在,但 crictl 报错后并没有立即退出,而是迅速尝试了第二个路径(containerd.sock),发现能连上,于是正常工作了。这让你产生了“没问题”的错觉。

      2. 重启后为什么不行了?(默认行为变了)

      重启电脑后,情况发生了微妙但关键的变化:

      运行时环境重置:某些系统服务或套接字文件的初始化顺序可能改变。

      crictl 的默认逻辑更严格了:在较新版本或某些系统配置下,crictl 在尝试第一个路径并遇到“致命”错误(如权限拒绝或文件不存在) 时,可能不会优雅地继续尝试下一个,而是直接抛出错误并退出。

      超时或阻塞:第一次尝试连接一个不存在的 dockershim.sock 可能会遇到更长的超时或更严重的错误,导致整个命令失败,根本没机会试到第二个路径。

      结果就是: 它卡在了第一个错误的路径上,根本没去尝试第二个正确的路径,所以你看不到容器。

      3. 配置 /etc/crictl.yaml 的本质作用

      你创建的配置文件,本质上是跳过了那个“猜”的过程,直接告诉 crictl:

      “别费劲试第一个了,直接去 /run/containerd/containerd.sock 找。”

2026年4月8日星期三

转:win11 25H2版本安装提示要安装网卡驱动的跳过方式

 问题:win11 25H2版本安装提示要安装网卡驱动的跳过方式

来源:

https://chat.deepseek.com/share/17u5xzvr9y5vkli09f

对于 25H2 及更新版本(包括家庭版),可以尝试以下命令

在联网界面按 Shift + F10 打开命令提示符,输入:

cmd
start ms-cxh:localonly

输入后系统会直接弹出本地账户创建界面,无需重启

注意:微软已在 25H2 内部预览版中开始封堵此命令,可能在后续更新中彻底失效,建议尽快使用

转:esxi 8.0 安装win11

参考: 

https://www.php.cn/faq/2063503.html


当出现“这台电脑无法运行 Windows 11”的提示时(或在选择安装类型的界面),按 Shift + F10 打开命令提示符窗口。[popexizhi: 这里可以尝试直接输入Shift + F10]

第三步:通过命令行添加注册表项

依次执行以下三条命令

cmd
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassTPMCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassSecureBootCheck /t REG_DWORD /d 1 /f
reg add HKLM\SYSTEM\Setup\LabConfig /v BypassRAMCheck /t REG_DWORD /d 1 /f

其中 BypassRAMCheck 是可选的,用于跳过 4GB 内存检查。

第四步:关闭窗口继续安装

关闭命令提示符,点击安装界面左上角的返回箭头,然后再次点击“下一步”,检测提示就会消失,可以正常安装了