Every 的六位工程師教你「如何用 AI 放大工作成果」

2025-10-29 08:20:33

在現今 AI 驅動的開發時代，最引人注目的不是大團隊如何擴張，而是小團隊如何放大生產力。
知識媒體 Every 的六位工程師，利用 AI 工具、智能代理（Agents）、自動化管線與嚴謹的流程設計，成功以「六人之力」同時運營四款 AI 產品、一項顧問業務，並每日產出新聞信。

本文整理自 Every 的專文〈Inside the AI Workflows of Every’s Six Engineers〉，深入介紹這六位工程師如何善用 AI、如何分工、以及他們對「人機協作」的新詮釋。

整體概念：AI 是流程放大的助力，不是取代者

這六位工程師對 AI 的使用有一個共通點：

他們不是讓 AI 決定一切，而是讓 AI 在結構化流程中協助完成具體任務。

他們以「流程 → 工具 → guardrails」的三層結構來設計每日工作，確保 AI 幫忙加速而非干擾。
而且，他們都重視「Source of Truth」——無論是設計（Figma）、專案管理（Linear）、或程式碼（GitHub），都要有唯一的真實來源。

六位工程師的工作方式與 AI 策略詳解

Yash Poojary（Sparkle GM）— 兼顧創意與效率的「邊緣實驗者」

Yash 是團隊中最熱衷於實驗 AI 工作流程的人，他每天同時開兩台電腦：

一台運行 Claude Code
一台運行 Codex

他會在相同的 codebase 上測試相同的 prompt，觀察兩者輸出差異。
結果發現：

Claude Code 回覆較詳盡、邏輯解釋完整，適合探索性任務；
Codex 輸出更精準，適合直接落地實作。

設計整合

Yash 原本用「設計圖截圖 → 貼給 AI」的做法，但後來升級為：

在 Figma 中設計 UI；
利用 MCP（Model Context Protocol） 讓 Claude 直接讀取設計系統的元件資料（顏色、間距、元件名稱）；
Claude 自動生成對應的前端程式碼。

工作節奏（Guardrail）

他嚴格區分：

早上：主線任務（寫代碼、修 bug）
下午：實驗 AI 工具或嘗試新 prompt 技術

這種「雙模式」設計，讓他既能保持專注，又能持續創新。
他甚至自製了一個監控工具 AgentWatch，當 Claude Code 的長任務結束時會自動通知，避免等待浪費時間。

Kieran Klaassen（Cora GM）— 把開發變成系統的「流程編排者」

Kieran 把「規劃」視為 AI 開發中最重要的一環。
他從來不直接開寫程式，而是先讓 Claude Code 幫他做三層功能規劃：

Small：單一功能或簡修；
Medium：模組級更新；
Large：全新功能或系統重構。

文件與工具整合

他使用 Context 7 MCP，能自動將官方 API 文件與程式碼片段嵌入 prompt，確保 AI 的理解是基於最新版本。
接著，他讓 Claude 生成「工作任務計畫」並自動同步到 GitHub，轉換為具體的 issue 或 pull request。

在進行程式撰寫時，他使用：

Claude Code 處理高階架構；
Cursor 或 Amp 處理底層實作。
最後再讓 Claude 自動生成初步 code review，自己僅需檢查與合併。

Kieran 形容：「AI 幫我先鋪好 70%，我只要確認剩下 30% 是否能執行。」

Danny Aziz（Spiral GM）— 把 AI 當專案顧問的「策略工程師」

Danny 的特色是「用 AI 做前期思考」。
他使用 Droid CLI 工具，在命令列中同時呼叫 OpenAI 與 Anthropic 模型，並根據不同任務選擇最佳模型。

策略化使用

GPT-5 Codex：負責主要架構與核心邏輯。
Claude：協助討論資料結構、用戶體驗與錯誤處理。

他不直接要求 AI 寫程式，而是先問：

「如果我要加這個功能，會對資料庫、延遲、維護造成什麼影響？」

AI 的回覆會成為他規劃文件的一部分。
這讓他能預先設計「里程碑」式開發計畫，再分階段交由 AI 生成程式碼。

開發環境極簡

他堅持一螢幕開發，只在需要設計時開啟 Figma。
這種極簡 setup 幫助他保持決策一致，不讓多視窗分散注意力。

Naveen Naidu（Monologue GM）— 將流程制度化的「紀律型工程師」

Naveen 是團隊中最注重流程的人，他堅持一句話：

「如果某件事不在 Linear 上，就等於它不存在。」

任務全自動化

所有錯誤回報、需求、用戶建議皆透過 Linear 管理；
小任務：直接將 ticket 內容餵入 Codex Cloud 觸發自動修正；
大任務：建立本地 plan.md 檔案，作為 Claude / Codex 的藍圖；
終端環境使用 Ghostty，整合 Codex CLI，讓 AI 直接於終端生成與修正程式。

自動化審查

他在每次提交後使用：

Codex 的 /review 指令自動進行語法與邏輯檢查；
Sentry 監控錯誤變化，比較修正前後的錯誤率。

此外，他自研了 Monologue，一款語音轉文字工具，可將口頭描述即時轉成 prompt 或 Linear ticket，讓「開會時的靈感」直接成為開發任務。

Andrey Galko（工程主管）— 稳中求進的「系統掌舵者」

Andrey 是團隊的穩定力量，他不盲目追新，只採用「能穩定交付」的工具。
他曾愛用 Cursor，但後因價格策略改變，轉向 Codex。

對 AI 程式生成的觀察

他指出：

GPT-3 時代：AI 生成的程式能執行，但與既有 codebase 格格不入；
GPT-4.5 / GPT-5：AI 能讀懂上下文，生成符合團隊架構的代碼；
對前端 UI：Claude 稍佔優勢；
對後端邏輯：Codex 更穩定可靠。

他強調：

「我的任務不是每天換工具，而是確保整體系統運作一致。」

他會定期審查團隊使用的 AI 工具與 API 接口，確保安全、隱私、效能都在控制範圍內。

ityesh Agarwal（Cora 工程師）— 專注單任務的「深潛型開發者」

Nityesh 是「極簡開發」的代表，他只用一台 MacBook Air M1，且只用一款工具：
Claude Code（Max 方案）

專注式開發流程

在正式開寫前，他花數小時研究 codebase、設計流程，並用 Claude 進行思維驗證。
寫程式時，僅開一個終端，不切換視窗、不同時運行其他 AI。
Claude 若出現模糊或幻覺，他會立刻中斷並要求解釋，確保邏輯一致。

協作整合

他將 Claude 直接連接至 GitHub：

Claude 提交 Pull Request；
團隊成員逐行評論；
Claude 根據評論自動修正後再提交。

這種「AI 寫、團隊審」的工作模式讓程式審查變得高度自動化卻仍保留人工把關。

共通啟示：人機協作的黃金法則

原則	說明
1. 規劃先於開發	先用 AI 協助定義任務範圍與優先級，減少返工。
2. 明確的時間節奏	採取早午分段制或固定實驗時段，避免分心。
3. 單一真實來源（Source of Truth）	任務、程式、設計都集中在固定系統（如 Linear、GitHub）。
4. 人工監督 AI	中斷、提問、比對是保持品質的關鍵。
5. 個性化但協同一致	六人各有風格，但交付標準一致。