笔者所在的团队是从事后端开发方向，在业务发展的过程中涉及到大量的在线表格元数据管理工作，因为涉及到多团队多业务的协作，在线表格形式的协作方式弊端逐渐显露且效率低下。

于是我们想要开发一个好用易用的元数据管理平台，该工作涉及到大量的前端开发，现在借助AI工具，可以摇身一变成为全栈工程师。

5.1 需求背景：

在当前业务阶段，数据库监控告警中台与业务侧交互，进行元数据录入（监控指标、监控事件、默认告警策略）时，主要依赖在线表格进行交互。 交互表格如下示例：

这样的交互方式存在一些问题：

1、字段过多，虽然有相应的文档进行说明，但是理解成本还是较高。

2、字段值缺少校验，如果填写错误或不规范，在后置流程中才能发现，需要反复修改，效率低下。

3、元数据的呈现不够直观，如指标之间的展示顺序需要等一体化环境部署出来之后才能再进行调整，调试成本过高。

4、版本管理困难，在线文档会记录所有表格的变更，难以溯源，并且表格呈现的永远是最新的数据，发布的版本也得通过部署环境来review，并且对于不同的环境往往需要衍生多份表格做隔离，如公有云版本、私有云主线版本、私有云LTS版本的配置都不同。

5、权限管理较弱。

6、出包流程繁琐，公有云已经接入流水线进行出包，但是在私有云，由于私有云存在一些逻辑调整（策略分片之类），当前出包还是由人工手动出包，流程较为繁琐。

基于以上现状，我们通过公司提供的AI工具进行了一些尝试，开发了系统初版。

5.2 快速原型：使用CodeBuddy IDE构建初版元数据管理系统

5.2.1 需求拆分

高效利用AI coding最核心的点就是拆分需求，功能点之间一定要做到模块化，尽量减少模块之间的依赖，功能交互之间尽量做到树状呈现而非网状呈现，因为当功能模块之间依赖过于严重就会导致AI在进行修改模块A时，对模块B造成影响。 在第一次实现元数据管理工具时，主要的功能点拆分如下：

各个模块之间相互独立，仅有一些表单层面的参数传递，在逻辑上没有依赖，这样有利于项目后期的维护，对于AI来说，上下文能存储的信息是有限的，将逻辑功能做到模块化以后，AI后期只需要理解相应模块的代码就能进行开发，而不需要理解单个模块。

5.2.2 提示工程踩坑的实践

在初版开发时，尝试了多种方式，也踩了很多坑，在多次尝试、调整、重写后终于完成了第一版，以下是一些踩坑经历:

• 上下文崩溃：AI的上下文本质上是有限的，无法存储整个项目的信息，随着实践的深入，整个实践过程中的反复擦写上下文会导致关键知识丢失，从而使AI在下一步的输出结果逐渐脱离预期，并且这种“上下文崩溃”的现象往往是不可逆的，在得到错误的结果后，如果只是一味的让AI修正，只会适得其反。
  • eg. 以第一次实践为例，在实现到功能C时，前端界面和交互逻辑都已经完善，但是在实现功能D时，AI对整个项目造成了不可逆的破坏。

实现完功能C后的结果：

实现完功能D后的结果：

• 难以保持输出结果幂等：即便AI将文档拆分的足够完整，并且记录了每一次的训练结果，它仍然不能利用这个文档复现出当前项目，甚至完全不可用。
  • eg. 按照第一次实践时保存的文档直接训练的结果如下，仅有前端界面的交互，并且交互逻辑和第一次实践时的交互逻辑完全不同

• 二八定律：如果只是要AI实现需求的80%（整体框架），只需要花费20%的时间，但是需要完善剩下的20%的部分，往往需要花费80%的时间，还不一定能完成，容易出现“最后一公里”的问题，这个时候往往还是需要用户自身的知识储备才能提效。
  • eg. 现在想要调整前端的一些组件颜色,本质上只需要在前端更改一些颜色的值，但是在AI进行交互，可以发现，AI很容易错改或者漏改，导致优化一个很小的点却需要耗费大量的时间。

5.3 无缝协作：其他开发者加入协作

前面提到了初版系统完成了开发，但是在实际工作中，经常是碰到需要协作开发大型项目的情况，这里分享下开发者B加入项目，需要快速上手并开始贡献的场景以及vibe coding实践经验。

5.3.1 关键挑战：开发者B无法访问开发者A在CodeBuddy中的上下文记录

