最近创业没太多进展，值得开心的是我的宝贝女儿出生了，我当爸爸了，开启新的人生体验！

产品和创业方面感觉没什么可写，推荐几本最近看的书：

• 独立开发者营销获客手册
• SEO实战密码
• 流量的逻辑
• 真需求-梁宁

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

大家好，今天继续聊聊我最近做的项目—艺爪AI自媒体副业工具，最近更新了很多功能，持续快速迭代。

1. 字幕拼图功能

字幕拼接图片非常适合做经典语录和读书分享图文。可以用它来制作那些带有深刻文字的图片，一键生成，直接上传到你的公众号或者小红书，吸引粉丝和流量。

2. AI文案生成功能

内置的文案库和AI智能改写功能，让你可以快速生成高质量的文案。这不仅仅是节省时间，更是提高了内容的原创度和爆款概率。AI文案已经和字幕拼图、治愈系图文（有图有字） 功能深度融合。

如果你懒得自己写文案，AI文案生成功能非常好用，50万+的文案词库加上智能改写，批量制作图文内容效率极高。

3. 公众号图文排版

这个免费图文排版功能最近也更新升级了，可以实现非常丰富的公众号图文样式，支持多种图片布局，实时预览，一键导出，用来做公众号图文非常简单方便。

现在这款副业工具产品已经比较完善，但还没有解决流量问题，缺精准流量。

欢迎有自媒体工具、副业项目相关流量的朋友联系我，可以推广🤝合作。

艺爪AI自媒体副业工具，专注于自媒体图文创作。
网址: https://zmt.ezboti.com
公众号: 艺爪助手
如果你对这个工具感兴趣，或者想要了解更多关于它的信息，欢迎随时联系。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

上期文章发布之后，我综合考虑选择了自媒体工具方向。现在产品已上线一个多月，一直忙于产品迭代更新。这次分享一下最近2个月的进展。

自媒体副业工具

艺爪AI自媒体副业工具，小白也能用的自媒体赚钱利器！
网址: https://zmt.ezboti.com
教程&案例: https://www.ezboti.com/docs/zmt/start/

产品第一版提供姓氏头像工具，吸引了少部分用户使用，迭代更新把功能完善之后，最近更新上线了治愈图文工具，功能也比较完整了。艺爪AI副业工具 新功能「有图有字」上线了！

这个方向对了吗

经过这2个月的摸索，我觉得大概是对的。和AI对话/AI写作相比，这个产品用户群体更加垂直，没有被大厂炮火覆盖，用户使用频率比较高（做自媒体账号每天都用），付费意愿也更强。从数据来看，付费人数比AI写作明显更高。

但是也存在问题，增长缓慢。做自媒体副业能赚钱吗？能赚钱，但只有少数人能赚到钱。賺钱这个事，需要的能力非常多，大多数人不具备。目前副业工具这个产品的用户基本是有自媒体经验、有思路、也有执行力的一小群人，这个工具能节省时间，提高效率，帮助他们赚更多钱。

对于更广泛的普通人，做自媒体还没有赚到过钱的人，从0到1是艰难的过程，需要长期坚持努力，也需要一点运气（坚持几个月创作内容，等某一天你的某个文章无意间就火了）。大部分人不具备这些要素，只是单纯的想赚钱。

我不想做割韭菜的事，忽悠赚快钱不可取。我想要实打实做副业赚钱的工具，实现 “小白也能用的自媒体赚钱利器” 这个大目标，任重道远。

其他

蚁阅RSS 服务器最近快到期了，核算发现续费成本太高，严重入不敷出。花了半个月时间把服务迁移到云函数上（Serverless），优化配置降低成本。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

转眼一个月又过去了，艺爪AI APP上架了几家主流应用商店，但下载量惨淡，短视频推广效果也不好。我感觉得再调整方向，不然肯定赚不到钱。

APP端适配

艺爪AI基于uniapp开发，可以跨小程序、网页、APP多端，适配APP端碰到几个难点，都解决了。

1. Markdown/Latex/二维码渲染在APP端报错，原因是APP端和小程序一样是逻辑层（JS）和视图层（Webview）分离，JS代码无法直接操作DOM。解决办法是用 uniapp-renderjs 技术，把DOM操作的代码放在视图层运行，就能直接操作DOM了。
2. AI写作用到了富文本编辑，使用 Quill 这个库实现的，其中的DOM操作非常复杂，使用 renderjs 也无法正常运行。最后选择用 webview 把网页版的AI写作页面嵌入APP中，绕过了这个问题。
3. APP支付，基于艺爪付费实现，参考代码-Uniapp框架支付。

现在已经开发完成了安卓端。iOS端支付比较复杂，还没有时间做适配，后续再考虑加上。

APP上架了

艺爪AI APP上架了国内的主流应用商店，其中小米、Vivo、OPPO、百度应用商店都比较顺利，腾讯应用宝审核了几轮最终通过了，华为应用商店要求非常严格，审核还没通过。

审核涉及的问题有这些：

1. 应用内为用户提供合成生成内容服务前，未进行真实身份信息认证。（要求手机号登录，暂未完成）
2. 应用内含深度合成或生成式人工智能服务内容，未提供举报功能。（加上了举报功能）
3. 登录/注册页面无《用户协议》或《隐私协议》。（加上了，而且默认不能勾选）
4. 支付页面未展示会员服务协议。（加上了：购买会员代表已阅读并同意《会员服务协议》）
5. 首页显著提示：内容由AI生成，请勿用于从事违反相关法律法规的活动。
6. 《用户协议》和《隐私协议》内容缺少开发者信息。（加上了公司名称和联系方式）
7. 《用户协议》和《隐私协议》内容缺少更新/生效时间。（加上了更新日期）

自己辛苦开发的APP上架了，应该是件开心的事情，但是上架了几天，APP下载寥寥无几。

这段时间短视频推广效果也很差，转化的用户没有几个。也发现同行、同类产品都是做付费广告推广，但这样成本打不住，可能还得亏更多。

从APP上架后的效果以及市场反馈来看，我感觉得再调整方向，不然肯定赚不到钱。

路在何方？

方向不对、努力白费，我思考了很多创业方向的问题，做了一点调研，大致有三个可以考虑的方向。

自媒体工具 - 帮助普通人做自媒体赚钱

• 各大自媒体平台上，大部分内容都是“营销号”创作的，大部分流量也是给了这群人，这个群体通过一些固定的模式创作出大量内容，吸引流量变现。其中创作内容和流量变现需要软件工具支撑。
• 自媒体赚钱已经有成熟的模式，这个群体中有些人是【团长（师傅）】，他们开培训课程教学员做账号发内容（【项目】），积累粉丝和流量。项目对应着特定的受众群体/账号类型/类目，例如姓氏头像就是一个项目，按大类分的话属于头像壁纸类。赚钱项目非常多，少部分赚到钱的人会成为团长教别人赚钱，流量暴涨（赚大钱）是小概率事件，选对项目坚持做基本能赚到零花钱。
• 从需求看：这些创作者属于业余兼职/失业/宝妈等人群，想通过互联网赚钱，会动手实操。自媒体平台需要大量的内容供用户消费。创作者需要每天生产原创/伪原创内容，持续发布内容，使用工具软件是必须的，只要能赚钱回本，付费意愿很高。
• 从技术看：AI擅长创作内容，再结合软件自动化，是自媒体推广人群的最佳工具，绘画、写作都能很好满足需求。但是AI要和具体的推广项目结合，把人工操作的流程、套路模式做成简单的工具，方便普通人高效做赚钱项目。

国产版Poe - 聚合国产AI大模型API

• 目前国内没有这类产品，大厂不会做这类产品，有市场需求（开发者、科技博主、研究人员？）。
• 聚合API需要对接很多API，适合开源共建，开源能够增加聚合API的数量，同时减少每个开发者的工作量。
• 艺爪AI本身用了多个大模型，作为开发者需要这样的聚合API服务，把聚合API标准化并开源，有长期价值。
• 通过开源的方式提高知名度，获取持续的流量。用户可以自己部署开源版，也可以充值艺爪AI会员直接即用。

蚁阅RSS升级 - RSS + AI结合，更好用的阅读器

• 传统的RSS阅读器基于订阅源链接获取信息，有了AI能力之后，可以实现根据用户的意图订阅内容，你想要什么，就让AI助理帮你从互联网各个地方收集这方面的信息，整理好之后给你，不再需要自己找RSS源。
• 国内内容平台都比较封闭，开放的信息源不多，订阅源是绕不过去的难题，也许AI可以实现更智能的爬虫，不需要写代码就能获取你想要的信息。
• 蚁阅RSS已经积累了非常多用户反馈，RSS阅读器需求持续存在，用户体验需要完善，有很多功能等待实现。
• 国内做内容产品涉及很多内容审核合规问题，爬各大平台的内容也有合规风险。

你觉得这些方向靠谱（能赚钱）吗？

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

最近两个月，我开发上线了 艺爪AI写作 功能，这个功能既能提高写作效率，又能保证文章质量。

它最大的特点在于人机交互，用户可以通过与AI的交互，逐步引导并补充信息，从而生成更符合个人需求的文章。

我也在推广上做了一些尝试，希望让更多人了解并体验这个全新的AI写作工具。

为什么开发AI写作功能？

今年的市场环境与去年相比已发生巨大变化，简单的AI对话产品没有了竞争力，市面上充斥着众多竞品，大厂APP功能更强大且免费。因此，我迫切需要开发一个更具竞争力的东西出来。

我重新思考了产品方向，并调研AI市场的用户需求。一方面，我参考了风投投资的创业公司，收集大量AI方向创业公司的信息，例如YC的投资名单，从中整理出一些可行的产品方向。

另一方面，我尝试分析产品积累的用户对话数据（所有数据均为匿名，仅用于内部调研和产品改进，不涉及个人隐私问题）。因为数据量非常大，我用了一些分析方法，比如词频、词云、主题模型和关键词统计。结果发现，对话问答和写作这两方面的需求都很强，大约各占了1/3，其他需求则分布在不同的小领域里。

综合考虑，AI写作的需求很广泛也很重要，所以我决定先开发AI写作这个功能。

AI写作应该做成什么样？

请看AI的回答：

我分析了市面上的AI写作产品，发现 Notion AI 和 WPS / Word AI 比较符合AI交互式写作的特点，其他大部分产品都是AI文章生成器，直接生成文章，不支持交互式写作。还有一些产品是针对特定写作领域的，比如论文写作和小说写作。

我认为，AI写作的最佳方式是人与AI的交互。用户可以逐步指导AI如何改写，从而生成更符合需求的文章。而那种直接生成文章的工具，往往很难写出用户满意的好文章。

艺爪AI写作上线和推广

经过一个多月的开发，艺爪AI写作在5月底完成上线了，第一版只适配了电脑端，随后开发适配了移动端界面。经过近一个月的迭代和优化，现在产品已经比较好用了。感兴趣的朋友可以通过下面链接访问：

• 艺爪AI官网 www.ezboti.com/ai
• 艺爪AI写作视频教程 - Bilibili

产品上线后，接下来要考虑的就是推广问题了。要让更多人知道我们的产品，特别是那些真正需要它的人。

我本来的计划是，一方面找代理商合作推广，另一方面我自己也通过自媒体来宣传。但现在AI的热潮已经消退，市场回归理性，推广起来比以前难了，我们的产品竞争力也没有那么强，所以代理商不太愿意推广了，我们得自己想办法去做市场推广。

虽然渠道销售可以放大流量，但在产品标准化之前，我们还是得直接面对用户。参考 初创公司的销售模式-奇绩创坛。

AI算法备案

还有一个好消息，艺爪AI成功通过了网信办算法备案。

艺爪AI助手合规运营，安全、可靠，更加放心使用！

后续计划

1. 利用同一套跨平台代码，上架艺爪AI助手的APP端、桌面客户端，为用户提供更好的使用体验。

2. 深入探索AI写作的市场需求，不断迭代产品，提升用户体验，让AI写作更加贴合用户的实际需求。

现在，想请教大家一个问题：你心目中理想的AI写作功能应该是怎样的？欢迎在评论区留下你的想法，期待与你共同探讨和进步！

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

最近一个多月我比较忙碌，开始投入工作和创业中，在此分享一下进展和我在AI方面的一点经验。

本月进展

蚁阅RSS 收到用户赞助，新增发布订阅功能。发布订阅功能用于公开你的订阅，让网友可以在你的网站上阅读你的订阅内容。详见蚁阅1.9.0更新日志。

接单给一个AI小程序增加Markdown和Latex数学公式渲染功能，已完成交付上线。

接单给一个企业接入AI实现业务需求，正在开发中。

调研AI市场用户需求，计划开发新功能「AI写作」。

重构了自己AI产品的前端代码，修复一些遗留问题。

如何让AI输出结构化JSON数据

AI（LLM）的输入和输出都是基于自然语言的，然而编程语言只能理解结构化的数据，将AI集成到业务中时经常需要用到结构化的数据，这时可以借助TypeChat让AI生成结构化的JSON数据。

因为AI的训练数据包含了大量编程知识，其中包括TypeScript和JSON，所以可以借助TypeScript描述数据结构，让AI用JSON格式输出数据。通过实践验证AI也确实能够遵循指令输出JSON数据。

示例提问：

You are a service that translates user requests into JSON object according to the following TypeScript definitions of type `Result`.
你是一个用户请求翻译器，根据用户请求和以下TypeScript定义准确翻译成符合 `Result` 类型的JSON对象。TypeScript定义如下：
```
// 判断用户需要什么样的咖啡
type Result {
    size: string,    // 大小：中杯、大杯、超大杯
    sugar: string,   // 糖分: 无糖、半糖、9分糖
}
```
Please translate the user request into a JSON object directly, with 2 spaces of indentation, use `null` to represent values that cannot be translated. Please make sure response JSON text directly.
请将用户请求直接翻译成JSON数据，用2个空格缩进，无法翻译的值用null表示。请确保直接输出JSON数据，不要回复其他内容。

Please translate the following user request into JSON object（请翻译以下用户请求成JSON数据）:
我想要一杯咖啡，不要加糖，大杯，加牛奶

AI的回答：

```json
{
  "size": "大杯",
  "sugar": "无糖",
  "milk": true
}
```

但是使用过程中发现存在一些缺陷：

AI可能不会直接输出JSON文本，而是用Markdown语法输出，也可能会输出多余的文字。

解决方案：使用正则表达式提取代码块里面的JSON文本。有些模型支持 JSON mode ，可以确保输出JSON格式数据。

AI可能输出的JSON语法不对，多余的逗号，添加了注释，将 null 写成了 undefined。

解决方案：使用 https://github.com/PiotrDabkowski/Js2Py 这个库将JSON文本当作JavaScript解析，提取返回的对象。

AI输出的JSON数据结构可能不对，会缺失字段或者多余字段。

解决方案：对数据问题做容错处理，校验数据，校验失败时让AI重新回答。调整 temperature 和 top_p 参数，减少输出的随机性和多样性，使输出更加稳定、集中和确定。

AI对字段的含义理解可能不对，返回了错误的数据。

解决方案：在TypeScript文本中写注释，描述字段的含义，给AI提供指导，给AI举例子。

微软的TypeChat库提供了很好的思路，但处理各种特殊情况时不够灵活，最好的效果是直接自己拼接提示词。我写了一个 typechat.py 已开源在GitHub Gist上，可以参考使用。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

2023年经历了监管风波、产品调整、家庭变故等悲喜交加的事，博客也很久没有更新了，在此做一个总结，新的一年继续创业。

2023年

2月底，我的AI产品被监管约谈下线，为满足合规只能用国产AI大模型。当时国产AI大模型还未开放使用，到4月份我把产品改成了AI工具箱，但底层还是ChatGPT，为避免风险所以没有上线推广。

5月至7月我把AI产品的佣金推广功能迁移到了 艺爪付费 中，AI产品没有进展。这段时期我的精力也转移到了新房装修、谈婚论嫁这些个人事情上。

8月中旬，我母亲因交通事故意外去世，之后我基本在处理家里的事情。到年底我和女朋友订婚、结婚，家里的事情大部分处理好了，我开始恢复精力投入工作。

这一年发生了太多事情，悲喜交加，对未来有希望，同时也带着遗憾。

创业已三年

从2021年开始创业，一转眼已经3年了，真是岁月如梭！创业之路不算顺利，没有取得大的成果，只是有了很多和以前不一样的经历。

我现在生活在小城市，没有太大的经济压力，创业和工作相对自由，是一种舒适的生活状态。回想3年前选择离开大城市，我觉得这是正确的选择，让我有时间陪伴父母、照顾家庭，让我有经济条件持续创业。

新的一年我会继续创业，抓住AI大模型的机会，争取早日财务自由。

在此特别感谢所有关注、关心、帮助我的朋友们，感谢大家的支持！
祝愿大家顺顺利利，一起财务自由！

回顾2023年目标

把 ChatGPT 做成稳定赚钱的产品

基于ChatGPT和国产AI大模型做成了产品，有收入但没有稳定盈利。

产品盈利 5 万元人民币

目标已达成，主要原因是在风口上抓住了机会，前期收益高，目前收益很少，每月收入大约1000元。

控制好作息，每周锻炼 1 次以上，保持高效率

