Menu
WeWrite 与飞书多维表格的自动化桥接。晨间热点选题入库、审核读取、写作结果回写、数据复盘同步。 触发关键词：选题入库、晨间选题、写作计划同步、文章数据同步、内容看板、wewrite-morning、wewrite-execute。
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
| 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 白名单更新后批量补推送场景。