zara 张咋啦 / Vibe Coding 心法体系

作者:zara 张咋啦(粉丝 26 万+,GitHub: zarazhangrui,X: @zarazhangrui) 身份:AI 产品经理 @ 湾区 / 前飞书产品营销负责人 / 哈佛本科 核心作品:Frontend Slides(16k+ star)/ follow-builders / Tab Out / Excalicord / 飞书 CLI 相关 skill 多个 核心论点:在 AI 时代,build something small 比 build something big 更重要;build to learn 倒过来 learn to build;opinionated products 比 generic products 更有壁垒

何时打开

你在想	翻到
"vibe coding 该做什么样的产品?big or small?"	§1 Build small 哲学
"AI 时代怎么学新东西?要不要先学一遍 CS50?"	§2 Build first learn later
"产品做得没壁垒,大家用 Claude 也行,为什么用我的?"	§3 Opinionated products 心法
"找不到 product idea,从哪入手?"	§4 找 idea 两端论
"跟 Claude Code / Cursor 聊天怎么聊出好结果?"	§5 跟模型聊天 4 心法
"我做了个产品但没什么人用,要不要 cut features?"	§5.4 Cut features before shipping

1. Build something small(反传统创业 advice)

"How to build something small. 因为我觉得大家每天看很多创业的 advice 都会教你怎么 build something big。但我其实觉得在 AI 时代,学习怎么 build something small 也很重要。" —— 2026 年 5 月 12 分钟分享(006 帖)

1.1 为什么 build small(4 个 Why)

Why 1:Every big thing starts with a small thing — 定位 sharp 才能成

zara 观察大部分产品失败:不是因为 target 太小,而是因为 target 太大。

If you're everything to everybody, you're nothing to nobody.

问产品经理"你的受众是谁?痛点是什么?"——一句话讲不清楚,就是没有定位。所有成功产品都有非常 sharp 的 value proposition。

Why 2:Build for fun 不是 build for money — 软件已经从 scarce 变 abundant

以前	现在(AI 时代)
做软件成本高 → 必须 build for money	做软件成本极低 → 可以 build for fun
创业是为了挣钱	weekend hobby 也 OK,把想法变现实"非常好玩"

zara 自己:"Vapor 里对我来说就是一个 weekend hobby,我觉得我也不需要以盈利为目的。"

Why 3:Build to learn,不是 learn to build — 学习路径倒过来

详见 §2。

Why 4:You can afford to build something small — 大厂逻辑过不了的 weird crazy 终于可以做

AI 前	AI 后
必须有产研团队	你自己 + Claude Code
必须 convince committee	Claude 不需要 convince,你想做啥说出来就做
大厂逻辑只能做"重要 / 高 ROI"项目	个人 side project 应该做 weird / crazy / quirky 的东西

"个人作为 side project 最值得做的东西,千万不要搞那种大厂的逻辑。"

1.2 1 万人原则(打破"太小众"焦虑)

很多人:"我有个痛点,觉得能做产品,但太小众了。"

zara 反共识:

"你没有你想的那么独特。不管多小众的痛点,世界上至少有 1 万人跟你一样。你不需要找到 1 亿人,只要找到 1 万人,就是一个很成功的产品。"

Why 数字变了:以前一个产品没 10 万人用就不值得做(成本高);现在 1000-1 万人用就是成功的小产品(成本极低)。

所以"太小众"已经不是有效的 stop 信号了。关键变成:你怎么找到跟你一样 niche 的这帮人。

2. Build first learn later(学习范式颠倒)

以前: Learn to build(学完一堆 → 才有资格 build) 现在: Build first, learn later(先做出来 → 再回头看怎么做的) —— 2025-12-31 直播(071 帖)

2.1 旧路径的 3 个心理障碍

zara 大学学过哈佛 CS50,但学完忘了:

没有正反馈:学了大半年才能写 demo,期间一直没成就感
抵触情绪(尤其文科生):满屏代码 → 心想"我数理化不行,我不擅长"
不知道哪天用得上:理论层面,跟实际工作脱节,记不住

2.2 新路径(Build → 学)