作息比去年更好一些，爬山、散步的次数比去年更多，争取今年做的更好。

2024年目标

[✔️] 保持AI大方向不变，做用户愿意付费的产品
[✔️] 产品 月收入 1 万元人民币
[✔️] 管理好时间：照顾家庭，锻炼身体，高效工作

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

过去的两个月可以说相当刺激，我在ChatGPT风口上经历了产品的大起大落，在此总结分享我看到和学到的东西。

方向的重要性

在好的方向上努力，收获是100倍甚至1000倍，选好方向至关重要，方向不对努力白费。

变化是机会的重要来源，巨大的变化代表着巨大的机会，意外的成功和失败都蕴含着新机会。

用户和需求是产品的生命之源，从需求出发去思考产品，利用所有能用的技术去满足需求，方向基本就对了。

会员分销模式

会员订阅付费是很好的盈利模式，用户愿意为好用的产品付费，按月、按年为产品付费后就能长期留住用户，同时获得非常好的现金流。只要产品不断迭代完善，产品价值越来越高，收入就会越来越多，形成正循环。

分销是很好的推广模式，有把用户规模放大的效果。能赚钱是分享传播的巨大推动力，通过收入分成让用户帮你推广，就有源源不断的精准流量。做一级分销即可，多级分销无法体现产品价值，而且有传销的嫌疑。

合伙人原则

合伙创业需要确定好合作原则，把可能遇到的问题，坦诚相待提前约定好。下面是我们的原则：

1. 原则：要么一起成功，要么一起失败，不可另立门户。
2. 退出机制：如果要退出，股份只能由合伙人回购，不允许卖给其他人。

资金方面我每个月用 Beancount 记账，账本放在Git仓库共享给合伙人，做到清晰透明。

上周我的前端伙伴因为多方面的原因选择退出了，我们按照约定好聚好散，产品继续正常运转。

看数据做决策

用户可能会提很多建议，自己和合伙人会有很多的想法，竞品和各种行业信息也会带来很多启发，从逻辑上、经验上很难判断哪些是更值得做的，很容易走弯路。

从产品数据能清晰的看到用户和需求，能指明最正确方向，答案都在数据里面，是最客观和准确的，做产品一定要认真看数据做决策。

政府监管风险

在 2 月 21 日，我被网信办监管部门上门约谈，产品也按要求主动下线了。需要等安全评估通过才能上线，预计一个月之后会有整改意见。

根据多方了解到的信息，主要原因是 ChatGPT 涉及境外数据，这点非常敏感。从大环境来看，中美关系越走越远，互相防备，再加上国内内容审查一直就特别严格，在国内继续用 ChatGPT 的话风险非常大。

小创业者的机会

目前我可以确定 AI 这个方向有巨大的机会，变化、风险、机遇并存。

目前我的判断是两条路，可以都尝试：

1. 用国产的和开源的AI技术，在国内继续做AI应用。
2. 用ChatGPT的API接口，在境外面向海外用户做AI应用。

国内的AI技术比ChatGPT落后一年左右，只要在这个方向上坚持一年，可以抓住更长期的机会。

推荐书籍

• 《合伙人原则》
• 《网信部门常用法律法规》

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

距离 2021自宅创业总结 已过去整整一年，刚好进入了创业新阶段。在这个忙碌的春节对 2022 做一个总结，回顾过去，规划未来。

2022年创业情况

在2022年我是远程兼职上班 + 业余时间创业的状态，做了2个新产品，其中艺爪付费做了8个月，ChatGPT小程序做了2个月，另外有2个月主要在考驾照、接外包项目。之前做的蚁阅RSS和果蔬时节只用了很少的时间维护。

创业收入和支出

收入比去年多一些，主要是外包接单和卖账号这类一次性收入增加了。

支出和去年相当，没有大的变化。

注：数据截止2022年12月31日，工资收入、生活支出等在此略过。

创业产品总结

我投入了约8个月时间在艺爪付费上，做成了一个有价值的产品，但并没有获得直接的收入。艺爪付费目前有100+用户注册，有2个产品接入使用，另外我自己有2个产品接入。它给我最大的回报，是我做新产品时可以快速实现付费功能，降低新产品的开发和维护成本。

最近2个月我做了ChatGPT小程序（超级AI），这是一次意外的成功，也是第一次有了合伙人。ChatGPT小程序目前有5w+注册用户，我们年前刚刚上线了ChatGPT会员版，第一次体验到了赚钱的感觉。进入了创业新阶段，机会和风险并存，看到了希望但还需努力争取。

最重要的是，这一年的经历更新了我对创业的认知。

1. 让自己接触更多机会： 认识更多的人，去更远的地方，经历更多事情，接触新事物，尝试新想法，给自己创造更多可能性。

2. 从用户和需求出发： 用户和需求是产品的生命之源，产品只有满足用户需求才能存活，用户愿意付钱（或时间）产品才能赚钱。

3. 掌握生产资料： 软件产品是信息时代的生产资料，并且可以完全通过自己的双手创造出来，掌握生产资料就等于解放了自己。

回顾2022年目标

做 3 款新产品，不耗在单个产品上

只完成了2款新产品，有几个产品在想法阶段被自己否定了，直到机缘巧合遇到ChatGPT。我应当更加积极地寻找有用户需求且能赚钱的产品，而不是把过多时间投入在艺爪付费上。

产品盈利 2 万元人民币

远未达标，应当更深刻认识到方向的重要性，把时间投入到能赚钱的产品上。

适当旅行，控制好作息，保持高效率

基本达标，保持了睡眠充足，但锻炼太少了。长时间工作会颈椎和肩膀痛，需要严格落实间歇休息，多喝水，多活动颈椎肩膀。

2023年创业目标

[✔️] 把 ChatGPT 做成稳定赚钱的产品
[✔️] 产品盈利 5 万元人民币
[✔️] 控制好作息，每周锻炼 1 次以上，保持高效率

推荐一些书籍

• 《创新与企业家精神》
• 《矛盾论》和《实践论》
• 《摩根信札》

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

本期最大的收获是做ChatGPT小程序，上线当天用户量突破1000，我第一次做出这么火爆的产品。

ChatGPT小程序

故事从12月4日开始，有个之前认识的网友联系我，得知ChatGPT账号非常好卖，ChatGPT是OpenAI最新发布的人工智能对话机器人，效果非常惊艳。

我写程序批量注册，他负责销售，收益分成。我很快写好了程序，注册了一批ChatGPT账号，赚了一点钱。然后发现市场上ChatGPT账号价格越来越低，也很难批量销售出去。

我们想到可以做一个小程序，把ChatGPT的功能做到小程序上，打开就能直接用。我在一个创业群里发了条消息寻求合作，很快找到一个做小程序的伙伴，一起合作开发。我负责后端，他负责小程序，不到3天小程序急速完成上线，上线当天用户量就突破1000，涨势非常好。

我们也做了一些推广，主要是营销的伙伴负责，带来很多的流量，我们还预想着日活过万，然后小程序就被举报封了，我们发布的两个小程序同时被封。举报人和我正好同在一个微信群里，虽然很难过，但还是接受了现实，大家都按丛林法则生存。

小程序被封之后，我们马上整改去掉违规的内容（群二维码），然后开始申诉。过了一天多，小程序终于恢复了，目前我们在继续迭代改进。附两个小程序码欢迎体验，只是名称不一样，内容完全一样。

如果你有流量擅长推广，非常欢迎合作！如果需要批量采购ChatGPT账号，也欢迎联系。

艺爪付费

果蔬时节APP，在阿里云上申请的APP电子版软著，但还要等半个月才能拿到证书。

艺爪付费增加了支付宝APP支付方式，但还没时间更新文档，会继续完善。

招聘

我在BOSS直聘上，尝试了一下招聘一个前端工程师，月薪开的3～5K，岗位放上去一下午收到50+简历。基本都是应届生，面试了几个水平确实不太行，写简单的代码都磕磕绊绊。经验丰富的工资要求又高，我完全负担不起，所以就没有继续招聘了。

我也看到疫情之下，毕业生就业压力非常大，其中一个候选人和我说，工资只要够吃住就可以接受。

看书

这段时间看了一点创业的书，主要是《心力》、《毛选1》里面的矛盾论、实践论和唯物辩证法。

创业是和一群未知的人，去一个未知的地方，干一件未知的事情。面对充满不确定的未来，只具备解决已知问题的能力显然是不够的。认知深刻，心力强大，创业才能走的更远。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

果蔬时节APP

果蔬时节是我去年开发的小程序，我打算做成一个APP来体验整个开发、上线的流程，也可以作为艺爪付费的参考案例。果蔬时节基于 uni-app 开发，用的是跨平台框架，适配成APP比较容易，但第一次尝试也折腾了几天时间。

目前适配了 Android 端，正在尝试上架华为应用商店。有些应用商店上架需要软著，正准备申请。

适配APP遇到的主要问题（都已解决）：

1. 确保样式、组件的兼容性，适配不同的平台。
2. 增加用户协议和隐私政策，上架必须提供，可以参考别人的改一改。
3. 打包成安装包，步骤很多以及各种配置比较复杂。

下一期计划适配 iOS 端，申请软著以及上架。

MBTI性格类型

我最近半年关注了 MBTI（迈尔斯-布里格斯性格分类法），有时感觉很准有时又觉得不准。最近我特意读了 《天资差异》 这本书，书中第一部分对 MBTI 理论解释的很清晰透彻，后面几部分有些枯燥，如果你也对 MBTI 感兴趣的话，推荐阅读。

据我个人观察和判断，我觉得 MBTI 理论是基本准确的：

1. 《军队院校招收学员体格检查标准》第四十四条 按照《中国MBTI－G人格类型》实施检测，检测判定为ENFP、INTJ、ISTP人格类型，且符合下列情形之一的……不合格。
2. 在职业偏好、行为习惯、学习成绩等划分的人群中，MBTI 类型有显著的倾向性，例如学霸中 ISTJ 占比很高，多才多艺的 ENFP 占比很高。

但是 MBTI 不可偏信，适合作为参考：

1. 性格是内在的特质，只有自己真正了解自己的内心，其他人只能看到表象。
2. 统计学上显著的倾向性仅仅是倾向性，不是绝对。每个人都是独一无二的，MBTI 只能描述最典型的特点，刻板印象带有较多偏见。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

本期进展较少，国庆假期也没有投入时间开发产品。主要成果是考到了驾照，然后买了车。

艺爪付费

主要做了两个小功能（更新日志），写了一篇文档（案例 - 蚁阅会员付费的实现）。

• 新增付费界面介绍文案配置。
• 新增用户使用兑换码接口，兑换码功能可以单独使用了。

下一期时间会更充裕，继续努力更新迭代。

驾照&买车

国庆节前考完科目三、科目四，拿到了驾照。然后国庆假期看车、买车，前几天办好了所有手续和车牌。车子买的是吉利帝豪S，普通燃油车，落地价差不多10万。

考虑到偶尔会开车跑周边县城，以及逢年过节带家人出行。五菱宏光MiniEV续航不够且空间太小，身边亲人朋友都不建议买。其他长续航电动车、混动车价格偏贵。综合考虑买车+养车成本以及实用性，我选择了买燃油车更稳妥。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

艺爪付费

这一期艺爪付费做了一些更新，主要包括：

1. 接入了支付宝标准支付渠道
2. 后台界面支持手动增减用户余额
3. 会员数据导入增加执行进度，支持大批量导入
4. 付费墙和权益增加别名字段，方便API集成
5. 其他界面和功能上的小改进

我也把蚁阅的会员系统迁移到艺爪付费了，大约半天时间实现代码集成，然后花了一些时间测试和验证。后续我准备写一篇文章介绍迁移过程，蚁阅的代码也是开源的，方便用户作为实际案例参考。

上一期我申请了奇绩创坛投资，结果出来了，略有遗憾未能通过。投资人的反馈主要有 【现有替代手段多】、【项目推进速度不够快】。我觉得这个反馈非常准确，也很值得思考。

现有替代手段多

主要的替代手段，一个是自建会员系统、自己对接支付渠道，另一个是直接用APP应用商店SDK实现内购。

我尝试回答【为什么选择我】这个问题，这也是产品的迭代方向：

1. 成本：降低开发成本，让开发者只需几个小时，就能实现完整的会员付费功能。产品要非常容易集成，对开发者友好，提供保姆级教程和开源案例。
2. 实用：全平台统一，处理好平台差异和各种边界情况。提供完善的后台管理、数据报表、团队协作功能。支持国内市场和海外市场，提供国际化和本地化方案。
3. 信任：数据安全，做到金融级安全保障。做好系统设计，保障长期稳定运行。持续改进，积累良好口碑。

项目推进速度不够快

这几个月由于各种事情，我在艺爪付费上投入的时间确实不多。

原本计划今年开发3个新项目，但时间不太够用。我打算只做一个全平台的简单APP，体验一下开发APP上架应用商店，也可以作为艺爪付费的参考案例。

我感觉艺爪付费离盈利还有些远，但这个产品确实有价值，我会继续独立开发，有机会的话会考虑招募兼职小伙伴。

其他

1. 科目三挂了，可能是太紧张导致严重失误。
2. 中秋前几天本地疫情，封控10多天了，等解封后继续考科目三。
3. 外包项目完成，款项也收到了。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

这一期比较忙碌，花了很多时间在考驾照上，艺爪付费在继续完善。

考驾照

这段时间经常天亮出发去练车，趁早晨比较凉快，练一个小时车。上周考过了科目二，顺利的话预计9月初拿驾驶证。

随手拍的日出，偶然发现的风景。

艺爪付费

艺爪付费主要修复了一些小问题，正在接入支付宝标准支付渠道，投入时间不多。

还有一件事情，有网友推荐我申请 奇绩创坛 天使投资。我看了一下申请方式，非常务实，只需要填写申请表（有很多值得思考的问题），不需要商业计划书和PPT。

因此我就试着申请了，预计8月底会有结果，无论通过与否对我来说都是好消息。如果很幸运通过了，那我可以组建小团队专注这个方向，创业旅程会更精彩。如果没有通过，说明方向不够好或者市场不够大，竞争会更小，继续独立开发更适合。

接私活项目

机缘巧合，一个蚁阅的老用户联系我，希望我帮他做个网站。对方是产品经理出身，对要做的东西想的比较清楚，我感觉项目不是很复杂，谈妥之后就签合同接下来了，每周花一天时间做。

虽然过程中需求/方案还是有些调整，但需求比较明确，有原型图和需求文档，不至于出大问题。主要的影响是我自己的时间不太够用了，这段时间都特别忙碌。

认识更多的人，让更多人认识自己，给他人提供价值，机会随之而来。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

艺爪付费

这一期艺爪付费迭代更新了很多功能，并且有了一个成功案例 集美美图App。集美美图的作者也是独立开发者，这个App做的非常漂亮，很有设计感，值得学习，推荐大家体验！

这段时间我认识了很多有趣的网友，有创业成功的前辈，有正在创业或独立开发的朋友，也有很多准备做独立开发的朋友。独立开发是比较孤独的，但一路上遇到很多同路人，互相交流，便不觉得孤独了。

接下来我会继续完善艺爪付费，主要包括：

1. 适配更多支付渠道，优化支付体验
2. 支持配置界面内容文案，优化界面展示
3. 完善系统现有的功能，提高易用性和安全性
4. 研究增加礼品卡功能（发卡工具）
5. 研究无需账号系统、无需代码的集成方式

继续努力吧！

重回赣州

在外面折腾几个月后，我在6月底重回老家赣州了。

离开一线城市

决定离开一线城市之前，我和几个在一线定居的朋友聊了一下。

在一线城市定居，房子是最大的问题。按现在的房价，一套房大概要500万，首付120万，掏空6个钱包，背30年房贷，每年还贷30万。在一线城市周边定居的话，房子勉强买得起，但要么工作通勤时间极长，要么过候鸟生活。

以我目前的经济条件，压力巨大，在一线城市也没有归属感，所以彻底放弃在一线城市定居的想法了。

赣州怎么样

房子方面，赣州一套房不到100万，有几年一线工作的积蓄买房压力很小。我在2021年上半年买了一套，今年年底交房，房子问题算是已经解决了。

工作方面，赣州主要是加工制造业，软件相关的工作比较少，招聘网站上普遍工资8k-10k，够养家糊口。但互联网职业很适合远程，我可以给一线城市的企业远程工作，哪怕工资缩水一半，也不会低于10k。

经济上无压力，在家上班，有时间做自己喜欢的事情（比如独立开发），躺平很舒服。

未来的打算

首先是婚姻问题，有点感慨造化弄人，我也在相亲了，看缘分吧。之后打算是成家立业，结婚生子，过上平凡的生活。

工作上会保持一边远程兼职、一边独立开发的状态，可能会持续3～5年。等自己的产品赚钱了，再转成全职独立开发。

近期正在考驾照，刚报名了驾校，然后打算买个车子，可能会买五菱宏光MiniEV。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

这一期主要在做 艺爪付费 (EZRevenue) 这个产品，终于上线内测了。

艺爪付费

艺爪付费 https://www.ezfuns.com/
为网站App提供会员、订阅、内购付费功能

这个服务适用于网站或App通过增值付费盈利的场景，适合于个人开发者、小团队、初创企业以及中小型企业，计划中支持中国+海外市场。

