X开源Grok驱动的算法代码,揭秘内容传播机制

xiaohack博客专注前沿科技动态与实用技术干货分享,涵盖 AI 代理、大模型应用、编程工具、文档解析、SEO 实战、自动化部署等内容,提供开源项目教程、科技资讯日报、工具使用指南,助力开发者、AI 爱好者获取前沿技术与实战经验。


时光奔流,我们即将与 2025 年挥手作别。感谢这一路上,每一位伙伴的并肩前行与坚定支持。
今年,美团技术团队在持续深耕中涌现出不少值得分享的实践与开源产品&服务。我们从中精选了18篇具有代表性的技术文章,内容涵盖大模型开源、研发技能、产品服务三大方向。值得一提的是,美团 LongCat 团队今年在大模型开源领域成果显著,陆续发布了涵盖基座模型、图像、视频、语音等多个方向的开源产品与工具,期望能够持续推动AI技术分享与生态共建。
希望这些开源的大模型产品、服务及凝结一线技术实战经验的内容,能为大家带来启发和帮助,陪伴同学们在技术前行的道路上扎实成长。愿我们在新年里,继续向下扎根、向上生长,迎着光,奔赴更高、更远的山海。2026,期待继续同行!

9月初,美团正式发布并开源 LongCat-Flash-Chat。LongCat-Flash 采用创新性混合专家模型(Mixture-of-Experts, MoE)架构,总参数 560 B,激活参数 18.6B~31.3B(平均 27B),实现了计算效率与性能的双重优化。
根据多项基准测试综合评估,作为一款非思考型基础模型,LongCat-Flash-Chat 在仅激活少量参数的前提下,性能比肩当下领先的主流模型,尤其在智能体任务中具备突出优势。并且,因为面向推理效率的设计和创新,LongCat-Flash-Chat 具有明显更快的推理速度,更适合于耗时较长的复杂智能体应用。
目前,已在 Github、Hugging Face 平台同步开源,同时你也可以访问官网 https://longcat.ai/,与 LongCat-Flash-Chat 开启对话。(阅读全文)
开源地址:Hugging Face | Github

9月,美团 LongCat 团队正式发布全新高效推理模型 LongCat-Flash-Thinking。在保持了 LongCat-Flash-Chat 极致速度的同时,全新发布的 LongCat-Flash-Thinking 更强大、更专业。综合评估显示,LongCat-Flash-Thinking 在逻辑、数学、代码、智能体等多个领域的推理任务中,达到了全球开源模型的先进水平。
同时,LongCat-Flash-Thinking 不仅增强了智能体自主调用工具的能力,还扩展了形式化定理证明能力,成为国内首个同时具备「深度思考+工具调用」与「非形式化+形式化」推理能力相结合的大语言模型。我们发现,尤其在超高复杂度的任务(如数学、代码、智能体任务)处理上, LongCat-Flash-Thinking 具备更显著的优势。目前, 该模型已在HuggingFace、Github全面开源。(阅读全文)
开源地址:Hugging Face | Github

要让人工智能真正理解、预测甚至重构真实世界,“世界模型”(World Model)已成为通往下一代智能的核心引擎。作为能够建模物理规律、时空演化与场景逻辑的智能系统,世界模型赋予AI“看见”世界运行本质的能力。而视频生成模型有望成为构建世界模型的关键路径——通过视频生成任务压缩几何、语义、物理等多种形式的知识,AI得以在数字空间中模拟、推演乃至预演真实世界的运行。
基于这一关键目标,10月,美团 LongCat 团队正式发布 LongCat-Video 视频生成模型 —— 不仅以统一模型在文生、图生视频基础任务上达到开源先进水平,更依托原生视频续写任务预训练,实现分钟级长视频连贯生成,从根源上保障跨帧时序一致性与物理运动合理性,尤其在长视频生成领域具备显著优势。
作为一款视频生成模型,LongCat-Video 凭借其精准重构真实世界运行状态的能力,正在成为美团探索世界模型的第一步,也是关键的一步。同时,这也为后续支撑更多自动驾驶、具身智能等深度交互业务场景,夯实了技术基础。(阅读全文)
开源地址:GitHub | Hugging Face | Project Page

11月,LongCat-Flash-Omni 正式发布并开源。LongCat-Flash-Omni 以 LongCat-Flash 系列的高效架构设计为基础( Shortcut-Connected MoE,含零计算专家),同时创新性集成了高效多模态感知模块与语音重建模块。即便在总参数 5600 亿(激活参数 270 亿)的庞大参数规模下,仍实现了低延迟的实时音视频交互能力,为开发者的多模态应用场景提供了更高效的技术选择。
综合评估结果表明,LongCat-Flash-Omni 在全模态基准测试中达到开源先进水平,同时在文本、图像、视频理解及语音感知与生成等关键单模态任务中,均展现出极强的竞争力。LongCat-Flash-Omni 是业界首个实现 “全模态覆盖、端到端架构、大参数量高效推理” 于一体的开源大语言模型,首次在开源范畴内实现了全模态能力对闭源模型的对标,并凭借创新的架构设计与工程优化,让大参数模型在多模态任务中也能实现毫秒级响应,解决了行业内推理延迟的痛点。模型已同步开源,欢迎体验。(阅读全文)
开源地址:Hugging Face | Github

语音大语言模型(Speech LLM)想落地,绕不开一个死结:既要快速理解语音里的语义,又要说出自然的音色,还得实时响应。比如智能音箱 “听不懂” 语音,车载助手 “说” 得像机器人,实时翻译延迟卡半秒。深究根源,全在 “语音 Token 化”:作为拆分语音为 Speech LLM “离散单元” 的关键步骤,传统方案始终没平衡好 —— 要么缺语义、要么丢声学、要么延迟高,刚好卡了 Speech LLM 落地的 “死结”。
针对 Speech LLM 落地中的音频处理难题,11月,美团 LongCat 团队正式开源专用语音编解码方案 LongCat-Audio-Codec。它提供了一套一站式的 Token 生成器(Tokenizer)与 Token 还原器(DeTokenizer)工具链,其核心功能是将原始音频信号映射为语义与声学并行的 token 序列,实现高效离散化,再通过解码模块重构高质量音频,为 Speech LLM 提供从信号输入到输出的全链路音频处理支持。通过创新的架构设计与训练策略,LongCat-Audio-Codec 在语义建模、声学重建、流式合成三大维度实现突破。(阅读全文)
开源地址:Github | Hugging Face

12月初,美团发布 LongCat-Image 图像生成模型。当前 AI 图像生成技术需求旺盛,但行业陷入 “两难困境”:闭源大模型性能强劲但无法自行部署或二次定制开发,开源方案普遍存在轻量化与模型性能难以兼顾、面向商用专项能力不足的痛点,制约商业创作与技术普惠。
为此,美团 LongCat 团队正式发布并开源 LongCat-Image 模型,通过高性能模型架构设计、系统性的训练策略和数据工程,以 6B 参数规模,成功在文生图和图像编辑的核心能力维度上逼近更大尺寸模型效果,为开发者社区与产业界提供了 “高性能、低门槛、全开放” 的全新选择。(阅读全文)
开源地址:Hugging Face | GitHub

今年 8 月,美团开源的 InfiniteTalk 项目凭借无限长度生成能力与精准的唇形、头部、表情及姿态同步表现,迅速成为语音驱动虚拟人领域的主流工具,吸引全球数十万名开发者的使用。10月底,LongCat 团队开源了 LongCat-Video 视频生成模型,尤其在长视频生成领域具备显著优势。
在 InfiniteTalk 和 LongCat-Video 基座的良好基础上,LongCat 团队针对实际场景中的核心痛点持续优化,12月正式发布并开源 SOTA 级虚拟人视频生成模型 —— LongCat-Video-Avatar。
该模型基于 LongCat-Video 基座打造,延续 “一个模型支持多任务” 的核心设计,原生支持 Audio-Text-to-Video(AT2V)、Audio-Text-Image-to-Video(ATI2V)及视频续写等核心功能,同时在底层架构上全面升级,实现动作拟真度、长视频稳定性与身份一致性三大维度的显著突破,为开发者提供更稳定、高效、实用的创作解决方案。(阅读全文)
开源地址:GitHub | Hugging Face | Project

美团外卖推荐算法团队基于HSTU提出了MTGR框架以探索推荐系统中Scaling Law。MTGR对齐传统模型特征体系,并对多条序列利用Transformer架构进行统一建模。通过极致的性能优化,样本前向推理FLOPs提升65倍,推理成本降低12%,训练成本持平。MTGR离在线均取得近2年迭代最大收益,且于2025年4月底在外卖推荐场景全量。本文系相关工作的实践与经验总结,希望能给从事相关方向研究的同学带来一些帮助。(阅读全文)

美团信息安全技术团队核心服务升级JDK 17后,性能与稳定性大幅提升,机器成本降低了10%。高版本JDK与ZGC技术令人惊艳,且Java AI SDK最低支持JDK 17。本文总结了JDK 17的主要特性,然后重点分享了JDK 17+ZGC在安全领域的一些实践,希望能对大家有所帮助或启发。(阅读全文)

华为鸿蒙单框架操作系统HarmonyOS NEXT已于2024年10月23日正式发布Release版。HarmonyOSNEXT仅支持鸿蒙原生应用,不再兼容安卓。本文对鸿蒙公开资料进行了深入分析和解读,梳理了鸿蒙单框架应用的签名机制,拆解每一步的实操过程和背后的实现原理,并对源码分析整理签名的校验机制。从中管中窥豹,探究鸿蒙系统的安全设计思路,给从事鸿蒙研发的同学提供一些借鉴。(阅读全文)

管理企业大规模服务的弹性伸缩场景中,往往会面临着两个挑战:第一个挑战是精准的负载预测,由于应用实例的启动需要一定预热时间,被动响应式伸缩会在一段时间内影响服务质量;第二个挑战是高效的资源分配,即在保障服务质量的同时控制资源成本。为了解决这些挑战,美团与中国人民大学信息学院柴云鹏教授团队展开了“预测技术在弹性伸缩场景的应用”科研合作,相关论文《PASS: Predictive Auto-Scaling System for Large-scale Enterprise Web Applications》在具有国际影响力的会议The Web Conference 2024(CCF-A类会议)上作为Research Full Paper发表。(阅读全文)

