从 2024 年下半年开始，我就在比较激进地让 AI 帮我写代码。到现在为止，自己真正亲手敲代码的比例已经很低了，算是一个偏激进的 vibe coding 实践者。

这半年多下来，感想很多，而且很杂。但如果要把它们收束成一句话，我现在最深的感受其实不是“AI 好强”，而是：

AI 让写代码这件事越来越不难了，但把一个产品真正做出来、做对，依然很难。

这两天我给自己的 blog 做了一个欢迎页，灵感来自 Norris 的个人主页。现在回头看，这个需求本身其实一点都不复杂，无非就是想做一个看起来更完整、更有进入感的首页。

但真正折腾起来，从作图、改图，到写代码、改代码，再到反复调整视觉和交互细节，前前后后磨了很久，也消耗了不少 token。最后我很明显地体感到，问题并不在于 AI 不会写，也不在于它能力不够，而在于我自己对需求的描述还不够准。

很多时候，第一次描述不够清楚，出来的结果就会和预期有偏差；等你开始纠错时，如果纠得太猛，又很容易矫枉过正，直接偏向另一个方向。越改越歪，到最后甚至会觉得还不如推倒重来。

所以这篇文章我想写的，不是“AI 会不会取代程序员”，也不是“AI 编程工具哪个好”。我更想记录的是，在 AI 把开发能力快速拉平之后，真正难的东西到底还剩下什么。

写代码

第一层当然还是写代码本身。但现在我越来越觉得，AI 带来的变化，早就不只是“帮你实现一个 function”这么简单了。

它可以参与的层次非常多：表结构设计、模块拆分、程序层级设计、接口定义，甚至是更上层的系统设计和架构设计。很多过去要依赖高级工程师、架构师、甚至技术负责人长期积累的能力，现在都可以通过 AI 先给你一个相当像样的起点。

某种意义上说，它真的很像一个高级架构师，但又不止是架构师。因为它不只是站在上面画图，它还能顺手把底下那部分实现也一起补上。

所以如果你在让 AI 写代码的时候，不是把输出丢在一边自己去刷短视频，而是真的顺手看看它怎么拆问题、怎么组织代码、为什么这样设计，那其实是一个很高频、很廉价的学习过程。

你会看到它怎么命名，怎么分层，怎么补边界条件，怎么从一个模糊目标一步步落成可以执行的代码。这种学习未必系统，但胜在密度极高，而且贴着真实问题。

也正因为这样，我现在很难再把“开发”理解成单纯的体力活。至少在很多场景里，开发本身已经不再是最难的一环。真正的问题开始转移了。

理解需求

我刚上班那会儿，其实一直有一种很强的偏见：产品经理到底有什么用？

在当时的我看来，这个角色无非就是把用户说的问题整理成文档，再拉着大家开会，像是一个被强行安插出来的中间层。很多时候你甚至会觉得，需求如果直接给开发，不是更快吗？

现在回头看，我觉得当年的判断只能说对了一半。不是产品经理这个角色没用，而是某些产品经理没用，所以才让我长期没有真正感受到“理解并梳理需求”到底有多难，也有多重要。

这两年我的实际工作环境里，组内并没有一个强存在感的产品经理。很多需求最后都要靠自己去理解、去拆、去梳理。以前总觉得这部分只是开发前的准备动作，现在才发现，它本身就是非常核心的一段工作。

尤其是在 AI 参与开发之后，这种感受更明显了。因为 AI 可以帮你梳理需求，可以陪你反复讨论，也可以根据你的描述快速往下推进，但前提是你自己得先把问题理解到一定程度。

如果你连自己要解决的到底是什么都没搞清楚，那 AI 只会非常高效地帮你把坑挖得更完整一点。最要命的是，梳理完需求之后，下一个负责开发的人往往还是你自己。既然最后埋单的人还是自己，那前面就更不能随便给自己埋坑。

所以我现在越来越能理解，为什么一个好产品经理会稀缺。不是因为这个岗位门槛天然有多高，而是因为把一团模糊的想法真正整理成可执行、可验证、可落地的需求，这件事本来就很难。

描述需求

如果说理解需求，是先把事情在自己脑子里想明白；那描述需求，就是进一步把这件事准确地传递出去。

而这恰恰是我最近感受最深的难点。

欢迎页那次折腾就是一个很典型的例子。最后做出来的东西并不复杂，事后看甚至会觉得“这不就是个很简单的页面吗”。但真正麻烦的地方在于，我脑子里其实只有一种模糊的感觉：我想要它更完整一点、更有氛围一点、更像一个入口，而不是一打开就是普通博客列表。

