我們需要一個 AI Prototype 殺手 — 用評分表擋住 90% 不該做的功能

我們團隊今年用 AI 生了十幾個 prototype。最後只有兩個上線。

問題不是 AI 不好用。問題是我們太晚說不。

生產力幻覺

先說一個反直覺的數據。

METR 在 2025 年做了一場隨機對照實驗：讓資深工程師在自己熟悉的 codebase 上使用 AI coding 工具。結果呢？平均慢了 19%。不是快 19%，是慢 19%。而且這些工程師在實驗後仍然「覺得」自己變快了。

2025 Stack Overflow Developer Survey 也指出類似的現象：近半數開發者表示，debug AI 生成的 code 比自己寫還花時間。螢幕上出現了很多 code，commit 數量暴增，但理解、驗證、整合這些 code 的隱藏工時，往往比從零開始更長。

這就是我說的生產力幻覺。AI 讓產出「看起來」爆量成長，但真正的瓶頸從來不是打字速度——是判斷力。而判斷力不會因為 code 生得更快就自動提升。

消失的看門人

在 AI coding 工具普及之前，over-engineering 有一個天然的制約機制：做不完。

想做一個有多畫面的內部管理平台？要寫前端、後端、串 API、搞部署、處理權限。一個工程師估一估，兩週起跳。PM 聽到兩週，自然會問：「這個問題值得花兩週嗎？」

這個問題本身就是看門人。它擋掉了大量「聽起來不錯但其實不值得」的需求。

現在這個看門人消失了。

用 Cursor、Claude Code、Copilot，一個下午就能生出完整的 prototype——有前端、有後端、有資料庫 schema、甚至有部署腳本。Andrej Karpathy 管這叫 vibe coding：「完全交給 AI，擁抱指數成長，忘掉 code 的存在。」從「想法」到「看得到的東西」之間的摩擦力趨近於零。

摩擦力消失聽起來是好事。但摩擦力同時也是過濾器。

AI 是放大器，不是方向盤。 它等比放大你做對的事，也等比放大你做錯的事。如果你原本就善於取捨，AI 讓你快十倍交付精準的方案。但如果你本來就有過度設計的傾向——想做的比需要的多、規劃的比驗證過的大——AI 會讓你一個下午就把 over-engineering 推到極致，而不是像以前那樣在第三天因為「寫不完」而被迫收斂。

當任何人都能在午餐後生出一個看起來很專業的 demo，你會發現團隊裡開始出現一種新型態的浪費：prototype 通膨。每個人都有想法，每個想法都能快速變成 prototype，每個 prototype 都會佔用後續的討論時間、review 時間、部署資源、維護承諾。

有人負責說 yes 很容易。但誰來說 no？

為什麼你需要一個「AI 功能殺手」

我不是在說你需要一個專門否決所有東西的人。我是說，你需要一個結構化的判斷機制，在 prototype 從「午後靈感」變成「排進 sprint」之前，先過一關。

這個機制的核心不是技術審查，是價值審查。

技術審查問的是「做不做得到」。在 AI 時代，答案幾乎永遠是「做得到」。但這不是對的問題。對的問題是：

• 這個問題是真的嗎？
• 現有的工具真的解不了嗎？
• 做完之後誰來養？
• 花這個力氣值得嗎？

為了系統性地回答這些問題，我整理了一份 PRD 殺手評分表。

評分表：五個核心問題

完整版有 10 個構面，但實戰中我發現有 5 個問題的殺傷力最大。如果這 5 題你答不好，其他 5 題答得再漂亮也沒用。

1. 問題真實性（1-5 分）

你要解的問題，有數據支撐，還是靠感覺？

• 5 分：有量化數據，用戶主動抱怨超過三次，能指出具體的時間/金錢損失
• 3 分：有人提過，但沒有數據，痛度不確定
• 1 分：「我覺得大家應該需要這個」

紅旗規則：≤ 2 分直接亮紅旗。連問題都不確定存在，就不該開始寫 code。

2. 現有工具替代性（1-5 分）

Google Sheet、Notion、Airtable、甚至一個 Slack reminder 能不能解決 80%？

• 5 分：找遍了，現有工具完全無法處理這個場景
• 3 分：現有工具能解一半，但有明確的缺口
• 1 分：Google Sheet 就能做，只是沒人花時間設定

紅旗規則：≤ 2 分直接亮紅旗。如果現成工具就能解，你在造的不是產品，是履歷。

3. 用戶規模與採用率（1-5 分）

做完之後，多少人會真的打開來用？不是「可以用」，是「會用」。

• 5 分：50+ 人的日常工作流程會直接受益，有明確的 adoption path
• 3 分：10-20 人偶爾會用
• 1 分：5 人以下，而且他們現在用 Excel 也活得好好的

