Менде бірнеше Miro тақтасы бар, олар әлдеқашан load-bearing болып кеткен — жылдар бойы жиналған рефлексиялар, жоспарлар, ойлау карталары. Export түймесі саған PNG не PDF береді. Бұл — дерек емес, деректің фотосуреті.

Неге оларды сыртқа шығару керек

Vendor lock-in — теориялық мәселе емес. Ол нақты: өз деректеріңді API арқылы жүктеп алу үшін Expert tier-ге upgrade жасауың керек. Яғни, өзіңдікі болып тұрған нәрсені қайтарып алуға рұқсат үшін ақы төлейсің.

Мен әлдеқашан Obsidian-first принципімен өмір сүремін: маңызды нәрсенің бәрі жергілікті vault ішінде, git-ке салуға, grep жасауға және он жылдан кейін де оқуға болатын plain files түрінде жатады. Осындай форматқа экспорт бермейтін құрал — тәуелділік үзуге келмейтін дәрежеге жетпей тұрып кетуің керек құрал.

Неге Export сені құтқармайды

Miro-дағы Export түймесі саған PNG не PDF береді. Бұл — raster, құрылымы жоғалған. Box ішіндегі мәтінді өзгерте алмайсың. Shape-ті сүйреп жылжыта алмайсың. Жазуды grep жасай алмайсың. Бұл — тақтаның қазасы туралы хабарлама, тақтаның өзі емес.

Obsidian-да vault ішінде тұратын екі балама бар: Excalidraw plugin және нативті Canvas. Екеуі де — JSON. Екеуі де — editable. Екеуі де — searchable. Екеуі де жазбаларыңның қасында vault ішінде жатады, ал мәтінді тікелей Obsidian ішінен grep жасай аласың.

'Export to Obsidian' түймесі жоқ кезде оларды қалай шығарасың

UI-дағы Export саған керегін бермесе — API-ге кіресің. Miro-да REST API бар: ол тақтадағы әрбір shape-тің JSON сипаттамасын қайтарады. Excalidraw мен Obsidian Canvas — екеуі де open-format JSON. Олардың арасында — mapping.

Мен екі Python скрипт жаздым. miro_to_excalidraw.py және miro_to_canvas.py. Standard library only — нөл deps. Оларды token мен board ID-мен іске қосасың, файл аласың, оны vault-қа тастайсың.

Түрлендіруден кейін не сақталды

Мақсат тек shapes-ті көшіріп әкелу емес еді — тақта Miro-дағыдай оқылатындай етіп визуалды сақтап қалу еді.

• Позициялар мен өлшемдер — әрбір shape-тің координаттары 1:1
• Түстер fill opacity-мен (40% сары түс 40% сары болып қала береді)
• Borders — түс, ені, стилі (solid / dashed)
• Қаріптер мен alignment — monospace monospace болып қалады, center center болып қалады
• Connectors — көрсеткілер Miro бекіткен нүктелердің дәл өзінде тұрады
• Curved connectors — түзу сызықтардың орнына bow доғалары
• Images файлдың ішіне ендірілген (сыртқы URL емес)
• Mindmap nodes — мәтін experimental Mindmap API арқылы шығарылған
• Z-ordering — overlap шатаспайды

Қай жерде қолайсыз болды

Miro API-де бірнеше олқылық бар, оларды reverse engineering арқылы айналып өтуге тура келді.

• Curved connectors — Miro control points-ты API арқылы ашпайды. Сондықтан дәл түпнұсқа қисықтың орнына мен bow синтездеймін — екі endpoint арасындағы тұрақты радиусты доға. Визуалды жағынан жақын, mathematically identical емес.
• Z-index — Miro API z өрісін мүлде қайтармайды. Қай shape үстінде, қайсысы астында тұруы керек? Эвристика: ауданы үлкенірек = артқа тереңірек. Бұл жұмыс істейді, өйткені нақты тақталарда үлкен контейнерлер әдетте ұсақ элементтердің астында отырады.
• Mindmap — mindmap nodes мәтіні кәдімгі items API арқылы қолжетімсіз. Experimental Mindmap endpoint-ке бөлек call керек. Filled nodes boxes-қа айналады, unfilled — plain text-ке.

Excalidraw vs Canvas — қалай таңдау керек

Егер сен drawings стилінде ойласаң — sketchy lines, hand-drawn feel, freeform композициялар — Excalidraw таңда. Excalidraw plugin файлды whiteboards-та көрген дәл сол эстетикалық стильде рендерлейді.

Егер тақталарың негізінен көрсеткілермен жалғанған, мәтіні бар тіктөртбұрыштар болса және сен Obsidian-да second brain ретінде өмір сүрсең — Canvas таңда. Canvas нативті, бір басқанда ашылады және vault-тың backlinks пен tags-ымен тұтасып тұр.

Кейбір тақталарды Excalidraw-ға (visual style маңызды болғанда), басқаларын Canvas-қа (жылдамдық пен нативті feel маңызды болғанда) түрлендіремін. Repo екі форматты да қолдайды — іске қосу кезінде таңдайсың.

Қорытынды

Python 3, standard library only. pip install жоқ, virtualenv жоқ, node_modules жоқ. python3 miro_to_excalidraw.py 'BOARD_ID' 'output.excalidraw' — сосын файл сенің қолыңда.

Repo: github.com/oleksiimazurenko/miro-to-obsidian. MIT лицензиясы. PR-лар құпталады — әсіресе мен әлі кездестірмеген edge case-тер үшін.

Сабақ Miro-дан әлдеқайда кең

SaaS lock-in — есірткі. Алғашқы айлар тегін. Алты айдан кейін — әдет. Бір жылдан кейін деректерің тек олардың UI-ы оқи алатын форматта тұрады. Екі жылдан кейін — өзіңдікі болып тұрған нәрсені қазып алу үшін Expert tier-ге ақы төлейсің.

Қорытынды «SaaS-ты қолданба» емес. Қорытынды мынау: load-bearing болуға жол берген әрбір құралға оны алғаш ашпай тұрып exit plan керек. «Керек болғанда бұл жерден қалай шығамын» деген сұрақ «UI қаншалықты жайлы» дегенмен бірдей салмақты. Plain-text экспорты немесе ашық API-і жоқ құрал — екі жылдан кейін төлейтін жасырын баға белгісі бар құрал.

Obsidian-first Obsidian мінсіз болғандықтан емес. Ал plain markdown файлдары Obsidian-ның өзінен ұзақ өмір сүретін формат болғандықтан. Дәл солай, жалаң Excalidraw JSON файлы plugin-нің өзінен ұзақ өмір сүреді. Дәл солай, бұл Python скрипті Miro-дан ұзақ өмір сүреді.

Кеңестердің ретсіз тізімі емес — олар шаршаған сәтіңде-ақ буланып ұшып кетеді. Қысым астында есіңе түсіре алатын, аты бар канон — нысанға бағдарланған дизайн үшін SOLID қалай жұмыс істесе, солай. Мен оны CRAFT деп атаймын: бес қағида, әрқайсысына бір әріп, бәрі бір аксиоманың астында. Атаудың өзі — бүкіл мән: кодтау қолөнер болып қала береді, ал AI — онсыз да жұмысты атқара алатын адамның қолындағы жай ғана құрал.

Аксиома: жылжымалы сызық

Бес әріптің алдында олардың бәрін билейтін бір ереже тұр — SOLID-тің жүрегінде «жалғыз жауапкершілік» тұрғаны сияқты:

AI сен әлдеқашан меңгергенді істейді. Сен әлі үйреніп жүргеніңді істейсің. Сызық сен өскен сайын жылжып отырады.

Меңгерілген бөлікті AI-ға бер — сонда жылдамырақ боласың, бұл таза ұтыс. Әлі қалыптастырып жүрген бөлігіңді AI-ға берсең — оны мүлде қалыптастырмайсың; өзіңе тіпті қажет болмаған жылдамдық үшін шеберлікпен төлейсің. Төмендегі әр қағида — сол сызық бүгін сен үшін қай жерде тұрғанына адал болып қалудың амалы ғана.

CRAFT — бес қағида, бір қысқарту

Жоғарыдан төмен қарай оқығанда, әріптер — жұмыс ағыны: алдымен өзіңе сын таста, AI бергенді өшпенділікпен тексер, не емес, неге деп сұра, әдейі кедергі жаса және шынымен түсінгеніңді тексер.

C — Challenge First

Қағида. AI-ды ашпас бұрын, есепті 5–15 минут өзің шешіп көр. Беттегі бірінші шешім сенікі болуы керек — тіпті олқы болса да. AI сені бөгеуден шығару үшін келеді, ешқашан сенің орныңа бастау үшін емес.

Неге. Ойша модельді дәл осы арпалыс құрады — нейрондар сен тұрып қалғанда тұтанады, дайын жауапты оқып отырғанда емес. Бұл — бұрын шындық тегін жасайтын дәл сол кедергі; енді оны өзің жоспарлауың керек.

R — Review Adversarially

Қағида. Кодыңды AI тексермейді — AI-дың кодын сен тексересің. Әр жасалған жолды багты, шеткі жағдайды, қауіпсіздік саңылауын аңдып оқы.

Неге. Пайымдау — инженериядағы ең төзімді дағды әрі модельдер күшейген сайын құндырақ бола түсетін жалғыз дағды. AI-ды тексеру оны қайрайды және модельдер жасауды жақсы көретін сенімді қателерді ұстайды. Дифті оқымай қабылдау екеуін бірден бұзады.

A — Ask Why, Not What

Қағида. AI-ды сенің орныңа жазатын жасырын автор ретінде емес, ұстаз ретінде пайдалан. Дайын үзіндіні ғана емес — пайымдауды, баламаларды, ымыраларды сұра.

Неге. «Не» саған балық береді; «неге» қармақ береді. «Кодты бер» артыңда ештеңе қалдырмайды. «Неге басқа емес, осы тәсіл, әрі бос кірісте не бұзылады?» деген сені бұрынғыдан бір саты ақылдырақ қалдырады.

F — Friction on Purpose

Қағида. Шындық енді сені күш салуға мәжбүрлемейді, сондықтан қарсылықты өзің қайта қос. Тұрақты түрде AI-сыз жаттығулар жаса — көмекшісіз, нөлден бастап бірдеңе құрастыр. Кодты қоюдың орнына қайта тер. AI-ды жауып, ол саған жаңа ғана үйреткенді өзің қайта жаңғырт.

Неге. Дағды тек қажетті қиындық арқылы бекиді. Көшіріп-қою жадта із қалдырмайды; сол жолдарды баяу қайта теру — қалдырады. Кедергі жылдамдыққа салынған салық сияқты сезіледі — шын мәнінде бұл дағдыны тым болмаса сақтап қалудың құны.

T — Test Your Understanding

Қағида. Басты қақпа — бір ғана сұрақ: мен мұны басқа адамға жол-жолымен түсіндіре алар ма едім? Егер жоқ болса — код саған тиесілі емес, оны шығармайсың. Іске қоспас бұрын нәтижесін болжа; әдейі бұзып, қайта жөнде.

Неге. «Жұмыс істейді» деген «түсінемін» деген емес — дәл осы алшақтық құзыреттілік елесі болып табылады, әрі дағдыдан айырылу дәл осы жерде жасырынады. Өз түсінігіңді тексеру — бір күні құралсыз жұмыс істей алмайтын күйде оянудан сақтайтын ең арзан сақтандыру.

CRAFT қысқаша

Өзіңді тексер: өсіп жатырсың ба, әлде тозып жатырсың ба?

Қай бағытта бара жатқаныңды білу үшін зерттеу қажет емес. Мына жағдайда тозып жатырсың:

• AI-сыз сол нәрсенің қарапайым нұсқасын жаза алмайсың.
• Біреу сұраса, түсіндіре алмайтын кодты қоясың.
• Көмекші сөндірулі күйде жұмыс істеу ойынан-ақ мазасызданасың.
• AI шығысын оқуды қойып, жай ғана қабылдай саласың.
• Үзіндіні іске қоспас бұрын оның не істейтінін болжай алмайсың.

Мына жағдайда өсіп жатырсың:

• AI сені шынымен түсінетін нәрселерде жылдамдатады.
• Модельдің қателерін жүйелі түрде ұстайсың.
• Онсыз да әлі жұмыс істей аласың — баяуырақ, бірақ істей аласың.
• Оны жаңа тұжырымды үйрену үшін пайдаланып, сосын сол тұжырымды көмексіз қайта жаңғыртасың.
• Нені беріп, нені өзіңде қалдыратыныңды саналы түрде шешесің.

Егер бір-ақ әріп алсаң

T-ні ал. Түсіндірілу қақпасы — мұны жол-жолымен түсіндіре алар ма едім? — бүкіл әдістемедегі ең қарапайым әдет, әрі жалғыз өзі тозудың шамамен 80%-ын ұстайды. CRAFT-тағы қалғанының бәрі сол қақпадан адал өтуді жеңілдете түседі.

Қорытынды

Оқуда түбегейлі ештеңе өзгерген жоқ. Саналы түсіну әрқашан маңызды болды; жаттап алу әрқашан нашар алмастырғыш болды. Өзгергені — орта сол айырманы сенің орныңа енді мәжбүрлеп ұстамайды. CRAFT — оны өзіңе-өзің мәжбүрлеп ұстатудың амалы ғана.

Ойын ережелері сол қалпында. Тек ойын қатерлірек болды — оңай жол енді табыстың бетпердесін киіп алды.

Егер осының бәрінің артындағы диагнозды әлі оқымаған болсаң, AI мен жоғалған кері байланыс туралы алдыңғы жазбадан баста. Ол — дерт туралы еді; бұл — ем.

Бұл "үйрену керек пе, жоқ па" деген емес. Бұл нақты нені AI-ға беріп, нені өзіңде қалдыратының туралы. Әрі AI шынымен өзгерткен бір нәрсе туралы — "бәрі аударылып түсті" деген бағытта емес, әлдеқайда нәзік бағытта: мәжбүрлі кері байланыс жоғалды, оны бұрын шындықтың өзі сенің орныңа істейтін еді.

Екі шеткі көзқарас — екеуі де біржақты

Алдымен әр талқыда қылтиятын екі даурыққан лагерьден үстелді тазалап алайық:

• 1-лагерь: "Тілдерді үйренудің керегі жоқ — AI жазып береді". Ең қатты айқайлайтындар — "30 күнде AI-мен бағдарламашы бол" деген буткемптерді сататындар.
• 2-лагерь: "Бәрі топастанады, бірер жылда мамандар қалмайды". Ең қатты айқайлайтындар — кіші мамандардың қаншалық тез өнімді көрінетінінің алдында өз дәрменсіздігінен сәл сескенетін тәжірибелілер.

Жалған дихотомия. Түбінде іргелі ештеңе өзгерген жоқ: әрдайымғыдай, құрғақ жаттау емес, саналы түсіну бағаланады. AI тек шынымен білетіндер мен қалғандардың арасындағы алшақтықты тереңдетеді — әрі мұны бұрынғыдан жылдам істейді.

Дәлелдер базасы не дейді

Бұл енді "маған солай көрінеді" емес. 2025–2026 жылдары нақты өлшемдер пайда болды:

• Nature (2026 маусым), "Is AI ruining our skills?" — AI-ға шамадан тыс сүйену дағдыларды тоздырады. Тек бағдарламашыларда емес — дәрігерлерде де.
• Anthropic RCT, 52 инженерге: AI-көмекші шеберліктің қалыптасуын ~17%-ға төмендетеді. Нәзік тұсы — тапсырманы орындау жылдамдығы емес, дағдының қалыптасуы зардап шегеді. Яғни қысқа мерзімде жылдамсың, ұзақ мерзімде — нашарсың.
• AI & Society: deskilling — дайын шешімі жоқ құрылымдық мәселе. "AI жаман" емес, "құрал оқу ортасын өзгертті".
• TechCrunch: инженерлер AI-сыз жұмыс істеуден бас тартады, өйткені онсыз енді істей алмайды. Тақырыбы: "бұл кейін кері соғуы мүмкін".

Сарапшы K. Crowston-ның қорытындысы (Nature келтіреді) — бұл "AI ма, жоқ па" емес, мынау: қай дағдыларды өзіңде қалдырып, қайсысын беретініңді саналы түрде шеш. Постың қалған бөлігі осы сөйлемге сүйенеді.

Нені беру, нені қалдыру

Нақтырақ — шекара мына жерден өтеді:

Оқи алмайтын нәрсеңе review жасай алмайсың. Сондықтан "тілді білмей түсіну" — елес; бұл AI-ға соқыр сенім. Әрі дәл осы жер "AI пайдаланатын маман" мен "AI операторының" арасындағы өту нүктесі. Біріншісі AI-ды басқарады; екіншісін AI басқарады.

Тағы да үнемі шатастырылатын айырма: дағдыны жоғалту ≠ дағдының қалыптаспауы. Кенет AI-ға сүйене бастаған тәжірибелі маман мықты күйінде қалады — оның дүние моделі бұрыннан бар. Бірінші күннен 100% AI-ға арқа сүйеген жаңадан бастаушы бұл модельді ешқашан құрмайды. Бұл — салдары әртүрлі, әртүрлі мәселелер.

Қалай дұрыс үйрену керек — және неге, түбінде, ештеңе өзгермеді

Үйрену әрі қарай да керек — тек дұрыс. Терминдер мен командаларды құрғақ жаттау емес, логиканы түсініп, оның тұтастай қалай жұмыс істейтінін сезіну. Құндылық "есте сақтауда" емес, "түсіну → қолдана білу → бағалауда".

Ең бастысы: бұл AI-ға дейін де әрдайым болып келген нәрсенің дәл өзі. Әрқашан құрғақ жаттағандар емес, маман ретінде шынымен білетіндер бағаланды. AI ештеңені аударып тастаған жоқ — ол тек жалқау жолды жеңілдетеді (енді түсінбей-ақ "істеуге" болады), сондықтан осы екі типтің арасындағы алшақтық тек тереңдей түседі.

Саналы үйренген — сол күйінде қалады. Жалқау болған — жалқау күйінде қалады. AI бұл бөліністі тудырған жоқ — тек оны жарыққа шығарды.

Қарапайым мысалдармен тексер

