用AI写个个人玩具项目确实很顺手，但一旦落地到真实业务场景，情况就完全不同了。这篇文章整理了团队在打造AI原生研发团队过程中摸索出的实战经验，围绕四个核心方向展开：通用能力如何搭建、Harness工程实践、开发与产品如何高效协同。目标是打破职能壁垒，让不懂代码的产品同学也能借助AI，自主定义并实现内部运营工具，从而带动整个团队的研发效能提升。此外，还分享了一些踩坑后的教训，希望能给正在思考如何用AI提升团队能力的同学提供一些参考。

整体概览

让AI连续运行一整天，这确实是Harness Engineering能够达到的一种能力上限。但坦白说，这种方式更适合从零开始或与现有业务关联度较低的任务，不仅Token成本高，在日常开发中也很少会用到。

日常开发更多是在现有项目中增加功能、修复Bug，没有必要上那么重的自动化工程，轻量的Vibe Coding就足够了。因此，这篇文章不打算讨论如何把AI Coding的能力上限推得更高，而是重点解决一个更日常的问题：如何守住这类需求的质量下限，同时提高Token效率。

行业里的各种概念层出不穷——Prompt Engineering、Harness、Agent Loop——各有各的适用场景。事实上，很多事情本质上就是在搭建护栏（Harness）。

但说实话，团队里的每个人并不需要一上来就完全理解并应用这些概念。代码本身就是描述业务逻辑最精确、最高效的语言。对大多数人来说，更实际的起点，是先学会高质量地使用AI来完成编码任务。

真正ROI最高、见效最快的方式，是先让AI Coding运转起来，再让护栏随着实际需求逐步生长出来。

文中涉及的项目叫Vibe Flowing，是一个业务属性很强的"AI原生海外网络运营平台"，主要服务于海外网络运营相关的业务场景。

所谓"AI原生研发"，在这里指的是：项目的所有组件和能力，包括页面功能、定时任务、Agent智能体、开放API、外部接口对接等，都由AI统一维护。

使用者只需要描述需求。简单需求可以通过对话直接完成；复杂需求则先写成文档，经过研发流程对齐后再进行开发。

在这套机制下，团队里不管会不会写代码，每个人都能参与进来。网络运营同事即使不是开发人员，也能完成提需求、写代码、做验收的完整流程。

这正是AI赋能团队最直观的体现：当门槛降得足够低，人的参与面自然就打开了。

问题在哪

在聊具体做法之前，先说说为什么要这么做。

VibeCoding的门槛已经很低了。网络运营同事用各类AI编码平台，自己就能写个网页，查查数据、画个图表，满足一时之需。但用着用着问题就来了：

1、重复造轮子、数据不互通、只有自己说得清

每个人写的网页都在各自调用后端系统接口：运营的、网管的、CMDB的、SNMP的，各写各的，互不知道。同样是查一条专线的信息，张三的页面查一遍，李四的页面又查一遍，鉴权方式、数据口径还不一样。更麻烦的是数据散落在各个孤岛里，没法关联分析。比如专线流量异常了，想同时看流量趋势、丢包率、运营商质量，得开三四个页面来回切，数据还对不上。

有人尝试把这些页面聚合到一个入口里，放个超链接列表方便大家跳转。但说实话，这有点草台班子：链接越来越多，页面风格五花八门，哪个是最新的、哪个还能用、哪个出了问题找谁，谁也说不清。时间一长就成了"历史遗产"，没人敢动也没人想动。

2、想正经做点事，拦路虎太多

运营同事真想做一个能持续用的系统，第一道坎就是各种系统接口权限的申请。网管系统要开权限，CMDB要开权限，数据库要开账号，每一个都是流程、审批、等待。好不容易权限拿到了，接口文档不全、字段含义不清、鉴权方式各异，AI想帮忙对接也经常踩坑。出问题了让AI排查，一通操作猛如虎，token烧了不少，往往还没问到点子上。

因为这些底层问题的复杂性远超业务逻辑本身，AI在没有上下文的情况下很难高效定位。

说到底，Vibe Coding适合写"一次性"的东西，但做不了"能持续迭代的系统"。缺的不是AI的能力，而是一个专业开发先搭好的架子：日志、鉴权、权限控制、外部接口封装、数据库变更流程、定时任务等，都得先打通。有了这个底座，AI在上面开发就不必每次从零开始，也不在基础设施问题上浪费时间和token。

这就是做VibeFlowing的出发点：先搭好企业级底座，再让AI在上面持续开发，把整个团队的能力边界往外推。

不只是专业开发干活更快，非开发人员也能参与建设真正有用的业务系统。

效果概览

展开讲具体做法之前，先看两个实际跑通的场景，感受一下"AI原生研发"到底是什么体验。

场景一：AI原生的研发整体流程

运营同事想加一个新功能，比如"出口流量按AS聚合的桑基图"，他不需要写需求文档，不需要找开发排期，自己就能搞定。

