មគ្គុទេសក៍របៀបប្រើប្រាស់ Claude Code ពេញលេញ៖ ចាប់ពីការដំឡើង រហូតដល់ការឱ្យ AI រត់មុខងារមួយដោយខ្លួនឯង

ម៉ោង ១១ យប់ ក្នុង משרד (Office) סטארតអាប់ (Startup) មួយនៅតំបន់ Nei Hu មានមនុស្សតែពីរនាក់ប៉ុណ្ណោះ។ វិស្វករម្នាក់បានទទួលការងារបន្ទាន់មួយ គឺត្រូវជួសជុលកំហុស (Bug) មុនពេលដាក់ដំណើរការនៅថ្ងៃស្អែក ប៉ុន្តែបញ្ហានេះកើតឡើងនៅលើម៉ូឌុល (Module) ដែលសរសេរដោយសហការីម្នាក់ដែលបានลาចេញតាំងពីបីឆ្នាំមុន ដោយគ្មានកំណត់ចំណាំ (No Comments) និងគ្មានតេស្ត (No Tests)។ គាត់បានវាយបញ្ចូលតម្រូវការចូលទៅក្នុង Terminal ហើយងើបទៅឆንកាហ្វេ (Coffee)។ ពេលគាត់ត្រឡប់មកវិញ នៅលើអេក្រង់បានបង្ហាញឯកសារពាក់ព័ន្ធចំនួនប្រាំរួចជាស្រេច បានចង្អុលបង្ហាញពីមូលហេតុដែលអាចកើតមាន ព្រមទាំងបានកែសម្រួលកន្លែងមួយ និងបានរត់តេស្តរួចរាល់ទៀតផង។

នេះមិនមែនជាឈុតផ្សាយពាណិជ្ជកម្មទេ ប៉ុន្តែវាជាការប្រើប្រាស់ប្រចាំថ្ងៃរបស់ Claude Code នាពេលបច្ចុប្បន្ន។ ប៉ុន្តែ ακριβώς ព្រោះតែវាអាចចូលរួមកែសម្រួលកូដរបស់អ្នកពិតប្រាកដ តម្លៃនៃការប្រើប្រាស់ខុសគឺខ្ពស់ជាងឧបករណ៍ AI ធម្មតាឆ្ងាយណាស់។ អត្ថបទនេះបានចងក្រងពីដំណើរការជាក់ស្តែងដែលខ្ញុំធ្លាប់ប្រើប្រាស់ រួមទាំងចំណុចខ្សោយមួយចំនួនដែលខ្ញុំធ្លាប់ជួបប្រទះផ្ទាល់ផងដែរ។

នេះជាអ្វី៖ ជា Agent មិនមែនគ្រាន់តែជា Auto-complete នោះទេ

សូមបញ្ជាក់ពីនិយមន័យឱ្យបានច្បាស់លាស់ជាមុនសិន ព្រោះវាជាកត្តាកំណត់ពីរបៀបที่คุณត្រូវប្រើប្រាស់វា។

ឧបករណ៍សរសេរកូដ AI ដែលភាគច្រើនធ្លាប់ស្គាល់ គឺប្រភេទ «បំពេញបន្ថែម (Auto-complete)»៖ អ្នកវាយអក្សរ វាទាយបន្ទាត់បន្ទាប់ ហើយចុច Tab ដើម្បីយល់ព្រម。GitHub Copilot គឺស្ថិតក្នុងទម្រង់បែបនេះនៅដំណាក់កាលដំបូង ដោយអ្នកត្រូវចាំមើលវាគ្រប់ជំហាន ដើម្បីជួយសន្សំសំចៃពេលវេលាវាយអក្សររបស់អ្នក។

