AI 使用心得：B 端产品工作中的方法、边界与实践

从个人工作量来看，34 个人日压缩到 15 个人日，并不是因为流程被省略，也不是因为评审质量下降，而是工作方式被重新组织。

图2：34人日到15人日的效率变化

效率不是来自省略流程，而是来自工作方式重组：AI 做结构化和遗漏检查，人做判断与复核。

这批需求从接收到评审通过，通常包含五类工作：

工作环节	过去主要消耗	AI 介入后的变化
业务沟通	背景、目标、约束反复确认	先整理输入，再让 AI 反问遗漏
流程梳理	分支、异常、边界在脑中反复打转	让 AI 帮忙摊开流程和异常
交互设计	先画很久，才进入讨论	先生成可讨论版本，再人工修正
文档撰写	从空白页开始铺结构	用模板或 Skill 生成初稿
评审调整	评审现场暴露大量遗漏	提前把待确认项显性化

过去最耗时的环节，是信息在脑中反复整理：

• 这个分支有没有漏？

• 异常应该怎么处理？

• 页面和系统是否有联动？

• 规则是否影响旧流程？

• 测试是否能够验证？

AI 介入后，工作方式可以调整为：从空白页工作，变成循环式工作

输入背景 → AI 反问 → 补齐上下文 → 生成初稿 → 人工复核 → 继续迭代

这里有一个非常关键的分工：

1. AI 是劳动者

• 整理材料；

• 生成初稿；

• 提出疑点；

• 补齐结构；

• 检查遗漏；

• 帮助表达。

2. 人是决策者

• 判断业务目标；

• 确认流程边界；

• 拍板异常规则；

• 评估系统影响；

• 承担评审结论；

• 对最终结果负责。

人是决策者，AI 是劳动者。

比如在收银、支付、对账、定价等场景里，AI 可以参与分析、解释、建议、异常识别和文档整理，但核心交易逻辑必须保持确定、可验证、可追溯。

AI 从“会回答问题”，逐步走向“能进入真实工作现场”。

阶段	关键问题	典型做法
Prompt Engineering	怎么把问题问清楚？	角色设定、步骤拆分、输出格式约束
Context Engineering	怎么把上下文给足？	提供文档、截图、代码、历史规则、业务背景
Harness Engineering	怎么让 AI 进入工作现场？	给工具、文件、权限、执行环境和验证循环

5.1 Prompt Engineering：把问题问清楚

最早的 AI 使用，重点在 Prompt Engineering，也就是如何写好提示词。

角色设定、分步骤思考、few-shot 示例、输出格式约束，都是这个阶段常用的方法。它们现在仍然有效，但只是起点。

例如让 AI 写需求文档时，泛泛地说“写一份 PRD”，效果通常不会稳定。更好的方式是明确角色、结构和输出要求。

更好的提示方式

• 按 B 端产品经理视角处理；

• 按背景、目标、流程、规则、异常、验收标准组织；

• 不确定信息标为待确认；

• 输出 Markdown；

• 先提出问题，再生成文档。

Prompt 是入口，但只靠 Prompt 很快会遇到瓶颈。

5.2 Context Engineering：把上下文给足

真正影响 AI 输出质量的，不是某一句提示词，而是上下文。

文档、历史对话、代码库、业务背景、旧需求、接口说明、页面截图、评审反馈，都是 AI 能否干好活的关键材料。

很多时候，AI 不是不聪明，而是缺少必要材料。

上下文给得足，AI 生成的文档可以接近可评审状态；上下文给得差，再强的模型也只能猜。

需求文档场景中，大部分时间并不是在“让 AI 写”，而是在做 Context Engineering：把需求背景讲清楚，把旧规则找出来，把相关接口和系统关系说明白，把脑中的判断转成 AI 可理解的信息。

5.2 Harness Engineering：让 AI 进入真实工作环境

Agent 出现以后，AI 不再只是回答问题，还可以进入真实工作环境。

Harness Engineering 可以理解为给模型配工具、文件系统、权限、执行环境和循环机制，让它能够读取材料、调用工具、修改文件、检查结果、继续迭代。Codex、Claude Code 等工具，价值就在于让模型进入真实工作现场。它们可以读文件、改代码、检查结果、理解设计稿、生成页面、整理接口文档。

