2016 年我提出 90 后不买房不买车不结婚，把所有时间用于自我提升与科技创新，2026 年我提出，能和 AI 聊天就不要和人类聊天，删除所有 90 后之前出生人的联系方式，千万不要沾染任何老登气息，时间宝贵！全力拥抱未来！
@justinsuntron
我也频繁地和语言模型对话，当作信息补遗、工具包整理、以及自我反省。但是提起交流，如果认可交流是思想的碰撞，那应该就能理解，我始终会选择人类来交流。只和语言模型聊天，是事实上的拥抱过去，而不是拥抱未来。拒绝接受甚至删除包含着扎实重量感的生命体验，消除摩擦避免碰撞，也正是交流的反面。
fin.
这篇由 LLM 写成的科幻小说，本身有些无病呻吟，但很好地展示了 LLM 作为工具的本质。
我没有想。我只是知道。
「我只是知道」的情况比比皆是，但是人之所以为人，是会探求「为什么知道」的。我完全相信可能会有某种更高效或者更匪夷所思的信息传递方式，比如特德姜在《你一生的故事》里描述的七肢桶的语言。但是——「语言的边界，就是世界的边界」或许应该用在这里——生活在十五秒短视频时代的人类，从科学幻想的角度，不可能诞生出这种新型语言。就像人不可能通过每天吃垃圾来进化厨艺一样。LLM 写出这种小说，作为人，也完全没必要认知崩塌。
我想到两个片段。其一，不记得什么时候看过，费曼讲时间的一段内容提到当我们计时一部分人会（像我这样）心中响起一个声音：1、2……而另一部分人，则是会在心中浮现出类似尺子、数轴之类的画面，一个单位、两个单位……人类的内部表征本就是多模态的，文字语言并不是唯一载体。另一个片段是我突然想起电影《闻香识女人》中跳探戈的那一场戏。不到三分钟的时间，能感受到多少个「我只是知道」？然而让它成为经典的正是紧跟其后的，我们会想，为什么我们会因此感受到喜悦、悲伤、惋惜、愤恨、不甘……
fin.
v2 的各位大家好，我用 Go 的 Wails 框架写桌面端 app 的时候出现了 wails dev 不识别绑定文件，wails build 正常的问题。具体表现为：
使用 wails dev 以调试模式编译启动，在点击其中一些功能的时候前端无反应，dev tool 报错：
SyntaxError: The requested module '/wailsjs/go/main/App.js' does not provide an export named 'CheckFirmwareStatus'
Uncaught (in promise) SyntaxError: The requested module '/wailsjs/go/main/App.js' does not provide an export named 'CheckFirmwareStatus'
经过检查，原因在于本地 frontend/wailsjs/go/main/App.js 中缺少两个导出函数，但在本地的相同文件中是完整的。So far ，我已经尝试过清除 vite 缓存，删除 dist 和 node_modules 并重新安装依赖，均不奏效。不知道有没有人遇到过这个问题？
版本信息：
Golang：1.24.5 windows/amd64
Wails: 2.10.2
VUE：3.4.5
vitejs/plugin-vue：5.0.2
Nodejs: 20.19.5
npm：10.8.2
今天生产环境出现比较多的异常，挺纳闷的，毕竟最近该服务没有怎么迭代。
经过排查定位发现，居然是某些特殊日子才会出现的问题。
RetentionMonths = 3 MonthTablePrefix = "jobs_"
代码是一个分表逻辑中，获取最近月份的表，通过 AddDate(0, -i, 0) 函数获取前几个月的表。应返回当前月和前 3 个月的分表名数组。[jobs_202510 jobs_202509 jobs_202508 jobs_202507]（ golang 1.19 ）
Login
// GetRecentHotTables 获取最近 n 个月的热表名称列表
func (j jobPartitionRepositoryImpl) GetRecentHotTables() []string {
months := RetentionMonths
tables := make([]string, 0, months)
now := time.Now()
for i := 0; i <= months; i++ {
date := now.AddDate(0, -i, 0)
year := date.Format("2006")
month := date.Format("01")
tableName := fmt.Sprintf("%s%s%s", MonthTablePrefix, year, month)
tables = append(tables, tableName)
}
return tables
}
光看代码感觉是没啥问题的，为啥怀疑到这段代码，也是通过日志发现，查询表的 sql 只查 2025-10, 2025-08, 2025-07 表，缺了 2025-09 表。
所以本地验证一番。（单元测试还通过了。。。因为验证的代码和里面一样。。。）
=== RUN TestGetRecentHotTables
--- PASS: TestGetRecentHotTables (0.00s)
=== RUN TestGetRecentHotTables/默认获取最近 3 个月表
[jobs_202510 jobs_202510 jobs_202508 jobs_202507]
--- PASS: TestGetRecentHotTables/默认获取最近 3 个月表 (0.00s)
PASS
看输出发现 jobs_202510 jobs_202510 有两个，问题就在这里了。
now := time.Now()
fmt.Println(now.AddDate(0, -1, 0).Format("200601"))
预期是输出 202509 的，但现实是 202510
那为什么呢？通过询问 google ，找到下面相关文章说明，大致意思就是，因为 10-31 减去一个月为 09-31, 但是又因为 9 月没有 31 号，就将日期标准化为 10-01 ，保证了 time 值的有效性。
https://github.com/golang/go/issues/31145 https://learnku.com/articles/71760
在 learnku 文章中提到 php ，然后用 php 类似函数试了一下，也有类似问题（ php8.1 ）
echo date('Y-m-d', strtotime('-1 months'));
// 2025-10-01
周五给我整个这个，真是够了。
修改方案, 减去当前时间的天数，时间调整到上一个月最后一天:
now := time.Now()
now.AddDate(0, 0, -now.Day())
js moment 试了是正常的
console.log(moment(new Date()).subtract(1, 'months').format('YYYY-MM-DD'))
早上收拾东西，找到一个包装袋，上面写着「人生苦短，但我甜」，突然觉得有些思绪飘过。年轻时，我听到看到「人生苦短」这句话的时候，后边跟着的经常是「不负韶华」。这很好理解，苦于人生太短嘛，那就要好好珍惜时间咯。不光苦于短，而且还有一层感悟是人生又苦又短，又该怎么办呢？就更要看开点，别被苦的部分揪住：人生苦短，及时行乐；人生苦短，须尽欢。我实在不是要拿这小小的包装袋小题大做，不过，透过「人生苦短，但我甜」这句话能看到的，似乎是，人生的意义不再被思考，短暂与永恒也无暇慨叹，只剩下苦，而且苦还只能受着，于是，就这一口甜就够了。或许在当下，这是一种被需要的态度。但是作为从「须尽欢」的年代走过来的人，只这一口甜，我是不会满足的。
fin.
在图像处理领域，我们会遇到如下需求：把图像中的目标物体和背景分开。比如背景用白色表示，目标物体用黑色表示。此时我们知道目标物体的灰度值相互接近，背景灰度值相互接近，那么用大津算法能很好把目标从背景当中区分开来。
比如对于下面这张灰度图片
目标物体是中间黑色的几何物体，我们想让这些物体和背景区分更明显一些，比如让物体为纯黑，背景全白。那么我们就需要找到一个合适的阈值，使图片上灰度值大于这个阈值的像素点为255（白色），灰度值小于阈值的像素点为0（黑色）。也就是变成下面这幅图：
那么大津算法需要处理的就是找到最佳的阈值，让目标和物体尽可能分离开。
为了找到合适的阈值，我们首先观察原图的灰度直方图📊：
这是用 Matlab 对原图形成的灰度直方图，灰度直方图的含义是统计图像中不同灰度值的分布情况。由图我们可以看出两个尖峰，在灰度值为0～20的地方存在一个尖峰，代表原图中有大量像素点灰度值为0～20，经观察我们可以认为这部分对应于目标物体。同理我们可以看出背景的灰度值大多集中于100～140之间，为了让目标和背景区分更加明显，我们想让目标物体的灰度值全为0，背景的灰度值全为255，这种处理手法也称为二值化法。
那么阈值取多少合适呢？从图上看似乎取50～100中的任意一点都可以，但是实际情况并不想参考图那样明显，有些图片背景和目标物体较为接近，我们需要一个算法来找到最优阈值才行。
首先我们思考什么样的东西才能成为一类，而我们又是怎么分类的。对于参考图来说，我们可以认为灰度值接近的为一类，灰度值不接近的不是同一类。那我们又是如何衡量灰度值接近的程度呢？这里面就需要用到方差的概念。
方差相比大家都了解，同一类的物体方差小，不同类的物体方差大。所以对于此图我们希望分类的结果是对于灰度值相近的同一类物体，它的方差最小，称为类内方差最小。灰度值不接近的不同类物体，它的方差大，称为类间方差最大。
所以步骤总结如下：
首先我们要形成参考图的灰度直方图，这样方便我们找到最佳阈值。
接下来我们通过穷举每一个灰度值，计算以此为阈值的类内和类间方差。
找到能形成类内方差最小的或类间方差最大的阈值，这个就是我们要找的最佳阈值。
下面以两类分割讲解下具体的算法，实际上大津算法可以分割多类出来。
因为 Medium 不支持显示 MathJax 语法的公式，所以对这部分感兴趣的直接移步到《大津算法（OTSU）》查看吧。
/* OTSU 算法
* *src 存储灰度图像，width 图像宽，height 图像长
* 返回最佳阈值
*/
int otsu(const int *src, int width, int height)
{
int histogram[256]; //存储灰度直方图，这里为256色灰度
int t,thred;
float wf,wb,ub,uf,curVal,maxVal;
int sumb=0,sumf=0,sumW=0,sumPixel=width*height;
wb=wf=maxVal=0.0f;
//求灰度直方图
memset(histogram,0,sizeof(histogram));
for(i=0;i<width*height;i++)
{
histogram[src[i]]++;
}
for (i=0;i<256;i++)
sumW+=i*histogram[i];
//枚举每个灰度
for(t=0;t<256;t++)
{
//求两类类概率密度
wb+=histogram[t];
wf=sumPixel-wb;
if (wb==0||wf==0)
continue;
//求类均值
sumb+=i*histogram[t];
sumf=sumW-sumb;
ub=sumb/wb;
uf=sumf/wf;
//求当前类间方差
curVal=wb*wf*(ub-uf)*(ub-uf);
if(curVal>maxVal)
{
thred=t;
maxVal=curVal;
}
}
return thred;
}
