本文面向集团内部同事，聚焦 AI 在 B 端产品工作中的真实使用方法。
正文以方法论为主，附录补充实战案例。方法论解决三个问题：为什么用、怎么用、边界在哪里。案例库解决一个问题：这些方法到底怎么落到真实工作里。

💡  如果只保留一句话：人是决策者，AI 是劳动者。

AI 的价值不是替代判断，而是重组工作方式。

• 正文部分：适合快速理解 AI 在 B 端产品工作中的价值、方法和边界。
• 附录部分：适合结合具体案例回看，理解这些方法怎么落到真实工作里。
• 图示说明：文中配有关键流程图和案例图，方便快速理解整体方法。

🚀  开场：AI 的价值，不是追热点，而是重组工作方式

先放一个个人实践中的真实结果：

📌   34 个人日 → 15 个人日

     今年四月份，手里有一批原本预计需要 34 个人日完成的需求工作，范围覆盖接需求、沟通、交互、文档撰写和评审。

     最终用 15 个人日完成，并顺利通过评审，质量没有打折。

     这个结果背后的关键，不是让 AI 替我们做决策，而是逐步形成一套稳定的 AI 工作方式。

✅   一套可复用的 AI 产品工作流：

1. 把业务背景和关键判断交代清楚；
2. 让 AI 反向追问缺失信息；
3. 用固定模板或 Skill 生成结构化初稿；
4. 由人复核业务边界、系统联动、异常规则和评审表达；
5. 把可复用经验沉淀下来，进入下一次工作。

图 1：AI 在产品工作中的价值。它不是替代判断，而是把背景输入、反向追问、结构化初稿和人工复核串成稳定工作流。

AI 对产品工作的价值，不在于制造新概念，也不在于替代人的判断。

它真正有用的地方，是把大量重复劳动、结构化劳动和初稿劳动先跑起来，让产品经理把更多精力放回业务理解、流程判断、异常处理和方案取舍。

B 端产品工作天然适合引入 AI。需求落地前的流程梳理、交互设计、需求文档撰写、评审沟通，都具有明显的文字密集、逻辑密集、图形密集特征，并且高度依赖上下文。

📌   真正消耗时间的，往往不是“打字”。

     而是反复整理信息、确认规则、检查遗漏、补齐异常分支、把口头判断转成可评审文档。

     AI 如果使用得当，能显著降低这部分成本。

🧭 本文会回答的五个问题

📌  一、为什么开始认真使用 AI：“不爱写文档”

坦白说，在进入当前更规范的协作流程之前，我并不是一个很爱写文档的产品经理（其实压根没写过hhh）。

以前同时负责过加油站 APP、餐饮手机端、餐饮收银系统、叫号屏、划菜屏、餐饮后台、代理商后台等多个端。那时的工作方式更偏向“先想清楚，再当面讲清楚”。

⚡️   过去的工作方式：重沟通，轻文档

• 先把流程和页面交互想清楚；
• 评审时拉齐开发、测试和业务方，把需求讲清楚；
• 中途有问题就坐在一起讨论，当场解决。

   这种方式的优势是速度快、沟通直接、反馈及时。

对当时的我来说，文档不是最核心的产物，真正重要的是相关角色是否理解这件事怎么做。

但在更复杂的组织环境里，文档沉淀无法绕开。

需求需要进入统一协作平台，需要有评审记录，需要沉淀背景、规则、异常、验收标准和历史依据。文档不只是服务当前开发测试，也服务后续追溯、交接和复盘。

💡   这也是 AI 进入产品工作流的起点。

     当文档从“可选表达”变成“组织协作的必要资产”，产品经理就必须解决两个问题：

• 如何减少低价值的文档体力劳动；
• 如何保证文档不只是写得快，而是写得完整、准确、可评审。

AI 的价值正是在这里出现。

它可以把口头判断、流程理解、规则边界和评审材料转成结构化内容，同时帮助检查遗漏、追问细节、补齐异常分支。

✅   AI 在文档工作里的价值

• 把零散口头信息整理成结构；
• 把隐含规则变成显性条目；
• 把流程分支和异常情况提前摊开；
• 把评审材料从空白页推进到可讨论初稿；
• 把可复用经验沉淀成模板或 Skill。

所以，AI 使用的核心目标不是“看起来先进”，而是让产品工作更稳、更快、更可复用。

