网页：内容站

内容消费：内容站、媒体展示站、个人主页

---

思路/经验

前端

1. 侧边目录栏要注意做sticky，不然页面向下滚动后，会不被带着走
2. 本地服务的路由端口最好固定下来

测试

1. 用学会使用URL参数调试：如/todo-board/?previewDate=2026-08-05

---

案例一：财报 → 网页（Claude Code）

1. 核心思路

参考这个 小红书帖子}}

2. 提示词

请读取 source/ 目录中的 NVIDIA FY2026 10-K 年报 PDF 和官方财务 Excel，独立完成一款可交互的 NVIDIA 财报研究产品。最终产品应让非财务专业用户快速理解：
- NVIDIA 的核心财务表现和三年变化；
- 各业务板块的收入结构与增长贡献；
- 年报中披露的主要经营亮点；
- 年报中披露的主要风险与不确定性；
- 关键数字来自年报或 Excel 的具体位置；
- 哪些结论是原始披露，哪些是基于数据的分析判断。

请自主完成资料理解、需求判断、PRD、数据结构设计、前端开发、数据可视化、来源溯源、自动化测试和问题修复，直到交付一个可以本地运行、主要功能可用、视觉完成度较高的产品。

必须满足的验收条件：
1. 提取收入、净利润、毛利率、研发投入、现金流等核心指标，并展示三年趋势。
2. 展示主要业务或市场的收入结构和变化，例如 Data Center、Gaming、Professional Visualization、Automotive。
3. 分开呈现经营亮点、风险因素和待观察指标，不直接输出买入或卖出建议。
4. 关键财务数字必须提供来源定位，至少包含 PDF 页码或 Excel 工作表；能定位到表格或单元格时应保留更精确的位置。
5. 对 PDF 与 Excel 中的核心数字进行交叉核对，生成核对结果；出现无法确认或不一致时必须明确标记，不得自行补造。
6. 正确处理财年、单位、币种、同比和百分比，避免将 NVIDIA FY2026 误写成自然年 2026。
7. 为主要页面和核心交互编写并执行自动化测试，优先使用 Playwright；发现问题后自行修复并复测。
8. 在 notes/ 中留下 PRD、数据字典和数据核对说明，在 output/ 中保存测试报告或必要的交付产物。
9. 不修改 source/ 中的原始文件。
10. 页面显著位置注明"仅用于财务信息研究和模型能力测试，不构成投资建议"。

请连续执行，不要停留在建议、方案或代码片段阶段。除非遇到权限、付费、敏感凭据或不可逆操作，否则不需要向我确认。

3. 注意事项

1. 交付物和验收条件要一次性写死

   10 条验收条件覆盖了数据提取、来源溯源、交叉核对、自动化测试、产物归档、免责声明。每一条都可量化、可勾选，Agent 完成一轮后能自检。如果验收条件模糊（如”做得好一点”），Agent 会在跑偏后难以自纠。

2. 边界约束比"做什么"更重要

   “不修改 source/ 中的原始文件”防止 Agent 破坏原始资料；“分清披露与分析”防止把推断包装成事实；“不输出买入或卖出建议”锁死合规边界。这些”不能做的事”比”要做的事”更能防止 Agent 在开放任务中过度发挥。

3. "连续执行"是兜底指令

   最后一句”请连续执行，不要停留在建议、方案或代码片段阶段”是关键。没有这句话，很多 Agent 会输出一份漂亮的方案然后停下来问你”这样行不行”。加上之后它才会真正开始干活。

4. 使用建议

• 可迁移骨架：任何”给一份原始资料 → 造一个可交互研究产品”的需求都能复用。换掉数据源、换掉验收条件中具体的指标名称，其余结构不动：

请读取 source/ 中的【原始资料】，独立完成一款可交互的【产品描述】。

核心要求：……
必须满足的验收条件：
1. ……（量化、可勾选）
2. ……
……
N. 不修改 source/ 中的原始文件。
N+1. 页面显著位置注明"仅用于【用途说明】，不构成【风险提示】"。

请连续执行，不要停留在建议、方案或代码片段阶段。除非遇到权限、付费、敏感凭据或不可逆操作，否则不需要向我确认。

