写给下一次解锁：记一次在前AI时代的安全研究
当找洞不再稀缺，研究还有意义吗？
开篇
2025年的夏天，在希腊雅典的议题会场，当我演示解锁特斯拉车门的那一瞬间，思绪突然回到了2023年那个夏末的傍晚。
我从北京环球贸易大厦走出来，刚结束KCon的分享，夕阳被玻璃幕墙切成一片片反光，落在手里的手机上。
那时我在朋友圈写过几句话，算是给自己留了个路标：
"我最初做二进制安全研究，习惯用既有的漏洞模式去理解新的代码；但我也隐约不甘心——如果这个方向上很久没有出现足够“新”的攻防范式，那么会不会在无线电这片更荒凉、更冷门的边界上，仍有机会做出一点原创的技术？一路摸索时，我常遇到“这是漏洞吗”的问题，很多漏洞的场景也并不完美，但我也还是被那种从无到有的创造感牵引着往前走。"
过去很多年以来，深耕垂直领域技术一直是安全从业者自我认同的来源，不断学习新技术通常都会有回报。但到了今年，似乎一切都不一样了。在LLM(大语言模型)越来越强的今天，机器已经能系统性地挖掘“已知范式”下的漏洞；漏洞挖掘这件事，越来越像工业化的质检线替代手工抽检——更快、更稳定、也更规模化。我隐约感觉，某种“以找洞证明价值”的旧叙事正在进入倒计时。我不得不去想：当“找洞”不再稀缺，一些以模式化挖掘为主的工作，会被自动化逐步吞掉；而剩下更难的部分，会把安全研究者推向更底层、更跨学科的边界。作为安全从业者，我们还能把学习投向哪里，才算是在追逐真正有价值的东西？我当时也说不清，只听到风从帕特农神庙的石柱间穿过，像一句尚未写完的判词。
散场后我走出会场，夜风从山坡上吹下来。那天夜里，雅典卫城在远处亮着。帕特农神庙正在维修，脚手架和防护网把它的轮廓切得断断续续，但它依旧稳稳地立在山脊上，俯视着城里的车灯与人声。
背景：一切的出发点
我最早关注 Tesla 破解这件事，是在 2022 年看到 NCC Group 在油管上的一个视频。视频讲的核心仍然是“中继”——一个并不新鲜的攻击思路：针对信用卡、乘车卡的 NFC 中继、433/315MHz 射频钥匙中继、电动汽车的蓝牙钥匙中继，过去几年早就被反复讨论，几乎是无线电攻防里最常见的范式之一。按理说，这类题材很容易被认为是“新瓶旧酒”，但那段时间我反复看完后的感受恰好相反：同样是中继，NCC Group 依然能做出新的突破，说明中继攻击的故事还没有结束。
这是一张中继攻击的原理图，针对的场景是汽车无钥匙进入功能，车主靠近汽车就行解锁汽车或者启动汽车，这种攻击通俗一些讲，就是通过网络延长钥匙信号，使车辆误以为钥匙在近处。
这件事真正吸引我的点，也不只是“解锁一台车”的结果，而是它背后隐含的问题：在无线电这样的冷门，是否是发现全新原创性的技术的土壤。Tesla 过去在钥匙链路上做过多轮修补，尤其是对时延的限制，在我观察到的部分实现里，业务侧对时延更敏感，使得一些纯应用层中继更难稳定奏效——这也把视线推向更底层的链路。
后来我和同事沿着视频里的线索继续追，第一次看到 NCC 的 Sniffle 项目时也很受触动：它并不是临时起意发现的漏洞，而是一个迭代超过六年的工具链。我们当时为了确认他们使用的硬件，反复回放视频细节，同事大林眼尖首先定位到 TI CC2652RB 开发套件，再顺藤摸瓜找到项目本体，白总(Bacde)二话不说直接下单，海外邮寄过来需要好几周。对我来说，那一刻相当于找到了起点：工具、硬件、资料入口都清晰了，帮我坚定了接手这个 OKR 的信心，这是后面所有故事的起点。
从零开始的学习与摸索
BLE链路层中继攻击是一个技术难度很高的目标，BLE（低功耗蓝牙技术）不同于 Wi-Fi 的固定信道，BLE 包含 37 个信道，每一毫秒都会在上面根据跳频算法(#1/#2)进行切换，让嗅探器难以捉摸。并且 BLE 经过多年发展，诞生了 SMP 层用于实现配对/密钥协商，对数据报文进行了加密。进一步提高了门槛。这对所有 BLE 底层的研究者来说都是挑战。
图：BLE通信会不断的跳频
从二进制安全转到无线电，我很快意识到自己带着一套熟悉的方法论，却面对着另一套完全不同的直觉。做二进制时，我有一套流程化的工具和方法论：反汇编、调试器、内存布局、调用栈，很多东西是能被“看”到的。但在 BLE 这里，最先拦住我的不是协议的复杂，而是“工具链”——报文在空中的时序是怎么样的、如何被确认与重传，连接或者断开的表现是什么，这些关键行为我没有条件获取。
大部分常见的蓝牙开发板，比如 nRF52、TI CC系列，默认只提供到 L2CAP 甚至更上层的接口：你写应用层调GATT、收发特征值，体验很好，但代价是底层细节被封装得很干净，大多掌握在芯片厂商手里——要么是闭源协议栈。多年以后才有第三方的安全项目（比如 SweynTooth）把更底层的接口做了出来。所以当我第一次认真思考“链路层中继到底有什么价值”时，我其实是缺乏直观印象的：链路层不像应用层那样直观，它是一套精确的系统，光靠想象很容易把自己带偏。
图：蓝牙协议栈和CONNECT_IND报文
「2021 住院期间」
我其实并不是完全没做功课。2021 年因一点小病住院的两周里，疫情让病房格外安静，我把蓝牙 5.3 核心手册里 BLE 相关的部分从头到尾读了一遍：协议层功能、PDU构成、字段含义，我都能说出个大概。但当问题变成“为什么必须中继链路层”、“时延检查到底在哪里”，那种理解就显得很苍白。
更麻烦的是，无线电安全本身冷门资料也少，再加上我并非通信专业出身，对射频没有基础：调制解调、采样率这些词我都认识，但谈不上真正理解。我当时甚至会被一些反直觉的事实卡住：为什么有人用树莓派的金属引脚就能发射无线电波？物理层、链路层这些概念，在工程上到底对应什么？目标很大、工具很少，那段时间我确实有过一阵无从下手的挫败感。
后来我做了一个看起来有点“笨”的选择，不懂那就自己造。我开始用 HackRF 做小实验，尝试从零实现一个极简的 BLE接收链路，逼着自己把“手册上的流程”变成“能跑起来的东西”。
于是就有了开源项目BTLE-R。它当然不完整：时间仓促，我只实现了广播接收；发送功能因为 Python性能限制，效果很一般，更合理的方式还是固件化。但对我来说，这已经够了——当我亲手把调制、解调、跳频这些环节串起来之后，协议栈不再是一张结构图，而变成了可以被感知的过程，这种直觉一旦建立起来，我才真正有底气继续往下走：这条路冷门、门槛高，但并非走不通。
关键技术（上）：最初的误解与方案1为什么会失败
可跳过
段落技术内容较多，快速阅读可跳过，直接阅读后续「国庆前的喜讯 / 外部事件 / 后记」
技术细节
研究一开始，我把方向带偏过一段时间。现在回头看，那个误解其实很“自然”：我把无线电中继的经验、以及网络转发的直觉，直接套进了 BLE。在很多传统无线电场景里，中继的思路很朴素：在一个固定信道上监听，把收到的内容转发到另一端，再由另一端发回响应。你关注的是链路是否通、带宽够不够、噪声和距离够不够；只要你能听到并转发，系统往往就能继续跑下去。
channel 433Mhz
C P_r C_r P
PDU(Adv seed)------>
PDU(Adv seed)----->
PDU(Resp)------>
<--------PDU(Resp)
<--------PDU(Resp)
<-------PDU(Resp)那时候我甚至和同事讨论过一个看似合理的方案：既然 BLE有跳频，那我们就把跳频规律算出来，跟着跳，实时切换频段做中继就行。channelmap、hop 参数并不是不可获得，blejack 之类项目也给过打样。于是就有了我后面称作“方案1”的东西：在两端各放一套设备，分别贴近 victim central 和 victim peripheral，把一侧抓到的链路层数据通过Wi‑Fi/以太网转发到另一侧，再在对应的频点上发回去。为了让这件事成立，我做了两件关键工作：
- 第一，解析跳频相关参数，尝试推导 channel map 和 hop序列；
- 第二，按这个序列实时切换频道，尽量做到“你在 channel 8 上说话，我也在channel 8 上把话转过去；你跳到 channel 25，我也跟着跳”。
victim central (C)
victim peripheral (P)
relay master (C_r)
relay slave (P_r)
channel x(跳频，一次connection事件中不会改变)
channel 8
C P_r C_r P
LL PDU(Encrypted)------>
LL PDU(Encrypted)----->
LL PDU(Encrypted)------>
<--------LL PDU(EncResp)
<--------LL PDU(EncResp)
<-------LL PDU(EncResp)
channel 25
C P_r C_r P
LL PDU(Encrypted)------>
LL PDU(Encrypted)----->
LL PDU(Encrypted)------>
<--------LL PDU(EncResp)
<--------LL PDU(EncResp)
<-------LL PDU(EncResp)从纸面上看，这套方案并不荒唐。BLE 的跳频规律不是玄学，blejack这类项目也早就证明了“跳频可计算、可跟踪”。
我当时真正低估的，是 BLE链路层的另一面：它不是“把包搬过去”就行的通信，而是一个高度参数化、强时序约束的精密连接。WinOffset/WinSize 决定首包窗口，connInterval规定连接事件的节拍（最小 7.5ms 起），peripheralLatency只是允许跳过部分事件但不放宽节奏，supervisionTimeout则像心跳监护仪一样盯着链路有没有“按时活着”；再加上 ChM/Hop/ChSel控制跳频序列。它们共同决定了一个事实：链路层连接对额外延迟极其敏感。
同一个 connInterval内，双方收发有严格的窗口和间隔（例如 T_IFS这种级别的约束），很多实现会在有限次数的重传后迅速判断链路异常。你把链路层PDU 通过 Wi‑Fi/以太网转一次手，单侧延迟动辄就是几毫秒到几十毫秒；对普通网络来说这很正常，但对 BLE 链路层来说，这相当于把“节拍器”直接打乱了。锚点错了，后面的事件就对不上；心跳超了时限，连接就会被迫中断。
正常蓝牙通信的原理图：
如果用一个最直观的例子来解释：正常情况下，C->P 和 P->C 的往返延迟很小，设备距离近，链路在一个连接事件窗口里就能把数据收发完成。但在方案1里，C发出的数据先被 P_r 收到，再经 Wi‑Fi 转给 C_r，再由 C_r 发给真实 P。Wi‑Fi单侧可能就引入 50ms 量级的延迟，而单次连接事件能容纳的数据交换窗口由connInterval、transmit window 等参数共同限定，这些参数又来自 connect_ind，是你无法替用户选择的。
于是就出现了最典型的“错拍”：C->P_r这一步发生时，链路还在 channel 8；等数据绕了一圈准备从 C_r->P 发出去时，原本的连接事件窗口早就过去了，链路可能已经跳到下一次事件，甚至已经因为supervisionTimeout/重传失败进入掉线流程。
方案1中继失败的原理图：
那一刻我才真正明白：BLE 链路层中继难，不难在“频点数量”，而难在“时序与心跳”。也正因为这个失败，我才开始把问题从“怎么把包转过去”改写成“能不能换一种模型，让跨网延迟不再直接击穿链路层的节拍”。我试了很多次，而是我终于能把失败解释清楚，并据此否定了一个看似合理的错误模型。虽然没有直接受益，但是证伪也是一种价值。
关键技术（下）：洞见出现——链路层中继的正确模型
可跳过
段落技术内容较多，快速阅读可跳过，直接阅读后续「国庆前的喜讯 / 外部事件 / 后记」。
技术细节
理解了前面的失败原因之后，项目最后的实现方式其实就顺理成章了。这是一个看起来有一些反直觉的方案：不要试图维持同一条链路跨网同步；在两端各自建立独立的 BLE 链路，用本地时序把连接保持住，跨网只负责搬运需要转交的链路层负载。
具体做法是：在靠近“受害者手机/钥匙”（central）的一侧，我们用一块开发板伪装成“假外设”，先和手机建立一条完整的 BLE连接；在靠近“车辆”（peripheral）的一侧，再用另一块开发板伪装成“假主机”，和车辆建立另一条独立连接。两条连接各自拥有独立的接入地址和校验（Access Address/CRC），互相不需要同步。这样一来，手机和车都只是在和一个“正常对端”通信。
在此基础上，我们只搬运链路层 PDU，不去转发物理层前导、Access Address、CRC 这类与具体连接强绑定的字段。为了保证两条连接不会因为响应而断开，我们在空闲时用空包把每个连接事件填满，按本地节拍持续收发，确保像T_IFS、connInterval、supervisionTimeout 这类约束不被触发；一旦有真实数据需要转发，就用有效的链路层数据包替换掉原本要发的空包。
简单说就是：两端独立建链 +Empty PDU 占坑 + 只转 LL PDU报文。
这是后来ncc在2025公开的通信逻辑，我当时的想法与NCC Group殊途同归。
First, the relay master (C_r) gathers the adverisement body and scan response
from the victim peripheral (P). Next, the advertisement data is passed onto
the relay slave (P_r) to mimic the victim peripheral. Once the victim
central (C) connects to the relay slave (P_r) mimicking the victim peripheral,
the relay slave will inform the relay master, so that it can start its own
connection to the real victim peripheral with potentially different parameters.
C P_r C_r P
<----------Advert
ScanReq--------->
<---------ScanRsp
<---------Advert
<--------ScanRsp
<---------Advert
ScanReq-------->
<--------ScanRsp
ConnReq-------->
(I starts channel hopping with P_r)
ConnReq-------->
(wait for next advert)
<----------Advert
ConnReq--------->
Once connected, data can be encrypted, but we don't care, we just pass it on.
One limitation is that encrypted LL_CONTROL messages could change hopping
parameters, but we can't decipher them. It may be possible to make an educated
guess of what the control messages are though based on past behaviour.
C P_r C_r P
Encrypted------>
<----------Empty
Encrypted----->
Encrypted------>
<--------EncResp
<--------EncResp
(wait for next conn event)
Empty--------->
<-------EncResp
"""总结下来有几个关键技术点：
第一，两端各自维护独立的链路层连接，分别按各自协商得到的 Channel Map / Hop / ChSel 进行跳频，不需要做“四端同步”，也不需要在两条连接之间对齐频跳序列。
第二，跨网链路只承载链路层负载的转运，不参与链路层实时握手；通过在本地连接事件中用 Empty PDU 维持时序与心跳，TCP/IP 往返无需落在对端的 T_IFS 或 connInterval窗口内，跨网延迟只会影响负载被注入的连接事件时刻，不会触发链路层超时判定。
第三，在多数数据负载层面，SMP 加密不妨碍‘密文透传’：加密后的数据以密文形式封装在链路层数据负载中，中继端只需透明转发密文，无需解密、无需理解或改写上层语义。
而相对普通 GATT 层中继，链路层中继的优势在于：它把跨网延迟从“端到端链路时序”里剥离掉——两端各自维持独立的链路层连接，用 Empty PDU 保持connInterval/T_IFS/supervisionTimeout的节拍，因此不容易被简单的时延检测打断；同时它转发的是链路层报文，SMP加密后的密文也能直接透传，不需要在中继端解密/理解应用层语义。
理解模型之后，真正难的反而变成了工程细节。理论上“空包占坑”一句话就能讲完，落到实现里却全是细碎的坑：空包怎么发才不引发异常，哪些包必须中继、哪些包必须丢掉；丢错了怎么判断、怎么恢复；连接为什么会莫名其妙不稳定。那段时间我一开始拿手环和手机做测试，工区两头来回跑，盯着到底是广播没收到，还是连接又断了，效率很低，人也被消耗得很快。后来我才意识到，很多验证根本不需要把两台设备拉到蓝牙范围外——把设备放在一起也没问题，只要看日志、看时间差，就能判断这个模型到底在不在工作，测试周期一下子就被压进了可控范围。
工程细节也并不容易，这就是为什么我一直对ncc group的研究精神感到敬佩，因为你要解决的不是一个问题，而是面对一个看不到的终点，每一种思路背后都要解决冒出来的更多问题。
国庆前的喜讯
「2022 国庆前」
最后的临门一脚发生在老板来北京出差的那一周。我们把最后的工程问题逐个打解决：空包连接稳定下来，不该转的包也能识别并处理，整体链路终于能够对加密的链路实现“长时间”的中继，它当然不可能像真实直连那样稳，偶尔也会抽风、也会断开连接，但是BLE认证解锁车门到启动汽车，其实也就几分钟以内。
最后，在多次沟通、几次被拒绝之后，终于有同事愿意借我一辆 Tesla，留出一个下午做测试。那天下午第一次尝试就失败了。我们把链路从头排查了一遍，才发现是车库太暗，我把 MAC 地址写错了。改正之后，同事留在小米科技园室外，我在室内重新走了一遍流程——这一次，车门成功解锁，车辆也顺利启动。看到结果的那一刻，我没有立刻兴奋起来，而是先把日志和链路状态确认一遍，确保这是中继带来的效果，而不是偶然或误判。确认无误后，我才真正接受：攻击成功了。
结果是好的，我们在 2022 年国庆前完成了这个艰巨的任务。项目告一段落，国庆我坐上回家的火车。身体很累，心却异常亢奋——“maybe this is the best day of my life”。如果去问当时的我，我大概会兴奋地聊很多：能不能在黑客历史里留下些什么、能不能对公司的未来产品甚至更多人的现实安全产生价值。我想到了很多可能的未来。 但今天再回头写这段经历，尤其是多年以后再问“它真正留给了我什么”，答案反而更简单：挑战本身的有趣，以及把难题做成之后的成就感。
令人绝望的外部事件
但是在我成功破解没过多久，有一天我们发现知名安全硬核会议hardwear.io 上公开了一个议题，NCC Group 在会议上发布了关于蓝牙链路层中继的演讲。
坦白讲，那一刻对我的冲击很大。NCC在我们对外发布之前，就已经把这类攻击的关键点和一些技术细节公开了。在我眼里，这几乎等于把我几个月踩坑换来的“底稿”摊在了台面上：那些反复试错、慢慢磨出来的结论，突然以一种更权威、更完整的姿态出现了。震撼之后是一阵茫然——一种很直接的失落感：我花了那么多时间做出来的东西，好像一下子就被提前写进了结论里，那一瞬间我甚至会短暂地怀疑：这些细节究竟算不算属于自己的成果？
「2026 回望」
回到 2026 年再看，类似的情绪其实正在以另一种形式重复上演。AI基座模型越来越强，很多过去需要长时间训练和经验积累的技能，现在新手靠 agent + MCP +几行提示词也能快速做到“像样的结果”。那我们曾经投入的研究，会不会就此贬值、甚至变得没有意义？这让我想起当年的处境：你确实把问题跑通了，但别人恰到好处地先公开了一部分，那么你的努力就算白费了吗。
这个问题没有统一答案。
我不想在这里给出“路该怎么走”的结论，只说说我后来逐渐形成的一种观点：现代社会我们太习惯把自己当成一台产出结果的机器，可“人”终究不应该是工具，很难只靠“结果”来定义价值——结果会被更大的结果覆盖，也会被时间抹平。真正属于自己的，是在探索里长出来的理解、经验与判断力。
AI 也许能很快学会你花很久才掌握的技术，但它很难替你经历那些只能由身体和当下承担的瞬间：比如在极棒破解汽车时微微发颤的手，普吉岛修手机、眼看要失联的无措，迪拜四小时转机从哈利法塔往回赶的急切，或是雨后看见彩虹、下意识按下快门的那一下真实感。那些感受只能由你自己抵达，也只会归你所有。
安全研究同样如此。对我而言，最有价值的部分往往是过程：把问题简化、错误纠正、难题解决的快乐。至于最终那颗糖——解锁也好、汽车开走也好——它当然很重要，而不是全部意义的来源。
更现实的一点是：NCC 虽然公开了思路和部分实现，但并没有直接给出可即用的exploit（漏洞利用代码）；而且对不熟 BLE的人来说，即便难度被显著降低，真正跑通仍然需要理解协议、时序和工程细节。后来反而有不少同行来问我链路层相关的问题，有人因为专门跑来KCon听我的分享，也有人在我提示下真的复现成功。那种快乐很具体：不是“首发”的兴奋，而是你确认自己掌握的东西，能够实在的帮到别人——对我来说，这是一种更持久的满足感。
技术分享与议题经历
「2023 KCon」后续我还是投稿了议题。既然暂时没有公开的脚本，而问我的人又越来越多，与其零散回答，不如在会上把来龙去脉讲清楚：讲一次，至少能把误解和关键点都解释清楚。KCon 结束后，我又顺路去了一趟 在泰国普吉岛举办的HITBSecConf，让我印象深刻的不是海岛风情，而是一个很狼狈的小插曲：手机进了海水。人生地不熟、没有备用机，面对着接下来几天要失联的恐慌。后来手机修理处即将被拆机时候突然“自己活了过来”，大概率是之前在酒店用电吹风吹了很久的效果。这和我们研究的过程一样，你以为自己在做的是“研究”，可真正支撑研究继续走下去的，往往是这些琐碎的、临场的、把一切拉回正轨的能力。
「2025 OffensiveX雅典期间」时间瞬间到了三年后的2025 年，OffensiveX会议，我们和同事收到主办方邀请，一起去了希腊雅典做分享。虽然这次讲的是另一个汽车安全议题，和蓝牙中继无关，但主办方依然希望我们做一个现场演示：在欧洲的 Tesla上做一次 “live hacking”。某种意义上，这更像是给蓝牙中继补上的一次正式收尾——我一直没有机会亲手把它展示出来。
但总有意外。意外发生在最不该发生的时候：开发板的 micro USB接口在长途飞行里被压坏了。说到底是我的疏忽——线没拔，二十多个小时的移动和挤压把焊接点弄断了。更糟的是，我们一路还在倒时差处理公司的事，同时要对PPT的一部分内容进行调整以适配我们的现场演示。等前一天彩排结束，已经是傍晚，我们一边要赶去 Lake Vouliagmeni 的湖边晚宴（演讲者和赞助商的活动），一边又必须把板子救回来。我们试过各种方案，骑着滑板车逛遍雅典主城区，最后在路边找到一家修手机的小店，老板是个印度大哥，砍价之后花了点钱把接口补焊好。那晚我们卡着点赶到集合处，才发现晚宴时间临时往后推了——那种“差一点就错过”的紧张感似乎又回来了。
演示当天，我拿着笔记本走到预定的场地，Tesla 就停在路边。摄像师和工作人员已经就位，路过的人看到我们围着车，也纷纷开始停下来围观拍照。真正动手的那几分钟反而很安静 ：确认设备状态、看日志、走流程——当时我心里早就平静如水，不再激动。
但在车门再次解锁的那一刻，掌声从场内外同时涌起来，我突然有一种熟悉的既视感。那种情绪并不完全来自“结果”，更多来自 一种确认：这些年我把注意力不断推向更远的目标，几乎快忘了当初为什么会喜欢做这些事；而这一刻像是把我拉回原点——也许我仍然在那条轨道上，只是走得更远了。
会后现场我收到了很多不同行业的反馈：除了同行 ，也有教育工作者、学生、完全不做安全的人，他们说喜欢这个hacking show，也愿意停下来合影留念。那些具体的目光与握手，让我意识到自己做的事并不只属于一个小圈子——它至少能被听见、被理解。
也正因为如此，我对后来发生的一件小事印象很深。我在推特上收到 poc_crew的私信。他们说在现场看到了我破解 Tesla 的展示，问我是否对韩国本土汽车的研究感兴趣，并希望邀请我作为演讲者。坦白说，我当时并没有准备好一个“顺手就能讲”的新故事，我表达了感谢，但准备议题需要时间。那条消息带来的不是答案，而是一种回声——原来几年前研究的价值并没有随着项目结束而消失，也许它们会在更久以后，以意想不到的方式回到你身上，推动你继续把手伸向下一段未知。
后来我把这次旅行剪成了一个欧洲短片，调色和叙事还有很多要练的地方，但我挺喜欢这个收尾：我给摄影师拍了一张，他也给我拍了一张。一个记录者被记录的瞬间，反而像对这段旅途最干净的注脚。
后记：路在何方？
「2025 年末」
2025 年年末，NCC 终于把他们的中继脚本开源出来。看到代码仓库的那一刻，我反而很平静：这件事从“传闻”、到“论文/演讲”、到“可复现的代码”，终于走完了它该走的生命周期。对我来说，这像一个阶段性的句号。但句号落下之后，另一个更大的背景音也越来越清晰：时代变了。
再美妙的研究体验，终究会面对来自现实的挑战， 如今 AI正把很多“已知范式”做成工业化的质检线，把一些过去需要经验和时间的技能压缩成几行提示词。焦虑也随之而来：当“找洞”不再稀缺，我们过去打磨的能力与方法，还值不值得继续投入？
我越来越确信，答案是“值得”。只是意义的位置变了：工具会替你跑完大量重复的路，却不会替你决定该往哪里开路。
而在 AI 时代继续做研究，让我想起奥德修斯航过塞壬(Siren)出没的海域，海上的妖女，会用歌声引诱航海者。传说听到歌声的人会失去理智，把船驶向暗礁，最终葬身海中。奥德修斯下令让水手把耳朵用蜡封住，并把自己在桅杆上，还要求水手无论他怎么哀求都不要松绑。“听见却不偏航”，总要付出更多的代价。
研究的价值，往往就藏在这部分代价里——尤其是在更贴近现实世界、场景更复杂的系统里：身份与信任链、软件供应链与更新链路、以及协议与设备生态等，AI的误判与盲区仍在，需要人去定义边界、验证模型，并为结论负责。
那天夜里在雅典，卫城的灯一直亮着。帕特农神庙在修，轮廓被脚手架切得断断续续，它仍稳稳地立在山脊上，是二十一世纪的工程机器在上面运转。
（待续）