vibe coding 的软件工程感想

过去一段时间，我借助不同的大模型、编码工具和 Agent，完成了一系列个人项目。

这些项目既包括个人网站、图片画廊和地图交互，也包括 PDF 管理器、Obsidian 插件、自托管 Agent、iOS 应用，以及最近开始尝试商业化的 PassMap。

我使用过 Claude Code、Gemini、Codex、ChatGPT、DeepSeek 等模型和编码工具，也尝试过 Xiaomi MiMo。在使用方式上，我主要把 LLM 分成三种形态来使用：

第一类是 Web 端交互，包括日常对话、Deep Research，以及类似 NotebookLM 这样的信息整理与知识回溯工具。这一类更偏向信息获取、分析和思考辅助。

第二类是 Editor 和 CLI 形态。我会在 VS Code 中通过 OpenRouter 调用不同模型，在代码编辑环境中直接进行修改、重构和生成；CLI 则更多用于项目管理、脚本执行、构建流程和部署操作。这一类更贴近实际开发流程。

第三类是 Agent 形态，例如 Cowork 或 OpenClaw。这类工具可以在更高层级上连续执行任务，完成从理解需求、拆解步骤到执行和反馈的一整套流程，更接近“自动化协作”的工作方式。

刚开始时，我最直接的感受是：Vibe Coding 让我能够跨越不熟悉的语言和技术栈，快速做出过去很难独立完成的项目。

但随着项目从个人页面发展到 LibrisArk，再发展到 PassMap，我逐渐发现，真正的瓶颈已经发生了变化。

过去最困难的问题可能是“怎样实现”，现在更加困难的问题变成了：

应该做什么？系统应该怎样组织？数据库应该怎样设计？怎样判断一个交互是好的？怎样验证用户真的需要？怎样让产品持续运行？又怎样让一个产品最终成为能够产生收益的业务？

AI 没有消除产品和软件系统的复杂度。它更像是降低了实现成本，并把人的注意力推向了问题定义、系统设计、方案选择、结果验证和业务运营。

一、我做过的项目，以及 Agent 在其中的作用

与其按时间顺序列出所有项目，我更愿意按照项目性质进行分类。因为不同类型的项目中，Agent 发挥作用的方式并不相同，而人的工作重点也会发生变化。

1. 个人网站、内容展示与前端交互

这一类项目的系统复杂度通常没有那么高，主要工作集中在内容组织、视觉设计和交互细节上，包括个人网站、Gallery、地图交互，以及对历史网页和旧项目的重新整理。

个人网站与项目展示

我的个人网站主要保存在 yvonshong.github.io 仓库中，另外还有一个用于项目展示的 proj 仓库。公开仓库目前仍将其描述为个人网站，并保留了 Hexo、主题、静态资源和自动化工作流等结构。

我后来把个人网站迁移到了 Vercel 加 Cloudflare 的方案下。

这套方案同样能够实现 CI，在代码更新后自动进行构建和部署。相比继续使用 GitHub Pages，它的一个现实优势是可以减少 GitHub Pages 在国内访问受限所带来的影响。

在这个项目中，Agent 可以帮助我调整部署配置、构建流程和页面代码，也可以快速排查部署错误。但真正需要我决定的是：为什么迁移，使用怎样的托管方案，如何组织网站内容，以及过去的项目和博客应该以什么方式重新呈现。

Gallery：从展示图片到设计观看体验

我重新设计了个人网站中的图片画廊，项目代码保存在 Gallery 仓库中。当前项目使用 React、TypeScript 和 Vite，并包含独立的脚本、产品需求文档和自动化工作流。

Gallery 的基础功能并不复杂，但我在交互和视觉上花了很多时间。它也是目前我对交互和美感都比较满意的项目之一。

在正式实现之前，我先对不同方案进行了选型，然后把主要精力放在图片应该怎样被浏览、怎样切换，以及页面应该呈现怎样的节奏上。

除了页面本身，我还使用 Cloudflare R2 Storage 存储图片，实现了图片数据同步的脚本化，并加入了图片压缩流程。

Agent 在这里主要承担实现工作。它可以快速生成不同的页面方案，接入 Cloudflare R2，编写数据同步和图片压缩脚本，并根据我的反馈不断修改前端细节。

