阅读视图
2025年总结
TODO
一如既往,主要在工具链领域耕耘。但由于工作忙碌在opensource社区投入的时间减少了。
Blogging
不包括这篇总结,一共写了18篇文章。
Understandingand improving Clang -ftime-report - Natural loops
- lld 20 ELFchanges
- Migratingcomments to giscus
- CompilingC++ with the Clang API
Relocationgeneration in assemblers LLVMintegrated assembler: Improving MCExpr and MCValue LLVMintegrated assembler: Improving expressions and relocations - GCC 13.3.0miscompiles LLVM
LLVMintegrated assembler: Engineering better fragments LLVMintegrated assembler: Improving sections and symbols Understandingalignment - from source to object file Benchmarkingcompression programs - lld 21 ELFchanges
- Remarks onSFrame
Stackwalking: space and time trade-offs Sacramento游记 - Weak AVL Tree
llvm-project
翻新了integrated assembler,写了4篇相关的blog posts:
https://maskray.me/blog/tags/assembler/ Reviewednumerous patches. query is:pr created:>2025-01-01 reviewed-by:MaskRay=> "989Closed"
Linux kernel
贡献了两个commits,被引用了一次。
ccls
clang.prependArgs- 支持了LLVM 21和22
ELF specification
尝试推进SHF_COMPRESSED那样压缩section headertable。包括我在内的另一些人不喜欢采用general compression。
Misc
Reported 6 feature requests or bugs to binutils.
ld --build-id does not use symtab/strtab contentgas: monolithic .sframe violates COMDAT group rulegas: Clarify whitespace between a label's symbol and its colonld: Add --print-gc-sections=fileld riscv: Relocatable linking challenge with R_RISCV_ALIGNld: add --why-live
旅行
- 第一次去:台南、西安、兰州、天水、Sacramento、Puerto Vallarta,Jalisco, Mexico、Mazatlán, Sinaloa, Mexico
- 曾经去过:台北(上一次是近11年前)、北京
在 tvOS 上活下來:一個非典型播放器的工程實錄
tvOS 绝非 iPad 的放大版。本文是 Syncnext 播放器的工程实录,深入解析 Apple TV 开发的真实陷阱:从 Focus 焦点机制、严苛的存储限制,到 SwiftUI 填坑与 AVPlayer 深度调优,助开发者在 tvOS 平台上“活下来”
Frida Hook 流程
黑白厨师
这几天一口气刷完了 Netflix 出品的《黑白厨师》,感触颇深。没想到 Cooking 也能套上《鱿鱼游戏》的外壳:极简的规则,极端的赌注,有限的时间,封闭系统内的零和博弈。
在看之前,我对「温馨的烹饪」能否与「大逃杀美学」兼容是非常存疑的。但看完后不得不佩服,Netflix 不仅处理得很好,还在这场残酷的阶级叙事中,端出了一盘关于「人性」与「身份」的顶级料理。
机制:绝对真空里的「强制公平」
如果把《黑白厨师》看作一部韩剧,「机制」就是它最精彩的剧本。烹饪综艺最大的痛点在于:味觉是主观的,如何保证结果的公正与说服力?
节目组做了一个极其大胆的设定——蒙眼试吃。
当白钟元和安成宰蒙上眼睛,张嘴等待喂食时,这画面不仅充满了某种荒诞的宗教仪式感,更是一种暴力的强制公平。它强行抹去了「白汤匙」积累数十年的名声红利,把米其林三星主厨和外卖店老板拉到了同一条起跑线(味蕾)上。这种「在一个不公平的世界里创造一个残酷但公平的真空」,正是大逃杀题材最迷人的地方。
而评委的「双璧」设定,则是机制中另一个神来之笔。白钟元代表着「大众的味蕾」与「商业的敏锐」,追求直觉的爽感;安成宰则代表「精英的标准」与「技术的严苛」,追求意图的精准。两人的争论,实际上是将「好吃究竟有没有标准」这一哲学命题具象化了。这种价值观的碰撞,也是一大看点。
场景:感官的高压工厂
Netflix 的综艺有一种你一看就知道是「Netflix 出品」的质感。巨大的仓库、整齐划一的 40 个烹饪台、冰冷的不锈钢,当 40 名黑汤匙同时开火,那个画面不像厨房,更像是一个高压工厂或战场。为了满足 4K/HDR 的严苛画质,灯光采用了电影级的布光,甚至连声音设计都做到了极致——备菜的切剁声、炉火的轰鸣声,营造出一种 ASMR 般的沉浸感(一种让人头皮发麻、脊背发凉但又感到极度舒适和放松的生理反应)。这种极致的物理压迫感,会把屏幕前的观众也拉进去(所以一定要看高清的)。
玩家:艺术家与谋略家
如果说机制如剧本,厨师就是演员。除了对「厨艺」和「哲学」的考核,这档节目更深层地展现了「生存博弈」。
这就不得不提崔铉硕主厨。如果说其他人是在比赛做菜,那么崔铉硕更像是在「玩游戏」。在团队海鲜战中,他疯狂囤积扇贝让对手无材可用;在餐厅经营战中,他制定超高价策略,以极少的出餐量换取了最高的营业额。他敏锐地捕捉到了现代餐饮的残酷真相:厨艺好不等于会经营,商业头脑往往决定生死。
他的存在,打破了传统厨师的刻板印象,为节目注入了《鱿鱼游戏》的智斗感。
当然,这也是一个群像极佳的舞台。制作组显然精心挑选了那些拥有「鲜活、粗糙且充满生命力故事」的人。如果没有这些故事,这就是一场单纯的技艺展示;有了这些故事,菜品就有了灵魂。
核心人物:诗意与狂傲
最终的决战也是我心目中最好的结局,两位风格迥异的厨师,分别代表了烹饪的两个极端。
Edward Lee:寻找归途的诗人
看到 Edward Lee 的第一眼,就感觉到一种不一样的气质:说话不疾不徐,有一种淡淡的诗意。即使年过半百,依然像个少年一样在寻求突破。
对于他而言,这不仅仅是比赛,更是一场「身份认同的寻根之旅」。作为一个在美国长大的韩裔,他的料理(如拌饭口味的冰淇淋)本身就在挑战「正统韩餐」的定义。决赛那道「辣炒年糕点心」是整季的高光时刻。当他用不熟练的韩文念出那封信,讲述「Edward 喜欢威士忌,但李均(他的韩文名)喝玛格丽」时,那种异乡人的孤独与对故土的深情,瞬间把我击穿。
那不勒斯美味黑手党(权圣晙):专注的狂徒
如果 Edward 是水,权圣晙就是火。他身上体现的是年轻人的自信、狂傲,以及极致的专注。
在败者复活赛中,当所有人都在做咸口菜时,他独辟蹊径选择做甜品「栗子提拉米苏」。为了防止食材被拿走,他守在冷柜前啃巧克力的画面,有一种「认真的拙劲」。他选择 Edward Lee 战队时的果断,以及决赛前的放狠话环节,都展现了他极强的策略性和胜负欲:
“爱德华主厨,为了让你早点回家休息,今天我会速战速决。”
这种狂傲并不让人讨厌,因为他有与之匹配的实力。
我有时也会切换视角:假如自己是 Netflix 的决策者,面对这样一个项目,如何确保「基本能回本」(保底能力),同时又可能挣很多(其实就是价值投资)?对于白汤匙、黑汤匙、白钟元、安成宰,他们决定参与的动机是什么?杠杆点在哪儿?如果最后项目失败了,最可能是哪些地方出了问题?这样的思考也充满了乐趣。
ET,福尔摩斯,马尔科维奇,爱迪生:四种思维训练法
关于好奇心的重要性,怎么强调都不为过。尤其是在工作了一段时间之后,好奇心往往最先被消磨:流程变得熟悉、问题开始重复、注意力被琐碎事务和压力不断切割,慢慢地,我们便不再追问「为什么」。
为了对抗这种精神熵增,我总结了一套简单易行的思维训练法。通过四种「角色扮演」模式,强制切换视角,外加一个通用框架作为辅助工具,帮助我们找回对世界的敏锐度。
1. ET 模式(外星人视角):对抗「习以为常」
核心理念:去熟悉化(Vuja De)
我们常说 Déjà vu(既视感),即对陌生环境感到熟悉;而 ET 模式追求的是完全相反的状态——Vuja De(未视感)。即:面对最熟悉的事物,强迫自己把它当成第一次见到,甚至完全不理解其用途。
- 「火星人观察报告」:尝试描述一件日常小事,但不使用约定俗成的名词。以「开会」为例,如果剥离掉「会议」这个概念,在 ET 眼中看到的是:一群碳基生物围坐在一张木板旁,地位最高的雄性发出声波,其余低阶生物低头在发光的玻璃板上快速移动手指。洞察:这种视角的价值在于剥离了社会强加给事物的「功能固着」。当不再把「低效的会议」理所当然地看作「工作流程」,才更有可能发现其本质——比如「信息传递效率极低」,进而思考:为什么不直接进行脑电波传输(发文档)?
- 「为什么追问链」:因为 ET 从没见过地球的物品,所以一切都值得质疑。顺着这个逻辑链条深挖:为什么手机屏幕是长方形的?(为了适应手掌抓握);为什么一定要手持?(因为要随时观看);为什么一定要用眼睛看?(目前的信息交互受限于视觉)。这种像孩子一样的连续追问(比如我小时就很好奇,为什么大人们打招呼通常都是「饭吃了吗」),往往能带我们穿透表象,触达事物的底层逻辑或生理极限。
2. 福尔摩斯模式(侦探视角):对抗「视而不见」
核心理念:观察而非仅仅「看见」
福尔摩斯有一句名言:「你只是在看,你没有在观察。」 (You see, but you do not observe.) 这个模式要求我们将模糊的现状清晰化,寻找因果链条和逻辑漏洞。
- 从废弃中寻找线索:最近在看《黑白大厨》时,注意到一个细节:评审白钟元注意到角落里有一碟被回收的、只吃了一半的牛肉。其他选手都没有注意到,他还拿起其中一块没被吃过的牛肉品尝,发现牛肉过于干柴。 这就是侦探视角——从被忽略的细节(剩菜)中反推过程(烹饪失误),进而挖掘出被掩盖的真相。
- 关注「沉默的证据」:除了看到的,还要关注没发生的。比如在福尔摩斯的《银色马》一案中,关键线索是「那只在晚上没有叫的狗」。因为狗没叫,所以牵走马的人一定是熟人。在工作中,如果能注意到「谁没有发声」、「哪个数据没有变化」,有时能发现比喧嚣表面更重要的信息。
3. 马尔科维奇模式(体验视角):对抗「自我中心」
核心理念:深度沉浸与换位思考
概念源自电影《成为马尔科维奇》,主角通过一道暗门能直接进入马尔科维奇的大脑,透过他的眼睛看世界。在生活中,这个模式几乎随处可用。
比如在咖啡馆里,可以尝试切换视角:
-
作为店员:
- 为什么选择这家店?
- 需要哪些技能?
- 如果跳槽,可能会去哪里?
-
作为老板:
- 为什么选址在这里?
- 与周围咖啡馆的差异是什么?
- 收入、成本、利润结构大概如何?
- 哪些地方还有改进空间?
看剧时同样适用。比如:如果我是《绝命毒师》里的老白,在被 Tuco 掳走、Tuco 又被杀之后,该如何解释自己的失踪,既合情合理,又不引起怀疑?
4. 爱迪生模式(实验视角):对抗「光想不做」
核心理念:假设与验证
爱迪生代表的是实干派与实验精神。当对某个现象产生好奇,比如「为什么这类小红书帖子会火?」不只停留在分析。试着提出假设(可能是封面图夸张,也可能是标题引发焦虑),然后设计一个低成本的实验——发几篇不同风格的帖子去验证你的假设。在产品领域,这就是先做 Demo 验证可行性。唯有实验,才能将好奇心转化为确定的认知。
一个通用框架:3W2H
最后分享一个我自己经常使用的框架:3W2H。它是在黄金圈法则(Why–How–What)基础上的扩展,更适合日常思考。
以「电视」这个习以为常的物品为例:
- What(本质):它是什么?是显示屏,还是家庭娱乐中心?
- Why(根源):为什么我们需要电视?是为了获取信息,还是为了背景噪音?
- How(机制):它的运作原理和组成是什么?
- How much(量化):它的价格构成是怎样的?覆盖了多少人群?
- What if(假设):如果世界上没有电视会怎样?有完美的替代品吗?
这套组合拳能迅速将一个单薄的概念拆解得立体而丰满,在短时间内建立对陌生领域的深度认知。
好奇心不仅是一种能力,更是一种对抗平庸的武器。当我们开启 ET 的眼睛,用福尔摩斯的大脑思考,钻进马尔科维奇的躯壳,并像爱迪生一样去动手实验时,原本枯燥乏味的世界就会立刻生动起来。
世界没有变,变的是我们看待世界的分辨率。希望这四种模式和工具,能帮你擦亮积灰的镜头,重新发现那个充满惊奇的「新世界」。
Capacitor + React 的 iOS 侧滑返回手势
Swift 6.2 列传(第十七篇):钟灵的“雷电蟒”与测试附件
App 暴毙现场直击:如何用 MetricKit 写一份完美的“验尸报告”
04-📝物联网组网 | DTBluetoothProvider概要设计文档
一款轻量、低侵入的 iOS 新手引导组件,虽然大清都亡了
PolarisGuideKit:轻量、低侵入的 iOS 新手引导组件(遮罩挖孔 + Buddy View + 插件化)
关键词:UIKit · 新手引导 · 低侵入 · 插件扩展
GitHub:github.com/noodles1024…
背景:我为什么做这个组件?
可能是新手引导这个功能太小,随便实现一下也能用,导致没有人愿意认真写一个iOS下的新手引导组件,搜遍整个github也找不到一个在现实项目中能直接拿来用的。如果只考虑某一个具体的新手引导界面,实现起来很容易(特别是现在在AI的加持下,UI仔都不需要了)。但在不同项目、不同场景下,经过和和产品经理&设计师的多次沟通中,我发现了做“新手引导/功能提示”时的一些令人头疼的问题:
- 需要高亮某个控件,但布局变化、屏幕旋转后挖孔(高亮)位置容易偏
- 指引说明(箭头/气泡/按钮)形态不固定,可能还伴随着音频播放等附加功能,复用困难
- 点击高亮区域时,难以做到不侵入原有点击业务逻辑
- 显示新手引导时难以在不改变原有逻辑的情况下阻止NavigationController的滑动返回
- UITableView/UICollectionView
reloadData后高亮经常失效
于是我做了 PolarisGuideKit:一个基于 UIKit 的轻量新手引导组件,主打低侵入 + 可扩展 + 动态高亮。
PolarisGuideKit 能解决什么?
| 能力 | 说明 | 带来的价值 |
|---|---|---|
| 高亮遮罩 | 遮罩挖孔高亮 focusView | 高亮区域自动跟随,内置高亮效果,可自定义 |
| Buddy View | 说明视图可自由定制 | 文案、箭头、按钮任意组合 |
| 步骤编排 | 多步骤引导流程 | 支持下一步、跳过、完成 |
| 动态 focusView | reloadData 后自动修正 | TableView/CollectionView场景稳定 |
| 插件化扩展 | Audio/埋点/持久化 | 可插拔、解耦 |
快速上手(3 分钟接入)
import UIKit
import PolarisGuideKit
final class MyViewController: UIViewController {
private var guide: GuideController?
override func viewDidAppear(_ animated: Bool) {
super.viewDidAppear(animated)
let step = GuideStep()
step.focusView = myButton
step.buddyView = MyBuddyView()
step.forwardsTouchEventsToFocusView = true
step.completer = ControlEventCompleter(control: myButton, event: .touchUpInside)
let controller = GuideController(hostView: view, steps: [step])
controller.onDismiss = { _, context in
print("引导结束,原因 = \(context.reason)")
}
_ = controller.show()
guide = controller
}
}
核心概念一图速览
- GuideController:流程编排器,负责 show/hide/切换步骤
- GuideStep:一步引导配置(focus、buddy、style、completer)
- FocusStyle:高亮形状(矩形/圆形/圆角/无高亮)
- GuideBuddyView:说明视图(可继承自定义)
- GuidePlugin:生命周期扩展(音频/埋点/持久化)
重点能力拆解
1) FocusStyle:高亮样式可拔插
内置样式包含:
-
DefaultFocusStyle(矩形) -
RoundedRectFocusStyle(圆角矩形) -
CircleFocusStyle(圆形) -
NoHighlightFocusStyle(全屏遮罩)
let step = GuideStep()
step.focusView = someCard
step.focusStyle = RoundedRectFocusStyle(
focusCornerRadius: .followFocusView(delta: 2),
focusAreaInsets: UIEdgeInsets(top: -6, left: -6, bottom: -6, right: -6)
)
2) 动态 FocusView:Table/CollectionView不卡壳
UITableView / UICollectionView 复用导致高亮错位?
使用 focusViewProvider 动态获取最新 cell:
let step = GuideStep()
step.focusViewProvider = { [weak self] in
guard let self else { return nil }
var cell = self.tableView.cellForRow(at: targetIndexPath)
if cell == nil {
self.tableView.layoutIfNeeded()
cell = self.tableView.cellForRow(at: targetIndexPath)
}
return cell
}
3) 触摸转发 + 自动完成
在不侵入原有业务逻辑的前提下,高亮按钮依然能触发业务逻辑,同时自动关闭引导:
let step = GuideStep()
step.focusView = myButton
step.forwardsTouchEventsToFocusView = true
step.completer = ControlEventCompleter(control: myButton, event: .touchUpInside)
✅ 设置forwardsTouchEventsToFocusView和completer保证了“引导不侵入原有业务逻辑”。
4) Buddy View:说明视图随便做
继承 GuideBuddyView,自定义 UI + 布局:
final class MyBuddyView: GuideBuddyView {
override func updateLayout(referenceLayoutGuide layoutGuide: UILayoutGuide, focusView: UIView) {
super.updateLayout(referenceLayoutGuide: layoutGuide, focusView: focusView)
// 根据 layoutGuide 布局你的文案 / 按钮 / 箭头
}
}
5) 插件系统:音频 / 埋点 / 持久化
内置 AudioGuidePlugin,可在显示引导时播放音频文件,且可在BuddyView中配合显示音频播放动画(可选功能):
let step = GuideStep()
step.focusView = myCard
step.addAttachment(GuideAudioAttachment(url: audioURL, volume: 0.8))
let controller = GuideController(
hostView: view,
steps: [step],
plugins: [AudioGuidePlugin()]
)
如果想要加埋点、标记“引导是否已显示”,可通过自定义
GuidePlugin实现。
Demo 示例一览
- 圆角矩形高亮 + 圆角模式切换
- 圆形高亮 + 半径缩放
- 多步骤引导 + 平滑转场
- 触摸转发 + 自动完成
- 点击外部关闭(dismissesOnOutsideTap)
- 音频 + Lottie 同步演示
- UITableView 动态高亮
架构 & 视图层级
flowchart TB
subgraph Core["核心组件"]
GuideController["GuideController<br/>(流程编排器)"]
GuideStep["GuideStep<br/>(步骤配置)"]
end
subgraph ViewHierarchy["视图层级"]
GuideContainerView["GuideContainerView<br/>(透明容器)"]
GuideOverlayView["GuideOverlayView<br/>(遮罩 + 触摸转发)"]
MaskOverlayView["MaskOverlayView<br/>(遮罩基类)"]
GuideBuddyView["GuideBuddyView<br/>(说明视图)"]
GuideShadowView["GuideShadowView<br/>(焦点追踪器)"]
end
subgraph Extensions["扩展机制"]
FocusStyle["FocusStyle<br/>(高亮形状)"]
GuideAutoCompleter["GuideAutoCompleter<br/>(完成触发器)"]
GuidePlugin["GuidePlugin<br/>(生命周期钩子)"]
GuideStepAttachment["GuideStepAttachment<br/>(插件数据)"]
end
GuideController -->|"管理"| GuideStep
GuideController -->|"创建并承载"| GuideContainerView
GuideController -->|"派发事件"| GuidePlugin
GuideContainerView -->|"包含"| GuideOverlayView
GuideContainerView -->|"包含"| GuideBuddyView
GuideOverlayView -.->|"继承"| MaskOverlayView
GuideOverlayView -->|"创建"| GuideShadowView
GuideOverlayView -->|"使用"| FocusStyle
GuideStep -->|"配置"| GuideBuddyView
GuideStep -->|"使用"| FocusStyle
GuideStep -->|"通过...触发"| GuideAutoCompleter
GuideStep -->|"携带"| GuideStepAttachment
安装
Swift Package Manager
- Xcode → File → Add Packages…
- 输入仓库地址:
https://github.com/noodles1024/PolarisGuideKit - 选择 PolarisGuideKit
CocoaPods
pod 'PolarisGuideKit'
import PolarisGuideKit
注意事项(踩坑清单)
-
focusView必须是hostView的子视图 - 多 Scene / 多 Window 建议显式传
hostView -
GuideAutoCompleter触发后会结束整个引导(建议用于最后一步) - 动画转场在复杂形状下可关闭动画:
animatesStepTransition = false
项目地址 & 交流
- GitHub:github.com/noodles1024…
- Issues / PR:欢迎一起完善
- 如果觉得有帮助,欢迎 Star ⭐️
AT 的人生未必比 MT 更好 -- 肘子的 Swift 周报 #118
AT 的人生未必比 MT 更好 - 肘子的 Swift 周报 #118
学车时我开的是手动挡,起初因为技术生疏,常搞得手忙脚乱,所以第一台车就直接选了自动挡。但开了几年,我开始追求那种完全掌控的驾驶感,于是又增购了一台手动挡。遗憾的是,随着交通日益拥堵,换挡的乐趣逐渐被疲惫抵消,最终这台车也被冷落。算起来,我已经快二十年没认真开过手动挡了,但内心深处,我仍会时不时地怀念那段“人车合一”的时光。
Agent 模型的思维链是什么
关于 Agent 模型的思维链,之前被几个高大上的词绕晕了,claude 提出 Interleaved Thinking(交错思维链),MiniMax M2 追随和推动标准化,K2 叫 Thinking-in-Tools,Deepseek V3.2 写的是 Thinking in Tool-Use,gemini 则是 Thought Signature(思考签名)。了解了下,概念上比较简单,基本是一个东西,就是定义了模型思考的内容怎样在 Agent 长上下文里传递。
是什么
在25年年初 deepseek 的轰炸下,思考模型大家都很熟悉了,在 Chatbot 单轮对话中,模型会先输出思考的内容,再输出正文。再早的 GPT-o1 也一样,只不过 o1 不把完整的思考内容输出。
在 Chatbot 进行多轮对话时,每一次思考的内容是不会再带入上下文的。每次到下一轮时,思考的内容都会被丢弃,只有用户 prompt 和模型回答的正式内容会加到上下文。因为在普通对话的场景下没必要,更倾向于单轮对话解决问题,长上下文会干扰模型,也会增加 token 消耗。

