前言

生成式 AI 和 AI 擴展工具在過去幾年中迅速進化。藉助提示來進行程式碼生成、自動化測試、評審摘要和文檔補完等「過去由人類完成但可以由 AI 協助的任務」確實在不斷增加。

本文的目的不僅僅是介紹工具和功能，而是透過「可以立即使用的 AI 速查表」和「可實踐的自訂腳本範例」，傳遞讓你的工作稍微輕鬆的方法。希望從小的自動化做起，積累使用 AI 的經驗，以便設計出「自己/團隊該如何使用 AI」的方案。

本篇文章的目標讀者是：

• 在編程方面有一定經驗，曾親自使用 IDE 或編輯器的擴展功能。
• 在獲取外部 API 金鑰等設置步驟上無法感到困難，具備一定的工具使用能力。
• 不僅想了解工具，而是尋找「如何將其融入業務」和「能夠效率化的任務」，並有實踐的意願。

如果你對「幾乎從未接觸過代碼」或「安裝工具的設置看起來很麻煩」的感受存在，部分內容可能會略顯困難，但在閱讀中應能獲得一些啟示。

我們公司 Nuco 也發布了其他許多實用文章。如果你有興趣，歡迎來瀏覽我們的組織頁面。同時，Nuco 也在招聘新的同事！有興趣的人可以點擊這裡。

將 AI 融入工作流程的基本策略

僅僅「試用 AI」是不夠的。稍微花些心思，將「應該自動化的部分」和「人類應該做出判斷的部分」整理清楚，就可以最大化工具的優勢。接下來我們將仔細探討這些想法及具體要點。

自動化與手動的區分

按類型作業和例行工作清單

首先，列出你每次「用手做但感到無聊」或「耗時過長」的工作。例如：

• 程式碼格式化（手動執行格式化器、樣式檢查）
• 文檔草案撰寫（規格書/README/CHANGELOG 等）
• 測試模板準備或單元測試的搭建
• 程式碼評審的要點摘要撰寫

這些作業中，許多是可以用自動化工具或腳本來取代的。自動化不僅能節省時間，還能減少人為錯誤，使你能夠專注於「需要思考的任務」而不是例行工作。

“需要人類介入的判斷點”和“AI 可以委派的部分”

不過，將所有事情都交給 AI 並不是最佳方案。準確辨別保留給人類的判斷部分，是成功導入 AI 的關鍵。

人類應該判斷的部分範例：

• 架構或模式選擇等重大設計決策
• UI/UX 的細微感受（用戶的感受）仍需強烈的人類直覺
• 與安全性、法律或隱私相關的決策

另一方面，可以交給 AI 的部分：

• 明確定義的重複性任務（如：文檔的固定部分、日誌輸出等）
• 測試案例的假設生成或類型檢查等可型化任務
• 文本格式化、排版、拼寫檢查及語法修正等輔助工作

進行這種區隔後，可以減少「AI 過度插手導致漏洞」或「評審不斷回退」等“AI 常見失敗”的情況。

模型與工具的選擇

模型比較：回應速度、成本、精確度等

選擇模型是將 AI 融入工作流程的關鍵。雖然都是「提示 → 輸出」，但使用不同的模型時行為可能會有很大差異。

• 確保了解ChatGPT、Gemini、Claude 和本地 LLM各自的特點。一般來說，ChatGPT 在多模式上表現出色，但有時會自信滿滿地犯錯，Gemini 與 Google 的結合很強，但在日語上有一些不自然之處，Claude 在邏輯與上下文理解上表現較好，但無法進行圖片生成。
• 回應速度、回應時間、成本（如：代幣計費、請求單價）以及輸出的質量（正確性 vs 創造性 vs 一致性）之間的平衡至關重要。例如，如果是日誌生成或文檔補完等固定任務，則「注重速度 + 穩定性」會更有優勢。而在需求定義和創意生成方面，則可以容忍一定的波動和多樣性。
• 此外，考慮使用本地 LLM（在內部伺服器或邊緣設備上運行的模型）。在需要減少延遲或防範數據洩露風險的情況下，將本地運行的模型作為備份的情況逐漸增多。

最終的效果會是，保持對「自己的任務需求」與「模型的成本和限制」的意識，就能有效減少選擇迷茫。

擴展功能/插件的選擇要點

