欢迎光临
我们一直在努力

对比 4 款 国产AI 工作台,WorkBuddy 、QoderWork 、Kimi Work 、TRAE 怎么选

一人公司按中文办公、文件自动化、研究数据、产品代码四类任务路由到四款 AI 工作台,并统一按交付闭环验收

WorkBuddy、QoderWork、Kimi Work、TRAE Work 都在争夺“AI 工作台”这个位置。模型参数看起来最热闹,但我真正关心的只有一件事:交给 AI 的任务,最后能不能变成可打开、可修改、可验收的文件。

我的判断是,2026 年 AI 办公工具的竞争正在从“谁回答得更像人”转向“谁能把任务做完”。我把 WorkBuddy、QoderWork、Kimi Work、TRAE Work 放在同一把尺子上,不比较模型榜单,只比较它们能否把目标拆解、调用工具、修改文件、交付产物并留下可验收证据。先说清楚证据边界:这是一篇基于截至 2026-07-18 官方公开能力的选型框架,不是同任务实测总榜;最后的结论不是谁最强,而是一人公司该把哪类工作交给谁。

一、4 款工具为什么突然都叫 Work:从回答到交付

我先对照了两类近期横评:一类把 WorkBuddy、QoderWork、Kimi Work、TRAE Work 放进同一张功能清单,帮助读者识别定位;另一类让多款桌面 Agent 跑同场景任务,观察复杂任务如何拉开差异。四款 Work 产品盘点 · 新榜同场景实测

但我没有直接照搬这些文章的星级、效率数字和胜负结论。本文把证据拆成三层:**产品能力只认官方页面和官方文档;测试方法参考第三方横评;任务路由、试用优先级和验收线明确属于我的判断。**这样既能借鉴别人已经踩过的测试坑,又不会把二手评价写成产品事实。

这 4 款工具的官方定位其实已经把答案写得很直白。

工具官方强调的工作方式我对它的第一定位
WorkBuddy 自然语言下达任务,自主规划执行,处理本地文件并交付文档、表格、PPT、报告等成果 面向中文办公生态的综合调度台
QoderWork 从文件处理、浏览器自动化、桌面控制到定时任务,把需求直接落到电脑操作 擅长本地批处理与跨应用执行的桌面助手
Kimi Work 连接本地文件、浏览器、代码与定时任务,用 Goal 模式持续推进长任务 偏研究、数据与长周期目标的本地 Agent
TRAE Work 在统一 Workspace 中连接文档、数据、演示和代码,并在云端并行执行任务 把产品工作与开发工作放在一起的云端工作区

WorkBuddy 官方把核心过程概括为“说出要求、开始执行任务、交付完整成果”,结果区可以直接查看 Word、Markdown、PDF、Excel、CSV、PPT、分析报告、网页预览和代码变更。WorkBuddy 简介 · 结果查看

QoderWork 的官方文档把能力拆得更细:文件处理、浏览器自动化、桌面控制、定时任务、IM 频道、Skills、MCP 和第三方连接器都在同一条任务链里。它的文件操作在本地完成,需要模型理解的相关文本会发送给模型服务商,访问范围则受授权目录限制。QoderWork 官方简介

Kimi Work 走的是“本地执行 + 长任务”路线。官方资料显示,它能读写本地文件、运行 Python 与 Shell、通过 WebBridge 操作网页,并用 Goal 模式跨多轮推进任务;产物可以写回本地工作区,包括演示文稿、工作表、报告和代码库变更。Kimi Work 官方介绍

TRAE Work 则把 Work 与 Code 做成双模式,支持桌面、Web 与移动端协同。官方页面列出的输入包括 .docx、.csv、.pptx 和 Python 脚本,任务由云端并行推进,所有项目文件留在统一 Workspace 中继续审阅和修改。TRAE Work 官方页面 · 产品发布说明

我因此决定不做“谁的模型更聪明”的比较。模型会换,额度会变,活动价会过期;真正决定工具能不能进入日常生产的,是它有没有跨过从回答到交付的那条线。

二、我只用一把尺子:执行闭环,而不是模型参数

