使用 AI、日誌與 Static Automation，讓團隊在沒有「管理」的情況下自動運作
在軟體團隊中，最昂貴的不是程式碼，而是「溝通成本」。 每天成員在 Zoom、Slack、Email 之間穿梭，各種需求、會議紀錄、模糊訊息散落四處，最終造成的不是低效率，而是系統性資訊遺失。
我長期觀察到一個現象：
大家不是不知道要做什麼，而是不知道「現在」要做什麼。
於是，我開始嘗試打造一個不介入、不干預、不命令，但能讓所有人自然走向自己角色與任務的系統。
這個系統，我稱為 Invisible PM（隱形 PM）。
它不需要額外配額、不需要新帳號、不需要複雜後端。 它每天自動生成一份報告，讓每個人都清楚自己的下一步。
下面是我從零打造它的過程。
1. 問題不是工程師，而是訊息的熵
典型軟體團隊的問題不是技術，而是訊息流動的混亂：
- 關鍵訊息散落在 Zoom、Slack、工單系統與私聊
- 工程師誤解需求、PM 忘記跟進、老闆只看到結果
- 跨時區（例如印度、台灣、北美）協作存在溝通斷層
- 沒有人知道誰下一步要做什麼
- 每次會議後都需要有人「手動整理紀錄」，但沒人喜歡做
這些混亂都會導致高熵，而高熵必然降低輸出。
Invisible PM 的第一個目標就是：
降低訊息熵，把混亂重新結構化。
2. 用 Markdown 建立「真實工作日誌」
與其要求工程師「寫報告」，我做了一件更自然的事：
把工程師日常聊天、紀錄、自我提醒，統一成每日一份 Markdown log。
這份 log 可能長這樣：
- 今天和誰討論了什麼 API？
- 哪個 microservice 有 bug？
- 誰提出了新需求？
- 今天最大的阻塞點是什麼？
這份 Markdown 不需要華麗格式，甚至可以是非常粗糙的條列。 因為下一步會交給 AI 來整理。
3. 透過 API 自動抓取每天的 channel 訊息，累積成 日期.md
光靠人工整理 log 還不夠，真正的突破是：
直接透過 API，把每天的 channel 訊息自動抓下來，彙整成 YYYY-MM-DD.md。
具體做法：
- 排程每天執行一支 script（例如 Python 或 Node.js），呼叫 Slack / Teams / 自家 chat 系統的 API。
- 針對指定的 channel（例如
#commerce-rnd、#support、#infra）抓取過去 24 小時的訊息。 - 把每則訊息轉成標準化格式，例如：
時間戳記
使用者
訊息文字
是否有 thread / 回覆
是否附帶檔案或連結
- 透過簡單的規則先做一層「預清洗」：
過濾純貼圖 / 表情符號
合併連續的系統通知
把相同主題 thread 聚合成一組
最後輸出成一份當天的 YYYY-MM-DD.md log 檔，放在固定目錄下。
這樣做有一個非常關鍵的效果：
- 完全不依賴人的記憶或意願，訊息自動被「沉澱」到 log 中。
- 隨著時間推移，累積的 log.md 會越來越多，AI 可以學習與分析的脈絡也會越來越細緻。
當每天的 channel 訊息都持續被記錄下來，Invisible PM 的「眼睛」會越來越銳利， 能從歷史行為中看到模式：誰經常被卡住、哪種問題反覆出現、哪條 API 一再被問等等。
這一步，讓 Invisible PM 從「單次摘要工具」進化成「長期觀察與優化系統」。
4. 使用 Codex 讓 AI 自動生成企業級 daily report
有了每日 log 之後，下一步就是讓 AI 來整理。
我寫了一個小型 Shell pipeline：
markdown → codex → HTML → deploy
每天固定時間（例如 20:20）自動執行：
- 讀取當天的
YYYY-MM-DD.mdlog。 - 把內容餵給 Codex，搭配精心設計的 prompt：
幫我用英文整理今日工程進度
將資訊分成：Summary/Key Events/Risks/Blockers/ Next Actions
為每位成員產生具體的 Follow-up Items
直接輸出純 HTML，不要使用 Markdown code block
- Codex 回傳一份結構化的 HTML 報告。
- 腳本將這份 HTML 存成
report-<hash>.html或放在日期目錄裡。 - 透過 rsync、scp 或 CI pipeline，把報告部署到 static hosting。
這個步驟的關鍵不是「有沒有用到多高階模型」， 而是：
用一致的 prompt + 穩定的 log 結構，讓 AI 產出的報告在風格與結構上高度穩定。
5. Invisible PM 的靈魂：每位成員的「下一步任務」
這整套系統真正有價值的地方，不是摘要，而是：
為每位團隊成員自動生成清楚而具體的下一步（Action Items）。
報告中會生成類似這樣的段落：
Diyysh — Follow-ups
- 完成 FLEET API 與相關端點的文件與圖示整理。
- 確認 dashboard 中每個圖表對應的 API endpoint 與資料來源。
- 將變更紀錄與 ETA 更新到共享的 Google Doc。
Rooit — Follow-ups
- 套用新的 broker / topic / payload 設定至對應環境。
- 驗證 telemetry 解析與資料寫入 FLEET pipeline 是否一致。
- 回報任何 contract mismatch 或解析異常。
Stvve — Follow-ups
- 審閱目前 API / dashboard 文件是否足夠讓非工程角色理解。
- 確認時間預估與實際投入是否有落差。
- 對接接下來部署計畫與客戶溝通需求。
Stan — Follow-ups
- 確認今天產生的報告能在外部網址正常讀取。
- 檢查自動化 pipeline 是否穩定（API 抓取、log 存檔、報表生成）。
- 根據今日觀察微調明日的 prompt 或報告版型。
每位成員只需要看屬於自己的幾行，就能掌握：
- 今天應該完成什麼？
- 哪些是自己負責？
- 有沒有需要先解決的阻塞？
這種結構讓團隊默默進入一種「節奏模式」：
- 工程師不再被巨量訊息淹沒，
- PM 不用每天重新解釋，
- 老闆只要看一頁 HTML 就能知道目前狀況。
Invisible PM 不需要發號施令， 它只是每天「照實」把 log 轉成具體行動清單， 讓每個人自然聚焦手上的工作。
6. 為什麼我堅持用 Static HTML？
很多人會第一時間想到「做一個 Web App、後端 + 前端 + DB」。 但我後來選擇了最簡單的方法：
全部輸出成 Static HTML。
原因很簡單：
- 安全性簡單：沒有 server-side code，就沒有 server-side injection 漏洞。
- 維運成本低：靜態頁面放在任何 CDN / object storage 上就好，流量再大也只是多幾個 GET。
- 快取友善：瀏覽器可以長期快取舊報告，查歷史幾乎是瞬間完成。
- 抗故障：就算後端 API 或 AI provider 暫時掛掉，已產生的報告仍可正常閱讀。
- 完全符合「快照型」資訊的特性：每日報告本來就是 snapshot，沒有必要做成動態系統。
對我來說，Invisible PM 的價值不在於「他多炫」，而在於：
- 它夠簡單
- 可靠
- 可長期運作
- 不會因為某個服務升級或帳單問題就崩潰
Static HTML 正好就是這種「長壽資訊系統」的最佳載體。
7. Daily Automation = 團隊節奏自動化
Invisible PM 每天固定時間跑，例如 20:20：
- 透過 API 抓取過去 24 小時的 channel 訊息。
- 彙整成當日 log.md。
- 丟給 Codex 生成報告 HTML。
- 部署到公開或內部的報表站台。
這個節奏會慢慢建立一個「工作慣性」：
- 團隊知道每天的工作最後會被整理進報告。
- 每個人都清楚明天會看到自己的 Follow-ups。
- 訊息不再無聲消失，而是每天被「結清」成一份 HTML 文檔。
久而久之，團隊就會從「事件驅動」轉變成「節奏驅動」：
- 任務推進變得可預測。
- 風險與阻塞早在報告中浮現，而不是到 deadline 才爆。
- 管理者不需要用力控管細節，只要看每日節奏是否穩定。
8. Invisible PM 的技術組成
從技術角度來看，Invisible PM 可以拆成三層：
8.1 基礎層
- Bash / Python / Node.js scripts
- cron（或任何排程系統）
- Static Hosting（Nginx、GitHub Pages、S3 + CloudFront…）
- Markdown log 檔案
8.2 智能層
- Codex / LLM API
- 精心設計的 prompt 模板
- 報告版型（Summary / Key Events / Risks / Actions / Per-person Follow-ups）
8.3 自動化層
- 每日排程
- 自動產生日報與歷史報表
- 自動 versioning（依日期或 hash 命名）
- 自動部署與通知（可搭配 email / chat bot 推送報告連結）
整體系統刻意保持小而簡單， 這讓它具有兩個特點：
- 抗脆弱：就算某一層暫時失效（例如 AI API 掛掉），其餘部分仍可運作。
- 可替換：未來要換模型、換 hosting、換 chat 平台，都不需要重寫整套系統。
9. Invisible PM 是「系統」，不是「人」
Invisible PM 並不是要取代 PM， 而是要取代那些高度重複、低成長的管理動作：
- 重複整理會議紀錄
- 重複追問進度
- 重複分派任務
- 重複對齊資訊
真正需要人來做的，是：
- 設計系統
- 調整節奏
- 做出策略決策
- 在關鍵分岔點選擇方向
Invisible PM 做的事情其實很單純：
把每天的噪音，轉換成結構化的工作。
你不需要「管」人， 你只需要確保系統穩定地運作， 資訊自然會帶著人往正確的方向流動。
這就是我如何利用 API、AI、Markdown 與 Static HTML， 打造一個不說話、不干預、不命令， 卻能讓整個團隊穩定前進的 隱形 PM。
