用Traework搭建自媒体多平台数据分析工作台

做内容运营和自媒体的人，对下面这个场景应该不陌生：公众号后台看一次阅读量，知乎后台看一次赞同数，CSDN 后台看一次收藏量，B 站再点开一次播放量。如果是矩阵运营，可能还有小红书、视频号、抖音账号要一起看。数据散落在不同平台的后台，想看整体情况，只能手动逐个导出，再拿 Excel 一张表一张表合并。这个动作每周重复一次，分析的时间反而被搬运数据的时间占掉了。

问题不在于数据分析难，而在于流程重复。数据分析本身并不复杂，阅读量、点赞率、涨粉趋势这些指标，用 pandas 几十行代码就能算完；真正消耗精力的，是把不同平台的数据凑到一张表里，并且保证每次口径一致。

这篇文章讨论的是，怎么用 Traework 这类本地优先的工作流工具，把多平台数据采集、清洗、指标计算和可视化打包成一个可重复运行的数据分析工作台。先给一个判断：对个人运营者、垂直领域博主和独立开发者来说，与其追逐更复杂的分析模型，不如先把数据流程固化下来。本文会从概念、环境准备、核心流程到完整代码实现，一步步演示一个自媒体多渠道数据分析的落地案例。

1. 这篇文章真正要解决的问题

1.1 多平台数据分散，汇总成本远高于分析成本

做数据分析的人常犯一个错误：把精力花在算法、模型、可视化炫技上，却忽略了数据准备阶段。真实的运营场景里，数据来源往往是这样：

• 公众号后台导出流量分析，包含阅读量、分享量、关注量。
• 知乎创作中心导出赞同、评论、收藏数据。
• CSDN 博客后台有访问量、评论数、收藏数。
• B 站创作中心有播放、点赞、投币、弹幕数据。
• 如果还有小红书或抖音，数据字段就更不统一。

这些平台的后台导出格式都不一样，有的叫"阅读量"，有的叫"浏览量"，有的叫"播放量"，有的叫"访问次数"。字段名不同、时间格式不同、Excel 文件结构也不同。每次做周报，光是把这些文件整理成统一格式，就要花掉大半天。

真正值得分析的指标，比如互动率、涨粉率、爆文率，反而在数据整理完成后只需要几行代码就能算出来。

1.2 传统方案的三个短板

过去处理这种场景，常见做法有三种：

第一种：手动下载 + Excel 汇总。缺点是重复劳动，每周都要做一次，而且人工复制粘贴容易出错，口径经常对不上。

第二种：直接用平台自带的数据分析。缺点是每个后台只能看单个平台，没法做跨平台内容对比，哪个选题在 A 平台表现好但在 B 平台表现差，完全看不出来。

第三种：写一次性脚本处理。缺点是脚本散落在电脑各处，跑完一次就扔，下个月想复用发现依赖包版本变了、路径也不对，等于重写。

这三个短板背后其实是同一个原因：数据流程没有被固化下来，每一次分析都是一次从零开始。

1.3 本文方案：用 Traework 把分析流程变成工作台

Traework 这类本地工作流工具，正好解决了流程固化的问题。它可以让你把数据导入、清洗、指标计算、图表生成、报告输出这些步骤串成一条流水线。每次需要更新数据时，只要把新的导出文件丢进指定目录，运行一次工作流，就能得到一份完整的分析结果。

这篇文章适合三类读者：

• 运营多个平台账号，想统一看数据的内容创作者。
• 刚接触数据分析，想找一个小而完整的 Python 数据分析实操案例的同学。
• 想了解如何用一个本地工作流工具梳理日常重复性任务的开发者。

读完本文，你可以获得一个可复用的自媒体数据分析工作台模板，以及一套能跑通的数据清洗、指标计算、可视化的 Python 代码。

2. Traework 是什么：核心概念与适用边界

2.1 用通俗方式理解 Traework

Traework 是一个本地优先的工作流工具。你可以把它理解成一个"数据任务流水线管理平台"：它能管理多个数据处理步骤，让这些步骤按照顺序自动执行，并且把执行过程中的文件、记录、产物统一管理起来。

从技术角度看，它有以下几个关键能力：