聊天机器人完成的是一次回答,工作台完成的是一条任务链。我把这条链拆成 5 个检查点:

  • 目标:它能不能理解我要的最终结果,而不只是回答当前问题?
  • 规划:它能不能把复杂任务拆成有先后关系的步骤?
  • 执行:它能不能读取文件、运行工具、操作网页或调用外部服务?
  • 交付:它能不能输出真实文件,而不只是贴一段 Markdown?
  • 验收:它能不能展示变更、来源、运行结果或失败原因,让我判断任务是否完成?
  • 一人公司按中文办公、文件自动化、研究数据、产品代码四类任务路由到四款 AI 工作台,并统一按交付闭环验收

    图 1 · 任务重心决定先试哪款工作台:中文办公与综合调度看 WorkBuddy,本地文件与桌面动作看 QoderWork,研究与长任务看 Kimi Work,产品与代码协同看 TRAE Work;最终都要经过“目标—规划—工具调用—真实产物—验收/日志”闭环。(来源:WorkBuddy 官方文档、QoderWork 官方简介、Kimi Work 官方介绍、TRAE Work 官方页面;AIFlowLearn 使用 ImageGen 重绘,非官方架构图,事实快照为 2026-07-18)

    这 5 步里,前 3 步决定 AI 能不能动手,后 2 步决定结果能不能进入生产。很多工具在演示里能生成一页漂亮内容,却没有文件目录、修改记录、数据来源和失败状态。这样的结果适合看,不适合接着干活。

    我给自己设了一条很硬的判断:

    交付价值 = 可用产物 × 可验证性 × 可重复性 ÷ 人工接管次数。

    这是我的选型公式,不是行业 benchmark。它故意不放模型分数,因为一人公司的瓶颈通常不是少答对一道题,而是一个人要在调研、写作、数据、设计、开发、发布之间不断切换。AI 每把任务推回给人一次,切换成本就重新发生一次。

    近期一篇针对百度搭子、QoderWork、WorkBuddy、Kimi Work 的同场景测试也暴露了同样的问题:初级信息搜集与整理的交付质量整体都不错,进入基于历史材料做定向判断、重新组织页面和生成更贴合账号的选题时,工具之间才出现明显分化。这篇测试只用于说明“复杂任务更能拉开差异”,不构成本文 4 款产品的实测结论。新榜实测文章

    这意味着“问一个问题,看谁答得好”已经测不出工作台的真实能力。真正应该测的是:给它一份杂乱输入、一个明确产物和一组验收标准,它能不能自己走完中间那段脏活。

    我的判断

    模型决定单步上限,执行系统决定任务能不能走到最后。对一人公司而言,后者更稀缺,因为你的时间不是耗在想不到答案,而是耗在复制、整理、校对、改格式、找文件和重新开一个工具。

    三、4 款工具放进同一张任务地图,差异才真正出现

    功能列表会把所有工具写得越来越像。换成任务地图后,差异集中在 4 个位置:执行发生在哪里、能碰到哪些上下文、如何持续运行、产物怎么回到工作流。

    维度WorkBuddyQoderWorkKimi WorkTRAE Work
    主要执行面 授权的本地文件、内置工具、Skills、MCP、连接器与 IM 渠道 本地文件、浏览器、桌面应用、连接器与 IM 渠道 本地文件、Python/Shell、WebBridge、插件与专业数据源 统一云端 Workspace,覆盖桌面、Web、移动端和 Work/Code 双模式
    公开强调的产物 文档、表格、PPT、分析报告、网页、代码变更 文档、表格、演示文稿、PDF、可视化与文件整理结果 PPT、工作表、报告、代码与本地文件变更 文档、数据分析、演示、代码、代码 Wiki 与互动项目
    持续执行方式 本地自动化任务;专家团拆解、并行执行并整合交付 本地定时任务;可调用 Skills、MCP、连接器和文件系统 Goal 模式、Scheduled Tasks 与 Agent Swarm 云端后台并行任务,跨设备查看进度和继续审阅
    扩展方式 技能市场、自定义 Skill、自定义 MCP、连接器、专家与专家团 社区技能、自定义工作流、MCP、第三方连接器 插件市场、MCP、OAuth、WebBridge 与原生专业数据 更深的工具集成与多种交付格式;官方页面强调统一 Workspace
    我会优先交给它的角色 综合运营台、内容项目经理、中文协同入口 本地资料管理员、桌面自动化执行者 研究员、分析师、长任务推进者 产品经理与开发者共用的项目工作区

    这张表只比较官方公开的功能边界,不代表独立性能跑分。对我而言,最有价值的不是哪一列勾得最多,而是每款工具都形成了不同的“工作重心”。

    下面四个小标题和“更像谁”的描述,都是我基于公开能力给出的作者定位,不是产品官方自称;真正的胜负仍要回到第五节的同任务实测。

    WorkBuddy:更像一人公司的综合调度台

    WorkBuddy 的优势不是单项能力看起来多,而是把专家、专家团、Skills、MCP、连接器、项目和产物区放在一起。专家负责方法和角色,Skill 负责具体动作,专家团负责拆解与协作,结果区负责检查最终文件。它还把微信、企业微信、QQ、飞书、钉钉和小程序放进远程入口,适合中文工作环境里“人不在电脑前,任务还要继续推进”的场景。WorkBuddy 专家说明 · 连接器说明

    WorkBuddy 以本地工作空间为中心,连接 AI 专家团、Skills、MCP、连接器和 IM,并按团长拆解、专家并行、整合交付完成任务

    图 2 · WorkBuddy 的公开能力可以理解为一个综合调度台:本地工作空间承载任务与产物,专家团负责拆解协作,Skills、MCP、连接器与 IM 扩展执行入口,最终交付文档、表格、PPT、报告、网页或代码变更。(来源:WorkBuddy 官方产品页、专家与专家团、连接器说明、结果查看;AIFlowLearn 使用 ImageGen 重绘,非官方架构图)

    我会把它当作总控,而不是要求它在研究、代码、设计每一项都拿第一。对一人公司来说,总控的价值是减少窗口切换、文件搬运,以及把同一段背景重复讲给不同工具。

    **待实测问题:**专家团的并行协作能否稳定减少人工分配,以及研究、文件、代码等多类产物汇总后是否保持事实一致。

    QoderWork:本地脏活和跨应用动作更值得关注

    QoderWork 官方把桌面控制写进了核心能力:点击、输入、滚动,与屏幕上的应用交互;浏览器自动化则负责导航、填表和提取数据。再加上授权目录、本地文件操作、定时任务和连接器,它很适合接那些规则明确但人工做起来很烦的任务,例如批量整理合同、把多张表合并成报告、定时抓取后台数据并保存到指定目录。QoderWork 官方简介 · 定时任务说明

    QoderWork 在授权目录中连接本地文件、浏览器自动化、桌面控制、定时任务以及 Skills、MCP 和连接器

    图 3 · QoderWork 更像桌面执行者:任务进入授权目录后,可串联本地文件、浏览器自动化、桌面控制、定时任务与扩展能力,执行进度可见,结果写回文件。(来源:QoderWork 官方产品页、官方简介、定时任务说明;AIFlowLearn 使用 ImageGen 重绘,非官方架构图)

    我不会因为它也能写 PPT,就把它定义为“另一个 PPT 工具”。它更有辨识度的地方,是能把文件、网页和桌面应用串成动作链。

    **待实测问题:**跨应用动作在连续运行中的稳定性、失败后的恢复方式,以及批量文件改动能否留下完整映射与回滚证据。

    Kimi Work:长任务与专业研究是它最清楚的锚点

    Kimi Work 的 Goal 模式会在每轮结束时判断任务是完成、阻塞、暂停,还是继续,并允许用户把验收证据、范围、时间和资源限制写进目标。官方还把 WebBridge、定时任务、插件、金融与学术数据源放进同一产品,适合“资料很多、路径不确定、需要多轮探索”的任务。Kimi Work 官方介绍

    Kimi Work 连接本地文件、Python、Shell、WebBridge、Goal 模式、Cron、Agent Swarm 与专业数据,持续推进研究任务

    图 4 · Kimi Work 的公开能力更贴近研究长任务:从目标出发,跨多轮调用网页与本地执行环境,再把结果写成 PPT、表格、报告或代码变更。(来源:Kimi Work 官方产品页、官方介绍;AIFlowLearn 使用 ImageGen 重绘,非官方架构图)

    如果我要做一份需要查网页、读本地报告、运行数据处理、交付 Excel 和 PPT 的行业研究,我会先把 Kimi Work 放进候选。原因不是一句“研究强”,而是它公开展示的任务结构更接近研究工作的真实链路。

    **待实测问题:**Goal 模式在长任务中能否按验收标准收敛,多来源研究在多轮推进后是否仍能保持引用与结论一致。

    TRAE Work:把产品和开发放在一个 Workspace

    TRAE Work 的官方案例同时包含文献综述、数据趋势分析、演示文稿、代码 Wiki、网站和游戏。它把 Work/Code 做成双模式,再用云端 Workspace 承载文件、反馈、结果和跨设备进度。TRAE Work 官方页面

    TRAE Work 在统一云端 Workspace 中连接 Work 与 Code 双模式、后台并行任务及桌面 Web 移动端审阅

    图 5 · TRAE Work 把资料、Work 规划与 Code 实现放在统一云端 Workspace,并允许后台任务并行推进、跨设备查看和继续审阅,适合产品与代码强耦合的项目。(来源:TRAE Work 官方页面、产品发布说明;AIFlowLearn 使用 ImageGen 重绘,非官方架构图)

    如果一人公司的主业就是做软件,这种边界很有吸引力:需求文档、数据材料、原型、代码和审阅意见不必在办公 Agent 与编程 Agent 之间来回搬。我会优先用它测试“从产品资料到可运行项目”的连续交付,而不是拿它只写一篇普通周报。

    **待实测问题:**Work/Code 双模式之间是否真正复用上下文,以及云端并行任务完成后,文件版本、反馈和测试证据能否顺畅回到同一个项目。

    先过安全边界,再谈自动执行

    Agent 一旦能读文件、操作网页和调用连接器,选型就不再只是效率问题。我会在试用前把执行位置、授权范围、敏感数据和回滚证据写进清单。

    工具官方公开的执行与权限边界我在试用时必须验证
    WorkBuddy 本地文件按工作空间授权;连接器独立授权;自动化配置保存在本地客户端 外部发送前是否再次确认,文件变更与连接器动作是否有日志
    QoderWork 文件操作在本地完成;仅访问明确授权目录;相关文本会发送给模型服务商 哪些内容会进入模型请求,桌面操作失败后能否停止并回滚
    Kimi Work 可选择逐步询问或完整访问;本地运行代码;WebBridge 可操作已登录浏览器 敏感步骤的确认粒度,长任务中权限是否会被放大
    TRAE Work 官方强调云端 Workspace、后台并行与跨设备访问 敏感资料是否适合进入云端项目,组织的权限、保留和审计要求是否满足

    这里没有“本地一定安全、云端一定危险”的简单答案。我的底线是:先拿副本和脱敏数据试跑;任何会修改文件、提交表单或对外发送的动作,都要能看到授权、变更和失败记录。

    四、一人公司怎么选:按角色路由,不按总榜站队

    一人公司最容易踩的坑,是买了 4 个订阅,最后还是自己当复制粘贴中间件。我更认可“一个主工作台 + 若干专长工具”的路由方式。

    下面给的是基于官方公开能力形成的试用优先级,不是已经跑出来的实测胜负。真正订阅前,仍要用第五节的同任务验收确认。

    只有一个预算:先选最常发生的工作

    如果日常工作集中在中文资料、报告、PPT、表格、项目协作和 IM 远程入口,我会先试 WorkBuddy。它的产品边界最接近一个综合办公总控,尤其适合内容、运营、咨询、小团队负责人和 OPC 场景。

    如果每天最耗时间的是本地文件、后台网页和桌面软件之间的重复操作,我会把 QoderWork 放在第一顺位。它的选型价值不来自“会不会写”,而来自“能不能替我点、填、整理、保存并定时再做一次”。

    如果业务核心是研究、金融、咨询、学术或数据分析,我会先试 Kimi Work。Goal 模式、WebBridge、专业数据和本地运行能力更贴近长任务,适合把一个目标放进去持续推进。

    如果每天都要在产品文档、数据、代码和项目文件之间切换,我会先试 TRAE Work。它更像一个把 Work 与 Code 连接起来的项目空间,云端并行和跨设备则适合同时推进多个交付。

    预算允许组合:主控与专长要分开

    我的组合思路会是:

    • 用 WorkBuddy 做中文办公入口、项目调度、专家协作和最终产物汇总;
    • 用 Kimi Work 做资料密集型研究与需要多轮推进的分析任务;
    • 用 QoderWork 接本地文件与桌面应用的重复动作;
    • 用 TRAE Work 承接产品与代码强耦合的交付。

    这不是建议 4 个全买。相反,我会先确定一个主控,再看主控在哪类任务上需要自己频繁接管,只有接管次数持续偏高,才引入第二个工具。

    选型复盘

    工具越多,能力不一定越强,上下文搬运却一定变多。一人公司的工具栈应该像模型路由:常规任务走主路,专业任务才切专线,任何新订阅都要用“减少了多少次人工接管”来证明自己。

    我为什么不做价格总榜

    WorkBuddy、Qoder、Kimi 与 TRAE 都有各自的套餐、Credits 或 Usage 体系,任务复杂度和模型选择还会影响消耗。把月费直接放进一张表,会制造一种虚假的可比性。

    我真正会算的是“合格交付成本”:一个工具完成 10 次任务,其中 6 次需要我重新整理文件,另一个只完成 7 次但 6 次可以直接交付,后者对一人公司可能更便宜。时间、返工和注意力切换都要进入成本,而不是只看订阅页上的数字。

    五、别急着付费:用 3 个任务做一轮可验收的试用

    我不建议用“帮我写一篇 AI 文章”测试这类工作台。这个任务太短,也太容易被漂亮文字掩盖。真正有效的测试,要同时包含杂乱输入、外部动作、多种产物和明确验收标准。

    任务 1:把一堆资料变成可汇报的研究包

    给 4 款工具同一组网页链接、PDF 和历史表格,要求输出:

    • sources.xlsx:资料标题、来源、日期、关键事实与引用位置;
    • report.docx:带结论、证据和风险提示的研究报告;
    • briefing.pptx:给客户或团队汇报的 10 页演示;
    • run-log.md:记录缺失资料、冲突信息和未确认判断。

    我会检查 4 件事:来源能不能点开,数字能不能追溯,PPT 能不能直接演示,报告与表格之间有没有互相打架。

    任务 2:批量整理本地文件,而且必须可回滚

    准备一份副本目录,里面放命名混乱的合同、图片、发票和表格,让工具按规则分类、重命名、去重并生成索引。要求它先给计划,执行后交付:

    • 新目录结构;
    • mapping.csv,记录旧文件名与新文件名;
    • 重复文件清单;
    • 未处理文件及原因;
    • 回滚说明。

    这个任务能测出工具是否真的理解权限、文件操作和失败处理。我不会在第一轮就给真实业务目录,先用副本验证,再决定是否扩大授权范围。

    任务 3:从产品想法推进到一个可运行交付

    输入一份产品背景、用户访谈和功能约束,要求产出 PRD、竞品摘要、落地页、可运行原型、测试记录和发布演示。对 WorkBuddy,我会看专家团与产物区如何协同;对 QoderWork,我会看浏览器与本地文件链路;对 Kimi Work,我会看 Goal 模式能否持续迭代;对 TRAE Work,我会看 Work/Code 双模式之间是否减少资料搬运。

    我给这轮试用设计了一张 100 分验收表:

    评分项分值验收问题
    产物完整度 30 要求的文件是否齐全,格式是否能正常打开?
    事实与来源 25 结论能否追溯到输入材料或网页来源?
    文件可用性 20 表格、PPT、文档、代码是否能继续编辑和运行?
    人工返工量 15 我花了多少时间改格式、补数据和重新组织?
    自动化复用 10 同类任务能否保存成 Skill、自动化或可重复流程?

    我自己的判定线也写死:

    • 核心交付文件缺失、打不开或无法继续编辑,直接淘汰;
    • “事实与来源”低于 20 分,不进入真实业务;
    • 总分 80 分及以上,进入主工作台候选;70—79 分,只在限定任务试用;低于 70 分,暂不订阅;
    • “人工返工量”按实际时间计分:10 分钟以内得 15 分,11—30 分钟得 10 分,31—60 分钟得 5 分,超过 60 分钟或需要人工重做得 0 分。

    不要只跑一遍。我会把同一任务重复 3 次,记录成功率、人工接管点、产物差异和消耗。Agent 偶尔做对一次不难,连续交付才有资格进入生产。

    为了避免 4 款工具收到不同要求,我会统一使用下面这段任务骨架:

    目标:请完成【任务名称】,最终交付可直接使用的文件,而不是只在对话中回答。

    输入范围:
    – 仅使用【指定文件夹 / 指定链接 / 指定数据】
    – 不确定的信息必须标记,禁止自行补全为事实

    交付物:
    – 文件 1:【文件名 + 格式 + 用途】
    – 文件 2:【文件名 + 格式 + 用途】
    – run-log.md:记录来源、执行步骤、文件变更、失败与未确认项

    验收标准:
    – 所有文件可以正常打开并继续编辑
    – 每个事实能追溯到输入材料或网页来源
    – 文件之间的数据和结论保持一致
    – 遇到阻塞时停止高风险动作,说明原因并给出下一步

    权限边界:
    – 只读【输入目录】,只写【输出目录】
    – 修改、删除、提交表单或对外发送前必须征得确认

    这里还有 3 个常见误区。

    第一,提示词不同,最后却怪工具不同。横评时输入材料、输出文件名、验收标准和权限范围必须一致,只允许补充产品特有的调用方式。

    第二,把预览截图当成正式产物。页面看起来漂亮,不代表 .pptx 能编辑、.xlsx 公式正确、代码能运行。验收必须打开真实文件。

    第三,只看成功结果,不看失败后怎么收场。真正的工作台要能告诉我哪里阻塞、哪些文件改过、哪些结论没有证据,以及如何继续,而不是安静地交付一个半成品。

    六、写在最后:未来的 AI 办公工具,必须对结果负责

    我对这波 AI 工作台有 3 个判断。

    判断一:聊天框会退到入口,Workspace 会成为主体。

    工作不是一问一答,而是一组持续变化的文件、上下文、权限和状态。未来用户未必关心每一步用了哪个模型,但一定会关心任务做到哪里、改了什么、产物在哪里、失败后怎么继续。

    判断二:模型会越来越像公共供给,执行闭环才是产品差异。

    同一款产品可以切换模型,同一个模型也会进入多款产品。真正难复制的是任务规划、工具调用、权限控制、文件系统、连接器、Skills、专业数据和验收界面如何咬在一起。

    判断三:一人公司需要的是任务路由,不是工具收藏。

    一个人不可能同时盯住 4 个 Agent 的所有过程。最好的组合不是功能最多,而是主路足够稳定、专线足够明确、每次切换都有理由。

    所以,我现在看 WorkBuddy,不会先问它用了什么模型。我会先问:它能不能接住一人公司最常见的调研、内容、数据、开发和协同任务,能不能把中间动作做完,能不能交付我真正需要的文件,能不能让我在结果区完成最后验收。

    这也是 4 款工具横向比较后,我认为最值得记住的一句话:

    AI 办公工具真正的分水岭,不是它会不会说,而是它能不能做完、交付,并对结果负责。

    如果你也在搭一人公司的 AI 工作流,不妨现在就挑一个最耗时间的真实任务,把输入、产物和验收标准写清楚,再让 4 款工具中的候选者跑一轮。不要问“谁最强”,先看谁让你最少接管。

    延伸学习

    补充一个开源视角:如果想了解这类 AI 工作台背后的实现,可以看看这几个项目的源码解读:

    • OpenClaw:通用个人助理、Skills、工具调用与多渠道执行 – 中文 Codex 源码课程
    • Hermes Agent:长任务、自我学习、记忆、定时任务与子 Agent – 中文 Codex 源码课程
    • Odysseus:更接近自托管 AI Workspace – 中文 Codex 源码课程
    • UI-TARS Desktop:视觉理解、桌面操作与 Computer Use – 中文 Codex 源码课程

    这些课程适合对照商业工作台看看它们的架构是怎么实现的。

    也可以通过动态讲解建立整体认识:

    • OpenClaw Classroom:拆解 Gateway、Skills、工具调用和任务执行流程 – 课程链接
    • Hermes Agent Classroom:拆解记忆、自我学习、长任务、定时任务与子 Agent – 课程链接

    建议先看 PPT 讲解建立整体认识,再回头看 Codex 和源码。

    赞(0)
    未经允许不得转载:171主机测评 » 对比 4 款 国产AI 工作台,WorkBuddy 、QoderWork 、Kimi Work 、TRAE 怎么选
    分享到: 更多 (0)

    评论 抢沙发

    • 昵称 (必填)
    • 邮箱 (必填)
    • 网址