ตรวจโค้ดที่ AI เขียนอย่างไร: จับบั๊กด้วย 8 Tests ก่อนใช้งานจริง

วิธีตรวจโค้ดที่ AI เขียน คือกำหนดผลที่ต้องได้ก่อน อ่านส่วนที่เปลี่ยน แล้วรันทดสอบทั้งกรณีปกติ กรณีขอบเขต และข้อมูลผิดรูป จากนั้นตรวจสิทธิ์ ข้อมูล และแพ็กเกจที่เพิ่มเข้ามา เก็บคำสั่งกับผลรันไว้ให้คนอื่นทำซ้ำได้ หากยังไม่มีหลักฐานในส่วนใด ให้ระบุว่า “ยังไม่ตรวจ” แทนการรับรองทั้งระบบ

คู่มือนี้พาทำตัวอย่าง Python สั้น ๆ ตั้งแต่โค้ดมีบั๊กจนแก้ผ่านชุดทดสอบ พร้อมเฉลยที่จงใจเขียนผิดเพื่อให้เห็นว่า Tests สีเขียวอาจทำให้มั่นใจผิดได้ เหมาะกับคนเริ่มใช้ AI ช่วยเขียนโปรแกรมและคนรับงานจาก AI Coding Agent

ขอบเขตตัวอย่าง: เป็นสถานการณ์จำลองเพื่อการสอนที่จัดทำขึ้นสำหรับบทความนี้ จงใจใส่บั๊กและรันทดสอบจริงแบบออฟไลน์ ไม่ใช่ผลลัพธ์จากโมเดลบุคคลที่สาม ไม่ใช่ Benchmark และไม่ใช่ระบบค่าส่งพร้อมใช้งานจริง

เริ่มจากข้อกำหนด · ลองรันทดสอบ · ตรวจเฉลยของ Tests · เช็กลิสต์ก่อนรับงาน · ลองตัดสิน 3 กรณี

ก่อนตรวจ: ขอหลักฐาน 4 อย่างจาก AI

• ขอบเขตงาน: เปลี่ยนพฤติกรรมอะไร และอะไรต้องเหมือนเดิม
• รายการไฟล์กับ Diff: บรรทัดที่เพิ่ม ลบ หรือแก้ รวมไฟล์ทดสอบและไฟล์ตั้งค่า
• วิธีรัน: รุ่นของภาษา คำสั่งติดตั้งที่จำเป็น และคำสั่งทดสอบ โดยยังไม่รันคำสั่งที่ไม่เข้าใจ
• ผลและข้อจำกัด: Tests ใดผ่าน ล้ม ข้าม หรือยังไม่รัน พร้อมผลจริง ไม่ใช้เพียงข้อความ “ทดสอบแล้ว”

เริ่มจากสำเนางานหรือสภาพแวดล้อมทดสอบที่ไม่มีข้อมูลจริงและกุญแจระบบ การเปิด Tests ก็อาจรันโค้ดของโปรเจกต์ได้ จึงต้องอ่านไฟล์ทดสอบ คำสั่งติดตั้ง และสคริปต์ที่เกี่ยวข้องก่อน บทความนี้ใช้เฉพาะ Python กับ unittest ที่มากับภาษา ไม่มีแพ็กเกจเสริม ไม่มีเครือข่าย และไม่แตะฐานข้อมูล

ขั้นที่ 1: เขียนคำว่า “ถูก” ให้เป็นข้อมูลเข้าและผลที่คาดหวัง

สมมติร้านมีข้อกำหนดค่าส่งดังนี้ เขียนเกณฑ์นี้ก่อนดูคำตอบจากโค้ด เพื่อให้เฉลยอ้างอิงความต้องการของงานได้โดยอิสระ

• อินพุตเป็นยอดรวมหน่วยสตางค์ ชนิดจำนวนเต็มเท่านั้น และต้องไม่ติดลบ
• ยอดตั้งแต่ 50,000 สตางค์ขึ้นไป ส่งฟรี คืนค่า 0
• ยอดต่ำกว่า 50,000 สตางค์ คืนค่าส่ง 4000 หรือ 40 บาท รวมถึงยอดศูนย์ตามกติกาสมมตินี้
• ยอดติดลบต้องเกิด ValueError; ข้อความ ทศนิยม และค่าจริง/เท็จ ต้องเกิด TypeError
• ไม่มีส่วนลด ภาษี พื้นที่จัดส่ง การชำระเงิน หรือการแปลงสกุลเงินในขอบเขตนี้

