[I.2] 个人作业:软件案例分析

[I.2] 个人作业:软件案例分析

项目 内容
这个作业属于哪个课程 26春软件工程
这个作业的要求在哪里 [I.2] 个人作业:软件案例分析
我在这个课程的目标是 系统学习软件开发过程,评估当前已有的开源软件功能,了解软件评估指标,为后续项目开发做准备工作
这个作业在哪个具体方面帮助我实现目标 对开源软件功能、需求和用户体验进行初步调研和分析,从用户的角度评估软件性能,为后续自己作为开发者进行软件设计时提供参考和辅助

(一)选题简述

本次软件工程作业,我选择的分析对象为 AnZhiYu(hexo-theme-anzhiyu)

AnZhiYu 是一个运行在 Hexo 博客框架之上的开源主题(github 开源链接如下:https://github.com/anzhiyu-c/hexo-theme-anzhiyu),Hexo 官方主题列表将其描述为 “Simple & clean theme for Hexo, A designer-style theme”;该主题是基于 hexo-theme-butterfly 修改而来,它既不是单纯的配色皮肤,也不只是几个页面模板,而是一个集成了页面布局、主题配置、交互动画、评论系统、统计功能、PWA、AI 摘要、音乐球、右键菜单等功能的完整前端主题工程

作为计算机学院的学生,我们平时会接触到博客搭建、个人主页展示、课程笔记整理、项目记录等需求,对于大部分新手而言,有一个成熟、操作简单、容易上手且美观的的主题将使得我们的博客搭建事半功倍,评估一款博客主题是否优秀,可能会涉及安装体验、配置复杂度、可扩展性、稳定性和长期维护成本等多个软件工程问题,AnZhiYu 正好处在这样一个很适合分析的位置:它功能丰富、风格鲜明、文档较完整、社区真实存在,同时也暴露出配置复杂、边界场景 bug 较多、升级同步成本较高等问题,因此本次作业我选择以它作为分析目标

(二)调研与评测

2.1 项目简介

作为一个运行在 Hexo 之上的开源博客主题,其官方说明中已经给出了完备的配置流程:在博客根目录下通过 Git 克隆主题,将 _config.yml 中的主题名修改为 anzhiyu,并在缺少渲染器时安装 hexo-renderer-pughexo-renderer-stylus,此外,作者还专门强调了覆盖配置机制,即将主题配置复制到博客根目录下的 _config.anzhiyu.yml 中,以避免升级主题时丢失自定义配置

作为一个设计风格鲜明的博客主题,AnZhiYu 的功能特性非常丰富,目前作者已经实现的功能包括但不限于:页面组件懒加载、图片懒加载、多种代码高亮方案、多语言配置、多评论插件、网页访问统计、暗色模式、脚注语法、自定义 CDN、定制化右键菜单、主色调跟随封面图变化、沉浸式状态栏、图片大图查看、瀑布流即刻说说、瀑布流相册集、PWA、AI 摘要、音乐球、全局中控台和快捷键选项等,也就是说,相比于一些传统的博客主题,它越来越朝着一个智能化的前端方案方向发展,而不再是一个只负责显示文章列表的极简模板

作为一个博客主题,其界面如下:

image-20260317161900813

我们也可以对其进行美化和自定义,变成下面的样子:

image-20260317162201378

可以看出,其主体由首页头图、导航栏、文章卡片区、侧边栏、页脚、文章页目录、评论区以及多种交互组件组成。具体而言:

  • 导航栏负责站点级别的页面切换,如首页、分类、标签、相册页、关于页等
  • 文章卡片区负责展示博客内容本身,包括封面图、标题、摘要和元信息
  • 侧边栏承担公告、个人信息、最近文章、标签云等辅助展示作用,可以展示作者的联系方式
  • 文章页目录与评论区承担阅读导航与互动功能
  • 右键菜单、音乐球、暗色模式、沉浸式状态栏等组件则负责强化整体使用体验与个性化风格,比如可以设置作者喜欢的音乐,或者推荐几篇作者认为不错的文章进行快速跳转

2.2 使用说明

对于 AnZhiYu,其使用的核心流程非常简单,基础组件完全通过 Git Bash 即可完成配置,而扩展功能则可以通过修改本地主题的config文件进行配置:

  1. 安装 Hexo 博客框架
  2. 在主题目录中安装或克隆 hexo-theme-anzhiyu
  3. 修改 Hexo 根目录中的 _config.yml,将主题改为 anzhiyu
  4. 复制主题配置文件为 _config.anzhiyu.yml,在根目录中进行覆盖配置
  5. 通过 hexo s 本地预览,查看首页、文章页、分类页、相册页等实际效果
  6. 根据需要继续配置评论系统、统计服务、音乐组件、PWA、AI 摘要等个性化扩展功能

AnZhiYu 命令行操作界面如下:

image-20260317162426790

而在完成 AnZhiYu 主题配置后,博客的书写、配置与端侧部署也完全可以由简单的 Git Bash 命令行完成:

image-20260317155609384

整个过程在逻辑上是清晰的:Hexo 负责内容生成,AnZhiYu 负责前端展示与交互增强,对于希望搭建一个具有较强视觉表现力和个性化风格的博客站点的用户来说,它确实能够较好地解决需求,尤其是在 “个人主页 + 技术博客 + 生活展示” 这种混合场景下,AnZhiYu 的表现是很有竞争力的

该软件的优点如下:

  • 视觉风格鲜明,区别于许多偏极简的博客主题,更适合希望建立个人辨识度的用户,支持深度个性化开发
  • 功能覆盖范围广,从基础文章展示到评论、统计、PWA、AI 摘要、音乐球等都有支持,兼顾专业性和娱乐化
  • 官方文档较详细,README 中也给出了安装、覆盖配置和部分功能展示,开源体系较为完善,用户广泛形成社区
  • 可通过简单命令行进行部署和操作,对新手友好,操作简单,容易上手

同时,其强大的功能与高度可定制性也带来了如下缺点:

  • 升级成本相对较高,README 已明确提醒用户:每次更新主题时,可能需要手动同步 _config.anzhiyu.yml
  • AnZhiYu 主题对应的配置文件长达上千行,且部分高级配置配置繁琐(比如 LaTeX 公式的显示),缺乏对应的开源教程,如果想深度修改博客主题或完善功能,可能需要花一番功夫
  • 功能较多带来了更高的边界错误概率,公开 issue 中长期存在渲染、布局、搜索、移动端适配等问题
  • 相比成熟度更高的 Butterfly 和 Fluid,AnZhiYu 在社区规模和工程稳定性上仍有差距

2.3 改进意见

基于我在使用过程中的个人体验,在此提出如下仅代表个人的改进意见:

  • 增加一键切换新手模式,例如提供极简博客展示,让初学者不需要第一次就面对完整配置树,而是先保证能够使得博客正确部署与展示后,再逐步探索更多的配置
  • 增加配置体检与升级迁移助手,动扫描 _config.anzhiyu.yml 中失效、弃用或冲突的配置项,提示用户应如何同步升级
  • 增加对于配置文件的说明文档,或者简化配置文件的格式,目前的配置文件有大量字段缺乏说明,用户难以精确操作
  • 对 Markdown 语法边界场景、搜索组件、图片组件、移动端布局等高风险区域增加自动化回归测试
  • 在文档中进一步强化“常见错误排查”与“版本升级说明”,减少用户反复翻 issue 的成本

2.4 社区与受众调研

为对 AnZhiYu 在实际建站过程中的应用进行更加详细的了解,我选择在其社区 QQ 群(464636182)中随机抽取了几位积极用户与开发大佬进行讨论与调研

他在日常生活中有个人博客搭建与维护经验,并尝试过 Hexo 及不同主题的切换,覆盖了从“只会用现成模板”到“会进行一定程度自定义配置”的流程,因此对于分析用户为何选择某个主题,以及主题真正满足了什么需求,具有较强的参考价值

采访用户一:一位 AnZhiYu 鱼主题的初学者

image-20260317164024005

采访用户二:一位资深开发者

image-20260317164502959

采访结果显示,AnZhiYu 的长处主要体现在以下几点:第一,页面辨识度高,适合做个人主页和展示型博客;第二,功能多,很多展示效果不需要自己重复造轮子;第三,整体观感比极简主题更有氛围,与此同时,其问题也很集中:配置项过多,很多功能不是“装上就能用”,而是还需要继续查文档、配服务、调参数;对于没有前端经验的同学来说,上手门槛明显偏高。由此可知,AnZhiYu 的优势来自高度自由与设计表达,缺点也来自这种自由度带来的复杂性。

最终评分

经过以上分析,我给出的评价是:d) 好,不错

