speckit
含有「speckit」共 4 篇內容
全部內容
發佈日期由新至舊
付費限定
這是一篇記錄「舊系統重構新技術棧」的實戰經驗，我們面對的是一個陪伴公司十年的 PHP 專案，要在不推倒重來的情況下，將它重煉成可延展的 Python + React 架構。
大部分人用 Spec Kit 做 MVP 開發，但鮮少用於「舊專案重構」，這篇文章，就是我們在這條路上的探索與心得如果你也正
1 天前
主要有以下幾點：
1. 目前比較大眾的程式語言已經轉向Python。
2. 系統瓶頸不在語言本身： 我們實際 profiling 過，主要瓶頸在 I/O 與架構層，而非 PHP → Python 的語言效能差距，把架構整理好（模組化、事件流、資料介面清晰）帶來的效益遠大於語言更換本身。
3. 重構目標是「提升可維護性」而非「追求極限效能」
4. 生態系整合： 後續會接 AI、任務流程（如 n8n）、資料服務，Python 生態圈整合起來更順。
如果系統本身是走高吞吐量、高即時性，那 PHP → Go / Rust 這種方向可能更合理，但我們的案例剛好不同。
付費限定
延續上一篇《【🔒江湖一點訣】規格即內功 - 用 Spec Kit 打造穩健的 AI 開發體系》，這次想談談我在使用 Spec Kit 憲章 時遇到的一些真實挑戰與心得。
⚖️ 憲章過於鬆散的副作用
一開始我以為讓憲章「開放一點」比較靈活， 但卻變成了發散，導致專案開始後：
這時我才意識到
2025/11/29
看完才發現，原來憲章不是越硬越好，而是要會呼吸的內功心法。
你把「規範跟自由的拔河」寫成一場武林內功課，工程腦也會點頭。
以後朋友再吵規格，我就丟這篇說：來，先練好內功再出招🤣
付費限定
在 AI 助手協助寫程式越來越常見的今天，許多人也開始遇到這樣的問題：
• AI 幫你寫了功能，但回頭看不太知道為什麼是這樣實作
• 明明說好要「改某個地方」，AI 卻改了太多地方
• 想改一點功能，但團隊彼此說不清楚現在的行為是什麼
• 沒有「規格」，一切只能靠對話紀錄或記憶
在上一篇【
付費限定
在 AI 開發的江湖裡，人人都說「快」才是王道。
Claude Code、Cursor、Vibe Coding 每一招都讓你在數分鐘內構出一個雛形。
但當原型變成產品、團隊從一人變多人，你就會發現：快，不再是問題，穩，才是王道。
而讓專案穩下來的心法，叫做 - Spec Kit（規格驅動開發