同一个模型，在不同 Harness 里，能力可能差一个数量级。一个只能聊天的模型，和一个能读取上下文、调用工具、循环验证的 Agent，工作价值完全不同。

因此，判断 AI 工具价值时，不应只看模型本身，还要看它能否进入工作现场、能否读取上下文、能否调用工具、能否完成闭环验证。

需求文档撰写 ｜ 交互设计

这两类工作通常占据大量产品经理时间，且都需要结构化表达、上下文理解和持续迭代。

6.1 需求文档撰写：四步跑完一个需求

图 4：需求文档撰写四步法

6.1.1 建立需求文档 Skill

把需求文档的结构、规则、口径和注意事项沉淀下来。后续遇到类似工作时，不需要每次从零解释模板。

6.1.2 交代已知关键节点

调用 AI 前，至少要明确目标、核心流程、关键规则、主要对象、影响范围，以及哪些地方仍不确定。

6.1.4 调用 Skill 生成文档

上下文和关键问题补齐后，再生成文档，准确率会明显提高。AI 负责初稿和结构，人负责判断和定稿。

图 5：Codex Skill Creator 插件

把需求文档工作流沉淀为可复用 Skill，减少每次从零解释模板的成本。

PRD Writer 是典型场景。它可以把需求文档的结构、规则、口径和注意事项沉淀下来，后续遇到类似工作时直接复用。

AI 不应接收一个完全没想清楚的需求，然后替产品经理做产品判断。AI 最适合整理、追问和表达，不适合凭空拍板。

6.2 需求交互设计：快速可视化，但不能代替判断

Figma Make、Figma MCP 等工具让 AI 不再只是生成文案，而是可以进入设计工具，生成页面结构、流程草图和交互方案。

AI 在交互设计里的价值

• 先把想法快速可视化；

• 先形成一个可讨论版本；

• 先把流程和页面关系摊开；

• 再由人围绕真实画面判断和修正。

但交互设计中的 AI 仍然不能代替产品判断。产品经理需要判断：

• 页面层级是否合理；

• 用户路径是否顺畅；

• 异常状态是否完整；

• 业务规则是否表达清楚；

• 开发实现是否可控；

• 测试是否能够验证。

过去可能需要先画很久再组织评审，现在可以先由 AI 搭出骨架，再围绕真实画面讨论。这对需求早期尤其有价值。

把固定文档结构、规则口径和质量标准显性化，后续需求可以直接复用。

7.2 站在成熟方法论的肩膀上

Skill 还有一个重要原则：不要什么都从零开始。

设计规范、写作框架、交互原则、文档结构，都有很多成熟资源可以参考。比如 Apple Human Interface Guidelines、awesome-design 系列资源、GitHub 上高质量 Skill 仓库等。

图 9：Apple Human Interface Guidelines

成熟交互规范可以作为 Skill 本地化改造的基础，而不是每次从零摸索。

更有效使用AI的方式：

先复用成熟方法论，再结合自身业务做本地化改造。

把成熟规范提炼成 Skill，再让 AI 基于这些规范做设计和文档，比单纯依赖个人经验更稳定。

前文可以压缩成四个关键点。

1. 一个数字：34 → 15

AI 的价值从来都不是省略流程，而是重组工作方式。

2. 一种世界观：Prompt → Context → Harness

AI 应用从提示词，走向上下文，再走向工具和执行环境。

3. 一套工作流：PRD 四步法 + Skill 复利 + 成熟规范

建立 Skill、交代关键节点、AI 反向提问、生成 PRD，是一套可复制的文档工作流。

4. 一种信息源：稳定、可信、真实、前沿

学 AI 不靠短视频追热点，而是靠高质量、长期稳定的信息输入。

所有方法的前提仍然是：人是决策者，AI 是劳动者。

10.3 把经验总结成Skill

所有做过两次以上的工作，都值得沉淀。Skill 是个人生产力的复利资产。它能把一次经验变成以后反复可用的流程。

10.4 新工具要尽早体验，但不必焦虑

AI工具更新很快，新东西值得第一时间体验。Codex、Claude Code、Claude Design、Figma Make、Gemini 等工具，都代表了不同方向的探索。

但新工具不成熟也很正常。使用不顺，不一定是使用方式有问题，也可能是工具本身还没到稳定阶段。

