The AI-Native Era: Let LLMs Break Down Requirements Using DFS Thinking

From Traditional Prompting to an AI-Native Mindset

Most people still use large language models the old-fashioned way: writing long, exhaustive prompts that spell out every detail of what they want the model to do. But constrained by their own ability to articulate ideas clearly, they often can't write high-quality requirement descriptions and end up going back and forth in endless revision cycles — inefficient, to say the least.

The core insight from a Bilibili creator is this: LLMs are smarter than we give them credit for. We should let go of outdated thinking and shift toward an AI-Native approach. By analogy with Cloud Native — where capabilities are built into the platform and don't require extra development — AI-Native means the model already has the abilities you need. You just invoke them with a single sentence.

The key shift: instead of trying to write a perfect prompt upfront, let the LLM think on your behalf by asking you questions. You answer what it asks, and those exchanges accumulate in the context window. The richer the context, the more reliable the model's final output. Without enough information, models tend to go off track.

Cloud Native originated in software architecture to describe applications designed from the ground up for cloud environments — leveraging elasticity and distributed computing rather than simply moving legacy apps to the cloud. The AI-Native analogy: design your interactions around the model's native capabilities instead of trying to "tame" it with the mindset you'd use for traditional software (writing scripts, filling forms, listing rules). LLMs natively understand logical reasoning, structured analysis, and problem decomposition — and invoking these capabilities takes nothing more than a natural language instruction. The core shift is treating the model as a thinking collaborator, not an obedient execution tool.

DFS: Let the Model Ask Questions Layer by Layer

The core technique demonstrated is borrowed from computer science: DFS (Depth-First Search). You don't need to implement any code — just tell the LLM in plain language: please analyze my requirements using DFS.

Here's how the flow works:

• Start from the root node: Given your original goal, the model generates four question branches
• User selection and pruning: The model surfaces a tool (like a multi-select dialog) for you to check relevant options. Branches you don't select get pruned — some questions simply aren't relevant to your real goal
• Expand layer by layer: Each layer's questions stem from the previous layer's answers; select a branch and the model drills into four new sub-questions beneath it
• Converge and terminate: After at most four layers, the process stops — by now the context is rich enough

This works because the tree grows richer with each level, and so does your context. Compared to throwing a single sentence at the model and hoping for the best, this interactive tree-style questioning collects far more information — and the model's judgment becomes correspondingly more precise.

DFS (Depth-First Search) is a classic graph/tree traversal algorithm: start from the root, explore as far down one path as possible, then backtrack and try the next. Its counterpart, BFS (Breadth-First Search), visits all nodes on one level before moving to the next. The reason DFS suits requirements clarification: users only need to focus on one branch at a time, avoiding information overload. Through "keep what's relevant, prune what's not," the conversation consistently deepens along the path closest to the user's real goal. By the time you reach a sufficiently specific leaf node, the accumulated context is detailed enough for the model to generate targeted recommendations rather than generic advice.

Live Demo: From "Make ¥20K/Month on Social Media" to a Concrete Plan

The demo uses a relatable example: I want to be a content creator and make ¥20,000 a month.

If you just paste that sentence into a model, you'll get a flood of generic "here's what you should do" advice — because it's a generative model with no information about you personally.

But with the DFS prompting instruction in place, the dynamic changes entirely:

1. Layer 1: The model surfaces four strategic paths from the root goal (e.g., which type of content platform to focus on). The user selects two "paid" options — say, private community + paid services
2. Layer 2: Each retained path spawns new sub-questions; irrelevant branches get pruned; the user keeps one branch from each
3. Layer 3: The model drills into concrete constraints — weekly time available (user selects "under 10 hours"), starting capital (user selects "over ¥20,000"), existing accounts, professional skills, and so on
4. Convergence: After the agreed number of layers, the model generates a specific action plan (e.g., combining Douyin and Xiaohongshu with paid training offerings) built from everything collected along the way

The value isn't the plan itself — it's that the plan was generated after a series of targeted questions answered by the actual user, making it far more precise than anything produced from a single prompt.

Two Approaches: Write It All Out vs. Let the Model Ask

The creator wraps up by contrasting two paths to getting accurate output from an LLM:

Option 1 is the traditional approach — frontload every detail in your initial prompt: I don't have an account yet, I want to build a private community with paid services, I can only invest X hours per week… If you're capable of thinking through all the relevant considerations and expressing them clearly upfront, this works.

Option 2 is the "lazier but smarter" approach — when you yourself aren't sure which questions to even consider, use the model's questioning mode to do the thinking for you. It asks, you answer, and the process automatically builds up complete context. Then you ask for the plan.

Worth noting: the DFS prompt template can be copied directly onto any Agent — Claude Code, TreeWalk (used in the demo), or others. The method is platform-agnostic. The creator also mentions a community-shared skill called "BornMe" that follows a similar philosophy of using iterative questioning to accumulate context and improve output quality.

Significance and Limitations of This Approach

At its core, the DFS / goal-tree methodology shifts part of the structured-thinking responsibility onto the LLM. Its elegance lies in translating algorithmic concepts (depth-first search, tree pruning) into natural language that the model already understands — a textbook example of AI-Native capability in action.

That said, a few caveats are worth keeping in mind. This content comes from a single creator's demo and personal experience. The specific parameters — four branches per level, four levels max — are demo settings, not rigorously validated optimal values. The technique's effectiveness also depends heavily on the model's support for tool calling (e.g., multi-select dialogs). If you want to try it, treat it as a transferable prompting framework rather than a fixed formula, and adjust branch count and depth to fit your actual needs.

Tool Use / Function Calling refers to an LLM's ability to invoke predefined external tools during a conversation — such as rendering a multi-select dialog, executing a search, or writing to a file — and incorporate the results into its subsequent reasoning. The multi-select popup in the demo relies on this mechanism: the model generates a structured tool call request, the frontend or Agent framework renders the interactive UI component, and the user's selections are passed back to the model as text. Not all models or platforms support custom tool calls. In environments without this support, the same DFS logic can degrade gracefully to plain-text interaction: the model presents numbered lists of questions, the user replies with their numeric choices. The experience is slightly less polished, but the core approach remains fully usable.