Kapag kailangan pa ng tao na upo sa keyboard at magbigay ng direksyon sa bawat linya sa mga agent, ang pangunahing kakayahan ay ang pagsusulat ng mga prompt. Ngayon, ang mga agent ay maaaring tumanggap ng isang layunin at mag-run nang sarili nila, at ang bagong pangunahing kakayahan ay ang circular engineering.

May-akda ng artikulo: CyrilXBT

Artikulong isinalin, pinagkunan: ME News

Sa Hunyo 2026, sa loob ng isang linggo, tatlong tao ang nagkakaroon ng parehong konklusyon nang hiwalay.

Ipinahayag ni Peter Steinberger, ang developer ng OpenClaw, na dapat huminto na ang mga tao sa pagpapahiwatig nang direkta sa mga programming agent, at dapat silang magdisenyo ng mga loop system na makakapagpapadala ng mga utos nang awtomatiko sa mga agent.

Sa halos parehong oras, si Boris Cherny, ang tagapag-ugnay ng Anthropic Claude Code, ay nagpahayag na hindi na siya direktang nagpapakilala ng mga prompt sa Claude. Ngayon, ginagana niya ang isang serye ng mga loop na awtomatikong tumatawag sa Claude at nagpapasya kung ano ang susunod na gagawin, at ang totoong trabaho niya ay ang pagsusulat at pagdidisenyo ng mga loop na ito.

Ilang araw pagkatapos, ang Google engineer na si Addy Osmani ay isinagawa ang sistematisadong pagsusuri sa praktikang ito at ibinigay ang isang pangalan:

Loop Engineering,循环工程。

Hindi nila ito nilikha nang walang batayan, kundi tinawag ang isang pagbabago na nangyayari nang tahimik.

Dahil sa bago, ang mga panao sa ilalim ay nakalampas na sa isang mahalagang kritikal na punto: ang mga programming agent ay nagsimulang makapagtapos ng totoong mga gawain nang walang pagmamasid; ang gastos sa awtomatikong jadwal ay sapat na mababa upang ang paulit-ulit na pagpapatakbo ng isang gawain ay hindi na mukhang pagkawala; ang gastos sa isang pagpapatakbo ng agent ay bumaba na sa isang bagong antas—mas mabuti na hayaan ang agent na subukan limang beses kaysa mag-isip nang mabuti sa isang pagkakataon, dahil mas mababa ang gastos.

Ito ang eksaktong dahilan kung bakit umiiral ang road map na ito.

Kapag kailangan pa ng tao na upo sa keyboard at magbigay ng direksyon sa bawat linya sa mga agent, ang pangunahing kakayahan ay ang pagsusulat ng mga prompt. Ngayon, ang mga agent ay maaaring tumanggap ng isang layunin at mag-run nang sarili nila, at ang bagong pangunahing kakayahan ay ang circular engineering.

Narito ang buong 20-hakbang na landas mula sa isang prompt operator patungo sa isang system designer. Dapat ipagpatuloy ang bawat hakbang ayon sa pagkakasunod-sunod, dahil sa landas na ito, ang pagkakasunod-sunod ng mga hakbang ay kadalasang mas mahalaga kaysa sa anumang hiwalay na hakbang.

Ang circular engineering ay hindi isang iisang kasanayan na “natutunan” o “hindi natutunan,” kundi isang hanay ng mga kakayahan na nakakabatay sa isa’t isa. Bawat antas, ay nakadepende sa kung gaano kamatatag ang mga pundasyon sa ilalim nito.

Halimbawa, ang pagbuo ng automatic scheduling trigger sa hakbang 14 bago pa man makabuo ng totoong stop condition sa hakbang 10 ay magdudulot lamang ng isang sistema na makakapag-waste ng pera nang walang pagmamasid. Noon, kahit anong mangyari, kakaunti lang ang nagwawaste nang habang pinagmamasdan mo ang screen; ngayon, maaari itong magpatuloy na magbuburn ng pera nang sarili nito.

Kung gagawin mo ang persistent memory layer sa Step 11 bago magkaroon ng maaasahang verification mechanism sa Step 6 at Step 7, maaaring isave mo nang serio ang mga aral na isinumite ng isang reviewer na sobrang permissive at patuloy na nagpapalabas ng maling resulta.

Hindi ito makakatulong sa pag-unlad ng sistema, kundi magdudulot ng patuloy na pagkumpok ng maling karanasan, na gagawing “aktibong masama” ang memory layer mula sa “panahon na walang halaga”.

Kaya ang paglilipat sa ilang mga hakbang ay hindi lamang pagkakaroon ng isang function na hindi natutupad. Mas seriyoso ang problema dahil isasakop mo ang mga nakakaakit na advanced na kakayahan sa isang pundasyon na hindi kayang suportahan sila, at madalas ay hindi makikita ang problema hanggang sa ang sistema ay nagsimulang mag-scale at magdulot ng tunay na epekto.

Hindi kasali ang anumang teknolohiya ang totoong unang hakbang.