• Математика: көбейту кестесін жатқа білу әлі "математиканы білу" емес. Калькулятор бағанмен есептеуді өлтірді, бірақ көбейту дегеннің не екенін және оны қашан қолдану керегін түсіну қажеттілігін өлтірген жоқ.
• Телефондар: нөмірлерді енді басыңда ұстамайсың — телефон есте сақтайды. Бірақ кімге, не үшін қоңырау шалатыныңды білуің керек. Жадты бердің — пайымды қалдырдың.
• GPS: бағыттарды басыңда ұстамайсың. Бірақ қайда бара жатқаныңды түсінуің керек — және GPS сені бір ақымақ айналма жолмен апарып жатқанын байқауың керек.

Үшеуінде де машина механикалық жадты алды, түсіну мен пайымды емес — әрі әрдайым солай болған. AI — сол нәрсенің келесі итерациясы, тек енді тапсыруға болатын ауқым кеңірек.

Синтаксис — қосымша өнім, мақсат емес

Бұл "синтаксисті білудің керегі жоқ" дегенді білдірмейді. Синтаксисті бәрібір игересің — бірақ түсіну мен тәжірибенің қосымша өнімі ретінде, мақсат ретінде емес. Сен %d-ны флешкартамен жаттаған жоқсың ғой — format-string логикасын түсіндің де, ол өзінен-өзі есте қалды. Қалыпты оқу осылай жұмыс істейді: түсінесің → қолданасың → синтаксис өзі орнығады. AI, оны дұрыс пайдалансаң, тек осы циклды жеделдетеді.

Бірақ бір нәрсе шынымен өзгерді: мәжбүрлі кері байланыс жоғалды

"Ештеңе өзгерген жоқ" — бұл шамамен 80% рас. Бір маңызды нәрсе шынымен өзгерді, әрі бұл ұсақ-түйек емес.

Бұрын орта үйренуге мәжбүрлейтін. Жұмыс істейтін кодты кемінде істеуге жарайтындай түсінбей тұрып іске қоса алмайтынсың. Компилятор, баг, құлау — бұлар әркімді күшпен базалық деңгейге тартатын ұстаздар еді. Күрес міндетті болатын — әрі ол онша тырыспайтындардың бойында да түсінік қалыптастыратын.

Енді бұл ұстаз өшірілген: қалай жұмыс істейтінін бірде-бір рет түсінбей-ақ жұмыс істейтін нәтиже ала аласың. Түсінбегені үшін сол сәттегі жаза жоғалды. Осыдан "ештеңе өзгерген жоқ" деген тезис жіберіп алатын салдар туады:

Алшақтық тек бекіген типтердің арасында ғана тереңдеп жатқан жоқ — жаңа орта бұрын үйренетіндерді де сонда тартады, өйткені жалқау жол енді дереу жазасыз жұмыс істейтін нәтиже береді.

Сондықтан "жалқау жалқау күйінде қалады" деген де тым тар. Бұл мінезден гөрі орта мен әдеттер туралы: адамдардың көбі "тумысынан" жалқау емес, үйкеліс пен кері байланысқа жауап береді. Үйкелісті алып таста — үйренуге бейімдер де сырғанайды. Тәуекел тек жалқауларда емес.

Ең нәзігі — біліктілік елесі. AI олқылықтарды соншалық тегіс жамайды, өз надандығыңның қабырғасына соғылмайсың да, оны байқамайсың да. "Бәрі жұмыс істеп тұр" болғандықтан түсінемін деп ойлайсың (metacognitive laziness әсері). Сондықтан тырысқақ болып қалу қиындай түсті: енді бұл өзіңе саналы түрде үйкеліс жасауды талап етеді — кейде AI-ды өшіру, онсыз түсіндіріп немесе жазып көру, "мен шынымен түсінемін бе, әлде түсінемін деп ойлаймын ба" дегенді тексеру. Бұрын мұны сенің орныңа шындық істейтін — енді бұл сенің жауапкершілігің.

Ойын ережелері сол күйінде, бірақ ойынның өзі қулана түсті — жеңіл жол енді табысқа ұқсап бүркенеді.

Әлдеқашан білетіндер үшін — ойын басқаша

Жоғарыдағының бәрі дағдыны нөлден қалыптастыру туралы. Егер сен әлдеқашан қалыптасқан болсаң — сен үшін сурет керісінше, әрі мұны ашық айту маңызды, әйтпесе пост "AI жаман" деп оқылады, ал бұл ондай тезис емес.

Тәжірибелі маман өз шегін біледі. AI не бергенін көреді → жарты секундта қай жері "олай емес", қай жері "иә, бірақ бұл жағдайға емес", қай жері "иә, әрі осы жерде, дәл қазір жарайды" екенін түсінеді. Онда нақты оқиғалардың жылдарынан құрастырылған "мұнда бірдеңе дұрыс емес" деген кірістірілген детектор бар. AI бұл детекторды өшірмейді — керісінше, оны тезірек қоректендіреді: көбірек мысал, көбірек жағдай, тез сүзіп тастайтын көбірек patterns.

Сондықтан жаңадан бастаушыны операторға айналдыру қаупі бар дәл сол AI сениорды турбо-сениорға айналдырады. 3 минуттың орнына 30 секундтық boilerplate. Жаңа кітапхананы зерттеу — бір аптада емес, бір кеште. Модульді Python-нан TypeScript-ке көшіру — "бір кездері кейін" емес, шынымен қолжетімді. Бұл — әлдеқашан жиналған қозғалтқышқа құйылған нитро.

Тағы бір нәзік нәрсе: AI тәжірибелі маманға байқатпай өтірік айта алмайды. AI оған жаңадан бастаушыға қаншалық жиі өтірік айтса, соншалық жиі айтады — тек ол мұны сөйлемді оқып бітпей тұрып ұстап алады. Жаңадан бастаушы үшін біліктілік елесінің тұзағы болатын нәрсе сениор үшін күнделікті ағындағы тағы бір баг-репорт қана.

Уақытын әлдеқашан салғандар үшін AI — турбо. Әлі салмағандар үшін — салмаудың тағы бір себебі. Осы екі күйдің арасында орта жол жоқ — әрі бұл "нақ қашан үйрендің" дегенді мансаптағы ең маңызды факторлардың біріне айналдырады.

Жүйелік тәуекел: "сынған саты"

Сениорлар джуниорлардан шығады. Егер AI джуниор жұмысын жеп қойса әрі ешкім іргетас қаламаса → 5–10 жылдан кейін сениор етіп өсіретін ешкім қалмайды. Мамандардың "жоғалған ұрпағы" тәуекелі шынайы — әрі бұл дүрліктіру емес, қарапайым piping-мәселе: жүйенің кіріс құбыры бітеліп, шығыс құбыры ашық қалды.

Неге бұл нөлге жетпейді (бірақ ауыр тиеді): "бәрі үйренуді тоқтатты" деген тепе-теңдік тұрақсыз. Тапшылық үйренгендерді аса құнды етеді → үйренуге деген ынта қайта оралады. Мамандарды саналы түрде өсіретін компаниялар moat алады. Бірақ өту ауыр: AI анық әрі сенімді өтірік айтқанда, ал айналада шындықты ажырататын ешкім болмағанда, операторлар бірінші елеулі оқиғада құлайды.

Менің ұстанымым

• Тілді үйрену міндетті — жаттауға емес, оқу мен пайымға бағыттап. Жүйрік оқуға апарар жолды қысқарту мүмкін емес; AI бұл жолды қысқартпайды, тек оны байқаусызда қосымша (опциялық) етеді.
• Көпшілік "түсінуді" AI-ға беріп жатқанда — қазір үйрену — мүмкіндік терезесі: AI-мен бәсекелеспей, оны басқаратын тапшы маманға айналасың. Бұл — қысқа мерзімді терезе, нарық ерте ме, кеш пе бейімделеді. Ол ашық тұрғанда — пайдаланбау күнә.
• Сау режим: үйренуден қашу үшін емес, жылдамырақ жүру әрі тереңірек үйрену үшін AI-ды пайдалану. Антипаттерн — "бүкіл тапсырманы менің орныма істеп бер". Паттерн — өзің жазасың, AI "неге" екенін түсіндіреді, ал сен оның нұсқасын қабылдамас бұрын өзің тереңірек түсінесің.
• Жолға арналған парадокс: AI-ды тиімді пайдалану үшін жеткілікті білуің керек, қарапайым нәрседе ол қажет болмайтындай. Қарапайым нәрседе AI-ға тәуелді адам — күрделіде AI-дан алданады, әрі мұны байқауға мүмкіндігі болмайды.

Дереккөздер

• Nature — Is AI ruining our skills? Early results are in (2026 маусым): nature.com/articles/d41586-026-01947-1
• InfoQ — Anthropic study, ~17% skill mastery drop: infoq.com/news/2026/02/ai-coding-skill-formation
• TechCrunch — Coders are refusing to work without AI: techcrunch.com/2026/05/29/coders-refusing-ai
• AI & Society — AI deskilling is a structural problem: link.springer.com/article/10.1007/s00146-025-02686-z

Бірақ бір ай нақты қолданыстан кейін мен сол пост қамтымаған бірнеше елеулі мәселеге тап болдым. Ең үлкені — Claude Code-тың жасырын ерекшелігі, оған кездейсоқ тап болдым: Gmail MCP-ін қосқанымда, ол бес минуттан соң профилімнен "жоғалып кетті". Бүгін мен бәрін жаңа архитектураға қайта құрдым — XDG-үйлесімді, symlink пен gum арқылы интерактивті профиль таңдағышы бар. Бұл — v2, теориялық жақсарту емес, нақты тәжірибеден шыққан эволюция.

Не мазалай бастады

Төрт нәрсе. Алғашқы үшеуі — реттілік, көріну және масштаб туралы. Төртіншісі — бірден байқамаған нағыз архитектуралық тұзақ. Оларды ретімен қарастырамын, өйткені ақыр соңында дәл төртіншісі қайта құруға мәжбүрледі.

1. $HOME-да екі бөлек қалта — бұл былық

~/.claude мен ~/.claude-promova — $HOME түбірінде қатар тұрған екі dotfolder. XDG Base Directory Specification конфигтер ~/.config/ ішінде тұруға тиіс дейді. Тікелей home-да шашылып жатқан dotfile қалталары — уақыт өте $HOME-ды қоқыс тартпасына айналдыратын антипаттерн. Косметикалық, әрине, бірақ ls -la ~ көрген сайын мазалайтын.

2. Белсенді профильдің көрнекі растамасы жоқ

claude-ты іске қосамын да, қай профиль белсенді екенін білмеймін — сессия ішінде claude config list орындағанша. Қай терминалда нені іске қосқанымды ұмытсам, тексеруге тура келетін. Ұсақ нәрсе, бірақ personal + жұмыс екі қойындыда қатар жүргенде ол жиналып қалады.

3. Alias-тар масштабталмайды

Екі профиль — claude мен claude-promova — жарайды. Үшіншісін қосасың (фриланс клиенті) — үшінші alias керек. Төртіншісін — төртіншісі. Жарты жылдан соң қандай alias-тар жасағанымды есіме де түсіре алмас едім.

4. ~/.claude.json ішіндегі жасырын тұзақ

Ал міне, қайта құрудың нағыз себебі осы. Claude Code-та конфигурацияның екі түрлі орны бар, әрі құжаттама бұл туралы айқайламайды: ~/.claude/ — projects/, sessions/, hooks/, skills/ жататын каталог. Әрі бөлек — ~/.claude.json, тікелей $HOME түбіріндегі файл, онда oauthAccount, mcpServers, projects тарихы, skillUsage және нақты live күйдің тағы шамамен 40 өрісі тұрады.

claude mcp add --scope user командасы дәл сол home-түбіріндегі ~/.claude.json-ға жазады, ~/.claude/.claude.json-ға да, профиль каталогына да емес. Мен мұны білмедім. Бір күні тап болғанша.

Ашылу: Gmail MCP неге "жоғалды"

Бүгін таңертең мен Claude Code-та Gmail MCP-ін баптап жатырмын. Әдеттегі баптау: Google Cloud жобасы, OAuth деректемелері, claude mcp add gmail --scope user -- npx -y @gongrzhe/server-gmail-autoauth-mcp. Бәрі жақсы. Сессияны қайта іске қостым — жұмыс істейді, поштаны оқып, хаттарға жауап беріп отырмын. Бір сағаттан соң біз alias-тарды gum профиль таңдағышы бар функцияға рефакторлай бастадық, содан кейін бәрін XDG-ге көшірдік. Мен mv ~/.claude → ~/.config/claude-profiles/personal жасадым, CC-ды қайта іске қостым, мәзірден personal-ды таңдадым. Ал жаңа сессияда /mcp аштым:

figma            (failed)
playwright-test
claude.ai Notion

gmail жоқ. vaultforge жоқ. Тек үш сервер, оның біреуі тіпті failed болған. Ал мен Gmail-ды жаңа ғана қосқам. Сол уақытта басқа терминалдағы сессия (жұмыс профилі) Gmail мен Vaultforge-ті еш мәселесіз көрсетіп тұрды.

Мен қаза бастадым да, машинамда .claude.json деп аталатын үш түрлі файл барын таптым:

Міне, осы. Дәл осы — сол архитектуралық тұзақ:

1. claude mcp add --scope user CLAUDE_CONFIG_DIR-ге қарамастан әрдайым home-түбіріндегі ~/.claude.json-ға жазады
2. CLAUDE_CONFIG_DIR орнатылғанда Claude Code $CLAUDE_CONFIG_DIR/.claude.json-ды оқиды — профиль ішіндегі файлды
3. "user-scope MCP-тер" жазбалары мен "профиль MCP-тері" жазбалары бірдей атаулы бөлек файлдарда тұрады — әрі оларды шатастыру оңай

Менің жағдайымда ~/.claude.json (home-түбір, 113 KB) тірі, өзекті күй болды — gmail, vaultforge, OAuth сессиясы, бәрімен. Ал ~/.config/claude-profiles/personal/.claude.json (29 KB) ескі snapshot болып шықты, ол бұрынырақтан ескі ~/.claude/-та жатқан — бәлкім ескі CC нұсқасы сонда жазған, бәлкім плагин. Екі файлға да jq -r 'keys[]' қолданғанда home-түбірдегі нұсқада snapshot-та жоқ 41 бірегей кілт барын көрсетті.

Ал бұл 41 кілт — қоқыс емес. Бұл — Claude Code-тың нақты күйі:

• skillUsage — skill-дерді қолдану статистикасы
• githubRepoPaths — жоба навигациясына арналған репозиторийлер кэші
• cachedGrowthBookFeatures + cachedStatsigGates — feature flag-тер (оларсыз CC әр іске қосуда жаңасын тартады)
• hasShownOpus45Notice, hasShownOpus46Notice, hasShownS1MWelcomeV2 — UI флагтары (оларсыз модаль терезелер келесі іске қосуда қайта шығады)
• lastPlanModeUse, feedbackSurveyState, installMethod — onboarding және UX күйі

Егер жай ғана mv ~/.claude ~/.config/claude-profiles/personal merge-сіз жасасаң — бұның бәрін жоғалтасың. Welcome модальдары қайта оралады, githubRepoPaths іздеуі қайта жүреді, әрбір сауалнама сұрауы қайта келеді. Мен мұны істей жаздадым.

Жаңа архитектура

Бәрі ~/.config/ ішіндегі бір ата-каталогтың астында тұрады, дәл XDG қалағандай. Әр профиль өзіне-өзі жеткілікті — өзінің .claude.json-ын қоса, толық күйі бар. ~/.claude кері үйлесімділік үшін personal профильге symlink ретінде қалады.

~/.config/claude-profiles/
├── personal/
│   ├── .claude.json          ← full live state + MCP list (113 KB)
│   ├── projects/, sessions/, hooks/, skills/, ...
│   └── CLAUDE.md
└── promova/
    ├── .claude.json          ← work state + work MCPs (41 KB)
    └── projects/, sessions/, agents/, skills/, ...

~/.claude  →  symlink to ~/.config/claude-profiles/personal/

$HOME түбірінде ешқандай .claude.json жоқ. Әр профиль — бәрін ұстайтын бөлек оқшауланған каталог: projects/sessions қалталары да, MCP серверлері мен OAuth токендері бар сол файл да. Профильге бір ғана шындық көзі.

Symlink неге дәл personal-ға бағытталған

~/.claude/ жолын hardcode ететін бәрі — ескі скрипттер, плагиндер, Claude Code IDE кеңейтімдері, claude-powerline.json сияқты statusline конфигтері — өзгеріссіз жұмысын жалғастырады. Symlink personal профильге сілтейді. Егер кездейсоқ command claude-ты (wrapper функциясын айналып өтіп) іске қоссаң — default-жол іздеуі арқылы тағы да personal-ға түсесің. Personal бұрынғысындай "үнсіз default" болады, бірақ енді физикалық түрде XDG орнында тұрады.

Іске қосудағы интерактивті таңдағыш — функция + gum

Alias-тардың орнына — ~/.zshrc ішіндегі claude() функциясы, ол gum (Charm-ның TUI көмекшісі) арқылы көрсеткі пернелермен басқарылатын мәзір көрсетеді. Функция claude шақыруын shell деңгейінде ұстап қалады, профиль таңдауға мүмкіндік береді және сәйкес CLAUDE_CONFIG_DIR-мен command claude-ты іске қосады. Мұнда command маңызды — ол wrapper функциясын айналып өтіп, нақты бинарьді шақырады.

# brew install gum

# Claude Code: profile picker on launch
claude() {
  local profile
  profile=$(gum choose \
    --header "Claude profile:" \
    --cursor "▸ " \
    --selected.foreground 212 \
    --cursor.foreground 212 \
    --header.foreground 244 \
    "personal" "promova") || return
  case "$profile" in
    personal) CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/personal" command claude "$@" ;;
    promova)  CLAUDE_CONFIG_DIR="$HOME/.config/claude-profiles/promova"  command claude "$@" ;;
  esac
}

Іске қосқанда былай көрінеді:

Claude profile:
▸ personal
  promova

↑↓ — жылжу үшін, Enter — таңдау, Esc — бас тарту (сонда Claude жай ғана іске қосылмайды). Профиль әрдайым көрініп тұрады — ұмыту мүмкін емес.

Нөлден бастап (миграциялайтын v1 жоқ)

