第6章：用 SPEC 指揮 AI

這一章先不教技術，只想讓你看到「終點」長什麼樣子。本課後半會帶你完成一個真實上線的網站這個單元先不教技術，只想讓你看到「終點」長什麼樣子。接下來就帶你認識一個真實上線的網站：一個會自動批改規格書的工具。使用者把一份規格書檔案拖進網頁，等幾十秒，網頁就回給你一份「六個面向各打幾分 ＋ 具體改進建議」，同時把這次的原文與 AI 回饋自動存進一張 Google 試算表。整個過程，使用者只做了一個動作：拖檔案、放手。

最關鍵的一句話：這不是「手刻」出來的

很多人以為「做一個網站」等於「一行一行把程式碼敲出來」。但這個專案，作者幾乎沒有自己寫程式碼。真正做的事是：寫一份「把需求講清楚」的說明書，然後請 AI 幫忙做出來。這份說明書在這個領域有個正式名字，叫 SPEC（規格書）。

換句話說：會把需求說清楚，你就已經完成了開發的一半。 這正是這一章要教的核心能力，也是後半段所有章節的起點。換句話說：會把需求說清楚，你就已經完成了開發的一半。 這正是這個單元要教的核心能力，也是日後動手做工具的起點。

先說一個你一定有過的經驗：請別人幫忙買午餐，只說「幫我買個便當」，結果拿回來的根本不是你想要的。問題不在對方笨，而在需求講得太模糊。如果你說「幫我買巷口的雞腿便當，飯換成半份，加一份燙青菜，不要辣」，拿回來的就會很精準。跟 AI 合作，道理一模一樣。

SPEC 是「Specification」的縮寫，中文叫規格書在軟體開發裡，SPEC 是一份把「要做出什麼、有哪些規則、最後要交出什麼」寫清楚的文件。寫得好，AI 或工程師就能照著做，不會自由發揮跑掉。。用生活比喻：

一句話記住：需求講得多清楚，AI 就能做得多到位。 SPEC 寫得好，成品就八九不離十；SPEC 含糊，成品就會跑掉。下一節要拆解的，就是一份好 SPEC 該有的四個區塊。SPEC 寫得好，成品就八九不離十；SPEC 含糊，成品就會跑掉。而一份好的 SPEC，通常有四個必備區塊可以拆解。

本課專案用的那份 SPEC，其實是有結構的，分成四大塊。你可以把它當成一個萬用模板，以後請 AI 做任何事都能套。一份實戰可用的 SPEC，其實是有結構的，分成四大塊。你可以把它當成一個萬用模板，以後請 AI 做任何事都能套。每一塊都用本課既有的場景舉例（衛教、長照、研究室招生），方便你照著改。每一塊都用常見的工作場景舉例（衛教、長照、研究室招生），方便你照著改。

這不是新框架：它是第 1 章 RTCFE 的「專案放大版」

看到四個新名詞先別緊張。會寫第 1 章的 RTCFE，你就已經會寫 SPEC 的八成。 SPEC 四區塊其實就是 RTCFE 放大到「指揮 AI 蓋一整個專案」的尺度，差別只在多強化了「規則」這一塊、並寫成一份正式文件。對照如下：

本課專案還用了一個聰明的設計：把「AI 評分規格書的標準」獨立成另一份 SPEC，和「開發網站的 SPEC」分開放。「規格書自動評分網站」用了一個聰明的設計：把「AI 評分規格書的標準」獨立成另一份 SPEC，和「開發網站的 SPEC」分開放。為什麼要分開？用比喻說：「蓋房子的設計書」和「驗收房子的檢查表」是兩回事。 蓋房子的人看前者，驗收的人看後者，混在一起會亂。

分開的好處：哪天你想調整評分標準（例如加一個評分項目），只要改 SPEC B 那一份，完全不會動到網站的程式。這種「把會變動的東西獨立出來」的思維，是工程上很重要的習慣，後面講「環境變數」「金鑰保管」時你會一再看到同樣的精神。這種「把會變動的東西獨立出來」的思維，是工程上很重要的習慣，在「環境變數」「金鑰保管」等主題裡也會看到同樣的精神。

試著把下面這個模糊需求，用四區塊改寫看看。沒有標準答案，重點是「變具體」。

參考改寫方向（把需求填進四格）：

有沒有發現？光是「逼自己把需求填進這四格」，你對自己到底要什麼，就清楚了一大半。這就是 SPEC 的威力，它不是讓你變成工程師，而是逼你把腦中模糊的想法整理成 AI（或任何人）一看就懂、能照著做的說明書。

答對加 20 分，答錯倒扣 10 分。