• 验收条件设计原则：每一条应该是”跑完就能自检”的——例如”展示三年趋势”比”展示得很好”明确一百倍。不确定怎么写的，就想”如果我跑完这个 prompt，第一眼看什么来判断它做没做完”。

案例二：优化个人站点页面UI（ChatGPT）

1.提示词

给codex、codebuddy、opencode输入这个，让它输出下面这样的提示词

我觉得现在美食地图的 UI 整体还是有点差。我现在的想法是，说明当前已有的元素，让 GPT 根据这些元素生成几版不同风格的 UI 稿，去优化一下整体页面。

所以，你帮我想一条给 ChatGPT 的提示词。注意以下要求：
1. 只需要说明有哪些元素，以及它们的关联逻辑即可。
2. 不用涉及到代码层面。

给chatgpt使用的提示词案例

你是一位资深 Web UI/UX 设计师。这是一个「美食地图」个人网站页面的现有结构与交互说明，请你根据这些已有元素和逻辑，用image2 模型重新设计 3 版风格差异明显的 UI 稿。你不需要写代码，只需给出每版的设计方案说明。

以下是该页面目前的元素构成与联动逻辑：

一、整体布局（两栏结构）

顶部是一块横幅式 Hero 区域：左侧有标题 + 一行引导语，右侧有一个"累计记录店数"的统计数字。
Hero 下方分为左、右两栏：左侧是筛选导航栏，右侧是内容展示区。
二、左侧筛选导航栏（从上到下）

一个"搜索框"：输入关键词可在当前区域范围内即时过滤店铺（匹配店名、菜品名、评价内容）。
一个"区域列表"：每一行是一个区域按钮（如"校内 / 校外"），显示该区域下有多少个地点、共多少家店。点击可切换右侧展示对应区域的内容；当前选中的区域有高亮态。
三、右侧内容展示区（与左侧联动的三层结构）

第一层"地点标签栏"：显示当前区域内所有地点（如"兴隆夜市 / 隆江城"）的横向标签，每个标签显示该地点下有几家店。点击切换当前地点。
第二层"店铺卡片列表"：展示当前地点下的所有店。每张卡片包含：店名、分类标签（如"烤肉"，可选）、状态徽章（由店的整体评价自动推导，有 4 种：已吃过/推荐/想去试试/不再推荐）、简介菜品、整体评价、记录日期、地址（可选）。整张卡片可点击。
第三层"悬浮详情窗"：点击某张卡片后弹出。顶部展示该店的：状态徽章、店名、分类、地点、日期、地址、整体评价；主体按条目列出每道菜的：菜名、单菜评价、单菜价格（价格可选）。点遮罩/关闭按钮/按 Esc 均可关闭。
四、已有的视觉基调

页面整体是偏暖色、米黄 + 深棕的温馨风格。
状态徽章有固定语义色：已吃过=灰、推荐=绿、想去试试=琥珀、不再推荐=红。
交互习惯：卡片可点击会弹详情，搜索即时过滤，区域/地点逐层联动。
请在三张图中输出 3 版风格不同的方案，每版都请说明：整体布局思路、配色方案（给出具体色值倾向）、字体/排版、每个元素的具体视觉形态（按钮、卡片、徽章、悬浮窗各自的样子）、以及交互细节如何强化。最后可以给出一版你个人最推荐的方向并说明理由。

案例三：英雄联盟板块重构（熊窝 personal，2026-08-01，DeepSeek V4 Flash）

1. 核心思路

2026-08-01，把一个手工维护的静态前端板块升级为外部数据驱动的完整功能，单次会话完成。本次目标是把熊窝 personal 站点 的英雄联盟板块从”手工攻略”重构为”RESG 实战数据驱动的全 173 英雄速查”。

本案例成本：仅 43 条请求、230 积分（DeepSeek V4 Flash，平均每条约 5.3 积分），在一个会话内完成了数据打通、页面重构、交互、部署全流程。缓存命中率高是省成本的关键。

