7 กรณีใช้งาน Jev ที่ช่วยลดงานจริงในซอฟต์แวร์

มีคนถามเว็บไซต์ของเราว่ามีการเชื่อมต่อกี่รายการ เว็บไซต์กลับตอบด้วยคำแนะนำว่าฟอร์มสมัครใช้งานควรมีช่องข้อมูลกี่ช่อง

คำตอบมาอย่างรวดเร็ว แต่ใช้ประโยชน์ไม่ได้

คำถามทั้งสองมีคำว่า “กี่” โค้ดค้นหาของเราให้คะแนนขั้นต่ำ 0.86 กับคำถามพบบ่อยที่ถือว่าตรงกัน ทำให้ผลที่ตรงเพียงเล็กน้อยดูน่าเชื่อถือ ความเร็วซ่อนการตัดสินใจที่ผิดไว้

ความล้มเหลวแบบนี้ควรอยู่ในใจเมื่อดู Ship with Jev ณ วันที่ 26 กันยายน 2026 ไดเรกทอรีนี้มีผลงานจากชุมชน 551 รายการ ทั้งเกม ส่วนประกอบการค้นหา เอเจนต์เบราว์เซอร์ เครื่องมือวิจัย และการทดลองส่งต่อคำขอ ตัวเลขประสิทธิภาพในไดเรกทอรีมาจากผู้สร้างแต่ละราย จึงเป็นเครื่องมือค้นหาผลงาน ไม่ใช่เกณฑ์ทดสอบอิสระ

คำถามที่น่าสนใจคือ รูปแบบใดในนั้นช่วยลดงานของผลิตภัณฑ์จริง

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

Jev เพิ่มอะไรให้แอปพลิเคชัน

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

แนวคิดที่มาก่อนเรื่องความแตกต่างนี้ปรากฏในข้อมูล YouTube ที่เรานำเข้ามา ในการบรรยายของ Diogo Almeida ที่ AI Engineer ผู้ร่วมก่อตั้ง TypeSafe เสนอซอฟต์แวร์ที่หน่วยพื้นฐานสามารถแสดงความฉลาดได้มากขึ้น เขาเปรียบแนวทางนี้กับการติดผู้ช่วยเข้ากับซอฟต์แวร์เดิม นี่คือความเห็นของเขาเกี่ยวกับทิศทาง AI ไม่ใช่ผลทดสอบประสิทธิภาพปัจจุบันของ Jev

ลองนึกถึงทางแยกรางรถไฟ ผลลัพธ์ที่มีประโยชน์คือบอกว่ารถไฟควรไปตามรางใดที่ใช้ได้ ย่อหน้าที่อธิบายรางไม่ได้ช่วยสับราง

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

ควรเริ่มจากความท้าทายของ CLM

วันที่ 23 กันยายน Jacky Kwok, Hangoo Kang, Tarun Suresh, Jon Saad-Falcon, Marco Pavone, Christopher Ré และ Azalia Mirhoseini เผยแพร่ Contrastive Language Models ผลงานของพวกเขาท้าทายสมมติฐานที่ว่า Jev เป็นวิธีที่ใช้ได้จริงเพียงทางเดียวสำหรับการตัดสินใจเชิงความหมายที่รวดเร็ว

ผู้เขียนรายงานว่าผลแบบไม่มีตัวอย่างล่วงหน้าสำหรับงานใช้คอมพิวเตอร์ เกม และการเรียกเครื่องมือใกล้เคียงกับ Jev แต่เวลาแฝงต่ำกว่าได้ถึง 9 เท่า อีกชุดผลลัพธ์คือ 81.6% ในงาน DeepSWE ที่กันไว้ 38 งาน และ 87.6% ในงาน Terminal-Bench 2.1 จำนวน 30 งาน ผลด้านโค้ดเหล่านี้ใช้ตัวตรวจสอบ CLM ที่ปรับจูนแล้ว เพื่อเลือกจากคำตอบที่โมเดลอื่นสร้างขึ้น ผู้เขียนยังรายงานว่า Jev ต่ำกว่าเกณฑ์พื้นฐานการสุ่มเลือกของพวกเขาในการทดสอบตัวตรวจสอบชุดนั้น เวลาแฝงวัดบน H100 ทั้งหมดเป็นผลของผู้เขียนที่เรายังไม่ได้ทำซ้ำโดยอิสระ ดูผลประเมินและวิธีการต้นฉบับ

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

CLM เข้ารหัสสถานะกับการกระทำที่เป็นตัวเลือกแยกกัน ทำให้แคชเวกเตอร์ของการกระทำที่นำกลับมาใช้ได้ ที่เก็บโค้ด ระบุอินเทอร์เฟซที่ใช้ร่วมกับ TypeSafe ได้ และขีดจำกัดสถานะเริ่มต้น 2,048 โทเค็น โดยจะตัดสถานะที่ยาวกว่าออกหากไม่ตั้งค่าเป็นอย่างอื่น การใช้ API ร่วมกันได้ไม่ได้พิสูจน์ว่าจะตัดสินใจเหมือนกัน

