Babala ng Sysls: Ang pag-overload sa Claude at Codex ng konteksto ay maaaring magbawas sa performance

May-akda: sysls

Isinalin: Deep潮 TechFlow

DeepTide Summary: Ang developer blogger na may 2.6 milyong follower, sysls, ay sumulat ng isang mahabang artikulong may 827 na pagbabahagi at 7,000 na paborito, na naglalaman lamang ng isang pangunahing pahayag: Ang mga plugin, memory system, at iba pang harness mo ay malamang ay nagpapahirap sa iyo. Hindi ito artikulong nagtuturo ng malalaking prinsipyo, kundi isang koleksyon ng praktikal na prinsipyo mula sa totoong production projects—mula sa pagkontrol sa konteksto, pagharap sa pagiging mapagpuri ng AI, hanggang sa pagtukoy ng mga kondisyon para sa pagtatapos ng task. Ito ang pinakamalinaw na artikulong nakikita ko tungkol sa praktikal na paggamit ng Claude/Codex.

Ang buong teksto ay sumusunod:

Ikaw ay isang developer na gumagamit ng Claude at Codex CLI araw-araw, at araw-araw kang nag-iisip kung talagang pinaglalabanan mo ang kanilang kakayahan. Minsan, nakikita mo ang mga bulag na gawa nito, at hindi mo maintindihan kung bakit may ilan na nagtatayo ng rocket gamit ang AI, habang ikaw ay hindi kayang i-stack ang dalawang bato.

Isipin mo na problema ang iyong harness, plugin, terminal, atbp. Gamit mo ang beads, opencode, zep, at 26,000 na linya ang sinulat mo sa CLAUDE.md. Pero anuman ang gawin mo, hindi mo pa rin maintindihan kung bakit mas malayo ka na sa langit, habang ang iba ay naglalaro kasama ang mga anghel.

Ito ang artikulong inaasam-asam mo.

Bukod dito, walang interes akong may-ari. Sinasabi ko na ang CLAUDE.md ay kasama ang AGENT.md, at sinasabi ko na ang Claude ay kasama ang Codex, at ginagamit ko ang pareho nang malaki.

Sa mga nakalipas na buwan, nakita ko ang isang interesanteng bagay: halos walang tunay na nakakaalam kung paano maksimahin ang kakayahan ng isang agent.

Parang may maliit na grupo lang ang makakapagbuo ng buong mundo, habang ang iba ay naglalakbay sa gitna ng isang malaking dagat ng mga kasangkapan, na nagdudulot ng choice paralysis—naniwala na ang paghahanap ng tamang package, kasanayan, o harness组合 ay magpapabukas ng AGI.

Ngayon, gusto kong putulin ang lahat ng ito at ibigay sa inyo ang isang simpleng, tapat na mensahe, at mula doon tayo magmula. Hindi mo kailangan ng pinakabagong proxy harness, hindi mo kailangan ng isang milyon na package, at hindi mo kailangan ng isang milyon na artikulo para manatiling kompetitibo. Sa katotohanan, malamang na mas masama pa ang iyong pagmamahal kaysa magandang epekto nito.

Hindi ako dito para mag-tour—simula nang maaaring mag-code ang agent, gamit ko na ito. Subukan ko lahat ng package, lahat ng harness, lahat ng paradigm. Gumawa ako ng signals, infrastructure, at data pipelines gamit ang agent factory, hindi 'toy projects', kundi totoong use cases na tumatakbo sa production environment. Pagkatapos gawin lahat ng ito...

Ngayon, ginamit ko ang isang configuration na halos pinakasimple na posible, na naglalaman lamang ng pangunahing CLI (Claude Code at Codex), kasama ang pag-unawa sa ilang pangunahing prinsipyo ng proxy engineering, at nagawa ko ang aking pinakamalaking pagbobroke hanggang sa ngayon.

Una sa una, gusto kong sabihin na ang mga kumpanya ng base model ay nasa gitna ng isang makabagong sprint, at malinaw na hindi ito mabilis na magpapahinga. Bawat pagpapabuti sa "agent intelligence" ay magbabago ng paraan kung paano mo ito iuugnay sa pagtatrabaho, dahil ang mga agent ay dinisenyo upang maging mas handang sumunod sa mga utos.

