从零读懂JSON 到数据采购验收
零基础公开学习版 · 2026年9月27日
你不需要先学编程。把这套课程当成“学习读懂供应商的交货单,再检查货与单是否一致”。你已经会组织团队和推进项目,现在补的是数据交付语言。
本课程的毕业目标是:你能打开JSON、读懂字段和层级、发现常见交付问题、写清数据规格、看懂检查报告,并作出有依据的接收或退回决定。这是采购Owner的一项能力,不等于完成全部岗位训练。技术、语义、授权和客户效果仍需要相应人员共同确认。
课程内订单、说话人、语音记录均为虚构教学材料;音频清单只是一份练习目录,不含可听原音,不能据此验证转写是否正确。
第0课 今天先学会打开文件
本课结束,你要能把文件打开、修改副本、保存,并再次打开。
第一种方式最简单:解压课程包,双击“JSON零基础交互课.html”。进入“动手练习”,选择“01 第一条数据”,就能看到并修改JSON。所有处理在当前浏览器内完成,页面没有上传接口。关闭前点击“下载当前内容”保存;页面不自动保存你的修改。
第二种方式适合看供应商文件:找到“练习文件/01_第一条数据.json”,右键,选择“打开方式”,再选择“记事本”。不要用Word编辑原始JSON,也不要把后缀改成.docx或.xlsx。
你看到的英文不是程序指令,是这份数据使用的字段名称。字段名称可以是中文,但项目通常会约定英文名称;确认以后不能擅自换成同义词。
保存时先“另存为”一个副本。若用记事本,编码选择UTF-8,文件名为practice.json,保存类型选“所有文件”;界面不同也可先复制原文件再编辑。注意Windows可能隐藏扩展名,实际文件不能变成practice.json.txt。
如果以后安装VS Code:通过其官网下载,打开文件后,Windows可按Shift+Alt+F排版。排版只是让层级更整齐,不会自动修好内容。右下角应按客户要求使用JSON模式;JSON with Comments属于JSONC,允许注释等内容,不等于标准JSON交付文件。
大文件不要一次性粘进浏览器或记事本。先请工程人员提取少量样本与检查报告。本练习页限制导入1MB以内文件,定位是学习和小样本检查。
现在做:把第一条样本的language从en改成th,保存副本,再打开确认修改仍然存在。不要同时改其他字段。
第1课 JSON就是一份有字段的数据记录
先看这条最小样本:
{
"sample_id": "DEMO_001",
"language": "en",
"duration_seconds": 3.0,
"transcript": "Your order is ready.",
"quality_checked": false
}
逐行翻译:sample_id是样本编号;language是语种,这里en表示英语;duration_seconds是时长,单位秒;transcript是转写文字;quality_checked表示是否已完成这份教学规则所说的质检,false表示没有。
"language": "en"读作“language这个字段的值是en”。冒号左边是字段名,右边是字段值。外面的花括号表示:这些字段属于同一个对象,可以先理解成同一张信息卡。
这条记录本身不包含音频。即使transcript写得很流畅,也不能证明它与录音一致。JSON承载的是信息,信息真假还要查来源。
JSON是文本格式,不是Python、不是数据库,也不是某种AI模型。代码、转写、框坐标、对话记录都可以放在JSON里。
现在做:不看上文,逐个说出这五个字段的业务意思。再回答:如果duration_seconds是3,代表3秒还是3小时?答案来自字段与规格约定,不能只凭数字猜。
第2课 只记住六种符号和六种值
| 符号 | 你可以怎么理解 | 常见错误 |
|---|---|---|
{ } | 一张对象信息卡 | 少了结束花括号 |
[ ] | 按顺序排的一组东西,即数组 | 用花括号代替数组 |
: | 左边名称对应右边内容 | 写成中文全角冒号 |
, | 分隔同层级项目 | 少逗号,或最后一项多逗号 |
" " | 包住文字,也包住字段名 | 写成单引号或中文弯引号 |
\ | 转义,表达文字里的特殊符号 | 把Windows路径反斜杠直接写进去 |
下面这六种“值的类型”是你必须看懂的:
| 类型 | 示例 | 采购含义 |
|---|---|---|
| 字符串 string | "TH_001" | 文本,包括编号、语种、路径 |
| 数字 number | 3.5 | 可计算的时长、数量等 |
| 布尔 boolean | true 或 false | 是或否,具体代表什么要看字段定义 |
| 空值 null | null | 未知、不适用等,必须由项目约定 |
| 对象 object | {"speaker_id":"S1"} | 内部还有字段的一张子卡 |
| 数组 array | ["S1","S2"] | 有顺序的多个值 |
3.5是数字,"3.5"是文字。人看起来相似,处理程序可能接受一个而拒绝另一个。false是布尔值,"false"只是五个字母组成的字符串。null与"null"也不同。
尤其注意:0不是缺失,false不是缺失,空数组也不必然是错误。“这个字段的值是否有意义”和“它是否存在”要分开。
编号即使全是数字,也通常按项目约定存成字符串。例如"000123"可以保留前导零;纯数字写成000123不符合JSON数字语法。很长的编号也应使用字符串,避免某些软件的整数精度限制。
现在做:把练习中的"duration_seconds": "3.0"改成数字。再把"quality_checked": "false"改成布尔值。删的是包住值的引号,不是字段名的引号。
第3课 最容易出错的七个地方
1. 字段名必须用英文半角双引号包住。
2. 字符串用双引号,不能用单引号代替。
3. 同层级两项之间要有逗号,最后一项后不加逗号。
4. true、false、null必须小写,不能写True、False、None。
5. 标准JSON不允许//说明这样的注释。说明放到brief或字段字典。
6. 字符串里的实际换行要写成\n;需要双引号时写\"。
7. 同一个对象内不要出现重复字段名。有些软件悄悄保留最后一个值,采购交付规则应明确拒绝这种歧义。
合法的带引号文本:
{
"transcript": "他说:\"订单到了。\"",
"note": "第一行\n第二行",
"audio_path": "audio/DEMO_001.wav"
}
中文字符可以正常出现在字符串里面。中文逗号出现在“他说,你好”这类文本里没有问题;出现在字段之间、充当JSON分隔符时才有问题。
路径优先使用项目约定的相对路径,如audio/DEMO_001.wav。若必须写Windows路径,JSON文字里需要转义,例如"C:\\demo\\a.wav"。文件路径只告诉你位置,不代表文件已经交付。
现在做:依次加载练习02、03、04,只修一个错误就点击“检查语法”。不要为了消除报错而删除业务字段。
第4课 看懂一条记录里面的多层内容
语音可能被切成多个片段,每段有起止时间和转写:
{
"sample_id": "DEMO_001",
"duration_seconds": 3.0,
"segments": [
{"start": 0.0, "end": 1.2, "text": "Your order", "speaker_id": "S1"},
{"start": 1.2, "end": 2.8, "text": "is ready.", "speaker_id": "S1"}
]
}
外面是一条录音信息。segments是一个数组,里面有两个对象,每个对象是一段语音信息。数组有顺序,不能随意把第二段放到第一段前面。
工程人员可能说:segments[0].text有错。这不是另一份文件,而是一个“地址”:进入segments列表,取第一个元素,再读它的text字段。很多工具从0开始编号,所以[0]是第一个,[1]是第二个。这个写法是交流字段位置的路径表示,不是JSON文件必须采用的语法。
采购应核对:start和end的单位是什么?是否相对本录音开头?end是否超过总时长?是否允许多人重叠?本课规则为相对文件开头的秒、0≤start<end≤duration_seconds。多人重叠是否可接受由另一个规则决定,不能一概判错。
现在做:加载嵌套样本,把第二段end改为3.5。语法仍能通过,但业务规则应报“超过总时长”。这就是格式检查与业务检查的区别。
第5课 JSON和JSONL分别怎么交
JSON可以用一个数组装多条记录:
[
{"sample_id": "001", "text": "查询订单"},
{"sample_id": "002", "text": "申请退款"}
]
JSONL则把每条JSON放在一个物理行里:
{"sample_id":"001","text":"查询订单"}
{"sample_id":"002","text":"申请退款"}
JSONL两行之间不加逗号,也不在整个文件外面加方括号。每行里面的对象仍然按JSON规则写。标准JSONL每行可为任意合法JSON值;本课程和很多数据项目额外约定每行必须是对象,不接受数字或null当一整条记录。
文件采用UTF-8。行尾可以是LF或CRLF,最后一个换行可以存在,但中间空白行不作为合法记录。字段值中的换行使用\n,不能直接打断成下一条物理行。
屏幕自动折行不等于文件里真的换了一行。看行号判断,不要数屏幕上的视觉行。JSONL若导入后报“第8行错误”,先找到真实的第8行,不要猜第8条是否包括空行。
现在做:把两条记录保存为JSONL。在练习页选JSONL模式检查。再把两行之间加一个逗号,观察为什么出错。格式化JSONL时必须维持一条记录一行,不能把每条对象展开成多行。
第6课 缺失、空值和未通过不是同一件事
| 数据状态 | 意思 | Owner应该问什么 |
|---|---|---|
| 没有transcript字段 | 根本没交这个字段 | 是否漏交必填内容? |
"transcript": null | 交了字段,但值为空 | 这个场景是否允许未知? |
"transcript": "" | 交了空字符串 | 是静音,还是标注未完成? |
"quality_checked": false | 交了合法布尔值,表示未检查 | 为什么未检查就交付?应暂缓释放吗? |
"quality_checked": "false" | 类型不符合布尔约定 | 要求供应商按schema重导出 |
本课程的语音订单明确要求“有语音的片段、非空转写”,所以空字符串或null不合格。如果另一个项目专门采静音负样本,规则可能不同。这些是项目规则,不是JSON语言自带的规定。
不能为了让系统通过,把所有null都变成0,也不能把false改成true就宣称质检完成。修改状态必须有实际流程和证据。
现在做:加载练习08,回答“为什么false不是格式错误,但这一条仍然不应释放给客户?”
第7课 从语音走到SFT、API和Agent
JSON的语法一样,业务字段不同。先确认你买的交付物,再确认数据结构。
SFT示例:
{
"sample_id": "SFT_001",
"messages": [
{"role": "user", "content": "根据记录告诉我订单状态。记录:已发货。"},
{"role": "assistant", "content": "您的订单已发货。"}
]
}
采购检查:角色与顺序是否正确?回答是否有依据?是否违反指定格式?messages只是一个常见结构,客户训练系统可能要求其他结构,不能凭这一例规定所有供应商必须这样交。
API调用示例:
{
"sample_id": "API_001",
"user_text": "查询DEMO-01订单",
"tool_call": {"name": "get_order", "arguments": {"order_id": "DEMO-01"}},
"tool_result": {"status": "shipped"},
"answer": "您的订单已发货。"
}
采购检查:有没有get_order这个工具?参数名是order_id还是id?订单号是否来自用户原文?最终回答是否与工具结果一致?这里arguments按教学约定是对象;有些接口协议会要求它是JSON编码后的字符串,需要按接口文档区分。
Agent示例:
{
"sample_id": "AGENT_001",
"goal": "把待发货订单地址改成NEW",
"initial_state": {"status": "pending", "address": "OLD"},
"actions": [{"tool": "update_address", "arguments": {"address": "NEW"}}],
"final_state": {"status": "pending", "address": "NEW"},
"claimed_success": true
}
claimed_success只是提交者的声明。你要核对日志、权限与真实环境状态。若final_state仍是OLD,不能因为true就验收。JSON里写了NEW也不证明系统真的修改成功;实证需要可信执行记录或重放。
图像框数据还会出现bbox数组,例如[80,80,200,200]。先问它表示xyxy还是x、y、宽、高,单位是像素还是百分比。看懂四个数字远远不够,坐标约定是验收的一部分。
Coding任务中的code字段可能是一段代码字符串。看JSON不会使代码自动运行;检查格式也不会证明代码正确,必须由工程验收检查实现和测试。
现在做:打开API样本,把order_id改成id。语法会通过;只查语法的工具无法判断你违反了哪个接口约定。你需要另一份工具字段规格。
第8课 Owner要能写字段字典
字段字典就是给供应商的一张“填写说明”。不要只发一个样本让对方猜规则。
下面是本课程模拟语音订单的冻结规则。它仅用于练习,不是语音行业通用要求。
| 字段 | 类型 | 是否必填 | 教学规则 |
|---|---|---|---|
| sample_id | 字符串 | 是 | 非空;本批次不重复 |
| language | 字符串 | 是 | 只能是en或th;不能靠标签证明实际语种 |
| duration_seconds | 数字 | 是 | 大于0,且不超过30;单位秒 |
| audio_path | 字符串 | 是 | 必须精确匹配随包清单;不接受绝对路径或上级目录 |
| transcript | 字符串 | 是 | 非空,本批次约定只收有语音样本 |
| quality_checked | 布尔 | 是 | false合法,但暂停释放,需完成真实质检 |
| segments | 对象数组 | 是 | 至少1段;每段start/end/text/speaker_id齐全 |
片段规则:start和end必须为数字,0≤start<end≤总时长;text与speaker_id为非空字符串。数组顺序和重叠策略需与客户确认,本练习不自动拒绝重叠。
Schema可以理解成“机器能读的字段字典”。工程人员可以把类型、必填项和范围写成JSON Schema。你需要确认它反映真实需求,不必背标准语法。跨行唯一性、文件是否存在、实际音频时长、转写正确性和授权范围通常还要另做检查。
{
"type": "object",
"required": ["sample_id", "duration_seconds"],
"properties": {
"sample_id": {"type": "string", "minLength": 1},
"duration_seconds": {"type": "number", "exclusiveMinimum": 0}
}
}
这是schema片段,只示范两个字段,不是完整验收器。它自身也是JSON,但它描述的是规则,供应商样本描述的是实际记录,两者不要混淆。
现在做:给API样本写四行字段说明:工具名、订单号、调用结果、最终回答。每行写清类型、必填条件与依据。
第9课 分五层验收,别被一个绿色通过骗了
| 层级 | 检查什么 | 例子 |
|---|---|---|
| 1 语法 | 文本能否被解析 | 少逗号、引号不配对 |
| 2 结构 | 字段与类型是否符合规格 | 少转写,时长写成字符串 |
| 3 业务逻辑 | 字段之间是否自洽 | 结束时间超过总时长,重复样本ID |
| 4 交付对应 | 元数据与实际文件是否匹配 | 文件存在、可播放、时长正确、哈希一致 |
| 5 内容与来源 | 内容是否正确、有依据、可使用 | 听音核对、母语审核、授权记录 |
本练习页能检查第1层,以及指定教学规则下的第2和第3层;也能比对一份教学文件名清单。它不读取原始音频,不判断真实语言,不核验授权,不验证是否真的质检,不等于第4和第5层验收完成。
软件说“没有发现规则错误”,不代表这批货可以付款。你要知道检查覆盖了哪些规则、用了哪个版本、还有什么待核验。
重复要分开:重复字段名是一条对象内部有两个同名字段;重复sample_id是多条记录共用了编号;内容重复则可能是不同编号里装了同一段数据。三种问题需要不同检查。本工具前两种会查,内容近重复不会查。
现在做:试着向供应商解释:“这批文件能够解析,但时间轴越界和重复编号未解决,暂不验收。”
第10课 收到供应商交付后的固定动作
第一步,保存原始交付,记录批次、版本、交付时间、文件清单和检查范围。不要边查边覆盖原件。
第二步,确认规格版本。客户改过字段或时间单位时,旧版本不能直接用新规则验收,也不能默认全是供应商责任。
第三步,先小样本打开,再批量跑检查。解析失败要报具体文件、真实行号和错误,不要悄悄跳过坏行后宣称总数达标。
第四步,检查编号、数量、分布和资源对应。唯一编号数与记录行数分别统计。清单上有文件名,只说明清单声明有它,还要检查实际文件与内容。
第五步,按约定做人工或专家复核,记录各缺陷的数量与分母。抽检100条发现5条问题,只能先说该抽样范围发现5条;是否拒收整批看事先约定的抽样方案和缺陷等级。
第六步,形成问题单。写清sample_id、行号、字段路径、规则版本、实际值、预期要求、处理责任和复验安排。重复ID时仅写ID不够,需要行号或文件位置区分。
第七步,接收新版本、重新检查受影响项和必要的回归项,保留旧版本与修改记录。格式转换、事实修正、规则变更和缺素材应分开处理。
给供应商的表达示范:“批次B01按规则v1检查。第4行segments[0].end为4.2,总时长为3.0,违反end≤duration_seconds。请对照原音确认时间轴或时长字段,在修正版中保留原sample_id,并附修改说明。不得直接把4.2截断成3.0以消除报错。”
第11课 毕业实战 一批12条语音元数据
打开“动手练习”,加载“12 毕业验收批次”,切换JSONL模式,点击“检查语法”,再点击“按语音教学规则检查”。随包提供音频文件名清单,但没有实际音频;因此最后仍要写“原音及内容待验”。
你需要交四份东西:
1. 一份批次结论:暂缓还是接收,检查范围是什么。
2. 一份问题清单:行号、sample_id、字段路径、错误原因和处理建议。
3. 一份待核验清单:原音、时长、语种、转写、授权、质检证据等。
4. 一份给供应商的返修要求,不能要求他们通过编造内容或改状态来过检。
不要把毕业任务当成“修到所有灯都绿”。某些缺失信息只能从原始素材或记录恢复,不能由采购人员猜出来。本批出现重复编号,正确动作是让供应商核对记录映射,不是随便给一条换个编号。
先自己做,再打开“讲师答案.md”。本课程完成标准:能修正常见语法错误;能解释六种值与嵌套路径;能写字段字典;能准确定位批次问题;能说明自动检查覆盖范围;能给出可执行的返修与复验要求。任何一项没掌握,就回到对应练习。
这只能证明完成一次教学演练。进入真实项目后,还需要在专家和工程伙伴支持下独立负责一次试产与验收。
第12课 七天安排与以后不必死磕的内容
| 天数 | 学什么 | 必须做出的东西 |
|---|---|---|
| 第1天 | 0—2课 | 打开并保存一份JSON;讲清五个字段和六种类型 |
| 第2天 | 第3课 | 修复缺逗号、多逗号和错误引号,不删除字段 |
| 第3天 | 4—6课 | 定位嵌套字段;转换理解JSONL;区分null、0、false |
| 第4天 | 第7课 | 讲清语音、SFT、API、Agent各查什么 |
| 第5天 | 第8课 | 独立写一份任务字段字典,并与技术负责人确认 |
| 第6天 | 9—10课 | 写一份有定位信息的问题单与返修要求 |
| 第7天 | 第11课 | 完成模拟验收,复盘哪些问题工具查不出来 |
每天建议45—90分钟,按理解程度调整;这是学习安排,不承诺七天掌握完整Owner岗位。遇到不懂的字段,先问“这字段代表什么、谁填写、凭什么判断、错了如何处理”,再研究技术名词。
你暂时不用死磕解析器实现、复杂递归代码、数据库设计或大型数据平台。应持续练习的是:读懂交付、约定规则、检查证据、组织返修、解释验收结论。
查阅来源
- JSON语法与基本类型:https://www.json.org/
- JSONL编码与逐行格式:https://jsonlines.org/
- VS Code的JSON模式、格式化与schema支持:https://code.visualstudio.com/docs/languages/json
课程的业务阈值和练习样本为原创教学设置,并非上述来源规定的采购行业标准。JSONC与标准JSON的区别、语法合法与业务合格的区别,在正式交付中都要写清。