🎯题库与情境练习

{"bank":[{"analysis":"AI 体验五要素是**透明**（知道 AI 在做什么）、**可控**（可中断/可编辑/可再生成/可回退）、**可信**（引用来源与不确定提示）、**可恢复**（重试/降级/人工接管）、**可评估**（反馈入口与定期抽查）。中断、编辑、再生成、回退都属于“可控”。","answer":"A","chapter":"PDE·AI 体验","difficulty":1,"explain":{"B":"透明强调让用户知道 AI 在做什么、进展到哪一步。","C":"可信强调引用来源、置信提示与不确定时明说。","D":"可评估强调测试集、人工抽查与用户反馈闭环。"},"id":"ai-01-001","options":["可控","透明","可信","可评估"],"source":"chapter","stem":"用户能中断生成、编辑结果、一键再生成、回退到上一次回答，这主要体现 AI 体验五要素中的哪一个？","subject":"AI 体验设计","type":"single"},{"analysis":"幻觉不能根治只能管理。合理对策是引用来源、不确定时明确告知、高风险场景加核实提示，这与“可信”要素直接对应；边界到设计的映射是 AI 产品设计的核心考法。","answer":"A","chapter":"PDE·AI 体验","difficulty":2,"explain":{"B":"承诺零幻觉是不理解模型能力边界的表现。","C":"限制提问范围属于回避需求，不是治理方案。","D":"提高温度会增加随机性，反而抬高幻觉风险。"},"id":"ai-01-002","options":["给出引用来源、不确定时明说、高风险场景提示需核实","在宣传中承诺产品可以做到零幻觉","禁止用户提出开放性问题","把 temperature 调到最高让回答更丰富"],"source":"chapter","stem":"针对大模型“幻觉”这一能力边界，合理的产品设计对策是？","subject":"AI 体验设计","type":"single"},{"analysis":"上下文窗口是一次能看的长度上限，对应的设计对策是 RAG 检索、分段处理与摘要；同类的边界映射还有：不确定对应“结果可编辑 + 关键确认”，长任务对应“进度 + 断点恢复”，成本对应“额度提示 + 模型分级”。","answer":"A","chapter":"PDE·AI 体验","difficulty":2,"explain":{"B":"把处理成本转嫁给用户，不是合格的产品设计。","C":"超长内容会被截断，关键信息可能直接丢失。","D":"回避需求不能解决能力边界问题。"},"id":"ai-01-003","options":["用 RAG 检索相关片段，并配合分段处理与摘要","要求用户自己先把文档删短","不拆分，一次性把全文塞进提示词","换一个不需要长文档的场景"],"source":"chapter","stem":"处理长文档时受“上下文窗口”限制，最合适的产品化对策是？","subject":"AI 体验设计","type":"single"},{"analysis":"提示词四段为角色（你是谁）、任务（做什么）、约束（格式与限制）、示例（1~2 个）。上下文工程三招则是 RAG、记忆与工具调用。","answer":"A","chapter":"PDE·AI 体验","difficulty":1,"explain":{"B":"这是文档结构，不是提示词结构。","C":"这是系统可观测性要素。","D":"这是技术架构划分。"},"id":"ai-01-004","options":["角色 + 任务 + 约束 + 示例","标题 + 正文 + 结尾 + 署名","输入 + 输出 + 日志 + 报警","前端 + 后端 + 数据 + 部署"],"source":"chapter","stem":"提示词结构的四段通常是？","subject":"AI 体验设计","type":"single"},{"analysis":"选型原则是“**步骤固定用工作流，开放任务用 Agent，知识密集用 RAG**”。工作流更可控、更便宜，评审常问“为什么不用工作流”，不要为了 Agent 而 Agent。","answer":"A","chapter":"PDE·AI 体验","difficulty":2,"explain":{"B":"自主 Agent 路径不可控、成本不固定。","C":"多 Agent 协商的可复现性更差。","D":"每次自决步骤会让流程与结果不可预期。"},"id":"ai-01-005","options":["工作流：由人设计固定步骤的流水线","完全自主决策的 Agent","多个 Agent 自由协商","让模型每次自行决定步骤"],"source":"chapter","stem":"步骤固定、合规要求高的业务流，最合适的技术形态是？","subject":"AI 体验设计","type":"single"},{"analysis":"问题定义四问为**谁**（具体人群）、**什么场景**（时机与环境）、**什么障碍**（现有方案差在哪）、**什么结果**（怎么衡量）。四问缺一就不算定义清楚。","answer":"A","chapter":"PDE·问题定义","difficulty":1,"explain":{"B":"功能、技术、排期、预算属于方案与执行层，不是问题定义。","C":"成本与人力是资源问题，不回答为谁解决什么。","D":"竞品与趋势是背景信息，不能替代用户与场景。"},"id":"cp-01-001","options":["谁 + 什么场景 + 什么障碍 + 什么结果","什么功能 + 什么技术 + 什么排期 + 什么预算","谁 + 多少钱 + 多少天 + 多少人","痛点 + 竞品 + 趋势 + 机会"],"source":"chapter","stem":"一个完整的问题定义需要回答的四问是？","subject":"产品思维","type":"single"},{"analysis":"结果必须可衡量：有对象、有基线、有目标值，才能验收。反差对比是“做一个 AI 效率工具”（坏问题）与“给远程团队 PM 在跨时区周会后自动出待办清单，整理时间 \u003c 5 分钟”（好问题）。","answer":"A","chapter":"PDE·问题定义","difficulty":2,"explain":{"B":"没有指标口径与目标值，无法验收。","C":"满意度缺少测量方式与阈值。","D":"这是方案描述，不是结果。"},"id":"cp-01-002","options":["远程团队 PM 整理待办的时间从 30 分钟降到 5 分钟以内","整体提升团队的协作效率","让使用产品的用户更加满意","做一个更智能的效率工具"],"source":"chapter","stem":"下列哪一条才算“可衡量的结果”？","subject":"产品思维","type":"single"},{"analysis":"访谈要**问行为不问态度**：“你会用吗”几乎所有人都会礼貌性答“会”；“是不是觉得 A 好”属于引导式提问，会污染答案；直接索要功能等于让用户替你设计方案。回溯“上一次怎么做”才能拿到真实场景与卡点。","answer":"A","chapter":"PDE·问题定义","difficulty":2,"explain":{"B":"态度性问题会得到礼貌性的肯定回答。","C":"引导性提问暗示了选项，答案不可信。","D":"索要功能会让用户跳过问题本身。"},"id":"cp-01-003","options":["上一次遇到这个问题时，你是怎么做的","如果我们做这个功能，你会用吗","你是不是觉得 A 方案更好","你希望我们增加哪些功能"],"source":"chapter","stem":"用户访谈中最应该问的问题是？","subject":"产品思维","type":"single"},{"analysis":"四步为招募（5~8 名目标用户）、访谈（约 30 分钟，先场景后行为再态度）、归纳（亲和图聚类命名）、验证（拿方案回看用户会怎么用）。","answer":"A","chapter":"PDE·问题定义","difficulty":2,"explain":{"B":"必须先确定访谈对象，才能开始访谈。","C":"没有访谈素材，归纳无从下手。","D":"顺序颠倒，验证应发生在方案成形之后。"},"id":"cp-01-004","options":["招募 → 访谈 → 归纳 → 验证","访谈 → 招募 → 验证 → 归纳","归纳 → 访谈 → 招募 → 验证","验证 → 归纳 → 访谈 → 招募"],"source":"chapter","stem":"用户研究四步的正确顺序是？","subject":"产品思维","type":"single"},{"analysis":"定性研究追求信息密度而非样本量：5~8 名目标用户即可覆盖主要模式，10 人以上边际收益骤降；极端用户往往暴露最真实的边界；同事不是目标用户，容易带入内部视角与善意偏差。","answer":"A","chapter":"PDE·问题定义","difficulty":2,"explain":{"B":"定性访谈不是问卷调查，样本量不是关键。","C":"同事会带入内部视角，反馈失真。","D":"排除极端情况会丢掉最有价值的线索。"},"id":"cp-01-005","options":["5~8 名目标用户通常够用，极端用户信息量更大，且不要只找同事","样本越多结论越可靠，至少需要 100 人","找同事最方便，效果和找用户一样","只找最典型的用户，排除所有极端情况"],"source":"chapter","stem":"关于用户研究的样本，说法正确的是？","subject":"产品思维","type":"single"},{"analysis":"RICE =（触达人数 × 影响 × 置信度）÷ 人月。Impact 常取 0.25/0.5/1/2/3，Confidence 取 50%/80%/100%，Effort 以人月计；分数越高越优先。","answer":"A","chapter":"PDE·优先级指标","difficulty":2,"explain":{"B":"相加无法体现投入产出的比值关系。","C":"Effort 应当作为分母。","D":"分子分母颠倒，不符合 RICE 定义。"},"id":"cp-02-001","options":["（Reach × Impact × Confidence）÷ Effort","Reach + Impact + Confidence + Effort","Impact × Effort ÷ Reach","Confidence ÷（Reach × Impact）"],"source":"chapter","stem":"RICE 公式的组成是？","subject":"产品思维","type":"single"},{"analysis":"RICE = 5000 × 1 × 0.8 ÷ 2 = **2000**。分数不是圣旨，但必须算出来再争论；算完还要看它对应哪个已定义的问题。","answer":"A","chapter":"PDE·优先级指标","difficulty":2,"explain":{"B":"4000 是漏除 Effort（5000 × 0.8）的结果。","C":"800 是把系数乘错或重复除以系数的结果。","D":"5000 忽略了 Impact、Confidence 与 Effort。"},"id":"cp-02-002","options":["2000","4000","800","5000"],"source":"chapter","stem":"某需求 Reach 为 5000/季、Impact 为 1、Confidence 为 80%、Effort 为 2 人月，其 RICE 约为？","subject":"产品思维","type":"single"},{"analysis":"口诀“**有数 RICE，无数 ICE，体验 Kano**”。Kano 把功能分为基本型、期望型、魅力型、无差异与反向，用来判断“做了用户感不感知”；RICE 与 ICE 用于排优先级。","answer":"A","chapter":"PDE·优先级指标","difficulty":2,"explain":{"B":"RICE 用于排序投入产出，不做功能类型判断。","C":"ICE 适用于数据缺乏时的快速排序。","D":"用户画像是研究工具，不是功能分类方法。"},"id":"cp-02-003","options":["Kano 模型","RICE","ICE","用户画像"],"source":"chapter","stem":"想判断“某个功能做了用户感不感知”，应该用哪种方法？","subject":"产品思维","type":"single"},{"analysis":"北极星**只有 1 个**，代表产品让用户“完成”的核心价值；输入指标若干且能被团队动作直接影响；护栏指标是赢也不能坏的底线。3 个北极星等于没有北极星，团队会互相打架。","answer":"A","chapter":"PDE·优先级指标","difficulty":2,"explain":{"B":"多个北极星会让团队目标分裂。","C":"挑易达成的指标会误导产品方向。","D":"频繁更换会让团队无法积累与验证。"},"id":"cp-02-004","options":["只设 1 个能代表产品核心价值的结果指标","同时设 3 个，分别覆盖用户、收入与留存","挑最容易达成的那个指标当北极星","每月更换一次北极星以保持新鲜感"],"source":"chapter","stem":"关于北极星指标，正确的做法是？","subject":"产品思维","type":"single"},{"analysis":"P0（不做就死）是核心闭环，P1（做了大加分）是体验闭环，P2（锦上添花）是魅力功能。**MVP 是砍出来的，不是加出来的**；P0 没跑通就做 P2，功能再亮也没人用起来。","answer":"A","chapter":"PDE·优先级指标","difficulty":2,"explain":{"B":"P0 未闭环时，亮点功能没有使用基础。","C":"同时开工会让核心闭环延期交付。","D":"顺序颠倒，先做体验层会拖住可用性。"},"id":"cp-02-005","options":["先 P0 让核心任务跑通，再 P1 补体验闭环，最后做 P2 魅力功能","先做 P2 魅力功能吸引用户眼球","P0、P1、P2 三层同时开工","先做 P1 体验闭环，再回头做 P0"],"source":"chapter","stem":"MVP 三层的正确推进顺序是？","subject":"产品思维","type":"single"},{"analysis":"访谈四段：**暖场**（说明没有标准答案，降低表演欲）、**场景**（问“上次你是怎么做的”）、**卡点**（哪一步最烦/最慢/最贵）、**收尾**（现在怎么凑合解决，以及期望）。核心是问行为、问障碍，不急着给方案。","answer":"A","chapter":"PDE·用户研究","difficulty":2,"explain":{"B":"先给方案会污染用户回答，用户会顺着你说。","C":"会变成竞品吐槽大会，偏离用户自身场景。","D":"直接索要功能会让用户替你设计方案。"},"id":"cp-03-001","options":["暖场 3 分钟 → 场景 10 分钟 → 卡点 10 分钟 → 收尾 7 分钟","开场先展示方案，然后请用户打分评价","全程聊竞品的优缺点","只问用户希望我们增加什么功能"],"source":"chapter","stem":"30 分钟用户访谈的结构通常是？","subject":"产品思维","type":"single"},{"analysis":"访谈禁忌包括：不问“你会用吗”、**不先给方案**、不引导（“是不是觉得 A 好”）、不聊竞品功能、不现场承诺。先给方案会让用户顺着你的思路回答，污染真实信息。","answer":"A","chapter":"PDE·用户研究","difficulty":2,"explain":{"B":"开放式追问行为是访谈的正确做法。","C":"追问卡点正是访谈的核心目标之一。","D":"回溯真实经历能拿到可信的场景信息。"},"id":"cp-03-002","options":["访谈中先展示自己的方案，请用户评价好不好","用开放式问题追问用户上次是怎么做的","追问卡点具体出现在流程的哪一步","请用户描述最近一次的真实经历"],"source":"chapter","stem":"下列哪项做法违反了用户访谈的禁忌？","subject":"产品思维","type":"single"},{"analysis":"亲和图三步：一句一贴、保留原话；把相似的聚在一起、边聚边命名；用**用户视角**命名并按频次/强度排序。命名要贴近用户语言，例如“找不到上次那份合同”，而不是“功能覆盖不全”。","answer":"A","chapter":"PDE·用户研究","difficulty":2,"explain":{"B":"先命名会把自己的框架强加给素材。","C":"直接投票跳过了归纳，容易漏掉长尾问题。","D":"人口统计分组不是亲和图法。"},"id":"cp-03-003","options":["逐条贴便签并保留原话 → 聚类 → 命名并排序","先命好分类，再按分类去收集用户原话","直接让团队投票选出最想做的功能","按用户年龄和地域分组做统计"],"source":"chapter","stem":"用亲和图法归纳访谈素材的三个步骤是？","subject":"产品思维","type":"single"},{"analysis":"画像是“**行为 + 场景 + 障碍**”，五字段为谁（角色/规模）、场景、目标、障碍、成功标准。它的用途是共情与提醒“你在为谁做”，不是用于筛选用户；人口统计字段通常是噪声。","answer":"A","chapter":"PDE·用户研究","difficulty":2,"explain":{"B":"人口统计是照片式卡片，指导不了设计决策。","C":"生活方式标签与产品场景没有直接关系。","D":"拟人化装饰不能替代行为与障碍。"},"id":"cp-03-004","options":["角色、场景、目标、障碍与成功标准","年龄、收入、学历与地域","星座、爱好与常用 App","姓名、头像与口头禅"],"source":"chapter","stem":"有价值的用户画像应当包含哪些内容？","subject":"产品思维","type":"single"},{"analysis":"Job Story 用一句“**当我……我想……我能……**”串起场景、动机与结果，例如“当我开完跨时区周会，我想不再手动整理待办，我能 5 分钟内拿到按人分组的任务清单”。它从用户的任务情境出发，而不是从功能出发。","answer":"A","chapter":"PDE·用户研究","difficulty":2,"explain":{"B":"这是用户故事（User Story）的句式，聚焦功能而非场景动机。","C":"这是条件分支的逻辑描述。","D":"这是因果论证句式，不是任务脚本。"},"id":"cp-03-005","options":["当我（场景），我想（动机），我能（结果）","作为一个（角色），我想要（功能），以便（收益）","如果（条件），那么（行为），否则（结果）","因为（原因），所以（结论）"],"source":"chapter","stem":"Job Story（任务脚本）的标准句式是？","subject":"产品思维","type":"single"},{"analysis":"任务流包含**主流程**（happy path，最顺路径）、**分支**（如“重新生成/换一个”）与**异常**（额度不足/网络断/超时）。只画主流程或只画成功页等于半成品，评审会直接减分。","answer":"A","chapter":"PDE·状态设计","difficulty":1,"explain":{"B":"这是页面清单，不是任务流结构。","C":"这是数据处理的环节划分。","D":"这是发布策略，不是用户任务流。"},"id":"jh-01-001","options":["主流程、分支、异常","首页、详情页、设置页","输入、处理、输出","正常、灰度、全量"],"source":"chapter","stem":"设计用户任务流时，需要覆盖的“三条线”是？","subject":"交互设计","type":"single"},{"analysis":"流式状态要让输出可见且可中断：**逐字输出 + 停止按钮 + 光标闪烁/进度提示**。口诀“流式能停”，转圈 30 秒无反馈、无法中断是最典型的减分项。","answer":"A","chapter":"PDE·状态设计","difficulty":1,"explain":{"B":"长时间无反馈且不可中断，用户会以为卡死。","C":"隐藏界面会让用户误判为无响应。","D":"让用户刷新会丢失任务上下文与进度。"},"id":"jh-01-002","options":["逐字输出、停止按钮与光标或进度反馈","一个转圈图标，静默等待 30 秒","先隐藏界面，等结果出来再显示","提示用户刷新页面查看进度"],"source":"chapter","stem":"关于 AI 的“加载中（流式）”状态，必须提供的是？","subject":"交互设计","type":"single"},{"analysis":"失败状态三件套：**原因 + 重试 + 降级**（换模型/简化任务/转人工）。只说“出错了”，用户无法判断是网络、额度还是模型问题，也没有下一步动作可做。","answer":"A","chapter":"PDE·状态设计","difficulty":2,"explain":{"B":"无原因、无出口，属于不及格设计。","C":"跳回首页会让用户丢失已输入的内容。","D":"静默失败最糟，用户不知道发生了什么。"},"id":"jh-01-003","options":["失败原因、重试入口与降级方案","只弹出一句“出错了”","直接跳回首页","静默失败并保留空白区域"],"source":"chapter","stem":"AI 生成失败时，完整的失败状态应当包含？","subject":"交互设计","type":"single"},{"analysis":"空状态是引导机会：用示例提示词、模板或推荐问题告诉用户“这个 AI 能做什么、该怎么问”。空白屏幕会让首次使用者无从下手，直接流失在第一步。","answer":"A","chapter":"PDE·状态设计","difficulty":2,"explain":{"B":"空白会让用户流失在第一步。","C":"只有输入框缺少能力示范，用户容易问错方向。","D":"空状态不是错误态，用错误提示会误导用户。"},"id":"jh-01-004","options":["给出示例提示词、模板或推荐问题来引导用户","展示一片完全空白的区域","只显示一个输入框，不做任何说明","显示一条错误提示"],"source":"chapter","stem":"AI 产品的“空状态”应该怎么设计？","subject":"交互设计","type":"single"},{"analysis":"三种保真度各有用途：线框验流程、可交互原型验交互、代码原型验真实。AI 产品的延迟、流式与不确定性画不出来，只有接近真实的形态才能验证体验是否可用。","answer":"A","chapter":"PDE·状态设计","difficulty":3,"explain":{"B":"代码原型通常更慢，价值在于真实感。","C":"静态稿适合早期流程与信息结构评审。","D":"代码原型同样需要可用性测试来检验。"},"id":"jh-01-005","options":["静态稿无法表达真实延迟、流式输出与失败状态","代码原型的制作速度一定更快","静态稿无法用于任何评审场合","代码原型上线后不需要再做用户测试"],"source":"chapter","stem":"为什么 AI 产品建议直接用代码原型而不是静态稿来验证体验？","subject":"交互设计","type":"single"},{"analysis":"拆分三问：**能否复用**（拆不出复用部分说明粒度不对）、**状态放哪**（局部 useState / 共享 Context / 复杂状态库）、**Props 怎么定**（最小接口）。一个两千行的页面组件等于不及格。","answer":"A","chapter":"PDE·组件工程","difficulty":2,"explain":{"B":"技术选型与人力配置不是组件拆分的依据。","C":"按行数或文件数拆分是形式主义。","D":"排期与预算不决定组件边界。"},"id":"qd-01-001","options":["能否复用、状态放哪、Props 怎么定","用什么框架、用哪个库、几个人写","多少行代码、多少文件、多少接口","上线时间、预算多少、人力多少"],"source":"chapter","stem":"拆分组件时应当先问的三个问题是？","subject":"前端工程","type":"single"},{"analysis":"状态管理三档：局部用 useState/useReducer，跨组件少量共享用 **Context**，复杂全局状态（如任务队列、流式结果）上 Zustand/Redux 等状态库。大量状态无脑塞 Context 会导致每次变更牵连全组件重渲染。","answer":"A","chapter":"PDE·组件工程","difficulty":2,"explain":{"B":"各存一份会造成状态不一致，难以同步。","C":"后端存储满足不了前端交互的即时性要求。","D":"URL 参数不适合承载这类状态，还会污染地址。"},"id":"qd-01-002","options":["提升到 Context 等共享层统一管理","每个组件各自保存一份副本","存到后端数据库，用接口读取","全部塞进 URL 查询参数里"],"source":"chapter","stem":"用户信息、主题这类跨组件的少量共享状态，最合适放在哪里？","subject":"前端工程","type":"single"},{"analysis":"Props 应是**最小接口**：组件只声明自己真正需要的字段与回调。把整个 API 对象塞进去会让组件与数据结构强耦合，难以复用与测试，上游字段一改就牵连一大片。","answer":"A","chapter":"PDE·组件工程","difficulty":2,"explain":{"B":"大对象透传会造成组件与接口结构的隐式耦合。","C":"Props 过多通常说明组件职责不清。","D":"层层透传应改由共享层承载，避免中间组件被迫感知。"},"id":"qd-01-003","options":["只暴露最小必要接口，例如 title、onRetry","直接把整个接口返回对象透传进去","Props 越多越灵活，方便以后扩展","把全局状态直接当 Props 层层往下传"],"source":"chapter","stem":"关于组件 Props 的设计，正确的做法是？","subject":"前端工程","type":"single"},{"analysis":"用 **phase 枚举**表达互斥的阶段，能避免“同时为真”的非法组合，让渲染与分支判断都更清晰；流式内容与错误信息再各自用独立的 state 承载。","answer":"A","chapter":"PDE·组件工程","difficulty":2,"explain":{"B":"多个布尔值组合会产生互相矛盾的非法状态。","C":"单一 loading 无法区分上传、生成与失败。","D":"组件外的全局变量会破坏可预测性与可测试性。"},"id":"qd-01-004","options":["用 phase 枚举（如 idle/uploading/streaming/done/error）统一管理","用十几个互不相干的布尔值分别表示","只用一个 loading 布尔值表示全部状态","把状态存在组件外的全局变量里"],"source":"chapter","stem":"AI 产品中“上传中/生成中/完成/失败”这类流程状态，推荐的建模方式是？","subject":"前端工程","type":"single"},{"analysis":"生产级不等于“能跑”：**组件拆分清晰、状态归属明确、类型定义与错误处理完备、有必要的说明文档**，别人才接得住。类型安全能在编译期拦住大量低级错误，PR review 关注的正是这些可维护性信号。","answer":"A","chapter":"PDE·组件工程","difficulty":3,"explain":{"B":"能跑只是最低门槛，无法保证可维护。","C":"注释多不代表结构与职责清晰。","D":"只有作者讲得清，说明知识没有沉淀在代码里。"},"id":"qd-01-005","options":["组件边界清晰、类型定义完整、错误处理与说明文档齐备","只要本地能跑通、页面效果正常就算通过","注释的行数足够多","只有原作者本人能把它讲清楚"],"source":"chapter","stem":"评审“这份代码能不能交给第二个人接手”，最关键的判断依据是？","subject":"前端工程","type":"single"},{"analysis":"Core Web Vitals 为 **LCP**（最大内容渲染时间，目标 ≤ 2.5s）、**INP**（交互到下一帧渲染，目标 ≤ 200ms）、**CLS**（累计布局偏移，目标 ≤ 0.1）。口诀“LCP 二点五、INP 二百、CLS 一毛”。","answer":"A","chapter":"PDE·性能无障碍","difficulty":2,"explain":{"B":"这些数值远宽于实际目标，等于没有预算。","C":"TTFB、FPS 与包体积是有用指标，但不是 CWV 三项。","D":"这些是资源占用指标，不属于 CWV。"},"id":"qd-02-001","options":["LCP ≤ 2.5s、INP ≤ 200ms、CLS ≤ 0.1","LCP ≤ 5s、INP ≤ 1s、CLS ≤ 0.5","TTFB ≤ 100ms、FPS ≥ 120、包体积 ≤ 1MB","首屏时间 ≤ 1s、内存 ≤ 100MB、CPU ≤ 50%"],"source":"chapter","stem":"Core Web Vitals 三项指标及其“良好”目标是？","subject":"前端工程","type":"single"},{"analysis":"每来一个 token 就整列表全量重渲染会拖垮主线程、让 INP 爆掉。正确做法是只渲染可见项（**虚拟化**）并把更新**攒批**（每 2~3 帧或约 30ms 刷一次），同时用固定行高避免 CLS。","answer":"A","chapter":"PDE·性能无障碍","difficulty":3,"explain":{"B":"换模型不改变前端渲染开销。","C":"temperature 影响生成内容而非渲染性能。","D":"关闭错误提示会掩盖问题并损害可用性。"},"id":"qd-02-002","options":["消息列表虚拟化，并把更新攒批（按帧或按约 30ms 合并渲染）","把底层模型换成参数量更大的版本","提高生成时的 temperature 取值","关闭全部错误提示以减少渲染"],"source":"chapter","stem":"AI 流式输出时用户一边看字一边打字，页面出现明显卡顿，最直接的对策是？","subject":"前端工程","type":"single"},{"analysis":"“假停止”是 AI 产品的典型体验事故：必须用 **AbortController 真正取消流式请求**，或至少让 UI 立即响应并明确状态。用户点了没反应会认为产品坏了，后台请求还在继续计费。","answer":"A","chapter":"PDE·性能无障碍","difficulty":2,"explain":{"B":"动画不能替代真正的请求取消。","C":"上下文窗口与停止行为无关。","D":"网速不解决前端未取消请求的问题。"},"id":"qd-02-003","options":["用 AbortController 真正中断请求，或至少让 UI 立即响应","更多的加载动画","更长的上下文窗口","更快的网络带宽"],"source":"chapter","stem":"用户点击“停止生成”后界面看似停了，但请求仍在后台继续消耗资源，这说明缺少？","subject":"前端工程","type":"single"},{"analysis":"CLS 的经典来源是图片、广告位与异步内容没有预留空间，加载完成后把内容顶下去；**给出 width/height 或 aspect-ratio、为流式内容预留高度**是标准对策。字体策略（font-display）不当也会造成文字闪现。","answer":"A","chapter":"PDE·性能无障碍","difficulty":2,"explain":{"B":"CSS 变量本身不会造成布局偏移。","C":"请求次数影响加载速度，不直接造成位移。","D":"Grid 布局是正常排版手段，不必然产生偏移。"},"id":"qd-02-004","options":["图片或异步内容未预留尺寸，需给出 width/height 或 aspect-ratio","页面使用了 CSS 变量","页面发起的请求次数偏多","页面使用了 CSS Grid 布局"],"source":"chapter","stem":"CLS（累计布局偏移）最常见的来源及对策是？","subject":"前端工程","type":"single"},{"analysis":"无障碍四项为**语义**（用 button 而非 div onClick、label 关联输入）、**键盘**（全流程可用 Tab/Enter/Space 完成）、**焦点**（:focus-visible 可见且顺序合理）、**对比度**（正文 ≥ 4.5:1，大字号 3:1）。AI 产品还有两条专项：停止/重试按钮必须键盘可达，加载状态用 aria-live 播报。","answer":"A","chapter":"PDE·性能无障碍","difficulty":2,"explain":{"B":"补 alt 只是语义中的一小项，远未达标。","C":"div 加 onClick 对读屏与键盘不可用，应使用原生 button。","D":"隐藏焦点会让键盘用户彻底迷失位置。"},"id":"qd-02-005","options":["文本对比度至少 4.5:1，且用 Tab 键能完成上传、停止、重试与编辑的全流程","只要给所有图片补上 alt 就算达到无障碍标准","用 div 加 onClick 实现按钮，视觉上与原生按钮一致","隐藏焦点样式，避免焦点框干扰视觉"],"source":"chapter","stem":"关于 AI 产品的无障碍设计，做法正确的是？","subject":"前端工程","type":"single"}],"cert":"pde","chapters":[{"name":"PDE·AI 体验","title":"第 1 章 · AI 体验设计与大模型能力边界","url":"/pde/books/ai/ai-01-tixian/"},{"name":"PDE·状态设计","title":"第 1 章 · 流程设计与 AI 状态设计","url":"/pde/books/jiaohu/jh-01-zhuangtai/"},{"name":"PDE·组件工程","title":"第 1 章 · 组件拆分与生产级代码","url":"/pde/books/qianduan/qd-01-zujian/"},{"name":"PDE·问题定义","title":"第 1 章 · 问题定义与用户研究","url":"/pde/books/chanpin/cp-01-wenti/"},{"name":"PDE·优先级指标","title":"第 2 章 · 优先级与指标设计","url":"/pde/books/chanpin/cp-02-youxian/"},{"name":"PDE·性能无障碍","title":"第 2 章 · 性能预算与无障碍实战","url":"/pde/books/qianduan/qd-02-xingneng/"},{"name":"PDE·用户研究","title":"第 3 章 · 用户研究实战与优先级决策","url":"/pde/books/chanpin/cp-03-yonghu/"}],"practiceUrl":"/pde/practice/"}