https://devgo.cn/ AI 大模型、Agent、机器学习、AI 工具的中文精炼导读：一句话看懂 + 活人味深度解读。 zh-CN Tue, 06 Oct 2026 01:24:03 GMT devgo-build https://devgo.cn/docs/ai/article/fbb393b1fa.html 如果你让 AI 帮你把代码从一个语言搬到另一个语言，你会选最强的模型、开最高的推理预算，对吧？Akka 用 65 个开源项目做了一次大规模实验，结论却反直觉：在“规格驱动”的工作流下，更小、更便宜的模型（Sonnet）平均每个移植任务耗时 61 分钟，而更大的 Opus 要 120 分钟，虽然 Opus 省了约 40% 的 token，但小模型产出的代码在通过率和性能上反而更稳定。这背后不是模型能力问题，而是“约束”问题——当任务被拆成清晰的规格说明时，小模型更愿意老老实实照着做，大模型反而容易“自由发挥”。 实验分两批进行。第一批覆盖全部 65 个项目，Akka 为每个项目生成规格说明，并 Tue, 06 Oct 2026 01:23:59 GMT https://devgo.cn/docs/ai/article/fbb393b1fa.html https://devgo.cn/docs/ai/article/eba12d19c2.html 如果你维护过一个有点名气的开源项目，大概能体会那种感觉：Issue 列表里堆满了模板化、没头没尾的报告，标题写着“发现严重漏洞”，点开一看要么是误报，要么是根本没复现步骤。现在，这种痛苦正在以更猛烈的方式冲击 Google 的开源漏洞奖励计划（OSS VRP），而罪魁祸首，正是我们天天在用的 AI 大模型。 Google 在 10 月 1 日宣布，冻结其开源软件漏洞奖励计划（OSS VRP，即针对 Google 旗下开源项目的安全漏洞悬赏项目，白帽子提交有效漏洞可获现金奖励）。这不是暂停几天调整一下，而是直接冻结到 2027 年第一季度，期间 Google 会重新设计整个项目。官方给出的理由 Tue, 06 Oct 2026 01:23:25 GMT https://devgo.cn/docs/ai/article/eba12d19c2.html https://devgo.cn/docs/ai/article/3448ea0df9.html 你肯定遇到过这种事：一张横构图厨房照片要裁成正方形头像，结果人站在最左边，默认的中心裁剪把脸砍掉一半。或者一张按三分法构图的菜品图，主体偏右，裁完只剩一块桌布。几何中心裁剪很稳定，但它不懂含义——它只知道删掉左右等量的像素，不关心被删掉的是不是主体。内容感知裁剪则引入一个主体信号（人脸框、食物区域掩码或焦点）来移动裁剪窗口，能更好地保留不在中心的主题，但代价是多了个失败模式：如果检测器把高光调料、亮色餐巾或背景海报里的人脸当成焦点，结果会“自信地错”。 文章讨论的是在 Node.js 服务里做头像和菜品图的裁剪时，到底该选哪种策略。作者给出了一个很实际的默认值：内容感知裁剪更好，当食谱照片要 Tue, 06 Oct 2026 01:22:52 GMT https://devgo.cn/docs/ai/article/3448ea0df9.html https://devgo.cn/docs/ai/article/d458f2d532.html 用过 Claude Code 或类似 AI 编程助手的开发者，大概率都遇到过同一个痛点：让 Agent 去查一个函数定义、找一处配置来源，它会把整个文件甚至好几个文件读进上下文，然后这些内容会一直留在会话里，占用宝贵的 context window，还让后续每一轮对话都变得更慢、更贵。你只是想知道 flyTo 的动画时长是怎么算的，它却把 camera.ts 整个读了一遍，这些中间产物在回答完问题后毫无用处，却要跟着你走完整个 session。 Ototo 这个开源项目换了个思路：既然大部分代码探索本质上是“查资料”，而不是“思考”，那为什么非要让主 Agent 亲自去翻文件？它把探索这件事 Mon, 05 Oct 2026 23:43:09 GMT https://devgo.cn/docs/ai/article/d458f2d532.html https://devgo.cn/docs/ai/article/2e2df4d9a3.html 很多人在逆向 DataDome 时都经历过这样的时刻：JavaScript 跑完了，请求返回 200，甚至拿到了新 Cookie，然后带着这个 Cookie 去请求正文，还是 401。 如果只把逆向理解成“把一段混淆代码还原出来”，这件事就很难解释。代码不是已经能跑了吗？字段不是已经生成了吗？究竟还有哪里不对？ 这篇文章借分析 Reuters 页面中 DataDome 客户端的经历，讲清楚这些问题。不是先摆一整章术语，再让你自己寻找它们的用途，而是沿着调查往前走：遇到什么现象，为什么看这个位置，用到什么知识，最后能下什么结论。 你只需要会读基本的 JavaScript，知道对象、数组、函 Mon, 05 Oct 2026 13:08:34 GMT https://devgo.cn/docs/ai/article/2e2df4d9a3.html https://devgo.cn/docs/ai/article/0d54d45dbe.html 每年十月，Python 新版本发布后，总有一批开发者急着想知道“这次到底快了多少”。今年轮到 3.15，一位作者用自己非正式的基准测试，把 3.10 到 3.15 的 CPython、PyPy，以及 Node.js 和 Rust 都拉出来跑了一遍。如果你还在纠结要不要升级，这篇实测能给你一个比较靠谱的参考。 先说结论：Python 3.15 在单线程整数计算上只比 3.14 快了约 3% 到 4%，基本可以忽略；但它的 JIT（即时编译，解释器在运行时把热点代码编译成机器码以加速执行）版本终于发力，在递归 Fibonacci 测试上比标准解释器快了 20%，在冒泡排序测试上快了 28%。这是 Mon, 05 Oct 2026 13:06:27 GMT https://devgo.cn/docs/ai/article/0d54d45dbe.html https://devgo.cn/docs/ai/article/7788fca159.html 如果你的团队正在把大模型从原型推向生产，大概率会遇到这样一个场景：demo跑得欢，上线第一周指标也漂亮，然后某天运营突然说“这个推荐怎么这么离谱”——系统给出一个自信满满、煞有介事的建议，但实际上这个SKU根本不存在。这就是幻觉，它不像报错那样会弹堆栈，它通过所有传统健康检查，下游服务照常消费，等有人发现时已经产生了实际损失。这篇来自零售业库存准确性平台的技术复盘，讲的就是如何把幻觉率从15%压到1.5%，而撬动数字的杠杆不是换更强的基座模型，而是把LLM栈从“应用层的事”升级成“平台基础设施”。 项目背景是一家大型零售组织，库存记录在物理货架与系统之间会因为错放、损坏、盗窃、误点而产生偏差 Mon, 05 Oct 2026 13:06:06 GMT https://devgo.cn/docs/ai/article/7788fca159.html https://devgo.cn/docs/ai/article/1623cb04e6.html 你的团队里是不是也有这种混乱：A 组做安全告警分析，B 组做企业知识问答，每组都在构建自己的 Agent，也各自造了一套评估数据集、各存各的 trace、各跑各的评测脚本。改动一个模型或 Prompt，没人知道会不会把另一个团队的功能搞坏。Elastic 的主数据科学家 Susan Chang 在 QCon 上分享了他们从这种状态走向统一评估框架的全过程，里面有大量接地气的实操细节，值得每一个正在把 Agent 推向生产的人参考。 先看他们跑在线上的是什么。Elastic 的核心产品是 Elasticsearch，全世界很多公司在用它的关键词搜索和向量检索，像 Stack Overflow、 Mon, 05 Oct 2026 13:05:50 GMT https://devgo.cn/docs/ai/article/1623cb04e6.html https://devgo.cn/docs/ai/article/c84738e092.html 如果你在 Amazon S3 Vectors 上跑 RAG（检索增强生成，就是先从一个向量库里捞出相关文档片段，再喂给大模型生成答案），并且带元数据过滤条件，那你可能一直在悄悄丢结果。比如某个租户有 100 条记录，你请求返回最相近的 10 个 chunk，结果可能只回来 3 个，或者回来 10 个但根本不是这个租户数据里真正最相近的。没有报错，没有告警，模型只是拿比预期更少的上下文去回答问题。2026 年 9 月 30 日，AWS 发布了 S3 Vectors 的元数据预过滤（metadata pre-filtering）功能。索引现在有两种模式，新模式在相似度搜索之前先求过滤条件，而不是在 Mon, 05 Oct 2026 13:05:26 GMT https://devgo.cn/docs/ai/article/c84738e092.html https://devgo.cn/docs/ai/article/d5e0bb95c4.html 过去大半年高强度用 AI agent 写代码的人，大概都撞上过同一个隐形的墙：模型能力越来越强、prompt 写得越来越顺、上下文窗口越拉越长，但真正拖后腿的，反而是那个被默认了二十年的工具——Git。不是 Git 不好，而是它的设计前提是'人类手工编程'：一个人坐在编辑器前，想清楚要改什么，改完检查一遍，然后 add、commit、push。staging area 给你'最后再看一眼'的缓冲，branch 帮你隔离工作流，stash 让你临时放下手头的活。这套机制本质上是在给人类留喘气的时间，但 Agent 不需要喘气，它的干活方式是'先哗哗生成一大堆，回头再整理历史'，而 Git 的模型 Sun, 04 Oct 2026 20:52:27 GMT https://devgo.cn/docs/ai/article/d5e0bb95c4.html https://devgo.cn/docs/ai/article/4b939a2bf5.html 如果你最近半年用 agent 写代码，大概率经历过这个循环：写 prompt → agent 出活 → 自己跑 app → 验证/截图/找 agent 抱怨 → agent 改 → 再跑 → 再截图。写代码这部分工作，agent 已经承担了大半，但验证正确性对 UI app 来说尤为困难。agent 能在几分钟内吐出一大段像模像样的 Swift 或 Kotlin，但写完最多跑跑单元测试，然后就停在那儿了——它等你来运行、来看、来告诉它哪不对，它再根据反馈修改。这是相当低效的开发方式。 为什么移动端验证这么难？做 Web 的同学会感觉，agent 在前端的闭环验证做得还不错，原因很朴素：age Sun, 04 Oct 2026 20:52:13 GMT https://devgo.cn/docs/ai/article/4b939a2bf5.html https://devgo.cn/docs/ai/article/8da89b9e68.html 你刚做好的一个营销活动页，用户在地铁里点开，转圈三秒后跳出“连接失败”。你气得想骂运营商，但邻居团队用同一个后端，却能让用户离线也能看到页面骨架，甚至还能收到一条推送提醒“你收藏的商品降价了”——差别不在运气，在他们用了 PWA（渐进式 Web 应用）。 PWA 不是一门新语言，而是基于 HTML、CSS、JavaScript 的网页应用增强方案。它的核心哲学是“渐进增强”：任何用户、任何浏览器、任何网络下都能先拿到基本功能，条件允许时再解锁安装、离线、推送这些原生级能力。听起来很美好，但真正让它从“能看”变成“能用”的，是三个硬性前提。 首先是 HTTPS，没有它，浏览器根本不允许你注册 Sun, 04 Oct 2026 13:07:30 GMT https://devgo.cn/docs/ai/article/8da89b9e68.html https://devgo.cn/docs/ai/article/35a924d8b2.html 想象一个街角的面包店老板娘，她的全部生意都靠 WhatsApp 聊天维系。Priya 发来"1 kg 巧克力松露蛋糕，周日晚上，无蛋"，Rahul 说"2 盒布朗尼，明天早上，地址 14B Lakeview Apts"，紧接着又补一句"抱歉，改成 3 盒"。Meena 只发了句"晚安阿姨"。Sneha 要 12 个香草纸杯蛋糕加 6 个红丝绒，周六下午 4 点自取，还留了电话。六条消息，中英混杂，有修改、有相对日期、有自取、有纯闲聊。赶上节日旺季，订单翻倍，漏单、数量搞错、顾客不停追问"阿姨，我的蛋糕好了吗？"——这就是 Order Taker 要解决的问题：一个为"擅长烘焙但不擅长表格"的人 Sun, 04 Oct 2026 13:07:12 GMT https://devgo.cn/docs/ai/article/35a924d8b2.html https://devgo.cn/docs/ai/article/313cd26c31.html 如果你玩过正则高尔夫（用最短的正则表达式完成匹配任务），大概体会过那种“差一个字符就完美”的纠结。作者把这个玩法做成了每日游戏 Regex Hunter，每天一道题，所有人用同一个模式去匹配目标词、避开干扰词，然后比谁写得更短。但真正让他头疼的不是出题，而是“怎么给正则公平地计分”。 先说最基础的：长度就是分数，但“长度”怎么定义？在 JavaScript 里，`'😀'.length` 是 2，因为 JS 按 UTF-16 码元计数，一个 emoji 占两个码元。如果直接拿这个当长度，那用 emoji 写正则的人就白吃亏了。所以客户端用 `[...pattern].length` 按码点（U Sun, 04 Oct 2026 13:06:21 GMT https://devgo.cn/docs/ai/article/313cd26c31.html https://devgo.cn/docs/ai/article/8ce6dd0f62.html 2026 年 9 月 24 日，加密货币交易所 Bitget 遭遇了一场堪称教科书级的攻击：损失约 3.875 亿美元。但最反常识的地方在于——攻击者从头到尾没有碰过私钥，冷钱包也完好无损，钱是怎么没的？答案是：他们打穿了交易签名信任链。 先看时间线。18:31 UTC，攻击者先用 ETH 和 TRX 发起几笔小额的测试转账，刻意保持在交易所自动风控阈值之下，试探是否有警报。确认安全后，18:58 到 20:09 之间，攻击者在 9 条链（Ethereum、XRP、Zcash、TRON、BNB Chain、Base、Arbitrum、Optimism、Avalanche）上执行了 17 笔大 Sun, 04 Oct 2026 13:05:12 GMT https://devgo.cn/docs/ai/article/8ce6dd0f62.html https://devgo.cn/docs/ai/article/231d5fe5f6.html 你有没有过这种体验：给 AI Agent 派了个活，然后每隔几分钟就忍不住刷新一下看它跑完没有，生怕它卡住或者跑偏。如果任务只要几秒钟，盯着也就盯了；可一旦 Agent 要跑后台任务——比如定时抓取数据、批量处理文件、调用一堆工具链——这种“盯梢”就变成了一种折磨。AWS 的两位工程师 Joseph Dolivo 和 Igor Fil 显然也受够了，他们最近开源了一个叫 Pizza Bot 的项目，核心思路特别朴素：给 AI Agent 配一个像邮箱一样的收件箱。你只管把任务发出去，Agent 在后台慢慢干，干完了给你发“邮件”通知你。 这个设计的妙处在于它把人和 Agent 的交互方式从“ Sun, 04 Oct 2026 13:04:53 GMT https://devgo.cn/docs/ai/article/231d5fe5f6.html https://devgo.cn/docs/ai/article/81b68c5ee2.html 想象一下这个场景：你睡前部署了一个用 AI 编码助手生成的爬虫脚本，它调用某个付费 API 抓取数据。凌晨三点，脚本因为一个边界条件陷入死循环，疯狂发起请求。你早上醒来，看到的不是抓取结果，而是云服务商发来的账单通知——一夜之间，几百甚至几千美元就这么没了。这不是危言耸听，而是越来越多开发者正在经历的噩梦。 问题的根源在于，当前几乎所有按量付费（pay-by-usage）的云服务和 API 都默认没有硬性预算上限。所谓硬性预算上限，就是你可以设定一个规则："每月消费超过 X 美元，就立刻切断服务并返回错误"。与之相对的是软性上限（soft cap），也就是"超过 X 美元后给我发封警告邮件" Sun, 04 Oct 2026 13:04:19 GMT https://devgo.cn/docs/ai/article/81b68c5ee2.html https://devgo.cn/docs/ai/article/565c2e6275.html 右键菜单是 Windows 上每个开发者每天都要点几十下的东西，但它的构成远比想象中复杂。Windows 11 还把它一半的项藏在“显示更多选项”里，搞得人找东西要多点一下。市面上各种右键菜单管理工具我几乎都试过，每个都只覆盖一部分：有的能管传统项，有的能管扩展，但从来没有人把三类来源整合到一个界面里。所以我用 PowerShell 写了一个单文件右键菜单编辑器，带 WPF 窗口，MIT 协议，免费。你可以不安装直接试： ``` irm https://rocisapps.com/cme | iex ``` 先用着不放心可以先读源码，GitHub 每个 release 都附了同一个脚本。 # Sat, 03 Oct 2026 20:37:50 GMT https://devgo.cn/docs/ai/article/565c2e6275.html https://devgo.cn/docs/ai/article/232774c201.html 你有多久没真正做过一次恢复演练了？大多数团队的备份策略停留在“每天定时把数据库文件拷走”这一步，至于这些备份能不能用、恢复要花多久、丢了多少数据，没人说得清。这篇文章的作者用 SQLite 搭了一个极简的恢复实验室，把“备份→制造故障→恢复→校验”的完整闭环跑通，并且用 GitHub Actions 把恢复测试嵌进了 CI/CD 流程——每次代码推送都会先验证备份可恢复，才允许部署。这个思路对任何有状态服务的团队都有直接参考价值。 ## 先定义清楚：什么才算“恢复成功” 作者开篇就点破一个反常识的事实：**一文件夹的备份文件并不能证明你的应用能恢复**。要验证恢复能力，必须主动制造一次受控 Sat, 03 Oct 2026 20:37:31 GMT https://devgo.cn/docs/ai/article/232774c201.html https://devgo.cn/docs/ai/article/8e57e9a577.html 你管理着一台自托管的 GitLab 服务器，一天早上你看到安全邮件：一个 CVSS 10.0 的漏洞正在被利用，攻击者不需要任何账号就能读取服务器上的任意文件——包括 CI/CD 变量、部署令牌、SSH 密钥。更糟的是，你的服务器只要有一个公开项目就满足了攻击条件。这不是演习。 这个漏洞编号是 CVE-2026-85706，本质上是一个路径遍历问题：GitLab 的仓库提交 API（也就是 `/api/v4/projects/{id}/repository/commits/` 这个接口，用来获取提交记录）在解析 `file.path` 参数时，没有把路径限制在项目目录内，同时也没有严格校验调 Sat, 03 Oct 2026 20:36:36 GMT https://devgo.cn/docs/ai/article/8e57e9a577.html