若模型是“內核”，那麼擴展功能或插件則會大大影響“使用體驗”。透過以下的視角來選擇，可以顯著減少實施後的壓力。

• 持續維護狀態：更新頻率、錯誤修正歷史、開發者反饋、用戶評價等。被放置的插件未來可能會引發相容性問題。
• 社群支持與實績：檢查 GitHub 星數、問題的互動、用戶反饋等。
• 與 IDE 的整合度：自動補全片段、錯誤檢測、測試生成、即時預覽等，是否能順利與 IDE 的工作流程結合。
• 輕量性與啟動成本：過於繁重的插件會導致啟動時延遲，使人不想使用。
• 設定的細緻程度與自訂性：是否可以根據項目或團隊的風格進行調整。能否關閉不要的功能等。

檢查這些要素後，可以降低選擇那些「運行良好但使用不便」或「未來易出問題」的工具風險。

安全性、隱私與倫理的考量事項

在業務中使用 AI 時，風險管理絕對不能忽視。這裡我們要重點關注三個方面。

數據洩露風險及對策

當企業的機密數據或未公開規格直接嵌入提示中時，可能會遺留在模型運營方或日誌中。為了降低此類風險，可以采取以下措施：

• 不在提示中包含機密數據或個人信息，或者對其進行掩碼或轉換後再發送
• 制定限制輸出日誌保存的政策
• 根據需要考慮運行內部或私有模型

偏見與錯誤信息的輸出防止措施

AI 可能發生「幻覺（虛假或錯誤信息生成）」的情況，要始終保持警覺。為了防止此事故，以下是一些對策建議：

• 設置必須由人類審查輸出的流程
• 在提示中加入明確的指示（如「未提供來源時回答'不明'」或「註明可能包含錯誤」）
• 將輸出進行多模型、多參數的生成並比較、對比結果
• 與外部知識庫（RAG 或 DB 參考）對照檢查生成結果

使用授權、API 利用規約等合約性的法律注意事項

在使用 AI 模型 API 時，必須注意合約和法律上的限制。

• 確認 API 使用規約中的商用與再分配的可否、保存與快取的條件
• 檢查輸出代碼或文檔是否存在著作權風險（如生成類似現有作品的內容）
• 在涉及 GDPR 或個人資料保護法等隱私限制的國家地區，制定數據處理政策

AI 擴展功能和插件速查表

編輯器/IDE 擴展功能

將 AI 自然融入編輯器/IDE 中，能顯著改變日常的編程體驗。接下來將具體介紹現場「立即可用」的擴展功能和集成方法。

程式碼補全/自動補全插件

首先是能不斷提示程式碼建議的補全功能。如今已經成為我們的“夥伴”。

• GitHub Copilot（VSCode）
  GitHub Copilot 作為 VSCode 的擴展，能實現實時的程式碼補全和註解補全。
  如下圖所示，當你試圖創建一個計算機，完成加法後，它會自動給出減法的建議。按下 Tab 鍵即可接受並在程式碼中反映這一建議。

• Gemini Snippets / Gemini Code Assist
  Google 的 Gemini 提供程式碼補全功能的「Gemini Code Assist」，支援 VSCode 和 JetBrains。

• Tabnine
  Tabnine 是廣泛使用的支援多語言的 AI 補全工具。
  特別是當你讓它學習「共用庫名稱」或「函數命名規則」的時候，補全的準確性會提高。

• 提高質量的設定範例

  • 涵蓋整個專案的文件作為參考對像
  • 將補全候選的優先順序設為最近使用的 API 或類別
  • 限制補全的最大標記數或候選數，防止輸出過多不必要的選擇

錯誤檢測/靜態分析的組合

AI 補全十分便利，但也可能提供錯誤的程式碼建議，因此將其與 Linter 或型別檢查器結合使用會發揮強大作用。

• TypeScript + Copilot
  對 AI 補全生成的程式碼執行 TypeScript 的型別檢查，如果出現型別錯誤會自動提出修改建議的擴展也已有存在。
  這種「程式碼支援 + 靜態檢查」的組合，可護航以防止錯誤的發生。

