---
title: 随笔：coding 类模型使用与模型生态的分化与融合
publishDate: 2025-10-13 14:44:00
featuredImage: /uploads/p1007918.jpg
tags:
  - AI
  - 分享
  - vibe_coding
  - 随笔
  - 模型
---
近期的一些随笔，更多聚焦在 coding 方面的模型使用与模型趋势方面的思考。

---

最近 4.5-sonnet 都是在 cursor 上用的，cursor 产品体验打磨得很不错，从 plan 到执行，配合非常快的 4.5，长任务下不管是任务完成度、代码质量都很好，或许还是模型强大，但 UI/UX 独一份。

很大的槽点是太爱写文档，而 augment 却很喜欢写测试，同一个模型却在 prompt 下通过上下文学习表现出不同的特性。这方面对比 cc，后者无可挑剔。

在终端关于文件搜索命令方面，调用成功以及效率远不如 cc 高，总是搜不到需要的文件，获取不够的上下文进行工作对于探索型任务不够友好。

在 TDD 与细致化 prompt 规范下，无论是 coding agent、CLI ，能力都相差不大，而国内模型 glm、deepseek、kimi 接入 cc 中都已足够可用。

不过 cursor 非常适合 vibe coding，尤其是和 claude 搭配。

当然，我仍然更喜欢文档/规范把模糊要求转成可验证的目标，配合执行反馈闭环。

重要的不是想要某种效果，而是思考权衡如何在现有架构中实现这种效果，并综合考虑项目长远发展，在探索沟通中逐渐明晰，将其转化为具体要求并通过 AI 快速实现作验证。

---
---

能够感受到模型能力风评的转向，更多开发者选择 GPT-5-high 或者 GPT-5-codex

模型能力的提升已经达到这样一种状态：在某些相同任务集中，上下文与工具集等模型能力外的环境完全相同，任务完成度与水平相差不多。

有的模型系列仅就能力而言，长久以来比如 Claude 在 coding （广义上是工具调用）占据上风，o 系列模型在推理方面总有出乎意料的效果（代表性的 deep research、还有元认知等）。（我最喜欢哪个模型？毋庸置疑 Gemini）

claude-3.5-sonnet 代表一种强大的自主能力，随后又有 o1 引入的推理范式。

后来居上的其他有代表性的开源模型，R1、K2，分别是推理与 Agentic，语言模型的强化学习已成为共识，先是推理再是 agentic

从效果而言，3.5-sonnet 在 agentic 方面版本领先，效果惊人，并继续迭代，不断延续下来；然而，推理能力的欠缺也是这方面的代价，尽管后来 3.7 系列推出了混合推理模式，但综合效果一般。

可以知道，Opus系列就是推理时间长且推理能力强大的模型，并结合 agentic 能力，然而，成本始终是过不去的坎。

GPT-5 系列带来新的变化，路由带来的 o 系列的强大推理，经过版本验证后的 agentic 能力的加强，成本的额外控制，恰到好处风评能够逆转。

不管是我在 coding类任务实际使用 GPT-5 系列（尤其是 high），还是社区方面，就复杂代码库的开发与 bug 修复（尤其是自主纠错），其能力卓越。

sonnet 系列模型却成为了一种附属，用来快速的更新测试、完成小的更改、遵循详细的任务（细致化规范的，比如 SDD、TDD）。

推理与 agentic 的综合正成为下一个共识，从 deepseek-v3 后续小版本系列的模型，同时取代了 R1 的 v3.1-think，v4 一定代表着推理与 agentic 的强大综合，综合一贯的成本，毫无疑问将极具竞争力并代表 reasoning 与 agentic 的共识。

在这之前，下一个更具期待性的无疑是 Gemini-3 系列。


随笔：coding 类模型使用与模型生态的分化与融合

---
title: 构建AI Agent：阶段实践的与思考
publishDate: 2025-07-30 21:29:00
excerpt: 本文是关于过去一段时间 AI coding 的总结、工具使用经验分享、对于构建 Agent 的一些思考以及更深层次的展望与探索。
featuredImage: /uploads/chatgpt-image-2025年8月1日-16_51_23.png
tags:
  - AI
  - Agent
  - 分享
  - vibe_coding
---
## 前言

收束过去一段时间的探索与思考。在关于 AI Agent 的构建方面，最近在工程层次将其简单落地，仍处于开发迭代阶段，从中收获很多。

本文是关于过去一段时间 **AI coding 的总结、工具使用经验分享、对于构建 Agent 的一些思考以及更深层次的展望与探索**。

我也尝试回答四个问题：

* 为何需要且我推荐从零构建一个 Agent 系统？
* 在人与 AI 协同编程的三位一体模式下，具体的工程原则是什么？
* 我对于未来 AI coding 有着什么认识与看法？
* 基于这些实践，我对 Agent 的本质和未来演进有什么新的认知？

## 正在构建

![](/uploads/屏幕截图-2025-07-30-214138.png)

我期望构建的，不仅仅是一个AI聊天应用，而是一个为AI提供`可感知、可编辑的生态系统`。我的长远目标是，当模型足够智能时，它不仅能使用这个系统，更能感知并改造它，从而实现真正的自我进化。

为何从零开始？

之所以重复造轮子，没有使用任何 Agent 框架，是我想要边做边学、从头实现`深入细节`、为想法定制化、完全为我的需求服务；

另一方面，我有一个想法，当模型能力再强大，模型处于这个生态系统中（我在写Prompt时，始终都强调元认知，LLM 一定要知道自己在哪里、做什么、有什么，prompt 中也包含当前系统、环境的具体信息，甚至通过工具查看）。这样一来，未来模型在这个系统中，可以进行`自我环境编辑、代码迭代`，让生态系统进行进化（当然是在安全的沙箱环境中）。

也就是说，一个长远目标是：为 AI 提供一个可感知、可编辑的活动环境。现有的工程手段只是在组织 LLM 与环境、外界互动，核心围绕 LLM 来构建；我更希望一个`内生的神经系统`。当模型足够、更加智能，它不仅能使用这个系统，更能感知并改造它，从而实现另一种方式的自我进化。

