因為這也是我第一次開發 golang，因為就先建立了一個基本的 Docker 開發環境，以下的 Dockerfile 及 docker-compose.yml都可以直接使用，放在這裡供大家參考。

Dockerfile

FROM golang:latest

WORKDIR /app

COPY . .

# RUN go mod init myapp
RUN go get -u github.com/gin-gonic/gin
RUN go get -u gorm.io/gorm
RUN go get -u gorm.io/driver/mysql

CMD ["go", "run", "main.go"]

docker-compose.yaml

version: '3'

services:
  app:
    build: .
    ports:
      - "8080:8080"
    depends_on:
      - db

  db:
    image: mysql:latest
    environment:
      MYSQL_ROOT_PASSWORD: rootpassword
      MYSQL_DATABASE: myapp
      MYSQL_USER: user
      MYSQL_PASSWORD: password
    volumes:
      - mysql_data:/var/lib/mysql

  phpmyadmin:
    image: phpmyadmin/phpmyadmin
    ports:
      - "8081:80"
    environment:
      PMA_HOST: db
      MYSQL_ROOT_PASSWORD: rootpassword

volumes:
  mysql_data:

直接執行

docker-compose up --build // 執行即可

目前這個 docker-compose.yaml 會自動建立資料庫及管理介面的基本環境，可以直接從 0 開始。

完整的程式放在 github https://github.com/ssssuuunnnn/dolang-jin-docker

這個軟體可以在各個平台上執行，是用 golang 開發的，並且它也是一個開源的軟體，安裝簡單，使用上也容易，掃描的報告也非常的清楚。

本次將介紹如何把 grype 安裝在mac。

因為 grype 有支援 homebrew 的安裝，所以可以直接使用。

$brew install grype

安裝結果如下

接下來可以透過–version來確定是否安裝完成。

$grype --version // grype 0.82.0

因為資安的相關資訊都是預先更新至本機grype的資料庫中，需要透過資料庫的資料做比對，因此會需要更新資料庫，更新的話可以用「db update」可以更新，並且也可以透過「db status」查看本機資料庫的狀態。

$grype db update // 更新資料庫
$grype db status // 查看資料庫狀態

指令執行結果如下

最後就可以準備檢查 docker image 了，而檢查指令也很簡單「grype {docker image name}」

$grype {docker image name} // ex:grype golang:alpine3.16

執行結果如下

其中就會看到這個image裡面包了哪些東西，有什麼樣的安全問題。

其中

• INSTALLED 目前安裝的版本
• FIXED-IN 需要更新的版本
• TYPE是包的檔案類型包含但不限於以下幾種：
  • deb (Debian軟體包)
  • binary (二進制文件)
  • apk (Alpine Linux軟體包)
  • go-module (Go语言模組)
• VULNERABILITY 是哪一條資安通報
• SEVERITY 是嚴重程度

在使用Docker hub上已經包好的image時，最好都要先進行資安掃描，確保其安全性，若是必要也是可以將這個檢查結合到CICD的一環，使其安全性可以更加的全面。另外這也可以成為SBOM(Software Bill of Materials)的資料來源之一。

今天就分享到這邊，謝謝大家。

註：

github https://github.com/anchore/grype

homebrew https://formulae.brew.sh/formula/grype

這次分享的是 watchtower，這也是一個開源的專案，也是蠻多人使用，我看了一下這個專案也發展了好一陣子。

這個軟體他本來是直接包成Docker，並且使用Go語言進行開發。這個軟體主要是會定時的掃描Server上目前在執行的Docker有沒有新的版本，如果有新的就會主動進行更新，真的是非常的方便，由其是使用Docker開發的專案，在更新上也是非常的便利。

在軟體安裝及執行上也是非常的簡單，只需要幾個步驟就可以完成。

第一，起手示就是「docker pull」

docker pull containrrr/watchtower

接下來執行

docker run --detach \
 --name watchtower \
 --volume /var/run/docker.sock:/var/run/docker.sock \
 containrrr/watchtower

