OpenAI 推出免费的 LaTeX 原生工作空间 Prism，并集成 GPT-5.2
OpenAI 发布了Prism，这是一个基于云的免费 LaTeX 工作空间，专为学术写作和协作而设计，并且直接集成了 GPT-5.2。该平台将文档编辑、编译、引文管理及 AI 辅助修订功能整合在单个基于 Web 的工作区中，主要面向需要撰写长篇科学文献的研究人员。 Prism 完全支持 LaTeX 原生操作，并且是完全在浏览器中运行。用户可以创建、编译和预览文档，无需安装本地工具或管理 LaTeX 环境。该平台消除了现有 LaTeX 协作工具中常见的限制，对项目数量、协作者数量或编译时间没有任何限制。 Prism 的核心优势在于将 GPT-5.2 集成到了文档工作流中。与通过单独的聊天界面操作不同，该模型直接在项目的上下文中运行，可以访问文档结构、公式、参考文献和之前的修订。这使得它能够协助执行诸如修订文本、调整格式、更新公式和表格以及查找相关文献这样的任务，同时保证文档内部逻辑的一致性。 Prism 内置了引文管理功能，并支持与 Zotero 同步以发现参考文献。实时协作功能允许多个作者同时编辑文档，内联评论和专题讨论支持同行评审和反馈。自动化错误检查、公式转换和格式化工具旨在减少手动更正和重复的 LaTeX 调整。 本次发布在研究人员中间引发了关于 Prism 与 Overleaf 等工具的对比讨论。Povilas Karvelis指出： 我认为这种情况还会持续几年，直到知识图谱和 AI 代理成为主要的研究手段，使精心撰写的研究论文彻底过时。 其他早期用户强调了该平台的定价模型所带来的实际影响。一位研究人员评论道： 集成 AI 是 Prism 提供的功能中最不实用的。仅仅是让我可以免费拥有无限数量的项目和协作者，就使它成为比 Overleaf 更好的选择。 从技术的角度来看，Prism 的定位是一个集成的写作和协作环境，而不是一个 AI 优先的工具。AI 辅助功能是可选的，并且嵌入到了标准的学术工作流中，团队可以有选择地使用。核心功能的使用不依赖自动化辅助。 目前，拥有 ChatGPT 个人账户的用户可以通过 Web 访问 Prism。OpenAI 表示，未来版本将陆续支持 ChatGPT 商业版、团队版、企业版及教育版。 原文链接：https://www.infoq.com/news/2026/01/openai-prism/
现在做需求已经不是先想代码怎么写，而是先想怎么 prompt 了预估工时也不再是代码编写的时间，而是 Agent 多久能跑完，代码的生产速度≈Token 的生成速度gpt-5.2 真是一个靠谱的伙伴，基本上每次 prompt 都能拿到预期的结果BTW, codex-viz 是我 vibe coding 的一个统计 codex 本地用量的工具，有需要的可以自取 https://github.com/onewesong/codex-viz
📌 本文适用于已安装 ClawdBot 用户，介绍如何修改配置以接入 HodlAI 接口。详细安装教程请自行搜索，或借助 AI 指导，后续我们也将推出完整版教程。配置步骤1️⃣ 编辑配置文件使用任意编辑器打开 clawdbot.json：nano ~/.clawdbot/clawdbot.json 2️⃣ 替换配置内容将 models 和 agents 部分替换为以下内容：⚠️ 如需更换模型，请同步修改所有 gpt-5.2 相关字段（id、name、primary、models）"models": { "mode": "merge", "providers": { "llm": { "baseUrl": "https://api.hodlai.fun/v1", "apiKey": "你的 API Key", "api": "openai-completions", "models": [ { "id": "gpt-5.2", "name": "GPT-5.2", "reasoning": true } ] } } }, "agents": { "defaults": { "model": { "primary": "llm/gpt-5.2" }, "models": { "gpt-5.2": {} }, "workspace": "/root/clawd", "compaction": { "mode": "safeguard" }, "maxConcurrent": 4, "subagents": { "maxConcurrent": 8 } } } 3️⃣ 校验并重启服务clawdbot doctor --fix clawdbot gateway restart 关于 HodlAI持有 $HODLAI 代币，即可免费使用 200+ AI 模型📋 完整模型列表：https://api.hodlai.fun/pricing相关链接 平台 链接 🌐 官网 https://hodlai.fun/ 🐦 Twitter https://x.com/hodlai_bsc 💬 Telegram https://t.me/hodlai_fun
阿里发布 Qwen3-Max-Thinking；阶跃星辰获超 50 亿融资，加速推进「AI 进入物理世界」丨日报
开发者朋友们大家好：这里是 「RTE 开发者日报」 ，每天和大家一起看新闻、聊八卦。我们的社区编辑团队会整理分享 RTE（Real-Time Engagement） 领域内「有话题的 技术 」、「有亮点的 产品 」、「有思考的 文章 」、「有态度的 观点 」、「有看点的 活动 」，但内容仅代表编辑的个人观点，欢迎大家留言、跟帖、讨论。本期编辑：@瓒an、@鲍勃01 有话题的技术1、阿里发布万亿参数模型 Qwen3-Max-Thinking，性能对标 GPT-5.2昨天，阿里正式发布千问旗舰推理模型 Qwen3-Max-Thinking。该模型总参数量超万亿（1T），在多项权威评测中刷新全球纪录，官方宣称其性能媲美 GPT-5.2、Gemini 3 Pro，是迄今为止最接近国际顶尖水平的国产 AI 大模型。Qwen3-Max-Thinking 的预训练数据量高达 36T Tokens，并在预览版基础上进行了更大规模的强化学习后训练。在涵盖事实知识、复杂推理、指令遵循等 19 个基准测试中，该模型刷新了数项最佳表现（SOTA）纪录。根据官方公布的评测数据，Qwen3-Max-Thinking 在启用 TTS（Test-time Scaling）机制后，在科学知识（GPQA Diamond）测试中得分 92.8，略高于 GPT-5.2 的 92.4；在数学推理（IMO-AnswerBench）和代码编程（LiveCodeBench 2025.02-2025.05）中分别取得 91.5 和 91.4 的高分，均优于 GPT-5.2、Claude Opus 4.5 和 Gemini 3 Pro。特别是在启用工具的「人类最后的测试」（Humanity's Last Exam with Search）中，该模型得分为 58.3，大幅领先 GPT-5.2-Thinking 的 45.5 分，录得当前所有模型的最高分。技术层面，阿里表示 Qwen3-Max-Thinking 采用了一种全新的测试时扩展机制。 与业界普遍的简单增加并行推理路径不同，新机制能对此前推理结果进行「经验提取」式的提炼，通过多轮自我迭代在相同上下文中实现更高效的推理计算。此外，模型大幅增强了自主调用工具的原生 Agent 能力。 经过基于规则奖励与模型奖励的联合强化学习训练，模型可自适应选用搜索、个性化记忆和代码解释器等核心工具，不仅回答更流畅，还大幅降低了模型幻觉。目前，普通用户可通过千问 PC 端和网页端免费试用新模型，千问 App 也即将接入；企业开发者则可通过阿里云百炼获取 API 服务。体验链接Qwen Chat: https\://chat.qwen.ai/阿里云百炼：https\://bailian.console.aliyun.com/cn-beijing/?tab=model#/model-market/detail/qwen3-max-2026-01-23( @APPSO)2、打通感知、交互与执行：讯飞星辰升级多模态全栈能力，加速智能体规模化落地1 月 26 日，讯飞星辰智能体平台官宣重大升级，实现了讯飞星辰智能体平台和 AIUI 开放平台完全打通、升级超拟人交互技术、支持快速定制音色、RPA 升级，提供一套全面且完整的多模交互解决方案，让智能体拥有更全面的类人化交互能力、全场景执行能力。AIUI 开放平台接口打通 ：支持在「讯飞星辰」创建智能体并一键发布至 AIUI，实现语音交互与机器人动作规划（如桌面机器人绘本生成、运动轨迹）的同步调用与快速集成。秒级「一句话声音复刻」 ：利用超拟人交互技术，支持通过自然语言描述声线并在几秒内合成 4 个候选音色；支持中英日韩粤等多语种、方言及多风格（新闻、交谈、绘本）音色生成。单图构建多模态数字分身 ：支持通过一张照片快速生成数字人，其口型、表情及动作由大模型自动驱动；结合多模态视觉理解，支持智能体实现主动迎宾与环境感知的交互闭环。RPA 执行能力组件化 ：升级网页自动化智能组件，支持非专业开发人员通过低代码配置参数进行流程编排；提供开源可视化数据表格功能，实现数据提取与处理过程的透明化。最直观的一个例子就是，将 为智能体定制声音的时间压缩到了几秒钟 。发布会的实际演示中，操作人员在讯飞星辰智能体平台生成了曹操人格的智能体后，通过自然语言描述想要的音色声线、输入试听文本、点击生成，就在几秒内合成 4 个候选音色。接着选择保存、应用音色后，用户就能与刚刚的曹操人格智能体进行语音聊天。这是讯飞星辰智能体平台此次升级的一个缩影，而智能体的未来形态，将从单一工具，升级为兼具感知、交互能力，拥有专属声音、形象与性格人设，还能自主完成操作执行的全能型智能体，驱动这一切进化的核心，正是多模交互技术。当前海内外大厂与科创企业均在智能体平台赛道加速布局、密集发力，但行业仍普遍面临技术落地难、场景适配不深的核心痛点。讯飞星辰智能体平台此次实现感知、交互、执行三大核心能力的一体化整合，从底层打破智能体落地过程中的技术协同壁垒，直面其场景适配难题，为智能体技术的规模化落地扫清关键障碍。简言之，讯飞星辰智能体平台此次升级，核心便是瞄准降低智能体开发门槛、丰富其可落地的能力边界两大核心目标，在扩展服务能力的基础上，还提供了低代码、一键接入、快速接入等快速开发部署工具。总的来看，当前智能体产业技术成熟度足够支撑场景落地，市场需求旺盛，但落地效率与成本仍是核心瓶颈，而打通场景适配、能力集成、生态协同的全栈能力，将成为智能体产业竞争的核心壁垒。相关链接：https\://agent.xfyun.cn（@智东西、@讯飞开放平台）3、Google 支付 6800 万美元和解金，解决语音助手「监视」用户的指控据路透社报道，Google 已同意支付 6800 万美元，以解决一项指控其语音助手非法监视用户、并利用相关数据投放广告的索赔诉讼。Google 在这项集体诉讼的和解协议中并未承认存在任何不当行为。该诉讼指控 Google「在未经个人同意的情况下，非法且故意地拦截并录制个人的机密通信，并随后将这些通信未经授权地披露给第三方。」诉讼进一步声称，「从这些录音中收集的信息被错误地传输给了第三方，用于定向广告及其他目的。」该案件的核心争议集中在「错误唤醒」上，即指控 Google Assistant 即使在用户未通过唤醒词有意触发的情况下，也会自动激活并录制用户的通信内容。TechCrunch 已就此联系 Google 寻求置评。长期以来，美国民众一直怀疑电子设备在不适当地监视他们，这些怀疑正日益转化为法律诉讼。2021 年，苹果公司曾同意支付 9500 万美元，以解决关于其语音助手 Siri 在未获用户提示的情况下录制对话的类似指控。与其他科技巨头一样，Google 近年来也面临着多起隐私相关的诉讼。去年，该公司同意向得克萨斯州支付 14 亿美元，以解决两起指控其违反该州数据隐私法的诉讼。( @TechCrunch)02 有亮点的产品1、249 元起，苹果推出升级版 AirTag，精确查找范围扩大 50%昨天，苹果突然官宣，正式推出新款 AirTag，采用与 iPhone 17 系列、iPhone Air、Apple Watch Ultra 3 及 Apple Watch Series 11 相同的第二代超宽带芯片，在连接范围、精确查找能力与扬声器音量方面均进行了大幅升级：精确查找范围最高提升 50%，定位更快更准蓝牙连接范围扩大，远距离也能找到扬声器音量提升 50%，提示音更响亮支持 Apple Watch 精确查找，查找场景更丰富「查找」网络升级，脱离配对设备也能回传位置防追踪机制强化，跨平台警报更可靠支持共享物品位置，协助航空公司找回延误行李外壳与磁铁采用高比例再生材料，更环保新款 AirTag 已正式开售。售价方面，单件装售价 249 元，四件装售价 849 元，并提供免费镌刻服务。零售店将于本周晚些时候陆续上架。与此同时，苹果今天还推送了 iOS、iPadOS 和 watchOS 26.2.1，主要更新内容是新增对 AirTag 2 的支持。( @APPSO)2、京东「抢跑」淘宝，首款智能眼镜购物应用落地乐奇 Rokid1 月 26 日消息，京东科技购物智能体 JoyGlance 正式登录智能眼镜品牌乐奇 Rokid，标志着行业首款智能眼镜购物应用正式落地，是京东布局「具身智能消费场景」的关键一步。用户只需将 Rokid 眼镜系统更新至最新版本，应用由京东自研大模型 JoyAI 驱动，深度融合 Rokid 在光波导显示、远场语音交互与自研操作系统上的硬件能力，将传统网购流程从「搜索—浏览—比价—下单—支付」五步，压缩为极简的 「说、看、付」三步 。据悉，2025 年 10 月，Rokid 乐奇与京东科技就达成战略协议。此次携手，不仅是技术突破，更是消费入口的迁移，开启全球首个「所见即购买」的智能眼镜全链路购物入口，实现「目光所及、皆可购买」 。当购物从「指尖滑动」转向「目光注视」，智能眼镜正从可穿戴设备升级为下一代空间计算与消费交互终端。用户不再依赖搜索框或直播链接，而是将物理世界直接转化为购物入口，或为电商行业开辟了全新的场景。（@即智 Ultra）3、LiveTok 发布「LiveTok Avatars」：支持单张照片生成实时交互式 AI 数字孪生LiveTok 推出基于 AI 的虚拟助手平台「LiveTok Avatars」。该产品支持通过单张静态照片构建具备实时音视频交互能力的数字分身，旨在通过拟人化的「数字孪生」替代传统文字客服，实现 24/7 的实时客户互动。单图驱动数字孪生 ：用户仅需上传单张人物照片，AI 即可生成具备面部动态的克隆形象，无需复杂的视频采集。行为与语调克隆 ：AI 模型通过学习可复刻特定个体的说话风格、语速及特定动作习惯，提供具备自然停顿的类人语音响应。低代码 Web 集成 ：支持通过嵌入数行代码直接在网站部署，无需复杂的后端环境配置。实时音视频同步 ：提供低延迟的实时语音对话环境，演示版本目前支持单次最高 2 分钟的交互。目前处于 Beta 测试阶段，提供免费起步版，特定「数字孪生」功能需申请加入 Waitlist。相关链接：https\://www.livetok.ai/products/avatars( @LiveTok)4、阶跃星辰获超 50 亿人民币融资，印奇出任董事长昨天，大模型创业公司阶跃星辰（StepFun）完成超 50 亿人民币 B+ 轮融资，创下过去 12 个月大模型赛道单笔最高融资纪录。上国投先导基金、国寿股权、浦东创投、徐汇资本、无锡梁溪基金、厦门国贸、华勤技术等产业投资方参与本轮融资，腾讯、启明、五源等老股东继续加码。本轮资金将主要用于基础模型研发，并加速「AI + 终端」战略落地。同日，阶跃星辰宣布千里科技董事长印奇正式出任公司董事长，全面负责公司战略节奏与技术方向。 印奇此前已深度参与阶跃星辰的战略规划，其加入被视为公司在大模型「季后赛」阶段强化产业落地能力的关键一步。这笔融资规模不仅超过月之暗面此前宣布的 5 亿美元 C 轮，也高于智谱与 MiniMax IPO 募资额，成为近期 AI 资本市场最受关注的事件之一。过去两年间，该团队在「百模大战」中突围，跻身国内大模型第一梯队，并持续坚持预训练路线，构建了覆盖语言、多模态、音频、动作等方向的完整模型矩阵。印奇的加入补足了阶跃星辰在产业落地上的关键能力。作为旷视科技联合创始人，印奇在 AIoT、城市级物联网系统等领域拥有丰富经验，其长期关注的「AI+终端」路径也与阶跃星辰的战略方向高度一致。在商业化方面，阶跃星辰已与国内六成头部智能手机品牌达成深度合作，模型装机量突破 4200 万台，覆盖 OPPO、荣耀、中兴等品牌，日均服务用户达 2000 万人次；在汽车领域，公司与千里科技、吉利合作，将端到端语音模型集成至智能座舱系统，吉利银河 M9 上市 3 个月销量接近 4 万辆，阶跃星辰今年的车载模型装车目标为百万级；在技术路线方面，阶跃星辰坚持「原生多模态」策略，直接从图文交错语料进行端到端训练，以提升模型对物理世界的理解能力。其音频模型 Step-Audio-R1.1 通过 MGRD 技术在权威榜单 Artificial Analysis 上取得全球第一。印奇的加入意味着阶跃星辰将加速推进「AI 进入物理世界」的战略，并在手机、汽车等消费终端形成更具确定性的商业闭环。( @APPSO)03 有态度的观点1、俞敏洪：AI 或消灭大量教师岗位，中小学教师「一大半是不合格的」据快科技报道，新东方创始人俞敏洪近日在今年崇礼论坛上围绕互联网与人工智能对教育行业的影响发表最新观点。他指出，技术变革正推动教育从「一张嘴一块黑板」到「互联网 + 教育」，再迈向「AI + 教育」，并强调这一趋势将深刻改变教师岗位结构。俞敏洪表示，互联网仍在人类可控范围内，但其带来的舆论放大效应已深刻影响个人生活。他提到，过去三年遭遇的网暴与互联网环境密切相关。相比之下，人工智能的影响更具结构性，其在教育、医疗、生物等领域的应用将持续扩大。在教育场景中，他认为 AI 已能完成接近 100% 的英语交流与作业批改，不仅提升效率，也减轻学生面对老师时的心理压力。他指出，AI 的普及可能会「消灭大量老师岗位」，因为基础知识传递正被技术快速替代。他进一步强调，未来教师的核心价值将转向激发学生潜能、塑造人格与引导成长，这些能力无法被技术替代。按照这一标准，他直言目前国内中小学教师「一大半不合格」，部分教师面对学生提问时因无法回答而迁怒学生的现象亟需改善。俞敏洪还回顾新东方在「互联网 + 教育」时代的结构性变化：互联网放大名师影响力，使大量优秀教师离开线下课堂，包括他本人也不再走进教室授课。他认为，AI 的到来将带来更深层次的行业重塑，对教师提出更高要求，而这些要求比以往更难达到。他强调，人工智能的最终走向取决于使用者，而非技术本身，教育行业需要在技术变革中重新定义教师角色与价值。( @APPSO)阅读更多 Voice Agent 学习笔记：了解最懂 AI 语音的头脑都在思考什么写在最后：我们欢迎更多的小伙伴参与 「RTE 开发者日报」 内容的共创，感兴趣的朋友请通过开发者社区或公众号留言联系，记得报暗号「共创」。对于任何反馈（包括但不限于内容上、形式上）我们不胜感激、并有小惊喜回馈，例如你希望从日报中看到哪些内容；自己推荐的信源、项目、话题、活动等；或者列举几个你喜欢看、平时常看的内容渠道；内容排版或呈现形式上有哪些可以改进的地方等。作者提示: 个人观点，仅供参考​
Altman 承认“搞砸了”！曝 GPT-5.2 牺牲文采换顶级编程，明年成本降 100 倍，实锤 Agent 已能永久干活
在 AI 圈，Sam Altman 的每一次发声都被视为对未来“天气预报”的更新。 昨晚，Altman 在 X 上发帖称将举办一场线上研讨会，希望在开始构建新一代工具之前收集大众的反馈和意见。北京时间今早 8 点，这场由 OpenAI CEO Sam Altman 发起的研讨会如约而至。来自各行业的创业者、CTO、科学家和开发者社区的代表，围绕 AI 的未来形态、模型演进、智能体（Agent）、科研自动化以及安全问题，向 Altman 提出了最尖锐、也最现实的问题。 研讨会上，这位 OpenAI 的掌舵人不仅勾勒了 GPT-5 及其后续版本的进化蓝图，同时揭示了一个令所有开发者和创业者不得不面对的现实：我们正在进入一个智力成本极低、软件形态从“静态”转向“即时生成”的剧变期。 会谈的第一个焦点，落在了 GPT-5 性能表现的“非对称性”上。有开发者敏锐地察觉到，相较于 GPT-4.5，新版本在逻辑推理和编程上极强，但在文采上似乎略逊一筹。对此，Altman 表现出了极高的坦诚。 他承认，OpenAI 在 GPT-5.2 的研发中确实“搞砸了”写作能力的优先级，因为团队将有限的算力资源倾斜在了推理、编码和工程能力这些硬核智力指标上。 在 Altman 看来，智力是一种“可塑的资源”，当模型具备了顶级的推理引擎，写作能力的回归只是时间问题。这种“偏科”实际上反映了 OpenAI 的某种战略重心：先通过 Scaling Law（规模定律）攻克人类智力的最高地带，再回头去填补审美和表达的细节。这意味着，未来模型的竞争将不再是单一维度的比拼，而是看谁能更早地在全维度上实现“智力平权”。 如果说智力水平决定了天花板，那么成本和速度则决定了 AI 的渗透率。Altman 在会上给出了一个极具震撼力的承诺：到 2027 年底，GPT-5.2 级别的智力成本将至少下降 100 倍。 然而，这种“廉价到无需计量”的未来并非终点。 Altman 指出，市场正在发生微妙的转向：开发者对“速度”的渴求正在超越对“成本”的关注。随着 Agent（智能体）开始处理数十个步骤的长程任务，如果输出速度不能实现百倍以上的提升，那么复杂的自主决策将变得毫无实用价值。在这种权衡下，OpenAI 可能会提供两种路径：一种是极致廉价的“智力自来水”，另一种则是极速反馈的“智力推进器”。这种对速度的强调，预示着 AI 应用将从简单的问答，彻底跨入高频、实时的自动驾驶阶段。 在这种智力成本骤降、速度飙升的背景下，传统软件的概念正在瓦解。Altman 提出了一个颠覆性的愿景：未来的软件不应该是静态的。 过去，我们习惯于下载一个通用的 Word 或 Excel；未来，当你遇到一个特定问题时，计算机应该直接为你写一段代码，生成一个“即时应用”来解决它。这种“随需随生、用完即弃”的模式将彻底重构操作系统。虽然我们可能出于习惯保留一些熟悉的交互按钮，但背后的逻辑架构将是高度个人定制化的。每个人手中的工具都会随着其工作流的积累而演化，最终形成一套独属于个人的、动态进化的生产力系统。这不仅仅是软件的定制，更是生产关系的重组。 InfoQ 翻译并整理了这场研讨会的重点内容，以飨读者： 提问：您如何看待 AI 对未来社会和经济的影响？ Sam Altman：说实话，要在一年内完全消化这种规模的经济变革是非常困难的。但我认为这会极大地赋能每一个人：它将带来大规模的资源富足、门槛降低，以及创造新事物、建立新公司和探索新科学的极低成本。 只要我们在政策上不出大差错，AI 应该成为社会的一种“平衡力量”，让那些长期以来未被公正对待的人获得真正的机会。但我确实担心，AI 也可能导致权力和财富的高度集中，这必须是政策制订的核心关注点，我们要坚决避免这种情况发生。 提问：我发现 GPT-4.5 曾是写作能力的巅峰，但最近 GPT-5 在 ChatGPT 里的写作表现似乎有些笨拙、难以阅读。显然 GPT-5 在 Agent（智能体）、工具调用和推理上更强，它似乎变得更“偏科”了（比如编程极强，写作一般）。OpenAI 怎么看这种能力的失衡？ Sam Altman：坦诚说，写作这一点确实是我们搞砸了。我们希望未来的 GPT-5.x 版本在写作上能远超 4.5。 当时我们决定将大部分精力放在 GPT-5.2 的“智力、推理、编程和工程能力”上，因为资源和带宽是有限的，有时专注于某一方面就会忽略另一方面。但我坚信未来属于“通用的高素质模型”。即便你只想让它写代码，它也应该具备良好的沟通和表达能力，能清晰、犀利地与你交流。我们认为“智力”在底层是相通的，我们有能力在一个模型中把这些维度都做到极致。目前我们确实在猛攻“编程智力”，但很快就会在其他领域赶上来。智能将廉价到无需计量 提问：对于运行数千万个 Agent 的开发者来说，成本是最大的瓶颈。您如何看待小模型和未来的成本降幅？ Sam Altman：我们的目标是，到 2027 年底，让 GPT-5.2 级别的智力成本至少降低 100 倍。 但现在有一个新趋势：随着模型输出变得越来越复杂，用户对“速度”的需求甚至超过了“成本”。OpenAI 非常擅长压低成本曲线，但过去我们对“极速输出”的关注不够。有些场景下，用户可能愿意付高价，只要速度能提升 100 倍。我们需要在“极致廉价”和“极致速度”之间找到平衡，如果市场更渴望低成本，我们会沿着那条曲线走得非常远。 提问：现在的交互界面并不是为 Agent 设计的。Agent 的普及会加速“微型应用（Micro Apps）”的出现吗？ Sam Altman：我已经不再把软件看作是“静态”的东西了。现在如果我遇到一个小问题，我期望电脑能立刻写一段代码帮我解决掉。我认为我们使用电脑和操作系统的方式将发生根本性改变。 虽然你可能每天用同一个文字处理器（因为你需要按钮留在熟悉的位置），但软件会根据你的习惯进行极致的定制。你的工具会不断进化、向你个人的需求收敛。在 OpenAI 内部，大家已经习惯用编程模型（Codex）来定制自己的工作流，每个人的工具用起来都完全不同。软件“由于我、且为我”而生，这几乎是必然的趋势。给创业者的建议：不要做“模型的小补丁” 提问：当模型更新不断吞噬创业公司的功能时，创业者该如何建立护城河？有什么是 OpenAI 承诺不碰的？ Sam Altman：很多人觉得商业的物理定律变了，其实并没有。现在的改变只是“工作速度变快了”、“开发软件变快了”。但建立成功初创公司的规则没变：你依然要解决获客问题，要建立 GTM（转市场）策略，要创造粘性，要形成网络效应或竞争优势。 我给创业者的建议是：你的公司在面对 GPT-6 的惊人更新时，是感到开心还是难过？你应该去构建那些“模型越强，你的产品就越强”的东西。如果你只是在模型边缘打个小补丁，那会过得很艰难。 提问：现在的 Agent 执行长流程任务时经常在 5 到 10 步就断掉了。什么时候能实现真正长期的自主运行？ Sam Altman：这取决于任务的复杂程度。在 OpenAI 内部，有些通过 SDK 运行的特定任务已经可以近乎永久地运行下去了。 这不再是“何时实现”的问题，而是“应用范围”的问题。如果你有一个理解非常透彻的特定任务，今天就能尝试自动化。但如果你想对模型说“去帮我开一家创业公司”，由于反馈环路太长且难以验证，目前还很难。建议开发者先拆解任务，让 Agent 能够自我验证每一个中间步骤，再逐步扩大其职责范围。AI 能帮人类产生好创意吗？ 提问：现在很多人抱怨 AI 生成的内容是“垃圾（Slop）”，我们该如何利用 AI 提高人类创意的质量？ Sam Altman：虽然人们叫 AI 的输出为垃圾，但人类产生的废话也不少。产生真正的新创意是非常难的。我越来越相信，人类的思维边界取决于工具的边界。 我希望能开发出帮人产生好创意的工具。当创造的成本骤降，我们可以通过密集的反馈循环快速试错，从而更早找到好的创意。 想象一下，如果有一个“Paul Graham 机器人”（YC 创始人），他了解你所有的过去、你的代码和工作，能不断给你提供头脑风暴，即便他给出的 100 个主意里有 95 个是错的，只要能激发你产生那 5 个天才般的念头，对世界的贡献也是巨大的。我们的 GPT-5.2 已经让内部科学家感受到了非平庸的科学进展，一个能产生科学洞察的模型，没理由产生不了优秀的产品洞察。 提问：我担心模型会让我们困在旧技术里。现在的模型学习两年前的新技术都很费劲，以后我们能引导模型学习最新出现的技术吗？ Sam Altman：这绝对没问题。从本质上讲，模型是一个“通用推理引擎”。虽然现在它们内置了海量的世界知识，但未来几年的里程碑将是：当你交给模型一个全新的环境、工具或技术，只要解释一次（或让它自主探索一次），它就能极其可靠地学会使用。这离我们并不远。 提问：作为一名科学家，我发现研究灵感是指数级增长的，但人的精力有限。模型会接管整个科研流程吗？ Sam Altman：实现完全闭环的自主科研还有很长的路要走。虽然数学研究可能不需要实验室，但顶尖数学家目前仍然需要深度参与，纠正模型的直觉偏差。 这很像国际象棋的历史：Deep Blue 击败卡斯帕罗夫后，曾出现一段“人机协作（半人马）”强于纯 AI 的时期，但很快纯 AI 就再次统领了赛场。 现在的 AI 对科学家来说，就像是“无限量的博士后”。它能帮你同时探索 20 个新问题，做广度搜索。至于物理实验，我们也在讨论是该 OpenAI 自己建自动化实验室，还是让全球科研社区贡献实验数据。目前看，科研社区对 GPT-5.2 的拥抱让我们倾向于后者，这会是一个更分布式、更聪明、更高效的科研生态。 提问：我更关心的是安全问题，最好是更强的安全性。在 2026 年，AI 有很多可能出问题的方式，其中一个我们非常紧张的方向是生物安全。现在这些模型在生物领域已经相当强了，目前无论是 OpenAI，还是整个世界的总体策略，大多还是试图限制谁可以接触这些模型，并且通过各种分类器，阻止模型帮助人们制造新的病原体。但我不认为这种方式还能持续很久。你怎么看？ Sam Altman：我认为，世界在 AI 安全，尤其是 AI 生物安全这件事上，需要完成一次根本性的转变——从“封堵（blocking）”，转向“韧性（resilience）”。 我一位联合创始人曾用过一个我非常喜欢的类比：火灾安全。火最初为人类社会带来了巨大的好处，随后它开始烧毁整座城市。人类最开始的反应，是尽可能去限制火。我最近才知道，“宵禁（curfew）”这个词，最早就和“晚上不允许生火”有关，因为城市会被烧掉。 后来，我们改变了思路，不再只是试图禁止火，而是提高对火的韧性：我们制定了消防规范，发明了阻燃材料，建立了一整套体系。现在，作为一个社会，我们在应对火灾这件事上已经做得相当不错了。 我认为，AI 也必须走同样的路径。AI 在生物恐怖主义方面会成为一个真实的问题；AI 在网络安全上也会成为一个真实的问题；但与此同时，AI 也是这些问题的重要解决方案。 因此，我认为这需要的是全社会层面的努力：不是依赖少数“我们信任的实验室”永远正确地封堵风险，而是建设一种具有韧性的基础设施。因为这个世界上，必然会存在大量优秀的模型。我们已经和很多生物研究人员、公司讨论过，如何应对“新型病原体”的问题。确实有很多人投入其中，而且也有不少反馈认为，AI 在这方面是有帮助的，但这不会是一个纯技术问题，也不会是一个完全靠技术解决的问题。整个世界都需要以一种不同于过去的方式来思考这件事。坦率地说，我对当前的状态非常紧张。但我也看不到除“以韧性为核心”的路径之外，还有别的现实选择。而且，从正面看，AI 确实可以帮助我们更快地建立这种韧性。 不过，如果今年 AI 真的出现一次“明显、严重”的失败事件，我认为生物安全是一个相当合理的“风险爆点”方向。再往后一年、两年，你也可以想象，还有很多其他事情可能会出大问题。 AI 学习效率提高后，人与人之间协作还重要吗？ 提问：我的问题和“人类协作”有关。随着 AI 模型不断变强，它们在个人学习方面非常高效，比如快速掌握一个新学科。这一点我们在 ChatGPT 和教育实验中已经看到，也非常认可。但我经常会反复想到一个问题：当你可以随时得到答案时，为什么还要花时间、甚至承受摩擦，去向另一个人提问？你之前也提到，AI 编程工具可以用极快的速度，完成过去需要人类团队协作才能完成的工作。所以，当我们谈“协作、合作、集体智能”时，人类 + AI 是很强的组合，那人类与人类之间的协作会发生什么变化？ Sam Altman：这里面有很多层问题。我年纪比在座的大多数人都大一点。但即便如此，Google 出现的时候，我还在上中学。那时老师试图让学生承诺“不使用 Google”，因为大家觉得：如果你随手就能查到一切，那为什么还要上历史课？为什么还要记忆？ 在我看来，这种想法完全不可理喻。我当时的感觉是：这会让我变得更聪明，学到更多东西，能做更多事情，这就是我成年后要长期使用的工具。如果因为它存在，就让我去学那些已经被淘汰的技能，那反而是疯狂的。 这就好比：在你明明知道已经有计算器的情况下，却还强迫我去学算盘——那在当时可能是重要技能，但现在已经没有价值了。我对 AI 工具的看法是一样的。我理解，在当前的教育体系下，AI 工具确实成了问题。但这恰恰说明，我们需要改变教育方式，而不是假装 AI 不存在。 “让 ChatGPT 帮你写东西”这件事，就是未来世界的一部分。当然，写作训练仍然重要，因为写作是思考的一部分。但我们教人如何思考、以及如何评估思考能力的方式，必须发生变化，而且我们不应该假装这种变化不存在。我对此并不悲观。 那 10% 极端自学能力很强的学习者，已经表现得非常出色了。我们会找到新的方式，重构课程体系，把其他学生一起带上来。至于你提到的另一点——如何让这不是一个“你一个人对着电脑变得很厉害”的过程，而是一个协作过程。目前为止，我们并没有看到 AI 导致人类联系减少的证据，这也是我们在持续观察和测量的事情。 我的直觉恰恰相反：在一个充满 AI 的世界里，人与人之间的连接会变得更有价值，而不是更没价值。我们已经看到一些人开始探索新的界面，来让协作变得更容易。在我们考虑自研硬件和设备时，甚至一开始就在思考：“多人协作 + AI” 的体验应该是什么样子？ 虽然现在还没有人真正把这件事完全做对，但我认为，AI 会以前所未有的方式，让这种协作成为可能。你可以想象：五个人围坐在一张桌子旁，旁边还有一个 AI 或机器人，整个团队的生产力会被大幅放大。未来，每一次头脑风暴、每一次问题解决，AI 都会成为团队的一部分，帮助整个群体做得更好。Agent 大规模进入生产系统，最大的被低估风险是什么？提问：随着 Agent 开始大规模运行、直接操作生产系统，你认为最被低估的失败模式是什么？是安全、成本、可靠性吗？以及，哪些“艰难但重要的工作”目前投入还不够？ Sam Altman：你提到的这些问题，几乎每一个都成立。有一件事让我个人、也让我们很多人都感到意外。我第一次用 Codex 时，非常确信一件事： “我绝对不会给它完全、无人监督的电脑访问权限。” 我坚持了大概两个小时。然后我想：它看起来真的在做非常合理的事情；每一步都要我点确认实在太烦了；不如先打开一会儿看看会发生什么。结果，我从来没有再把完全访问权限关掉。我发现，很多人都有类似的经历。 这让我真正担心的是：这些工具的能力和便利性太强了，而它们的失败概率可能很低，但一旦失败，后果可能是灾难性的。因为失败发生得不频繁，人们会慢慢滑入一种状态：“应该没事吧。” 但随着模型变得越来越强、越来越难理解，如果模型内部存在某种微妙的错位，或者在长时间、复杂使用后出现新的系统性问题，你可能已经在某个系统里埋下了一个安全漏洞。你可以对“AI 失控”的想象有不同程度的科幻倾向，但我真正担心的是：人们会被这些工具的强大和愉悦感牵着走，而不再认真思考它们的复杂性。能力会上升得非常快；我们会习惯某个阶段的模型行为，并因此信任它； 但却没有构建足够健全的、整体性的安全基础设施。 于是，我们会在不知不觉中，走向一个危险状态。 我认为，围绕这一点，本身就值得诞生一家伟大的公司。AI 应该如何进入幼儿与基础教育？ 提问：我想回到教育的话题。我在高中时看到身边的同学用 ChatGPT 写作文、做作业；现在在大学，我们在 CS、人文等各个领域都在讨论 AI 政策。我想问的是：在幼儿园、小学、初中这些塑造思维方式的关键阶段，你作为一名父亲，如何看待 AI 对教育的影响？ Sam Altman：总体来说，我是反对在幼儿园里使用电脑的。幼儿园应该更多是：在户外跑来跑去，接触真实的物体，学习如何与他人互动。所以，不只是 AI，我甚至觉得大多数时候，幼儿园里连电脑都不应该有。 从发展角度来看，我们仍然没有完全理解技术对儿童的长期影响。关于社交媒体对青少年的影响，已经有很多研究了，而且结果相当糟糕。我的直觉是：大量技术对更小年龄儿童的影响，可能更糟，但讨论得却少得多。在我们真正理解这些影响之前，我不认为有必要让幼儿园阶段的孩子大量使用 AI。 提问：我们在生物医药领域。生成式 AI 在临床试验文档、法规流程等方面已经非常有帮助。现在我们也在尝试用它做药物设计，特别是化合物设计。但一个很大的瓶颈是 三维推理能力。你认为这里会出现一个关键拐点吗？ Sam Altman：这个问题我们一定会解决。我不确定是不是 2026 年就能完成，但这是一个非常普遍、非常高频的需求。我们大概知道该怎么做，只是目前还有很多更紧急的方向需要推进。但这件事一定会到来。 参考链接：https://www.youtube.com/watch?v=Wpxv-8nG8ec&t=2s
先说优点，比 cc 好用！比 codex 快！代码质量也比 cc 好得多！配置说明：安装 copilot marketplace.visualstudio.com GitHub Copilot - Visual Studio MarketplaceExtension for Visual Studio Code - Your AI pair programmer marketplace.visualstudio.com GitHub Copilot Chat - Visual Studio MarketplaceExtension for Visual Studio Code - AI chat features powered by Copilot 安装 copilot 接入第三方 API 的插件 marketplace.visualstudio.com AI Chat Models - Visual Studio MarketplaceExtension for Visual Studio Code - 为 GitHub Copilot Chat 提供 智谱 AI、火山方舟、MiniMax、MoonshotAI、DeepSeek、快手万擎、阿里云百炼 模型支持的扩展，并提供 `OpenAI / Anthropic Compatible` 自定义模型支持。 { "reasoning": { "effort": "xhigh", "summary": "auto" }, "store": false, "stream": true } effort 可选项 ：low、medium、high、xhigh配置密钥：这里前面的小眼睛要点一下显示！然后切换一下模型就可以开始愉快的玩帅了！最后贴一个 settings.json 的配置版本我这里的 baseUrl 用的是 cc-switch 的 proxy 地址，密钥随便填就行！"gcmp.compatibleModels": [ { "id": "rc:gpt-5.2", "name": "RC-GPT-5.2-Xhigh", "provider": "zhipu", "baseUrl": "http://127.0.0.1:15721", "model": "gpt-5.2", "sdkMode": "openai-responses", "maxInputTokens": 272000, "maxOutputTokens": 128000, "capabilities": { "toolCalling": true, "imageInput": true }, "useInstructions": false, "includeThinking": true, "extraBody": { "reasoning": { "effort": "xhigh", "summary": "auto" }, "store": false, "stream": true } }, { "id": "rc:gpt-5.2-low", "name": "RC-GPT-5.2-Low", "provider": "zhipu", "baseUrl": "http://127.0.0.1:15721", "model": "gpt-5.2", "sdkMode": "openai-responses", "maxInputTokens": 272000, "maxOutputTokens": 128000, "capabilities": { "toolCalling": true, "imageInput": true }, "useInstructions": false, "includeThinking": true, "extraBody": { "reasoning": { "effort": "low", "summary": "auto" }, "store": false, "stream": true } }, { "id": "rc:gpt-5.2-High", "name": "RC-GPT-5.2-High", "provider": "zhipu", "baseUrl": "http://127.0.0.1:15721", "model": "gpt-5.2", "sdkMode": "openai-responses", "maxInputTokens": 272000, "maxOutputTokens": 128000, "capabilities": { "toolCalling": true, "imageInput": true }, "useInstructions": false, "includeThinking": true, "extraBody": { "reasoning": { "effort": "high", "summary": "auto" }, "store": false, "stream": true } } ], 📌 转载信息来源： https://linux.do/t/topic/1505169转载时间： 2026/1/24 06:44:01
如图，不知道持续多久，大家能用赶紧用起来。可选模型包括最新的 gpt-5.2-codex 和 gpt-5.1-codex-max
RT，Microsoft365 的 copilot 大部分情况下都是大幅度降智的，见我的上个帖子经过研究，Microsoft365 其实可以用上满血 GPT 5.2 Thinking，经过对比和官网智力没有区别，而且基本不会触发降智，用过官网的都知道官网经常降智。好像还可以用 5.1，能用 5.2 应该没人会去用 5.1 吧，所以就没加到脚本里。此外，如果账号本来就有切换模型的权限，请本脚本设置默认模型，并使用官方功能切换模型，可以用本脚本去除无关的数据源，以提升模型能力。使用链接 https://m365.cloud.microsoft/油猴脚本如下，为了能活的久一点，没有上传到 github 并给帖子设了权限，所以不建议转发该帖子内容// ==UserScript== // @name M365 GPT 优化工具 // @namespace https://linux.do/u/fatekey/summary // @version 1.3 // @description Modify M365 chat websocket messages // @author fatekey // @match https://m365.cloud.microsoft/* // @grant GM_addStyle // @run-at document-start // ==/UserScript== (function() { 'use strict'; // ================= 配置与状态管理 ================= const STORAGE_KEY = 'm365_mod_config_v2'; const DEFAULT_CONFIG = { mode: 'default', // default, reasoning, chat cleanData: false }; function getConfig() { try { const saved = localStorage.getItem(STORAGE_KEY); return saved ? JSON.parse(saved) : DEFAULT_CONFIG; } catch (e) { return DEFAULT_CONFIG; } } function saveConfig(config) { localStorage.setItem(STORAGE_KEY, JSON.stringify(config)); } let currentConfig = getConfig(); // ================= WebSocket 拦截逻辑 ================= const originalSend = WebSocket.prototype.send; WebSocket.prototype.send = function(data) { let modifiedData = data; if (typeof data === 'string') { // 1. 处理模式替换 if (currentConfig.mode !== 'default') { const target = '"isSbsSupported":true'; let replacement = target; if (currentConfig.mode === 'reasoning') { replacement = '"isSbsSupported":true,"tone":"Gpt_5_2_Reasoning"'; } else if (currentConfig.mode === 'chat') { replacement = '"isSbsSupported":true,"tone":"Gpt_5_2_Chat"'; } if (data.includes(target)) { modifiedData = modifiedData.replace(target, replacement); } } // 2. 处理数据净化 if (currentConfig.cleanData) { const keywordsPattern = '"People","File","Event","Email","TeamsMessage"'; modifiedData = modifiedData.replace(keywordsPattern, ''); } } return originalSend.apply(this, [modifiedData]); }; // ================= UI 界面逻辑 ================= const css = ` #m365-mod-btn { position: fixed; top: 12px; right: 160px; z-index: 99999; background: #252525; color: #fff; border: 1px solid #444; border-radius: 4px; padding: 6px 12px; font-family: 'Segoe UI', sans-serif; font-size: 12px; cursor: pointer; box-shadow: 0 2px 5px rgba(0,0,0,0.2); transition: background 0.2s; user-select: none; } #m365-mod-btn:hover { background: #3a3a3a; } #m365-mod-modal-overlay { display: none; position: fixed; top: 0; left: 0; width: 100%; height: 100%; background: rgba(0,0,0,0.5); z-index: 100000; justify-content: center; align-items: center; backdrop-filter: blur(2px); } #m365-mod-modal { background: #1e1e1e; color: #fff; padding: 20px; border-radius: 8px; width: 300px; box-shadow: 0 10px 25px rgba(0,0,0,0.5); border: 1px solid #444; font-family: 'Segoe UI', sans-serif; } .mod-row { margin-bottom: 15px; } .mod-title { font-size: 16px; font-weight: bold; margin-bottom: 15px; display: flex; justify-content: space-between; align-items: center; } .mod-close { cursor: pointer; color: #aaa; font-size: 24px; line-height: 20px; padding: 0 5px; } .mod-close:hover { color: #fff; } .mod-select { width: 100%; padding: 6px; background: #333; color: white; border: 1px solid #555; border-radius: 4px; outline: none; } .mod-label { display: block; margin-bottom: 5px; font-size: 13px; color: #ccc; } .mod-checkbox-container { display: flex; align-items: center; cursor: pointer; user-select: none; } .mod-checkbox { margin-right: 10px; transform: scale(1.2); } .mod-status { font-size: 12px; color: #88ff88; min-height: 18px; margin-top: 10px; text-align: right;} `; if (typeof GM_addStyle !== 'undefined') { GM_addStyle(css); } else { const style = document.createElement('style'); style.innerText = css; document.head.appendChild(style); } function createUI() { // 1. 创建触发按钮 const btn = document.createElement('div'); btn.id = 'm365-mod-btn'; btn.innerText = '⚙️ 设置模型'; // 直接绑定 JS 函数，而非 innerHTML 字符串 btn.onclick = openModal; document.body.appendChild(btn); // 2. 创建模态框容器 const overlay = document.createElement('div'); overlay.id = 'm365-mod-modal-overlay'; // 点击遮罩层关闭 overlay.onclick = (e) => { if (e.target === overlay) closeModal(); }; const modal = document.createElement('div'); modal.id = 'm365-mod-modal'; // --- 标题栏 --- const header = document.createElement('div'); header.className = 'mod-title'; const titleText = document.createElement('span'); titleText.innerText = 'M365 GPT 优化工具'; const closeBtn = document.createElement('span'); closeBtn.className = 'mod-close'; closeBtn.innerHTML = '×'; // 修复点：使用 onclick 属性直接绑定函数，避开 CSP 限制 closeBtn.onclick = closeModal; header.appendChild(titleText); header.appendChild(closeBtn); modal.appendChild(header); // --- 选项 1: 模式 --- const row1 = document.createElement('div'); row1.className = 'mod-row'; row1.innerHTML = ` AI 模型 `; const select = document.createElement('select'); select.className = 'mod-select'; const modes = [ { val: 'default', text: '默认' }, { val: 'reasoning', text: 'GPT 5.2 Thinking' }, { val: 'chat', text: 'GPT 5.2 Quick' } ]; modes.forEach(m => { const opt = document.createElement('option'); opt.value = m.val; opt.innerText = m.text; if (currentConfig.mode === m.val) opt.selected = true; select.appendChild(opt); }); select.onchange = (e) => { currentConfig.mode = e.target.value; saveConfig(currentConfig); showStatus('修改生效'); }; row1.appendChild(select); modal.appendChild(row1); // --- 选项 2: 清理数据 --- const row2 = document.createElement('div'); row2.className = 'mod-row'; const labelClean = document.createElement('label'); labelClean.className = 'mod-checkbox-container'; const check = document.createElement('input'); check.type = 'checkbox'; check.className = 'mod-checkbox'; check.checked = currentConfig.cleanData; check.onchange = (e) => { currentConfig.cleanData = e.target.checked; saveConfig(currentConfig); showStatus('Clean Setting Saved'); }; labelClean.appendChild(check); labelClean.appendChild(document.createTextNode('移除无关数据源（邮件、联系人、云文档等）')); row2.appendChild(labelClean); modal.appendChild(row2); // --- 状态栏 --- const status = document.createElement('div'); status.id = 'mod-status-text'; status.className = 'mod-status'; modal.appendChild(status); overlay.appendChild(modal); document.body.appendChild(overlay); } // 打开弹窗函数 function openModal() { const overlay = document.getElementById('m365-mod-modal-overlay'); if (overlay) overlay.style.display = 'flex'; } // 关闭弹窗函数 function closeModal() { const overlay = document.getElementById('m365-mod-modal-overlay'); if (overlay) overlay.style.display = 'none'; } function showStatus(msg) { const el = document.getElementById('mod-status-text'); if (el) { el.innerText = msg; setTimeout(() => { el.innerText = ''; }, 2000); } } // 延迟加载确保不被框架覆盖 const waitLoad = setInterval(() => { if (document.body) { clearInterval(waitLoad); createUI(); } }, 500); })(); 📌 转载信息来源： https://linux.do/t/topic/1490924原作者： fatekey转载时间： 2026/1/20 19:19:50
当前关于 Vibe Engineering 的所有认知都会在 1 个月内严重过时
过去几周，我对于 Vibe Engineering 的实践有了更多的体会, 今天再次总结一下。其实也能看出来我避免使用 Vibe Coding 这个词，是因为当下的重点已经不再是代码，而是一些更高维度的东西。另外，本文的 AI 含量我会尽量控制在 5% 内，可以放心阅读😄。之前我提到的我开始的 TiDB Postgres 重写项目已经不再在是个玩具。在前几天出差的路上, 因为长途飞行没有网络, 我仔细 review 了一下这个项目的代码, 虽然一些地方略有瑕疵, 但是总体质量已经很高, 我认为已经是接近生产水平的 rust 代码，和以前我理解中的早期原型的定义很不一样。顺便提一句, 我认为这个项目从一开始就选择 rust 是一个无比正确的决定, rust 的严谨性让 AI 能写出更接近 bug free 的 infra code (对比我另一个项目 agfs 的 shell 和它自带的脚本语言 ascript，由于这项目使用 python，项目变大后，可维护性就大大降低，但此时重写已经很困难，只能捏着鼻子慢慢重构)，所以现在已经是 2026 年了， 如果你要再启动一个新的 backend infra 项目, rust 应该是你的第一选择。验证差不多后，我也邀请了几位我团队内的几个顶尖的 vibe coder 加入项目, 看看 100% 的 AI Native 研发模式能在多快把这个项目推进到何种程度，无论如何都很想看看，应该会很有意思。下面说说自己最近的一些感受。当前关于 Vibe Engineering 的所有的认知都会在 1 个月内严重过时并非危言耸听，哪怕我正在写的这篇文章，如果你是 2026 年 2 月看到，那么很遗憾，本文聊到的东西很可能已经过时，这个领域发展的太快，很多今天的 SOTA 也许下个月就过时了。而且很有意思，过去很多对 Vibe Coding 嗤之以鼻的大佬，例如 DHH，Linus，Antirez 等，在 2025.12 月开始纷纷改口，我觉得这是相当正常的，去年 12 月开始，AI 编程工具和头部的模型突然有一个跳跃式的进步，突然对于复杂任务和大型项目的理解，以及写出代码的正确率有了极大的提升。这进步大概来自于两个方面：一方面头部模型在长上下文（>256K) 的支持，尤其是关键信息的召回率提升惊人例如上面是 GPT-5.2 在长上下文的召回表现和 GPT-5.1 对比很明显，要知道对于 Agent Coding 的场景来说，通常是多轮次推理 + 长上下文（因为要放更多的代码和中间推理结果）才能更好的有大局观，大局观的正确是对于复杂项目起到决定性因素。在这种场景下，你可以做一个简单的计算，一个模型（类似 GPT-5.1) 每轮的召回率 50%，大概 3 轮后，正确的召回率就会降低到 12.5%, 而 GPT-5.2 仍然能保持 70% 以上。另外一个进步是主流的 Vibe Coding 工具的 Context Engineer 实践日益成熟，例如 Claude Code / Codex / OpenCode。从用户体验到最佳实践，肉眼可见的越来越好，例如对于 Bash 的使用，Subagent 等，这方面越来越多的资深 Engineer 的重度使用和经验分享会对这些工具的进化提供数据飞轮，尤其是 AI 也在深度的开发这些工具，迭代速度只会更快。其实这个进步也并不是去年 12 月那个时间点的突然什么黑科技爆发，其实前几个月一直在进步，不过还不能长时间离开人工干预，更像是那个时间点，主流 Coding Agent 的质量超过了一个临界点：100% 的无人工干预下完成长时间的 Agentic Loop 成为可能。Hire the best (model)，否则就是在浪费生命上面所有提到的进步，我个人感觉只反映在了最顶尖的闭源头部模型中。我听到很多朋友和我反馈到：“我感觉 AI 编程还是很傻啊？并没有你提到那么聪明”，我首先会反问，你是不是只是用着 $20 一个月那种入门模型？如果是的话，那先去用一阵 $200 以上的 Pro Max 档次的，也许有惊喜。我个人认为，目前主流的模型，即使并非头部那档，作为 chatbot 处理大多数普通人的短上下文的日常工作是完全足够的，哪怕是 GPT-4 在和你讲人生道理的时候也已经足够把你说得一愣一愣了。作为人来说，我们的直觉或者是一些简单的 CRUD Demo 已经无法评估这些模型之间的智商差距了。但是在复杂的项目的开发中，这个差距是极端明显的。根据我个人的实践来说，当下能用来进行大型 Infra 项目（数据库，操作系统，编译器等）开发的模型大概就两个：GPT-5.2 (xhigh) + Opus 4.5，还有半个算是 Gemini 3 Pro。大概上个月我主要用着 opencode + oh-my-opencode + Opus 4.5 但是最近两周转向到了 codex + gpt-5.2 的组合，下面分析一下这几个模型的一些脾气和调性，仅仅是个人感受，而且是在后端 Infra 软件开发这个领域，仅供参考。Opus 4.5 的风格是速度很快，是个话唠，由于 Sonnet 4 有严重 reward hacking 问题，例如是在解决不了 bug 的时候会偷偷的构造作弊的测试然后糊弄过去，所以导致很长一段时间我都不太敢用 Sonnet 系列模型干复杂的事情，但是这点在 Opus 4.5 中解决得很好，即使在模型冥思苦各种尝试想都搞不定的情况下也没有选择作弊，让我放心不少，但是 Opus 的问题是 reasoning 和做 investigation 的时间太少，动手太快，以至于发现不对的时候，又返回头确认假设和研究，这样的特性催生了像 ralph-loop 这样的奇技淫巧。比方说，同样的一个 prompt 在 Claude Code 结束后又通过 stop hook 重新调用，再完整走一遍流程，不断地逼近最终的结果。相比之下，GPT-5.2 更像是一个更加小心谨慎、话不多的角色。我最开始用 Codex 的体验其实不算太好，因为我一直觉得它有点太慢了。主要是因为我习惯用它的 xhigh 深度思考模式，在真正开始写代码之前，它会花很长时间去浏览项目里的各种文件和文档，做很多准备工作。可能也是因为 Codex 的客户端不会告诉你它的计划和大概需要多久，所以就显得过程特别长。有时候一些复杂的任务，它前期的调查可能就要花上一到两个小时。但是经过长时间思考后它完成的效果通常是更好的，尤其是在一个项目的大体框架已经稳定，Codex 考虑得更周全，最终也体现出更少的 bug 和更好的稳定性。对于第三个顶级模型，也就是 Gemini 3 Pro。虽然我也知道它的多模态能力非常吸引人，但就复杂任务的 Coding 场景而言，至少从我个人的体验来看，它的表现并没有 Opus 4.5 和 GPT-5.2 那么强。不过它确实针对一些快速的前端项目 Demo 和原型制作做了一些优化，再加上它的 Playground 模式，让你在需要一些炫酷的小 Demo 或前端项目时能更快实现。其实一个比较反直觉的事情是，过去我们经常说 Vibe Coding 只能搞一些比较简单的事情，比如上面那些小 Demo 或 CRUD 项目，你会看到网上各种各样的 KOL 其实都在做这种小原型，反而大家觉得对于一些像后端这种核心的基础设施代码，当前 AI 还是搞不定的。我以前也这么想，但从去年 12 月份开始，这个结论可能需要修正了。这里面的原因是，其实这类基础设施的代码通常是由顶级工程师长期精雕细琢而成，它们有清晰的抽象、良好的测试，甚至代码本身经过多轮重构后也相当精炼。所以当 AI 具备足够的上下文空间 + 更好的推理能力 + 更成熟的 Agentic Loop + 高效的工具调用时，这类 Infra 代码的开发和维护反而是能最有效地利用这些顶尖大模型的智商的场景。在实际的工作中，我经常会让多个 Agent 互相协作，或者使用一些复杂的工作流来把它们编排在一起，并不会让一个模型来完成所有的事情。后面我会再分享一些我自己实践中的具体例子。人在什么时候进入？扮演什么角色？上面提到了，这些顶级模型再配合主流的 Vibe Coding 工具，基本上已经能超越大多数资深工程师的水平了。这不仅体现在能写出更少 bug 的代码，也体现在在 review 中能发现更多人类工程师可能看不到的问题，毕竟 AI 真的会一行一行仔细看。所以人在这个过程中扮演什么样的角色，哪些阶段只有人才能做？根据我自己的实践来说，第一当然是提出需求，毕竟只有你才知道你想要啥，这很显然，但是有时确实也挺难的，毕竟人很难从一开始就准确描述自己想要什么，这时候我会用一个偷懒的办法：让 AI 来角色扮演，比方说，我在开发 PostgreSQL 版本的 TiDB 时，我就让 AI 假设自己是一个资深的 Postgres 用户，从开发者的视角告诉我有哪些特性是非常重要、一定要实现而且 ROI 比较高的，让它列出 N 个这样的功能点，然后 AI 就会根据它的理解生成一个需求列表，接下来你再和 AI 对这些需求逐个打磨，这其实是一个高效冷启动的方法。第二是在需求提出后，现在的 Coding Agent 大多都会和你有一个规划阶段（Planning），会反复确认你的需求。在这个过程中其实有一些技巧，比如不要给 AI 太具体的方案，而是让 AI 来生成方案，你只需要关注最终你想要的结果；提前告诉 AI 有哪些基础设施和环境的问题，让它少走弯路。另外，我通常会在提出需求的第一阶段就要求 Agent 做的一些关键动作。比如无论接下来做什么，都要把计划和 todo 列表放在一个 work.md 或 todo.md 这类文件里。还有，每完成一个阶段的工作，就把上一阶段的经验教训更新到 agents.md 里。第三点是当一个计划完成并且代码合并后，把这个工作的设计文档添加到项目的知识库中（.codex/knowledge）。这些都是我会在一开始提需求时就放进去的内容。第二个阶段就是漫长的调查、研究和分析的阶段。这个阶段其实基本上不需要人做什么事情，而且 Agent 的效率比人高得多，你只需要等着就好。唯一需要注意的就是在 Research 的过程中，我通常会告诉模型它拥有无限的预算和时间，尽可能充分地进行调研。另外，如果你的模型有推理深度的参数的话，我建议在这个阶段把它们全部调到 xhigh 的级别。虽然这会让过程变慢，但在这个阶段多烧一些 token、做好更好的规划、了解更多上下文，对后续的实现阶段会更有帮助。实现阶段没什么特别好说的，反正我现在基本不会一行行去看 AI 的代码。我觉得在实现阶段唯一要注意的就是，要么你就让 AI 完全去做，要么你就完全自己做，千万别混着来，我目前是倾向于完全零人工干预的模式效果更好。第四个阶段人就变得非常重要了，那就是测试和验收结果的阶段。其实在我个人和 AI 开发项目的过程中，我 90% 的时间和精力都花在了这个阶段：也就是如何评估 AI 的工作成果，我觉得在 Vibe Coding 时：There's a test, there's a feature，你只要知道如何评估和测试你要的东西，AI 就一定能把东西给你做出来。另外值得注意的是，AI 在实现过程中会自动帮你添加很多单元测试，但说实话，这些单元测试在微观层面基本都能通过，毕竟 AI 写这种局部代码时已经很难出 bug。但 AI 不擅长的是集成测试、端到端测试。比如在开发一个 SQL 数据库时，哪怕每个细节的单元测试都没问题，但整合到一起时集成测试可能会出错。所以我在完成大目标前，我一定会先和 AI 一起做一个方便的集成测试框架，并提前准备好测试的基础设施，收集和生成一些现成集成测试的用例，尽量一键能运行那种，这样在开发阶段就能事半功倍，而且关于如何使用这些测试的基础设施的信息，我都会在正式开始前就固化在 agents.md 里，这样就不用每次沟通的时候都再告诉它该怎么测试了。关于测试从哪来的问题，我自己的经验是你可以让 AI 帮你生成，但一定要告诉它一些生成的逻辑，标准和目的，另外就是千万不要把生成测试的 Context 和实际进行开发工作的 Agent 的 Context 混在一起。第五个阶段是重构和拆分。我发现当前的 Coding Agent 在面对单一模块复杂度超过大约 5 万行代码之后，就开始很难在 1-shot 里把问题一次性解决掉（但反过来这也意味着，只要任务复杂度控制在这个阈值之下，在一个足够好的 first prompt 驱动下，很多事情确实可以做到 1-shot AC），Agent 通常不会主动去做项目结构和模块边界的治理，你要它把功能做出来，它恨不得把所有东西都写进几个几万行的大文件里，短期看似很快，长期就是债务爆炸。我自己在这个阶段的做法通常是先停下来，用自己的经验进行模块拆分，然后在新的架构下进行 1～2 轮的重构，之后又可以高并发度的进行开发了。多 Agent 协同编程的一些实践前面提到我现在使用 Coding Agent 的时候，通常不会只用一个，我自己的工作流会尽量让多个 Coding Agent 同时工作。这也是为什么有时候在一些项目上会花掉好几千美金，因为你必须把并发跑起来。当然，并发和吞吐是一方面，但另一方面我觉得让不同的 Agent 在不共享上下文的前提下互相 Review 工作，其实能显著提高质量。这就像在管理研发团队时，你不会让同一个人既当运动员又当裁判。相当于 Agent A 写的代码交给 Agent B 来 Review，往往能发现一些 A 看不到的问题。通过这样的循环往复，你就会更有信心。例如，我在实际工作中现在用得比较好的一个工作流是这样的：首先让 GPT-5.2 在 Codex 下生成多个功能的设计文档，做出详细的设计和规划，第一阶段把这些规划文档都保存下来。然后在第二阶段，依然用 Codex 根据这些需求文档一个一个去实现功能。在实现的过程中，就像我前面提到的那样，记录 To-Do、经验教训，并在接近完成的时候，在代码通过测试并准备提交之前停下，把当前的工作区交给另一个 ClaudeCode 或 OpenCode，在不提供上下文的情况下，让 ClaudeCode 来 Review 当前还未提交的代码，根据设计提出修改建议。然后再把这些建议发回给 Codex，让 Codex 来评论这些建议，如果有道理就修改代码。改完之后，再让 ClaudeCode (Opus 4.5) 那边再次 Review，直到双方都觉得代码已经写得很不错了，再提交到 Git 上，标记这个任务完成，更新知识库，然后进入下一个功能的开发。另外在一个大型项目中我会同时开多个 Agent (in different Tmux) 并行开发多个功能，但我尽量让它们负责完全不同的模块。比如一个 Agent 修改内核代码，另一个 Agent 做前端界面，这样就能分开进行，如果你需要在一份代码上做一些彼此不太相关的工作时，可以利用 git 的 worktree 让多个 Agent 在不同的 git 分支上各自工作，这样也能快速提升吞吐量。未来的软件公司和组织形态未来的软件公司会是什么形态呢？反正从我自己的实践和与一些朋友的交流来看，至少在当下，团队中用 Coding Agent 的 token 的消耗呈现出一个非常符合二八定律的分布，也就是说，最头部的用 AI 用得最好的工程师，他们消耗的 token 可能比剩下 80% 的工程师加起来还要多，而且 Coding Agent 对于不同工程师产出（质量，吞吐）的增益是不一样的，这个方差非常大，也就是对于用的最好的一群人，他们的增幅可能是 10x，但是普通人可能也就是 10%，而且唯一的瓶颈是人工的 code review 和一些无法被自动化的线上运维工作（我觉得也很快了）而且这样的特点能够让这些头部的工程师在 AI 的协助下可以无边界的工作，也就是会有越来越多的 one-man army 出现，只是目前我认为和 token 消耗是正相关的，你能花掉多少 token，大致代表你能做得多好。另外我发现一个很有趣的现象，同样是 10x 的工程师，他们各自的 Vibe Coding 工作流和最佳实践其实并不相同。也就意味着，两个顶尖的 Vibe Coder 是很难在一个项目中（的同一个模块）协作。这种工作方式更像是头狼带着一群狼群（Agents），在一片自己的领地里面耕耘，但是同一片领地里很难容纳两匹头狼，会造成 1+1 < 2。在这样的组织形态下，我觉得传统意义上的“团队协作方式”会被重新定义。过去我们强调的是多人在同一个代码库、同一个模块里高频协作，通过评审、讨论、同步来达成共识；但在 Vibe Engineering 这种模式下，更有效的方式反而可能是强解耦的并行。管理者要做的是把问题切分成足够清晰、边界明确的“领地”，让每一个头部工程师带着自己的 Agent 群，在各自的领域里做到极致。从管理的角度看，这其实是一个挺大的挑战。因为你不能再用统一流程、统一节奏去约束所有人。对顶尖的 Vibe Coder 来说，过多的流程和同步反而会显著拉低效率，甚至抵消 AI 带来的增益。管理者更像是在做“资源调度”和“冲突隔离”：确保不同头狼之间尽量少互相干扰，同时在必要的时候，能够通过清晰的接口、契约和测试来完成协作。因为上面的种种，AI-Native 的研发组织其实很难自底向上从一个非 AI-Native 的组织中生长出来，因为大多数开发者面对变革的时候的第一反应其实并不是拥抱，而是回避和抵触，但是时代的进步不会因为个人的意志转移，只有主动拥抱和被动拥抱的区别。大概就写到这里吧，总的来说，在这样一个大环境下，对个人而言意味着一场深刻的转变，就像我之前在朋友圈里提到的，我身边最好的工程师们有一些已经陷入了或多或少的存在主义危机。但是作为具体的 Builder 的我来说是兴奋的，因为造物，在当下，门槛变低了许多，如果你能从造物中能获得成就感和找到人生的意义，那恭喜你，你活在一个最好的时代。但反过来，作为一个抽象的 “人” 来说，我又是悲观的，人类是否准备好面对这样的工具？以及这样工具带来的对于社会和整个人类文明的冲击？我不知道。
Flash>Pro？SWE-rebench 发布 12 月榜单：Claude Opus 4.5 位居榜首
SWE-rebench 于近日公布了 2026 年 1 月最新榜单，该榜单基于去年 12 月 GitHub 上真实的开发任务（包含代码问题修复与拉取请求）进行动态评测。结果显示，Anthropic 旗下的 Claude Opus 4.5 以 63.3% 的任务解决率位列第一，OpenAI 的 gpt-5.2-2025-12-11-xhigh 以 61.5% 紧随其后，谷歌的 Gemini 3 Flash Preview 则以 60.0% 的成绩位居第三。本次评测重点观察了模型在处理真实世界软件工程问题时的逻辑能力与成本效益。其中，排名第三的 Gemini 3 Flash Preview 凭借每题约 0.29 美元的低廉调用成本展现出极高的实用价值。在开源模型领域，智谱 AI 推出的 GLM-4.7 表现亮眼，其解决率从上一版本的 40% 大幅提升至 51.3%，成为目前性能最强的开源模型。此外，DeepSeek-V3.2 以 48.5% 的解决率紧随其后，且单题运行成本仅为 0.25 美元，进一步压缩了 AI 辅助开发的经济门槛。此次更新反映了主流 AI 模型在自动化软件维护领域的持续演进。除上述头部模型外，Kimi K2 Thinking、Qwen3-Coder 等新型模型也已悉数入榜，显示出全球大模型在垂直代码领域的技术路线正向着高解决率与低功耗方向协同发展。原文：𝕏 x.comIbragim@ibragim_bad🆕 We have updated SWE-rebench with the December tasks!SWE-rebench is a live benchmark with fresh SWE tasks (issue+PR) from GitHub every month.Some insights:> top-3 models right now are: 1. Claude Opus 4.5 2. gpt-5.2-2025-12-11-xhigh 3. Gemini 3 Flash Preview> Gemini 31:32 PM - 16 Jan 2026♥ 290🔁 18📌 转载信息来源： https://linux.do/t/topic/1476152原作者： HCPTangHY转载时间： 2026/1/18 08:46:20