• 利用 AI 協助的修正建議
  可以將「請提供這個錯誤的修正建議」的提示傳遞給 AI 模型，讓其生成修正版本，並將結果用作候選。將 Linter 提示的行作為輸入，獲得改進建議的方式也十分有用。
  此外，經過 AI 訓練的 Lint 工具也被報告能檢測出傳統基於規則的 Linter 無法識別的微妙上下文錯誤。

實例：大規模重構的自動支援
例如 Meta 的 Llama3 與 Google 的程式碼掃描器結合 Lint 進行了數百個文件的重構自動化。在更改程式碼命名規則或 API 簽名等大型任務上，這種自動化能提高效率。

格式化與 Linter 的組合設置

團隊希望統一代碼風格，AI 補全有時可能會忽略這一點，造成不一致，因此還是應和格式化工具和 Linter 結合運作，這樣更好。

• 與 Prettier / Black 整合
  設置讓 AI 補全生成的程式碼在提交之前自動被格式化。通常與 VSCode 的“保存時格式化”功能結合使用是標準做法。

• 與項目特有規範共存
  確定項目規則中的縮寫使用、命名模式、縮排寬度等，並將其反映在 Prettier 或 ESLint 中。理想情況下，AI 補全給出的建議也應與這些規範相符。

例：日文項目中的風格統一
例如，若想將變數名統一為 userName → user_name，則可以設定以抑制原本應使用大小駝峰式的 AI 補全，並利用格式化工具強制修正，這樣就更踏實了。

提示輔助工具和片段管理

提示模板的保存與再利用機制

在每次現場重寫提示的方式雖然能「局部改善」，但不易在整體上推廣。因此，擁有「設計模板結構以便保存和再利用」的機制是相當重要的。

舉例來說，提供以下類型的模板結構會更容易重用。

準備這類模板後，能減少在相似的情況下每次重新構建提示的麻煩，也則能降低錯誤的可能。
市場上還提供了幾種用於保存和再利用的工具。例如 PromptHub 是一個可以管理和共享提示的版本控制平台。
另外，還有 PromptLayer 提供提示追蹤、性能評估和協作功能等一系列工作平台。
利用這些工具，或在自己的輕量片段倉庫中管理（如 Git 管理），對於團隊的重用來說也會格外方便。

提示片段的結構範例

在從模板生成更具體的片段時，統一「說明」、「約束」、「期待格式」的結構會更有效處理。

範例 1：評審摘要用提示片段

說明: 請閱讀 Pull Request 的差異，總結變更的要點。  
約束條件: 將變更要點整理至三點以內，以列舉形式呈現。  

期待的輸出範例：

• 修正內容: 修復了某某功能的缺陷
• 影響範圍: API 回應中有變更
• 注意事項: 注意向後相容性

範例 2：測試生成用提示片段

說明: 請從指定的函數定義生成單元測試模板。  
約束條件: Jest（JavaScript）格式，至少包含兩個極端情況  

期待的輸出範例：

describe("myFunc", () => {
  it("正常情況", () => { ... });
  it("異常情況", () => { ... });
});

對於這些提示片段（輸入確認、測試生成、文檔補完等）進行類別化整理後，就能靈活地根據需要快速調用。

代理型功能與對話式工作流程

除了將 AI 當作輔助使用，若能嵌入“請求協助”的對話型體驗，工作效率將會進一步提升。

聊天代理的整合

將聊天型擴展整合到 IDE 或編輯器內，讓其能接收當前文件的上下文及專案信息。例如，若想要「重構這個函數」或「請解釋這條 SQL 查詢」，可以在聊天中提出請求，獲得對話形式的回應。

有一個研究提出了「Prompt-with-Me」（Prompt-with-Me），目的是在 IDE 中管理和再利用提示，同時參考專案的上下文。
透過這個方案，聊天代理能夠理解「是針對哪個文件的哪個方法」。

定型報告生成、評審摘要、規範書生成等

若把定型作業交給聊天代理處理，能保持動作不停，直接獲得成果。

• 程式碼評審要點提取
  將 Pull Request 的差異傳遞過來，請求其「將變更點/注意事項/影響範圍整理為三點」，即可獲得總結。

• 基於測試失敗日誌生成摘要
  傳遞 CI 日誌的堆疊跟踪及失敗點的提示，詢問「問題出在何處」和「請提供兩個修正建議」，這樣能夠得到不造成停頓的協助。

將這類對話流融入工作流程中，可減少工作中斷，更好地保持進度感。