這樣就可以完成了，只要執行成功，就可以從「docker logs」就可以看到掃描的狀況，如下圖所示。

像是我們看到如果watchtower有發現新的images時，就會自動更新，並且會把舊的image進行刪除，如此一來也不會因為一直抓新版本而佔用過多的空間。

再來我們說明一下可使用的參數：

• –cleanup：更新新image後刪除舊image
• -i 3600：更新頻率
• -s “0 0 3 * * *“：指定更新時間(寫法同crontab)
• –run-once：只更新一次(手動更新)

參數最後可填寫指定更新的的container名稱

以上是最基本的參數設定，有需要還可以到官網的文件

結語

上面的範例是使用了一般公開的image，而自己在開發時所會打包的docker可以透過CICD先上傳到私有的docker registry(Amazon Elastic Container Registry之類的)，這樣一來watchtower也可以自動更新私有的image。

另外如果image有更新或取得新image有遇到問題時也可以透過notify的方式通知到Email、Slack、Teams或Gotify。

在這個docker化的世界中，能有自個docker自動更新的服務也真是方便，因為最近在開發go，規模也不需要到使用k8s，就會需要用到這樣的服務，某種程度上也算是自動化的CICD的一環。

今天就分享到這邊，謝謝大家。

這次我嘗試將 GitHub Copilot 作為主要協作工具，從分析專案、補齊文件、建立 Docker 開發環境，到排除執行時的錯誤，完整驗證 AI 在維護既有專案上的實際價值。

這篇文章將分享整個流程，以及我是如何一步一步完成以下工作：

• 分析既有專案架構與技術棧
• 自動整理並產生專案文件（README、Copilot Instructions）
• 建立 Docker 本機開發環境
• 解決登入帳號與密碼驗證問題
• 排查 PHP 版本相容性造成的畫面空白問題
• 完成修復並成功讓專案在本機正常運行

整個流程如下圖所示：

專案背景

本次使用的是一個既有 PHP Web 專案，最近剛好換電腦，有很多東西都重置了，所以就來試試。這個專案中並沒有完整的開發文件，並且也不是使用市面上常用的 framework，因此第一步便是透過閱讀程式碼來理解整體架構，包括：

• 專案目錄結構
• 路由與 Ajax 流程
• 資料庫存取方式
• 系統角色與權限
• 使用的技術棧

在完成分析後，再利用 Copilot 協助整理成完整的 README，讓後續維護者可以更快速進入狀況。

建立可重現的開發環境

為了避免不同開發者之間的環境差異，我將整個專案 Docker 化，建立包含：

• PHP + Apache
• MySQL
• 初始化資料庫
• VirtualHost 設定

只需要一個 docker compose up -d –build，即可快速重建完整開發環境，大幅降低新成員加入專案的成本。

AI 不只是寫程式，更能協助除錯

建置完成後並非一路順利。

首先遇到的是登入問題，由於資料庫中的密碼採用 bcrypt 雜湊，無法直接登入，因此透過 Docker 容器產生新的 bcrypt Password Hash，再建立測試帳號完成驗證。

接著又遇到最棘手的問題──首頁完全空白，但沒有任何錯誤訊息。

透過逐步確認資料庫、模擬 HTTP Request、分析 HTML 回傳內容，最後定位到問題出在 PHP 8.2 對 count(null) 的行為變更，導致舊版程式在渲染過程中直接中斷。

只需將：

!is_array($func_list) && count($func_list) == 0

修改為：

empty($func_list)

便成功解決相容性問題，整個網站也恢復正常運作。

總結

這次最大的收穫，不只是成功將舊專案搬到本機，更驗證了 GitHub Copilot 在維護既有專案上的價值 。

它不只是協助撰寫程式碼，更能在以下幾個面向提供明顯幫助：

• 快速理解陌生專案
• 自動補齊專案文件
• 建立標準化 Docker 環境
• 協助分析錯誤原因
• 提供修復建議並驗證結果