จุดที่ต้องจับตาคือคำว่า “ตั้งแต่”: ยอด 500 บาทต้องส่งฟรีพอดี จึงควรมีกรณีทดสอบ 499.99, 500 และ 600 บาท การใช้จำนวนเต็มหน่วยสตางค์ช่วยให้ตัวอย่างไม่ต้องตัดสินวิธีปัดเศษทศนิยม แต่ไม่ได้แทนข้อกำหนดเรื่องเงินทั้งหมดของแอปจริง

ขั้นที่ 2: อ่านโค้ดและ Diff ก่อนรัน

สร้างโฟลเดอร์ใหม่สำหรับทดลอง และบันทึกโค้ดต่อไปนี้เป็น shipping.py นี่คือเวอร์ชันที่จงใจใส่บั๊ก อ่านแล้วลองคาดเดาว่าอินพุตใดจะเปิดเผยปัญหา

"""Teaching simulation: deliberately buggy, not production code."""


def shipping_fee(subtotal_satang):
    if type(subtotal_satang) is not int:
        raise TypeError("subtotal_satang must be an integer")
    if subtotal_satang < 0:
        raise ValueError("subtotal_satang must be non-negative")
    return 0 if subtotal_satang > 50000 else 4000

type(...) is not int ในตัวอย่างนี้ตั้งใจใช้สัญญาข้อมูลแบบเข้มงวดเพื่อปฏิเสธ True, False และทศนิยมด้วย ส่วนบรรทัดคืนค่าต้องนำไปเทียบกับข้อกำหนด ไม่ควรตัดสินจากความสั้นหรือความอ่านง่ายของโค้ด

ถ้าใช้ Git ให้เริ่มดู git diff สำหรับส่วนที่ยังไม่ Stage และ git diff --cached สำหรับส่วนที่ Stage แล้ว ตรวจ git status --short ด้วยเพื่อไม่พลาดไฟล์ใหม่ที่ยังไม่ถูกติดตาม คำสั่ง git diff --check ช่วยพบปัญหา whitespace หรือเครื่องหมาย conflict บางกรณี แต่ไม่ได้ตรวจตรรกะของโปรแกรม ตาม เอกสาร git diff

ขั้นที่ 3: รัน happy path แล้วเพิ่มกรณีที่อาจทำให้โค้ดผิด

ต้องมี Python 3 อยู่แล้ว เปิด Terminal ในโฟลเดอร์ทดลอง ตรวจด้วย python3 --version หากเครื่องใช้ชื่อคำสั่ง python ให้ตรวจว่าเป็น Python 3 แล้วใช้ชื่อนั้นแทนทุกจุด จากนั้นสร้างไฟล์ test_shipping.py ไว้ข้าง shipping.py และคัดลอกชุดทดสอบนี้

import unittest

from shipping import shipping_fee


class ShippingTests(unittest.TestCase):
    def test_normal(self):
        self.assertEqual(shipping_fee(60000), 0)

    def test_at_threshold(self):
        self.assertEqual(shipping_fee(50000), 0)

    def test_below_threshold(self):
        self.assertEqual(shipping_fee(49999), 4000)

    def test_zero(self):
        self.assertEqual(shipping_fee(0), 4000)

    def test_negative(self):
        with self.assertRaises(ValueError):
            shipping_fee(-1)

    def test_text(self):
        with self.assertRaises(TypeError):
            shipping_fee("50000")

    def test_boolean(self):
        with self.assertRaises(TypeError):
            shipping_fee(True)

    def test_float(self):
        with self.assertRaises(TypeError):
            shipping_fee(50000.0)

ค่าที่คาดหวังใน assertEqual มาจากข้อกำหนด ส่วน assertRaises ตรวจชนิดข้อผิดพลาดที่ต้องเกิด การใช้ unittest และการรันรายกรณีดูเพิ่มได้ใน เอกสาร Python unittest

เริ่มรันเฉพาะกรณีปกติที่ยอด 600 บาทก่อน:

python3 -m unittest -v test_shipping.ShippingTests.test_normal

ผลที่คาดหวังและพบจริงก่อนแก้: Ran 1 test และ OK เพราะทั้งเงื่อนไข “มากกว่า” และ “ตั้งแต่” ให้ผลเหมือนกันที่ยอดนี้ แต่เรายังไม่เคยตรวจยอด 500 บาทพอดี

