我手机里常年躺着一张叫“网络电台表”的表格，四列宽，一百多行，最早只是个便签，现在成了一套带校验脚本、有版本记录、能在手机、电脑、车机、智能音箱四类设备上直接跑起来的清单。做这件事的起因很朴素：想听的东西其实一直都有，问题是“找不到、连不上、连上了没声、有声听两分钟就断”。这张表就是为了把这几件事一次性摁死。它适合三类人：一是通勤、开车、做家务时习惯有背景声音的人；二是家里有老人，想把传统收音机换成更清晰、台更多的网络收听方式的人；三是喜欢自己折腾播放列表、订阅源、本地播放器的技术爱好者。下面我把这张表从“为什么这么设计”到“每一列怎么填”“怎么自动巡检”“怎么在车机上别翻车”整套拆开讲，你照着抄就能做出自己的一张。

1. 先想清楚这张表到底要解决什么问题

1.1 从“能听”到“听得下去”中间差了好几层

很多人以为网络电台的难点是“找源”，其实找源是最简单的一步。真正消耗时间的是后面三层：第一层是可用性，一个地址今天能用，下周可能就返回一个 HTML 落地页，播放器打开一片空白；第二层是兼容性，同一条流在你手机上的播放器里丝滑流畅，扔进车机就死活不认，因为车机只吃某几种封装格式；第三层是稳定性，前三十秒正常，第三十一秒断开，原因是服务端限制了并发连接数，或者要求特定的请求头。

我最初做这张表的时候，只记了“名称 + 地址”两列，用了不到两周就废了。因为我根本记不住哪条是好用的、哪条是上次试过不行的、哪条是音质太差只能应急的。后来我把表重构成一份带状态、带格式、带场景标签、带校验时间的结构化清单，才发现维护成本直线下降。这件事的本质不是“收集”，而是“建立一个可自我更新的判断依据”。

所以我给这张表的定位很明确：它不是一份“电台大全”，而是一份个人可用性清单。宁可只有八十条，条条能播，也不要三百条里一半是死的。这个取舍决定了后面所有的设计。

1.2 收录范围与三条硬性筛选标准

收录范围我做了很严格的收口，因为范围一放开，表就会失控。我只收三类：线性直播流（打开就是当前正在播的内容，不能回拖）、可循环的背景音流（环境音、纯音乐、白噪音这类长时间播放的）、结构化的点播音频源（有明确分集或曲目列表的）。播客类的订阅源我单独放一张子表，因为它和直播流的播放逻辑完全不同，混在一起会让字段一团乱。

筛选标准我只留三条，但三条都卡得很死：

第一条是底线，必须说清楚：我只收录公开提供、面向普通听众的收听入口。任何需要绕过限制、破解鉴权、抓取未公开地址的做法，我都不碰，也不建议你碰。原因不只是合规，更实际的是——这类源的生命周期极短，你花两小时搞定的地址，可能三天后就废了，投入产出比极差。

第二条里的“格式通用”是很多人忽略的坑。HLS（就是 .m3u8 结尾的那种清单文件）在手机和电脑上兼容性很好，但大量车机、老式网络音箱、部分电视盒子根本不支持。所以我在表里强制要求：每条记录如果只有 HLS，必须标注“仅手机/电脑”，并且尽量补一条 MP3 直连作为备用。这一条规则救了我无数次。

1.3 三个真实使用场景决定了字段怎么长

我不喜欢为了“完整”而加字段。每个字段都必须对应一个真实场景，否则就是负担。我复盘了自己的使用习惯，归纳出三个高频场景，字段设计完全围绕它们来：

场景一：早上七点，手机闹钟响完，一边洗漱一边听。这个场景要的是“一键打开就有声”，不需要选台、不需要缓冲太久。对应字段是“首选源”“启动延迟”“默认音量”——最后这个字段很多人想不到，不同源的响度差异巨大，有的台一开就是满音量，有的台要开到 80% 才听得清，记下来能避免每天早上被吓一跳。

