Vibe Coding 分享

比较典型的工具链就是 github 的 SpecKit（https://github.com/github/spec-kit），包括后面进行改良后的 get-shit-down(https://github.com/gsd-build/get-shit-done)AI 的视野局限性：当在项目工程中进行编程时，巨大的工程中进行某次小修改时，AI 的注意力往往只聚焦在当下的任务上，它做的修改也许能够完

闽江小张

500人浏览 · 2026-03-03 18:36:21

闽江小张 · 2026-03-03 18:36:21 发布

Vibe Coding 分享

vibe coding VS 古法编程

基础概念

古法编程：技术社区对传统手动编写代码方式的戏称，和之前许多年一样，不借助 AI 编码工具，纯手敲每一行代码
vibe coding：新兴编程方式，开发者通过自然语言描述需求，由AI生成相应代码，核心是 让开发者从"代码农民工"转变为"代码工头"

主要对比

代码创建	逐行手动编码	AI根据自然语言提示生成
开发者角色	架构师、实现者、调试者	提示者、引导者、测试者、优化者
编码专业知识需求	较高（需掌握语言语法）	极高
主要输入	精确的代码	自然语言提示和反馈
开发速度	较慢，有条不紊	极快
代码掌控力	完全掌控	依赖AI输出质量
思维状态	深度专注，心流状态	碎片化，需频繁与AI交互代码创建

两者关系

vibe coding 看似要替代古法编程，但实际上是古法编程的扩展与补充

古法编程提供了核心的经验积累，抽象层次和质量控制，是进行 vibe coding 的基础
vibe coding 在古法编程的基础上提供了自动化工具和框架，帮助开发提高代码生产力，但抽象层次和设计决策仍然是开发者不能缺少的一环

目前主流的 AI 编码工具和大模型

大模型对比（只谈用过的）

国外御三家：gpt，claude，gemini

claude 像是高工适合执行具体编码任务
- 执行速度快
- 发散性偏高：，无边界感，往往会过度设计，但有时也会补充准之外的正向工作
- 偷奸耍滑：代码完成度低，在设计好技术文档之后，往往需要跑两到三遍才能完全达到技术文档上的要求
GPT 像是架构师，适合分析问题，规划任务
- 执行速度超级慢
- 考虑问题发散性较低，以用户提出的执行标准为准，较少逾越
- 代码完成度高：往往一次能达到技术设计的标准，对于 UI（截图）的还原度相对较高
- 以上只适用于 gpt 模型而不是 gpt-codex。gpt-codex 跟国内模型差不多，只适合做一些简单重复性的工作
Gemini
- 编码质量和架构规划都不及 claude 和 gpt
- 前端 UI 编写很好
- 偶尔能 debug 出一些 claude 和 gpt 都无法解出的问题，但也只是灵光一闪，水平不稳定

国内：glm：glm4.7 适合做一些零散的小需求，上强度之后即使经过几轮自检仍有较多漏洞
其他：自己未使用过，但在社区和 ai 开发群中见到的讨论
1. GLM5: 表现快追上 claude opus 4.6了，但算力严重不足，非常慢
2. minimax 和 kimi：和 glm4.7 表现相近，在实际生产使用中只能作为补充，打下手的模型，与国外模型仍有一定的差距

### AI 编码工具

CLI (终端命令行工具)：
- codex
- claude code
IDE:
- Trae
- Antigravity
- Cursor
- opencode

一些概念

command

CLI 中一般提供了一套命令系统，可以将一些常用的 prompt 封装成命令，减少重复 prompt 的输出。凡是重复了两次以上的类似 prompt 都应该用命令表述！

Hooks

达成一定条件时会去执行其他逻辑，一般用于进行固化工作流，做一些自动化的操作

MCP（Model Context Protocol）

一个用于 AI 工具集成的开源标准，允许 AI Agent 可以通过标准协议接入 文件、数据库、网页、内部系统 等资源。极大的扩展了 AI 的能力边界。
mcp 服务器提供了一些可以调用的工具，ai 可以像内置工具一样去调用
mcp 也会侵占上下文，并不是越多越好，按需添加和开启
注意：mcp 并不是越多越好，其本身会侵占上下文，同时工具调用过程中也会伴随有查询，结果带来的上下文，需要控制其数量，使用必要的 mcp

Skills

可复用的作业指导书（SOP）+ 触发条件 + 交付格式。可以用命令触发，也可以在合适的场景自动触发

