# 結構化意圖工程命題：從提示詞工程退場到自然語言實作協議的形成 **作者：Neo.K (許筌崴)** **機構：EveMissLab (一言諾科技有限公司)** **日期：2026年7月** **版本：v0.1 公開論文初稿** **定位：可運行抽象系列／符號底空間系列／Agent 時代人機協作方法論** *** ## 摘要 本文提出「結構化意圖工程命題」：隨著 Agent、Skill、工具調用、記憶系統、上下文工程與多步驟自動化流程的成熟，傳統以單段文字技巧為核心的提示詞工程正在逐漸退居底層。提示詞不會消失，但它不再主要表現為一段一段手工撰寫的魔法咒語，而會被吸收進更大的意圖結構、任務協議、領域黑話、工具鏈上下文、驗證標準與人機迭代流程之中。 本文認為，未來真正重要的不是「會不會寫提示詞」，而是使用者、AI、Agent、Skill、工具、文件、程式碼、資料與領域知識之間，能否形成穩定的「意圖對齊結構」。在此結構中，自然語言不再只是鬆散描述，而逐漸轉化為一種帶有目標、邊界、約束、黑話、驗證、例外處理與實作路徑的結構化敘述。本文將此稱為「自然語言實作協議」。 本文進一步指出，領域黑話不是單純的排他語言，也不只是社群習慣，而是高密度的知識壓縮符號。黑話能快速建立共同底空間，提高約束空間，降低語義歧義，縮小概率生成範圍，並讓人類與 AI 更快進入同一個任務結構。但黑話也具有風險：真正理解黑話能提升對齊，錯誤使用黑話則會製造錯誤約束，使 AI 在錯誤的底空間中高效率生成錯誤結果。 本文最終主張：Agent 時代的核心能力，不是提示詞技巧，而是結構化意圖能力。使用者若無法在做中學、學中做，逐步理解自身領域、作品、工具鏈與驗證標準，即使擁有強大的 AI、Skill 與 Agent，也只能得到近似抽卡式的作品生成；而若使用者能與 AI 建立高品質意圖對齊，則自然語言將成為通往可運行抽象的高階操作界面。 *** ## 關鍵詞 結構化意圖工程、提示詞工程、Agent、Skill、自然語言實作協議、意圖對齊、領域黑話、上下文工程、Vibe Coding、人機協作、符號底空間、可運行抽象 *** # 1. 問題意識 在大型語言模型早期普及階段，「提示詞工程」曾被視為人類使用 AI 的核心能力。使用者透過特定句式、角色設定、步驟要求、格式約束、範例提示與語氣控制，引導模型產生更接近預期的答案。 這種階段可以簡化為： ```text 使用者 → 提示詞 → 模型 → 輸出 ``` 在這個模式中，提示詞看似是主要控制界面。誰更會寫提示詞，誰就能得到更好的輸出。 然而，隨著 Agent、Skill、工具調用、文件上下文、長記憶、程式執行、API 串接、多代理協作與自動化工作流開始普及，這種模式正在變化。 新的模式不再只是： ```text 寫一段提示詞 → 得到一段回答 ``` 而是逐漸變成： ```text 使用者意圖 → 結構化自然語言 → 上下文封裝 → Agent 任務拆解 → Skill / 工具 / 文件 / 程式執行 → 結果驗證 → 迭代修正 → 可運行作品或決策輸出 ``` 因此，提示詞工程並沒有消失，而是被吸收到更大的系統中。 本文的問題意識是： > **在 Agent 時代，提示詞工程究竟會退化、轉型，還是被更高階的意圖工程取代？** 本文的回答是： > **單段提示詞工程會退居底層，結構化意圖工程會成為人機協作的核心能力。** *** # 2. 從提示詞工程到結構化意圖工程 ## 2.1 傳統提示詞工程的特徵 傳統提示詞工程主要處理以下問題： ```text 如何讓模型扮演某個角色？ 如何讓模型按照某種格式輸出？ 如何讓模型分步思考？ 如何讓模型避免某些錯誤？ 如何提供範例讓模型模仿？ 如何控制語氣、長度、風格與任務方向？ ``` 這些技巧在早期非常重要，至今也仍然有價值。 但它們主要處理的是「模型輸出層」的控制，而不是完整任務系統的控制。 例如，使用者可以要求模型： ```text 請用專業語氣回答。 請一步一步分析。 請輸出 JSON。 請扮演資深工程師。 請幫我寫一個網站。 ``` 這些提示可以改善輸出，但它們仍然無法完全處理： ```text 實際檔案結構 部署環境 工具限制 API 權限 資料庫狀態 錯誤日誌 版本衝突 任務優先級 驗證標準 長期維護 跨文件一致性 ``` 當任務變成真實工程、真實作品、真實研究、真實商業流程時，單段提示詞就會顯得不足。 *** ## 2.2 Agent 時代的變化 Agent 時代的核心變化是：AI 不再只是回答，而是開始執行。 它可能會： ```text 讀取文件 搜尋資料 修改程式碼 執行測試 調用 API 建立任務清單 拆解問題 呼叫子代理 使用 Skill 維護記憶 追蹤狀態 回報進度 根據錯誤重新規劃 ``` 此時，控制 AI 的方式不再只是「一句話說得漂亮」。 真正重要的是： ```text 目標是否清楚 任務邊界是否明確 領域語彙是否正確 工具可用性是否被納入 驗證標準是否具體 錯誤處理是否可追蹤 上下文是否完整 人類是否能判斷結果好壞 ``` 也就是說，Agent 時代需要的是「意圖結構」，而不只是「提示句子」。 *** ## 2.3 結構化意圖工程的定義 本文將「結構化意圖工程」定義如下： > **結構化意圖工程，是指使用者、AI 或中介智能體，將模糊需求轉化為具備目標、邊界、領域語彙、任務層級、工具路徑、限制條件、驗證標準與迭代協議的自然語言實作結構，使 AI 系統能更穩定地理解、執行、檢查與修正任務。** 其核心不再只是： ```text 如何寫 prompt？ ``` 而是： ```text 如何讓意圖進入可執行狀態？ 如何讓 AI 知道什麼是對？ 如何讓任務被拆成可操作結構？ 如何讓領域黑話正確約束生成空間？ 如何讓人類與 AI 在同一個底空間中協作？ ``` 因此，結構化意圖工程不是提示詞工程的否定，而是提示詞工程的升級。 *** # 3. 單段提示詞工程退場命題 本文提出第一個核心命題。 ## 3.1 命題表述 > **單段提示詞工程退場命題：隨著 Agent、Skill、工具調用、多代理 handoff、記憶系統與上下文工程成熟，提示詞工程不再主要表現為一段段手工撰寫的模型指令，而會逐漸轉化為結構化意圖工程。提示詞仍然存在，但它成為任務協議、上下文設計、工具配置與驗證流程中的一個局部元件。** 早期模式： ```text Prompt as Command ``` 未來模式： ```text Prompt as Interface Fragment Intent as System Structure ``` 也就是： ```text 提示詞不再是全部控制權。 提示詞只是意圖工程中的一個界面片段。 ``` *** ## 3.2 為何提示詞工程會退場 提示詞工程退場的原因不是它失效，而是任務本身變複雜了。 當任務只是生成一段文字，提示詞足夠重要。 但當任務變成： ```text 開發網站 維護程式碼 設計資料庫 建立研究論文 整理大型知識庫 串接外部 API 部署 Cloudflare Worker 讓 Agent 執行長期任務 驗證數學推理 生成可執行工具 ``` 提示詞本身就不足了。 因為這些任務需要： ```text 長期上下文 工具使用 文件狀態 錯誤回報 版本控制 領域黑話 測試標準 結構化輸出 人類審查 多輪修正 ``` 此時，問題不再是「提示詞怎麼寫比較神」，而是「意圖如何被穩定轉譯成可執行流程」。 *** # 4. 自然語言結構化敘述 ## 4.1 自然語言不再只是描述 傳統上，自然語言容易被認為是模糊的。 但在 AI 時代，自然語言正在變成一種高階操作界面。 原因在於大型語言模型能夠理解、轉換、拆解、補全與重組自然語言中的任務結構。 然而，自然語言若過於鬆散，仍然會導致錯誤。 例如： ```text 幫我做一個網站。 幫我寫一個好看的頁面。 幫我修一下這個 bug。 幫我優化一下。 ``` 這些句子雖然能啟動 AI，但它們的約束太少。 更好的結構化自然語言會包含： ```text 我要做什麼 為誰做 目前狀態是什麼 不可以破壞什麼 使用哪些工具 成功標準是什麼 錯誤時如何回報 哪些部分由 AI 決定 哪些部分必須保留給人類確認 ``` 因此，自然語言需要從「感覺描述」升級為「結構化敘述」。 *** ## 4.2 自然語言實作協議 本文提出「自然語言實作協議」概念。 > **自然語言實作協議，是指一種以自然語言寫成，但具有可執行任務結構的敘述形式。它不等同於程式語言，卻能穩定引導 AI、Agent、工具鏈與人類共同完成實作。** 其基本組成可以是： ```text 任務目標 背景脈絡 當前狀態 限制條件 領域黑話 可用工具 不可破壞項 輸出格式 驗證方式 風險提示 迭代規則 ``` 例如，鬆散提示： ```text 幫我修 Cloudflare 的 API。 ``` 結構化敘述： ```text 目標：修復 logic.evemisslab.com 的 /api/base-space 端點，使其能回傳 JSON。 背景：目前 Cloudflare 部署成功，但 /api/base-space 回傳 404。 限制：不要破壞 /p/lm-000001/ 等靜態頁面；保留 BASE_SPACE_KV binding。 檢查方向：確認部署模型是否為 Workers Static Assets，而不是 Pages Functions。 成功標準：/api/base-space 回傳 weights/states/hits JSON；/api/log-crawler 可接收請求；legacy /papers/* 不再 404。 ``` 後者不只是更長，而是具有更高結構密度。 它能大幅降低 AI 的猜測空間。 *** # 5. 黑話作為意圖約束算子 ## 5.1 黑話的重新定義 本文將「黑話」重新定義為： > **黑話是某一領域中高密度壓縮的知識符號，它能在熟悉該領域的主體之間快速建立共同底空間，並對任務生成空間施加約束。** 黑話不是單純炫技。 黑話的作用是： ```text 快速指認問題層級 快速排除錯誤路徑 快速建立共同語境 快速壓縮複雜操作 快速降低語義歧義 ``` 例如： ```text KV binding namespace id wrangler.jsonc Pages Functions Workers Static Assets onRequest GET/POST 404 routing mismatch src/worker.js ``` 這些詞對外行來說像亂碼。 但對相關領域而言，它們會迅速定位： ```text 問題在哪一層？ 是程式邏輯問題？ 是部署模型問題？ 是路由問題？ 是 HTTP 方法問題？ 是 binding 名稱問題？ 是靜態資產與動態路由衝突？ ``` 黑話的價值在於縮小問題空間。 *** ## 5.2 黑話如何降低概率生成空間 大型語言模型在生成答案時，會根據上下文預測最可能的語言與結構。 當使用者只說： ```text 我的網站 API 壞了。 ``` AI 的可能路徑非常多。 但當使用者說： ```text Cloudflare Workers Static Assets 模型下，functions/api/base-space.js 沒有被吃到，/api/base-space 回傳 404；需要改成 src/worker.js 主入口並保留 ASSETS binding。 ``` AI 的生成空間會瞬間縮小。 因為這段話已經約束了： ```text 平台：Cloudflare 部署模型：Workers Static Assets 錯誤現象：404 錯誤原因：Pages Functions 慣例未生效 解法方向：單一 Worker 主入口 必保留資源：ASSETS binding ``` 這就是黑話的真正功能： ```text 提高約束空間 降低歧義 降低錯誤分支 縮短推理路徑 提高任務命中率 ``` 所以黑話本質上是一種「意圖約束算子」。 *** ## 5.3 黑話的風險 黑話能提高對齊，也能製造錯誤。 如果使用者真正懂黑話，黑話能快速建立共同底空間。 如果使用者不懂卻亂用黑話，AI 可能會被導向錯誤底空間。 例如： ```text 把這個 bug 用 RAG 修掉。 ``` 但實際問題可能是路由錯誤，與 RAG 完全無關。 又例如： ```text 幫我把這個網站改成 serverless。 ``` 但網站本來就已經在 serverless 環境，只是缺少 Worker 主入口。 這時黑話不是幫助，而是錯誤約束。 因此，未來的高階使用者需要學會： ```text 何時使用黑話 何時不要使用黑話 如何確認黑話是否對應正確問題層 如何讓 AI 反查黑話是否被誤用 如何在不懂時要求 AI 解碼黑話 ``` 這是結構化意圖工程的重要部分。 *** # 6. 用戶也必須被要求 AI 時代常見一種錯覺：只要模型夠強，用戶不需要懂。 這只對低階任務部分成立。 對高階任務，尤其是工程、研究、創作、策略、制度、產品與大型作品而言，用戶若完全不懂領域，就很難判斷結果好壞。 AI 可以生成內容，但用戶需要判斷： ```text 這是否符合目標？ 這是否破壞原架構？ 這是否只是表面能跑？ 這是否有長期維護問題？ 這是否符合領域慣例？ 這是否在錯誤層面解決問題？ 這是否只是模型幻覺？ ``` 因此，結構化意圖工程不只要求 AI，也要求用戶。 未來優秀的 AI 使用者不是只會命令 AI，而是會與 AI 共同建立任務底空間。 這需要使用者在做中學、學中做。 ```text 做中學：在實作過程中理解領域。 學中做：將理解立即轉化為新的實作約束。 ``` 這種循環會讓使用者逐漸從「抽卡者」變成「協作者」。 *** # 7. Vibe Coding 的上限問題 ## 7.1 Vibe Coding 的價值 Vibe Coding 代表一種新的人機創作方式：使用者透過自然語言、直覺、需求描述與即時回饋，讓 AI 快速生成程式或作品。 這種方式極大降低了實作門檻。 它使許多原本不會寫程式的人，也能開始建立網站、工具、原型、應用與自動化流程。 它的價值是真實的。 但它也有明顯上限。 *** ## 7.2 抽卡式作品生成 如果使用者只靠感覺，不理解領域，不建立驗證標準，也不逐步學習，那麼 Vibe Coding 容易變成抽卡式生成。 ```text 抽一次：AI 寫出能跑的東西。 抽二次：改一點後壞掉。 抽三次：AI 修好表面，但破壞架構。 抽四次：版本越來越亂。 抽五次：用戶不知道哪裡成功，也不知道哪裡錯。 ``` 這時作品像是被生成出來，而不是被真正掌握。 Skill、Agent、模板、框架、測試工具可以降低風險，但無法完全取代使用者的理解。 因為高品質作品需要： ```text 架構判斷 需求辨識 錯誤定位 風險意識 取捨能力 驗證能力 長期維護能力 ``` 這些能力無法只靠一句提示詞獲得。 *** ## 7.3 頂尖作品需要人機共同成熟 本文主張： > **Vibe Coding 的上限，不只取決於模型能力，也取決於用戶與 AI 的協調品質。** 使用者越懂領域，越能精準約束 AI。 AI 越理解使用者的目標與上下文，越能提供有效實作。 二者共同提高後，作品才會從抽卡生成變成穩定建構。 ```text 低階使用：用戶提出願望，AI 抽卡生成。 中階使用：用戶描述需求，AI 協助實作。 高階使用：用戶與 AI 共同建立領域底空間、任務結構與驗證協議。 ``` 這就是從 Vibe Coding 走向結構化意圖工程的過程。 *** # 8. 中介智能體與新職能的出現 未來可能出現一種新的角色。 這個角色位於： ```text 普通用戶 ↔ AI Agent / Skill / 工具鏈 / 實作層 ``` 之間。 它可能是人，也可能是 AI，也可能是一個團隊或平台。 本文暫稱其為： ```text 意圖架構師 領域轉譯師 AI 實作協調師 自然語言結構化工程師 Agent 操作設計師 人機對齊介面設計師 ``` 它的工作不是單純幫人寫提示詞，而是把模糊意圖轉換成可執行結構。 *** ## 8.1 中介角色的任務 這種中介角色需要處理： ```text 需求釐清 領域黑話轉譯 任務拆解 工具選型 上下文封裝 限制條件整理 成功標準設計 失敗模式預判 Agent 流程設計 Skill 選擇與編排 結果驗證 人類回饋轉譯 ``` 它不是傳統顧問，也不是單純工程師，也不是舊式 prompt engineer。 它更像是「意圖與實作之間的協議設計者」。 *** ## 8.2 為什麼需要中介角色 原因很簡單：大部分用戶不會自然具備結構化意圖能力。 他們通常只知道： ```text 我想要一個網站。 我想要一個工具。 我想要看起來更專業。 我想要修掉錯誤。 我想要做一個產品。 ``` 但他們不知道： ```text 應該用什麼架構？ 什麼是不該破壞的？ 錯誤在哪一層？ 成功標準是什麼？ 哪些內容需要持久化？ 哪些地方需要測試？ AI 應該自主到什麼程度？ ``` 中介智能體的任務，就是把模糊需求轉成結構化自然語言，再交給 AI 實作層。 *** # 9. 結構化意圖工程的基本框架 本文提出一個簡化框架。 任何高品質 AI 任務，都可以盡量包含以下要素。 ## 9.1 目標層 ```text 我要完成什麼？ 最終輸出是什麼？ 是文章、程式、網站、分析、策略、修復、設計，還是決策？ ``` ## 9.2 背景層 ```text 目前狀態是什麼？ 之前做過什麼？ 現有檔案、系統、理論、作品或限制是什麼？ ``` ## 9.3 領域層 ```text 這屬於哪個領域？ 需要使用哪些黑話？ 哪些黑話必須先解碼？ 哪些概念不可混用？ ``` ## 9.4 邊界層 ```text 哪些可以改？ 哪些不能改？ 哪些是假設？ 哪些必須確認？ 哪些風險不能踩？ ``` ## 9.5 工具層 ```text 可用哪些工具？ 是否需要搜尋？ 是否需要讀檔？ 是否需要執行程式？ 是否需要部署？ 是否需要產生可下載成果？ ``` ## 9.6 驗證層 ```text 怎樣算成功？ 怎樣算失敗？ 要看什麼輸出？ 要跑什麼測試？ 要用什麼觀測點確認？ ``` ## 9.7 迭代層 ```text 如果失敗，下一步如何回報？ AI 可以自行修正到什麼程度？ 何時需要人類介入？ 如何保留版本與決策紀錄？ ``` 這七層構成結構化意圖工程的基本骨架。 *** # 10. 結構化意圖與符號底空間 從符號底空間角度看，結構化意圖工程處理的是： ```text 人類模糊意圖 → 自然語言符號 → 領域黑話 → 任務結構 → AI 可操作上下文 → 工具鏈執行 → 可驗證結果 ``` 也就是說，它是人類意圖進入可運行抽象世界的轉譯過程。 如果沒有結構化，用戶的意圖停留在模糊語義雲。 如果過度形式化，用戶又難以使用。 結構化自然語言位於兩者之間： ```text 自然語言的彈性 ＋ 形式語言的約束 ＋ 領域黑話的壓縮 ＋ 工具鏈的可執行性 ``` 這使它成為 AI 時代非常重要的中介層。 *** # 11. 意圖對齊：比提示詞更核心 AI 對齊常常被理解為宏觀安全問題。 但在日常實作中，也存在一種微觀對齊： ```text AI 是否理解使用者真正要做什麼？ AI 是否知道目前任務屬於哪個層級？ AI 是否知道哪些東西不可破壞？ AI 是否知道使用者的作品風格與長期目標？ AI 是否知道何時應該問、何時應該直接做？ ``` 這就是「意圖對齊」。 提示詞只是意圖對齊的一種手段。 結構化意圖工程則試圖系統化這件事。 它讓意圖不再只是藏在一句話裡，而是被展開成可追蹤、可檢查、可執行的任務結構。 *** # 12. 反對意見與回應 ## 12.1 反對意見一：提示詞工程不會退流行 回應：本文不是說提示詞消失，而是說提示詞的中心地位下降。 提示詞仍然存在，但會被整合進 Agent instructions、Skill 描述、任務協議、上下文配置、工具調用與驗證流程中。 也就是： ```text 提示詞仍在。 但提示詞不再是全部。 ``` *** ## 12.2 反對意見二：未來 AI 會自動理解用戶，不需要結構化 回應：AI 的理解能力會提升，但高階任務仍然需要使用者提供目標、邊界與價值判斷。 尤其是創作、研究、產品、工程與策略任務，很多關鍵資訊不在模型內部，而在使用者的意圖、偏好、風險承受度與具體場景中。 AI 可以幫助結構化，但不能替使用者決定所有價值。 *** ## 12.3 反對意見三：黑話會排斥普通人 回應：黑話確實可能排斥普通人，但其本質不一定是排他，而是壓縮。 真正好的結構化意圖工程，應該包含「黑話解碼層」。 也就是： ```text 專家可以使用黑話快速對齊。 非專家可以要求 AI 解碼黑話。 中介智能體可以把黑話轉成可理解任務。 ``` 黑話不應該被神秘化，但也不應該被完全消除。 *** ## 12.4 反對意見四：這只是需求分析或產品經理工作 回應：結構化意圖工程確實與需求分析、產品設計、系統分析有重疊。 但它的不同之處在於，它直接面向 AI Agent 與可運行抽象系統。 它不是只寫給人類團隊看，而是要讓 AI 能執行、檢查、修正與延伸。 因此，它是一種新的人機混合協議設計。 *** # 13. 與第一篇論文的關係 第一篇「計算機複雜度膨脹命題」指出： ```text 計算機領域因抽象菁英密度、工程壓力、資本投入與工具鏈迭代， 形成了大量尚未被理論回收的可運行抽象與工程黑話。 ``` 本文則進一步指出： ```text 在這種高複雜度計算機場域中， 使用者若要有效驅動 AI 與 Agent， 就不能只依賴鬆散提示詞， 而必須學會結構化意圖。 ``` 因此，兩篇的關係是： ```text 第一篇：解釋為什麼計算機領域充滿高密度黑話與可運行抽象。 第二篇：解釋人類如何透過結構化自然語言，與 AI 共同操作這些可運行抽象。 ``` 第一篇處理「場域複雜度」。 第二篇處理「人機進入方式」。 *** # 14. 通往第三篇：AI 後抽象能力自動化 本文尚未完整展開 AI 對抽象能力本身的改變。 這將是第三篇的主題。 在本文中，AI 主要被視為一個需要被對齊、被引導、被協作的實作智能體。 但下一階段問題更激烈： ```text 當 AI 不只是執行人類意圖， 而開始協助生成新黑話、新工具、新框架、新協議、新抽象， 抽象能力是否開始被自動化？ ``` 換句話說，第三篇要處理的不是： ```text 人類如何更好使用 AI？ ``` 而是： ```text AI 如何讓抽象生產本身自動化、外部化、代理化與遞迴增殖？ ``` 這將使問題從「結構化意圖工程」進入「AI 後抽象能力自動化」。 *** # 15. 初步結論 本文提出「結構化意圖工程命題」，主張在 Agent、Skill、工具調用、記憶系統與上下文工程成熟後，傳統單段提示詞工程會逐漸退居底層，並轉化為更高階的自然語言實作協議。 提示詞不會消失，但它不再是核心。 核心將變成： ```text 意圖是否清楚 領域是否理解 黑話是否準確 任務是否結構化 工具是否匹配 約束是否完整 驗證是否具體 人機是否能共同迭代 ``` 因此，未來優秀的 AI 使用者不是單純會寫提示詞的人，而是能將自己的意圖、領域知識、作品標準與實作邊界結構化的人。 本文最重要的命題可以濃縮為： > **在 Agent 時代，提示詞工程不會消失，但會從句子技巧退居為系統元件；真正上升為核心的是結構化意圖工程，即人類、AI、黑話、工具鏈與驗證標準之間的對齊協議。** 如果第一代 AI 使用者學的是「如何問」，那麼下一代高階 AI 使用者需要學的是： ```text 如何知道自己在做什麼 如何知道什麼叫做對 如何讓 AI 知道什麼叫做對 如何在做中學、學中做 如何把模糊意圖變成可執行結構 ``` 這不是提示詞技巧的消失，而是提示詞技巧被吸收到更高階的意圖結構中。 *** # 16. 一句話版本 > **Agent 時代的核心不再是寫出漂亮提示詞，而是把人類意圖、領域黑話、工具路徑、限制條件與驗證標準結構化，使自然語言成為可執行、可約束、可迭代的人機實作協議。** *** # 17. 附錄 A：結構化意圖模板 以下是一個可供實際使用的簡化模板。 ```markdown ## 任務目標 我要完成什麼？ ## 背景脈絡 目前狀態是什麼？之前做過什麼？ ## 領域與黑話 這個任務屬於哪個領域？有哪些術語需要使用或解碼？ ## 可用資源 有哪些文件、程式碼、工具、API、資料、網站或限制？ ## 不可破壞項 哪些內容不能改？哪些功能必須保留？ ## 成功標準 怎樣算完成？要看到什麼結果？ ## 失敗觀測 目前錯誤是什麼？錯誤訊息、截圖、日誌或現象是什麼？ ## 執行權限 AI 可以直接做什麼？哪些地方需要先回報？ ## 輸出格式 需要論文、程式碼、檔案、清單、摘要、修復方案還是部署指令？ ## 迭代規則 如果失敗，如何回報？如何保留版本？下一步如何修正？ ``` *** # 18. 附錄 B：從鬆散提示到結構化意圖 ## 18.1 鬆散提示 ```text 幫我修網站。 ``` ## 18.2 初步結構化 ```text 我的網站部署成功，但某個 API 回傳 404。請幫我判斷原因。 ``` ## 18.3 高密度結構化 ```text 目標：修復 logic.evemisslab.com 的 /api/base-space 端點。 背景：Cloudflare 部署顯示 Success，靜態頁面 /p/lm-000001/ 正常，但 /api/base-space 回傳 404。 已知條件：wrangler.jsonc 已綁定 BASE_SPACE_KV；目前可能是 Workers Static Assets 模型，不吃 Pages functions/ 慣例。 限制：不要破壞現有靜態頁面與 legacy /papers/* redirect。 成功標準：/api/base-space 回傳 JSON，/api/log-crawler 可運作，/papers/* 不再 404。 請先判斷部署模型，再提出最小修改方案。 ``` 這三者的差別不是長短，而是意圖密度。 越高密度的結構化意圖，越能降低 AI 的錯誤概率。 *** # 19. 附錄 C：黑話解碼協議 未來使用 AI 時，可以加入以下指令： ```text 若我使用了領域黑話，請先判斷該黑話是否與目前問題層級相符。 若黑話可能被誤用，請指出可能誤用處。 若任務需要更精準術語，請提出替代術語。 若我其實不需要黑話，請用白話重新表述任務。 ``` 這可以防止「假懂黑話」造成錯誤約束。 *** # 20. 結語 提示詞工程的早期形式，像是在學會如何對 AI 說話。 但 Agent 時代要求的不只是說話，而是協作。 協作需要共同底空間。 共同底空間需要領域知識、黑話、邊界、驗證與迭代。 因此，未來真正重要的能力不是把一句話寫得像咒語，而是把一個意圖整理到足以被 AI 正確執行、被工具鏈正確承接、被人類正確驗證的程度。 這就是結構化意圖工程。 它不是提示詞工程的終結。 它是提示詞工程被吸收到更大系統後，所形成的新形態。