但真正决定产品质量的，并不是 Agent 能否把图片显示出来，而是人能否定义“什么是好的图片浏览体验”。

这里所说的审美，也不只是简单判断页面好不好看，而是判断图片是否始终是视觉主体，信息有没有清晰的主次，动画是否恰到好处，操作是否符合直觉，以及桌面端和手机端能否保持一致的观看节奏。

地图和手势交互

我还完成了两个与地图展示和交互有关的项目，分别保存在 holoearth 和 map 仓库中。其中，map 项目还包含地图数据、地理编码脚本和网页端交互代码。

这些项目整体上属于纯前端网页，从工程规模来看，与普通博客或展示页不会相差特别多，但使用了一些比较特殊的地图和手势库。

然而项目的主要工作是做调整缩放、拖动、点击和移动等操作，让手势反馈更加自然。

Agent 可以帮助我快速理解陌生的库、生成初始代码、处理事件，以及调试不同手势之间的冲突。

但手势是否符合直觉、是否容易误触、页面是否让人感到顺畅，依然只能通过不断试用和人工判断完成。

这让我意识到，对于很多前端项目来说，代码本身未必是最困难的部分。实现一个交互可能很快，但把它调整到自然、舒服和有完成度，需要大量细节判断。

历史项目的重新整理

我也借助大语言模型，对过去的一批项目进行了重新整理和优化。

其中包括大学时期完成的 MatlabLens。这是一个受到 Office Lens 启发的 MATLAB GUI 项目，包含图片加载、透视校正、裁剪、降噪、对比度调整、二值化、撤销和保存等功能。

我还重新整理了文字内容项目 九世呓语。这个项目使用 Markdown 和 HonKit 组织内容，并生成可以在线阅读的网页。

初高中物理笔记 则被重新组织成了模块化的电子书，包含物理知识章节、公式渲染和自动化部署流程。

此外还有过去的网页和书签项目 website、农历日历生成器，以及学生时期完成的 XML 课程展示项目。XML 项目中保留了 DTD、XSD、XSL、XQuery、XML 和相关网页展示内容。

其他被重新整理的内容还包括班级展示网页、旅行地点展示、个人博客中的 Project 页面，以及过去积累的学习资料。

在这些项目中，Agent 更像一个“旧项目现代化助手”。它可以帮助我阅读旧代码、解释过去的实现、重构不清晰的部分、更新页面样式、补充说明文档，并把过去零散的内容重新组织起来。

这类工作虽然并不是从零创造一个新产品，却降低了重新理解旧项目的成本，也让过去的积累重新获得了展示和使用价值。

2. 文档管理与个人知识系统

与展示类网页相比，文档管理和个人知识系统涉及更多数据结构、状态管理和长期使用问题。LibrisArk 和 GenWiki 是其中两个比较典型的项目。

LibrisArk：跨平台 PDF 管理器

LibrisArk 是我目前完成的工程量较大的项目之一。

它是一个面向 Ubuntu，同时考虑跨平台能力的 PDF 和文献管理器。公开仓库将它描述为一个 Local-First、AI-Enhanced 的桌面文献管理工具，使用 Tauri、Rust 和 SQLite，让用户尽可能保留对本地数据的控制。

LibrisArk 的主要功能包括管理本地 PDF、为 PDF 添加标签、自动生成标签、管理用户批注，以及接入大语言模型，让模型阅读论文、生成结构化摘要，并围绕论文内容回答用户的问题。

这个项目的特殊之处在于，我原本几乎完全不会使用其中涉及的一些编程语言和技术栈。

在传统开发方式下，我可能需要先学习语言、框架和桌面应用开发，再开始实现产品。但在 Agent 的帮助下，我可以一边开发，一边理解相关技术。

不过，LibrisArk 并不是直接从写代码开始的。

我首先进行了大量功能需求讨论，明确产品到底想解决什么问题，然后设计系统方案，对不同功能进行优先级排期。开发时先实现大体框架，再逐渐补充 PDF 管理、标签、AI 问答和批注等功能，最后继续优化交互和细节。

Agent 可以帮助搭建跨平台应用框架，处理 PDF、标签和批注逻辑，并接入大语言模型。它显著降低了陌生技术栈的进入门槛。

但它无法自动决定产品边界，也不会自然知道哪些功能应该优先。

