【AI 奏折】2026年07月31日
共收录 17 篇深度内容
📋 今日内容速览
快速浏览，点击感兴趣的推文查看详细分析
- 宝玉: HTML+CSS是AI生成美观可编辑PPT的最佳中间格式。
- Mr Panda: 12个深度解析AI/LLM的优质博客助你建立长期认知
- Berryxia.AI: 让普通人用自然语言解决生意问题的工具才是中国AI的胜负手。
- 铁锤人: AI生成PPT难修改，关键时刻易误事。
- 苍何: 利用聊天上下文构建个人知识库让AI更懂你。
- 泊舟: AI工具Remio能基于旧项目资料高效修改PPT，节省重复沟通时间。
- 向阳乔木: Memmy设计三层记忆系统，智能生成复用经验并方便搜索。
- 向阳乔木: 开源工具Memmy统一管理多Agent对话记忆，支持跨平台调用。
- iGeekbb: 闺蜜合伙创业易亏损，需谨慎。
- priyank joshi: 前端发展走过适配弯路，如今更高效。
- 歸藏(guizang.ai): Opus新版体验差，偷懒减工，不如4.6版本。
- 赵纯想: 年龄增长消磨少年心气，乐观渐成晨间限定。
- Yihui: AI图片应转WebP格式以节省流量提升体验，推荐Zipic转换。
- 向阳乔木: 科技公司对待书籍和AI控制权的态度引发争议。
- 鱼总聊AI: 卖家承担giffgaff封号售后责任并整理解决方案。
- 赵纯想: SpacetimeDB革新后端开发，实现数据库业务逻辑一体化与全栈类型统一。
- 宝玉: AI代码质量提升后，管理者减少干预转向全局把控以释放生产力。
📖 详细内容
宝玉 @dotey
宝玉 Prompt Engineer, dedicated to learning and disseminating knowledge about AI, software engineering, and engineering management. | 影响力: 0万粉丝
💡 核心观点: HTML+CSS是AI生成美观可编辑PPT的最佳中间格式。
可信度: 10/10 – 2项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ◦ 观点: AI生成PPT的最佳中间格式是HTML+CSS (该声明基于作者个人经验和偏好，属于主观结论，无公开标准或第三方验证支持。)
- ◐ 部分可验证: Claude Opus模型生成的HTML效果比GPT 5.6更好 (可通过实际测试Claude Opus和GPT的HTML生成效果对比验证，但“效果更好”涉及主观审美判断，需具体案例支撑。)
- ✓ 可验证: baoyu-design skill能1:1还原HTML为PPTX且无问题 (用户可通过作者提供的GitHub链接（https://github.com/jimliu/baoyu-design）和示例HTML（https://s.baoyu.io/files/baoyu-ai-skills-talk/ai-skills-talk.html）自行测试转换效果。)
原文内容:
关于AI生成PPT这件事，我确实有发言权。我开发过两个颇受欢迎的PPT技能模板：一个是纯图片版的"宝玉幻灯片"技能（baoyu-slide-deck），另一个是支持转原生PPTX格式的HTML模板（baoyu-design）。 我的核心观点是：要实现出色的设计效果且便于编辑，必须采用HTML+CSS方案。因为如果自行设计中间格式，很可能对AI不友好，最终成品要么美观度不足，要么只能组合出有限的风格样式——毕竟AI缺乏相关训练数据。不过现在像Claude Opus这样的模型已经能生成非常漂亮的HTML代码了。 或者说，HTML本身就是最佳的中间格式。 若需要转换为原生PPTX，则必须采用受约束的HTML+CSS方案，这样才能兼顾美观性和格式兼容性。 这是我最近用baoyu-design技能制作的PPT案例： https://s.baoyu.io/files/baoyu-ai-skills-talk/ai-skills-talk.html 最终实现了与PPTX格式的完美1:1转换。 就美观度而言，Opus模型表现最优，效果优于GPT-5.6。不过GPT的绘图模型很出色，可以配合使用来创建插图。比如这个幻灯片就是用Claude Code+Opus 4.8设计框架，再通过baoyu-image-gen技能调用Codex绘制插图完成的。 成本方面，如果不是大规模批量制作，差异并不明显，关键是要确保输出质量。 推荐尝试： https://github.com/jimliu/baoyu-design
⏰ 09:46 | ❤️ 304点赞 | 📝 267字 | 查看原文 →
Mr Panda @pandatalk8
Mr Panda AI builder & indie founder. Building products, writing ideas, and selling myself in public.
公众号：PandaTalk8 | 影响力: 74.88k万粉丝
💡 核心观点: 12个深度解析AI/LLM的优质博客助你建立长期认知
可信度: 10/10 – 3项声明可直接验证；1项需进一步确认；1项为观点陈述
事实核查:
- ✓ 可验证: Lilian Weng的博客（Lil’Log）涵盖LLM、Agent、RL、Scaling Law与AI Safety的论文综述式长文 (可通过提供的链接 https://lilianweng.github.io 直接访问博客，内容分类与主题描述一致，文章多为长文且标注论文引用。)
- ✓ 可验证: Sebastian Raschka的博客包含LLM架构、推理模型、论文解读与代码实现 (官网 https://sebastianraschka.com 显示其博客分类明确包含机器学习、LLM及代码实践，且有配套GitHub项目链接。)
- ✓ 可验证: 苏剑林的科学空间博客擅长中文AI技术内容，聚焦NLP、Attention与数学推导 (链接 https://spaces.ac.cn 可验证其为中文技术博客，近期文章主题与声明一致，含数学公式推导及NLP相关论文分析。)
原文内容:
别再只刷AI新闻了：12个值得长期阅读的AI/LLM技术博客 如果你只知道Lilian Weng却说不出第二个值得关注的AI博客，这份清单正适合你。 真正构建AI认知的，不是每天几十条模型发布快讯，而是那些愿意花数周时间深入研究、透彻解析问题的思考者。 以下12个博客涵盖AI原理、论文、数学推导、工程实践与前沿动态： 【研究综述与模型原理】 Lilian Weng — Lil’Log LLM、智能体、强化学习、扩展律与AI安全的论文综述长文 https://lilianweng.github.io Sebastian Raschka LLM架构、推理模型、论文解读与代码实现 https://sebastianraschka.com 苏剑林 — 科学空间 中文AI技术博客，专注NLP、注意力机制、位置编码与数学推导 https://spaces.ac.cn Sander Dieleman 深度解析扩散模型与生成模型，每篇都堪比微型专著 https://sander.ai 【AI工程与产品落地】 Eugene Yan LLM评估、检索增强生成、推荐系统及生产环境工程实践 https://eugeneyan.com/start-here/ Chip Huyen AI工程、数据处理、模型推理、部署与生产系统设计 https://huyenchip.com Simon Willison 高频实测最新模型、智能体与开发工具，拒绝空谈概念 https://simonwillison.net 【可视化与系统学习】 Jay Alammar 用可视化图解Transformer、BERT、嵌入等核心概念 https://jalammar.github.io Aman’s AI Journal 系统化涵盖Transformer、RAG、智能体、评估与LLMOps https://aman.ai/primers/ai/ 【开放模型与前沿趋势】 Nathan Lambert — Interconnects 开放模型、后训练技术、RLHF、推理模型与前沿研究 https://interconnects.ai 【经典档案】 Chris Olah’s Blog 神经网络可视化、表征学习与可解释性经典文献 https://colah.github.io Distill 机器学习交互式解释的标杆（已停更，存量文章仍值得精读） https://distill.pub 如果只能订阅5个，我推荐： Lil’Log + Sebastian Raschka + 科学空间 + Eugene Yan + Simon Willison 基本覆盖： 原理×论文×数学×工程×前沿动态 建议立即收藏，别让这份清单再次淹没在信息流中。 （注：我也在持续分享AI实用知识，欢迎关注）
⏰ 19:10 | ❤️ 32点赞 | 📝 437字 | 查看原文 →
Berryxia.AI @berryxia
Berryxia.AI | 影响力: 39.76k万粉丝
💡 核心观点: 让普通人用自然语言解决生意问题的工具才是中国AI的胜负手。
可信度: 6/10 – 1项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: 喀什卖包子的老板通过AI工具生成短视频脚本，将店铺从一家扩展到六家 (需核实该老板的具体案例（如店铺信息、AI工具使用记录等），但若无实名或公开数据支撑则难以完全验证。)
- ✓ 可验证: AI工具无需学习提示词或安装复杂程序，可直接用自然语言生成实用脚本 (部分AI工具（如ChatGPT、文心一言等）已支持自然语言输入生成脚本，功能可通过实测验证。)
- ◦ 观点: 中国AI的胜负关键在于「让普通人用自然语言解决生意问题」的工具 (此为对行业趋势的主观判断，无客观数据直接支持该结论。)
原文内容:
兄弟们，今天这个事儿真的还挺触动我的！ 明白真正能改变中国小生意的，不是Claude Code，而是让“卖包子的人”敢开口说话的工具。 全网都在吹终端、API、Skills有多强。 一个喀什卖包子的老板，初中毕业，每天凌晨四五点起来揉面，用一部手机、几百块钱，把店从一家开到六家。 起点就一句话：「帮我写个招客人来吃饭的短视频脚本。」 不用学提示词，不用装任何东西，工具直接把能用的脚本和思路交到他手里。 从那一条脚本开始，内容滚起来，生意滚起来，店也开到了六家。 当AI还在比谁的模型更聪明、谁的Agent更复杂时，真正下沉的工具已经在让没上过大学的人，用自然语言解决真实生意问题。 这跟当年电商被下沉市场做起来的路径，几乎一模一样。 你觉得中国AI真正的胜负手，会不会就在这些「敢让普通人开口」的工具上？
⏰ 16:17 | ❤️ 65点赞 | 📝 279字 | 查看原文 →
铁锤人 @lxfater
铁锤人 我在用 AI 协助我创业，走向自由 github 维护 3w star 项目，写过 1200w 浏览文章，公众号：铁锤人 商务联系：tiechuiren101 | 影响力: 0万粉丝
💡 核心观点: AI生成PPT难修改，关键时刻易误事。
可信度: 10/10 – 2项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: 用Skill做PPT可能导致无法修改关键信息，影响汇报结果 (需实测Skill的PPT功能是否支持修改或存在限制，但用户反馈或案例可部分佐证（如推文中的具体场景）。)
- ◦ 观点: cowork是唯一且正确的PPT制作软件 (此为主观推荐，未提供客观比较数据或权威依据，且“唯一正确”的说法具有排他性，属于个人观点。)
- ✓ 可验证: 做好PPT需满足三个黄金标准（未具体说明） (推文未列出具体标准，且关联的B站宣传片（kimi work）内容未提供链接或细节，无法直接验证。)
原文内容:
毁掉一场汇报最快的方法：用Skill做PPT 前段时间，朋友因为用Skill做PPT差点被辞退了！！ 他用Skill给上司做汇报的PPT，效果很不错。 但在等上司去汇报时候，上司发现漏了关键信息，需要修改几页PPT。 结果，AI生成的PPT不支持修改，最后只能带着错误的数据和大老板解释。 最后上司汇报回来后，特地找他谈话了。 这个事情他留下阴影，说以后再也不用skill做PPT了！！ 大多数人认为用skill做PPT效率很高。 但真正经历关键时刻的人才知道，skill做PPT是鸡肋 目前来说，做PPT唯一且正确的做法是用cowork这类的软件去做。 为什么呢？ 高手都知道，想要做好一个PPT需要满足三个黄金标准。 在B站上首发的kimi work宣传片，也很好地解释这一点。（不是广子，fable最好用） 下面的线程我们结合素材，一个一个讲清楚
⏰ 18:31 | ❤️ 70点赞 | 📝 250字 | 查看原文 →
苍何 @canghe
苍何 前大厂牛马开发，现 AI 创业，Microsoft MVP。 公众号【苍何】作者 。 专注AI出海，AI编程，智能体，MCP ，Skills。 出海寻找同频，分享 AI 干货。https://dinq.me/canghe | 影响力: 31k万粉丝
💡 核心观点: 利用聊天上下文构建个人知识库让AI更懂你。
可信度: 6/10 – 3项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: 将Codex和Claude Code的聊天上下文作为个人知识库可以提高使用流畅度 (需实测验证聊天上下文作为知识库的实际效果，且“丝滑”是主观描述，缺乏量化标准。)
- ◐ 部分可验证: 将聊天上下文反向push到Codex后，Codex会变得更懂用户，尤其在查询个人信息时 (需测试模型对上下文的记忆和个性化响应能力，但“异常懂你”是主观表述，依赖个人体验。)
- ◦ 观点: 该方法能让AI在真正理解用户的基础上，以用户的方式协助工作 (属于愿景性描述，无具体技术或数据支持“真正理解”这一主观主张。)
原文内容:
兄弟们，我发现把 Codex 和 Claude Code 的聊天上下文作为个人知识库，别提有多丝滑。 然后再把这些再反向 push 到 Codex，你会发现，Codex 变得异常的懂你，特别是要查个人一些信息的时候。 可谓是让 AI 在真正理解你的基础上，用你的方式帮你完成工作。 下面简单分享下使用方法：
⏰ 17:30 | ❤️ 21点赞 | 📝 98字 | 查看原文 →
泊舟 @bozhou_ai
泊舟 AI 程序员 & Vibe 编码者 | 构建 Agent 、系统提示与高效流程 | 热爱设计、编码，将想法转化为影响力|AI中转站创业中| 合作&咨询 +V:bozhou_ai | 影响力: 22.30k万粉丝
💡 核心观点: AI工具Remio能基于旧项目资料高效修改PPT，节省重复沟通时间。
可信度: 10/10 – 2项声明可直接验证；3项需进一步确认
事实核查:
- ◐ 部分可验证: remio工具能从已有资料中提取测试条件、评分、优缺点和结论，并重新组织成指定页数的PPT (需实测验证remio是否具备从历史资料中自动提取并重组信息的能力，且依赖用户提供的资料完整性。)
- ✓ 可验证: remio生成的PPTX文件支持直接编辑文字、图形和评分表，而非整页图片 (可通过下载remio生成的PPTX文件，检查其可编辑性（如修改文字/图形）直接验证。)
- ◐ 部分可验证: remio会为本地文件、网页、会议录音等建立本地索引，形成持续更新的个人知识库 (需实测工具是否具备多源数据整合和索引功能，但部分技术细节（如索引算法）可能未公开。)
原文内容:
我之前横评了 4 个 PPT Skill，测的是谁能从零做出一份能直接拿去讲的 PPT。 这次我换了一个更像真实工作的测试：让 AI 接手上次的旧项目，直接往下改。 因为老板平时很少让你重新做一份 PPT，更常说的一句话是：把上次那版改一下。 麻烦也从这里开始。 上次到底是哪版，评分表放在哪里，结论有没有改，会议里又补了什么要求，最后还得沿用哪套模板。这些项目背景，通常比写提示词本身更费时间。 普通聊天工具只知道当前对话。每次开始新任务，你都得把旧 PPT、原始文章、评分表和修改要求重新上传，再花一轮时间解释整个项目。 所以我拿之前做过的 PPT Skills 横评项目，测试了一款叫 remio 的工具。 我给它的要求很短： 把我之前《PPT Skills 实测》的内容，改成一份 8 页、10 分钟的内部分享 PPT。保留 4 个工具的评分和结论，删掉安装过程，增加一页“不同需求怎么选”，输出可编辑的 PPTX。 它从已有资料里找出了当时的测试条件、4 个 Skill 的评分、各自优缺点和最终结论，然后重新组织成了一份 8 页 PPT。 93、77、72、58，原来的评分全部保留。 新增的“不同需求怎么选”也不是随便按总分排序，而是根据最终交付物来分：正式汇报选 ppt-master，网页演示选 html-ppt-skill，社媒传播选 guizang，需要中文模板再加工可以考虑 GordenPPTSkill。 生成结果是可以继续编辑的 PPTX。文字、图形和评分表都能在 PowerPoint 里直接修改，不是把整页做成一张图片塞进去。 我又补了一句：帮这份 PPT 配图。 remio 先读取了生图和编辑规范，再判断每一页还有多少留白。中间的表格和对比页信息已经很满，它没有继续塞图，只在封面和结尾页调用 GPT-5.4 Image 2 生成了 2K 插图，配色也沿用了原来的藏青、浅蓝和暖金。 最后出来的版本，既保留了原来的评分和判断，也补齐了内部分享需要的结构、选择建议和视觉元素。 这次测试让我觉得 remio 比较特别的地方，是它会持续建立个人知识库。 本地文件、网页、会议录音、邮件、日历和聊天记录，都可以进入同一套上下文。它还会为这些资料建立本地索引，需要处理任务时，不只看当前对话，也会从已经积累的项目资料里找信息。 所以这次做 PPT 时，它调用的不只是一条提示词。原文章讲了什么、4 个 Skill 怎么评分、哪些结论应该保留、最后要交付什么格式，这些信息都来自之前的真实资料。 很多 AI 可以根据一句话生成一套看起来不错的 PPT，但真实工作里更高频的任务，是在现有项目上继续修改。 你需要的是一个已经知道项目来龙去脉、可以直接接着干活的办公助手。 remio 的知识库数据保存在本地，也支持解析 docx、pptx、Excel、CSV 和 PDF 等常用办公文件。 除了改 PPT，它还能根据已有资料补 Excel 字段、整理数据、写公式，生成项目方案、周报和月报，也能把会议录音转成文字，再继续整理结论和行动项。 付费用户还可以通过 CLI 调用本地知识库，或者使用自己的 coding plan 和 API Key，把 remio 接进现有工作流。 我的理解很简单：资料先进入同一套上下文，Agent 再基于这些资料干活。 所以 remio 更像一个通晓项目资料的 AI 办公秘书。它知道文件在哪里、之前讨论过什么、现在要交付什么，然后帮你继续改 PPT、补数据、写报告。 如果你平时也要处理大量项目文档，可以去试一下： https://remio.ai
⏰ 16:49 | ❤️ 43点赞 | 📝 1016字 | 查看原文 →
向阳乔木 @vista8
向阳乔木 喜欢摇滚乐、爱钓鱼的PM
网站：https://qiaomu.ai | 影响力: 0万粉丝
💡 核心观点: Memmy设计三层记忆系统，智能生成复用经验并方便搜索。
可信度: 6/10 – 1项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: Memmy 采用三层记忆系统设计，对应人的三种记忆模式（L1事实记忆→L2程序记忆→L3规律认知→Skill） (需通过实际测试或查阅Memmy官方文档验证其技术架构是否确实如此设计，但推文未提供直接技术文档链接。)
- ✓ 可验证: 在Codex中添加信息后，通过Claude Code提问“我喜欢什么？”时，Agent会调用Cli回答 (该声明依赖个人操作体验，未提供具体交互截图或公开功能说明，外部无法复现验证。)
- ◐ 部分可验证: Memmy能自动基于Agent对话提炼创建可复用的Skill，并支持搜索所有历史对话记录 (需实际安装应用或查看官方功能文档确认，推文附官网链接（https://memmy.bot）可能包含相关信息，但未明确指向具体功能页。)
原文内容:
Memmy 的 三层记忆系统设计有意思，对应人的三种记忆模式： L1 事实记忆 → L2 程序记忆 → L3 规律认知 → Skill（复用经验） 试着在 Codex 中添加了一些我的信息，换到 Claude Code 问：“我喜欢什么？” Agent 会调用 Cli 回答，感觉还挺方便的。 还会自动基于 Agent 对话，自动提炼创建可复用的Skill。 另外，能随时搜索所有 Agent 历史对话记录，也超级方便。 推荐安装体验： https://memmy.bot
⏰ 15:03 | ❤️ 24点赞 | 📝 115字 | 查看原文 →
向阳乔木 @vista8
喜欢摇滚乐、爱钓鱼的PM
网站：https://qiaomu.ai | 影响力: 0万粉丝
💡 核心观点: 开源工具Memmy统一管理多Agent对话记忆，支持跨平台调用。
可信度: 10/10 – 2项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ✓ 可验证: Memmy 是一个开源项目，能够统一管理不同 Agent 的对话和记忆 (可通过推文提供的链接 https://memmy.bot 或评论区提到的 GitHub 地址直接验证项目是否存在及其功能描述。)
- ◐ 部分可验证: Memmy 支持 Codex、Claude Code、Workbuddy、Hermes 等常见 Agent 的对话记录扫描管理 (需通过官方文档或实测确认是否支持所列的 Agent，部分 Agent 可能需进一步测试兼容性。)
- ✓ 可验证: Memmy 同时支持 Mac 和 Windows，并提供 TUI 和 Cli 界面 (可通过官网或 GitHub 的发布说明、文档直接验证支持的平台和界面类型。)
原文内容:
终于有人出手解决这个痛点了——实现不同智能体（Agent）的对话与记忆统一管理。 在Product Hunt上发现一个名为Memmy的开源项目。 https://memmy.bot 它能将Codex、Claude Code、Workbuddy、Hermes等常见智能体的对话记录统一扫描并集中管理。 软件设计相当完善，同时支持Mac和Windows系统，还提供文本用户界面（TUI）和命令行界面（Cli）。 这样即使不打开软件，也能通过任意智能体调用读取记忆，非常适合构建个人上下文系统。 GitHub地址详见评论区。
⏰ 15:02 | ❤️ 205点赞 | 📝 112字 | 查看原文 →
iGeekbb @igeekbb
iGeekbb 发一些碎碎念和有趣的东东，主打一个快分享。-私信开放欢迎投稿- | 影响力: 74.97k万粉丝
💡 核心观点: 闺蜜合伙创业易亏损，需谨慎。
可信度: 6/10 – 1项声明可直接验证；1项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: 10个闺蜜合伙开饭店，名字叫“欢天喜地十仙女”。 (可通过工商注册信息或饭店公开宣传资料（如社交媒体账号、招聘信息等）验证是否存在该合伙企业和命名，但需实际查询确认具体股东人数及名称真实性。)
- ✓ 可验证: 邹市明的成功案例让许多女性（“冉姐”）看到创业希望。 (邹市明的创业影响属于主观推断，无具体数据或公开报道证明其案例直接激励了特定群体；“冉姐”群体定义模糊，无法量化验证。)
- ◦ 观点: 十个仙女合伙创业会亏损，仇人看到都释怀。 (亏损预测和“仇人释怀”均为夸张表述，属于主观调侃，无客观事实依据或财务数据支持。)
原文内容:
实属逆天，前有七仙女咖啡馆，后有十仙女饭店。10 个闺蜜合伙开饭店，名字都想好了，叫欢天喜地十仙女，哈哈哈。 邹市明的成功案例让许多冉姐看到了希望，不要盲目去创业，这套路他太熟了，想想十个仙女得亏多少啊，仇人看到都释怀了。
⏰ 13:19 | ❤️ 147点赞 | 📝 95字 | 查看原文 →
priyank joshi @dingyi
priyank joshi promote your product ‣ [email protected]
‣ http://quaily.com/dingyi
‣ http://news.dex.group
‣ http://saaspick.dev
‣ http://topfeed.xyz | 影响力: 151.64k万粉丝
💡 核心观点: 前端发展走过适配弯路，如今更高效。
可信度: 6/10 – 1项声明可直接验证；1项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: 适配响应式设计需要找各种最佳实践，反复测试 (响应式设计的开发流程确实需要参考最佳实践和测试，但具体“反复测试”的频率和方式因团队或个人而异，需结合历史开发文档或工具日志验证。)
- ✓ 可验证: 早期需要写各种 hack 适配 IE6 (IE6 的兼容性问题（如 CSS Hack、条件注释等）有大量历史技术文档（如 MDN、Stack Overflow）和开源代码库（如早期 Bootstrap）可验证。)
- ◦ 观点: 前端没有死，人类只是走了很多年弯路 (这是主观观点，反映作者对前端技术演变的评价，无客观标准验证“弯路”或“前端已死”的结论。)
原文内容:
想想以前适配响应式设计，需要找各种最佳实践，反复测试，还有专门可以开很多个不同浏览器的测试软件，更早的时候还要写各种 hack 适配 IE6，不知道浪费了多少时间在这些破玩意上。 前端没有死，人类只是走了很多年弯路。
⏰ 12:04 | ❤️ 25点赞 | 📝 89字 | 查看原文 →
歸藏(guizang.ai) @op7418
歸藏(guizang.ai) 关注人工智能、LLM 、 AI 图像视频和设计（Interested in AI, LLM, Stable Diffusion, and design）
歸藏的 AIGC 周刊｜公众号：歸藏的AI工具箱 | 影响力: 0万粉丝
💡 核心观点: Opus新版体验差，偷懒减工，不如4.6版本。
可信度: 8/10 – 1项声明可直接验证；2项需进一步确认；2项为观点陈述
事实核查:
- ◐ 部分可验证: Opus 4.7、4.8 和 5.0 版本的使用体验比 4.6 更差 (可通过用户实测对比不同版本的响应质量、任务完成度等指标验证，但“使用体验”涉及主观感受，需依赖大量用户反馈或第三方评测数据，无法完全客观量化。)
- ◐ 部分可验证: Opus 模型在自动化循环中会削减需求工作量（如将7个需求完成度降至20%） (可通过设计自动化任务测试模型输出（如需求覆盖率、任务完成度），但“削减工作量”的指控需明确标准（如响应长度、逻辑完整性），且结果可能因任务类型而异。)
- ✓ 可验证: Anthropic 无法复现或超越 Opus 4.6 的性能 (模型训练细节和内部评估数据未公开，且“性能”定义模糊（如基准测试成绩与用户体验可能冲突），仅能通过后续版本更新间接推测。)
原文内容:
要不是 Cloud Max 有 Fable 5 的话，我现在根本都不想订阅。 Opus 4.7、4.8 和 5.0 都太他妈拉胯了，越来越拉胯。 测试成绩越来越好，但是使用体验上效果越来越差：就是疯狂地不说人话、无法沟通，加上疯狂偷懒。 它就像那种大厂里面最讨厌的同事，全是说教，但是不干活。 而且你给他布置任务以后，他疯狂地通过各种方式削减自己的工作量。 一旦用在自动化循环里，你就会发现你给他 7 个需求，他说都做完了，但是每一个需求都给你砍到原有工作量的 20%，最后的结果就是每个都不能用。 很难想象 Anthropic 这个公司现在经历了什么。 就好像 Opus 4.6 是一个偶然的结果，他们根本没有掌握怎么样再训出一个比 Opus 4.6 更好的 Opus 模型。
⏰ 11:33 | ❤️ 335点赞 | 📝 228字 | 查看原文 →
赵纯想 @chunxiangai
赵纯想 http://laper.ai – AI剧作 http://bellybook.cn – 胃之书 http://love.chunxiang.space – 入门课程 http://chunxiang.ai – 顾问服务 http://motherbase.app – 出海神器 | 影响力: 38.16k万粉丝
💡 核心观点: 年龄增长消磨少年心气，乐观渐成晨间限定。
可信度: 6/10 – 1项声明可直接验证；2项为观点陈述
事实核查:
- ✓ 可验证: 30岁后早晨会感到充满希望，而午夜会自我怀疑，这种情绪波动与25岁时全天分泌的某种物质有关 (情绪波动与年龄相关的生理变化（如激素分泌）的关联性缺乏具体科学依据或公开数据支持，属于个人体验的推测。)
- ◦ 观点: 40岁后可能完全失去信念感（“啥也不相信”） (这是基于个人对年龄增长的主观推测，无客观事实或研究数据支持，属于主观观点。)
- ◦ 观点: 少年心气与年龄增长导致的信念感变化相关 (“少年心气”是抽象概念，其与年龄的关联性无统一标准，属于个人对生活体验的比喻性表达。)
原文内容:
到了30岁最明显的感觉：早晨起来，相信任何事情可能发生。进入午夜，可能会怀疑自己。早晨起来，又全都相信了。也就是说，某些25岁的人全天都分泌的东西，30岁后只有晨间才分泌了。我估计到了40岁，就啥也不相信了。也许这就是所谓的：少年心气吧。
⏰ 11:00 | ❤️ 92点赞 | 📝 97字 | 查看原文 →
Yihui @yihui_indie
Yihui – AI Coding：https://happyaicoding.com
– AI Anime：https://mkanime.ai
– Bilibilier & Youtuber & Builder | 影响力: 52.06k万粉丝
💡 核心观点: AI图片应转WebP格式以节省流量提升体验，推荐Zipic转换。
可信度: 6/10 – 1项声明可直接验证；2项需进一步确认
事实核查:
- ◐ 部分可验证: AI 生成的图片没有转化成 WebP 格式会导致图片体积大、消耗大量流量并影响用户体验 (WebP 格式通常比 PNG/JPEG 更节省体积，但具体流量消耗和体验影响需实测对比原始格式与 WebP 格式的图片数据，且“用户体验”涉及主观感受。)
- ✓ 可验证: 推荐使用 Zipic（https://zipic.app）进行 WebP 格式转换和压缩 (可通过链接访问官网，验证工具是否支持 WebP 转换及压缩功能，但“体验非常好”为主观评价（见下条）。)
- ◐ 部分可验证: Zipic 的格式转换和压缩体验非常好 (用户体验是主观评价，无统一标准验证，需依赖个人感受。)
原文内容:
我才发现，最近团队的产品经理和后端研发同学在开发网站时，经常会犯一个小问题：AI 生成的图片没有转化成 WebP 格式，这样图片一般会很大，同时会消耗大量的流量，并且用户的体验也不太好。 建议大家都转成 WebP 格式。我这里推荐使用 Zipic 进行格式转换和压缩，体验非常的好。https://zipic.app
⏰ 10:59 | ❤️ 131点赞 | 📝 108字 | 查看原文 →
向阳乔木 @vista8
喜欢摇滚乐、爱钓鱼的PM
网站：https://qiaomu.ai | 影响力: 0万粉丝
💡 核心观点: 科技公司对待书籍和AI控制权的态度引发争议。
可信度: 8/10 – 2项声明可直接验证；1项需进一步确认；1项为观点陈述
事实核查:
- ✓ 可验证: Anthropic正在批量销毁稀有书籍来做蒸馏。 (该声明缺乏具体来源或公开证据（如官方声明、新闻报道或影像记录），目前仅基于匿名爆料，无法直接验证真实性。)
- ◐ 部分可验证: 马斯克称Grok会扫描珍本书籍，但要求不拆缝线以保护书籍。 (若马斯克曾在公开平台（如X/Twitter）发表此言论，可通过其社交账号历史记录验证，但实际操作细节（如是否真正执行）需进一步核实。)
- ✓ 可验证: 奥特曼在访谈中表示害怕极少数人以“AI太危险”为由垄断AI控制权。 (若奥特曼的访谈内容被公开报道或录制（如播客、视频），可通过原始访谈记录直接验证其表述。)
原文内容:
有人爆 Anthropic 自己正在批量销毁稀有书籍来做蒸馏。 马斯克马上说Grok也会扫描珍本书籍，但要求不拆缝线，要保护好这些书。 奥特曼虽然也不怎么被待见，但最近访谈里表示： 他非常害怕这样一种世界：极少数人以"AI 太危险、只有我们才懂"为理由，把 AI 掌控在自己手里。” Anthropic的CEO 达里奥的好人缘已经快败光了。 过度自信，总提一些看起来明显为自己利益服务的论点。
⏰ 10:34 | ❤️ 45点赞 | 📝 140字 | 查看原文 →
鱼总聊AI @ai_jasonyu
鱼总聊AI AI & 出海& Saas & APP & 海外手机卡eSIM实操干货分享 8年产品经验 | 单款产品营收 $200k+ （全自然流量 ） 代表作：@PaywallPro1 付费墙Agent：http://paywallpro.app 2胎爸爸 | 私信聊合作/咨询：jasonyu110 | 影响力: 47.67k万粉丝
💡 核心观点: 卖家承担giffgaff封号售后责任并整理解决方案。
可信度: 10/10 – 3项声明可直接验证；2项需进一步确认
事实核查:
- ◐ 部分可验证: giffgaff 本月开始大面积限制长期境外漫游用户 (可通过 giffgaff 官方公告或用户社区反馈验证是否存在封号政策，但具体封号规模（如”大面积”）和标准（如”长期境外漫游”）需依赖用户实测或内部数据，普通用户难以全面核实。)
- ✓ 可验证: 卖家有一千多张 giffgaff 卡仍在运输途中 (涉及卖家个人库存和物流信息，无公开数据或第三方证明，除非提供具体物流单据，否则无法验证真实性。)
- ✓ 可验证: 卖家整理了售后政策文档并承诺承担相应责任 (提供的飞书文档链接（需权限验证）可直接查看政策内容，承诺行为可通过后续实际售后行动验证，但需注意文档可能被修改。)
原文内容:
兄弟们，在我这下单的卡，售后政策来了！ 政策链接： https://my.feishu.cn/wiki/Diz5wOLPBiJ61vknn1lctFJunOh… 关于这次 giffgaff 大面积封号，我想跟大家说几句。 说实话，封号这件事让我挺意外的。 我是从6 月才开始卖 giffgaff 手机卡，前后只有一个多月。上个月看到终于有了一点利润，当时还挺开心，觉得自己找到了一项可以长期做下去的小业务。 结果没想到，这个月 giffgaff 就开始大面积限制长期境外漫游用户，这个业务直接宕机，也包含了我还在路上的一千多张卡。 很多粉丝朋友来找我，有的人担心余额，有的人担心号码，更有人绑定了银行、邮箱和各种账号。 这些卡虽然不是我生产的，封号也不是我能决定的，但它们确实是从我这里卖出去的。 我觉得售后这件事，我不能躲。 该承担的我会承担，该协助的我也会一直协助。 这两天，我把目前海外社区、官方资料以及用户实测的方法全部整理了一遍，也把售后政策统一写成了一份文档。 以后所有更新都会放在这里，避免大家到处找消息。 希望这份文档，能尽可能帮大家减少损失，也谢谢大家一直以来对我的信任。
⏰ 10:26 | ❤️ 131点赞 | 📝 358字 | 查看原文 →
赵纯想 @chunxiangai
http://laper.ai – AI剧作 http://bellybook.cn – 胃之书 http://love.chunxiang.space – 入门课程 http://chunxiang.ai – 顾问服务 http://motherbase.app – 出海神器 | 影响力: 38.16k万粉丝
💡 核心观点: SpacetimeDB革新后端开发，实现数据库业务逻辑一体化与全栈类型统一。
可信度: 10/10 – 2项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ◐ 部分可验证: SpacetimeDB没有传统后端，业务逻辑直接“坐在”数据库里运行。 (需查阅SpacetimeDB官方文档或技术白皮书，确认其架构设计是否真正消除传统后端层，并将业务逻辑嵌入数据库。目前缺乏直接公开的代码或架构图佐证。)
- ✓ 可验证: SpacetimeDB通过一套Type System统一数据库、服务端和客户端类型，减少AI对齐Schema的复杂度。 (可通过官方文档或示例代码验证是否实现类型系统跨层统一，例如检查是否支持共享类型定义文件或自动生成多端类型。)
- ✓ 可验证: SpacetimeDB原生支持实时同步，数据变化自动推送给客户端，无需额外集成WebSocket等工具。 (官方演示或文档通常会展示实时同步功能，可通过实际测试或查看API设计验证其实现机制。)
原文内容:
我一直在期待这样一个牛逼大辣子级别的东西。现在它出现了：SpacetimeDB。 一人成军，Vibe Coding 天生友好集大成者。 1、没有传统后端，业务逻辑直接“坐在”数据库里运行。 2、一套 Type System 打穿数据库、服务端和客户端。AI 不用反复对齐 Schema、ORM、API 类型。Agent需要理解的上下文更小了。它可以一次性看懂整个后端，而不是在Node.js、PostgreSQL、Redis、ORM、WebSocket、Docker和K8s之间来回迷路。 3、原生实时同步。数据变化自动推送给客户端，不需要再拼 WebSocket、消息队列、缓存和状态同步。 4、事务、鉴权、部署和数据同步都在同一个系统里。少掉的不只是代码，而是大量最容易被AI写错的胶水层。 真正的 ALL IN ONE ！
⏰ 09:25 | ❤️ 220点赞 | 📝 192字 | 查看原文 →
宝玉 @dotey
Prompt Engineer, dedicated to learning and disseminating knowledge about AI, software engineering, and engineering management. | 影响力: 0万粉丝
💡 核心观点: AI代码质量提升后，管理者减少干预转向全局把控以释放生产力。
可信度: 10/10 – 2项声明可直接验证；2项需进一步确认；1项为观点陈述
事实核查:
- ✓ 可验证: 从 TL（Teach Lead） 的角色变成了 EM（Engineering Manager） 的角色，技术参与深度减少 (角色转变及个人工作方式的变化属于个人体验，缺乏公开记录或第三方证据支持。)
- ◐ 部分可验证: AI 写的代码质量在 Fable 5 前后显著提升，只需稍加验证即可使用 (需实测或对比历史版本代码质量，但推文未提供具体案例或数据，依赖主观判断。)
- ◐ 部分可验证: 使用 Swift + AppKit 原生技术栈替代 Electron 是因性能问题，且 AI 辅助克服了 Swift 不熟悉的问题 (技术栈切换和性能问题可通过代码仓库或版本更新记录部分验证，但 AI 辅助的具体作用无法直接验证。)
原文内容:
今年以来，我在使用 Coding Agent 方面有一个很大的变化，就是从 TL（Teach Lead） 的角色变成了 EM（Engineering Manager） 的角色。 这两个角色主要差别在技术参与深度多少。 之前我更像一个 TL，虽然不是说事必躬亲，但是系统设计、代码审查什么的肯定是少不了的，说到底还是对 AI 写的代码不放心。 这样虽然质量更有保障，但是人会成为 Agent 的瓶颈，很多事情需要人去决策，细节需要人去掌握。 转折点在 Fable 5 前后，我发现 AI 写的代码质量已经相当可以了，只要稍加验证就不会有太大偏离，所以我越来越少的去干预 AI 写代码，而是会更站在全局去看一个项目： 决定项目怎么做，去验收好结果。 这极大的释放了 Agent 的生产力，大部分时候我想好要做什么功能，先和 Agent 一起做一个技术方案，然后确认方案没问题后，用 /goal 加上方案，让 Agent 去执行，写代码和自动化测试，等做好再去验收下功能，代码不怎么细看。 有 Bug 了就是把 Bug 描述给 Agent 让它自己去重现解决，并且让 Agent 补上相关测试覆盖，修复了后人再去验证一下。 这样还有一个好处，就是在技术选型时，不会局限于你自己的喜好和擅长。 当你是 TL 的角色是，还是会有点过度关注技术实现，包括技术选型会偏向你自己熟悉的喜欢的，而不一定是最适合的。 当你是 EM 的角色做技术选型，就不再关注自己擅长什么，而是什么技术最适合项目。 我因为前端熟悉，所以最开始开发字幕翻译 App 时，就优先考虑 Electron 这样的技术栈，因为自己熟悉，有问题能解决也能写的出来。 后来发现 Electron 性能很难满意，就换成了 Swift + AppKit 原生技术栈，本来我 Swift 是不熟悉的，但有 AI 辅助，整个过程毫无压力。 现在在设计 BaoCut 下一个大版本的时候，要考虑跨平台方案，首选是 Rust，哪怕我从来没写过一行 Rust 代码，但我知道这是一个很好的跨平台选择。 目前基于 Rust 的第一个版本已经写完了，整个过程几乎没有任何语言上的障碍。 通过这样的模式我在开发 BaoCut 的时候，基本上可以每天一个小版本迭代。https://baocut.app/releases/ 这两天速度慢下来了，是因为需要构思新的大版本，这时候人就又成了瓶颈了：如果人没想清楚该做什么，Agent 再厉害也帮不上。
⏰ 04:03 | ❤️ 316点赞 | 📝 690字 | 查看原文 →
相关文章
