@sillydaddy 那其实也不需要充血原型，用多个贫血原型、以类似 Time Machine 的形式表示会更清楚
为什么非要原型的观看者自己按指挥动下手呢……

@sillydaddy
父级 checkbox 和子级 checkbox 的关系也可以是业务逻辑，这一具有宏观明确表现的逻辑，很难说清是业务逻辑还是界面逻辑。

容器类我觉得应当是原型工具的基本了，虽然不是所有原型工具都这么想。
我觉得这是更多地是关于参考系及 overflow 变换，而不是逻辑。
（ fixed 一类的另论）

如果不是觉得一图胜千言的话就干脆不需要原型工具了。
在此基础上，我觉得多图并不如一图一言，这里有边际效益递减的问题。

所以 FramerX 其实是或者是想做 WYSIWYG 吗
如果说从开头就想着 WYSIWYG 做肯定会让转模型容易得多。而且配合现成的设计框架大概会更好。
可能让 antd 之类的 UI 库去附带做个 WYSIWYG 的类原型工具会更好。
（另外，其实可能蕴含了职责划分、保护岗位的关系，虽然这显然 off-topic ）

没用过也没苹果设备，但瞄了眼
https://caniuse.com/mdn-api_navigator_canshare
safari 上支持 share 但不支持 canShare
看了下 w3c 的 spec 里面没有提到 canShare ； MDN 内指向 w3c 的链接失效，表示被移到前述的 w3c spec

也就是说 canShare 已经弃了。

如果你想在工作中追求刺激，建议是创业，而不是大厂

如果你仅仅是想追求刺激，建议不分先后，想到啥写啥：
创业
独立 / 远程 + 游历
搞几个开源项目
去微博上盯着女拳喷（我保证，绝对刺激，虽然形式大概不是你希望的）

@sillydaddy
所以说这可能又要回到不要在原型阶段考虑更细致的逻辑。

其实最复杂的是 Apply - Cancel - OK 按钮
它需要状态保存和还原，这个让原型工具去做描述是真的疯了，恐怕大部分原型工具干脆不可能做到（哪怕只有一个 checkbox ），但逻辑本身清楚得很，不如说大家都常接触。

所以说这里有就个问题：你的设计不符合直观，那就是糟糕设计；符合直观，就不需要搞充血原型。
所以充血原型的工具，更多地像是用于向客户展示，而不是用于向实现者描述。

另一方面就是其实和 WYSIWYG 一步之遥。这个原型写出来能不能直接编译到，比如说 Vue 或者 React，那样也能节约大量的工作量。

你如果说的是 v-model="v.title" 的话
这里动的是计算中间量（那个生成的 r ），而不是 newList

@sillydaddy 这三点其实原本是针对你上次提出的相对复杂的界面显隐逻辑的
应该说是逻辑的实现细节
什么是复杂逻辑？就是既支持 and 又支持 or （虽然不一定同时发生，可能这个控件的显隐是 and，另一个是 or ），就是复杂逻辑。
在复杂的逻辑下，你要去发现某个 input 的逻辑是 check1 && check2 && check7 || check3 && check6，这显然强人所难。

倒是针对性地提出用户故事，形成一个典型路线，这个真不建议用一个充血原型，而应当采用多个贫血原型，从时序上彻底分隔。
（不过坏处是不够复用，都是复制粘贴）

让我想起了有人做 PPT，只用了一张，显示一页然后用纯白去覆盖，再显示下一页，再纯白覆盖。
不要这样。你应当做成多张简单朴素的 PPT，这样便于缩略图展现整个故事。
不需要丰富交互，只需要一些注释表示「这时点击这个按钮」，换页「就会变成这样」，「然后再点击那个按钮」。

@fengjianxinghun 是不是代码不影响版权法，同样也不影响 derived work 判定。

@ShadowPower 除非你很清楚自己在干什么（就算不是代码）不要用「禁止商用」的许可，主要是这一判定比较诡异。典型例子：一篇文章，某非盈利组织免费提供观看，同一页面上有公益性质广告，被判定为商业用途；同一篇文章，某新闻机构在付费栏目下提供这篇文章，不算商业用途（受新闻自由保护）。

@sillydaddy 你的回复有点南辕北辙。
首先澄清一下这句话的意思

> - 指交互有多么丰富。
> + 指交互丰富与否。

我偏向「贫血原型」或「 WYSIWYG 工具」，拒绝具有丰富交互「充血」。
打个比方，排版的时候，要么是 LaTeX 这种更抽象地描述的，要么是 Word 这种 WYSIWYG 的，你不太可能拿着 PostScript 这种拥有所有精确的底层功能的用。

而且我提醒你一句，你就算想交年费你也别上 App Store 。你一旦同意 App Store 条款你就不能上架 GPL 授权代码编译出来的软件

Apple 是软件四大自由的重要敌人。

https://developer.apple.com/cn/app-store/review/guidelines/
5.2 如果您认为自己的知识产权在 App Store 上受到了其他开发者的侵犯，请通过此网页表格提交权利主张。

GPL 与 App Store 条款不合，所有 GPL 授权代码所编译出来的软件一律不得上架 App Store
（这也是为什么 Qt 只有商业授权可以开发 iOS 应用）

如果你是 GPLv3，甚至可以搞大直接起诉 Apple Inc. 要求 App Store 「拒绝分发此软件或允许用户自行替换从 App Store 安装的软件」，苹果无法接受第二个选项。

前景看售前能力，能说动多少客户选择「打预防针」。

但反过来可能针对一些国企（有上级的安全性要求、上级又不提供技术支持）会比较容易说动。

我不觉得需要搞这么复杂，借个术语，「贫血原型」和「充血原型」，指交互有多么丰富。

我觉得充血原型工具不如直接搞 WYSIWYG 的界面编辑工具。

其次：
1. 不要在原型阶段考虑逻辑；
2. 不要指望设计人员能写对复杂逻辑；
3. 不要让前端自己猜或者自己从原型工具中挖掘逻辑
　 —— 如果你的设计不能让前端一眼看过去就知道按钮相关逻辑是什么样的，那显然用户会更加迷惑，那这个设计就是个垃圾设计。

如果 debug 是从程序中清除 bug 的过程，那么想必编程是引入 bug 的过程

@RedrumSherlock 这么命名是一种 geek 的怪癖，就好比中世纪末的手工匠会给自己做出的每件物品取个名字，即使别人看起来都差不多
不过确实，自己想不出来的话就别强行找代号命名了。

另一方面还有一个东西叫「开发代号」，通常是整个产品，且不对外公布。估计可能跟远古时期要满足 8.3 命名有关，可以用来命名项目文件夹。比如 Windows 98 = memphis
不过看楼主附言是随版本更替的，那就应该不是开发代号。

建议直接删除应用，用浏览器看。

@aureole999 @opengps 先不要说 CPU，这个功能首先有人写吧！

而且整体而言是存储和流量收费，这样一个功能可能拿来 DoS （ L7 ？这我分不清 L 了）
比如上传十个随机数据文件，并且以 2^10-1 种方式要求数据，并瞬间断开链接，瞬间就是 1023 倍的存储放大和大量的空耗 CPU 。流式处理的话可能缓解一点，但也免不了很多问题。

「电子智能产品是人体一部分」这不就是赛博格的概念嘛
直接碰瓷赛博朋克就免了，找点经典的赛博朋克小说里的名字。

@NanonaN 那是 syntactic diff 或者 macro-syntactic diff 的样子
当然，semantic diff 对于可魔改且有副作用的语言非常不友好，甚至可能有时因为被管理的代码以外的因素导致等价性改变。
所以想了想就放弃了