| name | wewrite-base |
| description | WeWrite 与飞书多维表格的自动化桥接。晨间热点选题入库、审核读取、写作结果回写、数据复盘同步。
触发关键词:选题入库、晨间选题、写作计划同步、文章数据同步、内容看板、wewrite-morning、wewrite-execute。
|
WeWrite-Base 桥接 Skill
将 WeWrite 公众号内容生产流程与飞书多维表格打通,形成自动化闭环。
⚠️ 前置:必须执行(不可跳过)
执行本 skill 任何 Op 之前,第一步必须加载飞书配置:
source ~/.claude/skills/wewrite-base/scripts/feishu_config.sh
加载失败时 feishu_config.sh 会打印明确错误指引:
- 配置文件不存在 → 用户按
docs/setup-feishu-base.md 创建 config.yaml
yq 未安装或版本错 → 用户 brew install yq
- 配置字段为空或 null → 用户回到 config.yaml 填入对应字段
LLM 行为约束:本 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 |
常量(非敏感)
CLIENTS:
AI文森说: winson
赵姐说事儿: zhaojie
STATUS_候选区:
热点池: 热点池
待审核: 候选
通过: 已采纳
已写作: 已写稿
淘汰: 放弃
STATUS_今日写作计划:
待写: 待写
写作中: 写作中
已推送草稿: 已推送草稿
发布失败: 发布失败
工作流全景
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)。
Op1: 晨间选题入库 (/wewrite-morning-topics)
前置
- 加载 skill:
wewrite(用于 fetch_hotspots.py 和 topic-selection.md)
- 加载 skill:
lark-base(用于 +record-upsert)
- 加载 skill:
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- 热点池自选 → 将「热点池」改为「已采纳」+ 填对应账号"
Op2: 审核同步 + 写作执行 (/wewrite-execute)
前置
- 加载 skill:
wewrite
- 加载 skill:
lark-base
- 加载 skill:
lark-im
设计要点
两段式:先排期、后写作。彻底解耦"哪些选题该写"和"写到哪一步了":
- Step A 排期:把候选区里
已采纳 的选题登记到「今日写作计划」(幂等)
- Step B 执行:基于「今日写作计划」状态字段决定写谁,这是中断恢复的核心
中断/失败的选题不需要回退候选区状态——下次执行时凭「今日写作计划」自己的状态字段就能找回来。
Step A — 排期同步(幂等)
把今天审核通过的选题登记到「今日写作计划」。重复执行不会产生副作用。
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 下次重新尝试"
注意:这一阶段不修改「选题候选区」的状态字段——候选区状态只反映审核进度,不反映写作进度。
Step B — 写作执行
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 补全缺失字段(来自热点池的人工选题)
如果该选题对应的候选区记录 切入角度 或 推荐框架 为空:
- 加载对应客户的 style.yaml
- LLM 补全切入角度和推荐框架
- 回写到候选区记录(写作计划记录的「框架类型」如已填则同步更新)
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}"
调用 WeWrite skill 的 Step 1-8:
- 客户映射:AI文森说 → winson, 赵姐说事儿 → zhaojie
- 选题由 Base 提供,跳过 WeWrite 自带的选题步骤(Step 2)
- ⚠️ 必须完整执行 Step 6 全部子步骤(6.1 实体提取 → 6.2 封面生成 → 6.3 封面验证 → 6.4 内文配图 3-6 张)。Step 6.4 内文配图是质量必备项,禁止以"全自动模式应该简化"为由跳过。封面生成完毕后必须继续 6.4,不能直接跳到 Step 7。
- 6.4 内文配图的执行依据是
wewrite/references/visual-prompts.md 第二节(## 二、内文配图)。批量调用 toolkit/image_gen.py --size article 生成图片,把图片相对路径写进 markdown 的对应段落后(用  语法)。
- 推送前确认 markdown 包含 ≥3 张内嵌图引用,否则视为 Step 6.4 未完成,回去补。
- 框架由 Base 的「推荐框架」指定
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 重推送的关键依据。
MARKDOWN_PATH=$(find "$WEWRITE_OUTPUT_DIR" -name "*.md" ! -name "*.publish.md" -newermt "@$SCAN_START" 2>/dev/null | head -1)
SLUG=$(basename "$MARKDOWN_PATH" .md)
COVER_PATH=$(ls "$WEWRITE_OUTPUT_DIR"/"$SLUG"-cover.* 2>/dev/null | head -1)
THEME=$(grep '^theme:' "$HOME/.claude/skills/wewrite/clients/{client}/style.yaml" | awk '{print $2}')
预先回写「今日写作计划」(即使后面推送失败,路径也已落库可供重推):
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 通知人工介入
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))
lark-cli base +record-upsert \
--base-token ${WEWRITE_BASE_TOKEN} \
--table-id ${WEWRITE_TBL_PLAN} \
--record-id {plan_record_id} \
--json "{\"写作状态\": \"发布失败\", \"发布结果\": \"失败\", \"备注\": \"{error}\", \"重试次数\": ${NEW_RETRY}}"
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:
- Step A 看到该记录已存在且状态==写作中,跳过创建(幂等保证)
- Step B 看到
状态 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})"
B.9 单条模式(外部调度入口)
用途:解决批量写作时 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 流程跑:
- 成功:写作计划状态终态为「已推送草稿」、候选区状态终态为「已写稿」、文章总览创建一条新记录
- 失败:写作计划标记「发布失败」+ 重试次数 +1、候选区状态保持「已采纳」不动
-
不发 B.5 / B.8 通知。失败时仍发 B.6 通知(让用户立即知道)。
-
跑完即退出。退出码:成功 0 / 失败 1 / 拒绝执行(状态不对/记录不存在)2。
调度方约定:
调度方(如 lifeos-wewrite-execute bash 脚本)的职责:
- 完成 Step A 排期(调度脚本自己用 lark-cli 排期,或先调一次默认模式只跑 Step A)
- 列出今日「待写 / 写作中 / 发布失败 且 重试次数<3」的记录
- 对每条启动一个独立
claude -p 调用单条模式
- 全部循环完成后启动一个独立
claude -p 发汇总通知(B.8)
这样每条文章的 LLM 会话上下文 ≈ 60K 基础 + 30-50K 单篇产出 = 80-100K(远低于 200K 警戒线,质量满血)。
Op3: 数据复盘同步 (/wewrite-sync-stats)
前置
- 加载 skill:
wewrite(用于 fetch_stats.py)
- 加载 skill:
lark-base
- 加载 skill:
lark-im
步骤
1. 拉取数据
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})"
Op4: 复盘报告 (/wewrite-retro)
前置
- 加载 skill:
lark-base
- 加载 skill:
wewrite(用于 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,超出需分页
- datetime 字段写入时使用毫秒时间戳
- select 字段写入时使用选项名称字符串
- 热点池记录不删除,用于历史参考;可通过视图筛选只看今天的
Base Schema 依赖
本 skill 依赖以下飞书 Base 字段,缺失需在 Base 中先补齐:
「今日写作计划」表(${WEWRITE_TBL_PLAN})
| 字段 | 类型 | 说明 |
|---|
| 计划日期 | 日期 | 今天 |
| 选题标题 | 单行文本 | 复制自候选区 |
| 对应账号 | 单选 | 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_TBL_TOPICS})
「状态」字段需包含选项:热点池 / 候选 / 已采纳 / 已写稿 / 放弃。
(不再需要"已排期"——之前讨论中加过的话可以删除。)
关联 skill
/wewrite-republish(待创建):手动重试推送失败的文章。读取「今日写作计划」中 写作状态==发布失败 的记录,根据"对应账号 + 选题标题"在 wewrite output/ 目录定位 markdown,调用 cli.py publish 跳过 LLM 直接重推送。适用于 IP 白名单更新后批量补推送场景。