该调查揭露了以色列军队在加沙战争中，使用名为“薰衣草”的人工智能系统大规模生成打击目标，并配合其他自动化工具，导致空前平民伤亡的流程。

1. AI目标生成系统：“薰衣草”

• 功能与作用：该AI系统分析加沙地带居民的大量监控数据，为每个人打分（1-100），评估其属于哈马斯或杰哈德军事派系成员的可能性。评分高的个人自动被列为打击目标。
• 规模与效率：在战争初期，“薰衣草”标记了约3.7万名巴勒斯坦人为潜在目标。军队将其输出视为“如同人类决策”，旨在解决“人类瓶颈”问题，实现目标生成的自动化与规模化。
• 准确性争议：内部评估显示系统准确率约为90%，即约10%的目标可能是错误标记。错误来源包括将与武装分子有通信联系的平民、亲属、同名同姓者或使用过武装分子旧手机的人误判为成员。

2. 高度自动化、简化的审核与打击流程

• “橡皮图章”式审核：对于“薰衣草”标记的低级目标，审核人员平均仅花费约20秒确认目标为男性，即批准轰炸。无需独立审查AI决策依据或原始情报。
• “爸爸在哪里？”等追踪系统：为定位目标，军队使用名为“爸爸在哪里？”等自动化追踪软件。这些系统实时监控标记目标，一旦目标进入家庭住宅，即自动发出警报，军队随即对该住宅实施轰炸。
• 选择武器与轰炸时机：为节省成本，对低级目标主要使用非制导的“哑弹”，可摧毁整栋建筑。系统性地在目标在家（通常是夜晚全家聚集时）时发动袭击，因为这比在军事活动中更容易定位。

3. 前所未有的平民伤亡容忍度

• 允许的“附带损伤”大幅放宽：在战争初期，为每名低级目标，军队被授权最多可造成15至20名平民死亡。对高级指挥官，可容忍上百名平民死亡。这与以往零容忍或极低容忍度的政策形成鲜明对比。
• 后果：导致数千名平民死亡，尤其是妇女和儿童。数据显示，战争前六周的死者中近半数在第一个月内丧生，其中许多是整户家庭被灭。

4. 配套的自动化与不精确工具

• 平民人数估算自动化：用于预估打击中平民伤亡的模型自动化且不精确，基于建筑大小和战前居民名单，再按估算的居民撤离比例折算，未实时核实实际居住人数。
• 缺乏实时验证与事后评估：有时从系统警报到实际轰炸存在时间差，导致目标已离开但仍轰炸住宅。对于低级目标的轰炸，通常不进行事后损伤评估，甚至不确认目标是否被击毙，只关注是否炸毁建筑。

5. 背景与态度

• 政策动因：10月7日袭击后，军方采取报复性心态，政策极其宽松。自动化系统旨在快速生成大量目标，以追求“杀伤力”。
• 军方立场：以色列军方否认使用AI定罪目标，称其仅为辅助工具，且要求独立的人类分析师审核。但多位参与行动的情报官员证词描绘了高度依赖AI、审核流于形式的相反图景。
• 影响：调查人员认为，这种大规模、自动化的打击方式造成了异常高的平民伤亡，并可能从长远上激发更多仇恨与反抗。

CityGaussian：基于高斯的实时高质量大规模场景渲染

核心问题与方法

该论文针对使用3D高斯溅射（3DGS）进行大规模场景重建和实时新视角合成所面临的挑战，提出了CityGaussian (CityGS) 方法。其核心挑战在于高效训练大规模3DGS并实现跨不同尺度的实时渲染。

CityGS采用了一种新颖的分治训练法和细节层次（LoD）策略来解决此问题。具体技术包括：

1. 高效训练与无缝融合：利用全局场景先验和自适应训练数据选择，实现高效的训练和不同区域高斯基元的无缝融合。
2. 跨尺度实时渲染：基于融合后的高斯基元，通过压缩生成不同细节层次。提出一种分块细节层次选择与聚合策略，实现跨大幅不同尺度场景的快速渲染。

实验结果

在大规模场景上的广泛实验表明，该方法达到了最先进的渲染质量，并能在不同尺度下实现一致的实时渲染。

关键对比实验：

• 未使用LoD技术的CityGS：在MatrixCity场景中，使用约2500万个高斯体进行渲染，测试速度仅为18 FPS（A100），交互体验不佳。
• 使用LoD技术的CityGS：实现了实时渲染，平均速度达到36 FPS（A100），显著提升了渲染效率与用户体验。

结论

CityGS通过引入分治训练和细节层次策略，有效解决了大规模3D高斯场景的高效训练与实时渲染难题，在保证高质量渲染的同时，大幅提升了渲染速度，使其适用于实际的大规模场景应用。

主要参考文献

论文主要引用并对比了Mega-NeRF、Switch-NeRF、3D高斯溅射等开创性工作，展示了其在大规模场景处理上的先进性。

早期计算机在没有堆栈时的子程序调用

在早期计算机没有堆栈和堆的时代，函数调用通过以下机制实现：

核心机制：使用秘密全局变量

• 编译器为每个函数的参数、返回地址和局部变量分别定义秘密全局变量。
• 函数调用时：
  1. 将参数值赋给对应全局变量
  2. 设置返回地址到该函数的秘密全局变量
  3. 跳转到函数入口
• 函数执行时：
  1. 从全局变量读取参数
  2. 使用预定义的全局变量作为局部变量
  3. 完成后跳转回返回地址变量中的地址

优化与变种

• 寄存器优化：使用链接寄存器自动保存返回地址，前两个参数通过寄存器传递
• 自修改代码：将返回地址变量直接设为跳转指令的地址字段
• 处理器指令支持：某些处理器添加了子程序调用指令（如bsr），将返回地址存储在子程序起始位置的字中

主要限制

• 不支持递归：递归调用会覆盖返回地址变量，导致返回地址错误
• 编程语言通过禁止递归来规避此问题，如FORTRAN直到1991年才标准化支持递归

历史背景

• FORTRAN最初不支持子程序（1958年添加）
• 动态内存使用固定大小缓冲区，超出则报错
• 这种机制反映了早期计算资源极度受限下的创新解决方案

IPEX-LLM：在Intel CPU和GPU上运行LLM的PyTorch库

⚠️ 项目状态

该项目已归档。Intel不再提供、保证其开发或支持（包括维护、错误修复、新版本或更新）。不再接受对此项目的补丁。项目存在已知的安全问题。

核心概述