🎯  二、使用 AI 的三个目标

我个人使用 AI 的目标，可以分为三层：短期、中期和长期。

1. 短期目标：减少重复劳动，提高工作效率

最朴素的目标，就是减少无效加班。

大量产品工作不是难在“想不出来”，而是难在重复整理：

• 把会议内容整理成纪要；
• 把口头需求整理成结构；
• 把流程分支补齐；
• 把评审材料写完整；
• 把不确定项标出来。

🧱   适合先交给 AI 跑初稿的工作

• 会议纪要；
• 需求结构；
• 流程分支；
• 异常清单；
• 验收标准；
• 待确认问题。

这些工作适合交给 AI 先跑初稿。人的精力则回到判断、确认和修正上。

2. 中期目标：把产品做精、做好、做接地气

效率不是最终目的，产品质量才是。

AI 节省下来的时间，不应该只变成“更快交差”，而应该投入到更重要的地方：业务理解、用户场景、流程边界、异常处理、系统联动、验收标准。

❗️   B 端产品最怕的不是页面不好看，而是规则没想清楚。

     很多问题不是视觉问题，而是：

• 规则是否清楚；
• 流程是否闭环；
• 异常是否兜住；
• 开发测试是否理解一致。

AI 可以帮助产品经理更快把信息摊开，但最终仍要由人判断方案是否合理。

3. 长期目标：打通产品、设计、开发上下游

随着 Codex、Claude Code、Figma Make 等 Agent 工具出现，产品经理能更直接地把想法推进到原型、页面甚至代码层。

这意味着产品经理的工作边界正在变化：不只是提出需求，也可以更快验证原型、更快形成设计草案、更快理解技术材料、更快推动方案从概念进入可讨论状态。

🚀   产品经理可以更快完成这些动作

• 更快验证原型；
• 更快形成设计草案；
• 更快理解技术材料；
• 更快推动方案从概念进入可讨论状态；
• 更快发现方案里的逻辑漏洞。

但越是让 AI 进入执行层，越要重视验证。

AI 写代码、生成原型、整理接口，都能提高产出速度，也会带来新的检查压力。测试、复核、校验不能被省略。

这一点对产品、设计、开发、测试同学都成立。

📈 三、AI 给产品工作带来的真实效率变化

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

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

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

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

• 这个分支有没有漏？
• 异常应该怎么处理？
• 页面和系统是否有联动？
• 规则是否影响旧流程？
• 测试是否能够验证？

AI 介入后，工作方式可以调整为：

✅   从空白页工作，变成循环式工作

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

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

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

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

🧱 四、AI 应用演进

过去三年，AI 应用能力的演进可以概括为三个关键词：

🧱 Prompt → Context → Harness

这三个词对应 AI 从“会回答问题”到“能进入工作现场”的变化。

图 3：Prompt、Context、Harness 三层演进。AI 从“会回答问题”，逐步走向“能进入真实工作现场”。

1. Prompt Engineering：把问题问清楚

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

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

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

📝   更好的提示方式

• 按 B 端产品经理视角处理；
• 按背景、目标、流程、规则、异常、验收标准组织；
• 不确定信息标为待确认；
• 输出 Markdown；
• 先提出问题，再生成文档。

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

2. Context Engineering：把上下文给足

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

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

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

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

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

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

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

Harness Engineering 可以理解为给模型配工具、文件系统、权限、执行环境和循环机制，让它能够读取材料、调用工具、修改文件、检查结果、继续迭代。

Codex、Claude Code 等工具，价值就在于让模型进入真实工作现场。它们可以读文件、改代码、检查结果、理解设计稿、生成页面、整理接口文档。

🚀   同一个模型，在不同 Harness 里，能力可能差一个数量级。

     一个只能聊天的模型，和一个能读取上下文、调用工具、循环验证的 Agent，工作价值完全不同。

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

🛠 五、产品工作中最核心的两个 AI 使用场景

当前产品工作中，AI 杠杆最大的两个场景是：

📄 需求文档撰写 ｜ 🎨 交互设计

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

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

图 4：需求文档撰写四步法。先建立 Skill，再交代关键节点、让 AI 反向提问，最后生成可评审初稿。

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

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

❗️   AI 不应接收一个完全没想清楚的需求，然后替产品经理做产品判断。

     AI 最适合整理、追问和表达，不适合凭空拍板。