AnZhiYu 凭借其鲜明的设计风格、丰富的功能特性和较强的个性化表达能力,已经成为 Hexo 主题生态中非常有辨识度的一个开源项目,尽管它在配置复杂度、升级迁移和部分边界场景稳定性上还存在改进空间,但这并不妨碍它成为许多有建站需求、希望打造高颜值个人博客用户的一个优秀选择

(三)Bug 排查与分析

在使用过程中,为客观评估 Bug 的严重程度,我们采用课程给出的评价标准,从功能完成度、性能与效率和用户体验感三个维度综合考量,按照 “致命性,严重,一般,轻微,难以察觉” 的顺序,顺次分配五星至一星

3.1 博客文章页图片右键“复制图片 / 下载图片”提示成功,但实际并未生效

测试环境:

  • 操作系统:Windows
  • 浏览器:Google、Edge
  • 出现位置:文章页图片右键菜单
  • 现象描述:点击“复制图片”与“下载图片”后,页面会提示“复制成功”或“正在下载中”,但图片既没有被复制,也没有真正下载

该 bug 是我尝试从博客上下载或复制相关图片时发现的,可在特定页面与特定操作下复现,复现过程如下:

  1. 打开使用 AnZhiYu 主题的博客文章页
  2. 找到正文中的一张图片
  3. 在图片上点击右键
  4. 选择“复制图片”或“下载图片”
  5. 观察页面提示与实际结果

