Technical Stack & Principles
技術棧、選型原則與版本策略
這頁是寫給 IT 主管與採購看的:我們實際用什麼、為何這樣選、不會做什麼, 以及你日後如何接手。如果你正在比較幾間 vendor,可以直接用這頁做對照。
我們實際使用的技術
以下為現時生產環境使用中的技術,不是「聽過」的清單。若你的項目需要其他技術,我們會先評估可行性再答覆。
| 層 | 技術 | 選型說明 |
|---|---|---|
| 前端 | Next.js 14、React、TypeScript、Astro、Tailwind CSS | 以靜態輸出為主,兼顧 SEO 與載入速度;需要互動功能時才引入客戶端組件。 |
| 後端 | Node.js(NestJS/Express)、PHP(Laravel)、Python(FastAPI) | 按你現有團隊日後維護能力選擇,不強迫採用我們最熟悉的語言。 |
| 資料庫 | PostgreSQL、MySQL、Redis、pgvector(向量檢索) | 交易類用關聯式資料庫;向量檢索用 pgvector 或外部向量庫。 |
| 雲端與部署 | AWS、Cloudflare(Pages/Workers/R2)、Docker、GitHub Actions | 可部署在你現有雲端帳戶,資源與帳單留在你名下。 |
| AI 與自動化 | OpenAI/Anthropic API、RAG、LangChain、n8n、Make、MCP | 敏感資料可走私有化部署;一般問答走雲端 API,按資料敏感度分流。 |
| 內容與電商 | WordPress、WooCommerce、Shopify、Sanity/Strapi(Headless CMS) | 沿用你現有 CMS 亦可,只換前台呈現,內容不用重輸。 |
五條選型原則
01
先問誰維護,再問用什麼
技術選型的最大風險不是「不夠新」,而是「三年後無人維護」。所以我們先確認你團隊或日後承接方熟悉哪種語言,再決定技術。若你沒有內部團隊,我們會選主流、招聘市場上有人的技術,而不是冷門但省事的方案。
02
能用靜態就不用動態
內容型頁面用靜態輸出(SSG),減少伺服器依賴、加快載入、降低被攻擊面。只有真正需要即時資料的功能才走伺服器端。
03
整合優先於重寫
除非現有系統已無法維持,否則優先以 API/中介層整合。重寫應是最後手段,因為重寫期間業務仍要運作,風險最高。
04
依賴越少越好
每個第三方套件都是日後的升級債。能用平台原生功能就不引入套件;引入的套件必須有活躍維護與明確授權。
05
資料擁有權歸客戶
源碼放在你的版本控制帳戶、雲端資源在你的帳戶、網域與憑證由你持有。我們以授權方式操作,不代持資產。
我們明確不會做的事
敢寫「不做什麼」,是因為這些做法遲早會變成你的風險。
- 不會用 WordPress 外掛硬砌 ERP/CRM 等核心業務系統(效能與資料一致性風險太高)
- 不會使用來源不明、無授權或已停止維護的套件與主題
- 不會把客戶源碼放在我們私有的 repo 而拒絕交付
- 不會以「獨家技術」為由拒絕說明架構(你請第三方審核是合理要求)
- 不會在未經你同意下把資料傳到第三地處理
版本與安全更新策略
- • 框架一律用 LTS 或穩定版,不在生產環境用 beta。
- • 依賴套件每月檢查一次,有已知高危漏洞即時修補。
- • 重大版本升級事前評估影響範圍並提供報價,不默默升級。
- • 部署流程走 CI,每次上線可回滾到上一版本。
常見問題
你哋用嘅技術,我哋內部團隊接手得到嗎?+
可以。我們選用的都是主流技術(Next.js、Node.js、PHP、Python、PostgreSQL),香港招聘市場有供應。交付時會提供架構文件、部署手冊與 30 日技術問答期,必要時可安排與你團隊做交接會議。
我哋現有系統係舊技術,係唔係一定要重寫?+
不一定。我們會先做技術評估,判斷是整合、擴充還是分階段替換。多數情況下可以用中介層(API/資料同步)讓新舊系統並存,按業務優先次序逐步遷移,避免一次過重寫的風險。
源代碼同知識產權邊個擁有?+
驗收付款後,為你項目度身開發的源碼與設計版權歸你所有。我們使用的開源框架與套件依其原有授權(多為 MIT/Apache),不影響你使用。第三方商業授權(例如某些 CMS 或插件)會事前列明費用與歸屬。
你哋會唔會用 AI 生成代碼?品質點控制?+
會用 AI 輔助開發,但所有代碼都要經過人手審核、型別檢查(TypeScript)、自動化測試與代碼審查流程才合併。AI 生成不代表免測試;我們的驗收標準與手寫代碼相同。
