Communitygithub.com

内容网站设计

设计、构建、撰写和审查人们愿意阅读的网站——文档、开发者文档和 API 参考、帮助中心与知识库、博客、编辑与新闻文章、指南、更新日志以及个人或公司文章——让读者快速找到答案,让代理能够阅读、引用和浏览。

内容网站设计 是什么?

该技能专注于内容网站的结构化设计,确保读者能快速定位、确认并获取所需信息,同时优化 AI 代理(如编码代理、搜索和回答引擎)的访问体验。它基于一系列经验法则和标准,例如“答案优先”、“一页一职”、独特且前置的标题、语义化的 HTML 结构,以及稳定的 URL 和锚点。技能涵盖了页面内容结构、导航、搜索、阅读舒适度,并特别强调了为代理读者提供的支持,包括服务器端渲染、干净的 Markdown 副本(如 `.md` 文件)以及 `llms.txt` 文件。其构建流程从分析用户首要任务和内容清单开始,逐步构建信息架构、页面模板,最终进行严格的验证测试,包括渲染审核、任务测试和代理可读性检查。适用平台包括所有支持基于 SKILL.md 的 AI 代理(如 Claude Code、Cursor、Codex)的网站建设场景。

兼容平台✓Claude Code~Codex CLI~Cursor
npx skills add https://github.com/thecatthatflies/interface/tree/HEAD/skills/content-site-design

在你喜欢的 AI 中提问

打开一个已预加载此 Agent Skill 的新对话。

文档

内容网站设计 是做什么的?

内容网站的存在,是为了让读者能找到页面,确认这是正确的页面,获得他们想要的答案或理解,然后继续做下一件事。大多数读者通过搜索直接进入一个深层页面,在阅读之前会先扫描,一旦得到所需信息便会离开。模型最常见的错误是设计外壳(英雄区域、卡片、侧边栏、深色模式切换),却忽略了内容本身的结构:模糊的标题、毫无意义的标题(“概述”、“简介”)、答案隐藏在第三段之后、混合了教程、参考和观点的页面、像“这里”这样的链接文本、没有日期、以及返回毫无用处的站内搜索。

应用 interface-guidelines 的优先级原则(每个人都能用 > 它传达真相 > 它表意明确 > 答案优先 > 错误可挽回 > 位置稳定 > 可见即可能 > 遵循惯例 > 精致美观)。如果已安装该技能,请先阅读其 SKILL.md。正文大小、行长、对比度和重排在该技能中已有涵盖(references/human-interface.md 第 6、7 节);本技能涵盖内容结构、导航、搜索以及针对代理读者的优化。

简要

  • 网站类型: 文档、帮助中心、知识库、编辑或博客,或混合型。混合型网站需为每个部分指定主要任务。
  • 读者及其到达方式: 从搜索引擎直接进入深层页面、从产品内部(“?”链接)、浏览、或订阅。谁是新手,谁是专家?
  • 首要任务: 读者带来的 10 到 20 个问题,用他们自己的语言表达。从搜索日志、支持工单和论坛帖子中获取,而不是从组织架构图中提取。
  • 内容类型: 对于文档,区分教程、操作指南、参考、解释;对于编辑类,区分新闻、分析、观点、指南。
  • 新鲜度: 内容变更频率、每页的负责人、产品版本变更时如何处理。
  • 代理读者: 阅读文档的编码代理、引用页面的搜索和回答引擎、导航的浏览器代理。它们必须准确做到什么?
  • 谁写作: 仅限员工,还是也包括用户(评论、社区回答)?外部内容需明确标记。

规则

标签: [E] 经验性, [S] 标准或机构性, [P] 实践者, [J] 判断。来源在参考文件中。

