编程与 AI

关于人工智能编码助手的一些有趣数据：更多的代码并不一定意味着更多的软件。

哈佛大学的菲奥娜·陈 (Fiona Chen) 和詹姆斯·斯特拉顿 (James Stratton) 的一项研究，分析了2021年至2026年3月期间，700多家软件公司中超过70万名员工的数据，以及3亿个工作事件。研究发现，在引入编码助手后，总代码行数平均增长了30%，提交次数增长了20%，拉取请求（pull request）数量增长了23%。

但关键问题是：效率是否提高了？在诸如Jira之类的工具中跟踪的错误、任务和功能的完成率，并没有出现统计学上显著的变化。

瓶颈出现在代码审查环节。从提交拉取请求到将其合并到主代码库的时间，增加了49%。需要修改的拉取请求比例几乎翻了一番，每个拉取请求的评论数量增加了35%，参与代码审查的员工比例也增加了14%。这意味着，在编写代码方面获得的效率提升，很大一部分都在代码审查和修复环节被抵消。

公司也在尝试利用人工智能来解决这个问题：截至2026年3月，有80%的被审查公司正在使用某种人工智能代码审查工具。然而，只有23.3%的审查意见来自这些工具，并且这些工具仅对10.8%的拉取请求做出了贡献；大部分工作仍然由人工完成。此外，在被审查的时期内，活跃员工数量也没有出现显著变化。

需要注意的是，这些数据截止到2026年3月，而这些工具在此之后可能已经得到了改进。但我的结论很明确：为了提高效率，不仅要加快代码编写的速度，还要加快代码审查、错误修复和集成等环节的速度。

相关新闻来自Ars Technica：https://arstechnica.com/ai/2026/10/ai-coding-agents-generate-more-cod…
研究的PDF版本：https://fion.ac/jellyfish.pdf

来源：DonanımHaber

作为一个天天和代码打交道的人，2025年对我来说变化特别大。AI编程工具不再只是帮我补全下一行代码，而是开始真正接手任务。回想一下，上半年大家还在聊 Cursor 和 Copilot 的补全体验，到了下半年，Spec 驱动开发突然就火了，仓库里堆满了写给 Agent 看的 Markdown 文件。

我最大的感受是，编程这件事正从“人主导”变成“Agent 主导”。以前 AI 只预测下一个字符，现在它能从需求分析一路做到代码生成和结果验证。有意思的是，几乎所有头部工具都同时在推 IDE、CLI 和 Cloud 三种形态，最后都往 Agent 的方向收敛。

但问题也跟着来了。最扎心的是 Token 成本：任务变长、工具调用变多，上下文反复回灌，账单涨得飞快。今年大家嘴上常挂着的已经不是“怎么写 Prompt”，而是“上下文工程”——怎么在效果、效率和成本之间做取舍，怎么提高缓存命中率。

对我来说，2025年真正的分水岭不在于谁的模型更强，而在于谁能把工程里那些原本隐性的约束和记忆，变成模型能理解、能复用的上下文结构。程序员的价值，正在从“写代码”慢慢转向“定义规则”。这一年，确实有点魔幻。

来源：InfoQ

IT之家报道，JetBrains 在 10 月 8 日发布博文，宣布推出编程 AI 模型 Mellum2.1，重点增强智能体编程能力。作为开发者，我对这类可以本地部署的开源模型一直比较关注，所以把要点整理在这里。

模型延续 Mellum2 的架构，是一个 12B 的混合专家（MoE）模型，活跃参数为 2.5B，依旧采用 Apache 2.0 许可证。训练上的变化是，把预训练之后的强化学习阶段从短期收尾环节扩展成了训练主体，补充了数学、算法竞赛、科学、工具使用和软件工程等任务的数据，并搭建内部强化学习环境，训练期间启动数百万个沙盒，覆盖数千个环境。训练前还会筛掉带测试缺陷、答案不可验证或难度不合适的任务。

能力方面，官方称它可以探索代码库、编辑文件并检查自己的修改，最大的改进在智能体编程：能识别失败测试的根因，起草修复方案并验证结果。速度方面，架构不变，多 Token 预测（MTP）让单请求场景下速度提高约 1.6 倍；与 Mellum2、Qwen3.5-9B 和 Gemma 4 E4B 在相同评估设置下比较，高负载时 Mellum2.1 在单块 H200 上的输出吞吐量接近 Qwen3.5-9B 的两倍。

模型已上线 Hugging Face，支持在本地或自有基础设施上部署，企业可以把代码和数据留在自己的环境里。后续计划推出面向 llama.cpp、Ollama 和 LM Studio 的 GGUF 版本，以及 vLLM 的 MTP 推测解码组件。

