一、案例背景与采集目标
出行前查班次,是每个人都做过的事:输入出发地、目的地、日期,出来一屏车次或航班,每一条写着车次号、出发到达时刻、历时、票价、余票。这一屏结果,其实就是一张结构非常规整的数据表,只等着被整理。
这一篇的示范站点是 中国铁路 12306 · 余票查询,网址 https://www.12306.cn/。它是铁路客票的官方查询入口,输入出发站、到达站、日期,就能看到当日车次与各席别的余票情况。要提醒的是:12306 有验证码与风控,本案例只示范「公开查询页」的结构与口径,正文明说——绝不绕过验证码,也绝不做高频抢票。
1.1 这个案例要拿到什么
- 某线路、某日期的班次清单,一班一行;
- 车次号、出发站、到达站;
- 出发时刻、到达时刻、历时;
- 席位类型与票价、余票状态;
- 把历时换算成分钟数,把时刻规范成统一格式;
- 按票价或历时排序,找出最合适的班次。
1.2 这个案例的难点在哪
| 难点 | 具体表现 | 对策 |
|---|---|---|
| 时刻是文本 | 「07:05」「次日 06:30」写法不一 | 统一成 HH:MM,并单独标出是否跨天 |
| 历时是中文 | 「2 小时 15 分」「135 分」混用 | 换算成分钟数,另存原文 |
| 跨天判断 | 夜间班次到达时间比出发时间还早 | 到达时刻小于出发时刻时,判定为次日到达 |
| 票价分席别 | 同一车次二等座 / 一等座 / 商务座价格不同 | 按「车次 + 席别」一行一条,票价单独成列 |
| 余票是状态 | 「有」「无」「12 张」 | 保留原文,另设标准化列 |
| 有验证码与风控 | 查询频繁会要求验证码 | 不绕过、不高频;改为人工少量查询并放大间隔 |
1.3 采集范围与边界
班次查询结果属于面向公众公开展示的出行信息,可作示范。但有两条绝对不能碰的线:一是不采集任何乘客的个人信息(订单、姓名、证件号、座位号等);二是不做自动化购票、抢票、占座——本案例只做查询结果的整理与分析。
目标站点与交付产物
下表是本篇用到的真实站点。绿色是课堂可稳定复现的示范站点;橙色是延伸站点,多数有登录墙或风控,课堂上只讲结构、原理与合规边界,不教绕过。
| 项目 | 内容 |
|---|---|
| 示范站点 | 12306 · 余票查询页 https://kyfw.12306.cn/otn/leftTicket/init 查询结果含车次/出发到达/时刻/历时/票价/余票,字段结构化程度高 |
| 延伸站点 |
|
| 交付产物 |
|
| 难度 | ★★☆ 中 |
| 合规提示 | 只采集公开的班次与票价信息,不涉及乘客订单与个人信息;不得做自动购票等影响票务秩序的操作,控制请求频率。 |
二、数据源与字段设计
目标站点:中国铁路 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 | 以真实浏览器打开页面:跑脚本渲染、滚动 / 翻页 / 点开详情、截图留证;可复用本机浏览器已登录状态,遇到验证码或登录弹窗会停下来交给你处理 | 打开查询页填线路与日期——遇到图形验证码就停下,改用人工查询 |
五步操作主线(全课程统一,每一篇都按这个顺序推进):
- 定目标与字段:先看本篇第二节的字段表,把「要哪几列、每列什么口径、要多少条」说清楚——字段清单就是验收标准,说不清就会拿回一张字段乱七八糟的表。
- 现场踩点(浏览器技能 BrowserSkill):打开
https://kyfw.12306.cn/otn/leftTicket/init,确认出发站、到达站、日期怎么填。 - 小样试采(WorkBuddy):先查一条线路,看采到的班次数与页面显示的车次数一致吗。
- 核对与清洗:① 出发到达时刻是不是都统一成了 HH:MM;② 到达早于出发的跨天班次有没有单独列出;③ 票价是不是纯数字(去掉「¥」「元」「起」)。
- 导出与归档:导出交付物(数据明细表 / 可筛选明细页 / 数据看板 / 可复用的技能包),文件名带上采集日期,并写清数据来源、采集时间与已知局限。
用浏览器技能 BrowserSkill 打开 https://kyfw.12306.cn/otn/leftTicket/init(12306 · 余票查询页),把这一页每条记录能采到的字段名和示例值列出来,先不要采集。下面是在 WorkBuddy 里完成本案例的完整流程。注意:遇到验证码就停下改用人工查询,这是本案例的铁律。
- 新建对话,粘贴提示词,把线路(如「广州南 → 上海虹桥」)、日期和网址换成你要查的那一组。
- 先看查询结果条数,确认采到的班次数与页面上显示的车次数一致。
- 检查时刻格式。出发到达时刻是不是都统一成了 HH:MM?有没有「次日」没处理?
- 核对跨天。让 AI 把到达早于出发的班次单独列出来,你逐条核对。
- 换算历时。说「新增一列历时分钟,并校验与页面历时的差异」。
- 清洗票价。说「票价统一成纯数字,去掉「¥」「元」「起」,另设席别列」。
- 排序找最优。说「按票价升序排一版,再按历时升序排一版,各取前 5 名」。
- 导出并归档。说「导出为 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 个班次;
两个结果并排列出来,方便我对比。
AI 助手小贴士|如果某一条的历时校验差异很大,先别改数字,回头看看出发和到达时刻是不是采反了——这是最常见的原因。
打开 WorkBuddy 或任意 AI 对话工具,试试这样问:请检查第 5 条:它的出发时刻和到达时刻会不会采反了?请把页面原文和采集值并排列出来给我看。
五、结果核对、清洗与保存
整理后的结果样例(节选,示例数据:车次、时刻与票价为教学示意,非真实班次;实际采集以 12306 当日查询为准):
| 车次号 | 出发站 | 到达站 | 出发时刻 | 到达时刻 | 是否跨天 | 历时 | 历时分钟 | 席别 | 票价 | 余票 |
|---|---|---|---|---|---|---|---|---|---|---|
| G1234 | 广州南 | 上海虹桥 | 07:05 | 14:32 | 否 | 7 小时 27 分 | 447 | 二等座 | 553 | 12 |
| G1234 | 广州南 | 上海虹桥 | 07:05 | 14:32 | 否 | 7 小时 27 分 | 447 | 一等座 | 886 | 有 |
| G7350 | 广州南 | 上海虹桥 | 08:20 | 15:58 | 否 | 7 小时 38 分 | 458 | 二等座 | 553 | 无 |
| G7318 | 广州南 | 上海虹桥 | 23:10 | 06: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 三条合规红线(每个案例都要过一遍)
- 只采公开班次字段。乘客的订单、姓名、证件、座位等个人信息一律不采、不碰。
- 不绕验证码、不做抢票。遇到验证码立即停止;采集只用于查询结果的整理与分析,绝不自动下单、抢票、占座。
- 控制频率。固定线路与日期,少量多次、间隔充足,不要高频轮询。
课程思政|诚信与职业操守 · 能查到,不等于能用
技术能力会增长,但使用的边界不能跟着放大。班次数据可以用来做课程分析、做一张性价比表,但一旦被用来「监控某个人的行踪」或者「自动抢占车票」,性质就完全变了。手里的工具越锋利,越需要有一颗守规矩的心。
七、随堂自测(10 题)
点击选项即可判分,答错的题会立刻显示解析。
1采集班次查询结果之前,最该先确认的是?
- A. 目标页面是否公开合法、并规划好查询频率,且不触碰验证码与个人订单
- B. 座位颜色好不好看
- C. 要不要顺便买张票
- D. 自己哪天要出行
2到达时刻比出发时刻还早,最合理的解释是?
- A. 数据采集错了
- B. 该班次次日到达,是否跨天应为「是」
- C. 时刻格式不统一
- D. 这趟车取消了
3历时原文是「2 小时 15 分」,换算成分钟应该是?
- A. 215 分钟
- B. 2.15 分钟
- C. 150 分钟
- D. 135 分钟
4想找出「最合适」的班次,比较可靠的做法是?
- A. 按票价和历时综合排序,必要时加权
- B. 只看票价最低的那一班
- C. 只看历时最短的那一班
- D. 随机挑一班
5余票列出现「有」「无」「12」三种写法,最稳妥的处理是?
- A. 把「有」当成 1 张直接转数字
- B. 保留原文,另设一列做标准化(有/无/具体张数)
- C. 删掉余票这一列
- D. 把「无」当成 0 参与平均值计算
6校验历时是否正确,最该先检查的是?
- A. 票价对不对
- B. 班次号长不长
- C. 余票多不多
- D. 是否跨天标记是否正确
7关于采集班次数据,下面哪种做法越界了?
- A. 查询班次与票价用于课程分析
- B. 把班次整理成性价比对比表
- C. 在报告中标注数据来源
- D. 用脚本高频刷新余票并自动下单抢票
8同一车次在结果里出现了两次,最可靠的去重依据是?
- A. 票价相同
- B. 出发时刻相同
- C. 车次号 + 查询日期
- D. 到达站相同
9票价列同时出现「¥553」和「553 元」,正确的处理是?
- A. 原样保留两种写法
- B. 只保留带「元」的那种
- C. 统一抽出纯数字,并注明币种
- D. 按字符数排序
10采集时页面弹出滑动验证码,正确的做法是?
- A. 想尽办法绕过验证码继续抓
- B. 停止采集,改为人工少量查询并放大间隔
- C. 找人付费破解验证码
- D. 换一批 IP 继续高频请求