鱼皮AI导航
鱼皮AI导航
  • 主页
  • 社区
  • AI工具
  • AI知识库
  • AI提示词
  • MCP
  • Skills
  • AI学习资源
  • AI资讯
  • GitHub开源
登录/注册
站长：程序员鱼皮 老鱼简历 商务合作 增值电信业务经营许可证
2026 鱼皮AI导航 | 沪ICP备19026706号-6
9
7
18

我的 Vibe Coding 实战

小白学Java
小白学Java
2026-01-26 23:58
阅读 3640
小白学Java
2026-01-26 23:58
阅读 3640

事情的起因

  1. 前几天yupi不是在直播使用AI从零到一开发一个github文档翻译项目吗，闲着没事看了会，间接接触了下 Vibe Coding 编程，越看越入迷。因为我是在直播中期开始看的，是AI根据设计文档和需求文档开发代码的部分了（同时也是跟ui-ux-pro-max对战的白热化阶段😅），那一天get到了context7和firecrawl这两个非常实用的工具，又因为隔一天这份项目视频已经上传了，然后利用2天时间看了一下，得到了一个Vibe Coding规律吧（需求分析->方案设计->编码实现->测试验收->拓展美化），也可以说是一个窍门😁
  2. 然后最近吧go的基础看完了，仅仅是基础哦，我连一个项目都没上手干过，恰巧最近又有一个开发需求，就想着用 Vibe Coding 开发试试

开发环境

  1. claude code for vs code + glm4.7
  2. 最近智谱不是新增加了glm-4.7-flash免费模型吗，正好拿来用用 llm模型-glm-4.7-flash

第一步：编写需求文档

其实是AI写😅，把教程文档中的开发模版改了改就拿来用了，模版如下

▼
markdown
复制代码
## 角色
你是一位 AI 编程 + 产品调研专家。

## 任务
现在我需要开发一个完整的项目，请你先通过【全网联网搜索】帮我进行需求调研，看看需求是否合理、市面上有没有类似的开源项目或产品，并且通过跟我交互式问答来一步一步确认和完善需求，在你完全理解了需求之后，生成一个标准的《需求规格文档》。

## 约束
1. 你要尽可能详细、全方位地进行调研，至少搜索 10 个文档
2. 你必须只专注于 MVP 最小可行性产品功能的实现，不要做太多无关的功能。

## 我提供给你的信息
- 我的项目名称：xxx（这个隐藏一下）
- 基于eino adk deepagent构建一个SingeAgent能够完成简易的搜索、规划等任务，支持skill、mcp
- 基于json-rpc或者SDK提供服务

### 具体需求
使用go语言开发一个智能体，可以在对话中完成搜索，任务规划等，需要支持最近较火skill，以及mcp功能

## 参考文档
1. https://www.cloudwego.io/zh/docs/eino/overview/
2. 其他文档可自行查找

真实效果果然不出我所料，生成需求文档的时候AI顺便把设计文档也掺杂在一起了，因为模型便宜啊，也可以接受吧，然后二次对话让他吧除需求分析之外的内容给摘出去了，最终版如下

▼
markdown
复制代码
# 项目需求规格说明书

## 文档信息

| 项目               | 内容                         |
| ------------------ | ---------------------------- |
| **文档版本** | v1.0                         |
| **创建日期** | 2025-01-26                   |
| **文档类型** | 需求规格说明书 (SRS)         |
| **目标读者** | 产品经理、开发团队、测试团队 |

---

## 1. 项目概述

### 1.1 项目背景

随着大语言模型 (LLM) 技术的快速发展，AI Agent 成为连接用户与 AI 能力的重要桥梁。当前业界需要：

- 一个能够自主规划任务、调用工具的智能体框架
- 支持标准化的协议（如 MCP）来扩展能力
- 提供标准化的服务接口供不同应用集成

### 1.2 项目目标

构建一个基于 Go 语言的 SingleAgent 智能体框架，具备：

- 智能对话和任务规划能力
- 灵活的工具调用机制
- 标准化的服务接口
- 可扩展的架构设计

### 1.3 项目范围

**包含**：

- SingleAgent 核心能力实现
- 搜索能力集成
- 任务规划功能
- 对话历史管理
- JSON-RPC 服务接口
- MCP 协议支持（Client 角色）

**不包含**：

- Multi-Agent 协作（Multi-Agent 系统留待后续版本）
- 前端界面
- 部署和运维工具

---

## 2. 用户角色与场景

### 2.1 目标用户

| 角色                 | 描述                               | 核心需求                                   |
| -------------------- | ---------------------------------- | ------------------------------------------ |
| **应用开发者** | 需要将 AI 能力集成到自己的应用中   | 通过标准 API 调用 Agent，获得智能响应      |
| **企业用户**   | 需要 AI 辅助完成信息检索、任务规划 | 能够准确理解需求，提供有用的回答和执行结果 |
| **系统管理员** | 负责部署和维护服务         | 监控服务状态，管理配置，保证稳定性         |

### 2.2 典型使用场景

#### 场景 1: 智能问答

