如何建立文件修訂紀錄
如何建立文件修訂紀錄：它需要哪些欄位、為何紀錄冊是一份獨立於文件本身、只可新增的紀錄，以及大部分手製表格完全略過的核實步驟。
文件修訂紀錄，是版本控制這種做法所產生、並保持準確的成品——一張列有版本、日期、作者、描述與核實人的表格。
簡而言之
- 修訂紀錄是成品（一張表格）；版本控制是保持它準確的那套做法。
- 最低限度的欄位：版本、日期、作者、描述、前一版本引用、核實人。
- 只可新增：修正一條錯誤的項目要靠新增一行，絕不修改舊有那一行。
- 一條沒有人對照真實改動查核過的項目，是一個說法，不是一條紀錄。
- QueryChart 透過它的變更日誌自動產生這一切——見 /features/version-control。
表格是一份紀錄，不是那套紀律本身
修訂紀錄，是大多數讀者一聽就會想到的那張表格：一個版本編號、一個日期、做出這次變更的人的姓名、一段簡短描述改了甚麼，通常還有審閱人的姓名。它是一項成品——表格裡的幾行，通常坐落在文件自己的封面頁上。版本控制則是另一回事，是產生那些行的東西：不寫一條項目就絕不修改受控文件、事後絕不改寫一條項目，以及由編輯者以外的人，對照實際改動查核那條項目，這種做法。一份文件可以帶着一張看起來很完整的修訂紀錄，背後卻完全沒有真正的版本控制——如果從來沒有人對照實際改動查核過任何一行。
把修訂紀錄，當成一個跟它所描述的文件分開的獨立對象，不是文件裡的一個章節。文件會改動；紀錄冊卻只會增長。每一條項目都需要一個版本編號、一個日期、一位作者、一段以淺白語言寫的變更描述與原因、一個指向它取代的版本的引用，以及——大部分手製表格漏掉的那一欄——誰對照真實改動核實過這條項目。漏掉最後這一欄，紀錄冊就成了一組未經核實的說法：作者對自己那次變更的自述，由改動它的同一個人歸檔。
下面的圖表，走一遍一個通用的紀錄項目流程——五條泳道裡的十六列——在流程裡移動的東西，是紀錄項目本身，不是文件。一項申請開立一條待處理項目，一位作者實施變更並歸檔一段前後描述，一位審閱人在結案任何東西之前，把那段描述對照實際改動比較，一位審核員之後再抽查已結案的項目。那個比較步驟，正是一份手製試算表幾乎從來不會有的東西，因為沒有人的職責明確是去執行它。QueryChart 徹底取代了那張手製表格：圖表的每一次修改，都被捕捉進一份帶有欄位級前後值與編輯者姓名的變更日誌裡，可以在比較版本畫面看到，見 /features/version-control——沒有人需要打字輸入項目，因為那本來就是實際被編輯過甚麼的紀錄，不是一份自述。
十六列，五條泳道，一條紀錄項目
看着單一條紀錄項目，由申請走到經核實、可供審核抽查的結案——一張手製表格通常略過的那些欄位，以流程的形式鋪陳出來。
一項申請，還未成為一條項目
起點列是「針對一份受控文件申請變更」——一個事件，不是一項任務——其後是「提交變更申請，附上原因與目標文件」，在任何東西被記錄之前，點名確切的文件與原因。「變更是否獲批准記錄？」決定一條待處理項目會不會被開立。
項目開立在先，改動在後
只有在獲批之後，「開立一條待處理紀錄項目」才會出現，是「檔案」形狀的列，不是某人收件匣裡的一則便條。「編配項目編號並連結文件」與「把變更指派給一位作者」都在紀錄冊負責人的泳道裡發生，早於作者泳道開始——這條項目作為一份紀錄存在，比文件被改動任何一個字都要早。
核實，不只是一段描述
「在文件中實施變更」把工作帶進作者的泳道，「記錄前後描述、作者與日期」則歸檔為它自己獨立的一列，而不是併進那次改動裡。之後「把紀錄項目對照已實施的變更查核」與「是否已對照文件核實？」，要求審閱人把項目的文字對照真實改動查核，之後才有人信任其中任何一方。
一個不一致，然後是結案與審核
「差異出在文件還是紀錄項目？」會把未通過的查核，送回「在文件中實施變更」或「記錄前後描述、作者與日期」，看是哪一方出錯。一條已核實的項目會到達「結案紀錄項目」、「通知申請人變更已完成」與「在定期審核中抽查已結案項目」，然後才到終點「修訂紀錄項目已結案並可供審核」——另一個出口是「申請被拒絕，不予記錄」，回到最頂端。
運作方式
把紀錄冊跟文件分開
把修訂紀錄放進它自己的成品裡——封面頁上的一張表格，或者一本獨立的登記冊——絕不能是埋在正文裡的一段文字。文件會改動；兩者之中，只有紀錄冊可以只增長，不倒退。
在第一條項目之前，先訂定欄位
版本編號、日期、作者、以淺白語言寫的變更描述與原因、一個指向它取代的版本的引用，以及誰核實了這條項目。漏掉最後兩者的任何一個，就沒有辦法分辨一條經查核的紀錄，跟作者的自述。
在改動之前開立項目，不是之後
在一項變更獲批的那一刻，就記錄一條待處理項目——編號、文件連結、指派的作者——早於任何人打開檔案。一條事後才寫下的項目，是憑記憶重建的，而這正是紀錄冊存在的目的所要防止的失效模式。
寫下改了甚麼，不只是有東西改了
「更新了第 4 節」不是一段描述；「把第 4 節的審批門檻由 500 美元改成 2,000 美元」才是。以淺白字句記錄改動前後、作者姓名與日期，令讀者不用打開文件自身的歷史，也能重建那次變更。
對照真實改動核實項目
在項目結案之前，找一個不是作者的人，把紀錄冊裡的描述跟文件裡實際改動的內容比較。如果兩者不一致，查清楚是文件錯了還是項目錯了——更正項目，對作者來說不一定是一種倒退。
抽查已結案項目，不用逐一覆核
建立一次定期審核，按屬於審核計劃、而不是臨時起意的一個時間表，抽查一批已結案項目，對照它們的文件。這正是令這本紀錄冊，變成一樣你不用自己重新核實一遍也能信任的東西的原因。
應避免的錯誤
把紀錄冊當成一場記憶測驗
在改動幾天之後才寫項目，會把一份紀錄變成一次重建。在變更獲批時就開立待處理項目，並在改動完成的同一天歸檔前後描述，而不是靠某人幾星期後的記憶。
原地修改歷史
為了修正一段錯誤描述，去更正試算表第三行，會摧毀修訂紀錄存在的目的本身——證明何時記錄過甚麼。改為新增一行；/yue/guides/如何追蹤sop的變更 與 /yue/guides/如何管理sop修訂，專門針對 SOP 覆蓋了這套只可新增的紀律。
一本沒有人對照文件查核的紀錄冊
一張有版本與描述欄位、卻沒有核實步驟的表格，是一組說法，不是一條紀錄。像上面圖表裡的「把紀錄項目對照已實施的變更查核」那樣，給比較這件事它自己獨立的一列與負責人，否則這本紀錄冊的可靠程度，就只等於作者的記憶。
把紀錄冊跟產生它的流程混為一談
修訂紀錄記錄的是改了甚麼；它並不決定誰可以批准一項變更，或者被取代的副本存放在哪裡——那是文件管制，完整覆蓋見 /yue/templates/文件管制流程。兩者都要建立，但要當成兩項獨立的成品來保持。
建立你自己的修訂紀錄冊
把紀錄項目流程圖開成你自己的範本，把你自己的文件類型放進泳道，然後讓 QueryChart 的變更日誌保存這份經核實的歷史，取代一張試算表。
相關指南
常見問題
修訂紀錄跟版本控制有甚麼分別？
修訂紀錄是成品——列有版本、日期、作者、描述與核實人的表格。版本控制則是保持那張表格誠實的做法：不寫一條項目就不改動任何東西的規則、項目事後絕不改寫，以及由作者以外的人拿兩者互相核對。你可以有一張修訂紀錄，背後卻是薄弱的版本控制——表格存在，卻從來沒有人對照真實改動核實過任何一行。
一張修訂紀錄表格需要哪些欄位？
版本編號、日期、作者、以淺白語言寫的變更描述與原因、一個指向它取代的版本的引用，以及——大部分手製表格都會漏掉的那一項——誰對照實際改動核實過這條項目。漏掉最後這一欄的一行，是作者的自述，不是一條經查核的紀錄。
如果一條舊項目有錯，應該修改修訂紀錄去修正嗎？
不應該。新增一行去更正紀錄，而不是改寫舊的那一行；這本紀錄冊值得信賴的程度，取決於它只可新增的歷史有沒有保持完整。如果出錯的是文件而不是項目，修正應該以一次新的文件修訂進行，而不是改寫紀錄冊裡的一行。
一本手動維護的試算表，對修訂紀錄來說夠用嗎，還是需要軟件？
一份試算表在有人修改一行而不是新增一行之前都可以運作，但這種情況很難防止，也很容易被忽略。QueryChart 的版本歷史，會自動寫出等效的紀錄——為每一次修訂配備欄位級的前後值與編輯者姓名的變更日誌，可以在比較版本畫面查看，並隨時可以還原，見 /features/version-control。上面的圖表，展示的是同一套紀律的手動版本——一項申請、一段歸檔的描述、一個核實步驟——無論由哪一個工具運作它。