我比较期待 GGUF 版本，那样普通开发者在自己的机器上也能试一试。你们更看重编程模型的准确度，还是部署成本？

来源：IT之家

我在 ITmedia NEWS 的报道中得知，谷歌发布了一个实验性游戏平台“Playground”。该消息于美国时间 2026 年 10 月 7 日公布，同日起面向美国 18 岁及以上用户通过网页浏览器提供。

使用方式只需用文字下达指令。可以从空白开始，也可以编辑现成的启动提示词，或者使用引导式帮助，做出的游戏可以当场测试。物理行为、规则、角色和环境的修改，只要用语言描述也能生效。据称无需编程经验，但文章并未说明使用的是哪种 AI 模型。

游戏还可以分享。由于基于网页，手机和电脑都能玩；可以把分享链接发给朋友和家人，也可以发布到画廊“Explore”，或者设为私密。部分类型支持排行榜和多人游戏，公开发布的游戏会依据谷歌社区准则接受安全审核。游戏创作功能将根据 Google One 会员等级分阶段开放。

另一项公告是与 Unity 的合作。两家公司计划在 2026 年内推出新产品“Unity Spark”，为 Playground 加入完整的游戏机制、高精细 3D 表现以及 Unity 运行时的灵活性。它还将直接连接 Unity Asset Store，目前正在测试，不久后将开启封闭测试版。Unity 的 CEO 指出，每月约有 30 亿人在玩 Unity 制作的游戏，但其中很多人从未亲自做过游戏。

我个人觉得，分享并游玩由提示词做出的游戏这种模式，也许会成为编程入门的一个有趣起点。你们怎么看这类工具？

来源：ITmedia NEWS

Next 撰文介绍了 Pi，这是一个刚刚发布 1.0.0 版本的开源 harness。对于不熟悉这个术语的读者，harness 是包裹在 AI 模型外层的软件层，让模型能够读取文件、执行命令或在互联网上搜索。

Pi 的定位是极简但可扩展。它兼容 1500 多个模型及其变体，既包括商用模型，也包括可以在本地运行的开放权重模型，并以 Claude Code 和 Codex 的替代品自居，不依赖 Anthropic 或 OpenAI 的模型。开发者们把这次发布 1.0 视为成熟的标志。

文章还提到了近期的新进展：MCP 连接器、一种名为“codemode”的模式，以及对 ChatGPT 的支持。Pi Durable 被描述为能够扛住内部和外部的灾难性故障。

需要说明的是，文章约 80% 的内容只对订阅者开放，所以我只介绍公开可读的部分。评论区里，好几位读者把 Pi 与 OpenCode 做了比较：有人认为它非常轻量，但配置更困难，尤其是 MCP；另一位读者提到了 Oh-My-Pi 这个变体。作者还预告了一篇关于安装和使用的文章。

我感兴趣的是把 harness 与模型分开的思路：换模型不必换工具。不过，当使用场景变得复杂时，Pi 的简洁性能否站得住脚，还有待观察。你们平时用 AI 写代码时，会用哪一种 harness？

来源：Next

Xataka 讲述了一个融合了编程、AI 和不少争议的故事。直到几天前，ArtCraft 还是一个用 AI 生成图像和视频的平台。团队成员 Brandon Thomas 宣布，他用氛围编程创建了七款 Adobe 应用的开源替代品，使用 Rust 编写：PhotoCraft（Photoshop）、VectorCraft（Illustrator）、FilmCraft（Premiere Pro）、LightCraft（Lightroom）、PdfCraft（Acrobat）、EffectCraft（After Effects）和 DesignCraft（InDesign）。

这些软件支持 Windows、macOS 和 Linux，也可以从 ArtCraft 中使用。文章指出，Adobe 从未为 Linux 提供过专业创意工具，因此这一空白并不小。

作者的一位同事试用了 PhotoCraft 几天：基本功能可以使用，看不到 Photoshop 那样的 AI 工具，而且应用非常轻量。尽管如此，目前它还无法取代原版。制作者自己也承认仍处于早期 alpha 阶段：缺少约二十种 AI 和生成式工具，排版和专业工作流的深度不够，也不兼容插件。

据制作者称，他们采用的是洁净室（clean-room）方式：依据公开的规范和程序可观察的行为开发，没有使用任何专有代码或资源。PhotoCraft 能打开 PSD 文件，是因为 Adobe 公开了这些规范。网上有人怀疑 Adobe 的程序被反编译过，但没有证据。