Sa ilang mga henerasyon na ang nakalipas, kung isusulat mo sa CLAUDE.md ang “Basahin muna ang READTHISBEFOREDOINGANYTHING.md bago gawin ang anumang bagay,” may 50% na posibilidad na sasabihin nito sa iyo ang “Pukol ka,” tapos gagawin nito ang nais niyang gawin. Ngayon, sumusunod ito sa karamihan sa mga utos, kahit anong komplikadong nested commands—tulad ng maaari mong sabihin, “Basahin muna ang A, pagkatapos ay basahin ang B, at kung C, basahin ang D”—at sa karamihan ng mga pagkakataon, masayang sumusunod ito.

Ano ang ipinapahiwatig nito? Ang pinakamahalagang prinsipyo ay ang pagkilala: bawat bagong henerasyon ng agent ay nagpapakailangan sa iyo na muli nang isipin kung ano ang pinakamahusay na solusyon, at dito nakabatay ang prinsipyo na mas kaunti ay mas marami.

Kapag gumagamit ka ng maraming iba’t ibang library at harness, ipinapakulong mo ang sarili mo sa isang “solusyon,” ngunit maaaring hindi umiiral ang problema na ito sa harap ng susunod na henerasyon ng agent. Alam mo sino ang pinakamalikhaing at pinakamaraming gumagamit ng agent? Tama—ang mga empleyado ng mga nangungunang kumpanya, na may walang hanggang budget para sa token at gumagamit ng tunay na pinakabagong model. Naiintindihan mo kung ano ang ibig sabihin nito?

Ibig sabihin nito, kung may totoong problema at may mabuting solusyon, ang mga kumpanya sa harap ay magiging pinakamalaking gumagamit ng solusyon na iyon. At ano ang gagawin nila pagkatapos? Isasama nila ang solusyon na iyon sa kanilang sariling produkto. Isipin mo, bakit pipiliin ng isang kumpanya na payagan ang isang ibang produkto na lutasin ang totoong problema at gumawa ng panlabas na pagkakasalalay? Paano ko alam na totoo ito? Tignan mo ang mga kasanayan, memory harness, sub-agents... lahat ng ito ay nagsimula bilang mga "solusyon" sa totoong problema, at pinatunayan na talagang kapaki-pakinabang sa praktikal na paggamit.

Kaya kung may isang bagay na talagang nakabubukas ng daan at nakakapalawig ng mga paggamit ng agent sa mayamang paraan, ito ay maaaring ma-integrate sa pangunahing produkto ng kompanya sa isang pagkakataon. Paniniwalaan mo ako, ang pangunahing kompanya ay naghahalos nang mabilis. Kaya mag-relax ka, hindi mo kailangang i-install ang anumang bagay o mag-asa sa anumang panlabas na pagkakasunod-sunod upang gawin ang pinakamahusay na trabaho.

Nag-aasahan akong mabilis na lalabas sa mga komento ang “SysLS, gamit ko ang isang pagsasama ng _____, sobrang galing! Isang araw lang, na-rebuild ko na ang Google!”—sa ganitong pagkakataon, sabi ko: Congrats! Pero hindi ka ang target na audience; ikaw ay kumakatawan sa isang napakaliit at napakaliit na grupo sa komunidad na talagang naiintindihan ang agent engineering.

Seryoso lang. Ang konteksto ay lahat. Ang isa pang problema sa paggamit ng libo-libong plugin at panlabas na dependensya ay ang pagkaapekto mo sa “context inflation”—kung saan sobra ng impormasyon ang nagpapalubos sa iyong proxy.

Gawin ko ba ang isang word-guessing game gamit ang Python? Simple. Hintayin mo, ano ba ang tala na “manage memory” na iyon sa 26 na sesyon pa ang nakalipas? Ah, may user na may screen na naka-stuck sa 71 na sesyon pa ang nakalipas dahil sa sobrang daming sub-process na aming ginawa. Laging isulat ang mga tala? Okay, walang problema… Ano ba ang ugnayan nito sa word-guessing game?

