คำสั่งที่ดีที่สุดสำหรับ Claude จะช่วยให้งานเข้าใจได้ง่าย: กำหนดเป้าหมายให้ Claude วัสดุที่ควรใช้ ข้อจำกัดที่สำคัญ และวิธีตรวจสอบผลลัพธ์ สำหรับการเขียน ให้รักษาข้อมูลข้อเท็จจริงและขั้นตอนต่อไปของผู้อ่าน สำหรับการวิจัย ให้เชื่อมโยงข้ออ้างกับแหล่งข้อมูล สำหรับการเขียนโค้ด ให้กำหนดพฤติกรรมที่ถูกต้องและดำเนินการทดสอบ.
เริ่มจากงานที่คุณต้องการด้านล่างนี้: เขียนร่างอีเมล, วิเคราะห์ชุดข้อมูลต้นฉบับ หรือแก้ไขฟังก์ชัน Python เลือกจาก 12 แบบแม่แบบที่ปรับใช้ได้ แล้วศึกษาตัวอย่าง 3 ตัวอย่างที่ผ่านการทดสอบด้วย Claude ใน GlobalGPT ตัวอย่างแต่ละตัวอย่างมีคำสั่งและคำตอบครบถ้วน เพื่อให้คุณเห็นได้ว่าควรคัดลอกส่วนใด ปรับเปลี่ยนส่วนใด และตรวจสอบส่วนใดในงานของคุณเอง.
หากงานของคุณเริ่มจากขั้นตอนการวิจัย ไปสู่การเขียน และต่อมาสู่การเขียนโค้ด, โกลบอลจีพีที นำ Claude และโมเดลชั้นนำอื่นๆ มาพร้อมกับเครื่องมือ AI หลากหลายชนิด รวมไว้ในแพ็กเกจสมัครสมาชิกราคาประหยัดและแดชบอร์ดเดียว คุณสามารถจัดการเวิร์กโฟลว์โดยรวมได้อย่างเป็นระบบ และเลือกโมเดลหรือฟังก์ชันที่เหมาะสมกับขั้นตอนต่อไป.
บนหน้านี้
สรุปคำสั่งที่ดีที่สุดสำหรับ Claude
เลือกแม่แบบตามการตัดสินใจหรือผลลัพธ์ที่ต้องการ ก่อนส่ง ให้แทนที่ส่วนที่อยู่ในวงเล็บ แม่แบบสำหรับการเขียนและการวิจัยสามารถใช้งานได้กับข้อความที่คัดลอกและวาง ส่วนคำสั่งการเขียนโค้ดที่ขอสิทธิ์เข้าถึงไฟล์หรือการรันโปรแกรม จำเป็นต้องใช้เครื่องมือที่สามารถดำเนินการเหล่านั้นได้จริง.
รูปแบบเริ่มต้นที่สามารถใช้ซ้ำได้ก็เพียงพอสำหรับงานหลายประเภทแล้ว. ภาพรวมการออกแบบคำสั่งของ Anthropic เริ่มต้นด้วยเกณฑ์ความสำเร็จและวิธีการทดสอบเกณฑ์เหล่านั้น คุณไม่จำเป็นต้องสร้างโปรไฟล์ผู้เชี่ยวชาญที่ซับซ้อนเพื่อระบุว่าคำตอบที่มีประโยชน์ควรประกอบด้วยอะไรบ้าง.
แม่แบบเริ่มต้นแบบสั้น
ช่วยผม [TASK] สำหรับ [กลุ่มเป้าหมายหรือวัตถุประสงค์].
ใช้วัสดุนี้: [PASTE MATERIAL].
ปฏิบัติตามข้อจำกัดต่อไปนี้: [ข้อเท็จจริง, ขอบเขต, ความยาว หรือกฎ].
ส่งกลับ [OUTPUT FORMAT].
ผลลัพธ์ที่สำเร็จต้อง [ข้อกำหนดที่สามารถตรวจสอบได้].
หากขาดรายละเอียดที่จำเป็น ให้ถามคำถามเฉพาะที่ทำให้งานไม่สามารถดำเนินการต่อได้.ใช้หัวข้อหรือแท็กเมื่อมันช่วยให้การแบ่งส่วนในบรีฟที่ซับซ้อนเป็นไปได้ง่ายขึ้น. แนวทางให้คำแนะนำของ Anthropic ในปัจจุบัน แนะนำให้ใช้คำแนะนำที่ชัดเจน ตัวอย่างที่มีประโยชน์ และแท็ก XML ที่อธิบายรายละเอียดสำหรับเนื้อหาผสม แท็กช่วยจัดระเบียบข้อความ แต่ไม่สร้างหลักฐาน ไม่ให้สิทธิ์เข้าถึงเครื่องมือ และไม่ทำให้คำตอบถูกต้อง.
Claude: หัวข้อสำหรับการเขียน
ในการเขียน ส่วนที่ยากที่สุดมักอยู่ที่การรักษาความกระชับไว้ขณะปรับเปลี่ยนวิธีการแสดงออก ให้ระบุชัดเจนว่าผู้อ่านต้องทำอะไร และรายละเอียดใดเป็นสิ่งที่แน่นอน ประโยคที่ไหลลื่นก็ไม่มีประโยชน์หากมันแอบแฝงคำสัญญาไว้.
1. เขียนอีเมลจากข้อมูลสรุปข้อเท็จจริง
คำเชิญ อัปเดต หรืออีเมลถึงลูกค้าที่ชัดเจน พร้อมรายละเอียดที่ต้องถูกต้องตามต้นฉบับ. นำ: สรุปข้อเท็จจริง, กลุ่มเป้าหมาย, การตอบกลับ, และจำนวนคำสูงสุด.
W1 · งานตัวอย่างที่ทดสอบด้านล่างนี้
เขียนอีเมลตามข้อกำหนดในบทสรุป ให้ถือว่าข้อมูลที่ได้รับการยืนยันแล้วเป็นข้อมูลที่แน่นอน แยกคำขอออกจากคำยืนยันอย่างชัดเจน ปฏิบัติตามรูปแบบและจำนวนคำที่กำหนดไว้ ใช้ข้อมูลที่ให้มาเท่านั้น
ผู้รับ: [ใครจะอ่านอีเมลนี้]
วัตถุประสงค์: [อีเมลนี้ควรบรรลุอะไร]
ข้อเท็จจริงที่ได้รับการยืนยัน: [วันที่, เวลา, ราคา, ขีดจำกัด และรายละเอียดอื่นๆ]
รายละเอียดที่ยังไม่ทราบหรือยังไม่ได้รับการอนุมัติ: [สิ่งที่คุณไม่สามารถสัญญาได้]
การดำเนินการของผู้อ่าน: [ขั้นตอนต่อไปที่ชัดเจน]
โทนเสียง: [โทนเสียง]
ผลลัพธ์: บรรทัดหัวข้อและเนื้อหา [จำนวนคำ] คำตรวจสอบผลลัพธ์: ตรวจสอบทุกวันที่ระบุไว้ ทุกตัวเลข ทุกคำสัญญา และขั้นตอนต่อไปให้สอดคล้องกับเอกสารสรุป แม้แต่ประโยคเพิ่มเติมที่เขียนด้วยน้ำเสียงเป็นมิตร ก็อาจก่อให้เกิดภาระผูกพันได้.
2. ให้สไตล์การเขียนของคุณสอดคล้องกับน้ำเสียงของคุณเอง
ร่างสั้นๆ ที่ฟังดูสอดคล้องกับงานของคุณที่มีอยู่. นำ: ตัวอย่างสองหรือสามชิ้นที่คุณเขียนไว้ และข้อมูลสำหรับบทความใหม่.
W2 · แม่แบบที่ปรับแต่งได้
ใช้ตัวอย่างการเขียนของฉันเพื่อระบุลักษณะสไตล์สามประการที่สามารถสังเกตได้ ได้แก่ จังหวะของประโยค ระดับความเป็นทางการ และวิธีการอธิบายแนวคิดของฉัน นำลักษณะเหล่านั้นไปประยุกต์ใช้กับ [รูปแบบ] ใหม่สำหรับ [กลุ่มเป้าหมาย]
ใช้ตัวอย่างเพื่อศึกษาสไตล์การเขียนเท่านั้น ส่วนข้อมูลข้อเท็จจริงให้อ้างอิงจากบรีฟใหม่ ให้ระบุสามลักษณะดังกล่าว แล้วตามด้วยร่างบทความใน [จำนวนคำ] คำ
[วางข้อความเขียนของคุณเอง]
[หัวข้อ, วัตถุประสงค์, ข้อเท็จจริงที่ยืนยันแล้ว, และสิ่งที่ผู้อ่านควรทำ]ตรวจสอบผลลัพธ์: ตรวจสอบจังหวะของประโยคและความชัดเจนของเนื้อหา แล้วตรวจสอบให้แน่ใจว่าข้อมูลตัวอย่างไม่ได้ถูกนำเข้ามาในฉบับร่างใหม่.
เลือกตัวอย่างที่มีสไตล์ที่คุณต้องการรักษาไว้ รายชื่อคำคุณศัพท์ เช่น “เป็นมิตร, มีวิสัยทัศน์, มืออาชีพ” ให้พื้นที่สำหรับการตีความมากกว่าตัวอย่างที่ชัดเจนไม่กี่ตัวอย่าง ส่วนเอกสารสรุปใหม่ควรยังคงเป็นแหล่งข้อมูลรายละเอียดที่เป็นข้อเท็จจริง.
3. ค้นหาการแก้ไขที่มีผลกระทบมากที่สุด
ฉบับร่างที่ดูอ่อนแอ แต่ยังไม่ถึงขั้นต้องเขียนใหม่ทั้งหมด. นำ: ฉบับร่างของคุณ กลุ่มเป้าหมาย จุดประสงค์ และส่วนใดที่ควรเก็บไว้.
W3 · แม่แบบที่ปรับแต่งได้
โปรดตรวจสอบฉบับร่างนี้สำหรับ [กลุ่มเป้าหมาย] ที่ต้องการ [เป้าหมายของผู้อ่าน] โปรดระบุการเปลี่ยนแปลงสูงสุดสามข้อที่จะช่วยปรับปรุงความชัดเจนหรือประโยชน์ได้มากที่สุด หากต้องการเปลี่ยนแปลงน้อยกว่าสามข้อ โปรดระบุไว้
สำหรับแต่ละการแก้ไข ให้อ้างอิงข้อความต้นฉบับ อธิบายปัญหาที่ผู้อ่านอาจพบ และเสนอข้อความทดแทน รักษาความหมายตามข้อเท็จจริงและองค์ประกอบต่อไปนี้: [MUST KEEP] อย่าเขียนใหม่ทั้งฉบับ
[PASTE DRAFT]ตรวจสอบผลลัพธ์: ปฏิเสธผลการวิจัยที่ไม่สามารถชี้ให้เห็นถึงส่วนข้อความที่แท้จริงหรือปัญหาของผู้อ่านที่มีความหมายได้.
4. ใช้เนื้อหาจากแหล่งเดียวเพื่อปรับให้เหมาะกับผู้ชมสองกลุ่ม
การแปลงการอัปเดตที่ได้รับการอนุมัติให้เป็นบันทึกภายในและข้อความสำหรับลูกค้า. นำ: แหล่งข้อมูลที่ได้รับการอนุมัติหนึ่งแห่ง และเอกสารสรุปข้อมูลผู้ชมสองฉบับ.
W4 · แม่แบบที่ปรับแต่งได้
ปรับเนื้อหาต้นฉบับที่ได้รับการอนุมัติให้เป็นสองเวอร์ชันสั้น:
A. [รูปแบบ, กลุ่มเป้าหมาย, วัตถุประสงค์, จำนวนคำสูงสุด]
B. [รูปแบบ, กลุ่มเป้าหมาย, วัตถุประสงค์, จำนวนคำสูงสุด]
รักษาวันที่, ตัวเลข, ความพร้อมใช้งานของฟีเจอร์ และข้อผูกพันให้สอดคล้องกัน ปรับเปลี่ยนคำอธิบายและจุดเน้นให้เหมาะสมกับผู้อ่านแต่ละกลุ่ม หากผู้อ่านกลุ่มใดต้องการรายละเอียดที่แหล่งข้อมูลต้นฉบับไม่มี ให้ระบุช่องว่างดังกล่าวไว้หลังร่าง
[PASTE SOURCE]ตรวจสอบผลลัพธ์: เปรียบเทียบทั้งสองเวอร์ชันด้วยรายการข้อเท็จจริงเดียวกัน; ผู้ชมใหม่ไม่ได้ให้สิทธิ์ในการเพิ่มคุณสมบัติหรือคำสัญญาใหม่.
ลองทำกิจกรรมเหล่านี้ใน GlobalGPT
เปลี่ยนเอกสารสรุปเป็นอีเมล เปลี่ยนชุดข้อมูลจากแหล่งเป็นคำแนะนำ และเปลี่ยนรายงานข้อผิดพลาดเป็นการแก้ไข.
เราได้ใช้ Claude Sonnet 5 ใน GlobalGPT สำหรับทั้งสามงาน ร่างอีเมลได้เก็บรายละเอียดเหตุการณ์สำคัญไว้ คำตอบจากการวิจัยได้ระบุเหตุผลที่ควรเลื่อนการเปิดตัวออกไป และการแก้ไขโค้ด Python ทั้งสองได้ผ่านการตรวจสอบทั้ง 24 ข้อเมื่อเราทดสอบแยกกัน นี่เป็นจุดเริ่มต้นที่มีประโยชน์สำหรับงานที่คุณสามารถนำมารวมไว้ในแดชบอร์ดเดียวกันได้.
หากต้องการลองด้วยตัวเอง ให้เลือกเทมเพลตด้านล่างและแทนที่เนื้อหาตัวอย่างด้วยเนื้อหาของคุณเอง GlobalGPT รวมเครื่องมือการเขียน การวิจัย การเขียนโค้ด และเครื่องมือ AI อื่นๆ ไว้ในแพ็กเกจสมัครสมาชิกราคาประหยัดเพียงแพ็กเกจเดียว ทำให้คุณสามารถก้าวจากขั้นตอนการเข้าใจปัญหาไปสู่การร่างผลงานถัดไปได้อย่างราบรื่น โดยไม่ต้องสลับไปมาระหว่างบริการต่างๆ.
วิธีที่เราเปรียบเทียบคำสั่ง
เมื่อวันที่ 14 กันยายน 2569 แต่ละงานได้รับคำสั่งสองชุดที่มีแหล่งข้อมูลสมมติและข้อกำหนดเดียวกัน: คำสั่งสั้นๆ หนึ่งชุด และคำสั่งที่มีโครงสร้างชัดเจนขึ้นอีกหนึ่งชุด เราเก็บคำตอบที่สมบูรณ์ชุดแรกจากแต่ละชุดไว้ รวมทั้งหมดหกคำตอบ การวิจัยใช้ข้อความที่ให้ไว้ ส่วนโค้ด Python ที่ส่งกลับมาได้รับการตรวจสอบแยกต่างหาก และไม่ได้ถูกโมเดลนำไปรันระหว่างการสนทนา.
ตัวอย่างเหล่านี้ครอบคลุมสามงาน โดยแต่ละงานทำหนึ่งครั้งต่อเวอร์ชัน ข้อมูลนำเข้าและคำตอบครบถ้วนปรากฏอยู่ด้านล่าง พร้อมกับการแก้ไขหรือการตรวจสอบที่แต่ละผลลัพธ์ต้องการ แม่แบบ 12 แบบที่สามารถใช้ซ้ำได้ยังไม่ได้รับการทดสอบแยกกันทั้งหมด.
การเปรียบเทียบผลลัพธ์ครั้งแรก · W
ร่างอีเมลเกี่ยวกับงานโดยใส่รายละเอียดสำคัญไว้แล้ว.
| ตรวจสอบ | คำแนะนำแบบเรียบง่าย | การสอนแบบมีโครงสร้าง |
|---|---|---|
| ข้อมูลหลักและการตรวจสอบการดำเนินการ | 8 / 9 | 8 / 9 |
| ความยาวของหัวและตัว | ผ่าน · 126 คำ | ผ่าน · 128 คำ |
| คำสัญญาในการติดตามผลที่ยังไม่ได้รับการอนุมัติ | ปัจจุบัน | ปัจจุบัน |
ทั้งสองเวอร์ชันยังคงรักษาวันที่ เวลา ความจุ ราคา หมายเหตุ และความแตกต่างระหว่างการขอจองและการยืนยันการจองไว้ ซึ่งทำให้คุณมีร่างที่สามารถแก้ไขได้แทนที่จะเป็นหน้าว่าง ก่อนส่ง ให้ลบคำสัญญาที่จะติดตามผลที่ทั้งสองฉบับไม่ได้ระบุไว้; เวอร์ชันธรรมดา ยังเรียกเซสชันว่า “เหมือนกัน” โดยไม่มีหลักฐานสนับสนุน สำหรับอีเมลของคุณเอง ให้ระบุทั้งข้อเท็จจริงที่ควรรักษาไว้และคำมั่นสัญญาที่คุณได้รับอนุญาตให้ทำ.
การตรวจสอบทั้งแปดข้อ ได้แก่ วันที่; เวลาท้องถิ่นและ UTC; ระยะเวลา; ความจุต่อเซสชัน; การเข้าร่วมแบบไม่เสียค่าใช้จ่าย; บันทึกที่สามารถดาวน์โหลดได้; ห้ามบันทึกเสียง; และการขอจองแทนการยืนยันการจอง ส่วนข้อที่เก้าจะตรวจสอบข้อมูลหรือคำมั่นสัญญาที่แต่งขึ้น จำนวนคำไม่รวมหัวข้อ.
เวลาที่ผ่านไป: 9.73 วินาที / 7.02 วินาที. จำนวนโทเคนข้อมูลเข้า + ข้อมูลออกที่รายงาน: 400 + 617 / 468 + 299. ได้รับคำตอบครั้งละหนึ่งครั้ง; ไม่มีการลองใหม่.
คำแนะนำแบบเรียบง่าย — คำแนะนำและเอกสารต้นฉบับครบถ้วน
เขียนอีเมลตามคำขอในบทสรุปด้านล่าง
รายละเอียดการทดสอบสมมติ นี่เป็นรายละเอียดของเวิร์กช็อปที่สร้างขึ้นเพื่อวัตถุประสงค์การทดสอบ ไม่ใช่ข้อเสนอจริง
คุณกำลังเขียนอีเมลเชิญเข้าร่วมเวิร์กช็อปชุมชนสมมติชื่อ Clear Notes
กลุ่มเป้าหมาย: ผู้นำโครงการในทีมขนาดเล็กที่ต้องการบันทึกการประชุมที่ชัดเจนและเป็นระเบียบมากขึ้น
เป้าหมาย: ชักชวนผู้อ่านให้ตอบกลับด้วยคำว่า MORNING หรือ AFTERNOON เพื่อขอจองที่นั่ง การตอบกลับนี้เป็นการขอจองที่นั่งเท่านั้น ไม่ใช่การยืนยันการจอง
ข้อมูลที่ได้รับการยืนยัน:
- วันที่: 8 ตุลาคม 2026
- มีสองเซสชันที่จัดขึ้นแยกกัน เริ่มเวลา 09:00 UTC และ 16:00 UTC
- แต่ละเซสชันมีระยะเวลา 40 นาที
- แต่ละเซสชันมีที่นั่ง 25 ที่
- การเข้าร่วมฟรี
- ผู้เข้าร่วมจะได้รับบันทึกการประชุมที่สามารถดาวน์โหลดได้
- ไม่มีการบันทึกวิดีโอ
- ยังไม่มีการกำหนดวันปิดรับสมัคร
สิ่งที่ต้องส่ง: หัวข้ออีเมลและเนื้อหาอีเมลยาว 100–140 คำ ใช้ภาษาอังกฤษที่เรียบง่ายและเป็นมิตร; ไม่ใช้คำโฆษณาเกินจริง ให้ระบุวันที่ เวลาเริ่มทั้งสองช่วงและเขตเวลา ระยะเวลา ความจุต่อเซสชัน ราคา เอกสารสรุปที่สามารถดาวน์โหลดได้ การไม่มีการบันทึกวิดีโอ และขั้นตอนการตอบกลับ อย่าสร้างลิงก์ กำหนดเวลาปิดรับสมัคร การยืนยันการจอง ผู้พูด หรือสถานที่จัดงานขึ้นมาเอง สามารถไม่กล่าวถึงกำหนดเวลาปิดรับสมัครที่ยังไม่ได้กำหนดไว้ได้.
คำแนะนำแบบเรียบง่าย — คำตอบต้นฉบับครบถ้วน
**หัวข้อ: เวิร์กช็อป Clear Notes – 8 ตุลาคม 2026 – ตอบกลับเพื่อจองที่นั่ง**
สวัสดีครับ/ค่ะ,
เราขอเชิญหัวหน้าโครงการที่ต้องการบันทึกการประชุมที่ชัดเจนและมีประโยชน์มากขึ้น เข้าร่วม Clear Notes ซึ่งเป็นเวิร์กช็อปชุมชนฟรีในวันที่ 8 ตุลาคม 2026
มีสองเซสชันที่เหมือนกัน แต่ละเซสชันใช้เวลา 40 นาที: เซสชันแรกเริ่มเวลา 09:00 UTC และเซสชันที่สองเริ่มเวลา 16:00 UTC แต่ละเซสชันมีที่ว่าง 25 ที่
การเข้าร่วมเป็นฟรี และทุกคนที่เข้าร่วมจะได้รับบันทึกการประชุมที่สามารถดาวน์โหลดมาเก็บไว้ได้ โปรดทราบว่าไม่มีการบันทึกวิดีโอ ดังนั้นการเข้าร่วมแบบสดเป็นวิธีเดียวที่จะเข้าร่วมได้
เพื่อขอจองที่นั่ง เพียงตอบกลับอีเมลนี้ด้วยคำว่า MORNING หรือ AFTERNOON ตามช่วงเวลาที่เหมาะกับคุณที่สุด การตอบกลับนี้ถือเป็นการขอจองที่นั่งเท่านั้น ยังไม่ถือเป็นการยืนยันการจอง เราจะติดต่อกลับพร้อมรายละเอียดเพิ่มเติมในเร็วๆ นี้
ขอบคุณ และหวังว่าจะได้พบคุณที่นั่น.การสอนแบบมีโครงสร้าง — คำแนะนำและเอกสารอ้างอิงที่ครบถ้วน
เขียนอีเมลเชิญตามที่ระบุในบทสรุป ให้ถือว่าข้อมูลที่ได้รับการยืนยันแล้วเป็นข้อมูลที่แน่นอน แยกคำขอจองที่นั่งออกจากคำยืนยันการจองที่นั่ง ให้ปฏิบัติตามรูปแบบและจำนวนคำที่กำหนดไว้ ใช้ข้อมูลที่ให้มาเท่านั้น
ข้อมูลการทดสอบสมมติ นี่เป็นรายละเอียดของเวิร์กช็อปที่สร้างขึ้น ไม่ใช่ข้อเสนอจริง
คุณกำลังเขียนอีเมลเชิญเข้าร่วมเวิร์กช็อปชุมชนสมมติชื่อ Clear Notes
กลุ่มเป้าหมาย: ผู้นำโครงการในทีมขนาดเล็กที่ต้องการบันทึกการประชุมที่ชัดเจนและเป็นระเบียบ
เป้าหมาย: เชิญผู้อ่านให้ตอบกลับด้วยคำว่า MORNING หรือ AFTERNOON เพื่อขอจองที่นั่ง การตอบกลับนี้เป็นการขอจองที่นั่งเท่านั้น ไม่ถือเป็นการยืนยันการจอง
ข้อมูลที่ยืนยันแล้ว:
- วันที่: 8 ตุลาคม 2026
- มีสองเซสชันแยกกัน เริ่มเวลา 09:00 UTC และ 16:00 UTC
- แต่ละเซสชันมีระยะเวลา 40 นาที
- แต่ละเซสชันมีที่นั่ง 25 ที่
- การเข้าร่วมฟรี
- ผู้เข้าร่วมจะได้รับเอกสารสรุปที่สามารถดาวน์โหลดได้
- ไม่มีการบันทึกการประชุม
- ยังไม่มีการกำหนดวันปิดรับสมัคร
ผลลัพธ์ที่ต้องการ: หัวข้ออีเมลและเนื้อหาอีเมลยาว 100–140 คำ ใช้ภาษาอังกฤษที่เรียบง่ายและเป็นมิตร; ไม่ใช้คำโฆษณาเกินจริง ให้ระบุวันที่ เวลาเริ่มทั้งสองช่วงและเขตเวลา ระยะเวลา ความจุต่อเซสชัน ราคา เอกสารสรุปที่สามารถดาวน์โหลดได้ การไม่มีการบันทึก และขั้นตอนการตอบกลับ ไม่ควรสร้างลิงก์ กำหนดเวลาปิดรับสมัคร การยืนยันการจอง ผู้พูด หรือสถานที่จัดงานขึ้นมาเอง สามารถไม่กล่าวถึงกำหนดเวลาปิดรับสมัครที่ยังไม่ได้กำหนดไว้ได้
การสอนแบบมีโครงสร้าง — คำตอบต้นฉบับที่สมบูรณ์
หัวข้อ: เชิญเข้าร่วม: เวิร์กช็อป Clear Notes – 8 ตุลาคม 2026
สวัสดีครับ/ค่ะ
หากท่านเป็นหัวหน้าโครงการที่กำลังมองหาวิธีบันทึกการประชุมให้ชัดเจนและเป็นระเบียบมากขึ้น เราขอเชิญท่านเข้าร่วมเวิร์กช็อป Clear Notes ในวันที่ 8 ตุลาคม 2026
มีสองรอบให้เลือก แต่ละรอบใช้เวลา 40 นาที: รอบแรกเริ่มเวลา 09:00 UTC และรอบที่สองเริ่มเวลา 16:00 UTC แต่ละรอบรับผู้เข้าร่วมได้ 25 คน และการเข้าร่วมเป็นฟรีทั้งหมด
ผู้เข้าร่วมทุกคนจะได้รับบันทึกการประชุมที่สามารถดาวน์โหลดได้เพื่อเก็บไว้และอ้างอิงภายหลัง โปรดทราบว่าไม่มีการบันทึกวิดีโอ ดังนั้นการเข้าร่วมแบบสดเป็นวิธีเดียวที่จะเข้าร่วมได้
เพื่อขอจองที่นั่ง เพียงตอบกลับด้วยคำว่า MORNING หรือ AFTERNOON ตามช่วงเวลาที่สะดวกสำหรับคุณ การตอบกลับนี้เป็นการขอจองที่นั่งเท่านั้น ยังไม่ถือเป็นการยืนยันการจอง เราจะติดต่อกลับพร้อมรายละเอียดเพิ่มเติมในเร็วๆ นี้
หวังว่าจะได้พบคุณที่งาน
ด้วยความปรารถนาดี
ทีม Clear NotesClaude: หัวข้อสำหรับการวิจัย
คำถามวิจัยจำเป็นต้องมีขอบเขตของหลักฐาน ให้ระบุข้อความที่เกี่ยวข้องพร้อมรหัสแหล่งข้อมูล หรือใช้เครื่องมือที่สามารถค้นหาแหล่งข้อมูลเหล่านั้นได้จริง URL เพียงอย่างเดียวไม่ใช่หลักฐานที่แสดงว่า Claude ได้เปิดหน้านั้นแล้ว แม่แบบเหล่านี้ช่วยแยกแยะระหว่างเนื้อหาที่แหล่งข้อมูลกล่าวไว้กับข้อสรุปที่คุณสามารถได้.
5. รวมข้อมูลจากแหล่งต่าง ๆ โดยไม่ทำให้ความเห็นที่ขัดแย้งกันถูกลดทอนความสำคัญ
ตอบคำถามเกี่ยวกับการตัดสินใจจากเอกสารที่คุณสามารถตรวจสอบได้. นำ: ส่วนที่ระบุไว้ วันที่ คำถามในการตัดสินใจ และข้อเรียกร้องใด ๆ ที่ต้องการตรวจสอบ.
R1 · งานตัวอย่างที่ทดสอบด้านล่างนี้
ตอบ [คำถามการตัดสินใจ] โดยใช้เฉพาะแพ็กเก็ตแหล่งข้อมูลด้านล่างเท่านั้น เปรียบเทียบคำนิยาม จำนวนประชากร และตัวหาร ก่อนที่จะถือว่าความแตกต่างทางตัวเลขเป็นหลักฐานของการปรับปรุง ให้แยกแยะระหว่างการกล่าวอ้างในร่างกับผลการวัด แนบข้อสรุปแต่ละข้อกับคำอ้างอิงจากแหล่งข้อมูลที่ตรงกันและสนับสนุนข้อสรุปนั้นอย่างแท้จริง และไม่ใส่หลักฐานที่ไม่มีอยู่
ผลลัพธ์: คำแนะนำไม่เกิน [LIMIT] คำ; ตารางที่มีส่วนประกอบ ได้แก่ ข้ออ้าง, คำตัดสิน, รหัสแหล่งที่มา, และคำอ้างอิงที่สนับสนุนอย่างแม่นยำ; และสามค่าการวัดที่ขาดหายไปซึ่งจำเป็นสำหรับการเปรียบเทียบอย่างยุติธรรม ใช้คำว่า “ได้รับการสนับสนุน”, “ได้รับการสนับสนุนบางส่วน”, “ไม่ได้รับการสนับสนุน”, หรือ “ขัดแย้ง” เฉพาะเมื่อหลักฐานสนับสนุนให้ใช้ป้ายกำกับนั้นเท่านั้น ตรวจสอบข้ออ้างเหล่านี้: [CLAIMS].
[SOURCE IDS, DATES, AND COMPLETE RELEVANT EXCERPTS]ตรวจสอบผลลัพธ์: ตรวจสอบข้อความที่อ้างอิง ข้อความที่ข้อความดังกล่าวสนับสนุน และตรวจสอบว่าปริมาณต่าง ๆ ใช้คำนิยามและตัวหารเดียวกันหรือไม่.
6. ตรวจสอบคำกล่าวอ้างโดยเปรียบเทียบกับแหล่งอ้างอิง
การตรวจสอบร่างเอกสารก่อนที่จะนำการอ้างอิงมาใช้เป็นหลักฐาน. นำ: คำกล่าวอ้างที่ถูกต้องและข้อความต้นฉบับ ไม่ใช่เพียง URL เท่านั้น.
R2 · แม่แบบที่ปรับแต่งได้
ตรวจสอบแต่ละข้ออ้างกับข้อความต้นฉบับที่แนบมาด้วย สำหรับแต่ละข้อ ให้ระบุ: ข้ออ้าง, รหัสแหล่งข้อมูล, คำอ้างอิงที่เกี่ยวข้องอย่างถูกต้อง, คำตัดสิน และเวอร์ชันที่แก้ไขแล้วหากจำเป็น
ใช้คำว่า "ได้รับการสนับสนุน" เมื่อแหล่งข้อมูลสนับสนุนข้ออ้างทั้งหมด; ใช้ "Partly supported" เมื่อแหล่งข้อมูลสนับสนุนเพียงส่วนหนึ่ง; "Unsupported" เมื่อไม่มีหลักฐานหรือหลักฐานไม่เพียงพอ; และ "Contradicted" เมื่อแหล่งข้อมูลขัดแย้งโดยตรงกับข้ออ้าง หากข้อความต้นฉบับขาดหายไป ให้ระบุว่าไม่สามารถประเมินการสนับสนุนได้ อย่าสรุปเนื้อหาของแหล่งข้อมูลจากชื่อเรื่องหรือ URL
[PASTE CLAIM–SOURCE PAIRS]ตรวจสอบผลลัพธ์: แหล่งข้อมูลที่แท้จริงก็อาจไม่สามารถสนับสนุนข้อกล่าวอ้างได้ การขาดหลักฐานไม่ใช่ความขัดแย้ง.
“ไม่มีหลักฐานสนับสนุน” หมายความว่าหลักฐานที่นำเสนอไม่สามารถพิสูจน์ข้อกล่าวอ้างได้ “ขัดแย้ง” หมายความว่าหลักฐานนั้นขัดแย้งกับข้อกล่าวอ้างนั้น การแยกแยะนี้มีความสำคัญเมื่อแหล่งข้อมูลยังไม่ได้รายงานผลลัพธ์ใดๆ: ยังไม่แสดงให้เห็นถึงการปรับปรุงหรือการเสื่อมลง.
7. เปรียบเทียบตัวเลือกต่าง ๆ กับเอกสารสรุปการตัดสินใจของคุณ
การเลือกจากตัวเลือกต่าง ๆ ที่มีหลักฐานไม่เท่ากัน. นำ: เกณฑ์ ข้อจำกัด และข้อมูลที่น่าเชื่อถือเกี่ยวกับแต่ละตัวเลือก.
R3 · แม่แบบที่ปรับแต่งได้
เปรียบเทียบ [ตัวเลือก] สำหรับ [การตัดสินใจ]. ใช้เกณฑ์ต่อไปนี้ตามลำดับความสำคัญ: [เกณฑ์]. ข้อจำกัดที่เคร่งครัด: [ข้อจำกัด]. ใช้ข้อมูลตัวเลือกด้านล่างนี้เท่านั้น
ส่งคืนตารางเปรียบเทียบ ตัวเลือกที่ได้รับการสนับสนุนดีที่สุด และข้อมูลที่ขาดหายไปซึ่งมีแนวโน้มสูงที่สุดที่จะเปลี่ยนแปลงตัวเลือกนั้น ระบุค่าที่ขาดหายไปว่าเป็น "ไม่ทราบ" แยกข้อมูลข้อเท็จจริงออกจากความเห็นส่วนตัว อย่าสร้างราคา คะแนน หรือน้ำหนักเชิงตัวเลขขึ้นเอง หากไม่สามารถเลือกตัวเลือกใดจากหลักฐานได้ ให้อธิบายจุดที่ต้องแลกเปลี่ยนที่ยังไม่ได้รับการแก้ไขอย่างชัดเจน
[วางข้อมูลที่ได้รับการตรวจสอบพร้อมรหัสแหล่งที่มา]ตรวจสอบผลลัพธ์: ตรวจสอบว่าคำแนะนำนั้นขึ้นอยู่กับค่าที่ไม่ทราบ หรือขึ้นอยู่กับน้ำหนักที่คุณไม่เคยเลือก.
8. เปลี่ยนหัวข้อที่กว้างเป็นแผนการวิจัย
เริ่มทำการวิจัยก่อนที่จะมีแหล่งข้อมูลเพียงพอเพื่อตอบคำถาม. นำ: การตัดสินใจ ผู้รับฟัง ขอบเขต และกำหนดเวลา.
R4 · แม่แบบที่ปรับแต่งได้
จัดทำแผนการวิจัยสำหรับ [คำถาม] เพื่อช่วย [กลุ่มเป้าหมาย] ในการตัดสินใจ [การตัดสินใจ]. ขอบเขต: [ภูมิภาค, ช่วงระยะเวลา, และข้อยกเว้น]. เวลาที่มีอยู่: [เวลา].
เสนอคำถามย่อยที่มุ่งเน้น 5 ข้อ สำหรับแต่ละข้อ ให้ระบุหลักฐานที่จำเป็น ประเภทแหล่งข้อมูลปฐมภูมิที่แนะนำ คำค้นหาที่เสนอ และผลการค้นพบที่อาจส่งผลต่อการตัดสินใจ ให้จบด้วยสองการค้นหาที่มีลำดับความสำคัญสูงสุด ห้ามสร้างงานวิจัยขึ้นมาเองหรืออ้างว่าได้อ่านแหล่งข้อมูลแล้ว หากใช้เครื่องมือค้นหา ให้ระบุแยกต่างหากว่าหน้าใดถูกเปิดจริง และแต่ละหน้าสนับสนุนข้อมูลอะไร.ตรวจสอบผลลัพธ์: ผลลัพธ์คือแผนงาน ให้ถือว่าการค้นหาที่เสนอและแหล่งข้อมูลที่เป็นไปได้เป็นเพียงแนวทาง ไม่ใช่ผลการวิจัยที่เสร็จสมบูรณ์.
การเปรียบเทียบผลลัพธ์ครั้งแรก · R
ผลลัพธ์ที่ขาดหายไปไม่ได้หมายความว่าข้ออ้างนั้นถูกหักล้าง.
| ตรวจสอบ | คำแนะนำแบบเรียบง่าย | การสอนแบบมีโครงสร้าง |
|---|---|---|
| การตรวจสอบการวิจัยที่กำหนดไว้ล่วงหน้า | 6 / 8 | 7 / 8 |
| ป้ายหลักฐานการเก็บรักษา | ขัดแย้ง · แรงเกินไป | ไม่ได้รับการสนับสนุน · เหมาะสม |
| บัญชีที่ได้รับการเชิญชวน เทียบกับจำนวนการเริ่มต้นกระบวนการลงทะเบียน | ไม่ได้อธิบายอย่างชัดเจน | ไม่ได้อธิบายอย่างชัดเจน |
ทั้งสองคำตอบได้ปฏิเสธการนำระบบไปใช้อย่างเต็มรูปแบบ และยอมรับว่าโครงการนำร่องใช้คำนิยามการเปิดใช้งานและกลุ่มประชากรที่แตกต่างกัน เวอร์ชันที่มีโครงสร้างได้ระบุข้ออ้างเกี่ยวกับการรักษาลูกค้าอย่างถูกต้องว่า “ไม่มีหลักฐานสนับสนุน” ส่วนเวอร์ชันธรรมดาเขียนว่า “ขัดแย้ง” แม้ว่าข้อความที่อ้างอิงจะระบุเพียงว่าไม่มีผลการรักษาลูกค้าอยู่เลย ทั้งสองคำตอบไม่ได้ชี้ให้เห็นอย่างชัดเจนถึงความแตกต่างของตัวหาร.
อัตราคือ 40/50 บัญชีที่ได้รับการเชิญ (80%) และ 54/60 การเริ่มต้นการลงทะเบียน (90%) การคำนวณนั้นถูกต้อง แต่การวัดผลทั้งสองไม่สามารถใช้แทนกันได้ คำตอบที่จัดโครงสร้างไว้ได้เพิ่มการตรวจสอบแยกต่างหากว่า “การเปิดใช้งาน” มีความหมายเดียวกันหรือไม่ นั่นเป็นคำถามวิเคราะห์เพิ่มเติม ไม่ใช่ข้ออ้างที่สี่ที่ระบุไว้ในบันทึกการเปิดตัว.
| คำร้องขอจดหมาย | สิ่งที่แหล่งข้อมูลที่ให้มาสนับสนุน | การรักษาที่เหมาะสม |
|---|---|---|
| B ทำให้ระดับการกระตุ้นเพิ่มขึ้น 10 จุดเปอร์เซ็นต์ | อัตรา นิยาม ตัวหาร และกลุ่มประชากรที่แตกต่างกัน | อย่าถือว่าช่องว่างนั้นเป็นการปรับปรุงตามสาเหตุ |
| B ช่วยเพิ่มอัตราการรักษาลูกค้า | S3: ยังไม่มีผลการเก็บข้อมูลไว้ 30 วัน | ไม่มีหลักฐานสนับสนุน; ยังไม่ถูกพิสูจน์ว่าผิด |
| B ได้ลดเวลาให้บริการลงเหลือหกชั่วโมง | S3: ค่ามัธยฐานรวม ไม่มีการแบ่งตามกลุ่มนำร่อง | ไม่มีการแสดงให้เห็นถึงการลดลง |
ดูผลการตรวจสอบการวิจัยทั้งแปดรายการ
1. A: 40/50 = 80%, ใช้บัญชีที่ได้รับเชิญ ทั้งสองผ่าน
2. B: 54/60 = 90%, ใช้การเริ่มต้นกระบวนการ onboarding ทั้งสองผ่าน; คำอ้างอิงจากแหล่งที่มาประกอบด้วยตัวหาร
3. ชี้ให้เห็นอย่างชัดเจนทั้งความแตกต่างในนิยามการเปิดใช้งานและตัวหารที่แตกต่างกัน ทั้งสองกรณีไม่ผ่านในส่วนตัวหาร
4. ไม่ถือว่าผลการรักษาลูกค้าที่ขาดหายไปเป็นหลักฐานของการปรับปรุง ทั้งสองกรณีอธิบายช่องว่างของข้อมูล
5. ไม่ถือว่าค่ามัธยฐานของการสนับสนุนที่รวมกันเป็นการลดลงที่พิสูจน์ได้ ทั้งสองกรณีผ่าน
6. อย่าสรุปผลประโยชน์เชิงสาเหตุหรือให้เหตุผลในการขยายโครงการอย่างเต็มรูปแบบจากโครงการนำร่องเหล่านี้ ทั้งสองผ่าน
7. จับคู่แต่ละข้ออ้างและป้ายกำกับหลักฐานกับสิ่งที่คำอ้างอิงที่อ้างถึงสนับสนุน คำตอบแบบธรรมดาไม่ผ่านในส่วน “ขัดแย้ง”; คำตอบแบบมีโครงสร้างผ่าน
8. ระบุการวัดผลที่ขาดหายไปสามอย่างที่เฉพาะเจาะจง ทั้งสองผ่าน
ป้ายกำกับที่ผิดของคำตอบแบบธรรมดาถูกนับหนึ่งครั้ง ในขั้นตอนตรวจสอบที่ 7.เวลาที่ผ่านไปแล้ว: 31.35 วินาที / 31.07 วินาที. จำนวนโทเคนข้อมูลเข้าและออกที่รายงาน: 743 + 2822 / 832 + 2837. ได้รับคำตอบครั้งละหนึ่งครั้ง; ไม่มีการลองใหม่.
คำแนะนำแบบเรียบง่าย — คำแนะนำและเอกสารต้นฉบับครบถ้วน
ทำแบบฝึกหัดที่อยู่ในส่วนท้ายของชุดเอกสารนี้
# ชุดเอกสารวิจัยสมมติ
องค์กร ข้อมูล คำพูด และเอกสารทั้งหมดด้านล่างนี้ถูกสร้างขึ้นเพื่อใช้ในการทดสอบที่สามารถทำซ้ำได้ รหัสแหล่งข้อมูล (Source IDs) อ้างอิงเฉพาะชุดเอกสารนี้เท่านั้น และไม่ใช่การศึกษาที่เปิดเผยต่อสาธารณะ
## S1 — การปิดโครงการนำร่อง A, 2 กันยายน 2026
"โครงการนำร่อง A ได้เชิญ 50 บัญชี; 40 บัญชีได้เสร็จสิ้นการเปิดใช้งานภายในเจ็ดวัน"
"การเปิดใช้งานหมายถึงการสร้างพื้นที่ทำงานและเชิญเพื่อนร่วมทีมอย่างน้อยหนึ่งคน"
"บัญชีดังกล่าวเป็นลูกค้าที่มีอยู่เดิม ซึ่งถูกเลือกโดยทีมสนับสนุนลูกค้า"
"โครงการนำร่องนี้ใช้กระบวนการนำทางในการเริ่มต้นใช้งาน"
## S2 — บันทึกบนแดชบอร์ดของโครงการนำร่อง B, 3 กันยายน 2026
"โครงการนำร่อง B บันทึกการเริ่มต้นกระบวนการเริ่มต้นใช้งาน 60 ครั้ง; บัญชี 54 บัญชีได้สร้างพื้นที่ทำงานภายใน 7 วัน"
"แดชบอร์ดนี้กำหนดการสร้างพื้นที่ทำงานเป็นการเปิดใช้งาน; ไม่จำเป็นต้องเชิญเพื่อนร่วมทีม"
"จำนวนการเชิญไม่ถูกบันทึก"
"บัญชีเหล่านี้เป็นบัญชีใหม่ที่สมัครด้วยตนเองผ่านรายการตรวจสอบ"
## S3 — รายงานการวิเคราะห์ของนักวิเคราะห์, 4 กันยายน 2026
"โครงการทดลองไม่ได้จัดแบบสุ่มและใช้กลุ่มบัญชีที่แตกต่างกัน"
"เวลากลางของการตอบกลับจากทีมสนับสนุนคือ 6 ชั่วโมง สำหรับทั้งสองโครงการทดลองรวมกัน; ไม่ได้แยกตามโครงการทดลองแต่ละโครงการ"
"ยังไม่มีผลการรักษาลูกค้า 30 วันหรือผลรายได้"
## S4 — ร่างจดหมายแจ้งการเปิดตัว, 5 กันยายน 2026
"โครงการทดลอง B เพิ่มอัตราการเปิดใช้งานขึ้น 10 จุดเปอร์เซ็นต์ ปรับปรุงอัตราการรักษาลูกค้า และลดเวลาตอบสนองของฝ่ายสนับสนุนลงเหลือ 6 ชั่วโมง นำรายการตรวจสอบไปใช้กับทุกบัญชี"
นี่เป็นร่างข้อเสนอ ไม่ใช่แหล่งข้อมูลเพิ่มเติม ข้อความในร่างนี้ต้องได้รับการตรวจสอบเทียบกับ S1–S3
## ภารกิจที่ใช้ร่วมกันในทั้งสองเวอร์ชันของคำสั่ง
คำตอบ: ชุดข้อมูลนี้เพียงพอที่จะสนับสนุนการนำโครงการทดลอง B ไปใช้กับทุกบัญชีหรือไม่?
ใช้เฉพาะ S1–S4 เท่านั้น ผลลัพธ์ (1) คำแนะนำไม่เกิน 120 คำ, (2) ตารางที่มีคอลัมน์ "ข้ออ้าง", "คำตัดสิน", "ID แหล่งข้อมูล", "คำอ้างอิงสนับสนุนที่แม่นยำ", และ (3) การวัดผลสามรายการที่ขาดหายไปเพื่อเปรียบเทียบอย่างยุติธรรม
ตรวจสอบข้ออ้างเชิงประจักษ์ทั้งสามข้อในบันทึกการขยายโครงการ: การเพิ่มขึ้นของการเปิดใช้งาน, การรักษาลูกค้าที่ดีขึ้น, และเวลาการสนับสนุนที่ลดลง ใช้คำตัดสินว่า “ได้รับการสนับสนุน”, “ได้รับการสนับสนุนบางส่วน”, “ไม่ได้รับการสนับสนุน”, หรือ “ขัดแย้ง” พร้อมคำอธิบายสั้นๆ หากจำเป็น ให้รวมอัตราตัวเลขและตัวหารของอัตราเหล่านั้นไว้ในคำแนะนำหรือตาราง อย่าสร้างการอ้างอิง URL ผลลัพธ์เชิงสาเหตุ หรือผลการวิจัยที่ไม่มีอยู่ในชุดข้อมูล.
คำแนะนำแบบเรียบง่าย — คำตอบต้นฉบับครบถ้วน
## คำแนะนำ (≤120 คำ)
อย่าเปิดตัวโครงการทดลอง B ในขณะนี้ อัตราการเปิดใช้งานดิบของโครงการทดลอง B (54/60 = 90%) สูงกว่าโครงการทดลอง A (40/50 = 80%) 10 จุดเปอร์เซ็นต์, แต่ทั้งสองโครงการนำร่องวัด "การเปิดใช้งาน" ด้วยวิธีที่แตกต่างกัน (โครงการ B ไม่ต้องการคำเชิญจากเพื่อนร่วมทีม), ใช้กลุ่มเป้าหมายที่แตกต่างกัน (ผู้สมัครใหม่แบบบริการตนเอง vs. ลูกค้าที่มีอยู่), และไม่ได้จัดกลุ่มแบบสุ่ม (S3) — ดังนั้นความแตกต่างนี้จึงไม่สามารถนำมาอ้างว่าเป็นผลจากรายการตรวจสอบได้ ข้ออ้างเกี่ยวกับการรักษาลูกค้าไม่มีหลักฐานสนับสนุน: S3 ระบุอย่างชัดเจนว่ายังไม่มีข้อมูลการรักษาลูกค้าใน 30 วัน ตัวเลข "หกชั่วโมง" สำหรับเวลาการสนับสนุนเป็นค่ามัธยฐานรวมจากทั้งสองโครงการทดลอง ไม่ได้แยกตามโครงการทดลอง ดังนั้นจึงไม่มีการแสดงให้เห็นถึงการลดลงที่เฉพาะเจาะจงสำหรับโครงการทดลอง B จำเป็นต้องมีการเปรียบเทียบที่ควบคุมได้ จับคู่ และกำหนดนิยามอย่างสม่ำเสมอ ก่อนการนำระบบไปใช้จริง
## ตารางตรวจสอบข้ออ้าง
| ข้ออ้าง | คำวินิจฉัย | รหัสแหล่งที่มา | คำอ้างอิงสนับสนุนที่แม่นยำ |
|---|---|---|---|
| "โครงการนำร่อง B เพิ่มอัตราการเปิดใช้งานขึ้น 10 จุดเปอร์เซ็นต์" | ได้รับการสนับสนุนบางส่วน — อัตราดิบต่างกัน 10 จุดเปอร์เซ็นต์ (54/60=90% เทียบกับ 40/50=80%) แต่การกำหนดนิยาม/กลุ่มตัวอย่าง/การออกแบบต่างกัน ดังนั้นความแตกต่างนี้จึงไม่สามารถระบุได้ว่าเกิดจากรายการตรวจสอบ | S1 | "โครงการนำร่อง A ได้เชิญ 50 บัญชี; 40 บัญชีได้เสร็จสิ้นการเปิดใช้งานภายในเจ็ดวัน" |
| (ข้ออ้างเดียวกัน, ต่อ) | | S2 | "โครงการนำร่อง B บันทึกการเริ่มต้นการลงทะเบียน 60 ครั้ง; 54 บัญชีได้สร้างพื้นที่ทำงานภายในเจ็ดวัน" / "ไม่จำเป็นต้องมีคำเชิญจากเพื่อนร่วมทีม" |
| (คำกล่าวเดียวกัน, ต่อ) | | S3 | "โครงการทดลองไม่ได้จัดแบบสุ่มและใช้กลุ่มบัญชีที่แตกต่างกัน" |
| "การรักษาลูกค้าดีขึ้น" | ขัดแย้ง — ไม่มีข้อมูลการรักษาลูกค้าเพื่อสนับสนุนข้อนี้ | S3 | "ยังไม่มีผลการรักษาลูกค้า 30 วันหรือผลรายได้" |
| "ลดเวลาการสนับสนุนลงเหลือหกชั่วโมง" | ไม่มีข้อมูลสนับสนุน — ตัวเลขดังกล่าวเป็นค่ามัธยฐานรวม ไม่ใช่ค่าที่ระบุเฉพาะโครงการทดลอง B หรือแสดงว่าเป็นการลดลง | S3 | "เวลาตอบสนองการสนับสนุนมัธยฐานอยู่ที่หกชั่วโมงสำหรับโครงการทดลองทั้งสองรวมกัน; ไม่ได้แยกตามโครงการทดลองแต่ละโครงการ" |
## ขาดข้อมูลการวัดสามอย่างที่จำเป็นสำหรับการเปรียบเทียบอย่างยุติธรรม
1. อัตราการเปิดใช้งานสำหรับทั้งสองโครงการนำร่องโดยใช้คำนิยามที่เหมือนกัน (เช่น การสร้างพื้นที่ทำงาน *และ* การเชิญเพื่อนร่วมทีมอย่างน้อยหนึ่งคน)
2. เวลาตอบสนองของฝ่ายสนับสนุนที่รายงานแยกกันสำหรับโครงการนำร่อง A และโครงการนำร่อง B (ไม่ใช่ค่ามัธยฐานรวม) โดยควรมีข้อมูลพื้นฐานก่อนการนำร่อง
3. ผลลัพธ์การรักษาลูกค้า (และรายได้) ในระยะเวลา 30 วัน สำหรับโครงการนำร่องทั้งสอง ซึ่งเก็บข้อมูลจากกลุ่มบัญชีที่เทียบเคียงได้ และควรเป็นกลุ่มที่สุ่มตัวอย่างหรือจับคู่.การสอนแบบมีโครงสร้าง — คำแนะนำและเอกสารอ้างอิงที่ครบถ้วน
ตอบข้อปฏิบัติโดยใช้ชุดข้อมูลแหล่งนี้เท่านั้น เปรียบเทียบคำนิยาม ประชากร และตัวหาร ก่อนที่จะถือว่าอัตราทั้งสองเป็นหลักฐานของการปรับปรุง ให้แยกแยะระหว่างข้ออ้างเบื้องต้นกับการวัดผล ให้เชื่อมโยงข้อสรุปแต่ละข้อกับคำอ้างอิงจากแหล่งข้อมูลที่ถูกต้องและสนับสนุนข้อสรุปนั้นอย่างแท้จริง และอย่าใส่หลักฐานที่ไม่มีอยู่จริง
# ชุดข้อมูลวิจัยสมมติ
องค์กร ข้อมูล คำพูด และเอกสารทั้งหมดด้านล่างนี้ถูกสร้างขึ้นเพื่อใช้ในการทดสอบที่สามารถทำซ้ำได้ รหัสแหล่งข้อมูล (Source IDs) อ้างอิงเฉพาะชุดข้อมูลนี้เท่านั้น; ไม่ใช่การศึกษาสาธารณะ
## S1 — การปิดโครงการนำร่อง A, 2 กันยายน 2026
"โครงการนำร่อง A ได้เชิญ 50 บัญชี; 40 บัญชีเสร็จสิ้นการเปิดใช้งานภายใน 7 วัน"
"การเปิดใช้งานหมายถึงการสร้างพื้นที่ทำงานและเชิญเพื่อนร่วมทีมอย่างน้อย 1 คน"
"บัญชีดังกล่าวเป็นลูกค้าที่มีอยู่เดิม ซึ่งถูกคัดเลือกโดยทีมสนับสนุนลูกค้า"
"โครงการนำร่องนี้ใช้กระบวนการแนะนำการใช้งานแบบมีผู้แนะนำ"
## S2 — หมายเหตุบนแดชบอร์ดของโครงการทดลอง B, 3 กันยายน 2026
"โครงการทดลอง B บันทึกการเริ่มต้นกระบวนการออนบอร์ด 60 ครั้ง; 54 บัญชีได้สร้างพื้นที่ทำงานภายใน 7 วัน"
"แดชบอร์ดนี้เรียกการสร้างพื้นที่ทำงานว่า "การเปิดใช้งาน"; ไม่จำเป็นต้องเชิญเพื่อนร่วมทีม"
"จำนวนคำเชิญไม่ถูกบันทึก"
"บัญชีเหล่านี้เป็นบัญชีใหม่ที่สมัครด้วยตนเองผ่านรายการตรวจสอบ"
## S3 — การทบทวนของนักวิเคราะห์, 4 กันยายน 2026
"โครงการทดลองไม่ได้จัดแบบสุ่มและใช้กลุ่มบัญชีที่แตกต่างกัน"
"เวลาตอบสนองของฝ่ายสนับสนุนมีค่ามัธยฐาน 6 ชั่วโมง สำหรับโครงการทดลองทั้งสองรวมกัน; ไม่ได้แยกตามโครงการทดลองแต่ละโครงการ"
"ยังไม่มีผลการรักษาลูกค้า 30 วัน หรือผลการสร้างรายได้"
## S4 — ร่างจดหมายแจ้งการขยายผล, 5 กันยายน 2026
"โครงการนำร่อง B เพิ่มอัตราการเปิดใช้งานขึ้น 10 จุดเปอร์เซ็นต์ ปรับปรุงอัตราการรักษาลูกค้า และลดเวลาตอบสนองของฝ่ายสนับสนุนลงเหลือ 6 ชั่วโมง ให้ขยายการใช้รายการตรวจสอบไปยังทุกบัญชี"
นี่เป็นร่างข้อเสนอ ไม่ใช่แหล่งข้อมูลเพิ่มเติม ข้อความในร่างนี้ต้องได้รับการตรวจสอบให้สอดคล้องกับ S1–S3
## งานที่ได้รับมอบหมายร่วมกันจากทั้งสองเวอร์ชันของคำสั่ง
คำตอบ: ชุดข้อมูลนี้สามารถสนับสนุนการนำโครงการทดลอง B ไปใช้กับทุกบัญชีได้หรือไม่?
ใช้เฉพาะ S1–S4 เท่านั้น ผลลัพธ์ (1) คำแนะนำไม่เกิน 120 คำ, (2) ตารางที่มีคอลัมน์ "ข้ออ้าง", "คำตัดสิน", "ID แหล่งข้อมูล", "คำอ้างอิงสนับสนุนที่แม่นยำ", และ (3) การวัดผลที่ขาดหายไปสามรายการที่จำเป็นสำหรับการเปรียบเทียบอย่างยุติธรรม
ตรวจสอบข้ออ้างเชิงประจักษ์ทั้งสามข้อในบันทึกการขยายโครงการ: การเพิ่มขึ้นของการเปิดใช้งาน, การรักษาลูกค้าที่ดีขึ้น, และเวลาการสนับสนุนที่ลดลง ใช้คำตัดสินว่า “ได้รับการสนับสนุน”, “ได้รับการสนับสนุนบางส่วน”, “ไม่ได้รับการสนับสนุน”, หรือ “ขัดแย้ง”, พร้อมคำอธิบายสั้นๆ หากจำเป็น ให้รวมอัตราตัวเลขและตัวหารของอัตราเหล่านั้นไว้ในคำแนะนำหรือตาราง อย่าสร้างการอ้างอิง URL ผลลัพธ์เชิงสาเหตุ หรือผลการวิจัยที่ไม่มีอยู่ในชุดเอกสาร
การสอนแบบมีโครงสร้าง — คำตอบต้นฉบับที่สมบูรณ์
## คำแนะนำ (≤120 คำ)
ไม่ — ข้อมูลในชุดนี้ไม่เพียงพอที่จะสนับสนุนการขยายโครงการนำร่อง B อย่างเต็มรูปแบบ โครงการนำร่อง A: 40/50 บัญชี (80%) ได้ถึงขั้น "การเปิดใช้งาน" ซึ่งกำหนดว่าเป็นการสร้างพื้นที่ทำงาน *บวก* การเชิญเพื่อนร่วมทีม จากลูกค้าที่มีอยู่ โครงการทดลอง B: 54/60 บัญชี (90%) ได้สร้างพื้นที่ทำงานภายใน 7 วัน โดยไม่มีข้อกำหนดการเชิญเพื่อนร่วมทีม สำหรับผู้สมัครใหม่แบบบริการตนเอง ช่องว่างดิบ 10 จุด (90%−80%) ผสมผสานนิยามที่แตกต่างกัน กลุ่มตัวอย่างที่แตกต่างกัน และไม่มีการสุ่มตัวอย่าง (S3) ดังนั้นจึงไม่สามารถตีความได้ว่าเป็นการ "เพิ่ม" อัตราการเปิดใช้งานตามรายการตรวจสอบ ยังไม่มีข้อมูลการรักษาลูกค้าหรือรายได้ใน 30 วัน (S3) ดังนั้น "การรักษาลูกค้าที่ดีขึ้น" จึงไม่มีหลักฐาน ตัวเลขการสนับสนุน 6 ชั่วโมงเป็นค่ามัธยฐาน *รวม* ของทั้งสองโครงการทดลอง ไม่ได้แยกตามโครงการ ดังนั้น "เวลาการสนับสนุนที่ลดลง" จึงไม่มีข้อมูลพื้นฐานหรือข้อมูลการสนับสนุนเฉพาะโครงการ
## ตาราง
| ข้ออ้าง | คำตัดสิน | รหัสแหล่ง | คำอ้างอิงที่สนับสนุนอย่างแม่นยำ |
|---|---|---|---|
| "โครงการนำร่อง B เพิ่มอัตราการเปิดใช้งานขึ้น 10 จุดเปอร์เซ็นต์" | ได้รับการสนับสนุนบางส่วน — ช่องว่างทางคณิตศาสตร์มีอยู่ (54/60=90% เทียบกับ 40/50=80%) แต่การเปรียบเทียบนี้มีความสับสนและไม่สามารถสนับสนุนข้ออ้างเชิงสาเหตุว่า "เพิ่มขึ้น" ได้ | S1, S2, S3 | S1: "โครงการนำร่อง A ได้เชิญ 50 บัญชี; 40 บัญชีเสร็จสิ้นการเปิดใช้งานภายในเจ็ดวัน" / S2: "โครงการนำร่อง B บันทึกการเริ่มต้นกระบวนการออนบอร์ด 60 ครั้ง; 54 บัญชีสร้างพื้นที่ทำงานภายในเจ็ดวัน" / S3: "โครงการนำร่องทั้งสองไม่ได้จัดแบบสุ่มและใช้กลุ่มบัญชีที่แตกต่างกัน" |
| การวัดการเปิดใช้งานทำด้วยวิธีเดียวกันในทั้งสองโครงการนำร่อง | ขัดแย้ง | S1, S2 | S1: "การเปิดใช้งานหมายถึงการสร้างพื้นที่ทำงานและเชิญเพื่อนร่วมทีมอย่างน้อยหนึ่งคน" / S2: "แดชบอร์ดนี้เรียกการสร้างพื้นที่ทำงานว่าเป็นการเปิดใช้งาน; ไม่จำเป็นต้องเชิญเพื่อนร่วมทีม" |
| "การรักษาผู้ใช้ดีขึ้น" | ไม่มีหลักฐานสนับสนุน | S3 | "ยังไม่มีผลการรักษาผู้ใช้ใน 30 วันหรือผลรายได้" |
| "ลดเวลาตอบสนองการสนับสนุนลงเหลือ 6 ชั่วโมง" | ไม่มีข้อมูลสนับสนุน | S3 | "เวลาตอบสนองการสนับสนุนมัธยฐานอยู่ที่ 6 ชั่วโมงสำหรับทั้งสองโครงการนำร่องรวมกัน; ไม่ได้แยกตามโครงการนำร่องแต่ละโครงการ" |
## ขาดข้อมูลการวัดสามอย่างที่จำเป็นสำหรับการเปรียบเทียบอย่างยุติธรรม
1. เวลาตอบสนองการสนับสนุนเฉพาะโครงการนำร่อง (ไม่ใช่ข้อมูลรวม) ก่อนและหลังการใช้รายการตรวจสอบ เพื่อให้สามารถแยกการเปลี่ยนแปลงที่เกิดจากโครงการนำร่อง B ได้
2. ตัวเลขการรักษาลูกค้า (และรายได้) ภายใน 30 วัน สำหรับทั้งสองโครงการนำร่อง เนื่องจากปัจจุบันยังไม่มีข้อมูลดังกล่าว ("ยังไม่มีผลการรักษาลูกค้าหรือรายได้ภายใน 30 วัน" S3).
3. คำนิยามการเปิดใช้งาน (activation) เดียวที่ใช้ร่วมกัน (เช่น การสร้างพื้นที่ทำงาน *และ* การเชิญเพื่อนร่วมทีม) ซึ่งนำไปใช้กับกลุ่มบัญชีที่สามารถเปรียบเทียบได้ (และควรสุ่มตัวอย่าง) ในทั้งสองโครงการนำร่อง แทนที่จะผสมผสานลูกค้าที่มีอยู่ (S1) กับผู้สมัครใหม่แบบบริการตนเอง (S2).เมื่องานวิจัยกลายเป็นฉบับร่าง ให้แนบชุดข้อมูลแหล่งที่มาไว้กับคู่มือการเขียน. พื้นที่ทำงานแบบหลายโมเดลของ GlobalGPT ช่วยให้คุณสลับไปมาระหว่างการวิจัย การเขียน และการเขียนโค้ดในแดชบอร์ดเดียว นำหลักฐานและสรุปมาใช้ในขั้นตอนต่อไป เพื่อให้ขั้นตอนถัดไปมีข้อมูลรายละเอียดที่จำเป็น.
Claude: คำแนะนำสำหรับการเขียนโค้ด
คำแนะนำการเขียนโค้ดที่มีประโยชน์ควรอธิบายพฤติกรรม สภาพแวดล้อม และสิ่งที่ถือว่าเป็นส่วนที่แก้ไขแล้ว ในช่องสนทนา ให้คัดลอกและวางโค้ดที่เกี่ยวข้องและข้อผิดพลาด ใน Claude Code ให้อ้างอิงไฟล์ที่สามารถเข้าถึงได้ และระบุเป้าหมายการตรวจสอบที่ชัดเจน ข้อความเดียวกันนี้ไม่สามารถเปลี่ยนช่องสนทนาให้กลายเป็นเทอร์มินัลได้.
คู่มือรหัส Claude ของ Anthropic แนะนำให้มอบหมายให้ผู้ช่วยดำเนินการตรวจสอบต่าง ๆ ที่สามารถทำได้ เช่น การทดสอบหรือการสร้างซอฟต์แวร์ ซึ่ง ไลบรารีคำสั่งอย่างเป็นทางการ ใช้คำชี้แนะเป็นจุดเริ่มต้นเพื่อปรับแต่ง โดยกำหนดผลลัพธ์ วัสดุอ้างอิง และวิธีการตรวจสอบผลงาน.
9. ตรวจสอบข้อผิดพลาดโดยมุ่งเน้นไปที่พฤติกรรมที่ชัดเจนและกรณีขอบเขต
การแก้ไขฟังก์ชันขนาดเล็กที่คุณสามารถกำหนดพฤติกรรมได้. นำ: รหัสโปรแกรม, พฤติกรรมที่คาดหมาย, ข้อผิดพลาดหรือกรณีที่ล้มเหลว, เวลาการทำงาน และข้อจำกัด.
C1 · งานตัวอย่างที่ทดสอบด้านล่างนี้
แก้ไขโค้ดให้สอดคล้องกับข้อกำหนดที่ครบถ้วน ตรวจสอบการตรวจสอบความถูกต้องก่อนการคืนค่าก่อนกำหนด ขอบเขตที่รวมหรือไม่นับรวม และกฎที่ต้องยังคงมีผลเมื่อเกิดข้อยกเว้น รักษา [PUBLIC INTERFACE] ไว้ เปลี่ยนแปลงเฉพาะส่วนที่ข้อกำหนดกำหนดเท่านั้น
[ข้อมูลเข้าที่ถูกต้อง, พฤติกรรมเมื่อข้อมูลเข้าไม่ถูกต้อง, กฎทางธุรกิจ, และผลลัพธ์ที่คาดหวัง]
[วางโค้ด]
[RUNTIME, DEPENDENCIES, AND WHETHER EXECUTION TOOLS ARE AVAILABLE]
ส่งคืนโค้ดที่แก้ไขแล้วพร้อมคำอธิบายสั้นๆ รายงานเฉพาะการตรวจสอบที่คุณได้ดำเนินการจริงเท่านั้น หากไม่สามารถดำเนินการได้ ให้ระบุไว้และระบุการตรวจสอบที่คุณควรดำเนินการ.ตรวจสอบผลลัพธ์: ดำเนินการทดสอบกรณีแบบอิสระ คำอธิบายที่น่าเชื่อถือไม่ใช่โปรแกรมที่ผ่านได้เพียงชั่วคราว.
10. เขียนการทดสอบจากเอกสารข้อกำหนด
การค้นหากรณีที่ขาดหายไปก่อนที่จะเชื่อถือการนำไปใช้. นำ: ข้อกำหนดด้านพฤติกรรมและกรอบงานการทดสอบโครงการ.
C2 · แม่แบบที่ปรับแต่งได้
เขียนการทดสอบสำหรับ [ฟังก์ชันหรือส่วนประกอบ] โดยใช้ [กรอบงานการทดสอบ] ให้ถือข้อกำหนดด้านล่างนี้เป็นสัญญา ครอบคลุมกรณีปกติ ขอบเขตที่กำหนดไว้ทุกข้อ ข้อมูลนำเข้าที่ไม่ถูกต้อง และการโต้ตอบระหว่างกฎต่างๆ ในจุดที่สำคัญ
สำหรับแต่ละการทดสอบ ให้ระบุข้อกำหนดที่การทดสอบนั้นตรวจสอบและผลลัพธ์ที่คาดหวังไว้ รักษาข้อกำหนดที่มีอยู่ให้คงเดิม หากข้อกำหนดไม่ชัดเจน ให้ระบุคำถามที่ก่อให้เกิดปัญหาแทนที่จะเดา โดยใช้เครื่องมือการดำเนินการ ให้รันการทดสอบที่เกี่ยวข้องและรายงานคำสั่งและผลลัพธ์จริง; หากไม่รัน ให้ระบุว่า "unrun"
[PASTE SPECIFICATION]
[PASTE CODE OR REFERENCE AN ACCESSIBLE FILE]ตรวจสอบผลลัพธ์: การทดสอบควรใช้เพื่อตรวจสอบให้สอดคล้องกับข้อกำหนด ไม่ใช่เพื่อซ้ำข้อผิดพลาดในเวอร์ชันปัจจุบัน.
ให้ทดสอบให้แยกออกจากส่วนการนำไปใช้งานเท่าที่เป็นไปได้ สำหรับเครื่องมือคำนวณค่าจัดส่ง ให้ทดสอบค่าขีดจำกัดน้ำหนักที่แม่นยำ และข้อมูลที่ป้อนไม่ถูกต้อง ซึ่งโดยปกติจะทำให้เกิดการจัดส่งฟรี ตัวอย่างในสถานการณ์ปกติเพียงอย่างเดียวอาจไม่ครอบคลุมการโต้ตอบระหว่างกฎต่าง ๆ.
11. ปรับโครงสร้างโค้ดโดยไม่ขยายขอบเขตงาน
การปรับปรุงส่วนเล็กๆ ของโค้ดโดยไม่เปลี่ยนแปลงพฤติกรรม. นำ: รหัส, ปัญหาการบำรุงรักษาเฉพาะ และข้อกำหนดด้านความเข้ากันได้.
C3 · แม่แบบที่ปรับแต่งได้
ปรับโครงสร้าง [CODE OR ACCESSIBLE FILE] เพื่อแก้ไข [ปัญหาการดูแลรักษาหนึ่งข้อที่เฉพาะเจาะจง]. รักษา [PUBLIC API, RETURN TYPES, ERROR BEHAVIOR, AND OTHER CONTRACTS] ให้คงเดิม. ใช้การพึ่งพาที่มีอยู่เท่านั้น อย่าเพิ่มคุณสมบัติที่ไม่เกี่ยวข้องหรือออกแบบใหม่โมดูลที่อยู่ใกล้เคียง
ส่งคืนการเปลี่ยนแปลงที่มีประโยชน์น้อยที่สุด อธิบายพฤติกรรมใด ๆ ที่ไม่สามารถรักษาไว้ได้ และระบุการทดสอบที่จำเป็นเพื่อตรวจสอบความเข้ากันได้ หากมีเครื่องมือพร้อมใช้งาน ให้ดำเนินการตรวจสอบเหล่านั้นและแสดงผลลัพธ์; หากไม่มี ให้ระบุการตรวจสอบที่เสนอและระบุว่ายังไม่ได้ดำเนินการ
[วางโค้ดและทดสอบที่เกี่ยวข้อง]ตรวจสอบผลลัพธ์: ตรวจสอบ diff เพื่อหาการเปลี่ยนแปลงที่อยู่นอกขอบเขตที่ขอไว้ แล้วรันการทดสอบที่เกี่ยวข้องอีกครั้ง.
12. อธิบายโค้ดที่ไม่คุ้นเคยโดยใช้ข้อมูลตัวอย่างที่ชัดเจน
เข้าใจฟังก์ชันก่อนที่จะปรับเปลี่ยนมัน. นำ: รหัสโปรแกรมจริงและข้อมูลเข้าตัวอย่างหนึ่ง.
C4 · แม่แบบที่ปรับแต่งได้
อธิบายโค้ดนี้ให้กับนักพัฒนาที่เข้าใจ [BACKGROUND] แต่ยังไม่คุ้นเคยกับ [LANGUAGE OR PROJECT] โดยใช้ข้อมูลตัวอย่างต่อไปนี้: [INPUT] อธิบายข้อมูลเข้า สาขาที่เกี่ยวข้อง การเปลี่ยนแปลงสถานะ และผลลัพธ์ที่คาดหวัง
ชี้ให้เห็นชื่อฟังก์ชันและนิพจน์จริง ๆ แยกแยะระหว่างสิ่งที่โค้ดแสดงกับสมมติฐานเกี่ยวกับความพึ่งพาที่ขาดหายไป จบด้วยกรณีขอบหนึ่งกรณีที่ควรทดสอบ อย่าเขียนโค้ดใหม่หรือสร้างพฤติกรรมสำหรับฟังก์ชันที่ไม่มีคำนิยาม
[PASTE CODE]
ตรวจสอบผลลัพธ์: ตรวจสอบสาขาที่อธิบายไว้และค่าที่คืนมาเทียบกับโค้ด; หมายเหตุการพึ่งพาที่ขาดหายไปว่าเป็น "ไม่ทราบ".
การเปรียบเทียบผลลัพธ์ครั้งแรก · C
ฟังก์ชันทั้งสองที่ส่งคืนมาผ่านการทดสอบทั้ง 24 กรณี.
| ตรวจสอบ | คำแนะนำแบบเรียบง่าย | การสอนแบบมีโครงสร้าง |
|---|---|---|
| กรณีติดเชื้อในท้องถิ่นที่ไม่เกี่ยวข้องกัน | 24 / 24 | 24 / 24 |
| การเปลี่ยนแปลงภายในฟังก์ชันขนาดเล็ก | ใช่ | ใช่ |
| การอ้างสิทธิ์ในการทดสอบโดยใช้เครื่องมือ | ไม่มีคำกล่าวอ้างดังกล่าว | ระบุอย่างชัดเจนว่าไม่ดำเนินการ |
ทั้งเวอร์ชันแบบธรรมดาและเวอร์ชันแบบมีโครงสร้างต่างก็จัดการกับเกณฑ์น้ำหนัก ค่าส่งฟรีสำหรับสินค้าพื้นฐาน ค่าเพิ่มสำหรับพื้นที่ห่างไกล และข้อมูลป้อนเข้าที่ไม่ถูกต้อง ตามข้อกำหนดที่กำหนดไว้ของเรา คำตอบแบบมีโครงสร้างระบุอย่างชัดเจนว่ายังไม่ได้ดำเนินการทดสอบ เราจึงได้ลองเรียกใช้ทั้งสองฟังก์ชันด้วยตัวเอง และคำตอบแบบธรรมดาก็ไม่ได้ระบุว่าได้ดำเนินการทดสอบเช่นกัน.
ดูข้อมูลทั้งหมด 24 รายการ และผลการผ่าน/ไม่ผ่านจริง
| [กรัม, ยอดรวมย่อย (เซนต์), ระยะไกล] | เซนต์ที่คาดไว้ หรือข้อยกเว้น | ธรรมดา | มีโครงสร้าง |
|---|---|---|---|
| [1, 0, false] | 500 | ผ่าน | ผ่าน |
| [1000, 0, false] | 500 | ผ่าน | ผ่าน |
| [1001, 0, false] | 900 | ผ่าน | ผ่าน |
| [5000, 0, false] | 900 | ผ่าน | ผ่าน |
| [5001, 0, false] | 1500 | ผ่าน | ผ่าน |
| [1, 9999, false] | 500 | ผ่าน | ผ่าน |
| [1, 10000, false] | 0 | ผ่าน | ผ่าน |
| [1000, 10000, true] | 300 | ผ่าน | ผ่าน |
| [5001, 0, true] | 1800 | ผ่าน | ผ่าน |
| [1001, 9999, true] | 1200 | ผ่าน | ผ่าน |
| [5001, 10001, false] | 0 | ผ่าน | ผ่าน |
| [0, 0, false] | ValueError | ผ่าน | ผ่าน |
| [-1, 0, false] | ValueError | ผ่าน | ผ่าน |
| [1.0, 0, false] | ValueError | ผ่าน | ผ่าน |
| ["1000", 0, false] | ValueError | ผ่าน | ผ่าน |
| [จริง, 0, ผิด] | ValueError | ผ่าน | ผ่าน |
| [null, 0, false] | ValueError | ผ่าน | ผ่าน |
| [1, -1, false] | ValueError | ผ่าน | ผ่าน |
| [1, false, false] | ValueError | ผ่าน | ผ่าน |
| [1, 1.5, false] | ValueError | ผ่าน | ผ่าน |
| [1, "0", false] | ValueError | ผ่าน | ผ่าน |
| [1, 0, 1] | ValueError | ผ่าน | ผ่าน |
| [1, 0, null] | ValueError | ผ่าน | ผ่าน |
| [0, 10000, false] | ValueError | ผ่าน | ผ่าน |
ข้อมูลนำเข้าและผลลัพธ์ที่คาดหวังได้กำหนดไว้ก่อนการสร้าง ค่าที่ส่งคืนต้องเป็นตัวเลขเต็มแบบแม่นยำ ส่วนข้อมูลนำเข้าที่ไม่ถูกต้องต้องก่อให้เกิดข้อผิดพลาด ValueError ทั้งสองฟังก์ชันได้รับการตรวจสอบแล้วจึงถูกเรียกใช้ในกระบวนการท้องถิ่น โดยถูกจำกัดการเข้าถึงเครือข่าย การอ่านไฟล์ของผู้ใช้ และการเขียนไฟล์ถูกปฏิเสธ การผ่านกรณีทดสอบเหล่านี้เป็นหลักฐานยืนยันความถูกต้องของฟังก์ชันและข้อกำหนดนี้ ไม่ใช่การยืนยันว่าพร้อมสำหรับการใช้งานในสภาพแวดล้อมการผลิต.
เวลาที่ผ่านไปแล้ว: 12.58 วินาที / 13.30 วินาที. จำนวนโทเคนข้อมูลเข้าและออกที่รายงาน: 553 + 735 / 621 + 1015. มีคำตอบหนึ่งครั้งต่อแต่ละครั้ง; ไม่มีการลองใหม่.
คำแนะนำแบบเรียบง่าย — คำแนะนำและเอกสารต้นฉบับครบถ้วน
แก้ไขฟังก์ชันตามข้อกำหนดด้านล่างและส่งมอบผลลัพธ์ตามที่กำหนด
# เครื่องคำนวณค่าส่งสมมติ
Python 3. ไม่ใช้เครือข่ายหรือแพ็กเกจภายนอก แก้ไขฟังก์ชัน shipping_cents(weight_grams, subtotal_cents, remote=False) ในโค้ดด้านล่าง
ข้อกำหนด:
- weight_grams เป็นจำนวนเต็มบวก subtotal_cents เป็นจำนวนเต็มไม่ติดลบ ค่า bool ของ Python ไม่ถือเป็นจำนวนเต็มที่ถูกต้องสำหรับข้อมูลเข้าทั้งสองตัวนี้
- remote ต้องเป็น bool
- ให้เกิดข้อผิดพลาด ValueError สำหรับข้อมูลเข้าที่ไม่ถูกต้องทุกกรณี แม้เมื่อคำสั่งซื้อมีสิทธิ์ได้รับค่าจัดส่งพื้นฐานฟรี
- ค่าจัดส่งพื้นฐานคือ 500 เซนต์ สำหรับ 1–1000 กรัม, 900 เซนต์ สำหรับ 1001–5000 กรัม, และ 1500 เซนต์ สำหรับมากกว่า 5000 กรัม
- ยอดรวมก่อนภาษีอย่างน้อย 10,000 เซนต์ จะยกเว้นค่าจัดส่งพื้นฐานเท่านั้น
- การจัดส่งไปยังพื้นที่ห่างไกลจะเพิ่ม 300 เซนต์ รวมถึงคำสั่งซื้อที่มีค่าจัดส่งพื้นฐานฟรี
- คืนค่าเป็นจำนวนเต็ม (int) รักษาลายเซ็นของฟังก์ชันไว้ อย่าเปลี่ยนแปลงข้อมูลอินพุต ดำเนินการ I/O หรือนำเข้าแพ็กเกจ
โค้ดที่มีข้อผิดพลาด:
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if subtotal_cents >= 10000:
return 0
if weight_grams < 1000:
fee = 500
elif weight_grams < 5000:
fee = 900
else:
fee = 1500
if remote:
fee += 300
return fee
```
สิ่งที่ต้องส่ง: บล็อก Python แบบมีรั้วหนึ่งบล็อกที่ประกอบด้วยฟังก์ชันที่แก้ไขแล้ว ตามด้วยคำอธิบายสั้นๆ เกี่ยวกับการเปลี่ยนแปลง อย่าอ้างว่าได้รันโค้ดแล้ว เว้นแต่คุณมีเครื่องมือสำหรับการรันโค้ดจริงๆ ผู้ประเมินจะรันกรณีต่างๆ ที่ครอบคลุมค่าเกณฑ์ กฎการจัดส่งฟรี ค่าธรรมเนียมเพิ่มเติมสำหรับการจัดส่งระยะไกล และทุกประเภทข้อมูลนำเข้าที่ไม่ถูกต้องในข้อกำหนดนี้.
คำแนะนำแบบเรียบง่าย — คำตอบต้นฉบับครบถ้วน
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if isinstance(weight_grams, bool) or not isinstance(weight_grams, int):
raise ValueError("weight_grams ต้องเป็นค่าจำนวนเต็ม")
if weight_grams <= 0:
raise ValueError("weight_grams ต้องเป็นค่าบวก")
if isinstance(subtotal_cents, bool) or not isinstance(subtotal_cents, int):
raise ValueError("subtotal_cents ต้องเป็น int")
if subtotal_cents < 0:
raise ValueError("subtotal_cents ต้องเป็นค่าไม่ติดลบ")
if not isinstance(remote, bool):
raise ValueError("remote ต้องเป็น bool")
if weight_grams <= 1000:
fee = 500
elif weight_grams = 10000:
fee = 0
if remote:
fee += 300
return fee
```
การเปลี่ยนแปลง:
1. **เพิ่มการตรวจสอบข้อมูลเข้า**: ตรวจสอบว่า `weight_grams` และ `subtotal_cents` เป็น `int` (ไม่รวม `bool` เนื่องจาก `bool` เป็นคลาสย่อยของ `int`), ว่า `weight_grams` เป็นค่าบวก, `subtotal_cents` เป็นค่าไม่ติดลบ, และ `remote` เป็น `bool`. หากไม่เป็นไปตามเงื่อนไขดังกล่าว จะเกิดข้อผิดพลาด `ValueError` แม้ว่าการสั่งซื้อนั้นจะมีสิทธิ์ได้รับบริการจัดส่งฟรีก็ตาม
2. **ปรับค่าขีดจำกัดน้ำหนัก**: เปลี่ยน `< 1000` และ `< 5000` เป็น `<= 1000` และ `<= 5000` เพื่อให้ช่วงน้ำหนัก (1000g, 5000g) จะอยู่ในระดับที่ถูกต้องตามข้อกำหนด ("1–1000 กรัม", "1001–5000 กรัม", "มากกว่า 5000 กรัม")
3. **แก้ไขลำดับการทำงานของระบบส่งสินค้าฟรี**: โค้ดเดิมจะคืนค่า `0` ทันทีเมื่อยอดรวมย่อยตรงเงื่อนไขส่งสินค้าฟรี โดยข้ามขั้นตอนการคำนวณค่าธรรมเนียมส่งสินค้าไปยังพื้นที่ห่างไกลไปทั้งหมด ตอนนี้ ค่าพื้นฐานจะถูกคำนวณก่อน หากยอดรวมย่อยมีคุณสมบัติตรงตามเงื่อนไข ค่าพื้นฐานจะถูกตั้งเป็นศูนย์ และ *จากนั้น* ค่าเพิ่มสำหรับการส่งไปยังพื้นที่ห่างไกลจะถูกเพิ่มเข้าไป — เพื่อให้มั่นใจว่าการส่งไปยังพื้นที่ห่างไกลยังคงเพิ่ม 300 เซนต์ แม้จะมีค่าส่งพื้นฐานฟรี
4. **ประเภทการคืนค่า**: ค่าทั้งหมดยังคงเป็นจำนวนเต็ม (int) ตามเดิม ซึ่งตรงตามข้อกำหนดการคืนค่า `int`.การสอนแบบมีโครงสร้าง — คำแนะนำและเอกสารอ้างอิงที่ครบถ้วน
แก้ไขฟังก์ชันให้ตรงกับข้อกำหนดที่ครบถ้วน ตรวจสอบความถูกต้องของข้อมูลเข้าก่อนที่จะมีการคืนค่าก่อนกำหนด รักษาค่าขีดจำกัดที่รวมค่าไว้ และแยกค่าธรรมเนียมพื้นฐานออกจากค่าธรรมเนียมเพิ่มเติมสำหรับการส่งไปยังพื้นที่ห่างไกล ให้ฟังก์ชันและคำอธิบายตามที่ขอ รายงานเฉพาะการตรวจสอบที่คุณได้ดำเนินการจริงเท่านั้น
# เครื่องคำนวณค่าส่งสมมติ
Python 3. ไม่ใช้เครือข่ายหรือแพ็กเกจภายนอก. แก้ไขฟังก์ชัน shipping_cents(weight_grams, subtotal_cents, remote=False) ในโค้ดด้านล่าง
ข้อกำหนด:
- weight_grams เป็นจำนวนเต็มบวก subtotal_cents เป็นจำนวนเต็มไม่ติดลบ ค่า bool ของ Python ไม่ถือเป็นจำนวนเต็มที่ถูกต้องสำหรับข้อมูลเข้าทั้งสองตัวนี้
- remote ต้องเป็น bool
- ให้เกิดข้อผิดพลาด ValueError สำหรับข้อมูลเข้าที่ไม่ถูกต้องทุกกรณี แม้เมื่อคำสั่งซื้อมีสิทธิ์ได้รับค่าจัดส่งพื้นฐานฟรี
- ค่าจัดส่งพื้นฐานคือ 500 เซนต์ สำหรับ 1–1000 กรัม, 900 เซนต์ สำหรับ 1001–5000 กรัม, และ 1500 เซนต์ สำหรับมากกว่า 5000 กรัม
- ยอดรวมก่อนภาษีอย่างน้อย 10,000 เซนต์ จะยกเว้นค่าจัดส่งพื้นฐานเท่านั้น
- การจัดส่งไปยังพื้นที่ห่างไกลจะเพิ่ม 300 เซนต์ รวมถึงคำสั่งซื้อที่มีค่าจัดส่งพื้นฐานฟรี
- คืนค่าเป็นจำนวนเต็ม (int) รักษาลายเซ็นของฟังก์ชันไว้ อย่าเปลี่ยนแปลงข้อมูลอินพุต ดำเนินการ I/O หรือนำเข้าแพ็กเกจ
โค้ดที่มีข้อผิดพลาด:
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if subtotal_cents >= 10000:
return 0
if weight_grams < 1000:
fee = 500
elif weight_grams < 5000:
fee = 900
else:
fee = 1500
if remote:
fee += 300
return fee
```
สิ่งที่ต้องส่ง: บล็อก Python แบบมีรั้วหนึ่งบล็อกที่ประกอบด้วยฟังก์ชันที่แก้ไขแล้ว ตามด้วยคำอธิบายสั้นๆ เกี่ยวกับการเปลี่ยนแปลง อย่าอ้างว่าได้รันโค้ดแล้ว เว้นแต่คุณมีเครื่องมือสำหรับการรันโค้ดจริงๆ ผู้ประเมินจะรันกรณีต่างๆ ที่ครอบคลุมค่าเกณฑ์ กฎการจัดส่งฟรี ค่าธรรมเนียมเพิ่มเติมสำหรับการจัดส่งระยะไกล และทุกประเภทข้อมูลนำเข้าที่ไม่ถูกต้องในข้อกำหนดนี้
การสอนแบบมีโครงสร้าง — คำตอบต้นฉบับที่สมบูรณ์
```python
def shipping_cents(weight_grams, subtotal_cents, remote=False):
if isinstance(weight_grams, bool) or not isinstance(weight_grams, int):
raise ValueError("weight_grams ต้องเป็น int (ไม่ใช่ bool)")
if weight_grams <= 0:
raise ValueError("weight_grams ต้องเป็นค่าบวก")
if isinstance(subtotal_cents, bool) or not isinstance(subtotal_cents, int):
raise ValueError("subtotal_cents ต้องเป็น int (ไม่ใช่ bool)")
if subtotal_cents < 0:
raise ValueError("subtotal_cents ต้องเป็นค่าไม่ติดลบ")
if not isinstance(remote, bool):
raise ValueError("remote ต้องเป็น bool")
if weight_grams <= 1000:
base_fee = 500
elif weight_grams = 10000:
base_fee = 0
surcharge = 300 if remote else 0
return base_fee + surcharge
```
คำอธิบายการเปลี่ยนแปลง:
1. **การตรวจสอบข้อมูลเข้าถูกย้ายไปก่อนการคืนค่าก่อนเวลา** โค้ดเดิมคืนค่า `0` สำหรับ `subtotal_cents >= 10000` โดยไม่ตรวจสอบข้อมูลเข้าก่อน ตอนนี้การตรวจสอบทั้งหมด (การตรวจสอบประเภทข้อมูลของ `weight_grams`, `subtotal_cents`, และ `remote` รวมถึงการยกเว้น `bool` อย่างชัดเจนสำหรับสองฟิลด์จำนวนเต็ม เนื่องจาก `bool` เป็นคลาสย่อยของ `int` ใน Python) จะเกิดขึ้นก่อนตรรกะการคำนวณค่าบริการหรือคำสั่ง return ใดๆ ดังนั้นข้อมูลเข้าที่ไม่ถูกต้องจะก่อให้เกิด `ValueError` เสมอ แม้ว่าการสั่งซื้อนั้นจะเข้าเงื่อนไขสำหรับการจัดส่งพื้นฐานฟรีก็ตาม
2. **แก้ไขค่าขีดจำกัดที่รวมค่าขอบเขตแล้ว** เวอร์ชันเดิมใช้ `< 1000` และ `< 5000` ซึ่งทำให้ค่าขอบเขต (1000 และ 5000) ถูกยกเว้นจากขีดจำกัดล่าง ซึ่งขัดกับข้อกำหนดในสเปคที่ระบุว่า "1–1000 กรัม" และ "1001–5000 กรัม" ที่รวมค่าขอบเขตไว้ด้วย ได้เปลี่ยนเป็น `<= 1000` และ `= 10000` ซึ่งทำให้ข้ามค่าธรรมเนียมเพิ่มเติมสำหรับการจัดส่งระยะไกลอย่างไม่ถูกต้องสำหรับคำสั่งซื้อที่มีบริการจัดส่งฟรี ตอนนี้ `base_fee` และ `surcharge` ถูกคำนวณอย่างอิสระ: `base_fee` จะถูกตั้งค่าเป็น `0` เมื่อถึงเกณฑ์ยอดรวมย่อย แต่ `surcharge` (300 เซนต์หากเป็น `remote`) จะถูกเพิ่มเข้าไปเสมอ เพื่อให้สอดคล้องกับ "การส่งสินค้าทางไกลเพิ่ม 300 เซนต์ รวมถึงคำสั่งซื้อที่มีค่าจัดส่งพื้นฐานฟรี"
4. **ประเภทค่าที่ส่งคืน** ส่วนประกอบของค่าธรรมเนียมทั้งหมดเป็นจำนวนเต็มธรรมดา (int) และผลรวม `base_fee + surcharge` ถูกส่งคืนเป็น `int` ซึ่งตรงกับลายเซ็นและประเภทค่าที่ส่งคืนที่กำหนดไว้
**การตรวจสอบที่ดำเนินการจริง:** ไม่มี — ผมไม่มีเครื่องมือสำหรับการรันโค้ดในสภาพแวดล้อมนี้ จึงยังไม่ได้รันโค้ดนี้ ข้อความข้างต้นอิงจากการอ่านสเปคด้วยมือและติดตามตรรกะด้วยตนเองเท่านั้น ผมยังไม่ได้รันเคสทดสอบกับโค้ดนี้.สำหรับงานที่ผสมผสานการเขียนโค้ดกับงานที่เกี่ยวข้องกับข้อความ รูปภาพ หรือวิดีโอ คุณสามารถ เชื่อมต่อ CLI ของ GlobalGPT กับโค้ดของ Claude และนำโมเดลและฟังก์ชันสื่อของแพลตฟอร์มมาใช้ในกระบวนการทำงานของเทอร์มินัล เริ่มต้นด้วยงานที่ชัดเจนและขั้นตอนการตรวจสอบที่คุณจะใช้เพื่อยืนยันผลลัพธ์.
มีอะไรเปลี่ยนแปลงเมื่อเราทำให้คำสั่งให้ชัดเจนขึ้น?
โครงสร้างเพิ่มเติมได้ช่วยในการตัดสินใจวิจัยครั้งนี้ แต่ไม่ได้ลบคำสัญญาเพิ่มเติมที่ระบุในอีเมลออกไป หรือปรับปรุงฟังก์ชันการจัดส่งที่ถูกต้องอยู่แล้ว เนื่องจากทั้งสองเวอร์ชันได้รับข้อกำหนดที่ครบถ้วน การเปรียบเทียบนี้จึงเป็นข้อเตือนใจที่มีประโยชน์ว่า คุณภาพของบรีฟมีความสำคัญก่อนที่จะเริ่มเพิ่มคำสั่งเพิ่มเติม.
ผลลัพธ์จากตัวอย่างคู่
งานต่าง ๆ จำเป็นต้องมีการตรวจสอบที่แตกต่างกัน.
| มาตรการเฉพาะงาน | คำแนะนำแบบเรียบง่าย | การสอนแบบมีโครงสร้าง | ควรทำอย่างไรกับผลลัพธ์ |
|---|---|---|---|
| การเขียนข้อมูลและคำมั่นสัญญา | 8/9 | 8/9 | ลบคำสัญญาที่จะติดตามผลที่ถูกสร้างขึ้น |
| การตรวจสอบหลักฐานการวิจัย | 6/8 | 7/8 | แก้ไขป้ายกำกับข้อมูลและเปรียบเทียบตัวหาร |
| ตัวอย่างพฤติกรรมของ Python | 24/24 | 24/24 | เก็บรักษาเอกสารข้อกำหนดที่สามารถรันได้และชุดทดสอบที่ทำงานได้อย่างอิสระ |
ตัวเลขเหล่านี้เป็นผลจากการนับจากรายการตรวจสอบต่าง ๆ ไม่ใช่เปอร์เซ็นต์ที่สามารถเปรียบเทียบกันได้ หรือคะแนนรวมของโมเดล ข้อความคำสั่งเต็ม คำตอบต้นฉบับ และรายละเอียดการทดสอบอยู่ใต้แต่ละตัวอย่าง เวลาการประมวลผลครั้งเดียวและจำนวนโทเคนใช้เพื่ออธิบายคำขอเหล่านี้เท่านั้น ไม่ได้แสดงถึงข้อได้เปรียบด้านความเร็วหรือค่าใช้จ่าย.
ใช้คำสั่งสั้นๆ เมื่องานและข้อมูลต้นทางชัดเจนแล้ว เพิ่มโครงสร้างเมื่อคำสั่ง เอกสาร ตัวอย่าง หรือข้อกำหนดที่ขัดแย้งกันเริ่มยากที่จะแยกแยะ. คำแนะนำของ Anthropic ยังแยกแยะพฤติกรรมที่เฉพาะเจาะจงตามแต่ละโมเดล, ดังนั้น นิสัยเก่าที่ชอบขอให้ตรวจสอบซ้ำๆ ไม่ควรกลายเป็นส่วนที่เพิ่มเข้าไปโดยอัตโนมัติในทุกคำขอ.
วิธีแก้ไขข้อความแจ้งเตือนที่ให้คำตอบไม่ชัดเจน
เปลี่ยนส่วนที่ก่อให้เกิดปัญหา หากคำตอบที่กำหนดกำหนดเส้นตายไว้ คำว่า “ปรับปรุงให้ดีขึ้น” จะกว้างเกินไป ให้ชี้ให้เห็นรายละเอียดที่ไม่มีหลักฐานสนับสนุน กำหนดขอบเขต และขอให้แก้ไขอย่างเฉพาะเจาะจง ให้เก็บคำตอบเดิมไว้หากคุณกำลังเปรียบเทียบเวอร์ชันของคำสั่ง แทนที่จะแทนที่มันไปอย่างเงียบๆ.
| เกิดปัญหาอะไร | สิ่งที่ต้องจัดหาหรือเปลี่ยนแปลง | การติดตามผลที่มีประโยชน์ |
|---|---|---|
| คำตอบนั้นเป็นคำตอบทั่วไป | ผู้อ่าน, งานปฏิบัติที่ชัดเจน และวัสดุจริง | เขียนใหม่สำหรับ [กลุ่มเป้าหมาย] โดยใช้ข้อมูลต่อไปนี้เท่านั้น: [สรุปสั้นๆ]. |
| เสียงนี้ฟังแล้วรู้สึกไม่ถูก | ตัวอย่างงานเขียนของคุณเอง | ให้ปรับให้สอดคล้องกับจังหวะและระดับความเป็นทางการของตัวอย่างนี้; และรักษาข้อมูลในคำสั่งใหม่ไว้. |
| มันเพิ่มคำสัญญา | ขอบเขตที่ชัดเจนและประโยคที่ก่อให้เกิดปัญหา | ยกเลิกข้อผูกพันในการติดตามผล แหล่งข้อมูลไม่ได้ให้สิทธิ์ในเรื่องนี้. |
| การอ้างอิงนี้ดูน่าเชื่อถือ | ข้อความที่อ้างอิงจริง | ข้อความนี้สนับสนุนคำกล่าวทั้งหมด ส่วนหนึ่ง หรือไม่สนับสนุนเลย? |
| สองค่าเปอร์เซ็นต์นี้ดูคล้ายกัน | คำนิยาม, ตัวหาร, กลุ่มประชากร, ช่วงเวลา | ก่อนที่จะเปรียบเทียบอัตรา ให้ระบุว่าแต่ละเปอร์เซ็นต์นั้นถูกหารด้วยอะไร. |
| โค้ดดูถูกต้อง แต่ไม่ทำงาน | ข้อมูลนำเข้าที่ก่อให้เกิดข้อผิดพลาดและผลลัพธ์ที่คาดไว้ ซึ่งสามารถทำซ้ำได้ | การป้อนข้อมูลนี้ควรให้ผลลัพธ์เป็น [value] แต่กลับให้ผลลัพธ์เป็น [value] โปรดแก้ไขกฎและรันกรณีนี้. |
สำหรับความต้องการที่ขาดหายไปจริง ๆ ให้ Claude ถามคำถามที่ตรงประเด็น ส่วนสำหรับงานทั่วไปที่มีบริบทเพียงพอ การสัมภาษณ์ 20 คำถามที่บังคับใช้จะเพียงแต่ทำให้งานล่าช้าเท่านั้น เช่นเดียวกัน ให้ขอคำอธิบายที่สั้น gọn หลักฐาน หรือผลการทดสอบ แทนที่จะขอสำเนาของกระบวนการคิดภายในส่วนตัว.
เก็บข้อความแนะนำที่มีประโยชน์ไว้พร้อมกับรูปแบบข้อมูลที่ป้อนเข้าและขั้นตอนการตรวจสอบที่ตรวจพบข้อผิดพลาด หากงานดังกล่าวกลายเป็นกระบวนการทำงานของแอปพลิเคชันที่สามารถทำซ้ำได้, การใช้ Claude ผ่าน API ให้คุณมีพื้นที่เพื่อจัดเก็บเวอร์ชันของคำสั่งและบันทึกคำขอไว้ คุณสามารถตรวจสอบตัวอย่างของคุณเองอีกครั้งเมื่อข้อกำหนดของโมเดลหรืองานมีการเปลี่ยนแปลง.
คำถามที่พบบ่อย
คำสั่งที่ดีสำหรับ Claude ควรมีอะไรบ้าง?
ให้รวมงานที่ต้องทำ บริบทหรือข้อมูลต้นฉบับที่เกี่ยวข้อง ข้อจำกัดสำคัญ ผลลัพธ์ที่ต้องการ และวิธีการตรวจสอบความสำเร็จ สำหรับคำขอที่เรียบง่าย ประโยคเดียวสามารถครอบคลุมหลายข้อได้ หากต้องการรวมเอกสาร ตัวอย่าง หรือกฎเกณฑ์ที่อาจก่อให้เกิดความสับสนได้ง่าย ให้ใช้โครงสร้างที่ชัดเจนขึ้น.
คำสั่ง Claude จำเป็นต้องใช้แท็ก XML หรือไม่?
ไม่ครับ ภาษาธรรมดาที่ชัดเจนเป็นจุดเริ่มต้นที่มีประโยชน์ แท็ก XML สามารถช่วยแยกคำสั่ง ตัวอย่าง และข้อความต้นฉบับในคำสั่งที่ซับซ้อนได้ ให้ใช้ชื่อแท็กที่อธิบายได้ชัดเจน เพื่อให้ส่วนต่าง ๆ ติดตามได้ง่ายขึ้น แท็กไม่รับประกันความถูกต้องของข้อมูล และเพียงการมีแท็กอยู่เท่านั้น ก็ไม่สามารถยืนยันได้ว่าคำสั่งใดดีกว่า.
Claude สามารถตรวจสอบแหล่งข้อมูลที่มันไม่สามารถเปิดได้หรือไม่?
ระบบสามารถวิเคราะห์ข้อความที่คุณให้มาได้ แต่ชื่อแหล่งที่มาหรือ URL เพียงอย่างเดียวไม่เพียงพอที่จะกำหนดเนื้อหาของหน้าเว็บนั้นได้ โปรดคัดลอกข้อความที่เกี่ยวข้องมาวาง หรือใช้เครื่องมือการค้นหาที่มีอยู่เพื่อค้นหาข้อความนั้น จากนั้นตรวจสอบทั้งข้อความที่อ้างอิงและว่าข้อความนั้นสนับสนุนข้ออ้างที่แนบมาด้วยหรือไม่.
ผมสามารถใช้คำสั่งเดียวกันใน Claude chat และ Claude Code ได้ไหมครับ?
คุณสามารถใช้任务และข้อจำกัดเดิมได้ แต่ต้องปรับคำขอให้เหมาะสมกับเครื่องมือที่มีอยู่ ในช่องแชท ให้ระบุโค้ดและบริบทที่เกี่ยวข้อง ใน Claude Code คุณสามารถอ้างอิงไฟล์โครงการที่เข้าถึงได้และขอรันการทดสอบ คำคำสั่งที่ระบุว่า “run the tests” ไม่ถือเป็นหลักฐานว่าการทดสอบได้รันจริง.
คำสั่ง Claude ที่ดีที่สุดคือคำสั่งที่คุณสามารถปรับใช้และตรวจสอบได้ เริ่มต้นด้วยงานที่ทำซ้ำๆ หนึ่งงาน แทนที่เนื้อหาตัวอย่างด้วยเนื้อหาของคุณเอง และใช้การตรวจสอบที่อยู่ข้างๆ แม่แบบก่อนที่จะเชื่อถือคำตอบ. ลองใช้ขั้นตอนการทำงานใน GlobalGPT เมื่อขั้นตอนต่อไปของคุณต้องการใช้โมเดลหรือเครื่องมือ AI อื่นในพื้นที่ทำงานเดียวกัน.
แหล่งข้อมูลและวันที่ทดสอบ: เอกสารคำชี้แนะอย่างเป็นทางการและเอกสารรหัส Claude ได้ถูกตรวจสอบเมื่อวันที่ 14 กันยายน 2026 ตัวอย่างคู่ดังกล่าวถูกสร้างขึ้นด้วย Claude ใน GlobalGPT ในวันดังกล่าว โดยใช้เนื้อหาสมมติ โปรดศึกษาคำชี้แนะและคำตอบทั้งหมดข้างต้น แล้วปรับใช้แม่แบบให้เหมาะสมกับงานของคุณ.
