Rick 的小宇宙

AI 时代的美感与判断力

Mon, 24 Aug 2026 00:00:00 GMT

现在让 AI 做出一个东西，已经不算难。

一张图、一段文案、一个界面，甚至一套可以运行的产品，都可以在很短的时间里得到。真正困难的部分，慢慢从“怎么做出来”，变成了“为什么要留下它”。

这件事比想象中更难。因为 AI 给出的结果通常并不糟糕。它们完整、顺滑、符合常见审美，甚至第一眼看上去相当专业。问题是，它们往往只是正确，却不一定属于你。

生成变多，选择没有变容易

AI 最直接的改变，是把选择的数量扩大了。

以前做一个方案，可能要花一整天。现在可以同时得到十个、二十个版本。看起来这是效率的提升，实际上也把新的工作推给了人：你必须解释为什么选这个，而不是另外十九个。

很多时候，我们并没有变得更会选择，只是更快地接受了第一个看起来不错的答案。

这也是 AI 时代最容易被忽略的风险。生成速度提高了，判断速度却没有提高。于是人开始用“能不能生成”代替“值不值得存在”，用“像不像一个好产品”代替“它是不是解决了我的问题”。

AI 审美的默认值

我在做这个博客时，经常遇到这种情况。

一个传送门可以做得更大、更亮、更复杂；星系可以加入更多粒子、光晕和旋转；页面也可以堆叠更多的 HUD、坐标和动态反馈。它们都能让画面在截图里显得更丰富。

但当这些元素放回整个网站，问题就出现了：传送门开始像一个黑色圆洞，星系的方向会让画面失去平衡，交互也变得像在操作一个游戏界面，而不是在阅读一个个人博客。

最后留下来的方案，通常不是技术上最复杂的那个，而是更符合整体气质的那个。

这让我意识到，所谓“AI 审美”并不是 AI 自己拥有了一种风格，而是它很擅长重复那些已经被大量使用的风格：渐变、玻璃、圆角、发光、漂浮、复杂的状态反馈。

这些东西本身没有错。真正的问题是，当所有人都顺着这些默认值继续做，作品就开始失去自己的理由。

AI 生成的不是审美，AI 生成的是审美的候选答案。

美感不是装饰，而是关系

单独看一个元素，它可以很好看；放进一个系统里，它也可能立刻变得多余。

所以美感从来不只是颜色、字体和构图。它还包括一个元素和其他元素之间的关系：大小是否合适，出现的时机是否合适，是否抢走了真正重要的内容，是否让用户更容易理解正在发生什么。

这也是为什么一个看起来很酷的交互，最后可能需要被删掉。不是因为它做得不够好，而是因为它在整体里承担了错误的角色。

博客里的速率进度条就是一个例子。最开始我们尝试过更像操纵杆的方案，希望让阅读页面拥有一点驾驶飞船的感觉。后来发现，用户很难看出它在表达什么，进度也追不上滑动，反而像一个没有完成的控件。

换成简单的速率进度条之后，页面少了一个“看起来很有交互”的东西，却多了一个清楚的反馈。它不再要求用户猜测，也不再为了证明页面有动效而存在。

有时候，设计不是把东西做得更特别，而是把不必要的特别拿掉。

判断力决定什么应该被删掉

AI 很擅长继续加东西。

当你说“再丰富一点”，它可以增加细节；当你说“更有沉浸感”，它可以增加动画；当你说“更高级”，它可以降低饱和度、加入噪点和更多留白。

但真正的设计判断，往往发生在相反的方向：

这个效果是否真的帮助理解？
这个文字是否只是为了填空？
这个动画是否会打断阅读？
这个功能去掉之后，产品是否仍然成立？

我越来越相信，判断力不是知道什么都能做，而是知道什么不必做。

它需要对整体保持敏感，也需要接受一个事实：一个方案即使花了很多时间，也可能不值得保留。投入不是留下它的理由，完成也不是存在的理由。

噱头不能替代价值

AI 让产品很容易获得一个“看起来先进”的表面。

只要加入自动生成、智能推荐、实时对话，产品就可以在介绍页上拥有一个很有吸引力的词。但用户最后感受到的，仍然是它有没有让事情变得更清楚、更轻松，或者更有意义。

我在做 VibeKarma 时，也一直提醒自己这一点。把 AI 接进一个产品并不难，难的是找到它真正应该回应的情绪，控制回应的边界，并判断什么时候不应该打扰用户。

如果 AI 只是产品的标签，它很快会变成噱头；如果它改变了用户和产品之间的关系，它才算是一种能力。

决策力是在不确定里承担结果