美团数据库团队推出了数据库容量评估系统,旨在解决数据库容量评估与变更风险防控等领域难题。本文介绍了系统架构和主要功能:系统使用线上流量在沙盒环境回放验证变更安全,结合倍速回放技术探测集群性能瓶颈,构建容量运营体系实现集群容量观测与治理闭环。系统具备数据操作安全、结果真实可靠、灵活高效赋能等特点,有效提升数据库稳定性与资源利用率。(阅读全文)

AI生成代码质量难以把控!本文分享来自美团的技术实践,三大策略破解AI编程痛点。单测快速验证逻辑正确性,安全网保护存量代码演进,TDD模式精准传递需求。告别「看起来没问题」的错觉,构建AI时代的代码质量保障体系。(阅读全文)

SGLang 团队是业界专注于大模型推理系统优化的技术团队,提供并维护大模型推理的开源框架SGLang。近期,美团M17团队与SGLang团队一起合作,共同实现了LongCat-Flash模型在SGLang上的优化,并产出了一篇技术博客《LongCat-Flash: Deploying Meituan’s Agentic Model with SGLang》,文章发表后,得到了很多技术同学的认可,因此我们将原文翻译出来,并添加了一些背景知识,希望更多同学能够从LongCat-Flash的系统优化中获益。(阅读全文)

增长与优化是企业永恒的主题。面对未知的策略价值,数据驱动的AB实验已经成为互联网企业在策略验证、产品迭代、算法优化、风险控制等方向必备的工具。越来越多的岗位,如数据科学家、算法工程师、产品经理以及运营人员等,要求候选人了解AB实验相关知识。然而,许多从业者由于缺乏有效的学习渠道,对AB实验的理解仍停留在初级阶段,甚至存在一些误解。我们希望通过系统性地分享和交流AB实验的理论基础、基本流程、核心要素及其应用优势,能够帮助更多相关人员深入了解实验,提升实验文化的普及度,最终辅助企业在更多领域做出精确数据驱动决策。
除了广泛传播实验文化外,该白皮书在深度上也可给实验研究人员,提供复杂业务制约下进行可信实验设计与科学分析评估的参考经验和启发。从美团履约技术团队、美团外卖业务的实践来看,实验者常常面临多种复杂的实验制约和难题,例如,在美团履约业务中,实验往往需要应对小样本、溢出效应(即实验单元间互相干扰)以及避免引发公平性风险等多重约束,需设计科学复杂的实验方案以克服相应挑战。通过撰写白皮书,我们系统性地总结和分享应对复杂实验约束的研究经验,进而能够促进实验技术的传播与升级,推动实验科学持续进步。
本白皮书以AB实验为中心,涵盖AB实验概述与价值、实验方法基础原理与案例剖析以及配套SDK代码分析等,内容丰富且易于理解和应用。适合从事AB实验研究的数据科学家、系统开发人员,以及需要实验驱动策略决策的业务和产研团队,同时也适合对数据驱动增长和数据科学等领域感兴趣的读者。(阅读全文)

这是一款由美团技术团队打造的 AI 编程类产品——NoCode,可以像聊天一样轻松搭建你的专属网站、游戏、各种小工具等等,当然还有更多的隐藏功能等你发现,文末我们还准备了2项互动奖励,期待跟大家一起,开启全新的 AI 编程之旅。(阅读全文)

Meituan CatPaw (以下统一使用“CatPaw”)是美团推出的 AI IDE,以 Agent & 人协作为核心,通过 Agent 智能驱动编程,辅以代码补全、项目预览调试等功能,结合美团自研的基于编程场景特训的 LongCat 模型,并支持多种模型混合调用,让编码过程更专注,项目交付更高效!
CatPaw 早在 2023 年就在美团内部以编辑器插件形态正式上线,此次完成全新升级后进行公开测试。目前在美团内部研发渗透率超 95%,增量代码 AI 生成率超 50%。(阅读全文)

