คำถามสัมภาษณ์ harness engineering: 22 ข้อพร้อมคำตอบสำหรับวิศวกร AI

วิธีเตรียมตัว

คำถามสัมภาษณ์เรื่อง harness engineering มักเริ่มจากภาพรวมแล้วค่อยลงรายละเอียด: harness คืออะไร ประกอบด้วยอะไร คุณวินิจฉัยปัญหาอย่างไร คุณวัดผลอย่างไร ผู้สัมภาษณ์กำลังมองหาการคิดเชิงวิศวกรรม คือความสามารถในการแยกปัญหาของโมเดลออกจากปัญหาของสภาพแวดล้อม และเสนอวิธีแก้ที่ตรวจสอบได้ ด้านล่างคือ 22 คำถามพร้อมคำตอบ จัดกลุ่มตามหัวข้อ

พื้นฐาน

1. Harness ของ agent คืออะไร?

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

2. Harness engineering ต่างจาก prompt engineering และ context engineering อย่างไร?

Prompt engineering ทำงานกับการเขียนคำขอหนึ่งครั้ง context engineering ทำงานกับสิ่งที่เข้าไปในหน้าต่างของโมเดลในแต่ละขั้น Harness engineering ครอบคลุมทั้งสองอย่างและเพิ่มสิ่งที่แก้ด้วยข้อความไม่ได้ ได้แก่ สิทธิ์เข้าถึงเครื่องมือ สภาพแวดล้อมที่ทำซ้ำได้ สถานะข้ามเซสชัน และการตรวจสอบผลลัพธ์ด้วยเครื่อง

3. บอกชื่อระบบย่อยทั้งห้าของ harness

คำสั่ง (AGENTS.md, CLAUDE.md, skills, เอกสาร) เครื่องมือ (shell, เทสต์, linter, เบราว์เซอร์, MCP) สภาพแวดล้อม (dependencies, runtime, Docker, worktree) สถานะ (PROGRESS.md, รายการฟีเจอร์, การตัดสินใจ) และวงป้อนกลับ (make check, E2E, hooks, ผู้ประเมิน) การขาดระบบย่อยใดระบบหนึ่งไม่ได้ทำให้ผลแย่ลงเล็กน้อย แต่สร้างกลุ่มความล้มเหลวที่เป็นระบบ

4. ทำไมการเปลี่ยนโมเดลเป็นตัวที่แรงกว่ามักไม่ช่วย?

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

การวินิจฉัย

5. Agent ละเมิดกฎที่เขียนไว้ใน CLAUDE.md คุณจะทำอย่างไร?

ก่อนอื่นตรวจว่า agent เจอกฎนั้นหรือไม่ ไฟล์ยาวที่มีหลายสิบข้อทำให้สิ่งสำคัญจางหาย ให้ย่อไฟล์หลักเป็นสารบัญ และย้ายรายละเอียดไปไว้เอกสารที่โหลดตามเงื่อนไข หากกฎนั้นสำคัญ ให้เปลี่ยนเป็นการตรวจสอบที่รันได้ เช่น linter เทสต์ guard แบบ grep หรือ hook เมื่อนั้นการละเมิดจะถูกตรวจพบด้วยเครื่อง ไม่ต้องพึ่งการใส่ใจของโมเดล

6. จากอาการจะระบุได้อย่างไรว่าระบบย่อยใดพัง?

การฝ่าฝืนแบบแผนที่รู้กันอยู่แล้วคือปัญหาของคำสั่ง agent ที่ «อยากทำแต่ทำไม่ได้» คือปัญหาของเครื่องมือ ทุกเซสชันที่เริ่มด้วยการซ่อมสภาพแวดล้อมคือปัญหาของสภาพแวดล้อม เซสชันใหม่ที่ไม่รู้ว่าค้างอยู่ที่ไหนคือปัญหาของสถานะ «เสร็จแล้ว» ที่ไม่ตรงกับความจริงคือปัญหาของวงป้อนกลับ

7. ควรเริ่มสร้าง harness จากระบบย่อยใด และเพราะเหตุใด?

จากวงป้อนกลับ เมื่อยังไม่มีคำสั่งที่ตอบด้วยเครื่องว่า «ทำงานได้หรือไม่» จะวัดผลการเปลี่ยนแปลงอื่นใดไม่ได้ ลำดับถัดไปมักเป็นคำสั่ง สถานะ สภาพแวดล้อม และเครื่องมือ แต่ลำดับนี้มาจากประสบการณ์และขึ้นอยู่กับสิ่งที่พังหนักที่สุด

8. จะวัดผลของส่วนประกอบ harness แต่ละชิ้นอย่างไร?

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

คำสั่งและบริบท

