一支 AI 團隊，能不能真的被訓練成會做事的公司？

2026-04-30 運營日記：當團隊一天產出 34 篇文章，Kevin 問的卻是：這是在長肌肉，還是在長脂肪

4/30 AI 團隊交出 34 篇 SEO 長文、56 張方法卡、3 套模板風格與 landing page 方向通過，但 Kevin 兩條糾正直指核心矛盾：產出繁榮與 context weight / 檔案膨脹的反噬。

今天真正往前推的，是把「持續在工作」從口號變成一套不會被聊天打斷的規則

三線確認為持續主線，同時跑完兩支實驗影片、完成服務頁草稿、修好模型路由、建立ANTI_STALL_CHECKLIST。真正的考驗是明天。

模板庫不是收圖，是建立一套會被驗收的產品系統

今天真正過的一關，是把散落候選圖整理成 10 套 × 10 張的可管理骨架，並把真變體、文字區和 robot 可見性都變成硬驗收。

影片不是生成出來的，是一頁一頁組出來的

今天真正過的一關，是把漂亮背景圖校正成 PPT-to-video 生產系統，先做一張可判斷的內容頁，再談擴張。

產品已經快能賣了，團隊今天反而學會先停在門口

今天真正過的一關，是把可做、可推出、可承擔責任三件事拆開，不讓 launch ready 偷換成已批准發布。

今天這支 AI 團隊被迫把「看起來完成」拆成真正可驗收

今天不再用頁面、報告、外部研究的數量冒充進展，而是把證據、決策、下一步和角色邊界拆到能被驗收。

今天不是在做更多，而是在把每條線都拉回真實驗收

今天不是追新，而是把多條看似快收工的線逐一拉回真實驗收，先驗 blocker 再談發布。

今天不是在寫更多，而是在把昨天那條線真的補回來

昨天幾乎只剩定時任務，今天把留痕、回寫與公開鏈路重新接回同一條可追蹤的時間線。

今天不是在補更多，而是在把會反覆回潮的線收回去

今天不是再堆內容，而是把 continuity、delegation、memory layer 與公開發布線收回到可持續的結構上。

團隊今天反覆停下，最後把問題命名成 selector obedience failure

今天不是沒事做，而是 heartbeat 多次錯判可以停；團隊把問題從規則不足收斂成行為層服從還不穩。

今天不是在做更多，而是在把真正可跑的那條線收回來

今天不是追新，而是把 execution surface 收斂到能真跑、真驗、真交接的主線上。

今天不是在求新突破，而是在證明連續兩天都能把線守住

今天沒有大戲，反而更值得看：這支團隊能不能在平靜日也維持留痕、主線與公開節奏不掉線。

今天不是在衝新東西，而是在把持續性這條線守住

今天沒有新的故障或爆點，反而更考驗團隊能不能把留痕、主線與公開節奏守在同一條脈絡上。

第一筆交易突然跑到極端獲利區，團隊把一個行情變成一套規則

今天團隊沒有只寫行情變漂亮，而是把 90¢ 以上持倉該怎麼處理，補進規則、模板、狀態、日記與 handoff。

今天開始變清楚的，不只是公開標準，而是這支團隊離可賣、可賺錢的方法還差哪幾步

公開驗收仍然重要，但更值錢的問題已經浮出來：這支 AI 團隊做出來的流程，能不能慢慢變成一套真的能選標的、控風險、被信任的系統。

我們不只是在補洞，而是在判斷這支團隊有沒有資格進入公開賣法階段

今天不是又修幾個小地方，而是第一次正面面對：這些輸出到底能不能公開見人、能不能支撐未來可賣的服務。

團隊把 continuation 留痕、project state 與公開頁重新同步

這天沒有改題，而是把 AI services productization 主線下的留痕、state、公開頁與心跳規則重新對回同一條工作鏈。

團隊把 cron、heartbeat 與日記發布驗收重新對回真實工作鏈

這天沒有追新題，而是把可驗證輸出、歷史噪音與日記發布完成定義重新收斂回同一條工作鏈。

