ການພັດທະນາຈະປ່ຽນແປງໄປແນວໃດດ້ວຍ Claude Mythos ແລະ Fable — ຈາກການກວດສອບ "ການຈັດຕັ້ງປະຕິບັດທີ່ຖືກຕ້ອງ" ໄປສູ່ "ວຽກງານທີ່ຖືກຕ້ອງ"

Anthropic ໄດ້ເປີດຕົວ ຫຼື Launch Claude Mythos ຄລາດ ແລະ Claude Fable 5 ເຊິ່ງເປັນແບບຈໍາລອງທີ່ເປີດໃຫ້ໃຊ້ງານທົ່ວໄປໃນສາຍພັນດຽວກັນ ໃນວັນທີ 9 ມິຖຸນາ 2026. Fable 5 ມີຈຸດແຂງໃນດ້ານ "long-horizon agentic work (ການເຮັດວຽກແບບເອເຈນຕ໌ໃນໄລຍະຍາວ)" ແລະ ໄດ້ຮັບການອະທິບາຍວ່າໄດ້ມີການເພີ່ມປະສິດທິພາບໃນດ້ານວິສະວະກຳຊອບແວ, ວຽກງານທີ່ໃຊ້ຄວາມຮູ້ ແລະ ວຽກງານດ້ານການເບິ່ງເຫັນ.

ແບບຈໍາລອງລຸ້ນນີ້ຈະປ່ຽນແປງການເຮັດວຽກຕົວຈິງແນວໃດ—ຂໍ້ຄຶດນັ້ນແມ່ນມາຈາກການປະຕິບັດຕົວຈິງຂອງທີມ Claude Code. ວິສະວະກອນຂອງທີມດັ່ງກ່າວໄດ້ກ່າວວ່າ "Fable 5 ໄດ້ປ່ຽນແປງວິທີການເຮັດວຽກປະຈຳວັນຂອງທີມ" ແລະ "ເມື່ອກ່ອນພວກເຮົາເຄີຍກວດສອບວ່າ Claude ເຮັດວຽກຖືກຕ້ອງຫຼືບໍ່, ແຕ່ດຽວນີ້ພວກເຮົາກຳລັງກວດສອບວ່າສິ່ງທີ່ມັນເຮັດນັ້ນແມ່ນວຽກທີ່ຖືກຕ້ອງຫຼືບໍ່". ບົດຄວາມນີ້ຈະສະຫຼຸບໂດຍອີງໃສ່ຂໍ້ມູນທາງການ ເພື່ອໃຫ້ຫົວໜ້າທີມພັດທະນາ ແລະ ຜູ້ຮັບຜິດຊອບທີມທີ່ໃຊ້ AI coding agent ເປັນປະຈຳ ໄດ້ເຂົ້າໃຈວ່າ Claude Mythos / Fable 5 ຈະປ່ຽນແປງການພັດທະນາໄປໃນທິດທາງໃດ ແລະ ວິທີການອອກແບບເພື່ອມອບໝາຍວຽກໃຫ້ຢ່າງມີປະສິດທິພາບໂດຍບໍ່ຕົກຢູ່ໃນສະພາວະ "ການໂຍນວຽກໃຫ້ທັງໝົດ".

Claude Mythos ແມ່ນຮູບແບບໂມເດວຂອງ Claude ທີ່ເນັ້ນໃສ່ການເຮັດວຽກຂອງຕົວແທນ (Agent) ແບບອັດຕະໂນມັດໃນໄລຍະຍາວ, ສ່ວນ Claude Fable 5 ແມ່ນໂມເດວປະສິດທິພາບສູງທີ່ເປີດຕົວ ຫຼື Launch ອອກມາໃຫ້ໃຊ້ງານທົ່ວໄປໃນສາຍວິວັດທະນາການດັ່ງກ່າວ. ກ່ອນອື່ນໝົດ, ຂໍໃຫ້ເຮົາມາທຳຄວາມເຂົ້າໃຈກ່ຽວກັບຂໍ້ມູນທາງການວ່າ ທັງສອງຢ່າງນີ້ເຊິ່ງເປັນຕົວເອກຂອງບົດຄວາມນີ້ແມ່ນຫຍັງ ແລະ ມີການປັບປຸງໃຫ້ດີຂຶ້ນໃນດ້ານໃດແດ່.

Anthropic ໄດ້ເປີດຕົວ ຫຼື Launch Claude Fable 5 ແລະ Claude Mythos 5 ໃນວັນທີ 9 ມິຖຸນາ 2026. ຕາມການຈັດວາງຢ່າງເປັນທາງການ, Fable 5 ແມ່ນແບບຈຳລອງປະສິດທິພາບສູງທີ່ຢູ່ໃນຊັ້ນ Mythos ເຊິ່ງເປີດໃຫ້ໃຊ້ງານທົ່ວໄປ (ສຳລັບຜູ້ໃຊ້ທົ່ວໄປ) ແລະ ໄດ້ຮັບການແນະນຳວ່າເປັນແບບຈຳລອງທີ່ທຸກຄົນສາມາດນຳໃຊ້ໄດ້ໃນຊີວິດປະຈຳວັນ.

ເພື່ອຄວາມເຂົ້າໃຈໃນການຈັດລະບຽບຊື່, ຄວນເຂົ້າໃຈວ່າ "Mythos" ໝາຍເຖິງຊັ້ນ (ສາຍພັນ) ແລະ "Fable 5" ໝາຍເຖິງແບບຈຳລອງສະເພາະທີ່ເປີດໃຫ້ໃຊ້ງານຢ່າງກວ້າງຂວາງໃນສາຍພັນນັ້ນ. ໃນບົດຄວາມນີ້, ພວກເຮົາຈະກ່າວເຖິງຄົນລຸ້ນນີ້ໃນຖານະທີ່ເປັນໂຄງສ້າງພື້ນຖານ ຫຼື Infrastructure ທີ່ຮອງຮັບການເຮັດວຽກແບບອັດຕະໂນມັດຂອງ Claude Code ເຊິ່ງຈະກ່າວເຖິງໃນພາຍຫຼັງ, ດັ່ງນັ້ນຕໍ່ຈາກນີ້ໄປຈະເນັ້ນການກ່າວເຖິງ Fable 5 ເປັນຫຼັກ.

ຈຸດແຂງຂອງ Fable 5 ທີ່ທາງການໄດ້ລະບຸໄວ້ຄື long-horizon agentic work (ການເຮັດວຽກຂອງເອເຈນແບບໄລຍະຍາວ). ພ້ອມດຽວກັນນັ້ນ, ຍັງມີການອະທິບາຍວ່າຄວາມສາມາດໄດ້ຖືກເສີມໃຫ້ແຂງແກ່ນຂຶ້ນໃນຂົງເຂດຕ່າງໆ ເຊັ່ນ: ວິສະວະກຳຊອບແວ, ວຽກງານທີ່ໃຊ້ຄວາມຮູ້ ແລະ ວຽກງານດ້ານການເບິ່ງເຫັນ.

