메뉴
WeWrite 与飞书多维表格的自动化桥接。晨间热点选题入库、审核读取、写作结果回写、数据复盘同步。 触发关键词：选题入库、晨间选题、写作计划同步、文章数据同步、内容看板、wewrite-morning、wewrite-execute。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | wewrite-base |
| description | WeWrite 与飞书多维表格的自动化桥接。晨间热点选题入库、审核读取、写作结果回写、数据复盘同步。 触发关键词：选题入库、晨间选题、写作计划同步、文章数据同步、内容看板、wewrite-morning、wewrite-execute。 |
将 WeWrite 公众号内容生产流程与飞书多维表格打通，形成自动化闭环。
执行本 skill 任何 Op 之前，第一步必须加载飞书配置：
source ~/.claude/skills/wewrite-base/scripts/feishu_config.sh
加载失败时 feishu_config.sh 会打印明确错误指引：
docs/setup-feishu-base.md 创建 config.yamlyq 未安装或版本错 → 用户 brew install yqLLM 行为约束：本 skill 所有 bash 命令依赖环境变量 $WEWRITE_BASE_TOKEN / $WEWRITE_TBL_* 等。如果跳过 source 直接执行 lark-cli 命令，会因为变量为空而失败。不要尝试用字面量 token 替代。
source 成功后，环境中可用：
| 变量 | 含义 | 用途 |
|---|---|---|
WEWRITE_BASE_TOKEN | 多维表格 Base token | 所有 lark-cli 命令的 --base-token |
WEWRITE_BASE_URL | 完整 Base URL | Bot 通知里给用户跳转链接 |
WEWRITE_TBL_TOPICS | 选题候选区表 id | Op1/Op2 读写选题 |
WEWRITE_TBL_PLAN | 今日写作计划表 id | Op2 work queue |
WEWRITE_TBL_OVERVIEW | 文章总览表 id | Op3 数据复盘 |
WEWRITE_TBL_ACCOUNTS | 账号配置表 id | 暂用作展示 |
WEWRITE_USER_OPEN_ID | 飞书 Bot 通知接收人 | 所有 lark-cli im +messages-send 的 --user-id |
# WeWrite 客户映射（飞书 Base "对应账号"字段值 → wewrite 主项目 client slug）
# 这些不是敏感数据，作为代码层映射常量保留
CLIENTS:
AI文森说: winson
赵姐说事儿: zhaojie
# 状态映射（沿用 Base 已有命名）
STATUS_候选区:
热点池: 热点池
待审核: 候选
通过: 已采纳 # 终态前的最后停泊态：审核已通过，等待 Op2 排期+写作
已写作: 已写稿 # 终态：文章已推送到草稿箱
淘汰: 放弃
STATUS_今日写作计划:
待写: 待写
写作中: 写作中
已推送草稿: 已推送草稿
发布失败: 发布失败
# ⚠️ 状态机的核心约定（架构 source of truth）
# 「今日写作计划」是真正的 work queue —— 记录"今天要写的活儿"和"写到哪一步了"
# 「选题候选区」的状态字段只反映审核进度，不反映写作进度（写作进度看 today's plan）
#
# 候选区流转：候选 → 已采纳 → 已写稿（写作成功后顺手回写，仅作展示用途）
# 写作计划流转：待写 → 写作中 → 已推送草稿 ✓
# ↓（失败/中断）
# 发布失败 ──(下次排期重置回待写)──→ 重试
07:30 Op1 用户在 Base 审核 10:00/11:00 Op2 21:00 Op3
热点抓取→选题入库 → [候选→已采纳] → 排期+写作（基于 work queue） → 数据同步
↓ ↓ ↓
选题候选区 今日写作计划+文章总览 文章总览
🔔Bot通知 🔔Bot通知 🔔Bot通知
选题候选区状态机（只管审核进度）：
候选 ──(人工审核)──┐
├──→ 已采纳 ──(写作成功后回写)──→ 已写稿
热点池 ─(人工拉起)─┘
今日写作计划状态机（真正的 work queue）：
待写 ──→ 写作中 ──→ 已推送草稿 ✓
│
└─(失败/中断)──→ 发布失败 ──┬─(重试次数 < 3, 下次执行 reset)──→ 待写（自动重试）
│
└─(重试次数 ≥ 3, 熔断)──→ 待人工处理 🔔
架构关键：中断恢复完全靠「今日写作计划」的状态字段——下次执行时凡是
状态 in [待写, 写作中, 发布失败 且 重试次数<3]的记录都会被重新捡起。不需要 reaper、心跳、超时阈值。
熔断：连续失败 3 次自动停手并 Bot 通知，等待人工介入（典型场景：IP 白名单错配、token 过期、内容审核拒绝）。人工处理后可调用
/wewrite-republish跳过 LLM 直接重推送（见单独 skill）。
/wewrite-morning-topics)wewrite（用于 fetch_hotspots.py 和 topic-selection.md）lark-base（用于 +record-upsert）lark-im（用于 Bot 通知）1. 抓取 TOP 30 热点
python3 {wewrite_dir}/scripts/fetch_hotspots.py --limit 30
解析 JSON 输出，获取 items 数组。
2. 热点池入库（30 条）
将 TOP 30 全部写入「选题候选区」，串行执行，间隔 0.5s：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_TOPICS} \
--json '{
"候选选题": "{item.title}",
"状态": "热点池",
"热点来源": "{item.source}",
"热度分": {normalized_1_10},
"热点URL": "{item.url}"
}'
注意：
对应账号 留空（热点池是账号无关的）热度分 从 hot_normalized(0-100) 转换为 1-10 评分：round(hot_normalized / 10)，最小 1热点来源 映射：微博/今日头条→头条/百度3. 账号匹配选题（每账号 10 条）
对每个客户 (winson→AI文森说, zhaojie→赵姐说事儿)：
a. 读取配置：
读取: {wewrite_dir}/clients/{client}/style.yaml → topics, blacklist, content_style
读取: {wewrite_dir}/clients/{client}/history.yaml → 最近 30 天已写关键词
读取: {wewrite_dir}/references/topic-selection.md → 评分算法
b. LLM 评分：用 topic-selection.md 的三维度算法（热度 30% + 相关度 40% + 切入价值 30%），从 TOP 30 中选出最匹配的 10 个。
c. 逐条写入「选题候选区」：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_TOPICS} \
--json '{
"候选选题": "{推荐标题，20-28字}",
"对应账号": "{AI文森说 或 赵姐说事儿}",
"状态": "候选",
"热点来源": "{source}",
"匹配度评分": {总分，1-10},
"热度分": {热度分},
"相关度分": {相关度分},
"切入角度": "{1-2句切入角度描述}",
"推荐框架": "{痛点型/故事型/清单型/对比型/热点解读型}",
"热点URL": "{url}"
}'
4. Bot 通知
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**WeWrite 晨间选题已入库**\n\n- AI文森说：{n1} 条候选\n- 赵姐说事儿：{n2} 条候选\n- 热点池：{n3} 条 TOP 热点\n\n请在[多维表格](${WEWRITE_BASE_URL}?table=${WEWRITE_TBL_TOPICS})中审核\n\n操作方式：\n- AI 推荐 → 将「候选」改为「已采纳」\n- 热点池自选 → 将「热点池」改为「已采纳」+ 填对应账号"
/wewrite-execute)wewritelark-baselark-im两段式：先排期、后写作。彻底解耦"哪些选题该写"和"写到哪一步了"：
已采纳 的选题登记到「今日写作计划」（幂等）中断/失败的选题不需要回退候选区状态——下次执行时凭「今日写作计划」自己的状态字段就能找回来。
把今天审核通过的选题登记到「今日写作计划」。重复执行不会产生副作用。
A.1 读取候选区今日已采纳记录
lark-cli base +record-list \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_TOPICS} \
--limit 200
筛选 状态 == "已采纳" 且 创建时间 为今天的记录。
A.2 读取「今日写作计划」今日全部记录
lark-cli base +record-list \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--limit 200
筛选 计划日期 为今天的记录，按 选题记录ID 建立索引（用作下面的去重 + reset key）。
A.3 对每条已采纳选题，决定建表/重置/跳过/熔断
「今日写作计划」中是否已有同 选题记录ID 的记录 | 该记录的「写作状态」 + 重试次数 | 动作 |
|---|---|---|
| 没有 | — | 创建新记录（写作状态: 待写, 重试次数: 0） |
| 有 | 已推送草稿 | 跳过（已完成） |
| 有 | 待写 / 写作中 | 跳过（Step B 会自然捡起来重写） |
| 有 | 发布失败 且 重试次数 < 3 | 重置为待写（in-place 重置，不创建新记录） |
| 有 | 发布失败 且 重试次数 ≥ 3 | 熔断：跳过自动重试，发 Bot 通知人工介入 |
创建：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--json '{
"计划日期": {今天的毫秒时间戳},
"选题标题": "{候选选题}",
"对应账号": "{对应账号}",
"写作状态": "待写",
"框架类型": "{推荐框架}",
"选题记录ID": "{选题候选区的 record_id}",
"重试次数": 0
}'
重置（仅当现状是「发布失败」且 重试次数 < 3）：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--record-id {plan_record_id} \
--json '{"写作状态": "待写", "发布结果": "", "备注": "第 {N} 次重试"}'
注意：重置时不清零重试次数——计数器累计是熔断的依据。
熔断（发布失败 且 重试次数 ≥ 3）：
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**⚠️ 选题已熔断，需人工介入**\n\n- 标题：《{选题标题}》\n- 账号：{对应账号}\n- 已连续失败：{重试次数} 次\n- 最近错误：{备注}\n\n常见原因：IP 白名单错配 / token 过期 / 内容被微信审核拒绝。\n\n建议处理：\n1. 排查根因（更新公众号后台 IP 白名单 / 重新拉 token / 调整文章内容）\n2. 调用 `/wewrite-republish` 跳过 LLM 直接重试推送（不消耗 LLM 调用）\n3. 或在 Base 中手动把「重试次数」清零，让 /wewrite-execute 下次重新尝试"
注意：这一阶段不修改「选题候选区」的状态字段——候选区状态只反映审核进度，不反映写作进度。
B.0 读取今日待办
lark-cli base +record-list \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--limit 200
筛选 计划日期 为今天 且 写作状态 in ["待写", "写作中"] 的记录。
「写作中」也要捡起来：那是上次中断留下的，对系统来说"待写"和"写作中"是同一回事——都从头重新写。
无可写项 → 发送 Bot 提醒：
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**今日尚无审核通过的选题**\n\n两种方式选题：\n- 从 AI 推荐中选 → 将「候选」改为「已采纳」\n- 从热点池自选 → 将「热点池」改为「已采纳」+ 填对应账号\n\n11:00 会自动重新检查。\n[前往多维表格](${WEWRITE_BASE_URL}?table=${WEWRITE_TBL_TOPICS})"
11:00 重试仍无 → 发送最终通知：
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**今日写作已跳过**\n\n11:00 重新检查仍无审核通过的选题，今日不发文。\n如需补发，随时手动执行 /wewrite-execute。"
有可写项 → 对每条记录依次进入 B.1 - B.7。
B.1 补全缺失字段（来自热点池的人工选题）
如果该选题对应的候选区记录 切入角度 或 推荐框架 为空：
B.2 标记开始写作
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--record-id {plan_record_id} \
--json '{"写作状态": "写作中"}'
B.3 执行 WeWrite 主管道
执行前记录开始时间戳（用于产物定位）：
SCAN_START=$(date +%s)
WEWRITE_OUTPUT_DIR="$HOME/.claude/skills/wewrite/output/{client}" # client = winson 或 zhaojie
调用 WeWrite skill 的 Step 1-8：
wewrite/references/visual-prompts.md 第二节（## 二、内文配图）。批量调用 toolkit/image_gen.py --size article 生成图片，把图片相对路径写进 markdown 的对应段落后（用  语法）。B.3.5 定位本次产物路径（无论成功失败都要做）
WeWrite Step 4.4 会把 markdown 落盘到 output/{client}/{date}-{slug}.md，Step 6 把封面落盘到 output/{client}/{date}-{slug}-cover.{jpg,png}。即便 Step 7 推送失败，本地产物也已存在——这是 /wewrite-republish 跳过 LLM 重推送的关键依据。
# 找 SCAN_START 之后修改的 markdown（排除 .publish.md）
MARKDOWN_PATH=$(find "$WEWRITE_OUTPUT_DIR" -name "*.md" ! -name "*.publish.md" -newermt "@$SCAN_START" 2>/dev/null | head -1)
# 同 slug 的 cover（jpg/png 都尝试）
SLUG=$(basename "$MARKDOWN_PATH" .md)
COVER_PATH=$(ls "$WEWRITE_OUTPUT_DIR"/"$SLUG"-cover.* 2>/dev/null | head -1)
# theme 从 client style.yaml 读
THEME=$(grep '^theme:' "$HOME/.claude/skills/wewrite/clients/{client}/style.yaml" | awk '{print $2}')
# title / digest 从 markdown 第一行 H1 + 摘要 frontmatter（如有）解析
预先回写「今日写作计划」（即使后面推送失败，路径也已落库可供重推）：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--record-id {plan_record_id} \
--json "{
\"markdown路径\": \"${MARKDOWN_PATH}\",
\"封面图路径\": \"${COVER_PATH}\",
\"主题\": \"${THEME}\",
\"摘要\": \"${DIGEST}\",
\"文章标题\": \"${TITLE}\"
}"
找不到 markdown（极少见，可能是 Step 4 LLM 失败连产物都没生成）→ 留空，
/wewrite-republish看到空字段会跳过该条并提示从头重跑。
B.4 写作成功后回写
a. 更新「今日写作计划」为终态：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--record-id {plan_record_id} \
--json '{
"写作状态": "已推送草稿",
"media_id": "{media_id}",
"发布结果": "成功"
}'
b. 顺手更新候选区状态为「已写稿」（仅作展示用途，让候选区也能一眼看出结局）：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_TOPICS} \
--record-id {topic_record_id} \
--json '{"状态": "已写稿"}'
这一步即使失败也不影响系统正确性——「今日写作计划」已经是终态，候选区只是展示。
c. 创建「文章总览」记录：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_OVERVIEW} \
--json '{
"标题": "{文章标题}",
"对应账号": "{账号}",
"推送日期": {今天的毫秒时间戳},
"框架类型": "{框架}",
"media_id": "{media_id}",
"选题关键词": "{keyword1, keyword2}",
"选题来源": "热点抓取",
"字数": {word_count},
"写作维度": "{维度1; 维度2}"
}'
记录返回的 record_id，额外写入 WeWrite 的 history.yaml 中作为 base_record_id。
B.5 Bot 通知（每篇完成后）
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**文章已发布到草稿箱**\n\n- 标题：《{title}》\n- 账号：{account}\n- 框架：{framework}\n- 字数：{word_count}\n- media_id：`{media_id}`\n\n请前往公众号后台检查并定时发布。"
B.6 发布失败处理
候选区状态保持「已采纳」不动。「今日写作计划」标记为"发布失败" + 重试次数 +1。
下次 Step A 排期：
重试次数 < 3 → 自动 reset 为"待写"重试（在第 N+1 次执行时跑）重试次数 ≥ 3 → 熔断，发 Bot 通知人工介入# a. 读当前重试次数
CURRENT_RETRY=$(lark-cli base +record-list \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--filter "record_id = '{plan_record_id}'" \
--fields "重试次数" --limit 1 | jq '.records[0].fields.重试次数 // 0')
NEW_RETRY=$((CURRENT_RETRY + 1))
# b. 更新写作计划（状态 + 重试次数 + 错误信息）
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--record-id {plan_record_id} \
--json "{\"写作状态\": \"发布失败\", \"发布结果\": \"失败\", \"备注\": \"{error}\", \"重试次数\": ${NEW_RETRY}}"
# c. Bot 通知（区分是否已熔断）
if [ "$NEW_RETRY" -lt 3 ]; then
MSG="**文章发布失败**\n\n- 标题：《{title}》\n- 账号：{account}\n- 原因：{error}\n- 已失败：${NEW_RETRY}/3 次\n- 降级：已生成本地 HTML 预览\n- 下次执行 /wewrite-execute 会自动重试（写作计划重置为待写）"
else
MSG="**⚠️ 文章已熔断（连续失败 ${NEW_RETRY} 次）**\n\n- 标题：《{title}》\n- 账号：{account}\n- 原因：{error}\n- 不再自动重试。请人工排查后调用 /wewrite-republish 重推送，或在 Base 中清零「重试次数」"
fi
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "$MSG"
B.7 中断恢复说明
如果 WeWrite 主管道中途被 kill / 网络断 / 进程崩溃，"写作中"状态留在「今日写作计划」里。下次 /wewrite-execute：
状态 in [待写, 写作中]，捡起来重新走 B.1-B.5注意：极小概率下中断发生在"草稿已推送到公众号 + 回写 base 失败"的窗口内，会导致重复推送一份草稿。当前设计接受这个成本——你可以在公众号后台手动删除重复草稿。
B.8 今日写作汇总通知
全部写作完成后发送汇总：
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**今日写作完成**\n\n| 账号 | 标题 | 状态 |\n|------|------|------|\n{逐行填充}\n\n共 {n} 篇已推送到草稿箱。\n[查看写作计划](${WEWRITE_BASE_URL}?table=${WEWRITE_TBL_PLAN})"
用途：解决批量写作时 LLM 上下文累积导致的质量漂移。每篇文章用独立 claude -p 调用、独立会话、独立 1M context，永远满血。
触发条件：调度方在 prompt 中显式声明"单条模式 + plan_record_id=XXX"。
与默认模式的差别：
| 行为 | 默认模式（B.0 - B.8） | 单条模式（B.9） |
|---|---|---|
| Step A 排期 | 执行（扫候选区已采纳记录登记到写作计划） | 跳过（调度方已确保排期完成） |
| B.0 列出待办 | 读「今日写作计划」状态 in [待写, 写作中] | 跳过（直接处理传入的 plan_record_id） |
| B.1 - B.6 单篇逻辑 | 对每条循环执行 | 只对一条执行 |
| B.5 Bot 通知 | 每篇完成后发 | 不发（避免 N 篇 N 条 Bot 噪音） |
| B.6 失败 Bot 通知 | 立即发 | 仍发（调度方需要立即知道失败） |
| B.8 汇总通知 | 全部完成后发 | 不发（汇总由调度方最后统一发） |
执行流程（外部传入 plan_record_id 后）：
用 lark-cli base +record-get --record-id {plan_record_id} 读取该记录，确认 写作状态 in [待写, 写作中] 且 计划日期 == 今天。其它状态拒绝执行（返回错误，让调度方决定下一步）。
从记录拿到关联字段：
选题记录ID → 用于读候选区记录、补全字段、最终回写候选区"已写稿"选题标题、对应账号、框架类型、推荐框架 → 主管道入参严格按 B.1 → B.2 → B.3 → B.3.5 → B.4 / B.6 流程跑：
不发 B.5 / B.8 通知。失败时仍发 B.6 通知（让用户立即知道）。
跑完即退出。退出码：成功 0 / 失败 1 / 拒绝执行（状态不对/记录不存在）2。
调度方约定：
调度方（如 lifeos-wewrite-execute bash 脚本）的职责：
claude -p 调用单条模式claude -p 发汇总通知（B.8）这样每条文章的 LLM 会话上下文 ≈ 60K 基础 + 30-50K 单篇产出 = 80-100K（远低于 200K 警戒线，质量满血）。
/wewrite-sync-stats)wewrite（用于 fetch_stats.py）lark-baselark-im1. 拉取数据
python3 {wewrite_dir}/scripts/fetch_stats.py --client winson --days 3
python3 {wewrite_dir}/scripts/fetch_stats.py --client zhaojie --days 3
2. 读取更新后的 history.yaml
找到有 stats 字段的条目。
3. 匹配并更新「文章总览」
优先按 media_id 匹配（精确），其次按 base_record_id 匹配：
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_OVERVIEW} \
--record-id {record_id} \
--json '{
"阅读量": {reads},
"分享量": {shares},
"点赞量": {likes},
"阅读率": {read_rate}
}'
4. Bot 通知（可选）
lark-cli im +messages-send --as bot \
--user-id ${WEWRITE_USER_OPEN_ID} \
--markdown "**文章数据已更新**\n\n{有数据变动的文章列表}\n\n[查看文章总览](${WEWRITE_BASE_URL}?table=${WEWRITE_TBL_OVERVIEW})"
/wewrite-retro)lark-basewewrite（用于 effect-review.md）+data-query 聚合分析「文章总览」{wewrite_dir}/references/effect-review.md 执行深度分析| 时间 | 操作 | 命令 |
|---|---|---|
| 07:30 | 晨间选题入库 | /wewrite-morning-topics |
| 10:00 | 写作执行（首次检查） | /wewrite-execute |
| 11:00 | 写作执行（重试） | /wewrite-execute --retry |
| 21:00 | 数据同步 | /wewrite-sync-stats |
+record-upsert 串行执行，批次间延迟 0.5s+record-list 的 --limit 最大 200，超出需分页本 skill 依赖以下飞书 Base 字段，缺失需在 Base 中先补齐：
| 字段 | 类型 | 说明 |
|---|---|---|
| 计划日期 | 日期 | 今天 |
| 选题标题 | 单行文本 | 复制自候选区 |
| 对应账号 | 单选 | AI文森说 / 赵姐说事儿 |
| 写作状态 | 单选 | 待写 / 写作中 / 已推送草稿 / 发布失败 |
| 框架类型 | 单选 | 痛点型 / 故事型 / 清单型 / 对比型 / 热点解读型 |
| 选题记录ID | 单行文本 | 候选区的 record_id（用作幂等 key） |
| 重试次数 | 数字 | 默认 0，每次发布失败 +1，≥3 触发熔断 |
| markdown路径 | 单行文本 | WeWrite Step 4 落盘的 .md 绝对路径（B.3.5 回写） |
| 封面图路径 | 单行文本 | WeWrite Step 6 落盘的封面图绝对路径（B.3.5 回写） |
| 主题 | 单行文本 | publish 命令的 --theme 参数 |
| 摘要 | 单行文本 | publish 命令的 --digest 参数 |
| 文章标题 | 单行文本 | publish 命令的 --title 参数 |
| media_id | 单行文本 | 写作成功后回写 |
| 发布结果 | 单行文本 | 成功 / 失败 |
| 备注 | 单行文本 | 错误信息或重试备注 |
「状态」字段需包含选项：热点池 / 候选 / 已采纳 / 已写稿 / 放弃。
（不再需要"已排期"——之前讨论中加过的话可以删除。）
/wewrite-republish（待创建）：手动重试推送失败的文章。读取「今日写作计划」中 写作状态==发布失败 的记录，根据"对应账号 + 选题标题"在 wewrite output/ 目录定位 markdown，调用 cli.py publish 跳过 LLM 直接重推送。适用于 IP 白名单更新后批量补推送场景。