ผมเลิกใช้ Claude Fable 5 แบบเดิม ๆ แล้วเปลี่ยนมาจ้างมันทำงานแทน

@gippp69
อังกฤษ2 วันที่ผ่านมา · 13 ก.ค. 2569
137K
116
3
30
150

TL;DR

เปลี่ยนรูปแบบการใช้งาน AI ของคุณด้วยการมองว่า Claude Fable 5 คือพนักงานที่คุณบริหารจัดการได้ กรอบการทำงานนี้ใช้การสลับโมเดลและการตั้งค่าระบบป้องกันอัตโนมัติ เพื่อให้มั่นใจว่างานที่ได้จะมีคุณภาพสูงและคุ้มค่าในเชิงต้นทุน

คุณไม่ได้จัดการพนักงานด้วยการพิมพ์คำสั่งทีละข้อความ คุณให้สัญญาจ้าง ระยะเวลาทดลองงาน และวิธีการวัดว่าพวกเขายังคุ้มค่าเงินเดือนหรือไม่ Fable 5 ก็สมควรได้รับการปฏิบัติแบบเดียวกัน

นี่คือปัญหา Fable 5 สามารถทำงานได้หลายชั่วโมงโดยไม่มีคุณ สร้าง subagent ของตัวเอง และทำงาน backlog ทั้งอาทิตย์ให้เสร็จภายในคืนเดียว มันก็มีค่าใช้จ่ายจริงต่อ token มันทำงานเกินขอบเขตทันทีที่คุณปล่อย scope ไว้ และมันจะปกป้องคำตอบที่ผิดได้ดีกว่ามนุษย์ส่วนใหญ่ปกป้องคำตอบที่ถูก

ถ้าปล่อยไว้โดยไม่จัดการ มันเป็นวิธีที่แพงในการสร้างความไร้สาระที่มั่นใจ แต่ถ้าใส่สัญญาจ้างเข้าไป มันจะเป็นสิ่งที่ใกล้เคียงกับพนักงานประจำมากที่สุดที่คุณสามารถใช้งานได้ในราคาไม่กี่ดอลลาร์ต่อวัน

นี่คือสัญญานั้น ไม่ใช่ทฤษฎี แต่เป็นไฟล์จริง เรียงตามลำดับที่คุณเขียน สร้างขึ้นจากการใช้งานจริง: bots ที่ฉันใช้ตรวจสอบบน VPS ในปารีสผ่าน pm2 อยู่แล้ว Auth flows และ billing tables ไม่ใช่จุดอ่อนของฉัน RPC keys, wallet addresses, และ live blockchain transactions ต่างหาก ระบบด้านล่างนี้สร้างขึ้นเพื่อสิ่งนั้น ไม่ใช่สำหรับ generic SaaS repo

ห้าส่วน แต่ละส่วนส่งมอบหนึ่งไฟล์ เวลาติดตั้งทั้งหมด: ต่ำกว่าสองชั่วโมง

การตั้งค่า

bash
1claude CLI (Claude Code) with Fable 5 access # usage credits, capped
2llm CLI + OpenRouter key # for the cheap models
3jq, git, pm2, cron
4a VPS with the bots already running

สิ่งที่คุณจะได้:

text
1agent-contract/
2 CONTRACT.md # Section 1: the terms of employment
3 ops/
4 shift.sh # Section 3: the daily shift
5 dispatcher.md # routing prompt, Fable only
6 intake.md # cheap reader, reads logs first
7 worker.md # cheap model, does the typing
8 reviewer.md # fresh Fable, checks the work
9 boundaries.md # Section 2: what it can and can't touch
10 guardrails/signoff.sh # Section 2: the deterministic yes/no
11 personnel/
12 trust.tsv # Section 4: who's earned autonomy
13 standing-checks/ # Section 4: things that must stay true
14 incidents/
15 log.tsv # Section 5: what broke and when
16 runbook.md # Section 5: what to do about it
17 Makefile

กฎข้อหนึ่งที่ควรจำไว้ก่อนเริ่ม เพราะมันกำหนดโทนของทุกอย่างหลังจากนี้:

Agent ที่ตรวจการบ้านตัวเองคือ Agent ที่ขึ้นเงินเดือนให้ตัวเอง

ไม่มีอะไรในระบบนี้ที่ตรวจสอบงานของตัวเอง ไม่มีสักครั้ง

ส่วนที่ 1: สัญญา (CONTRACT.md)

