metavige (Ricky Chiang)

1. 問題是從哪裡開始的？ #

這次思考的起點，其實不是想整理一套軟體開發方法，而是因為我開始嘗試和 LLM 一起工作。

AI 時代有一個很明顯的變化：產生資訊、整理資訊、修改程式與建立文件的成本大幅下降。以前需要花很多時間才能完成的分析、規格整理或實作，現在可能只需要幾輪對話就能產生一個可用的版本。

這讓「把想法快速變成東西」變得非常容易，但也帶來一個蠻反直覺的問題：當產生資訊的成本接近於零，資訊本身反而開始爆炸。

這也是我開始重新思考 SSoT、Intent、Spec 與 Canon 的原因。

開發一個新的系統或工具時，我很自然會採用 MVP 的方式。

先有一個想法，快速做出雛形，確認它是否真的有用。只要能運作，就拿到真實的專案裡使用。

接著，實際使用會產生新的問題：

• 某個功能不符合預期
• 某個需求原本沒有想清楚
• 某個規則不夠完整
• 實作方式產生新的限制
• 使用後發現其實還需要另一個能力

於是，每一個問題又變成下一個 Change。

這個循環一開始非常有效：

但當系統越來越大，問題就開始出現了。

舊問題還沒處理完，新問題又不斷冒出來。

最後 backlog 越來越長，功能越來越多，系統卻沒有變得更一致。

這時候我心裡冒出一個很直覺的疑問：

是不是系統已經開始發散了？

2. 問題可能不是 Iteration，而是 Change 被扁平化了 #

仔細觀察後我發現，問題不一定出在「持續迭代」。

最近滑 X、Reddit、GitHub，幾乎每天都會看到新的 AI 工具、新的 AI Skill。 今天有人分享 Claude Code 的 Best Practices，明天有人分享 Cursor Rules，後天又有人公開自己的 AGENTS.md，接著又出現各種 Prompt Library、Memory、Workflow Template…… 每一個看起來都很厲害，也很值得收藏。

但我開始思考一個問題：

這些 Skill，真的適合你的工作流程嗎？

從 Docker Sandbox、OrbStack 到 AI Agent 執行環境的設計思維

前言 #

過去幾年，大型語言模型（LLM）快速發展。最初的 AI 工具主要扮演「助手（Assistant）」的角色，協助撰寫程式、回答問題，真正執行的人仍然是開發者。

然而，這個模式正在改變。

近一年，Claude Code、Codex CLI、Gemini CLI，以及各種 AI Agent 開始具備直接操作 Terminal 的能力。它們可以修改程式碼、執行測試、操作 Git、啟動 Docker，甚至完成整個開發流程。

AI 已經不只是提供建議，而是真正開始「執行工作」。

這也帶來一個新的問題：

如果 AI 擁有和工程師一樣的權限，它到底能做到多少事情？

最近在重新設計 AI Agent 的 Skill，有一個蠻大的體悟。

一個專案的開始 #

開發專案時，通常會在本地端進行，並結合 Database 和 Cache 等服務。目前常見的做法是使用 Docker 啟動 Database 或 Cache container 來建立本地測試環境，而非直接連線到公司提供的測試環境。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18

version: '3.9'

services:
  postgres:
    image: postgres:16
    container_name: my_postgres
    restart: always
    environment:
      POSTGRES_USER: myuser
      POSTGRES_PASSWORD: mypassword
      POSTGRES_DB: mydb
    ports:
      - "5432:5432"
    volumes:
      - pg_data:/var/lib/postgresql/data

volumes:
  pg_data: {}  

以上面的例子來說，你需要先有以下的知識：