美团 LongCat 全新上线 AI 生图功能,该功能基于LongCat系列模型「LongCat-Image」打造而成。不仅在文生图任务中实现了“快、真、准” :出图快速响应、达到摄影棚拍摄质感、中文渲染精准度高;更在图像编辑任务上做到了精准便捷,无需复杂指令,可以用自然语言对图像进行二次编辑。
无论是追求高效出图的普通用户,还是需要精准落地创意的专业创作者,LongCat 都以 “轻量化模型 + 流畅体验” ,让 AI 生图真正成为人人可用的创作工具。目前,AI 生图功能已在LongCat APP和 https://longcat.ai/ 同步上线,轻松解锁高效创作新方式。(阅读全文)
最近的达沃斯论坛上,科技领袖们纷纷出来发表观点。当 Google 的 Demis Hassabis 和 Anthropic 的 Dario Amodei 在讨论更宏观的 AGI 话题时,微软 CEO Satya Nadella 与英国前首相 Rishi Sunak 的对话,更聚焦在了 AI 应用的话题。 Satya 以自己参加达沃斯的准备工作变化为例,来说明在企业内部,AI 正在打破传统层级架构,让信息流实现扁平化。 “自从我 1992 年参加以来,直到几年前,流程都没什么变化:我的现场团队会准备笔记,然后送到总部进一步提炼。但现在我直接找 Copilot 说,“我要见 xxx,给我一个简介”。它会给我一个全方位的视角。”“我做的是立即把这个简介分享给所有部门的同事。” 他指出,企业 AI 应用呈现出明显的 “杠杆效应”:初创公司能从零开始构建适配 AI 的组织,落地速度更快;大型企业虽手握数据、资源优势,但传统工作流程与组织惯性带来的变革管理挑战更大。而无论大小企业,都需经历 “思维转变 — 技能培养 — 数据整合” 的艰苦过程。 人才方面,他认为全球 AI 技术人才与初创公司的质量已无显著差异:“雅加达、伊斯坦布尔的人才技术水平并不逊色于西雅图、旧金山。”真正的差距在于大规模应用的推进力度。 Satya 表示,判断 AI 是否存在泡沫,关键也在于落地应用:若仅停留在科技公司的技术讨论,泡沫风险确实存在;但当 AI 加速药物临床试验、提升农业生产效率、优化公共服务时,技术就已转化为实实在在的经济价值。 今天,Satya 参加 All-In Podcast 的采访也发布了,这次谈话与 Rishi 那次比,有部分话题重合,但也更微观一些。他谈到,科技行业每十年换一批竞争对手是好事,能倒逼企业保持竞争力,科技产业蛋糕会持续变大,绝非零和博弈。而微软与 OpenAI 合作的核心逻辑:不押注单一模型,而是打造算力+应用服务器层的平台,兼容多模型生态。 他还提到,公司内部全球网络团队已用 AI Agent(数字员工)自动化处理光纤挖断、设备故障等 DevOps 重复工作,完全是自下而上的落地实践。此外还将 LinkedIn 等团队各角色合并为“全栈构建者”,重构 AI 产品工作流。现在,微软正在尝试新学徒制模式:由资深 IC 工程师带一组应届生,借助 AI 加速新人生产力爬坡,以适配 AI 时代的人才培养方式,新人仍需持续进入职场。 国际竞争方面,他认为,美国技术栈的核心优势是生态效应(平台之上生态收入远超自身收入),而非单纯市场份额,技术“扩散”是做大全球蛋糕,而非抢蛋糕。 我们翻译并整理了这次访谈内容,并在不改变原意基础上进行了删减,以飨读者。 Jason:今天非常高兴,能请到重量级嘉宾 Satya Nadella,Microsoft 的第三任 CEO,和我们的 AI 与加密领域负责人 David Sacks 来一场即兴炉边对话。Satya 出生在印度,大学毕业后来到美国,这一路经历本身就很传奇。你在书里写过,为了把太太接来美国,还专门“折返”了一趟。能不能简单和大家讲讲当时是怎么回事? Satya:这件事其实是美国移民政策下的一段“奇妙经历”。我和太太在印度读的是同一所大学,后来我来美国读研究生,我们结了婚。我拿到了绿卡,但问题是由于我们是结婚后才申请,她反而不能直接过来。结果就是,我不得不放弃已经拿到的绿卡。 最有意思的是,我去新德里的美国使馆,问工作人员:“请问放弃绿卡要排哪一队?”他们直接说:“没有这种队伍。”在九十年代,主动放弃绿卡绝对算是件“疯狂”的事。但为了让她能以 H1 签证过来,只能这么操作。好在最后一切都解决了,现在想起来更像是一段久远但有点荒诞的回忆。 Jason:我想聊聊 Copilot。你们最早在 GitHub 上推出 Copilot,后来做到桌面端,再到直接把它放进 Windows,这对 Microsoft 来说是个非常大胆的决定。我每天都在用。但老实说,在它还不能真正理解文件系统、也没法和应用深度交互之前,市场反应不温不火。不过现在你们明显在持续加码。 在我看来,面向知识工作者,AI 正在走向三种形态:一类是 Elon 在 xAI 做的那种“人类模拟器”,据说直接把“虚拟员工”塞进聊天和邮箱系统;一类是 Claude 刚发布的协作型 Agent,强得离谱,很多人已经被震住了,我自己连续玩了四十多个小时。 那 Microsoft 的愿景是什么?知识工作者究竟该怎么真正把这些东西用起来?现在大家更多还是在“玩 ChatGPT”,这和真正创造商业价值之间好像还有一道鸿沟。 Satya:要理解这些不同形态,最好的切入口其实是编程,代码工作几乎是最典型的知识工作。 回头看这条演进路线:最早是“Next Edit Suggestions”,也就是智能补全。老实说,我对这一代 AI 技术真正建立信心,就是从早期 Codex 那一代模型开始的。那还是 GPT-3.5 之前,但补全已经相当准确了。后来我们有了 chat 交互,再往后是可执行的 actions,现在则是全自主 Agent。这些 Agent 既可以在前台,也可以在后台;可以在云端,也可以在本地运行。 有意思的是,这些形态今天在编程中都有,而且你会全部用到,而非只选其中一种。比如我在 CLI 里,可以有前台 Agent、后台 Agent,同时直接在 VS Code 里改代码,这些全部并行进行。这说明了不同形态是可以组合的。 把这套放到知识工作上也是一样。我们是从 chat 开始,带推理的 chat 不只是一问一答,你能看到它完整的思考过程;现在到了 actions 阶段,通过模拟电脑操作、Skill 和 Agent 调用调用来执行任务,这就是 Copilot 如今的状况。 接下来,其实需要一个新的“隐喻”来理解 AI 时代的计算机。Jobs 当年形容 PC 是“思维的自行车”;Bill Gates 说过一句我很喜欢的话:“信息触手可及”。但在 AI 时代,我们需要新的说法。我很喜欢 Notion CEO 的一个比喻:“无限思维的管理者”。这个说法非常形象。 Jason:确实是个很棒的产品。不过你们还没收购它。 Satya:还没有(笑)。但这个比喻点中了关键:你同时在和大量 Agent 协作。我自己还常用两个词:宏观委派和微观引导,即你把一整块工作交出去,同时在执行过程中不断给细节指令。写代码其实已经是这样了。这正是今天 Copilot 的真实状态。 还有一种我特别期待的形态,很快你们就会看到:开发者并不是只待在自己的 repo 里。我们要开会、写设计文档、实现别人写好的规格说明,还要保证代码和这些内容一致。这就意味着,Copilot 需要能通过 MCP Server 之类的方式,把我的工作流、待办事项、上下文全部拉进来。这才是真正的知识工作“组合”。 安全领域也是一样。一个安全工程师面对的是海量日志:把日志放进文件系统、用代码分析、生成仪表盘,这些都是 AI 能大幅放大的知识工作场景。 Jason:那“数字员工”“数字同事”这种概念呢?是不是也在你们的规划里? Satya:核心问题其实是“身份”。我们推出了 Agent 365,就是把今天给人用的身份体系、终端防护体系,扩展到 Agent 身上。 Jason:也就是说,你可以“克隆”一个我,让他在 HR 或市场部里工作? Satya:没错。在 Office 体系里完全可以做到。这里有两种模式:一种是,每个知识工作者都拥有“无限个大脑”;另一种是,创造完全独立于你个人身份的 Agent。而身份这件事非常关键,权限、决策、责任追溯等全都依赖它。 Jason:说到底,就是搞清楚“谁对谁做了什么”。 Satya:正是如此。对任何组织来说,最重要的问题之一就是:工作是谁完成的、怎么完成的、来源是什么、能不能追溯,所以要么是“人 + 一堆 Agent”,由人来做宏委派、微观引导,要么就是一个完全独立的身份在运作。 Jason:过去几年,Microsoft 的员工数量基本没变,但收入多了 900 亿美元,利润还翻了一倍。你们也像 Alphabet、Meta 一样,削掉了不少中间管理层。这是因为自动化?还是以前人确实有点多? Satya:你抓住了一个非常关键的问题。我认为,这是自 PC 普及以来,知识工作最大的结构性变化。想想 PC 之前,一家跨国公司怎么做预测?传真、内部备忘录满天飞,最后凑出一份结果。后来 PC 成了标配,Excel + Email,让流程和产出物全变了,今天正在发生同样级别的变化。 举个例子,在 LinkedIn,我们以前有产品经理、设计师、前端工程师、后端工程师,后来我们把前面这些角色合并、扩大职责范围,统一成“全栈构建者”。这是结构性的调整,它改变了工作本身,也改变了工作流。 Jason:沟通成本一下就下来了,速度自然更快,一个人就能“vibe coding”。 Satya:没错,而且 AI 产品本身也有一套全新的工作流:从评测、到科学建模,再到基础设施。评测和产品由新的“全栈型 PM / Builder”完成,系统工程师负责支撑后端科学和基础设施,这是一个全新的闭环,必须从组织结构上去适配。 当然,对 Microsoft 来说,我们不可能只活在未来。现在,我们要一边把 Windows 的热补丁做好、质量做到位;一边还要持续提升 Copilot 的评测体系和质量,这两件事都必须是第一优先级的。 Jason:这大概是你职业生涯里最具挑战性的阶段吧?过去 Microsoft 在很多领域是双寡头甚至垄断,但现在面对的竞争完全不一样。 Satya:确实非常激烈。但我一直觉得,每十年换一批竞争对手,其实是好事,它能让你保持“体能”。我 1992 年加入 Microsoft,那时最大的对手是 Novell;现在是 2026 年,环境完全不同。竞争很残酷,但从 GDP 占比来看,五年后科技产业一定更大,这不是一个零和游戏。 Jason:蛋糕在变大。 Satya:而且会大得多。整个技术栈对社会的影响会极其深远。最终的问题是 Microsoft 的品牌定位是什么?客户期待我们提供什么?有时候我们会误以为,所有客户对所有厂商的期待都是一样的,但真正重要的是弄清楚客户“希望从你这里得到什么”。这其实是 Peter Thiel 那个观点的另一种表达:不是逃避竞争,而是通过理解客户,找到你真正不可替代的位置。 David:这次在达沃斯,既有不少国家领导人,也有大量《财富》世界五百强公司的 CEO。昨晚晚宴上,有人问你一个问题:他们该如何看待 AI,怎样才能真正把 AI 用好。我记得你当时提到了“扩散(diffusion)”这个词,这一点和我最近参与的一些政策研究高度契合。能不能展开讲讲你的想法? Satya:当然可以。事实上,你们一直在做一件非常重要的事,就是确保以美国为代表的技术栈,能在全球范围内被广泛采用、并且被信任。 回过头来看,技术本身只是起点,真正的价值来自于被大规模、深入地使用。我一直很喜欢一项研究,是 Diego Comin 做的,研究的是工业革命时期各国是如何实现领先的。结论其实很简单:那些把最新技术引入本国,并在此基础上做价值叠加的国家,最终跑得最快。说白了,不要重复造轮子,而是先用最先进的,再在上面持续创新。 这正是“扩散”的意义所在。像 AI 这样的通用型技术,关键在于能不能真正铺开。就拿美国来说,技术我们已经有了,但问题是:它有没有进入医疗?有没有进入金融?有没有进入所有行业?不只是大企业,也包括中小企业和公共部门。如果看不到这种广泛而密集的应用,就谈不上真正的成功。 现在我们正处在这样一个阶段:AI 正在更快地“扩散”。你们做的那些政策层面的工作其实非常关键。好消息是,技术已经成熟了,云计算和移动互联网这些“基础设施轨道”早就铺好了,这让 AI 的传播成为可能。现在真正的问题不在算力能不能拿到,而在于具体的应用场景是什么,以及组织如何管理随之而来的变化。 在达沃斯,还有一个常被提起的问题:发达国家之外,全球南方怎么办?我反而觉得这里蕴含着巨大的机会。在很多全球南方国家,公共部门在 GDP 中的占比非常高。想象一下,如果 AI 能显著提升政府把纳税人资金转化为公共服务的效率,哪怕只提升一点点,那可能就是几个百分点的 GDP 增长。 所以我非常乐观,我认为会形成一种强烈的拉动力,而美国也应该把我们已有的技术栈,推动在欧洲、亚洲、南美、非洲等地广泛落地。 David:我经常被问到一个问题:这场 AI 竞赛,怎么判断谁在赢?或者美国是不是领先全球?我给出的答案很直接:看市场份额。如果几年后我们放眼全球,看到美国公司的技术占据了绝大多数市场,那说明我们做对了;如果看到全球到处用的都是中国的芯片和模型,那可能就意味着我们输了。说到底,使用情况才是最真实的检验标准。 Satya:我同意。但你也在 Microsoft 工作过几年,应该记得 Bill Gates 对“平台”的理解。对我来说,除了市场份额,更重要的是生态效应。美国一直以来的优势,不只是本国公司的收入规模,而是围绕平台形成的完整生态。 我在 Microsoft 学到的一点是,每次去一个国家访问,最先看的不是我们卖了多少软件,而是围绕 Microsoft 平台,在当地创造了多少就业岗位。比如有多少渠道伙伴、多少 ISV、多少相关的 IT 从业者。我们有一整套指标,衡量一个国家的生态是如何围绕平台建立起来的。 这正是美国技术栈过去在全球,包括在中国,能够被广泛采用的原因:当地公司能在上面构建自己的产品和业务。这种事情还会再次发生。所以你们推动“扩散”的工作,本质上不是在抢蛋糕,而是在把蛋糕做大,增强对平台的信任,从而带来真正的经济机会。 David:你这么一说,我确实想起了一些往事。那还是十多年前,Yammer 被 Microsoft 收购,我们并入了 SharePoint 团队。当时产品经理们非常自豪的一点是:围绕 SharePoint 的生态收入,即非 Microsoft 的咨询公司、实施伙伴创造的收入,其规模是 Microsoft 自身软件收入的好几倍。Bill 也说过一句话:只有当平台之上的收入,显著超过平台自身的收入时,你才算真正拥有一个生态。所以,当我们谈“扩散”,希望美国保持领先地位,并不意味着这对世界其他地方是坏事。恰恰相反,其他国家和公司可以在这个平台之上创造出更大的价值。 Satya:完全同意。这一点非常关键。这不是“美国技术、美国收入”的问题,而是在用一个新平台在全球范围内创造机会。 我 90 年代做数据库产品时,和 SAP 有过深度合作。SQL Server 和 R/3 的结合,对双方都是巨大的成功。大家常提 Intel 和 Microsoft,但对我个人成长影响很深的一件事其实是和一家欧洲软件巨头的合作。放到今天也是一样,谁知道下一个伟大的 AI 应用会出现在哪里?我始终相信,即便基于美国的技术栈,世界各地都可能诞生顶级的科技公司。 Jason:你不仅是技术领袖,也是一位非常出色的并购操盘手,这一点其实被外界低估了。你和 Sam Altman、OpenAI 的合作,被认为既高明又充满争议。有人说,这笔交易可能让 Microsoft 获得巨额回报,但也有人质疑:你是不是亲手培养了一个未来最强的竞争对手?尤其是考虑到 Microsoft 过去错过了移动互联网浪潮,你们为什么不自己做一个 Gemini、xAI 或 Claude? Satya:我理解这种疑问。很多人问我:你们自己的基础模型在哪里?从知识产权角度说,我们确实拥有相关能力,但更重要的是,Microsoft 现在的战略有几个层面。 首先,我们要把“算力工厂”做好。Azure 是我们最大的业务之一,而随着 AI 的发展,它的市场空间会变得极其庞大,这要求我们在异构基础设施管理、软件调度和资源利用率上做到极致。 其次,是应用服务器层。未来,每个人都在构建 Agent,有强化学习环境、有评测体系,就像每一代平台都会有自己的应用服务器一样。我们现在在做的 Foundry,就是这个定位。 在这一层里,有一点已经非常清楚:任何应用、任何公司,最终都会同时使用多种模型。为什么不用呢,甚至在一个具体任务里,编排多个模型协同工作,效果往往比单一的前沿模型更好。我们在医疗领域做过一个“决策编排”的实践,仅仅通过给模型分配不同角色再进行协同,就能显著提升结果质量。 Jason:那是不是可以理解为,你其实看好开源模型,认为大模型本身会逐渐商品化,真正的价值不在这里? Satya:我更愿意把它类比成数据库市场。最早大家觉得数据库就是 SQL,后来才发现并不是。关系型、文档型、NoSQL,各种数据库层出不穷,甚至出现了大量开源项目和围绕它们建立的公司。模型也会是类似的演进路径,会有闭源的前沿模型,也会有达到前沿水平的开源模型。 接下来一个非常重要的方向是:企业能否把自身的隐性知识,真正嵌入到自己掌控的模型权重中。有人问我未来会有多少模型,我的回答是:可能和世界上有多少家公司一样多。这听起来极端,但在我看来,这正是“知识经济”向“AI 经济”转变的方式。 Jason:那你有没有在 Windows 桌面上,悄悄推进一个本地运行的大模型? Satya:其实已经在发生了,现在已经有完全驻留在本地、基于 NPU 和 GPU 的模型。高性能工作站正在回归,这本身就是一件非常有意思的事。 Jason: 明白了。所以 Microsoft 当然会重视 PC,这毕竟是你们的主场,有完整的桌面生态。 Satya:是的,本质上这是个商业问题。我们一直认为“形态”非常重要。我常开玩笑说,我的职业生涯是从命令行开始的,说不定最后也会回到命令行。但不管怎样,形态一直在演进。 Jason: 你当年起步时用的是 Sun 那种最早的工作站,价格五千到一万美元。你能想象有一天,你会向客户推荐一台一万到两万美元的桌面机,里面内置 LLM 和强悍硬件吗? Satya:完全有可能。你可以插一张 DGX 卡,做出一台非常强的机器。其实在模型架构上,我们可能只差一次关键调整就能实现某种分布式模型架构,比如真正能自我调度的 MoE 架构。这类突破会彻底改变“混合 AI”该是什么样子。 但不管怎样,我们非常明确:PC 必须成为本地模型的最佳载体。本地模型可以承担大量 prompt 处理,再按需调用云端能力。这里面还有大量工作空间,这也是我们正在坚定推进的方向。 David: 云与本地的协同已经证明了,能直接访问本地文件系统,本身就非常有价值。这让我想到 Yammer。很多人可能不知道 Yammer 当年最大的特点,是用消费级增长打法去攻企业软件。站在今天去看企业 AI 的采用,你觉得未来一年会怎么“扩散”?现在好像正处在一个关键点:会是自上而下,由 CEO 拍板、搞战略转型、走 RFP;还是自下而上,由一批 AI 原生员工先用起来,把工具带进工作中,做出惊人的成果? Satya:说实话,我觉得两种都会发生。自上而下的原因很简单:在客服、供应链、HR 自助这些场景里,AI 的 ROI 非常清晰,IT 和 CXO 很容易拍板,这也是目前最先落地的一波真实 AI 应用。 但最终真正改变组织的,一定是自下而上的力量。回看 PC 的历史也是这样:最早是律师把 Word 带进公司、财务把 Excel 带进来,后来有了邮件,最后才变成标配。现在正在重演这个过程。比如说 Agent,现在几乎所有人都在做 Agent,本质是在重构工作流,把大量重复、枯燥的事情自动化掉,这正是自下而上转型的起点。 说实话,我最兴奋的也是这种变化。以 Microsoft 为例,我们在全球管理着五百多个光纤运营点,尤其在亚洲。我自己以前都没意识到,这些所谓的 DevOps,其实很大一部分是物理资产:光纤会被挖断、设备会出故障。所谓 DevOps,很多时候就是在不停地发邮件问“这张光纤卡怎么了”“怎么修”。 现在负责全球网络的同事,已经构建了一批“数字员工”,本质就是 Agent 在自动处理这些 DevOps 工作。这完全是自下而上的:工具已经在那里了,我就用它来做自动化,减少重复劳动,提高效率和质量。 而这些能力最终能不能规模化,关键不在“学会没有”,而在“用不用”。所谓技能提升并不神秘,就是在实际使用中完成的。工具扩散、工具被真正用起来,这才是最重要的事情。 Jason: 正因为如此,现在用这些工具去赋能现有员工,比招人、培养新人要容易得多。站在今天看,如果 Microsoft 规模不变,三、四十年后谁会接我的工作?你们是典型的技术优先公司,理论上已经没有太多理由继续增加员工数量,这几年你们也基本没扩张,只是在内部结构上做了调整。 那你怎么看下一代?对那些现在还没拿到 Microsoft offer 的应届生,你会给什么建议?以前你花了很多精力去培养这群人,但现在好像没那么“奢侈”了。 Satya:这是个好问题。现在确实有争论:职业早期会发生什么变化、校园招聘还重要吗?我依然坚定相信校园招聘,因为 AI 会彻底改变一个人掌握代码库、建立熟练度的速度。 过去,新人进团队的爬坡期很长;现在不一样了,有文档、有技能库,还可以直接问 Agent,本质上就像身边有一个极其强大的导师帮你快速上手代码。换句话说,应届生的生产力曲线会比以往陡得多。 我们也在尝试新的学徒制模式:让一位资深 IC 工程师带一组应届生一起工作,因为这本身就是一种全新的工作方式。以前大家进 Microsoft 后会去读 Dave Cutler 的代码,理解什么是顶级工程实践;而现在,顶级实践更多体现在十倍、百倍工程师是如何借助 AI 打造高质量产品的。对于这些经验,新一代毕业生会学得更快。 对 Microsoft 这样的公司来说,这是好事。毕竟只要人类还没解决“永生”问题,我们就需要新人进入职场、在 Microsoft 成长。所以我们依然会积极投入,只是会确保岗位的边界和内容,让其既符合现有员工的期望,也符合新入职者的追求。 参考链接:移民政策下的一段“奇妙经历”
数字员工如何进入企业
“每十年换一批竞争对手”
与 OpenAI 合作背后:所有公司、应用会同时用多种模型
“我们在尝试新的学徒制模式”
目录 国内企业级在线交流工具主要有:企业微信、钉钉、飞书,国外的则是:Slack、Discord这两大IM工具,你会发现,他们有很多不一样的东西,其中有两个最大的不同,一个是企业管理,一个是企业文化。 Slack/Discrod 主要是通过建 Channel ,而国内的IM则主要是拉群。你可能会说,这不是一样的吗?其实是不一样的,很明显,Channel 的属性是相对持久的,而群的属性则是临时的,前者是可以是部门,可以是团队,可以是项目,可以是产品,可以是某种长期存在的职能(如:技术分享),而拉群则是相对来说临时起意的,有时候,同样的人群能被重复地拉出好几次,因为之前临时起意的事做完了,所以群就被人所遗忘了,后面再有事就再来。很明显,Channel 这种方式明显是有管理的属性的,而拉群则是没有管理的。 所以,在国内这种作坊式,野蛮粗放式的管理风格下,他们需要的就是想起一出是一出的 IM 工具,所以,拉群就是他们的工作习惯,因为没有科学的管理,所以没有章法,所以,他们不需要把工作内的信息结构化的工具。而国外则不然,国外的管理是精细化的,国外的公司还在重度使用 Email 的通讯方式,而 Email 是天生会给一个主题时行归类,而且 Email 天生不是碎片信息,所以,国外的 IM 需要跟 Email 竞争,因为像 Email 那样给邮件分类,把信息聚合在一个主题下的方式就能在 IM 上找到相关的影子。Channel 就是一个信息分类,相当于邮件分类,Slack 的 回复区和 Discord 的子区就像是把同一个主题信息时行聚合的功能。这明显是懂管理的人做的,而国内的拉群一看就是不懂管理的人干的,或者说是就是满足这些不懂管理的人的需求的。 团队协作和团队工作最大的基石是信任,如果有了信任,没有工具都会很爽,如果没有信任,什么工具都没用。信任是一种企业文化,这种文化不仅包括同级间的,还包括上下级间的。但是,因为国内的管理跟不上,所以,就导致了各种不信任的文化,而需要在这里不信任的文化中进行协同工作,国内的 IM 软件就会开发出如下在国外的 IM 中完全没有的功能: 而国外的 IM 则是,发出的信息可以修改/删除,没有已读标准,也不会监控员工。这种时候,我总是会对工作在这种不信任文化中人感到可怜……如果大家需要靠逼迫的方式把对方拉来跟我一起协作,我们还工作个什么劲啊。 所以,我们可以看到,畸形的企业管理和企业文化下,就会导致畸形的协同工具。最令人感到悲哀的是,有好多同学还觉得国内的钉钉非常之好,殊不知,你之所以感觉好用,是因为你所在的环境是如此的不堪。你看,人到了不同的环境就会有不同的认识,所以,找一个好一些的环境对一个人的成长有多重要。 给一些新入行的人的建议就是,一个环境对一个人的认知会有非常大的影响,找一个好的环境是非常重要,如果不知道什么 环境是好的,那就先从不使用钉钉为工作协同软件的公司开始吧…… 我们从上面可以得到,协同的前提条件是你需要有一个基于信任的企业文化,还需要有有结构化思维的科学的管理思维。没有这两个东西,给你的团队再多的工具都不可能有真正好有协同的,大家就是装模作样罢了。 假设我们的管理和文化都没有问题,那下面我们来谈谈协同工具的事。 我个人觉得 IM 这种工具包括会议都不是一种好的协同工具,因为这些工具都无法把信息做到真正的结构化和准确化,用 IM 或是开会上的信息大多都是碎片化严重,而且没有经过深度思考或是准备的,基本都是即兴出来的东西,不靠谱的概率非常大。 找人交流和开会不是有个话题就好的,还需要一个可以讨论的“议案”。在 Amazon 里开会,会前,组织方会把要讨论的方案打印出来给大家看,这个方案是深思过的,是验证过的,是有数据和证据或是引用支撑的,会议开始后,10 -15分钟是没有人说话的,大家都在看文档,然后就开始直接讨论或发表意见,支持还是不支持,还是有条件支持……会议效率就会很高。 但是这个议案其实是可以由大家一起来完成的,所以,连打印或是开会都不需要。试想一下,使用像 Google Doc 这样的协同文档工具,把大家拉到同一个文档里直接创作,不香吗?我在前段时间,在公网上组织大家来帮我完成一个《非常时期的囤货手册》,这篇文章的形成有数百个网友的加持,而我就是在做一个主编的工作,这种工作是 IM 工具无法完成的事。与之类似的协同工具还有大家一起写代码的 Github,大家一起做设计的 Figma……这样创作类的协同工具非常多。另外,好多这些工具都能实时展示别人的创作过程,这个简直是太爽了,你可以通过观看他人创作过程,学习到很多他人的思路和想法,这个在没有协同工具的时代是很难想像的。 好的协同工具是可以互相促进互相激励的,就像一个足球队一样,当你看到你的队友在勇敢地争抢,拼命地奔跑,你也会被感染到的。 所以,好的协同就是能够跟一帮志同道合,有共同目标,有想法,有能力的人一起做个什么事。所以,在我心中我最喜欢的协同工具从来都是创作类的,不是管理类的,更不是聊天类的。管理和聊天的协同软件会让你产生一种有产出的假象,但其实不同,这种工具无论做的有多好,都是支持性的工具,不是产出类的工具,不会提升生产力的。 另外,在创作类的协同工具上如果有一些智能小帮手,如:Github 发布的 Copilot。那简直是让人爽翻天了,所以,真正能提升生产力的工具都是在内容上帮得到你的。 我其实并不喜欢今天所有的 IM 工具,因为我觉得信息不是结构化的,信息是有因果关系和上下文的,是结构化的,是多维度的,不是今天这种线性的方式,我们想像一下“脑图”或是知识图,或是 wikipedia 的网关的关联,我们可能就能想像得到一个更好的 IM 应该是什么 样的…… 协同工作的想像空间实在是太大了,我觉得所有的桌面端的软件都会被协作版的重写,虽然,这种协作软件需要有网络的加持,但是协作软件的魅力和诱惑力实在的太大了,让人无法不从…… 未来的企业,那些管理类的工具一定会被边缘化的,聊天类的会被打成一个通知中心,而创作类的会大放异彩,让大家直接在要干的事上进行沟通、交互和分享。
这两天跟 Cali 和 Rather 做了一个线上的 Podcast – Ep.5 一起聊聊团队协同。主要是从 IM 工具扩展开来聊了一下团队的协同和相应的工具,但是聊天不是深度思考,有一些东西我没有讲透讲好,所以,我需要把我更多更完整更结构化的想法形成文字。(注:聊天聊地比较详细,本文只是想表达我的主要想法)国内外的企业 IM 的本质差别
企业管理
企业文化
小结
什么是好的协同工具
结束语
分享下 Gemini 搓的一个 Github 文件夹下载器,妈妈再也不用担心我为了一个文件夹下载整个仓库啦
精修样式,完美融入原生页面:
脚本源码:
// ==UserScript==
// @name GitHub Folder Downloader
// @name:zh-CN GitHub 文件夹下载器
// @version 0.7.0.33
// @author 叁月柒
// @match *://github.com/*
// @grant none
// @run-at document-idle
// ==/UserScript==
(function () {
'use strict';
const isFolder = () => {
const path = window.location.pathname.split('/').filter(Boolean);
return path.length >= 2 && (path.length === 2 || path[2] === 'tree');
};
const injectToMenu = () => {
const portalRoot = document.querySelector('#__primerPortalRoot__');
if (!portalRoot) return;
const menu = portalRoot.querySelector('ul[role="menu"]');
if (!menu || menu.querySelector('.gh-download-integrated')) return;
const menuText = menu.innerText;
// 确保是操作菜单
if (!menuText.includes('Copy path') && !menuText.includes('Delete directory')) return;
// 1. 分割线
const dividerHtml = `<li role="none" class="ActionList-sectionDivider gh-download-integrated"></li>`;
// 2. 标题
const headerHtml = `
<li class="ActionList-sectionHeader gh-download-integrated" style="padding: 8px 16px 4px 16px;">
<span class="ActionList-sectionHeader-label" style="color: #9198a1; font-size: 12px; font-weight: 500; display: block; line-height: 1.5;">
Download folder
</span>
</li>`;
// 3. 子选项
const createItem = (text, url) => `
<li role="none" class="ActionList-item gh-download-integrated">
<a role="menuitem" class="ActionList-content ActionList-content--visual16" target="_blank" rel="noopener noreferrer" href="${url}" style="text-decoration: none; padding-left: 16px;">
<span class="ActionList-item-label" style="padding-left: 24px; font-weight: 400; font-size: 14px; color: var(--fgColor-default, #adbac7);">
${text}
</span>
</a>
</li>`;
const downloadDirUrl = `https://download-directory.github.io?url=${window.location.href}`;
const downGitUrl = `https://downgit.github.io/#/home?url=${window.location.href}`;
const fragment = dividerHtml +
headerHtml +
createItem('by Download-Directory', downloadDirUrl) +
createItem('by DownGit', downGitUrl);
menu.insertAdjacentHTML('beforeend', fragment);
};
const observer = new MutationObserver((mutations) => {
if (!isFolder()) return;
for (const mutation of mutations) {
if (mutation.addedNodes.length > 0) {
injectToMenu();
}
}
});
observer.observe(document.body, { childList: true, subtree: true });
})();之前看到 @fatekey 佬 写的 雨云无限白嫖 FRP 服务器攻略(无 aff) - 福利羊毛 / 福利羊毛,Lv2 - LINUX DO ,照着搭了个 FRP。
原帖提到了自动签到的 Docker 版本,但续费还得手动调 API。想着既然每天签到攒积分,不如直接做成全自动:签到 + 到期检测 + 自动续费,一劳永逸。
于是在 fatekey 佬的 Docker 版基础上改了改,加上了自动续费功能。
本来想 fork 后提合并建议的,但想了想改的太多了,于是把仓库独立出来了
每日自动签到(验证码识别)
游戏云服务器到期检测
积分自动续费(到期前 7 天自动续)
Server 酱通知 (也有其他通知,都是原版自带的,我把
server 酱优化了一下)
git clone https://github.com/Jielumoon/Rainyun-Qiandao.git
cd Rainyun-Qiandao
# 编辑 .env 填入账号 cp .env.example .env # 运行
docker-compose up --build
| 变量 | 说明 |
|------|------|
| RAINYUN_USER | 雨云用户名 |
| RAINYUN_PWD | 雨云密码 |
| RAINYUN_API_KEY | API 密钥(可选,用于自动续费) |
| PUSH_KEY | Server 酱推送密钥(可选) |
| RENEW_PRODUCT_IDS | 续费白名单:只续费指定的产品 ID(可选) |
API 密钥在雨云后台 → 用户中心 → API 密钥获取。
# 每天早上 8 点执行
0 8 * * * docker compose -f /path/to/docker-compose.yml run --rm rainyun-qiandao
| 作者 | 仓库 | 说明 |
|------|------|------|
| SerendipityR | 原版 | Python 版本 |
| fatekey | 二改 | Docker 化 |
项目地址GitHub - Jielumoon/Rainyun-Qiandao: 三改版雨云签到工具的 docker 版
有问题欢迎反馈~
分享一个 Alfred 插件,切换多个 Claude Code 账号
复现,是你迈入“真科研”的第一步。 复现≠复制粘贴!它是用原作者公开的技术细节、实验步骤、代码仓库和数据集,自己动手重新实现,验证论文结果是否可重复的过程。 复现的最大好处是能够从理论层面走向实践。光看论文中的理论、公式和结果可能无法完全理解其背后的实现细节,而亲自动手复现,可以让你更好地理解技术原理。 论文中的研究结果,未必在其他环境下也能复现,尤其是涉及到数据集和模型训练等因素时。通过复现,我们可以验证这些结果是否具有普适性。 复现过程是一个实战的过程,尤其是在深度学习和机器学习、大模型领域,实验中的调参、数据处理、模型选择等都会是你宝贵的经验。对科研人员来说,复现一些经典论文是最直接的学习方式。 复现论文并不是一件容易的事,但只要你掌握了方法,逐步进行,也能顺利完成。接下来我们以《PhotoDoodle: Learning Artistic Image Editing from Few-Shot Examples》这篇论文为例,借助大模型实验室Lab4AI平台,带你从头开始复现。 复现的第一步是找到值得复现且能复现的论文和代码。大多数论文会将其代码发布在GitHub或其他平台上,因此你需要阅读论文,并且找到代码仓库的链接,链接通常附加在论文末尾或摘要部分。找到论文提供的GitHub开源代码后,你需要查看项目中是否有清晰的README文件,介绍如何配置环境、安装依赖、运行代码等。 这里分享5个筛选项目的关键技巧,总结为“三查”核心原则:查信息完整性、查代码一致性、查资源可行性,帮你快速避坑: 本次我们选用大模型实验室Lab4AI来进行复现,平台提供灵活计费的H卡算力,闲时使用更优惠。您也可以使用本地资源或者实验室资源,进行本次复现。 打开大模型实验室Lab4AI,登录大模型实验室Lab4AI平台。点击右侧“新建实例”,新建前建议先查看“GitHub项目的文档”的环境配置说明。 新建实例后,先下载论文代码,推荐4种常用方式: 环境配置是复现的“重头戏”,按以下步骤操作,少踩 90% 的坑: 使用 由于这个项目的README.md文件先介绍的如何推理,再介绍了如何训练。所以,我们先执行推理,看一下推理效果。 ① 由于CPU无法满足推理算力需求,所以需要重启Lab4AI实例并选择1卡GPU; 运行代码时出现一些依赖冲突与缺失的问题: 修改inference.py中的输入图像路径、编辑提示词等参数,重新运行可以看到获得不同的输出结果。 训练数据集与预训练模型是多数论文复现项目的基础支撑。《PhotoDoodle》项目的数据集及预训练模型的下载链接,都能在项目 GitHub 仓库的 README 文件中找到。 遇到网络问题时,您可以使用可靠的下载工具或者科学上网。 一旦完成了环境配置和数据准备,接下来的步骤就是开始训练。执行训练代码时,我们依据GitHub项目中给出的命令执行。 您也可以做一些个性化训练,按data 文件夹的格式组织自己的数据集,修改脚本中的参数即可实现自定义训练。 总结一下此次复现环节踩的坑以及对应的解决方法。 论文复现的环境配置是一项系统性的工作。对新手而言,关键要抓住三个核心: 每一次成功的环境配置,都是对你工程解决问题能力的一次极好锻炼。希望这份详细指南能帮你避开弯路,顺利开启论文复现之旅。 而Lab4AI大模型实验室,能为你提供一键复现方案,有效规避论文复现中的各类坑! 平台实现算力与实践场景的无缝衔接,配备充足 H 卡算力,支持模型复现、训练、推理全流程,更具备灵活弹性、按需计费、低价高效的优势,完美解决缺高端算力、算力成本高的核心痛点。 祝你复现顺利! GitLink开源创新服务平台与Lab4AI大模型实验室联合发起「论文头号玩家」论文复现计划。寻找百万「论文头号玩家」计划 | 首批复现体验官开放申请,最高可获500元算力金!本计划开放高性能H800 GPU算力,旨在降低复现门槛,推动学术成果的实践转化。手把手教你进行论文复现,小白也能学会,赶紧收藏
你是不是常常看见学术圈或技术论坛中大家提到“论文复现”这个词,却不太明白它的含义?
别急!这篇超详细的实操指南,从“是什么” 到 “怎么做”,再到 “避坑技巧”,手把手带小白走完第一次论文复现,赶紧收藏起来慢慢看~什么是“复现”?
简单说,就是跟着论文的“说明书”,亲自跑一遍实验,既能吃透论文核心逻辑,又能练编程、调参技能,还能检验研究成果的可靠性,毕竟学术研究的本质就是“可验证、可推广”。为什么要做论文复现?
1. 深入理解核心技术
2. 检验研究成果的可靠性
3. 累积实战经验
手把手教你做第一个复现项目