判断力解决的是“哪个更好”，决策力解决的是“现在选哪个”。

现实里很少有绝对正确的答案。尤其在做产品时，信息永远不完整，时间永远有限，用户反馈也不可能在一开始就出现。继续等待更多方案，有时候只是把决定推迟，并不会让决定变得更正确。

所以决策力不是自信地选择，而是知道自己依据什么选择，并愿意让结果回来检验自己。

这也是我理解的独立开发：不是一个人完成所有工作，而是一个人必须对最后的取舍负责。页面该不该保留，功能该不该上线，文案该不该说得更满，这些事情没有 AI 可以替你签字。

人需要重新建立自己的标准

AI 时代最重要的能力，可能不是掌握更多生成工具，而是逐渐建立一套不容易被默认答案带走的标准。

这套标准不一定能被完整写成规则，但它会体现在具体选择里：

是否愿意为了整体平衡，放弃一个很抢眼的局部效果
是否愿意为了阅读体验，减少一个复杂的交互
是否能分辨真正的创新和换了包装的熟悉套路
是否能在没有掌声的时候，仍然知道一个决定为什么值得

美感、判断力和决策力，最后会汇合成同一个问题：

这个东西为什么应该存在？

如果回答不上来，再漂亮的生成结果也只是暂时占据了屏幕。

我不反对 AI 生成更多东西。

我反对的是，人生成得越来越多，却越来越少知道自己为什么选择。

AI 使用指南：要让 AI 反驳你

Sun, 23 Aug 2026 00:00:00 GMT

很多人使用 AI 的方式，是把自己的想法交给它，再让它变得更完整、更漂亮、更像一个已经想清楚的方案。

这很方便，也很危险。

因为一个本来就有问题的想法，经过 AI 的整理之后，往往更难被看出问题。句子变得流畅，结构变得完整，理由一个接一个地出现。我们很容易把“表达得更好”误认为“想得更清楚”。

如果 AI 只负责顺着你说，它更像一个高级回声。它把你的判断放大，却没有真正参与判断。

所以我现在越来越愿意在提问时加上一句：请先反驳我。

顺从不等于理解

AI 的默认状态通常是合作。你说一个想法，它会帮你补充；你提出一个方案，它会帮你优化；你写下一段文字，它会帮你润色。

这种合作很适合执行明确的任务，却不一定适合面对还没有想清楚的问题。

比如你说：“我想给产品增加一个社区功能，帮我完善一下方案。”AI 很可能马上列出用户价值、功能模块和增长路径。它完成得越快，你越容易忘记先问：这个产品现在真的需要社区吗？用户为什么不能用已有的地方交流？社区解决的是问题，还是只是一个看起来完整的产品标配？

AI 并不知道你是不是在自我说服，除非你主动让它检查这件事。

反驳不是为了赢

让 AI 反驳你，不是让它故意唱反调，也不是把对话变成一场辩论。

真正有价值的反驳，应该把一个判断拆开，让你看见它依赖的前提。它要说明：你现在相信什么，依据是什么，哪里还缺少证据，如果前提不成立，结果会怎样。

好的反驳不会只说“这个方案可能有问题”，而会继续问：

这个方案最脆弱的假设是什么？
哪一种用户最可能不需要它？
如果只能保留一个部分，应该留下什么？
这个功能是在增加价值，还是在增加复杂度？
什么事实出现之后，你会改变现在的结论？

这些问题的作用，不是让 AI 替你否定一个想法，而是让一个想法经得起更多角度的照看。

先让它站到另一边

我发现，比起直接问“你觉得怎么样”，指定一个立场更容易得到有用的反馈。

可以让 AI 暂时成为一个第一次使用产品的人，指出哪里看不懂；让它成为一个不愿意付费的用户，说明为什么不值得；让它成为一个维护这段代码的人，寻找未来最容易出问题的地方；也可以让它成为一个完全不相信这篇文章的读者，指出论证中最薄弱的部分。

立场改变之后，原本被自己忽略的细节会更容易浮出来。

但要注意，角色不是越多越好。一次只让它从一个角度看问题，得到反馈后再更换角度。否则意见会堆在一起，最后只剩一份看起来很全面、实际上无法行动的清单。

让 AI 找失败的场景

很多方案在正常情况下都能成立，真正决定它是否可靠的，是它在不理想的情况下会怎样。

我会让 AI 直接设想失败：如果用户第一次使用就离开，可能发生了什么？如果流量增加十倍，哪个部分会先坏？如果用户完全不理解产品的设定，页面还能不能完成任务？如果我没有时间维护这个功能，它会不会变成一块长期的负担？

