2.1  借助 AI 加速提升工程师视野、架构能力、规划能力

在团队内部落地 AI Coding 工具多或多或少都会遇到一些挑战，如：

不同开发者使用工具的效果/体验不一
每个人使用工具主观意愿不同
每个人的技能、工龄、能力存在差异
使用工具的习惯与驾驭工具的能力也不相同

而这些问题我们可以总结为"人的因素"， 我们认为只要肯下功夫、有意愿，一个个问题务实的去解决，"铁杆也能磨成针"。面对上述挑战， 我们首先解决的是人的主观意愿问题，主要 3 个方法：

强制开发 CodeBuddy 的团队开发同学用 Prompt 提示词，把短暂的抱怨化为动力，以此来提升自己的表达与思维方式等全局视野能力，实际上这是一件非常难的事情。
建立团队内部吃狗粮小群，自己吃狗粮，自己用的不爽自己来解决，倒推质量提升。
先从 AI 辅助写代码解缺陷、简单的需求开始进行，不断改变自己的研发习惯。

抛开主观意愿问题，我们也不断通过 AI 来加速提升工程师的架构能力、规划能力，并拓宽工程师的视野，持续提升我们对 AI 的驾驭能力，具体执行部分体现为：

• 借助 AI 快速提升工程师识别项目工程架构、规划能力，人主导技术取舍和最终验收

#Prompt 输入
我刚接手参与 codebuddy code 项目，我不熟悉本项目工程，请帮我理解项目系统架构，各个模块的API调用流程图及工作原理，帮我快速提升对项目工程的理解和快速上手开发需求。基于你的理解和我项目计划的安排，需要 1 天内支持/mcp 的需求开发，支持接入MCP Server，并给出具体的架构图、操作步骤、推荐方案和实施计划，以 MD 形式保存

• 把需求拆解为清晰正交的任务，使用 AI 辅助撰写和拆解执行计划

在进行用户需求拆解和研发过程，我们采用如下流程及示例：用户需求输入 → CodeBuddy 分析 → Agent 任务拆解/分析 → 计划生成 → 代码生成 →正交执行验证 → 追踪与持续优化，通过这套流程帮助我们正确拆解需求任务。

#Prompt 输入
 帮我在/cost 指令中加一个付费的链接，帮助用户可以实现快速的跳转查看付费链接页面，其中付费网站地址可能会存在变化，由于当前网站可能存在改版，不要写死，我希望付费链接用变量引入，10 分钟内要求完成并上线。

不同人开发技能与工龄等不一样， AI 辅助提升的效率也不一样，工程师个人的能力决定了他的下限，AI 工具提升人的上限， AI 工具可以在最把人的能力在最短的时间迅速提升、拉平， 而需要的是我们进行积极拥抱 AI，拥抱 AI Coding 工具，通过上述方式以及日常项目内的实战经验分享，从而不断提升团队战斗能力，解决人的影响因素。

2.2  用好提示词/知识库/上下文治理，精准生成代码

当我们谈论 “ 人与Agent 智能体” 协作时，我们实际上是在讨论一个由 模型 (Model)、工具集 (Tools) 和 执行环境 (Environment)、人共同协作的一个上下文系统环境。

在使用 AI 过程中影响 AI 生成效果的主要为三部分，即工具本身的 System Prompt（ 系统提示词）、模型、以及用户提示词（User Prompt），其中工具本身的 System Prompt和 User Prompt 组成一个上下文执行环境， 一般我们在与 AI 执行环境中，尝试切换模型自身，不断优化 Prompt 提示词，或补充私域知识库、约束规则以及切换模型来提升 AI 的生成效果。 如下一些方法，帮助我们解决上下文环境因素的问题，助力精准生成代码。

• 合理利用 Rules 规范提升代码精准生成

在与 AI 互动中， 一直希望 AI 具有长期记忆功能，为了让 AI 能够“记住”项目的关键信息和我们的特定风格偏好，我们在CodeBuddy Code 启动项目是，就推荐用户引入其核心的记忆机制--- CodeBuddy.md 文件系统。

