站長阿川

站長阿川私房教材:
學 JavaScript 前端,帶作品集去面試!

站長精心設計,帶你實作 63 個小專案,得到作品集!

立即開始免費試讀!

介紹

大家好,我是 Shota,是工程師和講師。

作為一名工程師,我通常透過將AI工具應用於實際專案來開發它們;同時,作為一名講師,我將所獲得的知識系統化並與學生分享。

這是在將 AI 工具應用於實際專案之前您應該了解的一系列實用技巧的第五篇,也是最後一篇。本期的主題是「遊標提示 x 程式碼發布(在實際專案中使用)!第三部分:總結」。

本文摘自我提供的免費人工智慧驅動開發實作課程,該課程基於從實際開發工作中獲得的見解。

回顧上一篇文章

在前兩篇文章中,我們確認了以下兩點在使用AI工具進行bug修復和重建時是有效的:

  • 任務分解-將複雜的修復分解成更小的部分

  • 指定文件名-使用@符號明確指定要更正的文件

它之所以有效,原因如下:

✅ 細分任務的效果

  • 將大任務分解成單獨的子任務,使AI能夠準確地理解每個修正

  • 可以逐步檢查修正,最大限度地減少返工

  • 每個修復的影響範圍清晰且易於審查

✅ 指定檔案名稱的效果

  • @透過指定檔名,AI將準確地辨識需要修正的文件

  • 整改目標明確,整改落實到位。

然而我們發現,這項技術只是AI驅動開發實作課程中學習的七種方法之一

那麼,這七種方法的概述是怎麼樣的呢?這種方法的定位是什麼?其他六種方法的具體內容又是什麼?

七種方法概述

這是關於如何指導AI實現開發生產力和品質的總結。

以下說明是根據每種方法應在哪個開發過程中使用的方法來組織的。

影像.png

當談到指導人工智慧時,該過程大致可以分為三個步驟:

①準備 → ②指示 → ③確認

七種方法的定位是: ②教學過程中的具體教學方法

在前兩篇文章中,我們展示了對AI工具的實際指令,以及依照指令方法修改後的程式碼,作為修復bug和重構的技巧。

重構和錯誤修復中使用的方法的定位

事實上,最後兩次錯誤修復和重構都是使用「批量修復方法」對七個方法進行實際程式碼修復的情況

影像.png

每種方法都進行了詳細的解釋,以便能夠在實際案例中實踐。例如,批量校正方法的解釋如下:

[@ファイル名] + 
[コーディング規約 (オプション)] + 
[修正方針] 
で修正を依頼する

實際用例

我們如何使用這種方法來解決這個問題?例如,在兩篇文章之前的重構範例中:

迅速的:

@client/src/components/task-list.tsx
@client/src/components/task-dialog.tsx
@client/src/components/task-card.tsx

これらのファイルのエラー処理ロジック(エラーコードに応じたメッセージ設定)を@client/src/lib/error-utils.tsに共通関数化し、
各ファイルから共通関数を呼び出すよう修正してください。

修正結果:

// 修正前
} catch (error) {
  let title = "エラーが発生しました";
  let description: string;

  if (error instanceof Error) { // ❌ 重複したエラー処理
    if (error.message === ERROR_CODES.NOTFOUND_ERROR) {
      description = "対象のタスクが見つかりません。一覧を更新して最新情報をご確認ください。";
    } else if (error.message === ERROR_CODES.SERVER_ERROR) {
      description = "サーバーエラーが発生しました。しばらく経ってから再試行してください。";
    } else {
      description = "タスクの保存に失敗しました。ネットワーク接続を確認して再試行してください。";
    }
  }
}

// 修正後
} catch (error) {
  const { title, description } = getErrorMessage(error, "タスクの保存"); // ✅ 共通関数化
}

溝通結構

怎麼說呢:

[@ファイル名] + 
[コーディング規約 (オプション)] + 
[修正方針] 
で修正を依頼する

迅速的:

@client/src/components/task-list.tsx
@client/src/components/task-dialog.tsx
@client/src/components/task-card.tsx

これらのファイルのエラー処理ロジック(エラーコードに応じたメッセージ設定)を@client/src/lib/error-utils.tsに共通関数化し、
各ファイルから共通関数を呼び出すよう修正してください。

將上述內容與實際提示進行比較:

  • [@filename]是部分@client/src/components/task-list.tsx...

  • 【修改策略】これらのファイルのエラー処理ロジック(エラーコードに応じたメッセージ設定)を...

編碼約定是可選的,可以指定,但由於每次都指定比較麻煩,所以我們在AI工具本身中設定。這些設定被稱為自訂規則,具體的設定方法在課程中介紹。

任務細分與七種方法的關係

在前兩篇文章中,我們解釋了在向AI發出指令時需要牢記的兩個有效要點:

  • 任務分解-將複雜的修復分解成更小的部分

  • 指定文件名-使用@符號明確指定要更正的文件