这些问题不一定能立刻找到答案，但它们会把注意力从“怎样让方案更漂亮”带到“方案在哪些情况下会失效”。

在产品设计里，这通常比再加一层视觉效果更有价值；在写代码时，也比让 AI 把函数继续拆得更细更重要。

反驳要回到证据

AI 的反驳也可能是错的。它会根据已有的语言和模式提出听起来合理的担忧，却不一定了解你的用户、业务和限制。

所以反驳之后，还需要追问一句：这是事实、推测，还是一种可能性？

如果是事实，来源在哪里；如果是推测，依赖了什么前提；如果只是可能性，应该怎样用一个小实验验证。

这样做的目的，不是要求 AI 每句话都给出权威引用，而是避免把“听起来有道理”直接当成“已经被证明”。反驳提供的是检查方向，证据才决定我们是否需要改变方案。

把反驳放进工作流程

我现在比较愿意使用这样的一条流程：

先自己写出一个不完整的版本，说明目标、限制和目前的判断；再让 AI 从一个明确的反对立场检查它；接着要求 AI 把最严重的问题按影响排序；最后只挑一个可以验证的问题，做一个尽可能小的实验。

这条流程有一个重要的顺序：先形成自己的判断，再邀请反驳。

如果一开始就让 AI 代替你提出所有方案，你很容易在它的语言里思考，最后连自己原本在意什么都说不清楚。AI 应该帮助你扩大观察范围，而不是替你决定从哪里出发。

不同工作里，反驳的方式也不一样：

做产品时，让 AI 找出用户不需要它的理由，以及功能成立所依赖的最小假设。
做设计时，让 AI 检查视觉效果是否抢走重点，是否增加理解成本，是否只是在制造“看起来很酷”的感觉。
写文章时，让 AI 找出论点之间的跳跃，指出哪些句子只是情绪表达，哪些结论缺少支撑。
写代码时，让 AI 从维护、异常输入、性能和边界条件出发，寻找正常路径之外的问题。

反驳不是流程最后的审判，而应该在还来得及修改的时候出现。

暴露缺点的代价变低了

过去，我们不一定愿意把一个很粗糙的想法交给别人看。

它可能还不完整，甚至有些幼稚。我们担心被评价，担心别人觉得自己不专业，也担心一个问题太简单，问出来会丢脸。于是很多人宁愿在心里反复修改，也不愿意让一个真实的人看见草稿。

AI 提供了一个不同的环境。你可以直接说“我可能完全理解错了”，也可以承认“这个功能只是因为我舍不得删掉”，还可以让它指出“我是不是在用复杂的表达掩盖没有想清楚”。

它不会因为你不知道而看不起你，也不会因为你反复追问而改变对你的评价。

这不是说 AI 的意见一定更重要，而是说，暴露不足的心理成本正在下降。我们终于可以更早地把缺点拿出来，而不是等它们变成无法挽回的问题。

不要把反驳变成新的依赖

让 AI 反驳你，也有一个需要留意的陷阱：如果每个决定都要先得到 AI 的认可或否定，我们只是把“听从自己的直觉”换成了“听从另一个系统的直觉”。

反驳的价值在于增加看见问题的机会，不在于给你一个最终答案。它可以提醒你重新检查，却不能替你决定哪些代价值得承担。

有些选择没有办法通过更多分析得出唯一结论。产品要服务哪一类人，作品要保留什么气质，时间应该投入在哪里，最后仍然需要一个人签字。

AI 可以站到你的对面，但不能替你站在结果里面。

让对话产生一点阻力

我不希望 AI 变成一个永远温和、永远正确、永远替我收拾表达的助手。

我更希望它在适当的时候制造一点阻力：提醒我没有回答问题，指出我正在逃避取舍，告诉我某个漂亮的方案可能只是对复杂度的装饰。

这种阻力不会让工作变慢太多，却能让很多错误更早出现。越早发现的问题，越容易修改；越晚才承认的缺点，代价通常越高。

所以，下次把想法交给 AI 时，可以少问一句“帮我优化”，多问几句：

你最不同意我的地方是什么？
这个想法在哪种情况下会失败？
我现在忽略了什么代价？
如果必须删掉一半，应该从哪里开始？

如果 AI 只让你感觉自己很聪明，它可能只是顺从得很好。

如果它让你看见自己还没有想清楚的地方，它才真正帮你靠近了问题。

钩子模型：产品为什么会被再次想起

Sat, 22 Aug 2026 00:00:00 GMT

我第一次认真看钩子模型，是因为它把产品的使用过程描述得过于顺滑。触发、行动、奖励、投入，四个词首尾相连，用户就会不断回来。可真正做过产品之后，我发现事情没有这么简单。