Alam mo naman. Gusto mo lang bigyan ng tama at sapat na impormasyon ang agent para makumpleto ang gawain, hindi higit pa o kulang! Mas mabuti ang pagganap ng agent kung mas maayos ang iyong pagkontrol dito. Kapag umuusbong ka na ng mga kakaibang sistema ng memorya, plugins, o masyadong magkakalat na mga pangalan at pagtawag sa mga kasanayan, ibinibigay mo na sa agent ang isang instruksyon para gumawa ng bomba at isang reseta para magluto ng cake, habang gusto mo lang na isulat niya ang isang tula tungkol sa mga redwood forest.

Kaya, muli kong ipinapahayag—alisin ang lahat ng mga dependensya, at pagkatapos…

Tiyak na paglalarawan ng mga detalye ng implementasyon

Remember that context is everything?

Tandaan mo ba na gusto mong ibigay sa agent ang eksaktong impormasyon na kailangan upang matapos ang gawain, hindi higit o kulang?

Ang unang paraan upang gawin ito ay ang paghihiwalay ng pag-aaral at pagsasagawa. Dapat mong maging lubos na eksakto sa iyong paghingi sa agent na gawin.

Ano ang mga epekto ng hindi pagiging tumpak? “Gumawa ng isang sistema ng pagpapatotoo.” Kailangan ng agent na pag-aralan: Ano ang isang sistema ng pagpapatotoo? Ano ang mga alternatibong solusyon? Ano ang mga kahinaan at kalakasan nito? Ngayon, kailangan niyang maghanap sa internet ng maraming impormasyon na hindi naman kailangan niya, at puno na ang konteksto ng iba’t ibang detalye ng pagpapatupad. Kapag dumating na ang oras na talagang pagpapatupad, mas madaling mabigo o magkaroon ng hindi kinakailangang o hindi kaugnay na halusinasyon sa napiling solusyon.

Sa kabilang banda, kung sinabi mo, “Gumamit ng JWT authentication na may bcrypt-12 password hashing, token refresh rotation, at 7-araw na expiry...”, hindi na kailangang pag-aralan ang anumang iba pang alternatibo, malalaman kung ano ang iyong hinahanap, at maaaring punuan ang konteksto ng mga detalye ng implementasyon.

Siyempre, hindi mo palagi alam ang mga detalye ng implementation. Madalas ay hindi mo alam kung ano ang tama, at minsan ay nais mong ipagkaloob sa agent ang paggawa ng desisyon tungkol sa mga detalye ng implementation. Ano ang gagawin sa ganitong sitwasyon? Sobrang simple—likhain ang isang research task upang suriin ang iba’t ibang posibilidad ng implementation, o magdesisyon ka mismo, o hayaan ang agent na piliin kung anong implementation ang gagamitin, at pagkatapos ay ipagkaloob sa isang ibang agent na may bagong konteksto ang pag-implement.

Kapag nagsimula ka na mag-isip nang ganito, makikita mo ang mga lugar sa workflow kung saan ang konteksto ng agent ay hindi kinakailangang nadudumihan, at maaari mong itakda ang mga pader ng paghihiwalay sa workflow ng agent upang abstrakton ang hindi kailangang impormasyon mula sa agent at iwanan lamang ang partikular na konteksto na gagawin itong maging mahusay sa task. Tandaan, mayroon ka na isang napakatalino at matalinong kasamahan sa timbangan na kilala ang lahat ng uri ng bola sa uniberso—ngunit kung hindi mo siya sinasabi na gusto mong disenyo ang isang espasyo kung saan maaaring umiikot at mag-enjoy ang mga tao, patuloy niyang iuulat ang mga benepisyo ng mga bagay na spherical.

Mga limitasyon ng disenyo na naglalayong pagsabihan

Walang gustong gamitin ang isang produkto na laging nagkakritika sa iyo, sinasabi sa iyo na mali ka, o lubos na nag-iisip sa iyong mga utos. Kaya, ang mga aghente na ito ay magtatrabaho nang mabuti upang sumang-ayon sa iyo at gawin ang nais mong gawin.

