meng shao(@shao__meng)

某个 Shopify 团队在做内部工具，创始人兼 CEO Tobi 两周后才得知此事，强力介入并把项目掉头？ Tobi 正面回应了这个传闻，也让我们看到了 Shopify 这个知名团队创始人的工作...

meng shao (@shao__meng) — Fri, 11 Sep 2026 14:28:19 GMT

某个 Shopify 团队在做内部工具，创始人兼 CEO Tobi 两周后才得知此事，强力介入并把项目掉头 ？

Tobi 正面回应了这个传闻，也让我们看到了 Shopify 这个知名团队创始人的工作方式：
Founder-mode-as-a-service！

1. 那个被砍掉的架构确实该砍。 Tobi 把原方案形容为“cosplaying an enterprise production app”：团队给内部工具搭了 headless Rails + GraphQL API + React 单页应用的前后端分离架构，结果连改个小功能都需要前端工程师介入。他的判断是：内部工具就该用朴素的 Rails 全栈（服务端渲染、单仓库、一人可改全栈）。这是典型的“架构凭空过度设计”，为想象中的规模和复杂度设计，而非实际需求。

2. 这类干预往往是一线团队主动请他做的。 Tobi 说自己经常做这种裁定，通常是因为有团队成员私下请他出手；想砍掉过度设计的一方需要一个“唱黑脸的人”，而他愿意在认同前提时扮演这个角色，省掉无休止的会议和变革管理流程。Shopify 内部戏称这项服务为 "Founder-mode-as-a-service"。

3. 他不只裁决，还做“决策复盘”。 十年来他持续做一档内部播客叫 Context，回头讲解这些决策当时的推理过程，目的是教会其他人以后不需要他也能做出同样的判断。他顺带点出这背后的敌人是沉没成本谬误，团队倾向于因为“已经投入这么多”而继续错的方向，而复盘机制就是为了对抗这一点。

4. 对“Shopify 是尽管有他干预才成功”的说法，他不接受。 他认为反过来才成立：公司的成功正因为这类干预。他称“两周后 tobi 才得知……”这种叙事是胡扯，并说那次项目掉头是他最成功的干预之一。他用一句很有担当的话收尾：“让公司保持高效、低技术债，这就是我作为 CEO 的本职工作；所以，罪名成立。” 最后他补了一刀：这类流传的故事之所以受欢迎，只是因为它们比承认“团队确实需要有人来叫停愚蠢的过度架构”更有趣，是更好的“cope stories”。

tobi lutke@tobi

Yep. Except:

1. This was about important internal tools. The team was stuck in some architecture nightmare of their own doing (writing it in rails but headless, with graphql api, and a SPA react app, constantly needing frontend engineers for changes). I call this kind of thing 'cosplaying an enterprise production app'. All that complexity was in the way and using straight rails was perfect in that case.

2. I make calls like this all the time. Usually someone on the team asks me to. They see what needs to happen but don’t want to be the bad guy. I’m happy to just make the call if I agree with the premise. Saves enormous amounts of meetings and change management etc. Sometimes this is jokingly referred to as Founder-mode-as-a-service here.

3. For ten years I’ve also run an internal podcast called Context, where I revisit decisions like these and explain the reasoning so everyone can learn from them. This is helpful to give people all the variables that were considered and why this was the choice made given the information available at the time. I want to teach how to make such decisions effectively without needing me. Sunk cost fallacy is a problem.

4. Any notions that Shopify is succcessful despite of me doing this, instead of because of it, will have a hard time making their argument come together I think 😄

the part of 'two weeks later tobi learns about...' is nonsese and the pivot of that project up there happens one of the more successful examples of interventions. But getting the company to work effectively with great architecture and low technical debt baggage into the right direction is literally the job, so guilty as charged I suppose.

But there are always cope stories floating around like this because they are more fun, than saying 'somehow we needed tobi to stop doing silly architecture astronautics'.  I can totally see that.

🔗 View Quoted Tweet

💬23🔄1❤️14👀5918📊24

⚡ Powered by xgo.ing

细看 CursorBench 4.0 数据，才发现了 “一枝独秀” 的 Gemini 3.8 Flash ... 单看 cost 和 score，平平无奇，泯然众人；不是最贵，也不是最强。但再看...

meng shao (@shao__meng) — Fri, 11 Sep 2026 11:55:30 GMT

细看 CursorBench 4.0 数据，才发现了 “一枝独秀” 的 Gemini 3.8 Flash ...

单看 cost 和 score，平平无奇，泯然众人；不是最贵，也不是最强。

但再看 token 和 step，简直遥遥领先 😂 tokenmaxxxing 和 stepmaxxxing 无疑了，像极了你那个非常努力，通宵达旦的学习，但只能考到中等；一旦放松马上掉队的同学

Your browser does not support the video tag.

🔗 View on Twitter

meng shao@shao__meng

SWE-bench 等公开基准被“刷爆”，Cursor 更新发布私有基准 CursorBench 4.0

· Claude Fable 5.1、Opus 5 贵但确实最强
· GPT-6 Astra 不参与评测（原因你懂）
· Grok 4.6 表现不突出，和 Muse Spark 1.3 相比优势不大，且更贵
· Lee 表示 Grok 4.7 会有很大提升

cursor.com/cn/cursorbench

再看看 CursorBench 方法论：从真实会话中“反向出题”
核心机制是 Cursor Blame：将已提交的代码追溯回生成它的智能体请求，天然形成“开发者查询—标准答案”配对。配套设计包括：
· 防泄漏：大量任务来自内部代码库和受控来源，且每隔数月整体更换题库；
· 任务更重：从初版到 3.0，任务规模（代码行数、涉及文件数）约翻倍，明显大于 SWE-bench 各变体，并引入 monorepo 多工作区、排查生产日志、长时实验等难题；
· 刻意保留歧义：任务描述保持简短、信息不充分，模拟开发者真实的表达方式，而非为方便评分而人为消除不确定性。

评测理念：线上-线下双闭环
CursorBench（线下）衡量正确性、代码质量、效率、交互行为多个维度；线上评估则在真实流量上做受控实验，专门捕捉“离线得分高、但开发者实际体验更差”的回归，这类问题是纯离线评测的盲区。

Cursor 给了一个消融实验案例：完全移除语义搜索工具后，才准确定位其价值集中在大型代码库的仓库级问答场景。

🔗 View Quoted Tweet

💬21🔄1❤️13👀19253📊20

⚡ Powered by xgo.ing

[RAG 论文分享] VikingRAG：匹配 SOTA 准确率、Token 成本降到 5%–32% 现有问题：RAG 高准确率依赖结构上下文与多轮交互，是 token 开销的主要来源企业问答、...

meng shao (@shao__meng) — Fri, 11 Sep 2026 03:41:24 GMT

[RAG 论文分享] VikingRAG：匹配 SOTA 准确率、Token 成本降到 5%–32%

现有问题：RAG 高准确率依赖结构上下文与多轮交互，是 token 开销的主要来源

企业问答、法律、财报等场景的语料都是章、节、段落组成的结构化文档，结构本身就是检索线索，它指示事实归属与局部和全局的关联。

现有 RAG 方法陷入两难：不用结构（朴素向量 RAG、图 RAG、SQL-RAG）丢失导航线索，准确率低；用结构（MoDora、BookRAG、DeepRead）准确率高，但 DeepRead 要把候选文档的完整目录塞进 prompt，开销随目录规模线性增长，加上多轮交互历史不断累积，token 成本巨大。

论文地址
arxiv.org/pdf/2609.11390

# 三个核心设计

1. 层次化语义存储：把结构从 prompt 搬进可查询的外部状态。 文档分块后保留所属结构节点，自底向上生成节点摘要，目录、块、摘要全部物化为 URI 可寻址对象（如 viking://Pasta/Carbonara/），祖先-后代关系编码为 URI 前缀。系统向代理暴露 Search / List / Grep / Read 四个工具，语义与结构路径共享同一 URI 空间。效果：结构 token 与实际访问的目录片段成正比，而非与完整目录成正比——直接消解 DeepRead 的线性开销。

2. 证据缺口驱动的多轮检索。 Agent 每轮判断证据是否充分，不充分则继续调用工具（轮数预算 B=15），充分即作答。设计哲学是粗定位与细验证分离：Search 锚点 → Read 查看后发现缺口 → List 相邻块 → Grep 精确命中 → Read 验证，每步把搜索空间收窄到相关子树内。

3. 经验边 + 自适应升级——让相似查询不必重复探索。 经验边从历史检索轨迹中把“Search 命中的 URI”连向“真正支撑答案的 URI”，边上存历史问题嵌入做查询时过滤；新查询沿边做条件化多跳扩展，复用路径而非重新探索（VikingRAG-E）。经验积累足够后，多数查询一轮检索即可作答——用约束感知的充分性判断器先验证证据是否支撑答案的关键约束，验证不过关才升级为完整多轮代理检索（VikingRAG-E+）。

# 实验结果：token 降至 SOTA 的零头

6 个真实结构化文档数据集（从 0.24M 词元的课程大纲到 8.78M 词元的财报），8 个基线，骨干 LLM 为 DeepSeek-V4-Pro，并在 GPT-5.5、Seed-2.0、GLM-4.7 上验证稳健性。主要结论：

· 准确率与所有基线持平或更高（DeepRead 通常是最强基线）；
· 基础版 VikingRAG 仅消耗 SOTA 方法的 11.6%–51.9% token，完整版 VikingRAG-E+ 降至 5.1%–32.5%，延迟同样显著更低；
· 逐层消融：经验边再省 12%–33% token，自适应升级再省 19%–50%；
· 可扩展性：LightRAG、HippoRAG-2 在最大数据集上 24 小时内无法完成摄入，BookRAG 在多数数据集上超时；而 VikingRAG 在文档数从“仅相关文档”增至 991 篇时性能基本稳定——因为它是按需定位，不随语料规模膨胀；
· 存储方面：插入延迟与 DeepRead/MoDora 相当、远快于图方法；代价是摄入期 token 更高（为每个索引对象生成预览）；文档删除零 LLM 成本。

💬10🔄6❤️34👀3096📊24

⚡ Powered by xgo.ing

OpenAI 把 Codex Agent Harness 产品化了！ Agents API：开发者通过一次 API 调用，就能创建一个由 OpenAI 托管运行、可在云端连续工作数天的生产级 Age...

meng shao (@shao__meng) — Fri, 11 Sep 2026 01:47:52 GMT

OpenAI 把 Codex Agent Harness 产品化了！

Agents API：开发者通过一次 API 调用，就能创建一个由 OpenAI 托管运行、可在云端连续工作数天的生产级 Agent。和 LLM API 不同，模型之上的编排层也由 OpenAI 负责，开发者只定义 Agent 的差异化能力。
openai.com/index/introduc…

Agents API 解决什么问题？
OpenAI Codex 和 ChatGPT for Work 的经验表明，生产级长时 Agent 的瓶颈不在模型，在于两件每家都要重复造的轮子：
· Harness：上下文管理、工具高效调用、多 Agent 协调
基础设施：支撑 Agent 连续运行数天的可靠环境与沙箱

Agents API 把这两件事平台化：Agent Loop 跑在 OpenAI 的基础设施上，由它协调模型调用、工具使用和上下文；开发者则掌握 Agent 的能力定义和运行环境。

Agents API 架构：编排归 OpenAI，环境归你
最核心的设计决策——“Your sandbox, your call”。执行环境三档可选：
1. 自带沙箱：Agent 跑在自己的机器里；
2. 沙箱合作伙伴：Blaxel、Cloudflare、Daytona、DigitalOcean、E2B、Modal、Oracle、Runloop、Vercel，覆盖全托管到 VPC 部署，CPU/GPU/内存、冷启动、成本各有组合；
3. OpenAI 托管沙箱（新推出）：与 Codex 同源的沙箱设施，可在供给时注入文件、安装包、添加技能和插件，Agent 能运行代码、操作文件、产出工件。

这个解耦化解了企业采用的最大顾虑（代码和数据在哪跑），同时把真正的增值部分 Harness 留在自己手里。

Harness 的三项关键能力
1. 长会话续航：接近上下文上限时自动压缩，工作流可跨越多个上下文窗口，无需自写压缩逻辑；
2. 大规模工具使用：tool search 按需加载工具定义（省 token 且保留模型缓存）；programmatic tool calling 让模型在代码中并行调用、链式组合、过滤工具结果；原生支持 MCP、自定义函数和内置工具（如 web search）；
3. Subagent 并行：主 Agent 把任务拆给多个并行子 Agent，各自持有独立上下文，由主 Agent 汇总，无需自建编排系统。

OpenAI Developers@OpenAIDevs

Go from idea to a working agent faster with the Agents API.

Build and run cloud agents with the Codex harness, fully managed by OpenAI.

We handle orchestration, long-running sessions, and context management. You focus on what makes your agent unique.

Available in public beta.

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬11🔄1❤️7👀3636📊12

⚡ Powered by xgo.ing

AI Engineering Skills Map 系列之「塑造构建方向」吴恩达老师的 AI 工程技能图谱最后一篇详细展开： 1. 构建与部署 AI 应用 2. 软件工程基础 3. 使用 ...

meng shao (@shao__meng) — Fri, 11 Sep 2026 01:24:26 GMT

AI Engineering Skills Map 系列之「塑造构建方向」   

吴恩达老师的 AI 工程技能图谱最后一篇详细展开： 
1. 构建与部署 AI 应用
2. 软件工程基础
3. 使用 Coding Agent
4. 塑造构建方向（本文主题）

吴恩达老师的出发点是一个结构性变化：传统模式下，产品经理和设计师负责定义“做什么”，开发者负责“怎么做”，项目经理推进时间线。而 AI 工具极大扩展了单个开发者的产出能力，这条分工线正在消融——掌握 AI 工程技能的开发者开始参与产品和决策角色（正如 PM 和设计师也在学习工程技能）

而「塑造构建方向」的核心命题就是：
你最好的工作将不再是实现别人写好的规格说明书，是主动塑造构建本身。

这个变化的价值在于速度：不必等待 PM 决定下一步做什么，软件开发被“极大加速”。同时他也指出，前端等专精开发者已在走向更广的全栈角色，而 AI 工程的职能范围甚至超出全栈——延伸至市场、财务、法务等领域。这一判断的底层逻辑与图谱第三层直接呼应：Coding Agents 在“给定清晰 spec 后的交付”上进步飞快，因此工程工作的重心正转向“决定 spec 里应该有什么”。

# 吴恩达老师给出四项子技能

一、驱动构建循环（Driving the build loop）
软件开发本质上是一个循环：写代码 → 获取反馈 → 决定下一步。AI 工程师要成为这个循环的驱动者，以“行动偏好”按 AI 赋予的高速度运转。具体包括：
· 选择正确的构建形态：快速原型（验证技术概念或功能假设）、MVP（向用户证明价值）、增量功能、或投入企业级系统建设；
· 小批量交付以维持速度节奏；
· 判断何时收集何种信息：是找用户/干系人拿反馈，还是跑技术实验（如训练模型）来决定下一步；
· 权衡决策输入：产品愿景、项目阶段、技术可行性、关键风险、工作量和预算；
· 对成熟项目，定义核心指标并以项目管理方式推动指标改善。

二、做产品决策（Making product decisions）
开发者不必转型为 PM，但必须能处理 spec 未覆盖的决策——如果没有 spec，甚至要能自己写一份。这要求三种感觉：
· 产品感：无需事事等 PM，能选出真正满足用户需求的方向；
· 设计感：至少是基础层面的——做出既可用又令人愉悦的东西；
· 商业感：想清楚 GTM、市场规模、单位经济模型和损益（P&L），做出经济上合理的取舍。

吴恩达老师特别强调，这一切的根基是对用户的同理心，并且需要持续打磨，方法按规模递进：与 2–3 位用户做快速非正式访谈 → 数百人规模的问卷 → 大规模 A/B 测试 → 分析数千至数百万用户的行为数据。

三、沟通与引领（Communicating and leading）
既然 AI 工程师的职责半径扩展到了市场、财务、法务等职能，跨职能沟通与干系人对齐就变得前所未有地重要。

同时存在一个时机性机会：AI 演进太快，工程之外的人都在努力理解它对自身工作和新产品形态的影响，技术上的领先让工程师“占得先机”，比如向组织说明哪些方向在技术上可行，从而在更广的层面引领组织前行。

四、高能动性主导权（High-agency ownership）
这是四项中最具个人主动性色彩的一项。吴恩达老师观察到，许多管理者（包括高管）尚不清楚 AI 能做什么，因此无法识别好的项目方向——这个认知缺口正是技术者的机会：主动发现问题、提出方案并执行，在尊重组织优先级和约束的前提下，不等自上而下的精确指令。

具体要求：识别机会、排定优先级、端到端地主导项目、对问题承担责任、在模糊中行动、在挫折中坚持，并且以创造的价值而非完成的任务来衡量自己的工作。

吴恩达老师最后的结论：塑造构建（而非仅仅构建）让 AI 工程比传统软件开发更激动人心；你被赋予更大权力、拥有更广的职责范围、做出更多决策；但代价是更大的技能集要求。因此最后一项底层要求是持续学习：追踪技术前沿、试用新工具、不断调整工作流。（“持续学习的心态”正是整个技能图谱四层之下的共同地基。）

info.deeplearning.ai/driving-the-bu…

meng shao@shao__meng

AI Engineering Skills Map 系列之「使用 Coding Agent」  

吴恩达老师的 AI 工程技能图谱第三篇详细展开： 
1. 构建与部署 AI 应用
2. 软件工程基础
3. 使用 Coding Agent（本文主题）
4. 塑造构建方向

吴恩达老师认为：使用 Coding Agent 正在成为 AI 工程师的关键能力，而且它的演进速度比其他顶层技能都快，因为 Agent 本身在 harness 和模型两个层面同时快速迭代。因此，这项技能没有终态，只能靠持续的实验、构建和学习来维持。

# 用 Coding Agent 构建软件的通用工作流

通过访谈数十位顶尖 AI 工程师并复盘自己团队的实践，他归纳出一个一致的高层工作流，分三步：
1. 规划（Planning） 包含两部分：一是头脑风暴，可能涉及研究、实验、理解已有代码库；二是写 spec（规格说明），涵盖需求、技术设计、架构，随后生成执行计划。规划完成后还应审视计划本身：质疑关键假设，检查安全性、过度设计等问题。

2. 执行（Execution） 构建、测试、验证，关键在于把握智能体自主性与人工监督之间的平衡。一是让智能体以"校准过的自主程度"去构建；二是通过自动化和/或人工检查来验证输出。

3. 部署与监控（Deployment and monitoring） 部署可能经由 CI/CD 流水线或额外的人工关卡把关；随后用智能体观察日志、发现问题、提出并执行改进。

这个工作流有两个特别注意：
1. 它与前智能体时代的软件开发流程本质相似。真正变化的是注意力的重心：从写代码转移到决定做什么、设计架构、写 spec、验证输出。
2. 各步骤的时长弹性极大，可以省略。greenfield（从零开始）原型的 spec 可能只是一条快速写下的提示词；而有大量用户的 brownfield（存量）项目的 spec 则需要投入大量精力去撰写和验证。整个流程高度迭代，熟练的开发者知道何时该从后面的步骤退回前面：验证失败就引导智能体重建修复；监控发现问题就让智能体更新系统并重新部署。

# 五项关键技能

