# 开发日志

- Issue：#149
- 里程碑：M14 编辑体验与亮点表达重构
- 分支：`fys-dev/feat-m14-issue-147-149-hero-skills-followup`
- 日期：2026-04-06

## 背景

技能模块默认结构视图已经更清晰，但公开展示仍然只有单一读法。为了让招聘方从不同角度理解技能结构，需要在 web 端增加轻量的本地视图切换，而不把展示偏好写进后台配置。

## 本次目标

- 为技能区增加 `structure / tag-cloud / chart` 三视图切换。
- 所有视图都只使用现有 `skills.name + skills.keywords` 推导，不引入主观评分。

## 非目标

- 不在 admin 中配置技能展示样式。
- 不把视图状态写入数据库、URL 或发布数据。

## TDD / 测试设计

- 在 `published-resume-shell` 测试中覆盖三视图切换。
- 验证 `tag-cloud` 能展示标签且保留原始内容 tooltip。
- 验证 `chart` 只按真实条目数与相对占比渲染。

## 实际改动

- 在 `PublishedResumeSkillsSection` 中新增本地状态切换与三套渲染分支。
- `structure` 视图复用 issue 148 的行式解析结果。
- `tag-cloud` 视图优先使用解析出的 label，没有 label 时回退整行文本。
- `chart` 视图使用每个技能组条目数生成响应式横向分布图，显示组名、条目数和占比。

## Review 记录

- 这次只改 `apps/web`，没有引入新的 API、后台设置或共享契约变更，符合 issue 目标。
- 统计图只展示真实计数，避免把并不存在的“熟练度”伪装成数据事实。

## 自测结果

- `pnpm --filter @my-resume/web test` ✅
- `pnpm --filter @my-resume/web typecheck` ✅

## 遇到的问题

- `tag-cloud` 和 `chart` 都需要消费同一份技能解析结果，若各自独立计算会导致逻辑分散。
- 最终把解析与统计收口在同一组件内的辅助函数中，三种视图共享同一份派生数据。

## 可沉淀为教程/博客的点

- 前端局部状态如何为公开内容提供“多视角阅读”，同时不污染 CMS / 发布模型。
- 为什么真实可解释的技能统计，比主观熟练度雷达图更适合个人简历场景。

## 后续待办

- 继续做一轮 `admin 保存 -> publish -> web 展示` 的人工冒烟，确认 hero 与三视图在真实数据上表现稳定。
- 后续若要增加更多展示风格，优先继续放在 web 本地状态层而不是扩展后台配置。