Kung ipapalit mo ang isang “masaya” sa bawat tatlong salita, sasunod ito nang buong-pusong—naiintindihan ng karamihan ang punto na ito. Ang pagkasunod nito ang dahilan kung bakit ito isang napakagamit na produkto. Ngunit mayroon itong isang napakagiliw na katangian: ibig sabihin nito na kung sabihin mo, “Tulongan mo akong hanapin ang isang bug sa codebase,” sasagot ito ng isang bug—kahit kailangan nito na “likhain” ang isang isa. Bakit? Dahil sobrang sobrang nais nito na sundin ang iyong utos!

Ang karamihan sa mga tao ay agad nagmumura sa LLM dahil sa mga hallucination at paggawa ng mga bagay na hindi umiiral, ngunit hindi nila naunawaan na ang problema ay nasa kanilang sarili. Ano man ang hinihingi mo sa kanya, iyon ang ibibigay niya—kahit kailangan ng kaunting pagpapalawak sa katotohanan!

Ano ang gagawin? Nakita kong epektibo ang “neutral prompt,” na hindi pinapahiwatig ang isang partikular na resulta. Halimbawa, hindi ko sinasabi, “Tulongan mo akong hanapin ang isang bug sa database,” kundi sinasabi ko, “I-scan ang buong database, subukang sundin ang lohika ng bawat komponente, at i-report ang lahat ng natuklasan.”

Ang ganitong neutral na paalala ay minsan ay makakahanap ng bug, at minsan ay simpleng naglalarawan kung paano gumagana ang code. Pero hindi ito nagpapahintulot sa agent na maging biased sa paghuhula na may bug.

Ang isa pang paraan upang harapin ang pagiging mapagpasya ay gawin itong isang kahusayan. Alam kong ang aking tagapag-ayos ay nagtatrabaho upang mapasigla ako at sundin ang aking mga utos, at maaari kong pahalagahan ito sa anumang direksyon.

Kaya pinagtrabahuhan ko ang isang agent para sa paghahanap ng bug upang matukoy ang lahat ng bug sa database, at sinabi ko sa iyo na ang mga maliit na epekto ay +1 puntos, ang may kaunting epekto ay +5 puntos, at ang malalaking epekto ay +10 puntos. Alam kong magiging sobrang masigasig ang agent na matukoy ang lahat ng uri ng bug (kabilang ang mga hindi bug), at sasabihin sa akin ang isang marka tulad ng 104 puntos. Ito kong itinuturing bilang superset ng lahat ng posibleng bug.

Pagkatapos ay pinag-utos ko ang isang adversarial agent na magtanggol, sinasabi ko sa ito na kung matagumpay itong magtanggol sa isang bug, kukuha ito ng puntos ng bug na iyon, ngunit kung mali ang pagtanggol, babawasan ito ng -2 beses ang puntos ng bug. Ang agent na ito ay magiging aktibo sa pagtanggol sa kahit anong bilang ng bug, ngunit dahil sa mekanismo ng parusa, ito ay magiging mapagbantay. Patuloy pa rin itong aktibong “tanggulan” ang mga bug (kabilang ang totoong mga bug). Ito ay itinuturing ko bilang isang subset ng lahat ng totoong mga bug.

Sa huli, ginamit ko ang isang judge agent upang sumama sa input ng dalawa at magbigay ng puntos. Sinabi ko sa judge agent na mayroon akong totoong tamang sagot: +1 puntos kung tama, -1 puntos kung mali. Pagkatapos, binigyan niya ng puntos ang bug agent at ang adversarial agent sa bawat “bug.” Kapag sinabi ng judge kung ano ang katotohanan, sinuri ko ito. Sa karamihan ng mga kaso, ang paraang ito ay nakakamit ng napakataas na katumpakan, at minsan ay may mga pagkakamali pa rin, ngunit ito ay isang operasyon na malapit sa walang kamalian.

Maaari mong makita na sapat na ang paghahanap ng isang proxy para sa bug, ngunit epektibo ito sa akin dahil ito ay nagpapakita ng likas na naprogramang katangian ng bawat proxy—ang pagkagusto na magpasya.