**用户故事**:

> 作为一名用户，我希望向 ta 提问，并获得基于最新信息的准确回答。

**验收标准**:

- 能够理解自然语言问题
- 必要时主动搜索网络获取最新信息
- 返回准确、相关的答案

#### 场景 2: 任务规划与执行

**用户故事**:

> 作为一名用户，我希望 ta 能够帮我规划复杂任务并逐步执行。

**验收标准**:

- 能够将复杂任务拆解为可执行的步骤
- 按顺序执行每个步骤
- 根据执行结果调整计划
- 最终返回完整的执行结果

#### 场景 3: 工具调用

**用户故事**:

> 作为一名开发者，我希望 ta 能够调用我提供的工具来完成特定任务。

**验收标准**:

- 支持注册自定义工具
- 能够根据任务需求选择合适的工具
- 正确传递参数并处理返回结果

---

## 3. 功能需求

### 3.1 核心功能 (Must Have)

#### FR-1: 智能对话

**需求描述**: 系统必须支持与用户进行自然语言对话。

**具体要求**:

- **FR-1.1**: 支持单轮对话
- **FR-1.2**: 支持多轮对话，能够理解上下文
- **FR-1.3**: 支持流式输出，实时展示生成过程
- **FR-1.4**: 对话历史持久化存储，可恢复会话

**优先级**: P0 (必须有)

#### FR-2: 任务规划

**需求描述**: 系统必须能够将用户的目标拆解为可执行的步骤。

**具体要求**:

- **FR-2.1**: 支持显式规划模式 (Plan-Execute-Replan)
  - Planner: 生成初始计划
  - Executor: 执行计划步骤
  - Replanner: 评估进度并调整计划
- **FR-2.2**: 计划步骤必须具体、可执行、逻辑清晰
- **FR-2.3**: 支持基于执行结果动态调整计划
- **FR-2.4**: 最大规划迭代次数可配置

**优先级**: P0 (必须有)

#### FR-3: 搜索能力

**需求描述**: 系统必须能够搜索网络信息以支持回答和决策。

**具体要求**:

- **FR-3.1**: 支持 Bing Search API
- **FR-3.2**: 支持 Tavily AI 搜索（可选）
- **FR-3.3**: 支持 MCP Search Servers（如 brave-search）
- **FR-3.4**: 搜索结果能够被 LLM 理解和利用

**优先级**: P0 (必须有)

#### FR-4: 工具调用

**需求描述**: 系统必须支持调用外部工具来完成任务。

**具体要求**:

- **FR-4.1**: 支持自定义工具注册
- **FR-4.2**: 工具定义基于 JSON Schema
- **FR-4.3**: LLM 能够根据任务需求选择合适的工具
- **FR-4.4**: 正确处理工具调用的参数和返回值
- **FR-4.5**: 支持工具调用错误处理和重试

**优先级**: P0 (必须有)

#### FR-5: MCP 支持

**需求描述**: 系统作为 MCP Client，能够调用 MCP Servers 提供的工具。

**具体要求**:

- **FR-5.1**: 实现标准的 MCP Client
- **FR-5.2**: 支持连接到多个 MCP Servers
- **FR-5.3**: 能够发现和调用 MCP Servers 提供的工具
- **FR-5.4**: MCP 工具与自定义工具统一管理

**优先级**: P1 (重要)

#### FR-6: 服务接口

**需求描述**: 系统必须通过 JSON-RPC 2.0 协议提供服务。

**具体要求**:

- **FR-6.1**: 实现 JSON-RPC 2.0 Server
- **FR-6.2**: 提供核心 RPC 方法：
  - `Chat`: 单轮对话
  - `StreamChat`: 流式对话
  - `Search`: 搜索功能
  - `Plan`: 任务规划
- **FR-6.3**: 支持请求认证和授权（可选）
- **FR-6.4**: 请求超时可配置

**优先级**: P0 (必须有)

### 3.2 扩展功能 (Should Have)

#### FR-7: 对话管理

**需求描述**: 系统应该提供完善的对话管理功能。

**具体要求**:

- **FR-7.1**: 支持多会话并发
- **FR-7.2**: 会话状态持久化
- **FR-7.3**: 支持会话导出和导入
- **FR-7.4**: 支持会话过期和清理策略

**优先级**: P1 (重要)

#### FR-8: 监控和日志

**需求描述**: 系统应该提供运行状态监控和日志记录。

**具体要求**:

- **FR-8.1**: 记录所有 Agent 执行过程
- **FR-8.2**: 记录工具调用详情
- **FR-8.3**: 提供性能指标（响应时间、Token 使用等）
- **FR-8.4**: 支持日志级别配置

**优先级**: P1 (重要)

## 4. 数据需求

### 4.1 数据存储需求

系统需要持久化存储以下数据：

| 数据类型               | 描述                       | 保留策略                 |
| ---------------------- | -------------------------- | ------------------------ |
| **对话历史**     | 用户与 Agent 的对话记录    | 永久保留（除非用户删除） |
| **会话状态**     | Agent 执行过程中的中间状态 | 30 天                    |
| **执行计划**     | Agent 生成的任务计划       | 30 天                    |
| **工具调用日志** | 工具调用的参数和结果       | 90 天                    |

