想法

最近通过版本走查、自动化流程测试和对外应答，我对产品能力的成熟度有了更具体的认识。已有功能能够说明和演示，离完整闭环还有距离。

接下来需要逐项验证：要求能否被准确解构，通过标准是否说得清楚，AI 问答和人工核实能否稳定衔接。70% 的自动化率目前还是目标，得靠实际测试分清哪些环节可以自动完成，哪些仍需人参与。

最近的协作几乎没有文档。我先把方案做成可交互、接入真实数据和逻辑的原型，再交给开发去工程化。好处是逻辑能不能走通、哪里有坑，在前面已经踩过一遍；节奏确实快。

代价也很明显。做原型的人要多投入时间，我在这个项目里又更像产品经理，没法同时把设计质量照顾好。和业务负责人讨论引入 UI 时，他担心会打乱现在的协同方式。我也还在想，设计师应该在哪一步接进来。

讨论里有同事说，AI 对设计的帮助可能先体现在提质。我当时的回应是，它更像一种补全信息的思路。原型能把问题更早带出来，但设计师怎样参与，仍然值得继续试。

这段时间做接真实数据和模型的 Demo，我多花了不少时间，连提示词为什么这样设都要说清楚。工程版本还没好，Demo 却让我们赶上了验证，也让开发可以拿一个接近 POC 的东西去工程化。

我越来越觉得，很多工程化细节只有放到真实需求里反复讨论，才会慢慢清楚。原型先跑一遍，起码对能不能做有个更实际的结论。

准备设计思维训战和工作坊时，我感受挺深的一点是：很多时候，我们是在换一个视角看同一个问题，才看到更多可能。

上周读书时看到一句话，大意是如果想换个角度看问题，可能还得改变自己衡量成功与失败的标准。我觉得这句话挺应景的。

跟几个同事讨论退出机制时，我也在问自己：如果这个项目再来一次，我还会不会提出这个方向？当时不是为了提而提，我真的相信它。到现在，它在某些层面仍然成立；但以目前的做法和资源，很可能完不成。

我看漏的是企业内部的条件。即使重来一次，那个坑我可能还是会踩。走了一年，再站在今天判断，很容易“屁股决定脑袋”。所以需要给这件事设一个明确的验证节点。到时候如果仍拿不到满意的答卷，就该停下来，把投入留给更重要的事。

去年我就在想，做 AI 产品时，功能的 Prompt 和结果的评价方式也需要被设计。当时还写过一句很重的话：“Prompt 就是 PRD”。

最近试用一套带规则和 skill 的设计工具，让它按通用原则生成和检查具体业务界面，结果离我期待的还有距离。后来把对业务的理解、判断标准和原则补进去，输出才更贴近需求。

每个业务和背景都有差异，通用规则到了这里不一定够用。我觉得设计师的机会之一，是把这些差异说清楚，定义出适合当前业务的规则。最后还是要回到生成或检查的结果：是不是自己认可，是不是业务方认可。

面对海量信息，我觉得可以先把自己的判断标准、选择倾向，以及认可和不认可什么整理出来。它们能成为第一层过滤，帮我从大量材料里先找到值得继续看的东西。

过去信息量不大，每一层筛选大多靠人。现在能拿到的信息更多，第一层、第二层交给机器处理可能更合适。原始信息还在，标准以后变了，就重新过滤一次。人不必把精力耗在所有初筛上，可以把它留给后面的判断。

方案越完整，复杂度也越高。对合适的客户和场景，这些能力确实有用；但客户还在早期、刚开始接触这类产品时，往往只想解决眼前几个明确的问题。

多出来的完整性如果恰好不是当下所需，理解和使用的成本就会变重，甚至可能让人放弃这个方案。

我现在越来越觉得，有些观点被说成“鸡汤”或者“正确的废话”，可能只是因为听的人正处在不同阶段，需要的信息不一样。

一个人连怎么做都还不清楚时，更需要具体、能操作的东西：一个模板、一件能直接用的工具，放到现在可能是一段提示词或者一个 skill。这个时候，只讲核心思想，确实很难帮他迈出下一步。

但实操经验越来越多以后，过于具体的做法反而未必有用。他可能更需要一个新概念、一个案例，或一种看事情的新视角。具体方法往往只有在环境、背景和项目条件都足够接近时，才可能照着用。

所以方法论太通用不行，太具象也不一定好。理解它背后的思想，比把它当成模板照抄更有用。

我想做一类“事找人”的 AI：有需要的时候再找人，而不是让人一直待在交互里。继续往下想，这件事至少要回答三个问题。

第一，什么时候找人？触发条件需要明确。比如在合规场景里，数据映射不上时可以找人确认；换到产品机会场景，触发点就得重新定义。

第二，找到人时问什么？问题应该足够窄，并且和他眼下正在做的事有关，让他调用最近的判断就能回答。把整个过程展示给他，不一定能帮他作决定。

第三，问题背后用什么支撑？对熟悉这件事的人，一条线索、一个异常或一个片段，就可能足够触发他的认知框架。碎片不一定要先拼成完整报告，才有资格成为提问的来源。

原先“让事情主动找人”只是一个交互方向；把提问的时机、宽度和来源想清楚，它才更接近可设计的机制。

跟同事聊信息验证时，我说了一句：“是否选择相信验证结果，这是认知问题。”以前我总想要一个“验证过的事实”，以为验证能抵达完全客观的终点。现在觉得，如果没有明确的外部标准，最后仍要由人判断：他信不信，愿不愿意据此往前走。

