這不是產品功能公告，而是一組圍繞真實工程問題展開的文章：為什麼要做 QTable、AI 如何安全操作業務資料、Context 如何建立、Agent 如何執行工作，以及一個專案如何真正走向開源。
Self-hosted 真正困難的不是把 Container 啟動起來，而是長期 Upgrade、Recover 與 Operate。這篇結合 QTable 目前 PostgreSQL / Redis / MinIO / QTable / QTableUI Compose、Alembic、Health Check、Release Gate、ChangeSet 與 Runtime Trace，整理已具備的 Operational Foundation，以及 Backup / Restore、Readiness、Metrics / Alerting 仍需要補齊的 Boundary。
AI Native 不代表所有 Workflow 都要交給 Model。這篇結合 QTable 目前 Rule / Event / Execution、ChangeSet Event Materialization、Scheduler、Worker、Run-As Permission、Retry、Rule Version、Loop Guard 與 Execution History，拆解 Agent 和 Automation 為什麼應該分工。
Source 公開只是第一步，真正部署的是 Dependency、Container Image 和 Release Artifact。這篇結合 QTable / QTableUI 目前 CI、Dependency Audit、CycloneDX SBOM、Trivy、BuildKit Provenance、OCI Metadata、Image Digest 與 Full-Stack Release Gate，拆解一份 Source 如何變成可追溯、可驗證的發布制品。
Agent 可以讀表、分析任務、呼叫 Tool，但它不應該因為「是 AI」就獲得更高權限。這篇結合 QTable 目前身份傳遞、Workspace / Item Permission、Row Permission、Skill Authorizer、Relation Sanitizer 與 Action Plan Apply，拆解為什麼 Agent 權限只能收窄，不能放大。
同一條任務在 Grid 裡是一列，在 Kanban 裡是一張卡片，在 Gantt 裡是一段時間條。這篇結合 QTable 目前 Record / View Model 與 QTableUI 實作，拆解 Business State 和 View State 為什麼必須分開，以及 Kanban Order、Gantt Mapping、Realtime Sync 如何圍繞同一份業務事實工作。
真實 Agent 往往需要拆任務、估工期、讀 Schema、產生 Gantt 再寫入 Record。這篇結合 QTable 目前 Multi Tool Chain Runtime，拆解 ToolChainPlan、Dependency 與 Data Passing、Retry / Confirm / Rollback、執行可觀測性，以及目前 DAG 平行調度仍需要補齊的部分。
Agent 真正進入業務系統後，關鍵不是模型能記住多少，而是系統如何明確目前使用者、Workspace、Table、View、Conversation 與權限邊界。這篇結合 QTable 目前 Context Engine，拆解 Scope、對話壓縮、Cache / Session / Snapshot，以及上下文如何注入 Agent Runtime。
AI 開始修改業務資料後，真正危險的是過期、越權或理解錯誤的決定成為業務事實。這篇結合 QTable 目前的 Action Plan、record version、權限重驗證與 ChangeSet 實作，拆解 Preview → Confirm → Apply 為什麼是一條執行邊界。
Agent 真正進入業務系統後，難點不是產生文字，而是理解物件、關係、權限和狀態。這篇從 QTable 目前的 Field / Record / View / Relation / Permission 模型出發，討論多維表格為什麼是自然語言與可執行工作之間很實用的一層。
Airtable、Notion、飛書多維表格已經很成熟了，為什麼還值得做 QTable？第一篇從這個問題出發，解釋 QTable 真正想構建的是怎樣的 AI Native 工作底座。
Markdown 原文保存在本倉庫，外部技術社群內容將以此處作為 canonical source。