• 本地工作环境：数据处理过程在本地运行，数据文件不会上传到云端，对隐私敏感的自媒体数据比较友好。
• 工作流编排：把不同的脚本、命令、任务串联起来，前一个步骤的输出可以作为后一个步骤的输入。
• Skill 扩展机制：类似插件或技能包，可以针对特定场景预置能力。例如热搜词中出现的 frontend-design，就是一类偏向前端设计与页面生成的能力。
• 全局用户记录：可以理解为一个跨任务的统一存储区，用来存放全局配置、用户维度数据或公共字典，避免每个任务单独维护一份重复配置。

需要注意的是，很多人在刚接触 Traework 时，容易把它和 Traecode 混淆。从产品定位上看，Traecode 更偏向代码生成与单文件的编程辅助，而 Traework 更偏向工作流编排与多步骤任务执行。简单区分：Traecode 帮你写代码，Traework 帮你跑通流程。如果只是写一个 Python 脚本，用 Traecode 顺手；如果把数据获取、清洗、计算、出图、出报告五个环节串起来反复跑，那更适合用 Traework。

2.2 与 Dify、n8n、Excel 的对比

对比之后可以得出一个判断：如果数据完全来自同一个平台，用自带的创作者后台就够了；如果数据分散在多个平台、多张表、需要重复分析，工作流工具的价值才真正体现出来。

2.3 本地工作台的适用边界

不要把这个工作台理解成什么都能干的大数据平台。它的适用边界很清晰：

• 适合处理百万行以内的结构化数据，也就是运营人员手工导出的账号内容数据。
• 适合做规律性分析，比如每周内容复盘、月度涨粉趋势。
• 不适合做实时流计算，也不适合替代专业 BI 平台去做复杂的权限管理和报表发布。

理解了这些边界，后面搭建工作台时就不会给自己设定不切实际的目标。

3. 环境准备与前置条件

3.1 Traework 本地环境准备

Traework 的安装方式取决于你使用的操作系统。从现有信息来看，Traework 有本地客户端，启动后运行在本地工作环境中。安装完成之后，建议先确认本地工作环境能正常启动。很多使用者在第一次启动时遇到过"本地工作环境启动失败"的提示，一般和端口占用、目录权限、依赖组件未启动有关，具体排查思路会在第 7 节展开。

本文演示的数据分析工作台思路不依赖 Traework 的特定版本。你在选择安装包时以官网当前发布的稳定版本为准，重点是先把本地环境跑起来，再开始搭建项目。

3.2 存储目录规划

考虑到后面要搭建的是数据分析工作台，建议在安装完成后就把工作目录规划好。热搜词里有人问"全局用户记录对应的存储目录修改到 D 盘"，这说明 Traework 允许手动调整数据存储位置。对于 Windows 用户，如果你的系统盘空间紧张，或者想把项目数据统一放在数据盘，可以在 Traework 的配置文件中找到存储目录相关的配置项，将其改为目标路径，例如D:\traework-data。

修改存储目录时需要注意一件事：如果已经创建过项目，修改路径后需要确认原来的项目数据已经迁移到新目录，或者重新建立数据索引。否则重新启动后可能出现找不到项目记录的情况。

3.3 Python 分析环境准备

Traework 负责编排流程，真正执行数据分析任务的是 Python 脚本，所以本机需要准备一个 Python 环境。关于版本，建议使用 Python 3.9 及以上版本，本文示例代码基于 pandas 和 matplotlib，这两个库是 Python 数据分析最常用的组合。

建议用虚拟环境隔离项目依赖，避免多个项目之间的包版本冲突：

# 创建虚拟环境 python -m venv venv # 激活虚拟环境（Windows） venv\Scripts\activate # 激活虚拟环境（macOS / Linux） source venv/bin/activate # 安装依赖 pip install pandas matplotlib openpyxl

安装完成后可以用下面的命令确认环境正常：

python -c "import pandas; import matplotlib; print('analysis env ready')"

如果输出analysis env ready，说明分析环境已经就绪。

4. 核心流程拆解：从原始数据到分析报告

搭建数据分析工作台之前，先理解整个流程的四个阶段。很多数据分析案例只讲建模和可视化，忽略了前置的清洗和口径统一。实际上剖开来看，自媒体数据分析的核心不是"算什么"，而是"把数据弄整齐"。

4.1 数据接入阶段

