องค์กรส่วนใหญ่ใช้ Claude ในระดับที่พนักงานแต่ละคนพิมพ์คำสั่งของตัวเอง ผลคือคนสิบคนได้ผลลัพธ์สิบแบบจากงานเดียวกัน สิ่งที่แก้เรื่องนี้ไม่ใช่การสอนให้ทุกคนเขียนคำสั่งเก่งขึ้น แต่คือการย้ายวิธีทำงานขององค์กรไปไว้ในเครื่องมือ ผ่าน Projects, คำสั่งระดับองค์กร และ skills บทความนี้อธิบายสามอย่างนี้และลำดับที่ควรทำ
สามชั้นที่ทำให้ทีมได้ผลลัพธ์แบบเดียวกัน
ชั้นที่ 1 Projects — บริบทของงานหนึ่งชุด Project คือพื้นที่ที่เก็บเอกสารอ้างอิงและคำสั่งเฉพาะของงานนั้นไว้ด้วยกัน ทุกคนที่เข้ามาทำงานใน Project เดียวกันจึงทำงานจากข้อมูลชุดเดียวกัน เหมาะกับงานที่มีบริบทตายตัว เช่น การตอบคำถามจากคู่มือสินค้า การเขียนเอกสารตามรูปแบบของบริษัท หรืองานของโครงการหนึ่ง
ชั้นที่ 2 คำสั่งระดับองค์กร — กติกาที่ใช้กับทุกงาน ผู้ดูแลตั้งคำสั่งระดับองค์กรได้ตั้งแต่แผน Team ขึ้นไป สิ่งที่ควรอยู่ในนี้คือกติกาที่ใช้กับทุกบทสนทนา เช่น ภาษาที่ใช้ในเอกสาร รูปแบบที่องค์กรใช้ คำที่ห้ามใช้ และข้อเตือนเรื่องข้อมูลที่ห้ามป้อน ข้อนี้ทำครั้งเดียวแล้วมีผลกับทุกคน
ชั้นที่ 3 Skills — วิธีทำงานที่กระจายให้ทั้งองค์กร skill คือชุดวิธีทำงานสำหรับงานเฉพาะอย่างที่เตรียมไว้ล่วงหน้า แล้วกระจายให้ทุกคนใช้ได้เหมือนกัน แทนที่จะให้แต่ละคนคิดวิธีเอง เหมาะกับงานที่มีขั้นตอนตายตัวและทำบ่อย เช่น การจัดรูปแบบรายงานประจำเดือน หรือการตรวจเอกสารตามเช็กลิสต์ขององค์กร
แต่ละชั้นใช้เมื่อไร
- งานหนึ่งโครงการที่มีเอกสารอ้างอิงเฉพาะ ใช้ Projects
- กติกาที่ต้องใช้กับทุกงานทั้งองค์กร ใช้คำสั่งระดับองค์กร
- ขั้นตอนทำงานตายตัวที่หลายทีมต้องทำเหมือนกัน ใช้ skills
- ตอบคำถามจากเอกสารภายในจำนวนมาก ใช้ระบบค้นคืนเอกสารแทน (อ่านเรื่อง RAG)
ความผิดพลาดที่พบบ่อยคือเอาทุกอย่างยัดลงคำสั่งระดับองค์กรจนยาวเกินไป ซึ่งทำให้คำสั่งสำคัญถูกกลบ ให้เก็บเฉพาะกติกาที่ใช้กับทุกงานจริง ๆ ส่วนที่เหลือย้ายไป Project หรือ skill
เขียนคำสั่งระดับองค์กรอย่างไรให้ได้ผล
สิ่งที่ควรมี
- ภาษาและโทน เช่น เอกสารภายนอกใช้ภาษาทางการ เอกสารภายในใช้ภาษากระชับ
- รูปแบบผลลัพธ์ที่องค์กรใช้ เช่น รายงานเริ่มด้วยสรุปหนึ่งย่อหน้าก่อนรายละเอียดเสมอ
- สิ่งที่ห้ามทำ เช่น ห้ามเติมตัวเลขที่ไม่มีในต้นฉบับ ห้ามคาดเดาชื่อบุคคล
- ข้อเตือนเรื่องข้อมูล เตือนให้ปกปิดข้อมูลลูกค้าก่อนป้อน (เช็กลิสต์สำหรับพนักงาน)
สิ่งที่ไม่ควรมี คือรายละเอียดเฉพาะของแผนกใดแผนกหนึ่ง และคำสั่งที่ยาวเป็นหน้าจนไม่มีใครอ่านตอนแก้
ลำดับที่ควรทำ
- เริ่มจากคำสั่งระดับองค์กรสั้น ๆ ห้าถึงสิบบรรทัดที่เป็นกติกาจริง ไม่ใช่ความปรารถนา
- ให้ทีมนำร่องสร้าง Project ของงานที่ทำซ้ำ หนึ่งทีม หนึ่งงาน แล้วดูว่าผลลัพธ์นิ่งขึ้นจริงไหม
- เมื่อ Project นั้นนิ่งแล้ว ค่อยยกขึ้นเป็น skill เพื่อกระจายให้ทีมอื่นใช้
- ทบทวนทุกไตรมาส เอาสิ่งที่ไม่มีใครใช้ออก และอัปเดตเอกสารอ้างอิงที่เก่าแล้ว
ข้อที่สี่สำคัญที่สุดและถูกข้ามบ่อยที่สุด เอกสารอ้างอิงใน Project ที่ไม่มีใครดูแลจะเก่าลงเงียบ ๆ แล้ววันหนึ่งทั้งทีมก็ได้คำตอบที่อิงเงื่อนไขปีที่แล้ว ทุกชุดจึงต้องมีชื่อคนรับผิดชอบเหมือนเอกสารอื่นขององค์กร (จัดบ้านข้อมูลก่อนใช้ AI)
สัญญาณว่าทำถูกทาง
- คนใหม่ในทีมได้ผลลัพธ์ใกล้เคียงคนเก่าตั้งแต่สัปดาห์แรก
- ไม่มีใครต้องส่งคำสั่งยาว ๆ ให้กันทางแชตอีก
- เมื่อองค์กรเปลี่ยนรูปแบบเอกสาร แก้ที่เดียวแล้วมีผลกับทุกคน
- เวลาที่ใช้แก้ผลลัพธ์ก่อนส่งลดลง ไม่ใช่แค่เวลาที่ใช้สร้างร่างแรก
อ่านต่อ
บทความนี้อยู่ในคลัสเตอร์Claude ในองค์กร ถ้าจะให้ทีมใช้แบบทำงานหลายขั้นตอน อ่านCowork ในองค์กร และถ้าต้องการให้ทุกคนใช้ได้เหมือนกันหลังอบรม อ่านหลักสูตรอบรม Claude พื้นฐานการเขียนคำสั่งที่ทุกคนควรมีอยู่ที่พื้นฐานการเขียน prompt และหลักสูตร Prompt Engineering Essentials