CONTENT

简介完整的流程本地测试线上部署想法学习方向

简介

ref

1. 框架：还是利用中间件Agent，LLM本质上做的还是根据文本输入进行文本输出

2. 修改代码的格式：以diff的格式，修改指定行的代码；git本身使用历史久，对应的算法积累也成熟。因为如果整体改，容易不按要求修改部分，冗生bug代码。

3. 流程：agent→llm，llm→agent；agent接受diff文件后会进行基础的上下文一致性检测，从而与llm迭代版本

4. 补充优化：将IDE环境中的上下文信息一起发过去，如当前程序的文件结构，用户查看的文件名，打开了哪些文件，命令行的输出内容，时间戳等环境中的信息，用于让LLM更好的理解需求。当然，要注意脱敏

5. 程序部署的流程：部署前端，配置后台，建立数据库。这些功能可以给agent加MCP工具实现部分。

6. 问题：云平台适配
1. 接口API
2. 环境
3. 依赖
4. 配置标准

完整的流程

本地测试

ref

1. user prompt发给agent

2. agent打包”环境信息“，

3. ”工程模板“，

4. 连带”user prompt“一起发给LLM

5. LLM根据整体的prompt，确定用户需求，所要部署的环境，以及云平台的标准模板，开始写，改代码，以diff格式

6. agent校验LLM输出的发代码是否符合标准，符合后根据LLM的输出调用MCP读写改函数，应用到代码修改中；整个过程一般会重复多轮，直到整个项目可以在本地跑通，运行。本地端完成。

线上部署

ref

1. user prompt向agent发消息，内容为请求上线

2. agent同样的，判断请求类型后，打包user prompt，MCP函数说明（功能拓展后的丰富tool库函数），作为整体prompt，发给LLM

3. LLM输出预设标准的命令：前后端部署的命令如创建数据库，上传网站代码等，引导agent调用MCP服务

4. MCP操作云服务，根据输出的命令代码，调用云环境中的功能性函数，前后端部署，建库，配置域等上线操作

5. 整个项目跑完从立项，编码到上线部署的一次完整开发流程

想法

1. 显然，这暂时只适合不怎么需要运维的小项目，应用场景很局限，如一个测试反应的纯前端页面这种。
1. 但如果了解语法，比如能看懂基本的程序语言语法逻辑，就能模块化的细分需求，从而节省一些重复性的工作
1. 像人需要通过抄写，重复加深表意与语言符号之间映射联系
2. 编程需要重复使用语法，加深功能实现的逻辑与语法模块之间的联系
3. 所以理想的AI Coding进化方向不是大而全的包揽前后端，而是精深于个别功能实现模块的打包，以及项目结构即上下文的理解。
4. 新的问题：项目作为整体，上下文的联系很容易受到LLM幻觉的负面影响，而且巨大。

2. 缺点和常见问题：
1. debug时需要有阅读代码的能力，最好有对语法的整体认知，以及常用功能实现方式的了解
2. 拓展性极差
3. 运维困难，因为项目的实现方式不了解的话，无法针对性修改优化
4. 幻觉
5. 落地应用环境的变量不统一，复杂

3. 程序语言 = 语言；
1. 编程 = 写文字；做项目 = 写文章；
2. 现阶段的vibe coding = 好词好句好段模板，高级版的，能根据内容实时自动适配上下文的
3. 有功能性的文章需求，但很明显，好的文章无法靠辞藻堆砌，核心还是文字组合的方式，以及表达选择映射到文字的方式。

学习方向

1. 人负责整理功能实现的项目结构
1. 用到哪些函数
2. 项目的整体结构

2. AI负责根据自然语言，将模块化的需求+项目使用函数或功能组件，以及部署环境打包输入，输出该模块的程序代码。

3. 学习难点：
1. 不同语言的语法，需要时间，重复使用，加深记忆
2. 对项目整体结构和用到的技术栈的架构能力
3. 其它可能性：AI code的迭代速度，碾压了这些复杂的中间过程，幻觉和整体架构的精确度快速缩小逼近到可接受范围。