Vibe Coding | Yanpeng Tong

笔者的🧑‍💻编码方式从纯人工coding转变到现在的vibe coding，使用gpt4o mac端进行辅助编码，绝大多数code都由GPT4o生成。最近发现github copilot不仅有chat模式，还有agent模式，感觉AI coding的潜力还没有完全被发挥出来，故阅读相关博客，来探索一下AI coding生产力最大化的范式当下应该是怎么样的

AI Coding 是一个放大器

当你能用精准的提示词拆解需求，当对系统设计有敏锐直觉，AI会把你的能力指数级放大；反之，模糊的指令只会让AI输出漏洞百出的代码。 AI是一个放大器。如果你的能力很差，收益自然微不足道；如果你的能力系数为负，收益甚至可能是负值。

AI对语言和风格很敏感，常常反映出提示者的偏好与审美。顶尖工程师品味高，对什么可行、什么不可行，有着更为敏锐的品味和直觉。所以，要秉持工匠精神。就算AI帮忙，也要对产出成果感到骄傲，这点在AI系统的最终产出中得到了清晰的印证。

两种截然不同的prompt实现一个速率限制器

Prompt1: Write a Python rate limiter that limits users to 10 requests per minute.

Prompt2:
Implement a token bucket rate limiter in Python with the following requirements:

- 10 requests per minute per user (identified by `user_id` string)
- Thread-safe for concurrent access
- Automatic cleanup of expired entries
- Return tuple of (allowed: bool, retry_after_seconds: int)

Consider:
- Should tokens refill gradually or all at once?
- What happens when the system clock changes?
- How to prevent memory leaks from inactive users?

Prefer simple, readable implementation over premature optimization. Use stdlib only (no Redis/external deps).

还有个卓有成效的技巧，叫「元提示」（metaprompting）:先给模型一个简单任务，让它帮忙挖出需要权衡的因素和潜在的边界情况，整理成技术规格，再让另一个AI智能体去执行。

帮助人类的也能帮助AI

AI偏好的高质量团队和代码库有这些特征：

良好的测试覆盖率、有意义的断言；
自动化代码检查、格式化和测试，在代码合并前执行；
持续集成与持续部署 (CI/CD)；
完善的变更文档、技术规格（tech specs）、架构决策记录（ADRs），以及清晰的提交信息；
代码风格统一，通过格式化工具强制执行；
简单、简洁、结构清晰的代码；
功能定义清晰，拆分为多个小型的故事卡。

当今的AI能利用所有这些要素，自动搞定任务。

编辑器中的工具和技巧

不计成本地使用最好的AI Model
提供精准的Context：用Agentic编码工具，推荐Claude Code, Cursor, Windsurf, Cline; 只@相关的代码文件和文档；将编码规范写入RULES.md文件，为不同的智能体工具（如 .cursorrules, .windsurfrules, claude.md, agents.md 等）创建指向此文件的符号链接（Symlink）。
实现一个新功能或者重构时：拆解问题。指令越具体，AI的表现就越好。AI还能帮忙把提示写清楚，让指令变得更清晰、更具体。推理能力强的模型尤其擅长此道；化整为零，逐一击破。在开发大型功能时，应将其拆分为多个小任务，然后逐个交给AI处理，并在完成每个任务后进行一次代码提交（commit）。如果你遵循用户故事（story）的工作流，包含任务清单的故事卡描述对AI就是一份极佳的指南。提供技术规格与相关文档。不要在缺少产品宏观背景的情况下直接要求AI写代码。应向其提供技术规格，以及所用程序库的官方文档。对于大多数工具而言，直接粘贴文档链接通常是有效的。有些程序库甚至会提供一个llms.txt文件，专供编码智能体使用。好的模式是把开发分成「计划」和「执行」。一些先进的编程智能体已经内置了类似的流程。审慎对待AI的建议。不要将其建议视为理所当然，让它解释选择的理由，提出替代方案，分析方案的优劣。
调试时：用AI调试自己的bug。当AI生成的代码出错时，务必将最相关的错误上下文完整粘贴给它，以帮助其定位问题。（如使用专门的XML标签，如<error>，将错误日志或输出内容包裹起来）。提供尝试和观察。向模型说明已经尝试过的调试步骤和额外的观察发现，这能帮它形成正确的假设并排除错误的推断。提供丰富的上下文至关重要。

编辑器之外的实用技巧

AI是一位拥有海量知识、具有高效研究能力，超级有耐心的老师。

应积极用AI学习新知，揭开陌生代码或技术栈的神秘面纱。坚持不懈地深入挖掘，探寻最佳实践。同时，务必让AI引用高质量的信源，确保学到的知识准确无误。

📚 创建海量详尽文档

把代码库信息提供给AI，就能轻松地创建大量细致的文档。比如：

阐释功能，创建项目知识库；
汇总当前所有的监控指标；
智能识别缺失的测试用例。

这样做的好处显而易见——如今，生成文档的成本已极其低廉，而这些文档又能反过来极大地提升AI以及人类成员的工作效率。

🤝 解决日常协作小摩擦

