mirror of
https://github.com/tradecatlabs/vibe-coding-cn.git
synced 2026-08-25 16:48:28 +00:00
docs: 新增 OpenCode CLI 配置入门文档
This commit is contained in:
@@ -0,0 +1,11 @@
|
||||
Applying Dialectical Thesis-Antithesis-Synthesis to Vibe Coding: I treat each coding session as a round of "triadic progression"
|
||||
|
||||
Thesis (Current State): First let the model quickly provide the "smoothest implementation" based on intuition, with only one goal: get the main path running as soon as possible
|
||||
|
||||
Antithesis (Audit & Tuning): Immediately take the "critic" perspective and challenge it: list failure modes/edge cases/performance and security concerns, and ground the challenges with tests, types, lint, benchmarks
|
||||
|
||||
Synthesis (Correction Based on Review): Combine speed with constraints: refactor interfaces, converge dependencies, complete tests and documentation, forming a more stable starting point for the next round
|
||||
|
||||
Practice Mantra: Write smoothly first → Then challenge → Then converge
|
||||
|
||||
Vibe is responsible for generating possibilities, thesis-antithesis-synthesis is responsible for turning possibilities into engineering certainties
|
||||
@@ -0,0 +1,107 @@
|
||||
### Phenomenological Reduction (Suspension of Assumptions) for Vibe Coding
|
||||
|
||||
**Core Purpose**
|
||||
Strip "what I think the requirement is" from the conversation, leaving only observable, reproducible, and verifiable facts and experience structures, allowing the model to produce usable code with fewer assumptions.
|
||||
|
||||
---
|
||||
|
||||
## 1) Key Methods (Understanding in Engineering Context)
|
||||
|
||||
* **Epoché (Suspension)**: Temporarily withhold any "causal explanations/business inferences/best practice preferences."
|
||||
Only record: what happened, what is expected, what are the constraints.
|
||||
|
||||
* **Reduction**: Reduce the problem to the minimal structure of "given input → process → output."
|
||||
Don't discuss architecture, patterns, or tech stack elegance first.
|
||||
|
||||
* **Intentionality**: Clarify "who this feature is for, in what context, to achieve what experience."
|
||||
Not "make a login," but "users can complete login within 2 seconds even on weak networks and get clear feedback."
|
||||
|
||||
---
|
||||
|
||||
## 2) Applicable Scenarios
|
||||
|
||||
* Requirements descriptions full of abstract words: fast, stable, like something, intelligent, smooth.
|
||||
* Model starts "bringing its own assumptions": filling in product logic, randomly selecting frameworks, adding complexity on its own.
|
||||
* Hard to reproduce bugs: intermittent, environment-related, unclear input boundaries.
|
||||
|
||||
---
|
||||
|
||||
## 3) Operating Procedure (Can Follow Directly)
|
||||
|
||||
### A. First "Clear Explanations," Keep Only Phenomena
|
||||
|
||||
Describe using four elements:
|
||||
|
||||
1. **Phenomenon**: Actual result (including errors/screenshots/log fragments).
|
||||
2. **Intent**: Desired result (observable criteria).
|
||||
3. **Context**: Environment and preconditions (version, platform, network, permissions, data scale).
|
||||
4. **Boundaries**: What not to do/not to assume (don't change interface, don't introduce new dependencies, don't change database structure, etc.).
|
||||
|
||||
### B. Produce "Minimal Reproducible Example" (MRE)
|
||||
|
||||
* Minimal input sample (shortest JSON/smallest table/smallest request)
|
||||
* Minimal code snippet (remove unrelated modules)
|
||||
* Clear reproduction steps (1, 2, 3)
|
||||
* Expected vs. Actual (comparison table)
|
||||
|
||||
### C. Reduce "Abstract Words" to Testable Metrics
|
||||
|
||||
* "Fast" → P95 latency < X, cold start < Y, throughput >= Z
|
||||
* "Stable" → Error rate < 0.1%, retry strategy, circuit breaker conditions
|
||||
* "User-friendly" → Interaction feedback, error messages, undo/recovery capability
|
||||
|
||||
---
|
||||
|
||||
## 4) Prompt Templates for Models (Can Copy Directly)
|
||||
|
||||
**Template 1: Reduce Problem (No Speculation)**
|
||||
|
||||
```
|
||||
Please first do "phenomenological reduction": don't speculate on causes, don't introduce extra features.
|
||||
Based only on the information I provide, output:
|
||||
1) Phenomenon (observable facts)
|
||||
2) Intent (observable result I want)
|
||||
3) Context (environment/constraints)
|
||||
4) Undetermined items (minimum information that must be clarified or I need to provide)
|
||||
5) Minimal reproducible steps (MRE)
|
||||
Then provide the minimal fix solution and corresponding tests.
|
||||
```
|
||||
|
||||
**Template 2: Abstract Requirements to Testable Specs**
|
||||
|
||||
```
|
||||
Apply "suspension of assumptions" to the following requirements: remove all abstract words, convert to verifiable specs:
|
||||
- Clear input/output
|
||||
- Clear success/failure criteria
|
||||
- Clear performance/resource metrics (if needed)
|
||||
- Clear what NOT to do
|
||||
Finally provide acceptance test case list.
|
||||
Requirements: <paste>
|
||||
```
|
||||
|
||||
---
|
||||
|
||||
## 5) Concrete Implementation in Vibe Coding (Building Habits)
|
||||
|
||||
* **Write "phenomenon card" before each work session** (2 minutes): phenomenon/intent/context/boundaries.
|
||||
* **Have the model restate first**: require it to only restate facts and gaps, no solutions allowed.
|
||||
* **Then enter generation**: solutions must be tied to "observable acceptance" and "falsifiable tests."
|
||||
|
||||
---
|
||||
|
||||
## 6) Common Pitfalls and Countermeasures
|
||||
|
||||
* **Pitfall: Treating explanations as facts** ("Might be caused by cache")
|
||||
Countermeasure: Move "might" to "hypothesis list," each hypothesis with verification steps.
|
||||
|
||||
* **Pitfall: Requirements piled with adjectives**
|
||||
Countermeasure: Force conversion to metrics and test cases; no writing code if not "testable."
|
||||
|
||||
* **Pitfall: Model self-selecting tech stack**
|
||||
Countermeasure: Lock in boundaries: language/framework/dependencies/interfaces cannot change.
|
||||
|
||||
---
|
||||
|
||||
## 7) One-Sentence Mantra (Easy to Put in Toolbox Card)
|
||||
|
||||
**First suspend explanations, then fix phenomena; first write acceptance criteria, then let model write implementation.**
|
||||
@@ -95,5 +95,12 @@ In the paradigm of Vibe Coding, we are no longer just "typists" but "architects
|
||||
* **Reflective Equilibrium**: Iteratively calibrating specific judgments and general principles for systemic consistency.
|
||||
* **Conceptual Engineering**: Actively engineering and optimizing conceptual tools to serve Vibe Coding practices.
|
||||
|
||||
---
|
||||
|
||||
## Detailed Method Guides
|
||||
|
||||
- [Phenomenological Reduction](./Phenomenological%20Reduction.md) - Suspension of assumptions for clear requirements
|
||||
- [Dialectics](./Dialectics.md) - Thesis-Antithesis-Synthesis iterative development
|
||||
|
||||
---
|
||||
*Note: This content evolves continuously as the supreme ideological directive of the Vibe Coding CN project.*
|
||||
|
||||
@@ -1,15 +1,13 @@
|
||||
# 📖 Documents
|
||||
# 📚 Documents
|
||||
|
||||
> Documentation library for Vibe Coding methodology, guides, and resources
|
||||
> Vibe Coding knowledge system, organized by learning path
|
||||
|
||||
---
|
||||
|
||||
## 📁 Directory Structure
|
||||
## 🗺️ Directory Structure
|
||||
|
||||
```
|
||||
documents/
|
||||
├── -01-philosophy-and-methodology/ # Supreme ideological directive
|
||||
├── 00-fundamentals/ # Core concepts & principles
|
||||
├── -01-philosophy-and-methodology/ # Supreme ideological directive, underlying logic
|
||||
├── 00-fundamentals/ # Core concepts, glue coding, methodology
|
||||
│ ├── Glue Coding.md
|
||||
│ ├── Language Layer Elements.md
|
||||
│ ├── Common Pitfalls.md
|
||||
@@ -44,6 +42,26 @@ documents/
|
||||
└── Recommended Programming Books.md
|
||||
```
|
||||
|
||||
## 🚀 Quick Navigation
|
||||
|
||||
| Directory | Description | Target Audience |
|
||||
|:----------|:------------|:----------------|
|
||||
| [-01-philosophy-and-methodology](./-01-philosophy-and-methodology/) | Ideological principles, epistemological tools | Architects & advanced developers |
|
||||
| [00-fundamentals](./00-fundamentals/) | Glue coding, core concepts | Understanding fundamentals |
|
||||
| [01-getting-started](./01-getting-started/) | Environment setup, from zero | Beginners |
|
||||
| [02-methodology](./02-methodology/) | Tool tutorials, development experience | Improving efficiency |
|
||||
| [03-practice](./03-practice/) | Project experience, case reviews | Hands-on practice |
|
||||
| [04-resources](./04-resources/) | Templates, tools, external links | Reference lookup |
|
||||
|
||||
## 📖 Recommended Learning Path
|
||||
|
||||
1. **Philosophy** → [-01-philosophy-and-methodology](./-01-philosophy-and-methodology/README.md)
|
||||
2. **Concepts** → [Glue Coding](./00-fundamentals/Glue%20Coding.md)
|
||||
3. **Getting Started** → [Vibe Coding Philosophy](./01-getting-started/00-Vibe%20Coding%20Philosophy.md)
|
||||
4. **Setup** → [Development Environment Setup](./01-getting-started/02-Development%20Environment%20Setup.md)
|
||||
5. **Tools** → [tmux Shortcut Cheatsheet](./02-methodology/tmux%20Shortcut%20Cheatsheet.md)
|
||||
6. **Practice** → [Practical Examples](./03-practice/)
|
||||
|
||||
---
|
||||
|
||||
## 🗂️ Categories
|
||||
@@ -51,6 +69,8 @@ documents/
|
||||
### -01-philosophy-and-methodology
|
||||
Supreme ideological directive and epistemological tools:
|
||||
- **Philosophy & Methodology** - The underlying protocol of Vibe Coding
|
||||
- **Phenomenological Reduction** - Suspension of assumptions for clear requirements
|
||||
- **Dialectics** - Thesis-Antithesis-Synthesis iterative development
|
||||
|
||||
### 00-fundamentals
|
||||
Core concepts and methodology:
|
||||
|
||||
Reference in New Issue
Block a user