思維鏈提示詞 — Chain-of-Thought 推理完全指南

✓ 當任務涉及多步推理時
  - 數學問題
  - 邏輯謎題
  - 因果關係分析
  - 決策推理
  - 複雜的規則應用

✓ 當答案不明顯時
  - 「為什麼 X 比 Y 更好？」
  - 「在這種情況下應該怎麼做？」
  - 「什麼原因導致這個結果？」

✗ 當任務簡單時（CoT 無幫助或反而降低效率）
  - 單純分類
  - 直接查找
  - 簡單的事實問題
  - 創意寫作（可能太冗長）

✗ 當需要極快回應時
  - CoT 增加 tokens，變慢
  - 但準確度提升值得

Problem: [problem statement]

Before giving your final answer, think through this step by step:
1. [Step 1 description]
2. [Step 2 description]
3. [Step 3 description]

Then provide your final answer.

優點：簡單、直接
缺點：有時 Claude 的步驟不夠深入

Example:
Question: 艾莉絲有 5 個蘋果。她買了 3 個更多。然後她給了貝託 2 個。她現在有多少個？

Thinking:
1. 艾莉絲開始有 5 個蘋果
2. 她買了 3 個，所以現在有 5 + 3 = 8 個
3. 她給了貝託 2 個，所以現在有 8 - 2 = 6 個
4. 答案：6 個蘋果

Answer: 6

---

Now solve this:
Question: [你的問題]

Thinking: [Claude 會遵循相同格式]

方法：
1. 提出相同問題 3-5 次，但提示詞略有不同
2. 讓 Claude 提供不同的推理路徑
3. 多數投票選出答案

實例：
提示詞 1：「一步步思考…」
提示詞 2：「列出所有可能…」
提示詞 3：「從不同角度分析…」

好處：增加可靠性，即使單個推理有誤也能發現

Think step by step:
1. 分析情況
2. 做出決定

（太寬泛，無法引導具體思考）

Think step by step:
1. 列出約束條件（預算、時間、人力）
2. 對每個制約評估影響
3. 列出 3-5 個可能的選項
4. 比較每個選項的優缺點
5. 推薦最平衡的選項

✓ 推薦格式：
Step 1: [做什麼] → [結果] → So [中間結論]
Step 2: [做什麼] → [結果] → So [中間結論]
...
Final Answer: [綜合所有步驟]

這種「So」結構確保每步都有具體產出。

包含這樣的提示：
「在每一步，質疑自己的假設。這是否合理？」
「有沒有其他解釋這個結果的方式？」
「什麼可能讓我的推理出錯？」

這增加了 Claude 的批判性思維。

Question: 我們應該進入日本市場嗎？已有 $2M 預算，團隊 5 人。

Thinking steps:
1. Identify market constraints
2. Assess team capabilities
3. Evaluate financial risk
4. Estimate time-to-revenue
5. Compare with alternative markets
6. Make recommendation

Example response (CoT):
Step 1: Market constraints
- 日本市場語言障礙
- 競爭激烈（本地和國際）
- 規監複雜
- 進入費用 $500K-1M
→ So: 高投入成本

Step 2: Team assessment
- 無日語或日本商業經驗
- 需要當地夥伴
- 5 人無法同時進行兩個市場
→ So: 需要當地團隊投資

Step 3: Financial risk
- $2M 預算足以測試
- 但如果失敗，損失重
→ So: 高風險

Final assessment: 不推薦立即進入。建議先與日本合作夥伴試點。

Question: 一列火車從 A 城出發，時速 60 km/h。另一列從 B 城出發，時速 80 km/h。
兩城相距 350 km。如果兩列同時出發相向而行，何時相遇？

CoT format:
Step 1: Define variables
- Train A speed: 60 km/h
- Train B speed: 80 km/h
- Distance: 350 km
- They move toward each other

Step 2: Determine combined approach speed
- When moving toward each other, speeds add
- Combined speed = 60 + 80 = 140 km/h