image-20260317164940347

观察到页面顶部会给出复制成功的提示,但图片实际上既没有被成功复制到剪贴板,也没有被浏览器正确下载,通过测试发现,该问题不仅出现在自己的站点中,在官方演示博客中也能观察到,因此可以排除单个站点配置问题的可能

从功能角度看,这属于典型的前端提示状态与真实执行结果不一致的缺陷,它并非核心文章渲染错误,但会明显误导用户:系统给出了成功反馈,用户却没有得到任何有效结果。这种问题在交互体验上尤其具有破坏性,因为它会直接损害用户对整套 UI 提示系统的信任,综合考虑,我将其严重性评价为 2 星

其可能成因如下:右键菜单在点击后先执行了提示逻辑,而真正的复制或下载动作要么没有正确绑定到浏览器 API,要么受到了跨域、权限、图片资源来源或剪贴板安全策略的限制,但前端却没有根据实际返回值区分成功提示失败提示,目前,该问题已通过个人站点添加到官方主题的 Q&A 留言板中:

image-20260317165510404

3.2 当博客标题中存在英文单引号 ' 时,会导致图片无法解析

测试环境:

  • 操作系统:Windows
  • 使用方式:Hexo + AnZhiYu 本地预览与生成页面
  • 触发条件:文章标题中包含英文单引号 '

该 bug 是我在实际写博客时发现的,当文章标题中包含英文单引号 ' 时(比如 Somebody' Blog),文章页面中的图片会出现无法正常解析或显示异常的现象(如下图所示);去掉标题中的单引号后,图片又能恢复正常显示

image-20260317160653816

该 bug 在我的环境中同样具备较强可复现性。复现步骤如下:

  1. 新建一篇文章
  2. 在 front-matter 的 title 字段中写入包含英文单引号的标题
  3. 在正文中插入图片
  4. 本地预览或生成静态页面
  5. 打开文章页面,观察图片显示异常
  6. 将标题中的英文单引号去掉,再次预览,图片恢复正常显示

这个问题比上一条更隐蔽,因为普通用户很难第一时间想到:为什么标题里的一个字符,会影响正文图片显示?从使用体验上看,这种 bug 最糟糕的地方在于它跨越了用户的直觉边界:标题和图片在概念上明明是两个模块,但最终却发生了相互影响,导致排错成本大幅上升,综合评价为 2 星(我曾花费大量时间查找这个 Bug)

通过查看对应文章的配置文件,我们发现对应的 configTitle 和 title 等字段如下所示:

</script><script id="config-diff">var GLOBAL_CONFIG_SITE = { 
        configTitle: 'Destiny's Blog', 
        title: 'Destiny\'s Blog', 
        postAI: '', 
        pageFillDescription: '', 
        isPost: false, 
        isHome: true, 
        isHighlightShrink: false, 
        isToc: false, 
        postUpdate: '2026-03-08 09:31:43', 
        postMainColor: '', 
    }