Step 1 找到合适的论文和代码

在《PhotoDoodle》这篇论文中,GitHub上的代码仓库包含了与艺术图像编辑相关的实现,README有详细的项目介绍,包括了从少量样本中学习艺术风格的代码。需要重点关注以下几个部分:
Step 2 配置环境并安装依赖

Step 3 下载代码

Step 4 配置环境
(1) 创建独立虚拟环境,这样能够避免依赖冲突:
conda create -n doodle python=3.11.10
# 创建环境
conda activate doodle
# 激活环境
(2) 安装PyTorch与项目依赖
cd 命令进入代码所在文件夹,再分两步安装。根据GitHub说明,通过pip安装所需的PyTorch及所有依赖。如果网络环境受限,可以选择国内的镜像源(如清华镜像)来加速下载:pip install torch==2.5.1 torchvision==0.20.1 torchaudio==2.5.1 --index-url https://download.pytorch.org/whl/cu124
pip install --upgrade -r requirements.txt -i https://pypi.tuna.tsinghua.edu.cn/simple
Step 5 执行推理
(1) 准备工作:

②在终端执行conda activate doodle激活之前创建的Conda 环境,再通过cd 路径命令进入 PhotoDoodle 代码目录。(2) 运行推理代码:
python inference.py(3) 常见问题解决:
diffusers 版本过低”huggingface-hub 版本过高,与其他不兼容”transformers库的版本不兼容”
等等……
遇到这些问题时,最好的方法是参考项目文档中提供的建议,查看GitHub Issues寻找解决方案,您也可以询问AI大模型寻找解决办法。(4)自定义输出:

