明智的開發人員不會透過提出巨大的拉取請求來啟動新專案。他們透過集思廣益、隊友討論、原型設計、圖表、提案、ADR、MR/PR 和 GitOps（每次更改時都會使用稽核機器人）進行工作，並且當規模需要時，Workstation 的多代理架構可以組建一支出色的開發團隊，快速交付生產級工作。
1. “明智”對於新專案意味著什麼
智慧是儘早學習廉價的知識，以及晚時罕見地犯下昂貴的錯誤。下面的序列是有序的，因此每一步都會縮小下一步的爆炸半徑：
Brainstorm → Discuss with workmates → Prototype → Diagram → Propose → ADR
→ Implement in small slices → MR/PR + Review Bot → Merge
→ GitOps promote (dev → staging → prod) → Observe → Iterate
Optional scale-up:
Workstation multi-agent crew (Planner / Builders / Reviewers / Ops)
with human gates on risky actions
2. 頭腦風暴
在花時間與他人相處之前，先花 30-90 分鐘獨處：
- 結果 ——當我們完成後，對於企業來說必須有什麼是正確的？
- 約束條件 ——時間、合規性、平臺、技能、預算。
- 非目標 — v1 明確不包含的內容。
- 風險 — 資料、安全性、效能、鎖定、操作負載。
- 成功指標 — 選擇兩個（例如延遲+採用，或成本+錯誤率）。
把它寫在下面 docs/ideas/。不成文的頭腦風暴消失了。
3.與同事討論
邀請最小的有用圈子：同行實施者、相鄰系統的所有者以及安全/SRE（當風險需要時）。
- 時間範圍（25-45 分鐘）。以決定或開放性問題結束。
- 強制選項：A、B、推遲——不是含糊的協議。
- 指派一名抄寫員；該說明為提案奠定了基礎。
- 將不適視為 ADR 的風險——沒有沉默的否決權。
如果有人關閉迴圈，非同步 RFC 就很好。
4. 原型設計
當不確定性很高時會出現峰值。明智的規則：
- 將其標記為尖峰；設定日曆停止點（通常為 1-3 天）。
- 將其放在一次性樹枝上或
spikes/— 請勿拋光。 - 寫下你所學到的十個要點（尤其是失敗的事情）。
- 決定：推廣、重寫或放棄——永遠不要“悄悄地成為產品”。
5. 圖表
通常三個草圖就足夠了：
| 圖表 | 答案 |
|---|---|
| 上下文（C4 L1） | 誰在和什麼說話？信任邊界？ |
| 順序 | 快樂之路+一條失敗之路 |
| 部署 | 它執行在哪裡；配置和秘密流程 |
將 Mermaid 或 SVG 儲存在提案旁邊。 ADR 發生變化時進行更新。
6. 提案
保持 RFC 簡短（1-3 頁）：問題、選項（至少兩個）、建議、影響（安全/成本/操作）、部署和回滾、開放性問題。獲得批准後，將決定轉化為 ADR。
7.ADR——架構決策記錄
# ADR-00XX: Title Status: Proposed | Accepted | Superseded by ADR-00YY Date: YYYY-MM-DD Deciders: @alice @bob ## Context ## Decision ## Consequences ## Alternatives considered
將 ADR 儲存在 git 中（docs/adr/）。從 PR 連結它們。取代而不是重寫歷史。
8. MR 和 PR——交付單位
先生 （合併請求）和 公關 （拉取請求）是相同的想法：可審查的變更集。
- 小（優選 <400 行有意義的差異）；每次變更都有一個意圖。
- 描述：為什麼、如何測試、風險、回滾。
- 連結：票+ADR+圖表。
- 儘早起草以獲取反饋；如果沒有書面例外，切勿強制合併紅色 CI 或高嚴重性機器人發現。
## Summary ## Test plan - [ ] Unit / contract tests - [ ] Manual path … ## Risk & rollback ## References (ADR, ticket)
9. Review Bot——保護生產的自動評論
審閱機器人是自動的第一審閱者。它不會取代人類；它預先載入了無聊和危險的內容，因此開發人員可以將時間花在設計和產品風險上。
9.1 應評論什麼
- 安全性：注入、授權差距、秘密洩露、不安全的預設設定
- 正確性：空路徑、競爭、損壞的遷移
- 測試：缺少新分支的覆蓋範圍
- API/合約：在沒有版本升級的情況下進行重大更改
- Ops：缺少超時、無限制重試、非冪等寫入
9.2 它如何簡化開發人員的生活
- 作者在幾分鐘內開啟 PR → 機器人評論。
- 作者在詢問人類之前修復或回覆。
- 人類閱讀機器人摘要+重點關注架構和爆炸半徑。
- 更少的尼特回合；生產中逃逸的步槍較少。
9.3 保持機器人有用的策略
- 嚴重性：blocker / should-fix / nit — nits 不得阻止合併。
- 忽略生成的路徑；每月調整誤報。
- 需要人工批准
auth/,infra/、IAM 和資金路徑。 - 永遠不要讓機器人成為生產關鍵服務的唯一稽核者。
透過 PR 差異連線 SaaS 機器人（例如 CodeRabbit）、Cursor Bugbot 或自定義 Action + LLM。分層 lint → SAST → LLM 以獲得最強的姿勢。
10. 生產級質量的 GitOps 最佳實踐
所需的狀態存在於 git 中。協調器（Argo CD、Flux 等）使叢集匹配。促銷是合併；回滾是恢復。
- 單獨的應用程式程式碼和環境配置（或清除
envs/dev|staging|prod覆蓋）。 - 沒有臨時的
kubectl apply刺激作為幸福的道路——僅打破玻璃，經過稽核。 - 漸進式交付：自動同步較低的環境；產品的門控同步。
- 對產品中的可變標籤進行影象摘要。
- 用於特權和登錄檔的策略即程式碼 (OPA/Kyverno)。
- 同步後觀察；練習迴歸。
程式碼質量不僅是乾淨的功能，而且 變革如何進入生產.
11. 工作站多代理架構——打造優秀的開發團隊
一個明智的開發人員仍然需要槓桿。 Workstation 的多代理架構（Agentic AI 工作站包和 OpenClaw for Business，您需要具體或專門的代理團隊）讓您 自動組建開發團隊 圍繞業務簡介——而不是靜態的組織結構圖。
11.1 組合迴圈
- 簡短的 ——利益相關者的成果、限制、SLA。
- 撰寫 — 將角色對映到技能（規劃者、構建者、稽核者、運營者、合規者）。
- 載入程式 — 代理執行時 + MCP 工具 + 記憶體 + 審計跟蹤。
- 執行 — 代理拉動工作，根據規範/AC 實施，對每個步驟進行小型審查。
- 審查直至乾淨 — 審閱機器人 + 審閱代理 + 人門。
- 船 — GitOps 促進重要的環境。
11.2 角色圖（人+代理）
| 角色 | 代理確實 | 人類仍然擁有 |
|---|---|---|
| 規劃師 | 來自 Spec 的史詩、故事、AC | 優先順序和範圍縮減 |
| 建設者 | 並行實施、測試 | 硬邊緣域判斷 |
| 審稿人 | 規範合規性、稽核機器人分類 | 架構和產品籤核 |
| 行動 | GitOps 同步、SLO 監視、草稿回滾 | 上線和事件指揮 |
| HITL門 | 升級有風險的寫入/支出 | 批准或拒絕 |
11.3 為什麼這可以打造優秀的團隊
- 專業化 — 每個代理人都有一份工作；當角色不模糊時，質量就會提高。
- 無混亂的吞吐量 — 單個規格和審查機器人背後的並行構建者。
- 決策的共享記憶 — ADR + Spec + PR 歷史成為團隊的長期記憶。
- 與人類相同的門 — CI、Review Bot、CODEOWNERS、GitOps — 代理不會繞過生產紀律。
- 業務速度 — 花費數小時來組建一支有能力的團隊，而不是花費數週時間來為每個尖峰招聘。
11.4 它如何插入智慧路徑
人類仍然會進行頭腦風暴和討論。原型和圖表仍然存在。多代理團隊加速 提案起草、ADR 腳手架、實施切片、Review Bot 分類和 GitOps 推廣 ——而人類則對結果和風險進行判斷。這就是工作站模型：為您的工作流程配置的代理工作站和 OpenClaw 軟體包，而不是冒充團隊的聊天視窗。
12. 端到端質量門
Local: pre-commit (fmt, lint, secrets) + unit tests PR open: CI + Review Bot comments PR merge: human approve + branch protection + required checks Main: immutable artifact (image digest) GitOps: update env overlay → sync → verify Agents: Planner/Builder/Reviewer/Ops stay inside the same gates Prod: SLOs + alerts + runbook linked from ADR/PR
13. 入門清單
- 創造
docs/ideas/,docs/architecture/,docs/adr/ - 新增PR/MR模板+CODEOWNERS+分支保護
- 啟用預提交 + CI 所需的檢查
- 安裝評論機器人；調整路徑過濾器和嚴重性
- 寫入 ADR-0001：“我們使用 GitOps 進行部署”
- 定義環境升級規則和回滾比賽日
- 如果擴充套件交付：帶有 HITL 門的站立工作站多代理人員（規劃者/構建者/稽核者/操作者）
14. 反模式
- 巨大的“WIP，請批准”PR
- 僅在 Slack 中使用架構 - 從不在 ADR 中使用
- 原型合併為產品，無需測試
- 禁用評論機器人，因為它煩人
- 具有寫訪問許可權且沒有人工門的代理
- 對 GitOps 之外的產品進行修補，沒有恢復計劃
15. 結束
明智的開發人員將新專案視為一系列學習工件（筆記、圖表、提案、ADR），然後透過由 Review Bot 監視並由 GitOps 推廣的小型 MR/PR 進行交付。 Workstation 的多代理架構將這種智慧延伸到一個完整的開發團隊中：專業代理、共享規範、重要的人工判斷以及每條生存路徑上的生產級門。這就是如何在業務快速發展的同時保持生產程式碼質量最佳化的原因。
釋出者： 工作站.
