Matrix精选2026年07月06日29 分钟阅读Vibe Coding 时代的角色与架构主作者关注LOSSESRune 开发者，《当代学生生存手册》作者一名「屁股不歪」的前端工程师——LOSSES关注LOSSESRune 开发者，《当代学生生存手册》作者一名「屁股不歪」的前端工程师——联合作者关注LOSSESRune 开发者，《当代学生生存手册》作者一名「屁股不歪」的前端工程师——LOSSES关注LOSSESRune 开发者，《当代学生生存手册》作者一名「屁股不歪」的前端工程师——一名「屁股不歪」的前端工程师——29 分钟阅读微信扫码分享以图片分享分享到微博点击下方按钮可复制链接分享收藏举报Matrix 首页推荐Matrix是少数派的写作社区，我们主张分享真实的产品体验，有实用价值的经验与思考。我们会不定期挑选 Matrix 最优质的文章，展示来自用户的最真实的体验和观点。文章代表作者个人观点，少数派仅对标题和排版略作修改。Vibe Coding 给了很多人超能力，让人似乎能够不费吹灰之力，就把脑袋里面幻想的产品化作现实。在这个人人都有超能力的时代，出现了一些庞大压抑之下蹦出来的新时代优越论：理科生脑袋呆板，只有我们文科生才掌握了 Vibe Coding 时代的话语权；工程师不再重要，我们产品经理自己就可以完成从零到一；产品和工程师都不重要，我们设计师自己就能做出优雅灵动的东西；产品经理和设计师都可以进垃圾堆了，我们工程师自己就能指挥千军万马做出完美的产品。大公司也纷纷开始「拥抱 AI」，欢喜地迎接一场生产力革命，产品、设计、工程师都不重要了，裁掉一批拿来买 Token 就好。然而，现实是残酷的。产品经理做出来的玩意全是 Bug、设计师做出来的玩意卡的要死、工程师做出来的玩意没有人用、大公司从 AI 高潮醒来后纷纷削减了 Token 预算，老老实实地把之前开除的工程师找回来做原来的活。真的太口怕了，这到底是怎么回事？答案就在一个软件的研发流程当中。在产品研发流程里面，每个角色都非常重要，但这并不意味着其他人就不重要。架构的劣化哪怕是有些资历的工程师，也有可能会下意识地忽略一件事：开发并不像是作画一样，想要在这里加一颗星星，想要在那里加个房子，随手提笔加上去就好，只要把世界上最美好的想法全都塞到一个工程里面，那它就是世界上最好的软件。造物是快乐的，人们想要永远沉溺在这种快乐之中，享受井喷的多巴胺。但这件事情并不可持续，现实世界中的开发是一个类似建大楼的过程。产品是一层一层叠起来的，每一层之间都有着紧密的依赖关系。这种依赖并不仅限于代码层面，它几乎是上通天下入地的一个结构。从最基本的产品需要解决什么问题，解决的是谁的问题，用什么形态的产品解决这个问题，到视觉的架构、体验的架构、信息的架构，这些基础奠基起来之后，接下来才进入到了如何用工程架构来回应底层架构的期待。如果盖大楼的时候，工人已经盖到第五层，突然土老板想要在三层和四层之间加一个空中花园，你大概会觉得这人疯了。但在工程实践当中这种事情是真的存在的，需求变更谁还没见过呢，是吧。需求变更可以来自任何一层，但是层级越基础，牵涉到的产品变动就越广泛，换言之「楼体」就会越不稳定。一种常见的实践是，每一层都玩一个「先随便把这东西塞进去交差，剩下的以后再说」，来个两三次这楼就变得很滑稽了。四处都是木头桩子在做支撑，拆掉任何一个楼都会塌。过两天土老板又要在七八楼外面悬挂一个牛棚，工程师们就得顺着楼四处找个风水宝地把这牛棚挂起来，还得确保这楼不能倒。需求快速变更是一件非常让人恼人的事情。如果变更发生在基础层级，牵涉的产品变动就会非常广泛，搞得地动山摇，进而损害整个工程的稳定性。想不清楚事情就交付是一种原罪，无论是老板、产品经理、设计师、还是工程师。任何一层抱着「先随便塞进去交差的策略」，不做研究，玩那种走一步看一步的游戏，都会缔造灾难。经过数次迭代，工程会出现大量飞线、复制粘贴的代码、打结的逻辑、想不明白的异步竞争、理不清的事件和数据流，随便碰任何一个模块都会搞出一堆 bug，按下葫芦浮起瓢。如果你在屎山里面傲游过，大概能理解我在说什么。是的，工程质量是会随着产品演进而自然劣化，劣化越严重的工程其维护成本越高。疏于维护的工程造就心力憔悴的工程师，心力憔悴的工程师造出更大的屎山，这是不可持续工程的源头。地基的品质决定了楼可以搭多高，反映到工作实践上就是架构设计的时候脑子有没有想清楚。开发习惯决定了可以搭多快，比如频繁的需求变更又不留架构修补的时间，那么开发一定会越来越慢越来越痛苦，如果开发自己的脑子不灵光不整理架构，那迷你地狱就成型了。加班和熬夜也是从这里来的。让我们再来看看本以为能「降本提效」的 Vibe Coding。你会发现，它输出的速度的确是非常快。很快啊！很有精神！但是更快的代码输出会加速架构腐化的到来，开发行为与架构腐化伴生。一旦到达不可维护的临界点，工程就必须推倒重做。开发行为并不是一个线性的东西，这就是为什么单纯的靠 Vibe Coding 不能让你走得更快。因此我认为，Vibe Coding 不应当被视为提效的工具，抱着这样的想法只会提笑。Vibe Coding 省下来的时间应当被用来清理一切可能的历史债务。坦白讲，理想的开发流程是什么样的你我心里应当都有数。我们需要撰写文档、需要测试构建、需要代码评审，这些必要流程能够确保架构保持卓越状态，也可以帮助大语言模型快速的进入状态，核查自己的工作。你大概率不想跟在 Code Agent 屁股后面没日没夜的做 QA，它拉屎可比你捡得快。把事情想清楚软件研发是一场漫长的接力，从产品的发想、设计团队将想法具象化、开发再把设计想法化为现实，这当中需要非常多的人付出努力，而且每个人都有义务把问题想清楚，再把手里的棒子交出去。每个团队对这场接力跑的人力配置都不一样，但是一些核心环节都差不了太多。问题和用户的澄清你得先找到一个好的问题。这个问题是明确的、可证伪的、被人需要的。这个问题需要有一个清晰的边界，什么是我们立刻打算解决的（内涵），什么是我们在未来可以解决的（外沿），什么是我们力所不能及的。接下来，谁会提出这样的问题？这一步在实践中有一条现成的推导链条，行业里已经沉淀出成熟的工具，链条上的每一步都在缩小对用户的猜测范围，跳过其中任何一步，后面的所有决策都会建立在一个没有验证过的假设上。要做的第一件事是勾勒清楚用户是谁，给用户画一个画像。一份完整的用户画像需要包含姓名、照片、年龄、居住地、职业、背景描述、教育程度、收入、格言、线上活动、线下工作、技术和社交层面的适应程度、动机和目标。你的用户画像可以主要回答用户需要产品做什么，记录用户的动机、态度、目标和痛点。你也可以用另外一种模式绘制肖像，比如，你在做一个企业服务，那么你或许希望描绘用户在组织中的定位，绘制他们的工作内容、职责、知识储备和完成任务所需的条件。你要小心，不要虚构一个肖像，肖像的构建需要根据用户研究来完成。只根据经验和假设绘制「理想用户」，其结果极有可能带有偏见。他可以作为初步的猜想，但是进入设计决策之前必须用真实研究验证。请注意，这个地方是不能全自动委托给大语言模型办的。模型能够凭幻觉捏造出一份看起来完整的虚构画像，然后把它当成真实用户直接拿去用。究其背后的原因，是因为 LLM 的感知这个世界的方式方式和我们全然不同。LLM 没有真正活过，没有在真实的一天里遇到过让自己惊喜的瞬间，也没有遇到过让自己沮丧到想放弃的瞬间，这类经验没有办法靠训练数据替代。要拿到这些经验，你必须走出办公室和真人进行沟通，团队需要真的设计问卷和访谈，与真正的人交流，去现场见证真人遇到的真实问题，记录他们因为什么感到惊喜、因为什么感到沮丧。这是人性当中不可被忽视的事物，不是产品团队坐在办公室里盯着天花板就能寻思出来的，让 LLM 随便生成出来的虚拟肖像自然同样不可信。接下来我们要让自己捏造的小人们动起来，赋予它们动机，撰写 Epic。我们需要具体回答用户想达成什么目的，但是此时此刻答案仍然停留在抽象层面，还不涉及具体功能。做法是把画像里记录的目标逐条拿出来，转成一句描述用户想要达成的大方向的话，同时把画像本身按用户在不同情境下扮演的角色拆开，因为同一个用户在不同任务里扮演的角色并不相同。比如「作为个人 NAS 玩家，我想要能够轻松备份自己硬盘里面所有的文件，我不希望丢失任何重要文件」，它带有用户的完整的意图，但还没有说清楚具体要做哪个功能。Epic 存在可以给功能设计画出轻清晰的边界，以避免产品老师在无尽的大草原里肆意驰骋。我想你也知道那马儿背后是谁被拴住手脚被拖着满地滚。体验的抽象定义上面的内容可以被理解为对整个产品绘制一个纲要，有了纲要之后，我们就可以开始规划每一个具体的开发周期了，其思路依然是沿着从抽象到具体的方向来做。首先要做的是把 Epic 拆解成可以直接排进开发计划的具体的、可交付的单元。这些单元始于 User Story，它的作用是明确需求边界。其具体格式是「作为某类特定用户，我想要执行某项操作，以便达成某个业务目标」。一条好的 User Story 需要满足四个条件：简短且有概括性（这意味着你并不需要覆盖用户的全部细节）；只保留和产品设计相关的特征；清晰描绘产品需要解决的具体需求；可以在一个开发周期内完成。接着上面的例子，「作为个人 NAS 玩家，我想要能够轻松备份整块硬盘」这个 Epic 可以拆成：「作为每天产生 10GB 视频素材的 NAS 玩家，我想要指定不需要备份的文件夹，以便确保存储空间不被浪费」。用户为什么会需要这个功能？我们需要补齐用户的动机，增加具体的使用情境。这时我们可以使用 Job Story 这个工具。User Story 关注角色和目标，Job Story 关注触发动作的具体场景。其模板为：「当处于某种特定情境时，我想要执行某个具体动作，以便解决当前情境下的麻烦事」。以之前的备份需求为例，对应的 Job Story 为：「当我发现 NAS 提示存储空间已满 90%，且我马上需要导入新项目素材时，我想要一键排除所有 .tmp 和 .cache 结尾的文件夹，以便将存储空间留给重要文档」。简而言之，我们始终在回答这三个问题：用户对情境的感受，用户想达成的目标，用户为达成目标执行的具体任务。在理解了用户的基本情况之后，可以通过 Journey Map 来规划用户使用产品的大致流程。它是一种可以有效汇总问卷、访谈结果的手段，并且可以把用户诉求桥接到实际功能的设计上。我们把它画成一个大的时间轴，并且把此时用户可能的内心感受画成曲线。一张地图主要分为三个区域：顶部区域包含特定用户、具体场景以及对应的期望或目标。继续回到 NAS 的例子，我们的用户是每天产生大量视频素材的 NAS 用户。场景是 NAS 提示存储空间已达 90%，且用户需要导入新素材。期望是快速排除缓存文件以腾出空间。中间区域包含高抽象的的用户旅程阶段，以及由用户的动作、心态和情绪组成的细节。这些元素被映射在各个旅程阶段中。对于每个阶段，我们需要清楚地写出用户采取的实际行为和步骤；同时也要标注出用户的心态，即应用户在不同阶段的想法、问题和信息需求。在文字信息的下方，我们需要绘制一条情绪曲线，它需要横跨旅程的每个阶段，标示出用户体验的起伏状况，直观地展示用户究竟是开心的还是不开心的。在 NAS 场景中，旅程阶段划分为：收到存储警告、查找无用文件、执行排除操作、确认可用空间。在此阶段内，用户的动作是进入控制台逐级查阅并筛选以 .tmp 结尾的文件夹。用户的心态是确认当前的删除操作不会影响主项目。情绪曲线则记录了从空间不足时的焦虑，到层层寻找缓存目录时的烦躁，再到完成空间释放后的平静。这条曲线指出了流程中需要优化的负面情绪发生在什么时刻。在 Journal Map 的底部区域我们需要总结这个过程中获得的发现，即产品获得成功的潜在机会、用于评估方案实施效果的数据标准。这一小节能够说明如何优化用户体验，同时解答需要通过这些知识做什么、由谁负责改变以及如何衡量实施的改进。对于 NAS 这个例子，我们抓到