CI/CD 中的 AI 檢查點

最後，在 Pull Request 或部署之前嵌入 AI 檢查的機制，可以有效促進現場應用的成功。

• PR 前的自動評審協助
  當 PR 被創建時，AI（如 PR-Agent）會分析差異並生成評論建議和重構建議。
  此外，還可以與 GitHub Actions 等集成，自動對 PR 添加評論的方式（如「AI 程式碼評審機器人」）也有實作範例。

• 部署前檢查
  在正式反映之前，可以讓 AI 檢查「生成的程式碼是否存在危險模式」、「輸入驗證是否足夠」等問題，以返還警告，這也是有效的。

自訂腳本/片段集

在「僅依賴擴展功能」無法應對的細緻業務中，藉由腳本來覆蓋的階段。我們在此介紹幾個日常定型作業的便利腳本範例。

日常業務自動化腳本

文件生成/模板初始化腳本

當專案啟動時，手動建立目錄結構及初始文件往往用時不短。這種「初期設置」自動化的腳本非常方便。

範例：JavaScript / Node.js 專案的雛形腳本
例如，可以將以下腳本放置為 init-project.sh，這樣在每次啟動專案時即可一鍵生成基本結構。

#!/usr/bin/env bash

# 引數: 專案名稱
PROJECT_NAME=$1
mkdir $PROJECT_NAME
cd $PROJECT_NAME

# 目錄結構
mkdir src tests scripts

# 初始化 package.json
cat <<EOF > package.json
{
  "name": "${PROJECT_NAME}",
  "version": "0.1.0",
  "main": "src/index.js",
  "scripts": {
    "test": "jest"
  }
}
EOF

# README 和 .gitignore
echo "# ${PROJECT_NAME}" > README.md
echo "node_modules/" > .gitignore

# 測試文件範本
cat <<EOF > tests/sample.test.js
test("sample", () => {
  expect(true).toBeTruthy();
});
EOF

echo "Initialized project: ${PROJECT_NAME}"

運行這個腳本後，src/、tests/、scripts/ 資料夾即會生成，同時 package.json、README.md、.gitignore 及樣本測試也備妥。這樣就能大幅減少在「初始設定上所花的時間」。

框架別的雛形範例

• React 專案：生成 public/、src/、components/、pages/及 TypeScript 設定等
• Python 專案：生成 src/、虛擬環境結構、setup.py 或 pyproject.toml、tests/ 等
• Go 專案：生成 cmd/、pkg/、internal/，包括模塊初始化 go mod init

這類雛形腳本若能設計成「可根據規則各自配置」，再傳遞模板參數會相當便利。

部署前檢查/構建後檢查的自動化

自動化部署或構建後的檢查，能夠有效防範人為錯誤的發生。

構建前或後檢查的腳本範例
例如，對於 JavaScript 專案，準備進行這種檢查的腳本即可。

#!/usr/bin/env bash

# 依賴是否為最新？
npm install

# 構建
npm run build || exit 1

# 靜態分析檢查
npm run lint || exit 1

# 測試
npm test || exit 1

echo "所有檢查均通過。準備部署。"

將此腳本整合到 CI 中，可以強制執行「不通過構建、Lint或測試的代碼不能合併」的流程。

CI 過程範例（GitHub Actions）

name: CI Pipeline
on: [pull_request]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - name: Setup Node.js
        uses: actions/setup-node@v3
        with:
          node-version: 18
      - name: Run predeploy checks
        run: ./scripts/check_before_deploy.sh

如上所示，在 Pull Request 提交時可以進行自動檢查。

格式化、型別轉換和遷移支援腳本

資料格式轉換及結構變更等日常發生的微妙轉換工作也可腳本化，以大幅消減“繁瑣性”。

型別轉換腳本範例
例如，對 JSON 數據中以字串形式存在的數值欄位轉型為數字的簡單 Python 腳本。

import json

with open("data.json", "r") as f:
    arr = json.load(f)

for obj in arr:
    if "age" in obj:
        obj["age"] = int(obj["age"])

with open("out.json", "w") as f:
    json.dump(arr, f, ensure_ascii=False, indent=2)

這種轉換頻繁應用於日誌數據或外部 CSV → JSON 的變換，很方便成為实用工具。

