我也发现了这个问题。 同一个功能，我分别让 grok 、claude code 和千问生成代码，他们生成的函数名称和代码注释居然出奇的一致。可能训练的数据抄袭了相同的开源项目吧。

最近我用 AI 辅助开发 DNS DoH 的代理工具，也算是深度使用 AI 。帮助有不少，但不能指望太多。Vibe Coding 差不多是胡扯。AI 生成的代码作为原型验证和概念参考尚可，基本能跑通逻辑就算成功，然而维护性基本为零、可靠性和健壮性也没有。其次，AI 不知道现实世界的细节和 bug ，只是当你提问到具体细节的时候，它才可能意识到没考虑那个具体问题，它也无法很好的解决。问题是，当你提问具体细节的时候，你已经踩到坑。我本地测试很多问题都没有，部署到服务器会遇到各种奇怪的 DNS ，比如，同一时间多个重复的 DNS 请求，需要丢弃；有些查询返回了域名不存在，需要负缓存；以及 type 65 类型的 DNS 需要转发等各种问题。两天跑通主逻辑，然后逐个解决这些细节问题却花了我将近两周。

设计上，AI 给我的代码是多线程。测试时最多开 40 个线程，结果只有 1200 的 QPS 。而我自己重写的代码单线程多协程，只用一个线程就有 2600 个 QPS ，性能差太多，AI 只会生成无脑浪费计算资源的代码。它会抄作业，却不懂编程，不懂设计。写的代码也很难看，一个函数超过屏幕还多一大半，我不知道怎么维护这种东西，还是需要自己拆分和重新设计模块和接口。

正如 Frederick P. Brooks 多年前那篇论文，《没有灵丹妙药——软件工程中的本质性和附属性》。软件开发的困难分为两类：本质性困难，比如抽象概念的构建，数据、算法的构建工作（解决这些问题需要程序员一点想法）；附属性困难则是抽象概念映射到具体机器和代码，比如编译和语言错误等。软件工程领域，没有任何一项语言、技术或管理上的突破，能像硬件领域那样在十年内让生产力、可靠性或简洁性得到数量级的提升。包括 JetBrains 这些 IDE 工具，它们主要解决了附属性困难，却无法帮助降低本质性困难。现在 AI 出来，本质性困难得到解决了吗？

AI 对我最大的帮助并不是生成代码，而是搜索文档的效率显著提高，原本需要自己 Google 逐个打开网页看资料，现在比如要看 DNS 的报文格式，只需要让它告诉我就行，自己参考格式去解析，省掉了搜资料的过程。

复制 AI 代码的时候我也意识到侵权问题，AI 返回的代码里难免包括开源作品，我使用它的代码会无意中侵权。作者本人同意吗？这还不是最关键的，关键是用户不知道自己使用了谁的代码。如果我用了别人的代码，我会附上他的 Lisence ，表示对他人工作的尊重。现在这样侵权，我都不知道侵权了谁。未经同意、没有报酬，就随意拿别人的辛勤产出作为训练数据，伤害了那些认真做事的人。

@exploreexe #66 有报道偏见的成分。燃油车碰撞起火，汽油易挥发的特性，爆燃留给人逃生的时间更短。“玛莎拉蒂撞宝马案”，后排乘客被烧亡，驾驶员幸存但烧伤达 40%。新能源车电池即便起火，好歹锂电池起码不会挥发，从后排烧到前排需要一点时间，有机会逃生。只是电池起火难以扑灭，扑灭会可能再次起火。

2020 年 11 月，宝马一个月内就自燃了三辆。https://zhuanlan.zhihu.com/p/320053699
2018 年，宝马在韩国接连自燃 48 起，宝马被韩国 zf 禁止上路。https://www.unecne.com/archives/63758

即便如此，大家的印象仍然是宝马燃油车不会自燃，因为这些新闻从来不会上头条。但电车每一起火灾事故基本都成新闻头条了。

@neptuno #65 分母是总保有量，不是当年的销量。