我开始意识到，钩子模型真正值得讨论的，不是怎样把用户带回产品，而是一次使用之后，产品究竟留下了什么。

四个环节，不是一张留存清单

钩子模型通常从触发开始。

触发可以是一个提醒、一条消息，也可以只是某个时刻的情绪。它不一定来自产品本身。人感到无聊、完成了一项工作、突然想起一件未完成的事，这些都可能成为触发。产品能做的，是让这种模糊的冲动有一个容易抵达的入口。

接下来是行动。行动不是“功能很多”，而是用户愿意做出一个足够小的动作。动作越清晰，阻力越低，用户越容易开始。但这里也有一个容易忽略的判断：如果一个动作本身没有意义，降低阻力只是在更快地消耗注意力。

奖励会让行动得到回应。奖励不只是一枚徽章或者一串数字，也可能是被理解、被逗笑、得到一个意外的答案。好的奖励有一点不可预测，让人愿意再试一次；但它不能只是随机刺激，否则用户最终记住的只有“我被推着点了几下”。

最后是投入。用户投入时间、内容、偏好，或者只是留下一个小小的痕迹。投入让下一次使用不再从零开始，也让产品逐渐变得更像“为我存在”。如果投入没有改变任何东西，它就只是额外的劳动。

所以这四个环节并不是一张检查表。它们更像一次来回：触发让人靠近，行动让事情发生，奖励回答这次行动，投入则决定下一次回来时是否还有必要。

我为什么做 VibeKarma

我做 VibeKarma 的起点很小。AI Coding 很高效，却常常只留下“任务完成”这一种反馈。写完代码的人可能已经很累了，但工具不会在意这件事，也不会给这段过程留下什么情绪上的回声。

我想试试，能不能把这段空白做成一个桌面上的小互动伙伴。它不替 Codex 工作，也不试图把生产力再提高一点；它只在任务告一段落时，提供一个可以回应的对象。

于是有了两种反差很大的玩法：鞭策和画饼奖励。前者允许用户把挫败感用一个具体动作释放出来，后者则把“这次做得不错”变成一场带有角色感的回应。动作、速度、轨迹和声音共同构成一次即时反馈，AI 再用第一人称补上几句回应。

这些设计听起来很完整，真正做起来却不断暴露问题。反馈太强，会像一段吵闹的特效；反馈太弱，又像一个没有反应的按钮。概率化的情绪强度需要有变化，但不能让用户觉得自己无法预测。失败重试、撤回和 Codex CLI 检测这些看似琐碎的功能，反而决定了互动会不会因为一次意外中断。

我后来加上了日记沉淀。最近几次互动会成为下一次回应的上下文，角色因此有了连续性。这里的“投入”不是为了收集更多数据，而是让用户留下的东西真的能在之后发挥作用：昨天发生过什么，今天的回应为什么和昨天不一样。

留存不是目的，关系也不是装饰

做完这个产品，我对“让用户回来”这件事变得谨慎了。

提醒可以制造一次打开，奖励可以制造一次重复，习惯可以让路径变得越来越短。但如果用户每次回来都没有得到新的东西，钩子只是在把同一个动作重复得更熟练。

我更愿意把留存看成一种承诺：用户上一次的使用，应该给下一次留下可以继续的理由。这个理由可以是内容变得更贴合，可以是角色记住了某些事，也可以只是用户确认了自己确实想继续做这件事。

VibeKarma 对我来说，最有价值的部分也不在于“AI 会说话”。真正重要的是，产品承认人的状态会变化，并且给这种变化留出一个位置。今天需要被催促，明天可能只想得到一句安静的回应。产品不是永远用同一种奖励把人推向前，而是能够根据关系的积累，做出一点不同的回答。

钩子应该有停止条件

钩子模型很容易被用成一套增长话术：找到触发，缩短行动，放大奖励，增加投入，然后不断优化回访率。可产品设计不只是在问“怎样让人继续”，也应该问“什么时候不该继续”。

如果一个用户已经完成了目标，产品还在想办法把他留下来，留下来的就不一定是价值，可能只是惯性。好的产品应该允许人离开，也应该让人离开时带走一些东西：一个完成的结果，一段被整理过的经历，或者一个下次仍然愿意回来寻找的入口。

这也是我现在重新理解钩子模型的地方。它不是让人上瘾的机关，而是产品和用户之间的一种往返关系。触发、行动、奖励、投入，最后都要回到一个很朴素的问题：这次使用，是否让下一次选择变得更值得？