1. 支持订阅制、买断制、积分道具等多种付费模式，支持兑换码，简单配置即可上线使用。
2. 支持微信支付、支付宝、收款码、比特币、PayPal等多种支付渠道，个人开发者也能收款。
3. 累计收款100万元内免费，超出后按1%收取服务费。

欢迎感兴趣的朋友试用和反馈，也可以 联系我 加入内测交流群。

技术架构

1. 数据存储：腾讯云的 MySQL 服务，对象存储
2. 后端API：基于 Python，用了 Falcon、SQLAlchemy 框架
3. 服务器：通过腾讯云的云函数容器镜像部署
4. 前端界面：基于 Vue，用了 Vuetify 框架
5. 主站和文档：使用 Docusaurus 生成静态网站
6. 静态资源：通过腾讯云的对象存储，API网关，CDN 部署

整个项目时间投入：

1. 调研、思考、业务建模、后端代码开发，大约2/3时间
2. 界面设计、前端代码开发，大约1/3时间

一些感想：

1. 完全使用云服务非常高效，省时间、很便宜、很稳定。
2. 用成熟稳定、有点老但有维护的框架，开发效率最高。
3. 代码只要设计上、方向上没有问题，就不要纠结细节，面向业务一把梭更有效率。

其他

这个月我跑到惠州来了，会在这边待几个月，深圳/惠州/广州附近的朋友，可以约面基呀。

对了，推荐一个有意思的UP主 轻徙鸟 - 自由职业者的租房旅行计划，也是一个朋友推荐给我的。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

这一期继续在做付费订阅服务，后端基本完成，下一步是做前端界面，进度比预期慢了一些。顺便分享一下商标注册的事情。

EZRevenue

接着上一期梳理完业务逻辑，然后是持续写代码。写了一半感觉业务模型还有点不对，我决定再做一轮调研。调研主要分析了 50+ 网站和 App 的充值页面，思考我的业务模型能不能满足这些场景。也看完了 SaaS Pricing Strategy 这本书，对理论和实践都很有帮助。

调研后调整了部分业务模型，业务模型是超前设计，大概能满足95%的场景，有些大企业的 SaaS 定价过于复杂，很难满足。实现上先做比较简单的场景，简化实现，满足独立开发者和初创企业的需求。

写代码的过程中，我感觉单元测试非常有用，一方面确保自己不会把好代码改坏，另一方面测试失败了能快速定位问题，用 Python 这种动态语言也不会「重构火葬场」。跑一遍测试全过，就可以专心做下一个任务了。

后端部分告一段落，接下来做前端界面，争取快点上线。

关于产品名称

产品的中文名称我还没确定，其中 EZ 等于 艺爪（商标），后面还需要一个词。

主题：为网站和App提供会员、订阅、付费功能的服务。

我想到的有这些名称：

1. 艺爪付费：订阅付费，从消费者的角度可以叫做付费。
2. 艺爪收费：从开发者/商户的角度就是收费，开发者是我的直接用户。
3. 艺爪收款：同上，但这个名字感觉像聚合支付服务。
4. 艺爪小店：有点像一个软件商店，但不是应用商店平台，而是方便开发者在产品里卖会员和增值服务。

我也比较纠结，不知道哪个比较好，有什么建议吗？投票也行。

或是从 SEO 的角度，假如你想找一个这样的服务，你会搜索哪些关键词？欢迎博客留言。

商标注册

我在去年 10 月份提交的商标注册，前段时间刚注册成功，拿到了商标证书。

共注册了 5 个商标，其中 4 个注册成功，1 个被部分驳回，目前还在公告期。流程时间线：

• 2021-10-13 腾讯云下单
• 2021-10-14 提交给商标局，商标申报
• 2021-11-05 通过形式审查，商标局下发受理通知
• 2021-12-23 通过实质审查并进入公告期
• 2022-04-14 通过商标审查，商标局下发注册证书（电子版PDF）

各大云平台都有商标注册服务，我是在腾讯云申请的商标注册，选择快速注册即可。每个商标大类 320 元，大类里面可以选 10 个小类，超过 10 个要加钱。

商标的用途

简单来说，商标可以用于各种需要展示名称的场景，例如App名称，网站名称，公众号名称，店铺名称，广告标题等等。

用途1: 解决了产品起名问题，商标名可以放心使用，不用担心侵犯别人的商标。

用途2: 防止竞品用类似名称做推广/蹭流量，只要发现了就可以投诉让对方下架，严重的可以起诉。

用途3: 有些平台需要审核产品名称，商标注册证书可以作为依据，方便产品上架。

商标名称检索

商标有很多个大类，在同一个大类里面，商标名称不能和已注册的商标近似，否则容易被驳回。

提交注册的时候，建议每个大类单独提交一个，不要混着提交，这样一个类别被驳回的不会影响其他类别，通过率更高。

• 阿里云商标查询 https://tm.aliyun.com/
• 腾讯云商标查询 https://tm.cloud.tencent.com/
• 商标局官方查询 http://wcjs.sbj.cnipa.gov.cn/

建议提交注册之前，在商标局官方查询检索一遍，这里的结果最准确。

商标类别怎么选

和互联网密切相关的大类主要有：35类-广告贸易，9类-电子电脑，38类-通讯传媒，42类-技术服务。35类-广告贸易属于万能类型，商业行为基本都带广告属性，建议注册。9类-电子电脑可以保护软件产品，例如App，建议注册。

每个大类里面可以选 10 个小类，小类里面还有很多小项，建议防御性注册选择尽可能多的小类，小类里面的小项选一个即可。这样他人不能在这些小类上申请与该商标相同或近似的商标，实现一部分保护的目的。

具体操作上，可以查询别人商标的做法，例如可以查询：拼夕夕、阿里爷爷、微信豆，这些都是防御性注册的商标，可以参考他们选择的小类。

商标被部分驳回

商标被部分驳回的情况，基本是和已注册的商标近似了，可以默认不处理，这样商标局会给通过的部分发注册证书。如果还是想要注册下来的话（并且不差钱），可以联系商标注册的公司或顾问试一试复审。

因为我也有一个商标被部分驳回了，就发现好几个商标注册的人打电话、加我微信，问我要不要申请商标复审。我没有申请复审，没有必要，还很贵。

另外推荐阅读 少年老陈 - 聊聊商标注册的那些坑，防坑防骗防套路。

以上是我注册商标的经验总结，建议仅供参考，如有错误欢迎指正！

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

这一期主要在做新产品开发，没有太多分享的内容。

EZRevenue - 开发中

一个为网站和App提供会员、订阅、付费功能的服务。

梳理业务逻辑

为了理清应用内购(IAP)系统的逻辑，我研究了 Apple AppStore 后台系统，花了 99 美元注册 Apple 开发者会员（争取赚回来！）。同时也研究了华为应用商店的内购系统，发现和 Apple AppStore 基本一致。

调研期间发现一个专门研究定价的网站，上面有本电子书 SaaS Pricing Strategy 值得一读。

代码开发

主要做了数据建模，后端接口开发。

EZAuth - 已完成

类似 Auth0 和 Authing 的用户鉴权服务，只做了最基本的功能（够用）。复用了很多蚁阅账号系统的代码，进展顺利，已完成上线。

一些想法

充分的调研可以解决很多问题，少走很多弯路。

软件库升级是很消耗时间的工作，除非确实能显著提高开发效率，否则不要折腾。稍微旧一些，长期维护的项目更具有生产力。

软件产品定价有越来越贵的趋势，从永久买断模式变成订阅模式，再变成按席位订阅模式（按人头x时间付费）。价格定多少取决于给用户提供的价值有多少，产品价值会随着使用时长增加而增加，随着使用人数增加而增加，这样的定价模式就能给企业带来更多利润。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

春节已过去一个月，向着 2022 年目标，重新出发。

开始新产品

新产品是一个为网站和App提供会员、订阅、付费功能的服务，会集成多种支付渠道，只需几行代码就能让你的网站和App支持付费订阅。对标产品是国外的 RevenueCat。

这个产品的想法已经酝酿了一年多，考虑到面向开发者的产品太难赚钱，所以没有很快着手去做。在和很多开发者交流过程中，我感觉到大家需要这样的服务，所以应该有足够价值、值得做，能赚点零花钱也好。

目前我调研的情况是，国外有两个 RevenueCat 的竞品，但国内没有发现类似产品（欢迎提供线索）。有些关联但并不相同的是内容（知识）付费平台，例如：Patreon、面包多、爱发电等。

这个产品的前身是蚁阅的会员功能，我会把它做成支持多租户，功能相对完善，开箱即用的服务。

这一期主要做了：

1. 集成微信支付渠道，把果蔬时节的支付代码迁移了过来。
2. 重构代码，部署方式改成腾讯云-云函数（内部项目: ezfaas）。
3. 统一的用户鉴权服务（SSO登录），正在开发（内部项目: ezauth）。

新产品正在开发，可能还需要 2 - 3 个月上线，敬请期待。

云函数部署

我的所有新产品都会首先考虑云函数部署，按量付费、免运维、低成本、弹性扩容这些特点非常适合做创业项目，全是优点。以下是我整理的完整部署方式。

网站通常包含后端服务，数据库，前端静态文件。数据库直接买云厂商提供的。

后端服务

后端服务通过「云函数」部署，采用容器镜像部署方式，不建议用内置的各类编程语言模板。

1. 通过 Dockerfile 和 multi-stage build 制作很小的镜像，通常不超过 100M，推送到云厂商的镜像仓库。
2. 创建云函数，选择容器镜像部署，用环境变量做程序配置。
3. 写一个部署脚本，一键打包和更新部署镜像。

前端静态文件

前端静态文件通过「对象存储」部署。

1. 对象存储创建空间（Bucket），开启静态网站服务。
2. 通过命令行工具，将打包好的静态文件上传到对象存储。
3. 写一个部署脚本，一键打包和上传文件。

网关和CDN

前后端部署之后，再通过「API网关」，将不同路径的请求转发到前端和后端。网关会有一个默认的 HTTPS 访问地址。

添加 CDN（全站加速/动静加速）域名，源站为 API 网关地址，配置 DNS CNAME 解析到 CDN 地址，此处配置好静态文件缓存规则。

再生成免费的HTTPS证书，云厂商都有提供，配置到 CDN 域名上，实现全站 HTTPS 访问。

网站监控

最后可以部署 Gatus 服务（健康监控），配置每隔几分钟请求一次后端服务。这样可以使云函数保持活跃状态，减少冷启动时间，同时也可以监控异常情况。

用户鉴权服务

用户鉴权服务类似 Auth0 和 Authing，我想把我所有产品的用户模块都统一起来，毕竟每个产品都写一套登录注册就太麻烦了。但这类核心服务我不想依赖第三方，需要自己完全可控，更放心也更省钱。也不能靠自己开发，时间成本太高。

所以我调研了一些开源的替代品，最后选择基于 Django OAuth Toolkit 定制开发。

Django插件，最灵活
https://github.com/jazzband/django-oauth-toolkit

Django + 中文 LGPL
https://github.com/longguikeji/arkid

Java 老牌项目
https://github.com/keycloak/keycloak

golang
https://github.com/tarent/loginsrv

golang + 中文
https://github.com/casdoor/casdoor

golang 功能较多
https://github.com/ory/kratos

选择 Django 插件主要原因是我很熟悉 Python，使用最灵活，方便按需修改，其他选项供参考。

我到了新城市

最近两周天气转暖，我来到了福建的一个小城市，租了一间小房子住。生活更简单，日常琐事更少了，最大的变化是大幅减少了吃饭时间。

我现在早餐吃包子鸡蛋，午饭和晚饭都吃 若饭，用 Blender bottle 不锈钢摇摇杯，非常好清洗，5分钟吃完一顿饭，每天大约能节省 2 小时。

除了节省时间，调配好的代餐其实营养更均衡，没有辛辣油腻和过多糖分。但是和父母在一起时，没法这样吃，老一辈的观念接受不了。

升降桌和工学椅也配好了，生产力拉满。周边环境还不错，时常散散步，劳逸结合。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

在 2021 年 04 月，我 开始了自宅创业，转眼间春节将至，自宅创业已经 10 个月，是时候对 2021 做一个总结了。回顾一下我当初立的目标，做的产品，生活和收入情况，以及来年的打算。

收入和支出情况

统计时间范围：2021-04-09 至 2022-01-26

注：兼职等其他收入不太方便公开，所以在此略过。

待在老家不需要房租和伙食费，但支出加起来还是超过了3万块，比我预期的多一些。

很低的生活成本，再加上有部分兼职收入，所以我的现金流是正的，不用担心钱用光了。

回顾2021年目标

做 2～3 款产品并盈利，年收入 3 万元人民币

比较遗憾，2021年只做了「果蔬时节」这一款产品，再加上维护「蚁阅」。果蔬时节没有盈利（还亏了一些），蚁阅基本收支平衡。

如果只算被动收入的话，离目标还差很远，算上兼职收入则有 3 万元。

学习，读书，听书，保持高效

今年读书不多，只有两本，基本是听完的：

• 《采购与供应链管理》
• 《三体1》

还有很多书躺在书架上（电纸书），但没有时间看。

技术方面，不太关注新技术，主要用自己熟悉、“无趣”、稳定的框架和工具。用 Go 写了命令行工具，虽然写起来很生疏但还是很快实现了功能，以后跨平台的命令行工具会首先考虑用 Go 实现。

我也在完善自己的软件”基础设施”，把常用的工具用的更顺手，提高业务开发的效率。

保持身体健康，体重增加到 110 斤

夏天秋天偶尔会跑步+散步，稍微锻炼一下身体，天气变冷之后就没有再锻炼过。今年体重从 100 斤增加到了 122 斤，超额完成目标（主要是吃的好:），现在要适当控制饮食了。

有些时候很有激情，还是会写代码写的很晚，然后身体状况就会不太好，需要彻底停下来休息，没能做到劳逸结合。我的视力也下降了一些。

继续独立开发

我喜欢这 10 个月的生活状态，时间相对比较自由，可以做自己喜欢的事情，可以睡到自然醒。老家环境很舒适，有蓝天白云、青山、绿树、虫鸣鸟叫，清新的空气。不过生活也不是完美的，这里夏天太热、冬天太冷，热天蚊虫特别多。

这 10 个月的经历，让我想清楚、看清楚了未来方向，明白了自己想要什么，知道自己要做什么，以及不做什么。我也认识了很多同路人，有和我一样正在艰难前行的，也有少数已经成功的，就像旗帜一样指引着方向。

放弃丰厚的工资，做产品收入这么少，值得吗？

能够产生被动收入的软件产品，可以理解为信息时代的「印钞机」，并且可以完全通过自己的双手创造出来，虽然创造的过程很艰难，也不一定每个人都能成功。如果把被动收入算作存款利息的话，被动收入相当于 20 倍的存款（假设5%利率）。

由于资本家垄断了生产资料，劳动者无法独立地进行生产，故只能出售自身劳动力，供资本家剥削。

从资本论的角度理解，软件产品就是信息时代的生产资料，掌握生产资料就等于解放了自己。

所以我觉得，我会一辈子做独立开发，直到财富自由。

This is how I want to live the rest of my life.
— Michael Lynch

新的一年我应该会换个小城市生活，生活成本会更高但在承受范围内，也顺便旅行放松心情。

2022年目标

[✔️] 做 3 款新产品，不耗在单个产品上
[✔️] 产品 盈利 2 万元人民币
[✔️] 适当旅行，控制好作息，保持高效率

截止日期 2022 年除夕。

新产品已经有了大致想法，即将着手开发。对于盈利说实话我没有太大把握，我会专注于对用户有足够价值的方向，如果没什么人用（留存率太低），那就马上换方向。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

感觉时间过的飞快，先记录一下这个月的事情，年终总结要等过年前更新了。

代码重构

这个月前期主要在做代码重构，提高项目的开发效率。

首先是开源了 Hami-Vuex 这个库，我也将蚁阅和果蔬时节两个项目的前端状态管理换成了 Hami-Vuex。重构之后代码更加模块化了，代码提示也非常友好，可以参考 PR#11。

其实很早在蚁阅的前端代码中就有部分模块化的尝试，但写法算不上优雅，在果蔬时节中把这个尝试继续完善，最终抽象成了一个完整的库。

另一个重构是把果蔬时节的小程序端和后台管理界面代码拆分，原本是写在一起，类似这样：

src/
    pages/
        admin/
            xxx.vue
        app/
            xxx.vue
    store/
        admin/
            xxx.js
        app/
            xxx.js
package.json

当初用了很取巧的办法（条件编译）在一套代码里运行不同的界面。为了方便修改和部署，决定拆分成两个独立的目录，可以分别打包部署：

admin/
    src/
        pages/
        store/
    package.json

app/
    src/
        pages/
        store/
    package.json

shared/
    components/
    package.json

其中有部分代码需要复用，放在 shared/ 目录中。为了复用代码，尝试了 Monorepo 的模式，例如 yarn workspace, pnpm workspace, npm link，踩了一堆坑。最后发现解决办法是修改一个不起眼的 Webpack配置，这样文件软链接（符号链接）才能正常使用。

蚁阅图片代理更新

在12月底的一个下午，连续收到阿里云的几条告警短信，当时我被吓到了。