對於維護 Legacy System 而言，真正耗費時間的通常不是「寫功能」，而是「理解系統」與「找出問題」。透過 AI 的協助，許多原本需要數小時甚至數天的工作(ex: docker 建立、系統錯誤排查及建立相關文件)，都能在更短時間內(從天到小時)完成，讓開發者能將更多心力放在真正有價值的功能開發與系統優化上。

原本有點擔心沒有 framework 的專案會造成 AI 的混亂，最後發現我錯了，AI 使用的方案還比我之前的還更好。希望這篇文章能提供給正在接手舊專案、或準備導入 AI 協作開發的工程師一些參考與靈感。

在目前主要分幾個流程，如下：

0.建立 PRD 規範 (gemini GEM)、開好 github repo. & pages
1.桃園資料開放平台取資料
2.資料給 gemini 進行介面規劃及介面說明
3.需求及介面資料提供給 GEM 產生 PRD
4.PRD 資料提供給 copilot cli
5.本機介面測試
6.自動部屬至 github 及 pages

範例結果：https://ssssuuunnnn.github.io/Taoyuan_Housing_Transaction_Dashboard/

首先，先讓 gemini 產生介面相關設計及說明，一開始 gemini 給我的是用文字所畫出來的線稿跟說明。

+--------------------------------------------------------------------------------------------------+  
|  [Logo] 桃園市建物買賣不動產交易觀測儀表板                                       [最後更新: 115年1月]  |  
+--------------------------------------------------------------------------------------------------+  
|  【篩選條件】                                                                                      |  
|  年度：[ 全選 | v ]  月份：[ 全選 | v ]  行政區：[ 全選 (可複選)                       | v ]  [清除條件] |  
+--------------------------------------------------------------------------------------------------+  
|  【焦點指標 (KPI Cards)】                                                                         |  
|  +------------------------+  +------------------------+  +------------------------+              |  
|  | 最新月份交易總量 (115/1)|  | 本年度累計交易量 (115) |  | 當月交易量冠軍行政區   |              |  
|  |     3,656 棟           |  |     3,656 棟           |  |     桃園區 (639 棟)    |              |  
|  | ▲ +12.3% (按月比較)     |  | (統計至115年1月)        |  | 佔比：17.5%            |              |  
|  +------------------------+  +------------------------+  +------------------------+              |  
+--------------------------------------------------------------------------------------------------+  
|  【數據視覺化圖表區】                                                                             |  
|                                                                                                  |  
|  [圖表 A：歷月買賣棟數走勢圖 (折線圖 / 區域圖)]                                                       |  
|  棟數                                                                                            |  
|   |                                                                                              |  
|   |       /\        /\             /\                                                            |  
|   |  ____/  \______/  \___________/  \______                                                     |  
|   | /                                       \                                                    |  
|   +---------------------------------------------> 時間 (100年08月 ~ 115年01月)                   |  
|                                                                                                  |  
|  ----------------------------------------------------------------------------------------------  |  
|                                                                                                  |  
|  [圖表 B：各行政區交易量排行 (橫向柱狀圖)]         | [圖表 C：行政區交易佔比 (圓餅圖/環狀圖)]       |  
|  桃園區  [=======================] 639 棟        |               .------.                        |  
|  中壢區  [====================] 569 棟           |             /  桃園區  \                      |  
|  大園區  [=============] 517 棟                  |            |   17.5%    |                     |  
|  龜山區  [==========] 358 棟                     |             \          /                      |  
|  八德區  [==========] 355 棟                     |               '------'                        |  
|  ... (其餘行政區依序排列)                        |         (顯示所選期間各區份額)                |  
+--------------------------------------------------------------------------------------------------+  
|  【詳細數據清單】                                                         [搜尋行政區... ] [📥 匯出] |  
|  +------------+------------+----------------------+----------------------+                       |  
|  |  年度 (▼)  |  月份 ( )  |  行政區 ( )          |  買賣棟數 ( )        |                       |  
|  +------------+------------+----------------------+----------------------+                       |  
|  |  115       |  1         |  桃園區              |  639                 |                       |  
|  |  115       |  1         |  大溪區              |  45                  |                       |  
|  |  115       |  1         |  中壢區              |  569                 |                       |  
|  |  115       |  1         |  楊梅區              |  309                 |                       |  
|  |  114       |  12        |  桃園區              |  536                 |                       |  
|  +------------+------------+----------------------+----------------------+                       |  
|  | <  1  2  3  4  5  ...  46  > |                                         顯示 1-5 筆，共 2,258 筆 |  
+--------------------------------------------------------------------------------------------------+  
|  資料來源：桃園市政府開放資料庫 | 網頁免責聲明與隱私權政策                                         |  
+--------------------------------------------------------------------------------------------------+