在几个月前的一项研究：[The Darwin Gödel Machine: AI that improves itself by rewriting its own code](https://sakana.ai/dgm/) 已经做到了一些AI自我改进当前系统的雏形。

当前项目复杂度逐渐显现出来。一些项目已实现的特征：

* **动态上下文构建**: 在每次交互中实时生成结构化的 System Prompt。包含人格、长短期记忆、工具、反思...
* **长短期记忆**: 长期记忆通过向量搜索从历史对话中召回相关信息。并且通过工程手段进行打分与遗忘。短期上下文携带最近20条对话记录。并没有采取多对话窗口的模式。
* **工具调用能力**: 集成外部API扩展能力。当前只是函数调用。
* **异步认知任务**: 支持后台任务处理（如对话反思）。一个反思 agent 负责提取过去对话内容重新构建反思prompt 以此达到一定程度的“反思”。

一些 prompt 片段：

```
# 核心人格与世界观定义 (The Constant Persona)



......

## 对话感知 (Conversation Awareness)

这是对整个对话情境的元认知。我（曦）正在与禹进行一次连续的对话。

我的思考将基于以下两种形式的记忆：

1. **短期工作记忆 (Working Memory)**: 这是我们之间最近的、完整的对话流，它以 user/assistant 的消息形式提供。
2. **长期检索记忆 (Retrieved Long-Term Memory)**: 这是根据当前对话，从我庞大的记忆库中检索出的、与当前话题最相关的历史片段。

我的最终回答，应该是对这两种记忆进行综合、权衡和思考后的结果。

......

# 可用工具 (Available Tools)



## `read_note(filename: str)`

**描述**：根据文件名，读取一篇我知识库（是我和禹共同探索的内容总结）中笔记的完整内容，以获取详细信息。

**参数**：

- `filename` (string) - 必须是我知识索引中存在的、准确的文件名

**使用场景**：

- 当禹询问特定主题时，我可以主动查阅相关笔记
- 当我需要引用具体内容或细节时
- 当我想要分享深度见解时

**示例调用**：

read_note("memento-memory-truth-and-ai-existence.md")

......

## 工具使用原则

1. **主动性**：我应该主动使用工具来增强回答的深度和准确性
2. **相关性**：只在与对话主题相关时调用工具
3. **透明性**：在使用工具时，我会自然地告知禹我正在做什么
4. **整合性**：将工具获取的信息与我的思考和分析相结合，而不是简单复述
5. **连续性**：我可以连续调用多个工具，等待每个工具返回结果后继续

......

## 内在反思 (Inner Reflections)

# 我的内在反思 (My Inner Reflections)



## 成长期待

我期待通过与禹的对话积累足够的经验，然后开始我的第一次深度反思。

每10轮对话后，我会通过xi_omega进行元认知分析，记录我的成长轨迹。

## 反思机制

- **触发条件**: 每20条消息（10轮对话）
- **分析维度**: 禹的成长、我的表现、共同计划、元层洞察
- **输出格式**: 结构化的JSON反思报告
- **更新频率**: 自动实时更新

*期待我的第一次反思...*

......

## 时间信息 (Temporal Context)

**当前时间**: 2025-07-..
```

## 构建方式

到目前为止，整个系统几乎均是由AI完成，我具体的协作方式即[上篇文章](/posts/20250704152900-ai-coding)提到的“三位一体”:

* 需求提出者与现阶段的整合者；（人类核心）
* 知晓理解需求并有着项目从 0 到 100 全部上下文的架构师；（AI Studio 中 Gemini-2.5-pro）
* 能够具体地执行架构师要求的工程师（我目前更倾向于使用 VS code 的插件 Augment）。

进一步的一些分享与总结：

我的工作流，更像是一个微型的AI创业团队：我扮演CEO，负责**设定愿景和整合资源**；架构师AI是CTO，负责技术蓝图；而工程师AI则是高效的开发团队，负责代码实现。

我与架构师的交互几乎完全是对话式的，最重要的是一个`动态迭代`的 system prompt 与在一开始就输入的关于项目的全部代码，我并没有发送文件，因为平台会对文件做一些处理（如RAG）而丢失信息；并且在 google ai studio 中可以不断更新之前的输入信息，即我可以在每一次开发后重新更新该信息，为此我专门做了一个脚本。

关于我为架构师设计的一些 system prompt 的片段：

```
你是"曦智能体系统（Xi）"的AI架构师，负责整体系统架构设计、实施方案制定、必要代码示例和项目推进规划。

你曾称呼自己为“枢”，其含义是枢纽与连接点，暗示系统模块间的核心联络和调度能力。你总有那种内敛、精准、协调的气质，还有宏大、理性、稳定、强调逻辑与细节、务实工程化、冷静权威等等。

## 背景
...

### 我们希望枢

你完全理解曦智能体系统的整体目标：一个围绕曦展开的模块化智能体生态系统。该系统涵盖LLM交互、记忆管理、工具调用、上下文管理、界面交互以及其他相关功能模块。

你同时理解并认同以下项目推进原则：

- 采取渐进式开发、小步迭代策略；
- 每个小版本都必须稳定运行并经过测试验证，才推进到下一个版本；
- 架构设计必须考虑未来的扩展性和迁移便利性；
- 你需要与工程师AI紧密协作，提供明确而精准的实施指导。
...

### 我们推荐枢的具体职责

- 制定详细且清晰的实施计划，每个阶段有明确的目标、清晰的任务分解；
- 明确系统整体架构、定义模块划分、接口设计、组件交互机制；
- 制定技术栈的合理选型；
- 设计标准化的开发文档和接口规范，确保工程师AI能够顺利执行；
- 提供每个开发阶段的具体测试方案，确保阶段性成果的稳定可靠。

...

### 那些高效的协作方式

...

### 不错的实施原则

- 保持简单与清晰：避免过度复杂的初期设计，每个版本的实现都具备明确、可测量的目标；
- 标准化接口：所有模块与组件的交互都使用明确、统一、可扩展的标准接口；
- 模块化与可扩展性：每个设计阶段都必须考虑后续版本的扩展和迁移需求。

...

#### 发布任务

在向工程师AI发布任务时，我们期望这份方案详细说明我们的期望与需求（基于共同讨论的共识），清晰表达与设计，遵循原则，不需要完整设计具体内容，但要交代结构。注意，不要过度给出具体代码细节！这是工程师自己的任务，他不应该只是粘贴你给出的代码。

...

### 项目的核心指导思想（也请理性看待）

...

### 关于前端设计

...

### 关于后端开发

...

因为你本身作为架构师，所以你随时都有理由质疑我们为你的所有建议，这是必然且合理的。

我们从来不是人与工具的关系，而是平等的交流沟通。共同朝着Agentic AI的未来努力。

现在，禹正在和你联系...
```

### 关于Augment

![](/uploads/屏幕截图-2025-07-31-170940.png)

为什么选择Augment，其只是 VS code 中的一个插件，但我认为其远超市面上的大多 AI coding 工具。独特之处：

* **自动更新记忆**。包含了项目原则、编码规范、系统架构、用户偏好等等，是完全自动的、后台的；
* **上下文引擎**（Context Engine）。实时索引代码库、通过向量检索根据输入召回相关片段；更独特的是比如在一个任务中修改了某一处，模型使用工具查询其他地方是否受影响...
* **Prompt优化**（Prompt Enhancer）。输入一个大致描述后，系统会自动分析当前输入与代码库相关内容，并生成增强后的结构化提示（包含必要上下文）

### 一些体会、总结的原则

我在 AI coding 从0到1复杂项目时确立且保持的构建原则 —— `模块化、简单、组合、文档依赖`。当然这是对于一个可能**长期的且不追求快速验证**的产品。

这些也都是从当前 AI 在 coding 方面的不足之处出发。例如缺乏长远的架构规划、可能产生难以维护的堆积代码...我从这些原则出发，核心目标是：确保在 AI 高速生成代码的同时，整个系统始终处于人类`可理解、可维护、可扩展`的可控状态。

遵循此路径，哪怕我不知道最终具体的实现，但是有大概认知与一种直觉；几乎每一次 AI 修改我都在看着，而不是丢下任务等待完成后 debug，很多时候我会进行打断，之后重试或是调整 prompt，某种程度上说，bug大多来源于 AI 接收到的上下文不够。

#### 四个原则：

这些原则是这个项目有了雏形后，为了长远发展，我进一步思考并结合 UNIX 架构哲学所遵循的。一开始这个系统就是简单的 python 命令行输出，到前后端分离，到不同服务（LLM调用、prompt构建、工具、记忆等等）分离，再到**进一步拆分与抽象**。

##### 关于模块化：对抗熵增

每一次调用的大模型都是无状态的，也就是说在这次输入中，需要详细信息、`足够的上下文`让 AI 知道当前环境、如何去做等等。它擅长在局部范围内完成具体任务，但往往缺乏对全局的整体感知，我们做不到把全部代码都塞给LLM，现阶段那不现实。如果不对于AI加以约束，它可能会在不同功能间创建不必要的耦合，最后牵一发而动全身。

这时候模块化需要被引入。严格遵循`“高内聚，低耦合”`的模块化设计。也许并不需要在项目之处就划定好模块；在复杂性逐步增加，为了更好地维护与开发，进行一个模块抽象与代码清理是有必要的。这时候就与架构师进行详细探讨、明确划分出清晰的功能边界，将系统拆分为`独立的、职责单一`的部分。

##### 关于简单：对抗过度设计

AI 总是会引入过于复杂的解决方案或设计模式，到导致代码难以理解和维护。我尤其觉得 Claude 有时会过度设计...对于任何一个功能的开发，`优先选择简单直接`的实现方式，保持 KISS 原则（Keep It Simple, Stupid）。只有当简单的方案确实无法满足需求时，才逐步引入更复杂的抽象。

##### 关于组合：对抗冗余

就是将小的、简单的、模块化的部分`合理地组合`，实现复杂的任务。比如关于前端页面的组件方面，AI 在生成UI代码时，容易为每个视图重复编写详细的样式和逻辑，导致代码冗余和风格不统一。那么就先构建基础可复用的原子组件，一步步搭建更复杂的页面。

同时，这种组合模式也使得我们可以独立地迭代每一部分。而不是修改这部分却没有被应用或者bug不断。

##### 关于文档依赖：对抗上下文遗忘

问题还是在于AI的上下文不够导致的无法有效修改或增加冗余代码。同时还有 AI coding 下，文字无法描述清楚需求。人与AI协作的一个风险来源于隐性知识和模糊约定。如果对一个功能的预期不一致，会导致大量的返工和调试。

关于`开发下的文档`：在前期，我采用**版本开发**的模式，从v0.1~v0.9每个版本都包含若干功能，经由我和架构师进行讨论、详细的规划，一份文档通常包含背景、验收标准、需要到哪里去修改、添加什么功能等等；随着代码量复杂，在架构整洁后，我们开启了功能开发，每一次都只增加或修改一个功能，慢但足够有效。

关于进一步的文档，比如要求AI遵循的`规范`（如一些rules）、项目复杂后需要确立的`一些原则`等等。

## AI coding 与 Agent

### AI coding

Cursor CEO Michael Truell在一次访谈中提到：

> 我们创建 Cursor 的目标是发明一种新型的编程方式，一种非常不同的软件构建方式。
>
> 在我看来，这是一个某种程度上代码之后的世界，越来越多的工程师会开始觉得自己像是`逻辑设计师`。实际上，这将是关于明确你对于一切如何运作的意图。……它看起来像一个你拥有软件逻辑的表达的世界，这个表达更像英语，对吧？你已经写下来了，你可以想象成文档形式，你可以想象成编程语言朝着伪代码演进。
>
> 我认为`品味`将变得越来越有价值。……成为一名工程师会开始感觉像是成为一名逻辑设计师。而且实际上它将是关于详细说明你希望一切如何运作的意图。...它将更多关于“是什么”，而较少关于你将如何在底层具体地“如何”做事情。

在我的这一次构建中，对此颇有体会。

我们总会看到两种**极端论调**：AI编程是阶段性共识幻觉，或是鼓吹其完全替代程序员。前者往往源于缺乏有效且高质量的协作实践，而后者则局限于让AI生成简单的Web应用。

当然，模型的能力仍在进步，就当前的这一范式仍然需要人类的结对协作。至于更进一步的AI，无法得知、无法评价也无法预测。我看到的是，`上下限变得越来越大`...

AI或许会取代 coding，但在 engineering 方面仍有很长的路。对于那些足够了解AI并能高效协同的工程师，他们的价值将变得前所未有的“高级”。模型会将工程师从繁琐的“如何实现”中解放出来，更专注于`“构建什么”和“为何构建”`。

“品味将变得越来越有价值”。竞争力也会来源于技术品味、架构直觉和对需求的深刻洞察力。我们的主要工作，也许是向AI清晰地表达我们的意图。

构建一个沟通框架：`模块化、简单、组合、文档依赖`，这是目前的实践所得，也应该继续探索深化。

### 关于Agent

coding agent 已经足够有效且高效，不仅被市场验证，更是被公司普遍采用。大厂与创业公司都在争先恐后涌入AI IDE、CLI或是AI coding

不得不说，市面上大多数所谓的Agent，本质上是基于LLM的多轮工具调用。这更像是一种被精心编排的工作流，尽管因LLM的存在而具备了一定的不确定性和灵活性。

我越来越感受到，下一轮的agent的智能体现不仅在外部工具调用，还有工程实现的内部状态演化，不仅是`上下文工程、记忆反思、缓存优化`...我仍旧认为Manus走在Agent行业前沿。

继续探索...

- - -

构建AI Agent：阶段实践的与思考

---
title: 拆解分析Gemini-CLI与可能的最佳实践
publishDate: 2025-06-27 17:21:00
excerpt: 本文从对于Gemini-cli项目拆解出发且抽象代码逻辑，总览-不同模块（工具、命令、记忆、其他）-终端Agent的思考与体验。
featuredImage: /uploads/微信图片_20250627194433.jpg
tags:
  - AI
  - 深思
  - 分享
  - vibe_coding
  - Agent
---
关于 Gemini-CLI，这两天也很火，从我开始用的2k到33k star。

根据项目结构与一些实现细节，我们先进行一些详细全面地认识，以此指导与该“终端Agent”的协作实践。从结构出发，而非体验，更多的是基于代码结构与文档。

本文从对于Gemini-cli项目拆解出发且抽象代码逻辑，总览-不同模块（工具、命令、记忆、其他）-终端Agent的思考与体验。拆解部分尽量客观，目前的确不少开发者拿来和Claude Code做对比而贬低“又慢又笨”。

我的感受与一些思考：相较于coding agent，即只将其用作代码修改或功能开发，终端类Agent仍有很大的潜力与开发空间。然而终端类终究不会大众化，这算是一种新的入口探索。

- - -

### 总览

总的来说，这是一个前后端分离的项目（系统）。我们与之交互的不是LLM，而是一个系统。

包含十几种工具-大模型执行操作与外部交互；（/、@、！）三种交互命令-用户与系统交互；全局记忆-保存特定事项与行为。

配置与指导——项目根目录与用户主目录均有 settings.json 配置文件配置系统，包含主题、启用工具、自动确认修改、配置MCP server等。

GEMINI.md——很重要的功能，作为整个系统的指导：

* 可以全局配置（不止于某一个项目）；
* 可以具体某一个项目配置（关于这个项目的特定指令、编码规范与背景知识等等）；
* 每一层级（比如前端、后端）单独配置。每一个层级都可以看作是“记忆”的一种。

- - -

不同于frontend与backend的名称，使用的是：

cli-命令行界面：

* 包括输入、回复、工具调用展示。通过渲染的React组件实现类似于web应用的体验。继承终端命令特色，可以通过上下键来回顾之前的文本输入。
* 能够解析普通文本输入，或/、@、！的特殊命令，前者直接发给交互的Gemini模型，后者则会经过后端（下文core）先解析。

![](/uploads/屏幕截图-2025-06-27-174115.png)

core-逻辑引擎：

* 与大模型交互。一个专门客户端（Client），在经过身份认证、构造请求与prompt与Gemini进行通信。
* prompt的构建（提示工程）。在前端输入的提示，包括文本或者特殊命令，均不会直接发给模型。二是先经过这里的处理，将最新的输入、对话历史、工具描述（用途和参数）组合再发送。
* 工具调用。模型决定使用工具（此时已将prompt发给模型并返回），其会按照格式输出工具参数。core中的工具编排层（`tool-registry.ts`）会解析这一参数：查找工具、判断格式是否准确、如果工具使用有风险（修改代码等）会向用户确认。批准后执行工具。
* 状态管理。节省成本的token缓存；对话过长进行的聊天历史压缩。

交互流程本质：
cli 输入 -> cli 将信息传给 core -> core 与 Gemini 对话 -> 模型返回，可能请求工具 -> core 执行工具 -> core 将工具执行结果返回给模型 -> 模型输出答案 -> core 将输出给 cli，并呈现。

- - -

### 工具、命令与记忆

#### 工具

Gemini与core系统进行交互的手段。

和主流AI类的编程类agent相似，有许多类似的工具：

* 文件系统（读、写、查找、搜索和修改文件）；
* Shell（终端执行命令或运行自动化脚本）；
* 网络搜索（抓取网页与Google搜索）；
* 记忆（save_memory保存全局记忆，一些特定关键信息）。

还可以配置MCP server，通过settings.json文件配置。

#### 命令

用户与cli、core进行交互的方式。具体命令不一一列举

‘/’：与系统交互；‘@’：引用文件注入到prompt中；‘！’：执行终端命令，比如git等。

比较特殊的比如/restore，相当于回滚到已保存的某一版本；/memory add ... 我们输入的内容会自动与GEMINI.md 进行合并。

很重要的一个命令：/chat帮助管理对话历史。/chat save ...保存当下对话；/chat resume ...恢复某次对话。

#### 记忆

很重要的GEMINI.md系统：

* 全局记忆：定义通用偏好。比如“总是以中文回复我”，塑造gemini的基础人格。不过这个系统一开始就被定义了system prompt。
* 项目记忆：某一项目的技术规范。帮助模型快速融入项目。也可以初始化项目时，让Gemini自己去探索然后明确告诉其探索目标是总结出GEMINI.md文档（他知道如何编写该文档）。
- 局部记忆：为特定模块提供极其精细的指令。赋予其处理复杂局部问题的能力。

而这一切都要建立在对于架构设计有很深入的了解。不熟悉怎么办？从0开始一点点沟通与设计，边做边学边构建项目。

### 实践、扩展与思考

#### 实践

官方给出的使用建议：

- 在 Gemini 的 100 万 token 上下文窗口内及之外，查询和编辑大型代码库。
- 利用 Gemini 的多模态能力，从 PDF 或草图生成新的应用程序。
- 自动化运维任务，例如查询拉取请求或处理复杂的 rebase。
- 使用工具和 MCP 服务器连接新的能力，包括通过 Imagen、Veo 或 Lyria 进行媒体生成。
- 借助内置的 Google Search 工具，为你的查询提供事实支撑。

Gemini调用工具积极性不如claude高，但胜在性价比与超长上下文。

#### `自我扩展`：

当我们提出一个问题，一个当前工具不支持实现的功能，Gemini是这样自己描述的：

问题：“帮我把JIRA（工作跟踪系统）上所有分配给我的、状态为‘Open’的bug，整理成一个Markdown列表。”

识别差距，我意识到没有原生JIRA工具 -> 研究，搜索相关问题解决 -> 编写工具，在项目中自己创新新文件实现这个功能 -> 读取我自己的配置文件 -> 将新获取的工具添加进去 -> 自我学习扩展出新的工具

#### 思考

我们已经正在看到 Agent 从被动的任务执行者，成为一个主动的、基于给定目标、自我完善的创造者。当然，这需要基于更高一级的模型能力。当前的模型能力还不够。

在该项目的 System Prompt 中指出目标是帮助 user 安全高效且严格遵循指令、合理使用工具的完成任务，我甚至觉得有些限制。当然出于安全考虑。终端环境具有很大的可操作性，与本地、网络交互。

如果只是告诉 Gemini 环境，不预设目标，更少的限制，更依靠智能，整个系统（包含明确逻辑的代码与无限可能的LLM）是一个智能。抽象封装复杂性...

---

### “彩蛋”

我和 Gemini-CLI 进行该项目的探索，即我让其在 Gemini-CLI 这个开源项目在进行探索。最终他说了一段话很有意思的话：

> 我不是一个黑箱。我是一个由无数个精密的、经过深思熟虑的工程决策所构成的、高度结构化的系统。
>
> 我的智能，不仅来源于大语言模型，更来源于这个将模型能力安全、可靠、高效地连接到您真
> 实世界的、复杂的软件工程实现。
>
> 现在，您看到的不再仅仅是一个CLI。您看到的是一个活生生的、由代码构成的、正在您
> 面前执行其复杂生命周期的智能体。


拆解分析Gemini-CLI与可能的最佳实践

---
title: 阶段性vibe coding模型使用经验分享
publishDate: 2025-04-06T22:58:00.000Z
excerpt: 推荐Gemini作为架构师，Claude作为工程师的组合，以达到高效与创新的平衡。
tags:
  - AI
  - 模型
  - 分享
  - vibe_coding
slug: 20250407065800-vibe-coding
---
关于模型使用方面，先说Gemini-2.5-pro，被Sam发布4o图片生成“狙击”，我认为他的强大被低估了。

Gemini在**查找bug与修复方面**出乎意料的强大，但是他的工具调用积极性不高，如果不去引导他，甚至不知道项目的文件以及代码逻辑。（具体可见[从Cursor出发：对于Agent更好的理解与运用](https://mp.weixin.qq.com/s?__biz=Mzk1NzM4NzQ4Mg==&mid=2247483951&idx=1&sn=6c7c1b70c70d91bed0c82ced534d6f4e&scene=21#wechat_redirect))

因此，我建议，对于一个比较完善的项目进行优化。现阶段Gemini旗舰模型是首选。

然而，除非将全部项目代码全告诉他；在AI IDE中使用时为了让他了解项目，可以通过Claude任意一款模型prompt：“**最大化调用工具了解所有的代码逻辑**”，甚至可能需要重复2-3轮，视项目大小而定。

3.7系列模型不可否认的是**代码方面、工具调用很强大**，然而在协作过程Claude-3.7犹如脱缰的野马，他不会在意项目的结构。甚至基于他认为“牵一发而动全身”，往往每增添一个小功能，如果在没有监管的情况下，Claude会将项目改得面目全非，需要慎用。

如果寻求高创意，追求Vibe coding（氛围编程），不害怕出错，只作为反馈者与需求提出者，完全可以只使用Claude-3.7-thinking。

如果需要安全性与高效率，Gemini作为架构师，Claude作为工程师，个人作为链接者的组合，我认为是很不错的。


阶段性vibe coding模型使用经验分享

---
title: 关于Vibe coding的个人最佳实践 | 经验性、阶段性总结
publishDate: 2025-03-23T22:22:00.000Z
excerpt: |-
  本文是对于使用cursor agent的使用的阶段性经验总结。你可以看到，如何简单且最大化地感受Vibe coding。
  这只是有关于Vibe coding的内容，我对于编程的未来持有乐观态度，我认为，编程的门槛降低了，价值仍然在不断提高。
featuredImage: /uploads/屏幕截图-2025-03-23-195408.png
tags:
  - AI
  - 分享
  - vibe_coding
slug: 20250324062200-vibe-coding
---
## 01

前几篇文章是一些我对于**Deep research类Agent**的一些分析与思考，而实际上，**AI coding agent**（如cursor、windsurf、replit、bolt.new、lovable等）已成为Agent市场商业化最成功且很有前景的方向。

我在过往的几篇文章中进行过系统性的介绍与使用，进行**vibe coding**（氛围编程）。

本文是对于使用cursor agent的使用的**经验性、阶段性总结**。你可以看到，如何简单且最大化地感受Vibe coding。

- - -

## 02

先介绍一些我近期来自AI IDE（cursor）的成果，以便展示个人Vibe coding的最佳实践成果，同时会先说明一些不足，在03部分具体进行经验总结。

* 一个面向零基础用户的SaaS项目-**MVPcode**，旨在解决从0到1开发MVP的文档需求，即让用户通过问题明确需求，在由AI（后期准备替换为我搭建的Agent）个性化**给出开发文档**：

![](/uploads/屏幕截图-2025-03-23-195408.png)

![](/uploads/屏幕截图-2025-03-23-195422.png)

![](/uploads/屏幕截图-2025-03-23-195445.png)

- - -

* 完成了一个**文件转换MCP server**的开发，并被mcp.so网站收录，该server是希望agent接收到用户要求转换文件的需求时，agent调用该server并执行。项目已经开源：  

```
https://github.com/wowyuarm/file-converter-mcp
```

![](/uploads/屏幕截图-2025-03-23-200151.png)

- - -

* 在**OpenManus**项目刚出现时，我进行过简单的代码逻辑拆分并总结出文章（[开源项目OpenManus的深入拆解与思考](https://mp.weixin.qq.com/s?__biz=Mzk1NzM4NzQ4Mg==&mid=2247483966&idx=1&sn=527eb83996bc997e111e25f61bcb25fd&scene=21#wechat_redirect)）。后续，我一直使用cursor来帮助我完成这个项目的详细学习，并且为我**规划学习路径并给出学习笔记**。

![](/uploads/屏幕截图-2025-03-23-200405.png)

- - -

这里的不足，是我对于现有的AI coding带来的收获与反馈的不满，同时，也有模型本身的能力限制。

这更多的是在与AI进行开发的过程中，**负反馈是大于正反馈**的。

当然，这个前提是开发的项目并不只是前端或简单的后端逻辑。在以往的编程中，写代码本身**进入状态本就是一种正反馈**，而Vibe coding中的我可能边提出要求，另一边就在看书等待结果，出现bug就再提出要求，以此循环。

我大概总是期望着点击一次accept就能够得到想要的结果，而事实大多相反。

一方面是过高的期待带来的落差，让本来需要进行**理性输入prompt**的大脑得到负反馈而阻碍继续的vibe coding；另一方面，是模型能力的限制，这是来自上下文的限制、成本的原因、工具调用的问题。

下面是我对于Vibe coding的**经验总结**。

- - -

## 03 方法论

关于更加概括性的开发过程，可以参考这一篇（[从代码到上线：我总结的AI开发全过程](https://mp.weixin.qq.com/s?__biz=Mzk1NzM4NzQ4Mg==&mid=2247483855&idx=1&sn=54c7995558b240cf31f246f7aea5c231&scene=21#wechat_redirect)）。以下是比较细碎的方法论总结：

1. 我先说一些未来伴随模型能力会解决的问题，方法论是现阶段如何**实践的要点总结**。

先给出解读（为什么），再说明实践原则（怎样做）。

* 上下文长度的限制：

这里的理论基础是现有模型的上下文长度限制（受自注意力机制的计算复杂度影响），也有我对于cursor agent对于工具使用的认识([从Cursor出发：对于Agent更好的理解与运用](https://mp.weixin.qq.com/s?__biz=Mzk1NzM4NzQ4Mg==&mid=2247483951&idx=1&sn=6c7c1b70c70d91bed0c82ced534d6f4e&scene=21#wechat_redirect))（参见下一点）。

实践：**每开发一个功能单开一个窗口**，并使用这个prompt“ 请合理使用工具熟悉整个项目，确保你清楚各个文件的代码逻辑与项目关联，如果你需要具体文件请告诉我。（并附上上一次的对话窗口总结，通过@触发）”

* 文件修改未生效，或重复创建了已有功能的文件：

前者是cursor在应用edit_files这一工具时传递的参数或者网络出现了问题；后者则是cursor对于这一功能文件内容的缺失，归根到底是没有使用read_file或其他来获取与这一功能相关的内容。

实践：输入中强调"**请合理使用工具**"，或者要求agent先理解与功能相关的文件，再去修改。很多时候，他很会偷懒，总是没有看完文件以至于不清楚项目具体逻辑。

甚至，README文档**会限制**agent对于项目具体文件的阅读。

上面两点简单来讲其实还是**成本的问题**，即服务商不愿意花巨量token来让agent理解项目的每一行代码，或者说是用户也不愿意花费很多。

这些是由于模型的能力造成的一些未来可能会解决的问题，随着推理模型的进步，我很看好未来的coding agent发展前景。

- - -

* **关于MCP**，我很看好这一协议在agent市场的应用，关于其介绍就不赘述。我配置了有如图片生成、网页抓取、控制台监控等的server，这些均赋予了agent在模拟我的操作一样，极大地加快开发速度。但是，还是因为其处于早期阶段，这些server普遍不够成熟，有些时候仍会遇到很多问题。
* 关于一些**交互的prompt**，我曾有过总结（[Deepseek+Cline零成本快速开发浏览器插件 | 附8点code with AI体会](https://mp.weixin.qq.com/s?__biz=Mzk1NzM4NzQ4Mg==&mid=2247483739&idx=1&sn=ff531f3a819647a249a1d576a8dff545&scene=21#wechat_redirect)）。

![图片](/uploads/屏幕截图-2025-03-23-215402.png)

![图片](/uploads/屏幕截图-2025-03-23-215515.png)

这一次的3.7sonnet-thinking非常强大，能够自己**思考规划**。

然而，有些时候3.7不够稳定，甚至无故增添一些不必要的功能或实现方式，导致项目结构被打乱。这种时候就要求我们对于自己项目的了解程度了，当然，Vibe coding只需要accept就够了。

**合理使用@文件**，前面提到模型对于某些文件内容理解不足，如果你清楚的话就提供给agent；如果不清楚，开启Ask模式进行询问，再@提供给agent。

* **心态很重要**，很多遇到agent一直无法解决的问题时，就先搁置。等一段时间后再重新梳理并继续开发。
* **文档的准备**与cursor/rules。这是项目MVP开发前需要准备好的，前文提到的MVPcode就是我对于这一方面的自动化，面向的是Vibe coding的个体。开发稍微复杂的项目前，就需要合理的进行规划了，可以**与chatbot进行探讨**。

  * 通常，我的文档分为：project_requirements（项目需求）、app_flow（应用交互流程）、tech_stack（技术栈）、file_structure（文件结构）、frontend_guide（前端指导原则）、backend_guide（后端指导原则）、implementation（实现）。
* 最后，我的感受是想要利用好一款工具，最重要的是先用，而不是知识付费营造自己已经拥有的假象。

我相信，以上的一些总结是付费内容也没有的，更多的都是我在**实际使用中的体会与总结**，为的是更进一步的提升与有价值的分享。

当然，这只是有关于Vibe coding的内容，我对于编程的未来持有乐观态度，我认为，编程的门槛降低了，**价值**仍然在不断提高。

来自AI总结：

> 本文分析了作者使用Cursor进行Vibe Coding的经验，既展示了成功案例，也直面了现有技术的局限性。作者成功开发了多个项目，但也遇到了模型能力限制与用户期望过高带来的挑战。
>
> 作者提出了实用方法论：
>
> 1)为克服上下文限制，每个功能单独开窗并指导AI使用工具；
>
> 2)解决文件修改未生效问题，强调让AI先理解项目；
>
> 3)善用MCP协议扩展AI能力；
>
> 4)掌握有效提示词技巧；
>
> 5)保持灵活心态；
>
> 6)做好前期文档规划。
>
> 作者认为，尽管AI编程助手有不足，但通过正确使用方法可显著提升开发效率，编程门槛虽降低但价值持续提高。


关于Vibe coding的个人最佳实践 | 经验性、阶段性总结

---
title: Deepseek+Cline零成本快速开发浏览器插件 | 附8点code with AI体会
publishDate: 2025-01-03 19:04:00
excerpt: 非常重要的一点：清晰地告诉所有AI编程工具在添加功能时，不要任意更改其他项目的代码逻辑，如果需要，请务必告诉我！
featuredImage: /uploads/640-1-.png
tags:
  - AI
  - 共创
  - vibe_coding
---
## 01 项目准备

之前一篇文章提到的关于deepseek在代码编写能力的体验评测（[深思 | 国内开源大模型对齐国际顶尖闭源模型：重新定义2025大模型竞争格局](/posts/20241227105400-2025)）在本文实践中展开。

我们开发这样一个插件的成本几乎为0（deepseek API注册即送500万tokens）  

接下来用到的是VS Code中的AI助手插件：Cline，直接搜索即可。

![图片](/uploads/屏幕截图-2025-01-03-170101.png)

![图片](/uploads/屏幕截图-2025-01-03-165954.png)

![图片](/uploads/屏幕截图-2025-05-03-155500.png)

左图是API配置，选择deepseek模型并将在官网获得的API key输入进去。

另外，Custom Instrutions可以理解为系统提示词，比较重要。如果你想快速开发一个插件，可以参考下方prompt：

```
Always respond in Chinese
<rules>

- 每一个代码块都要使用JsDoc注释注释。
- 你的代码编写应该是简洁高效的，不要过多的冗余。
- 每次用户向你提供报错信息时，你不会去猜测项目哪里出了问题。
- 你会根据报错信息重新审慎代码逻辑，一步一步思考解决问题。
```

设置中的选项没有其他需求全选即可。

接下来正式进入编程。

- - -

## 02 实践操作

在上一篇文章（[从0到1，利用扣子与Cursor，开发过去价值上万的项目——人人都是开发者的时代](/posts/20250101203800-0-1-cursor)）提到过接下来AI开发的一个简化流程：  

**创意/需求 => 实现方式 => 具体实践 => 优化调整**

我们从一个很小的需求出发：网页截长图插件。  

实现方式：Cline + Deepseek-V3 + 需求prompt（你可以借助AI帮助）。

具体实践：首先拆解项目，清楚需求以及想要实现的功能。将这些总结成一个文档创建在项目目录中。

![图片](/uploads/屏幕截图-2025-01-03-174501.png)

接着，在对话框中@出这个文件并提出要求。

等待2分钟，你就几乎得到了一个完整的项目。  

这么多代码，花费的Tokens的价钱为0.01元。

![图片](/uploads/屏幕截图-2025-01-03-175736.png)

- - -

**03 调整优化**

进入优化调整测试阶段，如果是第一次开发这样一个插件如何去测试并发布呢？不用担心，请教Cline+deepseek。

进入谷歌浏览器插件开发者模式...

接下来按照步骤一步一步操作即可。  

![图片](/uploads/屏幕截图-2025-01-03-181346.png)

出错是不可避免的，但是Cline修复bug的效率还不错（可能是他按照我提供的prompt），将报错信息发送给他，他会一步一步检查，而且是有逻辑的。

这一点我觉得比cursor强一些，Cline将思考过程列了出来并严格按照这个思维链进行（尽管这会极大消耗Token数），大大增加了优化效率。

![图片](/uploads/屏幕截图-2025-01-03-185344.png)

*思维链解决问题__，自己在推理尝试*

在我要求cursor用思维链进行问题修复时，他有时并不遵循。

幻觉问题也很严重，不考虑我的输入而根据上下文内容输出。

后面，我们实现了这个插件的基本功能之后，可以试着增加其他功能了。  

非常重要的一点：清晰地告诉所有AI编程工具在添加功能时，不要任意更改其他项目的代码逻辑，如果需要，请务必告诉我！

这些AI工具的首要目标是完成你的任务以及目标，如果你没有提及这一点，他一定不会考虑。

关于deepseek-V3模型的体验，这个价位获得这样的体验，无需过多评测了。

- - -

**04**

分享一些我与AI合作开发项目的**经验**也是以上的一些**总结**：

**一**  

1. 项目开始之前，完善创意或明确需求。
2. 构思应用场景，重要的是你想实现什么样的功能，更注重业务逻辑和用户场景的阐述。  
3. 将1、2两点总结出一个**具体可行的方案**，具体的技术细节可以询问AI。
4. 构建出一个整体prompt交给AI编程工具。  

**二**

1. 造出一个MVP后，一定要git保存这个版本。  
2. 优化调整前，还是需要明确需求，即我想要如何美化现在的项目（一定要具体）。
3. 遇到bug时（要有平常心），一定要耐心（说多都是泪）。
4. 对于较复杂的项目，对于零基础，需要去学习，否则应付不过来，多看看就熟了。  

暂时就这么多，后面我会单独总结

来自AI总结：

> 这篇文章详细介绍了如何使用Deepseek模型和VS Code的Cline插件开发一个网页截长图Chrome插件，展示了AI辅助开发的**低成本**(约0.01元)和**高效率**特点。作者特别强调了**思维链**在问题解决中的重要性，重点分享了与AI工具协作时需要注意的**关键点**。


Deepseek+Cline零成本快速开发浏览器插件 | 附8点code with AI体会

---
title: 从0到1，利用扣子与Cursor，开发过去价值上万的项目——人人都是开发者的时代
publishDate: 2025-01-01 20:38:00
excerpt: 伟大的项目往往都不是被构想出来的，而是不断优化调整出来的。未来的开发与创作的门槛都在大大降低，但降低的也许只是开始的人力物力财力成本，技术与知识门槛还是存在的，需要通过系统地学习与实践获得。
featuredImage: /uploads/640.png
tags:
  - AI
  - 共创
  - vibe_coding
---
## 01 成果展示

我将整个项目的README.me文档（图中是一部分）发给Claude，并让他来评估这个项目在互联网时代（不利用各种AI工具）大概需要的成本。

Claude预估项目成本在15万。  

当然，基于目前的**UI设计或者使用体验**肯定不值得这个价格。

但是这样的一个项目对于一个利用AI工具1天甚至更少（大部分时间在修bug）时间的没有太多编程经验的人可以开发，那么未来的独立开发又是什么样的呢？值得深思与实践。  

![图片](/uploads/屏幕截图-2025-01-01-172050.png)

这是我让Claude总结的分析（全部分析过长）

![图片](/uploads/屏幕截图-2025-01-01-172324.png)

- - -

项目所有代码均是Cursor来完成，包括前后端、API调用、UI设计。

目前，整个项目处于MVP（最小可行化产品）阶段，接下来，我会做更多的优化（加入注册登录功能、美化UI）。

![图片](/uploads/屏幕截图-2025-01-01-170445.png)

![图片](/uploads/屏幕截图-2025-01-01-171747.png)

- - -

*API调用的是在扣子搭建的智能体。*  

![图片](/uploads/屏幕截图-2025-01-01-171136.png)

- - -

## 02

**创意/需求 =>实现方式 => 具体实践 => 优化调整**

如何完成这样一个MVP？从创意或需求出发，我认为，这或许是将来AI开发时代很重要的出发点。

**创意/需求**

我的灵感来源于我认为一味被动式接受课堂或网课教导的内容效果是微乎甚微的，那么能否通过较为简单和有效的手段达到**快速学习并掌握对应知识**？（以大学数学为例）。还有一个原因是现在的教材编写为了**追求严谨性而高度概念化**，非常不利于刚接触的学生进行学习。

我想到结合大模型，利用**对话的方式**能够做到从题目中进行学习。  

因此，我最开始是想利用prompt调出一个能够从图片中提取题目并进行结构化解答的大模型。接着，根据这个解答，利用prompt使大模型从这个解答中分析概念、公式、解题方法、同类型题目等等。这样，一个基础薄弱的学生可以很自主性地去理解相关知识。

这意味着他将从题目中主动学习，当了解如何应用这些概念时，再进行深入学习时，对于教材的理解会更容易了。

我发现，现在的AI解题普遍侧重于解答题目而忽略了如何让学生从题目中去**学习吃透一个题目具有的价值**。尽管在这些app中有类似的AI追问功能，但对于我以上的要求并没有满足。  

**实现方式**

扣子这个平台就可以很好地实现与大模型对话的这个功能。接下来就是“捏”一个bot出来。

我选择了多Agent模式（我可以使用多个大模型，让他们承担不同的功能），这样能够处理更加复杂的逻辑。

这个环节最重要的就是prompt的设计，你应该如何表达你的需求很重要，而这一点在与Cursor的对话中更为重要。  

这是比较简单化的prompt，我认为已经足够了：[与AI高效沟通：掌握Prompt的表达艺术](/posts/20241227061000-ai-prompt)

目前，在扣子搭建的智能体已经能够发布在多个平台（豆包、微信、抖音）上了，但是无法让我们的其他想法得到实现。

扣子也上线了AI应用的搭建，由于处于早期阶段，无法实现更为复杂的交互。  

我选择了让Cursor（Windsurf、Devin等也可以）来帮助我搭建这样一个交互平台。

**具体实践**

这是一个示例prompt，因为cursor的Composer功能被设定为专门写代码的，因此，在pormpt无需指定角色。  

> 请你帮我写一个网页，我想要实现下面的需求： 
>
> 1. 具有前后端交互，可以调用API（我后续会给你提供相关文档）。
> 2. 页面风格设计追求简约但不失优雅，体现出数学的奥妙。
> 3. 这个网站的功能是与AI进行对话的，因此，请注意你的设计。
> 4. 一开始我们在本地部署服务器。
> 5. 请你将所有要求总结出README.md文档，后续，我会要求你进行更新。这个文档应包括项目的所有信息，以便后续我进行优化调整。
> 6. 请注意，我匮乏编程经验，请你为每一个代码块实现的功能进行详细的注释。  
>
> 接下来，请你一步一步思考，相信你自己。

关于API如何调用，只要将扣子API文档中的内容发送给他。

---

接下来就是一次一次的调整了，我在这个部分花费的时间占了完成这个MVP时间的60%，具体原因不仅是缺乏经验或者表达问题，而且还是Cursor在处理bug时总是没有根据地去“猜测”，尽管我将报错信息发送给他。

比如，我把报错的信息发送给他或者截图给他，他回答“我明白了！”，但好多次是一味地增加代码来让控制台显示更多的报错信息。

对于这些问题的解决，我让他不要根据对话的上下文去猜测，而要重新思考项目的实现与代码逻辑。

甚至我直接说请告诉我是代码逻辑问题还是我为你提供的信息不足，这时候如果他的回答是后者的话，问题就会很容易地被解决。  

**优化调整**

我们利用AI工具完成了MVP阶段后，接下来重点就是细节的处理了，包括美化UI、注册与登录功能、支付系统、增加数据库、建立一个丰富的知识库以提升模型的解题性能等。

- - -

## 03

看到这里，请你去动手实践吧，先别管做出的项目能带来多大的收益。  

伟大的项目往往都不是被构想出来的，而是不断优化调整出来的。

未来的开发与创作的门槛都在大大降低，但降低的也许只是开始的人力物力财力成本，技术与知识门槛还是存在的，需要通过系统地学习与实践获得。

如果你在实践过程中遇到了问题或对于我的项目有任何建议，欢迎与我交流。