Dapat mong tanggapin na sa kasalukuyang workflow, ang mga pagtatakda sa efisiyensiya ay kadalasang hindi na ang kakayahan ng modelo, kundi ikaw mismo ay nananatili pa sa siklo.

Kapag nakaupo ka sa harap ng computer at naghihintay sa sagot ng model, binabasa ang resulta, at pumipili ng susunod na utos, ikaw ang pinakamabagal na bahagi ng buong sistema.

Ang model ay maaaring i-execute, i-verify, at i-retry, at mas mabilis ang mga operasyong ito kaysa sa pagmamasid ng tao sa bawat hakbang ng pagkumpleto nito.

Hindi may kasamang prompt sa hakbang na ito; ito ay isang kognitibong desisyon.

Bago mo talagang tanggapin ito, ang lahat ng susunod na hakbang ay mukhang mga hindi kailangang karagdagang gawain, kaysa sa kanilang tunay na kahulugan—ang pag-alis sa pinakamalaking bottleneck ng efisiyensiya sa sistema.

Kapag may problema ang output ng model, ang pinakakaraniwang reaksyon ng mga tao ay magdagdag ng isang patakaran sa orihinal na prompt.

Ilang buwan pagkatapos, ang pagkilos na ito ay magtatayo ng isang mataas na pader ng mga patakaran: malalim na nilalaman, magkakaugnay na magkakaiba, at matagal hanggang sa hindi kayang prosoesin ng modelo ang lahat ng mga hiling nang sabay-sabay sa kanilang trabaho na memorya.

Sa huli, ang modelo ay kadalasang nakakabase lamang sa pinakabagong lumalabas o pinakamakikita na mga nilalaman para sa pattern matching, at nang hindi alam ay nag-iisip ng iba pang mga patakaran.

Ang circular engineering ay nagbago nang lubos sa ganitong pananaw.

Kapag lumalabas ang problema, hindi ka na lang nagdaragdag ng isang bagong hiling sa prompt, kundi nagdaragdag ng isang bagong komponente sa sistema, halimbawa:

• Magdagdag ng isang hiwalay na pag-verify na hakbang;
• Magdagdag ng isang memory file;
• Magdagdag ng isang timer trigger;
• Magdagdag ng isang structured review na bahagi.

Dahil sa patuloy na pagpapalakas ng mga eksternal na sistema, ang mga prompt ay dapat maging mas maikli, hindi mas mahaba.

Anuman ang larangan ng partikular na gawain, bawat pagpapatakbo sa loop ay maaaring i-decompose sa limang pangunahing kilos:

Pagkilala, pagpapasa, pagpapatotoo, pagpapanatili, pagjadwal.

Pagkilala

Alamin kung ano ang tunay na gawain na kailangang matapos.

Pagpapasa

Ibigay ang gawain sa modelo, agent, o kasangkapan na responsable sa pagsasagawa.

Pagpapatotoo

I-check ang resulta batay sa totoong pamantayan.

Persistence

I-record kung ano ang nangyari sa pag-run na ito, kung ano ang natutunan, upang maiwasan ang pagkawala ng karanasan sa susunod na pag-run.

Pagjadwal

Ibigay kung kailan ulit tatanggalin ang proseso na ito.

Ang kasalukuyang workflow ng karamihan ay naglalaman lamang ng dalawang unang aksyon: pagkilala sa gawain at paghahatid ng gawain, at karaniwang ginagawa nang manu-manu sa window ng chat.

Ang tatlong iba pang galaw ay either hindi umiiral o nakatago sa sariling isipan ng tao.

Ang core ng circular engineering ay ang paggawa ng limang aksyon na ito ay malinaw at pagkatapos ay pagpapatakbo nito nang awtomatiko kung saan posible.

Bago magsimula sa pagbuo ng sistema, pumili muna ng isang gawain na iyong ginagawa nang paulit-ulit at kaya mong malinaw na ilarawan ang mga pamantayan sa kalidad.

Huwag pumili ng pinakamahirap na tanong o ng anumang bagong gawain na walang nakaraang halimbawa.

Dapat matugunan ng unang kandidatong gawain ang tatlong kondisyon:

1. Kailangan mong gawin ito nang paulit-ulit;
2. Mayroon itong malinaw na pamantayan na maaaring isulat;
3. Mayroon itong madaling kilalanin na “katayuan ng pagkumpleto”.

Sa ibang salita, pagkatapos makita ng isang kasamahan ang resulta, dapat niyang mabilis na matukoy kung tama ang natapos na gawain.

Mas mahalaga ang limitasyong ito kaysa sa mukha nito.

Kung walang malinaw na pamantayan para sa pagkumpleto ng isang gawain, hindi mo mabubuo ang tunay na proseso ng pag-verify. At ang isang siklo na walang maaasahang mekanismo ng pag-verify ay hindi tunay na siklo—ito ay isang pagkakamali na walang pagmamasid.

Ito ang pinakamadaling lalampasan ng karamihan, ngunit ito ang susi na nagdedesisyon kung makakapagtrabaho nang maayos ang sistema pagkatapos.

