AI 能让代码写得更快，但在「不能出错」的分布式存储系统里，如何确保提效不变成风险？本文结合美团基础技术部在 AI 评审、问题排查和自动化开发中的真实实践，分享 AI 能帮上什么忙、容易在哪些地方犯错，以及哪些地方仍需要人来把关。比「多写代码」更重要的，是让代码和结论经得起验证。希望这些经验能为复杂系统中的 AI 应用提供参考，在享受效率提升的同时，守住质量与稳定性的底线。 1. 背景：为什么分布式存储需要更审慎地使用 AI Coding 今年年初以来，随着Agent的普及，AI Coding 在功能开发、测试生成、脚本编写和执行、问题排查这些场景里都已经用得上了：读代码更快，实现和测试可以先让它写一版，研发之外的一部分杂活也能交给它去跑。 效率上去了，质量上的账也要重新算。同样的人力，一个版本里能交付的功能更多，改动的代码也更多，就算 AI 写的代码千行缺陷率和人写的持平，一个版本累计引入的缺陷绝对数量照样会涨。所以 AI Coding 的目标不能只是更快地写代码，提速的同时，代码质量和验证充分性还得比常规研发要求得更高。 分布式存储把这个问题放大了。代码规模大，模块之间关系复杂，一致性、并发、持久化、故障恢复和性能每一项都碰得到。一处看上去很局部的改动，平时可能一切正常，等到节点重启、磁盘异常、网络抖动或者高并发的时候才暴露出来。出了问题，受影响的也不会只是某一个功能，而是上层业务的数据可用性和系统稳定性，严重时还会波及数据正确性。存储服务支撑着大量上层业务，故障影响面大，修复也困难，对缺陷的容忍度极低。 要满足这样的质量要求，光让 AI 生成代码不够，AI 评审（Code Review）、AI 测试与验证、AI Debug 和受控自动化也得一起建起来，AI 生成的代码才能放心地进入研发流程。本文结合存储团队在 AI 评审、AI Debug 和 AI 自动化上的实践，讨论在分布式存储这类复杂度高、容错低的系统里，怎样一边用 AI 提速，一边靠更严格的评审、测试、调试和自动化验证守住稳定性与数据正确性，希望对其他类似系统落地 AI Coding 也有参考价值。 2. AI 评审（Code Review）：有益补充，但不能替代人对设计背景的判断 2.1 AI 评审擅长的地方 1. 能注意到跨文件一致性 例：ENABLE_UNITTEST 在三处调用点控制测试 mock 变体的编译分支，但…

Read More

上线了一个免费的 AI 图片质量增强站 https://hdimageenhancer.com/ 主要解决这些问题： 手机拍糊了、压缩过度 老照片、扫描件发灰发软 商品图 / 截图分辨率不够 想直接升到 HD / 4K 再发网页或打印 用法很简单：拖图上去 → 等几秒 → 下载。支持 JPG / PNG / WEBP / HEIC ，单张最大 25MB 。 目前免费就能用，每天有免费额度，不用注册也能试。 欢迎大家扔几张图试试。有 bug 、或建议）直接回帖

Read More

看来厨子的库存还没用完

Read More

各位佬好！ 先说说我为什么做这个站。 我一直向往自由，喜欢去中心化，不喜欢被束缚。 所以做了 InitAPI：主打 Uncensored 破甲模型，把审查拆掉，把选择权还给使用者。 新站开业，送一波测试额度，欢迎大家亲自跑一跑。 开业福利，合计 $15 （本站 USD 计费）： 注册＋回帖送 $10：进官网注册，回本帖留下你的 InitAPI 用户 ID ，$10 直接发到站内账户，不用先充值。 加 TG 群再送 $5：加入官方 TG 群，把用户 ID 发给群管理，核对后发放。 每人限领一次，两份都领到就是 $15 。 领取步骤： 进官网 https://initapi.ai 注册登录。 在个人设置里找到自己的用户 ID （是用户 ID ，不是 API Key ）。 回本帖留 ID ，格式：用户 ID：qq123 我们会按回复顺序核对并批量发放。注意保护隐私：只留 ID ，绝不要公开 API Key 和密码。 主打模型： 破甲版…

Read More

