🤐 这里有一个开发者，然后就，就...就...就...差一些点子了喂

🥳 去年底就想做的一件事情，最近提上了日程，简单梳理了一下运作模式，想听听大家的意见 ~ 如果有参与者就更好啦！具体的操作部分还不是很完善，这几天会陆续更新，感兴趣的朋友也可以暂时加个群关注下，二维码在文中。

运作模式

或可以缓解「就差个程序员」的尴尬问题，大家提想法，我来评估并实现，技术层面上来说，目前只接受可以用 Bookmarklet （小书签）实现的想法，所以你需要先了解一下小书签的能力范围，或者带着想法跟我聊，我来告诉你是否可行。

关于盈利和权责方面的问题：

就每一个想法来说，你和我之间是合伙人关系，你需要为小书签的前期开发付费，费用视开发工作量决定，可以协商，一般为小书签定价 * 10，这是一种风险分担方式，你不能空手套白狼，为前期开发付费也能倒逼你打磨想法，在一定程度上有利于提升小书签的成功率；
出于对想法的尊重，开发完成之后，我们各自拥有小书签的全部分发权（出售）：
- 我会跟你协商一个价格，挂在我自己的微信小商店，上架之后无限期时间内你都将拿到该小书签 50% 的销售额，小商店商户提现的手续费由我承担；
- 你可以以任何你喜欢的方式分发该小书签，其中也包括通过其它渠道降价销售，如果你认为这样会使你获利更多的话；
我会为从我的小商店购买的用户（不包括你和我）建立用户群，并为他们提供一手的使用帮助和售后服务；你可以跟我一起管理这个用户群，也可以建立你自己单独的用户群，但我未必有精力会为你的用户群提供直接的帮助，他们也无法享受作为主要开发者的我提供的售后服务。
我会负责该小标签的既有功能维护工作，保证小书签能够正常使用，如果你对该小书签有新的想法，即功能的调整、升级，需要为这部分开发工作单独付费，费用视工作量而定，可以协商，更新之后，你可以要求我调整在微信小商店中出售的价格，我一定会做出调整，但对调整的幅度保留协商的余地。

以上几条在最大程度上平衡了你作为想法提供者和我作为实际开发者之间的利益关系，在此基础之上，需要说明的是：

我不可否认会有我自己的想法，当我对该小书签的功能有更多想法的时候，我会优先争取你的支持，如果得不到你的支持，我也会做单独的实现，对于新实现的小书签，你只能拿到该小书签在微信小商店销售收入的 20%；
在条件成熟的时候，为了用户的方便，我会将多个「特别增强型」小书签整合为「通用增强型」小书签，比如将腾讯视频加速小书签、B 站视频加速小书签、百度网盘视频加速小书签统一整合为视频加速小书签；
整合之后的小书签与原先各个小书签之间独立运作、互不影响，对于新的通用增强型小书签，整合涉及到的特别增强型小书签的想法提供者们共同构成想法提供者，拿到该小书签的在微信小商店销售收入的 50%，但不再具有获利之外的其它权利，可协商。
代码全部公开，开放 ISSUE 但目前不考虑接受 PR 。

重要： 小书签将不可避免的会面临被用户或其他人无偿分发的问题，对此我也不想做任何限制使用的措施，我不希望出自自己手里的作品中掺杂着杂质，我想用上好的服务和理想主义者的行事风格打动大家，希望你能够理解。

Ideas

我将 Bookmarklet （小书签）能实现的功能分为「通用增强型」和「特别增强型」，通用增强型指不限定目标网站的通用能力，比如自动点击、DOM 截图、分屏、任意内容即使分享等，特别增强型指针对有限目标网站的功能，比如百度网盘视频播放器加速、微博爬虫、语雀快捷键、Chrome Offline 小游戏修改器等，也不排除之后会有其它的更加合理的分类。

重要： 当前阶段只接受特别增强型小书签的 Idea 。

矩阵

跟油猴脚本跟浏览器扩展有什么区别，回答是：大同小异，（油猴本质上是浏览器扩展）三者目标都是为了增强网页的能力和使用体验，做成小书签跟做成浏览器扩展的差异在于二者能拿到的浏览器操作权限不同，因此也会导致一些使用上的差异，比如小书签必须要点击才能启动，而扩展可以自动运行。

那为什么还要做小书签，回答是：很多功能在做到相当完善之前其实并不需要做成扩展，而小书签逐步完善之后自然也就做成扩展会更方便，在我规划中这是这个计划不同阶段的目标，扩展是一定会做的，但这是个循序渐进的过程，这也是我将「想法」分为通用增强型和特别增强型的出发点。

油猴和扩展已经很全了，你怎么确定自己不是在浪费时间，回答是：你知道有多少人会用油猴吗？你知道有多少人下载不了浏览器扩展吗？你对自己在油猴上找到的脚本真的满意吗？我虽然不知道这几个问题的确切答案，但我知道都不乐观，而我觉得我们可以做得更好。

下面是去年闲暇时随手写的（图一时方便，体验并不很好，优化空间超级大），类似的功能改造点还有很多很多。

最近在做些基础工作，以下还是草稿，详细的实施计划还在考虑中，🔎 关注这个计划或者要 💡 提供想法的朋友可以加群聊聊：

Bookmarklet

依赖分离 - 减少请求且调试方便，但开发不便、故障率高、依赖版本锁定相对困难（与减少请求冲突）
依赖打包 - 请求冗余且调试不便，但开发方便、故障率低、依赖版本锁定相对容易

优先实现依赖打包的方式，在开发过程中通过降耦合留足转换为依赖分离版本的操作空间，在将来比较成熟的版本中提供依赖分离版本以供其它场景（比如交给扩展统一调度等）使用。

小标签核心分发形态：开发 -> 发布至 CDN -> 小标签化（专属组件） -> 拖放部署 -> 使用

浏览器扩展阶段：

小标签市场

一键添加至收藏栏

可配置目标页面自动启用（减少冗余操作）

优先尝试调用依赖分离模式小书签，减少冗余请求

网站

https://app.thoughtsdaily.cn/bookmarklet

根据项目整体的进展，网站的开发也分多阶段进行：

不需要网站，发一篇推文即可
开放任意代码生成小书签的组件，功能未必完善，主要是自用
网站纯静态，主要是项目介绍
开放部分成熟的基础小书签，比如按钮连击……
支持提交需求和投票

小商店

挂在小商店出售，小商店的销售量直接与提供 Idea 的人的回报挂钩。