Step 6 执行推理下载数据集和训练模型

在下载数据和预训练模型时,出现了多次因为网络问题而无法下载数据和模型的情况。核心原因可归为四类:Step 7 执行训练
(1) 按论文提供的脚本执行

(2)个性化训练
复现高频问题及解决方案

小贴士:复现时一定要记笔记!把遇到的问题、解决方案、参数调整记录下来,下次复现能少走很多弯路~案论文复现总结
<div align="center">
参与活动您将获得:
</div>
<p align="center">
<img src="http://llamafactory-online-assets.oss-cn-beijing.aliyuncs.com/lmlab/docs/v1.0/blog/synchronize/jy_fuxian-15.png">
</p>
自己从 lroolle/chatgpt-degraded fork 改装来的,其实也就是加了一个监控订阅剩余时长的,这个对于 team 订阅来说还是挺重要的( 我自己有这个需求,所以就改装了一下
大概用了两个月了,一直没啥问题。订阅时间也很准,不过很多时候可能 openai 会提前封号,尤其是订阅时间只剩 1-2 天的时候要注意一下。
greasyfork 脚本:
2libra 没有自带的图片上传功能,昨天看到 一个帖子 后突然来了灵感,
把之前做的 v2ex 脚本中的图片上传功能抽离出来,做了一个通用的图片上传脚本。
主要功能


🔗 安装链接
基于哈雷佬的 Claudix 改造,将 OpenCode 带入 VSCode 侧边栏。
在 VSCode 里直接使用 OpenCode,自动连接本地 server。
opencode serveCtrl+L 发送选中代码,右键菜单添加文件早期版本,未经深度测试! 可能存在各种 bug,欢迎试用并在 Issues 反馈问题。
下载 最新 Release,在 VSCode 中:扩展 → “从 VSIX 安装…”
感谢 @Haleclipse 提供的 Claudix UI 基础
佬们有这个需求,我调研了一下,droid 果然不赖,而且明显比 codex 内工具调用快。
现在不光挂载了 droid cc 和 cx 可以调度 droid, 且,droid 也可以调度 cc cx ge 和 oc! 这样完全可以以 droid 为主 ai。 也变相实现了 codex 的并发。
肝坏了,掌声和在哪里。
给不了解 ccb 的 l 佬一句话介绍,一键打开 1-5 个不同 ai 工具完全版,然后他们之间可以相互通讯和调度,可见可控拉满。打个麻将斗个地主,甚至形成牛马链:a 发任务给 b b 再发给 c,形成 ai 蜈蚣,不在话下。 想怎么玩怎么玩。
用了就离不开 群友都这么说!可加群 github 有
本人前几天看到了 Gemini Voyager 这款插件,试用了一下觉得还不错。
作为向往成都团子的一名 Javaer,团子下面的 AI 我是都试过,Nocode、Catpaw、LongCat。(能在 L 站看到团子大佬吗?可以指点小弟一二否?)之前在 Catpaw 交流群中,我就 @官方说要不要加一个文件夹功能,第一方便查找之前的聊天记录,第二是直接拿一个软件网页版就能挤占知识库领域的份额难道不香吗?当时群里还有一些人觉得这个功能没用,可能需求不同,我觉得还是挺有用的。
而且该说不说,LongCat 在某些场景下确实还是会用到的,有三个原因,第一是因为他快,第二还是快,第三还是快!是真的快,而且每天还有免费 API 领,拿来练手学习 AI 开发也是不错的。回归正题,所以想着给 LongCat 贡献一下自己的代码吧(实际上是 Gemini 贡献的)总之,也是忙活了 6 个多小时,最后终于搞出来一版个人觉得还行的插件了。结果如图,对原来页面的侵入性还是很小的。感兴趣的可以去 Github 地址看一下,并且动手点个 Star,感激涕零。
Github 地址: 1parado/LongCat-Folder
原贴
前些天看到大佬发了个开源的 outlook 管理工具,个人还是更喜欢使用 docker,所以在大佬的基础上加了 docker 的部署方式,功能和原版一致
2026-01-21 更新公告
*添加因为某些网站有反爬机制无法访问的情况,优化了输出的内容* YuJunZhiXue/StudyAnalysis-Skills: 深度解析链接、文档或代码,生成 “全能导师级” 的教学笔记
github 访问不了的各位可以查看 gitee
yangyuhou/StudyAnalysis-Skills
本人目前正在修改,由于有的网站有反爬机制,比如知乎,正在尝试修改 SKills
如果可以的各位尽可能 star 一下
注意
如果不生成文件,请将 SKills 中的 data 文件删除,这是最重要的,让他重新自己创建即可!!!
下面部分是在 Skill 中的调用方式
何时调用 (When to use)
当出现以下任一场景时,请立即激活本技能:
- 显式学习指令:
用户明确要求:“学习这个”、“深度分析”、“深度学习”、“解析”、“解释这个概念”、“存入知识库”。
用户要求:“把这个讲清楚”、“教我怎么用”、“总结并生成笔记”。
关键词触发:只要用户提到 “学习” 或 “分析” 配合某个对象,必须激活。
- 复杂多模态输入:
用户提供了一个或多个 URL 链接(尤其是包含大量信息或图片的链接)。
用户上传了文档文件(PDF, Word, Markdown, TXT)。
用户上传了图片(PNG, JPG),且图片内容包含大量文字或图表(如架构图、思维导图)。
混合输入:同时包含链接、文字描述和图片。
- 代码深度解析:
- 用户选中或上传了代码文件,并询问:“这段代码是怎么跑的?”、“架构是怎样的?”。
- 隐式教学需求:
用户表示困惑:“我不理解这个概念”、“太难了,看不懂”。
用户需要降维打击:“用大白话解释一下”、“给个小白能懂的例子”。
实话说,我也经常被那些长得离谱的技术文档搞得头大。再加上现在的技术更新太快,资料一个接一个,代码库看的两眼迷茫。
尤其是每次想静下心学点东西的时候,没过半小时就放弃了,这种感觉真的很让人沮丧。
在记忆心理学里,这被称为 **“认知负荷”**。我们的大脑在同一时间能处理的信息量是非常有限的。如果资料里充斥着大量冗余信息、凌乱的逻辑,大脑会消耗掉绝大部分能量来理清这些噪音,导致你根本没力气去真正 “学习”。
所以我开始尝试把这些 “费劲” 的环节交给 Skills 来处理。
比如当我面对一个几万字的 GitHub 项目文档时,我不会直接去读,而是先运行我编写的 knowledge-absorberSkills 。这个 Skills 帮我完成了最痛苦的部分:
自动过滤掉啰嗦的客套话和重复的背景说明。
只抓住最核心的架构逻辑和关键 API。
把深奥的术语换成小白都能听懂的直白话语。
功能基本上就是给链接,给图片,给文档,给 PDF 给你读取,如果是长文本会自己截断,然后会生成 Html 和 md 两个格式文件,比如说你不爱看 md,可以直接把 html 拖入到浏览器观看 比如这篇文章很多字,看不懂说的什么
那么使用 SKills 来完成 效果图如下:
说到底,现在的知识获取已经不是拼体力,而是拼谁更会利用工具来 “武装自己”。
把那些繁琐、消耗能量的活儿交给 AI,交给 Skills,把最宝贵的注意力留给真正的思考。这才是这个时代最不焦虑的学习方式。
祝愿大家能够有完美的知识获取体验!!!
给各位开源啦。90% 的代码是 AI 编写的,有需要的功能可以跟我说。自用自用。
提示词管理 GitHub 地址: https://github.com/gaohp990421-bot/prompt.git
大 BUG 苹果手机可以任意改区
https://github.com/straight-tamago/misaka26
iOS /iPadOS 16.0 - 26.1 & 26.2 beta 1
Supported iOS 16.0 ~ 26.1 & 26.2 beta 1
和大家分享6个我收藏夹里雷打不动的网站。这些工具不是那种看着炫酷但一年用不上一次的“吃灰”神器,而是真真正正能解决日常痛点、提升效率的好东西。 这是一个最近很火的 AI 搜索工具,我用它已经基本替代了传统的搜索引擎。 它好在哪? Perplexity 不一样,它会直接读完网上的相关内容,然后给你写一段总结好的答案。最关键的是,它说的每一句话后面都会标一个小数字,点一下就能跳转到信息的原始出处。 这对查资料太重要了。用 ChatGPT 有时候它会一本正经地胡说八道,但 Perplexity 给了出处,你就可以去核实,心里更有底。平时写报告、做技术调研,或者只是查个冷知识,用它效率非常高。 这是一个非常有特色的在线白板工具,我特别喜欢它的“手绘风格”。 为什么用它? 平时工作中经常需要画图,比如画个业务流程图、系统架构图,或者给同事讲讲思路。用 Visio 或者那些专业的绘图软件,虽然功能强大,但操作太繁琐了,而且画出来的图太正式,有时候反而让人不敢随便改。 Excalidraw 打开网页就能画,界面极其简单,连注册登录都不需要。画出来的线条像是在纸上手画的一样,有一种草稿的感觉。这种“非正式感”反而能让人专注于逻辑和结构本身,而不是纠结线条直不直、颜色对不对。 它还支持丰富的素材库,像什么 AWS 的图标、各种 UI 组件,直接拖进去就能用。画完了可以直接复制图片,或者导出成文件,非常方便。 这是一个在线文件处理的好网站,专门解决那些不想装软件的临时需求。 解决什么痛点? 为了这点小事去下载安装一个几百兆的专业软件,既占空间又费时间,甚至还可能不小心装上一堆流氓软件。 123apps 就是把这一堆小工具全整合在一个网站里了。视频剪辑、音频转换、PDF 合并拆分、录屏,几乎涵盖了所有常见的文件处理需求。你需要什么功能,点进去把文件拖进去,处理完下载走人,干脆利落。 如果你经常需要分享代码,那这个网站绝对是颜值担当。 它有什么用? Carbon 就是专门解决这个问题的。你把代码复制进去,它会自动给代码加上高亮颜色,还能给图片加上漂亮的背景框和阴影,看起来就像是一张精心设计的海报。 你可以自己选配色主题(比如类似 VS Code 的风格),选编程语言,甚至调整窗口的圆角大小。做出来的图往 PPT 里一放,专业感立马就上来了。 这是一个把所有开发文档都装进口袋的网站。 极客首选 DevDocs 把几百种编程语言和框架的官方文档都抓取下来,整合成了一个统一的界面。 它的搜索速度极快,支持模糊搜索。而且它支持离线模式,你可以把常用的文档缓存到本地,哪怕断网了也能照样查。界面干净清爽,没有乱七八糟的干扰,就是纯粹为了查资料而生的。 很多人以为 GitHub 只是程序员存代码的“仓库”,其实它更像是一个巨大的技术宝库和开发者社区。 它能做什么? 首先,它确实是目前最好用的代码托管平台。无论你是写一个小脚本,还是开发一个大项目,把代码传上去,既安全方便,又不用担心硬盘坏了代码丢了。 其次,这里是找资源的神器。想学 Python?搜一下就有无数的教程和示例代码。想做一个博客?上面有很多现成的模板,改改就能用。 甚至很多面试官都会看你的 GitHub 主页,如果你经常在上面活跃,提交代码,或者给开源项目做贡献,这绝对是你简历上的一大亮点。 简单说,不管你是想找现成的轮子,还是想学习高手的代码,或者只是想存一下自己的学习笔记,GitHub 都是绕不开的。 以上就是我强烈推荐的6个网站。它们每一个我都用了很久,希望能帮大家节省时间,少走弯路。 如果对你有帮助,点点关注点点赞Perplexity AI

以前我们搜东西,比如搜“Java 怎么读取 Excel 文件”,搜索引擎会甩给你一堆链接,让你自己一个个点进去看,有的链接还是广告,或者内容早就过时了。Excalidraw

123apps

大家肯定都遇到过这种尴尬情况:突然需要把一个视频转成 GIF,或者要把 PDF 里的某一页拆分出来,又或者是一段录音需要剪掉开头那几秒杂音。Carbon

有时候我们在写文章、做 PPT 或者在群里讨论技术问题时,直接把代码截图贴出来,往往模糊不清,还很难看;如果直接复制文本,格式又容易乱掉。DevDocs
写代码离不开查文档。一会儿查 HTML 标签,一会儿查 CSS 属性,一会儿又要看 Python 的库函数。如果每次都去各自的官网查,要在浏览器里开一堆标签页,而且每个官网的排版、搜索方式都不一样,很心累。GitHub
Matrix 首页推荐
Matrix 是少数派的写作社区,我们主张分享真实的产品体验,有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章,展示来自用户的最真实的体验和观点。
文章代表作者个人观点,少数派仅对标题和排版略作修改。
人生中的第一个独立开发的 APP 终于通过审核了,这篇文章的重心不在应用推介,更多是记录我作为一名运营独自一人开发应用上架的完整历程。年纪大了,如果当下的感受没有被及时记录,很容易会被时间冲淡。

文章不会涉及到太多专业术语露出,无论你对 AI 编程是否感兴趣,都可以把它当个有趣的故事看下去。
我貌似一直对写应用 / 做产品有一种执念,尽管我连 GitHub 怎么用都一头雾水。
2014 年,因为经常要写 APP 推荐文的原因,为了丰富截图美观度,联合少数派的 Android 开发小哥倒腾了个【带壳截图】。当时的我,负责的只是想法、素材设计和宣传推广,没有参与过半行代码的编写。
2023 年,当时部门被公司一锅端,突然失业的我申领失业金频繁受挫,靠着每天把免费版 GPT 额度用完,很是艰难地倒腾了个如何申领失业金的微信小程序。这是我自己第一个手搓代码的的产品,这阶段的我开始掌握了「如何插入广告代码」这一核心技能。
2025~2026 年,因为工作缘故要经常输出鸿蒙相关的内容,我先是做了个缓解鸿蒙升级阵痛的小程序,后来在 Gemini 的帮助下,我正式提交了人生中第一款独立开发的 APP,一个能联网的、打通服务端和前端的、有实际功能的、不再是静态页封装的应用。
所幸每一个阶段的产品,我都在少数派写过文章,留下过印记。

早在去年鸿蒙推出开发者激励计划的时候,老麦就问过我能不能倒腾个鸿蒙应用,我说这超出了我的能力范畴。其实彼时的我已经写过好几个小程序了,然而在我的固有认知里,小程序和 APP 开发的区别应该比美图秀秀和 PS 还要大...... 加上现在鸿蒙编译工具和原生开发语言才推出市场没多久,可能 AI 都没有收集到足够的数据来应对。
事实证明一切都是借口,真正实践起来,我这个 GitHub 都用不明白的家伙,从 12 月 30 日配置到鸿蒙开发环境,到 1 月 5 号正式动工,最后 1 月 10 日提交审核,减去中间的元旦假期和周末,整个开发周期差不多就一个星期左右。

挣脱了思想的牢笼后,一切就豁然开朗了。
无论是 Gemini、ChatGPT,还是其他更进阶的 AI 编程服务,对网络和地区的要求都是极高的。网络的波动,经常会导致「地区限制、IP 污染」等拒绝访问的情况发生,哪怕能顺利进入,也会有一定概率只能新建聊天但无加载历史对话。
付钱也是个大问题,搞定了网络,也舍得每个月掏出 20 美元甚至更高的费用去订阅,但如果没有一张境外发行的银行卡或海外账户,那么大概率无法完成关键的付款操作。当然,真想要给钱还是有路子的,只不过给个钱甚至比软件破解还要费劲,又会劝退很大一拨人。
社交媒体上铺天盖地的都是「不懂代码也能编程」的帖子和教程,但目前市面上一些主流的 AI 编程工具其实都是需要使用者具备一定专业技能的,强如 Cursor 一打开就让我关联 GitHub 的代码仓库,单就这一步就直接难倒我了。
同时,零代码基础,意味着你无法判断 AI 输出的方案优劣 / 对错 / 是否最优解,AI 会偷懒、会造假、会胡说八道、会消极怠工...... 没有专业能力去支撑你的判断与决策,一旦涉及关键模块的改动,轻则影响项目进度,重则前功尽弃,推倒重来。
大 Boss 藏在临门一脚的收尾阶段。
从 2025 年开始,所有联网的应用都需要进行 APP 备案。然后备案要买服务器,买完服务器提示要买域名,买好域名之后又提示域名也要备案,要域名和服务器备案好了 APP 备案才算完成。兜兜转转,搞了差不多 1 个月才搞定。所幸只是耗时长,过程并不复杂。

来到核心的应用审核环节,由于之前提交审核的版本功能实在过于简单(体验与小程序保持一致),多次上架驳回,让我下定心思真正做一个有实际功能用途的 APP。于是乎,我拾起了 10 年前的带壳截图项目,因为应用名称已经备案了,所以我还是沿用【NEXT 升级站】这个名称,在截图带壳的基础上,新增了图层顺序调整、设备素材云端下载与更新、添加贴纸、设备形态切换等功能。

1 月 10 日,我将重新构造的 NEXT 升级站提交到鸿蒙应用商店;1 月 16 日,经过了多次沟通和调整之后,NEXT 升级站终于顺利通过审核,正式登陆鸿蒙平台。得知应用审核通过的瞬间心情还是非常激动的,毕竟花了这么多心思去打造,肯定是想让它呈现在公众面前,供有需求的人去使用。

因为 Chat 形态的 Gemini 不能直接操作项目,所以从配置环境的安装到最后的签名打包,涉及到开发环节的每一步,全都是 Gemini 输出文字指引,我来进行操作。虽然是原始了点,但一步一脚印,也不算是一件坏事。在这个鸿蒙应用开发项目里,我主要扮演产品经理和交付验收专员的角色,Gemini 则负责以下工作:
我不太清楚近期火热的 Vibe Coding 能否全自动地完成项目的代码编写和程序编译,因为我没真正使用过,一来是文章开篇提及到的网络问题,二来也是我自身专业度不足以支撑的问题,当然最主要的还是自我设限,认为自己驾驭不到。
有机会尝试的话,再给各位输出一篇关于 Vibe Coding 的体验文章。
Gemini 的靠谱程度,很大程度取决于你是「开新坑」还是「优化屎山代码」。如果是「开新坑」,决策准、速度快、效率高、完成度高,会是我对它的评价;一般这种情况下的需求指令都不会特别清晰或具体,这时候的它有足够的发挥空间,Gemini 擅长写半开放式作文。
一个具体的例子,10 月初我想把初始版本的【NEXT 升级站】小程序想快速移植为鸿蒙应用,在 GitHub 找到了滴滴出品的星河小程序转译鸿蒙应用的开源项目,专门请教了公司的开发同事,询问一下这件事情在技术层面的可行性,得到的结论是不行,斩钉截铁的不行。

随后,我将这个具体的想法交代给 Gemini 后,它给出的答案也是不行,但同时提出了另一种解决方案:因为我的产品架构很简单(本地搭好页面框架,从腾讯云读取数据),无需转译,直接用鸿蒙原生开发工具写一个更简单。
然后,它就手把手教我从如何安装配置鸿蒙开发环境、如何配置页面、如何调用组件、如何读取数据、如何解决编译报错、如何真机调试等等。因为我小程序已经写好了逻辑,所以它列了几个关键的 js 文件让我发过去,它就能复用对应页面的数据读取、字段展示、排序逻辑、元素布局等。
效果非常惊人,花了 1 天的下班时间,我就已经完成从搭建鸿蒙开发环境到输出 Demo 能在真机安装运行了。虽然一开始 Gemini 并没有告诉我 Beta 版编译工具签名的 APP 无法提交审核,但那是后话了......

但场景一旦切换到「具体功能优化、Bug 修复」时,当需求越具体,它就会变得越固执、越短视、喜欢钻牛角尖、重复造轮子、简单的事情复杂化:

诸如此类各种数不尽的骚操作,逐渐倒逼着我自己去管控整个项目走向。慢慢地,我这个毫无感情的代码复制粘贴机器,也开始系统性地判断 Gemini 输出的技术方案思路是不是可行的,给出的方案有哪些考虑不周到的地方,存在哪些风险,需要做哪些准备工作,备份哪些关键文件,实施过程中可能会发生的问题以及应对方案等:

见证我踩坑与进化的,是每次下达精准修改需求时越来越长的注意事项:
背后的心酸,只有我和 Gemini 才能知晓。
虽然开发环节总是会出现这样那样的问题,但在整个应用构建过程,我始终保持着非常激动甚至亢奋的心情。关键的转变在于我从某个环节的螺丝钉变成了整个链条的掌舵手,提出想法的是我,需求评估的是我,原型设计的是我,敲定技术实现方案的是我,字段配置、代码编译、功能验收、BUG 修复、功能迭代的还都是我......
每天结束代码编译工作时,我都会和 Gemini 复盘一下今日的成果、踩过的坑、明天的计划、以及突然冒出来的鬼点子。看着应用从最初的原型图,到一步步完善,最后成为能在真机运行的应用,成就感可以用爆棚来形容。


铺垫了这么久,是时候要请出主角了。NEXT 升级站聚焦于截图编辑与创作,支持带壳截图、快速切换设备形态、添加贴纸、云端更新素材库等。应用支持联网更新,即使不更新应用,也能获取到最新的设备素材与贴纸。
在产品架构设计阶段,应用内几乎每个环节我都加上了支持运营控制的字段与配置入口。除了机型素材和贴纸中心,还包括创作页背景、机型默认壁纸,甚至连遮罩颜色和透明度等,都可以在云端直接修改更新。节假日定期换个应景的素材,或和其他应用联名搞搞活动,是我作为一名老运营的职业习惯。

核心的截图创作页上,我将「机型系列」作为一个最小单位,一个单元内对应多个 SKU,下载对应素材后,可以左右切换更换同系列的姐妹机型与颜色。如果是涉及到折叠屏这种多形态变化的产品,同样可以通过左右切换,快速更换设备形态。


同时,「贴纸中心」的加入,大大丰富了截图的可玩性,这也是 NEXT 升级站区别于同类应用的一大特色功能。支持图层顺序调整带来了无限大的拓展空间:除了常规的表情贴纸,它可以是画布壁纸,还可以是契合产品的具体使用场景、更可以是模特手持的特写海报。


由于贴纸引入了图层概念,所以正常情况下只需新增一个图层字段或贴纸类型,就可以实现「图片背景」这一功能了,写好逻辑本地处理,当检测到图层字段等于 0 时,图片自动置底且铺满画框。道理是这个道理,但可惜,目前我的水平无法支撑这个需求的实现;不仅没有实现,还出现了同一个素材从创作页添加是正常的,但从贴纸中心添加就不能显示的奇特 Bug,折腾了好久才恢复到原样来。
此外,在原本的产品规划里,我是打算将 Navigation bar 和 tabBar 统一都设置为半透明的毛玻璃效果,让壁纸能够完整铺满整个屏幕,体验更加沉浸。但这涉及到全局组件的改动,加上当时风险管理意识不足,一番操作下来,布局全乱,软件元素和系统安全区叠加在一起,越改越乱,最后不得不代码回滚。
这也是这个版本里为数不多的遗憾。
我对图标尤为看重,7 天的开发周期,图标绘制就占了我整整一天的时间,可见重视程度之高。我希望 NEXT 的图标是有质感的、且符合应用使用场景的,在小红书找了几个我想要的效果素材发给 Nano Banana Pro,结果输出的第一个方案里就有对胃口的版本,这让我极其欣喜。

我完整阐述一下我的图标绘制操作和思路:
为什么要重绘图标?

我个人不太建议直接使用 AI 输出的图片作为图标。
一来是 Gemini 无法输出透明背景的 png,虽然市面上大把移除图片背景的工具和插件,但移除背景这个动作本身就会对图片质量本身产生较大影响,如边缘锯齿、阴影裁切、残留白边等;
二来应用图标在软件项目构造里并不是一张单纯的圆角矩形图,它是由一张透明背景的主体图 + 一张保留直角的背景图组成的;
三是考虑到 AI 输出的图片可能存在的版权归属问题,以及后续图标的拓展延伸(如面向付费用户提供多种图标切换、应用周边制作、品牌宣传露出等),几乎每个场景都需要你有「源文件」在手,而不仅仅只是一张 AI 提供的固定分辨率、放大会有锯齿的位图;
所以让 AI 输出方案 + 重绘修改,会是一个相对稳健且方便后续运营拓展的方案。哪怕你是设计新手也不要紧,目前主流的 AI 基本上可以做到专属教程产出,发一张图片过去,询问如何在 Photoshop 或 Figma 上绘制出一模一样的效果,它就会输出详尽的教程,包含每个图层需要叠加的效果参数、渐变色值等。
当然,图标重绘并不意味着百分百的还原 AI 稿,更多是根据实际情况进行风格和元素的调整,毕竟是手把手操作,灵活度上还是要比输入关键词指令更精准一些。我对这个工作流输出的图标成品很是满意(目前应用商店显示的图标和实际图标对不上,我争取下个版本修复)
介绍完应用功能和图标,我想展开聊聊 NEXT 升级站名字的来源和背后的功能变更。
故事的开始是去年我主力使用的华为设备升级到鸿蒙 5,在日常使用中或多或少都会有一些困扰与不习惯,于是我针对常见痛点梳理了解决方案,拾起老本行做了个微信小程序承载。想着解决他人问题之余还能靠流量主赚点广告费,没成想鸿蒙版的微信小程序并不支持加载流量主广告 😂 路径依赖失效了~

但每个月 19.99 的腾讯云套餐是无论如何都节省不了的支出,怎么样才能把这 19.99 用回本成为了我的新课题。既然腾讯云能被小程序调用,是不是也能被第三方网站或 APP 调用?我向 Gemini 提出了这个问题,得到了肯定的答复,随后我就搞了个页面,通过云函数将小程序的内容同步展示到网页来。不过这个页面更多是技术验证,并没对外开放访问。

小程序有了,引流页面也有了,作为一个面向鸿蒙用户提供解决方案的产品,没有鸿蒙原生应用似乎说不过去。刚开始我是打算通过「小程序转译」的方式去实现,结果 Gemini 告诉我直接原生编译工具写更简单。接下来的故事前文也提及过了,初始版本的应用多次被驳回,一是联网应用没备案,二是功能实在太过简单。

应用审核被驳回,但耗时一个月的应用备案下来了,秉持着备案不能白白浪费的原则,我又硬着头皮搞了如今以截图编辑与创作为核心的【NEXT 升级站】并成功上架,也算是给 10 年前的【带壳截图】一次秽土重生的机会。

所以现在的 NEXT 升级站处在一个非常神奇的阶段,同一个名字在不同渠道是两个完全不同形态的存在。在微信小程序里,它是提供各种常见问题解决方案的实用工具箱;在鸿蒙原生应用里,它是可以实现以带壳截图为核心的截图创作工具。至于后面究竟是逐渐融合还是单独区分,就有待后续故事的发展了,现在的我也说不准。

回顾 NEXT 升级站每一次的更迭,基本上都是脑海里的灵光一闪在稍纵即逝之际被 Gemini 及时验证可行性并给出实施方案,我才得以踏出下一步的。我认为这是 AI 存在最大的价值,通过 AI 快速验证各种天马行空想法的可行性,并以最低成本踏出第一步,只要出发了,距离终点就不远了。
我来简单盘点一下本次开发全链路的所需费用。
以一年时间为例,最基础的费用支出是 340.8 元。当然,实际上远不止这个价格, 正常情况下 Gemini 应该是最费钱的一项。除符合资格的学生优惠外,最近 Gemini 还推出了 $99.99/年的多人共享活动,就是对地区、账号和付款方式都有一定要求,感兴趣的可以去了解一下。

这是 2026 年我送给自己的新年礼物,突破身为一个运营原定能力边界的礼物。
简单评价一下这个开发周期只有 7 天的应用,我认为功能完成度是大大超出我预期的。代码质量我不好评价,后续版本维护上我也比较担忧,但在产品架构、功能完善度、可玩性上,我有信心,NEXT 升级站起码是合格的,甚至是超过平均水平线的。
当然,初个版本还是有很多不足的地方,受限于技术水平与人力原因,很多东西距离「尽善尽美」还有很长一段距离,不过大框架搭好了,素材也能支持云端更新,后续保持一定的频率更新,问题也不大。
> 关注 少数派小红书,感受精彩数字生活 🍃
> 实用、好用的 正版软件,少数派为你呈现 🚀
vibe 了一下 codex cli,改名叫 aish。让它不再专门在某个项目目录写代码。作为一个 shell 命令辅助工具运行,比如想不起来哪个复杂的 shell 命令的时候,随时 aish,然后提问…
GitHub - chunhuitrue/aish