选择困难症？2026年wiki记录工具选型指南帮你轻松决策

选择困难症？2026年wiki记录工具选型指南帮你轻松决策

选择 wiki 记录工具时，最容易踩的坑不是选错了功能，而是把“建起了知识库”误当成“团队已经会用知识库”。目录做得很漂亮，几个月后却没人更新；工具号称搜索强大，员工还是在群里追问旧文档在哪。我的判断是：选型先别比功能清单，先确认知识从哪里产生、谁来维护、使用者如何找到它，以及有一天要迁走时能否完整带走。

一、先给结论：不要找“功能最多”的，要找“最容易持续使用”的

1. 选择工具之前，先说清楚你要解决什么问题

“wiki记录工具”不是一种单一需求。有人想整理个人学习笔记，有人要把团队流程、产品资料和客户问题放在一起，也有人需要维护项目或技术文档。它们都可能被叫作知识库，但使用者、内容结构、权限要求和维护方式并不相同。

所以我不会从“有哪些热门工具”开始选，而会先问四个问题：谁来写，谁来读，最常找什么，内容多久需要更新一次。答案不同，适合的工具也可能不同。个人知识整理重在低摩擦记录；团队 wiki 还要考虑权限、协作和内容责任；技术文档则要进一步检查结构、版本变化和发布流程。

选型的核心不是工具能做多少，而是它能否让目标用户完成真实任务。如果销售同事要找一份最新报价规则，测试人员要查某个功能的验收说明，新员工要弄懂入职流程，那么“搜索能否找到正确、有效、可执行的内容”比首页有多少模块更值得验证。

2. 我建议采用“先淘汰，再比较，最后试用”的决策顺序

直接给工具打分，常常会把不同维度混在一起：一个产品部署灵活，另一个产品上手轻松，第三个产品权限设置细。若团队还没有说明哪些条件属于硬性要求，最后很容易由演示效果、个人偏好或某个功能亮点左右决策。

更可靠的做法是先设硬门槛，再比较体验，最后通过小范围试用验证。硬门槛包括数据管理要求、必需的访问方式、关键权限和迁移要求；体验比较则关注记录、检索、协作和维护；试用环节要让真实使用者带着真实任务操作，而不是只听产品介绍。

1. 先列硬条件：哪些要求不满足就不能采用，例如部署政策、访问边界、数据导出方式。
2. 再按场景比较：针对个人、团队、项目或技术文档分别评估，不把不同类型的工具放在同一条“功能多寡”标尺上。
3. 最后做任务测试：用团队真实资料完成写入、查找、编辑、授权和导出。

3. 一张打分表不能替代一条清楚的淘汰规则

很多团队喜欢给每个维度打 1 到 5 分，再计算总分。这个方法可以帮助整理讨论，但它有一个隐患：某项严重缺陷可能被其他高分抵消。例如，导出后的附件丢失，不能靠界面美观和模板丰富来“补分”。

我会把指标分为两类。第一类是硬门槛，不满足就退出候选范围；第二类是偏好项，用于比较剩余方案。安全与数据管理要求、必要的协作边界、内容可迁移性通常应先确认；界面习惯、模板选择和某些便利集成，则可以结合试用结果比较。

另外，评分不是客观事实。给“搜索体验”打 4 分之前，必须说明谁做了什么任务、使用了哪些内容、怎样判断成功。没有评分口径的数字看起来精确，实际上只是把主观印象写进表格。

二、先理解场景：同样叫 wiki，实际要解决的事可能完全不同

1. 个人记录：降低记录阻力，留意未来能否找回

个人使用时，最先影响长期习惯的往往不是复杂的组织功能，而是记录阻力：从想法出现到内容保存，要经过几步？临时笔记以后能否归档？跨设备使用是否符合自己的习惯？这些问题决定工具会成为日常工作台，还是又一个被遗忘的收藏夹。

个人场景也不能只看“能不能记”。建议拿一周真实内容试用：写几段读书摘录、一个待办想法、一份工作记录，再分别通过标题、关键词、标签或目录找回来。如果只能记得内容，却想不起放在哪里，说明组织方法或检索方式仍不适配。

个人知识库的另一项容易被忽视的要求是退出成本。即使今天只有几十篇内容，也要确认导出的文件是否可读，图片和附件是否随内容导出，链接或目录关系是否还能理解。内容量越大，临时发现迁移不完整的代价越高。

