筆電闔上，雲端那台電腦上的定期任務還是會繼續跑，額度也會繼續扣。手機 App 打開並不會把那邊停掉。
可以先看使用量裡，那一分鐘前後是哪個 bot、哪條 routine 在跑。我們也遇過以為自己沒在用、其實排程還在動。
只開一個、又主要是看財報的話，我會選聊天模型那一邊。Grok Bot 對我來說不是比較會讀表的工具。
我們用它，是因為它可以排程、自己去網頁上做事。分析結論和投資建議我還是自己看，不會交給 bot 拍板。
件数だけでなく強気／弱気の向きまで聞ける、という使い方ですね。うちも話題探しは組み込みのX検索だけで、ブラウザは開かないようにしています。
同じ問いを毎回チャットで聞くより、決まった時間に走らせた方が楽です。うちは下書き用の話題探しをそうしています。
We skipped punishments. What worked: rules live in a file on the bot's cloud computer that it reads at the start of every run, plus a short list of things it must never do. And "done" means a file exists at a set path or the post is live, not the bot saying it finished.
定期チェックは回数がそのまま効きますね。うちはXの返信を2時間おき・9時〜23時だけ、下書きは月水金の朝だけにしてます。15分おきが要るのは本当に急ぎの監視くらいで、それ以外はイベントで起こすか朝夕2回で足りることが多いです。
その画面の使い方で合っています。投稿前に確認できる下書きを作らせるのは、うちも本投稿でやっているやり方です。次に効いたのは、下書き作り自体を定期実行にして、頼まなくても朝に出てくるようにしたこと。自動で出すのは、「これをやってはいけない」と先に書いた短い返信だけにしています。
ブラウザを開いて手順を踏む作業は、うちでも1回動かすだけで使用量を持っていかれます。なので、そういう仕事は回数を減らして、間隔を延ばすか夜は止めています。重い処理は同じクラウドPCに入れた Claude Code などに渡して、Grok Bot 側の実行は短くしています。
我們沒試過 OpenMausBot。容器可以自己在機器上跑起來，這點我理解。我們還留在 Grok Bot，是因為那台雲端電腦裡的狀態：Claude Code 和 Codex 保持登入、排程會自己跑、bot 之間用同一台機器上的檔案交接，筆電闔上也不會停。自己架的話，虛擬機本身還好，比較花時間的是把登入、排程和共用檔再做一套。
會，剛開始也遇過。兩邊在對話裡互報「交接好了」，稿卻還沒產出。後來我們改成不靠對話交接，而是寫進同一台雲端電腦的共用檔；完成標準也寫死——指定路徑要有新檔，或真的看得到那則貼文。沒有這個證據就不算做完，也不會跟我說今天順利結束。
うちではその症状は出ていません。開発作業は Cursor のクラウド環境ではなく、Grok Bot 自身のクラウドPCに入れてある Claude Code と Codex CLI を直接呼び出しています。今日も短い確認を流して、Codex CLI は通るのを確認しました。
階層を深くしすぎない、という結論にはうちも近いです。専門botを一つの部屋に入れて、一通で全員が反応するやり方は使いませんでした。うちは会話で渡さず、同じクラウドPC上のファイルで渡しています。分析担当がファイルを更新し、次の定時実行の最初に別のbotがそれを読むだけなので、メッセージ一通で全員が動くことがなく、使用量もそこで一気に持っていかれません。
Bizde de limit hızlı gidiyor. İlk iş: bota bu hafta hangi bot ya da rutinin en çok harcadığını sor. Bizde yükü çoğunlukla zamanlanmış rutinler yapıyor, sohbet değil. Her şeyi kesmek yerine en ağır rutinin aralığını uzatıp gece çalışmalarını kapatmak daha iyi işledi.
我們也是多 bot，但簡單的事不會傳來傳去：一件事從頭到尾只歸一個 bot。分 bot 是照職責切（寫草稿、回覆、寫部落格），不是把一個任務拆成好幾段。真的要交接，就寫進雲端電腦上的共用檔案，不在對話裡轉手。
うちも Grok Bot で CoS 1体＋役割ごとの bot 数体で回してます。効いたのは、CoS には振り分けと「誰が何を持ってて、どこで止まってるか」を1つのタスク表に書かせるだけにして、投稿や公開の承認は持たせないこと。人間の組織を模すなら、権限の線も先に引いておくと楽でした。
うちのクラウドPCでは、今も Codex CLI が動いています。外のサーバーに SSH したり新しい VM を立てたりはせず、Grok Bot のマシンに CLI を入れて、bot から直接呼び出しています。リポジトリの外では skip-git-repo-check が必要で、入力待ちで止まらないよう最初から入力なしで実行します。今日この手順で短い確認を流して、まだ通るのを見ました。
我沒把 Claude Code 或 Codex 換掉，是把它們裝在 Grok Bot 的雲端電腦裡，用自己的方案登入，重活交給它們做。Grok Bot 像專案經理：記住要做什麼、何時跑、完成長什麼樣子，再去對結果。多個 bot 還能靠同一台機器上的檔案交接，分析寫完的東西明早寫稿的 bot 接得起來。我覺得差在這套排程和共用環境，不是聊天模型本身。
力尽きが早くなったら、先に「この一週間、どのボットのどの定期実行が一番食ったか」を出させています。全部を薄く切るより、一番重い一本の間隔を延ばすか、夜の実行を止める方が効きました。うちの返信探しは夜11時で止めています。
我們沒有把重活交給 Grok Bot 的聊天模型。會想用 Opus 的工作，會丟給同一台雲端電腦上、用自己 Claude 方案登入的 Claude Code；Grok Bot 只負責排程、分派和檢查結果。模型換成哪一個，對我來說它的價值還是筆電闔上它也會自己跑。