ต่อไปรันครบทั้ง 8 กรณี:

python3 -m unittest -v test_shipping

ผลที่พบจริงก่อนแก้: ผ่าน 7 กรณีและล้ม 1 กรณี ด้านล่างตัดเวลาและตำแหน่งไฟล์ออกเพื่อให้อ่านง่าย ข้อความสำคัญยังตรงกับผลรัน

FAIL: test_at_threshold
AssertionError: 4000 != 0
Ran 8 tests
FAILED (failures=1)

แปลผล: เราป้อน 50000 และคาดหวัง 0 แต่โค้ดคืน 4000 จึงพบหลักฐานว่าพฤติกรรมหนึ่งผิดข้อกำหนดแล้ว ไม่ต้องถกกันว่าโค้ด “ดูเหมือนถูกต้อง” หรือ AI อธิบายได้น่าเชื่อถือเพียงใด

ขั้นที่ 4: แก้ให้น้อย แล้วรันชุดเดิมซ้ำ

เปลี่ยนเฉพาะบรรทัดสุดท้ายของฟังก์ชันใน shipping.py โดยใช้ >= แทน > Diff ของตรรกะเป็นดังนี้ เครื่องหมาย - คือบรรทัดเดิม และ + คือบรรทัดใหม่ ไม่ต้องคัดลอกสองเครื่องหมายนี้ลงไฟล์

-    return 0 if subtotal_satang > 50000 else 4000
+    return 0 if subtotal_satang >= 50000 else 4000

บรรทัดใหม่ที่คัดลอกแทนได้:

    return 0 if subtotal_satang >= 50000 else 4000

ใช้คำสั่ง python3 -m unittest -v test_shipping เดิมอีกครั้ง โดยไม่ลดจำนวน Tests และไม่แก้เฉลยเพื่อให้ผ่าน

Ran 8 tests
OK

ผลที่พบจริงหลังแก้: ผ่าน 8/8 กรณีบน Python 3.12.14 ในสภาพแวดล้อมออฟไลน์ วันที่ 12 ตุลาคม 2026 (UTC) ข้อสรุปที่รองรับคือ “เวอร์ชันแก้ผ่านข้อกำหนดที่ตรวจใน 8 กรณีนี้” ยังไม่ใช่ข้อสรุปเรื่องความถูกต้องหรือความปลอดภัยของซอฟต์แวร์ทั้งระบบ

ขั้นที่ 5: ตรวจเฉลยของ Tests ด้วย

Test oracle คือเกณฑ์ที่ใช้ตัดสินว่าผลลัพธ์ถูกหรือผิด ในตัวอย่างนี้คือข้อกำหนดค่าส่งกับค่าที่ใส่ใน assertEqual หากเฉลยผิด โค้ดผิดก็อาจผ่านได้ ลองสร้าง bad_oracle_demo.py ในโฟลเดอร์เดียวกัน

"""Deliberately wrong expectation. Run explicitly; not a valid acceptance test."""

import unittest

from shipping import shipping_fee


class WrongExpectation(unittest.TestCase):
    def test_wrong_threshold_expectation(self):
        self.assertEqual(shipping_fee(50000), 4000)

ไฟล์นี้จงใจใส่เฉลยผิด ห้ามใช้เป็นเกณฑ์รับงาน: ที่ยอด 500 บาท ข้อกำหนดให้ส่งฟรี แต่ Test กลับคาดหวังค่าส่ง 40 บาท รันเพื่อสังเกตความผิดพลาดด้วยคำสั่งต่อไปนี้

python3 -m unittest -v bad_oracle_demo

• เมื่อใช้โค้ดเวอร์ชันบั๊ก: Test เฉลยผิดนี้ผ่าน 1/1 เพราะทั้งโค้ดและเฉลยผิดไปทางเดียวกัน
• เมื่อใช้โค้ดที่แก้แล้ว: Test เฉลยผิดนี้ล้ม 1/1 และแสดง AssertionError: 0 != 4000
• คำตัดสิน: ต้องแก้เฉลยตามข้อกำหนด ไม่ย้อนโค้ดที่ถูกให้กลับไปผิดเพื่อให้ทุก Test เป็นสีเขียว

ผลทั้งสองแบบข้างต้นรันจริงแยกจากชุดตรวจรับ 8 กรณี อย่าให้ผู้เขียนโค้ดแก้ข้อกำหนดหรือเปลี่ยนเฉลยโดยไม่มีเหตุผลและผู้ตรวจเห็นชอบ สำหรับงานจริงให้เก็บกรณีทดสอบจากปัญหาที่เคยพบ และให้เจ้าของงานตรวจตัวอย่างผลที่คาดหวังด้วย

