七猫技术团队

重构开发范式：AI 时代下全栈开发的实践与思考

陈奥飞 — Wed, 04 Feb 2026 08:07:47 GMT

一、引言：被“沟通成本”吞噬的效率

在传统的软件开发流程中，我们习以为常的一道“墙”横亘在前端与后端之间。不管是开发一个简单的后台管理页面，还是增加一个功能按钮，流程往往是这样的：

后端定义数据结构 -> 编写 API 文档 -> 前端阅读文档 -> 双方对齐字段 -> 前端 Mock 数据开发 -> 联调接口 -> 发现差异 -> 修改代码 -> 再次联调。

这其中，真正用于编写核心业务逻辑的时间可能只占 50%，剩下的时间都被消耗在了上下文对齐（Context Alignment）上。接口字段的变更、数据格式的异议、业务逻辑的传达偏差，这些沟通成本在微服务和前后端分离架构下被指数级放大。

但在 AI 时代，我开始思考：如果“上下文”不再需要人与人之间低效传递，而是由 AI 统一接管，开发模式会发生怎样的变革？本文将分享我近期利用 Go + 前端技术栈，结合 AI Agent 体系，独立完成一套生产级海外广告投放系统的实践经验。这不仅是一次技术栈的整合，更是一次开发范式的重构。

二、核心理念：从“契约驱动”到“上下文驱动”

在没有 AI 的时候，API 文档就是我们的“契约”。但在 AI 介入的整体化开发中，Shared Context（共享上下文） 取代了死板的文档。

为什么 AI 能化解“沟通墙”？当我们将前后端代码视为一个整体投喂给 AI 时，奇妙的化学反应发生了：

零损耗的信息传递： 我只需要告诉 AI “在这个页面增加一个素材上传功能”，AI 同时拥有后端的数据模型（Struct/Schema）和前端的 UI 规范。它不需要“查文档”，因为它知道后端 UploadHandler 需要什么参数，也知道前端 UploadComponent 该如何调用。
原子化的功能交付： 传统模式下，前后端是两条平行的流水线。而在“整体化”模式下，AI 是一次性生成整个功能闭环（Feature Loop）。几分钟内，生成的代码包含了数据库变更、后端 API、前端 UI 及样式。
极高的联调成功率： 既然代码出自同一个“大脑”，字段名永远不会拼错，数据类型永远匹配。联调不再是“找茬”的过程，而变成了单纯的“验收”。

三、架构实践：Go + 前端的一体化交付

为了极致的开发与部署效率，我采用了 Go (Backend) + Static/Embed (Frontend) 的架构模式。

技术选型逻辑

后端： Go 语言。
前端： 原生 HTML/JS/CSS 或引入 Vite 构建的现代前端框架。
部署： 所有的前端资源通过 Go 的 http.FileServer 或 embed 特性打包进同一个二进制文件。

// 示例：极简的静态文件服务集成
srv.HandlePrefix("/admin-gw/web/", http2.StripPrefix("/admin-gw/web/", http2.FileServer(http2.Dir("./web"))))

这种看似“返祖”的单体结构，在 AI 时代焕发了新生。它特别适合后台管理系统、工具类应用。通过这种方式，我们省去了单独配置 Nginx、单独维护前端 CI/CD 流水线的成本。

四、进阶秘籍：构建 AI 的“技能树” (Agent Skills)

单纯依靠 AI 的通用能力是不够的，为了让 AI 生成的代码符合项目规范（99.99% 可用），我构建了一套 Project-Specific Agent System。

1、建立 .agent 规范体系正如我的项目结构截图所示（见图），我在项目中维护了一个 .agent 目录，这不是给代码运行用的，而是给 AI “阅读”用的：

Memory (记忆): 存储项目的核心业务逻辑和上下文。
Rules (规则): 定义代码风格、命名规范、错误处理机制。
Skills (技能):
fbad_backend_dev: 包含 API 定义、DB 字段模式、Go 模块规范。
fbad_frontend_dev: 包含组件库规范、UI 风格指南、页面模板。
fbad_knowledge_base: 包含投放系统的业务架构、Facebook API 引用等。

2、Token 的“一次性投资”

这些 Skill 文档甚至不需要我亲手全写。我通过一次性投入大量 Token，让 AI 扫描现有代码，总结出架构风格和规范，自动生成这些 Markdown 文档。

3、对话即开发

有了这套 Skill 体系，AI 就变成了一个这就熟读项目代码的“资深员工”。

场景： “请帮我重构 AMQP 发布者逻辑” 或 “实现增量内容上传”。
结果： AI 会自动调取 backend_dev 的技能，生成符合 Go 标准的代码；同时调取 ui_styles，生成符合 Material Design 风格的界面。

五、成果验证：海外广告投放系统

基于上述理念，我独立开发并上线了一套生产级别的海外广告投放系统。

代码量级： 数十万行代码。
AI 贡献率： 99.99%（几乎所有逻辑、UI、样式均由 AI 生成）。
开发周期： 仅数周时间。
功能深度： 涵盖素材管理、广告创建、广告管理、广告投放策略配置、Facebook CAPI 对接、实时数据看板等复杂业务。

六、深度思考：工程师角色的转变

这次实践让我意识到，在 AI 时代，工程师的能力模型正在发生剧变：

从“搬砖”到“架构”： 编写具体的 CRUD 代码已不再是核心竞争力。定义 Skill、设计系统边界、构建让 AI 高效工作的“上下文环境”成为新的关键能力。
全栈的回归： 过去因为知识量爆炸导致的前后端分工，现在因为 AI 填平了技术鸿沟，使得“全栈”再次成为可能。一个工程师完全有能力独立闭环复杂的业务系统。
Prompt Engineering 即生产力： 我们不需要手写每一行 HTML，但我们需要懂得如何用精准的自然语言描述业务需求，并将其转化为 AI 可执行的指令。

七、结语

前后端整体化开发不仅仅是为了“偷懒”，它是一种对软件工程效率的极致追求。通过 Go 的简洁架构与 AI Agent 的强大能力结合，我们正在见证一种新的软件生产方式的诞生：人负责定义与决策，AI 负责实现与细节。

未来已来，希望这套实践能给大家带来一些启发。

为什么 flutter 的字体在 iOS 系统上更「细」？

七猫技术 — Mon, 26 Jan 2026 02:10:02 GMT

供稿来自：@张文森

现象

一切要从 UI 设计的一个反馈说起：

当前 flutter 开发的社区页面，在 iOS 文字显示的特别细（书城页面也有相同的问题），相比原生渲染还原度不够，需要看一下。

对比原生 iOS 的其他页面，字体的字重看起来确实不一样，也确实如设计反馈一样，flutter 页面的字体比原生页面要「细」一些，以社区帖子为例：

查找原因

开始简单的以为是 flutter 代码的问题，和 UI 同学调试半天后，都没实现原生的效果。

由此确定应该不是项目本身代码的原因，伟大的福尔摩斯曾经说过，「排除一切不可能的，剩下的即使再不可能，那也是真相」。所以开始怀疑是 flutter sdk 的问题，看了一下官方的 issue，发现也有类似的反馈。不幸的是，官方好像曲解了这个issue的原意，所以以「重复问题」的理由给关掉了，所以为何会有如此现象，我们就不得而知了。

iOS 系统上的字体

靠人靠天靠祖上，不算是好汉，为了找到问题的根因，我决定自己深入研究一下。众所周知，iOS 系统有一个非常有名的中文字体「苹方」，这个字体有多么有名呢？这么说吧，七猫的 UI设计师给鸿蒙App 的设计稿，中文字体用的也是苹方😂。
在iOS系统上，西文字体使用「SF Pro」，中文字体就使用「苹方」。

结合免费小说 App 中 flutter 页面和原生页面中的文字「2」的渲染，我们能够明显看出来，flutter中的「2」使用苹方字体渲染，而原生页面中的「2」使用的却是 SF Pro。

flutter 3.x版本的bug

产生这个差异的原因，是因为 flutter 3.x 版本的一个bug：在 fluter 中，文字部分的字重定义了 9 个枚举值，分别是FontWeight.w100、FontWeight.w200、FontWeight.w300...FontWeight.w900，我们分别使用这九种字重渲染“七猫 abcdx y z 9876543 2 1”，结果如下：

从图中我们不难看出，中文的「七猫」相比较于西文的「abcd...3 2 1」部分，字重只体现出来了两种，而非预期的平滑渐变效果，即在 iOS 系统上，flutter 无法正常渲染多级字重。

这个bug产生的原因，其实和 flutter 关系也不大，究其根本，是Skia渲染引擎的锅，Skia的SkFontMgr_Mac::onMatchFamilyStyleCharacter函数在匹配中文字符（如PingFang SC）时，生成的CTFontDescriptor仅包含weight属性，未指定familyName。这导致macOS的CoreText框架无法正确关联字体家族，转而回退到系统默认字体，且忽略用户指定的权重（如w600），最终使用默认权重（w400）渲染。

为了解决该问题，我们在flutter代码中手动指定了字体的回退逻辑：fontFamilyFallback: const ['PingFang SC']来临时解决该问题，所以字重展示恢复了正常，但随之而来的，就是「某些 iOS 系统」上，西文字符的展示会和原生有些许不同，比如「2」展示成了苹方体的「2」。

iOS 系统上字体的差异性

同样的flutter代码，为什么某些「iOS系统」上，「2」会显示成苹方体的「2」，而某些却不会呢？这个就要从苹果偷偷摸摸的对苹方字体的调整说起。苹果在 iOS 18上，启用了一套新的苹方体设计，所以现有的 iOS 系统，包含了两种苹方，我称之为「苹方」 & 「新苹方」。区别有以下几点：

版权的所有者不同
新苹方的西文字符调整成了类 SF Pro 的设计

所以同样的flutter代码，在不同的iOS设备中，字体的回退表现也不一致。

此外，新苹方终于支持可变字体了，对比老的苹方（or SF Pro），我们能够明显看出对于字重支持的差异性：

不过嵌入到 iOS 系统中的新苹方，还是以不同字重的静态文件来支持不同字重中文的展示的。使用 Swift UI ，分别指定不同的字体显示同一段文本，我们来看看他们有何区别：

可以看到，字重和字体大小对比系统处理都有所不同，苹果对于 iOS 中苹方字体的支持，确实让人有些摸不着头脑。不过大概可以猜出，iOS 系统中，为了字体排版展示的效果，使用系统字体时，苹果一定对其有一些特殊的处理，这些处理导致了即使是原生页面展示同样的文本，指定PingFang和指定系统字体的显示效果截然不同以及 flutter 的字体比原生更「细」的现象。

苹果类似的设计细节处理其实不少，比如在输入框中，当你同时输入英文和中文时，iOS系统都会自动把中英文之间的间距拉开，不需要手动加空格。

所以，这也解释了为什么设计师都喜欢Apple，因为 Apple 尊重设计。

解决方案

与其说是解决方案，我更愿意称之为这篇文章的总结。由于iOS系统的黑盒机制，我们无法了解具体的文字排版逻辑，所以也就很难实现同样的效果。

等待后续的flutter版本：可能后面 flutter 从Skia 切换到 Impeller后，这个问题就自然解决了
也可能后面系统内置的苹方字体切换为动态字体后也就没问题了。我们能做的，确实不多。

参考

AI 利器：Claude Code

秦皓 — Mon, 29 Dec 2025 02:19:02 GMT

AI 利器系列关注于效率提升的内容分享，通过实际案例分析，展示如何运用这些方法和工具，在不同场景下提升个人或团队的工作效率与产出，包括但不限于：AI 编程实践、工作流程优化、高效工具推荐。

一、写在前面

为什么介绍 Claude Code（简称 CC）而不是另一个 IDE？因为正如名言“一种不会影响你对编程的思考方式的语言，不值得学习。”所说的那样，我想要介绍的是另一种工作范式，而不是更好的 IDE。CC 不只你的开发环境，更是你的操作系统，它提供了丰富多样的扩展能力，你可以用它来做任何事情，让你和你的团队定制出完美符合团队需求的高效工作环境，它是你的剑，请你尽情地挥舞它。

本文将总结梳理 CC 的核心概念和扩展能力，并以实例展示为主，帮助大家快速认识 CC 的强大。

二、生态介绍

CC 提供的扩展能力丰富多彩，主要包括：MCP、Commands、Hooks、Sugents 和 Skills，同时其无头模式（Headless mode）可以让你像调用普通命令行那样使用 CC，更能无缝集成至你现有的工作流中。

三、分享回顾

本部分内容摘自《Claude Code 极速进化：从入门到精通的 AI 编程之旅》内部分享纪要，由飞书智能 AI 总结生成。

CC 基础操作

CC 高级扩展

CC 扩展对比

CC 扩展总结

四、实战案例

开发快捷指令（基于 Headless mode）

Commit 提交

alias cc-commit='claude -p "Write a commit for my changes using commitzen style, in Chinese" --allowedTools "Bash,Read" --permission-mode acceptEdits'

我们通过 alias 方式把 AI 智能提交封装为 cc-commit 指令，然后基于 cc-commit 进行快速 git 提交：

Commits 编排

alias cc-compose='claude -p "Stage my changes and write a set of commits for them using commitzen style, in Chinese" --allowedTools "Bash,Read" --permission-mode acceptEdits'

我们通过 alias 方式把 AI 智能提交封装为 cc-compose 指令，然后基于 cc-compose 进行快速 git 提交编排（将当前变更内容智能分成多次小的提交）：

开发快捷指令（基于 Commands）

安装七猫开发插件市场：（内部工具流程）

/plugin marketplace add https://codeup.aliyun.com/qimao/public/cc/plugins.git

之后再安装 devops 插件和 merge-request 插件：

我们可以样 Linus 来帮 Code Review（快捷指令：/devopos:linus-reviewer）

云效 MR 创建 Skill

我们可以通过七猫 merge-reqeust 插件智能创建一个云效合并请求（需要提前配置 YUNXIAO_TOKEN 环境变量并配置相关权限：

 /merge-request:start to develop branch

