通过 Vibe 贡献代码的思路#

先别急着写代码#

以我公司的一个 PHP 项目为例，我本人之前主要语言是 Python，并不熟悉 PHP，在这种情况下，熟悉一个数百万行的 PHP 项目并不容易，哪怕只是其中一个模块，理解其相关的结构也不是一件简单事。

所以第一步自然是让 AI 分析需求..吗？并非，其实第一步应该跑一遍 init 生成 AGENTS.md，作为能够生成代码库规范的指引文件，我们需要它或者另一种方式来生成，至少是生成要写的部分的代码规范。为什么不直接去理解代码库的结构呢，那太花时间了，且仅对最后的审查有意义。在最后审查时实际上只需要看到文件差异就可以大体知道是什么思路，实现符不符合要求了。

之后，就开始进行需求沟通，我有一个 dev-docs 的 Skill，会帮助我创建我自己的规范文档，结构如下：

1
{DOC_ROOT}/
2
├── README.md              ← 文档入口（文档索引）
3
├── _templates/            ← 文档模板（新建文档时复制使用）
4
├── assets/                ← 图片、截图、架构图等资源文件
5
├── conventions/           ← 开发规范、用户习惯、备忘录（持续更新，以最新为准）
6
├── features/              ← 功能文档（按功能聚合，日期编号排序）
7
│   ├── archive/           ← features 下已终态/失效 feature 归档
8
│   └── YYYY-MM-DD-功能名/
9
│       ├── 1-需求.md
10
│       ├── 2-设计-标题.md
11
│       ├── 3-实现.md
12
│       └── 参考/
13
├── adr/                   ← 架构决策记录（跨功能的技术决策）
14
│   └── archive/           ← adr 下已终态/失效 ADR 归档
15
├── wiki/                  ← 面向开发者的项目 Wiki（按主题分文件夹）
16
│   ├── architecture/
17
│   ├── development/
18
│   ├── features/
19
│   ├── operations/
20
│   ├── references/
21
│   └── archive/           ← wiki 终态/失效/移除内容归档
22
└── archive/               ← 其他跨分类归档（仅在没有对应分类 archive 时使用）

这不是最好的结构，只是我经常需要，就做出了这样的结构，实际使用中只有 features 用的多。当然，如果项目中有自己的结构文档，Skill 会查找项目中自己的文档并使用其结构。

做需求的目的呢，是确认需求与 AI 达成一致，实现规划是确定 AI 的大体实现方向没有问题。到这里，在实现一些小功能时就可以直接 loop 调用直到写完了。

写代码和复核#

Agent 确认完毕后，打开 IDE 看一眼差异更改，主要是看 AI 写的位置对不对，然后都写了什么类什么方法，不需要看的很仔细，看到这些就差不多知道 AI 是怎么实现的了。此时再委派两到三个不携带当前上下文的 Subagent 去复核本次更改，对边界以及其他问题进行修复，基本上中小需求到这里就可以上测试环境测试了。

如果是比较大的需求，在上面的基础上，额外多花些时间核对与制定实现规划，且在最后的逻辑梳理上需要进行额外的核查。如果需要新开模块，需要设计额外的架构时，这时候就需要了解一下项目当前的大体结构了，这时候再搭配 AI 去进行一个梳理，最后会达到一个比较不错的效果。

测试和上线#

还是拿如上的 PHP 项目来讲，我并不想在本机上安装 PHP。针对这种问题，其实已经基于 Docker 有了一种新的环境隔离方案，就是使用 Dev Container。我是自行搭建了一个包含 PHP 开发所需环境的 Docker，本地单元测试的运行全部交于这个 Docker 运行。

在本地测试完全没有问题后，上线服务器的测试环境，然后进行实际功能测试，在实际功能没有问题后，就可以上线了。

And more.#

自己的 Agent 能够做到什么程度，个人认为主要取决于两方面，一个是模型本身的能力，另一个是提示词工程的程度，至于 Agent 之间的编排，那就是另外的事情了。在熟知自己模型能够做到什么程度的情况下，将任务精细到自己模型能够承担且效果不错的程度，就能提升 AI 达成最终目的的效率，不然还要打回重做，到时候耗费的时间会更多。