企业官网建设流程全解析

Perplexity 在做“努力程度选择器”这个方向，最近关注度不低。这个功能比普通搜索模式的开关更有意思：它不是简单地把“要不要多思考一下”做成一个二选一，而是把回答问题的深度、查证范围、生成成本，从系统的默认值拆成用户可以自己选择的粒度。

刚接触这个概念，容易以为它只是一个三档下拉框：快速、平衡、深度。但实际上，真正值得关注的不是档位数量，而是“努力程度”这四个字背后牵扯到的计算量、查询次数、上下文长度和最终回答质量之间的平衡。这篇文章不聊具体版本号，也不猜发布日期，只把这个产品方向讲清楚：它到底在解决什么问题、粒度设计应该怎么做、如果自己开发类似功能怎么落地、以及怎么判断高努力档是不是真的划算。

1. “努力程度选择器”到底在解决什么问题

1.1 从“一次提问”到“按任务成本调档”

Perplexity 这类对话式搜索产品，核心能力是让用户用自然语言提问，然后由模型检索资料、组合上下文、生成回答。默认情况下，系统会按照某种固定策略处理所有问题：快速问题走一遍搜索就答，复杂问题可能要多轮检索、多步推理，但用户很难控制这个过程。

“努力程度选择器”想解决的，就是让用户提前决定这一次提问要花多少“人力”。如果你只是想知道某本书的作者是谁，那就用低努力档，模型快速检索一两次，直接给答案。如果你要写一份行业调研材料，需要把政策背景、市场数据、不同观点都整理出来，那就可以调到高努力档，让模型多搜索几轮、多读几个来源、写得更完整。

这个思路不是 Perplexity 首创，很多大模型产品已经在做类似的事情，比如部分工具会让用户选择“快速回答”还是“深度思考”。但差别在“粒度”这两个字：如果只是一个三档开关，用户能控制的仍然有限；如果能做到更细的粒度，用户就可以针对不同任务精准分配资源。

1.2 它和普通搜索模式的差异在哪里

传统搜索引擎的模式是“你输入关键词，我返回链接”，用户自己筛选信息。对话式搜索的模式是“你提问，我直接给答案”，但系统通常会隐藏“为了这个答案做了多少工作”。

努力程度选择器最大的差异，是把这个隐藏过程变成显式选项。它把一次回答拆成了几个环节：

• 查询理解：问题被拆成几个子问题，或者直接作为一条搜索词。
• 检索次数：模型会搜索几轮，每轮读取多少网页。
• 上下文长度：最终拼接给模型的资料上限是多少。
• 推理步骤：模型是直接生成回答，还是先做计划再生成。
• 输出长度：回答写到什么程度，是几句话还是一篇长报告。

低努力档会把上面的环节压缩到最少，高努力档会尽可能放开。理解了这个结构，才算真正理解“努力程度选择器”的价值。

我一般会这样跟人解释：它就像你请一个研究员帮忙查资料。你可以说“十分钟给我个结论”，也可以说“花三个小时把相关数据都整理出来”。两种需求都是合理的，区别不是谁更智能，而是你要不要为额外的信息深度付费。AI 产品做努力程度选择器，本质上就是把“研究员”的工时变成可选项。

2. 粒度设计：档位越多，体验不一定越好

2.1 “粒度”指的是什么

“粒度”这个词在技术圈很常见，指的是一个系统可以调节的最小单位。放在努力程度选择器里，粒度就是用户能感知到的那一档一档的差别。

粗粒度的设计可能只有三档：低、中、高。细粒度的设计可能有五个档位，甚至允许用户通过滑杆或者自定义参数直接指定“搜索几轮”“回答多长”。Perplexity 这次被讨论的“新粒度”，关键点就是“新”在更细的调节能力上，而不是简单加一个开关。

举个例子，如果你做代码调试，你问“这个报错是什么原因”，低努力档可能只给出常见的几个原因。中努力档会搜索相关的 GitHub Issue，给出一两个最接近的场景。高努力档会从报错信息、依赖版本、系统环境三个方向检索，把排障过程写成一篇文章。这中间的差异并不是“答得对错”，而是覆盖的广度和回答的可用性。

2.2 快速、平衡、深度之间的平衡关系

任何努力程度选择器，本质上都在处理三个变量：速度、质量、成本。

速度很好理解，档位越高，多次搜索和长上下文的处理时间越长。质量不是一下子就能提高的，很多时候从低档调到中档，质量提升明显；从中档调到高档，提升可能只有一点点。成本是最容易被忽略的，高努力档意味着更多的检索请求、更多的 token 消耗、更长的模型推理时间，这些在本地测试时不明显，但在接口调用或者批量任务里就是实打实的费用。

我见过不少人在刚接触这类功能时，直接把所有问题都调到最高档。结果就是回答变得很慢，而且很多简单问题反而不如低档清晰。高努力档会产生更长的上下文，如果模型没有处理好信息优先级，反而容易在长篇回答里塞进很多无关内容。所以快速、平衡、深度这三个方向不是简单的“好中差”，而是“不同任务下的匹配方案”。