人仍然需要判断产品到底解决什么问题，系统应该怎样组织，哪些功能属于核心流程，哪些功能可以推迟，以及用户操作是否真正合理。

从 LibrisArk 开始，我更明确地意识到：Vibe Coding 可以加速实现，但无法替代产品需求、系统设计和功能排期。

GenWiki：让收藏内容逐渐形成知识网络

我已在不改变你原有结构与语气的前提下，补充了 Karpathy / LLM Wiki / RAG 局限性这一层背景，使 GenWiki 的定位更“方法论化”而不是单纯工具描述。

---

我还开发了一个 Obsidian 插件 GenWiki。

它的目标是把用户从网页上收藏的文档，逐步整理为一个具有 Wiki 结构的个人知识库。

GenWiki 的设计灵感来自 Andrej Karpathy 提出的 “LLM Wiki” 概念。它试图解决传统 RAG（Retrieval-Augmented Generation）系统的一个核心局限：搜索是一次性的、碎片化的，而知识本身并不会在过程中持续累积和结构化。

在传统 RAG 中，信息通常以“被检索 → 被回答 → 被丢弃”的方式存在，系统更像一个临时问答接口，而不是一个会随着使用不断成长的知识体。

GenWiki 则尝试让 LLM 参与到一个更长期的过程：在 Obsidian vault 内持续地增量构建、结构化和审计个人知识库，使知识在不断使用中逐渐形成稳定的 Wiki 结构。

它不只是对内容进行一次搜索。它会读取网页剪藏，把新内容和已有笔记结合起来，通过双向链接组织为持久的 Wiki 文件，并持续检查知识库中可能存在的冲突和空缺。

在这个项目中，我尝试结合 LLM 的语义理解能力与脚本化流程，也就是一种面向 LLM 时代的 Skill（脚本化能力层），通过将提示词、规则与自动化脚本组合起来，对文档进行分类、整理并生成双向链接。

3. 自托管 Agent 与移动端应用

这一类项目主要是在探索新的运行环境和产品形态，包括在家中部署 OpenClaw，以及 Retake 和 Pocket Translator 两个 iOS 应用。

在家中部署 OpenClaw

我在家中自行部署了 OpenClaw。

这个过程让我接触了本地部署、自托管、环境配置和服务运行等问题。与普通网页相比，自托管更容易暴露出基础设施层面的复杂性。

很多问题并不来自代码本身，而是来自依赖版本、系统权限、网络配置、运行环境，以及不同服务之间的连接方式。

Agent 很适合帮助阅读部署文档、生成安装命令、编写脚本，并提供问题排查路径。

但最终仍然需要人结合真实机器和真实网络环境，判断问题到底发生在哪里。

在这个过程中，我明显感受到了一种 Skill 的持续进化。

每解决一次环境问题、部署问题或链路问题，相关经验就会被内化为新的能力；这些能力又会反过来影响下一次任务的处理方式。

因此，像 OpenClaw 这样的自托管系统，更像是在“养”一个系统。

它不是部署成功一次就结束了，而是在持续运行、调整配置、调试问题和积累经验的过程中逐渐稳定。Agent 可以给出方向，但最终仍然需要人把系统一点点调顺。

这也让我意识到，Vibe Coding 降低的是系统的创建成本，却不一定会降低系统长期的维护成本。

一个服务可以很快被搭建出来，但依赖会升级、接口会变化、配置会失效，运行环境也可能出现新的问题。每增加一个组件，实际上也增加了一份未来需要承担的维护责任。

Retake：围绕场景复刻的 iOS 相机应用

我还做了一个名为 Retake 的 iOS 应用。

Retake 面向动画圣地巡礼、电影取景地、历史照片匹配和场景旅行摄影。当前版本允许用户选择动画截图、电影画面或旧照片，将其作为半透明图层叠加在实时相机画面上，通过调整透明度和透视关系完成场景对齐，再拍摄一张不包含叠加层的照片。

这个项目的仓库中不仅包含应用代码，也保留了 PRD 和系统设计文档。

这说明即使是一个看起来相对轻量的移动端应用，也仍然需要先明确使用场景、交互流程和系统边界。

Agent 可以帮助快速搭建 iOS 项目框架、实现相机叠加和状态控制，但“用户怎样完成一次自然的场景复刻”，依然是一个产品和交互问题。

