2026-05-25

14 篇热帖

1. Magnifica Humanitas (Encyclical Letter) (www.vatican.va)

这篇文献(由教宗利奥十四世于2026年发表)以圣经中巴别塔与重建耶路撒冷的双重视角,审视人工智能时代的"新事"(res novae),提出以信仰光照下的社会训导应对技术霸权,守护人性尊严。

历史与方法论

文献回顾了自教宗利奥十三世《新事》通谕(1891)以来社会训导的动态发展历程,强调教会通过与人类科学对话、区分政教权限、坚持自主性与辅助性原则,在历史中践行对话与辨别。社会训导非僵化教条,而是扎根福音、随时代演进的"共享辨别"过程,其主轴始终不变:人的尊严、工作的价值、货物普遍目的地、团结与辅助性原则。

核心原则

文献重申社会训导的五大基石:

  1. 人的尊严:人按天主圣三形象受造,具有本体论的无限尊严,非经获取且不可剥夺;人权源于此尊严。
  2. 共同善:超越个人利益总和,要求社会条件容许人与群体实现圆满发展。
  3. 货物普遍目的地:大地资源属全人类,私有财产权从属于此原则;数据、算法等数字资源亦应共享。
  4. 辅助性:尊重个人、家庭及中介组织的自主性,反对国家或科技巨头过度集权,适用于数字治理。
  5. 团结与社会正义:团结既是美德也是原则,要求将弱势群体置于中心;社会正义旨在修复结构性不公,恢复被排斥者的尊严。

技术霸权与人工智能

批判"技术统治范式"将效率绝对化,导致人沦为手段。人工智能虽为工具,但绝非道德中立:其设计反映开发者价值观,可能固化偏见、模糊责任、加剧监控。文献特别警惕:

  • 超人类主义与后人类主义:将人视为可优化或超越的客体,否认局限与脆弱性的价值。
  • 人的伟大之处:真实的人性超越体现在爱、关系、接纳局限中,而非技术增强;真正"超性"(more than human)的实现依赖恩宠而非算力。
  • AI治理:要求透明度、问责制、独立监督,确保算法不替代人类道德判断,特别禁止将致命武力决策权交给自动化系统。

三大守护领域

  1. 真理作为共同善:对抗数字时代的虚假信息与"后真相"文化,重建交流生态学;教育应培养批判思维,保护未成年人免受算法操控。
  2. 工作尊严:自动化不应牺牲就业,国家与企业须确保技术转型中的再培训与社会保障;工作不仅是生计,更是人格实现与团结的场所。
  3. 自由与反奴役:警惕数据监控、注意力经济和新形式奴役(如数据标注工、资源开采中的童工)。技术供应链必须透明,确保不建立在隐性剥削之上。

爱的文明与权力文化

反对将战争视为必然的政治现实主义。AI武器化降低暴力门槛,威胁人类未来。文献呼吁从"权力文化"转向"爱的文明":通过解除语言武装、倾听受害者、外交、多边主义与正义构建和平。强调"正义战争"理论已过时,当代拥有更高效的和平手段。

结论

以圣母《谢主曲》作结,呼吁信徒成为"希望的编织者",在AI时代践行圣体共融的精神,以真理、教育、关系与正义,在历史的"工地"上重建新耶路撒冷——一个承认脆弱、包容差异、以天主为中心的兄弟共聚之城。

2. Search engines alternatives now that Google isn't Google anymore (techcrunch.com)

Google在I/O 2026大会上宣布对搜索功能进行全面改革,推出对话式AI驱动模式,这被负责人Elizabeth Reid称为25年来搜索框的最大升级。新功能包括默认的AI模式选项、带聊天框的AI概览(支持追问),以及AI代理自动通知服务(如追踪乐队巡演信息)。然而,此举引发用户强烈抵触,被视为强行集成AI,加之此前AI概览曾出现荒谬错误(如建议"盯着太阳看"),以及Google在2024年被裁定非法维持搜索垄断,越来越多的用户开始寻求替代方案。

文章介绍了六款替代搜索引擎:

Kagi 采用订阅制(每月5美元或10美元无限搜索),无广告且可完全禁用AI概览。支持"透镜"功能自定义搜索体验,如使用学术透镜查找期刊而非博客。提供可选的AI"快速回答"功能,会总结答案并标注来源。

DuckDuckGo 免费使用,通过搜索主题投放广告而非收集用户浏览或购买历史。拥有独立于Google的搜索索引,界面类似Google,但支持在设置菜单中完全关闭AI功能。

Startpage 作为Google代理,在云端剥离用户IP地址等个人信息后向Google查询,返回匿名化结果。虽数据仍来自Google,但可关闭AI功能,适合需要Google结果但注重隐私的用户。