检查了一下违规URL发现都是色图，阿里云检测到之后主动屏蔽了。幸好只是屏蔽了几个URL，没有直接屏蔽我的主域名，收到短信我马上就去把蚁阅图片代理功能关闭了。

估计是有用户订阅了奇奇怪怪的网站，然后图片被缓存到了阿里云CDN上，被阿里云的鉴黄程序扫描到了。为了更彻底的解决这个问题，必须把图片代理功能和主站隔离，这样万一图片域名被屏蔽也不会影响蚁阅其他功能。

具体做法是把图片代理功能单独部署在阿里云-云函数上，用独立子域名，所有图片请求不经过CDN和缓存，另外图片代理链接设置30分钟有效期，避免被分享传播。目前蚁阅图片代理已经更新好了，功能也已经恢复了。

蚁阅的经营情况

访问量统计，基于自建的 Plausible 服务，每天大约是 200 个活跃用户。

收入统计，基于 Beancount（介绍），蚁阅 2021 全年收入是 1905 元，大致可以负担服务器开支。

对于蚁阅这个产品，我希望保持小众，稳定运行下去，但不太会加新功能了。等其他产品赚到钱了，再考虑把蚁阅做大，目前蚁阅做的越大风险越大。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

Hami-Vuex 是一个 Vue 状态管理的库，基于 Vuex 实现，提供了更「香甜」的使用方式，所以叫做哈密瓜味的 Vuex！

主要特点：

• 基于 Vuex 构建，可与 Vuex 3 & 4 兼容和混合使用
• 兼容 Vue 2 和 Vue 3，低学习成本，无迁移压力
• 易于编写模块化的业务代码，Store 文件不再臃肿
• 完全的 TypeScript 支持，代码提示很友好
• 类似 Pinia 的用法（可能还更简单）
• 单元测试 Line Coverage: 100%

举个简单的例子，体验一下：

const counterStore = hamiVuex.store({

    // 设置一个唯一名称，方便调试程序和显示错误信息
    $name: 'counter',

    // 定义状态
    $state: {
        count: 0,
    },

    // 定义一个 getter，和 Vue computed 类似
    get double() {
        return this.count * 2
    },

    // 定义一个函数，等价于 Vuex action
    increment() {
        // $patch 是内置的 Vuex mutation，用于更新状态
        this.$patch({
            count: this.count + 1
        })
    },
})

// 在 Vue 组件中使用
console.log(counterStore.count)
console.log(counterStore.increment())
console.log(counterStore.double)

开源地址：

GitHub：https://github.com/guyskk/hami-vuex

详细文档及设计思路都在 GitHub 仓库中，欢迎品尝！
好用的话求 Star 哇！

一个月时间又过去了，生活基本是平淡的，但也有些零零散散的，有意思的事情，就当流水账记录一下。

远程兼职

我现在每周大概 4 天做远程兼职，这个月主要在做前端项目，用了 Vue 3 和 Typescript。

Vue 3 生态目前不是很完善，重写了太多的库以及开发者工具，估计再过半年能稳定下来。Typescript 用上了很舒服，类型提示和代码补全可以提高开发效率，减少低级错误。

最近也开始做 Python 后端项目，和我的技术栈很匹配。半独立开发的状态感觉很好，压力小很多，写代码的效率也有所提高。

果蔬时节小程序

果蔬时节后台部分终于完成上线了，之后在做代码清理和重构，丢掉一些历史包袱，等清理完之后再继续开发小程序端。

重构过程中，顺便造了一个前端轮子 Hami-Vuex，欢迎关注，过几天我单独写篇文章介绍一下。

时间管理

这个月我用 Toggl 记录了时间花费，并不是远程兼职的要求，完全是为了自己分析和管理时间。因为是记录给自己看的，所以我可以完全忠实的记录时间，而不会有任何的顾虑。

我的一些占用时间偏多的地方：

睡的太久了：
我通常是在0点之前睡觉，9点半左右醒来，差不多是自然醒。可能是天生比较能睡，这个就顺其自然了。

吃饭太久了：
大约是洗漱+早饭：1 小时，热菜+午饭：1.5 小时，晚饭+洗漱+家人闲聊：2.5小时。一方面是我吃的比较慢，另一方面是磨蹭及一些杂事。如果独居 + 若饭 的话，可以节省大部分时间。

业务之外的事情：
例如购物比价，逛网站论坛，听播客，阅读博客和资讯，零零散散也占用了不少时间。

Macbook Air M1

11 月底我买了台 Macbook Air M1，用了半个月，感觉非常好，性能很强，程序秒开，续航十足，完全静音，键盘好用，价格很实惠。兼容性也非常好，iTerm2 设置使用 Rosetta 打开，可以完全兼容 x86 程序。使用 Docker 也没问题了，如果没有 ARM 镜像可以通过 --platform=linux/amd64 参数运行 x86 的镜像，性能也不会太差。

两个字总结：真香！

税务开发票

前几天跑了一趟税务大厅，把开发票的流程搞定了，在此记录一下。

从税务角度，公司分为「小规模纳税人」和「一般纳税人」，发票分为「普通发票」和「专用发票」，开票方式有「自开发票」和「税局代开」。

小规模纳税人的税率低，但不能用专用发票抵扣进项税，增值税 = 销售额 x 税率。一般纳税人税率高，可以用专用发票抵扣进项税，「进项」可理解为购进货物/原材料的成本，增值税 = (销售额 - 进货成本) x 税率。企业默认都是小规模纳税人。

普通发票和专用发票的区别，就是上面提到抵扣进项税的区别，一般来说开普通发票就可以了，除非付款方是一般纳税人并且要求开专票。

公司自开发票的话，可以到税务大厅免费申请，税务会核定你一个月能开多少张票，以及额度是多少，然后发一个 UKey（类似U盘）。拿到 UKey 之后，下载官方的税务开票软件，按说明操作就可以开电子发票了。

如果是个人需要开票，或者公司无法自己开票，可以到税务大厅申请代开票。个人代开需要预缴 20% 的个税，这部分税可以在年底汇算清缴时多退少补。企业代开通常是开专票，开普票的话税局会建议你申请 Ukey 自己开。

滴滴出行见闻

我至今没有考驾照，也没有打算买车。因为很早就算过一笔账，假设每周打4次车，每次50元，5年的花费大约是5万元，远低于买车和养车的成本，更何况我用车的次数远没有这么高。

在比较偏远的地方（比如我老家农村）也是很好打车的，只要打车的时候选最贵的一档（我这边是50-60元），10公里外的车也会调度过来，稍微多等几分钟就行了。

由于滴滴被下架近半年了，出于好奇，我打车的时候会随意问一下司机，最近单量怎么样，滴滴好不好做之类的。得到的答案都是正面的，滴滴单量很稳定，没什么影响，而且开滴滴比较自由，比工厂上班舒服多了。偶尔会有抱怨滴滴抽成太高了，以及导航不准确、绕路的问题。

对于其他的平台，都是没什么订单，赚不到钱。我自己也试过在高德地图上打车，发现很难打到车，而且价格还更贵。

可以说，滴滴构建了非常牢固的护城河，哪怕捆住其手脚，然后所有竞争对手一起上都打不过它。

最后

通过「RSS阅读器」或者关注公众号「自宅创业」可以订阅博客更新，也可以在 关于我 页面找到我的联系方式，欢迎交流！

如题，我开始远程兼职了，从上周开始的，在预料之中，只是来的有点快。

远程兼职

找兼职的过程很顺利，偶然在一个群里看到个招聘消息，是认识多年但没有联系的网友。然后就聊了聊意向、技术栈、以及我后续时间规划，很快就谈好了。约定每周工作30小时，时薪不高但我也比较满意，主要是时间自由。网上签了合同，然后就开始参与项目了。

有一份兼职之后，经济方面就没什么担忧了。现在自己也还有不少空余时间，继续做自己的项目，自宅创业可以长期坚持下去。毕竟创业一次就成功的，十中无一。

订单系统

这两周也在继续写订单系统，还剩一点点，差不多要完成了。接下来会继续把订单系统做完，然后继续做小程序端改版。

最近我加盟的一个水果代理商也换交易系统了，新系统比我预期的好。之前他们用的是 易代理，做的确实不咋地。我查了一下新系统是 极速订货 提供的，价格比有赞贵不少，但确实比有赞更合适，更符合水果分销的模式。

上一期我尝试回答了 “为什么不直接用开源的商城系统？”，现在我想，如果我当初买一套交易系统来用，结果会如何？我觉得，水果业务我会照样做不起来，因为供应链、获客渠道这两个条件我还是不具备，最后折腾一场什么也没留下。

选择自建或者开源+定制交易系统的话，我虽然失败了，但我有了属于自己的交易系统。我可以让业务继续维持而不用额外付出成本，也还有机会把交易系统卖出去，转做 to B 生意。

坚持「做有积累的事情」，这是我学到的经验。

后续更新

考虑到创业时间减少，我打算后续博客 每月更新一次。可以通过 RSS 订阅博客，或是关注我的公众号「自宅创业」。创业路上，与君共勉！

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

这两周主要在写订单系统后台，快要写完了，比我预想的时间更长（包括部分上期完成的任务）。

订单系统

订单系统最核心的是商品和订单。商品分为基础商品（SPU）和商品规格（SKU），一对多的关系。订单分为顾客单和发货单，也是一对多的关系。除此之外，还有品类、供应商和供货商品，关系多就麻烦。

在后端逻辑和数据存储上，要处理关联查询和交易快照，代码有点复杂，花了不少时间。在前端界面上，表单字段很多，不同表单之间还有关联字段，花了较多时间处理。

之后我想明白了，对目前的业务来说，品类、商品、供应商都不多，前端一次性全查出来就好了，需要用的地方直接下拉选择。很多父子孙组件之间，属性和事件传递绕来绕去，不如干脆放到Vuex全局管理，更省心。

此外，我还仔细研究了拼多多商家后台，还有拼多多商家版App，确实做的不错。

为什么不直接用开源的商城系统？

比如 macrozheng/mall, saleor 和 django-oscar，直接用不好吗？或者二次开发？

说实话，我当时也调研了几个 Python 的开源商城框架，但没有很仔细。开源的和我想要的差别有点大，而且定制也有点复杂，再加上程序员本能吧，就直接自己做了一个。

最近和一些朋友聊的时候也被问到这个问题，所以我又更仔细的调研了一下。

开源电商有这么几个问题：

1. 前台系统主要是Web网站，支持小程序，APP的基本没有。
2. 后台管理系统功能不全，用起来也不方便，比如都没有批量发货，运费模板。
3. 基本没有适配中国境内的支付渠道，以及快递物流。

需要定制的内容很多，但应该还是比完全自建更容易。如果只是想卖货，不如用现成的电商服务，比如微信小店、Shopify、有赞商城。如果想做交易平台，再考虑是开源+定制还是自建，如果重来一次，我会先试试开源+定制。

后续计划

继续把订单系统做完，小程序迭代做完。也大致有了下一个产品的想法，但不着急去做。

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

从开始创业到现在，时间飞快的过了半年，业务还是没有做起来。折腾了很多东西，积累下来的，一是经验教训，二是产品代码。

产品迭代

第一次迭代：水果小程序支付下单功能，以及简陋的后台管理功能。持续1个月时间，完成上线。这一版功能基本可用，但还很不完善。

第二次迭代：重新设计业务模式，改进小程序，以及相对完善的后台系统。持续2个月时间，目前大概完成50%。

这一次持续时间很长，但还是严重延期了。一方面是开发效率不高，实际专注写代码的时间不够。另外也低估了电商系统的复杂度，按人天估算应该要30-40MD，也就是一个人实打实的写一个多月代码。

我的感觉是，产品迭代是不断积累价值的过程，只要方向没有错，产品就会越来越有用。良好的代码组织、组件库、框架可以显著提高开发效率。除了闷头生产业务代码，也要适时改进生产线，这样产品迭代会越来越轻松。

水果业务

由于水果业务很难做起来，我也在考虑是不是值得继续投入。

我的判断是，水果行业用户群体广泛，盈利模式清晰，做起来之后能形成明显的壁垒，钱途可观。但是，需要资源积累才能做起来，主要包括：供应链、获客渠道、信息系统。

目前资源并不具备，短期内也不太可能具备，我的计划是：

1. 先做好这一版小程序，以及后台管理系统，这是我的信息系统。
2. 搭建果蔬时节网站，做图文内容和SEO，业余时间慢慢运营，这是获客渠道。
3. 然后集中精力做新项目，水果业务进入放养状态。

反思自省

做有积累的事情

例如写代码、写文章、看书、认识各种各样的人，要么积累资源/资产，要么提高自己的知识和经验。反之如订单发货、发广告、营销带货、闲聊灌水、关注新闻八卦，做一遍和做一百遍没什么差别，几乎没有积累。

保持专注和高效

长时间做一件事的时候，时间越长越容易懈怠，正所谓一鼓作气，再而衰，三而竭。要沿着目标路线，专注地、坚持执行，越专注越高效。当然了，人不是机器做的，也要劳逸结合，该休息就停下来，不要去想别的事情。

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

最近的工作效率一直不行，产品迭代缓慢，需要反思一下。由于前几天在跑水果市场，这期博客也晚了几天。

我有写日记的习惯，每天睡前用App记录一下主要做的事情，否则过几天就忘记了，不知道时间怎么过的。我看了一下最近两周的日记，大致汇总看时间都去哪了。

真正干活的时间大概占一半，另一半时间在折腾各种事情。接下来要把精力聚焦在主要问题上，越专注越高效。可能会尝试用番茄工作法计时，度量更加准确。

你如果无法度量它，就无法管理它。 — 彼得·德鲁克

量化管理是第一步，如果你不能量化它，你就不能理解它；如果你不能理解它，你就不能控制它；如果你不能控制它，你就不能改进它。 — H·詹姆斯·哈林顿

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

在一个月前，我重新设计了小程序的业务逻辑（水果直销自营模式），并计划一个月完成。但是现在离完成还差很远，这次迭代延期了。

延期的主要原因是业务逻辑想的不够清楚，写代码建模的时候，写不下去了。当没有清晰的思路时，似乎就没了方向感，一直在想一直在改，但总是觉得不对，想不清楚然后就开始摸鱼了……

问题和解决思路

其中一个问题是，一款水果有很多种属性，比如酸甜度、口感、大小、外观，这些属性选项组合之后数量暴增，很多组合没有满足条件的商品。我花了很多时间思考怎么建模，研究怎么把属性标准化，比如酸度、甜度、硬度的量化，发现都解决不了问题。

之后我想到，业务逻辑的本质是满足顾客需求，让顾客选择合适的商品，也许可以做成决策流程图。

假设有三款商品，各有优势和劣势，顾客需要看商品详情、查看评价来判断哪款更合适。因为顾客对商品不了解，所以这个决策过程很难，商品越多，选择困难症越严重。

而我是比顾客更了解商品的人，我可以准备几个需求问题，帮助顾客决策，顾客回答需求问题就简单多了。思路参考 如何选择开源许可证？

正好现在是猕猴桃成熟季节，我也找到了好几个产地货源，总共买了5箱猕猴桃，当饭吃…… 根据亲身体会，做成【2021猕猴桃选购指南】：

对比一下京东自营，非常多规格，不知道怎么选。（淘宝、拼多多也是类似的）

你是否也有选择困难症呢？有没有3分钟内就下单付款的经历？欢迎留言。

个人经历：印象中京东有个常购清单功能，里面是经常买的商品，下单很方便。买新东西会很纠结，明知时间宝贵，但还是要挑很久，怕买到不合适的。

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

这段时间工作效率偏低，摸鱼时间都多于写代码时间了。这就是一鼓作气、再而衰、三而竭？ 本期主要做了：水果味道口感建模、界面设计、阅读《供应链管理》。

下面给大家分享用户调研的一个经验。

The Mom Test

《The Mom Test》是做用户调研非常实用的一本书，副标题：How to talk to customers & learn if your business is a good idea when everyone is lying to you.

之所以命名为 The Mom Test，是因为作者假设你今天向你的妈妈介绍创业想法，你妈妈会担心你难过，虽然听的云里雾里，但没有说出内心真实的想法。你的朋友也会考虑你的颜面或为了鼓励你，敷衍赞同你的主意。若你能把你妈妈内心深处的想法问出来，你才能通过 The Mom Test，从而判断正确的创业方向。（中国父母普遍厌恶风险，可能是全盘否决你的创业想法）

我在不同的时间、以不同的方式多次听到这个词，感受也愈发深刻。最早是在网上看了相关的文章，今年年初 Toby 推荐我听了本书作者 Rob Fitzpatrick 访谈播客 #154 – The Right Way to Talk to People About Your Business with Rob Fitzpatrick, Author of The Mom Test，最近在做产品过程中则不断实践和应用。

听完 Rob Fitzpatrick 访谈播客后（全英文，配合文字稿听的），我当时的总结如下：

1. 尽早开始寻找目标用户，先了解对方，然后再抛出产品方案。
2. 通过聊生活，聊过往经历等事实，筛选目标用户。
3. 独立开发者尽量不要做需要太多市场推广的产品，最好是用户自己找上门。