ចំណែកឯ Claude Code គឺជា «ប្រភេទភ្នាក់ងារ (Agentic)»។ អ្នកផ្តល់គោលដៅមួយ—ដូចជា ជួសជុល bug នេះ ឬបន្ថែមមុខងារ Pagination លើ API នេះ—វាជាអ្នកសម្រេចចិត្តដោយខ្លួនឯងថាត្រូវអានឯកសារណាខ្លះ រត់បញ្ជា (Commands) អ្វីខ្លះ និងត្រូវដោះស្រាយយ៉ាងដូចម្តេចពេលតេស្តបរាជ័យ រហូតដល់ចប់រង្វិលជុំ (Cycle) ទាំងអស់ ហើយអ្នកមានหน้าที่ត្រួតពិនិត្យ និងទទួលយកលទ្ធផល (Review)។

អត្ថន័យជាក់ស្តែងគឺ៖ តួនាទីរបស់អ្នកបានប្តូរពី «អ្នកវាយអក្សរ» ទៅជា «អ្នកពិនិត្យផ្ទៀងផ្ទាត់» វិញ។ ពេលវេលាដែលសន្សំសំចៃបាន មិនមែនជាពេលវាយអក្សរទេ ប៉ុន្តែគឺជាពេលវេលាស្វែងយល់ពីកូដដែលមិនស្គាល់ និងការសាកល្បងខុសត្រូវ (Trial and Error)។ ចំណែកឯអ្នកដែលខ្វះសមត្ថភាពក្នុងការពិនិត្យផ្ទៀងផ្ទាត់ ការប្រើប្រាស់ឧបករណ៍នេះនឹងកាន់តែមានគ្រោះថ្នាក់ទៅវិញទេ។

អាចប្រើប្រាស់បាននៅឯណា

ចំណុចប្រទាក់បច្ចុប្បន្នមានច្រើនជាងអ្វីដែលមនុស្សភាគច្រើនគິດ៖

• Terminal CLI៖ មានមុខងារពេញលេញបំផុត ដោយពាក្យបញ្ជាដំឡើងគឺ curl -fsSL https://claude.ai/install.sh | bash
• កម្មវិធីលើកុំព្យូទ័រ (Desktop)៖ មានសម្រាប់ macOS, Linux និង Windows
• ជំនាន់រុករកតាមអ៊ីនធឺណិត (Browser)៖ claude.ai/code មិនបាច់ដំឡើងអ្វីទាំងអស់
• Plugins សម្រាប់ IDE៖ VS Code និង JetBrains
• ទូរស័ព្ទដៃ៖ កម្មវិធី (App) ទាំង iOS និង Android
• Slack Bot៖ បើកកិច្ចការដោយផ្ទាល់នៅក្នុងការជជែក (Chat)
• GitHub Actions៖ ធ្វើការពិនិត្យ PR ដោយស្វ័យប្រវត្តិ

សម្រាប់ខ្ញុំផ្ទាល់ គឺប្រើ CLI ជាចម្បង និងប្រើទូរស័ព្ទដៃដើម្បីតាមដានវឌ្ឍនភាព។ គុណសម្បត្តិរបស់ CLI គឺវាស្ថិតនៅក្នុងថតរចនាសម្ព័ន្ធប្រព័ន្ធ (Project Directory) ផ្ទាល់តែម្តង ដែលធ្វើឱ្យអុិនវីរុនមេន (Environment Variables) ស្ថានភាព git និងពាក្យបញ្ជាតេស្តមានរួចជាស្រេច។

វិធីប្រើប្រាស់៖ ជំហានទាំងបួន

ជំហានទី១៖ ដំឡើង និងចាប់ផ្តើមនៅក្នុងថតរចនាសម្ព័ន្ធប្រព័ន្ធ (Project Directory)

បន្ទាប់ពីដំឡើងរួច ត្រូវតែ cd ចូលទៅកាន់ថតមេរបស់ប្រព័ន្ធ (Project Root Directory) ជាមុនសិន មុនពេលចាប់ផ្តើម។ មនុស្សជាច្រើនมักจะចាប់ផ្តើមវានៅក្នុងថតផ្ទាល់ខ្លួន (Home Directory) ដែលធ្វើឱ្យវាមិនអាចមើលឃើញរចនាសម្ព័ន្ធប្រព័ន្ធ ហើយអាចត្រឹមតែស្មានខុសប៉ុណ្ណោះ។ ការចាប់ផ្តើមលើកដំបូងនឹងតម្រូវឱ្យមានការចូលគណនី (Login) ប្រសិនបើអ្នកមានការជាវ (Subscription) របស់ Claude អ្នកអាចភ្ជាប់វាបានភ្លាមៗ ឬបើប្រើ API Key គឺគិតប្រាក់តាម Token។

