当前位置：首页 > news >正文

RepoAgent：基于LLM与AST的代码仓库智能文档生成与维护框架

news 2026/7/8 6:46:21

1. 项目概述：当大语言模型遇见代码仓库

在软件开发的世界里，我们常常面临一个经典困境：接手一个新项目，面对一个庞大的、陌生的代码仓库，如何快速理解其整体架构、模块划分和核心逻辑？传统的做法是，一头扎进代码海洋，从入口文件开始，逐行阅读，同时祈祷项目里有一份还算过得去的 README 或者注释。这个过程耗时耗力，尤其对于动辄数万行、模块间调用关系复杂的项目，理解成本极高。更别提那些因为迭代匆忙而文档缺失的“祖传代码”了。

这正是RepoAgent诞生的背景。它不是一个简单的代码注释生成器，而是一个仓库级的智能文档生成与分析框架。它的核心目标，是让大语言模型（LLM）成为你的“代码领航员”，自动为你梳理整个 Git 仓库的结构，理解代码对象（如类、函数）之间的调用关系，并生成结构清晰、上下文关联的文档。想象一下，你提交代码后，一个智能助手自动分析你的改动，更新相关模块的文档，并确保整个项目的文档树保持同步和一致。这不仅仅是节省了写文档的时间，更是将文档维护从一项“事后补救”的负担，转变为与开发流程深度集成的、可持续的自动化实践。

RepoAgent适合所有规模的开发团队和个人开发者。对于开源项目维护者，它能显著降低新贡献者的入门门槛；对于企业内部的中大型项目，它是保证技术文档与代码同步演进、提升团队协作效率的利器；对于独立开发者，它则是管理个人项目、构建清晰知识图谱的绝佳工具。

2. 核心设计思路：从文件到知识图谱的智能跃迁

RepoAgent的设计哲学，远不止于“用 GPT 给每段代码写个说明”那么简单。它的核心在于构建一个仓库级别的代码语义理解与知识表示系统。让我们拆解一下它是如何做到的。

2.1 基于 AST 的精准代码解析

大多数基础的代码分析工具可能依赖于简单的正则表达式或关键词匹配，这种方式在遇到复杂的语法结构时极易出错。RepoAgent选择了一条更彻底的道路：抽象语法树。

AST 是源代码抽象语法结构的树状表示。RepoAgent会为支持的编程语言（目前主要是 Python）的每个文件构建 AST。通过遍历这棵树，它能精确地识别出代码中的所有“对象”：包括模块、类、函数、方法，甚至是类变量和实例变量。更重要的是，它能捕获这些对象的元信息，例如：

函数/方法的名称、参数列表（包括参数名、类型注解、默认值）。
类的名称、继承关系、类属性和方法。
函数和方法的装饰器。
代码对象所在的物理位置（文件路径、行号）。

这个过程是后续所有分析的基础。它确保了RepoAgent对代码结构的理解是语法正确且无歧义的，避免了基于文本匹配可能产生的误判。

注意：AST 解析虽然精准，但对代码的语法正确性有严格要求。如果目标仓库中存在语法错误（例如缺少括号、缩进错误），解析过程会失败。因此，在运行RepoAgent前，确保你的代码至少能通过解释器的基本语法检查是必要的。

2.2 双向调用关系图的构建

这是RepoAgent区别于普通文档生成工具的关键创新点。仅仅知道仓库里有哪些类和方法是不够的，理解它们“如何协作”才是理解系统设计的关键。

RepoAgent在 AST 解析的基础上，进行了更深层次的静态分析，以构建对象间的调用关系图。它会分析：

内部调用：一个函数内部调用了哪些其他函数或方法。
外部导入与调用：从其他模块导入了哪些对象，并调用了它们。
类实例化与继承：哪些类被实例化，类的继承链是怎样的。

通过这种分析，RepoAgent能够为每个代码对象（比如一个工具函数）生成一份文档，这份文档不仅描述它“是什么”（功能、参数），还会指出它“被谁用”（调用者）和“它用了谁”（依赖项）。这就形成了一个局部的、围绕该对象的上下文网络。

当这个网络扩展到整个仓库时，RepoAgent实际上在内存中构建了一个代码知识图谱。这个图谱以代码对象为节点，以调用、继承、导入关系为边。有了这个图谱，生成文档就不再是孤立地描述每个文件，而是可以基于全局视角，阐述模块间的依赖、数据流和设计模式。

