流动性

流动性（现金流）是一个老生常谈的概念。在运行闲鱼的过程中，我对流动性有了切实的感受。
如何形容这种感觉呢。
你下个月到期有5万的欠款，但是你手头有一笔生意，每天能收到2000元，一个月就是6万元。
生意自身的利润是2%，只要你不停的往前跑，就不会倒塌，但你一停下来，就会立马崩溃。
现金流大，也意味着手头现金很多，多出来的现金和多出来的周期，就意味着更多的利润和收入。
国内的生意，大家都喜欢，大鱼吃小鱼，是平台就喜欢多收费，是大公司就喜欢利用自己压倒性的优势。
所以小商户整体利润都很低，在底层做，会被层层按揭，导致实际利润极低。

生意的本质

如果说，生意可以让房贷，往后延一个月，那就解决大问题了。但目前，生意只是把信用卡里的钱提取出来，按照月息2%的利率，收取收益而已。
相较于存放到投资平台，银行。利润更高，但是需要更人力的支出。
如果不讨论到底干了啥，只是抽象的说占用了多少人力，生意也就是一种占用更多人力的高收益投资，无二致。

非法集资

如果能把利润拉高，那么可以用分利润的方式去吸引他人加入，从而获得别人的现金。
这就是非法集资了，将高利润项目同他人分享，但是需要别人给与现金支持，从而将资金盘子做大。
在扩大盘子的同时，还要继续保持高利润，这是一个很难做到的事情，所以绝大多数时，都是骗局。

screenshot-to-code 是近期在github上很火的GPT衍生项目，其提供web界面去调用GPT-vision接口，进行图生代码的转换。
在这基础上，还做了前端框架融合（生成的代码使用tailwindcss）、server服务集成（代码在backend文件夹中）。
在上线两个月后，star数达到了3.1万，热度很高，AI的风潮确实十分强劲。

使用效果可以看这个视频

安装

下面来简单介绍下，在安装部署screenshot-to-code过程中可能遇到的问题。将分成两个部分来入手介绍。

基础依赖

screenshot-to-code项目中包含了前端和后端两部分，分别在frontend、backend文件夹中。需要分别将前后端项目启动，才算完整运行。
前端部分使用yarn作依赖管理，node作webui的server环境，后端部分则使用poetry作依赖管理，python作api的server环境。同时，为了避免多个环境依赖问题，项目使用docker多镜像联合运行，所以需要本地机器安装了docker和docker-compose。
最后，项目的核心能力是通过调用GPT-vision接口实现，所以还需要我们拥有openai的OPENAI_API_KEY，KEY需要我们在openai官网上开通GPT4的会员才能使用（GPT4需要付费使用，价格可以参考Pricing）。

简单对上面的概念做下介绍:

• yarn: JavaScript生态中的一种包管理工具
• poetry: Python生态中的一种包管理工具
• docker: 虚拟化工具，可分割出独立的环境模块，并在其中完成复杂依赖的安装，且不会影响宿主机器和宿主上的其他程序
• docker-compose: 将由docker虚拟化出的多个环境模块联合到一起的工具，比如将前端的模块、后端的模块联合到一起，组成网站

问题描述

1
2
3
4
5
6
7

``` js
const less = require("rollup-plugin-less");
const postcss = require("rollup-plugin-postcss");
const tailwindcss = require("tailwindcss");

less({ insert: false }),
postcss({ plugins: [tailwindcss] })

提示 config.less 文件 编译不识别 error: [LessError: Unrecognised input]

排查步骤

1. 错误定位: var isFinished = parserInput.i >= input.length中的isFinished 为fasle 导致报错
2. 为什么 parserInput.i 是0
3. 找到 parserInput.i 给值的地方
4. 定位到错误是发生在这段逻辑中 browser_plugin_template/node_modules/_less@4.2.0@less/lib/less/parser/parser.js
5. 在这个文件中，出错的逻辑在

   1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

   try { parserInput.start(str, context.chunkInput, function fail(msg, index) { throw new less_error_1.default({ index: index, type: 'Parse', message: msg, filename: fileInfo.filename }, imports); }); tree_1.default.Node.prototype.parse = this; root = new tree_1.default.Ruleset(null, this.parsers.primary()); tree_1.default.Node.prototype.rootNode = root; root.root = true; root.firstRoot = true; root.functionRegistry = function_registry_1.default.inherit(); } catch (e) { return callback(new less_error_1.default(e, imports, fileInfo.filename)); } var endInfo = parserInput.end();

   在 end的地方就报错了，问题在于 root = new tree_1.default.Ruleset(null, this.parsers.primary()); 这句的调用，这个逻辑从名字上看是以树状结构去搜索解析css的样式。
   换言之，为了定位报错的原因，已经找到less-plugin里的逻辑，但仍然无法定位具体原因，还要继续深入，这么一来，问题已经无法继续追查下去
6. 换个思路 parserInput.i 值不对，那么就监听所有可以给 parserInput.i 赋值的地方，看报错前最后一次调用是谁发起的
7. 然后发现 parserInput.i 被赋值的地方很多，而且很难以收口debugger，这意味着，通过less插件代码，定位错误原因的努力失败
8. 然后想到去搜索git主页的issue 看是否有类似的问题
9. 发现有类似的问题，并且很久没有结果了
10. 果断用新插件（postcss，支持use loader，加载解析不同类型的样式文件）