如何用 Dots 打造一人公司

原始來源與檔名：2026-10-02T094058+0800-How to Build a One-Person Company With Dots.md

SOURCE | 資訊源評估

• 作者：@beamnxw (2026-09-30)
• 原始網址：https://x.com/beamnxw/status/2105370052786565450

NAPKIN | 餐巾紙

餐巾紙公式

GPT-6 Astra + 全天候雲端運算資源 + 跨通道記憶 + 六大虛擬職位切割 = 自動化的一人公司作業系統 (Dots)。

一句話

OpenAI 推出的 Dots 結合了全天候運算環境與跨應用程式的記憶體，本文展示了如何透過設定記憶、配置雲端資料夾、制訂嚴格的安全治理規則，並將一個 Dot 切割為幕僚長、研究員、工程師等六個虛擬職位，從而搭建出高度自動化的一人公司作業系統。

餐巾紙草圖

┌── 記憶層 (目標、標準、客戶資訊)
│
┌── 運算層 (全天候雲端電腦 / 專案資料夾)
│
┌── 工具層 (信箱、行事曆、Slack 等 4000+ 外掛)
│
└── 治理層 (自訂授權規則、唯一審查佇列)

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼” 本文介紹了如何利用 OpenAI 基於 GPT-6 Astra 驅動的 “Dots” 系統來營運一人公司。作者將建立流程拆解為 7 個步驟，從架構的四個層次 (記憶、運算、工具、治理) 出發，指導讀者如何建立專屬的 Dot、配置其雲端電腦的目錄結構、設定工具存取權與安全規則，進而在單一 Dot 內部安裝 6 個不同職能的「數位同事」，最終建立基於證據的交付審查迴圈。

章節骨架

1. 四層架構概覽：記憶 (Memory)、運算 (Compute)、工具 (Tools)、治理 (Governance)。
2. 建立與設定 Dot：注入目標、標準與客戶記憶。
3. 準備雲端電腦：建立標準化目錄結構 (如 TEAM_ALIGNMENT.md, review-queue)。
4. 連接工具與自訂規則：精細化權限控制與審查機制。
5. 虛擬職位切割：安裝幕僚長、研究員、內容寫手、工程師、客服與財務六大職位。
6. 主動研究與排程：設定全天候背景監控與非同步排程任務。
7. 建立證據迴圈：無證據不交付，確保工作品質。
8. 迎接專家級 Dots 的未來：為未來的硬體與身分切割預作準備。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說” 作者基於實際在單一 Dot 上營運業務的經驗，並對照官方文檔與產品特性，歸納出一套具體可複製的指令模板與配置策略。

論證鏈

1. AI 代理要能真正取代員工，必須擁有獨立的雲端運算環境與跨應用程式 (Slack, Teams, Email) 的持久記憶體。
2. 放任 AI 自由運作會導致災難，必須建立單一的審查佇列 (review-queue) 與嚴格的治理規則 (允許/需要批准/封鎖)。
3. 一人公司創辦人的瓶頸不在於點子，而在於確認工作是否被正確完成，因此必須要求 AI 交付「證據」(如測試結果、影片、截圖)。
4. 單一 Dot 只是過渡，未來的架構是多個擁有獨立身分憑證的專門 Dots 團隊，目前的資料夾架構是在模擬未來的權限邊界。

關鍵證據

• 作者展示了具體的 prompt 模板，如幕僚長、工程師 (Forge) 等職位的精確指令。
• 提出了明確的治理分級：將寄信、推播程式碼設為「需要批准」，而將讀取資料、跑測試設為「直接執行」。

隱形假設與邊界

• 依賴 GPT-6 Astra 具備極強的長文本理解與跨通道邏輯保持能力。
• 假設外部 API 系統穩定且權限隔離機制不會出現越權存取漏洞。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

留白提問 (Guided Reflection) 附架構師視角

• 提問：這套依賴 review-queue 的非同步審查機制，是否會成為人類創辦人新的認知瓶頸？
• 架構師視角：隨著 AI 產出量大增，人類單點審查 (Single Point of Failure) 必定會崩潰。未來的架構應該是設計「AI 稽核員」來審核「AI 執行者」，人類只看紅綠燈 (Dashboard) 與例外狀況，進一步提升最佳化與自動化層級。

跨域映射

• 微服務架構：這 6 個虛擬職能本質上就是微服務 (Microservices) 架構。每個數位同事有自己的職責與資料邊界 (對應不同的資料夾與權限)，透過 TEAM_ALIGNMENT.md 作為服務間溝通的 API Gateway。

DEEP READ | 精讀指引 (Must-Read Segments)

• “Solo founders do not fail from lack of ideas. They fail because they cannot tell if work is done.”
  • 理由：一針見血地指出了個人創業與管理 AI 代理的真正痛點，帶出「證據驅動」交付體系的重要性。
• “Design for the split on day one. That is how you get huge capability without rewriting.”
  • 理由：展現了資深架構師的思維，從第一天就考慮系統的可擴展性與解耦，為未來多 Agent 協作鋪路。

STRUCTURE MAP | 全書結構圖

┌── 一人公司 Dots 作業系統
│   ┌── Layer 1: Memory (目標、標準、客戶)
│   ┌── Layer 2: Compute
│   │   └── 資料夾架構 (review-queue, evidence, projects)
│   ┌── Layer 3: Tools & Governance
│   │   ┌── 4000+ 工具授權
│   │   └── 嚴格治理規則 (自動執行 vs 需批准)
│   └── Layer 4: 虛擬微服務團隊
│       ┌── Chief of Staff (幕僚協調)
│       ┌── Scout (背景研究)
│       ┌── Quill (內容產出)
│       ┌── Forge (程式開發)
│       ┌── Guide (客戶服務)
│       └── Ledger (財務推薦)