这让我意识到，验证需要什么支撑，取决于接收者是谁。一个一直沉浸在具体事务里的人，看到一条线索、一个异常、一个片段，可能就能调动自己的经验作判断；数据对他是参考。没有参与这段事务的人，则可能需要更完整、可核对的数据，才能建立信心。

同一件事，给不同的人看，不能只交付同一种“证据”。设计要考虑他已经知道什么、还能凭什么判断，再决定是给一个足够窄的问题，还是给出更客观的数据。

最近把产品重新设计成“事找人”的逻辑，想做一类更静默的 AI：轻嵌入，尽可能少要求人反复交互，减少合规成本和沟通摩擦。

Demo 已经做出来，自动填写在当前测试里达到了预期。小模型仍有限制，所以这还只是阶段性验证。

回看这两年关于 AI 设计的笔记，我发现自己一直卡在一个问题上：怎么验证 AI 的输出对不对？过滤得到的是假设，我想要的是验证过的事实。但验证标准本身，也需要有人定义和判断。

把做过的项目放在一起看，我发现自己反复采用同一套做法：把 AI 的处理过程拆开，让每一步看得见；让人能用很低的成本纠偏；先观察过程是否稳定、偏差会在哪里出现；再把东西做出来，自己先用。

从咖啡豆管理工具到企业合规产品，再到 Agent 的设计，我好像一直在设计一种接口：面对不确定的处理过程，人不用时时盯着，却能在需要时找到介入和修正的位置。

以前我把“验证结果是否正确”当成唯一的关口。现在觉得，过程的可见性，以及人能不能方便地纠偏，也是这类产品必须设计出来的能力。

“逻辑是证明的工具，直觉是发明的工具。”——庞加莱

过去，我其实是一个不太喜欢逻辑的人。因为在我看来，逻辑更多是一种框架。框架可以帮助我们解释一个答案，却很难帮助我们发现一个真正好的答案。

很多新的想法，往往来自某个瞬间的灵光一闪，来自直觉，也来自过往经验长期累积之后形成的综合判断。

但在工作中，我们更容易相信逻辑。因为逻辑可以被解释，可以被拆解，也更容易被团队理解和接受。

直觉则不同。直觉背后有大量个人经历、上下文和隐性判断。别人很难完整理解你的经历，也很难理解你在当下为什么会做出这样的判断。所以他们最终只能理解他们能够理解的东西，也就是逻辑。

问题在于，几乎所有方法论都在指向逻辑。它们可以帮助我们把事情讲清楚、推完整、做严谨，却未必能帮助我们找到一个真正好的方案。

这一周，我跟团队说：我们需要推翻现在所有的东西，重新设计。

原因很简单：当前方案已经很难满足最初设定的目标。它被太多限制、客观条件和局部问题牵引着。我们不断在想，如果出现这个情况怎么办，如果出现那个情况怎么办。于是，我们开始围绕各种问题补丁式地解决细节，却慢慢忘掉了最初真正想达成的目标。

最后得到的结果，就是一个充满妥协的方案。

而一个充满妥协的方案，通常很难真正抵达目标。

事情还是应该尽早开始，不要等所有的都准备好了，或者说当没怎么选择的时候才开始做这件事情。

就是如果想做，那就先开始。然后可能有的时候也不用定什么目标，就是一切跟随自己在做什么事情，去展开就好了。

就像现在自己在做这些相关的总结也好，观点的整理也好，我觉得对很多人来说，其实都是一种启发，就是对他人是有价值的一种东西。

包括我再给别人推荐吃的、喝的、玩的，其实本质上也是做信息的筛选，也是有自己所谓的认证过也好，踩过坑也好。

那这些东西对于身边的人来说，它有用，那对于可能网上很多人来说，其实也应该有用。

所以会这样想，马上回去就选一台适合的手机。

拿到安克录音豆以后，我一直在思考它适合什么场景。我也和同事讨论过这个问题。单看录音这件事，手机可以完成，飞书妙记也可以完成，而且它本身也接入了飞书生态，所以一开始我会觉得它的功能并不稀缺。

但在这几天的使用过程中，我逐渐感受到它的价值。外面下雨，我一边打伞一边走路。在过去，如果我想边走边录音，就需要拿出手机，把手机靠近嘴边，才能保证录音效果。这样做不太方便，而且手机录音时也会影响我听歌。

现在使用录音豆以后，我可以一边听歌，一边走路，一边记录想法。哪怕两只手都拿着东西，只要我想说，按一下就能开始录。这一点对我来说很实用，因为我每天上下班主要靠走路，在路上经常会产生一些想法。过去要先掏手机、打开录音功能，过程比较麻烦，很多时候也就不记了。现在记录的门槛明显降低了。

我也发现，短时间记录还好，如果只是说一两句话，用手机也能接受。但如果是一边走路一边连续说十几分钟，手机就会变得很不方便。耳机本身也能收音，但识别效果比较差，实际体验不好。录音豆在这个场景下减少了很多负担，让我可以自然地边走边说。

从目前体验看，它的续航也比较够用，能支撑比较长时间的记录。对我来说，录音豆的核心价值并不只是“能录音”，因为很多设备都能录音。它真正有价值的地方，是降低了记录想法的操作成本，让我在走路、打伞、拿东西、听歌这些日常场景下，也能方便地把想法记录下来。

