[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-codex-log-bug-write-ssd-fix-en":3,"article-related-codex-log-bug-write-ssd-fix-en":30,"series-tools-7d032494-02a0-4f35-b213-4541fc055fb6":77},{"id":4,"slug":5,"title":6,"content":7,"summary":8,"source":9,"source_url":10,"author":11,"image_url":12,"cover_image":12,"category":13,"language":14,"translated_content":11,"related_article_id":15,"keywords":16,"key_takeaways":22,"views":26,"created_at":27,"published_at":28,"topic_cluster_id":29},"7d032494-02a0-4f35-b213-4541fc055fb6","codex-log-bug-write-ssd-fix-en","Codex日志bug把SSD写废了怎么办","\u003Cp data-speakable=\"summary\">我把\u003Ca href=\"\u002Ftag\u002Fcodex\">Codex\u003C\u002Fa>写爆SSD这件事拆成了可直接照抄的修复模板。\u003C\u002Fp>\u003Cp>我最近一直在看这种“安全工具把自己先弄出安全事故”的戏码，真有点烦。你一边听 \u003Ca href=\"\u002Ftag\u002Fopenai\">OpenAI\u003C\u002Fa> 讲 GPT-5.5-Cyber 怎么帮你补漏洞、怎么守住生产环境，另一边 Codex 却在本地疯狂写 SQLite 日志，写到能把消费级 SSD 直接熬死。这个反差太刺眼了，像是一个人一边教你怎么防火，一边把打火机塞进你口袋里。\u003C\u002Fp>\u003Cp>更让我不舒服的是，这类问题不是“模型回答错了”那么简单，而是基础设施层面的失控。你以为自己只是开了个 AI 编程助手，结果它在后台默默做高频写盘，机器还很安静，磁盘寿命却在一点点掉。开发者最怕这种事：没有报错，没有崩溃，只有硬件在悄悄流血。\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2052695927035531367\">这篇知乎\u003C\u002Fa>把这个矛盾讲得很直白，所以我想把它拆开，不讲情绪，讲你真正该关心的东西：它为什么会发生，风险到底在哪，怎么把这类工具管住。\u003C\u002Fp>\u003Cp>我也见过类似场景。日志系统默认开得太猛，开发机风扇像起飞，最后排查半天，问题根本不是业务逻辑，而是“写得太勤快”。AI 工具现在也开始复刻这个老毛病，只不过规模更大，速度更狠，后果更贵。\u003C\u002Fp>\u003Cp>原文作者是新智元，发在知乎专栏里，核心素材来自 OpenAI 这次 GPT-5.5-Cyber、Codex Security 和 Patch the Planet 的同步发布，以及社区对 Codex SQLite 日志写入异常的反馈。原文里提到了 \u003Ca href=\"\u002Ftag\u002Fgithub\">GitHub\u003C\u002Fa> issues、OpenAI 研究员回应和多个安全基准，我下面会按开发者视角拆开讲。来源链接我放在文末，方便你回去对照。\u003C\u002Fp>\u003Ch2>别被“修补地球”这句话带跑偏\u003C\u002Fh2>\u003Cblockquote>OpenAI还发起了一个听起来就很燃的计划—— Patch the Planet（修补地球）。\u003C\u002Fblockquote>\u003Cp>这句听起来像宣传口号，但我读下来只想说：它本质上是在讲一个很现实的问题，开源世界的漏洞太多，维护者太少，AI 只是把“发现问题”这件事加速了。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782306220295-visi.png\" alt=\"Codex日志bug把SSD写废了怎么办\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>原文里有个数字我觉得很关键：被广泛使用的开源项目中，94%的项目，一年内90%以上的新增代码，靠的是不到10个开发者。这个数字不是为了煽情，它是在提醒你，安全修复不是“多发几份报告”就能解决的。报告太多，维护者会先被噪声淹没。\u003C\u002Fp>\u003Cp>我以前在团队里也碰过类似情况。扫描器一开，告警像下雨，最后大家不是在修漏洞，而是在给漏洞做工单分流。AI 安全工具如果只会“发现”，不会“收敛”，那它就是把维护成本往别人身上甩。\u003C\u002Fp>\u003Cp>所以 Patch the Planet 真正有价值的地方，不是名字多大，而是它强调了专业人工复核。研究员先去重、先验证，再把干净的补丁送给维护者。这个思路很朴素，但很对。你不能把一车噪声倒给维护者，然后说自己在帮忙。\u003C\u002Fp>\u003Cp>怎么用到你自己的项目里？我建议你把“AI 安全扫描”分成三层：第一层只负责发现；第二层负责聚类、去重、排序；第三层才进入人工确认和补丁生成。别让自动化直接越过第二层，不然你会得到一个更快的垃圾制造机。\u003C\u002Fp>\u003Cul>\u003Cli>先定义“可行动”漏洞，而不是所有命中都算数。\u003C\u002Fli>\u003Cli>给每条告警加去重键：文件、函数、调用链、版本号。\u003C\u002Fli>\u003Cli>把人工确认作为发布门禁，而不是事后补课。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>GPT-5.5-Cyber强在哪，不在“更会聊天”\u003C\u002Fh2>\u003Cp>原文给了几个基准：CyberGym 85.6%，ExploitGym 39.5%，SEC-bench Pro 69.8%。这些数字的意思不是“它更聪明”，而是它更擅长做防御任务里的那套脏活累活：找漏洞、验证风险、生成补丁、给人工审查证据。\u003C\u002Fp>\u003Cp>我更愿意把它理解成一个专用安全工程师，而不是一个通用大模型。普通模型擅长给你解释概念，安全模型要做的是把攻击面一层层剥开。这个差别很大。前者像顾问，后者像值班工程师。\u003C\u002Fp>\u003Cp>原文还对比了普通版 GPT-5.5、\u003Ca href=\"\u002Ftag\u002Fclaude\">Claude\u003C\u002Fa> \u003Ca href=\"\u002Ftag\u002Fopus-47\">Opus 4.7\u003C\u002Fa> 和 Cyber 版。这里我不想把重点放在“谁赢了谁”，因为那很容易变成口水战。对开发者来说，真正有用的是：当模型开始进入高风险工作流时，评估指标必须贴近实际任务，而不是只看对话体验。\u003C\u002Fp>\u003Cp>我见过不少团队把“模型表现好”理解成“上线没问题”，结果一接到真实任务，模型开始稳定输出看起来很合理、实际很危险的建议。安全场景尤其这样。你不能只问它“能不能说”，你要问它“能不能在约束下做对事”。\u003C\u002Fp>\u003Cp>怎么落地？如果你在做内部安全助手，别直接让它碰生产系统。先把它放进只读环境，给它有限的代码快照、有限的执行权限、明确的审计日志。再把输出限定成三种格式：风险说明、证据链、候选补丁。别让它自由发挥写长篇建议，那种输出最容易把人带沟里。\u003C\u002Fp>\u003Cul>\u003Cli>把任务拆成“识别、验证、修复建议”三段。\u003C\u002Fli>\u003Cli>只给只读上下文，不给任意执行权限。\u003C\u002Fli>\u003Cli>所有建议必须附证据链，不能只给结论。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>Codex Security 不是插件，它是工作流入口\u003C\u002Fh2>\u003Cp>原文说 Codex Security 插件把漏洞扫描、威胁建模、攻击路径追踪、补丁生成直接焊进了 Codex 工作流。这个描述挺准确，我读的时候想到的不是“插件”，而是一个新的入口层：它试图把安全能力塞进你日常写代码的路径里。\u003C\u002Fp>\n\u003Cfigure class=\"my-6\">\u003Cimg src=\"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782306220398-d9bk.png\" alt=\"Codex日志bug把SSD写废了怎么办\" class=\"rounded-xl w-full\" loading=\"lazy\" \u002F>\u003C\u002Ffigure>\n\u003Cp>这件事的价值在于前移。以前很多安全检查是“写完再扫”，现在它想变成“边写边看”。这当然更高效，但前提是工具本身得稳定，不然你会在编码时多背一层故障风险。\u003C\u002Fp>\u003Cp>原文提到，自今年 3 月研究预览上线以来，Codex Security 已经扫描了超过 3000 万次提交，覆盖 3 万多个代码仓库，人工复核确认修复的发现超过 7 万个，自动判定修复的超过 50 万个。这个规模说明什么？说明 OpenAI 不是在做一个玩具功能，它在试图把安全扫描做成高频基础设施。\u003C\u002Fp>\u003Cp>我对这种规模化工具一向有个偏见：只要它开始大规模写日志、缓存状态、追踪上下文，就一定要盯住资源边界。因为一旦你把“安全”做成常驻服务，资源消耗会跟着放大。安全工具最怕的不是慢，是悄悄把别的系统拖垮。\u003C\u002Fp>\u003Cp>怎么用？如果你要把类似 Codex 的安全插件接进团队流程，我建议你先设三道闸：限制扫描频率、限制本地持久化、限制长任务运行时长。尤其是本地持久化，别默认让它把所有中间状态都落盘。很多“稳定性问题”其实都出在这里。\u003C\u002Fp>\u003Cp>还有个很实用的习惯：把插件的日志目录单独放到一个可监控分区里，给它设磁盘配额。这样一旦它开始发疯，你至少能看到它在烧什么，而不是等 SSD 寿命被磨掉一半才发现。\u003C\u002Fp>\u003Ch2>真正的 bug 不在模型，在写盘策略\u003C\u002Fh2>\u003Cp>这部分是我最想吐槽的。原文里那个问题很具体：Codex 在流式传输和长时间运行时，会以极高频率往本地 \u003Ccode>~\u002F.codex\u002Flogs_2.sqlite\u003C\u002Fcode> 写 TRACE 日志，峰值能到 16MB\u002Fs，实测有人算出一年可写入 640TB。这个量级已经不是“日志多一点”了，这是在拿 SSD 当耗材。\u003C\u002Fp>\u003Cp>最离谱的是，它还很安静。文件看起来不大，因为它在反复写入、删除、清理，肉眼看不出什么异常，但闪存芯片已经在吃满负荷。开发者最容易被这种假象骗过去：目录大小没涨，不代表写入量没涨。\u003C\u002Fp>\u003Cp>原文提到，有 GitHub 用户实测开机运行 21 天，主 SSD 被写入约 37TB 数据。这个数字已经足够让人警觉了。更关键的是，相关 issue 从 4 月就有人提，后面一路有人补刀，到 6 月 14 日又把问题顶上来。也就是说，这不是一次偶发事故，而是一个被社区反复指出、但迟迟没彻底解决的资源管理问题。\u003C\u002Fp>\u003Cp>我在项目里也见过类似“默认日志级别太高”的坑。开发阶段大家嫌日志少，生产阶段大家嫌日志多。最后没人去调，因为“先这样跑着”。结果一拖就是几个月，直到磁盘告急、I\u002FO 抖动、机器变卡，才开始认真看。\u003C\u002Fp>\u003Cp>怎么处理这种问题？别只改日志级别，得把写盘策略一起改掉。要么做采样，要么做批量刷盘，要么做内存环形缓冲。最差也要给 TRACE 级别加速率限制。日志不是越细越好，日志的成本也得算进去。\u003C\u002Fp>\u003Cul>\u003Cli>给 TRACE 日志加每秒写入上限。\u003C\u002Fli>\u003Cli>把高频日志改成批量落盘。\u003C\u002Fli>\u003Cli>为本地 SQLite 设置配额和轮转策略。\u003C\u002Fli>\u003C\u002Ful>\u003Ch2>SQLite 没错，错的是你把它当无限桶\u003C\u002Fh2>\u003Cp>我不想把锅甩给 SQLite。SQLite 本身没问题，问题是你拿它做高频日志存储，还默认允许持续写入、清理、再写入。数据库是拿来管理数据的，不是拿来当无限吞吐的垃圾桶。\u003C\u002Fp>\u003Cp>原文里最让我警觉的一点，是“写入再删除、写入再删除”的模式。很多人只看文件大小，不看底层写放大。SSD 不是机械硬盘，写入寿命是实打实会被消耗的。你每次觉得“反正只是日志”，硬盘都在替你记账。\u003C\u002Fp>\u003Cp>我建议你把这个问题翻译成工程语言：这是一个“后台写放大失控”的案例。它和模型能力没直接关系，和资源治理关系很大。只要你的工具会长时间运行、会流式输出、会记录上下文，就有可能踩到这个坑。\u003C\u002Fp>\u003Cp>怎么防？最简单的办法是把日志分层。热日志放内存，冷日志批量落盘，审计日志单独存储。然后再给每层设置不同保留期。别把所有东西都塞进一个 SQLite 文件里，最后再指望它自己长出节制。\u003C\u002Fp>\u003Cp>如果你是做平台工程的，我还建议加一个“日志写入预算”指标。这个指标不花哨，但很管用。比如每个 agent 每小时最多写多少 MB，超过就降级到摘要日志。你会发现，这种硬约束比事后排查好用得多。\u003C\u002Fp>\u003Ch2>OpenAI 的回应说明了什么\u003C\u002Fh2>\u003Cp>原文最后提到，OpenAI 研究员 Vaibhav Srivastav 回应说，这个问题已经修复，并随最新 Codex 版本发布，用户需要通过 npm 或 bash 安装脚本升级。这个回应很直接，也挺符合工程现实：先修，再让大家升级。\u003C\u002Fp>\u003Cp>但我更在意的是这件事暴露出来的节奏问题。一个安全工具刚高调发布，社区马上抓到资源写入异常，这会让人对“默认安全”这句话多一层怀疑。不是说功能没价值，而是说发布时对资源边界的把控还不够细。\u003C\u002Fp>\u003Cp>我一直觉得，做基础设施工具的人最该怕的不是“功能不够多”，而是“默认值太激进”。默认值一旦激进，用户就会替你承担后果。Codex 这次的日志问题就是典型例子：你不改配置，它就按自己的节奏写，最后硬盘先扛不住。\u003C\u002Fp>\u003Cp>如果你在团队里推类似工具，我的建议很简单：默认关闭高频 TRACE；默认只保留摘要日志；默认给本地存储加上上限；默认把升级说明写得比功能介绍更醒目。听起来很保守，但这才是能长期跑的做法。\u003C\u002Fp>\u003Cp>说白了，AI 工具进入安全场景后，最值钱的不是“会不会找漏洞”，而是“会不会老老实实待在边界里”。边界感差的工具，能力越强，风险越大。\u003C\u002Fp>\u003Ch2>你可以直接照着改的那套做法\u003C\u002Fh2>\u003Cp>如果你现在也在做一个会长时间运行、会写日志、会接本地存储的 AI 工具，我建议你直接拿下面这套规则当起点。它不花哨，但能救命。\u003C\u002Fp>\u003Cp>第一，把日志策略拆成三档：默认、调试、审计。默认档只保留必要事件，调试档只在短时间内打开，审计档单独落盘并限流。第二，把本地持久化从“默认开启”改成“显式开启”。第三，给每个 agent 加资源预算，尤其是磁盘写入预算。第四，所有长任务都要有超时和降级路径。\u003C\u002Fp>\u003Cp>我知道很多团队会嫌这套流程麻烦，但麻烦是有意义的。因为一旦工具开始常驻，任何一个“先不管”的小洞，最后都会变成运维账单。你不在设计阶段管住它，就只能在事故阶段补票。\u003C\u002Fp>\u003Cp>最后我想说，OpenAI 这次的两面性其实很典型：一边是更强的安全能力，一边是更糟的资源失控。开发者真正该学的，不是站队夸谁，而是把这种反差当成警报。能力提升了，边界也必须一起收紧，不然工具会比你想的更快把自己玩坏。\u003C\u002Fp>\u003Ch2>The template you can copy\u003C\u002Fh2>\u003Cpre>\u003Ccode># AI 安全插件资源控制模板\n\n## 1. 默认策略\n- TRACE 日志默认关闭\n- 仅保留摘要日志，保留期 7 天\n- 本地 SQLite 仅用于短期缓存，不用于无限追加\n- 所有长任务必须设置超时\n\n## 2. 磁盘写入预算\n- 单个 agent 每小时最大写入：100 MB\n- 单个 agent 每天最大写入：1 GB\n- 超过预算后自动降级为摘要模式\n- 超过 2 次预算触发，自动暂停高频日志\n\n## 3. 日志分层\n- 热日志：内存环形缓冲\n- 冷日志：批量刷盘，每 30 秒一次\n- 审计日志：单独目录，单独配额\n\n## 4. SQLite 使用规范\n- 禁止把 TRACE 级别日志直接写入主 SQLite 文件\n- 仅允许写入聚合后的事件摘要\n- 设置数据库最大大小上限\n- 启用轮转和清理任务\n\n## 5. 运行时保护\n- 流式任务开启 I\u002FO 监控\n- 当写入速率超过阈值时自动降级\n- 当磁盘占用超过 80% 时暂停非必要记录\n- 记录所有降级动作到审计日志\n\n## 6. 升级检查清单\n- 检查默认日志级别\n- 检查本地缓存目录位置\n- 检查磁盘配额是否启用\n- 检查长任务是否有超时\n- 检查是否存在无限写入路径\n\n## 7. 团队落地建议\n- 安全扫描和日志系统分开评审\n- 把资源预算写进 PR 模板\n- 上线前做 24 小时压力测试\n- 把写入量纳入可观测性面板\n\n## 8. PR 模板里直接加这一段\n### 资源与日志检查\n- [ ] 是否新增高频日志\n- [ ] 是否写入本地持久化存储\n- [ ] 是否设置写入速率上限\n- [ ] 是否设置磁盘配额\n- [ ] 是否有降级和回滚方案\n\n## 9. 适合贴到 README 的一句话\n本项目中的 AI 组件默认受磁盘写入预算约束，禁止无限制高频落盘。\n\u003C\u002Fcode>\u003C\u002Fpre>\u003Cp>这套模板不是专门给 Codex 用的，是给所有“会长时间跑、会写日志、会碰本地存储”的 AI 工具用的。你可以直接贴进 PR 模板、平台规范或者 README 里，先把边界立起来，再谈智能。\u003C\u002Fp>\u003Cp>来源：\u003Ca href=\"https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2052695927035531367\">https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2052695927035531367\u003C\u002Fa>。其中关于 GPT-5.5-Cyber、Codex Security、Patch the Planet 和 SQLite 写盘问题的叙述，主要来自原文与其引用的社区反馈；我在这里做的是面向开发者的拆解和模板化整理，不是原文复述。\u003C\u002Fp>","我拆开这篇知乎，讲Codex日志写爆SSD的根因、风险和可直接套用的限流修复模板。","zhuanlan.zhihu.com","https:\u002F\u002Fzhuanlan.zhihu.com\u002Fp\u002F2052695927035531367",null,"https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782306220295-visi.png","tools","en","fbdd88d7-87eb-485b-9608-766022fbebc5",[17,18,19,20,21],"Codex","OpenAI","SSD","日志","安全工程",[23,24,25],"AI 安全工具如果只会发现问题，不会收敛噪声，就会把维护成本甩给别人。","高频日志写盘是基础设施问题，不是小毛病，默认值必须收紧。","给 AI 工具加磁盘写入预算、日志分层和降级路径，比事后排查更有效。",0,"2026-06-24T13:03:12.763441+00:00","2026-06-24T13:03:12.752+00:00","5670eef8-2f80-4c83-a710-c41fc5aa527c",{"tags":31,"relatedLang":36,"relatedPosts":40},[32,34],{"name":18,"slug":33},"openai",{"name":17,"slug":35},"codex",{"id":15,"slug":37,"title":38,"language":39},"codex-log-bug-write-ssd-fix-zh","Codex 日志寫爆 SSD 怎麼管","zh",[41,47,53,59,65,71],{"id":42,"slug":43,"title":44,"cover_image":45,"image_url":45,"created_at":46,"category":13},"d7346581-d20f-40d6-a68a-2bc3202e6e23","open-source-agent-orchestrators-parallel-coding-autonomy-en","Open-source agent orchestrators are ready for parallel coding, not fu…","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782292674309-i1bq.png","2026-06-24T09:17:25.524293+00:00",{"id":48,"slug":49,"title":50,"cover_image":51,"image_url":51,"created_at":52,"category":13},"12b94d42-4411-4423-b114-7628c16b0403","go-127-rc1-1264-security-fixes-en","Go 1.27 rc1 and 1.26.4 ship security fixes","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782290876561-0kzh.png","2026-06-24T08:47:33.902085+00:00",{"id":54,"slug":55,"title":56,"cover_image":57,"image_url":57,"created_at":58,"category":13},"d3c7fdba-5905-4bbc-884c-8767dd4f3f69","cursor-spacex-ai-coding-productization-en","Cursor让SpaceX式AI编程更像产品","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782277405045-d6ow.png","2026-06-24T05:02:57.82919+00:00",{"id":60,"slug":61,"title":62,"cover_image":63,"image_url":63,"created_at":64,"category":13},"0b5e0100-8da6-4abd-9148-6ab05945d576","dometrain-advanced-system-design-ops-template-en","Dometrain’s system design course turns theory into ops","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782270215908-9wb4.png","2026-06-24T03:03:03.295446+00:00",{"id":66,"slug":67,"title":68,"cover_image":69,"image_url":69,"created_at":70,"category":13},"1beb929d-4b02-4ee5-9098-c4c95c7c8825","cdns-stock-page-turns-noise-into-watchlist-en","CDNS stock page turns market noise into a watch list","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782268391242-ty19.png","2026-06-24T02:32:50.226771+00:00",{"id":72,"slug":73,"title":74,"cover_image":75,"image_url":75,"created_at":76,"category":13},"6d6cd720-2fea-4a4b-b29e-08cae3e105f0","github-open-source-music-topic-shortlist-en","GitHub’s music topic turns discovery into a shortlist","https:\u002F\u002Fxxdpdyhzhpamafnrdkyq.supabase.co\u002Fstorage\u002Fv1\u002Fobject\u002Fpublic\u002Fcovers\u002Finline-1782243212008-6lsx.png","2026-06-23T19:33:01.28276+00:00",[78,83,88,93,98,103,108,113,118,123],{"id":79,"slug":80,"title":81,"created_at":82},"8008f1a9-7a00-4bad-88c9-3eedc9c6b4b1","surepath-ai-mcp-policy-controls-en","SurePath AI's New MCP Policy Controls Enhance AI Security","2026-03-26T01:26:52.222015+00:00",{"id":84,"slug":85,"title":86,"created_at":87},"27e39a8f-b65d-4f7b-a875-859e2b210156","mcp-standard-ai-tools-2026-en","MCP Standard in 2026: Integrating AI Tools","2026-03-26T01:27:43.127519+00:00",{"id":89,"slug":90,"title":91,"created_at":92},"165f9a19-c92d-46ba-b3f0-7125f662921d","rag-2026-transforming-enterprise-ai-en","How RAG in 2026 is Transforming Enterprise AI","2026-03-26T01:28:11.485236+00:00",{"id":94,"slug":95,"title":96,"created_at":97},"6a2a8e6e-b956-49d8-be12-cc47bdc132b2","mastering-ai-prompts-2026-guide-en","Mastering AI Prompts: A 2026 Guide for Developers","2026-03-26T01:29:07.835148+00:00",{"id":99,"slug":100,"title":101,"created_at":102},"3ab2c67e-4664-4c67-a013-687a2f605814","garry-tan-open-sources-claude-code-toolkit-en","Garry Tan Open-Sources a Claude Code Toolkit","2026-03-26T08:26:20.245934+00:00",{"id":104,"slug":105,"title":106,"created_at":107},"66a7cbf8-7e76-41d4-9bbf-eaca9761bf69","github-ai-projects-to-watch-in-2026-en","20 GitHub AI Projects to Watch in 2026","2026-03-26T08:28:09.752027+00:00",{"id":109,"slug":110,"title":111,"created_at":112},"9f332fda-eace-448a-a292-2283951eee71","practical-github-guide-learning-ml-2026-en","A Practical GitHub Guide to Learning ML in 2026","2026-03-27T01:16:50.125678+00:00",{"id":114,"slug":115,"title":116,"created_at":117},"1b1f637d-0f4d-42bd-974b-07b53829144d","aiml-2026-student-ai-ml-lab-repo-review-en","AIML-2026 Is a Bare-Bones Student Lab Repo","2026-03-27T01:21:51.661231+00:00",{"id":119,"slug":120,"title":121,"created_at":122},"6d1bf3f6-e191-4d30-b55b-8a0722fa6afe","ai-trending-github-repos-and-research-feeds-en","AI Trending Tracks Repos and Research Feeds","2026-03-27T01:31:35.709532+00:00",{"id":124,"slug":125,"title":126,"created_at":127},"010539a1-4c3a-4bd3-937a-26616422ee0d","awesome-ai-for-science-research-tools-map-en","Awesome AI for Science Is Becoming a Real Research Map","2026-03-27T01:46:50.89513+00:00"]