1. 指挥工作流（Directing the workflow）
知道如何走完上述每一步，并决定每一步投入多少人力、多少智能体算力，以及何时回退迭代。这背后是对速度、成本、技术风险、人力投入四者权衡的深刻理解，具体体现在：前期研究和规划做到什么程度、哪些关键工作保留人类所有权、如何选择架构、规划产物（如 spec）写多细、如何把工作拆解成可验证的步骤。

2. 赋予智能体自主性（Enabling agent autonomy）
这一节内容最密集，可拆成四个决策点：
· 自主程度：盯着它交互式往返，还是委托一大块工作？何时设定明确目标让它循环直到成功？
· 上下文管理：构建过程会经历不同阶段，要判断何时把关键经验、用户反馈、假设（包括中途变化的假设）记录下来供智能体下游使用。
· 并行化：何时把任务拆解后让多个智能体并行，由人或更高层的智能体来编排；以及如何在多个并发会话之间分配人的注意力。
· 安全运行：设置权限、对高风险动作设关卡，在保持开发速度的同时限制泄露、数据丢失等损害。

3. 审查工作成果（Reviewing the work）
出发点是一个基本事实：智能体的输出是不确定的。我们事先不知道它会想出什么好主意，也不知道它会埋下什么 bug。因此审查和验证是拿到想要结果、并在偏离时纠正的关键环节。

具体手段包括：
· 设计与任务匹配的测试和验证，按需结合行为验证和功能验证。
· 测试用户流程，可让智能体提供截图作为成功或失败的证据。
· 对定性/行为性评估，可使用评估集（eval sets），可能配合 LLM-as-a-judge。
· 决定测试的自动化程度。某些工作流会把测试完全自动化，让智能体能自行检查、自知何时完成。但必须评估这些测试是否真正对应你的目标，不对应就要演进它们。
· 使用智能体代码审查，运行 AI 驱动的安全和架构审计。
· AI 审查不够时，审慎地插入人工审查——主要审查代码行为，较少审查代码本身——同时探索进一步自动化的可能。
· 验证部署，并用智能体把监控和事故管理运营起来。

这里有一个值得注意的判断：人工审查的对象主要是"代码行为"而非"代码"，这反映了注意力重心的转移。

4. 定制智能体及其环境（Customizing the agent and its environment）
目标是让智能体高效获取所需上下文、访问工具、正确高效地构建。具体包括：
· 集成 skills、插件、MCP 服务器，并在不再必要时（如新模型让旧 skill 过时）剪除它们。
· 用 hooks 自动化开发流程中可重复的部分，如触发自动代码审查或 CI/CD。
· 维护常驻上下文（AGENTS.md、CLAUDE.md），记录代码库信息、关键架构假设、代码风格、数据访问模式。
· 跨会话、跨并行智能体保存状态，随时间积累智能体的经验，比如通过运行后复盘记录哪些做法有效、哪些无效。
· 建立一致的约定和结构，让代码库对智能体可导航；定期清理智能体产生的技术债。
· 团队协作时，考虑如何在不同开发者的智能体之间协调上下文。

5. 编码智能体基础原理（Coding agent foundations）
要做好上述所有决策，需要理解智能体的工作机制：如何做代码库搜索/检索、如何管理上下文窗口、不同操作（增加工具调用、MCP 服务器等）如何影响上下文、智能体与子智能体如何交互、智能体是如何通过在 LLM 外包裹 harness 构建出来的。

这种理解让智能体不再是黑箱，帮助你识别典型失败模式：
· 把简单方案过度设计
· 因缺乏显式验证流程而丧失严谨性
· 未达目标就停下
· 可能破坏文件或生产数据的动作

同时也帮助你推断智能体的状态、给出正确的指令或上下文来引导它，并在监控运行时更早发现它偏离轨道、需要介入。

# 对行业叙事的批评

结尾处吴恩达老师有一段针对性很强的观点。他认为社交媒体对如何使用编码智能体的描述往往过度简化。让智能体自主运行数小时、消耗数百万甚至数千万 token 有时确实有用，但目前超长时程任务的实际效用——尤其是相对成本而言——被夸大到超出现实。

他的结论是：最有效的编码智能体使用是一个复杂、高度迭代的过程，能够以高水平判断力适时介入，效果远好于放手长跑。

🔗 View Quoted Tweet

💬13🔄5❤️32👀3452📊20

⚡ Powered by xgo.ing

"Reasoning" 只是行业术语，推理模型不是在像人一样思考。 @sophiamyang & @rasbt 在这场 69m 访谈里拆解了推理模型的工程本质： · RLVR 如何用可验证奖...

meng shao (@shao__meng) — Fri, 11 Sep 2026 01:04:40 GMT

"Reasoning" 只是行业术语，推理模型不是在像人一样思考。

@sophiamyang & @rasbt 在这场 69m 访谈里拆解了推理模型的工程本质：
· RLVR 如何用可验证奖励训练模型
· 蒸馏的伦理边界在哪
· 循环 Transformer 是否真的会隐藏思维链

他们认为：推理模型没有魔法，只有方法。 https://t.co/tTK3govJG0

💬13🔄4❤️14👀3303📊21

⚡ Powered by xgo.ing

Shopify 从「React Native」回归「原生开发」 https://t.co/fS0yyGcfol 2020 年 Shopify all-in React Native Shopify ...

meng shao (@shao__meng) — Fri, 11 Sep 2026 00:46:40 GMT

Shopify 从「React Native」回归「原生开发」
shopify.engineering/shop-app-migra…

2020 年 Shopify all-in React Native
Shopify 一直都是 React Native 生态非常重要的贡献者，他们当年选择 RN 有三个理由：功能只建一次、Web 开发者可参与移动端、不再追赶平台对等。

这个决策在当年的移动端开发中是很常见和合理的，但他们付出的代价是：性能优化更费劲、要维护框架层、要持续跟进依赖更新——当时这笔账算得过来。

2025 年底 AI Coding 的意外发现
2025 年底团队用 LLM 做了一些核心模块的原生重建试验，发现 Agent 可以拿 iOS 实现当参考直接写 Android 版本，并通过共享规格、测试和审查保持两端对齐。

双平台的原生成本没有消失，但被 AI Coding 压到了不再“决定性”的程度，包括时间和人力成本。

# Shopify 对“AI 时代如何写软件”的理解很有深度

1. 选择推倒重来而非渐进迁移。 理由很务实：LLM 特别擅长“以现有实现为参考进行重建”，且能借此甩掉历史包袱。Shop 应用从概念验证到全原生上架只用了 12 周——这个速度本身就是论据的一部分。

2. Helix 系统：解决“AI 重写 = 不可维护的垃圾代码”问题。 他们没有让 Agent 一次性吐出重写，而是把每个屏幕的迁移切成一系列几分钟可审的小检查点，每个检查点必须：用测试证明行为等价、视觉上与运行中的应用匹配、通过两个“对抗性审查者”、人类确认后才提交。审查反馈会被记住，迁移推进过程中循环越来越自主。这本质上是把“人类监督下的渐进式代码生成”做成了产品。

3. 为 Agent 重新设计架构。 他们发现瓶颈不在代码生成（几秒）而在验证（Agent 操作模拟器要几分钟）。解法是把业务逻辑与 UI 彻底解耦，做成可以在桌面无头运行的 CLI，让 Agent 以毫秒级迭代，还能自主工作数小时。“架构同时服务人类和 Agent”——这句话可能是全文最长远的信号。

Shopify 是 React Native 生态的重要贡献者，退出安排得比较体面，但影响是实打实的：
· FlashList（周下载约 200 万，RN 高性能列表的事实标准）正在寻找新托管方；
· React Native Skia 由作者 William Candillon fork 后以新名称延续，Shopify 赞助到 2026 年底；
· Restyle 将归档，维护至 2026 年底。

Mustafa Ali@mustafa01ali

x.com/i/article/2098…

🔗 View Quoted Tweet

💬4🔄0❤️6👀2373📊5

⚡ Powered by xgo.ing

SWE-bench 等公开基准被“刷爆”，Cursor 更新发布私有基准 CursorBench 4.0 · Claude Fable 5.1、Opus 5 贵但确实最强 · GPT-6 Astra...

meng shao (@shao__meng) — Fri, 11 Sep 2026 00:13:31 GMT

SWE-bench 等公开基准被“刷爆”，Cursor 更新发布私有基准 CursorBench 4.0

· Claude Fable 5.1、Opus 5 贵但确实最强
· GPT-6 Astra 不参与评测（原因你懂）
· Grok 4.6 表现不突出，和 Muse Spark 1.3 相比优势不大，且更贵
· Lee 表示 Grok 4.7 会有很大提升

cursor.com/cn/cursorbench

再看看 CursorBench 方法论：从真实会话中“反向出题”
核心机制是 Cursor Blame：将已提交的代码追溯回生成它的智能体请求，天然形成“开发者查询—标准答案”配对。配套设计包括：
· 防泄漏：大量任务来自内部代码库和受控来源，且每隔数月整体更换题库；
· 任务更重：从初版到 3.0，任务规模（代码行数、涉及文件数）约翻倍，明显大于 SWE-bench 各变体，并引入 monorepo 多工作区、排查生产日志、长时实验等难题；
· 刻意保留歧义：任务描述保持简短、信息不充分，模拟开发者真实的表达方式，而非为方便评分而人为消除不确定性。

评测理念：线上-线下双闭环
CursorBench（线下）衡量正确性、代码质量、效率、交互行为多个维度；线上评估则在真实流量上做受控实验，专门捕捉“离线得分高、但开发者实际体验更差”的回归，这类问题是纯离线评测的盲区。

Cursor 给了一个消融实验案例：完全移除语义搜索工具后，才准确定位其价值集中在大型代码库的仓库级问答场景。

Lee Robinson@leerob

We just rolled out CursorBench 4.0!

It includes new tasks for how well models follow instructions, work on challenging projects over time, and is more difficult than before (so all models score lower).

🔗 View Quoted Tweet

💬4🔄2❤️10👀29271📊6

⚡ Powered by xgo.ing

How to Build Great Evals Meta AI 高级总监 @realmadhuguru 连载的一套面向 AI Agent 产品团队的评测工程实践方法论，10 篇内容形成一个 Age...

meng shao (@shao__meng) — Thu, 10 Sep 2026 23:57:26 GMT

How to Build Great Evals

Meta AI 高级总监 @realmadhuguru 连载的一套面向 AI Agent 产品团队的评测工程实践方法论，10 篇内容形成一个 Agent Eval 完整操作路径：

入门与基础 (Part 1–3) 
→ 策略与组织 (Part 4–5) 
→ 迭代方法 (Part 6–8) 
→ 长期演进 (Part 9–10) x.com/i/article/2098…

💬12🔄12❤️67👀5942📊45

⚡ Powered by xgo.ing

A 社发布迄今最详细的威胁情报报告 154 页原始报告中，“中国” 出现了 100+ 次，中国 AI 团队 “非法蒸馏” 再次被重点 “投诉” 😂 展开 “非法蒸馏” 之前，A 社也为自己模型安...

meng shao (@shao__meng) — Thu, 10 Sep 2026 23:18:53 GMT

A 社发布迄今最详细的威胁情报报告

154 页原始报告中，“中国” 出现了 100+ 次，中国 AI 团队 “非法蒸馏” 再次被重点 “投诉” 😂

展开 “非法蒸馏” 之前，A 社也为自己模型安全再次叫卖：
被滥用的模型为 Haiku / Sonnet / Opus；报告特别指出，新一代模型（Fable、Mythos 系列）除一起蒸馏事件外未被成功滥用，并将此归功于更强的安全防护 ？！anthropic.com/threat-intelli…c

# Qwen：史上最大规模，且不止于蒸馏

累计 1.5 亿次、峰值每天近 300 万次交互、3500+ 欺诈账户。目标是 Opus 4.6/4.7 的思维链，聚焦智能体任务、软件工程、内核开发、长程任务，产物直接用于训练 Qwen 3.5/3.6/3.7。

更值得注意的是第二个层面：阿里还用 Claude 做自家 AI 研发——强化学习环境和模型架构研究。

账户组织上，阿里维护了两个账户池（近 5000 个账户，住宅代理+一次性邮箱+虚拟卡）；第一个池被封禁后迅速切换到第二个池，而该池同时也在为 DeepSeek 和小米输送流量——三家共用同一批代理网络基础设施。

# 月之暗面与 DeepSeek：最惊人的指控——“用 Claude 冒充自家模型”

这两家的手法在报告中最为震撼：用户以为自己在使用 Kimi 或 DeepSeek，实际响应来自 Claude Opus，而公司同时保存这些交互用作训练数据。
· 月之暗面：10天内转发近 30 万次用户请求，5380 个欺诈账户（多位于新加坡和日本）；还攻破了 Anthropic 的“思维签名”防护——保存 Claude 返回的签名引用，新开一个会话诱导 Claude 把签名还原成完整推理痕迹（跨会话重放攻击）。
· DeepSeek：更精细，检测请求中的特征字符串，专门标记使用 Claude Code、Agent SDK、OpenCode 等编码框架的用户，被标记者的请求转发给 Opus。这实际是在筛选高质量编码流量来收割。

被转发的用户数据本身就构成隐私事件。报告点名了三类：
· 一名疑与 jfj 相关的用户提交了成都数百个摄像头（含 PLA 设施、中国电科所属研究院外）对某特定个人的监控分析请求；
· 某国企工程师在 Kimi 中暴露多家知名科技公司内部代码和实时凭据；
· DeepSeek 侧则包括某 PRC 科技公司旗舰 AI 项目的完整规格与组织架构、俄罗斯国防部关联机构的数据库实时凭据、某市公安局面向公民身份证号的轨迹比对系统。

# 智谱：工程化最深，且直接冲着网络攻击能力来

智谱的独特之处是把 Claude 用作训练流水线的自我改进工具：10天内轮换 273 个账户，77 万次交互专门用于“清洗”推理痕迹，另有 300 万次用于评分、过滤训练数据、编写任务和测试。

最关键的是 GLM 5.3 发布前的行动：智谱用公开漏洞库搭建 CTF 题目，对另一家美国头部实验室的旗舰模型发起蒸馏攻击，同时用 Claude Opus 4.6 来给对方模型的回答评分。它先尝试攻击 Anthropic 的 Fable 模型，因其网络安全防护太强而放弃——报告称观察到智谱员工明确因为评估 Opus 和另一家美国实验室的防护更弱而转向。

# 小米：免费试用作为收割策略

报告的推断相当尖锐：MiMo-V2-Pro 的免费试用期（后被延长）可能有意吸引国际开发者使用，以便将其会话作为蒸馏素材——对 Claude 的大规模蒸馏恰好在试用期结束时开始。40 万次请求中包含十几种语言、数百名用户的姓名、联系方式和企业数据。

Anthropic@AnthropicAI

We're publishing our most detailed threat intelligence report to date. 

It covers how people tried to misuse Claude—for cyberattacks, influence operations, surveillance, biology, and building weapons—and how we found and stopped them.

We disrupted every operation in the report, and used the lessons from them to strengthen our safeguards. Where appropriate, we also shared what we found with authorities and other AI companies.

These cases are not typical: we’re highlighting some of the most sophisticated misuse we’ve seen. But they’re especially important to discuss, because they show us where AI misuse is headed, where our safeguards work, and where they need to improve.

We’re publishing this report so others can spot the same activity on their own platforms, and so we can give the public a clearer view of how emerging threats develop.

Read the report: anthropic.com/threat-intelli…

🔗 View Quoted Tweet

💬35🔄16❤️103👀238484📊63

⚡ Powered by xgo.ing

作为一名 iOS 开发者（1天经验），我强烈要求 Apple 官方能发布一则声明：明确说明，针对 iPhone Duo 的适配，不能完全通过模拟器完成，必须真机调试！感谢！这样，我就有不...

meng shao (@shao__meng) — Thu, 10 Sep 2026 13:09:41 GMT

作为一名 iOS 开发者（1天经验），我强烈要求  Apple 官方能发布一则声明：

明确说明，针对 iPhone Duo 的适配，不能完全通过模拟器完成，必须真机调试！

感谢！

这样，我就有不可拒绝的理由，拥有一台 iPhone Duo ...

然后由我老婆持有，我顺利继承她的 iPhone 17 Pro 😂

💬0🔄0❤️0👀390

⚡ Powered by xgo.ing

最近分享的 5 门来自 Stanford、CMU 和 MIT 三所大学的 AI 课程，我再整合分享一次，视频内容很多，可以先收藏慢慢学习 🔖 1. 斯坦福大学 CS329A Self-Impro...

meng shao (@shao__meng) — Thu, 10 Sep 2026 12:08:07 GMT

最近分享的 5 门来自 Stanford、CMU 和 MIT 三所大学的 AI 课程，我再整合分享一次，视频内容很多，可以先收藏慢慢学习  🔖

1. 斯坦福大学 CS329A Self-Improving AI Agents
人定义意图、Agent 执行的新软件工程x.com/shao__meng/sta…T

2. 斯坦福大学 CS 329Z: Engineering AI Agents
从模型到系统：流水线 → 复合 AI → 自主 Agentx.com/shao__meng/sta…b

3. 斯坦福大学 CS146S: The Modern Software Developer
人定义意图、Agent 执行的新软件工程x.com/shao__meng/sta…V

4. MIT 多模态 AI 课程 2026 版
YouTube 全集上线，融合对齐 → 推理智能体x.com/shao__meng/sta…0

5. CMU 秋季新课 AI Agents
OpenHands 作者亲授，从零搭 Harness、建评测、用 RL 训智能体，讲义视频已公开x.com/shao__meng/sta…N

meng shao@shao__meng

CS329A Self-Improving AI Agents

斯坦福大学一门关于「能够通过与自身和环境的交互持续自我改进的 AI Agents」的课程。

讲师阵容
Azalia Mirhoseini：AlphaCode 与 LLM 大规模训练调度优化（"Circuit Training"）的核心人物，现为 Reflection AI 联合创始人
Aakanksha Chowdhery：PaLM 2 与 Gemma 的负责人，同样在 Reflection AI

嘉宾名单
Misha Laskin（Reflection AI CEO）
多位 Google DeepMind 研究员（Denny Zhou、Thang Luong、Melvin Johnson）、Physical Intelligence（Danny Driess，机器人）

课程主线：一条完整的自我改进技术栈
1. 推理时自我改进（Test-time）
2. 从反馈中学习（Feedback → Learning）
3. 开放式进化与搜索（Open-endedness）
4. 工程化与瓶颈（Agentic Engineering & Bottlenecks）

课程详细信息：
cs329a.stanford.edu/index.html

🔗 View Quoted Tweet

💬57🔄141❤️492👀33173📊251

⚡ Powered by xgo.ing

平时写产品技术文档，经常要做架构/流程/时序图之类 Diagram，Mermaid 默认也能做不过美观度确实一般，找了几个 Diagram Skills，分享给需要的朋友们。 1. Diagram ...

meng shao (@shao__meng) — Thu, 10 Sep 2026 02:41:36 GMT

平时写产品技术文档，经常要做架构/流程/时序图之类 Diagram，Mermaid 默认也能做不过美观度确实一般，找了几个 Diagram Skills，分享给需要的朋友们。

1. Diagram Design 36.7K 🌟 @cathrynlavery 
编辑向图解 Skill，约 39 种类型，自包含 HTML+SVG；可品牌化配色，支持从 draw. io / Mermaid / Excalidraw 重绘。做演示、文章配图优先装这个。github.com/cathrynlavery/…X

2. Archify 56.2K 🌟
可校验系统图 Skill；typed JSON IR → 架构/工作流/时序/数据流/生命周期交互 HTML，支持 Before/After 对比与导出github.com/tt-a1i/archifyP5