遷移腳本的安全性考量
在執行數據庫的結構變更、欄位新增或型別變更時，以下這些“安全措施”能讓我們更為安心。

• 事前做好備份（如：快照或取得轉儲）
• 如果能進行事務包裝，則設計為能回滾的結構
• 附上變更前後差異檢查的腳本

以下是 PostgreSQL 的遷移腳本雛形範例。

BEGIN;

-- 備份（如：表名_backup）
CREATE TABLE users_backup AS TABLE users;

-- 型別變更範例
ALTER TABLE users
  ALTER COLUMN age TYPE INTEGER USING age::integer;

-- 差異檢查（簡易版）
-- SELECT COUNT(*) FROM users WHERE age IS NULL;

COMMIT;

將此類步驟腳本化後，能大幅降低人為失誤的風險。

使用模型/API 的腳本

將生成 AI “透明地整合” 進你的腳本中，能使其靈活性大幅提升。在這裡我們將介紹從 API 調用到多個提示的自動化執行，再到輸出檢驗的「實用腳本範例」。

ChatGPT/Gemini/Claude API 的調用模板代碼

首先是基本範式。無論是哪個模型，通常都會有認證 → 請求 → 響應處理的流程。

範例：Python + OpenAI（ChatGPT）API 調用範例

import os
from openai import OpenAI

def call_chatgpt(prompt: str) -> str:
    client = OpenAI(api_key=os.getenv("OPENAI_API_KEY"))
    response = client.chat.completions.create(
        model="gpt-4o",  # 指定使用的模型
        messages=[{"role": "user", "content": prompt}],
        temperature=0.2,
    )
    # 回應解析：取出首個回覆部分
    return response.choices[0].message.content

if __name__ == "__main__":
    print(call_chatgpt("你好，今天的天氣如何"))

首先運行此最小組件，然後根據需求再進行擴展即可。

Claude API 調用範例（Python / HTTP 層級）
Claude API 的規範可以參考 Anthropic 公布的“Messages API”範例。

import os
import requests
import json

API_KEY = os.getenv("ANTHROPIC_API_KEY")
URL = "https://api.anthropic.com/v1/messages"
headers = {
    "x-api-key": API_KEY,
    "anthropic-version": "2023-06-01",
    "Content-Type": "application/json",
}

def call_claude(prompt: str) -> str:
    body = {
        "model": "claude-opus-4-1-20250805",
        "messages": [{"role": "user", "content": prompt}],
        "max_tokens": 1024,
        "temperature": 0.0
    }
    resp = requests.post(URL, headers=headers, json=body)
    resp.raise_for_status()
    j = resp.json()
    return j["choices"][0]["message"]["content"]

if __name__ == "__main__":
    print(call_claude("請用日語介紹自己"))

這種方式以 HTTP 層面發送提示，因此也能直接應用到其他語言（如 Node.js、Go 等）。

提示執行自動化（批次處理及 CLI 介面）

不僅僅是單一提示，往往會希望「依序發送多個提示以便獲得整體結果」。這時候 CLI 工具化和批次執行都是相當有用的。

匯集成 CLI 工具的方法（Python + Typer 例）

import typer
from typing import List

app = typer.Typer()

@app.command()
def batch_run(input_file: str):
    # input_file 預期為 JSON 或 YAML 格式，內含提示列表
    import json
    with open(input_file, "r") as f:
        prompts = json.load(f)["prompts"]
    results = []
    for p in prompts:
        out = call_chatgpt(p)
        results.append({"prompt": p, "response": out})
    print(json.dumps(results, ensure_ascii=False, indent=2))

if __name__ == "__main__":
    app()

可以將提示放在文件中，執行 python batch_tool.py batch_run prompts.json，最終可得到 JSON 格式的結果，便於後續處理。

多個提示 → 結果彙總批次的範例
例如，針對自動補完整文檔的提示、評審摘要的提示、測試生成的提示能一連串發送，將回應整合進一份 JSON 中，進而進行差異比較的批次處理。

prompts.json:
{
  "prompts": [
    "請總結這個 PR 的差異。",
    "請為以下函數撰寫單元測試： ...",
    "請調整這份文檔草案，使其更易讀。"
  ]
}

使用這種自動化工具將使日常操作變得相當輕鬆。

原文出處：https://qiita.com/K3n_to_n17/items/ef159340f25a5d0f8fba