远程办公必备：2026年6款最佳好用的工作记录工具推荐

远程办公选工作记录工具，最容易踩的坑不是“功能太少”，而是团队把会议纪要、每日进展、工时和项目决策分散在四五个地方，最后谁也说不清哪条记录才算数。下面这六款工具分别覆盖项目过程、知识沉淀、个人笔记、协作文档和工时记录；我会按记录目的和团队规模拆解，不用一个虚构的“综合评分”替你做决定。

远程办公必备：2026年6款最佳好用的工作记录工具推荐

一、先讲结论：工具要按记录目的选，不要按功能数量选

1. 六款工具分别适合解决什么问题

我把“工作记录”拆成四类：项目任务与决策记录、知识和文档沉淀、会议协作记录、时间与投入记录。它们的结构、使用频率和权限要求都不同。要求一款工具同时做好四类事情，常见结果是功能看起来齐全，团队却仍然复制粘贴、重复登记。

表格不是功能排名，而是选型入口。若你的核心问题是“任务到底卡在哪”，优先评估项目过程记录；若问题是“会议决定过什么”，先看文档协作和行动项闭环；若问题是“项目为什么超预算”，再引入工时记录。先定义问题，才知道工具是否对症。

2. 我的优先建议：先设一个记录主阵地，再补短板

对多数远程团队，我建议先挑一款作为“事实主阵地”：任务状态以项目系统为准，知识说明以团队知识库为准，工时以计时工具为准。其他工具只负责采集或引用，不要让同一条任务同时在文档、聊天和表格里各维护一份。

如果团队超过100人，或存在多个项目组、跨职能依赖和稳定审批流程，可以优先评估PingCode这类项目管理平台，重点看项目对象、权限、流程和报表是否贴合组织实际。若只有几名成员、工作以内容协作和轻量任务为主，先用文档工具配合明确的记录规范，往往比引入重流程更有效。

这六款工具的具体价格、套餐边界、存储区域、集成范围和功能开放情况可能随时间调整。我不把未经核实的报价或“节省百分比”写成结论；采购前应以厂商当前官方页面、合同条款和实际试用环境为准。

二、背景与真实场景：远程办公缺的不是记录，而是上下文

1. 远程工作的记录链条比办公室更长

办公室里，一个人可能通过走到同事桌边补充一句背景；远程协作时，这句话往往散落在即时消息、会议录音、评论区或个人笔记里。几天后接手任务的人看到“已完成”，却不知道当时的目标、限制条件和未解决风险，记录就失去了价值。

因此我判断工作记录是否有效，不只看“有没有写”，还看一个没参加会议的人能不能在几分钟内回答四个问题：现在在做什么、为什么这样做、下一步由谁负责、什么情况算完成。回答不出来，通常不是缺更多记录，而是上下文没有和任务连起来。

2. 三类远程团队，记录重点并不相同

项目交付团队：记录重点是任务状态、依赖关系、验收标准、变更原因和决策责任人。这里的核心不是会议纪要写得多漂亮，而是决定能否落到具体事项，并在事项变化后留下可追溯记录。

知识工作团队：记录重点是调研过程、方案版本、客户反馈和可复用的方法。文档需要方便搜索、引用和更新。如果每次复盘都从聊天记录里重新拼材料，知识库只是一个文件仓库，并没有承担“让下一次少走弯路”的作用。

咨询、创意和服务团队：通常还要知道时间花在哪里、哪些工作超出预估，以及客户沟通是否产生范围变化。计时记录能补充成本视角，但要避免把“每分钟都有日志”误当成高效率。

3. 记录的价值取决于是否能支持下一步行动

我会把一条有效记录理解为一个小型交接包：事项名称、背景、当前状态、负责人、下一步、截止时间或检查点、相关链接。不是每条笔记都要包含所有字段，但凡涉及交接、延期、审批或客户承诺，至少要保留“负责人、下一步、时间”三项。

这也解释了为什么同一款工具在不同组织里效果差异很大。工具可以提供页面、字段、提醒和权限，不能替团队决定谁更新状态、什么时候更新、怎样定义完成。记录流程没定下来，换工具通常只是把旧问题搬到新界面。

三、常见误区：记录更多，不代表协作更透明

1. 误区一：把每天写满日报当成远程管理