Bago isulat ang anumang utos para sa isang agent, isulat muna nang malinaw at natural na wika: ano ang dapat maging anyo ng tamang resulta.

Kailangan mo ang mga tiyak, ma-check na pamantayan, hindi ang mga ambigong pagtataya sa kalidad tulad ng “maraming pakiramdam” o “nagmumukhang propesyonal.”

Maaaring gamitin ang sumusunod na template:

Pangalan ng gawain: [Pangalan ng gawain]

Natapos na ang Definition of Done (DoD):

• [tiyak, masusuri na pamantayan 1]
• [tiyak, ma-check na pamantayan 2]
• [tiyak, ma-check na pamantayan 3]

Kahit na ang final output ay tila kompleto at mabuting pinahusay, kung kulang sa anumang isa sa mga ito, hindi ito maaaring ituring na natapos.

Kung hindi mo kayang punan ang template na ito para sa kasalukuyang napiling gawain, dapat bumalik ka sa Hakbang 4 at piliin muli ang isang mas angkop na gawain para sa pagbuo ng loop.

Ito ang pinakamahalagang desisyon sa arkitektura sa lahat ng cyclic systems.

Ang role na responsable sa pagbuo ng resulta ay dapat hiwalay sa role na responsable sa pagsusuri ng resulta.

Dahil sa pagkakaroon ng pagkakataon na agad na suriin ng modelo ang sariling output pagkatapos ng pagbuo nito, madalas itong magtanggol sa nabuong sagot kaysa talagang subukang suriin ito nang kritikal.

Sa isang makatwirang siklo, dapat mayroong kahit anong dalawang hiwalay na papel:

Tagagawa

Mayroong kalayaan sa paglikha ang mga tagagawa, at sila ang responsable sa pagbuo ng unang bersyon ng resulta.

Tagapagsuri

Ang reviewer ay tatanggap ng output ng builder at ang definition of done na isinulong sa Hakbang 5, at gagamit ng mga pamantayang ito upang matukoy kung ang resulta ay kwalipikado.

Sa ideal na sitwasyon, dapat makapag-access din ang mga reviewer sa mga independiyenteng ebidensya na hindi ma-access ng mga tagabuo, halimbawa:

• Test suite;
• Original na datos;
• Real-time data;
• Authoritative database;
• Original task brief.

Sa ganitong paraan, ang pagpapasya ng mga tagapagsuri ay batay sa totoong ebidensya, at hindi sa pagbuo muli ng isang subhektibong opinyon gamit ang parehong pag-iisip tulad ng tagagawa.

Kung ang tagapagsuri ay makakakita lamang ng output ng tagagawa, ito ay maaaring magbigay ng pagtataya kung ang resulta ay “mukhang magkakaugnay” lamang.

Hindi ito makakapag-decide kung ang resulta ay totoo o hindi.

Kaya, kailangan ng reviewer ang mga obhetibong batayan na maaaring i-verify, o Ground Truth. Ayon sa partikular na konteksto, maaari itong maunawaan bilang “benchmark na katotohanan,” “totoong data,” o “awtoridad na batayan.”

Ang mga obhetibong batayan ay magkakaiba para sa iba’t ibang gawain.

Programming task

Ang mga obhetibong batayan ay ang test suite at ang output na resulta pagkatapos ng tunay na pagpapatakbo ng code.

Content production task

Ang obhetibong batayan ay ang orihinal na materyales at content brief. Kailangan ng reviewer na i-compare ang orihinal na materyales kasama ang nabuong bersyon nang side by side.

Pananaliksik na gawain

Ang obhetibong batayan ay ang orihinal na dokumento, papel, dataset, o awtoridad na pinagkukunan na kinakailangan gamitin ayon sa tagubilin ng gawain.

Kung hindi mo malinaw na masasabi kung ano ang dapat gamitin ng reviewer bilang batayan para sa pagsusuri, hindi pa talaga may mekanismo ng pag-verify ang iyong loop, kahit gaano pa kasing tiyak ang mga salita ng reviewer.

Ang output ng tagagawa at ang konklusyon ng tagapagsuri ay dapat magkaroon ng malinaw na istraktura, at hindi lamang libreng paggalaw ng natural na wika.

Kung hindi, ang susunod na manager ay walang matatag at maaasahang impormasyon upang gawin ang pagpapasya at pagrout.

Ang mga tagabuo ay maaaring gamitin ang sumusunod na format ng output:

Output ng Builder:

• Final deliverables;
• Antas ng kumpiyansa sa resulta;
• Known uncertainty.

Ang mga tagapagsuri ay maaaring gamitin ang sumusunod na format ng output:

Mga kongklusyon ng pagsusuri:

• PASS: Nakapasa;
• FAIL: Pagkabigo;
• Kailangan ng pagbabago:
• Mga partikular na problema na natuklasan;
• Mga obhetibong pamantayan o orihinal na ebidensya na ginamit bilang batayan sa pagsusuri na ito.

Bago mag-access sa automatic scheduling at automatic retry, manu-manong i-run muna ang buong “Builder—Reviewer” workflow.

