这段时间我越来越明显地感觉到，很多产品经理在学 AI 的时候，还是会先盯住 prompt。
这很正常。
因为 prompt 是最容易看到的那层东西。
你问了什么，AI 回了什么，效果好不好，表面上都挂在这里。
而且在很多小任务里，prompt 也确实有用。
你想让它帮你起个标题、压一段文案、整理一个结构，甚至出一版需求初稿，prompt 写得清楚一点，结果往往就会好不少。
所以我不是想反过来说 prompt 不重要。
它当然重要。
但我最近越来越觉得，prompt 的价值，更多还是在“让事情先开始”。
任务一旦变长，或者开始牵扯上下文、规则、版本、联动修改这些东西，prompt 很快就不够了。
因为这时候你会发现，问题已经不是“它这一次有没有听懂”，而是“它能不能连续几轮都别跑偏”。
我以前也会把重点放在 prompt 上
前面一段时间，我自己其实也挺容易往这个方向想。
总觉得是不是我说得还不够清楚，
是不是 prompt 还能再补一点，
是不是我把背景交代得更完整，它就会更稳。
后来用得多一点，尤其是开始让 AI 参与原型、文档、流程梳理这类更长的任务以后，我慢慢发现不是这么回事。
它当然能听懂很多东西。
有时候甚至比我预期里理解得更快。
但它的问题也很明显。
前面几轮看着都还行，继续往后做，开始加新内容、补细节、改旧结构的时候，事情就容易慢慢变味。
你原本只是想补一小块，它可能顺手把别的地方也动了。
你以为自己是在往前推进，结果回头一看，之前已经确认过的内容开始漂了。
你前面花了很多力气才讲清楚的边界，它不是完全没记住，是记得不够稳。
这时候再回头盯着 prompt 调，其实已经有点偏了。
prompt 解决的是开始，不解决后面会不会越来越乱
我现在更愿意把 prompt 理解成一种启动能力。
它很适合解决“先动起来”这件事。
你有个模糊问题，想先出第一版；
你脑子里有个方向，还没来得及整理；
你想先让 AI 帮你把东西摊开一点，看看有没有继续往下聊的空间。
这些场景里，prompt 很有价值。
但复杂任务最怕的，往往不是第一版出不来。
真正麻烦的，是它后面会不会越来越乱。
这也是我最近越来越在意的一件事：
很多人觉得自己在学 AI，学着学着，最后学的还是“怎么更会提问”。
可复杂任务到了后面，真正拉开差距的，已经不是提问能力了。
而是你有没有办法让这场协作别失控。
所以我后来越来越在意“工作系统”这件事
我现在会觉得，AI 一旦开始参与复杂任务，产品经理更该补的，其实是另一层东西。
不是只想“这句怎么说更清楚”，
而是开始想：
这件事的背景有没有先沉淀下来。
哪些规则是固定的，哪些是还在变化的。
AI 这次读到的，是不是一套稳定的东西。
它改完以后，谁来检查。
哪里最容易出偏。
出偏以后，是继续硬修，还是应该回到前一个版本。
这些问题放在以前，看起来不像“AI 使用技巧”。
但现在我越来越觉得，它们反而才是真正重要的部分。
因为 AI 开始参与复杂任务以后，你面对的已经不是一个“问一句答一句”的工具了。
它更像一个能力很强、速度很快，但稳定性一般的协作对象。
你不能只会给它下指令。
你还得先把这场协作怎么跑搭起来。
只让 AI 知道规则，还是不够
我现在也越来越能理解，为什么很多人后来会开始做知识库、做 skills、做项目说明文档。
因为只靠聊天太不稳了。
你这次讲清楚了项目背景，下次可能还要重讲。
这次聊顺了输出风格，下次可能又得重新校。
这次好不容易把业务规则和边界说清楚了，如果没有沉淀下来，下次它还是得重新认识你一次。
所以往前走一步，去搭知识库、去封装 skills，这件事我当然认同。
而且我觉得这一步很重要。
但我后来慢慢意识到，做到这里还是不够。
因为“知道规则”和“稳定照着规则做”，中间其实还差一层。
AI 不是没读文档。
很多时候它读了，也理解了。
但一旦任务拉长，一旦开始联动修改，一旦中间出现几个来回，它还是可能慢慢漂。
所以问题会继续往前走。
不是它知不知道，
而是它做没做对。
这也是我后来越来越在意检查、反馈、验证这些东西的原因。
以前总觉得这些更像工程里的说法，现在我会觉得，对产品经理也很有启发。
你不能只负责把需求讲清楚。
还得开始设计：什么地方应该被检查，什么地方出了问题能早点被发现，什么地方不要等到最后全靠人肉兜底。
我后来开始给 Codex 补一些用于检查的能力
最近我在和 Codex 一起做这类复杂任务的时候，也开始慢慢把“检查系统”补起来了。
一开始我对这件事没有那么强的意识。
总觉得 Codex 先做，我再看一遍，差不多就够了。
后来发现，任务只要一变复杂，这种方式就很容易把人重新拖回执行里。
表面上看，是 Codex 在写、在改、在生成。
但真正麻烦的地方都在后面：
页面有没有挤，
交互是不是跑偏了，
某一轮是不是顺手把旧东西改坏了，
移动端有没有出问题，
视觉层级有没有乱，
前面已经确认过的结构有没有慢慢漂掉。
这些问题如果全靠我最后统一回看，其实很累。
而且很容易漏。
所以后面我开始给 Codex 补一些“用于检查”的能力。
有一类更像设计侧的稳定器。
比如我会先用 teach-impeccable 这类能力，把项目的设计背景、风格边界、页面气质先固定下来。
这样 Codex 不是每次都重新理解一遍“这个网站到底想做成什么样”，而是先站在一个相对稳定的上下文里工作。
这一步看起来不像在做页面，但它其实是在减少后面反复跑偏的概率。
再往后，等页面真的开始进入实现和修改，我会再用像 ui-ux-pro-max、polish 这种更偏检查和收尾的能力，去看排版、间距、层级、hover、细节一致性这些问题。
它们的作用不是替我做审美判断。
而是先把一些很容易被忽略的地方提前暴露出来。
比如某块是不是太挤，
某段字是不是太长，
交互有没有不协调，
列表节奏是不是断了，
某个局部是不是明显和整站不在一个完成度上。
再往下一层，就是更直接的页面检查。
我会让 Codex 调起浏览器，把页面真实打开，自己看实际渲染，再截图回看。
这里用到的能力更像 playwright-interactive 或者浏览器验证这一类。
它真正有用的地方，不是“能自动点页面”。
而是它让 Codex 不再只停留在代码和文字上，而是开始对真实页面结果负责。
让 Codex 打开浏览器截图回看，解决的不是点击问题
这件事一开始听起来很像一个很技术的动作。
但我后来越来越觉得，它的价值其实特别实际。
因为很多问题，不是在代码里能直接看出来的。
代码写完了，结构看着也没错，可一进浏览器，可能就挤了。
有些 hover 看代码时没问题，鼠标一移上去才发现很硬。
有些文字长度在数据里看着还好，一挂到真实页面上就显得特别突兀。
还有一些问题更麻烦，它不是完全错，而是你能明显感觉到“哪里不对”，只是如果没有截图对照和实际页面回看，你很容易当场忽略过去。
所以后来我会更倾向于让 Codex 自己先跑一遍页面，先做一轮截图和回看。
这一步的意义，不是省几次点击。
而是它把“检查”这件事，从原来很靠我临时记得去做，慢慢变成了协作链路里本来就该有的一层。
这层东西一旦补上，好处会很明显。
第一，是很多偏差会更早暴露出来。
不是等所有东西都做完了再统一发现，而是每改一轮，就能更快看到它有没有跑偏。
第二，是它能帮我过滤掉一部分低杠杆的体力活。
有些问题其实不需要产品经理每次亲自盯着才知道，比如排版挤压、间距跑掉、某些状态不一致、局部视觉层级失衡，这些完全可以先让 Codex 帮我筛一轮，再由我去看那些真正需要判断的地方。
第三，是它会反过来逼着整套协作更稳。
因为一旦开始认真做检查，我就会自然去想：哪些页面是高风险的，哪些地方最容易漂，哪些问题必须每轮都回看，什么才算这次改动真的过关。
前一层是在搭背景，后一层是在补反馈
这也是我后来越来越明确的一件事。
知识库、skills、项目说明这些东西，解决的是“让 Codex 知道规则”。
但检查、截图、回看、验证，解决的是“它做完以后，能不能早点发现自己有没有做错”。
前一层是在搭背景。
后一层是在补反馈。
如果只有前者，没有后者，任务一拉长，事情还是可能慢慢变乱。
因为它不是不知道规则，而是未必能在连续几轮修改里一直稳定照着规则做。
所以我现在会越来越把这件事理解成：
当 AI 开始参与复杂任务以后，产品经理不能只负责把需求讲清楚，也要开始设计这套协作里的检查和反馈。
什么地方应该被检查。
什么问题应该尽量提前暴露。
哪些风险不能等到最后再靠人肉兜底。
哪些地方适合让 Codex 先跑，哪些地方必须由我来做最后判断。
这些问题以前看起来不像“AI 使用技巧”。
但现在我越来越觉得，它们反而才是复杂任务里真正重要的部分。
因为复杂任务最怕的，从来不是第一版做不出来。
而是做着做着，越来越乱。
人后面更该往上站一点
这件事还有一个变化，我自己感受挺明显的。
以前和 AI 协作，很多时候人还是卡在执行里。
它做一点，你看一点。
它改一轮，你再验一轮。
表面上是 AI 在干活，实际上整条链路还是你亲自在拉。
小任务这样没问题。
短平快的事，反而这样最省劲。
但只要任务变复杂，人很快就会变成瓶颈。
你会发现自己越来越累，不是因为不会做，而是因为所有确认、检查、纠偏，最后都压在你这里。
所以我现在越来越认同一个变化：
人后面要慢慢从“逐步盯执行”，往“站在上面看整套系统”那个位置挪。
不是不做事了。
而是把精力从低杠杆的反复盯，挪到更高杠杆的地方。
比如定边界，定规则，定检查点。
比如判断哪些可以让 AI 先跑，哪些必须人工确认。
比如提前想好，哪类问题最可能反复出现，能不能别每次都靠自己去发现。
我觉得这才是 AI 真正开始改产品经理工作方式的地方。
所以后面更该学的，可能是这些东西
如果现在有人问我，产品经理要不要学 prompt。
我的回答当然还是要。
但如果继续问：那后面更该学什么？
我现在的答案大概会变成这样。
你得学怎么把背景沉淀下来，而不是每次都重新讲。
你得学怎么把高频方法封装出来，而不是一直靠现场发挥。
你得学怎么把信息组织清楚，让 AI 读到的是地图，不是一锅粥。
你得学怎么补上检查和反馈，而不是总等结果出来以后再人工兜底。
你还得慢慢学会，把自己从执行层往上提一点。
这些东西没有 prompt 那么显眼。
也没有“写一句万能提示词”那么容易让人兴奋。
但任务一复杂，它们的价值会一下子出来。
因为复杂任务里，最怕的从来不是第一版做不出来。
而是做着做着，越来越乱。
我现在更愿意这样理解这件事
如果 AI 只是帮我处理一些短任务，那 prompt 确实已经很好用了。
但如果它开始参与的是原型、文档、流程、分析，甚至是一整段持续迭代的工作，那我就不能再只把它当成一个回答问题的工具。
它更像一个很强，但也不算稳的协作对象。
这时候产品经理更重要的能力，也就不再只是“怎么把一句话问漂亮”。
而是我有没有把背景留住。
有没有把方法沉淀下来。
有没有把边界说清楚。
有没有给这场协作准备好检查和回退。
有没有让它在任务变复杂以后，还能继续往前走，而不是越做越乱。
我现在会更偏向这么看这件事：
当 AI 开始参与复杂任务，产品经理更该学的不是 prompt，而是怎么让 AI 在一套更稳的工作系统里持续做对。