核心是数据驱动优先：前端板块的”内容”不做死在页面里，而是拆成静态数据文件 + 渲染逻辑，Agent 负责生成数据并写渲染，解耦且可重复更新。

本案例的完整会话记录在 CodeBuddy（可搜索跳转）：personal：英雄联盟板块重构-0.21.0（会话索引 7e52d63d963b49d4861b441e2f7b2253）。

2. 提示词

这次任务不是单一 prompt 一次跑完，而是多轮迭代。核心的启动指令长这样：

英雄联盟板块我要做成全部 173 个英雄的数据速查，数据从 RESG（海克斯大乱斗数据站，https://www.resg.top/）拉取。
- 打通 RESG 公开 API，抓取每英雄的海克斯/装备/胜率数据，存成静态数据文件；
- 画廊支持按官方定位筛选、外号/拼音搜索、胜率/热度排序；
- 点英雄弹出详情抽屉，展示 RESG 海克斯推荐（单/双/三/四 Top5 + 胜率 + 出装）；
- 数据要能通过脚本重新生成，方便版本更新后刷新。

之后靠多轮追问迭代（改布局、加搜索、调抽屉样式）而非一次性写死，靠”本地起服务 + 浏览器实际检查”来驱动修正。

3. 注意事项

1. 先验证外部数据源再动手

   RESG 是 React SPA，HTML 没有内容，直接抓不到数据。先确认它的 API（api.resg.top）CORS 是否开放、能否服务端直连，再设计页面。若依赖外部数据，数据不可达会让整个功能白做。

2. 静态数据要能脚本再生成

   把”拉数据/生成数据/外号映射”固化成脚本（fetch-lol-all.py、gen-nicknames.py），而不是手写死数据。这样游戏版本更新时跑一遍脚本就能刷新，维护不依赖记忆。更进阶的做法是封装成 skill，让任意 Agent 都能触发更新。

3. 留意平台差异（macOS 大小写）

   macOS 文件系统大小写不敏感，git add champions/[a-z]*.png 通配符会命中不了与旧大写文件同 inode 的小写文件，导致新头像没提交。处理大小写同名文件必须用显式路径，不能依赖通配符。

4. 子路径部署下别用 `../` 做返回链接

   GitHub Pages 子路径部署下，../（纯目录）解析可能 404，返回首页链接要写 ../index.html 这类明确指向文件的形式。

4. 使用建议

• 本地起服务验证，别只看代码：npm run dev + 浏览器实际检查，很多问题（布局、404、交互）光看代码发现不了。

• 缓存命中率高是省钱关键：单会话连续开发、复用已读文件和重复的构建/验证命令，能大幅压低积分。本案例一个完整功能板块（含数据打通 + 页面 + 交互 + 部署）只花 43 条请求、230 积分。成本量级随模型迭代变化很快，一个月后（2026-08-31 记录）同类任务已被压到个位数积分，最新对照见配置记录：个人-决策时间线的「模型成本观察」。

• 可迁移骨架：任何”静态前端板块 + 外部数据源”的需求都能套：

我要做一个【板块】，数据从【外部数据源】拉取。
- 打通数据源，抓取数据存成静态文件；
- 提供【筛选/搜索/排序】交互；
- 支持【详情展示】；
- 数据要能脚本再生成，方便后续刷新。

案例四：Codex 三步法从零做网页（B站大白，2026-08-06）

1. 核心思路

参考这个 B站视频：Codex 绝对实操·网页制作全流程，UP 主”大白”用 Codex 大约 3 小时做出一个 UI 界面，靠它在黑客松拿了冠军和 1 万元奖金。他把整个过程拆成三步，专门教小白怎么从零开始做网页。

核心观念转变：把 Codex 当执行团队，自己做导演一轮轮指挥修改。不要一上来追求完美，先搭骨架 → 填素材 → 调细节。三步分别是：

1. 完善架构：别急着让 AI 写网页或直接给参考，先让 AI 反问项目问题，把脑内模糊想法聊成清晰闭环——AI 提关键问题，人一个个回答，不会的跳过，AI 自己补全逻辑。
2. 逻辑匹配：给视觉参考但明确”不是照抄”，让 AI 分析参考里的视觉语言（高级感、留白、卡片、动效）并和项目定位做匹配，先出一版结构化网页骨架，图片位置先预留并说明该放什么图。
3. 图片批量处理：所有图片丢进一个文件夹，让 Codex 自己识别、分类、匹配，不确定就问人；放错的单张调整，而不是自己处理五六十张图。

