产品思维是 AI 编程工具替不了的能力

速度正在暴露问题逻辑中的缺口

现在人人都能交付。这正是问题所在。

几周前，我用了三个小时做出了一款完整的测验应用。一个窗口播放《浴血黑帮》，另一个窗口开着 Claude。我描述自己想要什么，它就出现了。我没有亲手写任何一个组件，没有配置构建工具，也没有考虑路由。

这就是 vibe coding 的作用。它极大地缩短了从想法到实现的距离，以至于瓶颈不再是“你能不能把它做出来”，而变成了“你知不知道应该做什么”。

而大多数工程师——包括我自己——其实都没有为这种转变做好充分准备，只是大家都心照不宣。

构建成本曾经迫使你思考

长期以来，构建成本一直是一种迫使人把问题想清楚的机制。如果你准备花两周时间做一件事，那最好先把它理解透彻，至少能够为自己的决策辩护。实现所需的投入会逼着你尽早提出那些令人不舒服的问题，因为拖到后面再问，代价既痛苦又高昂。

Vibe coding 消除了这种阻力。总体而言，这当然是件好事。真的。你可以在一个下午里把想法变成能运行的产品，这确实有点不可思议。

但这也意味着，如今你可以信心满满地交付某个东西，却从未问过那些过去会被现实条件强迫着回答的问题。

它究竟解决了什么问题？为谁解决？成功是什么样子？需要做出哪些权衡？规模扩大后会发生什么？它会以什么方式失败？

这些不是工程问题，而是产品问题。它们一直都很重要，只不过以前有一种内置机制会迫使你面对它们。现在，这个机制消失了。

构建 Go Mastery 让我亲身体会到了这一点

当我开始构建 Go Mastery 时，第一反应是典型的工程师思维：我需要哪些组件、状态如何流转、数据模型是什么。

随后我意识到自己走偏了。这个项目的目标应该是学习 Go，而不是为了学习 Go 去构建一个 React 应用。这是两个截然不同的项目。如果沿着那条路走下去，我可能会花三个小时设计架构，却完全不去思考这套测验究竟能不能真正教会人什么。最终交付的会是一款精美无比、却毫无用处的软件。

于是，我强迫自己先停留在产品问题上。

为什么大多数测验无法带来真正的学习？因为它们的设计目标是让人完成，而不是让人理解。一个显然正确的答案，周围放着几个显然错误的干扰项。你不需要理解任何东西，只要不被干扰就行。与其说这是测试，不如说只是一次凭感觉的检查。

如果要设计一套让这种答题策略彻底失效的测验，它应该是什么样子？放置一个错误答案，再配上几个听起来都很合理的选项。这样一来，你就无法依靠模式匹配蒙混过关，而必须真正思考。

怎样才能让走捷径变得更难？加入一个质疑机制。回答之后，有 60% 的概率，测验会追问：“你确定吗？”你永远不知道自己是真的答错了，还是仅仅受到了挑战。于是你会停下来重新阅读；如果你和我一样，还会短暂地怀疑自己做过的每一个选择。

这些思考都不需要代码。它需要的是对问题有足够深入的理解，从而能够对解决方案形成自己的判断。实现只花了三个小时，是因为思考已经提前完成了。

这就是产品思维。Vibe coding 不会把它赋予你；它只会让你在缺乏这种思维时，暴露得更加明显。

Hallucination 是同一个问题，只是换了一身衣服

接下来才是有意思的地方。

AI hallucination 与学习中的错误认知，在结构上其实是同一个问题。两种情况下，都有某个听起来正确的东西，实际上并不正确。两者真正的危险都不是明显的错误，而是貌似合理的错误。一个 90% 正确、剩下 10% 存在隐蔽缺陷的输出，要比一个一眼就能看出错误的输出危险得多，因为明显错误的答案至少很容易被发现。

找出明显错误的答案只是基本要求。当周围所有内容听起来都合情合理时，仍能识别出错误答案，才是真正的能力。

因此，我认为“识别错误认知”正在成为工程领域最被低估的技能之一。这不是为了怀疑而怀疑，也不是对每一句话都进行强迫式的事实核查，而是一种具体的能力：读到某个听起来权威且合理的说法时，把它与你真正掌握的知识进行比对，然后准确找出它究竟从哪里开始偏离正轨。

使用 AI 构建产品，会直接训练这种能力。每当你向 Claude 或 GPT 输入 prompt，得到一个几乎正确的回答时，你都在锻炼它。每当你在 hallucination 被交付之前将其识别出来，你的判断就会变得更加敏锐。这就像去健身房，只不过这家健身房偶尔会试图说服你：goroutine 的工作方式和 JavaScript Promise 一样。

在 vibe coding 时代真正脱颖而出的，不会是最擅长写 prompt 的工程师，而是最擅长评估输出的工程师。评估输出与判断测验答案需要相同的能力：你必须足够深入地理解一个概念，才能知道某个东西为什么错，而不只是知道它错了。

这在实践中意味着什么

构建 Go Mastery 之后，我对自己的工作方式做了几项调整：

在写 prompt 之前，先写 brief。我要解决什么问题？谁遇到了这个问题？好的结果是什么样子？有哪些约束？花五分钟想清楚这些问题，可以省下三十分钟的反复迭代，以及一次让人摸不着头脑的 diff。

把 AI 输出当成一道测验题。不要问“它对不对？”，而要问“它错在哪里？”默认它正确，正是陷阱所在。合理的默认判断应该是：“它可能大体正确，但我需要找出其中不正确的部分。”通常，这部分并不难找。

学习概念，而不只是语法。Vibe coding 让你无需理解 Go，也能轻松交付 Go 代码。但当 hallucination 出现时——它一定会出现——你必须具备相应的心智模型，才能将其识别出来。停留在表面的熟悉程度无法赋予你这种能力，真正的理解才可以。

围绕问题思考，而不是围绕功能思考。“我应该构建什么？”远不如“我要解决什么问题，而这是不是正确的解决方案？”有用。现在生成新功能已经很容易，但值得解决的问题依然很难发现，而无论写多少 prompt，都无法替你完成这一部分。

技能栈正在上移

我们并不是在走向一个工程技能不再重要的世界，而是在走向一个最重要的工程技能不断向技能栈上层迁移的世界。

实现正在变得更便宜，理解正在变得更有价值。产品思维——知道要为谁构建什么，以及为什么要构建——正在成为真正的差异化能力。

这对工程师并不是威胁。说实话，只要你愿意主动适应，这其实是一种相当不错的发展。那些一直想站在产品层面思考、却被困在实现细节里的工程师，如今终于有了兼顾二者的工具。而那些始终只考虑实现的人则会发现，更好的工具反而让工作变得更难，而不是更容易，因为工具揭示了一个始终存在的事实：代码从来都不是最难的部分。

Vibe coding 不会取代思考，它只是让思考本身成为了工作。

我会撰写有关 Go、全栈开发，以及如何避免过度思考并将项目交付出去的内容。如果这些观点引起了你的共鸣，欢迎在 LinkedIn 上关注我。

如果需要采取进一步行动，你可以考虑屏蔽此人和／或举报滥用行为。