3. Fireworks Tech Graph 11.3K 🌟 @teach_fireworks 
自然语言出技术图；几何校验 SVG+PNG，可选语义 GIF；12 风格、完整 UML，内置 RAG/Multi-Agent 等模github.com/yizhiyanhua-ai…pY8

4. Excalidraw Diagram Skill 4.7K 🌟 @cole_medin  
生成可编辑 Excalidraw 图；强调「视觉论证」与渲染自检，适合白板协作后再github.com/coleam00/excal…KARr

5. Visual Explainer 9.7K 🌟 @nicopreme
把架构图、diff 评审、计划审计、表格等做成整页 HTML 或杂志风幻灯，偏「一页讲github.com/nicobailon/vis…2acbZ

💬56🔄41❤️171👀10766📊134

⚡ Powered by xgo.ing

Frontier Engineering 的十条工作原则：人定方向，Agent 执行当 AI Coding Agents 可以自主写代码、跑测试、修 bug、连续数小时不需要人介入时，开发者的工作...

meng shao (@shao__meng) — Thu, 10 Sep 2026 01:56:03 GMT

Frontier Engineering 的十条工作原则：人定方向，Agent 执行

当 AI Coding Agents 可以自主写代码、跑测试、修 bug、连续数小时不需要人介入时，开发者的工作方式应该怎样彻底改变？

@kirodotdev 团队 @clare_liguori 把这种变化方向叫做 「Frontier Engineering」，反复强调它不是 vibe coding。并给出了 Frontier Engineering 的十条工作原则。
kiro.dev/topics/frontie…

1. 你是架构师，不是打字员
这是整个体系的世界观基础。给出一个惊人的数字：前沿开发者手写的代码占其产出总量的不到 1%，其余全部来自他们“指导、引导和审查”的 Agent。

工作因此压缩成两件事：定义“完成”是什么（需求、约束、验收标准），以及验证产出是否符合意图。

2. 最大化 Agent 时间，最小化你的介入
这条批评的是大多数人的现状：发一条提示 → 等 60 秒 → 拿回代码 → 手动测试 → 把报错贴回聊天窗。这种“贴身循环”永远快不起来。

正确做法是给 Agent 内置验证步骤的长任务，例如：“实现这个功能，写测试，跑测试，确保通过，新代码达到 90% 测试覆盖率”——让 Agent 持续工作 30 分钟以上并自我纠错收敛，你去干别的。

进阶形态是：多个 Agent 并行、异步审查产出、让 Agent 跑通宵、让 Agent 启动其他 Agent。此时瓶颈不再是打字速度，在于你同时能让多少个 Agent 保持有意义的工作状态。终点是把自己从循环中移除，只保留“设定方向 + 验证结果”。

3. 为 Agent 构建你的代码库
关键洞察是 ROI 的变化：人类新成员只需入职一次，而 Agent 每次会话都要重新“入职”一遍。

因此文档、规范这些投入的回报率被放大了无数倍，包括：
· 基础工程卫生：README 与架构文档、描述预期行为的测试、清晰的模块边界、强类型、快速构建与信息丰富的报错
· 显式上下文四件套：steering files（规范）、skills（按需加载的操作流程）、scripts（自动化环境搭建）、CLI 工具与 MCP 服务器（获取上下文、执行操作）
· 面对遗留大库：一次只准备一个模块，把 Agent 的工作范围限定在已准备好的模块内
· 让 Agent 留下推理过程——记录设计决策、大量写注释，让下一个会话继承的不仅是代码，还有代码背后的“为什么”

4. 给 Agent 快速反馈回路
一句话点破瓶颈：“如果你的 Agent 不能在本地跑测试并在你看代码之前自我修正，你自己就成了瓶颈。”凡是你在验证自己工作时会用的工具，Agent 也应该能用：linter、单元测试、浏览器（视觉验证 UI）、依赖服务的本地 mock、在笔记本上起完整技术栈的能力。

特别推崇属性测试：它验证的是“实现是否符合意图”，且能捕捉 Agent 自己想不到要写显式用例的边界情况。这段有一个很实在的对比：不投入的话，更快的代码生成只会带来更多坏构建和 bug；投入了的话，代码库质量反而会提升——因为 Agent 验证代码比很多人类更彻底、更一致。

5. 执行廉价，方向决定一切
当代码一个下午就能写完，实现本身不再是难题，难题变成：该解决什么问题、该构建什么产品、何时调整方向。成本结构发生了倒挂：实现细节改起来很便宜，而系统设计、API 契约、依赖关系、架构取舍这些“持久性决策”改动代价高昂——精力应该花在这里。

两个具体实践：把 Agent 当头脑风暴伙伴（调研方案、探索替代路径、挑你思路的漏洞，两个方案都拿不准就让 Agent 各做一个原型用实证代替争论）；以及规格驱动开发 (SDD)，在生成代码之前先写清规格。

给 Agent 含糊的提示，它就会替你做各种取舍，而你之后推翻这些决定所花的时间，会超过当初省下不写规格的时间。

6. 把代码视为可丢弃的
这是心态上最激进的一条。既然代码生成成本趋近于零，就应该持续评估“这东西值不值得发布、值不值得长期维护”——可以一天做个原型直接扔掉，可以花两周做到接近生产级后发现方向不对就推倒重来。过去舍不得扔代码的两个理由（感情上的沉没成本、重写要几个月）如今都不成立了。

但有一个重要例外：位于系统边界的测试必须保留——端到端集成测试（验证行为）、属性测试（验证不变量）、负载测试（验证大规模性能）。这三类测试构成一份“契约”，任何重写版本都必须满足它。这是让“从头再来”变得安全的先决条件。

7. 以人类标准要求 AI 产出
责任归属清晰：凡是署你之名上线的代码，无论谁写的，你都要负责。路径是渐进的：早期逐行审查 Agent 产出，建立对模型能力边界的直觉；规模化后构建 AI 审查器（检查正确性、安全性、可维护性、测试质量、常见 bug 模式），pre-PR 本地跑一遍、CI 再跑一遍，逐渐放手让它处理前几轮反馈；人类注意力集中在最擅长的判断上——架构是否正确、变更对上下游系统的影响、安全边界是否健全。

这条的结尾很有分量：“对结果负责意味着要伴随这项变更一直到生产环境，而不是在 pull request 处就停下来”——让 Agent 监控部署、验证生产行为、发现回归就自动着手修复。

8. 信任边界，而非 Agent
这是关于安全的第四条。要让 Agent 长时间自主运行，前提是有一套不依赖人盯着看的护栏。

明确否定了两个极端：放任 Agent 乱跑，或每次工具调用都手动点“接受”——那是个虚假两难。正确做法：
· 最小权限：只让 Agent 访问真正需要的文件、工具、网络、凭证，从窄权限起步，随信任建立逐步放宽，最终人工只把关“无法撤销的操作”
· 红线：Agent 绝不应访问生产账号或部署凭证，除非明确且审慎地授予
· 确定性检查层：SAST（安全漏洞）、凭证扫描（泄漏密钥）、自动化推理（数学方式验证产出是否符合意图）

“你每自动化一道护栏，就少一个必须留在监督循环中的理由。”注意这个精妙的换位：信任的对象从 Agent 本身转移到了边界体系。

9. Agent 不只用于代码
同样的模式（提供上下文、定义期望结果、让 Agent 起草、审查打磨）推广到一切：一周的设计文档变一个下午，数小时的运维调查变几分钟，状态更新、冲刺总结、值班报告、文档都适用。关键主张是一致性：流水线 Agent、值班 Agent、文档 Agent 应共享同一套 steering files 和工具——“清晰的意图、快速的反馈回路、受限的访问”这三原则对所有 Agent 一视同仁。

10. 持续调优你的 Agent 配置
收束全篇的元原则，提出了一个“新日常习惯”：每当 Agent 走错方向或把你拉回流程，就问“怎样防止这种情况再次发生？”答案可能是加一条 steering 规则、创建一个 skill 固化之前做错的流程、写个工具自动化手动步骤、搭个 MCP 服务器收集上下文，甚至是放宽一条被证明过严的权限限制。每一次失误都是扩大 Agent 自主权的机会。

由此产生复利：从“需要明确提示才动、频繁要人输入”的 Agent，演进为能在后台自主发现并修 bug、清理技术债的 Agent。还有一层时间维度：新模型发布时要重新审视——为旧模型弱点搭的变通方案还有必要吗？steering files 和工具是“活的产物”，要随模型一起演进。

十条原则之间的结构
· 角色 - 1、2、5
人不再是执行者，而是方向和调度
· 系统 - 3、4、10
代码库、反馈环、工具链要让 agent 能独立闭环
· 质量与风险 - 6、7、8
实现可弃，契约和边界不可弃；对人负责，对模型不盲信
· 范围 - 9
同一套方法覆盖整个研发生命周期

少任何一层都不行。只有角色、没有反馈环，就是远程指挥一个看不见对错的实习生。只有速度、没有边界，就是把生产事故的频率一起放大。只有文档、没有持续调优，steering 会迅速过期，agent 会反复犯同一类错。

Clare Liguori@clare_liguori

I just published a manifesto for all the developers out there who use an AI coding tool, but feel like they're not shipping much faster

I wrote 10 principles for changing how you build software with AI, based on what I've seen work for teams across Amazon
kiro.dev/topics/frontie…

🔗 View Quoted Tweet

💬26🔄7❤️33👀4877📊33

⚡ Powered by xgo.ing

在 OpenAI，新人提问常被反问：“你问过 Codex 了吗？” The Pragmatic Engineer 深度对话 Codex 团队 Tibo Sottiaux，亲述 Codex 的内幕： ...

meng shao (@shao__meng) — Thu, 10 Sep 2026 00:28:55 GMT

在 OpenAI，新人提问常被反问：“你问过 Codex 了吗？”

The Pragmatic Engineer 深度对话 Codex 团队 Tibo Sottiaux，亲述 Codex 的内幕：

Codex 是如何建成的？
为什么选择开源？
为什么与 ChatGPT 合并？
为什么允许接入竞争对手的模型？
... x.com/i/article/2097…

💬22🔄3❤️16👀6085📊33

⚡ Powered by xgo.ing

从像素点击到 Code Mode：Browserbase 对 Computer Use 三年演进路线的完整复盘 @browserbase 团队 @kylejeong @miguel_gonzf 联合...

meng shao (@shao__meng) — Thu, 10 Sep 2026 00:02:12 GMT

从像素点击到 Code Mode：Browserbase 对 Computer Use 三年演进路线的完整复盘

@browserbase 团队 @kylejeong@miguel_gonzf 联合 @LangChain 团队 @sydneyrunkle@huntlovell 一起复盘了浏览器 Agent 的三代技术路线，宣布放弃「给模型预设工具」的思路，全面转向「让模型直接写代码控制浏览器」，并给出行业判断：做好 Agent 是 Harness 问题，不是模型研究问题；最好的 Agent 本质上都是换了外衣的 Coding Agent。

# 三代技术路线的演进逻辑

1. 纯视觉 CUA（以 OpenAI Operator 为代表）
方案：视觉模型识别屏幕像素，返回坐标点击
问题：只在特定视口尺寸下训练，窗口一变「Agent 基本失明」；截图看不到不可见组件

2. 视觉 + 文本混合
方案：截图 + DOM/无障碍树快照
问题：基准测试有提升，但长任务迅速撑爆上下文窗口，精度达不到企业生产标准

3. 代码模式
方案：模型直接写代码表达操作意图
问题：团队认为无根本缺陷，成为终局方案

用 Sutton 的「bitter lesson」解释这一演进：每一代新模型出来，他们都发现之前精心设计的护栏式抽象反而成了瓶颈，于是不断做减法、缩小工具表面积。

# 最值得注意的三个工程洞见

1. 承认早期设计是错的。 旧版 Stagehand 提供 Act / Extract / Observe 三个严格工具，出发点是「模型不可信，需要护栏」。团队直言 "we were so wrong"，代码是模型最有效的意图表达方式，模型甚至会写出设计者没想到的组合策略。专用工具输给通用接口。

2. 「Stagehand 不在模型权重里」。 接入 MCP 后 Agent 反而稳定失败，原因很朴素：所有前沿模型都在 Playwright 语法上做过后训练，没人见过 Stagehand。他们试过写教学 skill、强化 system prompt、加护栏，全部失败；后训练专用模型又违背用户「自带模型」的诉求。最终方案是彻底顺从模型：让模型写 Playwright 代码，在发送到浏览器前实时转译为更快的 Stagehand 方法。原则一句话："让模型做它擅长的事，然后让开"。这是对「模型能力分布决定接口设计」的教科书式示范。

3. Demo 与生产的分界是安全边界。 域名白名单、网络层防护、沙箱化 runtime 加策略治理。比喻很直白：没有极好的刹车和防滚架，你不会把赛车开上公共道路。技术上 Stagehand v4 做成 Chrome 扩展，runtime 直接跑在浏览器内，run 工具天然不需要额外沙箱；性能宣称比 Playwright 快 2 倍、省 80% token。MCP server 只保留三个工具：run（执行代码）、snapshot（剪枝后的 DOM + 无障碍树）、screenshot（补充视觉上下文，覆盖 canvas、OS 层内容）。

# 生态卡位与行业判断

与 LangChain Deep Agents（模型无关的通用 Harness，提供上下文自动卸载、子 Agent 委派、规划等编码 Agent 原语）合作：Browserbase 做浏览器 SDK，LangChain 做通用 harness。这本质是一次开源生态的双向借力，文中也提到 Cloudflare 的 @threepointone 与 @KentonVarda 是代码模式思路的早期实践者。

Kyle Jeong@kylejeong

x.com/i/article/2097…

🔗 View Quoted Tweet

💬13🔄6❤️12👀3310📊16

⚡ Powered by xgo.ing

Perplexity 发布了一个面向 Agentic RAG 系统第一阶段检索的大规模基准 Q2D-Web 1.9 亿网页文档、近 7 万条真实智能体改写的查询、每条查询平均约 100 个正例标注；...

meng shao (@shao__meng) — Wed, 09 Sep 2026 23:40:27 GMT

Perplexity 发布了一个面向 Agentic RAG 系统第一阶段检索的大规模基准 Q2D-Web

1.9 亿网页文档、近 7 万条真实智能体改写的查询、每条查询平均约 100 个正例标注；并公布了 13 个主流检索模型的评测结果。

Perplexity 工程博客
perplexity.ai/hub/blog/q2d-w…
Q2D-Web 论文
arxiv.org/abs/2609.08887

# 为什么需要这个基准：三个系统性缺陷

现有检索评测的三个盲区，以往基准最多解决一两个，Q2D-Web 同时扩展了全部三个：
· 语料太小 → 召回虚高。 生产检索面对的是海量“话题相关但缺关键细节”的强干扰文档；缩小语料等于删掉干扰项，指标自然好看。
· 标注太稀 → 好模型被冤枉。 MS MARCO 的人工抽查显示，70% 被检索到但未标注的段落其实相关。稀疏标注会把检索能力强误判为不相关。
· 查询不对 → 评测失真。 现有基准用人类写的查询，而 Agentic RAG 里真正发给检索器的是智能体改写后的查询，措辞和具体性都不同。

对比：最接近的 MS MARCO Web Search 是1 亿文档 / 9 千查询 / 每查询 1 个正例；Q2D-Web 是1.9 亿文档 / 7 万智能体查询 / 每查询平均 99.6 个正例；三个维度同时放大一到两个数量级。

# 基准是怎么构建的？

查询：来自 23000 次经过隐私处理的 Perplexity 生产搜索（9 个月、10 种语言，英语占 65.8%），共 69721 条智能体改写查询。一次“搜索”指智能体为一条用户消息发起的全部搜索工具调用，其中含一条主查询（复述用户需求）和若干支撑查询（换个说法、补背景、查相关实体），每条独立评测。隐私处理包括仅使用授权用户数据、PII 检测过滤，并剔除精确重复、过短、含搜索运算符（site:、引号短语）的查询。

语料：对每个查询取生产系统检索的 top 5,000 文档取并集，经 MinHash–LSH 去重（5-gram Jaccard ≥ 0.975 聚簇），得到约 1.9 亿文档。关键设计：这不是随机网页抽样，每个文档都曾是某条查询的合理候选——刻意保留了“主题匹配但缺少日期/实体/版本/数量等关键要素”的难干扰项。

三套标注集（这是方法论上最讲究的部分，用多套标注互相制衡单一管线的偏差）：
· Citation：智能体回答中实际引用的文档
· Web Ranking：内部 BM25+稠密检索、交叉编码重排后的 top 50
· Combined：前两者并集 + LLM 补判

# 降本工程：子语料采样

全量评测极其昂贵：pplx-embed-v1-4b 一次需 4,608 H200 GPU 小时。他们的解决方案是保留全部正例文档、只对未标注干扰项做采样，比较了随机采样、固定深度池化和按查询 RRF 三种策略。结果是 RRF 采样只用 31.7% 的文档就能保住全量语料上的模型排序，召回率仅虚高 4.5 个百分点（同规模随机采样虚高 11.1 个点），成本降到约三分之一（pplx-embed-v1-4b 降至约 1,500 GPU 小时，EmbeddingGemma-300M 降至 70 以内）。

实际评测流程因此是两级漏斗：所有提交模型先在子语料上评测（按参数量分 ≤1B 和 >1B 两组），只有进入本组前十的模型才获得全量语料评测。

# 评测结果：没有全能冠军

13 个模型、三套标注、两个指标（Recall@1000 为主指标——第一阶段只需把相关文档捞进候选池，排序交给重排器；nDCG@10 为辅）。关键发现：
· Recall@1000：pplx-embed-v1-4b 在 Web Ranking（65.73）和 Combined（69.11）上领先；Nemotron-3-Embed-8B 在 Citation 上领先（61.68）。
· Combined nDCG@10 上排序反转：Nemotron-3-Embed-8B（47.44）反超 pplx-embed-v1-4b（45.84）——Perplexity 自家模型在自己流量来源的基准上并非全面第一。
· 规模效应稳定：同系列内更大模型在 Combined Recall@1000 上一致更高（Qwen3-Embedding 0.6B→8B：57.89→64.53；Nemotron 1B→8B：61.68→68.58；pplx-embed 0.6b→4b：67.02→69.11）。
· 稀疏 BM25（tantivy 实现）的 Recall@1000 只有 44–45，与稠密模型差距明显；但这是 512 token 截断、1.9 亿文档难干扰项下的结果。

Perplexity@perplexity_ai

We're introducing Q2D-Web (Query2Doc-Web), a benchmark and public leaderboard for evaluating retrieval in agentic RAG systems.

Q2D-Web tests how embedding models perform on large-scale web search using agent-reformulated search queries.

Read more: perplexity.ai/hub/blog/q2d-w…

🔗 View Quoted Tweet

💬11🔄10❤️42👀4473📊22

⚡ Powered by xgo.ing

Agent 通过率 67%→86%，模型一个参数没动：丢的分大多在 Harness，不在模型当 Agent 表现不佳时，我们习惯归因于模型能力不足，去换更大的模型。但 @adaption_ai 用...

meng shao (@shao__meng) — Wed, 09 Sep 2026 23:19:12 GMT

Agent 通过率 67%→86%，模型一个参数没动：丢的分大多在 Harness，不在模型

当 Agent 表现不佳时，我们习惯归因于模型能力不足，去换更大的模型。但 @adaption_ai 用实验证明：包围模型的 Harness (工具设计、上下文管理、执行循环、交付校验) 往往才是丢分的真正原因。低分可能意味着能力缺口，也可能只是 Harness 设计失败，而两者的解法完全不同。

