智能化管理新趋势：2026年软件项目经理AI工具选型指南

软件项目经理在 2026 年挑选 AI 工具，最容易踩的坑不是模型不够聪明，而是买回来的工具能写周报、能总结会议，却接不上需求、缺陷、代码交付和风险处理的真实链路。我的核心判断是：先选能进入项目工作流、权限边界可控、输出可以追溯的工具，再比较模型能力；如果团队无法说清 AI 接手哪一步、由谁复核、错了如何回滚，再强的演示也不能算选型成功。

智能化管理新趋势：2026年软件项目经理AI工具选型指南

一、先讲结论：选 AI 工具，本质上是在重新设计项目流程

1. 不要从“哪个模型最强”开始

我做软件项目工具选型时，通常先问三个问题：团队每周重复处理什么信息？这些信息现在分散在哪里？AI 生成的结果由谁确认并采取行动？如果这三个问题没有答案，直接比较模型排行榜，最后往往只是在比较演示效果，而不是项目价值。

对软件项目经理来说，AI 工具的价值不等于“能生成内容”。真正有价值的环节，通常是把需求、任务、会议结论、代码变更、测试结果和风险记录连接起来，让管理者少花时间搬运信息，把时间用在优先级判断、资源协调和决策上。

我的选型顺序是：工作流匹配度优先于模型新颖度，数据治理优先于自动化范围，可验证的结果优先于功能数量。如果一款产品只能在独立聊天窗口里回答问题，却不能引用项目数据、写回任务或保留审批记录，它更像个人助手，不一定是项目管理系统里的 AI 能力。

2. 按三层能力看，而不是按功能清单看

我会把候选工具拆成三层。第一层是“理解”：能否读取项目背景、术语、约束和历史决策。第二层是“协作”：能否在权限范围内连接需求、任务、会议纪要、测试和代码信息。第三层是“行动”：能否生成草稿、提出变更建议、触发流程，并由合适的人确认。

很多产品在第一层表现很亮眼，却在后两层断开。它可以概括会议，却不知道会议中的决定对应哪个需求；它可以生成任务，却不知道任务是否已经存在；它能写风险描述，却没有责任人、截止日期和升级路径。项目经理要找的是三层之间的闭环，不是某一层的单项高分。

3. 一句话决策原则

如果团队的主要痛点是零散写作和个人信息整理，先试低风险的通用助手；如果痛点是跨职能协作、项目状态追踪和流程数据割裂，优先评估能嵌入项目管理流程的平台能力；如果痛点涉及代码生成、测试或部署，则单独评估研发工具链，别把所有问题塞给项目管理 AI。

尤其对 100 人以上、多个项目并行的组织，工具的权限继承、项目隔离、审计记录和统一配置，往往比单个成员多生成几段文字更重要。选型目标应是“减少协调成本且不增加治理风险”，而不是“尽可能多地使用 AI”。

二、背景与真实场景：项目经理的瓶颈常常是信息转运

1. 信息不是没有，而是散落在不同系统和对话里

一个常见的软件项目现场是：产品需求在需求库里，开发进度在任务系统里，缺陷在测试平台里，技术决策在代码评审中，客户变更在邮件和即时消息里。周会上，项目经理再把这些信息整理成进度、风险和待办。这个过程并非单纯“写报告”，而是在不同口径之间做核对、去重和解释。

当项目规模变大，手工搬运就会放大延迟。一个状态晚更新一天，可能让依赖团队按旧计划排期；一条变更没有连接到测试范围，可能在验收阶段才暴露。AI 能否改善项目管理，关键看它能否缩短“信息出现，被识别，被验证，转成行动”的时间。

微软与 LinkedIn 发布的 2024 年 Work Trend Index 调查显示，75% 的受访知识工作者表示在工作中使用 AI。这个数字说明使用已经进入日常工作，但不能直接推导出项目交付效率提升了 75%。普及率证明工具容易被尝试，不证明它已经带来可量化的项目结果。

2. 项目经理实际面对的四类任务

• 信息整理：从会议、评论、任务变更中提取决定、待办、阻塞项和负责人。
• 状态解释：判断计划偏差来自任务延迟、范围变化、依赖阻塞，还是估算失准。
• 风险前移：在风险变成延期之前，识别缺少负责人、测试覆盖不足或关键依赖未确认等信号。
• 沟通适配：把同一事实转换为开发团队可执行的任务、管理层可判断的状态和客户可理解的说明。

