Codotx

用 Claude Code Skill Creator

打造技術部落格寫作 Skill

Codotx — 想點創意科技

Codotx

為什麼要做寫作 Skill?

  • 技術文章產出頻率不高,每次都要重新溝通語氣和格式
  • 希望丟素材就能產出符合公司風格的初稿
  • 統一規範:frontmatter 格式、禁用詞彙、語氣定位
想點創意科技有限公司 © 2026
Codotx

設計流程

  1. 分析現有文章風格 — 歸納共同特徵
  2. 參考 humanizer-tw — 借鑑系統化分類
  3. 撰寫第一版 Skill — 跑測試案例
  4. 迭代修正 — 解決語氣和分類問題
想點創意科技有限公司 © 2026
Codotx

第一步:分析現有文章

抓了三種類型的文章來歸納寫作模式:

類型 文章
踩坑紀錄 Cloudflare Pages 預覽環境設定
工具比較 AI 合作開發的四種方式
個人反思 多巴胺開發 Dopamine Coding
想點創意科技有限公司 © 2026
Codotx

歸納出的共同特徵

  • 開場直接交代「我們要做什麼」
  • 用「我們」或「我」當主語,不用被動語態
  • 踩坑描述帶有排查脈絡
  • 結尾用具體清單收束,沒有感性結語
  • 程式碼區塊只放讀者需要複製的部分
想點創意科技有限公司 © 2026
Codotx

第二步:參考 humanizer-tw

GitHub 上的 Skill,專門處理中文 AI 寫作的去痕跡問題

值得借鑑的設計:

  • 系統化分類 — 八大類、19 個具體問題
  • 「個性與靈魂」概念 — 光去除壞模式不夠
  • 品質評分機制 — 五個維度各 10 分

但語氣偏口語,公司技術部落格需要再正式一些

想點創意科技有限公司 © 2026
Codotx

踩坑一:語氣太像個人部落格

第一版測試結果:格式正確、沒有 AI 套話,但語氣太隨性

修正前 修正後
光看那個 crash log 真的完全猜不到原因 一開始沒有馬上聯想到是架構相容的問題
玻璃心碎了一地 這個問題困擾了我好一段時間
想點創意科技有限公司 © 2026
Codotx

解法:三欄語氣校準表

明確標出「太正式」「適當」「太隨便」的分界

太正式 適當 太隨便
經由詳細的調查分析 排查之後發現 隨便 google 一下
予以高度重視 我們很重視這個問題 超在意的

「我認為」是適當用語,不需要降到「我覺得」

想點創意科技有限公司 © 2026
Codotx

踩坑二:AI 問題沒有系統化分類

第一版只是把禁用詞混在一起,AI 容易遺漏

整理成 八大類、19 個具體問題:

  1. 開場白與連接詞(3 個)
  2. 互聯網黑話(2 個)
  3. 翻譯腔(3 個)
  4. 書面語過重(2 個)
  5. 公式化結構(2 個)
  6. 結尾套話(2 個)
  7. 語氣問題(3 個)
  8. 節奏問題(2 個)
想點創意科技有限公司 © 2026
Codotx

踩坑三:光去除 AI 味不夠

即使通過所有檢查,沒有觀點和轉折 = 還是像機器寫的

缺乏靈魂的警訊:

  • 句子長度和結構都相同
  • 只有中立描述,沒有觀點
  • 不承認不確定性或取捨
  • 讀起來像產品文件或新聞稿
想點創意科技有限公司 © 2026
Codotx

增添人味的七個技巧

  1. 交代決策脈絡
  2. 加入具體數字
  3. 寫出轉折
  4. 帶入觀點
  5. 變化節奏
  6. 承認不確定性
  7. 對感受要具體
想點創意科技有限公司 © 2026
Codotx

最終 Skill 架構(約 300 行)

模組 內容
文章格式規範 frontmatter、檔名、圖片路徑
三種結構模板 踩坑紀錄、工具比較、觀點反思
語氣定位 語氣校準表、開場結尾指引
人味注入指南 靈魂警訊 + 七個技巧
19 個 AI 問題 八大類 + 替換表
品質評分 五維度各 10 分
快速檢查清單 交付前 11 項確認
想點創意科技有限公司 © 2026
Codotx

設計 Skill 的四個心得

先分析再動手 — 讀自己的文章和別人的 Skill,第一版就有不錯的起點

測試要涵蓋不同類型 — 三種模式各跑一篇,問題很快浮現

語氣校準需要明確邊界 — 三欄對照表比抽象描述有效得多

去除 AI 味 ≠ 注入人味 — 前者刪壞的,後者加好的,兩者都做才像真人寫的

想點創意科技有限公司 © 2026
Codotx

感謝聆聽

想點創意科技 Codotx

WordPress 開發 ・ WooCommerce 電商 ・ LINE 整合 ・ AI 解決方案

掃描 QR Code 閱讀完整文章