Kami · 紙：让 AI 交付物从"能看"变成"想看"

一份被 AI 搞砸的报告，催生了一个 12K 星的项目

想象这样一个场景：你让 AI 写一份美股研究报告，内容本身没问题——数据准确、逻辑清晰、结论明确。但当你准备把它发给团队时，你盯着屏幕上那份灰扑扑的文档，标题和正文挤在一起，每页都塞得满满当当，图表是用默认灰框拼出来的，字体是那套你在任何一份 AI 输出里都见过的无衬线体。你默默关掉窗口，心里想：内容能看，但这东西拿出去丢人。

Tw93（一位长期投资美股的独立开发者）遇到的正是这个问题。他发现每次开新对话，Claude 都会给他一套几乎一样的"默认文档脸"：结构难扫、格式过时、排版每次都不一样。于是他开始一条一条地调——字体换成衬线体，背景从纯白调成暖米色，强调色从深蓝灰改成油墨蓝，行距分三档，阴影全删掉。他后来说，这套调整的核心不是"变好看"，而是"让报告值得被读"。

后来他要做一场关于 Agent 技术的演讲，手上已经有文稿，不想从零做 PPT，于是用 Claude Design 按自己的风格一版版地调。过程中他加入了内联 SVG 图表、统一了暖色系色板、收紧了编辑节奏。这套方法越用越顺手，最后覆盖了他日常产出的全部文档类型——他把这堆模板和规则整理成了 Kami（紙，日语"纸"）。

现在这个项目在 GitHub 上收获了 12,274 个 Star、575 个 Fork，是 tw93 "Kaku · Waza · Kami" 三部曲中的收尾之作（前两部分别是写代码的 Kaku 和练工程习惯的 Waza）。

类比：给 AI 配一个专业排版团队

如果把大模型比作一个才华横溢但永远穿格子衫的作者，Kami 就是那位永远在场的资深编辑。

它不负责写内容——写内容是大模型的长项。它负责的是另一件事：把"能读懂"变成"愿意读"。

具体做法是把排版决策固化成一套规则和模板。当你说"帮我做一份简历"时，AI 不再是从零手写 HTML，而是从 Kami 提供的简历模板出发，只填内容、不动 CSS；当你说"帮我排版一份白皮书"时，它会自动选用长文档模板并套用统一的版式规范。

这就像一间有专职排版设计师的编辑部：写手（AI）专注把话说明白，设计师（Kami）负责字号层级、留白节奏、图表配色。两者分离，是 Kami 最核心的架构思想。

核心功能：一套规则，覆盖你所有交付场景

九类文档模板，EN/CN/KO 三语并行

项目内置 One-Pager（一页纸/执行摘要）、Long Doc（白皮书/长文档）、Letter（正式信函/推荐信）、Portfolio（作品集）、Resume（简历）、Slides（幻灯片）、Equity Report（个股研报）、Changelog（更新日志）、Social Cards（社交卡片）九类模板，每类都提供中文、英文、韩文三个变体。日文通过字体回退和排版微调支持，属于尽力而为档位。

设计上有一个很克制的决定：全页只用一种衬线字体。英文用 Charter，中文用仓耳今楷 TsangerJinKai02，日文用游明朝 YuMincho，韩文用思源宋体。字体统一后，页面气质立刻统一，比混排两种字体更显专业。

三条幻灯片渲染路径

这是 Kami 技术含量最集中的地方：

• WeasyPrint HTML → PDF（默认路径）：纯 Python 方案，跨平台一致，适合投影和分享
• python-pptx → 可编辑 PPTX：只在明确需要"可编辑演示稿"时才启用，方便客户二次编辑
• Marp Markdown：面向 Markdown-first 的演讲稿场景

三条路径共用同一套设计 token（references/tokens.json）和模板体系，所以视觉上高度一致。

十八种内联 SVG 图表 + Mermaid 接入

