极点宏观｜Financial Cloud Cloud · 构建文章
打造静态 AWS 模拟考场背后的练习引擎
这篇文章将深入探讨 Demo 背后的练习引擎，详细说明如何通过单一 HTML 文件，利用查询字符串（Query Strings）加载多个题库；剖析为什么 JSON 契约（Contract）如此重要；解析提交（Submit）与下一题（Next）的行为如何串起学习循环；以及移动设备的版面设计抉择如何创建用户信任。我们的核心焦点在于实用的工程纪律：简单的状态（State）、直觉的反馈（Feedback）、可重复使用的数据（Data），以及引导出可维护行为的 Prompt（提示词）。
免责声明
● 项目宗旨：本平台为独立开发项目，仅专注于推动教育探索与人工智能（AI）研究。旨在不受任何外部力量影响的情况下，促进对现代技术的深入理解。用户可在这个安全环境中研究复杂系统、测试创新想法并进行安全学习。
● 非商业用途：本独立项目绝无任何潜在的商业模式，亦完全不以获取财务收入、金钱利润或任何具体商业价值为目的。我们的核心重点纯粹在于学术发展，确保所有访问完全免费，不包含任何隐性成本、企业赞助或广告策划。
● 不保证正确性：由于本平台为采用实验性人工智能的教育工具，产出的内容偶尔可能不准确、具误导性或不完整。所有提供的内容均以「现状（As-is）」提供，不附带任何明示或暗示之保证、事实正确性担保，或对整体可靠性的任何承诺。
目录
● 第一部分：围绕 URL 状态设计练习引擎
说明如何通过测验、章节与题目的查询参数，在没有后端或账户系统的情况下，让每一次的练习状态都能被分享、测试，并极易进行调试。
● 第二部分：多个测验共用单一 JSON 结构
探讨可重复使用的题库 Schema（模式），以及为什么一致的字段能让同一个渲染器支持数据、机器学习、网络、云运营、金融服务业（FSI）与 AI 开发等练习题库。
● 第三部分：将提交反馈打造为学习循环
剖析答案判定模式：选取的答案、排序后的标准答案、结果文本、逐项选项解析，以及不使用多余红绿色特效的极简 UI。
● 第四部分：将移动设备按钮视为产品质量的体现
展示移动版界面中加大题目、提交与下一题按钮的重要性，以及微小的响应式调整如何让 Demo 从「堪用」跃升为「好用」。
● 第五部分：以契约进行调试，而非凭空猜测
将常见的氛围式编程（Vibe Coding）错误转化为具体检查点：获取失败、丢失 JSON 文件、答案不一致、无效的查询字符串，以及需要可预期退路（Fallback）的页面状态。
第一部分：围绕 URL 状态设计练习引擎
目标
打造一个可以分享、刷新、加入书签、调试，且能直接从营销网页打开的题目画面。
Prompt
URL 查询字符串应包含测验名称、章节与题目，且网页应直接跳转至对应的题目。
结果
practice-room.html 会从 URLSearchParams 中读取 exam、chapter 与 question。它会据此推导出 JSON 文件名称并进行获取（fetch）、找出指定的章节与题目、渲染画面，并在切换题目时动态更新 URL。
提示
● URL 是一种产品界面，而不仅仅是浏览器上的一段装饰。
● 默认值应让本地测试（Local Testing）更为轻松。
● 当导航需在不离开网页的情况下更新上下文时，请使用 replaceState。
● 保持查询参数名称易于人类阅读。
● 确保每个卡片链接都能打开一个有意义的第一题。
小结：URL 契约是最小型的路由系统。它能在没有路由、服务器、数据库或验证层的情况下，创建深层链接（Deep Links）。
第二部分：多个测验共用单一 JSON 结构
目标
通过强制执行单一且稳定的内容结构（Shape），让多种测验主题共用同一个渲染器（Renderer）。
Prompt
在添加练习题库时，应反复强调以
aws_certified_data_exam_questions.json为模板。
结果
所有题库均以一致的架构呈现章节、题目、选项、答案与解析。这让同一个 UI 能够支持数据分析（Data）、机器学习（ML）、网络（Networking）、云运营（Cloud Operations）、金融服务（FSI）交易、生成式 AI 以及 AI 开发等题库。
提示
● 不要让每次导入的内容都自创一套 Schema。
● 将 answer（答案）字段保持为数组（Array），如此单选题与复选题就能共用同一套数据模型。
● 解释（Explanations）应以选项字母作为键值（Key）。
● 将显示标题（Display Titles）保存在 JSON 中，让 UI 能自动加载对应的标签。
● 在宣称系统规模之前，先用自动化工具统计题目总数。
文件夹中的题库清单
● aws_ai_development_exam_questions.json: 共 1 章，含 20 题。
● aws_generative_ai_dev_organization_exam_questions.json: 共 4 章，含 80 题。
● aws_netowrking_core_exam_questions.json: 共 2 章，含 98 题。
● aws_fsi_trading_desk_design_exam_questions.json: 共 34 章，含 680 题。
● aws_certified_cloud_operations_exam_questions.json: 共 5 章，含 520 题。
● aws_fsi_macro_trading_exam_questions.json: 共 23 章，含 380 题。
● aws_certified_machine_learning_exam_questions.json: 共 4 章，含 460 题。
● aws_certified_data_exam_questions.json: 共 5 章，含 82 题。
● aws_certified_data_exam_questions_v1.json: 共 5 章，含 82 题。
第三部分：将提交反馈打造为学习循环
目标
通过在提交答案后显示每个选项对或错的理由，将简单的测验转化为深度学习体验。
Prompt
提交时显示正确与错误答案的解析，并明确指出不需要使用红绿色的 UI 视觉效果。
结果
实现会先将用户选取的答案与正确答案进行排序与比对，印出比对结果与标准答案，最后为每个选项渲染独立的解析区块。
提示
● 在最初的学习循环中，纯文本反馈便已足够。
● 在解析质量足够扎实之前，避免使用花俏的对错 UI 特效。
● 确保「已选取」与「正确答案」的状态在结果中清晰可见。
● 单选题（Radio Input）与复选题（Checkbox）共用相同的提交判断路径。
● 为「无解析」的情况设计明显的默认提示（Fallback），以便快速修正内容缺漏。
小结：这在「氛围式编程（Vibe Coding）」中非常关键，因为它能防止 AI 进行过度设计。用户所要求的并非游戏化的计分板，而是一个安静的自修室（Study Room）。UI 应全心服务于用户的记忆检索与复习。
第四部分：将移动设备按钮视为产品质量的体现
目标
让模拟考场在手机上也能好用，因为许多开发者（Builders）会利用会议空档、通勤途中或短暂的复习时间在手机上自学。
Prompt
移动版版面应将题目与答案选择区置于上方，题目清单置于下方，并加大题目按钮，以及提交和下一题按钮。
结果
CSS 通过媒体查找（Media Queries）来调整版面顺序、加大按钮点击区域，并在屏幕变窄时，确保题目清单依旧好读好按。
提示
● 移动版易用性不是最后的修饰（Polish Pass），而是核心行为。
● 当人们用手机学习时，按钮大小本身就是一项重要的「学习功能」。
● 内容的编排顺序远比美化装饰更重要。
● 保持当前题目处于高亮（Highlighted）状态。
● 在动用复杂的组件之前，先尝试使用简单的 Grid 与 Flex 布局。
小结：如果用户常常在手机上点错答案，这款练习产品就失败了。按钮变大并不只是为了解决美观，更是为了守护用户的专注力。
第五部分：以契约进行调试，而非凭空猜测
目标
通过验证 HTML、URL 与 JSON 边界之间的假设，让程序在发生异常时能自己说明原因。
Prompt
项目构建要求直接通过查询字符串（Query String）加载 JSON，后续又追加了许多测验文件名。这代表拼写错误与文件丢失是最常见的错误模式。
结果
播放器会捕获（catch）加载失败的错误，并显示清晰的消息，提示用户确认测验查询参数与 JSON 文件是否存在。
提示
● 当 Fetch 失败时，直接在 UI 显示加载失败的文件名，而不仅仅是打印到控制台（Console）。
● 当缺少某个章节时，应有可预期的退路（Fallback）。
● 当缺少某个题目时，自动跳回第一题。
● 在添加卡片（Card）时，务必确认对应的 JSON 文件存在。
● 添加题库时，记得检查答案数组与解析键值。
小结：调试的道理很简单：如果 AI 创建了一个链接，下一道 Prompt 就应该去验证该链接背后的文件。在氛围式编程（Vibe Coding）中，你需要养成这种「验证反射」习惯。
1：URL 状态
● 背景：此练习播放器需要可供分享的链接，以便在不需要服务器端路由的情况下，直接打开特定的测验、章节与题目。
● 目标：让每一个学习状态都能通过 URL 定位。
● Prompt：使用 exam、chapter 与 question 等查询参数导向至关联题目。
● 结果：网页读取 URLSearchParams，解析出 JSON 文件路径，找出对应章节，并高亮显示目前题目。
● 提示：使用稳定的参数名称。默认导向已知的练习题库。在切换题目时同步更新 URL。让卡片链接到真实存在的状态。测试拷贝粘贴的 URL 链接。
● Demo 实证：网页成功读取 URLSearchParams、解析 JSON 文件、定位章节，并突显目前题目。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对 URL 状态，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
2：JSON 加载
● 背景：应用程序直接从同一个文件夹加载静态 JSON 文件。这能大幅简化部署作业，但文件名就变得极为关键。
● 目标：不需经过打包（Bundling）或撰写后端代码，即可通过单一播放器加载多个题库。
● Prompt：让 HTML 网页加载 URL 查询字符串对应的 JSON。
● 结果：播放器会从 exam 参数中推算出文件名称，并在进行渲染前获取（fetch）该文件。
● 提示：卡片上的测验名称需与实体文件名一致。显示友好的获取错误消息。保持 JSON 架构（Schema）一致。避免隐藏的数据转换。验证第一题是否能正常渲染。
● Demo 实证：播放器从 exam 参数解析出文件名，并在渲染前获取该文件。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对 JSON 加载，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
3：答案判定
● 背景：AWS 风格的练习教材中，同时存在单选题与复选题。
● 目标：不论是单选按钮（Radio Button）或复选框（Checkbox），都共用同一条答案判定路径。
● Prompt：提交答案时应显示正确与错误答案的解析。
● 结果：程序收集用户选取的输入、对其进行排序，接着与排序后的标准答案数组比对，最后印出结果。
● 提示：将答案以数组形式保存。比对前先进行排序。不要默认只有单一答案。保持已选取状态清晰易读。测试包含「选两个答案（Select Two）」的复选题。
● Demo 实证：程序收集已选取输入、进行排序、比对排序后的标准答案数组并印出结果。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对答案判定，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
4：多选逻辑
● 背景：多重答案（复选）题目的数据模型应与单一答案（单选）题目相同，无需拆分。
● 目标：由答案数量决定输入控制项的类型（单选或复选），同时保留完全一致的渲染流程。
● Prompt：多选（单一答案）项目只有一个 Key；「选两个答案（Select-Two）」的项目则有多个 Key。
● 结果：当答案数组只有一个值时，渲染器会使用单选按钮（Radio Inputs）；当有多个值时，则改用复选框（Checkboxes）。
● 提示：从数据中派生 UI 呈现。避免重复撰写渲染器。保持输入字段名称（Name）一致。进行完整答案集的比对。在题目文本中特别注明「选取两项（Select-Two）」等提示。
● Demo 实证：当答案数组仅有一个值时使用单选按钮，大于一个值时则使用复选框。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对多选逻辑，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
5：解析渲染
● 背景：学习的价值在于解题脉络（Rationale）与逻辑，而不只是最后得分。
● 目标：提交答案后，展示所有选项的对错说明与解析。
● Prompt：当用户点击提交时，显示正确与错误答案的解析，且不使用红绿色 UI 视觉效果。
● 结果：结果区块中会条列每个选项的已选状态、答案状态以及对应的解析文本。
● 提示：解释干扰项为何错误。保持标准答案清晰可见。在考虑色彩特效前先使用文本说明。为没有解析的内容提供默认回报机制。审查解析文本的质量。
● Demo 实证：结果框列出了各选项的已选状态、答案状态以及解析文本。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对解析渲染，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
6：章节导航
● 背景：大型题库包含多个章节与数百道题目，因此导航界面必须保持简洁易用。
● 目标：直接从 JSON 结构动态渲染出章节群组与题目按钮。
● Prompt：左侧区域横向呈现所有章节与题目。
● 结果：题目清单会依章节将按钮分组，并高亮标记当前题目。
● 提示：从数据动态生成导航。保持章节标签精简。突显当前状态。在切换题目时重置（Reset）比对结果。避免手动写死（hardcode）按钮的 HTML 标记。
● Demo 实证：题目清单会按章节分组，并突显当前题目。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对章节导航，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
7：错误状态处理
● 背景：静态网页播放器最常因为查询字符串指向不存在的 JSON 文件，或是加载到格式错误的内容而故障。
● 目标：让错误消息对正在测试链接的人而言一目了然。
● Prompt：请确认 exam 查询参数与 JSON 文件。
● 结果：catch 区块会变更网页标题、显示错误消息，并呈现清晰的「空白状态（Empty State）」操作指引。
● 提示：在 UI 上呈现失败信息，而非仅打印到控制台（Console）。指明可能的修正方案。在出错后仍能保持页面可用。测试无效的 exam 参数值。不要隐藏 Fetch 错误。
● Demo 实证：catch 区块修改标题、显示错误消息并呈现清晰的空白状态指引。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对错误状态处理，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
8：数据契约重复使用
● 背景：同一个渲染器能直接支持数据分析（Data）、机器学习（ML）、网络（Networking）、云运营（Cloud Operations）、金融服务（FSI）、生成式 AI 以及 AI 开发等练习题库。
● 目标：通过确保所有题库都对齐相同的字段结构，来维护重复使用性。
● Prompt：以 aws_certified_data_exam_questions.json 为模板。
● 结果：添加题库变成了单纯的「内容添加」，而不需要修改任何代码。
● 提示：使用黄金模板（Golden Sample）。检查 answer 与 explanations 字段。保持章节数组结构一致。避免针对特定测验装饰分支 UI 逻辑。导入完成后，统计题目数量。
● Demo 实证：添加题库成了纯粹的内容扩展，而非代码层面的修改。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对数据契约重复使用，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
9：结果重置
● 背景：若学习者在提交答案后切换至新题目，残留的旧反馈可能会干扰新题目的作答。
● 目标：在导航状态（切换题目）改变时，立即清除作答结果状态。
● Prompt：下一题应切换至下一道题目，并干净地呈现新题目。
● 结果：播放器会在切换题目时，隐藏并清空结果框（Result Box）。
● 提示：点击下一题时重置。点击题目按钮时重置。渲染后保持答案未选取状态。避免残留旧的对错文本。让状态转换过程清晰直觉。
● Demo 实证：播放器在题目切换期间会隐藏并清空结果框。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对结果重置，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
10：下一题行为模式
● 背景：模拟考场需要一个流畅、快速切换题目的机制，而不需要强迫用户退回清单重新点击。
● 目标：在当前章节中循序前进，并在章节结束时自动跳转至下一章的第一题。
● Prompt：下一题：导向至下一题。
● 结果：goNext 函数会递增题目索引值（Index）；当前章节结束时，则会推进章节索引值。
● 提示：在最后一题时禁用「下一题」按钮。同步更新查询字符串（Query String）。重置反馈状态。在状态改变后重新渲染。测试章节与章节之间的切换边界。
● Demo 实证：当前章节结束时，goNext 函数会增加题目索引值或推进章节索引值。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对下一题行为模式，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
11：电脑版版面配置
● 背景：电脑版的 Prompt 将「导航」与「作答」明确拆分：左侧为题目列表，右侧为当前作答区。
● 目标：善用宽屏幕宽度，降低电脑版学习者的认知切换成本。
● Prompt：电脑版网页配置：左侧为题目按钮列表区；右侧为题目与答案选择区。
● 结果：网页网格（Grid）配置提供了一个稳固的侧边栏（Sidebar）与较宽广的主内容面板。
● 提示：使侧边栏支持滚动。确保主内容面板维持专注度。避免使用弹出式窗口（Modal）进行导航。使用可预期的字段排版。适度放大电脑版文本大小。
● Demo 实证：网页网格提供一个稳定的侧边栏与较大的主内容区块。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对电脑版版面配置，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
12：移动版版面配置
● 背景：在移动设备上，若采用「侧边栏优先」的排版，会逼学习者必须先滑过整串导航链接才能看到题目。
● 目标：重新调整页面顺序，让当前题目置顶最先呈现。
● Prompt：移动版网页配置：上方为题目与答案选择区，下方为题目按钮列表区。
● 结果：CSS 的 order 属性规则在小屏幕上会将右侧面板排在左侧面板上方。
● 提示：将核心任务放在最前面。将导航功能往下移。增加组件间距。保持按钮大尺寸。使用长题目进行测试。
● Demo 实证：CSS 的 order 规则在小屏幕下会将右侧面板移至左侧面板上方。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对移动版版面配置，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
13：题目按钮大小
● 背景：在手机屏幕上，微小的数字按钮会令人非常沮丧，特别是题库里有大量题目时。
● 目标：提升移动版复习时的点击准确度。
● Prompt：移动版：题目按钮列表加大按钮尺寸。
● 结果：移动版 media query 会调大题目按钮的宽度、高度、内边距（Padding）与字体大小。
● 提示：专为大拇指设计触摸区。避免过于拥挤的点击目标。保持数字清晰易读。使用自动折行的横列排版。维持当前题目的高亮显示。
● Demo 实证：移动版媒体查找调大了题目按钮的宽高、内边距与字体大小。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对题目按钮大小，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
14：提交与下一题按钮加大
● 背景：「提交」与「下一题」是整个应用程序的核心交互按钮。如果它们看起来或点起来太小，整个程序就会给人一种粗糙未完成的感觉。
● 目标：让移动设备上的主要操作（Primary Actions）更为舒适流畅。
● Prompt：移动版：加大「提交」与「下一题」按钮的尺寸。
● 结果：移动版中，这些操作按钮获得了更大的最小高度（min-height）、内边距与字体大小。
● 提示：优先处理核心操作按钮。采用一致的高度。避免拥挤的横向排版。确保「禁用（Disabled）」状态清晰可见。测试单手操作的便利性。
● Demo 实证：移动版中的核心操作按钮拥有更大的最小高度、内边距与字体。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对提交与下一题按钮加大，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
15：选项渲染处理
● 背景：为了容纳 AWS 风格多行且复杂的情境式答案，选项之间需要足够的间距。
● 目标：将每个选项渲染为 <label> 元素，以便学习者点击文本时即可直接选取该项目。
● Prompt：回应（Responses）是可能的解答；各选项的长度与复杂度应维持相仿。
● 结果：每个选项均使用 <label> 包裹 input 元素与文本内容，借此提升无障碍性（Accessibility）与点击体验。
● 提示：将 input 与文本包裹在一起。使用选项字母。允许长文本自动换行。保持间距一致。避免微小、难以点击的单选框目标。
● Demo 实证：每个选项都采用包覆着 input 与文本的 label 外壳，改善了无障碍度与点击反应。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对选项渲染处理，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
16：网址状态实时同步
● 背景：学习者在应用程序中反复切换点击后，应能直接分享当下看到的特定题目链接。
● 目标：让浏览器网址列（URL）随时与应用程序当前状态保持同步。
● Prompt：当用户点击某个题目时，跳转至对应题目。
● 结果：updateQueryString 函数会将当前的 exam（测验）、chapter（章节）与 question（题目）参数写入 URL 中。
● 提示：在每次切换导航后更新 URL。使用 replaceState 进行静默更新（无感刷新）。保持 exam 参数中不包含扩展名。避免触发页面完整重新加载。验证分享链接的有效性。
● Demo 实证：updateQueryString 函数会将 exam、chapter 与 question 写入网址列。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对网址状态实时同步，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
17：舍弃框架的纯粹决策
● 背景：此应用程序仅需要 Fetch API、DOM 动态产生、极简状态管理以及少数的事件接听器（Event Listeners）。
● 目标：在交互模型真正需要之前，极力避免引入繁重的 JavaScript 框架。
● Prompt：创建一个不带多余装饰的简单深色模式网页。
● 结果：模拟考场代码完美封装在单一极具可读性的 HTML 文件中。
● 提示：小型 Demo 请直接采用原生 JavaScript（Vanilla JS）。保持状态对象极小化。直接依数据动态创建 DOM。避开不必要的项目构建步骤（Build Steps）。只在代码真的变得难以维护（Pain Point）时才进行重构。
● Demo 实证：模拟考场在单一 HTML 文件中保持良好可读性。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对舍弃框架的纯粹决策，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
18：内容质量闸门控制
● 背景：出题指南指出，干扰项（Distractors）必须具备高度诱答性，且解析必须能确实推论出标准答案。
● 目标：将内容审查无缝集成至工程开发的工作流程中。
● Prompt：遵循出题指南，并将练习题库提升至专业水平。
● 结果：JSON 结构保留了选项层级的解析，方便日后进行独立稽核与查看。
● 提示：审查干扰项。确认标准答案 Key 的唯一性。避免过时的陈述。使用主动语态。保持解题逻辑符合最新版考试大纲。
● Demo 实证：JSON 结构保留了选项层级的详细解析以利后续稽核。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对内容质量闸门控制，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
19：公开链接完整测试
● 背景：首页（Landing Page）卡片上的每个入口，都与模拟考场对应的 URL 有着紧密的相依性。
● 目标：将每一张测验卡片都视为播放器功能测试的独立 Test Case。
● Prompt：添加测验卡片，并附带 exam_name&chapter=1&question=1 的链接。
● 结果：题库资源库（Library）成功转化为一整套能直接深层链接（Deep Links）至应用程序内部的捷径。
● 提示：实际点击每一张新加入的卡片。仔细核对 JSON 文件名拼写。确认初始章节编号。确认第一题编号。确认标题是否能顺利加载。
● Demo 实证：资源库转化为一系列可直接深层链接至应用程序内的完整入口。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对公开链接完整测试，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。
20：学习循环权责拆分
● 背景：模拟考场播放器负责实践学习行为，而首页（Landing Page）则负责内容的探索与分流。
● 目标：实施严格的权责拆分（Separation of Concerns），让未来的修改保持单纯与高维护性。
● Prompt：使用 index.html 呈现题库目录，并用 practice-room.html 进行题目练习。
● 结果：整个系统可以在完全不改动「答案判定逻辑」的情况下扩展目录清单，亦能在完全不重写「营销文案」的前提下精进播放器的功能。
● 提示：将探索流程与实著作答分开。将所有内容完好存放在 JSON 中。以超链接作为系统边界。避免跨文件之间的过度耦合。明确记录每项行为的权责归属。
● Demo 实证：本系统能完全独立扩展目录，而不必改动答案判定；同时也能精进播放器，而不用调整首页文案。这是审查人员可以直接验证的部分。实战笔记应紧扣这项实证，而非流于泛泛的氛围式编程空谈。
● 审查检查点：针对学习循环权责拆分，确认三件事：背景是否描述了真实的项目压力、目标是否点出预期行为，以及结果是否指向文件中或浏览器上清晰可见的具体实现。若三者缺一，发布前请重新撰写此笔记。