# 慢读 · AI 辅助前端开发提示词 先填写每份模板中的项目事实和待填材料，再交给能够读取仓库的 AI。没有提供的截图、日志、接口和测量结果属于未知信息，不要补成事实。每次只处理一个可验收任务。 以下八份 prompt 摘录自六课正文。前两课各两份，03 需求开发会生成下载包中尚不存在的 prototype。应用到已有项目时，替换工作目录与修改范围。 [课程总目录](https://tsonglew.github.io/blog/backend-to-platform) · [交付工作簿](./workbook.md) · [本地实验室](./lab/index.html) ## 01A 工程接手 prompt 只读建立工程地图，分清静态页面、模拟实验与真实应用。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-project) ```text 请只读调查当前工程，帮助一位有后端经验的开发者接手。 当前材料是慢读课程下载包，工作目录应包含 README.md、resources.json、lab 和 03-css。 这轮不修改文件，不安装依赖，不启动进程，不根据常见模板补造缺失文件。 先确认工作目录，阅读项目说明与约定，再找页面入口和引用关系。 如果存在 package.json，读取 scripts、依赖、packageManager、engines，结合锁文件、版本文件和 CI 配置判断运行方式。 如果这些文件不存在，明确写出，并根据实际文件说明怎样运行。 以实验室的“一键复现竞态”按钮为目标，从页面元素追到事件处理函数，再追到数据来源、状态变化和页面更新。 说明数据来自真实 HTTP、内存、定时器模拟还是静态内容。没找到的环节标记为未知。 对于 React 或 Vue 工程，额外寻找路由到页面组件的关系、组件状态与请求封装，但只报告真实存在的文件。 输出一份工程地图，包含入口、启动条件、关键文件及职责、操作调用链和未知项。 每个关键判断附文件路径与符号名，工具支持时给行号。 最后给我三个可以自行打开文件核对的问题，以及下一步最小验证动作。 把读代码得到的推断和实际执行结果分开，未运行的检查不能写成通过。 ``` ## 01B 启动诊断 prompt 先填原始命令和失败证据，再做最小修复。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-project) ```text 请定位当前工程的启动或访问失败，先调查，再做最小修复。 工程与目标页面 [工作目录、工程类型、预期访问的完整 URL] 环境 [操作系统、Node 与包管理器版本；静态示例则写 Python 版本] 执行经过 [按顺序列出原始命令、各自工作目录、退出码或进程是否仍运行] 失败证据 [原始终端报错、浏览器 Console 错误、失败请求 URL 与状态码] 已经尝试的操作 [实际改动及结果，没有就写没有] 先根据真实文件判断问题属于目录、环境、依赖、构建、浏览器加载还是业务执行。 列出最可能的两个原因，每个原因写明现有证据和能区分它们的下一步检查。 工具可以执行检查时先复现，不能访问终端或浏览器时明确限制，给我可执行的采集步骤。 确认原因后，修复范围只覆盖这个阻塞，说明修改前后差异与回退方式。 不要为消除报错删除锁文件、批量升级依赖、更换框架，或关闭类型检查与 lint 规则。 如果修复必须涉及这些变化，先说明依据、影响和可选方案，等待我选择。 复测原来的命令和目标页面，记录命令、退出结果及浏览器证据。 最后分开列出已确认原因、已执行修复、已验证结果与未验证项。 没有执行过的测试不能写成通过，启动成功也不能写成功能全部通过。 ``` ## 02A 视觉改进 prompt 填写真实截图和视觉目标，只修改一个明确问题。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-interface) ```text 请改进慢读的资料列表界面，本轮只处理一个已明确的问题。 输入材料 - 当前页面 URL 与本地目录填写在这里 - 当前截图、视口宽高、浏览器版本与缩放比例填写在这里 - 参考截图填写在这里，并标注要借鉴的区域与原因 - 当前最需要改善的现象填写在这里 - 期望的可见变化填写在这里 - 允许修改的文件填写在这里 先阅读实际 HTML、CSS 和已有组件，不猜测项目使用的框架。 说明当前结构、字体、密度、间距与交互状态，指出本轮涉及的规则。 已有样式变量和组件优先复用。需要新依赖时先说明用途与代价。 本轮约束 - 保留三条资料及真实链接，保留标题层级和表单 label - 保留原生 GET 表单，提交仍只改变 URL，不声称已经支持筛选 - 标题允许完整换行，状态继续显示文字 - 保留键盘焦点与跳到资料列表的入口 - 不重写整页，不同时修改业务行为 先提出一个小范围方案，再在允许文件内实施。 按相同数据、视口、缩放比例给出修改前后截图。 验证宽屏与 320 CSS px 窄屏，再用 Tab 检查相关控件。 若没有浏览器能力，明确列为未验证，给出人工操作步骤。 截图文件注明视口和修改版本，不能用不同尺寸的图片冒充前后对照。 最后交付修改文件、变更理由、实际验证结果及尚未验证的项目。 视觉评价请指出具体元素和差异，不能只写“更美观”。 ``` ## 02B 样式修复 prompt 填写元素尺寸与 Computed 证据，按原步骤复测。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-interface) ```text 请定位慢读的一处样式故障，先依据证据提出原因，再做最小修复。 页面 URL、代码目录与允许修改文件 填写这里 复现环境 填写浏览器版本、视口宽高、缩放比例和测试数据 复现步骤、预期与实际结果 填写这里，并附能看出问题的截图 已经取得的证据 - 越界或错位元素的选择器填写在这里 - 元素和父容器的实际尺寸填写在这里 - Computed 中相关属性的最终值填写在这里 - 获胜规则的文件与行号填写在这里 - 已尝试的改动及观察结果填写在这里 没有取得的内容写未取得，不补造数值。 请解释证据支持哪个原因，还有哪个条件需要验证。 若材料不足，给出下一项 DevTools 检查及预期观察，不直接大改。 优先修正造成故障的规则，避免连续追加覆盖规则。 不得用隐藏溢出、裁掉必要文字或删除焦点样式来掩盖问题。 不更换框架、组件库或数据，不改与本故障无关的文件。 修复后按原步骤复测，并复查正常标题、长标题、窄屏和键盘焦点。 输出实际修改、原因、前后证据、已验证与未验证项目。 无法打开浏览器时只提供待验证说明，不能声称测试通过。 ``` ## 03 需求开发 prompt 在解压后的练习目录生成尚不存在的 prototype，保留原有基线。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-01-browser) ```text 请实现慢读个人资料库的交互原型，并实际验证结果。 用户任务 用户希望从已收藏的文章里找到一篇资料并打开原文。 本轮完成资料列表、标题与简介搜索，以及加载、空数据、无匹配和失败重试。 暂不加入登录、添加收藏、服务端写入和跨设备同步。 先读材料 读取 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，说明看到的异常以及是否属于本次修改。 如果有浏览器工具，提供实际截图与关键操作结果；没有则标记未验证并给出步骤。 只报告真正执行过的命令、测试和结果，失败要保留，不要生成预期结果充当证据。 交付内容 给出运行地址、修改文件、已验证项目和仍未验证的项目。 发现影响实现的歧义时列出具体选择和建议；在已明确范围内继续完成工作。 ``` ## 04 架构 ADR prompt 核实已有能力与部署条件，再比较方案和状态归属。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-02-html) ```text 请为慢读的第一版真实应用起草一份简短 ADR，先研究与比较，暂不迁移项目。 已知产品范围 公开介绍页主要是稳定内容，登录后的资料工作台需要搜索、筛选与编辑。 目前已有独立 HTTP API 这一项请先核实；没有相关文件时标记为待确认。 仓库中的 resources.json 只是固定示例，不代表真实接口已经存在。 读取当前 README、依赖、路由、部署配置和有关 API 的材料，列出你的依据。 需要比较的决定 按公开页面与私有工作台分别比较 SSG、SSR、CSR 的适用条件。 至少给出沿用当前栈和一个有理由的替代方案，不为凑数罗列所有框架。 结合团队经验、已有组件、关键交互和托管条件比较，不按框架热度直接下结论。 如果建议 React + Vite，解释路由、数据缓存和部署回退由谁提供。 如果建议 SSR，说明服务端在哪里运行，用户数据怎样隔离，缓存如何失效。 ADR 内容 记录已确认约束、未确认假设、最终建议和不选择其他方案的具体原因。 列出依赖变化、运行成本，以及一种足以让当前决定失效的未来需求。 区分文档支持的事实、你的推断、需要实验的数据，附少量官方来源。 对首屏或性能的比较先设计同条件实验，没有实测就不要给百分比结论。 状态设计 画出 URL 条件、服务端资料、编辑草稿和临时界面状态的归属。 说明刷新、后退、后台重新获取和用户退出时，每类状态如何变化。 给出需要我作出的少量关键决定，以及你建议的默认行为。 最后提出一个最小验证任务，用来检验推荐方案最不确定的部分。 ``` ## 05 证据排错 prompt 填写复现过程与实际证据，没有取得的信息保留为未知。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-03-css) ```text 你正在修复慢读资料库的一个前端缺陷。 请按证据定位原因，完成最小范围修复，并证明修复有效。 项目条件 - 技术栈、启动方式和涉及文件填写在这里 - 页面或提交版本填写在这里 - 浏览器、视口、网络与缓存条件填写在这里 问题记录 - 可重复的操作步骤填写在这里 - 预期结果与实际结果分别填写 - 附相关代码、Console 第一条异常与调用栈 - 附脱敏后的请求参数、状态码和响应样本 - 若涉及异步，附请求编号及状态更新时间线 - 写明哪些材料尚未取得，不要补造日志 工作要求 1. 先复现，区分观察事实与假设。给每个主要假设安排一个验证动作。 2. 根据证据定位到请求、数据解析、状态或DOM样式中的具体位置。 3. 证据足够后直接做最小修复，保留既有界面与接口契约。 4. 若涉及竞态，检查成功、失败和加载状态的过期提交。 5. 不得用隐藏内容、吞异常、类型忽略或关闭安全检查掩盖故障。 6. 不为单个缺陷改框架、引入全局状态库或新增无关依赖。 7. 跑原始复现，并验证相邻的失败场景。没有执行的验证明确标注。 请交付 - 根因与对应证据 - 修改文件、具体行为变化和必要的取舍 - 已执行的验证、实际结果、仍未验证的项目 - 回归风险及撤销本次修改的方法 ``` ## 06 性能优化 prompt 固定条件、保留原始测量，同时验证功能与性能取舍。 [阅读对应课程](https://tsonglew.github.io/blog/backend-to-platform-04-performance) ```text 你负责慢读资料库的一次性能改进。请保留现有功能，找出证据支持的瓶颈， 实施最小有效修改，并用同条件的前后测量证明结果。 场景与材料 - 用户操作流程填写在这里 - 当前提交、生产构建命令和目标设备填写在这里 - 数据规模、网络与CPU限速、缓存条件填写在这里 - 附Lighthouse报告、Performance trace或真实用户监测摘要 - 写明指标来自lab还是field，缺少的数据写未取得 - 附项目预算及其测量口径，没有预算则先提一份有理由的建议 执行方法 1. 先复测基线，按影响与证据强弱排序候选原因。 2. LCP问题拆开四个阶段，交互问题定位到具体任务、渲染或布局。 3. 说明拟改哪一处、预期改变什么指标，以及可能转移到哪里的新成本。 4. 优先完成一项可归因的修改，再按同一过程复测。 5. 优化前后各跑至少五次，保留原始值并比较中位数。 6. 复查搜索正确性、结果一致性、错误恢复、键盘操作与窄屏。 限制 - 不得删功能、少算数据或隐藏内容来换更好数字 - 不得把TBT、普通函数耗时或实验心跳当成INP - 没有真实用户数据就不能声称线上p75达标 - 不批量添加memo、预加载或缓存，不随意改框架和引入依赖 - 没有测量依据的建议标为假设，不编造提升百分比 交付内容 - 瓶颈证据、修改说明与影响范围 - 完整环境、原始记录、中位数和报告文件 - 性能收益与代价，以及正确性检查结果 - 未解决的问题、未执行的测试与回滚方法 ```