它适合的核心场景是移动中的随手记录。尤其是对我这种每天通勤走路、路上经常有想法的人来说，便捷性就是一个很明确的需求。

最近在总结一些事情，想得有点多。 有时候觉得，当面对一些事情时，有很多判断维度，也不一定就是好事，毕竟做决策本身就不是数学题。

事情还是要准备得充分点，因为不知道客户那边的情况。幸好是过程中多准备了几个细节，也刚好只是多了一两个细节，客户那边就感兴趣，也给这次演示加分。

要判断一个场景、需求或机会方向是否成立，我会先看几个信号：

1. 有哪些组织已经在做这件事？在企业内部，也可以先看自己的公司或熟悉的公司。
2. 有没有承担这项任务的人或部门？他们是否已经购买工具，或用其他方式投入资源来完成它？
3. 这个任务是不是持续存在，只是完成它的方式在变化？
4. 驱动这个任务的因素是否稳定，相关需求是在增长还是下降？

这些信号不能替代后续验证，但能帮助我判断：这是不是一个值得继续研究的方向。

我以前写过“探索真正应该从建立判断标准开始，而不是从收集信息开始”。回头看，这句话描述的是第二轮以后的状态。第一轮还没有足够的信息，标准很难凭空定出来。

更接近我实际经历的过程是：先开放地接触大量信息；看得多了，一些模式会反复出现，也会开始觉得某些方向“对”或“不对”；再把这种感觉说清楚，提炼成可以表达和检验的标准；最后用它指导下一轮收集，逐步收敛。

所以“先建立标准”并非完全错，只是少说了最关键的一层：标准从哪里来。这个修正后来也进入了我整理机会探索方法的文章。

在 AI 时代如果做企业产品，不应该做那些只能私有化部署的业务

一些复杂的功能、流程、界面，直接在开发环境里写功能失败了🤷。。还是只能输出原型，需要输出可开发的 UI 图，然后由前端来接手。

这一周，我尝试在 Claude 中“蒸馏”自己。通过对自我各维度的还原，我获得了一次深入的审视，比过去更了解自己是一个什么样的人。

开启这项尝试的初衷，是因为日常工作中海量的信息处理和判断已经触及了我的精力极限。我希望制造几个“数字分身”来协助我筛选信息、辅助决策，以此缓解信息焦虑，提升选择的效率与质量。毕竟，人类的决策难免带有感性或不理性的一面——这虽非坏事，但不该消耗在所有的琐碎事务中。我需要学会把那些机器能胜任的理性部分“交出去”。

这周还是在借助不同的 AI 软件去推进手上的工作。过程中我有一个挺明确的感受，就是如果一开始想法还没有特别清楚，这时候用代码类的软件去做原型，可能最重要的不是先把某一个原型还原得特别细，而是应该在比较短的时间里，先快速做出几个完全不一样的原型方向。这样再结合自己的思考，反而会更快把原来一些没想明白的地方、一些盲区给逼出来。

尤其是在一件事情本来就没太多头绪的时候，其实更多的信息刺激是有帮助的。因为它会帮助你更快去辨认这个方案到底是不是对的，或者说，哪些方向是值得继续往下走的。所以我觉得，上周最大的收获其实不是某个具体的产出，而是我有点搞清楚了：在完全没有头绪的时候，到底做什么是有效的。

其实回头看，过去我们某种程度上也是这么工作的。只不过以前更多是靠纸笔，先画很多草图，再围绕这些草图去想。但那种方式始终还是缺一些细节。现在不一样了，因为工具能很快把很多细节带出来，但问题也在这里，一旦太早看到细节，就很容易整个人陷进去，开始纠结那些在当前阶段可能并没有那么重要的东西。

所以我现在会提醒自己，在做原型的时候，尤其是在还没想清楚的时候，要警惕自己是不是被这些细节带偏了。因为很多时候，细节本身不一定重要，真正重要的反而是先把方向拉开，把判断建立起来，先搞清楚眼下这个阶段最该做的事情到底是什么。

这一周开始没有打开过任何设计软件，基本上都是在Cursor、Claude、Claude code、Gemini 完成整体的方案设计和实现，包括方案的规划。

从上一次实践官网的设计规划和开发，到这一次直接设计大的功能模块，并且是在开发环境去做这方面的尝试。我觉得以后这种事情只会变得越来越普遍，有不少的事情可能都会直接跳过一个非常严谨的设计过程。

因为如果设计的时间成本和开发实现出来的时间成本是差不多的话，那么开发出来的东西他一定是可取道有用的东西变多，它的整体成本一定是变低的，而且开发一个原形出来，它是比设计图要反馈的信息要多得多，因为它是可以直接感受到哪里对和哪里不对，去验证一个概念，也是看到的一个接近于成品的功能，而不是一张图片。

这周没太多其他事情，基本都在被安排了调研，之前也都调研过了，但为了之后的事情，在陪着走过场。 没能获取很多新的和高价值的信息，有时候觉得这种事情，不做也不行，做了又觉得时间投入不值。

这周尝试了一下把官网“开发”出来，过程中没用过任何设计工具，也没写过代码，但就是开发出来了。流程变化也有明显变化。

以前：内容规划--->原型设计--->视觉设计--->开发实现。这整个过程，还担心有些效果不好实现，求着前端来实现。 现在：内容规划<--->开发实现。从内容规划到效果实现，基本上就是通过各种AI模型来完成，如果不是要记录一下在飞书，基本上用不上其他工具。基本上确定完了，就打个包扔给开发，让他来部署上线就可以。