2022 世界动力电池大会上欧盟院士、中科大教授、937 计划首席科学家孙金华表示，“目前，电动汽车起火率约为 0.03%，略高于传统燃油车。从起火汽车所处状态来看，35%处于充电状态，40%处于行驶状态，25%处于静止状态”。

美国国家运输安全委员会（ NTSB ）数据，电池电动汽车火灾的可能性仅为 0.03%，相比之下，燃油车为 1.5% ，混动为 3.4%。 https://www.renolon.com/electric-car-fire-statistics/

基于应急管理部消防救援局的数据，
2022 年 1 季度，新能源车火灾事故 640 起。https://www.119.gov.cn/article/47Sd3LDSJrA
2021 年全年，新能源汽车火灾共发生约 3000 余起。https://www.119.gov.cn/article/46TiYamnnrs
2020 年不完全统计，新能源汽车火灾共发生约 72 起。https://zhuanlan.zhihu.com/p/363323648

累计到 2022 年 1 季度，新能源火灾事故约 3800 起，同时新能源车保有量 891.5 万辆，计算为万分之 4.1 。
随着新能源车的销量迅速增加，反而（充电和行使）发生火灾的概率在不断下降，因为新的电池技术不断更安全。

只是学，很难学到理解深刻的东西。只要在项目中才能成长。我个人来说，我开始阅读 Python 的标准库源码时是进步最快的一段时间，因为发现它的那些设计都比较简单和清晰，代码很容易就能看懂；相比之下，自己设计的项目就显得很难看。

没学过 java ，不过你的设计肯定是有问题的。
基类就不应该调用派生类的任何东西，不管技术上能不能实现，你都不应该这么做。
这是一个道德性原则。

比亚迪 7 月份卖了 13 万辆，7 月份卖了 16 万辆。作为比亚迪的小股东，建议还是不要买比亚迪了，排队等车要半年。

楼上说比亚迪高自燃率，纯属尬黑。
比亚迪的销量和占有率是最高的，去年和今年已经卖了超 140 万辆。火灾事件与它的保有率相比，火灾事故率不足万分之一，火灾概率比传统油车低。

没有全职，不过我的投资收益也稳定，年化 20%+。 今年目前是 55%

房价太贵了，我手里的钱也够全款买套房，但是不值得。辛苦赚来的钱白白被剥削，跟傻子一样帮人打工。
持有股票的投资收益比买房好太多了。

@anonymous256 像 Linux/Win 这类可以“实时”交互的系统，此处的“实时”应该打个引号。因为本质上它不是实时的，是操作系统的中断程序调度出来的“伪实时”，CPU 进程调度切换太快，让用户感觉是实时的，其实不是真正的实时。

@cmu2chert 计算机执行多任务，就要考虑不同的任务之间是否允许抢占。
1. 例如批处理操作系统，它是不允许被抢占的。你提交一系列的任务，计算机会按照顺序一直到执行结束，这期间无法干预。
2. 像 Linux/Win 这类可以实时交互的系统，都是允许被抢占的。比如听着音乐，打着游戏，还能打开网页，因为新增的任务抢占了前面的任务。原理是：CPU 的计时器以固定的频率触发中断，然后 OS 执行调度算法，调度不同的进程，实现不同任务的上下文切换。

集体利益高于一切，在中国是很普遍的想法。家庭就是一个小集体。有多少人结婚、买房、生育并不是因为他们自己想要那么做，而是由于父母和家人的要求？许多人也是自愿接受了控制。这种价值观从家庭到学校、社会、公司、行政单位，无处不在。

举个例子，一个人明明几个月都没出小区，却还要强制几天一次的无意义核酸，个人的声音得不到尊重。又或者，疫苗接种明明是“自愿”的。但如果你不接种，居委会就三天两头打电话催促你，所谓“自愿”并不存在。

有共同志向的人为集体事业奉献自己，那也无可厚非。只是，有些集体以公共利益来强迫个人做奉献，规定别人的 人生。本质不是集体导向的价值观，而是法西斯。