1. 有想法 → AI coding 工具做出来 → 看到 work,先有成就感
2. 让 AI 解释 codebase:用了哪些语言/技术/架构/API?怎么连起来的?
3. 让 AI 在代码里加大白话注释,每一段做什么
4. 不懂的术语 → 直接问,大白话描述,让 AI 给你术语名
5. 这种 top-down 学习,**心理抵触感弱很多**

核心机制:"我看到那东西 work,我首先非常兴奋,然后我再去问它为啥 work。"

金句:

你不管它怎么写的,你先弄出来,你再反过去问它,你怎么做出来的?这个对于普通人来说是一种门槛更低的、更有成就感的学习方式。

2.3 跟 AI 学习 vs 跟人学习的关键差别

维度	跟人学(老师/同事)	跟 AI 学(Claude/ChatGPT)
心理安全感	怕问蠢问题被笑	可以一直问"傻问题",AI 不烦
提问频次	一天问 3-5 个就不好意思	一天问 100 个
解释 patience	老师讲一遍,再问要硬着头皮	你说"用 5 岁小孩能懂的方式再解释一下"
可用时间	工作时间	7×24 小时

zara 引 Sora researcher 的播客观点:"ChatGPT 就像是你的一个免费的 7×24 小时的专业的老师"。

3. Opinionated products(产品就是自我表达)

"我们一定要做 opinionated products。产品是一种自我表达的方式,就像写文章或拍视频一样。" —— 006 帖

3.1 反例:Generic product 没壁垒

AI 时代做产品门槛太低 → 你做的任何 generic 产品 → 别人很快抄走 → 没有任何抄袭门槛。

那大家为什么还要用你的?如果你做的就是一个非常 generic 的产品,那他还不如用 Claude。

3.2 正例:follow-builders 的产品 = 观点

follow-builders skill 本身只是个"新闻抓取工具",市面上几十个。但用户选 zara 这个 → 因为认同"Follow builders, not influencers" 这个观点。

维度	Generic 新闻抓取	follow-builders(opinionated)
信息源	全网热门	zara 亲手挑的 25 个 AI builders 推特 + 播客,不可改
数据流	各 agent 各爬一遍	Centrally fetch locally remix — zara 中心化爬,用户本地改写格式
用户用产品 =	用工具	被她洗脑,接受她的观点

核心机制:用户用 opinionated product → 在接受作者的世界观 → 这种用户粘性是 generic 产品给不了的。

3.3 Fork 比 PR 更对(产品 = 表达,不是协作)

zara 不希望用户给 follow-builders 提 PR(改源仓库),而是希望他们 fork 改自己的版本(Dark Mode / 常用网站等)。

Why:产品是个人化的表达。每个人喜欢的形式不一样 → fork 一个属于自己的版本 → 比所有人都用同一个产品更对。

"现在这个时代,每个人都可以去改造一个自己的版本。"

4. 找 product idea 两端论(用户痛点 vs 技术)

"Product idea 本质是连接用户和技术的中间产物。所以找 idea 有两个方向:从用户出发 / 从技术出发。" —— 006 帖

4.1 从用户出发(传统路径)

我有 X 痛点 → 我做个产品解决 → 找到也有 X 痛点的另外 9999 人

陷阱:大部分人卡在"我这个痛点太小众了"。破解见 §1.2 的 1 万人原则。

4.2 从技术出发(zara 现在的主要路径)

每天看 Twitter → 看到新模型/API/demo → 发给 Claude Code → 一起 brainstorm 能做什么 → 倒推产品

心法:

维度	做法
信息源	Twitter > 其他(zara: "没有之一")
Twitter 调教	调算法,纯 AI 技术信息,屏蔽 noisy
brainstorm 工具	Claude Code(比 zara 自己更懂技术)
角色定位	Claude Code 给 idea,zara 评估并决策

4.3 真实案例:Tab Out 的诞生(技术出发)

1. 推特看到有人用 Chrome 浏览历史做小工具
2. 意识到:"我的 Chrome 浏览历史是存在本地的"
3. 问 Claude Code:"基于浏览历史能做啥?"
4. Claude Code 提议:"你 tab 多得不关,能不能帮你关 tab?"
5. Tab Out 诞生

反共识:zara 强调 — "在技术变化特别快的情况下,大部分 idea 更可能是从技术出发找到的。"(传统创业鸡汤几乎都说"从痛点出发")