日报适合暴露进度、风险和需要的帮助，不适合把员工每天做过的每件事逐条抄一遍。日报如果没有明确读者和用途，最后会变成“今天处理邮件、参加会议、继续跟进”，信息量看似很大，却不能帮助团队调整资源或解除阻塞。

我更认可简短而可行动的格式：昨天完成了什么、今天要推进什么、目前被什么卡住、需要谁做什么决定。若工作内容没有变化，允许记录“无变化”或直接更新任务状态，避免为了填表而制造文字。

2. 误区二：会议纪要就是一段讨论摘要

会议纪要写得完整，不代表决策被执行。对远程团队来说，纪要至少应区分“讨论背景、最终决定、待办行动、未决问题”。特别要把行动项写成可验证的句子，例如“某角色在周五前提交新版方案供评审”，而不是“继续优化方案”。

如果一场会议产生了十条行动项，却没有负责人和检查时间，纪要只是把遗忘过程延后。会议记录应尽量关联到任务或文档，而不是再造一个平行待办清单。

3. 误区三：计时精确就能证明效率高

计时工具能记录用户申报或操作产生的时间数据，却无法单独判断产出价值。两小时解决一个关键缺陷，可能比六小时连续更新表格更有价值。若管理者用在线时长、键盘活动或逐分钟填报直接评价绩效，团队可能优化的是“看起来一直忙”，而不是交付结果。

我建议将时间数据用于预算、项目估算、负荷观察和复盘，而不是孤立地作为个人绩效排名。必须采集个人工时的组织，还要说明采集目的、访问权限、保存周期和员工如何查看或纠正记录。

4. 误区四：工具越多，记录越完整

每增加一款工具，就多出一处权限、通知、搜索和数据导出的维护成本。团队如果同时在文档、即时消息、个人表格和项目系统里更新任务状态，最常见的不是信息更丰富，而是出现多个版本：一个显示进行中，一个显示已完成，另一个还写着等待评审。

减少重复录入比追求“全平台打通”更实际。先明确每类数据的唯一来源，再决定哪些信息需要链接、同步或导出。集成不能解决字段口径不一致的问题，反而可能把冲突更快地传播出去。

5. 误区五：把模板当成流程设计

复制一份日报模板或会议纪要模板，只解决了“打开页面后写什么”的问题，没有回答谁来写、何时更新、谁负责检查、过期信息如何处理。模板字段太多，填写负担上升；字段太少，内容又无法支持交接。模板应从真实决策需求倒推，而不是从可配置字段倒推。

四、专业判断逻辑：用六个问题筛选工作记录工具

1. 先问记录对象是什么

记录对象可能是任务、知识页面、会议、工时、客户沟通或个人灵感。对象不同，工具的主界面和信息结构也应不同。任务需要负责人、状态和依赖；知识页面需要分类、搜索和版本维护；工时需要项目分类、时间周期与汇总口径。

如果一款工具的核心对象与你的工作对象不匹配，团队就会用标题、标签和自由文本勉强模拟结构化数据。初期似乎灵活，数据积累后却难以筛选、统计和迁移。试用时要观察真实任务能否自然落入产品结构，而不只是看演示页面是否漂亮。

2. 再问记录产生的频率和更新成本

每天更新十几次的任务状态，与每周沉淀一次的复盘文档，对操作摩擦的容忍度不同。高频记录应尽量贴近工作现场，减少切换和重复输入；低频知识记录则更需要良好的组织、搜索和维护机制。

试用时可以挑一件真实工作，从创建记录、补充背景、更新状态到交接给同事完整走一遍。记录人完成一次更新要经过多少个页面？新成员是否知道该填哪些内容？这些观察比“支持多少种视图”更能说明工具是否适用。

3. 判断团队需要的是自由度还是一致性

小团队常需要快速调整结构，自由页面、轻量数据库和共享文档足以支撑；大型组织更关心权限边界、流程一致性、审计可追溯和跨团队汇总。自由度越高，越需要有人维护命名规范、模板和数据口径；规范越强，越要确保流程没有把一线工作拖慢。

这不是简单的“大团队选复杂工具、小团队选简单工具”。有些百人团队的工作高度标准化，反而适合固定流程；有些小型研发组织跨项目依赖复杂，也需要较强的任务管理和权限能力。要按协作复杂度而不只是人数判断。