เช็กลิสต์ตรวจโค้ด AI ก่อนรับงานจริง

นำขั้นตอนทดลองไปใช้กับงานจริงได้ แต่ต้องเพิ่มการตรวจตามความเสี่ยงของงานแต่ละชิ้น รายการต่อไปนี้เป็นจุดตั้งต้น ไม่ใช่ใบรับรองความปลอดภัย

• พฤติกรรม: มีอินพุตและผลที่คาดหวังหรือยัง? ตรวจกรณีปกติ ค่าพอดีขอบเขต ค่าว่าง ข้อมูลผิดรูป และข้อผิดพลาดที่เคยเกิด หากมี Retry ให้ตรวจว่ากดซ้ำหรือส่งซ้ำแล้วไม่เกิดรายการซ้ำ
• สิทธิ์และความปลอดภัย: ผู้ไม่มีสิทธิ์เข้าถึงข้อมูลหรือสั่งงานได้หรือไม่? ฝั่งเซิร์ฟเวอร์ตรวจสิทธิ์ด้วยหรือพึ่งการซ่อนปุ่ม? มีการนำอินพุตไปต่อคำสั่ง SQL, Shell หรือ HTML โดยไม่มีวิธีจัดการที่เหมาะกับบริบทหรือไม่? งาน Login, Payment และข้อมูลส่วนตัวควรมีผู้เชี่ยวชาญตรวจเพิ่ม
• Dependencies: AI เพิ่มแพ็กเกจอะไร ทำไมต้องใช้ และมีแพ็กเกจนั้นจริงในแหล่งทางการหรือไม่? อ่านชื่อ รุ่น License ไฟล์ Lock และสคริปต์ติดตั้ง ตรวจประกาศช่องโหว่ที่เกี่ยวข้อง แล้วทดสอบการเปลี่ยนรุ่นในสภาพแวดล้อมทดสอบ
• ข้อมูลและผลข้างเคียง: โค้ดอ่าน เขียน ส่งออก หรือลบข้อมูลใด? บันทึกข้อมูลลับลง Log หรือไม่? ทดสอบด้วยข้อมูลสังเคราะห์ กำหนดปลายทางให้ชัด และขอดูวิธีกู้คืนก่อนงานที่เปลี่ยนข้อมูล
• ขอบเขตและหลักฐาน: Diff มีไฟล์นอกงานหรือเปลี่ยน Tests ให้ยอมรับพฤติกรรมใหม่หรือไม่? คำสั่งรันใช้กับโค้ดรุ่นเดียวกับที่ส่งจริงหรือเปล่า? เก็บผลล้ม ผลหลังแก้ รายการที่ยังไม่ตรวจ และผู้รับผิดชอบตัดสินใจก่อนนำขึ้นระบบ

หลักการตรวจความปลอดภัยอ้างอิง OWASP Secure Code Review ซึ่งวางการตรวจโดยมนุษย์คู่กับเครื่องมืออัตโนมัติ โดยเฉพาะตรรกะธุรกิจและบริบทของระบบ ส่วนการประเมินและแก้ปัญหาแพ็กเกจดู OWASP Vulnerable Dependency Management ผลสแกนไม่พบช่องโหว่ยังมีขอบเขตตามข้อมูลและวิธีตรวจที่เครื่องมือใช้

ลองตัดสิน 3 กรณีก่อนเปิดเฉลย

อ่านสถานการณ์แล้วเลือกในใจว่า “รับได้ในขอบเขตนี้”, “ส่งกลับแก้”, หรือ “หลักฐานไม่พอ” จากนั้นแตะหัวข้อเพื่อเปิดเฉลย ทั้งสามข้อเป็นสถานการณ์สมมติที่กำหนดคำตอบไว้ ไม่มี AI ตอบสด ไม่มีการรันโค้ดหรือส่งข้อมูลออกจากกล่องนี้

กรณีที่ 1: ผ่าน Test ยอด 600 บาทหนึ่งข้อ รับงานเลยได้ไหม?

เฉลย: หลักฐานไม่พอ ยังไม่ตรวจยอด 500 บาทพอดีหรือข้อมูลผิดรูป โค้ดตัวอย่างเวอร์ชันบั๊กก็ผ่านข้อนี้ได้ ขั้นต่อไปคือรันชุดกรณีขอบเขตและตรวจ Diff ก่อนตัดสิน