数据接入是把各平台导出的文件统一放入原始数据目录。这个阶段要明确：原始数据只读，不能清洗后覆盖原文件。建议为每个平台建一个子目录，或者用一个前缀标识文件名，例如wechat_2025_01.csv、zhihu_2025_01.csv。这样做的原因是，平台导出的数据结构可能随时调整，保留原始文件你才能回溯"上次分析为什么和这次数字对不上"。

4.2 数据清洗阶段

清洗阶段要做四件事：

• 统一字段名：把"播放量、浏览量、阅读量"统一为views。
• 统一日期格式：各平台日期可能是2025/01/01、2025-01-01、20250101三种格式，必须统一为 ISO 格式YYYY-MM-DD。
• 去除重复记录：同一篇文章被多平台转载或者导出时出现重复行，需要按文章 ID 去重。
• 处理缺失值：阅读量、点赞数这些核心字段为空时，要么删除该行，要么按规则填充。对于自媒体数据，推荐直接删除，因为缺失的记录无法参与互动率等指标计算。

4.3 指标计算阶段

指标是数据分析的表达层。自媒体内容的核心指标可以分成三类：

• 流量指标：总阅读量、平均阅读量、爆文率（阅读量超过账号均值 2 倍的文章占比）。
• 互动指标：互动率 =（点赞 + 评论 + 分享）/ 阅读量。这个指标比单纯看阅读量更能评估内容质量。
• 涨粉指标：单篇涨粉数、粉丝转化率（涨粉数 / 阅读量）。

4.4 可视化与报告阶段

最后一个阶段是把计算结果转化为图表，输出为 PNG 图片或一个 HTML 报告。这个阶段能直观看出各平台内容表现差异、发布时间与阅读量的关系、近几周互动率变化趋势。

理解这四个阶段后，下面进入完整的示例实现。

5. 完整示例：用 Traework 搭建自媒体数据分析工作台

下面的示例会从零搭建一个自媒体多渠道数据分析工作台。示例模拟的场景是：你同时运营公众号、知乎、CSDN 三个平台，定期从后台导出内容数据，希望用一个工作台完成"统一清洗 -> 计算指标 -> 生成图表"这个过程。

5.1 项目目录结构

建议的项目目录如下：

media-analysis/ ├── traework-project.yaml ├── scripts/ │ ├── data_clean.py │ ├── compute_metrics.py │ └── visualize.py ├── data/ │ ├── raw/ │ │ ├── wechat_2025.csv │ │ ├── zhihu_2025.csv │ │ └── csdn_2025.csv │ ├── clean/ │ └── output/

其中traework-project.yaml是工作流配置文件，scripts/目录存放三个 Python 脚本，data/raw/存放平台导出的原始文件，data/clean/存放清洗后的中间文件，data/output/存放最终图表和分析结果。

5.2 编写 Traework 工作流配置

首先在项目根目录创建traework-project.yaml。这是一个通用配置示例，具体字段名以你使用的 Traework 版本为准，但核心思路是一致的：定义项目名、数据目录和执行步骤。

# 文件路径：media-analysis/traework-project.yaml project: name: media-data-analysis description: 多平台自媒体内容数据分析工作台 storage: raw_dir: ./data/raw clean_dir: ./data/clean output_dir: ./data/output workflow: steps: - name: clean_data type: python script: scripts/data_clean.py desc: 清洗各平台原始数据，统一字段和日期格式 - name: compute_metrics type: python script: scripts/compute_metrics.py desc: 计算互动率、爆文率、涨粉率等核心指标 - name: visualize type: python script: scripts/visualize.py desc: 生成各平台表现对比图表

这份配置把三个步骤串成了流水线。Traework 会按顺序执行clean_data -> compute_metrics -> visualize，每个步骤的输出文件会保存在对应的存储目录中。

5.3 实现数据清洗脚本

数据清洗脚本是整个工作台最关键的脚本。