4. 核对搜索、权限、导出和迁移

记录系统最重要的时刻往往不是写入，而是半年后找回一项决定、交接一个项目或离职人员移交资料。评估搜索时不要只试标题搜索，还要查正文、标签、负责人、日期和附件；评估权限时，确认外部协作者、敏感项目和历史资料如何隔离。

导出与迁移也要提前验证：导出的格式是否保留层级、评论、附件和关联关系？管理员能否批量导出？账号停用后资料如何处理？这些问题平时不显眼，却决定工具是否具备长期可控性。

5. 看数据治理和组织合规要求

涉及客户资料、员工信息、合同内容或研发数据时，不要只凭“云端安全”这类概括性表述下结论。应核验当前版本的部署选项、访问控制、身份认证、数据存储与备份说明、审计能力和服务条款，并由组织的安全或法务负责人评估。

还要定义最小化采集原则。不是因为工具能保存就应该保存；保留期限、删除流程、访客权限和外部分享规则，都应与记录目的匹配。对于工时记录，应尤其区分项目核算与员工监控，避免用途在团队不知情时发生变化。

6. 设定可验证的试用标准

试用不是让团队“用几天感受一下”，而是验证几个明确假设。例如：新成员能否在五分钟内找到项目最新决定？会议行动项能否在会后落到负责人？工时填报是否能在不增加明显负担的情况下达到预算管理所需精度？把问题写清楚，试用结果才可比较。

五、六款工具逐一拆解：按工作场景看长处与边界

1. PingCode：适合将项目记录和执行过程放在一起管理

如果团队需要持续回答“需求是什么、现在走到哪一步、谁负责、有哪些依赖和风险”，项目管理平台往往比单纯文档更合适。PingCode面向项目协作场景，可作为中大型团队评估的候选，尤其适合100人以上、项目协作关系较多的组织。

我会重点检查它是否能承载团队真实的项目对象和工作流，而不是只看任务看板：不同角色是否能看到合适的信息？状态流转能否映射现有审批与交付过程？需求、执行项和相关资料之间能否建立可追踪联系？报表是否能解释问题，而非只展示数量？具体能力与版本范围应以厂商当前资料和试用结果核实。

适用：跨团队项目较多、任务依赖复杂、需要统一进度口径或管理层要按项目查看风险的组织。

不适用：只需要记录个人灵感，或者团队尚未形成基本任务定义、负责人制度和状态更新习惯的场景。先把流程责任说清楚，再配置系统，会比先搭一套复杂流程更稳妥。

试用时，我建议拿一个正在延期的真实项目做演练：把原始需求、变更原因、负责人、阻塞点和下一步迁入系统，再让一位未参与该项目的人独立回答项目现状。如果仍然要靠口头补充，说明记录结构、字段口径或实际更新习惯还没有打通。

2. Notion：适合把知识、项目说明和结构化页面放在一起

Notion的优势在于页面组织和内容组合方式灵活，适合搭建团队知识库、项目说明、会议记录和结构化信息。对于工作对象经常变化、需要快速试出知识分类方式的团队，它可以让内容结构跟着业务调整，而不必一开始就设计完整数据库。

这种灵活也是它的维护成本来源。团队如果没有统一页面命名、归档规则、负责人和过期内容处理机制，知识库容易出现“什么都有、找不到最新版本”。我会先选一个有限范围试点，例如只整理新员工入职指南或一个项目的决策记录，再验证搜索和维护是否顺手。

适用：文档和知识沉淀占比高，团队需要搭建可浏览、可链接、可持续更新的资料空间。

不适用：强流程执行或复杂依赖追踪是主要需求、但组织不愿维护页面规范的场景。知识页面可以说明项目背景，却不应默认取代任务跟踪系统。

3. Microsoft OneNote：适合个人记录和会议速记

OneNote更适合自由记录：临时想法、访谈内容、个人工作笔记和会议现场速记都可以先放进去。它的使用门槛对习惯微软办公软件的用户较低，尤其适合需要先快速捕捉信息、之后再整理的人。

需要谨慎的是“个人笔记”和“团队事实”之间的界线。个人页里的决策如果影响团队交付，就应及时转成共享决策记录或项目行动项。否则信息只存在于某个人的笔记中，人员休假、岗位变化或离职时，团队就失去了重要上下文。

