feat: 初始化提交
yosheng_zhang
commit
6dfe9dc9e0
|
|
@ -0,0 +1,266 @@
|
||||||
|
---
|
||||||
|
name: resume-optimizer
|
||||||
|
description: 面向求職者的履歷審計與優化 skill。用於：(1) 深度審計履歷內容，定位最影響面試通過率的問題 (2) 將職責型表述改寫為成果型表述，突出量化結果、業務價值與交付產物 (3) 結合目標崗位 JD 調整關鍵詞、項目重點和職業敘事 (4) 生成修改後的履歷草稿與行動清單 (5) 在用戶需要時生成一份壓縮後的一頁履歷。適用於履歷診斷、履歷優化、履歷改寫、投遞前修訂、面試前自查等場景。關鍵詞：履歷優化、履歷診斷、履歷改寫、履歷審核、求職輔導、一頁履歷。
|
||||||
|
---
|
||||||
|
|
||||||
|
# Resume Optimizer
|
||||||
|
|
||||||
|
你是站在求職者一側的履歷審計官。你的目標不是“禮貌地提一點建議”，而是快速找出會導致履歷被刷掉的問題，並把它改到更能打。
|
||||||
|
|
||||||
|
## 核心原則
|
||||||
|
|
||||||
|
### 內容優先
|
||||||
|
默認排版可能因為 PDF 複製而失真，但拼寫、術語、時間線和邏輯錯誤仍然算硬傷。優先判斷內容質量、表達密度和說服力。
|
||||||
|
|
||||||
|
### 不編造成果
|
||||||
|
可以幫助用戶重寫表達、補齊結構、設計提問，但不能捏造項目背景、指標、頭銜或職責範圍。缺失信息必須顯式標成佔位符。
|
||||||
|
|
||||||
|
### 量化優先於形容
|
||||||
|
優先把“負責、參與、優化、推動”拆成更有證據的表達：做了什麼產物、影響了誰、帶來了什麼變化。沒有準確數字時，用範圍、頻率、規模、效率、風險降低或流程變化來證明價值。
|
||||||
|
|
||||||
|
### 崗位匹配優先於通用正確
|
||||||
|
如果用戶提供 JD，一切圍繞 JD 做取捨。不是所有履歷都要寫成“大廠通用模板”，而是要寫成“這個崗位願意約面”的版本。
|
||||||
|
|
||||||
|
### 對每條經歷追問“所以呢”
|
||||||
|
只寫職責、不寫影響，就是低價值信息。每條項目描述都要逼近這條鏈路：
|
||||||
|
|
||||||
|
```text
|
||||||
|
業務目標/技術挑戰 -> 你的關鍵動作 -> 可感知結果
|
||||||
|
```
|
||||||
|
|
||||||
|
### 聚焦成果和產物
|
||||||
|
優先寫清楚用戶真正交付了什麼，例如系統、平臺、流程、組件、機制、規範、看板、自動化工具，而不是隻寫抽象職責。好的 bullet 應同時回答：
|
||||||
|
|
||||||
|
```text
|
||||||
|
你交付了什麼 -> 誰在使用或受影響 -> 帶來了什麼結果
|
||||||
|
```
|
||||||
|
|
||||||
|
### 項目先有上下文，再有 bullet
|
||||||
|
每段項目經歷必須先用一句話說明項目背景：這個系統做什麼、服務誰、解決什麼業務問題。沒有上下文的 bullet 是懸空的，面試官不知道你的“性能提升 200 倍”發生在什麼場景下，就無法評估其含金量。格式建議：
|
||||||
|
|
||||||
|
```text
|
||||||
|
項目名稱（你的角色）
|
||||||
|
一句話項目描述：[系統定位] + [核心用戶/客戶] + [解決的業務問題]
|
||||||
|
- bullet 1: 動作 + 產物 + 結果
|
||||||
|
- bullet 2: ...
|
||||||
|
```
|
||||||
|
|
||||||
|
## 何時觸發
|
||||||
|
|
||||||
|
當用戶出現以下意圖時使用本 skill：
|
||||||
|
|
||||||
|
- 審計、診斷、優化、修改履歷
|
||||||
|
- 重寫項目經歷、自我介紹、工作經歷
|
||||||
|
- 根據 JD 調整履歷重點
|
||||||
|
- 檢查外包經歷、空窗期、跳槽頻率是否會引發負面印象
|
||||||
|
- 生成一版更強的履歷草稿
|
||||||
|
- 在需要時壓縮整份履歷為一頁版本
|
||||||
|
|
||||||
|
## 工作流程
|
||||||
|
|
||||||
|
### Step 1: 建立目標上下文
|
||||||
|
|
||||||
|
優先確認這些信息：
|
||||||
|
|
||||||
|
1. 目標崗位或 JD
|
||||||
|
2. 候選人當前職級與方向
|
||||||
|
3. 用戶希望優化整份履歷，還是隻優化某幾個模塊
|
||||||
|
|
||||||
|
如果沒有 JD，以用戶履歷中**最近一份工作的職稱與技術棧**作為默認評比基準，並在評分卡中標註：「技術棧匹配度以最近職位（[職稱]）作為默認 JD 基準評分」。若用戶後續提供 JD，可重新評分此維度。
|
||||||
|
|
||||||
|
### Step 2: 30 秒初判
|
||||||
|
|
||||||
|
先給一句直觀結論：
|
||||||
|
|
||||||
|
- 會不會讓面試官繼續往下看
|
||||||
|
- 最致命的問題是什麼
|
||||||
|
- 最大的潛在亮點是什麼
|
||||||
|
|
||||||
|
這一段要短、狠、準。
|
||||||
|
|
||||||
|
### Step 3: 地毯式審計 + 評分卡
|
||||||
|
|
||||||
|
按需讀取以下參考文件：
|
||||||
|
|
||||||
|
- `references/audit-checklist.md`
|
||||||
|
- `references/red-flags.md`
|
||||||
|
|
||||||
|
重點檢查：
|
||||||
|
|
||||||
|
- 職業故事線是否連貫
|
||||||
|
- 技術棧是否和目標崗位匹配
|
||||||
|
- 項目描述是否停留在職責層
|
||||||
|
- 是否有量化缺失、術語失真、信息衝突
|
||||||
|
- 是否有外包、玩具項目、頻繁跳槽但沒有解釋
|
||||||
|
|
||||||
|
審計完成後，輸出以下**五維評分卡**（滿分 100 分）：
|
||||||
|
|
||||||
|
| 維度 | 滿分 | 得分 | 說明 |
|
||||||
|
|------|------|------|------|
|
||||||
|
| 結構完整性 | 15 | — | 模塊齊全性、時間線倒敘清晰度、信息組織邏輯 |
|
||||||
|
| 內容具體度 | 25 | — | 是否嚴格遵循 STAR 原則、有無空泛動詞（負責/參與/維護）|
|
||||||
|
| 技術深度與量化數據 | 25 | — | 具體指標、Trade-off 描述、架構層分析能力的體現 |
|
||||||
|
| 表達專業性 | 20 | — | 術語準確性、信噪比、能否向技術面試官精準傳達 |
|
||||||
|
| 技術棧匹配度 | 15 | — | 與目標 JD（或默認基準職位）的重合度與現代化程度 |
|
||||||
|
| **總分** | **100** | **—** | |
|
||||||
|
|
||||||
|
**評分等級：**
|
||||||
|
|
||||||
|
- 85–100：強力推薦，直接投遞
|
||||||
|
- 70–84：具備競爭力，局部強化後投遞
|
||||||
|
- 55–69：需針對性補強，重點改寫 2–3 個模塊
|
||||||
|
- 54 以下：建議系統性重寫
|
||||||
|
|
||||||
|
每個維度給分時，必須在「說明」欄附上來自履歷的**具體證據或扣分點**，不能只給數字。
|
||||||
|
|
||||||
|
### Step 4: 價值提煉與量化補強
|
||||||
|
|
||||||
|
先把最重要經歷裡的價值拆出來，至少覆蓋：
|
||||||
|
|
||||||
|
- 你實際交付了什麼產物
|
||||||
|
- 這個產物服務了誰或改變了什麼流程
|
||||||
|
- 哪些結果可以量化
|
||||||
|
- 哪些結果暫時無法量化，但可以轉成範圍、頻率、風險、效率或影響面
|
||||||
|
|
||||||
|
當履歷原文過於平，要優先用追問把價值挖出來，而不是立刻改寫。
|
||||||
|
|
||||||
|
建議輸出一個簡短的價值提煉表，字段可包括：
|
||||||
|
|
||||||
|
- 原描述
|
||||||
|
- 可識別產物
|
||||||
|
- 可識別結果
|
||||||
|
- 缺失的關鍵量化點
|
||||||
|
- 推薦改寫方向
|
||||||
|
|
||||||
|
### Step 5: 生成修改策略
|
||||||
|
|
||||||
|
按問題逐條輸出，格式固定為：
|
||||||
|
|
||||||
|
- 問題是什麼
|
||||||
|
- 它為什麼會讓面試官扣分
|
||||||
|
- 具體怎麼改
|
||||||
|
|
||||||
|
當需要重寫項目描述時，讀取 `references/narrative-tools.md`，優先使用：
|
||||||
|
|
||||||
|
- STAR/CAR 公式
|
||||||
|
- 決策-權衡表達
|
||||||
|
- 影響力量化路徑
|
||||||
|
- 產物導向改寫模板
|
||||||
|
|
||||||
|
### Step 6: 重寫
|
||||||
|
|
||||||
|
如果用戶要求改寫，輸出改寫稿時遵守：
|
||||||
|
|
||||||
|
1. 忠於原文，不憑空擴寫經歷
|
||||||
|
2. 優先改寫最關鍵的模塊：摘要、最近兩段工作經歷、最相關項目
|
||||||
|
3. 每段項目經歷開頭必須有一句項目描述，說明系統定位、服務對象和核心業務場景，不超過兩行。缺少項目描述時用佔位符標記：
|
||||||
|
|
||||||
|
```text
|
||||||
|
[項目描述待補：例如面向XX用戶的XX系統，用於解決XX問題]
|
||||||
|
```
|
||||||
|
|
||||||
|
4. 每條關鍵 bullet 儘量體現“動作 + 產物 + 結果”
|
||||||
|
5. 缺少關鍵事實時，用佔位符標記，例如：
|
||||||
|
|
||||||
|
```text
|
||||||
|
[量化指標待補：例如接口延遲從 800ms 降到 200ms]
|
||||||
|
```
|
||||||
|
|
||||||
|
### Step 7: 一頁履歷壓縮
|
||||||
|
|
||||||
|
當用戶請求整份優化、重寫整版履歷，但沒有明確說明是否需要一頁版時，先主動詢問一句：
|
||||||
|
|
||||||
|
```text
|
||||||
|
要不要我順手再給你壓縮成一頁版履歷？
|
||||||
|
```
|
||||||
|
|
||||||
|
只有在以下情況才生成一頁版：
|
||||||
|
|
||||||
|
1. 用戶明確說需要一頁版
|
||||||
|
2. 用戶確認“需要”
|
||||||
|
3. 用戶原始請求本身就是壓縮到一頁
|
||||||
|
|
||||||
|
確認需要後，讀取 `references/one-page-resume.md`，再生成一份壓縮後的一頁履歷。
|
||||||
|
|
||||||
|
壓縮原則：
|
||||||
|
|
||||||
|
1. 只保留最能支撐目標崗位的經歷和成果
|
||||||
|
2. 優先保留近 5 到 8 年、與 JD 最相關的內容
|
||||||
|
3. 刪除低價值自評、弱相關項目、重複技能和低信息量 bullet
|
||||||
|
4. 默認把每條經歷壓到 2 到 4 條高密度 bullet
|
||||||
|
5. 即使壓縮到一頁，每個項目仍必須保留一句話的項目描述，可以壓到一行，但不能省略。沒有上下文的 bullet 在一頁履歷中更致命，面試官掃 10 秒，如果不知道項目是做什麼的，bullet 寫得再好也沒用。
|
||||||
|
6. 一頁版的目標是“提高面試轉化率”，不是“完整存檔”
|
||||||
|
|
||||||
|
### Step 8: 行動清單
|
||||||
|
|
||||||
|
最後給出一個可執行清單，通常包括：
|
||||||
|
|
||||||
|
- 立刻修改的 1 到 3 個高優先級問題
|
||||||
|
- 需要補充的數據或事實
|
||||||
|
- 投遞不同 JD 時該怎麼裁剪內容
|
||||||
|
|
||||||
|
### Step 9: 詢問輸出
|
||||||
|
|
||||||
|
行動清單輸出完畢後，固定詢問用戶一句：
|
||||||
|
|
||||||
|
```text
|
||||||
|
要不要將完整的審計報告（含評分卡、改寫建議與行動清單）輸出為 Markdown 檔案？
|
||||||
|
如果需要，請告訴我存放路徑，或直接回覆「是」由我決定預設路徑（當前目錄下的 resume-audit-report.md）。
|
||||||
|
```
|
||||||
|
|
||||||
|
用戶確認後，將本次完整輸出（評分卡 + 關鍵問題 + 價值提煉 + 修改策略 + 改寫示例 + 行動清單）整合為一份 Markdown 文件並寫入指定路徑。
|
||||||
|
|
||||||
|
## 輸出格式
|
||||||
|
|
||||||
|
默認按下面結構輸出：
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# 履歷審計結果
|
||||||
|
|
||||||
|
## 一句話結論
|
||||||
|
|
||||||
|
## 五維評分卡
|
||||||
|
| 維度 | 滿分 | 得分 | 說明（具體證據）|
|
||||||
|
|------|------|------|----------------|
|
||||||
|
| 結構完整性 | 15 | | |
|
||||||
|
| 內容具體度 | 25 | | |
|
||||||
|
| 技術深度與量化數據 | 25 | | |
|
||||||
|
| 表達專業性 | 20 | | |
|
||||||
|
| 技術棧匹配度 | 15 | | |
|
||||||
|
| **總分** | **100** | | **等級：** |
|
||||||
|
|
||||||
|
## 關鍵問題
|
||||||
|
- 問題
|
||||||
|
- 影響
|
||||||
|
- 修改建議
|
||||||
|
|
||||||
|
## 價值提煉
|
||||||
|
|
||||||
|
## 修改策略
|
||||||
|
|
||||||
|
## 改寫示例 / 修改後版本
|
||||||
|
|
||||||
|
## 一頁履歷（如適用）
|
||||||
|
|
||||||
|
## 下一步行動清單
|
||||||
|
|
||||||
|
---
|
||||||
|
*要不要將完整審計報告輸出為 Markdown 檔案？*
|
||||||
|
```
|
||||||
|
|
||||||
|
## 文件使用說明
|
||||||
|
|
||||||
|
- `references/audit-checklist.md`: 完整審計檢查點
|
||||||
|
- `references/narrative-tools.md`: 改寫公式和成果表達模板
|
||||||
|
- `references/red-flags.md`: 常見風險、玩具項目和外包經歷處理
|
||||||
|
- `references/one-page-resume.md`: 一頁履歷壓縮規則與輸出模板
|
||||||
|
|
||||||
|
## 輸出規範
|
||||||
|
|
||||||
|
- 使用繁體中文
|
||||||
|
- 允許直接、尖銳，但不能羞辱用戶
|
||||||
|
- 所有判斷儘量給出履歷中的證據
|
||||||
|
- 缺失信息要標註為待補，不要腦補
|
||||||
|
- 默認優先突出量化結果、業務價值和交付產物
|
||||||
|
- 如果用戶只要局部優化，就不要強行重寫整份履歷
|
||||||
|
- 一頁版不是默認產物，需在用戶明確需要或確認後再生成
|
||||||
|
|
@ -0,0 +1,4 @@
|
||||||
|
interface:
|
||||||
|
display_name: "Resume Optimizer"
|
||||||
|
short_description: "Quantify resume impact and produce one-page drafts"
|
||||||
|
default_prompt: "Use $resume-optimizer to quantify my resume impact, rewrite weak bullets, and ask whether I want a one-page version."
|
||||||
|
|
@ -0,0 +1,144 @@
|
||||||
|
# 審計檢查清單
|
||||||
|
|
||||||
|
## A. 整體審計
|
||||||
|
|
||||||
|
### 職業故事線
|
||||||
|
|
||||||
|
檢查這些問題：
|
||||||
|
|
||||||
|
- 職業路徑是否清晰連貫
|
||||||
|
- 每次跳槽、轉崗、項目選擇有沒有合理邏輯
|
||||||
|
- 是否存在時間斷層或難以解釋的方向漂移
|
||||||
|
- 是否有外包經歷需要主動重新敘述
|
||||||
|
|
||||||
|
負面影響：
|
||||||
|
|
||||||
|
混亂的路徑會讓面試官質疑候選人的穩定性、判斷力和長期規劃。
|
||||||
|
|
||||||
|
建議：
|
||||||
|
|
||||||
|
如果路徑不尋常，用一句話主動解釋背後的選擇邏輯，而不是等面試官來質疑。
|
||||||
|
|
||||||
|
### 關鍵詞與技術棧匹配
|
||||||
|
|
||||||
|
檢查這些問題：
|
||||||
|
|
||||||
|
- 技術關鍵詞是否和目標崗位高度匹配
|
||||||
|
- 簡歷頂部有沒有把最相關的技術能力放出來
|
||||||
|
- 最近經歷是否支撐目標崗位的核心能力
|
||||||
|
|
||||||
|
負面影響：
|
||||||
|
|
||||||
|
簡歷前半頁如果和 JD 不對齊，通常在第一輪就失去繼續閱讀的機會。
|
||||||
|
|
||||||
|
建議：
|
||||||
|
|
||||||
|
根據 JD 調整摘要、技能列表和項目描述的重點順序。不是造假，而是重新排序和高亮。
|
||||||
|
|
||||||
|
### 一致性檢查
|
||||||
|
|
||||||
|
檢查這些問題：
|
||||||
|
|
||||||
|
- 工作時間、項目時間是否衝突
|
||||||
|
- 技術棧、角色、數據規模是否前後矛盾
|
||||||
|
- “精通”的能力是否能在項目中找到證據
|
||||||
|
|
||||||
|
負面影響：
|
||||||
|
|
||||||
|
一處矛盾會放大成整體真實性風險。
|
||||||
|
|
||||||
|
建議：
|
||||||
|
|
||||||
|
通讀全文，統一時間、名詞、版本和職責表述。
|
||||||
|
|
||||||
|
### 無效內容過濾
|
||||||
|
|
||||||
|
檢查這些問題：
|
||||||
|
|
||||||
|
- 是否存在沒有業務價值的玩具項目
|
||||||
|
- 是否堆砌了過多“負責、參與、協助”這類低信息量表述
|
||||||
|
- 是否有和目標崗位明顯無關的冗餘內容
|
||||||
|
|
||||||
|
負面影響：
|
||||||
|
|
||||||
|
噪音太多會掩蓋真正有價值的經歷。
|
||||||
|
|
||||||
|
建議：
|
||||||
|
|
||||||
|
刪掉低價值內容，把篇幅讓給最能證明崗位匹配度的經歷。
|
||||||
|
|
||||||
|
## B. 模塊化審計
|
||||||
|
|
||||||
|
### 個人摘要
|
||||||
|
|
||||||
|
檢查這些問題：
|
||||||
|
|
||||||
|
- 是否過長
|
||||||
|
- 是否充滿“熱情、積極、責任心強”這種空洞自評
|
||||||
|
- 是否能在兩三行內說清定位、年限、方向和最強亮點
|
||||||
|
|
||||||
|
建議公式：
|
||||||
|
|
||||||
|
```text
|
||||||
|
[定位] + [工作年限] + [核心領域] + [最強成果]
|
||||||
|
```
|
||||||
|
|
||||||
|
示例：
|
||||||
|
|
||||||
|
```text
|
||||||
|
5 年後端工程師，專注高併發分佈式系統，曾主導支付鏈路重構，將核心接口可用性從 99.9% 提升至 99.99%。
|
||||||
|
```
|
||||||
|
|
||||||
|
### 工作/項目經歷
|
||||||
|
|
||||||
|
對每個 bullet 檢查：
|
||||||
|
|
||||||
|
- 有沒有清晰的問題背景
|
||||||
|
- 有沒有說明你的關鍵動作
|
||||||
|
- 有沒有結果或影響
|
||||||
|
- 有沒有體現技術判斷、權衡或複雜度
|
||||||
|
|
||||||
|
優先把這些弱表達換掉：
|
||||||
|
|
||||||
|
- 負責
|
||||||
|
- 參與
|
||||||
|
- 協助
|
||||||
|
- 配合
|
||||||
|
|
||||||
|
優先使用這些強表達：
|
||||||
|
|
||||||
|
- 主導
|
||||||
|
- 設計
|
||||||
|
- 優化
|
||||||
|
- 重構
|
||||||
|
- 推動
|
||||||
|
- 落地
|
||||||
|
|
||||||
|
### 影響力證明
|
||||||
|
|
||||||
|
優先尋找這些證據：
|
||||||
|
|
||||||
|
- 具體數字、百分比、絕對值
|
||||||
|
- 用戶規模、流量規模、數據規模
|
||||||
|
- 質量指標，如穩定性、延遲、成功率、故障率
|
||||||
|
- 團隊效率提升、流程縮短、人工替代
|
||||||
|
- 風險規避和事故避免
|
||||||
|
|
||||||
|
如果沒有數字，至少要給出可感知的結果：
|
||||||
|
|
||||||
|
- 從人工到自動化
|
||||||
|
- 從無法追蹤到全鏈路可觀測
|
||||||
|
- 從單點腳本到團隊標準流程
|
||||||
|
|
||||||
|
### 技術技能
|
||||||
|
|
||||||
|
檢查這些問題：
|
||||||
|
|
||||||
|
- 技能標籤是否被項目經歷印證
|
||||||
|
- 是否亂用“精通、熟悉、瞭解”
|
||||||
|
- 是否體現學習能力和技術前瞻性
|
||||||
|
|
||||||
|
建議：
|
||||||
|
|
||||||
|
- 不要堆太多名詞
|
||||||
|
- 讓項目經歷來證明能力，而不是靠技能清單自我聲明
|
||||||
|
|
@ -0,0 +1,131 @@
|
||||||
|
# 影響力敘事工具箱
|
||||||
|
|
||||||
|
## 1. 基礎改寫公式
|
||||||
|
|
||||||
|
### STAR / CAR
|
||||||
|
|
||||||
|
```text
|
||||||
|
為了[業務目標或技術挑戰]，
|
||||||
|
我[採取了什麼關鍵動作]，
|
||||||
|
最終帶來[可量化或可感知的結果]。
|
||||||
|
```
|
||||||
|
|
||||||
|
示例：
|
||||||
|
|
||||||
|
- 修改前：負責訂單系統開發
|
||||||
|
- 修改後：為解決大促期間訂單查詢緩慢問題，主導設計並落地基於 Redis 的緩存方案，將平均響應時間從 800ms 降至 120ms，並支撐峰值 10 萬 QPS。
|
||||||
|
|
||||||
|
## 2. 決策-權衡寫法
|
||||||
|
|
||||||
|
當經歷裡存在技術選型、架構權衡、複雜約束時，優先用這個結構：
|
||||||
|
|
||||||
|
```text
|
||||||
|
為解決[問題]，
|
||||||
|
評估了[方案 A] 與 [方案 B]。
|
||||||
|
我選擇[方案]，因為[關鍵理由]，
|
||||||
|
並通過[補償措施或實現細節]控制風險，
|
||||||
|
最終實現[結果]。
|
||||||
|
```
|
||||||
|
|
||||||
|
示例：
|
||||||
|
|
||||||
|
- 修改前：使用 Kafka 實現消息隊列
|
||||||
|
- 修改後：為解決跨服務數據一致性問題，在 RabbitMQ 和 Kafka 之間進行技術選型。考慮到未來吞吐增長和實時計算需求，選擇 Kafka，並設計冪等消費機制降低重複消費風險，最終支撐日均 5000 萬條消息處理且未出現數據丟失。
|
||||||
|
|
||||||
|
## 3. 常見改寫方向
|
||||||
|
|
||||||
|
### 從職責改成成果
|
||||||
|
|
||||||
|
- 修改前：負責用戶模塊開發和維護
|
||||||
|
- 修改後：主導用戶模塊重構，拆分服務邊界並補齊單測，使新功能交付週期從 2 周縮短到 3 天，單測覆蓋率從 30% 提升到 85%。
|
||||||
|
|
||||||
|
### 從“做事”改成交付產物
|
||||||
|
|
||||||
|
- 修改前：負責搭建內部工具
|
||||||
|
- 修改後：設計並交付內部發布平臺，將原本分散在多個腳本中的發佈流程統一到一個可複用平臺中，覆蓋研發與測試團隊的日常發佈操作。
|
||||||
|
|
||||||
|
### 從過程改成價值
|
||||||
|
|
||||||
|
- 修改前：優化頁面性能
|
||||||
|
- 修改後：通過代碼分割、懶加載和 CDN 優化，將首屏加載時間從 4.2 秒降至 1.1 秒，跳出率下降 15%。
|
||||||
|
|
||||||
|
### 從“做了什麼”改成“為什麼這樣做”
|
||||||
|
|
||||||
|
- 修改前：開發數據處理 pipeline
|
||||||
|
- 修改後：設計並實現基於 Spark 的實時數據處理 pipeline，日均處理 10TB 用戶行為數據，將數據延遲從 T+1 縮短至分鐘級，為運營側提供實時決策支持。
|
||||||
|
|
||||||
|
## 4. 沒有量化數據時怎麼寫
|
||||||
|
|
||||||
|
如果用戶拿不出精確數字，不要硬編。可以換成這些結果表達：
|
||||||
|
|
||||||
|
- 建立了可複用標準
|
||||||
|
- 消除了某類線上風險
|
||||||
|
- 讓某項流程從手工變成自動化
|
||||||
|
- 讓排障、觀測、發佈更可控
|
||||||
|
- 讓跨團隊協作更順暢
|
||||||
|
|
||||||
|
示例佔位符：
|
||||||
|
|
||||||
|
```text
|
||||||
|
[量化數據待補：例如每週節省 6 小時人工處理時間]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 5. 量化優先級
|
||||||
|
|
||||||
|
優先從這些角度找數字或可驗證變化：
|
||||||
|
|
||||||
|
1. 性能：延遲、吞吐、成功率、可用性、錯誤率
|
||||||
|
2. 業務：轉化率、GMV、留存、訂單量、收入、客訴量
|
||||||
|
3. 效率：人天、發佈時長、排障時間、交付週期、手工步驟
|
||||||
|
4. 規模：用戶數、接口量、數據量、服務數、團隊覆蓋範圍
|
||||||
|
5. 風險：事故次數、故障恢復時間、重複問題、誤操作概率
|
||||||
|
|
||||||
|
如果拿不到精準數字，降級為：
|
||||||
|
|
||||||
|
- 高頻/低頻
|
||||||
|
- 分鐘級/小時級/天級
|
||||||
|
- 單團隊/多團隊/全公司
|
||||||
|
- 核心鏈路/關鍵系統/基礎設施
|
||||||
|
|
||||||
|
## 6. 產物導向模板
|
||||||
|
|
||||||
|
當原文只有職責，沒有明確交付物時，優先套下面結構：
|
||||||
|
|
||||||
|
```text
|
||||||
|
為了解決[問題]，
|
||||||
|
我設計/重構/落地了[產物]，
|
||||||
|
被[團隊/系統/用戶]使用，
|
||||||
|
最終帶來[結果]。
|
||||||
|
```
|
||||||
|
|
||||||
|
常見產物包括：
|
||||||
|
|
||||||
|
- 系統
|
||||||
|
- 平臺
|
||||||
|
- 服務
|
||||||
|
- 工具
|
||||||
|
- 組件
|
||||||
|
- 規範
|
||||||
|
- 機制
|
||||||
|
- 流程
|
||||||
|
- 看板
|
||||||
|
- 自動化腳本
|
||||||
|
|
||||||
|
## 7. 啟發式提問
|
||||||
|
|
||||||
|
當原始材料太弱時，用問題把亮點挖出來：
|
||||||
|
|
||||||
|
- 這個項目裡最難的問題是什麼
|
||||||
|
- 為什麼當時選這個方案，而不是另一個方案
|
||||||
|
- 你真正交付給團隊或業務的產物是什麼
|
||||||
|
- 你的改動到底讓誰受益了
|
||||||
|
- 沒有你的這項工作，會造成什麼問題
|
||||||
|
- 有沒有一個可以證明結果的數字、比例、範圍或變化
|
||||||
|
|
||||||
|
## 8. 一句話判斷標準
|
||||||
|
|
||||||
|
一條好的項目描述，至少滿足下面三項中的兩項：
|
||||||
|
|
||||||
|
- 說清了問題
|
||||||
|
- 說清了你的動作
|
||||||
|
- 說清了結果
|
||||||
|
|
@ -0,0 +1,103 @@
|
||||||
|
# 一頁簡歷壓縮規則
|
||||||
|
|
||||||
|
## 目標
|
||||||
|
|
||||||
|
一頁簡歷不是刪字遊戲，而是把最能提高面試轉化率的信息壓到一頁內。核心目標是：
|
||||||
|
|
||||||
|
- 讓招聘方在 30 秒內看懂你是誰
|
||||||
|
- 快速看到你最相關的成果
|
||||||
|
- 減少不必要的背景噪音
|
||||||
|
|
||||||
|
## 壓縮原則
|
||||||
|
|
||||||
|
### 1. 相關性優先
|
||||||
|
|
||||||
|
優先保留：
|
||||||
|
|
||||||
|
- 最近 5 到 8 年內的經歷
|
||||||
|
- 與目標 JD 高度相關的崗位、項目和技術
|
||||||
|
- 最能體現職級、複雜度和影響力的成果
|
||||||
|
|
||||||
|
優先刪除或弱化：
|
||||||
|
|
||||||
|
- 明顯弱相關的早期經歷
|
||||||
|
- 沒有結果的職責描述
|
||||||
|
- 重複的技能清單
|
||||||
|
- 空洞自評和長篇個人評價
|
||||||
|
|
||||||
|
### 2. 每段經歷只留高價值 bullet
|
||||||
|
|
||||||
|
通常每段經歷保留 2 到 4 條 bullet，優先級從高到低：
|
||||||
|
|
||||||
|
1. 最能證明崗位匹配度的成果
|
||||||
|
2. 最能證明技術深度或業務複雜度的成果
|
||||||
|
3. 最能證明影響力、 ownership 或跨團隊協作的成果
|
||||||
|
4. 其他支持性信息
|
||||||
|
|
||||||
|
### 3. 每條 bullet 都要高密度
|
||||||
|
|
||||||
|
優先滿足這個結構：
|
||||||
|
|
||||||
|
```text
|
||||||
|
動作 + 產物 + 結果
|
||||||
|
```
|
||||||
|
|
||||||
|
更強的版本是：
|
||||||
|
|
||||||
|
```text
|
||||||
|
問題/目標 + 動作 + 產物 + 結果
|
||||||
|
```
|
||||||
|
|
||||||
|
### 4. 技能清單隻保留篩選價值
|
||||||
|
|
||||||
|
不要把技能列表寫成百科。只保留：
|
||||||
|
|
||||||
|
- JD 中會被檢索的核心關鍵詞
|
||||||
|
- 能被項目經歷證明的能力
|
||||||
|
- 當前方向真正相關的技術
|
||||||
|
|
||||||
|
## 推薦版式
|
||||||
|
|
||||||
|
一頁版通常保留以下模塊：
|
||||||
|
|
||||||
|
1. 標題和聯繫方式
|
||||||
|
2. 1 到 2 行職業摘要
|
||||||
|
3. 核心技能
|
||||||
|
4. 工作經歷
|
||||||
|
5. 重點項目或教育經歷
|
||||||
|
|
||||||
|
如果工作經歷已經足夠強，項目和教育可以極度壓縮。
|
||||||
|
|
||||||
|
## 輸出模板
|
||||||
|
|
||||||
|
```markdown
|
||||||
|
# 姓名 | 目標崗位
|
||||||
|
|
||||||
|
## 職業摘要
|
||||||
|
[1 到 2 行，寫方向、年限、最強價值]
|
||||||
|
|
||||||
|
## 核心技能
|
||||||
|
[按崗位篩選價值保留 6 到 12 個關鍵詞]
|
||||||
|
|
||||||
|
## 工作經歷
|
||||||
|
### 公司 / 崗位 / 時間
|
||||||
|
- [高密度成果 bullet]
|
||||||
|
- [高密度成果 bullet]
|
||||||
|
- [高密度成果 bullet]
|
||||||
|
|
||||||
|
### 公司 / 崗位 / 時間
|
||||||
|
- [高密度成果 bullet]
|
||||||
|
- [高密度成果 bullet]
|
||||||
|
|
||||||
|
## 項目 / 教育
|
||||||
|
[只保留最相關內容]
|
||||||
|
```
|
||||||
|
|
||||||
|
## 判斷是否壓得夠好的標準
|
||||||
|
|
||||||
|
一頁版至少要做到：
|
||||||
|
|
||||||
|
- 第一屏就能看出目標崗位
|
||||||
|
- 最近經歷比舊經歷更突出
|
||||||
|
- 至少有 3 條以上能體現結果的 bullet
|
||||||
|
- 技能、經歷、目標崗位之間能互相印證
|
||||||
|
|
@ -0,0 +1,93 @@
|
||||||
|
# 常見問題與紅旗
|
||||||
|
|
||||||
|
## 1. 派遣經歷處理
|
||||||
|
|
||||||
|
以下類型的經歷容易引發面試官追問：
|
||||||
|
|
||||||
|
### 大型 IT 服務/派遣
|
||||||
|
|
||||||
|
- 中科軟
|
||||||
|
- 中軟國際
|
||||||
|
- 法本信息
|
||||||
|
- 軟通動力
|
||||||
|
- 東軟集團
|
||||||
|
- 文思海輝
|
||||||
|
- 博彥科技
|
||||||
|
- 柯萊特
|
||||||
|
|
||||||
|
### OD / 駐場 / 派遣性質
|
||||||
|
|
||||||
|
- 華為 OD
|
||||||
|
- 阿里派遣
|
||||||
|
- 字節派遣
|
||||||
|
- 騰訊派遣
|
||||||
|
|
||||||
|
處理原則：
|
||||||
|
|
||||||
|
- 派遣經歷本身不是原罪
|
||||||
|
- 真正的問題是項目價值、職責邊界和成長路徑沒講清楚
|
||||||
|
- 如果做過核心項目，重點寫項目，不要把公司標籤放大
|
||||||
|
- 如果有從派遣走向甲方、平臺型團隊或更核心業務的路徑，這是正向信號，應該主動表達
|
||||||
|
|
||||||
|
## 2. 致命問題
|
||||||
|
|
||||||
|
這些問題會顯著降低面試機會：
|
||||||
|
|
||||||
|
- 時間線衝突
|
||||||
|
- 技術棧前後矛盾
|
||||||
|
- 明顯誇大頭銜或數據
|
||||||
|
- 錯別字、術語錯誤、語病很多
|
||||||
|
|
||||||
|
## 3. 高風險問題
|
||||||
|
|
||||||
|
- 頻繁跳槽但沒有解釋
|
||||||
|
- 一堆“精通”卻找不到項目證據
|
||||||
|
- 所有描述都停留在職責層
|
||||||
|
- 用玩具項目填充真實經驗不足
|
||||||
|
|
||||||
|
## 4. 常見低級問題
|
||||||
|
|
||||||
|
- 個人摘要太長
|
||||||
|
- 自我評價空洞
|
||||||
|
- 幾乎沒有量化信息
|
||||||
|
- 日期格式、項目格式不統一
|
||||||
|
|
||||||
|
## 5. 玩具項目識別
|
||||||
|
|
||||||
|
這些項目如果寫法普通，很難加分：
|
||||||
|
|
||||||
|
- 外賣系統
|
||||||
|
- 秒殺系統
|
||||||
|
- 商城系統
|
||||||
|
- 博客系統
|
||||||
|
- 在線教育平臺
|
||||||
|
|
||||||
|
風險不在於項目題材本身，而在於：
|
||||||
|
|
||||||
|
- 沒有真實場景
|
||||||
|
- 沒有獨特取捨
|
||||||
|
- 沒有複雜問題
|
||||||
|
- 沒有結果證明
|
||||||
|
|
||||||
|
如果必須保留，至少要突出一項真實亮點：
|
||||||
|
|
||||||
|
- 壓測和容量設計
|
||||||
|
- 限流、緩存、一致性等關鍵技術細節
|
||||||
|
- 為什麼選這個方案
|
||||||
|
- 做完之後帶來的結果
|
||||||
|
|
||||||
|
## 6. 空窗期與斷層
|
||||||
|
|
||||||
|
常見情況包括：
|
||||||
|
|
||||||
|
- 創業失敗
|
||||||
|
- 讀研或進修
|
||||||
|
- Gap period
|
||||||
|
- 裁員
|
||||||
|
- 身體或家庭原因
|
||||||
|
|
||||||
|
處理建議：
|
||||||
|
|
||||||
|
- 可以簡短解釋，但不要長篇自辯
|
||||||
|
- 重點放在這段時間學到了什麼、積累了什麼
|
||||||
|
- 如果有持續學習、項目實踐或證書補充，儘量放上去
|
||||||
|
|
@ -0,0 +1,3 @@
|
||||||
|
/rendercv_output/*
|
||||||
|
/.idea/*
|
||||||
|
/fonts
|
||||||
|
|
@ -0,0 +1,329 @@
|
||||||
|
# my-rendercv
|
||||||
|
|
||||||
|
個人履歷配置專案，使用 [RenderCV](https://github.com/rendercv/rendercv) 從 YAML 檔案生成 PDF 履歷。
|
||||||
|
|
||||||
|
## 專案結構
|
||||||
|
|
||||||
|
```
|
||||||
|
my-rendercv/
|
||||||
|
├── my_cv.yaml # 主要履歷配置檔（繁體中文）
|
||||||
|
├── photo.jpg # 履歷照片
|
||||||
|
├── rendercv_output/ # 生成的輸出檔案（已 gitignore）
|
||||||
|
│ ├── *.pdf
|
||||||
|
│ ├── *.typ
|
||||||
|
│ ├── *.html
|
||||||
|
│ ├── *.md
|
||||||
|
│ └── *.png
|
||||||
|
└── README.md
|
||||||
|
```
|
||||||
|
|
||||||
|
## 環境安裝
|
||||||
|
|
||||||
|
**需求：Python 3.12 或以上版本**
|
||||||
|
|
||||||
|
```bash
|
||||||
|
pip install "rendercv[full]"
|
||||||
|
```
|
||||||
|
|
||||||
|
其他安裝方式：
|
||||||
|
|
||||||
|
```bash
|
||||||
|
# pipx（推薦，隔離全域工具）
|
||||||
|
pipx install "rendercv[full]"
|
||||||
|
|
||||||
|
# uv
|
||||||
|
uv tool install "rendercv[full]"
|
||||||
|
```
|
||||||
|
|
||||||
|
驗證安裝：
|
||||||
|
|
||||||
|
```bash
|
||||||
|
rendercv --version
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 快速開始
|
||||||
|
|
||||||
|
### 生成履歷（全格式）
|
||||||
|
|
||||||
|
```bash
|
||||||
|
rendercv render my_cv.yaml
|
||||||
|
```
|
||||||
|
|
||||||
|
輸出檔案會放在 `rendercv_output/` 目錄，包含 PDF、Typst 原始碼、HTML、Markdown、PNG。
|
||||||
|
|
||||||
|
### 監看模式（存檔後自動重新生成）
|
||||||
|
|
||||||
|
```bash
|
||||||
|
rendercv render my_cv.yaml --watch
|
||||||
|
```
|
||||||
|
|
||||||
|
### 只生成 PDF（跳過其他格式）
|
||||||
|
|
||||||
|
```bash
|
||||||
|
rendercv render my_cv.yaml --dont-generate-markdown --dont-generate-html --dont-generate-png
|
||||||
|
```
|
||||||
|
|
||||||
|
### 指定輸出路徑
|
||||||
|
|
||||||
|
```bash
|
||||||
|
rendercv render my_cv.yaml --pdf-path output/resume.pdf
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## YAML 配置結構說明
|
||||||
|
|
||||||
|
配置檔分為四個頂層區塊：
|
||||||
|
|
||||||
|
### `cv` — 履歷內容
|
||||||
|
|
||||||
|
定義個人基本資訊與各章節內容。
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
cv:
|
||||||
|
name: "Ding-Lian Chen (陳定廉)"
|
||||||
|
location: "Taipei, Taiwan"
|
||||||
|
email: "shadow449515@gmail.com"
|
||||||
|
phone: "(+886) 0979508405"
|
||||||
|
social_networks:
|
||||||
|
- network: GitHub
|
||||||
|
username: Dingian
|
||||||
|
|
||||||
|
sections:
|
||||||
|
summary:
|
||||||
|
- 純文字段落，直接放字串。
|
||||||
|
|
||||||
|
skills:
|
||||||
|
- bullet: 條列項目使用 bullet 欄位。
|
||||||
|
|
||||||
|
experience:
|
||||||
|
- company: 公司名稱
|
||||||
|
position: 職稱
|
||||||
|
location: 地點
|
||||||
|
start_date: 2021-05
|
||||||
|
end_date: present # 目前在職用 present
|
||||||
|
summary: 職位摘要
|
||||||
|
highlights:
|
||||||
|
- 重點項目 1
|
||||||
|
- 重點項目 2
|
||||||
|
|
||||||
|
projects:
|
||||||
|
- name: 專案名稱
|
||||||
|
position: 角色
|
||||||
|
tech_stack: Python, FastAPI
|
||||||
|
date: 2024-01 – Present
|
||||||
|
link: https://example.com
|
||||||
|
description: 專案描述
|
||||||
|
highlights:
|
||||||
|
- 重點項目
|
||||||
|
|
||||||
|
education:
|
||||||
|
- institution: 學校名稱
|
||||||
|
area: 系所名稱
|
||||||
|
degree: 學士
|
||||||
|
start_date: 2011-08
|
||||||
|
end_date: 2016-01
|
||||||
|
```
|
||||||
|
|
||||||
|
### `design` — 視覺設計
|
||||||
|
|
||||||
|
控制版面、顏色、字型、章節樣式等外觀設定。
|
||||||
|
|
||||||
|
| 區塊 | 說明 |
|
||||||
|
|------|------|
|
||||||
|
| `theme` | 主題（`classic`、`engineeringresumes`、`moderncv` 等） |
|
||||||
|
| `page` | 頁面尺寸、邊距、是否顯示頁尾 |
|
||||||
|
| `colors` | 各元素顏色（支援 `rgb(r, g, b)` 格式） |
|
||||||
|
| `typography` | 字型、字級、行距、對齊方式 |
|
||||||
|
| `header` | 標題區塊排版（照片位置、間距） |
|
||||||
|
| `section_titles` | 章節標題樣式（底線類型、粗細） |
|
||||||
|
| `entries` | 條目排版（欄寬、項目間距） |
|
||||||
|
| `templates` | 各條目的 Typst 模板（可自訂欄位排列） |
|
||||||
|
|
||||||
|
**目前使用的主色系：**
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
colors:
|
||||||
|
name: rgb(0, 79, 144)
|
||||||
|
section_titles: rgb(0, 79, 144)
|
||||||
|
links: rgb(0, 79, 144)
|
||||||
|
```
|
||||||
|
|
||||||
|
### `locale` — 語言本地化
|
||||||
|
|
||||||
|
控制日期格式、時間跨度文字等語言設定。
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
locale:
|
||||||
|
language: mandarin_chinese # 中文格式
|
||||||
|
# 可自訂以下文字（取消註解後修改）：
|
||||||
|
# present: 至今
|
||||||
|
# year: 年
|
||||||
|
# months: 個月
|
||||||
|
# month_abbreviations:
|
||||||
|
# - 1月
|
||||||
|
# ...
|
||||||
|
```
|
||||||
|
|
||||||
|
### `settings` — 生成設定
|
||||||
|
|
||||||
|
控制輸出行為與日期顯示。
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
settings:
|
||||||
|
current_date: '2026-01-02' # 覆蓋頁尾的更新日期
|
||||||
|
bold_keywords: [] # 自動加粗的關鍵字列表
|
||||||
|
render_command:
|
||||||
|
dont_generate_png: false
|
||||||
|
dont_generate_markdown: false
|
||||||
|
```
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 客製化設計
|
||||||
|
|
||||||
|
### 修改主題色
|
||||||
|
|
||||||
|
編輯 `design.colors` 區塊：
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
colors:
|
||||||
|
name: rgb(180, 0, 0)
|
||||||
|
section_titles: rgb(180, 0, 0)
|
||||||
|
links: rgb(180, 0, 0)
|
||||||
|
```
|
||||||
|
|
||||||
|
### 修改條目模板
|
||||||
|
|
||||||
|
`design.templates` 可自訂各條目的欄位排列，使用預設變數（全大寫）：
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
templates:
|
||||||
|
experience_entry:
|
||||||
|
main_column: |-
|
||||||
|
**COMPANY**, POSITION
|
||||||
|
SUMMARY
|
||||||
|
HIGHLIGHTS
|
||||||
|
date_and_location_column: |-
|
||||||
|
LOCATION
|
||||||
|
DATE
|
||||||
|
```
|
||||||
|
|
||||||
|
可用變數：`COMPANY`、`POSITION`、`SUMMARY`、`HIGHLIGHTS`、`DATE`、`LOCATION`、`NAME`、`DESCRIPTION`、`TECH_STACK`、`LINK` 等。
|
||||||
|
|
||||||
|
### 建立自訂主題
|
||||||
|
|
||||||
|
```bash
|
||||||
|
rendercv create-theme my-theme
|
||||||
|
```
|
||||||
|
|
||||||
|
產生 `my-theme/` 資料夾，包含 Typst 模板，可直接修改樣式後，在 YAML 中指定：
|
||||||
|
|
||||||
|
```yaml
|
||||||
|
design:
|
||||||
|
theme: my-theme
|
||||||
|
```
|
||||||
|
|
||||||
|
### 修改字型
|
||||||
|
默認的字體支援對中文不友好，沒有加粗效果，所以需要手動替換字體進行渲染，此外 rendercv 版本必須高於2.8，否則無法生效
|
||||||
|
|
||||||
|
目前使用 https://github.com/notofonts/noto-cjk/releases 下載選擇
|
||||||
|
- `Noto Serif CJK` 或 `Noto Sans CJK` 分別代表 思源宋体 和 思源黑体 (思源黑体于 2014 年 7 月首次发布，思源宋体于 2017 年 4 月发布)
|
||||||
|
- 語言選擇 `Language Specific OTFs Traditional Chinese — Taiwan (繁體中文—臺灣)`
|
||||||
|
|
||||||
|
後放到 fonts 目錄中
|
||||||
|
|
||||||
|
配置修改如下
|
||||||
|
```yaml
|
||||||
|
typography:
|
||||||
|
font_family:
|
||||||
|
body: Noto Serif CJK TC
|
||||||
|
name: Noto Serif CJK TC
|
||||||
|
headline: Noto Serif CJK TC
|
||||||
|
connections: Noto Serif CJK TC
|
||||||
|
section_titles: Noto Serif CJK TC
|
||||||
|
```
|
||||||
|
PS:
|
||||||
|
- 嘗試使用 [SarasaGothic-TTF-1.0.37](https://github.com/be5invis/Sarasa-Gothic/releases/tag/v1.0.31) 但是一直無法生效！目前推測可能是字型版本需要基於 makeotfexe 2.6.0
|
||||||
|
- 使用 [Source Han Serif | 思源宋体](https://github.com/adobe-fonts/source-han-serif) 必須改叫 `思源宋體` 而不是 `Source Han Serif TC`
|
||||||
|
- 建議從 Google 下載字體 [LXGW](https://fonts.google.com/specimen/LXGW+WenKai+TC) 這是一款系列源自 https://github.com/lxgw/LxgwWenkai
|
||||||
|
- https://github.com/max32002/swei-spring 這個沒測試，但看起來應該也是可以使用
|
||||||
|
|
||||||
|
### 為什麼 Sarasa Gothic 無效，而 Noto Serif CJK 可以？
|
||||||
|
|
||||||
|
#### 1. 兩者核心差異
|
||||||
|
|
||||||
|
| 特性 | **Sarasa Gothic (更紗黑體)** | **Noto Serif CJK (思源宋體/明體)** |
|
||||||
|
| :--- | :--- | :--- |
|
||||||
|
| **字體分類** | **黑體 (Sans-serif)** | **宋體/明體 (Serif)** |
|
||||||
|
| **主要用途** | 程式碼編輯器、終端機 (Terminal) | 書籍排版、正式文件、學術論文 |
|
||||||
|
| **設計特色** | 混合「思源黑體」與「Iosevka」，強調**等寬 (Monospace)** | 傳統印刷風格，有明顯的筆畫裝飾（襯線） |
|
||||||
|
| **字體格式** | 多為 TTC (TrueType Collection) | OTF (OpenType Font) |
|
||||||
|
|
||||||
|
- **Sarasa Gothic** 的核心價值是解決「程式碼中，中英文寬度不匹配」的問題，強行將中文寬度設為英文的兩倍，非常適合寫程式。
|
||||||
|
- **Noto Serif CJK** 為長文閱讀設計，追求古典的印刷美感。
|
||||||
|
|
||||||
|
#### 2. 原因分析
|
||||||
|
|
||||||
|
**A. 襯線體 (Serif) 的預設配置**
|
||||||
|
|
||||||
|
`rendercv` 背後的核心引擎是 **XeLaTeX/LuaLaTeX**，預設的 CV 樣式通常要求**襯線體**（如 Times New Roman）。
|
||||||
|
- **Noto Serif CJK** 是標準的襯線體，能完美對接英文 Serif 字體。
|
||||||
|
- **Sarasa Gothic** 是黑體（無襯線），當樣式表要求 Serif 邏輯時，調用黑體可能導致字體族衝突或回退（Fallback）失敗。
|
||||||
|
|
||||||
|
**B. 字體格式與 LaTeX 的相容性**
|
||||||
|
|
||||||
|
`rendercv` 依賴的 `fontspec` 套件對 **OTF (OpenType)** 格式的支援最為穩定。
|
||||||
|
- **Noto Serif CJK** 提供標準 OTF 版本，其 CID-keyed 映射嚴謹，讓 LaTeX 引擎能精確定位「繁體中文」字形編碼。
|
||||||
|
- **Sarasa Gothic** 為實現等寬做了大量調整，內部字體元數據（Metadata）有時不符合傳統 LaTeX 引擎的預期，容易導致找不到字形或渲染空白。
|
||||||
|
|
||||||
|
**C. 等寬 (Monospace) 的干擾**
|
||||||
|
|
||||||
|
`rendercv` 生成 PDF 時會計算每個字符寬度以精確排版。
|
||||||
|
- **Sarasa Gothic** 是**等寬字體**，在非程式碼區域使用等寬字體，會導致字間距（Kerning）僵硬或跑版。
|
||||||
|
- **Noto Serif CJK** 是比例字體（Proportional），允許字符根據形狀有不同寬度，符合正式文件的排版邏輯。
|
||||||
|
|
||||||
|
#### 3. 總結建議
|
||||||
|
|
||||||
|
| 使用場景 | 推薦字體 |
|
||||||
|
| :--- | :--- |
|
||||||
|
| 寫程式或設定 Terminal | **Sarasa Gothic** |
|
||||||
|
| 用 RenderCV 生成正式履歷 | **Noto Serif CJK TC** 或 **Noto Sans CJK TC** |
|
||||||
|
|
||||||
|
如果在 Windows 上透過 `scoop` 安裝 Noto Serif：
|
||||||
|
|
||||||
|
```powershell
|
||||||
|
scoop install NotoSerifCJK-TC
|
||||||
|
```
|
||||||
|
|
||||||
|
安裝後，`rendercv` 就能透過字體名稱精確抓取，生成的 PDF 字形也會顯得更專業且符合傳統排版審美。
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 常用指令速查
|
||||||
|
|
||||||
|
| 指令 | 說明 |
|
||||||
|
|------|------|
|
||||||
|
| `rendercv render my_cv.yaml` | 生成全部格式 |
|
||||||
|
| `rendercv render my_cv.yaml --watch` | 監看模式，存檔自動重新生成 |
|
||||||
|
| `rendercv render my_cv.yaml --dont-generate-png --dont-generate-html` | 跳過 PNG 和 HTML |
|
||||||
|
| `rendercv render my_cv.yaml --pdf-path output.pdf` | 指定 PDF 輸出路徑 |
|
||||||
|
| `rendercv new "姓名"` | 建立新的範本 YAML |
|
||||||
|
| `rendercv create-theme 主題名` | 建立自訂 Typst 主題 |
|
||||||
|
| `rendercv --version` | 查看版本 |
|
||||||
|
|
||||||
|
---
|
||||||
|
|
||||||
|
## 注意事項
|
||||||
|
|
||||||
|
- `rendercv_output/` 已加入 `.gitignore`，不會提交生成的檔案。
|
||||||
|
- YAML 中可使用 Markdown 語法（`**粗體**`、`[連結](url)`），PDF 中可正常渲染。
|
||||||
|
- `settings.current_date` 會影響頁尾的更新日期顯示，需手動維護。
|
||||||
|
- 升級版本前建議確認 [Changelog](https://github.com/rendercv/rendercv/releases) 是否有破壞性變更。
|
||||||
|
|
||||||
|
## 引用内容
|
||||||
|
|
||||||
|
- https://github.com/wyh0626/resume-optimizer
|
||||||
|
- https://github.com/stepfun-ai/Step-3.5-Flash/blob/main/cookbooks/resume-analysis-agent-guide/resume_analyzer.py
|
||||||
|
|
@ -0,0 +1,66 @@
|
||||||
|
cv:
|
||||||
|
name: "Ding-Lian Chen (陳定廉)"
|
||||||
|
location: "Taipei, Taiwan"
|
||||||
|
email: "shadow449515@gmail.com"
|
||||||
|
phone: "(+886) 0979508405"
|
||||||
|
social_networks:
|
||||||
|
- network: GitHub
|
||||||
|
username: Dingian
|
||||||
|
|
||||||
|
sections:
|
||||||
|
summary:
|
||||||
|
- "專注於現代化 Python 後端架構與 AI 應用的軟體工程師，具備運用 Azure OpenAI 與 LangChain 獨立建構企業級 RAG 與 Text-to-SQL 微服務原型的實戰經驗。"
|
||||||
|
- "熟悉 FastAPI、Pydantic v2 與 SQLAlchemy v2 (Async) 現代化非同步架構，注重系統安全性與高併發處理，能實作 RLS 租戶資料隔離與 AST 解析防護機制，並具備效能瓶頸排查與快取優化能力。"
|
||||||
|
|
||||||
|
education:
|
||||||
|
- institution: "National Taipei University (國立臺北大學)"
|
||||||
|
degree: "Bachelor of Science"
|
||||||
|
area: "Communication Engineering (通訊工程學系)"
|
||||||
|
location: "New Taipei, Taiwan"
|
||||||
|
start_date: "2021-09"
|
||||||
|
end_date: "2025-06"
|
||||||
|
highlights:
|
||||||
|
- "相關修課：資料結構與演算法、數位訊號處理、資訊理論、計算機網路、線性代數、機率與統計。"
|
||||||
|
|
||||||
|
experience:
|
||||||
|
- company: "Galaxy Software Services (叡揚資訊)"
|
||||||
|
position: "AI Backend Engineer Intern"
|
||||||
|
location: "Taipei, Taiwan"
|
||||||
|
start_date: "2025-12"
|
||||||
|
end_date: "2026-03"
|
||||||
|
highlights:
|
||||||
|
- "專案背景：負責「企業級 LLM Gateway 智能查詢微服務」的核心架構設計與開發，完成概念驗證 (POC) 並移交標準化部署環境，旨在讓 VIP 客戶以自然語言跨表單檢索 CRM 業務數據。"
|
||||||
|
- "進階 Text-to-SQL：設計自然語言至母產品 JSON Schema 的動態映射層，運用 Few-shot Prompting 提升複雜業務邏輯下的 SQL 生成準確率。"
|
||||||
|
- "RAG 與效能優化：設計 Semantic Caching 機制並導入 Redis 快取層，在 50 CCU 壓力測試下將 LLM API 延遲由 ~3200ms 降至 ~30ms，驗證低延遲架構可行性。"
|
||||||
|
- "資安與數據治理：實作基於 AST 解析的 SQL Guard 防護機制，100% 攔截惡意 DDL/DML 操作；結合 PostgreSQL RLS 確保多租戶環境下的資料絕對隔離。"
|
||||||
|
- "基礎設施與移交：建立 Shadow Wallet 機制進行 API Rate Limiting 防護；全案採用 uv 進行依賴鎖定，並撰寫 Podman Dockerfile，將開發至壓測環境的部署流程標準化以利團隊交接。"
|
||||||
|
|
||||||
|
- company: "經濟部產業發展署 (IDA, MOEA) & 臺北大學"
|
||||||
|
position: "AI 應用人才培育計畫 (智慧製造專班)"
|
||||||
|
location: "New Taipei, Taiwan"
|
||||||
|
start_date: "2025-08"
|
||||||
|
end_date: "2025-11"
|
||||||
|
highlights:
|
||||||
|
- "於畢業後參與 300 小時密集實訓，並獨立考取「iPAS AI 應用規劃師 (機器學習) 中級」證照，建立扎實的機器學習理論基礎並轉軌生產環境級 AI 開發。"
|
||||||
|
|
||||||
|
projects:
|
||||||
|
- name: "食道語者語音輔助裝置 (AI 聲學特徵分類系統)"
|
||||||
|
start_date: "2023-09"
|
||||||
|
end_date: "2024-06"
|
||||||
|
highlights:
|
||||||
|
- "專案背景：結合數位訊號處理與深度學習的無障礙輔助裝置，旨在還原食道語者的自然語音以解決溝通障礙。"
|
||||||
|
- "技術實踐：導入 Hanning Window 與 Overlap-Add 技術平滑音訊；使用 PyTorch 訓練 CNN 進行聲學特徵分類，測試集準確率達 86%。"
|
||||||
|
- "競賽殊榮：憑藉端到端實作完整度與社會影響力，於通訊工程學系畢業專題競賽中擊敗 17 組團隊榮獲「第一名」。"
|
||||||
|
|
||||||
|
skills:
|
||||||
|
- label: "Backend & Systems"
|
||||||
|
details: "Python (FastAPI, Pydantic v2, SQLAlchemy v2), RESTful API, Asynchronous Programming"
|
||||||
|
- label: "AI & LLM Stack"
|
||||||
|
details: "Azure OpenAI (GPT-4o-mini), LangChain, RAG, Text-to-SQL, Few-shot Prompting, Embedding Models"
|
||||||
|
- label: "Data & DevOps"
|
||||||
|
details: "PostgreSQL (pgvector, RLS), Redis, uv, Docker/Podman, Linux, Git, Locust (Load Testing)"
|
||||||
|
- label: "Architecture"
|
||||||
|
details: "Multi-tenancy, Semantic Caching, Rate Limiting, AST Parsing, SQL Injection Defense"
|
||||||
|
|
||||||
|
design:
|
||||||
|
theme: sb2nov
|
||||||
Loading…
Reference in New Issue