场景二：开车路上，一小时起步。这个场景要的是“绝对稳定、绝不中断”。对应字段是“车机兼容性”“备用源”“断流记录”。我给每条源都打了车机兼容性标记：直连、可播、不可播。不可播的直接从车机播放列表里排除，眼不见心不烦。

场景三：晚上写东西，需要没有人声的背景音。这个场景要的是“内容属性准确”。对应字段是“内容分类”“是否含人声”“单曲循环友好度”。最后这个字段有点土，但特别实用——有些纯音乐台每半小时插一段口播，你正在专注状态里突然来一段人声，非常出戏。

这三个场景想清楚之后，表格的骨架就定下来了。我很反对一上来就设计二十个字段，那大概率有一半永远不会填。

2. 表格字段设计：能不能长期维护，全看这一层

2.1 核心字段逐个拆解与你该填什么

必填字段我只设了九个，剩下的都是选填。这个比例是刻意控制的——必填项太多，你加新条目的时候会本能地偷懒，最后整张表的字段质量崩掉。

编号：用“类别缩写-序号”的格式，比如mus-001、news-014。为什么不用纯自增数字？因为一旦你删掉中间某条，纯数字编号就得重排，而重排会让所有引用失效（比如你在播放列表里写死了编号做排序）。带前缀的编号删了也不用动别人。

名称：这里我建议你写“可识别的通称”，不要写太长的官方全名。全名往往三四十字，在车机那种小屏幕上根本显示不全。我一般的写法是“类别 + 特征”，比如“古典音乐·无口播”“综合资讯·早间版”。

类型：只有三个值——live（直播流）、loop（循环背景音）、ondemand（点播）。这个字段决定了播放器该怎么处理：live不能拖进度条，ondemand可以，loop一般建议关掉自动重连以外的所有智能逻辑。

内容分类：我用了相对粗的颗粒度，八个大类：综合资讯、音乐（细分古典/流行/器乐）、戏曲曲艺、财经、少儿、科技、有声书、环境音。颗粒度太细会导致每个分类只有一两条，检索反而不方便。

编码格式与码率：这两个要分开写，格式写MP3、AAC、HLS/AAC，码率写实际数值（32/48/64/96/128/192）。不要凭感觉写“高清”“超清”，那玩意没有任何信息量。

协议：HTTP、HTTPS、HLS。这个字段直接决定车机兼容性，因为大量车机对 HTTPS 的支持是有问题的，尤其是老款。我自己遇到过好几条源，HTTP 能播、HTTPS 死活不出声。

首选源 / 备用源：这是整张表里最重要的两个字段。我的规则是：任何一条进入“常用”列表的源，必须至少有一个备用源。没有备用源的条目，我只能放在“试听区”，不进主播放列表。

最近校验时间 / 状态：状态只有四个值——OK、SLOW、FAIL、UNKNOWN。SLOW的定义是首包超过 3 秒或中途出现可感知卡顿。这个粒度足够用，再细分就是给自己找麻烦。

备注：这是最有价值的一列，也是最容易写废的一列。我的经验是，备注只写两种东西：一是“坑”，比如“需特定请求头”“并发连接数受限”“夜间码率会降”；二是“适配提示”，比如“车机可用”“仅移动端”。不写主观评价，什么“音质不错”“很推荐”这类话，三个月后你自己都不知道当时在说什么。

2.2 分类维度别只按内容分，按场景分更好用

这是我在用了半年之后做的一次大改。原来我按内容分类，结果每次想找“开车听的”还得在脑子里过一遍“哪些台是谈话类的”。后来我加了一个场景标签字段，用分号分隔多个标签，情况立刻不一样了。

场景标签我固定了六个：通勤、工作背景、睡前、做饭、带娃、运动。一个人可能同时打三个标签。这个字段的好处是，它允许你按“当下状态”检索，而不是按“内容属性”检索——人的需求从来都是场景驱动的，不是内容驱动的。

码率维度我单独做了一个视图，因为我发现不同网络环境下，最优选择完全不同：

