Vibe coding：用途与局限

给员工探索开发的空间

企业 CTO 可以帮助更多员工把专业知识转化为软件构想。邀请财务、运营、销售和工程团队参与。为他们提供时间、合成数据、沙箱 API 和支持。

在工具安装、账户和允许输入的内容上划清边界，再让员工使用不同工具探索。浏览器中的应用构建工具、编程助手或本地智能体，都可以帮助验证想法。选择了工具，不等于获得了上传公司信息或连接真实系统的许可。

公布一条简单流程，让员工把有用的原型交给工程或平台团队。原型创建者提供问题、示例工作流和观察到的价值。他们不需要同时承担该服务的安全和运维职责。

明确需要了解什么

Vibe coding 通常从描述想要的软件开始。使用者接受生成的代码，再根据看到的结果决定下一次修改。这个术语有不同含义。在本指南中，指导开发的人不一定理解每项实现决策。

这种方法有助于学习。简单界面可以揭示审批流程中的步骤过多。临时脚本可以帮助评估文件格式。原型为讨论提供具体设计。即使丢弃代码，也可以保留这些认识。

先提出一个能够通过观察回答的问题。例如：“团队经理能理解这个审批流程吗？”这个问题的范围清楚。而要求开发一套费用管理系统，还涉及数据保护、访问控制、运维和责任归属。

周二做出的银行应用原型

看一个虚构案例。周二，一位财务同事用 Lovable 和虚构的银行交易做了一个仪表板。它按类别汇总支出，并显示未付发票。团队由此可以讨论一套有用的工作流。

有人建议连接公司的银行账户。即使应用仍被称为“原型”，这样做也会改变其后果。

只读权限可能暴露余额、交易记录、客户姓名或名称，以及付款参考信息，具体取决于 API。如果连接还允许付款，错误就可能导致真实资金转出。确认实际权限范围；银行连接不一定包含付款权限。

演示不能证明用户只能看到获准访问的账户。隐藏按钮不能强制执行权限控制。OWASP 说明了缺少账户或记录级检查为何会暴露其他用户的数据。

对于付款 API，幂等性是指重复请求不会再次产生预期效果。Stripe 文档介绍了一种实现。检查实际服务提供方的行为、限制和重试规则。回滚应用不会撤销银行已处理的付款。

这个案例不能证明 Lovable 存在缺陷。Lovable 自身的安全指南要求保护秘密信息、执行服务端检查、测试数据策略并持续审查。对任何应用构建工具、智能体或手写应用，都应采用相同的证据标准。

连接真实系统前检查访问权限

继续使用合成数据和沙箱账户测试工作流。在授予真实系统的访问权限前，让服务、安全和平台负责人验证应用及其运行环境。

采用银行或服务提供方批准的连接流程。仅授予必要的账户访问权限和操作权限。把私有凭据存放在获准的秘密信息存储系统中，不要放入提示词或浏览器代码。需要付款时，明确审批要求和限额。验证如何撤销访问权限、调查故障和应对可疑活动。

这些决策应在机密信息或真实凭据进入系统之前完成。等到正式生产发布时再处理，可能已经太迟。接下来学习数据边界和企业基础设施。

扩大使用范围前明确职责

使用虚构数据的实验可以只运行很短时间，也可以只供少数人使用。当其他人开始依赖这个应用时，就要明确使用过程中的职责。

1. 指定负责人。
2. 明确允许的用户和数据。
3. 确定发生故障时如何响应。
4. 将源代码和配置保存在代码仓库中。
5. 验证其他人能够检查并重现该系统。

不是每个脚本都需要企业平台。不处理敏感数据的个人格式化工具，所需控制措施少于付款审批应用。评估错误的后果。检查能否发现错误，以及能否逆转其影响。

扩展原型之前，区分对问题的认识与有关实现的证据。可以保留界面并替换内部代码，也可以限制预期用途，还可以让原型继续只作为临时实验。

为演示后的漏洞管理做好准备

成功的演示可能掩盖严重的维护缺口。即使代码没有变化，依赖也可能出现新的漏洞公告。发布时的扫描只反映某个时间点的情况。

如果应用仍在使用，就必须有人持续发现、评估和修复漏洞。修复必须部署到生产环境，并通过验证。只有扫描器，却没有这套响应流程，就无法消除尚未处理的风险暴露。

检查实际工具和配置提供了哪些能力。后面的持续漏洞管理课程会说明完整流程，包括扫描失败和已部署版本。

让下一次修改易于审查

给智能体一项小范围修改，并明确验收标准。说明智能体可以执行哪些操作。检查生成的 diff。执行能够拒绝错误实现的检查。在发布职责明确之前，将部署保留为单独的决策。

NIST 安全软件开发框架介绍了更广泛的安全开发实践。评估缺失的控制措施时，可以将其作为参考。不需要背下整个框架。需要的是在软件影响其他人之前，识别还缺少哪些证据。