岗位职责1. 平台运营规划与全球化布局–负责游戏生态与分发平台的全面运营战略规划、核心业务目标制定与全球化落地，对平台整体 DAU 、MAU 、生态健康度及商业化营收全面负责。–统筹平台在海外重点市场的本地化运营与破局，制定差异化的海外市场推广策略及用户获取（ UA ）方案。2. 海外市场推广与用户增长–主导全球化流量获客与品牌声量打造，擅长结合海外主流社媒生态（如 Discord 、Reddit 、X 、TikTok 、YouTube 等）开展裂变增长与矩阵式社群搭建。–建立并管理海外发行运营团队，深度拓展并维护与海外渠道、本地媒体及核心合作伙伴的战略合作关系。3. 具备全球化内容生态与创作者搭建能力–搭建面向全球的 UGC 创作者、开发者及工会/公会招募、孵化与全生命周期管理体系，驱动内容生态自循环。–把控平台内容安全、合规性及海外本地化标准（如 GDPR 隐私保护、版权规范与内容审查机制等）。4. 商业化闭环与精细化运营–统筹平台多元化商业化变现路径（如付费订阅、全球化支付生态、分成机制等），持续优化全球不同区域的 ARPU 值与 ROI 模型。–建立科学的全球化数据监控与漏斗分析体系，通过数据驱动产品迭代、跨国本地化适配及精细化用户分层运营。5. 跨部门统筹与项目全盘管理–站在平台全局视角，高效协同产品、技术、海外发行、设计与本地化团队，输出高质量的需求规划（ PRD ）、用户流程及全球化交互设计规范。–严控项目排期与技术架构风险（如全球服务器并发、大文件分发、海外网络延迟优化等），保障平台在全球范围内的平稳高效运转。任职要求1. 基本背景统招本科及以上学历，具备 6-10 年及以上 互联网/游戏行业从业经验，其中至少 3-5 年 大中型游戏平台、应用分发平台或出海工具/社区产品的核心运营负责人管理经验。具备成熟的海外游戏发行或海外平台运营实战操盘战绩，有完整大体量出海项目成功落地经验。2. 核心专业能力全球化视野与海外推广能力：深刻理解海外主流游戏文化及用户心智，精通海外社媒裂变及本地化获客底层逻辑。平台级统筹与架构破局能力：不局限于单点业务，具备大盘视角，能统筹“技术-产品-运营-商业化-海外发行”的全链路闭环。商业化与创作者经济操盘经验：对全球化平台的变现模式、分成机制及创作者生态有深刻认知，具备跨国商业合作谈判与 ROI 优化能力。3. 软性素质团队管理与跨部门协同能力：具备优秀的大局观与跨文化团队管理经验，能够在执行层面扎实落地的同时，具备主动思考、前瞻性全球规划及跨部门高压协同的领导力。 岗位补充说明：远程 感兴趣联系 TG@aaaaaawe123

Read More

78 年生，高中学历，目前在扬州，可以去外地工作。 做跨境电商十多年，面向美国市场，英语好。熟悉 Amazon 、Shopify 独立站，擅长选品、产品开发和营销推广，有小小的百万美元级广告投放经验，也做过亚马逊采集、选品等软件开发。 **我比较擅长从 0 到 1 全盘操盘，一个人可以跑通选品、建站、广告、产品和供应链等多个环节。** 创业过两三次，最近一次个人创业做出过两个小爆款，累计净利润约 80–90 万元。 这十几年一直没有停止思考和学习，我觉得自己对选品、营销和商业化的理解比几年前提高了一个档次。 最近重新找工作，智联招聘投了可能上千份简历，只有两三个人加微信，大部分回复都是不合适。可能年龄和学历确实是短板，但有实操经验、有过盈利结果，为什么连展示能力的机会都很难得到？ 目前希望找一个管理灵活、重视结果的团队，把十多年的经验带进去，可能会上班个几个月，最好有底薪加提成。我愿意亲自下场做业务、提高业绩，先赚个几万元，继续开发自己的美国汽车 OBD 产品。 想请教 V 友： 1. 我这种背景，应该去哪里找机会？小型出海公司、程序员创业团队，还是项目制合作更合适？2. 如果不想被年龄和学历卡住，怎样才能让别人看到我的实际能力？还有什么更好的赚钱思路？3. 这里有没有技术创业团队、出海团队需要懂跨境电商和海外营销的人？ 欢迎大家给点实在的建议，也欢迎批评，谢谢！

Read More