Step 3: Calculate time using formula
- Time = Distance / Combined Speed
- Time = 350 km / 140 km/h = 2.5 hours

Step 4: Verify
- Distance covered by A: 60 × 2.5 = 150 km
- Distance covered by B: 80 × 2.5 = 200 km
- Total: 150 + 200 = 350 km ✓

Answer: 2.5 hours (or 2 hours 30 minutes)

Question: 我們的用戶留存率上個月從 45% 下降到 35%。可能的原因是什麼？

CoT approach:
Step 1: Time correlation analysis
- When did the drop start?
- Was there any product change around that time?
- Any external events (competitor, press)?

Step 2: Segment analysis
- Did all user segments drop equally?
- Or specific cohorts (new users, paid, free)?

Step 3: User feedback review
- Check support tickets for complaints
- Review NPS comments
- Look for patterns

Step 4: Hypothesis ranking
- Most likely: [cause A with evidence]
- Second: [cause B with evidence]
- Unlikely: [cause C, ruled out because]

Final recommendation:
Investigate [top cause] immediately with qualitative interviews.

Question: 我們發現一個重要的安全漏洞。修復需要 3 週，但競品可能已經知道。
應該馬上透露還是先修復？

CoT thinking:
Step 1: Stakeholder impact
- Users at risk if we wait
- Company reputation if we disclose early
- Competitors advantage if they know

Step 2: Ethical obligations
- Transparency vs. protection
- Legal requirements
- Industry standards

Step 3: Practical timeline
- Can we push the fix to 1 week?
- Can we deploy a temporary mitigation?

Step 4: Scenario comparison
- Scenario A (Disclose now): Build trust, legal protection, user protection
- Scenario B (Wait 3 weeks): Risk exposure, reputation damage

Recommendation:
Disclose to affected users immediately with mitigation plan,
offer timeline to full fix.

Question: API 端點間歇性出現 500 錯誤，但日誌沒有明顯錯誤。可能是什麼？

CoT diagnostic approach:
Step 1: Identify timing patterns
- When does it happen? (peak hours, specific endpoints, etc.)
- How often? (1/100 requests, 1/1000?)

Step 2: Review infrastructure
- Server memory/CPU during errors?
- Database connection pool saturation?
- Network timeouts?

Step 3: Check dependencies
- Third-party API failures?
- Cache invalidation issues?
- Race conditions under load?

Step 4: Hypothesis ranking
- Most likely: Connection pool exhaustion (common symptom)
- Second: Timeout on slow third-party calls
- Investigation: Add detailed logging to catch next error

Next steps: Deploy enhanced logging, monitor for 24 hours.

Question: 我們的新功能採用率低於預期（5% vs 20% 目標）。
應該改進功能還是改進上市策略？

CoT reasoning:
Step 1: Data interpretation
- Users who find the feature love it (high retention)
- But discovery is the problem
- This suggests: marketing/UX issue, not product issue

Step 2: User behavior analysis
- Where do users discover features?
- Are we promoting it in right places?
- Is onboarding mentioning it?

Step 3: Effort vs impact
- Improving feature: 2 weeks, maybe +5% adoption
- Improving onboarding: 1 week, could be +15%
- Marketing push: 3 days, might gain +8%

Step 4: Recommendation hierarchy
1. Fast win: Improve onboarding (3 days)
2. Follow up: Marketing push (concurrent)
3. Later: Feature improvements based on feedback

Expected outcome: 20% adoption within 4 weeks.

After completing your step-by-step reasoning:

1. Review your logic: Is each step logically sound?
2. Check for bias: Did you favor one option unfairly?
3. Identify assumptions: What did you assume to be true?
4. Stress test: What would break your conclusion?
5. Confidence level: How confident are you (0-100%)?
6. Alternative explanation: Could another interpretation fit the data?

This adds self-awareness and reduces overconfidence.