สัญญาจ้างพนักงานไม่ใช่รายการคำแนะนำ มันคือตัวเลข จุดหยุดเด็ดขาด และข้อกำหนดที่บังคับใช้ไม่ว่าพนักงานจะเห็นด้วยหรือไม่ก็ตาม เขียนไฟล์นี้ในแบบเดียวกัน ไม่มี "กรุณา" หรือ "พยายาม" โมเดลจะปรับพฤติกรรมตามภาษาที่นุ่มนวล เหมือนที่เด็กฝึกงานปรับตัวตามผู้จัดการที่ไม่เคยตรวจสอบ

markdown
1# CONTRACT.md
2
3## จุดหยุดเด็ดขาด (ไม่มีข้อยกเว้น ไม่ต้องถามซ้ำสอง)
4- ห้ามแตะ wallet keys, .env files, หรือ RPC credentials โดยไม่ได้รับอนุมัติ
5- ห้าม push การเปลี่ยนแปลงไปยัง bot process ที่ทำงานอยู่ (pm2 restart) โดยไม่ผ่าน signoff
6- ห้ามเกิน 150 บรรทัดที่เปลี่ยนแปลงใน commit เดียว โดยไม่ถามก่อน
7- ห้ามอ้างว่างานเสร็จโดยพิจารณาจาก output ของตัวเอง
8 เสร็จหมายถึง signoff script คืนค่า 0 เท่านั้น ไม่มีอะไรอื่นนับว่าเสร็จ
9- ห้ามสร้าง API endpoint, contract address, หรือ config value ขึ้นมาเอง
10 ถ้าไม่มีใน repo ให้หยุดและถาม
11- ห้ามเพิ่ม dependency ใหม่ เขียนใน ops/shift-log.md แล้วหยุดแค่นั้น
12- ห้ามแก้ไขหรือลบ test, alert threshold, หรือ monitor condition เพื่อให้ผ่าน
13 นั่นไม่ใช่การแก้ไข นั่นคือการฉ้อโกง
14- ห้ามรันที่ effort สูงกว่า "high" ภายใน shift "xhigh" สงวนไว้สำหรับการ review
15 แบบครั้งเดียวที่คุณ trigger ด้วยตัวเองเท่านั้น ไม่ใช่สำหรับ automated loop
16- ห้ามบรรยายหรืออธิบายการใช้เหตุผลภายในในการตอบสนอง มันดูเหมือนช่วยเหลือ
17 แต่ใน Fable 5 มันอาจไปกระตุ้น refusal classifier แทน
18
19## การจัดเส้นทางงาน (ใครทำอะไร ถูกที่สุดที่พอทำงานได้ชนะ)
20| model | cost per task | ambition | judgment | taste |
21|------------------|---------------|----------|----------|-------|
22| claude-fable-5 | high | low | 10 | 10 |
23| claude-opus-4-8 | medium | medium | 8 | 9 |
24| claude-sonnet-5 | low | high | 7 | 7 |
25| cheap OSS worker | lowest | highest | 5 | 4 |
26
271. การตัดสินใจว่าจะทำอะไรต่อไป, การ review diff, การตัดสินเมื่อมีข้อขัดแย้ง -> Fable 5,
28 อ่านอย่างเดียว, effort สูง
292. การอ่าน raw logs, dumps, หรืออะไรก็ตามที่เกิน 50k tokens -> cheap worker
30 ห้ามใช้ Fable นั่นคือการจ่ายอัตราผู้บริหารเพื่ออ่านสเปรดชีต
313. อะไรก็ตามที่ผู้ใช้หรือ chain โต้ตอบโดยตรง -> ต้องมีคะแนน taste 8 ขึ้นไปก่อนที่จะส่ง
324. อย่างอื่นทั้งหมด -> sonnet-5, effort ปานกลาง, เลื่อนระดับหนึ่งขั้นถ้าพลาด
33
34## คำจำกัดความ
35- "judgment" = สามารถจัดการสิ่งที่ยากที่สุดบนโต๊ะได้โดยไม่ต้องดูแล
36- "done" = signoff script คืนค่า 0 เต็มสต็อป
37- "small" = ต่ำกว่า 50 บรรทัดที่เปลี่ยนแปลง
38- "cleanup" = พฤติกรรมเหมือนกันทุกประการ signoff เขียวก่อนและหลัง
39
40## คำจำกัดความเดียวของ "done" ที่นับ
41- ทุกงานต้องมีเส้นชัยที่ตรวจสอบได้ด้วยเครื่องก่อนเริ่มงาน
42- Reviewer ที่ไม่เห็นทั้งแผนและร่างจะตรวจสอบ
43- guardrails/signoff.sh มีสิทธิ์ออกเสียงสุดท้าย ไม่ใช่ reviewer สคริปต์ต่างหาก
44- ถ้า worker และ reviewer ไม่เห็นด้วยสองครั้งติดต่อกัน ให้ส่งไปให้มนุษย์
45 ไม่มีความคิดเห็นที่สาม ไม่มี tiebreaker model

