iT邦幫忙

2026 iThome 鐵人賽

DAY 6
0
Build on Google AI

用 Google AI 簡化行政工作流程:一個學校行政人員的 30 天實作紀錄系列 第 6

Day 6:用 Gemini 草擬法規辦法(下)——修正草案對照表,與一個沒過的案子

  • 分享至 

  • xImage
  •  

會寫條文不稀奇,寫得出對照表才有用

昨天講草擬條文。今天講一件更關鍵、但外面幾乎沒人談的事:修正草案對照表。

公部門修任何規章,不是交一份「新版本」就好。你要交的是一張三欄的表:

修正條文 現行條文 說明

左邊是改完的樣子,中間是原本的樣子,右邊要說明為什麼要改。(欄位名稱各機關略有差異,我這兩份用的是「修正規定/現行規定/說明」。其中一份在條文表之前還多一層「修正名稱/現行名稱/說明」——因為那次連辦法的名字都改了,名字本身也是一列要交代的修正。)

審查的人不會逐字讀你的新版本,他們讀的是這張表——因為表上一眼就看得出動了哪裡。這份文件才是真正要送出去的東西。

所以對我來說,「Gemini 會不會寫法條」根本不是重點。重點是:它能不能產出這張表?

為什麼這張表比想像中難做

看起來只是把新舊條文並排,實際上有三個麻煩:

一、對應關係不見得是一對一。
一條可能被拆成兩條,兩條可能併成一條,也可能整條刪除、或新增一條原本沒有的。這時候「現行條文」那一欄要寫什麼?新增的條文對面是空的,刪除的條文則是右邊空著。這些都有慣例。

二、條號可能位移。
在第五條後面插一條新的,原本的第六條之後全部要往後推。而條文裡面如果寫了「依第七條規定」,那個「第七條」也要跟著改。錯了很難發現——因為每一條單獨看都沒問題。

不過這個坑我這兩案沒踩到——五份對照表從頭到尾只動第四條,沒有新增或刪除整條。它屬於我每次交件前都會查、但至今還沒查出問題的那一類。真正咬到我的是別的東西,寫在後面。

三、「說明」欄要寫得出理由。
不能寫「配合實際需要」這種廢話。要寫清楚為什麼改、依據是什麼。

實際做起來如何

我做過的兩份修法,對照表都是這樣產出來的,結論分三塊:

格式和排版:可以交出去。 三欄的結構、每一欄該放什麼、新增和刪除怎麼表示——這些有固定慣例,講清楚它就照做。

條號連動:可以交,但一定要驗。 這正好是我 Day 4 講的「要花力氣但驗得出來」那一類。方法很土但有效:把所有出現「第 X 條」的地方抓出來,一個一個對。 這種檢查很適合請它先列出來,我再逐條確認。

說明欄的理由:得自己寫。 因為理由通常不在文件裡。為什麼要納入這個項目、為什麼收費是這個級距——這些是討論出來的結果,AI 從現行條文推不出來。它能給你一句通順的話,但那句話撐不住審查時的追問。

實際上我為了寫得出那幾格,另外去蒐集了十七份其他學校的同類辦法來比對——誰有納入哪些證照、獎勵怎麼分級。這批 PDF 現在還躺在同一個資料夾裡。說明欄真正的內容是這個,不是文筆。

一個標題,就是整個政策

我另一份修的是一份學生檢定獎勵要點——學生考過某些檢定,學校發一筆獎勵金。

這次修正動到了它的名字。舊名字裡只有「程式檢定」,新名字把「人工智慧能力」擺進去了。

所以對照表的第一列不是條文,是名稱:修正名稱一欄、現行名稱一欄、說明一欄。我第一次做的時候還愣了一下——原來辦法的名字本身就是一項要單獨交代的修正。

而這一列的份量,比後面所有條文加起來都重。改名字不是文字調整,是政策範圍的擴張:原本只獎勵程式檢定,改完之後 AI 相關的專業鑑定也進到獎勵範圍裡。

我要說的是:這種等級的改動,AI 幫不上忙。

它可以幫我把決定寫成條文、排成對照表、檢查條號有沒有跑掉。但「要不要把 AI 檢定納入獎勵範圍」是政策判斷——牽涉到預算、學校的發展方向、以及對「什麼能力值得鼓勵」的看法。

AI 負責的是「決定之後的所有工作」,不是決定本身。 這句話大概是我整個系列想講的核心。

真正的坑:格式做到完美,案子還是沒過

前面講的都是「怎麼做得出來」。這一段講的是做出來之後發生什麼事。

那份獎勵要點的對照表,我自認做得不錯:三欄齊全、名稱列和條文列分開、說明欄每一格都寫得出依據。交出去之後——案子沒過。 會議決議「緩議」,要業務單位重新盤點哪些檢定適合納入、獎勵項目和金額再檢討過,之後重提。

我回頭去看那份草案檔案,最上面那幾行生效日期,到今天還是這樣:

115 年 X 月 X 日 第 1 次 XX 委員會議修正通過
115 年 X 月 X 日 114 學年度第 X 次行政會議修正通過

X 還是 X。 那份文件所有的格式都完成了,只有最關鍵的那幾個字填不上去,因為那要等決議。

這件事後來變成我對 AI 協作的一個提醒:它讓「做完」這件事提前到來,但「做完」不等於「成立」。 一份格式完整、依據齊全、排版正確的文件擺在眼前,很容易讓人產生一種事情已經推進的錯覺。實際上它只是待審而已,而審查會不會過,跟文件做得多漂亮沒有太大關係。

所以我現在寫工作成果的時候,這一案是列在「檢討與精進」,不是列在「已完成」。這個分界要自己守住——AI 不會提醒你,它交出東西的那一刻,語氣永遠是完成式。

給同樣要修規章的人

四個實際的建議:

一、給它現行全文,不要只給要改的那幾條。 少了上下文,它會產出格式正確但接不起來的東西。

二、條號自己對過一遍。 錯起來最難發現,但也最容易查,別省這五分鐘。

三、說明欄自己寫。 那是唯一要為結果負責的欄位。

四、文件做完不要當成案子做完。 這兩件事在 AI 協作之後,中間的距離變得比以前大很多。

明天

Day 7:換一種工作。四百多門課,怎麼篩出「跟 AI 相關」的那些——這件事真正難的地方,不在數量。


上一篇
Day 5:用 Gemini 草擬法規辦法(上)——第一份草稿是怎麼來的
下一篇
Day 7:四百多門課,篩出 11 門還是 30 門?
系列文
用 Google AI 簡化行政工作流程:一個學校行政人員的 30 天實作紀錄7
圖片
  熱門推薦
圖片
{{ item.channelVendor }} | {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言