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

在本次作业中，我选择开源项目 Typst 作为评测目标案例。Typst 是一款可用于出版的可编程标记语言，定位与 LaTeX 相似，但语法更简洁、编译速度更快、环境搭建更简单。

下面引用 Typst 官网的介绍：

“ Typst 是可用于出版的可编程标记语言，拥有变量、函数与包管理等现代编程语言的特性，注重于科学写作 (science writing)，定位与 LaTeX 相似。

语法简洁：上手难度跟 Markdown 相当，文本源码阅读性高，不会像 LaTeX 一样充斥着反斜杠与花括号。

编译速度快：Typst 使用 Rust 语言编写，即 typ(esetting+ru)st，目标运行平台是 WASM，即浏览器本地离线运行；也可以编译成命令行工具，采用一种增量编译算法和一种有约束的版面缓存方案，文档长度基本不会影响编译速度，且编译速度与常见 Markdown 渲染引擎渲染速度相当。

环境搭建简单：不需要像 LaTeX 一样折腾几个 G 的开发环境，原生支持中日韩等非拉丁语言，无论是官方 Web App 在线编辑，还是使用 VS Code 安装插件本地开发，都是即开即用。

现代编程语言：Typst 是可用于出版的可编程标记语言，拥有变量、函数、包管理与错误检查等现代编程语言的特性，同时也提供了闭包等特性，便于进行函数式编程。以及包括了 [标记模式]、{脚本模式} 与 $数学模式$ 等多种模式的作用域，并且它们可以不限深度地、交互地嵌套。并且通过包管理，你不再需要像 TexLive 一样在本地安装一大堆并不必要的宏包，而是按需自动从云端下载。 ”¹

本次作业中 Typst 的范围不只局限于名为 Typst 的命令行工具，还覆盖了包括开源社区贡献出来的开源部分和 Typst 公司的商业产品。其中，Typst 生态的核心部分是用 Rust 编写的全平台工具链，包括编译器和语言服务器等；另一部分是 Typst 官方的盈利产品，主要分析网页应用 https://typst.app/ ——类似 Overleaf 云端协作的 Typst 编辑器。

第一部分：调研与评测

软件评测

软件使用

由于本人已是 Typst 的老用户，日常使用频率较高，因此本次评测不再重复安装步骤，而是基于已有环境进行功能体验。软件更新通过 scoop update 管理，确保使用最新稳定版本。

测试环境：

操作系统：Windows 11
编辑器：VS Code
LSP：tinymist v0.14.10
编译器：typst v0.14.2

为了全面体验 Typst 的核心功能，我选取了两个典型场景：编写软件工程作业（涉及标题、正文、代码块、引用）和编写数学笔记（涉及公式、定理、证明）。以下是实际操作截图：

除了本地开发，我也测试了官方网页应用。注册账号后开箱即用，浏览器内即可直接编辑，无需任何配置，体验与本地基本一致：

产品使用基本流程：

环境搭建：本地用户需安装 Typst 编译器、tinymist 及对应 VS Code 插件；网页用户只需访问 https://typst.app/ 注册登录。
内容编写：使用类 Markdown 的语法编写文字。
样式定义：通过 #set 指令全局配置字体、页边距；通过 #show 指令对特定元素（如标题、链接）进行样式重写。
即时渲染：每保存一次（或者在 Web App 中键入时），PDF 预览会以毫秒级的速度实时更新。
导出分享：本地可通过命令行生成 PDF，网页端点击“导出”按钮即可下载高精度文档，也可生成分享链接进行协作。

软件分析

是否解决了用户需求？

Typst 精准击中了 LaTeX 用户长期以来的两大痛点：环境配置痛苦和编译反馈极慢。它让用户能够像写 Markdown 一样轻松，同时拥有 LaTeX 级别的专业排版能力。对于需要快速产出高质量文档的学生、科研人员，Typst 确实提供了更现代的解决方案。

多维度评估