IPEX-LLM 是一个面向 Intel GPU（如搭载iGPU的本地PC、独立GPU如Arc、Flex、Max系列）、NPU 和 CPU 的大型语言模型（LLM）加速库。它提供与众多流行框架的无缝集成，包括 llama.cpp、Ollama、vLLM、HuggingFace transformers、LangChain、LlamaIndex 等。

关键特性与优化

• 广泛模型支持：已对 70+ 个模型 进行了优化/验证，包括 Llama、Phi、Mistral、Mixtral、DeepSeek、Qwen、ChatGLM 等。
• 先进的LLM优化：支持 XPU 加速 和 低比特量化（FP8/FP6/FP4/INT4）。
• 多设备运行：支持在多种Intel硬件上运行，如 Core Ultra NPU、单/多卡 Arc GPU、Xeon + Arc GPU 组合。
• 丰富集成：可与 Ollama Portable Zip、llama.cpp Portable Zip 等工具一键部署。
• 分布式推理：支持在多个Intel GPU上进行流水线并行推理和基于DeepSpeed的张量并行推理。

近期更新亮点（2024-2025）

• 2025/05：使用FlashMoE，可在1或2个Intel Arc GPU上运行 DeepSeek V3/R1 671B 和 Qwen3MoE 235B 等超大模型。
• 2025/04：发布 ipex-llm 2.2.0，包含可移植的Ollama和llama.cpp包；新增对 PyTorch 2.6 的Intel GPU支持。
• 2025/03：支持 Gemma3 模型；可使用llama.cpp Portable Zip在单/双Arc A770 GPU上运行 DeepSeek-R1-671B-Q4_K_M。
• 2025/02：为Intel GPU（Windows/Linux）和NPU（Windows）提供 llama.cpp Portable Zip；支持直接在Intel GPU上运行 Ollama Portable Zip。
• 2024/12：新增对 Intel Core Ultra NPU（包括100H, 200V, 200K, 200H系列）的 Python 和 C++ 支持。
• 2024/11：在Intel Arc GPU上支持 vLLM 0.6.2。
• 2024/07：在Intel GPU上支持运行 Microsoft GraphRAG；新增对 StableDiffusion、Phi-3-Vision、Qwen-VL 等大型多模态模型的广泛支持；添加 FP6 支持。
• 2024/06：对 Intel Core Ultra 处理器添加实验性 NPU 支持；在多个Intel GPU上实现易于使用的大模型流水线并行推理。
• 2024/05：通过Docker镜像轻松运行ipex-llm；支持在Windows上一键安装。
• 2024/04：在Intel GPU上支持 Open WebUI；通过llama.cpp和ollama支持运行 Llama 3；新增C++接口，用于加速llama.cpp和ollama。
• 2024/03：项目从 bigdl-llm 更名为 ipex-llm。

性能与模型精度

文档展示了在 Intel Core Ultra 和 Arc GPU 上的令牌生成速度基准。同时，通过 Wikitext 数据集的困惑度测试，比较了不同量化方案（sym_int4, q4_k, fp6, fp8, fp16）下的模型精度，结果表明低比特量化在保持较好精度的同时显著提升了推理效率。

快速开始与使用方式

用户可以通过多种方式使用ipex-llm：

• 工具集成：Ollama、llama.cpp、Arc B580、NPU、PyTorch/HuggingFace、vLLM、FastChat、Text-Generation-WebUI、Axolotl（用于微调）等。
• Docker部署：提供用于GPU/CPU推理、vLLM、FastChat等场景的Docker镜像。
• 应用实例：支持运行 GraphRAG、RAGFlow、LangChain-Chatchat、Coding copilot、Open WebUI、PrivateGPT、Dify 等应用。
• 安装：提供 Windows GPU 和 Linux GPU 的安装指南。
• 代码示例：涵盖低比特推理（INT4/FP8/FP6/FP4/INT8/INT2）、FP16/BF16推理、分布式推理、模型保存/加载、模型微调（LoRA, QLoRA, DPO等）以及与社区库（HuggingFace, LangChain, LlamaIndex等）的集成。

已验证模型

超过70个模型已适配，主要包括：LLaMA系列（1/2/3/3.1/3.2）、ChatGLM系列、GLM-4/4V/Edge、Mistral/Mixtral、Qwen系列（1.5/2/2.5）、Baichuan2、InternLM系列、DeepSeek、MiniCPM系列、Phi系列、Whisper 等。详细列表请参考原文表格。

支持与反馈

• 如有错误或功能请求，请通过GitHub Issues提交。
• 请通过GitHub Security Advisory报告漏洞。

文章讨论了Phoenix LiveView与Svelte框架结合的优势，基于团队从纯LiveView转向LiveSvelte的实践经验。以下是核心内容总结：

LiveView的基本原理

• LiveView采用服务端有状态渲染模式：服务端负责页面状态和渲染，通过WebSocket增量更新DOM，类似SPA的体验但避免了前端微服务的复杂性。
• 对比传统SPA，LiveView简化了前后端分工，减少了路由和API层的样板代码，使业务逻辑更集中。

纯LiveView的痛点

1. 客户端状态不可避免
   对于动画、表单交互等需要即时响应的场景，LiveView需混合使用JS模块、hooks和自身状态，导致DOM状态管理复杂且模式不一致。
2. 组件体系复杂
   LiveView提供LiveView、LiveComponent、Component三种组件类型，它们语法、生命周期和通信方式差异较大，重构困难，且LiveComponent缺乏进程独立能力，限制消息传递。

LiveSvelte的解决方案

• 混合架构：通过LiveSvelte在LiveView中嵌入Svelte组件，形成前后端状态协同模型：
  • 服务端通过props向Svelte传递数据，LiveView进程可随时更新props触发前端重渲染。
  • 前端通过live.pushEvent向服务端发送事件，服务端处理后更新状态。
  • 双向通信基于LiveView维持的私有WebSocket，边界清晰。
• 优势：
  • 保留了LiveView的业务逻辑集中性和服务端状态管理能力。
  • 利用Svelte的前端组件模型和动画等特性，弥补了LiveView在交互体验上的不足。
  • 简化了前端复杂度（如数据过滤、转换等逻辑可放在服务端），减少前端样板代码。
  • 统一了路由和通信模式，避免SPA中常见的路由和API管理负担。

实践评价

• 团队认为LiveSvelte结合了两者优点：LiveView作为“后端为前端服务”的状态管理层，Svelte处理前端交互和渲染。
• 开发体验更高效，尤其对于需要精细前端交互的场景，且Svelte的简洁语法（如条件渲染）提升了协作效率。
• 文章建议对LiveView感到局限或寻求更成熟前端框架的开发者尝试此模式。

