論述
憑什麼要開源？
這是這個專案最該被質問的一題，也是我們最想正面回答的一題。 如果你只讀一頁，讀這頁。
先承認一件事：內部 wiki 也能解決那些痛點
重複回答同樣的問題、新人沒人教、資深離職把知識帶走 —— 這三件事確實很痛。 但誠實地說，這三件事，一份做得好的公司內部知識庫也能解決。
所以如果一個開源知識庫的全部理由只有「省時間」，那它站不住腳。 真正需要回答的問題是：憑什麼要公開？公開對你有什麼好處，是關起門來做拿不到的？
因為這是產業級的重複投資，不是公司級的效率問題
容積率怎麼算、使用執照怎麼送、防火區劃怎麼檢討、陽臺回計容積的邊界在哪 —— 這些題目沒有任何一題是某一家公司獨有的。
全台灣幾千家建築師事務所、營造廠、室內裝修公司，每一家都在自己摸索同一批答案； 每一家都有一份不完整的內部筆記；每一份筆記都會隨著寫的人離職而失效，然後下一個人重新摸一遍。
這不是哪一家的管理問題。這是整個產業，在同一批已知的題目上， 年復一年地重複燒錢。
而重複投資這種問題，本質上單一公司自己解不掉 —— 你把內部 wiki 做到滿分，也只是讓你這一家不再重複，隔壁那幾千家照樣重複。 要解掉它，答案必須在公司的邊界之外。
那為什麼是現在？以前為什麼不行？
「大家一起寫一份共同的知識庫」從來不是新點子。它以前失敗，是因為兩個很硬的現實理由。 而這兩個理由，都剛好在最近幾年鬆動了。
理由一：寫下來沒人看 —— 現在有讀者了
內部 wiki 的墳場人人都看過：寫的時候很認真，三個月後沒人翻，半年後連搜尋都搜不到想要的那句話。 知識寫下來的邊際效益太低，所以沒有人有動力持續寫。
現在變了。寫下來的東西有了一個全新的、而且極度勤勞的讀者：AI agent。
你寫一次 domain.md，AI 就能在新人第 87 次問使照流程時，拿它給出一個有依據的答案。
你不必在場，不必被打斷，也不必擔心自己講漏了哪一條。
筆記從死檔案，變成了一個活的同事。
這是 Agent Skills 這類開放格式在這兩年成立之後，才第一次真正可行的事。 寫知識的投報率，被 AI 改寫了。
理由二：公開沒好處 —— 但護城河的位置移動了
這是真正關鍵的一點。過去「知道法規怎麼查、流程怎麼跑」確實是競爭力 —— 因為資訊不對稱，知道的人就是比不知道的人值錢。
但當 AI 能讀懂公開知識，這種競爭力正在快速貶值。 你不公開，別人也會公開；你不寫，AI 也會從別的地方拼湊一個（可能是錯的）答案出來。 「查得到的知識」正在下沉成基礎設施 —— 就像水電，不是誰的護城河。
護城河沒有消失，它往上移動了。真正值錢的變成：
- 設計判斷 —— 在一堆合法解裡挑出對的那個，這件事 AI 做不到
- 業主關係與信任 —— 沒有任何文件寫得下來
- 跨專業整合能力 —— 把結構、機電、法規、預算收斂成一個能蓋的方案
- 承擔責任的資格 —— 簽證是法律授予的，不是知識授予的
把已經在下沉的東西公開，換整個產業的基準線上升 —— 對真的有能力的人，這是淨賺。 會因為「法規查詢知識公開」而失去競爭力的，本來也守不住那條護城河。
而且它不會停在寫完的那一刻
這是「活的」和「死的」真正的分界，也是幾乎所有內部知識庫失敗的地方。
共用資料夾、內部 wiki、Notion、某位主管硬碟裡的範例集 —— 幾乎每家公司都有過。 現在去打開你們公司那一份，看一眼最後修改日期 —— 那個日期，就是它真正的死亡時間。 它們失敗的原因從來不是寫得不好，而是寫完的那一刻就開始過期，而沒有人有理由回去更新。 維護是某個人的額外工作，而額外工作永遠排在最後。
開源知識庫的結構剛好相反：
內部資料庫的讀者沒有修改的權力，也沒有修改的動機。
開源知識庫的讀者，天生就是可以改它的人 —— 使用即維護。
每一次有人把某個技能拿出來用，就是一次「這段還準不準」的檢驗。 發現條號變了、發現某個縣市的做法不一樣、發現漏了一個前提 —— 當場改掉，下一個人看到的就是修好的版本。 改動留在 git 歷程上，誰在什麼時候改了什麼都查得到。
死的資料庫越用越舊，活的經驗越用越厚。 差別不在紀律，在結構。
新人和老鳥，都同時在兩邊
最常見的誤解是把這件事想成慈善：資深的人把知識捐出來，資淺的人拿去用。 如果真是這樣，它撐不了多久 —— 沒有人能長期靠善意運作。
實際的結構是雙向的：
老鳥也是受益者
因為沒有人是全領域的老鳥。 你在容積計算是老手，在機電配管就是新手； 你在台北市送審熟得不用查，換到台中就得重新摸一遍地方自治法規； 你做了二十年住宅，第一次接文化資產案子時，跟新人沒什麼兩樣。 專業的深度是垂直的，而案子是水平的 —— 這就是老鳥需要這個庫的理由。
新人也是貢獻者
而且是很關鍵的一種貢獻。新人卡住的地方，就是這份知識真正的缺口地圖。
老鳥寫知識最大的盲點是「這不是大家都知道嗎」 —— 他們早就忘了自己當年卡在哪裡，所以會把最關鍵的那一步跳過去。 只有還在卡的人知道到底哪裡不通。 所以新人問的「笨問題」不是打擾，是這個庫最需要的輸入； 把卡住的過程寫下來，本身就是一篇別人用得到的內容。
於是它變成一個交換：每個人在自己的專長處貢獻，在陌生的地方受益。 這種結構才撐得久，因為每一方都有實際拿到東西。
「那我不就是在幫競爭對手？」
會這樣問是合理的，所以直接回答。
一、你公開的不是你的案子，是產業的公共常識。 這裡收的是建築技術規則怎麼適用、送審流程怎麼跑、標章怎麼評、工序怎麼排、案子怎麼管 —— 這些本來就是公開資訊，只是散落在各處、要靠經驗才拼得起來。 你的設計手法、你的成本結構、你的業主名單，這個庫從來不收， 貢獻指南裡也明訂了保密邊界。
二、先寫的人定義標準。 當 AI 成為新人和業主查詢台灣營建知識的主要入口，那個入口裡放的是誰整理的判準， 會實質影響整個產業的做事方式。這件事已經在發生了， 差別只在於是由懂的人來寫，還是放任 AI 拿美國規範來答台灣的案子。
三、貢獻是署名的。 每一筆知識都留下貢獻者，每一次修改都留在 git 歷程上。 對個人、對事務所來說，這是可被看見的專業信用 —— 而不是無償的付出。
所以這裡要蓋的是什麼
不是一家公司的 wiki，是台灣 AEC 的公共知識基礎設施 —— 讓 AI 真的懂台灣怎麼做事，而不是每次都拿美國規範亂答你。
而基礎設施跟資料夾的差別，不在於量，在於可不可追溯。
這些東西講錯是會出事的。所以這個庫的核心不是「收了幾篇」，而是每一條知識都要能回答： 它從哪裡來？依據是哪一條？誰改過、什麼時候改的？哪些部分還不確定？
這也是為什麼我們把 資料狀況整頁攤開給你看，包含難看的數字。 一份誠實標示「哪裡還不可靠」的知識，比一份假裝完整的知識有用得多 —— 後者在專業場合是有害的。
我們不做什麼
- 不收未經授權的業主資料、案件圖說、契約與報價
- 不取代技師簽證 —— 這裡的內容不構成專業建議，也不承擔設計責任
- 不做成單一廠商綁定的產品 —— 採開放格式，任何 agent 都能讀
- 不隱藏缺陷 —— 空的分類就顯示是空的，只有骨架的說明就標出來
誰在做這件事
專案由 加號設計數位工程有限公司 徐灝發起， 但它不是一家公司的資產 —— 內容採 CC BY-SA 4.0，程式碼採 Apache 2.0，任何人都能自由使用、修改、 帶回自己的組織，唯一的要求是改良後同樣公開。