2026年功能规划软件大盘点：8款提升项目效率的顶级工具

2026年挑功能规划软件，最容易踩的坑不是选到“功能不够多”的产品，而是把投票数、路线图和需求池都搬进系统后，团队仍然说不清为什么做这个功能、谁负责验证、什么结果算成功。下面盘点的8款工具，分别适合不同的规划成熟度和协作方式；我更建议先按决策流程筛选，再比较功能，而不是先看榜单名次。

2026年功能规划软件大盘点：8款提升项目效率的顶级工具

一、先讲结论：没有通用第一名，先找最适合自己的规划闭环

1. 八款工具分别适合什么团队

如果只想先记住结论，可以把这8款工具分成三类：产品管理平台型、产品发现与路线图型、轻量可视化规划型。它们都能帮助团队整理功能，但解决的问题并不相同。

• PingCode：适合希望把需求、研发协作、测试和交付放在一套工作流里管理的中大型团队，尤其是100人以上、跨部门协作复杂的组织。
• Aha! Roadmaps：适合有较成熟产品管理职能、需要管理战略目标、产品组合和路线图的团队。
• Productboard：适合客户声音来源多、需要将反馈整理成洞察并连接到产品决策的团队。
• Jira Product Discovery：适合已经深度使用相关研发协作体系，希望把探索阶段的机会、优先级和交付工作衔接起来的团队。
• airfocus：适合需要灵活配置优先级模型、路线图视图和产品组合规划的团队。
• Craft.io：适合需要把产品策略、计划、需求和团队协作放进较完整产品管理空间的团队。
• ProductPlan：适合需要快速制作、分享和维护路线图，且路线图沟通是主要诉求的团队。
• Roadmunk：适合重视路线图呈现、利益相关方沟通，以及跨团队时间线视图的团队。

这些定位是选型起点，不是对产品能力的绝对边界。各产品的套餐、集成、权限和功能会持续调整，采购前应以官方当前产品说明和实际试用为准。

2. 我会把“功能规划”拆成四个连续动作

功能规划不是在白板上排一串功能名，而是一个从问题到结果的决策过程。我评估工具时，会检查它能否承接四个动作：收集问题、形成机会判断、安排资源与顺序、回看上线效果。

如果工具只能把需求放进列表，却无法把需求连接到用户证据、目标、负责人和结果指标，它更像需求登记簿，而不是完整的规划系统。反过来，如果工具功能很全，却要求团队重复录入、维护大量字段，系统也可能变成新的行政负担。

3. 选型时先看决策摩擦，而不是功能数量

我建议把首要问题设为：目前最昂贵的决策摩擦发生在哪里？是客户反馈散落在多个渠道，是优先级经常被临时关系左右，是产品与研发反复确认范围，还是管理层看不懂路线图？不同摩擦对应不同工具侧重点。

一款功能规划软件是否“顶级”，取决于它能否降低你当前最贵的协作成本，而不是它有多少张看板、多少种图表或多少个集成入口。团队规模、流程约束、数据迁移成本和本地化要求，往往比功能清单上的勾选数更能决定最终效果。

二、为什么功能规划越来越难：问题不在需求少，而在证据和执行断开

1. 反馈越来越多，可靠决策却没有同步变多

产品团队可以从销售访谈、客服工单、用户研究、应用评价、埋点和内部建议中收集大量信息。真正困难的是把这些声音归纳成可验证的问题，而不是把每条建议都变成一项功能。

同一个问题可能由不同用户用完全不同的语言表达；同一个功能请求也可能来自不同原因。若只按请求出现次数排序，容易把“声音最大”误判成“价值最高”。规划工具要能保留来源、用户类型、场景和证据强度，才有机会让讨论回到问题本身。

2. 路线图一旦变成承诺表，调整成本会被放大

路线图常被误用为精确到日期的功能交付承诺。市场变化、技术评估和资源调整本来就会改变计划；如果外部沟通把所有想法都包装成确定日期，团队最终只能在“不断改期”和“硬做低价值功能”之间选择。

更实用的做法，是区分探索中、已承诺和已交付的内容，并明确时间精度。季度方向可以表达目标，近期计划可以具体到迭代，长期机会则不应假装已经排定。工具需要帮助团队表达这种确定性差异，而不是只提供一条漂亮的时间轴。