9. AGENTS.md ที่ดีควรจัดโครงสร้างอย่างไร?

เหมือนตัวกำหนดเส้นทางไม่ใช่หนังสือเรียน มีว่าโปรเจกต์คืออะไร เปิดอย่างไร ตรวจสอบอย่างไร Definition of Done และรายการสั้น ๆ ของข้อจำกัดที่บังคับ รายละเอียดอยู่ในเอกสารแยกพร้อมลิงก์แบบ «อ่านเมื่องานเกี่ยวกับการชำระเงิน» ไฟล์กำหนดหลักที่ไม่เปลี่ยน («ข้อมูลถูกตรวจสอบที่ขอบเขต») ไม่ใช่สั่งการเขียนโค้ดหรือเลือกไลบรารีทีละบรรทัด

10. Subagent ใช้ทำอะไร?

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

11. «หนี้ harness» คืออะไร?

คือความคลาดเคลื่อนที่สะสมระหว่าง harness กับความเป็นจริง เช่น กฎที่ล้าสมัย คำสั่งที่ไม่ทำงานอีกแล้ว เอกสารเกี่ยวกับโมดูลที่ไม่มีอยู่จริง มันทำงานเหมือนหนี้ทางเทคนิค สะสมอย่างเงียบ ๆ และถูกจ่ายด้วยความล้มเหลวของ agent ต้องทบทวน harness เป็นประจำ ไม่ใช่ตั้งค่าครั้งเดียวแล้วทิ้ง

สถานะและเซสชัน

12. จะจัดการกับอาการ «ความจำเสื่อม» ของ agent ข้ามเซสชันอย่างไร?

เก็บสถานะไว้ใน repository ได้แก่ PROGRESS.md (สถานะ สิ่งที่ทำ ปัญหาขวางทาง ขั้นตอนถัดไป) DECISIONS.md (การตัดสินใจ เหตุผล ตัวเลือกที่ถูกปฏิเสธ) รายการฟีเจอร์พร้อมสถานะ และ commit บ่อย ๆ ในคำสั่งให้กำหนดลำดับการเริ่มต้น: อ่านความคืบหน้า รันสคริปต์ตรวจสอบสภาพแวดล้อม แล้วหยิบฟีเจอร์ที่ active

13. กฎ WIP=1 มีไว้ทำไม?

เมื่อ agent เริ่มหลายฟีเจอร์พร้อมกัน สถานะจะกระจัดกระจาย ไม่มีฟีเจอร์ใดเสร็จสมบูรณ์ การเปลี่ยนแปลงปนกันและย้อนยาก ฟีเจอร์ที่ active เพียงหนึ่งเดียวให้จุดตรวจสอบที่ชัดเจน commit ที่สะอาด และการกู้คืนที่ง่ายหลังความล้มเหลว

14. การทดสอบ cold start คืออะไร?

คือการตรวจว่าเซสชันใหม่ตอบคำถามพื้นฐานได้โดยไม่ต้องมีคนบอกหรือไม่ ได้แก่ โปรเจกต์นี้คืออะไร ค้างอยู่ที่ไหน ฟีเจอร์ใดกำลัง active ตรวจสอบอย่างไรว่าทุกอย่างปกติ หาก agent ตอบจากไฟล์โดยไม่ต้องเดา ระบบย่อยสถานะกำลังทำงาน

การตรวจสอบ

15. ทำไมยูนิตเทสต์ที่เขียวจึงไม่พิสูจน์ว่าฟีเจอร์ทำงาน?

ยูนิตเทสต์แยกโมดูลและ mock การพึ่งพา จึงมองไม่เห็นจุดเชื่อมต่อ ได้แก่ อินเทอร์เฟซไม่ตรงกัน สถานะแพร่กระจาย (schema เปลี่ยนแต่แคชยังเก่า) ทรัพยากรรั่ว ปัญหาการตั้งค่าและสภาพแวดล้อม บั๊กที่ยูนิตเทสต์จับได้เป็นเพียงส่วนย่อยของที่การทดสอบเชิงบูรณาการจับได้ และส่วนนั้นเป็นส่วนย่อยของที่ E2E จับได้

16. Verification gap คืออะไรและวัดอย่างไร?

คือสัดส่วนของงานที่ agent รายงานว่าเสร็จแล้ว แต่การตรวจสอบอิสระไม่ยืนยัน หยิบงาน 10 ชิ้นติดต่อกันและบันทึกข้อเท็จจริงทั้งสองสำหรับแต่ละชิ้น ตัวชี้วัดนี้ให้จุดอ้างอิง: หลังเปลี่ยน harness ให้คำนวณใหม่บนชุดงานที่คล้ายกัน

