DESIGN.md@docs · git:20260319.1e4d509 · 2026-03-19 · sha256 4473b3c15af25e5f

DESIGN.md@docs git:20260319.1e4d509A

Immutable. This exact content is served forever at /api/v1/blob/4473b3c15af25e5f.

# 设计原则

本文档记录 md2wechat-skill 当前采用的设计原则,而不是历史实现草图。

如果你要了解当前模块边界,请优先阅读 [架构说明](ARCHITECTURE.md)。

## 一等目标

这个项目最重要的不是“生成 HTML”,而是:

1. 稳定地产生可发布内容
2. 让失败可观测、可阻断
3. 让 CLI 输出可被自动化稳定消费
4. 让平台差异停留在 adapter 边界

## 设计约束

### 1. 命令层只做命令层的事

`cmd/` 负责:

- 参数解析
- 输入装配
- 输出渲染
- 退出码和 JSON envelope

它不负责业务编排。

### 2. 应用层负责编排

`internal/publish` 负责:

- 发布主流程
- 图片帖子主流程
- 资产处理
- draft 保存与创建流程

### 3. 平台层只负责平台

`internal/draft` / `internal/wechat` 只做:

- 微信草稿结构映射
- 微信 API 调用
- 上传、重试、平台约束

它们不负责 Markdown 解析、图片提取或命令分支判断。

### 4. 图片链必须单一路径

图片是发布主链的硬依赖,所以:

- 本地图
- 网络图
- AI 图

都要通过统一的 `AssetPipeline` 进入发布系统,不能为某个命令维护第二套上传与回填逻辑。

### 5. 文档描述当前事实

文档只描述已实现、已验证、已进入 release 路径的能力。

## 什么时候继续重构

只有满足下列条件之一,才值得继续做更深的架构拆分:

1. 出现第二个正式发布后端
2. `AssetPipeline` 出现跨两个独立业务域的重复逻辑
3. 真实 smoke/staging 暴露出当前边界无法承接的新约束

如果只是为了“更抽象”,当前阶段不应该继续拆。