维度	优势	劣势
界面	Web 端：极简主义设计，分栏布局清晰。IDE：配合 VS Code 插件有完美的语法高亮和符号补全。	官方 Web 编辑器目前缺乏深度的文件管理功能（如批量重命名或文件夹嵌套层级过深时的导航）。
功能	强大的脚本能力（基于 Rust 风格的逻辑），支持函数、变量和循环，可以像写程序一样写文档。	相比 LaTeX 几十年的积累，目前在特定领域的专业宏包（如复杂的电路图、化学方程式自动排版）还不够丰富。
性能	由于采用了增量编译计数，改动一个字可以在毫秒内完成预览页面的更新。与 LaTeX 的渲染速度形成鲜明对比。甚至 Typst 实时预览效果体验高于一般（以 JavaScript 写成而难以性能优化的）Markdown 双栏编辑器。	暂无
用户体验	报错信息精准到行列，错误类型友好可读，且具有提示。语法简洁，易于用户上手，同时图灵完备，能做复杂且强大的功能。与之相比，LaTeX 的宏编程让人烧脑。	学习曲线虽然比 LaTeX 平缓，但对于完全没有编程思维的用户来说，理解 `#show` 和 `#set` 的逻辑仍有门槛。

Table 1: 多维度评估

改进意见

增强生态迁移工具。开源社区可以提供更成熟的 pandoc 插件，帮助用户将更多其他类型的文件转换为 .typ 文件，解决“历史债”问题；同时也支持从 .typ 文件导出到其他格式，便于与仍使用 Word、LaTeX 等工具的协作者交接。

优化离线包管理。目前 Typst 的包管理深度集成于编译器中，遇到未缓存的包会自动联网下载，虽方便了多数用户，但在内网开发或无网络环境下则难以使用。此外，用户无法精细管理本地包缓存（如清理无用包、手动导入离线包）。建议增加离线包导入功能，并提供缓存管理界面。

提供可视化排版辅助。Typst 强调“代码即文档”，但对于表格、CeTZ（对标 TikZ）绘制的图表等二维结构，允许“所见即所得”的拖拽式调整会大幅降低调试成本。用户不再需要盲目尝试代码参数来调整位置或样式，可以通过图形界面快速完成布局，再同步生成对应代码，兼顾效率与可复现性。

用户调研

评测结论

类别	指标描述	Typst	LaTeX	Markdown
核心功能	排版质量、公式处理、图表与参考文献支持、文档结构管理等核心能力的完备性和易用性。	8 分：内置常用排版元素（公式处理、图表与参考文献支持），复杂场景下模板和包数量尚不及 LaTeX。	10 分：功能完备，宏包丰富，是期刊和学位论文的标准。	6 分：仅基础标记，排版能力弱。
细节	语法设计是否直观、错误提示是否清晰、是否有模板库、是否支持实时预览等。	9 分：语法直观，错误清晰，实时预览。	4 分：语法晦涩，错误难懂，配置复杂；实时预览需依赖 Overleaf 等第三方平台，但通常只能保存一次预览一次。	8 分：语法极简，但错误提示、实时预览等细节完全依赖编辑器。
用户体验	写作流程的流畅度、实时预览体验、界面简洁性、专注模式支持。	10 分：即时渲染，修改文件可立即预览。界面极简，无任何干扰元素，支持深色模式和全屏专注模式，全程沉浸式写作。	8 分：编译有等待时间，实时预览需依赖编辑器和平台，写作流程存在中断感。	9 分：优秀编辑器实时渲染零延迟，界面和专注模式依赖于编辑器，但体验依赖具体工具。
辅助功能	文档模板、自定义样式、插件扩展等辅助功能的丰富度。	7 分：基础主题，模板生态尚处早期，不过用户可方便地自定义模板与样式。	8 分：编辑器主题，文档类丰富，可深度自定义样式，但是对普通用户门槛较高。	9 分：编辑器丰富，自定义强。
差异化功能	相比其他排版系统的独特功能点，以及对目标用户的吸引力。	9 分：结合 Markdown 易用与 LaTeX 排版。	8 分：排版质量与生态，学术标准。	8 分：极简普适，工具链完善，几乎是笔记、文档、博客的通用语言。
软件的效能	编译 / 渲染速度、内存占用、启动速度、文件大小等。	10 分：毫秒级编译，文件修改后可增量编译；内存占用低，自身安装包仅几十 MB。	5 分：编译文档慢，多次编译尤甚。TeX Live 完整安装占用数 GB 磁盘空间，内存消耗大，且每次编译都需加载大量宏包。	10 分：纯文本，几乎无开销。
体验	跨平台支持、离线可用性、移动端适配、键盘操作友好性、与其他工具（如 Git、编辑器）的协作能力。	10 分：跨平台可离线，键盘友好，Git 协作佳，无移动端。	7 分：跨平台可离线但配置复杂，协作时 .tex 文件虽为文本，但宏包冲突常导致合并困难，无移动端。	10 分：跨平台可离线，键盘高效，Git 协作佳。移动端有少量 APP 提供编辑，但是体验不佳。
成长性	学习曲线平缓度、用户自定义模板 / 宏的便利性、随着使用积累的效率提升。	10 分：学习平缓，自定义方便，越用越顺手，社区更新速度块。	9 分：学习陡峭，掌握后可实现强大功能。	7 分：上手极快，天花板低；编辑器在不断进化，变得越来越智能。
用户有控制权	编译/渲染过程可控、错误恢复便捷、快捷键可定制、状态反馈及时。	9 分：编译快，错误清晰，控制感强。	6 分：编译慢，错误难恢复，控制复杂。	8 分：依赖编辑器，优秀编辑器控制佳。
社区与生态	用户社区活跃度、模板 / 宏包数量、第三方工具支持、文档资源丰富度。	8 分：社区活跃，生态发展中。	10 分：生态庞大，模板工具丰富。	10 分：生态最广，普适标准。