2.3 产品设计上的取舍经验

如果让我来设计这类功能，我会重点考虑两件事：

第一，档位之间要保证输出结构稳定。用户从低档切到高档时，回答的格式不应该发生剧烈变化。如果低档给一段话，高档给一篇报告，用户会觉得这是两个不同的产品。更好的做法是保持结论先行、参考来源清晰的结构，只是内容的丰富程度不同。

第二，要给用户设置默认档位的建议。不是每个用户都理解“努力程度”意味着什么，如果让用户自己面对五个相近的档位，选择成本反而更高。系统可以根据问题类型给出建议：事实型问题走低档，分析型问题走中档，研究型问题走高档。用户也可以手动修改。

另外，档位的命名也要尽量直白。不要写“轻量”“均衡”“增强”“深度”这种看起来差不多的词，至少要让人一眼能判断“低档适合查资料，高档适合写分析”。

3. 在自建工具里实现类似功能，可以怎么设计

如果这个功能让你觉得有价值，想在自己的工具或者本地脚本里做一个类似机制，我建议先从拆环节开始，不要想着一步到位做一个完整的“努力程度调节器”。

3.1 拆解“努力程度”的组成环节

一次基于检索增强生成（RAG）的回答，一般包含这几个可调的部分：

• 搜索轮数：搜索一次还是搜索三次。
• 每个搜索结果的取用条数：取前 3 条还是前 10 条。
• 最大上下文长度：喂给模型多少资料。
• 模型推理步数：让模型直接回答，还是先写计划再回答。
• 回答长度上限：生成多少字，或者输出多少个 token。

这五个变量不需要做成五个设置项。对用户侧来说，可以合并成一个 effort_level 参数；但在内部实现时，每个 effort_level 映射到的是一组设定。

3.2 一个可参考的请求参数结构

假设你在做一个内部工具，可以定义一个伪配置，结构大概像这样：

{ "query": "某个具体问题", "effort_level": "balanced", "max_search_rounds": 3, "max_results_per_round": 5, "max_context_tokens": 8000, "max_reasoning_steps": 2, "max_answer_tokens": 1500, "timeout_seconds": 45 }

这里的关键不是参数名，而是每一档应该对应一组合理的数值。比如：

需要注意，这个表只是示例，具体数值要根据模型能力、知识库大小和实际任务来调整。如果模型本身上下文窗口只有 8k，你把上下文上限设成 16k 只会导致截断或者报错。

3.3 批量任务和接口场景的配置建议

在自建工具里，最常踩的坑不是单条任务跑不动，而是批量任务没有分层配置。

比如你要处理 1000 条用户问题，如果全部用深度档，第一是耗时非常大，第二是费用会翻很多倍，第三是有些简单问题被过度处理，反而降低了整体准确率。正确的做法是先跑一个小样本，把问题按类型分开，简单问题用快速档，复杂问题用深度档，然后再设置队列。

接口调用的时候也要注意超时设置。深度档的耗时可能是快速档的 5 到 10 倍，如果你用同一个 timeout 配置，很容易出现请求超时或者用户端反复重试。我一般会鼓励这样的做法：先单条测试看耗时，按耗时分布设计超时时间。不要把超时时间设得太短，也不要因为单条慢就锁死整个队列。

注意：不要一上来就开最大并发。努力程度调高之后，单任务耗时会明显增加，并发一高，资源占用很容易把本机或者网关打满。先用一条样例确认输入、输出和日志都正常，再逐步加并发。

4. 实测思路：高努力档到底是不是更聪明

这个功能最容易被误解的地方是“高努力=更聪明”。从实际体验看，高努力档只是把更多的计算资源投进这一次回答，它能不能变得更聪明，取决于你的问题到底缺的是检索、推理还是上下文。

4.1 单条任务看什么指标

测试时不要只盯着答案内容，还要记录四个指标：

• 首 token 延迟：从发出请求到第一个字返回的时间。快速档应该很短，深度档可能会长一些。
• 总耗时：整个回答生成完成的时间，这个时间最能反映努力程度是否生效。
• 检索轮数：看日志里实际发生了多少次搜索。如果设置了三轮，日志里只有一轮，说明配置没有生效。
• 回答长度：快速档和高档如果输出长度一样，那大概率是参数没有被正确传递。

日志是你的第一排查工具。很多“看起来没有变化”的问题，最后都会发现是参数没有传到检索函数或者模型生成函数里。

4.2 对比实验怎么做

想验证高努力档是否值得，我建议用同样的问题在不同档位下各跑一次，然后对比三点：

第一，信息覆盖度。低档回答里没有提到的观点，高档有没有补上？如果有，这些信息对你是否有用？第二，线索完整性。低档回答给出的链接或来源，是否被高档覆盖了？如果高档反而漏掉了某些关键来源，那说明参数调得很糟糕。第三，可读性。高档回答是否因为太长而让人抓不住重点，还是通过标题和列表让结构更清晰？

