问题：产出多，发布少
作为程序员和管理者，我每天产生大量的"可对外分享的东西"：
- 技术决策和架构设计
- 工具实践和踩坑经验
- 管理方法论和流程设计
- 代码库和开源项目
但实际对外发布的比例不到 5%。
不是因为懒——是因为从"私域产出"到"公域内容"之间有一条鸿沟：
- 脱敏（去掉公司名、人名、项目名）
- 适配（不同平台格式不同）
- 排期（什么时候发、发在哪）
- 追踪（发了之后效果如何）
每一步都是手工操作，摩擦巨大。
Content Atom：核心抽象
我设计 dese 的第一步是定义核心数据模型——Content Atom（内容原子）。
Content Atom 是最小可发布单元——从一次技术决策、一段会议讨论、一个代码提交中提取出来的、经过角度标注和隐私标记的内容种子。
它不是成品文章——它是文章的原料。一个 atom 可以：
- 独立发展为一篇文章
- 和其他 atom 组合为系列
- 适配为不同平台的不同格式（掘金长文 vs 小红书图文卡片）
管线架构
6 个阶段各自独立：
| 阶段 | 输入 | 输出 | 自动化程度 |
|---|---|---|---|
| Source | 私域系统 | 原始数据流 | 全自动 |
| Extract | 原始数据 | Content Atoms | AI + 人工确认 |
| Atom Store | atoms | 结构化存储 | 全自动 |
| Adapt | atom + 平台画像 | 适配后内容 | AI 草稿 + 人工审核 |
| Publish | 终稿 | 已发布内容 | 半自动（一键发布） |
| Track | 发布记录 | 效果指标 | 全自动 |
关键设计：Review Gate
在 Adapt → Publish 之间有一个人工审核门。
这不是"可选的"——是强制的。
原因：脱敏判断不能完全交给 AI。AI 可以做初步标记（"这里提到了公司名"），但最终"这个内容能不能对外"必须人来判断。
三阶段运营模型
dese 不是一步到位的——它有成长路径：
| 阶段 | 目标 | 内容来源 |
|---|---|---|
| Stage 1: 行为运营 | 从日常行为中提取内容 | 日总结/会议/聊天/代码 |
| Stage 2: 产物运营 | 主动创作有策略的内容 | 项目/教程/系列文章 |
| Stage 3: 战略运营 | 影响力矩阵管理 | 品牌/人设/受众分析 |
当前重心在 Stage 1——把每天已经在做的事自动转化为可发布内容。这是摩擦最低的起步点。
隐私即一等公民
dese 的核心设计约束是 privacy-by-default：
privacy:
risk: medium
sensitive_refs:
- "某项目名" → "某设计系统框架"
- "公司名" → "某新能源车企"
needs_transform: true
transform_hints:
- generalize: "将公司特定架构泛化为通用模式"
- strip: "移除内部人名"每个 Content Atom 在提取时就带有隐私标记。隐私风险分三级：
- low: 技术通用知识，直接可发布
- medium: 需要脱敏（替换公司名/人名/项目名）
- high: 需要深度改写或放弃发布
技术选型
| 选择 | 原因 |
|---|---|
| Python CLI | 本地工具，不需要服务器 |
| YAML 数据 | 可 git、可 grep、可人工编辑 |
| 本地 git | 版本追踪 + 备份，无外部依赖 |
| 无数据库 | 简单——YAML 文件就是数据库 |
| AI 辅助 | 提取和适配用 AI，审核用人 |
核心理念: 系统和敏感数据全部留在本地。远程（GitHub/发布平台）只有脱敏后的终稿。
总结：个人影响力的瓶颈不是"没东西可写"——是"从有到发"的摩擦太大。dese 的管线架构把这个摩擦拆解为 6 个可优化的阶段，用 Content Atom 作为中间表示，让 AI 处理机械环节、人专注于创意和审核。