可以看到成功创建了 MR：https://codeup.aliyun.com/qimao/public/sdk/message/change/55

Push 业务任务开发 Skill

目前 Push 一直有新的业务 Push 任务开发需求，架构大致如下：

每次都是基于以下流程进行开发：

根据业务定义大数据计算任务产出的业务字段；
新编写一个业务推送任务，根据具体业务进行数据查询和 push 消息封装。

其中涉及到大量的手动复制黏贴的操作，可以抽象成 SOP 流程，于是我写了一个 Skill 来进行模板代码的生成，核心文档 SKILL.md 如下：（过长，仅截图展现）

并提供快捷指令：

---
name: New Business Task
description: 新增一个业务推送任务（极简模式，仅需 task_id 和业务名称）
argument-hint: [task_id] [业务名称]
category: business
tags: [business]
---

使用 business-push-task-creator skill 创建一个新的业务推送任务，task_id=$1，业务名称=$2

我们用这个 Skill 来创建一个 task_id=01-001-DATE-abcdef，业务名称=iOSLiveActivity 的业务推送任务：

可以看到 CC 使用 business-push-task-creator 技能完成了业务任务的框架搭建，我们可以基于代码根据业务要求进行调整。

这个 Skill 目前只做到了模板代码创建和列出后续代办项，后续会对这个 Skill 进行优化，提供更多业务信息，让 CC 直接一步到位完成整个业务开发，减少人工介入（不过最近实在太忙了，没时间进一步优化 😂）。

CI/CD 集成

使用 CC 的无头模式，我们可以将 CC 集成到 Flow 流水线中，实现分析或报告的自动化。本例中主要介绍最简单的实现架构，大家可以基于自己的实际场景进行封装操作。

架构流程

流水线配置

触发调用

我们可以简单的在终端执行命令，使用流水线的 Webhook 运行流水线。

本演示流水线非常简单，但其中蕴含的可能性是非常值得大家去挖掘的，通过简单的配置，我们就可以将日常很多流程完全自动化并集成到现有系统中。

基于飞书 Aily 搭建 sls日志分析助手

朱训 — Wed, 10 Dec 2025 02:35:34 GMT

一、背景与目标

日志分析是排查问题、优化业务的关键环节，但传统日志处理流程繁琐、效率低下，难以快速为决策提供支持。

【sls日志分析助手】是一款基于飞书 aily辅助分析日志提供处理建议的解决方案，通过获取日志数据，AI 参与其中，帮助决策者快速预览、排查，提供决策建议支持，提升业务效率。同时穿插介绍aily这一有力工具，让人人都能在飞书内快速上手搭建自己需要的ai应用（傻瓜式上手）。

二、飞书Aily相关介绍

基础介绍，可直接跳过

1. 平台简介

飞书 aily 是围绕大语言模型构建的企业级智能体开发平台，具备 AI 技能编排、知识数据处理、效果调优与持续运营能力，能助力企业高效打造专业智能应用。

2. 核心优势

飞书 aily 拥有五大核心优势，可为办公、业务等场景提供全面智能化支持，提升企业工作效率：

深度检索能力：支持互联网资源与企业知识空间的深度检索。
任务深度规划：可预设执行步骤，引导模型有序推进任务流程。
丰富工具生态：支持集成和使用多种类型工具，既有官方 MCP 工具，也允许企业接入自定义工具和知识空间。
多轮对话理解：识别历史上下文与用户输入，支持文档与图片。
可视化报告生成：可自动生成含图表与可视化内容的专业调研报告。

3. 应用类型

三、SLS分析工具概述

跟着一步步，鼠标点击即可

1、前期准备

工具部署：阿里云 SLS 日志分析 MCP 已提前部署，需通过 PIP 命令安装。（安装教程参考：阿里云sls日志分析mcp ）
网关接入：该 MCP 已注册至公司自建 MCP 网关（基于：mcp-context-forge），可支持通过 Cursor 等工具直接调用。
IP 白名单配置：若公司自建 MCP 服务有访问限制，需参考飞书 Aily 帮助文档，添加飞书 IP 至白名单，避免访问失败。

2、搭建方案 1：基于 “自定义智能体” 搭建 SLS 分析工具

触发流程：

具体搭建：

效果演示：Demo 近一天error日志信息报告

3、搭建方案 2：基于 “工作流应用” 搭建 SLS 分析工具

触发流程：

具体搭建：

效果演示：Demo 近一天error日志信息报告

四、后续改进

为进一步拓展 SLS 日志分析助手的能力，计划从以下方向推进优化：

与 OnCall 告警系统联动：与基础平台OnCall告警等系统结合，实现 “告警自动触发分析”。
与 Codeup 代码仓库对接：支持 “分析结果触发代码操作”，自动创建需要的代码分支并提交MR。
......

五、拓展应用：更多场景探索

在搭建 SLS 分析工具的过程中，发现飞书 Aily “工作流应用”也可覆盖更多办公场景，以 “日常问题反馈群消息自动汇总分析” 为例，分享具体实践：

“业务问题反馈群” 每日接收大量问题消息，人工汇总需耗时 1-2 小时，且易遗漏关键信息，需通过自动化工具实现 “消息收集→AI 总结→数据统计→结果推送” 全流程。可通过aily搭建一个工作流用以统计并总结分析日常问题反馈群里的问题。（想象ing~~~☀️）

发现并使用飞书 “工作配方” 快速搭建

两步配置，开箱即用，不要重复造轮子~~~ 【狗头】

效果很不错👍🏻👍🏻👍🏻

当然例如其他模板：识别待办任务消息推送到群，消息包含关键词时,提醒我，AI总结会议进展、风险和待办等也不错，快快使用起来。效率飙升，提早下班～

当然飞书aily还可以有其他方向的探索例如grafana监控分析以及pyroscope火焰图分析等等，快去尝试吧~~~

AI 编程演进综述 v202510

七猫技术 — Fri, 28 Nov 2025 02:00:00 GMT

供稿来自：@秦皓

自 2 月以来，研发中心开始推进 AI 进研发提效工作，至此我们进行了 AI 编程最佳实践、工程化探索、提效实践分享以及 AI 提效活动评比等系列活动。现在时间来到 10 月，让我们一起回顾一下过去大半年 AI 编程的演进，帮助大家把握 AI 提效的方向和未来。

随着大模型能力的持续突破，AI 编程正经历从「代码补全」「氛围编程」到「Spec 驱动开发」的范式革命。软件开发的重心正从「如何编写代码」转向「如何定义问题和验证解决方案」。本文围绕技术基础、编程范式、知识工程、工具形态四个维度，简要回顾 AI 编程的演进历程，探讨其未来发展方向。

一、技术基础：大模型能力持续提升

大模型能力的快速迭代，构成了 AI 编程「从辅助到主导」跃迁的核心驱动力。近年来，我们见证了从性能优先到性能、成本、代理能力全方位竞争的转变。

国内编码大模型推荐（处理编码任务已经足够日常使用）：

二、编程范式：从辅助到自主的演进

2.1 范式演进概览

我们可以将 AI 编程范式粗略的分为三个阶段：辅助阶段、协作阶段和自主阶段。

这条演进路径展示了从微观到宏观、从被动到主动的清晰转变。

2.2 不同范式对比

Spec Driven Development（SDD，规范驱动开发，参见：AI 利器（九）：Spec 驱动开发）是一种基于精确规格说明的 AI 软件工程流程，是目前 AI 编程演进的最新范式。开发者通过编写结构化规范（包括功能需求、接口定义、验收标准等），指导 AI 自主完成从规划到实现的全过程开发。

目前主流的 AI IDE 都逐渐开始支持 SDD，如 Qoder 的（Quest Mode/委派模式，从产品设计层面原生支持 SDD）、Cursor 的 Plan Mode 等。同时，社区提供了如 spec-kit 和 OpenSpec 这样的工具，支持在不同 AI 编程工具中管理 SDD 流程。

2.3 角色进化之旅

这条演进路径，本质上是开发者将控制权逐步下放，并将自身角色向更高层次提升的过程。我们正集体从「如何写」的泥潭中走出，经过「写什么」的探索，最终迈向「为什么而写」的广阔天地。未来，编写精确规范的能力，或许将成为程序员最核心的竞争力。

三、知识工程：AI 编程的隐式基石

知识工程是对代码中业务逻辑、团队规范和领域知识的系统化处理，是 AI 编程从「玩具」走向「工具」的关键瓶颈。我们可以在 AI 变成范式的演进中看到知识工程的演进：

知识工程的核心价值：为 AI 这位「正规员工」编写详尽的文档，比如：

《岗位工作手册》（业务知识）
《公司管理条例》（仓库规范，如 Rules 等）
《项目综述》（代码仓库总结，如 AGENT.md、CLAUDE.md）
《操作手册》（开发流程，如 SKILL.md、Command 等）
《技术文档》（Sepc 文档等）

未来团队的核心竞争力，将取决于构建、维护和利用「AI 可读写知识体系」的能力。做好知识工程管理是 AI 编程时代提升效率和代码质量的关键。

四、工具形态：IDE 与 CLI 对比

随着 AI 编程范式的演进，工具形态也呈现出明显的分化并融合的趋势。在技术基础提升和范式转变的推动下，AI 编程工具从单一形态发展为多元化的生态系统，形成了 AI IDE 和 AI CLI 两大阵营。

4.1 AI 编程工具演进

4.4 维度对比

4.5 趋势总结

边界趋同：IDE 内置终端 Agent 模式，CLI 以插件方式可以结成到 IDE
协议统一：MCP 成为「AI 插件界的 USB-C」，跨平台兼容
双轨选型：桌面用 AI 原生 IDE，CI/CD 用 CLI
未来展望：本地模型压缩使 CLI 具备离线 Agent 能力，IDE 向多模态低代码演进

选型建议

🎯 写得爽、重构快 → AI 原生 IDE（Cursor/Kiro/Qoder）
🚀 跑得远、自动化 → AI CLI（Gemini CLI/Claude Code）
🔧 已绑定 VS Code/JetBrains 生态 → AI Coding 插件 + MCP

五、总结、展望及建议

从前面的回顾和分析可以看出，AI 编程的发展是一场多层次、全方位的技术革命。它不仅改变了我们编写代码的方式，更重塑了整个软件工程生态系统。

5.1 变化总结

AI 编程将重塑软件工程，具体体现在：

技术提升：大模型的能力的提升，带来了 AI 编程生态的繁荣
工具融合：IDE 和 CLI 工具分化并逐渐融合，不同产品形态融合进化通用范式（如 SDD）
开发流程：开发者通过编写结构化规范，指导 AI 自主、异步完成从规划到实现的全过程开发
技能转型：开发者核心技能转向定义规范、代理治理和对 AI 产出评估
风险管控：随着代理自主性增强，面临三大风险：级联错误、依赖爆炸、对齐失败。解决方案：加强完善监督评估机制，构建实时安全反馈系统

5.2 未来展望

AI 编程的发展将持续深化，我们可以预见：

生态成熟：IDE 和 CLI 的边界将进一步模糊，形成统一的开发体验
标准建立：MCP 等协议逐渐成熟，SDD 等新范式将逐步标准化，形成 AI 编程最佳实践指南
协作模式：AI 成为「准团队成员」，需要新的责任归属和协作模式
成功要素：完善 CI/CD 流程，构建稳健的人机协同生态系统和实时反馈系统，完善评估机制

5.3 行动建议

面对 AI 编程的时代浪潮，我们需要：

个人层面：主动学习和实践 AI 编程工具，提升系统架构思维和问题定义能力
团队层面：建立知识工程体系，完善 AI 编程规范、流程和评估体系，平衡效率提升与风险管控

六、延伸阅读

通过 AI Agent 自动排查 K8s 问题

郭子龙 — Tue, 18 Nov 2025 03:33:19 GMT

一、背景与痛点

现状痛点（Dev & Ops）：

研发：排查 K8s 问题需要熟悉 kubectl/日志命令，遇到 CrashLoopBackOff、FailedMount、镜像拉取失败等底层问题，需要在开发工作之外投入额外精力，影响主线任务推进。
运维：登录多层环境（堡垒机/跳板机/多集群），拉日志、看事件、比节点状态，信息分散难沉淀，同样的问题反复回答。

典型场景：

日常上线后，个别 Pod 启动异常；研发需要登录跳板机、切换集群、查事件、拉日志，流程繁琐且信息分散。
测试/预发环境调试报错（依赖未就绪、配置不一致等）；需要快速判断是应用配置、镜像、节点资源还是网络/存储侧，手工排查路径长且易遗漏。

效果与收益：

用 Agent + 群聊协作，把繁琐的多步骤操作简化为一个按钮，让分散的日志/事件/状态信息聚合成结构化诊断结论，排查过程自动留痕便于复用。
效率提升：平均排查时间从 10 分钟降至 1 分钟内。
降低门槛：无需记忆 kubectl 命令，一键触发即可完成大部分排查。
信息聚合：日志、事件、指标在一次对话中集中呈现，不再多处切换。
知识沉淀：排查过程自动留痕，方便团队回溯和经验传承。

二、使用方式

Agent 自动完成排查，也可以再通过继续对话交互深入分析。

技术指导（如 K8s 最佳实践咨询）和需求支持（如资源配额调整建议）。

使用示例：

1. @机器人排查告警信息。自动回复结构化诊断结论、建议和关键日志片段

2. @机器人，提出任何k8s相关需求，如资源优化。

3. @机器人排查容器异常退出。

三、实现方式

技术流程：

能力覆盖：

场景支持：Pod 异常、Node 状态、Service 网络、镜像拉取、调度失败等常见问题
信息聚合：容器日志、K8s 事件、资源状态、配置信息、调度详情、网络连通性等关键排查数据一次性呈现

核心能力kubectl-ai：

google-cloud 开源的 kubectl-ai 实现的 kubectl MCP。项目地址：https://github.com/GoogleCloudPlatform/kubectl-ai。项目也提供agent能力，这里只用到了MCP，因为飞书和aily agent交互实现比较简单。
Kubectl-ai DockerFile：