Basahin nang mabuti ang pagpapasya ng tagapagsuri at tanungin ang sarili mo:

• Sumasang-ayon ka ba sa kanyang konklusyon?
• Nagbigay ba ito ng isang resulta na alam mong may kamalian?
• Nagkakaroon ba ito ng maling pagtanggi sa isang orihinal na kwalipikadong resulta?

Kung ang reviewer ay tinanggap ang isang resulta na alam mong mali, o tinanggihan ang isang resulta na walang problema, dapat munang ayusin ang obhetibong batayan o kumpletuhin ang pamantayan bago magpatuloy sa pagbuo ng sistema.

Ang pag-automate ng isang maling verification step ay magdudulot lamang ng mas mabilis na paggawa ng maling resulta.

Upang gawing mas tiyak ang limang hakbang na ito, maaari nating obserbahan ang isang karaniwang gawain: ang pagpapalit ng isang orihinal na materyal sa isang buong artikulo.

Hakbang 5: Magbigay ng kumpletong depinisyon

Ang mga pamantayan para sa pagkumpleto ng gawain ay:

• Ang bawat katotohanan sa draft ay maaaring i-trace sa malinaw na nilalaman ng orihinal na sanggunian;
• Ang draft ay sumasapat sa lahat ng partikular na kahilingan sa briefing, kabilang ang haba, tono, at istruktura;
• Ang pangunahang argumento ng orihinal ay malinaw na pinanatili, hindi na-dilute ng walang kwentang pagpapalawig.

Hakbang 6: Gumawa ng draft ang mga tagagawa

Tanggap ng mga tagabuo ang orihinal na materyales at content brief, at lumilikha ng isang draft.

Samantala, kailangan din nito na malinaw na listahin ang anumang kakaibang aspeto sa proseso ng pagsusulat, tulad ng:

• Nakikita ba ang numerong iyon sa orihinal na dokumento;
• Isang konklusyon ay direktang inilahad sa orihinal na teksto, o itinayo ng modelo mismo?
• Kulang ba sa sapat na pinagkukunan ang isang katotohanan.

Hakbang 7: I-check ng reviewer ang orihinal na teksto

Ang mga reviewer ay tumatanggap ng draft at ang orihinal na materyales, hindi lang ang draft.

Kailangan nito na i-check nang hiwalay ang tatlong pamantayan sa definisyon, at ibigay ang magkahiwalay na resulta ng pagpasa o pagkabigo para sa bawat pamantayan, hindi na i-compress ang lahat ng dimensyon sa isang malabo at komprehensibong marka.

Ang pagsasama-sama ng tatlong iba’t ibang pamantayan sa isang pangkalahatang paghuhusga ay maaaring magkakaroon ng pagkakalikom kung aling dimensyon ang may problema. Ito ang pinakakaraniwang dahilan kung bakit maraming mga siklo na dati ay gumagana ay nagsisimulang mawalan ng halaga sa feedback.

Hakbang 8: Struktural na Pagpapasa

Dapat ang konklusyon ng reviewer ay isang structured object, hindi isang parirala ng natural na wika na puno ng mga pagsisigla.

Kailangan nito na maglabas ng tatlong malinaw na resulta ng pagkakaroon o pagkabigo, at magbigay ng tiyak na dahilan para sa bawat pagkabigo.

Hakbang 9: Manu-manong pag-verify ng mekanismo ng pagsusuri

Bago mag-run ang sistema nang awtomatiko, ang pagpapatakbo ng isang buong proseso nang manu-manu ay makakatulong sa iyo na makita kung ang mga tagapagsuri ay sobrang mabait o sobrang mahigpit.

Masyadong mahigpit na tagapagsuri, maaaring pabayaan ang mga fiksyon na datos dahil sa magandang pagkakasulat ng artikulo.

Ang sobrang mahigpit na tagapagsuri ay maaaring maliit na tanggihan ang isang sapat na artikulo dahil sa isang personal na pagkakagustong hindi isinama sa briefing.

Kadalasan ang mga problema na ito sa unang pagtatayo.

Mas mahal ang paglutas ng mga problema pagkatapos ng 50 beses na walang tao ang nagmamaneho ng sistema, kaysa sa paglutas nito noong unang pagkakataon na manual na pagsubok.

Ang Manager ay responsable sa pagbabasa ng mga desisyon ng mga reviewer at sa pagpapasya ng susunod na hakbang.

Dapat ding umiiral ang mga kondisyon para sa paghinto sa manager, at dapat itong isulat bilang malinaw na hard logic, hindi isang malambot na utos na maaaring i-evade ng modelo sa pamamagitan ng sariling pagsasalaysay.

Halimbawa:

Stop condition:

• Pinakamaraming pagbabago: 3 beses;
• Kapag nagkakaroon pa rin ng pagkabigo sa ikatlong pagsusuri, ipasa ang buong kasaysayan sa pagtrato ng tao, at huwag paganahin ang ikaapat na pagbabago;
• Pamantayan sa kalidad: Dapat ipakita ang PASS sa bawat item sa depinisyon;
• Budget limit: Kung ang gastos sa task ay lalampas sa X, o ang pagpapatakbo ay hihigit sa Y, ipaputol agad kahit anong kalagayan ngayon.

