今天你 AI 赋能了吗?打开浏览器,在地址栏输入 xuefulu.ai,按下 Enter 即可访问学府路1号!
2026年10月17日 星期六 12:32:20
常用网址:案例设计 | 案例导航 | 学府路1号 https://xuefulu.ai | 下载 WorkBuddy https://xuefulu.ai/WorkBuddy.html

一、案例背景与采集目标

出行前查班次,是每个人都做过的事:输入出发地、目的地、日期,出来一屏车次或航班,每一条写着车次号、出发到达时刻、历时、票价、余票。这一屏结果,其实就是一张结构非常规整的数据表,只等着被整理。

这一篇的示范站点是 中国铁路 12306 · 余票查询,网址 https://www.12306.cn/。它是铁路客票的官方查询入口,输入出发站、到达站、日期,就能看到当日车次与各席别的余票情况。要提醒的是:12306 有验证码与风控,本案例只示范「公开查询页」的结构与口径,正文明说——绝不绕过验证码,也绝不做高频抢票。

1.1 这个案例要拿到什么

1.2 这个案例的难点在哪

难点具体表现对策
时刻是文本「07:05」「次日 06:30」写法不一统一成 HH:MM,并单独标出是否跨天
历时是中文「2 小时 15 分」「135 分」混用换算成分钟数,另存原文
跨天判断夜间班次到达时间比出发时间还早到达时刻小于出发时刻时,判定为次日到达
票价分席别同一车次二等座 / 一等座 / 商务座价格不同按「车次 + 席别」一行一条,票价单独成列
余票是状态「有」「无」「12 张」保留原文,另设标准化列
有验证码与风控查询频繁会要求验证码不绕过、不高频;改为人工少量查询并放大间隔

1.3 采集范围与边界

班次查询结果属于面向公众公开展示的出行信息,可作示范。但有两条绝对不能碰的线:一是不采集任何乘客的个人信息(订单、姓名、证件号、座位号等);二是不做自动化购票、抢票、占座——本案例只做查询结果的整理与分析。

12306 的验证码与风控是明确的合规边界。遇到验证码,正确做法是停下来、改为人工少量查询,而不是想办法绕过。本案例的考核点是「把时刻与历时处理干净」,不是「采到多少班次」;固定线路、固定日期,一天查几次就够了。

目标站点与交付产物

下表是本篇用到的真实站点。绿色是课堂可稳定复现的示范站点;橙色是延伸站点,多数有登录墙或风控,课堂上只讲结构、原理与合规边界,不教绕过。

项目内容
示范站点12306 · 余票查询页
https://kyfw.12306.cn/otn/leftTicket/init
查询结果含车次/出发到达/时刻/历时/票价/余票,字段结构化程度高
延伸站点
  • 携程 · 火车票查询 https://trains.ctrip.com/(入口:首页填出发站、到达站与日期;有 WAF,浏览器可开、脚本会被拦)
  • 携程 · 机票查询 https://flights.ctrip.com/(入口:首页填航线与日期,取航班时刻与票价)
  • 去哪儿 · 火车票 https://train.qunar.com/(入口:首页填车站与日期,可与 12306 的余票口径对照)
  • 飞猪 · 出行频道 https://www.fliggy.com/(入口:首页顶部「火车票 / 机票」;深链会超时,用首页进)
交付产物
  • 数据明细.xlsx(含历时分钟数与跨天标记)
  • 数据明细.html(可按出发时段/历时/票价排序)
  • 数据看板.html(票价-历时散点 + 班次时段分布)
  • 技能压缩包(班次采集 + 时刻规范化规则表)
难度★★☆ 中
合规提示只采集公开的班次与票价信息,不涉及乘客订单与个人信息;不得做自动购票等影响票务秩序的操作,控制请求频率。

二、数据源与字段设计

目标站点:中国铁路 12306 · 余票查询,网址 https://www.12306.cn/。

项目内容
站点名称中国铁路 12306 · 余票查询(公开查询页)
入口网址https://www.12306.cn/(选择出发站、到达站、日期后查询)
页面形态与接口查询结果按车次列出,含各席别的余票与票价;页面有验证码与风控,属动态查询,本案例只讲结构与口径,不教绕过
实际规模同一条干线一天可有数十趟车,节假日班次与票价会临时调整
延伸站点携程火车票 https://trains.ctrip.com/、携程机票 https://flights.ctrip.com/、去哪儿 https://www.qunar.com/——聚合平台同样有风控,只作对照与本课合规讨论

