# 影響力敘事工具箱

## 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. 一句話判斷標準

一條好的項目描述，至少滿足下面三項中的兩項：

- 說清了問題
- 說清了你的動作
- 說清了結果