首先，从模板创建一个anydev开发容器，不需要手动配置任何东西，打开CodeBuddy后直接告诉AI需求："我想在流量分析页加一个出口流量按AS聚合的桑基图，能看到Top 20 AS的流量分布。"AI先和他对齐需求：要展示哪些维度、数据从哪来、放在页面哪个位置，用白话聊几句就确认了。

然后AI开始开发。后端接口、前端组件、数据库查询，全栈一把梭。开发过程中AI自己启动开发服务、自己跑测试、自己查日志排错，不需要人介入。开发完成后，AI告诉运营同事开发服务的访问地址，让他自己在浏览器里验证。

运营同事打开链接，看到效果满意了，回一句"OK"。AI自动跑完静态检查和兜底测试，推送代码到远程分支，创建MR，等管理员审批合并到统一环境（正在引入AI审批）。在合并之前，运营同事在自己的开发容器上就能正常使用这个功能，不用等流水线跑完。

整个过程，运营同事没有写一行代码，没有碰过git，甚至不需要知道"分支"这个概念。

下图是Vibe Flowing项目仓库提交记录，可以看到，架子搭好之后，整个团队都能接住AI来实现自己的需求。

这套AI原生的开发体系已经在海外网络运营、控制器运营团队应用，团队基于统一的AI研发基础设施，能够在3分钟内全自动完成环境配置，人人可以参与开发。

场景二：AI原生的Agent开发流程

运营同事想做一个专线质量分析智能体，按照已有Agent平台配置开发的方式，得等其他研发同事把MCP或者Skills开放出来，然后他得自己写提示词、配工具，还得自己跑验证，整个过程非常费时间。

现在在这套体系里，他只需要跟AI说："我想要一个能分析专线质量的Agent，输入专线ID，它自动查流量趋势、丢包率、时延数据，给出质量评估结论和异常原因。验收标准是：随便选一条专线，它能在30秒内输出结构化的分析报告。"

AI拿到这个目标后，自己去代码仓库里探索：

• 看看现有的数据模型有哪些
• 有哪些service可以复用
• 哪些工具函数能直接用

然后自己写系统提示词，定义Agent的行为规范和输出格式；自己封装工具函数，把数据查询能力接进来；自己注册到Agent框架里。

接下来是调试，AI自己跑端到端验证，选一条专线试一下，看输出效果。不满足验收标准，就调提示词、换模型、改工具返回格式，反复迭代。

整个Agent的开发过程AI自己跟自己对话、自己验收，不需要人盯着。

达到效果后，AI交给运营同事一个能用的智能体。运营同事到网页上的Agent聊天页，选这个专线质量Agent，直接就能用。

下面是一个例子：

1、自然语言描述需求：

2、AI编码实现并进行自主测试迭代

3、Agent对话效果：

小结

这两个场景的共同点是：人只管定义要什么，AI负责怎么做。这就是团队理解的AI原生研发：不是一个人的提效工具，而是一个团队的新工作方式。

从玩具到企业级

1、对接内部业务SDK

网平内部运营系统有很多接口，此前团队已经开发了Python版本的业务SDK，封装了各类第三方接口，比如网管系统、CMDB、SNMP乃至七彩石、日志等能力。在Vibe出来的项目中，首先要考虑的是集成这类SDK。

支撑现网运行的SDK此前固定了仅支持Python 3.6.8，去年团队做过升级到Python 3.12的探索，将基础依赖都进行了升级，可以直接在新项目中引入；如果是老项目，则需要提前处理好依赖的兼容性问题。

由于此SDK是私有包，需要在CI流水线中配置私有源认证。为了让Agent能理解SDK中具备的能力，将该SDK作为submodule的方式加入到代码仓库，实际编码时，让Agent自行探索即可，不需要额外写文档去解释每个接口。

对于一些日志、配置获取等基础常用能力，在IDE的Rules里写几行说明就行，比如"打日志用from nBroker.lib.logger import log"，AI记住后每次写代码都会用对。

2、通用底层能力

一个企业级运营系统应该具备几个通用能力，包括：

• 日志
• 页面权限控制
• 页面访问审计
• 开放API
• MCP工具
• 定时任务
• 工作流

这些能力每写一个项目都从头搭，成本太高。团队把它沉淀成一套标准设施，新项目直接继承。下面逐个说怎么做的。

日志：直接复用SDK中的统一日志方法，全项目统一调用签名，不自己造轮子。AI写代码时只需要在Rules里写一行说明就够了，不需要每次都教。

页面权限控制：实现了RBAC权限模型。用户的身份信息由太湖网关注入，后端解码后拿到login_name，再从人事系统查到部门和组。权限规则存在数据库里，支持按页面和操作两个粒度控制，管理员列表走七彩石远程配置，方便动态调整。这套机制对AI透明，AI写新页面时，只需要声明是否受限资源，权限校验自动生效。

页面访问审计：所有请求都经过鉴权中间件，用户身份、访问路径、API Token使用记录都落库留痕，方便审计追踪。

开放API：外部系统集成走API Token机制，支持Bearer Token和自定义Header两种方式。每个Token可以配置允许访问的路径白名单、管理员列表、过期时间。Token明文仅管理员可见，其他人看到的是掩码。这套机制让外部系统接入安全可控，AI也能自助创建和管理Token。