Pocket Translator：实时翻译应用

另一个 iOS 项目是 Pocket Translator。

它的核心是调用 Gemini Live Translation API，为用户提供实时翻译能力。

Agent 可以帮助完成 iOS 应用框架、API 接入，以及音频、文本和状态管理相关的代码。即使我对部分移动端技术并不熟悉，也可以较快完成一个可以运行的版本。

但这个项目真正困难的部分仍然是交互。

用户应该在什么时候开始说话？系统什么时候显示翻译结果？怎样让用户知道当前正在录音、识别还是翻译？实时翻译应该怎样避免打断交流？又怎样减少整个流程中的操作步骤？

模型提供的是翻译能力，真正把这种能力变成产品，仍然需要围绕具体使用场景重新设计。

4. 从技术项目走向真实业务

前面的项目大多是个人工具、内容展示、知识管理或交互实验。

PassMap 则开始涉及更加完整的业务系统。它不仅需要产品和工程，还涉及市场调研、商业模式、数据源、内容生产、流量获取、营销转化和数据分析。该网站面向赴日旅行者，以互动地图和地区页面的方式展示日本交通套票，并支持中文、英语、日语和韩语。

从 Deep Research 到产品上线

在正式写代码前，我先用两天和 AI 做了大量市场与竞品分析（Deep Research + 多轮对话），尝试梳理需求、商业模式和产品方向。但事后看，这一步仍然不够：AI 能扩展信息和假设，却无法验证真实用户行为。

随后我用一天搭建了前后端和数据库，这一阶段仍然遵循基本的 PRD、系统设计和功能排期。但很快暴露出问题：数据库 Schema 设计不够早期收敛，导致后续前后端、导入脚本和内容工具多次返工。

接着我又用一天做了内容生产工具，本质上是在补“内容系统”这个最初被忽略的模块。但这个模块在最初设计中并不存在，只能不断在已有系统上叠加功能，导致整体结构逐渐变得松散。

最后一天完成上线。之后工作的重心也从“把系统做出来”，转向数据完善、用户验证，以及 SEO、GEO 和内容与增长层面的优化。

数据与技术架构

PassMap 的网页托管和 CI 构建主要使用 Vercel，数据库使用 Supabase 进行管理和托管。

在数据层面，PassMap 的设计经历了一个明显的数据源迁移过程。最初我考虑使用 OpenStreetMap 作为基础地理与交通数据来源，但在实际评估后发现，日本国土交通省提供的数据更适合该项目的业务场景。这些数据本身已经结构化地包含了铁路线路、站点、城市信息以及各类交通运营商信息，因此在完整性和业务贴合度上更高。

基于这一数据源的变化，我编写了一系列脚本，对原始数据进行清洗、转换与批量导入，使其能够适配后续的数据库结构与查询需求。这一步实际上也决定了后续系统设计的基础形态，因为数据来源的结构直接影响了实体建模方式。

在数据分析与业务追踪层面，我在网页中引入了多种埋点与统计工具，用于观察用户行为与商业转化路径。目前主要包括 Vercel 的页面分析与转化统计能力，以及 Google AdSense 和 Affiliate 联盟管理工具，用于分别追踪流量表现、广告收益与联盟转化效果。

在这一过程中，我逐渐意识到一个关键问题：不同类型的数据指标需要严格分层管理。例如页面访问量、搜索表现、广告展示数据以及联盟转化数据，本质上属于不同业务层级的指标，如果混合在同一分析体系中，会导致对用户行为和商业效果的误判。因此后续需要进一步明确各类数据的归属系统与统计边界。

在技术架构层面，PassMap 采用了典型的前后端分离 + 托管式服务组合。前端与 CI 构建依赖 Vercel，数据库使用 Supabase 进行托管与管理，从而减少基础设施维护成本，并提升部署效率。

在数据模型设计上，系统需要管理多类核心实体，包括铁路线路、站点、城市名称、铁路运营商、航路运营商、巴士运营商以及套票信息等。这些实体之间存在较强的关联关系，因此数据库 Schema 的设计直接影响后续查询效率与数据一致性。

