Vibe Coding 之后，谁来把软件真正用起来？

概念插图：第一版完成之后，维护和使用还会继续。

在 TikTok 上刷到 @blameanthony 谈 Adobe 的视频，有一句话很有意思。他在配文里说，剪这条视频时 Adobe 崩溃了三次，自己还遇到了视频编码格式的支持问题。于是他问：要不要用 Vibe Coding 做一个开源替代品？

但他也说，自己愿意为 Adobe 付钱，前提是有人提供支持，修好问题，而且足够快。

这让“用 AI 做软件”的讨论多了一层。做出功能当然让人兴奋，真正开始使用之后，大家还会在意：出了问题，谁来处理？这个工具能不能一直用下去？

应用上线，工作才刚刚开始

Vibe Coding 缩短了从想法到第一版的距离。以前可能要排期的小工具，现在可以先做出来试试。对有明确需求的人来说，这很有吸引力。

不过，@blameanthony 的抱怨也提醒了我们：使用软件时，打断工作的往往是具体的小问题。打不开一个文件、处理到一半崩溃、上次好用的功能突然出了错，都足以让人停下来。

自建工具同样要面对这些事。第一版交付之后，反馈会继续出现，使用方式会变化，也会有人提出最初没想到的要求。

生成代码的速度可以很快，这些后续工作仍然需要时间。

多一个工具，也会多一处交接

在团队里，问题还会多一道：谁知道这件事，谁来接着处理？

反馈可能留在聊天里，处理进度放在项目工具里，相关客户资料又在另一个系统。要决定先改什么，往往得先把这些信息找齐。

工具越容易做出来，这类整理工作就越值得注意。每多一个入口，都要想好收到的信息去哪里，处理结果又怎么回来。否则，新工具虽然能用了，同事之间仍然要来回询问和转发。

最容易漏掉的，是反馈处理之后的那一步。问题已经修好，提出问题的人却没收到回复；团队讨论过暂时不做，下周又有人把它当作新需求提出来。记录一个处理状态，再把结果送回原来的讨论里，能省掉不少重复沟通。

反馈有了记录、负责人和回复，才算有人接着往下做。

让新工具接上已有工作

Leina 关注的是这些日常工作。团队可以在聊天里交代任务，让它通过已授权的 Apps 查找相关资料，把分散的信息整理到一起。能连接哪些系统、执行哪些操作，以实际支持和账号权限为准。

你可以先交给它一项具体工作：

整理过去七天的产品反馈，合并重复问题，保留每条原始记录的链接。列出受影响的功能、目前状态和记录中已有的负责人；没有写明的标成待确认。另列出已经处理、但还没有回复用户的问题。先把整理结果发到这里。

这份结果有两个用途：帮助团队决定先处理什么，也帮助负责沟通的人找到该跟进谁。它不需要替团队猜优先级，先把遗漏暴露出来就有价值。

检查几次之后，把有效的整理方法保存为 Skill。这样，AI 除了帮忙做出第一版，也能参与软件投入使用之后的日常整理。

从上线后的第一周开始

如果你刚用 AI 做出一个工具，可以先观察它投入使用后的第一周：

• 哪些信息仍要手动搬到别处？
• 谁在反复询问进展或补充背景？
• 哪些提交已经收到，却没有进入下一步？

选一项最常发生的整理或交接，看看能不能少花一点时间。

回到那条 Adobe 视频，愿意自己做替代品和愿意付订阅费，其实可以出现在同一个人身上。大家想要的很朴素：手头的事能够顺利做完，遇到问题有人处理。

AI 让第一版来得更快。之后的每一天，也值得有人照顾。

创建 Leina，从一周的真实反馈试起。先在集成目录确认资料所在的服务和所需操作是否支持；跑通后，可以把这套要求保存为 Skill，留给下一次使用。