การกำหนดขอบเขตงานใน Claude Code: จากคำขอที่คลุมเครือสู่การคอมมิต

ทำไมคำขอฟีเจอร์ที่คลุมเครือจึงเสียเวลา\n\nคำขอที่คลุมเครือฟังดูไม่เป็นภัย: “เพิ่มการค้นหาที่ดีกว่า”, “ทำ onboarding ให้ราบรื่นขึ้น”, “ผู้ใช้ต้องการการแจ้งเตือน” ในทีมจริง ๆ มันมักมาถึงเป็นข้อความแชทบรรทัดเดียว, สกรีนช็อตที่มีลูกศร, หรือการโทรจากลูกค้าที่จำได้ไม่เต็มที่ ทุกคนเห็นด้วย แต่แต่ละคนจินตนาการต่างกันไป\n\nค่าใช้จ่ายจะปรากฏทีหลัง เมื่อขอบเขตไม่ชัดเจน คนจะลงมือจากการเดา เดโมแรกกลายเป็นรอบของการชี้แจงอีกครั้ง: “ไม่ใช่สิ่งที่ฉันหมายถึง” งานต้องทำใหม่ และการเปลี่ยนแปลงขยายตัวอย่างเงียบ ๆ การปรับดีไซน์กระตุ้นการเปลี่ยนแปลงโค้ด ซึ่งกระตุ้นการทดสอบเพิ่ม การรีวิวช้าลงเพราะการเปลี่ยนแปลงที่ไม่ชัดยากตรวจสอบ หากไม่มีใครกำหนดว่า “ถูกต้อง” เป็นอย่างไร ผู้ตรวจจะถกเถียงพฤติกรรมแทนที่จะตรวจคุณภาพ\n\nคุณมักจะเห็นงานที่คลุมเครือตั้งแต่ต้น:\n\n- ไม่มีตัวอย่างทีละขั้นตอนของสิ่งที่ผู้ใช้ควรทำได้\n- ไม่มีการระบุกรณีขอบ (สถานะว่าง สิทธิ์ ข้อผิดพลาด)\n- งาน “แค่เผื่อไว้” ที่ขยายเป็น PR ใหญ่\n- ความเห็นในรีวิวถกเถียงเรื่องพฤติกรรม ไม่ใช่การใช้งาน\n- “ค่อยหาทางไประหว่างทาง” กลายเป็นแผน\n\nงานที่กำหนดขอบเขตดีให้ทีมมีเส้นชัยชัดเจน: เกณฑ์การยอมรับที่ชัด, แผน UI/API ขั้นพื้นฐาน, และขอบเขตชัดเจนว่าทำอะไรไม่รวม นั่นคือความต่างระหว่าง “ปรับปรุงการค้นหา” กับการเปลี่ยนแปลงเล็ก ๆ ที่สร้างและรีวิวง่าย\n\nนิสัยปฏิบัติได้: แยก “คำจำกัดความของเสร็จ” ออกจาก “สิ่งที่อยากได้” “เสร็จ” คือรายการตรวจสั้น ๆ ที่คุณสามารถรันได้ (ตัวอย่าง: “การค้นหาคืนค่าผลลัพธ์ตามชื่อเรื่อง แสดง ‘ไม่มีผลลัพธ์’ เมื่อว่าง และเก็บคำค้นไว้ใน URL”) “สิ่งที่อยากได้” คือทุกอย่างที่รอได้ (พจนานุกรมคำพ้อง, การปรับลำดับ, ไฮไลต์, การวิเคราะห์) การติดป้ายเหล่านี้ล่วงหน้าช่วยป้องกันการเบ่งขยายขอบเขตโดยไม่ได้ตั้งใจ\n\n## เริ่มจากผลลัพธ์ ไม่ใช่วิธีแก้\n\nคำขอที่คลุมเครือมักเริ่มจากการเสนอวิธีแก้: “เพิ่มปุ่ม”, “เปลี่ยนไปใช้โฟลว์ใหม่”, “ใช้โมเดลต่างไป” หยุดสักครู่แล้วแปลคำแนะนำเป็นผลลัพธ์ก่อน\n\nรูปแบบง่าย ๆ ช่วยได้: “ในฐานะ [ผู้ใช้] ฉันต้องการ [ทำอะไรบางอย่าง] เพื่อที่ฉันจะได้ [บรรลุเป้าหมาย]” พูดให้กระชับ ถ้าพูดไม่จบในประโยคเดียว มันยังคลุมเครือ\n\nต่อมา อธิบายสิ่งที่จะเปลี่ยนสำหรับผู้ใช้เมื่อเสร็จ ให้โฟกัสที่พฤติกรรมที่มองเห็นได้ ไม่ใช่รายละเอียดการนำไปใช้ ตัวอย่าง: “หลังส่งฟอร์ม ฉันเห็นการยืนยันและสามารถหาบันทึกใหม่ในรายการได้” นั่นสร้างเส้นชัยที่ชัดและทำให้ยากขึ้นที่การปรับแต่งเล็ก ๆ จะลอบเข้า\n\nให้เขียนด้วยว่าสิ่งใดจะยังคงเหมือนเดิม เป้าหมายที่ไม่รวมช่วยปกป้องขอบเขต ถ้าคำขอคือ “ปรับปรุง onboarding” เป้าหมายที่ไม่รวมอาจเป็น “ไม่เปลี่ยนดีไซน์แดชบอร์ด” หรือ “ไม่เปลี่ยนตรรกะระดับราคา”\n\nสุดท้าย เลือกทางหลักทางเดียวที่รองรับก่อน: ชิ้นงานแบบ end-to-end เดียวที่พิสูจน์ว่าฟีเจอร์ทำงาน\n\nตัวอย่าง: แทนที่จะเขียนว่า “เพิ่ม snapshots ทุกที่” ให้เขียนว่า: “ในฐานะเจ้าของโปรเจกต์ ฉันสามารถคืนค่าจาก snapshot ล่าสุดของแอป เพื่อที่ฉันจะย้อนการเปลี่ยนแปลงที่ผิดพลาดได้” สิ่งที่ไม่รวม: “ไม่รองรับการคืนค่าจำนวนมาก, ไม่มีการออกแบบ UI ใหม่”\n\n## ถามคำถามไม่กี่ข้อที่ลดความคลุมเครือได้\n\nคำขอที่คลุมเครือไม่ค่อยขาดแรงงาน แต่มักขาดการตัดสินใจ\n\nเริ่มจากข้อจำกัดที่เปลี่ยนขอบเขตอย่างเงียบ ๆ เวลาส่งงานสำคัญ แต่กฎการเข้าถึงและข้อกำหนดการปฏิบัติตามก็นสำคัญเช่นกัน ถ้าคุณกำลังสร้างบนแพลตฟอร์มที่มีระดับและบทบาท ให้ตัดสินใจแต่แรกว่าใครจะได้ฟีเจอร์นี้และภายใต้แผนใด\n\nจากนั้นขอหนึ่งตัวอย่างที่จับต้องได้ สกรีนช็อต พฤติกรรมคู่แข่ง หรือบันทึกก่อนหน้านี้เผยว่า “ดีกว่า” หมายถึงอะไร ถ้าผู้ขอไม่มี ให้ขอให้พวกเขาย้อนเหตุการณ์ครั้งล่าสุดที่รู้สึกเจ็บปวด: พวกเขาอยู่หน้าจอไหน คลิกอะไร คาดหวังอะไร\n\nกรณีขอบคือจุดที่ขอบเขตขยาย ดังนั้นตั้งชื่อกรณีใหญ่ ๆ เหล่านี้ตั้งแต่ต้น: ข้อมูลว่าง, ข้อผิดพลาดการตรวจสอบ, เครือข่ายช้า/ล้มเหลว, และ “ย้อนกลับ” หมายถึงอะไรจริง ๆ\n\nสุดท้าย ตัดสินใจว่าคุณจะยืนยันความสำเร็จอย่างไร หากไม่มีผลลัพธ์ที่ทดสอบได้ งานจะกลายเป็นความคิดเห็น\n\nคำถามห้าข้อนี้มักลดความคลุมเครือได้มากที่สุด:\n\n- ใครเข้าถึงได้ (ระดับและบทบาท)?\n- เส้นตายคือเมื่อไหร่ และเวอร์ชันขั้นต่ำที่ยอมรับได้คืออะไร?\n- ตัวอย่างพฤติกรรมที่คาดหวังคืออะไร?\n- เกิดอะไรขึ้นในสถานะว่าง ข้อผิดพลาด และการเชื่อมต่อช้า?\n- เราจะยืนยันว่ามันใช้งานได้อย่างไร (เกณฑ์หรือเมตริกเฉพาะ)?\n\nตัวอย่าง: “เพิ่มโดเมนกำหนดเองสำหรับลูกค้า” จะชัดขึ้นเมื่อคุณตัดสินใจว่ามันอยู่ในระดับไหน ใครตั้งค่าได้ ที่ตั้งโฮสต์สำคัญต่อการปฏิบัติตามหรือไม่ ข้อผิดพลาดใดจะแสดงสำหรับ DNS ไม่ถูกต้อง และ “เสร็จ” หมายถึงอะไร (โดเมนยืนยัน, HTTPS ทำงาน, และแผน rollback ปลอดภัย)\n\n## เปลี่ยบโน้ตรกให้เป็นเกณฑ์การยอมรับ\n\nคำขอที่รกผสมเป้าหมาย การเดา และกรณีขอบที่จำได้ครึ่งหนึ่ง งานของคุณคือแปลงสิ่งนั้นให้เป็นประโยคที่ใครก็ทดสอบได้โดยไม่ต้องอ่านใจ เกณฑ์เดียวกันควรนำทางการออกแบบ การเขียนโค้ด การรีวิว และ QA\n\nรูปแบบง่าย ๆ ช่วยให้ชัดเจน คุณสามารถใช้ Given/When/Then หรือหัวข้อสั้น ๆ ที่มีความหมายเดียวกัน\n\n### เทมเพลตเกณฑ์การยอมรับอย่างรวดเร็ว\n\nเขียนแต่ละเกณฑ์ให้เป็นการทดสอบเดียวที่ใครก็สามารถรันได้:\n\n- Given สถานะเริ่มต้น, when ผู้ใช้ทำ X, then เกิด Y\n- รวมกฎการตรวจสอบข้อมูล (ข้อมูลเข้าแบบไหนที่ยอมรับได้)\n- รวมอย่างน้อยกรณีล้มเหลวหนึ่งกรณี (ผู้ใช้เห็นข้อผิดพลาดอะไร)\n- กำหนด “สัญญาณเสร็จ” (QA ตรวจอะไร ผู้ตรวจคาดหวังอะไร)\n\nตอนนี้ใช้มันกับตัวอย่าง สมมติว่าโน้ตเขียนว่า: “ทำให้ snapshots ง่ายขึ้น ฉันอยากย้อนกลับถ้าการเปลี่ยนครั้งล่าสุดพัง” แปลงเป็นประโยคที่ทดสอบได้:\n\n- Given โปรเจกต์มี 2 snapshots, when ฉันเปิดหน้า Snapshots, then ฉันเห็นทั้งสองรายการพร้อมเวลและป้ายสั้น ๆ\n- Given snapshot หนึ่งรายการ, when ฉันคลิก Roll back และยืนยัน, then โปรเจกต์กลับไปยัง snapshot นั้นและแอปถูก build สำเร็จ\n- Given ฉันไม่ใช่เจ้าของโปรเจกต์, when ฉันพยายาม rollback, then ฉันเห็นข้อผิดพลาดและไม่มีอะไรเปลี่ยน\n- Given การ rollback กำลังดำเนินการ, when ฉันรีเฟรชหน้า, then ฉันยังเห็นสถานะและผลสุดท้าย\n- Given การ rollback ล้มเหลว, when มันเสร็จสิ้น, then ฉันเห็นข้อความชัดเจนและเวอร์ชันปัจจุบันยังคงใช้งานได้\n\nถ้า QA รันเช็คพวกนี้และผู้ตรวจยืนยันได้ทั้งใน UI และ logs คุณก็พร้อมจะวางแผนงาน UI และ API และแยกเป็นคอมมิตเล็ก ๆ\n\n## ร่างแผน UI ขั้นพื้นฐาน\n\nแผน UI ขั้นพื้นฐานคือคำสัญญา: การเปลี่ยนแปลงที่มองเห็นได้เล็กที่สุดซึ่งพิสูจน์ว่าฟีเจอร์ทำงาน\n\nเริ่มจากการระบุหน้าจอที่จะเปลี่ยนและสิ่งที่คนจะสังเกตเห็นภายใน 10 วินาที หากคำขอคือ “ทำให้ง่ายขึ้น” หรือ “ทำให้สะอาดขึ้น” ให้แปลงเป็นการเปลี่ยนที่จับต้องได้หนึ่งอย่าง\n\nเขียนเป็นแผนเล็ก ๆ ไม่ใช่การออกแบบใหม่ ตัวอย่าง: “หน้าคำสั่งซื้อ: เพิ่มแถบกรองเหนือตาราง” หรือ “การตั้งค่า: เพิ่มสวิตช์ใหม่ใต้การแจ้งเตือน” ถ้าคุณระบุหน้าจอและองค์ประกอบที่เปลี่ยนไม่ได้ ขอบเขตยังไม่ชัด\n\n### กำหนดสถานะ UI สำคัญ\n\nการเปลี่ยน UI มักต้องการสถานะที่คาดเดาได้บางอย่าง ระบุเฉพาะสถานะที่ใช้:\n\n- กำลังโหลด\n- ว่าง\n- ข้อผิดพลาด (และมีปุ่มลองใหม่หรือไม่)\n- สำเร็จ (toast ข้อความในบรรทัด รายการอัปเดต)\n\n### ยืนยันข้อความที่ผู้ใช้จะเห็น\n\nข้อความ UI เป็นส่วนหนึ่งของขอบเขต บันทึกป้ายและข้อความที่ต้องอนุมัติ: ข้อความปุ่ม ป้ายช่อง ข้อความช่วย และข้อความผิดพลาด หากคำลงท้ายยังไม่แน่นอน ให้ระบุเป็นข้อความชั่วคราวและบอกว่าใครจะยืนยัน\n\nเก็บบันทึก “ไม่ใช่ตอนนี้” สำหรับสิ่งที่ไม่จำเป็นต้องใช้ฟีเจอร์ (การปรับแต่ง responsive, การเรียงขั้นสูง, แอนิเมชัน, ไอคอนใหม่)\n\n## ร่างแผน API และข้อมูลขั้นพื้นฐาน\n\nงานที่กำหนดขอบเขตต้องมีสัญญาเล็ก ๆ ชัดเจนระหว่าง UI, backend, และข้อมูล เป้าหมายไม่ใช่ออกแบบทั้งระบบ แต่คือการนิยามชุดคำร้องและฟิลด์ที่เล็กที่สุดที่พิสูจน์ว่าฟีเจอร์ทำงาน\n\nเริ่มจากการระบุข้อมูลที่ต้องการและมาจากไหน: ฟิลด์ที่มีอยู่ที่อ่านได้, ฟิลด์ใหม่ที่ต้องเก็บ, และค่าที่คำนวณได้ หากคุณไม่สามารถบอกแหล่งที่มาของแต่ละฟิลด์ได้ แปลว่าคุณยังไม่มีแผน\n\nรักษาพื้นผิว API ให้เล็ก สำหรับหลายฟีเจอร์ หนึ่งการอ่านและหนึ่งการเขียนก็พอ:\n\n- GET /items/{id} คืนค่าสถานะที่ต้องการเพื่อเรนเดอร์หน้าจอ\n- POST /items/{id}/update รับเฉพาะสิ่งที่ผู้ใช้เปลี่ยนและคืนค่าสถานะที่อัปเดต\n\nเขียนอินพุตและเอาต์พุตเป็นวัตถุธรรมดา ไม่ใช่ย่อหน้ารายละเอียด รวมฟิลด์ที่จำเป็น vs ตัวเลือก และสิ่งที่จะเกิดขึ้นเมื่อพบข้อผิดพลาดทั่วไป (ไม่พบ, ตรวจสอบล้มเหลว)\n\nทำการตรวจสอบสิทธิ์อย่างรวดเร็วก่อนแตะฐานข้อมูล ตัดสินใจว่าใครอ่านได้และใครเขียนได้ และเขียนกฎเป็นประโยคเดียว (ตัวอย่าง: “ผู้ใช้ที่ลงชื่อเข้าใช้ทุกคนอ่านได้ ผู้ดูแลระบบเท่านั้นที่เขียนได้”) การข้ามขั้นตอนนี้มักนำไปสู่การทำงานซ้ำ\n\nสุดท้าย ตัดสินใจว่าสิ่งใดต้องเก็บและสิ่งใดคำนวณ กฎง่าย ๆ: เก็บข้อเท็จจริง คำนวณมุมมอง\n\n## ใช้ Claude Code เพื่อผลิตงานที่กำหนดขอบเขต\n\nClaude Code ทำงานได้ดีที่สุดเมื่อคุณให้เป้าหมายชัดเจนและขอบเขตแคบ ๆ เริ่มโดยวางคำขอที่รกและข้อจำกัด (เส้นตาย ผู้ใช้ที่ได้รับผลกระทบ กฎข้อมูล) แล้วขอเอาต์พุตที่กำหนดขอบเขตซึ่งรวม:\n\n1. สรุปขอบเขตเป็นภาษาธรรมชาติและเช็คลิสต์เกณฑ์การยอมรับสั้น ๆ\n2. ลำดับคอมมิตขนาดเล็ก (ตั้งเป้า 3–7) แต่ละคอมมิตมีผลลัพธ์ชัดเจน\n3. ไฟล์หรือโฟลเดอร์ที่น่าจะถูกแก้ต่อคอมมิต และสิ่งที่เปลี่ยนภายใน\n4. แผนการทดสอบสั้นต่อคอมมิต (เส้นทางที่สำเร็จและกรณีขอบหนึ่งอย่าง)\n5. บันทึกสิ่งที่ไม่รวมในขอบเขต\n\nหลังจากได้รับคำตอบ อ่านเหมือนผู้ตรวจ หากคุณเห็นวลีอย่าง “ปรับปรุงประสิทธิภาพ” หรือ “ทำให้สะอาดขึ้น” ให้ขอคำที่วัดได้\n\n### ตัวอย่างสั้น ๆ (ตัวอย่างของสิ่งที่ “ดี” เท่าที่ควรจะเป็น)\n\nคำขอ: “เพิ่มวิธีพักสมัครสมาชิก”\n\nเวอร์ชันที่กำหนดขอบเขตอาจระบุว่า: “ผู้ใช้สามารถพักได้ 1–3 เดือน; วันที่เรียกเก็บเงินถัดไปอัปเดต; ผู้ดูแลเห็นสถานะพัก” และสิ่งที่ไม่รวม: “ไม่มีการเปลี่ยน prorate”\n\nจากนั้นแผนคอมมิตจะเป็นแบบปฏิบัติ: คอมมิตหนึ่งสำหรับโครงสร้าง DB และ API, คอมมิตหนึ่งสำหรับคอนโทรล UI, คอมมิตหนึ่งสำหรับการตรวจสอบและสถานะข้อผิดพลาด, คอมมิตหนึ่งสำหรับการทดสอบ end-to-end\n\n## แยกงานเป็นคอมมิตเล็ก ๆ ที่รีวิวได้\n\nการเปลี่ยนแปลงใหญ่ซ่อนบั๊ก คอมมิตเล็กทำให้การรีวิวเร็วขึ้น ทำให้การย้อนกลับปลอดภัย และช่วยให้สังเกตเมื่อหลุดจากเกณฑ์การยอมรับ\n\nกฎที่มีประโยชน์: แต่ละคอมมิตควรปลดล็อกพฤติกรรมใหม่หนึ่งอย่าง และรวมวิธีพิสูจน์สั้น ๆ ว่ามันทำงาน\n\nลำดับทั่วไปมีลักษณะดังนี้:\n\n- โมเดลข้อมูลหรือตัวมิเกรต (ถ้าจำเป็น) พร้อมเทสต์\n- พฤติกรรม API และการตรวจสอบ\n- เชื่อม UI กับสถานะว่างและข้อผิดพลาด\n- บันทึกหรือการวิเคราะห์เฉพาะที่ต้องการ แล้วค่อยแต่งเล็กน้อย\n\nทำให้แต่ละคอมมิตมีจุดประสงค์ หลีกเลี่ยงการรีแฟกเตอร์ “ขณะนี้ฉันอยู่ที่นี่” เก็บแอปให้ทำงานแบบ end-to-end แม้ UI จะพื้นฐาน อย่ารวมมิเกรชัน พฤติกรรม และ UI เป็นคอมมิตเดียวเว้นแต่มีเหตุผลชัดเจน\n\n## การเดินผ่าน: “ส่งออกรายงาน”\n\nผู้มีส่วนได้ส่วนเสียพูดว่า: “เพิ่มการส่งออกรายงานได้ไหม?” มันซ่อนตัวเลือกมากมาย: รายงานแบบไหน รูปแบบอะไร ใครส่งออกได้ และส่งอย่างไร\n\nถามเฉพาะคำถามที่เปลี่ยนการออกแบบ:\n\n- ประเภทรายงานใดอยู่ในขอบเขตสำหรับ v1?\n- รูปแบบใดที่ต้องการสำหรับ v1 (CSV, PDF)?\n- ใครส่งออกได้ (admins, บทบาทเฉพาะ)?\n- เป็นดาวน์โหลดตรงหรือส่งทางอีเมล?\n- ข้อจำกัดอะไรบ้าง (ช่วงวันที่สูงสุด, จำนวนแถวสูงสุด, เวลาหมดเวลา)?\n\nสมมติคำตอบว่า: “Sales Summary, CSV เท่านั้น, บทบาทผู้จัดการ, ดาวน์โหลดตรง, สูงสุด 90 วัน” ตอนนี้เกณฑ์ยอมรับ v1 ชัดเจน: ผู้จัดการคลิก Export บนหน้า Sales Summary; CSV ตรงกับคอลัมน์บนตาราง; การส่งออกเคารพตัวกรองปัจจุบัน; การส่งออกมากกว่า 90 วันจะแสดงข้อผิดพลาดชัดเจน; การดาวน์โหลดเสร็จภายใน 30 วินาทีสำหรับสูงสุด 50k แถว\n\nแผน UI ขั้นพื้นฐาน: ปุ่ม Export ใกล้การกระทำของตาราง, สถานะกำลังโหลดขณะสร้างไฟล์, และข้อความข้อผิดพลาดที่บอกวิธีแก้ (เช่น “เลือก 90 วันหรือน้อยกว่า”)\n\nแผน API ขั้นพื้นฐาน: endpoint เดียวที่รับตัวกรองและคืน CSV เป็นไฟล์ตอบกลับ โดยใช้คิวรีเดียวกับตารางและบังคับกฎ 90 วันฝั่งเซิร์ฟเวอร์\n\nแล้วส่งของในคอมมิตแคบ ๆ: ก่อนอื่น endpoint สำหรับเส้นทางที่สำเร็จคงที่ จากนั้นเชื่อม UI แล้วตรวจสอบและข้อความแสดงแก่ผู้ใช้ สุดท้ายทดสอบและเอกสาร\n\n## ข้อผิดพลาดทั่วไปในการกำหนดขอบเขต (และวิธีเลี่ยง)\n\n### ความต้องการแอบแฝงแทรกตัวเข้ามา\n\nคำขออย่าง “เพิ่มบทบาททีม” มักแอบกฎเกี่ยวกับการเชิญ แก้ไข และเกิดอะไรขึ้นกับผู้ใช้เดิม ถ้าคุณกำลังเดาให้เขียนสมมติฐานนั้นลงไปแล้วเปลี่ยนเป็นคำถามหรือกฎชัดเจน\n\n### การขัดเกลาด้าน UI ปะปนกับพฤติกรรมหลัก\n\nทีมเสียเวลาหลายวันเมื่อหนึ่งงานรวมทั้ง “ทำให้ทำงานได้” และ “ทำให้สวย” ไว้ด้วยกัน ให้โฟกัสครั้งแรกที่พฤติกรรมและข้อมูล แยกสไตลิง แอนิเมชัน และช่องว่างเป็นงานถัดไป เว้นแต่จำเป็นต้องใช้ฟีเจอร์\n\n### พยายามแก้ทุกกรณีขอบใน v1\n\nกรณีขอบสำคัญ แต่ไม่จำเป็นต้องจัดการทั้งหมดในทันที แก้เท่าที่จะทำให้ความเชื่อมั่นไม่พัง (double submits, การแก้ไขขัดแย้ง) และเลื่อนที่เหลือพร้อมบันทึกชัดเจน\n\n### สถานะข้อผิดพลาดและสิทธิ์ถูกเลื่อนไปเป็น "ทีหลัง"\n\nถ้าไม่เขียนไว้ คุณจะพลาดมัน รวมอย่างน้อยหนึ่งเส้นทางไม่สำเร็จและกฎสิทธิ์หนึ่งข้อในเกณฑ์การยอมรับ\n\n### เกณฑ์ที่คุณตรวจสอบไม่ได้\n\nหลีกเลี่ยงคำว่า “เร็ว” หรือ “น่าใช้งาน” เว้นแต่จะแนบตัวเลขหรือการตรวจสอบที่ชัดเจน แทนที่ด้วยสิ่งที่พิสูจน์ได้ในการรีวิว