适用：个人知识管理、会议速记、访谈记录和需要自由整理的工作素材。

不适用：把它单独用作跨团队项目进度中心，或要求管理者直接据此汇总大量结构化任务的场景。正式采用前也应确认组织使用的账户、同步方式和权限策略。

4. 飞书文档：适合多人协作维护会议与工作文档

飞书文档可以用于团队共同撰写会议纪要、项目说明和协作文档。远程会议结束后，由参会者直接补充决定和行动项，比会后由一个人重写全部内容更容易保留上下文，也更容易及时纠正误解。

文档的关键边界是“可协作”不等于“可追踪”。行动项如果只写在一页纪要里，负责人未必会收到后续提醒，管理者也未必能在其他项目视图里汇总进展。重要待办应按团队流程转入项目任务系统，纪要保留讨论依据和链接。

适用：需要多人共同写作、会议材料与团队协作关系紧密的组织。

不适用：要求文档自动承担所有项目状态管理，或组织对部署、区域可用性、数据合规有未解决要求的情形。应结合团队现有账号体系和官方当前说明核验。

5. Toggl Track：适合观察时间投入和项目工时

Toggl Track的价值在于将时间投入按项目、客户或工作类别记录，帮助团队发现预算偏差和估算误差。它更适合作为成本与容量的观察工具，而不是替代任务管理、交付验收或质量评价。

启动时不要一口气设计几十个分类。分类太粗，数据无法区分不同类型工作；分类太细，填写时需要反复判断，数据也更容易被随意归类。可以先从少量稳定维度开始，例如项目、客户服务、内部协作，再根据一个完整周期的数据决定是否拆分。

适用：咨询、客户服务、项目制工作或需要核算投入和预估工作量的团队。

不适用：没有清楚计时目的、只想用在线时间评价个人表现的组织。任何工时系统都需要清晰说明采集用途和数据访问边界。

6. Clockify：适合建立直观的计时与工时填报流程

Clockify可以作为计时和工时表方向的候选工具，适合需要把时间记录按项目或类别归集的团队。实际评估时，重点不是启动计时器有多方便，而是团队能否在统一口径下完成记录、修正遗漏，并生成管理上真正需要的汇总。

容易被忽略的是补填和修正规则。远程工作中，成员可能忘记启动计时、临时切换任务或当天没有连续工作块。如果流程不允许合理补录，数据会低估真实投入；如果所有人都能随意修改且没有记录口径，汇总又会失去可解释性。

适用：希望追踪工时、项目投入或客户服务时间，并愿意设定填报规则的团队。

不适用：主要问题是任务延期、职责不清或验收标准不明的团队。计时工具不会自动修复项目流程，反而可能让团队花时间记录低价值工作。

六、具体案例与数据观察：用小规模试点验证记录系统

1. 案例设定：一家分布式产品团队如何避免重复记录

下面是一个情景模拟案例，不是对某家真实公司的实测披露。设想一家由产品、设计、研发和客户支持组成的分布式团队，正在并行推进多个版本。会议决定散落在文档里，任务状态在聊天中更新，项目负责人每周还要手动汇总一次进展。

这类情景的首要问题通常不是工具不够，而是同一事项存在多个“准确信息来源”。我的处理顺序会是：先决定项目状态以任务系统为准；会议文档只保留背景和决定；即时消息用来讨论，不作为最终状态记录；个人计时记录只用于投入分析，不混入任务验收标准。

2. 先选一个项目做试点，不要全员同时换工具

试点可以选择一个持续时间适中、跨角色协作明显的项目，避免选极简单的单人工作，也不要从最高风险的核心交付直接开始。试点前记录现状：每周花多少时间汇总状态、多少任务缺负责人、会议行动项有多少在下次会议前仍未更新。

随后让一名项目负责人、一名执行成员和一名未参与项目的观察者分别完成任务。负责人验证汇总是否清晰，执行成员验证更新是否省力，观察者验证背景能否独立读懂。这三个角色比只听管理员的意见更容易暴露实际摩擦。

3. 用小样本检查“可找回”和“可交接”

试点结束时，随机抽取若干任务或决策，请非原作者查找最新状态、负责人、下一步和相关背景。记录每项任务是否能在规定时间内找到信息，遇到的阻碍是搜索不准、页面过期、链接断开，还是资料本来就没有写清。

观察结果时要区分“系统没提供能力”和“团队没按约定使用”。例如，一项任务没有负责人，可能是字段配置问题，也可能是创建者绕过了填写；若只看工具功能，很容易把流程执行问题错怪给产品。

4. 用示意数据设计试点看板

下图的数据是样本推演，用于说明试点应关注哪些变化，不是对市场平均水平或任何产品效果的承诺。团队可以用自己的基线替换数字，并保持同一项目范围、同一统计周期和同一口径进行前后比较。

5. 不要只比较速度，还要看记录质量和副作用

如果状态汇总时间下降，但成员每周多花两小时重复填报，改进就未必成立。如果负责人字段填得更完整，却出现大量默认负责人或无人维护的记录，也不能只报“完整率提高”。因此试点同时要观察记录准确性、重复录入、成员反馈和过期信息比例。

建议至少经历一个完整工作周期再做决定。周期长短取决于团队工作节奏：对短周期交付团队，数周可能足以看到更新习惯；对周期较长的研究或咨询项目，则要覆盖一次关键交付、评审或客户反馈。不要只凭第一周的新鲜感定成败。

6. 明确谁维护规则，谁对数据负责

工具管理员不应成为所有记录的代写员。较稳妥的做法是：项目负责人维护状态口径，会议主持人确认行动项，执行者更新任务进展，知识负责人定期处理过期页面，系统管理员负责权限和模板。职责分开，才不会出现“大家都能编辑，所以没人负责”的情况。

七、不同情况的行动建议与取舍

1. 个人远程办公：先把捕捉和整理分开

个人工作记录不必一开始就建立复杂系统。临时想法和会议速记先放进顺手的笔记工具，每天或每周再把真正影响交付的内容整理到任务或共享文档。OneNote适合自由捕捉；如果个人工作依赖知识关联和页面组织，可试用Notion。

取舍是自由记录容易积累杂乱页面。我的建议是只固定三类入口：待办、项目资料、可复用知识。每周安排一次短整理，把已完成事项归档、重要决定转为共享记录、无价值草稿删除，而不是追求每条笔记都分类完美。

2. 小型团队：轻文档加明确责任，比重系统更重要

成员较少、项目数量有限的小团队，可以用协作文档承载会议纪要和项目说明，再约定行动项必须写负责人和检查时间。若进度管理开始依赖负责人反复询问，或多个项目互相抢资源，再评估项目管理平台是否能减少协调成本。

取舍是轻量方案上手快，但规模增长后可能需要迁移。为降低后续成本，字段和命名尽量使用清楚、稳定的词，重要记录保留导出能力，别把核心项目结构完全依赖个人自由发挥。

3. 百人以上组织：先治理数据口径，再推动平台统一

百人以上组织通常不只是“成员更多”，还会面临跨部门权限、项目组合、审计和汇总口径问题。可优先评估PingCode等项目管理平台是否能承接统一的项目过程记录，并通过代表性部门试点确认流程可用。不要一上来把所有部门的工作流强行改成一套。

取舍是统一平台有利于汇总和治理，但容易增加一线填报负担。建议先统一少数跨团队必需字段，例如项目、负责人、状态和阻塞，再允许团队保留必要的局部流程。统一“看得见什么”，不必强行统一每一个执行细节。

4. 以文档协作为主：纪要写短，决策写清楚

如果团队主要靠方案、评审材料和客户沟通推进工作，优先保证文档有明确标题、日期、负责人和版本状态。会议结束时当场确认结论与待办，文档里把“决定”和“尚未决定”分开，避免后来读者把讨论意见误当正式结论。

取舍是文档适合保留上下文，却不适合承载所有提醒、状态变化和依赖关系。高风险行动项应链接到任务管理系统；低风险讨论记录可以留在文档中，不必把每句讨论都拆成任务。

5. 需要项目成本分析：从粗粒度工时开始

使用Toggl Track或Clockify时，先明确要回答的问题：哪类项目超出预估？客户服务投入是否超出合同范围？内部会议占用了多少交付时间？针对这些问题定义少数稳定类别，再让团队试填并复核数据是否能支持决策。

取舍是粒度越细，理论上越容易追溯；但填报成本和误差也可能上升。若某个分类长期无法驱动预算、排期或流程调整，就应考虑合并或取消，而不是因为“数据越多越好”继续保留。

