其實用 Web LLM 對話產出資料或文件，現在很多人應該都很熟悉了。差別已經不太在「會不會跟 AI 聊天」，而是在兩件事：你給它的條件，它是不是真的理解；它回你一大堆東西之後，你自己是不是真的理解。
就像最近一些廢片常常在演的，情侶兩個人對話，但彼此有沒有真的聽懂對方的意思？
另外，用 AI 的時候不知道大家有沒有發現，它很容易「幫你想更多」。有點像你只是請它去超市買一塊豬肉，它會順路幫你想：「既然要煮飯，那應該還需要這個、那個……」最後回來的時候，除了豬肉，還多了泡麵、水果、青菜、牛肉。
你說要做一個上架平台，它可能順手幫你加上評分、留言、通知、統計、多語系；你自己看到之後也可能越想越多，開始覺得是不是還要一個頁面看到所有工具、是不是要管理功能、是不是要分權。這些東西不一定不好，甚至有些最後真的會變成必要功能，但需求階段最重要的問題不是「AI 幫我想了多少」，而是：它規劃出來的，到底是不是我要的？
這邊大家應該都知道一個最基本的原則：你給 AI 的需求越清楚，它產出的東西通常就越接近你真正想要的東西。但「寫得很長」不等於「講得很清楚」，真正重要的是有沒有把範圍、限制、使用情境與不能做的事情說明白。
當你只丟給 AI 一句「我想做 XXXX」，跟你把完整的需求、限制與使用情境說清楚，最後會差多少？
也有人說：「AI 已經很聰明了，我開 Auto Mode，丟一句話給它，它會幫我把需求想完整、把系統做出來。」
確實可以，而且現在的模型也越來越會主動追問與補足資訊。
但這不代表它腦補幻想出來的東西，就一定跟你腦中想的是同一件事。
這就跟男女朋友對話。
你只給對方一句話，對方開始猜。
最常見的就是 A:吃甚麼? B:隨便 A:火鍋 B:不要 然後猜一個輪才猜出B真的想吃的東西。
所以來看看當你給一句話跟完整的差異在哪
先來看只簡單描述需求的結果：
但當我把需求、範圍與限制講得更完整之後，得到的內容就變成這樣：
到這裡還沒結束。就算我把同一份比較完整的需求交給不同 AI，它們理解與規劃出來的東西仍然可能不同。
有人可能看不出差異，所以我請 AI 整理成比較表
拿這張表來看應該就很明顯了
上架類型 圖一規劃的是 EXE / MSI 加 Web App，圖二沒有明確限制，圖三才把範圍限制在靜態網頁。我的需求是「靜態小工具」，但三個答案裡只有一個真的把這件事情明確限制下來。如果我沒有特別確認，第一版平台甚至可能連 EXE / MSI 都被規劃成合法的上架類型。
圖三也不是全對。「上架後管理」那一列，圖二想到持續監控，例如 CVE、到期與 Owner；圖三寫「無持續監控」。圖三比較像一個可以直接往下實作的系統，但漏掉了上線後的管理；圖二比較廣，少了一些真正實作時需要的細節。
現況來說沒有哪一個 AI 給的答案會是完整的。各自看到一部分，有的貼近原始需求，有的想到後續治理，有的把實作想得完整。
我們真正要做的事情不是挑一個「最厲害的 AI」然後全部照單全收，而是自己看懂差異，再決定哪些東西要留下、哪些要修改、哪些不需要做。
這就是為什麼需要確認 AI 給的內容。如果從開始就讓 AI 自己理解、自己規劃，接著一路做下去，可能做出一個「可以跑」的系統。
但「可以跑」跟「是我要的」，其實是兩件不同的事情
「是我要的」跟「可以放進企業正式環境」，又是完全不同的事。
**功能做得出來，不代表需求符合；需求符合，也不代表他符合企業資安規範、治理、維運 **
如果只要求「把它做出來」，最容易驗證的是能不能跑；企業要求的不只有「能跑」。
確認它是不是我真正要的、權限是不是正確、安全控制有沒有做、出了問題能不能追、版本能不能回去、最後到底誰負責。這些事情不一定會因為功能做完，就自己跟著長出來。
三個AI都問完、差異也整理完之後，接下來不是叫第四個 AI 幫我決定誰是對的，而是我自己一項一項看。
因為這才是需求要做的事：AI可以提醒「你需要這個」，但最後要不要做、做到什麼程度，是人來決定。
例如這次整理需求時，我是這樣處理的
像這次我把需求丟給 AI，在對話中幫我想了很多原本沒有寫的需求：
評分與使用人數、留言、通知服務（Mail、站內通知）、統計儀表板、多語系、公告管理、Developer Center、Admin Console、Risk Engine、Security Gate、持續監控（CVE、到期、Owner）、版本更新重審、下架與離職轉手、審核 SLA 與代理人、退回重送、上架條款、Origin 隔離、CSP、完整性校驗、SBOM 與本地化。
這些東西有些我看到會覺得：「 這我原本真的沒想到遺漏了。」
但也有些一看就知道根本不需要，不是AI列什麼就全收下來，而是一項一項看。
我考慮留下來的：版本更新重審，後來進一步變成核准版本綁定 Hash；下架與離職轉手，因為規範裡本來就需要；稽核軌跡，保留而且只增不改；Origin 隔離、CSP、完整性校驗，後來成為 Phase 7 的核心；SBOM 與外部函式庫本地化，進到 Day 18 的掃描規則；上架條款，變成首次登入時要同意的開發者條款；退回重送也留下來，因為審核不可能永遠只有通過或不通過。評分與使用人數我也留下，讓使用者至少能知道哪些工具真的有人在用。
留下來，但改做法的：例如風險分級，原本 AI 提出的做法不完全符合我要的，所以最後改成掃描結果加上申請時登記的資料一起判定，而且風險等級不能讓使用者自己修改。Risk Engine 和 Security Gate 也不是照 AI 原本規劃的方式直接搬進來，而是重新整理成前後關係：先做安全檢查，再依照結果與工具資訊判定風險。
第一版先不做的：審核 SLA 與代理人、通知服務、統計儀表板、公告管理、持續監控。不是這些功能沒有價值，而是第一版先把「申請、掃描、審核、上架、下架」這條主流程走通。流程都還沒跑起來，就先做一堆提升效率與營運管理的功能，只會讓第一版越長越胖。
我判斷的標準，其實不只是：
「這個功能少了，系統還能不能跑？」
而是再多問幾個問題：這是不是核心流程需要的？是不是安全或治理需要的？
第一版現在就需要嗎？還是只是 AI 覺得「通常這種平台應該會有」？
如果不是核心流程、安全或治理必要，而且拿掉之後完全不影響第一版的目的，那就先刪掉。
AI 很會幫你想「還可以做什麼」，但需求確認真正要做的，反而是決定「什麼不要做」。
不是 AI 列出來我就必須全部收進需求。真正的過程比較像是 AI 不斷提供候選項目，
我再根據我到底要解決什麼問題，一項一項決定「留下、改掉、刪除，還是保留在第二階段做」。
但還有一個問題：你看得懂 AI 給你的東西嗎？
一直說需求要確認，有一個更現實的問題：如果今天我對這個領域完全不了解，只知道「我想要一個什麼東西」，那 AI 回給我的內容，我真的有能力判斷它講的是對的還是錯的嗎？
這也是為什麼提到，使用 AI 並不代表原本的專業知識就不需要了。
以前是你自己要會做，現在很多事情 AI 可以幫你做；
但你要有足夠的基礎，知道它做出來的東西合不合理、是不是真的存在、是不是適合你的環境。
我就遇過廠商拿著 AI 產出的 Debug 文件叫我找問題。
但我看完整份文件之後，第一個疑問反而不是「問題在哪裡」，而是：
你們真的理解 AI 在這份文件裡說的是什麼嗎？這些設定、元件、路徑或行為，你們有沒有先確認你們質疑的設備中是真的存在？
AI寫了一份看起來非常專業的文件，而人只是因為它寫得很像真的，
就直接把它當成真的，那問題其實已經不是 Prompt 寫得好不好了。
AI 可以幫你整理答案，但判斷答案能不能相信，需要專業。
回到這個專案來說，就是持續對話整理出真正要拿來往下開發的需求文件。
有人說：「現在模型越來越聰明，以後 Prompt Engineering 不重要 反正講一句話，AI 自己就會理解。」
我覺得這句話只對了一半，現在的模型確實更能理解我們的需求，也不需要為了一個簡單問題研究 Prompt 。
但現在也越來越常談的不是單純 Prompt Engineering，而是 Context Engineering：不只是在研究「這句話怎麼寫」，而是思考模型在做決定的那一刻，到底看得到哪些需求、規則、文件、工具、歷史紀錄與環境資訊。
模型更能理解我們的需求，但不代表「把需求說清楚」變得不重要，剛好是相反。
模型可以越來越會理解人話，但它還是不知道你沒有告訴它的規定，也不會憑空知道你心裡那個「理所當然」的限制。
產出來的東西就跟資安事件一樣，都必須依照人、事、時、地、物、情境 來判斷
我現在比較在意的是：我有沒有把真正重要的 Context 給它？ 它知不知道這次只做靜態網頁？知不知道正式環境不能碰？知不知道哪些資料不能出去？知不知道誰可以審核？知不知道哪些功能這一版明確不做？
如果所謂「Prompt Engineering 不重要了」，指的是不用再鑽研那些神奇關鍵字、特殊句型或咒語，我其實滿認同的；但如果因此變成「需求不用講清楚，反正 AI 自己會想」，那我完全不認同。
未來可能越來越不需要會寫漂亮的 Prompt，但永遠需要知道自己到底要什麼，也要有能力確認 AI 理解的是不是同一件事。
不是一大串跟 AI 的聊天紀錄，也不是某一個 AI 第一次吐給我的完整規格，
而是一份已經逐項看過、刪過、改過，也知道為什麼留下這些東西的需求文件。
這份文件接下來才會交給agent，讓它繼續做後面的架構、威脅建模與 Phase 規劃。
所以我真正要確認的不是單純一句「AI 有沒有聽懂」，而是：
我能不能確認，它理解的東西就是我要的？
如果連剛開始都看不懂 AI 幫我整理出來的需求，那後面就算它寫得再快，也不知道它到底做了甚麼。
需求不是 Prompt 丟出去就結束，而是雙方對同一件事情的理解終於一致。
iThome鐵人賽
看影片追技術