此外，系统还需要支持多语言能力，而这里的多语言并不仅仅是前端 UI 文案的切换，而是数据库层级的多语言建模问题。这意味着同一条套票或站点数据，需要在不同语言之间保持结构一致性，同时支持灵活查询与扩展。

这一设计进一步影响了多个系统层面，包括数据库 Schema 结构、查询逻辑、数据维护方式、内容生产流程以及前后端数据传输量。如果设计不合理，会导致数据冗余增加、查询复杂度上升，以及前端加载性能下降。

因此，后续优化的重点将集中在两个方向：一是进一步优化数据库结构与查询路径，减少不必要的数据冗余；二是优化前后端数据传输机制，降低请求体积与加载延迟，从而提升整体页面性能与用户体验。

商业模式和数据闭环

PassMap 当前考虑的核心盈利模式之一是 Affiliate 联盟分佣。

当商业模式确定为联盟营销之后，产品就不只是展示套票，还需要管理联盟链接、记录用户点击、区分不同来源的转化，并衡量最终产生的收益。

我希望逐渐建立的分析链路是：用户进入页面，在网页中浏览和点击套票，通过页面埋点观察访问行为，再通过联盟管理工具记录后续转化，最终量化内容、流量和商业结果之间的关系。

品牌、用户验证与内容营销

PassMap 下一阶段的工作包括完善首页品牌、Logo、Slogan，以及更加完整地展示套票信息。

与此同时，我也需要更早地接触真实用户，确认当前产品是否真正满足需求。

需要验证的问题并不只是“用户喜不喜欢这个网站”，而是更加具体的问题：用户会按照地区、线路、旅行天数还是价格寻找套票？他们最难理解的是使用范围、价格、购买方式，还是套票是否划算？什么信息不足会导致他们离开？他们是否愿意通过联盟链接跳转购买？

这些问题无法仅靠 AI 对话和竞品研究回答。

在真实用户验证之后，我才会进一步调整产品和内容。

目前，PassMap 的核心流量可能主要依赖 SEO，之后还会针对 GEO 进行优化，再逐步开展小红书、Twitter／X 和 Instagram 等渠道的内容营销。

不过，在开始大量生产营销内容之前，我希望先设计完整的内容生产工具链。

其中包括内容生产 Skill、多语言支持、内容模板、平台格式转换，以及如何把中文内容转化成适合 Twitter／X 和 Instagram 发布的英语内容。

这里给自己的提醒是：不要一开始就直接大量生产内容，而应该先明确内容生产的基本架构、数据来源、审核方式和发布流程。

后续，我也可能把 Admin 中的一部分内容生产能力拆分出来，但这属于更后期的工作，不应该在当前阶段抢占最核心问题的优先级。

二、从做出产品到让业务运转

做完 PassMap 的初始版本之后，我越来越明确地意识到，把一个产品做出来和让一个业务真正运转，是两件完全不同的事情。

Vibe Coding 可以让我很快完成一个网页、App 或者工具，但产品可以运行，并不意味着业务可以产生收益。

代码只是业务系统中的一部分。

1. 商业模式会反过来改变产品

做 Side Project 时，很容易产生一种错觉：只要产品足够好，就会自然获得用户和收入。

但真正需要回答的问题是，钱从哪里来，用户为什么愿意付费，或者什么样的用户行为能够转化为收入。

以 PassMap 为例，如果商业模式是联盟分佣，那么产品就不仅需要展示套票，还需要管理联盟链接、记录点击、追踪转化来源，并计算最终结果。

商业模式一旦发生变化，系统功能、数据库结构、内容策略和分析方式都会跟着变化。

因此，商业模式并不是产品完成以后再考虑的附加问题。它从一开始就会影响产品应该怎样设计。

2. 内容生产本身就是一个系统

在 PassMap 开发初期，我把重点放在前端、后端和数据库上，却没有充分意识到内容生产本身也是一个大型模块。

一个内容型产品运行之后，需要持续进行内容录入、编辑、图片处理、翻译、审核、更新和多平台发布。

这意味着内容生产不能只是临时编写几个脚本。

它同样需要需求分析、数据结构、工作流设计、自动化工具和人工审核机制。

从这个角度看，内容生产工具本身也是一个软件工程项目。

3. 工具需求来自真实业务摩擦

很多工具并不是一开始就计划开发的，而是在业务推进过程中才发现必须存在，是因为业务流程中真实存在摩擦。