對於文字所畫出來的線稿總感覺不夠具體，所以再次使用 nano banana 把線稿畫成圖檔，這樣看起來就具體多了。

第二，產生 PRD，在此之前己經有建立好 gemini GEM， 己經把相關規範跟內容都提供給了 GEM，所以再提供功能說明、介面的設計、串接資料、技術棧、git 位置…等等。接下來就是確認文件內容是否與想法有出入，再進行調整。

第三，將 PRD 提供給 copilot CLI

這部很簡單，直接執行即可，因為 copilot CLI 會直接依照 PRD 的內容進行開發，要做的就是等待，喝個咖啡。

最後，只需要確認內容及功能無誤，就可以讓 copilot CLI 幫你把程式碼都推上 git 並產生好網頁，結果如下。

這次比較完整的分享了，透過較符合軟體開發流程的方式，進行網頁的開發。發現到，思維改為 Agentic Engineering ，在整體都是可控的情況下去開發，把 AI 真正做為一個協作的角色，而不是採用憑感覺(Vibe)的方式進行開發。

未來軟體工程師只要確認介面及功能(API)的正確性即可，而在產生 PRD 的部分(把話說清楚)就會變的更加重要，但在工程師方面，也需要對相關技術有更多的學習跟了解才行。

以下為本次所產出的 PRD 資訊

https://docs.google.com/document/d/1rHpNj_5CLuMDC1fxHga4LsdV0SzAmBFQtk_So72nkPg/edit?usp=sharing

在三天端午三天的連假，就來讓上個月做的任務管理APP增加一些進度，這次增加的功能中，也是學習到一些新東西(對我來說)，這次增加的項目。

目前結果：https://ssssuuunnnn.github.io/matrix-todo/#matrix

1.基礎設定
— 建立 .github/copilot-instructions.md（記錄架構與開發慣例）
— 加入 Google Analytics

2.Firebase 跨裝置同步
— 新增 Google 登入（Firebase Auth）
— Firestore 即時同步，支援跨裝置資料共享
— 未登入維持 localStorage，首次登入自動遷移資料

3.手機 UI 優化

這次發現到原來gihub copilot有 copilot-instructions.md 的功能，其主要用途為讓開發者在專案中自訂 AI 的系統提示詞（System Prompts）與行為準則 。

簡單來說，它就像是給 Copilot 的「員工守則」，讓 AI 在幫你寫程式或回答問題時，能完全符合你或團隊的特定風格與規範。

核心功能與作用

當你在專案根目錄中加入這個檔案後，Copilot 在處理該專案的請求時會自動讀取它，並帶來以下改變：

• 統一程式碼風格 ：你可以規定變數命名法（如：必須使用 camelCase）、縮排（2 格或 4 格空白）、是否使用大括號等。
• 指定架構與設計模式 ：例如「在專案中一律使用 Repository Pattern」或「API 回傳格式必須符合特定 JSON 規範」。
• 限制使用的套件或語法 ：你可以叫 Copilot 禁用某些舊版 API，或強制使用特定的第三方函式庫（例如：一律使用 Axios 而非 fetch）。
• 調整回應語氣與語言 ：你可以要求 Copilot 一律用繁體中文回答，或者程式碼註解必須寫得非常詳細。