项目自带 18 种内联 SVG 图表模板，包括报告级架构图板。时序图、类图、ER 图可以直接用 Mermaid 文本编写，由 beautiful-mermaid 渲染成 SVG，再用 mermaid_normalize.py 重新套用 Kami 的暖色色板并做 WeasyPrint 安全化处理——不需要打包 Node 运行时，这一点对 Agent 技能包来说非常关键。

一套"交付前体检"流水线

这是 Kami 最被低估的部分。scripts/build.py --deliver 会在文档交付前跑完所有检查并给出一个总判定：

• 结构检查：content.json 填充前先校验 schema，防止内容缺块
• 版式检查：页面密度（尾部空白超过 25% 告警）、孤立行（orphan）、简历两页平衡
• 字体检查：确认真正绘制 CJK 文字的字体，而不是回退字体
• 残留检查：检测未替换的 {{占位符}} 和 Markdown 残留在 PDF 中
• 卡片检查：社交卡片文字是否压图、是否以 1-3 个字符结尾
• 节奏检查：幻灯片序列是否单调重复

作者还在 references/anti-patterns.md 里写下了九大类"AI 文档常见病"，明确要求不要生成散乱多页文档——"AI 生成多页文档时最常见的 draft 缺陷：把内容拆得太散，结果几页都填不满"，并给每个模板规定了"每页条目数下限，低于就合并"。

品牌档案：把偏好沉淀下来

在 ~/.config/kami/brand.md 写下姓名、角色、品牌色、默认字体、语气等 YAML 前置字段加 Markdown 自由笔记，之后所有文档都会自动沿用这些默认值，不必每次重复交代。优先级链明确写着：显式提示 > 编辑判断 > 习惯笔记 > frontmatter 默认 > 内置默认。用户还可以给一个品牌网站，让 brand_extract.py 自动起草品牌档案供确认。

零依赖 MCP Server

scripts/mcp_server.py 是一个纯标准库实现的 MCP 服务，暴露能力诊断、渲染、结构化检查、截图四类工具。这意味着任何支持 MCP 的 Agent 都可以把 Kami 当作外部排版引擎调用，而不必把整份技能提示词塞进上下文。项目还内置 scripts/mcp_server.py 的安全提示：只渲染受信任的本地 HTML。

其他实用细节

• 字体自愈：ensure-fonts.sh 在缺失中韩字体时自动从 CDN 恢复到用户字体目录；ensure_mathjax.sh 保证数学公式渲染
• 每日一次静默更新检查：check-update.sh 每天最多检查一次 GitHub Release，只写本地标记文件，不上传任何文档或任务内容，离线或沙箱环境下静默失败
• 白底打印变体：默认暖米色背景适合屏幕阅读，一键切换为白底适配家用/办公打印机，而卡片和表格仍保留暖色
• 落地页系统：同一套设计语言还覆盖产品落地页，含轮播图、响应式断点（880px/480px）、prefers-reduced-motion 支持，以及 Vercel rewrites、sitemap hreflang、robots AI 白名单、llms.txt 等部署配套文件

上手门槛：装起来只要一行，坑在系统依赖

安装极简，这是它能快速起量的关键：

npx skills add tw93/kami -a claude-code codex cursor -g -y

一份副本落在共享技能目录 ~/.agents/skills，Claude Code 会被软链过去，Codex、Cursor 等读取该目录的 Agent 直接以 /kami 形式识别。也支持作为宿主插件（Claude Code v2.1.142+ 走 /plugin marketplace add tw93/kami）和 Claude Desktop（下载 release 里的 kami.zip 上传到 Customize > Skills）。

但真正的门槛在后面：

PDF 渲染依赖 WeasyPrint，而 WeasyPrint 在 Linux 上链接 cairo/pango/harfbuzz 原生库，光 pip install weasyprint 会成功、运行时却报 cannot load library 'libgobject-2.0'。项目在 optional_deps.py 里把这条原生库安装提示做成了可执行的错误信息（apt-get install -y libcairo2 libpango-1.0-0 libpangoft2-1.0-0 libharfbuzz0b），这在同类项目里很少见——它把"环境问题"变成了"可照做的操作指引"。

