🚀 AI 提效实战分享：我的“老王 AI”开发工作流

分享人：wkl｜开发团队内部分享｜2026-09-16
基于 Claude Code 与 Codex 的真实记录整理；对话为历史记录的简化转述，省略业务标识与认证信息。数量与耗时均为个人经验估算。
配套：图片与讲解提示｜Skill 速查表

🎬 开篇：我们的一天，时间都去哪了

一句话：开发的时间大半不花在写代码上，而是花在梳理需求、摸清代码、查数据、写文档、排查定位上。

最费时间的环节	以前	现在
🧩 梳理需求	散在 PRD、原型和口头讨论里，靠反复问	grill-me 五维度问清，落成 01 需求分析
🗺️ 梳理代码结构	接手老功能靠记忆，翻半天才知道链路	抓包 + 链路定位，出 02 代码库全景
🗄️ 查数据	反复写 SQL 试	AI 出只读 SQL，我执行后回传
📄 写交付文档	手写 4—8 小时	按模板生成，我复核事实
🐛 排查定位	靠经验猜	日志 + 代码 + 数据交叉验证

AI 提效的本质，是把自己的工作模式沉淀成一套流程：繁琐耗时的交给 AI，重点决策留给自己。

但 AI 得先“敢质疑、讲证据、对交付较真”才真帮得上忙——所以我给搭档设了“老王”人设：😤 需求不清直接喷、🔨 编译不过继续修、🤝 先给结论再给依据。

对话 D1｜先让老王质疑需求（Claude Code，简化整理）

**我：**针对这个 PRD，帮我看看还有哪些不清晰的地方。

**老王：**PRD 里两个范围选择器长得一样，它们是否联动？数值为 0 和尚未产生数据，应该怎么区分？

**提效技巧：**主动要求它找歧义，把讨论推进到业务口径和边界条件。
对应 Skill：grill-me，连续追问目标、边界、异常和验收标准。 来源 D1

🔑 一、先说结论

一句话：给 AI 明确任务、提供上下文、要求验证，最后把经验留下来。

🙋 我负责说清任务、复核关键改动；🤖 AI 负责查链路、写代码、整文档；两边都要留下验证记录。

🧩 二、三个案例

案例	我的关键动作	对应 Skill
🐛 Bug 排查	先补证据，再改代码	bug-hunter
🧱 复杂改造	先定边界，再拆任务	doc-tech-solution → tech-solution-review
🔌 第三方对接	对照接口文档核枚举	api-integration

🐛 案例 1：让结论有证据

我提供给 AI	AI 负责做什么	对我的帮助
实际结果、预期结果、复现条件	定位入口，梳理完整调用链	避免只盯着报错行
日志、相关代码和表结构	列出已确认事实与待验证假设	把事实和猜测分开
诊断 SQL 的查询结果	对比代码预期与真实数据	用数据修正初步判断
修复后的构建和回归结果	汇总已验证项与未验证项	避免把“改完”当成“验证通过”

对话 D2｜让查询结果纠正初步判断（Claude Code，简化整理）

**我：**我把两张关联表的查询结果贴回来了：原先怀疑的金额其实一致，但类型和成本字段不同。

**老王：**收到，金额假设被数据推翻；真正差异是类型和成本。接下来只追这两个字段的赋值链路。

**提效技巧：**把查询结果贴回来，允许证据推翻最初的排查假设。
对应 Skill：bug-hunter，串起日志、代码、数据三类证据。 来源 D2

💡 日志看运行路径、代码看判断条件、数据看实际状态。 缺哪块补哪块，命中历史模式也要验证。

🧱 案例 2：先定边界，再拆任务

对话 D3｜迁移时把改动边界说清楚（Codex，简化整理）

**我：**调用方接口不改；服务端读取最新数据，合并本次修改，再把完整结果传给下游。

**老王：**明白。新增是追加，修改是替换，删除是移除；我会保持接口不变，只调整服务端组装逻辑。

**提效技巧：**业务边界由人明确，AI 再把新增、修改、删除的差异展开。
Skill 组合：doc-tech-solution 生成方案 → tech-solution-review 编码前挑刺 → project-utils 约束实现 → code-review-skill-main/business 双重审查。 来源 D3