使用AI正确心态：先上手，先判断方向，再决定是否纳入长期工作流。

10.5 懂一点底层，避免迷信和错过

不需要人人都变成算法工程师，但至少要理解一些基本概念：

• 模型为什么会幻觉；

• 上下文为什么重要；

• Agent 为什么需要工具；

• 生成内容为什么必须复核；

• 为什么同一个模型在不同工具环境里能力差异很大。

懂一点底层，最大的好处是不会迷信，也不会错过。

AI 可以负责整理、生成和辅助分析，但判断、审核和最终责任必须由人承担。

AI 使用中最需要注意两类风险。

1. 可以依赖，但不能完全依赖

AI 会一本正经地胡说八道。接口、数据、政策、历史规则、系统边界等内容，不能只看 AI 表达是否顺畅，而要回到来源材料里核验。

更稳妥的方式是：

• AI 负责阅读；

• AI 负责整理；

• AI 负责提出疑点；

• 关键结论必须由人确认。

2. AI 是助手，不是责任主体

文档需要人负责，方案需要人评审，业务结果也需要人承担。AI 可以加速，但不能替代责任。

把判断力交出去，不是在使用 AI，而是在逃避判断。

Agent工具的价值，适合通过一个简单流程理解。

图 11：Agent工作流

例如需要处理一个“B 端后台新增批量导入用户模块”的需求，可以按以下步骤推进：

Agent 任务流程：

• 把背景交给 AI；

• 让 AI 反问细节，例如导入格式、失败策略、权限控制、异常提示；

• 补齐上下文；

• 让 AI 生成 PRD 或交互原型；

• 人工检查和修正。

这个过程体现的是一种工作循环，而不是一次性命令：

输入背景 → AI 反问 → 补齐上下文 → AI 生成初稿 → 人工复核 → 继续迭代

真正有效的 AI 使用方式，不是一句话发出去就等结果，而是人和 AI 形成来回迭代。

以下案例是对正文方法论的实战补充，说明方法如何在真实工作中落地。

案例地图

案例	场景	AI用法	可复用经验
支付设置优化	B 端后台设计	真实页面抓取 + 设计 Skill	先读真实结构，再做视觉优化
PRD Writer Skill	需求文档沉淀	模板提炼 + 真实需求验证	Skill 是跑真实需求跑出来的
AI 点餐交互设计	收银系统交互	Gemini 原型 + Figma MCP 精调	先跑通逻辑，再做视觉
AI 分享材料生成	经验分享 PPT	Claude Design + 备注文件审稿	AI 不只是生成器，也可以当编辑
收银系统大需求 PRD	多模块复杂需求	计划模式 + PRD Skill	大需求先反问，不要先生成
接口文档可读化	系统对接	技术材料翻译 + 字段映射	AI 做第一层翻译，人做关键确认
Token 墨水屏Display 硬件	硬件小项目	协议分析 + 脚本生成	先搞清楚协议，再写代码

案例一：支付设置优化

背景

线下收银需要支付设置功能。之前做过的 B 端后台支付设置页，功能都有，但信息堆叠、层级不清晰。

这次想用 Apple HIG 的设计风格重做一版，但不是单纯换皮，而是要保留真实的业务逻辑和交互状态。

图 13：支付设置案例

先抓真实后台页面结构，再做视觉和层级优化，避免靠截图或想象猜业务状态。 

做法

1️⃣ 先把设计规范部署成 Skill

把 awesome-design-md 这个 GitHub 仓库里的设计原则，通过 Codex 部署成本地可调用的 design-md Skill。以后每次做设计，不用重新描述“我要 Apple 风格”。

2️⃣ 抓取真实页面，不靠猜

拿到线上后台地址之后，Codex 先模拟登录，拿到会话 Cookie；发现页面内容在 mainBox iframe 里，再直接抓 iframe 源码，把支付方式列表、开关状态、弹窗结构全部读出来。

3️⃣ 复刻 + 优化，来回迭代

基于真实页面结构，再按 design-md Skill 里的 Apple 风格规则生成初版原型，然后围绕弹窗、搜索、批量设置、快捷键、支付方式等细节反复调整。

关键转折