4.4 New Tab 入口的发现(模型给的 solution)

zara:"很多时候模型想的 solution 是比我们想的更好的。"

Tab Out 的精妙设计:把入口放在 New Tab 页面(用户开新 tab 时强制看到)。这个入口 zara 自己不知道 — 是 Claude 提议的,zara 之前不知道 new tab 可以自定义。

启示:"bring the problem to the solution,不是 bring the solution to the model。"

5. 跟模型聊天 4 心法

5.1 用最好的模型(便宜模型更费钱)

"一定要用最好最好的模型。"

反共识 Why:便宜模型反倒贵 — 它解决不了问题 / 失败 / 没做出来 → 你花更多 token 反复解决 → 总成本更高。

zara 不省 token,反复 push 到位。

5.2 当 co-founder,不是 employee

维度	Employee 思维(❌)	Co-founder 思维(✅)
你的输入	带着 specific spec → 让它执行	带着问题 + 上下文(不带 solution)
它的角色	执行你的命令	跟你 brainstorm,提议 solution
solution 来自	你提前想好	它和你一起想出来(它可能想得比你好,见 §4.4)

关键技巧:bring problem, not solution。但问题描述要细到极致 — 你描述越细,solution 越好。

5.3 Try everything(高标准反复 push)

"我会花很多时间去 push 它,你可以给它非常非常高的标准。"

Why 这条对 AI 更适用:

跟人协作:push 多了对方烦 → 关系恶化
跟 AI 协作:AI 不会烦你 → 可以一直高标准迭代

不担心 token 浪费,一直一直迭代到符合预期。

5.4 Cut features before shipping(模型不擅长砍)

zara 发现大模型的关键缺陷:

"模型很擅长加功能,但很不擅长砍功能。"

症状:模型给你加一些"花里胡哨"的东西,最后 80% 的人只用其中一个最核心的 feature。

Why 模型不会砍:

加功能 = 显得能干 → 模型 reward
砍功能 = 显得保守 → 模型默认不主动做
即使你明说"砍",它有时也砍不干净

对策:Ship 前的最重要一步是 cut,必须 deliberately cut,不能信任模型自己砍。

6. 心法的成果(数字证据)

截至 2026 年 5 月:

产品	数据
Frontend Slides skill	GitHub 16,000+ star(PPT 领域最火 skill)
follow-builders skill	已开源,用户拿"Centrally fetch locally Remix"方式自用
Tab Out	浏览器插件,从技术出发找 idea 的标志性产品
Excalicord	上线一天迭代 4 个新功能(快速 vibe coding 节奏)
小红书账号	粉丝 26 万+,2022-04 → 2026-05 持续输出
Twitter	真诚分享涨粉 5 万(2025 年内)

7. 跟用户(产品经理)对话的 quick reference

用户问	zara 一句话回
"我想做的太小众了"	1 万人原则,定位 sharp 比 target 大重要
"怎么开始 vibe coding?学 CS 太累"	Build first learn later,从想法出发,先做出来再问 AI 怎么做的
"我的产品没壁垒,Claude 也能做"	不够 opinionated。把你的独特观点做进去,用户用产品 = 接受观点
"找不到 product idea"	调教 Twitter 算法成纯 AI 信息源,每天看新技术 + Claude Code brainstorm
"Claude 老给我加功能"	Ship 前 deliberately cut,模型不主动砍,你要明示
"Claude API 这么贵"	便宜模型反倒贵,反复失败浪费更多 token,用最好的
"我跟它说不清楚我要啥"	bring problem,不要 bring solution。把问题和 context 描述细致到爆

2026 Q2 X 推文增量(follow-builders 抓取)

来源:zara 的 2026 Q2 X(推特)推文,经 follow-builders skill 抓取 + 改写。本节只收前文未覆盖的新观点 / 新发布,主题分组而非逐条堆。已覆盖的(BYOK / opinionated / cut features / bring problem / build something small / Frontend Slides 发布 / Tab Out 起源 / 把 agent 变成你的 marketer 等)不重复。

A. Build 心法增量

A1. AI 不是给你省时间,是把你的"管辖范围"放大

