threads-bot-builderlisted

# Threads 發文 bot 建造器(threads-bot-builder) ## 什麼時候用 - 使用者想固定在 Threads 產出內容,但每次手挑手寫太耗時 - 使用者想做排程發文或發文 bot,但不想要「全自動亂發」砸帳號 - 使用者要接 Threads API,想避開憑證、編碼與 token 的已知陷阱 不適用:使用者想做「完全無人值守、AI 自己決定發什麼」的全自動 bot —— 這份 SOP 的立場正好相反,見下方架構總覽。 ## 第 -1 步:先問他要做哪一種(不要跳過這步) **這一步決定後面三步怎麼寫,不要預設他要做哪一種。** 同一套骨架能做出很不一樣的 bot。差別只在四個欄位:內容從哪來、多久發 一次、拿什麼當去重鍵、這一型最容易做歪的地方。骨架完全一樣。 用 AskUserQuestion 問,選項可以照下表,也可以依他的狀況改寫: | 型態 | 內容從哪來 | 頻率 | 去重鍵 | 這一型最容易做歪的地方 | |---|---|---|---|---| | **內容策展** | 你關注的來源(專案、論文、新品、他人貼文) | 每天 1 篇 | 來源項目的唯一 ID | 變成無腦轉貼,沒有自己的觀點 | | **新聞快訊** | RSS / 新聞 API | 事件驅動,有大事才發 | 標題 + 原文網址 | 沒大事硬發,帳號變雜訊 | | **存稿排程** | 使用者自己先寫好的稿池 | 固定時段 | 稿件 ID | 稿池見底後空轉或重複發 | | **長內容改寫** | 使用者自己的文章 / 電子報 / 影片 | 每篇長文發布後 | 原文網址 | 一稿切太多則,變洗版 | | **產品 / 專案動態** | changelog、release、里程碑 | 有更新才發 | 版本號 | 全是宣傳,沒人想追蹤 | | **互動回應** | 收到的留言、提問、提及 | 觸發式 | 留言 / 訊息 ID(不是對話 ID,不然同一串的第二則會被誤擋) | 自動回覆變罐頭,比不回更傷 | 還有一個選項一定要留:**「以上都不是,我想做的是……」**。這份骨架不預設 用途,他講得出來就照他的做,把他的答案填進上表那四個欄位即可。 問完把答案寫成一行,例如: > 型態:長內容改寫|來源:我的電子報 RSS|頻率:每期發布後隔天| > 去重鍵:原文網址|要小心:一期最多切 2 則 這一行是後面所有步驟的依據,寫進第 2 步的流程指引檔。 ## 架構總覽(人在迴路) 核心不是「全自動」,是「**人出方向,AI 包勞動**」: 1. 固定時間(或事件觸發)由排程叫醒 bot 2. 觸發後第一件事**不是發文**,是問使用者一題(今天走哪個方向? 或直接給他看選好的素材讓他點頭) 3. 使用者點一下之後,選材、去重、寫文、發文全部自動 4. 使用者出 5 秒判斷,省下每次二十幾分鐘的重複勞動;而且每篇都是他 看過方向的,不會發出他沒同意的東西 為什麼堅持人在迴路:全自動發文很容易吐出一堆機器味、沒人看過的內容, 反過來砸掉帳號可信度。自動化可以省力,但不能拿可信度去換。 引導時先確認他接受這個架構再動工。**若他堅持全自動,提醒風險後尊重 決定** —— 但至少幫他留一個「發文前寫進草稿檔、隔 N 分鐘才真發」的 緩衝,讓他有機會攔截。 ## 照步驟做 動工前先跑第 0 步,之後每完成一步先跟使用者確認再往下。 ### 第 0 步:確認環境 先問清楚,不要假設: - 作業系統(Wi