If you don’t give the AI direction, it can’t drive you to the destination.

I hit a surprisingly common trap while building an app demo with Figma Make.

My instruction to the agent was simple:

Please implement based on what’s in my Figma Make share link.

Sounds reasonable.

But here’s the problem: a share link is usually a demo, not a behavioral spec.

What I got wrong

To move fast, I made the starting screen the main tab bar in my Figma Make project.

The agent did exactly what it saw:

• it treated the demo as the requirement
• it implemented “launch → main tab”

For a demo, that can be fine.

For a real product, it’s usually wrong.

A real mobile app launch is a state machine

On mobile, a standard launch flow is not “whatever the first UI looks like.”

Typically, after app launch you enter a dedicated launch activity/view controller and run a state machine, for example:

1) Force update / soft update / OK

2) Only if OK → check whether we can auto-login

• if yes → go to main tab
• if not → go to login

Those conditions and branches are the direction.

The UI is just the outcome.

Why I thought the agent was “overwriting” my work

At first, I kept thinking the agent wasn’t following my instructions and kept changing my implementation.

Then I checked the React site Figma Make actually built.

The flow was already “locked in” by my demo.

In other words:

• the demo defined the world I gave the agent
• the agent simply inferred behavior from visible states

The agent didn’t fail.

My direction did.

Takeaway: define behavior before UI

If you want AI to build the right UI, define behavior first:

• entry states
• branching conditions
• success criteria

UI is the outcome.

The flow is the direction.

Editor

Strengths:

• Strong hook and clear single point.
• Concrete details (Figma Make, React build verification, update/auth branches) make it credible.

Edits for the final:

• Move “demo ≠ spec” earlier so the main contrast shows up faster.
• End with a tight checklist readers can reuse.

Final

If you don’t give the AI direction, it can’t drive you to the destination.

I hit a common trap while building an app demo with Figma Make.

My instruction to the agent was:

Please implement based on what’s in my Figma Make share link.

Sounds reasonable—until you realize the link is a demo, not a behavioral spec.

To move fast, I made the starting screen the main tab bar.

So the agent did exactly what it saw:

• it treated the demo as the requirement
• it implemented “launch → main tab”

But real mobile app launch is a state machine.

Typically, after app launch you enter a dedicated launch activity/view controller and run checks like:

1) Force update / soft update / OK

2) Only if OK → check whether we can auto-login

• if yes → main tab
• if not → login

At first, I thought the agent was ignoring instructions and “overwriting” my work.

Then I checked the React site Figma Make actually built—the flow was already locked in by my demo.

The agent didn’t fail.

My direction did.

Takeaway: define behavior before UI.

A minimal checklist:

• entry states
• branching conditions
• success criteria

UI is the outcome.

The flow is the direction.

Keep your frontend and backend in the same folder.

This isn’t a new concept. Mono repos have been around forever. But in the age of Vibe Coding, their value multiplies.

Why Mono Repo Matters for AI Agent Coding

When you use an AI agent to write code, its understanding is limited to the context you give it.

If your frontend and backend live in two separate repos:

• The AI can only see one side at a time
• It doesn’t know what the other side’s API looks like
• You become the translator, manually feeding information back and forth

But if they’re in the same repo:

• The AI can read your frontend’s call logic and your backend’s API definition at the same time
• When you change a backend response format, it can automatically update the corresponding frontend fields
• Shared types, schemas, and configs stay in sync — no more drift between two repos

In short, a mono repo gives the AI complete context. Complete context means more accurate code generation.

Recommended Folder Structure

It doesn’t need to be complicated. This is enough:

my-project/
├── frontend/          ← React / Next.js
├── backend/           ← Node.js / Express / FastAPI
├── package.json
└── README.md

If you have shared type definitions or utility functions, add another layer:

my-project/
├── frontend/          ← React / Next.js
├── backend/           ← Node.js / Express / FastAPI
├── shared/            ← Shared types, constants, utilities
├── package.json
└── README.md

