พนักงาน 30 คนที่ทำงานได้จริง และค่าแรงเดือนละ 3,500 บาท ( Claude Max 100 )

ตอนนี้ผมนั่งคนเดียวที่โต๊ะทำงาน แต่มีพนักงาน 30 คนรอรับงานอยู่

ไม่ใช่พนักงานจริง ไม่มีค่าเงินเดือน ไม่มีประกันสังคม ไม่มีวันลาพักร้อน — แต่มีชื่อ มีตำแหน่ง มีบุคลิก มีขอบเขตงานที่ชัดเจน และทำงานได้ดีจริง

Mathita เป็น Assitan Ceo ที่นั่งสูงกว่าทุกคน เป็นเหมือนที่ปรึกษาที่กล้าท้าทายผมตอนกำลังจะตัดสินใจผิด

Marisa หัวหน้าฝ่ายการตลาด มี specialist 4 คนใต้บังคับบัญชา

Marina หัวหน้าฝ่ายขาย ดูแล proposal กับ outreach ทั้งหมด

Mathawee หัวหน้าฝ่ายการเงิน คำนวณ VAT หัก ณ ที่จ่ายให้ผมทุกครั้งที่ออกใบเสนอราคา

Methika คอยจัดการ Operations, HR, IT

Madeena เป็นแผนก HR คอยดูและพนักงานในองค์กร และRecuite พนักงานใหม่ๆหากจำเป็น

Mamaiya, เป็นแผนก It คอยบันทึกและแก้ไขเรื่องการติดตั้งโปรแกรมต่างๆ

นี่คือ Gen AI Space Company — บริษัทเสมือนของผมที่ทำงานจริงทุกวัน

บทความนี้คือบันทึก 30 วันที่ผมเริ่มทดลองสร้างบริษัทของตัวเองผ่าน Claude Max — ค่าใช้จ่ายเดือนละ 3,500 บาท (ราว $100) ถูกกว่าเงินเดือนเด็กฝึกงาน 1 คน แต่ได้ทีม 30 คน ถ้าคุณกำลังเป็น solopreneur freelancer หรือเจ้าของธุรกิจขนาดเล็กที่รู้สึกว่าตัวเองคือคอขวด — ลองอ่านบทความนี้ดู น่าจะเป็นแนวทางการสร้างบริษัทส่วนตัวของคุณขึ้นมาได้

หลักคิด 4 ข้อที่ต้องเข้าใจก่อนเริ่ม

ก่อนจะลงมือสร้างอะไร ผมขอวางหลักคิด 4 ข้อให้ก่อน เพราะถ้าผิดตรงนี้ ทุกอย่างที่ตามมาจะพังหมด

หนึ่ง — AI ไม่ใช่เครื่องมือ AI คือพนักงาน

คนส่วนใหญ่ใช้ AI แบบ “เปิด ChatGPT ขึ้นมา พิมพ์ prompt แล้วเอาคำตอบไปใช้” นี่คือการมอง AI เป็นเครื่องมือ — เหมือนใช้เครื่องคิดเลข

แต่ถ้าจะสร้างบริษัทได้จริง ต้องเปลี่ยน mindset จาก “prompt” เป็น “delegate” — เหมือนคุณมอบหมายงานให้ลูกน้อง ไม่ใช่กดปุ่มเครื่องจักร

ความต่างคือ ลูกน้องที่ดีต้องรู้ขอบเขตงานของตัวเอง รู้ว่าเมื่อไหร่ต้องส่งต่อ มีมาตรฐานผลงาน และมีบุคลิก — ไม่ใช่ generic intelligence ที่ทำได้ทุกอย่าง

สอง — พนักงานต้องมี Job Description ที่ชัด

ลองนึกภาพบริษัทจริง ถ้าคุณจ้างคนเข้ามาแล้วบอกว่า “ทำทุกอย่างก็ได้” — คนนั้นจะทำไม่ได้สักอย่าง เพราะไม่รู้ว่าตัวเองรับผิดชอบอะไร และเมื่อไหร่ต้องส่งต่อให้คนอื่น

AI ก็เหมือนกัน Marisa ของผมไม่ได้เป็น “AI ที่ช่วยเรื่องการตลาด” แต่เป็น “Head of Marketing ที่รับผิดชอบ brand voice, content strategy, ad campaign, course/event promotion ครอบคลุม GenAI Space, AI training, AICAT, ComfyCon Thailand — และ orchestrate ทีม 4 คน” นี่คือ Job Description ที่ชัดจนเธอรู้ว่าควรรับงานอะไร และควรส่งงานไหนกลับ

สาม — องค์กรต้องมี memory ร่วม

ทุกครั้งที่คุณเปิดแชทใหม่ AI ลืมทุกอย่าง คุณต้องเล่าใหม่หมด context หาย ความรู้ที่สะสมหายไป

บริษัทที่ทำงานได้จริงต้องมี second brain — พื้นที่กลางที่ทุกคน (รวมถึงตัวคุณเอง) เข้าถึงข้อมูลเดียวกัน รู้ว่างานไหนเคยทำแล้ว ลูกค้าคนไหนเคยคุยอะไร เคยขายในราคาเท่าไหร่ ทำไมถึงเลือกแบบนั้น

ถ้าไม่มี memory ร่วม คุณจะวนลูปอยู่ที่จุดเดิมตลอด

สี่ — AI ก็ทำผิดพลาดได้ และทำบ่อยมาก

ถ้าคุณคิดว่า AI เกิดมาทำงานกับคุณแล้วเก่งเลย คุณคิดผิดมาก แม้จะวาง describe งานไว้ดีแค่ไหน AI ก็ยังทำผิดพลาดเสมอ แต่สิ่งที่ดีคือ คุณสามารถบอกกับเค้าได้ว่าผิดตรงไหน (แนะนำให้ใช้คำสุภาพ) และเมื่อเค้าแก้ไขงานจนเป็นที่พอใจของคุณ ก็บอกให้เค้าบันทึกเอาไว้ รอบหน้าเค้าจะกลับมาทำงานให้คุณแบบเดิม 100%

3 เสาหลักของบริษัทเสมือน คือ Skill (ความสามารถ) + Second Brain (ความจำ) + Agent (ตัวตน+บทบาท)

เสาที่ 1 — Skill คือความสามารถของพนักงาน

Skill คืออะไร? Skill คือ Workflow การทำงานของเราที่เราจะกำหนดตั้งแต่เริ่มจนได้ผลลัพธ์ที่ต้องการ