MCP工具：基于FastMCP搭建了MCP Server，把专线分析、拓扑分析等核心能力封装成MCP工具，供其他AI客户端调用。MCP路径在鉴权白名单中，方便外部集成。

定时任务：基于APScheduler实现了装饰器注册机制，新增定时任务只需写一个@cron_job装饰器函数，声明任务ID、执行间隔和描述即可。定时任务独立进程运行，不阻塞API。支持前端页面暂停/恢复/修改间隔/手动触发，多副本环境下通过数据库抢占保证一条指令只执行一次。AI新增定时任务时，只需要写业务函数，调度和管理的"脚手架"自动就位。

工作流：基于DBOS实现了简单的工作流调度能力，让平台能够支撑复杂流程的运行，这些流程中间可以有人工待办、异步回调等待，从而让一个复杂的任务能够持续跑一个月甚至更长时间而不间断，即使中断了也能从历史状态恢复，即所谓的Durable Function。

小平台内置这些能力，就意味着AI能够帮团队把这些都搞定，而不需要跨系统交互，这是AI原生研发的基础条件。

Harness工程实践

1、大仓组织形式

项目采用单仓monorepo的形式，后端flo/和前端web/在同一个Git仓库里。好处是AI在一次会话中可以同时看到前后端代码，做全栈改动时上下文完整，不需要跨仓库切换。

后端的目录结构遵循严格的分层约定：controllers（API层）→ services（业务层）→ models（数据层）→ source（外部接口），调用方向只能向下，禁止反向依赖或同层互调。此外还有analysis（数据分析）、cron（定时任务）、cli（命令行工具）、agent（智能体）等独立目录。这个约束写在AGENTS.md里，AI每次写代码都会遵守。

关键设计是每个职能目录下都有一个_framework/子目录，存放框架级的"脚手架"代码。业务代码只管写业务函数，框架代码负责调度和生命周期管理。这样AI写新功能时聚焦业务逻辑，不会被基础设施的细节干扰。

前端同理，components/按业务域分目录，每个组件配套Storybook story文件。views/只做组件协调，保持整洁。这套结构符合直觉，AI探索代码库时能快速定位，人也容易审查。

下面是前端组件化示例，可以看到积累了相当多可复用的组件，这些组件主要是按照业务模块划分：

2、用Rules和Skills给AI立规矩、装技能

大仓结构解决"代码怎么组织"，Rules和Skills解决"AI怎么干活"。这一环很关键，不做约束，AI每次都是"自由发挥"，质量全看运气；做了约束，行为就有了下限保障。

Rules：分场景加载的项目护栏

项目设计了多层Rules，按场景自动加载到AI的上下文中：

第一层是AGENTS.md，放在项目根目录。这是面向CodeBuddy IDE和With开发环境的通用规则文件，集中了所有开发护栏和工程偏好——文件红线、后端分层规范、前端工程约定、DB变更流程、流量图表配色、网络拓扑可视化偏好等。AI每次会话都会读这个文件，相当于随身带着一本"项目规范手册"。

第二层是.vscode/anydev_rule.md，这是面向统一研发容器的规则文件，会自动加载到每个开发同事的容器环境中。相比AGENTS.md侧重工程规范，anydev_rule更侧重研发流程约束和用户保护，核心是几条铁律：

• 三阶段流程不可绕过：任何需求，哪怕改一个文案，都必须走"需求讨论 → 开发实现 → 确认提交"三阶段，每个阶段之间需要用户明确确认，禁止AI自行判断"小改动可以跳过讨论"
• 用户是非专业开发：出现技术名词必须用白话先解释，方案先讲再动手，不让用户做选择题，拿不准就停下来问
• 分支管理对用户透明：用户不需要关心分支，AI全程管理（自动切到dev-$用户名分支、自动同步远程dev、自动处理冲突）
• Git操作护栏：禁止破坏性命令，改动范围最小化，删除文件前必须确认
• 产品同学常见误区主动提醒：比如用户说"把数据清掉"，AI要主动告知anydev账号没有DELETE权限，建议改用软删除

第三层是CodeBuddy内网版插件的记忆系统。项目规则中有一部分以Memory形式存在，比如"数据库时间字段统一用DATETIME"、"前端代码修改后必须跑type-check"、"流量图表入流量绿色、出流量蓝色"等。这些记忆会在AI相关场景自动触发，不需要每次重复说明。

三层Rules叠加，基本覆盖了"AI在这个项目里什么能做、不能做、怎么做"的全部约束。设计原则就一条：规则集中、分场景加载、不重复。AI上下文有限，规则散乱或重复既费token又容易让AI混淆。

关键Rule：Anydev云开发护栏以及开发示例如下，左侧文件目录中可以看到有4个关键开发约束，右侧是AI完成开发后交给人验证时回复的效果：

Skills：给AI预装"专业技能包"

Rules管的是"规矩"，Skills管的是"能力"。团队沉淀了一批常用Skill，覆盖项目开发的高频场景：

