Announcement

👇Official Account👇

Welcome to join the group & private message

Article first/tail QR code

PFinalClub
Search K

Appearance

Vibe Coding 时代的开发者：如何跟 ChatGPT 5.1 一起写代码，而不是被替代 ​

你有没有这种体验：IDE 里一行代码都没敲，任务已经“完成 80%”；
结果线上一挂，leader 问是谁写的，你看着屏幕沉默不语：
“不能说完全不是我写的，只能说大部分不是我写的。”

欢迎来到 Vibe Coding 时代。
键盘声越来越少，prompt 越来越长，Bug 依然如约而至。

这篇文章不聊“AI 会不会抢程序员饭碗”这种宏大问题，只聊一件更现实的事：

既然 ChatGPT 5.1 已经坐在你工位上了，你怎么跟它一起干活，
让它加班，让你下班，而不是反过来。

一、先说清楚：什么是 Vibe Coding？ ​

Vibe Coding 这玩意，本质上就一句话：

“我不想在语法细节里打转，我只想描述我要什么，然后看着 AI 把代码敲出来。”

再配上：

  • 一点 Lofi 音乐
  • 一块超宽屏
  • 两盏氛围灯
  • 一杯装在马克杯里的某种液体（咖啡 / 茶 / 功能饮料 / 柠檬水都行）

你就拥有了社交媒体意义上的——“认真写代码的一天”。

技术视角下，它其实是三件事叠加：

  • 自然语言建模：用中文 / 英文描述需求、约束、边界条件
  • AI 代码生成：ChatGPT 5.1 / Copilot / 其他 LLM 把它翻译成代码
  • 人类审计与重构：你来决定哪些能用，哪些必须砍掉重写

如果你只做前两步，不做第三步，那不叫 Vibe Coding，叫 Vibe Gambling。

二、最常见的翻车现场：不是 AI 太蠢，是你太相信它 ​

聊怎么用之前，先看几个大家普遍遇到的坑。读着读着，如果你觉得“怎么这么眼熟”，说明你已经深度体验过了。

1. “看起来很对，就是跑不起来” ​

典型现象：

  • 本地一跑，能过 happy path；
  • 真上测试环境，一堆边界条件全炸；
  • 出了问题往下翻代码，发现一半逻辑你压根没细看过。

原因很简单：

  • 传统开发是：“写代码 → 自己理解”；
  • Vibe Coding 很容易变成：“AI 生成 → 大致扫一眼 → 直接 copy”。

人类天生不擅长做“只看结果不看过程”的审计工作，尤其是几百行一坨的时候。

2. 调试体验：像在给陌生人免费加班 ​

以前 debug 是在跟“过去的自己”对话：

“我当时为什么这么写？哦原来是为了 xxx。”

现在 debug 更像在翻别人 GitHub 仓库：

  • 命名风格和你完全不一样
  • 错误处理哲学跟你团队约定完全相反
  • 日志要么没有，要么一股“教学示例味”

你不是不会 debug，你只是不认识这个写代码的人——而那个人叫 ChatGPT。

3. Demo 非常丝滑，上生产惨不忍睹 ​

Vibe Coding 特别擅长：

  • 写 demo
  • 录视频
  • 写博客里的代码片段

但线上服务需要的是：

  • 可观测性（日志、指标、Trace 一条龙）
  • 一致的错误处理策略
  • 性能与资源使用的边界

这些东西，ChatGPT 5.1 不是写不出来，而是——你不提醒，它也不会主动上心。

三、重新分工：你当导演和架构师，ChatGPT 5.1 当高级工具人 ​

想跟 5.1 长期和平共处，核心是换一套身份认知：

别把自己当“写代码的人”，而是当“组织智能的人”。

听起来有点玄？直接给一套可以明天就试的工作流。

1. 先别让它写代码，先让它“打草稿” ​

无论是 Go / PHP / TypeScript，都可以这样来：

  1. 写清楚上下文和约束，包括但不限于：

    • 项目结构（单体 / 微服务 / Monorepo）
    • 错误处理约定（是否统一 wrap、是否用统一中间件处理）
    • 日志方案（用什么库、日志级别、字段规范）

  2. 然后对 5.1 说：
    “先别写实现，先帮我列：模块切分 / 结构体设计 / 接口定义 / 错误类型设计。”

  3. 你做的事只有一件：
    在这个“结构草稿”上疯狂批注：

    • 这里太复杂了，拆简单点
    • 这里要考虑幂等
    • 这里需要预留熔断 / 重试
    • 这里未来可能会拆成独立服务

这一步的思路是：

让 5.1 把你脑子里的想法拉成“白板草图”，而不是直接生成 500 行成品。

2. 按模块生成，而不是“一口气全写完” ​

