Post by @yangyi on X (Clay 內部 AI 寫作原則)

原始來源與檔名：2026-08-14T094448+0800-Post by @yangyi on X.md

SOURCE | 資訊源評估

• 準確性: 高 - 作者引述了矽谷當紅公司 Clay 內部的實際工作規範，內容極具現實指導意義，直擊當前企業大量使用 AI 所導致的「溝通通膨」痛點。
• 易理解性: 高 - 四條原則簡單明瞭，將抽象的寫作哲學轉化為具體的行動準則與自我檢核表。
• 閱讀策略建議: 建議直接將這四條原則與文末的自我檢核表複製並貼在團隊的協作規範（如 Notion 或 Slack）中，作為跨部門溝通的底線要求。

NAPKIN | 餐巾紙

餐巾紙公式

AI 生成的冗長文件 = 作者偷懶省下的時間 × (讀者群浪費的時間 × N)

寫作是將自己的思考進行降維與壓縮的過程，如果交給 AI 擴寫，就是在增加組織內的認知負載與通訊雜訊。

一句話

寫作即思考的證明（Proof of Thought）。把寫作外包給 AI，等於偽造了你思考過的證明，最終受害的是基於這些「假思考」做決策的團隊。

餐巾紙草圖

┌──────────────────────────
│   ❌ 糟糕的工作流 (AI 擴寫)
│   [短 Prompt] ──▶ [AI 生成冗長報告] ──▶ [N 個讀者被迫看廢話] (乘法成本)
│
│   ✅ 正確的工作流 (人類壓縮)
│   [AI 協助發想] ──▶ [人類收斂思考] ──▶ [極簡精確的文件] ──▶ [N 個讀者快速吸收]
└──────────────────────────

ROUND 1: SKELETON | 骨架掃描

“這本書在說什麼”

• 核心問題: 團隊成員過度依賴 AI 生成長篇大論的報告，導致溝通效率低下且內容空洞，該如何規範？
• 核心答案: Clay 提出了四條核心 AI 寫作原則：為每一句話背書、寫作即思考、寫的時間必須大於讀的時間、簡潔勝於冗長。
• 論證結構: 條列與演繹型。列出四條規範，並解釋背後的機會成本（如乘法成本）與語義學上的物理限制（無損轉換不存在）。

章節骨架

1. 原則一：你必須為每一句話背書。不允許推卸責任給 AI。
2. 原則二：寫作即思考 (Proof of Thought)。生成文件不是目的，想清楚才是。
3. 原則三：寫的時間 > 讀的時間。短提示生成長文是不尊重讀者時間（乘法成本）。
4. 原則四：長不等於好。簡潔是高成本的選項，因為需要人類親自刪減。
5. 根本問題：自然語言沒有「無損轉換」，改寫必定損失資訊。

ROUND 2: DISSECTION | 血肉解剖

“憑什麼這麼說”

論證鏈

┌──────────────────────────
│ 自然語言的語義傳達不存在「無損轉換」，換個說法一定會改變微小含義
│   │
│   ▼
│ AI 的擴寫必然摻雜了作者原本沒有想表達的「雜訊」與「幻覺」
│   │
│   ▼
│ 若作者不為每一句話背書，團隊將基於這些 AI 產生的「雜訊」做出錯誤決策
│   │
│   ▼
│ 結論：作者必須承擔「刪減」與「把關」的成本，確保文件是「思考的證明」
└──────────────────────────

關鍵證據

1. 未被識破的嚴重性: 如果你用 AI 寫的報告沒被識破，團隊會「基於你沒想過的觀點做決策」，這比被識破（只是尷尬）的後果嚴重百倍。
2. 乘法成本 (Multiplier Cost): 作者偷懶少花 5 分鐘，若報告發給 10 個人看，團隊總共損失的是 50 分鐘的閱讀與理解成本。
3. AI 的表達限制: AI 只能基於你給的 Prompt (Token) 進行推演。你給的表徵越粗糙，AI 在擴寫時丟失的核心思想就越多。

隱形假設與邊界

• 隱形假設:
  • 假設該文件的目的是用來「驅動決策」或「同步核心狀態」，而非單純的格式化報告（如機器生成的例行系統日誌）。
  • 假設讀者的時間價值高於作者在寫作上投入的時間價值。
• 邊界條件:
  • 如果任務是「SEO 文章生成」、「發想 100 個行銷標語」這類需要發散思維與數量的場景，擴寫與長篇大論反而是合理的工作流。此規範適用於團隊內部的高效能協作與決策溝通。

ROUND 3: SOUL | 靈魂提取

“還能怎麼用”

• 作者盲點: 原文未具體說明如何「稽核」員工是否有遵守這些規範，除了員工自律，或許還需要配套的 Review 文化。
• 知識連接:
  • 這與亞馬遜 (Amazon) 著名的「六頁備忘錄 (6-page narrative)」文化如出一轍，強調寫作者必須深度思考。
  • 「Proof of Thought」借用了區塊鏈「Proof of Work (工作量證明)」的概念，寫作就是人類在組織中展現工作量的密碼學證明。
• 行動觸發: 在下次發送團隊週報或提案前，做一次自我檢核：「有沒有哪句話刪掉不損失資訊？」有的話就刪掉；「我是不是可以直接發 Prompt 給他們？」如果是，那就直接發。

留白提問 (Guided Reflection)

• 提問：在你的團隊中，是否有過「大家開會討論一份長篇文件，最後發現沒人（包括作者）真正同意文件裡某個觀點」的經驗？
  • 架構師視角 (引導思路)：這就是典型的「被 AI 劫持的決策」。解決方案不是禁用 AI，而是改變 PR (Pull Request) 或提案的審查機制——要求作者在文件中標註哪些段落是 AI 輔助發想，並在會議中要求作者「用自己的話」重新闡述該段落的邏輯。
