使用Vibe-Coding开发C2框架时的感想

2026-04-17 14:46:28 # 杂谈

最近闲的没事，使用AI开发了一整套的C2框架，前端GUI界面使用wails3 + Vue，后端使用Go的gin框架，并用Go开发了植入物。

在我最初的计划了，我并没有打算这么早就着手开发C2框架，奈何AI的进化速度让人感慨万千，以前“古法编程”的时代一去不返，手搓底层通信协议、处理死锁、或者设计复杂的系统架构，往往要耗费几天甚至几周的时间，现在有了AI的辅助，开发效率简直是降维打击。

我目前主要使用的AI是Codex-GPT5.4和Gemini 3.1，不要问我为什么不用Claude，不是不想用，是用不起也用不了。

codex-GPT5.4用来做框架的设计、复杂场景的规划和排除纠错，编码也还行，但是GPT5.4它有一个问题，就是喜欢将代码复杂化，不够精简。

Gemini 3.1前端设计优秀，代码编写的效率和准确度也很好（虽然比不上Claude），只要提示词足够优秀，基本上一次就能把功能实现完整。这个两个模型我都是混着来的，并没有说5.4就不能用来编码，Gemini 3.1就不能设计之类的见解。

就比如在开发大文件上传和下载，我就先用GPT5.4帮我规划一遍，然后我提取计划中有用的信息，设计了下面的提示词给Gemini 3.1，并附上：理解需求，列出当前要如何实现大文件上传和下载的规划，由我来确认，确认完后才能开始编码。

一、数据结构设计：

核心数据结构：分块元数据 (Chunk Metadata)
type FileChunk struct {
    TaskID     string `json:"task_id"`      // 关联的具体文件传输任务
    FileID     string `json:"file_id"`      // 文件的唯一标识，使用file的hash值作为FileID
    ChunkIndex int    `json:"chunk_index"`  // 当前是第几个分块
    TotalChunks int   `json:"total_chunks"` // 总分块数
    Data       []byte `json:"data"`         // 加密后的分块数据载荷 (如 512KB)
}

注意：使用项目自带的packet.go中的打包和解包逻辑，不要用json序列化和反序列化。

二、 设计 (Download：目标主机 -> 前端)
1.前端 (Frontend)
	- 发起请求：通过api.sendCommand发送命令请求，命令常量是CommandDownload=28，CommandUpload 29
	- 状态查询：当server每处理完一个分块元数据，就通过websocket向指定用户发送事件，处理完后，就发送完成事件，计算出接收到的数据大小，并发送这些信息给前端（不是文件数据）
	- 获取成品：server成功将文件数据块拼接后，将其存储在本地磁盘中。server会向前端提供GET /api/v1/list_download查询server上可以已经从beacon上获取的文件，GET /api/v1/download获取指定的文件。
2.服务端 (Server)  
	- 任务生成：接收前端指令，将下载任务放入目标 Beacon 的任务队列和数据库中。
	- 状态中心与落盘：Server 需要在本地硬盘static/download维护一个“正在传输的文件”
	- 接收与拼接：当网关 Beacon将传来的分块数据提交给Server时，Server解析出 `ChunkIndex`，按照偏移量（Offset）将 `Data` 追加写入到本地的临时文件中，如果所有分块接收完毕，计算一次完整文件的Hash以校验完整性，最后将任务标记为完成。
3.植入物 (Beacon)
	- 任务初始化：唤醒后拿到下载任务。打开目标文件，计算出文件总大小和总分块数（如按 512KB 切分）。
	- 异步读取（Go 语言语境）：绝对不能用 `os.ReadFile` 把文件一次性读进内存。应当使用 `os.Open` 配合 `io.Reader`，每次只读取固定大小的 buffer。
	- 分发策略：- **单次心跳带多块**：如果 Beacon 睡眠时间较长，可以在一次心跳中，打包上传 2~5 个 Chunks，以提高整体下载速度。
	  
