人生中,几乎没有像最近几个月这样,这么期待起床,这么亢奋的想要做事。
作为注意力障碍型的ADHD—I,从小都习惯一个人闷在角落里,大脑在疯狂奔逸,各种幻想,各种想法,各种念头,吃饭都停不下来。但是面对现实要求我做的事,背书、做题、都打不起精神来,迷迷糊糊。因为脑海里想的事情,往往距离平凡的小日子很遥远,无法落地,所以精神和肉体过着双轨制的生活。
想要表达,想要我心中的创造在现实落地,所以我从小就写小说,从童年童言童语的小故事开始,到初中和同学一起交换小说,到大学后在网上签约连载......这不是我多么喜欢小说这个体裁,而是因为我一个人能调动的能力,就只能写小说,拍不了电影,做不了游戏,只有小说这种形式,能把我的念头落地产出。
我小时候特别喜欢数码宝贝这个动漫,一直幻想有一天数码宝贝真的会在现实世界中诞生。所以即便在少年时期接触不到编程资源,也一直对程序员这个职业心生向往。上了大学终于进入CS体系下的专业,学会了编程,并做了很多人工智能方向的科研工作,我非常感恩。
但是在毕业前后,我陷入一种迷茫,我想要的到底是做一个纯粹的技术螺丝钉,还是像把那些瑰丽的想象带到现实?特别是,和一个工作了的同学聊天时,他告诉我,程序员只能负责写代码去实现别人规定的东西,而到底要做什么东西,解决什么问题,是产品经理决定的。这给我泼了一头冷水,如果我只能做一个无法发挥自己创意的工具人,那该是多么折磨的人生,这简直是ADHD人士的地狱。但是放下技术做产品经理对我来说是一个让我感到自己的技术积累和追求都作废的未知赛道,也不是说卷就能卷的......
所以我会羡慕现在的人,或者说现在的ADHD后辈。因为会Coding的LLM,改变了上述的牢笼逻辑。
最符合我本能的工作方式,我懂技术,并且基于这个基础我来设计产品,不需要枯燥的分工,打螺丝的工作交给AI,我动脑子做设计、分析、评价就好。
这就是我童年时幻想的生活方式。
最近我有时会突然想起前LLM时代,那些挣扎,仿若南柯一梦。如果LLM没有诞生,在那个平行世界,我们会过怎么样的生活?
大水理论和大壶理论是水健康领域的入门,尿白理论才是真正的核心。很多人大水大壶已经放在身旁,但是一天懒得喝多少,这就不行,一定要量到位才行。
判断量是否到位很简单,当你每天早上把大水/大壶放在身旁时,你只有一个目标:把尿喝白。
没事就喝,你会发现你上厕所的频率也增加了,这也就顺便解决了你久坐的问题。当你关闸到你的尿清澈无比,说明你就练成了。
尿至清则无病。
孙哥参加别人的访谈,大谈薄肌大水理论。
劝别人买大水,喝大水。
呵。
殊不知,每天买一杯大水,需要中国青年为此付出10块钱。
而孙哥自己,只买大壶,从来不买大水。
大壶,是每一个00后年轻人,能接触到的最容易入手的稳健投资,拥有大壶,从此拥有富人思维,开拓富人眼界,开启全球水资源套利模式。
孙哥就从来都不买大水,他花10块钱买个大壶,在公共区域接水,到朋友家接水,到活动场地接水,到饭店接水。
他每天省下10块买水钱,定投特斯拉和比特币。
从2010年3月开始,如果一个人,每天花10块钱定投比特币,并一直持有到2026年10月,他可以攒到96356枚比特币。
按照今天的价格,是544亿人民币。
大水理论,是消费主义陷阱,是资本家的做局,是落后过时的理论。
真正的强者,只买促销的大壶,接免费的大水。
中国18到40岁的适龄青年,有4亿。
只要4亿年轻人都能放下大水,拿起大壶,实践薄肌大壶理论!
中国年轻人每天可省40亿元,一年就是1.46万亿元。
这不是“薄肌大水论”,
这是大壶兴国论!
少年强,则中国强。
放下大水,立地成壶。
每天省下10块钱,做金融产品定投。
10年后,我们巅峰相见。
#颖学
#薄肌大壶
#理财专家
(图中,是孙哥的大壶)
codex 13号这把重置之后,感觉token消耗巨快无比,我基本3天就到尽头,然后不敢动了,开始让codex和grok build配合工作, 把重活丢给grok。我用的是x20,我的朋友用的plus,以前都没听说有不够用的情况,这次2天就用完,然后就没招了。
Tibo,你有看到大伙渴望的眼神吗?
@thsottiaux
Update on rate limits in Codex.
— Tibo (@thsottiaux) xitter.cf/thsottiaux/status/2091…">August 23, 2026
We’ve found (a) some inefficiencies when using images in long sessions with multiple compactions (b) high p95+ usage for Computer History (c) a feature that was meant to generate conversation titles that was draining a bit more usage than… xitter.cf/thsottiaux/statu…">xitter.cf/thsottiaux/statu…
Update on rate limits in Codex.
We’ve found (a) some inefficiencies when using images in long sessions with multiple compactions (b) high p95+ usage for Computer History (c) a feature that was meant to generate conversation titles that was draining a bit more usage than intended. And we have a tiger team combing through everything and shipping fixes tomorrow. We also found a novel approach to drive efficiency up significantly that is completely unrelated and we will be working on next week.
As part of some of the fixes tomorrow, we will also do a full reset of the usage for all paid subscriptions.
See you then.
codex解除5小时限制的后果:一天用完一半。
不过确实爽。
话说codex更新后,出了不少问题,前两天感觉消耗得特别快,这个得到大众验证,貌似是372k的上下文处理出了问题,codex负责人帮大家重置了额度。
但我昨天遇到了新的问题,就是我打开老session,变得异常缓慢,要白屏卡半天才能加载出来,而且不再显示完整历史记录,只能往上看到不到10条,我让claude检查, 他说是因为这些session体积太大,都好几个G。
但是,在codex更新之前,我也频繁使用这些session,一直都很丝滑。
大概就是新版的codex在这方面存在退步。
@thsottiaux
I use opus4.8 to summarize the promblem: ════════════════════════════════════════════════════════════════ Codex Desktop (Windows / MSIX) — large existing sessions white-screen, truncate history, and crash the renderer after the 26.707.x update ════════════════════════════════════════════════════════════════ TL;DR Since updating from 26.609.3341.0 to the 26.707.x line, opening any large existing session (hundreds of MB to 2.35 GB) shows a multi-second white screen, then renders only ~<10 messages of scrollback, and frequently crashes the renderer. The exact same session files opened instantly with full history on 26.609. The crash reproduces with 26 GB of free system RAM, so this is a client regression in the session load/render path — not user data size and not memory pressure. ENVIRONMENT - OS: Windows 11 (build 10.0.26200) - App: OpenAI.Codex (MSIX, Microsoft Store) - Last-known-good: 26.609.3341.0 (sessions opened instantly, full history) - Regressed line: 26.707.x 26.707.3748.0 first installed 2026-07-11 14:29 → .6957 (07-13) → .8168 (07-13) → .8479 (currently installed) → .9564 attempted 07-14 (has not successfully registered) - Renderer: ChatGPT.exe, Chromium 150.0.7871.101 - Session store: %LOCALAPPDATA%\...\.codex\sessions (rollout .jsonl per session) REPRODUCTION 1. Have a large, image-heavy session on disk (created on an earlier version). 2. Open it in the desktop client. → long white screen, then only the tail (~<10 messages) is scrollable; older history never loads; renderer often crashes. On 26.609.x the same file opened instantly with complete history. EVIDENCE IT IS A CLIENT REGRESSION (not the user's data or RAM) 1) Crashes with plenty of free RAM — not a system OOM - Renderer (ChatGPT.exe) crashed while opening a large session with 26.1 GB free system RAM (system at 59% used). - No Windows "Application Error"/OOM event is logged — the renderer exits cleanly. Consistent with the renderer exceeding its OWN per-process V8/Chromium heap limit while parsing the full multi-GB rollout into memory, which is independent of available system RAM. - Windows also logged RADAR_PRE_LEAK_64 for ChatGPT.exe 150.0.7871.101 on 2026-07-12 (excessive memory growth). 2) File sizes PREDATE the update — size didn't change, the client did - Largest sessions and their last-modified dates (all before 26.707 landed on 2026-07-11): 2352 MB last modified 2026-06-22 735 MB last modified 2026-06-30 576 MB last modified 2026-06-19 - Same size, fast on 26.609, slow/crashing on 26.707. 3) The client rewrites the entire rollout on open - Opening a session updates its rollout .jsonl mtime to the exact moment of opening, with NO new user turns (observed: a 365 MB session rewritten at 15:37:21 on open). This suggests the client re-serializes the whole rollout on open, which both stalls the load (white screen) and drives the memory blow-up / crash. SESSION CORPUS (for context on scale) - 302 sessions, 11 GB total. - Size distribution: 2 files > 1 GB, 5 in 500 MB–1 GB, 13 in 100–500 MB, 282 < 100 MB. - Large sessions are image-heavy. Measured on a 576 MB session (2341 lines): 129 lines contain inline base64 PNG screenshots and account for 58.7% of the bytes (~12 MB per image record); the remaining ~41% (238 MB) is text/tool output. - Usage: these months-old sessions were reused daily for ~1 week with no issue until the 26.707 update. SUSPECTED ROOT CAUSE / FIX AREAS - Session load appears to parse (and re-serialize) the ENTIRE rollout .jsonl into the renderer on open. For multi-GB, image-heavy rollouts this blows the renderer heap and stalls the UI. - Suggested: lazy/windowed loading (read only the tail needed to render, stream older turns on scroll), stop rewriting the full rollout on open, and virtualize scrollback so the whole history need not be resident in the renderer. IMPACT Users who rely on long-lived, image-heavy sessions can no longer open them: history is effectively inaccessible and the app crashes under the load. Regressed between 26.609.3341.0 and 26.707.x. ════════════════════════════════════════════════════════════════
最近Musk推倒了巴别塔,我希望呼唤全世界AI领域的ADHD们可以聚集起来,一起讨论:
1. 自身的ADHD,是否让你感受到AI能带来能力提升和放大,是否解决你曾经的所谓缺陷?是否让你感到兴奋?
2. 使用AI的过程中,你觉得有什么ADHD的问题还未解决,或者需要一些技巧去解决?
3. 你是否见过对ADHD很有用的AI产品,或者你自己就在开发这样的产品,是否可以分享,推荐?
4. 你享受vibe coding吗?你能应付同时处理多个项目吗?你觉得等待vibe coding的过程中,你希望集中精力在思考这个项目,还是不断切换到其他项目,还是休息?
5. 欢迎加入社群一起讨论:xitter.cf/i/communities/20366955…
#ADHDINAI
上周的接触到的事情给了我提醒,我曾经以为只有我自己能想到的一些东西,我可以慢慢等,慢慢琢磨打磨,最后慢慢把它实现。但是视野放开,其实海外可能会人也在做类似的事,只是没有通过中文看到,而国内也会有越来越多人关注,有些想法可能不是只有我能想到,在我真正想做的事情上面,不能再磨蹭了。
另一个体会是,很多人都会有原教旨主义的傲慢,我也是。比如我一直关注ADHD领域,就会觉得自己是懂哥,ADHD的AI产品很多,我自己也在做,特意瞄准专业的理论去设计,觉得自己的点打得很准。但我看到一个全员非ADHD背景的团队,因为近期小红书上ADHD很火就做了一个ADHD的产品,就很快做得很完善,收到了评委们的认可。这件事给我很大启发,就是我自认为自己是某领域的“超级用户”,就觉得自己做的产品就是对的,就觉得只有自己能做了某类产品。原教旨主义者必须克制自己的自以为是,用专业的态度做事。







