简介这份名为 Manuscript 的字体资源包以手稿风格为设计主题面向需要为文档、课件、海报、视频字幕或自媒体配图增添书写质感的排版爱好者与设计师。压缩包内共 3 个文件包含 TTF 字体、HTM 说明文档和 GIF 预览图整体仅 45KB轻量且便于快速获取Manuscript 一词自带手稿、原始文本之意与这套字体的手写气质高度契合适合在数字文档中模拟纸质手稿的注释感和温度感。借助说明文档可以了解该字体的适用场景与基本属性预览图则能直观查看字形效果省去安装后才发现不合适的麻烦。用户下载解压后安装 TTF 文件即可在 Word、Photoshop、Illustrator、PPT 等常用软件中调用用于标题、引文、信纸、邀请函或手账装饰等场景让版面呈现类似手写原稿的亲和力与个性TTF 格式对 Windows 和 macOS 均有良好兼容性适合需要快速为设计项目增添手写感、又不想在网络上逐一筛选字体的普通使用者和入门设计师。已有 293 人学习下载值得喜欢手写风格字体的人收藏备用。 我一直觉得“Manuscript”这个词比中文的“稿子”更能准确描述写作过程中那种凌乱又严格的状态。它既可以指一篇还没投出去的学术论文也可以是一份改了十几版的创作手记甚至是一本没定稿的说明文档。我今年给自己定的一个小项目代号就叫“Manuscript”核心只有一个把写作从“打开Word写到哪算哪”变成一套有版本、有备份、有节奏的流程。这篇文章就是把我在维护这套手稿系统时积累的东西整理出来。适合的人很清楚如果你经常写长文、改论文、维护开源文档或者只是想让自己的文字不再因为误改、误删、格式混乱而重来那这里面的方案和排查思路应该能直接帮上忙。我会把工具选型为什么这么做、每一步操作背后的逻辑、以及踩过的坑都摊开讲不会只丢一句“用Git就行了”。1. 为什么写作前要先管理“稿子”1.1 手稿管理不是写文档而是管理迭代过程很多人听到“手稿管理”就觉得是“找个好看的软件写东西”。但真正决定一篇文章质量的不是最后那个干净整洁的终稿而是修改过程本身。我见过太多人写了三个月最后电脑里躺着十个文件名从“最终版”到“最终版3.0再改不改”的文档每一个都像是上一版的复制品互相之间改了什么完全不可追溯。Manuscript这个项目想解决的就是用一套轻量方法让每次修改都有迹可循。核心不是“用哪个编辑器”而是把写作当成一个持续迭代的工程今天删掉的两个段落后天后悔了还能找回来导师说某个章节逻辑不对你能直接回到三天前的版本对比哪里出了问题。这种可控感对写作来说太重要了因为写长文章几乎必然经历反复推翻重构没有版本管理你的自信心会被一次错误的“全选删除”摧毁。1.2 大多数人失败在自己坑自己我见过最有意思的翻车案例是有人写毕业论文用Word的“修订模式”结果提交时不小心接纳了所有陌生人的批注导致整篇文档全是自己都不知道是谁写的红色注释。还有人在群里求助说写了两周的稿子打不开了结果发现文件被同步网盘自动改名或者出现了冲突副本本地版本和云端版本互相覆盖。这些问题看起来是技术问题本质上都是流程问题。写作的过程本身已经足够消耗脑力如果格式、备份、版本对比这些琐事还要分散注意力那写完一篇长文就像跑了一场没带水袋的马拉松。所以我做Manuscript项目时给自己的原则是能用工具自动完成的绝对不手工记忆能用一个命令搞定的绝对不打开三个软件反复切换。这套原则听起来简单实施起来却需要好几个层面的配合。2. 写作环境与工具选型2.1 主流写作方案的适用边界手稿管理的第一步是选择合适的载体。我把用过的方案分成四类Word/WPS这类传统编辑器、Markdown类纯文本编辑器、LaTeX这类专业排版系统、Notion这类在线协作笔记。它们没有绝对好坏只看适用场景。方案优势适用场景不擅长的场景Word所见即所得批注方便学术投稿、团队协作改稿版本管理、格式一致性差Markdown纯文本轻量易版本管理写作、技术文档、博客复杂排版、期刊严格格式LaTeX数学公式、排版质量顶级理工科学术论文学习曲线陡峭写作效率初期低Notion实时协作、信息组织灵活素材收集、大纲规划长文导出格式不稳数据绑定平台以写作效率来看Markdown 的“内容与样式分离”特性几乎是为长期写作量身定做的。你可以把心思全放在文字本身不用频繁处理标题字号、目录缩进这类干扰项。纯文本的好处还在于无论用哪个软件打开内容都不会乱码这为后面接入版本管理创造了很好的基础。2.2 我为什么选择 Markdown Git Pandoc 的组合在我的Manuscript项目里核心三件套是Markdown、Git、Pandoc。选择这套组合的原因很简单三个工具各管一摊互不干扰而且全部免费开源。Markdown负责把手稿写成纯文本简单到一张A4纸就能写完包含标题、列表、代码块的格式说明。Git负责记录每一版修改小到一个标点的增删大到整段重写都能留下历史记录。Pandoc负责把手稿导出成需要的格式比如Word、PDF、HTML甚至符合学校要求的复杂模板。你可以把 Markdown 想象成“毛坯房”Git 是给这个毛坯房装的摄像头和档案柜Pandoc 则是装修队负责把它变成能交房的样子。三个工具体积都不大却恰好覆盖了写作从“写”到“管”到“交付”的全部环节。3. 手稿生命周期的完整管理流程3.1 从大纲到“坏稿”的写作节奏手稿要想写得快、改得稳节奏比技巧更重要。我的做法是先写大纲把章节结构用标题铺出来这时候不关心语句是否优美只关心逻辑是否完整。然后立刻进入“坏稿”阶段——故意写得很粗糙把想法先落到纸面上语法和措辞都留给后面统一处理。这个阶段最容易犯的错误是边写边改。刚写完第一段的开头回头一看觉得读不通立刻删掉重写结果半小时过去了还停留在第一段。写作和修改是两个模式混在一起只会互相拖累。我给自己定了一个强制规则坏稿阶段禁止回看前面的内容只管顺着大纲往出倒东西。等你看到成段成段的文字躺在那里那种“我已经有初稿了”的心理反馈会带来巨大的正向激励。3.2 用Git给手稿上保险前面提到版本管理这里具体说Git怎么用。说实话Git不是为写作设计的它本质上是给程序员管理代码用的但用在文本写作上反而非常合适。因为Markdown是纯文本恰好是Git最擅长处理的对象。操作上并不复杂我平常只用到几个基础命令。第一次进入手稿目录时执行初始化cd ~/manuscript git init然后每次有阶段性进展就提交一个新版本git add . git commit -m 完成第三章初稿这个过程会让你的手稿每隔一段时间就自动留下一次快照。为什么强调“阶段性”而不是“每次保存都提交”因为提交过于频繁会淹没有意义的时间节点你要的不是每敲一个字母都记录而是每完成一个完整的思维单元就打个标记。比如“写完引言”“把实验数据补进去”“删除了冗余的讨论段落”这些都是好的提交信息。如果真的改错了想回到之前的版本一条命令就能完成git checkout commit_id -- 文件路径我第一次体会这种安全感是靠实践记住的当时我删除了整段3000字的讨论两天后搜资料发现其中有一部分其实是关键的文献对标对象如果当时没有Git这部分内容就彻底丢了。而现在我只需要在历史记录里找到那次删除把需要的段落复原即可。3.3 一键导出从Markdown到各种交付格式手稿写完之后最怕的事情就是格式调整。学术期刊要Word公众号要Markdown内部交流要PDF如果每个格式都手动调一遍会耗费大量精力。Pandoc在这里堪称神器。最简单的Markdown转Word命令是pandoc manuscript.md -o manuscript.docx如果你有学校或期刊指定的模板还可以加参数指定参考文档让生成的Word自动套用模板样式pandoc manuscript.md -o manuscript.docx --reference-doctemplate.docx转PDF则稍微麻烦一点需要本地有LaTeX引擎pandoc manuscript.md -o manuscript.pdf --pdf-enginexelatex为什么用LaTeX引擎因为中文排版和常见字体支持需要它。第一次生成PDF时我踩了很大的坑默认引擎总是报找不到中文字体后来换成xelatex并且指定字体才解决pandoc manuscript.md -o manuscript.pdf --pdf-enginexelatex -V CJKmainfontNoto Sans CJK SC有了这一步Markdown作为主格式就可以在需要的时候变成任何一种交付形态你不会被锁死在某个软件的格式里。4. 高频问题与排查技巧4.1 格式在不同工具间不一致的排查人不会在同一篇文章里踩两次相同的坑但不同文章会踩相同的坑。我在这个项目里遇到最多的就是同一份Markdown文件在不同工具里显示效果不一致。某些编辑器的预览只支持一种风格的排版换一个工具后表格变得很丑代码块没有高亮甚至某些扩展语法直接不显示。解决这个问题的核心是明确Markdown的方言范围。我为自己限制的标准是只使用CommonMark基础语法加上GFMGitHub风格的表格和任务列表。这类语法在绝大多数现代编辑器和Pandoc里都有支持不会出现“在我这能显示在你那显示不了”的情况。具体排查时建议用一个最小的文件测试比如只包含一个标题、一个粗体、一个表格然后在目标工具里看渲染效果。如果基础语法都表现正常再去检查是不是特殊扩展语法导致的问题。这样做可以快速定位是哪一层出了问题而不是全篇盲目试错。4.2 目录、章节编号错乱的处理长手稿最怕章节编号错乱。Markdown里的标题默认不自动编号你看到的那种“1.2”样式通常是渲染器自己加的。Pandoc导出Word时会自动生成编号但如果你在Markdown里手动写了“1.2 引言”同时模板又开启自动编号就会出现“1.2 1.2 引言”这种灾难现场。我的处理原则是Markdown正文里只写标题文字不写编号把所有编号交给模板和参数。Pandoc导出时可以通过指定--number-sections参数让文档自动编号pandoc manuscript.md -o manuscript.docx --number-sections这样手稿源文件始终干净标题还是纯文字交付时再自动补上编号。如果你需要特定章节跳过编号比如参考文献和附录可以在对应标题后面加上{-}标签## 致谢 {-}这个语法Pandoc和很多Markdown解析器都支持能够有效控制编号范围。4.3 长周期写作时的动力断崖比格式更难解决的是长时间写一份手稿时中间段落的动力衰减。一份手稿写了一个月之后前面写的内容连自己看了都觉得陌生每天打开文件不知道从哪里继续。这时候我尝试过几个有效做法最值得推荐的是“存档快照短期迭代目标”的组合。存档快照就是利用Git在一周的结尾提交一个带说明的commit比如“第5周结束已完成数值实验部分”。这么做的好处是在你感觉不到进步的时候能看到文件列表里有迹可循地往前推进。短期迭代目标则是定一个很小的每日任务比如“今天只写完300字的结论导入段”而不是“今天要写完一整章”。手稿的建立不是一蹴而就而是靠一天三百五百字堆积出来的。真实感受是小目标能极大降低每天启动写作时的心理阻力因为300字听起来没有威胁感。5. 让手稿管理更顺手的几个补充技巧5.1 用脚本统计每天写了多少字没有反馈的写作如同在黑暗里走路所以我给Manuscript项目写了一个小脚本用来追踪每天新增的字数。核心逻辑很简单利用Git在每天特定时间点提交或统计差异。一个更轻量的做法是用git diff统计两天之间的增量字数git log --since2026-01-01 00:00 --until2026-01-02 00:00 --prettyformat:%H -- manuscript.md | xargs -I {} git show {} --stat但这条命令对新手不太友好更简单的方案是写一个Python脚本来做字符串长度统计import os, glob total 0 for path in glob.glob(*.md): with open(path, encodingutf-8) as f: total len(f.read()) print(f当前手稿总字数为: {total})你可以把这段脚本放在手稿目录里每次想知道自己写了多少就运行一次。虽然技术含量不高但心理激励作用很强尤其当你看到数字从几千涨到几万时会产生一种“我真的在完成它”的真实感。5.2 自动备份与跨设备同步版本管理解决了“改错了”的问题但还没有解决“电脑丢了”的问题。我强烈建议给Manuscript项目再加一道云同步的保险。这一步的关键是不要把Git仓库的目录放到Dropbox、OneDrive这类同步盘里直接作为工作目录否则本地文件被另一台设备同步过来的旧版本覆盖你很可能会得到一团乱麻。更稳妥的方式是使用Git远端仓库普通的仓库托管服务就可以比如GitHub、GitLab。我把手稿目录作为一个Git仓库推到远端这样既获得了跨设备备份也保留了版本历史。在不同电脑上继续写作时先拉取最新代码写完再推送git pull origin main git add . git commit -m 完成修改 git push origin main这套流程配合前面提到的Pandoc导出方案可以做到无论在哪台设备上只要有文本编辑器和Git就能无缝继续写作。我自己的体会是当写作环境不依赖特定软件和特定电脑时你对“随时随地可以推进”的信心会明显增强。6. 一些关于手稿的最终体会做Manuscript这个项目快半年最大感受是写作工具再复杂也只是为了让你能更专注地面对文字本身。我见过有人花大量时间配置自动化的CI流水线、设计多级目录模板结果独立开发了一个“稿子管理框架”却一个字都没写出来。这其实走了另一个极端。工具的价值在于稳定地解决你真实遇到的痛点。如果你只是写写日记和短文章一个word文档就够了但如果你在写一篇需要反复修改、经历多轮反馈的正式手稿那Markdown、Git、Pandoc这套基础的组合足以覆盖绝大多数的需求而且完全是免费开源。最后分享一个我一直在用的小技巧每次commit的手稿版本号不是用“v1.0”或者时间戳而是用那天完成的短语比如draft-done、revise-background、fix-chapter3。这样以后回头翻历史记录一眼就能看到这个版本背后做了什么事情。写作本来就是一版一版堆出来的给每一版起个名字你会感觉自己真的在动手“做”一篇手稿而不是被动地“等”它完成。本文还有配套的精品资源点击获取