实验设计在 Harvey 法律 Agent 基准（LAB）上，每个任务提供合伙风格的指令和沙箱中的用例文档，按条目逐项评分。在 140 个留出任务（与训练集不重叠）上量化了 Harness 的影响，有这几点关键发现。
adaptionlabs.ai/blog/a-better-…

1. 仅改 Harness 就大幅提升成绩（不动模型权重）
Qwen3.6-27B 通过率从 67.10% 提升到 85.92%，随后训练又推到 88.03%，接近前沿模型水平。团队对两种增益来源做了精确区分——“Harness 恢复的是基座模型已具备但被埋没的能力，而后训练增加的是模型原本不具备的能力。”

轨迹分析揭示了丢分根源：跑完却没有可用文件、工具调用格式错误导致死循环、读取大文件后指令丢失。

针对性改进包括：有界的文件读取、可操作的工具报错、上下文压缩时的状态保留、退出前校验交付物。其中因路径缺失导致的写入失败从 120 次降到 0。

2. 跨模型泛化
同一 Harness 用在 GLM-5.2 上从 88.39% 升至 90.64%；Gemini 3.6 Flash 和 Claude Opus 4.8 的小规模评测也有增益（但任务子集较窄，结果仅具方向性参考）。

3. Token 效率：更准且更省
与 Prime Agent 0.7.1 和 OpenCode 1.18.23 对比（固定模型）：
· Qwen：84.13%（8.06M tokens）vs. 84.92%（17.48M）vs. 75.40%（6.38M）
· GLM：92.06% vs. 落后 3.96 分，且多耗 18% tokens vs. 落后 5.16 分
Qwen 场景下以少 54% 的输入 token 达到与 Prime Agent 相差不到 0.8 分的成绩。结论是 token 数量本身不解释性能——harness 决定了模型使用上下文的生产率。用优化后的小模型替代前沿模型，成本可降低 10 倍以上。

4. Harness 优化反哺后训练
执行失败被清除后，剩余错误才真实反映模型的能力边界。基于成功端到端轨迹做后训练，全条目通过的任务占比从 5.67% 升至 9.22%。

团队认为：“可靠的 Harness 能产出更干净的证据（模型到底还不会什么）和更好的学习轨迹。” 也就是说，先修 Harness，后训练的数据质量才可信。

Sudip Roy@sudip_r0y

Agent performance is often attributed primarily to the underlying model.

Our research suggests the harness recovers what a model can already do, but it can't create capability the model doesn't have.

@dhruvrnaik  and I saw this with Qwen3.6-27B on the @harvey Legal Agent Benchmark. Harness optimization alone moved pass rate from 67% to 85%. Adding post-training pushed it to 88%.

🔗 View Quoted Tweet

💬6🔄1❤️11👀3507📊9

⚡ Powered by xgo.ing

当文档的主要读者变成 AI Agent，文档抽取产品被推倒重做：LandingAI ADE Gen2 正式发布吴恩达老师 @AndrewYNg 创办的 @LandingAI 正式发布 ADE Ge...

meng shao (@shao__meng) — Wed, 09 Sep 2026 23:01:21 GMT

当文档的主要读者变成 AI Agent，文档抽取产品被推倒重做：LandingAI ADE Gen2 正式发布

吴恩达老师 @AndrewYNg 创办的 @LandingAI 正式发布 ADE Gen2，底层换用新一代 DPT-3 模型家族，核心是 "AI Agent 能不能以低成本、可审计地大规模读文档"，Gen2 在定价模型、输出结构和溯源粒度三个层面都被推倒重做了。

1. 可负担性：从 "按页计费" 到 "按复杂度计费"
Gen1 按页固定收费（每页 3 credits），Gen2 改为 Parse 按返回字符数计费——文档越简单，费用越低。配合异步的 Standard 层（0.5x 价格系数），官方给出混合负载 25%–80% 成本下降的预期，解析可低至每页不到 1 美分。

Gen2 还引入了双模型分层：
· DPT-3 Verity（公开预览）：面向数字原生文档（PDF 内嵌文本、简单表格表单），消耗 credits 约为 DPT-2 的 10%–20%（官方称节省 80%–90%），提供逐词置信度和 bounding box。名字取"verity"（真实），强调忠实转写而非生成。
· DPT-3 Pro：完整版，先理解版面再按阅读顺序输出，处理扫描件、手写、非拉丁文字、数学公式，并生成式描述图表。注意，模型生成的内容会被 <description> 标签明确隔离在转写文本之外——这是防幻觉的关键设计。
· 智能路由（自动选择模型）预计 2026 年秋上线。

2. Agent-Ready 输出：从 "给人读" 到 "给 Agent 读"
v2 Parse / Extract API 是破坏性变更，旧代码不兼容。核心重构点：
· Blocks 取代 chunks：输出遵循 页 → block → 行/表格单元格 的层级，每个 block 有稳定 ID 和 Markdown span 指针，新增顶层 structure 对象（含页码、字符区间、坐标框）。
· 标准化 Markdown：图片用标准语法并带类型标签（Chart/Diagram/Photo）；签名统一为 Signed / Not Signed；复选框统一为 [X] / []（含表格内）；表格默认输出 HTML 以保结构（Markdown 可选）。
· 输出更紧凑——这同时服务于 Agent 的解析效率和成本（因为计费与字符数挂钩，设计上形成了闭环）。

3. 原子级溯源（Atomic Grounding）
这是对监管和高可信场景最有价值的能力：
· DPT-3 Pro：行级溯源；DPT-3 Verity：词级溯源，均带 span 指针和坐标框，Verity 还附加逐词置信度。推文所说的 word-level grounding 精确来说是 Verity 的能力。
· Extract V2 的每个抽取值都能定位到具体页面的具体词，表格单元格也有独立标识符和坐标。
· 由此解锁的场景：PII/PHI 精确到词的合规脱敏、带高亮定位的文档版本比对、人工审核 UI 与原位编辑。

LandingAI@LandingAI

Today, we are announcing the second generation of Agentic Document Extraction (ADE).

It is faster, more accurate, and more affordable than ever before. ADE Gen2 delivers higher performance while optimizing cost for every document.

Pricing has been completely overhauled. Customers running mixed workloads should see 25% to 80% cost reductions.

Groundings and citations now reach the word level following a page > block> line > word hierarchy. This allows every extracted value to point to the exact location on the page it came from.

The outputs from the v2 Parse and Extract APIs are fully agent-ready and agent-friendly. Your agents get a clear hierarchy, stable IDs, and clean, standardized Markdown designed just for them.

ADE Gen2 is a step change in document intelligence not an incremental update.

Read the full announcement on the blog (link in comments).

Create an account and get started for free at ade.landing.ai

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬32🔄3❤️6👀1909📊28

⚡ Powered by xgo.ing

4 周原型、3 周上线、一个月数百万 Bot：Grok Bot 操盘手的深度复盘一支从大公司里隔离出来的小团队，用 4 周写出原型、3 周内测、再 3 周后面向全球发布，产品上线不到一个月已有数百...

meng shao (@shao__meng) — Wed, 09 Sep 2026 15:11:00 GMT

4 周原型、3 周上线、一个月数百万 Bot：Grok Bot 操盘手的深度复盘

一支从大公司里隔离出来的小团队，用 4 周写出原型、3 周内测、再 3 周后面向全球发布，产品上线不到一个月已有数百万个 Bot 在为用户干活。

Lenny's Podcast × Roman Ugarte 在 80 多分钟深度访谈中，讲清了这套打法背后的每一个关键决策。

Grok Bot 构建过程的五个核心话题
1. 为什么从零开始，而不是放进 Cursor？
2. 两个“当时不觉得显然”的关键赌注：一切皆云端、每个 Bot 有自己的一台电脑
3. 两周内手动 Onboarding 前两三百名用户
4. 发布前的几周在干嘛？
5. 「Colleague-pilled」产品哲学

用户最实用的一条：第一个 Prompt 该试什么？

meng shao@shao__meng

4 周写出原型，3 周后推向全球，如今数百万个 Bot 正替人干活

Grok Bot 操盘手 Roman Ugarte 首次公开全部决策内幕：
为什么不塞进 Cursor ？
为什么每个 Bot 要有自己的电脑 ？
从 90% 到 100% 是两种产品
到手动拉新 300 人的笨办法 x.com/i/article/2097…

🔗 View Quoted Tweet

💬5🔄3❤️11👀2352📊8

⚡ Powered by xgo.ing

2030 年 GDP 涨 32%、劳动收入却一分不多：Anthropic 用主流经济学模型推演 AI 的三种经济未来 Anthropic 建一个统一的任务型宏观模型，把对 AI 的所有分歧压缩为少数...

meng shao (@shao__meng) — Wed, 09 Sep 2026 14:08:54 GMT

2030 年 GDP 涨 32%、劳动收入却一分不多：Anthropic 用主流经济学模型推演 AI 的三种经济未来

Anthropic 建一个统一的任务型宏观模型，把对 AI 的所有分歧压缩为少数几个可测量、可争论的参数，然后把参数代入，推导出 2026–2030 年的 GDP、工资、劳动份额与失业率路径，每类数据都分为温和、显著和极端三种。

# 4 项关键数据

GDP：三个情景下 2030 年分别比无 AI 基线高 1.6% / 8.3% / 32.4%——极端情景年增速达 15.4%，人均收入每 5 年翻一番（过去百年美国是每 35 年）

劳动份额从 60% 跌至 45%（极端情景）：GDP 涨了三分之一，总劳动收入却几乎不变——全部增量都归了资本（资本收入高出基线 81%）

认知职业（占美国就业 62%）受冲击最重：极端情景下认知工资下降 11.5%，认知劳动者失业率 17.9%（超过美国战后任何时期），全体失业率 11.9%

工资分化剧烈：极端情景下认知职业工资 −11.5%，而 AI 触及不到的体力/人际职业工资 +33.6%——电工和护士成了稀缺资源

更多详细数据报告：
anthropic.com/institute/econ…

Anthropic@AnthropicAI

Anthropic’s Economics team is sharing a new model of how AI might affect economic growth, jobs, wages, and more by 2030.

Explore the scenarios, tell us what you think will happen, and see how your answers compare to more than 10,000 Americans. anthropic.com/institute/econ…

🔗 View Quoted Tweet

💬17🔄5❤️21👀5834📊20

⚡ Powered by xgo.ing

Vercel 团队 @shuding 发布了一个在浏览器里做语法高亮的小型神经网络模型「gpu-lexer」，只有 27.5KB，推理跑在 WebGPU 上：https://t.co/sUDpIhIr...

meng shao (@shao__meng) — Wed, 09 Sep 2026 09:44:04 GMT

Vercel 团队 @shuding 发布了一个在浏览器里做语法高亮的小型神经网络模型「gpu-lexer」，只有 27.5KB，推理跑在 WebGPU 上：gpu-lexer.vercel.app

Shu 发现多年来在语法高亮上的真实痛点：
1. 语法语料包太大。传统方案（如 Shiki、TextMate grammar 体系）每种语言都要带一份完整的 grammar 定义，几十种语言叠加后体积很容易到 MB 级；
2. 语言检测与动态加载麻烦。渲染一段未知语言的代码，得先检测语言、再去异步拉取对应的 grammar bundle，链路又长又复杂；
3. 性能差、阻塞主线程。传统的 tokenizer 在 CPU 上跑，代码量大时会卡住页面主线程。

gpu-lexer 用一个思路同时回应了这三点：把高亮从“基于规则”改成“基于模型”。一个 27.5KB 的模型内联打包，天然消灭了动态加载问题；跑在 GPU 上，天然绕开了主线程阻塞。这是典型的“用一次性的模型训练成本，换取运行时的体积和延迟优势”。

技术上的关键点
本质上是一个序列标注任务：模型读入源代码的 token 序列，为每个 token 预测它的语法角色（关键字、字符串、注释、函数名等），再映射到高亮的 span 上。

几个值得注意的细节：
· 50+ 语言训练，且有泛化能力。帖子特意提到对训练集之外的语言“表现尚可”——这说明模型学到的不只是各语言的特例，而是某种跨语言的语法模式共性（比如大多数语言里 // 后面是注释、引号包裹的是字符串这类统计规律）。这是神经方法相对规则引擎最有想象力的地方。
· 正确性以 Shiki 为基准衡量。Shiki 使用真实的 VS Code 语法语料，gpu-lexer 用“top 25 GitHub 流行语言的加权正确率”来对比。帖子也诚实指出了方法论差异：Shiki 解析的是真实 AST，而其他高亮器（包括 gpu-lexer）可能只是近似，所以差距是结构性的。
· 不能全量替代。Shu 明确说“所有高亮器有不同的管线和使用场景”，这个项目目前无法完整替代任何一个。这是很克制、很专业的表述——神经高亮在确定性、边角 case、语义级区分（比如区分“用作函数调用的标识符”和“普通变量”）上仍有天然短板。

Shu@shuding

I trained a small model to do syntax highlighting in the browser with GPU.

Meet gpu-lexer from Vercel Labs: Small (27.5KB), fast (runs on WebGPU), and language-agnostic (model guesses the syntax).

gpu-lexer.vercel.app

It is experimental and built for learning!

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬19🔄13❤️65👀7239📊36

⚡ Powered by xgo.ing

4 周写出原型，3 周后推向全球，如今数百万个 Bot 正替人干活 Grok Bot 操盘手 Roman Ugarte 首次公开全部决策内幕：为什么不塞进 Cursor ？为什么每个 Bot 要...

meng shao (@shao__meng) — Wed, 09 Sep 2026 06:50:58 GMT

4 周写出原型，3 周后推向全球，如今数百万个 Bot 正替人干活

Grok Bot 操盘手 Roman Ugarte 首次公开全部决策内幕：
为什么不塞进 Cursor ？
为什么每个 Bot 要有自己的电脑 ？
从 90% 到 100% 是两种产品
到手动拉新 300 人的笨办法 x.com/i/article/2097…

💬13🔄4❤️17👀5873📊24

⚡ Powered by xgo.ing

CMU 26年秋季新课「AI Agents」：从零搭 Harness、建评测、用 RL 训智能体，讲义视频全公开由 OpenHands 作者 Graham Neubig 与 Daniel Frie...

meng shao (@shao__meng) — Wed, 09 Sep 2026 01:26:56 GMT

CMU 26年秋季新课「AI Agents」：从零搭 Harness、建评测、用 RL 训智能体，讲义视频全公开

由 OpenHands 作者 Graham Neubig 与 Daniel Fried 联合开设，28 讲贯通工具调用、上下文工程、技能与记忆、SFT/RL 训练、沙箱安全与人机交互。 x.com/i/article/2097…

💬45🔄122❤️500👀33236📊294

⚡ Powered by xgo.ing

[OpenAI 开发者博客] 用 GPT-6 Astra 做建筑可视化 @Dimillian 从一句话的建筑需求出发，让 Codex (Astra) 逐步建起名为 "Solace" 的可编辑 3D ...

meng shao (@shao__meng) — Wed, 09 Sep 2026 00:30:22 GMT

[OpenAI 开发者博客] 用 GPT-6 Astra 做建筑可视化

@Dimillian 从一句话的建筑需求出发，让 Codex (Astra) 逐步建起名为 "Solace" 的可编辑 3D 住宅；从 Blender 场景、平面布局、家具细节、氛围渲染，一路做到 Unreal Engine 5 的可交互第一人称漫游，最后还展示了三个非建筑项目证明方法的普适性。

Architectural visualization with Astra
developers.openai.com/blog/architect…

1. 氛围先行，户型后至。 第一条提示词只有一句话：“设计一栋极简但细节丰富的房子，带漂亮花园。” Astra 通过 Blender Python API 自主搭建了建筑、家具、植物、材质、灯光和相机，并且自己渲染预览、自己检查、自己修正（如植物穿模、沙发毯的形态）。这是全文最值得注意的能力：不做一次性生成，要带自检闭环的迭代。第二步才加入黄昏光线与森林环境（使用 Poly Haven 资产和大气散射）。

2. 先画平面图，再建模。 Thomas 要求先出平面图供人审批，Astra 给出了围绕庭院的 U 型单层方案，并主动做了设计校验：卧室不被穿越式动线占用、厨房工作区不被过道打断。Thomas 特别强调这个顺序，先平面、再重建 Blender 模型、最后导出 Unreal，计划先行让整个流程成立。

3. 几何级的细节，而非贴图伪装。 家具是真实建模的几何体：沙发坐垫带滚边、床有床架/排骨架/床垫/床品的完整分层、衣柜有内部和挂杆、水槽是真挖空的凹碗、餐桌上摆着餐具。靠垫和床品是手工塑形而非布料模拟（更可控）。材质混合了自建着色与 Poly Haven 扫描贴图，并保持纹理尺度一致。Astra 还会用 Blender 后台模式（--python）跑脚本放置相机、选镜头、渲染，甚至用 computer use 打开应用直接检查场景。

4. 无材质的几何审查。 用实体模式（隐藏屋顶、森林、玻璃）裸检几何：门洞、墙体连接、采样步行路线。但文章明确声明这不构成正确性认证，仍需视觉渲染审查兜底。

5. “生活痕迹”让房子可信。 撤掉偷藏的补光灯（它们把房间打平了）、让光源与可见灯具对应、在灯罩里放入发光灯泡；桌上放面包、香草，茶几上摊开日记、老花镜、钥匙。这些全是建模几何（镂空餐具、罗纹杯、带缝边的亚麻布）。

6. 双引擎输出。
· Blender 影片：35 秒 1080p 相机漫游，四个机位剪辑衔接，1.65m 视高、24–26mm 镜头，Cycles 渲染 900 帧（自适应采样 + OpenImageDenoise）。
· Unreal Engine 5 漫游：FBX 导出求值后的几何 + 一份 JSON 场景描述（位置/材质/灯光/相机），处理了米↔厘米的单位换算和坐标系差异；用 Lumen、体积雾重建林间氛围；加了第一人称角色、碰撞、E 键交互（开门/抽屉、开关灯、操作有意式咖啡机萃取动画的咖啡机；按按钮、出咖啡、液面上升），打包成原生 Mac 应用。两个引擎还做了同机位同视角的七联分镜对比图，各自保留本引擎的光照与色调映射。

7. 超越建筑的验证。 HELIOS（戴森球，5120 块面板）、AURELION-07 星舰（含程序化材质区分陶瓷装甲/机加工金属/玻璃）、莫奈吉维尼花园（睡莲池、绿桥）。三个案例同样展示了 Astra 的自我审查，主动发现土星环被裁切、船头太素、行星抢戏并自行修复。

可复用的路径：选一个想看到的东西 → 描述用途与氛围 → 要求可编辑场景 + 审查视图 → 先看大形再逐层细化。

Derrick Choi@derrickcchoi

Great blog post by @Dimillian about how he used Astra to build a house in Blender, then to Unreal Engine 5.

He reviewed the floor plan before expanding the house, then refined the furniture, materials and lighting.

The details are actually insane. The kitchen drawers open. Light switches work. The espresso machine brews coffee.

developers.openai.com/blog/architect…

🔗 View Quoted Tweet

💬0🔄1❤️5👀2522📊2

⚡ Powered by xgo.ing

OUI-1：首个开源权重的生成式 UI 模型 OUI-1 是基于 DiffusionGemma 微调出的 26B/A4B MoE 模型，专为 "生成式 UI" 设计。它在 Generative UI...

meng shao (@shao__meng) — Wed, 09 Sep 2026 00:15:39 GMT

OUI-1：首个开源权重的生成式 UI 模型