The point isn’t a perfect structure — it’s that frontend and backend live under the same root directory.

Separate Repos vs Mono Repo

When you’re Vibe Coding, these differences get amplified. The more you rely on AI, the more its context window matters.

How to Get Started

If your current project already has separate repos, no need for a big migration. You can:

1. Create a new folder and pull both repos in (via submodules or just move them)
2. Start your next project with a mono repo structure from day one
3. Try letting an AI agent modify both frontend and backend in a mono repo — feel the difference

Wrap Up

The key to Vibe Coding isn’t just which AI tool you use — it’s how you organize your project so the AI can do its best work.

A mono repo is the lowest-cost, highest-return move you can make.

Try it. You’ll find it surprisingly efficient.

把前端和後端放在同一個資料夾裡。

這不是什麼新概念，mono repo 已經存在很久了。但在 Vibe Coding 的時代，它的價值被放大了好幾倍。

為什麼 Mono Repo 對 AI Agent Coding 很重要？

當你用 AI agent 來寫程式，它的理解範圍就是你給它的 context。

如果你的前端和後端分成兩個 repo：

• AI 只看得到其中一邊
• 它不知道另一邊的 API 長什麼樣
• 你得自己當翻譯，把另一邊的資訊手動餵給它

但如果它們在同一個 repo 裡：

• AI 可以同時讀到前端的呼叫邏輯和後端的 API 定義
• 改了後端的 response format，它能自動幫你更新前端的對應欄位
• 共用的 type、schema、config 放在一起，不會出現兩邊不同步的問題

簡單來說，mono repo 讓 AI 的 context 變完整了。Context 完整，生成的程式碼就更準確。

推薦的資料夾結構

不需要太複雜，這樣就夠了：

my-project/
├── frontend/          ← React / Next.js
├── backend/           ← Node.js / Express / FastAPI
├── package.json
└── README.md

如果你有共用的型別定義或工具函式，可以再加一層：

my-project/
├── frontend/          ← React / Next.js
├── backend/           ← Node.js / Express / FastAPI
├── shared/            ← 共用型別、常數、工具函式
├── package.json
└── README.md

重點不是結構多完美，而是前後端在同一個根目錄下。

分開 vs 合在一起的差別

當你在 Vibe Coding 的時候，這些差異會被放大。因為你依賴 AI 的程度越高，它能掌握的 context 就越重要。

怎麼開始？

如果你現在的專案已經是前後端分開的，不用急著大改。可以：

1. 開一個新資料夾，把兩個 repo 用 submodule 或直接搬進來
2. 下一個新專案，直接用 mono repo 結構開始
3. 試著讓 AI agent 在 mono repo 裡同時修改前後端，感受一下差異

結語

Vibe Coding 的關鍵不只是用哪個 AI 工具，更是你怎麼組織你的專案讓 AI 能發揮最大效果。

Mono repo 就是最低成本、最高回報的一步。

試試看，你會發現這個效率很高

Not a full SaaS. Not a long course. Not a bloated template bundle.

Just a small, focused prompt artifact that does one job clearly.

That is the format I want to explore more deliberately.

So I’m starting a small series of compact source prompts: one-shot prompt products designed around specific workflows, with each one acting as a reusable technical artifact rather than a piece of content dressed up as a product.

The first one is:

LLM Knowledge Base Source Prompt
https://marvinsight.gumroad.com/l/llm-knowledge-base-source-prompt

The idea behind this product line

There are already plenty of large products for AI builders:

• full frameworks
• heavy starter kits
• video courses
• giant prompt packs

Those can be useful.

But I think there is also room for something smaller and sharper: artifacts that are compact enough to study in one sitting, specific enough to be immediately useful, and structured enough to be reused or adapted in real work.

That is the bet behind this series.

