Vibe Coding 技术债：修复还是重建应用？

当一个有用的原型变成他人依赖的软件时，Vibe Coding 技术债就会显现。应用看起来仍然很有说服力，但小改动会破坏另一个页面，没人能解释哪个数据库才是权威来源，采购维护服务的人也无法判断下一份方案是在修复，还是要重新开始。

如果重要业务流程能够被理解、重现和改进，且不会造成无法接受的中断，就适合修复 Vibe Coding 应用。当结构性问题阻碍这种进展时，可以考虑分阶段替换，并将数据迁移和业务连续性纳入比较。应依据应用的实际证据决策，而不是依据最初编写代码的方式。

人们确实对这种开发方式感兴趣。Google 在其 Vibe Coding 课程公告 中报告了美国搜索兴趣的增长，并将规划、测试和调试列为学习内容。这证明这种方法受到关注，但不能证明你的应用存在缺陷，也不能证明重建的收益能抵消成本。

本指南面向已有可运行应用、却不确定下一步该怎么做的创始人和运营团队。它提供委托评估、比较方案以及保留原型已带来经验的方法。下文的咨询接收应用是假设示例，并非客户案例，也不是经过测量的投资回报。

从后果识别 Vibe Coding 技术债

技术债是对某些设计和实施选择的简要称呼，这些选择会让后续修改更昂贵或更有风险。有些选择是有意为之：在确认客户是否需要服务时，原型可能先采用简单的人工流程。真正的问题是，当限制已经明显影响业务后，仍继续依赖这种选择。

寻找可以观察到的后果。开发者能否重现报告的故障？团队能否不手动修改线上数据库就发布变更？记录是否有稳定标识符，还是不同页面对同一客户有不同理解？这些问题能将情绪化的代码质量争论，转化为可以审查的维护问题。

区分症状与解释

假设某个客户咨询接收应用有时会创建重复咨询。症状是重复记录，可能原因包括重复提交表单、重复集成事件或不一致的记录匹配。让助手删除可见重复项，可能改善页面，却没有改变底层操作。

记录发生了什么、哪条路径导致问题，以及团队如何发现它。然后要求可重现的解释。AI 编写过部分代码，并不足以确定原因；生成文件数量很多，本身也不是丢弃它们的理由。

明确实际掌握什么以及能重现什么

比较修复与替换前，盘点代码仓库、托管、数据库、域名、第三方集成和管理账户。确认每项由谁控制，以及另一位开发者能否通过约定流程取得所需访问权。不要将凭据写入评估文档。

要求评估者依据记录的源代码和配置文档构建并运行应用。如果线上服务依赖仅存在于托管控制台的变更，应明确列出。看起来完整的代码仓库，仍可能无法描述客户实际使用的系统。

十二要素应用的配置指南 将部署专用配置与应用代码分开。利用这一区分要求配置清单，同时避免把秘密信息放入仓库或评估简报。记录每项设置由谁控制，以及接替团队如何取得访问权。

十二要素应用的开发与生产一致性指南 解释了环境差异为何会导致部署问题。应将原则用于应用的实际服务和支撑系统。本地演示使用不同存储或配置，只能为生产修复会有相同行为提供很弱的证据。

让一条重要流程变得可理解

选择业务已在依赖的一条路径。在咨询接收示例中，访客提交咨询，同事审核，批准后的记录进入 CRM。映射沿途的输入、记录标识符、转换和外部影响。纳入拒绝的提交及人工干预。

追踪完整路径

应用的成功提示可能出现在 CRM 接受记录之前。如果业务将该提示视为交接完成的证明，缺陷部分来自结果设计。修复应明确成功的含义，以及目标系统未确认时用户会看到什么。

约定如何发现不确定情况，以及由谁负责。可能已到达目标系统的记录，在重放前需要检查。这类澄清可能比界面的外观重写更有价值，因为它改变了团队处理实际工作的方式。

将路径转化为验收证据

使用覆盖获准、拒绝和不确定结果的真实情境示例。验收测试应展示业务规则，例如再次收到同一提交时保留原咨询编号。避免仅重复实施的当前行为，却不判断该行为是否正确的测试。

保留有用的产品经验。客户理解的措辞、员工实际使用的字段、已发现的异常路径，即使某个组件需要替换，也可能值得保留。丢弃这些知识的重建，可能只是在更整洁的仓库中重演旧错误。

对比针对性修复与分阶段替换

要求评估者依据相同验收要求解释备选方案。当问题边界可以隔离，且周围流程可理解时，修复可能适合。当所需变更不断跨越不一致的数据模型或无法突破的平台限制时，替换可能有充分理由。

这些是评估标准，不是自动评分系统。关键流程的严重缺陷可能比其他地方的多项小改善更重要。决策还取决于业务能承受多少中断，以及应用是否仍在验证市场。

应警惕尚未检查数据和发布流程就宣布重建的方案。同样，也应警惕不解释下一位开发者如何验证变更的修复承诺。两种方法都需要一条可信路径，将当前应用带到可验收的运营状态。

将安全审查作为独立工作流

可维护性与安全性有交集，但回答不同的问题。容易修改的代码仍可能泄露其他客户记录。权限修复可以降低安全风险，却不一定让部署或维护可预测。应用同时需要两者时，应分别界定范围。

OWASP 应用安全验证标准 为验证应用安全控制和定义要求提供基础。它可以帮助组织评估中的安全部分。完成检查表本身，不能证明业务流程可维护，也不能证明所有风险已消除。