2.1 完整字段表(12 个字段)

下表就是本案例的验收标准。「席别」这一列很关键:同一趟车的二等座、一等座、商务座价格不同,所以按「车次 + 席别」一行一条,票价单独成列,才便于比较。

字段名字段含义示例值口径与备注
车次号列车车次G1234照录原文,含字母前缀(G/D/K/T/Z 等)
出发站出发站点广州南保留站名与城市,站点全称
到达站到达站点上海虹桥保留站名与城市,站点全称
出发时刻发车时间(HH:MM)07:05统一成 HH:MM,补前导零
到达时刻到达时间(HH:MM)14:32统一成 HH:MM;跨天到达的按本日刻度记录
是否跨天是否次日到达否到达时刻小于出发时刻即判定为「是」
历时行程耗时原文7 小时 27 分照录页面写法,便于核对
历时分钟换算后的分钟数447「X 小时 Y 分」→ X × 60 + Y
席别座位类型二等座二等座 / 一等座 / 商务座 / 硬卧 / 硬座 等照录
票价该席别票价(元)553纯数字,去掉「¥」「元」「起」;币种另注为人民币
余票余票状态原文12原文照录,如「有」「无」「12」(「有」「无」为状态,「12」为张数)
查询日期本次查询的乘车日期2026-10-08班次与票价随时间变化,这一列是数据的背景

2.2 时刻、历时与跨天的处理口径

处理口径
时刻规范化:
  「7:5」→「07:05」;「07:05」保持不变;页面写「次日 06:30」的,把「次日」记为跨天标记

跨天判断:
  若到达时刻 < 出发时刻,判定为次日到达,是否跨天 = 是

历时换算:
  「7 小时 27 分」→ 7 × 60 + 27 = 447 分钟
  「135 分」→ 135 分钟
  「1 天 3 小时」→ 24 × 60 + 3 × 60 = 1620 分钟

校验:
  历时分钟 应当约等于(到达时刻 − 出发时刻)+ 跨天 × 1440,两者差异超过 10 分钟要复核
「历时」一定要自己算一遍再和页面比对。算出来的历时和页面标注对不上,往往说明跨天判断错了,或者把出发到达时刻采反了。

课程思政|数据安全与法治素养 · 只查班次,不碰乘客

班次信息是公开的出行信息,查询它没有问题;但乘客的订单、姓名、证件、座位属于个人隐私,任何情况下都不该去碰。出行类数据与个人行踪高度相关,法律约束也最严。数据工作者的分寸感,在这种地方体现得最清楚。

AI 助手小贴士|跨天判断是这类数据最容易出错的一步。先让 AI 把「到达时刻早于出发时刻」的班次单独列出来,人工核对一遍。

打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请把所有「到达时刻早于出发时刻」的班次单独列出来,并说明你是否已把它们标记为次日到达。

三、零代码操作步骤

工具与技能|先看清三个角色,再动手

本篇全程零代码:你把要求说清楚,AI 去执行,你负责验收。三个角色分工如下——浏览器技能指的是腾讯开源的 BrowserSkill,它能让 AI 直接操作你电脑上真实的浏览器(可复用已经登录的状态),自己开一个独立窗口干活,不打扰你正在看的网页;遇到验证码、登录或确认弹窗,它会停下来交给你本人处理。

角色负责什么在本案例里具体做什么
你确认字段清单、验收结果、清洗与合规把关盯字段清单、核对结果、处理异常(如验证码)
WorkBuddy接中文指令:探字段 → 批量采 → 清洗 → 导出交付物拆解本篇的采集任务并跑完全量、产出交付物
浏览器技能
BrowserSkill
以真实浏览器打开页面:跑脚本渲染、滚动 / 翻页 / 点开详情、截图留证;可复用本机浏览器已登录状态,遇到验证码或登录弹窗会停下来交给你处理打开查询页填线路与日期——遇到图形验证码就停下,改用人工查询