这个换算是：码率（kbps）÷ 8 = 每秒字节数（KB/s），再乘 3600 秒。128 kbps 就是 16 KB/s × 3600 ≈ 57.6 MB。实际会有一点协议开销，所以我一般按上浮 5% 估。别小看这个计算，我最早用 192 kbps 听了一整个月的通勤，月底看到流量单子才反应过来。

2.3 一份可以直接复制的表格模板

下面是我现在用的字段结构，你复制到表格软件里就能直接用。字段名我用了英文，这样导出成 CSV 之后不会被中文逗号搞乱。

id,name,type,category,codec,bitrate_kbps,protocol,primary_url,backup_url,scene_tags,car_ok,last_check,status,note mus-001,古典音乐·无口播,loop,音乐,AAC,128,HTTPS,https://example.com/a.m3u8,https://example.com/a.mp3,工作背景;睡前,no,2024-06-01,OK,夜间码率自动降至 96 news-014,综合资讯·早间版,live,综合资讯,MP3,64,HTTP,https://example.com/b.mp3,,通勤;做饭,yes,2024-06-01,OK,整点有 2 分钟广告段 env-003,雨声环境音,loop,环境音,AAC,48,HTTPS,https://example.com/c.m3u8,,睡前;工作背景,no,2024-05-28,SLOW,首包偶发超过 5 秒

我强烈建议你把这张表同时维护成两个形态：一个是表格软件的版本，用来筛选、排序、看视图；一个是 CSV 或 Markdown 的纯文本版本，放进版本管理里。纯文本版本的价值在于——你随时能看到“上周改了哪几行”，这是排查“为什么突然不行了”的关键线索。我有一次就是因为翻到了变更记录，才发现是自己在编辑时手滑删掉了地址末尾的一个参数。

注意：表格里的地址一定要带完整协议头，不要写成“//example.com/a.mp3”这种省略形式。有些播放器能自动补全，有些不能，而“有些能有些不能”正是最麻烦的一类兼容问题。

3. 数据采集与可用性校验：把手工活压到最低

3.1 源从哪来，以及怎么判断能不能信

采集渠道我按可信度排了个序，从高到低：官方公开的收听入口、播放器内置的公开列表、社区长期维护的清单、从公开网页播放器的网络请求里观察到的媒体地址。

前两个我基本直接用，第三个会做批量校验，第四个用得最少，因为这类地址往往带时效性参数，今天抓的明天就过期。而且我要强调一次：只做观察和记录，不做任何绕过。如果发现某个地址需要额外鉴权、需要登录态、需要特殊的签名参数，直接放弃，不要花时间去逆向——投入产出比极低，而且这类地址通常明确不是给人直接调用的。

判断一个源“能不能信”，我看三个信号：一是地址里有没有明显的时效性参数（一长串时间戳、随机 token），有的话基本可以判定为短命源；二是响应头里的内容类型是不是音频类型，而不是text/html；三是有没有明确的公开说明表示这个入口是提供给听众直接收听的。第三条最容易被忽略，但它其实是最重要的——有公开说明的源，通常结构稳定、能活很久。

3.2 一个脚本批量做三件事：连得上、响得快、播得久

手工点一遍一百条源，一次至少四十分钟，而且你很难判断“到底断没断”。我写了个小脚本，把校验拆成三个独立的判断，分开记录，这样出问题时能立刻定位是哪一层挂了。