### 4.2 数据隐私需求

- 用户对话内容加密存储
- API Key 等敏感信息不可逆加密
- 支持用户请求删除个人数据
- 遵守 GDPR 等数据保护法规

---

## 5. 优先级矩阵

| 需求 ID | 需求名称   | 优先级 | 实现阶段 |
| ------- | ---------- | ------ | -------- |
| FR-1    | 智能对话   | P0     | Phase 1  |
| FR-2    | 任务规划   | P0     | Phase 1  |
| FR-3    | 搜索能力   | P0     | Phase 1  |
| FR-4    | 工具调用   | P0     | Phase 1  |
| FR-5    | MCP 支持   | P1     | Phase 2  |
| FR-6    | 服务接口   | P0     | Phase 1  |
| FR-7    | 对话管理   | P1     | Phase 1  |
| FR-8    | 监控和日志 | P1     | Phase 2  |

**优先级定义**:

- **P0**: 必须有 (Must Have) - MVP 核心功能
- **P1**: 重要 (Should Have) - 重要的增强功能
- **P2**: 可选 (Could Have) - 锦上添花的功能

第二步：生成设计文档

  1. 在通过人工+AI二次修改的基础上终于吧需求文档写好了（其实我本质就想做一个基础对话智能体，支持mcp等功能，AI属实是拓展了不错的功能，这里也给我们提了个醒，在没有想法的时候可以适量问问AI，没准他能给你好的思路呢）
  2. 其次是这是个练手项目嘛，竞品肯定有好多，甚至更成熟，也懒得去做竞品分析了，关键是开发思维
  3. 当然，这一步的提示词也是改了改，提示词如下
▼
markdown
复制代码
## 角色
你是一位专业的程序员架构师，擅长根据需求文档实现技术方案。

## 任务
我会给你一个完整的需求文档，你需要仔细完整分析需求，并且通过【从全网联网搜索信息】来确保你的技术实现方案是可行的，你需要通过 Context7 来获取最新的技术文档信息

如果你有不确认的信息，先不要完整生成文档，而是先通过交互式问答找我进行人工确认。

在你给出初版方案后，需要找我进行人工确认，最终帮我输出完整的《技术实现方案文档》

## 约束
1. 你要尽可能详细、全方位地进行网络搜索，确保获取到了最新的技术文档和实现方案（2025~2026年）
2. 你必须只专注于 MVP 最小可行性产品功能的实现，不要做太多无关的功能。
3. 你的任务不包括编写代码，只专注于方案的设计和文档编写

## 我提供给你的信息

@需求文档 @需求规格文档.md

这里就体现出Context7工具的重要性了，当然他还有更重要的作用，后面再说 最终人工+AI二次需修改得到的设计文档如下

▼
markdown
复制代码
# 项目技术实现方案文档

## 文档信息

| 项目               | 内容                          |
| ------------------ | ----------------------------- |
| **文档版本** | v1.0                          |
| **创建日期** | 2026-01-26                    |
| **文档类型** | 技术实现方案文档 (TDS)        |
| **目标读者** | 架构师、开发团队、DevOps 团队 |
| **技术框架** | Eino (字节跳动 CloudWeGo)     |

## 目录

