[IND] 11 分鐘閱讀OraCore 編輯部

用教會框架寫 AI 簡報

我把 AP 的梵蒂岡 AI 報導拆成可直接套用的寫作 brief,幫你用「人類尊嚴」而不是產品話術來寫 AI。

分享 LinkedIn
用教會框架寫 AI 簡報

我把 AP 的梵蒂岡 AI 報導拆成可直接套用的寫作 brief,幫你用「人類尊嚴」而不是產品話術來寫 AI。

我最近看 AI 報導看得有點煩,因為太多文章都在寫同一種東西:新模型、快多少、準多少、又接了什麼工具。看久了真的會麻木。直到我看到 AP 這篇 〈Pope Leo XIV to unveil AI-focused encyclical with Anthropic co-founder〉,我才覺得這題終於不是在講 demo,而是在講一個更難也更實際的東西:當 AI 進到制度裡,誰還算人,誰還有決定權。

這篇讓我停下來的原因很簡單。它把教宗 Leo XIV 和 Anthropic 的 Dario Amodei 放在同一個畫面裡,卻沒有把故事寫成科技展或宗教奇觀。它在講的是:教會要用最正式的文件形式,去談 AI 時代的人類尊嚴。這種寫法很值得偷,因為我們自己在寫 AI 簡報、產品文案、內部政策時,常常只會講功能,不會講立場。結果就是,字很多,態度很空。

Source anchor:我這篇拆解主要靠 AP News 這篇報導,原文在這裡。AP 有提到 encyclical 將在 5 月 25 日推出,主軸是 AI 時代的人類尊嚴;來源沒有提供瀏覽數或書籤數,所以我不亂掰。

教宗不是在「宣布 AI」,他是在選框架

訂閱 AI 趨勢週報

每週精選模型發布、工具應用與深度分析,直送信箱。不定期,不騷擾。

不會寄垃圾信,隨時可取消。

“Pope Leo XIV and the co-founder of artificial intelligence company Anthropic will launch the pontiff’s first encyclical on May 25, a document on the care of human dignity in the era of AI.”

翻譯一下就是:梵蒂岡不是把 AI 當成一個新玩具在介紹,而是把它當成一個會碰到尊嚴、勞動、權力分配的社會問題。這個差很多。因為一旦你用「尊嚴」當框架,討論就不會停在模型準不準、回應快不快,而是會往下追:哪些工作被替代、哪些決策被自動化、哪些人被迫接受系統判定。

用教會框架寫 AI 簡報

我自己寫 AI 內容最常踩的坑,就是團隊口口聲聲說要做 responsible AI,結果文件只剩下 latency、filter、fallback。那不是 responsible,那只是風險管理包裝成道德語言。AP 這篇有意思的地方就在這裡:它提醒我,真正有力的 AI 敘事,不是先講技術,而是先講人會失去什麼。

實操寫法很簡單。你在寫任何 AI 內容前,先補一句「這東西改變了人的什麼」。不是「提升效率」這種空話,而是「改變了誰能決定、誰能被信任、誰能保留判斷」。如果你一句都寫不出來,那你的內容大概還停在產品規格表。

  • 先寫人類後果,再寫技術特性
  • 少用「智能化」「高效化」這類空詞
  • 每篇 AI 文案至少放一個明確的價值判斷

Anthropic 不是來湊熱鬧,是來當翻譯機

AP 點名 Dario Amodei,這不是裝飾。Anthropic 一直在講 safety、alignment、harm reduction,這些詞你可以嫌它們有點公關腔,但它們確實是 AI 業界少數還願意碰風險和責任的語言。梵蒂岡要談 AI,找一個只會講算力和產品迭代的公司沒用,因為那只會把談話拉回技術自嗨。

我看這段時第一個反應是:對,這就是需要一個真正的 counterparty。不是找一個來站台的人,而是找一個能把倫理問題翻成技術問題、再把技術問題翻回倫理問題的人。這種人很少,但在公共溝通裡超重要。因為沒有翻譯機,雙方只會各講各的,最後大家都覺得自己很深刻,其實完全沒對話。

我以前也做過類似的爛事。團隊想對外講 AI,我們找了工程師上台,結果他把所有問題都講成架構圖。聽眾不是聽不懂,是根本不知道那跟自己有什麼關係。這就是失敗的溝通:技術有了,脈絡沒了。AP 這篇提醒我,好的 AI 敘事一定要有人能把風險講成人話。

實操上,你可以這樣做:每次做 AI 簡報,固定安排一個「技術翻譯位」。這個人不一定最會寫 code,但要能回答三件事:這系統優化了什麼、犧牲了什麼、出錯誰負責。答不出來,就不要急著發表。

  • 找一個能講 tradeoff 的人,不是只會講功能的人
  • 每次簡報都留一頁給 failure mode
  • 不要讓「複雜」變成逃避回答的藉口

encyclical 這種老格式,反而最有用

教會明明可以發聲明、發新聞稿、發社群貼文,卻選了 encyclical。這不是復古情懷,這是策略。encyclical 是正式教導文件,意思是這件事不是臨時反應,而是制度層級的立場。它的好處很殘酷:你不能像發推文一樣今天講、明天刪、後天重寫。

用教會框架寫 AI 簡報

也就是說,這種格式逼你留下可被引用、可被反駁、也可被追問的文字。這點我超有感,因為我看過太多公司寫 AI principles,首頁很漂亮,點進去全是「我們重視負責任、透明、以人為本」這類誰都能簽名的句子。真正有用的文件不是會讓人點頭的文件,而是會讓人拿來對照行為的文件。

我之前幫團隊整理 AI 政策時最痛苦的地方,不是寫不出來,是大家都想寫得溫和,結果寫到最後沒一條能執行。梵蒂岡的做法反而比較狠:它選一個足夠正式的格式,逼自己把話說死一點。對開發者來說,這很值得學。你不需要寫神學,但你需要寫能活過產品週期的文件。