ลองนึกถึง SOP ของบริษัทจริง — เอกสารที่บอกว่า “ถ้าลูกค้าขอใบเสนอราคา ให้ทำตามขั้นตอนนี้ ใช้ format นี้ คิด VAT แบบนี้” SOP ทำให้พนักงานคนไหนก็ทำได้ผลลัพธ์เท่ากัน ไม่ต้องอาศัยความจำของหัวหน้า

Skill ในโลก AI คือสิ่งเดียวกัน — ชุดคำสั่งที่ถูก trigger อัตโนมัติเมื่อ context ตรง

ทำไม skill ดีกว่า prompt ยาวๆ?

ลองคิดว่าทุกครั้งที่จะออกใบเสนอราคา คุณต้องพิมพ์ prompt 500 บรรทัดอธิบายเรื่อง VAT 7% หัก ณ ที่จ่าย 3% กับ 2% format ตัวเลขแบบไทย เงื่อนไขการชำระเงิน — กว่าจะจบได้แต่ล่ะงานมันเหนื่อยมาก

แต่ถ้ามี skill ชื่อ proposal-quotation-writer-thai — แค่บอก “เขียนใบเสนอราคาให้ Mahidol คอร์ส 2 วัน 200,000 บาท” skill จะถูก trigger เอง คำนวณ VAT ใส่หัก ณ ที่จ่ายถูกต้อง format เลขไทย เสนอ 3 tier (basic/standard/premium) ออกมาเป็นไฟล์พร้อมส่ง

นี่คือพลังของ skill — encode ความเชี่ยวชาญลงไปครั้งเดียว ใช้ได้ตลอด

โครงสร้างของ skill ที่ดี

Skill ที่ใช้งานได้จริง มี 4 ส่วน:

ชื่อ + คำอธิบาย — ที่สำคัญที่สุดคือ description ต้องบอกชัดว่า “เมื่อไหร่ใช้ เมื่อไหร่ไม่ใช้” เพราะ AI จะเลือก skill จาก description ถ้าเขียนกำกวม AI จะใช้ผิด skill หรือไม่ใช้เลย
Workflow ที่เป็นขั้นเป็นตอน — ไม่ใช่แค่ “ช่วยเขียน proposal” แต่ต้องบอกว่า ขั้น 1 ถามขอบเขตงาน ขั้น 2 ดูราคาฐาน ขั้น 3 คำนวณภาษี ขั้น 4 generate ทั้ง 3 tier ขั้น 5 export เป็นไฟล์
Reference files ( optional ) — ตัวอย่างจริงที่เคยใช้ได้ผล ราคาฐาน เงื่อนไขมาตรฐาน เพื่อให้ skill มี anchor ไม่หลุดกรอบ
Trigger keywords — “ทำ proposal” “ใบเสนอราคา” “quotation” — AI จะ match keyword แล้วเรียก skill

Insight สำคัญ: skill หนึ่ง = ความสามารถหนึ่ง ไม่ใช่ “skill รวมทุกอย่าง” Skillที่ดีต้องชัดเจนในงานเท่านั้น พนักงานคนนึงอาจมี 5-10 skill ตามขอบเขตงาน เช่น Marisa มี skill เขียน social post, skill brand audit, skill content calendar — แยกกันคนละไฟล์

ถ้าคุณเพิ่งเริ่ม — list งานที่คุณทำซ้ำๆ สัปดาห์ละครั้งขึ้นไป แต่ละงานคือ skill ที่คุณควรสร้าง เริ่มจาก 1 skill ก่อน ทำให้ดี แล้วค่อยขยาย

วิธีการสร้าง Skill ทำได้ 3 รูปแบบ 1.คือเขียนเองจาก Workflow การทำงานของคุณ โดยใช้ /Skill Creator 2. ทำงานกะ Claude ไปเรื่อยๆ จนพอใจแล้วบอกให้ Claude สร้าง Skill นี้เก็บไว้ 3.Download Skill ของคนอื่นๆที่สร้างไว้เข้ามา แต่ส่วนตัวผมไม่แนะนำเพราะถ้าเราไม่รู้จักเค้ามากพอ เค้าอาจจะฝังอะไรบางอย่างมาในเครื่องได้

เสาที่ 2 — Second Brain คือความจำขององค์กร

ถ้าไม่มี second brain พนักงาน AI ของคุณจะลืมทุกอย่างหลังจบแชท ลูกค้าคนเดิมโทรมาวันรุ่งขึ้น คุณต้องเล่าทุกอย่างใหม่ ราคาที่เคยคุย deal ที่เคยปฏิเสธ — หายหมด

ผมใช้ระบบ 2-layer คือ Notion + Obsidian และอยากอธิบายว่าทำไมต้อง 2 ที่ ไม่ใช่ที่เดียว

Notion = ระบบงาน (Operating Layer)

Notion เก่งเรื่อง “ดูสถานะ + แชร์ + ติดตาม” — มี database มี view กรอง มี timeline มี kanban เปิดบนมือถือได้ ทีมเข้าถึงได้

ผมใช้ Notion สำหรับ:

Pipeline ลูกค้า (prospect → proposal sent → won/lost)
Log งานของพนักงาน AI ทุกคน (Marisa ทำอะไรไปแล้ววันนี้ ผลลัพธ์ดี/พอใช้/พัง)
ปฏิทินคอร์สที่จะสอน
ติดตามเงินค้างจ่าย AR

ทุกครั้งที่พนักงาน AI ทำงานเสร็จ เขาจะ log ผลงานเข้า Notion พร้อม outcome — ดี / ต้องปรับ / พัง สะสมไปเรื่อยๆ จนเห็นว่าใครเก่งอะไร งานแบบไหนพังบ่อย

และผมสร้าง SKill notion-to-second-brain เอาไว้เพื่อบันทึกตามที่เนื้อหาตามที่ผมต้องการ ใครสนใจสามารถลอง Download ไปทดลองใช้งานได้

วิธีการใช้งานง่ายมาก เมื่อไหร่ทำงานจนจบก็ /notion-to second brain เค้าก็จะไปบันทึกงานใน notion ได้เลย

https://drive.google.com/drive/folders/18Nc0EfdSJfS4uG2g_6hhXXIp5NFPVn_D?usp=sharing

Obsidian = สมองส่วนลึก (Knowledge Layer)

