后端转全平台 03｜把需求写成 AI 能交付的前端任务

让 AI 生成一屏收藏列表，几句话就能开始。难的是随后判断这屏东西能不能交付。标题变长有没有被截掉，加载失败能否重试，手机上能不能找到搜索框，程序说「已完成」时究竟运行了哪些检查。

这节课要交付一份可执行的前端任务说明，以及一次有证据的验收记录。你需要会读接口数据，能在本地启动项目，并有一个可以读取和修改代码的 AI 编程工具。HTML 与 CSS 的具体写法可以让工具实现，业务规则、约束和验收结论需要有人负责。

带上第一课的工程地图与第二课的视觉约束。这次委托把它们变成可运行的交互原型，沿用同一份交付工作簿记录修改范围和验收结果。

先打开慢读界面基线，看一眼三条示例数据。下载包里保留了这些材料，提示词模板可另存到自己的项目。基线页面目前只有静态内容和原生表单，尚未实现动态搜索、登录和持久保存。本课会指导你委托 AI 生成自己的练习版本，不能把基线当作已经完成这些功能的应用。

GitHub 的提示工程文档建议明确目标、提供具体例子、指出相关代码，再通过较小的任务迭代。本课参考了这些原则，把它们落实到一次前端交付里。GitHub Copilot 提示工程 ↗

一句「做个漂亮页面」遗漏了什么#

下面这段要求可以得到很多种合理答案。

帮我做一个漂亮的收藏管理页面，用现代化设计，支持搜索和移动端。

AI 可能选择密集表格，也可能画出占满首屏的大卡片。搜索可以指标题匹配，也可以包括标签、简介和全文。「支持移动端」也没有说明要保住哪些操作。模型需要自己填满这些空白，最后你会收到一组未经讨论的产品决定。

换成下面这段，第一轮就更容易检查。

做一个叫慢读的个人资料库页面。读者主要任务是找到之前保存的文章并打开原文。
先展示三条给定资料，搜索范围限定标题和简介，忽略英文大小写。
桌面采用左侧阅读状态导航、右侧列表；390px 窗口改为单列，搜索入口仍可见。
标题最多占用所需行数，不用固定高度截断。资料状态必须有文字。
沿用参考页的浅色纸张背景与深绿色强调色，先把信息层级和阅读间距做好。
交付时展示成功、无匹配结果和加载失败三种状态，并说明如何重复触发。

第二段仍允许 AI 设计字号、间距和组件实现。它先固定了会影响用户任务的选择，你就能按同一组条件比较不同方案。

「高级感」「像某个知名产品」「符合最佳实践」可以描述方向，但需要跟随可观察的要求。否则反馈容易变成下一轮的「再高级一点」。

先把项目现场交给 AI#

上下文不等于把整个仓库粘进聊天框。先让工具读取与任务相关的入口、依赖和约定，确认它能访问哪些材料。

如果你在已有产品里工作，至少提供页面路由、相邻页面、设计组件、API 契约和运行命令。组件库已有按钮，就让 AI 复用；项目用某个路由器，就别在一次页面任务里顺手更换。后端接口还没实现的字段，需要在任务里标明。

独立练习则可以解压下载包，把 AI 的工作目录设为包含 resources.json 的那一层。本课让它新建 prototype，基线文件继续用于对照。在这个目录启动本地服务，就能访问稍后生成的页面。

python3 -m http.server 8080 --bind 127.0.0.1

原型预期地址是 http://127.0.0.1:8080/prototype/index.html。这里没有现成的 prototype，它是接下来的任务产物。

先发一条只读请求也有价值。

先阅读当前目录的 README、resources.json 和 03-css/index.html、03-css/styles.css。
如果发现 package.json、项目约定文件或已有应用入口，也读取与本任务有关的部分。
列出数据字段、可复用样式、当前运行方式，以及会影响实施的未知信息。
把亲自读到的事实和你的推测分开。尚未找到的接口或组件，不要假设已经存在。

