笔者从业之初有使用过jquery + bootstrap写前端页面的经历,后专注于后端开发,多年未再开发前端功能。本文记录了笔者使用opencode开发基于vue技术栈的页面、自测、ui自动化测试,以及修复bug的全部过程。相关开发经验也可以迁移到其他AI编码工具,如claude code 或者 codex 等
序章:全栈的ROI考量
为什么要挑战全栈这件事,躺在后端的舒适区里不好吗,它能带来什么样的价值?
内部管理系统的特点: 重后端逻辑、轻前端体验
- 用户少且固定:使用者是内部员工如产品,运营甚至是后端开发者自己
- 交互简单,对UI/UX要求不高:绝大多数是表单、表格、按钮和弹窗的组合,极少有复杂的动画或极度动态的交互。能用,不造成资损就行。
- 数据驱动,而非设计驱动: 内部系统的页面大多是数据密集型的,如各种报表、列表、详情页。开发的重点在于如何高效地从后端获取数据并展示,而不是如何进行创意设计。后端开发人员对数据结构和业务逻辑最熟悉,由他们来写页面能更好地将数据与视图绑定。
在这种情况下,引入一个专业前端工程师可能是一种"资源错配"。因为他的核心技能(复杂状态管理、极致性能优化、跨端适配、用户体验设计)在这种场景下就是杀鸡用宰牛刀,并且沟通成本却会增加。
内部管理系统前后端分离的弊端:
- 沟通成本,研发效率:一个功能从需求到上线,如果在后端和前端团队间传递,会产生大量的会议、联调、接口拉扯。由后端一人完成,信息损耗为零,交付速度最快。
- 人力成本与资源分配:招聘和培养专业前端成本不低。对于大量"简单"的内部系统,公司更倾向于将稀缺的前端资源投入到对用户体验要求极高的客户产品(如App、官网)上。
有了AI加持,学习一门新技术的愈加容易。取消分工(即全栈)会是一个趋势。
核心考量:沟通对齐成本 + 工作协调 + 联调成本 > 学习前端的成本(AI加持)
一 需求背景
企业微信客户灰度配置功能一直是通过后台数据库进行管理,并没有前端配置页面。现在需要为企业微信客户的灰度配置增加前台管理页面,方便运营管理。
- 灰度规则分为按机器人id灰度,按微信群id列表,按客服的组织架构进行规定。这三个配置都需要下拉列表搜索。
- 配置项操作需要支持编辑启用停用。
- 操作记录列表分页展示,需要支持搜索功能。
二 开发前的准备工作
1 opencode安装及配置
chrome mcp 配置,用于ui自动化测试
打开C:\Users{你的工号}.config\opencode\opencode.json,增加如下配置
json
"chrome-devtools": {
"type": "local",
"command": ["npx", "-y", "chrome-devtools-mcp@latest"]
}
2 idea 插件配置
插件市场搜索apifox helper插件并安装

