說實話，不知道怎麽回答，不是行業大佬，只是機緣巧合分別呆過了幾種不同類別的團隊和公司。只能就我個人的經歷，所看到的東西做一下分享。
首先，其實這個問題有個大前提就已經不太明了了，究竟啥是技術策劃，有標準定義嗎？招聘網站上面的確也有，但是落實到具體的業務能力，其實還是個有偏差的，就算是TA，也有多種細分類別，畢竟你都談到TA-TD這個部份了，一定是有細分的。
我自己最早做橫版動作RPG入的行，結果卻在之後的幾年裏做了射擊品類關卡，算是個爆款。那時候我身為小白關卡，簡單自學之後開始拉灰盒，但是第二年之後專案定位希望能有更多的關卡互動機制，我當時一個程式碼都不會，連C#讀作」西秀噗「都不知道的策劃，但還是用復制黏貼的方法做出了幾個場景內的玩法互動機制，什麽傳送門，煙霧蘑菇，彈簧，移動版之類的東西，那時候我就在想，我要是一個正經會打程式碼的策劃就好了。
與此同時，這個時候我只知道團隊裏有一個技術美術，雖然我其實也不是那麽清楚，究竟技術美術當時做了哪些跟技術相關的美術產出。於是，我模模糊糊的，也想到是不是未來有個工種就是技術策劃， 一個會程式碼懂遊戲設計的策劃。
程式碼和遊戲設計都重要，前者是基礎，後者是重點，畢竟T只是個字首。
在一個初期的小型團隊，20人以內的小體量專案，一個會程式碼懂設計的策劃，就很不錯了。（有就不錯了）這樣的TD，著重於快速使用程式碼邏輯實作基礎的玩法機制，與其叫TD，不如叫TLD Technical Level Designer，技術關卡，暴雪EA傾向於需求這樣的關卡設計師。
那麽如果上升到50人以上，100人以內的偏中後期專案呢？（得有個像樣的，程式碼實作能力要強，因為要求不只在於快速實作某個單獨小玩法了， TD在這裏更像一個「鐵匠」，一個專門制造「武器」的人，勇者們沒有鐵匠，可是只能赤手空拳的。 ）
在我之後的另一個專案中，已經有了一個正經的老程式，但他的職位是技術策劃，實打實的，有職級的，也幹了實事。他制作了一個技能編輯器，並在之後的工作裏也持續做著關卡編輯器。
此時這位技術策劃的定位，在於促進玩法生產的效率。但，他的定位也不局限於此，不然只是個工具人。
所以，他的另一項工作便是快速實作玩法demo，這個時候其實程式碼要求依然是有的，但是，更多的在於快速實作可玩的玩法叠代demo，這個demo是個切片，並且一定是具有較強的策劃思維的人才可勝任，因為只有這樣的人，才不會盲目的聽著其他戰鬥或關卡策劃去實作某個功能，淪為其實跟客戶端沒差的人， 他需要從技術角度和核心玩法去思考玩法的實作。
我這裏都沒有講到專案類別，因為我認為技術策劃實際不會因為遊戲類別發生太大的工作變化，實質就一個：提升玩法生產效率，使玩法可透過實際可玩的玩法切片進行驗證叠代與校正。
這裏想額外提一下，可能這是我遇到的專案比較特別？大家看的時候可以當參考吧，別當典型。
我想講的是，照理說中後期，不是應該少做玩法的改動嗎？
事實是，目前的幾個大型廠商都有非常堅實的GAC部門了，他們能從策劃角度提供各種方面（互動，營運，核心玩法，市場競品）專業的使用者體驗反饋，並提出有建設性的修改建議，而有些創新性的專案如果要改動很可能就要改比較核心的玩法了，這時候改，肯定不是瞎吉兒改的，這時候有靠譜的TD幫忙，能很快的做一次驗證。避免改動到連美術都生產完結了，結果制作人（老板）最後看了看，覺得好像還是不行的樣子。然後20人左右3-4個月，甚至更多的時間，就消耗掉了，這些人力，全都是錢，一個玩法，如果白做了，光算這個薪金就浪費了幾百萬，可是，專案的開發時間才是最寶貴的，很可能你明天專案就被裁了。
接著，我到了一個包含所有美術在內，所有子公司，外包可能超五百人的在研專案。因為專案的特殊性就不描述內容了。就講一個現象，那就是其實還是客戶端的大兄弟更靠譜一些，原因的話，按我目前的資歷，沒法一下總結出來，還能總結到位。總之一言概之就是，當工業化細分到一定程度，部份職位反而就不太需要了，會有其他的相關部門被單獨拉出來。
改天有時間再專門寫一下遊戲開發流程相關的文章吧，其實光講TD，講的不會很清楚，見笑了啊，實際真的需要看各種研發階段，專案難題，盈利模式各方面問題綜合著看。