2. 团队知识库：把“共同维护”设计进去

团队 wiki 的难点不是多人能否访问，而是多人能否在约定下共同维护。谁负责流程页面？规则变化后由谁更新？旧内容怎样标记失效？如果这些问题没有答案，工具只会让过时信息更容易被复制和传播。

多人协作还需要考虑内容的可见范围。并不是每个人都应看到所有资料，也不是每个页面都需要复杂审批。选型时要验证权限能否覆盖真实工作方式：例如按团队、项目或页面控制访问时，成员是否容易理解自己能看什么、改什么。

因此，团队 wiki 的采用成本不只是订阅费。培训、权限配置、内容迁移、信息架构设计和日常维护都要有人投入。对规模较小的团队而言，过于繁复的管理能力可能变成额外负担；对跨部门协作组织而言，权限和责任边界不清又可能带来治理风险。

3. 项目与技术文档：重点验证内容关系和变更过程

项目文档经常与需求、决策、测试、发布和复盘等内容相连。此时，页面之间是否容易建立关系、变更后能否追溯、读者能否判断哪一版有效，会比单纯的文件夹层级更重要。

但不能因为工具支持很多链接或模板，就推断团队一定能建立良好的知识结构。真正要检查的是：常用文档能否按现有工作流程找到；页面改动后，负责人员是否清楚；新成员能否从一份说明追到相关背景，而不是在多个页面之间迷路。

如果团队已有固定的项目管理、代码或文档工作流，还要实际核验集成是否解决问题。集成数量本身不是价值。只有当它减少重复录入、避免信息断层，或让读者能从日常工作位置抵达知识内容时，才值得纳入选型依据。

4. 自托管与云端：不要把部署方式直接等同于安全结论

自托管提供了更多部署和运维控制空间，但也意味着组织需要承担升级、备份、监控、故障恢复和权限管理等责任。云端方案通常减少基础设施维护工作，但仍要核实服务条款、数据处理范围、导出方式和组织政策是否匹配。

所以我不会用“自托管更安全”或“云端更省心”作为最终结论。部署方式只是责任如何分配，不是风险自动消失。应先让负责安全、合规或信息系统的人员说明边界，再检查候选方案提供了什么证据、团队承担什么维护工作。

三、选型中最常见的误区：看起来在比较，实际上没有验证

1. 误把功能数量当成适配度

功能列表很容易比较，实际使用价值却不容易从列表上看出来。一项功能可能只对特定套餐开放，也可能需要管理员配置，还可能与团队现有流程冲突。仅仅看到“支持权限”或“支持版本历史”，并不能说明它满足具体场景。

我建议把功能描述改写成任务。例如，不问“是否支持搜索”，而问“员工能否在权限范围内，用常用词找到最新的流程说明”；不问“是否支持导出”，而问“导出的页面、附件和层级能否被团队继续使用”。任务化的问题更容易在试用中得到可观察的答案。

2. 只比订阅价格，不算采用和维护成本

工具费用只是总成本的一部分。还要考虑数据迁移所需的人力、管理员的日常配置、成员培训时间、内容结构维护和未来退出成本。价格较低的方案，如果需要大量手工整理或额外维护，未必总成本更低。

可以用一个简单的成本框架来检查，而不急着把所有投入换算成精确金额：直接费用、一次性迁移投入、持续维护投入、用户学习成本、风险处置成本。每一项都写明估算依据和不确定性，避免用一个看似精确的总数掩盖缺少资料的问题。

3. 只看演示，不用自己的资料测试

演示页面通常已经经过整理，内容结构清楚、搜索词准确、权限也配置妥当。真实团队的资料往往有重复页面、旧版文件、缩写、附件和命名不一致。若试用只看演示环境，无法判断工具在团队自己的内容条件下是否好用。

测试集不需要很大，但要有代表性。至少准备一份常见流程、一份历史记录、一份带附件的资料、一份容易混淆的旧版内容和几个真实问题。让不同角色独立完成查找，再记录是否找到正确版本、花了多久、是否需要向同事求助。

4. 先搬全部资料，再考虑分类和责任

把旧文档一股脑迁入新系统，常常只是把旧问题搬到新界面。重复版本、无人负责的页面和不再适用的流程，会让新知识库一开始就充满噪声。内容越多，用户越难判断搜索结果是否可信。