GCC 14 中 -fanalyzer 静态分析器的改进主要集中在以下方面：

1. 无限循环检测

新增了 -Wanalyzer-infinite-loop 警告，能够检测一些简单的无限循环案例。例如，当循环变量的更新存在错误（如使用错误的变量进行自增）时，分析器会发出警告并描述控制流路径。

2. 缓冲区溢出可视化

增强了 -Wanalyzer-out-of-bounds 警告的输出可读性。当检测到缓冲区溢出时，分析器现在会生成文本图表，可视化展示内存布局、写入操作及溢出位置，支持非 ASCII 字符的 UTF-8 表示，帮助用户更直观地理解问题。

3. C 字符串操作分析改进

• 对扫描缓冲区并寻找空终止符的 API 进行了模拟，能检测未正确终止的字符串缓冲区。
• 新增 null_terminated_string_arg 函数属性，用于标记期望以空字符结尾的字符串参数，帮助分析器识别潜在的越界读取。

4. 污点分析默认启用

修复了污点分析相关的大量误报问题，现在在启用 -fanalyzer 时默认开启污点分析。这包括对攻击者可控输入的跟踪和未消毒使用的检测，并启用了以下相关警告：

• -Wanalyzer-tainted-allocation-size
• -Wanalyzer-tainted-array-index
• -Wanalyzer-tainted-assertion
• -Wanalyzer-tainted-divisor
• -Wanalyzer-tainted-offset
• -Wanalyzer-tainted-size

示例展示了分析器如何检测到 Linux 内核 CVE-2011-2210 中因不正确的上界检查导致的漏洞。

5. 未来计划与发布

• 计划在 GCC 15 中改进警告输出的可读性，例如使用 ASCII 图形突出显示控制流路径。
• GCC 14（14.1 版本）预计于 2024 年 4 月正式发布，目前（2024 年 4 月）已在 Fedora 40 Beta 中使用预发布版本（GCC 14.0）。
• 用户可通过 Compiler Explorer 网站体验这些新功能。

核心论点：对xz后门事件的反思认为，仅修复ssh后门是不足够的。假设攻击者“Jia Tan”的行动是长期且多层次的恶意计划，那么当前系统中仍在运行其编写的代码，存在更广泛、潜伏更深的威胁。

关键担忧与潜在攻击向量：

1. 隐藏漏洞：xz中可能被植入隐蔽的缓冲区溢出等漏洞。攻击者可构造特制的xz文件，在解压时利用该漏洞篡改后续解压的其他软件源代码（例如，通过污染gcc或Apache文档中的图片文件），从而将后门扩散到更关键的软件中。
2. 可疑的代码变更：“Jia Tan”在二月（ssh后门被植入前两个月）主导了xz解码器的重写，新增了1000多行C代码。此举为植入此类隐藏漏洞提供了绝佳机会。随后的提交（如准备多版本和内联汇编）进一步增加了代码复杂性和隐藏点。
3. 禁用安全机制：“Jia Tan”设法禁用了Landlock沙箱。由于沙箱仅用于xz命令而非liblzma，这对ssh后门并非必需。禁用它表明攻击者可能计划让xz在dpkg或rpm等包管理器运行期间，任意写入系统文件以安装其他后门。
4. 可扩展的恶意框架：攻击者引入的基于“测试文件”的系统是可扩展的，意味着他们未来可随时添加更多恶意测试文件，以实现对xz的进一步控制。

结论与建议：

• 所有由“Jia Tan”编写或可能受其影响的提交都应被视为不可信。
• ssh后门很可能只是其长期计划的一部分，后续攻击的风险依然存在。
• 因此，建议发行版（如Debian）回退到更早、更安全的xz版本。
• 文章作者已创建并维护一个清理过的“xz-unscathed”分支，彻底排除了所有相关提交。

海底地图测绘项目“Seabed 2030”进展与挑战

项目背景与目标

• 起源：马来西亚航空MH370失踪事件（2014年）凸显了广大深海区域的未知性，推动了全球海底测绘行动。
• 成立：2017年由国际海底地形图委员会（GEBCO）与日本财团联合发起。
• 目标：到2030年完成全球海底测绘，绘制出所有大于100米的地貌特征，以支持联合国可持续发展目标第14项（保护和可持续利用海洋资源）。
• 初始状态：2017年项目启动时，仅6%的海底达到现代测绘标准。

当前进展与挑战

• 完成比例：截至2024年4月，约24.9%的海底已按项目标准完成测绘。
• 剩余任务：需在剩余6年内完成约75%的测绘工作。
• 主要挑战：
  • 极地冰盖：永久冰层覆盖区域难以探测。
  • 深海广阔：全球约50%海域深度超过3,200米。
  • 成本与效率：传统依赖船舶的测绘方式缓慢、昂贵，且偏向装备条件好的区域。

技术手段与新发现

• 数据收集方法：
  • 卫星测高：通过海洋表面高度变化反推海底地貌（如发现深海山）。
  • 声纳与激光雷达：船载或机载设备直接测量深度。
  • 众包数据：依靠科考船、渔船、货轮、邮轮等自愿提供数据。
  • 卫星观测：如英国ARGANS公司提供的高分辨率卫星测深数据。
• 新发现示例：
  • 2024年1月，施密特海洋研究所利用卫星测高线索，在中美洲沿海发现4座深海山，其中一座高达2,681米，占地450平方公里。
• 技术创新：
  • 自主航行器：如美国Saildrone公司的20米长风能太阳能测绘无人机，可在恶劣海况下以较低成本测绘深达7,000米的海底。
  • 人工智能：日本JAMSTEC等机构利用深度学习提升现有地形数据分辨率。

合作与未来展望

• 开放数据：所有测绘数据汇入免费访问的GEBCO海底网格。
• 伙伴关系：项目依赖全球科研机构、政府机构、企业及慈善组织的数据捐赠与合作。
• 未来方向：自主航行器和人工智能被视为加速测绘的关键，有望大幅提升覆盖效率和监测能力。
• 项目态度：尽管挑战巨大，项目负责人表示，通过全球合作，到2030年将比2017年（6%）大幅接近完成全球海底测绘的目标。

匿名公共语音邮箱收件箱摘要

项目概述 这是一个匿名公共语音邮箱项目，用户可以匿名录制并留下语音消息。该收件箱汇集了来自全球各地用户上传的录音，内容五花八门，构成一个独特的匿名声音社区。

时间与数量