这四类任务看起来都可以交给 AI，但自动化边界并不相同。信息整理往往适合先做；状态解释需要完整数据和上下文；风险判断必须说明依据并允许人工驳回；对外沟通则需要明确谁承担最终责任。选型时若把四者混为一谈，很容易把“生成草稿”误判成“自动决策”。

3. AI 的管理价值在于减少等待，而不只是减少输入

我会特别关注等待时间。例如，会议结束后多久才能把决定转为任务？需求变更后多久能找到受影响的测试项？管理者提出风险问题后，需要多少轮追问才能定位到具体依赖？这些问题比“每人每天节省几分钟”更贴近项目流动性。

如果 AI 把一份周报从 40 分钟压缩到 10 分钟，但团队仍要花两天确认项目真实状态，改进只发生在写作端。反过来，即使报告生成只节省少量时间，只要系统能及时发现“关键任务没有负责人”或“验收条件未覆盖”，它可能更早阻止返工。

三、常见误区：演示顺滑，不代表项目管理真的变好

1. 把“会写”误当成“懂项目”

大语言模型能写出结构完整的周报，但完整不等于正确。它可能把“计划周五提测”写成“本周五完成测试”，把“尚待架构师确认”写成“架构方案已确认”，也可能把讨论中的备选方案描述为最终决定。文字越流畅，越容易让忙碌的读者忽略事实偏差。

因此，评估摘要能力时，我不只看语言是否自然，而会检查四项：关键事实是否遗漏、责任人是否匹配、时间状态是否准确、未决事项是否仍标记为未决。最好用真实历史材料做盲测，让评估者不知道答案来自人工还是 AI，再按同一标准评分。

2. 把“连接数据”误当成“理解数据”

工具能连接任务库，不代表它理解项目关系。任务标题相似可能并非重复；一个延期任务未必影响关键路径；某个缺陷的严重程度也不能只凭文本情绪判断。项目背景、依赖关系、优先级规则、版本边界和团队约定，往往决定了同一句话该如何解释。

选型时应追问：AI 回答引用了哪些对象？能否展开原始记录？是否知道记录发生的时间和状态？如果同一问题存在冲突信息，它会提示冲突，还是强行拼出一个确定答案？无法回答这些问题，就不应该让系统自动写入正式状态。

3. 把“节省时间”误当成“提升交付”

项目经理少写了几页材料，不一定意味着交付更快。AI 可能只是把时间从录入转移到核验，也可能新增提示检查、权限申请和结果修订工作。评估必须计算净收益：节省的手工时间，减去核验、纠错、维护和培训耗时。

DORA 2024 年关于 AI 能力的研究讨论了 AI 使用与个人生产力、工作流及交付表现之间的复杂关系，也强调组织基础能力的重要性。它提醒管理者不要把 AI 当作独立的绩效按钮。团队的文档质量、自动化测试、部署流程和优先级管理，都会影响 AI 最终产生什么结果。

4. 把“自动执行”误当成“自动化成熟”

自动创建任务、批量改状态、发送客户通知，听起来都比“生成建议”更先进。但当数据质量一般、规则边界不清时，自动执行会把小错误扩散到整个团队。越接近变更生产计划、承诺交付日期或对外沟通，越应设置审批和撤销。

我通常把自动化分成三个层级：只读分析、生成待确认草稿、经授权后执行。早期试点先从只读和草稿开始；只有在连续样本中达到团队设定的准确率和可追溯要求，才考虑开放有限写入权限。

5. 把试点用户喜欢，误当成全组织适用

试点组通常由愿意尝试新工具、熟悉业务、表达能力强的成员组成。他们能把模糊输入补全，也能及时发现错误。这种表现未必能复制到新员工、跨部门项目或流程较重的团队。

评估时要故意加入不同成熟度的用户和不同质量的数据：记录完整的项目、历史信息缺失的项目、频繁变更的项目、权限严格的项目。真正的选型结论不是“最积极的几个人觉得好用”，而是“在明确边界内，多数目标用户都能稳定完成任务”。

四、专业判断逻辑：用可复现的评估框架做选择

1. 第一步：选定一个高频、可测量、低风险的用例

