Qoder談AI原生研發重塑

從許願式開發，走向Spec先行

分享一開始便直指常見落差：不能只寫下一個願望，就期待 Coding工具直接產出可上生產的成果。即使一次性的 plan 看似精彩，它若沒有持久化、結構化，也沒有驗收設計，便難以成為團隊可複用、可累積的工程資產。

「Talk is cheap，但是現在情況我們更傾向於說，Code is cheap。」
— 宋文龍（聞可）

因此，研發流程應採取Spec先行，並把Spec當作需要生產、管理與治理的正式資產。講者觀察到，善用 Coding工具 的團隊會重度投入Spec的建立與維護，對Spec的管理甚至可能比程式碼管理更受重視。

• Spec要明確描述具體使用場景與實作要求，避免模型在模糊敘述中自行補足關鍵假設。
• 驗收條件必須預先寫入，包括可接受的結果、必要門禁，以及無意義、高風險或不允許執行的行為。
• 清楚的約束讓模型在可控制的範圍內探索與執行，而不是把一次對話當成不可追溯的黑盒子。

Spec先行Spec驅動開發持久化Spec結構化資產Validation門禁工程Code is cheap

團隊級Harness：把知識、Skill與上下文接上治理

講者將Harness拉高到團隊尺度討論。它不僅是個別Agent的能力配置，也涵蓋Skill、MCP與上下文管理；要真正有效，必須透過整個團隊的共同執行，讓知識能被管理、生成並持續治理。

這背後是能力工程的問題。Skill本身很容易生成，但也可能快速氾濫；團隊必須辨識哪些Skill值得沉澱、哪些只適合個人情境，以及如何避免工具能力變成缺乏品質控管的堆積。個人筆記特別標出門禁工程，也呼應這項工作不是單純產生能力，而是替能力建立可用、可信與可控的邊界。

Harness團隊級HarnessSkillMCP上下文管理能力工程知識治理門禁工程

測試不是縮減，而是成為全員責任

同一個模型、同一個Agent，為何不同團隊得到的成果差異很大？講者的答案有三個來源：前置輸入不同、Spec不同、基礎知識不同，以及反向要求的驗收點不同。這也意味著，AI時代的測試工作不會淡出，反而會更重要。

• 測試人力的配置可能改變，但驗收、測試案例與品質門禁的價值會提高。
• 團隊需要把測試驗證建進整體工作流，再讓 Coding工具 與程式碼生成進場。
• 講者提到Qteam中有成員專業、全職投入撰寫測試與測試用例，顯示測試是AI研發流程的專門能力。
• 若缺少上述基礎工作，Coding工具或Agent或許能抬高成果下限，卻難以推升團隊的交付上限。

「以前我們講人人都是產品經理，現在人人都是測試員。」
— 宋文龍（聞可）

測試驗證測試用例驗收點品質門禁人人都是測試員Qteam

人帶Agent Team，協作從工具使用升級為網路

從「每人配一個Agent、把它當工具」出發，分享提出更進一步的理想：人應帶領一個Agent Team。每位成員都可以成為具備專屬設定與偏好的超級個體；在其周圍，開發、設計、產品、測試等專家型Agent各自分工，並由人來帶領與決定。

更理想的形態，是人與Agent Team交織成協同網路。以Qteam的實踐為例，講者描述每位同學都配有自己的Agent工具；「我的Agent去問他的Agent」不再只是想像，而是協作網路真正開始運轉的訊號。

• Agent Team可容納不同專家角色，讓任務依專業分流與拆解。
• 人仍需管理目標、配置與協作關係，而非把所有判斷完全外包給Agent。
• 多Agent也是交叉檢視的機制：不應只讓同一個Agent自行產生、再自行判定成果。

Agent Team超級個體人機協同協同網路多Agent專家模式Qteam

組織轉型的答案：短鏈決策、人才密度與低協調成本

當客戶詢問Agent轉型時，焦點往往不只是技術與產品，也會落到職責如何調整、組織如何重新配置等現實問題。講者沒有給出單一標準答案，但提出一組更適合Agent時代的組織方向：極短的決策鏈、極高的人才密度、極低的人際協調開銷，以及極強的決策洞察。

Agent隨時等待任務、產出速度很快，若人的決策與授權仍層層傳遞，反而會形成新的瓶頸。講者援引布魯克斯定律指出，在進度落後的專案中加人可能讓進度更落後；根源在於人數增加後，人與人之間的溝通與協調成本會急遽上升。

• 人因Agent而提升能力後，組織更應追求高人才密度，而不是只以增加人數回應工作量。
• 傳統One Pizza Team約七、八人的經驗，在Agent工具普及後仍可繼續往更精簡的方向思考。
• 人的創造力、判斷力與選擇仍不可取代；Agent並非通用的人，領導者的決策洞察更顯重要。

Agent轉型決策鏈人才密度協調開銷布魯克斯定律One Pizza Team決策洞察

產品落地：以Qoder CLI承接方法論

分享後段回到Qoder的產品實作。講者表示，前述方法不是抽象口號，而是團隊在實際問題中持續處理、再沉澱進產品的能力。Qoder的不同產品形態皆以Qoder CLI為基礎，IDE與雲端Agent也透過Qoder CLI實現；客戶可用CLI包裝成自己的客製化Agent。

