這批社群內容如何標記示例
這批社群內容包含事先撰寫的編輯材料，以及編設的教學情境。讀者不論從哪裡看到，都應有明確標記；不能看似顧客自然發起的談話，也不能當作某次解讀確實產生結果的證據。
以下標記方式供審閱，說明決定發布之前，這批示例應如何區分。它不代表 Mystilink 已採納某項社群政策，也不表示帖子已上線。
說明眼前是哪種材料
虛構練習串應在開頭附近註明虛構；功能提議要說是提議；客服模擬要說問題是假設。各標記在回答不同問題，不宜混成一種模糊說法。
例如，一篇以學習練習為題的串文，可以介紹學習者比較同圖兩種解釋。開頭說明情境是為討論編設的，之後的回覆便可提出不同方法，而不暗示幾位真實使用者各自遇過同一件事。
產品主張也要另標狀態。虛構情境可討論查過的程式儲存庫中存在的功能，卻不能證明正式版本已可使用。情境性質和功能狀態都會影響理解，就兩邊都標。
身分與發言來源都要誠實
預備帖子不能編顧客身分、專業資格或人生經歷。教學可以寫得像談話，不必假稱沒人提供過的體驗。編輯提問可寫「你會怎麼記這項不確定？」，再附清楚標明是預先寫好的示例回答。
用多個聲音示範分歧時，要說是示例回覆，別造成獨立顧客投稿的印象。「我用了好幾年」就是在陳述真實歷程；除非屬實且獲准使用，否則應刪除。
具名貢獻者只能按實際付出署名。AI 協助與編輯責任，應依團隊採納的揭露規則說明；這批材料本身，不能替公司確立那些規則。
討論材料不等於證據
編設討論串能教方法，不能建立顧客需求、滿意度或產品可靠度。虛構客服情境可以展示有效報告該有什麼，不能算成真正的缺陷回報。
同理，預備回覆相互贊同，不能證明社群有共同看法。編輯不應概括為使用者共識。之後取得真實回應時，來源與性質應跟預備示例分開。
虛構解讀能示範怎麼留牌序、怎麼限定詮釋，不能說成準確預測。練習若有後續結果，結果同樣是編的，也得留著標記。
複製出去，標籤也要在
人們常經由預覽、搜尋摘要、截圖或被引用的回覆讀到串文。重要性質應放在容易跟示例一起傳走的文字裡。長頁底部才有標記，開頭單獨分享就可能看不到。
客服模擬可用「假設性排錯練習」開頭，讓目的明白。回覆摘錄可能也需短註，如「預先撰寫的示例回覆」。別只用顏色或小圖示傳達狀態。
封面與圖說也要查。工作區插畫若不是正式功能截圖，就不能這樣標。概念圖只要說是提案、不重現私人資訊，也能有用。
真實案例走另一套流程
日後真有社群成員提供案例，應取得預定用途所需授權，檢查可辨識資料。公開帳號名稱，不自動代表可把詳細人生故事搬進行銷文章。
原始投稿和編輯改動要分得出來。縮寫案例時，保留影響意義的限定，不能挑著引，把不成功經驗寫成正面推薦。
團隊也應決定貢獻者如何要求更正、下架。這些只是流程要求提案，不是說現已有特定管道或回應承諾。相關人員核准、確實能運作後，才適合公布細節。
匯入這批材料以前，檢查標記
編輯應逐一看標題、開頭、回覆和圖說，有沒有暗示真實經驗。找出帶實際使用、個人成果或共同認同意味的句子，保留合理的假設語氣，重寫容易誤會之處。
再把幾個例子拿出完整對話單讀：預覽卡、複製回覆、封面圖說。只要看起來像沒標明的顧客自述，就在匯入或分享前改好。
標記應幫人判斷材料怎麼用。讀者能從虛構例學習，也知道這是在提供可討論的方法，不是在記錄某位顧客經歷。