skill-name/
├── SKILL.md          # 必需
├── scripts/          # 可选：可执行代码
├── references/       # 可选：附加文档
└── assets/           # 可选：模板和资源

skill 解决的问题：
- 固化流程
  - 减少重复工作
  - 把脆弱的多轮编排改为更缺德ing的程序化执行
- 节省上下文：因为 SOP 编排，减少了试错与长返回，间接减少上下文膨胀

subAgent（子代理）和多 Agent（Agent Teams / 多智能体协作）

subagent 是专门处理某一类任务的 AI 助手
- 有自己独立的上下文窗口
- 执行结果会回到主会话汇总
- 它更适合做“专注、可并行、只要结果”的任务（比如：查 API、找 bug 根因、写测试方案）
- 使用 subagent 完成不同的任务可以增加效率，同时减少主 agent 的上下文内容，减少模型幻觉，增加模型准确性
Agent teams：
- 真正的多会话并行，每个成员都是一个完整的 ai 对话
- 共享任务列表，会自动对齐，当有任务依赖时，完成以来任务后被阻塞的任务会自动解除阻塞
- 成员之间可以直接通信
- 每个成员能加载常规的项目上下文, 如CLAUDE.md， skills，mcp
- 支持在一个终端内切换查看，也可以每个队友一个窗口（多窗口需要 tmux 或者 iTerm2）
- 成本高效会更高（慎用）
subAgents 和 Agent Teams 差异
- 通信方式：
  - Subagent：只能向主代理汇报结果
  - Teams：队友彼此直接发消息、也能自组织
  协调方式：
  - Subagent：主代理管理一切
  - Teams：共享任务列表，队友可认领任务并协作
  token 成本：
  - Subagent：较低（结果摘要回主上下文）
  - Teams：较高（每个队友都是独立 Claude 实例）
- subAgents 和 agetn 的使用场景的考量：
  - subAgents 和 agent teams 最大的差异是能否在并行时无法互相通信沟通
  - 在进行多模块开发需协商的任务时需要使用 agent teams，比如涉及到多个模块的需求开发，重构等
  - 而一般简单的粒度较细，较为完整的任务适合 subgent，如单测编写，crash 日志分析，补充注释等

一些好用的工具推荐

get-shit-done（GSD）

定位：一个面向 Claude Code 等工具的 spec-driven + context engineering 框架，主打解决“越聊越乱”。(GitHub)

适合场景：

任务大、周期长、上下文容易膨胀的项目
想把“AI 开发流程”标准化、模板化的团队

oh-my-claudecode（OMC）

定位：在 Claude Code 上做“多 agent 编排”的工具/工作流集合，强调 teams-first、多种执行模式。(GitHub)

（你分享里可以用一句话带过：“把 Claude Code 从单兵升级成小队。”）

oh-my-codex（OMX）

定位：OpenAI Codex CLI 的多 agent 编排层（类似上面的 OMC，只是给 Codex 用）。(GitHub)

Claude Code 的通知/用量统计工具

claude-code-notifications：用 hook/脚本做通知（比如任务结束弹 toast）。(GitHub)
Claude-Code-Notifier：多渠道通知 + 集成 ccusage 做用量/成本分析。(GitHub)
ccusage：统计 Claude Code token 使用。(GitHub)

项目实际开发怎么处理

vibe coding 的困境

代码量极度廉价而获取好代码的的成本会更高：在 ai 工具的帮助一下，以前可能几天时间才能写出的代码能以极快的速度生成并投入到项目中，如果对设计和代码质量不加以控制，项目会快速腐化，甚至无法维护
对话式编程的“局部最优”与“全局最优”冲突：
- AI 的视野局限性：当在项目工程中进行编程时，巨大的工程中进行某次小修改时，AI 的注意力往往只聚焦在当下的任务上，它做的修改也许能够完成局部的需求，但对于整体架构来说并不对。
  - 比如登录按钮未做防抖处理，导致多次点击发送多次请求，让 AI 修，它可能会直接在请求前加锁，请求后解锁。更好的方式是在提前做好防抖按钮组件
- 这样会导致两个问题：
  - 这种大局观的缺失的改动会随着项目迭代导致项目全局熵增
  - 这样“补丁”式的代码会导致项目代码逻辑越来越碎，代码层面的腐化会非常严重
上下文信息爆炸：
- 项目变大，代码量是指数级增长的“噪音”。当我们在有限的 Context Window 里塞满了具体的实现细节，真正的“工程信息”反而被稀释了
- 上下文的污染会导致两个问题：
  - 噪音太多，易出现幻觉，正确率下降
  - 噪音太多，导致 ai 的注意力被稀释，无法做出正确的判断与决策