import csv import time import requests TIMEOUT_CONNECT = 5 TIMEOUT_READ = 8 SAMPLE_SECONDS = 20 def check_one(url): result = { "url": url, "tcp": "FAIL", "first_byte_ms": "", "content_type": "", "sustain": "FAIL", "note": "", } t0 = time.time() try: with requests.get( url, stream=True, timeout=(TIMEOUT_CONNECT, TIMEOUT_READ), headers={"User-Agent": "RadioListChecker/1.0"}, allow_redirects=True, ) as resp: result["tcp"] = str(resp.status_code) result["content_type"] = resp.headers.get("Content-Type", "") first = next(resp.iter_content(2048), b"") result["first_byte_ms"] = int((time.time() - t0) * 1000) if not first: result["note"] = "首包为空" return result # 判断是否误拿到网页 head = first[:64].lower() if b"<html" in head or b"<!doctype" in head: result["note"] = "返回的不是音频流" return result # 持续读取，看是否中途断开 got = len(first) deadline = time.time() + SAMPLE_SECONDS try: for chunk in resp.iter_content(4096): got += len(chunk) if time.time() > deadline: break except Exception as e: result["note"] = f"中途断开: {type(e).__name__}" return result result["sustain"] = "OK" if got > 0 else "EMPTY" result["note"] = f"采样 {got // 1024} KB" return result except requests.exceptions.ConnectTimeout: result["note"] = "连接超时" except requests.exceptions.ReadTimeout: result["note"] = "读取超时" except requests.exceptions.SSLError: result["note"] = "证书或 TLS 握手失败" except Exception as e: result["note"] = f"{type(e).__name__}: {e}" return result if __name__ == "__main__": with open("stations.csv", newline="", encoding="utf-8") as f: rows = list(csv.DictReader(f)) out = [] for row in rows: for col in ("primary_url", "backup_url"): url = (row.get(col) or "").strip() if not url: continue r = check_one(url) r["id"] = row["id"] r["field"] = col out.append(r) time.sleep(0.5) with open("check_result.csv", "w", newline="", encoding="utf-8") as f: w = csv.DictWriter(f, fieldnames=list(out[0].keys())) w.writeheader() w.writerows(out)

几个设计上的细节值得说一下为什么这么写。

为什么把连接超时和读取超时分开？因为这两种超时的含义完全不同。连接超时说明网络层就不通，可能是地址错、域名解析失败、或者对端限流；读取超时说明连上了但数据不来，通常是服务端在等你发完整的请求，或者上游转码卡住了。分开了，排查方向立刻清晰。

为什么要读 20 秒？我试过只读前 2KB 就算通过，结果漏掉了一大批“握手正常、播十秒就断”的源。20 秒是个折中值——足够覆盖大部分服务端的首轮缓冲和限流判定，又不至于让全量校验跑到天荒地老。一百条源，每条最多 20 秒，加上间隔，一轮大概 40 分钟，放在夜里跑就行。

为什么要判Content-Type和首包内容？这是我踩过最大的坑。有些地址在你请求时，会返回一个 HTTP 200，内容是一段跳转页或者提示页。状态码漂亮得很，播放器一打开就是无限缓冲。所以脚本里必须做内容层面的判断，光看状态码等于没看。

first_byte_ms这个指标我用来做分级：小于 800 毫秒判OK，800 到 3000 毫秒之间算正常但记一笔，超过 3000 毫秒直接标SLOW。为什么卡 3 秒？因为我的心理阈值就是“按下播放键到出声，三秒内能接受”，超过三秒我就会下意识去看手机是不是没网了。

3.3 脚本判完之后，还得人耳过一遍

这里我必须泼一盆冷水：脚本只能判断“有没有数据”，判断不了“好不好听”。自动化校验通过之后，新收录的源我依然会做一次人工复核，复核清单固定四项：

第一，听 30 秒有没有声音，且声音是不是“对的”。有过一次，脚本一路绿灯，我戴上耳机一听，是两个台叠在一起的声音，各说各的。这种通常是上游转发配错，脚本完全无法感知。

第二，听有没有明显的破音和削波。低码率源如果编码参数设得激进，人声的齿音会非常刺。这个只能靠耳朵。

第三，切台两次，看会不会把播放器卡死。有些源在断开连接时不发正常的结束信号，播放器会一直等，表现就是“切过去就转圈，再也回不来”。这个问题的排查成本很高，所以我在收录阶段就筛掉。

第四，看时间轴显示是否正常。直播流理论上不该有总时长，但有些源会吐一个错误的时长元数据，导致进度条乱跳、定时关闭功能失效。这个纯属细节，但很影响日常体验。

