ARTICLE DETAIL

建站实战干货

来自一线的建站与推广经验沉淀,每一条都经过真实交付验证。

Zed zed-eval 深度指南:用 Python CLI 编排 Zed Agent 的 Modal/Harbor/Pier 基准评测

2026/9/7 17:19:54 拓冰建站 浏览量
Zed zed-eval 深度指南:用 Python CLI 编排 Zed Agent 的 Modal/Harbor/Pier 基准评测 Zed zed-eval 深度指南用 Python CLI 编排 Zed Agent 的 Modal/Harbor/Pier 基准评测【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed本文基于 Zed 仓库中 crates/eval_cli/zed_eval/README.md 展开系统讲解zed-eval这一 Python CLI 与已安装 Agent 包的完整用法从本地安装、Modal 部署到按内容寻址构建 headlesseval-cli二进制、在 Modal/Harbor/Pier 上发起 SWE-Atlas、Terminal-Bench、DeepSWE 等基准评测再到监控、取回结果、重判rejudge与基线baseline管理。读完后你既能复制可运行的全部命令与参数也能结合 zed_eval 源码理解其注册表、判官配置与沙箱 Agent 适配的实现细节。zed-eval 是什么两层评测架构Zed 的评测体系分为两层Rust 层eval-cli二进制。无头headless运行 Zed Agent 的可执行程序供容器化评测框架Harbor、Pier直接调用其独立文档见 crates/eval_cli/README.md。它复用与生产版 Zed 编辑器相同的NativeAgentAcpThread管线具备完整的工具调用、子 Agent 与重试能力只是没有 GUI。Python 层zed_eval包即本文主题。提供zed-eval命令行工具负责在本地构建/复用eval-cli构建产物、在 Modal 上编排远程评测运行、监控与取回结果同时暴露 Harbor/Pier 的已安装 Agent 类供远程编排器在沙箱内驱动eval-cli。从 pyproject.toml 可以看到该包的定位与依赖约束[project] name zed-eval version 0.2.0 description Harbor agent wrapper and remote orchestration CLI for Zeds eval-cli requires-python 3.12 dependencies [harbor0.15.0, modal1.5.0] [project.scripts] zed-eval zed_eval.cli:main即 Python 3.12 环境锁定harbor0.15.0与modal1.5.0入口为 cli.py 中的main()。README 明确建议大多数基准评测用户应从zed-eval入手而不是直接调用eval-cli。快速开始安装、体检、部署、小批量试跑以下命令均假设在仓库根目录执行。安装 CLIcrates/eval_cli/script/install-zed-eval该脚本见 install-zed-eval等价于uv tool install --editable crates/eval_cli/zed_eval --force因此安装后的zed-eval命令以可编辑模式跟踪 checkout 中的代码变更无需设置PYTHONPATH。如果不想全局安装也可以直接以源码方式运行crates/eval_cli/script/zed-eval doctor体检与创建共享卷zed-eval doctor --create-volume从 cli.py 的command_doctor实现看doctor会依次检查本地git、modal、harbor三个可执行文件是否存在Modal 工作区中是否存在两个默认 secret见下节缺失时给出--api-secret/--modal-token-secret或modal secret create的修复提示打印默认值一览namespace、app 名、volume 名、secret 名、仓库根、当前 base SHA、默认模型与默认判官qnadeepseek-v4-pro, rf/twkimi-k2.7-code。--create-volume会顺便创建共享 Modal 卷。部署 Modal 应用zed-eval deploy在首次发起运行前必须部署一次之后每当修改了 Python 编排代码zed_eval包内的控制器逻辑也要重新部署。README 特别警告部署会替换线上应用并可能取消进行中的运行因此评测活动进行中要避免执行。deploy是唯一会部署的命令其余命令只调用已部署函数。发起一个小批量运行并观察结果zed-eval run rf --from local --n-tasks 2 zed-eval runs # 本机上最近发起的运行本地索引无网络调用 zed-eval status # 最近一次运行的状态 zed-eval logs run-id # 控制器日志 zed-eval report run-id --fetch运行发起后本地运行索引会记住该运行的 namespace 与 benchmark 名因此多数命令只需要 run id如果运行是在别的机器发起的则需要显式传--experiment-name必要时加--namespace。从 run_index.py 看这个索引是刻意设计为“尽力而为”的每次发起运行时写入一条把 run id 映射到卷上位置namespace experiment及少量元数据的记录默认上限 500 条可用AGENT_EVALS_RUN_INDEX覆盖位置索引缺失、不可读或不可写时既不阻塞发起也不导致查询崩溃查不到的命令会回退到显式的--experiment-name/--namespace标志并给出友好提示。运行包测试开发uv run --project crates/eval_cli/zed_eval python -m unittest discover -s crates/eval_cli/zed_eval/tests测试目录 tests 覆盖了 benchmark 注册表test_benchmarks.py、发起逻辑test_launch.py、源解析test_source.py、rejudgetest_rejudge.py、报告test_report.py、运行索引test_run_index.py、基线test_baseline.py等模块可对照验证上文所述行为。前置条件Modal 工作区与两个 secret使用zed-eval需要对用于评测的 Modal 工作区的访问权限控制器用的 Modal token secret默认名agent-evals-modal-token存放 Agent/判官 API key 的 LLM provider secret默认名agent-evals-llm-providers。两个 secret 的内容要求与 config.py 中的默认名一一对应控制器 secret应包含MODAL_TOKEN_IDMODAL_TOKEN_SECRETLLM provider secret应包含所选模型所需的 key例如ANTHROPIC_API_KEYOPENAI_API_KEYBASETEN_API_KEY默认名可在全局参数层覆盖zed-eval \ --volume agent-evals \ --api-secret agent-evals-llm-providers \ --modal-token-secret agent-evals-modal-token \ doctor这些默认值在 config.py 中集中定义DEFAULT_VOLUME_NAME agent-evals、DEFAULT_LLM_PROVIDERS_SECRET_NAME agent-evals-llm-providers、DEFAULT_MODAL_TOKEN_SECRET_NAME agent-evals-modal-token并且全部支持环境变量覆盖AGENT_EVALS_VOLUME、AGENT_EVALS_LLM_PROVIDERS_SECRET、AGENT_EVALS_MODAL_TOKEN_SECRET、AGENT_EVALS_APP_NAME见 cli.py 的add_common_options。发起基准评测run 命令与 benchmark 注册表非交互发起zed-eval run# 一个 SWE-Atlas part zed-eval run rf --from local --n-tasks 5 # 多个 benchmark 在可能时共享一次构建 zed-eval run swe-atlas terminal-bench-2.1 --from v0.210.0 --n-tasks 5 --yes # DeepSWE 自动在 Pier 下运行 zed-eval run deepswe --from local --n-tasks 10 # 只查看将要发生什么不实际发起 zed-eval run swe-atlas --from v0.210.0 --plan zed-eval run deepswe --from local --dry-run--plan打印简明的发起计划加--verbose可展开完整 manifest 与 harness 命令--dry-run打印完整 manifest 与 harness 命令两者都不实际发起运行。支持的 benchmark 选择器选择器含义计分方式swe-atlasqna、rf、tw三部分的组LLM judgeqna/swe-atlas-qnaSWE-Atlas Codebase QALLM judgerf/swe-atlas-rfSWE-Atlas RefactoringLLM judgetw/swe-atlas-twSWE-Atlas Test WritingLLM judgeterminal-bench-2.1/tb21Terminal-Bench 2.1测试脚本deepsweDeepSWE测试脚本注册表背后的实现新增 benchmark 只是一次“数据变更”benchmarks.py 的模块文档说明Benchmark数据类描述编排器端到端运行一个 benchmark 所需的一切“与构建源和模型无关”的信息——由哪个 harness 运行Harbor 或其 Pier fork、数据集如何供给、trial 如何计分、是否需要 LLM 判官、单任务超时。它强调“新增 benchmark 应当是这里的一次数据变更而不是新的控制流”。注册表中每个条目的关键字段harnessharbor或pier。DeepSWE 选择 Pier因为 Pier 是带“按 Agent 网络白名单”的 Harbor fork而 DeepSWE 任务以allow_internet false运行必须靠白名单放行模型 API 主机api.anthropic.com、api.openai.com、inference.baseten.co。dataset三种供给方式——registry从 harness hub 拉取如scale-ai/swe-atlas-qna、terminal-bench/terminal-bench-2-1、path由控制器克隆 git 仓库后按目录供给如 SWE-Atlastw部分使用data/tw目录、pier_path在 Pier 下运行的 path 数据集如 DeepSWE 的tasks目录。scoring / needs_judge / default_judgerubric-judgeSWE-Atlas 三部分配 LLM 判官testsTerminal-Bench 2.1、DeepSWE由测试脚本计分不需要判官。default_timeout_secsqna 7200srf/tw 3300sterminal-bench-2.1 3300sdeepswe 7200s。env对 Terminal-Bench 2.1 与 DeepSWE 这类断网任务注册表注入ZED_EVAL_DISABLE_TOOLSfetch,search_web禁用在无法联网时必然失败的抓取/搜索工具避免 Agent 把预算浪费在注定失败的调用上该变量经 agent_common.py 的add_zed_eval_env传入沙箱。选择器解析同样在 benchmarks.py 中BENCHMARK_GROUPS把swe-atlas展开为三个部分BENCHMARK_ALIASES提供短名qna/rf/tw/tb21resolve_benchmarks支持逗号分隔与重复传参并去重保序。交互式发起zed-eval swe-atlas --interactive尽管命令名叫swe-atlas交互流程实际可以发起 SWE-Atlas 各部分、Terminal-Bench 和 DeepSWE。非交互场景请用runrun会为每个 benchmark 自动选择正确的默认判官且从不提示输入。选择源码与构建内容寻址的 eval-cli 构建--from决定把什么源码构建成eval-cli--from local构建当前HEAD加已跟踪tracked变更--from ref/tag/sha构建干净的 git ref、tag 或 SHA。构建是内容寻址的相同内容会自动复用。也可以显式命名或复用某个构建zed-eval build --from local zed-eval run rf --build bld-abc123 --n-tasks 2 zed-eval builds --details未跟踪文件untracked files不会进入构建。如果它们与评测无关可显式放行zed-eval run rf --from local --allow-untracked --n-tasks 2追求可复现的运行应使用干净的 ref/tag/SHA或要求已跟踪树干净zed-eval run rf --from v0.210.0 --n-tasks 2 zed-eval run rf --from local --require-clean --n-tasks 2从 cli.py 的add_build_source_options还可以看到更多构建源选项--base-sha、--patch-path、--repo-urlModal 构建器拉取 base SHA 的远端默认 source.py 中的AGENT_EVALS_REPO_URL或仓库规范地址、--clean-source与--zed-version精确构建某个 git ref/tag/SHA 的干净源码快照不带本地补丁。--from的默认值也可由AGENT_EVALS_FROM环境变量提供--from main表示构建origin/main的最新提交且 ref/tag/SHA 会对照远端做规范化解析使团队成员共享同一个构建。在 Modal 侧构建目标为x86_64-unknown-linux-musl构建信息以agent-evals-build-v3schema 记录见 source.py 顶部的BUILD_SCHEMA_VERSION、BUILD_TARGET等常量卷上的每个构建目录含eval-cli、build-info.json、source-info.json、source.patch四个文件见下文“存储模型”。选择模型与判官Agent 模型默认 Agent 模型为sonnet-4.6即anthropic/claude-sonnet-4-6config.py 的DEFAULT_MODEL。常用示例zed-eval run rf --model sonnet-4.6 --n-tasks 2 zed-eval run rf --model opus-4.5 --n-tasks 2 zed-eval run rf --model baseten:kimi-k2.7-code --n-tasks 2 zed-eval run rf --model baseten:deepseek-v4-pro --n-tasks 2config.py 的MODEL_PRESETS定义了这些简写到provider/model的映射sonnet-4.6/claude-sonnet-4.6→anthropic/claude-sonnet-4-6、sonnet-4.6-latest→anthropic/claude-sonnet-4-6-latest、opus-4.5→anthropic/claude-opus-4-5、baseten:kimi-k2.7-code→baseten/moonshotai/Kimi-K2.7-Code、baseten:deepseek-v4-pro→baseten/deepseek-ai/DeepSeek-V4-Pro不在表中的字符串按原样作为provider/model传给eval-cli。Baseten 预设会自动生成 OpenAI 兼容的 provider 配置BASETEN_API_URL https://inference.baseten.co/v1provider id 为baseten沙箱 secret 中必须包含BASETEN_API_KEY。--model也可配合AGENT_EVALS_MODEL环境变量取默认值。CLI 还提供了更底层的模型路由选项--model-provider zed|baseten、--baseten-model、--baseten-api-url、--baseten-model-max-tokens默认 262144、--baseten-model-max-output-tokens默认 65536、--openai-compatible-provider-json、--anthropic-available-models-jsonREADME 建议对 Baseten 优先使用--model baseten:model-id简写。判官judge预设SWE-Atlas 的默认判官策略是--judge autoqnadeepseek-v4-prorf与twkimi-k2.7-code需要时可覆盖zed-eval run rf --judge leaderboard --n-tasks 2 zed-eval run rf --judge deepseek-v4-pro --judge-model deepseek-ai/DeepSeek-V4-Proconfig.py 的JUDGES字典给出了全部预设的完整定义预设判官模型上游认证环境变量max_tokensleaderboard/opus-leaderboardclaude-opus-4-5-20251101Anthropic API/v1ANTHROPIC_API_KEY不设置保持 verifier 硬编码 2048deepseek-v4-pro/deepseekdeepseek-ai/DeepSeek-V4-ProBasetenBASETEN_API_KEY8192kimi-k2.7-code/kimimoonshotai/Kimi-K2.7-CodeBasetenBASETEN_API_KEY8192gpt55gpt-5.5-2026-04-23OpenAI API/v1OPENAI_API_KEY不设置源码注释解释了max_tokens的设计意图Baseten 判官设置 8192 是为了让运行时判官与离线校准一致ZED_JUDGE_MAX_TOKENS由沙箱内判官 shim 应用leaderboard/opus 路径刻意留空使判官保持在 verifier 硬编码的 2048以“忠于 leaderboard 条件”。判官在沙箱内通过本地代理http://127.0.0.1:8089/v1调用EVAL_BASE_URL_IN_SANDBOX由judge_verifier_args生成--verifier-import-path zed_eval.verifier:ZedJudgeProxyVerifier及EVAL_MODEL/ZED_JUDGE_UPSTREAM/ZED_JUDGE_AUTH_ENV等注入参数。监控、取回与报告常用命令zed-eval runs # 本地、快速的最近运行列表 zed-eval list --details # 查询 Modal 卷上的运行 zed-eval list -e swe-atlas-rf --details zed-eval status run-id zed-eval logs run-id zed-eval fetch run-id zed-eval report run-id --fetchruns只读本机运行索引最新在前、无网络调用适合“我最近发起了什么”list --details则查询卷上的运行状态可加-e experiment-name过滤、--all-namespaces跨 namespace 查询status打印一次state.jsonlogs打印一次controller.log两者都允许省略 run id 而默认取本机最近一次运行fetch下载运行归档并解压到~/.cache/harbor/jobs/run-id/可用--jobs-dir覆盖report输出通过率pass rate以及 token 消耗、工具调用次数、Agent 步数等资源指标--json输出机器可读格式。从 report.py 与 cli.py 可以看到报告的几个细节通过率附带误差估计pass_ratepass_sem--timeouts-as-failures控制超时是否计为失败——默认auto行为下对 Terminal-Bench、DeepSWE 这类“测试计分”基准超时自动计为失败report也可以直接分析本地目录--job-dir/--jobs-dir。多 benchmark 套件suite一条命令发起多个 benchmark 时各运行会按一个suite_id分组该 id 存储在每条运行上zed-eval run qna rf terminal-bench-2.1 --from local --n-tasks 2 --yesrun命令可用--suite-id显式指定组 id见 cli.pylaunch.py 中mint_suite_id会在未显式指定时生成。套件级命令对该组内所有运行生效zed-eval suite status suite-id zed-eval suite logs suite-id zed-eval suite fetch suite-idsuite logs支持--follow与--interval默认 30s持续跟踪。重新判分rejudge只重跑 judge不重跑 Agentrejudge通过只重跑判官来创建一个派生运行它复用父运行中已经产出的 Agent 工作成果补丁/答案不重做 Agent 工作也不修改父运行zed-eval rejudge parent-run-id --judge deepseek-v4-pro zed-eval rejudge parent-run-id --judge kimi-k2.7-code --dry-run zed-eval report derived-run-id --fetch若父运行不在本机运行索引中需传--experiment-name必要时加--namespace--parent-namespace可指定父运行所在 namespace--new-run-id可指定派生运行 id默认为parent-rejudge-judge-rand。rejudge.py 的模块文档澄清了实现边界它刻意不是对评分器的重新实现而是原样运行每个任务包自带的 SWE-Atlas 校验脚本——RF 用evaluate_rubrics.py、QnA 用evaluate_answer.py哪个脚本存在就用来区分任务类型并走与沙箱内在线路径相同的判官代理 shimjudge_proxy.JUDGE_PROXY_SCRIPT因此重判结论与首轮结论以完全相同的方式产生唯一差异是判官模型。由于这些校验脚本从固定绝对路径/tests、/logs/...读输入并从EVAL_MODEL/EVAL_BASE_URL/EVAL_API_KEY取判官配置rejudge 控制器被设计为在一次性容器Modalrejudge_controller内运行。基线baseline-of-record基线命令用于记录与查看“已完成、干净提交运行”的基准参照结果zed-eval baseline record run-id --experiment-name swe-atlas-rf zed-eval baseline list zed-eval baseline show swe-atlas-rf --model anthropic/claude-sonnet-4-6从 cli.py 的baseline子命令定义看record会把一次或多条已完成运行提升为其 (benchmark, model) 组合的“记录基线”并默认要求构建来自干净提交且 base SHA 可从origin/main到达两个逃生舱口--allow-dirty构建携带本地补丁非干净提交时也记录--allow-off-main无法验证 base SHA 可从 origin/main 到达时也记录--repo-url指定用于解析 origin/main 的远端默认AGENT_EVALS_REPO_URL或规范仓库。baseline list列出每个 (benchmark, model) 的当前记录基线支持--jsonbaseline show experiment-name --model model查看单条记录--history可包含已被取代的历史基线。存储模型共享 Modal 卷上的构建与运行运行与构建都存放在共享 Modal 卷上目录结构如下与 volume.py 中的路径拼接runs/{namespace}/{experiment_name}/{run_id}、builds/build-id一致builds/build-id/ eval-cli build-info.json source-info.json source.patch runs/namespace/experiment-name/run-id/ request.json state.json controller.log harbor-command.txt run-metadata.json harbor-job.tar.gz summary.json安全提示README 原文强调namespace 只是防止无意碰撞不是访问控制。任何能访问该 Modal 工作区/卷的人都能读取运行清单、日志、补丁与归档。独立使用 eval-cli本地或自定义 harness不经过zed-eval编排也可以直接构建并调用 Rust 二进制# 为当前平台构建 cargo build --release -p eval_cli # 构建 Harbor/Pier 沙箱使用的 Linux x86_64 二进制 crates/eval_cli/script/build-linuxbuild-linux 脚本用 Docker cargo-zigbuild 交叉编译出x86_64-unknown-linux-musl静态二进制可通过--output指定输出路径默认target/eval-cli可运行在任意 Linux 发行版glibc 或 musl/Alpine。直接运行示例eval-cli \ --workdir /testbed \ --model anthropic/claude-sonnet-4-6 \ --instruction Fix the bug described in... \ --timeout 600 \ --output-dir /logs/agenteval-cli从环境变量读取 provider API keyANTHROPIC_API_KEY、OPENAI_API_KEY等并向输出目录写入result.json、thread.md、thread.json。退出码约定退出码含义0Agent 正常结束1出错模型/认证/运行时失败等2超时3被 SIGTERM 或 SIGINT 中断作为 Harbor/Pier 已安装 Agent 使用Python 包同时暴露供远程编排器使用的已安装 Agent 类zed_eval.agent:ZedAgent—— Harborzed_eval.pier_agent:ZedPierAgent—— Pier手动做本地 Harbor 实验配合本地构建的 Linux 二进制pip install -e crates/eval_cli/zed_eval/ crates/eval_cli/script/build-linux harbor run -d swebench_verifiedlatest \ --agent-import-path zed_eval.agent:ZedAgent \ --ae binary_pathtarget/eval-cli \ --ae EVAL_CLI_TIMEOUT600 \ -m anthropic/claude-sonnet-4-6agent.py 的ZedAgent值得细看它解释了“已安装 Agent”在沙箱内到底做了什么二进制来源三选一--ae EVAL_CLI_CONTAINER_PATH容器内路径Modal 可把预构建二进制挂载进每个沙箱免去上传、binary_path本地文件上传到/usr/local/bin/eval-cli、download_url或EVAL_CLI_DOWNLOAD_URL容器内 curl 下载装入后先跑eval-cli --help自检环境准备安装基础依赖apt/apk/dnf/yum 分支处理、Node.js v22.14.0Alpine 用 musl 构建、按 npm 预装 LSPbasedpyright、typescript-language-server、vtsls、tailwindcss-language-server、自编译 eslintGo 存在时装 gopls 并有 120s 超时保护、uv ruff全部工具安装均为尽力而为单个失败不阻塞 trialworkdir 探测优先EVAL_CLI_WORKDIR覆盖否则依次探测/app、/testbed、/repo中的 git 目录再find / -maxdepth 3 -name .git兜底见 agent_common.py 的detect_workdir超时协商ZedAgent会重放 Harbor 0.15.0 的外层 Agent 预算计算从 trialconfig.json与任务task.toml的agent.timeout_sec推导使eval-cli --timeout比 Harbor 的协程强杀早 45sEVAL_CLI_FINALIZE_BUFFER_SEC到期保证日志与部分答案在 Agent 被杀前落盘EVAL_CLI_TIMEOUT可显式封顶退出码处理退出码 2超时被视为“可判分的轨迹”而非崩溃包装命令会打印超时消息并继续进入交付/校验阶段eval_cli_with_log_command用“子 shell 状态文件 tee”的写法确保管道不掩盖eval-cli的退出状态产物归集运行结束后把result.json、thread.json、thread.md、eval-cli.txt复制到/logs/artifacts/并通过patch_command在 workdir 生成patch.diffgit add -A git diff --cached HEAD无 HEAD 或非 git 目录时安全跳过populate_context_from_result再从result.json提取input_tokens、output_tokens、cache_read_input_tokens、step_count与tool_call_count回填给 Harbor 的AgentContext。编排参数速查从 cli.py 实现补充除 README 覆盖的参数外cli.py 中还有几个对实操重要的默认值均可从 config.py 溯源--n-concurrent默认 25。注释解释了为何刻意保守——真正的瓶颈是 Agent 模型 API 的速率限制而非 Modal 容量约 150 个并发 Agent 循环曾打爆速率上限确认模型速率有富余前不要调高--sandbox-timeout-secs默认 14400s4 小时--sandbox-idle-timeout-secs默认 300s--eval-cli-timeout覆盖单任务 Agent 超时默认取 benchmark 注册表值--override-cpus/--override-memory-mb默认None即完全交给每个任务声明的资源SWE-Atlas 任务声明 16 CPU / 16 GB往下覆盖会导致内存密集任务被 OOM 杀掉exit 137并改变实验条件需显式传入才生效--staff远程运行默认关闭 staff 模式因为该模式启用的沙箱终端在 Modal 沙箱中会挂起cleanup命令修剪过期构建与冷构建缓存默认保留 14 天--dry-run只报告不删除从不删除评测结果。小结zed-eval把 Zed Agent 的基准评测收敛为一条清晰的流水线本地doctor体检与 secret 校验 →deploy发布 Modal 控制器 → 内容寻址构建eval-cli--from local或干净 ref可复现、可共享→run按注册表发起 Harbor/Pier 评测benchmark 选择器、模型预设、判官预设全部数据化→runs/status/logs/fetch/report监控与报告 →suite/rejudge/baseline完成分组观察、只重判不重跑与记录基线。所有默认值volume、secret、模型、判官、并发、超时都集中在 config.py 且可用全局参数或AGENT_EVALS_*环境变量覆盖而沙箱内的实际执行由 agent.py 的ZedAgent/ZedPierAgent完成把eval-cli的启动、超时协商、产物归集与退出码语义封装成 Harbor/Pier 可直接消费的已安装 Agent。【免费下载链接】zedCode at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.项目地址: https://gitcode.com/GitHub_Trending/ze/zed创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考