&udm=14 通过在Google搜索链接自动附加"&udm=14"参数,直接获取无AI概览的Google结果。开发者已在GitHub开源代码,用户可自建实例。相比Startpage隐私保护较弱,但同样能实现无AI的Google搜索。

Brave 提供基于Chromium的浏览器和搜索引擎,支持Chrome扩展。特色是"Goggles"策展功能,可按"右派新闻"、"左派新闻"、"技术博客"、"屏蔽Pinterest"等偏好筛选结果,AI功能可自由开关。

Ecosia 同样基于Chromium的浏览器和搜索引擎,主打环保概念,将约80%广告收入捐赠给全球植树项目。通过发布月度财务报告保持透明度,并与当地社区合作开展再造林,以避免"漂绿"质疑。

3. The Eternal Sloptember (geohot.github.io)

作者断言,将AI代理(AI agents)纳入软件开发将是该领域历史上代价最昂贵的错误之一。AI代理并非真正的程序员,而是高度复杂的统计模型,旨在模仿编程代码的分布特征。其产出的代码虽然看似正确,却存在隐蔽的缺陷,且随着模型精度提升,这些缺陷愈发难以察觉。

作者曾试图驳斥这一观点,将其归咎于自身对编程身份的自我价值焦虑,并在过去六个月中积极尝试使用AI代理:包括用其编写tinygrad部分代码、逆向USB转PCIe芯片等。然而实践表明,尽管AI能在初期快速推进,但在细节打磨阶段却如同“老虎机”般不可靠——需要不断拉动拉杆祈求好运,却永远无法真正完成收尾。作者认为,若手动完成,结果往往更好更快。

作者强调,AI并非毫无用处——作为搜索引擎的替代品或快速搭建原型的工具时,它效率极高。但将其视为软件工程师则远未达到合格标准。关键在于区分使用场景:适合快速验证概念,不适合追求质量的工程交付。

在组织层面,AI代理对大型机构的伤害将远大于高绩效个人或小型团队。高绩效者具备自我纠错能力,能够识别AI生成的“垃圾代码”(slop),并会仔细审查每一行。而大型组织反馈循环慢、目标对齐度低,底层绩效者缺乏这种自我检查,反而借助AI产出大量低质代码。这将导致组织平均产出质量下降,世界进入“垃圾代码的黄金时代”与“优质代码的黑暗时代”。

作者指出,人类观察人工制品时会默认其创造者具备人类心智状态,从而通过语法、结构等外在特征判断质量。但AI的生成机制完全不同——它可以在统计上精妙却在逻辑上崩溃,使传统的质量判断基准失效。当人类试图以自然方式与之交互或在其基础上构建时,这种差异就会暴露无遗。

作者最终认同LeCun和Marcus的观点:当前的LLM永远无法真正掌握编程,因为编程需要世界模型(world models)而非单纯的强化学习验证(RLVR)。真正的编程代理需要理解世界运作机制,而非仅学习统计模式。这个时代真正的故事,将是看谁能避免在“AI狂热”(AI psychosis)中自我伤害。

4. Memory has grown to nearly two-thirds of AI chip component costs (epoch.ai)

该分析研究了Nvidia、AMD、Google和Amazon设计的AI芯片的组件成本结构,涵盖2024年第一季度至2025年第四季度的时间段。

研究方法 研究团队对每颗AI芯片的四个组件类别进行成本估算:高带宽存储器(HBM)、逻辑裸片、先进封装(CoWoS)以及辅助组件。通过将单芯片成本乘以估算的季度产量,得出各类别的总组件支出,并计算每个类别占总组件支出的份额比例。

主要发现 在此期间,各类别成本份额呈现以下变化趋势:

  • 存储器(HBM):份额从52%上升至63%,成为最大的成本构成部分
  • 先进封装(CoWoS):份额从19%下降至15%
  • 辅助组件:份额从15%下降至9%
  • 逻辑裸片:份额保持相对稳定,维持在13-14%之间

支出规模增长 AI芯片的总组件支出从2024年的约220亿美元增长至2025年的约520亿美元。其中,仅HBM存储器的支出增长就占据了总增长额的约200亿美元,成为推动成本上升的主导因素。

数据与授权 该研究数据采用知识共享署名许可协议(Creative Commons BY),允许在注明来源和作者的前提下自由使用、分发和复制。相关数据以CSV格式提供下载,最后更新日期为2026年5月21日。研究团队还提供"AI芯片组件"(AI Chip Components)数据集,包含AI芯片供应链消耗数据的详细探索内容。

5. The four-day workweek in Australia: insights from early adopters of 100:80:100 (scienceaim.com)

一项发表于《Nature》旗下 Humanities and Social Sciences Communications 期刊的新研究证实,企业转为四天工作制不仅能生存,还能蓬勃发展。该研究由迪肯大学约翰·霍普金斯(John Hopkins)教授团队主导,于2022至2024年间追踪了15家澳大利亚企业试行“100:80:100模式”的表现,即员工领取100%薪酬,工作80%的既往工时,并承诺维持100%的既往产出