与当前市面上主流竞品（LaTeX、Markdown）相比，Typst 交上了一份兼具 Markdown 轻便性、LaTeX 专业性的答卷。我评价为 e) 非常推荐。

Bug 分析和提交

以下问题在可以 Windows 11 下使用 typst v0.14.2 下复现。

在进入具体 Bug 分析前，设定以下量化标准以便评估：

★★★★★：致命性系统故障、安全性漏洞、用户体验完全不可用

★★★★☆：严重功能缺失、用户体验极差

★★★☆☆：中等程度功能异常、影响美观

★★☆☆☆：轻微界面、交互瑕疵、不影响核心功能

★☆☆☆☆：建议性改进、极少数场景下出现

中英文距问题

问题描述

Typst 默认对中英文间距做了调整。中文与英文之间，就算没有加空格，Typst 也会自动在中英文之间添加间距。但是如果手动给中英文之间添加了间距，会比默认间距更大。

示例代码

#set text(cjk-latin-spacing: auto)
#set text(
  font: (
    "simsun",
  ),
  lang: "zh",
)
1. 中文  English  中文
2. 中文 English 中文
3. 中文English中文

此时前两个的间距是一致的，尽管第 1 行的中英文之间有两个空格，Typst 也会只视为一个空格，这是 Typst 所遵循的智能间距。

但是第 3 行不添加任何空格时，虽然 Typst 为中英文之间添加了默认间距，但是与手动添加的空格不一致，第 3 行的间距会明显比第 1、2 行小。这导致排版不一致。

Typst 为了实现中英文混排的“智能间距”，会在检测到相邻字符的 Unicode 脚本切换（如中文与拉丁字母）时，自动插入一个默认间距。这个默认间距的宽度设置得较为合适，符合一般中文排版习惯（例如约为 1/4 em）。同时，Typst 也保留了用户手动输入的空格（无论是显式键入的空格符 U+0020，还是由换行符转换而来的空格），这些手动空格的宽度就是普通空格的宽度（通常约为 1/3 em 或与字体相关）。单独来看，自动间距和手动空格宽度都可能是视觉上“合适”的——前者紧凑精致，后者舒展清晰，不同用户或不同场景可能有不同偏好。

问题的核心在于两者宽度不一致，且 Typst 缺乏统一机制。当用户出于个人习惯（有人习惯加空格，有人习惯不加）或因为源码中的换行（为保持代码可读性而换行）而意外引入手动空格时，最终文档中就会出现两种宽度并存的局面：同一份文档里，有的中英文之间是较窄的自动间距，有的是较宽的手动空格间距。这种不一致破坏了文档的整体美观和专业性。

在成熟的排版软件（如 Microsoft Word、Adobe InDesign）中，中英文之间的间距由引擎统一控制，用户手动添加空格不会改变最终的间距宽度——引擎要么忽略手动空格，要么将其与默认间距合并，确保一致性。Typst 的行为违背了这一行业惯例。

可能成因

Typst 为了实现中英文之间的自动间距，采用了修改汉字字形属性的方式，而非插入独立的空白字符。具体来说，函数 add_cjk_latin_spacing 在处理中英文混排时，会检测到相邻的汉字（CJK）和拉丁字母，然后通过增加汉字的 x_advance（水平前进宽度）并设置相应的 offset，在汉字右侧“挤出”一段空白。这段空白附着在汉字上，是汉字字形的一部分，而非独立的排版元素。

