# Qbit Academic Submission

> Process academic投稿/学术投稿 materials into the Scholar Feishu Base SOP. Use when the user gives an academic manuscript, Word/docx file, author name, institution, paper/project description, conference info, Feishu群聊消息/@机器人上下文, or later provides a WeChat article link to match and write back to the投稿Base.

- Skill: `imtangyujing/qbit-academic-submission` (Agent Skill, multi-file: 3 files)
- Install (CLI): `npx skillmds@latest add imtangyujing/qbit-academic-submission`
- Raw SKILL.md: https://api.skillmd.com/api/skills/imtangyujing/qbit-academic-submission/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Docs & Writing
- Author: imtangyujing (https://skillmd.com/u/imtangyujing)
- Updated: 2026-09-21
- Page: https://skillmd.com/skills/imtangyujing/qbit-academic-submission

---


# Academic Submission SOP

## Purpose

把用户在Codex对话里给出的学术投稿信息和Word稿件整理进Scholar投稿Base。默认目标是最小可用流程：建记录、提取字段、上传附件、后续回填微信链接。

涉及Base读写时，先使用`lark-base`skill并遵守其reference。涉及docx内容提取时，可直接读取`word/document.xml`或使用本地文档工具。

后续如果入口来自飞书群聊，优先复用现有机器人做demo；不要默认要求新建机器人。

## Base Target

默认Base信息见`references/base-schema.md`。除非用户另给Base链接，使用该Base和表。

核心字段：

- `项目参与者`：投稿人姓名。
- `院校/机构`：学校、机构或团队。
- `研究项目`：短句，采用“方法/简称：解决什么问题”的风格。
- `技术标签【新】`：自由生成的多选标签，写这里。
- `入选会议`：会议、期刊或接收信息。
- `附件`：原始Word/docx等稿件。
- `微信链接`：文章发布后的微信链接。

不要再写`技术方向`，除非用户明确要求。

## Create Record Workflow

1. 从用户消息和文件名提取基础信息：投稿人、院校/机构、主题补充语。`院校/机构`只按用户消息里明确提供的内容填写，不从稿件正文里提炼。
2. 读取Word/docx正文，优先关注标题、摘要、论文信息、方法名、结语、项目链接附近文本。
3. 生成字段值：
   - `项目参与者`：找不到就写`待补充`。
   - `院校/机构`：只用用户消息里的明示信息；消息里没给就写`待补充`。
   - `研究项目`：一句短句，格式优先为`方法名/简称：解决xxx问题`。
   - `技术标签【新】`：2到4个自由标签，贴近稿件真实技术点。
   - `入选会议`：只有看到明确证据才写；找不到就不写这个字段，保持空白。
4. 用`lark-cli base +record-upsert`新建记录。附件字段不要放进JSON。
5. 用`lark-cli base +record-upload-attachment`上传原始文件到`附件`字段。该命令要求`--file`是当前工作目录内的相对路径；必要时切到文件所在目录再执行。
6. 回读新记录，确认文本字段和附件在同一条记录里。

## Feishu Group Demo Notes

当任务来自飞书群聊时，把群消息当作自然入口，流程保持同一套Base写入规则。

推荐demo触发方式：

- 只处理明确@机器人或明确转发给机器人的消息。
- 只处理包含投稿语义、docx附件、作者/机构信息、微信链接回填语义的消息。
- 如果群里有人@编辑老师，机器人应等待明确指令或被@后再处理，避免误读普通讨论。

消息上下文处理：

1. 优先读取被@的那条消息正文。
2. 如果消息带Word/docx附件，下载附件后按Create Record Workflow处理。
3. 如果正文只有“这是某某那篇+微信链接”，进入WeChat Link Backfill。
4. 如果作者或机构缺失，按Missing Value Backup写`待补充`；如果会议缺失，保持`入选会议`为空。
5. 如果一条消息里包含多篇稿件或多个附件，逐条处理；无法区分时先在群里回复候选项并等待确认。

机器人能力边界：

- 需要机器人在群内，且有读取群消息、下载附件、发送回复、读写Base的权限。
- 长连接/WebSocket事件订阅适合demo，省去公网回调地址。
- 群聊demo阶段先把处理范围收窄到“被@的单条消息+该消息附件”，稳定后再扩展到上下文窗口或编辑老师协作流。
- 复用用户已有机器人时，不要改应用名称或权限配置；只记录需要新增的scope和事件类型。

## Field Style Rules

`研究项目`要短，像旧记录的一行项目描述，避免长摘要。好例子：

- `Think with Images/Videos：解决医学多模态模型推理缺少视觉证据查证的问题`
- `C-Evolve：基于共识机制优化多提示词进化`
- `AgentFlow：在线优化智能体系统的新范式`

`技术标签【新】`允许按稿件自由发挥，不局限于原选项。标签应偏概念化和可聚类，例如：

- `医学AI`
- `视觉推理`
- `多模态Agent`
- `世界模型`
- `对抗安全`
- `模型蒸馏`

`入选会议`只根据明确信息写入，例如`ICML 2026`、`CVPR 2026`、`NeurIPS 2025`、`Nature`。不确定或没有提及时，不写这个字段，保持空白。

## Missing Value Backup

缺失或证据不足时写`待补充`，不要猜。适用字段包括投稿人、院校/机构、论文标题等用户希望沉淀到Base的信息。

例外：`入选会议`没有明确证据时保持空白，不写`待补充`。

`院校/机构`只来自用户消息里的明示信息，不从稿件正文提炼；消息里没给就写`待补充`。

如果`技术标签【新】`没有足够技术线索，可写`待补充`或只写一个最确定标签。

## WeChat Link Backfill

当用户后续给微信链接并说明是哪位投稿人或哪篇文章时：

1. 在Base里检索候选记录，优先用`项目参与者`匹配，再结合`研究项目`、`院校/机构`消歧。
2. 只命中一条时，把链接写入该记录的`微信链接`字段。
3. 命中多条或不确定时，列出候选记录让用户确认。
4. 回读记录确认`微信链接`已写入。

用户可能会说：

- `这是李文杰那篇：https://mp.weixin.qq.com/...`
- `这个链接回填到上海创智学院LeapQuest那篇`
- `这篇发了，微信链接是...`

## Output

完成后用很短的中文说明写入结果，包括record_id、`研究项目`、`技术标签【新】`、`入选会议`、附件或微信链接状态。若用了`待补充`，明确列出来。