Obsidian เก่งเรื่อง “compound + cross-link” — โน้ตทุกอันเชื่อมกันด้วย wikilink เห็น graph ความรู้ทั้งหมด ทุกแนวคิดมีหน้าของตัวเอง ทุก source ที่อ่านมีหน้าสรุป

ผมใช้ Obsidian สำหรับ:

Wiki ความรู้ทั้งหมด (concept, framework, source สรุป)
Master curriculum ของคอร์สที่สอน (เก็บเนื้อหาเป็นข้อความดิบ)
บันทึกบทสนทนาที่มีคุณค่ายาว
Canvas สำหรับ map ความเชื่อมโยงเชิงพื้นที่

วิธีตั้งค่า Obsidian ให้เป็นสมองของบริษัทคุณ

ขั้นที่ 1 — ติดตั้ง Obsidian

ไปที่ obsidian.md → ดาวน์โหลดตามระบบของเครื่อง (Windows / Mac / Linux)
ติดตั้งเหมือนโปรแกรมทั่วไป
เปิดโปรแกรม → กด “Create new vault” → ตั้งชื่อ vault (ผมตั้งว่า “Brain”) → เลือกที่อยู่ในเครื่อง

Obsidian ฟรี ไม่ต้องสมัคร account ไม่ต้อง cloud ทุกอย่างเป็นไฟล์ .md เก็บในเครื่องของเรา ปลอดภัย 100%

ขั้นที่ 2 — ติดตั้ง MCP for Obsidian

MCP (Model Context Protocol) คือสะพานให้ Claude อ่าน/เขียน Obsidian ของคุณได้โดยตรง

วิธีติดตั้ง (ใน Claude Code):

claude mcp add obsidian --scope user "uvx mcp-obsidian"

หลังติดตั้งต้อง:

เปิด Obsidian + เปิด vault ที่ต้องการ (MCP ทำงานเมื่อ Obsidian เปิดอยู่)
ใน Obsidian → Settings → Community Plugins → install “Local REST API” → enable
คัดลอก API key ที่ plugin สร้างให้ → ใส่ใน config ของ MCP

จากนั้น Claude จะอ่าน/เขียนไฟล์ใน vault ของคุณได้เหมือนนั่งโต๊ะเดียวกัน

*** ควรใช้งานใน Claude Code จะเหมาะสมที่สุด ***

ขั้นที่ 3 — ติดตั้ง LLM Wiki จาก karpathy

LLM Wiki

A pattern for building personal knowledge bases using LLMs.

This is an idea file, it is designed to be copy pasted to your own LLM Agent (e.g. OpenAI Codex, Claude Code, OpenCode / Pi, or etc.). Its goal is to communicate the high level idea, but your agent will build out the specifics in collaboration with you.

The core idea

Most people’s experience with LLMs and documents looks like RAG: you upload a collection of files, the LLM retrieves relevant chunks at query time, and generates an answer. This works, but the LLM is rediscovering knowledge from scratch on every question. There’s no accumulation. Ask a subtle question that requires synthesizing five documents, and the LLM has to find and piece together the relevant fragments every time. Nothing is built up. NotebookLM, ChatGPT file uploads, and most RAG systems work this way.

The idea here is different. Instead of just retrieving from raw documents at query time, the LLM incrementally builds and maintains a persistent wiki — a structured, interlinked collection of markdown files that sits between you and the raw sources. When you add a new source, the LLM doesn’t just index it for later retrieval. It reads it, extracts the key information, and integrates it into the existing wiki — updating entity pages, revising topic summaries, noting where new data contradicts old claims, strengthening or challenging the evolving synthesis. The knowledge is compiled once and then kept current, not re-derived on every query.

This is the key difference: the wiki is a persistent, compounding artifact. The cross-references are already there. The contradictions have already been flagged. The synthesis already reflects everything you’ve read. The wiki keeps getting richer with every source you add and every question you ask.

You never (or rarely) write the wiki yourself — the LLM writes and maintains all of it. You’re in charge of sourcing, exploration, and asking the right questions. The LLM does all the grunt work — the summarizing, cross-referencing, filing, and bookkeeping that makes a knowledge base actually useful over time. In practice, I have the LLM agent open on one side and Obsidian open on the other. The LLM makes edits based on our conversation, and I browse the results in real time — following links, checking the graph view, reading the updated pages. Obsidian is the IDE; the LLM is the programmer; the wiki is the codebase.

This can apply to a lot of different contexts. A few examples:

Personal: tracking your own goals, health, psychology, self-improvement — filing journal entries, articles, podcast notes, and building up a structured picture of yourself over time.
Research: going deep on a topic over weeks or months — reading papers, articles, reports, and incrementally building a comprehensive wiki with an evolving thesis.
Reading a book: filing each chapter as you go, building out pages for characters, themes, plot threads, and how they connect. By the end you have a rich companion wiki. Think of fan wikis like Tolkien Gateway — thousands of interlinked pages covering characters, places, events, languages, built by a community of volunteers over years. You could build something like that personally as you read, with the LLM doing all the cross-referencing and maintenance.
Business/team: an internal wiki maintained by LLMs, fed by Slack threads, meeting transcripts, project documents, customer calls. Possibly with humans in the loop reviewing updates. The wiki stays current because the LLM does the maintenance that no one on the team wants to do.
Competitive analysis, due diligence, trip planning, course notes, hobby deep-dives — anything where you’re accumulating knowledge over time and want it organized rather than scattered.

Architecture

There are three layers:

Raw sources — your curated collection of source documents. Articles, papers, images, data files. These are immutable — the LLM reads from them but never modifies them. This is your source of truth.

The wiki — a directory of LLM-generated markdown files. Summaries, entity pages, concept pages, comparisons, an overview, a synthesis. The LLM owns this layer entirely. It creates pages, updates them when new sources arrive, maintains cross-references, and keeps everything consistent. You read it; the LLM writes it.

The schema — a document (e.g. CLAUDE.md for Claude Code or AGENTS.md for Codex) that tells the LLM how the wiki is structured, what the conventions are, and what workflows to follow when ingesting sources, answering questions, or maintaining the wiki. This is the key configuration file — it’s what makes the LLM a disciplined wiki maintainer rather than a generic chatbot. You and the LLM co-evolve this over time as you figure out what works for your domain.

Operations