4. 維護者明確度（1-5 分）

Build 完之後，誰養這個東西？Bug 誰修？API 改版誰跟？

• 5 分：有明確的 owner，已納入團隊 roadmap，有維護預算
• 3 分：提案人願意花 20% 時間維護，但沒有正式承諾
• 1 分：「我用 AI 生的，應該不用怎麼維護吧？」

這一題是隱形殺手。 我見過太多 prototype 在 demo 那天光芒萬丈，三個月後變成沒人敢碰的遺跡。CodeRabbit 的研究指出 AI co-authored code 的重大問題率是人寫的 1.7 倍、安全漏洞率 2.74 倍——而這些問題最終都落在維護者頭上。AI 生成的 code 不會自己 maintain。

5. 技術複雜度 vs 問題價值（1-5 分）

你正在蓋的東西，跟你要解的問題，scale 對得上嗎？

• 5 分：技術方案精準對應問題規模，沒有多餘的架構
• 3 分：有點 overbuilt，但還在合理範圍
• 1 分：為了管 10 個人的週報，搞了 FastAPI + Cloud SQL + OAuth + Slack Bot + AI 摘要

決策區間

五題加總，滿分 25：

另外有一條硬規則：紅旗超過 2 面，不管總分多少，原則上不進正式開發。

實戰案例 A：某「內部數據管理平台」

背景：團隊有一批散落在各處的內部數據——週報、進度追蹤、跨部門指標——有人提案做一個整合平台，把資料彙整、視覺化、通知提醒、權限控管全包進去，規劃了五六個完整模組。

用 AI coding 工具，兩個下午就生出了 prototype。有 dashboard、有篩選器、有匯出功能、甚至有 AI 自動摘要。Demo 當天大家都說讚。

拿出評分表：

總分：9/25。紅旗：3 面。判定：直接砍。

這個案例完美展示了 AI 時代的陷阱：因為做起來太快，所以跳過了「該不該做」的判斷，直接衝到「怎麼做」。而生產力幻覺讓所有人都覺得「反正也沒花多少時間」——但真正的成本不是那兩個下午，是之後每一次 sprint planning 裡它佔掉的討論時間，是 Cloud Run 上跑著的那個沒人看的 instance，是三個月後有人問「這個服務還要不要維護」時所有人面面相覷的尷尬。

實戰案例 B：某「客戶數據問答機器人」

背景：業務團隊每天要查客戶數據——廣告花費、訂單趨勢、活躍度指標。每次都要找數據分析師拉報表，來回要半天到一天。

提案做一個 chatbot，讓業務直接用自然語言問問題，後面接 Looker API 拉即時數據。

總分：21/25。紅旗：0 面。判定：可以正式規劃。

同樣是 AI 工具，同樣是內部需求，但跑一次評分表，高下立判。

評分表不是反創新

我知道有人會說：「這不就是官僚嗎？創新需要空間，不是每個 idea 都要先被審判。」

我同意。但有兩件事要分開看：

探索和承諾是兩回事。

你用一個下午生 prototype 來探索想法？完全沒問題，這正是 AI 工具的價值。但當這個 prototype 開始被放進 sprint、開始要求 code review、開始佔用 Cloud Run 的 instance、開始出現在週會的進度報告上——它就不再是探索，它變成了承諾。

評分表管的是從探索到承諾的那個轉折點。

先殺掉爛案，才有資源養出好案。 如果你的團隊同時在養 10 個 prototype，每個都半死不活，那真正有價值的那 2 個也拿不到足夠的注意力。殺掉 8 個，才能把資源集中在值得的 2 個上。

帶走這個

附上簡化版評分表，歡迎拿去殺你團隊的下一個 AI prototype：

□ 問題真實性：有數據支撐，還是靠感覺？（≤2 紅旗）
□ 現有工具替代性：Google Sheet 能解嗎？（≤2 紅旗）
□ 用戶規模：多少人會真的用？
□ 維護者明確度：build 完誰養？
□ 技術 vs 價值：是不是為了小問題蓋大平台？

每項 1-5 分，滿分 25
→ 10 以下：直接砍
→ 11-15：先用現成工具
→ 16-19：限時限範圍 PoC
→ 20+：正式推進
→ 紅旗 ≥ 3：不管幾分，原則上不做

如果你對 AI prototype 通膨、vibe coding 踩過的坑有興趣，我之前也寫過幾篇相關的實戰紀錄，有機會再整理分享。

這篇文章基於真實的團隊經驗整理。案例細節已匿名化處理。評分表持續迭代中，完整版含 10 個構面和紅旗機制。

引用來源：METR 2025 RCT、2025 Stack Overflow Developer Survey、CodeRabbit State of AI vs Human Code Generation、Andrej Karpathy — Vibe Coding 定義