3. 大型组织真正的难点是上下游协作成本

对100人以上的组织而言，功能规划通常要连接产品、设计、研发、测试、销售、客服和管理层。信息在角色之间传递时，最常见的损耗不是“没人知道功能名称”，而是目标、范围、依赖关系和决策依据逐步丢失。

这也是为什么大型团队不能只看路线图展示。还要核对权限和字段是否能适配现有流程，需求如何进入研发执行，变更如何被记录，管理层能否获得汇总视图，以及团队是否需要维护两套相互矛盾的计划。

4. 软件并不能替代产品判断

工具能提升信息可见性，却不能自动回答“这个问题是否值得解决”。评分模型可以把假设写得更明确，但无法替代用户研究、业务分析和风险评估。若输入证据本身存在偏差，自动排序只会更快地放大偏差。

因此，我把软件看作决策流程的承载层，而不是决策本身。选型时要确认工具是否让团队更容易提出问题、检查依据和修改判断，而不是只看它能否把分数算出来。

三、常见误区：看起来像规划，实际可能只是在整理列表

1. 把客户投票数直接当成优先级

投票能表达关注度，却无法完整反映问题的普遍性、商业影响、用户价值和实现成本。积极参与投票的用户往往不是总体用户的随机样本；付费客户、活跃用户和内部同事的声音也可能被过度代表。

更稳妥的做法是把投票当作一个信号，并与用户分层、问题频率、流失风险、收入影响、战略目标和研究证据结合。工具最好允许团队查看原始反馈和聚合逻辑，避免一个总分掩盖来源差异。

2. 把时间线做得越细，误认为计划越可靠

精确日期看起来有管理感，但在不确定性很高的阶段，过早承诺具体交付日只会制造虚假的确定性。规划对象越远，日期预测通常越容易受到范围、依赖、人员和技术风险影响。

我更倾向于按确定性分层：远期表达目标和机会，近期表达有明确负责人和可验证范围的工作，已进入开发的事项才进一步沟通预计交付区间。若产品只提供日期甘特图，却不支持表达假设与信心程度，团队要额外设计管理约定。

3. 用单一评分公式替代讨论

RICE、加权评分或成本收益模型可以帮助团队统一语言，但不应被当成客观真理。触达人数、影响程度和信心等级都需要定义口径；不同产品线即使使用同一公式，参数尺度也未必可比。

评分的价值在于暴露分歧。例如，市场团队认为某项改动影响高，研发团队却认为风险和成本远高于预估。工具应支持记录分歧、假设与决策人，而不只是输出一个看似精确的分数。

4. 认为接入研发系统就已经打通端到端

集成存在，不等于流程打通。要检查信息能否双向更新，字段映射是否稳定，计划变更是否有记录，链接能否让不同角色看到适合自己的上下文，以及断开连接时如何处理。

如果产品规划平台和研发系统分别要求维护负责人、状态和日期，最终仍会出现“哪个系统才是准的”这一问题。试点时应选真实需求走完整流程，测量重复录入和同步失败，而不是只看集成目录里有没有对应图标。

5. 只看采购价格，不算迁移与维护成本

实际成本不止订阅费用，还包括初始配置、数据清洗、历史记录迁移、权限设计、集成开发、培训、管理员维护和流程调整。轻量工具单价可能较低，但若团队需要大量补充管理动作，总拥有成本未必更低。

相反，功能丰富的平台也不一定适合所有团队。如果只有少数人维护，其他角色只偶尔查看，复杂权限和工作流可能成为负担。选型必须同时评估购买成本和持续运营成本。

四、专业判断逻辑：用六个维度把候选工具筛到可验证

1. 先定义决策对象：问题、机会还是交付项

不同团队口中的“功能”，可能指用户问题、产品机会、用户故事、研发任务或版本交付项。若这些对象没有区分，反馈汇总和路线图必然混乱。选型前先写清楚：什么是进入规划池的对象，什么阶段转成执行事项，谁有权改变状态。

我通常用一个真实需求做演示：从客户原话开始，找到对应问题，补充证据和目标，再形成候选方案，最后关联执行工作和结果指标。任何一步需要复制粘贴到另一个系统，都要记录原因和成本。

2. 检查优先级模型是否可解释

