Vibe Coding的大坑
现在网上很流行所谓的“不懂代码也能创建产品”，“文科生也能做开发”，“十分钟把你的想法做成现实”，看上去很美好，测试一下似乎也没什么问题。
但是实际有人敢上线运营吗？
要么把用户密钥用明文写进了日志，要么加个小功能的时候原来的功能不知道哪儿就崩了，要么有个地方把全量的异常全吞掉导致问题根本就查不下去……
这就是我在改造一个现有的工作流项目时所遇到的问题。
如何避免
90% 的代码事故不是 AI 写得不好，而是因为没有合适的、有边界、可落地、可校验的工程指引文件。
我手上这个项目是用 Copilot Vibe Coding 出来的，但是里面没有任何的工程文件，只是纯粹用自然语言引导生成的一个项目。
这种所谓的“原生态 AI 编程”，虽然运行起来可能没问题，但代码质量非常堪忧。
全程所有的约束都是以自然语言输入，但 AI 的上下文有限，说到后面往往它就会把前面的忘掉。
而且我们也很难时时把相关约束都记在脑子里，然后下次一起给 AI。
这样就会出现非常多的令人哭笑不得的问题，甚至是致命的。
其实，只要有一个项目规则文件，简单写几句话，就能解决大多数问题。
使用 cursor 就是 .cursorrules，使用 Copilot 就是 .github/copilot-instructions.md。
我们来看看具体的案例，再看如何通过简单的项目约束文件来解决它们，让不会代码的人也可以做出相对可用的项目。
实例一：日志系统
如果我们正式做项目，一般的做法是建立一个专门打印日志的文件并提供接口。在项目中的其他地方调用这个接口，这样可以实现统一的日志打印。
我们会在这个文件里去做格式化（比如增加日期、时间、文件行数等参数），也会做日志的性能优化，例如通过增加缓存、待积累到一定程度后再一次性将缓存写入文件，以提高性能。
通过一些标志位或者宏定义，就可以定义日志级别，从而针对不同的阶段打印不同的日志。
而在更大的系统中，日志模块会是一个非常重要的部分，所有相关的应用都会通过这个模块打印日志。
如果不做任何限制，AI 最大可能就是直接打印到控制台。
更可怕的是，AI 在没有提醒的情况下，并不会分辨当前打印的信息是什么内容。
落地的日志中，就很可能会有明文的用户名、密码、IP 地址等等敏感内容。
没有把这些东西直接发出去就算烧高香了。
解决方案也很简单：直接项目规则文件中，用自然语言加一两行规则就好。
实例二：新增 Feature
使用 Vibe Coding 的好处，是实现代码的成本非常低。
即使生成出来不好用，继续修改迭代就好，实在不行重新生成一份也不费劲。
但是，如果不把 AI 改动的范围限定好，它很可能会把原本好好的功能和逻辑改成一团麻。
结果就是只想给页面加个返回按钮，然后发现原本页面上的 Blog 列表不知道哪里去了。
要解决这种问题要从两方面入手：
一是做好版本控制，万一不行直接回退，不要完全依赖于 AI 自己的回退机制。
二是在项目规则文件中，明确指定 AI 可以操作和修改的范围。
实例三：异常处理
我们都希望代码运行时不会出现异常，一切都可以正常运转，但是事实往往不会这么顺利。
出问题的时候，有价值的异常信息，可以帮助快速定位和解决问题，无论是对真人还是 AI，都是非常重要的。
但是放任 AI 去处理代码逻辑，它会搞一个大型的 try - catch，最后直接输出一些没有意义的内容。
像这种错误日志，神仙来了都得皱眉。无论是给人还是给 AI，都找不出问题在哪里。
所以，要在规则文件中指明，不可以用这种粗暴简单的方式处理异常。
总结：不懂代码怎么处理
- 一，建立自己的 Vibe 工具的对应项目规则文件。如果不知道如何建立——问 AI。
- 二，还是要学会版本控制。其实很简单，先会 git add, git commit -m "add file", git push 就可以了。做某些重大变化前，先走一套这三个命令。万一如问题要回退，再去查怎么办。
- 三，根据项目当前的编程语言和开发工具，在规则文件中添加相应的规则说明。即使不完善，也比没有规则强。实在不知道怎么写，先问自己的 Vibe Coding 工具用的是什么语言，然后找免费的大模型去问一套规则文本，或者直接找一个现成的规则文件，放到指定位置就可以了。附录里是一段跨编程语言通用的规则说明，可以直接复制作为参考。
附：项目规则示例
# Vibe Coding 工程指引 (General Rules)
## 1. 日志与安全 (Logger & Security)
- **统一接口**：禁止使用原生的 `console.log` 或 `print`。必须调用项目定义的封装日志接口。
- **脱敏原则**：绝对禁止将用户密码、API Key、私钥、个人隐私（Email/手机号）以任何形式打印到日志或控制台。
- **格式化**：所有日志必须自动包含 [时间戳]、[日志级别]、[文件路径:行号]。
## 2. 改动边界 (Code Scope & Modification)
- **修改范围限制**：除非显式要求，否则 AI 仅允许修改当前任务涉及的文件。严禁为了实现小功能而重写无关的核心架构文件。
- **不可变保护**：禁止修改 `src/core` 下的基础配置和协议定义，除非得到明确指令。
- **增量原则**：优先通过增加新函数或新文件来实现功能，而非修改已有的稳定函数。
## 3. 异常处理 (Error Handling)
- **拒绝沉默失败**：严禁使用空的 `try-catch` 或只打印 "Error occurred"。
- **可追溯性**：Catch 到的异常必须记录原始 Stack Trace（堆栈跟踪），并提供足够的上下文信息（如：在执行 X 操作时，参数 Y 导致了失败）。
- **逻辑重试**：关键网络请求必须包含超时检查和合理的重试机制。
## 4. 交付质量 (Quality Control)
- **测试前置**：对于逻辑复杂的函数，在修改后必须生成/更新对应的单元测试，并确认测试通过。
- **自说明代码**：变量名必须具有语义化，禁止使用 `a`, `b`, `tmp` 等无意义命名。复杂的逻辑必须附带简短的注释说明其“为什么这么写”。
## 5. 开发工作流 (Workflow)
- **原子化提交**：每完成一个子功能或修复一个 Bug，请提醒用户进行 Git Commit。
- **上下文刷新**：当任务完成或转向新功能时，请主动建议用户清理或刷新会话上下文，以防旧逻辑干扰。