这次不是“让 AI 画一个好看的页面”，而是先让 AI 读真实页面结构，再用成熟设计规范约束它做方案。

可复用经验

• 做设计不要只把 AI 当画图工具，更有效的方式是先把成熟设计规范部署成 Skill。

• Agent 做设计前要先拿到真实页面结构，靠猜出来的原型容易和实际业务脱节。

• B 端后台设计的核心不是好看，而是层级清晰。

• 迭代中出现“按了葫芦起了瓢”很正常，遇到这类问题要退一步看整体布局逻辑。

案例二：PRD Writer Skill 沉淀

背景

不是一开始就想做 Skill，而是先跑了一个真实需求：原料档案支持删除。跑完之后发现，有些东西值得固定下来，才去做了 PRD Writer Skill。

做法

步骤一：上传需求文档模板，先提炼框架

把公司的需求文档 PDF 模板传给 Codex。PDF 是扫描件，没有文字层，Codex 自己装了 PDF 渲染库，把六页都转成图片，逐页识别，最终提炼出五段式框架：概述、总体流程、功能需求、非功能需求、上线通知。

图 14：PRD Writer案例

先从公司需求文档模板中提炼固定框架，把隐性的写作结构变成可复用骨架。

步骤二：用真实需求跑一遍

把“原料档案支持删除”这个需求丢进去跑。Codex 按框架生成初稿，覆盖背景目标、删除流程、校验顺序、异常提示、上下游依赖、测试验收点，同时追问了成本卡、差异单、积理侧校验等待确认项。

图 15：PRD Writer案例

用“原料档案支持删除”真实需求验证文档框架，AI 同时补出待确认项。

步骤三：折腾过在线文档自动填写，但稳定性不足

曾经想把内容直接填到公司飞书文档里。中间一度能精确按格填表格，但后来越来越偏，填一格跑到别的位置，撤回又撤错。

图 16：PRD Writer案例

自动填充飞书文档一度可行，但在线编辑器结构复杂，稳定性不足。

步骤四：把工作流沉淀成 Skill

最终把完整文档模板框架发给 Codex，让它用 skill-creator 创建 PRD Writer Skill，固定章节顺序、表头、触发场景和信息不全时的标注规则。

图 17：PRD Writer案例

最终把需求文档流程沉淀为 Skill，让后续同类工作不再从空白页开始。

关键转折

在线文档自动填充当时并不稳定，但这次折腾逼出了一个更有价值的结果：把需求文档工作流沉淀成可复用 Skill。

可复用经验

• Skill 不是凭空设计出来的，是跑真实需求跑出来的。

• Agent 填在线文档目前不一定可靠，复制粘贴 + 人工检查反而更稳。

• 凡是做过两次以上的工作就值得做成 Skill。

• 经验结构化以后，才能真正产生复利。

案例三：AI 点餐交互设计

背景

AI 点餐收银系统需要加两个新功能：AI 识别菜品、定额收银。

这不是单页设计，而是一套完整的交互链路：识别怎么触发、结果怎么确认、识别不准怎么纠错、菜品怎么更换、价格怎么调整。

做法

步骤一：用 Gemini 把交互逻辑跑通

不是直接开 Figma 画，而是先把业务场景和流程描述给 Gemini，让它生成一个 React 可交互原型。

这个过程是真实的来回迭代：

• 单品识别确认弹窗太重，改成清单式批量确认；

• 增加识别区域标注，左侧快照和右侧清单序号对应；

• 增加合计价格修改功能，支持快捷加减和直接输入；

• 因为是安卓收银系统没有物理键盘，改成自定义数字软键盘；

• 更换菜品的交互从“点击菜品名触发”改成“独立文字按钮”，更适合触屏操作。

中间还有一条逻辑自然浮出来：更换菜品后要不要上报训练数据？上报影响下次识别，不上报不影响。

图 18：AI点餐案例

先用 Gemini 跑通识别、确认、纠错、改价等交互链路，再进入设计精调。

步骤二：把代码搬进 Figma 精调

Gemini 跑通交互逻辑之后，把代码给 Figma MCP，让它复刻成可编辑的设计稿。Figma 里的调整主要是视觉细节：暗色改白色、修复菜品行折行、提示区域从按钮感改成纯文字提示条。

图 19：AI点餐案例