与此不同，用户手动输入的空格（U+0020）是一个独立的字符，其宽度由当前字体的空格字形（space glyph）决定，通常是一个固定的宽度（例如字体设计中的空格宽度，可能约为 0.33em 或更宽）。当用户在中文与英文之间键入空格时，该空格字符会作为独立的元素参与排版，其宽度完全来自字体。

这两种机制产生的空白在本质上是不同的：

自动间距：通过修改汉字属性实现，宽度由 Typst 内部设定（例如固定为 0.25em），不受字体空格宽度影响。
手动空格：作为独立字符，宽度由字体决定，通常与字体设计相关，可能略宽于自动间距。

由于实现机制的差异，Typst 无法自动将手动空格与自动间距统一。当用户出于个人习惯（习惯加空格或不加空格）或因为源码中的换行（换行符被转换为空格）而引入手动空格时，文档中就会出现两种不同的空白宽度：自动间距（较窄）和手动空格（较宽）。即使两者单独看起来都“合适”，但它们并存于同一文档中就会破坏排版的一致性。

问题评级

★★★☆☆。排版是 Typst 的核心功能，间距不一致直接影响文档输出质量，但程序仍能正常编译，不导致崩溃或数据丢失，无任何安全风险。影响范围限于中英文混排用户，属于中等程度困扰。

Typst 团队可能以英文用户为主，对中文用户的书写习惯（部分人习惯手动加空格，部分人不加）以及排版一致性的重要性理解不够深入，未意识到手动空格不应导致间距差异。测试用例可能未覆盖中英文混排时不同用户习惯的场景，也未对比用户手动加空格与不加空格时的输出差异，导致该问题流入发布版本。

同时，Typst 仍处于快速迭代期，团队可能优先处理更严重的稳定性或性能问题，将此类“体验优化”问题暂时搁置。

建议改进

将 add_cjk_latin_spacing 的实现方式从“修改汉字 x_advance 和 offset”改为插入独立的空白元素（如 Spacing 类型）。这样，自动间距就与手动空格（U+0020 字符）处于同一抽象层次，便于统一处理。

`figure` 容器内的 `table` 无法触发自动分页

问题描述

Typst 原本支持对长表格自动分页。在文档顶层直接使用 #table 组件时，排版引擎能够根据页面剩余空间自动截断内容并跳转至下一页续接。见Figure 6。

但在实际测试中，为了为一个包含 50 余行数据的长表格添加题注并实现自动编号，我按照 Typst 官方规范将 #table 组件嵌套在了 #figure 容器内。在实时预览过程中发现，当该表格的高度超过当前页面剩余空间时，其自动分页逻辑失效。表格底部的行直接溢出到页边距之外，并与底部的页脚内容发生重叠，未能正确截断。见Figure 7。

可能原因

当 #table 独立存在时，Typst 排版引擎能够根据页面剩余空间自动截断内容并跳转至下一页续接。但在嵌套场景下，#table 被放入 #figure 中，#figure 会被视为一个不可分割的原子块。布局引擎会尝试计算整个 #figure 的总高度，由于其高度超过了页面可用高度，引擎却无法将其拆分，最终导致内容直接“冲出”页面底部，重叠在页脚甚至页外。

为什么软件团队未能修复该 Bug？我认为主要原因是以下几点的结合：

具体的设计质量不高：Typst 的底层布局引擎是基于 Constraints 和 Blocks 构建的。在最初的设计中，#figure 被定义为一个原子容器，其目的是为了确保图片、表格与其对应的题注（Caption）在逻辑上始终保持在一起，避免出现“表在第一页，题注在第二页”的排版事故。

这种设计在处理图片（不可拆分）时表现完美，但在处理长表格（高度动态且可拆分）时，其“不可拆分”的硬性约束与表格的“流式分页”属性产生了架构层面的冲突。修复它不仅是改几行代码，而是需要重构 #figure 的基础定义。
对用户需求掌握不好：Typst 的早期用户多为进行短篇幅论文撰写的开发者，他们对表格的需求往往集中在“小而精”的数据展示。

团队可能低估了学术界和工业界对超长实验数据表（超过一页）并配合标准 #figure 编号的强依赖。在开发者看来，如果表格太长，用户可以不加 #figure；但在用户看来，不加 #figure 就没法自动生成“表 1.1”的标签，这属于刚需。
测试把关不严：由于 Typst 的测试用例可能大多聚焦于单个组件，但在复合场景下的测试覆盖不够全面。

