這幾年指導學生的時候常遇到的問題就是學生會說「因為 OOO 做不出來，所以改用 XXX 方法」，有的甚至直接跳到 metaheuristic 方法，或者學生就等著看老師要怎麼辦，抑或是看能不能就直接更換題目。這種時候都讓我感到相當痛苦。
要知道「做不出來」(是主觀能力認定) 與「此問題無解」(是客觀事實否定) 其實有天淵之別，為了避免學生在「原方法尚未分析清楚」的情況下任意切換方法，導致研究方向失控或失去理論基礎。我將我的想法稍作整理，我想應該在廣義的控制理論、隨機系統、最佳化、金融工程領域都能適用：
什麼不是更換研究方法的理由：
以下理由都不足以支持換方法：
- 「跑不出答案(跑了很多次)」、「電腦算不動」、「算法不 converge 」、「結果怪怪的」、「找不到答案」、「證不出來」、「資料拿不到」、「AI建議我換方法（但自己不知道為什麼）」
- 「我看別人（文獻）用這方法有效」、「別人(文獻)都這樣用」、「文獻看不懂」
- 「我覺得 metaheuristic 方法 GitHub 上有現成 package 比較簡單」
- 「我不知道怎麼 debug」、「code不會寫」
只說「做不出來」其實本身沒有任何意義。這類說法大多是「執行結果不如預期」而非「方法原理上不可行」。
要換方法應先提交 Failure Analysis Report：
未提交前，不應任意更換方法，也不該自行更動研究方向。這份報告的目的是要讓指導教授看得出來，你已經有試過各種「系統性修正」，而不是亂試新方法。學生應該要能回答：失敗發生在哪？合理推測失敗原因及其論據為何？若要換方法，新方法究竟解決原本方法哪個部分的限制？更細步來說， Failure Analysis Report 至少應包含：
- 原方法的完整理論與演算法描述
- 問題的 objective、constraints、dynamics
- 參數設定
- 算法步驟
- 預期應滿足的最佳性條件（如 KKT、Bellman、HJB、local/global optimality）
- 預期應滿足的對偶性質 (strong/weak duality，duality gap)
- 預期應滿足的拘束資格條件 (constraint qualification, Slater's condition)
- 預期應滿足的可測性/連續性/可導性等條件
- 預期應滿足的穩定性條件（如 Lyapunov function, asymptotic/non-asymptotic）
- 預期應滿足的強健性條件 (worst-case analysis, sensitivity analysis)
- 預期應滿足的算法複雜度條件
- 預期應滿足的近似條件
- 明確指出「哪裡做不出來」，只說「做不出來」= 無效論證。學生應回答：
- 失敗發生在哪一行計算？
- 是 gradient / subgradient / Jacobian / Hessian 算不出來？
- 約束是否不相容？
- 數值解是否跳出可行域？數值誤差？
- dynamics 無法滿足？
- initial condition 是否導致 divergence？
- 實驗/模擬結果是否可重現？(不同資料集都指向同一結論)
- 模擬結果不佳的具體意義(穩定性不好？報酬不佳？變異太大？)
- 合理的失敗原因推論（有理論或合理假設），例如：
- 模型非凸 → local solver 卡在 local minima
- state/control constraint 過於嚴格 → 無可行解
- dynamics stiffness 太高 → 數值爆炸
- objective/loss scale 不當 → 需要 normalization
- 多期多目標計算
- Impossibility claim 的證明: 若你要宣稱「這個問題做不到 / 不可能」必須附上 理論或模擬證據，例如：
- 證明無可行解
- 顯示最佳性條件（KKT / Bellman）不可同時滿足
- 顯示系統缺失某robustness/stability/performance
- 指出該問題在某些條件下為 NP-hard，並說明該障礙是否適用目前研究問題的結構
- 提供反例或實驗結果，清楚展示失敗原因
沒有上述證據，只說「做不出來」、「不可能」等說法，是不會被直接接受的。我預期學生應該要提供「數值/實證數據」與「結構性論證」各一項：
- 數值例子(宣稱非凸應該提供非凸性理論推導反例，或在低維情況繪製其非凸結構的圖例)
- 圖表 (solution path, 誤差收斂曲線，state trajectory, etc)
- log / 訊息 (錯誤碼，停止條件)
- constraint violation
- Optimality Condition (e.g., KKT) violation
- Complexity analysis
- 數值或者理論反例
- 調整 step size
- 更換 initial condition
- 放寬或修改部分 constraint
- scaling / normalization / shifting
- convex surrogate、linearization / relaxation
- 理論上合理的 heuristic（不是隨便 metaheuristic）
- greedy algorithm with provable approximation ratio 是合理的 heuristic；而 genetic algorithm without convergence guarantee 若只是因為有現成package可用，則不能直接取代理論分析。也應檢查「方法與問題的結構假設(convexity, smoothness, dimensionality等)是否相容。
- 考慮的問題範圍與算法適用性，比如 L-BFGS-B 適用於 box 拘束。
- 求解器更換 (Gurobi/MOSEK/CVX)
- 更換solver本身仍應有明確理由，比如問題規模大小變動等等。
對採用「新方法」的要求：必須有合理性證據
允許換方法的合理理由示例：
- 新方法與研究問題結構更一致（例如確認問題具有 QP, LP, SOCP, SDP 結構後，改用相對應的convex optimization approach）
- 可以證明更好的 optimality/stability/robustness 性質
- 可以證明可行性、收斂性
- 在保留可驗證的approximation/regret guarantee前提，達成原方法不可達的問題規模。
- 文獻中有具體、可查證的支持
不合理理由示例：
- 「github上有現成套件」
- 「我覺得 metaheuristic 比較方便」
- 「網路上有人這樣用」
- 「我自己跑起來比較順」
若新方法無法在 「理論上更強」 或與 「結構更相容」或「在保留guarantee前提下擴展問題規模」三者中一項，則原則上不應更換。未達以上要求就換方法，我傾向於將其視同無效研究行為。不僅浪費自己時間也浪費指導教授時間。
反思：
研究不是亂試方法，特別在遇到困難的時候，應該要去理解原方法限制在哪？為什麼失敗？
雖然說是這樣說，但是可能更多時候師生立場不同，可能學生觀點會認為是老師們都是「站著說話不腰疼」，只會在旁邊指指點點，但是在我自己經驗裡，其實情況更多時候往往相反：是我本人自己(而非學生)跳下去解決問題，重寫理論、重跑模擬、重寫論文幾乎是家常便飯。
如果長期都是這樣，那指導學生的意義何在？畢竟我本人已經有一博三碩，應該是不需要再多一個學位，因此這些關於「合格的研究方法」以及在「方法失敗時的分析與回報」的標準，確實應該是在研究最早期就應該先說清楚。每一次更換方法或調整題目，都應該確保是在有論證的研究判斷下所做的決策，而非遇到困難後的逃避。
