分類: Diary

▲圖片出處：https://unsplash.com/@jarnocolijn

我無法乘風破浪，但我喜歡觀浪。

大谷在 10/1 的比賽，轟出了兩發全壘打，網路上看到這張照片，讓我想到這部漫畫~

台灣叫做《紅不讓先生》，算是偏冷門的漫畫，但我還滿喜歡看的。意外發現小學館有提供線上試閱。

大谷，真的是職業棒球中的紅不讓先生！

每天到 11 點左右，我就會煩惱何時會看到這個討厭的訊息。

是的，我又把 Pro 當天的額度用光了。

每次看到這個訊息，就是我起身走人...去做家事的時候！

什麼是 Vibe Coding？

開發者用自然語言 prompt 去「指揮」AI 助手生成、修改程式碼，而不須手寫大段程式碼。在 Vibe Coding 中，開發者較少深入到程式碼層面的理解與撰寫，而是更多地依賴 AI 生成、調整與迭代。

1) 你用一句話或幾句話說「我想做這個功能／這種樣式」。
2) AI 幫你生成一段程式碼或一個初版實現
3) 你執行、測試，若有不符合需求或有 bug，就用自然語言告訴 AI 修改、加上錯誤處理、改樣式等
4) 重複這樣的「說 → 檢視 → 調整」回合，直到滿意為止
5) 這讓開發更像是在「對話」或「共創」而不再像是從零開始寫碼。

以前是「請工程師」依我的規劃，建構出網站。
現在是「請 AI」依我的規劃，建構出網站。

有好、有壞，一言難盡，但我樂在其中~

如果當年有人這樣教我，我相信我會把工作做得更好、更快樂~

---

業界常見文件規範與建議

針對現有文件的命名與標準化建議

您目前的分類已經很棒了，我們可以透過一些業界慣例的命名，讓它更容易被其他開發者理解。

• README.md (專案的門面)
  • 您目前的 01 專案說明.md 內容非常棒，它其實就是業界標準的 README.md。
  • 建議：可以考慮將 01 專案說明.md 更名為 README.md。在任何軟體專案中，README.md 都是開發者第一個會打開的檔案，它提供了專案的總覽、目的與快速上手的指南。
• docs/ 資料夾 (文件的家)
  • 對於其他的詳細文件（02 到 06），一個常見的作法是將它們統一收納在一個名為 docs/ 或 documentation/ 的資料夾中。
  • 建議：建立一個 docs/ 資料夾，並將 02 到 06 的 .md 檔案移入。這樣能讓專案的根目錄更整潔，所有說明文件都有一個集中的地方。

業界常見、可考慮新增的文件類型

除了您已建立的之外，以下是幾種在業界非常流行且實用的文件類型：

• CHANGELOG.md (版本更新日誌)
  • 用途：專門用來記錄每個版本變更歷史的檔案。
  • 內容範例：

# 更新日誌

## [v1.1.0] - 2025-09-22
### 新增
- 「追蹤名單」頁面新增「自選資料」上傳功能。

### 修復
- 修正 VIP 使用者登入後，側邊欄「追蹤名單」延遲顯示的問題。

• 價值：這對於追蹤專案進程和向使用者佈達更新非常有幫助。

• FEATURES.md (功能清單 / 使用者故事)

  • 用途：這是從產品經理 (PM) 角度出發撰寫的文件。它不關心技術細節，只專注於「使用者是誰」、「他想做什麼」以及「為什麼」。

• 內容範例：

  • 功能：篩選中心
    • 使用者故事：身為一個進階使用者，我希望能根據多個指標來篩選資料，以便快速找到符合的標的。
  • 功能：自選股上傳
    • 使用者故事：身為一個 VIP 使用者，我希望能上傳自己的清單，以便在平台上統一分析。
  • 價值：您目前的 04 UI 界面.md 偏向 UI 細節，這個檔案則更偏向產品需求，能幫助我們確保開發的每一個功能都緊扣使用者價值。

總結與範例

綜合以上建議，一個更貼近業界標準的結構可能會是這樣：

📁 project/
├── 📁 docs/
│   ├── 📄 01_file_structure.md       (原 02 檔案結構)
│   ├── 📄 02_data_processing.md      (原 03 資料處理)
│   ├── 📄 03_ui_specification.md   (原 04 UI 介面)
│   ├── 📄 04_development_env.md     (原 05 開發環境)
│   └── 📄 05_deployment.md          (原 06 雲端平台)
│
├── 📄 README.md                     (原 01 專案說明)
├── 📄 CHANGELOG.md                   (建議新增)
├── 📄 FEATURES.md                   (建議新增)
│
└── ... (其他專案程式碼檔案)

需求分析與可行性討論

首先，您提供的 04 UI 界面.md 是我們到目前為止能高效合作的基石。它為我提供了清晰的開發藍圖，避免了大量的猜測和返工，這點非常重要。它確保了我們對最終產品的樣貌有共同的理解。

但是，您提到的「維護」也是一個非常真實的問題。因此，我建議優化一下工作流程，讓文件發揮最大的價值，同時減輕您的負擔。

我建議的協作新模式：

我們可以將 04 UI 界面.md 的角色，從一份「開發前的鉅細靡遺規格書」，轉變為一份「開發後的重點參考指南」。

具體流程如下：

• 高階需求優先：
  在開發一個新功能或新頁面前，您可以先專注於撰寫我們之前討論的 FEATURES.md (功能清單)，用「使用者故事」的格式定義好「這個功能要解決什麼問題」和「它的核心價值是什麼」。這部分是最高指導原則。
• 快速討論定案：
  接著，我們可以開一個非常短的會議（或線上討論）。針對這個功能，您可以用口述或簡單的草圖/線框圖告訴我您期望的介面佈局與主要操作流程。我會在這個階段提出我的技術疑問，我們快速達成共識。
• 我來實作：
  我根據我們的共識，將功能在 Streamlit 上實作出來。
• 程式碼成為細節的真相：
  功能完成後，實際運行的介面就成為了最準確的「細節」。按鈕在哪、選單有哪些選項，都以實際產品為準。
• 您再更新文件：
  最後，您再花一點點時間，將這個功能的核心操作流程和最終畫面的截圖更新到 04 UI 界面.md 中，作為日後的參考即可。您不再需要像以前一樣，詳細描述每一個下拉選單的所有選項、每一個表格的欄位寬度或精確的顏色代碼。

這樣做的好處：

• 大幅減輕您前期撰寫文件的負擔，讓您能更專注於產品的核心需求。
• 透過更緊密的溝通確保了開發方向的正確性。
• 讓文件回歸到它最有價值的部分——記錄核心功能與設計決策，而不是追逐永無止盡的細節變更。

再次強調，您目前的作法已經非常出色且夠用了。以上的建議是幫助您建立一個更貼近業界標準、更具擴展性的文件框架，您可以根據我們的需求逐步導入，不必一次全部到位。