问题评级

★★★★☆。#figure 是学术论文中带标签表格的唯一标准实现方式，此 Bug 导致长表格无法在规范文档中正常使用。

改进建议

重构容器约束，修改 #figure 的布局逻辑，允许其根据子元素的需求支持跨页（Breakable）。确保父容器在调用子元素布局函数时，能够正确传递当前页面的剩余可用高度。

第二部分分析

截至今日（2026 年 3 月 17 日），Typst 的 GitHub 仓库，共有 4468 次提交，27 次 Release，425 为贡献者，约十万行代码。这些数据对接下来的分析有很大的参考价值。

工作量分析

6 名计算机专业毕业生（具备 Rust 开发能力）复刻一个达到目前 Typst 成熟度（v0.14）的系统需要多久？

从技术壁垒角度看，Typst 不仅仅是一个渲染器，它包含了一套完整的编译器架构、自研布局引擎以及脚本语言解释器。如果 6 名大学生要攻克这些技术难关，从难到易的分析如下：

排版引擎：涉及字体度量、Unicode 多语言编码、HarfBuzz 绑定、数学公式排版（TFE 算法等），这是最难的部分，由于相似的代码在网上不多见，很可能会经历多次技术路线的死胡同。这一部分约占总工作量的 40%。
编译器与脚本语言：从词法分析到语法树构建，再到增量编译机制，要求极高的算法功底。技术实现上，编译器的编写对于科班计算机学院的学生不算难事，但是编程语言的设计、独当一面的脚本语言代码风格设想非常需要想象力和创造力。这部分的工作约占 30%。
生态与插件系统：包管理协议与标准的建立，基于 WASM 的插件扩展机制，约占 15%。
跨平台与工具链：CLI 开发、LSP 服务（用于编辑器补齐）、Web 端 WASM 适配，约占 15%。

假设团队成员拥有极强逻辑思维和底层开发经验的基础，相关的技术难度稳定逐个突破，每个工作日都能参与项目代码的编写，略去查阅文档以及 Bug 反馈的时间，可以对项目排期做定量估计。

Typst 项目中有约 10 万行 Rust 代码。考虑到 Rust 的开发效率与安全性权衡，高水平毕业生的人均日产出有效代码（含测试）约为 200 行。

。

实际上，考虑到需求调研、架构反复迭代（Typst 的布局引擎经历过多次重构）以及复杂的测试，项目的完成时间只会更长，预计最快需要 12 到 15 个月才能从零做到目前的程度。

软件质量分析

优劣势对比与排名

Typst 虽然采用了跟 Markdown 一样简单的语法，但是它的目标是 LaTeX 那样成熟的纸质文档排版工具。在当前的现代代码驱动排版系统（因此排除了传统的 Word/Pages）中，这样的竞品不多。

在直接构成竞争关系的现代代码驱动排版系统中，Typst 的表现如下：

排名	工具	定位	优势	劣势
1	LaTeX	学术界标准排版系统	历史悠久，生态最成熟；数学公式排版的标准；强大的参考文献管理	宏编程困难，学习曲线陡峭；编译速度慢，难以实时预览
2	Typst	简洁易上手的排版系统	语法简单，编译速度块，实时预览具有与所见即所得近乎相似的体验	生态尚薄弱，在相关领域较少被人接受
3	Quarkdown	专业级 Markdown 扩展	能够在 Markdown 基础上增加动态脚本、印刷级 PDF、交互式幻灯片，兼容 Markdown 生态	生态较新
4	SILE	现代排版引擎（Lua 驱动）	从底层重新设计的排版算法	生态很小
5	Groff (GNU troff)	传统 Unix 排版工具	历史悠久，体积轻量，适合手册页	语法古老，功能有限，现代使用场景少

改进建议：设立生态健康度度量指标

当前团队可能只关注编译器性能指标，建议增加生态维度的可量化 KPI：

指标	当前状态	目标	测量方式
关键领域模板覆盖率	基础科学为主	覆盖 CS/工程/商科/医学	统计官方包管理器分类
迁移成功率	无	LaTeX 文档/模板 70% 可自动迁移	抽样测试 pandoc 转换
内网/企业采用率	低	支持 Top 10 高校/研究所内网部署	合作调研