Windows 用户需要走 WSL，因为辅助脚本是 Bash，而且原生 Windows 下 WeasyPrint 还要另装 GTK/Pango 运行时。

字体授权是硬门槛：中文字体 TsangerJinKai02（仓耳今楷）仅限个人免费使用，商业使用需向 tsanger.cn 申请授权。项目用 ensure-fonts.sh 在仓库检出时把字体复制到本地而非随包分发，正是为了规避这个风险。对企业商用场景而言，这是落地前必须评估的一项。

---

争议与局限：不回避的问题

1. 强绑定单一视觉语言。 Kami 的整套价值建立在"暖米色 + 油墨蓝 + 单一衬线体"这一套语言上。这对个人开发者是优点（省心、成品率高），对需要品牌定制或暗黑主题的团队则是约束。品牌档案能覆盖部分诉求，但无法覆盖"彻底换一套设计语言"的需求。

2. 排版正确 ≠ 内容正确。 所有体检流程检查的是密度、孤行、字体、残留——全是版面指标。数据是否准确、结论是否成立、图表口径是否一致，Kami 不负责，也不该负责。用户若把"通过了 Kami 检查"等同于"报告可信"，是危险的误读。

3. 依赖栈偏重且偏 Linux。 WeasyPrint + PyMuPDF + pypdf + Pygments + python-pptx 全部是可选依赖，装齐后环境体积可观。Windows 原生支持基本不可用，被迫转向 WSL。对只想导出一次 PDF 的用户来说，这是偏重的代价。

4. 作者本人是唯一主导者。 项目贡献者仅 10 人，绝大多数提交来自 tw93 本人。虽然 MIT 协议完全开放，但从工程治理角度看，模板演进节奏与个人审美绑定较强，第三方贡献合并到设计系统核心的路径并不明朗。

5. 日文与韩文属于"尽力而为"。 官方明确表述为"字体回退与版式检查"级别，不如中英文完整。跨语言排版中的字距、行高、标点悬挂问题，仍需要人工目视确认。

6. 模板文件的重复。 仓库里 skills/kami/ 和 plugins/kami/skills/kami/ 两份几乎同构的技能树（为插件分发服务），维护时容易出现两份不同步的风险。

行业意义：AI 输出的竞争正在从"内容"转向"交付"

12,274 个 Star 是个值得玩味的数据。在 AI 编程工具横行的当下，一个不写代码、只管排版的项目能拿到这个量级的关注，说明需求本身是真实存在的。

背后是趋势性的变化：2024-2025 年，AI 工具的竞争焦点是"能不能做"；到 2026 年，能力普遍化了，"做出来好不好看、好不好用、能不能直接交付"就成了区分度所在。AI 生成的 HTML、PDF、PPT 已经多到令人麻木，而"看起来像专业设计过的"和"看起来像默认输出"之间，是一道真实的鸿沟。

Kami 抓住的正是这道鸿沟里的一个具体缝隙：不是重新发明排版，不是做又一个设计系统，而是把审美决策前置成可复用规则，让 Agent 在生成内容的同时自动获得排版品味。

从工程上看，它示范了一条很值得借鉴的路径：把"品味"编码成约束。什么字号、什么行距、什么配色、什么禁止项——全部写成可执行规则、JSON token 和检查脚本。这比"让 AI 自由发挥"要可控得多，也符合当前 Agent 工程从"Prompt 工程"转向"Context 与约束工程"的趋势。

同一作者的三部曲（Kaku 写代码、Waza 练习惯、Kami 出文档）也透露出一种更完整的野心：不只解决某一个环节，而是覆盖"技术工作的完整交付链路"。

---

小结：Kami 用 12K 星证明了一件事——在 AI 能力趋同之后，排版、审美与交付规范本身就是产品。它不是模型，不是框架，而是一套"给 AI 装上设计师经验"的可执行规则库。对个人用户它是一行命令的效率提升，对企业则需要先解决字体商用授权、Windows 环境与日韩语言支持三个现实问题。