108 lines
4.3 KiB
Markdown
108 lines
4.3 KiB
Markdown
### 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.**
|