• 收件箱记录共771条语音留言。
• 时间跨度从2023年5月持续至2026年6月，显示项目已运营数年。
• 消息按时间倒序排列，最新的记录为771号（2026年6月2日）。

内容特征 录音内容包罗万象，体现了匿名性带来的自由表达，主要类别包括：

1. 个人情感与故事：用户分享个人经历、情感宣泄（如思念、失恋、家庭问题）、秘密（如出柜、抑郁）或生活片段（如毕业、工作、失去亲人）。
2. 社交与问候：大量“你好”、“测试”类消息，以及对特定人或群体的问候、生日祝福或恶作剧。
3. 幽默与荒诞：包含笑话、恶搞、拟声词、无厘头短语和模仿（如拨号音、动物叫声）。
4. 观点与评论：涉及社会议题（如医疗、政治）、对特定事物（游戏、饮料品牌、名人）的看法，以及随机的人生感悟。
5. 互动与反馈：部分消息以“RE:”开头，回应或延续之前的留言，形成非实时对话。
6. 创意表达：包括即兴演唱、乐器演奏、诗歌朗诵、角色扮演和声音艺术。

具体例子（展示内容范围）

• 编号1：“Yooooo, I LOVE you dude”（0:58）— 表达喜爱。
• 编号277：“Shout out to The File>New Show!”（0:27）— 推广内容。
• 编号413：“Death of a cat (part 1)”（5:01）— 分享悲伤故事。
• 编号449：“Mike Tyson wants you to be prepared”（1:21）— 趣味引用。
• 编号497：“Mustard man has been summoned”（0:43）— 社区内部梗或玩笑。
• 编号545：“You are not alone”（0:42）— 提供支持。
• 编号636：“This website will forever be my favorite”（0:30）— 对项目本身的评价。
• 编号685：“I really love spending time with you”（1:01）— 私人情感。
• 编号714：“Welcome to the site!”（0:08）— 对新用户的欢迎。

意义总结 该项目作为一个数字时代的“匿名声音壁画”，记录了普通人瞬间的思绪、情感与创造力。它跨越地理和时间限制，提供了一个无评判的释放与连接空间，内容从深刻到琐碎，从私人到公共，共同构成了一个生动、真实的人类声音档案。

SWE-agent：普林斯顿团队开源的自动化软件工程代理

项目概述
SWE-agent 是一个开源工具，能让用户选择的语言模型（如 GPT-4o 或 Claude Sonnet 4）自主使用工具，在真实 GitHub 仓库中修复问题、发现网络安全漏洞或执行自定义任务。该项目由普林斯顿大学和斯坦福大学的研究人员构建与维护。

核心特点

• 在 SWE-bench 基准测试中，性能处于开源项目领先水平（12% 的修复率）。
• 设计灵活通用，最大化语言模型的自主权。
• 配置简单，由单个 YAML 文件管理，完全文档化。
• 专注于研究，设计简洁且易于修改。

版本与进展

• 开发团队目前主要投入于 mini-swe-agent，其性能与 SWE-agent 相当，但结构更简单，推荐作为后续使用首选。
• 近期重要版本更新：
  • 2024 年 7 月：mini-SWE-Agent 在 SWE-bench 验证集中达到 65% 的性能（仅 100 行 Python 代码）。
  • 2024 年 5 月：SWE-agent-LM-32b 在 SWE-bench 上实现开源模型最优性能。
  • 2024 年 2 月：SWE-agent 1.0 与 Claude 3.7 结合，在 SWE-bench 完整和验证集中达到当前最优性能。

使用方式

• 提供浏览器试用环境。
• 文档涵盖安装、命令行操作、基准测试及常见问题解答。
• 欢迎通过 GitHub 提交问题和拉取请求参与贡献。

相关项目

• EnIGMA：SWE-agent 的一种模式，专注于解决进攻性网络安全（夺旗赛）挑战，在多个安全基准测试中表现最优。需配合 SWE-agent 0.7 使用。

团队与引用

• 项目由 John Yang、Carlos E. Jimenez 等研究人员发起，联系邮箱见原文。
• 建议用户在研究中引用相关论文（SWE-agent 与 EnIGMA 的引用格式已提供）。

许可协议

• 采用 MIT 许可证。

美国生物技术公司LyGenesis首次为一名患者实施了一项实验性治疗，使其有望在自身淋巴结中“生长”出一个额外的微型肝脏。此项临床试验针对肝功能衰竭但尚未接受器官移植的患者。
这一治疗方法利用患者体内淋巴结为新肝组织的生长提供环境，旨在通过微型肝脏恢复部分或全部肝脏功能，为无法获取肝脏移植的患者提供新的治疗途径。
相关研究显示，异位肝组织在淋巴结中可生存并维持功能（见Nature Biotechnology, 2012；Liver Transplant, 2020两篇论文）。本次临床试验标志着该技术首次应用于人体，若取得成功，有望缓解肝脏器官短缺的问题并拓展器官再生医学领域。

文章标题报道了台湾发生的一次7.4级地震，震源深度为34公里。内容提及“最新地震”应用程序支持大多数现代浏览器，用户可查看支持的浏览器列表；如果应用程序无法加载，建议尝试使用旧版应用程序。

Cloudflare R2 新增三项功能

Cloudflare 宣布为其零出口费用的对象存储平台 R2 推出三项新功能，均处于测试阶段。

1. 事件通知（公开测试版）

   • 目的：允许在 R2 存储桶中的数据发生变化时自动触发 Workers，从而构建由数据变化驱动的应用程序和工作流（例如数据转换、媒体后处理）。
   • 工作原理：每次数据变化时，都会向指定的消息队列发送消息。消费者 Worker 接收消息并执行后续操作。
   • 启用方式：可通过 Wrangler 命令创建，例如 wrangler r2 bucket notification create <bucket_name> --event-type object-create --queue <queue_name>。

2. 针对 Google Cloud Storage 的 Super Slurper 迁移工具

   • 目的：简化从 Google Cloud Storage (GCS) 到 Cloudflare R2 的一次性数据迁移，无需自行管理迁移虚拟机和重试逻辑。
   • 优势：用户可借此享受 R2 的零出口费用，无论是永久迁移还是临时复制数据。
   • 操作方式：通过 Cloudflare 仪表板中的 R2 > 数据迁移选项，选择 Google Cloud Storage 作为源，配置凭据后即可启动迁移任务。