4.注意事项
①防死锁与清理：在 Beacon 端读写大文件时，如果突然断网或 Server 重启，文件句柄可能会一直处于打开状态（导致被系统锁定）。Beacon 内部需要一个超时回收机制：如果某个文件传输任务超过 N 分钟没有收到新的数据块，自动关闭文件句柄并删除传输了一半的残缺文件。
②块大小动态调整 (Dynamic Chunk Size)：对于带宽较大的直连 HTTP Beacon，块大小可以设置为 1MB；但对于通过 SMB 命名管道级联的 Beacon，块太大容易阻塞管道中的心跳包或其他高优先级命令，建议保持在 256KB 到 512KB 之间。
③你可以按照项目的实际需求，优化、补充和完善
④补了上传 ACK 协议
⑤增加了上传聚合运行态

三、前端传来的参数是这样的

完整前端流程

1. 前端下发 CommandDownload=28
2. WebSocket 收到 FILE_TRANSFER_COMPLETE
3. 从事件里的 download_url 或 file_id 获取文件
4. 调用 GET /api/v1/download?file_id=<file_id>
   
每个 FileChunk 成功处理后：FILE_TRANSFER_PROGRESS
最后一个 FileChunk 成功完成后：FILE_TRANSFER_PROGRESS + FILE_TRANSFER_COMPLETE
任一 FileChunk 处理失败：FILE_TRANSFER_ERROR

两个模型帮我编写了99%的代码，至于剩下的1%就是保留咱们的古法编程，不是不小心的，是故意的，古法编程，匠心独具。

除了那一点点的古法编程，在AI编程辅助的时代下，我还能干什么？我是亲生经历，看着AI帮我逐步开发出C2框架，再到后面随着项目越来越复杂，很多意想不到bug随之发生，我还有花大量的时间去排查纠错。

为什么不用AI来排查纠错呢？理由如下

随之对上下文越来越大，AI会越来越笨，不知道自己做了什么事情，忘记前面我提过的需求和一些约定。
耗费token
如果你连问题都提不出来或者提出问题不够具体，等待你的是两种结果：一：AI思考很久，并把问题解决了；二：提出了一些自以为是的解决方案，把项目搞的一团槽，最后还是要自己亲自出马，亲手调试排查问题。

我也看到了网上有很多言论说程序即将失业，就连最近的Claude模型都能挖掘出大型系统的0day漏洞，事实上也如此，我认识的朋友在顶级安全实验室，用着Claude挖掘出十几个0day。

我认为，AI大爆发时代确实淘汰了一部分初级程序员和坚持古法编程的程序员，对于部分白帽子来说也有很大的影响，但同时拔高了顶级程序员和安全研究者的上限。对于顶级程序员来说，他们经验丰富，具备框架设计的能力，能看懂代码，知道什么地方容易出bug并能快速调试排查。对于安全研究者来说，他们可以把自己的挖掘漏洞经验写成一份详细的提示词喂给AI，让AI来挖掘漏洞，效率翻倍。

有些外行用AI开发出一个不能交付的前端页面，然后说程序员即将完蛋，是也可能不是？反正我不做过多评价。

不过AI的出现，确实带来了一个难以逾越的鸿沟，它不仅没有填平技术上的差距，反而像一个放大器，把这道鸿沟劈得更深、更宽了。

初级程序员的知识断层。以前，新手是通过手敲大量的基础代码（比如基础的 CRUD、搭建环境、写简单的脚本）来培养代码感和试错直觉的。现在，AI直接把这块“垫脚石”抽走了，导致地基不稳。

高级级程序员的杠杆效应。这样有经验的开发者来说，AI则是物理外挂，脑海中已经有了清晰的系统架构和战术意图。

这也就是所谓强者恒强，弱者恒弱？算了，不想讨论那么多，直接看我做的C2框架效果（现在还是开发阶段，UI可能变，接口可能变，反正一切都可能变）