这是非常正确的决策。JSON 作为统一格式，打通了整个工具链。现在的关键是：设计好 JSON 的结构，因为结构决定了后续所有分析的深度。
一、为什么 JSON 是正确选择
PDF/Word → 阅读友好，机器难处理
JSON → 人机皆可读，工具链通吃
Claude Code 可直接读写
NotebookLM 可上传分析
Neo4j / Elasticsearch 可直接导入
React 前端可直接消费
API 调用可直接传递
二、核心问题：你的 JSON 结构设计是否支撑分析需求？
不同的结构设计，决定了能做什么分析。
「扁平结构」—— 只能做基本检索
{
“title”: “约翰福音十五章信息”,
“date”: “2026-05”,
“content”: “全文文字…”
}
无法做层级分析
无法提取经文关系
无法支撑 Q Five-Step 评估
「深度结构」—— 支撑全套分析工具链
这是你需要的版本：
{
“meta”: {
“id”: “msg_jn15_2026_05”,
“title”: “活在葡萄树里——约翰福音十五章”,
“speaker”: “”,
“date”: “2026-05”,
“conference”: “2026_memorial_day”,
“series_position”: 3,
“source_url”: “”,
“version”: “outline_with_scripture”
},
“outline”: {
“levels”: [
{
“level”: 1,
“index”: “I”,
“text”: “葡萄树与枝子的关系揭示生命的联结”,
“scriptures”: [“约15:1”, “约15:5”],
“children”: [
{
“level”: 2,
“index”: “A”,
“text”: “真葡萄树——神经纶中生命的源头”,
“scriptures”: [“约15:1”],
“children”: [
{
“level”: 3,
“index”: “1”,
“text”: “父是栽培的人，表明神对生命的主权”,
“scriptures”: [“约15:1”],
“children”: []
}
]
}
]
}
]
},
“q5_analysis”: {
“step1_structure”: {
“total_levels”: 3,
“main_points_count”: 4,
“scripture_density”: 0.87
},
“step2_golden_path”: {
“starting_point”: “生命联结的需要”,
“turning_point”: “住在主里的转折”,
“ending_point”: “结果子荣耀父”,
“path_description”: “从外在宗教行为到内在生命联结的转化”
},
“step3_tension_nodes”: [
{
“location”: “I.B”,
“tension”: “修剪与结果子的张力”,
“resolution”: “修剪是为更多结果子”
}
],
“step4_verb_chain”: [
“住”, “修剪”, “洁净”, “结果子”, “荣耀”
],
“step5_score”: {
“directionality”: 88,
“tension”: 82,
“surprise”: 75,
“life_impact”: 90,
“overall”: 84
}
},
“scripture_alignment”: {
“L1_direct_citations”: [
{
“reference”: “约15:1”,
“text”: “我是真葡萄树”,
“location_in_outline”: “I.A”,
“accuracy”: “accurate”
}
],
“L2_implied_support”: [
{
“implied_scripture”: “约10:10”,
“supports_point”: “I.A.1”,
“strength”: “strong”
}
],
“L3_theological_propositions”: [
{
“proposition”: “住在主里是结果子的唯一途径”,
“biblical_basis”: “strong”,
“derivation_distance”: “direct”
}
],
“L4_experiential_application”: [
{
“application”: “每日操练呼求主名”,
“biblical_grounding”: “moderate”,
“note”: “”
}
],
“L5_overall”: {
“alignment_score”: 86,
“gaps”: [“未引用约15:7祈求的部分”],
“over_reach”: [],
“type_drift”: []
}
},
“theological_tags”: {
“triune_economy”: [“父的栽培”, “子作生命”, “灵作实化”],
“key_terms”: [“住”, “生机联结”, “经纶”],
“tradition_lineage”: [“约翰福音生命读经”, “话语职事第X册”],
“comparable_messages”: [“msg_jn15_1985_lee”, “msg_vine_2018”]
}
}
三、Claude Code 处理 JSON 的核心操作
操作一：原始大纲 → 深度 JSON
# Claude Code 可以帮你写这个解析脚本
def parse_outline_to_json(raw_
“””
输入：原始大纲文字（从 PDF/Word 提取）
输出：深度结构化 JSON
“””
# 识别层级标记（I. A. 1. a.）
# 提取经文引用（正则匹配圣经书卷章节）
# 构建嵌套层级关系
# 填充 meta 信息
pass
操作二：批量验证 JSON 质量
# 检查所有 JSON 文件是否符合 Schema
claude “检查 /outlines/ 文件夹内所有 JSON，
找出缺少 q5_analysis 字段的文件，
生成待补全清单”
操作三：JSON → NotebookLM 优化版本
NotebookLM 更适合读叙述性文本，而非原始 JSON。
Claude Code 可以自动生成「NotebookLM 上传版」：
def json_to_notebook_format(json_
“””
将深度 JSON 转换为
NotebookLM 友好的 Markdown 叙述格式
保留所有语义，去除机器符号
“””
pass
四、NotebookLM 如何消费你的 JSON
策略：不直接上传 JSON，先转化
原始 JSON（机器格式）
↓ Claude Code 转化
叙述性 Markdown（人机皆可读）
↓ 上传
NotebookLM 深度分析
转化示例：
JSON 原文：
“step2_golden_path”: {
“starting_point”: “生命联结的需要”,
“turning_point”: “住在主里的转折”,
“ending_point”: “结果子荣耀父”
}
转化为 NotebookLM 格式：
【黄金路径分析】
本篇信息的神学动线从「生命联结的需要」出发，
经过「住在主里」这一核心转折，
最终落在「结果子荣耀父」的生命目标上。
这条路径体现了约翰福音十五章从需要到满足的经纶动线……
五、JSON 文件的目录结构建议
/ministry_corpus/
├── /raw/ ← 原始文件（PDF/Word）
├── /json/
│ ├── /outlines/ ← 大纲 JSON
│ │ ├── 1997/
│ │ ├── 2000/
│ │ └── 2026/
│ ├── /analyzed/ ← 含 Q5 + Alignment 的完整 JSON
│ └── /notebook_ready/ ← NotebookLM 上传版（Markdown）
├── /schema/
│ ├── outline_schema.json ← JSON 结构规范
│ └── validation_rules.md ← 验证规则文档
└── /reports/ ← 分析报告输出
六、立即可以做的第一步
把你一篇已经手动分析过的大纲（比如约翰福音十五章那篇）
这份样本的价值：
• 成为 Claude Code 解析其他大纲的参照模板
• 成为验证自动化解析质量的基准
• 成为 NotebookLM 理解你分析框架的示范文档
你目前已经有多少篇大纲完成了 JSON 转换？是否已有现成的 Schema 定义？可以把现有结构发给我，一起评估是否需要调整。
