[Samsung Electronics] เป็นไปได้หรือไม่กับสถานการณ์ที่ AI พัฒนาเฟิร์มแวร์ MCU ของเครื่องใช้ไฟฟ้าได้ 100%

ชื่อเรื่อง: เป็นไปได้หรือไม่กับสถานการณ์ที่ AI พัฒนาเฟิร์มแวร์ MCU ของเครื่องใช้ไฟฟ้าได้ 100%

ต้นฉบับ: Samsung Tech Blog - https://techblog.samsung.com/blog/article/90

• Samsung Electronics นำ 'Harness Engineering' มาประยุกต์ใช้กับการพัฒนาเฟิร์มแวร์ MCU ของเครื่องใช้ไฟฟ้าในบ้าน (เครื่องดูดควัน) เพื่อทดสอบว่า AI agent จะสามารถสร้างเฟิร์มแวร์ได้ครบ 100% โดยไม่ต้องมีการเขียนโค้ดโดยมนุษย์ ด้วยการวนซ้ำแบบอัตโนมัติในขั้นตอนวางแผน-พัฒนา-ตรวจสอบได้หรือไม่

• ในที่นี้ 'Harness' ไม่ได้หมายถึงการทำให้โมเดลฉลาดขึ้น แต่คือการออกแบบสภาพแวดล้อมการทำงานให้ AI สร้างผลลัพธ์ตามที่ตั้งใจไว้ เช่น ข้อมูลที่จำเป็น ข้อห้าม วงจรตรวจสอบตนเอง โครงสร้างโฟลเดอร์ เอกสารสเปก มาตรฐานการเขียนโค้ด และ build/linter บทบาทของนักพัฒนาจึงเปลี่ยนจาก 'ผู้เขียนโค้ด' ไปเป็น 'ผู้ออกแบบสเปกและฮาร์เนส'

• หลักการสำคัญคือ "สเปกที่ AI ตรวจสอบยืนยันไม่ได้ เท่ากับไม่มีสเปกนั้นอยู่จริง" ความต้องการที่ไม่ได้ถูกจัดทำเป็นเอกสารจะไม่สามารถเป็นทั้งเกณฑ์การพัฒนาและเกณฑ์การตรวจสอบได้ จึงเท่ากับเป็น 'ความต้องการที่ไม่มีอยู่จริง' (เช่น หากไม่บอกว่าจะให้ระดับแรงลมเป็น Low-Mid-High หรือ On-Off AI ก็จะตัดสินเองตามอำเภอใจ) จุดเริ่มต้นคือ 'การออกแบบสเปก' เพื่อจัดระบบสเปกแบบ legacy และ 'ความรู้โดยนัย' ของนักพัฒนาให้อยู่ในรูปแบบที่ AI ใช้งานได้

• สเปกที่กระจัดกระจายถูกจัดระเบียบใหม่โดยยึดโฟลเดอร์ docs/ เป็นศูนย์กลาง การทำงานของผลิตภัณฑ์เก็บไว้ใน behavior/ เหตุผลเชิงออกแบบอยู่ใน design/ และข้อมูลการกำหนดค่าฮาร์ดแวร์กับการเริ่มต้นระบบอยู่ใน hardware/ รวมถึงจัดแยกสเปกการสื่อสาร state machine และ communication protocol ไว้ในโฟลเดอร์ของแต่ละส่วนเพิ่มเติม พร้อมเสริมฐานของฮาร์เนสด้วย AGENTS.md ที่บรรจุกฎการทำงานของ AI และ ARCHITECTURE.md ที่กำหนดโครงสร้างเลเยอร์กับกฎ dependency ส่งผลให้เอกสารทำหน้าที่เป็น 'Single Source of Truth'

• นอกจากฮาร์เนส 3 ประเภทคือ สเปก/การพัฒนา/การตรวจสอบแล้ว ยังมีการให้ 'สกิล' เช่น เอกสารสเปก MCU เฉพาะของ Samsung วิธีใช้ MCU debugger และ USB Switch สำหรับตัด-จ่ายไฟ 220V จริงแบบกายภาพ ใช้ SDD/TDD/BDD เพื่อควบคุมขอบเขตการพัฒนา และต้องผ่าน quality gate ของ Build/Test/Lint จึงจะไปขั้นถัดไปได้