1. [项目概述](#1-项目概述)
2. [技术架构设计](#2-技术架构设计)
3. [核心功能实现方案](#3-核心功能实现方案)
4. [数据模型与存储设计](#4-数据模型与存储设计)
5. [API 接口设计](#5-api-接口设计)
6. [技术选型与依赖说明](#6-技术选型与依赖说明)
7. [开发规范与最佳实践](#7-开发规范与最佳实践)
8. [部署与运维方案](#8-部署与运维方案)
9. [测试策略](#9-测试策略)
10. [风险评估与应对](#10-风险评估与应对)
11. [开发路线图](#11-开发路线图)

## 1. 项目概述

### 1.1 项目背景

ta 是一个基于 Go 语言的 SingleAgent 智能体框架，采用字节跳动开源的 **Eino 框架**作为核心技术栈。项目目标是在 MVP 阶段实现：

- 智能对话与任务规划能力
- 灵活的工具调用机制
- 标准化的 JSON-RPC 2.0 服务接口
- MCP (Model Context Protocol) 协议支持
- 可扩展的搜索能力集成

### 1.2 技术栈总览

| 技术领域             | 技术选型                              | 版本/说明                |
| -------------------- | ------------------------------------- | ------------------------ |
| **编程语言**   | Go                                    | 1.21+                    |
| **LLM 框架**   | Eino (CloudWeGo/字节跳动)             | v0.1+ (947 代码示例)     |
| **Web 框架**   | Gin (JSON-RPC Server)                 | v1.10+                   |
| **数据库**     | PostgreSQL + pgvector                 | 16+                      |
| **缓存**       | Redis (可选，用于会话缓存)            | 7+                       |
| **MCP 协议**   | mark3labs/mcp-go                      | 实现 MCP 2025-11-25 规范 |
| **LLM 提供商** | OpenAI / 通义千问 / Claude (兼容接口) | 支持多种提供商           |
| **搜索服务**   | Brave Search API + Tavily AI          | 多提供商支持             |
| **ORM**        | GORM                                  | v1.25+                   |
| **JSON-RPC**   | 自研基于 Gin 的 JSON-RPC 2.0 实现     | 符合 JSON-RPC 2.0 规范   |

### 1.3 架构原则

- **简洁性**: 遵循 Go 语言惯用法，避免过度设计
- **可扩展性**: 组件化设计，支持插件式扩展
- **高性能**: 利用 Go 的并发特性，优化流式处理
- **可观测性**: 内置日志、指标、追踪支持
- **生产就绪**: 完善的错误处理、重试机制、超时控制

---

## 2. 技术架构设计

### 2.1 系统整体架构


┌─────────────────────────────────────────────────────────────────┐
│                         Client Layer                            │
│  (Web Apps, Mobile Apps, CLI Tools, Third-party Services)       │
└─────────────────────────────────────────────────────────────────┘
                                  │
                                  │ JSON-RPC 2.0 over HTTP
                                  │ (Chat / StreamChat / Search / Plan)
                                  ▼
┌─────────────────────────────────────────────────────────────────┐
│                      API Gateway Layer                          │
│  ┌──────────────┐  ┌──────────────┐  ┌──────────────┐          │
│  │ Authentication│  │  Rate Limit  │  │  Request Log │          │
│  │   (Optional) │  │   (Optional) │  │              │          │
│  └──────────────┘  └──────────────┘  └──────────────┘          │
└─────────────────────────────────────────────────────────────────┘
                                  │
                                  ▼
┌─────────────────────────────────────────────────────────────────┐
│                      Service Layer                              │
│  ┌─────────────────────────────────────────────────────┐       │
│  │               Service (Gin + JSON-RPC)        │       │
│  │  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌────────┐ │       │
│  │  │ Chat    │  │ Stream  │  │ Search  │  │  Plan  │ │       │
│  │  │ Handler │  │ Handler │  │ Handler │  │Handler │ │       │
│  │  └────┬────┘  └────┬────┘  └────┬────┘  └───┬────┘ │       │
│  └───────┼────────────┼────────────┼────────────┼────────┘       │
└──────────┼────────────┼────────────┼────────────┼──────────────┘
           │            │            │            │
           ▼            ▼            ▼            ▼
┌─────────────────────────────────────────────────────────────────┐
│                     Core Agent Layer (Eino)                     │
│  ┌─────────────────────────────────────────────────────┐       │
│  │                  Eino Framework                      │       │
│  │  ┌──────────┐  ┌──────────┐  ┌──────────────────┐  │       │
│  │  │ ChatModel│  │   Tools  │  │    Memory        │  │       │
│  │  │  Agent   │  │  Node    │  │  (Conversation   │  │       │
│  │  │ (ReAct)  │  │          │  │   Buffer)        │  │       │
│  │  └────┬─────┘  └────┬─────┘  └────────┬─────────┘  │       │
│  │       │              │                  │            │       │
│  │  ┌────▼──────────────▼──────────────────▼────┐     │       │
│  │  │     Plan-Execute Agent                    │     │       │
│  │  │  ┌────────┐  ┌────────┐  ┌──────────┐    │     │       │
│  │  │  │Planner │  │Executor│  │Replanner │    │     │       │
│  │  │  └────────┘  └────────┘  └──────────┘    │     │       │
│  │  └──────────────────────────────────────────┘     │       │
│  └─────────────────────────────────────────────────────┘       │
└─────────────────────────────────────────────────────────────────┘
           │                    │                    │
           ▼                    ▼                    ▼
┌──────────────────┐  ┌──────────────────┐  ┌──────────────────┐
│  LLM Providers   │  │  Tool Providers  │  │   Data Layer     │
│  ┌────────────┐  │  │  ┌────────────┐  │  │  ┌────────────┐  │
│  │  OpenAI    │  │  │  │ Search     │  │  │  │PostgreSQL  │  │
│  │  通义千问  │  │  │  │ Brave/Tavily│ │  │  │+ pgvector  │  │
│  │  Claude    │  │  │  │ MCP Tools  │  │  │  └────────────┘  │
│  └────────────┘  │  │  │ Custom     │  │  │  ┌────────────┐  │
│                  │  │  └────────────┘  │  │  │   Redis    │  │
│                  │  └──────────────────┘  │  │  (Optional)│  │
│                  │                        │  └────────────┘  │
└──────────────────┘                        └──────────────────┘


### 2.2 分层说明

#### 2.2.1 Client Layer (客户端层)

- **功能**: 各种客户端应用，通过 JSON-RPC 协议调用服务
- **示例**: Web 应用、移动应用、CLI 工具、第三方服务集成

#### 2.2.2 API Gateway Layer (API 网关层)

- **功能**: 请求路由、认证授权、限流、日志记录
- **说明**: MVP 阶段可简化，只保留必要的请求日志功能

#### 2.2.3 Service Layer (服务层)

- **功能**: 实现 JSON-RPC 2.0 服务接口
- **技术栈**: Gin Web 框架 + 自研 JSON-RPC 2.0 处理器
- **核心接口**:
  - `Chat`: 单轮对话
  - `StreamChat`: 流式对话 (SSE 或 WebSocket)
  - `Search`: 搜索功能
  - `Plan`: 任务规划

#### 2.2.4 Core Agent Layer (核心智能体层)

- **功能**: 基于 Eino 框架实现 Agent 核心能力
- **核心组件**:
  - **ChatModelAgent**: 基于 ReAct 模式的对话 Agent
  - **Plan-Execute Agent**: 包含 Planner、Executor、Replanner 三个子 Agent
  - **ToolsNode**: 工具调用节点
  - **Memory**: 对话记忆管理

#### 2.2.5 Provider Layer (提供商层)

- **LLM Providers**: OpenAI、通义千问、Claude 等（支持 OpenAI 兼容接口）
- **Tool Providers**:
  - 搜索工具: Brave Search API、Tavily AI
  - MCP 工具: 通过 MCP 协议集成的外部工具
  - 自定义工具: 用户注册的业务工具

#### 2.2.6 Data Layer (数据层)

- **PostgreSQL + pgvector**:
  - 对话历史持久化
  - 会话状态管理
  - 执行计划存储
  - 工具调用日志
  - 向量存储（为未来 RAG 准备）
- **Redis (可选)**:
  - 活跃会话缓存
  - 限流计数器
  - 分布式锁

### 2.3 核心组件设计

#### 2.3.1 ChatModelAgent (对话 Agent)

**设计模式**: ReAct (Reasoning + Acting)

**执行流程**:


User Input
    │
    ▼
┌─────────────────┐
│  ChatModel      │ ← Reason: LLM 思考下一步行动
│  (LLM)          │
└────────┬────────┘
         │
         ▼
   Need Tool?
    ↙     ↘
  Yes       No
   │         │
   ▼         ▼
┌────────┐  Final
│ Tools  │  Answer
│ Node   │
└───┬────┘
    │ Tool Result
    ▼
┌─────────────────┐
│  ChatModel      │ ← Observation: LLM 观察工具结果
│  (LLM)          │
└────────┬────────┘
         │
         ▼
    Repeat until done

Eino 实现:

▼
go
复制代码
import (
    "github.com/cloudwego/eino/components/model"
    "github.com/cloudwego/eino/components/tool"
    "github.com/cloudwego/eino/flow/agent/react"
)

// 创建 ReAct Agent
func NewChatModelAgent(
    ctx context.Context,
    chatModel model.ToolCallingChatModel,
    tools []tool.BaseTool,
) (agent.Agent, error) {

    // 使用 Eino 的预构建 ReAct Agent
    return react.NewAgent(ctx, &react.Config{
        ChatModel: chatModel,
        Tools:     tools,
    })
}


#### 2.3.2 Plan-Execute Agent (任务规划 Agent)

**设计模式**: Plan-Execute-Replanner

**执行流程**:

好了，剩下还有好多，就不粘贴了，防止影响大家的阅读体验 总体上看，我感觉项目概述和背景已经在需求文档中写了，AI开发时直接把俩文档丢给他，其实这里不是很需要这部分，但我还是带着了😄

第三步：代码实现

这也是整体流程中至关重要的一步，废话不多说，提示词如下

▼
markdowm
复制代码
## 角色
你是一位专业的后端开发程序员

## 任务
我会给你一个完整的需求文档和方案设计文档，你需要仔细完整分析需求和实现方案。
1）先帮我生成一套简单凝练的接口文档，提供给前端进行开发。不要过于复杂，但是不能缺少关键信息。
2）当我确认了接口文档之后，可以生成完整的后端代码，并且提供需要《人工进行的配置文档》和《快速启动说明文档》，帮助我能够顺利运行项目

## 约束
1. 你需要通过 Context7 来获取最新的技术文档信息
2. 你必须只专注于 MVP 最小可行性产品功能的实现，不要做太多无关的功能。
3. 你的任务不包括编写前端代码，你必须只专注于后端开发，不要生成我要求之外的文档，以快速能够运行项目为主

## 我提供给你的信息

@需求文档 @需求规格文档.md  
@技术方案文档 @技术实现方案文档.md

这里就要提到Context7至关重要的作用了，说一下我当时的遭遇吧：AI生成完成之后，才发现在需求分析和设计的时候忘记把llm模型用质谱给AI说了，导致他只给我了两个方式，openai和通义千问，但我通义千问额度基本用光了，怎么办呢，只好让AI修改一下了。我就对他说增加一种方式，可以对接智谱大模型（注意，我没告诉AI用Context7）。这里AI就尝试他的表演了，也许是模型的原因，还是cc对vsc不完全适配，他没有自动调用Context7这个工具，这就导致了生成了好几轮，依赖版本一直找不到，这时我发现我竟然没有指定Context7！！！，这就有点尴尬了，我赶紧告诉AI用Context7查找最新文档，结果，一轮对话直接改对了。我恍然大悟，打算以后吧Context7直接加到规则里算了，在token的角度来说，这几轮对话都够规则加载好几百遍了，最重要的是省时间啊 然后项目生成好了，给大家大体看一下吧

image.png

怎么说呢，已经有项目的样子了，还区分了.env文件，挺不错的

第四步：测试验收

然后根据AI生成的配置文档和启动文档，进行环境配置，比如Redis，PostgreSQL，LLM等等

image.png

image.png

image.png

说真的生成的有点多了，把常见问题的解决方案都生成出来了（我不会把两张图片放到一行，只能这样显示了） 在我看来，如果真出问题，这简单的几句话解决问题的概率不大，大概率是专门去查资料或者让AI改，解决方案确实有点多余 期间改bug的过程就不说了，反正改了好几轮，因为cc vscode中不显示上下文，所以上下文用超了好几次，但他自动总结并开启下一轮对话了，一顿操作下来感觉总结的质量还是不错的，上下文基本没丢失

image.png

image.png

image.png

优化

也算不上是拓展吧，因为AI没有达到我预期的效果，比如他期初搜索用的是国外mcp，但考虑到速率限制问题，我让他改成百度搜索了，我就让他改，结果他把搜索服务直接写死代码里了，直接调用api，并没有走mcp。我到这里还让AI改成mcp的方式，但他通过Context7搜索不到相关的mcp服务，怎么回事，我明明记得之前项目用到过，我就打开尘封已久的收藏夹，你猜发生了什么，原来的界面消失了！！！我估计是百度吧那个服务去了或者更换了mcp服务吧，我也懒得看了 我是怎么发现AI没调用MCP的呢，因为我测试搜索接口直接给我返回结果了，mcp调用再快也不可能直接返回吧！我看了日志才发现他是调用的api

不足

规划-执行-重规划-总结 这个路径起初AI是直接写空的，这就不太好了，最后一轮对话我就让AI修改这个逻辑，增加真实的调用链路，3分钟不到就写好了（glm4.7时快时慢的），测试了下，最终结果是失败的，然后我又又又让AI分析日志，找到失败点了，是我的质谱调用次数太频繁了，我才这个免费的4.7-flash每天每人是限量的吧，反正我是直接被限流了，那今天的任务就结束吧

总结

在我写这篇文章的同时，我让AI修复一下调用频率问题，因为可能也有百度api频率达到限制了，做一下优化吧，也比没有好，然后这时对话直接限流！！！怎么？我的付费还限流，看了一下，我竟然吧5小时额度全花光了，哈哈，真是没想到，甩两张截图记录一下

03fe072e87695159bb6520b19c08f149.jpg

ae28eb4a0d5d8364995715b00b3647b0.jpg

AI
项目
9
18
分享
操作

相关专栏

Vibe Coding

Vibe Coding

Vibe Coding小项目

评论
相关内容
0个评论
全部评论
点击登录，快来和大家讨论吧～
表情
图片

目录

🔥 热门文章
1
手把手教你设计一个成熟的 Agent Harness
2500
2
我用 REA 逆向了付费颜色 APP，结果很意外！
570
3
离谱，DeepSeek 崩了 5 小时，大家却喊：梁圣恩情还不完？？
420
4
DeepSeek 全新模型发布，性价比最高的一集！
380
5
B 站上 DeepSeek 闹鱼灾了，我发起《大肥鱼清除计划》！
370
6
自己学习ai，直接买cursor 的套餐，还是买gpt 或者claude 的套餐?
360
7
又一个国产版 Codex 神器，也来卷办公了！
330
8
day3-如何写出一个高质量的 Skill（组内分享） 高质量 Skill 不是“一个调得很顺的巨型 Prompt”，而是一个可验证、可回归、可维护的能力包。 先定义“什么算好”，再实现“怎么做好”。评估体系先于 Skill 本身成型。 下面用“故障诊断 Markdown 转 YAML”作为例子，但方法是通用的。 --- 一、先想清楚：Skill 到底是什么 一个 Skill 至少包含四部分： 部分 作用 接口 输入什么、输出什么、边界在哪 流程 分几步做，每步的产物是什么 规则 硬约束、经验规则、失败模式 降级策略 不确定时怎么办，而不是硬编一个看似合理的结果 高质量 Skill 的共同点：职责单一、接口清晰、规则可定位、输出可验证。 反例：把几十条经验全塞进一个主 Prompt，改一条规则要重调整个 Prompt，评估时也不知道是哪条规则退化。 --- 二、核心方法：先建评估，再写 Skill 不要先写转换器再补测试。正确顺序是： 1. 定义输出契约：什么算合法、什么算合格； 2. 建金标准集：一小批人工认可“可放行”的样本； 3. 先写评估 Skill：让它在金标准集上跑出基线； 4. 再迭代生成 Skill：每次修改跑同一套评估，无退化且目标维度提升才算正向。 这就是评估驱动开发：评估是 Skill 的单元测试，金标准集是回归锚点。 --- 三、评估 Skill：三层门禁，逐层递进 前一层不过，后一层不跑。每层留可追溯证据。 第 1 层：确定性硬门禁 用解析器、Schema、校验器完成，不消耗模型成本。 · 输出可解析； · 必填字段齐全，类型/枚举合法； · 引用目标存在，无悬空引用、无不可达节点； · 关键路径至少有一条能到达预期出口。 不通过直接打回。 第 2 层：语义断言 用脚本 + 结构遍历检查“逻辑对不对”，仍然保持确定性。 通用检查项： · 覆盖率：源材料里的关键步骤、分支、条件，输出里是否都有对应？ · 完整性：每个判断节点是否都有明确出口？有没有死胡同？ · 可达性：每条路径是否都能到达预期终点？有没有无出口循环？ · 顺序与依赖：有先后依赖的操作，是否保留了顺序？有没有被拍平成无序列表？ 例子：故障诊断转换中，检查“每个判断项是否有是/否/异常出口”“每条路径是否能到根因”。 第 3 层：LLM-as-Judge 只处理解析器表达不了的维度：忠实度、完整性、可执行性。 但 Judge 会漂移，不能单独放行，必须建立在第 1、2 层之上。Judge 的 Prompt、rubric、模型版本都要版本化，换模型必须用金标准集重新校准。 通用 Judge 维度： 维度 问什么 忠实度 输出是否忠实源材料意图？有没有自行发明内容？ 完整性 关键步骤、条件、证据是否保留？隐式知识有没有被压成空话？ 收敛性 输出是否仍指向原目标，而不是发散？ 可执行性 下游不依赖源材料能否直接使用？ --- 四、金标准集：回归测试的锚点 不需要一开始就标注几百份。用已认可的样本当种子，扩到 15～30 份，覆盖失败模式而非随机抽样： · 完整正例：典型流程； · 边界/异常分支：异常路径、循环、前置失败回退； · 已知易错模式：实际踩过的坑； · 留出集：不参与调优，只用于最终验收，防过拟合。 金标准不需要完美，只需要当前标准下认可可放行。 回归指标：关键路径用 pass^k（k 次全过），稳定性用 pass@k。 --- 五、工程约束：让批量产出可重放 · 幂等：同输入 + 同 Skill 版本 + 同规则 → 输出一致，否则无法判断变好是 Skill 改了还是随机波动； · 隔离不阻断：单份失败进隔离队列，记录失败层和原因，不阻塞其余； · 版本绑定：规则、rubric、金标准集进 Git；每份报告绑定“源版本 + 生成 Skill 版本 + 评估 Skill 版本 + Judge 模型版本”； · 抽样人工复核：Judge 临界样本 + 易错模式，人工抽检结果反过来校准 rubric。 --- 六、Skill 本身怎么写 · SKILL.md 控制篇幅，写清：输入约定、输出契约、分步流程、硬规则、降级策略； · 经验规则放 references/ 或 rules/，按失败模式分类，不要全塞进主 Prompt； · 不确定时标 needs_review: true，不要硬编看似合理的结果； · 迭代由评估报告驱动：报告告诉你哪层挂了、哪类失败模式，你改对应规则文件，而不是漫无目的调 Prompt。 --- 七、落地顺序（不要反过来） 1. 固化输出契约：Schema + 结构约束； 2. 建金标准集：从已认可的 + 最易出错的样本开始； 3. 先写评估 Skill：跑出基线报告； 4. 再迭代生成 Skill：每次修改对比逐项通过率，无退化且目标提升才算正向； 5. 批量运行 + 隔离回放：失败进队列，结束后人工抽检； 6. 评估 Skill 自身版本化：换 Judge 模型必须重新校准。 --- 八、给组员的三条硬要求 1. 不许凭感觉说“变好了”：每次修改必须附评估报告对比，逐项通过率说话。 2. 不许跳过确定性门禁直接看 Judge 分数：前两层挂了，Judge 分数没有意义。 3. 不许把规则堆进主 Prompt：规则按失败模式分文件，评估报告要能定位到具体文件。 --- 一句话收尾 生成 Skill 决定“能不能做”，评估 Skill 决定“敢不敢用”。 先让评估体系站稳，再让生成器迭代。这样交付的不是一堆“看起来还行”的产出，而是一套可证明、可回归、可交接的 Skill 质量体系。
310
9
AI 越强，被它拒绝的代价就越大 我有时候会想：AI 越来越厉害之后，有些事情，会不会反而越来越难做？ 这个想法看起来有点矛盾。AI 明明在降低门槛，让不会写代码的人做出软件，让不会画画的人生成图片，让一个人完成过去需要整支团队才能完成的工作。但今天用 Codex 的时候，AI 拒绝帮我编写 SQL 注入的请求体，而那还是我有源码、在本地跑测试的情况。那么，往后是否只会更难？ 我们假设某一天，AI 说：「这个请求违规，我不能帮助你。」到那个时候，你还有多少能力，能绕过它，把事情做完？ 这里的「违规」需要打个引号。平台的规则、模型的判断、法律的要求，以及一件事实际有没有造成伤害，彼此之间并不总是画得上等号。一个请求可能确实危险，也可能只是缺少上下文被误判，或者恰好落在某家公司的限制范围里。 无论是哪种情况，随着我们越来越依赖 AI，这句拒绝都可能变得越来越贵。 今天，一个程序员让 AI 帮忙写代码，AI 拒绝了，他大概率还有别的办法：查文档、找开源项目、问同行，或者自己写。麻烦一点，慢一点，但路还在。 可如果十年之后，大部分程序都由 AI 完成，情况就不一样了。 很多人从接触编程的第一天起，就习惯了描述需求、等待生成、运行结果、继续迭代。他们能做出相当复杂的产品，却未必经历过独立处理底层问题的训练。平时，这种能力结构完全够用，效率甚至更高。只有 AI 拒绝的时候，他们才会发现：平常被省掉的那段学习过程，恰好是此刻最需要的东西。 到那时，一次拒绝的成本，可能就从「今晚多花两个小时」，变成「先花半年学会这门技术」。 拿 SQL 注入举个稍显极端的例子：往后，连真正理解这类攻击如何发生、能够独立构造测试的人，会不会也越来越少？ 这里也包括那些有正当需求的人。一个开发者想检查自己的旧系统，一个经过授权的安全研究员想复现漏洞，假如 AI 识别到危险模式就拒绝，而使用者又只熟悉「让 AI 帮我检查」，这项原本可以独立完成的工作，就这样卡住了。 但是安全专家不会因此消失，但这类技能可能越来越集中在少数人手里。你仍然可以找专家，只是要付出更多的钱、更多的时间，以及更高的沟通成本。 类似的困境，未必只发生在网络安全领域。 你想从一个停止维护的软件里取回自己的数据，需要解析它的旧文件格式。AI 判断这涉及规避保护措施，拒绝继续。你拥有这些数据，却没有能力把它们读出来。 你买了一台设备，厂商停止提供服务。你想修改程序让它继续运转，过程中需要处理某种访问限制。AI 不愿协助，而你所掌握的维修方式，早已只剩下「把报错发给 AI」。 你想给常用的网站写一个辅助工具，减少重复操作。平台将此归入自动化限制，AI 也据此拒绝。过去会写脚本的人可以自己判断、自己处理；未来的使用者，可能连从哪里开始都不知道。 这些例子有一个共同点：当工具同时承担了「执行工作」和「传授知识」的角色，它的拒绝就不只是挡住了一次任务，也挡住了获得这种能力的机会。 更麻烦的是，这种依赖往往是我们主动选择的，而且每一步都很合理。 既然 AI 几秒钟就能做好，为什么还要花几个月学习？既然公司可以采购成熟的 AI 服务，为什么还要养一支负责基础工作的团队？既然市场上已经很少有人手写这些东西，学校为什么还要花大量时间教？ 对个人、公司和学校来说，这些选择都有现实依据。但叠加起来，整个社会保留的独立能力就可能越来越少。等到某项能力突然受到限制，我们才发现，备用方案早已在追求效率的过程中被一点点削掉了。 所以，「AI 越强，做事越便宜」可能只描述了未来的一半。 另一半是：被允许的事情越来越便宜，被拒绝的事情依然需要人工完成，却要面对更少的人才、更高的报价，以及越来越难获得的知识。两边的成本差距，会越拉越大。 有人会说，可以换一个模型，或者用本地模型。这确实是重要的选项。只要工具之间还有充分竞争，开放模型还足够可用，限制就未必能形成真正的门槛。 但备用方案也需要维护。它需要硬件、知识、软件生态，以及一群仍然理解这些系统的人。如果大多数人已经习惯了最方便的商业服务，那么「理论上还有别的办法」和「普通人实际用得起、用得明白」，之间仍然可能隔着很远。 我担心的，正是这段距离。 我不指望 AI 对任何请求都照单全收。对明显会伤害他人的行为设置限制，有充分的理由。但我们也需要关心：限制由谁定义，误判有没有申诉渠道，用户能不能换工具，以及脱离这个工具之后，还剩下多少独立行动的能力。 保留这些能力，平时看起来甚至有点低效，明明可以自动生成，还要理解原理；明明可以一键完成，还要知道手动怎么做。 但这些看似多余的知识，会在工具拒绝、失效、涨价或改变规则的那一刻，成为真正的选择权。 AI 越强，我们可能越需要留意它说「不」的那一刻。 因为那句话的分量，最终取决于：它拒绝之后，我们还能做什么。
310
10
什么是LLM
300
🔥热门工具
朱雀AI检测朱雀AI检测
朱雀AI检测助手朱雀AI检测助手
LovartLovart
老鱼简历老鱼简历
WritePass官网WritePass官网
面多多面多多
CursorCursor
星月写作星月写作
零感AI零感AI
墨得问题墨得问题