🤷 可以预见，以后 0-1 的项目，设计师的空间会进一步被压缩。

这周试了一下之前写的 gpts，有了一些新的发现，年后可以尝试完善一下信息关联部分

虽然是临时做的，只花了 30 分钟，但居然还不错。

这周在时间和项目实际情况都不太清晰、又很紧迫的情况下，我组织了一场共创工作坊。结果上没有达到理想预期（例如关键决策者未参加），但这也不是我能控制的；不过从共创过程本身，我观察到了一些很有意思、也很有价值的收获与问题。

过程观察：分歧没那么大，更多是信息不透明

开始前我以为大家观点分歧会特别严重，但实际观察发现分歧并不大。很多偏差来自于对实际情况了解不够、信息不够透明，导致在一些方向上的理解与认知出现偏差。

这次工作坊的一个收获是：在对“哪些角色很重要”这类关键问题认知拉齐之后，大家也开始能更进一步去找到一些值得继续研究、完善，或者发展新能力/新场景的方向，并产生了一些对应想法。

方法与改进：流程要更精简，且越早标准化越好

从现场节奏来看，未来我在规划好流程后，应该再砍掉 20%–30% 的环节，才会刚刚好、比较充分。讨论占用了大量时间，这虽然可预料，但很难阻止，因为这是进入状态非常关键的一步。

同时我认为，这项工作应该越早标准化越好，并且在“如何规划和设计工作坊流程”上需要有更多指向性的沉淀。因为每一种类型的工作坊、以及不同的目标，其交付物和流程差异都不小。

那次共创工作坊让我们对关键角色有了更多共识，也让一个问题更清楚：我们对客户的需求场景仍了解不够。

讨论出的新研究方向，是把目光延伸到产线末端客户，看看我们能不能帮助企业满足它的客户的需求。如果只盯着企业内部使用者和决策者，可能会漏掉需求形成的另一端。目前这还是工作坊里形成的研究方向。

背景

在设计 AI 原生功能时发现，Loading 并非简单的等待态，而是一个关键的信息交互环节。由于模型计算与多步编排几乎不可避免，未来 AI 产品都会面临这一体验节点的系统性设计问题。

本周思考与行动

• 明确了整体原则：Loading 的目标是在用户等待过程中建立专业信任感与透明度，而非展示 AI 的推理能力。
• 将 Loading 视为一种“叙事型设计”，通过结构化信息降低不确定性，让用户感知系统是有流程、有边界的。
• Cisco 的数据治理白皮书中关于 Transparency / Trustworthiness 的理念，意识到用户未必细看具体文案，但会快速形成“这个 AI 是否靠谱”的整体感受。
• 基于“时间 × 角色 × 场景 × 意图”的思路，构想未来 Loading 可动态匹配不同层级的信息表达。
• 鉴于该方向涉及体验、算法与工程成本，为推动团队对齐，先制作了一个示意 Demo，用更具象的方式与同事沟通分阶段 Loading 与不同场景下的变化可能性。

思考

• Loading 本质是在构建体验层面的信任，而不是技术层面的解释。
• 设计重点不只在“写什么”，而在于是否呈现出专业流程感与可控性。
• 这类设计更接近早期服务设计 / 内容设计中的信息架构与叙事，而非传统 UI 动效。
• Transparency 是减少不确定性，Trustworthiness 是建立专业感；
• 在 AI 产品的 Loading 中，它们更多通过“整体体验”传递，而不是靠用户细读具体文案。

看到这么一句话，挺有道理的：“当设计师的“建议”，变成实实在在的设计稿时，才会被认同”。

最近大半年都在做“产品经理”，更能看清楚设计师的优劣势和“尴尬位置”。

1、越是模糊的机会探索，要与业务决策者的距离越近。保持过程产出与沟通的高频同步，用持续的阶段性交付（判断、结论、方案草稿、数据等）来对齐认知，避免因为信息不对称导致方向跑偏，或由于对方的信息跟你不一致而导致的不被认可。

2、要让业务负责人和最高决策者及时掌握关键信息。尤其是在高度不确定的探索型项目里，信息本身就是决策依据——必须确保关键节点、重要变化、主要风险与下一步选择能被第一时间理解。

3、必须拿到并同步一手信息，和关键决策者保持同频。不仅要自己接触一线、获得真实反馈，也要主动把信息结构化地传递给关键决策者。

4、要有补位意识。必要时适当补位，不拘泥于自身岗位边界，以阶段目标/最终目标为导向。

这两周在帮忙面试别人，发现一个还挺明显、也挺有意思的现象。

大部分人其实只能把自己熟的业务讲清楚。在这个范围内，只要业务还能找得到类比点，哪怕没真的做过，他们也能把一些方法、经验往相似的场景里套，基本还能说得通。

但一旦问题稍微跳出原来的业务边界，尤其是已经没法直接类比的时候，就会明显卡住。一下子不知道该从哪儿开始想，也不太敢往下判断。

之前跟颐姐讨论也聊到一个类似的话题：很多人其实缺的是基于基本思维的系统性思考能力，以及面对复杂问题时先搭一个模型的能力。现在再看，会发现这和面试里的感受是完全对得上的。

可以理解为，他们一般不太会先把一个问题拆开来看。他们不知道这个问题里到底有哪些基础元素、哪些关键变量在起作用，也不知道该先搭一个“用来想问题的框架”，而是习惯直接去找结论。

