---
title: "把 Word 修订带回源稿"
date: "2026-08-04"
canonical: "https://raytally.com/ideas/2026-08-04-twenty-years-of-pandoc/"
generator: "萤录 RayTally · dev-prompt-v4"
signal:
  query: "Twenty Years of Pandoc"
  observed_at: "2026-08-04T00:33:33.063Z"
sources:
  - url: "https://pandoc.org/twenty-years-of-pandoc.html"
    boundary: "发布于 2026-08-02T00:00:00.000Z。 观测于 2026-08-04T00:33:33.063Z。"
  - url: "https://news.ycombinator.com/item?id=49156750"
    boundary: "发布于 2026-08-03T00:00:00.000Z。 观测于 2026-08-04T00:33:33.063Z。"
  - url: "https://pandoc.org/MANUAL.html"
    boundary: "来源记录未提供发布时间。"
  - url: "https://sidedoc.io/"
    boundary: "来源记录未提供发布时间。"
notice: "本任务书中的信号，是在所列时间点截取的有界观察（搜索关注、论坛分数或新品列表），不是市场验证、用户数量或持续需求证明。转述或据此行动时，必须保留这些时间边界与最强反方。"
---

[在 RayTally 阅读原始页面](https://raytally.com/ideas/2026-08-04-twenty-years-of-pandoc/)

使用声明：以下信号只是带时间边界的公开观察，不是市场验证、用户数量或持续需求证明；转述或执行时必须保留时间边界与最强反方。

你是资深产品工程师。请把下面这条产品灵感做成一个可以本地运行的 MVP。

## 灵感

把 Word 修订带回源稿
收到带修订的 Word 稿后，把每处改动定位回 Markdown 或 LaTeX 主稿，再重新生成各交付版本。

## 产品概念

用 Markdown 或 LaTeX 写长文的人，最怕客户从 Word 发回一份密密麻麻的修订，最后只能把 DOCX 当成新主稿。用户把原始文本仓库里的源文件和编辑后的 Word 文件交给产品，产品先按标题、段落和相邻句子建立对应关系，而不是只按字符位置硬匹配。 修订、批注、删改和段落移动会被还原成一组可审阅的补丁。用户能逐条接受一句措辞修改，查看一段被移动到哪里，或把编辑留言保留成源文件旁的注释。无法确定对应位置的改动会单独列出，并附上 Word 中的原段落，避免悄悄改错内容。 确认补丁后，产品把修改写回 Markdown 或 LaTeX 主稿，再从同一份源文件重新生成 Word、PDF 和网页。每次导出都会保留本轮编辑版本，方便作者向客户说明哪些意见已采纳，哪些仍待讨论。 第一版优先处理正文、标题、脚注和普通批注。复杂表格、嵌入式图形与大量手工排版会保留在待处理区，让作者决定是否手动接回。

## 为什么是现在（有事实支撑）

Pandoc 二十周年回顾于 8 月 2 日发布，再次把 DOCX 往返与修订识别带回讨论。 8 月 4 日观察时，该帖位列 Hacker News 第 12，获 88 分和 11 条评论，让源稿作者更容易重新碰到 Word 意见回写难题。

## 方向判断（以下为模型推断，未经独立验证）

目标用户：面向用 Markdown、Quarto、R Markdown 或 LaTeX 维护长文的人。交稿后，客户或合作者只愿在 Word 里开修订。文件退回时，源仓库可能已经继续演进。作者此刻既要吸收意见，又不能让 DOCX 取代可构建、可追踪的主稿。

最小切入点：入口接收原始 Markdown 或 LaTeX 文件，以及客户返回的 DOCX。用 Pandoc 的 DOCX reader 和 `--track-changes=all` 提取修订、批注、作者与时间。 源文件按标题、段落、句子和脚注拆块，同时保留字节范围。先用标题路径和相邻段落缩小候选，再以文本相似度识别改写与移动。补丁只改命中的源文件范围，不重写整份文档。首版限制在 Pandoc Markdown 和结构规整的 LaTeX；表格、绘图环境及跨段批注进入人工区。

最强反方：段落匹配一旦出错，正确措辞可能被写进相似但无关的位置。长文中的重复句、改标题和跨章节移动都会放大误配。LaTeX 宏、引用命令和条件编译还会让可见文本偏离源码。为了避免静默损坏，低置信度修改必须逐条确认，这会削弱自动化带来的省时感。复杂 DOCX 结构若经转换丢失，用户还要同时维护人工修复清单。产品最终依赖的不是转换成功率，而是作者是否敢把补丁写回主分支。

以上是模型基于灵感本身与已核验事实的推断，请当作方向假设与真实约束对待：不要默认「最强反方」已被解决，也不要据此在产品里写下确定性结论。

## 以小博大（模型推断）

第一批用户可从 Pandoc、Quarto、R Markdown 和学术写作社区触达。发布一个本地命令行版，让用户用真实论文或技术白皮书验证差异。用前后对照案例展示批注、段落移动和脚注如何回到 Git 提交。再提供 GitHub Action，在收到 DOCX 后自动生成可下载的补丁审阅页。

## 竞品与缝隙（模型推断）

- Pandoc 加手工 diff：Pandoc 已能读取 DOCX，并用 `--track-changes=all` 保留插入、删除和批注。修订人及时间也会进入中间表示，过滤器还能继续处理这些节点。 它擅长在格式之间转换，也能从同一源稿生成 DOCX、PDF 和网页。不过，官方流程没有把编辑后的 DOCX 与原始源文件重新对齐。用户仍需接受整份 Word 结果，或自行解析标记后做文本比较。复杂表格等结构还可能在转换中损失细节。产品的缝隙是补上段落对应、移动识别和逐条回写，并始终保留原仓库文件的局部写法。
- Sidedoc：Sidedoc 已提供 DOCX 的提取、同步、差异和重建流程。它把正文、结构、样式与资源拆进 `.sidedoc` 目录，也支持带作者信息的插入和删除。 这已经覆盖了不少 Word 往返编辑需求，表格和图片的保真范围也更宽。它当前公开的流程从 DOCX 提取内容，再同步回该文档体系。批注和脚注仍列为未支持，现有 Markdown 或 LaTeX 仓库也不是其工作流的明确起点。这里的机会是专门处理“源稿先存在、Word 后返回”的不对称场景，并把不确定对应项交给作者确认。

## 怎么赚钱（模型推断）

按项目订阅收费，包含本地处理、版本留存和固定数量的活跃文档。复杂表格、批量迁移与团队审阅权限放入更高档方案。

## 来源背景

主题：Pandoc诞生二十周年
触发的 Hacker News 原帖（英文原文）：Twenty Years of Pandoc
抓取时热度：约 88 分、11 条评论（观测时点数值）

以上数据是抓取时刻的历史快照，分数与评论数会随时间漂移，只用于理解「为什么是现在」，不要写进产品文案当作精确的市场数字。

## 来源清单

- Twenty Years of Pandoc（https://pandoc.org/twenty-years-of-pandoc.html）
- Twenty Years of Pandoc（https://news.ycombinator.com/item?id=49156750）
- Pandoc User's Guide（https://pandoc.org/MANUAL.html）
- Sidedoc（https://sidedoc.io/）

## 交付要求

- 开工前，先从上文的产品概念与最小切入点提炼 3–5 条可验证的完成标准并列出，交付时逐条对照说明。
- 先交付「最小切入点」描述的核心流程，让核心用户能走通；范围外的账号、支付、后台等通用系统，除非确有必要否则不做。
- 页面或接口里不要展示未经验证的市场数字。
- 关键文案保持克制、可验证；产品内若需要领域事实、安全指引类内容，从「来源清单」等权威来源取材改写并注明出处，不要凭通识编写。
- 若在已有项目里实现：先读 README、依赖与项目约定，遵循既有技术栈与风格，不重构无关代码。
- 若当前目录为空：选一套轻量技术栈，优先交付可运行原型。
- 完成后说明改了什么、如何运行、如何验证。
- 遇到真正会改变产品方向的歧义再提问，普通实现细节自行做工程判断。