• Agent创建：新增ReAct Agent的完整工作流，探索代码、写提示词、创建工具、注册、验证
• 工作流创建：基于DBOS的工作流编排，处理需要持久化和重试的复杂任务
• Changelog发布：生成changelog条目并创建git tag，处理版本发布
• 前端设计：创建有设计质量的前端界面，避免"AI审美"的通用感
• Vue开发：Vue3 + Composition API + TypeScript的开发规范和最佳实践
• 工蜂：代码平台操作，仓库管理、合并请求、代码审查、Issue管理
• 代码腐化处理：这个特别重要，AI原生研发跑起来之后，代码仓库的演进速度会特别快，但硬币的另一面是代码腐化也来得更快，团队创建了2个职责分离的代码去腐化技能，扫描代码问题、创建issue，以及认领issue、修复代码问题，避免"既当裁判又当运动员"。让Agent高频小批量定期运行这两个技能，保障仓库代码质量
• iWiki：企业内部文档的检索和编辑
• 技能创建：创建新的Skill或优化已有Skill

这些Skill在CodeBuddy内网版插件中会自动加载。AI在遇到对应场景时自动触发，不需要人手动调用。比如用户说"新增一个专线质量分析Agent"，Agent创建Skill就会自动激活，AI按照Skill里定义的工作流一步步执行：先探索现有代码理解数据模型，再写提示词和工具，然后注册和验证。

Rules和Skills的关系：Rules保底线（不犯错），Skills提效率（干活快）。光有Rules，AI不犯错但每次得摸索怎么干；光有Skills，AI干得快但可能不合规范。两者一结合，AI既守规矩又高效，人的介入成本就降到最低。

3、TDD实践与取舍

TDD（测试驱动开发）在AI编码场景下有一个微妙的问题：AI写测试很快，但也很容易写出"自欺欺人"的测试，例如只覆盖happy path，或者断言太弱。团队的做法是用规则约束来兜底，而非追求严格的"先写测试"。

后端用pytest，前端用vitest做组件测试、Playwright做E2E。提交前必须通过静态检查：后端跑ruff（代码风格）+ ty check（类型检查），前端跑oxlint + vue-tsc。这些检查命令都写在AGENTS.md里，AI会自觉执行。

关于"前端功能测试能否覆盖后端"这个问题，经验是：前端E2E测试能验证整条链路（前端 → API → DB），对于业务逻辑的正确性保障是有价值的。但后端单元测试的价值在于快速定位——E2E挂了你不知道是前端渲染问题还是后端逻辑问题。所以团队的取舍是：核心业务逻辑必须有后端单元测试，前端E2E主要覆盖关键用户流程，两者互补而非替代。

覆盖率目标定在70%，作为参考值不阻断。重要的是改动的文件要有测试覆盖，而不是盲目追求数字。

实际操作中，更看重"验收"而非"测试"。对于网络运营同事提的需求，最终验收标准是"页面表现符合预期"，这个验收过程本身就是在做端到端验证。AI开发完一个功能后，用Playwright headless截图验证，再交由提需求的人确认，形成闭环。

4、轻量SDD

SDD（Spec Driven Development，规格驱动开发）听起来很重，大家一般会使用各类开源Spec框架来保障整体流程，但团队用一套极简的文件命名约定就实现了类似的效果。

核心思路：需求文档就是开发的唯一输入。简单的需求直接对话，复杂的写成Markdown文档，AI读完文档后讨论、开发、验收。

文档流转规则：

• features/目录存放需求文档，按draft_→ready_→done/三阶段流转
• draft_前缀：未确定的方案，AI和人一起讨论迭代
• ready_前缀：方案对齐确认，可以开始开发
• 开发完成后移到done/目录

方案讨论文档放在ai_docs/running/目录，同样遵循draft_→ready_的命名约定，完成后移到ai_docs/done/。

这套机制的好处是：AI一次会话中读完一个ready_文档就拥有了完整的需求上下文，不需要人来反复解释。而文档本身也是AI协助写的，运营同事口述需求，AI整理成结构化文档，开发同事review确认后，AI改前缀为ready_，并开始开发。

一句话：文档命名约定就是工作流。不用额外的项目管理工具，文件名本身就在表达状态。

5、封装CLI工具

AI在开发过程中经常需要做一些"运营性"操作：执行DDL、回填数据、管理配置。如果让AI自己写临时脚本去import db跑，既不安全也不留痕。团队给AI封装了几个CLI工具，让这些操作有规可循。

flow-db-exec：数据库变更执行工具，是DB变更的唯一入口。支持单条SQL执行和按文件行号片段执行两种方式，还有dry-run干跑模式。这个工具做了三件事：一是高危关键字（DROP/DELETE/TRUNCATE）硬拦截，和数据库账号权限互为双保险；二是强制留痕，SQL必须先写到changelog.sql再执行；三是执行结果清晰可读，SELECT结果格式化输出，写操作返回受影响行数。