等结构你认可之后，再按模块下指令：

  • “现在只实现 UserRepository，要求：……”
  • “帮我写这部分的单元测试，覆盖这几种失败场景……”
  • “把错误处理统一改成我们项目里的风格：wrapped error + 统一中间件……”

每次生成代码，都让 5.1 带上：

  • 简单的注释
  • 失败路径的处理
  • 一小段“自我审查”，例如：
    • 这段代码有哪些潜在风险？
    • 如果把并发量放大 10 倍会怎样？
    • 哪些地方最可能出 bug？

你要做的，不是盯着每一行语法，而是看：

  • 结构有没有踩你团队的禁区
  • 有没有一看就不舒服的地方（抽象过度 / 分层过细 / 命名别扭）

3. 最关键的一步：让 5.1 给自己挑刺 ​

这一步很多人压根没用过，但效果非常好：

“请你用严苛 code review 的标准，审查一下你刚才写的这段代码，从

  • 可读性
  • 性能
  • 错误处理
  • 日志 & 可观测性
    这四个方面指出问题，并给出更好的版本。”

你会发现：同一个 5.1，认真起来和敷衍的时候，代码完全不是一个水平。

你的工作变成：

  • 在两版之间做 trade-off
  • 决定是“稍微复杂但是健壮”，还是“简单一点但可接受”

三.五、真实案例：我用 ChatGPT 5.1 重构博客的 SEO 关键词优化脚本 ​

这是我上周末真实遇到的一个任务，也是我第一次完整体验"Vibe Coding"工作流的过程。

背景 ​

我的技术博客 friday-go.icu 用 VitePress 搭建，有 100+ 篇技术文章。最近发现 Google Search Console 里显示"低价值内容"，需要优化 SEO。

核心需求：

  • 批量扫描所有 Markdown 文件的 frontmatter
  • 检查哪些文章的 keywords 字段为空或过于简单
  • 根据文章标题和内容，自动生成 10-15 个中文长尾关键词
  • 把优化后的 keywords 写回文件，不破坏原有格式

如果纯手写，我估计要 2-3 小时（文件遍历 + YAML 解析 + OpenAI API + 错误处理）。

第一步：让 5.1 先画草图（不写代码） ​

我的完整 prompt：

我有一个 Go 项目需求：