如何設定

設定非常簡單，只要在專案的根目錄（Root）或 .github/ 資料夾下，建立一個名為 copilot-instructions.md 的檔案即可。

內容

你可以根據專案需求自由修改，可以參考這次這個專案的內容：

https://github.com/ssssuuunnnn/matrix-todo/blob/main/.github/copilot-instructions.md

為什麼要用它？

1. 減少重複溝通 ：不用每次開啟新對話都跟 Copilot 說「請用 TypeScript 寫」、「請用繁體中文回答」。
2. 團隊程式碼一致性 ：當團隊所有人都 Pull 這個檔案後，每個人電腦上的 Copilot 都會遵循同一套規範，大幅降低 Code Review 的摩擦。
3. 新人快速銜接 ：新進工程師就算不熟悉團隊的程式默契，Copilot 也會主動引導他們寫出符合團隊規範的程式碼。

opilot-instructions.md 在多人或直接用AI開發專案時非常有用，可以把相關規範設定好，接下來不管是在 Vibe Coding 或是手寫程式讓AI建議時，都會參照這個檔案，這樣一來在開發時，就不會變成多種寫法。最大的幫助我認為是在Vibe Coding時，AI可以變成真正懂專案規矩的虛擬隊友，這樣在概有專案的維護上可以更加的順暢。

同時也順手查了一下，github 是否有提供其他的 .md 可使用，下面也大概分享：

CONTRIBUTING.md

• 當其他人準備在你的專案建立 Pull Request 或 Issue 時，GitHub 會在網頁上方自動顯示一條連結 ，提醒對方「請先閱讀貢獻指南」。這用來規範如何開分支、Commit 怎麼寫、測試怎麼跑。

README.md (special：個人檔案)

• 特殊功能 ：如果你建立一個與你 GitHub 帳號同名 的公開儲存庫（例如 github.com/your-username/your-username），並在裡面放 README.md，它就會轉化為你的個人首頁大看板（Profile README） ，支援動態統計圖表、WakaTime 狀態等多種小工具渲染。可以參考幾個厲害的開發者anuraghazra、thmsgbrt

另外還有一些 .md 屬於比較用在開源軟體的部分，這邊就不再另外介紹了，例如：CODE_OF_CONDUCT.md、SECURITY.md、SUPPORT.md

總之，這次 AI 又給許多我不知道的東西，不管是 .md 或是 firebase的功能，對於未來運用到團隊上，讓人獲益良多。

這次使用的AI服務為 copilot CLI。

最終目標預計將會做出Web+ APP，跨平台、多使用者的服務，讓整個系統可以上架提供服務。

用一個下午做出自己的任務管理 App，我學到了什麼

Photo by Volodymyr Dobrovolskyy on Unsplash

看完很多時間管理的文章，一直覺得市面上的 Todo App 不是太複雜就是太陽春，就想說乾脆自己做一個。剛好最近一直在推的艾森豪決策矩陣讓我很有感，就把兩件事合在一起，做了一個叫「今天該面對什麼」的 Web App，從需求到上線大概花了一個下午。

本次注重在產品設計與開發思路，技術細節（React、TypeScript 等）就不多介紹。

以下是這次從零打造一個工具產品，讓我重新思考的七件事：

1. 先寫 PRD，再動手（Write Before Code）先想清楚再說

很多人的習慣是「想到就做」，結果做到一半發現方向不對。這次我先把需求寫成一份完整的產品文件，定義清楚目標用戶是誰、核心功能是什麼、資料要存在哪裡。這個動作看似多了一道手續，但讓後面的每一步都快很多。需求越清楚，執行越快。

2. 四象限命名要「有人味」（Human-first Naming）不要讓工具讀起來像教科書