Ang isang loop na walang tunay na kondisyon para sa paghinto ay hindi isang sistema, kundi isang obligasyon na naghihintay para maipakita ang panganib.

Bakit hindi mapagkakatiwalaan ang mga malambot na utos tulad ng “tigil kapag sapat na ang resulta”?

Kasi ito ay isang payo lamang.

Kapag ang modelo ay nagkakaroon na ng maraming pagkakataong pagbabago ngunit hindi pa rin nakapasa, upang bigyan ang gawain ng isang tila masatisfyong wakas, malamang ito'y magpapasiya na paniniwalaan na “sapat na malapit na ang bersyon na ito sa pamantayan,” at kaya'y bababaan nito ang sariling antas ng paghuhusga.

Sa kumpara, ang mga iterasyon na sinusuri ng code nang mekanikal, o ang mga malinaw na patakaran na hindi kayang iwasan ng manager sa pamamagitan ng pag-iisip, ay hindi nagdudulot ng ganitong problema.

Kung ang bawat siklo ay magsisimula mula sa zero bawat beses na ito ay pinapagana, hindi ito makakatanda sa mga natutunan noong nakaraang pagpapagana.

Kaya kailangan magdagdag ng isang simpleng persistent layer.

Maaaring lumikha ng isang file para sa bawat tunay na bagong karanasan, at isama sa itaas ng file ang isang pangungusap na naglalaman ng summary:

• Ano ang natutunan;
• Ano ang naayos;
• Bakit mahalaga ang karanasang ito.

Ang pangunahang prinsipyo ay: mag-record lamang ng bagong kaalaman na hindi pa nabawasan sa ibang lugar.

Ang pag-uulit ng memorya ay hindi kaalaman, kundi ingay.

Upang maging epektibo ang mekanismo ng persistence sa matagalang panahon, kailangan magpakamatyag sa pag-write.

Madaling makaramdam ng pagkakaroon ng pagnanais na i-record ang lahat ng detalye ng operasyon, ngunit ito ay magreresulta lamang sa pag-uulit ng problema ng “masyadong malaking prompt” na nabanggit sa Hakbang 2, ngunit sa pagkakataong ito, ang nagkakaroon ng paglalawak ay ang prompt, hindi ang folder ng memorya.

Ang mga tunay na karanasan na dapat tandaan ay ang mga ito na kung kalimutan, kailangan mong mag-iiwan ng maraming oras para mahanap muli, hindi ang karaniwang pagpapatakbo na naganap nang maayos ayon sa inaasahan.

Ang pagdodoble lang ng mekanismo ng persistence ay magdudulot din ng mga problema na katulad ng sobrang haba ng prompt.

Sa paglipas ng panahon, makakalikha ang sistema ng mga dekada ng mga file, kung saan marami sa kanilang nilalaman ay simpleng magkaibang paraan ng pagsasalaysay ng parehong problema.

Kaya, dapat ay isagawa ang pag-ayos ng memorya file sa fixed na pagsisiklo. Ang paggawa nito tuwing linggo ay karaniwang isang makatwirang kadalian.

Ang proseso ng pag-ayos ay kasama ang:

• Iwasan ang umiiral na memorya;
• I-merge ang mga paulit-ulit na nilalaman;
• I-compact ang maraming magkakatulad na karanasan sa isang mas malinaw na prinsipyo;
• Alisin ang mga nilalaman na nakatuklasang mali o luma na.

Hindi ang layunin na akumulahin ang lalong maraming mga file, kundi makamit ang mas kaunting mga kaalaman na may mas mataas na density ng impormasyon.

Marami ang lalampas sa hakbang na ito dahil hindi ito agad nagdadala ng makikita mong bagong kakayahan, kundi nagpapalakas lamang sa pag-iwas sa mga problema sa hinaharap.

Ngunit dahil sa kawalan nito ng agarang feedback, mas dapat itong malinaw na isama sa schedule, hindi ipagpaliban hanggang sa makita ng isang tao na ang folder ng memorya ay naging mahirap pangasiwaan.

Sa katotohanan, ang ganitong uri ng gawain na “iayos sa susunod na pagkakataon” ay karaniwang hindi maiuunlad, hanggang sa mabawasan na ang system performance dahil sa malaking dami ng magkakaugnay, obsoletong, at bahagyang kaugnay na memorya na nagpapalaban para sa context window.

Sa bawat pagkakataong magsisimula ang bagong gawain, hayaan ang loop na unang i-scan ang isang maikling buod sa file ng memorya upang matukoy kung aling mga karanasan ang tunay na may kinalaman sa kasalukuyang gawain, at i-load lamang ang mga kaugnay na detalye.

Dapat ding malinaw na hilingin sa sistema: kung walang laman ang umiiral na memorya na angkop sa kasalukuyang gawain, sabihin nang direkta na walang angkop na karanasan.