flow-config：业务配置管理工具，支持增删改查和按前缀过滤，配置存在数据库里，方便运行时动态调整。多说一句：很多团队习惯把所有配置丢到远程配置中心去管，但实际用下来会发现，评审发布流程比较繁琐，配置和代码分属两个系统，割裂感强，AI也很难直接操作。其实大部分业务配置，例如阈值、开关、参数等，没那么敏感，没必要搞那么重。项目直接用内部的数据库表管，配一个CLI加一个管理页面就够了。配置和代码同在一个仓库，AI能直接读写，改完即生效，不用跨系统走流程。Key按模块分层命名（如threshold.surge_ratio），同模块配置聚合成dict读取，代码里统一走app_config模型，不直接拼SQL。这套机制轻量、透明、AI友好，运营同事也能在页面上自助改。

run-cron：定时任务独立进程入口，只启动调度器不启动API，避免重任务阻塞线上接口。

这些CLI工具的设计理念是把高频运营操作封装成"安全、留痕、可重复"的命令，AI用着高效，人审查也放心。AI不用理解底层连接、事务这些细节，调一个命令就行。

6、前端组件化

前端组件化是老生常谈，但在AI编码场景下有一个特殊价值：组件化让审查变得可行。

如果一个Vue文件有1000行，AI改了一处，人很难快速判断影响面。但如果拆成100~200行的子组件，每个组件职责单一，AI的改动通常集中在一两个组件里，审查时只需看这几个文件。

项目的规则是：

• Vue SFC控制在500行内，超过即拆
• 独立功能域抽子组件，可复用逻辑抽composable，工具函数移utils/
• 子组件100~200行，composable 30~70行
• 所有组件配套Storybook story

最后一条特别重要，目前项目里有143个story文件，覆盖了几乎所有组件。Story不只是给设计师看的，更是给AI和开发者提供的"组件说明书"，这是因为story里定义了组件的各种状态和props组合，AI开发新功能时可以先看story了解已有组件能力，避免重复造轮子。开发完新组件后补story，也相当于做了一次自测。

页面视图层走"智能组件 + 展示组件"模式。View层只协调，把专线ID、出口ID、时间范围传给子组件，每个数据卡片自己fetch、自己渲染。View层保持整洁，新增卡片不会让主文件膨胀。

这套约束写在AGENTS.md里，AI写前端时会自觉遵守。偶尔超了，提醒一句就拆好了。

7、让AI看见问题

AI编码最大的风险不是写得慢，而是写错了不知道。让AI能"看见"问题是质量保障的关键。

团队的做法分四层：

第一层：静态检查即反馈。后端ruff + ty check，前端oxlint + vue-tsc，这些工具的输出AI都能直接读到。AI写完代码后自己跑检查，有报错自己修。这比等人来review高效得多。

第二层：AGENTS.md汇总规则。项目根目录的AGENTS.md集中了所有开发护栏和工程偏好，包括文件红线、分层规范、代码风格、DB变更流程等。AI每次会话都会读这个文件，相当于有一个"项目规范手册"随时可查。规则越集中，AI遵守得越好。

第三层：开发服务AI自主管理。项目通过一个dev.sh脚本统一启动前后端开发服务，这个脚本本身就是AI写的，后续怎么改、日志在哪儿看、进程怎么查，全部交给AI管理。开发者不需要记这些细节，跟AI说一声"启动开发环境"或"看下后端日志"就行。AI对开发环境的掌控力越强，自己发现和解决问题的能力就越强。

第四层：Playwright验证。AI开发完功能后用Playwright headless截图、检查API请求、验证交互行为。这相当于AI自己做了一遍QA。

四层叠加，大部分问题AI会话内就能发现和修复，到人审查时已经比较成熟了。

8、DB变更管控

DB变更在生产系统里是最敏感的操作。团队设计了一套"极简、透明、可验证"的流程。

极简：所有DDL/DML通过flow-db-exec一个入口执行，AI不需要写临时脚本。常用的加字段、加索引、按主键更新，直接执行后告知即可。

透明：任何变更必须先落到changelog.sql（注明日期与目的），同步更新主结构定义文件，然后按行号执行刚追加的片段。这样变更历史可追溯，新环境重建数据库也有完整记录。

可验证：按风险分级处理。

操作	处理方式
加字段、加索引、按主键单行UPDATE	直接执行后告知
ALTER改字段类型/名/删字段	先讲方案，用户确认后再执行
不带主键的批量UPDATE	先SELECT COUNT(*)评估，确认后执行
DROP / DELETE / TRUNCATE	硬拦截，改用软删除或人工执行

时间字段统一用DATETIME，禁止BIGINT时间戳，方便运营同学理解。AI在数据库操作上有清晰边界感，既高效又安全。

9、Agent工作流

Agent智能体是这个项目的重要能力。这里想重点分享的不是Agent框架的技术细节，而是AI原生的Agent研发方式。

传统做法是：开发者手动搭建Agent平台，在某个管理后台配置提示词、注册工具、设置参数，再把能力暴露出去。这种模式下，每新增一个Agent都需要人在多个系统间来回操作，维护成本高，迭代慢。