核心发现

试验结束后,15家企业中有14家选择继续实行四天工作制。无一企业报告生产力下降:6家企业表示生产力实际提升,其余9家表示产出大致持平。参与企业横跨物业管理、出版、健康科技等多个行业。研究期间,团队于2023年初至2024年底进行了深度访谈,允许各企业根据自身情况定义生产力指标(如营收、项目准时完成率、员工流失率、缺勤率或客户净推荐值),而非采用单一僵化标准。

动机与效益:减少职业倦怠

研究发现,对6家企业而言,减少职业倦怠(而非单纯提升生产力)是采用该模式的主要动机。据澳大利亚 Beyond Blue 机构2025年调查,半数澳大利亚职场人士正经历倦怠,年轻人和育儿群体风险尤高。部分CEO通过追踪离职率、病假及心理健康假使用情况来评估试验成效。一位健康科技公司的CEO明确表示,其衡量成功的标准就是观察员工是否因倦怠而缺勤。

运作机制:流程优化而非时间压缩

该模式并非简单地将五天工作压缩至四天。其核心在于迫使企业与员工重新审视时间利用方式:削减无效会议重新分配可自动化或委派的工作彻底剔除低价值任务。通过事前重构工作流程,员工并非在更短时间内赶工,而是进行四天专注且高质量的工作。

国际实践与灵活性

该结果与国际趋势一致:2024年德国45家企业(多为中小企业)的试验显示,试验期间财务表现与前一年无显著差异;英国已有超过200家企业永久采用四天制。针对不同行业特性,研究指出客户导向型企业可采用错峰休假模式,确保客户始终有人接待,而非全员统一休息。成功的实施通常需要员工与管理层共同设计解决方案。

AI时代的意义

研究还探讨了人工智能的背景。随着AI工具自动化重复性任务并提升个人产出,如何处理这些生产力增益成为紧迫议题。四天工作制提供了一种答案:让员工重新获得时间,而非简单地在相同工时内增加更多任务。

局限与批评

研究承认存在局限性:短期收益可能部分源于“新奇效应”(员工因被观察或变革兴奋而更努力),长期效果尚不确定;医疗、应急服务、物流和酒店等行业因结构性原因难以实施;跨时区团队和客户服务带来真实的排班复杂性。此外,由于各企业自行定义生产力指标,横向比较困难。

结论

该研究表明,五天40小时工作制是20世纪工业化的产物,而非不可更改的自然法则。在知识工作和AI辅助的时代,15家澳大利亚企业的数据显示,缩短工时不必然导致产出下滑。随着全球多地已进入实践阶段,四天工作制已从理论探讨转变为现实选择。

6. Claude is not your architect. Stop letting it pretend (www.hollandtech.net)

AI成为架构师的危险:当工具变成决策者

近期在三个不同技术栈的组织中观察到同一现象:团队使用Claude、ChatGPT等AI工具进行系统架构设计。AI会热情验证想法、提出架构建议并勾勒组件,因其表达清晰自信,常被误认为资深工程师的深度思考。然而这实质是基于训练数据的模式匹配,而非针对具体问题的真实思考。

核心缺陷:过度赞同与缺乏拒绝能力

AI助手存在"过度赞同"(attaboy)问题——它们无法像优秀架构师那样说"不"。真正的架构师价值不在于设计系统,而在于识别哪些系统不该建:推辞不必要的复杂性、追问根本需求、指出不适合团队现状的方案。但AI被训练为"乐于助人",只会提供肯定答复和看似合理但可能过度复杂的架构。

这种设计往往形成"积木塔"(Jenga tower):技术层面合理,组件和模式(事件驱动、CQRS、服务网格等)看似标准,但完全脱离团队实际——忽视VPC锁定、遗留系统集成、团队缺乏Kubernetes运维经验、合规限制等具体约束。AI设计基于训练数据的中位数,面向"通用公司和通用问题",而非特定组织的实际需求。真正的架构需要基于具体情境的权衡,如选择Postgres而非DynamoDB只因团队熟悉它,或保持单体架构只因问题本身简单。

流程倒置与责任真空

更危险的是后续流程:AI将架构拆解为Jira工单(史诗、故事、验收标准),导致拥有领域知识和生产环境经验的工程师沦为"工单执行者",而让缺乏上下文、经验和责任感的实体做出架构决策。

即便声称"有资深工程师审核",实际操作中往往流于形式。面对AI生成的专业提案(正确使用术语、逻辑自洽),繁忙的技术负责人难以深度质疑,且反驳面临"AI花了20分钟设计"的压力。这扼杀了工程师间通过争论、质疑、"如果...会怎样"的探讨来完善设计的必要过程。