这期播客主要在讲做用户访谈，简言之怎么问潜在用户才能了解到真实需求和想法，从而判断生意有没有钱途。

等你听完这期播客，欢迎留言说说你的想法！

我的实践经验

问事实和经历

当我想挖掘网上买水果的需求时，我是这么问的（原文）：

你最近一次买水果是什么时候，感觉怎么样？你在网上买水果踩过坑吗？说说你踩过的坑，或是你觉得体验很好的地方？

如果我直接问大家买水果有什么需求、痛点，很多重要的事实就会被忽略，听到的可能还是伪需求。挖掘需求是我们自己的工作，潜在用户只是提供线索。

让用户掏钱体验

产品还没做好，一样可以让用户参与体验，关键是：用户愿不愿意掏钱？

在我做小程序在线下单之前，就先用朋友圈和微信转账卖水果。如果有人掏钱了，对收到的水果也比较满意，那就可以继续做，否则在线下单就该放弃了。

观察用户行为

用户行为就是最好的事实，用户需要什么、喜欢什么、不喜欢什么都能通过行为反映出来。

比如小程序里的水果考试助力功能，我发现大家考试失败了都不喜欢分享助力，就算分享也是分享给自己的小号。用户行为不会直接告诉我要怎么做，但告诉了我真实的想法。

让长辈使用产品

让不熟悉互联网的长辈来使用你的产品（真 · Mom Test），可以检验产品是不是足够简单易用，对受众广泛的产品很有效。

前几天我设计了一个水果味道选择器，如下图：

初步实现了一下交互效果，让我妈使用，我在旁边观察。然后我发现我妈不知道怎么点，我就明白了，这个设计太复杂。长辈们日常使用的App，基本都没有滑块操作，短视频没有进度条，听音乐也不用进度条。

然后我重新设计，改成了方块按钮，这才足够简单易用。对互联网产品非常熟悉的人，往往高估了产品的简单易用性。

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

本期概要

小程序下单支付上线之后，水果供应方面发现一些问题。由于水果的成熟期很短，采用评测方式选品太慢，等评测出来这款水果就差不多卖完了。再加上产地下雨等原因，单一的源头供应商无法长期稳定供货。

经过一番思考，我想出了「直销自营模式」，也分别和供应商、顾客朋友讨论，听取大家的想法和建议。这个模式会有一些风险，但还是值得去实践验证。

直销自营模式

业务流程

1. 顾客在小程序选择需要的水果，以及大小、重量、表皮外观、软硬口感、酸甜味道等，系统自动估算成本和售价，顾客付款下单。
2. 平台匹配满足需求的供应商和商品，通知供应商发货，货款由平台和供应商结算，差价则为平台利润。
3. 顾客收到货，快递签收5天内，如果有售后问题，都可以获得赔偿。
   • 对于坏果、烂果、蛀虫、缺斤少两等有客观标准的问题，拍照/拍视频作为证据。按个数或者重量赔偿，损坏超过一半则补发一箱。
   • 对于酸甜味道口感等偏主观的问题，可以提出与下单要求中的哪一些不符。由顾客决定赔付比例，超过50%则补发一箱。
4. 赔偿由平台直接先赔付给顾客，然后平台再和供应商结算。
   • 对于坏果、烂果等客观问题，平台会及时将证据提交给供应商，由供应商承担责任。
   • 对于味道口感等偏主观的问题，由平台承担责任。

优势

1. 对顾客来说，直接选水果需求，比看商品详情、看评价更简单省事。只要平台能保证满足需求，让我买到满意的水果，价格合适就可以下单。
2. 签收5天内都可以售后，比一般电商平台48小时内售后更友好。味道口感等问题也可以赔付，一般电商平台都不支持，味道口感又很重要，这种服务很友好。
3. 从顾客的需求出发，平台就可以找不同的供应商供货，只要保证满足顾客需求即可，供应链可以更灵活、供货会更稳定。

劣势

提供5天的售后时长，平台就要承担更多的风险。对味道口感等偏主观问题做担保，会显著增加被薅羊毛的风险。

后续的计划

之前我对一些功能点想不清楚，例如：水果品类和水果商品的关系，对比评测的内容，如何展示大量的商品。换成新模式之后，这些都不需要了。快速迭代试错，让我可以少走很多的弯路。

接下来我计划用一个月时间，按「直销自营模式」设计和实现程序，争取早点上线！

最后

从顾客的角度，你觉得这种模式怎么样呢？购买时可能还会有哪些顾虑？

你可以在 关于我 页面找到我的联系方式，欢迎交流！

本期概要

这一期继续做下单支付功能，在7月最后一天上线了，然后忙了两天补充商品信息，完善后台管理功能。由于时间不够，商品评测功能没有做好，放到下一期了。

找Bug送水果

支付下单功能做好后，我在用户群做了个找Bug送水果活动，邀请用户测试整个下单流程。活动效果还不错，大家对功能和交互提了一些建议，但有点意外的是竟然没有发现Bug :D

还有个意外惊喜是，活动结束后，我在凌晨 00:02 提交小程序审核，00:18 就审核通过了，微信小程序审核太给力了！因为担心下单支付不方便测试，所以我录了30秒的演示视频一起提交给审核，可能这个视频也很有帮助。

后续的计划

小程序完善

小程序还有不少功能需要补充完善，包括水果评测、发货/配送通知。界面交互设计也需要改进一下，再结合运营情况，逐步迭代完善。

供应链管理

最近在看一本书《采购与供应链管理：一个实践者的角度》，感觉非常实用，我打算边学边做，现学现用。无论做什么生意，稳定高效的供应链都至关重要，供应链管理值得学习一下。这本书作者的博客还提供RSS源，非常不错。

水果供应链，按我现在的模式，可以做到京东自营的品质，并且价格还能更低一点。

因为水果人人皆可种植，供应渠道很多，在同一地区，用同样的方法，种同样的品种，结出的果子基本一样。再加上水果不耐储存的特点，普遍采用产地一件代发的模式，供货成本也是一样的。我自身的成本显然比大公司低很多，只要把差价定少一点，价格就有优势。

拉新和裂变

前一段时间主要在完善程序，用户数量基本没有增长。接下来要拉一些新用户体验产品，有反馈才能持续迭代改进。最近也和一些做产品运营的朋友交流，初步判断裂变是用户增长的核心，做好裂变可以把推广引流效果放大10倍以上。

在微信上做社交裂变有明显的优势，也有很多案例可以模仿，但是要注意微信的规则，避开「诱导分享」的地雷，但我预感还有很多坑等着我去踩。

最后

如果你想体验一下这个小程序，可以微信搜索「果蔬时节」，找到Bug送水果哦！ 目前小程序点购买会提示先添加客服微信再下单，可以放心添加，添加后会自动发送新客优惠给你，领取后就可以下单了。

商品都是明码实价，添加微信是为了方便售前售后沟通，接收顾客的反馈，提供更好的服务。如果你有什么想法、反馈和建议，一定要告诉我啊！

你可以在 关于我 页面找到我的联系方式，欢迎交流！

本期概要

这一期主要在做小程序支付下单功能，对接微信支付，写前端界面，后端接口，后台管理界面。

界面设计工作在上一期基本做好了，这些功能模块中，订单和支付是最复杂的，硬骨头先啃掉了。

订单和支付

由于之前做蚁阅时，对接过一个第三方支付系统，所以对订单状态机，主要流程和接口都比较熟悉了。这次对接的是微信支付，主要是接口内容和认证方式有些区别。

订单系统复杂的根源在于要和支付系统进行网络交互，同步支付状态。要保证在各种网络情况下都不出错，订单接口都需要做幂等设计，也就是同样的参数重复调用接口，效果和只调用一次一样。

在创建订单之前，一定要先生成订单号，不可以用数据库自增ID。大型系统的订单号可以参考大厂的开源方案，小系统用日期时间加随机数即可，可以将用户ID末几位放到订单号中，在遥远的将来做数据分片用。

我的方案是：日期 + 小时 + 用户ID末3位 + 随机数5位，生成之后再到数据库中检查一下是否存在，已存在就重新生成。

前端请求到订单号之后，就可以发起创建订单请求，如果请求失败可以用同样的订单号重试，后端也不会创建重复的订单，因为可以根据订单号识别重复请求，实现接口幂等性。

订单创建之后，请求支付系统获取支付信息，请求中同样携带订单号，支付系统会根据订单号识别重复请求，这样支付系统也不会创建重复订单。

支付信息会返回到前端，用于拉起支付App或者显示付款二维码。用户付款之后，再调用查单接口获取支付状态，支付完成。支付系统同时也会主动请求你的后端接口，通知支付状态，保证支付状态及时同步。

订单取消、退款等逆向操作，需要考虑优惠券退还和库存变更。

感兴趣的朋友可以学习极客时间《后端存储实战课 - 李玥》这个课程，很深入很实用。

其他商品和订单功能

如果按常规电商的做法，商品详情订单管理之类都很好做，不需要太多思考。但我倾向于做点差异化，把功能做的更简单实用，所以很多产品交互就需要思考，有时候想不清楚就很头大，也会花费不少时间。

争取下一期把剩余的功能模块全部搞定，上线内测。

最后

你可以在 关于我 页面找到我的联系方式，欢迎交流！

本期概要

1. 税务和五险一金
2. 水果评测活动
3. 创业三个月回顾

税务和五险一金

税务方面，使用了自记账一周多，感觉他们服务太不积极了，税务密码验证问题一直都没解决。然后我找了一下阿里云上的记账报税服务，发现一年只要360元，服务也比较积极，所以我改用 阿里云智能财税 记账报税了。拍照记账用起来都差不多，用脚投票莫怪我～

五险一金方面，跑腿花了两个半天时间，比较折腾。

第一天在社保中心办了五险中的工伤和失业险，开通了网上操作功能，但是给我的登录账号写错了，第二天又跑了一趟。

五险中的养老、医疗、生育划分到了医保范围，在医保中心办理，但要等这个月10号之后才能办理，材料可以先准备好。

公积金由于我已经在「我的社保」交了7月份的，要等8月份再办理公积金。材料都已备齐，等8月份再跑一趟交材料。

总的来说，新注册公司第一次办理这些，都要求到现场办理，网上办不了，很多材料都要打印盖章。跑腿之前，先打电话询问了解清楚，可以节省很多时间。

水果评测活动

上期结束时提到，小程序上线了一个新功能。这个功能叫做「水果考试」，每种水果一张试卷，题目是关于这种水果的购买、吃法、储存等等知识，考试通过的用户购买相应水果可以享受优惠。

有句话叫「把产品卖给需要它的人」，这朴实无华的话，却是做生意的内功心法。真正需要你的产品的人，很乐意花钱购买，而不需要的人，真的是白送都不要。水果考试的一个作用，就是筛选真正需要买水果的人，另一个作用是普及知识，减少水果损坏和售后。

有一次，在蚁阅微信群里，大家主动聊起了我的新项目，一时兴起我决定送出5箱水果，通过抢红包形式，手气最佳的获奖。结果我发现，有人领到的水果是自己不喜欢吃的，还有人领了水果就失联了，问他好不好吃都不回复（目测是个小号）。

这一期我开始在水果群做水果评测活动，就要求相应的水果考试通过才能获奖，把水果送给真正需要的人。目前是每周五做活动送水果，第一次由于规则设计太复杂，效果不是很好（中间有些规则争论），但收到水果的伙伴都写了评测。第二次活动规则简化了，效果好很多，抽奖时也有一个没有做水果考试就想糊弄过去的，没让他得逞。

对水果感兴趣的朋友，也欢迎来体验水果评测活动！

创业三个月回顾

从离职创业到现在，正好三个月了，每期写博客都觉得，怎么又过了两周了！

这三个月来，我调整了几次方向，快速试错。虽然没赚到钱，但确实学到很多，体会到很多，有点累但乐在其中。

最初的设想

最初的设想是做查询当季水果的小程序，依靠广告和推广外卖优惠券盈利。不打算卖水果，因为卖水果业务太重了。目标是到618电商节，推广电商红包赚几千块钱。

实践之后，发现查询当季水果这个需求太弱了，很难汇集到目标用户，这条路走不通。

淘宝客/多多客

第一次调整，是把小程序改成水果带货模式，从电商平台筛选货源，通过做淘宝客/多多客拿佣金。这样有买水果需求的用户，可以从小程序跳转到电商平台下单，我获得一点佣金。

实践之后，发现找稳定可靠的水果商家太难了，货源质量时好时坏，自己完全不可控。

水果微商

第二次调整，是自己找货源，做自营水果。我开始尝试水果微商的模式，从成本/价值方面考虑，发现有一定的竞争优势。核心在于低成本获客，筛选可靠货源积累口碑，复购率高、转化率高。虽然很多水果品类不适合快递运输，但也有很多适合快递运输的。

目前正在朝这个方向努力，先逐渐积累可靠货源，把小程序做好，提高获客转化率、复购率。小程序还差下单购买功能，已经在开始做了，争取一个月内搞定！

最后

合抱之木，生于毫末；九层之台，起于累土；千里之行，始于足下。

与君共勉！

公司注册流程和经验

这一期把公司注册流程基本走完了，营业执照和对公账户都有了。税务完成一部分，社保公积金还没开始办，剩下的可以慢慢做。

1. 注册公司，拿营业执照

注册公司的流程很多，我是在支付宝上找的「跑政通」代办，收费 10元 + 500元。

公司类型我选的 个人独资企业，最适合独立开发者，可以参考 独立开发者公司资质与税务工作 这篇文章。

公司名称尽量不要和别人相似，想到的名字可以到 公司核名查询 - 阿里云 先查询看看。

公司经营范围，可以先到 微信小程序服务类目文档 搜索「经营范围」，有些服务类目对公司经营范围有要求。

公司注册地址 用的是家庭住宅地址，需要提供房产证和户口本信息。不用钱，比租办公室划算多了。

政府今年在推企业注册「一网通办」，理论上可以全程网上办理，只需要亲自跑一趟拿营业执照。但因为工商系统有问题，我在网上没走通，只完成了公司核名。最后是代办让我整理好材料，亲自跑一趟工商局交材料，当场拿到了营业执照。

拿到营业执照之后，要去刻章店刻章，至少要 公章和法人章 这两个，可以再加个财务章。印章在开对公账户和办税务时要用。我选的最便宜的套餐，200元三个章，大约半小时刻好。

此外，可以看这篇 自己办理注册公司的流程，供参考。

2. 到银行开对公账户

开户之前要先 打电话给银行预约 ，银行会亲自上门调查，确认你是合理合法经营，然后才会办理开户。

需要先 准备好招牌，写上公司名称挂在门口，才能作为经营场地。房间工位整理一下，银行上门的经理会问具体业务。我是在拼多多商家「智尚标识」买的招牌，20元一个小招牌（20x40cm)。

开对公账户要法人亲自到营业厅办理，需要填材料、录音录像，我是上午填好材料，下午拿到了对公账户。支付密码器可以不办，办理「凭印鉴」查账转账就可以（注意印章千万别弄丢了）。

不同银行的收费不一样，国有大银行收费较高，一年要几百到上千（年费、网银、密码器，短信费等）。我选的 当地商业银行，不收费。但是网银暂时开不了，要等有10笔左右正常业务流水后，再去营业厅开通网银。

没有网银不影响收款，只是转账查账需要带印章去银行办理。

3. 微信平台认证（可选）

对公账户开好之后，就可以在微信平台认证，开通微信支付了。

微信认证最省钱的方法是先注册一个服务号，然后服务号做微信认证，交300元。服务号名称用公司简称通过率更高，审核也很快，一天就通过了。

服务号认证之后，就可以 复用公众号资质注册小程序，不用再交钱审核。

同样的，企业微信也可以从服务号的管理界面开通，直接复用微信认证。

微信支付也可以从服务号管理界面进入开通，填写资料，一个工作日审核通过。

4. 办理税务和社保公积金

处理税务我用的是 自记账，新注册的公司需要 办理税务登记，我按照 税务登记教程 先在电子税务局网站上办理，走不通，最后是亲自到税务大厅办理的。

然后每月/每季度报税的事情，主要由自记账的客服帮忙处理，正在折腾中。

社保公积金，我离职之后是在「我的社保」App 交的，每月要付 129 元服务费。接下来我准备用公司给自己交社保公积金，这笔服务费就能省掉了。

更新：记账报税改用「阿里云智能财税」了，详见下一期。

注册公司总结

最后

这一期小程序新功能开发也完成了，即将上线，欢迎来体验！

本期概要

1. 自动化生成原创内容，初步告一段落。
2. 开始注册公司了，卖货和收款都需要营业执照。
3. 准备小程序新功能，交互和界面设计完成。

自动化生成原创内容

在上一期里，我尝试了很多 NLP 方法，但没有取得什么成果。

这一期我继续投入了几天时间，手工整理一种水果的语料素材，然后参照 狗屁不通文章生成器 的思路，按一定规则生成 300-500 字的文章。生成的内容可读性还不错，没有机器翻译的味道，不仔细看发现不了这是程序生成的。

只要语料素材丰富、质量好，规则做的丰富一些，就能生成大量原创文章。 预估了一下，全部实现自动化还需要很多时间，所以这个就暂告一段落了。

开始注册公司