AI能极大降低团队日常工作中遇到的各种小阻力：

利用AI创建模拟服务器（mockserver），用于协调前后端团队的工作，消除开发过程中的阻塞。前后端对好接口契约就能开工；
通过向AI提供shell历史会话记录，为基础设施部署、常见故障排查等场景创建运行手册（runbook）和指南；
将现有的运行手册和指南提供给AI，让它将其转化为能自动执行常见任务的脚本。

🧑‍💻 代码评审 (Code Review)

为合并请求（Pull Request）创建一个模板，将每个功能的代码变更提交给AI，让它解释变更和部署步骤；
为了缩短首次代码评审的响应时间，可以引入代码评审机器人来完成初步检查。但切勿完全取代人工评审！
作为评审者，当你遇到不理解的代码变更时，可以先让AI解释。向它寻求澄清，在获得了必要的背景信息后，再向开发者提问。

🔍 调试和监控线上应用

用AI的深度研究能力，寻找罕见错误的解决方案。调试线上问题时，可遵循与在编辑器中调试时相同的建议：提供尽可能丰富的上下文；
AI非常擅长为可观测性工具编写查询语句和告警规则，还能写Python代码分析和处理数据。

⚙️ 性能优化

用AI优化数据库和调校配置。此时，务必向其提供有关基础设施和硬件的上下文信息，并分享查询计划（query plan）。

Summary 如今，大模型比过去聪明得多。它们能更智能地推理，工具使用也更出色。人们编写软件的方式正发生着巨变，因此有必要重新审视一些曾被奉为金科玉律的传统智慧。

别急着搞复杂抽象：首先，花费过多时间去寻找和构建精巧的抽象，其价值正在降低。

DRY（不要重复自己）原则对确保代码模式的一致性固然有用，但为了应对需求变更而维护，本身就需要付出成本。

返工的成本极低。小范围的代码编写不如整体代码结构和组织重要。可以快速构建多个原型测试想法。

氛围编程(Vibe Coding)很适合原型开发，但事后要将原型抛弃并重新进行规范的开发。

验证并修正一个既有方案，通常比从零开始创造它要容易得多。这极大地降低了人们尝试新事物的阻力。[真的，这使得现在nlp实验idea验证的速度飞升，AI会完成绝大部分code，nlper们只需要小范围修正迅速迭代]

测试是绝对不容妥协的。AI能够快速、批量地生成测试用例，这让任何不写测试的借口都荡然无存。

但请记住，必须时刻严格审查其生成的内容！

How-Nicholas-use-LLM

直接制作整个web App[Link]
新技术的导师[link]
开始一个新的工作：直接生成了一个代码骨架，无论他是否能直接运行，比平地起高楼好多了）
简化代码
干杂活：做一些boring task
作为一个万能的参考手册
生成式搜索，有些内容用搜索引擎如同大海捞针
解决一次性问题
做各种知识性的问答
解决已经有解决方案的任务
修复bug

Pre-2022 when I ran into an error message from some popular tool or library I would follow the following protocol:

Copy error message
Paste into Google
Click top stackoverflow link
Verify the question is what I want to ask; if not go to 2
Apply top solution to task
If it does not work, go to 2, change search terms, pray, etc

What does this look like now, in 2024?

Copy error message
Ask LLM "How do I fix this error? [error]"
Apply step-by-step solution as suggested by LLM
If it does not work, say "that didn't work"

Evaluate what LLMs can do, not what they can’t LLM数不清句子里有几个词，strawberry里有几个r，写一首每一个单词都以a开头的诗，乘以两个数字。。。确实有缺陷，但是人根本不会用LLM去完成这些任务，关注他们能解决的问题，意义会大得多

Reference

这篇blog主要参考了以下前两篇blog，另外三篇也是很好的to-read

@misc{carlini2024ai,
  author    = {Nicholas Carlini},
  title     = {How I Use AI},
  year      = {2024},
  url       = {https://nicholas.carlini.com/writing/2024/how-i-use-ai.html},
  note      = {Accessed: \today}
}

@misc{nilenso2025coding,
  author    = {Nilenso Blog},
  title     = {AI-Assisted Coding},
  year      = {2025},
  url       = {https://blog.nilenso.com/blog/2025/05/29/ai-assisted-coding/},
  note      = {Accessed: \today}
}

@misc{anthropic2025claude,
  author    = {Anthropic Engineering},
  title     = {Claude Code Best Practices},
  year      = {2025},
  url       = {https://www.anthropic.com/engineering/claude-code-best-practices},
  note      = {Accessed: \today}
}

@misc{willison2025llms,
  author    = {Simon Willison},
  title     = {Using LLMs for Code},
  year      = {2025},
  url       = {https://simonwillison.net/2025/Mar/11/using-llms-for-code/},
  note      = {Accessed: \today}
}

@misc{crawshaw2025programming,
  author    = {Russ Cox / Chris Crawshaw},
  title     = {Programming with LLMs},
  year      = {2025},
  url       = {https://crawshaw.io/blog/programming-with-llms},
  note      = {Accessed: \today}
}