#初始化项目，开启记忆功能，在 Terminal 终端执行
> /init

通过上面命令会自动分析整个代码库，并生成一个初始的 ./CODEBUDDY.md Project memory 记忆文件。这个文件是至关重要的，它承载了 CodeBuddy Code 在本项目中的长期记忆, 如下是 CodeBuddy Code 存储记忆的三个场景位置。

这些记忆 MD  文件在 CodeBuddy IDE 中叫 Rules，也是可以引用的，在日常项目开发过程中，沉淀项目或个人独有的 Rules 是非常有必要的。

在日常开发 CodeBuddy IDE 和过程中，我们总结很多类似的 Rules 规则，组成了团队的知识库，利用这种 Rules 驱动开发的好处在于，不在停留在仓库中，而在于可以及时的维护和做好版本化管理，保持持续迭代。

• 统一的 Prompt 模版框架输入

在日常和 AI 交互中，每个人输入可能不一样，结果有偏差，为此，我们设定了一个统一的目标实现框架模型：ZWYX，以及对应不同用户输入层级， 通过这种方式实现统一的 Prompt 模板输入，详细如下：

例如：开发一个自定义指令

#Prompt 输入
参考/mr指令 帮我实现一个自定义指令/issue，可以实现创建 Tapd 需求单，具体的步骤你帮我进行拆解，我来把关

#用户 Prompt 输入分析
参考/mr指令(清晰的现状) 帮我实现一个自定义指令/issue，可以实现创建 Tapd 需求单（明确的目标），具体的步骤你帮我进行拆解（ 具体的步骤），我来把关（ 补充信息）

• 变更内容精确到具体的问题文件或具体范围，单次单个任务

2.3  连续 Agent 工作流并行开发，自动生成（流程因素）

在日常开发过程中， 经常因为手写编码的人力瓶颈以及我们需要频繁被切换到各种工具，或在 IDE 中切换跳转，不断打断我们的研发思维，无法做到单人并行开发。

• 把研发任务拆解为 Worktree

针对研发中各类任务，可进行分类管理，不同的分支解决不同的任务问题，我们可基于 Git Worktree 原理，将日常研发任务管理进行分类。

具体实现方法：创建 Worktree 目录：首先，创建一个用于存放所有 Worktree 的文件夹，例如 .trees，并将其加入.gitignore，如下

mkdir -p .trees

添加 Worktree：针对每一项开发任务，使用 git worktree add 命令创建一个新的工作目录。每个 Worktree 都会自动基于 main 分支创建一个同名的新分支。

# 任务1: UI 功能开发
> git worktree add -b deyuan_ui_feature .trees/deyuan_ui_feature

# 任务2: 测试框架增强
> git worktree add -b deyuan_testing_feature .trees/deyuan_testing_feature

# 任务3: 代码质量工具集成
> git worktree add -b deyuan_quality_feature .trees/deyuan_quality_feature

查看 Worktree: 通过 git worktree list

这样我们有了三个物理隔离但共享 Git 历史的工作区。

• 多 Agent 并行开发

在 CodeBuddy Code CLI Agent 场景下，我们可以利用Git worktree 和 为每个 Worktree 打开一个独立的终端，并启动 CodeBuddy 对话，实现多个 AI 打工人，突破人力瓶颈，CodeBuddy Code 可以像多个同事一样，帮我们并行多任务需求开发 工作环境，解决人力问题和加速项目迭代。

当所有任务在各自的 Worktree 中完成后，在终端我们为每个 Worktree 的变更分别直接输入/mr 自动提交，准备将所有成果合并到 main 主干分支，整个合并过程，CodeBuddy 会处理可能出现的任何冲突。

• 团队 Git 提交/Changelog 常规动作自动化，保障一致性

在日常操作过程讲一些常规操作的如分支、提交信息、changelog、推送转为自然语言触发，看似简单，但是面临运营和用户需要及时感知，传统情况下需要人工手工整理和传递，耗费大量时间，我们将这些浪费时间的琐碎事情，全部转为自动化生成的 rules 规范，加入到 CODEBUDDY.MD 中作为长期记忆，让 AI 帮我们实现团队标准化生成和执行，提升团队协作效率与确保一致性，如下为操作步骤：