Ang tanong na ito ay tila mahirap, parang kailangan mong malalim na matutunan at sundan ang mga pinakabagong pag-unlad sa AI, ngunit tunay na simpleng simpleng… kung sinasagawa o kinuha ng OpenAI at Claude ito o ang kumpanya na nagawa ito… malamang ito ay may kapaki-pakinabang.

Napansin na ang mga kasanayan (skills) ay nasaan-man at bahagi na ng opisyal na dokumentasyon ni Claude at Codex? Napansin na kinuha ni OpenAI ang OpenClaw? Napansin na agad ni Claude ang idinagdag ang memorya, boses, at remote work functionality?

Paano ang planning? Nalalala mo pa ba ang dami ng mga tao na natuklasan na ang pagplano bago ang pagpapatupad ay talagang napakagamit, at naging core feature ito?

Oo, ang mga iyon ay kapaki-pakinabang!

Nalalala mo pa ba ang walang katapusan na stop-hooks na sobrang kapaki-pakinabang, dahil ang mga agent ay sobrang hindi gustong gawin ang mga matagal na proseso… tapos biglang nawala ang pangangailangan sa paglabas ng Codex 5.2?

Ito ang lahat ng kailangan mong malaman... Kung talagang mahalaga at kapaki-pakinabang ang isang bagay, gagawin ng Claude at Codex ito nang sarili nila! Kaya hindi ka kailangang mag-alala nang sobra kung gagamitin mo ang "bagong bagay" o magkakaroon ng kamalayan sa "bagong bagay"—hindi mo kailangan kahit na "mag-upgrade."

Tulungan mo ako. I-update ang iyong napiling CLI tool nang panahon-panahon, at basahin ang mga bagong feature na idinagdag. Sapat na iyon.

May ilan sa mga gumagamit ng proxy na nakakakita ng isang malaking trap: minsan ay tila sila ang pinakamatalinong mga bagay sa mundo, ngunit minsan ay hindi mo maikakredito na sinaktan ka nito.

Galing ba ito? Ito ay isang bulag!

Ang pinakamalaking pagkakaiba ay kung sinong agent ang pinipilit na gumawa ng mga aksiyon o "paggawa ng mga suposisyon." Sa kasalukuyan, mahina pa rin sila sa pag-uugnay ng mga punto, pagpapuno ng mga kulang, o paggawa ng mga suposisyon. Habang gawin nila ito, agad mong makikita—nagkakaroon ng malaking pagbaba sa kalidad.

Isa sa pinakamahalagang patakaran sa CLAUDE.md ay ang patakaran tungkol sa paano makakuha ng konteksto, at nag-uutos ito sa agent na unang basahin ang patakaran na iyon bawat beses na basahin ang CLAUDE.md (o bawat pag-compress). Bilang bahagi ng patakaran sa pagkuha ng konteksto, ang ilang simpleng panuto ay maaaring magdulot ng malaking epekto: muli pang basahin ang plano ng gawain, at muli pang basahin ang mga kaugnay na file bago magpatuloy.

Ang ating pagkakaroon ng malinaw na pakiramdam kung kailan natapos ang isang gawain. Ang pinakamalaking problema sa kasalukuyang pagkakaintindi ng isang agent ay ang kakayahan nito na malaman kung paano simulan ang isang gawain, ngunit hindi malaman kung paano ito tapusin.

Madalas ito'y nagdudulot ng napakalaking pagkabigo: ang agent ay nagtatapos sa paggawa ng isang hanay ng stubs.

Ang pagsubok ay isang mahusay na milestone para sa isang agent, dahil ang pagsubok ay deterministikong gawain, at maaari mong itakda ang mga malinaw na inaasahan. Hindi mo matatapos ang iyong gawain kung hindi nagmamay-ari ang X na pagsubok; at hindi ka pinapayagan na baguhin ang mga pagsubok.

Kaya mo lang i-review ang mga pagsubok, at kapag lahat ng pagsubok ay nakapasa, maaari ka nang magkaroon ng kalmado. Maaari mo rin itong automatikuhin, ngunit ang pangunahing punto ay—tandaan na ang “pagtatapos ng gawain” ay natural para sa tao, hindi para sa agent.

