真實場景 GSD：代碼、文章、提案三種任務的實戰套路

前面五篇把 GSD 的問題、心法、工具和陷阱都講清楚了。這篇的任務只有一個：把那些東西變成你今天就可以用的操作手冊。

不同任務類型的卡點不一樣，啟動的方式也不一樣。以下用三種最常見的任務類型示範完整的 GSD 節奏——你不需要全部用上，找到對應你今天工作的那個就夠了。

場景一：代碼開發任務

最常見的卡點

需求模糊，不知道「做完」的邊界在哪裡
AI 改了東西，不知道有沒有動到不該動的地方
修了 bug 但產生了另一個 bug，不斷循環
「先做出來再補測試」然後測試永遠沒補

GSD 套路

啟動（3 分鐘）

跟 AI 說清楚這四件事：

這次要完成什麼（功能/修復，限定一件事）
不需要動的範圍（明確說出來，AI 不動的東西比它猜哪裡不能動更可靠）
做完的標準（什麼行為/輸出算完成）
這次有什麼已知的限制或依賴

任務：實作 user 登入的 JWT 刷新邏輯
不動的範圍：登入/登出流程、user schema 不動
完成標準：refresh token 可以換出新的 access token，舊的 refresh token 自動失效
限制：用現有的 auth.service.ts，不新增 dependency

執行（專注段）

先讓 AI 列出它打算怎麼做，確認過再動手
每完成一個小步驟（例如一個函數），先在本地跑一下驗收，確認無誤再繼續
如果 AI 的輸出讓你看不懂，就是一個信號——先搞懂才繼續，不要蒙著頭跑

收尾（5 分鐘）

跑一遍主流程的手動測試，確認 happy path 過了
寫 commit message，說清楚改了什麼
如果還有沒補的測試或 edge case，開一張待辦事項，記下來，不要留在腦子裡

常見陷阱提醒
AI 幫你改 bug 的時候，很容易順手改一些「它覺得可以更好」的地方。在 diff 裡仔細看你沒要求的改動——不是說它改的一定不好，而是你得知道它改了什麼，不然你不能說「我知道這個功能做了什麼」。

場景二：文章寫作任務

最常見的卡點

不知道從哪裡下筆，一直在醞釀
AI 生的草稿讀起來像 AI 寫的，改起來比重寫還累
寫了一半，發現結構不對，推倒重來
覺得還沒準備好發出去，一直在「潤稿」

GSD 套路

啟動（5 分鐘）

在動筆之前，先用 AI 把這兩件事確認清楚：

誰在讀，讀完他知道什麼
不是「這篇是給開發者看的」，而是「讀完這篇的人，應該能說出 X 是怎麼回事，並且知道下一步是什麼」。
文章的骨架（H2 清單）
用一句話概括每個 H2 要說的論點——不是標題本身，是「這個段落在說什麼」。確認骨架對了，再開始寫。

骨架對了，AI 寫的草稿才能往對的方向走；骨架沒確認就開始寫，很容易寫到一半才發現結構跑掉，然後陷入「重構文章」的耗時模式。

執行（段落逐一完成）

建議的節奏：一次只請 AI 寫一個 H2 段落，而不是請它一次輸出整篇文章。

一次一段有幾個好處：

你可以在每段完成的時候驗收語氣、觀點是不是你要的
你自己介入修改的成本低很多——改一段，遠比改整篇容易
每完成一段你有一個小的進度感，比一口氣看到一篇「差一點完美」的草稿，心理上好處理

用 AI 寫稿的指令建議帶上：「語氣直接一點，不要太多鋪陳，不要用『值得注意的是』這類開頭」——這樣至少能過濾掉最容易讓人改不完的 AI 語氣。

收尾（10 分鐘）

快速掃一遍全文，確認每個 H2 的論點清楚、有首尾呼應
把你覺得讀起來不像你說話方式的句子改掉（兩三個就好，不要全改）
設一個發出去的時間點——今天還是明天，說好，然後遵守它

常見陷阱提醒
「這篇還沒準備好」這個感覺，99% 的時候不是真的——是你對「被人看到」這件事有點緊張。問自己一個問題：「如果這篇文章只要讓一個人讀了有收穫，它現在達到了嗎？」如果是，就發。

場景三：提案準備任務

最常見的卡點

不清楚對方真正在乎的是什麼，做了很多但打不中核心
太多資訊塞進去，反而讓人不知道重點在哪
AI 幫你生的提案太「模板感」，讀起來沒有說服力
來回修改多個版本，但版本之間的差異沒有方向

GSD 套路

啟動（5 分鐘）

提案啟動最重要的一步，是先把「對方的問題」說清楚——不是你要提什麼，而是「對方現在的狀況是什麼、他希望達到的結果是什麼、他最在意的限制是什麼」。

用 AI 做一個「對方視角的摘要」：

受眾：[對方是誰、什麼角色]
他們的現況：[現在面對的問題或挑戰]
他們想要的結果：[用他們的語言說]
他們最在意的限制：[時間、預算、風險、內部政治...]
請幫我從「對方最在意的是什麼」這個角度，整理出這份提案需要回答的核心問題。

這一步做完，你就有了一個不容易跑偏的框架。

執行（結構優先，細節後補）

提案寫作的正確順序：先確認「一句話說明提案的核心論點」，再展開結構，最後才填細節。

逆向來做的代價是：你花了很多時間填細節，最後發現核心論點不清，整份提案需要大幅重寫。

用 AI 的建議順序：

請 AI 幫你列出提案的一句話論點（三個版本，你選一個）
根據核心論點展開 3-4 個支撐點
每個支撐點需要哪些資料或例子支撐（先列清單，再去找）
最後才是版面設計與視覺包裝

收尾（10 分鐘）

用「對方視角」快速讀一遍：這份提案有沒有回答「為什麼這個方案對他最好」？
確認有一個清楚的「下一步是什麼」——對方看完要做什麼動作、你希望他怎麼回應
版本命名好，把「目前要送出去的版本」存一份，不要讓版本繼續漂移

常見陷阱提醒
AI 生的提案語言通常太「正式」——充滿「為了達成目標」「透過有效的方法」這類填充句。這些句子讀起來有字、但沒有說任何東西。送出去之前，把這類句子換成「我們做了 X，因此你會得到 Y」的具體語言。

通用的收尾儀式

不管是哪種任務，結束之前做這三件事，讓大腦能真的說「這件事做完了」：

確認完成條件已達到（不是「感覺差不多了」，是「DoD 清單打勾了」）
把待解決的問題記錄在對的地方（不是留在對話裡，是進待辦清單或筆記）
讓輸出離開草稿狀態（commit、發布、發送——讓它真的「出去了」）

把 GSD 變成一個習慣

這個系列從「診斷問題」講到「真實場景套路」，所有的內容加起來，最終想讓你帶走的，只有這一套日常節奏：

早上：今天的三件事是什麼（任務層清單）
開始每件事前：邊界和完成條件確認了嗎
結束每件事後：可以打勾了嗎，待解決的問題記下來了嗎
一天結束：有沒有東西真的完成了

這四個問題，不需要任何特殊工具——但它們能讓你的 AI 使用效率，比大部分人高出一個數量級。不是因為你用了更厲害的模型或更長的 prompt，而是因為你知道你在做什麼、做到哪裡算完、做完了能收尾。

這就是 Get Shit Done。

回到系列總覽

這篇是 GSD 系列的最終站，講 代碼、文章、提案三種任務的實戰套路。完整閱讀路線與其他篇主題，請回到 GSD 入門課。