2. 交互设计：快速可视化，但不能代替判断

另一个核心场景是交互设计。

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

🎨  AI 在交互设计里的价值

• 先把想法快速可视化；
• 先形成一个可讨论版本；
• 先把流程和页面关系摊开；
• 再由人围绕真实画面判断和修正。

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

• 页面层级是否合理；
• 用户路径是否顺畅；
• 异常状态是否完整；
• 业务规则是否表达清楚；
• 开发实现是否可控；
• 测试是否能够验证。

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

🧩 六、Skill：把个人经验变成可复用资产

Skill 是 AI 使用中非常重要的一类资产。

图 6：Skill 的价值。把重复工作沉淀成可复用资产，让经验持续复利。

Skill 的本质，是把一类常做任务沉淀成可复用、结构化的指令。它不是简单 Prompt，而是包含任务目标、工作流程、输入要求、输出格式、质量标准和边界规则的小型方法论。

💡   一个好的 Skill，等于给未来的自己打工。

     凡是做过两次以上的工作，都值得考虑沉淀成 Skill。

比如：

• 写 PRD；
• 写周报；
• 梳理接口文档；
• 做竞品分析；
• 做交互评审；
• 做会议纪要；
• 做需求影响范围分析。

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

图 8：交互设计 Skill 示例。把交互设计流程、输出格式和检查标准沉淀为可复用资产。

这些工作都有固定套路，如果每次都从零开始，就是浪费。

站在成熟方法论的肩膀上

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

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

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

✅   更有效使用AI的方式

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

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

📡 七、学习 AI 的关键：信息源决定天花板

学 AI 不只是学工具按钮，更重要的是建立高质量信息源。

尤其在当前阶段，AI 发展很快，传统学习方式容易滞后。一本书从选题到出版，可能已经过去几个月；一门课从录制到上线，也可能跟不上工具更新。

📌   高质量信息源的四个标准

• 稳定：能够持续跟进，而不是偶尔刷到；
• 可信：来自一手材料、官方发布或真实从业者；
• 真实：有业务实践、产品判断和失败经验；
• 前沿：能看到工具、模型和产业变化的最新方向。

短视频更适合获取线索，不适合建立系统判断。三五分钟内容很难讲透真正的方法论。

真正值得长期投入的，是 CEO 级别、核心从业者级别的长访谈。三四个小时的长访谈里，可能夹杂英文术语，表达也不一定完全包装精致，但往往包含很多未经整理的一手判断。

💡  建议每周至少投入 4 到 5 小时在高质量长内容上。

值得关注的一手声音

选择国内内容时，我更看重三点：

• 是否持续跟进前沿变化；
• 是否能把国外一手信息转译成中文语境；
• 是否能结合国内产品、商业和组织环境做出自己的判断。

其中，水球泡我个人比较推荐。他的内容通常不是简单搬运热点，而是会结合 AI 工具变化、产品趋势和实际使用体验做拆解，对想持续理解 AI 发展的人比较友好。

当然，国内内容更适合作为“理解和转译”的入口。真正重要的判断，仍然建议回到一手材料、官方发布、长访谈和真实业务实践中交叉验证。

🧠 八、方法论小结：四个关键点

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

💡   所有方法的前提仍然是：

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

✋ 九、五条使用心得

1. 用能力最强的大模型处理关键任务

关键任务不建议过度节省模型成本，也不建议用能力不足的小模型处理重要工作。

写需求、做方案、梳理复杂材料时，模型能力会直接影响结果质量。很多时候，人的时间比工具订阅费更贵。

❗️   同时，任何工具使用都必须遵守公司安全、合规和数据要求。

     涉密材料、客户信息、交易数据、内部接口等内容，不应随意投喂到不受控环境。

2. 通过持续使用建立手感

AI 不是看教程学会的，而是用出来的。

可以从小任务开始：

• 整理会议纪要；
• 把口头需求改成结构化描述；
• 列出异常分支；
• 检查 PRD 是否遗漏；
• 把接口文档翻译成产品语言；
• 把设计规范应用到具体页面。

用得越多，越能判断 AI 能做什么、不能做什么。

3. 把经验总结成 Skill

所有做过两次以上的工作，都值得沉淀。

Skill 是个人生产力的复利资产。它能把一次经验变成以后反复可用的流程。

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