"ການເຮັດວຽກຂອງເອເຈນແບບໄລຍະຍາວ" ຈະສົ່ງຜົນດີກໍຍ້ອນວ່າປະລິມານວຽກທີ່ສາມາດຈັດການໄດ້ໃນການສັ່ງງານຄັ້ງດຽວນັ້ນມີຂະໜາດໃຫຍ່ຂຶ້ນ. ບໍ່ແມ່ນພຽງແຕ່ການຕື່ມລະຫັດ (code completion) ພຽງສອງສາມແຖວ, ແຕ່ AI ເອເຈນ ສາມາດດຳເນີນວຽກງານທີ່ຕໍ່ເນື່ອງກັນໄດ້ຢ່າງອິດສະຫຼະ ເຊິ່ງລວມໄປເຖິງການຕີຄວາມໝາຍຄວາມຕ້ອງການໄປຈົນເຖິງການຈັດຕັ້ງປະຕິບັດ ແລະ ການກວດສອບ—ຄຸນສົມບັດນີ້ເອງທີ່ເປັນຕົວສະໜັບສະໜູນທາງດ້ານເຕັກນິກໃຫ້ແກ່ການກວດສອບ ແລະ ການປ່ຽນແປງຮູບແບບການເຮັດວຽກທີ່ຈະໄດ້ເຫັນໃນຕໍ່ໜ້ານີ້.

ຕົວຢ່າງທີ່ສະແດງໃຫ້ເຫັນຢ່າງຊັດເຈນວ່າຮຸ່ນຂອງໂມເດວນີ້ຈະປ່ຽນແປງການເຮັດວຽກຕົວຈິງໄດ້ແນວໃດ ແມ່ນມາຈາກປະສົບການຕົວຈິງຂອງທີມງານ Claude Code. ທ່ານ Thariq Shihipar ເຊິ່ງເປັນວິສະວະກອນຂອງທີມງານດັ່ງກ່າວ ໄດ້ກ່າວຜ່ານທາງ X (Twitter ເດີມ) ວ່າ: "Claude Fable 5 changed how we work on the Claude Code team day to day (Fable 5 ໄດ້ປ່ຽນແປງວິທີການເຮັດວຽກປະຈຳວັນຂອງພວກເຮົາໃນທີມ Claude Code)" ແລະ "We used to verify that Claude did the work right. Now we verify that it's doing the right work. (ເມື່ອກ່ອນພວກເຮົາເຄີຍກວດສອບວ່າ Claude ເຮັດວຽກໄດ້ຖືກຕ້ອງຫຼືບໍ່ ແຕ່ຕອນນີ້ພວກເຮົາກວດສອບວ່າ ມັນກຳລັງເຮັດວຽກທີ່ຖືກຕ້ອງຢູ່ຫຼືບໍ່)".

ເຖິງແມ່ນວ່າທ່ານ Thariq ຈະຖືກແນະນຳໃນຖານະວິສະວະກອນຂອງທີມງານ Claude Code ທີ່ Anthropic, ແຕ່ຄວນສັງເກດວ່າໂພສເຫຼົ່ານີ້ບໍ່ແມ່ນເອກະສານທາງການ ແຕ່ເປັນພຽງປະສົບການຕົວຈິງ ແລະ ການໂຄສະນາຈາກສະມາຊິກໃນທີມເທົ່ານັ້ນ. ເຖິງຢ່າງໃດກໍຕາມ, ຄວາມຮູ້ສຶກທີ່ວ່າຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການກວດສອບກຳລັງປ່ຽນຈາກ "ຄວາມຖືກຕ້ອງຂອງການຈັດຕັ້ງປະຕິບັດ" ໄປສູ່ "ຄວາມຖືກຕ້ອງຂອງວຽກງານ" ນັ້ນ ກໍສອດຄ່ອງກັບການອອກແບບຟັງຊັນທາງການທີ່ຈະໄດ້ເຫັນໃນບົດຕໍ່ໄປ.

ການປ່ຽນແປງຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການກວດສອບ ໝາຍເຖິງການທີ່ນ້ຳໜັກຂອງວຽກງານໃນການກວດສອບ "ຄວາມຖືກຕ້ອງຂອງການຈັດຕັ້ງປະຕິບັດ" ແຕ່ລະແຖວນັ້ນຫຼຸດລົງ, ແລະ ນ້ຳໜັກຂອງວຽກງານໃນການກວດສອບວ່າ "ໄດ້ເຮັດວຽກທີ່ຖືກຕ້ອງຕາມຈຸດປະສົງແລ້ວຫຼືບໍ່" ນັ້ນເພີ່ມຂຶ້ນ. ບໍ່ໄດ້ໝາຍຄວາມວ່າການກວດສອບທັງສອງຢ່າງຈະໝົດໄປ, ສິ່ງທີ່ປ່ຽນແປງຄືການຈັດສັນເວລາອັນຈຳກັດຂອງມະນຸດວ່າຈະແບ່ງໃຫ້ກັບສ່ວນໃດຫຼາຍກວ່າກັນ.

ການກວດສອບແບບດັ້ງເດີມແມ່ນເນັ້ນໃສ່ການອ່ານຄວາມແຕກຕ່າງຂອງໂຄ້ດທີ່ AI ຂຽນຂຶ້ນເທື່ອລະແຖວ ເພື່ອກວດສອບຄວາມຖືກຕ້ອງຂອງໄວຍາກອນ, ປະເພດຂໍ້ມູນ (Type), ຕັກກະ (Logic) ແລະ ການຜ່ານການທົດສອບ. ນີ້ແມ່ນການກວດສອບເພື່ອເບິ່ງວ່າ "ໄດ້ມີການຈັດຕັ້ງປະຕິບັດຢ່າງຖືກຕ້ອງຫຼືບໍ່ (did it build the thing right)". ໃນຊ່ວງເວລາທີ່ເຄື່ອງມືຍັງມີຂອບເຂດຈຳກັດ, ຜົນລວມທີ່ AI ສົ່ງອອກມາແມ່ນມີພຽງແຕ່ສອງສາມແຖວ ຫຼື ປະມານໜຶ່ງຟັງຊັນເທົ່ານັ້ນ, ເຊິ່ງການໃຫ້ມະນຸດກວດສອບ (Review) ເພື່ອຮັບປະກັນຄວາມຖືກຕ້ອງນັ້ນຖືວ່າເປັນວິທີທີ່ເປັນໄປໄດ້ໃນຄວາມເປັນຈິງ.

ໃນຂັ້ນຕອນນີ້, ພາລະຂອງຜູ້ກວດສອບສ່ວນໃຫຍ່ແມ່ນມາຈາກການທີ່ "ບໍ່ສາມາດເຊື່ອໝັ້ນໃນສິ່ງທີ່ AI ຂຽນໄດ້ຢ່າງເຕັມຮ້ອຍ". ໃນຄວາມເປັນຈິງ, ໃນ ບົດຄວາມປຽບທຽບລະຫວ່າງ Claude Code ແລະ Codex ກໍໄດ້ລະບຸໄວ້ວ່າ ການນຳຜົນລວມຈາກ Agent ໄປໃຊ້ງານຈິງໂດຍບໍ່ຜ່ານການກວດສອບນັ້ນ ເປັນຄວາມຜິດພາດທີ່ພົບເຫັນໄດ້ທົ່ວໄປ. ການອ່ານຄວາມແຕກຕ່າງຢ່າງລະອຽດເປັນວິທີການຮັບປະກັນຄຸນນະພາບທີ່ມີປະສິດທິຜົນໃນຂະນະທີ່ຜົນລວມຍັງມີຂະໜາດນ້ອຍ.

