我开始把 AI 当成同事之后

今年，我从工作了十年的公司离职了。

十年是一个很长的时间。长到很多事情已经变成了身体记忆，业务怎么流转、问题从哪里来、出了事应该找谁确认，好像都不需要再想。每天坐到电脑前，很多上下文是天然存在的，像桌子、椅子、显示器一样摆在那里。

离开之后，我才慢慢意识到，过去很多所谓的工作经验，其实有一部分是被环境托住的。

在公司里，一个问题到我手上的时候，通常已经被处理过一轮。它可能经过了产品、运营、客服，或者至少经过了某个业务流程，最后变成一个需求、一个任务、一个 bug，变成一段程序员能理解的话。它当然也会不合理，也会反复变更，也会让人骂骂咧咧，但大多数时候，它已经被翻译过了。

创业以后，这层东西没了。

问题会以各种奇怪的方式出现。一个电话，一句群消息，一段完全基于用户自己理解的判断，或者一个明明和产品本身没什么关系、但最后还是会落到你这里的麻烦。

我以前以为，创业最难的是把产品做出来。

后来才发现，能把东西做出来，只是开始。

从程序员到创业者

以前做程序员的时候，我面对的问题相对清楚。

这个功能怎么实现，这个页面怎么优化，这个接口为什么报错，这段逻辑为什么绕不出来。哪怕问题很复杂，也总有一些线头可以抓。能复现就去定位，能定位就去修，边界清楚就拆开做。

创业之后，很多事情没有这么干净。

你要想的不只是“怎么做”，还要想“该不该做”“做到哪里就够了”“这个问题到底是不是问题”。有些需求看起来很直接，往里多想一步，又会发现它背后其实是用户的误解、使用习惯，或者对产品能力的另一种期待。

更麻烦的是，用户不一定知道自己真正想问什么。

有些问题表面上是功能问题，实际是在问规则、问边界、问收费、问一个基础概念。你很认真地解释了一遍，对方也很认真地听了，但最后总结出来的东西，和你刚才说的几乎不是一回事。

这种时候会有一种很强的无力感。不是因为问题难，而是你发现双方根本不在一个语境里。你以为自己在解释事实，他其实只是想从你的回答里找到一句能印证自己判断的话。

还有一些问题，严格来说和产品本身没什么关系。可能是设备环境，可能是系统设置，也可能是某个第三方软件弹出来的提示。但用户不会这么分。他只知道自己在使用你的产品时被卡住了，于是这件事就自然地变成了你的问题。

从他的角度看，这也不是完全不能理解。用户不是来做技术归因的，他只是想把事情做完。

只是最后，需要接住这些混乱的人，变成了你。

真正困难的不是写代码

创业之后，我很快发现，真正让我累的反而不是写代码。

代码里的问题也烦，但它有一套比较熟悉的处理方式。报错了看日志，异常了打断点，性能不对就分析链路，结构太乱就想办法拆。它们不一定简单，但至少大多数时候可以验证，可以复现，可以一点点往前推。

用户问题不是这样。

它经常混着情绪、误解、期待和现实条件。你要先判断他到底卡在哪里，再判断这件事是不是产品该承担的问题，接着还要想现在要不要处理，怎么处理，怎么解释。很多时候，真正消耗人的不是解决方案，而是前面这一长串判断。

有时候你解释了很多，对方听到的还是另一个意思。

有时候你顺手解决了一个和产品无关的问题，对方并不会知道那其实是额外帮助。

有时候你一直积极响应，久了以后，这种响应就变成了默认值。某一次没有及时回复，之前做过的那些事不太会被想起来，用户只会看到这一次没有被满足。

我倒也不想简单地说用户不好。很多人确实不懂这些边界，也没有必要懂。他只是遇到了麻烦，希望有人能帮他把事情继续做下去。

理解归理解，消耗也是真的。

以前我更多是在解决工程问题。现在很多时间，我是在判断一个问题到底是不是问题。

这是一种完全不同的疲惫。

AI 进入我的工作流

也正是在这个阶段，我真正进入了 AI 编程。

以前我也用 AI，但更多是把它当成一个更聪明的补全工具。写代码的时候让它补几行，遇到问题的时候让它解释一下，偶尔生成一点重复内容。它有用，但还谈不上改变工作方式。

现在不太一样。

我会把一个问题比较完整地交给 AI。让它读代码、拆需求、整理方案、生成初版、补测试、写文档、做 review。很多时候，我不是从第一行代码开始写，而是先把背景、目标和限制讲清楚，再等它给出一个可以讨论的东西。

真正进入这种工作方式以后，最明显的变化不是代码写得更快了，而是我写代码这件事本身变少了。

刚开始我其实有点不适应。

毕竟在很长一段时间里，我对程序员的理解，还是和亲手写代码绑在一起的。代码是我一行一行写出来的，所以我知道它为什么存在，知道哪里可能会出问题，出了事也知道应该从哪里开始查。

现在很多代码不再是我亲手写出来的。

但这不代表我可以不管。恰恰相反，我反而要更认真地看它。它到底有没有理解问题，有没有破坏原来的设计，有没有引入新的隐患，测试是不是真的覆盖到了关键路径，这些都要重新判断。

以前我更像是在生产代码。现在很多时候，我是在组织代码。

