简要描述
这个工具主要用于生成 PayJS 的测试支付订单，在 PayJS 官方不提供测试订单工具之后，可以使用这个工具来生成测试订单，简化操作。
下载地址
截图
更新日志
0.0.3
- 设置 key 为密码类型，保护信息安全。
0.0.2
- 支持 payjs 生成 1 分钱订单，并展示二维码。
PayJS 测试二维码生成工具
发表评论
分类目录归档：产品
什么是我眼中好的开发者产品的文档？（一）
我自己作为开发者使用过很多的开发产品，也看过不少的文档。最近频繁受邀针对不同的产品的文档提出建议，单独写这样一篇文章来说明一下我觉得什么是好的文档。一方面，可以帮助更多的开发者产品变得更好，另一方面，也可以用于自省，我自己在设计产品时是否会有类似的问题。
不过也需要注意，这篇文档仅涉及 「Guide」和「API Documentation」的部分，对于更多的 Changelog、Example、Tools 、 SDK 则没有涉及，这部分留待后续再写。
本文当中参考了包括：Notion 开发者文档、微信小程序开发者文档、声网 Agora 开发者文档、WordPress 开发者文档、飞书开发者文档等开发者产品。
API Documentation vs Guide
其实不少的产品文档写的都是 API Reference ，而不是 Guide，二者在实际的使用意义上是有所不同的。
- Guide 帮助开发者快速上手一件事，从 0 开始，完成一件事。这是「用户视角」。
- API Reference 则是告诉开发者你能使用我的产品做什么事情。这是「平台视角」。
一个好的文档应该是二者兼备的，这样才能一方面降低开发者的进入门槛（Guide 负责），另一方面， 可以让开发者可以知晓能力的范畴，帮助开发者尽可能拓展的应用边界，创造出美好的体验和新的世界。
一个好的 Guide 应该是什么样的？
这里我们以 Notion 的文档为例：
1. 一个好的 Guide 应该尽可能的显眼 & 好找
作为一个新的开发者，进入一个新的开发者平台时时迷茫的：“我应该做什么？”、“我应该看什么？“
这时一个明确的「Guide」、「Get started」可以帮助我们快速找到一个开始的锚点，这个锚点会成为开发者在这个平台中开始进行的下一步。
2. 一个好的 Guide 应该有明确的步骤描述 & TOC
开发者在进入一个新的平台时，需要的是「快速跑完流程，以熟悉平台的各项基本功能」，而不是需要了解到所有的能力（如果开发者已经非常熟悉你的产品，其实根本不会看 Guide，直接去对应的 API Documentation 查看实现了）。
一个明确的步骤描述和 TOC 可以帮助开发者降低心理压力，并让用户找到自己所在的位置，进行下一步的推进。步骤的名称也非常的重要，一个清晰明确的步骤，可以帮助开发者快速明确自己要做什么事情，不会产生疑惑。
此外，也需要注意，步骤不建议太多，可以移除掉那些非核心的步骤，重要的是帮助用户跑通开发流程。
3. 一个好的 Guide 应该是场景相关的
开发者在使用产品进行产品开发时，会有明确的预期，我要做什么事情。但产品需求和平台的能力是不同的。我们很难将产品需求和平台能力直接挂钩，这时就需要开发者盲人摸象般在整个平台上搜索和查看，找到适合自己的文档。这个时候，如果有一个场景相关的 Guide，可以帮助开发者快速找到适合自己的场景，并进行文档的细分。
在这些文档中，你的目的是帮助开发者快速了解在你平台上某个方向的能力、核心概念和如何组合你所提供的能力，帮助开发者快速实现自己的业务诉求。
一个好的 API Documentation 应该是什么样的？
如果说 Guide 是开发者进入一个平台的时候最基础的教程文档。API Documentation 则是一个开发平台中最为核心的部分了，开发者每天都需要与 API Documentation 打交道，以完成一项工作，如果 API Documentation 做的不好，那对于开发者来说，简直就是一个灾难。
1. 一个好的 API Documentation 应该是组织合理的
API Documentation 当中往往包含了大量的信息，那么合理的拆分不同的 API 的模块，可以帮助开发者无需遍历所有的 API ，而是直接按照模块逐级查找自己所需的 API 即可，可以有效的提升查找的效率。
2. 一个好的 API Documentation 应该具备所涉及到的各项数据结构的说明
对于复杂的 API 接口来说，参数/返回值往往不仅仅是一个简单的 Integer 、String ，还会涉及到一些更加复杂的结构化数据的定义。
一种选择是将这种复杂的结构化数据抽象出来，成为一个新的类型；另一种选择是每次都解释一遍。显然，根据软件工程的 “DRY” 原则，我们应当将其抽象出来。在将对应的数据结构抽象出来后，需要注意的是，将其放在一个明确的位置进行展示和说明。原则上，这些结构的说明应该先于具体的接口说明。
3. 一个好的 API Documentation 应该提供相应的 Sample Code
对于开发者来说，Talk is cheap, show me code。而在开发领域也是同样的。你提供的 Sample Code （甚至是在线的调用测试），都可以帮助开发者更好的理解相关的能力和开发逻辑。
所有的细节，都在 Sample Code 中一览无余。
4. 一个好的 API Documentation 应该可以提供上下游关系
在 WordPress 文档中，有一个我非常喜欢的功能就是 Related 。Related 内部分为 Uses 和 Used By，分别介绍了某个函数都是用了哪些函数来完成自己的功能和哪些函数使用本函数完成自己的功能。
伴随着 Uses 还提供了这个函数的源码（不过这个对于平台类型的产品不能直接照抄），这样我可以非常清晰的参考这个函数的 Uses 和源码，以了解这个函数是如何实现自己的功能的。这样当我需要的时候，就可以非常方便的基于这个函数，改造出一个我自己使用的函数。
而 Used By ，则提供了其他的函数是如何使用这个函数的。对于一些我比较陌生的函数，可以直接参考其他函数的用法。从某种意义上来看，这是比测试用例更加全面的用法的说明，因为这是在“生产环境”下的用法。
我们在开源世界如果没有文档，会看测试用例，那么在 WordPress 当中，我会看的是 Used By。
5. 一个好的 API Documentation 可以提供用户之间的沟通渠道
我在 WordPress 开发者文档当中，还会常用到的一个功能是 —— User Contributed Notes。这个功能为开发者提供了一个基于函数的共建笔记。开发者可以自发的在其中撰写自己针对这个函数的开发经验。
当我在不知道某个函数应该怎么使用的时候，我往往会去 User Contributed Notes 去找找看，看看别人是如何使用某一个函数的。官方的文档往往无法跳出「我有什么」的思路，而用户的共建笔记则可以共享出开发者使用某个函数的「奇技淫巧」。这些「奇技淫巧」让开发者的产品显得与众不同，也可以进一步的扩大产品的范畴。
总结
一个好的开发者产品文档是什么样的我很难定义，但至少上述的这些点，确实让我使用这些平台的产品在开发应用和业务的时候变得更加坚定。希望我的这些笔记，可以帮助到你，让你也可以涉及出一个好的开发者文档。
独立开发者可用的支付方式
我会关注一些个人可用的收款方式，核心支付要解决的问题是在开发产品过程中，必须要用到的各项基本技能。如果支付流程无法打通，独立开发者的商业模式就会遭到最直接的打击：你如何赚到钱？
可能你会想，我难道不能使用广告的方式来赚钱么？
当然可以，但与直接向最终用户收款的方式相比，显然，广告赚到的钱不过是蝇头小利。
此外，我也说过，广告赚钱是非常少量的，因为你拿到的本身就是平台收益中的一小部分。此外，广告还有一个问题是与流量相关的，你必须不停的想办法获取流量，并将流量转化，这对于独立开发者而言，并不友好。因此，我并不看好以广告为基础的独立开发产品模式。
故而，我十分在乎收款流程的通畅。
其实想想也能明白，你会发现国内独立开发者大多出现在 iOS、Android 等移动应用开发平台上，这里很难说没有平台提供的收款渠道带来的价值。
所以从这个角度而言，我也建议大家可以适当关注一些收款渠道，以便你自己后续使用。
为什么不注册公司，自己接入渠道？
当提起这些第三方渠道的时候，大家经常会说，诶呀，你这个收款平台的费率好高啊，你看看支付宝官方，只有XXX。
我觉得，这个事情如果只对比收款费率的话，过于单纯。
实际上，支付宝官方、微信支付官方往往需要企业资质才能开通。而你开通这些账号所支付的成本，远超你当下的收入。
你用你前期的收入，养活了代注册公司、代记账公司。早期其实完全没有必要，你大可以用这些平台完成前期的冷启动，启动完成，有了长期收入，你的收益足以支撑你继续后续的工作，再替换不迟。
我关注到的收款平台
面包多 Pay
PayJS
XorPay
云计算的增长在 SaaS
我一直以来，都很喜欢诸如 LeanCloud、Firebase、云开发这样的产品，这背后的逻辑是「随着云计算的成本不断下降后，下一步发展起来的是各样的 SaaS 产品」。
这些 SaaS 产品的建设，和过去相比，基础设施的发展使得开发一个 SaaS产品变得比以前简单太多了。
如果你需要服务器，无论是阿里云，还是腾讯云，甚至是面向全球的 AWS、Azure，都是你只需要花钱就可以买到的。
如果你需要邮件系统，SES、Mailgun、Postmark，各种不同的产品，让你的开发变得无比的简单。
你需要做的，只是找到你自己的 niche，然后针对这个 niche ，开发一款产品，并将你的产品推出，并发布上市，将你的产品售卖给你的客户。
很多时候，我们在看云计算的市场的时候，如果我们关注的是 IaaS，基础设施，我们就会发现，我们面对的往往是那些旧有的，已经存在的市场，他们会使用我们的产品，来替代曾经的产品。但同样的，我们的产品也会被成本更低的 IaaS 产品所替代。
我们要的是旧有的产业，还是那些新的产业？面向一个已经存在的百亿市场，还是一个未来会爆发的千亿市场？
好风凭借力，送我上青云
对于如今的开发者们来说，已经处在一个很好的时代了，他们拥有着丰富的基础设施，这些基础设施，让我们可以以更加低成本的方式，来构建我们自己想要的产品和工具。
我们站在巨人的肩膀之上，构建属于我们自己的产品。
为什么我们一定要完全自己去构建一个产品呢？从国家的角度来说，这样情有可原，而从个人的角度来说，借助这些基础设施来构建一款产品，才是最为实际的。
我们需要自己从 0 开始建设一个云服务么？当然没必要，我们可以使用阿里云、腾讯云、AWS、Azure，你可以使用任何一个云服务厂商为你提供的基础设施，构建自己的产品，直到他们无法满足你的那一刻。
从给项目不买域名做起
我是一个灵感非常丰富的人，所以我总是会有各种奇奇怪怪的想法，并且试图将其转换为一个实体的项目（工程师的身份赋予我将其从灵感变为现实的可能，而产品经理的经历让我可以关注一个产品最为重要的是，至于说运营的工作，让我可以把一个项目从 0 开始推广）。
而我过去的一个毛病是，当我有了灵感后，会先试着去买一个域名。但，购买域名并不意味着我一定能把这个项目做完，大部分时候我会注册一个域名，然后，放一年，直到他过期。久而久之，我就有了几十个域名。。。
所以，我在思考，在后续的新的项目中，我将会启用项目代号制，先不思考项目名是什么，以及应该用什么域名，而是先尽全力将自己的 MVP 跑通，以及完成功能假设和市场假设。
所以代号从哪来呢？不妨从一些经典电影中找找灵感吧，最近看一些英文电影，然后从英文电影中寻找答案。
关注体验，而不是关注效率
今天和我的广告主，芦笋的创始人晓力聊了很多，其中聊到独立开发者的工作，我提到了一个概念：
作为独立开发者，我们需要关注产品的体验，而不是关注产品的效率。因为在效率的追求上，我们一定不如大公司能够在这个事情上做的更好，在这种情况下，做一个更具备“个人特色”的事情，会让我们在一件事上走的更远。
个人特色意味着独特的品味和体验，这种独特的品味和体验，将会引导用户持续使用。而这些独特的品味和体验，将会是留下我们的用户的重要的部分。
抖音和快手的区别
前几天和一个做投资的朋友聊到了抖音和快手，谈及二者的不同，我是这样评价的。
关于抖音
谈及抖音，需要看字节跳动的企业文化和张一鸣在做的事，字节跳动的使命叫「Inspire Creativity, Enrich Life」，中文「激发创造 丰富生活」。
这句话没啥问题。不过，如果你和张一鸣做今日头条的逻辑一起来看的话，就能明白抖音提供的价值。
张一鸣认为，现有的推送机制，按时间推送的机制（如微信公众号），信息触达目标用户的效率太低，所以做出了今日头条，希望通过机器算法的机制，来优化信息触达目标用户。
而抖音，从产品形态上来看，就是视频版的今日头条。依然依靠强算法推荐，让「引擎觉得对你有用」的产品，出现在你的面前。
至于说，激发创造，丰富生活，其中是没有「人」的存在的。当然，是激发每一个人创造，丰富每一个人的生活，但本质上是推荐引擎将数据推荐给每一个人。引擎不在乎内容是谁做的，他只在乎内容对目标受众有价值。
这也解释了，抖音上为什么往往是一个网红需要不断的跟进潮流，出新的内容，产出新的价值，才能持续产生收益。
快手
同样是短视频平台，快手讲究的是「快手是记录和分享大家生活的平台，每天产生上千万条原创新鲜视频」。
快手虽然也有推荐引擎，但在快手当中，首先核心概念是每一个快手主播，数据和信息以主播为核心进行推动。
在快手的世界，以「人」为本，不太在乎算法。如果你关注了某一个主播，他产出的内容会强推荐给你，让你可以持续看到。
从这个角度来看，快手其实在做的事情「很互联网」，和我们曾经使用的 Feed 流非常接近。
我的评价
二者我都不抗拒，我用抖音搜索我想要的信息，它可以产出我最需要的信息，很好的承载了一个「视频版搜索引擎」的角色。而快手则会成为我的工具，因为他以我为中心，展现我的价值，是一个创作者的助手。
谈独立开发者
今天可能有些同学因为「独立开发者」这个标签关注我的推特，不过这个号可能你们看不到太多关于独立开发者的「技术」分享，因为「技术」不是独立开发者的关键，对于独立开发者来说，技术够用就行。反而是产品、市场、商业、运营的能力对独立开发者来说会更有帮助。我并不推荐经验不足的同学做独立开发者。
因为对于独立开发者来说，能够独立打造一个产品，是基本功。你需要能够 Cover 掉整个项目的几乎所有流程，然后才有资格成为独立开发者。如果你的技术不全面，那你就必须想办法解决这个问题。可以是借助云服务、可以是借助 No Code 工具。不要让技术把你卡住了。
当产品研发不会成为你的阻碍以后，你就踏上了独立的路线。成为独立开发者的路径是漫长且枯燥的，但同时也是开心的。因为你可以做你喜欢的事情、做你想做的产品、服务你想服务的人，并从中获得支付，养活自己。
相比之下，我认为有商科、金融等背景的人会更容易成为独立开发者，原因是更具备理解商业逻辑的能力。如果你不是，或者你不能理解，那就找一些书，看看商业世界是如何运转的，你又如何从中提供价值，赚取收益。当你开始思考商业的问题时，你就真正的走上了独立开发者的道路。
在前期，你可能做了大量的事情，都是在尝试，在锻炼，但不要害怕，开发产品本来就是一个困难且复杂的事情。失败也是大概率的事情。但你可以从自己的每一次开发过程中吸取教训，让自己的下一次产品比这一次更加成功。
作为独立开发者，我不太建议你采用广告的方式来获得收益。广告的方式本质上是流量生意，你的收入和你的用户的增长并不是线性的。而且流量生意对于资本、渠道等关系的要求很高，对于绝大多数开发者来说，并不适合。关注一个小众领域，服务一小撮人，是一个比较简单且实用的路径。
你从每一位用户（客户）身上收取费用，你的用户增长和收入是呈线性关系。相比于「可能是指数型增长的广告业务」个人觉得会更适合刚刚开始的同学。当然，如果你确实有明确的流量入口，把控了流量，那做广告型的业务也未尝不可。
我常说，「和别人做一样的事情，就不要预期和别人有不同的结果」，做独立开发者就是一个试图做和别人不一样的事情，在这个过程中，你是孤单的，但也是快乐的。作为开发者，我们能够选择「做自己喜欢且可以赚钱的事情」，是非常幸运的，别浪费了这种快乐。
在我看来，独立开发者和作家、播客主播一样，都是创作者。这部分就像 @zhufengme 说过的「创作者不能缺钱」。如果缺钱，就不太好搞创作了，那么穷困潦倒，要么不得不放弃一部分原则，以养活自己。处在一个比较舒适的状态下，认真去做自己喜欢的事情，反而可能更容易走出自己的路。
为什么太缺钱的人或者太关注钱的人可能反而不容易成功？原因是，如果你太过于关注钱，你就变得和商业公司一样了，追求的是利润。但，从追求利润的角度来看，商业公司一定会在这个事情上拥有比你更加强大的能力和实力。所以我不太喜欢做有强资本属性的事情，因为你很难在这个维度和大企业竞争并取得成功
独立开发者不要追求效率，而是要想办法追求美好的体验，就如 @RioJot 和黄海在疯投圈「51.从泡泡玛特谈起：物质消费中的情感体验」中提到的，我们有太多的企业去追求且擅长追求效率，而情感体验，是作为个人能够做的更加极致的部分。效率从各个角度来看，你都不如大企业能够做的更好
但你可以在情感体验和观点（opinion）中获得价值，@plidezus 的 Flomo 就是一个很典型的拥有自己的 Opinion 的产品。而研发同学们特别熟悉的 Rails 的母公司 Basecamp ，也是一个非常典型的 Opinion 导向的公司。他们通过构建一种 Opinion ，找到和自己同频的人，然后向他们售卖针对这个Opinion的产品
在产品触达用户之时，DevRel 团队都要做什么
经尾尾邀请，在“聊聊 DevRel && 技术运营”群做了一次关于 DevRel （开发者关系）的分享，以下是分享内容，希望对你有帮助。
Slides 地址：https://docs.google.com/presentation/d/1n6XBLfmpSCDg3196LIn_8FGKIqkCIp-qN9sMQ-uxzVk/edit?usp=sharing
《布道之道》链接：https://www.ituring.com.cn/book/736
直播回放：https://bytedance.feishu.cn/minutes/obcnxp28x2898p51qk37zrzy