I’m interested in making tiny, high-leverage prompt products that behave more like source artifacts than marketing assets.

Why start with a knowledge base prompt

A lot of AI work eventually runs into the same problem:

How do you turn raw notes, scattered decisions, working files, and project context into something durable?

Not just searchable.

Not just pretty.

Actually durable.

For me, that usually means:

• markdown-first structure
• Git-friendly organization
• content that humans can maintain
• content that agents can also read and extend
• a system that does not collapse into a thin docs UI with weak information architecture

That is why the first product in this series is centered on a knowledge base.

Karpathy, X, and the gist-like artifact

A key part of the inspiration came from Andrej Karpathy, and I want to be explicit about that.

This product direction was not something I came up with in isolation. It was shaped in part by seeing Karpathy frame markdown, text files, and compact source artifacts as serious interfaces for LLM workflows.

In particular, these references mattered:

• Karpathy’s gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
• Karpathy’s X post: https://x.com/karpathy/status/2039805659525644595?ref=anduril.tw

What I found compelling there was not just the specific content, but the format itself: a compact, portable artifact that carries a lot of implementation direction without pretending to be an entire product by itself.

That framing mattered to me.

I did not want to sell “AI vibes.”

I wanted to package a source specification that someone could actually use, inspect, adapt, and build from.

What this first prompt is for

LLM Knowledge Base Source Prompt is designed to generate a markdown-first internal wiki and LLM-friendly knowledge base starter.

The target output includes:

• Next.js App Router
• Fumadocs
• MDX-based content
• static export compatibility
• a dashboard-style homepage
• structured content for Tasks / Repos / Topics / Decisions / People / Daily
• English-first content with Traditional Chinese as an alternate locale

The point is not to create a generic docs shell.

The point is to give builders a stronger starting structure for long-term knowledge capture.

In other words, this is less about “generate me a docs site” and more about:

generate me a usable knowledge system from a compact source artifact.

What you are buying

You are buying the prompt itself.

More specifically, you are buying a focused source prompt that you can:

• paste into Claude
• adapt for other coding models
• fork into your own internal wiki workflow
• use as a starting point for agent memory or team knowledge infrastructure

So the product is not the finished website.

It is the source-level artifact that helps produce one.

Why this format matters to me

I like products that are small enough to understand.

A compact prompt artifact can still contain:

• product thinking
• information architecture
• implementation direction
• editorial judgment about what belongs in the system

That makes it a surprisingly good product form.

It is easy to ship, easy to revise, easy to remix, and easy for other builders to evaluate quickly.

That is exactly why I think this format is worth exploring as a series, not just as a one-off experiment.

The first entry in a broader series

This knowledge base prompt is the first entry.

It will not be the last.

My goal is to build a line of one-shot prompt products where each one has:

• a clear use case
• a concrete output shape
• a compact but serious source artifact behind it

This first release happens to be about markdown-first knowledge systems.

Future ones may target other focused workflows with the same philosophy.

Product link

If this specific workflow is relevant to you, you can check it out here:

https://marvinsight.gumroad.com/l/llm-knowledge-base-source-prompt

I’m less interested in making prompt products that feel disposable.

I’m more interested in making small technical artifacts that people can actually build with.

This is the first one.

你沒給 AI 正確方向，它就載不到你要去的地方。

我今天踩了一個很典型、也很容易被忽略的坑：

我叫 AI agent：

請參考 Figma Make share link 中的內容，進行實作。

聽起來很合理對吧？

但問題是：share link 裡的內容，其實是 demo，不是產品的行為規格（behavior spec）。

我到底給錯了什麼？

為了 demo 快，我在 Figma Make 裡把 app 的起始畫面直接做成 main tab bar。

於是 AI 真的超級「聽話」：

• 它把 demo 當成真需求
• 直接實作成「一進 app 就進主頁」

這在 demo 上看起來沒問題。

但在 mobile app 上，這通常不是你想要的真實行為。