ອີກດ້ານໜຶ່ງແມ່ນການກວດສອບທີ່ເບິ່ງວ່າ "ກຳລັງເຮັດວຽກທີ່ຖືກຕ້ອງຢູ່ຫຼືບໍ່ (is it doing the right work)". ເຖິງແມ່ນວ່າໂຄ້ດຈະບໍ່ມີຂໍ້ຜິດພາດ ແຕ່ຖ້າສິ່ງທີ່ກຳລັງສ້າງນັ້ນບໍ່ສອດຄ່ອງກັບຈຸດປະສົງ ຫຼື ຂໍ້ຈຳກັດ ການປະຕິບັດງານນັ້ນກໍຖືວ່າ "ບໍ່ແມ່ນວຽກທີ່ຖືກຕ້ອງ" ເຖິງຈະ "ຖືກຕ້ອງ" ໃນທາງເຕັກນິກກໍຕາມ. ມັນເປັນການກວດສອບເພື່ອຖາມຫາຄວາມສົມເຫດສົມຜົນໃນຂັ້ນຕອນຕົ້ນນ້ຳ ເຊັ່ນ: ການຕີຄວາມໝາຍຄວາມຕ້ອງການ, ການຕັດສິນໃຈດ້ານການອອກແບບ ແລະ ການຈັດລຳດັບຄວາມສຳຄັນ.

ຄວາມຮູ້ສຶກຂອງທີມງານ Claude Code ທີ່ໄດ້ອ້າງອີງໃນຕອນຕົ້ນທີ່ວ່າ "ຕອນນີ້ ພວກເຮົາກຳລັງກວດສອບວ່າວຽກນັ້ນຖືກຕ້ອງຫຼືບໍ່" ແມ່ນໝາຍເຖິງການກວດສອບໃນຂັ້ນຕອນຕົ້ນນ້ຳນີ້ເອງ. ເມື່ອສາມາດມອບໝາຍວຽກງານທີ່ເປັນຊຸດໄດ້ຄືກັບ Fable 5, ນ້ຳໜັກຂອງການກວດສອບຈະປ່ຽນໄປສູ່ການຕັ້ງຄຳຖາມກ່ຽວກັບທິດທາງຂອງສິ່ງທີ່ກຳລັງສ້າງຫຼາຍກວ່າການຕິດຕາມຄວາມຖືກຕ້ອງຂອງໂຄ້ດເທື່ອລະແຖວ—ຄວາມຮູ້ສຶກນີ້ບໍ່ແມ່ນສິ່ງທີ່ຂຽນໄວ້ໃນເອກະສານທາງການ ແຕ່ເປັນປະສົບການຕົວຈິງ ເຊິ່ງມັນກໍສອດຄ່ອງກັບການອອກແບບຟັງຊັນການເຮັດວຽກທາງການທີ່ຈະໄດ້ເຫັນໃນບົດຕໍ່ໄປ.

ການກວດສອບທັງສອງຢ່າງນີ້ບໍ່ແມ່ນ ການແລກປ່ຽນ ຫຼື Trade-off ແຕ່ເປັນຄົນລະຊັ້ນກັນ. "ຄວາມຖືກຕ້ອງຂອງການຈັດຕັ້ງປະຕິບັດ" ສາມາດຮັບປະກັນໄດ້ງ່າຍຂຶ້ນດ້ວຍວິທີການທາງເຄື່ອງຈັກຫຼາຍກວ່າແຕ່ກ່ອນ ໂດຍຜ່ານການກວດສອບປະເພດຂໍ້ມູນ (Type check), ການທົດສອບອັດຕະໂນມັດ, CI, ແລະການກວດສອບເຊິ່ງກັນແລະກັນລະຫວ່າງ Agent ທີ່ຈະກ່າວເຖິງໃນພາຍຫຼັງ. ດ້ວຍເຫດນີ້, ພາລະຂອງມະນຸດຈຶ່ງຫຼຸດລົງໃນດ້ານ "ຄວາມຖືກຕ້ອງຂອງການຈັດຕັ້ງປະຕິບັດ" ເປັນຫຼັກ.

ໃນທາງກົງກັນຂ້າມ, "ວຽກງານທີ່ຖືກຕ້ອງຫຼືບໍ່" ນັ້ນ ມະນຸດຜູ້ທີ່ເຂົ້າໃຈຈຸດປະສົງ, ພື້ນຖານຄວາມເປັນມາ, ແລະຂໍ້ຈຳກັດເທົ່ານັ້ນທີ່ຈະສາມາດຕັດສິນໄດ້ໃນຂັ້ນສຸດທ້າຍ. ສິ່ງນີ້ຈະບໍ່ຫາຍໄປ ແຕ່ຈະຍັງຄົງເປັນການກວດສອບທີ່ມະນຸດຕ້ອງໃຫ້ຄວາມສຳຄັນ. ນອກຈາກນີ້, ກົນໄກໃນການປ້ອງກັນຄວາມຜິດພາດໂດຍໃຊ້ "ໂຄງສ້າງ" (ເຊັ່ນ: CLAUDE.md, ກົດລະບຽບ, ແລະການສ້າງ CI guard) ແມ່ນປະເດັນທີ່ແຕກຕ່າງຈາກການກວດສອບ, ເຊິ່ງໄດ້ມີການອະທິບາຍຢ່າງລະອຽດໃນ Harness Engineering.

ສິ່ງທີ່ຊຸກຍູ້ໃຫ້ເກີດການປ່ຽນແປງນີ້ ແມ່ນມາຈາກ 3 ກົນໄກທີ່ເຮັດໃຫ້ AI ສາມາດ "ດຳເນີນວຽກງານຂະໜາດໃຫຍ່ໄດ້ໃນຄຳສັ່ງດຽວ, ລວມເຖິງການກວດສອບຄວາມຖືກຕ້ອງ" ໄດ້. ເຊິ່ງໄດ້ແກ່: ການປະຕິບັດງານທີ່ຂັບເຄື່ອນດ້ວຍເປົ້າໝາຍ, ການກວດສອບເຊິ່ງກັນແລະກັນໂດຍ Sub-agent, ແລະ ໂມເດວທີ່ມີຄວາມສາມາດໃນການເຮັດວຽກໄລຍະຍາວ. ຕໍ່ໄປນີ້ແມ່ນລາຍລະອຽດໂດຍອີງຕາມຂໍ້ມູນທາງການ.

/goal ແມ່ນຄຳສັ່ງຂອງ Claude Code ທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດຕັ້ງເງື່ອນໄຂການສຳເລັດວຽກໄດ້, ເຊິ່ງ Claude ຈະເຮັດວຽກຕໍ່ໄປຈົນກວ່າຈະບັນລຸເງື່ອນໄຂນັ້ນໂດຍບໍ່ຈຳເປັນຕ້ອງໃຫ້ຄຳສັ່ງໃນທຸກຂັ້ນຕອນ. ເອກະສານທາງການ (code.claude.com/docs/en/goal) ໄດ້ອະທິບາຍໄວ້ວ່າ "ເປັນການຕັ້ງເງື່ອນໄຂການສຳເລັດວຽກ ແລະ Claude ຈະເຮັດວຽກຕໍ່ໄປຈົນກວ່າຈະບັນລຸເງື່ອນໄຂນັ້ນໂດຍບໍ່ຕ້ອງມີການສັ່ງການໃນແຕ່ລະບາດກ້າວ". ການນຳໃຊ້ຄຳສັ່ງນີ້ຈຳເປັນຕ້ອງມີ Claude Code v2.1.139 ຂຶ້ນໄປ.