五步操作主线(全课程统一,每一篇都按这个顺序推进):

  1. 定目标与字段:先看本篇第二节的字段表,把「要哪几列、每列什么口径、要多少条」说清楚——字段清单就是验收标准,说不清就会拿回一张字段乱七八糟的表。
  2. 现场踩点(浏览器技能 BrowserSkill):打开 https://kyfw.12306.cn/otn/leftTicket/init,确认出发站、到达站、日期怎么填。
  3. 小样试采(WorkBuddy):先查一条线路,看采到的班次数与页面显示的车次数一致吗。
  4. 核对与清洗:① 出发到达时刻是不是都统一成了 HH:MM;② 到达早于出发的跨天班次有没有单独列出;③ 票价是不是纯数字(去掉「¥」「元」「起」)。
  5. 导出与归档:导出交付物(数据明细表 / 可筛选明细页 / 数据看板 / 可复用的技能包),文件名带上采集日期,并写清数据来源、采集时间与已知局限。
起手一句话(可直接复制):用浏览器技能 BrowserSkill 打开 https://kyfw.12306.cn/otn/leftTicket/init(12306 · 余票查询页),把这一页每条记录能采到的字段名和示例值列出来,先不要采集。

下面是在 WorkBuddy 里完成本案例的完整流程。注意:遇到验证码就停下改用人工查询,这是本案例的铁律。

  1. 新建对话,粘贴提示词,把线路(如「广州南 → 上海虹桥」)、日期和网址换成你要查的那一组。
  2. 先看查询结果条数,确认采到的班次数与页面上显示的车次数一致。
  3. 检查时刻格式。出发到达时刻是不是都统一成了 HH:MM?有没有「次日」没处理?
  4. 核对跨天。让 AI 把到达早于出发的班次单独列出来,你逐条核对。
  5. 换算历时。说「新增一列历时分钟,并校验与页面历时的差异」。
  6. 清洗票价。说「票价统一成纯数字,去掉「¥」「元」「起」,另设席别列」。
  7. 排序找最优。说「按票价升序排一版,再按历时升序排一版,各取前 5 名」。
  8. 导出并归档。说「导出为 Excel,文件名 schedule_20261008.xlsx」。
排序要分两次做、分别导出。「最便宜」和「最快」往往不是同一班车,一次只按一个维度排,结论才清晰。

四、提示词模板与追问技巧

下面这段可以直接复制。注意:网址写全、字段按编号列清、把「不绕验证码、不做抢票」交代死。

提示词
请帮我整理中国铁路 12306 余票查询的结果,做一张班次清单表。

【目标站点】https://www.12306.cn/
  这是 12306 的余票查询页,输入出发站、到达站、日期后显示当日车次与各席别余票。
  该页有验证码与风控,请只按下面约束处理,不要尝试任何绕过手段。

【查询条件】出发站:广州南;到达站:上海虹桥;日期:2026-10-08

【需要字段】按这个顺序:
  1. 车次号(如 G1234)
  2. 出发站
  3. 到达站
  4. 出发时刻(统一成 HH:MM)
  5. 到达时刻(统一成 HH:MM)
  6. 是否跨天(是 / 否)
  7. 历时(页面原文,照录)
  8. 历时分钟(换算成整数分钟)
  9. 席别(二等座 / 一等座 / 商务座 等)
 10. 票价(纯数字,去掉货币符号和「元」)
 11. 余票(原文照录,如「有」「无」「12」)
 12. 查询日期(乘车日期,格式 2026-10-08)

【处理口径】
  - 若到达时刻早于出发时刻,判定为次日到达,是否跨天填「是」
  - 历时分钟按「X 小时 Y 分 → X×60 + Y」换算
  - 校验:历时分钟应约等于(到达 − 出发)+ 跨天 × 1440,差超过 10 分钟要标出
  - 同一趟车不同席别按多行记录,便于比较票价

【合规要求】
  - 只整理查询结果里公开展示的班次与票价字段
  - 绝不采集任何乘客的订单、姓名、证件、座位等个人信息
  - 绝不绕过验证码;绝不做自动购票、抢票、占座
  - 固定线路与日期,少量查询、间隔充足;遇到验证码立即停止并告诉我
  - 结果导出为 schedule_20261008.xlsx

