ผู้เขียนต้นฉบับ: Meta Alchemist
เรียบเรียง: Peggy, BlockBeats

หมายเหตุบรรณาธิการ: Claude Fable 5 เปิดตัวเมื่อวันที่ 9 มิถุนายน 2026 โดย Anthropic วางตำแหน่งให้เป็นโมเดลระดับ Mythos ที่เชี่ยวชาญด้านงานวิศวกรรมซอฟต์แวร์ระยะยาวและมีคุณสมบัติด้านความปลอดภัยที่แข็งแกร่งยิ่งขึ้น

หลังจากโมเดลใหม่ออนไลน์ นักพัฒนาเริ่มสำรวจการใช้งานในสถานการณ์วิศวกรรมจริงอย่างรวดเร็ว: @meta_alchemist แชร์ Prompt การตรวจสอบคลังรหัสนี้ ซึ่งเป็นตัวอย่างที่ชัดเจน มันทำให้ Fable 5 ไม่เพียงแค่สร้างโค้ด แต่ทำหน้าที่เหมือนหัวหน้าทีมเทคนิคอาวุโส ตรวจสอบคลังรหัสอย่างเป็นระบบในสี่ขั้นตอน: ขั้นแรกจัดโครงสร้างโปรเจกต์และสแต็กเทคโนโลยี จากนั้นตรวจสอบสถาปัตยกรรม ความปลอดภัย การทดสอบ ประสิทธิภาพ การพึ่งพา และเอกสารตามไฟล์และหมายเลขบรรทัดจริง หลังจากนั้นกลั่นกรองกลยุทธ์การปรับปรุง และแยกย่อยเป็นภารกิจสำคัญที่มีลำดับความสำคัญและการประมาณการ工作量 ผู้ใช้บางส่วนใช้สิ่งนี้เพื่อชำระหนี้ทางเทคนิค ค้นหาช่องโหว่ด้านความปลอดภัยและปัญหาประสิทธิภาพที่โมเดลเก่ามองข้าม ขณะที่บางคนพบปัญหาเบื้องต้น เช่น สภาพแวดล้อมแซนด์บ็อกซ์ที่ไม่เสถียร

โดยรวมแล้ว การเปิดตัว Fable 5 ไม่เพียงแต่เป็นการอัปเกรดความสามารถของโมเดล แต่ยังผลักดันให้ AI ก้าวจาก "ผู้ช่วยเขียนโค้ด" ไปสู่ "ผู้ร่วมตรวจสอบทางวิศวกรรมและปรับปรุงโปรเจกต์"

ต่อไปนี้เป็นเนื้อหาต้นฉบับ:

คุณใช้ Claude Fable 5 แล้วหรือยัง?

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

โปรดรัน "Prompt การตรวจสอบและปรับปรุงโปรเจกต์" นี้ในทุกคลังรหัสที่สำคัญสำหรับคุณ (คัดลอกและวางโดยตรง):

แผนการตรวจสอบและปรับปรุงคลังรหัส

Prompt สร้างโดย Claude Fable 5

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

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

ระยะที่ 1 / การค้นพบและรวบรวมข้อมูล: อ่านก่อน แล้วค่อยตัดสิน

ก่อนที่จะสรุปผลใด ๆ โปรดสำรวจโค้ดเบสทั้งหมดอย่างเป็นระบบ:

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

· ระบุไฟล์เริ่มต้น โมดูลหลัก รวมถึงโฟลว์ข้อมูลและโฟลว์ควบคุมหลักในระบบ

· อ่าน package manifest, lockfile, การกำหนดค่าการ build, การกำหนดค่า CI, ไฟล์สภาพแวดล้อม/การกำหนดค่า และเอกสารทั้งหมด รวมถึง README, CONTRIBUTING, ADR เป็นต้น

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

· บันทึกแนวปฏิบัติที่โปรเจกต์นำมาใช้แล้ว รวมถึงรูปแบบการตั้งชื่อ ขอบเขตโมดูล รูปแบบการจัดการข้อผิดพลาด สไตล์การทดสอบ ฯลฯ เพื่อให้คำแนะนำในภายหลังสอดคล้องกับวัฒนธรรมทางวิศวกรรมที่มีอยู่ ไม่ใช่ขัดแย้งกับมัน

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

ระยะที่ 2 / การตรวจสอบ: อิงตามหลักฐานและระบุระดับความรุนแรง