对话 D4｜用真实环境数据生成自测清单（Codex，简化整理）

**我：**查询结果贴回来了，其中两条 SQL 没有查到数据。

**老王：**不编造测试参数。已有数据直接复用，空数据标为前置条件；能由前序步骤产生的数据，放到后面验证。

**提效技巧：**先补测试数据，再生成按业务顺序可执行的清单。
对应 Skill：doc-self-test-checklist，按实际代码和数据编排可执行用例。 来源 D4

🔌 案例 3：对照文档，而不是凭感觉补枚举

对话 D5｜拿接口文档纠正状态映射（Claude Code，简化整理）

**我（先问）：**本地这个状态能不能映射成对方的“已取消”？

**我（核对后）：**我重新对照了 API 文档，里面没有这个状态码，该怎么处理？

**提效技巧：**对照外部契约复核 AI 产物，发现不支持的状态就重新讨论。
对应 Skill：api-integration，整理字段、枚举、异常重试和联调检查项。 来源 D5

💡 名称相近 ≠ 语义一致；映射规则、文档版本、失败样例一起留下来，别把“选个最接近的状态”当通用规则。

⚙️ 三、我怎么组织 AI 工作流

3.1 规则、知识、流程分开存

类型	解决的问题	我的组织方式
🧭 全局与项目规则	每次重复交代规范	CLAUDE.md / AGENTS.md 放核心约束与资料索引
📚 知识文件	AI 缺少业务背景	编码规范、按库拆分的 DDL、接口文档、经验与 Bug 模式
🧰 Skill	同类任务执行步骤不稳定	定义输入、执行步骤、输出产物和验证要求
🧠 Memory 与交接	新会话丢失偏好和进度	记录偏好、已确认决策、未完成事项及下一步

速览：28 个专项 Skill、12 条 Bug 模式、9 篇经验、5 套文档模板。 入口保持简短、细节按任务读取；值钱的不是数量，是同类任务能秒查到相关规则。

3.2 我给“老王”立的几条规矩

场景	约束	如何检查
🔍 开始编码	先查现有实现与项目规范	引用复用位置，说明新增内容的必要性
🗄️ 写 SQL	先查真实 DDL，核对租户和逻辑删除条件	查看结构来源、查询条件与结果
⚡ 性能相关改动	避免循环查库，批量操作按范围分批	审查调用次数、批次和执行计划
🔨 完成代码	编译必须通过，验证范围明确	保留实际命令、结果及未验证项
🚦 提交与发布	commit/push 按授权执行，上线按团队流程	人工复核改动、发布条件及回滚方案

💡 结论以工具输出和产物为准；核心业务改动必须人工复核，不能只看 AI 自己标的风险点。

3.3 两个 agent 怎么配合

工具	我常安排的任务	接续方式
🅰️ Claude Code	需求讨论、链路分析、Bug 排查	读项目资料与已有交接记录
🅱️ Codex	长编码任务、跨模块迁移	按已确认方案实现，留下改动与验证记录
🔄 两者切换	编码后接续审查或自测	导出摘要，接手方先核对当前代码

切换的关键是交接质量：目标、已完成、关键决策、涉及文件、验证结果、未完成事项、下一步，一个都不能少；两个 agent 不要同时改同一片代码。

对话 D6｜交接时把未完成事项写明白（Claude Code，简化整理）

**我：**下个会话继续处理这项 Bug 排查。

**老王：**交接已整理：哪些已经完成、哪一处改了但还没编译、下一轮先做什么，以及还有哪些待验证项，都已写明。

**提效技巧：**交接要留下已做、未验、下一步，防止接手方把进度当结论。
Skill 组合：conv-handoff 保存会话进度；跨工具时再用 cross-agent-sync 同步上下文。 来源 D6

3.4 Skill 串成一条编号文档链

主线是一条编号文档链，统一放 docs/requirements/{需求}/：