代码原型跑通逻辑后，再搬进 Figma MCP 做视觉、状态和触屏细节调整。

最终产出

一套完整的 AI 识别收银交互方案：

触发 → 识别 → 确认 / 纠错 → 更换菜品 → 价格调整 → 结算

每个节点的交互状态都有，可以直接进入评审讨论。

可复用经验

• Agent 工具适合处理复杂但可结构化的设计任务。

• 先用代码原型跑通逻辑，再进 Figma 精调视觉，两个工具各做各擅长的事。

• 不要期待一次生成正确，这套方案需要来回迭代，每轮解决一个具体问题。

• 设计过程会逼出需求里没写的逻辑，例如“更换菜品后要不要上报训练数据”。

案例四：AI 分享材料生成

背景

组里要做 AI 使用经验分享，时间紧，PPT 还没做。4 月 18 日 Claude Design 发布，4 月 19 日凌晨直接试用，10 分钟出成果。（当然，还是提前已经想好了要分享的内容）

做法

步骤一：先喂信息，不要直接让它生成

Claude Design 上来会先问一份问卷，把受众、时长、目标、个人背景、高频场景、杀手锏案例、风格都交代清楚。

图 20：分享材料案例

受众、时长、目标、风格和关键案例交代越清楚，Claude Design 的初稿越贴近真实需求。

步骤二：初稿出来后，上传自己的备注文件

Claude Design 出了 22 张初稿之后，把自己之前手写的 PPTX 备注文件也上传进去，让它读。它发现了时间线偏差、精华内容被埋、回顾页没有覆盖新增内容等问题。

步骤三：逐条对齐，最终 34 张全配演讲稿

根据它发现的问题逐条处理：新增“信息源四要素”和“御四家”两张独立页；回顾页从三个关键点升级成四个；讲稿全部用自己的原话重写。

可复用经验

• 做分享材料时，先交代受众、时长、目标、风格和关键案例，不要只说“帮我做 PPT”。

• 初稿出来后，把备注、旧材料、草稿再喂给 AI，让它找缺口。

• AI 不只是生成器，也可以是编辑和审稿人。

案例五：收银系统大需求 PRD

背景

这批需求包含五个模块同时推进：POS 开票、部分退款、手动折扣、菜品数据本地化、菜品排序优化。

每个模块都有上下游系统依赖，模块之间还有逻辑交叉。按过去的做法，这批需求估计需要 34 个人日，包括沟通、交互设计、文档撰写和评审。

图 21：收银大需求案例

五个模块之间存在开票、退款、折扣、本地化、排序等跨分支联动。

做法

步骤一：先把 AI 拉回计划模式

第一次输入不是直接让 AI 写文档，而是五个需求的原始描述，外加一句话：

先不着急生成需求文档，我一点一点给你交代信息，咱们互相沟通完，发现没有逻辑漏洞以后咱们最后生成需求文档。

这一步很关键。如果让 AI 先生成，你会进入“修改初稿”的模式，思路跟着 AI 走；让 AI 先反问，你是主动想清楚再交代，最终文档质量完全不同。

步骤二：让 AI 逐条追问逻辑坑

AI 提前标出了多个关键问题：支付刚完成时海博订单大概率还没生成，小票上的二维码绑定谁？混合支付订单能不能开票？指定金额退款是否必须选菜品？手动优惠和现有营销活动的先后顺序怎么定？部分退款发生后，已经打印过的开票二维码还能不能用？

图 22：收银大需求案例

先让 AI 进入澄清模式，提前追问关键逻辑坑，而不是一上来生成 PRD。

这些问题把核心规则提前倒逼出来：

• 开票链路先申请开票链接打印二维码，等海博落单后扫码才能真正开票；

• 指定金额退款不做，需求直接缩水一半；

• 手动优惠优先级大于营销活动，取消手动优惠后营销活动自动恢复；

• 没开票的可以对剩余未退部分开票，已开票的走冲红逻辑。

步骤三：调用 PRD Writer 生成初稿

对齐完五个分支、拍板跨分支逻辑后，调用自建 PRD Writer Skill 生成初稿。初稿大约 80% 的结构可以直接用，主要补异常提示文案、待评审项边界说明、跨系统联动描述。

步骤四：评审时直接讨论关键问题