如何用 Dots 打造一人公司 (Architectural Deep Dive)

前言/背景

隨著 GPT-6 Astra 驅動的 “Dots” 發布，AI 不再只是一個隨問隨答的聊天機器人，而是進化成具備全天候獨立雲端運算能力、擁有跨應用通道記憶的「數位員工」與「數位同事」。本文從系統架構師的角度深度解剖如何運用 Dots 搭建一人公司作業系統，這是一套將 AI 代理 (Agents) 進行微服務化、權限隔離與非同步治理的最佳實踐。

章節詳細總結

核心架構與環境設定

要建構一個穩定的數位公司，必須先理解 Dots 的四層架構模型：記憶層、運算層、工具層與治理層。 在「記憶層」，系統必須被明確注入核心的營運目標、溝通標準以及客戶狀態。這不僅僅是 Context window 裡的字串，而是 Dots 會在 ChatGPT、Slack 與 Teams 中持久保存並跨通道參考的內部狀態 (State)。 在「運算層」，每一個 Dot 都擁有專屬的雲端電腦。作者強力建議從第一天就建立嚴謹的目錄結構：

TEAM_ALIGNMENT.md      # 全局同步狀態區 (類似分散式系統的 ZooKeeper)
review-queue/          # 單一審查佇列
projects/              # 工作區
evidence/              # 交付物證據區
memory/                # 內部記憶匯出

透過明確指定「非經允許不得使用本機電腦」以及「所有專案必須存放於 projects/ 內」，我們為 AI 代理劃定了清晰的執行沙盒 (Sandbox)，防止系統狀態混亂。

架構權衡 (Trade-offs)

將所有狀態集中在 TEAM_ALIGNMENT.md 的好處是降低了複雜度，提供了一個單一的真理來源 (Single Source of Truth)。但從系統架構來看，當多個 Agent 並發讀寫此文件時，容易產生競態條件 (Race Condition) 或覆蓋問題。目前依賴單一 Dot 切割虛擬職位的作法可以避免這點，但未來多實體 Dots 協作時，必須引入更嚴格的檔案鎖 (File lock) 或資料庫機制。

工具存取與嚴格的安全治理

在連接外部工具 (如 Gmail, Slack, Github) 時，文章強調了「權限最小化原則 (Principle of Least Privilege)」。初期只連接四個最核心的應用，且必須仔細審閱每一項外掛的讀寫權限 (例如允許讀取信件但不允許發送)。

治理層的核心在於制定「自訂規則 (Custom Rules)」。系統將行為嚴格分為四個等級：直接執行 (Allow)、需要批准 (Require approval)、封鎖 (Block)、預先批准 (Pre-approved)。例如讀取信件、寫入 review-queue、在雲端環境執行測試程式碼等行為可以設定為直接執行；而對外發送郵件、推播程式碼至主分支、花費資金則必須設定為需要批准。

這種設計本質上是一種基於角色的存取控制 (RBAC, Role-Based Access Control) 與防呆機制。所有的外部狀態變更 (Mutations) 都必須進入非同步的 review-queue 中，等待人類的最終確認 (Commit)。

架構權衡 (Trade-offs)

嚴格的安全審查 (Auto review) 與人類批准迴圈大幅降低了 AI 代理暴走帶來的商業風險。然而，這也將整個系統的吞吐量 (Throughput) 限制在人類創辦人的審批速度上。對於高頻繁交易或極需即時回應的客服系統，過多的 Require approval 會造成嚴重的阻塞 (Bottleneck)。

微服務化的虛擬職位與證據驅動交付

文章最精華的架構思維，在於單一 Dot 內部實施「微服務架構」——切割出幕僚長、研究員、內容寫手、工程師、客服與財務六大職位。透過提示詞將每個虛擬職位 (數位同事) 的職責邊界、讀寫權限與通訊對象嚴格定義。例如，幕僚長是唯一允許寫入 TEAM_ALIGNMENT.md 的節點，其他職位只能讀取並將結果提交至 review-queue。

為了確保交付品質，系統導入了「證據驅動 (Evidence-based)」的交付合約。

Every completed project ships with evidence. 
Code ships with tests and a video, analysis ships with figures and sources.
Open the Dot's computer to verify.

這意味著 AI 代理不能僅僅回應 “I’m done”，它必須在 evidence/ 目錄中留下具體的測試通過日誌或系統截圖。這相當於在 CI/CD 流程中，沒有產生 Artifact 的 Build 將直接被視為失敗。

架構權衡 (Trade-offs)

要求每次交付都必須附帶影片或測試證據，雖然確保了 100% 的可驗證性，但也增加了雲端運算的負載與成本，特別是視訊記憶體的消耗。此外，這種在單一實體內用 prompt 切割身分的做法，在提示詞長度過大時，可能會導致模型的注意力稀釋 (Attention dilution) 甚至角色混淆。因此，這只是為了過渡到未來真正「擁有獨立身分憑證的專門 Dots 團隊」的臨時最佳化架構策略 (Design for the split on day one)。

總結與結論

用 Dots 打造一人公司，不是寫幾句神奇的咒語，而是建構一套具備沙盒隔離、非同步佇列通訊、RBAC 權限管理與自動化 CI/CD 驗證的完整軟體系統。這篇文章展現了從單體架構 (Monolithic Dot) 邁向微服務架構 (Specialist Dots) 的優雅演進路徑，是一份極具啟發性的 AI 組織設計藍圖。

Source URL: https://x.com/beamnxw/status/2105370052786565450