我们的 Vibe Coding 安全审计指南 更详细地解释了该审查。对于这里的修复决策，应要求区分紧急遏制、针对性修复和长期设计变更的发现。如果报告把每个问题都当作重写整个应用的理由，就更难判断优先级。

如果有真实事故的迹象，应保留调查证据。日常维护规划不应覆盖日志，或重置事故负责人需要检查的环境。在把所有无法解释的行为当作普通技术债之前，先确定当前状况。

批准替换前规划迁移

如果没有数据和切换计划，替换估算就是不完整的。明确权威记录、附件、客户账户、外部标识符，以及进行中工作的状态。决定哪些历史需要迁移，团队如何验证迁移后的含义。

GitHub 的仓库备份指南 区分镜像克隆，与备份 Git LFS 对象及 Wiki 所需的额外工作。因此，源代码备份只是清单的一部分。在把代码导出当作恢复计划之前，单独盘点应用的线上数据库、上传文件和外部服务。

证明目标系统能保留流程

使用受控数据演练，并比较源端与目标端记录。除总数外，还要检查关联关系和运营状态。咨询关联到错误组织，即使记录数一致，也仍然是错的。记录有意进行的转换，避免被误认为信息丢失。

没有明确协调计划时，避免让相互竞争的写入者处理同一业务流程。分阶段替换期间，定义哪个系统负责每项操作，以及变更如何跨越边界。否则，迁移可能制造项目原本想消除的重复工作。

定义停止条件

约定哪些证据允许切换，哪些情况会使其停止。考虑记录缺失、访问权限错误、集成未确认，以及无法接受的人工工作。定义谁作出决定，发布延期时工作如何继续。

回滚不仅是重新部署昨天的界面。新系统一旦更改记录或触发外部操作，旧应用可能无法理解新的状态。要求供应商解释实际业务发生后的恢复方式，包括无法自动撤销的变更。

比较整个变更的成本

要求以 GBP 计价的明确范围方案，将评估、修复、测试、迁移和交接分开。纳入对源代码访问权及数据导出能力的假设。依据尚未调查的仓库报固定价，可能只是在隐藏不确定性，而非消除它。

纳入业务方自身的工作：审核示例、准备数据、培训同事，以及过渡期间管理异常。即使没有出现在开发者估算中，这些活动也会占用人力。应明确描述，而非编造通用重建价格或承诺生产率提升。

最便宜且可信的选项，是以可接受的持续管理负担满足约定结果的方案。有时是集中修复，有时平台限制使替换成为实际选择。评估应给你足够证据，让你理解原因。

委托可维护的下一步

准备应用 URL、故障流程的脱敏示例、仓库控制权详情，以及问题的业务后果。说明接下来需要哪些改动，现有产品哪些部分已表现良好。这能为评估者提供具体调查对象。

要求初始交付包含可重现的发现、修复和替换选项、假设、验收标准，以及剩余不确定性的说明。这比委托无人能描述终点的开放式清理，更适合做采购决策。

我们的软件开发服务 是讨论应用修复、集成变更或分阶段替换的起点。如果团队间正在移交访问权、代码和运营知识，我们的软件项目接管指南 也说明了交接时应要求什么。

要讨论你的应用，请向我们提供开始难以操作或修改的流程 。我们可据此界定评估范围，以及作出修复或重建决策所需的证据。目标是团队能够掌握和运营的软件，并理解其剩余限制。

常见问题

什么是 Vibe Coding 技术债？ Vibe Coding 技术债指 AI 辅助应用中，让后续变更更困难或更有风险的实施与设计选择。应通过可重现性、流程行为、数据完整性和管理责任评估，而不是假定所有生成代码都需要替换。

Vibe Coding 应用总需要重建吗？ 不是。当重要流程可理解，且缺陷能隔离并验证时，针对性修复可能适合。替换建议应解释结构限制、备选方案、迁移工作和运营后果。

聘请开发者修复应用前应检查什么？ 确认对源代码、托管、数据和集成的控制权，然后提供可重现的问题示例。要求验收标准、安全发布方式，以及其他开发者可以使用的交接材料。

如何比较修复与重建成本？ 依据相同业务结果比较范围明确的 GBP 方案。包括调查、实施、验证、必要迁移、内部员工时间和持续管理责任。省略数据过渡的替换价格，不是完整比较。

安全审计足以证明可维护性吗？ 不能。安全审计评估约定范围内的控制。可维护性还需要证据，证明应用能够被重现、修改、发布、恢复和交接，并且重要业务流程已被理解。

评估期间应停止使用应用吗？ 不应自动停止。当具体风险要求时，约定遏制或限制措施。评估应解释哪些操作可以继续，以及谁负责异常。

替换后端时可以保留现有设计吗？ 这通常是值得调查的选项。保留客户理解的界面决策，再测试替换系统是否保留其含义。当验证、记录责任或集成时序变化时，熟悉的页面仍可能表现不同。应将这些行为纳入验收测试，而不是把外观相似视为等效证明。

原平台无法导出全部内容怎么办？ 确定替换范围之前，先查明缺失的记录、文件和关联关系。要求基于证据的导出演练，记录哪些部分仍需手动处理或无法访问。业务可能需要分阶段过渡、暂时访问旧系统，或缩小替换范围。不要假定未经测试的导出将会可用，就安排最终切换。任何未解决限制都应写入方案和验收条件。

首次评估应交付什么？ 可重现的发现、修复与替换选项、明确假设、验收标准，以及范围明确的下一步。它应解释还有什么未知，以及哪些证据会改变建议。