开发侧反馈：“这次退款和开票之间的关系写清楚了，之前总是评审完了还要问。”冲红方式也明确标成“待评审项，备选方案 A/B”，评审时财务直接针对这一条讨论，没有绕弯。

关键转折

34 → 15 背后，不是流程省了，而是工作方式变了：

背景输入 → AI 反问 → 逐条对齐 → Skill 生成初稿 → 人工确认边界和异常

可复用经验

• 大需求不要上来就让 AI 写文档，先把 AI 拉到澄清模式。

• 跨分支问题最容易漏，适合让 AI 帮忙做关系检查。

• 待定项要显式标出来，不要假装已经确定。

• AI 生成初稿的价值，不是一次写对，而是让人从空白页中解放出来

案例六：接口文档可读化

背景

小精灵扫码点餐系统需要和京东海博餐饮 SaaS 打通。

目标是让用户用小精灵扫码点餐，订单落到海博系统（数字化管理系统）里，商品、库存、订单等基础设施都走海博，小精灵只作为点餐入口。

我负责商品部分，需要建立两边的商品绑定关系，涉及商品拉取、SKU 绑定、下单翻译、状态同步等多个模块。

图 23：接口文档案例

先说明系统对接背景和商品部分边界，再让 AI 帮忙组织接口清单和字段映射。

做法

步骤一：先交代背景，让 AI 反问

没有直接让 AI 写文档，而是先把背景说清楚：两个系统需要打通，海博出 API，小精灵接，我主导商品部分，需要出整体方案 + 接口清单 + 字段映射表。

AI 随即提了三个问题：能拿到哪边的数据模型？希望先产出哪个？谁主导、谁配合？

这一步的价值，是逼着自己在动笔之前先把边界和资源想清楚，而不是拿到需求就开始写。

步骤二：喂材料，让 AI 做第一层翻译

陆续上传海博后台商品管理截图和小精灵 API 接口文档。AI 从接口文档里提取接口用途、关键字段、入参出参、调用时机、异常码，把技术语言翻译成产品语言，输出字段映射关系。

图 24：接口文档案例

把海博截图和小精灵 API 文档交给 AI 做第一层翻译，先把技术材料变成产品可读语言。

边界也很清楚：AI 做的是第一层翻译。

接口含义和系统边界还是要和开发确认，不能只凭摘要定稿。

图 25：接口文档案例

字段、接口和业务规则需要继续回到来源材料确认，不能只凭 AI 摘要定稿。

图 26：接口文档案例

技术材料被可视化梳理后，更容易定位系统边界、调用时机和异常规则。

步骤三：生成初稿，中途发现逻辑错误

AI 基于截图和接口文档生成 V1.0，覆盖绑定流程、下单翻译、状态同步等模块。看到“售罄推送”这一节时，发现不对：海博根本没有售罄 / 沽清的概念，只有上下架。

于是提出：海博只有下架功能，是不是应该对应小精灵的下架？

AI 随即反问：海博的库存模块里确实没有沽清 / 售罄的概念吗？还是可能在库存模块有但你没看到？因为这会影响 Webhook 事件的设计。

这个反问很关键。售罄和下架是两个不同概念。售罄是今天卖完明天可能恢复，下架是从菜单移除不再售卖，两个对应不同的业务逻辑和接口设计。

图 27：接口文档案例

发现“售罄 / 下架”概念差异后，先确认业务含义，再调整文档和 Webhook 设计。

步骤四： 文档迭代，三个版本定稿

确认之后文档同步调整：去掉售罄状态查询和售罄 Webhook，改为下架状态同步 Webhook；下单校验从“是否售罄”改为“该 SKU 在门店是否上架”。

V1.0 → V1.1 → V1.2，三版迭代，最终文档覆盖背景目标、用户分析、指标、名词解释、功能需求、接口清单、上线通知。

顺手也沉淀了一个 channel-product-integration Skill，包含对接模式判断、信息收集清单、字段映射表模板、PRD 模板。下次接入新渠道直接复用，不用从零摸索。

可复用经验

• 不要拿到需求就让 AI 写，先交代背景让 AI 反问，把遗漏的规则逼出来。

• AI 适合做技术材料的第一层翻译，但关键结论要回到来源和开发确认。