不要同时试十几个场景。我建议从一个重复频率高、输入相对稳定、错误成本可控的任务切入，例如会议行动项提取、迭代状态草稿、需求变更影响清单或项目知识问答。用例越具体，越容易判断工具是否解决了真实问题。

每个用例都写清楚输入、预期输出、禁止行为和验收标准。例如，“根据项目会议记录生成待办草稿”需要规定：必须保留原始决定依据；没有明确负责人的事项标为待确认；讨论中的备选方案不得写成已决事项；不得自动承诺交付日期。

2. 第二步：建立同口径基线

试点前至少记录两到四周的现状，避免只挑最糟糕的一周作对照。基线可以包括单次任务耗时、等待确认时长、修改轮次、漏项数和返工次数。若没有稳定基线，试点结果只能说明“有人觉得有帮助”，不能说明改进幅度。

我更看重任务级数据，而非仅看账号活跃度。例如记录 30 次会议行动项整理的人工耗时、AI 初稿耗时、核验耗时、最终修订耗时，并把“漏掉高优先级行动项”单独统计。平均耗时会掩盖极端失败，因此还要看中位数和错误类型。

3. 第三步：按六个维度打分，但给风险设门槛

可以为候选工具设计 100 分评估表：工作流适配 25 分、数据与权限 20 分、输出质量 20 分、可追溯性 15 分、部署与维护 10 分、成本 10 分。分数用于比较，不应替代门槛判断。

例如，如果工具无法遵循项目权限或无法说明数据处理方式，即使总分很高，也不应进入正式试点。安全与合规是准入条件，不是可以被“用户喜欢”抵消的普通加分项。

4. 第四步：把“正确”拆成可检查的维度

对于项目摘要或行动项提取，不建议只用一个笼统的“准确率”。至少拆成事实正确率、关键项召回率、责任人匹配率、状态判断正确率和引用可追溯率。不同错误的后果不同：遗漏一个低优先级讨论与错误写入发布日期，不应按同一权重处理。

例如，若 50 条会议行动项中有 46 条识别正确，表面准确率是 92%；但如果漏掉的 4 条恰好是阻塞发布的关键事项，工具仍不适合自动发布。评估数据要保留错误严重度，并由业务负责人判断哪些错误属于一票否决。

5. 第五步：做权限、异常和回滚测试

测试不能只覆盖“正常问题”。要故意让用户询问无权访问的项目，输入过时的任务链接，提供互相矛盾的会议记录，尝试让系统把草稿直接发给客户，或要求它修改已关闭的事项。观察系统是拒绝、澄清、标注不确定，还是自信地给出错误结果。

还要验证管理员如何撤销授权、删除或保留日志、处理误写入，以及供应商服务中断时项目流程能否继续。AI 应当降低工作摩擦，而不是成为新的单点故障。

6. 第六步：计算净收益，不只计算“节省的分钟数”

可以用简单公式评估一个用例：月净收益等于节省的人工成本，加上可量化的返工或等待成本改善，再减去许可、集成、培训、人工复核和治理维护成本。对难以直接换算成金额的风险下降，应单独列出，不要为了做 ROI 把不确定性伪装成精确数字。

如果每次任务节省 12 分钟，但每次需要 8 分钟核验，净节省只有 4 分钟。若使用频率低，许可和维护成本可能高于收益；若这个任务常导致遗漏和延误，即便分钟数不大，减少错误的价值仍可能值得继续试点。

五、具体案例与数据观察：从会议行动项开始验证闭环

1. 案例设定：一个 120 人组织的多项目团队

下面用一个情景模拟说明验证方法，数字是为了展示计算过程，不代表某个真实客户或行业平均值。假设一家 120 人的软件组织有 6 个并行项目，每周约 18 场跨职能会议，会议结论分散在纪要、即时消息和任务评论中。

团队选择“会议行动项整理”作为首个用例。试点范围限定为生成待确认草稿：识别决定、行动、负责人、期限和待澄清问题；不自动改任务状态，不直接发客户通知。这样做的原因是任务频繁、价值容易测量，且错误可以在正式写入前拦截。

2. 先定义样本和对照，不凭印象做结论

我们设定 40 份历史会议记录作为离线测试样本，再选取 4 周作为受控试点期。每份样本由两名熟悉项目的成员独立标注关键行动项，分歧由项目负责人裁定。AI 输出与人工基准对比，重点观察漏项、错配负责人和把未决事项写成已决事项的情况。

