AI Native 回忆录：稳定性前端 S1 实践复盘

这是2026年的第 65 篇文章

（ 本文阅读时间：约 30 分钟 ）

开篇：从「AI Native」到真实交付

2026年春，「AI Native」在集团内部被频繁提及，但多数团队仍将其等同于「使用更先进的AI工具」。对于一支兼顾产品交付与研发范式探索的稳定性团队而言，AI Native意味着后端写前端、PM搭原型、设计师出代码的闭环能力。然而，效率提升的同时，交付质量与协作规范成为新挑战。

在一次代码评审中，后端同学提交的PR充斥着Tailwind类名、手写CSS及直接Fetch接口的组件。虽然功能可运行，但无法合入主库。这揭示了一个核心矛盾：以前担心做不出来，现在担心做出来的东西无法维护。

作为稳定性团队前端，笔者深度参与了「Agentic Ops智能体应急助手」与「AI Native研发模式转型」两项工作。本文将探讨当全员借助AI生产代码时，团队如何通过规则、协作机制与质量保障，将AI产物纳入真实交付体系。

01 AI，快与慢：能运行与能接手之间

——每个人都快了，然后呢？

AI Coding虽节省了生成时间，但对齐组件、处理旧代码衔接、评审与接手等后续工序的成本常被忽略。

风格不一致与原型浪费

AI倾向于基于开源语境（如Vite、Next.js、Tailwind）给出默认答案，这与线上存在的Ice + Fusion、Umi + Ant Design等历史技术栈冲突。导致的结果包括：

• 风格割裂：不同成员生成的页面布局、配色各异，缺乏统一性；已有组件库未被复用，出现大量手写实现。
• 原型失效：PD用AI生成的原型往往停留在演示阶段，前端需重新接入工程体系进行还原。开放了代码生产入口，却未移交团队判断标准，导致局部省时变为下游加班。

三条探索路径的局限

为解决上述问题，团队尝试了三种方案：

1. 全员培训：补前端基础课效果有限，因为决定上线质量的往往是课程之外的工程细节与历史包袱。
2. 建立知识库：文档难以覆盖所有技术债，且存在冲突仲裁难、检索成本高的问题。将规范塞入Prompt效果不佳，且易随上下文丢失。
3. 切换平台：接入Aone Super等一站式平台面临配置复杂、本地安装门槛高、任务连续性差及长期维护成本高等问题。

最终结论是：不能仅在AI写代码前做动作，而应让规则在代码产生的那一刻就到场。团队选择了Skill（结构化规则包）作为载体，将集中维护的规则命中场景后注入AI上下文。

02 无规矩，不成方圆：Skill与Plugin的实践

老师傅手上的判断，怎样交给AI？

确定使用Skill后，首要任务是盘点仓库。团队前端项目主要分为三类体系，各自的技术栈与约束不同：

Skill需先识别项目类型，再应用对应规范。an-frontend-skill包含五维结构：

• When：涉及React/TSX操作时自动加载。
• What：基于项目类型识别历史栈，减少分歧。
• Don't / Why：明确禁止项及其原因。
• How：提供最小可运行示例，如公共组件三段式、API调用双轨等。
• Map：按需加载设计Token、国际化等补充能力。

已跑通的场景

1. 平台升级改造：Umi 3升级至Umi 4，工期从月级压至周级，规范对齐工作接近零。
2. AIOps原型协作：引入Skill与设计直接AI Coding后，原型代码复用率从不足30%提升至80%。
3. 国际化改造：通过自动化流水线，两周落地原本需两个月的工作量。
4. 新建看板：Status云产品健康看板研发周期三周，AI代码采纳率80%。

从Skill到Plugin：Anchor工作台

随着Skill细化，安装依赖链变得复杂。团队利用Claude Code官方插件形态，构建了前端AI Coding工作台Anchor，将Skills、Commands、Agents等打包为可安装的Plugin。

Anchor分为三层：

配合Hook机制（如拦截npm install、记录会话活跃度）及显式触发命令/code-review，实现了人与AI使用同一份检查依据。Plugin安装时间从十分钟缩短至三十秒，显著减少了因缺依赖导致的失败。

03 和而不同：设计与前端的协作演进

——设计和前端的协作，为什么最终没有只留一套代码？

初期尝试让设计直接修改正式代码以消除还原差异，但因技术栈冲突、节奏不一及发版拆分成本高而失败。最终采取分库策略：