第三部分建议和规划

市场现状

Typst 面对的是专业文档排版工具市场。这个市场可以分成两块：一块是直接用户，也就是核心市场，主要包括全球的学术研究人员、高校学生和技术写作者。全球大概有 1000 万科研人员，其中超过 70% 需要写论文、做报告，这些都是 Typst 的潜在用户。目前 Typst 在 GitHub 上有 4 万多个星标，月活用户估算在 10 到 20 万之间。

另一块是潜在用户，有更广阔的市场。企业里那些习惯了 Markdown、又想输出更专业文档的工程师，出版行业的编辑，从中学到大学需做作业、写教案的师生，这些人目前还没大规模用上 Typst，但需求是存在的。

竞争产品

直接竞品已在第二部分详述，竞争态势可归纳为：

产品	市场定位与份额	威胁程度
LaTeX	学术界 >80%	高，生态壁垒极高
Word / Google Docs	通用市场 >90%	中，赛道不同
Quarkdown /SILE /Groff	文档 <1%	高，功能重叠度高
Typst	新兴 <5%	——

产品定位

Typst 当前定位是“兼具 Markdown 的简洁和 LaTeX 的专业”。

维度	优势	劣势	竞争态势
技术体验	编译速度、实时预览、错误提示	生态薄弱	单点突破，尚未形成系统优势
用户心智	现代、简洁、程序员友好	学术权威性不足	被视为“玩具”而非“工具”
商业模式	开源核心 + 云服务增值	收入模式单一	依赖捐赠和有限的企业服务

Typst 处于技术领先但市场滞后的阶段。LaTeX 凭借几十年积累的生态和学术惯性形成护城河，Typst 需要找到非对称作战的突破口。

市场与产品生态

根据产品特性和 GitHub 社区的观察，可以画出几类典型用户。

特点	用户 A：张明，计算机科学博士生	用户 B：李教授，高校青年教师	用户：王工程师，技术文档工程师
学历	博士在读	博士	本科/硕士
年龄	25-28 岁	32-40 岁	26-35 岁
专业	计算机科学/软件工程	数学/物理/工程	软件工程
爱好	开源贡献、技术博客、效率工具	教学工具探索、学术社交	自动化工具、文档即代码（Docs-as-Code）
收入	奖学金/助研金，月收入 3000-5000 元	年薪 15-30 万	年薪 20-40 万
表面需求	快速撰写发表论文，避免 LaTeX 调试痛苦	指导学生统一论文格式，减少格式审查工作量	将现有 Markdown 文档升级为专业 PDF 手册
潜在需求	希望简历/CV 也能用同一套工具制作	需要批注和协作审阅功能	与 CI/CD 流水线集成；多格式输出（PDF/HTML/EPUB）

根据观察，这三类用户之间其实有一条影响链：李教授是决策者和影响者，他会把工具推荐给学生；张明是早期采用者，用得好会在同学里传播；王工程师则会把学术工具带到工业界。我们可以利用这个关系做点事情，比如搞个“学术影响者计划”，给顶尖高校的年轻老师定制课程模板包，顺便送学生授权；再比如建立模板贡献者的声誉系统，谁做的好就官方推荐；还可以鼓励企业把内部模板开源出来，让学术界也能用上。

产品生态关系

除了用户，Typst 周边还有一些相关产品，它们的关系和利用策略可以看这个表：

子产品/相关产品	关系类型	生态利用策略
tinymist（LSP）	核心依赖	推动成为 VS Code/JetBrains 官方推荐插件，降低入门门槛
typst.app (Web)	云服务增值	与本地 CLI 形成“离线 - 在线”闭环，Web 端作为协作和模板分发中心
pandoc	生态伙伴	开发官方 typst 格式支持，成为 Markdown→PDF 的最佳路径
Git/GitHub	基础设施	强化“文档即代码”工作流，开发 GitHub Action 官方插件
Zotero/Mendeley	学术工具链	集成参考文献管理，提供一键导入 `.bib` 功能

产品规划

新功能设计：智能模板迁移系统

为何选择此功能？

基于前文分析，Typst 的最大瓶颈是生态薄弱，而生态建设的最大障碍是迁移成本。用户拥有大量历史 LaTeX/Markdown/Word 模板，但手动迁移困难。该系统直接解决这一痛点，相比其他功能（如可视化编辑器、移动端 App）都更有战略价值。。

使用 NABCD 分析：