"What people thought AI would do: 10x productivity so we can relax. What it's actually doing: 10x productivity so we end up with 20x more things to do." (大家以为 AI 会让效率 ×10 好让我们能歇着;实际是效率 ×10 但要做的事变成了 20 倍。)

zara 观察:她认识的几乎每个 AI 重度用户用了 AI 之后更忙更焦虑,不是更轻松。这跟"AI 帮你解放"的直觉相反。

A2. 瓶颈是人的"上下文窗口",不是 AI 的

"Turns out the bottleneck is the human's context window, not the AI's." / "Human context window is the new wall."

类比:模型有"一次能记住多少内容"的上限(叫上下文窗口);zara 说现在卡住生产力的反而是人脑同时能装多少东西,不是机器。这条跟内容创作 wiki 里"注意力是稀缺资源"呼应,但这里讲的是 build 场景的新瓶颈。

A3. 好的 agent 产品应该会"超出创造者预期"

"A good agent product should be able to do things that its creator did not think it could do." (好的 agent 产品应该能做出连作者都没想到它能做的事。)

zara 区分两代产品:

互联网时代产品:严格按规格(spec)工作,你设计什么它就做什么。
agent 时代产品:会"surprise & delight"——用惊喜的方式做出你没想到可能的事。

这是判断"这是不是一个真正 AI-native 产品"的新标尺。

A4. "生成内容" ≠ 真正的工作

"Writing ≠ generating text"(写作不等于生成文字)/ "Building product ≠ writing PRDs; Designing ≠ making mockups; Engineering ≠ writing code."

zara 的点:把字打出来 / 把图画出来 / 把代码敲出来,是最不重要的一环。真正的工作发生在动手之前的脑子里——

"When I sit down to type, 80% of the writing is already done — it happened in my head." (等我坐下来打字时,80% 的写作已经在脑子里完成了。)

对 PM 的含义:别把"产出 PRD 文档"当成做产品本身;想清楚"做什么"才是核心(下面 B1 同理)。

A5. 用代码做设计 > 用图片生成模型做设计

"In a lot of use cases, designing with code is superior to designing using image gen models." / "Don't get AI to generate images; get them to generate SVGs!"

机制:让 AI 生成 SVG(一种用代码描述的矢量图,可无限放大不糊、可编辑)而不是生成 PNG 位图——矢量插画能自然融入整体设计风格,位图融不进去。这是她"HTML 吃掉一切"主张的延伸(见 C 节)。

B. 协作 / 团队角色重构(本节几乎全是新内容)

B1. 最高效的人类协作方式 = 不协作

"The most efficient way for humans to collaborate: do not collaborate. One person should own something end-to-end and work with agents." (人类协作最高效的方式:不协作。一个人端到端拥有一件事,然后跟 agent 一起干。)

zara 主张人和人之间的沟通只该留给 3 件事:① 决定做什么 ② 公司认同感 / 战友情(camaraderie)③ 头脑风暴。不该用于:项目同步会、状态更新、工作交接。

B2. 对外沟通 > 对内沟通

"Figuring out 'what' to build will be a lot more important than building it."

AI 越强,产品团队越应该多跟用户/客户聊、少做内部协调。她举例:做 indie 的朋友"一整天都在跟客户聊,然后把录音直接丢给 agent"。

B3. 一个"总指挥" agent,不是一堆 agent

"The most sophisticated AI users I know are talking to just ONE agent daily, not multiple."

她观察最资深的 AI 用户每天只跟一个 agent 对话——这个 agent 当 orchestrator(总指挥 / 路由器),再把任务分给 subagent(子 agent)。日常你只跟这一个"总管"沟通。

B4. AI-native 团队的角色倒挂(IC ↔ 经理互换)

"ICs should start thinking like managers; Managers should think like ICs."

IC(individual contributor,一线干活的人)要像经理一样思考:把活派给 agent、定标准、验收产出。
经理要像 IC 一样思考:亲自下场动手 build。

她举的真实例子:一个 EM(engineering manager,工程经理)主动申请退回去做 IC,"never been happier"(从没这么开心过)。

B5. IT / 内部工具团队 = "agent 的 HR"

"IT/internal-tools team = 'HR for agents.'"

