Vibe Coding 时代的
规模化业务开发

全栈工程师
从前端到后端到模型

算法 + 架构
一直在和语言模型打交道

每月 Token 消耗
重度 AI 编程实践者

"完全沉浸在感觉里，忘记代码本身的存在"——用自然语言驱动 AI 写代码，人只看结果。原型起飞极快。

纯靠"感觉"的项目大多活不过两周。业界共识转向 Spec-Driven Development：先写清楚规格，再让 Agent 干活（GitHub Spec Kit、Kiro 等）。

Coding ≠ Engineering

• Engineering：稳定性、安全、性能、架构、线上故障、长期维护——让产品可靠地跑下去
• Coding：把一个想法变成能用的工具——让 demo 跑起来
• 这是两件事。越用 AI 写代码，越会发现工程师不简单——工程能力不会被 vibe coding 稀释，反而更值钱

新的核心能力：会指挥 AI

• 把需求讲清楚
• 会拆任务
• 会判断做出来的东西有没有跑通
• 会发现哪里不对，让它继续改

就像写作：不是人人要当作家，但人人都要会写邮件、写方案。Coding 也一样，正在变成写作、表格、PPT 之后的新通识能力。

配置即 Markdown：Agent 的"代码文件"

AGENTS.md   开放标准（Linux 基金会），6 万+ 仓库
            Codex / Cursor / Copilot 原生读取
CLAUDE.md   Claude Code 每次会话自动加载的
            "常驻系统提示词"
SKILL.md    一个文件夹 + 一个 md = 一项技能
spec.md     Spec 驱动开发：md 是源码，
            代码是编译产物

为什么是它？

• 人机通用：人读得懂，模型也读得懂，不需要中间翻译
• 进版本库：md 文件能 diff、能 Review、能走 PR——提示词第一次有了工程管理
• GitHub 官方定调：Spec-Driven Development = "把 Markdown 当编程语言用"
• 写得越准，AI 干得越对：描述能力成了新的编程能力

Claude Pro（≈ Cursor Pro / ChatGPT Plus）

• 每天 1-2 小时 AI 辅助开发够用（约 45 次请求 / 5 小时窗口）
• 全功能 Claude Code：终端 + 桌面 + IDE，Sonnet 和 Opus 都能用
• 适合：学生、新手、想先验证工作流的人

Claude Max 5x

• Pro 的 5 倍用量，长任务、多会话不再掐着表用
• 适合：每天以 AI 为主力干活的全职开发者
• 判断标准：连续两周经常撞 Pro 限额，就该升这档

Claude Max 20x（≈ ChatGPT Pro / Cursor Ultra）

• Pro 的 20 倍用量，限额基本无感
• 适合：全天多 Agent 并行、跑跨天云端任务的重度玩家
• 团队规模化：考虑 Team 版或直接走 API 按量付费

对人：Review 得动

每个 PR 只解决一个 Issue，改动小、目的明确，十分钟能看完。

对 AI：Issue 就是 Spec

写得好的 Issue 可以直接喂给 Cursor / Claude Code / Codex 当任务描述——一份输入，人机通用。

工作流的每一步，都有一条命令

# 建任务
gh issue create --title "新增 Agent 名称输入框"
# 提 PR（自动带上 commit 信息）
gh pr create --fill
# 盯 CI
gh pr checks --watch
# Review 与合并
gh pr review --approve
gh pr merge --squash

更重要的：gh 是 Agent 的"手"

• Claude Code / Codex 操作 GitHub 靠的就是 gh——开 PR、查 CI、读 Review 评论、回复讨论
• 装好 gh 并 gh auth login 一次，Agent 就能跑通 Issue → PR → 合并全流程
• 把它写进 CLAUDE.md："完成后用 gh pr create 提 PR，并等 gh pr checks 全绿"——流程变成了 Agent 可执行的指令

分支：隔离 AI 的改动

feature/issue-12-agent-create
bugfix/issue-18-task-status
hotfix/login-error

英文小写 · 用 - 连接 · 带 Issue 编号
永远不直接在 main 上写代码

• AI 改崩了？删分支重来，零成本
• Codex 云端任务也是：一个任务一个分支一个 PR

推荐 Prompt：先问方案，再要代码

