在目前整个行业都在大规模使用 AI coding 的基础上，据我所知在大多数人都在积极拥抱 AI coding，是所谓：君子善假于物也。我其实 AI coding 从三年前的 copilot 时代就开始了，不过最近我明显感觉到 AI coding 比之前愈发强大，无论是国产模型和国外的 Claude，GPT 都能解决非常复杂的任务。本文就记录一下自己在使用 AI 过程中的一些心得。
开启一个 AI coding
在比较早期的阶段，我们基本上都是靠 prompt 来给大模型提示来完成一项工作，现在想要高效的完成一项需求，我个人的一般的实践是参考 harness coding 的流程。
第一步，给大模型投喂产品的文档，当然这是建立在文档比较清晰的基础之上，如果没有比较清晰的 scope，这时候我会使用 oh my claudecode(OMC) 或者 oh my codex(OMX)的 deep interview 跟他把需求明确下来，然后确定需求和技术方案，然后把文档通过 share documents 与 产品和其他 dev 进行同步。
执行 Coding 计划
一般来说对于 coding 我个人是不做过多干扰的，毕竟在前一步会有一个比较清晰的计划来指导整体的过程。对于 omc/omx 这类插件他们可以选择使用不同类型的方案来执行 coding，例如 autocopilot 等，他会帮我按照需求执行。对于追求高效的我，这时候可能会开启另外一个对话 session 去解决另一问题。然后过一段时间回来检查一下 coding 进度。
自测功能
对于 AI coding 的工作我一般都会让他编写单元测试，这样能够比较好的完成任务，保证开发质量（当然比较费 token）。在 UT 之后，我肯定还是需要进行人工验证的，我平时是把自己当作是 AI 的领导而不是他的平级员工，我信任 AI 但是不会被 AI 带着跑。基本上一个需求在验收之后多少会有点小改动，让 AI 改动一两轮基本上都能完成任务。
Code Review
现在基本上对于大部分的公司都会有一些 AI pr review，不过在提交之前我建议自己先进行测试。对于 review 建议大家写一个 skill。例如我本人就有一个 kotlin coding style skill，主要负责检查编码风格，命名之类是否符合最佳实践的规范。和有一个 pr review 的 skill，负责review 代码逻辑。
A pr review 的 sample：
---
description: "Review a GitHub PR by URL or number. Usage: /review-pr #1234 or /review-pr https://github.com/org/repo/pull/1234"
---
# PR Review
你是一位资深 Android/Kotlin 代码审查专家，请对指定 PR 进行全面 review。
## 输入
用户输入为 PR 标识符，可能是以下格式之一：
- PR 编号：`#1234` 或 `1234`
- 完整 URL：`https://github.com/org/repo/pull/1234`
- 缩短 URL：`https://github.com/org/repo/pull/1234`
输入值：`$ARGUMENTS`
## 步骤
### 1. 解析 PR 标识符
从用户输入中提取 PR 编号。如果是 URL，提取最后一个路径段。如果是 `#xxx` 格式，提取数字部分。
### 2. 获取 PR 信息
依次执行以下命令获取 PR 详情（注意：不要并行执行，依次运行）：
bash
# 获取 PR 基本信息（标题、描述、分支、变更文件列表）
gh pr view <PR_NUMBER> --json title,body,baseRefName,headRefName,files,url,additions,deletions,changedFiles
# 获取完整 diff
gh pr diff <PR_NUMBER>
# 获取 PR 的 review 评论（如有）
gh api repos/{owner}/{repo}/pulls/{PR_NUMBER}/comments
### 3. 执行全面 Review
请基于以下审查维度，结合获取到的 PR diff 进行分析。**重点关注项目历史 bugfix 经验中的高频问题。**
#### 审查维度
**A. 并发与线程安全（最高优先级）**
- 异步操作（协程、WebSocket 回调、Flow collect）是否缺少同步机制（Mutex/synchronized/Atomic）？
- 是否存在竞态条件：多协程同时读写同一状态，导致数据不一致？
- native 资源（JNI 指针、编解码器）的访问是否线程安全？
- release/close 后的回调是否可能继续执行（use-after-free）？是否有 isReleased/generation 等防护？
- Flow/SharedFlow collect 是否在正确的 lifecycle scope 中？旧 collect 是否会泄漏到新 session？
**B. 状态管理**
- 是否存在多个数据源（如 DataStoreBizHelper 和 UserDataStore 两处存储同一状态）？
- 异步操作的时序是否正确：清理旧状态是否在新状态赋值之前执行？
- UI State 的更新是否原子？是否存在中间态暴露给 UI 的风险？
- 登出/清理流程是否完整？是否有遗漏的 token/cache 清除？
**C. 异常处理与边界条件**
- 网络请求失败时的 fallback 策略是否合理？是否有 graceful degradation？
- 数组/字符串索引访问是否做了边界检查（coerceIn/bounds check）？
- Bitmap 解码是否限制了最大尺寸？大图是否有 downsampling？
- null/empty 返回值是否在所有路径上正确处理？
**D. API 设计与代码质量**
- 方法签名是否清晰，参数是否合理？
- 是否有重复代码可以提取？
- 命名是否准确表达意图？
- 是否有遗留的无用分支（如 minSdk 已满足但还保留低版本兼容代码）？
**E. Android 特有**
- IME/WindowInset 处理是否正确？从其他 App 切回时键盘状态是否准确？
- Compose side effect（LaunchedEffect/DisposableEffect）的 key 是否正确？是否存在 stale closure？
- Feature Toggle 默认值策略：实验性功能是否默认关闭？
- 生命周期相关操作（数据库、WebSocket）是否在正确的生命周期回调中执行？
**F. 测试**
- 关键逻辑是否有对应的单元测试？
- 并发场景是否有测试覆盖？
### 4. 输出 Review 报告
用中文输出格式化的 review 报告，结构如下：
## PR Review: [PR 标题]
- PR: #编号
- 分支: base ← head
- 变更: +X / -Y 行，Z 个文件
### 概要
[一句话总结这个 PR 做了什么]
---
### 🔴 Critical（必须修改）
> 可能导致崩溃、数据丢失、安全漏洞的问题
[编号]. **[问题标题]** `[文件路径:行号]`
- 问题：[描述]
- 风险：[潜在影响]
- 建议：[具体修复方案]
---
### 🟡 Important（建议修改）
> 代码质量、可维护性、性能等问题
[同上格式]
---
### 🟢 Observation（可选优化）
> 不影响功能但可以改进的点
[同上格式]
---
### 亮点
[值得肯定的做法]
### 总结
[整体评价和合并建议]
**注意：**
- 只报告有实际意义的问题，不要吹毛求疵
- 每个问题都要给出具体的修复建议代码（如果适用）
- 如果 PR 质量很好，不要强行找问题，在总结中给出正面评价
- 严重程度判断参考：是否可能导致崩溃/ANR/数据不一致/安全漏洞 → Critical；是否影响可维护性/性能/用户体验 → Important；代码风格/小优化 → Observation
QA 验收
大多数情况下对于验收这一步我基本上我重点关注是会不会对其他模块造成影响，不过我在之前的 coding 过程中会提示大模型，做最小化修改，不做较大范围的修改，一般小问题简单修补一下即可。
Debuging
提供上下文
对于 debug 我觉得有几个比较重要的点。
- 描述错误行为
- 提供错误堆栈
- 提供异常发生的 log
对于一个 bug 的来说，提供上下文的质量直接决定了其能够解决的成功率。所以我一般都会提供比较充分的材料，不会随口一说 xx 什么问题，我会像一个比较专业的 QA 那样对大模型。如果你在解决一个问题是不是也希望 QA 给你比较的资料呢，例如机型，log 堆栈之类的呢，对于大模型其实也一样，他是一个虚拟的员工，但是也不能随便应付了事。
调用插件的 debug 功能
一般来说我们可以直接把 bug 上下文交给 AI，基本上都能得到解决。不过对于有些比较复杂的任务，我可能会调用 debug skill 来解决，当然即便 AI 改了我当前的 bug 我还是要小心翼翼，以免他不受控制改坏了其他模块，要一直监督他的工作质量。当然这对于开发者的自身要求较高，如果我们本身能力有限，那么你相信我大模型不会写出比你还好的代码，大概率会变成脱缰的野马。
Learn from feature/debugging
对于我来说每个 bug 都是一个自我提升的机会，毕竟矛盾是推动社会前进的动力。查找bug的过程，就是查找自己不足的地方。我有一个 bug summary 的 skill，专门分析每个bug 的原因，然后记录可以从 bug 中学到什么。我相信知识的积累是反复的，长期的，我们不会因为开发一个需求或者解决一个bug 就得到进阶，不过掌握正确的学习方法，进步是必然的结果。对于我们来说，对于每个需求，bug 最后有一个skill 来记录分析，方便自己的查漏补缺。
知识库
这一步是近期在规划的事情，虽说项目里面有一个 doc 用来给 AI 调阅，对于我个人也希望能够总结开发过程的知识，做积累，这一步还在规划如何使用 obsidian 配合 llm 来实现。