3. 低频访问存储类（私有测试版）

   • 目的：为不常访问的数据（如旧用户内容、日志）提供更低廉的存储成本，同时保持性能和持久性。
   • 使用方式：
     • 直接上传对象时指定存储类为 InfrequentAccess。
     • 设置对象生命周期策略，将一段时间后不常访问的数据自动移至此存储类。
   • 定价模型：采用类似 R2 的计费组件，但增加了数据检索（处理）费，即在检索低频访问数据时按 GB 收费，这使得存储单价得以降低。具体定价如下：
     • 存储：$0.01 / GB-月
     • A 类操作（写入、列出）：$9.00 / 百万次请求
     • B 类操作（读取）：$0.90 / 百万次请求
     • 数据检索（处理）：$0.01 / GB
     • 出口流量：$0（免费）
   • 未来计划：预计未来将支持自动优化存储类别，以适应数据访问模式的变化。

用户可加入私有测试版候补名单以获取低频访问功能访问权限。反馈可通过 Cloudflare 开发者 Discord 提供。

Portr：专为团队设计的开源ngrok替代方案

Portr是一个隧道解决方案，允许用户将本地的HTTP、TCP或WebSocket连接暴露到公共互联网。其底层技术基于SSH远程端口转发，以安全地建立连接隧道。

该工具主要面向小型团队，旨在方便地将开发服务器暴露在公共URL上，但不建议用于生产环境服务器。

主要特性：

• 支持将本地HTTP、TCP和WebSocket服务暴露到公共URL。
• 内置本地检查器，位于http://localhost:7777，用于检查请求、重放请求以及调试WebSocket会话。
• 通过portr logs命令提供对代理友好的本地请求日志，日志存储在~/.portr/db.sqlite数据库中。
• 提供管理面板，用于团队、用户和连接的管理。

核心功能与工作流程： 用户可以通过简单命令将本地服务暴露到公共URL，并可指定子域名以获得固定的访问地址（例如：portr http 9000 --subdomain amal-test）。启动一个HTTP隧道会立即产生三个效果：

1. 创建一个指向本地服务的公共HTTPS URL。
2. 在本地启动Portr检查器。
3. 将HTTP请求日志持久化到本地，可供命令行查询。

本地检查器与日志： 检查器功能允许用户：

• 检查传入的HTTP请求和响应。
• 重放已存储的请求。
• 检查请求头和负载。
• 监控升级后的WebSocket会话并捕获数据帧。

相同的数据也可通过命令行访问，支持按子域名、URL路径过滤，并可输出为JSON格式。

设置与集成： 项目提供了服务器设置、客户端安装、HTTP隧道配置及入门指南。此外，Portr还包含一个名为portr-cli的技能，可用于集成Claude Code和Codex（通过Vercel Labs skills），方便开发者在这些AI工具中使用。

贡献与许可： 项目欢迎社区贡献，并提供详细的贡献指南。该项目采用GNU Affero通用公共许可证v3.0（AGPL-3.0）授权。

藏红花：最昂贵的香料

藏红花（Saffron）是世界上最昂贵的香料之一，价格高昂源于其高度劳动密集型的收获过程。在超市中，0.5克藏红花售价可达8美元，而在网络上，10克藏红花的售价为120美元。所有藏红花均需手工从番红花（Crocus sativus）植物中采摘，该植物在秋季开花，花瓣呈紫色和蓝色。昂贵的原因并非种植困难，而在于提取过程耗时费力：花朵仅开放几天，必须在上午阳光充足时手工采摘柱头（stigmas）——那些珍贵的红橙色丝状物。研究表明，生产1公斤干燥藏红花需7万至20万朵花，耗时370至470小时。

藏红花起源于野生番红花（Crocus cartwrightianus），可能源自现今伊朗地区，通过人类选择具有长柱头的标本而驯化。现有番红花是不育的，依赖人工移植地下茎繁殖。最早的文字记载可追溯至公元前2300年的美索不达米亚作品《萨尔贡的传说》，其中将藏红花与城市关联。2022年的研究基于古代艺术和遗传学证据，提出藏红花约于公元前1700年在希腊首次被驯化。通过国际贸易，藏红花从中东和地中海地区传播至西班牙（921年引入），并最终扩散到英国、俄罗斯等地。

藏红花用途广泛：

• 烹饪：作为核心调味料，用于全球菜肴如西班牙海鲜饭和印度比尔亚尼菜，味道略带泥土甜味，带有烟熏香气。
• 药用：历史上被赋予多种药用属性，如镇静剂、祛痰剂、催情剂等，曾用于治疗发烧、忧郁症等。
• 染料：用于衣物或皮肤染色，在印度教中被视为神圣颜色，常用于额头点染；在罗马用于婚礼长袍；佛教僧侣的袍子颜色源于藏红花，但实际染色未必使用该植物。

现代藏红花主要生产于伊朗、印度和希腊等劳动力成本较低的国家。然而，藏红花对气候敏感，虽耐旱但惧怕极端高温，气候变暖可能延迟开花，影响农民收益。为此，一些农场通过旅游促进经济多元化。尽管科技发展，藏红花收获过程仍未实现机械化，其劳动密集特性维持了其奢侈品地位，使其在香料市场中始终独树一帜。

Plandex 概述

Plandex 是一款基于终端的 AI 开发工具，专注于规划和执行涉及多步骤、跨越数十个文件的复杂大型编码任务。它能处理高达 200 万令牌的上下文（单个文件约 10 万令牌），并可通过 tree-sitter 项目映射索引超过 2000 万令牌的目录。

核心功能特点

智能上下文管理

• 有效上下文窗口大：默认模型包支持 200 万令牌上下文，仅按需加载每一步所需内容。
• 适用于大型项目与文件：可轻松生成、审查、修订并应用跨数十个文件的更改。
• 快速项目映射：利用 tree-sitter 快速生成项目映射并进行语法验证，支持 30 多种编程语言。
• 上下文缓存：对 OpenAI、Anthropic 和 Google 模型使用上下文缓存，降低成本和延迟。

高可控性与灵活性

• 可配置的自主性：根据任务需要，可在全自动模式与精细控制模式间灵活切换。
• 自动化调试：可自动调试终端命令（如构建、检查、测试、部署和脚本）。若安装了 Chrome，还可自动调试浏览器应用程序。
• 项目感知聊天模式：帮助在实施前构思想法，也适用于提问和学习代码库。
• 多模型组合与切换：可轻松尝试并组合来自多个提供商的模型（Anthropic、OpenAI、Google 及开源模型）。提供不同能力、成本、速度权衡的精选模型包。
• 可靠的文件编辑：优先保证正确性。在需要时会验证语法和逻辑，遇到问题时具备多层回退机制。
• 完善的版本控制：支持对计划的每次更新进行版本控制，包括分支管理，以便探索不同路径或比较不同模型的结果。
• Git 集成：可生成提交信息，并支持自动提交。

