装了Codex不知道做啥？用「摩擦点思维」找到真实需求

从一条看不清的评论说起

很多人装完 Codex、Claude Code 这类 AI 编程工具后，都会陷入一个尴尬的境地：跑通了 Demo，工具用得也顺手，但每次打开脑子里都是一句话——我到底该让它写点什么？

工具背景：Codex 是 OpenAI 推出的代码生成模型，基于 GPT 架构针对编程任务进行微调，能理解自然语言并输出可运行代码。Claude Code 则是 Anthropic 推出的命令行 AI 编程助手，深度集成终端环境，可直接读写文件、执行命令。这两款工具代表了"Agentic Coding"的新范式——AI 不再只是代码补全工具，而是能端到端完成完整开发任务的执行者。正因如此，它们的上手门槛极低，却也让许多用户在"能做"与"做什么"之间产生了真空地带。

一位 B站 UP 主的经历很有代表性。他在 YouTube 看工具测评时，被评论区那个写死的小字号折磨了整整一年：脸凑到离屏幕不到 20 公分，一条高赞评论看三遍还费眼；评论里夹着一个俚语，英语过了六级也没看懂，只能复制、切标签页、粘进谷歌翻译，一条评论来回四趟。

那天晚上他打开 Codex，半个小时后就有了一个浏览器插件：评论字号可以自己调，翻译直接显示在评论下方。问题解决了，但真正值钱的洞察不在插件本身，而在于如何找到该做什么。

需求描述：别堆技术名词，只讲现象

这个插件的提示词非常朴素，UP 主原样念了出来：

我发现 YouTube 默认的评论字体都太小了，请你给我一个插件，让我可以单独修改评论区域字体的大小，并且可以调用谷歌翻译来翻译相应的评论。

没有技术名词，没有指定前端框架。解决这类日常小问题根本不需要框架，唯一需要注意的是模式选择 Build Web App——浏览器插件本质上就是跑在网页里的那一套代码。

浏览器插件原理：Chrome 扩展程序基于 WebExtensions API 构建，本质上由 HTML、CSS 和 JavaScript 组成，通过 manifest.json 声明权限和入口。其核心能力包括：content script（注入目标网页操作 DOM）、background service worker（处理后台逻辑）和 popup 页面（点击图标弹出的界面）。正因为插件就是"跑在网页里的那套代码"，AI 生成时选择 Build Web App 模式完全合理——生成结果无需额外编译或环境配置，即可直接加载运行。

这里藏着 Vibe Coding 的核心心法：你不用懂技术，把现象描述清楚就行。 AI 写代码不是一次成型，好处恰恰在于你只需描述现象，它自己会迭代修改。

什么是 Vibe Coding：这一概念由 AI 研究者 Andrej Karpathy 在 2025 年初正式提出，核心主张是：开发者无需深究每一行代码的实现细节，只需用自然语言描述意图，让 AI 完成具体编写与调试，人类负责把控方向和验收结果。这一理念的兴起，本质上是 AI 编程能力成熟后对"人机协作边界"的重新划定——人的价值从"写对代码"转向"提出正确问题"。它不是编程能力的退化，而是编程入口的民主化。

部署简单到出乎意料

生成代码后，打开 Chrome 扩展程序页面，右上角开启开发者模式，把整个代码文件夹拖进去，插件立刻可用。刷新 YouTube，右上角就多出一个图标——不用注册、不用付费、不上架商店。这种「即写即用」的自用工具，是 AI 编程时代最容易被低估的应用场景。

灵感从哪来？答案藏在「摩擦点」里

工具越用越顺手，就越容易陷入「拿着锤子找钉子」的困境。UP 主指出：项目想法只有两个来源。

第一个来源：你自己的摩擦点

注意，他强调的不是「需求」，而是摩擦点——那些你每天都在做、每天都做得别扭、别扭完又默默忍下去的动作。

摩擦点的概念来源："摩擦点"（friction point）这一概念源自用户体验设计领域，指用户在完成目标过程中遭遇的阻力或不便。精益创业方法论中的"问题访谈"、Y Combinator 的"做用户自己想要的东西"等经典框架，本质上都在寻找高频、真实的摩擦点。过去这类小摩擦点因"解决成本过高"而长期被忽视——雇开发者太贵，自学技术太慢。而 AI 工具将执行成本压缩至数小时后，原本属于"长尾痛点"的问题，首次具备了被系统性解决的可能。

比如放大字体、复制去翻译，这两件事他忍了整整一年。为什么忍？因为太小了，小到不值得专门搜一款软件来解决。以前这类需求就是这样被吞掉的：解决它的成本，远高于忍受它的成本。

而现在，AI 半小时就能把它搞定。这意味着我们需要换一个思维习惯：别想「我能做什么产品」，而是去记录「今天我又忍受了什么」。

他给出了一个非常落地的方法：在备忘录里开一个清单，随手攒一周。 你会发现自己从来不缺灵感，只是灵感从没被写下来过。这个反直觉的结论值得牢记——AI 降低了执行成本后，稀缺的不再是能力，而是「被记录下来的真实痛点」。

第二个来源：别人的摩擦点

自用工具只解决你一个人的问题。别人的摩擦点里，才藏着能打包、能变现的机会。

去哪找？看别人在哪抱怨——小红书、各类贴吧、应用商店的评论区。重点看差评。差评里那句「要是能……就好了」，本身就是一份现成的需求说明书。

差评挖掘的方法论价值：应用商店差评挖掘是硅谷产品团队常用的竞品分析手段。App Store 和 Google Play 的评论数据可通过 Sensor Tower、AppFollow 等工具批量抓取分析，但对个人开发者而言，直接阅读差评同样高效。差评的核心价值在于：用户已经完成了"发现问题→清晰表达"的前两步，开发者只需完成第三步——实现解决方案。结合 AI 的代码生成能力，从发现一条差评到跑通原型 Demo，整个周期理论上可以压缩至数小时内，这在过去是完全不可想象的。

方法也很直接：整段复制给 AI，让它先给出解决思路，再挑一个方向写出来。UP 主把这一步称为「分水岭」——从解决自己的问题，跨越到解决一群人的问题。

小结：AI 编程的真正瓶颈在哪里

这个案例表面在教人做浏览器插件，实际上点破了一个更深的道理：

当 AI 已经能替你写代码时，瓶颈从「怎么做」转移到了「做什么」。技术门槛被抹平之后，能持续产出价值的人，是那些愿意留意生活中细微摩擦、并把它们记录下来的人。

• 自己的摩擦点 → 打磨专属自用工具，提升日常效率
• 别人的摩擦点 → 从差评中挖掘可规模化的产品机会

对所有装了 Codex 却不知道做什么的人来说，这或许是最实用的一课：先别急着写代码，先攒一周你曾经忍受过的小事。

核心要点