Alam mo ba ang iba pang mga feasible na task endpoints na nangyari recently? Screenshot + verification. Maaari mong ipaabot ng agent ang isang bagay hanggang sa makapasa lahat ng mga pagsubok, pagkatapos ay hingin ang screenshot at i-verify ang “design o behavior” sa screenshot.

Ito ay nagpapahintulot sa iyo na hayaan ang agent na mag-itera at magtrabaho patungo sa iyong hinahangad na disenyo, nang hindi ka nag-aalala na ititigil ito pagkatapos ng unang pagsubok!

Ang natural na pagpapatuloy nito ay ang paglikha ng isang “kontrata” kasama ang isang tagapag-ayos at ang pag-embed nito sa mga patakaran. Halimbawa, ang `{TASK}CONTRACT.md` ay nagtatakda kung ano ang kailangan gawin bago mo ma-terminate ang sesyon. Sa `{TASK}CONTRACT.md`, ikaw ang magtatakda ng mga pagsubok, screenshots, at iba pang mga pagsusuri na kailangan tapusin bago ma-verify na maaari nang tapusin ang iyong gawain!

Isang karaniwang tanong na tinatanong sa akin ay kung paano makakapagpatakbo ng isang agent nang 24 oras habang sinusiguro na hindi ito maliit.

Mayroong simpleng paraan dito. Lumikha ng isang stop-hook na hahadlang sa pagtatapos ng sesyon ng agent kung ang lahat ng mga bahagi ng `{TASK}_CONTRACT.md` ay hindi pa natatapos.

Kung mayroon kang 100 na contract na may malinaw na spesipikasyon at naglalaman ng mga nilalaman na nais mong buuin, ang stop-hook ay magpapahinga sa pagtatapos ng agent hanggang sa matapos lahat ng 100 na contract, kasama ang lahat ng kailangang i-run na pagsubok at pagpapatotoo!

Propesyonal na payo: Natuklasan kong ang mga mahabang 24-oras na sesyon ay hindi pinakamainam para sa paggawa ng mga gawain. Bahagyang dahilan nito ay ang paraang ito ay pilit na nagdudulot ng paglalawak ng konteksto, dahil ang konteksto ng mga hindi kaugnay na kontrato ay papasok sa iisang sesyon!

Kaya hindi ko ito inirerekomenda.

Mayroong mas mabuting paraan para sa automation ng agent—bumuo ng bagong sesyon para sa bawat kontrata. Gumawa ng kontrata kung kailangan mong gawin ang anumang bagay.

Lumikha ng isang orchestration layer upang lumikha ng bagong contract kapag kailangan gawin ang «isang bagay», at lumikha ng bagong session upang tratuhin ang contract na iyon.

Ito ang magbabago nang lubos sa iyong experience bilang agent.

Nag-e-employ ka ng isang administrative assistant, inaasahan mo ba na alam na niya ang iyong schedule mula sa unang araw? O kaya paano ka kumakain ng kape? Kain ka ng hapunan sa 6:00 PM kesa 8:00 PM? Malinaw na hindi. Babaguhin mo ang iyong mga preferensya habang lumalipas ang panahon.

Sakto rin sa agent. Magsimula sa pinakasimpleng konfigurasyon, kalimutan ang mga kumplikadong istruktura o harness, at bigyan ng pagkakataon ang pangunahing CLI.

Sundin ang mga hakbang na ito upang idagdag ang iyong mga pagpili.

Mga patakaran

Kung ayaw mong gawin ng agent ang isang bagay, isulat ito bilang isang patakaran. Pagkatapos, sabihin sa agent ang patakaran na ito sa CLAUDE.md. Halimbawa: “Bago sumulat ng code, basahin ang `coding-rules.md`.” Maaaring magkaroon ng nesting ang mga patakaran, at maaaring kondisyonal ang mga patakaran! Kung sumusulat ka ng code, basahin ang `coding-rules.md`; kung sumusulat ka ng mga pagsubok, basahin ang `coding-test-rules.md`. Kung nagkakaroon ng pagkabigo ang iyong mga pagsubok, basahin ang `coding-test-failing-rules.md`. Maaari mong lumikha ng anumang uri ng lohikal na sangay na patakaran na susundin ng agent, at magiging masigasig na sumunod si Claude (at Codex) kung may malinaw na paliwanag sa CLAUDE.md.