AI 可以很快给出一个看起来完整的答案，但这个答案能不能用，最后还是要回到我这里。

少写代码之后，我反而更忙了

一开始我以为，AI 把开发效率提高之后，我应该会轻松不少。

后来发现也不是。

它确实节省了很多工程执行时间。以前要一点点写、一点点改、一点点查的东西，现在可以更快拿到一个结果。我能从一些重复劳动里抽出来，也能同时推进更多事情。

但省下来的时间没有变成空闲。

它很快被别的事情填满了。用户沟通、产品判断、商业决策、服务边界、文档说明、售后支持、功能取舍，这些过去在公司里可能由不同角色分担的事情，现在都会来到我面前。

AI 帮我少写了一部分代码，但没有帮我少承担责任。

甚至可以说，正因为开发变快了，我才更快地撞上了代码之外的问题。功能很快能做出来，于是更重要的问题变成了它该不该做。bug 很快能修掉，于是要继续想它背后是不是有更大的产品问题。页面很快能搭出来，于是要确认它是不是真的解决了用户的困惑。

效率提高之后，并不会自动变轻松。

它只是让下一个问题来得更快。

AI 像同事，但不是负责人

我说自己开始把 AI 当成同事，并不是因为它真的像人一样可靠。

恰恰相反，它经常误解上下文，给出一些看起来合理但实际不成立的方案，也会在细节上偷懒，把没有确认过的事情说得很确定。它有时候很聪明，有时候又让人觉得离谱。

但它确实承担了一部分过去必须由我亲自完成的工作。

它像同事，是因为我需要给它背景，给它拆任务，看它做出来的东西，指出哪里不对，再让它继续改。很多结果不是一次就能得到的，而是在几轮来回里慢慢接近。

但它不是负责人。

它不会真正理解我的用户，不会替我承担错误后果，也不知道什么方案在商业上更合适。哪些需求要满足，哪些需求要拒绝，什么时候应该快一点，什么时候应该克制一点，这些事它都不能替我决定。

更不用说，它不能替我去面对用户的情绪。

所以我现在会把很多事情交给 AI，但不会把判断交给 AI。

这可能是我这段时间最深的感受。

AI 让很多事情变快了，但没有让事情变简单。它只是把一部分执行工作接过去，然后把我推到更靠前的位置。

我不再只是问“这个功能怎么写”。

我开始更多地问：“这个问题到底是什么？”

程序员能力正在重新排序

以前我会更在意自己能不能写出更好的代码。

会不会一个框架，熟不熟一种技术栈，能不能快速实现需求，能不能解决复杂 bug，这些当然都重要。它们是程序员很基础的能力，也是在很长一段时间里评价程序员的主要方式。

但现在，我越来越觉得，程序员能力的顺序正在变。

当 AI 可以写出越来越多代码时，真正拉开差距的，可能反而是那些不太像写代码的能力。

比如能不能定义一个好问题，能不能判断一个需求是不是真需求，能不能控制实现范围，能不能识别 AI 产出的风险。再往外一点，是能不能理解系统边界，能不能把用户混乱的表达翻译成产品决策，能不能在很多事情都不确定的时候，还是把它往前推一点。

这些能力过去也重要，只是经常被藏在“经验”这个词后面。

现在它们变得更明显了。

因为代码的生产速度变快之后，结果好不好，不再只取决于写代码的速度。更重要的是，你一开始有没有把问题想对。

AI 可以生成一个方案，但不能替我决定这个方案是不是当前最合适的。

AI 可以补全一段实现，但不能替我确认它会不会带来新的维护成本。

AI 可以整理一份文档，但不能替我承担文档被误解之后的后果。

说到底，AI 改变的不是责任的归属，而是责任出现的位置。

以前责任更多藏在代码里。

现在责任更早地出现在问题定义里。

重新理解程序员这件事

离开工作了十年的公司之后，我从一个稳定系统里走了出来。

创业让我直接面对用户、产品、商业，还有那些没有被整理过的问题。AI 让我写代码越来越少，也让我更快看见代码之外的部分。

这两件事发生在同一年，对我来说有一种很奇妙的重叠。

我一边离开过去熟悉的工作方式，一边进入一种新的工作方式。以前我会用写了多少代码、解决了多少技术问题，来确认自己仍然是一个程序员。现在这种确认方式好像没有以前那么重要了。

我依然需要理解代码，需要判断架构，需要保证结果可靠，也需要在出问题的时候站出来解决。

只是我不再需要亲手写下每一行。

这没有让我离编程更远。相反，它让我更清楚地意识到，程序员从来不只是写代码的人。

程序员真正做的事情，是把混乱的问题变成可执行的结构，再让这个结构尽可能稳定地运行起来。

以前这个过程更多发生在代码里。

现在，它也发生在产品判断里，发生在用户沟通里，发生在一次次和 AI 的对话里，发生在那些看起来不属于开发、但最终决定产品能不能继续往前走的地方。

我不知道这是不是程序员工作的下一种形态。

但至少对我来说，它已经发生了。

我开始把 AI 当成同事之后，写代码确实越来越少。可我需要判断的事情越来越多，需要负责的事情也越来越多。

也许这反而让我更清楚地意识到：

我不是因为写了很多代码，才像一个程序员。

而是因为我仍然在试图理解问题、组织方案，并为结果负责。