这些思考模型用到 Agent 上,就是下图这样,每次模型输出工具调用,同时都会输出 thinking 内容,思考应该调什么工具,为什么调,但下次这个思考内容会被丢弃,不会带入上下文:

Agent 的 loop 是:用户输入 → 模型输出工具调用 → 调用工具得出结果 → 模型输入下一步工具调用 → 调用工具得出结果 → …. 直到任务完成或需要用户新的输入。
这不利于模型进行多轮长链路的推理,于是 claude 4 sonnet 提出把 thinking 内容带入上下文这个事内化到模型,以提升 Agent 性能,上下文的组织变成了这样:

就这样一个事,称为 Interleaved Thinking,其他的叫法也都是一样的原理。
为什么要带 thinking
面向 Chatbot 的模型,倾向于一次性解决问题,尽量在一次 thinking 一次输出解决问题。
Agent 相反,倾向于多步不断跟环境( tool 和 user )交互解决问题。
Agent 解决一个复杂问题可能要长达几十轮工具调用,如果模型对每次调用工具的思考内容都抛弃,只留下结果,模型每次都要重新思考每一轮为什么要调这个工具,接下来应该调什么工具。这里每一次的重新思考如果跟原来的思考推理有偏移,最终的结果就会有很大的出入和不稳定,这种偏移在多轮下几乎一定会发生。
如果每一轮调用的思考内容都放回上下文里,每次为什么调工具的推理逻辑上下文都有,思维链完整,就大大减少了模型对整个规划的理解难度和对下一步的调用计划的偏差。
有没有带 thinking 内容,对效果有多大差别?MiniMax-M2 提供了他们的数据,在像 Tau 这种机票预订和电商零售场景的任务 benchmark 提升非常明显,这类任务我理解需要操作的步数更多(比如搜索机票→筛选过滤→看详情→下单→支付),模型在每一步对齐前面的思路很重要,同一个工具调用可能的理由随机性更大,每一步的思考逻辑带上后更稳定。

