README 裡的表格應該幫助訪客更快回答一個具體問題：我該安裝哪個套件？哪個功能可用？哪個環境通過了？如果把表格當作通用頁面佈局，或者塞進手機螢幕根本放不下的大段文字，它就會變成負擔。
讓每一欄只負責一件事
表頭要短而明確。Package、Runtime 和 Status 比 Information 1、Information 2、Information 3 更有資訊量。需要多句說明的內容，應該放在表格外面。
| Package | Runtime | Status |
| :--- | :---: | :---: |
| `core` | Node 22 | Stable |
| `cli` | Node 22 | Beta |第一欄通常靠左，因為名稱本來就是按文字掃讀的。緊湊的執行環境和狀態欄位可以置中。數值型基準結果通常應該靠右。
使用有意義的連結文字
不要把很長的原始 URL 直接塞進儲存格。像 [API reference](./docs/api.md) 這樣的連結既能縮短欄寬，也能告訴螢幕閱讀器目標內容是什麼。如果表格裡反覆出現「click here」之類的連結，離開上下文後它們就失去意義了。
徽章本質上是圖片，過多會增加視覺雜訊。只在少量持續變化的訊號上使用它們，不要把每一行都裝飾一遍。最好在徽章連結或周圍文字裡提供有用的替代文字。
優化原始碼審閱
Pull Request 審閱者會同時看渲染結果和 diff。盡量做到一行一筆記錄。如果只是一般值變化，不要手工補齊幾百個空格，否則每次改動都會重寫整張表。對於自動產生的相容性矩陣，最好提交產生腳本或原始檔，方便審閱者追溯資料來源。
檢查窄螢幕
GitHub 也許允許寬表格橫向捲動，但使用者很容易失去列上下文。把最重要的識別欄放在最前面，減少欄位數，並把不相關的維度拆成多張表。如果某一列比其他列長很多，它大概率更適合放在獨立小節裡。
保持說明最新
功能矩陣和支援表會很快過期。把它們納入和程式碼相同的審查流程。某次發布如果改變了相容性，應該在同一個 Pull Request 裡更新 README，而不是等後面再補。
先在 Markdown 表格產生器 中建立並對齊原始碼，再在分支或 PR 中確認最終渲染效果，然後合併。