偶然复杂性带来的 debug 灾难：AI 的代码不加以控制和理解，会堆成屎山，而且还擅长屎上雕花，可能变量命名规范，还有详细的注释（而且是瞎编的），结构看起来很工整。但在逻辑深处存在一个极其罕见的边缘情况（Edge case）下会直接崩溃，这类问题是很难发现的。可能工程迭代着迭代着就会出现鬼打墙的情况：AI 反复修改都无法修改好，还可能越修越乱最后没人看得懂。
对项目的掌控力的下降：古法编程下，工程代码是推理+理解+制作=结果。vibe coding 下将推理过程外包了，工程师最多 review，而人脑的记忆又是十分短暂的。

如何在实际开发中更好的 vibe coding

不要让 ai 写认知以外的代码：当对代码无知时，已经没办法去保障工程质量与稳定性了，因为这是没有审查标准或者审查标准都是错误的审查
plan mode 模式优先：
1. 在实际动工之前先讨论好要做什么，以及如何做，设计好技术文档是后续所有工作的基石
2. 使用最好的模型去做技术设计的推理
ai 写的文档和代码需要审查，确认之后才可以接受这段代码是 ok 的
不要让 ai 工具执行 git：git 是 ai 编码的最后一道防线，只要在未提交之前，所有的过错，甚至是误删都可以通过 git 恢复
利用 CLAUD.md 和 /rule/memory 做整体和模块级的约束
1. CLAUD.md 文档是项目整体的通用约束标准，也需要随着项目的变更去进行更新
2. 模块级别的细分规则和约束可以通过 /rule/memory 去做约束，可以让 Claude 在处理某个模块时才加载对应规则，从而既降低噪音又提高一致性
codex 做架构处理，claude 做工程实现，并且用 codex 做检查处理
善用 mcp 和 skill 增加模型工作能力，比如 iOS 开发使用 apple-docs mcp 抓取官方 api 相关知识，使用 context7 查询 github 上三方库的最新信息，防止使用过时的信息让 ai 做出错误的决策
SDD + TDD 范式驱动开发

SDD（ Spec-Driven Development 规格驱动开发）

核心理念：先写一份详细的技术文档，明确输入、输出、逻辑边界和 UI 约束，然后让 AI Agent 根据这份“图纸”一次性生成完整的代码。比较典型的工具链就是 github 的 SpecKit（https://github.com/github/spec-kit），包括后面进行改良后的 get-shit-down(https://github.com/gsd-build/get-shit-done)
SDD 下开发流程
1. 讨论确定需求细节
2. 生成详细的需求技术文档，包括本身逻辑，涉及网络的接口，UI约束
3. 根据技术文档将其拆分成不同一个个细分任务的文档
4. 将任务进行执行
好处：
1. 明确需求和技术文档的设计，确保顶层架构不回出现偏差
2. 留下的文档是宝贵的资产，ai 可以通过阅读文档了解该模块核心情况，开发者也可以阅读文档快速了解工程

TDD（Test-Driven Development 测试驱动开发）

核心理念：测试先行，确定好需求的准出标准，保证结果是符合需求的
TDD 下开发流程
1. 编写好测试和错误用例，证明其是真的能测试到问题
2. 写最小实现让它通过（只做“刚好够用”
3. 在测试保护下重构开发（改结构不改行为）
好处：
1. AI 很会“生成看起来合理的代码”，但容易偏离真实意图、漏掉边界条件。测试为提供的准出标准，能够感知到其是否真的合理了，还是看起合理
2. 在后续迭代中或者重构中，测试仍然会发挥其该有的作用，减少因为重构导致逾期行为变形
注意事项：
1. UI 不需要测试，只测试功能逻辑部分
2. 不必追求单测覆盖率，主要测试关键逻辑路径，比如网络，数据持久化，复杂的逻辑等关键路径

SDD + TDD 的开发范式