Егер сен ескі екі-қалта + alias хагін қолданып жүрсең — төмендегі миграция скриптіне өт. Бұл бөлім — нөлден таза құрастыру: жаңа машина немесе қарапайым қолданыстан қалған әдепкі ~/.claude. Алдымен пішінін шеш: бір аккаунт әрі бірнеше профиль (жобаларды және олардың MCP жиынтығын оқшаулау үшін — жиі кездесетін жағдай), әлде профильге шынымен бөлек аккаунттар (жеке vs жұмыс).

1. Каталогтарды орналастыр

# prerequisites
brew install gum jq

# 1. XDG parent for all profiles
mkdir -p ~/.config/claude-profiles

# 2. fold an existing default install in as your first profile (no-ops on a fresh machine)
if [ -d ~/.claude ] && [ ! -L ~/.claude ]; then
  mv ~/.claude ~/.config/claude-profiles/personal
  [ -f ~/.claude.json ] && mv ~/.claude.json ~/.config/claude-profiles/personal/.claude.json
fi

# 3. one directory = one profile
mkdir -p ~/.config/claude-profiles/personal ~/.config/claude-profiles/work

# 4. these files will hold OAuth tokens — lock them down
chmod 600 ~/.config/claude-profiles/*/.claude.json 2>/dev/null

Бір профильге бір каталог, жалғыз XDG түбір-каталогының астында. Егер сен Claude Code-ты бұрын қолданған болсаң, сниппет бұрыннан бар ~/.claude-ты personal ретінде ішіне жинайды әрі онымен бірге home-түбіріндегі ~/.claude.json live күйін де көшіреді; шынымен жаңа машинада бұл жолдар жай ғана ешнәрсе істемейді. Қалғаны — алғаш іске қосқанда өздігінен толатын бос каталогтар — ал chmod 600 маңызды, өйткені бұл файлдарда ақыр соңында OAuth токендері жатады.

2. Әр профильді аутентификацияла

# launch each profile once and authenticate it
CLAUDE_CONFIG_DIR=~/.config/claude-profiles/work claude
#   → run /login in the session, sign in, done.
# Same account for every profile? One /login is enough — macOS keeps it in the
# shared Keychain, so the other profiles are already authenticated.

Әр профильді өзінің CLAUDE_CONFIG_DIR-мен бір рет іске қосып, /login орында. Басты нюанс: егер барлық профиль бір аккаунтты пайдаланса, тек бір рет кіресің — macOS тіркелгі деректемесін Keychain-нің жалғыз ортақ жазбасында сақтайды, сондықтан басқа әр профиль автоматты түрде аутентификацияланады.

Профильге бөлек аккаунттар — қиынырақ жол: Keychain-нің сол ортақ жазбасы бір ғана логинді ұстайды, сондықтан екінші аккаунтпен басқа профильге кіру біріншісін қайта жазып жіберуі мүмкін. Егер бұл сенің жағдайың болса — бір машинада екі Claude аккаунтын іске қосу бөлімінің арнайы нұсқаулығын ұста әрі сенер алдында өзіңнің Claude Code нұсқаңда тіркелгі деректемелерінің оқшаулануын тексер.

3. Symlink пен picker

# personal becomes the default target of ~/.claude (back-compat)
ln -s ~/.config/claude-profiles/personal ~/.claude

# add the claude() gum picker from the architecture section to ~/.zshrc, then:
source ~/.zshrc
claude        # ← now shows the profile menu on every launch

Осы жолды hardcode ететін бәрі жұмысын жалғастыруы үшін ~/.claude-ты personal профильге бағытта, содан кейін жоғарыдағы архитектура бөліміндегі claude() gum picker-ін ~/.zshrc-ге тастап қой. Қайта жүктегеннен кейін claude әр іске қосуда профиль мәзірін көрсетеді — миграцияланған баптаумен бірдей соңғы күй, тек нөлден құрастырылған.

4. Әр профильдің MCP-ін сарала

Соңында, әр профильге тек оған көрінуге тиіс құралдарды ғана бер: сол профильдің settings.json-ында disableClaudeAiConnectors: true қой да, оған не қажет болса, claude mcp add арқылы қайта қос — дәл жоғарыдағы конекторлар бөліміндегідей. Дәл осы он алмастырмалы профильді мақсатқа арнап құрылған он профильге айналдырады.

Миграция скрипті

Мұны оқып отырып, ескі схемадан көшкісі келетіндерге арналған. Ең сыни қадам — екіншісі: ол home-түбіріндегі ~/.claude.json-ды personal профильде бұрыннан бары бар нәрсемен merge жасайды, mcpServers тізімдерін біріктіреді. Бұл қадамсыз профиль MCP-терін де, бүкіл live күйін де жоғалтады.

# 1. Move existing dotfolders into a new XDG-style parent.
#    APFS mv is an inode rename — safe even if claude --resume is open in
#    another terminal, file descriptors stay alive on the same inode.
mkdir -p ~/.config/claude-profiles
mv ~/.claude          ~/.config/claude-profiles/personal
mv ~/.claude-promova  ~/.config/claude-profiles/promova   # rename as needed

# 2. CRITICAL: merge ~/.claude.json (the live state — likely 100+ KB) into
#    the personal profile, unioning mcpServers so no MCP is dropped.
jq -s '.[0] * {mcpServers: (.[0].mcpServers + .[1].mcpServers)}' \
  ~/.claude.json \
  ~/.config/claude-profiles/personal/.claude.json \
  > /tmp/personal-merged.json
mv /tmp/personal-merged.json ~/.config/claude-profiles/personal/.claude.json

# 3. Fix permissions — jq+mv inherits umask (likely 644), but this file
#    holds OAuth tokens. Tighten to 600 immediately.
chmod 600 ~/.config/claude-profiles/personal/.claude.json

# 4. Back up the orphaned home-root file (delete once verified)
mv ~/.claude.json ~/.claude.json.migrated.bak

# 5. Symlink for backward compatibility (statusline configs, IDE plugins,
#    anything that hardcodes ~/.claude/ keeps working unchanged)
ln -s ~/.config/claude-profiles/personal ~/.claude

Рұқсаттар туралы үшінші қадам өз алдына маңызды. jq | mv umask 644-пен (бәріне оқылатын) файл жасайды. Онда OAuth токендері бар. Merge-тен кейін бірден chmod 600 жасау міндетті.

Миграциядан кейін — барлық белсенді Claude сессияларын жауып, қайта аш, shell-ды қайта жүкте (source ~/.zshrc немесе жаңа терминал), claude-ты іске қос, профиль таңда, claude mcp list арқылы бүкіл MCP орнында екенін тексер. Бәрі жақсы болса — ~/.claude.json.migrated.bak-ты өшір. Бірдеңе дұрыс болмаса — қайтару тривиалды: mv ~/.claude.json.migrated.bak ~/.claude.json да symlink-ты алып таста.

Бонус: профиль сайын MCP конекторлары (ұйымың оларды ортақтастырғанда)

Жоғарыдағы архитектура оқшаулаудың екінші осін ашады — әрі дәл осы менің шын мәнінде ең көп қолданатыныма айналды. Егер сенің Claude аккаунтың бір ұйымға тиесілі болса, ұйым қашықтағы MCP конекторларының ортақ жиынтығын тарата алады (Figma, тапсырма трекері, метрика бэкенді, дерекқор шлюзі, CMS…). Claude Code ұйым қосқан әрбір конекторды әрбір сессияға автоматты түрде тартады, өйткені олар сен іске қосқан каталогқа емес, аккаунтқа байланған.

Екі-үш конектормен бұл жақсы. Он жоба мен ондаған ұйым конекторымен бұл жарамай қалады: әр сессия өзі мүлдем тиіспеуге тиіс құралдарды жүктейді. Бұл модельдің құрал тізіміндегі шу, бұл бос кеткен контекст, әрі — шын ауыртатын тұсы — сессияға басқа жобаға тиесілі жүйеге қол созуға мүмкіндік береді. B жобасымен жұмыс істеп жатқанда A жобасының конекторы тіпті болмауға тиіс.

Авто-тартуды өшір де, содан соң сарала

Тетік — жалғыз баптау, disableClaudeAiConnectors (Claude Code v2.1.182+). Ол кез келген баптау scope-ында тұрады — оның ішінде профильдің өзіндік settings.json-ында да — сондықтан ол әр CLAUDE_CONFIG_DIR сайын. Оны true қой да, сол профиль ұйым конекторларын автоматты тартуды толық тоқтатады:

{
  "disableClaudeAiConnectors": true
}

Содан кейін тек сол профильге шын қажет конекторларды қайта қосасың. Айқын қосылған серверлерді флаг тиіспейді, сондықтан олар әдеттегідей жүктеледі — нәтижесі профиль сайын сараланған ішкі жиын:

# add back only what this profile uses — writes to the profile's own .claude.json
claude mcp add --scope user --transport http figma  https://<your-figma-connector>/mcp
claude mcp add --scope user --transport http linear https://<your-linear-connector>/mcp

Сол аккаунт, сол ұйым каталогы — бірақ әр профиль тек өз бөлігін көреді, оған қоса саналы түрде қайталайтын ортақ конекторларды (тапсырма трекері әдетте бәрінде тұруға лайық).

Сенер алдында мұны тексердім

Құжаттаманың сөзіне сеніп қалғым келмеді, сондықтан бір профильде таза A/B жүргіздім — сол аккаунт, сол OAuth токені, жалғыз айырмашылық — сол бір settings.json:

profile WITHOUT the flag
  /mcp → Figma, Linear, Grafana, Postgres, Notion, Sentry, …   (entire org catalog)

same account, profile WITH  disableClaudeAiConnectors: true
  /mcp → (nothing auto-loaded)

…then  claude mcp add  Figma + Linear
  /mcp → Figma, Linear                                         (exactly the curated subset)

Ол уәде еткенін тап-тура істейді. Оған арқа сүйемес бұрын білуге тұрарлық екі ескертпе:

• OAuth конекторын қайта қосу бір интерактивті логинді талап етеді. URL-дегі кілт арқылы аутентификацияланатын конекторлар claude mcp add арқылы толықтай автоматты қайтады. OAuth артындағы конекторлар сол профильде оларды алғаш қолданғанда браузерде бір реттік аутентификация сұрайды.
• claude mcp list ұйым конекторларын мүлдем көрсетпейді — тек жергілікті анықталған және айқын қосылған серверлерді. Автоматты тартылғандары тек тірі сессияда /mcp арқылы көрінеді. mcp list олардан "бос" көрінгенде абыржыма.

Не аласың

• $HOME-дағы екі dotfolder орнына бір ата-каталог — XDG-үйлесімді
• Symlink ~/.claude/-ты hardcode ететін бәрімен үйлесімділікті сақтайды
• Әр профиль өзіне-өзі жеткілікті — оның толық күйі мен MCP-тері өзінің .claude.json-ында тұрады
• Профильге бір ғана шындық көзі — home-түбіріндегі профильдікінен үнсіз ажырап бара жатқан жетім конфиг енді жоқ
• Сезімтал деректердің (oauthAccount, токендер) рұқсаттары кепілді түрде 600
• Әр іске қосуда белсенді профильдің көрнекі растамасы — қай профиль белсенді екенін ұмыту мүмкін емес
• Үшінші профиль қосу = функцияның case-іне бір жол қосу, жаңа alias клондап, оның атын жаттау емес

Кемшін тұстары

Ашығын айтқым келеді. Бұл — тегін жақсарту емес; онымен бірге бірнеше ымыраға келу де келді, әрі оларды алдын ала білген жөн.

• gum — қосымша тәуелділік (brew install gum, ~13 MB). Егер оны орнатқың мүлдем келмесе — zsh-тегі select-ке немесе қарапайым read-ке қайтуға болады. Жұмыс істейді, бірақ сондай әдемі көрінбейді әрі көрсеткі пернелермен навигация жоқ.
• Әр іске қосуда бір Enter басу. claude-ты күніне ондаған рет іске қосатындарға бұл ашуландыруы мүмкін. Балама төменде (direnv).
• ~/.claude → personal symlink-і personal-ды default етеді. Жұмыс профилін default ету керек болса, symlink-ты қайта бағыттауға тура келеді (ln -sf). Қиын емес, бірақ бұл "ұмыт та кет, ешнәрсе бұзылмайды" емес.
• Symlink теориялық тұрғыда бұзылуы мүмкін, егер бір құрал ~/.claude.json-ды temp+rename паттерні (write-file-atomic) арқылы атомарлы қайта жазса. Іс жүзінде Claude Code-тың өзі олай істемейді, бірақ үшінші тарап плагиндерін орнатсаң — тексер.
• Егер профильдерде түрлі жоспарлы түрлі Anthropic аккаунттарың болса — ауысқаннан кейін Claude Code OAuth күйін синхрондап жатқанда секундтан аз кідіріс болуы мүмкін. Менің қолданысымда байқалмайды, бірақ ол нөл емес.

Қарастырған баламаларым

direnv — әр жобаның түбіріндегі .envrc негізінде CLAUDE_CONFIG_DIR-ды автоматты орнатады. Нөл интерактив, нөл шерту. Кемшілігі: әр work root-қа .envrc қою керек, ал танылмаған қалтада claude-ты іске қоссаң — default профильді аласың (ол қалағаның болмауы мүмкін). Аз ғана work root-та тұратын әрі ешқашан ештеңе шерткісі келмейтіндер үшін direnv шынымен жақсырақ.

Symlink негізіндегі ауыстыру (~/.claude symlink-ын қайта бағыттау арқылы бір ғана белсенді профиль) — оны да қарастырдым да, бірден бас тарттым. Түрлі профильді екі терминалды бір мезгілде ашық ұстай алмайсың — жаһандық "ағымдағы" біреу-ақ. Мен үшін бұл — deal-breaker.

Қорытынды

v2 — жай ғана v1 үстіндегі жақсырақ UX емес. Бұл — Claude Code-та жасырын архитектуралық ерекшелік бар екенін мойындау (~/.claude.json — home-түбіріндегі бөлек файл, оған --scope user командалары CLAUDE_CONFIG_DIR-ге қарамастан жазады), әрі профильдер арасында нағыз оқшаулау керек болса, оны ескеруге тура келеді. Бірінші тәсіл (~/.claude + ~/.claude-promova + alias) 80%-ға жұмыс істеді, бірақ қалған 20% профильдер арасындағы күйдің үнсіз ығысуы түрінде көрінді. Енді ол ескерілген. Егер жаңа бастап жатсаң — бірден v2-ден баста. Егер v1-де отырсаң — миграция скрипті жоғарыда, көшу бес минут алады да, ештеңе бұзбайды (дәл jq merge — сені күйден айырылудан құтқаратын қадам).

Екі ереже менің галлюцинацияға толы жұмыс ағындарымды сенімді пайплайндарға айналдырды: бір агент — бір мамандану және shell командасы ретінде орындалатын кез келген нәрсе shell командасы ретінде орындалуы тиіс. Бұл теория емес. Бұл — менің Claude Code-пен күнде істейтін ісім, әрі шын мәнінде нәтиже беретін паттерндер осылар.

Неге жалпы бейінді агенттер өтірік айтады

LLM — келесі токенді болжайтын жүйе. Промпт екі рөлді сұрағанда — X-ті құрастыр және X-ті тексер — модель бірінші рөлді аяқтайды да, екіншісінің шығысы қалай көрінетінін оны шын орындамай болжайды. Өзін-өзі тексеру құрылымдық тұрғыдан әлсіз: сол контекст, сол модель, сол соқыр аймақтар. Тексерудегі өтті құрастырудағы өтті дегенмен корреляцияланады — олар бірге сәтсіздікке ұшырайды.

Модель өзінің өтірік айтып жатқанын білмейді. Оның көзқарасы бойынша мен бәрін мұқият тексердім дегені мен кодты жаздым дегеннің дәйекті жалғасы. Сенімдісің бе? деген промпттердің галлюцинацияларды ұстай алмайтын себебі де осы: модель екінші жүрісте де дәл сондай сенімді. Сенімділік дұрыстықпен емес — келесі сөйлемнің қаншалықты сенімді естілетінімен корреляцияланады.

Шешім — жақсырақ промпт емес. Абай бол, қайта тексер, галлюцинация жасама — бұл нұсқаулар ештеңе бермейді. Шешім құрылымдық: агентті физикалық тұрғыдан жалған сыңай таныта алмайтындай етіп мамандандыр және сандық жұмысты shell арқылы жүргіз, сонда жауап токен ықтималдығынан емес, нақты күйден келеді.

1-ереже: бір агент — бір мамандану

Жұмысты бөлек контексттері бар бөлек агенттерге бөл. Әр агентте жалғыз жауапкершілік пен тар құралдар жиыны бар. Бүкіл ағын шеңбер бойымен жүгіретін бір агенттің орнына эстафетаға айналады:

• Builder агенті: spec-ті алады, кодты жазады. Оның бар жұмысы осы. Оның Read, Edit, Write, Bash құралдары бар.
• Reviewer агенті: spec-ті және diff-ті алады, қабылдау критерийлерін тексереді. Таза контекст. Кодтың қалай жазылғанын білмейді — тек не шыққанын ғана. Оның Bash, Read, Grep, Glob құралдары бар — жазу құралдары мүлде жоқ.
• Analytics агенті: сұрауларды құрастырып әрі орындау арқылы деректер туралы сұрақтарға жауап береді. Тек Bash. Нақты команданы орындамай жауапқа жете алмайды.
• Оркестратор: әр агентті кезекпен жіберетін және бір агенттен ешқашан екіншісінің жұмысын істеуді сұрамайтын негізгі сессия.

Нақты мысал: UI жүзеге асыру плюс Figma макетіне қарсы визуалды тексеру. Builder компоненттерді жазады да, diff-ті commit жасайды. Одан кейін оркестратор reviewer-ді дизайн URL-імен, diff-пен және нақты қабылдау критерийлерімен шақырады. Reviewer Playwright-ты іске қосады, скриншоттар түсіреді, оларды эталонмен салыстырады және нақты скриншот жолдары мен пиксель айырмашылықтарымен PASS немесе FAIL қайтарады. Builder тексеру қадамына мүлде жақындамайды — тексерудің шынайы болатын себебі де нақ осы.

Анти-паттерн — бұл мега-агент: осы UI-ды құрастыр да, оның макетке сәйкес келетініне көз жеткіз дейтін жалғыз промпт. Кепілдік беремін — ол бәрі сәйкес келеді деп хабарлайды. Сәйкес келмейді. Мен тексердім деген баяндау — бұл жай ғана мен құрастырдым дегеннен кейінгі ең ықтимал токендер тізбегі.

2-ереже: әрдайым промпттың орнына shell

Сандық барлық нәрсені, нақты күйге қатысты барлық нәрсені, жауабы дұрыс көрінгенімен қате болуы мүмкін барлық нәрсені — sh арқылы жүргіз. Агенттің жұмысы — команданы құрастырып орындау, содан соң оның шығысын оқу. Ақиқат көзі агент емес. Shell шығысы.

• Санау: wc -l logs.txt — шындық. Модельден шыққан шамамен 47 лог жолы бар дегені — галлюцинация.
• Analytics: psql -c "SELECT count(*) FROM events WHERE created_at > now() - interval '30 days'". Көлемін бағала емес.
• Тесттер: pnpm test --reporter=json | jq '.numFailedTests'. Не сәтсіз болғанын қорытында емес.
• Git күйі: git rev-list --count main..HEAD, git diff --stat. Коммиттерді сана немесе өзгерістерді сипатта емес.

Мұны бойыңа сіңіргеннен кейін агент санды ойдан шығаруға дайындалған әрбір орынды байқай бастайсың. Мұнда шамамен 200 жазба бар сияқты... — жоқ. SELECT count(*) орында. Тесттердің көбі өтеді... — жоқ. Тест жиынтығын іске қос, JSON-ды талда. Модель команданы құрастыруда керемет. Ал команданың өзі болуда сенімсіз.

Өзім тап болған сәтсіздік режимдері

Бұлар — болжамды мысалдар емес. Паттернді өзгертпей тұрып, олардың әрқайсысы маған нақты уақытыма шығын әкелді:

• Елес тексеру. Агент мен 14 бөлімнің бәрін макетпен салыстырып тексердім деді. Ол макетті ашпады. Скриншот түсірмеді. Тексеру — баяндаудағы галлюцинацияланған қадам болды.
• Сенімді айтылған қате сандар. Analytics деректерінен monthly active users сұрадым. Шамамен 3× қателескен сан алдым. Модель нақты сұрауды орындаудың орнына үлгі жолдардан интерполяция жасады.
• Ойдан шығарылған файл өзгерістері. Агент мен config/feature-flags.json файлын жаңарттым деді. Жаңартқан жоқ. Ол тек ниеттенген еді. git diff бос болды.
• Жалған тест жүгірулері. Барлық тесттер өтеді. Бірде-бір тест орындалмады. Агент test runner-ді ешқашан шақырмады — ол runner шығысының қалай көрінетінін болжады.

Төртеуі де сол екі ережемен шешіледі: агентті бөл, shell-ге ысыр. Reviewer-де Write жоқ, сондықтан ол файлдарды жалған өңдей алмайды. Analytics агентінде тек Bash бар, сондықтан ол сұраудан келмеген санды қайтара алмайды. Құрылымдық мүмкін еместік ізгі ниеттерді әрдайым жеңеді.

Мұны Claude Code-та қалай құрылымдау керек

Claude Code .claude/agents/*.md ішінде анықталатын sub-agent-тарды қолдайды. Әр агент файлы атауды, сипаттаманы, рұқсат етілген құралдар жиынын және жүйелік промптты жариялайды. Оркестратор (сенің негізгі сессияң) оларды Agent құралы арқылы жібереді. Мен reviewer үшін қолданатын анықтаманың түрі мынадай — қысқа, тар және код жазуға физикалық тұрғыдан қабілетсіз:

---
name: reviewer
description: Reviews a diff against acceptance criteria. Cannot edit code.
tools: Bash, Read, Grep, Glob
---

You are a strict code reviewer. You receive:
- A diff (already produced by the builder)
- Acceptance criteria

Your job:
1. Run the build, the tests, the linter — through Bash.
2. Read the changed files directly.
3. Compare the actual behavior to the criteria.
4. Report PASS or FAIL with concrete evidence (command output, file excerpts).

You must NOT:
- Trust the builder's summary
- Assume anything was verified just because it was claimed
- Mark something PASS without running the actual check

Құралдар жиынына назар аудар: Bash, Read, Grep, Glob. Write жоқ, Edit жоқ, Agent жоқ. Reviewer командаларды орындай алады, файлдарды оқи алады, паттерндерді іздей алады — басқа ештеңе жоқ. Егер ол галлюцинацияланған diff-ті тексерілген деп өткізуге әрекеттенсе, оның құрал шақыруларының пішіні мұны айқын көрсетеді: нақты тексерулер болмаған. Құрал шақыруларын аудиттеп, нақ не тексерілгенін көре аласың.

Оркестрация паттерні: негізгі сессия Builder-ді шақырады → күтеді → нақты өзгерісті қармау үшін git diff-ті өзі орындайды → Reviewer-ді spec-пен және diff-пен шақырады → үкімін оқиды. Негізгі сессия бір агенттен ешқашан екеуін де істеуді сұрамайды. Құрал шектеулері промпт нұсқауларынан күштірек: тексеруді жалғандама — бұл тілек. Write-тың болмауы — бұл факт.

Тастау керек анти-паттерндер

Промпттерде көретін, ешқандай әсері жоқ — немесе одан да жаманы, жалған қауіпсіздік сезімін беретін нәрселер:

• Абай бол және жұмысыңды қайта тексер. Ешқандай қосымша мінез-құлық тудырмайды. Модель мұқият жұмысқа ұқсайтын нәрсені бұрыннан-ақ шығарады.
• Шынымен тексергеніңе көз жеткіз. Шынымен деген сөз модель әрекет ете алатын семантика қоспайды. Ол шынымен тексердім деп мәлімдейді.
• Галлюцинация жасама. Prompt engineering мемі. Галлюцинация — модель өшіре алатын ауыстырғыш емес.
• Агентке кіші сандарда сену. Дәл кіші сандарда ол ең сенімді түрде өтірік айтады. Адалдықтың табалдырығы жоқ.
• Адалдықты мәжбүрлеу үшін промптқа қосымша ережелер қосу. Құрылымдық түзетулер (бөлу + shell) промпт өзгертулерін әрдайым жеңеді. Егер ережені орындату қажет болса, оны қазақ тілінде емес, құралдарға қолжетімділікте кодта.

Егер галлюцинацияларды ұстау стратегияң неғұрлым екпінді тұжырымдама болса, сенде стратегия жоқ. Сенде тек үміт бар.

Ойлау моделі

Агент — әріптес емес. Ол функция: prompt → tokens. Функция кодты жазуда керемет, ал дұрыс нәрсе істеген-істемегенін іштей саралауда нашар. Оның өз жұмысы туралы мәлімдемелерін гипотеза ретінде қабылда. Diff, exit коды, скриншот, жолдар саны — міне, дәлелдер осылар. Жүрістің соңындағы қорытынды — бүкіл жүйедегі ең өтірікшіл бет.

Мамандану — баяндаудың ауытқуынан сақтандыруың. Shell — сенің жалғыз ақиқат көзің. Builder жазады. Reviewer тексереді. Bash шешеді.

Қорытынды

Бір нәрсені есте сақтасаң: бір агентке өз шығысын әрі өндіруге, әрі бағалауға жол берме; әрі бірде-бір агентке команданы орындамай сандық сұраққа жауап беруге жол берме. Қалғанының бәрі осы екі ереженің салдары. Құралдарға қолжетімділікті агрессивті түрде баптап, қорытындылардың орнына құрал шақыруларын аудитте — сонда галлюцинация беті барлық жерден өзің қарауды бұрыннан білетін бірнеше нақты орынға дейін тарылады.

Мәселе

Claude Code әдепкіде бәрін ~/.claude ішінде сақтайды — OAuth токенін, әңгіме тарихын, глобалды CLAUDE.md-ты, жоба жадын, MCP серверлерінің конфигурацияларын және баптауларды. Екі тіркелгің болса, саған толықтай оқшауланған екі әлем қажет:

• Жеке тіркелгі: өзіңнің Max/Pro жазылымың, өз қалауларың жазылған жеке CLAUDE.md, өз MCP серверлерің (Obsidian, жеке құралдар)
• Корпоративтік тіркелгі: компания басқаратын жоспар, Jira/Slack интеграциясының нұсқаулары бар жұмыстық CLAUDE.md, компанияның MCP серверлері
• Әртүрлі OAuth сеанстары: бір конфигурация каталогында бірден екі тіркелгіге кіріп отыру мүмкін емес
• Бөлек жоба жады: жұмыс жобаларының контексті жеке сеанстарға немесе керісінше сіңіп кеткенін қаламайсың

Контекст ауысқан сайын шығып, қайта кіру — амал емес. Сеанс күйін жоғалтасың, әрі бұл жай ғана азапты.

Шешім: CLAUDE_CONFIG_DIR

Claude Code бір ғана орта айнымалысын мойындайды: CLAUDE_CONFIG_DIR. Оны кез келген жолға орнатсаң, Claude ~/.claude орнына сол каталогты бәріне пайдаланады — аутентификация, тарих, баптаулар, жады, бәрі-бәрі. Бүкіл орнату 60 секунд алады.

1-қадам: Екінші конфигурация каталогын жаса

Өз қолданысыңа сай мағыналы атау таңда:

mkdir ~/.claude-work

Болды. Claude оны алғаш іске қосқанда қажетті құрылыммен толтырады.

2-қадам: Екінші тіркелгіні аутентификациялап ал

OAuth арқылы кіруді іске қосу үшін Claude-ты жаңа конфигурация каталогымен бір рет іске қос:

CLAUDE_CONFIG_DIR=~/.claude-work claude

Браузер ашылады. Корпоративтік тіркелгіңмен кір. OAuth токені ~/.claude-work ішінде сақталады — ~/.claude ішіндегі жеке сеансыңнан толықтай бөлек.

3-қадам: Shell alias қос

Айнымалыны есте сақтап жүрмеу үшін мынаны shell баптауыңа қос:

alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

Shell-ды қайта жүкте:

source ~/.zshrc

Не аласың

Енді сенде толықтай оқшауланған екі Claude ортасы бар:

• claude — жеке тіркелгіңмен, жеке CLAUDE.md-мен, жеке жадымен іске қосады
• claude-work — корпоративтік тіркелгіңмен, жұмыстық CLAUDE.md-мен, бөлек жадымен іске қосады
• Оқшауланған тарих: жұмыс әңгімелері жұмыста, жеке әңгімелер жеке ортада қалады
• Бөлек MCP серверлері: жеке Obsidian vault-ыңның MCP-і жұмыс сеанстарында көрінбейді
• Тәуелсіз баптаулар: әр тіркелгі үшін рұқсат етілген құралдар, рұқсат деңгейлері және модель қалаулары бөлек

Астыңғы қабатта қалай жұмыс істейді

Конфигурация каталогы — Claude Code күйінің жалғыз шындық көзі. Әрқайсысының ішінде мынау жатыр:

~/.claude/              ← personal account
├── CLAUDE.md           ← personal global instructions
├── projects/           ← personal project memory
├── settings.json       ← personal permissions & MCP servers
└── ...                 ← OAuth session, history, cache

~/.claude-work/         ← corporate account
├── CLAUDE.md           ← company-specific instructions (Jira, Slack, etc.)
├── projects/           ← separate project memory
├── settings.json       ← different MCP servers, permissions
└── ...                 ← separate OAuth session

claude-work іске қосқанда, Claude бәрін ~/.claude-work ішінен оқиды. Ол ~/.claude бар екенін мүлдем білмейді. Екі дана толықтай тәуелсіз — тіпті оларды терминалдың бөлек қойындыларында бір мезгілде іске қоса аласың.

N тіркелгіге дейін масштабтау

Бұл үлгі кез келген тіркелгі санына кеңейеді. Бірнеше тапсырыс берушісі бар фрилансерсің бе? Тағы alias қос:

# Personal (default — no alias needed)
# Just run: claude

# Corporate
alias claude-work='CLAUDE_CONFIG_DIR=~/.claude-work claude'

# Freelance client
alias claude-client='CLAUDE_CONFIG_DIR=~/.claude-client claude'

Әр alias өз конфигурация каталогын, өз OAuth сеансын, тапсырыс берушіге тән нұсқаулары бар өз CLAUDE.md-ын алады. А тапсырыс берушісінің кодтық базасы мен Jira жобасын білетін бір CLAUDE.md, ал Б тапсырыс берушісіне мүлдем басқа CLAUDE.md жасауыңа болады.

Тәжірибелік кеңестер

• Каталогтарды анық атап қой: ~/.claude-work, ~/.claude-clientname — олардың саны үш-төртке жеткенде өзіңе рахмет айтасың
• Әрқайсысына арнайы CLAUDE.md жаз: жұмыстық CLAUDE.md компанияға тән нұсқауларды қамти алады (Jira тикеттерін қалай жасау, қай Slack арналарына сілтеу, деплой процедуралары). Жеке CLAUDE.md жеңіл әрі ықшам күйде қалады.
• Әр тіркелгіге бөлек MCP серверлері: жұмыстық құралдарды (Jira MCP, Slack MCP, ішкі API-лер) тек жұмыстық конфигурацияда бапта. Жеке конфигурацияңды таза ұста.
• Қай тіркелгі белсенді екенін тексер: қай тіркелгіде екеніңе сенімсіз болсаң, сеанс ішінде claude config list іске қос — ол конфигурация каталогының жолын көрсетеді

Бұл тәсіл қай жерде әлсіз болады

CLAUDE_CONFIG_DIR тіркелгі бойынша оқшаулайды, жоба бойынша емес. Бір профильдің ішінде Claude сол тіркелгі үшін бұрын тіркеген барлық MCP серверлерін көреді — барлық жобаларың бойынша. Жалғыз өзің жеке қолдансаң, әдетте бұл мәселе емес. Бірақ бір тіркелгінің астында бірнеше өндіріс үшін маңызды жоба пайда болғанда, әсіресе төлем, әкімшілік құралдар немесе инфрақұрылым сияқты қиылысатын салаларда, нақты жобааралық тәуекел туады: жасанды интеллект көмекшісі Б жобасымен жұмыс істеп жатқанда А жобасының құралын шақырып жіберуі мүмкін, әсіресе екеуі де атауы ұқсас операцияларды ұсынғанда.

Профиль үлгісі мен қай тіркелгідемін? деген сұраққа жауап береді. Ол дәл қазір қай жобаның құралдары белсенді болуы керек? деген сұраққа жауап бермейді. Ставкасы жоғары жұмыс үшін тіркелгілер бойынша бөлудің үстіне екінші оқшаулау қабатын қос:

• Тек тіркелгіге ғана емес, әр өндіріс үшін маңызды жобаға жеке профиль: ~/.claude мен ~/.claude-work орнына ~/.claude-work-billing және ~/.claude-work-admin жаса. Әр профиль өзіне шынымен қажет MCP серверлерін ғана көреді.
• .mcp.json арқылы жоба ауқымындағы MCP: жобаның түбіріне тек сол жобаның MCP серверлерін тізетін .mcp.json файлын коммит жаса. Claude сол каталогтан іске қосылғанда оларды өзі қосып алады. Ғаламдық конфигурацияңды барынша ықшам ұста — тек әмбебап құралдар (жазбалар, іздеу), ешқандай өндірістік endpoint жоқ.
• MCP серверлерін бір мәнді етіп ата: admin, billing, mcp-server секілді жалпылама атаулардан аулақ бол. Жоба атауын префикс ретінде қой: acme_billing_prod, acme_admin_stage. Сипаттамалы атау бірдеңе қате контекстен шақырылғалы тұрғанда сені тоқтап ойлануға мәжбүрлейді.
• Әр MCP құрал шақыруын мақұлдамас бұрын қарап шық: *_create_*, *_delete_*, *_charge_* тәрізді шақырулар саналы түрде екінші рет қарауға тұрады. Жаппай автомақұлдаудан ұтқан кез келген жылдамдығың қате жобаның құралы өндіріске бірінші рет атылған сәтте буланып жоғалады.

Жалпы ереже: профильдерді батыл бөл, өндірістік деңгейдегі MCP-ті әдепкі профильден аулақ ұста және жобалар арасындағы құрал атауларының қиылысын рефакторингке тұратын жаман белгі деп есепте.

Қорытынды

Бір ғана орта айнымалысы. Бір ғана alias. Тіркелгілер арасында толық оқшаулау. Ешқандай logout/login биі жоқ, конфигурация қайшылықтары жоқ, контекст ағып кетуі жоқ. Бұл — тым қарапайым болғаны сонша, тіпті көңіліңді қалдыратындай шешім — бірақ дәл осы оны жақсы етеді. Бір рет бапта да, ол жайлы қайтып ешқашан ойлама.

MCP дегеніміз не және неге бұл соншалықты оңай емес

MCP (Model Context Protocol) — Claude-қа сыртқы құралдар мен деректерге жалғануға мүмкіндік беретін Anthropic-тің ашық протоколы. Принципі қарапайым: жергілікті сервер іске қосылады, ол "құралдарды" (tools) ұсынады, ал Claude оларды әңгіме барысында шақырады.

Obsidian үшін теориялық тұрғыда MCP серверлері жеткілікті. Тәжірибеде — әрқайсысының өз мәселелері бар.

Obsidian экожүйесінің басты мәселесі: Obsidian — ресми MCP-сі жоқ жабық қосымша. Қауымдастық бұл олқылықтың орнын толтырды, бірақ әрбір іске асыру өз жолымен жүреді, әрі ешқайсысында "ресми бата" жоқ.

1-әрекет: MarkusPfundstein/mcp-obsidian

Іздеген кезде табылатын алғашқы құрал. GitHub-та 3400 жұлдыз, барлық оқулықтарда бар. Қауіпсіз таңдау сияқты көрінеді.

Қалай жұмыс істейді: Obsidian-дағы Local REST API плагинінің негізіндегі Python сервері. Сервер плагинге HTTPS арқылы жүгінеді, ал плагин операцияларды Obsidian API арқылы орындайды.

Не дұрыс болмады

• 17 ай бойы жаңартылмаған
• 85 ашық issue
• move/rename жоқ — тек read, write, append, delete
• Local REST API-де құжатталған деректер жоғалту багы бар: POST endpoint append кезінде файлды үнсіз қайта жазып жіберуі мүмкін

Рефакторингке жарамайды — бізге файлдарды жылжытып, сілтемелерді сақтау қажет. Әрі қарай жүреміз.

2-әрекет: aaronsb/obsidian-mcp-plugin

Obsidian-ның нативті плагині ретінде жұмыс істейтін нұсқаны таптым. Бұл Obsidian-ның ішкі API-іне тікелей қол жеткізуді білдіреді — backlinks, Dataview, байланыстар графы. Нативті API арқылы move барлық вики-сілтемелерді автоматты түрде жаңартады, өйткені Obsidian мұны өзі өңдейді.

Орнату қиындықтары

• Плагин Obsidian-ның ресми каталогында жоқ (PR валидация қателерімен ілініп тұр)
• BRAT (Beta Reviewers Auto-update Tool) арқылы орнату керек
• Claude Desktop Bearer token-ды UI арқылы тікелей қабылдамайды — плагинде HTTPS-ті қосуға мәжбүр етті
• localhost үшін self-signed сертификат сенім мәселелерін тудырады

Осы айналма жолдардың бәрі арқылы ақыры жалғадым. Негізгі сынақ — vault.move шынымен [[wikilinks]] қайта жазады, керегінше жұмыс істейді.

Өндірісте не дұрыс болмады

Жаппай рефакторингті бастаған кезде (Obsidian-да ондаған қалталарды drag-and-drop + бір мезгілде MCP операциялары), сервер 4+ минутқа қатып қалды. Себебі: плагин Obsidian-ның ішінде жұмыс істейді. Obsidian құрылымның жаппай өзгеруінен кейін мыңдаған файлды қайта индекстегенде, плагин де онымен бірге бұғатталады.

Қорытынды: ашық Obsidian данасына және оның индексіне тәуелділік жаппай операциялар үшін апатты.

3-әрекет: @bitbonsai/mcpvault

Қисынды тұрғыда — бізге Obsidian-ға тәуелді емес сервер керек. Дискідегі файлдармен тікелей жұмыс істейді. @bitbonsai/mcpvault — көптеген шолуларда ұсынылады. Файлдық жүйеге тікелей қол жеткізу, қарапайым баптау (npx @bitbonsai/mcpvault@latest /path/to/vault), 14 құрал. Obsidian-ды ашық ұстаудың тіпті қажеті жоқ.

Орнатпас бұрын бір маңызды жайтты тексердім — move кезінде вики-сілтемелер жаңарады ма. Пайдаланушының пікірін таптым:

Файлдық жүйе коннекторы өзінің Obsidian-да екенін білмейді — ол <code>.md</code> файлдары бар қалтаны көреді, болды. Файл аттарының семантикалық салмақ көтеретінін, әрбір <code>[[wikilink]]</code> қайта атау немесе жылжыту сәтінде бұзылатынын білмейді. Auto-update links тек қайта атау қосымшаның ішінен жасалғанда ғана іске қосылады. Мұны Claude-тан файл аттарын тазалауды сұрағаннан кейін, сілтемелерінің жартысы бұзылған dashboard-қа оралғанда білдім.

mcpvault-тың өз құжаттамасында расталды: PR #101 (wiki link resolution) шолуда, merge жасалмаған. Яғни mcpvault арқылы move vault-тың жартысын бұзады. Жарамайды.

4-әрекет: VaultForge (финал)

blacksmithers/vaultforge — рефакторинг жасайтын AI агенттеріне арнайы жасалған.

Архитектуралық тұрғыда дұрыс

• Тікелей файлдық жүйе — Obsidian-ға тәуелді емес
• Өз wikilink қозғалтқышы — барлық түрлерін (stem, толық жол, alias, embed) жаңартатын [[wikilink]] шешу логикасын іске асырады
• Әдепкіде dry run барлық қиратушы операцияларда — алдымен нені өзгертетінін көрсетеді, содан кейін сіз растайсыз
• 27 құрал бәсекелестердегі 8–14-ке қарсы: batch_rename, update_links, backlinks (әсерді талдау), prune_empty_dirs, frontmatter, smart_search (BM25), vault_themes (TF-IDF clustering)
• MIT лицензиясы, TypeScript, нөл ішкі тәуелділік
• 30 секундта орнату .mcpb арқылы (Claude Desktop үшін one-click extension)

Оқшауланған файлдарда қауіпсіздік сынағы

Айқас сілтемелері бар 4 сынақ файлын жасадым — stem сілтемелер, alias-пен сілтемелер, толық жолмен сілтемелер. Бір файлды ішкі қалтаға жылжытамын:

delta.md → subfolder/delta-renamed.md

VaultForge dry run көрсетті: "1 файл қайта аталады, 3 сілтеме жаңартылады". Шын мәнінде орындадым.

Кейін тексердім — сілтемелердің үш түрі де дұрыс жаңарды. Дәл осы нәрсе бұрынғы барлық құралдарда жетіспеді.

VaultForge-ті қалай орнату керек — түпкілікті нұсқаулық

Егер сізде macOS және Claude Desktop болса:

1-қадам

.mcpb файлын жүктеп алыңыз:

curl -fsSL https://github.com/blacksmithers/vaultforge/releases/latest/download/vaultforge.mcpb \
  -o /tmp/vaultforge.mcpb && open /tmp/vaultforge.mcpb

2-қадам

Claude Desktop кеңейтімді орнату диалогын ашады. Vault-қа абсолютті жолды енгізіңіз — backslash-сыз, қалыпты бос орындармен:

/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/MyVault

3-қадам

Save түймесін басыңыз. Claude Desktop кеңейтімді конфигке автоматты түрде қосады. Қайта іске қосу қажет емес — .mcpb кеңейтімдері автоматты түрде қабылданады.

4-қадам

Тексеріңіз: жаңа чатта сұраңыз: "What is the status of my Obsidian vault?" — totalFiles: 416, totalDirs: 135, ... сияқты бірдеңе қайтуы керек

Obsidian-ның MCP экожүйесі туралы не түсіндім

Біріншіден, "ең танымал" деген "жұмыс істейді" дегенді білдірмейді. MarkusPfundstein/mcp-obsidian-да 3400 жұлдыз бар және ол әдепкі ұсыныс, бірақ ол ескірген әрі негізгі операциялары жоқ.

Екіншіден, нативті плагиннің жасырын құны бар. Aaronsb плагині мінсіз көрінді — graph, Dataview, нативті move. Бірақ жұмыс істеп тұрған Obsidian данасына және оның индексіне тәуелділік оны байыпты жаппай операцияларға жарамсыз етеді.

Үшіншіден, link-engine-сіз тікелей файлдық жүйе — тұзақ. Mcpvault жылдам әрі қарапайым, бірақ "жай ғана файлдарды жылжыту" vault құрылымын бұзады. Сілтемелер файлдық жүйе білмейтін таңылған семантиканы көтереді. Өз wikilink логикасын іске асырмайынша, құрал минаға айналады.

Төртіншіден, оқшауланған деректерде сынаңыз. Қандай да бір құралға жаппай рефакторингті сеніп тапсырмас бұрын — айқас сілтемелері бар 4–5 файлдан тұратын сынақ қалтасын жасап, не болатынын қараңыз. 5 минуттық сынақ backup-тан қалпына келтірудің сағаттарын үнемдейді.

Бесіншіден, vault-тың git-бэкапын ұстаңыз. Бәрінің ішіндегі ең маңыздысы. Vault ішінде бір ғана git init және мерзімді коммиттер — бұл AI агентінің немесе құралдың кез келген қатесінен сақтандыру. Егер бірдеңе бұзылса — git reset --hard бәрін қайтарады.

Қорытынды

Жол бірнеше сағат пен үш сәтсіз әрекетке созылды. Түпкілікті архитектура былай көрінеді:

• VaultForge — негізгі жұмыс құралы. Тікелей файлдық жүйе + өз wikilink қозғалтқышы + 27 құрал = кез келген ауқымдағы тұрақты рефакторинг.
• Git — vault-ты нұсқалау. Кез келген қате үшін тегін қайтару.

Енді осының бәрі неден басталса, соны істей аламын: Claude-тан 400 жазбаны дұрыс PARA архитектурасына реттеуді, қайталануларды біріктіруді, frontmatter қосуды, MOC карталарын құруды сұрай аламын. Әрбір операция қауіпсіз, сілтемелер сақталады, dry run бірдеңе өзгермес бұрын не болатынын көрсетеді.

Егер сіз де өзіңіздің ретсіз Obsidian-ыңызға қарап, AI көмекшісін қаласаңыз — бірден VaultForge-тен бастаңыз. Менің өлі жобалар, beta плагиндер және link-логикасы жоқ файлдық жүйе серверлері арқылы өткен жолымды қайталамаңыз.

Егер әрбір қара құрдым жаңа әлемнің Үлкен Жарылысы болса ше? Бұл мақала біздің әлеміміз шексіз рекурсивті ағаштың бір түйіні болуы мүмкін деген идеяны зерттейді — мұнда қара құрдымдар суб-әлемдерді дүниеге әкеледі, энергия Хокинг сәулеленуі арқылы қайта оралады, ал физиканың іргелі заңдары әлемдер арасындағы байланысты мүмкін емес ету үшін әдейі жасалған.

Қара құрдым = әлем

Идея ой толғау сәтінде туды: жеткілікті масса мен қысым бір нүктеге шоғырланғанда қара құрдым пайда болады. Бұл сингулярлық — шексіз тығыздық, шексіз қисықтық — Үлкен Жарылысты сипаттайтын жағдайларға күдіктенерлік дәрежеде ұқсас.

Егер бұл әртүрлі жақтан қаралған бір оқиға болса ше? Сырттан біз материяны жұтып жатқан қара құрдымды көреміз. Іштен қарасақ — өмірге жарылып шыққан жаңа әлемді. Қара құрдымға құлаған масса мен энергия өзінің жұлдыздары, планеталары және, бәлкім, өз қара құрдымдары бар мүлдем жаңа ғаламның шикізатына айналады.

Біздің әлемдегі әрбір қара құрдым бір әлемді қамтуы мүмкін. Ал біздің әлеміміз аталық әлемнің қара құрдымының ішінде өмір сүруі мүмкін.

Неліктен әлемдер бір-бірімен байланыса алмайды

Міне, ең әсем тұсы: оқиғалар көкжиегінен өткеннен кейін кері қайту жоқ. Жалпы салыстырмалылық теориясы мұны кепілдейді — аталық әлемнің болашағы толығымен оқиғалар көкжиегінен тыс жатыр әрі іштен қол жеткізу мүмкін емес. Суб-әлемнің тұрғысынан алғанда, аталық әлем әлдеқашан аяқталған. Оның бүкіл уақыт сызығы өтіп кеткен.

Бұл — жетілдірілген технологиямен еңсеретін техникалық шектеу емес. Ол кеңістік-уақыттың геометриясының өзіне сіңірілген. Әлемдер бір-бірінен түбегейлі оқшауланған — қашықтықпен емес, уақыт құрылымымен.

Энергия айналымы: қарызға алу мен қайтару

Бірақ энергия жоғалмайды. Хокинг сәулеленуі — қара құрдымдардың баяу буланатын кванттық процесі — таңғажайып айналым жасайды:

1. Аталық әлем қара құрдым жасап, энергияны суб-әлемге береді
2. Суб-әлем өзінің бүкіл өмірлік циклін триллиондаған жыл бойы өткізеді
3. Қара құрдым баяу буланып, Хокинг сәулеленуі арқылы энергияны аталық әлемге қайтарады
4. Аталық әлем өз энергиясын қайтарып алады — үстемесімен қоса

Бұл «үстеме» қызық: физиктер қазір Хокинг сәулеленуі ақпаратты сақтайды деп есептейді. Аталық әлем жай ғана бос энергияны қайтарып алмайды — ол ішінде болған барлық нәрсенің ізін алады. Қалыптасқан әрбір жұлдыз, әрбір планета, сананың әрбір сәті — сәулеленуде кодталған.

Түбіне дейін рекурсия

Егер сіз бағдарламашы болсаңыз, бұл үлгіні бірден танисыз. Бұл — рекурсия. Әрбір әлем аз энергиямен universe() шақырып, суб-әлемдер жасайды, олар өз кезегінде суб-суб-әлемдер жасайды — қара құрдым түзуге энергия жетпей қалғанша, яғни базалық жағдайға дейін.

universe(energy)
  ├── creates black holes
  │     ├── universe(energy - n)
  │     │     ├── universe(energy - n - m)
  │     │     │     └── base case: not enough energy for black holes
  │     │     └── returns energy via Hawking radiation
  │     └── returns energy via Hawking radiation
  └── receives all energy back

Физик Ли Смолин осыған ұқсас идеяны Космологиялық Табиғи Сұрыпталу ретінде тұжырымдады: әлемдер қара құрдымдар арқылы «көбейеді», әрі әрбір ұрпақтың физикалық тұрақтылары сәл өзгеше болады — сансыз циклдар барысында көбірек қара құрдым, көбірек әлем тудыруға оңтайландырылған.

Осы циклде біз қайдамыз?

Біздің әлемге шамамен 13,8 миллиард жыл. Бұл көне болып естіледі, бірақ оның толық өмір ұзақтығы аясында біз небәрі ең басын көріп отырмыз:

Біз әлеміміздің жалпы өмір ұзақтығының шамамен 0,00000000...01% тұсында өмір сүреміз. Жұлдыздар дәуірі — біз көре алатын барлық нәрсе — ең басындағы қысқа жарқыл ғана. Әлемнің шынайы тарихы — қара құрдымдардың суб-әлемдерді жасап, буландыратын баяу да шыдамды дәуірі.

Жоғары өлшемдер туралы мәселе

Осыған дейін талқыланғанның бәрі біздің үшөлшемді түсінігіміз аясында әрекет етеді. Бірақ біздің әлеміміз жоғары өлшемді бір нәрсенің «тілімі» болса, онда қара құрдымдар мен суб-әлемдердің бүкіл рекурсивті ағашы біз қабылдай алмайтын құрылымның көлеңкесі ғана болуы мүмкін.

1884 жылы Эдвин Абботт Флатландия шығармасын жазды — үшінші өлшемді елестете алмайтын екіөлшемді тіршілік иелері туралы әңгіме. Флатландия арқылы өтетін шар үлкейіп, кішірейетін шеңбер түрінде көрінеді. «Флатландықтар» оны математикалық түрде сипаттай алады, бірақ көріп отырғанын ешқашан шынайы түсінбейді. Біз де өз әлемімізге қатысты дәл осындай жағдайда болуымыз мүмкін.

Сана дегеніміз не? Субъективті тәжірибе неге бар? Дэвид Чалмерс мұны «қиын мәселе» деп атады — және бұл біздің өлшемдік ауқымымыздан тыс бірдеңенің әрекет ететінінің ең күшті дәлелі болуы мүмкін.

Бәрі де іргелі деңгейде құлыпталған

Ең таңғаларлық түйсіну — біздің білмейтінімізде емес, керісінше біздің біле алмайтынымызда. Ізденістің әрбір бағыты іргелі кедергіге тіреледі:

• Аталық әлемді көргіңіз келе ме? Оқиғалар көкжиегімен бөгелген
• Сананы түсінгіңіз келе ме? Бөгелген — жүйе өзін толық талдай алмайды (Гёдельдің толымсыздық теоремалары)
• «Бұрын» не болғанын білгіңіз келе ме? Бөгелген — уақыт Үлкен Жарылыстан басталды
• Жоғары өлшемдерді қабылдағыңыз келе ме? Үшөлшемді тіршілік иесінің танымдық шектеулерімен бөгелген

Философ Колин Макгинн мұны танымдық жабықтық деп атайды: кейбір сұрақтар адам санасы үшін деректердің жеткіліксіздігінен емес, сананың өзінің құрылымынан жабық. «Біз әлі білмейміз» бен «біз біле алмаймыз» арасындағы айырмашылық орасан зор.

Қалған жалғыз нәрсе: өзін-өзі жетілдіру

Егер әрбір шығу жолы әдейі бөгелген болса — сыртқа қарай алмасаңыз, артқа қарай алмасаңыз, жоғары қарай алмасаңыз — онда бір ғана бағыт қалады: ішке қарай. Әлем адамды өзіне назар аударуға мәжбүрлеу үшін әдейі құрылған сияқты.

Бұл тұжырым діннен де, философия оқулықтарынан да шыққан жоқ. Ол қара құрдымдардың, рекурсияның, ақпарат теориясының және таным шектерінің логикасын қадағалаудан туындады. Экзистенциалистер, буддистер, стоиктер мен физиктер — бәрі әртүрлі жолмен бір нүктеге келеді: тіршіліктің мәні жай ғана өмір сүріп жатқан тіршілік иесін жетілдіруде болуы мүмкін.

Біз бұған сеніммен емес, физикамен келдік — қара құрдымдардан бастап, рекурсивті әлемдер арқылы, білімнің іргелі бөгеттеріне дейін, жалғыз ашық есікке дейін: жақсырақ болу.

Дереккөздер

• Ли Смолин — Космологиялық Табиғи Сұрыпталу
• Стивен Хокинг — Хокинг сәулеленуі
• Дэвид Чалмерс — Сананың Қиын Мәселесі
• Эдвин Абботт — Флатландия: Көп өлшемді роман (1884)
• Курт Гёдель — Толымсыздық теоремалары

Қарапайым сайттар үшін — портфолио, блог, лендинг, шағын бизнес сайттары — дәстүрлі CMS қажетсіз жүкке айналып барады. Claude Code, Cursor және GitHub Copilot сияқты AI құралдары енді код базасын тікелей өңдей алады, контексті түсінеді, мазмұнды аударады және өзгерістерді git арқылы деплой жасайды. CMS берген абстракция қабаты неғұрлым ақылды интерфейспен — табиғи тілмен — алмастырылып жатыр.

Сіз төлеп жүрген CMS салығы

Әрбір CMS жасырын құнмен келеді. Тек жазылым ақысы ғана емес — әйтпесе қарапайым сайтыңызды орап тұрған тұтас күрделілік экожүйесі:

• Инфрақұрылым: Хостинг жасайтын дерекқор, қолдап отыратын API, қорғайтын басқару тақтасы. Тек WordPress-тің өзі вебтің ~43%-ын және CMS-ке бағытталған шабуылдардың ~90%-ын құрайды.
• Өнімділік: Беттерді динамикалық түрде генерациялау, әр сұрауда API шақырулары, CMS деректерін клиент жағында гидратациялау. Сіздің 3 беттік портфолиоңыз енді SaaS өнімінің архитектурасына ие.
• Жеткізушіге тәуелділік: Мазмұныңыз біреудің дерекқор схемасында тұрады. Contentful-дан Sanity-ге көшу керек пе? Бұл конфигурацияны өзгерту емес, бүтін бір жоба.
• Контексті ауыстыру: Кодты IDE-де өңдейсіз, содан кейін тақырыпты өзгерту үшін браузердегі CMS басқару тақтасына ауысасыз. Мәні бойынша бір операция үшін екі түрлі ойлау моделі.
• Құны: Headless CMS бағасы көбіне API шақырулары немесе мазмұн жазбалары санына қарай өседі. Жеке блогқа айына $99 тұратын мазмұн инфрақұрылымы қажет емес.

Күн сайын 50 адам мазмұн өңдейтін маркетингтік сайт үшін бұл құн ақталады. Ал әзірлеушінің портфолиосы немесе шағын бизнестің лендингі үшін ше? Сіз шалшықтан өту үшін көпір салып жатырсыз.

Не өзгерді: AI кодыңызды түсінеді

CMS-тің болу себебі қарапайым еді: техникалық емес адамдарға (тіпті мазмұн өзгерту үшін кодқа тиіскісі келмейтін әзірлеушілерге де) сайттарды жаңарту үшін көрнекі интерфейс керек болды. Код тым күрделі, тым нәзік, тым оңай сынатын еді.

AI бұл теңдеуді түбегейлі өзгертті. Заманауи AI кодтау құралдары тек автотолықтырып қоймайды — олар жоба құрылымын түсінеді, бар паттерндерді оқиды және контекстке сай дұрыс өңдеулер жасайды. Жұмыс процесіндегі өзгеріс күрт:

# Old workflow: CMS
1. Open browser → log into CMS dashboard
2. Navigate to content → find the right page
3. Edit in WYSIWYG editor → fight with formatting
4. Preview → looks different from production
5. Hit publish → pray the cache invalidates

# New workflow: AI
1. Tell AI: "Change the pricing on the landing page to $29/month"
2. AI edits the file, you review the diff
3. Push to git → deploy

Бұл болжам емес. Дәл қазір оқып отырған осы блог SolidStart-та жұмыс істейді, мазмұны TypeScript файлдарында сақталады. Әрбір мақала — оның ішінде осы да — AI-ға не жазу керегін айтып, нәтижесін тексеріп, git-ке push жасау арқылы жасалды. CMS басқару тақтасы жоқ. Дерекқор жоқ. Мазмұн мен код арасында API қабаты жоқ.

Осы сайттан алынған нақты мысалдар

Бұл сайт 10 тілді қолдайды, блогы бар, OG суреттерін динамикалық түрде генерациялайды, RSS арналары мен sitemap шығарады. Мазмұн қабаты былай көрінеді — таза TypeScript:

// This blog post you're reading right now is a TypeScript file.
// No database. No API. No CMS dashboard.
// Just a typed object that AI can read and edit directly.

export const myPost: BlogPost = {
  slug: "ai-killed-cms",
  date: "2026-04-17",
  translations: {
    en: {
      title: "Why I stopped using a CMS",
      description: "AI understands my codebase better than any CMS UI.",
      content: makeContent(proseEn),
    },
    uk: { /* ... */ },
    de: { /* ... */ },
    // 10 languages — AI translates them all
  },
};