AI 工具更新很快，新东西值得第一时间体验。

Codex、Claude Code、Claude Design、Figma Make、Gemini 等工具，都代表了不同方向的探索。

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

✅   使用AI正确心态：

     先上手，先判断方向，再决定是否纳入长期工作流。

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

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

• 模型为什么会幻觉；
• 上下文为什么重要；
• Agent 为什么需要工具；
• 生成内容为什么必须复核；
• 为什么同一个模型在不同工具环境里能力差异很大。

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

⚠️ 十、使用边界与常见风险

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

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

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

🔁 十一、可复制的 Agent 任务流程

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

图 12：Agent 工作流。关键不是一次性生成，而是输入背景、AI 反问、补齐上下文、生成初稿、人工复核、持续迭代。

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

✅   Agent 任务流程

• 把背景交给 AI；
• 让 AI 反问细节，例如导入格式、失败策略、权限控制、异常提示；
• 补齐上下文；
• 让 AI 生成 PRD 或交互原型；
• 人工检查和修正。

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

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

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

🛤 十二、推荐学习路径

1. 设计资源

图 13：设计资源推荐。Apple HIG、awesome-design 系列资源与 GitHub 高质量 Skill 仓库，可以帮助产品经理借助成熟规范和方法沉淀，减少从零摸索的成本。

2. 入门课程

可以根据基础选择（点击可跳转）：

• 🔗  李宏毅《生成式 AI 导论》
• 🔗  3Blue1Brown 关于神经网络的动画讲解:
• 🔗  吴恩达《AI for Everyone》:

这些课程不一定直接讲某个工具怎么操作，但能帮助建立基础直觉：AI 能做什么，不能做什么，为什么会这样。

图 14：AI 入门课程推荐。李宏毅《生成式 AI 导论》、3Blue1Brown 神经网络动画讲解和吴恩达《AI for Everyone》，更适合帮助初学者建立基础直觉。

3. 工具和心态

工具上，可以重点关注 Claude、Codex、Claude Code、Figma Make、Gemini 等。

心态上，需要把握五点：

✅  工具使用心态

• 先用起来；
• 边用边学；
• 不必等完全准备好；
• 不因工具不成熟而焦虑；
• 把能复用的经验沉淀下来。

图 15：AI 工具与使用心态。Claude、Codex、Claude Code、Figma Make、Gemini 等工具代表了 AI 进入写作、代码、设计和多模态协作场景的不同方向。

AI 的牌局才刚开始。拥抱变化，持续使用，沉淀方法，比短期追热点更重要。

🌟 结语：AI 不是替代判断力，而是放大判断力

如果只保留一句话，就是：

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

AI 最适合处理重复劳动、结构化劳动、初稿劳动和资料整理。它可以帮助产品经理更快写文档、更快做原型、更快理解接口、更快学习新知识。

但 AI 不能替代最终责任。

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

这也是 AI 使用中最重要的原则。

📚 附录：实战经验案例库

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

案例地图

案例一：支付设置优化

📌   背景

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

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

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

做法

关键转折

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

可复用经验

• 做设计不要只把 AI 当画图工具，更有效的方式是先把成熟设计规范部署成 Skill。
• Agent 做设计前要先拿到真实页面结构，靠猜出来的原型容易和实际业务脱节。
• B 端后台设计的核心不是好看，而是层级清晰。
• 迭代中出现“按了葫芦起了瓢”很正常，遇到这类问题要退一步看整体布局逻辑。

案例二：PRD Writer Skill 沉淀

📌   背景

不是一开始就想做 Skill，而是先跑了一个真实需求：原料档案支持删除。

跑完之后发现，有些东西值得固定下来，才去做了 PRD Writer Skill。

做法

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

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

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

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

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

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

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

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

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

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

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

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

关键转折

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

可复用经验

• Skill 不是凭空设计出来的，是跑真实需求跑出来的。
• Agent 填在线文档目前不一定可靠，复制粘贴 + 人工检查反而更稳。
• 凡是做过两次以上的工作就值得做成 Skill。
• 经验结构化以后，才能真正产生复利。

案例三：AI 点餐交互设计

📌   背景

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

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

做法

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

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

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