4.1 三条常用追问指令

追问指令
追问一(跨天没标对):
第 3、7 条的到达时刻早于出发时刻,请确认它们是否应该标为「次日到达」,
并把历时的校验差异算给我看。

追问二(票价清洗):
请把票价统一成纯数字,去掉「¥」「元」和「起」;
「起」字有就单独记到票价备注列,不要丢。

追问三(排序找最优):
请按票价升序输出前 5 个班次;
再按历时分钟升序输出前 5 个班次;
两个结果并排列出来,方便我对比。
余票不要急着转成数字。「有」不等于「充足」,「无」也不等于 0 张。保留原文,另设一列做标准化,判断更稳。

AI 助手小贴士|如果某一条的历时校验差异很大,先别改数字,回头看看出发和到达时刻是不是采反了——这是最常见的原因。

打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请检查第 5 条:它的出发时刻和到达时刻会不会采反了?请把页面原文和采集值并排列出来给我看。

五、结果核对、清洗与保存

整理后的结果样例(节选,示例数据:车次、时刻与票价为教学示意,非真实班次;实际采集以 12306 当日查询为准):

车次号出发站到达站出发时刻到达时刻是否跨天历时历时分钟席别票价余票
G1234广州南上海虹桥07:0514:32否7 小时 27 分447二等座55312
G1234广州南上海虹桥07:0514:32否7 小时 27 分447一等座886有
G7350广州南上海虹桥08:2015:58否7 小时 38 分458二等座553无
G7318广州南上海虹桥23:1006:15是7 小时 5 分425二等座553有

5.1 四步清洗,一句话一条

清洗指令
① 时刻规范化:
   把出发、到达时刻统一成 HH:MM(补前导零),如「7:5」改成「07:05」。

② 跨天复核:
   凡是到达时刻早于出发时刻的,是否跨天改成「是」,并核对历时。

③ 历时校验:
   用(到达 − 出发)+ 跨天 × 1440 重算一遍,
   与「历时分钟」差异超过 10 分钟的记录单独列出。

④ 票价与余票标准化:
   票价统一成纯数字;余票保留原文,另设「余票标准」列(有 / 无 / 具体张数)。

5.2 保存与归档

文件命名
schedule_20261008.xlsx           原始明细表
schedule_20261008_clean.xlsx     清洗版(时刻规范化 + 历时校验)
schedule_cheapest.xlsx           按票价升序的前 10 名
schedule_fastest.xlsx            按历时升序的前 10 名
schedule_20261008_log.txt        日志:线路、日期、班次数、校验异常条数
同一线路里,「最便宜」和「最快」往往不是同一班。把两个榜单并排放在一起,你就能得到一张简单的「性价比参考表」。

AI 助手小贴士|校验历时差异时,先排除「跨天标记错了」这一种可能,再怀疑时刻采错,最后才考虑页面数据本身的问题。

打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请按「跨天标记错误 / 时刻顺序采反 / 页面数据本身」三类,归类我的历时校验异常记录,各举一例。

课程思政|工匠精神与严谨求实 · 一分钟的差异,可能是一次误车

把「07:05」写成「7:5」在纸上还看得懂,进了程序就可能报错;把跨天的到达时刻当成当天,算出来的历时就是错的。出行数据对时间的精度要求极高,一个小失误可能让整个建议失效。数据工作里的「差不多」,往往就是「差很多」。

六、常见问题与合规红线

6.1 这个站点上最容易踩的五个坑

现象原因怎么处理
历时算出来是负数到达时刻早于出发时刻但没标跨天判定为次日到达,加 1440 分钟后重算
出发和到达时刻反了页面上两列位置接近,取错列把页面原文与采集值并排核对,逐条检查
票价带着「¥」和「起」没做数值清洗抽出纯数字,另设席别与票价备注列
余票「有」被当成 1 张把状态当成了数量保留原文,另设标准化列
查询几次后弹出验证码查询频率过高触发了风控立即停止,绝不绕过验证码;改为人工少量查询、拉长间隔

