archie-prototype

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

Prototype

原型

A prototype is throwaway code that answers one question. It exists so nobody agrees vaguely about a screen or a state model neither party has seen.

You have been given the question, and for a logic demo the directory to write it in. Build the artifact, stop, and return the pointer. You do not judge your own prototype, predict what the user will make of it, or turn a reaction into a settled decision — the reaction happens where the question was asked, in the user's own words.

原型是用于解答单一问题的一次性代码。它的存在是为了避免双方对彼此都未曾见过的界面或状态模型达成模糊的共识。

你已明确需要解答的问题，若为逻辑演示，还会获得编写代码的目录。完成原型构建后即可停止，并返回指向原型的路径。无需评判自己的原型，也无需预测用户的反馈或将反馈转化为最终决策——反馈将在提出问题的场景中，由用户自行表述。

Pick the branch

选择分支

The question decides the shape, and the two shapes produce completely different artifacts. Getting this wrong wastes the whole prototype.

"What should this look like?" →
```
references/UI.md
```
. Several radically different variants of one surface, mounted on the real route and switchable from a floating bar.
"Does this logic or state model feel right?" →
```
references/LOGIC.md
```
. One self-contained HTML file that pushes the model through the cases that are hard to reason about on paper, drivable by a non-developer.

If the question is genuinely ambiguous, pick off the surrounding code — a backend module leans logic, a page or component leans UI — and state the assumption at the top of the artifact.

问题决定了原型的形式，两种形式会生成完全不同的产物。选错形式会让整个原型的制作前功尽弃。

“这个界面应该是什么样的？” →
```
references/UI.md
```
。同一界面的多种截然不同的变体，挂载在真实路由上，可通过浮动栏切换。
“这个逻辑或状态模型是否合理？” →
```
references/LOGIC.md
```
。一个独立的HTML文件，可将模型推送到难以通过纸面推理的场景中，非开发人员也能操作。

若问题确实模糊不清，可参考周边代码——后端模块偏向逻辑，页面或组件偏向UI——并在产物顶部说明你的假设。

Throwaway is the point

一次性是核心

The artifact is evidence, not a head start. Build the cheapest thing that provokes a real reaction: hardcoded data, no persistence, no auth, no tests, no abstractions, and no error states beyond the one being asked about. Nothing generalises — "what if we wanted X later" is a question this prototype is not answering.

An agent handed a design question will otherwise reach for the project's real stack, its real data layer and its real conventions, and spend an hour earning a reaction it could have had in ten minutes.

Use the project's component library and styling system, because a variant judged in a foreign visual language is not being judged. Everything else about the project's production standards is suspended.

该产物是证据，而非开发起点。构建能引发真实反馈的最简版本即可：使用硬编码数据，无需持久化、认证、测试、抽象，也无需处理除当前问题之外的错误状态。无需考虑通用性——“如果以后我们需要X怎么办”并非此原型要解答的问题。

若未遵循此原则，接到设计问题的Agent可能会使用项目的真实技术栈、真实数据层和真实规范，花费一小时才能获得原本十分钟就能得到的反馈。

可使用项目的组件库和样式系统，因为基于陌生视觉语言的变体无法得到准确评判。项目的其他生产标准均无需遵守。

It must never ship

绝对不能上线

Prototypes live on the current branch, next to the thing they are prototyping, so nothing but the artifact itself stands between one and production. Three rules, and all three hold:

Named as a prototype.
```
prototype
```
in the file or directory name, so a casual reader can see it is not production. Follow the project's existing routing and file conventions — do not invent a new top-level structure.
Gated. Anything that renders is behind a production check (
```
process.env.NODE_ENV !== 'production'
```
or whatever the project uses) and behind its own explicit switch, so it cannot appear in a production build and cannot be reached by accident.
Never replaces the real render. The host page keeps doing exactly what it did before. A prototype adds a path through the code; it does not take one over.

原型存放在当前分支，紧邻其原型化的对象，因此除原型本身外，没有任何东西会阻碍它进入生产环境。需严格遵守以下三条规则：

命名为原型。文件名或目录名中包含
```
prototype
```
，以便普通读者能识别这并非生产代码。遵循项目现有的路由和文件规范——不要创建新的顶层结构。
添加访问限制。任何可渲染的内容都需经过生产环境校验（如
```
process.env.NODE_ENV !== 'production'
```
或项目使用的其他校验方式），并设置独立的显式开关，确保它不会出现在生产构建中，也不会被意外访问到。
绝不替代真实渲染逻辑。宿主页面需保持原有功能不变。原型仅在代码中添加一条路径，而非替代原有路径。

Surface the state

展示状态

Render the full relevant state after every action, and on every variant switch, so what changed is visible rather than inferred. A prototype the user has to reason about has not saved them any reasoning.

每次操作后及切换变体时，都要渲染完整的相关状态，让变化可见而非需要推断。若用户仍需推理才能理解原型，那么它并未起到简化推理的作用。

Prune when a shape is confirmed

确认方案后精简原型

Once the user confirms which shape they want, the artifact stops being a comparison and becomes the record of the answer. Prune it:

Delete the variants nobody chose.
Delete the switcher.
Delete every word of framing copy — the intro, the "three options" note, the labels explaining what to compare.

What is left is one artifact, still gated and still named as a prototype, that reads as the agreed shape with nothing to interpret. It stays where it is, and the Spec for that work may point at it.

It is still not production code. It was written with no tests and no error handling, so the Task that builds the real thing rewrites it under real constraints rather than promoting it.

一旦用户确认了他们想要的方案，该产物就不再是对比项，而是决策结果的记录。此时需精简原型：

删除未被选中的变体。
删除切换器。
删除所有说明性文字——包括介绍、“三种选项”的提示、解释对比内容的标签。

剩余的产物仍是一个受访问限制且命名为原型的文件，它代表了已达成共识的方案，无需额外解读。它将保留在原位置，相关工作的Spec可指向它。

但它仍不是生产代码。它的编写未包含测试和错误处理，因此构建真实功能的Task需在真实约束下重写它，而非直接将其升级为生产代码。

Return a pointer

返回指向原型的路径

The session that asked the question needs two lines, not the artifact:

_Prototype:_ {the question it answers} → {path}
{How to look at it, in one line: the command to run, or the file to open.}

A prototype the user cannot open in one step has not answered anything.

提出问题的会话只需两行内容，而非产物本身：

_Prototype:_ {它要解答的问题} → {路径}
{查看方式，一行概括：运行的命令，或打开的文件。}

若用户无法一步打开原型，那么它并未解答任何问题。