AI арқылы жасайтын, бұрын CMS талап ететін істер:

• Жаңа мақала қосу: "X туралы жаңа мақала жаз, бар посттардың құрылымын ұстан" — AI файлды жасайды, аудармаларын қосады, оны индекске тіркейді
• Лендинг мәтінін жаңарту: "Hero тақырыбын Y-ге өзгерт" — AI керек файлды тауып, жаңартады
• Мазмұнды аудару: "Бағалар бетіне неміс аудармасын қос" — AI ағылшын нұсқасын оқып, сөзбе-сөз емес, мәдени тұрғыдан бейімделген аударма шығарады
• Қатені түзету: "About бетінде қате бар, 'recieve' емес, 'receive' болу керек" — 3 секундта бітті, мағыналы хабарламамен git-ке коммит жасалды

CMS шын мәнінде нені шешті — және AI оны қалай алмастырады

CMS не әкелгені және әрбір мүмкіндік AI жұмыс процесіне қалай сәйкес келетіні жайлы шыншыл болайық:

Басты түйін: git қазірдің өзінде кез келген CMS салғаннан гөрі жақсырақ нұсқаларды бақылау жүйесі. Ал табиғи тіл кез келген WYSIWYG редакторынан жақсырақ интерфейс — өйткені ол тек пішімдеуді емес, ниетті жеткізеді.