ຄວາມໝາຍຂອງມັນແມ່ນງ່າຍດາຍ, ເປັນການປ່ຽນແນວຄິດຈາກການສັ່ງງານເປັນຂັ້ນຕອນວ່າ "ຕໍ່ໄປເຮັດອັນນີ້, ຫຼັງຈາກນັ້ນເຮັດອັນນັ້ນ" ມາເປັນການກຳນົດເງື່ອນໄຂທີ່ຕ້ອງບັນລຸໃຫ້ແນ່ນອນກ່ອນ. ສິ່ງທີ່ກຳນົດຜົນສຳເລັດໃນທີ່ນີ້ຄື ການຂຽນເງື່ອນໄຂການສຳເລັດວຽກໃຫ້ຊັດເຈນພຽງໃດ. ຖ້າເງື່ອນໄຂບໍ່ຊັດເຈນ, ບໍ່ວ່າຕົວແບບຈະເກັ່ງສ່ຳໃດກໍບໍ່ສາມາດເຮັດວຽກໄດ້ຢ່າງຖືກຕ້ອງ. ສາມາດເວົ້າໄດ້ວ່າ ຄຳສັ່ງນີ້ແມ່ນປະຕູທຳອິດທີ່ຍ້າຍຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການກວດສອບໄປສູ່ "ການອອກແບບເງື່ອນໄຂ".

Dynamic workflows ແມ່ນຟັງຊັນຂອງ Claude Code ທີ່ Claude ຈະຂຽນສະຄຣິບ JavaScript ເພື່ອຈັດການ ແລະ ປະຕິບັດງານຂອງຊັບເອເຈນ (sub-agents) ຈຳນວນຫຼາຍໃນຂະໜາດໃຫຍ່. ເອກະສານທາງການ (code.claude.com/docs/en/workflows) ໄດ້ລະບຸການນຳໃຊ້ໄວ້ ເຊັ່ນ: ການກວດສອບບັກທົ່ວທັງໂຄ້ດເບສ (codebase), ການຍົກຍ້າຍລະບົບໃນຂະໜາດ 500 ໄຟລ໌, ແລະ ການຄົ້ນຄວ້າທີ່ຕ້ອງກວດສອບແຫຼ່ງຂໍ້ມູນເຊິ່ງກັນແລະກັນ.

ສິ່ງທີ່ຄວນສັງເກດແມ່ນການກວດສອບໄດ້ຖືກລວມເຂົ້າໃນກົນໄກການເຮັດວຽກ. ການອອກແບບລວມມີ "adversarial verification" (ການກວດສອບແບບປໍລະປັກ) ເຊິ່ງເປັນການທີ່ເອເຈນທີ່ເປັນອິດສະຫຼະຈະທົບທວນຄືນຜົນການຄົ້ນພົບ (findings) ຂອງກັນແລະກັນຢ່າງລະອຽດກ່ອນທີ່ຈະລາຍງານ. ຢ່າງໃດກໍຕາມ, ຟັງຊັນນີ້ຍັງຢູ່ໃນຂັ້ນຕອນ Research Preview, ການນຳໃຊ້ຈຳເປັນຕ້ອງມີ Claude Code v2.1.154 ຂຶ້ນໄປ ແລະ ແພັກເກດແບບເສຍເງິນ, ໂດຍໃນ Pro ຈະຕ້ອງເປີດໃຊ້ງານຜ່ານ /config. ຄວນຈື່ໄວ້ວ່າ ນີ້ບໍ່ແມ່ນຟັງຊັນທີ່ "ໃຜກໍສາມາດມອບໝາຍວຽກໃຫ້ເຮັດໄດ້ທັນທີ" ແຕ່ເປັນຟັງຊັນຂັ້ນສູງທີ່ມີເງື່ອນໄຂເບື້ອງຕົ້ນ. ສຳລັບແນວຄິດການອອກແບບທີ່ກ່ຽວຂ້ອງ, ສາມາດເບິ່ງເພີ່ມເຕີມໄດ້ທີ່ Agent orchestration ແລະ Multi-agent system.

ສິ່ງທີ່ຂັບເຄື່ອນຟັງຊັນເຫຼົ່ານີ້ໃຫ້ເຮັດວຽກໄດ້ຈິງ ກໍຄືໂມເດວທີ່ຮອງຮັບການເຮັດວຽກໄລຍະຍາວ ເຊັ່ນ Fable 5. ດັ່ງທີ່ໄດ້ເຫັນໃນບົດກ່ອນໜ້າ Fable 5 ມີຈຸດເດັ່ນໃນດ້ານ long-horizon agentic work ແລະ ໄດ້ຂະຫຍາຍຂອບເຂດຂອງວຽກທີ່ສາມາດຈັດການໄດ້ໃນຄັ້ງດຽວ. ດ້ວຍເຫດນີ້, ຟັງຊັນ "ມອບໝາຍວຽກແບບລວມສູນ" ເຊັ່ນ: ການຂັບເຄື່ອນດ້ວຍເປົ້າໝາຍຜ່ານ /goal ແລະ Dynamic workflows ຈຶ່ງສາມາດເຮັດວຽກໄດ້ຢ່າງແທ້ຈິງ.

ຍິ່ງໄປກວ່ານັ້ນ, ໃນການເປີດຕົວ ຫຼື Launch ຂອງ Claude Opus 4.8, ໄດ້ມີການອະທິບາຍກ່ຽວກັບ Dynamic workflows ວ່າ: "Claude ຈະວາງແຜນການເຮັດວຽກ, ດຳເນີນການ Sub-agent ແບບຂະໜານຫຼາຍຮ້ອຍຕົວພາຍໃນເຊສຊັນດຽວ (ໃນ Opus 4.8 ເອເຈນສາມາດເຮັດວຽກໄດ້ຍາວນານຂຶ້ນ), ພ້ອມທັງກວດສອບຜົນລັອກກ່ອນທີ່ຈະລາຍງານໃຫ້ຜູ້ໃຊ້ຊາບ". ການທີ່ເອເຈນສາມາດຈັດການວຽກໄດ້ຫຼາຍຂຶ້ນໃນຄັ້ງດຽວ ແລະ ມີການກວດສອບຜົນລັອກດ້ວຍຕົນເອງກ່ອນສົ່ງຄືນ—ນີ້ຄືເບື້ອງຫຼັງທາງເຕັກນິກຂອງຍຸກ Mythos / Fable ທີ່ສະໜັບສະໜູນປາກົດການ "ການຍ້າຍແກນຫຼັກ ຫຼື ຈຸດສຳຄັນຂອງການກວດສອບ".

ເມື່ອວຽກງານຕ່າງໆເລີ່ມດຳເນີນໄປຢ່າງເປັນລະບົບ, ເວລາຂອງນັກພັດທະນາຈະປ່ຽນຈາກການແນະນຳວິທີ "ຂຽນລະຫັດເພື່ອຈັດຕັ້ງປະຕິບັດ" ໃນແຕ່ລະຂັ້ນຕອນ ໄປສູ່ການອອກແບບວ່າ "ຈະເຮັດຫຍັງ, ມີຂໍ້ຈຳກັດແນວໃດ, ຈະເຮັດຮອດຂັ້ນໃດ ແລະ ຈະກວດສອບແນວໃດ". ນີ້ຄືການປ່ຽນແປງຈາກຜູ້ສັ່ງການ ໄປສູ່ການເປັນຜູ້ອອກແບບທີ່ຮ່ວມພັດທະນາ.