检查它列出的路径是否真实、记录数是否正确。发现上下文读错时，先纠正这一步。让错误假设进入代码，后面会更难辨认。

设计要求写到能讨论的程度#

慢读首先服务阅读和查找。这里可以让 AI 提出两种紧凑草图，再根据任务选择。草图不必精修到最终配色，先确认首屏内容和操作顺序。

这些是本次练习的设计决定，AI 可以提出更合适的替代方案。接受替代方案时，把理由和新的验收条件一起更新，别让讨论只剩审美偏好。

成功页面也只覆盖了部分工作。

空资料库和搜索无结果需要不同文案。前者没有收藏，后者仍有收藏，只是当前条件没找到。把两种情况都交给一行「暂无数据」，用户难以决定下一步做什么。

一份可以直接使用的任务 prompt#

下面的提示词针对刚解压的练习目录，生成范围刻意收在一页原型。已有应用可以替换「运行与修改范围」段，沿用自己的技术栈与组件。产品架构会在下一课单独决定。

请实现慢读个人资料库的交互原型，并实际验证结果。

用户任务
用户希望从已收藏的文章里找到一篇资料并打开原文。
本轮完成资料列表、标题与简介搜索，以及加载、空数据、无匹配和失败重试。
暂不加入登录、添加收藏、服务端写入和跨设备同步。

先读材料
读取 README.md、resources.json、03-css/index.html 和 03-css/styles.css。
读取 workbook.md 中前两课填写的工程事实、视觉约束与未确认项。
如果已经完成第二课，读取 ui-review/index.html、ui-review/styles.css 和工作簿记录的截图。
界面副本放在其他位置时，先按工作簿中的真实路径查找；未做界面练习则注明，沿用静态基线。
resources.json 是唯一的示例数据来源，保留其中三条记录的标题、链接和状态。
静态基线用于对照视觉与内容，它目前没有动态搜索。
文件不存在时报告具体路径；不要把缺失的文件或接口描述成已经读过。

运行与修改范围
在当前示例目录中新建 prototype 目录，把 index.html、styles.css、app.js 都放在其中。
使用浏览器原生 HTML、CSS 和 JavaScript，不为这一页引入框架和远程依赖。
用当前目录的本地 HTTP 服务运行，页面地址为 /prototype/index.html。
不要覆盖 02-html 和 03-css 基线，也不要更改其他目录。
将已确认的视觉规则应用到 prototype，不覆盖 ui-review 中的对照产物。

数据与行为
通过相对路径读取 ../resources.json，检查 items 是数组且必需字段有效。
正常数据中 id、title、url、description 是字符串，tags 是字符串数组。
status 允许 unread、reading、archived，对应未读、阅读中、已归档。
标题与简介进行包含匹配，忽略英文大小写，首尾空格不影响查询。
这是三条固定数据的客户端筛选，不接入虚构的搜索接口。
无匹配时保留输入并提供清除条件，失败时重试不清空搜索词。

界面方向
参考基线的浅色背景、深绿色强调色和文字层级。
桌面保留侧栏与列表，窄屏改成单列，优先保证搜索和资料可读。
标题和简介允许自然增高，长网址可换行，不靠隐藏溢出来掩盖问题。
输入框有可见标签，链接与按钮按实际用途实现，焦点清楚，支持键盘操作。

可重复的异常场景
提供仅用于这个练习的明确入口，切换 loading、empty、error 和 success。
loading 保持等待直到切换，error 状态允许重试恢复成功。
场景切换入口标注为模拟数据，交付说明写清楚触发方式。
不要把模拟状态或临时内存数据描述成真实服务端能力。

验收与证据
在 1280px、390px、320px 下检查布局，记录实际视口尺寸。
用长标题和连续无空格网址检查换行，用键盘完成搜索、清除与打开链接。
确认三条数据的链接正确，中文搜索正常，无匹配与加载失败可以分别复现。
检查 Console 与 Network，说明看到的异常以及是否属于本次修改。
如果有浏览器工具，提供实际截图与关键操作结果；没有则标记未验证并给出步骤。
只报告真正执行过的命令、测试和结果，失败要保留，不要生成预期结果充当证据。