说起来有点意思，此前团队牵头搞过一个智能体平台，主打配置化，拖拽填表就能搭Agent，上线比Knot还早。但现在AI写代码能力大幅提升之后，也许没必要整那么重，直接用代码描述Agent：提示词是文件，工具是函数，注册是装饰器。Everything as Code，这才是AI原生的研发流程。

团队的做法完全不同：给AI一个业务目标，让它自己基于现有代码仓库端到端地完成Agent的创建。

具体来说，当需要一个新Agent，例如"专线质量分析"，只需要跟AI说清楚这个Agent要解决什么业务问题、应该具备什么能力。AI会自己完成全部工作：

• 探索代码仓库，理解现有的数据模型、服务接口和工具能力
• 编写系统提示词，定义Agent的行为规范和输出格式
• 复用或创建工具函数，把需要的数据查询和分析能力封装成Agent可调用的工具
• 在注册表中登记，接入统一的会话管理和流式输出框架
• 补充Storybook story做验证

整个过程不需要去任何外部系统手动配置，不需要在管理后台填表单，所有产物都在代码仓库里，可追踪、可review、可回滚。

这里有一个更深层的设计理念需要强调：系统中有什么能力，AI自己去看。项目的所有内容，包括数据模型、服务接口、工具函数、Agent提示词、前端组件、定时任务等，都在同一个代码仓库里，AI都可以获取到。这就是面向AI原生的设计：不把能力藏在某个管理后台或外部系统里，而是全部以代码形式存在，让AI能直接探索、理解、复用。

传统的智能体组织形式是"平台 + 后台配置"：Agent平台是中心，工具和提示词在管理后台维护，人要去后台注册和配置。这种模式下，AI看不到全貌，每接一个新能力都需要人手动"告诉"平台。而团队的做法是"代码即配置"：Agent的提示词是代码文件，工具是代码函数，注册是代码装饰器。AI需要什么能力，直接在代码仓库里找，找到了就能用。不需要任何中间环节。

这种设计带来的好处是显而易见的：AI新增一个Agent时，不是在白纸上画画，而是在一个已经充满能力的生态里"搭积木"，看到有现成的流量查询service就复用，看到有现成的图表渲染工具就直接接，看到有其他Agent的提示词写法就参考。整个过程的效率，远高于在管理后台从零开始配置。

这背后的支撑是团队在框架层做了统一抽象：一个ReactAgent基类负责模型配置、上下文注入、流式事件输出、会话持久化等通用能力。新增Agent只需关注三件事：叫什么名字、系统提示词是什么、有哪些工具，基类和注册机制把其余的都包了。

还有几个设计细节值得提一下：

1、Agent通过SSE流式输出，支持断连重连，客户端刷新页面后能从上次断开的位置继续，跑几分钟的分析任务中途刷新不会丢失；

2、工具沉淀有一个重要约定：工具返回值尽量是markdown字符串而非原始JSON，一来Agent更好理解，二来大幅减少token消耗，此外人在页面上也看起来更方便。

下图展示了Agent创建技能的部分内容，完整内容的可以去文末的原始代码仓库中查看：

AI原生的Agent研发方式，核心价值就是：人只关注业务价值，即这个Agent要解决什么问题、输出什么结论。

至于提示词怎么写、工具怎么对接、框架怎么注册，全由AI端到端搞定。人的精力花在定义"对的问题"上，而不是"对的配置"上。

10、Anydev统一研发环境

前面讲的Rules、Skills、CLI工具都是"AI怎么干活"的护栏，但还有一个前提问题：开发环境本身怎么准备好。

传统模式下，一个新同事加入项目，光是准备开发环境就要折腾半天。比如装系统依赖、装Python和Node工具链、配置私有源认证、生成环境变量文件、装前后端依赖、启动开发服务。每一步都可能踩坑：系统包版本不对、私有源地址记不住、环境变量漏配导致服务启动报错。对非开发同事来说，这道门槛几乎不可逾越。

团队用一套自动化初始化脚本解决了这个问题。基于公司的Anydev云研发容器，开发环境在容器启动时自动完成全部配置，从创建容器到可用，3分钟以内，全程零人工介入。

具体实现在scripts/system/setup.sh，按顺序串起7个子步骤：

第一步：上报开发环境。容器启动后第一时间把自己的IP、前后端服务地址、开发分支等信息注册到项目的devops管理页面。这样运营同事在网页上就能看到谁的开发环境在线、地址是什么，直接点链接就能验收功能，不用问"你的开发环境地址是多少"。

第二步：安装系统依赖。自动安装mysql-devel、gcc、gettext等编译和运行所需的系统包。考虑到容器内dnf偶发网络抖动，做了最多3次重试。

第三步：安装工具链。安装uv（Python包管理）和pnpm（前端包管理），以及rtk（内部研发工具）。装完立即source环境变量，让后续步骤的当前shell就能用。

第四步：注入开发规范。把.vscode/anydev_rule.md拷贝到.codebuddy/rules/目录。这样AI在容器里一启动就自动加载项目规范，不需要人手动配置，前面讲的三层Rules中的第二层就这么自动就位了。之所以做延迟加载，是为了区分平台基础能力开发、业务逻辑开发这两个场景，让专业开发不受限制。