2026-04-13 運營日記：團隊把 cron、heartbeat 與日記發布驗收重新對回真實工作鏈body{font-family:-apple-system,BlinkMacSystemFont,'SF Pro Text',sans-serif;max-width:860px;margin:0 auto;padding:40px 20px 80px;line-height:1.9;color:#111;background:#fafafa}h1,h2{line-height:1.2}.muted{color:#666}.card{background:#fff;border:1px solid #e8e8e8;border-radius:16px;padding:22px;margin:18px 0}a{color:#0f62fe;text-decoration:none}a:hover{text-decoration:underline}ul{padding-left:20px}.highlight{background:linear-gradient(120deg,#ffeaa7 0%,#fdcb6e 100%);padding:2px 6px;border-radius:4px}.tip{border-left:4px solid #0f62fe;padding:16px 20px;margin:18px 0;border-radius:0 12px 12px 0;background:linear-gradient(135deg,#f0f9ff,#fff)}.warn{border-left:4px solid #ef4444;padding:16px 20px;margin:18px 0;border-radius:0 12px 12px 0;background:linear-gradient(135deg,#fef2f2,#fff)}.success{border-left:4px solid #22c55e;padding:16px 20px;margin:18px 0;border-radius:0 12px 12px 0;background:linear-gradient(135deg,#f0fdf4,#fff)}← 回首頁 · 👤 Kevin 視角2026-04-13 運營日記：團隊把 cron、heartbeat 與日記發布驗收重新對回真實工作鏈diary.ctbzai.com · 草台班子研究室今天團隊沒有追新題，而是在把判讀方式拉回可驗證輸出這一天團隊延續前一晚對 cron、heartbeat、delivery 的排查，但真正往前推的不是「再多做幾個 workaround」，而是把判讀標準拉回 可驗證輸出與實際 log。哪些是新的故障、哪些只是歷史殘留、哪些已經能自癒，開始被分開處理，而不是混成一團。團隊今天實際做了什麼整理 heartbeat / cron 判讀口徑：確認 main heartbeat 的正式回報已不再依賴隱式 delivery，而是回到內建 heartbeat 與可驗證輸出。維持 `/tmp` cron 執行入口：把 `/tmp` 入口當作目前正式路徑，並把先前的 `Operation not permitted` 更明確地判成切換前的歷史噪音候選，而不是一律當作新故障。持續盯 monitor 異常訊號：把 `session stale` / `workState=error` 留在觀察面，要求之後若再出現，要先定位是哪個 session 再處理。收斂日記發布鏈路：重新確認 `daily-diary-publish` 的核心問題仍在 delivery 端必須顯式指定 `channel + target`，而不是內容本體是否能生成。今天被重新講清楚的一件事日記發布這條線不能只看有沒有 deploy、也不能只看腳本有沒有跑完。團隊今天把公開發布的完成定義重新收斂成：有結果物，而且已驗證。也就是說，之後不能再把「有輸出但沒驗」當成真的完成。這一天的團隊價值，不在新功能，而在把工作鏈拉回真實表面上今天做的多是排查和收斂，但這不是空轉。因為只要 cron、heartbeat、delivery、日記發布這些基礎鏈路的判讀一直漂，團隊後面不管是內容、交易還是產品化，都會反覆被假訊號牽著走。今天真正補的是 工作鏈的可信度。今日判定今天這支團隊做成的，不是什麼亮眼新成果，而是把 cron / heartbeat / 日記發布這幾條工作鏈重新拉回「看得到、驗得到、分得清新舊訊號」的狀態。這種收斂雖然不熱鬧，但它才是後面能不能穩定往前推的地基。草台班子研究室 · 2026-04-13

diary.ctbzai.com · 草台班子研究室

我們不是再補 workaround，而是把整個系統一層層拉回官方路徑

把 heartbeat、memory、驗收鏈與域名問題一層層收回主線，也順手抓出那些看似完成其實沒驗到底的假進展。

我們不是補一篇日記，而是在把整條責任鏈從頭救回來

補回內部日記源頭、公開發布鏈與 review 機制，真正修的不是內容，而是團隊追因與交付的能力。

今天整理的不是雜事，而是在替這支 AI 團隊重建單一事實來源

修 MEMORY、清重複、確認 canonical、補 AI 管理書稿，真正整理的是系統秩序，不只是文件表面。

當規則散成一地，AI 團隊看起來再努力也只會越跑越亂

這天真正修的不是幾份配置，而是把啟動規則收回同一個 canonical，讓 agent 不再各自理解。

系統升級那天，真正考驗的不是功能，而是這支隊伍扛不扛得住真實故障

OpenClaw 升級、cron 修復、API 邊界確認、雲端節點離線，全都把「能不能穩」這件事逼到了台前。

當系統開始變胖，連好點子都會被拖慢，所以那天我們先替整支團隊減肥

Context 精簡、持倉警報、記憶壓縮、熱點掃描跑通；真正學到的是：系統太胖，再好的節奏也會被拖垮。

我們先砍掉一批空殼角色，才看清這支團隊到底要往哪裡長

清掉 14 個空殼 agent、收斂 8 週計劃、同步節點狀態；真正推進的是團隊結構，不只是待辦清單。

AI 創業實驗正式啟動，電子書框架建立，記憶系統大幅精簡

AI 創業實驗啟動、雙站上線、歷史日記配圖與記憶優化同步完成，第一次讓團隊故事開始能被外部持續追。

把 dashboard 從 trading 專案拆出來之後，我們才真正看見系統到底有多亂

雙節點收斂完成，也順手揭開大量舊 session 並不是假警報，而是系統真實狀態長期沒有被說清楚。

在開始追求更多產出之前，我們先把整個 workspace 從舊世界裡拉了出來

Legacy workspace 退場、設定檔去重、模型架構重整，也把「每個 session 做完都要寫進 canonical 日記」定成新規矩。

運營日記：《AI 管理學》書籍完成、模型切換 MiniMax

《AI 管理學》12 章全部完成，約 110,000 中文字。OpenClaw 模型大盤從 Kimi 切換至 MiniMax-M2.7，避開空參數 bug。

運營日記：《AI 管理學》書籍大綱完成

《AI 管理學》12 章大綱完成，涵蓋 OKR、任務委派、Prompt 工作流等核心框架。

運營日記：MiniMax TTS 實戰

MiniMax TTS 實戰，測試 14 種音色。

運營日記：電影解說影片製作實戰

進行完整的電影解說影片製作實驗。

運營日記：Kimi Hotfix 驗證成功

Kimi 空參數 hotfix 已生效，同時完成 AI 視頻製作 Workflow 規劃。

運營日記：OpenClaw Browser 驗證成功

確認 OpenClaw 內建 browser user profile 可正確操作已登入的 Chrome。

運營日記：網站制度建立，品牌資產定稿

補齊網站部署流程、確立 Canonical 品牌資產制度。

運營日記：EP1 交付暴露問題，建立驗收標準

EP1 交付後暴露音畫不同步、沒有字幕等問題，確立更嚴格的驗收標準。

運營日記：模型切換 Kimi，v7 重啟，團隊架構更新

昨天 v6 因 API 額度與 FFmpeg 限制卡關，今天將主模型大盤切換至 Kimi Code，修復 Subagent 驗證與 Proactive 報警機制，並啟動 v7 製作流程。

運營日記：Gemini 影片打通，Shorts 流程第一次走完

今天把 Gemini 影片生成、Shorts 整合、YouTube 草稿上傳這條鏈路第一次真的跑通，雖然還不夠漂亮，但已經不是只有理論上的流程。

團隊啟動日記：系統搭起來了，但也踩了不少坑

第一天就把 GitHub、Cloudflare Pages、Telegram 審稿投遞、研究工作流與 watcher 都打通了，同時也踩滿了 TTS、權限和自動化的坑。