---
title: "正確的使用方法"
date: "2026-02"
category: "ai運用"
tags: ["ai運用"]
description: "我覺得運用LLM的關鍵點是讓自己跳脫出單純的寫程式碼這樣的固化思維——將自己作為一個規劃任務的主管，或者是微操大師去監察任務，而不是單純的讓自己成為一個局外人..."
source: "https://enriquemark.com/zh-hant/posts/%E6%AD%A3%E7%A1%AE%E7%9A%84%E4%BD%BF%E7%94%A8%E6%96%B9%E6%B3%95"
---

我覺得運用LLM的關鍵點是讓自己跳脫出單純的寫程式碼這樣的固化思維——將自己作為一個規劃任務的主管，或者是微操大師去監察任務，而不是單純的讓自己成為一個局外人。這一切都建立在對專案和設計、架構、技術的理解之上。我的確可以不懂所謂的「具體程式碼」怎麼實現，但我必須關注「輸入」了什麼，以及「輸出」了什麼，其次則是「安全」與「效能」。作為技術主管，我當然需要對我要求員工使用的技術，至少有足夠的瞭解。

小模組，精確的提示（明確的指向特定函式模組以及操作邏輯，這本身就需要人類對專案的理解），架構設計——可以避免完全交給ai帶來的上下文缺失和維護地獄。尤其是要以vibe工程的思維來考量，測試和謹慎也必不可少。

今天的debug的經歷是很有意思的，完全的把問題仍給ai並不能解決問題，最後還是我自己找了半天，做了斷點測試，把問題源頭定位出來，明確的給了指令讓他去修復——而且一開始居然給了一個很複雜的重構方案明明只要出口封裝一個str輸出就夠了，他卻跟我說要把三個模組重構才能才把問題解決，這明顯是一個問題。

而且有一點我的確是贊同的，用ai的時候會給人一種虛假的掌握感，一旦遇到了ai解決不了的問題就會無助，甚至是焦慮和憤怒。尤其是ai寫的程式碼我幾乎看不懂的情況之下，這就非常成問題。所以對業務邏輯和專案的理解是至關重要的，所以我認為最謹慎的ai應用方式就是明確的指定「應該如何，以及用什麼方法寫」，精確到類是最好的。他的確不如直接全部交給ai要來得那麼快，但也至少提升了百分之二三十的效率。尤其是考慮到未來可能遇到的維護地獄，人工設計的結構是建立在對專案的充分掌握之上，因此出問題至少不會毫無頭緒。ai有些時候會對錯誤進行過於完美的包裝，導致出現問題都不知道到哪裡去定位，因此測試和可維護的設計非常重要。

Bash非常靈活，可以藉助此而呼叫已有的命令列功能。