多正常啊, 个人在进入职场前也能踩踩坑，了解各种公司的恶性行为，况且实现协议有啥约束力啊，发现是坑可以马上跑的呀

二一种，实习也是学术界和工业界的常见合作方式，我们原来牵头的课题也是某个教授派手下研究生来我们公司做，其实干的活还是他在学校哪些，不见 AI 行业一堆大佬都是以实习生方式存在

即便我很看好 AI 的未来，我也认为 对 AGI 的迷信与 “人形机器人”一样充满了“人类中心主义”的傲慢与局限

这种迷思 一方面是 是人类探索自身奥秘的执念，同时受文化叙事和认知局限的驱动

求拉 V: YW55a25vCg==

为什么要和别的孩子比

@thevita 中分 -> 中风

@tangshanliu 因为我爸就是开药店的执业医师，大部分患者，你跟他说要多吃几天药，人只会认为你就是为了赚他钱，下次就不来了，背后还蛐蛐你（毕竟都是熟人社会），比如 劳动人民吃饭都比较重油重盐，已经出现好几个我爸告知有中分风险需要干预的人，奈何不会信你的。少部分有慢性病的熟人会听，一般以受过教育、有退休金的老年人为主，所以说到底背后还是经济问题。

.vscode 会 commit 部分文件: extensions.json, 之前没有 settings.json, 用 .editorconfig 之类的, 但满足不了需求，还是把 settings.json 加进去了

大医院医生面临的患者群体不一样，简单说就是大病重病要更多，当然想得也就多（并不是说乱开检测的情况就不存在）
下级医院乱开的情况就更严重了
要想又好又快，就去小诊所吧，抗生素激素一上，30 分钟见效......

心理因素

我感觉很多人在使用各种 LLM 产品的时候都提到了 “降智” 这个问题，抛开服务成本因素，人的心理过程也很显著

第一次接触到会应为某一些 case 产生 ”惊艳“ 的感觉，这种 ”惊艳“ 锚定了较高的心理预期

长时间使用时，我们面临的问题/场景 是呈现某种随机分布的，LLM 对问题的表现也一定是呈现某种分布，导致在某些地方表现不好，这些”预期违背” 的情绪也会被放大

火焰图照一下，缩小范围，看看有不有没注意到的同步调用.

我也喜欢问基础点的，其实是想看看工作多年后，候选人有没有形成自己的认知体系，如果背八股文不至于挂，但肯定是减分的，

项目的话，除非是领域高度相关，不然基本目标就是判断下候选人的参与深度，过滤下简历水分而已

没说清楚啊，与你的事务会会发生冲突的都有啥啊，仅仅同一个逻辑的不同任务吗？有没有 读-写冲突？有没有其他不同粒度、不同逻辑的写-写冲突，doBusinessLogic 里面有不有 外部一致性要求？

超大事务呗，某些系统很常见，并不是所有业务都是互联网，上面的不要看到这种就报警

锁放外部（方案 A ）正如你所说，只解决了 processBatch 的并发问题，但是不能避免其他事物的更新，依然可能导致 write-skew ，除非你保证只要该这个表，都拿锁，那和表锁其实也没太大差别，就看你们的数据库实现得整么样了

锁表（方案 B ）通过合理的加锁，能避免 write-skew, 但是冲突域会变大，影响系统吞吐，甚至某些 db 可能会阻塞读，但是话又说回来，如果你的场景类似，半夜批量计算，冲突可能低那种，耶完全可以接受

其他方案:
其实具体看你能接受 哪部分 可以被适当取舍，比如上面只讨论了锁的情况，取舍的就是与其他事物的冲突

如果你能接受适当若化 这个超大事务的原子性的话还可以: processBatch 内加锁，这个锁止解决 不同 processBatch 任务间的冲突（更好的办法可能是引入一个协调者来保证 不同 processBatch 尽量不冲突），然后更新使用乐观锁+重试，让 这个 batch 实现最终一致，也不失为一种办法（当然，这里没讨论你的 doBusinessLogic 有不有外部一致性的情况）

分享一下我的看法，我理解这些概念不太喜欢先深入细节，有全局视角再看细节

无栈协程的核心就是 把顺序代码变成一种状态机，不同语言的实现差异很大，但逻辑差不多

(其实我们如果不用 coroutine, 写事件驱动应用 就是手写这个状态机）

await 就是状态转移点，从一个 await 完成 到下一个代码路径上的 await 就是一次状态转移

将这一小段代码封装起来 就叫 task, 这就是 事件循环执行的基本单元（不同语言实现也不一样，python 应该是依靠 生成器状态机来实现，rust ，c++ 则靠编译器）

future/awaitable 作用是管理 task 之间的依赖关系，在某个 task 的 future done 的时候，将依赖它的 task 放进就绪队列等待执行（不同实现也不一样，比如 直接通过 callback ）

所以:


- 啥时候让出权限: 一个 task 完成的时候
- 啥时候任务加进事件循环： 这个任务的依赖 future done 的时候 （实现可以都不一样，单实践效果一定是这样的）
- 啥时候恢复执行: 进如 ready 队列了，就等待执行了，自于啥时候执行，就是 队列和 调度器的实现了，也都不一样

----


正好前段时间看了 foundationdb ，他们自己实现了一个 叫 flow 的语言，在 < c++20 上实现了无栈协程，它的编译器会把 flow 的代码编译成 C++ 的状态机，可以清晰的看到怎么把代码转成状态机

touch bar 对我很鸡肋，我无法适应需要我需要目光下移去看一个和屏幕不在一个平面上的东西，即便只要瞟一眼，割裂感也很严重

其实 更大可能是 reuse 了

“复杂性” 从来不来自技术本身，而是来自于“业务”，或者说我们的数字系统的建模对象

而发明眼花缭乱的技术、思想，什么 react programming/DDD/各种 design pattern ，不过是为了控制复杂度的实践而已

不要搞反了关系，如果你预期到你的建模目标的复杂度不值得你专门去搞一个新“技术”/“框架”，那你就不用嘛