提示：人工复核一定要用你“平时真正会用”的那套设备和耳机去听。用电脑加监听耳机听着完美的源，换成手机外放或者车机喇叭可能完全是另一回事。设备本身就是变量。

4. 播放端落地：一套源，五种设备，各有各的坑

4.1 手机和电脑：播放列表怎么组织才不乱

播放列表我统一用 M3U 格式，因为它是兼容性最好的纯文本格式，几乎所有播放器都认，而且可以手写、可以用脚本生成。我的做法不是“一个大列表”，而是按场景切成五个小列表：通勤、工作背景、睡前、做饭带娃、应急备用。

#EXTM3U #EXTINF:-1 group-title="通勤",综合资讯·早间版（64k MP3） https://example.com/b.mp3 #EXTINF:-1 group-title="工作背景",古典音乐·无口播（128k AAC） https://example.com/a.m3u8

为什么不做一个大列表？因为在一个一百多条的列表里上下翻找，体验极差，而且车载场景下你根本没空翻。切成五个列表，每个二三十条，滚动两下就能找到。group-title这个属性在支持的播放器里还能自动分组，等于白送一层分类。

生成方式上，我用脚本从主表里按scene_tags字段筛选，拼出#EXTM3U和#EXTINF行。这样主表一改，列表重新生成一次就同步了，不用手工维护两份。

有一个小经验：#EXTINF行里的显示名称，不要超过 20 个字符。我第一次生成的时候把完整备注也拼进去了，结果在车机上显示成一条滚动跑马灯，看着特别别扭。

4.2 车机和智能音箱：兼容性最差的两个环节

这两个设备是整条链路上最容易翻车的地方，我单独说。

车机的问题主要有三个。第一，格式支持窄。大量车机只认 MP3 和部分 AAC 的直连流，HLS 清单基本无解。所以我在表里给每条源都打了car_ok标记，车机播放列表只从car_ok=yes的条目里生成。第二，HTTPS 支持参差。有些车机对证书链要求严格，你手机上好好的源，车机就是不播。我遇到这类情况，第一反应就是换 HTTP 版本的备用源试试。第三，音频焦点被抢占。导航播报一响，电台就被压下去甚至停掉，播完不自动恢复。这个不是源的问题，是播放器的音频焦点处理问题，能做的只有换播放器或者接受它。

如果车机实在搞不定，我最后的兜底方案是手机播放 + 蓝牙转发。这条路的稳定性其实比车机直连更高，因为解码在手机上完成，车机只当音箱用。代价是每次上车要手动连一次、手机会耗电、来电会打断。但我个人的实际体验是，这个兜底方案比折腾车机自带播放器省心得多。

智能音箱的问题更集中。一是投播协议对 HLS 支持差，很多音箱的投播通道在拿到 m3u8 时就懵了，表现是“投过去没反应”或者“响一声就停”。二是单声道 / 立体声处理不一致，有些流是单声道，音箱会把声音全压到一侧，听着很怪。三是音量归一化缺失，不同源的响度差能到十几分贝，切个台像坐过山车。

我的经验是：给音箱用，优先选 MP3 直连、码率 96 或 128、立体声、有明确响度处理的源。宁可少几条，也别硬凑。另外，如果你的音箱支持本地网络播放，把它和播放列表放在同一个局域网内，稳定性会比走云端投播好很多。

4.3 弱网环境下的取舍：宁可降码率，也别断流

这一条是我在高铁上被教育出来的。移动网络信号波动的时候，高码率源的体验是灾难性的——它不会告诉你“我卡了”，它只会让你听着听着突然静音两秒，然后跳回三秒前的内容，来回横跳。

我的处理策略是分级降级：给高频使用的条目，在表里准备好 128 / 64 / 32 三档。移动场景下默认用 64，检测到连续卡顿就手动切 32。32 kbps 的人声类内容其实还能听，只是齿音发闷、背景音乐糊成一片，但“能听清在说什么”这个底线是守得住的。音乐类降到 32 就很勉强了，我一般就直接放弃、换个内容。