算法工程师的一天是“改代码—提交训练—等待—看日志—决定下一步”，过程中还经常被打断。我们团队从 Karpathy 的 AutoResearch 出发，经过三次架构重构，搭建出一套可在企业云端训练平台使用的算法研究自进化系统：系统从单线程 LOOP 探索升级为 CyclicGraph Engine 图探索架构，用状态机保证长周期运行的稳定性，并通过“业务知识库 + 真实大闭环 + 经验自动沉淀”实现系统自进化、越用越好用。 在结构、目标与场景均不相同的两个业务建模项目中，单任务完成耗时较人工基线分别减少约 85% 与 83%，其中一个算法模型已将系统自主推导的方案推全上线，并取得线上收益；另一个多目标项目中，系统产出的方案在全部 12 个预估目标上同时超过人工基线。两个项目唯一的共同点是同一套系统架构，说明增益来自架构本身。本文分享这套系统的设计理念、架构演进与可信度设计，希望对大家有所帮助或启发。 1 背景：算法工程师的时间都去哪了？ 一个算法工程师的典型工作流是：修改代码、推送代码、提交训练、等待、查看日志提取指标、与上一轮对比、决定下一步。等待的间隙，工程师会切换到其他任务，但切换有成本，时间利用不充分；如果训练在凌晨完成，还要等到第二天继续。一天下来，大约完成 2~3 次实质性迭代。真正需要判断力的环节，反而被切换和等待挤压得所剩无几。 2025 年底，Andrej Karpathy 开源了 AutoResearch：一个在单张 H100 上训练 5000 万参数教学级 GPT 的实验原型。仓库只有三个文件：program.md 用自然语言描述研究规则，train.py 是 Agent 唯一可自主修改的训练代码，prepare.py 负责评估。正是这个极简组合，让 LLM 驱动的研究在夜间和周末自动运行。约两天内，系统运行约 700 次实验，产出约 20 个针对 val_bpb 的正向提交。这套循环背后有一个刻意的信任设计：负责评估的 prepare.py 被冻结为不可修改文件，Agent 只能改训练代码而不能改评估函数，从机制上杜绝了“篡改裁判”的可能；而 keep/reset 的 Git…

Read More

搜索和推荐场景中想要使用语言模型提高在线效果，往往面临着在线极低延迟的约束，现有通用大模型推理引擎并非在这一延迟约束下设计，因此本文从「具有确定 decode 次数上界的请求」这一工作负载出发，重新设计在线执行路径：以静态 DAG 组织完整业务请求，结合 AOTInductor 编译、Packed Prefill、请求内 K/V 共享及选择性 FP8，系统性压缩调度与计算开销。在平均端到端时延低于 20ms 的约束下，Prefill-only 有效 MFU 达到 67%，吞吐较 SGLang 提升 10 倍，为 SLM 在搜推场景的大规模落地提供了一套高性能、可复用的工程实践。 摘要 搜推场景下业界逐渐使用 SLM（Small Language Model， 小参数量语言模型0.5~1B），用于意图理解，相关性判断，生成式推荐等任务，这些模型保留 Decoder-only Transformer 和 Next-Token Prediction 的基本结构，但在线执行形态与开放式文本生成存在明显差异： Prefill-Only 模式：仅执行一次 prefill，根据每条序列最后一个有效 Token 位置的 logits 得到类别或分值，或基于 prefill 产出的 Embedding 接入 MLP 模块做分类任务； Beam Search 模式：执行一次 prefill 和固定次数 decode，在固定 beam…

Read More

美团在 MTGR 基础上提出统一推荐基座大模型 MTFM，首次实现外卖多个主要业务的统一精排模型。围绕规模可扩展性、场景可延展性与架构高效性三大挑战，MTFM以异构 Tokenizer 与动态掩码实现多场景特征免对齐，通过混合注意力与 Target Scale-Up 提升模型 Scaling 能力，借鉴 LLM 优化实践提升深层网络训练效果，并以 User-Level 训练范式与定制算子保证系统开销可控。美团外卖多个业务订单量提升 2.06%~6.68% 不等，推理成本降低 24%，相关工作已被 KDD 2026 收录。 1. 引言 我们去年提出了 MTGR[1] —— 一种新的生成式精排框架，在美团外卖推荐场景验证了 Scaling Law 的有效性，并取得显著业务收益。然而，推荐领域的 Scaling Law 探索往往局限于单场景内部，模型被限制在单场景孤岛中，跨场景的数据、算力和架构无法充分复用。在美团这一问题尤为突出，推荐覆盖外卖首页、拼好饭等多个业务场景，各场景长期独立建模。与此同时，大语言模型（LLM）已验证一条清晰路径：基座模型（Foundation Model）足以统一处理编程、数学、写作等多领域任务，也可以将文本、图像、语音等异构信息表示为 Token 序列并进行端到端学习，展现出了强泛化性与可扩展性。因此，我们认为美团推荐的下一个阶段关键在于打通跨场景的异构性，充分利用多场景数据提升 Scaling Law 的上限，即建设统一推荐基座大模型。 推荐基座大模型主要面临三个核心挑战：规模可扩展性（Scalability）、场景可延展性（Extensibility）和架构高效性（Efficiency）。规模可扩展性要求模型在参数规模、数据量扩大时，效果能够稳定、可预期地提升；场景可延展性要求模型能够低成本适配已有场景或接入新场景；架构高效性要求模型在处理多场景的海量数据时，训推仍保持可接受成本开销。 为解决上述挑战，我们在 MTGR 的基础上，提出美团统一推荐基座大模型 MTFM（Meituan Foundation Model for Recommendation）。MTFM 使用类 Transformer 骨干进行端到端建模，提出 Target Token Scale-Up 提升模型能力，借鉴…

