Vibe coding 指南：適用場景、常見風險與檢查方法

Vibe coding is building software by describing what you want in plain language and letting an AI agent write, run, and revise the code. You steer by reacting to what appears, rather than by writing each line yourself. The term was coined to describe a style of working, not a method, and it has spread quickly because it can turn an idea into a running prototype in an afternoon.

This article explains what vibe coding is, where it is strong, where it fails, and how to use it without building something fragile.

What vibe coding is

In a vibe-coding session, you:

1. describe the goal, such as "a page that lists orders and lets me mark them shipped",
2. let the agent generate the code and often run it,
3. look at the result, and describe the next change,
4. repeat until it works well enough to show someone.

The loop is fast, and the feedback is immediate. That speed is the appeal. The risk is that the loop optimises for "it looks right now", and says little about whether the code is correct, safe, or repeatable.

Where it works well

Vibe coding suits certain kinds of work:

• Prototypes and demos, where the goal is to test an idea with real users or stakeholders.
• Internal tools with a small audience and an owner who can fix problems quickly.
• Throwaway scripts that automate a one-off task.
• Exploring unfamiliar territory, such as a library you have never used, where a working example teaches more than a document.
• First drafts of interfaces, where the layout matters more than the internals.

In these cases the cost of a mistake is low, and the speed gain is large.

Where it breaks

Most failures of vibe-coded apps come from a small set of causes.

The agent invents things. It calls a method that does not exist, uses an option from a version you do not run, or assumes an API behaves the way it did in its training data. Checking the current documentation for the library catches many of these.

The happy path is the only path. The demo works with the input you typed. Empty fields, unexpected types, and slow networks are rarely exercised, so they fail in production.

It works on one machine. A lockfile out of step with the manifest, a global tool that is not in the repository, or a hard-coded path makes the app run for its author and nobody else.

Generated infrastructure drifts. Dockerfiles, routing config, and build files get hand-edited, then overwritten the next time something regenerates them. The change disappears without warning.

Secrets end up in the code. An example key copied into a real file is an easy mistake to make and an expensive one to find later.

Nobody can explain the result. When the author cannot describe what the code does, the next change is a guess, and the next bug is harder to find.

How to use it without getting burned

The fix is not to stop vibe coding. It is to add checks around the loop.

1. Start from a clean clone. If the app runs only in your existing environment, it is not ready.
2. Run the same install step your CI runs. Shortcuts that work locally are the usual source of CI failures.
3. Give the agent real tools. Documentation lookup, a test runner, a browser, and access to the running app let it check its own work instead of guessing.
4. Test the bad inputs on purpose. Send empty fields, wrong types, and oversized values.
5. Keep secrets out of the code. Read them from the environment and make sure the environment file is ignored by git.
6. Edit the source, not the generated output. When a tool writes your build files, change its input and regenerate.
7. Read the diff before accepting it. The speed of generation tempts people to skip review. Review anyway, especially for security and data handling.
8. Keep the plan written down. A short document with the goal, the constraints, and the checks makes a new session start where the last one stopped.

Tools that help

Model Context Protocol (MCP) servers give an agent access to things it would otherwise guess at: current documentation, a browser, a database, or a running local stack. Some of these are general, such as documentation lookup and browser testing. Others are tied to a specific tool. For example, TDK CLI can run a local multi-service stack and exposes it through tdk mcp, so an agent can start the stack, check readiness, and read recent logs. The agent sees the real state of the system, not its own summary of it.

Tools do not replace judgement. They make the agent's claims checkable.

What vibe coding does not replace

Architecture, security review, data protection, and operational responsibility still belong to people. An agent can write the code for a payment flow, but someone has to decide what the flow must guarantee, check that it does, and own the result when it fails.

Vibe coding changes how fast you can go from idea to running code. It does not change what makes software trustworthy.

Summary

Vibe coding is a fast loop of describing, generating, and reacting. It is excellent for prototypes, internal tools, and exploration, and it is risky when the output goes to users without checks. Use it with a clean-clone test, the same install step as CI, real tools the agent can run, tests for bad input, and a review of every diff. Keep the code you ship something you can explain.