第五步：渲染private.env。项目的私密配置（七彩石Token、Git私有源认证、UV私有源账号等）不能明文提交到代码仓库，团队用private.env.template模板 +envsubst在容器启动时渲染生成。模板里用${VAR}占位，容器环境变量注入实际值。渲染前会校验所有必填变量，缺一个就直接报错退出，不会生成一个"半残"的配置文件让后续服务启动时才报莫名其妙的错。

第六步：安装项目依赖。后端uv sync、前端pnpm install，一条命令搞定。前端安装时一次性放行onlyBuiltDependencies的构建脚本，避免后续启动时因ERR_PNPM_IGNORED_BUILDS退出。

第七步：启动开发服务。调用dev.sh启动前后端开发服务，等待端口就绪后打印访问地址。dev.sh本身也做了端口占用检查、进程管理、日志重定向，支持start/stop/restart/status四个命令。

这套脚本的设计有几个关键点：

一是每步独立、可单独执行。7个步骤各自是独立的shell脚本，放在setup_steps/目录下。调试某个步骤时可以单独跑，不用每次从头来。

二是失败即停、原因清晰。每步都set -e，任何一步失败立即中断，并打印具体的错误信息。比如private.env渲染时缺变量，会列出具体缺哪些变量名，而不是生成一个有问题的文件让后续步骤报含糊的错。

三是幂等可重跑。脚本设计为可重复执行，已经装过的不会重复装，已经在运行的服务不会重复启动。

这套机制的效果是：任何同事，不管会不会写代码，从Anydev模板创建一个开发容器，等几分钟就能拿到一个完整可用的开发环境。前后端服务已经启动，AI已经加载了项目规范，私有配置已经就位，开发分支已经切好。打开CodeBuddy直接说需求就行。

这和前面讲的"通用底层能力"是配套的：通用底层能力是代码层面的基础设施，Anydev统一研发环境是环境层面的基础设施。两者叠加，才让"AI原生研发"对整个团队真正可用，不是"理论上能用"，而是"打开就能用"。

三、开发与产品协同

页面评论到自主开发

这是团队在"AI原生研发"上最有代表性的实践：让不懂开发的网络运营同事也能直接提需求，AI自主完成开发。

具体机制是这样的：

页面级评论系统。团队在每个页面植入了评论功能，运营同事可以在页面上任意位置圈点评论。评论会记录页面路径、元素定位信息（xpath、html片段、元素坐标），还能附带截图。这相当于一个"所见即所得"的需求提交工具。运营同事看到哪里有问题，直接在页面上标注，不需要写需求文档，不需要懂技术术语。

评论状态流转。评论有open / resolved / closed三种状态，开发同事确认后改为resolved，上线后改为closed。整个流程在页面上可见，运营同事能随时看到自己提的问题处理到哪了。

复杂需求走SDD流程。如果评论背后的需求比较复杂，开发同事会把评论内容整理成features/下的draft_文档，AI读完文档后参与讨论，方案确定后改为ready_，AI自主开发，最后由提需求的人验收。

开发容器自助注册。每个开发同事有自己的开发容器，容器启动后自动上报环境信息（前后端地址、分支等）到devops管理页面。运营同事可以在开发容器上提前验收功能，确认没问题再合并上线。

一个例子：

核心价值是把需求提报门槛降到最低。运营同事不用学任何开发工具，页面上圈圈点点就能提需求。AI把需求翻译成代码，开发同事负责review和兜底，每个人做自己最擅长的事。

四、Lessons from AI Coding

1、避免廉价习得感

用AI写代码久了，容易产生一种"我也会编程"的错觉。这种廉价习得感是危险的。

实际上，AI写出来的代码如果人不理解，就没办法做好审查，质量就没办法保障。团队要求成员学习一些基本的开发术语和概念：什么是分层架构、什么是ORM、什么是中间件、什么是SSE。不是为了让大家都会写代码，而是为了能看懂AI写的东西，能给出有质量的反馈。

"这个函数职责太重了，拆一下"、"这个逻辑应该放service层不是controller"、"这个SQL没走索引"，这些反馈比"感觉不对，你再看看"有用得多。AI的输出质量很大程度上取决于人的反馈质量，而人的反馈质量取决于对开发概念的理解程度。

经验是：运营同事不需要会写代码，但需要能读懂代码的大致逻辑。花一点时间理解基本概念，会让AI协作的效率提升一个量级。

2、给非开发者一张"能力地图"

上面说的是开发侧要学概念，其实在用户侧，即使用这个系统的网络运营同事，同样面临"概念不清"的问题，只是维度不同。

运营同事不需要懂代码，但他们需要懂"产品语言"。比如页面上每个区域叫什么：导航栏、面包屑、侧边栏、主体内容区、弹窗、抽屉……这些在前端开发里是常识，但对运营同事来说并不直观。如果一个人连"把侧边栏收起来看看"都听不懂，那和AI协作提需求时就会有很多沟通损耗。