• 提問：「簡潔是成本更高的選項」，作為工程師，這句話讓你聯想到程式碼重構的什麼原則？
  • 架構師視角 (引導思路)：就如同 Blaise Pascal 名言：「我寫這封信這麼長，是因為我沒有時間把它寫短。」程式碼也是一樣，複製貼上寫出 500 行的義大利麵條程式碼很快，但要抽象出 50 行的高內聚核心函數，需要極深的領域認知與思考。寫作與寫程式，本質上都是在做「資訊壓縮」。

跨域映射

• 在 區塊鏈，這叫 Proof of Work (工作量證明)
• 在 團隊協作，這叫 Proof of Thought (思考證明)
• 在 軟體工程，這叫 DRY 原則 (Don’t Repeat Yourself) 與高內聚

DEEP READ | 精讀指引 (Must-Read Segments)

[!IMPORTANT] 學習的本質需要「認知阻力」。請親自回到原文閱讀以下核心段落，感受原始論述的阻力，不要只依賴 AI 的總結。

1. 原則一 · 你必須為每一句話背書
   • 「後果分兩級：被人類識破 = 尷尬；沒被識破 = 團隊基於你沒想過的觀點做決策（更嚴重）。」
   • 推薦理由: 深刻點出了 AI 濫用的最大隱患。多數人只怕被發現用 AI 會尷尬，卻忽略了如果沒被發現，錯誤的決策將像毒藥一樣滲透進專案中。
2. 原則二 · 寫作即思考
   • 「spec / 狀態更新 / 複盤是 “proof of thought”——生成文件並不是目的，目的是把問題想清楚。外包給 AI 等於偽造了一份我思考過的證明。」
   • 推薦理由: 重新定義了文件的價值。文件不只是文字載體，更是作者大腦已經完成收斂與架構化的證明。

Post by @yangyi on X (Architectural Deep Dive)

前言/背景

隨著 AI 工具的普及，企業內部溝通出現了一種危險的趨勢：員工用簡短的提示詞 (Prompt) 讓 AI 生成長篇大論的報告，導致文件充斥廢話與雜訊。矽谷新創公司 Clay 的聯合創辦人針對此現象，提出了內部 AI 寫作的四條核心原則。本文的核心精神在於，將「寫作」視為「思考的證明 (Proof of Thought)」，嚴格限制 AI 在決策型文件中的越俎代庖。

章節詳細總結

原則一：作者必須為每一句話背書 (Accountability)

在文件中，絕對不允許出現「那句話是 AI 寫的，忽略吧」這種卸責的說法。

• 架構決策與風險評估：如果一篇由 AI 大量注水的文章沒有被同事識破，其後果比被識破更加嚴重。因為團隊會根據文件中「作者根本沒認真想過、由 AI 幻覺隨機拼湊出的觀點」進行架構決策或資源分配。這是典型的 Garbage In, Garbage Out 系統災難。

原則二：寫作即思考的證明 (Proof of Thought)

文件的產出本身不是目的，「決定強調什麼、如何組織邏輯」的這個過程，才是讓作者真正搞懂問題的關鍵。

• 深度洞察：撰寫 Spec、系統狀態更新或 Post-mortem（事後複盤）時，這份文件是作者「思考過 (Proof of thought)」的密碼學證明。如果把撰寫過程完全外包給 AI，就等於在系統中偽造了這份證明，破壞了團隊的信任基礎。

原則三與四：乘法成本與極限壓縮 (Multiplier Cost & Compression)

• 乘法成本：如果作者用短 Prompt 讓 AI 生成長文，省下了自己的時間，但這份長文卻要發給 $N$ 個讀者看。這是一種「不尊重對方時間」的行為，將作者的一次性偷懶，轉化為組織的乘法成本 ($N \times \text{閱讀時間}$)。
• 簡潔是高成本選項：這與軟體工程中的重構同理。AI 的冗詞贅句會製造雜訊 (Noise)，稀釋真正的內容 (Signal)。與其讓 AI 把短 Prompt 擴寫成長文，不如直接把原始的短 Prompt 發給團隊。人類的價值在於花時間去「刪除」與「壓縮」資訊，而非生成廢話。

語義傳達的物理限制：無損轉換不存在

Clay 提出這些原則的底層邏輯在於一個語言學現實：對於自然語言的語義傳達，並不存在「無損轉換 (Lossless Conversion)」。

• 這意味著「換個說法但意思一樣」在嚴格意義上是不成立的。每一次 AI 的改寫，都在微妙地改變原始意圖。
• AI 擁有的上下文 (Context) 只有你給予它的 Token。作者大腦中的表徵如果沒有精確轉化為文字，AI 的改寫就會造成嚴重的資訊遺失或扭曲。

總結與結論

• 文件的本質是共識，而非字數：在工程與產品團隊中，規格書 (Spec) 的價值在於收斂分歧，而不是比拼字數。AI 擴寫只會增加分歧的表面積。
• 建立團隊的自我檢核機制：導入文章提供的 Checklist（例如：有沒有哪句話刪掉不損失資訊？）。這可以作為 Pull Request 或 RFC (Request for Comments) 提交前的標準流程。
• 防範組織內的「認知通膨」：當生成文字的成本趨近於零時，閱讀與過濾資訊的注意力成本將急遽上升。優秀的架構師與管理者必須扮演「雜訊過濾器」，強制要求文件維持高密度的訊號雜訊比 (Signal-to-Noise Ratio)。