【上下文】
- 项目是 VitePress 技术博客，文件结构：docs/zh/golang/*.md, docs/zh/工具/*.md
- 每个 Markdown 文件开头有 YAML frontmatter，包含 title, description, keywords 等字段
- 我想批量优化 keywords 字段，让它们更符合中文 SEO 长尾词习惯

【约束】
- 不能破坏原有 YAML 格式（缩进、引号、多行等）
- 如果 keywords 已经有内容，跳过不处理
- 需要调用 OpenAI API 生成关键词（用 gpt-4o-mini，控制成本）
- 日志必须清晰：哪些文件处理了、哪些跳过了、哪些报错了

【不要直接写代码】
请先帮我列出：
1. 核心模块划分（比如：文件扫描模块、YAML 解析模块、AI 生成模块、文件写回模块）
2. 主要的 struct 和 interface 设计
3. 错误处理策略（哪些错误要中断、哪些可以降级）
4. 并发设计（要不要并发处理多个文件？）

5.1 给的草图（摘要）：

模块设计：
1. FileScanner: 递归扫描目录，过滤 .md 文件
2. FrontmatterParser: 解析 YAML，提取 title/description/keywords
3. KeywordGenerator: 调用 OpenAI API，生成关键词列表
4. FileWriter: 把优化后的 keywords 写回文件，保持格式

并发建议：
- 用 worker pool 模式（5 个并发），避免 OpenAI API 限流
- 每个文件独立处理，失败不影响其他文件

错误策略：
- API 调用失败：记录 warning，跳过该文件
- 文件写入失败：记录 error，但不中断流程

我在这个草图上做了两处批注：

  • "5 个并发太多了，OpenAI API 有 RPM 限制，改成 3 个"
  • "KeywordGenerator 要支持重试机制（最多 3 次），避免偶发网络抖动"

第二步：按模块让 5.1 生成代码 ​

我先让它写 FileScanner：

现在先实现 FileScanner 模块，要求：
- 递归扫描指定目录下的 .md 文件
- 返回文件路径列表
- 跳过 node_modules, .git, public 等无关目录
- 用标准库 filepath.Walk，不要引入额外依赖

5.1 给出了代码，我发现有两个小问题：

  • 它用了 ioutil.ReadDir（已废弃），我让它改成 os.ReadDir
  • 没考虑软链接，我让它加了 filepath.EvalSymlinks 检查

然后是 FrontmatterParser：

实现 FrontmatterParser，要求：
- 用 gopkg.in/yaml.v3 解析 frontmatter
- 提取 title, description, keywords 字段
- keywords 可能是 string 也可能是 []string，都要支持
- 如果 keywords 已存在且非空，返回 nil（表示跳过）

这一块它写得还不错，但我让它补了一个边界条件：

  • "如果 frontmatter 格式错误（比如缺少 --- 分隔符），不要 panic，而是返回明确的错误"

第三步：让 5.1 自己审查 + 优化 ​

在生成完 KeywordGenerator（调用 OpenAI API 的部分）后，我用了你文章里提到的"让 5.1 挑刺"：

请用严苛的 code review 标准，从以下角度审查你刚写的 KeywordGenerator：
1. 错误处理是否健壮（API 超时、限流、返回空结果）
2. 日志是否清晰（调试时能快速定位问题）
3. 成本控制（是否可以缓存结果、减少重复调用）
4. 性能（是否有不必要的内存拷贝）

给出改进版本。

5.1 的自我审查（关键点）：

  • 问题 1：没处理 OpenAI API 返回的 JSON 格式错误
    → 改进：增加 JSON 反序列化的错误处理
  • 问题 2：日志只打印"调用成功"，看不到具体生成了多少关键词
    → 改进：改成 log.Printf("Generated %d keywords for '%s'", len(keywords), title)
  • 问题 3：可以增加本地缓存，避免同一篇文章重复调用 API
    → 改进：用 sync.Map 做内存缓存（key = title, value = keywords）

我采纳了前两个，第三个暂时没做（因为是一次性脚本，不需要缓存）。

最终效果 ​

代码行数：约 280 行（包含注释和错误处理）
实际耗时：

  • 和 5.1 对话 + 改代码：55 分钟
  • 真正运行 + 修 bug：20 分钟
  • 总计：1 小时 15 分

如果纯手写，我估计要：

  • 写代码：1.5 小时
  • 调试 YAML 解析的边界条件：30 分钟
  • 总计：2 小时

节省了 40% 时间，但关键是：

  • 我花在"写代码"上的时间少了 70%
  • 我花在"设计、审查、决策"上的时间多了 50%

最终上线运行效果：

  • 成功处理了 87 篇文章
  • 跳过了 23 篇（已有 keywords）
  • 失败了 2 篇（YAML 格式损坏，手动修复）

（这里后续补一张截图：终端输出日志，显示"处理进度 + 成功/跳过/失败统计"）

我从这次经历里学到的 3 件事 ​

  1. "草稿优先"真的有用
    一开始让 5.1 画结构，比直接让它写代码，效率高太多。
    我可以在"草稿阶段"就发现设计问题，而不是等到代码写完再改。

  2. "让 AI 自己挑刺"是个杀手锏
    5.1 认真 review 自己代码的时候，质量明显提升一个档次。
    但你得给它明确的维度（错误处理、日志、性能），它才知道往哪个方向改。

  3. 你的角色是"导演 + 质检员"，不是"打字员"
    整个过程中，我几乎没"手写"超过 10 行代码，但我做了无数次决策：

    • 3 个并发还是 5 个？
    • 要不要缓存？
    • 错误要中断还是降级？
    • 日志打到什么粒度？

    这些决策，才是"不可替代"的部分。

四、我会不会被"更会用 5.1 的人"替代？ ​

坦白讲，会有一部分人被替代，但不是因为 5.1，而是因为：

他既不会写好代码，也不会用好 5.1。

我们可以把开发者粗暴地分成三种：

1. 只会手写代码，但拒绝用 AI 的 ​

  • 优点：基本功扎实
  • 缺点：产出速度会被彻底碾压
  • 未来角色：可能会在“极端可靠领域”继续有需求（内核、安全、极高性能场景），但数量有限

2. 只会写 prompt，不懂工程和架构的 ​

  • 优点：前期看起来产能很高
  • 缺点：项目一大就会崩盘，Bug / 技债 / 运维压力全找上门
  • 未来角色：会被下一代工具替代，因为任何人都能写“差不多的 prompt”

3. 既懂工程，又会 orchestrate AI 的 ​

他们会做的事包括：

  • 能把需求拆成合理的模块和边界
  • 知道哪些适合交给 5.1，哪些必须自己写
  • 知道如何审计 5.1 的输出，让它为你的架构服务

未来，这些人更像是“放大器”：

  • 一个人可以顶过去三五个纯手工开发的产出
  • 他们不是在跟 AI 竞争，而是在用 AI 放大自己的判断力

你想成为哪一类，大概率是可以自己选的。

五、在 Vibe Coding 时代，怎么保住“硬功夫”？ ​

既然我们承认要和 5.1 合作，那“别被替代”就不是靠拒绝使用，而是靠：

在 AI 极擅长的地方借力，在 AI 不擅长的地方补位。

换句话说：该让它做的让它做，该你硬上的别躲。

给你几个简单可执行的习惯：

1. 每周保持一段“纯手写时间” ​

不用太长，30–60 分钟就行。
可以做这些事：

  • 手写一个常见数据结构 / 算法
  • 重构一段老代码，不借助 AI，让自己重新走一遍决策路径
  • 为现有项目写一份“设计说明书”或 README 的架构部分

这段时间的目标不是“提高效率”，而是给大脑做力量训练。

2. 每次用 5.1，都让它“解释一下为什么这么写” ​

比如：

  • “请用架构师角度解释一下，你为什么这样划分模块？”
  • “如果改用事件驱动 / CQRS / 另一种模式，会发生什么变化？”
  • “这段实现里，哪部分最脆弱，最值得写测试？”

你会得到一段“教材式解释”。
这段解释，比那几百行代码更值钱。

3. 故意跟它“唱反调”一两次 ​

当 5.1 给你一个方案时，主动问：

  • “给我一个完全相反风格的实现，比如从 OOP 改成偏函数式风格。”
  • “如果我不允许使用某个第三方库，你会怎么改？”

你会开始学会 比较方案，而不是被第一个答案牵着走。
慢慢地，你会发现自己在做的，其实已经是架构设计而不是简单“写代码”。

六、别忘了：安全、可观测性和规范，依然是你的锅 ​

无论 5.1 写了多少代码，有三件事永远写在你名字上：

  • 安全：有没有把 token 写在代码里，有没有做输入校验
  • 可观测性：出了问题你追不追得到
  • 团队规范：代码风格、错误处理、日志标准

给一套“最小自查清单”，你可以直接贴进项目里：

  • 所有外部调用：
    • 是否有超时与重试策略？
    • 失败时是否打点 / 记日志？
  • 错误处理：
    • 是否统一 wrap / 分类？
    • 是否会在边界层（HTTP / RPC）归一化？
  • 日志：
    • 是否包含 trace id / request id？
    • 是否避免在日志里打出敏感信息？

你完全可以让 5.1 来帮你写这张清单、甚至自动检查一遍代码，
但勾不勾选，是你的责任。

七、Vibe Coding 时代，最好的位置在哪里？ ​

如果把软件开发流程粗暴拆开，大致是这样：

需求 → 架构 & 设计 → 编码 & 测试 → 部署 & 监控 → 运营 & 迭代

Vibe Coding 和 ChatGPT 5.1，目前最厉害的是这几个环节：

  • 编码：大量样板代码、胶水代码、CRUD
  • 测试：生成测试用例、mock、简单集成测试脚手架
  • 文档：接口文档、使用说明、CHANGELOG 草稿

而最不容易被替代的是：

  • 需求拆解：你到底要解决什么问题
  • 架构折中：在复杂度 / 性能 / 成本 / 上线时间之间做平衡
  • 工程规范与团队文化：
    同样的 AI 工具，在你手上和别人手上，产物差距会非常大

所以，这篇文章真正想说的一句话是：

别再纠结“会不会写代码会被替代”，
把精力放在“如何更好地组织智能”——包括你自己和 ChatGPT 5.1。

八、小结：明天就可以尝试的 3 个小实验 ​

如果你看到这里，可以试试下面三件小事：

实验 1：只让 5.1 画草图 ​

找一个你准备写的新功能，禁止它直接写实现，只让它列：

  • 模块划分
  • 接口定义
  • 数据结构设计
  • 错误类型设计

你在上面批注，感受一下自己从“码农”变成“导演”的过程。

实验 2：请 5.1 做一次“严厉的 code reviewer” ​

把你最近写的（或它写的）一段核心代码扔给它，让它从：

  • 可读性
  • 性能
  • 错误处理
  • 日志 & 可观测性

这四个维度挑刺并重写一版。你只做一件事：
挑你喜欢的部分 merge 回项目。

实验 3：给未来的自己写一封“使用说明” ​

用自然语言写下：

  • 你希望项目里的错误处理长什么样
  • 你接受 / 不接受哪些快捷方式
  • 哪些“为了赶上线的妥协”，未来必须还债

然后把这封“说明书”交给 ChatGPT 5.1，让它以后都按这个标准来生成代码。

当你开始这样用 ChatGPT 5.1 的时候，你就已经从：

  • “担心被替代的那一拨人”，

缓缓走向：

  • “把 AI 当成增幅器的那一拨人”。

延伸阅读：把想法落地到真实项目 ​

Vibe 可以继续，Coding 也要硬。
能一起弹琴的，才配一起 Vibe。

上次更新于: