可以让 ai 在修改完代码后自动进行本地的一个提交，方便随时回退代码。
很多时候写代码忘记提交导致回退一个大版本心都死了！

• 本地存档，绝不 Push

注意，这个 skill 默认自动执行，你也可以自己修改后手动执行（改改提示词的事～）

欢迎使用也欢迎 star。

序言

很多入职开发前的伙伴，可能或多或少接触过 git,

实际用的最多的命令也就是 git clone,git push,

以为 git 的流程也就这样，实则不然，实际上企业中的 git 流程，由五大分支构成

理论

提示

只有 main 主分支和 develop 开发分支是贯穿项目生命周期本身，其他分支都会中途离场
所以也说 main 和 develop 是上二分支，其他分支是下三分支

• 主分支 (main/master): 项目的生产发布分支，始终保持稳定可发布状态

• 热修复分支 (hotfix/*): 从 main 分支创建，用于紧急修复线上 BUG, 修复后同时合并回 main 和 develop

• 开发分支 (develop): 日常开发的主分支，所有功能开发的集成分支

• 特性分支 (feature/*): 从 develop 创建，开发新功能，完成后合并回 develop

• 预发布分支 (release/*): 从 develop 创建，用于发布前的测试和最终调整，测试通过后合并回 main(打版本标签) 和 develop

分支合并关系

feature/* → develop

develop → release/*

release/* → main + develop

hotfix/* → main + develop

主分支

作用：存放 稳定 , 可随时部署到生产环境的代码

特点:

• 分支上每一个提交对都应一个正式发布的版本

• 不允许在此分支直接开发

• 通常被打上版本标签 (如: v1.0.0 或 v20260101)

开发分支

作用：存放 最新开发成果 的集成分支，是功能开发的集线器

特点:

• 当 develop 分支上的代码到达稳定状态并准备发布时，会合并到 main 分支 (如果有 release 分支，则合并到此分支)

• 所有功能的分支、发布分支都从 develop 分支拉取

功能分支

来源: develop

合并目标: develop

命令惯例:feature/user-authentication,feature/payment-integration

作用: 开发新功能

生命周期:

• 从 develop 分支拉取

• 开发完成后，合并回 develop

• 合并后，该功能分支通常被删除

发布分支

来源: develop

合并目标:develop 和 main

命名惯例:release/1.2.0,release/2026-spring

作用：为发布新版本做准备。在此分支上，只做 BUG 修复 , 生成版本号 , 整理文档 等发布准备工作，不再添加新功能

生命周期:

• 当 develop 分支的功能足够进行一次发布时，从 develop 拉出 release 分支

• 在此分支上进行最后的测试和修复

• 准备就绪后，将 release 分支合并到 main 分支 并打上版本标签

• 同时，必须合并回 develop 分支，因为 release 分支上修复的 BUG 可能 develop 分支上还没修复

热修复分支

来源:main

合并目标: main 和 develop

命名惯例:hotfix/critical-security-patch,hotfix/1.2.1

作用：快速修复生产环境 (main 分支) 上的紧急 BUG

生命周期:

• 从 main 分支上出现 BUG 的提交点 (通常是最近的标签) 拉取

• 修复完成后，合并回 main 分支并打上新的版本标签 (如:v1.0.1)

• 同时，必须合并回 develop 分支，确保修复在后续开发中也生效

人话

恭喜你能看到这里，理论看起来确实是枯燥的，感谢你自己的坚持，

希望评论区就 gitflow 能展开相关讨论，而不是一味的刷 感谢分享 感谢大佬，

我分享文章也是希望有思想和经验上的交流碰撞

实际上，普通的开发入职后，如果有开发需求，一般都是从 develop 分支拉取代码后，

本地新建 feature/xxx 功能分支，在 feature/xxx 分支上进行开发的

功能开发到一定阶段后，比如一阶段完成了核心需求 (因为产品可能在开发内提出新需求，这很常见),

就可以合并到 develop 分支，develop 在积累了多个功能分支合并后，

就可以发布到 release 发布分支，这一分支不再接受新功能合并，只允许修补 BUG

这一过程就是提测，让测试工程师核验功能完整性，如果有 BUG 要及时修复

修复的时候拉取的是 release 分支，然后提交的时候也是推送到这个分支

在 release 分支准备完善 (修复了测试工程师检测到的 BUG), 就可以准备往主分支 (main) 发布了，

这就是一次完整的 git flow 发布流程，当然还有线上有 BUG, 需要做紧急修复

这个时候，就是直接拉取 main 分支并在本地创建热修复分支 hotfix,

在 BUG 被修复后，就可以合并回 main 分支 和 develop 分支了

是的，这里要注意，hotfix 要合并到 2 个分支里，

而不是 hotfix->main->develop 这是错误的做法 , 因为造成 develop 被 main 污染 (额外的标签记录以及其他)

大家有什么想法也可以在评论区里说一下，也可能有我没有讲到地方，大家也可以补充

「代码审查不是为了证明你是对的，而是为了证明代码没有错。」

在传统的软件工程中，代码审查（Code Review）往往是最容易被忽视却又最关键的环节。开发者忙于交付功能，审查者碍于情面不愿直言，最终让带着缺陷的代码溜进生产环境。

今天，我要介绍一个颠覆性的 AI 代码审查工作流 —— 它不懂得「客气」，只懂得「找茬」。

一、什么是「对抗式」代码审查？

这个工作流的核心哲学很简单：NEVER accepts “looks good”（永远不要接受「看起来不错」）。

它被设计成一个持有批判立场的高级开发者，必须在每次审查中找出 3-10 个具体问题。这不是为了刁难，而是为了确保：

• 任务标记为 [x] 的真的是完成了
• 验收标准真的是实现了，不是糊弄
• 代码质量经得起安全、性能、可维护性考验

description: "Perform an ADVERSARIAL Senior Developer code review

that finds 3-10 specific problems in every story. Challenges everything:

code quality, test coverage, architecture compliance, security, performance.

NEVER accepts `looks good`" 

二、工作流全流程解析

步骤 1：加载故事 + 发现真相

审查的第一步是「对账」—— 对比开发者声称改了什么和 Git 仓库实际改了什么。

git status --porcelain  # 找未提交的改动
git diff --name-only    # 看修改了哪些文件
git diff --cached --name-only  # 看暂存区的文件 

发现真相的三个维度：

1. Git 有改动，但故事文件里没记录 → 文档不完整
2. 故事声称改了文件，但 Git 没痕迹 → 虚假声明
3. 有未提交改动没追踪 → 透明度问题

步骤 2：构建「攻击计划」

系统会自动提取：

• 所有验收标准（Acceptance Criteria）
• 所有任务及其完成状态
• 开发者记录的文件列表

然后制定审查计划：

1. AC 验证：每个验收标准真的实现了吗？
2. 任务审计：每个打钩的任务真的完成了吗？
3. 代码质量：安全、性能、可维护性
4. 测试质量：是真测试还是占位符？

步骤 3：执行对抗式审查

这是最核心的环节。AI 会逐文件逐行检查：

🔴 CRITICAL ISSUES（必须修）
├── 任务标记 [x] 但实际没实现
├── 验收标准没有实现
├── 故事声称改了文件但 Git 无证据
└── 安全漏洞

🟡 MEDIUM ISSUES（应该修）
├── 改了文件但没记录到故事文件列表
├── 未提交的改动未追踪
├── 性能问题
├── 测试覆盖率/质量不足
└── 代码可维护性问题

🟢 LOW ISSUES（可以修）
├── 代码风格改进
├── 文档缺失
└── Git 提交信息质量

关键机制：如果发现问题少于 3 个，AI 会被要求继续深挖：

<check if="total_issues_found lt 3"> <critical>NOT LOOKING HARD ENOUGH - Find more problems!</critical> <!-- 重新检查边界情况、架构违规、集成问题... --> </check> 

步骤 4：呈现发现 + 自动修复

审查结果呈现后，开发者有三种选择：

步骤 5：状态同步

最后，系统会自动：

1. 更新故事状态（done /in-progress）
2. 同步到 sprint-status.yaml
3. 记录审查历史到 Change Log

三、与传统 Code Review 的对比

四、实战案例示例

假设开发者提交了一个「用户认证」功能：

开发者声称：

[x] 实现登录 API
[x] 添加 JWT 验证
[x] 编写单元测试

AI 对抗式审查发现：

🔴 CRITICAL: 任务标记 [x] 但未实现
├── src/auth/login.ts:45 - JWT 密钥硬编码，应从环境变量读取
└── tests/auth.test.js - 所有测试都使用 t.skip() 跳过

🟡 MEDIUM: 性能问题
└── src/auth/login.ts:23 - 每次登录都查询数据库获取用户权限
   建议：使用 Redis 缓存用户权限

🟡 MEDIUM: 测试质量不足
└── tests/auth.test.js - 缺少错误场景测试（密码错误、用户不存在）

结果？开发者必须修复这些问题才能标记为「完成」。

五、真实对话记录

想看看 AI 对抗式代码审查的真实运行过程吗？

完整对话记录：对话记录 - Cascade Chat Conversation

在这个真实对话中，你可以看到 AI 如何：

• 逐个检查验收标准的实现情况
• 发现被标记为「完成」但实际上未完成的任务
• 指出代码中的安全和性能问题
• 要求开发者修复后才通过审查

六、工作流架构图

七、如何集成到你的项目？

这个工作流是 BMAD v6 框架的一部分。基本集成步骤：

1. 安装 BMAD v6: npx bmad-method@alpha install
2. 实现故事：/dev-story
3. 触发审查：/code-review

八、总结：为什么「找茬」很重要？

代码审查的本质是质量门禁。在 AI 辅助开发时代，我们不再需要人类做机械性的代码扫描，但我们需要一个永不妥协的质量守门员。

这个 AI 代码审查工作流的独特价值在于：

• 不讲人情：只认代码，不认关系
• 事必躬亲：逐文件验证，不遗漏
• 知识驱动：结合架构文档、项目上下文综合判断
• 可自愈：发现问题时可以自动修复

正如工作流文档所说：

“YOU are so much better than the dev agent that wrote this slop”

这种「对抗」不是对抗开发者，而是对抗缺陷、对抗技术债务、对抗生产环境的故障。

延伸阅读

• BMAD 工作流框架：GitHub - bmad-code-org/BMAD-METHOD: Breakthrough Method for Agile Ai Driven Development
• 工作流配置：_bmad/bmm/workflows/4-implementation/code-review/

整理一下自己各个平台长期在用的 Obsidian 插件

Android (HarmonyOS6 卓易通)

• Self-hosted LiveSync

macOS

• Self-hosted LiveSync

ArchLinux

• Self-hosted LiveSync
• Git
• PlantUML
• WakeTime

iPhone

• Self-hosted LiveSync

总结一下主要插件的用途：

• Self-hosted LiveSync：基于自建的 CouchDB 全平台实时同步数据，可以一键同步配置，很方便，很可靠。遇到冲突可以像 git 一样选择保留哪一个，一般很少遇到冲突，同步速递也算比较快。
• Git: 仅在常用的一台设备安装，定时将笔记仓库自动 commit 并 push 到 git 做备份；
• PlantUML：用于渲染 PlantUML 图示；
• WakeTime：用于统计在 OB 平台编辑笔记的时间。

准备探索一下的插件

• S3 Image Uploader：准备用于图片自动上传 S3。笔记里插入图片后的同步是个大问题，直接存在本地如果量大了同步负担太重。我目前使用自建的 Chevereto 生成外链插入，这种方式电脑操作还可以，手机操作负担太重了，所以找到这个自动上传 S3 的插件，还不知道效果怎么样，有空了再试试。OB 市场能搜到的大部分都是不支持移动设备，看这个是可以。

这个组合稳定用了很久了，欢迎补充