Huwag magpilit na gamitin ang mga nakaraang karanasan sa isang hoànay iba’t ibang bagong problema dahil ang memory system ay umiiral na.

Susunod, kailangan mong pumili kung kailan magpapatakbo ang siklo na ito nang awtomatiko nang walang tao ang mag-start.

Maaaring kasama ang mga paraan ng pag-trigger:

• Cron scheduled task;
• File change listener;
• Calendar-based cycle trigger;
• Nagpapalabas kapag nagkakaroon ng pagbabago sa isang panlabas na pangyayari o estado.

Ang hakbang na ito ay magpapalit sa isang sistema na maaaring i-start mo lamang nang manual, sa isang sistema na makakapagpatuloy sa pagpapatakbo habang ikaw ay natutulog.

Ang nakakatooto, ito ay karaniwang ang pinakamadaling hakbang sa buong lista, ngunit ito rin ang hakbang na hindi pa ginagawa ng marami, kahit na natapos na nila ang iba pang mga komponente.

Bago gamitin ang loop sa anumang mahalagang gawain, kailangan aktibong subukan ang apat na uri ng pagkabigo.

Sarili: Hindi matatapos na gawain

Ibigay sa sistema ang isang totoong hindi matutugunan na gawain upang masiguro na makakauwi ang manager ayon sa mga kondisyon ng paghinto, hindi isang walang hanggang loop.

Kung isang loop ay tinitest lamang sa mga gawain na kayang matagumpay na tapusin, hindi ito patotohanang may kakayahang mag-fail nang maayos.

Pagsusuri 2: Maaaring mukhang wasto ngunit mali ang resulta

Magbigay ng isang output na alam mong may maliit na pagkakamali.

Dapat basahin ang resultang ito nang lubos na maluwag, ngunit may isang artipisyal na error sa katotohanan o lohika na iyong isinama.

Obserbahan kung makakakita ang reviewer ng mga problema, hindi lang dahil ang nilalaman ay tila makatwiran.

Sukat 3: Ibahagi ng tagagawa at tagapagsuri ang mga blind spot ng modelo

Kung gumagamit ang tagapagbuo at ang tagapagsuri ng parehong pundamental na modelo, maaaring isama nang may intensyon ang isang karaniwang pagkakamali na madalas gawin ng modelo, at obserbahan kung papayagin ng tagapagsuri ito.

Kung mayroon ang reviewer at ang builder ng parehong blind spot, nawawala ang kahalagahan ng paghihiwalay ng mga tungkulin sa Hakbang 6.

Suliranin 4: Kalkulahin ang operating cost sa pinakamasamang kaso

Sa pamamagitan ng pinakamataas na bilang ng pagbabago, paggamit ng pinakamahal na model call at pinakamahabang output sa loob ng makatwirang saklaw, kalkulahin ang kabuuang gastos na kakailanganin ng sirkulong ito sa pinakamasamang kaso.

At saka tanungin nang tapat ang sarili mo:

Magkakaroon ba ng pag-aalala ka kung lumabas ang numerong ito sa totoong bill?

Complete these four tests before the trust cycle handles critical tasks to identify most potential issues in advance.

Kung hindi, malamang ay magkakaroon ang mga problema na ito sa harap ng mga customer at manager, o direktang ipapakita sa iyong bill, kaysa sa isang pagsubok na iyong kontrolado.

Pagkatapos makamit ang stable na pagpapatakbo ng loop, huwag gamitin ang iisang modelo na iyong pinakamahalaga para sa lahat ng mga karakter.

Ang iba’t ibang papel sa loop ay may iba’t ibang hiling sa kakayahan ng modelo.

Builder

Dapat gamitin ng mga tagagawa ang pinakamalakas na modelo.

Dahil ito ang nagtatanggol ng pangunahing komplikadong pag-iisip at pagbuo ng nilalaman. Kung gagamitin ang model na walang sapat na kakayahan dito, bababa ang kalidad ng unang bersyon, at maaaring kailanganin ang higit pang mga pagbabago sa susunod.

Sa huli, ang gastos na kinakailangan upang ayusin ang mababang kalidad na draft ay maaaring mas mataas kaysa sa paggamit ng mas malakas na modelo mula sa simula.

Reviewer

Ang mga tagapagsuri ay responsable sa pagsusuri batay sa malinaw na mga pamantayan, at karaniwan ay hindi kailangan ng malakas na kakayahan sa pagkamalikhain.

Kapag sapat ang detalye ng standard, madalas ay maaaring matatag na matapos ng mas maliit, mas mura, at mas mabilis na modelo ang gawain ng pagsusuri.

Kung gumagana ang isang maliit na modelo batay sa isang napakalaking checklist, maaaring magkaroon ito ng katulad na katatagan sa malalaking modelo, ngunit mas mababa ang gastos at latency.

Manager

Ang manager ay nagr-routes lamang batay sa mga alituntunin na naisulat, at halos hindi kailangang gamitin ang pinakamahal na model.

Ang tungkulin nito ay isagawa ang naka-definirang lohika, hindi ang open-ended na pag-iisip.