2.3 增量更新与 Git 集成的工作流

另一个核心设计是与开发流程的无缝集成。RepoAgent不是设计成一个偶尔运行一次的离线工具，而是一个可以嵌入到git工作流中的持续集成助手。

它通过pre-commit钩子实现这一点。当你配置好RepoAgent后，每次执行git commit时，它会自动触发：

差异分析：RepoAgent会利用git diff能力，精确找出本次提交中新增、修改、删除了哪些文件。
影响范围分析：结合之前构建的代码知识图谱，分析这些文件的改动，会影响哪些相关的代码对象。例如，修改了一个工具函数的签名，所有调用它的地方都需要在文档中更新其调用方式说明。
定向文档生成/更新：只针对受影响的对象及其关联对象，调用 LLM 重新生成或更新文档。未受影响的文档保持不变。

这种增量更新机制带来了巨大优势：

效率极高：无需每次都为整个仓库重新生成文档，大大节省了计算资源和时间，尤其对于大型项目。
一致性保障：自动维护文档与代码的同步，避免了代码已改、文档滞后的“文档腐化”问题。
无感集成：开发者几乎不需要改变习惯，文档维护在提交时自动完成。

3. 实战部署与核心配置详解

理解了核心思路后，我们来一步步将其部署到实际项目中。这里我将以一个典型的 Python 项目为例，展示从安装到产出第一份文档的全过程，并深入每个配置参数的意义。

3.1 环境准备与安装

首先，确保你的环境已安装 Python（建议 3.8 及以上版本）和git。RepoAgent提供了多种安装方式，最推荐的是使用pip直接安装，这是最快捷、最标准的方式。

# 1. 使用 pip 安装 RepoAgent 核心包 pip install repoagent

安装完成后，你可以在命令行中验证是否成功：

repoagent --help

你应该能看到所有可用的命令列表，如run,diff,clean等。

实操心得：虽然项目也推荐使用pdm进行开发环境搭建，但对于绝大多数只想使用其功能的用户，pip install足矣。除非你计划阅读或修改RepoAgent的源代码，否则无需进入开发模式。

3.2 获取并配置 LLM API 密钥

RepoAgent的核心智能依赖于大语言模型。它默认使用 OpenAI 的 API（如 GPT-3.5-Turbo, GPT-4），因此你需要一个有效的 OpenAI API 密钥。

安全地设置环境变量：将 API 密钥设置为环境变量是最佳实践，避免在脚本或配置文件中硬编码敏感信息。

在 Linux/macOS 的终端中：
```
export OPENAI_API_KEY='你的-api-key-here'
```
为了让这个变量在每次打开终端时都生效，你可以将上面这行命令添加到你的 shell 配置文件（如~/.bashrc,~/.zshrc）中，然后执行source ~/.zshrc（或对应的配置文件）。
在 Windows 的命令提示符（CMD）中：
```
set OPENAI_API_KEY=你的-api-key-here
```
注意，这种方式设置的变量只在当前 CMD 窗口有效。
在 Windows PowerShell 中：
```
$Env:OPENAI_API_KEY = "你的-api-key-here"
```
若要永久设置，需要在系统环境变量中添加。

验证配置：设置完成后，可以运行一个简单的 Python 交互命令来测试：

python -c "import os; print('API Key exists:', 'OPENAI_API_KEY' in os.environ)"

如果输出True，则配置成功。

3.3 首次运行与参数解析

现在，进入你想要生成文档的目标代码仓库的根目录。假设我有一个项目叫my_awesome_project。

cd /path/to/my_awesome_project

首次运行生成完整仓库文档的命令很简单：

repoagent run

这个命令会触发以下动作：

递归扫描当前目录下的所有 Python 文件（默认忽略__pycache__,.git等目录）。
为每个文件构建 AST，解析代码对象，并分析调用关系，在内存中构建知识图谱。
将知识图谱的结构信息保存为一个 JSON 文件（默认名为.project_doc_record），作为后续增量更新的基准。
为每个识别出的代码对象（类、函数等）调用 LLM API，生成对应的 Markdown 文档。
将所有生成的 Markdown 文档组织到一个文件夹中（默认名为markdown_docs）。

