楼主，了解一下 VeraCrypt 吧——针对性的密码保护，只需要输入 1 个 password 。也是 Joplin 官方回复里提到的方案。

理念不同而已，
用户：意思就是我只要一个简单的 password，就能阻拦大部分普通用户偷看，哪怕本地数据库是明文状态。
开发方：你数据库都明文了，表面上加一个锁有啥意义呢？不如换其他更靠谱的方法，我们不做这样的累赘功能。

FAQ 里的原文：
Q：
Could there be a password to restrict access to Joplin?(可以给 Joplin 加一个密码准入功能吗？)

A：
The end to end encryption that Joplin implements is to protect the data during transmission and on the cloud service so that only you can access it.
On the local device it is assumed that the data is safe due to the OS built-in security features. If additional security is needed it's always possible to put the notes on an encrypted Truecrypt drive for instance.
(Joplin 使用了端对端的加密，它可以保证数据传输过程的安全，并且传到云端的数据是加密的，只有你才能解密。
而本地机器上笔记数据的安全性，只能依赖于操作系统提供的安全防护措施。如果需要额外的保护，你总是可以使用像 TrueCrypt(也就是 VeraCrypt)这样的软件，把笔记放到它们制作的虚拟磁盘里)

如果有疑问的话，可以在回复里面提问，说不定我可以答上来。

@adrianzhang

帐号解决的是不同用户的权限问题。

我想的是不同 App 的权限问题——App 只能访问给予权限的那些文件(夹)，而且这些文件(夹)可以细化。

App 可能不是 Mac App Store(官方应用商店)下载的

@GeruzoniAnsasu
我贴链接就是为了给自己写的东西引流。。哈哈
论文查重有点不太一样：抄袭论文的人总是会故意特意打乱原有的论文。但在网上留言的人，应该很少特意去掩饰自己的语言习惯。

是的。
就是#43 楼的 @swulling 提到的概率。
如果觉得 50%概率太高，可以换一个说法：每秒产出千万个 uuid，连续产出 85 年，才有百万分之五十的概率存在一次碰撞。如果换成每秒百万个 uuid，那么 85 年产生一次碰撞的概率就是一亿分之五十。