ជំហានទី២៖ ឱ្យវាអាននិងយល់ពីប្រព័ន្ធជាមុនសិន សឹមបញ្ជាឱ្យវាធ្វើការ

កំហុសដែលអ្នកទើបចេះប្រើតែងតែធ្វើគឺ ការដាក់តម្រូវការភ្លាមៗពេលចូលដល់។ ប្រយោគដំបូងที่ดีជាងគឺ៖

សូមមើលរចនាសម្ព័ន្ធនៃប្រព័ន្ធនេះជាមុនសិន ហើយប្រាប់ខ្ញុំពីបច្ចេកវិទ្យា (Tech Stack) ការបែងចែកម៉ូឌុលหลัก និងវិធីរត់តេស្ត។ កុំទាន់កែប្រែអ្វីទាំងអស់។

ប្រយោគ «កុំទាន់កែប្រែអ្វីទាំងអស់» គឺមានសារៈសំខាន់ណាស់ ព្រោះវាមានទម្លាប់សកម្មខ្លាំង ប្រសិនបើអ្នកមិនហាមឃាត់វាទេ វាអាចនឹងลงมือធ្វើការបាត់ទៅហើយ។ បន្ទាប់ពីផ្ទៀងផ្ទាត់ថាវាមិនយល់ច្រឡំទេ សឹមឈានដល់ជំហានបន្ទាប់។

ជំហានទី៣៖ សរសេរឯកសារ CLAUDE.md ដែលជាជំហានសំខាន់បំផុតនៃឧបករណ៍នេះ

ដាក់ឯកសារ CLAUDE.md មួយនៅថតមេរបស់ប្រព័ន្ធ (Project Root Directory) ដែលក្នុងនោះសរសេរអំពីច្បាប់របស់ប្រព័ន្ធ។ រាល់ពេលដែលវាចាប់ផ្តើមដំណើរការ វានឹងអានឯកសារនេះ។ គុណភាពនៃឯកសារនេះ គឺជាកត្តាកំណត់ដោយផ្ទាល់ថា តើអ្នកនឹងប្រើប្រាស់វាដោយរលូន ឬមួយក៏ខឹងសម្បាប៉ុណ្ណោះ។

អ្វីដែលគួរតែសរសេរជាក់ស្តែង៖

ទំនៀមទម្លាប់របស់ប្រព័ន្ធ (Project Conventions)

• Frontend ប្រើ TypeScript + React, Backend ប្រើ Node.js
• តេស្តប្រើ vitest កម្មវិធីរត់គឺ npm run test
• សារ Commit ប្រើភាសាអង់គ្លេស ឬចិន (អាស្រ័យលើក្រុម) ទម្រង់៖ type: description

ការកំណត់កម្រិតតឹងរឹង (Important Constraints)

• ធ្វើតែកិច្ចការដែលខ្ញុំបានស្នើសុំយ៉ាងច្បាស់លាស់ប៉ុណ្ណោះ។ កុំបន្តកែសម្រួលរចនាសម្ព័ន្ធឡើងវិញ (Refactor) ដោយស្វ័យប្រវត្តិ និងកុំបន្ថែមស្រទាប់អរូបី (Abstraction Layers) ដែលមិនត្រូវបានស្នើសុំ។
• កុំបន្ថែមបណ្ណាល័យភាគីទីបី (Third-party Packages) បន្ថែម បើចាំបាច់ត្រូវសួរខ្ញុំជាមុនសិន។
• កូដក្រោម src/legacy/ មិនត្រូវប៉ះពាល់ឡើយ ព្រោះវាជាប្រព័ន្ធចាស់ដែលត្រៀមនឹងត្រូវជំនួស។
• បន្ទាប់ពីកែសម្រួលរួច ត្រូវតែរត់ npm run test ជាដាច់ខាត បើតេស្តមិនឆ្លងកាត់ទេ កុំប្រាប់ថាបានធ្វើរួចរាល់។