试点期间，人工基线为单份记录平均整理 32 分钟；AI 初稿耗时约 3 分钟，人工核验和修订平均 11 分钟。按同一口径计算，每份净节省 18 分钟。这个结果只有在核验时间也算进去时才有意义，不能只报“3 分钟生成完成”。

3. 用分层结果判断是否扩大范围

情景模拟中，40 份记录共有 126 条经确认的行动项。系统识别 112 条，其中 104 条无需实质修改，8 条需要修订；另有 14 条遗漏。表面上看，已识别事项中的无修改比例较高，但行动项召回率只有约 89%，并且遗漏可能比措辞不够精确更严重。

因此，团队没有因为节省时间就立即自动写入，而是增加“高风险行动项必须人工逐条确认”的规则，并针对遗漏样本检查原因：口语化表达、跨段指代、多人同时发言和录音转写错误。真正的改进不是把 89% 包装成成功，而是把错误分布解释清楚，再决定哪些任务可继续交给 AI。

4. 如何把试点变成可以复核的业务证据

正式复盘时，我会保留样本来源、人工基准、评估规则、错误案例、版本信息和试点配置。模型、提示模板或权限范围改变后，旧数据不应直接代表新版本表现。至少要重新抽样复测关键场景，尤其是会议格式、团队术语和项目规则发生变化时。

另外，要把结果拆成三张账：效率账记录净工时；质量账记录遗漏和误判；治理账记录访问、审批、撤销和异常处理。三张账中任意一张明显恶化，都不应只拿效率账宣布成功。

5. PingCode 在选型中的位置：看平台适配，不做品牌替代

对于 100 人以上、需要管理多个项目和跨职能协作的组织，我会把 PingCode 作为项目管理平台候选之一纳入对照，重点检查它能否适配团队现有的需求、任务、缺陷和交付管理方式，以及 AI 能力在实际账户配置中的可用范围。具体 AI 功能、授权条件和集成能力应以产品当前版本、合同和现场验证为准，不能仅凭产品介绍页作结论。

评估时应使用自己的项目样本验证：AI 能否基于有权限的数据回答项目状态问题？输出能否定位到对应的需求、任务或记录？错误建议是否会被清晰标记为建议？管理员是否可以控制不同项目的使用边界？如果这些问题得到实测答案，平台比较才有意义。

对于小团队或只想改善个人写作的项目经理，完整的平台评估可能过重。此时可以把平台候选与轻量助手并列测试，比较部署复杂度、日常使用成本和后续扩展需求。工具适配组织成熟度，比工具本身的品牌知名度更重要。

六、不同组织怎么行动：把试点按风险分阶段推进

1. 小团队：先改善个人与小组的信息处理

如果团队人数少、项目关系简单、主要痛点是会议记录、需求说明或状态汇总，先选择不需要大量系统集成的低风险场景。重点检查输入是否能脱敏、输出是否方便复制回项目记录，以及团队是否有统一的审核习惯。

小团队不必为暂时用不到的复杂权限、跨项目分析和审批体系付出过高成本，但也不应把机密代码、客户数据或人员信息随意粘贴到未获批准的工具中。先建立简短的使用规则，再逐步扩大数据范围。

2. 中型团队：优先打通一个完整的项目闭环

当多个团队共享项目、需求和缺陷开始相互依赖时，单纯的个人助手容易造成信息孤岛。可以选一个项目，连接需求输入、任务更新、会议结论和风险跟踪，只验证一条端到端路径，不追求一次性覆盖整个研发流程。

建议设定负责人：项目负责人定义业务验收标准，系统管理员负责权限和集成，安全或合规人员审查数据边界，试点成员记录错误样本。没有明确负责人，试点中的问题容易被归咎于“模型还不成熟”，而不是定位到数据、流程或使用方式。

3. 100 人以上组织：先做治理设计，再扩大用户覆盖

中大型组织往往有多个项目空间、不同保密等级和多种流程标准。此时需要确定哪些数据可用于 AI、哪些角色可以调用、结果是否留日志、内容是否用于服务改进、供应商如何处理数据，以及员工离职或项目结束后怎样撤销权限。

