这一篇目标： 把你的 Markdown 变成一套可发布、可浏览、可回填链接的最小服务。

核心闭环：

Markdown -> publish CLI -> share API -> R2
                  │
                  └-> 图片上传到 img API -> R2(img)

---

先说“最小功能清单”

你只需要先实现这 8 个功能：

1. POST /api/publish（带 API key）
2. GET /api/articles
3. GET /api/articles/:slug
4. DELETE /api/articles/:slug
5. GET /（首页）
6. GET /c/:category（分类）
7. GET /:slug（文章）
8. POST /upload（图片上传）

这就是 Mom 的文章/笔记/share 服务最核心骨架。

---

第 0 步：目录结构

mini-mom/
├── tools/
│   └── publish.ts
└── workers/
    ├── shared/
    │   ├── auth.ts
    │   └── r2.ts
    ├── img/
    │   ├── src/index.ts
    │   └── wrangler.toml
    └── share/
        ├── src/index.ts
        ├── src/markdown.ts
        ├── src/render.ts
        └── wrangler.toml

---

第 1 步：先复用，再精简（最快路径）

如果你要最快复刻，不建议从空白手写。

建议直接把这几份文件作为起点：

• workers/shared/auth.ts
• workers/shared/r2.ts
• workers/img/src/index.ts
• workers/share/src/index.ts
• workers/share/src/markdown.ts
• workers/share/src/render.ts
• tools/share.ts（你自己的 mini 版可先删减）

你可以先“整包跑通”，再删成你自己的最小版本。

---

第 2 步：关键配置

workers/share/wrangler.toml（示例）：

name = "mini-share-worker"
main = "src/index.ts"
compatibility_date = "2024-01-01"

[vars]
PUBLIC_URL = "https://s.example.com"
IMG_URL = "https://img.example.com"

<span class="private-link" title="未发布的笔记">r2_buckets</span>
binding = "BUCKET"
bucket_name = "mini-share"

workers/img/wrangler.toml（示例）：

name = "mini-img-worker"
main = "src/index.ts"
compatibility_date = "2024-01-01"

[vars]
PUBLIC_URL = "https://img.example.com"

<span class="private-link" title="未发布的笔记">r2_buckets</span>
binding = "BUCKET"
bucket_name = "mini-img"

再设置密钥：

cd workers/img && wrangler secret put API_KEY
cd ../share && wrangler secret put API_KEY

---

第 3 步：发布 CLI（mini 版思路）

tools/publish.ts 最小流程：

1. 读本地 markdown
2. 解析 frontmatter（title/slug/category/tags）
3. 扫描图片并上传 img /upload
4. 替换图片为公网 URL
5. 调 share /api/publish
6. 回填 share_url

你不一定要一步做到智能封面、AI 脱敏。 先把“可发布 + 可访问 + 可回填”跑通，再迭代。

---

第 4 步：数据结构约定（一定要先定）

文章对象建议固定：

{
  "slug": "my-article",
  "title": "My Article",
  "category": "技术",
  "tags": ["workflow", "ai"],
  "coverImage": "https://img.example.com/xxx.webp",
  "content": "# markdown...",
  "html": "<h1>...</h1>",
  "publishedAt": "2026-02-09T10:00:00.000Z",
  "updatedAt": "2026-02-09T10:00:00.000Z"
}

R2 索引建议：

articles/<slug>.json
index/all.json
index/c-<category>.json

这个约定一旦定下来，前后端和 CLI 都会轻松很多。

---

第 5 步：验收命令（必须真跑）

发布一篇：

curl -X POST https://s.example.com/api/publish \
  -H "Authorization: Bearer <API_KEY>" \
  -H "Content-Type: application/json" \
  -d '{
    "slug":"hello-mini-mom",
    "title":"Hello Mini Mom",
    "category":"技术",
    "tags":["mini-mom"],
    "content":"# Hello\n\nThis is my first article."
  }'

列表验证：

curl https://s.example.com/api/articles

页面验证：

open https://s.example.com/hello-mini-mom

如果这三步通过，你的 share 分身就已经能用了。

---

你后续可以按这个顺序加能力

1. 发布前脱敏（规则 + AI）
2. 专栏封面自动生成（smart/never/always）
3. /admin 管理页
4. share-to-x 分发草稿

别一上来全开。 先保证“每天稳定发一篇”，比“功能很多但常坏”值钱得多。

---

系列收尾：你现在拥有了什么

• 一个可复刻的内容链路架构
• 一套明确的目录、配置和接口边界
• 一个可迭代的 Mini Mom 分身（只做内容工作流）

从这里开始，你可以按自己的习惯扩成：

• 团队版
• 多人协作版
• 完全私有版

核心都一样： Capture -> Publish -> Serve。