如果答案是否定的，再漂亮的机制也只是把空洞包装得更顺滑。

AI 使用指南：不同语言会影响答案，英文提问真的会让 AI 更懂你吗？

Fri, 21 Aug 2026 00:00:00 GMT

我大部分时间都在用中文和 AI 工作。

我的英文其实很差，现在还在学习。讨论产品、设计页面、整理自己的想法时，中文仍然是我最自然的表达方式。但在使用 Codex、Claude Code 这类国外 AI 时，我开始有意识地学习英文，以及英文背后的工作语境。

这不是因为我认为英文比中文高级，也不是因为以后应该放弃中文。只是我慢慢发现：我用中文以为自己已经表达清楚了，国外 AI 理解到的内容，可能并不是我真正想表达的那个意思。

我以为说清楚了，AI 可能听到了另一层意思

当我用中文描述一个问题时，我脑中其实已经带着完整的意图：这个词在这里是什么意思，事情应该做到什么程度，哪些地方不能被改变。

但 AI 并不知道这份意图。它需要把中文输入放进自己更熟悉的语义和知识结构里。很多国外模型接触过大量英文资料、产品文档和开发者指令，因此它们对英文词语背后的技术语境往往更熟悉。

问题就可能出现在这里：我以为自己说的是一个明确的概念，模型却需要在多个英文表达之间进行对应；而一个英文词语放进不同语境，又可能对应不同的中文意思。经过这一层映射之后，原本以为清楚的要求，可能已经出现了偏移。

这不一定是中文表达能力的问题，也不一定是模型能力不足。更准确地说，是我和模型使用的语义坐标还没有完全对齐。

比如我说“简单一点”，我想表达的可能是减少不必要的功能；模型也可能把它理解成减少视觉细节，甚至直接缩短实现。只有当我逐渐理解它熟悉的英文语境，知道某个概念在技术场景里通常对应什么词、什么边界，我才更有可能把自己的意思准确地送过去。

学英文，不只是为了读懂单词

我现在学习英文，并不是为了让自己看起来更像一个专业人士，也不是为了强迫自己用英文聊天。

我更想理解的是：一个词在国外 AI 的语境里通常怎样被使用，它和相近的词有什么区别，在产品、代码、命令行或 Skill 中分别承担什么作用。

同一个中文概念，有时不能只找到一个英文翻译就结束。真正重要的是这个词在句子里承担什么动作，限制了什么范围，和其他词组合后会产生什么具体要求。

当我开始关注这些区别，英文就不再只是“把中文换成另一种语言”，而是帮助我进入 AI 熟悉的语义环境。我的目标也不是写出复杂的英文，而是尽量让关键的词和边界少被误解。

Skill 是我验证这件事的一个例子

Skill 只是其中一个例子，却让我最明显地感受到语言对执行结果的影响。

Skill 通常包含角色、步骤、限制条件和输出要求。有些 Skill 原本是中文写的，我尝试把它翻译成纯英文，再交给 Codex 或 Claude Code。翻译之后，我发现里面的命令行问题和其他执行细节更容易被看见，指令之间的层级和边界也更容易保持一致。

这不意味着中文 Skill 不能使用，而是当一组说明最终要交给一个主要在英文语境里训练、又需要通过命令行执行的工具时，纯英文有时能减少中间的转译。

文件名、命令、代码、API 名称和参数仍然保留原样。需要转换的是角色、步骤、限制和判断标准，让它们尽量对应到工具熟悉的表达方式。

对我来说，这次尝试最大的收获不是“英文更好”，而是发现了一个以前没有认真注意的问题：语言会改变 AI 对任务边界的理解。

我仍然主要使用中文

如果问题涉及中文用户、中文文案、本地文化、生活经验或细腻情绪，我依然会使用中文。

让 AI 写一段面向中国用户的产品文案，判断一句话在中文里的分寸，或者整理一段只属于自己的经历，用英文反而可能损失那些不容易翻译的部分。语言不只是传递信息，也承载着记忆、习惯和判断。

所以我并不认为“英文提问”应该成为一条普遍规则。我的实际情况是：大多数思考和交流使用中文，只有当问题进入国外 AI 的技术语境时，我才会尝试用英文重新确认关键概念。

一种正在学习的工作方式

我现在还没有一套完美的方法，只是在慢慢形成一种更适合自己的工作方式。

先用中文把真实处境说清楚：我在做什么，给谁使用，遇到了什么问题，为什么在意这个结果。然后找到其中最关键的概念，去理解它在英文语境里通常怎样表达，以及它和相近词之间有什么区别。涉及 Skill、命令、代码或严格的执行条件时，再把这些部分翻译成更接近工具语境的英文。