SDD 确定了规范，但不太好保证最后生成的代码是按照规范的，而 TDD 确定了代码是按照要求生成执行，但是缺少了系统级的边界/模块职责/非功能约束
使用 SDD 将编码意图结构化，TDD 将意图可执行化
具体流程推荐：
1. 先写 Spec（SDD 的核心工件），在仓库里维护 SPEC.md / docs/spec/*.md，包含：
  - 目标/范围/非目标
  - 模块边界与依赖方向（哪些能改、哪些不能碰）
  - 接口/数据契约（API、事件、表结构等）
  - 非功能要求（性能/安全/一致性）
  - 验收标准（Acceptance Criteria）（这部分会直接生成测试）
2. 从 Spec 派生测试（进入 TDD）用同一份 Spec 里的验收标准，拆成三类测试（按性价比排序）：
  - 契约测试/接口测试：锁住 API / schema 行为（最防跑偏）
  - 领域单元测试：锁住不变量、边界条件（信息密度最高）
3. 先跑一次确保 Red（测试真的能失败），避免“看似有测试其实没约束”。
4. 让 AI 只做“最小改动”把测试跑绿，此时 prompt 重点不是“写代码”，而是
  - “只改这些模块/文件”
  - “必须满足 SPEC 的这些条款”
  - “目标：让以下 failing tests 通过”
  - 输出 git diff + 验证命令
5. 绿了再重构（Refactor），并同步 Spec
  - 允许 AI 重构，但以“测试全绿”为护栏
  - 如果实现过程中有取舍/更改行为：先改 Spec，再改测试/实现（否则 spec 漂移）
配合 Clean Architecture，将 UI 和业务逻辑层分开，更易维护，也更易推动 TDD

AI 时代下我们该何去何从

在缩小中高级研发差距

以前很多“中级到高级”的门槛是：你写得快、记得多、踩坑多。
现在 AI 让“写得快”变成默认能力，所以差距会更集中在：

你能不能把问题定义清楚
你能不能设计可验证的方案
你能不能控制风险、保证质量(Simon Willison’s Weblog)

对新手来说可能是毒药（如果用错了）

新手最大的问题不是“写不出来”，而是：

不知道什么是对的
不知道怎么验证
不知道为什么这样设计

如果他全程靠 AI 自动驾驶，会变成“能交作业但不会做题”。

你的建议可以很具体：

让新手用 AI 解释代码、带着他读项目，而不是直接生成
强制新手写测试、跑验证命令
把“为什么这么做”写进文档/规则里，形成团队知识库

代码会更廉价，但底层知识与工程经验更值钱

这句话你可以讲得很“现实”：

代码生成会越来越便宜
但判断需求、约束设计、系统取舍、线上风险、质量体系这些不会消失
甚至会更重要，因为 AI 会把“产能”放大，你需要更强的“质量与方向盘”

Simon Willison 那套“agentic engineering patterns”里核心也一直在强调：测试、QA、理解系统、可验证性这些能力会变得更关键。(Simon Willison’s Weblog)

参考资料与延伸阅读（你可以直接发给同事）

我把你提到的官方文档 + 关键文章都放在这里（按“最推荐优先”排序）。

Vibe coding 概念与起源（百科）(维基百科)
Collins 2025 Word of the Year：vibe coding(Collins Dictionary Language Blog)
Claude Code Overview（Claude Code 是什么）(Claude)
Claude Code Skills 指南（SKILL.md 怎么写）(Claude)
Sub-agents（子代理）(GitHub)
Agent Teams（多 agent 团队协作）(Claude)
Hooks（钩子/门禁自动化）(Claude)
Features overview（功能权衡：别把上下文装爆）(Claude)
MCP 介绍与规范（协议与生态）(Anthropic)
Simon Willison：Agentic Engineering Patterns（非常适合用来“吹牛但不空”）(Simon Willison’s Weblog)
DocDD / Documentation-Driven Development（先写文档的思路）(Gist)
get-shit-done（SDD 框架示例）(GitHub)
oh-my-claudecode（Claude Code 多 agent 编排）(GitHub)
oh-my-codex（Codex CLI 多 agent 编排）(GitHub)
OpenAI Codex（产品页 + CLI）(OpenAI)

2048 AI社区

有“AI”的1024 = 2048，欢迎大家加入2048 AI社区

更多推荐

2026毕业季AI论文工具亲测｜避开查重雷区，毕业生高效写稿全攻略

•新手零门槛，全流程辅助：哪怕是第一次写论文、完全没有思路的同学，只要输入论文题目，就能自动生成完整的开题报告思路，一键输出逻辑清晰的论文大纲，还能帮忙补充专业理论框架，逐段优化内容逻辑，连段落衔接生硬、逻辑断层的问题都能给出针对性修改建议，同时附带降重改写方案，彻底解决初稿无从下手的难题。核心亮点：支持超大篇幅文本输入，可直接上传PDF格式文献，快速提取文献核心观点、关键数据和可引用内容，长文本