我的小程序目前是引导用户添加个人微信，通过个人微信完成下单和付款。但是用户量本来就少，添加微信的就几乎没有了，通过聊天沟通手动录单，也比较繁琐。

在研究小程序自助下单流程的时候，发现没有卖货和收款的资质就很难走下去。微信对个人主体小程序开放的服务类目非常有限，既不能卖货，也不能收款。如果没有企业身份，小程序卖货功能就无法过审上线，收款的话还是要引导用户加微信转账，或者截屏再扫描个人微信收款码。

然后我咨询了一位做独立开发的前辈 Shidenggui，发现公司一年成本只要一千块左右。

不同地区的价格会有差异，用住宅地址作为公司注册地址需要有房产证，可能还需要其他证明。

公司类型可以考虑个人独资企业，最适合独立开发者，可以参考 PixelMage - 独立开发者公司资质与税务工作 这篇文章。

公司经营范围，可以先到 微信小程序服务类目文档 搜索「经营范围」，有些服务类目对公司经营范围有要求，例如卖水果就要求「经营范围需含“初级食用农产品”相关（如：蔬菜、水果等）」。其他经营范围可以参考同类公司的写法。

我目前正在走公司注册审批流程，预计下一期可以分享完整的公司注册经验。

小程序新功能设计

我准备给小程序增加两个功能，一个是下单购买，另一个叫吃货考试。

下单购买不必多说，主要是商品详情、优惠券和下单流程，可以算是简化版的电商App。

吃货考试的逻辑是这样的：每种水果都对应一组题目，题目是关于水果的知识、水果的吃法，用户全部答对之后，买相应的水果每单均可享受 1 元无门槛优惠。

吃货考试的目的是帮助用户了解这种水果，避免知识误区和误解，导致不好购买体验。我查看了各大电商平台上水果类的中差评，有些是商品介绍不清楚导致不符合预期，有些是后熟的水果提前切开了，还有些是不知道联系售后赔付，直接给了差评。

水果是典型的非标商品和易损耗商品，同一棵树上的果子都会有很多差异，十分完好的果子也仍然有小概率会在路上损坏变质。所以售前售后和用户的沟通非常关键，我希望通过吃货考试的形式，产生更好的购物体验，同时又能节省成本，给用户多一点价格优惠。

目前交互和界面设计刚刚完成，后续就是代码实现和上线了。

最后

你可以在 关于我 页面找到我的联系方式，欢迎沟通交流！

本期概要

1. 这两周花了大量时间研究自动化生成原创内容，但没有什么成果。
2. 开拓了新的推广引流渠道，知乎推广留微信号导致违规，推广引流进展缓慢。
3. 水果生意慢慢起步，总共卖出 5 个订单，还是很艰难。

自动化生成原创内容

为了自动化地做推广引流，需要创作大量原创文章内容。这两周大概有一半时间在研究这个问题，但没取得什么成果。

自动生成文章，我想到的有这些方案：

在线翻译洗稿:

先将采集的文章翻译成其他语言，再翻译回来。因为机器翻译已经比较成熟了，所以翻译准确率还不错，但还是会有不少很别扭的句子。原本80分的文章，洗稿之后能打到60-70分。

根据标题直接生成文章:

大致是输入一句话，利用NLP模型自动补全下一句，再用生成的句子作为输入，迭代生成文章。我尝试了一下，生成的文章基本没法读，可能语料太少，以及模型没优化好。

用NLP算法仿写文章:

大致是将模板文章拆分成句子，对每一个句子从语料库中找一个最相似的替代，文章就仿写出来了。 尝试了一下，结果也很差，可能是语料库太小了，再加上算法只能识别字符和词语相似，无法理解句子结构和含义，找出的相似句子差距太大。

根据规则生成文章:

果蔬类的文章内容主要是描写和说明，需要先对每种水果整理出一批结构化的语料，例如每种水果的外观、味道、口感、形容词、属性说明等等，然后根据规则组合成文章，大体思路类似于狗屁不通文章生成器。难点在于整理结构化语料，手工整理很耗时间，尝试用 NLP 算法分析采集的文章提取语料，还没找到很好的方法，自然语言的表达实在是太丰富了。

同义词和句子结构替换:

先采集文章，然后分句分词，借助同义词库做随机替换，再加上一定的规则对常用句式做改写。这个处理可以叠加在其他方案上，单独使用生成的文章原创度可能不够。另外，网络采集的文章通常会有错字和语法错误，可以用句子纠错算法做纠正，这类算法也相对比较成熟了。

总结:

最简单粗暴的方案就是翻译洗稿 + 同义词替换，这也是主流 SEOer 伪原创工具的做法。我比较倾向于根据规则生成文章这个方案，文章内容可控，质量比较好，而且是真原创文章。我准备再用一些时间，哪怕是手工整理语料，也要做出点效果来。

NLP相关库:

• 结巴分词: https://github.com/fxsjy/jieba
• 生产级NLP工具包: https://github.com/hankcs/HanLP
• NLP工具包: https://github.com/ownthink/Jiagu
• 新华字典数据: https://github.com/pwxcoo/chinese-xinhua
• 中文近义词: https://github.com/chatopera/Synonyms
• 中文文本纠错: https://github.com/shibing624/pycorrector
• 文本相似度: https://github.com/seomoz/simhash-py
• NLP学习资料: https://github.com/fighting41love/funNLP

推广引流进展缓慢

因为没有什么时间发帖和写内容推广，内容曝光量不高，目前每天不到10个新用户访问小程序。

在知乎上因为签名留微信号太明显了，被禁言一天，然后一个月内不能写签名，也就不好引流了。 做推广一定要好好学习平台规则：知乎用户信息管理规范

这两周也开拓了其他几个推广引流渠道，基本上有人气的App我都注册账号了，积少成多慢慢来。

水果生意

我卖水果的定位是 “好吃不贵”，目前找到一家供应商的水果品质很不错，价格适中。根据我自己多次购买试吃，和其他渠道的水果对比，这家的品控做的明显比其他人更好。

这两周通过朋友圈和微信群宣传，总共卖出了 5 个订单，反馈也都很好。

卖水果很艰难，我想到的原因可能是：

1. 用户基数太小，有购买需求的人少。
2. 卖的品类较少，顾客偏爱自己喜欢的几种水果，对尝鲜比较谨慎。
3. 品牌和信任感还没有建立起来，新客下单会有疑虑。
4. 朋友圈和微信群宣传内容比较碎片化，不够清晰和完整。

接下来我准备更新一下小程序，用小程序来展示水果购买信息，简化购买流程。

我也向你提个问题，你最近一次买水果是什么时候，感觉怎么样？你在网上买水果踩过坑吗？说说你踩过的坑，或是你觉得体验很好的地方？欢迎 加我微信 交流，另有水果赠送！

最后

借用一位水果大哥的话：

当我们还没有足够的实力，没有足够的名气的时候，我们就要像这棵荔枝一样，默默生长，默默成长，终有一天，你一定会红的，莫愁前路无知己，天下谁人不识君，你的伯乐，早晚会出现。

你可以在 关于我 页面找到我的联系方式，欢迎沟通交流！

这两周主要在推广小程序，了解水果行业，越做发现水越深。

推广小程序

我主要是在贴吧和知乎推广小程序，现在每天有十几个新用户访问，有了一点效果。 也新开了豆瓣、小红书、抖音、头条之类的账号，还在养号当中。

贴吧上主要有两类目标贴吧，一是水果贴吧，二是美食贴吧。

水果贴吧的主要用户是果农，每天都有大量的果农和水果行业的人在里面打广告，也很容易加到微信，和他们聊天增加了我对水果行业的认识。也见识了推广营销正规军的威力，例如橙心优选同样的帖子内容一直保持在首页，用批量小号顶帖，几天时间就把果农全部拉进群。

美食贴吧内容比较泛，什么吃的内容都有，帖子非常多，新帖很快就沉了。后续要买些小号，用程序自动化操作才有比较好的效果。

知乎推广主要是答题、发视频、举报回答。答题就像是在鱼塘里钓鱼，要让鱼饵充满诱惑力，吸引目标用户，但写优质回答非常耗时间。发视频能快速增加创作分数，用于账号升级。举报回答可以增加盐值，增加账号权重。

后续计划

推广引流离不开大量优质内容，但是手工创作内容非常耗时耗力。后续我准备把知乎专栏等自媒体用起来，通过程序自动化生成原创内容，自动发布到各大平台。积水成渊，量变产生质变。

微信搜一搜

小程序名称优化

最开始我的小程序名称是「品牌词 + 核心关键词」，期望用户搜索核心关键词时能展示到我的小程序。但是很显然，微信搜一搜并不会给新出现的小程序推荐流量，核心关键词不起作用。

目前流量主要来自站外引流，引导用户搜索品牌词找到小程序。微信搜一搜会考虑（1）小程序标题是否覆盖了搜索词，（2）搜索词在标题中的占比，越大表示相关度越高。因为核心关键词增加了标题长度，反而使得搜索相关度下降，所以我要把核心关键词去掉。改名之后，在小程序类目就能稳定排在第一位了。

公众号和视频号

之前我也开通了公众号和视频号，试图通过公众号和视频号给小程序导流。然而事与愿违，微信不会给新开的公众号和视频号推荐流量，还会分走品牌词的搜索流量。用户搜索品牌词时，结果第一条是视频号，可见微信对视频号的重视程度是高于小程序的。

为了聚焦流量，避免损耗，我把公众号和视频号都清空了，之后几天小程序就稳定排在了搜索结果第一位。

好景不长，小程序又从首页消失了

一天早上醒来，发现搜索品牌词竟然没有展示我的小程序，展示的反而是几个文档小程序，例如：览心文档、新浪爱问。原来这些文档和问答小程序，为了搜刮流量，会大量铺设内容，霸占长尾关键词，这些内容也包含我的部分品牌词。而他们的权重又比较高，就把我的小程序挤走了。

后续计划

后续我准备把站外流量都引导到个人微信号，一个微信能加 5 千好友，足够产品启动了。微信号还具备双向沟通能力，能主动联系用户，转化率远高于其他形式。微信号才是真·私域流量。

水果生意模式

这两周认识了非常多做水果生意的人，让我对水果行业有了全新的认识。

在水果种植、采收、仓储、发货运输、推广销售、售后整个链路中，大致可以分成三个角色。

果农

果农主要负责水果种植，兼做采收工作。他们不具备推广销售能力，也没有很好的售后服务意识，对互联网了解很浅。他们最大的难题是把水果销售出去，绝大部分会选择依靠水果采购商，这样至少能赚钱，水果不会烂在地里。

我们在抖音，视频号，拼多多，淘宝，闲鱼等等平台上看见的自称果农卖水果的，要么是水果供应商，要么是水果代理，顶多是找了果农拍的小视频，不可能是真正的果农。

供应商

水果供应商负责水果收购、仓储、发货、品控，通常提供一件代发和售后包赔。较大的供应商会建立销售联盟，招收代理销售，也有的会开网店、超市等多元化销售。

水果快递运输是非常大的成本，靠快递公司的量大优惠远远不够，这里面的奥秘就在于政府的惠农政策。当地政府会和供应商、快递物流公司达成合作，让物流公司只收很低的运费，政府可以给他们低价提供场地、仓库，降低税收等，同时还可以直接补贴。当前 5 斤水果发货运费可以低到 3-4 元，这也才使得网上卖水果可行。

代理

常见的是水果微商、视频带货、自媒体带货，他们通过加盟水果供应商获取货源，销售水果赚差价，利润大约有 5% 至 20%。水果代理的价值在于提供一对一服务，让客户能买到好吃又实惠的水果。水果代理的口碑至关重要，好的口碑才能带来源源不断的订单。

拼多多，生鲜电商，社区团购等等可以算是水果代理，只不过他们规模大得多。他们不是供应商，因为他们做不到去每个水果产地采购、发货。

拼多多的水果靠谱吗

少部分靠谱，但你会觉得有点小贵。

拼多多给人的印象是便宜，因为价格竞争太激烈了。很多果农（供应商）和我说，拼多多上卖水果就是赔本赚吆喝，高价卖不出去，低价卖亏本，除非有别的办法赚到钱。

正当的方法主要是品质分级，价格差异化，例如大部分品相很一般的水果就低价促销，吸引大量用户购买，这些用户当中有些愿意高价买品质更好的水果，例如特级、精品、超大果，靠这部分利润赚钱。

不正当的方法我了解不多，主要是以次充好，当水果收购价上涨时就发一些差一点的果子，或是发成熟度低一点的果子减少运输损坏，降低成本。

最后

你可以在 关于我 页面找到我的联系方式，欢迎沟通交流！

回家自宅创业两周了，乡村自然环境真的很舒服。

村里现在很少人种地了，也没有人砍柴，在屋顶上一眼望去，四面都是绿油油的山，绿油油的树，比往年更加茂密。田间地头长满了杂草，有些种了果树也没人打理。随春风飘过的，是泥土的气息，青草的芬芳，令人全身舒适。

各种鸟雀也变多了，田间能看见野鸡、白鹤，树林里有布谷鸟、斑鸠、麻雀，还有许多叫不上名字的鸟儿。它们叽叽喳喳的叫声，此起彼伏，和山风混合在一起，胜过了任何白噪声应用。

生活环境的切换，就像是现实版的《星露谷物语》，唯一的区别是我在电脑前写代码，而游戏里主角在耕种爷爷的农场。

新产品

最近做的是一个和水果相关的微信小程序，已经上线并做了一轮更新。

小程序功能不算复杂，用的是 uni-app 框架，使用下来感觉不错。小程序本身有不少坑，uni-app 文档写的比较清晰，遇到的问题都有解决方法。

后端用的是 Python，通过阿里云函数计算部署，免运维。云函数还不是很成熟，配置起来稍微复杂些，但配好之后用起来很省心。

最难的部分是推广，这段时间的推广可以说很失败，我可能一个目标用户都没找到。

小程序推广

小程序推广离不开微信生态，最有希望的流量来源是微信搜一搜，我推广工作的核心也是搜一搜SEO。根据一些大佬的经验，搜一搜的流量很可观，做的好每天自然流量有几百上千。

我做了这些尝试：

1. 微信群推广，加了十几个群，日常发广告。这些群质量都太差，里面全是发广告的，高质量的行业社群太难找了。
2. 在搜狗问问和搜狗指南写内容，审核很严格，没能插广告。本以为搜狗是腾讯旗下的，推广腾讯的内容会更容易。
3. 在百度知道，百度经验写内容，主要在养号，基本没有写广告。这两天试了试百度贴吧推广，审核比较松。
4. 开新公众号，写了两篇文章，阅读量个位数。新公众号已经拿不到任何微信的流量了。
5. 微信小视频推广，发了几个视频内容，观看量显示有几十但没有点赞，不知有没有水分。
6. 微信小程序页面内容接入，特地优化了小程序内容方便收录，提交了一万多个页面，但似乎没什么效果，收录看运气。
7. 知乎推广，这周刚开始做，日常回答问题养一下号，从知乎引流到微信相对容易一些。

以上推广效果是：

1. 很多做推广营销的加我微信，企图在我这打广告。
2. 不少果园主，批发商，微商加我微信，想找地方卖水果。
3. 真正关注小程序功能和内容的，可能一个都没有。

我个人总结是：

1. 微信不会主动给小程序、公众号、视频号流量，一定要先给微信带来流量，向微信证明你的产品有吸引力，微信才会分发流量给你。
2. 需要在微信外获得大量曝光，找到精准流量，才能完成产品冷启动。我得继续在各个平台养号，进行软推广，在推广这件事上付出更多时间和精力。
3. 产品本身需要功能足够有用，对用户有吸引力，可以一边推广一边优化。

最后

你可以在 关于我 页面找到我的联系方式，欢迎沟通交流！

2021-04-06 离职
2021-04-07 收拾东西回老家
2021-04-08 整理房间和工作台
2021-04-09 自宅创业第一天

今天是我自宅创业的第一天，我终于 Follow My Heart，踏上了创业这条路。

“自宅创业” 取自《自宅创业圣经》这本书，即一人独自在家创业。我会用一年时间，独立开发互联网产品和服务，并获得被动收入。

我会不定期在博客分享创业中的思考和经验，尽量透明和公开，希望对大家也有所帮助。在此特别感谢 timqian 和 Toby 两位前辈，以及 独立开发者社区 的朋友们分享经验，让我能摸着前人的脚印过河！

欢迎通过 蚁阅RSS 订阅我的博客和以上链接。

2021年目标

• 做 2～3 款产品并盈利
• 年收入 3 万元人民币
• 锻炼身体，体重增加到 110 斤
• 截止日期 2021 年除夕

我的第一年目标是年收入 3 万元人民币，这个数字远低于上班的工资，因为创业第一年会非常艰难，过高的目标并不现实。我计划用 3 年时间获得和上班工资相当的收入，做最好的准备，最坏的打算。

挑战条件

• 一个全干工程师
• 每周工作约 40 小时
• 启动资金不超过 3 万元
• 生活成本一年不超过 2 万元

我的工作台

设备是年前买好的，花了一天时间整理的工作台，非常满意！

显示器：飞利浦 27英寸 4K 279C9 入手价2999¥
工学椅：网易严选 多功能人体工学转椅 入手价1099¥

如果我失败了