กรณีที่ 2: ยอด 500 บาทได้ค่าส่ง 40 บาท แต่ AI บอกว่าเป็นค่าที่เหมาะสม

เฉลย: ส่งกลับแก้ ขัดข้อกำหนดที่ระบุว่ายอดตั้งแต่ 500 บาทส่งฟรี คำอธิบายของผู้เขียนโค้ดไม่เปลี่ยนข้อกำหนดที่ตกลงไว้ หลักฐานคืออินพุต 50000 ผลจริง 4000 และผลที่คาดหวัง 0

กรณีที่ 3: แก้แล้วผ่าน 8/8 มี Diff และผลรัน แต่ยังไม่ต่อระบบร้าน

เฉลย: รับได้เฉพาะฟังก์ชันจำลองตามเกณฑ์ที่ทดสอบ ยังรับรองแอปทั้งระบบไม่ได้ ต้องตรวจการเชื่อมต่อจริง เช่น ระบบส่งหน่วยบาทหรือสตางค์มาให้ และข้อผิดพลาดแสดงแก่ผู้ใช้อย่างไร ก่อนพิจารณาการใช้งานจริง

ข้อความที่ใช้สั่ง AI ให้ส่งงานแบบตรวจซ้ำได้

ใช้ข้อความนี้ประกอบคำสั่งงาน โดยเติมข้อกำหนดและไฟล์ที่อนุญาตให้เปลี่ยนให้ชัดเจน:

ตรวจโค้ดกับข้อกำหนดที่ให้ก่อนแก้ สรุปไฟล์ที่เปลี่ยนและเหตุผล เพิ่ม Tests สำหรับกรณีปกติ ขอบเขต และข้อมูลผิดรูป โดยอธิบายว่าเฉลยมาจากข้อกำหนดข้อใด ห้ามแก้เกณฑ์หรือข้าม Test เพื่อให้ผ่าน รันในสภาพแวดล้อมทดสอบที่ไม่มีข้อมูลจริง แล้วส่งคำสั่ง รุ่นภาษา ผลก่อนและหลังแก้ และสิ่งที่ยังไม่ตรวจ หากรันไม่ได้ให้บอกตรง ๆ แยกข้อเสนอแก้ไขออกจากการอนุมัติใช้งานจริง

สิ่งที่บทความนี้ตรวจแล้ว และยังไม่ได้ตรวจ

• ตรวจแล้ว: ชุด Python ออฟไลน์ 8 กรณี ก่อนแก้ล้มที่ขอบเขต หลังแก้ผ่านทั้งหมด; happy path เดี่ยวผ่านทั้งที่ยังมีบั๊ก; เฉลยผิดให้ผลชวนเข้าใจผิดตามที่สาธิต
• ยังไม่ได้ตรวจ: แอปจริง API ฐานข้อมูล การยืนยันตัวตน การคิดภาษี/ส่วนลด ความเร็วภายใต้โหลด การทำงานพร้อมกัน และสภาพแวดล้อมของผู้อ่าน
• ไม่ได้อ้างว่า: โค้ดนี้ปลอดภัยทุกด้าน Tests ครอบคลุมทุกอินพุต หรือ AI รุ่นใดเขียนโค้ดได้ดีหรือแย่จากการทดลองนี้

หากงานแตะข้อมูลลูกค้า เงิน สิทธิ์ผู้ใช้ หรือการลบข้อมูล ให้ถือส่วนที่ยังไม่ตรวจเป็นเหตุให้หยุดขอหลักฐานเพิ่ม อย่าแปลว่า “ไม่พบปัญหา” โดยอัตโนมัติ

คำถามที่พบบ่อยเกี่ยวกับการตรวจโค้ดที่ AI เขียน

ให้ AI อีกตัวตรวจโค้ดแทนคนได้ไหม?

ช่วยหาประเด็นเพิ่มได้ แต่ยังต้องตรวจว่าข้อทักท้วงถูกจริงและรันทดสอบเอง AI อาจพลาดบั๊กหรือทักปัญหาที่ไม่มีอยู่ เอกสาร Responsible Use ของ GitHub Copilot ระบุข้อจำกัดทั้งปัญหาที่ตรวจไม่พบ ข้อทักท้วงผิด และข้อเสนอแก้โค้ดที่อาจไม่ถูกต้องหรือไม่ปลอดภัย จึงควรใช้ประกอบการตรวจโดยมนุษย์