问题在于，这种“感觉”对于人来说也许还能靠来回交流慢慢逼近，但对于 AI 来说，如果你不能把它拆成更具体的约束，它就只能根据自己的统计经验去猜。于是每一次输出都可能“差不多对”，但就是不完全对。

更麻烦的是，当结果偏了以后，纠错也不是一句“改一下”就能解决。因为你自己未必知道到底是哪一层偏了。是排版偏了，还是氛围偏了？是图不对，还是文案不对？是层次不够明显，还是你一开始就给了一个错误方向？

这时候如果只是不断局部修补，很容易出现另一种经典问题：把一个地方修正了，另一个地方又歪了。最后你会发现，真正稀缺的能力不是“指出哪里不喜欢”，而是准确描述自己到底想要什么。

这也让我重新想到那本之前很火的书：《人人都是产品经理》。

这个标题其实可以从很多角度解读。但我现在最新的个人感悟是：产品经理的门槛，不在于一个人是什么教育背景、学的什么专业、是不是科班出身，而在于他有没有能力去理解一件事，并把它描述清楚。

这个能力和 background 关系没有那么大，所以当然可以说“人人都能当产品经理”。

但换一个角度讲，既然这个能力几乎对所有人都开放，那也意味着：人人都很难把它当好。

写文档

还有一个我越来越想加进去的点，是写文档。

我现在会觉得，vibe coding 的时候，写文档不是可有可无，而是非常重要。以前常说“好记性不如烂笔头”，这句话放到 AI 协作里其实一样成立，甚至更成立。

因为你不是在跟一个始终稳定、永远记得上下文的人协作，而是在跟一个能力很强、但会幻觉、会遗忘、会随着上下文窗口变化而丢失细节的系统协作。很多你以为“刚才已经说过了”的前提，只要没有被稳定地落下来，后面就很可能再次漂掉。

所以文档的第一个作用，就是对抗 AI 的幻觉和上下文丢失。

你把关键约束、目标、术语、边界条件、设计取舍写下来，等于是在不断给 AI 立锚点。这样它后面无论是继续写代码，还是继续帮你分析问题，偏航的概率都会小很多。

第二个作用，是维持复杂系统里的逻辑一致性。

系统一旦稍微复杂一点，很多东西就不是某一个函数对不对的问题了，而是不同模块之间是不是还在遵守同一套规则。你脑子里当然可以暂时记住，但只靠脑子记，随着需求变动、文件变多、对话变长，迟早会乱。

这时候文档就不是“额外工作”，而是系统本身的一部分。它负责把那些高层规则固定下来，让你、也让 AI，都能反复回到同一个基准面上。

我自己这段时间总结下来，写好文档至少有两个很实际的经验。

第一，尽量写 Markdown 文档。

不是因为 Markdown 有什么神奇，而是因为 AI 对结构化信息的理解能力，明显强于一大坨没有层级的纯文本段落。标题、列表、编号、表格，这些结构会天然帮它理解“什么是主干，什么是补充，什么是并列，什么是从属”。

第二，文档要分层级写。

不要试图把所有东西都堆在同一篇长文里。目标、背景、核心原则、模块设计、边界条件、待确认事项，最好分层组织。这样不只是人看起来轻松，AI 在引用、总结、续写的时候也更稳定。

所以我现在的感受已经和以前完全不一样了。过去我会本能地排斥写文档，总觉得那是行政负担，是“真正写代码之前”或者“写完代码之后”才不得不补的一件事。

现在我越来越觉得，文档本身就是编程的一部分。不是因为流程要求你写，而是因为你如果想把 AI 真正用好，想让一个复杂系统在多轮协作之后还能保持一致，那你就必须主动把文档写好。

最后

所以如果今天再让我总结，AI 时代做产品最难的点到底在哪，我的答案大概不是“技术实现”，而是另外四件更靠前的事：

• 你能不能借助 AI 学会更高层次地思考代码
• 你能不能在开工之前先把需求真正想清楚
• 你能不能把自己想要的东西，描述到足够准确
• 你能不能把关键认知沉淀成文档，稳定地传递给未来的自己和 AI

开发门槛在下降，这几乎已经是一个越来越明显的事实了。但也正因为开发变容易了，过去那些被技术门槛遮住的问题，反而会越来越暴露出来。

以前做不出来，我们可以怪技术太难；以后做不好，很多时候就只能承认，是我们还没有想清楚、没有说清楚，也没有记清楚。