原本的象限名稱是「重要且緊急」、「重要但不緊急」，正確但無聊。後來改成「火燒屁股了！」、「有空一定要做」、「這誰的事啊？」、「晚點再點開」 — — 一眼就知道自己的任務屬於哪個情緒狀態。工具如果讓人感到有距離，再好用也沒人想碰。

3. 截止日期要有智慧（Smart Deadline）光顯示日期沒有意義

一般的日期欄位只告訴你「幾月幾號」，但我真正需要的資訊是「還有幾天」、「是不是快來不及了」。所以加了智慧提示，會自動顯示「🔔 快到期」、「⚠ 已逾期 N 天」，並讓卡片變色。資訊本身不值錢，讓人一眼看懂才值錢。

4. 三種瀏覽模式，因為人的狀態每天不一樣（Context-aware Views）

有時候需要看全局分佈（矩陣），有時候需要清單一項一項處理（清單），有時候需要跟日期對齊（日曆）。同樣的資料，在不同的時間點你需要的是不同的呈現方式。這也讓我想到，好的工具設計要跟著使用者的狀態走，而不是強迫使用者適應同一個畫面。

5. 資料存在本地就夠了（LocalStorage First）不要過度設計

一開始想說要不要接資料庫、做帳號系統，後來決定先用 LocalStorage 解決。結果發現對個人使用來說完全夠用，而且啟動速度快、不需要網路、沒有隱私問題。很多時候「過度設計」才是拖慢進度的主因，夠用就是好設計。

6. 從 PRD 到上線，一個下午（Ship Fast）完成比完美更重要

包含安裝環境、寫程式、推上 GitHub、設定 GitHub Pages 自動部署，總共花了不到半天。不是每件事都要做到百分百才能發出去，先讓真實的人用到真實的產品，比在腦袋裡反覆迭代更有價值。

7. AI 是協作對象，不是魔法棒（AI as Co-pilot）需求還是要自己想清楚

這次全程用 AI 協助開發，速度確實快很多。但 AI 能做好的前提是「你知道自己要什麼」。如果連需求都模糊，AI 給你的答案也會是模糊的。工具再強，思考還是要自己來。

結語

這次做下來最大的體悟是：好的工具應該讓你少想一件事，而不是多學一件功能。

對於身處各行各業的我們，其實核心道理是一樣的 — — 先搞清楚問題是什麼，再用最直接的方式解決它，然後快點讓別人用看看。

現在這個 App 已經上線了，如果你也常常不知道今天該做什麼，可以去試試看：👉 https://ssssuuunnnn.github.io/matrix-todo/

除了用 App，我也先去把「把這篇文章發出去」從「晚點再點開」象限，搬到「火燒屁股了！」象限了。

Photo by CardMapr.nl on Unsplash

以下是這份手冊中關於人才、執行與創意 的七大核心特質：

1. 識別並成為「A 級玩家」 (A-Players)

在 MrBeast 的公司裡，只有 A 級玩家 的容身之處。這類人才的特質是：極度執著、能從錯誤中學習、具備高度智慧、從不找藉口，並且對 YouTube 的價值有著深度的信仰 。相對地，Jimmy 認為平庸的「C 級玩家」對公司是有毒的，必須立即請其離職，以保護 A 級玩家的環境。

2. 絕對的「結果導向」 (Result-Oriented)

這是一家以結果論英雄的公司，投入的時數與工作量是無關緊要的 。Jimmy 強調，五個人工作一週卻解決不了的問題，若 A 級玩家能在 30 分鐘內搞定，那這 30 分鐘的價值遠勝於那一週的徒勞。公司評價員工的唯一標準就是：你是否達成結果並推動目標前進 。

3. 誠實重於禮貌 (Honesty Over Politeness)不要鄉愿

為了追求極致，團隊成員之間必須保持誠實而非客套的禮貌 。這意味著在討論專案時，直接「說出負面因素」(Say the Negatives) 比只說好聽話更有價值。如果一個場地預算超支或有潛在風險，負責人必須開誠布公，而不是為了維持和諧而隱瞞問題。