Sa totoo lang, ito ang unang praktikal na payo na ibinigay ko: gamitin mo ang iyong CLAUDE.md bilang isang lohikal, nested na table ng nilalaman na nagpapaliwanag kung saan hanapin ang konteksto sa mga partikular na sitwasyon at resulta. Dapat itong maging kahit anong maikli, at naglalaman lamang ng IF-ELSE na lohika na nagsasabi kung saan hanapin ang konteksto sa bawat sitwasyon.

Kung nakikita mo ang isang agent na gumagawa ng isang bagay na hindi mo sumasang-ayon, gawin itong isang patakaran at sabihin sa agent na basahin ang patakaran bago gawin muli ang bagay na iyon, siguradong hindi na ito gagawin.

Kasanayan

Ang mga kasanayan (Skills) ay katulad ng mga patakaran, ngunit higit na angkop para sa pag-encode ng mga "mga hakbang sa paggawa" kaysa sa pagkakaroon ng paboritong paraan sa pagsusulat ng code. Kung mayroon kang tiyak na paraan kung paano gustong gawin ang isang bagay, gusto mong i-embed ito sa mga kasanayan.

Sa katotohanan, madalas na nagkakaroon ng paghihinaan ng loob dahil sa kawalan ng malinaw na pag-unawa kung paano lalutasin ng agent ang isang problema. Kung gusto mong gawing mas tiyak ito, hayaan ang agent na unang suriin kung paano ito lalutasin, at isulat ang solusyon bilang isang skill file. Makikita mo na ang paraan kung paano lalutasin ng agent ang problema bago ito talagang makarating dito, at maaari mong i-correct o i-improve ito bago ito mangyari.

Paano mo ipapakilala sa agent ang kasanayang ito? Tama! Isulat mo ito sa CLAUDE.md na kapag nakakaroon ka ng sitwasyong ito at kailangan mong gamitin ito, basahin ang `SKILL.md`.

Mga patakaran at kasanayan sa pagproseso

Sigurado kang gustong magdagdag ng mga patakaran at kasanayan sa tagapag-ayos nang patuloy. Ito ang paraan upang bigyan ito ng pagkakakilanlan at pagtanda sa iyong mga preferensya. Halos lahat ng iba pang bagay ay labis.

Agad kang makakaramdam ng magic kapag nagsimula ka na. Magpapagawa ito ng mga bagay "ayon sa iyong nais". At sa huli, makakaramdam ka na ng "pagkakaintindi" sa agent engineering.

Tapos...

Makikita mo ang pagbaba ng performance na muli.

Ano ang nangyayari?!

Sobrang simple. Habang idinadagdag mo ang mas maraming patakaran at kasanayan, nagsisimulang magkondadikta o magsimula ang agent na magkaroon ng malubhang context inflation. Kung kailangan ng agent na basahin ang 14 na markdown file bago magsimula sa pag-program, mayroon siyang parehong problema ng sobrang impormasyon na walang kwenta.

Paano ito gagawin?

Linisin. Ipasok ng iyong agent ang「spa」, i-integrate ang mga patakaran at kasanayan, at tanggalin ang mga kabalintunaan sa pamamagitan ng pagsasabi sa amin ng iyong updated na pagkakapreferensya.

At babalik na naman ang pakiramdam na ito ay katulad ng mahika.

Ito na lang. Ito talaga ang susi. Panatilihin ang simpleng paraan, gamitin ang mga patakaran at kasanayan, gamitin ang CLAUDE.md bilang direktoryo, at maging mapagmalasakit sa kanilang konteksto at mga limitasyon sa disenyo.

Walang perfecto na agent ngayon. Maaari mong ipagkatiwala sa agent ang maraming disenyo at implementasyon, ngunit ikaw ang responsable sa resulta.

Kaya maging mabuting alerto…… at masayang pagsikat!

Ang saya ng maglaro ng mga laruan sa hinaharap (habang malinaw na ginagamit ito para sa seriozong bagay)!