好用的评分体系不是维度越多越好，而是团队能解释每个维度为何存在、由谁填写、如何校准、多久复审。可以先从三到五个核心维度开始，例如战略契合、用户影响、证据置信度、紧迫性和实现成本。

若一个工具支持自定义公式，试点时不要只验证公式能否运行，还要检查低、中、高分的判断标准是否一致。否则团队会把模型变成复杂的数字表演：看似量化，实则每个人心中都有一套分数解释。

3. 把规划视图和执行视图分开评估

管理层需要看战略目标、投入方向和主要依赖；产品负责人需要看机会、证据和优先顺序；研发团队需要看范围、验收标准和工作状态。所有人看同一张大表，通常既不够简洁，也不够具体。

优先选择能按角色提供不同视图、同时保持数据关系清晰的工具。若必须通过复制多份路线图满足不同对象，应当追问这些视图是否基于同一份数据，以及修改如何同步。

4. 核实数据治理与部署约束

企业选型要把安全、访问控制、审计、数据驻留、单点登录、备份和权限继承纳入前置评估。某些团队还需要本地部署、专属环境或特定行业合规能力，这些属于硬约束，不应等到试点完成后才发现。

这里不宜根据产品宣传页做推断。应由信息安全、法务、采购和业务负责人共同核对当前版本的官方材料、合同条款与实际配置，并要求供应方对关键要求书面确认。

5. 评估集成质量，而非集成数量

先列出真正需要交换的数据：需求链接、负责人、状态、版本、优先级、目标和结果。然后判断谁是主数据源、同步频率是多少、字段冲突如何处理、失败如何告警。

如果集成只是单向创建任务，适合轻量试点；若团队要求双向状态同步、审计追踪和跨项目汇总，就必须用实际环境验证。不要因为演示环境里的数据是干净的，就忽略生产环境中的字段差异和历史遗留。

6. 用四周试点验证，不用一次性大迁移赌结果

我建议先挑一个产品线、一个明确问题和一组跨职能角色，设定四周左右的试点周期。此周期是实践建议，并非行业标准；工作节奏更慢的组织可以延长，但试点必须设定开始和结束条件。

1. 第一周梳理现有流程、对象定义和关键数据，记录基线。
2. 第二周配置最少字段与视图，让团队用真实需求运行。
3. 第三周观察反馈到决策、决策到执行之间的断点，记录重复录入和等待。
4. 第四周复盘结果，决定扩大、调整或停止试点。

五、八款功能规划软件逐一拆解：优势要和适用边界一起看

1. PingCode：适合需要规划与研发协作衔接的中大型组织

当组织不只需要排路线图，还希望将需求管理与研发、测试、交付过程连接起来时，PingCode值得纳入候选。对于100人以上、涉及多个产品团队和共享研发资源的组织，平台化协作能够减少规划信息与执行信息之间的断层。

评估时重点看需求层级是否贴合现有流程，产品目标和执行事项如何关联，跨团队依赖是否清晰，以及管理视图能否从团队层汇总到项目组合层。大型组织还要确认权限、工作流配置和数据治理能否适配内部制度。

它的优势在于可以考虑更完整的研发协作上下文；相应的取舍是，流程越复杂，越需要投入前期梳理和管理员运营。若团队只有几名产品人员，需求量有限且不需要系统化研发协作，一套轻量路线图工具可能更省事。

2. Aha! Roadmaps：适合重视战略、组合规划和产品管理体系的团队

Aha! Roadmaps常被纳入成熟产品管理团队的候选名单，原因是其规划思路更关注战略目标、产品组合和路线图之间的关系。若组织需要对不同产品线、业务目标和资源方向进行统一沟通，它的产品管理定位值得重点评估。

试用时，不要只看路线图能否展示，而要观察战略目标是否真的参与优先级判断，组合视图是否支持管理者做资源取舍，以及从想法到计划的关系能否保持清晰。

需要留意的是，体系完整通常意味着团队必须先建立相应的产品管理习惯。若公司尚未明确目标层级、产品责任人和路线图沟通规则，工具本身不会自动补上这些治理能力，反而可能增加配置工作。

3. Productboard：适合把客户反馈转成产品洞察的团队

Productboard的典型评估场景，是反馈来源多、产品团队需要识别共性问题并让决策更贴近客户证据。它适合关注反馈整理、用户洞察与规划衔接的团队，尤其当销售、客服和产品研究都在贡献信息时。