在方法對應上，RepoWiki用於支援企業知識管理，Coding工具提供強化的Spec模式，並搭配Harness與相關SDK能力。重點仍然不是工具名稱本身，而是讓知識管理、Spec驅動、Agent執行與驗收治理能在同一套研發系統裡連結。

QoderQoder CLIRepoWikiIDE雲端AgentSDK客製化Agent

白天寫Spec，夜間讓Agent跑出成果

Spec模式最具畫面感的使用情境，是把人的高判斷工作與Agent的大量執行工作拆開：白天仔細寫好複雜Spec，夜間交給Coding工具執行，隔天再依產出的程式碼推進上線。個人筆記將這一段濃縮為「白天寫spec，晚上跑程式」，也精準點出工作節奏的改變。

這類模式仍有前提：Spec要寫得好，工具本身也要能承接長任務。講者並提及目標驅動的執行方式，例如提高測試覆蓋率或進行程式碼遷移，使用者可給定明確目標，讓Agent自主執行並在遇到重大卡點時才回到人手上處理。

• 長時間、目標明確的工作可由Agent持續推進，但不代表人可以放棄設計目標與驗收。
• 專家團模式可配置多個自有Agent，協助拆解任務與協作。
• 產品經理與測試角色如何協同，不只靠人際交辦，也可以透過Agent之間的工作安排串接。

把人放回關鍵處：規則、審查與反過度工程

講者反覆提醒，工具只提供方法與思路；若不寫規則、不拆任務、不做審查，每一次使用都只會停留在一次性的工具互動，無法沉澱為個人或團隊的品質。Spec先行、多Agent、上下文與知識管理，必須共同進入日常工程流程。

人不必逐行檢視所有AI生成程式碼，但必須依自身能力與風險判斷，在真正重要的點介入。講者提醒，AI可能一次生成大量程式碼，也可能產生看似完整卻過度工程化的內容；產出很詳細，不等於已經能順利運行。因此，人的工作從大量手工產製，移向設定邊界、辨識風險、審查結果與做出取捨。

人工審查任務拆解上下文交叉檢視過度工程化風險判斷人機分工

知識四層與保鮮：讓Agent從程式碼走進領域

在知識治理案例中，講者特別強調「知識四層」的觀念。程式碼是重要基礎，但程式碼本身並不夠；團隊還有內部流程、資料，以及與特定領域有關的重要知識。若缺乏這些脈絡，Agent即使能理解通用問題，也難以穩定處理需要專業領域知識的任務。

知識治理也不能是一次性整理。案例中提到，會先透過Knowledge Card補充前置知識與額外資訊，遇到問題後再調整；但更重要的是維持知識保鮮，淘汰舊內容、讓新知識持續生成。當程式碼或相關內容變化後，知識庫應更新，並通知內部與關聯團隊，讓產品、營運與測試用例能隨之調整。

• 將知識視為需要像編譯程式碼般處理的工程對象，提供給Agent使用與生產。
• 以Knowledge Card補足通用模型容易出現的空泛表述與領域資訊缺口。
• 知識更新必須串連下游工作：相關團隊收到變更後，產品、營運與測試都要依影響範圍更新。
• 垂直Agent的可用性，建立在持續可維護的領域知識與流程脈絡之上。

知識四層Knowledge Card知識保鮮領域知識垂直Agent程式碼知識流程與資料

從單點工具到研發OS：Qoder的內部實踐

講者以Qoder內部實踐說明，團隊一方面生產Coding工具，另一方面也使用Coding工具，因此會直接面對模型與工具的不確定性。其核心構想是讓需求進入後，由Coding Agent承接流程中多個環節；透過Graph中的設定與交付物，將多個Agent串成可運作的研發流程。

個人筆記標出的垂直agent，正是這段分享的關鍵：不是把Agent孤立地當成單一功能，而是使其建立在特定領域的知識、任務流程與協作關係上，逐步形成面向研發的作業系統式能力。

講者指出，Qoder在全球已有上百萬用戶，面對大量每日問題時，若完全依賴人工處理將難以負荷；這也是將Agent化流程與知識治理投入產品及研發現場的實際意義。

重點回顧：AI時代，人更重要，只是重要方式改變

這場分享的結論並非「Agent取代人」，而是人的重要性重新定位。當Agent能快速生成與執行，人更需要提供正確輸入、界定真實問題、管理知識與驗收，並在組織中做出高品質決策。軟體工程面對的真實複雜性不會自動消失，AI帶來的是重新分配工作、壓低協調成本並放大人類判斷的機會。

「人的重要性也越重要，人的重要方式變了。」
— 宋文龍（聞可）

• 以Spec先行取代許願式開發，將需求、場景、約束與驗收變成可管理資產。
• 以團隊級Harness治理Skill、MCP、上下文與知識，避免能力氾濫卻無法複用。
• 把測試與驗收前置，讓人人都是品質責任的一環。
• 讓人帶領Agent Team，透過多Agent協作與交叉檢視形成協同網路。
• 組織轉型應縮短決策鏈、提高人才密度、降低人際協調開銷，並保留人的關鍵判斷。
• 把知識做成持續更新、可通知下游團隊的治理系統，支撐垂直Agent與長期研發能力。

AI NativeCoding AgentSpec驅動開發Agent Team知識治理測試驗收組織轉型人機協同