【大模型/评测】近期大模型发布与评测要点如下：

一个开源项目怎么连续5天上GitHub Trending：阿里这篇复盘值得一看！ 阿里内部的AI Code Review工具开源两个月，20k star，连续5天上GitHub Trending首页。团队写了篇复盘，讲的是具体做对了什么、踩过什么坑，值得拆开看看。 1. 开源前先想清楚定位，别为了开源而开源这个工具在阿里内部已经跑了两年，20k月活、采纳率30%+、误报率不到5%。真正的转折点是26年之后越来越多人反馈"代码是AI写的，看不过来，不敢合"——这是个真实痛点，。 1）差异化很清楚：不是"用了大模型"就完事，是"确定性工程×Agent协同"的混合架构，规则该硬编码的地方硬编码，只在真正需要动态决策的地方用Agent。 2）主动在README里写清楚哪里做得还不够好。用户预期对了，用完不失望，留存反而更高；把话说满，用户一旦发现不符预期，"被骗了"的负面口碑传播比正面快得多。 本质上是可信度来自你敢暴露短板，不是来自你把优点吹到多满。 2. 先完成，再完美首个版本只做了几件事：CLI工具、模型配置命令、评审框架内核、Claude Code的skill集成、GitHub Action、可观测能力。就这样发了。 1）窗口期有限，打磨三个月，用户心智可能已经被别人占了。 2）不完美反而给社区留了参与空间——两个月后100多个正式版本、一百多位贡献者、60%以上的feature commit来自外部PR，这些能力很多是团队一开始根本预见不到的场景里长出来的。 3）一个教训：早期太关注框架内核完备性，配模型这个"最入口"的环节做得太复杂，来的流量转化率很低。后来想明白：易用性就是转化率，这件事不能拖到后面做。 3. 谨慎增加用户的认知复杂度 README从1000行砍到200行，只留"你是谁、为什么选你、怎么快速开始"，其他全扔文档站。 1）判断新功能是否增加复杂度的标准：新增的东西是否让同一批用户面对更多选择。同时支持GitLab CI和GitHub Actions不算复杂度增加，因为这两类用户互相看不见对方的东西；但同时提供两个功能相近的参数让同一个用户纠结该用哪个，才是真正的负担。 2）判断路径：用户进来→5分钟理解核心价值并跑起来→有兴趣再看细节。凡是让这条路径变长的改动，都要三思。 4. 快速响应，是社区活不活的关键小bug、小特性12小时内发版修复，PR提交后尽快review。两个月发了89个版本。 1）靠人力根本撑不住这个节奏，靠的是一整套AI Coding工作流：内部代码100%AI生成、100%AI评审；人只做审查AI输出和最终决策。团队专门配了一套Skill（读Issue、建PR、评审代码、发版、润色回复语气）。 2）一切皆代码是这套工作流能跑通的前提——CI/CD、评审规则、发版流程、文档全是代码化的，Agent才能读、能改、能跑。你的发版流程如果是"点三个按钮、填两个表单、等审批"，Agent根本插不进去。 3）一次事故换来的规矩：不能让AI自己选方案再执行，决策权必须在人手里。有次让AI自由决定怎么优化工具调用逻辑，单测过了就发了，结果在上HN头条前两天引入了bug，用户第一次用就踩坑。后来定死：核心链路改动必须跑完整评测集才能发版，AI写代码必须给明确方案约束。 5. Trending不是终点，是起点第一次上Trending，第二天就掉了——原因很简单，新人进来没事可做。第二次上Trending前，团队提前准备了一批Good First Issue，PR来了就处理，结果连续5天首页。 本质上是流量来了没有承接，就像开了…

Wake：以前套壳模型，现在流行套壳code agent，不同Code Agent 聊天记录，现在散在 ~/.claude、~/.codex等多个私有code agent目录里，Wake把这 13 个code agent 的会话全收进一个窗口，能搜、能跳、能一键接着聊。 它支持的 13 个 agent： Claude Code、Codex CLI、Copilot CLI、Cursor 的 CLI 转写、OpenCode（含 v2 beta）、Kiro、Gemini CLI、Pi、Oh My Pi、Grok Build、Kimi Code，以及 Antigravity CLI（只能读元数据——转写是加密的）。 痛点： agent 用久了会意识到一件事：真正积累下来的资产不是代码，是那几百段对话——你怎么描述问题、怎么纠偏、哪条路走通了。但这批资产通常散落在不同地方：Claude Code 在 ~/.claude，Codex 在 ~/.codex，Cursor、opencode、gemini、