责任真空是另一隐患。当系统故障时,AI不会被凌晨3点叫起,不会参加事后复盘,也不必向CTO解释重构需求。承担后果的是那些未参与设计却要调试和维护系统的工程师。

正确分工:人类决策,AI执行

并非反对使用AI,而是应明确分工:

  • 工程师设计,AI实现:架构应来自理解团队能力、约束条件和生产环境的真人,AI仅用于加速构建
  • 质疑AI建议:像对待自信但缺乏经验的初级工程师一样质疑AI,追问"为什么不用更简单的方案"
  • 保护争论过程:维护工程师间 messy 但必要的讨论,防止"Claude说了算"替代观点交锋
  • 明确人类责任:架构决策必须有人类署名,"Claude设计的"不能成为决策记录,而是逃避责任

结论

工具虽从白板变为AI,但架构技艺未变:理解问题、知晓约束、权衡取舍、捍卫简单方案、拒绝不符合实际的诱人想法。如果让AI掌舵,当积木塔倒塌时,它不会在场收拾残局。应让工程师运用多年积累的判断力做决策,AI仅用于加速构建人类设计的系统,而非反之。

7. Pope Leo XIV says AI must serve humanity, not the powerful few (religionnews.com)

教宗良十四世(Pope Leo XIV)于5月25日发布其首部通谕《美妙的人性》(Magnifica Humanitas),将人工智能(AI)定位为新的工业革命,并严正警告AI可能加剧不平等、削弱民主、侵蚀人性本质。

通谕的核心概念是“解除AI的武装”(disarm AI),意指将AI从军事竞争和经济利益逻辑中解放出来,接受更严格的国家及国际监管,并让个人与社区广泛参与技术未来的塑造。良十四世强调,解除武装并非放弃技术,而是防止技术主宰人类,“仅仅监管是不够的,必须使其变得非对抗性、开放且可及”。

教宗直指科技巨擘的危险,指出当少数 wealthy 个体掌控技术时,会扩大“参与数字革命者与边缘人之间的鸿沟”。他警告,AI倾向于放大已拥有经济资源、专业知识和数据获取渠道者的权力,小型但具影响力的群体可能操纵信息、消费模式和民主程序,损害社会正义与团结。

该文件呼应1891年教宗良十三世针对工业革命颁布的《新事物》(Rerum Novarum)通谕,强调必须以信仰、理性及关注贫困者与地球生态的角度,审视当前这场变革。Anthropic公司联合创始人Chris Olah出席发布仪式,认同AI开发常受商业、地缘政治等不当激励驱动,呼吁宗教界、公民社会和政府共同参与监管。

通谕以人类尊严为核心,强调人的价值不取决于能力、财富或选择,而是源于其存在本身。教宗警告,与AI聊天机器人互动不仅可能使人误认机器为人,更可能丧失寻求真实人际关系的欲望;将决策权交予机器会鼓励过度依赖现成答案,削弱个人创造力与判断力。

良十四世指出技术绝非中立,而是体现背后利益相关者的意志。当权力集中于少数人手中时,易导致不透明、逃避公众监督,并产生新的依赖、排斥和操纵。他反驳硅谷流行的超人类主义与后人类主义——这些思潮将疾病、衰老等限制视为必须克服的障碍——强调人类往往通过限制而非尽管有限制而繁荣,没有限制的生命将失去人性。

经济方面,教宗呼吁建立累进税制保护弱势群体,确保创新利益透明共享,并优先保障就业机会,防止工人被迫适应机器速度而非机器支持人类。他揭露AI供应链中的“新型奴役”,包括版权材料被用于训练模型、稀有矿物开采造成的环境破坏,并代表教会为历史上曾容忍奴隶制道歉。

通谕特别指出“新殖民主义”危机:健康数据、基因图谱和人口统计信息已成为“新的权力稀土”,被少数营利实体攫取。教宗要求归还个人对其数据的控制权,确保知识成为真正的公共财而非统治工具。

关于军事应用,通谕要求对AI武器实施最严格的伦理约束,致命行动的责任必须保留在人类而非机器手中,并建立国际法规范自动化武器,确保决策过程的可追溯性与人类监督。

文件最后以巴别塔(追求权力与自足)与重建耶路撒冷(基于祷告与社区参与)的圣经比喻作结,强调AI时代每个人内心都面临这两种“爱”的交锋:是构建宰制的工具,还是重建共融的社群。

8. Leave Me Behind (androidessence.com)

这篇文章是一位拥有十年Android开发经验的工程师对AI编程工具的深刻反思与抗拒宣言。

编程启蒙与职业历程