阶段	Skill	产出文档	这份文档的作用
01 需求	grill-me	需求分析	问清边界、异常与验收标准
02 摸底	codebase-onboarding	代码现状	架构、数据模型、依赖一次摸清
03 方案	doc-tech-solution	技术方案	定范围、流程与任务拆分
04 评审	tech-solution-review	方案评审报告	编码前挑刺，不过就不进编码
05 实现	doc-implementation-log	实现日志	改动、编译结果、未验证项留痕
06 审查	code-review ×2	代码审查报告	工程质量 + 业务逻辑双查
07-09 交付	doc-self-test-checklist 等	自测 / 联调 / 上线清单	每个阶段有据可依，发布含回滚

每个 Skill 的作用、概述、产出文档和文档用途，见 Skill 速查表。

作者的活和审稿人的活分开：doc-tech-solution 写方案，tech-solution-review 挑刺——只看需求有没有漏、边界清不清楚、数据设计与回滚站不站得住、有没有过度设计。评审不过就不进编码；方案自己审自己，基本等于没审。

需求中途变了（change-handler）先分级，再决定回退到哪一步：

flowchart TD
    A["需求变了"] --> F{"改动落在哪一级?"}
    F -->|"不改结构，只改值"| L1["L1 直接改"]
    F -->|"影响一个模块"| L2["L2 阶段内最小代价调整"]
    F -->|"核心设计要变"| L3["L3 回退到 04 重新评审"]

专项分支：bug-hunter 查 Bug、perf-sql-optimizer 治慢 SQL、data-fix-gen 修数据、api-integration 接三方、unit-test-gen 补单测。Skill 负责把步骤和检查项稳定下来，我负责边界判断、结果复核和是否交付。

💬 四、提问与验收

一句话：一次说清目标、材料、约束、验收；有结果就贴回，缺信息就标出来。 重点不是把提示词写漂亮，而是让 AI 知道什么不能擅自决定。

怎么看有没有真省时间：总耗时、审核耗时、返工次数、遗漏项、文档可用性。如果只是很快产出一堆内容、最后花更多时间纠错，那不算提效。经验估算：单 Bug 排查 2 小时 → 30 分钟；4 份文档 4—8 小时 → 约 1 小时（个人经验，不是统一基准）。

🚀 五、接下来想尝试的方向

一句话：数据库查询目前还是 AI 出 SQL、我在 DataGrip 执行再回传，下一步想接 MySQL MCP 减少人工搬运（演进计划，尚未落地）。

层次	分工	配套要求
📁 本地 DDL	快速检索、离线结构分析	标注库、环境和导出时间，定期更新
🔌 测试库工具连接	查样例、看状态分布，验证排查假设	只读账号、库表范围限制、查询超时与审计
🔒 生产库	维持人工审核执行流程	控制查询范围，变更按审批与回滚流程

⚠️ 只读不等于没有查询负载，LIMIT 也不等于扫描量小；连上以后仍要看执行计划和环境差异。经验也分适用范围，哪些适合共享、哪些只是个人偏好，边用边筛。

🏰 六、思考：AI 时代下开发人员的护城河

一句话：AI 越强，定义问题、组织上下文、设计验证、承担决策的价值越大。

护城河	要积累的能力	我的实践
🎯 问题定义权	知道业务要解决什么，识别错误前提与模糊边界	三方对接先核实允许的状态，再谈映射
🧠 隐性上下文	理解历史决策、业务例外和踩坑原因	Memory、经验库、Bug 模式、真实 DDL 与接口资料
⚖️ 责任与决策权	判断方案取舍、上线时机、影响范围、回滚条件	方案人拍板，提交按授权，生产按流程复核
✅ 验证体系设计	把“应该没问题”变成可检查的条件和证据	编译检查、业务断言、三类证据交叉验证
🏗️ AI 生产体系	把一次有效协作变成可复用的流程	规则索引、专项 Skill、编号文档、跨 agent 交接

长期业务理解没法靠一份提示词复制，团队内该共享的就共享；个人价值在于能不能持续获取、判断和更新这些知识。

身份变化：从亲手写每一行代码，到组织实现并对业务结果负责。 对话 D3 里“调用方接口不改”的边界、D5 里“文档没有这个状态”的核对、方案评审结论的采纳，都是人的判断。

提效的目标不是产出更多内容，而是让正确交付更稳定、更可重复。这只是我当前阶段的用法，其他同事可能有更顺手的工具和提示方式，也欢迎交流。