一、AI使用感受

1.1 使用频率

高频重度用户，每天使用时长超过5小时，覆盖开发全流程，包括需求分析,任务拆解,代码生成，缺陷修复case分析回复，文档撰写、任务拆解分析，需求分析等。

深度使用的佐证：

• CLAUDE.md 厚度：项目级配置文件写到 350+ 行，覆盖角色定义、架构规范、工作流、SOP、禁止行为、缓存策略、自定义指令

• Skill体系完整：一整套自定义Skill（zendesk-flow / ones / weekly-report / okr-report / new-module 等），非临时拼凑，而是反复使用和踩坑后的系统性沉淀

• 本机环境齐全：Zendesk MCP Server、ONES API、ones-api.sh、Zendesk REST 凭证全部配齐，形成完整的本地AI工作环境

1.2 上手难度

对于开发人员来说，难度不大。公司紧跟AI发展潮流，过渡非常丝滑：

ChatGPT对话 → Copilot辅助编码 → Claude Code/CodeX 全流程协作

上手路径：

1. Claude Code安装，配置自定义模型、URL和API_KEY

2. VSCode插件安装使用

3. 自定义Skill开发与配置

第一次使用Claude Code的感受是非常惊艳。 公司同事特别爱分享，形成了良好的AI工具使用氛围。

我们还增加了很多skill,比如常用的： AI开发入口/start，新建模块脚手架/new-module,ones排查修复/ones,case分析回复/zendesk-flow，/zendesk-log，,周报/weekly-report，OKR 进度报告生成okr-report,/文案导入/import-text，AI占比查询/ai-stats，代码审核/code-review,/review,代码提交/git/PR,更新配置/update-config等

通用研究/查询类

SwitchBot 业务流程类（项目专属）

代码质量 / 验证类

配置 / 工具类

1.3 对工作效率的影响

正向影响

重复性工作大幅压缩

• 设备框架生成：auto-file-create CLI 一次生成14+文件，过去手写要半天

• 协议解析、物模型代码生成：分钟级出稿

• 多语言文件（11种）批量翻译：节省大量机械劳动

知识检索成本降低

• 跨35个RN模块 + 40+ iOS设备模块的代码定位

• 命名规范、架构约束的实时校验，不用反复查文档

上下文切换成本降低

• RN/iOS双端联调时减少认知切换

• 新人上手周期缩短（规范、模板、缓存索引都在.claude/）

负面/需警惕的点

验证成本被低估 AI生成的代码看着像，但跑不通的概率不低。比如webp bundle的silent-fail陷阱、桥接层方法签名错配，靠人工code review才能兜住。

"看似完成"的陷阱 SOP第6.1节明确"验证失败3次立即停止"——就是为了防止AI一直在错误方向上自信地推进。

架构腐化风险 如果不强约束依赖方向（common/buzCommon/modules单向），AI容易为了"能跑"而引入反向依赖。

真实效率倍数

净收益的关键：把AI用在它擅长的层（生成 + 检索 + 校验），人工守在决策层和验证层。

具体案例：天气站多视图切换功能（MultiViewSwitchPage）

该功能落在 src/modules/weatherStation/src/business/home/dataSourceSet/MultiViewSwitchPage.tsx，配套还有HomeLayoutSelect、HomeDataSelect、CustomContentEdit等十来个页面。

各阶段效率收益

需求拆解阶段（1h → 20min，3x）

需求："用户可在首页切换不同布局视图（数据卡片/日程/天气大屏等），每个视图可绑定不同数据源和自定义模块"

AI输出：

• 影响面分析：哪些设备型号支持、是否影响快控、是否需要桥接层改动

• 依赖链：MultiViewSwitch → HomeLayoutSelect → HomeDataSelect → DataSourceDeviceSelect

• 自动检测出和ScreenShowSet、ScheduleManagement的耦合点

人工兜底：AI漏掉了"切换视图后蓝牙下发协议字段不同"这个隐性约束。

脚手架阶段（2h → 15min，8x）

10个页面骨架、navigation路由配置、Redux reducer扩展、11种语言文案占位——全部批量生成：

Text

HomeLayoutSelectPage.tsx ✅ 列表 + 卡片预览

HomeDataSelectPage.tsx ✅ 多选 + 排序

CustomContentEditPage.tsx ✅ 拖拽编辑

DataSourceDeviceSelectPage.tsx ✅ 设备筛选

这一层AI几乎不犯错，因为有sample模板 + .claude/rn_spec.md 双重约束。

业务逻辑阶段（3d → 1d，3x）

视图切换核心逻辑：本地预览态 → 草稿态 → 蓝牙下发 → IoT同步 → 影子回写

AI实际贡献：

• 状态机草图（5个状态 + 8个转移）

• Redux action/reducer框架

• 各页面之间的参数传递规范

AI翻车点：

• 影子数据合并策略：AI默认用Object.assign浅合并，实际需要按viewId深合并

• 多语言键名冲突：AI把view_mode复用了ScreenShow的同名key

联调阶段（2d → 1.8d，几乎无收益）