Парадигманың ауысуы: код — мазмұн қабаты

Біз инверсияны көріп отырмыз. Жиырма жыл бойы үрдіс мазмұнды кодтан бөлу болды — мазмұнды дерекқорға салу, оны API арқылы ашу, frontend-те рендерлеу. Кодты өңдеу қиын болып, мазмұнға техникалық емес адамдар қол жеткізуі керек болған кезде бұның мәні бар еді.

AI жақсырақ CMS болу арқылы CMS-ті ескіртпеді. Ол кодты басқару тақтасындай қолжетімді ету арқылы CMS-ті ескіртті.

Веб-мазмұнды басқарудың дамуы айқын траекторияны ұстанады:

1. 2000-шы жылдар: Монолитті CMS (WordPress, Drupal) — мазмұн мен көрсетілім бір жүйеде байланысқан
2. 2010-шы жылдар: Headless CMS (Contentful, Strapi) — мазмұн API арқылы бөлінген, frontend фреймворктерімен рендерленеді
3. 2020-шы жылдар: Статикалық сайт генераторлары + Markdown (Hugo, Astro) — мазмұн файл ретінде, деплой кезінде құрастырылады
4. 2025+: Код-мазмұн ретінде + AI — мазмұн типтелген кодта тұрады, AI — өңдеу интерфейсі

