Claude Code Serye ng Tutorial 4: Ano ang mga Gamit ng Claude Code?

Karaniwang mga Gamit

Hinati ko ang mga gamit sa apat na kategorya, mula sa pinakamadalas hanggang sa hindi gaanong madalas.

Unang Kategorya: Pag-unawa sa Code

Ito marahil ang pinakaginagamit. Kapag kumuha ka ng proyekto ng iba, tumingin sa lumang module, o magbukas ng repository na walang dokumentasyon, tanungin ito nang direkta.

Mga tiyak na paraan:

claude "Ano ang proyektong ito? Saan ang entry point?" — Babasahin nito ang package.json, istraktura ng directory, at mga mahahalagang file, at magbibigay ng buod.
Buksan ang isang function, ipaliwanag ang lohika, gumuhit ng daloy (gamit ang text).
I-trace ang buong path ng isang API request mula frontend hanggang database.

Ang ginagawa nito ay mahalagang "maruming trabaho ng pagbabasa ng code" para sa iyo. Hindi mo na kailangang mag-grep nang matagal at mag-ipon ng puzzle sa isip. Inaayos nito ang path, at ikaw ang magdedesisyon.

Ang kapalit para sa ganitong sitwasyon ay: manu-manong paghahanap sa codebase, pagkuha ng tala, at pagguhit ng call graph.

Ikalawang Kategorya: Pagsulat at Pagbabago ng Code

Ito ang pinakapinag-uusapan, ngunit hindi ito ang pinakamadalas gamitin. Karaniwan, ang pagsulat ng code ay ganito:

Gumawa ng bagong feature: "Magdagdag ng endpoint para baguhin ang email sa user module, dapat i-validate ang format ng email, at sumulat ng unit test."
Refactor sa maraming file: "Palitan lahat ng moment() sa tatlong file na ito ng dayjs(), huwag baguhin ang ibang lohika."
Migration at upgrade: "Gawing Vue 3 Composition API ang component na ito mula sa Vue 2."

Ang code na ginagawa nito ay hindi laging tama sa isang beses, ngunit kayang gawin lahat ng pagbabago sa maraming file nang sabay-sabay, at maaari mong i-diff ang bawat file at tanggapin o tanggihan.

Ang kapalit para sa ganitong sitwasyon ay: manu-manong pagsulat ng repetitive code, manu-manong search at replace ng mga reference sa maraming file.

Ikatlong Kategorya: Pag-debug at Pag-aayos

Kapag may bug, ang karaniwang daloy ay: tingnan ang error, hanapin ang file, hulaan ang dahilan, subukan ayusin, kung hindi gumana bumalik. Direktang matatanggap ng Claude Code ang buong error stack, at gamit ang project code ay mag-locate ito.

Karaniwang gamit:

Ibigay ang output ng failed test, babasahin nito ang kaugnay na code, magmumungkahi ng solusyon, at pagkatapos ay tatakbuhin muli ang test para tingnan kung pumasa.
Kapag may CI error, ilagay ang log, hayaang ayusin, pagkatapos patakbuhin ang git diff para kumpirmahin ang pagbabago.

Ang papel nito dito ay parang "unang tagapagsiyasat". Ikaw ang gumugugol ng oras para mag-isip, ngunit ito ang naghahanap ng file, nagkumpara ng pagkakaiba, at nagpapatakbo ng verification commands.

Ang kapalit para sa ganitong sitwasyon ay: paulit-ulit na pagpapatakbo ng tests, pagbabasa ng error logs, manu-manong paghahambing ng code differences.

Ikaapat na Kategorya: Iba't Ibang Automation

Ang kategoryang ito ay hindi gaanong kapansin-pansin, ngunit pinakamadaming nasasave na oras kapag pinagsama-sama.

Mga halimbawa:

Sumulat ng Git commit message: claude "Gumawa ng commit message sa Conventional Commits format batay sa kasalukuyang git diff"
Gumawa ng PR description: Ipagawa sa Claude Code na ikumpara ang pagkakaiba ng kasalukuyang branch at main, at gumawa ng buod ng pagbabago at test notes.
Sumulat ng release notes: Payagan ang Claude Code na basahin ang commit history ng nakaraang linggo at gumawa ng CHANGELOG.
Sagutin ang environmental issues: "Nag-error sa pag-install ng dependency na ito, tulungan akong suriin ang terminal output at hanapin ang dahilan."

Ang pagkakatulad ng mga ito: hindi kumplikado ngunit nakakapagod. Kapag ginawa mo mismo, kailangan mong lumipat ng window at mag-type ng marami. Ibigay mo rito, ilang segundo lang tapos na.

Ang kapalit para sa ganitong sitwasyon ay: manu-manong pag-edit ng text, pagsulat ng standardized na dokumentasyon, paghahanap ng configuration ng environment.

Isang "Mapa"

Kung ilalagay ang apat na kategoryang ito sa pang-araw-araw na workflow, ganito ang mapa:

Kumuha ng hindi pamilyar na proyekto
    │
    ▼
[Pag-unawa sa Code] ─── Alamin ang istraktura, entry point, at mahahalagang lohika
    │
    ▼
Simulan ang pagsulat ng bagong feature o pagbabago ng module
    │
    ▼
[Pagsulat/Pagbabago ng Code] ─── Gumawa ng implementasyon, refactor sa maraming file
    │
    ▼
Patakbuhin ang tests, may bug
    │
    ▼
[Pag-debug at Pag-aayos] ─── Suriin ang error, i-locate, ayusin, patakbuhin muli
    │
    ▼
Maghanda para mag-commit
    │
    ▼
[Iba't Ibang Automation] ─── Sumulat ng commit, PR description, release notes
    │
    ▼
Mag-commit, tapos

Hindi mo kailangang gamitin ito sa lahat ng apat. May team na ginagamit lang para maintindihan ang code, may iba naman para sumulat ng tests at mag-release ng PR. Aling bahagi ang pinakamahirap para sa iyo, doon ka magsimula.

Dalawang Pamantayan na Maaaring Gamitin

Kung hindi ka sigurado kung dapat mong ipagawa sa Claude Code ang isang bagay, tanungin ang iyong sarili ng dalawang tanong:

1. Ito ba ay "mekanikal" kaysa "malikhain"?

Ang pagbabago ng isang daang reference, pag-format ng output, paggawa ng boilerplate code — ang mga ito ay magtatagal kung gagawin mo nang manu-mano, ngunit nasa isip mo na ang paraan. Tamang ipagawa ito rito.

2. Mataas ba ang "cost of verification" ng gawaing ito?

Kung ang isang pagbabago ay nangangailangan ng paulit-ulit na paglipat, pagtakbo ng tests, at pagtingin ng logs para makumpirma, ang personal na pagsubok ay mabagal. Kayang gawin ng Claude Code ang loop na "baguhin-takbo-tingnan-baguhin muli" nang mag-isa, at mas magiging madali para sa iyo.