Read More

综述 搭一个 Agent 正在变得越来越容易 过去三年，有两条趋势在同时发生。 一是基座模型的能力持续进化，它带来的结果是对使用者的要求在往下降。早期要让模型稳定地按格式输出、正确地选中一个工具，需要反复打磨 Prompt、设计各种兜底。现在这些能力越来越多地由模型本身承担，长上下文、原生工具调用、更强的指令遵循和多步推理，把大量原本需要工程去补的地方补上了。 二是 Agent 框架的功能持续丰富。从早期需要自己实现规划、记忆、工具注册和状态管理，到现在框架和协议层把这些抽象成标准组件，接一个工具、加一个 Skill，工作量都在显著下降。 两条曲线叠加，结论很直接：搭建 Agent 门槛正在逐年降低。这带来的直接变化是 Agent 落地场景越来越多，越来越发散。 评测认知的稀缺 自 2022 年底 ChatGPT（基于 GPT-3.5）发布以来，市场上出现了一波又一波 Agent 项目。但是那些真正走过冷启动、完成灰度扩量、推到全量的项目数量屈指可数。这导致掌握 Agent 评测方法的人非常稀缺。 过去三年绝大部分 Agent 项目都死掉了。它们消失的原因有一些共性： 停在 Demo：演示效果很好，一接真实流量就发现覆盖不住，用户的问法、数据的脏乱、场景的边界远超预期，团队疲于打补丁，最后不了了之。 卡在扩量：小范围试用还行，一放量各种问题集中暴露。团队既说不清问题出在哪一层，也不敢大改，因为改完不知道会不会把原来对的地方弄坏，项目在原地反复摇摆。 说不清业务价值：模型换了几轮，Prompt 迭代了几十版，团队自己觉得变好了，但拿不出证据。到了要资源、要继续投入的时候，回答不了“项目到底带来了什么”，最终停止投入。 这三种死法看起来不同，追下去会发现共同点：团队缺少一套可靠的判断机制。不知道当前版本行不行，不知道问题出在哪一层，不知道改完是真的变好还是换了个地方出错，也不知道怎么向外证明这件事的价值。做决策靠的是感觉和个别案例，而感觉在复杂系统面前不可靠。 把两件事放在一起看，会得到一个略显割裂的图景：搭 Agent 的门槛在快速降低，把 Agent 做好的认知却仍十分稀缺。并且，有限的评测认知面对发散的场景，同样力不从心。做好一个 ChatBot 的经验，并不能无缝泛化到做一个长程 Agent 身上。为此，我们希望将团队两年来在众多业务方中打磨出的评测的认知，以体系化的形式分享给大家，希望能帮大家少走一些弯路。 这个系列博客想做什么 前不久，我们发布了一篇博客《Agent 评测漫谈》，介绍了评测的核心方法论，回答的是“评测是什么、为什么这么做”。文章发出后，我们收到不少的反馈，其中出现频率最高的一类是：方法论看了，但具体到自己的项目，还是不知道从哪下手。 为此，我们计划撰写《Agent 评测白皮书》系列博客，体系化地为大家讲解评测的落地指南 —— 先做什么后做什么，每一步的产出物长什么样，做到什么程度算达标，遇到常见的坑怎么处理。计划分四篇： 本系列博客面向 Agent 产品、研发、算法、运营和评测负责人。如果你正在从零开始搭一个 Agent，或者手里的项目卡在某个阶段推不动，希望这几篇能提供一些可以直接用上的东西。…

Read More