# 文件路径：media-analysis/scripts/data_clean.py import os import pandas as pd RAW_DIR = "./data/raw" CLEAN_DIR = "./data/clean" FIELD_ALIASES = { "阅读量": "views", "浏览量": "views", "播放量": "views", "访问量": "views", "点赞数": "likes", "点赞": "likes", "评论数": "comments", "评论": "comments", "分享数": "shares", "分享": "shares", "收藏数": "favorites", "收藏": "favorites", "发布日期": "publish_date", "日期": "publish_date", "文章标题": "title", "标题": "title", "文章ID": "post_id", "ID": "post_id" } def normalize_platform_file(filepath, platform): """读取一个平台导出的 CSV 文件，统一字段名并返回 DataFrame。""" df = pd.read_csv(filepath, encoding="utf-8") df.rename(columns=FIELD_ALIASES, inplace=True) # 只保留需要的核心字段，避免平台私有字段干扰 required_cols = ["post_id", "title", "publish_date", "views", "likes", "comments", "shares"] available_cols = [col for col in required_cols if col in df.columns] df = df[available_cols] # 统一日期格式 df["publish_date"] = pd.to_datetime(df["publish_date"]).dt.strftime("%Y-%m-%d") # 补充平台标识 df["platform"] = platform return df def main(): os.makedirs(CLEAN_DIR, exist_ok=True) all_frames = [] # 每个平台一个 CSV 文件，文件名含平台名 file_map = { "wechat": "wechat_2025.csv", "zhihu": "zhihu_2025.csv", "csdn": "csdn_2025.csv", } for platform, filename in file_map.items(): filepath = os.path.join(RAW_DIR, filename) if not os.path.exists(filepath): print(f"[跳过] {filename} 不存在") continue df = normalize_platform_file(filepath, platform) all_frames.append(df) print(f"[完成] {filename} 清洗完成，共 {len(df)} 条记录") if not all_frames: print("错误：没有找到任何原始数据文件") return merged = pd.concat(all_frames, ignore_index=True) # 按文章ID和平台去重，防止重复行影响统计 merged.drop_duplicates(subset=["post_id", "platform"], inplace=True) # 去掉核心字段为空的行 merged.dropna(subset=["views", "likes"], inplace=True) out_path = os.path.join(CLEAN_DIR, "merged_clean.csv") merged.to_csv(out_path, index=False, encoding="utf-8-sig") print(f"合并完成，最终保留 {len(merged)} 条记录，输出至 {out_path}") if __name__ == "__main__": main()

这段代码做了几件关键事情：

• 字段映射：通过FIELD_ALIASES字典，把不同平台的"阅读量/浏览量/播放量"统一映射为views。
• 日期标准化：pd.to_datetime自动识别常见日期格式，输出统一为YYYY-MM-DD。
• 去重与缺失处理：按post_id + platform去重，并删除阅读量和点赞数缺失的记录。
• 输出编码：用utf-8-sig编码保存，方便后续在 Excel 中直接打开不乱码。

5.4 实现指标计算脚本

清洗之后的merged_clean.csv已经是一张标准化的宽表，接下来就可以计算核心指标。

# 文件路径：media-analysis/scripts/compute_metrics.py import os import pandas as pd CLEAN_DIR = "./data/clean" OUTPUT_DIR = "./data/output" def compute_metrics(df): """基于清洗后的数据计算自媒体内容核心指标。""" result = df.copy() # 互动率 =（点赞 + 评论 + 分享）/ 阅读量 result["interaction_rate"] = ( result["likes"] + result["comments"] + result["shares"] ) / result["views"].replace(0, pd.NA) # 点赞率 result["like_rate"] = result["likes"] / result["views"].replace(0, pd.NA) # 日期转 datetime 方便按时间聚合 result["publish_date"] = pd.to_datetime(result["publish_date"]) return result def main(): os.makedirs(OUTPUT_DIR, exist_ok=True) clean_path = os.path.join(CLEAN_DIR, "merged_clean.csv") if not os.path.exists(clean_path): print("错误：请先运行 data_clean.py 生成清洗数据") return df = pd.read_csv(clean_path, encoding="utf-8-sig") result = compute_metrics(df) # 输出带指标的明细数据 result.to_csv(os.path.join(OUTPUT_DIR, "metrics_detail.csv"), index=False, encoding="utf-8-sig") # 按平台汇总 platform_summary = result.groupby("platform").agg( total_views=("views", "sum"), avg_views=("views", "mean"), avg_interaction_rate=("interaction_rate", "mean"), article_count=("post_id", "count"), ).round(4) platform_summary.to_csv(os.path.join(OUTPUT_DIR, "platform_summary.csv"), encoding="utf-8-sig") print("指标计算完成") print(platform_summary.to_string()) if __name__ == "__main__": main()