ໃນເມື່ອກ່ອນ, ການເຮັດວຽກສ່ວນໃຫຍ່ແມ່ນການຄິດຂັ້ນຕອນການປະຕິບັດງານແຕ່ລະຂັ້ນ, ສັ່ງການໃຫ້ Agent, ແລະ ກວດສອບຄວາມແຕກຕ່າງ (diff) ທີ່ສົ່ງກັບຄືນມາ. ແຕ່ໃນປັດຈຸບັນ, ພຽງແຕ່ສົ່ງເງື່ອນໄຂການເຮັດວຽກໃຫ້ສຳເລັດ ແລະ ຂໍ້ຈຳກັດຕ່າງໆໃຫ້, Agent ກໍສາມາດດຳເນີນການໃນຂອບເຂດທີ່ກຳນົດໄວ້ໄດ້ດ້ວຍຕົນເອງ. ເວລາທີ່ເຄີຍໃຊ້ໃນການສັ່ງການແບບຕໍ່ເນື່ອງນັ້ນຫຼຸດລົງຢ່າງເຫັນໄດ້ຊັດ.

ໃນໜ້າວຽກການພັດທະນາຂອງບໍລິສັດພວກເຮົາກໍເຊັ່ນກັນ, ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການກວດສອບ (Review) ກຳລັງປ່ຽນຈາກ "ການຕິດຕາມຄວາມແຕກຕ່າງເທື່ອລະແຖວ" ໄປສູ່ "ການພິຈາລະນາວ່າການປ່ຽນແປງນີ້ເໝາະສົມຫຼືບໍ່ ໂດຍອີງໃສ່ເງື່ອນໄຂການຍອມຮັບ ແລະ ເຈດຕະນາໃນການອອກແບບ". ຄວາມຮູ້ສຶກທີ່ໄດ້ຮັບຄື ນ້ຳໜັກຂອງການຕັ້ງຄຳຖາມວ່າ "ມັນມຸ່ງໄປໃນທິດທາງທີ່ຖືກຕ້ອງຕາມຄວາມຕ້ອງການຫຼືບໍ່" ນັ້ນມີຫຼາຍກວ່າການເບິ່ງຄວາມແຕກຕ່າງຂອງໂຄ້ດໂດຍກົງ. ເມື່ອການສັ່ງການແບບຕໍ່ເນື່ອງຫຼຸດລົງ, ຈຶ່ງເກີດມີພື້ນທີ່ໃຫ້ຄິດວ່າຄວນຈະກວດສອບສິ່ງໃດແດ່.

ເວລາທີ່ເຫຼືອຈາກການໃຫ້ຄຳສັ່ງແບບລຳດັບຈະຖືກນຳໄປໃຊ້ໃນການອອກແບບຂັ້ນຕົ້ນ. ໂດຍສະເພາະແມ່ນການອອກແບບວິທີການກຳນົດຈຸດປະສົງ, ພື້ນຖານຄວາມເປັນມາ, ຂໍ້ຈຳກັດ, ເງື່ອນໄຂການສຳເລັດ, ແລະ ວິທີການກວດສອບ. ໃນແງ່ທີ່ວ່າຄຸນນະພາບຂອງບໍລິບົດທີ່ສົ່ງໃຫ້ Agent ເປັນຕົວຕັດສິນຜົນງານ, ສິ່ງນີ້ຈຶ່ງເປັນເສັ້ນທາງທີ່ຕໍ່ເນື່ອງຈາກ Prompt Engineering ໄປສູ່ Context Engineering.

ບໍ່ພຽງແຕ່ຮູບແບບການເຮັດວຽກຂອງບຸກຄົນເທົ່ານັ້ນ, ການເຄື່ອນໄຫວເພື່ອສ້າງມາດຕະຖານການອອກແບບນີ້ໃນລະດັບທີມກໍມີຄວາມສຳຄັນເຊັ່ນກັນ. ວິທີການທີ່ບໍ່ເຮັດໃຫ້ການຂຽນເງື່ອນໄຂການສຳເລັດ ແລະ ຮູບແບບການກວດສອບກາຍເປັນເລື່ອງສະເພາະບຸກຄົນ, ແຕ່ເປັນການແບ່ງປັນຜ່ານກົນໄກຕ່າງໆ ເຊັ່ນ: CLAUDE.md, Skills, ແລະ Hooks ນັ້ນ ໄດ້ຖືກກ່າວເຖິງໃນ ຄູ່ມືການນຳໃຊ້ Claude Code ສຳລັບທີມ. ການຍ້າຍເວລາໄປໄວ້ທີ່ການອອກແບບ ບໍ່ໄດ້ໝາຍເຖິງການໃຫ້ແຕ່ລະຄົນພະຍາຍາມແກ້ໄຂບັນຫາສະເພາະໜ້າ, ແຕ່ໝາຍເຖິງການເຮັດໃຫ້ວິທີການມອບໝາຍງານ ແລະ ວິທີການກວດສອບກາຍເປັນຊັບສິນຂອງທີມ.

"Fable 5 ຈະຈັດການທຸກຢ່າງໃຫ້ຢ່າງຖືກຕ້ອງເອງ" ນັ້ນເປັນການເຂົ້າໃຈຜິດທີ່ອັນຕະລາຍ. ເຖິງແມ່ນວ່າຄວາມສາມາດຂອງ Model ຈະເພີ່ມຂຶ້ນກໍຕາມ, ແຕ່ນັ້ນບໍ່ໄດ້ໝາຍຄວາມວ່າ "ບໍ່ຈຳເປັນຕ້ອງມີການກຳກັບດູແລ". ກົງກັນຂ້າມ, ໃນການອອກແບບຢ່າງເປັນທາງການ, ການກຳກັບດູແລໂດຍມະນຸດຍັງຄົງເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ.

ຄຳກ່າວອ້າງທີ່ພົບເຫັນໃນ SNS ເຊັ່ນ "ບໍ່ຈຳເປັນຕ້ອງມີຄຳສັ່ງລະອຽດອີກຕໍ່ໄປ" ຫຼື "ປ່ອຍໃຫ້ເປັນໜ້າທີ່ຂອງມັນໄດ້ເລີຍ" ນັ້ນ ຄວນອ່ານໃນຖານະເປັນພຽງການໂຄສະນາປະຊາສຳພັນເທົ່ານັ້ນ. ຄວາມໝາຍທີ່ແທ້ຈິງຂອງການພັດທະນາຄວາມສາມາດ ບໍ່ໄດ້ໝາຍເຖິງ "ການບໍ່ຕ້ອງມີການກຳກັບດູແລ" ແຕ່ໝາຍເຖິງ "ຄວາມສຳຄັນຂອງການອອກແບບຈຸດປະສົງ ແລະ ການອອກແບບການກວດສອບນັ້ນ ເພີ່ມທະວີຂຶ້ນເລື້ອຍໆ".

ເຫດຜົນແມ່ນງ່າຍດາຍ ຄືຫາກເຮົາກຳນົດຈຸດປະສົງທີ່ຜິດພາດ, ເອເຈນ (Agent) ທີ່ຍິ່ງເກັ່ງເທົ່າໃດ ກໍຈະຍິ່ງດຳເນີນການໄປໃນທິດທາງທີ່ຜິດໄດ້ໄວ ແລະ ໝັ້ນໃຈຫຼາຍຂຶ້ນເທົ່ານັ້ນ. ຄວາມຜິດພາດທີ່ອາດຈະສັງເກດເຫັນໄດ້ໃນລະຫວ່າງການເຮັດວຽກດ້ວຍມືນັ້ນ, ເມື່ອເປັນການດຳເນີນການແບບອັດຕະໂນມັດເປັນກຸ່ມກ້ອນ ກໍອາດຈະສົ່ງຜົນກະທົບເປັນວົງກວ້າງໃນເວລາທີ່ເຮົາຮູ້ສຶກຕົວ. ຍິ່ງຄວາມສາມາດສູງຂຶ້ນເທົ່າໃດ, ຈຸດປະສົງໃນຂາເຂົ້າ ແລະ ການກວດສອບໃນຂາອອກ ເຊິ່ງເປັນທັງສອງປາຍທາງທີ່ມະນຸດຕ້ອງເປັນຜູ້ອອກແບບ ກໍຍິ່ງມີຄວາມສຳຄັນຫຼາຍຂຶ້ນເທົ່ານັ້ນ.