ចំណុច «ធ្វើតែកិច្ចការដែលខ្ញុំបានស្នើសុំយ៉ាងច្បាស់លាស់ប៉ុណ្ណោះ» ខ្ញុំគត់សំគាល់ថាជាច្បាប់ដែលគួរតែសរសេរជាងគេក្នុងចំណោមច្បាប់ទាំងអស់។ នៅពេលដែលអ្នកប្រាប់វាឱ្យជួសជុល bug មួយ វាអាចនឹងឆ្លៀតពេលកែសម្រួល file បីផ្សេងទៀត បន្ថែមការគ្រប់គ្រងកំហុស (Error Handling) និងបន្ថែម Types ទៀតផង។ បើមើលដាច់ដោយឡែកពីគ្នា គឺគ្មានអ្វីខុសទេ ប៉ុន្តែការពិនិត្យកូដរបស់អ្នក (Code Review) នឹងក្លាយជាគ្រោះមហន្តរាយ ហើយអ្នកមិនអាចញែកដាច់ពីគ្នាបានទេថា អ្វីខ្លះជាកិច្ចការចាំបាច់ដើម្បីជួសជុល bug ហើយអ្វីខ្លះដែលវាបន្ថែមតាមអំពើចិត្ត។

ជំហានទី៤៖ ដាក់ចេញកិច្ចការ ហើយធ្វើការផ្ទៀងផ្ទាត់ (Acceptance)

ការពិពណ៌នាអំពីកិច្ចការកាន់តែជាក់ស្តែង កាន់តែดี។ ឧទាហរណ៍នៃការសួរមិនល្អ និងការសួរល្អ៖

• ❌ «ជួយខ្ញុំធ្វើឱ្យកូដនេះប្រសើរឡើង (Optimize) បន្តិច»——វាប្រហែលជាមិនដឹងថាអ្នកចង់ optimize អ្វីទេ វាអាចកែប្រែផ្នែកល្បឿនលឿន (Performance) ឬផ្នែកភាពងាយស្រួលក្នុងការអាន (Readability)។
• ✅ «មុខងារនេះនឹងយឺតខ្លាំង (Timeout) នៅពេលបរិមាណទិន្នន័យលើសពីមួយម៉ឺនកំណត់ត្រា សូមរកមើលចំណុចស្ទះ (Bottleneck) និងជួសជុលវា កុំផ្លាស់ប្តូរចំណុចប្រទាក់ខាងក្រៅរបស់វា (External Interface) ហើយក្រោយពេលកែរួច ត្រូវរត់តេស្ត»

វិធីសាស្ត្រទីពីរផ្តល់នូវគោលដៅ ការកំណត់កម្រិត និងស្តង់ដារនៃការផ្ទៀងផ្ទាត់ដល់វា។

បច្ចេកទេសកម្រិតខ្ពស់

ប្រើ /clear ដើម្បីកាត់ផ្តាច់បរិបទ (Context)។ ប្រសិនបើអ្នកប្តូរភារកិច្ច ប៉ុន្តែមិនបានសម្អាតវាទេ បរិបទនៃភារកិច្ចមុននឹងរំខានដល់ការវិនិច្ឆ័យ។ ភារកិច្ចមួយ គឺត្រូវមានការជជែកគ្នាស្អាតដាច់ដោយឡែកពីគ្នា។

ចេះប្រើទម្រង់ផែនការ (Plan Mode)។ នៅពេលជួបប្រទះការកែប្រែទ្រង់ទ្រាយធំ ត្រូវឱ្យវា «ស្នើតែផែនការជាមុនសិន មិនត្រូវធ្វើការកែសម្រួល»។ បន្ទាប់ពីពិនិត្យនិងអនុម័តរួច សឹមអនុញ្ញាតឱ្យវាធ្វើការ ដែលវាមានភាពងាយស្រួលជាងការកែរួចហើយត្រូវថយក្រោយ (Rollback) ឆ្ងាយណាស់។

