從一位資安治理實習生的真實工作場景出發,記錄如何用 Prompt Engineering 打造一份可重複使用的報告範本——從心態建立、CO-STAR 框架,到資料前處理、防呆機制、版本控制,最終串接自動化,把重複性的日報週報工作,變成一條穩定運作的 AI 產線。
【Day 1】開賽宣言:為什麼我們需要把「寫報告」變成「寫程式」? 前言 如果你也在公司負責日報、週報這類例行性報告,一定有過這種經驗:資料東拼西湊、格式每次都...
前言 昨天我們建立了一個核心心態:AI 不是聊天對象,是需要規格書的產線員工。今天要往下追問一個更根本的問題:這門叫做 Prompt Engineering 的...
前言 前兩天我們談了心態(把 AI 當產線員工)和目標(追求穩定性與可重複性)。今天要開始動手拆解一個實際的問題:一份能重複使用的範本,內部到底該怎麼切分結構?...
前言 Day 3 我們把範本切成了 System Prompt(骨架)和 User Prompt(血肉)。今天要更進一步:就算在血肉、甚至骨架內部,其實也還藏著...
前言 前四天,我們一直在談範本的「結構」——骨架、血肉、變動頻率。但有一件事,我們一直刻意留到今天才談:你到底怎麼定義「這是一份好報告」? 這個問題聽起來有點蠢...
前言 第一階段的五天,我們建立了心態、目標、結構拆解能力,也做出了一份品質檢查清單。現在進入第二階段:怎麼系統化地把這些素材,組織成一份真正能用的 prompt...
前言 昨天我們用 CO-STAR 框架把一份 prompt 該考慮的六個面向做了完整掃描。今天要放大鏡對準其中最關鍵、卻也最常被寫得太隨便的兩項:Context...
前言 前兩天我們把 Context 與 Role 這兩塊地基打穩了。今天要處理的是 CO-STAR 裡最直接影響「格式穩不穩定」的一項——Response(回應...
前言 昨天我們把格式這種「硬」規則搞定了——輸出的骨架該長什麼樣子,已經很明確。但即使格式完全正確,你可能還是會遇到一個常見的抱怨:「格式是對的,可是讀起來就是...
前言 昨天結尾我們用了一個小技巧:與其抽象描述「不要有 AI 味」,不如直接給一個「反例 vs 正確寫法」的對照。今天要把這個技巧正式擴展成一套完整方法論——F...