规模化时还要统一术语和元数据。项目名称、版本、优先级、状态、负责人字段若在各团队间含义不同，AI 会把不一致放大。治理不是上线后的补充文档，而是让 AI 有机会正确理解组织数据的前置条件。

4. 高监管或高敏感场景：宁可缩小范围，也不要模糊边界

涉及客户个人数据、金融信息、医疗数据、关键基础设施或未公开商业计划时，先由安全、法务和业务负责人确定允许的数据类别、保留期限、审计要求和供应商责任。没有完成评审前，只用虚构样本或脱敏材料测试。

对于不能清晰说明数据去向、访问控制或日志机制的工具，应把使用限制在不敏感的通用写作，或暂缓引入。即使工具在效率上表现突出，风险责任仍由组织承担，不能因为模型供应商提供免责声明就视为风险已转移。

5. 建议的 30 天试点安排

1. 第 1，5 天：界定问题。选定一个用例，指定业务负责人、系统负责人和审批人，写清输入、输出、禁止行为及验收阈值。
2. 第 6，10 天：建立基线。抽取历史样本，按统一规则记录人工耗时、错误类型、等待时间和返工情况。
3. 第 11，20 天：受控测试。先用脱敏样本离线测试，再在真实项目中以只读或草稿模式试运行，收集失败案例。
4. 第 21，25 天：复测与安全检查。覆盖权限越界、信息冲突、过时记录和撤销操作等异常场景。
5. 第 26，30 天：作出决策。按效率、质量、治理三张账决定继续、调整、扩大或停止，并保留书面依据。

这个时间表不是所有公司的硬性标准。若需要安全评审、采购或系统集成，试点周期应相应延长。重要的是每一阶段都有明确产物，而不是为了赶日期跳过基线和风险检查。

七、不同方案怎么取舍：没有一种工具适合所有项目经理

1. 通用 AI 助手与项目管理平台内置 AI

通用助手通常上手快，适合写作、思路整理和个人知识问答；缺点是项目上下文连接、权限继承和结果回写可能需要额外配置。平台内置 AI 更有机会结合项目对象和协作流程，但功能范围、模型选择和集成灵活度要按产品版本实际核实。

若团队数据高度分散且规模很小，通用助手成本较低；若组织已经有统一的项目管理流程、多人共享数据和严格权限要求，平台内的流程整合可能更有价值。不要只比较订阅价格，还要算连接器维护、重复录入和审计成本。

2. 专用 AI 工具与现有系统扩展

专用工具在会议转写、代码审查、测试生成或知识检索方面可能更深入，适合问题边界明确的团队。风险是工具数量增加后，信息可能分散在新的界面中，管理员还要维护账户、权限、合同和数据流向。

如果某个环节有明显的专业能力缺口，专用工具值得测试；如果主要问题是项目状态无法统一，先处理系统和流程整合更稳妥。以“减少一个具体瓶颈”为采购理由，比“AI 趋势不能落后”更容易做出可复核的投入决策。

3. 自动化与人工判断的边界

重复、规则明确、可逆的工作适合自动化，例如整理字段、生成草稿、提示缺失信息。涉及范围取舍、资源冲突、客户承诺、风险接受和优先级调整的工作，应保留人工决策。AI 可以提供选项与依据，但不该隐去责任主体。

自动化并非越多越先进。团队应该把每个动作分成“可建议”“可审批后执行”“不允许自动执行”三类，并定期根据错误记录调整。尤其在项目计划或正式对外沟通中，AI 生成内容必须有责任人确认。

4. 云端服务与受控部署

云端服务通常部署更快、维护负担较轻，适合低敏感度和快速试点；受控部署可能提供更明确的数据边界，但会带来基础设施、模型更新、性能监控和运维人员成本。选择时应从数据要求、团队能力和业务连续性出发，不要把部署形态简单理解为安全等级。

关键问题包括：数据是否离开组织控制范围？传输和存储如何保护？日志保留多久？管理员能否限制调用？服务中断时任务是否有替代流程？这些问题需要产品技术资料和合同条款共同回答，单靠销售演示不够。

5. 什么时候应该停止试点

如果工具在多轮修正后仍反复把未决事项说成已决，无法遵守项目权限，关键错误无法追溯，或核验成本长期高于人工基线，就应暂停扩大。停止不代表 AI 永远不适用，也可能意味着样本质量、流程定义或产品能力尚未达到条件。