เขียนโปรแกรมไม่เก่ง จะเริ่มตรวจตรงไหน?

เริ่มจากเขียนตัวอย่างอินพุตกับผลที่ควรได้ และลองเส้นทางที่ผู้ใช้จะทำจริง ขอให้ AI อธิบาย Diff ทีละส่วนและแสดงหลักฐานรันตามคำสั่ง หากยังอ่านผลข้างเคียง สิทธิ์ หรือการเปลี่ยนข้อมูลไม่ออก ให้ผู้พัฒนาที่เข้าใจระบบช่วยตรวจส่วนนั้นก่อนนำไปใช้

Build ผ่านและ Tests ผ่านทั้งหมด แปลว่า Deploy ได้แล้วหรือยัง?

ต้องดูว่า Tests ตรวจอะไรและรันกับเวอร์ชันใด การผ่านชุดหนึ่งสนับสนุนพฤติกรรมในชุดนั้นเท่านั้น ยังต้องดูการเชื่อมต่อจริง ความปลอดภัย การย้อนกลับ และเกณฑ์ของระบบที่รับงาน ตัวอย่างนี้ผ่าน 8/8 ได้โดยไม่เคยเชื่อมระบบร้านเลย

ถ้า AI บอกว่าทดสอบแล้ว แต่ไม่มีผลรัน ควรทำอย่างไร?

ขอคำสั่งที่ใช้ รุ่นของเครื่องมือ โค้ดรุ่นที่ทดสอบ และผลสำเร็จหรือผิดพลาดที่ตรวจย้อนกลับได้ จากนั้นรันซ้ำในสภาพแวดล้อมที่เหมาะสม หากยังรันไม่ได้ให้บันทึกว่า “ยังไม่ยืนยัน” อย่าเปลี่ยนข้อความรายงานเป็นหลักฐานแทนการทดสอบ

ต้องซื้อเครื่องมือตรวจโค้ด AI เพิ่มไหม?

ตัวอย่างในบทความใช้ Python และ unittest ที่มากับภาษา จึงไม่ต้องซื้อเครื่องมือเพิ่มสำหรับการทดลองนี้ งานจริงควรเลือกชุดทดสอบ ตัวตรวจแบบสถิต และเครื่องมือความปลอดภัยให้ตรงภาษาและความเสี่ยงของโปรเจกต์ การซื้อเครื่องมืออย่างเดียวไม่ได้ทำให้ข้อกำหนดหรือเฉลยถูกต้อง

อ่านต่อ: เชื่อมการตรวจโค้ดกับการรับงาน Agent

ผลจากชุดทดสอบเป็นหลักฐานส่วนหนึ่งของงาน เมื่อต้องรับสิ่งส่งมอบทั้งชุด ให้ใช้เช็กลิสต์ตรวจงาน AI Agent หลังส่งมอบเพื่อรวมผลตรวจและข้อจำกัด หากคำอธิบายโค้ดหรือรายงานอ้างข้อมูลภายนอก ให้ตรวจแหล่ง ตัวเลข และวันที่ด้วยคู่มือตรวจสอบคำตอบ AI

• กรณีทีม AI ถอดโครงสร้างเกมและ Evidence Lab: ดูเหตุผลที่ความคืบหน้าหรือ Build ผ่านยังต้องมีเกณฑ์ตรวจพฤติกรรม
• Loop Engineering สำหรับ AI Coding Agents: นำผลตรวจกลับเข้าวงจรแก้ไขที่มีขอบเขตและจุดหยุด
• 12 Agentic AI Projects: ขยายจากฟังก์ชันเล็กไปสู่ Schema, สิทธิ์, Approval และการกู้คืน
• AI Agent Prompt 7 ชั้น: ออกแบบคำสั่งและเกณฑ์ส่งมอบให้บอก PASS, FAIL และ UNKNOWN ได้

แหล่งข้อมูล: เอกสาร Python, Git, OWASP และ GitHub ที่ลิงก์ไว้รองรับวิธีใช้เครื่องมือและข้อควรระวัง ส่วนข้อกำหนดค่าส่ง โค้ด Tests และสามกรณีฝึกตัดสินเป็นตัวอย่างที่สร้างขึ้นสำหรับคู่มือนี้ ตรวจเอกสารวันที่ 12 ตุลาคม 2026 (UTC)