更关键的是，运营同事需要知道这个项目整体具备什么能力。系统有几十个页面、十几个Agent、若干定时任务和开放API，散落在各处。如果运营同事不知道系统已经能做什么，提需求时就会要么重复提（"能不能加个出口流量对比"，其实已经有了），要么不敢提（不知道这个系统能做这么复杂的事）。

团队的办法是做了一份能力地图，一份结构化的文档，把整个项目的功能模块、Agent能力、定时任务、开放API按业务域分类罗列，每个能力附一句简要说明。运营同事读一遍，就能对"这个系统能做什么"有个整体认知。

成本很低，AI几分钟就生成完了，但效果是显著的：读完能力地图后，运营同事提需求时明显更"有的放矢"了，大家知道哪些是已有能力的微调，哪些是真正的新功能；和AI对话时也能更准确地描述上下文（"在流量工作台页面的分光TopN卡片这里，我想加一个……"），AI理解起来也更高效。

总的来说，AI原生研发要降低的门槛，不只是"写代码"，还有"理解产品"。能力地图这类轻量文档投入不大，但对非开发者的参与度提升很明显。

3、省token

最后聊一个工程性强但很重要的话题：如何省token。

在AI原生研发模式下，token消耗是实打实的成本。一次会话如果上下文太大，不仅贵，还慢。团队在实践中总结了几个有效的做法：

AGENTS.md集中规则。项目规范写在一个文件里，AI读一次就够了，不需要在每个文件里重复说明。规则集中也意味着AI不需要到处翻找约定。

工具返回markdown而非原始数据。Agent工具返回格式化好的markdown表格或摘要，而不是原始JSON。一来Agent更好理解，二来大幅减少token消耗，一个格式化表格可能200 token，而原始未经整理的JSON可能得花10倍。

CLI工具替代临时脚本。flow-db-exec一行命令搞定的事，不需要AI写50行Python脚本去import db、建连接、执行SQL、格式化输出。命令的输出本身就是精简的。

大仓 + 语义搜索。单仓monorepo让AI一次会话能覆盖全栈，配合语义搜索快速定位相关代码，减少"到处找文件"的探索开销。

SDD文档驱动。复杂需求写成文档，AI读完文档就有完整上下文，不需要人在对话里反复补充信息。文档也比对话历史更精练。

组件化 + Storybook。AI开发新功能时先看story了解已有组件，避免重复实现。组件拆得小，AI每次改动的范围也小，上下文不需要加载整个大文件。

探索一些可行的工具。比如RTK（Rust Token Killer）等技术，不过验证下来之后，发现效果一般，偶尔压缩时还会出bug，一些压缩策略还会导致语义混淆，就不用了。绝大部分Bash命令都能通过参数来精确控制输出啥，这些AI抖动，没必要再整一个新的。

省不了几块钱，还让AI再依赖一个不稳定的命令行工具，得不偿失～

小结

说到底，AI原生研发不是把所有东西丢给AI，而是搭好一套让AI高效干活的基础设施和协作机制。基础设施越好，AI产出质量越高，人的审查负担越轻。这是个正向循环，值得在工程上持续投入。

五、总结

回看全文，AI原生研发的核心可以归纳为一句话：搭好底座，让AI在上面高效干活，让团队里每个人，不管会不会写代码，都能参与建设。

具体来说，团队做了三层事情：

第一层：基础设施。把日志、鉴权、权限控制、开放API、定时任务、MCP工具这些通用能力沉淀成标准设施，新项目直接继承。业务SDK以submodule形式集成，AI自行探索理解能力。这一层的价值是：AI开发新功能时不需要从零搭基础设施，也不会在底层问题上浪费token。

第二层：工程护栏。大仓分层 + AGENTS.md规范 + anydev_rule流程约束 + Memory记忆系统，构成Rules三层护栏；Agent创建、前端设计、Vue开发、工蜂等Skills预装技能包。配合CLI工具、DB变更管控、TDD验收闭环、SDD文档驱动、组件化 + Storybook，让AI既守规矩又高效。这一层的价值是：AI的行为有下限保障，人的审查负担降到最低。

第三层：协作机制。页面评论提需求、Anydev统一开发模板、能力地图降低理解门槛，让网络运营同事不写代码也能参与建设。Agent研发走AI原生路线，给目标，AI端到端完成，网页直接可用。这一层的价值是：需求提报门槛降到最低，每个人做自己最擅长的事。

三层叠加，形成正向循环：基础设施越好 → AI产出质量越高 → 人的审查负担越轻 → 人有更多精力优化基础设施。不是一蹴而就的事，是在实践中持续迭代的结果。

针对已有的存量项目，团队正在按照这套方案，构建大仓、搭好Harness工程骨架，让更多业务也能参与到开发中来。

这套方案不是AI研发的终点，而是AI时代开发和产品协作的新的起点。团队还在路上，但方向是明确的：不是让AI替代人，而是搭好一套让AI和人都能高效发挥的体系，把整个团队带到下一个台阶，即「AI原生的研发&运营团队」。