计算指标时有一个容易踩坑的点：阅读量为 0 的记录不能直接参与除法，否则会得到无穷大值。这里用replace(0, pd.NA)先做保护，避免指标失真。

5.5 实现可视化脚本

可视化脚本把计算结果转成两张图：各平台总阅读量对比图、各平台平均互动率对比图。

# 文件路径：media-analysis/scripts/visualize.py import os import pandas as pd import matplotlib.pyplot as plt plt.rcParams["font.sans-serif"] = ["SimHei", "Microsoft YaHei", "PingFang SC"] plt.rcParams["axes.unicode_minus"] = False OUTPUT_DIR = "./data/output" def main(): summary_path = os.path.join(OUTPUT_DIR, "platform_summary.csv") if not os.path.exists(summary_path): print("错误：请先运行 compute_metrics.py 生成平台汇总数据") return summary = pd.read_csv(summary_path, encoding="utf-8-sig") fig, axes = plt.subplots(1, 2, figsize=(12, 5)) # 图1：各平台总阅读量 axes[0].bar(summary["platform"], summary["total_views"], color=["#4C72B0", "#DD8452", "#55A868"]) axes[0].set_title("各平台总阅读量对比") axes[0].set_ylabel("阅读量") # 图2：各平台平均互动率 axes[1].bar(summary["platform"], summary["avg_interaction_rate"], color=["#4C72B0", "#DD8452", "#55A868"]) axes[1].set_title("各平台平均互动率对比") axes[1].set_ylabel("互动率") plt.tight_layout() out_path = os.path.join(OUTPUT_DIR, "platform_analysis.png") plt.savefig(out_path, dpi=150) print(f"图表已输出至 {out_path}") if __name__ == "__main__": main()

在 Windows 环境中，matplotlib 默认字体可能不含中文字符，图表中文会显示为方块。所以脚本开头需要显式指定中文字体，并关闭 Unicode 负号，这是处理中文可视化的标准做法。

5.6 在 Traework 中运行工作台

在 Traework 本地工作环境中打开media-analysis项目，执行工作流配置中的步骤。如果 Traework 支持直接运行工作流，它会依次执行三个脚本：先清洗、再算指标、最后出图。

也可以先在命令行手工跑一遍全部脚本，确认逻辑无误后再把流程交给 Traework 编排：

# 依次执行三个脚本，验证整条流水线 python scripts/data_clean.py python scripts/compute_metrics.py python scripts/visualize.py

实际项目中，你应该把脚本放在 Traework 的工作流里统一执行。这样每次拿到新的平台导出文件后，不需要记住三条命令，运行一次工作流即可拿到完整结果。

6. 运行结果与效果验证

6.1 预期输出

如果三个脚本都能正常运行，你会在data/output/目录下看到三个文件：

• metrics_detail.csv：带各项指标的文章明细数据。
• platform_summary.csv：各平台汇总指标。
• platform_analysis.png：可视化对比图。

platform_summary.csv内容大致如下：

6.2 如何判断流程成功

判断工作台是否搭建成功，可以看三点：

1. 三个脚本依次执行没有报错，日志中没有出现"错误"级别输出。
2. merged_clean.csv中的总记录数小于等于三个原始 CSV 记录数之和，并且没有明显的重复记录。
3. 生成的 PNG 图片能正常显示，中文标题没有乱码或方块。

6.3 失败时先看哪里

如果流程执行失败，第一步先看错误信息出现在哪个阶段：

• 如果data_clean.py报错，优先检查 CSV 文件编码和字段名。
• 如果compute_metrics.py报错，优先检查merged_clean.csv是否存在，以及views字段是否有非数字类型。
• 如果visualize.py报错，优先检查中文字体是否配置成功。

一个典型的失败场景是：读取 CSV 时遇到UnicodeDecodeError，原因是平台导出的文件是 GBK 编码。解决方案是在pd.read_csv中加一个编码参数，例如encoding="gbk"，或者读取时先用chardet检测编码。这个会在下一节的排查表中展开。

7. 常见问题与排查思路

搭建和运行过程中，下面几个问题出现频率最高。

上面这些问题中，utf-8-sig和replace(0, pd.NA)是最容易忽略的两个细节。很多自媒体数据分析脚本能跑通，但结果不对，往往就出在这两个地方。