4. 創意節省資金 (Creativity Saves Money)才是提升ROI的方式

當面對預算壓力時，Jimmy 認為「創意才是答案」，而不是盲目撒錢。他舉例，與其直接給參賽者 2 萬美元現金，給予「一年份的多力多滋」可能更具喜劇效果且成本更低（約 1,825 美元），這能顯著提高投資報酬率 (ROI)。

5. 主動找出瓶頸 (Identify Bottlenecks)

在製作流程中，每個人都必須具備識別瓶頸 的能力。你不能只是把工作丟給別人就消失，而是要看著對方的眼睛，告訴他：「你是我的瓶頸」。負責人需要每日檢查進度 ，確保沒有任何環節停滯，並以「連上帝都無法阻止我準時完成影片」的決心執行任務。

6. 守護「關鍵組件」 (Critical Components)

所謂關鍵組件 ，是指那些「沒有它，影片就無法成立」的核心元素。例如，如果要送出一座島，那麼確保那座島的所有權就是關鍵組件。對於這類關鍵任務，絕對不能有「擲硬幣」(Coin Flip) 的僥倖心理，必須準備多重備案並投入 10 倍的關注度，隨時向老闆回報狀況。

7. 注意你的「 資訊攝取」 (Information Diet)

創作者的產出品質取決於其輸入的內容，這就是所謂的資訊飲食 。Jimmy 建議團隊應該大量吸收 YouTube 上的內容、迷因與文化趨勢，將大腦變成靈感的資料庫。你無法從你不知道存在的事物中獲得啟發，因此必須每天觀察世界在流行什麼，才能持續創新。

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

結語

這份手冊揭露了 MrBeast 帝國的根基：極度的當責文化與對內容的無限追求 。對於想要在內容創作領域取得成功的人來說，是一套關於如何在高速競爭的數位時代中脫穎而出的生存法則。

本篇最重要的是，請記住 Jimmy 的叮囑：「別找藉口，拿出結果，並且永遠保持對 YouTube 的信仰。」

對於身於其他產業的我們，也可以用相同的核心理念進行發展，持續對有興趣的領域浸泡在其中，對團隊有問題的洞查並解決，這才能建立優秀的團隊。

除了看YouTube，我先去吃看看MrBeast的巧克力了。

資料來源：https://drive.google.com/file/d/1YaG9xpu-WQKBPUi8yQ4HaDYQLUSa7Y3J/view

最近在看YT 小林對Duolingo的CEO Luis von Ahn 的訪談，其中有講到Duolingo對於產品的一些發展原則，透過員工手冊的方式，讓同仁可以有共同的理念跟做法。

1.手冊中有五大原則(The Five Principles)，其中大概內容如下：

目光長遠 (Take the Long View)：致力於打造一個「永遠」的產品，優先考慮用戶的長期留存而非短期收益。例如：為了不干擾用戶學習體驗，他們會嚴格限制廣告數量和通知頻率。

提高標準 (Raise the Bar)：追求卓越是基本要求，每項功能都必須直觀、有趣、有用且精緻。公司強調「對事不對人」的坦誠反饋，並堅持每天「試用自家產品」(dogfooding) 以發現問題。

快速執行 (Ship It)：強調以極快的速度進行實驗與迭代。透過真實世界的數據反饋來引導決策，而不是無止盡的內部討論。 ​

以行動證明 (Show Don’t Tell)：優先展現成果而非講述過程。溝通時使用簡潔的摘要，並以數據和原型 (Prototypes) 作為決策依據，而非個人意見或簡報。

寓教於樂 (Make It Fun)：產品建立在「玩樂」的基礎上，利用遊戲化機制讓學習變得有趣。其品牌形象既健康又帶點「瘋狂」，例如其標誌性角色 Duo 的有趣形象。

2. 獨特的企業文化