iOS桥接、蓝牙协议字段对齐、真机切换抖动——AI在这一层基本只能当"知识检索器"用。

净账汇总

关键启示

1. AI收益分布极不均匀：脚手架8x，联调1.1x。盲目套"AI提效5x"是不对的

2. 越靠近硬件越无效：蓝牙抖动、影子同步靠真机回归，AI帮不上忙

3. 隐性约束是最大坑：协议字段、状态机边界、跨模块影响——得人来兜底

4. 节省的时间投回验证：少花在coding上的时间正好用来加更多真机回归用例

二、AI辅助工作具体运用在哪些方面

2.1 需求与任务管理

• 需求拆解：把PRD/需求文档拆成可执行的子任务清单，标注模块归属和依赖关系

• MVP拆分：按架构层（common / buzCommon / modules）规划模块职责

• 任务追踪：维护tasks.md，输出当前进度总览

2.2 代码生成

• iOS设备框架生成：通过auto-file-create CLI自动生成14个默认Swift文件 + 18个可选协议扩展

• RN新模块骨架：yarn new从src/buzCommon/sample/复制模板 + 自动注册DebugEntry.js

• 物模型代码生成：根据物模型协议字段生成Swift/OC代码

• RN组件代码生成：函数组件 + React.memo + TS类型规范的成品代码

2.3 代码审查与校验

• RN规范校验：依据.claude/rn_spec.md检查禁止any、空catch、硬编码中文、类组件等

• iOS命名校验：依据.claude/ios_naming_rules.md校验Wo前缀、MARK顺序、拼音/数字序号

• 架构依赖检查：防止modules反向依赖common/buzCommon

2.4 协议与桥接

• 协议解析：解析设备通信协议字段与结构（BLE/IoT/MQTT）

• NativeModule扩展：在8个现有桥接模块（WoPropertyModule / WoCommunicationModule等）中扩展方法

2.5 多端联调

• 双端模块创建：RN侧（页面/Redux/路由/网络）+ iOS侧（Model/View/VC/Manager）一次性搭建

• 多语言补全：11种语言文件批量生成t(key) / c(key)对应文案

• 跨模块平台需求：按common → buzCommon → modules顺序逐层修改

2.6 工程信息检索

• 项目缓存：通过.claude/project_cache.md快速定位35个RN模块 / 40+ iOS设备模块路径

• UI组件查询：wrn-ui 50个组件参考（.claude/ui_components.md）

• 协议注册表：auto-file-create历史生成记录索引

2.7 流程与质量

• SOP约束执行：需求摘要 → 用户确认 → 子任务拆解 → 逐任务执行 → 异常停止（失败3次必报告）

• 变更追踪：关键修改输出diff摘要 + 更新project_cache.md

• 禁止行为拦截：12条红线（手写协议文件、类组件、any类型、空catch等）

2.8 外部系统联动（Skills）

• ONES工单流转：识别工单号自动读写、补缺陷原因/验证版本

• Zendesk工单处理：端到端分析 + 日志取证 + 改单回写

• 文案导入：从Excel批量导入到本地RN项目

• 周报生成：从Git提交历史生成研发周报

总结：从"读需求"到"出代码"再到"改单/写报告"的全链路都有AI介入，但越靠近"创建框架文件/协议文件"这类有强规范的环节，越要求走自动化工具（CLI/脚本），而不是让AI直接write/edit。

三、AI在工作中的占比

3.1 数据来源

• 数据来源：http://192.168.6.124:5000/authors?since=2026-05-14&until=2026-06-23

• 统计时长：5月14日至今

3.2 整体占比

3.3 占比说明

高占比的背后逻辑：

• AI擅长的部分（占比极高）：脚手架生成、模板代码、多语言文件、Redux样板代码、路由配置、格式化代码

• 人工主导的部分（占比低但关键）：架构决策、协议字段定义、异常边界处理、真机调试、最终代码审查

AI占比高不等于人工不重要。人工的价值集中在决策层和验证层——这恰恰是质量的关键控制点。

四、踩坑经验

一、上下文与记忆类

坑 1：AI "记得" 的东西其实是旧的

• 现象：AI 引用某个函数/文件路径，但实际已被重命名或删除

• 应对：让 AI 在推荐前先 grep / Read 验证，不要相信「我记得有这个方法」

坑 2：长对话后忘记最初约束

• 现象：开头说"禁用 any"，30 轮后 AI 又写出 any

• 应对：把硬性规则写进 CLAUDE.md（项目级）或 memory（用户级），而不是只说一次

坑 3：上下文压缩后丢失关键决策

• 现象：context compaction 后 AI 重新「发明」之前讨论过的方案

• 应对：关键决策落到 tasks.md 或 plan 文件，不要只留在对话里

二、代码生成类

坑 4：过度工程化

• 现象：让 AI 改个 bug，它顺手重构了 5 个文件

• 应对：明确说「只改这一处」「不要重构」，或在 CLAUDE.md 里写死

坑 5：编造 API / 方法

• 现象：调用根本不存在的 SDK 方法、组件 props