การ์ดโมเดลที่เผยแพร่ ระบุเวกเตอร์จาก Qwen3-8B และเตือนว่าผลการตรวจสอบที่ดีต้องใช้ส่วนหัวที่ปรับจูนแล้ว อีกทั้งระบุชัดว่า CLM ให้คะแนนตัวเลือกที่ส่งมา ไม่ได้สร้างคำตอบใหม่ น้ำหนักโมเดลแบบเปิดช่วยให้ประเมินได้ แต่ฮาร์ดแวร์ การให้บริการ และการดูแลรักษายังมีต้นทุน

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

เวิร์กโฟลว์เจ็ดแบบด้านล่างยังน่าประเมิน คุณค่าของมันไม่ได้ขึ้นอยู่กับการที่ Jev ชนะทุกการเปรียบเทียบ

1. ค้นหาโดยตรวจว่าผลลัพธ์ตอบคำถามจริง

นี่เป็นตัวเลือกแรกของผม เพราะเห็นความผิดพลาดได้และติดป้ายผลลัพธ์ได้ง่าย ข้อความที่ส่งกลับมาตอบสิ่งที่ผู้เยี่ยมชมถามหรือไม่

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

1. การค้นหา

   คำสำคัญ, เวกเตอร์

   ตัวเลือกจำนวนเล็กน้อย

   เพิ่มสิ่งที่พลาดไปไม่ได้
2. Jev

   การตัดสินใจแบบมีชนิดข้อมูล

   ข้อความนี้

   ให้ข้อเท็จจริงหรือไม่?
3. คำตอบ

   หรือไม่มีคำตอบ

   ถูกต้องหรือยังไม่ตอบ

   วัดเวลาแฝงรวม

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

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

jevsearch ที่ Kyle McLaren สร้าง ทำให้ลำดับชัดเจน: ผลจากคำสำคัญมาก่อน แล้วจึงจัดอันดับด้วย Jev เกณฑ์ทดสอบที่เผยแพร่ใช้ชุดเอกสารของโครงการเองกับคำถามที่ติดป้ายคำตอบไว้ เป็นหลักฐานที่มีประโยชน์ต่อการทดสอบนั้น ไม่ใช่คำรับประกันสำหรับเว็บไซต์หรือภาษาอื่น

วัดคำตอบที่ถูกต้อง คำตอบที่ไม่มีหลักฐาน คำถามที่ยังตอบไม่ได้ และเวลาแฝงรวม รวมคำที่สะกดผิดและคำถามที่แปลภาษาแล้วด้วย ผลที่ไม่เกี่ยวข้องยังไม่เกี่ยวข้องแม้จะมาเร็ว

2. ส่งคำขอไปยังหน้า คิว หรือเอเจนต์ที่เหมาะ

ผู้ใช้เขียนว่า “เปลี่ยนบัญชีแล้วรายชื่อติดต่อไม่เข้ามา” แอปของคุณต้องแยกให้ออกว่าเป็นการแก้ปัญหาการเชื่อมต่อ เรื่องการเรียกเก็บเงิน การจับคู่ฟิลด์ หรือคำขอสร้างการซิงค์ใหม่

ส่งหน้าจอปัจจุบัน บทสนทนาล่าสุด และปลายทางที่ผู้ใช้นั้นเข้าถึงได้ ขอปลายทางที่เหมาะที่สุด พร้อมตัวเลือก “ไม่ตรงกับที่ใด” อย่างชัดเจน ให้แอปควบคุมรหัสของปลายทางเอง

การตัดสินใจหลายอย่างอาจมีประโยชน์พร้อมกัน ได้แก่ เจตนา ปลายทาง ความเร่งด่วน และข้อความมีคำขอที่ลงมือทำได้หรือไม่ รูปแบบ fan-out ของ TypeSafe ให้คำถามอิสระใช้คำขอเดียวกันได้ จากนั้นโค้ดนำคำตอบที่เกี่ยวข้องไปใช้

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

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

3. เปลี่ยนข้อมูลที่ยุ่งเหยิงเป็นการเชื่อมต่อที่เชื่อถือได้

นี่คือเวิร์กโฟลว์การเชื่อมต่อที่เสนอ ไฟล์ส่งออกต้นทางมี customer_email, billing_email และ account_owner_email ส่วนปลายทางต้องการอีเมลของผู้ติดต่อ

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

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

1. โค้ด

   หาตัวเลือก

   customer_email

   billing_email

   account_owner_email
2. Jev

   เลือกหนึ่งฟิลด์

   คำอธิบายฟิลด์

   ค่าตัวอย่าง, วัตถุประสงค์
3. โค้ด

   คัดลอกค่าเดิม

   ชนิดข้อมูล, ค่าที่จำเป็น

   ข้อจำกัดของปลายทาง

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

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

วัดระเบียนที่ถูกปฏิเสธและการจับคู่ผิดเทียบกับตัวอย่างที่ตรวจทานแล้ว คำขอ API สำเร็จพิสูจน์ว่าได้รับข้อมูลที่ส่งไป ไม่ได้พิสูจน์ว่าอีเมลที่ถูกต้องไปถึงผู้ติดต่อที่ถูกต้อง