​綠色機器 (The Green Machine)：這是 Duolingo 構建事物的方法論，包含：招募優秀人才、定義成功指標、設定長期護欄、建立反饋循環、高效執行，並根據結果決定是否繼續投入。

招聘哲學：公司在招募時非常看重人才的卓越性與品格。他們有一句名言：「寧缺勿濫」(Better a hole than an a**hole)，即使是高階主管，如果缺乏善意也會被拒絕。 ​

怪咖與創新：手冊提到 Duolingo 是一個「古怪的地方」，鼓勵提出大膽且看似荒謬的問題（例如「99 個壞點子」傳統），以此激發創新。

3. 產品與商業策略

​Juicy 設計語言：這是一種色彩鮮艷、圓潤且友好的設計風格，旨在讓學習體驗更像玩遊戲。
​盈利與使命的平衡：雖然引入了廣告和訂閱服務，但堅持「學習內容絕不設收費牆」，以確保教育的普及性。

建立標準：目標是讓「Duolingo 分數」和「Duolingo 英語測試 (DET)」成為全球語言能力的衡量標準。

以上內容，可以讓大家知道Duolingo是如何發展到目前的程度，對於這樣的方式，可以供產品經理參考。

身為一位己經連勝900天的使用者，才知道Duolingo在平台的發展上有這些宗旨。以公司的角度，如果可以提供準則，透過這個方式也可以讓員工可以有一致的想法及做法，這樣對於員工不會發展，造成產品發展混亂，這很值得參考。

資料來源：https://blog.duolingo.com/handbook/
​

當專案即將上線的通知發出，心中總會湧現一股複雜的情緒。這不僅是為了完成任務的成就感，更是對這段跌跌撞撞旅程的回顧與反思。這個專案能如預期地在時程內上線，並非偶然，而是在每個細節上勤勞踏實的結果。回首這段經歷，我深刻體會到，一個如質如期的專案，靠的是每個環節的精準掌握，別無他法。

在專案執行的過程中，我面臨了許多前所未有的挑戰。跨部門的需求確認、部門間的溝通協調、有限的人力安排、與外部廠商的緊密協作，以及時程的安排與掌控，每一項都讓我感到巨大的壓力。特別是在專案人員的休假管理、開發部門對需求理解的一致性，以及需求方的需求管理上，這些都是我過去未曾面對的課題。這次的經驗讓我明白，這些看似簡單的環節，實則充滿了變數，需要專案經理花費大量的時間與心力去克服。

透過這些挑戰，我學到了寶貴的經驗。我意識到專案經理的工作並非靠著華麗的技巧或特殊的管理模式，而是回歸到最基本、最紮實的層面：對每個階段執行內容的確實掌握（例如：每日的整體進度會議）、確保資訊傳遞的清晰與即時(各階段的資訊佈達及人員間觀念的同步)、面對危機時的果斷反應，以及確認每個項目都能確實完成。這說起來容易，但要真正實踐，需要極大的耐心與毅力。然而，這正是專案經理的價值所在，也是我們需要不斷精進的課題。

我深知，專案經理這個職位，在團隊中往往是一個不討人喜歡的角色。我們必須不斷地催促、要求、甚至在某些時刻扮演「壞人」的角色，以確保專案能按時程推進。但為了實現專案的最終目標 — — 如質如期，這種犧牲是必要的。如何讓團隊成員理解這種「必要之惡」，並看到背後為了專案成功所做的努力，也是我未來需要學習的地方。

這次的專案經驗，讓我對專案管理有了更深的體悟。一個成功的專案，沒有捷徑，只有勤奮與堅持。透過這次的實戰，我不僅提升了管理能力，也學會了如何應對複雜的人際關係與突發狀況。我會將這些寶貴的經驗應用在未來的專案中，繼續努力，讓每一個專案都能成功上線。因為一個失敗的專案，沒有人會在意中間做得多漂亮，失敗就是失敗，所以成功才是唯一的準則。