01、
AI 写方案，总感觉「对」，但不「准」
AI 写东西越来越快了。
给它一个 prompt，30 秒出一份方案框架，看起来还有模有样。
但「看起来有模有样」和「能用」，中间隔着一道很深的沟。
我做过一个实验：
把同一个 Brief 分别给 AI 直接写，和给「懂这个客户」的策划人写，然后对比两份方案。
AI 写的那份，读起来顺滑，逻辑自洽，但只是感觉「对」，不感觉「准」。
「对」的方案，说了所有人都知道的事。
「准」的方案，说了对面那个决策者没说出口的焦虑。
这件事，大模型做不到。它不是不想，它是真不知道。
因为它的训练数据里，没有那些「不能写进会议纪要」的东西，而那些东西决定了方案生死：
比如你和客户开完会之后，在下电梯前，客户在走廊里拉着你说的话。
比如你在会议室里观察到的，董事长说完一段话之后，品牌总监那个微妙的表情。
所以：
AI 取代的是「写方案」这个动作，取代不了「判断该写什么方案」这个能力。
想通这件事之后，我问了自己一个问题：
如果「判断」是策划人的核心价值，那我的「思考+判断」，能不能被翻译成 AI 能执行的指令？
能，我就不是「一个会写方案的人」，而是「一个能把自己的判断力产品化的人」。
02、
我决定把自己「蒸馏」成一个 Skill
「蒸馏」这个词，最近在网上很流行。
流行的说法是「蒸馏员工」——把员工的经验榨出来，然后裁掉。
我的想法不一样：
一个公司首先应该蒸馏老板自己。
因为只有老板（或者核心决策者）的脑子里，才积累了大量「只有他知道、但从来没说清楚过」的隐性知识。
员工的知识往往是可替代的，老板的判断力才是真正的稀缺资产。
我做这件事的过程，真的很像蒸馏：
把一大锅混合物（我过去十几年做策划积累的经验、直觉、踩过的坑），
通过加热（反复问自己「我到底是怎么想出这个方案的」），
收集蒸馏出来的纯液体（可描述的判断标准），
剩下的渣（不可描述的直觉、天赋、运气）就让它留在瓶底。
我要做的，是把「我怎么做策划」这件事，翻译成 AI 能理解和执行的指令系统。
这件事在各种 Vibe Coding工具出现之前，我只停留在「想想而已」的阶段。
理由很诚实：我不懂代码。
不过 Claude Code 和 Workbuddy 这类工具的出现，让普通人也可以通过代码实现自己想法了。
大概十天前吧，我决定不管了，先干起来再说。原因是两件事刺激了我：
第一件事：开会碰一个客户的方案，开会时发现，这个框架我去年给另一个客户写过，几乎一样的叙事结构。
第二件事：一个同事，也算很资深了，写出来的方案总是「叙事逻辑很好，但洞察 weak、创意不锐、文案太平」。我知道问题在哪，但我没法把「想法」翻译成他能执行的「方法」，只能自己手动改。
这两件事指向同一个问题：
我的策划能力，在我脑子里，出不去。
如果我能把这些东西「蒸馏」出来，变成一套 AI 能执行的指令——那么，我每次做新项目，就不需要从零想了。AI 会按照我过去积累的标准，先出一个初稿，我再做判断和修改。
甚至，我可以把这套思维方式，变成一个 skill，让公司里的其他同事也可以用。这样就可以给每个人配一个拥有我的思路的「方案助手」。
想清楚这件事之后，我把自己再次当成产品经理，打开了WorkBuddy+ Claude Code ，建了一个叫「方案助手」项目，然后开始写 SKILL.md。
03、
一个不懂代码的人，
怎么用 10 天「搓」出自己的策划系统
第一天：我以为我知道，其实我不知道
4 月 17 日上午，我坐在电脑前，准备写第一行指令。
我给自己的任务是：把「做方案的流程」写下来。写了三行，卡住了。
「我怎么想出方案框架的？」
嗯……先看 Brief，然后想策略，然后出框架……
这叫「说了一堆，等于没说」。
大多数人的专业知识，是「隐性知识」
——你知道怎么做，但你说不清楚是怎么做到的。
要把隐性知识变成显性知识，唯一的方法是：逼自己把每一个判断拆到最小单元。
比如，「我想策略」这个动作，拆开来其实是：
先读 Brief，把客户「说出来的需求」和「没说出来的焦虑」分开
找这个命题的「矛盾点」——客户说「我要品牌升级」，但其实他真正的问题是「他的人不想变」
从矛盾点出发，想一个「反直觉但一说就懂」的核心主张
把这个主张翻译成客户组织里不同角色都能认可的语言
这四步，我做了十几年，但从来没有把它们写下来过。
这个过程中，我发现了很多「我以为我知道，但其实我不知道」的东西。
比如，我一直觉得自己做方案很「凭感觉」。但拆完之后发现，我的「感觉」其实是一套相当稳定的判断标准——
我不喜欢「全面但平庸」的方案
我倾向于「先找到一个尖锐的洞察，再围绕它建整个方案」
我的方案里一定有「客户没说、但我帮他说出来」的那部分
这些判断标准，原来一直在，只是从来没有被「命名」过。一旦被命名，它们就可以被写进 SKILL.md，变成 AI 能执行的指令。
同一个下午，我推翻了自己
4 月 17 日那天，我干了两件矛盾的事：
上午：我设计了 6 套方案模板，觉得「这下好了，以后做方案直接选模板填内容，效率翻倍」。
下午：我发现不对。AI 用模板生成的方案，看起来工整，但读起来像「填空题」。每一个方案都长得差不多，因为它本质上是「往模板里塞内容」，而不是「从客户的问题出发想方案」。
这个错误很有价值。它让我想清楚了一件事：
模板是拐杖，不是义肢。
拐杖的意思是：你平时走路，偶尔用它辅助一下。 义肢的意思是：你失去了腿，只能靠它。
如果 AI 做方案的方式是「选模板 → 填内容」，那它就是义肢——取代的是一个「填空题机器」，不是一个有判断力的策划人。
所以当天晚上，我做了第一次重构：模板降级为「参考」，方法论思考和叙事设计升为核心。
AI 的工作流从「选模板 → 填内容」，变成了「理解 Brief → 方法论思考 → 叙事设计 → 参考模板呈现」。
接下来的 9 天
接下来的 9 天，就是在真实反馈中反复迭代。
最有价值的一条反馈来自同事：「叙事逻辑好，但还是不够打动人。」
这指向了一个真实的问题——我把自己「想框架」的能力蒸馏出来了，但「想洞察」「想创意」「写文案」的能力还没有。
我新建了一个文件，专门写「洞察思考链 + 创意发散法 + 文案工具箱」，把这部分能力也蒸馏进去。
4 月 23 日做了一次比较大的重构，把工作流扩展成「双模」：
快速模式：分钟级出框架，适合时间紧、命题清晰的项目
深度模式：用六顶思考帽的方法论，做两轮循环分析，适合复杂策略问题
这个「双模」设计，后来成了我写给 AI 的长期 Memory：
不试图用同一种方式处理所有问题。
04、
搓出来是一回事，
用起来是另一回事
10 天开发完，我心里其实没底。所以我拿真实项目来验证。
有两个案例，我觉得还挺有代表性。
第一个案例：一个技术品牌「翻译」题
这是一个做 eVTOL（电动垂直起降飞行器）的科技企业。
他们的技术很硬核，但问题很典型：
技术人做品牌，容易陷入「我觉得我的技术很牛，所以大家应该买单」的叙事。
我拿到 6 份资料，先用「快速模式」出了第一版框架。
坦白说，不够好。
AI 生成的框架，逻辑是通顺的，但「技术叙事品牌化」这个核心命题，它没抓准。
AI 不知道这家公司的创始人，是一个「技术理想主义者」，他的叙事能量来自「我在改变人类出行方式」，而不是「我在卖一个交通工具」。
这件事， Brief 里没有， BP 里也没有。它在我们和客户的沟通过程里，在于我们对于创始人的直觉认知里。
所以我的动作是：把「创始人 IP 驱动」这个判断，手动加进方案框架里，然后让 AI 基于这个判断重新生成。
第二版框架出来了，核心洞察是：「中国全倾转旋翼 eVTOL 开创者」。
这个主张不是在说「我们的技术参数领先」，而是在说「我们在这个技术路线上，是中国第一个吃螃蟹的人」。
不是炫耀自己的技术能，而是讲一个西西弗斯式的品牌故事：要做难而正确的事，为一个行业开创一条新技术路线。
——这就有点意思了。
第二个案例：一份会议纪要里藏着的真相
这是我最想说的一个案例。
客户是一家房企，需求是「品牌整合传播」——把集团的战略主张，翻译成一线公司能理解和执行的动作。
除了客户的基础文档资料，还有两份文档：上一次会议的会议纪要，和客户品牌部负责人的一段录音。
我把这两份材料喂给方案助手，然后问它：「从这两份材料里，你有什么洞察？」
第一次回答，很表面：「客户希望提升品牌在区域公司的影响力。」这话没错，但等于没说。
我换了一个问法：「你觉得客户品牌部负责人，在这件事上的真实处境是什么？」
这一问，AI 给出的回答让我意外：
「品牌部负责人在推动这件事时，面临两个方向上的拉扯：
往上：董事长对品牌的重视程度不够，需要证明品牌的价值
往下：区域公司对集团的品牌主张有抵触，觉得『不接地气』
所以，这个「品牌翻译行动」的本质，不是「把集团主张传达下去」，而是「先帮品牌部负责人解决上下夹击的政治生态问题」。」
这个分析，是我读会议纪要和听录音的时候，隐约感觉到的，但没有清晰地想出来。
AI 帮我把这个「隐约的感觉」变成了「明确的判断」。
然后，方案框架从 v1 迭代到了 v3，最终方向定为「双线作战」：向上线先做一件事让董事长看到品牌价值，向下线把集团主张「翻译」成区域公司能用的语言。
这个案例让我意识到：
「方案助手」真正的价值，不是「出框架快」，而是「它能帮你把隐性的洞察，变成显性的判断」。
你脑子里有感觉但说不清楚的东西，通过和 AI 的对话，可以被「逼出来」。
这件事，比「分钟级出框架」更有价值。
踩过的一个坑：AI 的记忆会交叉污染
实战中还发现一个问题：AI 在给不同客户做方案时，会把 A 客户的判断标准串到 B 客户身上。
比如，给科技客户做的方案里，出现了「房企常用的叙事角度」。
问题的本质是：所有客户项目混在同一个空间里，AI 的记忆交叉污染了。
解决方法很直接：按客户拆分成独立空间，每个空间，给 AI 写不同的memory记忆文件，互相不串。
这个架构后来还带来了一个意外收获：
我把方案助手从「项目级」升级为「用户级全局 Skill」的时候，这个「一客一空间」的架构直接可以复用。
一个经验：给AI 设定Soul文件，让它遵守基本原则
在不断迭代过程中，我为这个 skill 构建了许多原则性的约束规范。
包括思考原则、沟通记录、空间规范，以及对常见的AI 信息源约束。
同时规定了 4 级信息可信度标注，要求对于所有数字信源必须确定真实与推断，已减少 AI 幻觉，让它别胡编乱造数据。
（这套 skill约束规范的逻辑，
参考学习了@数字生命卡兹克 的 CLUEDE.md ）
05、
三个启发：
工具化之前，先想清楚你在重复什么
10 天开发 + 实战项目之后，我想说三件事。
重复的部分，才值得被工具化
我做方案助手的前提是：我一直在重复「想方案框架」这件事。
如果我的每一个方案都是全新的、不可复用的，那工具化没有意义。
但事实是：同一个策划人，面对不同的客户，思考框架有 70% 是相似的。
这没什么奇怪的。
思考框架可以重复，恰恰是咨询服务得以成立的前提。
麦肯锡这样咨询公司早就有「七步成诗」、MECE、金字塔结构。
华与华这样的公司更是要将创意咨询环节「流水线化」。
差异在「行业洞察」、「关键判断」和「客户落地」，不在「怎么想出一个好方案」这件事本身。
所以，工具化的第一步，不是「学技术」，而是审视自己的工作流程，找出那些你在重复的部分。
草台模式，反馈比规划重要
方案助手 v1.0 到 v2.1 的每一次迭代，都来自真实使用中的反馈，不是来自「我先想一个完美的系统，再动手做」。
同事说「叙事很流畅，但洞察、创意都很weak」，我就补洞察方法论。
我发现「AI 把 A 客户的风格串到 B 客户」，我就做空间隔离，然后做全局识别。
如果你在做一个工具（不管是为自己还是为团队），最有价值的那个功能，一定来自真实使用者的反馈，不是来自你坐在电脑前的想象。
你的方法论应该是工具箱，不是锤子
快速模式适合命题清晰、时间紧的项目。
深度模式适合复杂策略、需要深度洞察的项目。
两套流程，共享同一套方法论底座，但「怎么用」根据问题复杂度动态选择。
不要试图用同一套系统解决所有问题。
根据问题选工具，而不是拿着锤子看什么都是钉子。
06、
AI 让我变懒了，
但也让我理解：
人真正重要的价值是什么。
写这篇文章的时候，我发现了一件事：
「把自己蒸馏成 Skill」这件事，本质上是在逼你把隐性知识变成显性知识。
这个过程本身，就会让你的判断力变得更清晰、更可复用。
「把你自己的方法翻译成 AI 指令」这件事，让你把自己的方法想得更清楚了。
一份新的 Brief 来到面前，「想框架」这件事， 70% 是不需要重新来过，AI 可以搞定。我把剩下的 30%（那部分只有我能做的判断）补进去。
「AI 让我变懒了」，但是也在提醒我：「把精力花在了只有我能做的事情上」。
15年前，我是一个「靠写字吃饭」的品牌策划人。 客户付钱，买的是我坐在电脑前，把 Brief 变成方案的那几天时间。
后来，我成为管理者，开始变成了一个「靠判断力吃饭」的人。客户付钱，买的不只是方案文档，更是「你怎么看我们这个行业、这个问题、 这个机会」的判断力。
今天，AI 时代让我可以把思考判断力产品化。
每个企业都有自己的品牌资产、知识资产、决策流程、判断标准，
如何用 AI工具结合人的共创，把这些变成可复用的系统？
——解决这件事，比卖时间、卖判断力，价值高得多。