还有一个反直觉的点：切到低码率不一定意味着更稳定。有些服务端的低码率流是实时转码出来的，反而比高码率直出更容易抖。所以我实测下来，扫码率的时候一定要结合“这条流的转码方式”，而不是只看数字。这个只能靠记录，我在备注里专门写“实时转码”这四个字，提醒自己这类源在弱网下不见得靠谱。

5. 常见问题速查与踩坑记录

5.1 能连上、状态码 200、但不出声

这是最高频的一类问题，占了我在表里标FAIL条目的一大半。原因通常有四种，排查顺序我固定成下面这样，能省不少时间。

第一种，地址返回的是网页而不是流。判断方法很简单：用命令行工具直接看响应头，看Content-Type是不是音频类型或者流媒体清单类型。如果是text/html，那就说明这个地址已经变成了一个落地页，源没了。

第二种，需要特定的请求头。有些服务端会检查User-Agent或者Referer，普通的播放器默认请求头对不上就被拒。表现是连上了、立刻断，或者干脆返回一个几乎为空的响应。这种情况我会在备注里写清楚需要什么头，然后换一个支持自定义请求头的播放器。但我要提醒一句：这类源的生命周期通常不长，能换就换。

第三种，协议版本问题。同一条内容，HTTP 能播、HTTPS 不出声，或者反过来。这个是真没道理可讲，实测为准。所以我在表里给同一条源尽量备一个不同协议的版本。

第四种，播放器自己的解码器缺失。某些编码格式在部分播放器里没有内置解码支持，表现为“地址是好的、别的播放器能播、这个就是不出声”。判断方法是换一个播放器交叉验证，能播就说明是播放器的问题，不是源的问题。

# 只看响应头和内容类型，不下载音频，快速判断是不是拿到网页了 curl -sI -A "RadioListChecker/1.0" "https://example.com/a.m3u8" | head -n 20 # 读取 2 秒音频数据，判断是不是真的有流 curl -s -A "RadioListChecker/1.0" --max-time 2 "https://example.com/a.mp3" -o /dev/null -w "%{content_type} %{size_download}\n"

这两条命令是我排查时的第一手动作，比打开播放器等半天要快得多。第二条命令里的size_download特别有用——如果 2 秒内下载字节数是 0 或者只有几百字节，那基本可以判定流没起来。

5.2 播了几分钟就断，重连又好了

这类“间歇性断流”是最烦人的，因为它不像彻底失效那样一眼能看出来，而是让你的体验持续处于一种“好像还行但总归不太对”的状态。我遇到过的原因和对应处理整理如下。

这张表是我一条条踩出来的。其中“并发连接数受限”这一条，我一开始完全没想到——家里的音箱和手机同时播同一个源，两个都断，我以为是源挂了，折腾了半天。后来只用手机播就稳定了，才反应过来。所以现在我给这类源专门打了备注，只允许单设备使用。

5.3 几个容易被忽略的细节问题

音质忽大忽小。这不是玄学，是响度标准化的问题。不同源的响度能差十几分贝，晚上从安静的古典乐切到热闹的资讯台，能直接把人吓一跳。解决办法有两个：一是播放器里开“音量标准化”功能（如果支持）；二是我在表里加了一个“响度”标签，只写低、中、高三档，切台之前先看一眼。这个土办法比什么都管用。

直播流显示总时长。有些流会吐一个错误的时长元数据，导致进度条走到某个点就卡住，定时关闭也跟着失效。这个纯属源的问题，我的处理是：进“睡前”列表的源，必须验证过定时关闭功能正常，验证不通过的不进这个列表。因为睡前听东西，定时关闭是刚需，没这个功能等于没法用。

切台时“啪”一声爆音。这是采样率突变导致的，播放器没做重采样就直接输出。没什么好办法，只能选一个处理得好的播放器。我在备注里会给这类源打标记，尽量避免在安静环境里切到它们。

后台播放被系统杀掉。手机系统为了省电，会把后台播放的应用清掉。这个不是源的问题，需要在系统设置里把播放器加入后台运行白名单、关掉针对它的电池优化。我在这上面浪费过整整一个下午，一直以为是源不稳定，最后发现是系统把应用杀了。