还有一个挺明显的点：他们对“答案”本身也没什么想象力。

很多时候，答案在他们脑子里只能是某种见过的做法、行业里的常规解法，或者“别人都是这么干的”。

如果拆不出这些基础元素，就谈不上重组答案。于是思考就只能一直依附在具体业务和过往经验上。

当然，有时候这也不一定是坏事。因为当方法被进行一步抽象，本质上就是在找杠杆，而找杠杆这件事，本来就一定会丢细节。很多具体业务里，恰恰是那些细节在起决定作用，而且从短期来看，也是无法替代的价值。

整体来看，还是要看这个人被放在什么样的使用场景里。

一份研究报告有没有价值，要先看在当前语境下，谁来定义“价值”。不同角色有不同动机和预期，有时甚至会得出相反的判断。对关键决策者来说，报告是否回应了他关心的问题，常常比信息本身有多丰富更重要。

所以在动手之前，我得知道他希望回答什么，再围绕这个问题寻找显性和隐性的信息。拿到信息还不够，也要理解他会怎样解释它：我在讲用户的问题和动机时，他可能正在想，这件事要不要解决，投入产出比如何。

研究要帮助人解决值得解决的问题。弄清什么是眼下的高价值问题，才能判断这份报告该做什么。

直到现在，我仍然看到很多人把用户说出口的一句话——想要某个功能，或者指着一个页面说要改成什么样——直接当做需求本身。

更多时候，那只是用户当下能想到的方案。他可能在别的地方见过相似的做法，也可能只是觉得这样能让眼前的事继续推进。包括我自己，在接受访谈或讨论方案时，也会不自觉地说“如果改成这样会不会更好”。用方案表达，是一种很自然、也很省力的沟通方式；没有必要因此责怪用户。

但如果讨论从这个方案开始，很容易顺着它进入实现和优化。推进看起来很快，大家也似乎在同一个语境里，最后却可能只得到一个被不断修补的方案，而没弄清它为什么在此时被提出来。

我觉得需要先把注意力拉回几个地方：用户正在试图完成什么；他在什么处境下提出这个方案；他为什么觉得这个办法能行。尤其要回到方案出现之前的那个时刻——哪里卡住了，哪一步开始困难，如果什么都不改变，事情又会怎样。理解这些，比立即讨论方案的细节更重要。

这周有 80% 的时间都在跟各方案技术团队开会，这过程还是挺有意思的，涨了一些见识，也帮他们解决了一些方案实现的逻辑问题。他们的方案倒是更清楚了，我的方案还没画好。🤷‍♂️

这周基本都在忙产品落地的事情，产品方案的功能设计，过程中提出了一个新的方案和思路，整体逻辑和定义得到了整体团队的认可，也解决了一个很大的业务问题和技术相关问题，下周和算法的同学完成方案的定义。

不得不说，我的咖啡豆记录工具立了大功，方案的设计思路基本复现在一个更大的系统上。

另外分享一个有意思的概念：人与 AI 的认知耦合。通俗点，可以理解为共享上下文。

意思是，建立一个人类意图与AI任务能透明共享、协同演化的智能交互机制，其最终形态是将传统问答式人机互动升级为具有持续共同创造能力的“共创式关系”。

核心隐含假设：

• 人与AI可以共享一种中间状态
• 意图与任务模型之间具备对齐的可能性
• 元认知可以成为可工程化的监督机制

元认知 = 思考自己在想什么，并能主动调整这种想法的能力

在该语境下，意思是系统主动“意识到自己的理解或策略可能有问题”，并提醒人类或自我修正。

本周与项目负责人多次讨论了一个关键问题：我们在市场验证上的力度仍然不足。目前依靠访谈获取的信息仍偏局部，难以全面确认价值假设的有效性。接下来需要从更广泛的信号源进行验证，例如关注目标行业的会议、峰会等活动，通过与更多潜在客户交流，获取更具代表性的反馈。

这也引出了新的工作重点之一，就是价值传递方式的构建。我们需要明确如何向外部传达产品理念与价值，包括完善官网、制作可分享的介绍材料（如 PPT 等），让潜在客户能快速理解产品定位与优势。

与此同时，MVP 的落地被再次确认为最优先事项。Charter 报告或概念说明可以帮助我们在内部达成共识，但外部客户不会仅凭一份 PPT 就进入共创或试点阶段。只有当产品能够真正被体验和使用时，我们才能获得真实的反馈与合作机会。

换言之，MVP 是连接内部构想与市场验证的关键桥梁。缺乏 MVP 不仅让我们在沟通上被动，也可能错失早期验证与客户共创的最佳窗口期。

🤔 用了两年多的 AI 产品后，终于还是迎来了一些后遗症：动手能力和以前相比，变差了。

✌️ 用了两年多的 AI 产品后，发现自己抓重点的能力提升了不少，行为对于个人的影响还是很大，大概是因为业务促使，需要看到一些关键性的问题，以及使用 AI 产品时，提问的准确性得到了主动与被动的训练。

这段时间在做企业合规相关的研究和概念探索，尤其是概念的实现逻辑、自动化的可能性，以及信息的提取与处理。这些想法其实并不是突然冒出来的，很多启发都来自于上半年我自己折腾的那套「咖啡豆管理工具」。

当时只是为了更高效地管理自己的咖啡生豆和熟豆，用飞书多维表格 + AI 做了不少自动化的小尝试。过程中，我慢慢摸清了什么样的提示词最合适，小模型能处理到什么粒度，哪些环节必须留给人来做，自动化逻辑又该怎么搭。