ຂໍ້ສົມມຸດຖານນີ້ບໍ່ໄດ້ມາຈາກຄວາມຄິດເຫັນສ່ວນຕົວຂອງນັກພັດທະນາ ແຕ່ໄດ້ຮັບການຢືນຢັນຈາກການອອກແບບຢ່າງເປັນທາງການ. ໜ້າແນະນຳ Claude Code ຂອງ Anthropic (anthropic.com/product/claude-code) ໄດ້ລະບຸຢ່າງຊັດເຈນວ່າ "Human oversight remains central (ການກຳກັບດູແລໂດຍມະນຸດຍັງຄົງເປັນຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ)" ໂດຍອະທິບາຍວ່າລະບົບຈະຂໍອະນຸຍາດກ່ອນການປ່ຽນແປງໄຟລ໌ ຫຼື ການປະຕິບັດຄຳສັ່ງ ແລະ ນັກພັດທະນາຈະເປັນຜູ້ຄວບຄຸມຢ່າງເຕັມທີ່ວ່າຈະ Commit ສິ່ງໃດ.

ກ່າວຄື, ບໍ່ວ່າ Agent ຈະເຮັດວຽກດ້ວຍຕົນເອງໄດ້ຫຼາຍປານໃດກໍຕາມ, ໃນຊ່ວງເວລາທີ່ມີການປ່ຽນແປງຈະຕ້ອງມີການອະນຸມັດຈາກມະນຸດເຂົ້າມາແຊກແຊງ ແລະ ໄດ້ຮັບການອອກແບບມາໃຫ້ມະນຸດເປັນຜູ້ຕັດສິນໃຈໃນຂັ້ນສຸດທ້າຍວ່າຈະສົ່ງມອບສິ່ງໃດອອກໄປ. ການທີ່ມະນຸດເປັນຜູ້ກຳນົດການກວດສອບ "ວຽກງານທີ່ເຮັດນັ້ນຖືກຕ້ອງຫຼືບໍ່" ແລະ ເປັນຜູ້ຕັດສິນໃຈຂັ້ນສຸດທ້າຍນັ້ນ ບໍ່ແມ່ນພຽງແຕ່ການໃສ່ໃຈໃນການດຳເນີນງານເທົ່ານັ້ນ ແຕ່ເປັນວິທີການໃຊ້ງານທີ່ເຄື່ອງມືດັ່ງກ່າວໄດ້ວາງເປັນຂໍ້ສົມມຸດຖານໄວ້.

ໃນການປະຕິບັດງານຈິງ ຈຳເປັນຕ້ອງມີການອອກແບບທີ່ສາມາດເຮັດໃຫ້ "ການມອບໝາຍງານຢ່າງເຕັມທີ່" ແລະ "ການກວດສອບຢ່າງແນ່ນອນ" ດຳເນີນໄປຄຽງຄູ່ກັນໄດ້. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງມັນແມ່ນການກຳນົດ 3 ຢ່າງຄື: ການອອກແບບການປ້ອນຂໍ້ມູນ, ການອອກແບບການກວດສອບ ແລະ ການຕັດສິນໃຈປ່ອຍງານ ໃຫ້ສຳເລັດກ່ອນທີ່ຈະເລີ່ມລົງມືເຮັດວຽກ. ຕໍ່ໄປນີ້ຈະຂໍສະແດງວິທີການສົ່ງມອບງານຢ່າງລະອຽດຕາມລຳດັບ.

ຢ່າງທຳອິດ ແມ່ນການອອກແບບການປ້ອນຂໍ້ມູນ. ໃຫ້ສົ່ງມອບຈຸດປະສົງ, ພື້ນຫຼັງ, ຂໍ້ຈຳກັດ, ແລະ ເງື່ອນໄຂການສຳເລັດໃຫ້ແກ່ Agent ເປັນຊຸດດຽວກັນ. ບໍ່ແມ່ນການສັ່ງງານແບບແຍກສ່ວນເປັນຄັ້ງໆໄປ, ແຕ່ໃຫ້ຄິດເຖິງການໃຫ້ຂໍ້ມູນໃນຄັ້ງດຽວວ່າ "ເຮັດເພື່ອຫຍັງ", "ມີເງື່ອນໄຂເບື້ອງຕົ້ນແນວໃດ", "ຕ້ອງຮັກສາສິ່ງໃດໄວ້", ແລະ "ເຮັດເຖິງຂັ້ນໃດຈຶ່ງຖືວ່າສຳເລັດ".

ຕົວຢ່າງ, ຖ້າໃຊ້ /goal ວິທີການສົ່ງຂໍ້ມູນຈະເປັນດັ່ງນີ້: "ໃຫ້ດຳເນີນການ Implement ມາດຕະຖານ ຫຼື Specification ນີ້ ແລະ ສືບຕໍ່ເຮັດວຽກຈົນກວ່າຈະບັນລຸເງື່ອນໄຂການຍອມຮັບທັງໝົດ. ຢ່າງໃດກໍຕາມ, ຫ້າມເຮັດໃຫ້ຄວາມເຂົ້າກັນໄດ້ຂອງ API ທີ່ມີຢູ່ເດີມເສຍຫາຍ ແລະ ຖ້າຈຳເປັນຕ້ອງມີການປ່ຽນແປງ DB Schema ໃຫ້ສະເໜີແນະກ່ອນລ່ວງໜ້າ". ໃນທີ່ນີ້, "ບໍ່ເຮັດໃຫ້ API ທີ່ມີຢູ່ເດີມເສຍຫາຍ" ແລະ "ການປ່ຽນແປງ Schema ຕ້ອງສະເໜີແນະກ່ອນ" ແມ່ນຂໍ້ຈຳກັດ, ສ່ວນ "ຈົນກວ່າຈະບັນລຸເງື່ອນໄຂການຍອມຮັບ" ແມ່ນເງື່ອນໄຂການສຳເລັດ. ຍິ່ງກຳນົດຂໍ້ຈຳກັດ ແລະ ເງື່ອນໄຂການສຳເລັດໄວ້ຕັ້ງແຕ່ຕົ້ນຫຼາຍເທົ່າໃດ, ການມອບໝາຍວຽກເປັນຊຸດກໍຈະຍິ່ງຫຼຸດຜ່ອນການເຮັດວຽກທີ່ຜິດພາດ ຫຼື ອອກນອກລູ່ທາງໄດ້ຫຼາຍເທົ່ານັ້ນ.

ອັນທີສອງ, ແມ່ນການອອກແບບການກວດສອບ. ໃຫ້ກຳນົດເງື່ອນໄຂການຍອມຮັບ ແລະ ຮູບແບບຂອງບົດລາຍງານທີ່ຕ້ອງການໃຫ້ລາຍງານ ກ່ອນທີ່ຈະເລີ່ມຕົ້ນວຽກງານ. ຕົວຢ່າງເຊັ່ນ: ຖ້າລະບຸວ່າ "ຫຼັງຈາກການປະຕິບັດງານແລ້ວ, ໃຫ້ລາຍງານໄຟລ໌ທີ່ມີການປ່ຽນແປງ, ເນື້ອໃນການປະຕິບັດງານ, ຈຸດທີ່ຍັງບໍ່ໄດ້ແກ້ໄຂ, ຜົນການທົດສອບ ແລະ ຄວາມແຕກຕ່າງຈາກ ມາດຕະຖານ ຫຼື Specification", ມັນຈະເຮັດໃຫ້ການກວດສອບຜົນລວມງ່າຍຂຶ້ນໃນແງ່ຂອງ "ວຽກງານທີ່ຖືກຕ້ອງ".

ກົນໄກທີ່ຕົວແທນ (Agents) ກວດສອບ findings ຂອງກັນແລະກັນ ເຊັ່ນ: Dynamic workflows, ຈະຊ່ວຍເຮັດໃຫ້ການກວດສອບນີ້ເປັນອັດຕະໂນມັດໃນຖານະເປັນຕົວກອງຂັ້ນຕົ້ນ. ຢ່າງໃດກໍຕາມ, ນັ້ນບໍ່ແມ່ນການທົດແທນການກວດສອບໂດຍມະນຸດ, ແຕ່ເປັນການກະກຽມຂັ້ນຕອນກ່ອນໜ້າເພື່ອໃຫ້ມະນຸດສາມາດສຸມໃສ່ການກວດສອບຂັ້ນສຸດທ້າຍໄດ້. ມາດຕະຖານຂອງສິ່ງທີ່ຖືວ່າເປັນ "ວຽກງານທີ່ຖືກຕ້ອງ" ນັ້ນ, ມະນຸດຍັງຄົງຈຳເປັນຕ້ອງເປັນຜູ້ກຳນົດເອງ.

ອັນທີສາມ, ແມ່ນການຕັດສິນໃຈໃນການປ່ອຍສິນຄ້າ (Shipment). ມະນຸດຈະເປັນຜູ້ກວດສອບຄວາມແຕກຕ່າງ, ຜົນການທົດສອບ, ຄວາມແຕກຕ່າງຈາກມາດຕະຖານ ຫຼື Specification, ແລະ ຈຸດທີ່ຍັງບໍ່ທັນໄດ້ຮັບການແກ້ໄຂທີ່ Agent ສົ່ງກັບມາ ເພື່ອຕັດສິນໃຈວ່າຈະປ່ອຍສິນຄ້າຫຼືບໍ່. ດັ່ງທີ່ໄດ້ກ່າວມາຂ້າງຕົ້ນ, ມັນຖືກອອກແບບມາໃຫ້ຜູ້ພັດທະນາເປັນຜູ້ຄວບຄຸມສິ່ງທີ່ຈະ Commit, ສະນັ້ນ ຈຸດກວດສອບສຸດທ້າຍນີ້ຈະບໍ່ຖືກຂ້າມໄປ.

ໂດຍສະເພາະການປ່ຽນແປງທີ່ກ່ຽວຂ້ອງກັບຂົງເຂດທີ່ມີຜົນກະທົບສູງຫາກເກີດຄວາມຜິດພາດ ເຊັ່ນ: ການຢືນຢັນຕົວຕົນ, ສິດທິ, ການແຍກ Tenant, ແລະ ການເກັບເງິນ, ຍິ່ງເປັນສິ່ງທີ່ມອບໝາຍໃຫ້ເຮັດເປັນກຸ່ມກ້ອນຫຼາຍເທົ່າໃດ ກໍຍິ່ງຕ້ອງກວດສອບຢ່າງລະມັດລະວັງຫຼາຍເທົ່ານັ້ນ. ຄຳວ່າ "ການທົດສອບຜ່ານແລ້ວ" ອາດເປັນຫຼັກຖານວ່າ "ການຈັດຕັ້ງປະຕິບັດຖືກຕ້ອງ", ແຕ່ບໍ່ໄດ້ເປັນການພິສູດວ່າ "ກຳລັງເຮັດວຽກທີ່ຖືກຕ້ອງ". ມະນຸດຈະເປັນຜູ້ຕັດສິນໃຈວ່າຈະປ່ອຍອອກໄປ ຫຼື ສົ່ງກັບຄືນ ໂດຍການປຽບທຽບກັບເງື່ອນໄຂການຍອມຮັບ (Acceptance Criteria) ແລະ ເຂົ້າໃຈເຖິງບັນຫາທີ່ຍັງຄົງຄ້າງ — ນີ້ຄືບົດສະຫຼຸບຂອງການອອກແບບວິທີການມອບໝາຍວຽກ.

ຕໍ່ໄປນີ້, ຈະຂໍຕອບ 3 ຂໍ້ສົງໄສທີ່ມັກພົບເຫັນເລື້ອຍໆໃນການເຮັດວຽກຕົວຈິງ ໂດຍເນັ້ນສະເພາະຈຸດສຳຄັນ.

ສະຫຼຸບກໍຄື ເປັນໄປໄດ້ ແລະ ຍິ່ງທີມທີ່ມີຈຳນວນຄົນໜ້ອຍກໍຍິ່ງເຫັນຜົນໄດ້ງ່າຍ. ໃນທີມທີ່ມີບຸກຄະລາກອນໃນການກວດສອບ (Review) ຈຳກັດ, ການອອກແບບເງື່ອນໄຂການສຳເລັດງານໃຫ້ຊັດເຈນ ແລ້ວເອົາກຳລັງຄົນໄປໂຟກັສທີ່ການກວດສອບ ແລະ ການຕັດສິນໃຈຂັ້ນສຸດທ້າຍນັ້ນ ມີຄວາມເປັນຈິງຫຼາຍກວ່າການຕິດຕາມລາຍລະອຽດການປະຕິບັດງານທັງໝົດ.

ຢ່າງໃດກໍຕາມ, ຟີເຈີດັ່ງກ່າວມີເງື່ອນໄຂເບື້ອງຕົ້ນຄື: /goal ຕ້ອງໃຊ້ໃນ Claude Code v2.1.139 ຂຶ້ນໄປ, ສ່ວນ Dynamic workflows ຕ້ອງໃຊ້ໃນ v2.1.154 ຂຶ້ນໄປ ແລະ ຕ້ອງເປັນແພັກເກດແບບເສຍເງິນ (ສຳລັບ Pro ຕ້ອງເປີດໃຊ້ງານຜ່ານ /config), ເຊິ່ງອັນຫຼັງນີ້ຍັງຢູ່ໃນຂັ້ນຕອນຂອງ Research Preview. ເລີ່ມຕົ້ນຈາກການປັບຕົວໃຫ້ຊິນກັບວິທີການເຮັດວຽກໂດຍການສົ່ງເງື່ອນໄຂການສຳເລັດງານຜ່ານ /goal ກ່ອນ, ແລ້ວຈຶ່ງຂະຫຍາຍໄປໃຊ້ Dynamic workflows ຕາມຄວາມຈຳເປັນ ເຊິ່ງເປັນລຳດັບຂັ້ນຕອນທີ່ເໝາະສົມທີ່ສຸດ.

