Vibe Coding 技巧_2025_08_26
用 AI 自己来“打磨”你的需求说明（Prompt）
假设我想让 Windsurf 做一个用户与工单列表页面。很多人会随手丢一句含糊的请求，比如：
新增一个页面展示全部用户；点击用户能看到他的请求及 ID；点开请求可以关闭或回复，同时看到全部对话；用 React 组件划分结构；服务层请求 API，API 再调 Supabase SDK……
这对人和 AI 都不够清晰。更好的做法是——就让 AI 来优化 Prompt，把任务拆清楚：
🧩 任务：用户请求管理页（Angular + Supabase）
🖥 页面目标：新建一个页面，展示并管理用户请求
👥 用户列表
- 组件：UserListComponent
- 点击用户：加载该用户的请求，展示请求 ID 列表
📄 请求详情
- 组件：RequestDetailComponent
- 展示整段会话历史
- 支持两类操作：回复、关闭
⚙️ 架构
- 组件模块化：UserListComponent 发出选中事件 → RequestListComponent 渲染请求 → RequestDetailComponent 处理会话与操作
- 统一的 UserRequestService 负责 API 调用
🔗 API（例如 /api/user-requests）
- 能力：获取用户列表 / 按用户取请求 / 按请求取消息 / 提交回复 / 关闭请求
🗄 Supabase 集成
- 用 Supabase JS SDK 查询 users、requests、messages
- insert 新回复、update 请求状态（如 closed=true）
这样做的好处是：你能先验证 AI 是否真正理解你的目标，再让它开工。一个好的 Prompt，应该做到：
- 拆分任务与分层，前后端职责清楚
- 命名具体（组件、服务、路由、表结构）
- 动作明确（允许操作、触发条件、状态变更）
- 技术栈落地（Angular/Supabase/接口路径）
- UI 行为与数据模型都有交代
- 语言简短、祈使、避免长复合句
让 AI 记录“经验库”
我给 AI 设了一条规则：
LEARNING 做任务时，识别能让下次更快完成的关键信息（例如项目结构、文件位置、常见坑），写进项目里的 ai-learnings.md，并在后续任务引用。
如果它没写，我会显式要求：请把刚才任务的要点补充到 ai-learnings.md。久而久之，你会得到一份专属于项目的“AI 工作手册”。比如某个项目里，它总结了：
- 前端：Angular 17+（Standalone Components；@if/@for）
- 服务层负责 API 与状态；组件只与服务通信
- 注入统一用 inject()，不用构造器注入
- 系统消息统一走 SystemMessageService.showMessage()
- 默认不展示成功提示，除非明确要求
- 随着迭代，模式、服务、组件职责都会被梳理得越来越清楚，AI 下次就能更快对齐。
随着迭代，模式、服务、组件职责都会被梳理得越来越清楚，AI 下次就能更快对齐。
保留一份“团队规则”，随用随更
有些规则靠你来定更快——我会维护一份“规则清单”，项目里通常有 30 ～ 500 条，也会附带数据库 Schema。示例：
- 用 pnpm，不要用 npm
- 不在生成代码中写“赘余注释”
- 使用 Standalone 组件
- 服务注入用 inject()，不要构造器
- 需要提示用户或输出信息，统一用 system-message.service.ts 的 showMessage()；除非明确要求，不用 console
- 新建接口文件：IMySpecialInterface.ts
- ESLint 为 flat config，在 eslint.config.js
- 一次性数据获取优先 async/await，少用订阅
团队规范越明确，AI 的产出就越贴近你的口味。把人类的共识写清楚，是让 AI 稳定产出的核心。
行内指令做快速修改
一个很实用的小技巧：别只在聊天窗口下指令，把修改请求直接写到代码里作为行内注释（Windsurf/Cascade 等都支持）。提交“更改建议”后，AI 会按注释执行并顺手删除注释，效率很高。
避免“否定表达”，改用正向指令
我曾写过这样的规则：
Don’t add comments to generated code.
否定句对 AI 来说容易误解。换成正向表达更清晰：
- 避免冗余/显而易见的注释
- 只有在解释意图、约束或复杂逻辑时才写注释
这样 AI 既知道何时不写，也知道何时该写，效果更好。
别“情绪化”对话
有人觉得“调侃/施压 AI”很好玩。 我的经验是：情绪化语言只会降低代码质量。 AI 会把对话语境切到一种过度谨慎、过度收缩的状态，结果就是更容易出错、更难推进。保持客观、明确、礼貌，反而更高效。
常回滚，别在坏代码上“叠罗汉”
一旦发现实现方向走偏，立刻回滚，然后改进 Prompt/规则，再来一轮。否则 AI 会在“坏基础”上继续生成更多坏代码，越积越烂。
先搭架子，AI 才不“糊成一团”
不加引导，AI 很容易把所有东西堆进一个 1 万行文件里。你需要给出清晰的架构骨架：
- 要哪些组件、哪些服务、哪些层
- 哪些文件该复用、哪些该新建
- 某些区域已有约定，就让它沿用，别“另起炉灶”
否则它不是全塞一处，就是过度拆分。你的指挥棒，决定了可维护性。
越简单越友好
今天的 AI 还不擅长“高层抽象”。想用好它，就需要让实现尽量简单：
- 在 Angular 中，更偏向
BehaviorSubject/signals + 简单服务 - 不要在没有足够规则与人类监督下，复制一套 Redux 式 Store
- 文件结构要直白：像
shared这种“语义不清”的目录，会让它不知该放啥 - 避免“运行期动态生成、字符串拼接注入”的黑魔法——AI 很难跟踪
总之：明确、显式、易跟踪。复杂度越低，AI 越稳定。
小结
Vibe coding 对专业工程师也很有用；但没有方法论，AI 产出的代码往往不可维护。反过来，只要你设好规则、清晰分工、收紧复杂度，它就能成为可靠的生产力加速器，帮你更快、更稳地把应用落地。