標準的 mobile app launch 其實是一個 state machine

在 mobile app 上，標準手法通常是：app launch 後先進入一個 Launch Screen 的 activity / view controller，然後在這個實例物件中做判斷。

例如一個常見流程會是：

1) 強迫更新 / 建議更新 / 可正常使用

2) 在「可正常使用」之後，才檢查是否可以 auto login

• if yes → go to main tab bar
• if not → go to login page

這些條件與分支，才是「方向」。

UI 長什麼樣，是結果。

我為什麼會一直以為 AI 在亂改？

我一開始一直以為：AI 沒有照我的指令做、一直改掉我的實作。

最後我去檢查 Figma Make build 起來的 React 網站，才發現網站的流程就是如此設計。

換句話說：

• 我給 AI 的「世界」就是那個 demo
• AI 只能照我給的可見狀態去估

它沒錯。

錯的是我一開始給的方向：我給的是 demo，不是行為規格。

結論：要 AI 做對 UI，先把「行為規格」寫清楚

你要 AI 做對 UI，先定義「行為」：

• 入口狀態（entry states）
• 分支條件（branching conditions）
• 成功條件（success criteria）

UI 是結果；流程才是方向。

Editor

這篇要傳達的核心很清楚，也符合 builder 角度：

• 不是模型問題，是 workflow/spec 的問題
• 有具體工具（Figma Make）與具體流程（update → auth → main/login）支撐可信度

我在 final 只做兩個「不改意思」的微調： 1) 讓「demo vs spec」對比更快出現（更像文章的主線） 2) 結尾再強化一次可複用的 checklist

Final

你沒給 AI 正確方向，它就載不到你要去的地方。

我今天踩了一個很典型、也很容易被忽略的坑。

我叫 AI agent：

請參考 Figma Make share link 中的內容，進行實作。

聽起來很合理。

但我後來才發現：share link 裡的內容，其實是 demo，不是產品的行為規格（behavior spec）。

為了 demo 快，我在 Figma Make 裡把 app 的起始畫面直接做成 main tab bar。

於是 AI 真的超級「聽話」：

• 它把 demo 當成真需求
• 直接實作成「一進 app 就進主頁」

但在 mobile app 上，標準的啟動流程通常不是「看 UI 長什麼樣」，而是先跑一個 state machine。

一般做法是：app launch 後先進入 Launch Screen 的 activity / view controller，然後在這個實例物件中做判斷，例如：

1) 強迫更新 / 建議更新 / 可正常使用

2) 在「可正常使用」之後，才檢查是否可以 auto login

• if yes → go to main tab bar
• if not → go to login page

我一開始一直以為：AI 沒有照我的指令做、一直改掉我的實作。

最後我去檢查 Figma Make build 起來的 React 網站，才發現網站的流程就是如此設計。

換句話說：

• 我給 AI 的「世界」就是那個 demo
• AI 只能照我給的可見狀態去估

它沒錯。

錯的是我一開始給的方向：我給的是 demo，不是行為規格。

結論很簡單：要 AI 做對 UI，先把行為規格寫清楚。

一個最小 checklist：

• 入口狀態（entry states）
• 分支條件（branching conditions）
• 成功條件（success criteria）

UI 是結果；流程才是方向。

Have you ever thought that a browser could do more than just open websites?
Now there’s an AI browser called Comet, designed to make “researching online” smarter and more efficient.
Let’s dive right in — here’s what this trending AI tool is, what it can do, and what you should pay attention to.

1. What Is Comet?

Comet is an AI browser created by Perplexity, built around the concept of “thinking while browsing.”
In short, it doesn’t just open pages — it helps you summarize, organize, and compare information, so finding what you need no longer feels like searching for a needle in a haystack.
It’s built on the Chromium framework, meaning it supports Chrome extensions and requires almost no learning curve.
Originally limited to paid users, Comet is now available for everyone to download for free.