更稳妥的做法是先选一个范围做整理：定义页面类型、命名规则、负责人、复核周期和失效标识，再迁移优先级最高的资料。没有必要第一天就追求覆盖所有历史内容。先让最常用、最重要的知识可靠，通常比“迁移完成率好看”更有价值。

5. 把“能搜索到”误认为“找到正确答案”

搜索返回一堆结果，不等于检索成功。用户还需要判断哪一条是最新的、适用范围是什么、是否有权限访问、答案是否能直接执行。选型测试应记录“正确结果是否被找到”，而不是只记录“页面有没有返回结果”。

如果测试发现用户频繁点开旧页面，问题可能出在版本标记和内容治理，而不只是搜索算法。如果同一问题有多个相似答案，可能需要合并页面或指定权威版本。工具能帮助呈现信息，但不能替团队决定哪条知识有效。

6. 把未经验证的宣传语当成测试结论

“安全”“高效”“智能搜索”“适合团队”等词语，需要转成可核验的问题。安全要看组织要求与公开材料是否匹配；高效要说明具体任务和基线；搜索能力要用真实内容测试；适合团队则要看团队规模、协作流程和管理方式。

如果某个产品页面写明功能、价格或套餐边界，文章和内部决策材料应记录信息核对日期。功能和套餐可能调整，单次查询不能永久代表当前情况。无法确认的事项应标记为待核实，而不是用推测补齐。

四、专业判断逻辑：用统一测试，把“喜欢”变成可复核的证据

1. 先建立“必须满足”和“加分项”两张清单

必须满足的条件要少而明确。若清单写得过长，候选工具可能一个都不符合；若写得太宽，又会让真正重要的限制在试用后才暴露。每一项都应有负责人和验证方式，例如由信息安全人员确认数据要求，由实际使用者验证检索任务。

加分项则用于区分已满足硬条件的候选方案。可按场景考虑模板灵活度、目录维护方式、评论与讨论体验、常用集成和移动端访问。加分项不是越多越好，应优先选择能直接减少现有工作摩擦的能力。

2. 设计一组固定任务，而不是让每个候选方案自由展示

公平比较的关键是任务一致。候选方案如果各自演示最擅长的功能，最后比较的不是产品，而是演示脚本。建议用同一批资料、同一组问题和相近的测试角色，让每个方案完成相同动作。

1. 建立一篇团队常用流程说明，并按约定目录放置。
2. 用一个真实问题查找该流程，记录是否找到正确版本。
3. 由另一名成员补充内容，再检查变更是否容易理解。
4. 将一个页面设置为不同访问范围，验证权限是否符合预期。
5. 导出页面与附件，检查文件能否阅读、层级是否清楚。
6. 让新参与者仅凭知识库完成一项常见任务，观察是否仍需口头解释。

测试记录要区分“任务完成”与“体验满意”。例如，用户最后找到了页面，但先点开三个过期版本；这可以算完成，却不代表检索体验好。把失败路径也记下来，往往比只记最后的成功结果更能解释问题。

3. 记录过程指标，让不同人的意见可以对照

试用时可以记录任务完成率、找到正确版本的比例、每个任务耗时、求助次数、权限配置错误次数和导出完整性。指标不必追求复杂，重要的是定义清楚分母、测试对象和判定方式。

例如，“找对资料的比例”可以定义为：参与者在限定时间内找到指定的现行页面，并能指出适用范围；仅仅打开了搜索结果不算成功。“导出完整性”可以逐项检查页面文本、附件、层级和内部链接，不宜只看是否生成了一个压缩包。

这些数据不能代表所有用户，也不能直接证明长期采用效果。它们的用途是比较候选方案在同一批任务中的差异，并发现需要调整的流程。样本小的时候，结论应写成“本轮试点观察”，而不是“普遍如此”。

4. 让内容治理和工具能力一起接受评估

知识库质量是工具、内容和责任共同作用的结果。即使搜索功能不错，页面没有标题规范、失效资料没有标识、内容无人维护，用户仍然可能找不到可信答案。相反，结构简单但责任明确的知识库，也可能比功能复杂却无人管理的系统更可靠。