案例中的项目例子是”爬宠 + 3D 打印 + 真实交付的黑客松展示网站”。

2. 提示词

以下是视频中逐字引用的 4 段提示词。第 1 段里的项目描述是示例，可替换为自己的项目方向。

（第一步·完善架构）

我的方向是爬宠、3D 打印和真实的交付，我想做一个可以展示的网站，请你向我提出问题，并和我一起完善这个项目的逻辑

（第二步·视觉逻辑匹配）

这是我给你的视觉参考，请你分析参考里的视觉语言和逻辑，然后结合我的项目定位，重新设计一个符合我项目定位的网页结构，请把视觉参考和我的项目逻辑做匹配，不是简单的套模板

（第二步·结构化骨架）

请你根据刚才的项目定位和参考视觉，先给我做出来一版结构化的网页版本，注意所有需要图片的地方，请先为我预留，并且告诉我，这里需要放什么图片

（第三步·图片批量处理）

我所有的图片都在这里，你自己去识别分类并且匹配，如果你不确定哪张图应该放在哪里，你可以先问我

3. 注意事项

1. 先聊逻辑再写代码

   第一步的反问环节是整个流程最值钱的。小白最常见的问题不是”不会写代码”，而是”不知道自己到底想做什么”。让 AI 先反问、自己一个个回答，能把脑内模糊的想法逼成闭环。不会答的跳过让 AI 自己补全，比直接让 AI 猜你要什么靠谱得多。

2. 参考 ≠ 照抄

   给视觉参考时，明确让 AI”分析视觉语言并匹配项目逻辑”，而不是”照这个做”。否则 AI 会直接套模板，出来的东西和参考几乎一模一样，失去项目自己的定位。关键措辞是”不是简单的套模板”——这句话把 AI 从”复制”拉回”理解再创造”。

3. 图片批量丢给 AI 处理

   不要自己命名、裁切、归类几十张图。把所有图片丢进一个文件夹让 AI 识别、分类、匹配，放错的单张微调即可。人最不该做的就是重复性的文件整理工作，这是 AI 最擅长的。

4. 分阶段推进，别追求一次到位

   三步流程的本质是”先骨架 → 填素材 → 调细节”。一上来就追求完美，容易卡在第一步动不了。先把结构搭出来，再逐步填充，每一轮都有可见的进展，心态和效率都会好很多。

4. 使用建议

• 可迁移骨架：任何”从零做一个展示网页”的需求都能套这个三步流程：

第一步（完善架构）：
我的方向是【项目方向】，我想做一个【目标产物】，请你向我提出问题，并和我一起完善这个项目的逻辑。

第二步（视觉匹配 + 骨架）：
这是我给你的视觉参考，请你分析参考里的视觉语言和逻辑，然后结合我的项目定位，重新设计一个符合我项目定位的网页结构，请把视觉参考和我的项目逻辑做匹配，不是简单的套模板。
请你根据刚才的项目定位和参考视觉，先给我做出来一版结构化的网页版本，注意所有需要图片的地方，请先为我预留，并且告诉我，这里需要放什么图片。

第三步（素材批量处理）：
我所有的图片都在这里，你自己去识别分类并且匹配，如果你不确定哪张图应该放在哪里，你可以先问我。

• 你负责指挥，AI 是执行团队：不要把自己当成写代码的人，把自己当成导演。一轮轮指挥修改，比一次性写出完美 prompt 更有效。
• 模糊想法 → 敢于推进的项目是最难的一步：很多人卡在”我还没想清楚”。第一步的反问环节就是用来解决这个的——不需要想清楚才开始，而是通过和 AI 对话逐渐想清楚。

---

一、先区分 Dashboard 和 Kanban

这里的「看板」主要指 Dashboard（人生驾驶舱）：把生活中多个维度集中到一个页面，帮助自己观察状态、安排重点和做出取舍。