为了导入交通数据，需要批量处理脚本；为了生产套票页面，需要 Admin 内容工具；为了做多语言营销，需要翻译和内容转换能力；为了衡量效果，需要埋点和数据分析；为了管理分佣，需要 Affiliate 管理工具。

判断一个工具是否有价值，应该看它是否解决了当前业务中的真实问题。

4. 意识到业务复杂，不代表同时做完所有事情

一个真正运转的业务，通常可以分成几个层面来看：基础设施层面包括域名、邮箱、公司注册、数据库、前后端架构与持续集成；数据与内容层面包括多语言支持、数据源接入、数据维护，以及用户内容生产与个人内容生产；产品与体验层面包括交互优化与用户反馈机制；商业与增长层面则包括支付、金融注册与金融渠道，以及数据分析、SEO、GEO 和内容营销。

但是，意识到业务复杂，并不意味着所有事情都应该同时完成。

早期产品更需要找到一个最小的业务闭环。

对 PassMap 来说，这个闭环可以被概括为：

用户通过搜索或内容进入网站，找到适合自己的套票，点击联盟链接，完成后续购买，并产生可以追踪的分佣。

围绕这个闭环，当前真正重要的问题是：套票信息是否准确，页面能否帮助用户完成决策，搜索能否带来真实用户，联盟点击能否被正确追踪，以及用户最终是否发生转化。

相比之下，公司注册、复杂的内容自动化、完整的后台拆分和更高级的数据系统虽然可能重要，但不一定属于当前阶段最需要解决的问题。

业务虽然复杂，每个阶段真正的瓶颈通常只有少数几个。

5. 用户验证应该更早发生

Deep Research、竞品分析和与 AI 多轮讨论，能够帮助形成假设，却不能证明假设成立。

用户调研也不应该只出现在产品全部完成之后。

在更早的阶段，可以通过少量访谈、落地页、搜索数据、页面点击和真实内容，验证用户究竟在寻找什么。

这样可以避免围绕一个未经验证的需求，快速生成大量功能和代码。

Vibe Coding 降低了试错成本，但这并不意味着应该用完整系统验证每一个假设。很多问题可以先通过更小的实验解决。

三、对 Vibe Coding 时代的重新理解

1. AI 降低了实现门槛

Vibe Coding 最大的变化，是个人可以很快把一个想法变成可以运行的产品。

即使面对不熟悉的语言、框架、数据库、跨平台应用、iOS 开发或插件系统，也可以借助 Agent 快速完成初始版本。

过去可能需要先花很长时间学习技术栈，现在可以一边开发，一边让 Agent 帮助理解和实现。

这极大提高了个人做项目的速度，也让一个人能够同时处理过去需要不同角色完成的工作。

但它本质上仍然是一个效率放大器，最终放大的不是“能力本身”，而是输入的想法与创意质量。如果方向和创意本身是模糊或低质量的，AI 只会更快地把这种不确定性变成一个完整的系统。

2. AI 不仅放大生产力，也会放大决策质量

实现速度变快，并不意味着软件工程的基本原则变得不重要，反而更需要被严格遵循。

恰恰相反，当代码可以被快速生成时，软件工程中的“错误传播速度”也被同步放大：一个早期不合理的决策，会在短时间内扩散到整个系统的各个层面。

从软件工程的角度看，这本质上是技术债务的提前加速显现。例如在需求阶段没有做好清晰的需求管理（Requirements Management），或者在 PRD 中没有明确边界条件与非功能性需求（如性能、可扩展性、数据一致性），都会在后续开发中被 Agent 快速“规模化实现”，从而放大问题。

如果数据库 Schema 在系统设计阶段（System Design）没有被充分建模，那么 Agent 会基于这个不完整甚至错误的结构，迅速生成前端、后端、API、数据脚本和业务逻辑。此时问题不再局限于数据库层，而会扩展为跨层级的系统性重构成本。

同样，在缺乏合理架构设计（Architecture Design）和模块划分的情况下，快速生成的代码往往会形成强耦合结构，使得后续的迭代、扩展和重构成本显著上升。

因此，传统软件工程中的关键实践并没有因为 Vibe Coding 而失效，反而变得更加关键：

