上圖為笈成的資料建置之大致流程，茲說明如下。

首先尋找最佳品質的可用電子文本。笈成目前收錄文本主要來源包括行政院衛生署中醫藥委員會建置之82部典籍、醫籍650文本、中醫瑰寶苑網站之651~699文本、《漢典》之31部電子書、永諸藏書數十部、及其他網路文本，格式有TXT、DOC(X)、PDF、HTML等，詳見參考資源。

取得文本後，將電子文本轉置為HTML5格式的笈成文本，而後持續以程式處理、人工校對、差異比對等方式改進「笈成資料原始檔」（即笈成文本與共用網頁模版）的品質。

製作「笈成站台產生器」，可將笈成資料原始檔輸出為靜態網頁，以便發布於大部分伺服器環境。

中醫笈成網站即是將前述靜態網頁同步發布至伺服器，並加上其他站台輔助程式提供進階功能，例如自動轉換缺字的笈成檢字系統。將本地資料同步到伺服器的工具很多，如rsync及FreeFileSync皆可，本站主要使用rsync。

笈成資料原始檔、笈成站台產生器皆以Git做版本控管，並發布於GitLab供開放協作。

實用工具

Git

我們主要使用Git作為版本控制系統。使用版本控制系統的目的在於記錄每次修訂，以便在發生錯誤或有疑義時可追溯及還原。Git使用特殊的壓縮格式儲存資料，可節省大量儲存空間。按我們實際使用情形，儲存50000個修訂版本大約只需要最新版本資料的7倍空間。

除此之外，Git還支援版本線的分支、合併、移植、重新定基等進階功能，對於整理資料及多人協作亦大有助益。

Git為命令列介面，功能強大，但不易上手，可額外安裝圖形介面以利上手及提高一些基本操作的效率。Windows作業系統可使用TortoiseGit，跨平台使用者可考慮SourceTree等圖形介面。

WinMerge

WinMerge主要用於文字檔的差異比對，介面完善易用，可單獨使用或整合Git圖形介面使用。

Notepad++

Notepad++是國人開發的純文字編輯軟體，提供完善的純文字編輯功能，且有語法標示、自動補完、正規表示式搜尋／取代、多檔案搜尋／取代等功能，執行速度也很快，一般可完全取代Windows內建的記事本。

示例：如何利用上述工具快速提高資料品質

許多中醫數位文本最初是由中國建立，而後轉為繁體中文，或有經過校對，但錯誤仍所在多有。假設我們發現許多已收錄的文本有錯誤的簡轉繁「炒松」（應為「炒鬆」）……。

1. 用Git將目前版本記錄下來，假設為版本A。
2. 用Notepad++的「在檔案中尋找/取代」功能，指定將資料目錄下所有「*.html」檔案的「炒松」取代為「炒鬆」。
3. 將更動提交為新版本B。可在提交訊息註明為全自動修改，並記錄使用的尋找及取代條件，以利事後追查。
4. 比對所有更動的文字，檢查是否有錯誤。可用圖形介面TortoiseGit和WinMerge列出所有被更動的檔案，逐一進入比對有差異處，亦可在命令列用「git diff」列出差異摘要逐一瀏覽。
5. 若發現散在的錯誤，則手工修訂之。
6. 若發現大量有規律的錯誤，例如多處「炒松子」被誤改為「炒鬆子」、「炒松节」被誤改為「炒鬆節」，則退回版本A，修改條件再試一次，如此例可改為尋找正規表示式「炒松(?!子|节)」取代為「炒鬆」，然後再提交為新版本B2。
   • 就此例而言，亦可在版本B對所有檔案做「炒鬆子」取代為「炒松子」、「炒鬆節」取代為「炒松節」之操作再提交為新版本。最佳做法視具體情況而定。
   • 若在執行6.之前已做了一些5.的修訂，可將已做的修訂先提交為新版本C，按步驟6.退回版本A，更改條件，重新取代，提交為新版本B3，再移植C的修訂（git cherry-pick C）即可。
7. 重複上述步驟，直至確認被更動的內容無誤，即完成此次的修訂工程。

簡而言之，即是利用機器處理大量重複、類似的問題，再藉由差異比對找出剩餘的少量問題人工修正，即可快速提高資料的整體品質。

附：為何沒有選擇維基文庫？

維基文庫是開放自由編輯的古籍資料庫，與維基百科一樣是用MediaWiki架設。我們當初曾考慮過在上面整理資料，但實際操作後發現一些限制：

• 維基內建語法無法滿足語義化整理古籍資料的需求：維基文庫雖允許自訂模版，但模版語法仍有侷限，且模版需調用模版頁面，導致依賴整個伺服器環境，一旦脫離伺服器，撰寫工具解析及處理內容即相當困難。按此，在維基文庫上很難做到如目前典籍檢索器強大的檢索功能。
• 維基文庫難以有效利用資訊技術做大規模修改：因資料皆在伺服器上，且維基文庫為防止破壞訂下許多限制，撰寫機器人修改文本曠力費時，操作速度也慢。一般機器人約15秒編輯一個頁面，若資料有3萬頁，須125小時才能完成；而前述本地檔案尋找取代的方式，一般只要10秒至1分鐘即可竟功。
• 基於頁面而非整個資料庫的版本控制不利復原：MediaWiki的版本控制是針對個別頁面，雖有其優點，但整體而言不如Git針對整個版本庫的版本控制靈活。例如Git可以把「所有頁面將X修正為Y」記錄為一個版本，而MediaWiki會把對每個頁面的編輯分別記錄，產生成千上萬個修訂，導致查閱不便。若大規模編輯出錯，MediaWiki要復原所有被破壞的頁面並不容易（非管理者只能再寫個機器人，以同樣慢的速度逐頁編輯復原）；而用Git只要一個簡單指令即可完全復原。
• 缺少私人空間：MediaWiki是完全公開的系統，設計上未提供私人空間，使用者想嘗試任何操作都會立即留下永久的公開記錄，這種特性讓一些使用者望而卻步。MediaWiki雖然支援即時線上編修，但行動設備編修文本的效率其實不高。相較之下，基於Git的流程讓使用者能在自己的設備，用最習慣順手的純文字編輯器，寫無限次草稿，做無限次程式操作，還能重整版本記錄，直至一切妥當再發布上線，更為靈活高效。
• 此外，維基文庫系統龐大，人員眾多，要做大規模、自動化修訂需要大量溝通協調，時程往往會拉得很長，難以有效率推行。

總體而言，維基文庫的設計是以人工即時編輯為主，而我們要大量程式操作，因而不適合以之作為主要平台。話雖如此，維基文庫仍是優秀的協作系統，也收錄了大量優質文獻，若有志者願意做雙向的資料共享與整合，我們樂觀其成。

至於其他wiki系統，按我們過去嘗試以DokuWiki建置《笈成資料庫》的經驗，自架DokuWiki允許自訂語法，也允許私人空間，比MediaWiki靈活，但「大規模編輯」及「錯誤還原」仍有相同的困難。此外DokuWiki系統在資料量大時效能會明顯低落，過去《笈成資料庫》的資料量即有效能問題，因此也非理想。