开发友好且易于安装

• REPL 模式：支持命令和文件加载的模糊自动补全。只需在任意项目目录中运行 plandex 即可开始。
• CLI 界面：支持脚本操作或通过管道输入数据至上下文。
• 一键安装：CLI 安装无依赖。提供 Docker 化的本地模式以便自行托管服务器，也提供云托管选项。
• 强大的沙盒与回滚：采用累积式差异审查沙盒，将 AI 生成的更改与项目文件分离，直至准备就绪。命令执行受控，便于回滚和调试。

工作流程与托管

• 灵活的托管选项：
  • Plandex Cloud：于 2025 年 10 月 3 日起逐步停止服务，不再接受新用户。
  • 自托管/本地模式：可通过 Docker 在本地运行，或托管在自己的服务器上。需使用自己的 OpenRouter.ai 密钥或其他模型提供商账户和 API 密钥。
• 安装：可通过 curl 命令安装（支持 Windows WSL）。
• 配置：需设置模型提供商的 API 密钥环境变量。拥有 Claude Pro 或 Max 订阅的用户，可在首次运行时选择连接订阅。

资源与社区

• 提供完整文档。
• 设有 Discord、讨论区和问题跟踪系统供交流反馈。
• 项目接受贡献，鼓励参与开发和改进。

文章摘要

本文记录了巴西特种环境执法部队G.E.F.在亚马逊雨林深处，特别是雅诺马米原住民保护区，打击猖獗的非法采矿活动的行动与困境。

核心行动力量：G.E.F.部队

• 性质与构成： G.E.F.是隶属于巴西环境部的一支小型特种部队，成员多为拥有生物学、生态学等高学位的“科学战士”，接受过专门的战术和野外作战训练。领导人是费利佩·芬格。
• 任务： 在总统卢拉发起的“自由行动”（内部称“Xapirí行动”）框架下，深入亚马逊腹地，侦察、摧毁非法采矿营地及其设备（如挖掘机、船只、发电机），打击矿工（garimpeiros）。
• 行动方式： 利用直升机和GPS情报进行快速突袭。由于法律限制难以逮捕普通矿工，主要策略是销毁设施和营地，迫使矿工撤离。行动中面临矿工使用星链（Starlink）通讯预警、设置障碍、甚至携带武器等对抗。

严峻的环境与人道危机

• 非法采矿的破坏： 非法淘金和锡石开采使用重型机械和汞，严重破坏河流系统与森林，导致生态退化。全球金价上涨加剧了这一热潮。
• 雅诺马米人的苦难： 矿工的侵入给与世隔绝的雅诺马米原住民带来了疾病（如疟疾）、饥饿、暴力（包括谋杀和性侵）乃至死亡。一段矿工骚扰与世隔绝社群的TikTok视频成为行动导火索。
• 犯罪集团渗透： 采矿活动日益受到如“首都第一司令部”（P.C.C.）等有组织犯罪集团的控制，他们提供资金、武器并参与毒品洗钱，使冲突更加危险。

复杂的政治与社会背景

• 历史与政策摇摆： 前总统博索纳罗任期对环境监管大幅倒退，纵容采矿。卢拉上任后宣布紧急状态并发动大规模清理行动，短期内取得成效（非法毁林率下降）。但军方配合度低，行动后非法采矿回潮。
• 深层困境： 地方经济依赖资源开采，许多贫困民众将采矿视为生计出路。军方历史上对亚马逊开发和原住民权利持保留态度。环保部门（如IBAMA）长期人手与资金不足。
• 行动局限： G.E.F.部队人数极少，面临法律授权不足、资源有限、当地势力抵制以及犯罪集团武装化等多重挑战。他们自知是在“打一场可能输掉的战斗”。

原住民领袖的呼声 雅诺马米代表达维·科佩纳瓦指出，卢拉政府虽有行动但远未解决问题，非法采矿和犯罪活动仍在继续，他呼吁总统亲临被侵占领土实地查看。

结语 尽管面临巨大困难，G.E.F.部队凭借专业和信念坚持行动。然而，他们的努力被描述为“只能推迟亚马逊的终结”。文章结尾以一处曾遭骚扰的雅诺马米定居点被遗弃、而附近又出现新矿坑的景象，凸显了保护工作的紧迫性与艰难。

GIAM（数学艺术入门指南）摘要

教材概况

• 名称：GIAM (a Gentle Introduction to the Art of Mathematics)
• 版本：当前版本为 3.1
• 性质：免费、开源教科书
• 许可证：遵循 GNU 自由文档许可证 1.3 版

核心内容

• 涵盖领域：数学基础，包括逻辑、集合、关系、函数与基数。
• 教学重点：介绍多种数学证明技巧，如直接证明、间接证明、反证法、逆否命题证明、数学归纳法、组合证明等。
• 特色：每章开头附有有趣的引言。

配套资源

1. 教材正文：提供 PDF 格式下载。
2. 练习册：单独的练习工作簿。
3. 解答手册：包含提示与解答。

技术信息与版本

• 排版：使用 PDFLaTeX 排版。
• 图形制作：图形由 XFig 生成，照片使用 GIMP 修改。
• 源代码：源文件压缩包可下载，源代码托管在 GitHub。
• 替代版本：提供其他版本可供选择。

获取方式

• 电子版：可从网站免费下载 PDF。
• 实体版：可通过 CreateSpace 按需印刷获取平装本。

Redict 7.3.0 版本发布

Redict 社区宣布发布 Redict 7.3.0，这是其基于 Redis® OSS 7.2.4 的 copyleft（版权左翼）分支的首个稳定版本。用户可通过 Codeberg 官方仓库或容器镜像 registry.redict.io 下载。

项目定位与特点

Redict 专注于稳定性与长期维护，追求在现有范围内实现卓越。相较于同期出现的另一个分支 Valkey，Redict 采取更保守的创新策略，优先保证软件的长期可靠性，而非追求激进的功能扩展。这种差异既源于项目文化——强调有限范围和长期稳定性，也服务于区别于商业驱动项目的目标。

许可证与社会目标

• 许可证：采用 LGPL（Lesser GNU General Public License）。这能保护贡献者的劳动成果不被纳入专有软件（如 Redis® 的转向），同时平衡商业用户需求，允许云服务商在不涉及复杂合规问题的情况下提供 Redict 服务。
• 社会政治目标：强调独立、草根、社区驱动的开发模式，不受少数商业利益集团控制，致力于构建基于自由软件的未来，避免用户和贡献者再次面临因商业原因导致的危机。