工程也能做?
这么一个简单的事,不用模型支持,直接工程上拼一下给模型是不是也一样?比如手动把思考内容包在一个标签(<think>)里,伪装成 User Message 或 ToolResult 的一部分放在里面,也能达到保留思考的效果。
很多人应该这样做过,但跟模型原生支持还是有较大差别。
工程手动拼接,模型只会认为这部分仍是用户输入,而且模型的训练数据和流程没有这种类型的用户输入和拼接,效果只靠模型通用智能随意发挥。
模型原生支持,训练时就可以针对这样规范的上下文训练,有标注大量的包含思考过程的 trajectory 轨迹数据训练,响应的稳定性必然会提升,这也是 Agent 模型的重点优化点之一。
签名
上述工具调用的 thinking 内容带到下一轮上下文,不同的模型做了不同额外的处理,主要是加了不同程度的签名,有两种:
thinking 内容原文,带签名校验
claude 和 gemini 都为 thinking 的内容加了签名校验,带到下一轮时,模型会前置判断思考内容有没有被篡改。
为什么要防 thinking 内容被篡改?毕竟 prompt 也可以随便改,同样是上下文的 thinking 内容改下也没什么。
主要应该是篡改了模型的 thinking 内容会打乱模型的思路,让效果变差,这也是需要避免的。
另外模型在训练和对齐时,已经默认 thinking 是模型自己的输出,不是用户随意的输入,这是两个不同类型的数据,如果实际使用时变成跟Prompt一样可随意篡改,可能有未知的安全问题。
不过国内模型目前没看到有加这个签名校验的。
thinking 内容加密
claude 在一些情况下不会输出自然语言的 thinking 内容,而是包在redacted_thinking里,是一串加密后的数据。
而 gemini 2.5/3.0 的 Agent 思维链没有明文的 thinking 字段,而是 thought_signature,也是一串加密后的数据。
用这种加密的非自然语言数据,一个好处是,它可以是对模型内部更友好、压缩率更大的数据表述方式,也可以在一些涉及安审的场景下内容不泄露给用户。
更重要的还是防泄漏,这就跟最开始 GPT o1 不输出所有思考内容一样,主要是为了不暴露思考过程,模型发布后不会太轻易被蒸馏。
最后
目前 claude 4 sonnet、gemini 3 在 Agent 工具调用的场景下,都强制要求带工具调用的思考内容和签名,这个链路正常是能很大程度提升整体的推理执行效果,是 Agent 多步骤推理的必需品。
但目前 Agent 模型的稳定性还是个问题,例如在某些场景下,业务逻辑明确需要下一步应该调工具 A,但模型思考后可能就是会概率性的调工具B,在以前是可以直接 hack 替换调工具调用,或手动插入其他工具调用,没有副作用。
但在思维链这套机制下比较麻烦,因为没法替模型输出这个工具调用的思考内容,一旦打破这个链,对后续推理的效果和稳定性都会有影响。
可能模型厂商后续可以出个允许上层纠错的机制,例如可以在某个实际告诉函数工具选择错误,重新思考,原生支持,弥补模型难以保障稳定的不足。
02-📝物联网组网 | 数据传输基础-进制基础知识详解
03-📝物联网组网 | 蓝牙通信: 经典蓝牙与低功耗Ble通信、iBeacon技术
深入理解 Swift Concurrency:从 async/await 到隔离域
1月10日用户隐私保护新规出炉,政策解读
2026年1月10日,国家互联网信息办公室发布了《互联网应用程序个人信息收集使用规定(征求意见稿)》,进一步优化了个人隐私保护法案内容。
政策原文:mp.weixin.qq.com/s/epF6mh-Oc…
一句话总结:这次的新政细化了隐私合规规则,堵住了一些规则漏洞,进一步保护用户隐私。对于大部分开展正规业务的开发者来说,无需特别的改动。后续可按渠道平台(华为、小米等)要求,做进一步调整。
内容概览:
1、明确禁止“无关场景调用相机/麦克风”,直击“偷听偷拍”乱象。——旧规:仅原则性要求“不得超范围收集”,但未明确哪些行为算违规。
2、位置权限分级管理:区分“实时定位”与“单次定位” ——旧规:仅笼统要求“最小必要”。
3、进一步强化了不允许获取用户全部相册权限,必须使用系统系框架Android SAF,只能获取用户授权后的部分照片。
4、操作系统厂商,需提供“精细化授权”选项,如 “仅本次允许”“仅今天允许”。
5、生物识别信息(人脸、指纹等)原则上只能本地存储,不能上传。除非法律允许或用户单独同意。
6、App运营者对第三方SDK负连带审核义务。用户向App提出对SDK的数据权利请求(如删除),App必须转达并督促SDK响应,不能再以“这是第三方SDK行为,与我无关”推责。
7、账号注销流程进一步简化:不得强制用户提供额外身份证明(如手持身份证、学历证明等)。堵住了一些App以“安全验证”为名设置注销门槛的做法。
下面是详细介绍
一、首次 明确禁止“无关场景调用相机/麦克风” —— 直击“偷听偷拍”乱象
- 旧规:仅原则性要求“不得超范围收集”,但未明确哪些行为算违规。
-
新规(第14条):
- 必须“用户主动选择使用拍照、语音、录音录像等功能时”才能调用相机/麦克风;
- 禁止在用户停止使用相关功能后继续调用;
- 禁止在无关场景(如浏览商品页、看新闻)调用音视频权限。
实质变化:这是首次以部门规章形式将“后台静默调用麦克风/摄像头”直接定性为违规。此前企业常以“预加载”“性能优化”为由辩解,今后不再成立。
二、位置权限分级管理:区分“实时定位”与“单次定位”
- 旧规:仅笼统要求“最小必要”。
-
新规(第14条):
- 实时定位类(导航、外卖) → 调用频率必须“限于业务最低频度”;
- 单次定位类(搜索、推荐、广告) → 仅允许调用一次,且需用户进入界面或主动刷新;
- 原则上禁止申请“后台持续获取位置”权限(除非法律另有规定或确需)。
实质变化:终结了“只要用户开了定位,App就可高频后台上报位置”的灰色操作。例如,电商App在首页展示附近门店,只能触发一次定位,不能持续追踪。
三、强制使用系统级存储访问框架(如Android SAF)
-
新规(第14条):
- 用户上传图片/文件时,若系统提供标准存储访问框架(如Android的Storage Access Framework),App 不得再索要“相册”“存储”全权限。
- 即使因文件编辑/备份获得存储权限,也不得访问用户未主动选择的其他文件。
实质变化:推动从“粗放式读取整个相册”转向“按需访问单个文件”,大幅降低隐私泄露面。这要求开发者重构文件上传逻辑。
四、操作系统需提供“精细化授权”选项(开发者需适配)
-
新规(第14条):
- 操作系统在弹窗征得用户同意时,应提供基于时间、频度、精度的授权选项(如“仅本次允许”“仅今天允许”“模糊位置”)。
实质变化:虽然责任在OS厂商,但开发者需确保App能兼容这些细粒度授权(例如用户选择“仅本次允许位置”,下次使用需重新申请)。否则功能将异常。
五、生物识别信息默认本地处理,禁止网络传输
-
新规(第15条):
- 人脸、指纹等生物特征信息,默认应在终端设备本地处理和存储;
-
不得通过网络传输至服务器,除非:
- 法律法规明确允许;或
- 用户单独书面同意(且目的充分必要)。
实质变化:许多App当前将人脸照片上传服务器进行比对(如刷脸登录),今后必须评估是否真有必要。若非必要,必须改为本地验证(如Face ID/指纹API)。
六、SDK责任穿透:App运营者对第三方SDK负连带审核义务
-
新规(第19条):
- App运营者必须审核嵌入的SDK,确保其行为符合公示规则;
- 用户向App提出对SDK的数据权利请求(如删除),App必须转达并督促SDK响应。
实质变化:不能再以“这是第三方SDK行为,与我无关”推责。开发者需建立SDK准入机制,并保留沟通记录。
七、账号注销流程进一步简化(禁止设置障碍)
-
新规(第18条):
- 注销后15个工作日内必须删除或匿名化数据;
- 不得强制用户提供额外身份证明(如手持身份证、学历证明等);
- 若使用统一账号体系(如微信/QQ登录),必须支持单App注销,不影响其他服务。
实质变化:堵住了一些App以“安全验证”为名设置注销门槛的做法。