电车。 比亚迪

我之前的邻居也是楼道养狗，经常把垃圾袋放门口。
现在整个楼的邻居都把垃圾放楼前树下，明明垃圾回收点就在 50 米的不远处。
我在拼多多定制了个“公告牌”，写了：垃圾不要扔树下，小区环境靠大家。情况稍微好了一点，但还是有人喜欢把垃圾扔旁边。拿他们没辙。

王小波-- 《居住环境与尊严》
http://www.vrrw.net/hstj/18331.html
《门前空地》
https://www.ihuaben.com/book/8188032/51963453.html
《环境问题》
https://m.fanwenxiansheng.com/article/20220320/988ea86.html

不要局限于一个小的方向吧，多关注语言自身的特性和设计，关心更多的编程语言、系统、算法，视野也就更开阔了。

油价还会继续涨价的可能性很高，因为欧盟通过了对俄罗斯的能源制裁。原油可能会涨到 150 美元以上。中国原油进口的占比是 70%+，国际油价涨，国内汽油就同等幅度跟涨。

在你的触发器函数里面，解开函数调用栈就可以了。三种常用的办法：

1. gcc 内置宏__builtin_return_address：非常粗略的低级方法。这会在堆栈上的每一帧上获得函数的返回地址。注意：只是地址，不是函数名。所以需要额外的处理来获取函数名。
2. glibc 的 backtrace 和 backtrace_symbols：可以获取调用堆栈上函数的实际符号名称。
3. libunwind 库

参考自： https://eli.thegreenplace.net/2015/programmatic-access-to-the-call-stack-in-c/

根据上述文章提到的办法，采用 libunwind 库，我简单修改了下它的代码:
1. 代码示例

```
// example.cpp

#include <libunwind.h>
#include <stdio.h>

// Call this function to get a backtrace.
void backtrace() {
unw_cursor_t cursor;
unw_context_t context;

// Initialize cursor to current frame for local unwinding.
unw_getcontext(&context);
unw_init_local(&cursor, &context);

// Unwind frames one by one, going up the frame stack.
while (unw_step(&cursor) > 0) {
unw_word_t offset, pc;
unw_get_reg(&cursor, UNW_REG_IP, &pc);
if (pc == 0) {
break;
}
printf("0x%lx:", pc);

char sym[256];
if (unw_get_proc_name(&cursor, sym, sizeof(sym), &offset) == 0) {
printf("(caller function: %s+, offset: 0x%lx)\n", sym, offset);
} else {
printf(" -- error: unable to obtain symbol name for this frame\n");
}
}
}

void foo1() {
backtrace(); // <-------- backtrace here!
}

void foo2() {
backtrace(); // <-------- backtrace here!
}


int main(int argc, char **argv) {
foo1(); // <-----在函数 foo1()和 foo2()中可以看到整个的调用栈。
printf("\n");
foo2();
return 0;
}

````

2. 编译前安装依赖（以 ubuntu 为例）:
sudo apt install libunwind-dev

3. 编译指令:
g++ -o example example.cpp -L /usr/local/lib -lunwind

用 handler 比用 if 会更好吗？ handler 里面不一样还是要用 if 写一堆判断？一个函数里面的内部需要返回不同的错误。

这个草案是不可能被通过的。
因为这违背了 Golang 的基本设计哲学：错误是值。
https://go.dev/blog/errors-are-values

不直接去返回那个（错误的）值，却放在 handler 里面去返回，不是在搞笑吗？这会让你同一逻辑的代码在空间上分离。比如一个函数 和它的错误处理在代码的空间上分离，这绝对更加不利于代码的可读性。if err != nil { ... } 只是丑陋了一点，但是可读性仍然是良好的。

golang ，永远不太可能有除了 if err != nil { ... } 之外的错误处理方案，因为它的设计哲学决定了这个。除非它改变设计哲学。像 Python 的做法是把错误当成异常，而不是值。