页面

  • 答案优先。 前两段承载主要观点;细节按重要性递减排列(倒金字塔结构)[S: GOV.UK; P: NN/g]。读者只阅读页面的一小部分文字,尼尔森估计约为 20% 到 28% [P: Nielsen 2008, 数据来自 Weinreich et al. 2008]。
  • 一页一职。 教程用于教学,操作指南用于指导,参考用于描述,解释用于讨论;不要在同一页面上混合它们 [P: Procida, Diátaxis]。
  • 标题是唯一、具体且前置的, 使用读者的语言,长度约 65 个字符或更少,以免在搜索结果中被截断 [S: GOV.UK]。任务页面以动词开头(“轮换一个 API 密钥”);关于任务的指南使用动词 -ing 形式(“轮换 API 密钥”)[S: GOV.UK]。
  • 标题下方有一句摘要, 长度为一个句子或 160 个字符以内,补充标题所缺的关键词;这段文字同时用作 meta 描述 [S: GOV.UK]。
  • 标题应准确说明该部分的内容, 前置重要信息,避免使用“概述”或“更多信息”,不要写成问句;即使移除标题,内容也应保持可理解性 [S: GOV.UK]。标题层级遵循结构:一个 h1,不跳级 [S: WCAG 1.3.1, 2.4.6]。
  • 短句、短段落、朴实语言。 将句子长度控制在约 25 个词以内,段落保持在五个句子或更少,首次出现专业术语时予以解释 [S: GOV.UK]。用“您”称呼读者,使用主动语态,将条件说明放在指令之前(“要删除一个项目,请打开设置”)[S: Google 开发者文档风格指南]。
  • 步骤用编号列表,集合用项目符号列表,对比用表格 [S: Google 开发者文档风格指南; GOV.UK]。
  • 为扫读而设计: 有意义的标题和前置的段落可以抵消 F 型扫读模式,即读者会跳过页面的右侧和底部区域 [P: Pernice, NN/g 2017]。
  • 有意义的日期: 实质性变更处标注“上次更新 2026 年 11 月 4 日”并附简短变更说明,文章则标注发布日期。仍然准确但内容较老的页面标注“已审阅” [S: GOV.UK 变更说明; J]。
  • 脚注: GOV.UK 禁止在服务内容中使用脚注;学术和长篇编辑类内容可能需要。决策依据是读者是否需要验证来源 [S: GOV.UK; J]。