演示时建议拿一组真实反馈做测试：能否保留原始语境，能否按客户、细分市场或问题归类，能否区分重复声音与独立证据，最后是否能解释某个机会为何进入计划。

主要取舍在于，反馈采集和归类若没有稳定的责任人与规范，信息很快会堆积。团队要评估日常运营成本，以及产品规划、研发执行之间的连接是否满足自身流程，而不是只关注洞察界面的呈现效果。

4. Jira Product Discovery：适合已有相关研发协作基础的团队

如果团队已经在相关研发协作环境中工作，Jira Product Discovery可以作为探索阶段管理的候选，重点看它能否帮助团队把机会、优先级和交付协作联系起来。已有工具基础可能降低上下文切换，但不能替代对工作流的验证。

试点时要检查产品发现与执行项目之间的对象关系、权限边界、字段映射和视图维护方式。特别是多个团队使用不同工作流时，管理层汇总是否清楚，产品人员是否需要在多个项目之间重复维护信息。

它可能更适合希望在既有工具体系内扩展产品发现流程的团队。若组织并没有相关系统基础，或不同部门的数据治理差异较大，则应把实施和治理成本纳入比较，不要只把“同一生态”视为自动优势。

5. airfocus：适合需要灵活调整优先级和路线图视图的团队

airfocus适合重点考察优先级方法、路线图视图和产品组合规划灵活性的团队。它可以作为希望让不同团队按各自场景配置决策视图的候选，尤其适合产品负责人需要向多个受众解释规划的环境。

试用时应验证自定义字段和评分模型是否容易理解，路线图视图更新是否与底层数据一致，以及管理者能否在组合层看清资源分布和依赖。灵活性越强，越要设定配置边界，避免每条产品线都定义一套不可比较的标准。

如果团队需要的是稳定、简单、低维护的共享路线图，过度配置会削弱灵活性的价值。建议先约定统一核心字段，再允许少量局部扩展，不要在试点第一周就复制所有现行表格。

6. Craft.io：适合希望在统一空间管理产品计划的团队

Craft.io可纳入需要把产品策略、规划内容和团队协作放在相对完整空间中考察的候选。对于希望减少分散文档，同时让计划与产品工作保持联系的团队，应该重点评估它对自身产品管理流程的覆盖程度。

实际测试可以从一个产品目标出发，依次检查机会、需求、优先级和计划视图之间的关联。若信息结构需要大量自定义才能对应团队概念，应进一步比较配置成本与流程收益。

取舍在于，完整的产品工作空间需要团队接受较一致的对象定义和维护习惯。如果组织各产品线的流程差异很大，统一模板可能让部分团队觉得约束过强；若只需要一张对外路线图，则可能用不到其完整规划能力。

7. ProductPlan：适合以路线图制作与沟通为主要任务的团队

ProductPlan适合评估路线图的制作、更新与分享体验。对于经常需要向管理层、客户或跨部门伙伴解释规划方向的团队，路线图的易读性和分享效率具有实际价值。

演示时重点看不同受众的视图是否容易维护，计划内容能否标识目标、负责人、状态和确定性，调整之后是否可以快速同步给利益相关方。路线图只要能减少反复制作演示材料，就可能带来可见收益。

但路线图呈现不等于完整的反馈管理和研发执行闭环。若团队需要深入管理客户证据、复杂依赖、工作流和交付状态，应验证是否需要与其他系统组合使用，并把双系统维护成本一并计算。

8. Roadmunk：适合重视路线图可视化和跨团队沟通的团队

Roadmunk适合关注路线图可视化、时间线表达和跨团队沟通的团队。若目前的主要痛点是计划分散在多个表格、外部受众难以理解优先级和阶段安排，可以通过真实业务案例评估它的展示与协作体验。

要验证路线图能否表达不同时间范围、不同团队视图和计划确定性，并检查路线图调整后相关角色如何获知变化。对于多产品线组织，还应确认跨团队依赖和汇总视图是否符合实际沟通方式。

其适用边界与路线图工具普遍相似：如果团队更需要深度需求分析、客户反馈治理或研发流程管理，单靠可视化路线图可能不够。产品展示是否直观，应与数据维护和系统连接能力同时评估。

9. 用一张表快速缩小候选范围