โปรดตรวจสอบในแต่ละมิติต่อไปนี้

สำหรับการค้นพบแต่ละรายการ ให้บันทึก:

a) สิ่งที่คุณพบ

b) พบที่ไหน ในรูปแบบ: ไฟล์:หมายเลขบรรทัด

c) เหตุใดสิ่งนี้จึงสำคัญ กล่าวคือ ผลกระทบที่เป็นรูปธรรม ไม่ใช่หลักการนามธรรม

d) ระดับความรุนแรง: Critical / High / Medium / Low

สถาปัตยกรรมและการออกแบบ

ขอบเขตโมดูล การเชื่อมโยง/การเกาะกลุ่ม การพึ่งพาแบบวนซ้ำ การรั่วไหลของนามธรรม God Object/God File การละเมิดเลเยอร์ คอขวดในการขยายขนาด

คุณภาพโค้ด

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

ความปลอดภัย

คีย์หรือข้อมูลรับรองที่ถูก hardcode ความเสี่ยงจากการ injection การ deserialize ที่ไม่ปลอดภัย การขาดการตรวจสอบอินพุต จุดอ่อนในการรับรองความถูกต้อง/การอนุญาต การพึ่งพาที่ล้าสมัยซึ่งมี CVE ที่รู้จัก การกำหนดค่าที่ผ่อนปรนเกินไป

การทดสอบ

ช่องว่างในการครอบคลุมการทดสอบ โดยเฉพาะในตรรกะทางธุรกิจหลัก คุณภาพของการทดสอบ กล่าวคือ การทดสอบกำลังตรวจสอบพฤติกรรม หรือแค่ตรวจสอบว่าทำงานได้ ประเภทการทดสอบที่ขาดหายไป รวมถึง unit test, integration test, end-to-end test รูปแบบการทดสอบที่ผันผวน โค้ดที่ทดสอบยาก

ประสิทธิภาพ

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

การพึ่งพา

การพึ่งพาที่ล้าสมัย, ไม่มีการบำรุงรักษา, ซ้ำซ้อนหรือหนักเกินไปโดยไม่จำเป็น; ความเสี่ยงด้านใบอนุญาต; สถานะการบำรุงรักษา lockfile

ประสบการณ์นักพัฒนาและการดำเนินงาน

ต้นทุนการสร้าง/เริ่มต้น, ช่องว่างใน CI/CD, การขาดการบังคับใช้ lint/formatting, คุณภาพของล็อกและการสังเกตการณ์, การรายงานข้อผิดพลาด, เส้นทางการปรับใช้

เอกสาร

ความถูกต้องของ README, เส้นทางการเริ่มต้นใช้งาน, พฤติกรรมสำคัญที่ไม่ได้บันทึก, เอกสารที่ล้าสมัยซึ่งขัดแย้งกับโค้ด

กฎของเฟสนี้

ควรให้การค้นพบที่มีความมั่นใจสูง 15 รายการ ดีกว่าให้การค้นพบเชิงคาดเดา 50 รายการ

แยกแยะข้อเท็จจริงและการตัดสิน ตัวอย่างเช่น:

·ข้อเท็จจริง: "ฟังก์ชันนี้ไม่มีการจัดการข้อผิดพลาด: src/api/client.ts:142"

·การตัดสิน: "ขอบเขตความรับผิดชอบของโมดูลนี้รู้สึกไม่ชัดเจน"

และระบุให้ชัดเจนว่าประเภทไหนเป็นประเภทไหน

พร้อมกันนี้ ให้ระบุสิ่งที่โค้ดเบสนี้ทำได้ดี จุดแข็งก็สำคัญไม่แพ้กัน เพราะมันกำหนดว่าสิ่งใดควรถูกเก็บรักษาไว้

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

เฟส 3 / กลยุทธ์การปรับปรุง

รวมผลการตรวจสอบเป็นกลยุทธ์ชุดหนึ่ง:

·ระบุ 3–5 หัวข้อที่สามารถอธิบายปัญหาส่วนใหญ่ได้ เช่น "ไม่มีขอบเขตบังคับระหว่างเลเยอร์" "การจัดการข้อผิดพลาดเป็นการแก้ปัญหาเฉพาะหน้าชั่วคราวเกินไป"

·สำหรับแต่ละหัวข้อ เสนอสถานะเป้าหมายและหลักการเบื้องหลัง

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