所以试点时除了测试产品，还要测试维护机制：页面是否有负责人？哪些内容需要定期检查？政策变更后谁来更新？旧版资料怎样处理？如果组织暂时没有人承担这些职责，选型结论应如实写出这个限制，不能期待换工具自动补上治理能力。

5. 设定权重时，先解释为什么某项更重要

团队可以为偏好项设置权重，但权重应来自工作风险和业务影响，而不是为了让某个候选方案胜出。比如，知识主要用于应急操作的团队，正确检索和权限边界可能优先于个性化外观；以个人写作为主的用户，记录顺滑度可能更重要。

一种实用做法是给每个维度写一句“如果不满足，会造成什么后果”。若后果只是少一点便利，它可能是加分项；若会导致敏感资料暴露、重要流程无法查找或内容无法迁移，它就应进入硬门槛或高权重项。

五、具体案例与数据观察：用一个模拟试点看清差异

1. 场景设定：一个 24 人团队，资料分散在多处

下面的案例是情景模拟，用于说明如何设计测试，不是对某个真实组织或具体产品的测评。假设一个 24 人团队，日常需要维护客户处理流程、产品说明、项目决策记录和新成员指引，现有资料分散在共享文件夹、聊天记录和个人文档中。

团队的抱怨不是“缺少更多页面”，而是找资料要问人、旧版内容难辨认、相同规则出现多个版本。负责人因此决定比较两个符合硬性要求的候选方案，并先拿一小批常用资料做试点。

试点材料包括 30 篇页面、12 个附件、5 个流程主题和 10 个常见问题。参与者分为资料维护者、普通成员和新加入成员三类。测试不以页面美观打分，而是观察检索、协作、权限和迁移任务能否完成。

2. 把“找资料慢”拆成可观测的任务

团队先挑出 10 个真实问题，例如“客户资料无法打开时先检查什么”“哪个页面是当前的退款规则”“某项功能发布前由谁确认”。每位参与者不提前知道页面标题，只拿到问题描述，避免靠记忆直接跳转。

每次任务记录起止时间、访问页面数、是否找到有效答案、是否打开过期内容，以及是否向同事求助。结果只能解释这批资料和参与者的试点情况，但足以帮助团队发现：用户到底是不会搜索、目录不清楚，还是内容本身有冲突。

下表中耗时和完成率都是示意数据，目的是演示如何记录差异。真实项目应替换成自己的试用记录，并说明测试人数、任务数量、内容范围和测试日期。

3. 数字看起来有差异，也要检查差异来自哪里

假设候选方案乙的平均查找时间更短，不能马上得出“搜索一定更好”的结论。还要检查参与者是否更熟悉乙的操作方式，测试资料是否偏向乙的目录结构，任务难度是否一致，以及两边的内容是否同样完整。

打开过期页面次数较多，也不一定完全是工具问题。如果旧页面没有标记失效、多个版本标题相似，任何方案都可能受到影响。试点复盘要把产品因素和内容因素分开，避免将知识治理的缺陷归咎于搜索功能。

我会把每个发现分成三类：工具能力问题、内容质量问题、使用规则问题。能由工具配置解决的，记录配置方案；需要整理页面的，安排内容负责人；需要培训或规则约束的，明确责任人和复核时间。这样试点结果才会转成行动，而不是停留在一张比较表上。

4. 计算维护成本，而不是只统计上线速度

模拟团队还记录试点期间的投入：资料清理 6 小时、页面迁移 8 小时、权限配置 3 小时、用户说明 2 小时。数字不是行业平均值，只用于展示如何记录成本。若真实团队的数据明显不同，应以实际工作量和内容状态为准。

迁移时间之外，还要设置未来维护的观察窗口。短期试用可以发现页面是否容易创建，却不一定看得出一个月后是否有人更新。团队可以选 10 篇会变动的页面，记录负责人、复核日期和变更后的更新延迟，验证维护安排能否执行。

5. 试点结论应写成“适用条件”，而不是“谁赢了”

一个有用的试点结论可以这样写：在本轮 10 个检索任务中，某方案的有效答案命中数较高，导出附件符合团队要求；但权限设置仍需要管理员复核，且内容过期问题必须通过页面负责人制度解决。这样的结论比“方案乙更好”更能指导下一步。

