iT邦幫忙

鐵人檔案

2026 iThome 鐵人賽
回列表
AI 自動化

《從聊天到規格書:我如何把 AI 訓練成報告產線員工》 系列

從一位資安治理實習生的真實工作場景出發,記錄如何用 Prompt Engineering 打造一份可重複使用的報告範本——從心態建立、CO-STAR 框架,到資料前處理、防呆機制、版本控制,最終串接自動化,把重複性的日報週報工作,變成一條穩定運作的 AI 產線。

參賽天數 27 天 | 共 27 篇文章 | 0 人訂閱 訂閱系列文 RSS系列文
DAY 1

Day 1|開賽宣言:為什麼我們需要把「寫報告」變成「寫程式」?

【Day 1】開賽宣言:為什麼我們需要把「寫報告」變成「寫程式」? 前言 如果你也在公司負責日報、週報這類例行性報告,一定有過這種經驗:資料東拼西湊、格式每次都...

2026-08-28 ‧ 由 cyj666 分享
DAY 2

Day 2|心法篇:Prompt Engineering 在解決什麼問題?(穩定性與可重複性)

前言 昨天我們建立了一個核心心態:AI 不是聊天對象,是需要規格書的產線員工。今天要往下追問一個更根本的問題:這門叫做 Prompt Engineering 的...

2026-08-29 ‧ 由 cyj666 分享
DAY 3

【Day 3】System Prompt vs User Prompt:解構範本的「骨架」與「血肉」

前言 前兩天我們談了心態(把 AI 當產線員工)和目標(追求穩定性與可重複性)。今天要開始動手拆解一個實際的問題:一份能重複使用的範本,內部到底該怎麼切分結構?...

2026-08-30 ‧ 由 cyj666 分享
DAY 4

【Day 4】變數化思維:如何找出工作流程中「固定不變」與「每次變動」的元素?

前言 Day 3 我們把範本切成了 System Prompt(骨架)和 User Prompt(血肉)。今天要更進一步:就算在血肉、甚至骨架內部,其實也還藏著...

2026-08-31 ‧ 由 cyj666 分享
DAY 5

【Day 5】定義你的輸出規格:什麼是好報告?先有人類標準,才有 AI 產出

前言 前四天,我們一直在談範本的「結構」——骨架、血肉、變動頻率。但有一件事,我們一直刻意留到今天才談:你到底怎麼定義「這是一份好報告」? 這個問題聽起來有點蠢...

2026-09-01 ‧ 由 cyj666 分享
DAY 6

【Day 6】系統化撰寫框架 (上):CO-STAR 框架解析與應用

前言 第一階段的五天,我們建立了心態、目標、結構拆解能力,也做出了一份品質檢查清單。現在進入第二階段:怎麼系統化地把這些素材,組織成一份真正能用的 prompt...

2026-09-02 ‧ 由 cyj666 分享
DAY 7

【Day 7】系統化撰寫框架 (下):如何設定完美的 Context (背景) 與 Role (角色)?

前言 昨天我們用 CO-STAR 框架把一份 prompt 該考慮的六個面向做了完整掃描。今天要放大鏡對準其中最關鍵、卻也最常被寫得太隨便的兩項:Context...

2026-09-03 ‧ 由 cyj666 分享
DAY 8

【Day 8】結構化輸出 (Structured Output):用 Markdown 與 JSON 控制產出格式

前言 前兩天我們把 Context 與 Role 這兩塊地基打穩了。今天要處理的是 CO-STAR 裡最直接影響「格式穩不穩定」的一項——Response(回應...

2026-09-04 ‧ 由 cyj666 分享
DAY 9

【Day 9】Tone & Style 控制:讓 AI 寫出來的報告不再有濃濃的「AI 味」

前言 昨天我們把格式這種「硬」規則搞定了——輸出的骨架該長什麼樣子,已經很明確。但即使格式完全正確,你可能還是會遇到一個常見的抱怨:「格式是對的,可是讀起來就是...

2026-09-05 ‧ 由 cyj666 分享
DAY 10

【Day 10】Few-shot Prompting 實戰:給範例比說破嘴更有效

前言 昨天結尾我們用了一個小技巧:與其抽象描述「不要有 AI 味」,不如直接給一個「反例 vs 正確寫法」的對照。今天要把這個技巧正式擴展成一套完整方法論——F...

2026-09-06 ‧ 由 cyj666 分享