博客 / 詳情

返回

使用 AI 編程工具的一點實踐體會:為什麼要減少對話輪次、一次把需求説清楚

使用 AI 編程工具的一點實踐體會:為什麼要減少對話輪次、一次把需求説清楚

一、背景

隨着 Cursor、Copilot、ChatGPT 等 AI 編程工具在日常開發中的普及,
越來越多的開發者開始嘗試用 AI 來完成:

  • 單個功能模塊
  • 小型系統原型
  • 重複性或模板化代碼

我自己在實際使用這些工具的過程中,也逐漸形成了一些使用習慣。
其中最重要的一點體會是:

在讓 AI 寫代碼時,應儘量減少對話輪次,用盡可能清晰、完整的描述一次性説明核心需求。

這篇文章主要記錄我在實踐中總結出的原因、經驗以及適用邊界。


二、常見的錯誤使用方式

在剛開始使用 AI 編程工具時,我(以及身邊不少同事)都會下意識採用類似下面的方式:

  1. 先描述一個比較模糊的需求
  2. 看 AI 生成的代碼
  3. 發現不符合預期
  4. 繼續在當前對話中補充或修改需求
  5. 重複上述過程

這種方式在簡單問題上通常沒什麼問題,
但在以下場景中,很容易出現偏差:

  • 模塊之間存在關聯
  • 功能有前後依賴關係
  • 有較多隱含約束(性能、擴展性、結構等)

最終結果往往是:

代碼越來越“補丁化”,整體實現逐漸偏離最初的目標。


三、為什麼對話輪次越多,結果越容易偏離?

3.1 模型理解是“上下文驅動”的

AI 模型並不是像人一樣“始終記得最初的目標”,而是:

  • 基於當前上下文進行概率推斷
  • 更傾向於滿足最近一輪對話中的顯式要求

當我們不斷追加新指令時:

  • 新需求可能與舊需求存在隱性衝突
  • 模型會嘗試“局部修補”,而不是整體重構

久而久之,最初的設計目標就會被逐漸稀釋。


3.2 人在補充需求時,往往是“局部視角”

在多輪對話中,人通常是在針對當前不滿意的點進行修正,例如:

  • “這裏能不能換成異步?”
  • “這個字段我不想要了”
  • “這個函數再加一個參數”

但問題在於:

  • 這些修改可能影響其它模塊
  • AI 並不知道你是否接受連帶變化
  • 你自己也未必在當下考慮到了所有影響

最終就會出現:

  • 功能能跑
  • 結構卻越來越奇怪

3.3 模型限制 + 問題拆解方式的疊加效應

偏離預期,往往不是單一原因造成的,而是:

  • 模型在長對話中的抽象能力下降
  • 人在提問時逐漸變成“修 bug 式提問”
  • 缺乏一次“全局視角”的重新校準

這三點疊加在一起,就很容易讓結果走偏。


四、更推薦的使用方式:少輪次 + 高質量輸入

4.1 一次性描述清楚“核心需求”

這裏説的“一次性”,並不是要求把所有細節都寫死,而是至少要説明清楚:

  • 這個模塊/系統要解決什麼問題
  • 有哪些核心功能
  • 功能之間是否有關聯
  • 哪些點是不能隨意改動的約束

示例思路:

我要實現一個 XXX 系統,主要包含 A / B / C 三個功能。
其中:
- A 和 B 之間存在依賴關係
- C 的實現不能影響 A 的調用方式
- 性能優先級高於代碼簡潔性

4.2 接受“非核心問題”的逐步優化

在一次高質量描述後,AI 生成的結果通常會:

  • 核心結構基本正確
  • 功能邏輯大體符合預期
  • 細節上存在一些小問題

這些小問題通常包括:

  • 命名不夠優雅
  • 局部代碼不夠簡潔
  • 樣式或美觀問題

👉 這些問題是適合通過“少量追加對話”來優化的。


五、什麼時候應該“停止對話,重新編輯問題”?

這是一個非常關鍵的判斷點。

5.1 明確應該重來的一些信號

如果出現以下情況之一,強烈建議重新編輯需求,而不是繼續對話修補

  • 新需求會影響多個已有功能
  • 修改一個功能,會連帶影響其它模塊
  • 你發現自己在“打補丁”而不是在設計
  • 你已經很難用一句話説明當前代碼結構

此時繼續對話,大概率只會讓問題更復雜。


5.2 正確的做法

更好的方式是:

  1. 停止當前對話
  2. 回顧當前代碼和真實需求
  3. 新的對話中重新整理描述
  4. 把之前暴露出的缺陷明確寫進去

例如:

在之前的實現中,我發現 A 和 B 的設計存在耦合問題。
這次希望:
- 明確拆分 A / B 的職責
- 保證後續擴展 C 功能時不需要修改 A

六、關於“一次性描述”和“靈活調整”的平衡

需要強調的是:

減少對話輪次 ≠ 一次性把一切寫到極致完美

更合理的平衡是:

  • 核心設計、關鍵約束:一次説明清楚
  • 非核心細節、體驗優化:允許少量調整
  • 結構性缺陷、系統性問題:直接重來

把 AI 當成一個:

執行能力很強,但不具備全局自省能力的助手

而不是一個會自動“幫你糾偏”的高級工程師。


七、總結

結合自己的實際使用經驗,我目前形成的結論是:

  1. AI 編程工具非常依賴輸入質量
  2. 對話輪次越多,越容易偏離最初目標
  3. 核心問題應一次性描述清楚
  4. 結構性問題不要通過“補丁式對話”修復
  5. 重新編輯問題,往往比繼續對話更高效

後續我也會結合具體案例(包括錯誤示範和正確示範)進一步補充説明。


這篇文章並不是否定多輪對話的價值,而是希望在合適的場景下,用更合理的方式使用 AI。

user avatar
0 位用戶收藏了這個故事!

發佈 評論

Some HTML is okay.