摘要
這篇從一個很小的需求開始：把 YouTube Shorts 藏起來。我把需求交給 Codex，8 分多鐘後拿到完整的 Chrome 擴充功能專案，接著再請它把成品安裝進 Arc 瀏覽器。透過這次實作，我們可以看到 Coding Agent 如何從一句需求往下處理專案、檔案、安裝與調整，也能理解第一次使用 Codex 時，為什麼適合先挑「範圍小、需求具體、結果可驗收」的任務。

引言

我只是想上 YouTube 查一支教學，結果又被 Shorts 吸走十幾分鐘。

這種小問題以前我大概只有兩個選項：忍著用，或去找別人做好的擴充功能。自己做一個？光想到還要學 Chrome Extension，我就會先放棄。

這次我換了方式，直接把需求丟給 Codex：

幫我做一個可以隱藏 YouTube Shorts 的 Chrome 擴充功能。

不到十分鐘，專案真的出現在我的電腦裡。我又補了一句：「幫我安裝到 Chrome。」最後，原本一句「我不想看到 Shorts」，真的變成一個可以使用的工具。這次實際做完之後，我也終於比較知道 Codex 該怎麼理解了。

接下來我會把這次實戰過程拆開來看。讀完這篇，你會知道 Codex 實際接手了哪些開發工作，以及第一次使用時，什麼樣的任務最適合拿來交給它。

以前遇到這種需求，我會先去找別人做好的

我上 YouTube 通常有很明確的目的：找一支教學、查一個產品，或把稍後觀看的影片補完。

麻煩的是 Shorts。

首頁往下一滑就會看到，側邊欄也有入口。有時只是順手點進去，回神已經過了十幾分鐘。
以前碰到這種問題，我的第一個反應大概是搜尋：

YouTube Shorts 隱藏 Chrome 擴充功能
然後從別人做好的工具裡挑一個。

「自己做」幾乎不在選項裡。

Chrome 擴充功能對我來說一直是工程師的工作。搜尋開發方式，很快就會看到 manifest.json、JavaScript、DOM、權限設定。光是判斷第一步該做什麼，就已經超出我平常使用電腦的範圍。

這次我想看看 Codex 能把這段距離縮短多少。
我打開一個新的本機專案，直接把需求寫進去：

我想做一個自己的 Chrome 擴充功能。
開啟之後，自動隱藏 YouTube 首頁、側邊欄與導覽列裡的 Shorts。
我沒有開發 Chrome Extension 的經驗，請幫我建立完整專案。
做好後也告訴我怎麼在 Chrome 本機載入並測試。

送出之後，我就等它處理。

這也是我第一次刻意不先查 Chrome Extension 教學。
我想看的很單純：如果我能把需求講清楚，Codex 會把它做到什麼程度？

一句需求，怎麼變成可以安裝的 Chrome 擴充功能

Codex 跑了 8 分 42 秒。之後我電腦畫面右側多出一份 README，專案名稱叫做「Shorts 靜音鍵」。

它把功能列得很清楚：預設隱藏 YouTube 電腦版的 Shorts 推薦區塊、Shorts 卡片、側邊欄入口與 Shorts 分頁，工具列圖示可以暫停或重新啟用。README 往下就是安裝步驟：打開 Chrome 擴充功能頁面、開啟開發人員模式、載入未封裝項目，再選取 Codex 建好的 youtube-shorts-hider 資料夾。

〔截圖 1：輸入需求約 8 分鐘後，Codex 已建立「Shorts 靜音鍵」專案，右側 README 同時整理功能與本機安裝步驟〕

看到這裡，我原本準備照 README 自己安裝。
後來想到 Codex 現在也能操作電腦，我又補了一句：

直接使用電腦，代勞我安裝在Chrome 瀏覽器。

Codex 回來後告訴我擴充功能已經裝進Chrome 瀏覽器，也重新整理了 YouTube。
我打開 Chrome 瀏覽器的插件頁面，「Shorts 靜音鍵 — 隱藏 YouTube Shorts 1.0.0」已經躺在裡面。左邊有圖示，右下角有開關。

我把開關關掉，再打開，接著回到 YouTube 看結果。

〔截圖 2：Codex 已將「Shorts 靜音鍵」安裝到 Chrome 瀏覽器，擴充功能頁面可直接控制啟用與停用〕

十幾分鐘前，需求還停在一句「我不想在 YouTube 看到 Shorts」。現在瀏覽器裡多了一個可以開關的工具。
這段過程很適合拿來觀察 Codex 的工作方式。需求送出去之後，它先建立專案、整理檔案，再把安裝方式寫進 README；我提出下一個動作後，它又接著操作電腦，把成品裝進瀏覽器。

我負責描述需求、看結果、決定下一步。

做到這裡，就可以開始拆一個更重要的問題：剛才這段流程，和叫 ChatGPT 幫忙寫一段程式，到底差在哪？

看懂 Codex：它接手的是一段開發流程

過往的時候，如果是自己從零寫程式，從「我想做這個工具」到「它真的能用」，中間通常還有一串工作：查資料、找教學、寫程式、建立專案結構、設定環境、除錯、安裝，再回頭測試。

Codex 把這段流程壓縮了。我先描述需求，它接著建立專案、處理檔案、完成開發，再把工具裝進瀏覽器。最後由我打開畫面驗收，看到問題再繼續調整。

〔圖解 3：傳統人手動開發與使用 Codex 的流程對比；左側由人處理查資料、寫程式、建專案、除錯與安裝，右側由 Codex 接手大部分開發流程，人主要負責描述需求與驗收結果〕

這張圖可以幫我們抓住 Coding Agent 最容易被忽略的一點：它接手的是一段開發流程。

像這次的「Shorts 靜音鍵」，我從一句需求開始，Codex 往下完成專案、檔案與安裝。我的工作則集中在需求、判斷與驗收。

如果你第一次接觸 Codex，可以先觀察這件事：從想法到成品之間，原本哪些步驟得自己查、自己做、自己排錯，現在開始能交給 Agent 往下跑。

第一次用 Codex，我會建議挑這類任務：

• 範圍小：幾十分鐘內能看到成品
• 需求具體：可以直接說清楚要改什麼
• 結果可驗收：打開畫面就知道成功或失敗

「隱藏 YouTube Shorts」剛好符合這三個條件。重新整理頁面後，Shorts 還在不在，一眼就能確認。

同樣的方式也可以套到其他小工具：替常用網站加一顆快捷按鈕、整理下載資料夾、把重複操作包成腳本，或替自己的工作流程做一個很小的內部工具。

先從這種任務開始，會比較容易看懂 Codex 在做什麼，也比較容易知道下一句該怎麼要求它。

等你親眼看過一次完整流程，「Codex 是什麼」就不需要靠產品定義硬背了。

你已經知道它能接手哪一段工作。

小補充：這款插件正在審核中
等到開發出來那天與大家分享，八分鐘解決注意力問題，超划算

結論

做完「Shorts 靜音鍵」後，我對 Codex 的理解具體很多。

以前想到自己做一個工具，我會先想到要學哪個語言、專案怎麼建、錯誤怎麼排。這次我從需求開始，十幾分鐘後，Chrome 瀏覽器裡已經多了一個能開關的 Chrome 擴充功能。中間的專案建立、檔案處理與安裝流程，大部分由 Codex 往下推進，我則負責描述需求、看結果，再決定下一步。

這也提供了一個很實用的 Codex 入門方法：先找一件你早就希望電腦幫忙、而且結果一眼能驗收的小事。 做過一次完整流程後，Coding Agent 這個詞就不再只是產品介紹裡的名詞。