即刻App年轻人的同好社区
下载
App内打开
江流儿_MIuY
1k关注898被关注2夸夸
intp
NLP算法工程师-关注AIGC和出海,ai金融
漫无边际BoundLess播客主理人
公众号:江流儿的异世界
置顶
江流儿_MIuY
2年前
关注AI和播客~
播客相关:

1、justpod npr 播客制作workshop m.okjike.com

2、第五届播客节会员内场 m.okjike.com

AI相关:

1、ai硬件+宠物 m.okjike.com

2、ai产品经理 m.okjike.com

3、AI端侧模型应用 m.okjike.com

4、ai产品经理应该要怎么做--文君 m.okjike.com

5、sora或者说文生视频给未来的启示,可以说非常棒!非常值得一看,基本上涵盖了文生视频对影视创作的深度认知和未来影响 m.okjike.com

6、第一届互联网AI社群春晚前期圆桌座谈文字转播重点版。 m.okjike.com

7、给普通人的AI指南

m.okjike.com

8、吴恩达:如何用ai构建你的职业 m.okjike.com

9、ai做ppt。m.okjike.com

10、卡兹克直播笔记 m.okjike.com

11、The AI PM's Playbook:2025 年顶尖产品经理如何将影响力提升 10 倍

12、ai创业存活下去的六大路径:m.okjike.com

江流儿_MIuY发表了动态:推荐阅读:《The AI PM's Playbook:2025 年顶尖产品经理如何将影响力提升 10 倍》 这篇文章围绕“产品经理如何在 2025 年通过 AI 提升 10 倍影响力”展开,主要内容包括: 1. AI 产品经理的三种类型 - AI-powered PM(AI 驱动的 PM):每位 PM 都需使用 AI 作为工作助力。 - AI PM(专职 AI 的 PM):专门在 OpenAI、Anthropic 等公司构建核心 AI 产品。 - AI feature PM(负责 AI 功能的 PM):为现有产品添加 AI 功能(如 Notion AI、Miro 智能画布)。 2. 正确使用 AI 的 3 条规则 - 提示词(Prompt)技巧至关重要:熟练掌握如何向 AI 提供清晰、上下文丰富且结构合理的提示词。 - “20-60-20” 法则:前 20% 提供关键背景,中间 60% 让 AI 生成主内容,最后 20% 由人做提炼、修改与补充。 - 迭代至拿到满意结果:通常需要多次修订,通过给 AI 明确反馈来逐步完善输出。 https://baoyu.io/translations/the-ai-pms-playbook?continueFlag=b427fccc8874cc0a1217abbd7655bb5d 来源于宝玉

26
江流儿_MIuY
09:26