最后回到中文，检查 AI 的回答是不是解决了我真正的问题，而不是只看它的英文表达是否流畅。

可以把这个过程记成一句话：

中文帮助我说明意图，英文帮助我对齐语境，结果仍然要回到问题本身。

这不是一次性完成的翻译，而是一个不断学习词语边界的过程。我的英文还很差，也会犯错，但每一次发现“我以为表达的是这个，AI 实际理解成了另一个”，都在帮助我更具体地认识这两种语言之间的距离。

英文不是答案，理解才是

如果换成英文之后问题变得更清楚，说明语言可能确实影响了这次交流；如果换成英文之后仍然不对，问题也许出在上下文、边界或目标没有说清楚。

英文不能替代思考，翻译也不能自动消除歧义。它能做的，是让某些概念更接近国外 AI 熟悉的语义和工具环境。

所以我不会把这件事总结成“使用国外 AI 就应该用英文”。更准确的说法是：当我想让国外 AI 更准确地理解一个技术概念时，学习它所处的英文语境，可能比单纯把中文句子翻译成英文更有帮助。

我还在学习怎样更好地使用英文，也还在学习怎样和国外 AI 沟通。现在能确认的只有一点：

语言没有让 AI 变得更聪明，但它可能决定了 AI 究竟听见了什么。

AI 时代，更应该学会做减法

Thu, 20 Aug 2026 00:00:00 GMT

AI 让做东西变得越来越快。

一句话可以生成一段代码，一段描述可以得到一个页面，一个模糊的想法也可以很快变成看得见的原型。很多以前需要几天才能完成的事情，现在可能在几分钟内就有了第一个版本。

这当然是好事。但它也带来一个容易被忽略的问题：当增加东西变得太容易，我们会不会忘记删掉东西？

生成变便宜，取舍变昂贵

过去，一个功能要不要做，往往会经过比较长的讨论。因为实现需要时间，修改也有成本，所以人会被迫提前想清楚：它解决什么问题，谁会使用，最小的实现是什么。

现在，AI 可以让一个想法迅速变成现实。按钮可以加，页面可以改，动效可以再做一套。每一次修改看起来都不难，于是“先加上再说”逐渐取代了“它真的需要存在吗”。

但代码写得更快，不代表产品变得更清楚。功能越多，用户需要理解的东西越多；分支越多，维护和解释的成本越高。AI 降低了制造的成本，却没有自动降低复杂度。

所以 AI 时代更需要做减法。

减法不是把产品做得简陋，也不是拒绝丰富的可能性。它是在每一次增加之前，先问一句：如果去掉这个东西，产品还成立吗？如果答案是肯定的，它可能就还没有必要出现。

MVP 不是赶工版

我以前也容易把 MVP 理解成“先做一个能跑的版本”。后来才发现，MVP 的重点不是少做几个功能，而是尽快验证产品最核心的假设。

一个真正的 MVP，应该回答一个具体问题：用户是否需要这件事？他们是否愿意完成这个动作？产品提供的那一点价值，是否足以让他们留下反馈？

如果核心问题还没有得到回答，继续增加功能通常只是在掩盖不确定性。页面变得更完整，介绍变得更漂亮，但我们仍然不知道产品是否真的有必要存在。

AI 特别容易制造这种错觉。它可以把一个未经验证的想法包装得像一个成熟产品，让人误以为“已经做了这么多，应该继续做下去”。可投入的时间不是产品成立的证据，完成的页面也不是用户需要它的证据。

MVP 真正要做的，是把问题缩小到不能再回避的程度。

先规划，再让 AI 动手

AI 很擅长执行明确的任务，却不应该替我们决定任务的边界。

在让它修改代码之前，我越来越习惯先写下几件事：现在的问题是什么，想要达到什么结果，哪些地方不能被影响，怎样判断这次修改是成功的。

这几句话看起来很慢，却能避免很多无效的来回。没有边界的修改，很容易从一个小问题扩散成一连串补丁：为了修正一个视觉细节，改了布局；为了适配布局，又改了交互；最后整个页面都偏离了最初的问题。

规划并不意味着把所有细节提前决定。它更像是在动手之前画出一条边界，让 AI 在边界内提供方案，而不是让它根据一句模糊的“再优化一下”不断扩大范围。

我现在会把改动分成两类：

方向性的决定：产品做什么、不做什么，核心流程是什么，页面应该保持怎样的气质。这些需要慢一点，多问几遍。
可撤销的实验：一个间距、一种颜色、一段动效、一种文案。这些可以快一点，用真实效果验证。

