Civitai 审核工具 Retool 迁移任务拆解:从低代码后台到自建 Moderator App 的分阶段迁移实战指南
发布时间:2026/9/18 21:23:47 作者:尧图编辑部 阅读量:1,286

Civitai 审核工具 Retool 迁移任务拆解从低代码后台到自建 Moderator App 的分阶段迁移实战指南【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文以 Civitai 仓库内docs/moderator-app/retool-migration-tasks.md为骨架完整呈现审核工具从 Retool 低代码后台迁移到自建 Moderator App这一大型工程的任务拆解包括现状核对表、跨切面基础建设Phase 0、最高优先级应用Phase 1、剩余 V1 应用Phase 2、V2 与低优先级Phase 3以及工作流迁移Phase 4并逐一标注每个任务的依赖关系、阻塞项与开放问题。读者读完可以掌握如何把一份按 ClickUp 工单描述的迁移需求分解为可独立交付的小任务、如何用源码与审计文档交叉核对迁移完成度、以及迁移过程中权限模型、动作日志、数据迁移三条底线的落地方式。一、迁移背景与现状核对工单描述 vs 仓库现实该任务清单源自 ClickUp 工单868kkxqpnModeration Tooling — Retool → Civitai migration, design。每个条目都被设计为可独立发布independently shippable并明确写出依赖关系。文档作者在整理时对照了apps/moderator中NAVIGATION常量与路由树见 access.ts逐条核对工单要求与仓库现状得出下表工单章节条目状态Conventions按审核角色做权限门控完成— 按角色授权/admin管理1.1总览页、各队列计数部分完成— 仪表盘按计数列出可达队列防重叠未开始1.2User Lookup用户查询部分完成—/retool/user-lookup已上线170 个导出查询中 97 个未移植见 user-lookup-audit.md1.3Bulk Image Manager未开始ImageQueueGrid与化妆品多选可复用1.5User / Post Reports部分完成—/reports已存在无按报告的图片网格、无先前审核活动面板1.6Chat Audit完成—/retool/chat-audit只读4 个标签页 全部导出查询已移植或已分类1.7Image Lookup完成—/retool/image-lookup10/10 查询、4/4 标签页1.8Article Lookup未开始/articles/*只覆盖队列不覆盖查询1.9Front Page Audit未开始 —被一个开放问题阻塞1.12Buzz 增减未开始 —被一个开放问题阻塞2.1Bulk Ban未开始2.2Moderation Rules未开始2.3Model notes未开始2Retool Workflows未开始此外文档明确列出已迁移且不在工单范围内的部分图片审核队列、文章队列、黑名单blocklists、禁用提示词 / 提示词测试器 / 扫描器审计、漫画审核、化妆品授予。这一节的价值在于迁移完成度的核对不能只看页面上线了没有而要逐条对照导出清单与路由树。审计文档 parity-findings.md 中就曾记录名称级覆盖率门槛不成立——Bulk Image Manager 的 40 个查询全部被点名仍有 4 个未被覆盖因为分类行会吞掉它不承载的行为。核对时必须读每个查询的 WHERE 子句、输入控件与 SELECT 列而不是只看名字。二、Phase 0 — 跨切面基础建设一切的前提工单的 Conventions 章节点名了以下四项基础工作。文档强调先做它们避免每个应用各自发明一套版本doing them first avoids each app inventing its own version。0.1 共享实体解析器Shared entity resolver一个统一的解析器接受user ID / username / email作为输入并扩展支持post ID / model ID / model version ID供内容工具使用。返回可判别联合discriminated result让调用方可以按结果分支处理。源码印证在 user-lookup.service.ts 中resolveUserId正是这一思路的实现——先尝试按数字 ID 查询限定在2_147_483_647范围内避免 int4 越界报错再按 username/email 查询且刻意支持全数字用户名的边界情况。它被 1.2、1.3、1.7、1.8、2.1 消费。0.2 审核动作日志Mod action log每次动作都要记录actor执行者、action动作、target目标、reason原因、timestamp时间戳。它支撑先前的审核活动——显示是谁做的面板1.2、1.5和防重叠系统1.1。文档给出了关键演进ModActivity现在是append-only只追加——原来用于把重复记录折叠成单行的unique([activity, entityType, entityId])唯一约束已被移除三个写入方主应用trackModActivity、spokerecordModActivity、auth-hubtrackImpersonation都改为纯 INSERT。为此启用的读路径索引已就位(entityType, entityId, createdAt)和(userId, createdAt)。源码印证见 mod-activity.ts——recordModActivity使用无目标的onConflict(doNothing)注释解释了为何刻意不写目标列无目标子句在唯一索引存在与否两种情况下都合法命名目标会在索引被删除后报 42P10 错误而省略该子句在索引删除前会报 23505。recordModActivityBatch则是同一条语句写多行并把同样的 onConflict 逻辑收拢在一处避免调用方各自复制一份。剩余缺口没有 reason/detail 列。工单要求动作旁边记录原因因此 0.2 仍需在 1.2e/1.5 能展示为什么采取动作之前增加一个details jsonb或等价物列。历史从迁移那一刻开始。迁移前写入的行是就地去重的因此表中每个实体只保留最后一个执行者。任何先前审核活动面板对较老账号都会显得稀疏——应在 UI 中明示而不是暗示记录是完整的。0.3 Retool DB 数据迁移审核备注moderation notes、strike违规记录、定时静音timed mutes都存放在 Retool 数据库中按工单自己的盘点共 8 个查询。只迁移 UI 而不迁移数据会让两套系统同时成为权威leaves both systems authoritative这是必须避免的。需要的产出目标 schema、回填backfill、切换计划cutover plan以及过渡期内 Retool 是否继续写入的决策。关联资料retool-db-tables.md 给出了这份数据迁移的完整画像——Retool 自己的 Postgresretool_db存有 Civitai 主库从未有过的审核数据其中必须迁移的表包括UserNotes56,339 行自由文本备注 两个行为标志spamWhitelist/deservedMuteUserStrikes12,771 行strike 体系Civitai schema 中无对应物TimedMutes0 行定时静音当前为空——文档提醒移植前要与审核团队确认该功能是否已死ModerationImageHelp37 行审核员之间请求二次意见的队列。该文档还记录了两个 schema 问题审核员用名字而非 ID 标识37 个不同标识符中只有 5 个能匹配到 Civitai 审核账号需要手工构建 name→userId 映射表以及TimedMutes.userId是 text 而其他表是 integer迁移时需先检查非数字值再转型。注该文档同时标注了RETOOL_DATABASE_URL已于 2026-08-21 退役两库合并getModeratorDb()读取MODERATOR_DATABASE_URL——所以迁移后的目标就是 Moderator DB连接字符串变化即完成切换。0.4 共享服务中的动作归属Action attribution in shared services把工单列出的动作ban、ToS、strike、mute、note、buzz统一走现有的mod-actions/registry.ts接缝而不是新建临时端点这样主应用与 spoke 保持在同一条代码路径上。源码印证见 mod-actions/registry.ts——它被明确定义为跨应用审核动作注册表每个条目把主应用通过/api/mod/[action]调用的动作映射到 spoke 处理器输入 schema 使用共享的civitai/moderation契约端点按主应用客户端发送的确切形状校验handler 调用与审核页面相同的 spoke 服务两个入口执行同一份代码。注释强调这是唯一被认可的入站接缝——加动作就在这里加不要新增临时端点。三、Phase 1 — 最高优先级工单自己的标注1.1a 防重叠Anti-overlap选择一种机制签到check-in、动作日志告警action-logging warnings、或两者结合开放问题。依赖 0.2——因为另一位审核员正在处理这个账号的判断依据正是动作日志。1.1b 仪表盘队列覆盖Dashboard queue coverage当前仪表盘只展示携带countKey的队列共 13 个全部在 Images/Articles 下。需要把计数扩展到其余队列让总览完整。源码印证在 access.ts 的NAVIGATION中可以看到countKey的使用模式——Images 组下minor、poi、tag、newUser、modRule、remixSource、reported、appeals、csam、imageTags、imageRatings、stuckIngestioninformational、ingestionErrors都有计数而 Models 组刻意没有countKeyPending 计数约需 10 秒而sidebar-counts.service.ts是每次导航都要等待的单个 Promise.all计数放在页面自己的标签页上单独拉取。informational: true用于没人会去处理的计数如卡住的扫描不计入仪表盘需要关注总量。1.2 User Lookup —— 单项最大的工程Retool 应用有603 个组件 / 122 个查询横跨 6 个后端。文档明确警告不要把这一项拆成一个任务Donotscope as one task。建议拆分如下每个子项都可独立交付1.2a Shell解析器输入、身份/资料、内容计数、Civitai 评分1.2b Reports 面板— 针对/由该用户提交的报告1.2c 审核记忆— 备注作者可编辑、strike、静音状态 历史1.2d 安全信号— 注册/活动 IP、共享 IP 账号、垃圾信息启发式、生成滥用1.2e 先前审核活动面板依赖 0.21.2f 内容动作— 评论批量删除 / ToS、被封禁提示词列表1.2g 账号动作— ban/unban、清除内容、静音、强制登出、编辑社交链接与 bio1.2h 订阅与 Buzz— 余额、收据、支付、Stripe 深链。不接 Paddle2026-08-07 决定深链曾被误建并于 2026-08-21 移除1.2i 支持上下文— Freshdesk 联系人匹配1.2j LoRA 训练、已发送 DM1.2k 之前和其他审核员聊过弹窗依赖 0.2源码印证1.2a 的实现细节user-lookup.service.ts 的getUserLookup用单个Promise.all并发拉取 13 个数据源——identity、profile、scores、counts、stats、reportsFiled、reportedContent、subscription、curator、ranks、strikeCountAllTime、modContact、strikes。其中两个跨库/慢查询被显式.catch()降级Moderator DB 宕机不应当让整个查询空白getModeratorContact是对ChatMessage的无界扫描失败时返回空默认值。计数部分用COUNT_SOURCES数组统一管理Models/Images/Posts/Articles/Collections/两种评论/Reviews/Chat Messages——最后一项是 Retool 导出中不存在的第九行因为AllCountsUnion不产生它而审核骚扰案件恰恰要数 DM。Models 与评论还保留了 per-flag 明细NSFW/ToS/POI/locked/deleted因为412 个模型与412 个模型、其中 9 个违反 ToS、3 个 POI是两个不同的事实。1.3 Bulk Image Manager瀑布流网格 多选复用ImageQueueGrid通过实体加载0.1批量 ToS 附带 reason 可选 strike支持 nsfwLevel含 Blocked与日期过滤器。源码印证见 bulk-image.service.ts——Retool 需要 10 个查询才能覆盖 5 种图片来源因为它的查询无法 join 到另一个查询的输出FindModelVersions → FindPosts → FindImagesFromPosts是一个 join 被表达成三次往返这里每种来源是单个查询。Source/Link列被刻意移除它们在每个查询里硬编码域名媒体 URL 统一来自$lib/media/edge-url链接来自$lib/entity-url都以CIVITAI_APP_URL为准。注释还提醒civitai.red是审核链接的预期目标域名ClickUp 868kn8aa0不要纠正 .red 链接为 .com。四、Phase 2 — 剩余 V1 应用1.5 Reports 升级按报告的内联图片网格per-report image grid inline加上先前审核活动与先前报告在同一屏幕上工单的 everything on one screen 要求。依赖 0.2。1.6 Chat Audit已以只读形式上线于/retool/chat-audit。开放问题被如此解决只读——Retool 的 BANAPI/SetNote刻意不移植执行留在 User Lookup那里有上下文和审计轨迹默认仅对 admin 级别授权可见保留期不变。Retool 的全部四个标签页都已移植搜索/转录search/transcript、报告队列reports queue、洞察insightstop chatters/chats全时段与 24 小时、重复消息、以及 Newest。未打开转录时消息正文藏在 Show message text 开关后面。1.7 Image Lookup已上线于/retool/image-lookup。对照导出审计为完成10/10 查询、4/4 标签页。1.8 Article Lookup按 ID 查询完整 Article 行。1.12 Buzz 增减被开放问题阻塞——独立应用还是并入 1.2h五、Phase 3 — V2 与低优先级2.1 Bulk Ban— 受限工具封禁一批用户。需要自己的角色限制授权系统支持这一点以及 0.1 用于列表解析。2.2 Moderation Rules— 工单标记为低优先级用得不多not used much。2.3 Model notes— 模型上的自由文本审核备注现有变更历史覆盖其余部分。源码印证Bulk Ban 的权限思路access.ts 中/retool/bulk-ban的注释解释了看页面是调查行为候选列表、IP 聚类执行封禁是整个应用中爆炸半径最大的动作必须与阅读分开——这正是受限工具需要自己的角色限制的实现形态。同样地/users/newest被刻意设计为/users的兄弟节点而非子节点如果新用户列表挂在/users下而/users的授权同时门控 User Lookup 的 ban/purge/批量评论动作那么让他们看新注册就等于让他们封禁任何人见 access.ts。六、Phase 4 — 工作流迁移确认有两个 Retool Workflow 处于活跃状态需要迁移Daily Challenge — Not Prepared Check78e2bb67…Daily Challenge — Not Started Checkceb7402d…工单作者不确定这是否是仅有的活跃工作流——文档强调在退役任何东西之前先审计其余 Retool 工作流的使用情况audit remaining Retool workflows for usage before decommissioning anything。七、阻塞范围的开放问题以下问题从工单延续而来每个都阻塞了旁边的条目问题阻塞Front Page Audit — 砍掉还是保留仅视频的精简版1.9Buzz — 独立应用还是放进 User Lookup1.12防重叠 — 签到、动作日志告警、还是两者都要1.1a权限 — 哪个角色层级获得哪个工具/动作每个新页面的授权配置八、关于工单本身的附注工单描述的1.4、1.10、1.11 小节缺失——编号从 1.3 直接跳到 1.5、1.9、1.12。文档提醒要么是刻意删除要么是在编辑中丢失在把这份清单当作完整清单对待之前值得确认没有遗漏。九、迁移工程的方法论沉淀从该任务拆解文档及其配套审计文档中可以提炼出几条可复用的工程方法以导出清单为唯一事实源但不止步于名字user-lookup-audit.md记录了 170 个查询的完整分类42 移植 / 14 Retool 管道 / 17 等价覆盖 / 97 真实缺口并两次修正了97 这个数字被高估的结论——审计文档会过时行动前要重新对照代码。警惕预设工作流这类盲区extract.mjs最初只报告查询把下拉框中的预设标签如 Stripe Chargeback Retrieval 罐头事务、定时静音时长 6/12/24/48/72/168 小时全部丢弃——罐头工作流也是功能。修复后提取器输出 tabs option sets立即暴露了应用真实的目录结构。已迁移不等于与导出逐行为等价parity-findings.md记录了大量移植了但行为不对的实例——报告details在所有页面被丢弃举报者自己的话从未到达 DOM、getReports只在传入参数时才应用过滤否则静默返回全部历史、选了但从不渲染的列是最反复出现的缺陷类型取数花一次查询丢弃它花的是审核员盲目决策。刻意不做的事要留痕Paddle 工作流Civitai 已停用 Paddle、ReactionsAll无界裸行、GeneratorCount对 10.8 亿行的全时段 COUNT、ToggleMod角色层级决策未定——每一条不移植都写明了理由避免下一次审计重新发现它并把时间花在重建上。这套任务拆解 → 导出审计 → 逐项核对 → 明确标注阻塞与开放问题的流程正是把一份 ClickUp 设计工单落地为可追踪、可验证、可增量交付的工程计划的关键。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考