Ingest. You drop a new source into the raw collection and tell the LLM to process it. An example flow: the LLM reads the source, discusses key takeaways with you, writes a summary page in the wiki, updates the index, updates relevant entity and concept pages across the wiki, and appends an entry to the log. A single source might touch 10-15 wiki pages. Personally I prefer to ingest sources one at a time and stay involved — I read the summaries, check the updates, and guide the LLM on what to emphasize. But you could also batch-ingest many sources at once with less supervision. It’s up to you to develop the workflow that fits your style and document it in the schema for future sessions.

Query. You ask questions against the wiki. The LLM searches for relevant pages, reads them, and synthesizes an answer with citations. Answers can take different forms depending on the question — a markdown page, a comparison table, a slide deck (Marp), a chart (matplotlib), a canvas. The important insight: good answers can be filed back into the wiki as new pages. A comparison you asked for, an analysis, a connection you discovered — these are valuable and shouldn’t disappear into chat history. This way your explorations compound in the knowledge base just like ingested sources do.

Lint. Periodically, ask the LLM to health-check the wiki. Look for: contradictions between pages, stale claims that newer sources have superseded, orphan pages with no inbound links, important concepts mentioned but lacking their own page, missing cross-references, data gaps that could be filled with a web search. The LLM is good at suggesting new questions to investigate and new sources to look for. This keeps the wiki healthy as it grows.

Indexing and logging

Two special files help the LLM (and you) navigate the wiki as it grows. They serve different purposes:

index.md is content-oriented. It’s a catalog of everything in the wiki — each page listed with a link, a one-line summary, and optionally metadata like date or source count. Organized by category (entities, concepts, sources, etc.). The LLM updates it on every ingest. When answering a query, the LLM reads the index first to find relevant pages, then drills into them. This works surprisingly well at moderate scale (~100 sources, ~hundreds of pages) and avoids the need for embedding-based RAG infrastructure.