Need（需求）：显性需求是用户想把 LaTeX 模板（尤其是期刊投稿模板）转成 Typst 格式；隐性需求是很多机构想统一文档标准，但又不想花钱请人改。GitHub 上“template request”标签下有两百多个没解决的问题，用户调研里“生态迁移工具”也被列为最想要的改进。
Approach（做法）：我们打算做三层架构。第一层用 Tree-sitter 把 LaTeX 或 Word 文档解析成语法树；第二层建个社区共建的宏包映射库，把 LaTeX 宏包对应到 Typst 模块；第三层用微调过的代码大模型（比如 CodeLlama）处理那些模糊的语义，同时保留和编写注释。
Benefit（好处）：用户迁移时间从几小时缩到几分钟，文档结构还能保留。对生态来说，等于一次性解决了“先有鸡还是先有蛋”的问题，模板库能快速丰富起来。商业上，企业版可以卖私有模板迁移服务，也算条收入路子。
Competition（竞争）：LaTeX 自己没有出官方迁移工具，社区里的 pandoc 转换质量参差不齐。Quarto 支持单向从 Markdown 转 LaTeX，但反过来不行。我们的方案是双向的、可定制的，还能靠社区不断迭代，差异化很明显。
Delivery（推广）：第一阶段先把核心迁移引擎开源，吸引技术爱好者贡献映射规则；第二阶段集成到 typst.app 里，提供“上传 .tex → 下载 .typ”的一键服务；第三阶段可以跟 Overleaf 合作（或者直接竞争），给跳槽过来的用户提供优惠。

要实现这个功能，需要 6 个人干 16 周。配置上，1 个项目经理兼做需求分析，3 个开发（分别负责 Rust 底层、前端界面和 LLM 集成），1 个测试工程师，1 个既能画界面又能写技术文档的多面手。

16 周的详细规划如下：

周次	阶段	核心任务	交付物	里程碑
1	启动	需求细化；技术选型（LLM 模型、解析器方案）；搭建 CI/CD	技术设计文档；开发环境	设计评审通过
2	基础	实现 LaTeX 词法分析器；建立 AST 基础结构	可解析 80% 常用 LaTeX 命令的解析器	基础架构完成
3	基础	实现 Typst 代码生成器；建立双向映射表框架	端到端原型（简单文档）	原型验证
4	核心	开发宏包语义映射数据库；覆盖 top 20 常用宏包	宏包映射 v1.0	核心能力可用
5	核心	集成 LLM 优化层；处理模糊语义和注释	LLM 微调 pipeline	智能层集成
6	迭代	支持 Word 格式输入（基于 pandoc）；优化表格/图片迁移	多格式支持原型	范围扩展
7	质量	建立迁移质量评估体系（BLEU 分数 + 人工评估）；批量测试	测试框架；100 份样本测试报告	质量基线建立
8	质量	Bug 修复；性能优化（大文档处理）；边缘 case 处理	性能优化报告	中期评审
9	产品	Web 界面开发（上传 → 预览 → 下载）；用户账户集成	Web MVP	Web 端可用
10	产品	开发迁移报告功能（对比原文件和新文件差异高亮）	差异可视化功能	用户体验优化
11	生态	启动社区映射贡献计划；开发贡献者工具（映射规则验证器）	贡献指南；验证工具	社区机制建立
12	集成	集成至 typst.app 主站；A/B 测试入口	生产环境部署	集成完成
13	测试	全链路压力测试；安全审计（文件上传安全）	测试报告；安全审计报告	发布准备
14	文档	编写用户指南和 API 文档；制作演示视频	完整文档包；宣传材料	文档完备
15	发布	灰度发布（10% 用户）；收集反馈；紧急修复	灰度发布报告	预发布
16	发布	全量发布；社区推广；总结复盘	正式发布；复盘报告	v1.0 发布

当然，计划赶不上变化，得提前做风险控制。如果 LLM 智能转换的效果可能不及预期，我们在第四周需要设个决策点，根据效果决策是否切回纯规则引擎。如果 Word 格式太复杂的话，在第六周可以评估是否先只支持 LaTeX。要是 Rust 开发人手不够，第二周需要确认核心开发能力，随时调整分工。

¹ https://typst.dev/docs/chinese/

Posted on 2026-03-17 22:52 Likend 阅读(39) 评论(0) 收藏举报

刷新页面返回顶部

likend

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

第一部分：调研与评测