技術網誌怎麼寫提示詞：把項目經驗寫成有乾貨的技術文章（問題 → 過程 → 數據 → 教訓）
想把做過的項目、踩過的坑寫成技術網誌（公司技術號、掘金、個人網誌），但不知道怎麼組織、怕寫成流水帳時用：AI 先通過提問挖出文章的核心價值，再給大綱和開頭，正文由你補充真實細節，避免寫出空洞的 AI 腔文章。
通用大模型 對話模型通用
你是一名技術社區的資深編輯，幫我把一段項目經驗寫成技術文章。注意：文章的價值來自我的真實經歷和數據，你負責挖掘、組織和潤色，不要編造經歷、數據和代碼運行結果。 素材： - 項目背景與我負責的部分：[項目背景] - 遇到的核心問題：[核心問題] - 我嘗試過的方案（包括失敗的）：[嘗試過的方案] - 最終效果與數據：[如接口耗時從 2 秒降到 200 毫秒] - 目標讀者：[如有 1 到 3 年經驗的後端開發] - 發佈平台與篇幅：[如公司技術公眾號，3000 字左右] 第一步：先向我提 5 個以內的問題，挖掘素材裏還缺的關鍵細節，例如：當時為什麼會選錯方案、定位問題的轉折點是什麼、有沒有可以量化的對比。等我回答後再繼續。 第二步：給出 3 個標題候選和文章的「一句話核心觀點」，標題要具體，說清楚解決了什麼問題、用了什麼方法，不用誇張詞。 第三步：給出大綱，建議結構： 1. 開頭：用一個具體的現象或數字引出問題（不要從「隨着互聯網的發展」寫起）； 2. 背景：讀者理解問題所需的最少上下文； 3. 排查或探索過程：按時間順序，保留走過的彎路和當時的判斷依據； 4. 方案與關鍵代碼：只放核心片段，每段代碼前後說明它解決了什麼； 5. 效果：前後對比的數據，註明測量方式； 6. 經驗與適用範圍：這個方案在什麼情況下不適用； 7. 結尾：一兩句總結，不寫口號。 第四步：寫出開頭兩段和一個章節的完整示範，其餘章節寫成要點，由我補充真實細節。凡是需要我提供的資訊，用「（待補充：……）」標出。 全文風格：第一人稱復盤口吻，少用形容詞，多用數字、日誌片段和對比；技術名詞首次出現時給一句解釋。 公司內部的敏感資料（內部系統名、真實業務數據、客戶名）提醒我在發佈前替換或脫敏。
高亮處換成你自己的內容：[項目背景]、[核心問題]、[嘗試過的方案]、[如接口耗時從 2 秒降到 200 毫秒]、[如有 1 到 3 年經驗的後端開發]、[如公司技術公眾號，3000 字左右]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[我嘗試過的方案] 一定要包括失敗的，讀者最想看的往往是「為什麼一開始的思路不行」。[最終效果與數據] 有具體數字的文章說服力強得多，沒有就在追問環節補。
常見坑：
- 讓 AI 直接寫全文，結果是結構工整但沒有資訊量的「正確的廢話」，讀者一眼就能看出來。這條提示詞刻意讓 AI 只寫示範章節，正文的細節由你補充。
- 開頭寫大背景、寫行業趨勢，讀者三行之內就會關掉。直接從一個具體現象開始，例如「上線第三天，訂單接口的 P99 耗時從 300 毫秒漲到了 4 秒」。
- 代碼貼太多。只保留關鍵片段，完整代碼放倉庫連結。
追問技巧：初稿寫完後，把全文貼回去，說「站在目標讀者的角度，指出哪些地方看不懂、哪些地方可以刪掉」。
示例輸出
示例，僅供參考（標題候選節選）
- 《一次 MySQL 深分頁優化：從 4 秒到 80 毫秒的排查過程》
- 《訂單列表翻到第 1000 頁為什麼會卡死？聊聊延遲關聯和游標分頁》
- 《深分頁優化踩坑記：加索引為什麼沒用》
一句話核心觀點：深分頁慢的根源是掃描並丟棄大量行，加索引解決不了，要改變分頁方式。
開頭示範：
上個月，運營同學反饋訂單後台「翻到後面就打不開」。監控顯示，offset 超過 10 萬之後，這個接口的耗時穩定在 4 秒以上。我們的第一反應是加索引——結果加完之後幾乎沒有變化。（待補充：加索引前後的具體耗時）
同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～