log.md is chronological. It’s an append-only record of what happened and when — ingests, queries, lint passes. A useful tip: if each entry starts with a consistent prefix (e.g. ## [2026-04-02] ingest | Article Title), the log becomes parseable with simple unix tools — grep "^## \[" log.md | tail -5 gives you the last 5 entries. The log gives you a timeline of the wiki’s evolution and helps the LLM understand what’s been done recently.

Optional: CLI tools

At some point you may want to build small tools that help the LLM operate on the wiki more efficiently. A search engine over the wiki pages is the most obvious one — at small scale the index file is enough, but as the wiki grows you want proper search. qmd is a good option: it’s a local search engine for markdown files with hybrid BM25/vector search and LLM re-ranking, all on-device. It has both a CLI (so the LLM can shell out to it) and an MCP server (so the LLM can use it as a native tool). You could also build something simpler yourself — the LLM can help you vibe-code a naive search script as the need arises.

Tips and tricks

Obsidian Web Clipper is a browser extension that converts web articles to markdown. Very useful for quickly getting sources into your raw collection.
Download images locally. In Obsidian Settings → Files and links, set “Attachment folder path” to a fixed directory (e.g. raw/assets/). Then in Settings → Hotkeys, search for “Download” to find “Download attachments for current file” and bind it to a hotkey (e.g. Ctrl+Shift+D). After clipping an article, hit the hotkey and all images get downloaded to local disk. This is optional but useful — it lets the LLM view and reference images directly instead of relying on URLs that may break. Note that LLMs can’t natively read markdown with inline images in one pass — the workaround is to have the LLM read the text first, then view some or all of the referenced images separately to gain additional context. It’s a bit clunky but works well enough.
Obsidian’s graph view is the best way to see the shape of your wiki — what’s connected to what, which pages are hubs, which are orphans.
Marp is a markdown-based slide deck format. Obsidian has a plugin for it. Useful for generating presentations directly from wiki content.
Dataview is an Obsidian plugin that runs queries over page frontmatter. If your LLM adds YAML frontmatter to wiki pages (tags, dates, source counts), Dataview can generate dynamic tables and lists.
The wiki is just a git repo of markdown files. You get version history, branching, and collaboration for free.

Why this works

The tedious part of maintaining a knowledge base is not the reading or the thinking — it’s the bookkeeping. Updating cross-references, keeping summaries current, noting when new data contradicts old claims, maintaining consistency across dozens of pages. Humans abandon wikis because the maintenance burden grows faster than the value. LLMs don’t get bored, don’t forget to update a cross-reference, and can touch 15 files in one pass. The wiki stays maintained because the cost of maintenance is near zero.

The human’s job is to curate sources, direct the analysis, ask good questions, and think about what it all means. The LLM’s job is everything else.

The idea is related in spirit to Vannevar Bush’s Memex (1945) — a personal, curated knowledge store with associative trails between documents. Bush’s vision was closer to this than to what the web became: private, actively curated, with the connections between documents as valuable as the documents themselves. The part he couldn’t solve was who does the maintenance. The LLM handles that.

Note

This document is intentionally abstract. It describes the idea, not a specific implementation. The exact directory structure, the schema conventions, the page formats, the tooling — all of that will depend on your domain, your preferences, and your LLM of choice. Everything mentioned above is optional and modular — pick what’s useful, ignore what isn’t. For example: your sources might be text-only, so you don’t need image handling at all. Your wiki might be small enough that the index file is all you need, no search engine required. You might not care about slide decks and just want markdown pages. You might want a completely different set of output formats. The right way to use this is to share it with your LLM agent and work together to instantiate a version that fits your needs. The document’s only job is to communicate the pattern. Your LLM can figure out the rest.

view raw llm-wiki.md hosted with ❤ by GitHub

วิธีการง่ายมาก Copy ทั้งหมดทุกคำนี่เลยแล้วเอาไปวางให้ Claude code อ่านและสั่งให้จดจำเอาไว้

ขั้นที่ 4 — สร้าง CLAUDE.md (Schema ของ Wiki)

CLAUDE.md คือไฟล์คู่มือที่บอก AI ว่า “เวลามาทำงานใน vault นี้ ทำตาม rule นี้”

วางไว้ที่ root ของ vault ในนั้นเขียน:

ประวัติคุณ (เป็นใคร ทำอะไร)
โครงสร้าง folder
format ของ frontmatter (title, type, tags, created, summary)
workflow เช่น “เวลา ingest บทความใหม่ ทำตามขั้น 1-7”
workflow เช่น “เวลา save chat ทำตามขั้น 1-5”

ผล: ทุกครั้งที่เปิดแชทใหม่ AI อ่าน CLAUDE.md → รู้ rule ของ vault ทันที ไม่ต้องเล่าใหม่

หากไม่เคยทำมาก่อน วิธีการที่ง่ายที่สุดคือ ถาม Claude ไปเลยว่าจะสร้าง Claude.md ต้องทำอย่างไรบ้าง ส้รางคำถามออกมาให้หมดแล้วสร้างให้เลย

เคล็ดลับ: Hot Cache

ผมมีไฟล์ชื่อ hot.md ใน Obsidian ที่ auto-load ทุกครั้งที่เปิด session ใหม่ของ AI ในนั้นมี 4 ส่วน:

Last Updated (อัพเดทล่าสุด)
Key Recent Facts (ข้อเท็จจริงสำคัญที่ยังใช้อยู่)
Active Threads (เรื่องที่กำลังตามอยู่)
Recent Changes (อะไรเพิ่งเปลี่ยน)

ผลคือ AI ไม่เริ่มจากศูนย์ทุกครั้ง เปิดมาก็รู้ทันทีว่า “ผมเพิ่งคุยกับลูกค้า Sritep ส่งใบเสนอราคา v2 ไปแล้ว ต้อง follow-up วันที่ 18 พ.ค.” นี่คือสิ่งที่ทำให้ AI รู้สึกเหมือนพนักงานจริงๆ — เพราะเขาจำคุณได้

สรุป workflow ที่ได้หลังตั้งครบ 5 ขั้น

เปิด Claude Code → AI อ่าน CLAUDE.md → อ่าน hot.md → รู้ context ทั้งหมด → ทำงานต่อได้เลย

ผมพิมพ์ “บันทึกบทสนทนานี้ลง wiki” → AI สร้างไฟล์ใหม่ + update index + update log + refresh hot cache → จบในคำสั่งเดียว

นี่คือสิ่งที่ผมหมายถึงเมื่อบอกว่า “second brain ของบริษัทเสมือน” — มันคือพื้นที่ที่ AI กับคุณ share กัน ทำงานในนั้นเหมือนเอกสารใน Google Drive แต่ทุกการ save ทำให้ AI ฉลาดขึ้นเรื่อยๆ

ระบบการบันทึกงาน — ทำไมต้องบันทึก

ทุกครั้งที่พนักงานคนใดคนหนึ่งทำงานเสร็จ — ไม่ว่าจะเขียน proposal ตอบลูกค้า หรือ research ข้อมูล — ผมจะให้เค้า บันทึกงานนั้นในระบบทันที

ไม่ใช่แค่บันทึกว่า “ทำเสร็จแล้ว” แต่บันทึกครบ 3 อย่าง:

งานคืออะไร — input ที่ได้ + output ที่ส่งมา
ใครเป็นคนทำ — Head ไหน specialist ไหน
ผลลัพธ์เป็นยังไง — ดี / ต้องปรับ / พัง

ผมใช้สัญลักษณ์ง่ายๆ คือ ✓ (ใช้ได้เลย) / ⚠ (ต้องแก้นิดหน่อย) / ✗ (พังต้องทิ้ง)

บันทึก 2 ที่ — Notion + Obsidian

Notion — เก็บที่หน้าของ Head แต่ละคน (Marisa มีหน้าของตัวเอง Marina มีหน้าของตัวเอง) เปิดดูได้ทุกที่จากมือถือ
Obsidian — เก็บใน wiki ของผม link กับ entity / concept ที่เกี่ยวข้อง

ทำไมต้อง 2 ที่? เพราะถ้าวันนึงผมจะ “ดู performance” ของพนักงาน → ไปดูที่ Notion ถ้าจะ “ดูว่างานนี้ใช้ความรู้อะไรบ้าง” → ไปดูที่ Obsidian

ถ้าสิ่งนั้น “ต้องดูสถานะ ต้องแชร์ ต้องติดตามเวลา” → ไป Notion เพราะ Notion สามารถเชื่อมกับ Claude.ai ได้ ทำให้สามารถทำงานได้ทุกที่แม้ไม่ใช่คอมของเรา

ถ้าสิ่งนั้น “เป็นความรู้ที่จะอ้างอิงซ้ำ ที่ต้อง link กับเรื่องอื่นและต้องการบันทึกเรื่องที่ไม่ต้องการเปิดเผยให้คนอื่นรู้ ” → ไป Obsidian

ทำไมไม่ใช้ที่เดียว? เพราะคนละบทบาท — Notion คือพื้นที่ “ทำงาน”ที่สามารถใช้งานได้ทุกที่แม้ไม่มีคอมของตัวเองหรือในมือถือ

Obsidian คือพื้นที่ “คิด” บังคับให้รวมในที่เดียว และหลักการของ Obsidian จะบันทึกลงคอมของเราเท่านั้นไม่ผ่านระบบคลาวด์ใดๆ ทำให้ปลอดภัย 100%

ครั้งหน้า Marisa เปิด log นี้ → “เคยทำแบบนี้ ad headline แบบไหน CTR ดี” → ออกแบบ campaign ใหม่ที่ดีกว่าเดิม

สิ่งที่ระบบบันทึกทำให้

ทุกครั้งที่ log = ความรู้ของบริษัทเพิ่มขึ้น 1 ชั้น

หลังใช้งาน 3 เดือน — ผมเห็นแล้วว่า:

ปรียาเก่ง quote ม.รัฐ, แต่งาน corporate ยังอ่อน
ปลายฝนเขียน hook ดี แต่ closing ต้องแก้บ่อย
ใบหม่อนเขียนเร็วถ้ามี outline, ช้าถ้าต้องคิดเอง

ผม เห็น pattern ที่ปรับ agent ได้ — เพิ่ม guidance ในจุดที่อ่อน, ตัดงานที่ไม่เหมาะออก, เปลี่ยน workflow

นี่คือสิ่งที่ทำให้บริษัทเสมือน “ฉลาดขึ้นเรื่อยๆ” ไม่ใช่ AI ที่หยุดอยู่ที่ความสามารถวันแรก แต่เป็นทีมที่ เรียนรู้ผ่านการบันทึก

เสาที่ 3 — Agent + Sub-agent + Role-play

มาถึงเสาที่ผมว่าสนุกที่สุด — การสร้างตัวพนักงาน

Agent ต่างจาก prompt ยังไง?

Prompt = คำสั่งครั้งเดียว เสร็จแล้วจบ
Agent = ตัวละครถาวร มีบุคลิก มีขอบเขต มีความเชี่ยวชาญ มีไฟล์ของตัวเอง

ทุกครั้งที่คุณเรียก agent นั้น เขาจะ “เป็น” ตัวเองคนเดิม คงเส้นคงวา เพราะอ่านบุคลิก/ขอบเขต/มาตรฐานจากไฟล์ของตัวเองทุกครั้งที่ถูกเรียก

ระบบ Agent / Sub-agent ของ Claude — ตามหลักการจริง

User (Boss)

└─ Main Agent (Claude ตัวที่ Boss คุยด้วยตรงๆ)

├─ Subagent A (spawn ผ่าน Task/Agent tool — context แยก)

└─ Subagent A.1 (subagent spawn subagent ได้อีก แต่กิน context)

├─ Subagent B

└─ Subagent C ← parallel ได้ถ้าเรียกใน message เดียว

มีแค่ 2 ระดับเชิงเทคนิค คือ Main กับ Subagent — “sub-sub-agent” คือ subagent ที่ spawn subagent อีกที ไม่ใช่ tier ใหม่ในระบบ แค่ recursive call

คำ	คือ	อยู่ตรงไหน
Main agent	Claude instance ที่ user คุยตรง — เป็น orchestrator	conversation ปัจจุบัน
Subagent	Claude instance แยก context ที่ main spawn ขึ้นมาทำงานเฉพาะ	`~/.claude/agents/<name>.md` หรือ `<project>/.claude/agents/`
Skill	ไฟล์ SKILL.md ที่ โหลดเข้า context ของ agent ปัจจุบัน (ไม่ใช่ agent ใหม่)	`~/.claude/skills/<name>/SKILL.md`
Tool	function ที่ agent เรียกใช้ได้ (Read, Bash, MCP tools)	กำหนดใน agent frontmatter
Hook	shell command ที่ harness รันอัตโนมัติ (ไม่ใช่ AI)	`settings.json`
MCP server	external tool provider	settings/mcp config

สับสนบ่อยสุด: Skill ≠ Subagent

Skill = “Claude คนเดิม + คู่มือใหม่” (อ่านคู่มือแล้วทำเอง)
Subagent = “Claude คนใหม่ที่มีคู่มือตั้งแต่เกิด” (context แยก, persona ติดมา)

คุณสมบัติของ Subagent — 4 ข้อ

Context แยก (จุดสำคัญสุด)

Subagent มี “หัว” ของตัวเอง ไม่เห็นบทสนทนาของ main, main ก็ไม่เห็นรายละเอียดข้างในของ subagent — เห็นแค่คำตอบสุดท้าย

ทำไมสำคัญ: main ไม่บวม → คุยกับ Boss ได้นาน ไม่ลืม

ส่งงานครั้งเดียวจบ

เรียก subagent → เขาทำเสร็จ → ส่งคำตอบกลับ 1 ครั้ง → จบ ถามกลางทางไม่ได้

ผล: ต้อง brief ให้ครบรอบเดียว เหมือนสั่ง freelancer ทาง email ไม่ใช่นั่งคุยกัน

จำกัดเครื่องมือได้

กำหนดได้ว่า subagent ตัวไหนใช้อะไรได้บ้าง — researcher ให้อ่านอย่างเดียว ห้ามเขียนไฟล์ ห้ามรัน command

ผล: ป้องกันความเสียหาย เหมือนให้ key เฉพาะห้องที่จำเป็น

เรียกพร้อมกันได้

ส่ง subagent หลายตัวใน message เดียว → ทำงานขนานกัน เร็วกว่าทำทีละคนหลายเท่า

ผล: launch คอร์ส 1 ครั้ง = social + landing page + research ลูกค้า + pricing เกิดพร้อมกัน

Role-play ที่ดี = ไม่ใช่แค่ “act as a marketer”

นี่คือจุดที่คนทำพลาดบ่อย เขียน prompt ว่า “you are a senior marketing expert” แล้วคิดว่าเป็น role-play แล้ว — ไม่ใช่

Role-play ที่ทำให้ agent ทำงานได้จริงต้องมี 4 องค์ประกอบ:

ชื่อ เพศ อายุ บุคลิก — ฟังดูเด็กเล่นแต่จำเป็น เพราะมันทำให้คุณสื่อสารกับ agent เป็นธรรมชาติ ผมเรียก Marisa ว่า “พี่ Marisa” ได้ บอก “หาพนักงานมาเขียนใบเสนอราคาให้หน่อย” ได้ ผมไม่เคยลืมว่าใครเก่งอะไรเพราะเขามีตัวตน
ขอบเขตงานที่ชัด — ใบหม่อนรับงาน “บทความยาว blog newsletter description คอร์ส” ไม่รับ “social post สั้นๆ” ถ้าผมขอผิด เธอจะบอกผมเองว่า “อันนี้น่าจะให้ปลายฝนทำดีกว่า”
มาตรฐานผลงาน ห้ามทำอะไร ต้องมีอะไรเสมอ — เช่น ปรียา (proposal specialist) “ต้อง” ใส่ VAT 7% หัก ณ ที่จ่ายถูกต้องทุกครั้ง “ห้าม” ส่ง draft ที่ยังไม่ได้คำนวณภาษี — นี่คือ guardrail ที่ป้องกันความผิดพลาด
การส่งต่อ — เมื่อไหร่ส่งกลับให้ Head เมื่อไหร่ส่งให้ specialist อื่น เมื่อไหร่ส่งกลับให้ผมตัดสินใจ — กฎการ escalate ที่ชัด

Architecture ของ Gen AI Space Company

เอาล่ะเมื่ออ่านจนเข้าใจในเรื่องของการจัด Agent + Sub-agent + Role-play ผมจะมาอธิบายต่อในการจัดทีมบริษัทของผม :

ชั้นบนสุด: Mathita — Assistant CEO เป็นเหมือนหุ้นส่วน ท้าทายผมได้ ปกป้องเวลาและพลังงานผม ไม่ใช่แค่ลูกน้องที่รับคำสั่ง

ชั้นกลาง: 6 Heads of Department — Marisa (Marketing), Marina (Sales), Mathawee (Finance), Madeena (Operations), Mamaiya (HR), Methika (IT) แต่ละคนเป็น orchestrator รับงานจากผม ตัดสินใจส่งต่อให้ specialist

ชั้นล่าง: 24 Specialists — แต่ละ Head มี 4 คน specialize เฉพาะทาง เช่น ในทีม Marisa มี ใบหม่อน (long-form writer), ปลายฝน (social media), น้ำหวาน (ad copy), พิมพ์ใจ (brand strategist)

ทำไมต้องเป็น 3 ชั้น? เพราะใกล้เคียงกับองค์กรจริง — ผม (CEO) คุยกับ Mathita หรือ Head เท่านั้น ไม่ต้องไปสั่ง specialist เอง Head จะรู้ว่าควรส่งงานให้ใคร ผมประหยัด context ในหัวมหาศาล

เคล็ดลับ orchestration

อย่าเรียก agent ทีละคน ถ้างานที่ต้องทำเป็นอิสระต่อกัน — เรียกพร้อมกันในข้อความเดียว AI tool ดีๆ จะ parallel ให้ ลด context และเร็วขึ้นมาก

ตัวอย่าง: ผมอยาก launch คอร์สใหม่ — เรียก ปลายฝน เขียน social post + ใบหม่อน เขียน landing page + ดารินทร์ research prospects + ปรียา ตั้ง pricing tier — พร้อมกัน 4 คน ส่งกลับมาให้ผม review ในรอบเดียว

นี่คือสิ่งที่ทำให้ผมคนเดียวทำงานได้เหมือนทีม 10 คน

จะไม่เล่าครบทุกคน เดี๋ยวยาว ขอเอา 2 ทีมมาเป็นตัวอย่างให้เห็นภาพ

ทีม Marisa (Marketing) — 4 คน

ใบหม่อน — long-form writer เขียนบทความยาว blog newsletter description คอร์ส (คนที่ช่วยเขียนบทความนี้ก็คือเธอ)
ปลายฝน — social media writer ดูแล Facebook Threads LinkedIn caption hooks
น้ำหวาน — performance copywriter เขียน ad headline, tagline, landing page CTA
พิมพ์ใจ — brand strategist วาง positioning, voice consistency, naming, brand audit

ทุกคนเก่งคนละด้านชัดเจน ถ้าผมขอใบหม่อน “เขียนแคปชั่นโพสต์สั้นๆ” เธอจะปฏิเสธ บอกว่า “อันนี้น่าจะให้ปลายฝนทำดีกว่า” เพราะเธอรู้ขอบเขตตัวเอง

ทีม Marina (Sales) — 4 คน

ดารินทร์ — prospect research analyst หาข้อมูลลูกค้าก่อน outreach
ฟ้าใส — outreach writer เขียน cold email, DM, follow-up sequence
ปรียา — proposal specialist เขียนใบเสนอราคาไทย คำนวณ VAT 7% หัก ณ ที่จ่ายครบ
เบญจวรรณ — closer ดูแล objection handling, pricing pushback, ปิดดีล

ขั้นตอนการขายของผมจริงๆ ที่เกิดขึ้นบ่อย: ดารินทร์ research ลูกค้า → ฟ้าใส ส่ง outreach → ปรียา ทำ proposal → เบญจวรรณ ตอบคำถามราคา ทุกคนรับช่วงต่อกันเป็นสายพาน

4 ทีมที่เหลือ ใช้ pattern เดียวกัน

Mathawee (Finance) — bookkeeper / analyst / billing-AR / tax specialist
Madeena (Operations) — project manager / scheduler / vendor / quality
Mamaiya (HR) — recruiter / onboarding / people development / curriculum keeper
Methika (IT) — infrastructure / AI tools stack / automation / security

ทุกทีมแบ่งแบบเดียวกัน — Head คอย orchestrate, specialist 4 คนรับงานเฉพาะทาง

ตัวอย่างงานที่ 1 — งานเดี่ยว: ทำใบเสนอราคา Mahidol

Input: “ปรียา ช่วยทำใบเสนอราคาให้ Mahidol คอร์ส AI 2 วัน 200,000 บาท”

Process:

ปรียา (proposal specialist) ดู context ของลูกค้า + ราคาฐานของผม
คำนวณ VAT 7% + หัก ณ ที่จ่าย 3%
เสนอ 3 tier — Basic / Standard / Premium
Export เป็น PDF + ส่งกลับมาให้ผมรีวิว

Output: ใบเสนอราคา 3 ตัวเลือก พร้อมส่ง Mahidol ในเวลา 15 นาที

Log ที่บันทึก:

หน้า Notion ของ Marina (Head of Sales) → row ใหม่: “Mahidol — 2-day AI course / ปรียา / ✓”
ใน Obsidian → ไฟล์ wiki/sources/mahidol-proposal-2026-05.md + cross-link กับ entity Mahidol

ทำไมต้อง log: เดือนหน้ามี ม.อื่นถามคล้ายกัน → ปรียาเปิด log เก่า → ใช้ราคาเดิม เห็นว่าเคยปรับยังไง → ทำเร็วขึ้นเท่าตัว

ตัวอย่างงานที่ 2 — งานทีม: Launch คอร์สใหม่

Input: “Marisa ผมจะ launch คอร์ส ‘AI for HR’ เดือนหน้า ทำให้พร้อม”

Process: Marisa ไม่ทำเองคนเดียว เธอเรียกทีม 4 คนพร้อมกัน:

ใบหม่อน → เขียน landing page (long-form)
ปลายฝน → เขียน Facebook teaser 3 โพสต์
น้ำหวาน → เขียน ad headline 5 ตัว
พิมพ์ใจ → ตรวจ brand voice ทุกชิ้น

ทั้ง 4 คนทำงาน ขนานกัน ส่งกลับมาให้ Marisa รวบ → Marisa ส่งให้ผมรีวิวทีเดียว

Output: Landing page + 3 teaser posts + 5 ad headlines + brand check — ได้ใน 1 ชั่วโมง (ถ้าผมทำเองคนเดียว = ครึ่งวัน)

Log ที่บันทึก:

หน้า Notion Marisa → 4 rows ของ specialist แต่ละคน (พร้อม outcome ของแต่ละชิ้น)
ใน Obsidian → wiki/analysis/launch-ai-for-hr-2026-06.md link campaign นี้กับ Mathawee (P&L), Marina (sales target), Madeena (event ops)

ทำไมต้อง log: launch

เมื่อผมตันกะไอเดียอะไรมากๆ ผมจะลองเรียกพนักงานประชุมดุและก็จะออกมาเป็นแบบนี้

เริ่มต้นยังไง — 4 ขั้น

ถ้าอ่านมาถึงนี่แล้วอยากเริ่มทำของตัวเอง นี่คือลำดับที่ผมแนะนำ:

ขั้น 1 — List งานที่คุณทำซ้ำๆ

นั่งลงเขียนทุกงานที่ทำสัปดาห์ละครั้งขึ้นไป เขียนใบเสนอราคา ตอบลูกค้า เขียนโพสต์ คำนวณค่าใช้จ่าย — list ออกมาให้หมด นี่คือ Job Description ที่คุณต้องการ

ขั้น 2 — เลือก 1 พนักงาน เริ่มก่อน

อย่าสร้าง 30 คนพร้อมกัน คุณจะจัดการไม่ไหวและ debug ไม่ออก เริ่มจาก “งานที่หนักสุด” หรือ “งานที่ผิดบ่อย” — สร้าง 1 agent + skill ที่ครอบคลุมงานนั้น

ผมเริ่มจาก Marisa เพราะ marketing เป็นงานที่ผมไม่ชอบทำที่สุด แต่จำเป็นต้องทำเยอะ

ขั้น 3 — สร้าง Second Brain ขนาน

ไม่ต้องสมบูรณ์ตั้งแต่วันแรก — แค่เปิด Notion workspace ใหม่ 1 หน้า กับ Obsidian vault ที่ยังว่างเปล่า ก็พอ ที่สำคัญคือ “มีที่ให้ log” ก่อน เนื้อหาจะค่อยๆ สะสม

ขั้น 4 — + เรียนรู้การทำงานร่วมกันในระยะยาว ทำงานจริง → log outcome → ปรับ agent

นี่คือขั้นที่สำคัญที่สุด ใช้งาน agent กับงานจริง สังเกตว่าเขาทำได้ดีตรงไหน พลาดตรงไหน แล้วกลับไปแก้ description/skill/role-play ของเขา

ทำซ้ำหลายๆรอบ พนักงานจะเริ่มเข้ารูป ตอบสนองงานของคุณได้แม่นยำขึ้นเรื่อยๆ

ข้อผิดที่คนเริ่มต้นทำบ่อย

สร้างทุกอย่างก่อนใช้งาน — ผิด ใช้งานก่อน แล้วค่อยสร้างตามที่ขาด ผมเริ่มมีแค่ Marisa คนเดียว ค่อยๆ เพิ่ม Marina แล้ว Mathawee ตามที่งานบีบ
Agent กว้างเกินไป — “AI ที่ช่วยทำทุกอย่าง” = ไม่มีใครรับผิดชอบ ต้องแคบและเฉพาะ ดีกว่ามี 10 agent ที่เก่งเฉพาะทาง มากกว่ามี 1 agent ที่ทำได้ทุกอย่างแบบงั้นๆ
ลืมว่า boss ยังต้อง curate — AI ไม่ตัดสินใจแทนคุณ มันแค่ทำให้ขั้นกลางเร็วขึ้น คุณยังต้องเลือกว่าจะรับลูกค้าไหน ตั้งราคาเท่าไหร่ จะ pivot ไปทางไหน — และนี่คือเรื่องดี ไม่ใช่เรื่องน่าเศร้า เพราะนี่คือสิ่งที่ทำให้ธุรกิจของคุณยังเป็นของคุณ

ในตอนเริ่มผมเริ่มสร้างตัวผมและ มาริสา Assistant CEO ก่อน กำหนดบุคลิกและการทำงานอย่างชัดเจน ( เจนรูปประกอบได้ตามใจเรา ) และผมก็สร้างแผนก HR ให้มารับงานต่อจาก มาริสา เพื่อให้เค้าจ้างพนักงานเข้ามาตามที่ผมต้องการจนครบ

ช่วงนี้จะใช้ Token เยอะหน่อยและแนะนำให้ทำใน Claude code + ใช้ Opus เพราะ ผมต้องการทีมงานที่ฉลาด เหนื่อยตอนสร้างทีเดียวแต่หลังจากนั้นใช้งาน Sonnet ได้ยาวๆ เพราะเราวางโครงไว้ดีแล้ว

หลายๆครั้งที่ผมคิดงานไม่ออก ผมจะเรียก มาริสามาให้ไปเรียกพนักงานที่เกี่ยวข้องมา เช่น ขอเรียกประชุมพนักงานที่เกี่ยวข้องเพื่อมาหาไอเดียในการไปเสนอออกบูทขายที่ศูนย์ประชุมสิริกิต วันอาทิตย์หน้า มันก็จะออกมาประมาณนี้..

เป็นเรื่องเป็นราวกันเลยทีเดียว..

ปิดท้าย

บริษัทของคุณไม่จำเป็นต้องสร้างให้ใหญ่

ไม่ต้องมี 30 agent ไม่ต้องมี 6 ฝ่าย ไม่ต้องมี second brain ที่สมบูรณ์แบบตั้งแต่วันแรก

สิ่งที่สำคัญคือ — สร้างให้คุณคนเดียวทำงานได้เท่าทีม 10 คน นั่นแหละคือชัยชนะ

วันที่คุณรู้สึกว่า “ผมไม่ใช่คอขวดแล้ว” — วันนั้นคุณจะเข้าใจว่าทำไมผมถึงสร้างบริษัทเสมือนนี้ขึ้นมา

ไม่ใช่เพราะอยากดูล้ำ ไม่ใช่เพราะกระแส AI กำลังมา

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

บทความนี้จึงอยากสร้างแรงบันดาลใจให้กับคนที่ยังไม่รู้จะสร้างบริษัทของตัวเองอย่างไร

เพราะผมเชื่อว่ายุคต่อไป — solopreneur ทุกคนควรมีบริษัทของตัวเอง

แล้วเริ่มจากคุณ 1 คนก่อนได้เลยครับ..

ใครสงสัยอะไรทักมาถามได้ครับ…

genaispace.net : A Space to learn Generative AI Together

รับเทรนนิ่งองค์กรเกี่ยวกับการใช้ Generative AI เพื่อพัฒนาทักษะของพนักงาน เป็นองค์กร,บริษัท,กลุ่ม,เดี่ยว ด้วยประสบการณ์กว่า 3 ปี ผ่านองค์กรใหญ่ๆมากกว่า 60 แห่งและพนักงานกว่า 3,000 คน

สร้างบริษัทส่วนตัวด้วย AI: บันทึกการสร้าง บริษัท Gen AI Space Company ของผม