• 设计独立维护原型库aiops-studio，与正式库an-aiops物理隔离。
• 通过frontend-skill与design-skill约束原型产出的规范。
• 两个库共享规范但不共用发布节奏，降低试错心理成本。

新版工作流

设计工作流：MasterGo设计 → D2C转码 → 放入原型库 → AI调整 → 部署评审 → 交付代码

前端工作流：Code Review → 代码移植 → 微调适配

该模式将原本两三天的高频交互压缩至半天。除约20%的复杂交互场景外，80%的需求可走新链路。

VersionShell：版本隔离与管理

为解决多人协作时的版本覆盖问题，开发轻量工具VersionShell。各版本独立构建IIFE包发布至CDN，VersionShell按需加载。这使得原型具备代码资产生命周期，评审可随时回溯任意模块状态。

数据验证

04 君子不器：PDFE与有条件的全栈

——当一个人能做更多事，角色的边界在哪里？

PDFE：Product · Design · Frontend Engineer

在Agentic Ops项目中，前端工程师被迫承担产品、设计与开发全链路职责，形成PDFE角色。其核心在于独立闭环，大幅减少沟通成本，关键能力涵盖产品思维、设计品味与前端工程能力。

跨端协作的边界与风险

随着团队全栈转型，后端借助R2C写页面，前端借助AI写接口。但需注意：

• 结对编程必要性：跨端实现仍需领域专家支持，特别是服务调用链与数据一致性。
• 排期困难：陌生领域的环境配置与排障耗时难以预估。
• 评审与维护成本高：Reviewer需具备跨域知识，且跨端代码可能缺乏长期维护人。

因此，建议实行有条件的全栈：标准中后台页面可由非前端角色承接；核心链路与复杂问题仍由专家主导。关键在于将实践过程沉淀为团队可复用的方法。

05 授人以渔：从工具到能力沉淀

——事情做完，除了结果还能留下什么？

ai-drawio：从Prompt到Skill

将画图能力从独立Web App沉淀为Skill，用户可在Qoder或千问办公中直接生成标准.drawio文件，无需切换平台，实现了能力的无缝嵌入。

q-sketch：统一视觉风格

为解决配图风格不一问题，整理出适合技术博客的手绘风格Skill，包含铅笔线稿、暖色水彩及Q版人物设定，确保视觉辨识度与专业感。

效果展示（本文配图由本Skill辅助生成）

ata-article：写作规范Skill

将技术文章写作流程结构化，涵盖选题、大纲、事实填充、数据核对及去“AI味”自检。核心规则包括少陈述价值观、多写具体动作、数据朴素具体及避免概念堆砌。

AI故障查询助手与前端小助手

利用OneAgent与XOps ChatUI，两人一周跑通故障查询助手全流程，成为团队新AI业务默认脚手架。同时，集成钉钉、语雀等工具的“前端AI小助手”，实现了规范答疑、技术解答、进展查询及周报自动生成。

06 朝花夕拾：验证与反思

已发生的变化

2026年7月数据显示，团队AI Coding渗透率达100%，AI采纳占比79.6%，辅助代码量超120万行。部分成员单月AI采纳代码占比超95%，证明了AI已进入日常生产。

感觉快与真的快

研究指出，开发者常主观感觉AI提升了效率，但实际上可能因审查成本增加、不安全代码增多而变慢。针对此，团队加强了质量底线：

• 单测与发布卡点：行覆盖率稳定在80%以上。
• 复盘规则前置：从历史复盘中提取编码规则，理论故障拦截率达70%。

S2待验证事项

07 尾声：修好，还是体面？

引用《禅与摩托车维修艺术》中的故事：面对松动的车把，是用啤酒罐铝片垫上修好，还是为了体面宁可一直松着？

AI Native的实践中，Skill、Plugin、PDFE等工具或许看起来不够“体面”，但它们如同那片铝片，高效解决了当下问题。我们选择务实，因为解决实际问题比维持表面的完美更重要。

参考材料

AI 时代产研组织效能规模化提升实践

[2] 如何把超级个体的产能，转化成组织能力?

[3] 从超级个体到超级团队

[4] Agentic coding and persistent returns to expertise

[5] Sonar 调查

[6] METR 2025 年对照实验

[7] ACM CCS 2023 相关研究

欢迎留言一起参与讨论~