2. What Can It Do?

• AI Search Summaries: Instead of giving you a list of links, Comet provides concise summaries with cited sources.
• AI Assistant Sidebar: Ask questions, compare data, translate content, or explore related topics right from the page.
• Automation Tools: With your permission, it can help you compare prices, organize schedules, or send emails.
• Cross-Tab Organization: Even with multiple tabs open, Comet can automatically summarize and connect their content.

3. Why People Use It

Comet feels incredibly smooth to use.
You no longer need to juggle ten tabs for research, note-taking, and fact-checking — the AI connects everything for you.
Most impressively, it’s not just a search tool; it’s like a shared brain that thinks and makes decisions alongside you.

4. A Note on Security and Privacy

While AI tools are convenient, always stay alert about privacy and data security.
Comet analyzes your browsing activity to generate suggestions.
In short: don’t let AI handle sensitive or confidential operations — keeping human judgment in the loop is always the safest choice.

5. Final Reminder

If you’d like to try this AI browser, you can download it directly from the official website.
Even better, I have a personal referral code — use my link https://pplx.ai/atimis193889 to unlock early access or get extra usage credits.

Referral Link

Want to see how powerful “AI-assisted browsing” can be?
Try it now — next time you’re doing research, you might just feel like you’ve turned on a cheat code.

你有沒有想過，瀏覽器不只是開網頁那麼簡單？現在有一款叫 Comet 的 AI 瀏覽器，正在讓「上網查資料」這件事變得更聰明、更有效率。
話不多說，我幫你快速介紹這個最近爆紅的 AI 工具是什麼、能幹嘛、要注意什麼。

一、什麼是 Comet？

Comet 是由 Perplexity 推出的 AI 瀏覽器，主打「邊瀏覽邊思考」。
簡單說，它不只幫你開網站，還會幫你整理、摘要、比較，讓查資料不再像是在深海裡撈針。
它基於 Chromium 架構，所以能支援 Chrome 擴充功能，也不會有學習門檻。
一開始 Comet 只給付費用戶試用，現在已經開放給所有人免費下載。

二、它能幫你做什麼？

• AI 搜尋摘要：輸入關鍵字後，它不只丟連結，而是直接幫你整合重點、附上來源。
• AI 助手側邊欄：可以即時問問題、幫你對比資料、翻譯或延伸查詢。
• 自動化操作：授權後，它甚至能幫你比價、整理日程、寄信。
• 跨分頁整理：開太多分頁也不怕，Comet 會自動幫你總結不同頁面的重點。

三、為什麼大家在用？

Comet 的體驗很「順」。
你不用再開十幾個分頁查資料、記筆記、找答案，AI 幫你串起整個流程。
最特別的是，它不只是搜尋器，而像是一個「共用大腦」—— 跟你一起思考、決策。

四、請注意資安風險

AI 雖然方便，但也要注意 資安與隱私。
Comet 會分析你瀏覽的內容來提供建議 簡單說：機敏性高的操作不要交給 AI 處理，保持人腦在場最安全。

五、最後小提醒

如果你想試試這款 AI 瀏覽器，可以直接去官方網站下載。
更棒的是，我有一個 專屬邀請碼 —— 使用我的推薦碼 https://pplx.ai/atimis193889，就能提前體驗新功能或拿額外的使用額度。

推薦碼連結

想感受「AI 幫你上網」的威力？趁現在就試試看。
說不定下次查資料，你會懷疑自己是不是開了外掛。

How to Switch to Plan Mode - Shift + Tab

In Claude Code, you can use the shortcut Shift + Tab to switch modes. The first switch is to auto accept mode. You can see the prompt at the bottom of the terminal to know which mode you’re currently in. Press Shift + Tab a second time to enter plan mode. When you enable plan mode, Claude enters a state focused on thinking and planning. At this time, Claude Code will not modify your code but will list the steps it will take and the implementation blueprint. So you can safely conduct various confirmations and divergent thinking.