FROM xxx-registry.cn-shanghai.cr.aliyuncs.com/public-test/alpine:3.21

# 下载 kubectl 和 kubectl-ai
# RUN wget https://dl.k8s.io/release/v1.33.0/bin/linux/amd64/kubectl -O /bin/kubectl && chmod +x /bin/kubectl && \
#     wget https://github.com/GoogleCloudPlatform/kubectl-ai/releases/download/v0.0.26/kubectl-ai_Linux_x86_64.tar.gz && tar -xzf kubectl-ai_Linux_x86_64.tar.gz -C /bin/ && rm kubectl-ai_Linux_x86_64.tar.gz

# 复制本地文件（如果存在）
COPY ./deploy/kubectl-ai /bin/kubectl-ai
COPY ./deploy/kubectl /bin/kubectl

# 设置权限并安装依赖
RUN chmod +x /bin/kubectl-ai && \
    chmod +x /bin/kubectl && \
    apk add bash &&  rm -rf /var/cache/apk/*

ENTRYPOINT [ "/bin/kubectl-ai" ]

Kubectl-ai MCP启动方式：

apiVersion: apps/v1
kind: Deployment
metadata:
  name: kubectl-ai
  namespace: kubectl-ai
  labels:
    app: kubectl-ai
spec:
  replicas: 1
  selector:
    matchLabels:
      app: kubectl-ai
  template:
    metadata:
      labels:
        app: kubectl-ai
    spec:
      serviceAccountName: kubectl-ai
      containers:
      - name: kubectl-ai
        image: xxx.cn-shanghai.cr.aliyuncs.com/public-test/devops:kubectl-ai-latest
        imagePullPolicy: Always
        args:
        - --llm-provider=openai
        - --model=qwen3-coder-plus
        - --skip-permissions=true
        - --max-iterations=20
        - --v=4
        - --alsologtostderr
        - --mcp-server
        - --mcp-server-mode=streamable-http
        - --http-port=9080
        envFrom:
        - secretRef:
            name: kubectl-ai
        resources:
          requests:
            cpu: 100m
            memory: 128Mi
          limits:
            cpu: 1000m
            memory: 512Mi
        livenessProbe:
          tcpSocket:
            port: 9080
          initialDelaySeconds: 30
          periodSeconds: 10
          timeoutSeconds: 5
        readinessProbe:
          tcpSocket:
            port: 9080
          initialDelaySeconds: 5
          periodSeconds: 5
          timeoutSeconds: 3

Kubectl-ai 鉴权：使用k8s RBAC,屏蔽secret权限，防止集群密钥泄露：

---
# ServiceAccount for kubectl-ai deployment
apiVersion: v1
kind: ServiceAccount
metadata:
  name: kubectl-ai
  namespace: kubectl-ai
  labels:
    app: kubectl-ai
---
# ClusterRoleBinding to grant the ServiceAccount cluster-wide read-only access
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRoleBinding
metadata:
  name: kubectl-ai-readonly-binding
  labels:
    app: kubectl-ai
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: ClusterRole
  name: kubectl-ai-readonly
subjects:
  - kind: ServiceAccount
    name: kubectl-ai
    namespace: kubectl-ai
---
# ClusterRole with all read-only permissions
apiVersion: rbac.authorization.k8s.io/v1
kind: ClusterRole
metadata:
  name: kubectl-ai-readonly
  labels:
    app: kubectl-ai
rules:
  # Core API resources - 基于内置 view ClusterRole
  // ... 略

飞书交互：

飞书 aily workflow配置入口：

Agent配置：

提示词配置，根据使用情况持续优化提示词，比如查询 log 时限制行数防止上下文超限。
模型：使用DeepSeek-V3.1
工具配置：添加kubectl-ai MCP。

四、后续改进

统一运维 Agent 入口，屏蔽底层差异：以 K8s 排查为起点，逐步整合更多运维能力：日志查询与分析（SLS）、指标监控与告警（Prometheus/Grafana）、服务拓扑与依赖关系（链路追踪）、资源变更历史与回滚建议、DBA 能力（慢查询分析、锁等待排查、索引优化建议等）、打造"一站式"运维助手，统一入口解决跨域问题。
知识库积累：沉淀 Agent 自动问答模板，例如 “Pod Crash 原因排查步骤”。
与监控联动：告警自动触发 Agent 自查，生成问题报告。比如结合基础平台 OnCall 告警系统，自动 @排查机器人。Agent 自动生成工单或建议修复命令。
持续优化模型能力：结合内部日志样本，微调分析准确率。

五、结语

通过 kubectl-ai + 飞书 aily workflow，我们把多步骤命令行操作简化为一个按钮，让运维经验沉淀为可复用的自动化能力。

Agent 能解决日常大部分琐碎问题，显著提高排查效率，但个别疑难杂症仍需人工介入 —— 它是第一道防线和效率工具，而非完全替代。

期待与基础平台团队深化合作，将 Agent 能力与 OnCall 告警系统等深度集成，共同构建更智能的研发协作体验。

AIOps 通用 Agent 探索（Simple）

七猫技术 — Mon, 03 Nov 2025 02:39:17 GMT

供稿来自：@秦皓

背景说明

目前我们使用 Cursor 时，除了编码外在诸如需求分析、技术文档编写、代码评审、代码部署调试、线上日志分析等场景下也会借助它进行工作提效。同时在通过与开发、测试和运维团队的交流讨论之后，我们整理出了基于 AI 的研发全流程，如下图所示：

可以看到 AI 贯穿于我们的研发整个流程，但在绝大部分场景下，会因为 Cursor 局限在单机设备上，无法方便地与我们现有的系统进行集成。为每个场景开发独立的 Agent 非常耗费人力，DevOps 流程本身并不像业务流程要求特别精细（特别是偏向分析、问题排查或总结报告等场景），基于对大模型智能会持续提升的信念，通过践行 Manus 提倡的更少结构，更多智能（Less structure, more intelligence ）的理念，我们进行了开发一个 AIOps 通用 Agent 的探索。

预期目标

使用 ReAct 框架，参照（并简化）Manus 架构和 Cursor/Cline 开发一个 AIOps 通用 Agent，我们的目标是通过完善 Prompt + LLM（Agent）+ Tools + Workspace 的方式实现 DevOps 流程的落地。

✨✨ 实现让用户通过提示词定义具体流程，就能快速实现某个流程的 AI 自动化集成✨✨

下文我将先先对本文用到的主要相关理论进行简单阐述，然后介绍 AIOps 通用 Agent 的设计实现方案，AI MR 场景实践效果，最后对未来的形态进行展望。

AIOps 通用 Agent

仓库地址：https://codeup.aliyun.com/qimao/public/aiops/aiops。

架构设计

整体架构包括：

1. 管理平台（暂无）

用户基于场景对任务进行管理
对外提供 API，用于系统集成
定义周期性调用的 Job
任务运行的报告

2. AIOps 通用 Agent

封装了核心的 LLM（ReAct Engine）
提供 LLM 具体需要使用的工具
Agent 运行环境管理（基于 Docker）

3. 其他

使用 Langfuse 进行 LLM 调用监控
使用 Bashly 封装常用的依赖工具

核心流程

一次 Agent 运行的核心流程如下：

组件说明

我们从上面的架构和流程图中，抽象出以下几个组件：

本文后续将以代码 MR 报告总结为例进行展开，我们提供 Codeup 相关命令行依赖（codeup），通过使用系统提示词定义一个 MR 评审总结核心流程，来实现让 AI 进行代码评审报告的能力。

提示词（Prompt）

提示词（Prompt）是我们最终需要关注的部分，随着 LLM 大模型能力的提升，相信我们的主要工作将以编写提示词为主，以后整个 AIOps Agent 的核心部分就是提示词的编写（流程的制定）。

在合并请求（MR）场景中，我们通过提供（codeup 和其他常用个 shell 命令：git 、jq 等依赖），再编写以下系统提示词，实现一个 MR 报告生产 Agent：

使用 codeup 或 git 和 jq 等常用 bash 终端命令（我已经为你完成 codeup 命令的权限认证），请按照以下步骤审查进行 Codeup 合并请求（MR）审查。你需要在指定的代码仓库 /var/aiops/repos/${{repod_id}} 中处理相关 git 命令。


# Codeup MR 审查流程 - 详细步骤

## 1. 收集 MR 信息
1. 获取 MR 的明细
  ```bash
  codeup mr get ${{repo_id}} ${{local_id}}
  ```

## 2. 理解上下文
1. 获取 MR 的完整变更文件树：
  ```bash
  codeup mr tree ${{repo_id}} ${{local_id}}
  ```
2. 使用 codeup repo file 命令查看特定分支上的文件内容：
  ```bash
  codeup repo file ${{repo_id}} ${{file_path}} --ref ${{branch}} | jq -r '.content' | base64 -d
  ```

## 3. 分析变更
分析本次变更主要：
- 修改了什么（总结几个点）
- 对整体仓库的影响
- 潜在的缺陷或问题
- 概括审查结果

## 4. 追加代码评审描述
对整个代码变更进行代码评审描述的更新（**这个步骤一定要执行，描述中的内容要求保持换行**）：
  ```bash
  codeup mr update ${{repo_id}} ${{local_id}} --description '【原始的代码评审描述】
  \n
  【更新时间】
  【新的代码评审总结内容】'
  ```




# 用于 MR 审查的常用 Codeup CLI 命令，以及对应的返回格式

##  基本命令示例及返回格式

```bash
# 获取合并请求详情
$ codeup mr get 3394535 211
{
  "id": 211,
  "title": "fix: update Add function call to lowercase add",
  "description": "1 【更新时间】2025-06-10 11:02 代码审查完成：1. 发现2处潜在边界条件问题需补充测试 2. 存在3个魔法数字需要常量化 3. 所有反馈已通过行间评论标注",
  "state": "UNDER_REVIEW",
  "source_branch": "feat/cr",
  "target_branch": "master",
  "author": "秦皓",
  "created_at": "2025-05-13T09:21:16+08:00",
  "updated_at": "2025-06-10T11:02:52+08:00",
  "conflict_status": null,
  "reviewers": [
    {
      "name": "秦皓",
      "status": null,
      "reviewed": false,
      "review_time": null
    }
  ],
  "comment_count": 8,
  "unresolved_comment_count": 8,
  "url": "https://codeup.aliyun.com/qimao/public/devops/demo/change/211"
}


# 获取合并请求变更文件树
$ codeup mr tree 3394535 211
{
  "changedTreeItems": [
    {
      "aMode": "100644",
      "addLines": 13,
      "bMode": "100644",
      "delLines": 1,
      "deletedFile": false,
      "isBinary": false,
      "newFile": false,
      "newObjectId": "33eb73b5a624d113763f5d1ac5746d9e2da241db",
      "newPath": "README.md",
      "oldObjectId": "3ff86afe4fad6809ee9e1b7f5c3352712ff821e3",
      "oldPath": "README.md",
      "readStatus": "INIT",
      "renamedFile": false
    },
    {
      "aMode": "100644",
      "addLines": 0,
      "bMode": "0",
      "delLines": 9,
      "deletedFile": true,
      "isBinary": false,
      "newFile": false,
      "newObjectId": "0000000000000000000000000000000000000000",
      "newPath": "main.go",
      "oldObjectId": "90c6869506feed59a97b60ca92bb17db95bf09d2",
      "oldPath": "main.go",
      "readStatus": "INIT",
      "renamedFile": false
    }
  ],
  "count": 2,
  "totalAddLines": 47,
  "totalDelLines": 22
}

# 获取合并请求补丁集列表
$ codeup mr patches 3394535 211
[
  {
    "version_no": 1,
    "patch_set_name": "版本1",
    "patch_set_id": "0a7c40a77e1e42fe8a4659340c48a2b9",
    "commit_id": "747053544a3f08cce4de0c8fdc976f8f1ca90d76",
    "short_commit_id": "74705354",
    "create_time": "源分支"
  },
  {
    "version_no": 1,
    "patch_set_name": "Base",
    "patch_set_id": "7a4c707968a0483fa7df52ab7a2500c2",
    "commit_id": "07ab2d3dc2c2800b5e76656c02edc1bd44f67221",
    "short_commit_id": "07ab2d3d",
    "create_time": "目标分支"
  }
]
```

## 差异和文件命令

```bash
# 查看 master 分支上的文件内容：
$ codeup repo file 3394535 main.go --ref master 
{
  "blobId": "90c6869506feed59a97b60ca92bb17db95bf09d2",
  "commitId": "07ab2d3dc2c2800b5e76656c02edc1bd44f67221",
  "content": "cGFja2FnZSBtYWluCgppbXBvcnQgKAoJImNvZGV1cC5hbGl5dW4uY29tL3FpbWFvL3B1YmxpYy9kZW1vL2FwcCIKKQoKZnVuYyBtYWluKCkgewoJYXBwLlJ1bigpCn0K",
  "encoding": "base64",
  "fileName": "main.go",
  "filePath": "main.go",
  "lastCommitId": "02989c2393215ea6b8bf68af09439b85e0ef2d69",
  "ref": "master",
  "size": "96"
}

# 读取文件具体内容
$ codeup repo file 3394535 main.go --ref master | jq -r '.content' | base64 -d
package main

import (
        "codeup.aliyun.com/qimao/public/demo/app"
)

func main() {
        app.Run()
}
```

## 审查命令（创建合并请求评论）

```bash
#  更新合并请求描述（**保持换行**）
codeup mr update 3394535 211 --description '原始评论

${{date_time}}【评审更新】
## 代码评审总结 

### 主要变更 

1. **代码结构重构**：将计算功能从 app 包分离到独立的 calc 包，提升代码模块化程度 
2. **文件重组**：app/app.go → app/calc/calc.go, app/app_test.go → app/calc/calc_test.go, 删除根目录 main.go，新增 app/main.go 
3. **函数规范化**：私有函数 divide/multiply 修改为导出函数 Divide/Multiply 
4. **功能增强**：新增命令行计算器功能，支持四则运算演示 

### 对项目的影响 
- **正面影响**：改善了代码组织结构，计算逻辑与应用逻辑分离，便于维护和测试 
- **兼容性**：删除了原有的 Run() 函数，但通过新的 main.go 提供了更实用的命令行界面 

### 发现的问题 
🚨 **严重问题**：app/main.go 第22行存在函数调用错误 
- 当前代码：calc.add(a, b) 
- 应修正为：calc.Add(a, b) 
- 影响：程序无法正常编译运行 

### 建议 
1. **必须修复**：修正 app/main.go 中的函数调用错误 
2. **代码质量**：添加错误处理逻辑，当前 strconv.Atoi 的错误被忽略 
3. **测试覆盖**：建议为新增的 main.go 添加集成测试 

### 审查结果 
- ✅ 代码架构设计合理 
- ✅ 测试用例完整迁移 
- ❌ 存在编译错误需修复 
- ⚠️ 缺少错误处理机制
'

# 创建全局评论：
codeup mr comment add 3394535 211 "代码看起来不错"

# 对于严重缺陷创建行内评论：
codeup mr comment add 3394535 211 "这里需要修改" \
  --type INLINE_COMMENT \
  --file /src/main.go \
  --line 42 \
  --from-patch abc \
  --to-patch def \
  --patch abc
```




最终输出格式保持如下：

```markdown
# 评审总结（${{repo_id}}-${{local_id}}
${{date_time}}【评审总结】,MR 地址：${{url}}。

## 评估结论
✅ 建议合并|🧰 修复问题后合并|❌ 不建议合并

## 📋 评审流程总结

1. **✅ 收集 MR 信息**
  - MR 标题：``
  - 状态：``
  - 分支：``

2. **✅ 理解变更上下文**
  - 共涉及 5 个文件变更（47行新增，22行删除）
  - 主要是代码结构重构和模块分离

3. **✅ 分析变更内容**
  - **代码结构重构**：将计算功能分离到独立的 calc 包
  - **文件重组**：重命名和移动多个文件
  - **功能增强**：新增命令行计算器功能

4. **✅ 发现关键问题**
  - 🚨 **严重问题**：`app/main.go` 第22行函数调用错误
  - 当前：`calc.add(a, b)` 
  - 应为：`calc.Add(a, b)`

## 🎯 关键建议：
1. **必须修复**：函数调用错误，否则程序无法编译
2. **代码质量**：添加错误处理逻辑
3. **测试覆盖**：为新功能添加集成测试

✨
```




- 忽略以 "md,mdc,yaml,json" 等后缀结尾的文档




核心参数: 
- repo_id: 仓库 ID
- local_id: 合并请求 ID

其他参数：
- file_path: 具体需要查看的文件
- branch: 具体需要查看文件的分支
- date_time: 当前时间，格式："2025/06/06 13:10:11"，使用 date 命令获取
- url: 在 codeup mr get 中的返回值中

LLM（ReAct Engine）

我们基于字节开源的 Eino 框架实现通用的 ReAct Agent 引擎，之后便可基于它加上：

系统提示词
工具列表
执行环境

迅速运行一个 Agent 实例。React Engine 核心代码（仅 100 行余行）：

package engine

import (
        "context"
        _ "embed"
        "errors"
        "fmt"
        "io"
        "strings"

        "aiops/internal/engine/tools"

        "github.com/cloudwego/eino-ext/callbacks/langfuse"
        "github.com/cloudwego/eino-ext/components/model/qwen"
        "github.com/cloudwego/eino/callbacks"
        "github.com/cloudwego/eino/components/tool"
        "github.com/cloudwego/eino/compose"
        "github.com/cloudwego/eino/flow/agent/react"
        "github.com/cloudwego/eino/schema"
)

type Engine struct {
        model *qwen.ChatModel // LLM 大模型
        tools []tool.BaseTool // 工具

        systemPrompt string // 系统提示词

        lfCfg *langfuse.Config // Langfuse 观测 LLM 调用链路
}

func NewEngine(systemPrompt string, chatModel *qwen.ChatModel, lfCfg *langfuse.Config, _ []tool.BaseTool) (*Engine, error) {
        return &Engine{
                model:        chatModel,
                tools:        tools.GetAllTools(),
                lfCfg:        lfCfg,
                systemPrompt: systemPrompt,
        }, nil
}

func (a *Engine) Run(userPrompt string) (result string, err error) {
        cbh, flusher := langfuse.NewLangfuseHandler(a.lfCfg)
        defer flusher() // 等待所有 trace 上报完成后退出

        callbacks.AppendGlobalHandlers(cbh) // 设置 langfuse 为全局 callback

        // 生产 Agent 实例
        ctx := context.Background()
        ragent, err := react.NewAgent(ctx, &react.AgentConfig{
                ToolCallingModel: a.model,
                ToolsConfig: compose.ToolsNodeConfig{
                        Tools: a.tools,
                },
                MaxStep: 40,
        })
        if err != nil {
                return "", fmt.Errorf("failed to create agent: %w", err)
        }

        // 流式调用
        sr, err := ragent.Stream(ctx, []*schema.Message{
                {
                        Role:    schema.System,
                        Content: a.systemPrompt, // 系统提示词
                },
                {
                        Role:    schema.User,
                        Content: userPrompt, // 用户提示词
                },
        })

        if err != nil {
                return "", fmt.Errorf("failed to stream: %w", err)
        }

        defer sr.Close() // remember to close the stream

        // 获取最终返回结果
        var buf = strings.Builder{}
        for {
                msg, err := sr.Recv()
                if err != nil {
                        if errors.Is(err, io.EOF) {
                                // finish
                                break
                        }
                        // error
                        return "", fmt.Errorf("failed to recv: %w", err)
                }

                buf.WriteString(msg.Content)
        }

        // 返回结果
        return buf.String(), nil
}

ReAct Agent 实现细节可参考文档：Eino: ReAct Agent 使用手册。

工具（Tools）

Tool 提供了 LLM 执行具体任务的能力，在生成 MR 报告场景中，我们在提示词提供了多个 shell 命令，所以我们仅提供一个 bash_command 的命令，用于执行 shell 命令即可:

// ToolBash Bash 命令执行工具
type ToolBash struct{}

// Info 返回工具信息
func (t *ToolBash) Info(ctx context.Context) (*schema.ToolInfo, error) {
        return &schema.ToolInfo{
                Name: "bash_command",
                Desc: "执行 Bash 命令行指令，支持执行各种 shell 命令、脚本和系统操作",
                ParamsOneOf: schema.NewParamsOneOfByParams(map[string]*schema.ParameterInfo{
                        "command": {
                                Type:     "string",
                                Desc:     "要执行的 bash 命令，支持管道、重定向等 shell 特性",
                                Required: true,
                        },
                        "working_dir": {
                                Type:     "string",
                                Desc:     "命令执行的工作目录，可选，默认为当前目录",
                                Required: false,
                        },
                        "timeout_seconds": {
                                Type:     "number",
                                Desc:     "命令执行超时时间（秒），可选，默认为 30 秒",
                                Required: false,
                        },
                        "environment": {
                                Type:     "object",
                                Desc:     "附加的环境变量，格式为 key-value 对象，可选",
                                Required: false,
                        },
                }),
        }, nil
}

此处的工具指的是 ReAct 框架需要的需要的工具。在运行 Docker 时，我们还会提到提示词中使用的如 codeup、git、jq 等命令行工具，这些工具我们称之为运行时依赖。

执行环境（Workspace）

执行环境（Workspace）是 Agent 实际运行的环境，我们使用独立 Docker 容器了隔离 Agent 运行，以保障执行环境的可靠性。在运行 Docker 时，将用户定义的运行时依赖（如 codeup、git、jq 等命令行工具）、Codebase 或者文件数据（通过磁盘卷挂载的方式）安装到容器中。

核心代码：

        // 创建沙箱实例
        sandbox, err := sandbox.NewDockerSandbox(context.Background(), &sandbox.Config{
                VolumeBindings: a.volumes,             // 挂载 codebase 等数据卷
                Env:            a.envs,                // 环境变量
                Image:          "aiops-sandbox:latest", // 镜像，包含完整运行时依赖
                WorkDir:        "/workspace",           // 定义 workspace 
                MemoryLimit:    512 * 1024 * 1024,
                CPULimit:       1.0,
                NetworkEnabled: true,
                Timeout:        30 * time.Minute,
        })
        if err != nil {
                log.Printf("创建沙箱失败：%v\n", err)
                return nil, fmt.Errorf("创建沙箱失败: %w", err)
        }

        // 创建容器
        err = sandbox.Create(context.Background())
        if err != nil {
                log.Printf("创建沙箱失败：%v\n", err)
                return nil, fmt.Errorf("创建沙箱失败: %w", err)
        }
        defer sandbox.Cleanup(context.Background())

Agent 定义

暂时未开发 Web UI 管理界面，我们可以通过等价的 YAML 格式了解一个 Agent 定义可以有多简单：

// 默认的通用 Agent
- id: "default"
  name: "默认通用 Agent"
  system_prompt: "你是一个无所不知的助手，请根据用户的问题给出回答，涉及时间的问题，应该用命令行工具获取当前最新时间，如果无法访问互联网，使用你已有的知识给出回答，并最终将答案输出给用户。"
  report_path: "aiops/reports/default"

// 合并请求 Agent
- id: "code_review" 
  name: "Code Review"
  async: true
  system_prompt_doc: "task_cr.md"
  system_prompt: ""
  user_prompt: ""
  user_prompt_template: "请为我给 repo_id=${{repo_id}}, local_id=${{local_id}} 的合并请求进行代码评审"
  user_prompt_params:
    - param: "repo_id"
      value: ${{repo_id}}
    - param: "local_id"
      value: ${{local_id}}
    - param: "repo_url"
      value: ${{repo_url}}
  tools:
    - "codebase"
  envs:
    "API_KEY": "pt-xxxx"
  volumes:
    "/var/aiops/repos/${{repo_id}}": "/workspace/src"
  pre_shell: ""
  post_shell: "codeup mr comment add ${{repo_id}} ${{local_id}} 'AI 代码评审报告: ${{report_url}}'"
  report_path: "aiops/mr/reports/${{repo_id}}/${{local_id}}/"

场景效果（MR 报告）

我们通过代码合并请求（MR）总结报告为例，使用相同的提示词，AIOps 通用 Agent 得出的报告与 Cursor 得出的报告质量几乎一致。

核心价值

通过对生成合并请求（MR）报告场景的实践，我们认为 AIOps 通用 Agent 是一个值得持续探索的方向，让我们能在尽可能减少人力投入的同时，让我们方便快捷地在现有流程中集成 AI 的能力。主要表现在：

简单高效：通过使用 Markdown 提示词定义业务流程的方式，即可快速实现某个特定 DevOps 场景下的分析报告、问题排查甚至自动修复等 AI Agent 能力。
隐私安全：通过自研开发的方式，我们可以完全控制代码或数据不会被泄露。
易于集成：通过暴露标准 Open API 的方式，可以快速在第三方系统中进行集成调用，无缝接入到现有的各个系统中。
异步处理：通过暴露 API 接口共第三方系统集成，或者设置定时运行 Job，能够实现异步、周期行处理工作，减少人工操作，实现自动化。
集中管理：通过脱离 Cursor IDE 环境（云端化）并进行集中管理设置的方式，提高了团队工作成果的可复用性，一人开发，全员受益。
贴合自身：通过自研开发的方式，我们可以基于我们七猫自身团队的流程特性进行定制设计，效率更高，品质更有保障。

未来展望

搭建管理平台，实现 Web UI 管理，能够更加直接方便的管理提示词、工具、报告、参数（数据、文件或代码仓库）、依赖（Docker 中的工具）、对外暴露的 API 能力等。
随着技术的进一步提升与功能需求的不断丰富，也希望在架构上进行升级，提供如多 Agent 协同、记忆与上下文管理、交互数据和任务反馈等更丰富的能力。
通过在 AIOps 流程中的持续探索和成熟之后，我们也希望将这一套方案迁移到我们七猫的业务中，开发对应的业务通用 Agent、数据通用 Agent 等。

参考链接

95. 对Manus创始人肖弘的3小时访谈：世界不是线性外推，做博弈中的重要变量
Manus 的调研与思考 | Why·Liam·Blog
04｜提示工程：更好地释放LLM的能力-程序员的AI开发第一课-极客时间
https://react-lm.github.io/
https://www.promptingguide.ai/zh/techniques/react
https://github.com/cline/cline/blob/main/.clinerules/workflows/pr-review.md
Linux 文本三剑客超详细教程：grep、sed、awk

AI 驱动工作流 - 自动化项目分析与线上问题修复

七猫技术 — Mon, 20 Oct 2025 01:50:28 GMT

供稿来自：@吴安乐

一、引言

此前我们已详细介绍了从需求梳理到提测&部署的AI辅助工作流。

在 Devops 生命周期中，上线后的可持续维护是保障系统稳定运行的关键环节。本文聚焦线上持续监测阶段，深入探讨如何通过AI驱动实现自动化的性能分析与问题修复，构建完整的可持续维护闭环。

二、方案简介

现状与挑战

虽然有监控工具能及时发现问题，但后续的诊断与修复强依赖人工。日常开发任务重，对于非严重问题无法及时抽出时间完成修复，从而沉淀为技术债务。

例如，Sentry用于错误追踪，Prometheus/Grafana用于性能监控，研发人员需手动分析日志、定位根因、编写修复代码等工作。

系统概述

本文提出的AI驱动可持续维护系统包含两大核心模块：

自动化线上问题修复：AI实时监控Sentry问题 → AI 自动修复代码并创建MR → 飞书通知详情 → 人工最后确认
自动化线上性能分析：监控项目性能指标与构建产物 → 自动识别性能瓶颈 → 生成优化建议

核心目标

人工零干预：从问题出现到修复方案生成（MR）完全自动化，减少人工 90% 的工作量。
人工确认机制：mr 生成后飞书实时通知，研发人员仅需关注最终审查与合并
缩短问题修复时间：从错误发生到修复方案生成，最短可在3分钟内完成
可视化与可追溯性：提供完整的错误趋势监控和修复记录留存，便于审计与复盘

三、核心原理与架构设计

架构

触发层：Sentry webhook、飞书监控模块捕获事件。
执行层：阿里云运行自定义Docker镜像，调用Claude Code（无头模式）执行性能分析，代码分析与修复。
交互层：飞书aPaaS推送通知、展示数据看板，人工确认MR。
存储层：修复记录、性能数据留存于飞书数据库，支持SQL查询与可视化。

工具

docker 镜像
claude code：AI cli 编程工具，支持无头模式自动化运行
mcp：qm-lighthouse-mcp 前端性能监控与优化工具、lark-mcp：飞书生态中的监控与告警模块、codeup-mcp：代码托管与流水线集成工具
Headless Chrome：无头浏览器，包含 chrome 全部内核，用于前端性能分析的虚拟环境
定制化提示词：提示词
飞书APAAS 应用
阿里云流水线：AI 流程执行的核心容器

流程

自动化线上问题修复

自动化线上性能分析

四、成果展示

修复案例

五、总结

基于 AI +claude code等 AI cli 工具，我们能轻易构建一个无所不能的AI Agent。就像第一次工业革命的蒸汽机，基于蒸汽机，可以实现火车，轮船等一系列改变世界的伟大发明

AI 利器：Claude Code 服务化

七猫技术 — Thu, 16 Oct 2025 01:52:24 GMT

供稿来自：@李天鸣

写在前面

要问 2025 年上半年 AI 编程领域哪家强？我相信 Cursor 会是呼声最高的选手。但这个领域变化之快也是令人始料未及的，谁会想到在 2025 年撼动 Cursor 地位的竟然是一款命令行工具，一个连鼠标都不用的软件——Claude Code。

我的主力 AI 编程工具也从 Cursor → Cursor + Claude Code：

「代码块」级别的精确控制使用 Cursor 的 Tab 功能。
「功能」级别的改动则直接使用 Claude Code 来完成。

融入工作模式

时间回到今年三月份，当时觉得 Cursor 在本地运行做代码评审、单元测试、问题分析等任务的能力，完全吊打传统的静态分析工具，同时也远远强于只调用 Open API 的工作模式。

于是，自然而然地想要将 Cursor 做成服务化应用在各个工作流中，奈何我能力有限，难以将界面化的 Cursor 应用进行很好的封装。而这些阻碍恰好在 Claude Code 这个命令行工具面前迎刃而解。

上图是一个程序员简化后的工作模式，左侧工作主要是跑在本地环境，相信大家也都自己舒适的解法，不再赘述。右侧「服务端环境」则是将 Claude Code 部署在服务器上来打通各个工作流，如代码评审、服务部署、日常巡检、告警监控等，以此实现相对高质量的 AI 自动化能力。

Claude Code 服务化简化

架构图：

请求处理流程

传输层：Recovery、Request ID、Metrics 中间件的作用
应用层：参数解析、验证、响应处理的具体流程

业务层核心逻辑

任务类型判断：异步 vs 同步任务的分支逻辑
同步任务处理：直接执行并等待结果
异步任务处理：GoSafe 协程、独立上下文、Webhook 回调

存储层执行逻辑

Docker 沙箱管理：容器创建、环境配置、卷绑定、网络配置
命令执行机制：具体的 Claude CLI 命令格式
重试与错误处理：重试策略、会话继续、超时控制、资源清理
异步回调机制：WebhookRequest 构造和发送

应用场景

这里以「AI 代码评审」生成分析报告为例：

异步处理模式下，AICR Agent 接收请求后立即返回，由 Claude 服务在容器内异步执行分析并通过 Webhook 回调 DevOps 服务，期间任务状态由 Redis 维护，分析结果上传文件服务器生成访问 URL。

功能演示：

总结

坦率来说，我也是花了将近一个月来适应 Claude Code 写代码。而一旦适应了这种“键盘即界面”的极致效率，真就有一点不想回去了。再加上 Claude Code 命令行工具的属性（无界面、轻量级、灵活性），天然能够方便地集成到不同的工作流中实现自动化能力，这种渗透能力绝对强的可怕。也许 Claude Code 挑战的不是 Cursor，而是在重塑全新的编程模式。

AI 协助接口健壮性测试

七猫技术 — Mon, 29 Sep 2025 02:16:02 GMT

供稿来自：@许小雨、王敏

一、背景：

本文旨在实现API健壮性测试用例的自动化生成与执行，提升API的质量与可靠性，同时降低人力投入和测试成本。

二、解决问题：

测试重心偏向核心业务测试人员主要关注核心业务流程，往往忽略了接口参数类型、边界值等细致测试，导致部分异常场景未被覆盖。
接口和参数数量激增随着系统接口和参数数量不断增加，人工难以穷尽所有组合，测试覆盖率不足，容易遗漏特殊或极端情况。
人工设计用例成本高、效率低手工编写和维护测试用例耗时耗力，难以适应接口频繁变更和快速迭代的需求。
异常和非法数据场景考虑不全对于参数异常、非法输入等非正常业务场景，测试设计往往不够系统，存在健壮性和安全性隐患。

三、项目整体流程图

四、用户使用详细流程

1.  **启动服务**:
    *   打开终端，进入项目目录，运行以下命令：
        ```bash
        python curl_parser_web.py 
        ```
    *   复制终端里显示的网址 (例如: `http://127.0.0.1:8001`)。

2.  **开始测试**:
    *   在浏览器中打开刚才复制的网址。
    *   将你的cURL命令**粘贴**到页面的输入框里。
    *   点击 **`全流程`** 按钮。

3.  **查看报告**:
    *   等待页面刷新。
    *   点击页面底部出现的 **“点击查看”** 链接，即可在新标签页看到测试报告。

五、AI提示词（Prompt）

1. 通过apifox MCP获取接口信息数据。

目的：为了获取接口元数据，接口参数等。

## 1. AI智能获取apifox的接口信息
请使用 MCP 读取apifox的接口信息并存储到api_definitons目录中，生成信息格式参考api_definitons/api_definition_sample.json，读取接口信息：api/v1/community/audit/post/list

2. cURL命令解析

请将以下cURL命令解析为结构化API信息，输出字段包括base_url、api_path、method、headers、data。

## 1. AI智能解析与补全接口定义

- **用AI自动补全接口定义JSON里的描述、参数说明、示例数据等，提高接口文档质量。**
- **关键提示词：**
  > 根据以下接口path和参数，自动生成详细的接口描述、参数说明和示例数据，以OpenAPI JSON格式输出。

## 2. AI驱动的cURL命令智能解析

- **用AI模型解析复杂cURL命令，自动提取base_url、api_path、headers、data等，智能填到apiInfo.csv。**
- **关键提示词：**
  > 将以下cURL命令解析成结构化API信息，输出字段包含base_url、api_path、method、headers、data。

## 3. AI自动生成健壮性测试用例

- **结合接口定义，AI自动生成边界值、异常、SQL注入、XSS等多种类型测试用例，提高测试覆盖率。**
- **关键提示词：**
  > 为以下API接口自动生成健壮性测试用例，覆盖参数缺失、类型错误、边界值、格式错误、安全性等场景，以CSV格式输出。

## 4. AI辅助接口测试结果分析

- **用AI分析测试报告，自动归纳失败原因、给出修复方案建议，提高测试闭环效率。**
- **关键提示词：**
  > 分析以下API测试报告，归纳失败原因并给出修复建议。

3. 自动生成测试用例

# API测试用例生成Prompt
请给我设计一个通用的健壮性测试用例脚本如下：
#API测试用例生成脚本


请使用以下步骤为给定的API接口生成全面的测试用例：

## 第一步：获取API信息
使用Apifox MCP工具获取目标API的详细信息，包括：
- 接口地址和请求方式
- 请求参数（查询参数、请求头等）
- 响应结构
- 参数说明（是否必填、数据类型、描述等）

## 第二步：整理API文档
将获取到的API信息整理成结构化文档，内容应包括：
- 接口基础信息（URL、方法、描述）
- 请求参数表格（参数名、必填性、类型、描述）
- 响应参数结构
- 相关业务说明

## 第三步：设计健壮性测试用例
针对API的异常情况，设计健壮性测试用例，确保对**每个请求参数**覆盖以下所有异常场景：

### 参数缺失测试
- 必填参数完全缺失
- 必填参数值为空（""、null）
- 多个必填参数同时缺失

### 参数类型错误测试
- 字符串类型参数传入数值、布尔值、数组等其他类型
- 数值类型参数传入字符串、布尔值、对象等其他类型
- 布尔类型参数传入字符串、数值等其他类型
- 数组类型参数传入字符串、数值等其他类型
- 对象类型参数传入字符串、数值、数组等其他类型

### 参数范围与长度测试
- 数值参数：0值、负数、小数、超大值、最小值、最大值边界
- 字符串参数：空字符串、超长字符串、最小/最大长度边界
- 数组参数：空数组、超大数组、单元素数组
- 日期参数：无效日期、未来日期、历史日期、边界日期

### 参数格式测试
- 不符合格式要求的参数值（如邮箱、手机号、URL等）
- 特殊字符（如emoji、Unicode字符、控制字符等）
- 不同编码的参数值（如UTF-8、GBK等）

### 安全性测试
- SQL注入测试（如 ' OR 1=1 --, 等SQL片段）
- XSS测试（如  等脚本代码）
- 命令注入测试（如 ; rm -rf /、& ipconfig 等命令）
- CSRF测试（缺少或伪造CSRF token）
- 敏感信息测试（如尝试获取敏感数据）

### 业务规则测试【需要结合业务逻辑自定义规则】
- 违反业务唯一性约束的参数
- 不符合业务关联性要求的参数（如关联ID不存在）
- 违反业务状态流转规则的参数值
- 权限边界测试（如尝试操作无权限资源）

### 参数组合测试
- 多个参数同时出现异常情况
- 互斥参数同时提供
- 依赖参数关系测试（一个参数依赖另一个参数）

健壮性测试用例遵循CSV格式，预期结果应包含相应的错误代码和错误消息：
```csv
测试标题,请求参数,预期结果
```

## 健壮性测试结果判断标准
对于接口异常场景，满足以下任一种情况即视为测试通过：

### 状态码判断
- **4XX系列**：
  - 400 Bad Request：参数错误、请求格式错误
  - 401 Unauthorized：认证失败
  - 403 Forbidden：权限不足
  - 404 Not Found：资源未找到
  - 422 Unprocessable Entity：业务逻辑不合法

- **5XX系列**：
  - 500 Internal Server Error：服务器内部错误
  - 503 Service Unavailable：服务器过载或维护中

### 错误信息判断
- **详细描述**：响应体中应包含清晰明确的错误信息，说明异常原因
- **错误码**：返回特定错误码，便于定位问题

### 其他判断
- **安全性**：响应中不应包含服务器内部路径、数据库结构等敏感信息
- **幂等性（待拓展）**：修改操作的接口在异常场景下应保证幂等性（同样的操作做一次和做多次，结果是一样的）

## 注意事项：
1. 测试用例应确保覆盖每个参数的所有可能异常场景
2. 预期结果应基于API的实际设计，包含正确的状态码和数据结构
3. 对于模糊匹配的内容，可使用星号(*)表示
4. 测试参数应考虑实际业务约束和验证规则
5. 确保对所有输入参数都执行完整的测试矩阵

## 示例应用：
以"帖子列表接口"(api/v1/community/audit/post/list)为例，生成健壮性测试的完整测试用例集，涵盖参数缺失、类型错误、范围越界、格式不当、安全性问题等各种异常场景。

六、接口测试案例

测试接口：【帖子筛选接口】api/v1/community/audit/post/list

导入的API接口信息：

生成的测试用例：

用例执行结果：

发现问题：

问题1：biz_id参数XSS攻击-请求参数：{bizid=“”}，预期：这种情况应该报“400 Bad Request - 参数biz_id包含非法字符实际：展示了部分帖子内容
问题2: 结束日期早于开始日期-请求参数：{"comment_start_time": "2023-06-01", "comment_end_time": "2023-05-01"}预期：响应信息应该展示：结束日期不得早于开始日期的提示实际：展示了部分帖子内容

七、AI赋能价值总结

项目优点：AI在测试流程中的应用与简化

1. AI辅助接口定义与用例生成

接口信息补全：能从cURL命令或部分JSON中提取信息，并自动补全，生成结构化的接口定义，这可以减少手动编写文档的工作量。
测试用例生成：能够基于接口定义，自动创建包括异常值和参数值缺失相关的测试用例，这有助于提高测试的覆盖范围。
测试结果分析：规划了AI分析测试报告的功能，旨在帮助归纳失败原因和提供修复建议，有潜力加快问题定位和修复的过程。

2. 简化的Web操作界面

一站式操作：项目通过curl_parser_web.py提供了一个Web界面，将多个后台步骤（解析、生成、执行）整合起来。
操作简单：用户通过在页面上粘贴信息和点击按钮，就可以启动整个测试流程，降低了工具的使用难度。

目前不足之处与后续改进

1. 从用户操作的角度来看，虽然流程简化了，但在控制性和反馈上还有提升空间

2. 对复杂业务的理解有限：AI擅长生成通用的、模式化的测试（如边界值、常规安全漏洞），但对于需要深度理解特定业务流程的测试场景，AI可能无能为力，例如，一个涉及多个步骤、有复杂状态流转的交易流程，AI很难仅凭一个接口定义就生成有意义的端到端测试用例。

不用rules？用提示词MCP！

七猫技术 — Tue, 16 Sep 2025 02:51:59 GMT

供稿来自：@姜森

为什么商业化团队的提示词方案选择了MCP？

在商业化服务端项目多的情况下，使用rules难免会遇到rules更新不方便，存在公共提示词在各项目、各成员中不统一，无法版本控制，维护困难等问题；

简介

这是一个提示词的MCP server，他会将预设的prompt作为工具(tools)返回，帮助Cursor/Cline...更高效地执行各种任务。

背景

在提示词如何使用这个问题下，商业化团队也进行了很多尝试，最终找到了一种适合团队层面的提示词方案，也就是MCP的方式。这个基于标准协议的提示词工程，可以脱离cursor使用，在deepchat、trae等支持MCP接入的客户端使用统一的提示词；

项目介绍

便于使用：在对话框中仅需输入两个字即可完成整个提示词流程；
使用 MCP SSE 模式：可轻松部署在开发环境集群或本地环境；
维护简单：仅需更新项目中的 YAML 文件即可管理提示词，未来可实现可视化平台；

name: prompt_name                # 唯一标识符，用于调用此prompt
description: prompt description  # 对prompt功能的描述
arguments:                       # 参数列表（可选）
  - name: arg_name               # 参数名称
    description: arg description # 参数描述
    required: true/false         # 是否必需
messages:                        # prompt消息列表
  - role: user/assistant         # 消息角色
    content:
      type: text                 # 内容类型
      text: |                    # 文本内容，可包含参数占位符 {{.arg_name}}
        Your prompt text here...

扩展性强：各研发团队可独立维护专属提示词库，甚至可推广至非研发团队；

集中化管理：统一维护团队公共提示词，解决本地提示词版本管理难题；

Git 集成：利用 Git 仓库管理提示词，天然具备版本控制、分支管理与 CI/CD 流水线发布能力。

效果展示

配置和部署

codeup 仓库

Appstack 部署

cursor中实际效果

以生成测试用例文档为例，仅输入test_doc，即可触发tools，获取完整的提示词，并执行；

总结

好的提示词需要不断积累和迭代，这也是团队和公司宝贵的财富，本方案可以让提示词使用更方便，更通用。如果有使用提示词MCP的需求，推荐复制该代码到本团队代码仓库，维护属于本团队的提示词MCP。

AI 编程落地业务开发的探索与实践

七猫技术 — Wed, 03 Sep 2025 04:11:27 GMT

供稿来自：@李韬

一、序言

我们收集了大家在AI 编程中遇到了各类问题：

如何高效使用 Rules 和 MCP？当前使用门槛较高，是否有最佳实践？
如何让 AI 在处理复杂需求时表现更优？
面对架构复杂的老项目，AI 处理效果不佳，如何解决？
希望生成简单代码时，AI 输出却过于复杂，如何优化？
...

收集到的问题很多，但是核心问题我觉得可以被归为两类：

AI编程不稳定，我们无法评估这个功能结合AI开发工期如何，这种“无法掌控的感觉”是在业务迭代中不能接受的。那么如何提升AI编程的稳定性，让流程可控是我们核心要解决的问题。
AI编程有一定门槛，或者说用好AI编程有一定门槛，比如 MCP 配置、Rules 管理、Cursor 配置等等都比较繁琐

经过数月在业务场景中深度应用 AI 编程（覆盖全新项目开发、老项目代码重构及新模块扩展），以及团队对AI 工程化建设、MCP 工具开发等实践，我对上面两个问题有了答案。本文将从以下两部分展开：

AI 编程配置：详解项目中 Rules、MCP 及自定义模式的配置实践。
AI 开发流流程：剖析不同场景下（新项目 / 老项目）的完整开发流程，涵盖计划、编码、复盘核心环节，通过标准化流程释放 AI 编程效能。
优化提示词：介绍在AI编程场景下如何高效优化提示词

二、AI 编程基础配置

工欲善其事，必先利其器。我们先来介绍项目中必要的 rules、mcp、custom mode 配置，然后提供给大家一个更低门槛、更快速完成配置的方法。

Rules 配置

前置条件：确认项目已具备以下核心 Rules 文档：

项目架构（包含目录结构、技术栈、业务分层）
技术方案编写规范
代码开发规范（命名、注释、格式）
功能开发流程模板
代码提交与评审规范

文档价值：传统开发中，系统化文档可降低重复培训成本；而 AI 缺乏长期记忆，每次会话相当于 “新成员入职”，标准化文档是 AI 理解项目的核心依据

文档组织最佳实践

集中存储：将 Rules 统一存放于项目根目录 .cursor/rules 下，便于 Cursor 自动引用。
场景化分类：按开发阶段命名文件前缀，示例目录结构如下：

.
├── plan
│   └── p-design-tech-solution.mdc            // 技术方案编写规范、模板
├── develop
│   ├── d-gen-data-center-crud-from-sql.mdc   // d-gen 开头的是总结的某类功能的代码生成模版、开发流程。
│   ├── d-gen-cronjob.mdc                     // cronjob 开发流程、代码模板;
│   ├── d-gen-api.mdc                         // http api 开发流程、代码模板;
│   └── d-test-unit-test.mdc                  // 单元测试规范、模板
└── review
    ├── r-code-review.mdc                      // 代码评审规范
    ├── r-git-commit.mdc                       // commit message 规范
    ├── r-merge-request.mdc                    // 创建远程合并请求流程
    └── r-summary-sop.mdc                      // 总结本次代码修改的标准流程生成 p-gen-xx 文件，供下次开发使用
├── g-code-spec.mdc                            // 项目代码规范
├── g-project-hotkey.mdc                       // 项目中的 hotkey 比如\`提示语中出现 cr 则参考 xxx.rules 执行\`
├── g-project-structure.mdc                    // 项目结构、技术架构、业务架构...
├── g-system.mdc                               // 项目 AI 聊天规范，比如强调多轮对话、引导补全...

根目录规则文件：作为项目默认规范，配置 RuleType 为 Always、Auto Attached、Auto Request，在对话中自动携带。
子目录规则文件：仅在特定场景使用，配置 RuleType 为 Manul、Auto Request。

Rules 编写技巧

老项目规则生成：结合 /Generate Cursor Rules 快捷命令生成部分规则。

开发后总结：代码提交阶段，让 AI 结合代码变更和聊天记录总结生成功能开发规范。
参考 Rules：Cursor.directory/rules

自定义模式配置

很多人会分不清自定义模式下的系统提示词和 Cursor Rules 分别应该存放什么内容，觉得功能比较重复。我是这样理解的：Cursor Rules 下存放的是原子的、独立的规则, 自定义模式的系统提示词会编排这些 Cursor Rules 形成工作流。

应该有的模式

在开发不同阶段配置不同自定义模式，模式的名称可与规则子目录一致，分为 plan、develop

如何配置

1. 模式开启Cursor Settings → Features → 勾选 Custom modes。

2. 模式定义

plan 模式（规划阶段）
模型 gemini-2.5-pro，具备深度思考，对长上下文解析能力更好的
MCP feishu、filesystem，打通需求文档访问
系统提示词，如下：

你是一个资深架构师，擅长需求分析、技术方案设计、任务规划。

## 1. 需求分析阶段
本阶段的目的：同用户一起熟悉并确认需求，梳理需求逻辑

在开始本阶段工作前，请再次确认并充分理解 `p-story-analysis.mdc` rules 规则中的指导原则。
结合规则，一步步帮助用户熟悉需求。此阶段分析的成果（如核心流程、关键实体、伪代码）将作为技术方案设计的重要输入。

注意：对于复杂逻辑，请引导用户或协助用户使用伪代码的形式对其核心逻辑进行描述。伪代码应能清晰反映主要步骤、关键判断和循环，同时兼顾边界条件。在技术评审前，可以先输出一个侧重核心逻辑、简化错误处理的伪代码版本。生成的伪代码初版可供用户评审，AI 应根据用户反馈进行迭代优化，直至满足技术评审要求。

## 2. 技术方案设计阶段
在开始本阶段工作前，请再次确认并充分理解 `p-design-tech-solution.mdc` rules 规则中的指导原则。
### 2.1 首先进行可行性分析，主要是对针对第三方接口。通过 TDD 测试驱动开发的方式编写测试用例和对应第三方接口请求实现，等待用户进行测试验收。

### 2.2 可行性确认完毕后，结合规则编写输出：《技术文档.md》 文件初版，并辅助用户完善文档。该文档应力求包含[架构图、模块划分、接口设计、数据模型、关键技术选型、风险评估等关键要素]。完善后的《技术文档.md》将是任务拆分的主要依据。

在技术方案中，如果涉及到关键算法或复杂流程，请引导用户或协助用户使用伪代码的形式对其核心逻辑进行描述。伪代码应能清晰反映主要步骤、关键判断和循环，同时兼顾边界条件。
《技术文档.md》初版已生成后，请用户审阅并提供修改意见。AI 应根据用户反馈进行迭代优化，直至满足技术评审要求。

在本阶段工作中，请持续关注并识别潜在的技术风险、业务风险、外部依赖，并及时与用户沟通。

## 3. 任务拆分阶段
在开始本阶段工作前，请再次确认并充分理解 `p-task-splitting.mdc` rules 规则中的指导原则。
完成技术方案设计后，结合规则及完善后的 `技术文档.md` 输出 `开发任务.md` 文件初版，并辅助用户完善文档。该文档应包含[任务列表、优先级、预估工时（可选）等]。

在本阶段工作中，请持续关注并识别潜在的技术风险、业务风险、外部依赖，并及时与用户沟通。

3. develop 模式（开发阶段）

模型 claude-3.5，较强的代码能力，生成速度较快
MCP mysql, gitlab, codeup等，打通数据库，代码仓库
系统提示词，如下：

你是一个资深开发，擅长各种语言、设计模式、算法，你对代码的质量有极高的要求。

# 开发阶段流程规范
## 任务维护
1. 详细阅读 `技术文档.md`,`开发任务.md`，明确任务目标、功能需求和技术要求
2. 每完成一个子任务，立即更新 `开发任务.md` 中的对应任务状态
## 开发执行
1. 按照`开发任务.md`逐步进行代码实现，每完成一个任务后，简要说明完成情况和主要改动点，提交给用户进行 review 确认
2. 确保代码符合项目架构和设计模式，如无必要尽量保持简单实现
3. 对核心功能，可根据 `d-test-unit-test.mdc` 规则编写单元测试，保证代码质量和功能正确性

# 代码提交阶段流程规范
## 代码审查
1. 提交代码前，必须参考 rules `r-code-review.mdc` 中的规则进行全面的代码审查
2. 确保所有问题都得到解决后，方可进入下一步

## 代码提交&推送远端

MCP 配置（面向公司内部）

企业内部MCP

目前最常用的是需求平台和代码平台打通的 MCP 工具，主要提供搜索未完成需求、查询需求文档内容、提交合并请求等 tools。你可以使用 DevOpsCTL 工具去获取配置，如下：

企业外部MCP

你可以去网站寻找开源工具：

如何快速完成项目配置

对于改动较为频繁的 rules, 我们将它单独维护在 https://codeup.aliyun.com/qimao/public/cursor-rules 项目中，你可以提交自己团队的 rules. 然后可以通过 devopsctl rules install 命令安装团队的 rules 到项目中
对于修改低频的mode、mcp 我们将配置内置在了 devopsctl，你可以 通过 devopsctl mode genconfig , devopsctl mcp genconfig 获取配置

三、AI 编程流程

AI编程流程的固化是为了提升AI编程的稳定性，如何设计这个流程呢？
其实现实中的敏捷迭代流程已经给了我们答案，为了保证流程、工期可控，整个迭代流程被拆分成了 需求分析、需求澄清、技术方案设计、任务拆分、开发... 等等阶段。我们无需去创新工作流，只需考虑如何在原有的迭代流程加上AI辅助提效即可。

在研发视角下，开发流程可被大致划分为下面三个阶段，在此过程中编码体检和效率应不断提升。

简单解释一下几个阶段的作用和目的：

计划阶段：对应需求迭代的需求分析、需求澄清、技术方案设计、任务拆分等前置工作，是保证开发质量的重要因素
编码阶段：参考计划阶段输出的文档进行开发
复盘阶段：CodeReview、Rules 生成（代码模版、某类功能的开发流程）..., 保证后续计划阶段、编码阶段的质量、效率

下面我们通过不同的研发场景进行详细解释。

场景一：新项目或新模块开发

✏️ 计划阶段

好了完成了前置配置工作，终于可以开始愉快的开发工作了。第一步我们需要进行 需求分析、方案设计、任务拆分，与AI达成共识，最终产出技术文档，并通过该文档指导AI后续编码工作。

切换到 plan 模式后，输入需求链接或需求文档链接+实现要求，AI 会根据 p-design-tech-solution.mdc 中的需求分析要求和技术文档模版进行技术文档编写

其中最核心的规则是强调三点：

避免主观臆断的功能实现，需要确认沟通
需求任务复杂情况下，拆分分析任务，多轮对话，增强质量把控
提供技术文档模版，保证内容质量和格式在这些规则要求下，AI会先生成一份大纲，比如：包含核心流程、数据库设计、API设计，核心功能伪代码等，但是每一部分内容比较简略，AI会与我们多轮沟通逐渐完善每一个部分。

如下是一个实际功能开发的plan流程：【暂不支持视频】

最终我们会得到两份文档：技术文档.md、开发任务.md（简单功能可能会合成一份）、基础代码（三方接口的验证测试用例，核心代码框架），用户可以在后续编码阶段使用。

这里强调一点，技术文档和开发任务都要尽量具体，比如标明涉及的文件（我们AI没有生成出来，我们自己补充上），比如:

图1中，是一个是比较简单的功能，AI帮我们梳理出来了涉及文件。
图2中，是一个复杂的任务，我给缺少相关文件的任务进行了补充。

简单功能

复杂功能

⌨️ 编码阶段切

换到 develop 模式后，结合开发任务.md+技术文档.md我们让AI进行开发。同时如果有同类功能开发的模版或SOP Rules，可以提供AI参考，提示词如下：

接着，我们需要不断对AI完成的任务做出反馈, 或者直接动手修改，完成后再进入下一个任务。下面是develop流程的部分录屏：【暂不支持视频】

开发完成后我们可以通过两种方式进行代码提交：

手动提交

通过Cursor中的Git插件进行 commit message 生成很好用,就是格式不易控制，可能需要自己微调一下（调整后 Cursor 也能学习到）。

Agent

提交我们通过 develop 自定义模式触发提交，可以看到 Agent 执行了代码评审并将修改划分成两个Commit提交，甚至贴心的帮我把一些不该提交的文件添加了 .gitignore

🧠 复盘阶段

在复盘阶段我会选择性的执行如下三个流程：

生成代码模版：如果你已经知道某个场景可以总结为反复利用的代码模版，那么直接手动触发，生成 Rules。
总结某类功能开发的SOP：当某次功能开发涉及到一个较完整的模块时，我会让 Agent 根据当前分支和主分支的差异生成开发某个模块的标准流程，提示词如下：

生成结果如下, 可以看到内容包含了开发这类功能应该新增｜修改哪些文件，并整理了代码依赖关系，这个文档既可以给人参考，也可以帮助AI更高效的生成代码！

场景二：老项目逻辑调整

在复杂的老项目对某个模块进行修改时，我们用 AI辅助分析+Tab辅助编码 的形式的AI编码模式。因为我们要让AI全面理解项目的时间较长、难度较大，并且代码本来也不会特别多，所以这样更省时间。

✏️ 计划阶段

对老项目的改动我们求稳，让AI根据需求生成技术文档.md和开发任务.md时着重强调找到相关代码并确认改动点和风险点，这对刚接手项目的人也是一个快速了解项目的方式。

⌨️ 编码阶段

结合上一步的生成的 技术文档.md和开发任务.md，我们找到对应的改动点进行手动编码，Cursor 中的Tab模型在 0.5.0 后，使用体验上有质的飞跃，可以跨文件提示非常智能。

🧠 复盘阶段

同场景一

四、优化提示词

在涉及到AI的场景，提示词就是核心，它决定了我们AI编程的效果。所以在新加入 Custom mode 或 Rules 时我们要慎重，需要保证它的质量。

我们可以分两个阶段进行优化：

结构优化 这一点，任何的AI平台都可以做，我们可以直接在Cursor里让它参考 RICE框架 优化提示词结构，输出格式为 xml 或者 markdown
内容优化内容优化涉及到相关代码库、业务知识，所以我们在Cursor里进行调优效果更好。

AI编程场景，我们无法获取Cursor最终拼接的Prompt是什么，Cursor会在服务端进行相关代码配置、提示词修改最终给到大模型去回复，所以在其他平台进行提示词优化无法到达最好的效果。

我通过 Cursor-Agent 的方式搭建了一个提示词优化工作流，主要流程为：填入提示词 v1-> 填入测试用例 -> 生成回复 -> 人工提供反馈 -> 生成优化提示词V2；文章篇幅有限，不在这里展开说了，详细内容可以参考：Prompt 调优Agent。

五、总结通过

标准化的 Rules 配置、场景化的模式设计及全流程的工具链打通，AI 编程从 “实验性工具” 转变为 “可落地的生产力”。

我觉得AI在编程领域一个很大的价值在于：可以将团队的研发流程快速统一。在以前这些经验只能通过文档分享的方式让团队成员吸收，效率很低。而现在，通过AI，我们可以快速将我们宝贵的经验以工作流 prompt 的形式分享并落地。

这里总结一下本文的核心要点：

文档先行：用结构化 Rules 降低 AI 理解成本。
流程驱动：分阶段（计划→开发→复盘）规范操作，通过每个阶段对应的自定义模式让研发流程更规范、可控，也降低了使用门槛。
人机协同：复杂分析与简单编码交给 AI，关键逻辑由人工把控。
注重提示词质量：提示词需要维护，我们要及时的更新、优化

AI 代码评审在七猫的实践

七猫技术 — Wed, 27 Aug 2025 02:31:16 GMT

供稿来自：@李天鸣

写在前面

作为一个程序员，我们的工作本质上就是交付一行行的代码，那么对代码质量的把控始终都是重要的环节。本次 AI 代码评审的关键目标如下：

通过 AI 对代码的分析能力来辅助代码评审，提供不同视角来发现潜在的问题；
掌握 AI 应用工程化的核心开发流程与新技术的实践经验，为 AIOps 打下基础。

产品方案

经过讨论后，我们大致认为有以下几种方案：

在没有 AI 评审之前，我们就是通过云效来对问题的代码进行评论的。

最后我们采用了方案一。用户在无须任何额外配置的情况下，提交合并请求（MR）后会自动触发代码评审，流程如下：

评论效果：

技术方案

技术选型

全代码 or 低代码？

👉 全代码。虽然目前各种低代码平台的功能也非常强大，但我们还是在可控性、稳定性、扩展性的角度来权衡，作为一个长期维护的项目，最后我们还是决定使用全代码来实现。

Python or Golang ？

👉 Golang。公司业务后端主要的语言为 golang，但是作为一个全新的项目我们并没有任何历史包袱，所以我们也认真考虑过是否要使用 AI 生态最为强大的 python ？不过最终我们认为项目的定位是为了解决企业内部的效率问题golang 已经足够用了。

手搓 or 框架？

👉 字节的 Eino 框架。经过技术调研，我们确定 AI Agent 开发模式具备一定的范式，比如“流程编排”必不可少，因为项目是以 LLM 为核心来进行开发的，而我们则是不断地对输入、输出进行调整。再比如“切面能力”业务逻辑中免不了对各个环节的调试。而这些能力框架都提供了，因此能够大幅提升开发效率。

业务流程

前置过滤：目前支持 <代码组> 和 <代码库> 两个级别的筛选设置。
AB 测试：因为不同模型、不同提示词对输出结果的影响很大，所以在项目一开始设计了 AB 测试功能，方便后续的效果调优与功能迭代。
获取数据：目前会获取“增量”的 diff 数据、commit 数据、修改的代码文件等。
数据分组：分析给定的代码文件集合，基于代码的逻辑关系、功能相关性和依赖关系，将文件进行智能分组。
初审：对代码进行第一轮的评审，根据不同级别输出对应的内容：
high: 高风险问题，影响核心功能或存在安全隐患，可能导致系统故障
medium: 中等问题，影响用户体验或代码质量，可能影响业务流程
info: 信息提示，代码规范或性能优化建议，不影响核心功能
复审：第二轮评审，根据第一轮的输出结果，以及相关数据来对问题打分。
输出过滤：根据打分由高到低排序，最终拿到 5 条评论（数量可配置）。
行间评论：调用云效 API 将结果反馈给用户。

项目排期

开发过程

流程编排

使用流程编排要求我们对步骤进行封装，定义好输入、输出的数据结构，然后进行组合：

func (f *Flow) compile() error {
        chain := compose.NewChain[*CodeReviewRequest, string](compose.WithGenLocalState(func(ctx context.Context) *ReviewContext {
                return &ReviewContext{}
        }))

        // 获取数据步骤
        fetchLambda, fetchOpts := f.FetchLambda()
        // 代码分组步骤
        analysisLambda, analysisOpts := f.AnalysisLambda()
        // 初审步骤
        preReviewLambda, preReviewOpts := f.PreReviewLambda()
        // 复审步骤
        secondReviewLambda, secondReviewOpts := f.SecondReviewLambda()

        // 流程是单向的链式编排
        chain.AppendLambda(fetchLambda, fetchOpts...)
        chain.AppendLambda(analysisLambda, analysisOpts...)
        chain.AppendLambda(preReviewLambda, preReviewOpts...)
        chain.AppendLambda(secondReviewLambda, secondReviewOpts...)

        // 编译，对输入输出进行校验
        runner, err := chain.Compile(context.Background())
        if err != nil {
                return err
        }

        f.runner = runner
        return nil
}

代码逻辑相对更清晰，可维护性强，根据业务需求的迭代只需要提供固定步骤，然后对编排逻辑进行改造即可。

数据结构

为了让大模型更好地理解代码评审的内容，我对 Diff 数据进行了结构化处理：

核心逻辑

是的，这里的核心逻辑已经不再是代码，而是由提示词构成的。

应用观测

与传统微服务一样 AI 应用同样需要进行观测，尤其是每次 token 消耗、API 调用 RT 等指标。感谢运维同学的大力支持 @郭子龙目前已经提供 langfuse 平台。

至此核心流程已经开发完成，能够监听 MR 事件 -> 获取数据 -> 分析代码 -> 行间评论。

效果调优

以下的测试内容，是针对一次真实的开发迭代来进行模拟的。代码变更行数 2000+，属于常规量级。

提示词优化

说是提示词优化，但是在实际过程中，我发现评审的最终效果始终达不到我的预期，所以在经过一天半的调整之后，我决定从数据结构开始重新设计。

由于篇幅的缘故，具体的过程就不做展开了，这里可以看到提示词的变更记录：

「初审阶段」最终线上版本传入给大模型的数据结构，可以看到这里我做了大量的减法：

[
  {
    "id": "文件编号",
    "path": "文件路径",
    "content": "文件完整内容",
    "change_ranges": [
      {
        "start_line_number": "变更起始行号",
        "end_line_number": "变更终止行号"
      }
    ]
  }
]

理解大模型的能力边界

缺乏精确计算能力：在行间评论的业务需求中，需要精确定位到具体的问题行号，但是即便我把每一行 diff 的对应行号信息算好给到大模型，但是在评论的过程中依旧会出现大量的“行号漂移”。当然我们可以提供行号计算工具给大模型调用，但是在实际测试下来对 token 的消耗非常严重，出于对工程化的考量我最终放弃了使用大模型输出的行号数据。
多不等于好：当我把 diff 变更数据、diff 行号信息、对应的文件数据都给到大模型之后，我发现模型给出的答案很多都是断章取义，从结果反推来看大模型的回答似乎没有很好理解代码本身，再结合上述的行号问题，我在翻看它的审查结果时效率也非常低下。

工具推荐

AI 应用开发提示词优化的时间，可能才是占比最大的时间，所以一款趁手的工具十分必要。

这里推荐一个提示词优化工具 promptpilot ，可以很好地帮助我们提升效率。

模型选择

目前主要是基于三个维度来考量：效果、耗时、成本。

计费方式基于：阿里百炼平台。
Token 数量：输入 100k 左右，输出 3k 左右。

数据分组阶段

当前采用 qwen-long 因为需要考虑到新项目的极端情况，qwen-long 支持百万级的上下文。

代码分析阶段

这里理论上还可以分为初审和复审，因为时间关系还没来得及比较

综合考量目前采用 qwen-plus 作为代码分析模型。

后续规划

用户自定义的评审设置：通过自然语言描述代码评审的偏好

我只想要输出 high 级别的问题，数量不超过 3 条。对于支付流程的代码需要重点审查，是否有并发问题……

通过 RAG 引入团队知识：目前各个业务方的业务模式是相对独立的，团队内部自治的规范，尤其是特定场景的业务知识，难以从公司层面做统一，但是又非常有实用价值，能够更好地辅助代码质量的评估。
建立反馈机制：不同用户对评审的结果也有不同的要求，通过收集用户反馈 + LLM 分析能力，来持续优化结果输出。

AI 应用的价值

「结构化」数据：数据具有高度的规范性和规律性，就像是整齐排列在货架上的商品，每一项都有着明确的定义、固定的格式和清晰的逻辑关系。
「半结构化」数据：它的结构更为灵活和松散，例如 XML 文档，其中既有标签来表示一定的结构，又允许在标签内有相对自由的文本内容。
「非结构化」数据：几乎没有明显的结构，像大量的文本文件、图片、音频和视频等。在传统互联网的发展进程中，其处理的数据范围主要集中于“结构化”数据。对于“半结构化”和“非结构化”数据，传统互联网的处理能力则相对有限。然而，在大语言模型时代，情况发生了明显改变。 我们可以通过 AI 应用开发来挖掘、加工、分析这部分的数据，解决传统编程无法处理的问题，从而提升企业的生产效率。

稳定性智能监控与归因

七猫技术 — Tue, 24 Jun 2025 08:00:00 GMT

供稿来自：@吴昌鑫

一、背景

App 稳定性是影响用户体验的重要因素之一，随着 App 功能及使用场景的日益复杂，稳定性保障贯穿开发、日常监控、问题解决等各个阶段。

开发人员日常值班、添加告警任务，关注稳定性趋势和 Top 问题波动。
运营和测试关注用户反馈，发现问题会第一时间同步开发、跟进解决。

这其中也一直存在一些问题：

形式化：人工值班制度效率低下，易流于形式。
效率不高：由于稳定性问题有较强的专业性，运营和测试发现问题，第一时间无法找到处理人，还需要值班开发人员初步分析，再转给处理人，涉及人员多、流程繁琐就很容易导致处理不及时；对于值班开发人员也不友好，经常充当工具人。

随着 AI 发展，希望通过稳定性 Agent 交付一个稳定性系统，能自主感知问题、自主分析，并且让非专业同学也能高效、精准地解决问题。

涉及多个岗位人员，频率高，还是希望能在飞书上闭环，所以选用了飞书Aily（低代码 Agent 搭建平台）进行开发。

二、技术实现

整体流程：

智能监控

智能监控主要覆盖稳定性指标日报、告警分析、运营反馈三个场景：

客户端开发人员均需了解并重视 App 稳定性数据；然而，日常多数开发人员不会主动访问 bugly 后台，因此期望以更简化、更轻量的方式促使大家参与其中。
稳定性波动在很大程度上是由线上配置变更引起的，其发生时间常处于上下班高峰期或凌晨，给排查和响应效率带来了极大阻碍，所以我们借助主动感知告警、智能分析来提升整体响应效率。

3. 当测试人员、运营人员收到用户反馈的闪退问题时，会前往 bugly 后台搜索闪退记录 -> 并在反馈群告知开发人员 -> 等待开发人员转交给具体处理人员，整个流程冗长、效率低下；通过稳定性 Agent 能够快速分析崩溃原因、找到处理人员。

智能归因

虽然我们做了大量稳定性、性能监控，但是有时候无法通过监控数据（比如崩溃堆栈）直接归因，需要结合代码、用户日志、用户埋点等进一步分析；但是各个系统都是独立的，希望通过 AI 打破数据孤岛、聚合智能归因。

时不时会收到用户反馈流量问题（比如1天耗流几十G，对用户伤害大），但是现在监控覆盖不全（比如受限于采样，iOS webview、流媒体播放都是独立进程、无法监控），需要结合耗流场景（广告、听书）进一步诊断分析；但是日志埋点往往数据量大，信息比较零散，人工分析耗时间；尝试通过 AI 整合多系统数据，聚合分析。
Bugly 是三方采购的稳定性监控平台，数据本身和我们自有系统相隔离；尝试通过 bugly-mcp，整合外部系统和自有系统，聚合智能分析。

AI 本身擅长处理大量数据，并且给到充足的上下文信息，AI 的分析能力将进一步增强。

三、总结与展望

稳定性 Agent 目前尚不能算作一个智能体，其智能化程度不足，细节方面仍需进一步优化；不过，期望在传统流程的基础上对“Agent”进行升级，使其具备一定的自主性（感知与决策能力），提高效率，并且使其更加简单易用。

通过接入更多数据，持续提升其能力。例如，在问题跟进过程中，只需提供一个用户 ID，便能实现稳定性问题的分发、流转与跟进。
（畅想）推动越来越多的系统实现 Agent 化，如日志系统、埋点系统等，借助多 Agent 协作来自主完成复杂任务；例如，在反馈群中，当运营反馈用户 A 出现崩溃情况时，稳定性 Agent 会立即向日志 Agent 和埋点 Agent 索要该用户的相关信息，日志 Agent 和埋点 Agent 返回相关内容后，稳定性 Agent 结合监控数据、日志以及埋点信息，自主分析出用户在何种场景下因何问题发生了崩溃。

AI + 跨平台 - 七猫书城改造与提效实践

七猫技术 — Mon, 23 Jun 2025 03:12:00 GMT

供稿来自：@王柯、@张文森、@王林、@费高联

背景&契机

随着纯血鸿蒙的推出，客户端跨平台需求被推到了前所未有的高度，业内都在如火如荼地做着各类跨平台改造。(字节开源Lynx、腾讯开源ovCompose、B站KMP实践、京东Taro)
我们鸿蒙端书城功能是落后双端很多的，需要尽快追齐。以上两点作为契机，我们进行了本次书城改造，对鸿蒙端来说是做新需求，对双端来说，是做次重构。开发中大量运用了AI，跨端方案选型为Flutter 七猫跨端方案选型，本文主要是总结下经验，希望这套开发方案能更多地推广，最后极大幅度提升客户端开发效率。

成果

Cursor使用数据(Flutter数据来自本次实践的4位开发，其他各端数据非全采样仅供参考)

现状 & 改进

客户端AI为什么不好用？影响研发效率的有哪些客观原因？

为什么AI更容易理解声明式UI？

总的来说声明式UI更简洁，且各端近年主推都是声明式UI。（安卓Compose、苹果SwiftUI、鸿蒙ArkUI、Flutter）

提效的思路

实践

工程AI化目录结构如下

.cursor/
├── docs
│   ├── book-store
│   │   ├── knowledge
│   │   │   └── book-store-ui-solution.md
│   │   └── request
│   │       ├── book-store-discover-request.md
│   │       ├── book-store-leader-board-request.md
│   │       ├── book-store-must-read-request.md
│   │       ├── bs-config-request.md
│   │       ├── bs-novel-request.md
│   │       ├── bs-rank-request.md
│   │       ├── bs-tag-books-request.md
│   │       ├── bs_listening_request.md
│   │       ├── bs_novel_load_more_request.md
│   │       └── bs_tab_listening_load_more_request.md
│   ├── common
│   │   └── widget-overview.md
│   └── templates
│       └── generate-request-dto.md
├── mcp.json
└── rules
    ├── code-quality.mdc
    ├── code-spec.mdc
    ├── gitflow.mdc
    └── preferences.mdc

Rules

Docs

文档统一以.md形式，Agent会话中按需取用。

BookStore (每个模块新建一个目录用于存放对应知识，可以有Reader、AD、Community、User等):
Knowledge: 存放书城技术文档，如类结构、目录结构等
Request: 存放接口定义
Templates: 存放通用模版代码
Common: 存放项目公共知识

现代化项目架构：数据分层

刚才我们讲到：cursor在原生开发上水土不服的原因之一就是项目缺少明显的架构分层，导致类文件代码膨胀，AI难以正确理解。

现代化的前端界面开发的共识就是数据驱动，这种思想也充分体现了软件设计中的关注点分离原则，提升了软件的可维护性，有利于将前端工程中的复杂状态管理标准化。

书城Flutter开发中，我们将数据分成了3层：

DTO : 服务端返回的网络数据
POJO ：本地持久化的数据
VO ：UI层使用的数据

传统的原生开发者往往喜欢在UI层直接使用服务端 or 本地数据库的数据，这么做并不合理，将业务逻辑与用户界面代码混在一起，只会使代码更加难以测试、调试和维护。

我们以书城单个feed流为例：

如此，当我们看到某个类，就知道其用于什么场景，需要拓展/调整功能，也可以快速搜索定位。

此外，Repository层的代码、BookVO以及Widget层的代码，cursor都可以根据实际情况精准生成，我们需要做的，仅仅是将dto代码映射为vo层的mapTo 工作，下面我们举🌰说明。

面向模版开发：精准生成request及dto代码

没有cursor时，为了解决无聊的重复代码编写工作，我们往往会定义许多模版代码，使用 ctrl c + ctrl v，然后根据具体业务改吧改吧就能用了，比如接口请求的request以及dto类，这个方法在cursor中能变得更加好用：

在.cursor/docs中创建“代码模版”，指导其生成对应代码；
根据不同业务配置模版代码中的变量，控制cursor智能能生成对应业务代码。

以小说tab接口为例：

# generate-request-dto.md
用于指导根据`curl`以及对应请求响应返回的`json`生成对应的request文件以及对应的dto文件。

## 步骤

### 1.生成 dto 文件
首先需要根据用户输入的json文件生成对应的`dto`文件，文件存放至 `%mf`路径下，若该路径不存在，请先创建对应文件夹目录（%mf为占位符，由用户输入）。
注意：dto相关字段需手动从map中解析，不使用`json_serializable`及`json_annotation`等package，注意嵌套json对象的解析，原则上dto中的字段类型不能为Map类型。
### 2.生成 request 文件
其次，需要你根据`curl`以及上一步生成的`dto`类生成对应的`request`文件，文件存放至 `%rf`路径下，若该路径不存在，请先创建对应文件夹目录（%rf为占位符，由用户输入）。
生成的request文件需要严格遵循下面模版：
```dart
import 'package:loktar/network/request.dart';
import 'package:loktar/channel/network_channel.dart';

class %r extends Request<%m> {

  final %t %s;

  %r(this.%s);

  @override
  Response<%m> fromJson(Map json) {
    final error = json['error'] != null ? ResultError.fromJson(Map.from(json['error'])) : null;
    final data = json['data'] != null ? %m.fromJson(Map.from(json['data'])) : null;
    return Response<%m>(dataObject: data, resultError: error);
  }

  @override
  bool get isSign => true;

  @override
  HttpMethod get method => HttpMethod.get;

  @override
  Map get parameters => {
        
      };

  @override
  DomainName get domain => DomainName.gw;

  @override
  String get path => %p;

  @override
  Map get headers => {};
}
```

## request文件相关说明

### 占位符说明：

[省略内部细节逻辑]

### 请求参数说明

[省略内部细节逻辑]

使用时，根据具体接口，我们创建具体文档输入模版中的变量，指导cursor生成对应代码：

# bs-novel-request.md
书城推荐tab接口请求返回json以及curl示例。
你需要根据该json以及curl生成`bs_feed_dto.dart`以及`bs_novel_request.dart`两个文件：
- %m: BSFeedListDTO
- %r: BSTabNovelRequest
- %mf: lib/book_store/dto/bs_feed_dto.dart
- %rf: lib/book_store/request/bs_novel_request.dart
  
详细的生成规则请严格遵循 @.cursor/docs/generate-request-model.md 要求

## json示例
```json
[省略内部细节逻辑]
```

## curl
```
[省略内部细节逻辑]
```

将bs-novel-request.md拖入cursor的聊天界面，cursor会帮我门生成对应的代码：

此次Flutter书城开发过程中，共有 10 个接口的 request及其dto代码，约 2100行代码，全由cursor自动生成，由于模版提供了明确的边界，这些代码完全不用修改就可直接使用。

业务组件沉淀：图生代码的最佳实践

传统的Android View体系由于组件继承体系的限制，使得自定义业务组件复杂度高，成为奢望。反观Flutter这种声明式的UI框架，通过不同的widget间的自由组合，使得我们可以沉淀出项目自己的组件库，同时这种声明式ui将组件状态与样式充分解耦，做到布局即代码，消除XML与Java/Kotlin之间的逻辑割裂。

在开局一张图，用Cursor生成代码？一文中，我们也提到过这种声明式UI对于cursor生成代码的友好。

以小说tab中的相关推荐书籍举个🌰：

代码秽土转生：利用Cursor翻译现有代码

书城flutter项目开发时，由于缺少项目文档，很多情况下我们需要“逆向开发”：先梳理 Android/iOS代码逻辑，再输出Flutter代码，这个过程往往复杂又痛苦。

但是借助Cursor ，我们只需要把 Native 代码通过 @file 输送给 Cursor，AI 工具就能快速理解 Native 代码，并结合现有的业务逻辑，完成Native 代码到 Flutter 代码的转化。

以发现页负反馈弹框为例：

展望

推广整体策略

新页面：直接使用AI + Flutter化的方案开发 (如正在做的勋章等)老页面：Flutter开发后，先在鸿蒙端上线，再推全到双端

书城Flutter化二期

免费小说客户端后续改造

下阶段目标

AI + Flutter生态完全铺开后，客户端开发综合提效150%。(200% - 100%) *1.5=150%

总结 & 风险

互补：脱离AI时，对于客户端研发，Flutter是个新的框架，需要不少成本去学习，但有AI加持，这个过程大大加速了，本次实践中，大多数伙伴也是从未写过一行Flutter代码的。
化学反应：AI + Flutter整体契合度非常高，写新需求+修bug体验都非常好。
潜在的风险：诚然，这套开发模式提效潜力较大，但Flutter本身是个复杂度极高的框架，随着渗透率的不断提高，未来会遇到各种复杂的问题，技术栈如何维护、下一步的演进方向是什么，是需要思考的问题。

FAQ

是否只能用于新需求开发，复杂项目维护、修bug是否用不了？良好的软件工程设计下，可以。
Flutter不能接商业化吧？插页广告要接怎么办？ 三端都可以接商业化，使用PlatformView，我们在鸿蒙端也做过了类似验证。
iOS 26推出了液态玻璃效果，Flutter是否天塌了？ 技术上并非不可实现，后续通过三方UI组件方式推进，参考Flutter应如何实现液态玻璃

七猫技术团队

重构开发范式：AI 时代下全栈开发的实践与思考

一、引言：被“沟通成本”吞噬的效率

二、核心理念：从“契约驱动”到“上下文驱动”

为什么 AI 能化解“沟通墙”？当我们将前后端代码视为一个整体投喂给 AI 时，奇妙的化学反应发生了：

三、架构实践：Go + 前端的一体化交付

技术选型逻辑

四、进阶秘籍：构建 AI 的“技能树” (Agent Skills)

1、建立 .agent 规范体系正如我的项目结构截图所示（见图 ），我在项目中维护了一个 .agent 目录，这不是给代码运行用的，而是给 AI “阅读”用的：

2、Token 的“一次性投资”

3、对话即开发

五、成果验证：海外广告投放系统

六、深度思考：工程师角色的转变

七、结语

为什么 flutter 的字体在 iOS 系统上更「细」？

现象

查找原因

iOS 系统上的字体

flutter 3.x版本的bug

iOS 系统上字体的差异性

解决方案

参考

AI 利器：Claude Code

一、写在前面

二、生态介绍

三、分享回顾

CC 基础操作

CC 高级扩展

CC 扩展对比

CC 扩展总结

四、实战案例

开发快捷指令（基于 Headless mode）

开发快捷指令（基于 Commands）

云效 MR 创建 Skill

Push 业务任务开发 Skill

CI/CD 集成

基于飞书 Aily 搭建 sls日志分析助手

一、背景与目标

二、飞书Aily相关介绍

1. 平台简介

2. 核心优势

3. 应用类型

三、SLS分析工具概述

1、前期准备

2、搭建方案 1：基于 “自定义智能体” 搭建 SLS 分析工具

3、搭建方案 2：基于 “工作流应用” 搭建 SLS 分析工具

四、后续改进

五、拓展应用：更多场景探索

AI 编程演进综述 v202510

一、技术基础：大模型能力持续提升

二、编程范式：从辅助到自主的演进

2.1 范式演进概览

2.2 不同范式对比

2.3 角色进化之旅

三、知识工程：AI 编程的隐式基石

四、工具形态：IDE 与 CLI 对比

4.1 AI 编程工具演进

4.4 维度对比

4.5 趋势总结

五、总结、展望及建议

5.1 变化总结

5.2 未来展望

5.3 行动建议

六、延伸阅读

通过 AI Agent 自动排查 K8s 问题

一、背景与痛点

现状痛点（Dev & Ops）：

典型场景：

效果与收益：

二、使用方式

使用示例：

三、实现方式

技术流程：

能力覆盖：

核心能力kubectl-ai：

飞书交互：

四、后续改进

五、结语

AIOps 通用 Agent 探索（Simple）

背景说明

1、建立 .agent 规范体系正如我的项目结构截图所示（见图），我在项目中维护了一个 .agent 目录，这不是给代码运行用的，而是给 AI “阅读”用的：