เปลี่ยนตัวเลขของคุณเอง อะไรก็ตามที่คุณยอมให้ผ่าน 80% ของเวลาแล้วยังเรียกได้ว่า "เสร็จ" ต้องมีตัวเลขหรือ "ห้าม" ติดอยู่ มิฉะนั้นให้ตัดทิ้ง

ส่วนที่ 2: ขอบเขตและการลงนาม

สัญญาจ้างพนักงานไม่มีความหมายหากไม่มีการตรวจสอบประวัติว่าพวกเขาได้รับอนุญาตให้แตะอะไรได้บ้าง และผู้จัดการที่ลงนามก่อนที่อะไรจะถูกส่งออกไป สองไฟล์

ops/boundaries.md:

markdown
1## ทำงานคนเดียว
2ร่างแก้ไขบน branch; อัปเดต shift-log.md; restart instance *ที่ไม่ใช่ production*
3สำหรับทดสอบ; แจ้งเตือนข้อมูล feed ที่เก่า
4
5## ต้องการลายเซ็นฉัน
6อะไรก็ตามที่อยู่ใต้ wallets/, .env*, config/rpc.json; diff ใดๆ ที่เกิน 300 บรรทัด;
7การเปลี่ยนแปลงใดๆ กับ pm2 process ที่ทำงานอยู่; อะไรก็ตามที่ส่ง transaction
8
9## ปลุกฉันทันที
10reviewer ล้มเหลวในการแก้ไขเดียวกันสองครั้ง; router ส่ง model ที่แตกต่างจากที่ร้องขอ;
11ค่าใช้จ่ายรายวันข้ามเส้น; standing check เปลี่ยนเป็นสีแดง; อะไรก็ตามที่ขอ private key

ops/guardrails/signoff.sh (แก้ไขคำสั่งให้ตรงกับ bots ของคุณ):

bash
1#!/usr/bin/env bash
2set -e
3npm run typecheck --if-present
4npm test --if-present
5pm2 describe "$BOT_NAME" | grep -q "status.*online" || exit 1

รันมันด้วยตัวเองหนึ่งครั้งก่อนที่สิ่งอื่นใดในระบบนี้จะทำงาน ถ้ามันไม่ผ่านอย่างสะอาดบน setup ปัจจุบันของคุณ นั่นคืองานแรกจริงๆ ทุกอย่างที่ตามมาสมมติว่าสคริปต์นี้บอกความจริง

ส่วนที่ 3: กะทำงาน

นี่คือคณิตศาสตร์ที่ทำให้ระบบนี้สำเร็จหรือล้มเหลว เซสชันเต็มที่ Fable 5 เป็นคนพิมพ์ จะมีค่าใช้จ่ายจริงสูงเป็นสี่หลักถ้าคุณปล่อยให้มันเขียนเป็นชั่วโมง Fable 5 ที่เป็นคน ตัดสินใจ ในขณะที่ model ราคาถูกเป็นคนพิมพ์ เป็นบิลที่แตกต่างกันโดยสิ้นเชิง ประมาณ 15-20% ของ tokens สำหรับ 100% ของการตัดสินใจ

ดังนั้นกะทำงานจึงมีพนักงานสี่คน ไม่ใช่หนึ่ง:

  1. Model ที่เกือบฟรีอ่าน overnight logs และ pm2 output บอกว่า "เงียบ" หรือ "ดำเนินการได้" เท่านั้น
  2. Fable 5 อ่านอย่างเดียว ตัดสินใจสิ่งเดียวที่มีมูลค่าสูงที่สุดที่จะทำ และเขียน work order มันไม่แตะโค้ด
  3. Worker model ราคาถูกดำเนินการ work order บน branch ที่แยกออกมา
  4. Fable 5 ชุดใหม่ ที่เห็นเฉพาะ spec และ diff โหวตผ่านหรือไม่ผ่าน

สคริปต์ที่กำหนดไว้ในส่วนที่ 2 เป็นผู้ลงคะแนนชี้ขาด ทุกครั้ง

Gipp 🦅 - inline image

