给软件开发者准备的优质简报，每日阅读 10分钟。
Frontier AI has broken the open CTF format
CTF竞赛已死：AI如何终结了这场曾经充满意义的网络安全竞赛
- AI能力跃升彻底改变了CTF竞赛本质：GPT-4能单次解决中等密码学挑战，Claude Opus 4.5配合Claude Code和MCP工具实现了中难度及部分高难度挑战的自动化解题，GPT-5.5 Pro已能单次解决Insane级别的无泄漏堆溢出挑战，使公开在线CTF演变为"token投入越多、排名越靠前"的付费游戏
- 开源编排工具大幅降低了AI竞赛门槛：任何人只需调用CTFd API就能并发启动AI实例处理所有简单题目，团队只需接手剩余难题，使得排名衡量的是"谁更愿意使用前沿模型和投入资金"而非安全技能；这导致TheHackersCrew等传奇团队要么退出、要么勉强参赛，2026年的CTFTime排行榜已面目全非
- CTF曾是初学者的清晰成长阶梯，但AI破坏了这个反馈循环：初学者在建立AI所替代的直觉前就被推向使用AI，既破坏了"主动挣扎才能真正学习"的机制，也因可见的进步被自动化梯队碾压而丧失动力；作者建议初学者转向picoGym、HackTheBox等以学习为核心的平台
- 组织者的所有抵抗手段均告失败：拒绝字符串、提示注入检测、搜索能力截断等手段只是暂时摩擦，刻意对抗AI的题目往往也变得令人生厌；作者还反驳了"AI与国际象棋引擎"的类比——象棋引擎在正式比赛中明确禁止使用，而AI在CTF中却被允许自由使用，这个类比从根本上就不成立
- 虽然竞赛形式已死，但CTF社区的价值仍在：作者以个人经历说明CTF曾让他遇见行业中最值得尊敬的人，完成过精心设计的挑战；呼吁通过SecTalks、学生会议、本地聚会及Discord等平台保持社区连接，将重点从被AI侵蚀的scoreboard转向真正的学习与交流，共同寻找新的方式延续网络安全领域的竞争精神
Moving away from Tailwind, and learning to structure my CSS
从 Tailwind 迁移到原生 CSS 的结构化心得
- 作者 Julia Evans 将部分站点从 Tailwind 迁移到语义化 HTML + 原生 CSS；主要动机包括：Tailwind 越来越依赖构建系统导致 2.8MB 的 CSS 文件、她已不再需要 Tailwind 的约束来实现特殊需求、项目中混用原生 CSS 和 Tailwind 导致维护困难，以及对语义化 HTML 的好奇心
- 她将 CSS 代码库按 9 个方面组织：reset（复制 Tailwind 重置样式）、components（每个组件独立 CSS 文件）、colours（颜色变量）、font sizes（字号变量）、utilities（跨组件共享类）、base（全局基础样式）、spacing（间距规范）、responsive design（响应式设计）和 build system（esbuild 生产构建）
- 组件采用唯一类名和独立文件管理，使用嵌套选择器组织变体样式，遵循"一个组件的 CSS 永不覆盖另一个组件"的原则；颜色和字号均通过 CSS 变量定义，便于统一管理和复用
- 响应式设计开始更多使用 CSS Grid 的 auto-fit 和 grid-template-areas 特性，减少对媒体查询的依赖；间距管理则采用"猫头鹰选择器"（
* + *）和"无外边距"等 CSS 技术，由外层布局组件统一控制 - 她深受 "Tailwind and the Femininity of CSS" 一文影响，认为 CSS 是一门值得认真对待的技术，LLM 时代尤其需要尊重人类的专业知识；wizardzines.com 的设计由 Melody Starling 完成，她还计划学习 @layer、@scope、容器查询和 subgrid 等现代 CSS 特性
Every AI Subscription Is a Ticking Time Bomb for Enterprise
AI订阅时代即将终结：企业隐性成本危机迫在眉睫
- 史无前例的亏损领跑策略：OpenAI、Anthropic、Google等主要AI厂商正以远低于成本的价格销售订阅服务，将这种“用热狗价格卖牛排”的战略作为行业惯例——这种补贴模式已使企业深度嵌入其生态，而依赖一旦形成，价格修正将不可避免
- 订阅价格与实际成本鸿沟触目惊心：Claude Pro月费20美元，但高强度使用者的API等效成本达200至400美元/月；Anthropic每收取1美元订阅费，实际计算成本支出高达8美元；微软据报在GitHub Copilot上每用户每月亏损超20美元，部分重度用户计算成本高达80美元/月
- 代理式AI彻底颠覆成本模型：代理式工作流使token消耗量较传统对话式呈数量级增长——开发者运行多个并发编码代理时，消耗的不是3至4倍，而是一个数量级以上的token；GitHub已承认"代理式使用正在成为默认模式"，Flat-fee定价模式已难以为继
- IPO压力将成定价重构导火索：OpenAI预计2029年前累计现金消耗1150亿美元，已承诺2030年前投入6650亿美元用于计算基础设施；Anthropic年化收入突破300亿美元、OpenAI达250亿美元，但这些收入在成本面前仍入不敷出——IPO后的公开市场将对利润率施加刚性要求，倒逼补贴时代终结
- 重定价序幕已然拉开：GitHub Copilot于2026年6月转向用量计费模式，Anthropic Max定价200美元/月，OpenAI推出100美元Pro版重新定义重度用户定价——这些仅是行业价格底线上移的开端
- 多数企业尚未正视危机：高盛调查显示许多大型企业AI预算已超支数倍，KPMG预计美国企业未来一年AI平均支出将达2.07亿美元，逼近工程师薪资水平；企业当前按20美元/席位预算AI成本，但实际等效API费用可能达1.5万至4万美元/月——补贴时代终结后，未做准备的组织将面临六位数年度预算缺口
I don't think AI will make your processes go faster
AI不会让流程变快的真正原因
- 市场低迷时企业热衷流程优化，如今AI浪潮更增添了不切实际的期望；作者重新阅读《丰田模式》和《目标》两本经典后发现，许多优化措施过于简单化，误解了应该关注的核心
- Gantt图示例揭示常见误区：人们看到软件开发耗时最长便直接将其作为优化目标，却忽视了一个关键事实——耗时最长的地方往往不是问题的真正根源
- 软件开发慢不是因为编码速度慢，而是上游需求定义不清晰——"销售完成后发送邮件"这类模糊描述会引发大量后续澄清工作，真正的问题出在需求梳理阶段
- 即使引入AI快速生成代码，同样面临上游问题：AI生成的是否是"正确"的代码？与人类开发者相比，AI需要更细致的需求输入和验证，实际的项目时间线并非如预期般大幅缩短
- 《目标》的核心教训指出：瓶颈环节应获得可预测、高质量的输入；加快流程的关键不是增加资源或依赖工具，而是审视上游条件是否具备——例如法律审批慢是因为缺少完整文档，那就应该解决文档问题而非增加律师
Mozilla to UK regulators: VPNs are essential privacy and security tools
Mozilla呼吁英国监管机构：VPN是重要的隐私安全工具，不应被限制
- 英国科学、创新与技术部正就"数字世界中成长"政策进行公开磋商，考虑对VPN实施年龄限制，该讨论的背景是用户为规避《在线安全法案》规定的年龄验证系统而使用VPN
- Mozilla向英国政府提交意见书，明确反对年龄限制VPN的提案，认为强制年龄验证和限制VPN等简单粗暴的干预措施不仅无法有效保护青少年，还会损害所有用户的基本权利
- VPN通过隐藏用户IP地址保护位置信息、减少在线追踪、避免基于IP的用户画像分析，对活动人士、异见人士、记者等弱势群体尤为重要，同时提升所有用户的在线基础保护
- 年轻人尤其容易受到在线追踪、定向广告以及未经充分同意或透明度的情况下为商业目的收集和处理个人数据的风险
- Mozilla认为限制年轻人使用隐私保护工具，与帮助他们在数字世界中建立自主性和负责任数字行为习惯的目标存在矛盾
- Mozilla建议监管机构应追究平台责任、鼓励负责任使用家长控制功能、投资数字技能教育，并采取全社会共同参与的数字福祉方法
Native all the way, until you need text
近二十年原生开发者的反思：富文本场景下 Web 技术的务实选择
- 作者拥有近二十年 macOS/iOS 原生开发经验，尝试用纯 Swift/SwiftUI 构建支持 Markdown 的聊天界面，发现原生方案在简单界面之外仍相当不成熟。
- SwiftUI 无法实现整篇 Markdown 文档的文本选择（设计如此），转而依次尝试 NSTextView、NSCollectionView、纯 TextKit 2，分别遭遇流式文本 CPU 突升、单元格闪烁、流式渲染性能差等问题。
- 逐层深入后意识到，仅为实现上下文菜单、字典查询、可访问性等基本原生功能就需要数月时间，最终转向 WebKit 渲染 Markdown，获得良好性能与几乎完美的排版。
- 最后尝试 Electron，结果令人惊喜——文本操作、Markdown 渲染、macOS 集成均开箱即用，性能甚至优于手写的 TextKit 2 实现。
- 反思指出：构建长篇富文本聊天时，SwiftUI 与 Apple 原生 SDK 不再是优势，反而成为约束，Web 技术提供了更实用的文本渲染模型。
- 这解释了为何大多数依赖聊天、富文本等核心交互模式的新应用选择 Web 技术——并非权宜之计，而是务实的技术选择。
Mercurial, 20 years and counting: how are we still alive and kicking? [video]
Mercurial：历经20年仍活跃的分布式版本控制系统
- Mercurial创建于2005年，是一个分布式版本控制系统，20年来持续活跃并保持竞争力，Firefox等大型项目仍在使用
- 尽管在2010年代的人气竞争中败给Git，但项目获得了大型科技公司的持续资助，并未真正消亡
- Mercurial社区孵化了多个现代工具，包括Heptapod，以及衍生工具Sapling（被Facebook采用）和jj-vcs/jj等
- 本演讲围绕四个核心问题展开：Mercurial如何度过Git风暴、它对用户生活的潜在影响、大公司参与如何重塑项目、2025年用户为何仍选择它
- 通过回顾历史，演讲旨在评估版本控制的现状与未来，并强调社区驱动型开源软件的相关性
Prolog Basics Explained with Pokémon
用宝可梦学习Prolog：逻辑编程入门
- 作者通过构建宝可梦规则引擎来学习Prolog，发现逻辑编程在表达复杂关系时极为简洁，灵感源自Bruce Tate的《七周七语言》，并将其应用于宝可梦draft league的对战分析
- Prolog的核心概念包括：谓词（predicates）定义关系、事实（facts）存储数据、交互式查询（queries）检索信息、变量以首字母大写标识并通过统一（unification）机制进行模式匹配
- Prolog查询支持任意参数作为变量，实现多方向灵活查询，例如查询"哪些是草属性宝可梦"只需将宝可梦名称设为变量；逗号表示"且"、分号表示"或"，多表关联查询比SQL的JOIN和EXISTS子句更加直观
- 规则（Rules）由头部和主体组成，仅当主体条件全部满足时规则成立，作者通过定义优先技能规则逐步排除干扰项（如双打技能、保护类技能），并使用条件语句处理特性加成效果（如具有潜台词特性的宝可梦技能优先度+1）
- Prolog的查询模型与数据模型本质相同，使得扩展查询和添加新规则变得简洁，而宝可梦社区的主流工具是硬编码固定技能的电子表格，Prolog则可查询任意技能组合及其对对手阵容的克制关系
- 作者认为这类"非程序员借助工具解决特定领域复杂问题"的场景在现实中普遍存在，Prolog可能是更优的解决方案，但目前该程序尚未有非程序员用户愿意使用——需要将其构建成网页应用