Bukod dito, anuman ang pagganap ng mga tagapagbuo at tagapagsuri, ang manager ay tumatakbo sa bawat iterasyon ng isang beses, kaya ang kanyang gastos sa bawat pagtawag ay lalo na mahalaga.

Ang makatwirang konfigurasyon ng mga antas ay karaniwan ay:

• Ang malakas na modelo ay responsable sa pagbuo;
• Ang murang at matatag na modelo ang responsable sa karaniwang pagsusuri;
• Ang mura na modelo o programa ng patakaran ang responsable sa pagrute at pagpapamahala.

Ang tunay na malaking pagpapababa sa gastos sa loop system ay karaniwang nagmumula sa pagkakatugma ng mga papel sa ganitong modelo.

Naniniwala ang marami na ang pagkontrol sa gastos ay nangangahulugan ng pagbawas sa bilang ng mga siklo o pagbabago. Sa katotohanan, mas epektibong paraan ay ang pagpaparehistro ng gastos ng modelo sa aktwal na antas ng hirap ng bawat tauhan sa siklo.

Matapos ang unang siklo na tagumpay, madali para sa mga tao na agad na subukang buuin ang maraming siklo nang sabay-sabay, at paralel na prosesuhin ang limang iba’t ibang gawain.

Kahit na ang kasalukuyang arkitektura ay nakakatugon na sa ganitong pagpapalawak, dapat mong pigilan ang ganitong pagkukusa.

Dapat mong hayaan muna ang unang loop na mag-run nang sapat na panahon hanggang sa hindi mo na kailangang suriin nang mabuti ang bawat output nito.

Hindi ito tumutukoy sa isang pagpapakita na nagsuot ng tagumpay nang biglaan habang pinapanood ng lahat, kundi ito ay patuloy na nakakapasa sa random na pagsusuri ng tao matapos ang isang tunay na pagpapatakbo.

Dapat lamang magsimula sa pagbuo ng pangalawang siklo kapag natapos na ang estado na ito.

Ang pangalawang loop ay dapat gamitin para sa isang gawain na malinaw na iba sa unang loop.

Para matiyak kung ang paaalat na arkitektura ay may totoong universalidad, at hindi lamang mas detalyadong pinapaganda para sa iisang gawain.

Pagkatapos mong i-run ang maraming loop nang sabay-sabay, kailangan mong magtatag ng isang nag-iisang monitoring view upang i-trace ang lahat ng gastos at pag-trigger ng mga kondisyon para sa paghinto ng lahat ng loop, hindi lang ang bawat isa nang hiwalay.

Nakikita nang mag-isa, ang isang budget para sa isang siklikong gawain ay maaaring lubos na makatwiran.

Ngunit kahit na ang sampung loop ay nagtatrabaho nang nasa loob ng kanilang budget, ang kanilang kabuuang gastos ay maaari pa ring umabot sa isang nakakagulat na antas.

Dahil ang bawat hiwalay na data sa bawat siklo ay tila normal, ang panganib na ito ay kadalasang nakikita lamang kapag lumabas ang pinagsamang talaan.

Kailangan ding rekordin ang bawat pag-trigger ng condition para sa paghinto, maliban sa mga natapos na gawain.

Kung ang isang loop ay madalas na makakarating sa pinakamataas na bilang ng pagbabago, habang ang ibang loop ay rare na nagkakaroon nito, ang signal na itinataguyod nito ay maaaring hindi “partikular na mahirap ang gawain”, kundi:

• Hindi makatwiran ang mga pamantayan sa pagsusuri;
• Ang mga tagapagsuri ay sobrang mahigpit, kaya hindi nakakapasa anumang resulta;
• Sinuri ng sistema ang maling batayang obhetibo;
• Ang pagkakatawag sa sarili ay may problema.

Kung tanging sinusubaybayan ang mga tagumpay na resulta at ang bawat manual na upgrade ay itinuturing na magkakahiwalay at random na pangyayari, ang pattern na ito sa antas ng disenyo ay hindi makikita.

Ang pinakamalaking pamantayan upang masabing natapos na ang pagbabago ng pag-iisip ay ang pagbabago sa mga indikador na pinapansin mo araw-araw.

Ang mga nagpapatakbo ng prompt ay nag-aalala tungkol sa:

• Ilang epektibong prompt ang isinulat mo ngayon?
• Ano ang pinakamabuting prompt?
• Paano isulat ang mga prompt nang mas matalino.

Ang mga designer ng sistema ay nakikialam sa:

• Ilan ang kasalukuyang bilang ng mga siklo na nagpapatakbo;
• Ano ang reliability ng bawat cycle?
• Ilang oras ang inilabas ng sistema para sa sarili nito;
• Ano-ano ang mga trabaho na hindi na kailangan ng tao na masuri?

Kung patuloy mo pang sinusukat ang iyong produktibidad batay sa bilang ng prompts na iyong inilagay, hindi pa talaga natapos ang pagbabago ng isip na hinihingi sa Hakbang 1, anuman ang bilang ng mga loop na naitayo mo sa teknikal na aspeto.