3 前端技术栈学习
对前端技术栈有个全局的理解,后端开发同学需要具备review AI工具生成的代码的能力,对代码质量兜底。
| 组件或工具 | 说明 | 目标 |
|---|---|---|
| html | 用于创建网页的标准标记语言 | 了解 |
| javascript | 前端语言 | 基础的语法 |
| typescript | js的超集 | 基础的语法 |
| css | 样式表 | 了解 |
| node.js | JavaScript 运行时环境 | 会安装 |
| npm | JavaScript 包管理工具 | 会使用命令 |
| vue | UI库 | 基础的语法,工程结构,组件 |
| 公司前端组件库 | 类似后端maven私服 | 会使用,会传参 |
学习难度:比后端的中间件或者jvm调优简单,相当于后端的crud的难度。借助大模型,学习新技术效率比过去高很多。
三 开发流程
1 为前端工程生成AGENTS.md文件
AGENTS.md是给ai coding agent使用的操作手册,相当于给人看的 README.md。 这个文件每次opencode启动都会加载到opencode的上下文里,并且不会被卸载或者压缩,属于长期记忆。
使用 /init 命令创建,opencode会调用一个叫explorer的子智能体全局扫描
json
/init
需要增加的内容
手动改agents.md需要重启opencode 否则无法生效
- 回复语种指定
始终使用简体中文回复
b. 中间文件存放位置指定
tmp/ - 所有AI coding agent生成的中间文件,都放在这里
c. 禁止自动commit
commit代码必须由我来操作!严禁自动commit代码
d. tdd前端测试驱动开发流程及ui自动化测试配置
md
## 测试驱动开发 (TDD)
### 强制要求
**所有功能开发或 Bug 修复必须遵循 TDD 流程,并使用 Chrome DevTools MCP 进行集成测试验证。**
### TDD 工作流程
1. **编写测试用例**
- 在实现功能前,先编写测试用例
- 测试用例应覆盖正常流程、边界情况和异常情况
2. **运行测试验证**
- 使用单元测试框架验证逻辑正确性
- 使用 Chrome DevTools MCP 进行前端集成测试
3. **实现功能代码**
- 编写最少量的代码使测试通过
- 遵循代码规范和最佳实践
4. **重构优化**
- 在测试通过的基础上进行代码重构
- 确保重构后测试仍然通过
### Chrome DevTools MCP 集成测试
#### 必测项目
所有前端功能必须通过以下测试验证:
1. **UI 渲染测试**
- 验证组件是否正确渲染
- 检查样式是否符合设计稿
- 使用 `chrome-devtools_take_snapshot` 获取页面快照
- 使用 `chrome-devtools_take_screenshot` 截图验证
2. **交互功能测试**
- 使用 `chrome-devtools_click` 模拟用户点击
- 使用 `chrome-devtools_fill` 填写表单
- 使用 `chrome-devtools_hover` 测试悬停效果
- 验证交互后的状态变化
3. **数据验证测试**
- 使用 `chrome-devtools_evaluate_script` 执行 JavaScript 验证数据
- 检查 DOM 元素的文本内容、属性值
- 验证样式值(如背景色、字体大小等)
4. **网络请求测试**
- 使用 `chrome-devtools_list_network_requests` 监控网络请求
- 使用 `chrome-devtools_get_network_request` 检查请求详情
- 验证 API 调用的参数和响应
#### 测试示例流程
```bash
# 1. 启动开发服务器
npm run dev
# 2. 使用 Chrome DevTools MCP 进行测试
# - 导航到目标页面
# - 获取页面快照,验证元素存在
# - 如果遇到登录界面,则点击一键登录的tab,然后点击一键登录按钮
# - 执行交互操作
# - 验证结果
# - 检查网络请求和控制台错误
手动改agents.md需要重启opencode 否则无法生效
2 opencode切换到plan agent
按tab键切换到plan agent

Plan agent (架构师/技术负责人视角) : 不直接修改代码,而是理解需求并生成自然语言形式的实施计划。它通过读取代码库,分析依赖关系,输出高层级的设计文档。
Build agent (工程师视角) : 基于 Plan 阶段确定的路径,执行具体的代码编写与文件修改。
3 使用idea插件生成后端接口文档
导出markdown格式的接口文档,放到工程下面或者顺丰云文档里,建议存放到临时目录/tmp下。

踩坑记录,响应体的data字段要用泛型,否则工具无法判断返回的是哪个类。
4 写开发提示词
提供给大模型必要的信息,善用@上下文注入操作:
在哪个页面上开发?
哪些组件可以复用?避免ai重复造轮子
接口文档的位置?
业务逻辑?
现在我需要在@src\views\system\grayConfig\index.vue 这个页面上增加一个新的tab页,名字叫企微功能灰度。新的tab页的交互和样式完全参考@src\views\system\grayConfig\function,新的企微功能灰度tab页和这个tab页的灰度配置数据的增删改查的接口不一样,配置列表、操作记录列表、停用启用的展示和操作完全一样。配置的编辑略有不一样,rule字段:0-全量灰度,不可编辑,仅展示。 1-指定群id,则用输入框展示config字段,可编辑,2-指定机器人,则用输入框展示config字段吗,可编辑,3-指定组织,则调用@src\components\orgSelect/ 这个组件进行组织架构的选择。 企微功能灰度的增删改查的api在@tmp/api.md 里。尽量复用@src\views\system\grayConfig\function/ 这个文件夹下的组件和其它相关的组件。
5 反复进行需求及技术细节的澄清
plan agent会针对需求及技术细节进行多轮提问,需要逐个回复大模型
6 切换到build agent
大模型所有的问题回答完毕后,按tab键切换到build模式,让agent开始干活。
plan: 需求整理 + 技术规划 + 任务拆解
build: 代码实现
7 bug修复/ui自动化测试
告诉大模型bug的必须要信息,并驱动chrome自动化验证:
哪个页面的问题?
哪个组件的问题?
问题的现象?
提示词
@src\views\system\grayConfig\wecomFunction\operateRecord.vue 操作记录页面的生效范围规则展示错误,生效范围内容用后端返回的effectiveScopeContent字段。
ai驱动chrome进行ui自动化测试
8 找前端同学review代码
前期需要前端同学介入。
四 开发效能数据
| 需求 | 企微灰度配置管理页面 |
|---|---|
| 功能点 | 1. 配置编辑(机器人、群、组织架构) 2. 启用停用 3. 操作记录分页查询 4. 配置列表页 |
| 代码行数 | 1404行vue技术栈的前端代码,100% opencode直出 配置列表页 机器人选择组件 企微群选择组件 编辑抽屉组件 操作记录组件 少量后端代码 |
| 提测质量 | 一个bug (100% opencode 修复) |
| 纯人工手搓代码开发时长(前端同事评估) | 2.5人天(熟练的前端开发5个组件1.5天 + 前后端接口拉通及联调各0.5合1人天) |
| 使用opencode开发时长 | 2人天用于前端工程熟悉和vue语法学习(一次性成本,不计入效能对比) 2人天用于实际代码开发及bug修复 |
本次探索预估提效:1 - ( 2 / 2.5) = 20%
整体研发流程opencode介入情况

ai编码工具全流程介入,是我们的目标。
五 opencode 原理
1 opencode全景图

大模型是无状态的,不会记住任何东西。只能做实时推理。
命令行调用本机工具
shell
mysql -u root -p -D my_database -e "SELECT id, name FROM users LIMIT 5;"
命令行调用远程工具
shell
# 查询远程数据库 remote_db 中 users 表的前 5 条记录
mysql -h 192.168.1.100 -P 3306 -u myuser -p -D remote_db -e "SELECT id, name FROM users LIMIT 5;"
# 执行多条语句,用分号分隔
mysql -h db.example.com -u admin -p -D mydb -e "SELECT NOW(); SELECT COUNT(*) FROM orders;"
# 连接远程主机 192.168.1.200 的默认端口 (6379),并执行命令
redis-cli -h 192.168.1.200 -p 6379 PING
# 如果远程 Redis 有密码,使用 -a 参数(注意 -a 后的密码会明文显示在命令历史中,有安全风险)
redis-cli -h 192.168.1.200 -p 6379 -a your_password GET user:name
命令行式ai coding agent才是业界主流,终极形态

2 失忆问题
上下文窗口

以一个三轮会话为例


上下文:大模型每次预测下一个token所能注意到的文本数据
上下文窗口:大模型每次预测下一个token所能注意到的文本数据最大长度,不断的向右滑动。
一旦多轮会话的全部问答超出了上下文窗口,agent会自动触发上下文压缩机制。仅有关键信息被保留,非关键信息丢失,于是"失忆"了。
上下文污染

在前面的现象里,上下文里充斥着这些内容。
- 跑测试 → 500 行日志。
- 搜索代码 → 200 行 grep。
- 分析错误 → 一堆中间推理过程......
这些信息有一个共同特征:它们对"当下执行"是必要的,但对"后续决策"是噪声。而 opencode 的主对话上下文是线性追加的,不会自动过期,默认"都当成重要记忆"。所以问题不是 opencode突然不聪明了 ,而是它把临时执行数据,当成了长期决策记忆。 这在工程上,本来就一定会"炸"。
上下文窗口限制与上下文腐烂现象 => 长期记忆 + 隔离上下文
3 短期记忆 vs 长期记忆
都属于agent层面的功能
大模型本质上是没有记忆的,无状态的
短期记忆:agent每次都把聊天历史放到提示词中。
- 一旦会话的轮数过多,agent就会对对话进行截断或者压缩,避免超出上下文长度限制。这就导致agent失忆,遗忘前面的提示词。
- 会话终止,则所有的短记忆都会被清空。
长期记忆:利用外部存储对重要信息进行持久化,如文件系统,rag,关系型数据库
4 编码智能体的长期记忆 Agents.md
它是一种在会话开始时自动加载、高优先级的背景知识。为 AI Agent 创建一个专属的、标准化的 README.md 文件。
精准地向 AI Agent 传达了最高频、最核心的几类信息:
环境与启动:AI 一眼就能知道这是vue项目,用了什么框架,以及如何把它跑起来。
测试与质量:AI 清楚地知道如何验证自己的代码修改(make test)和如何保证代码质量(make lint)。
协同规范:当 AI 被要求生成 Commit Message 或 PR 时,它会严格遵循我们定义的格式,确保与团队的工作流保持一致。
可以看到,AGENTS.md 就像一张"项目说明书",但它的读者不再是人类,而是 AI Agent。它用一种结构化的、无歧义的语言,为我们接下来的人机协作,设定了清晰的"游戏规则"。
参考资料
- https://code.claude.com/docs/zh-CN/best-practices claude code最佳实践
- https://mp.weixin.qq.com/s/wf3l4ngPTENl7rk88piRLg 【AI Coding】借助cursor实现业务需求全栈交付实践
- https://research.trychroma.com/context-rot 上下文腐烂
- https://platform.claude.com/docs/en/build-with-claude/context-windows 上下文窗口
- https://time.geekbang.com/column/intro/101089301?tab=catalog AI 原生开发工作流实战