那段经历当时只是“玩票”，但现在回头看，已经悄悄成为我做合规相关概念研究的底层思路。比如，如何把复杂的信息拆解成结构化的字段，如何把人和 AI 的分工嵌进工作流，如何用合适的触发逻辑让整个链条高效运转。

从咖啡豆到企业合规，这个跨度听起来有点离谱，但某种程度上，这就是最真实的认知积累路径——动手做了才有经验，多去创造一些变量，再把经验复现到更大的事情上。

1、概念工程一直在做重复的事情，每个阶段的重复率应该有 30%左右，而且都是重点内容。每个阶段只是换了个名称和陈述方式，可能这也是由不同的人去定义和撰写带来的现象吧。

2、整体实践下来，还是思路的价值大于方法和流程，把关键问题回答清楚比较重要。

1. 第一个是关于文化氛围的重要性。这周参与了 AIABU 的产品共学交流会，六七个不同背景的人，喝着饮料或啤酒，围绕一两个主题展开讨论。氛围轻松，没有后续必须衔接的任务和计划，更像是一种学习和交流的文化。大家把项目中的想法和经验拿出来分享，少了功利心，反而让参与者更主动、更愿意发问和交流。这样的氛围让我觉得很有价值，学习本身也因此变得更自在。

2. 第二个是共识在团队推进中的不可替代性。体会来自和项目组成员一起共创功能设计和实现方案。这个过程让我感到，尽管 AI 能显著提高效率，甚至给出一些超预期的思路，但项目归根结底还是团队的产物。共识不可避免，每个人都有不同的看法，要推动项目前进，就必须建立共同的理解。与其说这是单一决策驱动的过程，不如说是大家贡献不同经验和视角，共同探索的过程。尤其是在一个对业务和技术都陌生的项目里，路径选择众多，权衡复杂，这种共创显得尤为重要。AI 在这个过程中究竟能扮演什么角色？现实中，这种共创大多还发生在白板前的线下场景。现在可能没有清晰答案，但未来或许会出现一种“虚拟参与者”，以无形嵌入的方式加入到共创中。

3. 第三个感受是流程与业务匹配度之间的矛盾。随着 MVP 功能逐渐浮现，难题和风险被具体化。理想中希望实现 90% 以上全自动化，但现实可能只能做到 40%-50%。这意味着要在理想与完整性之间做出妥协。虽然结果不够优雅，却为后续提升留下空间。同时，时间压力也不允许我们把所有细节完全打磨后再推出。更复杂的是，MVP 设计、产品方案设计和概念工程的流程几乎相当于在做两套项目，它们的差异性超过一半。很多概念工程需要回答的问题，并不能直接帮助产品设计，反而成为一种负担。这让我产生了疑惑，或许是我水平不够。

之前做各类调研和分析的工作比较多，通过 AI 来提升效率和质量，效果已经很显著。这一周多都在做产品原型，发现 AI 居然没有太多奏效，现在回过头来看，还是有很多提升思路，先随手记一下，后面再抽时间来整理。

• 应先基于需求和 JTBD 明确结果，匹配最自然的交互形态，再区分可省略与必须保留的步骤。
• 合理划分前端交互与后台计算，平衡用户操作成本与机器计算成本。---这里可能有几个方案选择，先标注理由 → 为什么这个环节必须“露面”
• 关键在于保留必要的交互，当前来看主要还是使过程自然和相对透明可信。
• 尽管通过一些技巧，技术上能实现直接拿到“结果”，但事情发展还是要有循序渐进的过程。
• 当前也不完全是技术做不做得到的问题，是用户信任问题，也是厂家需要“免责”，这都需要时间。

设计师如果有机会，还是要影响产品形态和功能设计，虽然会多花一些时间，看起来是投入产出比低了，但效果是显著的。

最近做 MVP 功能取舍，原以为几天能梳理好，越往下做问题越多，很多地方得先和团队说清楚。这次我更多用草图推进沟通，没有急着用 AI 原型工具。眼下要验证的是能否落地、关键技术问题在哪，概念展示的精度不够。

功能设计要做减法，工具也得看当下要回答什么问题。用纸上草图能更快说清楚的，就先用草图；需要更高精度时，再补对应的原型。

做新项目时，同一个词在不同人那里可能是不同意思。如果不早点对齐，后面的方案看起来在一起推进，方向却可能已经偏开。

必要时把人拉到一起共创，先说清楚关键词和它们指的细节，再继续做方案。

突然想到，制定标准本身是在很模糊的状态下快速抓住一些要点，所以怎样补充和修正这些要点，就可以提升这个过程的效率和完备性。

最近有感，有了 AI 以后，以前看过的案例突然发挥了很大作用。 知道开始和终点，中间过程基本可以还原 80%，就可以用于后续的验证。 人在过程中还是发挥着“指挥”的作用，原先 AI 刚出来时，可以抹平了人和人之间的差距，现在反而觉得 AI 可能会进一步拉大了人之间的能力差距。

现在准备研究报告变得很快。内容的丰富度、信息的提炼和报告的完整性，都比以前提升了一个量级。但节奏变快，也意味着留给自己思考的时间变少了。

过去找资料、分析资料、输出内容，是一个边做边想的过程。实际操作会不断带来反馈，让人有机会修正问题。现在一个新命题刚提出来，有时连自己对它都还不了解，就已经开始看大量相关内容。这个看起来也对，那个也有道理，最后报告似乎拼得很完整。

