xxih/ai-harness-zh/prototype

Prototype(原型)

原文:skills/engineering/prototype/SKILL.md

原型 = 回答一个问题的一次性代码。问题决定形状。

选分支

识别要回答的是哪个问题——从用户 prompt、周围代码,或者用户在的话直接问:

• "这个逻辑 / 状态模型对吗?" → LOGIC.md。构造一个小的交互式 terminal app,把状态机推过"纸上推理推不动"的 case。
• "这看起来应该长啥样?" → UI.md。在同一个路由上生成几种截然不同的 UI 变体,通过 URL 参数 + 浮动底栏切换。

两条分支产出完全不同的工件——选错就废掉整个原型。如果问题真的模糊且用户不在,默认选周围代码更匹配的那条(后端模块 → 逻辑;页面或组件 → UI),并在原型顶部注明假设。

两条分支共通规则

1. 从第一天起就是一次性代码,并且明确标记。原型代码放在真正会被用到的地方附近(挨着它要原型的模块或页面),这样上下文显然——但用名字让随便看的人也能看出它是原型,不是生产。对一次性 UI 路由,遵守项目已有的路由约定;不要发明新的顶层结构。
2. 一条命令跑起来。用项目已有的任务跑法——pnpm <name>、python <path>、bun <path> 等。用户必须能不动脑子启动它。
3. 默认不持久化。状态在内存。持久化是原型在 *检查* 的东西,不是它该依赖的东西。如果问题确实涉及数据库,打到一个临时 DB 或本地文件,起名 PROTOTYPE — wipe me。
4. 跳过打磨。无测试,只保留能让原型 跑起来 的错误处理,无抽象。目的是快速学到点东西然后删掉。
5. 暴露状态。每次动作后(逻辑)或每次切换变体后(UI),打印或渲染完整相关状态,让用户能看到改了什么。
6. 完成时删除或吸收。原型回答完它的问题,要么删掉,要么把验证过的决策折进真代码——别让它在仓库里烂着。

完成时

原型唯一值得留下的是"答案"。把答案找一个持久地方记下来(commit message、ADR、issue,或挨着原型的 NOTES.md),连同它回答的问题。用户在 → 快速对话;不在 → 留占位符,他们(或你下一次)在删原型之前填上判定。