我和 AI 一起修电视索尼 CEC 失效排查实录TL;DR电视的 HDMI-CEC 全链路瘫痪根因是某根 HDMI 线把 CEC 总线13 脚拉死导致电视开机时 CEC 初始化失败。而mIsCecAvailable这个标志一旦为 false 就不会自愈所以后续怎么重启、怎么改设置都没用。修复动作只有一个组合拔光所有 HDMI 线 → 重启电视不是待机→ 插回设备。顺序不能反。这篇文章除了讲技术还想讲清楚一件事这整个过程是我和一个 AI 智能体一来一回干完的。它负责敲命令、读 dumpsys、分析日志我负责拔线、看画面、以及在关键时刻纠正它的误判。〇、开场我把 adb 交给了 AI事情很简单家里的 SONY XR-65X91J 接 Apple TV 4K以前电视遥控器切到 HDMI3Apple TV 自动亮遥控器还能直接控制它。某天开始这套流程全废了切到 HDMI3Apple TV 没反应屏幕黑着电视遥控器按下去Apple TV 毫无响应得先摸出 Siri Remote 按一下Apple TV 才醒按以前的习惯这种问题我会自己开终端一条条adb shell试。但那天太晚了我换了种干法——直接把电视的 adb 连接交给 WorkBuddy 里的智能体小智让它自己查。我的开场白只有一句我我的电视的 HDMI3 连接的是 Apple TV分析一下为什么我将信号源切换到 HDMI3 的时候没有唤醒 Apple TV。它回得也很干脆小智我先连电视把 HDMI-CEC 的实际配置和切换 HDMI3 时的日志抓出来再下结论。然后它就开始自己跑命令了。下面整个过程都是真实发生的交互。一、第一回合AI 交上来的体检报告它做的第一件事不是猜是分层取证——先查 settings 三层再查服务再查 dumpsys 状态机最后翻 logcat。几分钟后它给出的核心结论只有一行mIsCecAvailable: false再往下是设备表mDeviceInfos: CEC: logical_address: 0x00 device_type: 0 ... display_name: TV只有电视自己地址 0x00一个下游设备都没有。以及报文历史CEC message history: [S] time2026-06-05 18:35:46 messageReport Physical Address 0F:84:00:00:00 [S] time2026-06-05 18:35:48 messageDevice Vendor Id 0F:87:08:00:46 [S] time2026-06-05 18:35:54 messageActive Source 0F:82:00:00 ...12 条记录全是[S]Send一条[R]Receive都没有。它给我的解释是小智CEC 是双向总线协议。一条[R]都没有意味着这块电视从来没有成功接收过任何 CEC 报文。这不是Apple TV 没开某个开关能解释的。同时它发现 HAL 层在刷屏E/CEC_HAL: Tx notify NOT coming, Timeout return W/HdmiCecController: Failed to send Active Source 0F:82:00:00 with errorCode2到这里它给了一个初步判断而且是错的小智从首次开机起每条发送就都是errorCode2……这台电视的 CEC 可能一直就没工作过只是你之前没用过这个功能。二、第二回合我的一句话把方向掰回来了它问了我一个关键问题小智顺便问一句你用 Apple TV 遥控器能开关电视或者调电视音量吗如果完全没反应基本就坐实是 CEC 整条链路的问题。我的回答同时也否掉了它前面的推测我能以前用电视遥控器切换到 HDMI3会唤醒 Apple TV然后用电视遥控器也能够控制 Apple TV现在不行了。它立刻改了判断小智这条信息很关键。既然以前能用那说明这不是出厂即坏我收回一直没工作的判断。CEC 硬件是好的现在处于卡死状态。这是整个排查的转折点。如果它继续沿着硬件从来没工作过推下去结论会变成主板故障送修而曾经好过、现在坏了这个前提把方向引向了后来发生了什么变化——这才有了后面的隔离实验。我后来复盘时觉得这是人机协作里最值钱的部分AI 能看到我看不到的数据但它不知道我的生活史。有些信息只存在于人脑里必须由人补给它。三、第三回合AI 自己设计并执行了五次抢救确认是后天失效之后它没有停在分析上而是自己列了一串恢复手段一条条试#手段命令结果1CEC 开关重置cmd hdmi_control cec_setting set hdmi_cec_enabled 0→1❌ 无效2ARC 通道重置cmd hdmi_control setarc off→on❌ 无效3重启 CEC HAL 进程kill -9 pid❌Operation not permitted无 root4端口抖动检测10 秒 × 5 次采样❌ 四口状态恒定非接触不良5整机重启adb reboot❌ 无效其中第 1 条实验是它自己想到的而且做得非常聪明23:52:19 setCecSettingIntValue hdmi_cec_enabled 0 ← CEC 已关闭 23:52:20 E/CEC_HAL: Tx notify NOT coming, Timeout ← 照样超时 23:52:22 E/CEC_HAL: Tx notify NOT coming, Timeout ← 照样超时 23:52:24 setCecSettingIntValue hdmi_cec_enabled 1 ← 再打开 23:52:26 E/CEC_HAL: Tx notify NOT coming, Timeout ← 还是超时它的解读是小智CEC 在软件层都关掉了驱动层还在每 2 秒报一次发送超时。这一条就够了——问题与 Android 的 CEC 状态机无关与 BRAVIA Sync 的设置无关是驱动/物理层的持续故障。这是全篇最有说服力的一段证据。我自己想不到这么试一般人的思路是打开看看而它是关掉看看——如果关了还在报错说明报错的根本不是这一层。四、第四回合它给不了手于是给我造了把工具到这一步它已经很明确了问题在物理层而物理层它碰不到。小智软件层能试的全试完了四条路全堵死。剩下的必须动手了。我做了个实时监控让你拔线的瞬间就能看到结果。然后它写了两个脚本扔进项目目录./cec_live.sh# 实时监控每 2 秒一行./cec_probe.sh10# 单次采样输出完整体检报告cec_live.sh的输出长这样23:58:19 -- [重连中] 23:58:22 1 [总线异常] 23:58:24 1 [总线异常]它的原理很简单——把Tx notify NOT coming的出现频率当成 CEC 总线的健康度指标。正常应该是0 次每当 2 秒出现 1 次就说明有东西在拉着总线。这个设计让我不用反复跑命令、翻日志只要看着屏幕拔线就行。这是我觉得 AI 在这类任务里最实用的能力它能把你去做物理动作我盯着数据这种配合变成现实。五、第五回合我拔线它看数据我按它说的把四根 HDMI 线全拔了然后截了张监控图发过去。00:01:02 [总线异常] ... 00:02:12 [总线异常] 00:02:14 [总线正常] ← 从这里开始一次超时都没有了 ... 00:03:01 [总线正常]它的反应小智这个结果很关键四根线全拔掉后 TX 超时在同一瞬归零了。说明电视的 CEC 控制器本身没坏问题出在外部。它还注意到一个我没在意的细节小智注意那个70 秒的延迟——拔线之后不是立刻恢复而是过了一分多钟才彻底安静。说明 CEC 控制器需要重新检测 HPD 状态、重新初始化才能脱离异常态。这句话后来成了修复方案的关键。六、第六回合为什么之前那次重启没用在等我的过程中它自己去重启了一次电视adb reboot然后查状态——还是坏的。它当时的解释小智mIsCecAvailable是开机时一次性判定的一旦变成 false 就不会自愈只有重启才能重新初始化。之前那次重启时线还插着、总线还是坏的所以重启后照样失败。必须先拔线、再重启顺序反了就是白折腾。这个因果链一说通整件事就闭环了某根线把 CEC 总线拉死 ↓ 电视开机时 CEC 初始化失败 → mIsCecAvailable false ↓ 这个标志不会自愈只有重启有机会翻盘 ↓ 重启的那一刻如果总线还是坏的 → 依然失败 ↓ 所以必须先拔线制造干净环境再重启它甚至主动承认了这个顺序问题小智这也是我一开始没让你先拔线就重启的原因——当时我还没排除是电视本身坏了。七、第七回合验证四根线全拔 重启之后我按它的要求只插回 Apple TV 那一根。它一查电视立刻识别到了mDeviceInfos: CEC: logical_address: 0x04 device_type: 4 cec_version: 5 vendor_id: 4346 display_name: Apple TV physical_address: 0x3000 port_id: 3logical_address 0x04→ Playback Device 1vendor_id 43460x10FA→ Apple Inc.physical_address 0x3000→ HDMI3它自己的评价是小智vendor_id 4346、physical_address 0x3000、device_type 4——它是一个完整、合法的 CEC 设备被电视正常纳管了。然后它直接发了个 intent 切到 HDMI3抓下了修复后的完整握手00:08:55 [S] Give Device Power Status 04:8F ← 问 Apple TV 状态 00:08:55 [R] Report Power Status 40:90:00 ← 答我开着 00:08:56 [S] Set Stream Path 0F:86:30:00 ← ★ 关键报文之前根本发不出去 00:08:56 [R] Image View On 40:04 ← Apple TV收到醒了 00:08:56 [R] Active Source 4F:82:30:00 ← Apple TV我接管画面 mActiveSource: (0x04, 0x3000) ← Apple TV 是当前活跃源 mActiveRoutingPath: 0x3000 ← 路由锁定 HDMI3一步不缺教科书级的 One Touch Play。八、被忽略的技术细节Routing Change和Set Stream Path不是一回事报告里有一段我觉得最值得单独拎出来的分析——为什么设备表为空的时候切信号源更不容易唤醒设备。它抓到了故障期间切 HDMI3 的轨迹23:43:52.995 TIS_HdmiControlHelper: portSelect() id: 3 23:43:53.006 HdmiControlService: portSelect: portId: 3 23:43:54.001 addAndStartAction RoutingControlAction 23:43:54 [S]: Routing Change 0F:80:00:00:30:00 ← 只发了这一条 23:43:56.003 removeAction: RoutingControlAction ← 2 秒后放弃两条报文的区别是致命的报文Opcode语义能唤醒设备吗Routing Change0x80“我的路由要变了通知你们一声”❌ 只是告知Set Stream Path0x86“我要显示 3.0.0.0 的画面”✅ One Touch Play 的触发点原因在HdmiControlService的逻辑目标地址上的设备已知就发Set Stream Path精准投递未知就只能广播Routing Change让设备自己宣告。而故障期间设备表本来就是空的。所以形成了双重故障CEC 物理层发不出报文即使发得出发的也是通知而不是唤醒指令这一点在中文资料里几乎查不到是它逐行对比修复前后的日志才发现的。九、复盘人机怎么分工才高效这件事做完我认真想了想这种协作的边界在哪。AI 做得好、人做不了的部分能力具体表现批量取证十几分钟内跑了上百条 adb 命令翻了 setting/secure/global 三层、包列表、dumpsys、logcat 全量交叉验证从设备表为空和零条[R]两个独立证据推出同一个结论反向实验设计主动把 CEC 关掉用关了还报错来证明问题不在这一层自己造工具发现需要人配合做物理动作当场写了监控脚本不漏细节从一堆日志里挑出 70 秒延迟、errorCode2、mConfigs变空这些线索不嫌烦凌晨一点反复采样、反复对比没有差不多就这样吧只有人能做的部分能力为什么 AI 不行拔线 / 插线物理世界没有 API补充生活史以前能用这句话决定了整个排查方向AI 无从得知质疑结论它说可能一直没工作过我一句以前能用就把它掰回来了看画面“切过去了但黑屏和切过去了有画面”只能人眼判断量电压万用表是它碰不到的东西AI 在这件事里犯的两个错写出来才有参考价值过早下结论看到首次开机就失败就推断从没工作过。它缺的是时间维度的信息用户的使用史这个必须人补。顺序搞错先提议重启、后提出拔线。虽然它后来自己纠正了“必须先拔线再重启”但这个顺序问题导致了中间一次无效尝试白等了 45 秒。规律是AI 在信息完备的确定性推理上极强在信息缺失时该不该下结论上容易冒进。十、技术总结三条能省下几小时的经验1.mIsCecAvailable不会自愈这个字段在HdmiControlService初始化时一次性判定一旦为 false后续无论开关 CEC、改设置、切输入都不会翻回来。唯一出路是重新初始化也就是重启。看到mIsCecAvailable: false别浪费时间调设置。2. 必须先拔线再重启顺序反了等于白做。开着机的设备状态是坏的快照重启会把这个快照固化下来。推广一下任何开机自检 状态锁死型故障都要先制造干净环境再重启。3.cable_connection_status字段不可信排查中一度被它误导明明线拔了还是显示cable_connection_status1已连接。可靠的判断依据是mConfigs数组mConfigs: [] ← 没信号 mConfigs: [TvStreamConfig {mStreamId0;...}] ← 有信号前者是缓存值只在特定事件刷新后者反映真实的流配置状态。十一、附排查命令速查# 1. CEC 总体状态先看这个adb shell dumpsys hdmi_control|head-5# 2. CEC 设备表有没有识别到下游设备adb shell dumpsys hdmi_control|sed-n/mDeviceInfos:/,/mCecController/p# 3. 报文历史[S] 发送 / [R] 接收重点看有没有 [R]adb shell dumpsys hdmi_control|sed-n/CEC message history/,/mCec/p# 4. 发送失败日志adb shell logcat-d|grepFailed to send# 5. 物理层超时CEC 总线健康度核心指标adb shell logcat-d|grep-cTx notify NOT coming# 6. HDMI 端口真实状态看 mConfigs别看 cable_connection_statusadb shell dumpsys tv_input|grepTvInputHardwareInfo|grephdmi# 7. 切换输入时抓 CEC 报文adb shell logcat-c# ...在电视上切到目标输入...adb shell logcat-d|grep-EHdmiCecController|portSelect健康基线指标正常值故障值Tx notify NOT coming0 次/分钟每 2 秒 1 次Failed to send0每条报文都失败[R]接收记录有零mDeviceInfos含下游设备只有 TV 自己mIsCecAvailabletruefalse需重启恢复十二、后记这次真正花时间的不是找答案而是证伪——把Apple TV 设置问题“固件 bug”主板硬件故障一个个排除掉。而排除的过程是人和 AI 交替推进的它挖数据我提供它拿不到的事实它试软件手段我做物理动作它下结论我负责质疑它写工具我负责用最有价值的两个技术动作也正好一人一半看[R]记录AI 发现——一条接收都没有比任何猜测都硬。隔离变量拔光所有线人执行——有时候拔掉一切比任何高级命令都有效。至于到底是哪根线的问题目前还没定论HDMI2 上还有一台设备没插回去可能是它也可能只是某次插拔导致 13 脚接触劣化、重新插拔就恢复了。这类故障有复发风险先把流程记下来下次直接照做。 我和 AI 一起修电视：索尼 CEC 失效排查实录
我和 AI 一起修电视索尼 CEC 失效排查实录TL;DR电视的 HDMI-CEC 全链路瘫痪根因是某根 HDMI 线把 CEC 总线13 脚拉死导致电视开机时 CEC 初始化失败。而mIsCecAvailable这个标志一旦为 false 就不会自愈所以后续怎么重启、怎么改设置都没用。修复动作只有一个组合拔光所有 HDMI 线 → 重启电视不是待机→ 插回设备。顺序不能反。这篇文章除了讲技术还想讲清楚一件事这整个过程是我和一个 AI 智能体一来一回干完的。它负责敲命令、读 dumpsys、分析日志我负责拔线、看画面、以及在关键时刻纠正它的误判。〇、开场我把 adb 交给了 AI事情很简单家里的 SONY XR-65X91J 接 Apple TV 4K以前电视遥控器切到 HDMI3Apple TV 自动亮遥控器还能直接控制它。某天开始这套流程全废了切到 HDMI3Apple TV 没反应屏幕黑着电视遥控器按下去Apple TV 毫无响应得先摸出 Siri Remote 按一下Apple TV 才醒按以前的习惯这种问题我会自己开终端一条条adb shell试。但那天太晚了我换了种干法——直接把电视的 adb 连接交给 WorkBuddy 里的智能体小智让它自己查。我的开场白只有一句我我的电视的 HDMI3 连接的是 Apple TV分析一下为什么我将信号源切换到 HDMI3 的时候没有唤醒 Apple TV。它回得也很干脆小智我先连电视把 HDMI-CEC 的实际配置和切换 HDMI3 时的日志抓出来再下结论。然后它就开始自己跑命令了。下面整个过程都是真实发生的交互。一、第一回合AI 交上来的体检报告它做的第一件事不是猜是分层取证——先查 settings 三层再查服务再查 dumpsys 状态机最后翻 logcat。几分钟后它给出的核心结论只有一行mIsCecAvailable: false再往下是设备表mDeviceInfos: CEC: logical_address: 0x00 device_type: 0 ... display_name: TV只有电视自己地址 0x00一个下游设备都没有。以及报文历史CEC message history: [S] time2026-06-05 18:35:46 messageReport Physical Address 0F:84:00:00:00 [S] time2026-06-05 18:35:48 messageDevice Vendor Id 0F:87:08:00:46 [S] time2026-06-05 18:35:54 messageActive Source 0F:82:00:00 ...12 条记录全是[S]Send一条[R]Receive都没有。它给我的解释是小智CEC 是双向总线协议。一条[R]都没有意味着这块电视从来没有成功接收过任何 CEC 报文。这不是Apple TV 没开某个开关能解释的。同时它发现 HAL 层在刷屏E/CEC_HAL: Tx notify NOT coming, Timeout return W/HdmiCecController: Failed to send Active Source 0F:82:00:00 with errorCode2到这里它给了一个初步判断而且是错的小智从首次开机起每条发送就都是errorCode2……这台电视的 CEC 可能一直就没工作过只是你之前没用过这个功能。二、第二回合我的一句话把方向掰回来了它问了我一个关键问题小智顺便问一句你用 Apple TV 遥控器能开关电视或者调电视音量吗如果完全没反应基本就坐实是 CEC 整条链路的问题。我的回答同时也否掉了它前面的推测我能以前用电视遥控器切换到 HDMI3会唤醒 Apple TV然后用电视遥控器也能够控制 Apple TV现在不行了。它立刻改了判断小智这条信息很关键。既然以前能用那说明这不是出厂即坏我收回一直没工作的判断。CEC 硬件是好的现在处于卡死状态。这是整个排查的转折点。如果它继续沿着硬件从来没工作过推下去结论会变成主板故障送修而曾经好过、现在坏了这个前提把方向引向了后来发生了什么变化——这才有了后面的隔离实验。我后来复盘时觉得这是人机协作里最值钱的部分AI 能看到我看不到的数据但它不知道我的生活史。有些信息只存在于人脑里必须由人补给它。三、第三回合AI 自己设计并执行了五次抢救确认是后天失效之后它没有停在分析上而是自己列了一串恢复手段一条条试#手段命令结果1CEC 开关重置cmd hdmi_control cec_setting set hdmi_cec_enabled 0→1❌ 无效2ARC 通道重置cmd hdmi_control setarc off→on❌ 无效3重启 CEC HAL 进程kill -9 pid❌Operation not permitted无 root4端口抖动检测10 秒 × 5 次采样❌ 四口状态恒定非接触不良5整机重启adb reboot❌ 无效其中第 1 条实验是它自己想到的而且做得非常聪明23:52:19 setCecSettingIntValue hdmi_cec_enabled 0 ← CEC 已关闭 23:52:20 E/CEC_HAL: Tx notify NOT coming, Timeout ← 照样超时 23:52:22 E/CEC_HAL: Tx notify NOT coming, Timeout ← 照样超时 23:52:24 setCecSettingIntValue hdmi_cec_enabled 1 ← 再打开 23:52:26 E/CEC_HAL: Tx notify NOT coming, Timeout ← 还是超时它的解读是小智CEC 在软件层都关掉了驱动层还在每 2 秒报一次发送超时。这一条就够了——问题与 Android 的 CEC 状态机无关与 BRAVIA Sync 的设置无关是驱动/物理层的持续故障。这是全篇最有说服力的一段证据。我自己想不到这么试一般人的思路是打开看看而它是关掉看看——如果关了还在报错说明报错的根本不是这一层。四、第四回合它给不了手于是给我造了把工具到这一步它已经很明确了问题在物理层而物理层它碰不到。小智软件层能试的全试完了四条路全堵死。剩下的必须动手了。我做了个实时监控让你拔线的瞬间就能看到结果。然后它写了两个脚本扔进项目目录./cec_live.sh# 实时监控每 2 秒一行./cec_probe.sh10# 单次采样输出完整体检报告cec_live.sh的输出长这样23:58:19 -- [重连中] 23:58:22 1 [总线异常] 23:58:24 1 [总线异常]它的原理很简单——把Tx notify NOT coming的出现频率当成 CEC 总线的健康度指标。正常应该是0 次每当 2 秒出现 1 次就说明有东西在拉着总线。这个设计让我不用反复跑命令、翻日志只要看着屏幕拔线就行。这是我觉得 AI 在这类任务里最实用的能力它能把你去做物理动作我盯着数据这种配合变成现实。五、第五回合我拔线它看数据我按它说的把四根 HDMI 线全拔了然后截了张监控图发过去。00:01:02 [总线异常] ... 00:02:12 [总线异常] 00:02:14 [总线正常] ← 从这里开始一次超时都没有了 ... 00:03:01 [总线正常]它的反应小智这个结果很关键四根线全拔掉后 TX 超时在同一瞬归零了。说明电视的 CEC 控制器本身没坏问题出在外部。它还注意到一个我没在意的细节小智注意那个70 秒的延迟——拔线之后不是立刻恢复而是过了一分多钟才彻底安静。说明 CEC 控制器需要重新检测 HPD 状态、重新初始化才能脱离异常态。这句话后来成了修复方案的关键。六、第六回合为什么之前那次重启没用在等我的过程中它自己去重启了一次电视adb reboot然后查状态——还是坏的。它当时的解释小智mIsCecAvailable是开机时一次性判定的一旦变成 false 就不会自愈只有重启才能重新初始化。之前那次重启时线还插着、总线还是坏的所以重启后照样失败。必须先拔线、再重启顺序反了就是白折腾。这个因果链一说通整件事就闭环了某根线把 CEC 总线拉死 ↓ 电视开机时 CEC 初始化失败 → mIsCecAvailable false ↓ 这个标志不会自愈只有重启有机会翻盘 ↓ 重启的那一刻如果总线还是坏的 → 依然失败 ↓ 所以必须先拔线制造干净环境再重启它甚至主动承认了这个顺序问题小智这也是我一开始没让你先拔线就重启的原因——当时我还没排除是电视本身坏了。七、第七回合验证四根线全拔 重启之后我按它的要求只插回 Apple TV 那一根。它一查电视立刻识别到了mDeviceInfos: CEC: logical_address: 0x04 device_type: 4 cec_version: 5 vendor_id: 4346 display_name: Apple TV physical_address: 0x3000 port_id: 3logical_address 0x04→ Playback Device 1vendor_id 43460x10FA→ Apple Inc.physical_address 0x3000→ HDMI3它自己的评价是小智vendor_id 4346、physical_address 0x3000、device_type 4——它是一个完整、合法的 CEC 设备被电视正常纳管了。然后它直接发了个 intent 切到 HDMI3抓下了修复后的完整握手00:08:55 [S] Give Device Power Status 04:8F ← 问 Apple TV 状态 00:08:55 [R] Report Power Status 40:90:00 ← 答我开着 00:08:56 [S] Set Stream Path 0F:86:30:00 ← ★ 关键报文之前根本发不出去 00:08:56 [R] Image View On 40:04 ← Apple TV收到醒了 00:08:56 [R] Active Source 4F:82:30:00 ← Apple TV我接管画面 mActiveSource: (0x04, 0x3000) ← Apple TV 是当前活跃源 mActiveRoutingPath: 0x3000 ← 路由锁定 HDMI3一步不缺教科书级的 One Touch Play。八、被忽略的技术细节Routing Change和Set Stream Path不是一回事报告里有一段我觉得最值得单独拎出来的分析——为什么设备表为空的时候切信号源更不容易唤醒设备。它抓到了故障期间切 HDMI3 的轨迹23:43:52.995 TIS_HdmiControlHelper: portSelect() id: 3 23:43:53.006 HdmiControlService: portSelect: portId: 3 23:43:54.001 addAndStartAction RoutingControlAction 23:43:54 [S]: Routing Change 0F:80:00:00:30:00 ← 只发了这一条 23:43:56.003 removeAction: RoutingControlAction ← 2 秒后放弃两条报文的区别是致命的报文Opcode语义能唤醒设备吗Routing Change0x80“我的路由要变了通知你们一声”❌ 只是告知Set Stream Path0x86“我要显示 3.0.0.0 的画面”✅ One Touch Play 的触发点原因在HdmiControlService的逻辑目标地址上的设备已知就发Set Stream Path精准投递未知就只能广播Routing Change让设备自己宣告。而故障期间设备表本来就是空的。所以形成了双重故障CEC 物理层发不出报文即使发得出发的也是通知而不是唤醒指令这一点在中文资料里几乎查不到是它逐行对比修复前后的日志才发现的。九、复盘人机怎么分工才高效这件事做完我认真想了想这种协作的边界在哪。AI 做得好、人做不了的部分能力具体表现批量取证十几分钟内跑了上百条 adb 命令翻了 setting/secure/global 三层、包列表、dumpsys、logcat 全量交叉验证从设备表为空和零条[R]两个独立证据推出同一个结论反向实验设计主动把 CEC 关掉用关了还报错来证明问题不在这一层自己造工具发现需要人配合做物理动作当场写了监控脚本不漏细节从一堆日志里挑出 70 秒延迟、errorCode2、mConfigs变空这些线索不嫌烦凌晨一点反复采样、反复对比没有差不多就这样吧只有人能做的部分能力为什么 AI 不行拔线 / 插线物理世界没有 API补充生活史以前能用这句话决定了整个排查方向AI 无从得知质疑结论它说可能一直没工作过我一句以前能用就把它掰回来了看画面“切过去了但黑屏和切过去了有画面”只能人眼判断量电压万用表是它碰不到的东西AI 在这件事里犯的两个错写出来才有参考价值过早下结论看到首次开机就失败就推断从没工作过。它缺的是时间维度的信息用户的使用史这个必须人补。顺序搞错先提议重启、后提出拔线。虽然它后来自己纠正了“必须先拔线再重启”但这个顺序问题导致了中间一次无效尝试白等了 45 秒。规律是AI 在信息完备的确定性推理上极强在信息缺失时该不该下结论上容易冒进。十、技术总结三条能省下几小时的经验1.mIsCecAvailable不会自愈这个字段在HdmiControlService初始化时一次性判定一旦为 false后续无论开关 CEC、改设置、切输入都不会翻回来。唯一出路是重新初始化也就是重启。看到mIsCecAvailable: false别浪费时间调设置。2. 必须先拔线再重启顺序反了等于白做。开着机的设备状态是坏的快照重启会把这个快照固化下来。推广一下任何开机自检 状态锁死型故障都要先制造干净环境再重启。3.cable_connection_status字段不可信排查中一度被它误导明明线拔了还是显示cable_connection_status1已连接。可靠的判断依据是mConfigs数组mConfigs: [] ← 没信号 mConfigs: [TvStreamConfig {mStreamId0;...}] ← 有信号前者是缓存值只在特定事件刷新后者反映真实的流配置状态。十一、附排查命令速查# 1. CEC 总体状态先看这个adb shell dumpsys hdmi_control|head-5# 2. CEC 设备表有没有识别到下游设备adb shell dumpsys hdmi_control|sed-n/mDeviceInfos:/,/mCecController/p# 3. 报文历史[S] 发送 / [R] 接收重点看有没有 [R]adb shell dumpsys hdmi_control|sed-n/CEC message history/,/mCec/p# 4. 发送失败日志adb shell logcat-d|grepFailed to send# 5. 物理层超时CEC 总线健康度核心指标adb shell logcat-d|grep-cTx notify NOT coming# 6. HDMI 端口真实状态看 mConfigs别看 cable_connection_statusadb shell dumpsys tv_input|grepTvInputHardwareInfo|grephdmi# 7. 切换输入时抓 CEC 报文adb shell logcat-c# ...在电视上切到目标输入...adb shell logcat-d|grep-EHdmiCecController|portSelect健康基线指标正常值故障值Tx notify NOT coming0 次/分钟每 2 秒 1 次Failed to send0每条报文都失败[R]接收记录有零mDeviceInfos含下游设备只有 TV 自己mIsCecAvailabletruefalse需重启恢复十二、后记这次真正花时间的不是找答案而是证伪——把Apple TV 设置问题“固件 bug”主板硬件故障一个个排除掉。而排除的过程是人和 AI 交替推进的它挖数据我提供它拿不到的事实它试软件手段我做物理动作它下结论我负责质疑它写工具我负责用最有价值的两个技术动作也正好一人一半看[R]记录AI 发现——一条接收都没有比任何猜测都硬。隔离变量拔光所有线人执行——有时候拔掉一切比任何高级命令都有效。至于到底是哪根线的问题目前还没定论HDMI2 上还有一台设备没插回去可能是它也可能只是某次插拔导致 13 脚接触劣化、重新插拔就恢复了。这类故障有复发风险先把流程记下来下次直接照做。