AI-Native 转型半年后，我的工作系统长这样

半年前我写了第 1 篇，讲业务同事拿着 Claude Code 做的 demo 来找我对需求。5 篇文章之后，系列完结了。

回头看，真正改变我的东西很具体：整个工作系统换了。

Axure 从常用列表移到了"偶尔打开"。写 prompt 从对话变成了 skill。盯进度从人肉变成了自动。这篇文章不讲之前讲过的事，只讲半年后我实际在用的东西。

接到新需求，我不再先画原型

现在有新需求进来，第一步是整理背景：业务目标是什么，谁在用，为什么现在做，现有流程卡在哪里，有哪些历史包袱不能碰。

然后把这些丢给 AI，让它帮我补上下文。

这一步很像找一个不太累的同事一起过脑子。它不一定给最终答案，但会把我没写出来的东西逼出来：这个需求其实涉及两个角色？有个隐藏的审核环节？这个指标是给业务看还是给运营看？

之后才是方案。让 AI 拆几个方向——保守方案、理想方案、最小上线方案。再让它站业务、研发、运营三个视角挑刺。方向差不多了，就用 Claude Code 或 Codex 做一个高保真 demo。

这个 demo 不一定会被直接开发。但它有一个原型替代不了的作用：大家终于在看同一个东西了。

业务看到的是页面上有没有它要的信息。研发看到的是数据从哪里来、状态怎么流转。我能更快发现方案哪里想得太满，哪里可以砍掉。以前很多评审都在想象里进行，现在至少有一部分讨论落在屏幕上。

我把注意力从盯进度上挪开了

产品经理有一类工作很琐碎：版本进度要看，需求状态要确认，风险要提前抛，卡点要追。以前这些基本靠人肉。

人肉盯能做，但它很耗注意力。一天里被这些小事切几次，脑子会很碎。

现在我把一部分固定任务交给 Hermes 和 cronjob。到期自动确认，固定周期自动检查，某些状态自动触发提醒。它们不复杂，但很有用：因为这些事不该每次都靠我临时想起来。

这也是我对 AI-Native 理解最深的变化。它包含两个部分：用 AI 写东西，以及把自己的工作习惯改造成系统。以前我会觉得 PM 强在能扛事、能盯细节。现在我更关心哪个问题不该继续占用我的注意力。

我搭了一个业务知识库

AI 输出不好，很多时候问题不在模型，在于它完全不知道你的业务上下文。

所以知识库是第一步。不需要多精致，但要持续积累。我会往里放这几类东西：

业务背景：客户是谁，业务怎么赚钱，关键指标是什么。 产品地图：有哪些系统、模块、角色、权限、数据对象。 历史需求：做过什么，为什么做，当时怎么取舍的。 评审纪要：业务、研发、设计反复争论过什么。 我的判断习惯：什么情况要保守，什么可以先出 demo，什么风险必须提前说。

这些内容放进去以后，AI 的回答明显变了。它不再从互联网上找一个通用答案，而是开始贴近你的业务场景。

如果现在开始转型，我会先做这几件事

不建议一上来研究一堆工具。工具会变，今天是 Claude Code 和 Codex，明天又会有新的。要练的是工作方式。

从自己的项目开始，把你负责的业务整理成 AI 能读的材料，不用等公司统一建知识库。同时挑一个最烦、最高频、最容易重复的工作——需求拆解、验收清单、风险巡检都可以——写成可复用的 prompt 或 skill。不要追求大而全，先让一个动作稳定下来。下次评审试着带一个 demo，不是为了炫技，只是让讨论更早落到体验上。最后，把能自动触发的事情交给系统。如果一件事每周都要问、每个版本都要查、每到节点都要提醒，它就不该长期靠你记着。

系列写完了，工作还在换

5 篇文章从"业务拿 demo 来找我"写到"Multi-Agent 系统"。第 1 篇提出问题，这篇算是半年后交的一份答案草稿。

还不是最终版。但这个工作系统确实比半年前好用多了。