表格用于缩小候选，不代表统一评分或名次。产品版本、部署选项和商业套餐可能随时间变化，采购时应对照官方当前资料，并要求供应方按自身场景演示。

六、案例与数据观察：用一个虚构但可复算的团队情景看规划改进

1. 情景设定：十二人产品团队，每月处理约八十条需求线索

下面用一个明确标注的情景模拟说明如何评估规划工具，不把它包装成真实客户案例。假设一家B2B软件公司有12人产品团队，每月收到约80条需求线索，来源包括客服、销售、客户成功和内部建议。

团队原先用表格登记反馈，用即时通讯讨论优先级，再由产品经理把选中的事项手动录入研发系统。不同渠道对同一问题使用不同描述，管理层看路线图时也难以辨认哪些是方向、哪些是承诺。

2. 先记录基线，再定义试点成功标准

这个情景不以“上线新系统”作为成功标准，而是观察几项结果：反馈是否可追溯、决策等待是否缩短、重复录入是否减少、进入研发后的范围澄清是否改善，以及团队是否能说明每项优先事项背后的证据。

为了避免伪精确，以下数字都是示意数据，代表可以在真实试点中采集的口径。实施前应从团队工作记录、系统时间戳和访谈中建立自身基线。

3. 规划流程改善不等于产出数量增加

如果需求整理更快，团队未必应该马上承接更多功能。更好的结果可能是少做低价值项目、提前识别风险、让产品和研发更早达成范围共识。效率指标需要和质量或结果指标一起看，避免为了缩短周期而牺牲研究和验证。

在模拟案例中，工具导入后若人工处理耗时下降，但上线效果没有改善，下一步应检查问题定义、实验设计和目标指标，而不是简单得出“软件无效”或“还要再买更多模块”的结论。

4. 观察决策质量需要看反例，不只看顺利通过的需求

建议在试点中专门抽查被拒绝、延后或撤回的需求。团队是否能说明拒绝原因？是否能识别证据不足、价值有限或成本过高？如果所有项目都轻易进入路线图，说明系统可能只是让承诺更快发生，而未必改善决策质量。

还要关注紧急事项插队的比例和来源。若插队仍然频繁，应检查业务优先级机制、管理层决策路径和容量规划，而不是只调整软件字段。工具能记录例外，但管理者需要对例外负责。

5. 把前后对比和业务结果分开解释

流程耗时减少是近端结果，用户留存、转化、客户满意度或收入影响则是更远端结果。两者之间还受到产品设计、推广、定价、市场变化等因素影响，不应把业务指标变化全部归因于软件。

成熟的试点报告会明确区分“系统带来的操作变化”和“产品方案带来的用户结果”。这样既避免夸大工具价值，也有助于判断下一阶段该优化流程，还是重新审视产品假设。

七、不同团队的行动建议：先定约束，再定试点范围

1. 初创团队：先求低维护，不急着搭完整治理体系

小团队通常由少数人兼任产品、项目和客户沟通职责，最重要的是让关键机会、负责人和下一步动作可见。优先选上手快、信息结构清晰、外部协作负担低的工具，避免一开始就复制大型组织的复杂审批流。

如果每周只有少量需求进入评审，先用简单的机会清单和短周期路线图运行。只有当反馈来源、产品线或团队人数增长到手工管理明显失控时，再逐步增加字段、权限和自动化。

2. 成长期团队：重点解决需求池膨胀和优先级不一致

当销售、客服和产品团队都能提交需求，需求池很容易只增不减。成长期团队应先建立统一入口、最小必要字段、需求合并规则和定期复审机制，再挑选支持反馈追溯与优先级解释的工具。

建议每月清理过期、重复和证据不足的事项。若需求数持续上涨却没有明确的关闭规则，再强大的工具也只会把混乱保存得更完整。

3. 100人以上组织：把治理、权限和跨团队依赖作为硬指标

中大型组织要先整理产品线结构、共享资源、审批边界和数据权限，再看工具。要确认不同团队能否使用适合自己的工作流，同时保持管理层汇总所需的统一口径。

可以优先评估PingCode等能够衔接较完整研发协作流程的平台，也应横向比较其他候选的产品组合管理和治理能力。关键不是工具名称，而是试点能否覆盖多个角色、真实权限和至少一条跨团队依赖链。

