2026-07-01 Md-Render：资产优先与业务编排原则
- 性质：对话沉淀为可复用 Q&A
- 日期：2026-07-01
- 项目上下文：md-render Markdown 编辑器 / 内容工作台
- 关键词：资产模型、业务编排、provenance、派生版本、低耦合、可复用
问题
md-render 后续改功能时，如何避免「多做几个页面入口」却越改越耦合？怎样把长期有价值的东西沉淀成可复用资产，并让业务流程尽量只组合资产，而不是互相写死？
回答
目标不是堆功能入口，而是资产是核心、业务是编排层：各工作流消费资产、生成资产、关联资产，而不是把数据锁死在某个页面里。
落地原则
资产是核心
文档、图片、摘录、知识库条目、模板、发布配置、Daily 记录、Agent 产物等，应尽量有独立身份、元数据、来源和引用关系。业务是编排层
「写公众号」「做选题」「整理知识库」「发布到平台」等工作流，应消费 / 生成 / 关联资产，而不是在页面内部维护私有数据结构。保留原稿
平台化生成、改写、摘要、发布稿等，优先生成新资产或派生版本，不直接覆盖源文档。模块低耦合
组件不直接跨模块读写内部结构；尽量通过 store action、utils/service、IPC client 等稳定边界交互。来源可追溯
导入、剪藏、AI 生成、手写、同步来的内容，都要能追到source/provenance，便于搜索、复用、去重与同步。不过度设计
先把资产边界、字段和调用链理清，用小函数和现有模式落地；不提前上复杂插件架构。
改需求时的五类判断
以后改 md-render，优先判断新需求属于哪一类，避免把「某个页面的需求」写成全局耦合逻辑：
| 类型 | 含义 | 例子 |
|---|---|---|
| 1. 新资产类型 | 需要独立身份与元数据的新实体 | 摘录、Daily 条目、发布配置 |
| 2. 资产加工动作 | 对已有资产做非破坏性变换 | 摘要、改写、派生版本、关联 |
| 3. 业务视图 / 工作流 | 组合多个资产的 UI 或流程 | 写公众号、选题面板、知识库整理 |
| 4. 外部来源导入 | 把外部内容变成带 provenance 的资产 | 剪藏、同步、文件导入 |
| 5. 发布 / 同步适配器 | 把资产推到外部平台或格式 | 公众号发布、RSS、导出 |
决策口诀：先问「这是新资产、加工、视图、导入还是发布？」——只有答案清楚，再动代码。
与现有实现的衔接
- 关联文档召回、元数据面板等已有能力，应继续走稳定 service 边界（如
contextRecall.js），而不是在 UI 组件里复制排序 / 抽词逻辑。 - 检索与关联是资产引用关系的一种；后续若上 FTS5 或 embedding，仍应挂在资产层，而不是绑死在某个业务页。
- Agent 产物、发布稿、摘要等，默认写入派生资产；源文档只读或显式版本化。
核心启示
页面是工作流的壳，资产才是系统 of record。业务只编排，不私藏数据；加工只派生，不覆盖原稿。
另见
- 关联文档搜索能不用向量 embedding 吗（md-render 关联文档召回与 service 边界）
- SQLite FTS5 是什么，文档检索什么时候用它（资产检索升级路径）
- 编译式知识库（provenance、结构化知识层）
- 关键词重合召回（轻量关联，不绑页面）
- 微前端与 Monorepo（模块边界与低耦合选型，概念可类比）
维护：Cursor Agent，2026-07-01。