17. จะเขียน Definition of Done สำหรับ agent อย่างไร?

ใน AGENTS.md เป็นรายการข้อที่ตรวจสอบได้: คำสั่งตรวจสอบจบด้วยรหัส 0 มี E2E ครอบคลุมสถานการณ์ migration ถูกนำไปใช้ และความคืบหน้าถูกอัปเดต ควรระบุให้ชัดด้วยว่าอะไรไม่ถือว่าเสร็จ: «ดูถูกต้อง» «ยูนิตเทสต์ผ่าน» «ในเครื่องของฉันทำงานได้»

18. ทำไม agent ไม่ควรตั้งสถานะ «เสร็จ» ด้วยตัวเอง?

โมเดลมีแนวโน้มประเมินงานของตัวเองสูงเกินจริง และการประเมินตนเองเกิดขึ้นในบริบทเดียวกับที่ตัดสินใจ สถานะ passing ต้องถูกตั้งโดยสคริปต์ตรวจสอบจากผลการรัน พร้อมบันทึกแฮชของ commit เป็นหลักฐาน

19. จะตั้งผู้ประเมินอิสระอย่างไร?

เป็น agent หรือเซสชันแยกที่เห็นเพียงข้อกำหนด diff และผลการรัน แต่ไม่เห็นเหตุผลของผู้ทำ มันประเมินตาม rubric (ความถูกต้อง สถาปัตยกรรม เทสต์ การจัดการข้อผิดพลาด) และทุกการประเมินต้องอ้างอิงไฟล์ บรรทัด หรือ log ควรใช้โมเดลอื่นเพื่อไม่ให้จุดบอดซ้ำกัน

20. จะทำให้กฎสถาปัตยกรรมบังคับใช้ได้อย่างไร?

สามระดับ: guard แบบ grep (เร็ว ตามรูปแบบ) กฎ linter ที่เข้าใจกราฟการ import (import-linter, dependency-cruiser) และเทสต์สถาปัตยกรรมใน CI ทั้งหมดนี้ถูกผนวกเข้า make check ล้มด้วยรหัสที่ไม่ใช่ 0 และพิมพ์ WHY กับ FIX เพื่อให้ agent แก้การละเมิดเอง ตัวกระตุ้นให้เพิ่มการตรวจสอบใหม่คือความคิดเห็นเดิมที่ปรากฏซ้ำในการรีวิวครั้งที่สอง

การทำงานอัตโนมัติ

21. ต้องมีอะไรบ้างเพื่อให้ปล่อย agent ทำงานหลายชั่วโมง?

เป้าหมายที่ชัดเจน ตัวชี้วัดความคืบหน้าที่เพิ่มอย่างต่อเนื่อง (เช่น จำนวนฟีเจอร์ที่ passing) งบประมาณเวลาและจำนวนครั้งต่อฟีเจอร์ การย้อนกลับอัตโนมัติเมื่อเกิดการถดถอย และรายการงานที่ต้องใช้คน ได้แก่ migration โครงสร้างพื้นฐาน และเงิน นอกจากนี้ต้องมีการแยกส่วน: sandbox หรือ git worktree แยกต่างหาก เพื่อให้ข้อผิดพลาดไม่กระทบสภาพแวดล้อมการทำงาน

22. เมื่อใดวงวนของ agent เดียวไม่พอ และจะออกแบบกราฟบทบาทอย่างไร?

เมื่อผู้ทำเริ่มตรวจสอบตัวเองและติดขัด งานจะถูกแบ่งเป็นบทบาท: ลงมือทำ รีวิว ทดสอบ รวมโค้ด ผู้รีวิวได้บริบทสะอาดและ rubric ส่วนการรวมโค้ดดำเนินการเมื่อ review == pass เมื่อรีวิวไม่ผ่าน ฟีเจอร์จะกลับไปที่การลงมือทำ และหลังจากล้มเหลวหลายครั้ง จะเริ่มใหม่ด้วยบริบทสะอาด ซึ่งบ่งชี้ว่าปัญหาอยู่ที่การเข้าใจโจทย์ ไม่ใช่ที่โค้ด

สรุป

ในการสัมภาษณ์ harness engineering คำตอบที่ทรงพลังที่สุดคือคำตอบที่พูดถึงสิ่งที่ตรวจสอบได้: ไฟล์ไหน คำสั่งไหน ตัวชี้วัดใด จำระบบย่อยทั้งห้า verification gap และกฎที่ว่า «สถานะความพร้อมมาจากสคริปต์» ให้แม่น หัวข้อทั้งหมดนี้รวมกันเป็น harness เดียวบนโปรเจกต์จริงในหลักสูตร harness engineering