典型的“生日问题”：( https://zh.wikipedia.org/wiki/生日問題 )，里面有概率的计算公式。

@matrix67 #7
真是神帖啊。浪费了一个小时，不过看得过瘾，哈哈。
是不是马甲，每个人都心里有数。
不过也真巧，正好应了我在 4 楼提到的“文字指纹”——可以把各方的发言找出来，验一验文字指纹就知道了，这事有够无聊，也挺有意思 ( 逃

同意 3 楼。
看看我设计的“文字指纹”是怎么惨被差分攻击破解的：( /t/774059 )

@no1xsyzy
高保真的交互，对于演示是最有帮助的，可以亲自体验，看视频和亲自操作肯定有差别。
然后对于建立产品的完整感觉也有帮助，因为所有的交互都集成在一起了，切换体验不同的场景很方便。

不过这些应该是到后面再做的。

@no1xsyzy
想了一下，可能自己潜意识里一直想的是直接在原型上做产品概念的迭代，所以总想着要把原型一次做到位，后续把它作为迭代的基础，因为代表真实产品的样子嘛！想想其实大部分的原型应该只要示意图+说明，或者你说的多个贫血原型就足够了。毕竟涉及到交互的迭代还是占的比例很小，而产品设计的迭代占的比例更大，可以直接在低保真上面迭代。

@no1xsyzy
我刚想起了一个具体的例子。可以表达清楚我的想法。

下面这个是 React 写的一个组件，可以交互式操作的。链接里面有动图，表现怎样以交互方式修改一棵树的结构。
https://github.com/frontend-collective/react-sortable-tree

虽然它看起来是纯界面的东西，但其实连续的多次操作涉及到了后面的数据结构(树状列表)，在不编程的情况下，是非常难以用原型工具把它做出来的，正像你说的，如果能做出，那离 WYSIWYG 就一步远了。

但是，原型工具是可以 mock(模拟)出它的单次操作的交互效果的，而且可以保证交互效果完全一致——甚至鼠标连续移动对应的连续状态变化也可以做出来，而不需要引入编程。这就是用前面说的，针对“拖拽条目排序”这种业务操作，选取一条预设的演示路径，拖拽预设的条目到预设的位置。什么是界面操作，什么是业务操作，也不是绝对的，这个例子可以给人很多启发。

如果设计师想让开发做的就是这种效果，那用言语表达肯定是难以沟通的，而正好是原型发挥作用的地方。设计师 mock 出来的这个东西，因为不完整所以也不能编译后用在真实的产品中。

@no1xsyzy
对于这个 Apply - Cancel - OK，我倾向于认为它是业务逻辑，而不是界面逻辑。

界面逻辑就是界面元素之间如何互动。比如对于 7 楼提到的例子，就是父级 checkbox 与子级 checkbox 间的交互互动。再比如对于 PageScroll(滚动翻页)来说，业务数据已经完全交付在页面中的 Container(容器)里面了，然后后续的滑动、翻页这些交互都是界面范畴的交互，而不再涉及业务和数据的处理了。类似的例子还有很多。

Apply-Cancel-OK，如果要演示的话，也只需要一条典型的演示路径就可以。比如我在原型的设置页面 A 里面，设置一些选项配置。然后点击 Apply-Cancel-OK，观察配置所引起的效果，就要切换到页面 B 。(页面 B 体现的是设置对后台数据的影响，哪怕只是这个产品的一些设置项，对于原型来说，也是产品的后台数据)。原型是不可能做到针对页面 A 里的每个不同的配置组合，都修改对应的产品数据的。所以原型能做的就是，在页面 A 中，允许自由交互，但在点击 Apply-Cancel-OK 时，提示只能应用预设的数据，然后再展示预设的页面 B 。这对于演示 Apply-Cancel-OK 的逻辑，完全没有问题。

> “你的设计不符合直观，那就是糟糕设计；符合直观，就不需要搞充血原型”
我还是觉得是一图胜千言。尤其是对于动效来说。

>“另一方面就是其实和 WYSIWYG 一步之遥。这个原型写出来能不能直接编译到”
这个我觉得 mock 出来某个效果，跟实际去做某个效果，工作量还是差不少的。首先 2 者依赖的工具或框架不同，你说的直接编译其实 FramerX 就在做，它的原型是基于 React 来做显示的，原型组件对应的 React 组件可以直接用在产品上。但像 Principle 或 Origami 这些工具，它们提供的交互效果依赖于它们自己提供的环境去运行，估计也很难脱离出来。再者，mock 时用的数据，以及呈现界面的方式，可以跟真实的代码逻辑有很大不同，虽然看起来一样，用起来一样，但总感觉少点啥，应该是因为复用比较难吧。

@no1xsyzy > “这三点其实原本是针对你上次提出的相对复杂的界面显隐逻辑的”
哦。本来想着写完这篇主题再 @你一下的。但给忘记了。
我比较怀疑界面的显隐逻辑能够变得复杂。上次主题说的复杂，主要是针对，界面在一系列操作之后，得到的结果数量可能非常多。比如我举的例子里面，N 多个显示元素都有各自的内部状态，而且可以自由操作，那么在一个页面上点击多次后，会形成复杂的组合。但界面本身的操作逻辑，并不复杂。之所以提到这个“数量组合爆炸”，是因为如果原型工具提供的功能本身不能消减这种组合爆炸，会导致有些原型制作不出来，而这些原型本身的逻辑很简单。
最简单的一个例子，如果你尝试用 Figma 做一个界面上有很多个组件的页面，然后在页面上可以对每个组件独立交互，然后有个组件可以稍微影响某个其他的组件(也就是说界面的逻辑根本不复杂)。你会发现它用 overlay(覆盖层)来模拟组件状态变换的制作方式，会让人崩溃。所以 Figma 或者 Sketch 等工具，侧重点就在于界面的高保真设计，对于交互，它们只提供最基本的。

我现在能想到的最复杂的界面逻辑，就是下面这个：
1 个父 checkbox，下面有 2 个子 checkbox 。
触发选中 /取消选中父 checkbox 时，子 checkbox 也随之选中 /取消选中，不管它们当前处于什么状态；
而触发选中 /取消选中每个子 checkbox 时，该子 checkbox 也会切换选中 /取消选中，而不受父 checkbox 当时状态的影响。

> “在复杂的逻辑下，你要去发现某个 input 的逻辑是 check1 && check2 && check7 || check3 && check6，这显然强人所难。”
如果说某个 input 能否输入，受控于这 5 个 checkbox 的状态，那么，这个逻辑是可以很直接的得出的，或者说是很直观的，哪怕是对于设计师，不需要经过多次步骤的运算得出这个逻辑表达式，而是一步就能得到。这也有点类似主题里说的“条件判断”，在用户对某个页面随意操作后，用户想把页面上的填充或选择作为输入，做下一步的业务操作，这里原型工具可以判断一下各个填充或者选择是否符合预设的条件，这个条件也许比较复杂，但不需要设计师去计算，而是可以直观一步得出的。我是这样想的，因为实在想不到界面上会产生复杂的逻辑流，如果确实产生了，那大概率是因为牵涉到了底层的业务逻辑，由业务驱动产生的数据变化反映在了界面上，这种情况又回到原型本身的能力边界讨论上了。

@no1xsyzy #3 >“打个比方，排版的时候，要么是 LaTeX 这种更抽象地描述的，要么是 Word 这种 WYSIWYG 的，你不太可能拿着 PostScript 这种拥有所有精确的底层功能的用。”

其实原型工具本身就是 mock(“假装”)实际产品的交互效果的。比如你真实产品在加载数据的时候，是根据互联网上获取的数据，来逐渐填充页面内容的。到了原型工具这里，会直接给不同的页面内容设置不同的延迟，就能做出这种效果了，而且仅仅从界面和互动上看，100%保真。这种其实是不需要抽象的底层功能的。或者说，所需的抽象，远远不如真实产品那样复杂。如主题中所提到的，仅仅一个线性映射(比如 Principle 所用)，就可以 mock 绝大部分的界面交互效果。因此也不会带来更大的操作难度。

其实我还是偏向你说的“充血原型”的，也就是能将真正产品的界面、交互、业务逻辑展现出来的。用设计界的术语叫“高保真”。

1. 界面高保真： 这块太容易理解了，不多说了，也不在主题的讨论范围呢。
2. 交互高保真：意思是，别管你底层的业务逻辑多复杂，原型上展现的界面，基本就是真实产品的界面。真实产品上能够交互的显示元素，也要能在原型上交互。当然，这个前提是，只是界面的交互，而不能涉及到产品的复杂逻辑。这点是原型完全可以做到的。
3. 业务逻辑：原型不支持编程，肯定无法做到保真业务逻辑。在主题里也提到了原型怎样展现业务逻辑(这里的业务逻辑，在原型上的体现其实就是一连串的交互动作，可能涉及到多个页面的切换，多个页面是有复杂的因果影响的，背后是业务逻辑和数据在支撑。而原型到此应该止步了，它展现业务逻辑的方式，应该是针对某个业务场景从无数条操作路径中只取一条，来体现业务逻辑对应的页面逻辑)。

> 1. 不要在原型阶段考虑逻辑；
你说的这个逻辑是业务逻辑吗？如果是的话，原型阶段为啥不考虑呢？原型就是为了演示业务逻辑啊。

> 2. 不要指望设计人员能写对复杂逻辑；
没有复杂的逻辑，复杂的以至于需要编程才能实现的逻辑，是不能在原型工具上实现的。业务逻辑是一定会体现在界面的交互逻辑上的。复杂的业务逻辑要想体现为界面的交互逻辑，也只能拆解成一系列简单的业务操作。比如在原型上对数据任意的增删改查，哪怕是增删改查这 4 个操作各执行一遍，原型也是不可能做到的。原型能做到的是，分别针对增、删、改、查，提供一些交互，把这 4 种操作，演示一遍，而且还只能使用预设的数据。这已经是原型的能力极限了，但对于演示产品的业务逻辑，也已经足够保真了。

> 3. 不要让前端自己猜或者自己从原型工具中挖掘逻辑
你说的是从制作好的原型中挖掘交互逻辑吧？对于高保真原型，不存在这个问题啊，高保证原型展示的是真实产品的交互逻辑。页面怎么操作，是跟真实产品一样的。当然，原型想要做的好，需要对某个页面上可以执行哪些操作，要有必要的提示。现在的原型工具很多也能做到。可以看一下主题里“原型工具需要支持条件判断”那段描述。

@no1xsyzy
嗯。这篇主要是从原型工具的完备性的角度谈的。

你说的“交互有多么丰富”，即使再丰富，也是有一个顶的，是能够达到的。

原型工具本来就是各有侧重的。但有一个问题：
比如说某个原型工具甚至支持连续触发。也支持组件，也支持动作。但却不支持一个触发对应多个动作。
对，我说的就是 Principle 。

其他有些原型工具也是这样的。本来是有实现某些东西的能力，但是这些能力却漏掉了一些情景。这就不是“贫血”和“充血”的选择问题了，而是不完备。

@37Y37 #39
这么想的人很多。只是要不要做乌贼——自己是脱身了，但在整个社会变成大墨缸的过程中，也有自己出的一份力。

我自己想看那种讲解具体应用案例的。怎么收集数据、怎么构建模型、怎么构建环境、怎么训练调参。。

@AlwaysBee 楼主真是高产哪