请先不要直接改代码。帮我分析：
1. 这段代码在做什么
2. 我的需求应该改哪些文件
3. 最小改动方案是什么
4. 可能影响哪些地方
5. 我应该怎么测试

我的需求是：xxx

• 看懂方案之后，再让它动手
• 生成后检查：有没有改太多文件？有没有删掉不该删的？

Commit：让人看得懂

feat: add agent create form
fix: resolve task status refresh
test: add agent form tests

update / fix / 改一下 / 临时提交 ✕

• 一个 commit 只做一类事
• AI 改一轮 → 验证 → 提交一次，随时可回滚

自测：像用户一样完整跑一遍

• 页面能打开，控制台无报错
• 空输入、错误输入都有提示
• 接口失败时不崩、有兜底
• 没有破坏已有功能

Agent 产品加测：模糊输入会追问而不是乱执行、不无限循环、工具调用失败有兜底、日志能看到关键步骤。

PR 模板四件套

## 我改了什么
## 我为什么这样改
## 我测试了什么
  已测试：
  1. 创建 Agent 成功
  2. 名称为空时提交失败
  3. 接口 400 时页面有提示
## 我不确定的地方

两条铁律

• 测试证据：不要只写"已测试"，要写怎么测的，贴截图 / 日志
• 暴露不确定：不确定的改法直接写出来，比假装全懂强

禁止出现："这是 AI 写的，我也不太清楚。"

这种代码不应该进入仓库。AI 生成的代码，提交者本人负责。

• 禁止直接 push main
• PR 至少 1 人 Review
• CI 通过才能合并
• Secret Scanning + Dependabot

• GitHub Projects：Backlog → In Progress → Review → Done
• 每个任务有状态，不靠聊天记录管理
• Issue 模板 + PR 模板统一格式

• 人和 Agent 共用同一套流程：一个 Issue → 一个分支 → 一个 PR
• Codex 云端并行跑 3-5 个杂活任务
• 瓶颈从"写代码"变成"Review"——所以改动必须小

Agent = Model + Harness

Model   越来越强，也越来越同质化
        ——模型是商品
Harness 包住 Agent 的工具、护栏、
        反馈回路和可观测层
        ——这才是竞争力

88% 的 Agent 项目死在上生产之前。死因大多不是模型弱，而是 Harness 脆。

AI 工程的三个阶段

• Prompt 工程（2023）：怎么问，AI 答得好
• Context 工程（2025）：喂什么上下文，AI 干得对
• Harness 工程（2026）：搭什么环境，AI 能长期稳定干活

Terraform 作者 Mitchell Hashimoto（2026.2）给出核心定义：每当 Agent 犯一次错，就工程化一个机制，让它永远不再犯这个错。

工程师角色的转变

从"亲手写代码"，转向设计环境、写清意图、搭反馈回路——让 Agent 在环境里自己跑对。

每天都能做的 Harness 工程

Agent 又把测试命令记错了？别只是再纠正一次——把正确命令写进 CLAUDE.md。错误一次，规则一条，团队所有人的 Agent 同时受益。

安全底线

• 严禁提交 API Key / Token / .env / 用户数据
• Prompt 集中管理进 /prompts 目录，改 Prompt 也走 PR
• Agent 工具权限最小化：读写分离、删除谨慎、调用设超时
• 关键行为留日志：输入、计划、工具调用、输出、耗时

1. 装上工具，登录一次
   brew install gh && gh auth login
   装一个 Agent：Claude Code / Cursor / Codex 任选

2. 给你的项目写第一份 CLAUDE.md
   项目结构 + 启动命令 + 三条编码规则，10 行就够

3. 打开仓库保护
   禁止直接 push main · PR 必须 1 人 Review

4. 挑一个最小任务跑全流程
   Issue → 分支 → AI 先解释再生成 → 自测 → PR

5. Agent 犯一个错，就往 CLAUDE.md 加一条规则

一周后你会发现

• 第 1 个任务比手写慢——在学工作流，正常
• 第 5 个任务开始反超
• CLAUDE.md 长到 30 行时，Agent 的"翻车率"肉眼可见地下降

别追求一步到位。流程是跑出来的，不是设计出来的——先跑通一个最小闭环。