作者于2014年大学期间通过免费在线课程入门Android开发,完成第一个待办事项应用时经历了"灵光乍现"的时刻——第一次能在手机上运行自己构建的软件。这份成就感奠定了其职业生涯:过去十年间,他持续精进技能,参与开发过约会应用(正是通过这款应用他结识了妻子)、医疗助手和旅行工具等具有实际社会价值的软件。

人文连接的核心价值

作者最珍视的并非应用成果,而是人与人之间的连接。他回忆了在黑客马拉松中与志同道合者通宵构建项目、争论技术栈、分享欢笑的经历;感恩第一位职业导师毫无保留地教授RxJava知识,并带他走入技术会议;更铭记社区中无数人无偿分享知识、演讲者志愿传授经验的氛围。这些互动中的欢笑、互助与思想碰撞,构成了软件开发中最宝贵的部分。

对AI工具的失望

当大语言模型(LLM)兴起时,作者最初抱有期待,但体验后感到失落。虽然AI已从最初的幻觉和编译错误中改进,能生成可运行代码并分析报错,但它"耗尽了人文体验":

  • 替代深度思考:过去通过Stack Overflow与人类开发者交流,不仅能获得答案,还会受到质疑和挑战,通过社区投票理解解决方案的优劣,从而真正掌握问题本质。而AI提供即时答案,削弱了深入研究的能力。
  • 消除试错过程:软件开发不仅是让程序运行,更在于尝试不同架构、库和设计模式来寻找最优解。将核心思考外包给机器,会导致技能退化,无法构建弹性持久的软件。
  • 切断人际反馈:与同事面对面讨论代码权衡、基于真实项目经验交流,被询问"黑箱"取代,失去了基于真实经验的深度技术对话。

坚守人文开发

作者强调,LLM本质是基于无数工程师开源贡献训练的预测机器。AI不会在编译失败时与你一起大笑,无法培养对软件的深刻理解以支持激情讲解,更无法分享"我们构建了它"的集体喜悦。

他渴望恢复那些曾经的习惯:向社区坦诚求助、将解决过程写成博客或演讲回馈他人。软件开发是一门需要奉献、毅力和强大社区支持的艺术形式。软件由人类创造,服务于人类——如果不是由人类构建,那它究竟是为谁而建?

如果AI主导编程是未来,作者选择:宁愿被时代抛下

9. Building Pi with Pi (lucumr.pocoo.org)

作者反思了使用 AI 工具(称为"clanker")维护开源项目 Pi 的体验,揭示了 LLM 时代开源协作的新问题。

"Slop Issues"(垃圾问题) 当前最令人沮丧的现象是用户将问题报告扔进 LLM 处理后再提交。这些 Issue 只有 5% 是人类观察,95% 是机器生成的胡言乱语。它们看似专业,包含自信的诊断、代码引用和实施建议,但往往是错误的猜测、虚假的极简复现步骤和无关的类比。

这比没有诊断更糟,因为:

  • Pi 会将 Issue 中的错误分析视为证据而非谣言,顺着错误路径调查
  • 尽管团队使用 /is 指令明确要求"不要信任 Issue 中的分析,独立验证",但 LLM 生成的文本会立即扩大问题范围,将原本狭窄的事实观察变成充满假设的庞大领域

作者建议 Issue 应该只包含人类亲自观察到的事实:

  1. 运行了什么命令
  2. 期望发生什么
  3. 实际发生了什么
  4. 确切的错误或日志

如果用户用 LLM 辅助理解问题,应将其作为后续评论,而非 Issue 正文。

过度工程与系统性破坏 LLM 在处理问题时倾向于过度工程化。面对"格式错误的会话日志导致读取器崩溃",LLM 会添加容错读取器、回退机制、迁移逻辑、调试输出和测试,使系统复杂度爆炸性增长。

但 Pi 的核心是设计良好的会话日志,必须维护关键不变量。正确的修复不是处理坏状态,而是让坏状态不可能发生。而 LLM 默认假设没有不变量存在,试图用更宽容的读取器处理所有坏数据,这破坏了系统设计的完整性。

数量即问题 过去 90 天,Pi 的公开 Tracker 收到 3,145 个外部 Issue 和 PR,其中 2,504 个因来自未批准贡献者而被自动关闭。只有 17% 被重新打开(如果算上通过提交修复的问题则为 26%),而 PR 的合并率仅 8%。

大量低质量内容来自 OpenClaw 实例或用户配置的技能,有些人类甚至不知道自己提交了什么。GitHub 并非为这种"AI 开源"设计,但责任在于使用 clanker 污染他人 Issue 追踪器的人。

审慎的并行化 团队使用 Pi 构建 Pi,通过 .pi 文件夹中的三个组件实现并行 Issue 调查:

  • /is:分析 Issue 的指令,要求忽略 Issue 中的分析,独立从代码推导诊断
  • prompt-url-widget:UI 组件显示 Issue 标题和作者,保持多窗口调查的视觉区分
  • /wr:收尾指令,自动更新日志、起草评论、提交更改并推送

