We are releasing updates to Veo 3.1 in the Gemini API, adding native vertical video, higher resolutions, and improved consistency.
- Improved character identity and background details.
- 9:16 vertical videos without cropping from landscape.
- Improved 1080p outputs and new 4K resolution video.
- Embeds SynthID digital watermarks for content verification.
- Now Available in @GoogleAIStudio, Gemini API, @GeminiApp & Vertex
“如何构建高准确率 AI 审查系统”的工程实践指南
Cursor 团队这篇文章，讲述了他们如何通过系统化的工程方法，构建并迭代自动代码审查工具 Bugbot。团队核心观点：构建一个好用的 AI Bug 检测器，不能只靠简单的提示词，而需要一个包含多轮验证、去噪和投票机制的复杂流水线。
核心目标：解决“狼来了”的问题
AI 代码审查工具最致命的问题是误报。如果 AI 总是对无关紧要的风格问题指指点点，或者标记出不存在的 Bug，开发者很快就会忽略它。 Cursor 的目标非常明确：只关注真正的逻辑 Bug，并追求极高的准确率，宁可漏报也不要误报。
技术解密：Bugbot 是如何工作的？
文章揭示了 Bugbot 能够达到高准确率的“秘密武器”——一个包含多个步骤的复杂流水线。这不仅仅是一次 API 调用，而是一个系统工程：
1. 并行多路检测（Parallel Detection）：
· Bugbot 不只看一遍代码。它会同时启动 8 个独立的检测进程。
· 关键创新： 每个进程看到的 Diff 顺序是随机打乱的。
· 原理： LLM 对上下文顺序敏感。通过打乱顺序，强制模型从不同角度“审视”代码，避免因阅读顺序导致的思维定势。
2. 聚类与投票（Clustering & Voting）：
· 将这 8 次检测发现的所有 Bug 收集起来，把相似的 Bug 归为一组。
· 多数决机制： 如果一个 Bug 只有 1 个进程发现，其他 7 个都没发现，它很可能是误报，直接丢弃。只有多个进程都“共识”的问题才会被保留。这是降低幻觉最有效的手段。
3. 合成与过滤（Synthesis & Filtering）：
· 将同一组的多个 Bug 描述合并成一个清晰的描述。
· 过滤掉非代码逻辑问题（如文档错误、编译器警告），专注于真正的代码缺陷。
4. 独立验证模型（Verifier Model）：
· 引入一个专门的“验证者模型”。它的任务不是找 Bug，而是拿着代码和刚才生成的 Bug 报告，去判断“这真的是个 Bug 吗？”
· 这是一个二次确认步骤，进一步清洗掉可能的误报。
5. 去重（Deduplication）：
检查这个 Bug 是否在之前的运行中已经报告过，避免重复骚扰用户。
数据驱动的进化
Cursor 团队强调，他们不再依赖“感觉”来优化产品，而是建立了一套数据驱动的评估体系。
· 指标提升： 经过 40 次重大实验迭代，Bugbot 的“解决率”从 52% 提升到了 70% 以上。
· 召回提升： 每个 PR 平均发现的 Bug 数量从 0.4 个提升到了 0.7 个。这意味着它不仅更准了，而且能发现更多问题。
Cursor now catches 2.5x as many real bugs per PR.
More on how we build and measure agents for code review: cursor.com/blog/building-…
Google 发布了更新版 Veo 3.1。
这是 Google 第一次让“AI 视频真正可控”的一次更新。
在 Flow 里可以实现角色/品牌的一致性输出，支持 1080p/4K。
如果你在做广告或短视频内容：这是值得围绕它搭建生产流水线的一次升级。
Rules、commands、MCP servers、subagents、modes、hooks、skills... 这么多名词，到底都是什么，什么时候该用什么？看看 @leerob 的分析。
Lee 把这些功能的发展历程按时间线展开，解释了它们几乎都是为了解决早期 AI Agent 的几个核心痛点：
· 模型容易产生幻觉
· 上下文窗口被无关信息撑爆
· 工具调用不可靠
· 工作流难以重复和分享
· 特定任务需要更可靠、可发现的行为
他最终把所有概念简化为两大类：
· 静态上下文 → 主要靠 Rules 实现，始终包含在每一次对话中
· 动态上下文 → 主要靠 Skills 实现，只在需要时加载，避免浪费 token
他强烈建议：绝大多数开发者把主要精力放在高质量的 Rules 和 Skills 上就够了，其他高级功能可以按需使用。
再来看看这些概念的解释 🔽
1. Rules
最早出现，为了对抗幻觉，把代码库规范、业务规则、重要文件路径等“永远要记住的信息”强行塞进系统提示词。 → 演变为“静态上下文”的代名词。
建议：保持精简、高质量，像维护“活文档”一样；Agent 每次犯错，就去更新规则文件，让它逐步进化。
2. Conditional Rules
希望只在相关文件打开时才加载对应规则，但当时模型工具调用能力太弱，经常判断错误，所以暂时搁置，后来被更成熟的机制取代。
3. Commands / Slash Commands
把重复出现的提示词或完整工作流（例如“写完代码 → git commit → 创建 PR”）打包成可重复触发的快捷方式。 可以分享、通过 git 同步，很实用。
4. MCP Servers
让 Agent 能真正“做事”：执行代码、调用外部 API、读 Slack 消息、创建 Linear ticket、OAuth 授权等。 本质是给模型暴露“第三方工具”。
早期问题：加载太多工具描述会撑爆上下文 → 后来优化为“只在用到时加载工具描述”。
现在 MCP 主要用于需要复杂认证的场景，其他情况 Skills 已能覆盖大部分需求。
5. Subagents & Modes
· Subagents = 给 Agent 套上特定“人设”+严格限制工具范围（比如只允许读文件、不允许写），让它在研究、规划等任务上更可靠。
· Modes = 在 UI 层面切换“频道”，修改系统提示词、添加专用界面（比如规划画布）、显示提醒。
目标：提高可发现性（用户一看就知道能用什么模式）和可靠性。
6. Hooks
提供 100% 确定性的行为，例如：对话前强制注入某段上下文、对话后自动把结果记到数据库。 适合需要严格一致性的场景。
7. Skills
Lee 认为这是目前最重要、未来增长最快的方向，也是开放标准。
· 基础版：类似高级 Commands，可重复的工作流。
· 高级版：打包代码、脚本、资产，甚至小项目模板，按需加载，不占初始上下文。
· 优势：全局可共享（~/.cursor/skills）、团队协作友好、上下文高效。 他预测未来几个月会出现丰富的 Skills 生态。
Rules, commands, MCP servers, subagents, modes, hooks, skills...
There's a lot of stuff! And tbh it's a little confusing.
Here's what you need to know (and how we got here).
让 AI解读下Anthropic的组织构建调整。
他们把产品团队拆成两条线:
Labs 团队专门折腾新东西。
Instagram 联合创始人 Mike Krieger 加入这个团队，与 Ben Mann 一起工作。
Instagram 当年也是从一个滤镜 app 长成十亿用户巨兽,
"从小实验长成大产品"的经验，正是 Anthropic 现在需要的。
Product 团队负责把验证过的功能做稳。
新来的 Ami Vora 带队，确保几百万用户每天用的 Claude 不出岔子。
强化类似 Claude Code 的产品演化路径:
6 个月前还是研究预览版，现在是十亿美元级的产品，逻辑：
1. 先做个粗糙版本给早期用户试
2. 看哪些功能真的有人用
3. 把有用的快速打磨成产品
4. 规模化推广
MCP(模型上下文协议)也是这么起来的，现在每月 1 亿次下载,成了行业标准。
为什么这个时候做这个调整?
CEO说 AI 发展太快了，传统的产品开发方式跟不上。
按传统软件公司的节奏——立项、调研、开发、测试、发布，等你走完流程，模型可能已经迭代三个版本了。
他们需要两种速度:
① Labs 用"实验速度"探索边界
② Product 用"工程速度"保证质量
Anthropic 让不同的团队用不同的节奏和方式工作。
原文见评论区
来自 @addyosmani 和 @svembu 的讨论，指出了 AI Agents 带来的一个核心矛盾：
短期：AI Agents 带来效率提升
长期：会破坏长期的人才培养机制，导致人才断层
他们的解决方案：必须在 AI 辅助的工作流中，重新设计出能够通过“刻意练习”培养下一任架构师的机制！
核心矛盾：效率优化 vs. 人才梯队
Sridhar Vembu 提出了问题的起点：AI 确实能让资深架构师更高效，并减少对初级工程师执行力的需求。但这引出了一个悖论——如果初级岗位消失，未来的资深架构师从何而来？毕竟，没有人能够跨越初级阶段直接成为专家。
Addy Osmani 的回复则是对这一悖论的深入剖析。他指出，如果我们只为了追求今天的代码产出率（生产力），而牺牲了初级工程师的成长路径，实际上是在 “透支未来” 。
专业视角下的核心洞察
Addy 的论述可以从以下三个专业维度进行解读：
A. “隐性知识”的断层
· 观点：AI 可以生成代码，但无法传递“隐性知识”。
· 解读：软件工程不仅是编写语法正确的代码，更包含了对架构模式的识别、对技术决策次生影响的预判，以及在信息不完整情况下的直觉判断。
· 分析：这些能力通常被称为“肌肉记忆”，是在无数次试错、Debug 和代码审查中积累起来的。如果初级工程师变成了单纯的“AI 监工”（只负责验收结果），他们就失去了通过“刻意练习”构建这些认知的过程。
B. “监管者”不等于“架构师”
· 观点：跳过“一万小时”的练习，直接进入“监管 AI 输出”的阶段，培养不出真正的架构师。
· 解读：这里提出了一个深刻的身份危机。能够审查 AI 生成的代码，并不代表理解了系统底层的逻辑。
· 风险：这种模式下成长起来的开发者，容易出现“达克效应”——因为不知道自己不知道什么，从而对 AI 的盲目自信。一旦遇到 AI 无法解决的复杂系统性故障，他们将束手无策。
C. 人才培养路径的“定义缺失”
· 观点：业界常说“初级工程师以后会做不同的工作”，但目前尚无共识这具体是什么工作。
· 解读：这是一个行业的结构性迷茫。如果初级工程师不再是负责写基础功能模块，那么他们的新职责（如 Prompt Engineering 或调试 AI 代码）是否具备向上兼容的技能属性？
· 分析：如果新的工作内容无法积累为“架构能力”，那么职业发展的阶梯就断了。
提出的解决方案：Trio-Programming（三人编程模式）
Addy 并非单纯的悲观者，他给出了一个具体的组织演进建议：Trio-Programming（三人组编程）。
· 定义：Senior + Junior + AI。
· 核心逻辑：
· 不是简单的让初级工程师去用 AI，而是强调资深工程师的介入。
· 资深工程师将“指导”视为一种 “能力倍增器” ，而非降低自身效率的负担。
· 意义：在这种模式下，初级工程师不再是单纯地执行任务，而是在资深人员的带领下，学习如何驾驭 AI、如何评估 AI 的产出质量。这是为了在利用 AI 的同时，保留人类传递经验和判断力的渠道。
宏观警示：避免“领导力真空”
Addy 最后的警告是对企业管理层的直接喊话：
· 短期主义陷阱：如果企业仅以“每行代码的成本”作为优化指标，大规模削减初级岗位或缩减培养成本。
· 长期代价：5 到 10 年后，当现有的资深架构师退休或离职，市场上将出现严重的 “领导力真空” 。企业将发现自己拥有一堆能跑的代码，却找不到真正懂系统、能做关键决策的人来维持技术演进。
AI amplifies senior expertise but may starve the junior pipeline that creates it. That is, if we only optimize for today's productivity vs. the long-term.
The muscle memory of fields like software engineering develops through repetition and guided practice.
Knowing when to trust your instincts. Recognizing antipatterns. Understanding second-order consequences of technical decisions.
AI agents can generate code, but can't transfer the tacit knowledge that separates someone who can review AI output from someone who can architect systems.
What worries me is if we skip the "10,000 hours of practice" phase and jump straight to "overseer of AI output," are we actually training architects? Or are we training people who don't know what they don't know?
The industry keeps saying "juniors will do different work now." but there isn't yet alignment about what that work actually is, how it builds toward senior capabilities, or whether it creates the judgment AI assistance assumes you already have.
Maybe the resolution isn't either/or. Maybe it's hybrid pair-programming where juniors work alongside AI but with better senior oversight and deliberate skill-building, not just task completion.
You could call it trio-programming. Seniors who see mentorship as force multiplication but not a tax on their productivity.
If companies optimize purely for cost-per-line-of-code today, we'll pay for it in a leadership vacuum in the coming years. I hope we're more mindful of the future than that.
Claude Code 的创建者 Boris Cherny 今天发了一组推文，用一个故事解释了 Anthropic 新产品 Cowork 为什么会诞生。
【1】从“没人会用”到“同事已经在用了”
2024 年底，Boris 刚把 Claude Code 的第一版（当时叫 Claude CLI）发布给团队内部试用。那时候 Sonnet 3.5 的 agent 能力还很弱，他前一天才刚给它加了一个文件编辑工具，自己也只拿它当个记事本用。
第二天走进办公室，他看到同事 Robert 的屏幕上开着终端，Claude CLI 正在运行，旁边是一个红绿色的代码 diff 视图。
Robert 已经在用它写代码、操作 git 了。
【2】然后是数据科学家
几个月后，Anthropic 的工程师们已经日常使用 Claude Code。有一天 Boris 走进办公室，看到数据科学家的电脑上也开着 Claude Code 终端。他问了一句“你也在试这个？”，结果发现对方不是在试用，而是在干活——用它写 SQL 查询、做数据分析、画 matplotlib 图表，甚至用 ASCII 字符在终端里画简易图表。
Claude Code 是给工程师做的，数据科学家却拿它来工作。
一周后，整排数据科学家的屏幕上都是 Claude Code。
【3】接着破圈了
随后几个月，同样的事情反复上演。设计师用它做原型和改文案，财务用它建模型、做预测，销售用它分析 Salesforce 和 BigQuery 里的数据，用户研究员用它处理问卷结果。
到现在，用户用 Claude Code 做的事情已经远远超出编程范畴：控制烤箱、从坏掉的硬盘里恢复婚礼照片、分析自己的 DNA 和医疗记录、跟客服讨价还价。
【4】所以有了 Cowork
Boris 说，到某个时刻，这些事情就不再让他惊讶了。“我们应该让那些想用 Claude agent 做非编程事情的人更容易上手”——这变得显而易见。于是就有了今天发布的 Cowork。
他在推文里还说了一句话：“产品还早期，还不够完美，但人们已经发现它在各种意想不到的场景下极其好用。”
这话听着像自谦，其实是 Anthropic 做产品的一贯风格：先发布、先让用户玩起来、再根据反馈迭代。Claude Code 就是这么长大的。
【5】AI agent 正在从程序员玩具变成通用工具
Claude Code 最初只是给工程师用的命令行工具，但它的本质是自然语言交互——你告诉它要做什么，它帮你执行。这个能力跟你会不会写代码没关系。数据科学家能用，财务能用，设计师也能用，只是原来的界面对他们不够友好。
Cowork 做的事情，就是把这个能力包装成更多人能接受的形态。
Anthropic 的产品嗅觉：不是先想“我们要做一个面向非程序员的产品”，而是观察到用户已经在这么用了，然后顺势而为。用户行为是最好的产品经理。
It's late 2024, a few days after I launched the first version of Claude Code (then called Claude CLI) to team dogfooding. I walked into the office and saw my coworker Robert with a terminal up on his computer, Claude CLI running and a red/green diff view on screen.
I was surprised. This was back in the Sonnet 3.5 days, before the model was good at agentic coding. I had just given it a FileEdit tool the day before. Claude CLI was a prototype that I thought it wasn't useful for anything yet. But Robert was already starting to use it to write code & use git for him. I was still using the CLI as a note taker mostly, but I also started making it my go-to tool for using git as a result.
The funny thing about "AI slop" is that it's insanely smart.
These videos are reward hacking human attention much more effectively than trad entertainment companies and even UGC like TikTok.
The barrier to content creation is near zero, so the iteration speed is insanely fast.
Today we’re announcing Open Responses: an open-source spec for building multi-provider, interoperable LLM interfaces built on top of the original OpenAI Responses API.
✅ Multi-provider by default
✅ Useful for real-world workflows
✅ Extensible without fragmentation
Build agentic systems without rewriting your stack for every model: openresponses.org
ChatGPT Go is rolling out globally in every country where ChatGPT is available.
ChatGPT Go is our low-cost subscription tier that gives you 10x more messages, file uploads and image creation vs free tier, more memory, longer context window, and unlimited use of GPT 5.2 instant for $8 USD/month.
openai.com/index/introduc…