但这份报告到底要回答什么问题？我们又怎么判断，它是否真的回答了这个问题？这些思考一旦在快速产出中被跳过，内容再丰满，自己心里也会知道它是空的。

我提出过一个与 AI 相关的场景和概念，也邀请相关人群做了快速验证。场景有价值，需求真实，概念本身也得到了认可。真正的挑战却在“输入条件”：支撑它落地的信息，不容易稳定地获得。

那次验证之后，我开始问另一个问题：当需求和价值都明确，但实现它的前提不成立，工作的重心是不是该改变？

有些障碍不是能力不够，而是现实里存在结构性的矛盾。问题可能早有人看见，也有人试过解决，只是解决成本太高，不值得为局部问题投入那么多资源。此时继续打磨概念，和转向寻找更可行的路径，是两种不同的选择。这个判断会影响下一步的执行策略，甚至整个方向。

最近工作有了一些进展，但也的确让我有点郁闷，半年工作回顾一下。

关于研究的价值与被认知

研究很多时候，是在寻找一些有价值但未知的信息。但实际上，“有价值”这个判断，很可能并不是来自于研究者本人的认知，而是来自于决策者的认知——是谁认为这个信息是有价值的，才决定了这个信息的地位。

回顾调研经历与输出

在今年三四月份，我做了一次大范围的调研，把市场上能看到的 AI 产品基本都梳理了一遍。

• 分析了微软、IBM 等大公司的企业应用场景；也调研了国内做 AI 的大型企业，以及聚焦企业应用的厂商；并输出了一份内容很全面的调研报告，涵盖了能看到的大部分方向，做了大量分析。
• 结合 AI 和当下目标，尝试了一些新的工作流，也取得一些成果。

焦点变化与现象反思

最近这两个月，有了更多聚焦，也在持续观察现在能做什么、该做什么。

直到最近，才真正明确聚焦到“审核”这个方向：包括合规审核、合同审核、招投标审核等等。

但其实这个方向早在去年年底就已经看到过了，今年三月份也再次出现过。那为什么直到最近一周才真正被重视起来？

原因并不是因为现在掌握了过去没有的信息，而是：

• 业务方的KPI到期了；
• 他们与客户沟通后，才发现客户确实有这样的需求。

这说明了什么？

你看到多少信息，本身并不决定它的价值。

真正决定价值的，是业务方是否看到、是否认同这些信息的价值。

信息输出的现实问题

我们常常能做的是：

• 把这些信息更好地总结、洞察、输出和讲述，
• 希望能够让业务方产生共鸣，理解这些洞察。

但现实是，单向输出的方式，往往很难让对方接受他们原本没经历过的事情。

• 所以哪怕你花了半个月做一份调研报告，
• 最终可能只是被业务方听了你讲30分钟，讨论5分钟，之后就再也没打开过。

如果重新来过，我会怎么做？

我可能不会一开始就告诉他们“有哪些场景可以做”。

我会优先：

• 想办法把外部看到的场景与内部相关部门的需求、决策者真正关心的场景进行拉通；
• 然后让有说服力的人去和业务方的决策者沟通。

因为很多时候，同样的话，从你嘴里说出来不一定有说服力，但换一个人来说，效果可能就完全不同。

当业务方犹豫不决、把握不准时，早点催他决策。

验证了大范围搜寻场景之后的筛选逻辑。随着 AI 技术的演进，以后做市场层面的机会研究，做事的方式可能还会发生变化。

这周推进了三件事：AI 场景评估模型、ROI 估算器 demo、知识库任务梳理。

核心推进是把「怎么评估一个企业 AI 机会」这件事，从散点思考推到了结构成型，搭了个“模型”，准备批量跑分，将场景进行一次初步筛选。虽说结构搭起来了，但评分逻辑偏主观，准备后续进行一轮验证。

这周做了一次概念验证，原先的结构性问题，仍然存在，不会因为 AI 就变好。

当然也有不少收获，尤其是这次，这整个流程基本都是由 AI 协助完成的，甚至可以说，80% 以上的环节是靠 AI 推动的。，在过去真的无法想象。

从最初的场景设想，到调研需求、分析行为链、识别典型场景，再到设计初步方案、输出关键概念，最后进行了一轮快速验证。

验证结果是积极的：场景真实、需求成立，价值也能被接受。

但意外的是，真正的问题根本不在 AI 的能力，而在“信息能不能进来”。

三个非常现实的难点几乎同时暴露出来：

1. 销售不想记

不管是会议中还是会后，销售都不太愿意主动记录。一是怕麻烦，二是担心自己表现被暴露，变成评估依据。

2. 客户不让记

想用录音解决，但很快发现根本行不通。大部分客户出于隐私和保密的考虑，不接受任何形式的会议录音。

3. 就算有人记，也很难记好

笔记往往零碎、不统一、不深入。内容浅、风格差异大，最终无法被结构化使用，等于信息从源头就“碎了”。

结果是：AI 足够聪明，输入却是“残缺的原料”

这轮验证让我非常清楚地意识到：

不是 AI 不行，而是它根本“没有东西可分析”。

更进一步地说，这不是某一个项目的问题，而是AI 落地普遍会遇到的结构性问题：

我们过度强调输出能力，却低估了输入机制的设计难度。

让我重新修正判断的点：

“输入机制”是 AI 系统的第一性问题

