ทักษะที่ปราศจาก persona ก็เหมือนกับคำสั่งที่ไม่มีผู้บัญชาการ คุณอาจจะใส่ไฟล์คำจำกัดความที่เต็มไปด้วยข้อกำหนด รูปแบบเอาต์พุต และกฎเกณฑ์ด้านสไตล์ แต่ถ้าคุณไม่เคยบอก AI เลยว่ามันควรจะเป็นใคร คุณก็กำลังขอให้พนักงานที่มีความสามารถแต่ไร้ทิศทางมานั่งเดาชื่อตำแหน่งงานของตัวเอง ผลลัพธ์ที่ได้ก็จะเป็นอย่างที่คุณคาดไว้: เอาต์พุตที่ดูธรรมดาและโทนเสียงที่เปลี่ยนไปมา ระดับความเชี่ยวชาญที่แกว่งไปมาอย่างรุนแรงในแต่ละครั้งที่รัน และกระบวนการดีบั๊กที่ให้ความรู้สึกเหมือนการไล่จับควัน
เรื่องนี้สำคัญเพราะเวิร์กโฟลว์การเขียนโค้ดด้วย AI ในปัจจุบันไม่ใช่แค่การป้อนพรอมต์แบบครั้งเดียวจบ (single-shot prompts) อีกต่อไป แต่มันคือระบบแบบโมดูลาร์ที่สร้างขึ้นจากการเชื่อมต่อทักษะเล็กๆ หลายอย่างเข้าด้วยกัน เมื่อทักษะแต่ละอย่างขาดอัตลักษณ์ที่ชัดเจน ทั้งระบบก็จะได้รับผลกระทบ
ทำไมการขาด Persona ถึงทำให้เวิร์กโฟลว์ของคุณพัง
เมื่อคุณละเลยการประกาศบทบาท คุณกำลังบังคับให้โมเดลต้องด้นสดเพื่อกำหนดอำนาจของตัวเอง นาทีหนึ่งมันอาจจะเขียนโค้ดเหมือนเด็กฝึกงานที่ระมัดระวังตัวเพราะกลัวจะทำให้ระบบพัง แต่อีกนาทีต่อมา มันอาจจะออกแบบ distributed system เหมือนกับ principal engineer ที่เคยผ่าน edge case มาทุกรูปแบบ ความไม่สม่ำเสมอนี้ไม่ใช่แค่เรื่องน่ารำคาญ แต่มันทำให้เวิร์กโฟลว์ของคุณขาดความน่าเชื่อถือ
ปัญหาจะสะสมขึ้นอย่างรวดเร็ว AI จะเลือกใช้เสียงที่สุ่มมา ทำให้ codebase ของคุณเริ่มฟังดูเหมือนถูกเขียนโดยคณะกรรมการที่ไม่เคยมาประชุมกันเลย เอาต์พุตจะเปลี่ยนไปทุกครั้งที่คุณรันทักษะ ซึ่งหมายความว่าคุณไม่สามารถเชื่อถือการทดสอบอัตโนมัติหรือการทำ diff reviews ได้ การตรวจสอบ (Auditing) จะกลายเป็นเรื่องที่เป็นไปไม่ได้ เพราะคุณไม่รู้ว่ามุมมองไหนเป็นตัวสร้างผลลัพธ์นั้นขึ้นมา สิ่งนี้ถูกสร้างขึ้นโดยวิศวกรที่เน้นด้านความปลอดภัย หรือเป็นเพียงนักพัฒนาทั่วไป? หากคำตอบคือ "แล้วแต่ที่โมเดลจะรู้สึก" คุณก็ไม่มีทางตรวจสอบความถูกต้องของตรรกะได้เลย
การเชื่อมต่อทักษะ (skill chaining) ยิ่งทำให้เรื่องนี้แย่ลง ลองจินตนาการถึงทักษะหนึ่งที่สร้าง API contracts และอีกทักษะหนึ่งที่เขียนส่วน implementation หากทักษะแรกทำตัวเหมือน senior architect ที่ละเอียดลออและบังคับใช้การตรวจสอบที่เข้มงวด แต่ทักษะที่สองกลับทำตัวเหมือน junior developer ที่ข้ามการจัดการ error ไป การเชื่อมต่อของคุณก็จะพังทลายลง สายโซ่จะแข็งแรงได้ก็ต่อเมื่อทุกข้อต่อรู้ถึงอัตลักษณ์ของตัวเอง หากไม่มีสิ่งนั้น ความรับผิดชอบก็จะหายไป เมื่อมีบางอย่างพัง คุณไม่สามารถชี้ได้ว่าเลนส์ไหนที่ทำงานผิดพลาด เพราะไม่มีการกำหนดเลนส์เอาไว้ตั้งแต่แรก
วิธีแก้ไข
ทางออกนั้นง่ายแต่ต้องชัดเจน ให้เพิ่มการประกาศบทบาทเป็นคำสั่งแรกสุดในไฟล์ทักษะของคุณ อย่าเอาไปฝังไว้ใต้กฎการจัดรูปแบบหรือโครงสร้างเอาต์พุต จงนำด้วยอัตลักษณ์
ใช้โครงสร้างที่ชัดเจน: "You are a [role] with expertise in [domain]." ตามด้วยประโยคหนึ่งหรือสองประโยคเกี่ยวกับสิ่งที่บทบาทนี้ต้องทำจริงๆ ในบริบทของงานนั้น ตัวอย่างเช่น: "You are a senior backend engineer with expertise in distributed systems. Your job is to review pull requests for concurrency risks and data consistency issues. You question assumptions about state management and refuse to approve code that lacks proper error handling."
เพียงเท่านี้ก็พอแล้ว อย่างมากไม่เกินสามประโยค ประวัติที่ยาวเกินไปจะกลายเป็น noise โมเดลไม่ต้องการประวัติวัยเด็กหรือรายการงานอดิเรก มันต้องการ "สมอทางวิชาชีพ" (professional anchor) ที่จะช่วยกำหนดการตัดสินใจของมัน
ยึดตามบทบาททางวิชาชีพจริงๆ การเป็น staff software engineer หรือ technical documentation writer จะช่วยให้โมเดลมีกรอบความรับผิดชอบที่จดจำได้ การขอให้มันทำตัวเหมือน Sherlock Holmes หรือพ่อมดในยุคกลางอาจจะดูสร้างสรรค์ แต่มันจะนำไปสู่การเชื่อมโยงที่คาดเดาไม่ได้ซึ่งไม่เกี่ยวข้องกับ pipeline การรีวิวโค้ดของคุณเลย บทบาทจริงๆ มาพร้อมกับข้อจำกัดที่แท้จริง
สิ่งที่จะเปลี่ยนไปเมื่อคุณทำได้อย่างถูกต้อง
เมื่อทักษะแต่ละอย่างมี persona ของตัวเองแล้ว เวิร์กโฟลว์ทั้งหมดของคุณก็จะเริ่มมีความเสถียร
ความสามารถในการคาดเดาได้คือรางวัลแรก AI จะหยุดเดาความอาวุโสของตัวเอง Persona ระดับ senior จะตั้งคำถามที่ยากขึ้น มันจะโต้แย้งข้อกำหนดที่คลุมเครือ แจ้งเตือน edge case ที่ขาดหายไป และเรียกร้องบริบทที่เสียงระดับ default หรือ junior อาจจะมองข้าม เมื่อคุณกำหนดบทบาท คุณก็ได้กำหนดมาตรฐานไปในตัว
การรีวิวจะเร็วขึ้น เมื่อเพื่อนร่วมทีมอ่านเอาต์พุตที่ระบุ persona ไว้อย่างชัดเจน พวกเขาจะเข้าใจมุมมองที่อยู่เบื้องหลังทุกคำแนะนำ พวกเขาจะรู้ว่าควรปฏิบัติกับคำแนะนำนั้นในฐานะข้อกำหนดทางสถาปัตยกรรมที่ต้องทำตาม (hard architectural requirement) หรือเป็นเพียงความชอบด้านสไตล์ (soft style preference) บริบทจะกลายเป็นสิ่งที่ชัดเจนแทนที่จะเป็นการคาดเดา
การเชื่อมต่อทักษะ (skill chaining) จะทำงานได้ตามที่ตั้งใจไว้เสียที แต่ละ