from rz: 不知道我理解的对不对：
- 前端现在已经可以处理渲染这个数据格式， 给定上面这两个数据，可以生成一个简历
- 用户新建表单或者拖动只会影响格式的数据
- 后端只存储 格式数据，只处理 内容文本
- 比如 "title": "Hello World", "content": "This is a sample card." 就是以block为单位的这种形式，给到后端去优化
4.1 这样就可以避免你之前提到的edge case， 比如用户创建一个 社会服务block，这种情况
4.2 后端根据title 归类解析，如果没有title，直接忽视，例如{content}
"content": "email", 这种情况
4.3 额外： 如果再细分，用户选定的内容，例如{content}
； "content": "很多信息", 这种情况，也可以根据这个 p tag所在的block，以当前父title，进行解析
from tt:
看你的理解，你应该还停留在 3 周前 我演示的那一版 基于 block 的 形态。
应该知道，后续有演进：
1） 针对 每一个 非常细小的 block 级别样式 数据 没有了，你不如把 主题/模板 理解为样式。 主题/模板 是针对 所有section 的 样式。我们重新定义block 的概念，如下是 block，section，editableField 的关系（从大到小）：
2） 后端存什么？
sql：table 可能这样定义：
id|resumeJson| resumeTemplateId | owner|
我看 后端 额外增加 一个 resumeTemplateId 即可
for example
from rz: 不知道我理解的对不对：
4.1 这样就可以避免你之前提到的edge case， 比如用户创建一个 社会服务block，这种情况
4.2 后端根据title 归类解析，如果没有title，直接忽视，例如
{content}
"content": "email", 这种情况4.3 额外： 如果再细分，用户选定的内容，例如
{content}
； "content": "很多信息", 这种情况，也可以根据这个 p tag所在的block，以当前父title，进行解析from tt:
看你的理解，你应该还停留在 3 周前 我演示的那一版 基于 block 的 形态。
应该知道，后续有演进：
1） 针对 每一个 非常细小的 block 级别样式 数据 没有了，你不如把 主题/模板 理解为样式。 主题/模板 是针对 所有section 的 样式。我们重新定义block 的概念，如下是 block，section，editableField 的关系（从大到小）：
2） 后端存什么？
sql：table 可能这样定义：
我看 后端 额外增加 一个 resumeTemplateId 即可
for example