• 应对：陌生库强制先读源码 / 文档；让 AI 列出依据再写

坑 6：补丁式叠加而非修根

• 现象：测试失败 → AI 不停加 try-catch / 兜底，掩盖根因

• 应对：要求先输出根因分析，再写修复；失败 3 次必须停（已写进 SOP）

坑 7：批量改动不可审查

• 现象：一次提交几十个文件，diff 看不过来

• 应对：拆成小批次，每批单独 review；用 /code-review skill

三、跨端 / 工具类

坑 8：跳过既定工具，手动 write/edit 创建

• 现象：让 AI 加新设备，它直接 Write 出 Swift 文件，绕过 auto-file-create CLI

• 应对：CLAUDE.md 第 8 条已禁止；遇到时立刻打断、重来

坑 9：iOS / RN 双端不同步

• 现象：RN 端加了字段，iOS 桥接层没改，运行时 crash

• 应对：双端任务必须列双端 checklist，分别勾选

坑 10：硬编码多语言文案

• 现象：AI 直接写中文字符串，绕过 t(key) / c(key)

• 应对：CLAUDE.md 已禁止；review 时 grep 中文字符识别遗漏

四、协作流程类

坑 11：未对齐就开干

• 现象：需求模糊，AI 凭猜测实现一大段

• 应对：先要求输出「需求摘要 + 存疑点」，确认后再动手（SOP 步骤 1）

坑 12：destructive 操作未确认

• 现象：force push / 删分支 / 重置工作区不商量直接执行

• 应对：高风险操作必须先 ask；CLAUDE.md 可指定「写操作前需确认」

坑 13：盲目相信 AI 的「测试通过」

• 现象：AI 说「已验证」，实际只跑了 lint

• 应对：用 /verify 或 /run skill 实际拉起 app；UI 改动必须真机跑

核心认知：AI缺乏对业务上下文的深度理解，有时会"一本正经地胡说八道"。关键在于学会驾驭它，而不是被它驾驭。

五、如何让AI审核它输出的内容

5.1 自我审查类（单Agent闭环）

策略1：Chain-of-Verification (CoVe) 自验证链

Text

流程：

1. 让AI输出初稿

2. 让它针对初稿生成3-5个"验证问题"

（如：这个API是否真存在？这个数字来源是哪？）

3. 逐个回答验证问题，发现矛盾就修正

策略2：Self-Critique 自我批判

• 用第二轮prompt让AI扮演"严格审查者"角色，攻击自己的输出

• 关键：必须切换角色/身份，否则容易"自我维护"

• 例："作为代码审查专家，找出上述代码中的3个潜在bug"

策略3：Step-back / Reflection

• 输出后强制反思："我是否遗漏了边界情况？""我的假设是否成立？"

• 适合数学推理、逻辑题

5.2 交叉验证类（多Agent/多模型）

策略4：Multi-Agent Debate（多智能体辩论）

• 让两个AI各自给答案，再让第三个AI当"裁判"

• 或让A、B互相反驳2-3轮再收敛

• 适合开放性问题、设计决策

策略5：多模型集成（Ensemble）

• 同一问题让Opus / Sonnet / GPT分别回答

• 投票或加权融合，分歧大的地方人工介入

• 适合事实类、判断类任务

策略6：Adversarial Verify（对抗验证）

• N个独立"怀疑者"被明确告知"默认你要反驳这个结论"

• 多数反驳就否决，避免"看起来合理但错"的输出

• Workflow常用模式：3票里≥2票通过才采纳

5.3 分步检查类（流程拆解）

策略7：Plan → Execute → Verify 三段式

Text

先输出计划 → 用户/另一个AI确认 → 再执行 → 最后验证

Claude Code的EnterPlanMode就是这个思路。

策略8：分维度审查

把一次"综合review"拆成多个独立维度并行：

每个维度用专门prompt，避免"什么都看 = 什么都没仔细看"。

策略9：Pipeline + Gate（流水线 + 关卡）

• 每个阶段产出有schema约束（JSON Schema）

• 不符合就重试，符合才进下一阶段

• 强制结构化降低"自由发挥"的错误

5.4 外部Ground Truth（最可靠）

策略10：工具调用验证

• 让AI调用真实API / 编译器 / 测试框架去验证

• 写代码→跑测试；引用API→实际fetch

• 比任何"自我审查"都可靠

策略11：RAG + 引用强制

• 要求每个事实声明附带来源链接

• 然后第二个Agent去fetch链接，验证引用是否支持原文

策略12：单元测试 / Schema校验

• 输出代码→跑测试套件

• 输出JSON→schema校验

• 输出SQL→EXPLAIN / dry-run

5.5 关键工程原则

5.6 实战建议

最关键一句话：AI自查的有效性，取决于审查者和生成者的"心理距离"——同一个prompt自审基本无效，换角色/换模型/换维度才真正起作用。

总结

最终认知：AI是强大的效率杠杆，但它的价值上限取决于使用者的工程素养和验证纪律。真正的竞争力不是"用了AI"，而是建立了一套可持续、可复制、可审计的AI协作体系。