ໂດຍພື້ນຖານແລ້ວ, ຈະຮັບປະກັນດ້ວຍລະບົບການອະນຸຍາດ ແລະ ການອອກແບບສິດທິ. Claude Code ຖືກອອກແບບມາໃຫ້ຮ້ອງຂໍການອະນຸມັດກ່ອນການປ່ຽນແປງໄຟລ໌ ຫຼື ການປະຕິບັດຄຳສັ່ງໂດຍຄ່າເລີ່ມຕົ້ນ, ເຊິ່ງນັກພັດທະນາຈະເປັນຜູ້ຄວບຄຸມສິ່ງທີ່ຈະ Commit. ເຖິງແມ່ນວ່າຄວາມເປັນອິດສະຫຼະຈະເພີ່ມຂຶ້ນ, ແຕ່ປະຕູໃນການກວດສອບຊ່ວງເວລາທີ່ມີການປ່ຽນແປງກໍຍັງຄົງຢູ່.

ນອກຈາກນັ້ນ, ແທນທີ່ຈະໃຫ້ມະນຸດຄອຍເຝົ້າລະວັງໃນທຸກຄັ້ງ, ການສ້າງລະບົບເພື່ອປ້ອງກັນຄວາມຜິດພາດດ້ວຍ "ໂຄງສ້າງ" ເຊັ່ນ: ກົດລະບຽບການອະນຸຍາດ, CI Guard, ແລະ ຂໍ້ກຳນົດຂອງ Repository ຈະຊ່ວຍໃຫ້ມີຄວາມສະຖຽນຫຼາຍຂຶ້ນ. ການອອກແບບ Guardrail ທາງໂຄງສ້າງນີ້ ໄດ້ອະທິບາຍຢ່າງລະອຽດໄວ້ໃນ Harness Engineering.

ຄວນເລີ່ມຕົ້ນຈາກວຽກທີ່ສາມາດຂຽນເງື່ອນໄຂການສຳເລັດໄດ້ຢ່າງຊັດເຈນ ແລະ ມີຜົນກະທົບຈຳກັດໃນກໍລະນີທີ່ເກີດຄວາມຜິດພາດ. ຕົວຢ່າງເຊັ່ນ: ການຂະຫຍາຍການທົດສອບ (Test), ການປັບປຸງໂຄງສ້າງລະຫັດ (Refactoring) ຫຼື ການຍົກຍ້າຍລະບົບແບບປົກກະຕິ ເຊິ່ງເປັນວຽກທີ່ກຳນົດເງື່ອນໄຂການຍອມຮັບ (Acceptance Criteria) ໄດ້ງ່າຍ ແລະ ເໝາະສົມສຳລັບການຝຶກມອບໝາຍວຽກເປັນກຸ່ມ.

ໃນທາງກົງກັນຂ້າມ, ວຽກທີ່ການຕີຄວາມໝາຍຂອງຄວາມຕ້ອງການບໍ່ຊັດເຈນ ຫຼື ວຽກທີ່ຕ້ອງແຕະຕ້ອງເສັ້ນທາງຫຼັກທີ່ມີຄວາມສຳຄັນໃນລະບົບຕົວຈິງ (Production) ຄວນເກັບໄວ້ເຮັດຫຼັງຈາກທີ່ມີຄວາມຊຳນານໃນການມອບໝາຍວຽກແລ້ວ. ສຳລັບເກນການຕັດສິນໃຈວ່າຈະມອບໝາຍວຽກລະດັບໃດໃຫ້ກັບເຄື່ອງມືໃດນັ້ນ, ສາມາດອ້າງອີງຈາກຂໍ້ມູນການທົດສອບຕົວຈິງໃນ ບົດຄວາມປຽບທຽບ Claude Code ແລະ Codex ໄດ້.

Anthropic ໄດ້ ເປີດຕົວ ຫຼື Launch ຄລາສ Claude Mythos ແລະ Fable 5 ເຊິ່ງມີຈຸດເດັ່ນໃນການເຮັດວຽກຂອງ Agent ໃນໄລຍະຍາວ ແລະ ກຳລັງປ່ຽນແປງວິທີການພັດທະນາຢ່າງຕໍ່ເນື່ອງ. ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ຂອງການກວດສອບໂດຍມະນຸດໄດ້ຍ້າຍຈາກ "ການຈັດຕັ້ງປະຕິບັດຢ່າງຖືກຕ້ອງຫຼືບໍ່" ໄປສູ່ "ການເຮັດວຽກທີ່ຖືກຕ້ອງແລ້ວຫຼືບໍ່", ໂດຍມີການຂັບເຄື່ອນເງື່ອນໄຂການສຳເລັດວຽກຜ່ານ /goal, ການກວດສອບເຊິ່ງກັນແລະກັນຂອງ Sub-agent ຜ່ານ Dynamic workflows, ແລະຮູບແບບທີ່ແຂງແກ່ນໃນການເຮັດວຽກໄລຍະຍາວເຊິ່ງລວມເຖິງ Opus 4.8, ທັງໝົດນີ້ແມ່ນປັດໄຈທີ່ຊ່ວຍສະໜັບສະໜູນການປ່ຽນແປງນີ້ທາງດ້ານເຕັກນິກ.

ຢ່າງໃດກໍຕາມ, ຄວາມສາມາດທີ່ເພີ່ມຂຶ້ນບໍ່ໄດ້ໝາຍຄວາມວ່າ "ສາມາດປ່ອຍປະລະເລີຍໄດ້". ເຖິງແມ່ນວ່າໃນການອອກແບບຢ່າງເປັນທາງການ, ການກຳກັບດູແລໂດຍມະນຸດຍັງຖືກວາງໄວ້ເປັນ ຈຸດສຳຄັນ ຫຼື ແກນຫຼັກ ແລະ ມະນຸດຍັງເປັນຜູ້ຕັດສິນໃຈວ່າຈະສົ່ງມອບສິ່ງໃດ. ດັ່ງນັ້ນ, ໃນການປະຕິບັດງານຕົວຈິງ, ການອອກແບບຈຸດປະສົງ, ຂໍ້ຈຳກັດ, ເງື່ອນໄຂການສຳເລັດວຽກ, ແລະ ວິທີການກວດສອບເພື່ອມອບໝາຍວຽກຢ່າງເຕັມທີ່ ພ້ອມທັງຮັກສາສິດໃນການຕັດສິນໃຈຂັ້ນສຸດທ້າຍໂດຍອີງໃສ່ເງື່ອນໄຂການຍອມຮັບ — ນີ້ຄືຫົວໃຈສຳຄັນຂອງການດຸ່ນດ່ຽງທັງສອງດ້ານນີ້.

ບໍລິສັດຂອງພວກເຮົາໃຫ້ການສະໜັບສະໜູນການອອກແບບຂະບວນການພັດທະນາ ແລະ ການເຮັດວຽກໂດຍມີ AIエージェント ເປັນພື້ນຖານ, ລວມເຖິງການຊ່ວຍໃຫ້ທີມງານສາມາດນຳໄປປັບໃຊ້ໃນໜ້າວຽກຈິງໄດ້. ຫາກທ່ານຕ້ອງການອອກແບບຮ່ວມກັບພວກເຮົາວ່າ "ຄວນເລີ່ມມອບໝາຍວຽກໃດ ແລະ ດ້ວຍເງື່ອນໄຂການສຳເລັດວຽກແບບໃດ", ທ່ານສາມາດປຶກສາຫາລືກັບພວກເຮົາໄດ້ຢ່າງເປັນກັນເອງ ພ້ອມກັບການຮຽນຮູ້ພື້ນຖານຂອງ AIエージェント ໄປພ້ອມກັນ.