Panache：把 Markdown、Quarto 和 R Markdown 拉回一条统一工具链
开发团队写文档这件事，表面看起来简单，真正进入工程化阶段却很容易分裂。
- 一部分内容是 Markdown 正文；
- 一部分内容是 Quarto 或 R Markdown 里的代码块和元数据；
- 一部分需求是排版统一；
- 另一部分需求是编辑器里要有诊断、补全、跳转和 code action；
- 真到 CI 里，又希望它能像
ruff、biome、prettier一样稳定跑起来。
问题在于，这几类能力往往不在同一个工具里。
很多 Markdown 工具擅长“渲染”或者“简单格式化”，但对带有 YAML frontmatter、引用、表格、代码块、文献引用和 Quarto 扩展语法的文档工程来说，通常还差一截。
今天想记下的 jolars/panache，就在补这块空白。它不是只想做一个 Markdown formatter，而是要把 language server、formatter 和 linter 合成一套统一工具链，服务对象直接指向 Markdown、Quarto 和 R Markdown。
按 GitHub 仓库页面、release 页面和 commits feed 在 2026-06-24 的公开信息，这个仓库当前约有 177 stars、9 forks，主要语言是 Rust，仓库创建于 2025-09-03，最近一次公开提交时间是 2026-06-24。项目采用 MIT 许可证，最新 release 是 v2.58.0，发布时间为 2026-06-23。
项目概览
| 属性 | 详情 |
|---|---|
| 仓库 | jolars/panache |
| 定位 | Markdown / Quarto / R Markdown 的 language server、formatter 和 linter |
| Stars | 177 |
| Forks | 9 |
| 主要语言 | Rust |
| 创建时间 | 2025-09-03 |
| 最近公开提交 | 2026-06-24 |
| License | MIT |
| 最新版本 | v2.58.0 |
| 版本日期 | 2026-06-23 |
| 项目主页 | panache.bz |
它在补的不是“排版”单点，而是整条文档开发链路
Panache 在 README 里的自我描述很直接：它是一个 language server、formatter 和 linter，而且不是面向普通纯文本 Markdown，而是明确支持：
- Markdown；
- Quarto；
- R Markdown。
这件事的价值，在文档仓库规模变大之后会特别明显。
因为这类文档并不只是写几段说明文字，它们经常同时包含：
- frontmatter；
- 引用和脚注；
- 表格；
- 代码块；
- 可执行分析内容；
- 多种外部格式化和 lint 规则。
如果工具只擅长其中一部分，你最后还是会回到“编辑器一套、CLI 一套、CI 再拼一套”的状态。Panache 的路线则是把这几块收拢成一个可重复使用的入口。
最关键的点，是它把 LSP 和 CLI 当成同一产品，而不是两个松散附件
README 里写得很清楚，Panache 的设计目标包括：
- 完整的 LSP 实现；
- 独立 CLI，可同时做 formatting 和 linting；
- 支持 Quarto、Pandoc、R Markdown 语法；
- 基于 lossless CST 的解析；
- 幂等格式化；
- 可配置但不过度放任的默认风格；
- 可在代码块上调用外部 formatter 和 linter。
我觉得这比“支持 VS Code”更重要。
很多文档工具的问题不在于能不能装进编辑器，而在于编辑器体验和 CI 行为经常不是同一套逻辑。你本地看到的结果、提交前跑的命令、CI 最终检查的输出，可能来自不同实现。
Panache 试图把这些入口统一在一个核心里。这样你在编辑器里看到的诊断、在命令行里执行的格式化、在流水线里跑的检查，更有机会保持一致。
对带代码块的技术文档来说，支持外部 formatter / linter 很重要
我最在意的一点，是 Panache 不是把文档当成“纯文字文件”处理。
README 明确提到它支持对代码块调用外部 formatter 和 linter，而且内置了常见语言和工具的 preset。这个设计很务实，因为现实里的技术文档通常长这样：
- 正文是 Markdown；
- 示例代码可能是 Python、R、JavaScript、Bash、YAML；
- 有些代码块需要格式化，有些还要做 lint；
- 你不希望文档主工具完全重造每种语言的规则。
换句话说，Panache 的思路更像“文档层的总调度器”，而不是试图自己吞掉所有代码语言生态。
这让它更适合真正的文档工程场景：课程材料、研究报告、技术博客、数据分析说明、团队 handbook、含大量示例代码的知识库，都可能受益。
lossless CST + idempotent formatting，说明它重视可审计性
Panache 在设计目标里强调了两个词：
- lossless CST-based parsing
- idempotent formatting
这两个点看起来偏实现细节，但其实非常关键。
文档格式化工具一旦会“吃信息”或者每次运行结果不稳定，就很难进入团队级工作流。因为：
- diff 会变脏；
- review 成本会上升；
- 很难放心把它接入 pre-commit 或 CI；
- 作者会害怕工具偷偷改坏文档结构。
Panache 把这两个目标直接写进 README，至少说明它不是把“能跑通 demo”当成结束，而是在往稳定的工程工具方向收敛。
安装入口很多，说明作者在认真做分发
另一个让我觉得它已经过了玩具阶段的信号，是安装方式覆盖得比较全。
README 里能看到：
- Homebrew；
- crates.io；
- 预编译二进制；
- macOS / Linux 安装脚本；
- Windows PowerShell 安装脚本；
- AUR；
- NixOS；
- PyPI；
- npm。
这不是锦上添花，而是直接决定工具能不能进入真实团队。
一个只靠 cargo install 的 Rust 工具，往往只能吸引已经在 Rust 生态里的人；但如果你希望文档作者、数据分析同学、技术写作者、平台工程师都能装起来，分发路径就必须足够宽。Panache 在这点上明显想得更远。
它适合什么团队
从目前公开信息看，我觉得 Panache 特别适合下面这些场景：
- 团队文档大量使用 Markdown，但已经不满足于最基础的格式化；
- 内容里有 Quarto 或 R Markdown，包含 frontmatter、引用、表格和代码块；
- 希望编辑器体验和 CI 检查共用同一套核心规则；
- 想给文档仓库引入更稳定的 lint / format 流程；
- 希望代码块仍然复用各语言已有的 formatter / linter，而不是重新发明一遍。
尤其是做技术写作、研究文档、分析报告、课程材料或知识库工程的人，应该会很容易理解它的价值。
它的边界也很明确
当然，Panache 也不是“所有文档问题的总答案”。
从项目定位看，它更偏向：
- 面向作者和仓库维护者的文档开发工具；
- 面向结构化技术文档，而不是所见即所得写作器；
- 面向工程工作流，而不是内容发布平台。
如果你的核心需求是：
- 团队协作式在线编辑；
- CMS 发布流程；
- 非技术作者优先的可视化写作；
- 文档站点托管和审校后台；
那它不是直接答案。
但如果你真正要解决的是“技术文档仓库缺一套像代码仓库那样稳定的语言服务和质量门禁”，Panache 的方向就很对。
为什么值得继续关注
我觉得这个项目有意思，不只是因为它用了 Rust，也不只是因为它支持 Quarto。
真正值得注意的是，它抓住了一个长期被低估的问题：文档工程经常已经很复杂，却还在使用明显低于代码工程成熟度的工具链。
Panache 想做的事情，本质上是把这条链补齐：
- 编辑器里的语言服务；
- 命令行里的格式化；
- 命令行里的 lint；
- 代码块和正文之间的协同；
- 本地作者体验和 CI 质量门禁的一致性。
只要你写的不是“随手记两段 Markdown”，而是一批需要长期维护、可审计、可协作的技术文档，这条路线就很有价值。
小结
jolars/panache 不只是想把 Markdown 排得更整齐，而是想让 Markdown、Quarto 和 R Markdown 这类技术文档，也拥有更接近现代代码工具链的开发体验。
如果你的仓库里已经有越来越多“带结构、带代码、带规则”的文档内容，这个项目很值得放进观察列表。