注意：以上所有排查，都要坚持“一次只改一个变量”。我见过太多人（包括我自己）同时换源、换播放器、换网络，然后问题消失了，但完全不知道是哪个改动起的作用，下次遇到还得重新折腾一遍。

6. 维护机制：一张表能不能活过一年，看这一节

6.1 定期巡检、分级标记、绝不直接删

我给自己定的规则是每月一轮全量巡检，每周一轮常用条目巡检。全量巡检用脚本跑，跑完把结果合并回主表；常用条目巡检就二十来条，手工听一遍，两分钟的事。

关键在于状态怎么标。我的原则是：绝对不直接删除失效条目，而是把状态改成FAIL，同时记下失败的时间和失败方式。为什么？因为一条源失效，可能是临时的（服务端重启、上游调整），过两周可能自己就好了。如果直接删了，你永远不知道它好没好。保留着，下次巡检脚本自动再试一次，好了就自动转回OK，成本几乎为零。

SLOW这个状态我也是这么用的。它不算是“坏”，只是“体验不达标”。我的处理是把SLOW条目从“首选播放列表”里踢出去，但仍然保留在“备用”里。这样主列表永远是干净的，但选项还在。

巡检结果我是这么合并的：脚本输出一份结果表，我按id和字段名做主键，把status、last_check、note三列回写。回写之前一定会先看一遍差异——如果某天突然有三十条同时变成FAIL，那大概率不是三十条源同时挂了，而是我的网络或者脚本出了共性问题。这个“异常聚集”的判断很重要，能帮你避免大规模误标。

6.2 用版本管理管住变更，别信自己的记性

我所有条目都放在纯文本里，用版本管理工具做记录。每次改动都提交一次，提交信息写清楚改了什么，比如“news-014 主源改为 64k”“mus-001 备注补充夜间降码率”。

这件事的价值，我是在一次事故之后才真正体会到的。当时有个常用源突然不出声，我查了半天源本身，最后翻变更记录才发现——是我自己三天前整理表格时，把地址末尾的一个查询参数当垃圾字符删掉了。没有变更记录，我可能要花两个小时去找一个根本不存在的“服务端问题”。

除了版本管理，我还有两个小习惯。一是每月导出一次快照，存成带日期的 CSV，这个纯粹是防手滑，文件丢了能找回来。二是给每条源留一行“首次收录时间”，这个字段我一开始觉得没用，后来发现它特别有价值：能播放超过一年半的源，稳定性通常极好，值得优先放在主列表；而刚收录两周的源，我会放在“观察区”，先跑一个月再说。

6.3 表做大了之后，我删掉了哪些东西

最后说点反向的经验。这张表从最早的十几个字段，一路加到二十多个，然后又砍回十四个。砍掉的那些，都是我一开始觉得“以后肯定用得上”的字段。

砍掉的有：语言（我根本不听非母语内容，这个字段永远是同一个值）、更新时间（直播流没有这个概念）、主持人（我记不住，也从来不按人筛）、官方页面链接（我从来没点开过）、评分（主观分数三个月后就失去意义，而且我打分的时候永远在打 4 分和 5 分，区分度为零）。

留下的是那些真正影响决策的字段。判断标准很简单：一个字段如果在过去一个月里，你没有因为它而改变过任何一次操作，那它就该被砍掉。表格的价值不在于信息全，而在于信息能帮你在一秒钟内做出选择。

我现在打开这张表，看到的是：一百多条、十四条字段、五个场景列表、一个月一次自动巡检、每周一次手工抽查。它在我的手机里已经存在了两年多，期间大改过三次，但骨架一直没变。说实话，它带来的实际收益就是“按下播放，声音就出来了”——听起来很朴素，但这件事在两年里帮我省下的时间，远远超过做它花的那些功夫。

如果你也打算做一张，我的建议是先从十条开始，只填必填字段，用两周。两周之后你会非常清楚地知道，哪些字段是真正需要的，哪些是你给自己找的活。