• 单品识别确认弹窗太重，改成清单式批量确认；
• 增加识别区域标注，左侧快照和右侧清单序号对应；
• 增加合计价格修改功能，支持快捷加减和直接输入；
• 因为是安卓收银系统没有物理键盘，改成自定义数字软键盘；
• 更换菜品的交互从“点击菜品名触发”改成“独立文字按钮”，更适合触屏操作。

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

图 22：AI 点餐案例。先用 Gemini 跑通识别、确认、纠错、改价等交互链路，再进入设计精调。

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

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

图 23：AI 点餐案例。代码原型跑通逻辑后，再搬进 Figma MCP 做视觉、状态和触屏细节调整。

最终产出

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

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

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

可复用经验

• Agent 工具适合处理复杂但可结构化的设计任务。
• 先用代码原型跑通逻辑，再进 Figma 精调视觉，两个工具各做各擅长的事。
• 不要期待一次生成正确，这套方案需要来回迭代，每轮解决一个具体问题。
• 设计过程会逼出需求里没写的逻辑，例如“更换菜品后要不要上报训练数据”。

案例四：AI 分享材料生成

📌   背景

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

做法

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

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

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

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

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

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

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

关键转折

最省力的地方不是“让它生成”，而是“让它发现我没意识到的问题”。

上传备注文件这个动作，相当于把一个能读懂你意图的编辑拉进来，帮你把散落在各处的素材重新整合进 PPT。

可复用经验

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

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

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

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

📌   背景

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

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

图 25：收银大需求案例。五个模块之间存在开票、退款、折扣、本地化、排序等跨分支联动。

做法

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

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

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

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

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

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

图 26：收银大需求案例。先让 AI 进入澄清模式，提前追问关键逻辑坑，而不是一上来生成 PRD。

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

• 开票链路先申请开票链接打印二维码，等海博落单后扫码才能真正开票；
• 指定金额退款不做，需求直接缩水一半；
• 手动优惠优先级大于营销活动，取消手动优惠后营销活动自动恢复；
• 没开票的可以对剩余未退部分开票，已开票的走冲红逻辑。

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

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

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

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

关键转折

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

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

可复用经验

• 大需求不要上来就让 AI 写文档，先把 AI 拉到澄清模式。
• 跨分支问题最容易漏，适合让 AI 帮忙做关系检查。
• 待定项要显式标出来，不要假装已经确定。
• AI 生成初稿的价值，不是一次写对，而是让人从空白页中解放出来。

案例六：接口文档可读化

📌   背景

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

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

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

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

做法

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

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

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

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

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

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

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

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

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

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

图 30：接口文档案例。技术材料被可视化梳理后，更容易定位系统边界、调用时机和异常规则。

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

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

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

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

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

图 31：接口文档案例。发现“售罄 / 下架”概念差异后，先确认业务含义，再调整文档和 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 的剩余额度，放在桌上作为环境感知信息：不需要主动打开工具，抬头就能看到。

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

图 32：Token 墨水屏案例。最终把 Claude Pro 额度显示到桌面电子价签上，让工具状态变成可感知的环境信息。

做法

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

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

正常到这里就卡死了。

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

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

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

图 33：Token 墨水屏案例。通过网页 JS 分析 Web Bluetooth 通信协议和命令结构，找到不依赖专用基站的可行路径。

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

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

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

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

• CoreBluetooth 缓存导致 TimeoutError；
• 设备广播窗口有限；
• APP 图标偶尔消失。

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

最终状态

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

整个系统由三部分组成：

可复用经验

• 遇到未知硬件，先搞清楚它走什么协议，再判断有没有可行路径，不要上来就写代码。
• 网页工具的 JS 源码是宝藏，Web Bluetooth API 的通信逻辑全在里面。
• 硬件项目必须接受反复调试，TimeoutError、广播窗口、缓存问题都是真实存在的。
• Agent 工具适合这类“想法 → 跑通”的任务，从协议分析到完整脚本到菜单栏 APP，全程可以在 Codex 里推进。

🧩 附录结语

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

• PRD Writer 是跑真实需求跑出来的，不是设计出来的；
• 支付设置页是先抓真实页面结构再做的，不是靠猜；
• 收银系统五个分支是先对齐逻辑再生成的，不是直接让 AI 写；
• 墨水屏是先搞清楚协议再写代码的，不是上来就动手。

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

如果只保留一句话，就是：

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

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

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

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

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

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

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

END