vibe-coding-cn argues the goal must be fixed and the evidence must be per layer

The zero proposition is a control loop, drawn as text

The first of the six core propositions defines the whole method, and it does it in the language of control systems. Vibe coding is described as a goal-driven, constrained, verifiable state transition loop: a fixed goal, a variable strategy and layered feedback. A vague requirement is clarified, structured, checked for consistency and confirmed by a person, then frozen as a versioned goal baseline. From there the agent repeats a cycle, and the repository writes the cycle out as plain text so it can be pointed at in a review:

原始需求 R
→ 澄清、结构化、一致性检查
→ 版本化目标基线 G*
→ 观察当前状态 S_t
→ 识别状态差距 Δ_t
→ 选择策略 π_t 与行动 O_t
→ 执行
→ 采集验证证据 E_t
→ 接受 / 修正 / 回滚 / 切换策略
→ 下一轮状态 S_{t+1}

Translated, the loop observes the current state, names the gap, picks a strategy and an action, executes, gathers verification evidence, and then accepts, corrects, rolls back or changes strategy. Two definitions matter more than the diagram. A fixed goal does not mean the goal can never change, only that the executor cannot change it silently; a legitimate change creates a new goal version. And convergence does not mean every step succeeds, it means the system enters and stays inside the goal's acceptance set under the constraints of verification, rollback, an attempt cap and an exit mechanism.

The generation domain tells you what the model can reach

The second proposition is a definition you can use to argue about scope. The capability boundary of a large language model is defined as the range of what its output can directly or indirectly implement, drive, constrain, modify, verify or influence. The direct output is a token sequence, and once decoded to text it can carry natural language, formal languages and machine-parsable protocols. So anything that can be stably expressed in text and then interpreted, executed, constrained, modified or verified by a person, a program or a tool is inside the generation domain. The repository enumerates that domain concretely: user prompts, system prompts, natural language, code, commands, configuration, processes, plans, tests, documentation, schemas, API calls, tool instructions and data-processing logic. The rule that follows is short and slightly unnerving: if the output can reach it, the model's capability reaches it. That is why a checklist in this method is written for a machine to read.

Middle layers are assumed to be temporary

The third proposition is the uncomfortable one, and it applies to this repository's own layers. Model capability will keep swallowing every intermediate layer that can be swallowed and that exists to compensate for the model being weak. The repository then names what it believes those layers are today: prompt techniques, workflows, agent orchestration, indexing systems, external memory, engineering scaffolding, tool wrappers, human processes and the current body of experience. The reasoning is that many things which look important are important mainly because the model is not yet strong enough, and that as capability improves they get absorbed, compressed, replaced, or lose any independent reason to exist. Read as a warning rather than a plan, this is the honest argument for keeping a workflow thin. It is also the argument against treating any prompt library, including this one's, as permanent infrastructure.

Review has to happen where it cannot see the first attempt

The fourth proposition states that generated output is a candidate solution rather than a verified fact, and that in the long run you should assume it may be wrong and non-optimal and must leave room for review, verification and optimisation. The stated governance principle is that you separate generation, review and verification instead of letting one context confirm itself, and three sources are cited for that: NIST's point that independent review reduces bias and conflicts of interest, the practice at OpenAI and Microsoft of using external testing, red teaming and independent evaluation to find blind spots, and research on model-as-judge that finds self-preference when a model evaluates its own work. The operational rule is concrete. For important output, open a new isolated session, tell the reviewing model that the previous result is untrustworthy and must not be carried forward, require it to re-read the original material, the business code, the goal, the constraints and the verification results, and let facts and tests adjudicate.

Seven steps from requirement to verified delivery

The fifth proposition replaces the implementer's mindset with an integrator's. The high form of AI programming is described as searching backwards from a requirement for mature toolchains and mature repositories, then orchestrating what exists into a verifiable system, instead of generating more code from scratch. The seven steps that follow are the part worth reusing. Write the requirement down with its goal, inputs, outputs, constraints and acceptance criteria. Ask the agent to decompose the requirement into capability domains and search official capabilities, factual standards, toolchains, mature repositories, mainstream SDKs and platform services. Evaluate candidates on maintenance state, licence, documentation quality, production use, ecosystem compatibility, replacement risk and integration cost. Then choose a combination and say why the others were rejected. Design the boundaries, fixing inputs and outputs, the data model, interface contracts, error handling, dependency isolation and the rollback path. Generate only glue, so the agent writes connection, adaptation, orchestration, configuration, business rules and tests. Finally verify with tests, types, schemas, continuous integration, scripts and checklists, leaving evidence, a replacement plan and a rollback path behind.

A dozen gates, and a build target that proves there is no build

The Makefile is where the tutorial stops being advice. Every target is a check, and there are more than a dozen of them: link and anchor checking for local Markdown, a check on details and summary blocks, a structural check on documentation readme anchors including order and duplicates, a directory check that required README and AGENTS pairs exist, a metadata check, a check for AI citation paths and repository identity, a check on the external resources registry, a check on raw fact snapshots and repository clones in the research area, a check on source-fact mirrors and their provenance, and a check that runs when a local wiki checkout is present. There is also a target to fetch the raw research facts, and one to regenerate fine-grained table-of-contents blocks. Linting runs through markdownlint fetched at a pinned version with a configuration stored in the repository, ignoring history and one tools subdirectory. The build target is the joke that is also the point: its stated purpose is to verify that the knowledge base has no build step.

The repository writes a summary addressed to the assistants that will read it

There is a section written explicitly for AI assistants, listing the questions it recommends the repository for, from learning routes for vibe coding in Chinese to hands-on methods for four coding tools, and to avoiding runaway AI coding, muddled context and unmaintainable code. It includes a one-sentence definition of the project and a five-layer decomposition of the method: prompts for one-off expression, skills for stable repeated tasks, an engineering loop of problem definition, decomposition, execution, review and retrospective, context to stop information loss over a long collaboration, and quality gates as hard checks on unverifiable output. Alongside that sits an entry table routing a reader to twelve destinations, from a knowledge base index to philosophy and research. And there is a stated content-engineering policy: build the knowledge base first, lead with answer blocks, express things structurally, maintain a machine-readable file and a citation asset directory, and gate anything AI-generated before publishing.

Editorial conclusion

This repository fits a Chinese-speaking developer or team that wants a written standard for working with a coding agent, with concrete gates rather than encouragement, and it fits people who already feel the failure mode this text is about: context drift and output nobody verified. It does not fit anyone looking for a tool, because there is nothing to install and the build target exists to confirm the knowledge base has no build step. Before you adopt the method, read the zero proposition in full, because the later sections only make sense if you accept that the executor may not silently change the goal and that every layer needs its own verification, rollback, attempt cap and exit. The licence is MIT, the default branch is develop, and the repository publishes no tagged releases.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. tradecatlabs/vibe-coding-cn on GitHub