如果我失败了，我会考虑第二年找一份远程兼职，靠兼职补齐年收入目标，再次挑战。

最后

你可以在 关于我 页面找到我的联系方式，欢迎沟通交流！

2020 年很特别，经历了很多事，遇到了很多人，读了很多书，也有很多的收获。

最近三年我保持了每天写日记的习惯，每天睡前写一两句记录一天的生活。 我想，记忆是会模糊的，也许几十年后看这些日记，我还能看见自己的一生是如何度过的。

我也翻阅了 2020 年的日记，蚁阅和独立开发贯穿我的生活，填满了我的业余时间。

工作时间

2020 年工作有些枯燥乏味，上半年在做产品升级和部署环境迁移，下半年主要负责一个子项目的后端开发， Java Sprint Boot 和 Elasticsearch 用的比较多，踩了些坑，积累了一些经验。

在 PayPal 工作的感觉是，公司的基础设施很落后，生产环境和开发环境都很不稳定，各种数据和系统混乱，开发效率低下，这可能是组织架构和历史遗留原因。另一方面，我觉得公司对方向和趋势的判断非常准确，对安全合规非常重视。

PayPal US 从 2021 年初开始支持比特币交易，推广力度也非常大。 从整个金融系统的运行效率和运行成本来看，这个方向非常正确。PayPal 高昂的手续费本质上是被现有金融系统里庞杂的中间商赚走了，支持加密货币将使 PayPal 占据非常有利的位置。

值得一提的是 PYPL 股票价格从年初 90$ 一路涨到现在 270$， 导致我入职时拿的受限股以及绩效奖励的受限股每年兑现之后，是一笔非常可观的收入了。

不过年后我就会离职了，自由职业是我既定的方向。 如果有什么让我一觉醒来就能热血沸腾，那一定是自由职业。

业余时间

饮食

在 2019 年年底，我尝试了 Solyent 和 若饭 。若饭相当于 Solyent 的国内版，是营养代餐食物。在 2020 年由于疫情原因，我一年基本上都是吃若饭。

Solyent 我买了一罐咖啡味的，不是特别习惯吃，再加上海淘价格昂贵，之后我都吃若饭。 若饭有句口号是 “一分钟，九分饱”，我加上冲水和洗杯子时间，大概五分钟吃完一顿饭，一天节省至少一小时。

若饭的味道其实就是没有味道，但我感觉挺好，我吃了半年之后才开始有一点点腻。 考虑到营养均衡，我大约 80% 的食物是若饭，周末偶尔点个比较好的外卖，平时多吃水果。

吃代餐粉一定要用摇摇杯，尽量买矮胖型的方便清洗，推荐 Blender摇摇杯。

开发蚁阅

我的业余大部分时间是在开发蚁阅或者相关的项目，另一部分是在学习独立开发需要的知识。 经过了一年的 迭代更新，年前 蚁阅在 V2EX 正式发售，成为了当天最热帖子。

和蚁阅相关的，还有另外三个项目：

1. TinyOps 轻量级运维自动化工具，可以将我需要手工操作的步骤自动化，例如自动部署代码，定时备份数据库。
2. ProxyAnt 将 V2Ray 和 Caddy 简化封装，既是梯子又是网关。这是我用 golang 写的第一个项目。
3. ShopAnt 蚁阅在用的充值支付系统，以后可能会做成独立的产品。

学习独立开发

这一整年我都在朝着独立开发方向前进，一边观摩学习，一边动手实践（开发蚁阅）。

设计方面

2019 年我通过《30天学会绘画》临摹，有了一些基本的设计感觉。2020 年我买了 Sketch，上手设计产品界面，现学现用。写代码之前先设计好界面布局和交互，能节省很多改代码的时间。

产品方面

我在极客时间上学习了《邱岳的产品手记+实战》课程，收获良多。 也学习了 方糖气球（Server酱） 的课程， 对产品的构思，商业模式，用户增长等等都大致清楚了。

运营方面

主要看了《运营之光》这本书，可能要在实践中多摸索经验。

观摩学习

我加入了独立开发者社区，观摩学习前辈的经验，例如： 食灯鬼, PixelMage, Eric Woo

关注了一些独立开发的前辈，例如： Timqian, Toby, 单枪匹码

关注新出的产品，例如： 新趣集, 知晓程序, V2EX创意

读书和听书

下半年有一段时间，我偶尔有些偏头痛，可能是用眼过度或是用脑过度，我开始注意让自己保持放松， 远离屏幕，毕竟身体才是革命的本钱。

休息时偶尔听听音乐，后来我发现听书也很不错，既可以让眼睛休息，大脑放松，又不会有睡不着的焦虑， 所以我在豆瓣阅读上听了很多文学社科类的书籍。

• 《向死而生：我修的死亡学分》
• 《枪炮、病菌与钢铁》
• 《月亮和六便士》
• 《了不起的盖茨比》
• 《原则》
• 《颠覆者：周鸿祎自传》
• 《周鸿祎：我的互联网方法论》
• 《运营之光》
• 《美国陷阱》
• 《关键对话》
• 《别逗了费曼先生》

在得到App上听的课程：

• 《怎样成为时间管理的高手》
• 《前沿科技-合成生物学》
• 《前沿科技-脑机接口》

在极客时间听的课程：

• 《李玥 - 后端存储实战课》
• 《邱岳的产品手记 + 实战》

读了一些不错的书：

• 《具体数学》
• 《世界上最简单的会计书》
• 《买房那些事》
• 《自宅创业圣经》

游戏

下半年有段时间状态不佳，没心思学习，在 Stream 上买了游戏但没怎么玩。
《饥荒》,《缺氧》,《异星工厂》,《星露谷物语》。

其中《异星工厂》让我对自动化有了深刻的理解，但我肝了几天就肝不动了。

其他

滴答清单 把要做的事都记在清单上，减轻大脑记忆负担。
Beancount 开始复式记账，掌握自己的资产负债情况。

2021年目标

[✔️] 自由职业，独立开发好用的产品。
[✔️] 继续学习，读书，听书，保持高效。
[✔️] 保持身体健康，不能走火入魔。

上周受邀参加了朋友许友昌的一期播客节目，我们聊了业余时间做产品的经历， RSS 的前景和创业问题，一起探讨了独立开发这件事，我也分享了蚁阅开发过程中的一些思考和总结。

蚁阅带给我最大的收获就是认识了各种各样的朋友，也因此加入了独立开发者社区， 遇到了许友昌，也就有了这一期播客。一切都像是不期而遇，又像是冥冥之中。

这是我第一次参加播客节目，欢迎大家随便听听~

订阅节目:

• 喜马拉雅: 调试者说 - 程序员业余开发

直接播放:

拓展链接:

• 蚁阅: https://rss.anyant.com/
• Stringer: https://github.com/swanson/stringer
• UX Coffee 设计咖: 我有一双隐形的翅膀（周楷雯·独立开发者）
• 独立开发者社区: http://indiehackers.net/

蚁阅 是一个 RSS 阅读服务， 全文阅读是其中一个很实用的功能，可以为读者提供流畅和一致的阅读体验。

早期在存储方面没有考虑太多，直接把文章信息和全文存储在 PostgreSQL 里面，随着订阅量越来越多， 这个表也越来越大（每个订阅至多保留 1K 篇文章），不久的将来会达到几千万这个量级。这会带来两个问题：

1. 单表/单数据库的处理能力受限于单块磁盘的 IO 性能，会成为瓶颈。
2. 数据备份和恢复会越来越慢。

要解决 #1，需要对数据做分片，使用多个磁盘。要解决 #2，需要支持增量备份和恢复。

使用云厂商的对象存储方案，可以很好的解决这两个问题。 但是蚁阅有点特殊，首先我不希望绑定到任何云厂商，说不定哪天就被封了，这完全不可控； 其次蚁阅要支持独立部署，哪怕蚁阅服务没了，大家也能自己部署继续用这个产品。

不能使用云厂商的方案，那就找开源替代方案，调研下来大致有这些方案：

1. Ceph
2. MinIO
3. SeaweedFS

Ceph 是重量型方案，对小项目来说太复杂了。
MinIO 比较新，部署相对比较简单，但架构和配置还是挺复杂的。
SeaweedFS 部署简单，架构也简单，基于 Facebook Haystack 设计。

SeaweedFS方案

我首先按 SeaweedFS 设计了一版存储方案。SeaweedFS 相当于 KV 存储，键称为 fid。 例如: 3,01637037d6，开头的 3 表示 Volume ID，中间的 01 是文件的 Key，用于定位文件， 后 8 位是 Cookie，用于防止猜解 URL，这里似乎用不上。Key 和 Cookie 都是 32 位整数，用 16 进制表示。

SeaweedFS 有 Master 节点和 Volume 节点，Master 负责管理 Volume ID 到 Volume 节点的映射关系，Volume 节点负责存储数据。 通常可以由 Master 分配 fid，保证全局唯一和数据平衡。也支持自定义生成规则。

实际上每个 Volume 存储为磁盘上一个文件，SeaweedFS 会在内存里维护 fid 到文件读写位置的映射， 实现每次查询和写入都只需要 1 次 IO 操作，同一个 Volume 的操作是串行的。

蚁阅使用自定义 fid 生成规则，由 feed_id 和 offset 唯一确定一篇文章，不依赖于 Master 节点：

story key: 64 bits
+----------+---------+--------+----------+
|     4    |   28    |   28   |    4     |
+----------+---------+--------+----------+
| reserve1 | feed_id | offset | reserve2 |
+----------+---------+-------------------+

reserve1 和 reserve2 是保留位，目前没有用到。

然后数据按 feed_id 范围分片，比如每 1K 个订阅的文章存储在一个 Volume，每个分片数据大约是 1G， SeaweedFS 每个 Volume 最大支持 32G。 范围分片很容易支持扩容，随着订阅量增长只需添加更多的 Volume 节点，不用数据迁移。

但范围分片可能会有数据不均匀，所以稍微改进一下，每 8 个 Volume 一组， 数据按 feed_id 范围分组，每 8K 个订阅一组，组内再哈希分片。 这样数据分布会比较均匀，扩容时就一次扩容一组 Volume。

性能分析

按这个方案实现之后，做了一些性能分析。

首先在阿里云 200G 高效云盘上，磁盘性能大约为 3000 IOPS。 使用 SeaweedFS 自带的 benchmark 命令，可以测到写入 QPS 接近 3000， 符合每次查询和写入都只需要 1 次 IO 操作，接近磁盘性能极限。

