想像一個個人開發的軟體儲存庫，GitHub 的 Issue 與 Pull Request 連續編號已經接近四位數。
第一個直覺很容易是：
「一個人快做了1000次開發？」
接近，但不能這樣直接換算。GitHub 在編號體系中把每個 Pull Request 都視為一種 Issue，同一個儲存庫裡 Issue 編號與 Pull Request 編號不會重複。因此，序號接近1000，代表兩者共用的連續編號走到這裡，不代表完成了1000個 Pull Request。[1]
真正有趣的問題反而是：
如果這種規模的修改、檢查、修復、發布與營運大多由人不用AI、靠手工完成，需要多少成本？商業上還能不能成立？
這正是AI時代個人開發很值得算的一筆帳。
1. GitHub編號不是健身房的重複次數
儲存庫編號不是工作量計。
有人一個 Pull Request 改2000行，有人只改一行CSS也開一個 Pull Request。Bug、設計筆記、功能需求、調查任務等 Issue 也會使用同一套編號空間。
所以：
接近1000號，不等於1000個人的工作量。
也不等於：
接近1000個完整功能。
這個數字比較像閘門的通過計數器，而不是體重計。
不過，如果短時間內真的累積了大量小修改，它仍然透露一件事：
設計 → 實作 → 驗證 → 修復的循環被重複執行了很多次。
要計算人工成本，真正該看的是一次實質循環平均花多少時間，而不是只看編號。
2. 每件事看起來很小時，最容易低估人工成本
日本一份在2026年9月公布、以自由接案工程師案件刊登資料為基礎的報告顯示，2026年8月的平均月度案件單價為78.9萬日圓。[2]
這不是所有工程師的薪資，也不是任何特定人的時薪，只是該市場刊登案件的平均值。
但它可以作為一種替代成本基準：如果要從外部購買相似的專業工程能力，大概是什麼量級？
用每月160小時計算，約為每小時4930日圓。
現在假設有 1000個實質性變更單位。注意，這只是計算例子，不等於GitHub的#1000。
| 每次變更平均時間 | 總時間 | 以160小時/月換算 | 以78.9萬日圓/月估算 |
|---|---|---|---|
| 15分鐘 | 250小時 | 1.56人月 | 約123萬日圓 |
| 30分鐘 | 500小時 | 3.13人月 | 約247萬日圓 |
| 45分鐘 | 750小時 | 4.69人月 | 約370萬日圓 |
| 1小時 | 1000小時 | 6.25人月 | 約493萬日圓 |
| 2小時 | 2000小時 | 12.5人月 | 約986萬日圓 |
| 3小時 | 3000小時 | 18.75人月 | 約1479萬日圓 |
| 4小時 | 4000小時 | 25人月 | 約1973萬日圓 |
即使每次只要15分鐘，1000次也會變成250小時。
「每件都很輕」不代表「總成本很輕」。
而且小任務也有固定流程：調查、建立分支、審查、測試、合併、部署確認與回復判斷。
全部靠人做下去，名片很快會變成摺頁：作者、翻譯、前端、後端、QA、基礎設施、總編，一張塞不下。
3. 「我自己做，所以人工成本是0」在現金帳上可以成立，在經濟比較裡是另一回事
一個個人網站每月主機費1000日圓，廣告收入5000日圓。
用現金來看，確實賺4000日圓。
但如果站長每月花50小時，做商業比較時就需要另一個角度。
至少把兩種數字分開：
現金利潤 = 收入 − 實際現金支出
勞動調整後利潤 = 收入 − 實際現金支出 − 自己的工作時間 × 選定的替代時薪
如果本來就是興趣，把自己的時間算成0完全合理。沒有人玩50小時遊戲後說自己產生了50小時人事虧損。
問題只出現在把興趣帳直接當成「商業上很賺錢」的證據。
學習、樂趣、作品成就感與聲譽都是真實回報，只是它們不等於商業利潤。
做商業比較時，不能因為沒有人開薪資單給自己，就假裝時間不存在。
4. 廣告模式需要的分母，可能比想像大得多
廣告收入可以先用一個簡單公式理解：
廣告收入 = 頁面瀏覽量 ÷ 1000 × 實際RPM
實際RPM會隨國家、裝置、廣告格式、季節、主題與讀者族群大幅變動。
因此這裡不假裝有一個統一的市場RPM，只用假設值看數量級。
如果希望只靠廣告每月回收78.9萬日圓：
| 假設的實際RPM | 每月回收78.9萬日圓所需PV |
|---|---|
| 100日圓 | 約789萬PV |
| 300日圓 | 約263萬PV |
| 500日圓 | 約158萬PV |
| 800日圓 | 約99萬PV |
這不是對任何特定網站廣告收入的預測。
它只說明：
如果把人工用市場替代成本計價，想單靠廣告回收，有時會需要非常大的流量。
因此很多人工營運的網站不只靠廣告，而是把聯盟行銷、商品銷售、客戶開發、會員、贊助、品牌價值甚至興趣價值一起算進去。
5. AI改變的不只是「寫文章的速度」
如果把AI價值縮成「30秒寫一篇文章」，就漏掉了大部分經濟意義。
營運一個Web媒體有很多周邊流程：
- 找題目
- 調查
- 寫稿
- 查核事實
- 改程式
- 測試
- 多語化
- 發布
- 驗證線上實際結果
- 修復故障
- 分發到社群平台與電子報
- 看數據後改善
完全靠人工時，流程越多，變動人工成本通常越高。
AI加上自動化後，前期系統設計成本可能更高，但 第二篇、第十篇、第一百篇的新增成本有機會下降。
這不只是「作者寫快了」。
更接近：
一個人可以擁有一個小型編輯部與開發團隊的操作系統。
人並沒有消失。
人的角色移向輸入、判斷、規格、品質標準、例外處理與治理。
從每個產物都親手製作的人，轉成工廠設計者兼總編。
6. AI不是插上就一定加速的魔法氮氣
研究結果並不是一路朝同一方向，這點反而很重要。
2023年公開的一項 GitHub Copilot 對照實驗中，在指定的 JavaScript HTTP 伺服器任務上，可使用AI的組別比對照組快55.8%。[3]
但METR在2025年的隨機對照試驗得到相反結果：16名資深開源開發者在自己熟悉多年的成熟儲存庫中完成工作時，允許使用當時AI工具後，平均反而多花19%的時間。[4]
METR在2026年2月又表示，後續實驗越來越難解讀。越來越多開發者不願參加「禁止使用AI」的條件，多代理並行工作也讓實際工作時間更難量測。較新的AI可能確實比2025年初提供更大的加速，但受到選擇偏差與量測問題影響，不能用新資料很有把握地說出一個精確百分比。[5]
所以結論不是：
AI永遠快55%。
也不是：
AI會讓專家慢19%。
效果取決於任務、對程式庫的熟悉程度、代理工作流、審查負擔、平行化與測試環境。
AI可以高速產生正確結果；系統設計差時，也能高速量產Bug。
真正該量的是自己的實際流程。
7. 純手工網站不一定會輸
高度自動化的AI系統並不保證比手工網站更賺錢。
以下情況中，手工很可能仍然合理：
- 每月只發少量文章
- 專家本人文字就是商品
- 一篇文章就能賣高價產品或服務
- 不需要多語和大規模分發
- 更新很少
- 製作本身就是興趣
- 建立自動化的成本高於能省下的人工
而自動化比較容易發揮效益的情況是：
- 同一流程反覆出現
- 維護多種語言
- 內容數量持續增加
- 每次都要QA、發布與線上驗證
- 分發管道越來越多
- 人不斷重做相同檢查
本質上是固定成本與變動成本的競爭。
AI工廠前期貴。 手工工坊每件產品貴。
還要記住：就算造出一座極先進的全自動工廠，如果沒有任何讀者，它也不是未來媒體，而是一座非常高科技的倉庫。
8. 想看一個「不用AI、主要靠手工」網站的真實採算，問這些數字
不用評價那個人。
如果只是比較營運模式，下面幾個數字已經很有用：
- 每月站長投入時間
- 每月PV或獨立訪客
- 月收入與現金支出
- 文章總數與每月新增文章數
- 營運語言數量
- 營運年限與初期建置大致工時
然後可以算：
現金利潤 = 收入 − 現金支出
站長現金回報時薪 = 現金利潤 ÷ 工作時間
勞動調整後利潤 = 現金利潤 − 工作時間 × 比較時薪
每篇文章的邊際成本 = 新增寫作 + 翻譯 + QA + 發布 + 分發所需的時間與費用
最後一項尤其重要。
過去花過1000小時，不如 現在再發布下一篇要幾小時 能說明未來的經濟性。
9. AI個人開發真正強的不是大量，而是可重複
一夜產生大量檔案，現在已經不是最難的事情。
難的是把系統做到：
- 下次還能套用同一品質標準
- 只重做失敗的範圍
- 防止重複發布
- 能辨識目前版本
- 驗證真正上線後的結果
- 某個管道被卡住時其他工作仍能繼續
- 只有必須由人完成的認證才交還給人
- 之後能追查發生過什麼
這不是單純的生成量。
這是 營運資產。
手工網站也可以透過流程文件、範本、CMS、自動備份與檢查表逐步累積同樣的資產。
AI時代的差異在於，一個人現在可以把這些營運層做得非常深。
10. 結論：比「有沒有到1000」更有意思的是「下一個單位多少錢」
Issue與Pull Request的連續編號接近四位數，看起來確實很驚人。
但不要把它當成生產力分數。
更值得看的數字是：
人工工作時間 單次變更成本 單篇文章邊際成本 發布前返工率 站長每小時產出 相對於收入的勞動調整後利潤
手工網站完全可能賺錢。
使用AI的網站也完全可能虧損。
但每次都由人手工完成寫作、翻譯、開發、QA、發布、監控與分發，和先投資建立系統、之後持續降低邊際成本，是兩條非常不同的成本曲線。
接近1000的編號之所以有趣，不是因為它像一枚勳章。
真正值得看的問題是：
這麼多次試錯中，有多少最後變成了「下一次不需要人再重複相同動作」的系統？
這才是AI個人開發在經濟上最有意思的地方。
參考資料（5筆）
- GitHub Docs — Issue event types / REST API. GitHub states that every pull request is an issue, but not every issue is a pull request, and that issue and pull-request numbers do not overlap within a repository docs.github.com
- En Japan / Freelance Start, 2026-09-03. August 2026 freelance-engineer listings averaged ¥789,000 per month; 445,327 listings were included at month end. This is a marketplace listing statistic, not a universal salary or an observed cost for any person discussed in this article prtimes.jp
- Peng, S., Kalliamvakou, E., Cihon, P., & Demirer, M. (2023). “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot.” In a controlled JavaScript HTTP-server task, the treatment group completed the task 55.8% faster arxiv.org
- Becker, J., Rush, N., Barnes, B., & Rein, D. / METR (2025-07-10). “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity.” Sixteen experienced developers completed 246 tasks in mature repositories; allowing early-2025 AI tools increased completion time by 19% on average in this study metr.org
- METR (2026-02-24). “We are Changing our Developer Productivity Experiment Design.” METR reports that later productivity experiments suffered from participant-selection and time-measurement problems, especially as developers became reluctant to work without AI and used multiple agents in parallel; the newer data are weak evidence for the size of current speedup metr.org