CMS әлі де қажет болатын кездер

Бұл "CMS өлді" деген пікір емес. CMS ауқымды деңгейде нақты мәселелерді шешеді. Ол әлі де қажет, егер:

• Үлкен редакциялық командалар: Рөлге негізделген қатынауды, бекіту процестерін және бір мезгілде өңдеуді қажет ететін 10+ мазмұн редакторы. Git merge қақтығыстары — мазмұн редакторы шешетін мәселе емес.
• Жоғары жиілікті мазмұн: Күніне 50+ мақала жариялайтын жаңалық сайттарына git коммиттері емес, оңтайландырылған редакциялық пайплайндар керек.
• Күрделі мазмұн байланыстары: Мыңдаған SKU, өнім нұсқалары мен динамикалық баға белгілеуі бар электрондық коммерция каталогтарына құрылымдалған дерекқорлар қажет.
• Реттеуші талаптарға сай болу: Аудит іздерін, мазмұнды бекіту тізбектерін және заңмен бекітілген тексеру процестерін талап ететін салаларға арнайы жасалған жүйелер керек.

Шекара айқын: егер мазмұн өзгерістеріңіз бірнеше техникалық емес мүдделі тараптардың жоғары жиілікте үйлесуін талап етсе, CMS өз күрделілігін ақтайды. Егер сіз жеке әзірлеуші, шағын команда болсаңыз немесе сағат сайын емес, апта сайын өзгеретін сайтты басқарсаңыз — AI + код қарапайымырақ, жылдамырақ, арзанырақ және сенімдірек.

Болашақ: AI әмбебап интерфейс ретінде

Үрдіс CMS шегінен асып түседі. "Негізгі жүйе тікелей әрекеттесуге тым күрделі" деген себеппен болған әрбір бағдарламалық абстракция қабатын AI сығымдап жатыр. Әкімшілік тақталары, конфигурация UI-лері, дерекқордың көрнекі редакторлары — бұлардың бәрі адам ниетін жүйелік өзгерістерге аударатын интерфейстер. AI бұл аударманы туа біткендей жасайды.

Қарапайым сайттар үшін болашақ әлдеқашан келді. Мазмұныңыз — код. Редакторыңыз — AI. Нұсқаларды бақылауыңыз — git. Деплойыңыз — push. Бүкіл CMS қабаты — басқару тақтасы, дерекқор, API, хостинг — сіздің ниетіңіз бен сайтыңыздың арасындағы аралық бағдарлама (middleware) болды. AI сол аралық бағдарламаға деген қажеттілікті жойды.

Ең жақсы CMS — CMS-тің болмауы. Мазмұнды басқару маңызды емес болғандықтан емес — керісінше, AI кодтың өзін біз бұрын-соңды көрген ең түсінікті мазмұн басқару интерфейсіне айналдырғандықтан.

Perplexity Desktop MCP (Model Context Protocol) коннекторларын қолдайды. Obsidian vault-ыңызға бағытталған ресми @modelcontextprotocol/server-filesystem серверін қосу арқылы Perplexity-ге табиғи тілде жазбаларды оқуды, жасауды және өңдеуді айта аласыз — тікелей чаттан. Плагиндерсіз, кеңейтімдерсіз, көшіріп-қоюсыз.

Мәселе

Perplexity зерттеуде тамаша — ол интернеттен іздейді, дереккөздерді қорытындылайды және сілтемелермен жауап береді. Бірақ осы нәтижелерді Obsidian vault-ыңызға сақтағыңыз келгенде жұмыс процесі бұзылады: мәтінді көшіресіз, Obsidian-ге ауысасыз, қажетті жазбаны табасыз, қоясыз, пішімдейсіз. Әр. Жолы.

"Perplexity to Obsidian" секілді браузер кеңейтімдері экспорттауға көмектеседі, бірақ олар бір бағытты — жасанды интеллект сіздің vault-ыңызды көре алмайды, бар жазбаларды оқи алмайды және қалталар құрылымына сүйеніп нені қайда қою керектігін шеше алмайды.

MCP дегеніміз не?

Model Context Protocol (MCP) — жасанды интеллект модельдеріне жергілікті құралдармен және дерек көздерімен өзара әрекеттесуге мүмкіндік беретін ашық стандарт. Оны жасанды интеллектке арналған USB порт ретінде елестетіңіз — сіз "серверді" (шағын бағдарламаны) жалғайсыз, ал жасанды интеллект жаңа мүмкіндіктерге ие болады. Біздің жағдайда filesystem сервері Perplexity-ге файлдармен жұмыс істеу үшін 14 құрал береді:

Perplexity Desktop (Mac App)
  │
  ├── MCP Connector: "Obsidian Vault"
  │     │
  │     └── @modelcontextprotocol/server-filesystem
  │           │
  │           ├── read_file()      → read any .md file
  │           ├── write_file()     → create or overwrite files
  │           ├── edit_file()      → patch existing files
  │           ├── list_directory() → browse vault structure
  │           ├── search_files()   → find files by pattern
  │           └── ... 14 tools total
  │
  └── Perplexity AI Model
        │
        └── "Save this to my daily note" → calls write_file()

Негізгі түйін: жасанды интеллект моделі файлдарыңызға тікелей қол жеткізбейді. Ол сіздің құрылғыңызда жергілікті түрде жұмыс істейтін MCP сервері ұсынатын құралдарды шақырады. Жасанды интеллекттен деректермен бірдеңе істеуді нақты сұрамайынша, деректеріңіз компьютерден ешқашан шықпайды.

Талаптар

• Perplexity Pro жазылымы (MCP коннекторлары ақылы пайдаланушыларға қолжетімді)
• App Store-дан алынған Perplexity Mac App (браузер нұсқасы емес)
• Mac-та орнатылған Node.js (npx жұмыс істеуі үшін)

Қадамдық баптау

Бүкіл баптау шамамен 2 минут алады:

Команда

Command өрісіне қоятын команда:

npx -y @modelcontextprotocol/server-filesystem "/Users/yourname/Library/Mobile Documents/iCloud~md~obsidian/Documents/Obsidian Vault"

Жолды Obsidian vault-ыңыздың нақты орналасқан жерімен алмастырыңыз. Егер vault iCloud арқылы синхрондалса, жол ~/Library/Mobile Documents/iCloud~md~obsidian/Documents/ астында болады. Тырнақшаларды сақтап қалыңыз — жолда бос орындар болуы ықтимал.

Оны қалай пайдалану керек

Коннектор Running күйін 14 қолжетімді құралмен көрсеткеннен кейін, кез келген Perplexity чатына өтіп, vault-ыңызбен сөйлесе бастаңыз:

> Show me the structure of my Obsidian vault
> Add a new reflection to daily notes/2026-04-12.md: "Started using MCP today"
> Find all notes that mention "meditation"
> Create a new note in concepts/ about quantum computing
> List all files in my ideas/ folder

Жасанды интеллект сіздің vault құрылымыңызды түсінеді, пішімдеу келісімдеріңізді құрметтейді және бар мазмұнмен жұмыс істей алады. Одан тақырыпты интернеттен зерттеп, қорытындыны нақты жазбаға тікелей сақтауды сұрай аласыз — Perplexity іздеуін Obsidian ұйымдастыруымен бір ағында біріктіресіз.

MCP неге басқа тәсілдерден асып түседі

MCP-ге дейін Perplexity мен Obsidian-ды байланыстырудың шектеулі жолдары болды:

Ағымдағы шектеулер

• Тек Mac — Perplexity MCP коннекторлары қазіргі уақытта тек Mac App Store нұсқасында жұмыс істейді
• Obsidian API интеграциясы жоқ — filesystem сервері файлдармен тікелей жұмыс істейді, Obsidian API арқылы емес. Бұл файлдарды жасау кезінде Obsidian плагиндерін (Linter, Templater) іске қоспайтынын білдіреді
• Растау қажет — құпия файл операциялары Perplexity қолданбасында сіздің растауыңызды талап етуі мүмкін — бұл қауіпсіздік функциясы, қате емес

Қорытынды

Бұл баптау Perplexity-ді зерттеу құралынан зерттеу-мен-сақтау құралына айналдырады:

1. Интернеттен зерттеп, бір әңгімеде Obsidian-ге сақтаңыз
2. Жасанды интеллект сіздің vault құрылымыңызды көреді және ұйымдастыру жүйеңізге бейімделеді
3. Қолданбалар арасында ауысу жоқ — бәрі Perplexity чатында болады

Дереккөздер

• Model Context Protocol — official MCP specification
• MCP Filesystem Server — the server used in this setup
• Perplexity Help Center — Local and Remote MCPs for Perplexity
• Perplexity Blog — Everything is Computer

Таң сайын сағат 9:00-де Claude Code CLI утилитасын headless режимінде іске қосатын 6 жолдан тұратын bash-скрипт. Ол 11 бапталатын тақырып бойынша интернеттен жаңалықтарды іздейді, шуды сүзгіден өткізеді және пішімделген markdown-дайджестті iCloud арқылы синхрондалатын Obsidian vault-қа тікелей жазады. Нөл тәуелділік. Барлығы ~100 жол конфигурация.

Мәселе

Әзірлеуші ретінде бірнеше технологиядан хабардар болып отыру — күнделікті салық сияқты. RSS-арналар шулы, Twitter уақытты жеп қояды, ал жаңалық хаттар дәл ағын үстінде терең отырғаныңда келеді. Маған зерттеу жұмысын өзімнің орныма істейтін және нәтижелерді мен әлдеқашан жұмыс істейтін жерде — Obsidian vault-та көрсететін нәрсе керек болды.

Әдеттегі шешім — скрапинг құбырын құру: жоспарлаушы, краулер, NLP-құбыр, дерекқор, хабарландыру қызметі. Бұл сайт өзінің HTML-ын өзгерткенде сынуы мүмкін нәрсе үшін апталап кететін жұмыс. Маған бір түстен кейін құрастыруға болатын нәрсе керек еді.

Архитектура

Бүкіл жүйе — 4 файл және нөл тәуелділік. Міне, ол басынан аяғына дейін қалай жұмыс істейді:

macOS launchd (9:00 AM daily)
  │
  └── digest.sh
        │
        └── claude -p "$(cat prompt.md)" --max-turns 20 --allowedTools Read,WebSearch,WebFetch,Write
              │
              ├── Reads topics.yaml (11 configurable topics)
              ├── WebSearch → finds news for each topic (last 24-48h)
              ├── WebFetch → reads full articles
              ├── Filters noise: old tutorials, promos, AI spam
              └── Write → saves digest to Obsidian Vault
                    │
                    └── ~/Obsidian Vault/digests/2026-04-12.md
                          │
                          └── iCloud sync → available on all devices

Код (толығымен)

Жоба әдейі барынша ықшам етіп жасалған. Әр жол өз орнын ақтайды.

Кіру нүктесі: digest.sh

Бүкіл қосымша — 6 жолдан тұратын bash-скрипт:

#!/bin/bash
DIGEST_DIR="$HOME/Developer/news-digest"

claude -p "$(cat "$DIGEST_DIR/prompt.md")" \
  --max-turns 20 \
  --allowedTools Read,WebSearch,WebFetch,Write

Негізгі жалаушалар: -p Claude-ты headless режимінде іске қосады (интерактивті терминалсыз), --max-turns 20 агентке барлық тақырыпты зерттеуге жеткілікті орын береді, ал --allowedTools агентті тек файлдарды оқумен, интернеттен іздеумен және нәтижені жазумен шектейді.

Ми: prompt.md

Ақыл-ой осында тұрады. Промпт Claude-ты нені іздеу, қалай сүзу және қайда сақтау керектігі туралы нақты нұсқаулықтары бар жаңалық зерттеу агентіне айналдырады:

# News Digest Agent

You are a news research agent. Your job is to find today's most important
and interesting news for a senior frontend developer.

## Instructions

1. Read the topics file at ~/Developer/news-digest/topics.yaml
2. For EACH topic, search the web for news from the last 24-48 hours
3. Filter: only include genuinely new and noteworthy items
4. Write the digest as a markdown file to Obsidian Vault digests/YYYY-MM-DD.md
5. IMPORTANT: Use the Write tool to save the file. Do NOT output to stdout.

## Rules

- Language: Ukrainian for summaries, English for titles and technical terms
- If there's no real news for a topic — SKIP IT ENTIRELY
- Prioritize: releases > breaking changes > security > new patterns > discussions
- Max 5 items per topic, sorted by importance
- Include direct links to sources
- Skip promotional content, generic tutorials, and AI-generated spam

