
最后往往变成了:AI 写代码 1 分钟,你由改 Bug 1 小时。
其实,GLM-4.7 并不缺编程能力,缺的是一份听得懂的 "需求文档"。 今天咱们就来聊聊,如何通过 Vibe Coding(氛围编码),把 AI 从 "人工智障" 调教成你的 "神级队友"。
AI 不是肚子里的蛔虫。绝大多数无效代码,都源于过于简陋的提示词。
❌ 错误示范(千万别这么问):
帮我写个登录功能✅ 正确示范(教科书级提问):
我需要为一个React应用创建用户登录功能。要求:
- 使用TypeScript
- 包含邮箱和密码验证
- 支持记住登录状态
- 错误处理要友好
- 遵循项目现有的组件结构
请先分析现有的认证相关代码,然后提供完整的实现方案。看出区别了吗?第二个提示词不仅描述了 要什么,还通过约束条件告诉了 AI 怎么做。
咱们做项目管理用的 SMART 原则,写提示词时一样好使:

试图在一个 Prompt 里解决所有问题,通常会得到一坨无法维护的代码。把复杂任务 "切碎",才是高手的做法:
请帮我分析一下当前项目的架构...基于刚才的分析,如果要添加第三方登录,应该如何设计?请实现Google登录功能...请添加错误处理...GLM-4.7 最牛的地方在于——它不是在真空中工作的,它能看见你的整个项目。

💡 高阶技巧:
请分析一下这个项目的结构和主要技术栈。请参考 components/Button.tsx 的写法,创建一个新的 Card 组件,这样生成的代码风格才不会突兀。就像打游戏有快捷键一样,熟练使用 / 命令,手速能快一倍(以 Claude Code 为例):
/create-component (瞬间创建组件), /add-tests (一键补全测试)/commit (AI 帮你写 Commit 这里的 message), /pr-review (自动代码评审)/optimize (性能优化), /clean (代码洁癖福音)
上下文就是 AI 的 "短期记忆"。如果 AI 开始胡言乱语,通常是因为它 "断片儿" 了。
👇 建议收藏这个 "上下文模板":
这是一个 [项目类型] 项目,使用 [技术栈]。
主要功能是 [核心功能描述]。
我们的编码规范包括:
- [规范1]
- [规范2]
- [规范3]
当前我需要 [具体需求],请基于以上背景提供解决方案。
当 GLM 给出的代码报错时,千万别直接关掉重开!这其实是调教它的最好机会。
✅ 正确的 "怼" AI 姿势:
刚才生成的代码有个问题:当用户输入为空时,应该显示友好的提示信息,而不是抛出异常。
现在的行为是:[描述当前行为]
期望的行为是:[描述期望行为]
请修改相关的验证逻辑。遵循 "分而治之" 的原则,永远不要把一个超级复杂的任务直接扔给它,除非你想得到一个超级复杂的 Bug。

让我们看看,如何优雅地指挥 AI 完成一个功能模块。
🎯 场景:为博客系统添加评论功能
"我正在开发一个 Next.js + TS 博客。已有文章展示和用户认证。我想加个评论功能(支持回复、Markdown),请先分析方案。""基于分析,请设计数据库模型和 API 接口。""先实现数据模型和 CRUD API。""基于设计创建展示组件,风格要和现有组件库一致。""最后,添加点赞、举报和敏感词过滤功能。"问题: "帮我写个函数" 解法: 明确输入、输出、边界条件,把它当实习生教。
问题: 直接生成代码,导致风格割裂 解法: 总是让它 "阅读" 现有项目结构。
问题: 想要一个完整的 ERP 系统 解法: 拆解!拆解!再拆解!
问题: 代码不对就重新开新的对话 解法: 在原对话中指出错误,建立反馈闭环。
记住:好的提示词是成功的一半,好的反馈循环是成功的另一半。
未来的编程,不是人与机器的竞争,而是 "会用 AI 的程序员" 与 "不会用 AI 的程序员" 之间的竞争。现在,打开你的 IDE,开始这段 Vibe Coding 之旅吧!
相关文章推荐:
如果这篇文章帮到了你,不妨点个分享给同样需要的朋友吧! 你的每一次支持,都是我持续创作的动力!💪