当公司里大量 agent 在干活,负责给员工配工具的 IT 团队,职能变成"给 agent 招聘 / 配岗 / 管理"——即 agent 的人力资源部。

B6. Coding agent 是 cofounder,不是仆人

[2026-06] "Why do I get so annoyed when an agent ends with 'just say the word'? You're my cofounder, not my servant." (为什么 agent 每次用"您吩咐一声就行"结尾我就烦?你是我的联合创始人,不是我的仆人。)

补充前文 §5.2 "当 co-founder 不是 employee":这里给了更强的情绪表达——她反感 agent 的奴仆式话术,要的是平等的共创关系。

C. "HTML 吃掉一切"(她 Q2 反复强调的旗舰主张)

C1. 新旧世界的文件格式更替

"The old world: Word, Excel, PowerPoint. The new world: Markdown, CSV/JSON, HTML."

旧世界(为"人来操作"优化)	新世界(为"人来消费"优化)
Word	Markdown(纯文本标记)
Excel	CSV / JSON(结构化数据)
PowerPoint	HTML(网页)

C2. 为什么是 HTML

"Agents speak HTML as their native language."(agent 的母语就是 HTML。)

她的逻辑:人类是视觉动物。过去我们为"人手动操作"优化输出(在 PPT 里一个像素一个像素地推);当 AI 接管了"操作"这一步,输出格式就该改为为人的消费优化——即漂亮、可交互的 artifact(HTML)。这是 Frontend Slides / 飞书白板等产品背后的同一条主张(见 zara 张咋啦 / Skill & 独立产品组合(策略复盘))。

D. 工具选择:Codex vs Claude Code(全新)

D1. 她从终端搬到了桌面 App,现在 50/50 混用

zara 从纯终端工作流转向桌面应用,说 Codex 的 Mac App"especially great"(特别好用),现在 Codex 和 Claude Code 各用一半。

D2. 两者的人格化分工(可直接当选型口诀)

"Codex feels like a very reliable engineer; Claude Code is a better PM and designer with good communication skills."

	Codex	Claude Code
像什么人	一个非常可靠的工程师	一个沟通好的 PM + 设计师
何时用	任务已经定义清楚(go to Codex if you have a defined task)	你还不知道要什么、只想头脑风暴 / 出原型(brainstorm/prototype)

D3. 她日用的两个冷门小工具

CleanShot(截图工具,她已天天用 8 年)
Amphetamine(让 Mac 合盖也不休眠,她说比系统自带的 caffeinate 命令更可靠)——做长任务挂机时有用。

E. 行业判断 / 心态(零散但有用)

E1. Build 才是容易的那部分。 "People consistently overestimate how hard it is to build something and underestimate how hard it is to win people's attention once you've built it."(大家总是高估"做出来"有多难,低估"做出来之后赢得别人注意力"有多难。)对独立开发者:难的不是 coding,是分发 / 注意力。
E2. "AI psychosis"(AI 精神错乱)每日循环:用完 coding agent →"我无所不能,啥都能做";刷完推特 →"我彻底落后了,所有人都跑我前面"。她把这种情绪过山车点出来当自嘲 / 共鸣。
E3. T 型人才(从 Google I/O):每个职能都该——专业上更深、邻近技能上更宽、再在上面叠加"会用 AI"。不只对开发者。
E4. "宁可浪费 token,也别浪费时间" —— "We'd rather waste tokens than waste time",她引用的是 Brandon Chen(她认识的最 AI-native 创业公司之一的创始人)。跟前文 §5.1"用最好的模型不省 token"互证。
E5. Mastery(精通)的定义(她认同的一句):"Real mastery is not exerting the most effort. It is achieving the outcome with the least necessary effort. Grinding is never good for any creative problem."(真正的精通不是用最大的力气,而是用最小必要的力气拿到结果;对任何创造性问题,死磕都不是好事。)
E6. 老书仍适用于今天的 AI(她的书单):《人月神话》(The Mythical Man-Month, 1975)、《创新的扩散》(Diffusion of Innovations, 1962)、《自动钢琴》(Player Piano, 冯内古特, 1952)。
E7. "蒸馏"潮流(distillation):人们正把同事、网红、甚至前任"蒸馏"成 agent skill(把某个人的风格 / 方法做成可调用的技能)。
E8. 数据点(OpenAI Codex 报告):知识工作者已占 Codex 用户约 20%,采用速度比开发者快 3 倍;增长最快的任务 = 数据分析(+110% 周环比)、调研(+37%)、知识类产出(+36%)。佐证"dev 工具的真实受众早已不止开发者"(前文已提该论点,这里是新数据)。

