# 方法来自哪里：案例与证据边界

来源：本对话中的用户主张、用户提交的截图与真实试玩反馈，以及已交付的机械蝶小样。记录日期：2026-09-21。

本文件用于保留方法的来历。不要据此继续开发机械蝶，也不要把机械蝶的具体选择套用到其他项目。

## 用户直接提出的方法主张

- “用户通过看见、试玩、比较，才发现自己原本没有表达出的真实条件。”
- “体验 → 判断 → 结构化意图 → 受约束的下一次生成。”
- 选择应冻结为可追溯、可重开的决策状态，并成为后续生成与 Git 提交的约束。
- 不同维度可以组合，结构更接近可组合的决策图。
- 时间仍然向前推进，知识建立可以从体验结果回推为更早阶段的约束。
- 用户在这个体验过程中“没有感受到分支爆炸压力”。
- 最后明确纠正：项目核心是找到不同于许愿式编程的方式，应先提炼、保存和复用方法，机械蝶是案例。

以上是已确认的用户表达；其中关于普遍效果或生产组织的主张，仍需与实际实现证据区分。

## 实际案例：机械蝶

| 体验事件 | 用户提供的证据 | 可以据此确认什么 | 不能据此确认什么 |
|---|---|---|---|
| 看到不同视觉方向 | “中间的翅膀我喜欢，身体用右边那种。左边的机械结构留一点，但别那么密。” | 用户能组合不同候选的部分，形成更具体的起点 | 三个原候选中必须整套选一个；所有后续参数已确定 |
| 试玩第一轮并留下版本 | 喜欢追随光点的动态，指出玻璃反光太亮、看不见目标光点 | 外形、动作偏好与具体不适开始分离表达 | 给光点加圆环和标签一定合适 |
| 看到增强后的目标标记 | 指出标记遮挡，目标范围小，原意是“外部的一个光点” | 先前对追随对象和空间关系的理解不足 | 某个固定停留距离已获用户认可 |
| 体验主体与背景的关系 | 指出全黑背景单调，背景与蝴蝶有很大相互关系 | 环境需要进入当前判断范围，维度之间有关联 | 加上任何背景都能改善效果 |
| 选择下一轮环境方向 | 用户明确选择先看“晨雾花园” | 晨雾花园是当前采用的试验方向 | 最终花园画面已通过完整审美验收 |

实际小样具有动作、齿轮、翅面、微光与环境选项；支持保存组合、缩略图和文字反馈。第三轮交付保留了用户两版记录。技术检查与用户后续认可分别记录。

当前实现没有完整的决策状态执行器、自动影响分析或 Git 绑定。不能把本方法建议的数据结构说成已在机械蝶程序中实现。

## 用户提供的业务情境例子

用户提供了在 Claude 交互页面中制作的预约系统截图，并说明已经可以据此判断业务关系。截图包含：

- 两个人争同一时段，比较先到先得与占位五分钟。
- 在体验中看到确认、放弃、超时和另一个人等待的后果。
- 比较日历式、先选人和对话式入口，分别留下或剪掉。

【已确认】这些是用户提供的截图及说明，展示了其希望采用的业务体验方式。

【推断】同样的方法可能用于业务规则：通过亲手触发后果，发现表达在前期需求中容易遗漏的条件。

【不确定】本项目没有读取或执行该预约系统的完整程序，不能声称其并发处理、数据一致性或业务正确性已经验证。

## 从案例提炼出的工作边界

- 一次局部修正可能暴露更早阶段的错误理解，不能只沿当前实现做参数微调。
- 用户的新反馈可能增加一个维度，候选系统要允许扩展，不只是关闭已有选项。
- AI 的好处、代价和观察提示帮助非专业用户介入，但必须保留其假设性质。
- 保存组合有价值；保存其条件、来源和后续约束力，是这套方法继续发展的方向。
- 单个案例与单个用户的体验不证明市场独创性、普遍适用性或稳定收益。

方法主张、操作建议和技术实现分别保存，避免下一次复用时把三者混为一谈。