还要说明哪些事情没有验证。例如，短期试点通常无法证明长期采用率，也无法代替安全、合规或大规模性能审查。把未验证事项列出来并安排核实，能避免团队把有限样本误读成全面保证。

六、按不同情况行动：把选型变成一套可执行的流程

1. 个人用户：用一周验证记录、回找和导出

个人用户可以先不做复杂评分表。挑一周内确实会产生的内容，按自己的习惯记录，再设置三个回找任务：凭标题找、凭关键词找、凭关联主题找。若每次都要先记起当时放在哪个目录，说明当前结构可能不适合自己的思维方式。

一周结束时，把内容导出一次，查看文件是否能在常见阅读环境中打开，图片和附件是否完整，目录是否仍然有意义。之后再决定是否长期迁入旧资料。先验证自己会不会持续使用，再决定要不要搬家。

1. 选 10 至 20 条真实记录，不用虚构的演示内容。
2. 覆盖临时想法、长文、清单和附件等不同类型。
3. 至少完成 5 次回找任务，记录是否找到正确内容。
4. 做一次导出，检查可读性、附件和文件组织。
5. 确认手机、电脑或常用访问方式是否符合日常习惯。

2. 小团队：选一个高频主题做试点，不要一次重建全部知识

小团队可以先选一个资料分散、问题重复出现的主题，例如客户处理流程或产品常见问题。明确试点范围、页面负责人和试用期限，再让不同角色完成相同任务。若第一轮连“哪份资料有效”都无法确认，先治理内容，不必急着扩大迁移规模。

每个页面至少应有可理解的标题、适用范围、负责人或维护方式，以及最近复核时间。并不是每篇内容都需要复杂审批，但用户要能分辨这是现行规则、历史记录还是个人备忘。标记方式应简洁一致，避免维护成本高到没人愿意执行。

3. 中大型组织：把权限、责任和运维放在试点前面

组织规模变大后，资料之间的访问边界和职责分工通常更复杂。试点前应确认安全、合规、信息系统和业务负责人的要求，明确哪些数据可以进入、谁有权管理、异常如何处理、备份和恢复由谁负责。

同时，不能只让管理员参与测试。实际使用者需要验证查找和协作，内容负责人需要验证维护流程，管理者需要确认治理成本可承担。若只有技术团队评估，最终系统可能满足部署要求，却没有解决员工的知识查找问题。

对于 100 人以上的组织，建议将试点设计成分阶段评估：先验证约束条件，再验证跨角色任务，之后才评估扩大范围所需的培训、治理和支持能力。具体规模划分不是产品适用性的自动判断，关键仍是权限复杂度、团队分布和维护资源。

4. 已有工具但效果不佳：先诊断症状，再决定迁移

已经在用工具的团队，未必需要立即换系统。若用户找不到资料，先检查标题、关键词、重复页面和失效内容；若没人更新，检查责任是否明确；若协作频繁出错，再检查权限和修改流程。只有当问题与工具能力直接相关，并且调整内容与规则仍无法解决时，迁移才更有依据。

迁移本身会带来学习成本和信息丢失风险。启动前先抽样导出一部分资料，核验附件、链接、层级和权限信息能否处理，再决定迁移范围。不要把“导出按钮存在”当成完整迁移方案。

5. 把试点做成有退出条件的实验

试点开始前要设定停止条件。例如，候选方案无法满足关键数据要求；核心任务多次无法完成；导出结果丢失关键附件；维护责任没有人承担。停止条件能防止团队因为已经投入时间，就不断为不合适的方案寻找理由。

也要设定扩大试点的条件，例如关键任务达到团队约定的成功标准，参与者能够在合理时间内独立完成，管理员可以解释权限配置，试点资料有人负责更新。具体阈值由团队根据风险设定，不应把示意数字当成行业统一标准。

七、不同情况下的取舍：没有通用答案，只有明确代价

1. 易上手与管理精细度之间的取舍

简单界面和较少配置，有利于快速开始，但可能无法覆盖复杂权限或治理要求；细致的管理能力可以满足更多组织约束，也可能增加配置、培训和维护负担。团队不应为了“以后也许用得到”提前承担全部复杂度。

判断方法是列出未来一年内确定会发生的管理任务，再看候选方案是否能够支持。尚无明确业务场景的功能，可以保留为观察项，不必当成当前选型的决定因素。

2. 自由组织与统一规范之间的取舍