• 项目上下文初始化：开发者B克隆项目仓库。为了快速理解这个陌生的代码库，B在项目根目录的终端中运行了关键命令：codebuddy /init
  • 自动生成上下文：此命令指示Codebuddy Code扫描整个项目，分析其结构、依赖关系和代码模式，并自动生成一个Codebuddy.md文件 。这个文件成为了项目的“活文档”，包含了项目摘要、核心文件、推荐的bash命令和推断出的编码风格指南 。这完美解决了B没有A的对话历史的问题，因为Codebuddy Code直接从源代码本身重建了上下文。
    • eg. codebuddy /init 产生文档结果示例

项目结构以及技术栈说明

项目编码规范以及数据模型约束

开发者B在没有与A进行大量沟通的情况下，迅速掌握了项目的技术栈和架构，并准备好开始开发新功能。

• 实践经验总结：
  • 人为审核修正：文档的维护非常重要，模型在读取代码库生成上下文之后仍可能有偏差，需要人为审核并加以修正。
  • 项目演进与文档维护：在编码时可以指示大模型在阶段性工作完成后编写子功能文档并更新Codebuddy.md

5.4新功能开发与AI结对编程

开发者B在借助Codebuddy code了解项目后，需要为系统添加“权限管理”新功能。

5.4.1 实践流程：

• 规划（Codebuddy Code）：开发者B采用“计划优先”的工作流，向Codebuddy Code发出指令：“基于Codebuddy.md中的项目上下文，为‘权限管理’功能制定一个详细的实施计划。实现按product或者product+resource types 管理用户权限, admin用户默认拥有所有写权限;当不设置resouce type时,该用户拥有product级别所有权限; 先分析需求, 给出设计方案, 在获得批准前不要编写任何代码。”

• 执行（Codebuddy Code）：在B批准计划后，Claude Code自主执行，修改了多个前后端文件以实现该功能。B将代码提交到一个新的PR。

可以看到Codebuddy Code会按照设计方案列出执行计划Todo，并按计划修改相应文件并记录进度。

• Code Review（AI结对编程）：另一个AI工具（或会话）扮演审核代码的角色。基于相关的git commit，使用相应的提示词：“你是一位资深代码审查员。请审查此commit中的变更。对照Codebuddy.md中的规范，检查代码质量、安全性和一致性。特别关注新API端点的数据校验和前端按钮的交互逻辑。”

由一个AI（Codebuddy Code）实现、再由另一个AI（Codebuddy IDE或者新上下文会话）辅助审查的全功能模块。这个流程不仅展示了不同工具的优势互补，还模拟了人类的结对编程，利用一个AI的生成能力和另一个AI的批判性分析能力来提升代码质量 。

5.5 文档化

借助大模型的能力，可以及时、准确地为新功能生成文档。

提示词：“你是一名技术文档工程师。根据router.go中的Gin路由设置和GORM模型，为后端API的API.md文件新增一个‘数据导入/导出’的API说明，其中包含每个新API的请求/响应示例。”

一个结构清晰、易于理解且更新及时的项目文档文档。

5.6 AI Coding实践技巧总结

在利用AI coding时，可以参考如下实践技巧：

• Step by step：不要企图让AI一口气实现整个项目，按照需求拆分之后，需要明确各个模块之间的依赖关系，然后按照顺序让AI来实现。本质是Plan模式，建议分模块生成需求文档和设计文档，避免在一个过长的上下文中交互，可以将不同的模块开启新的上下文处理。
• 想清楚再下笔：AI和人之间的交互本质还是根据词向量去尝试理解并推测用户意图，所以有的时候，AI并不完全理解用户意图，尤其是在一些细节上，这里可以在和AI交互时，让AI等一等，复述它对需求的理解，并且在一些能够把控的细节上（比如指定用xx库来实现）尽量做到精细化，这样可以增加整个项目的可控性。
• 充分验证：完成一个模块之后，及时review，自动化测试可以交给AI来做，对于一些极端场景、边界条件，用户也需要及时验证，这样更容易发现问题。
• Git版本管理：AI coding本质上是一个黑盒，coding的下一步结果是不可控的，所以在完成一个阶段性成就之后需要及时提交。当AI出错时，尽量不要在已经犯错的分支上继续改成，在已经犯错的分支上持续改正容易造成局部收敛，从而破坏整个项目，此时需要及时回退，重新训练。
• 避免陷入问题低效修复循环： 功能生成后，人工调试总有bug，多次修复仍未果。此时应避免继续在当前上下文中处理（模型上下文用量过大时，模型表现会下降）