人类一生所学不过 4GB，加州理工顶刊新研究引热议
24 小时不间断学习且不遗忘，一辈子也只有 4GB 的 “知识储量”？
科学家们最新研究，计算出了人类学习积累上限，就这么多~~（甚至还不如一块 U 盘能装）。
这是来自 Cell 旗下神经科学顶刊 Neuron 上的一项工作，它提出了一个发人深省的悖论：
人类信息处理速度仅为每秒 10bit，而我们的感官系统却能以每秒 10 亿 bit 的速率收集数据。
由此，按照每秒 10bit 的速度来算，人类 24 小时不间断学习且不遗忘，100 年储存的知识也不过 4GB。
什么概念呢？来和大模型做个对比：
大语言模型每个参数就能存储 2bit 知识，一个 70 亿参数的模型就能存储 140 亿 bit 的知识。
△结论来自华人学者朱泽园”Physics of Language Models” 系列论文
难怪研究人员还提出了一项推论：
随着算力的不断提升，机器在各类任务中的表现超越人类只是时间问题。
另外，按照这项研究的结论，马斯克目前的脑机接口研究也有问题了。
研究人员表示：
我们预测马斯克的大脑与计算机的通信速率大约为 10bit/s。与其使用 Neuralink 的电极束，不如直接使用电话，因为电话的数据传输率已经被设计得与人类语言相匹配，而人类语言又与感知和认知的速度相匹配。
一时间，这一系列惊人推论在学术圈各大社区引起广泛讨论。
美国知名医师科学家、斯克里普斯转化研究所创始人 Eric Topol 也忍不住下场转发。
为啥我们一次只能思考一件事呢？
所以，结论如何得出的？
中枢神经系统 “串行” 影响信息处理速率
简单说，要想计算人一辈子能学多少知识，我们得先从大脑处理信息的速度说起。
从对几项日常活动（如打字、说话演讲、拧魔方等）的评估来看，他们初步得出 “大脑处理信息的速度约为 10bits/s” 这一结论。
以人类打字为例，高级打字员每分钟能打 120 个单词（每秒 2 个），平均每个单词按 5bit 计算，那么信息传输速率就是 10bits/s。
同样，若以英语演讲为例，如果将节奏控制在舒适程度——讲话速度为每分钟 160 个单词，则信息传输速率为 13bits/s，略高于打字。
再比如 “盲拧魔方” 这项竞技活动，选手需先观察魔方几秒，然后闭眼还原。以一次世界纪录的成绩 12.78s 为例，其中观察阶段约 5.5s，由于魔方可能的排列数约为 4.3x1016≈265，则最终信息传输速率约为 11.8bits/s。
使用类似方式，作者估算了更多场景下的信息处理速度（从经典实验室实验到现代电子竞技等），结果显示为 5~50bits/s 之间。
由此也得出一个整体结论：人类思考的速度始终在 10bits/s 的尺度范围内。
按照这一标准，假设我们能活 100 岁，每天 24 小时不间断学习（且剔除遗忘因素），那么我们最终的 “知识储量” 也将不到 4GB。
事实上，与 10bits/s 形成鲜明对照的是——人类感官系统以约 10 亿 bits/s 的速率收集数据。
10bits/s VS 10 亿 bits/s
具体来说，我们每天从周围环境中获取信息的速率就以 Gbps/s 起算。
举个栗子，视觉系统中单个视锥细胞能以 270bits/s 的速度传输信息，而一只眼睛就拥有约 600 万个视锥细胞。
那么，光是双眼视觉系统接收信息的速度就高达 3.2Gbps/s。照此推算，我们接收信息的速度与处理信息的速度之间的差距比值竟然达到了 108:1。
要知道，人类大脑里有超过 850 亿个神经元，其中三分之一集中在大脑皮层组成了复杂的神经网络。也就是说，明明单个神经元就能轻松处理超过 10bits/s 的信息。
而现在所观察到的现象却与之不符，显而易见，上述二者之间存在一定矛盾。
从神经元本身的性能来看，它们具备快速处理和传输信息的能力，但这并没有直接转化为整体认知速度的提升，说明还有其他因素在起作用。
那么，为什么人类信息处理速度如此之慢？
按照论文分析，原因可能在以下几个方面：
最主要的，中枢神经系统在处理信息时采用的是串行方式，对信息传输速率有所限制。
这里要提到并行处理和串行处理之间的区别。
所谓并行处理，显然指多个任务同时进行。以我们看东西为例，视网膜每秒会产生 100 万个输出信号，每一个信号都是视网膜神经元对视觉图像局部计算的结果，由此同时处理大量视觉信息。
而在中枢神经系统中，他们观察到了一种 “心理不应期”（psychological refractory period）效应，即同时面对多个任务，中枢神经系统只将注意力集中在一个任务上。
当然，他们也进一步探究了出现 “串行” 背后的原因，结论是这与演化过程早期的神经系统功能有关。
展开来说，那些最早拥有神经系统的生物，核心利用大脑来检测气味分子的浓度梯度，以此判断运动方向进行捕食和避开敌人。长此以往，这种特定功能需求使得大脑逐渐形成了 “一次处理一个任务” 的认知架构。
在进化过程中，大脑的这种架构逐渐固化，虽然随着物种的进化，大脑的功能越来越复杂，但这种早期形成的认知架构仍然在一定程度上限制了我们同时处理多个任务和快速处理信息的能力。
除此之外，还有理论认为存在 “注意瓶颈” 等限制了信息处理。注意力是认知过程中的一个重要因素，它就像一个瓶颈，限制了能够进入认知加工阶段的信息数量和速度，不过其具体运作机制目前人类尚未完全理解。
总之，按照论文的观点，10bits/s 这样的速度已经可以满足人类生存需求，之所以还存在庞大的神经元网络，原因可能是我们需要频繁切换任务，并整合不同神经回路之间的信息。
马斯克脑机接口过于理想化
不过话虽如此，鉴于 10bits/s 和 10 亿 bits/s 之间的巨大差距，人类越来越无法忍受慢节奏了。
由此论文也得出一个推断：随着算力的不断提升，机器在各类任务中的表现超越人类只是时间问题。
换成今天的话说，以 AI 为代表的新物种将大概率逐渐 “淘汰” 人类。
另外，论文还顺带调侃了马斯克的脑机接口系统。
其中提到，马斯克的行动基于肉体带宽不足对处理信息的限制。按照老马的设想，一旦通过高带宽接口直接连接人脑和计算机，人类就可以更自由地和 AI 交流，甚至共生。
然而他们认为这一想法有些过于理想化。
10bits/s 的限制源于大脑基本结构，一般无法通过外部设备来突破。
由此也提出开头提到的建议：
与其使用 Neuralink 的电极束，不如直接使用电话，因为电话的数据传输率已经被设计得与人类语言相匹配，而人类语言又与感知和认知的速度相匹配。
不过上述言论也并非意味着他们对脑机接口失去信心，他们认为其关键并不在于突破信息速率限制，而是以另一种方式提供和解码患者所需信息。
作者之一为上海交大校友
这项研究由来自加州理工学院生物学与生物工程系的两位学者完成。
Jieyu Zheng 目前是加州理工学院五年级博士研究生，她还是上海交大本科校友，还有康奈尔大学生物工程学士学位，在剑桥大学获得教育与心理学硕士学位。
她的研究重点聚焦于认知灵活性、学习和记忆，特别关注大脑皮层和海马体在这些功能中的核心作用。目前她正在进行一个名为 “曼哈顿迷宫中的小鼠” 项目。
Markus Meister 是 Jieyu Zheng 的导师，1991 年起在哈佛大学担任教授，2012 年于加州理工学院担任生物科学教授，研究领域是大型神经回路的功能，重点关注视觉和嗅觉的感官系统。
Markus Meister 曾于 1993 年被评为 Pew 学者，2009 年因其在视觉和大脑研究方面的贡献获 Lawrence C. Katz 神经科学创新研究奖以及 Minerva 基金会颁发的 “金脑奖”。
新研究发布后，作者们就在 X 上当起了自个儿的自来水。
我们提出的特征是脑科学中最大的未解数值。
Markus Meister 还调侃每秒 10bit 的处理速度可是经过了同行评审的。
随后学术圈各大社区也针对这项研究开始讨论起来。
有人认为论文读起来很有意思，发人深省：
简化内容，只聚焦于中枢神经系统并且将讨论的内容分为内部和外部大脑两部分后，更有意义了。
这是一个非常重要的视角，值得深思……
然鹅，也有不少人提出疑问。
我越想这篇论文中的某些估计，就越怀疑。例如，关于打字员与听者之间比特率的等效性（S.3）似乎有误。正如香农所指出的，英文字母的熵约为每字符 1bit。但如果是一连串的单词或是概念，情况又如何呢？
作者默认了一个假设，即每秒 10bit 是慢的。与我们在硅基底上实现的通用计算系统相比，这的确很慢，但这种假设并不能线性地转化为大脑的信息吞吐量和存在的感知。
对于这项研究，你有什么看法呢？
参考链接：
[1]http://www.caltech.edu/about/news/…
[2]http://www.cell.com/neuron/abst…
[3]news.ycombinator.com/item?id=424…
[4]arxiv.org/pdf/2408.10…
欢迎在评论区留下你的想法！
— 完 —
来源：juejin.cn/post/7492778249534619648
为什么一个文件的代码不能超过300行？
大家好，我是前端林叔，掘金小册《如何写出高质量的前端代码》 作者。
先说观点：在进行前端开发时，单个文件的代码行数推荐最大不超过300行，而超过1000行的都可以认为是垃圾代码，需要进行重构。
为什么是300
当然，这不是一个完全精准的数字，你一个页面301行也并不是什么犯天条的大罪，只是一般情况下，300行以下的代码可读性会更好。
起初，这只是林叔根据自己多年的工作经验拍脑袋拍出来的一个数字，据我观察，常规的页面开发，或者说几乎所有的前端页面开发，在进行合理的组件化拆分后，页面基本上都能保持在300行以下，当然，一个文件20行也并没有什么不妥，这里只是说上限。
但是拍脑袋得出的结论是不能让人信服的，于是林叔突发奇想想做个实验，看看这些开源大佬的源码文件都是多少行，于是我开发了一个小脚本。给定一个第三方的源文件所在目录，读取该目录下所有文件的行数信息，然后统计该库下文件的最长行数、最短行数、平均行数、小于500行/300行/200行/100行的文件占比。
脚本实现如下，感兴趣的可以看一下，不感兴趣的可以跳过看统计结果。统计排除了css样式文件以及测试相关文件。
const fs = require('fs');
const path = require('path');
let fileList = []; //存放文件路径
let fileLengthMap = {}; //存放每个文件的行数信息
let result = { //存放统计数据
min: 0,
max: 0,
avg: 0,
lt500: 0,
lt300: 0,
lt200: 0,
lt100: 0
}
//收集所有路径
function collectFiles(sourcePath){
const isFile = function (filePath){
const stats = fs.statSync(filePath);
return stats.isFile()
}
const shouldIgnore = function (filePath){
return filePath.includes("__tests__")
|| filePath.includes("node_modules")
|| filePath.includes("output")
|| filePath.includes("scss")
|| filePath.includes("style")
}
const getFilesOfDir = function (filePath){
return fs.readdirSync(filePath)
.map(file => path.join(filePath, file));
}
//利用while实现树的遍历
let paths = [sourcePath]
while (paths.length){
let fileOrDirPath = paths.shift();
if(shouldIgnore(fileOrDirPath)){
continue;
}
if(isFile(fileOrDirPath)){
fileList.push(fileOrDirPath);
}else{
paths.push(...getFilesOfDir(fileOrDirPath));
}
}
}
//获取每个文件的行数
function readFilesLength(){
fileList.forEach((filePath) => {
const data = fs.readFileSync(filePath, 'utf8');
const lines = data.split('\n').length;
fileLengthMap[filePath] = lines;
})
}
function statisticalMin(){
let min = Infinity;
Object.keys(fileLengthMap).forEach((key) => {
if (min > fileLengthMap[key]) {
min = fileLengthMap[key];
}
})
result.min = min;
}
function statisticalMax() {
let max = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (max < fileLengthMap[key]) {
max = fileLengthMap[key];
}
})
result.max = max;
}
function statisticalAvg() {
let sum = 0;
Object.keys(fileLengthMap).forEach((key) => {
sum += fileLengthMap[key];
})
result.avg = Math.round(sum / Object.keys(fileLengthMap).length);
}
function statisticalLt500() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 500) {
count++;
}
})
result.lt500 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
function statisticalLt300() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 300) {
count++;
}
})
result.lt300 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
function statisticalLt200() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 200) {
count++;
}
})
result.lt200 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
function statisticalLt100() {
let count = 0;
Object.keys(fileLengthMap).forEach((key) => {
if (fileLengthMap[key] < 100) {
count++;
}
})
result.lt100 = (count / Object.keys(fileLengthMap).length * 100).toFixed(2) + '%';
}
//统计
function statistics(){
statisticalMin();
statisticalMax();
statisticalAvg();
statisticalLt500();
statisticalLt300();
statisticalLt200();
statisticalLt100();
}
//打印
function print(){
console.log(fileList)
console.log(fileLengthMap)
console.log('最长行数：', result.max);
console.log('最短行数：', result.min);
console.log('平均行数：', result.avg);
console.log('小于500行的文件占比：', result.lt500);
console.log('小于300行的文件占比：', result.lt300);
console.log('小于200行的文件占比：', result.lt200);
console.log('小于100行的文件占比：', result.lt100);
}
function main(path){
collectFiles(path);
readFilesLength();
statistics();
print();
}
main(path.resolve(__dirname,'./vue-main/src'))
利用该脚本我对Vue、React、ElementPlus和Ant Design这四个前端最常用的库进行了统计，结果如下：
| 库 | 小于100行占比 | 小于200行占比 | 小于300行占比 | 小于500行占比 | 平均行数 | 最大行数 | 备注 |
|---|---|---|---|---|---|---|---|
| vue | 60.8% | 84.5% | 92.6% | 98.0% | 112 | 1000 | 仅1个模板文件编译的为1000行 |
| react | 78.0% | 92.0% | 94.0% | 98.0% | 96 | 1341 | 仅1个JSX文件编译的为1341行 |
| element-plus | 73.6% | 90.9% | 95.8% | 98.8 | 75 | 950 | |
| ant-design | 86.9% | 96.7% | 98.7% | 99.5% | 47 | 722 |
可以看出95%左右的文件行数都不超过300行，98%的都低于500行，而每个库中超过千行以上的文件最多也只有一个，而且还都是最复杂的模板文件编译相关的代码，我们平时写的业务代码复杂度远远小于这些优秀的库，那我们有什么理由写出那么冗长的代码呢？
从这个数据来看，林叔的判断是正确的，代码行数推荐300行以下，最好不超过500行，禁止超过1000行。
为什么不要超过300
现在，请你告诉我，你见过最难维护的代码文件是什么样的？它们有什么特点？
没错，那就是大，通常来说，难维护的代码会有3个显著特点：耦合严重、可读性差、代码过长，而代码过长是难以维护的最重要的原因，就算耦合严重、可读性差，只要代码行数不多，我们总还能试着去理解它，但一旦再伴随着代码过长，就超过我们大脑（就像计算机的CPU和内存）的处理上限了，直接死机了。
这是由于我们的生理结构决定的，大脑天然就喜欢简单的事物，讨厌复杂的事物，不信咱们做个小测试，试着读一遍然后记住下面的几个字母：
F H U T L P
怎么样，记住了吗？是不是非常简单，那我们再来看下下面的，还是读一遍然后记住：
J O Q S D R P M B C V X
这次记住了吗？这才12个字母而已，而上千行的代码中，包含各种各样的调用关系、数据结构等，为了搞懂一个功能可能还要跳转好几个函数，这么复杂的信息，是不是对大脑的要求有点过高了。
代码行数过大通常是难以维护的最大原因。
怎么不超过300
现在前端组件化编程这么流行，这么方便，我实在找不出还要写出超大文件的理由，我可以"武断"地说，凡是写出大文件的同学，都缺乏结构化思维和分治思维。
面向结构编程，而不是面向细节编程
以比较简单的官网开发为例，喜欢面向细节编程的同学，可能得实现是这样的：
<div>
<div class="header">
<img src="logo.png"/>
<h1>网站名称</h1>
<!-- 其他头部代码 -->
</div>
<div class="main-content">
<div class="banner">
<ul>
<li><img src="banner1.png"></li>
<!-- 省略n行代码 -->
</ul>
</div>
<div class="about-us">
<!-- 省略n行代码 -->
</div>
<!-- 省略n行代码 -->
</div>
</div>
其中省略了N行代码，通常他们写出的页面都非常的长，光Dom可能都有大几百行，再加上JS逻辑以及CSS样式，轻松超过1000行。
现在假如领导让修改"关于我们"的相关代码，我们来看看是怎么做的：首先从上往下阅读代码，在几千行代码中找到"关于我们"部分的DOM，然后再从几千行代码中找到相关的JS逻辑，这个过程中伴随着鼠标的反复上下滚动，眼睛像扫描仪一样一行行扫描，生怕错过了某行代码，这样的代码维护起来无疑是让人痛苦的。
面向结构开发的同学实现大概是这样的：
<div>
<Header/>
<main>
<Banner/>
<AboutUs/>
<Services/>
<ContactUs/>
</main>
<Footer/>
</div>
我们首先看到的是页面的结构、骨架，如果领导还是让我们修改"关于我们"的代码，你会怎么做，是不是毫不犹豫地就进入AboutUs组件的实现，无关的信息根本不会干扰到你，而且AboutUs的逻辑都集中在组件内部，也符合高内聚的编程原则。
特别是关于表单的开发，面向细节编程的情况特别严重，也造成表单文件特别容易变成超大文件，比如下面这个图，在一个表单中有十几个表单项，其中有一个选择商品分类的下拉选择框。
面向细节编程的同学喜欢直接把每个表单项的具体实现，杂糅在表单组件中，大概如下这样：
<template>
<el-form :model="formData">
<!--忽略其他代码-->
<el-form-item label="商品分类" prop="group">
<el-select v-model="formData.group"
@visible-change="$event && getGr0upOptions()"
>
<el-option v-for="item in groupOptions"
:key="item.id"
:label="item.label"
:value="item.value"
></el-option>
</el-select>
</el-form-item>
</el-form>
</template>
<script>
export default {
data(){
return {
formData: {
//忽略其他代码
group: ''
},
groupOptions:[]
}
},
methods:{
groupOptions(){
//获取分类信息，赋给groupOptions
this.groupOptions = [];
}
}
}
</script>
这还只是一个非常简单的表单项，你看看，就增加了这么多细节，如果是比较复杂点的表单项，其代码就更多了，这么多实现细节混合在这里，你能轻易地搞明白每个表单项的实现吗？你能说清楚这个表单组件的主线任务吗？
面向结构编程的同学会把它抽取为表单项组件，这样表单组件中只需要关心表单初始化、校验规则配置、保存逻辑等应该表单组件处理的内容，而不再呈现各种细节，实现了关注点的分离。
<template>
<el-form :model="formData">
<!--忽略其他代码-->
<el-form-item label="商品分类" prop="group">
<select-group v-model="formData.group" />
</el-form-item>
</el-form>
</template>
<script>
export default {
data(){
return {
formData: {
//忽略其他代码
group: ''
}
}
}
}
</script>
分而治之，大事化小
在进行复杂功能开发时，应该首先通过结构化思考，将大功能拆分为N个小功能，具体每个小功能怎么实现，先不用关心，在结构搭建完成后，再逐个问题击破。
仍然以前面提到的官网为例，首先把架子搭出来，每个子组件先不要实现，只要用一个简单的占位符占个位就行。
<div>
<Header/>
<main>
<Banner/>
<AboutUs/>
<Services/>
<ContactUs/>
</main>
<Footer/>
</div>
每个子组件刚开始先用个Div占位，具体实现先不管。
<template>
<div>关于我们</div>
</template>
<script>
export default {
name: 'AboutUs'
}
</script>
架子搭好后，再去细化每个子组件的实现，如果子组件很复杂，利用同样的方式将其拆分，然后逐个实现。相比上来就实现一个超大的功能，这样的实现更加简单可执行，也方便我们看到自己的任务进度。
可以看到，我们实现组件拆分的目的，并不是为了组件的复用（复用也是组件化拆分的一个主要目的），而是为了更好地呈现功能的结构，实现关注点的分离，增强可读性和可维护性，同时通过这种拆分，将复杂的大任务变成可执行的小任务，更容易完成且能看到进度。
总结
前端单个文件代码建议不超过300行，最大上限为500行，严禁超过100行。
应该面向结构编程，而不是面向细节编程，要能看到一个组件的主线任务，而不被其中的实现细节干扰，实现关注点分离。
将大任务拆分为可执行的小任务，先进行占位，后逐个实现。
本文内容源自我的掘金小册 《如何写出高质量的前端代码》
来源：juejin.cn/post/7431575865152618511
3小时，从0到1上线MVP海外AI网站产品！深度复盘
三、新手3小时极限上线AI产品网站
作为程序员来说，最喜欢务实，不讲虚的。
所以讲完了创业史（具体看这篇：1个人，创业2年心酸史，做各种海外赚美金项目。这一次，你终于悟道了）我们再来讲讲如何3小时极限上线一个AI产品网站。
3.1 什么是AI产品网站出海？
AI产品网站出海，简单来说基于AI技术的产品，通过网站的形式面向海外市场。这不仅仅是语言的翻译，更是对海外用户需求的深度理解和产品的本地化适配。在如今这个AI快速发展的时代，海外市场对AI应用的接受度和付费意愿相对较高，特别是欧美市场。
AI网站出海的核心在于：
技术门槛低：借助现有的开发工具Cursor和AI API大模型，独立开发者也能快速搭建产品
市场需求旺盛：海外用户对AI工具的付费习惯已经形成（比如OpenAI，Claude）
竞争相对较小：相比国内市场，海外AI工具市场仍有大量空白领域
变形路径清晰：订阅制、按次付费等付费模式已被广泛接受。
3.2 为什么选择AI产品网站出海作为创业方向？
3.2.1 个人兴趣和优势
首先我做了5年内核开发程序员，一开始接触知识星球的时候，看到的都是国内各种平台，很明显就不感兴趣。
所以还是打工人的时候，一开始做的项目就是海外工具站。
但是虽然我是程序员，但程序员也分很多种，前端，后端，对于做一个网站，完全没有经验。
当时我记得捣鼓了很久，上线后各种报错，代码完全看不懂，后来就放弃了。
现在，完全不同了。
不需要懂代码，Cursor直接帮你搞定。
当然，要想做出一个成熟的AI产品网站，肯定还是要去学代码的，不然每次编程就和抽卡一样，太随机了。
每当一个bug解决、一个功能实现的实现，程序员的那种成就感油然而生。
其次，我做过很多海外项目，对这一块还是比较熟悉的，所以这些都是我的优势。
自然而然，我应该做AI产品网站出海。
3.2.2 试错成本很低
这里主要是讲资金成本。
相比于我做过的很多海外项目来说，AI产品网站的开发成本特别低。
一个网站：最便宜的几美金一年。
AI编程工具：Cursor（20美金一个月，之前的教育优惠直接免费1年）
其他：都是免费（是的，你没有看错）
下面这张图是网友总结的，可以看到：除了域名和AI编程工具，其他真的是免费的。 （程序员很老实，从来不骗人）
但是，这里要讲下但是，这里讲的是启动资金成本。
如果你的网站有流量了，很大，那你肯定也要投入资金买服务器了。
但这个时候，你也已经开始赚钱了，并且还不少。
所以说，试错成本真的很低。
自从我做过FB跨境电商后，真的再也不想去碰成本这么高的了。
这里还有一个费用，肯定很多人都很关心。
API调用费用
先给大家看一张图，我这次用的photomaker这个API
它一下生成4张图片，才0.0011美金。
从我开发到上线后找人测试，也才花了2.8美金。
并且我的API账号还是之前薅的羊毛，一共两个号，薅了100美金（用不完，完全用不完。）
就算你的网站上线后，你放心，也只会有少量的API调用。
除非很多人用，但这时候你已经开始赚钱了。
我现在用的有：
- Claude 4 :
某宝买共享账号，它给你一个账号池，每3个小时可以使用40次，非常方便。
用于写开发者文档，和claude讨论需求。
- Cursor pro账号
之前某鱼搞的教育优惠，100多块直接用1年。
- 其他
也就上站的时候买一个域名，几美金就行。其他真没了。
3.2.3 市场机会巨大
从个人兴趣和优势出发，不断试错，那也要去能赚到钱的地方是吧。
海外AI工具市场正处于爆发期，用户对新产品的接受度高，愿意为解决实际问题的AI工具付费。
光说没有用，我看看实际案例，我们都喜欢看见再相信。
- Pieter Levels
这是一个海外的独立开发者，一个人，做了这么多产品。
而且他所有的收入都列在了他的推上。
- 刘小排老师
老外大家可能觉得很遥远，我们看看国内。
一个人，创业后第一个产品就做到了100万月活，只用了1个月，并且做完就放放那了，都没做任何付费推广。
- 百里登风
这个人大家可能不太熟悉，这个人就是我（哈哈哈）
从0到1，上线一个MVP产品，用了3个多小时。
我特意用秒表测了一下自己的极限开发速度。
从看到需求到正式上线大概花了3个多小时（包含吃饭时间）。
个人认为还可以继续优化，大概2个小时就差不多可以完成。
这是我开发的产品，10大场景下的AI摄影生成工具。（目前小bug还比较多，当然后面需要慢慢优化，比如登陆界面还没做，支付还没接等等。）
看到现在，大家肯定很枯燥了吧。
所以，我们先来看看我花了3个小时，做出的产品，让你先感受下我的乐趣，或者以后也会成为你的乐趣。
原始图片：
场景一：专业正件照片
场景二：社交和约会照片
场景三：健身锻炼照片
场景四：旅行照片
场景五、婚礼照片
好，不能再放了，再放怕你睡不着。
是不是很牛逼，很逼真，虽然我不知道有没有人做过这种产品，但至少它很有趣，那就可以了。
网站地址：http://www.headshotpro.art/。
- 大家
AI时代，每一个人都有机会，每个人都可以做出自己的AI产品网站，所以能看到这里的，都要给大家留个位置。
3.3 如何发现海外AI摄影场景需求？
当然不是我想出来的，自己拍脑袋想出来的几乎都不行。
我是群里看到的，一个网站，一个月13万刀。
这时候，好奇心就来了，这是什么网站？（好奇心往往会有一些发现）
这个网站其中一个功能就是上传自拍，制作自己的AI人物
刚才我才发现，它也有AI场景功能，不过它要输入提示词，我直接固定10个场景。
大家都很懒，肯定会直接吃喂到嘴边的饭，而不是自己去找饭吃，所以固定10个场景，不需要用户输入提示词（这一点很重要）
真正吸引我的是真实感，连眼球都能看清楚。这也太太厉害了，AI一般给人的感觉都很假。
所以我也想开发一个类似的AI摄影图片功能。
其实这一步之后，还需要市场调研，竞品分析，差异化思考。
因为你能想出来的东西，肯定大家都做过了，但不妨碍我们去玩。
是的，你没有看错，就是玩。
3.4 从0到1：3小时极限MVP开发全流程
3.4.1 用claude写需求文档
总算进入正题了，到这你已经看了3908个字，我已经写了一下午加一晚上了，腰都酸了，现在已经22:48分了，奈何就是想写呢。
好，继续（下面的教程大家放心，因为我之前公众号写AI工具使用方法都写的很细，自己都体验过一遍，生怕大家错过每一个步骤。）
看到一个需求后，第一步，不是直接用Cursor实现一个完整的产品，而是先和AI讨论，写一个开发者文档。（这一步很重要）
为什么很重要？这里要说一下。
因为你如果不写这个文档，可能你一边开发，一边脑子里就已经想到一个新功能，做着做着就跑偏了。
很多人觉得写开发者文档很难，需要长篇大论。
其实，不需要。
AI就是你的员工，就是你的伙伴，就是你的合伙人。
比如：我要开发一个AI摄影产品。
你这么说：
我想要开发一个网站，用户上传头像后，为用户创建各种场合的逼真的照片。我们来聊聊这个需求，你觉得应该怎么做？
接下来，你就继续和它聊天，随便聊，就把它当作你的员工，直到你的想法和它的答案对上，就可以了。
比如我说：
我需要10个有痛点需求的场景。
下一步：做出MVP需求文档
你和它说：
你先做MVP，帮我产生一份MVP需求文档，尽量简单。
好，这时候，你的员工就帮你干活了。把这份文档保存在飞书里。
下面的是我让AI生成的需求文档。
这里有一个比较有意思的点，claude 可以生成图文形式的需求文档。
给大家看看我的，非常好玩。一目了然。
3.4.2 V0做出产品原型
有了需求文档，不是去直接开发产品了，而是先做个产品原型。
这个就像你想吃鸡腿，你脑海里就会有一个鸡腿的样子（这个叫心理表征，可以看《刻意练习》）
那你现在只有一个文档，没有一个产品的样子，所以先把这个样子做出来。
V0网址：v0.dev/
这里注意一点，我们做一个产品原型，只做壳子就行。具体的功能先不实现，因为具体的功能比较复杂，它比较难做，后面去Cursor里做。
你这样告诉V0:
我要做一个给外国人生成AI摄影图片的产品，使用NextJS框架。
你只需要帮我做一个产品原型，不需要实现具体的功能，
设计的风格尽可能参照小红书的风格。
下面是需求开发文档。（这里你把刚才生成的需求文档复制给他）
然后，等一会，十分钟吧，他就给你生成好了，中间可能会遇到一些报错，直接点击按钮让它修复就可以。
我们来看看具体的效果。
是不是非常不错？
是的，但是我们还需要实现它实际的功能。
3.4.3 Cursor开发实际功能
好，现在我们来真正做实际的功能。
- 下载V0生成的代码，点击右上角下载代码。
- 打开Cursor，先让Cursor帮你总结下代码功能
告诉Cursor员工：帮我看看我的所有代码，告诉我这个项目干了什么？
- 让代码在本地运行起来
总结完之后，我们需要把代码在本地跑起来。
因为V0生成的代码是在他们自己的服务器上运行起来的，我们下载下来后，需要重新在本地运行。
告诉Cursor员工：帮我在本地运行这个项目。
Cursor员工一顿操作后，终于搞定了。
运行命令：npm run dev
就会给你一个地址：
鼠标移动到上面，单击就可以打开，看到网站效果。
如果这时候出现问题，比如网站打开报错，直接截图告诉Cursor员工，同时把终端里的报错信息告诉Cursor员工。
一遍不行两遍，两遍不行三遍，直到修复成功。
- 选择合适的API