Xataka 也提醒了氛围编程的问题：AI 生成的代码可能难以调试，其中可能包含人类程序员绝不会写的内容。对于个人应用来说，这比大型项目的风险小一些。我觉得这是一个很好的提醒。文章提到的免费替代品有 Affinity、GIMP 和 DaVinci Resolve。你会信任这样生成的应用吗？

来源：Xataka

我读了 Computer Sweden 上 Simon Bisson 的分析：微软已将 Rust 提升为内部 Tier-1 地位，与 C#、TypeScript 和 C 处于同一级别。该地位尤其要求完整的工具链，以及与 Windows 和 Azure 的集成。

背景是，Azure 首席技术官 Mark Russinovich 一直强调 Rust 的内存安全是微软安全战略的重要组成部分，而微软也是 Rust Foundation 的创始成员之一。Rust Foundation 网站上的一篇客座文章介绍了如何将 Rust 与 Microsoft Visual C（MSVC）相连，以实现语言之间的无缝互操作。

其中最具体的是 Rust 编译器的新后端 rustc_codegen_utc。它使用 Visual C 的后端，即名为 C2.DLL 的动态库，并将 .OBJ 文件交给 MSVC 链接器。其优势在于 Rust 可以借助微软已有的安全与稳定性工作，Rust 与 C 代码也能兼容。微软称该后端已可用于生产环境，并表示有一百多个内部 Rust 项目在使用。不过它目前仅限内部使用，公司暗示工具可能开源，但未给出时间表。

对于微软以外的人来说，情况更务实：VS Code 中的 Rust 支持通过 rust-analyzer 实现，构建仍需要 MSVC C Build Tools，而微软的 windows crate 可直接访问 Windows API。文章建议，学习用 Rust 做 Windows 开发时，先从现有工具入手。

我个人觉得，看到这么大的公司投入资源，以避免维护两支独立的编译器团队，这一点很有意思。你们用 Rust 做什么？

来源：Computer Sweden

我在Computable上读到了Linux Foundation《2026年欧洲开源现状》报告的摘要。这是第五版，在布拉格的Open Source Summit Europe上发布。核心信息很明确：仅仅使用开源并不能带来控制力，还必须参与贡献，并共同参与治理。

数字显示问题所在。对94%的欧洲组织来说，数字主权对其技术战略很重要，对61%而言非常重要。欧洲开发者贡献了Kubernetes、OpenStack等基础设施项目近40%的代码，但许多组织只停留在使用层面。31%的组织没有正式的开源管理框架。有框架的组织报告其投资回报为4倍以上，没有框架的为3.6倍。

AI编码工具也有涉及。94%的组织在使用或试用生成式AI编码工具，四分之三认为这些工具提升了开源的价值，48%因此使用了更多开源。近一半的组织维护内部分支，每个发布周期平均9.5个分支耗费311小时。

我特别注意到，Agentic AI Foundation的高层主要是美国公司，如AWS、Anthropic、Google、Microsoft和OpenAI。在Gold级别，欧洲只有Suse和Ericsson。与此同时，欧盟委员会正在筹备一项约20亿欧元的科技主权计划。

Linux Foundation Europe的Thierry Carrez认为，开源有助于减少依赖，但前提是积极参与开放的治理结构。作为开发者，我深有同感：一个合并请求有时比一份政策文件更有影响力。你们那边的情况如何？

来源：Computable

The Register 的 Richard Speed 报道了 ArtCraft 公司的情况。该公司在其 Rust 应用合集中新增了 Word、Excel 和 PowerPoint 的替代品。公司称这些是对专有软件的清洁室式重新实现，而且项目在开发中大量依赖 Claude。其 GitHub 仓库里还有模仿 Photoshop、Illustrator 和 Premiere Pro 的项目。

评测者在一台 Arm 架构的 Surface 上运行了 Word 替代品 WordCraft，发现它运行良好。它与 Word 相似，但按钮、图标和图像有所不同。该项目仍处于 pre-alpha 阶段，ArtCraft 估计其功能与 Word 的相似度约为 62%，评测者建议不要用于生产环境。路线图也承认，尚未开始针对真实世界 DOCX 文件的兼容性测试，图表、SmartArt 和嵌入的 OLE 对象都被舍弃了。

在授权方面，WordCraft 采用 MIT 或 Apache 2.0 双重许可。拼写词典和连字符处理使用了 Grady Ward 的公共领域词表 Moby Hyphenator II。ArtCraft 表示，一切都基于公开规范和观察，并且只使用原创或开放许可的素材。LibreOffice 的开发者 The Document Foundation 拒绝置评，微软确认收到咨询但没有进一步回应，Adobe 则拒绝就创意应用项目置评。

