Dikaya Pro 2: ทบทวนโค้ดด้วยกรณีทดสอบ ไม่ใช่คำรับรองลอยๆ

ตัวอย่าง API ขั้นต่ำ

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

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://dikaya.cc/v1",
    api_key=os.environ["DIKAYA_API_KEY"],
    max_retries=0,
)
response = client.chat.completions.create(
    model="seller-pro-2",
    max_tokens=512,
    messages=[{"role": "user", "content": "สร้างรายการตรวจสอบสำหรับงานของฉัน แยกข้อเท็จจริงจากแหล่งข้อมูลออกจากสมมติฐาน"}],
)
print(response.choices[0].message.content)

เริ่มจากกติกาที่คนในโครงการยืนยันแล้ว

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

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

ขอกรณีทดสอบก่อนขอแพตช์

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

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

อ่านแพตช์โดยดูสิ่งที่ต้องไม่เปลี่ยน

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

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

ใช้เดโมกับตัวอย่างเล็กที่พิสูจน์ได้

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

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

ไม่สับสนระหว่างผู้เสนอรหัสกับผู้รันคำสั่ง

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

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

ควบคุมการส่งและเก็บหลักฐานการทบทวน

ใน Python SDK ตั้ง max_retries=0 และกำหนดเพดานคำตอบชัดเจน ใช้รหัส seller-pro-2 ไม่สลับกับ GLM 5.3 อีกตัว คู่มือ SDK รองรับคำอธิบายเรื่องการส่งซ้ำและชนิดข้อผิดพลาด ไม่ใช่หลักฐานว่าทุกความสามารถเข้ากันได้หรือโมเดลพร้อมให้บริการแน่นอน หากการเชื่อมต่อขาด ผลกับค่าใช้จ่ายอาจยังไม่ทราบ ต่างจาก HTTP ปฏิเสธที่ยืนยันแล้ว

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

คำถามและคำตอบ

Pro 2 กับ seller-glm-5-3 ใช้รหัสแทนกันได้หรือไม่?

ไม่ได้ ทั้งสองเป็นรหัสสาธารณะคนละตัว แม้ Pro 2 จะอธิบายได้ว่าเป็นรุ่นปรับแก้บนพื้นฐาน GLM-5.3 ก็ไม่ควรรวมการตั้งค่า สิทธิ์ หรือบันทึกผลเป็นตัวเดียวกัน เก็บรหัสที่ส่งจริงไว้เพื่อให้ตรวจย้อนกลับได้ถูกต้อง

โมเดลบอกว่าทดสอบผ่านแล้ว ต้องรันเองอีกหรือไม่?

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

ควรทำอย่างไรถ้ากติกาเวลาติดกันยังตกลงไม่ได้?

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

เดโมให้พื้นที่พอส่งทั้งคลังโค้ดเพราะบริบทใหญ่หรือไม่?

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

แหล่งข้อมูล

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

• Dikaya: รายการโมเดลและเงื่อนไขการเลือกใช้งาน
  dikaya.cc
• Dikaya: คู่มือ API และขอบเขตของคำขอ
  dikaya.cc
• Dikaya: ราคาสาธารณะสำหรับตรวจสอบเงื่อนไข
  dikaya.cc
• เอกสาร Python SDK: ข้อผิดพลาดและการปิดส่งคำขอซ้ำ
  github.com
• คู่มือ MDN: สถานะ HTTP การอ่านผลและยกเลิก Fetch
  developer.mozilla.org