（1）制定发布 rules ，参考，可以配置为 User Prompt

---
description: "? 智能发版 - 自动更新版本号和changelog，执行构建验证并创建发版MR"
argument-hint: "[custom-prompt]"
---
# ? 智能发版流程
分析变更历史，自动更新版本号和changelog，执行构建验证并创建发版MR。
## ? 发版信息收集
### 工作区和分支状态
!`git status --porcelain && echo "--- Current Branch ---" && git branch --show-current && echo "--- Remote Status ---" && git fetch origin && git status -uno`
### 当前版本信息
!`echo "Package.json version:" && jq -r '.publishConfig.customPackage.version // .version'package.json`
### Changelog结构检查
!`echo "Current CHANGELOG.md:" && head -20 CHANGELOG.md 2>/dev/null || echo "CHANGELOG.md 不存在"`
### 最近提交历史
!`git log --oneline -10 --format="%s"`
### 未发布变更检查
!`grep -n "未发布" CHANGELOG.md | head -5 || echo "无未发布标记"`
## ? 发版策略
### 版本号规则
遵循 [语义化版本](https://semver.org/lang/zh-CN/) 规范：
- `major.minor.patch` - 主版本.次版本.修订版本
- **Major**: 破坏性变更 (BREAKING CHANGE)
- **Minor**: 新功能 (feat)  
- **Patch**: 修复和改进 (fix, docs, chore等)
### 分支命名规范
- `publish/codebuddy-code-v{版本号}` - 发版分支
- 例如: `publish/codebuddy-code-v1.0.12`
## ? 自动化流程
1. **执行构建验证**（确保代码质量）
2. **分析变更类型确定版本号**
3. **创建发版分支**（如在主分支）
4. **更新package.json版本号**（改 publishConfig.customPackage.version 这个字段的版本号）
5. **更新CHANGELOG.md**（移除"未发布"标记，添加发布日期）
6. **生成发版提交信息**
7. **暂存并所有提交变更（git add .）**
8. **推送到远程**
9. **open 命令打开MR页面，等待合并**
### 构建验证步骤
```bash
npm run build     # 构建验证（包含lint检查）
npm run test      # 测试验证（如存在）
```
### 额外补充说明
$1  !!IMPORTANT
---
**开始智能发版流程...**

（2） 开发为自定义指令/mr, 自动进行分析和生成

（3）智能生成 Changelog 结果

（4）快速同步至用户群，及时传递产品变更日志

2.4  高效协作，小步快跑，质量闭环，降低等待（协同因素）

传统协作模式下面临各个角色的协作沟通，涉及的角色也有产品经理、设计工程师、研发工程师、测试工程师、研发 PM 以及部署运维工程师、运营等人员。

如下采用一张图来清晰的呈现我们在传统研发流程的一个协作现状。

• 规范共识，高效协作：因为缺乏背景，加入沟通时间/理解不一致，所以要沟通澄清、对齐 需求颗粒度、拉通协作方继续澄清、明确目标，这一套下来繁琐且浪费研发人员大量时间，而实际大量的沟通协作本质是因为未缺乏共识。面对开发场景，我们借鉴法律制度一样，形成共识，人人遵循。具体做法是把我们日常沟通的长下文利用规则进行沉淀为 Rules，同时这个项目尽可能的少的参与，本次项目参与的角色除了1 名管理者，以及 4 名研发工程和 1 名产品经理，也没有设计工程师和测试工程参与，完全研发要自己解决代码质量问题，不被过多的琐事进行干扰。

• 小步试跑，质量闭环：在开发过程中前期建议渐进式开展，小步试跑，遇到问题快试快改快发，实现快速发布，并及时推送至用户群体验，尽早获得反馈和改进。同时与运营同学密切协作，积极关注用户群中的问题，当日汇总反馈和提单，避免消息淹没导致跟丢。