需求管理（Requirements Management）：明确用户问题、边界条件与验收标准，而不是仅停留在功能描述
系统设计（System Design）：在实现之前定义数据模型、模块边界与依赖关系
敏捷开发（Agile Development）：通过小步迭代持续验证假设，而不是一次性完成大规模实现
验证与测试（Testing & Validation）：通过单元测试、集成测试与端到端验证控制 AI 生成代码的不确定性
持续集成与上线流程（CI/CD & Deployment）：确保每一次变更都可追踪、可回滚、可验证
可观测性与监控（Observability & Monitoring）：通过日志、指标与链路追踪持续理解系统真实运行状态
安全与数据治理（Security & Data Governance）：明确数据流向、权限边界与隐私处理方式，控制外部模型与服务带来的风险

在这个意义上，Vibe Coding 并没有削弱软件工程的重要性，而是改变了它的作用方式：从“限制开发速度的约束”，变成“防止系统性错误被快速放大的控制机制”。

Vibe Coding 减少的是代码实现成本，而不是系统复杂度。系统复杂度不仅没有消失，反而因为生成速度提升而更快显现。

更准确地说，AI 不仅会放大生产力，也会放大早期决策的质量。

在软件工程体系正确的情况下（需求清晰、架构合理、测试完善、发布流程规范），Agent 能够快速放大正向收益；但在工程基础薄弱的情况下，它也会以同样的速度放大设计缺陷、架构问题与技术债务。

3. 提前设计，不等于把所有事情都想清楚

PassMap 的数据库返工让我意识到 Schema 需要尽早设计，但这并不意味着项目开始前应该把所有功能和架构一次性想清楚。

人在项目早期不可能了解全部需求，很多问题只有在真正实现、使用和测试后才会暴露。

更合理的做法，是提前识别修改成本高、影响范围大、未来难以迁移的决策。

核心数据实体、实体之间的关系、唯一标识、多语言结构、权限边界、数据来源、更新机制和关键转化事件，都值得较早设计。

而次要页面样式、低频自动化、非核心后台功能和未经验证的复杂功能，则应该保持可调整，甚至故意推迟。

真正重要的是判断哪些决策一旦错误，会产生最大的返工成本。

4. 需求变更与重构：软件复杂性不可消除，只能被管理

即使前期进行了设计，开发过程中仍然会出现需求变更、功能调整、数据结构变化和代码重构。

这并不一定代表前期设计失败。

从软件工程的基本共识来看，这其实是系统复杂性的必然结果。正如 Brooks 在《No Silver Bullet》中所指出的，软件开发中不存在能够显著降低复杂度的“银弹”，因为软件的本质复杂性（essential complexity）来自问题本身，而不是实现方式。换句话说，无论使用多先进的工具、语言或 AI，系统的复杂度都不会被消除，只会在不同层级之间转移。

软件系统本身具有不可消除的复杂性（inherent complexity）。人不可能在项目开始时就完全掌握所有“未知的未知”（unknown unknowns），也无法在缺乏真实使用反馈的情况下穷尽所有边界条件。因此，很多需求只有在系统被实现、被测试、被真实使用之后才会逐渐显现。

从这个意义上说，重构并不是失败的标志，而是软件演化过程的一部分。正如持续演进式设计（evolutionary design）所强调的，系统不是一次性构建完成的，而是在不断反馈中逐步逼近合理结构。

因此，返工和重构无法完全消失，也不应该被视为异常。更现实的目标，是在承认复杂性不可消除的前提下，尽可能降低其扩散成本：例如提前保护核心领域模型、稳定关键数据结构、控制高耦合边界，同时允许非核心模块保持可变性与可替换性。

换句话说，软件工程不要期望消除变化，而是要管理变化；复杂度无法消除，但是在不可避免的复杂度中建立结构化的秩序。

5. Agent 可以参与思考，但人承担最终责任

简单地说“Agent 负责实现，人负责判断”并不完全准确。

Agent 不只是写代码。它也可以辅助需求讨论、竞品研究、架构分析、风险识别、测试设计和数据分析。

但人需要定义目标、提供上下文、建立约束和评价标准，并对最终结果承担责任。

Agent 可以生成多个交互方案，但人需要明确什么样的交互才算自然；Agent 可以提出多个系统架构，但人需要判断哪一个更容易维护；Agent 可以实现商业功能，却不能自动证明商业模式成立。