基础设施

项目全面采用自由软件工具链：

• 代码托管：使用非营利的自由软件平台 Codeberg，而非 GitHub。
• 持续集成：运行在自由软件 SourceHut 上。
• 社区交流：选择 Matrix 和 IRC 而非 Discord。 此举体现了项目响应 Redis® 许可证变更，加固自由软件生态系统的决心。

致谢

文章感谢了多位核心贡献者（如容器、文档、客户端库等方面）以及所有提交补丁、参与测试的人员，同时致敬了上游 Redis® OSS 的众多贡献者及其构建的社区。

未来计划

未来的保守性改进计划包括：

• 现代化构建系统（候选方案为 muon）。
• 分支生态系统，尤其是 Redis® 客户端库（社区贡献的重要方向）。
• 去 vendor 化，分离如 Lua 和 jemalloc 等依赖。
• 大幅投入文档建设，目标是成为生态系统的权威参考。
• 对官方 Redis® C 客户端库的分支 hiredict 进行改进。

放下跟上步伐的想法：对阅读中竞争心态的反思

童年阅读的自我竞争与当前变化

作者回忆童年时，在图书馆为获得金星而阅读童话书，这是一种自我竞争，享受积累星星的乐趣。然而，近年来，阅读氛围发生了变化：在线讨论书籍时，出现了一种混合了义务、社交表现、好奇、爱书、参与欲望和早期采纳主义的感觉，导致从“想读”转变为“必须跟上”的压力。

阅读的本质被量化扭曲

阅读本应是生产性的，产生想法、情感和同理心，但现在却常被量化框架束缚，如设定阅读数量目标、完成阅读挑战或比较阅读量。例如，Goodreads挑战成为一种品牌方式，表达“最近读书不多”，这实际上将阅读转化为任务和数字游戏，影响人们将快速阅读视为常态。

个人经历揭示社交压力

作者分享在纽约书店工作的经历，原本热爱书籍社区的对话和热情，但逐渐感受到必须对某些书籍或作者持意见的压力。一次，在书店地下室，朋友的朋友询问最近阅读内容，带着期待核对清单，作者突然不想谈论阅读，因为感觉阅读被游戏化，不再是简单的享受。

在线书籍讨论的负面影响

这种氛围渗透到在线书评中，人们为没有时间阅读而焦虑，担心“落后”于阅读挑战或目标。作者质疑：落后于谁？这些挑战、列表和书堆分享服务了什么目的？它们可能带来快乐，但对一些人来说，却导致压力和对阅读方式的错误认知。

建议：回归阅读的内在价值

作者鼓励读者，如果量化阅读带来快乐，可以继续；否则，应给自己空间，远离互联网和量化平台。阅读的价值是不可量化的，它是体验、过程、教育和礼物，无论每年读10本还是100本书，都能从中受益，无需向他人证明。

德克萨斯大学奥斯汀分校的一项跨学科研究，通过可穿戴设备在真实生活场景中进行了长期监测，验证了体力活动、睡眠质量与心理健康之间的关联。

核心发现：研究指出，体力活动会延长快速眼动睡眠潜伏期，即进入REM睡眠阶段所需的时间。这表明运动可能有助于在进入REM睡眠（通常伴随生动梦境、大脑活跃度接近清醒状态）前，巩固更深层次的睡眠。

研究方法与创新：与以往在实验室中观察单夜睡眠的研究不同，本研究发表于《自然-科学报告》，采用创新方法。研究人员利用手腕佩戴的活动追踪器，在自然环境（家、工作等）中对82名年轻参与者进行了长达数月的连续监测，记录其运动、心率以及由此推断出的睡眠阶段（如深度非快速眼动睡眠和快速眼动睡眠）。同时，通过智能手机应用程序收集参与者的自我报告幸福感数据。

主要结果：

• 该研究成功复制了先前实验室研究的结论：无论是低强度还是中高强度的体力活动，都与更深度、更具恢复性的睡眠相关。
• 更好的睡眠质量随后又与次日早晨更高的精力水平和更低的压力感相关联。
• 关键突破在于首次利用此类穿戴式设备，在真实场景中展示了睡眠结构（指每个睡眠周期内不同睡眠阶段，如深度NREM和REM的构成）与个人感知的幸福感之间的关联。

研究意义：

• 此研究克服了传统实验室研究的局限性，如环境陌生带来的压力及无法进行长期观察，其结果更具普遍性。
• 研究证实，即便是标准的消费级可穿戴设备（如Fitbit），也能敏感地测量睡眠结构并产生具有预测价值的结果。
• 这为未来在自然环境中，利用普及的穿戴设备大规模研究与生活方式、情绪乃至情绪障碍相关的睡眠模式开辟了新的可能性。

关于SSD的知识总结 (基于2019年文章)

本文是一篇关于固态硬盘的中等技术深度讨论，旨在澄清与SSD相关的一些常见误解，并解释其与HDD在工作原理上的根本区别。

1. SSD基本原理与结构

• 核心存储技术：SSD使用NAND闪存（一种非易失性存储器）存储数据。数据存储在由浮栅晶体管构成的单元中，通过控制单元中的电子数量来表示数据。
• 基本操作：NAND闪存支持读、编程（写入）和擦除三种基本操作。其中，擦除只能在块级别进行，而读和写入的基本单位是页。
• 物理构成：SSD内部主要由少量的NAND闪存芯片和一颗复杂的控制器芯片组成。
• 多级单元：根据每个单元存储的比特数，可分为SLC、MLC、TLC和QLC。单元存储的比特数越多，容量越大、成本越低，但通常速度越慢、寿命越短、读写过程越复杂。
• 3D NAND：为了突破平面NAND的容量极限，发展出了3D NAND技术，通过垂直堆叠存储层来增加存储密度，是当前主流技术。

2. 与HDD的根本差异及关键机制

• 写入限制：这是SSD与HDD最关键的差异。NAND闪存不能原地覆盖写入。要修改一个页的数据，必须将其标记为无效，并将新数据写入一个全新的、已擦除的页。
• 闪存转换层（FTL）：控制器中的核心组件。它维护着逻辑区块地址（LBA，主机使用的地址）到物理块地址（PBA）的动态映射表，以应对不断变化的物理页位置。
• 垃圾回收：由于写入会产生无效页，为保持可用空间，控制器会在后台将有效数据从一个包含无效页的块复制到新块，然后擦除旧块。此过程对主机透明，但会增加写入放大。
• 磨损均衡：控制器通过算法，确保所有闪存块被均匀地擦写，以避免某些块过早耗尽寿命，从而延长SSD的整体使用寿命。
• 过量配置：SSD的实际物理存储容量大于标称的用户可用容量。这部分额外空间用于管理操作（如垃圾回收、替换坏块等），是维持性能和寿命所必需的。标准过量配置约为物理容量的7.37%，部分型号会更多。