ឱ្យវាអានសារកំហុស (Error Messages) ដោយខ្លួនឯង។ អ្នកមិនចាំបាច់ចម្លងនិងបិទភ្ជាប់កំហុសនោះទេ គ្រាន់តែបញ្ជាឱ្យវាសាកល្បងរត់តេស្ត វា會អានលទ្ធផល និងធ្វើការជួសជុលដោយខ្លួនឯង។

ការគ្រប់គ្រងកូតា (Quota Management)។ គម្រោង Pro (ប្រហែល ១៧-២០ ដុល្លារក្នុងមួយខែ) ការរត់ Refactor ខ្នាតធំអាចប្រើប្រាស់កូតាអស់ក្នុងរយៈពេលត្រឹមតែប៉ុន្មានម៉ោងប៉ុណ្ណោះ។ អ្នកដែលប្រើប្រាស់យ៉ាងយកចិត្តទុកដាក់ភាគច្រើនត្រូវដំឡើងកម្រិតទៅ Max 5x (១០០ ដុល្លារ) ឬ Max 20x (២០០ ដុល្លារ)។ វាត្រូវបានណែនាំឱ្យប្រើ Pro ក្នុងរយៈពេលមួយខែជាមុនសិន ដើម្បីកត់ត្រាប្រេកង់នៃការប៉ះពាល់ដែនកំណត់ មុនពេលសម្រេចចិត្ត។

កិច្ចការដែលត្រូវយកចិត្តទុកដាក់

វានឹងបង្កើតកូដដែលមើលទៅហាក់ដូចជាត្រឹមត្រូវ ប៉ុន្តែការពិតគឺខុស។ អ្វីដែលវាសរសេរគឺមានវេយ្យាករណ៍ត្រឹមត្រូវ រចនាប័ទ្មស្របគ្នា និងមានលក្ខណៈអាជីព ប៉ុន្តែតក្កវិជ្ជា (Logic) អាចនឹងខុស ជាពិសេសលើបញ្ហាករណីអម (Edge Cases) និងបញ្ហាស្របពេលគ្នា (Concurrency)។ អ្នកត្រូវតែមានសមត្ថភាពពិនិត្យមើលលទ្ធផលរបស់វា នេះមិនមែនជាជម្រើសទេ។

ត្រូវបញ្ជាក់ឱ្យច្បាស់អំពីបញ្ហាការលេចធ្លាយទិន្នន័យ (Data Leakage)។ កូដនឹងត្រូវបញ្ជូនទៅកាន់ Cloud Model។ សម្រាប់ប្រព័ន្ធហិរញ្ញវត្ថុ វេជ្ជសាស្ត្រ និងគម្រោងដែលមានកិច្ចសន្យារັກ្សាការងាករ (NDA) ត្រូវតែធានាថានយោបាយ និងលក្ខខណ្ឌកិច្ចសន្យារបស់ក្រុមហ៊ុនត្រូវបានបំពេញមុនពេលដាក់បញ្ចូល—ក្រុមការងារជាច្រើនបានប្រើវាជាមុនសិន សឹមនឹកឃើញនៅពេលក្រោយ ដែលធ្វើឱ្យលំដាប់លំដោយខុសប្រក្រតី។

កុំឱ្យវាប៉ះពាល់ដល់ការផ្ទេរទិន្នន័យ (Database Migration) និងការដាក់ឱ្យដំណើរការលើប្រព័ន្ធពិត (Production Deployment)។ ប្រតិបត្តិការប្រភេទនេះមិនអាចត្រឡប់វិញបានទេ (Irreversible) ហើយតម្លៃនៃការខុសឆ្គងគឺខ្ពស់ជាងពេលវេលាដែលបានសន្សំសំចៃឆ្ងាយណាស់។ គោលការណ៍របស់ខ្ញុំគឺ៖ រឿងណាដែលអាចត្រឡប់វិញបាន គឺปล่อยໃຫ້វាធ្វើដោយសេរី រឿងណាដែលមិនអាចត្រឡប់វិញបាន គឺត្រូវធ្វើដោយខ្លួនឯង។