交付内容
给出运行地址、修改文件、已验证项目和仍未验证的项目。
发现影响实现的歧义时列出具体选择和建议；在已明确范围内继续完成工作。

这段 prompt 同时定义了成果和证据。320px、390px、1280px 是本课挑选的检查尺寸，覆盖它们不代表覆盖所有设备；遇到实际用户设备仍要补测。原型的运行时字段检查也只解决数据输入问题，真实应用还需要服务端权限与业务校验。

拿到代码后，检查它说了什么#

先打开页面走一遍任务，再看修改。不要把浏览器截图、构建通过和用户流程通过混为一个结论。

AI 可以执行这些检查，也可以协助你审查自己的代码。你需要核对证据与结论是否对应。一个改动声称修好了「手机布局」，只提供桌面截图，证据就不完整。GitHub 的代码审查指南同样强调检查生成代码的正确性、边界情况和可维护性。审查 AI 生成代码 ↗

无障碍检查也需要具体操作。自动扫描能找到部分问题，仍应手动检查焦点顺序、标签与键盘行为。让 AI 跑工具，然后自己走一次主要流程，两种结果可以相互补充。MDN 无障碍测试工具 ↗

出问题时，给出复现条件再要求修改#

「搜索有问题，修一下」仍会让 AI 猜测范围。先在请求与性能实验室观察竞态，再把你实际记录的证据填进下面这份调试 prompt。实验室用本地计时器模拟响应，下面的顺序和计划延迟与它一致，实际执行时间以日志为准。

请定位异步搜索出现旧结果覆盖新结果的原因，并做最小范围修改。

复现条件
在配套实验室的故障模式下点击一键复现竞态。
它先搜索 HTML，计划延迟 900ms；80ms 后搜索 React，后一次计划延迟 200ms。
当前关键词最后是 React，页面最终也必须保留 React 对应结果。
我实际观察到的结果、发生问题的页面地址和截图如下
[粘贴观察记录，不确定的内容写未确认]

排查要求
先沿输入事件、查询条件、请求发出、响应处理、状态更新追踪数据。
记录每个请求对应的关键词和先后次序，找到旧响应怎样进入当前界面。
基于读到的代码解释原因，再修改相关文件，不重写页面的视觉样式。
考虑取消旧请求或让失效响应不能更新状态，并说明选择理由。

验收要求
先在故障模式记录旧结果覆盖，再切换修复模式重复上述次序，比较实际日志。
扩展验收可以修改本地模拟器，反过来设置响应速度；当前页面没有这个切换选项。
接入自己的真实搜索页后，再检查正常搜索、清空输入和请求失败，保留用户当前输入。
报告修复前后的实际观察和执行过的检查；没有运行的检查明确写出。

取消请求和忽略失效响应都是可讨论的实现办法。验收应约束最终结果，而无需先认定某个 API 就是唯一修法。React 的 Effect 教程给出了搜索请求乱序及清理失效响应的具体示例，这个问题也会发生在其他 UI 技术中。React 关于 Effect 与数据请求的说明 ↗

如果修复没有生效，继续附上新证据。说明哪一步仍失败，检查它改的是复现问题的文件，还是另一个看起来相似的页面。每次只扩大到证据指向的范围，避免一次搜索故障演变成整个项目的重写。

本课要留下的东西#

保存你的最终任务 prompt、可以运行的原型，以及一份简短的验收记录。记录里至少有一个异常状态和一次窄屏检查，未完成的检查写明原因。

把原型地址、数据来源、完整 prompt 和检查记录填入工作簿的第三课。下一课根据这份原型讨论正式应用的架构，尚未存在的 API 继续标成待确认。

最后更改一个原先没覆盖的条件。可以把资料标题加长，也可以返回不合法的 tags。让 AI 解释页面实际发生了什么，要求它补一个针对该问题的修复和验证。你能根据材料判断这次修改是否成立，就已经完成了本课最有价值的练习。