Конфигурация: topics.yaml

Тақырыптар толығымен бапталады — жаңа тақырып қосасың да, ол ертеңгі дайджестке енеді. Әр тақырыптың аты және AI іздеуін бағыттайтын қосымша контексі болады:

topics:
  - name: better-auth
    context: "auth library for TypeScript. New releases, breaking changes"

  - name: Next.js
    context: "GitHub issues, releases, App Router, Turbopack, performance"

  - name: SolidJS
    context: "SolidStart, releases, ecosystem, comparison with React"

  - name: Tailwind CSS
    context: "v4 updates, new utilities, plugins"

  - name: Claude AI
    context: "Anthropic announcements, Claude Code, new models, MCP, API"

  - name: GPT AI
    context: "OpenAI announcements, new models, ChatGPT features"

  - name: React
    context: "React 19+, Server Components, new patterns, ecosystem"

  - name: Apple
    context: "Hardware, software, WWDC, developer tools, Apple Intelligence"

  - name: Notable People
    context: >
      Latest tweets from: Elon Musk, Dario Amodei, Sam Altman,
      Jensen Huang, Andrej Karpathy, Simon Willison, Swyx...

  - name: AI Global
    context: "Major AI news, new models, regulations, open-source AI"

launchd арқылы жоспарлау

macOS-те launchd — қайталанатын тапсырмаларды жоспарлаудың табиғи тәсілі (Linux-тегі cron сияқты). plist-файл скрипттің қашан және қалай іске қосылатынын анықтайды:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN"
  "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>com.news-digest</string>

    <key>ProgramArguments</key>
    <array>
        <string>/bin/bash</string>
        <string>/Users/you/Developer/news-digest/digest.sh</string>
    </array>

    <key>StartCalendarInterval</key>
    <dict>
        <key>Hour</key>
        <integer>9</integer>
        <key>Minute</key>
        <integer>0</integer>
    </dict>

    <key>StandardOutPath</key>
    <string>/Users/you/Developer/news-digest/logs/stdout.log</string>
    <key>StandardErrorPath</key>
    <string>/Users/you/Developer/news-digest/logs/stderr.log</string>

    <key>EnvironmentVariables</key>
    <dict>
        <key>PATH</key>
        <string>/usr/local/bin:/opt/homebrew/bin:/usr/bin:/bin</string>
        <key>HOME</key>
        <string>/Users/you</string>
    </dict>
</dict>
</plist>

Оны launchctl load ~/Library/LaunchAgents/com.news-digest.plist арқылы орнатасың. Скрипт күн сайын сағат 9:00-де іске қосылады, тіпті жүйеден шығып кеткен болсаң да — launchd жүйе оянған кезде өткізіп алынған тапсырмаларды орындайды.

Нәтиже қалай көрінеді

Таң сайын Obsidian vault-та құрылымдалған әрі маңыздылығы бойынша сұрыпталған жаңалықтары бар жаңа markdown-файл пайда болады:

---
date: 2026-04-12
---

# News Digest — 2026-04-12

## Next.js