链接

  • 链接文本应命名目标, 在页面内前置且唯一;永远不要使用“点击此处”、“阅读更多”或“这里” [S: GOV.UK, WCAG 2.4.4]。
  • 当链接离开网站、打开文件或改变语言时,需说明: “定价表(PDF,240 KB)” [S: GOV.UK]。
  • 在需要的地方放置链接,而不是堆在页面底部的“进一步阅读”中; 任务页面末尾的下一步操作如果具体可行,则可以接受 [S: GOV.UK]。
  • 每个标题都有一个稳定的锚点(#rotate-a-key),并带有可见的复制链接控件。重命名标题时,需保持旧锚点仍可工作 [J]。
  • URL 应可读且永久有效。 当页面移动时,重定向旧 URL;永远不要让文档链接返回 404 [J]。

导航

  • 读者直接进入深层页面。 每个页面应显示其位置(面包屑或高亮的章节)以及邻近和后续内容 [S: WCAG 2.4.8; P: NN/g 面包屑]。
  • 导航标签使用读者的词语,并能预测其内容(信息线索)[E: Pirolli and Card 1999]。
  • 每个页面至少有两种访问方式: 导航加搜索,或站点地图 [S: WCAG 2.4.5]。
  • 长页面应包含页面内目录, 由 h2 和 h3 生成,并高亮当前章节 [J]。
  • 存档和搜索结果使用分页或“加载更多”,而不是无限滚动, 这样读者可以到达页脚、返回之前的位置以及分享位置 [P: NN/g 无限滚动]。
  • 文档: 一个按读者任务和 Diátaxis 类型组织的侧边栏,当版本有差异时显示可见的版本切换器,旧版本页面上应有链接指向当前版本的横幅 [P: Procida; J]。

搜索

  • 搜索是主要路径,而非附加功能。搜索框应在每个页面上可见,而不是在桌面端隐藏在一个图标后面 [P: NN/g; J]。
  • 结果应显示页面标题、所属章节或类型、包含匹配词的高亮片段以及日期。能够容忍真实查询中的错别字和同义词 [J]。
  • 无结果页面应提示拼写纠正、更宽泛的搜索词以及热门页面,并记录该查询 [J]。
  • 每月审查零结果和热门查询;每个查询都指向一个缺失的页面、一个缺失的同义词或一个糟糕的标题 [P: 常见文档实践; J]。

阅读舒适度

  • 正文字号、行长、行高、对比度和重排应遵循基础规范。在手机上,读者对简短、简单文本的理解程度与桌面端相同,但对于困难文本会变慢,因此困难内容在移动端需要额外的结构 [P: Moran, NN/g 2016]。
  • 没有覆盖文字的插屏广告或粘性元素;广告和新闻通讯提示永远不会中断答案的第一个屏幕 [S: WCAG 2.4.11 聚焦; J]。
  • 传达信息的图片必须包含传达该信息的替代文本;装饰性图片使用空替代文本 [S: WCAG 1.1.1]。图表附近应有文本解释 [J]。
  • 代码示例应为文本,而非图片,并带有复制控件和语言标签。用于语言变体的选项卡应将所有变体保留在 DOM 中 [J]。
  • 打印和阅读器模式应生成不含导航外壳的内容 [J]。

针对代理

  • 内容应在 HTML 中, 服务器端渲染,而非在页面加载后由客户端 JavaScript 组装,以便不执行脚本的爬虫和代理也能获取 [J]。
  • 语义结构即界面: 标题、列表、表格、带有语言类别的 code 和 pre、figure 和 figcaption [S: WCAG 1.3.1]。
  • 稳定的、可引用的 URL 和锚点, 每个页面有一个规范 URL,并且页面中包含日期 [J]。
  • 每个文档页面的干净 Markdown 副本 位于同一 URL 下,追加 .md,并使用 rel="alternate" type="text/markdown" 链接,这是为编码代理提供无外壳内容的一种低成本方式。llms.txt 位于站点或文档根目录是一种社区提议;对于一般网站,需求测量值较低,但它适合编码代理阅读的文档 [P: Howard, llms.txt; foundation agent-surfaces section 6]。
  • 页面文本、注释或不可见元素中不得包含给代理的隐藏指令。 它们与提示注入无法区分 [J; foundation oversight section 5]。
  • 用户生成内容(评论、社区回答、论坛帖子)应在标记和视觉上标明,并附带作者和日期,以便代理和用户评估其可靠性 [J]。

构建顺序

  1. 首要任务和内容清单: 列出每个已有或计划的页面,包括其类型、所有者、上次审阅时间以及所服务的任务。删除或合并不服务于任何任务的页面。
  2. 信息架构: 根据读者任务和内容类型划分章节;使用读者的词语进行标签;通过树形测试检验标签(人们在纯文本树形结构中完成五个任务)[P: NN/g 树形测试]。
  3. 每种内容类型的页面模板: 标题、摘要、日期、正文结构、下一步操作。对于文档:教程、操作指南、参考、解释模板(references/docs.md)。
  4. 首先编写或重写首要任务的页面,使用 references/writing.md;一个完整、优秀的页面胜过 20 个占位页。
  5. 语义化 HTML 外壳: 地标、跳转链接、面包屑、作为 nav 并带有 aria-current 的侧边栏、页面内目录、页脚。服务器端渲染。
  6. 搜索 使用来自日志或首要任务列表的真实查询;调优同义词。
  7. 代理层: 规范 URL、锚点、Markdown 副本、站点地图、可选的 llms.txt。
  8. 样式 适应长时间阅读;品牌负责外观(brand-identity)。
  9. 验证(如下)。

验证

  1. 渲染审核 在首页、长文章或参考页面、搜索结果页面和 404 页面上进行:

    node <interface-guidelines>/scripts/audit.mjs <dist-or-url> --out audit-output
    
  2. 首要任务测试: 对于每个首要任务,从搜索引擎查询或首页开始,到达答案。统计步骤数,并注意信息线索失效的地方。分别以人(使用键盘,手机宽度)和代理(仅使用无障碍快照)的方式执行一次。

  3. 内容静态检查 针对每个页面(references/writing.md 第 8 节有脚本大纲):一个 h1;无跳级标题层级;标题唯一且在 65 个字符以内;摘要存在且在 160 个字符以内;无通用标题或链接文本(“概述”、“点击此处”、“阅读更多”);标记超过 25 个词的句子;缺失替代文本的图片;存在上次更新日期。

  4. 链接: 爬取无效的内部链接和缺失的锚点;检查旧 URL 是否已重定向。

  5. 无 JavaScript 检查: 使用 curl 获取页面,确认主要内容及标题在 HTML 中。

  6. 搜索: 运行 20 个热门查询和 5 个拼写错误;正确的页面应位于前三个结果中。

  7. 代理阅读: 给代理一个文档页面的 URL 或其 .md 副本,并让其执行任务;检查它是否遵循了当前版本并引用了正确的章节锚点。

陷阱

  • 将文章摘要的卡片网格作为文档首页,缺乏任务入口点或搜索。
  • 标题命名为“引言”、“概述”、“详情”,或写成问句。
  • FAQ 页面收集不相关的问题,而不是在最相关的页面上进行解答。
  • 答案位于关于该主题为何重要的长篇序言之后。
  • 教程中途变为参考,或参考被掺入了观点。
  • 无日期的文章,以及每个页面的“上次更新”都设置为构建日期。
  • 仅由客户端 JavaScript 渲染的内容,隐藏面板不在 DOM 中的选项卡,截图形式的代码。
  • 存档和搜索结果使用无限滚动。
  • 隐藏在页面中的给 AI 爬虫的指令文本。
  • 重新设计文档站点样式时,标题、标题和搜索仍然存在问题。

参考

文件何时阅读
references/writing.md编写或编辑页面:标题、摘要、标题、句子、链接、日期、数字、编辑细节及静态检查大纲
references/docs.md文档和帮助中心:带模板的 Diátaxis 类型、API 参考页面、代码示例、版本、更新日志、面向编码代理的文档
references/navigation-search.md站点结构、标签、侧边栏、面包屑、内容列表、存档、搜索结果、404 页面

Individual skills in this repo

This repo contains 4 individual skills — each has its own dedicated page.

thecatthatflies/brand-identity

Create a complete brand identity as real, usable files - strategy and vibe, a verified color system (OKLCH ramps, light and dark themes, WCAG-checked roles), typography, a professional logo in SVG (from a clean wordmark or geometric mark to a complex, meaningful symbol), favicons, app and social assets, design tokens, and a brand guidelines page. Use whenever someone asks for a logo, brand, brand kit, identity, color palette, theme, font pairing, visual direction, "vibe", rebrand, favicon or app icon, or says things like "make it look like a real company", "I need branding for my bakery/app/startup", or "what colors should we use", even if they only ask for one piece. Not for laying out pages or screens; those skills (landing-page-design, web-app-design and siblings) consume the tokens this one produces.

thecatthatflies/form-design

Design, build, and review forms and multi-step flows that people finish without errors and agents can fill without guessing - sign-up and sign-in, checkout and payment details, address and contact forms, applications, onboarding questionnaires, wizards, settings forms, validation and error messages, passwords and passkeys. Use whenever someone builds or fixes a form ("add a sign-up form", "our checkout converts badly", "make these errors better", "why won't autofill work", "turn this into a wizard"), even if they only mention one field. Includes a rendered-page checker for labels, autocomplete, input types, paste, and error wiring. Not for the surrounding app shell, tables, or settings navigation (web-app-design), store layout and product pages (ecommerce-design), or native desktop dialogs (desktop-app-design).

thecatthatflies/landing-page-design

Design and build marketing pages that people remember and understand, and that agents can read accurately - product and launch pages, homepages for a product or studio, pricing pages, waitlists, feature pages, one-pagers, event and campaign pages. Covers art direction (a concept drawn from the subject, one memorable idea, composition), message and page structure, honest proof, pricing, sign-up and waitlist flows, and speed. Use whenever someone asks for a landing page, "a site for my app", "a page to announce X", "make our homepage less generic", "a pricing page", "a coming-soon page", or wants an existing marketing page redesigned or critiqued, even if they only say "make it look good". Consumes brand tokens from `brand-identity` and does not invent logos, palettes or type systems; run that skill first when no brand exists. Not for product UI behind a login (`web-app-design`), docs or blogs (`content-site-design`), storefronts and checkout (`ecommerce-design`), or HTML email (`email-design`).

thecatthatflies/web-app-design

Design, build, and review SaaS and internal web application UI that people use for work and agents can operate - app shells and navigation, list and detail views, data tables with sorting, filtering, bulk actions and pagination, empty states, settings, onboarding, roles and permissions, workspace or tenant switching, optimistic updates and undo, command palettes, and URL-driven view state. Use whenever building or reviewing an admin panel, CRM, back office, internal tool, project tracker, or any logged-in product ("build me an admin for orders", "our app feels clunky", "add bulk delete", "make the table filterable", "add an org switcher"), even when the request names only one screen. Not for KPI and monitoring pages (dashboard-design), forms and wizards in depth (form-design), marketing pages (landing-page-design), native desktop shells (desktop-app-design), or AI chat surfaces (ai-chat-design).

相关技能