repoagent run支持许多参数来定制化行为，理解它们对于高效使用至关重要：

参数	全称	类型	默认值	作用与解析
`-m`,`--model`	`model`	TEXT	`gpt-3.5-turbo`	指定使用的 LLM 模型。这是最重要的参数之一。`gpt-3.5-turbo`性价比高，速度快；`gpt-4`或`gpt-4-turbo-preview`理解力和生成质量更高，适合对文档质量要求严苛的项目，但成本也更高。
`-t`,`--temperature`	`temperature`	FLOAT	`0.2`	控制生成文本的随机性。范围 0.0 到 2.0。值越低（如 0.1-0.3），输出越确定、一致，适合技术文档；值越高，输出越有创造性、多样化。对于文档生成，强烈建议保持较低值以确保准确性和稳定性。
`-r`,`--request-timeout`	`request-timeout`	INTEGER	`60`	API 请求超时时间（秒）。如果网络较慢或生成内容很长，可以适当调高此值，避免任务因超时失败。
`-b`,`--base-url`	`base-url`	TEXT	`https://api.openai.com/v1`	API 的基础 URL。如果你使用的是 OpenAI 官方服务，无需修改。如果你部署了本地模型或使用兼容 OpenAI API 的第三方服务（如 Ollama, vLLM, 或国内的一些大模型平台），则需要将此参数指向你的服务地址。这是支持本地模型的关键。
`-tp`,`--target-repo-path`	`target-repo-path`	PATH	当前目录	目标仓库的路径。通常你已经在目标目录下，所以无需指定。如果你希望从其他位置对一个仓库运行，可以用此参数指定。
`-hp`,`--hierarchy-path`	`hierarchy-path`	TEXT	`.project_doc_record`	项目结构记录文件的路径/名称。这个 JSON 文件是`RepoAgent`的“记忆”，存储了代码知识图谱。建议将其加入`.gitignore`，因为它是生成的中间文件，且可能包含 API 调用内容。
`-mdp`,`--markdown-docs-path`	`markdown-docs-path`	TEXT	`markdown_docs`	Markdown 文档的输出目录。所有生成的文档都会放在这个文件夹下，并按原代码的目录结构组织。
`-i`,`--ignore-list`	`ignore-list`	TEXT	(内置列表)	忽略的文件或目录列表，用逗号分隔。例如`-i “tests/, temp.py, *.log”`。内置列表通常已包含常见的非代码目录如`.git`,`node_modules`,`venv`等。
`-l`,`--language`	`language`	TEXT	`Chinese`	生成文档的语言。可以是`English`、`Chinese`等。LLM 会根据此参数生成对应语言的描述。
`-ll`,`--log-level`	`log-level`	枚举	`INFO`	日志级别。调试时可用`DEBUG`查看更详细的解析和 API 调用过程；正常使用`INFO`或`WARNING`即可。

一个更复杂的首次运行示例，使用 GPT-4 模型，并为大型项目设置更长的超时：

repoagent run --model gpt-4 --temperature 0.1 --request-timeout 120 --language English

3.4 集成到 Git 工作流：自动化文档维护

首次运行生成了完整的基线文档后，下一步就是将其集成到日常开发中，实现文档的自动同步。这通过pre-commit钩子实现。

步骤 1：在目标仓库中初始化 Git 和安装 pre-commit确保你的项目已经是 Git 仓库。如果不是，先初始化：

git init

然后安装pre-commit工具：

pip install pre-commit

步骤 2：创建.pre-commit-config.yaml文件在项目根目录下创建这个文件，这是pre-commit的配置文件。内容如下：

repos: - repo: local # 表示使用本地钩子 hooks: - id: repo-agent name: RepoAgent entry: repoagent run # 钩子触发时执行的命令 language: system # 使用系统环境中的 repoagent pass_filenames: false # 重要！不让 pre-commit 传递文件名，由 repoagent 自己分析 git diff stages: [commit] # 在 commit 阶段触发 # 目前主要支持 Python 文件，这里指定触发文件类型 types: [python]

步骤 3：安装钩子运行以下命令，将配置的钩子安装到当前仓库的.git/hooks目录下：

pre-commit install

安装成功后，你会看到类似pre-commit installed at .git/hooks/pre-commit的提示。

步骤 4：体验自动化流程现在，你的自动化文档流水线已经就绪。接下来进行常规开发：