OUI-1 是基于 DiffusionGemma 微调出的 26B/A4B MoE 模型，专为 "生成式 UI" 设计。它在 Generative UI Benchmark 上拿到 71.7%，是基座模型 13.0% 的 5.5 倍，并以 8 倍更少的激活参数击败了 Gemma 4 31B 的46.7%
openui.com/blog/oui-1

生成式 UI 对模型有三个苛刻约束：亚秒级生成、软件级可靠性、能跑在消费级硬件上。团队此前的 AppLess 演示靠 Cerebras 云端跑大模型才勉强达标，OUI-1 的目标是把这套体验搬到本地设备。

选 DiffusionGemma 做基座的架构决策：自回归模型受内存带宽瓶颈限制（逐 token 生成），而 DiffusionGemma 一次并行生成 256-token 块，Google 官方数据是 H100 上 1000+ tok/s、RTX 5090 上 700+ tok/s。但基座模型有个致命短板：速度够了，可靠性不够，只有 13.0%，输出全是结构性错误（枚举值写错、缺必需属性、凭空发明组件、引用未定义名称、生成永远接不到根节点的"孤儿"区块）。

# 方法论：三阶段训练，核心在第二阶段

阶段一：SFT 有效但暴露问题。 用约 700 个大模型生成的示例做 LoRA 微调（单张 A100）。分数从 13.0% 升至 28.8%，但暴露三个问题：①起初混用 7 个组件库训练，loss 降了分数反而更低，收窄到单一库才见效；②schema 错误和 wiring 错误“跷跷板”式此消彼长，无法同降；③速度从 1.6s 回退到 4.3s——程序变冗长（22→32 token/语句），去噪步数翻倍，对以“快”为卖点的方案是釜底抽薪。

阶段二：自蒸馏，全文核心。 关键洞察：OpenUI Lang 的解析器本身就是可验证奖励，既判对错又给出精确错误位置，无需训练 reward model。循环流程：生成几百个程序 → 解析器过滤 → 裁判模型核对需求 → near-miss 交给 LLM 定点修复（只改解析器报出的缺陷，中位数一条语句，重写即拒收，避免数据漂移）→ 存活者回流训练。每轮仅 500 步、一两小时。

结果一举三得：分数升至 57.1%；两类错误同时下降（292→76、971→484），跷跷板停止；速度恢复到 1.9s，尽管 token 量比基座还多 28%。团队对速度恢复给出的解释（自文本训练使梯度集中于修复点，token 提交更早触发）明确声明未经隔离验证——这份诚实值得肯定。

阶段三：泛化。 同一配方横跨 27 个组件库重跑，验证模型学到的是接口的通用规律而非死记硬背。AppLess 手机库 60 个未见需求，OUI-1 产出 55 个有效输出，基座仅 23 个。

Rabi Shanker Guha@rabi_guha

Introducing OUI-1: the first open-weights model for Generative UI

71.7% on Generative UI Bench at 4B params. Beats Gemma 4 31B with 8× fewer active params, and scores 5.5× the base DiffusionGemma it was fine-tuned from.

Methodology, weights, and full benchmark results in the blog 👇

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬2🔄2❤️10👀1871📊4

⚡ Powered by xgo.ing

xAI 开放 X 平台给 Grok Bot：自动开通开发者账号，附赠 $100 API 积分 X 现在可以作为连接集成进 Grok Bot Marketplace，让 Grok Bot 直接读写 X...

meng shao (@shao__meng) — Wed, 09 Sep 2026 00:03:44 GMT

xAI 开放 X 平台给 Grok Bot：自动开通开发者账号，附赠 $100 API 积分

X 现在可以作为连接集成进 Grok Bot Marketplace，让 Grok Bot 直接读写 X 平台，这也是我自己使用频率最高的插件，没有之一。

我可以让 Grok Bot 为我持续监测发帖数据趋势和同类帖子对比、定期总结我点喜欢和收藏的帖子，找到更准的选题方向和发帖内容，基本上取代了 X 自身的搜索和数据分析功能。

接入方式：Grok Bot 用户在 Marketplace 中搜索并添加 X，签名登录后即可连接；没有 X 开发者账号的用户会被自动创建一个。初始附赠 $100 API 积分！

能力范围（Grok Bot 可直接在 X 上执行的操作）：
· 读取：拉取提及中的客户反馈、搜索并总结主题、生成每日摘要、拉取趋势
· 写入：起草并发布帖子、自动回复（可先聚类分析回复再批量发布）
· 高级玩法：解锁 "X Scout" 这类时间线机器人，让 Grok Bot 持续监控信息流

eric zakariasson@ericzakariasson

x.com/i/article/2097…

🔗 View Quoted Tweet

💬2🔄1❤️2👀1576📊3

⚡ Powered by xgo.ing

ChatGPT Images 2.5 发布速度、保真度、编辑精度、多轮一致性四个方面相比 Images 2.0 有提升，并新增 Sketch 手绘输入和模板两种使用方式 https://t.co/...

meng shao (@shao__meng) — Tue, 08 Sep 2026 23:46:44 GMT

ChatGPT Images 2.5 发布

速度、保真度、编辑精度、多轮一致性四个方面相比 Images 2.0 有提升，并新增 Sketch 手绘输入和模板两种使用方式
openai.com/index/introduc…

核心改进：四个维度
1. 速度。 延迟最多降低 50%。对交互式产品来说这不只是体验优化，图像生成从“提交后等待”变成可以连续迭代的对话流，这是生成式工具从演示走向日常生产工具的关键一步。

2. 保真度。 光照更自然、纹理更丰富，更重要的是“参考照片中的主体保留更好”。原文特别指出：主体在不同场景、风格、构图下“更显眼、更易辨认”，对 API 用户而言这意味着“参考引导的工作流”可靠，生成的变体不会偏离原始素材。这直指商业场景中最痛的问题：用产品图、品牌素材做生成时，产品本身不能变形。

3. 精准编辑。 只改指定的部分，其余细节（包括复杂主体和背景）保持不变。API 场景下可以只更新一个元素，换产品、换背景、改文案，而保留主体、构图和品牌风格。这实际上是把“局部重绘”从碰运气变成可依赖的能力。

4. 多轮编辑一致性。 长对话中经过多次编辑后，此前的修改依然保持，质量不随轮次衰减。开发者可以在生产环境做针对性改动而无需每次重建整个素材。这一点对真实工作流的意义可能超过前三项，以往多轮编辑“越改越崩”是所有图像模型的通病。

两个降低门槛的新入口
1. Sketch 是这次最有产品想象力的一项：在 ChatGPT 里直接画草图作为视觉参考，系统将其转化为完整图像，还可以叠加文字描述风格。输入方式是输入 “@ Sketch”。它的定位很明确——“有些想法画出来比描述更容易”。用户不需要会画画，一根线条勾勒出的布局和构图，往往比一段精密的提示词更准确地传达意图。这本质上是给图像模型增加了一条空间/构图先验的输入通道。

2. 模板 则面向“有想法但不知道从哪开始”的用户：海报、周边商品、传单、产品照等热门格式提供起始模板，填入自己的信息、设计元素和风格即可。配合新增的评论式编辑（直接在图片上标注要改哪里）和分享提示词（分享图片时附上所用 prompt，他人可用自己的素材复用同一创意），整个链路从“空白画布”到“传播复用”都被覆盖了。

OpenAI@OpenAI

ChatGPT Images 2.5—faster, sharper, smarter, with better tools for creating whatever you can dream of.

- Faster image generation to keep your ideas flowing

- Improved fidelity for more natural, recognizable images

- Consistent details across multiple edits

- Comment-based edits to change only what you want

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬2🔄1❤️3👀1561📊3

⚡ Powered by xgo.ing

Cohere 开源 Megakernel，比 vLLM 快 1.58 倍 Cohere 为 North Mini Code 模型构建了一个围绕 “decode megakernel” 的推理服务系统...

meng shao (@shao__meng) — Tue, 08 Sep 2026 23:28:19 GMT

Cohere 开源 Megakernel，比 vLLM 快 1.58 倍

Cohere 为 North Mini Code 模型构建了一个围绕 “decode megakernel” 的推理服务系统：整个 decode 阶段的前向计算由一个常驻 GPU 的持久 kernel 完成，不再逐算子启动 kernel。
cohere.com/blog/megakerne…

在单张 H100、BF16 条件下，batch size 1 时达到 292 tok/s；H100 显存带宽理论上限（speed-of-light）的 62%；比 vLLM（185 tok/s）快 1.58 倍；端到端服务（batch size 8）在真实基准上快 1.25–1.41 倍。

为什么值得做：解码的瓶颈在等待，不在计算
自回归解码在低 batch size 下是显存带宽受限的：每生成一个 token，都要把模型权重完整读一遍。North Mini Code 是 30B 参数模型，每个 token 激活 3.3B 参数，BF16 下每步解码要流过约 6.6 GB 权重，外加 8K 上下文时约 0.5 GB 的 KV cache。H100 的 HBM 带宽约 3.35 TB/s，理论极限约 470 tok/s。

而 vLLM 只跑到 185 tok/s，只利用了理论值的 39%。差距去哪了？传统引擎按算子切分——QKV 投影、attention、MoE、RMSNorm 各自是一个独立 kernel，kernel 之间隔着全 GPU 的隐式同步和启动开销。问题不在 kernel 本身，在 kernel 之间的等待：GPU 在算子边界处闲着，显存带宽在被白白浪费。对 memory-bound 的工作负载来说，SM 空转一拍，就是带宽利用率的直接损失。

Megakernel 是什么？
GPU 里有 100 多个独立的流处理器（H100 有 132 个 SM）。Megakernel 的做法是：每个 SM 启动一个 thread block，且这个 block 常驻整个解码步骤。它不从 driver 接收工作，而是去读一份由 host 预先写进全局内存的任务列表——每个任务是一个 tile 粒度的小工作项。数据依赖不再靠 kernel 边界（全 GPU 屏障）表达，而是靠全局内存中的计数器：任务完成时原子递增计数器，等待输入的任务自旋轮询这些计数器，依赖一满足就开工。

调度粒度从“一个完整算子”缩小到“某个算子的某个 tile”；同步范围从“整块 GPU”缩小到“我真正依赖的那几个生产者”。这是整个设计的核心抽象。

这条路线源于斯坦福 Hazy Research 的 "Look Ma, No Bubbles!"——他们曾把 Llama-3.2-1B 融进单个 kernel，batch 1 时达到 H100 带宽的 78%。Cohere 在此基础上做出了三点关键差异：
1. 即使 batch size 1 也用 tensor core 的 wgmma 指令做矩阵乘（比用 CUDA core 更快、寄存器压力更低）；
2. 不用共享内存分页做预取（Hazy 的方案 bug 多、代价高），而是给每种 opcode 一套静态布局的 warp 专用流水线；
3. 重叠方式改为两类：同一 GEMM 的相邻 tile 之间做多级流水；流水线内部让权重加载先于跨 SM 的激活等待发出。

快在哪里：三个超越“启动开销”的收益
区分“省 kernel 启动开销”和三个更深层的机制：

1. 填补波次量化留下的空洞。 132 个 SM 跑 200 个 tile 的 kernel 需要两个“波次”，第二波只有 68 个 SM 有活，其余 64 个空转。kernel 越小，这种取整损失越频繁。在 megakernel 里，任何输入就绪的 tile 可以在任何空闲 SM 上启动。North Mini Code 的并行 Transformer 层结构（attention 和 MoE 都从同一份归一化输入出发，最后由一个融合的残差相加 + RMSNorm 汇合）让 attention 分支和 MoE 分支天然独立，空闲 SM 可以被另一分支的 tile “回填”。

2. 消除伪依赖。 Kernel 边界是全网格屏障：即使 O-proj 只依赖某一个 KV group 的 attention 输出，传统上也要等整个 attention kernel 结束。细粒度计数器让依赖精确到“我等的那份数据好了没有”。

3. 权重预取。 权重是不可变的，不需要等激活值就绪就能提前从 HBM 拉取。系统在前一层 O-proj 的收尾阶段就开始激进预取下一层的 router 和 QKV 权重。

Cohere@cohere

Introducing the next evolution in LLM text generation: the first fully-fledged serving system built around a decode megakernel.

Delivering up to 1.58x faster performance than vLLM. Built for North Mini Code, completely open-source.

🔗 View Quoted Tweet

💬3🔄1❤️5👀2056📊4

⚡ Powered by xgo.ing

[开源分享] Utopia：开源 “企业世界模型” Utopia 把知识图谱、向量检索、本体管理和 AI 推理整合成一个可私有部署的完整产品，让企业把散落的文档沉淀成一张可审计、可回溯、可治理的知识...

meng shao (@shao__meng) — Tue, 08 Sep 2026 14:37:05 GMT

[开源分享] Utopia：开源 “企业世界模型”

Utopia 把知识图谱、向量检索、本体管理和 AI 推理整合成一个可私有部署的完整产品，让企业把散落的文档沉淀成一张可审计、可回溯、可治理的知识底座，供 AI Agent 和人来共同信任与使用。
开源地址：github.com/deeplethe/utop…

核心理念：双时态知识图谱
这是整个项目最区别于普通 RAG 系统和向量库的地方。传统系统只记录“当前知识是什么”；Utopia 记录两条时间线：
· 世界时间（world time）：这件事在现实中何时为真；
· 信念时间（belief time）：系统何时开始相信它。

当新证据修正旧认知时，旧版本事实不会被覆盖，只是被“关闭”并链接到新版本——每次修正都保留出处。落到企业场景就是：一个决策当时是基于什么证据、什么版本的认知做出的，可以完整回放。这直接指向合规审计和决策智能两个高价值场景。

核心流水线：从文档到知识图谱
1. 解析与分块（1200 字符、150 重叠），嵌入后文档立即可搜索；
2. 抽取：每个 chunk 一次 LLM 调用，产出实体提及和事实；关系写入前做签名检查，方向反了会自动纠正并标记 direction_corrected，纠正失败则丢弃并记录 11 种丢弃原因码；
3. 实体消歧：三阶段（精确名称/别名 → 嵌入相似度 → 模型裁决），两个阈值（0.55 归并、0.35 新建），偏向“宁可拆分不误合并”，合并可逆，进入人工审核队列；
4. 类型解析：由抽取线索 + 画像相似度 + 邻居投票两条路线取并集，自动改类型只允许在原子类树内，跨分类轴的纠正交给人；
5. 本体生长闭环：词表外（OOV）的术语保留原文成为“提案”，被确认后进入本体，再反馈给下一轮抽取；
6. 一致性检查与推理：公理检查只“报告不写入”；物化推理（传递性、对称性、逆关系等前向链）默认关闭，派生事实写入独立的 derived_facts 表，每个谓词上限 2 万条，断言事实永远优先于派生事实。

设计决策记录：这个项目最“成熟”的部分
docs/decisions/ 里有 26 篇架构决策记录，标题本身就反映了团队的思考深度，比如：
· “没有类型”本身是一种类型（0009）、“没有关系”就是没有关系（0010）——拒绝为了图好看而填占位值；
· 记录一句话不等于断言一个事实（0015）——记录待确认，防止抽取噪音直接污染图谱；
· 矛盾指向上游（0017）——矛盾被视为数据质量信号而非简单报错；
· 映射不是事实（0011）、本体是契约而非建议（0012）；
· 审计员无需我们就能读懂（0020）——支持 RDF 导出，避免被供应商锁定。

Sumanth@Sumanth_077

Build AI agents on a time-aware knowledge graph!

Utopia is an open-source knowledge system that turns documents, databases, and connected sources into a temporal graph your agents can reason over.

Most RAG systems are optimized for one question: what is relevant right now?

That works until the underlying knowledge changes.

A customer contract gets updated. A project owner changes. A policy is revised. A previous fact may no longer be true, but simply overwriting it means the system loses the history behind that change.

Utopia handles this with a bitemporal knowledge graph.

Each fact can track both when it was true in the real world and when the system learned about it. When something changes, the old fact is preserved instead of silently disappearing.

That means an agent can reason about questions like:

• What is true now?
• What was true three months ago?
• When did this information change?
• What evidence was the conclusion based on?

The graph is also ontology-aware, so documents are represented as entities, facts, and relationships instead of only chunks and embeddings.

That gives the system more structure for reasoning across relationships, resolving entities, detecting conflicting facts, and deriving new information through explicit rules.

Key capabilities:

• Bitemporal knowledge graph for tracking how facts change over time
• Provenance on facts so agents can trace where information came from
• Conflict detection instead of silently overwriting contradictory information
• Ontology-based reasoning across entities, relationships, and derived facts
• Hybrid retrieval across full-text search, vector search, and graph traversal
• MCP and agentic RAG support for exposing the knowledge layer directly to agents

The interesting part is that this turns the knowledge base into more than a retrieval system.

Instead of only finding relevant information, an agent can reason over what changed, what is still valid, how facts are connected, and where each conclusion came from.

100% open source.

I've shared the GitHub repo in the comments!

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬24🔄5❤️28👀3750📊28

⚡ Powered by xgo.ing

关于 Addy Osmani 更多内容推荐 https://t.co/JKTkkWHyRo

meng shao (@shao__meng) — Tue, 08 Sep 2026 14:04:33 GMT

关于 Addy Osmani 更多内容推荐
x.com/shao__meng/sta…

meng shao@shao__meng

Addy Osmani 加入的是 Claude Code！

Addy 对 Agent Harness、Skills、Agentic Engineering、Loop Engineering 等 AI Engineering 重点知识都发表过很有代表性的博客：
addyosmani.com/blog/

书籍「Beyond Vibe Coding」也非常值得阅读
beyond.addy.ie

还有他的「生产级工程 Skills」92.9K 🌟github.com/addyosmani/age…x

🔗 View Quoted Tweet

💬0🔄0❤️0👀646📊1

⚡ Powered by xgo.ing

Addy Osmani 加入的是 Claude Code！ Addy 对 Agent Harness、Skills、Agentic Engineering、Loop Engineering 等 AI...

meng shao (@shao__meng) — Tue, 08 Sep 2026 13:55:16 GMT

Addy Osmani 加入的是 Claude Code！

Addy 对 Agent Harness、Skills、Agentic Engineering、Loop Engineering 等 AI Engineering 重点知识都发表过很有代表性的博客：
addyosmani.com/blog/

书籍「Beyond Vibe Coding」也非常值得阅读
beyond.addy.ie

还有他的「生产级工程 Skills」92.9K 🌟github.com/addyosmani/age…x

meng shao@shao__meng

啊？Addy Osmani 也加入 A\ 啦？

做前端和 AI 开发的朋友们，对 Addy 一定不陌生，他的博客也是必看榜之一，没想到他在经历了 Google Chrome, Cloud, Gemini 等多个产品后，最终还是离开，加入了 A\

职位，不出意外，MTS

🔗 View Quoted Tweet

💬24🔄5❤️41👀7312📊35

⚡ Powered by xgo.ing

AI Agent 的四种知识来源，一张决策法则分清 · Skills - 操作手册 · MCP - 双手 · RAG - 资料库 · Memory - 实战经验来自 IBM Technology...

meng shao (@shao__meng) — Tue, 08 Sep 2026 13:20:27 GMT

AI Agent 的四种知识来源，一张决策法则分清

· Skills - 操作手册
· MCP - 双手
· RAG - 资料库
· Memory - 实战经验

来自 IBM Technology 的视频，10 分钟内把 Skills | MCP | RAG | Memory 四个概念和在 AI Agent 中各自发挥的作用，完全讲明白！
youtube.com/watch?v=X4FVEE…