一个常见现象是：从低档升到中档，效果提升很明显；从中档升到高档，只是从 2000 字变成 4000 字，但核心结论没有变化。这说明深度档投入的资源没有换回有效信息，问题本身可能不需要那么高的努力程度。

4.3 成本和体验的取舍

如果你是在做产品，需要把成本和体验放在一起看。高努力档在单条请求上可能只是多花几秒钟，但如果是每天几千次的调用，费用和延迟会成倍增长。

可以给产品设计一个简单的策略：默认档位设为平衡档，用户主动点击“深度研究”才使用高档。而不是默认就最高档。也可以按问题类型自动选择档位，比如简单的事实型问题直接走快速档，需要综述的问题才用深度档。

提醒一下：输出变长不等于质量变好。很多模型在长上下文的场景下，反而会重复某个观点、加入大段铺垫信息。判断质量要看信息密度，而不是字数。

5. 边界与常见误区

5.1 不是所有问题都需要更高努力

简单问题用深度档，得到的可能不是更详细的结果，而是更加啰嗦的结果。比如“今天天气怎么样”，不管你怎么调努力程度，本质答案就是那几个字段。深度档反而可能把未来一周的天气预报都堆进来，造成信息干扰。

更合理的用法是，先判断问题类型。事实型和决策型问题需要不同的努力程度。事实型问题速度快最要紧，决策型问题需要更多信息支撑。如果一个产品把所有问题都默认设成高努力，用户会被慢速和高成本拖垮；如果一个产品把所有问题都设成低努力，遇到复杂问题又会显得“不够聪明”。这个平衡就是功能设计的核心。

5.2 输出变长、回答变慢不等于质量变好

我刚接触类似机制时，也容易陷入一个误区：只要回答变长了，就认为档位生效了。后来发现，很多长回答是在重复搜索到的同一条信息，只是换了几种表达方式。真正有效的努力是：

• 检索到了更多不同的信息源。
• 上下文里包含了更多角度。
• 最后生成时进行了信息交叉验证。
• 回答里明确指出了哪些信息是确定的，哪些是存疑的。

如果只是把搜索结果塞得更多，没有做信息筛选和融合，高努力档反而会让答案更难读。这也是为什么“粒度”重要：你要调的不是“生成字数的上限”，而是“处理信息的深度”。

5.3 排查链路：功能有没有真正生效

遇到“选了深度档，但回答还跟快速档一样”的问题，我的排查顺序是：

先看现象，是速度没变慢，还是内容没变长，还是来源数量没变多。接着看配置，effort_level 有没有真正传到后端，有没有被其他默认配置覆盖。然后再看日志，搜索轮数和上下文长度有没有按预期变化。最后看输入，如果问题本身非常具体，三句话就能回答完整，那即使开了高努力档，模型也可能觉得不需要额外检索，这不是 bug，而是模型对任务复杂度的判断。

这个排查顺序只针对“功能没生效”，如果是“功能生效了但效果差”，那就要重新看参数映射了。

6. 这类产品趋势对普通用户和开发者的意义

6.1 搜索产品正在变成可配置的研究助手

Perplexity 做努力程度选择器，至少说明一个趋势：对话式搜索正在从“统一的问答体验”转向“可配置的研究工具”。以前的搜索引擎给所有人的结果基本一致，现在的 AI 产品可以根据用户设定或者任务类型，动态调整回答的深度和形式。

对普通用户来说，这个趋势意味着“提问”本身需要更有策略。你不再只是输入一句话然后等答案，而是要判断自己真正需要什么。想要快速结论，就别选深度档；想要完整调研，就别问完一句话看完一段话就走。学会根据任务选择努力程度，会比催更“更强模型”更实际。

6.2 给普通用户的建议

如果这个功能真的上线，我的建议是先别急着每次都选最高档。按任务类型分：查时间、查人名、查定义，用低档足够；做比较、做分析、做规划，用中档起步；写综述、做资料梳理、调研多个利益相关方观点，再考虑深度档。

也可以留意默认档位是否有记忆功能。如果产品能记住你上次的选择，下次使用前先确认当前档位是不是你需要的。很多体验问题不是功能没有，而是档位没有切对。

6.3 给开发者的建议

如果你想在自有产品里实现一个类似机制，不要只做档位映射，还要把日志和指标做好。你要能回答这几个问题：

• 某个档位平均耗时多少。
• 某个档位平均调用多少次检索接口。
• 某个档位下用户是否真的回访更多。
• 有没有用户选了深度档，但实际并没有用深度档做复杂任务。

指标没有做好之前，就算把档位从三档加到十档，也只是多几个参数，不会给产品带来实质提升。先跑通一个三档版本，用小流量验证，再考虑要不要细化粒度，会是更稳妥的做法。

努力程度选择器真正落地时，最该盯住的不是“档位数量够不够多”，而是每一次选择是否真的让用户在速度、深度和成本之间获得了更好的平衡。把这个逻辑想清楚，不管是直接用产品还是参考它做自建功能，都不会跑偏。