你可能會想,如果後者的檔案名稱規範是通訊的[@ファイル名]部分的一部分,那麼前面關於分解任務的討論在通訊部分中去了哪裡?

事實上,任務細分並不包含在這七種方法中。

這是因為,如上節所述,七種方法是將①準備→②指示→③確認這②指示過程概括出來,而任務細分的討論則是針對①準備過程,即發出指示之前的準備階段。

簡而言之,如果你在指導AI之前將任務分解成更小的部分,然後使用這七種方法來指導AI,它將能夠快速準確地工作,這意味著你可以同時實現開發的生產力和品質。

其他 6 種方法的詳細訊息

方法概述

我們再來回顧一下這七種方法的概述。現在,我們再來看一種更具體的方法。

資料流方法

這是一種提問方法,可以幫助您快速了解應用程式的資料流,以便在程式碼審查期間簡化程式碼理解。

影像.png

尤其:

[機能名] +
[アーキテクチャー]
で説明を依頼する

我會以這種格式詢問。

具體提示和人工智慧答案

迅速的:

タスク一覧表示機能のデータフローを、
下記のアーキテクチャに基づいて、
具体的なファイル名やコンポーネント名
などを踏まえて説明してください。

Frontend (React)
  - UI
  - Business Logic
  - API Access

Backend (Express + Drizzle ORM)
  - API EndPoint
  - Business Logic
  - Data Access

Database (PostgreSQL)
  - Table

人工智慧答案:

タスク一覧表示機能のデータフローは、以下のアーキテクチャに基づいて説明できます:

Frontend (React)
  - UI
    - コンポーネント名: TaskList(task-list.tsx)
    - タスクの一覧を表示するために、Reactのコンポーネントとして実装されています。TaskCard(task-card.tsx)コンポーネントを利用して、各タスクの詳細を表示します。
  - Business Logic
    - React Queryを使用してAPIからタスクデータを取得し、ローディング状態を管理します。
  - API Access
    - タスクデータの取得はuseQueryを用いて行われ、APIエンドポイント/api/tasksへのリクエストを通じてデータを取得します。

Backend (Express + Drizzle ORM)
  - API Endpoint
    - ファイル名: server/routes.ts(routes.ts)
    - タスクの取得、作成、更新、削除を処理するAPIエンドポイントを定義しています。GET /api/tasksエンドポイントがタスク一覧の取得を担当しています。
  - Business Logic
    - 各APIエンドポイントのロジック(例:タスクの取得)はこのファイル内で実装され、データベースからのデータ取得やエラーハンドリングを行います。
  - Data Access
    - drizzle-ormを使用してデータベースアクセスを行い、タスクデータに対するCRUD操作を行います。

Database (PostgreSQL)
  - Table
    - テーブル名: tasks(schema.ts)
    - タスクの情報を格納するtasksテーブルが定義されています。カラムにはid, title, description, status, created_at, updated_atが含まれます。statusはタスクの状態(未着手、進行中、完了)を表します。

このように、フロントエンドからバックエンド、そしてデータベースまで、タスク一覧表示機能はコンポーネントやエンドポイントを介してスムーズにデータを流通させ、ユーザーにタスク情報を表示する仕組みになっています。

與批量校正方法類似,資料流方法具有明確定義的通訊結構:

溝通結構

怎麼說呢:

[機能名] + 
[アーキテクチャー]
で説明を依頼する

迅速的:

タスク一覧表示機能のデータフローを、
下記のアーキテクチャに基づいて、
具体的なファイル名やコンポーネント名
などを踏まえて説明してください。

Frontend (React)
  - UI
  - Business Logic
  - API Access

Backend (Express + Drizzle ORM)
  - API EndPoint
  - Business Logic
  - Data Access

Database (PostgreSQL)
  - Table

將上述內容與實際提示進行比較:

  • [函數名稱]タスク一覧表示機能のデータフロー

  • [架構]下記のアーキテクチャに基づいて...

首先了解資料流的重要性

之所以稱為資料流,是因為應用程式處理的本質是一系列的資料流:①輸入資料→②資料轉換→③輸出資料

了解每個架構元素如何轉換資料以及資料如何流經它將幫助您有效地理解應用程式規格。

此外,這些提問方法都是有組織的,可以逐步加深理解

  • 資料流方法理解整個應用程式

  • 使用文件方法了解特定文件

  • 使用區塊方法理解特定元件和功能的作用

  • 使用邏輯方法理解特定過程的細節

這就是過程。

如何有效運用提問

AI 工具具有一項功能,可讓您選擇程式碼、右鍵單擊並要求對程式碼進行解釋,但是為什麼在提出問題時您要費心自己指定函數名稱或架構呢?

通常,程式碼解釋功能可以透過選擇程式碼來指定“解釋什麼”,但無法指定“如何解釋”。因此,解釋方式取決於工具的預設功能,通常從程式角度進行解釋(解釋語言功能和語法)。

