從一份沒有範本的網站規格書，
看「效率導向」與「學習導向」的兩種 AI 用法
最近，公司有位同事要整理官方網站的視覺說明書與技術規格書。
但公司沒有既有的範本或標準。
我建議他先請 AI 找架構、整理內容，讓他能先把眼前的工作完成。
如果換成是我，我也會使用 AI。
但我不會一開始就問：
請幫我產出一份網站規格書。
我會先問：
要做好這份文件，我需要懂什麼？
同樣使用 AI，目的可能完全不同
同事使用 AI，主要是為了提高效率：
遇到問題、取得答案、完成任務。
這種方式沒有錯。
工作有期限時，速度本來就很重要。
但我的出發點，會多一層「學習」。
碰到不熟悉的工作，我會先請 AI 幫我整理這個領域的知識，
找出必學內容與判斷標準。
我可能請它規劃幾堂課，
也可能請它整理知識地圖、比較案例，或用問題測試我的理解。
形式並不重要。
重要的是：
我不想讓 AI 跳過理解，而是讓它幫助我完成理解。
接著，我會先花一段時間學習，再開始實作。
實作遇到問題，就回頭補充知識、修改，再繼續往下做。
先弄懂，才知道 AI 給得對不對
以網站視覺說明書為例，我不只想知道裡面要放顏色、字體和按鈕。
我還會問：
- 這份文件是給誰看的？
- 使用者能不能理解設計的用意？
- 其他設計師與工程師能不能照著使用？
- 這套規則能不能在未來繼續延伸？
視覺說明書當然要排版好看。
畢竟顧名思義，它本身就是一份「視覺」說明書。
但好看不是唯一目的。
它真正的功能，是把設計師腦中的想法，
整理成其他人看得懂、用得上的規則。
技術規格書也是如此。
它不能只列出尺寸、格式與參數，而要先說清楚：
這項規格想解決什麼問題？
接著，才說明使用情境、限制與技術細節。
否則內容再完整，客戶還是不知道為什麼要這樣做。
同樣是網站，規格也不一樣
集團 CMS 重視的可能是：
- 多站管理
- 角色權限
- 內容審核
- 多語系
- 版本紀錄
電商網站更在意的則是：
- 商品
- 庫存
- 付款
- 訂單
- 物流
- 退款
它們都叫做網站，卻不能直接套用同一份規格書。
範本只能提供骨架。
真正決定內容的，是系統的目的、使用者與營運流程。
如果沒有先理解這些差異，我也無法判斷 AI 產出的文件是否適用。
先花兩天學習，不一定比較慢
假設一項工作原本需要七天，我寧可先花兩天理解，再用五天完成。
前兩天看起來沒有產出，卻能幫我建立判斷能力。
下次遇到不同系統時，我會知道：
- 哪些內容可以沿用？
- 哪些規格需要重做？
- 客戶可能在哪裡看不懂？
- AI 漏掉了哪些流程與例外情況？
第一次可能仍然需要七天。
下一次，也許只需要四天。
這個速度不是來自省略步驟，而是之前的學習開始累積。
研究也支持這種 AI 用法
華頓商學院副教授 Ethan Mollick 曾分享一項世界銀行實驗。
學生接受六週由 GPT-4 支援的結構化輔導後，研究估算其進展相當於一般教育環境約 1.5 至 2 年的學習成果。
但這不是讓學生自行把問題丟給 AI。
實驗中有明確的課程設計，也有教師提供引導。
這項研究證明的不是「AI 可以取代教師」，而是：
當 AI 配合明確課程、教師引導與學生主動思考時，才可能有效提升學習。
Ethan Mollick 也提醒，把 AI 當成答案助手，
可能讓人記得更少；把 AI 設定成導師，效果才會不同。
好的 AI 導師不會直接給答案，
而是透過提問、提示與回饋，引導使用者自己思考。
簡單來說：
AI 幫你完成，不一定能讓你學會；AI 引導你思考，才有機會累積能力。
這也接近 MIT 教授 Seymour Papert 提出的「建造式學習」：
人會在實際做出作品的過程中，持續理解、犯錯與修正。
AI 放大的，是速度還是能力？
我和同事都在使用 AI。
差別不在於誰比較會使用工具，而是希望透過工具得到什麼。
效率導向是：
遇到問題 → 使用 AI → 完成任務。
學習導向則是：
遇到問題 → 建立理解 → 開始實作 → 發現不足 → 補充學習 → 留下能力。
兩種方式都能完成工作。
但如果 AI 只負責處理眼前的問題，
下一次遇到不同情境時，可能仍然需要重新詢問。
如果在過程中建立了自己的判斷能力，下一次就能更快調整，
甚至建立一套讓其他人也能使用的方法。
效率解決的是這一次的問題。
學習累積的，是下一次解決問題的能力。
我希望 AI 幫我走得更快。
但我不希望它替我錯過學習。