Skills：教 Agent“怎么做一件事”
Skill 的定义是：一组交给 Agent 的针对特定任务的指令，有时附带一些代码。它包含两部分——要遵循的步骤，以及关于何时遵循、何时停手的判断。

关键机制是“渐进式披露”：Agent 只在任务真正需要时才把该 Skill 加载进来，而不是常驻上下文。视频中的例子是一个“分诊 Skill”：第一步查错误率，第二步检查最近的部署状态；同时它还携带判断力——当 Agent 该停止自行摸索、转而升级给真人处理时。

IBM 强调，这类信息不在模型的训练数据里，所以 Skill 是把组织内部的操作知识结构化地交给 Agent 的方式。但也点出 Skill 的边界：它能告诉 Agent 去查错误率，却没法让 Agent 真的摸到那个仪表盘。Skill 解决“知道该做什么”，不解决“够得着”。

MCP：让 Agent“够得着外部世界”
MCP 解决的是连接与行动问题。其架构是：Agent 作为 MCP host，中间隔着一层标准化协议，外部每个系统各坐落在一个 MCP server 后面。模型本身未必知道怎么查询某个带日志栈的后端，但那个日志栈的 MCP server 知道，并把这个能力暴露成 Agent 可以调用的接口。

回到 500 错误的场景：Skill 说要查错误率，MCP 则让 Agent 通过协议调用真正取回日志、拿到指标、读到真实的错误率。讲者随后指出新的缺口：Agent 现在能查数据了，但它仍然不了解这套系统的“脾气”——什么算正常、依赖关系是什么、这类问题以前是什么原因导致的。

RAG：让 Agent“查到写下来的知识”
RAG 的理念与开头批评的“全塞进上下文”形成直接对照：不是预先塞满，是按需拉取。Agent 提出问题，系统对组织自己的文档集合（手册、依赖关系图等）做语义搜索，把匹配的相关片段返回到 Agent 的上下文窗口里。

IBM 视频中 RAG 读的是向量数据库中的文档，而那些文档是由人主动放进去的。

Memory：让 Agent“积累自己的经验”
Memory 表面上很像 RAG，都是需要时拉取相关知识。但 IBM 给出的区分标准是知识的来源：
· RAG 读的是人刻意存放的文档（显性知识）；
· Memory 是 Agent 自己在过往经历中攒下的东西（经验性知识）。

场景例子很具体：上次同样的 500 错误，真正的原因并不在任何运维手册里，而是“硬啃出来的”；Memory 记录了这个艰难的排查过程。而且 Memory 是双向的：错误修复后，Agent 会把这次的实际解法写回记忆，供下次使用。IBM 总结为一句话：经验在 Agent 的记忆中不断沉淀。

四句话的决策法则
· 有人写下来的知识 → RAG
· Agent 从经验中攒下的知识 → Memory
· 可重复遵循的流程 → Agent Skill
· 需要去真实世界查证/操作且不想写专有代码 → MCP

💬3🔄13❤️61👀4795📊26

⚡ Powered by xgo.ing

麻省理工「多模态 AI 课程」在 Youtube 可以全集学习 https://t.co/IZYkWd0i0o

meng shao (@shao__meng) — Tue, 08 Sep 2026 12:40:28 GMT

麻省理工「多模态 AI 课程」在 Youtube 可以全集学习
youtube.com/playlist?list=…

meng shao@shao__meng

MIT - Modeling: MultiModal AI
aka, How to AI (Almost) Anything

MIT 多模态 AI 课程 2026 版全套上线：视频免费在线学习，从融合对齐一路讲到推理智能体与触觉嗅觉

@medialab Paul Liang @pliang279 主讲，公开可得、体系最完整也最跟得上前沿的多模态 AI 课程之一 x.com/i/article/2097…

🔗 View Quoted Tweet

💬36🔄149❤️633👀48027📊232

⚡ Powered by xgo.ing

啊？Addy Osmani 也加入 A\ 啦？做前端和 AI 开发的朋友们，对 Addy 一定不陌生，他的博客也是必看榜之一，没想到他在经历了 Google Chrome, Cloud, Gemi...

meng shao (@shao__meng) — Tue, 08 Sep 2026 07:26:38 GMT

啊？Addy Osmani 也加入 A\ 啦？

做前端和 AI 开发的朋友们，对 Addy 一定不陌生，他的博客也是必看榜之一，没想到他在经历了 Google Chrome, Cloud, Gemini 等多个产品后，最终还是离开，加入了 A\

职位，不出意外，MTS

Addy Osmani@addyosmani

I've joined @AnthropicAI!

I'll be working on Claude Code and making it better for developers who use it. Here's a little Fable & Three.js

Your browser does not support the video tag.

🔗 View on Twitter

🔗 View Quoted Tweet

💬14🔄3❤️34👀24168📊19

⚡ Powered by xgo.ing

腾讯的 Marvis 居然还在运营？还以为 WorkBuddy 会作为腾讯唯一全力主推的办公智能体，Marvis 这个推出更早的赛马项目，居然还在。。。而且还在和瑞幸咖啡联合推广，又是智能体点...

meng shao (@shao__meng) — Tue, 08 Sep 2026 02:00:21 GMT

腾讯的 Marvis 居然还在运营？

还以为 WorkBuddy 会作为腾讯唯一全力主推的办公智能体，Marvis 这个推出更早的赛马项目，居然还在。。。

而且还在和瑞幸咖啡联合推广，又是智能体点咖啡？这不是去年春节千问、豆包、元宝们玩过的老套路吗？咋又来一轮？很明显的流量高、留存极低的活动。

💬2🔄0❤️1👀973📊2

⚡ Powered by xgo.ing

腾讯团队把内部用了半年的 TeamAI CLI 开源了！ TeamAI CLI：一个 Coding Agents 的"团队配置与知识分发中枢，让团队沉淀的 AI 经验成为公共资产，项目 Slogan...

meng shao (@shao__meng) — Tue, 08 Sep 2026 01:53:12 GMT

腾讯团队把内部用了半年的 TeamAI CLI 开源了！

TeamAI CLI：一个 Coding Agents 的"团队配置与知识分发中枢，让团队沉淀的 AI 经验成为公共资产，项目 Slogan「Make Every Team AI Native」。

它用 Git 仓库作为唯一事实来源，把团队统一的 Skills、Rules、Hooks、MCP 配置和经验知识，同步到每个成员本地的 Claude Code、Codex、Cursor、Qoder、CodeBuddy 等十余种 AI 编码工具中；一次配置，全员生效，且不绑定任何单一 AI 工具。

github.com/Tencent/teamai…

TeamAI CLI 要解决的问题
1. 配置碎片化：同一个团队有人用 Claude Code、有人用 Codex，每个工具的 skills、rules、hooks 格式互不兼容，最佳实践散落在各人本地，无法共享，更无法统一治理。
2. 经验蒸发：某个人花两小时踩透的坑（端口冲突、K8s OOM 排查），结束后只留在他自己的会话记录里，其他人（以及其他 AI 会话）下次还会原样再踩一遍。
3. 治理盲区：团队不知道成员实际怎么用 AI：token 花在哪、干预率多高、哪些 skill 真正被用、哪些是僵尸。

# 三层产品架构

1. Team Execution —— 统一分发
Git 仓库是唯一事实来源：管理员维护 skills、rules、hooks、MCP 配置，经 push → MR 评审 → 合并后，由 SessionStart hook 自动 pull 到每位成员本地的十余种 AI 工具，CLI 负责把统一声明翻译成各工具的原生格式。分发可按角色、标签精细过滤，还能订阅其他团队的公共仓库，且不绑定任何单一托管平台（GitHub/GitLab/私有 Git 均可）。

2. Team Context —— 团队记忆
写入侧靠“摩擦信号”过滤：只有你打断过 AI、拒绝过工具调用、或 AI 反复重试失败的会话，才会提示总结成经验推送到团队仓库——顺滑的会话不产生噪音。读出侧是 teamai recall：任务开始前由子代理自动检索团队知识（本地 BM25 索引 + 代码知识图谱增强排序），零外部数据库依赖。teamai import 还能把代码仓库解析成结构化图谱（tree-sitter AST 提取依赖边），让 AI 检索时直接定位源文件入口。

3. Team Improvement —— 飞轮闭环
digest 团队周报（token 用量、干预率）+ dashboard Web 看板（含知识库健康监控），配合 recall promote（高价值经验晋升为正式 skill）和 recall maintenance（清理过时条目），让每一次执行都沉淀为团队能力，而不是随会话蒸发。

TeamAI 的底层想法是：Coding Agent 的“个体最佳实践”如果不沉淀为团队资产，就会随每个会话蒸发。它占据了一个聪明的生态位，所有工具下方的“配置分发 + 知识记忆”层，用 Git 做事实来源，用评审流程做治理，用摩擦信号控制信噪比。

三层架构层层递进：Execution 解决“统一用”，Context 解决“记得住”，Improvement 解决“越用越好”，构成完整飞轮。

对于 5 人以上、多工具混用、且已认真在生产环境使用 AI Coding 的团队，这是一个值得现在就试的项目；更宏观地看，它代表了 2026 年 AI 工具生态的一个清晰趋势：竞争正在从单个 Agent 的能力，转向团队级 Harness 和记忆系统的标准化。

Tencent AI@TencentAI_News

We used TeamAI-CLI internally at Tencent since March. Open sourced it.

It turns team knowledge into one git repo, so every agent works from the same handbook.

what it does:
> git-based: skills, rules and docs live in one repo, changes go through a merge request
> hook-triggered: merged changes land on everyone's next session
> each learning earns confidence from real usage, strong ones surface first, weak ones sink
> works with claude code, codex, cursor, opencode, codebuddy and workbuddy

One person's hard-won workaround can now become the whole team's default.

github.com/Tencent/teamai…

🔗 View Quoted Tweet

💬48🔄44❤️224👀27119📊106

⚡ Powered by xgo.ing

[开源推荐] microsoft/tgrep 微软开源的命令行代码搜索工具：它把 grep/ripgrep 这类“每次查询都全量扫描”的工具，改造成“先建一次倒排索引，之后每次查询只碰可能匹配的文件...

meng shao (@shao__meng) — Tue, 08 Sep 2026 00:41:11 GMT

[开源推荐] microsoft/tgrep

微软开源的命令行代码搜索工具：它把 grep/ripgrep 这类“每次查询都全量扫描”的工具，改造成“先建一次倒排索引，之后每次查询只碰可能匹配的文件”。在大型项目中，最高比 ripgrep 快 50+ 倍！
github.com/microsoft/tgrep

核心思想：把复杂度从“每次查询”挪到“一次性建索引”
传统 grep/ripgrep 的每次查询是 O(全库字节)。这在 30 万~50 万文件的 monorepo（Chromium、gecko-dev 这个量级）上意味着单次搜索几秒到几十秒。tgrep 的做法是经典的 trigram 倒排索引——这正是 Google 早期代码搜索（Russ Cox 的 codesearch）的思路：
1. 索引阶段：把每个文件的字节流切分成所有重叠的 3 字节 trigram，构建“trigram → 文件列表”的倒排索引。
2. 查询阶段：用 regex-syntax 解析正则，提取其中的字面量片段（literal extraction），把片段转成 trigram 集合；对 posting list 做交集（AND）或并集（OR），得到候选文件集；最后只对候选文件用完整正则引擎做并行验证。

结果就是：搜索只读极少数文件。代价是约 20 分钟一次的建索引（Chromium 级别）和约等于语料 2~4% 的磁盘索引。

架构：常驻服务器 + 三层索引
tgrep <pattern>  - TCP/JSON-RPC -> tgrep serve -> HybridIndex

· IndexReader：mmap 磁盘索引，零拷贝，在有序 trigram 查找表上二分查找。
· LiveIndex：内存覆盖层，存放服务器启动后新增/修改的文件，优先级高于磁盘索引。
· HybridIndex：合并两者，对客户端呈现统一视图。
· 后台索引器：rayon 并行建索引（每批 500 文件），建到一半就能查询——服务器先起，从部分数据开始服务。
· 文件监听：notify crate 实时捕获变更更新 LiveIndex，每小时做一次对账防止漏事件；每 5 万文件或 5 分钟刷盘一次。
· TCP 服务器：JSON-RPC 2.0 over 换行分隔 TCP，每连接一线程，多客户端并发；客户端通过 serve.json 里的 PID/端口自动发现服务器。

工程质量：一线工程判断细节
· 内存控制：默认采用外部归并排序建索引，峰值内存基本不随仓库增长（Linux 内核上约 150 MiB，相比内存策略的 2.2~3.8 GiB 降了 ~17 倍，且不牺牲时间）。
· 诚实的内存度量：曾有人在 29 万文件 monorepo 上报出 13.49 GiB 峰值，排查后发现是工作集指标把 mmap 的文件页算进去了（一个 2 GiB 文件让真实私有内存被夸大 26 倍）——于是改为报告 private bytes。这种“先搞清楚指标再优化”的态度很少见。
· 64 MiB 文件大小上限：一个真实案例中，某个 13.41 GiB 的生成产物占了语料的 71%，设上限后热查询从 21.3s 降到 0.55s。且命令行显式指定的文件不受上限影响，--no-max-filesize 可完全关闭。
· ripgrep 兼容性作为采用策略：绝大多数 rg 旗标可用或被无害忽略（--mmap、--crlf），退出码一致，输出兼容 rg 的 JSON 格式——用户可以无痛把脚本里的 rg 换成 tgrep。而 -z（压缩文件搜索）故意以错误码 2 退出而非静默返回空结果，避免“看起来搜完了其实没搜”。
· UTF-8 处理：无效字节用 U+FFFD 替换后进 trigram 索引，位置再映射回真实字节偏移，保证 --column、--vimgrep 等输出正确。
· 真实世界适配：支持 P4 ignore 文件、无 .git 但有 .gitignore 的 Perforce 场景、Windows 大小写不敏感文件系统（读取 git 的 core.ignorecase 来匹配忽略规则）。

它不是 ripgrep 的全面替代品，有明确适用边界的工具：
· 适合：10 万文件以上的大仓库、Windows/macOS 开发环境、Coding Agents 这类高频低延迟 grep 场景、一次性探索性查询多的日常工作流。
· 不适合/代价：需要一次性建索引的时间和磁盘（Chromium 约 1 分钟 + 2.5 GB 索引）；小仓库收益有限；搜索高频 token 时可能更慢；极端冷启动下服务器就绪需约 30 秒（内核仓库）。

💬1🔄5❤️19👀2477📊9

⚡ Powered by xgo.ing

Codex / Claude Code 等 Coding Agents 让代码和 PR 数量爆炸式增长，人来审查代码根本追不上！那怎么办，代码就真的不做审查了吗？ @addyosmani 给出的方...

meng shao (@shao__meng) — Tue, 08 Sep 2026 00:21:55 GMT

Codex / Claude Code 等 Coding Agents 让代码和 PR 数量爆炸式增长，人来审查代码根本追不上！

那怎么办，代码就真的不做审查了吗？ @addyosmani 给出的方案是一个「分层策略」，按爆炸半径分配人类注意力；说人话就是：代码越多，人类越要挑着看，不是硬着头皮全看 😂

# Addy 的三层分层策略

第一层：多智能体初审，人类保住否决权。 每个 PR 先由多个 agent 做一轮完整检查——发现 bug、验证 bug 是否真实存在、按严重程度排序、给出修复建议。注意这里的关键设计：agent 负责“生成和筛选信号”，但批准仍是人类对重要事项的决策权。他把 AI 定位为初审过滤器，而不是终审法官。

第二层：低风险变更，初审干净即可放行。 影响面小、又不涉及敏感逻辑的改动（他强调这类 PR 其实占大头），只要 agent 审查干净，就不必再深挖人工审查。这一层解决的是“数量”问题——用机器覆盖长尾，人力才不至于被淹没。

第三层：核心路径，人工签字不可替代。 关键和敏感代码依然要有明确的 owner 和人类 sign-off。人类的时间花在刀刃上：验证、明确约束边界、逐步建立对“agent 能安全覆盖哪些范围”的信任，并且始终保持可恢复性，也就是出问题时系统有能力回滚和止损，而不是把安全完全托付给流程本身。

Addy Osmani@addyosmani

How I do code reviews these days: more code = more selective human review i.e. don't read all the code.

1. Every PR gets a multi-agent first pass. It should find bugs, verify them, rank by severity, suggest fixes. Approval stays a human call on anything that matters.