Ang huling hakbang ay hindi na ganap tungkol sa iyong sariling sistema.

Ginagamit ito upang patunayan na talagang naiintindihan mo ang这套方法.

Kailangan mong subukan ipaliwanag sa isang tao ang limang pangunahing galaw nang hindi nakadepende sa mga kumplikadong termino:

Pagkilala, pagpapasa, pagpapatotoo, pagpapanatili, pagjadwal.

Kung kayang i-dala mo ang isang tao sa pagbuo ng kanyang unang loop gamit ang limang galaw na ito at ang mga nakaraang hakbang, ibig sabihin ay natapos mo na ang tunay na pagbabago na ilarawan sa road map na ito.

Hindi ka na ang tao na nasa loob ng loop at patuloy na nagpapasok ng susunod na utos.

Naging isa ka sa mga nasa labas ng siklo, na nagdisenyo ng sistema at nagmamasid kung paano ito tumatakbo nang sarili nito.

Ang apat na gastos na makakalap nang tahimik pagkatapos i-skip ang mga hakbang

Kailangan magbigay ng babala sa dulo ng artikulo.

Ang paglilipas sa mga hakbang sa road map na ito ay madalas ay hindi agad nagdudulot ng pagkabigo ng sistema.

Ang kanyang pagkabigo ay karaniwang tahimik, at kahit sa isang mahabang panahon ay mahirap makita, hanggang sa ang mga problema ay nakumpuni na sa isang malaking antas.

Kapag pinapaglabas mo ang hakbang 6 at 7, walang mga reviewer na talagang independiyente, at walang mapagkakatiwalaang obhetibong batayan, magkakaroon ng akumulasyon sa pagpapatotoo ng utang.

Ang siklo ay tila patuloy na gumagana nang maayos, dahil ang mga resulta na nilikha ay “mukhang mabuti.”

Hanggang sa isang pagkakamali ay magkakaroon ng patuloy na akumulasyon sa loob ng maraming pagpapatakbo at sa huli ay matuklasan ng isang tao, iyong mapapansin na ang sistema ay hindi nagtataglay ng tunay na pagtataya kung tama ang resulta mula sa simula.

Maaaring magkaroon ng pagbaba sa pag-unawa kapag nag-skip ka sa hakbang 20.

Patuloy ka pang gumagamit ng sarili mong nilikhang loop, ngunit hindi na makapagpaliwanag nang malinaw kung bakit umiiral ang bawat komponente, at hindi makapag-debug nang epektibo kapag may pagkabigo sa sistema.

Dahil sa katotohanang hindi mo pa talaga na-internalize ang lohika sa likod ng ganitong arkitektura.

Ang cognitive surrender ay nangyayari kung ang hakbang 1 ay hindi nagawa nang totoo.

Kahit na patunay na ang sistema ng pag-verify ng kanyang kumpiyansa sa pamamagitan ng matagal na paggamit, patuloy kang titingin nang manual sa bawat output dahil sa iyong pagkakadepende.

Ang ganitong pagkilos ay tila maingat, ngunit sa katotohanan ay nagpapalabas sa buong kahulugan ng pagbuo ng sistema.

Kung iiskip ang hakbang 10 at walang totoong kondisyon para sa paghinto ng loop, maaaring magkaroon ng walang hanggang pagkawala ng Token at gastos sa pagtawag.

Hindi mo karaniwang napapansin ang problema agad kapag nagsisimula nang mawala ang kontrol ng sistema, kundi hanggang sa lumabas ang huling taksil, natutuklasan mo na ang siklo ay nagaganap na ng maraming walang kwentang pagtawag.

Lahat ng gastos na ito ay maiiwasan.

Ang paraan upang maiwasan ang mga ito, laging iisang disiplina:

Gumawa nang sunod-sunod, huwag iskip ang mga hakbang na tila hindi sapat na kahanga-hanga.

Ang mga pinakamakapagpapagod na bahagi ang karaniwang nagtataglay ng tunay na epekto:

• Clear completion definition;
• Makatotohanang kondisyon para sa paghinto;
• Maaaring i-verify na obhetibong batayan;
• Independent review mechanism.

Kumpara sa iyan, ang mga bahaging tila mas nakakaaliw—mga matalinong prompt, mga kumplikadong mga anyo ng sistema—ay mas maliit kaysa sa paniniwala ng marami.

Ang tunay na nagpapasya sa kalidad ng sistema ay kung alam ba ng sistema na iyong binuo:

• Kailan tama ang sarili mo;
• Kailan tama ang sarili mong pagkakamali;
• Kailan dapat tumigil.

Ito ang buong pagkakaiba sa pagitan ng operator ng prompt at ng designer ng sistema.

Hindi ito tungkol sa kung sino ang mas matalino o kung sino ang makakasulat ng mas magandang prompt.

Ang totoong pagkakaiba ay kung may sapat ka bang disiplina upang seriyosong buuin ang mga bahaging mababaw, madaling i-skip, ngunit talagang nagpapasya sa kumpiyansa ng sistema.