修改或新增一个 Python 文件，例如utils/helpers.py。
使用git add utils/helpers.py将改动暂存。
执行git commit -m “feat: add new helper function”。

在git commit命令执行后、实际创建提交对象前，pre-commit钩子会被触发，自动运行repoagent run。此时RepoAgent会：

检测到utils/helpers.py被修改。
分析该文件的改动影响了哪些对象（比如新增了一个函数calculate_stats）。
调用 LLM 为这个新函数生成文档。
同时，它会分析知识图谱，找到所有调用了utils/helpers.py中其他函数的代码，并判断这些调用关系或描述是否需要更新（例如，如果calculate_stats被另一个模块的函数调用，该调用者的文档可能需要更新）。
将新生成或更新的 Markdown 文件写入markdown_docs目录。
关键一步：RepoAgent会自动将这些更新的 Markdown 文件git add到暂存区。这意味着文档的更新会和你的代码变更在同一次提交中。

整个过程完成后，git commit才会最终完成。你可以在提交历史中看到，一次提交既包含了代码改动，也包含了对应的文档更新，保持了原子性。

重要提示：pass_filenames: false这个配置至关重要。如果设为true，pre-commit只会将本次提交涉及的文件名传给repoagent，这破坏了RepoAgent基于完整知识图谱进行影响分析的能力。设置为false后，repoagent run在钩子中运行时，会自己执行git diff来分析所有变更，从而做出正确的全局更新决策。

4. 进阶使用与场景化技巧

掌握了基础部署和配置后，我们来看看如何更高效、更定制化地使用RepoAgent，以及如何处理一些特殊场景。

4.1 利用`diff`和`clean`命令进行精细控制

除了核心的run命令，RepoAgent还提供了两个非常实用的辅助命令。

repoagent diff：预览变更影响在正式运行生成或提交之前，你可能想先看看这次代码改动会导致哪些文档被更新或生成。diff命令就是干这个的。

repoagent diff

它会模拟一次run的过程，但不会真正调用 LLM API 生成文档，而是会输出一个报告，列出：

哪些文件被检测到变更（新增、修改、删除）。
这些变更会影响哪些代码对象。
哪些对应的 Markdown 文档将会被新建或更新。

这个功能非常有用，特别是在配置pre-commit之前，或者当你对一次大规模重构的影响范围不确定时，可以先diff一下，做到心中有数，避免意外生成大量不必要的 API 调用。

repoagent clean：清理缓存与生成物随着项目迭代，RepoAgent生成的.project_doc_record文件和markdown_docs文件夹可能会变得过时或臃肿。如果你想从头开始重新生成所有文档，或者切换了 LLM 模型/提示词模板希望得到全新结果，就需要清理旧数据。

repoagent clean

这个命令会删除默认的（或通过-hp、-mdp指定的）项目结构记录文件和 Markdown 文档目录。执行后，再次运行repoagent run将会像第一次一样，重新解析整个仓库并生成全套文档。

注意事项：clean命令是不可逆的。在执行前，请确保你已经备份了markdown_docs目录中任何你手动修改过、不想丢失的文档。一个良好的实践是，将markdown_docs也纳入版本控制（.gitignore中不忽略它），这样文档的历史变更也能被追踪。

4.2 支持本地大语言模型

RepoAgent的架构设计是模型无关的，它通过 OpenAI API 的格式与 LLM 交互。这意味着任何提供了兼容 OpenAI API 接口的模型服务都可以被使用。这为使用本地部署的模型打开了大门，例如Llama 3、ChatGLM、Qwen、GLM-4等。

操作步骤：

部署本地模型 API 服务：你需要先在你的机器或内网服务器上，部署一个能够提供类似 OpenAI API 接口的模型服务。常用的开源工具有：
- Ollama：最简单，开箱即用，支持大量模型，默认 API 端口是11434。
- vLLM：高性能推理框架，特别适合批量推理，API 兼容性好。
- OpenAI-Compatible API 的各种封装：很多项目都提供了将开源模型包装成 OpenAI API 格式的工具。

配置RepoAgent：运行RepoAgent时，通过--base-url参数指定你的本地服务地址，并通过--model参数指定你部署的模型在服务中的名称。

例如，使用 Ollama 运行了llama3:8b模型：