Concurrency Level:      16
Time taken for tests:   384.116 seconds
Complete requests:      1048576
Failed requests:        0
Total transferred:      1106812710 bytes
Requests per second:    2729.84 [#/sec]
Transfer rate:          2813.92 [Kbytes/sec]

Connection Times (ms)
              min      avg        max      std
Total:        0.5      5.8       107.9      3.5

Percentage of the requests served within a certain time (ms)
   50%      4.8 ms
   66%      6.4 ms
   75%      7.2 ms
   80%      7.9 ms
   90%     10.0 ms
   95%     12.4 ms
   98%     15.5 ms
   99%     18.2 ms
  100%    107.9 ms

但是蚁阅更新订阅时是批量写入文章，我发现这个操作很慢。
如果一个订阅有 50 篇文章，全部写入就需要 500 ms，而且并行发请求效果和串行耗时一样。

所以问题可能是 Volume 数量影响了并行性能，我用 aiohttp 写了个脚本测试不同的 Volume 数量和客户端并发数对性能的影响。（详细结果附在文末）

结论是：增大并发数或 Volume 数对性能提升非常小，性能取决于磁盘，而单个磁盘 IO 是串行的。

PostgreSQL方案

从监控数据发现，SeaweedFS 方案比改写前慢了 3 倍左右。 猜想是由于蚁阅都是批量写入，而且数据都是连续的，PostgreSQL 会把一个事务里的 IO 操作合并，提升了性能。

因此我又设计了一版基于 PostgreSQL 的存储方案，表结构如下:

CREATE TABLE IF NOT EXISTS story_volume_0 (
    id BIGINT PRIMARY KEY,
    content BYTEA NOT NULL
)

主键 ID 按上文 story key 方式编码。一开始我尝试 feed_id, offset 联合主键，发现 Django 不支持， 遂改用自定义编码，效果是一样的，同时支持范围查找和范围删除。

数据分片同样用范围分片，只是分片大小设为了 64K，单表大约 1KW 行数据。
配置里指定 Volume ID 到 “数据库 + 表” 的映射关系，表会在首次使用时创建。
扩容只需部署好 PostgreSQL，然后增加映射关系即可。

写入操作，支持批量写入：

INSERT INTO story_volume_0 (id, content) VALUES (:id, :content)
ON CONFLICT (id) DO UPDATE SET content = EXCLUDED.content

我用 asyncpg 简单实现了一版，然后做了个对比测试，单个写性能略好于 SeaweedFS， 但延迟略高于 SeaweedFS。（详细结果附在文末）

正式的实现用的是 SQLAlchemy + psycopg2，有连接池性能很好，实现起来也比较稳妥。
从监控数据上看，性能和改写前基本持平，所以没有再对比批量写的性能了。

综合考虑，PostgreSQL 迁移成本较低，不用多维护一个组件，性能也不错，就选定它了。

数据压缩

文本数据压缩是很有必要的，能节省很多存储空间。数据库已经内置支持压缩，但我还是在应用层做了压缩，原因是： 数据库是有状态服务，迁移和扩容比较麻烦，而应用层是无状态的，扩容非常方便，所以尽量把负载转移到无状态服务上。

压缩算法有非常多，要在压缩率，压缩速度，解压速度之间权衡，这个网站提供了很有用的压测数据： http://quixdb.github.io/squash-benchmark/

在压缩数据上我增加了 1 字节的自定义版本号，可以方便支持不同的压缩算法。

+----------+-------------+
|  1 byte  |   N bytes   |
+----------+-------------+
|  version |   content   |
+----------+-------------+

目前对小于 1KB 的文章，不需要压缩，小于 16KB 的文章（大部分），用 lz4 压缩比较快， 大于 16KB 的文章，用 gzip 压缩率比较高，节省存储空间。

数据兼容和升级

这次存储改造后兼容上一版(1.4.2)的数据，只是增加了几个新表，无需做数据迁移，可以平滑升级。 应用层会先读新表数据，读不到再去读旧表，性能会有一点损失，但保持数据兼容是更明智的做法， 可以避免很多不必要的风险和痛苦。

另外 Django 的充血模型，不适应复杂的存储架构，后续要慢慢重构分层。

数据冗余和容灾

目前蚁阅只有一个数据库，依靠每天全量备份做容灾，后续要考虑增量备份。

自己做多副本容灾的话难度比较大，投入产出比太低，所以后续会考虑混合云方案， 即依靠云厂商抵抗自然灾害，靠自己活下去，哪怕网线被拔了也要能快速复活。

附存储方案压测结果

测试环境为 Mac Docker，磁盘 IO 比较差。结果仅供参考。
每个测试跑 3 轮，第一行为写性能，第二行为读性能。

SeaweedFS方案

1 volume, 1 concurrency
0 ------------------------------------------------------------
avg=2.7 p50=2.6 p80=2.8 p90=3.0 p95=3.6 p99=5.9 qps=373
avg=2.4 p50=2.3 p80=2.6 p90=2.9 p95=3.2 p99=4.6 qps=415
1 ------------------------------------------------------------
avg=2.7 p50=2.6 p80=2.9 p90=3.2 p95=3.7 p99=5.7 qps=368
avg=2.4 p50=2.4 p80=2.6 p90=2.8 p95=3.1 p99=4.5 qps=409
2 ------------------------------------------------------------
avg=2.6 p50=2.5 p80=2.8 p90=3.0 p95=3.3 p99=5.9 qps=383
avg=2.3 p50=2.2 p80=2.4 p90=2.6 p95=2.8 p99=3.2 qps=444

2 volume, 2 concurrency
0 ------------------------------------------------------------
avg=5.3 p50=3.4 p80=4.6 p90=6.0 p95=22.8 p99=40.7 qps=381
avg=4.3 p50=2.9 p80=3.7 p90=4.5 p95=6.0 p99=37.3 qps=470
1 ------------------------------------------------------------
avg=5.1 p50=3.4 p80=4.5 p90=5.7 p95=14.0 p99=38.1 qps=393
avg=4.4 p50=2.9 p80=3.7 p90=4.5 p95=6.3 p99=36.7 qps=459
2 ------------------------------------------------------------
avg=5.3 p50=3.5 p80=4.6 p90=5.7 p95=25.2 p99=41.4 qps=378
avg=4.2 p50=2.9 p80=3.8 p90=4.8 p95=6.4 p99=37.0 qps=475

2 volume, 20 concurrency
0 ------------------------------------------------------------
avg=55.2 p50=66.5 p80=86.4 p90=92.1 p95=97.3 p99=109.5 qps=363
avg=44.9 p50=26.5 p80=77.5 p90=84.6 p95=89.5 p99=96.3 qps=445
1 ------------------------------------------------------------
avg=57.4 p50=71.7 p80=87.9 p90=94.1 p95=98.4 p99=109.9 qps=349
avg=45.7 p50=27.6 p80=76.7 p90=84.3 p95=90.4 p99=101.4 qps=438
2 ------------------------------------------------------------
avg=60.3 p50=74.0 p80=90.9 p90=96.9 p95=101.9 p99=111.1 qps=332
avg=43.9 p50=23.5 p80=76.9 p90=83.8 p95=88.6 p99=96.0 qps=456

10 volume, 20 concurrency
0 ------------------------------------------------------------
avg=60.3 p50=75.4 p80=90.3 p90=95.2 p95=100.6 p99=107.3 qps=332
avg=53.9 p50=62.8 p80=86.2 p90=92.4 p95=97.6 p99=104.4 qps=371
1 ------------------------------------------------------------
avg=58.1 p50=71.2 p80=88.7 p90=95.2 p95=98.7 p99=105.7 qps=344
avg=47.2 p50=25.8 p80=80.1 p90=86.7 p95=91.0 p99=100.1 qps=424
2 ------------------------------------------------------------
avg=59.0 p50=68.7 p80=89.0 p90=95.2 p95=101.0 p99=107.9 qps=339
avg=49.3 p50=44.1 p80=81.9 p90=88.3 p95=94.9 p99=100.8 qps=406

PostgreSQL方案

concurrency=1
0 ------------------------------------------------------------
avg=3.6 p50=3.5 p80=3.9 p90=4.2 p95=4.6 p99=6.4 qps=275
avg=3.2 p50=3.1 p80=3.5 p90=3.8 p95=4.2 p99=5.0 qps=310
1 ------------------------------------------------------------
avg=3.9 p50=3.8 p80=4.2 p90=4.6 p95=4.9 p99=6.4 qps=254
avg=3.1 p50=2.9 p80=3.3 p90=3.7 p95=4.0 p99=7.9 qps=322
2 ------------------------------------------------------------
avg=4.2 p50=3.9 p80=4.5 p90=4.9 p95=5.4 p99=8.5 qps=240
avg=3.2 p50=3.1 p80=3.5 p90=3.8 p95=4.1 p99=4.8 qps=310

concurrency=2
0 ------------------------------------------------------------
avg=4.7 p50=4.5 p80=5.2 p90=5.8 p95=6.3 p99=8.2 qps=426
avg=3.6 p50=3.5 p80=4.0 p90=4.4 p95=4.7 p99=6.5 qps=556
1 ------------------------------------------------------------
avg=4.5 p50=4.4 p80=4.9 p90=5.4 p95=5.8 p99=7.1 qps=443
avg=3.7 p50=3.5 p80=4.0 p90=4.4 p95=4.7 p99=7.3 qps=547
2 ------------------------------------------------------------
avg=4.7 p50=4.5 p80=5.1 p90=5.6 p95=6.2 p99=7.7 qps=426
avg=3.8 p50=3.6 p80=4.2 p90=4.7 p95=5.3 p99=6.3 qps=529

concurrency=5
0 ------------------------------------------------------------
avg=10.5 p50=7.3 p80=10.1 p90=19.2 p95=38.2 p99=50.1 qps=474
avg=5.9 p50=5.4 p80=6.5 p90=7.4 p95=9.7 p99=15.8 qps=853
1 ------------------------------------------------------------
avg=10.7 p50=7.4 p80=10.1 p90=28.8 p95=38.5 p99=45.0 qps=466
avg=6.2 p50=5.6 p80=6.8 p90=7.9 p95=9.2 p99=20.7 qps=813
2 ------------------------------------------------------------
avg=10.5 p50=7.8 p80=10.7 p90=21.1 p95=33.8 p99=38.5 qps=475
avg=6.5 p50=6.3 p80=7.6 p90=8.5 p95=9.3 p99=12.3 qps=768

concurrency=10
0 ------------------------------------------------------------
avg=21.7 p50=15.7 p80=37.6 p90=47.1 p95=52.2 p99=60.7 qps=461
avg=14.7 p50=12.7 p80=18.2 p90=26.0 p95=35.7 p99=41.6 qps=680
1 ------------------------------------------------------------
avg=22.4 p50=16.0 p80=40.3 p90=52.0 p95=56.1 p99=62.7 qps=447
avg=13.3 p50=11.8 p80=16.4 p90=20.7 p95=27.1 p99=41.1 qps=754
2 ------------------------------------------------------------
avg=24.0 p50=16.9 p80=44.4 p90=53.6 p95=58.2 p99=79.3 qps=416
avg=15.0 p50=12.8 p80=17.6 p90=27.2 p95=34.0 p99=44.6 qps=668

蚁阅 是一个 RSS 阅读服务，使用 Python 实现， 已经上线运行近一年了。

前期主要在做功能开发，没有太多时间去研究性能问题，最近终于有时间做了一次性能优化。

这是优化前的状况：

CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
c27c40739bbe        rssant-web          0.00%               1.887MiB / 200MiB     0.94%               360MB / 365MB       13.2MB / 4.1kB      2
69beb84e30cc        rssant-async-api    0.04%               86.95MiB / 750MiB     11.59%              160MB / 150MB       913kB / 0B          4
a1cade903c76        rssant-api          0.03%               385.5MiB / 500MiB     77.11%              214MB / 209MB       13MB / 0B           504
1dd2be833b3b        rssant-worker-2     78.59%              1227.8MiB / 1.465GiB  61.85%              24.3GB / 12.7GB     24.8MB / 0B         33
924b7a6cec7d        rssant-worker-1     75.07%              1256.8MiB / 1.465GiB  63.79%              24.2GB / 12.7GB     1.36MB / 0B         33
4caec7b41dbf        rssant-harbor-2     13.60%              465.2MiB / 750MiB     62.03%              56.1GB / 7.56GB     102kB / 0B          33
ede36c43decd        rssant-harbor-1     15.77%              437MiB / 750MiB       58.27%              56.8GB / 7.62GB     171MB / 20.5kB      33
ea467498ede5        rssant-scheduler    2.57%               87.75MiB / 500MiB     17.55%              328MB / 2.78GB      5.85MB / 0B         33
3a617ac14ad3        rssant-postgres     1.18%               39.31MiB / 500MiB     7.86%               19.8GB / 377GB      2.47TB / 89.2GB     24
6cb8c642ad1e        rssant-prometheus   0.05%               47.02MiB / 200MiB     23.51%              559GB / 6.07GB      190GB / 19.9GB      11
3ea7a652f116        rssant-grafana      0.03%               15.09MiB / 200MiB     7.54%               289MB / 187MB       812MB / 515MB       15

整个系统最繁忙的是 rssant-worker 这个组件，即耗CPU又吃内存，运行几周后偶尔还会OOM，本次优化的就是这个组件。 这个性能问题由来已久，从最早基于 Celery 的实现到现在自己做的 Actor 系统都有一样的问题。

相关业务和组件

各组件功能如下：

• rssant-web: 流量入口，使用Nginx承载静态文件和转发API请求。
• rssant-api: 后端API，基本是Django做增删改查。
• rssant-async-api: 图片代理API，使用aiohttp实现。
• rssant-scheduler: 服务发现和注册，以及调度定时任务。
• rssant-harbor: 执行定时任务，以及将RSS解析结果入库。
• rssant-worker: 爬取和解析RSS订阅，并把结果发送给 rssant-harbor。

用户添加订阅之后，订阅信息会存到数据库，然后整个系统会定期检查并更新订阅。流程如下：

1. scheduler 有个定时器，每分钟触发一次，触发后发消息让 harbor 检查订阅。
2. harbor 收到消息后，去数据库中查询更新时间距现在超过1小时的订阅，把这些订阅的状态设为【更新中】， 然后将订阅的 ID 和 URL 发送给 worker，让 worker 去执行检查。
3. worker 收到消息，把订阅内容抓下来，解析得到订阅基本信息和所有文章，把结果发给 harbor。
4. harbor 收到结果，将每篇文章的链接及哈希值和数据库记录比对，将有变化的文章入库。

Worker 内部的流程：

1. 使用 requests 请求订阅内容，会带上 ETag, Last-Modified 请求头以利用 HTTP 协商缓存。
2. 订阅抓取之后，使用 feedparser 解析，得到初步结果。
3. 对结果中的每篇文章内容，用 lxml 做清洗和图片链接替换，用 readability 提取摘要。
4. 得到干净的内容之后，发送给 harbor 进行入库。
5. 对一些只有摘要的文章，worker 还会用 aiohttp 重新抓取全文，结果也用 lxml 和 readability 处理。
6. 对于文章中的图片链接，worker 会用 aiohttp 批量检测防盗链，如有防盗链则做链接替换。

内存性能优化

我很早就关注到内存的问题，也尝试使用 tracemalloc 和 objgraph 等工具去分析，没有太大收获。 结果类似下面这样，有个 FeedParserDict 类型有时增长很多，但很快会被 GC 掉，其他都是内置类型：

>>> objgraph.show_most_common_types(shortnames=False)
builtins.function                           27203
builtins.dict                               22782
builtins.tuple                              16488
builtins.weakref                            6806
builtins.list                               6505
builtins.cell                               5979
builtins.type                               3749
builtins.getset_descriptor                  3183
builtins.builtin_function_or_method         2524
builtins.property                           1852

>>> objgraph.show_growth(shortnames=False)
builtins.list                      8170      +967
builtins.dict                     24400      +625
builtins.tuple                    16926      +213
builtins.method                    1904      +140
feedparser.util.FeedParserDict      208      +139
builtins.Context                    757       +98
builtins.frame                      198       +87
builtins.coroutine                  109       +75
collections.deque                  1030       +60
builtins.weakref                   6955       +50

Worker 中用到了很多库，首先就怀疑 feedparser 有内存泄漏，但我没有证据，本地测试显示内存都回收干净了。

然后将其他模块中也频繁使用的库排除掉，主要有 Django 和 Actor 系统，requests 和 aiohttp 在其他模块也有用到，但使用没那么频繁。而底层的 ssl 因为出现过比较多内存泄漏问题，所有对它特别关注。

最终确定了 6 个嫌疑人: feedparser, lxml, readability, requests, aiohttp, ssl

Worker 中也有不少代码，这些代码也有嫌疑，因此我并不直接测试三方库，而是测 Worker 中与三方库相关的代码。如果测出问题，再排查是使用姿势不对还是三方库自身有问题。

测试步骤:

1. 从蚁阅数据库导出 10K 个订阅链接，然后开线程池把内容下载保存到磁盘。
2. 开线程池测试 requests，aiohttp 分别下载这些订阅。每秒钟记录一次内存占用。
3. 开线程池测试 feedparser，lxml，readability，用本地磁盘的订阅内容作为输入。每秒钟记录一次内存占用。

测试跑完之后，用 Pandas 和 Matplotlib 分析内存占用，结果如下图（横轴时间，纵轴内存占用MB）：

先看 3 个订阅解析相关的库，feedparser 有很多毛刺，但整体还是稳定的。

再看网络请求的库，requests 内存占用非常大，简直要上天。

检查一番代码以及 Google 搜了一圈之后，我将用到的 Session 和 Response 对象用完都手动 close 掉，结果如下。

内存大幅下降，而且也保持稳定了。看来是 Requests 这个库使用姿势不太对。

修复代码，上线。我期待着内存明显下降，然而并没有，监控图表显示内存只降了一点。

我仔细排查代码，想到搜索 Celery Memory Leak 时看到的文章提到：

Python不会主动把内存还给操作系统，如果程序执行使用了大量内存，待程序空闲之后 Python 会保留这部分释放的内存，预留给下次使用，所以程序的内存占用就是峰值时的内存占用。

这个表述不完全准确，有些情况 Python 还是会把内存还给操作系统， 这涉及到 Python 的内存管理和内存碎片问题，比较复杂。

对于 Celery，它有个 CELERYD_MAX_TASKS_PER_CHILD 配置项，让程序处理完指定数量的任务后就重启， 这个选项就是为了解决内存占用太大，但实际并没有内存泄漏，只是 Python 预留了内存导致看起来像内存泄漏。

所以要降低内存占用，就需要降低峰值时的内存占用。

我排查代码之后，做了一个优化，在一个大函数里提前释放一些内存：

del parsed, response, parsed_feed  # release memory
... # 下面是一些耗时操作

上线之后，内存又下降了一些，但降的不多。

总结下来，降低内存占用有两个要点：

1. 减少内存分配，对于大文本，字节流等要避免复制，尽可能 Zero-Copy。
2. 内存用完尽快回收，缩短对象的生命周期。

蚁阅中大部分内存都在三方库中分配和复制，目前能做的优化不多。

CPU性能优化

Worker 的 CPU 占用居高不下，主要是解析和处理订阅内容比较耗 CPU。

测试步骤：

1. 使用 feedparser 解析 10K 个订阅，统计 feedparser 执行时间 (feedparser)。
2. 使用 lxml 和 readability 处理文章内容，统计执行时间 (parse_found)。

测试结果如下，length 为订阅的大小，单位KB，另两列为执行时间，单位毫秒：

>>> print(df.quantile([0.5, 0.9, 0.99, 0.999]))
            length   feedparser  parse_found
0.500    39.429199    80.527544    39.163351
0.900   300.510742   599.925160   288.799524
0.990  1409.133887  3455.563748  1493.881977
0.999  4687.004390  9793.667774  4234.304533

其中 feedparser 占用时间最多，lxml + readability 时间也不少。 订阅体积越大，执行时间也越长。

接着分析 feedparser 的性能，用 pyinstrument 得到一个很直观的图，时间主要花在 resolve_relative_uris 和 _sanitize_html 这两个函数上。

经过一番搜索，发现 feedparser 有参数可以禁用这两个函数。

feedparser.RESOLVE_RELATIVE_URIS = False
feedparser.SANITIZE_HTML = False

因为链接处理和 HTML 清洗在 parse_found 中也会做一遍（feedparser 做的不够好）， 所以不需要 feedparser 做处理。

改完参数再测一遍，执行时间明显下降：

>>> print(df.quantile([0.5, 0.9, 0.99, 0.999]))
            length   feedparser  parse_found
0.500    39.273438    35.867929    37.057638
0.900   300.033984   135.883141   283.440208
0.990  1401.178672   915.256548  1466.076121
0.999  4695.528279  2557.008664  4030.596158

接下来分析 parse_found 的性能，这个函数会对每篇文章都做 HTML 清洗，链接处理，以及文本摘要。 执行时间 = 文章数量 * 每篇文章处理时间，文章数量在 10 到 100 之间，处理基本是调用 lxml API。

分析发现 lxml 的 fromstring 和 tostring 方法在每一步清洗都会调用，耗时较多。 实际上 fromstring 只需要调用一次，得到 DOM 对象，然后各个清洗步骤都对 DOM 对象操作， 最后用 tostring 将 DOM 对象转成字符串。

另一方面，因为订阅的大部分文章都已经解析过，存在蚁阅数据库了，每次只会有少量文章需要更新。 如果比较哈希值，可以快速跳过没有变化的文章，大幅降低处理时间。

粗略估计，做完这两个优化可以把 parse_found P99 时间降到 100~200ms，而 feedparser 仍然会是瓶颈。

是否可以把 feedparser P99 时间也降到 100~200ms 呢？

花了一些时间把 feedparser 的代码过了一遍，感觉是很难:

1. feedparser 底层使用 sgmllib 和 xml.sax，通过回调函数(各种 handler)处理 XML 标签。
2. feedparser 是纯 Python 实现，而 sgmllib 是 C 拓展，这意味着需要频繁在 Python 和 C 之间状态切换。
3. feedparser 和 sgmllib 都很老了，包含很多兼容性代码，对 Python 3 也没有做优化。

如果用 Golang 会怎么样呢？

我找到了 gofeed，然后选了一个 5MB 的超大订阅测试一下， 发现只要 100 多毫秒! 意味着 P999 是 100 多毫秒，P99 就更低了！

PS: 目前正在学习 Golang，等学好了再来更新!

业务逻辑优化

到目前为止，内存占用降低约 10%，CPU 处理时间降低约 50%。接下来考虑在业务上做优化了。

在前面的分析中可以看到，极少数(1%)订阅消耗了大量资源，可以降低这些超大订阅的检查更新频率。

>>> print(df.quantile([0.5, 0.9, 0.99, 0.999]))
            length   feedparser  parse_found
0.500    39.273438    35.867929    37.057638
0.900   300.033984   135.883141   283.440208
0.990  1401.178672   915.256548  1466.076121
0.999  4695.528279  2557.008664  4030.596158

另外对停更的订阅，更新不频繁的订阅，没人看的订阅，都可以降低检查更新频率。

这就是蚁阅的订阅冻结功能，动态调整检查更新频率，下面是目前的规则：

+------------+----------+------------+----------+
|   冻结时间  |  300k以下 | 300k~1500k | 1500k以上 |
+------------+----------+------------+----------+
|   资讯新闻  |    1H    |     1H     |    3H    |
|   周更博客  |    1H    |     2H     |    9H    |
|   月更博客  |    4H    |     8H     |    9H    |
+------------+----------+------------+----------+

优化效果

CPU性能优化：订阅处理时间缩短了一半。
业务优化：需要检查更新的订阅少了一半。
意外收获：因为业务优化和CPU性能优化，内存分配更少，回收更快，内存占用也大幅下降了。

Grafana 的图表，大约 20:00 上线的：

阿里云的监控图表：

注：凌晨4点的峰值是因为在定时做数据库备份。

(全文完)