不要再假设“人愿意配合”。真正需要设计的，不是智能分析的部分，而是让信息“走进来”的通道。

总结：这不是一次输出最多的一周，但是修正判断边界的一周

我们这次做的不是一个项目，而是一种结构验证。

它让我重新思考：

• AI 概念的成立，并不等于场景可以跑起来；
• 输入条件不成立，一切输出都是假象；
• 而“输入是否成立”这件事，往往不在技术层，而在人性、组织边界、行为成本。

最近在整理一些碎片经验，对自己有用我是知道的。

对其他人而言，有用之处估计也仅限于“拓宽视野”了，或者毫无用处。

以前看别人的东西，真正能看到的估计也就 5%，觉得没什么用。

现在看来，恰好这 5% 能带来新的变量和影响，可以从“不知道”到”知道”。

但也可能由 5% 瞬间清零，因为看过的东西如果没有后续，基本也就忘了。

最近除了推进项目，也花了不少时间在做总结，有些想法：

1. 「正确」与「困难」

最近的工作逐渐聚焦，整体的轮廓慢慢清晰了起来，许多细节也在推进过程中逐步显现，变得越来越明确。

我非常清楚，这一切来之不易。

所谓的“难”，并不仅仅是因为专业能力或经验上的不足。真正的难点在于：找到那件「正确」的事情本身就很难；而即使找到了，让大家都认同这就是「正确」的事情，也同样不容易。

但这恰恰是最关键的事。

我们不能仅仅去主张一件“困难”的事情，也不能因为它挑战性高就默认它是值得做的。我们真正要做的，是聚焦于「正确」的事情——那种对整体有价值、值得长期投入的方向。

困难不是价值的“证据”，正确才是。

2. 识别「正确」的事情为什么很难？

• 谁都能说一嘴，谁都能提问题！！！越在早期或探索期，目标越抽象，边界不清，谁都可以提出“似乎有道理”的方向，谁都能提出未知，但真正“能撬动”业务价值的路径，除了往往深藏在复杂现象之后，没几个人能及时提出来。
• 每个人的意见都很多，尽管他并未深入了解过。每个人的利益、风险感知、经验偏好都不同。你即使识别出了“正确的事情”，也未必能立刻获得广泛支持。
• 验证成本高。很多真正正确的决策，短期看不到效果，甚至还需要“先踩几个坑”才有全貌，很容易在中途被质疑。对个人或团队的信心都有很多的打击。-----其实在两周以前，我们也有个怀疑，如果这个方向还被否定了，我们该做什么？？

用 AI 解读书籍，或许应该往“厚”的方向读。

读一本书，除了找自己能共鸣的信息，还可以试着从不同角度理解书中的观点。世界上不只有作者的视角和我自己的视角，也有许多与它们不同的经验和看法。新的共鸣，未必只来自作者原来的说法。

项目的设计排期，其实是策略的执行安排。

比如，一个设计部门要发起未来两年有业绩潜力的新项目，并在三个月内完成 1.0 版本、得到验证。要做排期，就得先把命题拆开：背景是什么，为什么做，需要回答哪些问题；然后才知道设计、产品、开发、干系人管理和资源申请各自要做什么。

这个解构过程就是在想“怎样做，才更可能得到想要的答案”。先做什么、后做什么、不做什么，是执行上的取舍；把这些工作放进时间表，策略就有了可见的形状。

所以排期上的每一项工作都值得再问一句：做完能拿到什么，为什么要在这里做？如果回答不了，排期可能只是事情的堆叠，还没有成为执行方案。

如果想发现“不足”，首先需要一条比现状更高的标准。我把它想象成一条“虚线”：它代表理想值，或者事情可能达到的理想状态。有了这条线，再看现状，差距才会显出来，我们也才知道要补足什么。

但很多时候，用户自己提不出那个“理想”。这时，设计师要在理解具体情境的基础上，试着提出一个可能的理想状态，再去检验它是否真的有价值。

这样看，需求洞察也包含一个动作：在合适的范围内，提出值得验证的假设。

最近两年的工作，仿佛一直在通过研究寻找新的用户问题、新的需求。我开始怀疑：如果总期待发现前所未有的机会，会不会反而限制了创新？真的有那么多完全没人遇到、也没人尝试解决的问题吗？

我跟同事聊过这个疑问。既然旧问题一直存在，为什么不鼓励大家创造更好的新方案去解决它？有人提醒我，公司其实也有鼓励创新的课题，只是创新本身不容易。我不反驳这一点；这个话题到现在也没有结论。

但我想继续保留这个问题：在寻找新问题之外，我们是不是也该认真看一看，已有的问题还有哪些更好的解法？

原来之前做“整体洞察”时，总觉得内容有价值，却又好像缺了什么，问题可能就在这里：它没有影响到决策者的下一步行动。

研究成果和洞察还需要回答一个问题——接下来做什么？也就是那个“然后呢”。

看到一篇谈设计时机的文章，想起以前做项目时聊过的一个例子：小程序要获取用户的地理位置，有的在刚打开时就申请，有的等用户真的需要位置服务时再问。两种方式也许都能取得权限，但前一种会让我觉得不太礼貌。

如果把小程序比作一个人，刚见面的陌生人就问你家地址，总会显得莫名其妙。可如果他捡到了你的手机，想寄还给你，这时再问地址，感受就完全不同。

向用户索取信息，尤其是个人信息，不能只看自己什么时候用得上，也要想想对方此时是否理解你为什么要问。