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 暴露出当前边界无法承接的新约束 如果只是为了“更抽象”,当前阶段不应该继续拆。