4. เลือกโมเดลที่เล็กที่สุดซึ่งทำงานสำเร็จ

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

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

Jev Router ของ OpenRouter ให้รูปแบบนี้ผ่าน API แชตด้วยรหัสโมเดล typesafe/jev-router หน้ารายการระบุว่าเลือกทั้งโมเดลและระดับการใช้เหตุผลตามบทสนทนาที่เปลี่ยนไป ก่อนใช้จริงต้องประเมินโมเดลปลายทางที่อนุญาต ค่าใช้จ่ายจริง การจัดการข้อมูล และพฤติกรรมระหว่างการเรียกเครื่องมือ เราตรวจหน้ารายการแล้ว แต่ยังไม่ได้ทดสอบประสิทธิภาพตัวส่งต่อนี้

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

งานนี้ต้องการอะไร?

1. กฎและข้อเท็จจริงที่แน่นอน

   โค้ดทั่วไป

2. คำถามเชิงความหมายที่มีขอบเขต

   โมเดลตัดสินใจ

3. การเขียนหรือการพัฒนา

   โมเดลสร้างเนื้อหาที่เหมาะสม

4. หลักฐานบ่งชี้ว่าต้องการมากกว่านั้น

   ส่งต่อระดับสูงขึ้น

ตัวส่งต่อเองใช้เวลาและเงิน งานซ้ำที่ชัดเจนอาจใช้กฎตายตัวได้ดีกว่า ส่วนงานกำกวมให้เปรียบเทียบการส่งต่อกับเกณฑ์พื้นฐานที่ใช้โมเดลเดียว โดยดูงานที่ทำเสร็จจริง

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

5. ตรวจข้อกล่าวอ้างก่อนกลายเป็นคำตอบถึงลูกค้า

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

คู่มือตรวจสอบการอ้างอิง ของ TypeSafe แยกการตรวจสองแบบ การเทียบข้อความธรรมดาตรวจหาคำอ้างที่หายไป การตัดสินใจเชิงความหมายประเมินว่าบริบทของแหล่งข้อมูลรองรับข้อกล่าวอ้างหรือไม่

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

การทำงานเสร็จยังต้องมีหลักฐานตรง การทดสอบพิสูจน์พฤติกรรมที่ทดสอบ บันทึกการเผยแพร่พิสูจน์ว่ามีการเผยแพร่ การตัดสินใจเชิงความหมายชี้ว่ารายงานไม่ตรงกับหลักฐานได้ แต่สร้างหลักฐานที่ขาดไม่ได้

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

6. เปลี่ยนบทถอดเสียงและความเห็นลูกค้าเป็นรายการคัดเลือกที่ใช้ได้

คลังบทถอดเสียงมีประโยชน์เมื่อหาช่วงสำคัญได้ ตัวกรอง “มีคำว่าการเชื่อมต่อ” อ่อนกว่าคำถาม “อธิบายว่าทำไมลูกค้าจึงเลิกตั้งค่า” มาก

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

แนบ URL ต้นทางและเวลาของช่วงไว้กับทุกข้อความที่เลือก เวลามาจากบทถอดเสียง ส่วนโมเดลตัดสินความเกี่ยวข้อง

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

รูปแบบการให้คะแนนหลายมิติ ของ TypeSafe เก็บมิติแยกกัน เพื่อให้โค้ดปรับน้ำหนักได้ คลิปที่เหมาะกับบทสอนอาจต่างจากคลิปที่เหมาะกับการสาธิตผลิตภัณฑ์สั้น ๆ ใช้การตัดสินใจเดิมซ้ำเมื่อหลักฐานและเกณฑ์ยังไม่เปลี่ยน

JevQL เป็นผลงานชุมชนที่เกี่ยวข้อง มีเงื่อนไขเชิงความหมายบนแถว PostgreSQL โดยประเมินนอกฐานข้อมูล เอกสารของโครงการแสดงว่าตัวกรองทั่วไปมีผลต่อค่าใช้จ่าย ลดจำนวนแถวที่เข้าเกณฑ์ก่อนขอการตัดสินใจเชิงความหมาย

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

7. อินเทอร์เฟซที่เลือกการกระทำถัดไปที่เป็นประโยชน์

หน้าตั้งค่าอาจได้รับคำว่า “หยุดการซิงค์นี้จนถึงพรุ่งนี้” เอเจนต์เบราว์เซอร์อาจต้องเลือกจากปุ่มควบคุมที่เห็นบนหน้าปัจจุบัน

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

Ship with Jev มีเดโมค้นหาเที่ยวบินผ่านเบราว์เซอร์ของ Gregor Zunic เวลาและต้นทุนที่รายงานเป็นของเดโมนี้ แนวคิดที่นำไปใช้ได้คือเลือกจากการกระทำที่มีในแต่ละขั้นตอน ส่วนการทำงานในเบราว์เซอร์แบบอื่นต้องตรวจสอบเอง

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

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

ผมจะเริ่มตรงไหน

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

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

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

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

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

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