อย่าให้ LLM
คิดเลข

เรากำลังเขียน skill ตัวหนึ่งให้ช่วยเตรียมงบการเงินเพื่อยื่นกรมพัฒนาธุรกิจการค้าทางออนไลน์ (DBD e-Filing) ขั้นตอนคร่าวๆ คือ ดึงงบทดลองจากซอฟต์แวร์บัญชี จับแต่ละบัญชีเข้ารายการย่อตามแบบที่กรมกำหนด แล้วประกอบเป็นงบดุลกับงบกำไรขาดทุนให้พร้อมยื่น

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

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

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

ช่วงที่ 1จุดที่เกือบปล่อยให้ LLM คิดเลข

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

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

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

เลยถอยกลับมาถามตัวเองว่า งานในขั้นตอนนี้ ตรงไหนที่เป็นของโมเดลจริงๆ และตรงไหนที่ไม่ใช่

ช่วงที่ 2ในทุก skill มีงานสองแบบที่ต้องแยกออกจากกัน

พอแยกดูทีละขั้น งานในการเตรียมงบมันมีอยู่สองชนิดที่ต่างกันคนละขั้ว

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

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

เส้นแบ่งทั้งหมดสรุปเป็นคำถามสองข้อ ถามก่อนลงมือทุกขั้นตอน

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

ถ้าคำตอบของขั้นตอนหนึ่งขึ้นกับการอ่านและตีความจริงๆ ไม่มีคำตอบเดียวที่ถูก งานนั้นถึงค่อยเป็นของ LLM วางผิดทางพังได้ทั้งสองด้าน เอา LLM ไปทำงานที่ต้องเป๊ะ ผลก็มั่วและไม่ซ้ำเดิม เอาโค้ดไปทำงานที่ต้องตีความ มันก็เปราะ เจอข้อมูลจริงที่ไม่เข้าแม่แบบเมื่อไหร่ก็ล้ม

ช่วงที่ 3เครื่องยนต์ที่เทสต์ล็อกไว้

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

หน้าตาแนวคิดเรียบง่ายมาก ไม่ต้องมีอะไรซับซ้อน

ยอดสินทรัพย์ = ผลรวมของบรรทัดฝั่งสินทรัพย์
ยอดหนี้สิน + ส่วนของทุน = ผลรวมอีกฝั่ง
แล้วตรวจว่า สินทรัพย์ == หนี้สิน + ทุน ถ้าไม่เท่า แปลว่ามีอะไรผิด ฟ้องออกมาเลย

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

เรื่องการแยกแบบนี้ไม่ใช่กฎที่เราตั้งขึ้นเอง Anthropic เขียนไว้ในประกาศเปิดตัว Agent Skills ตรงตัวว่า skill สามารถแนบโค้ดที่รันได้ "สำหรับงานที่การเขียนโปรแกรมแบบเดิมเชื่อถือได้กว่าการให้โมเดลสร้าง token" นั่นคือเส้นเดียวกันเป๊ะ คือมีงานที่โค้ดทำได้ดีกว่า และคุณควรปล่อยให้โค้ดทำ

ช่วงที่ 4ทำไม golden test ถึงสำคัญกว่าที่คิด

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

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

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

ช่วงที่ 5เส้นแบ่งนี้ใช้ได้กับทุก skill ไม่ใช่แค่งานบัญชี

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

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

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

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

เขียนจากงานจริง ไม่ใช่ทฤษฎี จากการสร้าง skill เตรียมงบยื่นกรมพัฒน์จริง ที่แยกเครื่องยนต์คำนวณออกมาเป็นสคริปต์ + golden test แล้วทดสอบผ่าน

ที่มาและอ้างอิงReferences

• เครื่องยนต์คำนวณงบและ golden test มาจากงานจริงของเราเอง คือ skill เตรียมงบยื่น DBD e-Filing บันทึกไว้ภายในช่วงปลาย มิ.ย. 2026 (golden test รันผ่านจริง)
• คำพูดเรื่องแนบโค้ดที่รันได้ มาจาก Anthropic, "Introducing Agent Skills" ต้นฉบับว่า "Skills can include executable code for tasks where traditional programming is more reliable than token generation."
• รูปแบบรายการย่อและแบบงบการเงินอ้างอิงประกาศกรมพัฒนาธุรกิจการค้า (DBD) ที่เป็นข้อมูลสาธารณะ