Yibie: Karpathy 的 AutoResearch 项目最近挺火的。但说实话,大多数人只看到了"让 AI 自动跑实验"这个表面,没看懂背后的方法论其实可以应用到任何领域。 我花了点时间拆解这个项目,发现它其实提供了一套通用的实验思维框架。不只是搞机器学习的能用,做产品的、做营销的、甚至优化团队会议都能用上。 ## 1. 让专家定标准,让系统去试错 传统做实验的方式是人类自己上:设计实验、执行、分析结果、决定下一步。Karpathy 的方案是倒过来的——人类只负责制定"什么是好"的标准,剩下的让系统自动完成。 这在 AutoResearch 里体现为 program.md(人类写的规则)和 http://train.py(AI 改动的代码)的分离。 但这个思路放到其他领域一样好用: 做广告的可以让设计师定义"好广告 = 点击率 > 5%,且符合品牌调性",然后让系统或实习生批量生成 100 个标题+图片组合去测试。做产品的可以定义"好设计 = 用户完成率 > 80%,步骤不超过 3 个",然后自动调整界面布局做 A/B 测试。 关键是把"判断权"和"执行权"分开。人类擅长定性判断,机器擅长大规模定量试错。 --- ## 2. 时间盒约束:不要最优,要够快 Karpathy 有个洞察挺有意思:不要问"什么是最优解",要问"在 5 分钟内能找到什么好解"。 AutoResearch 每次实验严格跑 5 分钟就停。这不是抠门,而是一种设计选择——约束会逼你找到更聪明的捷径。 不同类型的约束适用于不同场景: - 时间盒(比如 5 分钟、1 小时、1 天):适合需要快速迭代的领域,强制你试错而不是过度优化 - 预算盒(比如 100 元、1000 元):适合商业实验,逼你选择高性价比方案 - 数量盒(比如 10 个版本、100 次尝试):适合创意生成,强制多样性避免局部最优 - 样本盒(比如 100 个用户、1 个区域):适合市场测试,降低失败成本 对比一下两种思路: 传统的做法是"我们花 3 个月做个完美版本再发布"——风险在于做完了可能发现没人要。 AutoResearch 的思路是"我们用 1 周做 10 个粗糙版本,每个测 100 个用户"——快速找到方向,失败成本极低。 --- ## 3. 找到你的"北极星指标" AutoResearch 用 val_bpb(验证集 bits per byte)作为单一指标。这个数字小了就保留改动,大了就回滚。没有讨论,没有纠结。 复杂世界被压缩成单一数字,决策速度指数级提升。 这听起来过于简化,但实际操作中极其有效。关键是找到那个真正重要的指标。 举几个例子: - 写作领域:别纠结"深刻、有趣、易懂"这些模糊标准,直接看完读率 × 分享率 - 招聘领域:别空谈"能力强、文化匹配、有潜力",直接看试用期内绩效评分 - 选址:"人流大、租金低、竞争少"三难全,不如直接用月营收除以月租金 - 营销:别纠结"有创意、有传播、有转化",直接算 ROI 好指标有三个特征:能测量、当天或实时知道结果、单一不需要权衡。 --- ## 4. 实验也需要"后悔药" AutoResearch 用 Git 分支管理实验。尝试 A 失败了就丢弃,尝试 B 成功了就合并到主干,然后基于 B 继续尝试 C。 这听起来是技术细节,其实是一种思维方式:任何尝试都要有"回退"机制。 不会用 Git 的人也能实践这个思路: 写文档的可以用版本历史,或者养成"另存为 v1、v2、v3"的习惯。做设计的可以用 Figma 的版本历史,或者复制画板保留旧版本。定商业策略可以写决策日志,限定可撤销的试点范围。培养个人习惯可以做 30 天试验 + 日记记录,不行就换。 关键是不要因为害怕失败而不敢尝试——反正随时可以回到上一好状态。 --- ## 5. 设计"不用人在场"的系统 program.md 里有一句指令很有意思:"NEVER STOP... The human might be asleep"。 核心理念是把"人必须在场"变成"人可以不在场"。 这需要设计一个完整的自主循环: 首先是触发器——什么情况下开始一轮实验?可以是时间驱动(每天早上 8 点)、事件驱动(新数据来了)、或条件驱动(指标下降了)。 然后是执行器——具体做什么?要有明确的动作清单、出错怎么处理、资源够不够。 接着是判断器——怎么算成功?怎么算失败?最坏情况怎么优雅降级? 最后是记录器——每次尝试都要记,为什么做这个决定也要记,方便事后复盘。 这套机制搭好了,你就可以去睡觉,让系统自己跑。 ## 实战:用这个框架优化团队会议 光说理论没意思,看个实际例子。 假设你们团队每周例会太浪费时间,想优化。很多人不知道怎么下手,或者用"感觉"试错。 用 AutoResearch 框架这么干: 先定义实验空间——哪些东西可以调整?比如会议时长(30/45/60 分钟)、参与人数(全员/代表制/自愿参加)、议程结构(先信息同步后决策讨论,还是只讨论预提交议题)。 然后明确固定约束——什么不能动?比如每周一次周三下午、必须有会议记录、关键决策者必须在场。 接下来找到北极星指标——怎么算"好"?可以用会议满意度评分(1-5 星)和决策效率(议题闭环率)。 设定资源盒——打算投入多少资源试错?比如 4 周试验期、每周试 1 种新形式、固定 8 人团队参与。 最后是决策规则——什么时候保留新形式?比如满意度 ≥ 4.0 且闭环率 ≥ 80%。什么时候放弃?满意度 < 3.0 或有人明确反对。 跑 4 周下来,你会有一个明确的"最佳会议形式",而且是数据支撑的,不是拍脑袋定的。 ## 几个关键的心智转变 这套框架要求你改变一些固有观念: - 从"我要找到最优解"变成"我要在有限时间内找到足够好的解" - 从"人必须参与每一步"变成"人监督,系统执行" - 从"失败是坏事"变成"失败是数据,快速失败是优势" - 从"专家直觉判断"变成"指标驱动决策" - 从"做完美再发布"变成"快速试验,快速学习" ## 一句话总结 AutoResearch 的本质是用"可计算的成功标准 + 严格的资源约束 + 版本化的试错机制",把探索优化过程从"专家的手工艺术"变成"可自动化的大规模实验"。 这套思想不只适用于机器学习。广告创意测试、产品界面优化、投资策略回测、教育内容设计、组织流程改进、个人习惯养成——只要满足三个条件都能用:变量能编码(可以写在配置里)、结果能量化(可以 return 一个数字)、实验能快速验证(5 分钟到 1 小时见分晓)。 *基于 Karpathy 的 AutoResearch 项目分析 (http://github.com/karpathy/autoresearch)*