កុំរំពឹងថាវាจะជំនួសការគិតគូរពីស្ថាបត្យកម្មរបស់អ្នក។ វាពូកែខាងប្រតិបត្តិការណាស់ ប៉ុន្តែការសម្រេចចិត្តដូចជា «តើមុខងារនេះគួរធ្វើឬទេ តើគួរពុះចែកជាសេវាកម្ម (Services) ដែរឬទេ តើគួររចនាម៉ូដែលទិន្នន័យ (Data Model) យ៉ាងដូចម្តេច» នៅតែជាការងាររបស់អ្នកដដែល។ ប្រសិនបើអ្នកចង់ប្រៀបធៀបឆ្លងគ្នា អ្នកអាចប្រើប្រាស់ដំណោះស្រាយរួមបញ្ចូលគ្នាជាមួយកម្មវិធីកែសម្រួលដូចជា Cursor ។

រំលែកដំណើរការការងារដែលត្រូវគ្នា

ចង្វាក់ការងាររបស់ខ្ញុំគឺ៖ នៅពេលព្រឹក ខ្ញុំដាក់កិច្ចការដែលមានវិសាលភាពច្បាស់លាស់ឱ្យវាធ្វើ ហើយខ្ញុំផ្ទាល់ដោះស្រាយផ្នែកដែលទាមទារការវិនិច្ឆ័យ ដល់ពេលរសៀលទើបធ្វើការពិនិត្យរួម (Review diff) របស់វា។ វិធីសាស្ត្របន្ថែមទៀតក្នុងការបញ្ចូល AI ទៅក្នុងការងារប្រចាំថ្ងៃ អាចមើលបាននៅ មគ្គុទេសក៍ភារកិច្ច AI ឬ បណ្ណាល័យគំរូ Prompts។

មតិយោបល់ពី TheAI學院

និយាយតាមត្រង់ ខ្ញុំតែងតែមានប្រតិកម្មមិនល្អចំពោះពាក្យថា «AI ជំនួសវិស្វករ» ប៉ុន្តែបន្ទាប់ពីប្រើវាបាន কয়েকខែ ខ្ញុំត្រូវតែសារភាពថា មាតិកាការងាររបស់វិស្វករពិតជាមានការផ្លាស់ប្តូរមែន។ អ្វីដែលបានផ្លាស់ប្តូរ មិនមែនជា «តើនៅតែត្រូវការវិស្វករដែរឬទេ» នោះទេ ប៉ុន្តែជា តម្លៃដែលបានប្តូរពី «ការសរសេរចេញមក» ទៅជា «ការវិនិច្ឆ័យថាតើសរសេរបានត្រឹមត្រូវឬអត់» វិញ។

មតិយោបល់៖ Claude Code គឺជាភ្នាក់ងារសរសេរកូដ AI ដែលមានភាពពេញវ័យបំផុតនាពេលបច្ចុប្បន្ន ប៉ុន្តែអ្វីដែលវាពង្រីកកាន់តែខ្លាំងគឺ ការវិនិច្ឆ័យដែលមានស្រាប់របស់អ្នក—អ្នកដែលមានការវិនិច្ឆ័យខ្លាំង ផលិតភាពនឹងកើនឡើងទ្វេដង អ្នកដែលមានការវិនិច្ឆ័យខ្សោយ គឺគ្រាន់តែបង្កើតបំណុលបច្ចេកវិទ្យាកាន់តែលឿនប៉ុណ្ណោះ។

សំណជាក់ស្តែងសម្រាប់អ្នកអាន៖ វិស្វករដែលមានបទពិសោធន៍ចាប់ពីបីឆ្នាំឡើងទៅ គួរតែដាក់វាចូលទៅក្នុងដំណើរការការងារឥឡូវនេះ ដោយចាប់ផ្តើមពី «ការសរសេរ