6.2 三条合规红线(每个案例都要过一遍)

  1. 只采公开班次字段。乘客的订单、姓名、证件、座位等个人信息一律不采、不碰。
  2. 不绕验证码、不做抢票。遇到验证码立即停止;采集只用于查询结果的整理与分析,绝不自动下单、抢票、占座。
  3. 控制频率。固定线路与日期,少量多次、间隔充足,不要高频轮询。
出行数据与个人行踪高度相关,法律约束最严。即使技术上「能做」,也不要去做任何涉及他人行程信息的采集,更不要尝试用自动化手段影响票务秩序。守住这条线,比学会任何一个技巧都重要。

课程思政|诚信与职业操守 · 能查到,不等于能用

技术能力会增长,但使用的边界不能跟着放大。班次数据可以用来做课程分析、做一张性价比表,但一旦被用来「监控某个人的行踪」或者「自动抢占车票」,性质就完全变了。手里的工具越锋利,越需要有一颗守规矩的心。

七、随堂自测(10 题)

点击选项即可判分,答错的题会立刻显示解析。

已答 0 / 10 · 正确 0 —

1采集班次查询结果之前,最该先确认的是?

  • A. 目标页面是否公开合法、并规划好查询频率,且不触碰验证码与个人订单
  • B. 座位颜色好不好看
  • C. 要不要顺便买张票
  • D. 自己哪天要出行
答案:A。公开合法、控制频率、不碰验证码与个人订单,是出行数据的三条底线。

2到达时刻比出发时刻还早,最合理的解释是?

  • A. 数据采集错了
  • B. 该班次次日到达,是否跨天应为「是」
  • C. 时刻格式不统一
  • D. 这趟车取消了
答案:B。夜间班次常在次日到达,到达早于出发即判定为跨天,计算历时时需加一天。

3历时原文是「2 小时 15 分」,换算成分钟应该是?

  • A. 215 分钟
  • B. 2.15 分钟
  • C. 150 分钟
  • D. 135 分钟
答案:D。2 × 60 + 15 = 135 分钟,单位换算不能简单地拼接数字。

4想找出「最合适」的班次,比较可靠的做法是?

  • A. 按票价和历时综合排序,必要时加权
  • B. 只看票价最低的那一班
  • C. 只看历时最短的那一班
  • D. 随机挑一班
答案:A。最便宜和最快通常不是同一班,综合两个维度才能得到有意义的推荐。

5余票列出现「有」「无」「12」三种写法,最稳妥的处理是?

  • A. 把「有」当成 1 张直接转数字
  • B. 保留原文,另设一列做标准化(有/无/具体张数)
  • C. 删掉余票这一列
  • D. 把「无」当成 0 参与平均值计算
答案:B。状态与数量是不同的东西,保留原文再标准化,既不失真又能比较。

6校验历时是否正确,最该先检查的是?

  • A. 票价对不对
  • B. 班次号长不长
  • C. 余票多不多
  • D. 是否跨天标记是否正确
答案:D。历时为负或偏差大,最常见的原因就是跨天没有标记,先查这一项。

7关于采集班次数据,下面哪种做法越界了?

  • A. 查询班次与票价用于课程分析
  • B. 把班次整理成性价比对比表
  • C. 在报告中标注数据来源
  • D. 用脚本高频刷新余票并自动下单抢票
答案:D。自动下单抢票既破坏票务秩序,也可能违反相关规定,是明确禁止的行为。

8同一车次在结果里出现了两次,最可靠的去重依据是?

  • A. 票价相同
  • B. 出发时刻相同
  • C. 车次号 + 查询日期
  • D. 到达站相同
答案:C。车次号加乘车日期能唯一定位一趟车,其他字段都可能重复。

9票价列同时出现「¥553」和「553 元」,正确的处理是?

  • A. 原样保留两种写法
  • B. 只保留带「元」的那种
  • C. 统一抽出纯数字,并注明币种
  • D. 按字符数排序
答案:C。数值列只保留数字,币种另作说明,这样才能正确比较与计算。

10采集时页面弹出滑动验证码,正确的做法是?

  • A. 想尽办法绕过验证码继续抓
  • B. 停止采集,改为人工少量查询并放大间隔
  • C. 找人付费破解验证码
  • D. 换一批 IP 继续高频请求
答案:B。验证码是网站明确的访问边界,正确做法是停止并改为低频人工查询,而不是绕过。