decoded.legal 的 Neil Brown 告诉该报，法律地位取决于司法管辖区；开发者可能主张其独立实现不构成侵权，但考虑到利害关系，此事有可能诉诸法庭。

我觉得有意思的不是这一主张本身，而是速度：一个小团队借助 AI 编程工具，就能公开一套辨识度很高的办公套件，虽然尚未完成，但已足以供人测试。接下来的问题是质量、维护以及法律层面。我很想听听，其他用 AI 助手写代码的人如何看待“清洁室”这种说法。

来源：The Register

我在科技门户网站上看到，OpenAI 在推出 GPT-6 模型的同时，宣布了 ChatGPT 的一项新功能，名为「智能界面」（Intelligent UI）。关键在于，回答不再只有文字，而是可以在对话中把文字与交互式视觉元素结合起来。

支持的元素包括插图、图表、统计图、表单和交互按钮。文章引用了 OpenAI 博客的内容，称 GPT-6 经过训练，能够判断哪些情况下交互元素比文字更合适，并学会了如何在回答中安排它们。

文章举了几个例子：一幅七速自行车插图，配有可选择各部件并显示说明的按钮；以可滚动分组形式展示的麻将牌图片；以及退休储蓄计算器、多人分摊账单的小工具等。在模型方面，高级订阅用户可使用 GPT-6 Sol，Go 订阅用户和免费用户则使用效率更高的 Luna。文章还提到网络搜索有所改进，收集信息时的部分回答出现得更快，并且对绕过安全训练的尝试有更强的抵抗力。

我认为这一步对开发者很重要，因为它让对话更接近按需生成的小型应用。我想问的是：按钮是否真的比写得好的文字更有帮助？很想听听大家的看法。

来源：科技门户

Bootstrap 终于在五年后重新动了起来：联合创始人 Mark Otto 宣布了 Bootstrap 6 的首个 alpha 版，heise developer 对此进行了报道。这个框架源自 Twitter 的圈子，自 2011 年起就是开源项目，所以我觉得这条消息很有意思。

数字能说明 Bootstrap 有多大：据项目方称，安装量超过 17.5 亿次。但与此同时，它的市场份额在下降。据 W3Techs 统计，2026 年 8 月初有 13.8% 的网站使用 Bootstrap，而 2025 年 12 月这一比例还是 15.3%。在新项目中，Tailwind CSS 正在不断扩大影响力。

团队瞄准的是现代浏览器：Chrome 和 Edge 130 及以上，Firefox 132 及以上，Safari 18 及以上。为此，Bootstrap 6 使用了自动明暗切换、原生对话框，以及相对于周围元素而非窗口进行对齐的布局等功能。颜色、间距和圆角大多可以通过 CSS 变量控制，甚至可以在运行时修改。类名向 Tailwind 靠拢：.d-md-none 变成 .md:d-none，.col-lg-6 变成 .lg:col-6。手风琴组件无需 JavaScript 即可工作。

我觉得尤其值得一提的是 AI 相关的部分：文档以 llms.txt 和 llms-full.txt 的形式提供，仓库中还有技能文件，旨在帮助 AI 智能体完成例如迁移等工作。

文章指出，现有页面不能直接切换过去。Bootstrap 5 暂时仍会获得支持，在支持结束之前还会发布 5.4.0 更新。版本 7 据称会更快到来。你们中还有人在用 Bootstrap 吗？又有谁已经换成了别的东西？

来源：heise online

这周XYZ的一则新闻引起了我的注意：弗罗茨瓦夫理工大学与下西里西亚肿瘤、肺病与血液学中心正在构建一个医疗AI平台。它不是又一个聊天机器人，而是一个基础模型，把病历、化验结果、影像和治疗路径整合在一起。

他们从肺癌入手——DCOPiH每年接诊超过1400名新患者，数据记录完善。该系统将在多学科会诊前检查病历是否完整，指出缺漏，防止患者在各项检查之间“掉队”。决定仍由医生做出；AI的作用是把时间还给医生，让他们多陪伴病人，而不是代替医生思考。

技术上让我感兴趣的是联邦学习：数据留在医院内，只有训练成果会汇入共享模型。其基础将是波兰语模型PLLuM的经验，但会加入真正的医学语言和多模态能力。

首个原型将在未来几个月内推出。如果它能走出下西里西亚，或许会成为波兰最值得一谈、无需营销炒作的重要AI项目之一。

来源：XYZ