# 信息架构与体验决策

本文记录站点界面调整的理由和验证标准。后续改动应优先解决明确的用户问题，而不是单纯增加功能。

## D-001：首页采用个人刊物结构

- 用户问题：纯时间流缺少主张，但任务目录又会让个人站看起来像资源站。
- 决策：首页只保留站点主张、文章列表和订阅入口。
- 理由：个人技术站应由文章建立价值，避免把少量内容包装成产品化资源目录。
- 验证：访问者能理解本站讨论什么，并直接进入文章。

## D-002：导航保持最小

- 用户问题：内容数量较少时，主题、指南、分类和归档会制造重复入口。
- 决策：主导航只保留首页、文章和关于，搜索与 RSS 使用图标入口。
- 理由：减少选择成本，让内容本身成为主要导航。
- 验证：两次操作内可以到达任意文章。

## D-003：文章页强化上下文和下一步

- 用户问题：从搜索直接进入文章的读者不知道内容是否仍然有效，也缺少继续阅读入口。
- 决策：显示文章类型、更新时间、更新说明、标签、相关文章、订阅和反馈。
- 理由：这些信息分别回答“这是什么”“是否新鲜”“接下来读什么”“如何持续获得更新”。
- 验证：文章正文前能判断范围和时效，正文后有明确但不过量的后续动作。

## D-004：订阅入口同时提供 RSS 与邮件

- 用户问题：技术用户和普通读者的订阅习惯不同。
- 决策：RSS 直接链接现有 Feed；邮件订阅在未接入第三方平台前使用预填邮件申请。
- 理由：RSS 零依赖且适合技术读者；预填邮件在纯静态站点上可以立即工作，并保留迁移到 Buttondown、Loops 等服务的配置入口。
- 限制：人工处理邮件订阅，不进行自动群发。
- 验证：入口不依赖 JavaScript也能完成订阅意图。

## D-005：“是否有帮助”采用低基础设施反馈

- 用户问题：读者缺少一个低成本方式说明内容是否解决了问题。
- 决策：文章末尾提供“有帮助”和“需要改进”两个反馈入口，生成包含文章地址和反馈类型的预填邮件。
- 理由：当前内容规模不足以支撑独立反馈后端；邮件方案不收集隐式行为数据，也不会引入第三方追踪。
- 后续：反馈量稳定后，再接入可配置 API，并保持界面和数据字段兼容。
- 验证：两次点击内可以提交带文章上下文的反馈。

## D-006：分享功能优先复制摘要和链接

- 用户问题：平台专用分享按钮覆盖有限，而且容易增加无效入口。
- 决策：提供复制“标题 + 摘要 + 链接”的通用操作，并保留原生系统分享能力。
- 理由：复制内容适用于聊天、邮件、笔记和任意社交平台；Web Share API 在支持的平台提供更短路径。
- 验证：桌面端和移动端至少有一种可用分享方式。

## D-007：侧栏按页面目的显示

- 用户问题：所有页面固定使用归档侧栏，压缩专题页和搜索页空间，移动端则完全消失。
- 决策：布局支持 `sidebar: false`，专题页和搜索页使用完整内容宽度；文章与列表页保留发现入口。
- 理由：侧栏是辅助导航，不应成为所有页面的结构约束。
- 验证：关闭侧栏的页面不保留空列，文章页仍可发现搜索和归档。

## D-008：使用项目锁定环境部署 Pages

- 用户问题：GitHub Pages 默认 Jekyll 版本与本地项目版本不同，导致生成的 HTML 与 CSS 不完全一致。
- 决策：由 GitHub Actions 使用 `.ruby-version` 和 `Gemfile.lock` 构建 `_site`，再通过 Pages Artifact 部署。
- 理由：本地预览、CI 验证和线上发布共享同一依赖契约，减少环境差异和缓存排查成本。
- 权限：构建任务只读仓库；部署任务仅获得 `pages: write` 和 `id-token: write`。
- 验证：线上页面的生成器版本和本地构建版本一致，CSS 校验值一致。

## D-009：不把文章包装成资源目录

- 用户问题：“任务入口 + 可直接使用”形成两层资源导航，与个人技术刊物定位不符。
- 决策：删除任务卡片和指南清单，统一为文章列表。
- 理由：同一篇文章不应被多次包装；摘要直接说明其价值即可。
- 验证：首页每篇文章只出现一次。