• ลูป AUTOPILOT เริ่มจากโค้ดแบบ Zero-Base แล้ววนซ้ำวางแผน-พัฒนา-ตรวจสอบได้เอง โดยแยก 'agent ฝั่งสร้าง' ออกจาก 'agent ฝั่งประเมิน/ตรวจสอบ' เพื่อป้องกันไม่ให้ AI ประเมินผลงานของตัวเองแบบผ่อนปรนเกินไป

• โจทย์ที่ยากที่สุดคือการสร้างสภาพแวดล้อมที่ทำให้ AI ตรวจสอบผลลัพธ์บน 'MCU จริง' ได้โดยตรง สภาพแวดล้อมการตรวจสอบประกอบด้วย Codex AI บนพีซี + MCU debugger แบบ JTAG + USB Switch สำหรับควบคุมพลังงาน โดย Codex AI เป็นผู้ควบคุม debugger และสวิตช์ ตัว debugger สามารถอ่านและเขียนสถานะของ MCU ได้โดยตรง ส่วน USB Switch ใช้เปิด-ปิดไฟ 220V เพื่อให้ AI รีเซ็ตชุดอุปกรณ์ได้เองแม้อยู่ในสถานะที่กู้คืนไม่ได้

• มีการให้ AI เข้าถึงสเปกผลิตภัณฑ์ ข้อมูลโปรโตคอลและแพ็กเก็ต datasheet ของ MCU วิธีใช้ debugger โค้ดต้นฉบับและโครงสร้างตัวแปร รวมถึงวิธีเปิด/ปิดไฟ AI จะวิเคราะห์เอกสารสเปกแล้วสร้าง test scenario ด้วย 'เจตจำนงอัตโนมัติ' ของตนเอง จากนั้นฉีดอินพุตคีย์ลงไปยังอุปกรณ์จริงผ่าน debugger (memory Write) แล้วอ่านค่าสถานะกลับมาเป็นตัวแปร (memory Read) เพื่อวินิจฉัย Pass/Fail ของแต่ละสถานการณ์ได้เอง กล่าวคือ เมื่อองค์ประกอบ 3 อย่างคือ 'สถานการณ์การทำงาน + memory Write + memory Read' ทำงานเชื่อมกัน จึงจะเกิดการตรวจสอบอัตโนมัติแบบอัตโนมัติเต็มรูปแบบ

• ผลลัพธ์: ทั้ง 5 รอบเสร็จสมบูรณ์ได้เองโดยไม่มีมนุษย์แทรกแซง (รอบละประมาณ 4.5~5.5 ชั่วโมง) ความสมบูรณ์ของการทำงานพื้นฐานราว 95% ส่วนที่ขาดอีกราว 5% เกิดขึ้นหลัก ๆ ใน HAL (UART, Timer, WatchDog, Clock เป็นต้น ซึ่งเป็นพื้นที่ที่ต้องตรวจสอบกับฮาร์ดแวร์จริง) และสามารถแก้เสริมได้ด้วยการดีบักร่วมกับมนุษย์ 1~4 ชั่วโมง

• ยืนยันความเป็นไปได้ในการลดระยะเวลาพัฒนาเฉลี่ยได้ 50~70% อย่างไรก็ตาม ตัวเลขนี้เป็นค่าประมาณของ AI ที่อิงเฉพาะเวลาพัฒนาล้วน ๆ โดยไม่รวมการอนุมัติ การรีวิว และการรีลีส ขณะที่การลงทุนเริ่มต้นและการกำหนด 'เกณฑ์การตรวจสอบที่สมบูรณ์จนไม่จำเป็นต้องมีมนุษย์รีวิวโค้ด' ยังเป็นโจทย์สำคัญต่อการขยายการใช้งาน