补充一个排查原则：任何数据流程改造前，先备份原始数据。尤其是修改配置、清理重复记录、合并多表数据之前，一定要保留一份原始导出文件的副本。数据分析中可追溯性比计算速度更重要。

8. 最佳实践与工程建议

8.1 数据文件与目录规范

我建议在项目的一开始就固定以下规范：

• 原始数据目录data/raw/只读，任何脚本都不得修改该目录下的原始文件。
• 清洗后的数据统一输出到data/clean/。
• 最终报告和图表统一输出到data/output/。
• 文件名必须包含平台名和日期，例如wechat_2025_W01.csv，方便追溯某次分析用的是哪个批次的数据。

这个规范能避免一个常见问题：分析完后过了两周，想回看某个数字是从哪份文件算出来的，结果打开目录发现里面一片混乱。

8.2 建立统一的字段口径

跨平台数据分析最坑的地方，不是代码写不出来，而是字段口径不统一。以"阅读量"为例：

• 公众号后台的"阅读量"统计的是图文消息打开次数。
• 知乎的"浏览量"统计的是问题或文章被看到的次数。
• B 站的"播放量"统计的是视频被播放的次数。
• 小红书的"笔记浏览"和抖音的"播放量"又各有各的规则。

这三个数字背后代表的意义完全不同。直接拼在一起做对比，指标会有偏差。稳妥的做法是：

1. 在清洗脚本中统一命名为views，但保留platform字段。
2. 在做平台间对比时，不对比绝对数值本身，而是对比互动率、爆文率这类相对指标。
3. 在做报告时，注明数据来源的统计口径。

8.3 安全与隐私

自媒体账号数据虽然不是机密数据，但同样涉及个人隐私和商业信息。有几点建议：

• 本地工作台的数据不要同步到公网或上传到不受控的云存储。
• 如果工作台里包含私人账号信息，注意在分享报告前做脱敏处理。
• 如果脚本里有平台 API 的 Token 或 Cookie，一定不要硬编码在脚本里，更不要提交到公开仓库。建议使用环境变量或 Traework 的配置中心管理敏感信息。

8.4 增量更新与任务调度

内容数据是持续增长的。如果每次都清洗全部历史数据，数据量变大后性能会下降。更稳妥的模式是：

• 首次运行时全量清洗。
• 后续运行只处理新增的文件，按文件名中的日期批次识别增量。
• 每周固定时间运行一次工作流，可以用 Traework 的定时触发能力，也可以用系统自带的任务计划程序调用工作流命令。

8.5 沉淀可复用的 Skill

如果你在 Traework 中使用过 Skill 机制，可以把这个自媒体数据分析能力沉淀为一个 Skill。这样在做其他内容账号分析时，只需要替换原始文件目录和平台字段映射，不需要重写核心代码。这正是工作流工具相比一次性脚本的价值所在：一次搭建，多次复用。

9. 总结与后续学习方向

这篇文章通过一个自媒体多渠道数据分析案例，把 Traework 工作流配置、Python 数据清洗、指标计算和可视化串联成了一个完整闭环。核心内容可以概括为三点：

第一，多平台数据分析的真正瓶颈不是算法，而是数据整理的重复劳动。把数据流程固化成一个可反复执行的工作台，比优化某个指标的算法更有实际价值。

第二，字段口径统一是跨平台数据分析的地基。阅读量、浏览量、播放量背后的统计口径不同，必须先通过字段映射和标准化处理，才能进入指标计算环节。

第三，Traework 这类本地优先工作流工具，用来跑定时数据任务有一个明显优势：数据不出本地，流程容易复用，执行过程有记录可追溯。

如果你接下来想继续深入，有三个方向值得研究：

• Skill 开发：把本文的数据分析脚本封装成 Traework Skill，做成可复用的数据处理能力单元。
• 自动化报告：把visualize.py的输出 png 和platform_summary.csv的内容合并，自动生成一份 HTML 周报。
• 对接平台 API：从手动下载 CSV，转变为通过平台开放接口定时拉取数据，进一步减少手工操作。

最后提醒一句：开始动手之前，先去把你各平台后台的导出功能摸一遍，弄清楚导出的字段列表和文件编码。数据源摸清楚了，后面的流程搭建其实是顺水推舟的事。