另一方面,使用資料流方法和其他方法,雖然需要花時間在提示中指定要解釋“什麼”,但提示可以清楚地說明“如何”解釋,讓使用者無論其技術知識水平如何都能快速獲得對功能本質的理解。

當然,如果預設的程式碼解釋功能能夠幫助你理解程式碼,那麼使用它也是非常有效的。此外,你不需要按順序使用所有方法,只針對不確定的部分提問也是非常有效的

以上就是我們對七種方法的介紹,包括兩篇文章中介紹的批量校正方法以及資料流方法。希望這些資訊對您有所幫助。

其他方法

除了這些方法之外,AI驅動開發實作課程也教你以下方法:

  • 六項要求

  • 相位法

  • 資料流方法

  • 文件方法

  • 塊方法

  • 邏輯方法

  • 批量校正方法

透過使用圖表和表格的解釋性影片來了解這些方法背後的理論之後,您就可以透過使用動手實作影片親自向AI工具發出指令來練習整個應用程式開發過程。

透過理論學習和實際應用開發實踐,您將獲得可以在工作場所使用的真正實用技能。

概括

透過本系列技巧,我們了解了以下內容:

有效AI指令的基本結構

①準備(分解任務)→ ②指示(7種方法)→ ③確認

每一步都很重要,七種方法的系統指導是成功的關鍵

經過驗證的方法的多功能性

  • 大量修復對於重構和錯誤修復都非常有效

  • @filename + 修訂策略的簡單結構可用於各種情況

系統化方法的重要性

  • 整個開發過程採用系統方法,而非一次性技術

  • 每種方法協同工作以實現開發生產力和品質。

對於那些想要了解更多的人

本文內容節錄自《 AI驅動開發實戰課程》。

本課程將透過結構化理論和實踐培訓相結合的方式為您提供由人工智慧驅動的開發技能:

理論大師

掌握加速人工智慧驅動發展的七種方法。

透過圖表和表格進行詳細的理論解釋,讓您有系統地了解每種方法的結構和用法。

實踐培訓

從需求定義到開發真實應用程式的測試的實踐、端到端流程。

需求定義過程

  • 透過使用六個要求的氛圍編碼與人工智慧代理進行有效的需求協調

  • 使用階段方法劃分範圍可以逐步實現開發請求並最大限度地減少返工

  • 以人工智慧易於理解的方式傳達需求,確保如預期實施

程式碼審查流程

  • 使用資料流方法快速了解整個應用程式架構

  • 使用檔案方法、區塊方法和邏輯方法逐步了解程式碼細節

  • 從前端(React)到後端(Express + Drizzle ORM)到資料庫(PostgreSQL)的高效審核

程式碼修復流程

  • 透過使用批量修復方法加入 JSDoc 註釋來提高可讀性

  • 透過統一 API 呼叫處理和使用批次修正方法的標準化錯誤處理提高了可維護性

  • 透過非同步處理錯誤處理和 HTTP 狀態程式碼支援提高應用程式穩定性

測試流程

  • 全端測試全面驗證所有應用程式功能

  • 使用批次修復方法修復了測試期間偵測到的錯誤(資源存在性檢查不足、驗證檢查不足)。

  • 透過測試和修復錯誤週期實現實際品質改進

透過在各個工序中實際運用這七種方法,並指示AI進行開發,將理論轉化為實務技能,獲得兼顧生產力和品質的實務技能。

我們想透過與你們分享一條特別的訊息來表達對你們所有人的感激之情。

紀念200名付費會員

感謝你們,《AI驅動開發實戰課》付費會員數已突破200人。

為了感謝觀看我們五篇實用技巧系列的所有人,我們將贈送特別優惠券。

特價優惠券訊息

【僅限前20名】2萬日圓優惠券

  • 為慶祝會員人數達200人,將有20人享有20,000日圓的折扣!

  • 原價:39,800日圓 → 19,800日圓

  • 在此處獲取優惠券

【截止8月底】立減10,000日圓優惠券

注意事項

  • 此優惠券僅限前 20 人使用,一旦達到限額,優惠券將失效。

  • 優惠券不可組合使用。

  • 優惠券不得轉讓或轉售。

課程詳情在這裡

這是實用技巧系列的最後一期。非常感謝您連續五期的關注。如果您覺得這篇文章對您有幫助,請按讚。我們會繼續提供有用的訊息,希望您繼續關注我們。


原文出處:https://qiita.com/ShotaFukuyama/items/496f3021f122621591a7


共有 0 則留言


精選技術文章翻譯,幫助開發者持續吸收新知。
站長阿川

站長阿川私房教材:
學 JavaScript 前端,帶作品集去面試!

站長精心設計,帶你實作 63 個小專案,得到作品集!

立即開始免費試讀!