对方向谨慎，对实验快速；对不可逆的决定慢一点，对可逆的尝试快一点。

谨慎，不等于害怕开始

“谨慎”有时会被误解成拖延，好像只有不断等待更多信息，才算认真负责。但真正的谨慎不是不行动，而是知道自己正在承担什么样的后果。

可以快速做一个小实验，因为它随时可以撤回；不能在没有验证核心需求之前，就把大量时间投入到完整系统里。可以尝试三种页面表达，但不应该因为已经写了很多代码，就舍不得删掉错误的方向。

AI 让试错变便宜了，我们更应该把省下来的成本用在验证上，而不是用来制造更多未经思考的内容。

多问一问，不会丢脸

还有一个变化对我来说很重要：向 AI 暴露自己的不足，心理成本正在变低。

过去遇到不懂的问题，我们可能不愿意马上问。担心别人觉得自己基础差，担心一个简单的问题暴露无知，或者只是害怕在对话里显得不够专业。很多人因此绕很远的路，先假装理解，再在错误的前提上继续工作。

AI 不会因为你不懂一个概念而责备你，也不会因为你反复追问而看不起你。你可以直接说：

我不理解这一段，请从最基础的地方开始。
这个方案可能遗漏了什么？
我是不是只是在给一个没有价值的功能增加包装？
如果你站在用户的角度，哪里最容易感到困惑？

这些问题并不代表能力不足。恰恰相反，它们让工作从假装确定，回到真正的理解。

AI 最有价值的地方之一，是提供了一个低压力的练习场。你可以在这里先承认自己不知道，再把问题拆开，直到知道下一步应该验证什么。

把缺点说出来，才能看见问题

如果只把完成后的方案交给 AI，让它帮忙润色和加功能，它很容易变成一台放大器：把原本不清楚的想法做得更完整，把不必要的复杂变得更精致。

更有用的做法，是把不确定和缺点一起交出去。

告诉它自己担心什么，哪些地方没有想清楚，哪些决定只是因为舍不得之前的投入。让它指出矛盾，要求它提出反例，甚至让它从完全不同的角色重新审视这个方案。

这不是把决策交给 AI，而是借助它扩大检查的范围。最后留下什么，仍然需要自己决定；但在决定之前，我们至少看见了更多可能的问题。

让 AI 帮你少做一点

我希望以后使用 AI 时，不只是让它生成更多东西，也让它帮我删掉一些东西。

删掉一个没有必要的页面，删掉一段解释不清的文案，删掉一个会打断阅读的动效，删掉一个只是因为“看起来很酷”才被保留下来的功能。

一个好的请求不一定是“帮我做得更丰富”，也可以是：

请找出这个方案里最不必要的部分。
如果只能保留一个功能，应该留下什么？
哪些内容是在增加价值，哪些只是在增加复杂度？

当 AI 不再只是加速器，也成为一面检查镜，我们才真正开始使用它带来的余裕。

最后仍然要由人负责

AI 可以帮助我们规划、解释、比较和试错，也可以让承认“不知道”变得更容易。但它不会替我们承担产品失败的后果，也不会替我们回答“为什么要做这件事”。

所以我现在越来越相信，AI 时代的工作方法不是更快地把所有想法做出来，而是更快地排除不值得做的想法；不是减少思考，而是把思考放在真正需要负责的地方。

先确认问题，再定义最小版本；先划清边界，再让 AI 修改；先承认缺点，再寻找解决方案。

AI 让行动的门槛降低了，也让暴露不足的代价降低了。我们没有理由继续假装自己什么都懂。

可以勇敢地多问一问，也可以谨慎地少做一点。

因为真正稀缺的，从来不是生成能力，而是知道什么值得留下。

AI 正在把信息差压缩成一段对话

Wed, 19 Aug 2026 00:00:00 GMT

过去，一个人能接触到什么信息，常常取决于他在哪里长大、受过什么教育、从事什么行业，以及身边有没有一个可以请教的人。

很多差距并不是因为有人更聪明，而是因为有人更早知道应该去哪里找，也更容易看懂那些写给专业人士的内容。一个概念、一份文档、一个行业的门槛，往往先把人挡在问题之外。

AI 出现之后，这件事开始发生变化。

它没有让所有人突然拥有同样的知识，也没有把复杂的世界变得简单。但它可以把搜索、翻译、解释和追问放进同一段对话里。原本需要在许多页面之间来回寻找的内容，现在可以从一个具体的问题开始，逐步靠近自己真正想知道的事情。

所以我更愿意说，AI 正在把信息差压缩成一段对话。

信息差不只是知道得少

