Y Yuan Tools
2026/7/6

第八个工具：时间戳转换器与脚本化全链路测试

这次我用时间戳转换器测试新升级的 Python 自动化流程，从脚手架、验证、Release 资产、GitHub 发布到 Astro 主站同步，完整记录哪些环节稳定、哪些环节还值得继续脚本化。

第八个工具：时间戳转换器与脚本化全链路测试

这次做的是“时间戳转换器”。

表面上，它是一个给开发调试、日志排查和接口联调用的小工具：输入秒级或毫秒级时间戳，就能看到本地时间、北京时间、UTC 和 ISO 8601；也可以把日期时间字符串反向转换成时间戳。

但这次真正值得记录的，是我刚刚把小工具开发流程继续脚本化了一轮，然后用这个工具做了一次真实全链路测试。

为什么选时间戳转换器

时间戳工具有几个很适合流程测试的特点：

  • 功能不大，但是真实有用。
  • 有纯逻辑部分，适合写单元测试。
  • 有 Web 版和 Windows 桌面版。
  • 有复制、导出、批量处理这些小工具常见交互。
  • 发布后可以直接放进 Yuan Tools 网站在线使用。

它不像一个大项目那样会拖慢验证节奏，也不像“Hello”工具那样过于简单。用它测试流程，刚刚好。

这次工具做了什么

时间戳转换器 v0.1.0 包含这些能力：

  • 实时显示当前秒级和毫秒级时间戳。
  • 自动识别 10 位秒级时间戳和 13 位毫秒级时间戳。
  • 时间字符串转时间戳。
  • 同屏展示本地时间、北京时间、UTC 时间和 ISO 8601。
  • 支持一行一个时间戳的批量转换。
  • 支持复制毫秒时间戳、复制报告和导出 TXT 报告。

所有转换都在浏览器本地完成，不需要后端服务，也不会上传输入内容。

这次真正测试的是流程

我这次没有手动从零创建项目，而是先使用统一脚手架：

$env:PYTHONUTF8='1'; python D:\dev\yuan-tools\scripts\yuan_pipeline.py scaffold-tool --slug timestamp-converter --name 时间戳转换器 --port 1430

开发完成后，我使用新加的严格验证命令：

$env:PYTHONUTF8='1'; python D:\dev\yuan-tools\scripts\yuan_pipeline.py validate-tool --project yuan-timestamp-converter --slug timestamp-converter --name 时间戳转换器

这一步会按顺序执行所有本地验证，只要其中一步失败，后续步骤就不会继续跑。

发现的问题

这次流程总体跑通了，但也暴露出几个值得继续优化的点。

第一个问题是 Tauri 首次构建耗时明显。因为 Rust crates 第一次需要下载和编译，validate-tool 这一步花了比较久。后续同一机器上会快很多，但如果换新环境，这个时间仍然需要预期管理。

第二个问题是 prepare-release --feature-cards 直接传 JSON 字符串在 PowerShell 里不够稳定。命令执行时因为引号转义导致 JSON 解析失败，结果 release 资产已经生成，但 site-metadata.json 没有生成。这说明脚本需要更好的原子性，也说明复杂结构参数最好改成 JSON 文件输入。

第三个问题是新工具目录如果还没有初始化独立 git 仓库，git -C 工具目录 status 会向上找到根仓库。这不会直接导致发布失败，但会让状态判断变得不够清楚。后续发布前检查应该明确判断当前目录是否就是独立 git 根目录。

第四个问题是生产博客来源其实是 Obsidian 目录。只写 yuan-blog-platform/src/content/blog 会在构建时被 sync:obsidian 覆盖。后续写博客应该先写 Obsidian，再由构建同步到 Astro。

这些问题都不是灾难，反而很有价值：它们说明流程已经从“能跑”进入了“需要稳定、可重复、可审计”的阶段。

当前结论

这次时间戳转换器已经完成：标准脚手架创建、功能开发、中文 UI、README、工具使用说明、Vitest 单元测试、Web 静态发布包、Windows 桌面 EXE、GitHub Release 资产、独立 GitHub 仓库、Yuan Tools 根索引更新、Astro 主站同步和构建。

下一步，我会把这次发现的问题继续收进 Python 脚本，让发布过程更少依赖人工判断。

发布链接