First Press of Shift + Tab - Enter Auto Accept Mode

Use Shift + Tab to Enter Plan Mode

Advantages of Think Mode

Plan First, Then Execute

When you make a request to Claude in think mode, Claude will first analyze and think about your requirements, then provide a detailed plan blueprint.

View Implementation Blueprint

In plan mode, Claude will display a complete implementation plan, allowing you to understand the entire implementation process before actual execution.

Execute After Confirmation

When you confirm the plan, Claude will start executing actual code modifications based on the previous planning.

Personal Thoughts

Before knowing about plan mode, I used prompts to prevent Claude Code from directly modifying code, instead asking it to give me a general direction and steps first. However, when using prompts alone, sometimes Claude Code would still directly initiate modifications. Moreover, since I mostly develop iOS apps, it would often directly execute Xcode build or other Xcode CLI commands.

In plan mode, I feel the quality of modification context has improved, and the solutions it proposes in plan mode have preserved the concept of Canvas or artifacts in the UI, allowing for minor modifications to the same file without affecting the overall structure and logic.

This is what I like most about it. After all, I need to get things done right first before I can start asking AI to do things well.

Related Articles

• How to Paste Screen Captures to Claude Code Editor on macOS (English)

• 將螢幕的截圖貼上到 Claude 的程式碼編輯器的方法，macOS 適用 (Chinese)

切換 think mode 的方法 - shift + tab

在 Claude code 中，你可以使用快捷鍵 shift + tab 來切換 mode。第一次的切換是 auto accept mode，你可以看 terminal 下方的提示，來知道現在的 mode 是哪一種。按第二次 shift + tab 就會進入 think mode。當你啟用 think mode 後，Claude 會進入一種專注於思考和規劃的狀態，這時候 claude code 並不會去更動你的程式碼，而是列出他會進行的步驟，以及如何實作的藍圖 (blueprint)。所以你可以放心的進行各種確認和發散的思考。

第一次按 shift + tab - 進入 auto accept mode

用 shift + tab 進入 think mode

think mode 的優點

先規劃再執行

當你在 think mode 中向 Claude 提出請求時，Claude 會先分析和思考你的需求，然後提供一個詳細的計劃藍圖。

查看實作藍圖

在 think mode 中，Claude 會展示完整的實作計劃，讓你可以在實際執行之前就了解整個實作流程。

確認後執行

當你確認計劃後，Claude 會根據之前的規劃開始執行實際的程式碼修改。

心得

在不知道 think mode 之前的我，是使用 prompt 讓 Claude code 不要直接修改程式碼，而是先給我一個大概的方向和步驟。只是，單純用 prompt 時，有時候 claude code 還是會直接發動修改。而且因為我大多時間是開發 iOS，常常會直接執行到 xcode build or 其他 xcode cli 指令。

在 think mode 下，我覺得修改的上下文品質有提高，而且他在 think mode 提出的方案， UI 有保留 Canvas or artifacts 的概念，可以做到同一份檔案做小幅度的修改，而不會影響到整體的結構和邏輯。

這是我最喜歡的地方，畢竟，要先把事情做對，我才可以開始要求 AI 把事情做好。

相關文章

• How to Paste Screen Captures to Claude Code Editor on macOS (English)

• 將螢幕的截圖貼上到 Claude 的程式碼編輯器的方法，macOS 適用 (Chinese)

Nintendo Mario Kart Download Link

Wallpaper 1

Mobile - 1320 x 2868

Mobile - 1440 x 2560

Desktop

Wallpaper 2

Mobile - 1320 x 2868

Mobile - 1440 x 2560

Desktop

Other Wallpaper Links

Mario Wonder - Wallpapers Available for Download on Nintendo’s Official Website

The Legend of Zelda - Tears of the Kingdom Wallpapers Available on Nintendo’s Website