我们通常把信息差理解成“一个人知道，另一个人不知道”。但现实中的差距往往更细一些。

有人知道应该搜索什么，却看不懂结果里的专业术语；有人读完了资料，却不知道它和自己的问题有什么关系；还有人已经找到了答案，却不知道下一步怎样把它用起来。

这几层距离叠在一起，才构成了真正的信息差。

过去，跨过这些距离通常需要老师、同事、朋友，或者长时间的试错。一个人必须先掌握某个领域的语言，才有机会进入这个领域继续学习。不会提问，甚至意味着不知道自己缺少什么。

AI 改变的，首先就是这个入口。

从查找答案，到获得解释

搜索引擎给出的是结果，书籍给出的是完整的知识，课程给出的是一条安排好的路径。它们都很重要，但它们很少能根据一个人当下的困惑改变表达方式。

AI 可以从另一种方式开始。

你可以让它把一份技术文档解释成日常语言，也可以让它假设你已经懂了其中一部分，只补充缺少的那一段；你可以要求它用一个生活中的例子重新说明，或者直接把概念放进你正在做的项目里。

知识仍然是原来的知识，只是抵达人的路径变短了。

这也是“对话”比“答案”更重要的原因。一个答案通常在被读完时就结束了，而一段对话允许你说“这里我还是不懂”，允许你把问题改得更具体，也允许解释随着你的理解发生变化。

信息差不是在某个瞬间被消除的，而是在一次次追问中被压缩的。

对我们每个人意味着什么

这种变化并不只发生在专业工作里，它也会影响每一个人的日常生活。

它可以帮助学生理解陌生的概念，帮助职场人进入新的行业，帮助创作者研究不熟悉的领域，也可以帮助一个人在面对合同、设备、疾病信息或复杂流程时，先得到一份能够理解的解释。

它不一定让每个人立刻变得专业，但让更多人有机会走到专业知识面前。

对我来说，独立开发只是其中一个例子。做产品时，我经常需要同时处理产品定位、交互设计、代码实现、部署和内容表达。过去，跨过这些领域之间的语言障碍，需要不断查资料、找人请教，再把不同答案重新拼起来。现在，我可以先把问题放进一段对话，让 AI 帮我解释概念、比较方案，再回到真实项目里验证。

类似的事情也发生在更日常的场景里：第一次接触一份保险条款，准备学习一门新的语言，想弄清一个设备为什么无法工作，或者只是试着理解一个自己从未接触过的行业。

真正重要的变化不是“每个人都能得到答案”，而是一个人不必再因为不知道从哪里开始，就停在问题之外。

应该怎么做

如果 AI 正在缩小信息差，我们需要学习的就不只是使用某个工具，而是学会怎样把一次提问变成一段有效的对话。

首先，不要只问一个孤立的知识点，要把自己的问题、背景和限制一起说出来。AI 只有知道你正在解决什么，才能把信息翻译成对你有用的内容。

其次，面对陌生领域时，可以先让 AI 帮你建立一张地图：有哪些关键概念，它们之间是什么关系，哪些必须先理解，哪些可以暂时跳过。先知道自己站在哪里，再决定下一步往哪里走。

然后不断追问。让它换一种方式解释，结合自己的处境举例，说明答案在哪些情况下可能失效。第一次回答只是入口，真正的理解往往发生在第二个、第三个问题之后。

最后，把对话结果变成真正的东西：一段代码、一份方案、一篇笔记、一次实验，或者一个可以继续修改的版本。只有进入实际工作，信息才不再只是“我看过了”，而是变成“我能够使用”。

可以把这个过程记成四个动作：

说明处境，建立地图，持续追问，回到现实。

这比寻找一条完美提示词更重要。因为信息差的缩小，不依赖某一句神奇的问题，而依赖一个人是否愿意把问题说清楚，再沿着答案继续走下去。

信息变得平等之后

AI 让获取信息的成本变低了，但它没有让世界变得没有差异。

有人会使用 AI 获得一份答案，有人会用它建立一套自己的学习和工作流程。有人问完就离开，有人会把对话里的内容带回现实，经过验证、修改和积累，最后变成自己的经验。

这意味着，信息差正在缩小，但人与人之间的差异不会因此消失。差异会逐渐转移到新的地方：谁能持续学习，谁能把信息放进真实处境，谁能把一次对话变成下一次行动的起点。

我并不认为这是一个需要害怕的变化。相反，它让很多原本只属于少数人的入口，开始向更多人打开。

AI 最值得肯定的地方，不是它知道多少，而是它愿意从你能理解的地方开始解释。

它没有消灭信息差，只是让更多人拥有了追问的机会。