它和 Kanban（任务看板） 不一样。Kanban 重点管理任务的流转；Dashboard 则更像总览，任务只是其中的一个组成部分。

二、什么是 Life OS

Life OS（生命操作系统） 是 Notion 等工具中常见的一类个人管理框架：借用「操作系统」的比喻，把原本分散在不同 App、表格或笔记中的生活模块整合进一个工作区，并通过首页仪表盘汇总它们的状态。

典型模块包括：

• 🏠 首页仪表盘：汇总今日重点、快捷入口和各模块状态；
• ✅ 任务与日程：日、周、月计划；
• 🔄 习惯与日常 routine：追踪重复的日常行动；
• 📓 日记与情绪：记录感受、回顾状态；
• 🎯 目标与生活维度：把长期方向拆到可观察的领域；
• 💰 财务、工作与职业：以及膳食等按个人需要加入的领域。

它和普通的习惯打卡模板的差别在于范围：打卡模板只解决「是否完成一项习惯」，Life OS 尝试把打卡、日程、目标、回顾和其他生活信息放进同一套系统，让它们能被统一查看和关联。Dashboard 往往就是这套系统的入口和总览页。

三、什么是 Link Hub

Link Hub（链接中心） 常见于个人主页、Link in Bio 或 Notion 模板中：把分散在各处的外部入口收进一个页面，例如社交账号、作品集、课程、预约日历、播客和订阅链接。它的核心作用类似 Linktree——让访客通过一个链接找到全部公开入口；Notion 版还可以按需要加入数据库或日历。

「Hub」也可以泛指某一类内容的统一入口。比如 Knowledge Hub（知识中心） 用来汇总学习资料、笔记、参考资料、待读文章和常用工具，Team Hub（团队中心） 用来承载协作资源。这种用法更接近主题目录或仪表盘，不一定是外部链接列表。

因此，Life OS 偏向个人的自我管理，Link Hub 偏向对外展示、分享或导航；两者都可能使用 Dashboard 作为首页形式，但解决的问题不同。

四、搭建思路

1. 先定维度：不要一开始就堆功能。可以从两种常见框架中选择：
   • 「生命之花」：健康、成长、财务、人际、工作、娱乐、环境、贡献等生活维度；
   • 「PARA 方法」：项目、领域、资源、归档，用于组织持续积累的信息。
2. 再选路线：根据自己是否愿意配置工具或维护代码，选择现成模板、低代码工具或自建页面。
3. 采用三段式结构：顶部放今日概览（目标、快捷入口）；中部放核心追踪（任务、习惯、目标、财务）；底部放回顾与资源（周复盘、知识库、心情）。
4. 让它真正被使用：固定一个查看时间，例如早咖啡或睡前的两到五分钟；只保留会改变行动的模块，并让手机也能方便打开。

五、可参考的案例

六、路线怎么选

• 不想碰代码、希望随处打开：使用 Notion、飞书或钉钉多维表，从模板开始调整。
• 有 homelab 或服务器，想做浏览器新标签页中枢：考虑 Homepage 或 Homarr。
• 希望完全掌控，也愿意练手：从一个本地 HTML 页面开始，逐步加入任务、习惯、目标和统计模块。

七、Notion 仪表盘可复用的小组件来源

如果走 Notion 路线，仪表盘里的时钟、天气、习惯追踪、倒计时、名言引用等「小组件」并不需要从零做——以下站点都提供可嵌入 Notion（或任何支持 iframe 的页面）的现成组件，改改参数和样式直接用。

选用思路：

• 极简工具类（时钟、天气、计时器、倒计时、名言）：Indify、Saif Saber 足够，风格也贴近 Notion 原生。
• 对外展示类（价格表、评论墙、社交 feed、表单、落地页装饰）：Common Ninja 更合适，组件多且偏商务。
• 不确定要什么、想按功能浏览：从 Apption 这类聚合站入手，组件下通常有社区评论和使用数据可参考。
• 想自己调参数生成：Widgets.so 的 Builder 形式最自由，适合有具体定制需求但不愿写代码的人。