@zhwguest
因为没有理论支撑，意味着不可解释，难以复现。没有元素周期表的时候，古代的炼金术士也能炼丹呢，能利用核能吗？

@zhwguest 这种类比是不准确的

高级语言和垃圾回收机制都是有理论基础的，前者有类型系统与语义定理，编译原理作为基础，后者有可达性模型和分代的工程经验。而大模型有什么呢？涌现？ scale 定律？目前依然没有靠谱的理论基础，我们这样用只是 it just works

1. 把更高抽象和更脏实现混为一谈
高级语言/GC 引入的是抽象与自动化，目标是减少偶然复杂度；而屎山是设计退化与耦合失控。前者通常降低出错率和变更成本，后者相反。

2. 把能修 bug 当成能演进系统
sre benchmark 中的任务相对固定明确，而现实业务中有很多业务相关的知识，如何让大模型准确理解业务领域的知识，并不是一件成本低廉的事情。

3. 假设 AI 修复是稳定且无副作用的
至少目前来看，ai 对代码的理解比 gpt3.5 时期刚出来的时候能力强了许多，但是依然不能保证没有问题。大模型的训练方式就天然决定了它的回答上限依赖于训练数据，无法解决新领域的问题，同时由于 token 输出依赖自然语言，同样无法解决自然语言相关的问题：概念描述和自我指代的悖论。

不考虑在 1.x 版本多待会吗，直接就 2.0 了

一个简单的数学题目：
n / 9 = (n + 8) / 12, n = ?

n 越大左边越划算

> 子曰：「言，乃心之声。慎言，可以自保。」
哪个子？



感谢分享

电脑是自己的还是公司的，是不是装了些安全监控的软件。
git 是咋用的，命令行里的 git 还是 ide 带的 git 插件，如果是后者可能是因为插件间的冲突影响的

这个是和你的上下文有关的，如果你把代码报错直接丢给模型，而且是新对话，模型自然会倾向于用英文回复。如果
- 你之前的对话中包含中文
- 你在丢给模型先加了一些话比如：帮我分析下这个日志报错的原因，如何修复
- 使用系统提示词 rule, 比如 .cursor/rules 请用中文回复
那模型就会用中文回答你的问题

pull request 里面包含 merge request 不是很正常的吗，github 上很多开源社区的做法是，在提交到主分支前，由 bot 或者人手工 rebase 成单条记录然后合并。在 pr 阶段保留 merge request 信息可以方便 review 人员查看变更历史，之前 resolve 的评论就可以往后面的 commits 看。
一个特殊的例子，openjdk 仓库里面 pull request 合并后都是 close 状态的，主分支保持干净
https://github.com/openjdk/jdk

你说的这个双语对照早就有人做了，建议看一下 “沉浸式翻译”

@HeyWeGo 这种属于过度谄媚，我有时候提问它老这样回我，问题是我提问的目的是为了学习不了解的只是而不是听它来恭维我的，感觉被微调调废了，还得专门加上系统提示词：请批判性地评估我的请求，无需盲目照办。

我这也发现了 3 年前的动态刷到首页上面

@CathayChen 25 次，咋了

$ git log --oneline | Select-String -Pattern "revert|Revert" | Measure-Object | Select-Object -ExpandProperty Count
25

@konakona 这种不是运维岗，不都是现查的吗，用得多才记得

这完全没必要用锁，是设计的问题，流程调整下就好了。
我理解你这块是离线的业务对吧。

首先 select id from tasks where status = 'PENDING' 拿出全量需要处理的数据，做成一个离线文件或者放内存里（看你自己的数据规模决定）
接着实现一个缓冲，简单点可以在内存里面构造一个比如长度为 16 的队列，存放下一批需要处理的数据

然后是设置并发度，比如说 4 ，这一块你用线程/纤程/进程 实现都可以，依次从队列里面取任务，队列空了在获取下一批数据到队列里面。

这一块自己实现细节还挺多的，比如任务失败了如何重跑，需不需要做背压之类的。

我之前做过类似的，用框架实现，对应的代码就很简洁，伪代码类似这样

```
ids.toStream.buffer(16).mapPar(4)(row => processData(row))
```

@Yosomi 你要是觉得肯德基的炸鸡香，那麦当劳的薯条肯定脆；
你要是觉得肯德基炸鸡糊了，麦当劳的薯条也必须是软的。

说一个偏题事情，你们还记得之前所谓的 ai 程序员 ai devin, 感觉宣传上面有点异曲同工之妙

是吧 > 失败