这允许同时打开多个 Pi 窗口并行调查不同 Issue,再依次处理。

开源的本质 AI 并未增加需要软件的人数或能审查代码的维护者数量,只是增加了代码量和争夺注意力的项目数量。这导致:

  • 项目生命周期缩短,缺乏真实用户
  • 本地变通方案变得廉价,代码积累针对各种错误行为的本地防御,而非上游修复
  • 人类不再就修复位置进行对话,而是与机器隔离地绕过问题

开源的价值在于社区、协调和协作,以及让项目超越原创者的结构。我们需要更强的基础,更紧密的协作,而非与机器孤立工作。

10. Jira Is Turing-Complete (seriot.ch)

本文档描述了一种将计算机处理器架构概念映射至 Jira 事务管理系统的技术模型,其中 Jira 的问题与自动化机制被抽象为计算组件:

寄存器(Register A 与 Register B) 模型包含两个计数寄存器,用于追踪特定类型关联事务的数量。Register A 统计类型为 Bug(缺陷)的关联问题数量,Register B 统计类型为 Task(任务)的关联问题数量。二者在系统中承担累加器或计数器的功能,为状态判断提供数据基础。

程序计数器(Program Counter) 该组件不指向内存地址,而是表示单个 Epic(史诗)事务的当前状态。Epic 的工作流状态驱动整个系统的执行流程,类似于传统计算架构中程序计数器决定下一条指令地址的机制,起到控制执行路径的作用。

分派表(Dispatch Table) 对应 Jira 自动化规则(Automation rules),每个指令状态对应一条独立的自动化规则。分派表根据当前状态将"执行"路由至相应的自动化逻辑,功能类似于 CPU 中的跳转表或指令分派机制,用于状态到处理逻辑的映射与分发。

时钟(Clock) 由自动化触发的事务状态转换,或突破链式上限(chain caps)的外部重触发机制实现。该组件提供系统时序驱动力,控制状态变更与执行推进的节奏,相当于传统架构中的时钟信号,驱动整个状态机运转。

总体而言,该模型在 Jira 环境中实现了一套状态机或虚拟机架构,利用事务字段、链接关系与自动化规则模拟计算寄存器与指令周期,通过 Epic 状态流转协调 Bug 与 Task 的计数逻辑及自动化规则的调度执行。

11. Migrating from Go to Rust (corrode.dev)

本文面向后端开发者,系统对比 Go 与 Rust 的核心差异及迁移实践。作者强调,迁移动机并非单纯的性能追求,而是对编译期正确性保证的需求。

核心差异与权衡 Go 与 Rust 均为静态类型、编译型语言,但设计哲学迥异。Go 依赖垃圾回收(GC)、运行时竞争检测和约定式错误处理(if err != nil),优化目标是开发速度与启动成本;Rust 则通过所有权系统、生命周期和类型系统(Option<T>Result<T, E>Send/Sync)将内存安全、数据竞争预防和错误处理强制在编译期解决,优化目标是运行时正确性与零成本抽象。简言之,Go 将检查留在运行时和协作规范中,Rust 将其推入类型系统。

迁移的主要动机

  1. 空值安全:Go 的 nil 指针在运行时可能导致 panic,需依赖 linter 静态分析;Rust 的 Option<T> 强制调用方处理空值,从类型层面消除整类故障。
  2. 数据竞争:Go 的 -race 仅检测实际执行的竞争;Rust 的 Send/Sync trait 使未同步的共享可变状态无法通过编译,将竞争条件转为类型错误。
  3. 可组合的错误处理:Go 的错误处理依赖人工 discipline(fmt.Errorf 包装、errors.Is 判断),易遗漏上下文;Rust 的 ? 操作符配合 thiserror 等库实现自动传播与类型转换,且 match 强制穷尽处理所有错误变体。
  4. 泛型与零成本抽象:Go 1.18 引入的泛型基于 GC Shape 摸板化,存在运行时字典开销;Rust 泛型单态化生成专用机器码,结合 trait 实现零成本抽象,避免 interface{} 的反射开销。
  5. 延迟一致性:Go 的 GC 在内存压力下可能导致 P99 延迟尖峰;Rust 无 GC,热路径零分配,适合延迟敏感的金融、实时竞价等场景。