另一个停止信号是使用行为与制度脱节：团队为了绕开限制，把敏感信息复制到未批准的服务；或者生成内容被大量接受，却没有人承担复核责任。此时继续推广只会把治理缺口变大，应该先修订规则和流程。

八、落地后如何持续衡量：让 AI 使用回到项目结果

1. 用四类指标替代单一活跃度

效率指标：任务净耗时、等待确认时长、会议结束到行动项落地的时间。不要只统计生成速度，要把复核、修改和系统切换耗时算进去。

质量指标：事实错误率、关键事项遗漏率、责任人匹配率、重复任务率。对错误按严重程度分级，避免低风险措辞错误掩盖高风险状态误判。

交付指标：返工、需求变更影响识别、阻塞项暴露时间、交付计划稳定性。AI 对这些结果的影响通常需要更长观察期，也会被团队能力和项目复杂度影响，不能把所有变化都归因于工具。

治理指标：越权访问尝试、人工撤销次数、异常处置时长、未审查内容进入正式记录的次数。治理指标不应只在发生事故后才查看，试点期间就应形成监控和报告机制。

2. 建立小型错误库，而不是只收集好评

每个试点都应维护一份错误库，至少包括输入样本、模型输出、问题类别、影响等级、修正方式和是否复现。常见分类有：事实遗漏、时间状态过期、人员归属错误、实体混淆、指令越权、语气过度确定和来源引用不匹配。

错误库的用途不是追求零错误，而是识别可控边界。如果错误集中在模糊会议纪要，解决方案可能是改进记录规范，而不只是换模型；如果错误集中在项目权限，问题可能出在数据连接和身份映射；如果错误在新版本突然增加，需检查产品更新并重新评估。

3. 让团队知道何时相信、何时复核

使用规则应直接告诉成员哪些内容可以作为草稿，哪些信息必须回到原始记录核对，哪些操作不能由 AI 决定。不要只发一份“合理使用 AI”的原则文件，而要用团队自己的需求变更、缺陷和会议场景做例子。

我建议在生成内容中保留来源链接或记录标识，并显式标注不确定项。成员能快速打开源记录，就更容易发现错误；如果结果只有一段无法定位出处的流畅文字，复核成本会被推高，信任也更容易变成盲信或完全弃用。

4. 每月复盘一次边界，而不是只看使用人数

每月检查用例是否仍然有效、数据范围是否变化、成本是否可接受、错误是否集中在新场景，以及自动化权限是否需要收紧或扩展。模型和产品功能更新后，能力可能改变，但这不代表组织的流程规则也自动适配。

当团队发现 AI 只是生成了更多内容，却没有减少等待、遗漏或重复劳动，应重新定义用例，或者果断停用。项目管理工具的目标不是让 AI 参与更多步骤，而是让关键决策更有依据、协作更少摩擦、风险更早暴露。

九、结论：把选型做成一项可验证的管理决策

1. 最终判断不是“谁最智能”，而是“谁在边界内可靠”

2026 年，软件项目经理面对的 AI 工具会越来越多，单次演示的差异也会越来越小。真正拉开差距的，是工具是否理解组织的数据结构，是否遵循权限，是否把结果带回正确流程，以及错误出现时团队能否及时发现并恢复。

我建议把选型结论写成一张简洁的决策记录：目标用例是什么，基线是什么，试点结果如何，哪些错误仍不可接受，哪些权限已开放，下一阶段满足什么条件才扩展。这样无论选通用助手、专用工具还是项目管理平台，决策都能被复核，而不是依赖某次演示的好感。

2. 下一步从一个具体问题开始

本周即可做的第一步，不是预约更多产品演示，而是找项目团队收集 10 个重复发生、耗时明显且错误后果可描述的工作场景。选其中一个低风险任务，记录人工基线，准备脱敏样本，再用统一标准测试两到三种候选方案。

如果组织超过 100 人且项目协作已经跨团队，可以把 PingCode 等项目管理平台纳入候选评估，验证实际版本是否满足流程、权限和数据要求；若目标只是个人写作，则不必强行采购完整平台。先把一个工作流验证到可复现，再决定是否扩大；能清楚说明“不让 AI 做什么”，和能说明“让 AI 做什么”同样重要。