真正无法外包给 Agent 的，并不是某一种具体操作，而是对目标、取舍、风险和结果的责任。

6. 人的工作从生产转向编排和验收

在 Vibe Coding 时代，人仍然需要承担几个关键角色。

首先是把握方向。人需要决定做什么、不做什么、先做什么，以及项目最终要走向哪里。

其次是建立审美和评价标准。页面是否美观、信息是否清晰、交互是否自然、内容是否统一，都需要具体的判断标准，而不只是模糊的感觉。

再次是监督和验收。Agent 生成的功能需要经过人工检查，边界情况、数据错误和真实用户体验都不能仅凭代码已经运行来判断。

最后是方案选择。Agent 可以生成大量候选方案，人必须判断哪个方案更符合需求、更容易维护，也更值得投入。

因此，人的角色更像是编排者、评审者和最终责任人。

四、进一步复盘后，我意识到自己还忽略了什么

除产品、系统和业务之外，还有一些问题，是我在进一步复盘这些项目后才更加明确地意识到的。

1. 可验证性比“代码能运行”更重要

我过去更多强调人工验收，但随着 LibrisArk 和 PassMap 变得复杂，仅靠人工点击页面已经无法覆盖所有情况。

Agent 生成代码时，也应该同步考虑测试、类型检查、数据校验、日志、错误监控、数据库迁移和回滚机制。

对于数据导入，需要确认数据数量、唯一性、关联关系和异常值；对于核心业务功能，需要提前定义什么结果才算正确；对于线上系统，需要能够发现错误发生在什么时间、影响了哪些用户，以及应该如何恢复。

Vibe Coding 的成熟程度，不应该只看代码生成得有多快，也应该看生成结果是否容易验证。

2. 创建成本和长期所有权成本不是一回事

AI 让增加功能变得非常容易。

但每增加一个模型、云服务、API、框架、数据源、自动化脚本或外部平台，也意味着未来多承担一份维护责任。

PassMap 使用 Vercel、Supabase、分析工具、AdSense、Affiliate、外部交通数据源、多语言数据库和内容工具。每一个单独看都不复杂，但组合起来会形成持续的运维和维护成本。

服务可能调整价格，API 可能变化，数据源可能停止更新，脚本也可能在没有人注意时失败。

因此，Vibe Coding 降低了创建成本，却不一定降低长期所有权成本。

创建一个功能之前，除了考虑它现在能带来什么，也应该考虑未来是否愿意继续维护它。

3. 安全、隐私和数据责任不能被速度掩盖

LibrisArk 会读取用户的论文和批注，Pocket Translator 会处理声音和翻译数据，OpenClaw 涉及本地服务、网络和 API Key，PassMap 则使用外部数据源并生成面向用户的信息。

这些项目都涉及安全、隐私和数据责任。

需要明确哪些数据会发送给第三方模型，数据存储在哪里，API Key 如何管理，服务是否暴露到公网，外部数据是否允许再次加工，以及自动生成的内容出现错误时由谁负责。

AI 可以让功能迅速完成，但功能越接近真实用户，就越需要对数据和结果承担责任。

4. 项目越容易开始，越需要学会停止

Vibe Coding 降低项目启动成本后，我遇到的新问题可能不再是“没有能力实现”，而是项目越来越多。

个人网站、Gallery、地图、LibrisArk、GenWiki、OpenClaw、Retake、Pocket Translator、PassMap，以及不断被重新整理的历史项目，都会占用注意力和维护精力。

同时还有一个更隐性的状态：因为实现变得太容易，很容易进入持续兴奋的开发状态，沉迷在 Vibe Coding 的即时反馈里，经常不自觉地熬夜推进项目。短期看效率很高，但从长期来看，这并不是一个可持续的工作方式。

因此，需要区分哪些项目只是学习实验，哪些用于作品展示，哪些是自己长期使用的个人工具，哪些是真正准备持续经营的商业项目。

学习实验完成目标后可以结束；作品展示只需要保持可访问；个人工具根据自己的使用频率维护；商业项目则需要围绕用户、收入和长期运营持续投入。

当创造变得容易，选择不做什么、停止什么、以及控制投入节奏（包括时间和精力），反而会变得更加重要。