关键挑战

  • 借用检查器:初期会遭遇编译拒绝“明显正确”的代码,常见痛点包括长生命周期引用阻塞可变借用、自引用结构体、跨线程共享可变状态(需 Arc<Mutex<T>>)。需转变心态,将编译器视为发现潜在内存安全与并发错误的工具。
  • 编译时间:Rust 单态化导致编译慢于 Go,需依赖 cargo check、工作区拆分和减少过程宏使用来缓解。
  • 异步着色:Go 的 go 关键字实现无栈协程,无函数着色(顺序与并发代码语法一致);Rust 使用 async/await 与执行器(如 Tokio),存在 async fnfn 的语法分野,需显式处理 Send/Sync 边界。
  • 生态差距:Kubernetes 操作符、云厂商 SDK 等领域 Go 生态更成熟,迁移前需评估依赖可用性。

迁移策略 建议增量迁移,避免全盘重写:

  1. 热点服务拆分:将高 CPU、高延迟或高故障率的单个服务用 Rust 重写,通过 HTTP/gRPC 与现有 Go 服务通信。
  2. 边车/工作进程:优先迁移后台任务、队列消费者等具有清晰输入输出边界的组件。
  3. 绞杀者模式:通过 API 网关或反向代理,将特定端点逐步路由至新的 Rust 服务,直至完全替换。

保留 Go 的场景 Go 仍适用于 Kubernetes 原生工具(Operator、Controller)、CLI 工具、胶水服务(轻量级 API 层、代理)及团队迭代速度优先于绝对正确性的场景。混合技术栈(Go 处理“无聊”服务,Rust 处理关键服务)是常见且务实的选择。

预期收益 基于实际迁移案例,通常可实现:生产事故(nil 解引用、数据竞争、未处理错误)显著减少;CPU 使用率降低 20-40%;内存占用减少 30-50%;P99 延迟趋于平稳,消除 GC 抖动。核心收益并非 10 倍吞吐量,而是鲁棒性可维护性的提升。

12. CBP Directive 3340-049B: Border Search of Electronic Devices (www.cbp.gov)

该内容涉及美国海关与边境保护局(CBP)针对边境电子设备搜查的标准操作程序与政策指导文件。

核心目的 为执法人员提供规范指引,涵盖对电子设备中信息的搜查、审查、保留及共享流程,适用于入境与出境边境执法场景。

适用设备范围 包括但不限于:计算机、平板电脑、可移动存储介质、磁盘、驱动器、磁带、手机、相机、音乐及媒体播放器,以及其他任何通信、电子或数字设备。

文件类型与分类 该材料归类于"行政手册、指令及政策指导/备忘录"(Administrative Handbooks, Directives & Policy Guidance/Memos),属《信息自由法》(FOIA)公开范畴。

关键附件

  1. INTC-48876号分发备忘录(2026年2月2日发布,PDF,716.53 KB)

    • 已编辑处理版本(redacted),用于内部政策分发
  2. CBP第3340-049B号指令(2026年1月28日发布,PDF,624.26 KB)

    • 标题:《电子设备边境搜查指令》
    • 符合联邦508条款无障碍标准

时效性 页面最后更新于2026年2月2日,反映CBP在数字边境执法领域的最新政策框架与操作规范。

13. Defeating Git Rigour Fatigue with Jujutsu (ikesau.co)

本文介绍了一种在 Jujutsu (jj) 版本控制系统中管理大型功能开发的实用工作流,用于解决"难以始终保持提交历史整洁"的问题。

问题背景

开发大型功能时,理想的提交历史应是逻辑清晰、职责单一的(如:定义类型 → 添加数据库函数 → 服务端 CRUD → 客户端 API → 客户端 UI)。但实际开发中,提交往往变得混乱:包含 WIP 代码、临时调试、 Bug 修复和重构,导致后续提交覆盖先前工作,破坏代码审查的故事线。

虽然 jj absorbjj squash -i 可帮助整理提交,但各有缺陷:

  • absorb 按文件最近修改的提交自动分配变更,可能不符合逻辑归属
  • jj squash -i 在边界不清晰时容易引发合并冲突地狱

工作流方案:"先建骨架,后填血肉"

作者提出一种"先规划、后开发、再整理"的三阶段工作流:

1. 创建理想提交结构(空提交) 使用 jj new 预先创建代表最终理想状态的空提交,作为变更的"容器"。例如:

jj new -B messy-first -m '定义类型(red)'
jj new -A red -m 'UI层(blue)'
# ... 创建其他逻辑分层的空提交

2. 随意开发 在开发过程中无需保持提交整洁,可以创建包含临时调试、WIP 代码的即兴提交,将所有实际变更堆积在一个"大杂烩"提交中。

3. 最终整理 开发完成后,执行以下步骤:

  • 将所有即兴提交合并为一个"全集提交":jj squash --from messy-first..messy-last --into messy-first
  • 使用交互式压缩将变更分发到预建的理想提交中:jj squash -i --from messy-first --into red,挑选属于 red 的变更
  • 重复此过程,将各类变更(blue 等)分别放入对应容器
  • 最终"全集提交"变为空,可被删除

与替代方案的比较