这里所有的字符串,开发者都默认使用英文单引号进行包裹,因此当一个字符串中出现单引号时,会导致这部分字符串被提前异常截断,从而导致后面的内容匹配错误,最终造成了这个问题,该 Bug 在本地即可修复,通过修改配置文件的设置(比如把单引号改成双引号,或者尽量不在标题中使用'),即可避免

3.3 当文章过长或节标题过多时,目录会从中截断,后续节标题无法正常显示

测试环境:

  • 操作系统:Windows
  • 使用方式:Hexo + AnZhiYu 本地预览与长文写作
  • 触发条件:文章较长、节标题较多、目录层级较深

该 Bug 是在撰写长篇文章时发现的,当文章比较长,或者标题数量较多时,右侧目录会出现从中间截断的现象,后续部分节标题无法继续显示,导致目录失去应有的导航作用

该 Bug 在长文场景下稳定出现。复现步骤如下:

  1. 新建一篇较长文章
  2. 在文章中连续设置大量二级、三级标题
  3. 本地预览页面
  4. 观察右侧目录区域
  5. 发现目录显示到中间某处后不再继续展示后续标题

image-20260317170416013

如图所示,子标题已经阅读到方差阈值法时,目录标题还停留在上一节的相关性分析,对于一些正在阅读其他博主博客的用户而言,如果目录在文章较长时发生截断,这会明显影响技术博客、教程、课程笔记和论文笔记类文章的阅读体验。

经过查阅相关资料,其可能成因如下:

  • 目录容器可能设置了固定高度或 max-height,但滚动行为没有正确适配
  • 当节标题数量较多时,目录生成逻辑正常,但 CSS 显示层发生裁切
  • 可能存在目录更新逻辑只计算了前半部分节点,后续节点没有完整挂载

考虑到该问题会在长文写作这一常见场景中明显影响导航体验,但不会影响文章正文本身显示,因此综合评价其严重性为 3 星,目前,比较好的解决方法即减少子目录的嵌套,在实际应用中发现,如果在文章中多次应用一到五级目录的嵌套,则很有可能触发目录显示截断,同时,该问题已通过个人站点添加到官方主题的 Q&A 留言板中,并且在官方社区的 QQ 群进行了反馈

(四)开发分析

4.1 工作量估算

作为一个功能较丰富、设计风格明确、并整合了多种前端交互与第三方服务的 Hexo 主题,若从零开始,由一个 6 人团队(计算机专业本科毕业生,并配备专业 UI 支持)开发出当前版本的核心功能,进行理想化分析时,其工程量测算可按功能模块进行分条分析:

  • 基础主题框架:首页、文章页、归档页、分类页、标签页、关于页等基础模板设计与渲染逻辑,约需 5 人月
  • 配置系统与覆盖配置机制:主题配置项定义、解析、优先级覆盖、升级兼容,约需 4 人月
  • 页面交互组件:暗色模式、右键菜单、沉浸式状态栏、图片灯箱、音乐球、全局中控台、快捷键等,约需 6 人月
  • 第三方服务整合:评论系统、统计系统、广告挂载、AI 摘要、PWA、CDN、自定义主色调等,约需 6 人月
  • 文档与预览站建设:README、功能说明、安装教程、配置文档、演示站维护,约需 3 人月
  • 样式与视觉设计打磨:卡片式设计、响应式布局、深浅色模式协调、细节动画,约需 4 人月
  • 测试与调试:Markdown 渲染测试、兼容性测试、移动端测试、视觉回归测试,约需 4~6 人月
  • 项目管理与维护:需求分析、版本规划、issue 处理、社区支持、文档更新,约占整体的 20% 左右

各模块之间并行开发,但部分模块之间存在强依赖关系,例如基础模板完成后方可大规模接入交互组件,配置系统成熟后才能降低后续维护成本,综合考虑后,我认为该主题若由 6 人团队从零实现到当前成熟度,大约需要 8~10 个月,总工作量约为 40~48 人月,如果再考虑持续迭代、社区答疑、版本兼容与文档维护,实际成本还会更高

4.2 软件质量分析

我们将 AnZhiYu 与其同类产品进行对比(如其他常见的博客优秀主题,这里我选择 Butterfly 和 Fluid),可以得出如下的优势和不足:

优势:

  • 视觉风格鲜明,在 Hexo 主题中辨识度很高,更适合个人展示与设计风格较强的博客
  • 功能丰富,覆盖从基础博客展示到评论、统计、PWA、AI 摘要、音乐球等多种扩展需求
  • 官方文档较完整,README 中给出了预览、文档和安装配置方法
  • 已被收录进 Hexo 官方主题列表,说明其具备一定代表性,也被业界所认可

劣势:

  • 相较于 Butterfly 和 Fluid,配置复杂度更高,对初学者不够友好
  • 当前公开 issue 中仍有较多与渲染、搜索、布局、移动端适配相关的问题,说明边界稳定性仍需加强
  • 官方所给出的README 文档中已明确提醒升级时可能需要同步修改 _config.anzhiyu.yml,维护成本高于普通极简主题
  • 社区规模和工程成熟度仍弱于 Butterfly 与 Fluid,当前 GitHub 页面显示,Butterfly 约 8.2k stars、1.4k forks,Fluid 约 8.1k stars、1.2k forks,而 AnZhiYu 约 2.4k stars、384 forks

从个人体验感而言,在同类产品中,AnZhiYu 的综合质量大致可以评为中文 Hexo 主题第一梯队,但未必进入前二,如果以工程成熟度、安装清晰度、社区规模为标准,Butterfly 和 Fluid 更占优势;如果以视觉个性、页面氛围和个人展示效果为标准,AnZhiYu 则非常突出,综合来看,我认为它在同类产品中大致可以排在 第 3 名左右

针对上述描述,在软件工程方面,可以尝试把配置演进管理与边界场景测试提升为更高优先级,尤其是配置升级迁移、Markdown 渲染快照测试、图片与搜索组件的回归测试等,应该被纳入更系统的质量保证流程中

(五)规划建议

5.1 市场现状调研

静态博客主题市场虽然不像移动应用市场那样面向大众用户,但它依然是开发者工具生态中的一个稳定细分市场,有一部分自己稳定的受众和群体,Hexo 官方将自己定位为一个 fast, simple and powerful blog framework,并强调其支持 GitHub Flavored Markdown、插件扩展和一键部署;npm 页面显示,Hexo 当前仍有约 41,295 次 weekly downloads,说明它对应的博客与建站生态依然活跃

目前,AnZhiYu 的主要竞争对手主要分为两大类:

  • Butterfly 为代表的成熟多功能 Hexo 主题,其特点是社区大、文档成熟、长期维护稳定,这类主题发展时间久,有庞大的受众和维护团队
  • Fluid 为代表的偏稳健、偏规范、Material Design 风格的 Hexo 主题,其特点是安装路径清晰,对新手更友好,这类博客的通过保守化功能,最大程度上降低了用户使用过程中的配置失误与出错风险

对于上述产品而言:

  • AnZhiYu 的定位是设计风格鲜明、适合打造个人数字空间的个性化博客主题,优势是氛围感强、展示效果突出,劣势是配置复杂、维护成本较高
  • Butterfly 的定位更偏成熟稳定的全能型主题,优势在于社区规模大、生态成熟、文档和支持都更强,有完善的说明与设计文档和大量的新手教程
  • Fluid 的定位更偏优雅、规范、适合技术博客和文档站的稳健型主题,优势是逻辑清晰、上手友好,同时由于其技术的保守性,降低了用户在个性化开发过程中的出错风险

目前来看,AnZhiYu 想在竞争中持续保持吸引力,不能只依赖页面更好看的优势,而应在配置体验、升级迁移、测试保障这些更偏工程质量的方向上进一步补强,需要进一步扩大社区与团队规模,吸纳更多爱好者加入维护与文档设计工作,使得整个博客主题对用户更加友好

5.2 市场与产品生态

AnZhiYu 的核心用户大致可以涵盖计算机、软件工程、网络安全、设计、数字媒体等相关专业或兴趣背景,本科及以上学历占比较高,其表面需求是 “想搭一个好看、功能多、可展示自己的博客站点”,潜在需求则包括 “建立个人品牌、沉淀作品、长期维护个人主页、把博客做成数字身份的一部分”

用户群体之间存在一定的关系,以 Hexo 为中心,实际上形成了一条比较完整的生态链:Hexo 提供博客框架,主题作者提供前端方案,插件作者补充功能模块,站长根据需求组合主题与插件,再通过博客、教程、issue、文章相互传播。AnZhiYu 自身 README 中也展示出其与评论系统、统计系统、主色调 API、PWA 等外部能力的耦合关系,因此它并不是一个孤立产品,而是 Hexo 生态中的一个 “前端整合层”

AnZhiYu 的子产品和相关产品之间同样存在明显联系,其本体之外,还有预览站、文档站、示例功能展示、评论服务接入、统计服务接入等外围内容。README 还提到如果用户想要类似 WordPress 的后台编辑体验,可以参考同作者的相关项目,这说明其产品思路本身已经不局限于“单纯的博客主题”,而是朝着更完整的博客工具链延展

(六)产品规划

基于对 AnZhiYu 用户的测评调研,以及其所在市场的分析,我认为一种最值得优先推进的新功能是:配置体检与升级迁移助手(AnZhiYu Doctor),因为这两项功能是在版本更新与迭代中留住大部分新手用户的关键要点,根据 NABCD 方法,对该功能的升级与后续发展说明如下:

(1)Need:

  • 当前用户在使用 AnZhiYu 时,最真实的痛点不是没有更多炫酷组件,而是配置项太多、升级后容易失效、不知道哪些配置冲突、出现页面异常时不知道应该查哪里,官方 README 文档已明确提醒升级时可能需要手动同步 _config.anzhiyu.yml,这说明配置迁移已经是用户的常见维护成本

(2)Approach:

  • 在主题中接入一个智能体,作为官方的配置诊断工具,它可以扫描 _config.anzhiyu.yml,识别弃用键、缺失键、冲突键和高风险组合;在用户升级主题版本时,自动给出迁移建议,并指出哪些页面或功能可能受影响。对于评论系统、搜索系统、统计系统这类常见外部依赖,还可以增加专项检查项

(3)Benefit:

  • 这么做可以明显降低新手上手成本,减少因配置错误导致的 issue 数量,降低版本升级时的维护压力,也能让整个主题在软件工程意义上显得更成熟、更专业

(4)Competitors:

  • Butterfly 和 Fluid 的优势之一并不只是功能多,而是它们在安装与使用路径上更成熟、更稳健,AnZhiYu 若想在竞争中胜出,必须在开发者体验和配置管理上形成自己的差异化竞争力,而不能只继续卷视觉特效,需要落地到一些具体的用户体验层面

(5)Delivery:

  • 这一功能可先以命令行检测器的方式交付,再逐步集成到本地预览页或文档站中,最终形成发现问题 - 解释问题 - 给出修复建议的闭环体验,最终完成闭环

若要完成上述功能开发,角色配置可以如下:

  • 产品经理(1 人):负责需求细化、用户调研、功能验收、协调进度
  • 前端开发(2 人):负责诊断面板 UI、配置提示展示、本地预览可视化
  • 配置/集成工程师(1 人):负责配置 schema、版本迁移逻辑、第三方服务检查
  • 主题功能开发(1 人):负责将诊断器接入主题现有结构
  • 测试(1 人):负责编写测试用例,进行配置兼容测试、Markdown 渲染测试、视觉回归测试

具体的 16 周路线规划如下:

阶段 周次 主要任务
需求与设计 1-2 梳理现有 issue,访谈真实用户,识别安装、升级、配置三类高频痛点;产出 PRD 文档
3-4 设计诊断工具信息架构,定义 _config.anzhiyu.yml 的 schema 规则;完成 UI 原型
核心开发 5-7 开发配置扫描器,支持识别缺失键、弃用键与冲突键;实现命令行版输出
8-10 接入评论、统计、搜索、PWA 等常见依赖的专项检查;开发可视化诊断页面
测试与完善 11-12 内部测试(Alpha),补充 Markdown 渲染与页面布局回归测试,修复主要问题
13-14 招募志愿者公测(Beta),收集反馈;优化错误提示文案与迁移建议准确性
发布与迭代 15 准备发布说明、升级文档、FAQ;进行最终回归测试
16 发布功能并同步文档站与 README;观察社区反馈,规划下一阶段迭代

posted @ 2026-03-17 17:33  l-h-c  阅读(18)  评论(0)    收藏  举报