實操寫法:把你的 AI 立場文件寫成「一年後還能被引用」的版本。定義名詞、寫清楚不做什麼、列出人類覆核點。不要只寫願景,還要寫邊界。你如果連邊界都不敢寫,那這份文件只是裝飾。

梵蒂岡官方內容通常會回到 Vatican 官方網站,這種正式文件的原始脈絡可以從那裡追。

這篇真正談的是尊嚴,不是監管

AP 的摘要很準,說這份 encyclical 是在談「the care of human dignity in the era of AI」。這句話比「AI safety」難處理多了,因為尊嚴不是一個好量化的欄位。它會碰到工作、身份、代理權、信任、以及人是不是被當成可替換零件。

我自己最怕的 AI 文章,就是只處理得了可測量的風險。偏見分數可以修,延遲可以調,錯誤率可以降。但尊嚴不是這樣運作。很多人對 AI 的反感,不是因為它偶爾答錯,而是因為它讓人感覺自己在系統裡不再重要。這件事很難寫,但不能不寫。

我以前在產品團隊就遇過這種狀況。大家一直說某個 AI 功能只是 assistive,結果使用者根本不在意你叫它什麼,他們在意的是:最後誰說了算、誰能改、誰會被相信。那就是尊嚴層。你如果只寫效率,不寫尊嚴,最後做出來的東西通常都很順,但也很冷。

實操上,我建議你每次寫 AI 內容都加一個「尊嚴檢查」。問自己:這個系統會不會改變某個人的地位、選擇權、或被對待的方式?如果會,就直接講,不要假裝只是流程優化。這句話很土,但很好用。

AP 的寫法比一般 AI 新聞高明,因為它不把 AI 當主角

很多 AI 報導都犯同一個毛病:只要有 AI,就把 AI 寫成宇宙中心。結果一篇新聞看完,讀者只記得模型名字,忘了這東西到底跟誰有關、跟什麼制度有關。AP 這篇比較聰明,它把重心放在教會怎麼回應 AI,而不是 AI 本身有多炫。

這種寫法很值得抄。因為當你在寫內部 brief、對外稿件、甚至產品說明時,最容易犯的錯就是把技術放太前面。技術不是不能講,但它應該服務於問題,不該自己變成問題。這篇報導讓我重新確認一件事:好的 AI 敘事不是「我們做了什麼」,而是「我們為什麼要這樣做,以及這樣做會害誰不舒服」。

我也很喜歡它的節制。它沒有假裝這是一場科技界的盛大事件,也沒有把宗教寫成落後背景板。它只是老實地說,現在連教會都在用最正式的語言處理 AI。這對開發者其實是警訊:如果連最慢的制度都開始逼問尊嚴,你還在只寫 benchmark,就真的有點落伍了。

實操寫法很直接:寫 AI 內容時,先決定主角是「人」還是「模型」。如果主角是模型,文章通常會空;如果主角是人,文章才會有衝突、有代價、有立場。你可以把這當成編輯 checklist。

  • 先寫問題,再寫工具
  • 先寫制度,再寫模型
  • 先寫人怎麼受影響,再寫技術怎麼運作

開發者最該偷走的,是這種「先立場、後技術」順序

我不會叫你在 sprint doc 裡塞神學,但我真的建議你學這個順序:先定義立場,再定義技術。梵蒂岡不是先講模型架構,而是先講尊嚴;先講人,再講系統。這順序看起來老派,實際上非常實用,因為它會逼你承認一件事:AI 不是純工具,它會重排權力。

這也是為什麼很多 AI 專案最後會爛掉。不是技術不夠,而是前面沒把「我們到底在替誰做事」講清楚。當這句話沒講清楚,後面的規格、提示詞、guardrail 都只是補洞。AP 這篇給我的最大啟發,就是一個正式文件可以很硬,但它硬的不是語氣,是框架。

如果你要把這套東西帶回工作裡,我會建議你先做一頁紙的 AI position note。不要長篇大論,先把四件事寫明白:這功能幫誰、改變什麼、不能做什麼、出事誰負責。這四件事比一百句「我們重視責任」有用多了。

可抄的模板

# AI position note for a product team

## What we are building
We are building [feature name], an AI-assisted system for [user group] to [task].

## Why this exists
This feature exists to reduce [pain point] while preserving human judgment in [critical decision area].

## What it changes for people
- It changes how users [act / decide / review].
- It may affect [work / access / trust / status].
- It must not remove human review from [specific step].

## What we will not do
- We will not use this system to make final decisions about [employment / housing / health / finance / discipline / access].
- We will not hide AI involvement from users.
- We will not ship if we cannot explain the failure mode in plain language.

## Human dignity check
Before launch, answer these in writing:
1. Who gains control?
2. Who loses control?
3. What happens when the model is wrong?
4. What is the user allowed to override?
5. What part of the experience must stay human?

## Review gate
This feature cannot ship until:
- Product signs off on user impact
- Engineering documents failure modes
- Legal reviews disclosure and retention
- A named owner approves the rollback plan

## Public-facing summary
We use AI to assist with [task], but a human remains responsible for [decision / approval].

## One-sentence policy
If the system changes someone’s agency, status, or access, we write that down before we ship.

這段模板不是照抄 AP,也不是照抄梵蒂岡;它是我把這篇報導的核心框架拆出來,改寫成產品團隊可以直接用的版本。你可以把它丟進 Notion、Confluence、README,甚至直接貼進 launch checklist。

原始報導請看 AP News:AP 原文 URL。上面對「尊嚴優先、技術次之」的整理是我的衍生解讀,不是逐字翻譯。