让每个人自由建目录和标签，开始时很灵活，但团队规模扩大后可能出现同义标签、重复页面和分类冲突。统一模板能提高一致性，却可能让不同类型的内容被迫套入同一种结构。

比较稳妥的方式是只规范最关键的部分：内容类型、标题规则、负责人和失效标识；其他组织方式允许适度灵活。规则越多，越需要说明为什么存在、由谁维护，避免规范本身成为没人遵守的文档。

3. 即时协作与内容稳定性之间的取舍

多人能够快速编辑，有利于共同完善资料；但对于规则、标准或操作流程，修改过快也可能让读者不清楚哪个版本已经生效。团队应根据内容风险决定变更方式，而不是让所有页面都采用同一套审批等级。

低风险的团队笔记可以直接协作，高影响的操作说明则应有明确负责人和复核方式。关键不是追求最严格的流程，而是让用户知道当前页面是否有效、出现错误时由谁处理。

4. 快速迁移与内容清理之间的取舍

快速迁移能尽早让资料集中起来，但会把重复、过时和含糊内容一并带入；先清理再迁移更干净，却需要投入额外时间。可以按内容风险分层：高频、关键流程优先整理；低频历史材料先归档或保留在只读区域；不确定是否仍有效的内容先标注待核实。

不要用“全部迁完”作为唯一的项目成功标准。可以同时看高优先级内容覆盖率、有效页面比例、检索任务成功情况和待核实内容数量。对用户来说，少量可信的知识，通常比大量无法判断真伪的页面更有用。

5. 当前便利与未来可迁移性之间的取舍

某些工具的内容组织方式可能很方便，但如果依赖特定格式或内部链接，迁出时需要额外处理。反过来，过分追求通用格式也可能限制日常协作体验。正确做法不是要求零成本迁移，而是提前知道迁移会损失什么、需要多少人工补救。

至少定期抽样做一次备份或导出验证。确认导出内容是否可读、附件是否齐全、页面关系是否保留，并记录操作步骤。迁移能力不是“最后一天才考虑”的备选项，而是长期知识资产能否持续掌握的重要条件。

八、最终决策清单：用六个问题结束纠结

1. 我们是否明确了主要使用场景？

如果团队还不能说清楚知识库主要服务谁、记录什么、最常解决哪类查找问题，就先不要比较产品。把目标限定到一个具体场景，才能判断哪些能力是必须的。

2. 是否用真实资料测试过检索？

至少准备一组常见问题和真实内容，让不同角色独立查找，并检查他们是否找到有效版本。记录耗时、错误访问和求助情况，不把“搜索框能返回结果”当成检索成功。

3. 是否核实当前价格、套餐和功能边界？

功能、价格、免费额度和套餐限制可能变化。正式决策材料应记录核对日期和信息来源；无法确认的项目列为待核实，不凭旧印象做承诺。

4. 是否实际导出过内容？

测试页面、附件、目录关系和链接，不只检查是否出现导出文件。若导出需要人工处理，记录工作量和可能丢失的信息，并判断团队是否接受这个成本。

5. 是否有人负责维护知识？

至少明确高频页面的负责人、更新触发条件和过期处理方式。如果没有人承担这些工作，就应把这项限制带入选型结论和试点计划，而不是期待工具自动维护内容。

6. 是否写清哪些问题还没有验证？

试点通常无法证明长期采用率、所有权限场景或极端情况下的恢复能力。把未验证事项写进决策记录，安排后续核实，比用一个“全面通过”掩盖边界更负责任。

我的最终判断是：wiki 工具选型，本质上是在选择一种知识维护方式。如果内容没有负责人、页面没有有效状态、用户没有回找路径，换一个工具通常只会让旧问题换个界面继续存在。

下一步可以这样做：今天先选出一个最常被问到的知识主题，整理 10 到 20 篇真实资料，写下 5 个真实查找任务；再用统一口径测试不超过三个候选方案。把检索、协作、权限、导出和维护成本都记录下来，然后依据硬门槛和试点证据做决定。

选择困难时，不必追求一次找到“永远正确”的工具。先找到符合当前场景、能够持续维护、退出成本可接受的方案，再用真实使用反馈决定是否扩展。这样的决策未必最炫目，却更可能让知识库在半年后仍然有人打开、有人更新、也有人信任。