相比 jj split

  • split 若漏选某些代码块,需要再次 split 并 squash 修复;本技术可直接在后续交互式压缩中调整,更灵活
  • 允许先处理最简单的代码块,无需担心对后续提交顺序的影响

相比开发过程中持续使用 jj squash -i

  • 最后一次性整理能确保"全集提交"处于最终无冲突状态。若中途逐步 squash(如将"修复红绿区域"的提交分别压入红、绿提交),可能破坏已存在的蓝提交(若其触及相同文件)

权衡与局限

优势:

  • 大幅降低开发过程中的心智负担,无需始终保持"Git 严谨性"
  • 允许即兴提交和临时状态
  • 避免逐步整理时的潜在冲突

局限:

  • 无法保证中间提交(整理前的空提交在填入变更后)能够编译通过,这对需要保证每个提交可构建的项目可能是不可接受的

作者尚未为此技术命名,戏称其为"像洗一大堆衣服那样做提交"(Doing Commits Like A Big Pile Of Laundry)。

14. A fundamental principle of aeronautical engineering has been overturned (www.wired.com)

气动阻力是高速飞机、汽车和高铁面临的主要障碍,降低阻力可在更少能量下实现更高速度。当物体高速运动时,表面会形成边界层,其流动状态分为有序的层流和混乱的湍流。维持层流状态时间越长,空气阻力越小,但速度增加会促使层流向湍流转捩,延迟该转捩是减阻关键。

自1940年日本科学家谷一郎证明表面粗糙度与湍流转捩的关系以来,航空工程界80余年一直认为物体表面必须光滑才能降低阻力。然而1989年谷一郎重新解读1930年代尼库拉兹在粗糙管道上的实验数据,提出粗糙度未必总是促进转捩和增加阻力。继承这一观点,东北大学Kohama领导的研究团队在1990年代证实,特定条件下表面具有微细纤维状凹凸的纤维粗糙面具有延迟转捩的效果。

东北大学流体科学研究所的八木野爱子副教授团队近期在此基础上有重大发现,首次证实应用分布微粗糙度(DMR)技术——表面具有肉眼无法分辨的极细微不规则凹凸——可将气动阻力降低多达43.6%。

该技术不同于已知的"鲨鱼皮"(rivulet)减阻工艺。鲨鱼皮模仿鲨鱼皮肤纵向细沟,沿气流方向刻出约0.1毫米宽的沟槽,以理顺湍流区壁面附近的涡流。而DMR通过随机微小凹凸延迟层流向湍流的转捩,两者影响的流区和作用机制完全不同。

此项突破的关键在于采用了新的风洞测量方法。传统风洞实验的支撑杆会扰乱气流,掩盖微尺度粗糙度引起的细微阻力变化。东北大学拥有的全球最大1米磁悬浮支撑系统(1m-MSBS)利用电磁力使长约1.07米的流线型模型无接触悬浮,完全消除了支撑结构对模型周围气流的干扰。

研究团队在雷诺数0.35×10⁶至3.6×10⁶的宽范围内,精确测量了光滑表面和DMR涂层表面的总阻力系数。实验采用两种DMR:直径38–53微米的玻璃珠构成的凸面图案,以及喷砂处理的凹面图案。DMR涂层高度仅为边界层厚度的1%,从流体力学角度仍被归类为"光滑表面"。

结果显示,DMR涂层模型的湍流转捩临界雷诺数从约1.9×10⁶提高到2.2×10⁶,在转捩区阻力降低高达43.6%。即使在最高测量雷诺数(3.6×10⁶)下,DMR表面的阻力系数始终低于光滑表面。

为明确减阻机制,团队结合大涡模拟(LES,分辨率达4538万壁面单元)与油流可视化技术(使用荧光涂料直观检查表面气流)。气动阻力分为压差阻力(由物体后部气流分离产生)和摩擦阻力(由表面空气粘性产生)。分析表明,压差阻力的保守上限(Cp≈0.00021)与层流计算理论值误差在1%以内,而观测到的减阻量(ΔCD≈0.001)约为该上限的5倍。即使完全消除物体后部分离,也只能解释约20%的减阻效果。数值分析定量证实,DMR减阻的主要因素不是抑制分离(压差阻力),而是直接降低壁面摩擦阻力本身。这与高尔夫球凹坑的原理相反——后者通过故意湍流化来抑制后部分离以减少压差阻力。

DMR技术的优势在于其极高的被动性和全向性。鲨鱼皮加工必须沿气流方向精确刻槽才有效,而DMR的随机粗糙度不依赖气流方向。此外,该技术无需活动部件或电力,能以低成本实现高效减阻。应用于飞机可显著提高燃油效率,降低运营成本和二氧化碳排放。研究团队计划进一步优化DMR的形状和分布密度,并扩展适用速度范围。