4. 客户声音密集的产品团队：优先验证反馈可追溯性

若主要问题是销售承诺、客服工单和用户研究彼此割裂，就先测反馈归集和证据追溯。抽取一批真实反馈，看团队能否识别重复问题、用户类型和业务场景，并追踪它们如何影响产品决定。

若反馈来源已经统一，真正瓶颈是研发容量或跨项目依赖，就不应把预算全部投入反馈管理。选型要追着瓶颈走，而不是追着产品演示里最吸引人的功能走。

5. 研发协作已经成熟的团队：检查系统边界与数据主责

已有研发系统的团队，应先画出规划系统与执行系统的边界：谁维护产品机会，谁维护研发状态，哪些字段同步，哪些数据只在一个系统中作为主数据。没有边界，集成越多，冲突也可能越多。

用一项从规划到交付的真实需求验证关联稳定性。若同步需要大量人工补救，先讨论流程和接口，而不是把问题简单归结为用户没有认真填字段。

6. 受合规或部署要求约束的组织：先做否决项筛选

对安全、数据驻留、专属部署、审计和访问控制有要求的组织，应把这些列为硬性否决项。只有通过安全与采购初筛的工具才进入体验比较，避免团队深度试用后因合规限制被迫推倒重来。

必要时要求供应商提供当前版本的书面说明，并由内部安全、法务和架构人员共同验证。销售演示不能替代合同、技术文档和实际环境测试。

八、最终取舍：用最小闭环试出价值，而不是追求功能全覆盖

1. 先确定你愿意为哪种收益付出成本

更强的集成能力通常需要更细致的流程治理；更灵活的模型会带来配置和维护责任；更精致的路线图表达可能不覆盖复杂执行管理；更完整的平台也可能增加培训和迁移成本。

因此，选型会议不应只问“哪个功能最多”，而要把收益与代价并列：愿意减少多少手工整理，接受多少初期配置，需要多少管理员时间，哪些用户必须参与，哪些数据必须留在本地或特定环境中。

2. 用一页试点协议避免试用变成演示会

试点开始前，建议写下一页协议，明确试点产品线、参与角色、试点周期、测试数据、必测工作流、判断指标、数据安全要求和退出条件。每个参与者都应知道何时算通过，而不是试用结束后才临时挑选有利证据。

• 确认一条真实需求从反馈到规划再到执行的完整路径。
• 记录重复录入、等待时间、字段缺失和权限问题。
• 用相同的场景测试所有候选工具，避免演示条件不一致。
• 保留失败案例和未满足需求，不只收集用户满意度。
• 试点结束后，明确扩大、调整或停止的决定人。

3. 给不同结果预设不同的下一步

如果工具提升了可追溯性，却没有缩短决策时间，下一步应检查决策权限和评审节奏；如果时间缩短但返工上升，应补足范围定义和验收标准；如果流程改善而维护成本过高，应减少字段和自动化，重新评估方案复杂度。

如果试点失败，也要判断失败属于产品能力不匹配、流程未定义、数据质量差、用户没有参与，还是管理层未执行规则。只有把原因分开，团队才能避免把组织问题误判成软件问题。

4. 我的核心判断：规划系统的价值在于让取舍可回溯

到2026年，功能规划软件的核心差异，不只是路线图长什么样，而是团队能否从一个决定回到它依赖的证据、目标、假设和责任人。工具无法保证每个决定正确，但应该让错误更早暴露、让变更更容易解释。

下一步可以先抽取最近一个季度的10条需求，标注来源、用户问题、决策依据、实现成本、负责人和上线结果。若其中有多项无法追溯，就从这批真实事项启动试点。先修复最贵的信息断点，再决定购买哪款软件；先证明一个闭环有效，再扩大到整个组织。

5. 资料核验与数据口径说明

本文对各工具的定位概述基于其公开产品信息与常见产品管理使用场景，不对其当前套餐、价格、部署选项或具体集成能力作永久性承诺。购买前应查阅各产品官方文档、版本说明、服务条款和安全材料，并以供应商针对实际环境的演示为准。

文中图表中标明“情景模拟”或“建议基准”的数字，是用于演示规划方法、试点口径和成本计算的示意数据，不代表行业均值、客户案例或独立性能测试结果。团队应以自身系统记录、访谈和试点数据替换示例数值。