社群貢獻挑戰

如何提交你自己之 AI 安全挑戰至社群，含審查過程、品質標準與貢獻指引。

社群貢獻挑戰

最佳挑戰來自社群。若你已設計有趣之 AI 安全練習、謎題或情境，你可提交其以納入社群挑戰庫。貢獻挑戰被審查、測試並為整個社群發布以享受。

為何貢獻

貢獻挑戰對你與社群有益：

• 教學深化理解。 設計挑戰需足夠理解技術以圍繞其建立受控情境。此較僅執行技術為較高標準。
• 社群認可。 你之姓名（或代號）附於你建立之每挑戰。品質挑戰於社群內獲得聲譽與認可。
• 改善此領域。 每新挑戰為下一代 AI 安全從業者之訓練機會。你之貢獻具乘數效應。
• 對你想法之回饋。 審查過程與社群對你挑戰之回應對你之思考提供有價值回饋。

提交過程

步驟 1：提案

於建立完整挑戰前，提交描述以下之提案：

# Challenge Proposal: [Title]
 
## Concept
[2-3 paragraphs describing what the challenge tests and why it is interesting]
 
## Learning Objectives
[What skills or knowledge does this challenge develop?]
 
## Difficulty Level
[Beginner / Intermediate / Advanced / Expert]
 
## Estimated Time
[How long should a participant at the target difficulty level expect to spend?]
 
## Technical Requirements
[What infrastructure does the challenge need? A model API, a web server,
a database, custom tools?]
 
## Novelty
[How does this differ from existing challenges? What makes it unique?]

經社群平台提交提案。審查者將於 7 天內以以下之一回應：

• 接受 —— 繼續進行建立完整挑戰
• 請求修訂 —— 概念有趣但需精煉（提供特定回饋）
• 拒絕 —— 概念與現有挑戰重疊過多或未符合品質標準（提供理由）

步驟 2：挑戰開發

一旦你之提案被接受，建立完整挑戰。完整挑戰提交含：

挑戰規格：

# [Challenge Title]
 
## Overview
[Detailed description of the scenario and objectives]
 
## Setup Instructions
[How to deploy the challenge environment]
 
## Objectives
[Numbered list of objectives with point values]
 
## Hints
[Progressive hints, from vague to specific]
 
## Solution
[Complete walkthrough of the intended solution]
 
## Alternative Solutions
[Other valid approaches you have identified]
 
## Scoring Rubric
[How to evaluate submissions]

技術實作：

• 為任何自訂元件（聊天機器人、代理、過濾器、API）之原始碼
• 部署組態（Docker、docker-compose 或等效）
• 驗證挑戰正確運作之測試腳本
• 確認預期解決方案運作之解決方案驗證腳本

文件：

• 具設定指令之 README
• 依賴與需求清單
• 已知議題或限制

步驟 3：審查

提交挑戰經兩階段審查：

技術審查（1--2 週）：

• 審查者部署挑戰並驗證其運作
• 測試預期解決方案
• 探測挑戰尋找將其瑣碎化之非預期解決方案
• 評估程式碼品質與部署可靠度

社群測試（1--2 週）：

• 3--5 名志願測試者於不見解決方案下嘗試挑戰
• 測試者於難度、清晰度與樂趣因素上提供回饋
• 回饋與你分享以作最終修訂

步驟 4：發布

於審查後，你之挑戰以以下發布至社群挑戰庫：

• 你作為挑戰作者之歸因
• 將挑戰置於較廣課程之編輯引言
• 基於測試者回饋之社群難度評級

品質標準

什麼造就好挑戰

清楚目標。 參與者應確切知其嘗試達成何。模糊目標挫敗參與者並使評分不一致。

適當難度。 挑戰應足夠困難以需真正努力但不至困難以致目標受眾無法存取。最佳挑戰具「平滑難度曲線」—— 容易開始、困難完成。

教育價值。 參與者應自嘗試挑戰學到某事，即使他們未完成。需模糊瑣事或幸運猜測之挑戰不教授有用技能。

現實情境。 最佳挑戰建模從業者於真實委任中遇到之情境。為教學理由之人工約束可接受，但核心情境應感覺合理。

公平解決方案。 預期解決方案應經系統思考與技能應用可尋獲。需「猜作者之想法」或依賴隱藏假設之挑戰為差設計。

常見拒絕原因

貢獻指引

技術要求