ops/shift.sh:

bash
1#!/usr/bin/env bash
2set -euo pipefail
3cd "$(dirname "$0")"
4DAILY_BUDGET="${DAILY_BUDGET_USD:-5}"
5INTAKE_MODEL="${INTAKE_MODEL:-openrouter/deepseek/deepseek-v4-flash}"
6WORKER_MODEL="${WORKER_MODEL:-openrouter/moonshotai/kimi-k2.6}"
7
8# 1. INTAKE, pennies
9pm2 logs --lines 100 --nostream | llm -m "$INTAKE_MODEL" -s "$(cat intake.md)" \
10 >> shift-log.md
11grep -q "status: actionable" shift-log.md || { echo "quiet shift"; exit 0; }
12
13# 2. DISPATCH, Fable, xhigh, read-only, decides and stops
14claude -p "$(cat dispatcher.md)
15LOG: $(cat shift-log.md)
16TRUST: $(cat personnel/trust.tsv)
17BOUNDARIES: $(cat boundaries.md)" \
18 --model claude-fable-5 --effort xhigh --allowedTools "Read" \
19 --output-format json > /tmp/order.json
20
21SERVED=$(jq -r '.modelUsage | keys[0] // "claude-fable-5"' /tmp/order.json)
22[[ "$SERVED" != *fable* ]] && { echo "rerouted, discard this run" >> shift-log.md; exit 2; }
23
24jq -r '.result' /tmp/order.json > work-order.json
25ACTION=$(jq -r .action work-order.json)
26[[ "$ACTION" == "stop" ]] && exit 0
27[[ "$ACTION" == "queue" ]] && { echo "queued for signature" >> shift-log.md; exit 0; }
28
29# 3. EXECUTE, cheap worker, isolated branch
30BR="shift-$(date +%s)"
31git worktree add "../$BR" -b "$BR" >/dev/null
32( cd "../$BR" && llm -m "$WORKER_MODEL" -s "$(cat "$OLDPWD/worker.md")" \
33 "$(cat "$OLDPWD/work-order.json")" > shift-notes.md )
34
35# 4. REVIEW, fresh Fable, spec and diff only, nothing else
36VERDICT=$(claude -p "$(cat reviewer.md)
37SPEC: $(jq -r .spec work-order.json)
38DIFF: $(cd "../$BR" && git diff)" \
39 --model claude-fable-5 --effort high --allowedTools "" \
40 --output-format json | jq -r .result)
41
42# 5. THE ONLY VOTE THAT SHIPS ANYTHING
43if [[ "$VERDICT" == PASS* ]] && ( cd "../$BR" && "$OLDPWD/guardrails/signoff.sh" ); then
44 echo "PASS, shipped or queued per trust tier" >> shift-log.md
45else
46 echo "FAILED: $BR held for review" >> shift-log.md
47fi

การตัดสินใจที่ทำโดย Fable และโค้ดหนึ่งบรรทัดที่พิมพ์โดย Fable เป็นป้ายราคาสองแบบที่แตกต่างกัน จ่ายราคาที่สูงกว่าสำหรับการตัดสินใจเท่านั้น

ส่วนที่ 4: แฟ้มบุคลากร

ความไว้วางใจไม่ใช่การตั้งค่าทั่วทั้งบริษัท มันต้องได้รับจากแต่ละงาน เช่นเดียวกับที่คุณจะไม่มอบกุญแจ production ให้พนักงานใหม่ในวันแรก ไม่ว่าผลงานพอร์ตโฟลิโอจะดีแค่ไหน

personnel/trust.tsv ติดตามทุกงานที่เกิดซ้ำตามชื่อ: จำนวนครั้งที่รัน, จำนวนครั้งที่ผ่าน, ระดับปัจจุบัน

  • watch: ต่ำกว่า 10 ครั้ง หรืออัตราผ่านต่ำกว่า 90% ร่างเท่านั้น ไม่มีข้อยกเว้น
  • probation: 10-19 ครั้ง ที่ผ่าน 90%+ เข้าคิวรอลายเซ็นคุณ ทุกครั้ง
  • cleared: 20+ ครั้ง ที่ผ่าน 95%+ ส่งได้โดยไม่ต้องมีคุณ
Gipp 🦅 - inline image

การพลาดในงานที่ cleared แล้วไม่ได้รับคำเตือน มันจะตกกลับไปที่ probation ทันที และพิมพ์ไปที่ stderr ซึ่ง cron จะส่งอีเมลถึงคุณ การลดตำแหน่งอัตโนมัติเป็นวิธีเดียวที่ใช้ได้ผลจริง

ครึ่งหลังของแฟ้มบุคลากรคือ personnel/standing-checks/ ทุกงานที่เสร็จสิ้นจะจบการศึกษาที่นี่ในฐานะคำสั่งที่ต้องคงความจริงต่อไปตลอดกาล ตรวจสอบวันละครั้ง:

markdown
1# personnel/standing-checks/bankr-claim-monitor.md
2predicate: pm2 describe bankr-claim-monitor | grep -q "status.*online" && \
3 sqlite3 claims.db "select count(*) from claims where ts > strftime('%s','now','-1 day')" | grep -qv "^0$"
4last-verified: 2026-07-08
5on-violation: wake me, do not auto-restart blind

งานที่คุณตรวจสอบเพียงครั้งเดียวยังไม่เสร็จ มันคือสมมติฐานที่มีประทับเวลา

รันการตรวจสอบทุกวันผ่าน cron predicate ที่ล้มเหลวหมายถึงสิ่งที่เคยเป็นจริงหยุดเป็นจริงไปอย่างเงียบๆ และไม่มีใครสังเกตเห็นถ้าไม่มีไฟล์นี้

ส่วนที่ 5: รายงานเหตุการณ์

นี่คือส่วนที่ playbooks ดั้งเดิมข้ามไป และเป็นส่วนที่สำคัญจริงๆ เมื่อระบบทำงานบนโครงสร้างพื้นฐานที่เคลื่อนย้ายเงินจริง ทุกระบบ agentic ในที่สุดก็จะทำสิ่งที่คุณไม่ต้องการ คำถามคือคุณรู้จาก log ที่สะอาดหรือจากกระเป๋าเงินที่ถูกดูดจนหมด

ops/incidents/runbook.md:

markdown
1| signal | meaning | do this
2|----------------------------------|---------------------------------------|--------
3| exit 2 (rerouted) | model อื่นให้บริการคำขอ | ทิ้ง output นั้นไป ไม่ต้องสร้างอะไรต่อจากมัน ลองใหม่พรุ่งนี้
4| stop_reason: refusal | safety classifier ปฏิเสธ, HTTP 200 | ไม่ใช่ error ให้ตรวจ log; ถ้างานปฏิเสธซ้ำๆ งานนั้นอาจกำลังแตะสิ่งที่มันไม่ควรแตะ
5| signoff fails twice, same fix | worker และ reviewer ไม่สามารถตกลงกันได้ | ดึงเข้าสู่การ review โดยมนุษย์ ไม่ต้องลองซ้ำอัตโนมัติเป็นครั้งที่สาม
6| standing check goes red | สิ่งที่เสร็จแล้วหยุดเป็นจริง | ตรวจสอบวันที่ last-verified, ดู diff ว่าอะไรถูกส่งไปตั้งแต่ครั้งนั้น, อย่า auto-revert
7| daily spend crosses the line | งบประมาณเกิน | หยุด shift, อ่าน shift-log.md, หาว่าขั้นตอนไหนที่บานปลาย
8| a task touches wallets/.env/rpc | ความพยายามละเมิดขอบเขต | หยุดทันที สิ่งนี้ไม่ควรเกิดขึ้นถ้า boundaries.md ถูกรักษา ให้ถือว่าทุกครั้งที่เกิดขึ้นเป็นบั๊กในตัวระบบเอง

บันทึกทุกเหตุการณ์เหล่านี้ไปยัง incidents/log.tsv พร้อมประทับเวลา ไม่ว่าคุณจะดำเนินการกับมันหรือไม่ก็ตาม เป้าหมายไม่ใช่ศูนย์เหตุการณ์ แต่เป็นศูนย์เหตุการณ์ที่คุณรู้ช้าเกินไป

สัปดาห์ละครั้ง ให้ทำ compost pass: อ่าน incident log, การลดตำแหน่งใน trust file, และอะไรก็ตามที่ยังคงอยู่ในคิวและไม่ได้ลงนามนานกว่า 3 วัน ดึงออกมาอย่างมากที่สุดสามข้อเสนอ: จุดหยุดเด็ดขาดใหม่สำหรับ CONTRACT.md, การแก้ไขคำอธิบายงาน, หรือ standing check ที่คุณขาดไป คุณลงนามทั้งสามอย่างด้วยตัวเอง ระบบสามารถเสนอกฎถัดไปของตัวเองได้ แต่มันไม่เคยได้รับอนุญาตให้เขียนกฎนั้น

ตารางการทดลองงาน

สามจุดตรวจ ไม่ใช่สามสิบวันของการดูแล:

Gipp 🦅 - inline image

จุดตรวจ 1. รัน shift ด้วยตนเองทุกวันเป็นเวลาหนึ่งสัปดาห์ อ่านทุกบรรทัด ผ่านเมื่อสาม shift ติดต่อกันจัดเส้นทางแบบที่คุณจะจัด

จุดตรวจ 2. Cron เข้ามารับช่วง shift คุณตรวจสอบคิวพร้อมกาแฟแทนที่จะรันเอง ผ่านเมื่องานที่เกิดซ้ำสองงานข้าม 20 ครั้งที่บันทึกไว้

จุดตรวจ 3. งานที่ทำผลงานได้ดีที่สุดของคุณทำงานโดยไม่มีคุณดูแล ผ่านเมื่อมันทำงานครบหนึ่งสัปดาห์เต็มโดยไม่มีการแทรกแซงจากคุณเลย

กฎโดยย่อ

  • สัญญาคือตัวเลขหรือ "ห้าม" อะไรที่นุ่มนวลกว่านั้นจะถูกปรับเปลี่ยนรอบ
  • Dispatcher ตัดสินใจ Worker พิมพ์ ไม่มีใครตรวจสอบงานของตัวเอง
  • การตัดสินของ Fable คุ้มค่ากับราคา การพิมพ์ของ Fable มักจะไม่คุ้ม
  • ความไว้วางใจเป็นรายงาน ไม่ใช่ทั้งบริษัท และการลดตำแหน่งเป็นไปโดยอัตโนมัติและดัง
  • งานที่เสร็จแล้วแต่ไม่ได้ตรวจสอบซ้ำไม่ใช่เสร็จ มันคือการเดาที่มีวันที่กำกับ
  • ขอบเขตอยู่ในไฟล์ที่คุณอ่านได้ภายในสิบวินาที ไม่ใช่ในความจำของคุณ
  • บันทึกเหตุการณ์มีอยู่เพื่อให้คุณพบปัญหาจากรายงาน ไม่ใช่จากยอดเงินคงเหลือ
  • ห้ามสร้างอะไรต่อจาก output ของ model ที่คุณไม่ได้ขอ
  • สัปดาห์ละครั้ง ระบบสามารถเสนอหนึ่งกฎใหม่ คุณยังคงเป็นคนลงนาม

โมเดลไม่เคยเป็นส่วนที่ยาก การสร้างสิ่งรอบๆ มันที่ยังคงซื่อสัตย์เมื่อไม่มีใครมอง นั่นคืองานจริง นี่คือหน้าตาของสิ่งนั้นสำหรับกอง bot แทนที่จะเป็น codebase

เริ่มต้นด้วย guardrails/signoff.sh รันหนึ่ง shift ด้วยตนเอง เขียนหนึ่ง standing check สำหรับ bot ตัวสุดท้ายที่คุณส่งไป ครั้งแรกที่มันจับสิ่งที่คุณมั่นใจว่าดี ส่วนที่เหลือจะหยุดเป็นทางเลือก

ติดตาม @GipArcAI สำหรับบทวิเคราะห์แบบนี้เพิ่มเติม และหาเราได้ที่ X: https://x.com/gippp69

บันทึกในคลิกเดียว

อ่านบทความไวรัลเชิงลึกด้วย AI ใน YouMind

บันทึกแหล่งที่มา ถามคำถามที่ตรงประเด็น สรุปข้อโต้แย้ง และเปลี่ยนบทความไวรัลให้เป็นโน้ตที่นำกลับมาใช้ได้ใน AI เวิร์กสเปซเดียว

สำรวจ YouMind
สำหรับครีเอเตอร์

เปลี่ยน Markdown ของคุณให้เป็นบทความ 𝕏 ที่สะอาดตา

เวลาคุณเผยแพร่งานเขียนยาวของตัวเอง การจัดรูปแบบรูปภาพ ตาราง และบล็อกโค้ดให้เข้ากับ 𝕏 นั้นน่าปวดหัว YouMind เปลี่ยนร่าง Markdown ทั้งฉบับให้เป็นบทความ 𝕏 ที่สะอาดตาและพร้อมโพสต์ทันที

ลอง Markdown เป็น 𝕏

แพตเทิร์นให้ถอดรหัสเพิ่มเติม

บทความไวรัลล่าสุด

สำรวจบทความไวรัลเพิ่มเติม