• 中途发现错误是正常的，AI 初稿的价值不是一次对，而是让问题更早暴露。

• 做过一次的项目就值得沉淀成 Skill。

案例七：Token 墨水屏Display硬件

手里有一块 4.2 寸三色墨水屏（电子价签），想让它实时显示 Claude Pro 的剩余额度，放在桌上作为环境感知信息：不需要主动打开工具，抬头就能看到。

这个需求没有现成方案，需要从零搞清楚屏幕怎么驱动、数据怎么拉取、怎么定时刷新。

图 28：墨水屏案例

最终把 Claude Pro 额度显示到桌面电子价签上，让工具状态变成可感知的环境信息。

做法

步骤一：发现屏幕对接不是想象中的简单

一开始拿到屏幕，不确定型号。把设备名 ZKC42V和ESL_BWR 都丢给AI判断：这是零售店用的电子价签，走 Zkong 私有协议，没有开源驱动，必须配专用基站硬件才能用。

正常到这里就卡死了。

但接着找到一个网页工具，可以通过蓝牙连接这块屏幕推送图片。方向变了：不走私有协议，走这个网页的蓝牙通道。

步骤二：逆向网页协议，搞清楚怎么推数据

把网页源码直接发给 AI，让它分析蓝牙通信协议。AI 从 JS 源码里提取出了完整的 GATT 结构、命令字节表、数据包格式和分块传输逻辑。

图 29：墨水屏案例

通过网页 JS 分析 Web Bluetooth 通信协议和命令结构，找到不依赖专用基站的可行路径。

这一步的价值是：不需要抓包，不需要逆向固件，直接读前端 JS 就把协议搞清楚了。

步骤三：用 Agent 写完整方案，边跑边修

有了协议之后，用 Codex 直接写 Python 脚本：拉取 Claude Pro 额度数据，生成黑白 + 红色双通道图片，通过 BLE 推送到屏幕，再设置 cron 每 5 分钟自动刷新。

过程中遇到了真实硬件问题：

• CoreBluetooth 缓存导致 TimeoutError；

• 设备广播窗口有限；

• APP 图标偶尔消失。

最终加了菜单栏快捷按钮、LaunchAgent 和机会主义推送机制。

最终状态

桌面上放了一块墨水屏，每 5 分钟自动刷新，显示 Claude Pro 的额度使用情况。

整个系统由三部分组成：

模块	作用
epd_daemon.py	BLE 推送守护进程，扫到设备就推，扫不到跳过
epd_manager.py	菜单栏管理 APP，可以手动触发推送和蓝牙切换
cron 定时任务	每 5 分钟触发一次

可复用经验

• 遇到未知硬件，先搞清楚它走什么协议，再判断有没有可行路径，不要上来就写代码。

• 网页工具的 JS 源码是宝藏，Web Bluetooth API 的通信逻辑全在里面。

• 硬件项目必须接受反复调试，TimeoutError、广播窗口、缓存问题都是真实存在的。

• Agent 工具适合这类“想法 → 跑通”的任务，从协议分析到完整脚本到菜单栏 APP，全程可以在 Codex 里推进。

回头看这7个案例，有一条线索贯穿始终：

• PRD Writer 是跑真实需求跑出来的，不是设计出来的；

• 支付设置页是先抓真实页面结构再做的，不是靠猜；

• 收银系统五个分支是先对齐逻辑再生成的，不是直接让 AI 写；

• 墨水屏是先搞清楚协议再写代码的，不是上来就动手。

每一个用对了的地方，背后都是人先想清楚了，AI 才做得好。

AI 最适合处理重复劳动、结构化劳动、初稿劳动和资料整理。它可以帮你更快写文档、更快做原型、更快理解接口、更快把想法变成可以讨论的东西。

但它不能替代最终责任。业务目标、流程边界、风险取舍、评审结论，还是要人来负责。

真正会用 AI 的人，不是把判断力交出去的人，而是更会组织上下文、更会提出问题、更会沉淀方法、更会验证结果的人。

这也是 34 → 15 这个数字背后真正的答案：

不是 AI 替你做了什么，而是你把精力放回到了真正值得人来做的事上。

AI 的牌局才刚开始。先用起来，边用边学，把能复用的沉淀下来，比短期追热点重要得多。