00
江流儿_MIuY
2天前
上周末去了一场openclaw活动做分享,一下子有300多人加我,因此创建了2个openclaw群,现在1群251个人,2群170,目前2群还能通过二维码的方式进入,养虾的朋友可以进。
00
江流儿_MIuY
5天前
notebooklm做PPT简直太牛了🥺🥺🥺
这将是我唯一推荐的做PPT的平台。
30
江流儿_MIuY
5天前
1、agent编程工作流
2、agent自主经济
00
江流儿_MIuY
6天前
在真正有价值的地方建立自己的核心壁垒,而不是在人多的地方内卷。
00
江流儿_MIuY
7天前
咋啦分享了自己独立上架了一款产品的心得。

我整理了下,内容非常好。有认知有实践。👇👇👇

我的首个独立产品上线复盘:Coding 不等于 Shipping

最近,我第一次端到端地独立开发并上线了一个录屏工具——Excelicord。(大家现在看到的这个视频,就是用它录制的)。

之前在 Gemini 3 发布的时候,我曾用 AI 生成过很多前端 Demo,但那些大多只是原型;我也曾参与过产品上线,但都是与程序员合作。而这一次,是我完全没有程序员协助,仅依靠自己和 Claude 共同完成并上线的真正产品,目前已经有很多朋友在使用了。

借此机会,我想和大家分享一下我在 Web 开发方面的一些核心心得。

1. 最大的感悟:Coding ≠ Shipping
Vercel 的 CEO 曾发过一条推文,我深表认同:“我们要学会去 Shipping(交付上线),因为 Shipping 和 Coding 是两种完全不同的技能。”

Shipping 不仅仅是写代码,它还包含了设计、测试、讲故事、用户教育、营销推广以及转型迭代等。作为独立开发者,你的工作远不止写代码。AI 可以把代码写得很好,但剩下的 Shipping 工作依然需要你自己来完成。

在开发 Excelicord 时,我大约只有 30% 的时间在做功能本身——很多功能只要给 Claude 几个提示词就能写出来。但我有 70% 的时间都花在了 Shipping 相关的“系统打通”上。

虽然这是一个很简单的工具,但它背后串联了 8 个系统:

AI 编程:Claude (或 Claude Code)

数据库:Supabase

部署:Vercel

邮件服务:Resend API

域名:Namecheap

数据分析:PostHog

账号系统:Google Sign-in

支付接入:Stripe

如果只是做一个工具给自己用,你只需要一个 AI 编程工具让它在本地跑起来就行;但如果你要 Shipping 给用户用,你就需要把上述这七八个系统全部打通。这两者的难度完全不在一个级别。

此外,由于我全程不碰代码,全靠给 Claude 写提示词,我的绝大部分时间都在等待输出和测试。产品上线后你会发现,用户的使用环境千奇百怪。比如一个 Web 产品,在 Chrome 里很正常,在 Edge 里可能就会报错或出现性能问题。这些坑,只有在你真正把产品 Shipping 出去之后才会发现。

2. 善用 AI 的搜索与深度研究能力
在使用 AI 编程时,我们经常会遇到它聊了好几轮也解决不了的 Bug。这时候,我会让它直接去网上搜索一下别人是怎么解决的——因为大概率我不是第一个踩这个坑的人。

根据我的经验,十次里有八次,它上完网之后就能直接把问题解决掉。Claude 具备网络搜索和深度研究的能力,大家一定要好好利用。自己解决不了的,就让它去查。

3. 让 AI 参与前端设计,多版本迭代
如果你想做出一个好看的产品,一定要调用 AI 的前端设计能力,并且让它多做几个版本。你可以让它生成一个 Playground,在里面提供各种不同的 UI 版本供你挑选和比对。

4. 给 Web 开发初学者的两条建议
定义好范围,先从“给自己做产品”开始:不要一开始就挑战周期太长或太难的项目。挑一件简单的事情,先给自己做一个好用的工具。因为这能让你更容易获得正反馈,迅速上手。

学会站在巨人的肩膀上:比如我的这款录屏软件,其实是基于开源的白板工具 Excalidraw 开发的。我不需要从零去造一个白板,只需要直接接入它已有的功能,然后在它的基础上增加录屏模块,难度就大大降低了。多去关注市面上的开源软件、代码库和 API,把它们像拼乐高一样拼接起来,加入你的特色小功能。这会极大降低项目难度,带来更多的成就感。

以上内容来自咋啦的小红书

上线了第一个独立开发的产品 我的4个心得 Coding跟shi... xhslink.com
复制后打开【小红书】查看笔记!
00