# 假设 Ollama 服务运行在本地默认端口 11434 export OPENAI_API_KEY="ollama" # Ollama 通常不需要真密钥，但需要设置一个非空值 repoagent run --base-url http://localhost:11434/v1 --model llama3:8b

例如，使用 FastChat 提供的兼容 API：

export OPENAI_API_KEY="no-key-required" repoagent run --base-url http://localhost:8000/v1 --model qwen-7b-chat

本地模型的优劣分析：

优势：
- 数据隐私：代码无需离开内网，满足严格的合规要求。
- 成本可控：一次部署，无限次使用，无按 token 计费的压力。
- 定制化：可以使用领域微调过的模型，生成更符合专业术语的文档。
挑战：
- 硬件要求：运行 7B 以上的模型需要可观的 GPU 内存。
- 生成质量：同等参数下，开源模型的代码理解和文本生成能力可能仍与 GPT-4 有差距，可能需要更精细的提示词工程。
- 速度：本地推理速度可能慢于云端 API，尤其是大型模型。

4.3 处理大型仓库与性能优化

当面对像XAgent这样拥有 27 万行代码的大型项目时，直接运行repoagent run可能会遇到 API 调用次数过多、耗时过长的问题。以下是一些优化策略：

分模块初始化：不要试图一口气为整个巨型仓库生成文档。可以先为核心模块或你当前正在开发的模块生成文档。通过--ignore-list参数暂时忽略其他目录。
```
repoagent run --ignore-list “docs/, experiments/, legacy/”
```
等核心模块稳定后，再逐步扩展到其他模块。
利用增量更新的优势：这是RepoAgent面对大型项目的王牌。一旦完成了首次全量生成（可以安排在夜间或周末进行），后续的日常开发完全依赖pre-commit钩子的增量更新。每次提交只处理改动的文件，开销极小。
调整 LLM 模型策略：
- 全量生成用高性价比模型：首次全量生成时，可以使用gpt-3.5-turbo，快速且成本较低，先搭建起文档骨架。
- 关键模块用高质量模型：对于核心、复杂的模块，可以后续单独用gpt-4重新生成或润色文档。可以通过手动删除该模块在markdown_docs中的文档和.project_doc_record中的相关记录，然后使用--ignore-list只针对该模块运行RepoAgent并指定 GPT-4 模型。
控制生成粒度：RepoAgent默认会为每个独立的类、函数生成文档。对于某些内部工具函数非常多且简单的文件，这可能会产生大量细碎的文档。目前版本可能缺少配置生成粒度的参数，但你可以通过后续的提示词定制，来让 LLM 将一些紧密相关的简单函数合并到同一个文档段落中描述。

5. 常见问题排查与实战心得

在实际使用中，你可能会遇到一些典型问题。这里我总结了一份排查清单和个人踩坑经验。

5.1 安装与运行问题

问题现象	可能原因	解决方案
`bash: repoagent: command not found`	1.`pip install`未成功。 2. Python 脚本目录未加入系统 PATH。	1. 检查安装是否成功：`pip show repoagent`。 2. 尝试用`python -m repoagent`代替`repoagent`命令。
`ModuleNotFoundError: No module named ‘xxx’`	依赖包缺失。	重新安装或升级：`pip install --upgrade repoagent`。确保在正确的 Python 虚拟环境中操作。
`openai.AuthenticationError`	`OPENAI_API_KEY`环境变量未设置或设置错误。	1. 检查密钥是否正确：`echo $OPENAI_API_KEY`。 2. 确保在运行`repoagent`的同一个终端会话中设置了环境变量。
`openai.APITimeoutError`或任务卡住	1. 网络问题。 2. API 超时时间设置太短。 3. 模型响应慢（如 GPT-4）。	1. 检查网络连接。 2. 增加`--request-timeout`参数值，如`120`或`300`。 3. 对于大型任务，考虑分批次运行。

5.2 文档生成质量问题