·กำหนดว่า "เสร็จสิ้น" หมายถึงอะไร — ให้สัญญาณที่วัดได้ เช่น "CI จะล้มเหลวเมื่อมีข้อผิดพลาด lint" "ความครอบคลุมการทดสอบโมดูลหลัก ≥ 80%" "ปัญหาระดับ Critical เป็นศูนย์"

เฟส 4 / แผนงานโดยละเอียด

การแปลงกลยุทธ์เป็นแผนปฏิบัติการ:

แบ่งงานออกเป็นภารกิจอิสระแต่ละงาน แต่ละภารกิจต้องประกอบด้วย:

· หัวข้อและคำอธิบายภารกิจ

· ไฟล์/พื้นที่ที่ได้รับผลกระทบ

· เกณฑ์การยอมรับ กล่าวคือ จะตรวจสอบได้อย่างไรว่างานเสร็จสมบูรณ์

· การประมาณปริมาณงาน: S = น้อยกว่า 2 ชั่วโมง, M = ครึ่งวัน, L = 1–2 วัน, XL = ต้องแยกย่อยเพิ่มเติม

· ความเสี่ยงจากการเปลี่ยนแปลงเอง กล่าวคือ อาจทำให้ฟังก์ชันที่มีอยู่เสียหายหรือไม่

· การพึ่งพาภารกิจอื่น

โปรดจัดเรียงภารกิจตาม Milestone:

Milestone 0

ตาข่ายความปลอดภัย: สิ่งที่ต้องทำให้เสร็จก่อนการปรับโครงสร้างอย่างปลอดภัย เช่น การทดสอบเส้นทางสำคัญ, CI gate, การสำรองข้อมูล

Milestone 1

การแก้ไขที่สำคัญ: ปัญหาด้านความปลอดภัยและความถูกต้อง

Milestone 2

การปรับปรุงที่มีเลเวอเรจสูง: การเปลี่ยนแปลงที่ทำให้งานที่ตามมาทั้งหมดง่ายขึ้น

Milestone 3

คุณภาพและการขัดเกลา: งานที่มีลำดับความสำคัญปานกลางถึงต่ำที่เหลือซึ่งคุ้มค่าที่จะจัดการ

โปรดระบุ Quick Wins แยกต่างหาก กล่าวคือ ภารกิจที่มีผลกระทบสูง ปริมาณงาน S และสามารถทำได้ทันที

สำหรับสามภารกิจอันดับต้นๆ โปรดแนบร่างการดำเนินการโดยย่อ รวมถึงวิธีการ ขั้นตอนสำคัญ และจุดที่อาจพลาดได้ง่าย

รูปแบบการส่งมอบสุดท้าย

โปรดสร้างเอกสารเดียวที่มีส่วนต่างๆ ดังนี้:

Executive Summary: ไม่เกิน 10 ประโยค ให้คะแนนสุขภาพโดยรวม A–F พร้อมเหตุผล ระบุความเสี่ยง 3 อันดับแรกและโอกาส 3 อันดับแรก

Repo Map

Audit Report

Improvement Strategy

Task Plan: รวมถึง Milestone, ตารางภารกิจ และ Quick Wins

Open Questions: ระบุข้อมูลที่ต้องตัดสินใจโดยมนุษย์ เช่น เจตนาของผลิตภัณฑ์ โมดูลที่สามารถยกเลิกได้ เป้าหมายประสิทธิภาพ เป็นต้น

ข้อจำกัด

ในระหว่างการตรวจสอบนี้ ห้ามแก้ไขโค้ดใดๆ ให้ทำการวิเคราะห์เท่านั้น

อย่าเติมเต็มรายงาน หากมิติใดมีสุขภาพดี ให้อธิบายด้วยหนึ่งประโยคแล้วดำเนินการต่อ

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

วิเคราะห์ความต้องการที่แท้จริงของโปรเจกต์ และให้คำแนะนำด้วยวิธีที่มีประสิทธิภาพสูงสุด

หากคลังโค้ดมีขนาดใหญ่ ให้เน้นวิเคราะห์โค้ด 20% ที่สำคัญที่สุด ซึ่งรับผิดชอบงาน 80% อย่างลึกซึ้งก่อน และระบุว่าส่วนใดที่ตรวจสอบเพียงผิวเผิน

[ลิงก์ต้นฉบับ]

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia