造出来才算懂：为什么有些知识只能从试制中得到
Analysis can say what a thing is, but not all the ways it can fail. Properties that do not exist on the drawing only appear once the thing is actually put together
1. Why Knowing the Blueprint Is Not Knowing How to Build It
A familiar scene: the specification is clear, no step is missing from the flowchart, the review passes, and then the first real build produces trouble from somewhere the documents never mentioned. Two components that each pass their own tests interfere once joined; a deviation too small to matter on paper amplifies after sustained operation; users handle the thing in ways no designer anticipated. The first reaction is almost always that the analysis was not detailed enough. That reaction is rarely right. Another round of analysis adds more of the same kind of description, and description is precisely what was not missing.
Writing from the experience of a large operating system, Frederick Brooks offered the well-known advice in The Mythical Man-Month that the first system should be planned for disposal. What matters is not the prediction that it will fail, but that he placed the failure inside the plan. Prototyping is not a repair after execution goes wrong; it is a stage in the process of coming to know. If the first version is meant to be thrown away, what it produces is not a product but knowledge about how this system fails.
The question can now be put more precisely: why do some kinds of knowledge never appear during analysis, however complete the description becomes?
2. Two Senses of "Understanding"
To understand a thing means at least two different things. The first is being able to say what it is, what it is made of, and what rules it follows. That layer transfers entirely through text and fits inside a specification. The second is being able to make it, or at least to anticipate how it will fail under concrete conditions. The object of the first is a property that already exists; the object of the second includes combinations that have not yet been realised.
Herbert Simon drew a useful distinction in The Sciences of the Artificial. Natural science asks how things are; design asks how things ought to be in order to reach a goal. Artefacts are peculiar because they must answer at once to an internal logic of construction and to the demands of an external environment, and the interface where the two meet is where the real problem lives. This explains something otherwise puzzling: specifications usually state the requirements on each side of that interface separately, while what actually happens at the interface becomes visible only when the two sides are put together.
Seymour Papert carried the same point into learning in Mindstorms. Understanding, on his account, is not completed when an explanation is received; it forms while someone builds an object that runs, that others can see and argue about. The point is not a pedagogical preference for hands over heads. It is a harder claim: some properties exist only after something has been constructed. A structure not yet assembled has no deformation under load; a program not yet run has no behaviour under real input. However precise a description is, it has nothing to describe when the property is not there yet.
3. A Prototype Produces New Questions, Not Just Verification
Treating a prototype as a way to verify an existing idea misses its most valuable output. Verification assumes the question is settled and only the answer remains in doubt. What a prototype usually produces is something that was never on the list of questions at all.
The invention of the transistor, recorded in Crystal Fire, is a clear case. The researchers at Bell Labs did not finish the theory first and then build to the drawing. Whether a point-contact device worked depended on the state of the semiconductor surface, contact pressure and material purity — details not yet fully understood, which appeared as variables demanding attention only through repeated concrete attempts. Theory supplied a direction; it did not hand over the list of variables in advance.
Structures: Or Why Things Don't Fall Down makes the same point from the other side. Structural failure often comes not from members lacking strength but from a load path being misread, or from local behaviour at a joint nobody allowed for. Individual members can be checked one by one; a load path exists only in the whole. The history of tolerance in The Perfectionists adds a third layer: precision was never a wish about how accurate one would like to be, but a capacity to manufacture and measure that accuracy reliably. A tolerance written on a drawing is not yet knowledge until a process can hold it.
These three cases point to one mechanism. Analysis handles parts that can be decomposed; a prototype exposes the couplings between them. A coupling term is in none of the individual descriptions and cannot be obtained by adding them up. Making the analysis finer therefore clarifies each part further without ever making the coupling appear.
4. The Objection: Making Also Constrains the Imagination
The strongest reply is not that prototypes are expensive. It is that they change the question.
First, a working prototype quickly anchors discussion to "this is what it already does", quietly closing questions that were open — whether it should be built at all, whether another form is possible. Brooks's insistence elsewhere in the same book on conceptual integrity in large systems points to the reverse side: early choices constrain every later design for a long time. The first solution that works is easily mistaken for the best one.
Second, the cost of prototyping is not evenly distributed. Software can afford to discard a version; bridges, fabrication lines and vaccines cannot. Applying "build it and see" as a general method in those domains hands irreversible costs over to trial and error. More decisive still, some failures cannot be diagnosed. When several variables change together, a failure does not reveal which one caused it, and such a prototype produces noise rather than knowledge.
Third, and this is the hardest boundary, the argument does not hold for natural objects at all. Nobody understands a star by making one. Constructive understanding works only where the object can be intervened upon and the results of intervention can be attributed; promoted into a general epistemology, it becomes a handsome slogan with no way to be carried out.
5. Three Tests
What deserves keeping, then, is not the slogan "build more prototypes" but a set of conditions for deciding when a prototype is the right move.
One: can the object be intervened upon? Where something can be taken apart, assembled, subjected to conditions and observed, a prototype may yield information analysis cannot. Where it can only be observed, the route must be prediction and falsification instead.
Two: can failure be attributed? A prototype has to be designed as an experiment that teaches something: change one nameable variable at a time, or keep records fine enough to pull the result apart afterwards. Without that, a failure is merely an expensive accident.
Three: can the reasoning be traced? The conclusion must be kept together with the reasons for setting things up that way. Simon's interface can be read backwards here: a prototype is valuable because it fixes one concrete encounter between internal assumptions and an external environment. Keep the conclusion and discard the assumptions, and there is no way to tell which parts still hold when the environment changes.
The three tests also answer the objections above. Anchoring is held in check by keeping an alternative form alive; cost is contained by screening which cases qualify; poor diagnosis is improved by experimental design. They are not a recipe for success. They are the line separating a deliberate trial from a lucky accident.
6. Put Making Inside the Process of Knowing
Back to the opening question: why does reading the blueprint not tell you how to build? The answer is not that analysis is defective. Analysis has its own proper object — properties that already exist, can be decomposed and can be described. Many decisive properties of an artefact appear only after it has been constructed, subjected to conditions and watched failing. The difference between the two is not one of precision but of subject matter.
A modest but quite specific judgement follows: do not permit prototyping only after analysis is complete. Place it early in the process of knowing, and give it the authority to rewrite the list of questions rather than merely answer the questions on the list. Two disciplines go with it — keep at least one form that was not adopted, so the first workable solution cannot close the discussion; and record the assumptions behind each trial, so the conclusion can be re-examined when conditions change.
Where prototypes are genuinely impossible, this gives way to a different route: state the prediction explicitly, name the observation that would overturn it, and go looking for that observation. Both routes rest on a plainer stance — keep "it has not yet been seen to fail" apart from "it cannot fail". The first describes the current state of knowledge; the second is an untested assertion. Confusing the two is the error that paper plans most reliably commit.
