GitHub 個人檔案 README 是由個人檔案持有人撰寫並控制的，因此其中關於職務、雇主或職涯經歷的任何內容都屬於自我陳述。把自行撰寫的自傳與精選儲存庫及貢獻顯示區分開來，然後依每項素材實際顯示的內容加以標示，而不要把客氣的自我介紹升級成已驗證的任職紀錄。
使用我們的 TraceSeek 應用程式尋找公開社群檔案線索。
辨識 README 屬於哪一種證據
個人檔案 README 是持有人自行撰寫並控制的頁面；它可以包含自傳、圖片、貢獻描述及其他個人內容。這使它成為一種呈現方式的選擇，而不是由雇主、薪資系統或驗證服務所產生的紀錄。當一份職涯摘要重述該文本中的職稱或公司時，它只是在重述持有人自己的話。誠實的標示是自我陳述。 [GitHub：公開個人檔案元素]
- 開啟 README，記下哪些行描述了職務、日期或雇主。
- 在閱讀任何針對這些內容的摘要之前，先把每一行都標記為作者自行撰寫。
把自傳、精選項目與貢獻放在各自獨立的欄位
同一個個人檔案彙整了數個不同的元素：README 自傳、持有人選擇凸顯的精選儲存庫與 gist，以及各自獨立的貢獻、狀態與徽章顯示。貢獻圖的變動代表活動，不是任職認證。精選專案顯示某人選擇展示什麼，不代表某家具名公司曾聘用他們。把這些當成一個混合的故事來讀，正是摘要從描述偏離成背書的地方。 [GitHub：公開個人檔案元素]
| 觀察 | 限制 | 下一步 |
|---|---|---|
| README 陳述了職稱或雇主 | 由作者自行撰寫；無雇主驗證 | 在摘要中重新標示為自我陳述 |
| 精選儲存庫與職涯陳述並列出現 | 精選代表強調，不代表聘用或付酬 | 將專案與任職保持為各自獨立的項目 |
| 貢獻圖顯示活動 | 顯示的是該個人檔案上的活動，不是職務 | 不要把活動轉換成職務陳述 |
| 個人檔案隱藏活動，但保留 README | 隱私設定決定可見性，不決定真實性 | 記錄這項可見性限制，就此打住 |
重新標示缺乏佐證的任職陳述
改寫主要是刪減。把讀起來像已確認任職的詞句，改成單純的歸屬陳述，例如「個人檔案自稱擔任某職務」，或「作者描述在某公司的工作」。引用時保留對方原話不變，並把歸屬說明放在引號之外。這既保留了有用的資訊，也去掉了該素材從未獲得的地位。
- 在整份摘要中，對作者的陳述使用一致用語。
- 刪除任何暗示 README 中含有雇主確認的措辭。
將摘要標示為作者文本的濃縮
把 README 中的職涯經歷視為持有人自己的描述，並在摘要中出現的每一處都如此標示。讓這項標示與引用的自行撰寫文字明確區隔，使讀者能看出哪些字是作者本人的、哪些是摘要的框架。 [GitHub：公開個人檔案元素]
停在素材的邊界
如果 README 不存在、儲存庫是私人的、個人檔案與眼前的人不符，或文本含義不明，正確的做法是記錄這項確切的限制並停下來。不要索取私人帳號存取權，不要將相似的照片或帳號名稱等同於已驗證的帳號所有權，也不要用推論填補空缺。像「未發現公開的任職證據」這樣精確的註記，比一句建立在空無之上的自信斷言更有用。 [GitHub：公開個人檔案元素]
- 寫下一行，指出缺失或含義不明的來源。
- 任職一節就到此為止，不要猜測。
用一份簡短的工作表讓標示保持誠實
針對每一項被聲稱的職務，列出 README 的確切句子、註明它由持有人撰寫、把任何另行精選的儲存庫列為凸顯項目，並記錄你將使用的標示。這份工作表是供你自己閱讀時參考的編輯建議；它不是平台功能，也不是測試結果。 [GitHub：公開個人檔案元素]
還有幾個問題
一份精美的 GitHub README 能驗證某人的任職嗎？
不能。README 由個人檔案持有人撰寫並控制，因此它反映的是那個人選擇如何描述自己的職涯。只有獨立來源，例如雇主本身，才可能支持驗證性的說法，而 README 中並不存在這類來源。
精選儲存庫能支持職涯摘要中的職稱嗎？
單憑它本身不行。精選儲存庫與 gist 是持有人選擇凸顯的項目；這項選擇與誰聘用他們、擔任什麼職務毫無關係。把專案保留為凸顯項目，把職稱保留為作者的陳述。
如果個人檔案是私人的或隱藏了活動，我該怎麼辦？
私人個人檔案會隱藏貢獻活動與其他社群功能，但選填的 README、個人簡介與大頭貼可能仍公開。記錄確切的限制，並在該處停止對就業狀況的推論，而不是尋求私人存取或加以猜測。
來源與編輯說明
官方參考資料查核於 2026年10月24日。檢查清單、比較表格與範例措辭是 DateClues 的編輯工具，並非官方測試或經驗證的風險分數。
一般資訊。任何指南或工具都無法保證某人的身分、意圖或安全。 閱讀我們的編輯準則。