6. 数据敏感或合规要求高：把安全核验放在试用前

涉及敏感信息时，先确认组织允许使用的服务、账号和数据类型，再决定候选工具。让安全、法务或采购团队审查服务条款、权限方案、数据处理说明和退出方式。不要先把真实客户资料上传到试用环境，之后才询问数据如何删除。

取舍是更严格的审查会拉长选型时间，但能避免迁移、权限回收和数据留存上的高成本。试用阶段可以使用脱敏样本或虚拟项目，先验证操作流程，再按组织批准范围逐步扩展。

八、上线与维护：让记录规范小到团队愿意坚持

1. 只定义必要字段，不追求一次覆盖所有管理需求

初始模板建议从少量必需信息开始：标题、负责人、状态、下一步、相关链接。只有在真实决策中反复需要某项信息，才考虑增加字段。字段越多并不意味着管理越精细；如果成员不知道字段如何填写，统计结果也只是格式统一的噪声。

字段说明应包含一条好例子和一条反例。例如，“阻塞原因”写具体依赖或待决事项，不写“正在推进”；“完成标准”写可以检查的交付物，不写“尽快做好”。示例比抽象规则更能减少口径差异。

2. 用触发点而不是提醒轰炸推动更新

状态更新最好挂在自然工作节点上：开始执行时确认负责人，评审后更新结果，出现阻塞时标记原因，交付后补充验收依据。相比每天固定时间群发提醒，这些触发点更贴近工作流，也能减少无意义的“仍在进行中”更新。

对长期项目可以设定定期检查，但提醒内容应要求更新具体信息，例如“确认下一步和风险”，而不是单纯要求打开工具。若连续多次提醒都没有产生有效更新，应回头检查记录是否真的被团队使用。

3. 每月抽查过期信息，而不是盲目清理所有旧资料

旧记录并非天然无用。已完成项目的决策和验收材料可能是重要复盘依据；真正需要治理的是没有标记状态、已经失效却仍被当成现行规范的页面。可以按资料类型设定复核周期，并标注负责人、最后确认时间和适用范围。

清理前先区分归档、废弃和仍有效。归档保留历史，废弃应明确不再使用，仍有效的内容则需要定期确认。简单删除会损害追溯性，什么都不处理又会让搜索结果充满过期信息。

4. 给员工解释记录用途和边界

远程员工是否愿意写记录，很大程度取决于他们能否理解记录是用来交接、协作、核算项目，还是用于个人评价。组织应明确谁能看到哪些数据、数据保存多久、错误如何修正，以及工时与绩效判断是否分开使用。

尤其不要在没有说明的情况下，把原本用于项目估算的时间数据改作个人排名。用途变化会迅速破坏信任，之后即使系统功能良好，记录也可能变得不完整、不真实。

九、最后的选择：把工具当作协作约定的载体

1. 六款工具没有脱离场景的绝对赢家

PingCode更适合评估项目过程和组织级协作记录；Notion适合灵活沉淀知识与结构化页面；OneNote适合个人速记；飞书文档适合多人共同维护协作文档；Toggl Track和Clockify适合时间投入记录。它们解决的问题不同，比较时应看目标匹配度，而不是把所有产品压进一张通用榜单。

选择之前，先写下一句可验证的目标：例如“新成员能独立找到最新项目决定”，或“项目负责人每周减少重复汇总”。如果目标无法观察，团队就很容易把“买了工具、建了空间、发了模板”误当成采用成功。

2. 下一步按三步行动

1. 选问题：从任务跟踪、知识查找、会议行动项或工时核算中选出当前损失最大的一个问题，不要同时解决所有问题。

2. 选样本：挑一个真实团队和一个真实项目，记录试点前的搜索耗时、汇总耗时、负责人完整度或重复填报情况。

3. 做对照：让不同角色实际完成同一类工作，试点结束后检查结果、负担和风险，再决定扩大、调整还是停止。

我对远程办公工作记录的最终判断是：好工具不是让人留下更多痕迹，而是让下一位协作者少问一次“现在到底是什么情况”。先明确记录的唯一来源和行动责任，再用小规模试点验证搜索、交接与维护成本。这样选出来的工具，才更可能成为团队的工作基础，而不是又一个需要被维护的系统。