3. 数据管理、安全与性能

• TRIM命令：这是文件系统（如Windows NTFS）与SSD控制器之间的一个关键优化指令。当文件被删除时，系统会通过TRIM告知SSD哪些逻辑页已不再使用，允许控制器将其标记为无效并优化垃圾回收。启用TRIM对维持SSD长期性能至关重要。
• 已删除文件恢复：在支持并启用了TRIM的现代SSD上，删除的文件几乎无法恢复。因为TRIM指令（配合DZAT行为）会使主机后续读取这些页时直接返回零值，且实际数据可能很快被垃圾回收机制彻底清除。
• 安全删除的无用性：在SSD上执行“安全删除”（如覆写文件内容）或“擦除空闲空间”是无效且有害的。它不仅无法安全擦除数据（因为覆写会触发写入新页），还会产生不必要的写入量，增加磨损。
• 读干扰：读取一个页时，同块内其他页会受到微弱电压影响，可能随时间累积导致数据错误。控制器通过监控读取次数并在必要时重写块来管理此问题。
• SSD寿命：现代消费级SSD（如文中提到的120GB TLC型号）的标称写入寿命（如40TB）对于普通用户来说绰绰有余，在正常使用下几乎不可能在“可预见的未来”磨损耗尽。

4. 常见误解澄清

• SSD不需要碎片整理：传统碎片整理（整理文件碎片）对SSD性能提升无益，甚至有害。但Windows系统的“优化驱动器”功能，在特定条件下可能会对SSD执行必要的维护性操作（如发送TRIM指令或为系统还原点进行碎片整理），这与传统碎片整理目的不同。
• “写满零块”恢复性能：早期关于用工具写满零来恢复SSD性能的说法是误解。实际效果等同于触发了TRIM，释放了无效页，并非因为零值有特殊作用。
• MLC/TLC是“多层”单元：这是一个命名上的历史遗憾。“MLC”特指每单元存储2比特，而存储3比特的是TLC，4比特是QLC。从物理上看，所有单元本质上都是单层单元，只是控制器通过施加不同的电压阈值来解读其存储的多个比特。

结论

SSD是一种复杂而精密的设备，其工作方式与HDD截然不同。理解其“写入前必须擦除”、“需垃圾回收”以及“依赖TRIM”等核心特性，有助于用户正确使用和维护SSD。尽管其内部控制器算法高度复杂且保密，但其设计目标是为用户提供快速、可靠且持久的存储体验。

本文介绍了三体问题的一个非常基础的模拟。作者使用欧拉方法和较小的时间步长进行计算，发现即便采用简单的数值方法，也能得到较具视觉效果的三体运动轨迹。作者还尝试将三体随时间变化的极坐标转换为RGB颜色并制作动画，结果显示轨迹变化带来了较为突兀且闪烁的色彩转换。

该模拟的初始位置取自论文（arxiv:1805.07980）中的三体周期轨道F10。与利用高精度ODE求解器dop853得到的结果对比，可以看出简单欧拉方法虽然整体轨迹形状可辨识，但经过两周期后误差变得明显，模拟精度有限。

物理学中的拉格朗日变换（Legendre Transform）常在分析力学和热力学教学中被模糊介绍，导致学生和从业者基本概念理解不清，其定义与应用存在严重教学缺陷。主流教材，如Goldstein、Landau等，通常仅给出拉格朗日量与哈密顿量的公式转换，并通过不明确的微分符号和变量关系描述，缺少严格的数学结构和清晰定义。例如，“拉格朗日变换将变量从速度变换到动量”，但如何理解及操作这一变量独立性，教材多依赖隐含知识，如函数的凸性、变量可逆性，而非系统解释。

Arnold的《经典力学的数学方法》给出了较严谨定义：对凸函数f(x)，拉格朗日变换g(p)通过最大化“f(x)-px”获得，并由极值条件f’(x) = p确保唯一解。此定义虽形式清晰，但缺乏对变换本质（如自反性、对称性）的解释。相比傅里叶变换等函数变换，拉格朗日变换常被介绍得更为晦涩，学生难以领略其几何与数学联系。

作者提出更简明的定义：“两个凸函数F和G为拉格朗日变换互为变换，当它们的一阶导数互为反函数。”例如，如果G的导数g’与F的导数f’互为逆，则它们互为拉格朗日变换。这定义通过互为反函数的关系体现出变换的对称性与自反性，并指出实际的物理量只有导数（如哈密顿量和拉格朗日量的梯度），而非其绝对值本身，具有物理意义。例如，哈密顿量和拉格朗日量的转换公式，可理解为“哈密顿量的动量梯度与拉格朗日量的速度梯度互为逆函数”，配置变量的梯度相差符号并完成变量替换，两者全等。

对多变量情形，拉格朗日变换扩展为：

• 凸函数F和G分别定义在不同变量组上（如配置量与“动力”量），F和G互为拉格朗日变换时，各变量组上的梯度满足反函数关系，且配置变量的梯度相差符号。定义依然要求凸性保证唯一逆关系。
• 若处理非凸函数，则用最大化（supremum）的方式定义拉格朗日变换。此时变换后的函数总是凸的，实际上拉格朗日变换后等于原函数的凸包（convex hull）的拉格朗日变换，对非凸函数应用拉格朗日变换两次相当于取凸包。

拉格朗日变换的本质是将一个变量（如速度或温度）的函数，转为其共轭变量（如动量或压力）的函数，建立两种力学、热力学表述之间的联系。其结构特点：

• 独特性：梯度互为逆函数，函数间对称，自反（一阶变换后原函数可逆回）。
• 物理意义：只依赖于函数的导数（梯度），绝对值可加常数（物理上无意义）。
• 可扩展性：多变量自然推广，非凸函数变换具有凸化作用。
• 要求：需要函数对被转换变量凸，保证变换的唯一性和一致性。

作者强调标准教材多追求“公式美”，而不解释变换结构与原理，导致学生对物理基本“操作系统”理解浅表，实际可用更直观的导数逆关系定义，显著提升学理解与应用能力。