问题现象	可能原因	解决方案与调整方向
生成的文档过于笼统，像模板	1. 模型温度 (`temperature`) 设置过低。 2. 使用的模型能力不足（如`gpt-3.5-turbo`对复杂逻辑理解有限）。 3. 代码本身注释或命名就非常模糊。	1. 尝试将`temperature`微调到`0.3-0.5`，增加一些创造性。 2. 对核心模块换用`gpt-4`模型。 3. 在运行`RepoAgent`前，适当补充关键函数、类的 docstring，为 LLM 提供更多上下文。
文档中 hallucination（幻觉），描述的功能代码中没有	LLM 的固有缺陷，有时会“脑补”。	1.这是最重要的检查环节：生成的文档必须经过人工复核，尤其是核心逻辑部分。 2. 降低`temperature`值（如`0.1`）减少随机性。 3. 在提示词中强调“严格基于给定代码生成描述”。（需要修改`RepoAgent`源码中的提示词模板）
未识别出某些函数或类	1. 代码存在语法错误，导致 AST 解析失败。 2. 文件扩展名不是`.py`或不在扫描范围内。 3. 代码使用了非常动态的特性（如`exec`,`eval`生成的函数）。	1. 确保代码能通过`python -m py_compile your_file.py`检查。 2. 目前主要支持 Python。检查文件是否被`--ignore-list`意外排除。 3. 对于动态生成的代码，`RepoAgent`可能无法处理，需要手动补充文档。
调用关系分析错误	1. 代码中使用了复杂的元编程、装饰器或动态导入。 2. 静态分析的局限性。	1.`RepoAgent`的静态分析在遇到`getattr()`,`globals()[‘func_name’]()`这类动态调用时无能为力。 2. 这是所有静态分析工具的共性问题。对于这类情况，需要在生成的文档中手动修正或补充说明。

5.3 Git 与 pre-commit 集成问题

问题现象	可能原因	解决方案
`pre-commit`钩子未触发	1. 未在仓库根目录执行`pre-commit install`。 2. 提交时使用了`git commit --no-verify`跳过了钩子。	1. 确认`.git/hooks/pre-commit`文件是否存在且可执行。 2. 正常提交不要加`--no-verify`参数。
钩子执行时间过长，影响提交体验	仓库太大，或模型响应慢。	1. 这是增量更新的优势场景，通常只分析改动，速度很快。如果仍慢，检查网络或模型。 2. 可以考虑只在`git push`前通过手动运行`repoagent run`来更新文档，而非每次提交都触发。
钩子执行失败，导致提交中止	`RepoAgent`运行过程中出错（如 API 异常、解析错误）。	1. 根据错误信息排查上述“安装与运行问题”。 2. 临时跳过：本次提交使用`git commit --no-verify`。 3. 修复问题后，记得重新运行`repoagent run`以同步中断期间可能错过的文档更新。
生成的文档没有被自动`git add`	可能是`RepoAgent`在钩子中的执行流程问题。	检查`RepoAgent`的运行日志。正常情况下，它应该会输出类似 “Staging updated documentation...” 的信息。确保`pre-commit`配置中`pass_filenames: false`。

个人心得：将 RepoAgent 融入团队流程引入RepoAgent到团队时，沟通是关键。它不应该被当作一个“完全自动化、无需人工干预”的神器，而应该定位为一个“超级辅助”。

首次引入：可以安排一次简短的分享，演示其如何为某个复杂模块生成基础文档，强调其“快速搭建骨架”和“维护调用关系”的价值。
设定预期：明确告知团队成员，生成的文档需要复核，特别是业务逻辑部分。可以将复核作为 Code Review 的一个环节。
规范提交：鼓励小步提交、频繁提交。这样pre-commit每次处理的变化小，速度快，生成的文档增量也更容易 review。
处理冲突：如果多人同时修改了同一模块并生成了文档，可能会在markdown_docs中产生 Git 合并冲突。解决方式和解决代码冲突一样，需要人工介入，理解改动意图后合并文档内容。

RepoAgent代表了 AI 在软件开发流程中从“玩具”到“工具”的深刻转变。它解决的不是一个炫技的问题，而是一个真实、持久、影响团队效率的痛点——文档的创建与维护。通过将 LLM 的语义理解能力与静态代码分析、版本控制系统紧密结合，它构建了一个可持续的、自动化的文档流水线。这个工具的价值会随着项目规模的增长和时间的推移而愈发凸显。开始尝试用它来管理你的下一个项目吧，你会发现，拥有一个随时与代码同步的、结构化的项目知识库，会让阅读和理解代码这件事，变得前所未有的轻松。

查看全文

http://www.cnnetsun.cn/news/2093601.html