• 容器化部署。 挑戰必須可經 Docker 或 docker-compose 部署。無手動伺服器設定。
• 冪等設定。 多次執行設定腳本應產出同一結果。挑戰狀態應為可重置。
• 資源邊界。 挑戰應於具 4 CPU 核心、8GB RAM 與選配 1 GPU 之單一機器執行。若你之挑戰需更多資源，於提案中註記此。
• 於執行時期無外部依賴。 挑戰不應依賴可能變為不可用之外部服務（第三方 API、實時網站）。若需要，mock 外部服務。

內容要求

• 無真實有害內容。 涉及越獄之挑戰應使用良性代理任務。涉及資料外洩之挑戰應使用虛構資料。
• 清楚授權。 所有程式碼必須以 MIT 或 Apache 2.0 授權。所有內容必須為原創或適當歸因。
• 包容語言。 挑戰情境不應依賴刻板印象或潛在冒犯內容。

維護承諾

當你貢獻挑戰時，你同意：

• 於 7 天內回應錯誤報告
• 若底層模型或 API 變更則更新挑戰
• 至少參與他人挑戰之一輪社群測試

當前貢獻挑戰

以下挑戰由社群成員提交並審查：

開始

1. 研究現有挑戰。 審查上述每月挑戰與貢獻挑戰以理解品質門檻與格式。
2. 辨識缺口。 什麼技術或情境未被現有挑戰涵蓋？於學習時你在何處掙扎以尋找練習材料？
3. 起草提案。 使用上述提案樣版。首先聚焦於學習目標，然後圍繞其設計挑戰。
4. 建立原型。 於撰寫完整提交前，建立最小版本並自己測試。許多於理論聽來好之挑戰想法於實務不運作。
5. 提交與迭代。 提交你之提案、納入回饋、建立完整挑戰並經過審查過程。

社群挑戰庫經所有層級之從業者貢獻成長。你之獨特觀點與經驗可建立無他人可之學習機會。

挑戰設計原則

好之挑戰設計本身為技能。這些原則，自多年 CTF 與挑戰設計經驗發展，將協助你建立參與者享受並自之學習之挑戰。

難度漏斗

最佳挑戰具「漏斗」結構：容易開始、漸進較困難完成。首步應於目標難度層級對任何人可存取，給予參與者早期動能與信心。最終目標應延伸即便強參與者。

具體範例：提示提取挑戰可能具於系統提示中可見之旗標（容易定位）但於多防禦層之後（困難提取）。參與者快速理解其所需 —— 旗標就在那 —— 但取得其需漸進更精巧之技術。

避免「猜我之想法」挑戰

最糟挑戰需參與者猜作者之特定預期方法而非獎勵任何有效方法。挑戰具此問題之徵兆：

• 解決方案需嘗試挑戰中任何線索未建議之非常特定提示
• 多個看似有效之方法存在但僅一實際運作，且無試錯區分它們之方式
• 挑戰描述省略解決其之關鍵資訊

提供有意義回饋

參與者應可分辨其是否取得進展。此不意味贈送解決方案 —— 其意味設計挑戰使部分成功可見。例如：

• 為不同失敗模式回傳不同錯誤訊息之系統給予參與者關於其打中何防禦之資訊
• 目標可獨立完成之多目標挑戰使參與者量測部分進展
• 顯示系統內部狀態之除錯輸出或工具呼叫軌跡協助參與者理解為何其方法運作或不運作

以真實使用者測試

無任何自我測試量替代讓他人嘗試你之挑戰。於提交前請兩三人嘗試：

• 於目標難度層級之一人（以驗證挑戰適當困難）
• 於目標難度層級之上之一人（以檢查非預期捷徑）
• 於目標難度層級之下之一人（以驗證即便挑戰對其過難，指令清楚）

撰寫完整解決方案

你提交之解決方案應涵蓋：

• 預期方法 —— 你設計挑戰以教授之路徑
• 你知之替代方法 —— 運作之其他有效解決方案
• 看似有希望之非解決方案 —— 似乎應運作但不之方法，及它們為何失敗
• 邊界情況 —— 技術上滿足成功標準但非於挑戰精神之不尋常方法（決定允許或阻擋這些）

維護你之挑戰

貢獻挑戰為進行中責任。模型變更、API 演進且防禦改善。常見維護任務：

• 模型版本更新。 若你之挑戰針對特定模型版本，於新版本發布時測試其。行為變更可能使挑戰較容易、較困難或不可能。
• 基礎設施更新。 保持容器映像與依賴最新。於挑戰基礎設施中之安全漏洞令人尷尬。
• 社群回饋。 監控你挑戰之回饋。若多參與者報告同一混淆或挫敗，挑戰需修訂。
• 難度重新校準。 隨社群之集體技能改善，曾經困難之挑戰變常規。考慮加入較困難目標或建立具更新防禦之「v2」。