### Next.js 16.1 Released with Improved Turbopack Caching
Нова версія Next.js 16.1 включає покращене кешування для Turbopack,
що зменшує час холодного старту на ~40%.
[Посилання](https://nextjs.org/blog/next-16-1)

### Critical Memory Leak Fix in App Router
Виправлено витік пам'яті в App Router при частому перемиканні
між динамічними маршрутами.
[GitHub Issue](https://github.com/vercel/next.js/issues/...)

## Claude AI

### Claude Code 1.5 — MCP Server Auto-Discovery
Anthropic випустив оновлення Claude Code з автоматичним
виявленням MCP серверів у проєкті.
[Блог](https://www.anthropic.com/news/...)

Сандармен

Негізгі дизайн шешімдері

• API орнына Claude Code CLI — API-кілттерді, HTTP-клиенттерді басқарудың немесе жауаптарды талдаудың қажеті жоқ. CLI аутентификацияны, құралдарды орындауды және қателерден қалпына келтіруді өз бетінше атқарады
• Email орнына Obsidian — дайджесттерді іздеуге, оларға сілтеме жасауға болады және олар мәңгі сақталады. Олар кіріс жәшігінде тұншығудың орнына менің жазбаларымның қасында тұрады
• cron орнына launchd — launchd macOS-тің табиғи жоспарлаушысы. Ол өткізіп алынған іске қосуларды, журналдауды және орта айнымалыларын таза өңдейді
• Тақырыптарға YAML — жаңа тақырып қосу — 2 жолдық өзгеріс. Кодты өзгертудің қажеті жоқ
• Бос тақырыптарды аттап өту — нақты жаңалық болмаса, бөлім мүлдем қосылмайды. Толтырғышсыз, жасанды созылған мазмұнсыз

Өзіңдікін қалай құрастыруға болады

Оны 10 минутта іске қоса аласың:

1. Claude Code CLI орнатып, аутентификациядан өт
2. Репозиторийді клонда: git clone https://github.com/oleksiimazurenko/news-digest
3. topics.yaml-ты өз қызығушылықтарыңмен, ал prompt.md-ты сақтау жолыңмен өңде
4. plist-файлды өз пайдаланушы атыңмен және жолдарыңмен өңдеп, содан кейін оны launchctl load жаса
5. Сағат 9:00-ді күт — немесе bash digest.sh арқылы қолмен тексер

Қорытынды

Бұл жобадағы ең қызық нәрсе — онда жоқ нәрселер. Дерекқор жоқ, API-сервер жоқ, Docker-контейнер жоқ, npm-пакеттер жоқ, Python virtualenv жоқ, HTML-парсер жоқ, NLP-құбыр жоқ. Тек промпт, тақырыптар тізімі және барлық ауыр жұмысты AI-агентке тапсыратын 6 жолдық скрипт.

AI-агенттермен құрастыру тәжірибеде осылай көрінеді: сен нені және қайда екенін анықтайсың, ал агент қалай екенін атқарады. Әзірлеудің жалпы уақыты шамамен 2 сағат болды, оның ішінде сүзу сапасын дұрыстау үшін промптпен жүргізілген итерациялар бар.

Дереккөздер

• news-digest on GitHub — full source code
• Claude Code Documentation — headless mode and CLI flags
• Apple Developer — creating launchd jobs
• Obsidian — markdown knowledge base

next-themes тема жыпылықтауын (FOUC) болдырмау үшін React Client Component ішінде <script> тегін рендерлейді. React 19 енді бұл туралы ескертеді — әрі оны басудың ешқандай жолы жоқ. Кітапхана 2025 жылдың наурызынан бері жаңартылмаған. Шешім: next-themes орнына Zustand store + useServerInsertedHTML қолданып, скриптті React ағашынан тыс инъекциялау. Нөл жаңа тәуелділік. Нөл FOUC. Нөл ескерту.

Мәселе

Егер сіз next-themes кітапханасын Next.js 15+ және React 19 нұсқаларымен қолдансаңыз, әр бет жүктелген сайын консольде мына қатені көресіз:

Encountered a script tag while rendering React component.
Scripts inside React components are never executed when rendering on the client.
Consider using template tag instead.

src/providers/theme-provider.tsx (7:10) @ ThemeProvider

Бұл гидратация сәйкессіздігі емес. Бұл — клиентте React компоненттері рендерлеген <script> тегтері ешқашан орындалмайтыны туралы React 19-дың айқын ескертуі. Скрипт SSR кезінде жұмыс істейді (ол HTML ішінде бар), бірақ React оны қате деп белгілейді.

Неге бұлай болады

next-themes React гидратациялаудан бұрын <html> элементіне дұрыс тема класын орнатуы қажет — әйтпесе қате теманың жыпылықтауы пайда болады. Ол үшін ол React.createElement арқылы inline <script> инъекциялайды:

// next-themes renders a <script> inside a Client Component
return React.createElement(Provider, { value },
  React.createElement("script", {
    suppressHydrationWarning: true,
    dangerouslySetInnerHTML: { __html: `(...theme init code...)` }
  }),
  children
)

React 19 өз әрекетін өзгертті: компоненттер ішіндегі script тегтері енді айқын белгіленеді. React 19-ға дейін бұл үнсіз еленбейтін. Скрипттегі suppressHydrationWarning пропы көмектеспейді — ол гидратация ескертулерін басады, ал «компонент ішіндегі script» ескертуін емес.

Біз нені сынап көрдік (және неге сәтсіз болды)

Шешімді табу алдында біз әрбір тәсілді жүйелі түрде сынап көрдік:

Шешім: Zustand + useServerInsertedHTML

useServerInsertedHTML — бұл HTML-ды SSR ағынына React компоненттер ағашынан тыс инъекциялайтын Next.js хук. Скрипт HTML ішіне түседі, бірақ React оны клиенттік рендеринг кезінде ешқашан «көрмейді» — сондықтан ешқандай ескерту жоқ. Реактивті тема күйі үшін Zustand store-мен біріктірілгенде, біз тәуелділіксіз толық алмастырғышқа қол жеткіземіз.

Ол қалай жұмыс істейді

SSR (server):
  useServerInsertedHTML → injects <script> into HTML stream
  ↓
  Browser receives HTML with theme script already in it
  ↓
  Script runs BEFORE React hydrates → correct class on <html>
  ↓
  No flash. No mismatch. No warning.

Client (after hydration):
  useEffect → _init() → Zustand store syncs with localStorage
  ↓
  useTheme() → reactive theme state for components

1-қадам: Zustand store

Store тема күйін басқарады, DOM-ға класстар қолданады, жүйелік теманы анықтауды өңдейді және қойындылар арасында синхрондайды. _init() әдісі useEffect ішінде қолдануға арналған тазалау функциясын қайтарады:

import { create } from "zustand";

const STORAGE_KEY = "theme";
const MEDIA_QUERY = "(prefers-color-scheme: dark)";

function getSystemTheme(): "light" | "dark" {
  return window.matchMedia(MEDIA_QUERY).matches ? "dark" : "light";
}

function applyTheme(resolved: string, disableTransition: boolean) {
  const d = document.documentElement;

  if (disableTransition) {
    const style = document.createElement("style");
    style.appendChild(
      document.createTextNode(
        "*,*::before,*::after{transition:none!important}"
      )
    );
    document.head.appendChild(style);
    window.getComputedStyle(document.body);
    setTimeout(() => document.head.removeChild(style), 1);
  }

  d.classList.remove("light", "dark");
  d.classList.add(resolved);
  d.style.colorScheme = resolved;
}

interface ThemeState {
  theme: string;
  systemTheme: "light" | "dark";
  resolvedTheme: string;
  setTheme: (theme: string) => void;
  _init: (disableTransition: boolean) => () => void;
}

export const useThemeStore = create<ThemeState>((set, get) => ({
  theme: "system",
  systemTheme: "light",
  resolvedTheme: "light",

  setTheme: (newTheme) => {
    const { systemTheme, disableTransitionOnChange } = get();
    const resolved = newTheme === "system" ? systemTheme : newTheme;
    localStorage.setItem(STORAGE_KEY, newTheme);
    applyTheme(resolved, disableTransitionOnChange);
    set({ theme: newTheme, resolvedTheme: resolved });
  },

  _init: (disableTransition) => {
    const stored = localStorage.getItem(STORAGE_KEY) || "system";
    const system = getSystemTheme();
    const resolved = stored === "system" ? system : stored;

    set({ theme: stored, systemTheme: system, resolvedTheme: resolved });
    applyTheme(resolved, disableTransition);

    // System theme changes
    const mq = window.matchMedia(MEDIA_QUERY);
    const onChange = (e: MediaQueryListEvent) => {
      const newSystem = e.matches ? "dark" : "light";
      const { theme } = get();
      set({ systemTheme: newSystem,
            resolvedTheme: theme === "system" ? newSystem : theme });
      if (theme === "system") applyTheme(newSystem, disableTransition);
    };
    mq.addEventListener("change", onChange);

    // Cross-tab sync
    const onStorage = (e: StorageEvent) => {
      if (e.key !== STORAGE_KEY || !e.newValue) return;
      const system = getSystemTheme();
      const resolved = e.newValue === "system" ? system : e.newValue;
      set({ theme: e.newValue, resolvedTheme: resolved });
      applyTheme(resolved, disableTransition);
    };
    window.addEventListener("storage", onStorage);

    return () => {
      mq.removeEventListener("change", onChange);
      window.removeEventListener("storage", onStorage);
    };
  },
}));

export function useTheme() {
  return useThemeStore((s) => ({
    theme: s.theme,
    setTheme: s.setTheme,
    resolvedTheme: s.resolvedTheme,
    systemTheme: s.systemTheme,
  }));
}

2-қадам: ThemeProvider

Provider екі нәрсе жасайды: useServerInsertedHTML арқылы FOUC-тың алдын алу скриптін инъекциялайды және монтаждау кезінде Zustand store-ды инициализациялайды:

"use client"

import { useEffect } from "react"
import { useServerInsertedHTML } from "next/navigation"
import { useThemeStore } from "@/store/use-theme-store"

const THEME_INIT_SCRIPT = `(function(){
  try {
    var t = localStorage.getItem("theme") || "system";
    var r = t;
    if (t === "system") {
      r = window.matchMedia("(prefers-color-scheme: dark)").matches
        ? "dark" : "light";
    }
    document.documentElement.classList.remove("light", "dark");
    document.documentElement.classList.add(r);
    document.documentElement.style.colorScheme = r;
  } catch(e) {}
})()`

export function ThemeProvider({
  children,
  disableTransitionOnChange = false,
}) {
  // Injects script into SSR HTML outside the React tree
  // — prevents FOUC without triggering React 19 warning
  useServerInsertedHTML(() => (
    <script dangerouslySetInnerHTML={{ __html: THEME_INIT_SCRIPT }} />
  ))

  useEffect(() => {
    return useThemeStore.getState()._init(disableTransitionOnChange)
  }, [disableTransitionOnChange])

  return <>{children}</>
}

3-қадам: Layout

import { ThemeProvider } from "@/providers/theme-provider"

export default function RootLayout({ children }) {
  return (
    <html lang="en" suppressHydrationWarning>
      <body>
        <ThemeProvider disableTransitionOnChange>
          {children}
        </ThemeProvider>
      </body>
    </html>
  )
}

4-қадам: Оны қолдану

import { useTheme } from "@/store/use-theme-store"

export function ThemeSwitch() {
  const { theme, setTheme } = useTheme();

  return (
    <button onClick={() => setTheme(
      theme === "dark" ? "light" : "dark"
    )}>
      {theme === "dark" ? "☀️" : "🌙"}
    </button>
  );
}

next-themes-тен көшу

API әдейі бірдей жасалған. Көшу — әр файлда бір ғана импортты өзгерту:

- import { useTheme } from "next-themes"
+ import { useTheme } from "@/store/use-theme-store"

  // API is identical — no other changes needed
  const { theme, setTheme, resolvedTheme, systemTheme } = useTheme()

Салыстыру

Неге басқа баламалар емес?

@wrksz/themes

Ол да useServerInsertedHTML қолданатын тікелей алмастырғыш. Жұмыс істейді, бірақ бұл — бір ғана мейнтейнерден шыққан тағы бір тәуелділік. Егер next-themes бізге бірдеңе үйретсе — тәуелділіктер тасталады. ~100 жол кодпен сіз шешімді толығымен өзіңіздікі ете аласыз.

next-themes@1.0.0-beta.0

npm-де бар, бірақ шығарылым күнінсіз, changelog-сыз және React 19 ескертуі түзетілгені туралы нақты нұсқаусыз. Өндірістік кодты мерзімсіз бета-нұсқаға тігу — алуға тұрарлық тәуекел емес.

Тек CSS (prefers-color-scheme)

Жүйелік теманы анықтауға жарайды, бірақ пайдаланушы таңдауын сақтауды (localStorage), теманы қолмен ауыстыруды немесе «system» опциясын өңдей алмайды. Ол үшін JavaScript қажет.

Қорытынды

1. next-themes нақты түрде тасталған — соңғы шығарылым 2025 жылдың наурызы, React 19 ескертуі түзетілмеген
2. useServerInsertedHTML — React ескертулерінсіз скрипт инъекциялауға арналған дұрыс Next.js примитиві
3. Zustand Context провайдеріне қарағанда азырақ кодпен реактивті тема күйін қамтамасыз етеді
4. Бүкіл шешім — ~100 жол, нөл жаңа тәуелділік, әрі әр жолды өзіңіз иеленесіз

Дереккөздер

• shadcn/ui #10104 — Dark mode guide should address React 19 script warning
• next-themes #296 — React 19 support request (open since 2024)
• React #34008 — Script tags not executing in components (by design)
• @wrksz/themes — Drop-in replacement using useServerInsertedHTML
• Next.js Docs — useServerInsertedHTML API

Біздің қосымша (Promova) Next.js 16-ны Landing Builder — маркетингтік беттерді ~90 түрлі секция компоненттерінен (hero-лар, FAQ-тар, баға, пікірлер т.б.) құрастыратын CMS негізіндегі жүйемен бірге қолданады. Архитектура секция атауларын next/dynamic() шақыруларына сәйкестендіретін sectionRegistry.tsx файлын пайдаланады:

// sectionRegistry.tsx — imports all 90 sections
export const sectionRegistry = {
  HeroSection: dynamic(() => import('./HeroSection/HeroSection')),
  FAQSection: dynamic(() => import('./FAQSection/FAQSection')),
  ReviewsSection: dynamic(() => import('./ReviewsSection/ReviewsSection')),
  // ... 87 more
}

Бір лендинг беті небәрі 5-8 секцияны ғана рендерлейді. Бірақ Lighthouse мынаны көрсетті:

Eliminate render-blocking resources
  94 CSS resources (~330 KB)
  Potential savings: 5,440 ms

Неге? Turbopack барлық 90 import() жолын қолжетімді деп санайды және әрбір SCSS модулі үшін <link rel="stylesheet"> жасайды. Тіпті бетте ешқашан рендерленбейтін секциялардың да CSS-і <head> ішіне енгізіледі. Бұл — Next.js App Router-дің расталған, күтілетін әрекеті. CSS Server Components-тан келетін dynamic() импорттары үшін кодқа бөлінбейді. Мейнтейнерлер мұны FOUC-тың алдын алу үшін жасалған әдейі ымыраға келу деп есептейді. Түзету жоспарланбаған.

Мен сынап көрген барлық әдіс (және неге сәтсіз аяқталғаны)

Мен таба алатын әрбір тәсілді қарастырып, бірнеше күн жұмсадым. Міне толық тізім:

inlineCss тұзағы

Next.js-те барлық <link rel="stylesheet"> тегтерін inline <style> тегтерімен ауыстыратын experimental.inlineCss жалауы бар. Тамаша естіледі, солай ма?

Мәселе мынада: бұл бәрі не ештеңе. Оны маршрут бойынша қосуға болмайды. Егер сізде SSR (force-dynamic) беттер болса, әрбір сұраныс барлық CSS-ті inline түрде қайта құрады. Біз оны сынап көрдік — біздің headless CMS жүктемеге шыдамай, істен шықты. Мұның қауіпсіз жұмыс істеуі үшін беттеріңіздің 100%-ы force-static немесе ISR болуы керек. 20-дан астам SSR беті (аутентификация, бақылау тақталары, динамикалық беттер) болғанда бұл — ауқымды миграция.

Ашылым: Turbopack Import Attributes

Next.js 16.2 шығарылым жазбаларын ақтарып отырып, мен нашар құжатталған мүмкіндікті таптым: Turbopack Import Attributes. Ол TC39 with {} синтаксисін қолданып, нақты бір импорт үшін бұрыннан бар бандлер конвейерін ауыстыруға мүмкіндік береді:

import { cssText, styles } from './hero.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}

Бұл Turbopack-ке былай дейді: "Бұл импортты стиль кестесі ретінде өңдеме. Оны менің арнайы loader-ым арқылы өткізіп, нәтижесін JavaScript ретінде қарастыр."

Бұл — түйінді түсінік. Turbopack рендерлеуді бөгейтін <link rel="stylesheet"> жасаудың орнына, біздің loader SCSS-ті компиляциялап, оны JS жолы ретінде экспорттайды. Содан кейін біз оны компоненттің ішіне тікелей inline <style> тегі ретінде енгіземіз. Нәтиже: бетке нақты рендерленетін секциялардың CSS-і ғана бет HTML-іне түседі. 5 секциясы бар бет 94 емес, 5 секцияға арналған CSS алады.

Шешім

1. Арнайы Turbopack Loader

yarn workspace пакеті ретіндегі ~70 жолдық Node.js скрипті (@promova/scss-to-inline-loader):

const { createHash } = require('node:crypto')
const sass = require('sass')
const postcss = require('postcss')
const postcssModules = require('postcss-modules')
const path = require('path')

const SHARED_STYLES = path.resolve(__dirname, '../shared/styles')

// Same prependData as sassOptions.prependData in next.config.ts
const PREPEND_DATA = `
@use "sass:math" as math;
@use "sass:list" as list;
@use "${SHARED_STYLES}/_variables.scss" as *;
@use "${SHARED_STYLES}/_breakpoints.scss" as *;
@use "${SHARED_STYLES}/_mixins.scss" as *;
`

module.exports = function scssToInlineLoader(source) {
  const callback = this.async()
  processScss(source, this.resourcePath)
    .then((js) => callback(null, js))
    .catch((err) => callback(err))
}

async function processScss(source, resourcePath) {
  // 1. Compile SCSS → CSS (with global variables, mixins, breakpoints)
  const sassResult = sass.compileString(PREPEND_DATA + '\n' + source, {
    loadPaths: [path.dirname(resourcePath), SHARED_STYLES],
    style: 'compressed',
    sourceMap: false,
    url: new URL('file://' + resourcePath),
  })

  // 2. Scope class names with postcss-modules (CSS Modules compatible)
  let classNames = {}
  const result = await postcss([
    postcssModules({
      generateScopedName(name, filename) {
        const file = path.basename(filename, path.extname(filename))
          .replace('.module', '')
        const hash = createHash('md5')
          .update(filename + name)
          .digest('base64url')
          .slice(0, 6)
        return `${file}__${name}__${hash}`
      },
      getJSON(_, json) { classNames = json },
    }),
  ]).process(sassResult.css, { from: resourcePath })

  // 3. Export as JS module — same interface as CSS Modules
  return [
    `export const cssText = ${JSON.stringify(result.css)};`,
    `export const styles = ${JSON.stringify(classNames)};`,
    `export default styles;`,
  ].join('\n')
}

Ол не істейді: styles — стандартты CSS Modules-тегідей аймақталған класс атауларының картасы. cssText — жол ретіндегі компиляцияланған CSS.

2. InlineStyle компоненті

Автоматты дедупликация үшін React 19-дың кірістірілген <style href precedence> API-ін пайдаланады:

export function InlineStyle({ css, id }: { css: string; id: string }) {
  return (
    <style href={id} precedence="default">
      {css}
    </style>
  )
}

React 19 кепілдік береді: бірдей href → DOM-да тек бір <style>. Егер секция бетте екі рет рендерленсе, CSS бәрібір бір рет қана енгізіледі.

3. Компонент бойынша миграция (секциясына ~6 жол)

// BEFORE: Turbopack → <link rel="stylesheet"> (render-blocking)
import styles from './hero_section.module.scss'

// AFTER: Custom loader → JS module → inline <style> (non-blocking)
import { cssText, styles } from './hero_section.module.scss' with {
  turbopackLoader: '@promova/scss-to-inline-loader',
  turbopackAs: '*.js'
}
import { InlineStyle } from '@promova/scss-to-inline-loader/InlineStyle'

export function HeroSection() {
  return (
    <section className={styles.hero}>
      <InlineStyle css={cssText} id="hero-section" />
      {/* ... component JSX, className usage is identical */}
    </section>
  )
}

.module.scss файлдары дәл сол күйінде қалады. CSS-ті қайта жазу жоқ. Stylelint, Prettier, IDE қолдауы — бәрі сақталады.

Неге бұл inlineCss: true-ден жақсы

Міне басты айырмашылық:

inlineCss: true кезінде бет бәрібір БАРЛЫҚ 94 стиль кестесін inline түрде алады — олар жай ғана <link> тегтерінің орнына <style> тегтері. HTML ісінеді. Біздің тәсілмен тек нақты рендерленетін CSS қана HTML-ге түседі. 5 секция рендерленді → 5 <style> тегі. Болды.

Turbopack тұзағы: .module.scss үшін глобалды ережелер жоқ

Мен түскен бір тұзақ: loader-ды глобалды түрде қолдану үшін next.config.ts ішіне Turbopack ережесін қосуға болады деп ойлауыңыз мүмкін:

// ❌ THIS CAUSES A FATAL PANIC
turbopack: {
  rules: {
    '**/components/**/*.module.scss': {
      loaders: ['@promova/scss-to-inline-loader'],
      as: '*.js'
    }
  }
}

Мұны істемеңіз. Turbopack-тің кірістірілген CSS модуль конвейері арнайы ережелер қолданылмас бұрын .module.scss файлдарын ұстап алады. Ол as: '*.js' шығысымен қайшы келетін EcmascriptCssModule активін жасайды, бұл мынаған әкеледі:

FATAL PANIC: inner asset should be CSS processable

with {} атрибуттары жұмыс істейді, өйткені олар Turbopack-ке импорт орнында CSS модуль конвейерін толығымен айналып өтуді тапсырады. Мұны конфигурация арқылы глобалды түрде жасаудың жолы жоқ.

Нәтижелер

Landing Builder бойынша 127 секция компоненті көшірілді. Өндірістік құрастыру тексерілді.

Шектеулер

• Импорт сайын with {} ұзақ-сонар — әрбір импортқа 3 қосымша жол қажет. Оны глобалды түрде қолданудың жолы жоқ (жоғарыдағы тұзақты қараңыз).
• Тек Turbopack — with {} атрибуттарын Webpack қолдамайды. Егер Webpack қосалқы нұсқасы қажет болса, импорттар стандартты CSS Modules-ке қайтады (cssText undefined болады).
• Класс атауларын хештеу — біздің loader Turbopack-тің кірістірілгенінен өзге хештеу алгоритмін қолданады. Класс атаулары DevTools-та басқаша көрінеді. Функционалды тұрғыдан бірдей.
• HTML өлшемі ұлғаяды — CSS бөлек файлдар ретінде кэштелудің орнына HTML ішінде inline болады. CDN-нен берілетін статикалық/ISR беттер үшін бұл мәселе емес.

Мұны қашан қолдану керек

Бұл әдіс мына жағдайларда неғұрлым тиімді:

1. Сізде registry/barrel үлгісі бар — бір файл көптеген компоненттерді импорттайды, бірақ бетте тек бірнешеуі ғана рендерленеді
2. Сіз Turbopack-тесіз — Import Attributes Turbopack-ке тән
3. Сізге компонент бойынша бақылау керек — бәрі-не-ештеңе жалауы емес
4. Сіздің SCSS күрделі — айнымалылар, mixin-дер, breakpoint-тер, ұялау — бәрі қолдау табады
5. Сіз experimental.inlineCss-ті қолдана алмайсыз — өйткені сізде SSR беттер бар немесе егжей-тегжейлі бақылау қалайсыз

Қатысты GitHub Issues

Егер сіз Next.js App Router-дегі рендерлеуді бөгейтін CSS-тен зардап шексеңіз — сіз жалғыз емессіз:

Негізгі мәселе

• #62485 — Render blocking CSS (maintainers: "expected behavior")
• #61066 — Dynamic imports from Server Components are not code-split
• #54935 — Server-side dynamic imports don't split client modules
• #61574 — JS/CSS code splitting doesn't work as documented
• #57634 — Add support for critical CSS inlining with App Router
• #50300 — next/dynamic on server component does not build CSS modules

inlineCss мүмкіндігі және мәселелер

• PR #72195 — experimental: css inlining (the implementation)
• PR #73182 — Don't inline CSS in RSC payload for client navigation
• #75648 — WhatsApp preview broken with inlineCss + Tailwind
• #83612 — Turbopack wrong font URL with inline CSS

Қауымдастық шешім іздеуде

• Discussion #82894 — How to prevent render-blocking with CSS Modules? (2025)
• Discussion #70526 — Ideas for reducing render-blocking CSS
• Discussion #59814 — Render blocking styles with Tailwind
• Discussion #49691 — How to deal with render-blocking modular CSS
• Discussion #59989 — Critical CSS inlining with App Router
• Discussion #80486 — Is optimizeCss still in use?
• Discussion #85465 — Turbopack plugin API (doesn't exist)

Turbopack CSS қателері

• #68412 — Incorrect CSS modules load order with external components
• #76464 — Turbopack sometimes strips SCSS imports
• #82497 — SCSS module not loading when not-found.tsx is present
• #88544 — Exporting Sass variables from CSS modules doesn't work with Turbopack

Миллиондаған пайдаланушыға қызмет көрсететін тіл үйрену платформасы Promova-да жасалған. Егер сіз дәл осындай CSS мәселесімен күресіп жатсаңыз, жоғарыдағы GitHub issue-ларында осы мақалаға сілтеме жасаудан тартынбаңыз.

Next.js жаһандық fetch-ке патч салып, жауап деректеріне босатылуы тиіс болғаннан кейін де сілтемелерді ұстап тұратын кэш қабатын қосады. Әрбір fetch шақыруы GC-ге ешқашан қайтарылмайтын жадты қосады. Docker/Kubernetes-те бұл бірнеше сағат сайын OOM құлауына әкеледі. Бұл қате Next.js 14-тен (2024 жылдың сәуірі) бері бар және 16.2.x-те (2026 жылдың наурызы) әлі шешілмеген. Vercel-де мәселе эфемерлі serverless функцияларының арқасында білінбейді.

Қалыпты fetch қалай жұмыс істейді

Request → fetch → got data → response to user → GC cleans up → memory free

Next.js-те fetch қалай жұмыс істейді

Next.js жаһандық fetch-ті ұстап алып, оны өзінің кэш/трекинг қабатымен орайды:

Request → Next.js fetch wrapper → creates:
  - Performance entry (speed tracking)    ← not cleaned
  - Request metadata object               ← not cleaned
  - Internal promise wrapper              ← not cleaned
  - Cache lookup entry                    ← not cleaned
  - Response body (for unique URL)        ← not cleaned
→ Response to user
→ GC sees objects are still referenced → doesn't touch them
→ Memory grows indefinitely

Продакшнде не болады

Self-hosted (Docker/K8s):
  Request 1:      fetch → +100KB → RAM: 100KB
  Request 2:      fetch → +100KB → RAM: 200KB
  Request 1000:   fetch → +100KB → RAM: 100MB
  Request 50,000: fetch → +100KB → RAM: 5GB → OOM Kill 💀
  → Kubernetes restarts the pod → cycle repeats

Vercel (Serverless):
  Request 1: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  Request 2: [start] → fetch → +100KB → [process dies] → 0 KB ✅
  → Memory never accumulates

Зардап шеккен нұсқалар

Next.js — App Router бар барлық нұсқалар

Node.js

Node.js 20, 22, 24, 25-те сынақтан өтті — барлығында ағады.

Не жұмыс істемейді

Не жұмыс істейді (уақытша шешімдер)

axios уақытша шешімінің шектеуі

Өз API сұрауларыңды axios-пен алмастыруға болады. Бірақ Next.js ішкі түрде патч салынған fetch-ті мыналар үшін пайдаланады:

• ISR (Incremental Static Regeneration)
• revalidatePath / revalidateTag
• Дедупликациямен Server Components деректерін алу
• use cache (Next.js 16)

Яғни кодыңда бірде-бір fetch болмаса да — Next.js оны бәрібір астыртын пайдаланады.

Vercel неге түзетпейді

Бизнес-логика

Vercel — Next.js хостингінен ақша табатын компания. Олардың платформасында мәселе білінбейді (serverless = эфемерлі). Қате тек self-hosted-ке (Docker, K8s, VPS) — яғни Vercel-ге төлемейтіндерге ғана әсер етеді.

Ресми ұстаным

Tim Neutkens (Vercel мейнтейнері) мәселені талдап, бұл Next.js емес, undici-дің (Node.js fetch кітапханасы) мәселесі деп мәлімдеді. Issue #90433 жабылды. Мынаған қарамастан:

• сол Node.js-те axios пен node-fetch ағусыз жұмыс істейді
• Ағу тек fetch Next.js орамасынан өткенде ғана пайда болады
• Қате 2 жыл бойы түзетілмей ашық тұр

Басымдықтар

Осы 2 жылда Next.js командасы мыналарды шығарды:

• Turbopack (2-5x жылдам build) — маркетингтік артықшылық
• Cache Components / use cache — Vercel серверлеріне жүктемені азайтады
• middleware орнына proxy.ts — Vercel-де edge-деплойды жеңілдетеді
• DevTools MCP — AI хайпы

Self-hosted-тегі memory leak? Басымдықта емес.

Шешім: AWS Lambda (SST + OpenNext)

Бұл не

OpenNext — Next.js build-ін AWS Lambda пішіміне түрлендіретін ашық бастапқы кодты адаптер. SST — инфрақұрылымды автоматтандыратын фреймворк.

Архитектура

Next.js build
  → OpenNext
    → AWS Lambda (SSR, API routes)
    → S3 (static, assets)
    → CloudFront (CDN)
    → SQS + DynamoDB (ISR revalidation)

Бұл memory leak-ті неге шешеді

Lambda функциялары сұрауларды өңдейді және 5-15 минут белсенсіздіктен кейін қайта пайдаланылады. Жад жиналып үлгермейді.

Деплой

npx sst@latest init
npx sst deploy --stage production

Салыстыру

Lambda нюанстары

• Cold starts — бірінші сұрау баяуырақ (~200-500ms)
• Қауіпсіздік — OAC (Origin Access Control) қос, әйтпесе Lambda URL ашық болады
• OpenNext — қауымдастық жобасы, ресми Vercel емес. Next.js жаңа мүмкіндіктері бұзылуы мүмкін
• Әмиянға шабуыл — DDoS кезінде Lambda авто-масштабтауы үлкен шотқа әкелуі мүмкін

Неге нақты түзету шындыққа жанаспайды

1. Архитектуралық мәселе

Ағу — кездейсоқ қате емес, дизайн шешімінің салдары: Next.js жаһандық fetch-ті ұстап алып, үстіне кэш/трекинг қосады. Оны түзету үшін — App Router-дің fetch-пен қалай әрекеттесетінін қайта жобалау керек. Бұл ISR, revalidation, data cache, request deduplication-ге — фреймворктің өзегіне әсер етеді.

2. Мүдделер қақтығысы

Vercel өз платформасына әсер етпейтін нәрсені түзетуге ынталы емес. Self-hosted олардың бизнесімен бәсекелеседі. Self-hosted-те мәселе неғұрлым көп болса — соғұрлым көп адам Vercel-ге көшеді.

3. Кінәні аудару

Ресми ұстаным — "бұл undici, біз емес". Ол өзгермейінше — олар түзетумен айналыспайды.

4. Қауымдастық түзетуі жоқ

Next.js-тің AGPL-3.0 лицензиясы форктарға рұқсат береді, бірақ код базасы орасан зор әрі Vercel инфрақұрылымымен тығыз байланысқан. fetch орамасын түзететін қауымдастық PR-ы ішкі архитектураны терең түсінуді және мейнтейнерлердің мақұлдауын талап етер еді — ал олар issue-ді әлдеқашан жапты.

Қорытындылар

1. Егер Vercel-де болсаң — мәселе жоқ, ештеңе істеудің қажеті жоқ
2. Егер self-hosted болсаң әрі serverless керек болса — AWS Lambda-да SST + OpenNext
3. Егер self-hosted Docker болса — мүмкін жерде fetch-ті axios-пен алмастыр, RAM-ды бақыла, под-тарды автоматты қайта іске қосуды баптап қой
4. Егер жаңа жоба бастасаң — осы мәселесіз балама ретінде SvelteKit не Nuxt-ты қарастыр

Дереккөздер

• Issue #64212 — Memory Leak with global fetch (April 2024)
• Issue #68578 — Possible memory leak in Fetch API (August 2024)
• Issue #85914 — Memory Leak with fetch + standalone (November 2025)
• Issue #90433 — OOM in 16.0.10 (February 2026)
• Discussion #88603 — OOM in Docker/K8s (January 2026)
• Discussion #88078 — cacheMaxMemorySize behavior
• OpenNext
• SST — Next.js on AWS
• Secret knowledge to self-host Next.js
• Next.js Memory Usage Guide