剛剛在 line 群的小對話，覺得寫了蠻多的，摘回來一下：

剛剛在 line 群的小對話，覺得寫了蠻多的，摘回來一下： 「請問⋯到底該如何下指令⋯ 才能不讓機器人大改原先做好的內容⋯ 試過很多方法 也套過很多工具⋯ 但還是一直被大改」 我： 他是照你的指令改，所以是你給他的指令讓他覺得要大改，這個基本上還是的回到先做計畫再執行，並且要有能看的懂計畫的能力。 「但是 即便我沒有要求他改前面 也要求他不要改前面」 我： 因為它沒有前面後面，你跟他說要開一條路，他一路都更過去，他覺得他沒有錯，哈哈哈哈 你必須要在計畫中，明確的跟他商量出一條能避開的可行的路，他會去剷平他就表示他覺得這是可行的路，跟程式溝通避免負面表列。 「有⋯舉例說明嗎 不好意思 告訴我他要的 不要一直跟他說 你不要做什麼 告訴他 「要」什麼的意思嗎」 我： 比方說幫我們剛做的賓果盤加上連線標記 但是不要修改既有的畫面，採取在上面讀取狀態後加寫額外的 status board ，如果有碰到困難，請跟我討論 對，你跟他討論一條可行的路，他就會只做那條路，他會多做就是覺得沒有路，他也沒有很喜歡多做。 「那要怎麼避免 你叫他做這件事 他沒做⋯」 我： 所以你可以跟他說， ooo 區塊我們已經花了很多力氣處理完了，請你用其他方案加掛，如果需要修改他，請跟我討論原因跟有沒有替代方案。 用好一點的模型，告訴他你在意的事情是什麼（而不是不要），善用git 在他還是爆走的時候可以回到上一個存檔點。 然後我自己的習慣是會把要做的事情條列3-4點 ，每次結束會問她這些項目都做到了嗎，檢核點是啥，如何確保有做， 他還沒有很聰明，至少對於怎樣算完成，跟你我還有很大的落差，我們得處理品管。 「我錯了 我反過來了⋯ 因為不善整理 他跟我一問一答 整理出需求 算是有整理出來 但每次一更改就驚天動地」 應該說他很難理解你哪些要改哪些不要改， 你這種討論法要多問他會對現在的系統動到啥。不然會許願許的很開心但是一直在都更。 你慢慢會抓到傳統的模組分工，軟體工程的產品模組就是在避免改一個改一串，你理論上會慢慢被推去學會這件事情。 然後規模越大步伐越小。

原始 Facebook 貼文