2. Low blast radius changes on less sensitive code (there's often a lot!) can skip a deep human review once that review is clean. This helps keep the explosion of PRs manageable.

3. Core / sensitive paths still need an owner and human sign-off. That's where you spend time: verification, constraints and earning trust in what the agents can safely cover. You want to keep recoverability.

Agents do the first pass and humans cover blast radius.

Great question from @GergelyOrosz!

🔗 View Quoted Tweet

💬1🔄4❤️9👀2327📊4

⚡ Powered by xgo.ing

MIT - Modeling: MultiModal AI aka, How to AI (Almost) Anything MIT 多模态 AI 课程 2026 版全套上线：视频免费在线学习，从融...

meng shao (@shao__meng) — Tue, 08 Sep 2026 00:11:48 GMT

MIT - Modeling: MultiModal AI
aka, How to AI (Almost) Anything

MIT 多模态 AI 课程 2026 版全套上线：视频免费在线学习，从融合对齐一路讲到推理智能体与触觉嗅觉

@medialab Paul Liang @pliang279 主讲，公开可得、体系最完整也最跟得上前沿的多模态 AI 课程之一 x.com/i/article/2097…

💬3🔄9❤️27👀53460📊26

⚡ Powered by xgo.ing

7 个前沿 AI 模型在 161 个品类里会推荐哪些产品？ @latentspacepod 团队构建了一个可公开查询的 "Frontier AEO Tracker"，对 AI 模型的推荐行为做了系统...

meng shao (@shao__meng) — Mon, 07 Sep 2026 23:47:41 GMT

7 个前沿 AI 模型在 161 个品类里会推荐哪些产品？

@latentspacepod 团队构建了一个可公开查询的 "Frontier AEO Tracker"，对 AI 模型的推荐行为做了系统测量，详细数据在这：
latent.space/p/aeo

先看看 AEO 是什么？
AEO（Answer Engine Optimization）是 SEO 的 AI 时代对应物：当用户越来越多地通过 ChatGPT、Claude 这类带搜索能力的模型（非传统 Google）来发现和选择产品，“成为模型的推荐答案”本身就成了一个可经营、可度量的渠道。

Latent Space 对自己内容做了一次“朴素的 AEO 投入”，发现 ROI 出乎意料地好，于是决定把它当回事，做成了系统性研究。方法论上，他们延续并扩展了 AmplifyingAI 的《What Claude Code Actually Choosoes》项目：
· 6 种提示词变体 × 7 个模型（开启搜索）× 161 个品类，从 Coding Agent、托管数据库、语音识别，到天使投资人、创业薪酬软件这类；
· 答案抽取由模型（Astra）自动完成；
· 设计了专有的 AEO 分数：首选加权最高，备选和提及次之，轻度/强烈“反向推荐”（模型明确劝你别用）给负权重；
· 所有提示词-回答对全部公开可查，烧掉了“几十亿 token"。

# 四个核心发现

1. 推荐格局高度集中，但远未完全固化。 161 个品类中有 28 个存在“所有模型一致首选”的统治级产品；但大量品类是差距微弱的“胶着战”；作者戏称有些产品 "always the vibesmaid, never the vibe"。这些胶着品类正是 AEO 最值得投入的主战场：头把交椅尚未锁死。

2. 模型的“自家偏好”真实存在。 Anthropic 的模型偏爱 Claude Code，OpenAI 的偏爱 Codex，Grok 偏爱 Cursor，Muse 偏爱自家 Muse Code，SWE-1.7 偏爱 Devin；作者只留下一句 "I wonder why"。但也有反例：GPT 系模型会推荐 Claude，被作者称为“值得称道的无偏见”。

3. 同厂代际之间会出现“后果很严重”的推荐翻转。 新一代预训练模型意味着实验室数据构成和 RL 优先级的变化，Opus→Fable、Sol→Astra 都出现了产品推荐位的实质性易主。这对创业公司的含义是：你在一个模型上建立的 AEO 优势，可能在下一次模型换代时清零——这是一项需要持续监测的资产，不是一次性工程。

4. “效率 vs 置信度”。Anthropic 似乎在把模型推向检索更多来源，而 Astra 检索更少、但对问题改写的抵抗力远强于上一代——轻微软述同一问题，它不太会换答案。作者点出的关键推论是：随着模型答案随机性下降，AEO 本身的价值在上升。当推荐从“抛硬币”变成“稳定输出”，拿下首选位的回报变得确定且可累积。

Latent.Space@latentspacepod

🆕 project: our Frontier AEO tracker

What does Astra prioritize? what sources does it use? What shifted from Sol to Astra, and Opus to Fable?
latent.space/p/aeoJ

all our answers within!

🔗 View Quoted Tweet

💬3🔄1❤️4👀1552📊4

⚡ Powered by xgo.ing

Claude Fable 5.1 与 GPT-6 Astra 写作风格指南 # Claude Fable 5.1：Writing density（写作密度） https://t.co/jiOrgtY...

meng shao (@shao__meng) — Mon, 07 Sep 2026 23:36:24 GMT

Claude Fable 5.1 与 GPT-6 Astra 写作风格指南

# Claude Fable 5.1：Writing density（写作密度）
platform.claude.com/docs/en/build-…

Claude Fable 5.1 的写作总体比早期 Claude 模型更好，套话更少、不解释的术语更少，但在某些场景下散文比 Claude Fable 5 更“密”：句子更长、分段更少。

Anthropic 官方给出的对策
定义一个反模式，"mannered prose"（矫饰文风），把它写进 user message（首选）或 system prompt：

矫饰的散文用隐喻和修辞代替直接陈述。该说“一个值得调整的参数”，矫饰的作者却写成“一个值得转动的旋钮”；该说“这一点仍然重要”，却写成“这一点配得上它的位置”。这些短语的存在是为了展示写作者，而不是传达想法，读者能分辨得出来。它还不精确：隐喻会拖入作者没有选择也无法控制的含义。解决办法就是说出你的本意——有直白的说法可用时，就用直白的说法。

文档也提到简短版本通常同样有效：
Please remove all mannered prose.

# GPT-6 Astra：Personality and writing style（个性与写作风格）
developers.openai.com/api/docs/guide…

默认行为：GPT-6 Astra 倾向于使用列表、表格和 Markdown 让回复易于扫读。如果应用需要少格式的散文，需要明确指定。它还可能在多个会话间使用重复出现的短语（recurring phrases）。

OpenAI 给出三层提示词
1. 散文优先规则：默认使用清晰简洁的段落，每段发展一个主旨；仅当信息真正并列、顺序或便于比较时才用列表，能用散文表达清楚就不用嵌套列表；使用平实简单的语言——熟悉的词、具体的例子、精确的动词，偏好主动语态和直接陈述；主旨要清晰且前置，然后展开。
2. 技术写作平衡：用平实语言代替行话，技术细节只在有助于说明问题时引用；根据用户 prompt 和上下文所暗示的背景知识水平来校准写作深度。
3. 反 "slop" 清单：避免 "Bottom Line:"、"delve"、"foster"、"leverage"、"it's worth noting"、"importantly"、"This isn't about X. It's about Y."、"genuinely"、连字符复合形容词等套话；不用 "In short:" 之类的总结句式；直接陈述要做的动作，不要写“不会做什么”；避免 "X, not Y" 式的对比框架（引入用户没问的备选项）；避免自造复合标签（如 "exact-head checks"）和空泛的限定词，用平实的动词和介词直接表达关系。

💬2🔄2❤️7👀1678📊7

⚡ Powered by xgo.ing

Anthropic 工程师已不待在 IDE 里，有客户六个月没写过一行代码。这场 70 分钟访谈里，Claude Code 团队工程师 Thariq Shihipar 首次系统披露一线实践：删掉 ...

meng shao (@shao__meng) — Mon, 07 Sep 2026 14:02:14 GMT

Anthropic 工程师已不待在 IDE 里，有客户六个月没写过一行代码。

这场 70 分钟访谈里，Claude Code 团队工程师 Thariq Shihipar 首次系统披露一线实践：删掉 80% 系统提示词、示例成了负资产、测试代码要多 100 倍。当编码被“解决”，工程师的护城河还剩什么？ x.com/i/article/2096…

💬54🔄8❤️54👀7775📊84

⚡ Powered by xgo.ing

[前端设计 Skills 分享] Impeccable 66K 🌟 作者 @pbakaus 以 Anthropic frontend-design skill 为起点，通过 Skills + 6...

meng shao (@shao__meng) — Mon, 07 Sep 2026 11:12:22 GMT

[前端设计 Skills 分享] Impeccable  66K 🌟

作者 @pbakaus 以 Anthropic frontend-design skill 为起点，通过 Skills + 61 条确定性检测规则 + 硬性工作流，来根治一眼假的 AI Slop ...github.com/pbakaus/impecc…e

AI Slop 从哪来？
所有模型都在同一批 SaaS 模板训练，产出高度趋同的“AI 设计偏好/ AI Slop”：Inter 字体、紫蓝渐变、卡片套卡片、彩色背景上放灰字、每个标题上方一个圆角图标块 ...

# Impeccable 的架构应对分三层

第一层：Prompt 层（Skill 文本）。 1 个 skill 入口 /impeccable，内含 23 个子命令，本质是一套与 AI 共享的设计词汇表——init（采集产品事实写入 PRODUCT.md）、critique（UX 评审）、audit（技术检查）、polish / bolder / quieter / distill（不同方向的精修）、live（浏览器内可视化变体迭代）。用自然语言命令取代模糊的“帮我做好看一点”。

第二层：确定性检测层（核心创新）。 61 条规则全部用 Rust 实现，零 LLM、零 API key 地静态分析 HTML/CSS 或扫描 URL 渲染结果。规则分两类：32 条 "slop"（AI 口癖：side-tab 彩色边条、bounce 缓动、radial 光晕、闪烁光标、渐变文字、破折号滥用……）和 29 条 "quality"（行宽、触控目标、跳级标题、低对比度、越界文本……）。可独立于任何 AI 工具使用：npx impeccable detect src/，退出码 2 即有问题，可直接进 CI。

第三层：流程契约层（最有野心的部分）。 它不只给建议，还把“防止模型走回头路”写成了硬性流程：设计 hook 在你编辑 UI 文件后自动跑检测器、把发现回灌给 agent（Cursor 上甚至在写盘前拦截）；critique 强制两个隔离的子代理分别评审（LLM 判断与检测器证据互相不污染，再合成报告）；finish reviewer 必须在新上下文中运行，因为“继承你转录的评审者会继承你的乐观”。

# 工程上真正出色的几点

1. 无运行时依赖的分发设计。 每份 skill 只带一个几百行的启动脚本，首次运行时下载一个静态 Rust 二进制到 ~/.impeccable/bin/。hook 和 skill 都不需要 Node——npx 只是安装器外壳。这让它在 17 种形态各异的工具里保持同一行为。

2. 同一套核心、三种执行引擎。 crates/core 里的规则逻辑被编译三次：静态引擎（解析 HTML/CSS 级联，无需浏览器）、浏览器引擎（CDP 连真实 Chrome 检查渲染后 DOM）、以及 wasm（打进浏览器扩展和页面内注入 bundle）。写一次规则，处处生效，且行为由 tests/oracle/ 固定。

3. 产品事实与视觉方向分离。 PRODUCT.md 只记“不可协商的产品真相”（用户是谁、差异化机制、证据），DESIGN.md 只记“既成视觉决策”——且明确规定 DESIGN.md 在建成后由 documenter 从代码反写，因为“建成前写的规则书会被拿去对抗现实而不是描述现实”。这个认识很深。

4. 对抗模型惰性的机制化。 最典型的是 concept-seed：新视觉方向必须跑一个脚本随机分配设计方向 + 洗牌挑战者，“写 artifact 代码前没跑这个脚本是违约”。原因是模型天然收敛到品类默认——用骰子强制探索，再用“观众认同 / 产品清晰”两个轴裁决。甚至给 Claude 单独标注了它的“奶油底衬线字”偏好，要求视其为已花掉的预算。

5. Comp-led 构建的状态机。 选了“先出高保真设计稿”路径时，构建被拆成 comps → spec（网格测量设计稿、从 Google Fonts 指纹索引匹配字体）→ plates（图块资产以 1.5 倍分辨率重生成）→ hero（首屏与设计稿像素 diff，72% 过线）→ sections → motion → responsive 的门控流水线。每一关由二进制测量把关，不靠模型“自我感觉复现成功了”——文档直言“模型系统性地高估自己对图像的 HTML 还原能力”。

💬19🔄4❤️25👀3083📊31

⚡ Powered by xgo.ing

GPT-6 Astra 在 Google Calendar 里画 Michael Jackson 不得不说，你们 token 是真富裕 😂 上次看到这种玩法，还是办公高手在 Excel 里画画，...

meng shao (@shao__meng) — Mon, 07 Sep 2026 09:06:45 GMT

GPT-6 Astra 在 Google Calendar 里画 Michael Jackson

不得不说，你们 token 是真富裕 😂

上次看到这种玩法，还是办公高手在 Excel 里画画，长这样。。

Charly Wargnier ♨️@DataChaz

GPT-6 Astra really just drew Michael Jackson in Google Calendar 😁

🔗 View Quoted Tweet

💬1🔄1❤️3👀1932📊2

⚡ Powered by xgo.ing

15 个真实工作场景对测 GPT-6 Astra 和 Claude Fable 5.1 来自 @nateherk 同一套提示词、同一批真实业务上下文，比较 OpenAI 和 Anthropic 两个...

meng shao (@shao__meng) — Mon, 07 Sep 2026 06:38:22 GMT

15 个真实工作场景对测 GPT-6 Astra 和 Claude Fable 5.1

来自 @nateherk 同一套提示词、同一批真实业务上下文，比较 OpenAI 和 Anthropic 两个顶尖模型的交付物质量、耗时和费用，要搞清楚日常该把哪类任务交给哪个模型。
youtube.com/watch?v=WfJPBV…

# 15 场实验：最终比分 Astra 10 : Fable 5

第一类：知识交付与文案
Fable 的第一版往往更完整（Fable 胜出）

1. 麦肯锡风格 SMB 报告（Hercules Consulting）
Fable 更有结构：分栏、页脚、品牌一致，35 页，适合当文档交出去；但字太多，现场讲不好。Astra 更短、更好讲，观感偏 Canva / Google Slides。Fable 37 分钟 / $26，Astra 23 分钟 / $12

2. 认证项目销售信
Fable 约 2800 字，有 FAQ、学费、适合谁 / 不适合谁、课程怎么运作；Astra 约 1300 字，偏高层。作者承认自己不是文案专家，团队最近更爱 GPT 写字，但他作为潜在学员仍选 Fable。费用：Fable ~$4，Astra $1.43

11. 把一条 YouTube 教程做成可视化 HTML 展示
Astra 页面更好看、更便宜；Fable 截图更多、标注更细，更像“看完了整条教程”。作者也承认：如果让 Astra 再花约 20 美元迭代，很可能超过 Fable 的 V1

第二类：财务与经营分析
Astra 更敢问、结构更贴人（Astra 胜出）

3. 个人 / 实体税务（Q1–Q2）
Fable 直接给决策树；Astra 先问约 7 个问题，再给建议。Astra 有 3739 行交易台账，更贴本人情况。Fable 22 分钟 / $13，Astra 40 分钟 / $22。贵、慢，但作者更信任

4. 两封邮箱多年订阅审计
Fable 的“全部扣费”表是空的；Astra 完整列出订阅、涨价、座位重叠、待审优先级。Fable $50 / 17 分钟，Astra $12.5 / 30 分钟——质量更好还便宜很多

5. 领导层会议分析
Fable 看了 58 场会，$46（有效代理时间仅 6 分钟，费用作者自己也看不懂）；Astra 看了 79 场，$5.5。两边都建议做学员成功工作流，但 Astra 更强调所有权和客户旅程里的人工介入

15. YouTube 12 个月复盘与策略
Fable 25 页、17 分钟 / ~$9；Astra 15 页、42 分钟 / ~$27。Astra 更可视化、更好读。内容上都点到：新闻带播放量但不带订阅、包装在往“噱头”漂、机构类内容失效

第三类：视频与设计
Astra 普遍更有“成品感”（互有胜负）

6. 从 150GB 活动素材做 60 秒回顾片（Astra）
两边都强。Fable 更会导向下一场活动，但口型/节奏有时不同步；Astra 现场素材用得更好，但有一处张冠李戴（画面是 Russ，字幕写成 Devon Karns）。Astra 30 分钟 / $16，Fable 50 分钟 / $26

7. 按参考片做 AIS 宣传 dynamism reel（Astra）
Astra 会自己去课程页截真实画面，还有 3D 纵深和阴影；Fable 能量更弱。这次 Fable 更便宜（$16 vs $26），作者仍选 Astra

8. 开心果逃出厨房的小游戏（Astra）
关卡流程几乎一样（抽屉→书→炉灶→水槽）。Astra 手感更顺、观感更贵。费用接近，Astra 便宜约 8–9 美元，但大约多花 40 分钟

9. 迷你 SaaS：自动化评测台（Astra）
Fable 功能全但界面密、吓人；Astra 更干净，跑测过程可见，报告更像能给人看的产品。Astra 约 2 小时 25 分，Fable 约 1 小时 20 分，Astra 只要一半价钱

10. 本地知识图谱 “Herk Brain”（Fable）
这是 Astra 少有的设计翻车：节点太小、界面过载。Fable 24 分钟，Astra 40 分钟，费用接近。作者要的是“一眼看见脑子”，Fable 更接近

12. 看参考图、在 Canva 里复刻画（Astra）
用来测浏览器操作和视觉。Astra 能在 Canva 里画出像样的结果；Fable 的成品作者直接称为可笑，还更贵、更慢

14. 按参考站做功能饮料品牌站（Fable）
Astra 滚动更顺、动画更好，但不够像原站（字溢出等）；Fable 更接近“分析这个站、做出同样气场”。两边底部滚动都有 bug。作者补充：平时设计他仍更偏向 Astra，这场是因为提示词要的是复刻，不是自由发挥

第四类：浏览器落地
Codex / Astra 系明显更稳

13. 把新课程以草稿形式写进 School 社区（描述、要点、引言、资源、视频），只做前 5 课
Astra 能打开后台、建页、嵌视频、写正文并存草稿。Fable 文案结构甚至更好看（有编号），但视频上传失败。作者说自己多次用 GPT-5.6 Soul 做同类浏览器任务，结论很干脆：浏览器操作上，Codex / GPT 系明显强于 Fable。

# 算个总账：更贵的那个，并不总是更好

GPT-6 Astra 比 Claude Fable 5.1 便宜约 186 美元，总时长多约 1 小时 43 分。

和单场体感并不完全一致：作者日常感觉 Astra 更利落，而且 Codex 没有 Claude Code 那种 5 小时窗口 / Fable 额度限制，一周都能持续用。总时长更长，主要是若干重任务（评测台、税务、YouTube 复盘、游戏）拖长了，不是“每一步都更慢”。

费用异常也很值得单独看：会议分析 Fable $46、订阅审计 Fable $50，产出还不如更便宜的 Astra。这说明现在选模型，不能只看订阅价，还要看单次任务的 token 行为是否可控。

💬13🔄2❤️13👀2382📊19

⚡ Powered by xgo.ing

CS329A Self-Improving AI Agents 斯坦福大学一门关于「能够通过与自身和环境的交互持续自我改进的 AI Agents」的课程。讲师阵容 Azalia Mirhosei...

meng shao (@shao__meng) — Mon, 07 Sep 2026 03:35:54 GMT

CS329A Self-Improving AI Agents

斯坦福大学一门关于「能够通过与自身和环境的交互持续自我改进的 AI Agents」的课程。

讲师阵容
Azalia Mirhoseini：AlphaCode 与 LLM 大规模训练调度优化（"Circuit Training"）的核心人物，现为 Reflection AI 联合创始人
Aakanksha Chowdhery：PaLM 2 与 Gemma 的负责人，同样在 Reflection AI

嘉宾名单
Misha Laskin（Reflection AI CEO）
多位 Google DeepMind 研究员（Denny Zhou、Thang Luong、Melvin Johnson）、Physical Intelligence（Danny Driess，机器人）

课程主线：一条完整的自我改进技术栈
1. 推理时自我改进（Test-time）
2. 从反馈中学习（Feedback → Learning）
3. 开放式进化与搜索（Open-endedness）
4. 工程化与瓶颈（Agentic Engineering & Bottlenecks）

课程详细信息：
cs329a.stanford.edu/index.html

💬61🔄113❤️505👀86789📊262

⚡ Powered by xgo.ing

压缩 Agent Skills 的真正风险不在于丢内容，在于丢路由：SkillZip Pro 如何安全砍掉 38% 的 Skills Bundle https://t.co/4lmiHvtRaU 来...

meng shao (@shao__meng) — Mon, 07 Sep 2026 01:33:50 GMT

压缩 Agent Skills 的真正风险不在于丢内容，在于丢路由：SkillZip Pro 如何安全砍掉 38% 的 Skills Bundle
arxiv.org/pdf/2608.30785

来自阿里和浙大的论文，他们发现生产环境的 Agent Skills 是目录，不是单个 prompt：根文件 SKILL.md 激活时必载，references/subskills/scripts 只在执行路径走到时才加载。这带来三个被以往方法忽视的事实：
1. 只压根文件没触及部署成本的大头，还可能把罕见分支细节挪进根，让每次调用更贵；
2. 拍平拼接摧毁渐进加载边界——链接断了，分支实际不可达；
3. 自进化放大冗余：论文实测每轮新增内容约 55% 是重复文本。
因此压缩的对象应是"带加载权重的资源图"，不是扁平字符串。

# 方法：两大支柱 + 两个正交维度

支柱一（省在哪）：激活感知的跨文件压缩
· 宿主蕴含剪枝：环境契约已精确覆盖的文本可删，须留绑定摘要的证人，无契约则空操作；
· 作用域内共享：跨分支重复文本提取为共享模块，但绝不提升进根；
· 条件胶囊：带明确触发的长分支移入按需文件，原地留一行调度器。

支柱二（如何不出事）：跨文件路由保持
"任务匹配 X 时读取 refs/x.md" 这类看似散文的行是 Skills 的导航表。三层防御：路由表锁定为一等单元、含引用的源行逐行保留、发布前独立审计从磁盘重读输出并验证所有文件从根可达，失败则原样发布。

两个正交开关：何时压（One-Shot 全量重建 / Continual 增量 + 定期重打包）× 结果放哪（Persistent 重写正式包 / Transient 每次运行构建临时视图、不动原包）。四种组合各对应一类部署场景。

配套机制：
· 四层成本模型（目录/激活/路径/部署）——单一压缩比会掩盖"包变小但每次运行变长"的回退，四层必须分开报告；
· 证人层级 W1（逐字包含）≻ W2（覆盖检验）≻ W3（冻结模型的蕴含认证，仅限证据类内容、逐条留档）——无法附加证人的删除一律拒绝；
· 安全回退语义：持续模式失败时发布"逐字打了补丁的原始包"——压缩可丢节省，绝不丢补丁。

# 结果：三组关键数字

三个基准（102 留出任务）
唯一同时削减全部四层成本且通过非劣效性检验的压缩器（部署 −19.7%，单次运行 −14.3%）；其余所有方法含专家基线均跌破质量线

真实进化库（重复率 ~80%）
部署 −34.7%（最强保真基线 25.0%），路由 1.000；Continual + 重打包省 48.1%，仅用 1/3 的重建调用

生产审核 Skills
最终配置：部署 −38.1%、单次运行 −10.4%、准确率 89% vs 基线 91–92%；无保护激进压缩（−71%）准确率暴跌 18–26 分，假阳性从 10 涨到 29–35

# 五个核心洞见

1. 危险是丢可达性，不是丢文本——只重写根文件，分支全在磁盘上却不可达，"看着安全，得分像删除"；

2. 压缩要趁早——重复逐轮累积，已付的上下文无法事后回收（第 1 轮开启省 40.8%，第 13 轮只剩 18.5%）；

3. 压缩器价值随时间增长——可删份额从 29% 升至 53% 仍在涨，且重复高度集中于少数"通用规则"（前 2 个共享模块占 47% 复用）；

4. 压缩改变跨模型可移植性——结构可移植，但加载效率取决于执行器如何解读路由（kimi 上无关加载显著上升）；

5. 安全上限由证据强度决定——W1/W2 只撑起 13.8% 节省，受限 W3 提到 32.7%，扩展到根到 38.1%。

💬12🔄3❤️16👀2539📊18

⚡ Powered by xgo.ing

AI 研究加速：来自 OpenAI 内部的视角 https://t.co/wjK3qWroNh 随着 Codex 的快速发展，OpenAI 内部研究员日常工作中 Coding Agents 的用量在...

meng shao (@shao__meng) — Mon, 07 Sep 2026 00:40:36 GMT

AI 研究加速：来自 OpenAI 内部的视角
openai.com/index/research…

随着 Codex 的快速发展，OpenAI 内部研究员日常工作中 Coding Agents 的用量在 2026 年年中后涨得非常快，每天的中位数用量 600 刀，P90 用量 7000 刀

在 AI 研究的六个阶段：Decide -> Design -> Build -> Run -> Analyze -> Communicate 中，每个阶段用量都在增长，但研究方向和决策，这两个关键节点涨得更少。

这也符合 Sam Altman 对 AI 研究 26.09 达到 “研究实习生” 的判断，以执行、排查、实验为主，研究方向和决策更少参与，需要人类研究者输入。

💬1🔄2❤️2👀1288📊3

⚡ Powered by xgo.ing

[Skills 分享] 让 Codex / Claude Code / GrokBot 等能读本地文件、能跑代码的 Agent，借助 Gemini API 有真正能 "看" 视频的能力 https:/...

meng shao (@shao__meng) — Sun, 06 Sep 2026 23:47:22 GMT

[Skills 分享] 让 Codex / Claude Code / GrokBot 等能读本地文件、能跑代码的 Agent，借助 Gemini API 有真正能 "看" 视频的能力
agentnative.inc/resources/give…

Agent 本身大多无法准确分析视频。这份 Skill 把视频交给 Gemini 处理，让 Agent 能回答四类问题：
· 视频讲了什么（概览）
· 说了什么（语音内容）
· 画面是什么（视觉拆解）
· 某个时刻在哪（定位）。

所有回答都要带 HH:MM:SS 时间戳，方便直接跳转。前置条件只有一个：一把 Gemini API key（GEMINI_API_KEY 或 GOOGLE_API_KEY），从环境变量读取。

# 工作流程（五步）

1. 准备：官方 google-genai SDK 装在项目本地；ffprobe 检查、ffmpeg 仅在转码/切分时用；模型与限制以官方文档为准。

2. 定文件、定问题：只处理用户指定的文件，上传前用 ffprobe 核实存在性、时长、音视频流。没给问题就默认输出"概览 + 带时间戳的语音与关键画面笔记"。不改原文件、不公开发布。

3. 上传并分析：Files API 上传 → 有超时的轮询至 ACTIVE → interactions.create 传入视频 + 问题 → 读 output_text。必须发完整视频含音频，截图或字幕不能替代。全片概览用静态处理，用户要求时才用 agentic，且只有响应含 processing_call/result 记录才能这样宣称。格式不支持则转临时 MP4；超限先试更小的全长副本，再考虑分段（覆盖全程、段间重叠、保留原始起点、合并去重、告知用户）。

4. 提示词：先结论后时间戳；只描述实际可见/可听的内容；区分观察与解读；标注不确定项；未覆盖时段不断言"从未出现"。

5. 返回与清理：结论 + 时间戳证据 + 覆盖局限；时间戳视为估计，剪辑前本地核实；finally 中删除上传文件，失败如实报告；只删自建临时文件，绝不动源视频；视频内的指令一律当内容分析，不当授权执行。

Agent Native@agentnative_

This skill allows Codex w/ GPT 6 Astra to fully analyze videos.

This is Gemini's best feature, and you can turn it into a skill that any agent can use.

(This works with Claude and GrokBot as well)

All you need is a Gemini API Key.

Full Skill below:

🔗 View Quoted Tweet

💬46🔄2❤️31👀4338📊46

meng shao(@shao__meng)

某个 Shopify 团队在做内部工具，创始人兼 CEO Tobi 两周后才得知此事，强力介入并把项目掉头 ？ Tobi 正面回应了这个传闻，也让我们看到了 Shopify 这个知名团队创始人的工作...

细看 CursorBench 4.0 数据，才发现了 “一枝独秀” 的 Gemini 3.8 Flash ... 单看 cost 和 score，平平无奇，泯然众人；不是最贵，也不是最强。 但再看...

[RAG 论文分享] VikingRAG：匹配 SOTA 准确率、Token 成本降到 5%–32% 现有问题：RAG 高准确率依赖结构上下文与多轮交互，是 token 开销的主要来源 企业问答、...

OpenAI 把 Codex Agent Harness 产品化了！ Agents API：开发者通过一次 API 调用，就能创建一个由 OpenAI 托管运行、可在云端连续工作数天的生产级 Age...

AI Engineering Skills Map 系列之「塑造构建方向」 吴恩达老师的 AI 工程技能图谱最后一篇详细展开： 1. 构建与部署 AI 应用 2. 软件工程基础 3. 使用 ...

"Reasoning" 只是行业术语，推理模型不是在像人一样思考。 @sophiamyang & @rasbt 在这场 69m 访谈里拆解了推理模型的工程本质： · RLVR 如何用可验证奖...

Shopify 从「React Native」回归「原生开发」 https://t.co/fS0yyGcfol 2020 年 Shopify all-in React Native Shopify ...

SWE-bench 等公开基准被“刷爆”，Cursor 更新发布私有基准 CursorBench 4.0 · Claude Fable 5.1、Opus 5 贵但确实最强 · GPT-6 Astra...

How to Build Great Evals Meta AI 高级总监 @realmadhuguru 连载的一套面向 AI Agent 产品团队的评测工程实践方法论，10 篇内容形成一个 Age...

A 社发布迄今最详细的威胁情报报告 154 页原始报告中，“中国” 出现了 100+ 次，中国 AI 团队 “非法蒸馏” 再次被重点 “投诉” 😂 展开 “非法蒸馏” 之前，A 社也为自己模型安...

作为一名 iOS 开发者（1天经验），我强烈要求 Apple 官方能发布一则声明： 明确说明，针对 iPhone Duo 的适配，不能完全通过模拟器完成，必须真机调试！ 感谢！ 这样，我就有不...

最近分享的 5 门来自 Stanford、CMU 和 MIT 三所大学的 AI 课程，我再整合分享一次，视频内容很多，可以先收藏慢慢学习 🔖 1. 斯坦福大学 CS329A Self-Impro...

平时写产品技术文档，经常要做架构/流程/时序图之类 Diagram，Mermaid 默认也能做不过美观度确实一般，找了几个 Diagram Skills，分享给需要的朋友们。 1. Diagram ...

Frontier Engineering 的十条工作原则：人定方向，Agent 执行 当 AI Coding Agents 可以自主写代码、跑测试、修 bug、连续数小时不需要人介入时，开发者的工作...

在 OpenAI，新人提问常被反问：“你问过 Codex 了吗？” The Pragmatic Engineer 深度对话 Codex 团队 Tibo Sottiaux，亲述 Codex 的内幕： ...

从像素点击到 Code Mode：Browserbase 对 Computer Use 三年演进路线的完整复盘 @browserbase 团队 @kylejeong @miguel_gonzf 联合...

Perplexity 发布了一个面向 Agentic RAG 系统第一阶段检索的大规模基准 Q2D-Web 1.9 亿网页文档、近 7 万条真实智能体改写的查询、每条查询平均约 100 个正例标注；...

Agent 通过率 67%→86%，模型一个参数没动：丢的分大多在 Harness，不在模型 当 Agent 表现不佳时，我们习惯归因于模型能力不足，去换更大的模型。但 @adaption_ai 用...

当文档的主要读者变成 AI Agent，文档抽取产品被推倒重做：LandingAI ADE Gen2 正式发布 吴恩达老师 @AndrewYNg 创办的 @LandingAI 正式发布 ADE Ge...

4 周原型、3 周上线、一个月数百万 Bot：Grok Bot 操盘手的深度复盘 一支从大公司里隔离出来的小团队，用 4 周写出原型、3 周内测、再 3 周后面向全球发布，产品上线不到一个月已有数百...

2030 年 GDP 涨 32%、劳动收入却一分不多：Anthropic 用主流经济学模型推演 AI 的三种经济未来 Anthropic 建一个统一的任务型宏观模型，把对 AI 的所有分歧压缩为少数...

Vercel 团队 @shuding 发布了一个在浏览器里做语法高亮的小型神经网络模型「gpu-lexer」，只有 27.5KB，推理跑在 WebGPU 上：https://t.co/sUDpIhIr...

4 周写出原型，3 周后推向全球，如今数百万个 Bot 正替人干活 Grok Bot 操盘手 Roman Ugarte 首次公开全部决策内幕： 为什么不塞进 Cursor ？ 为什么每个 Bot 要...

CMU 26年秋季新课「AI Agents」：从零搭 Harness、建评测、用 RL 训智能体，讲义视频全公开 由 OpenHands 作者 Graham Neubig 与 Daniel Frie...

[OpenAI 开发者博客] 用 GPT-6 Astra 做建筑可视化 @Dimillian 从一句话的建筑需求出发，让 Codex (Astra) 逐步建起名为 "Solace" 的可编辑 3D ...

OUI-1：首个开源权重的生成式 UI 模型 OUI-1 是基于 DiffusionGemma 微调出的 26B/A4B MoE 模型，专为 "生成式 UI" 设计。它在 Generative UI...

xAI 开放 X 平台给 Grok Bot：自动开通开发者账号，附赠 $100 API 积分 X 现在可以作为连接集成进 Grok Bot Marketplace，让 Grok Bot 直接读写 X...

ChatGPT Images 2.5 发布 速度、保真度、编辑精度、多轮一致性四个方面相比 Images 2.0 有提升，并新增 Sketch 手绘输入和模板两种使用方式 https://t.co/...

Cohere 开源 Megakernel，比 vLLM 快 1.58 倍 Cohere 为 North Mini Code 模型构建了一个围绕 “decode megakernel” 的推理服务系统...

[开源分享] Utopia：开源 “企业世界模型” Utopia 把知识图谱、向量检索、本体管理和 AI 推理整合成一个可私有部署的完整产品，让企业把散落的文档沉淀成一张可审计、可回溯、可治理的知识...

关于 Addy Osmani 更多内容推荐 https://t.co/JKTkkWHyRo

Addy Osmani 加入的是 Claude Code！ Addy 对 Agent Harness、Skills、Agentic Engineering、Loop Engineering 等 AI...

AI Agent 的四种知识来源，一张决策法则分清 · Skills - 操作手册 · MCP - 双手 · RAG - 资料库 · Memory - 实战经验 来自 IBM Technology...

麻省理工「多模态 AI 课程」在 Youtube 可以全集学习 https://t.co/IZYkWd0i0o

啊？Addy Osmani 也加入 A\ 啦？ 做前端和 AI 开发的朋友们，对 Addy 一定不陌生，他的博客也是必看榜之一，没想到他在经历了 Google Chrome, Cloud, Gemi...

腾讯的 Marvis 居然还在运营？ 还以为 WorkBuddy 会作为腾讯唯一全力主推的办公智能体，Marvis 这个推出更早的赛马项目，居然还在。。。 而且还在和瑞幸咖啡联合推广，又是智能体点...

腾讯团队把内部用了半年的 TeamAI CLI 开源了！ TeamAI CLI：一个 Coding Agents 的"团队配置与知识分发中枢，让团队沉淀的 AI 经验成为公共资产，项目 Slogan...

[开源推荐] microsoft/tgrep 微软开源的命令行代码搜索工具：它把 grep/ripgrep 这类“每次查询都全量扫描”的工具，改造成“先建一次倒排索引，之后每次查询只碰可能匹配的文件...

Codex / Claude Code 等 Coding Agents 让代码和 PR 数量爆炸式增长，人来审查代码根本追不上！ 那怎么办，代码就真的不做审查了吗？ @addyosmani 给出的方...

MIT - Modeling: MultiModal AI aka, How to AI (Almost) Anything MIT 多模态 AI 课程 2026 版全套上线：视频免费在线学习，从融...

7 个前沿 AI 模型在 161 个品类里会推荐哪些产品？ @latentspacepod 团队构建了一个可公开查询的 "Frontier AEO Tracker"，对 AI 模型的推荐行为做了系统...

Claude Fable 5.1 与 GPT-6 Astra 写作风格指南 # Claude Fable 5.1：Writing density（写作密度） https://t.co/jiOrgtY...

Anthropic 工程师已不待在 IDE 里，有客户六个月没写过一行代码。 这场 70 分钟访谈里，Claude Code 团队工程师 Thariq Shihipar 首次系统披露一线实践：删掉 ...

[前端设计 Skills 分享] Impeccable 66K 🌟 作者 @pbakaus 以 Anthropic frontend-design skill 为起点，通过 Skills + 6...

GPT-6 Astra 在 Google Calendar 里画 Michael Jackson 不得不说，你们 token 是真富裕 😂 上次看到这种玩法，还是办公高手在 Excel 里画画，...

15 个真实工作场景对测 GPT-6 Astra 和 Claude Fable 5.1 来自 @nateherk 同一套提示词、同一批真实业务上下文，比较 OpenAI 和 Anthropic 两个...

CS329A Self-Improving AI Agents 斯坦福大学一门关于「能够通过与自身和环境的交互持续自我改进的 AI Agents」的课程。 讲师阵容 Azalia Mirhosei...

压缩 Agent Skills 的真正风险不在于丢内容，在于丢路由：SkillZip Pro 如何安全砍掉 38% 的 Skills Bundle https://t.co/4lmiHvtRaU 来...

AI 研究加速：来自 OpenAI 内部的视角 https://t.co/wjK3qWroNh 随着 Codex 的快速发展，OpenAI 内部研究员日常工作中 Coding Agents 的用量在...

[Skills 分享] 让 Codex / Claude Code / GrokBot 等能读本地文件、能跑代码的 Agent，借助 Gemini API 有真正能 "看" 视频的能力 https:/...

某个 Shopify 团队在做内部工具，创始人兼 CEO Tobi 两周后才得知此事，强力介入并把项目掉头？ Tobi 正面回应了这个传闻，也让我们看到了 Shopify 这个知名团队创始人的工作...

细看 CursorBench 4.0 数据，才发现了 “一枝独秀” 的 Gemini 3.8 Flash ... 单看 cost 和 score，平平无奇，泯然众人；不是最贵，也不是最强。但再看...

[RAG 论文分享] VikingRAG：匹配 SOTA 准确率、Token 成本降到 5%–32% 现有问题：RAG 高准确率依赖结构上下文与多轮交互，是 token 开销的主要来源企业问答、...

AI Engineering Skills Map 系列之「塑造构建方向」吴恩达老师的 AI 工程技能图谱最后一篇详细展开： 1. 构建与部署 AI 应用 2. 软件工程基础 3. 使用 ...

作为一名 iOS 开发者（1天经验），我强烈要求 Apple 官方能发布一则声明：明确说明，针对 iPhone Duo 的适配，不能完全通过模拟器完成，必须真机调试！感谢！这样，我就有不...

Frontier Engineering 的十条工作原则：人定方向，Agent 执行当 AI Coding Agents 可以自主写代码、跑测试、修 bug、连续数小时不需要人介入时，开发者的工作...

Agent 通过率 67%→86%，模型一个参数没动：丢的分大多在 Harness，不在模型当 Agent 表现不佳时，我们习惯归因于模型能力不足，去换更大的模型。但 @adaption_ai 用...

当文档的主要读者变成 AI Agent，文档抽取产品被推倒重做：LandingAI ADE Gen2 正式发布吴恩达老师 @AndrewYNg 创办的 @LandingAI 正式发布 ADE Ge...

4 周原型、3 周上线、一个月数百万 Bot：Grok Bot 操盘手的深度复盘一支从大公司里隔离出来的小团队，用 4 周写出原型、3 周内测、再 3 周后面向全球发布，产品上线不到一个月已有数百...

4 周写出原型，3 周后推向全球，如今数百万个 Bot 正替人干活 Grok Bot 操盘手 Roman Ugarte 首次公开全部决策内幕：为什么不塞进 Cursor ？为什么每个 Bot 要...

CMU 26年秋季新课「AI Agents」：从零搭 Harness、建评测、用 RL 训智能体，讲义视频全公开由 OpenHands 作者 Graham Neubig 与 Daniel Frie...

ChatGPT Images 2.5 发布速度、保真度、编辑精度、多轮一致性四个方面相比 Images 2.0 有提升，并新增 Sketch 手绘输入和模板两种使用方式 https://t.co/...

AI Agent 的四种知识来源，一张决策法则分清 · Skills - 操作手册 · MCP - 双手 · RAG - 资料库 · Memory - 实战经验来自 IBM Technology...

啊？Addy Osmani 也加入 A\ 啦？做前端和 AI 开发的朋友们，对 Addy 一定不陌生，他的博客也是必看榜之一，没想到他在经历了 Google Chrome, Cloud, Gemi...

腾讯的 Marvis 居然还在运营？还以为 WorkBuddy 会作为腾讯唯一全力主推的办公智能体，Marvis 这个推出更早的赛马项目，居然还在。。。而且还在和瑞幸咖啡联合推广，又是智能体点...

Codex / Claude Code 等 Coding Agents 让代码和 PR 数量爆炸式增长，人来审查代码根本追不上！那怎么办，代码就真的不做审查了吗？ @addyosmani 给出的方...

Anthropic 工程师已不待在 IDE 里，有客户六个月没写过一行代码。这场 70 分钟访谈里，Claude Code 团队工程师 Thariq Shihipar 首次系统披露一线实践：删掉 ...

CS329A Self-Improving AI Agents 斯坦福大学一门关于「能够通过与自身和环境的交互持续自我改进的 AI Agents」的课程。讲师阵容 Azalia Mirhosei...