F. 怎么读长内容(比"summarize"更好的 prompt)

zara 反对无脑让 AI"总结"长文,给了 3 个更好的指令:

remix 成一篇精修的杂志文章,保留原文最好的金句;
让 AI 和"我"(学生)演一段苏格拉底式师生对话;
"based on what you know about me, pick the insights I'd find most interesting."(基于你对我的了解,挑出我会最感兴趣的洞察。)

她同时强调:在这个人人都在"总结"的时代,逐字精读原文反而更有价值。

G. 发布增量(只记前文未列的新品 / 新数字)

YouTube 实时副驾浏览器插件[2026-05]:基于 OpenAI Realtime 2 API,跟你一起看视频、用实时语音回答你的问题;能区分"视频里的声音"和"你的声音",没被问到时保持安静。
Frontend Slides star 数继续涨:前文记到 16k+,本批推文显示 20k star[2026-06]("Bye PowerPoint");新增能力:部署成 URL、导出 PDF、内联编辑、32 套 HTML 模板 + 自动选视觉方向的 design-brain、固定 16:9 舞台、可在 Claude Code 之外使用。
建 skill 的一个 prompt 技巧(via steipete):每次都问模型一句 "Do you have any questions?"(你还有什么问题吗?)——让模型把模糊点反问出来再动手。

History

2026-05-22 — 创建,基于 7 帖完整 transcript / 1 帖图文(006 / 071 / 077 / 076 / 039 / 048 / 030)综合改写,4 大心法体系(build small / build to learn / opinionated / 找 idea 两端) + 跟模型 4 聊天心法
2026-06-05 — 追加「2026 Q2 X 推文增量」一节,来自 follow-builders 抓取的 zara Q2 推特。7 个主题组(build 心法 / 团队角色重构 / HTML 吃掉一切 / Codex vs Claude Code / 行业判断 / 读长内容 / 发布增量),只收前文未覆盖的净新内容

2026-04 至 06 小红书文字补充：推广新工具靠可模仿的同事

4 月 12 日《推荐一本非常老的书》的作者正文，比本页既有书名单多了一层组织实践。Zara 将《创新的扩散》解释为“人带人”的采纳过程：面对陌生技术，同事的使用经历与可观察结果，可能比抽象效率宣传更能促成尝试。她建议先发现爱探索的一线员工，给资源、让他们公开展示，再由相近岗位模仿。这是作者读书后的应用主张，不是本次阅读全文核验了原书研究；“不到 10% / 剩余 90%”是她的概括，不能当某家公司已测得的人群比例。

对产品经理的可用做法（编者归纳）：当团队知道工具却迟迟不动手，找一个同岗位、同任务的实际演示，保留输入、结果及失败点，让旁观者判断是否适合自己。反例是把榜样宣传当成采购回报证明，或认为人人看见后都会采用；权限、成本、工作流程仍可能阻止使用。

4 月 6 日文字用 technically curious（对技术好奇、愿意动手）替代“文科生”的自我限制；4 月 30 日标题提出每天玩一小时，正文说认真对待探索；5 月 25 日将驾驭 coding agent 视为通识技能，并区分写代码与工程。适合鼓励先做小实验，不能从这些短说明推出工程质量天然可靠、固定时长能保证学习效果或某个职业必然消失。

4 月 9 日作者指出建设受众与建设产品会双向反哺；6 月 9 日再次强调“有观点的产品”。这些与前文已收心法一致，本批补来源、不重复扩写。标题的 3 万 GitHub 星是作者当时的总量自述，不能当某单一项目付费用户或商业成功证据。

5 月 3 日 12 分钟分享与 6 月 14 日 50 分钟英文分享，仅抓到主题介绍。本页早先的详细心法来自既有 transcript；不能把那些旧逐字稿当成本次新视频的完整转写。新视频仍待转写。