FunnyTools methodology
FunnyTools 內容來源、審閱日期與錯誤修正方法
網站內容不是發布後就不變；真正重要的是哪些資訊需要追蹤版本、什麼時候應更新，以及錯誤怎麼留下修正證據。
更新：
工具網站會同時遇到兩種知識：
穩定知識
- 加權平均公式
- Base64
- JSON
- UUID標準
會變的規則
- Google Search功能
- NIST密碼建議
- GS1規格
- 學校GPA
- 法規／薪資規則
兩者不能用同一個更新方法。
一、來源優先順序
優先：
- 官方標準／主管機關
- 官方產品文件
- RFC / W3C / MDN / NIST / GS1等技術規格
- 原始研究
- 高品質二手資料
不要把：
SEO部落格
當成技術標準的唯一來源。
二、工具功能來源
FunnyTools自己的功能：
repository code。
如果：
- 中文頁說A
- 西文頁說B
- code說C
應：
先audit code，再修頁面。
不能用文章互相引用解決產品矛盾。
三、什麼時候更新 Date Modified？
只有：
- 公式修正
- 工具行為改變
- 外部標準更新
- 新增重要案例
- 實質重寫
才更新。
不要：
- 每天build改日期
- sitemap自動把所有頁面設今天
- 只改逗號就標「全面更新」
Google People‑First指南明確把：
只為看起來fresh而改日期
列為應避免的search-engine-first行為。
四、Review Date 和 Publish Date 分開
可以有：
- First published
- Last substantive review
- Tool version checked
比一個模糊：
Updated today
更有用。
五、Sources應靠近相關內容
不一定每一句都腳註。
但重要制度claim應能追到：
- official URL
- standard name
- version/date
例如：
NIST 800-63B
應寫清楚使用哪個現行版本。
六、Broken Source怎麼辦？
來源404：
- 找官方新URL
- 確認內容仍有效
- 更新citation
- 若內容已改，更新正文
- 修改review date
不要只換連結但不看內容。
七、使用者回報
好的bug report包含：
- tool URL
- browser/device
- exact inputs
- expected
- actual
- screenshot
- output file（若可安全分享）
這能直接變：
regression fixture。
八、修正紀錄
不是每個錯字都要公開changelog。
但重大：
- formula bug
- wrong standard
- data-loss bug
- privacy disclosure error
應留下：
- issue
- commit
- release note
- corrected review date
九、文章和工具一起修
如果工具公式修了：
相關guide也要同步查。
如果文章標準更新：
tool是否需要改validation，也要檢查。
本指南應建立：
content-to-tool dependency map。
十、不要假造Expert Review
如果沒有：
- 真實姓名
- 真實資格
- 真正完成review
不能顯示：
Reviewed by Expert。
可以誠實寫：
公式已依公開來源與測試案例複核。
這比假badge更可信。
十一、站方身份
現有 About 已清楚說明：
一名學生獨立維護。
本指南 不應為SEO突然捏造：
- 團隊
- 編輯部
- 醫師
- 財務專家
Who 必須是真實。
十二、FAQ
每篇都要每天更新嗎？
不需要。
Google喜歡新日期嗎？
不能因此假更新；內容實質新鮮度才有意義。
使用AI後可以說expert reviewed嗎？
只有真的有expert review才可以。
公式來源可以用Wikipedia嗎？
可輔助理解，但重要標準優先官方／原始來源。