外观
评测方法与写作规范
评测与数据库的分工
| 数据库页 | 深度评测 | |
|---|---|---|
| 回答 | 是什么 | 实际怎么样 |
| 形式 | 固定字段表格 | 文章 |
| 更新 | 数据改了自动更新 | 用 30 天后重写一次 |
| 例子 | 套餐 29 元 / 300GB | 300GB 够不够用？晚高峰切专线节点要不要手动？ |
评测里不复述数据库字段。 需要数据时链过去。
为什么要分工
如果评测复述数据库字段，它就没有独立的价值。
| 读者的问题 | 该去哪 |
|---|---|
| 这家多少钱？多少流量？ | 数据库页（可横向对比） |
| 它标注什么线路？覆盖哪些地区？ | 数据库页 |
| 300GB 对我够不够用？ | 评测 |
| 晚高峰切专线节点要不要手动？ | 评测 |
| 客户端的规则配置有没有坑？ | 评测 |
| 这家适合谁、不适合谁？ | 评测 |
数据库回答可结构化的事实，评测回答需要实际使用才知道的事。
三条具体的分工规则
一、评测里不复述数据库字段。 需要数据时链过去——这样数据更新时评测不会过时。
二、评测里的数字必须是实测的。 如果是品牌资料里的数字，标明来源并链到数据库页。
三、评测的结论不能是"数据好看"。 比如"每 GB 0.136 所以划算"不是评测该给的结论——那是数据库页的信息，而且每 GB 只在流量用完时有效。
一个具体的对比
| 数据库页会写 | 评测会写 |
|---|---|
| 19 元 / 100GB，标注全 IPLC | 100GB 对每天 1 小时 1080p 的人偏紧（45–90GB）；如果你还要下载，一个月不够 |
| 标注原生 IP / 家宽 IP | 测了三个节点，新加坡的 AI 通过，香港的失败——与"香港的 AI 限制概率更高"一致 |
| 标注无理由退款 | 问客服确认了天数限制与流量上限，截图保留；这让验证成本接近零 |
| 约 2025 年起运营（待官方确认） | 观察期不足两年，建议只月付；年付的损失上限是全年 |
| 四平台自研客户端 | 测了桌面端，规则配置界面与 Clash 系的差异是…… |
右列的信息无法从数据库字段推出来——这就是评测存在的理由。
评测的三个阶段
本站把评测分成三个阶段，因为"30 天实际使用""资料 + 快照""只有资料"能回答的问题完全不同，混在一起会让读者误判结论的强度。
| 资料评测 | 首轮评测 | 完整评测 | |
|---|---|---|---|
| 依据 | 只有品牌资料（vendor）+ 编辑判断（editorial）——没有任何本站实测记录 | 品牌资料 + 一次测速快照（measured） + 编辑判断 | 30 天实际使用 + 连续三晚晚高峰实测 |
| 能回答 | 资料本身是否完整、口径是否中立、有哪些字段缺失、该问客服什么 | 节点分布、快照时段的范围性表现、异常项、套餐够不够用 | 晚高峰是"慢"还是"断"、解锁能否持续、客服响应、30 天后有没有变差 |
| 不能回答 | 任何与实际表现有关的问题——速度、延迟、节点可用性、线路类型、解锁 | 线路类型是否为真、解锁能否持续、长期稳定性 | — |
| 标注 | 页首明确标为"资料评测（无实测记录）" | 页首明确标为"首轮评测" | 标为"完整评测"并附三晚数据 |
| 结论的强度 | 只够回答"资料能不能支撑一次试用决定" | 只够回答"要不要花一个月去验证" | 够回答"适不适合长期用" |
什么时候才写资料评测
只在一种情况下：该品牌已收录在数据库里，但本站没有它的任何实测记录。
站内目前只有一家属于这种情况（无忧链接）。
| 规则 | 说明 |
|---|---|
| 不得用资料评测冒充首轮评测 | 页首必须写明"没有实测记录" |
| 不得引用其他品牌的快照替代 | 跨品牌数据不能代表这一家 |
| 不得从品牌资料推导任何表现结论 | 资料只说明"品牌声称什么" |
| 必须写清资料本身的缺口 | 哪些字段缺、哪些是营销语言、哪些待核实 |
| 必须把"自己怎么验证"写得比首轮评测更详细 | 因为本站能替读者分担的判断为零 |
资料评测的价值不在结论，而在"把资料读一遍，告诉你该问什么、该测什么"。
为什么要分两个阶段
如果只有完整评测，站内在很长时间里会一篇都没有——每篇需要约五周（一个月使用 + 30 天复测）。
如果把资料 + 快照写成完整评测，那就是在夸大结论的强度——一次快照不能推导线路类型，也不能推导解锁能力。
所以：首轮评测明确写清自己能回答什么、不能回答什么，并给出读者自己验证的清单。 它的定位是"帮你决定值不值得花 19–25 元验证一个月"，而不是"替你做长期决定"。
资料评测的硬性要求
| # | 要求 |
|---|---|
| 1 | 页首标为"资料评测（无实测记录）"，并说明为什么没有 |
| 2 | 明确写出"本站没有这家的任何速度、延迟、节点可用性数据" |
| 3 | 区分品牌资料里的中立字段与营销语言——后者要指出来 |
| 4 | 列出资料里所有待核实与缺失的字段 |
| 5 | 不做任何跨品牌的速度对照（没有可比的数据） |
| 6 | 结论段写"适合谁 / 不适合谁 / 前提条件" |
| 7 | "尚未完成的部分"要比首轮评测更长，且排在显著位置 |
| 8 | 有推广关系在文首披露；没有推广关系也要写明 |
首轮评测的硬性要求
| # | 要求 |
|---|---|
| 1 | 页首标为"首轮评测"，并列出依据的数据层级 |
| 2 | 附本站实测记录（当前为测速快照），写明快照的测试时间、测试端环境、工具、协议——没有实测记录就只能写资料评测 |
| 3 | 明确写出快照的时段——凌晨 / 白天 / 晚高峰的证据强度完全不同 |
| 4 | 逐条解读异常项，不跳过不利的数据 |
| 5 | 不从快照推导线路类型或解锁能力 |
| 6 | 结论段写"适合谁 / 不适合谁 / 前提条件" |
| 7 | 单列"尚未完成的部分"，列出还没测的维度 |
| 8 | 有推广关系在文首披露 |
从首轮升级到完整评测
| 需要补的 | 说明 |
|---|---|
| 连续三晚 21:00 的丢包与降幅 | 判断线路方案的唯一可靠方法 |
| AI 与流媒体的逐节点实测（无痕窗口、非自制剧） | 解锁结论 |
| 一个月的实际使用记录 | 稳定性、流量消耗、节点失效频率 |
| 客服响应时间的实测 | 售后维度 |
| 30 天复测 | 判断趋势 |
补齐后把页首的"首轮评测"改为"完整评测"，并保留首轮的数据作为对比基准。
14 个维度，按品牌侧重
品牌背景 · 注册体验 · 套餐分析 · 节点覆盖 · 线路质量 · 客户端体验 · 晚高峰表现 · AI 体验 · 流媒体体验 · 稳定性 · 售后 · 价格竞争力 · 适合人群 · 注意事项
- 便宜机场：重点写价格、流量够不够、晚高峰会不会降到不能用；
- 老牌机场：重点写稳定性、售后、这些年的变动；
- 专线机场：重点写线路质量、延迟、和中转的实际差距；
- 新机场：重点写背景、风险、值不值得月付试。
不要让所有评测都长成一样的 10 个章节。
14 个维度的具体内容
| 维度 | 写什么 | 数据层级 |
|---|---|---|
| 品牌背景 | 开业时间、域名历史、可核实的公开信息 | vendor |
| 注册体验 | 注册流程、是否需要额外信息、客服响应 | 实际使用 |
| 套餐分析 | 流量够不够用（不是复述数字）、倍率、档位取舍 | 实测 + vendor |
| 节点覆盖 | 实际可用的节点数（不是品牌资料里的数字） | 实测 |
| 线路质量 | 连续三晚的晚高峰丢包与降幅 | measured |
| 客户端体验 | 订阅格式、规则配置、有没有坑 | 实际使用 |
| 晚高峰表现 | 本站最重视的一项（丢包 + 降幅 + 抖动） | measured |
| AI 体验 | 逐节点测（无痕窗口、实际发消息） | measured |
| 流媒体体验 | 逐节点测（非自制剧） | measured |
| 稳定性 | 连接稳定性 + 性能稳定性（三晚一致性） | measured |
| 售后 | 客服响应时间、回答的具体程度、退款条款 | 实际使用 |
| 价格竞争力 | 与同档位对比（链到价格数据库） | vendor 派生 |
| 适合人群 | 结论段的核心 | editorial |
| 注意事项 | 不适合谁、有什么坑 | editorial |
每个维度都要标明数据来源层级——这样读者知道哪些是实测、哪些是品牌资料、哪些是编辑判断。
按品牌类型侧重
不要让所有评测长成一样的 14 个章节。
| 品牌类型 | 重点写 | 可以略写 |
|---|---|---|
| 便宜机场 | 流量够不够、晚高峰会不会降到不能用、倍率 | 品牌背景 |
| 老牌机场 | 稳定性、售后、这些年的变动 | 注册体验 |
| 专线机场 | 线路质量、延迟、与中转的实际差距 | 价格竞争力 |
| 新机场 | 背景、风险、值不值得月付试 | — |
| 披露完整的机场 | 那些披露的字段是否与实测一致 | — |
| 披露少的机场 | 必须问客服的那些项，以及回答的具体程度 | — |
为什么侧重比覆盖更重要
一篇 14 个章节都写满的评测，读者读完仍然不知道该不该买。
| 写法 | 读者的收获 |
|---|---|
| 14 章节平铺直叙 | 信息多但没有判断 |
| 按类型侧重 + 明确的适合 / 不适合 | 知道这家对不对自己 |
举例： 对一家 19 元 / 100GB 的机场，"100GB 对每天 1 小时 1080p 偏紧"这一句比整章"套餐分析"更有用。
硬性要求
- 至少附一条本站 实测记录；
- 写明测试时间、运营商、城市、宽带、客户端；
- 结论段写"适合谁 / 不适合谁"，不写"强烈推荐"；
- 有推广关系必须在文首披露；
- 30 天后复测并更新"变化"小节。
评测里不能写什么
除了"必须写什么"，同样重要的是"不能写什么"。
七条禁止
| 不能写 | 为什么 |
|---|---|
| 编造的价格、测速、节点数量、运营状态 | 本站最基础的数据规则 |
| 编造的用户评价或亲自使用经历 | 同上 |
| 从测速图 OCR 出的"精确"逐节点数据 | 会制造虚假精度 |
| 从测速图推导的线路类型 | 逻辑上做不到 |
| 从测速图推导的 AI / 流媒体解锁 | 完全不同的维度 |
| "强烈推荐"、"性价比之王"这类无信息量的结论 | 不如写适合谁 |
| 未披露的推广关系 | 必须文首披露 |
三条容易越界的地方
一、"我用了三个月，非常稳定"。
如果这不是真实的使用经历，不能写。 本站的评测必须基于实际的测试记录，而且要标注测试时间与环境。
如果是真实的，那更要标注：什么时间段、什么环境、什么方法测的。
二、"香港节点 238.6Mbps"（从截图 OCR 出来的）。
这个数字看起来精确，但它是某个时刻某个环境下的一次测量。 录成数据会让读者以为这是该节点的稳定表现。
正确的写法： "某次测试中香港节点的下载速度在数百 Mbps 量级"（范围性观察）+ 标注测试环境。
三、"从测速图看，这家应该是真专线"。
做不到。 白天公网出口不饱和，专线、中转、直连都可能很快——线路类型要靠连续三晚的晚高峰丢包判断。
正确的写法： "连续三晚 21:00 测试，该节点丢包在 0.1–0.3% 之间、降幅 18–24%，符合专线级的表现区间"（附环境说明）。
没有实测就不写评测
本站不为了页面数量而写没有实测支撑的评测。
| 情况 | 本站的处理 |
|---|---|
| 有完整的三晚实测 | 可以写评测 |
| 只有品牌资料 | 只在数据库页展示，不写评测 |
| 只有一张测速快照 | 在实测中心做快照记录，不写评测 |
| 没有任何数据 | 不收录 |
所以没有评测的品牌在数据库页会看到"暂无评测"——这是诚实的状态，不是遗漏。
这与本站其他字段的处理一致： 评分留空、解锁矩阵留空、风险事件留空、官网域名只收 1 家。不做就不填。
五条硬性要求的理由
一、至少附一条本站实测记录。
| 为什么 | 说明 |
|---|---|
| 没有实测的评测是转述 | 它只能复述品牌资料 |
| 实测是评测与数据库的区别所在 | 数据库已经有 vendor 层数据了 |
| 读者需要知道结论的依据 | — |
二、写明测试环境（时间、运营商、城市、宽带、客户端）。
因为跨环境不可比。 六个影响变量里有四个不可消除（运营商、省份、城域网条件、本地环境）——不标注环境的测试结论，读者无法判断对自己是否适用。
见 实测方法与环境说明。
三、结论段写"适合谁 / 不适合谁"，不写"强烈推荐"。
| 写法 | 信息量 |
|---|---|
| "强烈推荐" | 零（对谁推荐？为什么？） |
| "性价比之王" | 零 |
| "适合每月流量在 100GB 以内、有解锁需求、想零成本验证的人；不适合要看 4K 或需要大流量的人" | 高 |
"不适合谁"往往比"适合谁"更有价值——它能帮读者快速排除。
四、有推广关系必须在文首披露。
| 规则 | 说明 |
|---|---|
| 文首披露（不是文末小字） | 读者在读之前就知道 |
推广链接标注 sponsored nofollow | 技术层面 |
| 推广关系不影响数据的记录方式 | 从品牌资料如实录入 |
| 推广关系不影响空字段的处理 | 未实测的一律留空 |
| 推广关系不影响状态标注与下线 | 见 标注规则 |
推广关系是商业事实，不是评价依据。
五、30 天后复测并更新"变化"小节。
因为这个市场变化快：
| 会变的 | 频率 |
|---|---|
| 上游线路（GIA 可能被降级成 GT） | 不定期 |
| IP 段被标记（解锁失效） | 较频繁 |
| 节点改名或下线 | 不定期 |
| 用户规模（超卖程度） | 持续 |
| 价格与套餐 | 不定期 |
一篇没有复测记录的评测只反映写作时的状态。 30 天的复测能捕捉到"刚买时好后来变差"这种最常见的情况。
复测该更新什么
| 项目 | 说明 |
|---|---|
| 晚高峰丢包与降幅 | 与首次测试对比 |
| 解锁能力 | IP 段可能已被标记 |
| 节点是否还存在 | 对照首次记录的完整节点名 |
| 价格与套餐是否变了 | — |
| 客服响应是否变化 | — |
| 有没有出现风险信号 | 见 风险信号识别 |
复测的结论有三种：
| 结论 | 怎么写 |
|---|---|
| 无明显变化 | 记录复测日期与数据 |
| 变好了 | 说明哪一项 |
| 变差了 | 明确写出来，并更新"适合谁"的判断 |
模板
评测模板在 docs/.vitepress/templates/review.md，复制到 docs/reviews/<slug>.md 开始写。品牌 slug 见 机场数据库。
一篇评测的完整流程
从买入到发布，约五周。
第 1 周：购买与基线
| 天 | 做什么 |
|---|---|
| 0 | 从可靠来源核对官网域名；问客服五个问题并截图；只买月付 |
| 1 | 排查本地（换有线、重启路由器、确认国内网站正常） |
| 1 | 装客户端、导入订阅、记下全部能用的完整节点名与倍率 |
| 1（白天） | 每个地区 2–3 个节点：ping -c 100 + 多线程下载三次 |
| 1（21:00） | 同一批节点重测。第一个判断点 |
| 2（21:00） | 重复 |
| 3（21:00） | 重复 + traceroute |
| 4 | 测 AI 与流媒体（无痕窗口、非自制剧） |
| 5 | 配规则分流，看连接日志验证 |
| 6–7 | 正常使用，记录实感 |
第 2–4 周：实际使用
| 关注什么 | 为什么 |
|---|---|
| 关键场景的真实表现（会议连续 30 分钟通话） | 数据测不出的部分 |
| 流量消耗速度 | 判断档位是否合适 |
| 节点是否突然失效 | 记录时间与现象 |
| 解锁是否持续可用 | IP 段可能被标记 |
| 客服的响应时间 | 售后维度 |
| 有没有出现风险信号 | 见 风险信号识别 |
第 5 周：复测与写作
| 顺序 | 做什么 |
|---|---|
| 1 | 30 天复测：晚高峰丢包、解锁能力、节点是否还存在 |
| 2 | 对比首次测试，判断趋势 |
| 3 | 按品牌类型确定侧重（便宜 / 老牌 / 专线 / 新） |
| 4 | 写作：不复述数据库字段，需要数据时链过去 |
| 5 | 每个维度标明数据来源层级 |
| 6 | 结论段写"适合谁 / 不适合谁" |
| 7 | 有推广关系在文首披露 |
| 8 | 附实测记录并写明测试环境 |
| 9 | 发布 |
之后：持续更新
| 时机 | 做什么 |
|---|---|
| 每季度 | 复测关键节点，更新"变化"小节 |
| 解锁相关 | 每月复测（IP 段被标记频率最高） |
| 价格或套餐变动时 | 更新，并在 变动记录时间线 记录 |
| 状态变化时 | 同步 机场状态页 |
| 被标为异常 / 失联时 | 从推荐位下线（硬规则） |
评测的模板与位置
| 项目 | 位置 |
|---|---|
| 模板 | docs/.vitepress/templates/review.md |
| 评测文件 | docs/reviews/<slug>.md |
| 品牌 slug | 见 机场数据库 |
| 评测中心 | 深度评测 |
写法： 复制模板到 docs/reviews/<slug>.md 开始写。品牌页会自动检测对应的评测文件是否存在——存在就显示链接，不存在显示"暂无评测"。
按品牌类型的写作侧重（展开）
前面给了侧重的原则，这里给具体该问的问题。
便宜机场（19–20 元档）
核心问题：这个价格的限制在哪？
| 该回答 | 怎么测 |
|---|---|
| 100–150GB 对什么使用强度够用？ | 按流量对照表算 |
| 晚高峰会不会降到不能用？ | 连续三晚测丢包与降幅 |
| 倍率是多少？ | 看节点名或问客服 |
| 同价的不同流量档怎么选？ | 对比披露完整度与退款保障 |
| 有退款条款吗？ | 决定验证成本 |
| 这个价格的成本自洽吗？ | 低价 + 大流量 + 全专线 = 不成立 |
可以略写： 品牌背景（这个档位的用户更关心实用性）。
老牌机场（2020–2023 年起运营）
核心问题：它这些年变了吗？
| 该回答 | 怎么测 |
|---|---|
| 稳定性的历史表现 | 如有历史记录；否则三晚测试 + 说明只是当前状态 |
| 售后质量 | 问几个具体问题，记录响应时间与回答的具体程度 |
| 这些年的价格与套餐变动 | 如有记录 |
| 与新品牌比，它的优势是什么 | 运营时长本身是存续风险的指标 |
| 有没有出现"停止投入"的信号 | 节点是否长期不修、渠道是否停更 |
可以略写： 注册体验（差异不大）。
专线机场（标注 IEPL / IPLC）
核心问题：标注与实测一致吗？
| 该回答 | 怎么测 |
|---|---|
| 连续三晚的晚高峰丢包与降幅 | 核心 |
| 与中转的实际差距有多大 | 同机场内对比专线与非专线节点 |
| traceroute 显示什么 | 有无 202.97 等公网出口跳点 |
| "全专线"的话要测所有地区 | "全"字提高了标注门槛 |
| 延迟是否接近物理下限 | 对比速查表 |
| 这个价格的流量够不够 | 专线成本刚性，流量通常更少 |
可以略写： 价格竞争力（专线的溢价是预期内的）。
新机场（2025 年起运营）
核心问题：值不值得月付试？
| 该回答 | 怎么测 |
|---|---|
| 背景：开业时间、域名、可核实的公开信息 | vendor 层 |
| 风险：观察期不足两年意味着什么 | 存续风险 |
| 有退款条款吗 | 决定验证成本 |
| 定价是否成本自洽 | 低价 + 大流量 + 全专线 = 不成立 |
| 三晚实测的结果 | 当前状态 |
| 明确写"只建议月付" | 年付的损失上限是全年 |
必须写： 风险提示与"不建议买年付"。
披露完整 vs 披露少的机场
| 类型 | 该重点写 |
|---|---|
| 披露完整（IP 类型、退款条款、客服方式都有） | 那些披露的字段是否与实测一致——这是检验透明度的机会 |
| 披露少 | 必须向客服问清的那些项，以及回答的具体程度（回答本身就是信息） |
"客服回答的具体程度"是一个可观察的质量维度——含糊、回避、或与官网标注不一致，是比测速数据更早出现的信号。
推广披露的具体做法
这是本站与很多测评站差异最大的地方，值得完整说明。
披露的位置与形式
| 要求 | 说明 |
|---|---|
| 文首披露 | 不是文末小字，读者在读之前就知道 |
| 说明披露什么 | 本文含推广链接 / 本站与该品牌有推广关系 |
推广链接标注 sponsored nofollow | 技术层面的标注 |
| 品牌页也单独披露 | 不只评测页 |
推广关系不影响什么
| 项目 | 规则 |
|---|---|
| 数据的记录方式 | 从品牌资料如实录入，不因推广而美化 |
| 空字段的处理 | 未实测的一律留空，不因推广而填充 |
| 实测结果的记录 | 如实记录，包括不利的结果 |
| 状态标注与下线 | 异常 / 失联同样从推荐位下线 |
| 结论段的写法 | 同样要写"不适合谁" |
| 风险提示 | 同样要写 |
举例： 一家有推广关系的品牌，如果它的 IP 类型字段在品牌资料里没有，本站就留空——不会因为有推广而猜一个填上。
如果它的三晚实测显示晚高峰丢包 4%，评测里就写 4%——并且在"不适合谁"里写明它不适合晚间会议。
为什么这样做
| 理由 | 说明 |
|---|---|
| 推广关系是商业事实，不是评价依据 | 两者必须分开 |
| 如果推广能影响数据，整套数据就没有意义 | 读者无法信任任何字段 |
| 数据分层让这个区分可见 | commercial 层与 vendor / measured 分开 |
| 读者有权知道利益关系 | 然后自己判断 |
读者可以怎么检验
| 检验点 | 怎么核对 |
|---|---|
| 有推广关系的品牌是否也会被标为异常 | 看 机场状态页 |
| 有推广关系的品牌的空字段是否真的留空 | 看 机场数据库 |
| 评测里是否写了"不适合谁" | 看各篇评测 |
| 快照是否被用于排名 | 看 实测中心 与 排行榜方法论 |
如果你发现本站违反了自己的规则，请通过 纠错与投稿 指出。
本站不接受的
| 不接受 | 说明 |
|---|---|
| 以商业合作换取更正面的评测 | — |
| 以商业合作换取撤销状态标注 | 见 标注规则 |
| 要求删除不利的实测结果 | — |
| 要求不写"不适合谁" | — |
| 代写或审稿 | — |
申诉的唯一路径是提供可核实的依据，与普通用户走同一流程、适用同一证据标准。
结论段的写法
这是评测里最重要也最容易写坏的一段。
三种写法对比
| 写法 | 例子 | 信息量 |
|---|---|---|
| 无信息量 | "强烈推荐"、"性价比之王"、"值得一试" | 零 |
| 有信息但不完整 | "适合预算有限的用户" | 低（预算多少？有什么限制？） |
| 本站要求的写法 | 见下文 | 高 |
本站要求的结构
适合谁：
- 具体的用户画像（流量需求、使用场景、网络环境）
- 为什么适合（对应到实测结果或可核对的字段）
不适合谁：
- 具体的用户画像
- 为什么不适合
前提条件：
- 需要你自己验证什么
- 需要向客服问清什么一个具体的示例
假设一家 19 元 / 100GB、标注全 IPLC + 原生/家宽 IP + 无理由退款、约 2025 年起运营的机场：
适合谁
- 有 AI 或流媒体解锁需求的人：它是站内唯一披露 IP 类型（原生 / 家宽 IP）的品牌，而 IP 类型是解锁的决定因素。
- 想零成本验证的人：站内唯一标注无理由退款——买一个月、测完、不满意可退。
- 月流量在 100GB 以内的人：入门档够用。
不适合谁
- 要看 4K 的人：100GB 只够每天约 15 分钟 4K（每小时 7–12GB）。
- 想买年付的人：约 2025 年起运营（待官方确认），观察期不足两年；而且年付档的流量在品牌资料里未公布。
- 流量需求大的人：同价的其他套餐有 150GB。
- 看重第三方观察的人：它是站内唯一没有测速快照的品牌。
前提条件
- "全 IPLC"需要用五地验证方案自己测（"全"字对所有地区都做了承诺，只测香港不够）。
- IP 类型标注需要验证：查出口 IP 的 ASN 是住宅运营商还是数据中心。
- 必须向客服问清：年付档每月流量、退款的天数与流量上限、哪些节点有倍率。
为什么这样写
| 特点 | 价值 |
|---|---|
| 画像具体（流量数字、场景） | 读者能对照自己 |
| 每条都有理由 | 可核对 |
| "不适合谁"同样详细 | 帮读者快速排除 |
| 明确前提条件 | 不让读者以为"看完就够了" |
| 标明哪些是需要自己验证的 | 诚实 |
"不适合谁"往往比"适合谁"更有价值——因为排除比选择更快。
不要写的三种结论
| 不要写 | 为什么 |
|---|---|
| "推荐给所有人" | 跨环境不可比，不存在对所有人都好的机场 |
| "不推荐" | 除非有明确的理由（如状态异常），否则同样是无信息量 |
| "综合评分 8.5 分" | 本站的评分字段是空的，因为需要控制条件下的持续监测 |
为什么本站的评测会很慢
诚实说明：一篇符合上述标准的评测需要约五周（一个月的实际使用 + 30 天复测）。
成本
| 环节 | 投入 |
|---|---|
| 购买（月付） | 19–79 元 |
| 三天基线测试 | 约两小时 |
| 一个月实际使用 | 持续观察 |
| 30 天复测 | 约一小时 |
| 写作 | 数小时 |
| 合计 | 约五周 + 一份套餐费用 |
这个成本决定了本站的评测数量增长会很慢。
为什么不降低标准
如果降低标准（不实测、只转述品牌资料），评测的产量能提高十倍。但那样的评测：
| 问题 | 说明 |
|---|---|
| 与数据库页重复 | 数据库已经有 vendor 层数据了 |
| 无法回答"实际怎么样" | 而这正是评测的价值 |
| 可能误导读者 | 让人以为有实测支撑 |
| 会让读者跳过自己的验证 | 而验证是唯一可靠的方法 |
本站选择慢而少，而不是快而多。
读者可以怎么做
在评测覆盖之前，你可以用本站的其他部分：
| 需求 | 去哪 |
|---|---|
| 横向对比可核实的数据 | 机场数据库 · 价格数据库 |
| 完整的选购流程 | 怎么买机场 |
| 自己做三天验证 | 实测方法与环境说明 |
| 按需求筛选节点 | 节点怎么选 |
| 判断线路方案 | 中转、直连与专线 |
| 判断解锁能力 | IP 类型 |
| 风险识别 | 风险信号识别 |
本站的主要价值在这些页面——它们提供的是判断框架与方法，而框架对任何品牌都适用，不需要逐篇评测。
而且你自己的三天验证比任何评测都更能回答"这家对我好不好用"——因为它覆盖了跨环境不可比的那四个变量。
投稿评测
本站欢迎投稿，但适用同样的标准。
投稿需要满足
| 要求 | 说明 |
|---|---|
| 附实测记录 | 至少连续三晚的晚高峰数据 |
| 写明测试环境 | 时间、运营商、城市、宽带、有线 / Wi-Fi、客户端、协议 |
| 记录节点完整名 | 机场调整时的唯一锚点 |
| 结论段写"适合谁 / 不适合谁" | 不写"强烈推荐" |
| 披露利益关系 | 如有 |
| 不编造任何数据 | 本站最基础的规则 |
| 不从测速图推导线路类型或解锁 | 逻辑上做不到 |
投稿会被怎么处理
| 步骤 | 说明 |
|---|---|
| 1 | 本站核对是否满足硬性要求 |
| 2 | 满足 → 编辑后发布，标注投稿者（如愿意） |
| 3 | 不满足 → 回复说明需要补充什么 |
| 4 | 涉及状态变化的 → 同步 机场状态页 |
| 5 | 涉及可核实的变动 → 记入 变动记录时间线 |
什么投稿最有价值
| 类型 | 为什么有价值 |
|---|---|
| 来自不同网络环境的实测 | 跨环境不可比——移动 / 联通宽带的数据尤其稀缺 |
| 来自不同省份的实测 | 同上 |
| 补全缺失字段（IP 类型、退款条款、客服方式、官网域名） | 站内这些字段各只有 1 家披露 |
| 客服问答的截图 | 可核对的依据 |
| 长期使用的观察（含复测） | 能看出趋势 |
"来自不同网络环境的实测"是最有价值的——因为本站的测试环境是单一的，而跨环境不可比是这个领域的核心限制。
投稿入口： 纠错与投稿。
一个提醒
"我这里不行"通常不构成评测或事故记录——因为跨环境不可比的因素（宽带运营商、省份、时段、本地网络）让单点观察难以作为整家的结论。
如果你想报告问题，先按 超时与连接失败 与 速度慢怎么排查 排查（更新订阅、换有线、测国内网站）。多数情况会在那里解决。
如果排查后仍然确认是整家的问题，带着完整的环境说明与测试数据投稿——那样的数据对其他读者很有价值。
三十秒速查
评测 vs 数据库：
| 数据库页 | 评测 | |
|---|---|---|
| 回答 | 是什么 | 实际怎么样 |
| 举例 | 19 元 / 100GB | 100GB 对每天 1 小时 1080p 够不够 |
| 更新 | 自动 | 30 天后重写 |
五条硬性要求：
| # | 要求 |
|---|---|
| 1 | 至少附一条本站实测记录 |
| 2 | 写明测试环境（时间、运营商、城市、宽带、客户端） |
| 3 | 结论段写"适合谁 / 不适合谁"，不写"强烈推荐" |
| 4 | 有推广关系文首披露 |
| 5 | 30 天后复测并更新"变化"小节 |
不能写：
编造的数据 · 从测速图 OCR 出的"精确"数字 · 从测速图推导的线路类型或解锁能力 · 无信息量的结论 · 未披露的推广关系
按类型侧重：
| 品牌类型 | 重点 |
|---|---|
| 便宜 | 流量够不够 + 晚高峰会不会崩 + 倍率 |
| 老牌 | 稳定性 + 售后 + 这些年的变动 |
| 专线 | 三晚丢包 + 与中转的实际差距 |
| 新 | 背景 + 风险 + 只建议月付 |
核心前提： 没有实测支撑就不写评测。"暂无评测"是诚实的状态，不是遗漏。
一份写作前的自检
开始写之前逐项打勾。
数据准备
- [ ] 有连续三晚的晚高峰实测记录（丢包 + 降幅 + 抖动）
- [ ] 测试环境完整（时间、运营商、城市、宽带、有线、客户端、协议）
- [ ] 记录了节点的完整名字与倍率
- [ ] 测过 AI 与流媒体（无痕窗口、非自制剧）
- [ ] 做过真实场景测试（会议连续 30 分钟通话等）
- [ ] 有 30 天复测的数据
- [ ] 问过客服并保留截图
写作规范
- [ ] 不复述数据库字段（需要数据时链过去）
- [ ] 每个维度标明了数据来源层级
- [ ] 按品牌类型确定了侧重（不是平铺 14 章节）
- [ ] 结论段写了"适合谁 / 不适合谁 / 前提条件"
- [ ] 没有写"强烈推荐"、"性价比之王"这类无信息量的结论
- [ ] 没有编造价格、测速、节点数量、运营状态、用户评价
- [ ] 没有从测速图 OCR 出"精确"数字
- [ ] 没有从测速图推导线路类型或解锁能力
- [ ] 提到品牌资料的数字时标明了来源
披露与合规
- [ ] 有推广关系已在文首披露
- [ ] 推广链接标注了
sponsored nofollow - [ ] 不利的实测结果也如实写了
- [ ] 风险提示写了（尤其新品牌）
- [ ] 没有提供任何规避服务方检测的方法
后续
常见误判
- 评测应该覆盖所有品牌。 没有实测支撑就不写——那样的评测与数据库页重复且可能误导。
- 评测该给"最好的机场"排名。 跨环境不可比——排名需要可比性，而四个关键变量不可消除。
- 评测该写"强烈推荐"。 不如写"适合谁 / 不适合谁"，后者信息量高得多。
- 有推广关系的评测更正面。 推广关系必须文首披露，且不影响数据记录、空字段处理、状态标注与下线规则。
- 评测里的数字越精确越好。 从截图 OCR 出的"精确"数字会制造虚假精度——范围性观察 + 环境说明更诚实。
- 能从测速图看出线路类型。 逻辑上做不到。
- 评测写完就不用管了。 30 天后必须复测，之后每季度更新。
- 所有评测都该写 14 个章节。 按品牌类型侧重——便宜机场写流量与晚高峰、老牌写稳定性、新机场写风险。
- 评测越多说明站点越有价值。 本站的主要价值在判断框架与可核对的数据，不在评测数量。
- 评测能替代我自己的验证。 不能——你的三天验证覆盖了评测无法覆盖的那四个环境变量。
名词速查
| 名词 | 含义 |
|---|---|
| 14 个维度 | 评测的完整覆盖范围（按品牌类型侧重，不平铺） |
| 适合谁 / 不适合谁 | 结论段的要求（替代"强烈推荐"） |
| 30 天复测 | 硬性要求，捕捉"刚买时好后来变差" |
| 文首披露 | 推广关系必须在开头说明，不是文末小字 |
| 范围性观察 | 对测速图的正确描述方式（替代 OCR 出的精确数字） |
vendor / commercial / measured / editorial / not-tested | 本站的五层数据分层 |
| 暂无评测 | 品牌页的诚实状态，不是遗漏 |
本页数据说明
| 内容 | 层级 | 含义 |
|---|---|---|
| 评测的分工、维度、硬性要求、禁止项 | 规则说明（editorial） | 本站的写作规范 |
| 评测流程与时间表 | editorial | 本站方法建议 |
| 评测的数量 | — | 按品牌逐篇写，没有实测支撑就不写 |
本站的评测必须附实测记录并写明测试环境（时间、运营商、城市、宽带、客户端）——因为跨环境不可比。
评测里不编造价格、测速、节点数量、运营状态、用户评价或亲自使用经历；不把测速图 OCR 成精确数据、不据此推导线路类型或解锁能力。
有推广关系必须文首披露，且不影响数据的记录方式、空字段的处理、以及状态标注与下线规则。 完整规则见 免责声明 与 收录、标注与撤销标注的规则。
一句话总结
评测与数据库页的分工很清楚：数据库回答"是什么"（可结构化的 vendor 层事实，链过去而不复述），评测回答"实际怎么样"（需要实际使用才知道的事，比如"100GB 对每天 1 小时 1080p 够不够"）。五条硬性要求：至少附一条本站实测记录、写明测试环境（跨环境不可比，不标注就无法判断适用性）、结论段写"适合谁 / 不适合谁"而不是"强烈推荐"、有推广关系文首披露、30 天后复测并更新"变化"小节。写法上按品牌类型侧重而不是平铺 14 个章节——便宜机场重点写流量够不够与晚高峰会不会崩、老牌机场写稳定性与这些年的变动、新机场写背景与风险。不能写的是编造的数据、从测速图 OCR 出的"精确"数字、以及从测速图推导的线路类型或解锁能力。 本站没有实测支撑就不写评测——所以评测数量增长慢，这是选择而不是遗漏。
下一步
- 看已有的评测 → 深度评测
- 实测的完整方法 → 实测方法与环境说明
- 站内的快照记录 → 实测中心
- 排行榜是怎么排的 → 排行榜方法论
- 品牌数据（评测不复述的部分） → 机场数据库 · 价格数据库
- 自己做验证 → 怎么买机场 · 节点怎么选
- 本站的规则 → 免责声明 · 标注规则
- 投稿或纠错 → 纠错与投稿
相关页面
常见问题
评测和数据库页有什么区别？
数据库页回答"是什么"（固定字段表格、数据改了自动更新），评测回答"实际怎么样"（文章形式、用 30 天后重写）。评测里不复述数据库字段，需要数据时链过去。
为什么评测不写"强烈推荐"？
因为跨环境不可比——同一家机场在不同宽带、不同省份、不同时段的表现可能差 3–5 倍。结论段写"适合谁 / 不适合谁"比写"推荐"更有信息量，也更诚实。
评测必须附实测记录吗？
必须。至少一条本站的实测记录，并写明测试时间、运营商、城市、宽带、客户端——没有环境说明的测试结论无法判断对读者是否适用。
为什么不是所有评测都写同样的章节？
因为不同类型的品牌值得关注的点不同。便宜机场重点写流量够不够与晚高峰会不会崩；老牌机场重点写稳定性与这些年的变动；新机场重点写背景与风险。
有推广关系的评测会更正面吗？
不会。推广关系必须在文首披露，而且不影响数据的记录方式、空字段的处理、以及状态标注与下线规则。推广关系是商业事实，不是评价依据。
为什么 30 天后要复测？
因为线路会被上游变更、IP 段会被标记、机场的用户规模会变化。一篇没有复测记录的评测只反映写作时的状态，而这个市场的变化速度较快。
站内现在有多少篇评测？
评测是按品牌逐篇写的，写完才会出现在评测中心。没有评测的品牌在数据库页会看到"暂无评测"——本站不为了页面数量而写没有实测支撑的评测。
我能投稿评测吗？
可以通过纠错与投稿联系。投稿需要满足同样的硬性要求：附实测记录、写明测试环境、结论段写适合谁不适合谁、有利益关系必须披露。