ARTICLE · 1199292
同事都说你的 AI 工具不错,然后呢?
同事都说你的 AI 工具不错,然后呢?借助大模型，把一个工作想法做成可以操作的原型，也就是 Demo，已经比过去容易得多。描述需求、生成页面，再根据结果修改，想法很快就能得到反馈。只要能帮自己少做一些重复工作，这样的尝试就有价值。 之前那篇 ，讨论的是交付时还缺什么。这次，我想往前再问一步： 一个 Demo 已经做出来，甚至获得了不错的反馈，我们凭什么决定，要继续把它做成产品？ 先做一个自己用得上的看板 设想这样一个场景。一位商务人员，每次拜访客户之前，都要打开客户管理系统，也就是 CRM，再翻一遍拜访记录和聊天信息，才能想起上次聊到了哪里、答应补充什么材料、这次应该问什么。 于是，他借助大模型做了一个商机看板：客户近况、最近的沟通记录、待跟进事项，都集中到一个页面上。大模型帮他整理记录，他自己核对重点，再决定接下来联系谁。 这个demo不一定很完整。只要能减少自己反复翻资料的时间，就可以继续用下去。 但此时验证的只有两件事：信息能够被整理出来，它对创建者本人有帮助。然而其他人是否有同样的困难，这种整理能不能稳定地减少工作，都还不知道。 
别人觉得不错，具体在认可什么 接着，他把看板分享给团队。有同事觉得一页看全客户情况很方便，有人希望增加客户意向评分，也有人问能不能自动生成拜访记录。 这些反馈都值得听，但还不能直接变成功能清单。 “这个不错”，可能是在认可页面，也可能只是觉得某个能力新鲜。只有回到实际工作，才能知道对方打算在什么时候用它，想用它替代哪一步操作。 比如，进一步询问后发现，一位同事最费时间的是拜访后反复整理记录：聊天里记一次，CRM 里再填一次，开会前还要汇总到表格里。他需要的不是更多图表，而是把一次沟通整理成可核对、可复用的记录。 另一位同事更在意拜访前的准备。 两种需求都和客户有关，却发生在不同环节，不适合一次全部解决。看板给讨论提供了起点，真正值得继续做的部分，还要到实际工作里去找。 
有了真实问题，也不一定另做系统 假如团队确认，重复整理拜访记录是大家共同的痛点，下一步也不必急着把整个看板开发成新系统。 先看已有的 CRM 是否已经支持相关功能，只是用起来不方便，或者团队没有统一的记录方式。如果用好现有功能、调整一下填写流程，就能解决大部分问题，再建一个独立系统，反而会多出一处需要同步的数据。 如果现有系统缺的，是把零散记录整理成草稿的能力，那么值得验证的只是一个辅助功能：大模型提取客户需求、待办事项和下次联系时间，商务人员确认后，再放回原来的工作流程。不妨叫它“拜访记录助手”。 这时，最初那个漂亮的看板已经不是主要交付物了。但它没有白做，它帮大家找到了更具体的问题。做成产品，不一定意味着新建一套系统；已有产品里的一个功能，同样可以承接经过验证的需求。 
用真实工作检验，而不是继续扩功能 沿着这个方向，可以先找几位有相关需求的商务人员，在允许使用客户资料的范围内，覆盖几次真实拜访。先把记录整理和人工确认这一小段做好。 要看的不是“模型生成了多少字”，而是和原来的做法相比，整理、核对、修改和录入加在一起，是否更省时间。比如，原来整理一次拜访要 30 分钟，现在生成只要几分钟，核对修改再花 10 分钟，这才是有意义的比较。此外，还要看客户的重要要求有没有遗漏，整理出的待办事项能不能直接用于后续跟进。 还要观察：在没有人催着试用的情况下，同事下一次需要整理记录时，会不会再次使用它。如果没有，要弄清楚是没有合适的任务，还是操作太麻烦、结果需要改得太多。只看打开次数，分不清这些情况。 这类试用很难在短期内证明它能增加成交，因为客户签不签约，还受价格、预算和竞争等因素影响。先验证它能否减轻整理负担、保住重要信息，比把短期业绩变化直接归功于 AI 更稳妥。 
根据结果，决定投入到哪一步 试用之后，大致会有四种结果。 第一种，它主要适合创建者自己的记录习惯，其他人暂时没有同样的需要。那就保留为个人助手。它已经产生了价值，不必为了证明创新成功而扩大使用。 第二种，部分同事有共同需要，但记录格式和分析重点还没有理清。那就继续小范围调整。这时要弄清的是哪些问题反复出现，而不是谁再提一个建议，就往页面里加一个功能。 第三种，需求得到验证，而且现有系统能够承接。那就把它融入已有系统，作为 CRM 里的一个功能，或者一段调整过的流程。这往往是成本最低、阻力最小的选择。 第四种，它在真实任务里持续减少了重复工作，结果经核对后能进入原有流程，相关团队也愿意投入资源，现有系统又承接不了。这时才有充分的理由考虑单独做成产品。即使只服务少数专业人员，只要解决的问题足够重要，也值得投入，人数不是唯一的标准。 到了这一步，再估算接入系统、人工检查和后续维护的完整投入，并与已有方案比较。上一篇讨论过的数据、权限、测试和运维，是交付时要补上的工作；这里关心的是，这些投入与已经验证的价值是否相称。 
归结起来，是四个问题 回头看，判断一个 Demo 是否值得继续投入，可以问四个问题： 人人都能做 Demo 之后，常有人问：产品经理还有什么用？或者反过来问：业务同事做出的 Demo，是不是都该交给产品经理接手？ 回头看这个商机看板，最初的想法来自商务人员，Demo 也是他自己做的。产品经理并不独占提出想法的权利，也不应该因为别人提出了想法，就自动承担把它上线的责任。 但这个过程里，仍然有很多产品工作：弄清“想要一个看板”背后的实际困难，区分哪些只是个人习惯，比较新建工具与改进现有系统，再用真实任务检验取舍。页面生成得再快，也不会替我们做出这些判断。 这些工作可以由懂业务的搭建者继续做，也可以由业务、产品和研发一起完成。需要谁参与，取决于问题和资源，不需要先给每个 Demo 指定一个产品经理来接手。 对产品经理而言，精力可以更多放在这些选择上。比如，同事提出“增加客户意向评分”，先了解他要据此做什么决定；如果他真正担心的是漏掉已经答应客户的事项，把待办记录补好会更有用。能把需求收窄、少做一项没有必要的功能，也是在推进产品。 这也意味着，全员vibe coding之后，企业要允许试用结果走向不同的选择：有的继续投入，有的融入已有系统，有的停留在个人使用。如果每个 Demo 最后都必须立项，大家反而会更在意证明自己的方案正确，而不愿承认更简单的办法也能解决问题。停在个人使用，不应被看作失败；发现现有系统改一改就够用，同样是一种成果。 
每一个把工作经验变成工具的尝试，都值得鼓励。Demo 让过去只能口头描述的想法，变成了可以体验、比较和修改的东西，也让更多岗位有机会参与创新。 但从商机看板到拜访记录助手，最终值得投入的东西，往往和最初做出来的样子不同。重要的是，我们是否更清楚地认识了使用者的问题，是否找到了比现有做法更合适的办法。 人人都能做 Demo 之后，决定下一步的依据，应当逐渐从“我把它做出来了”，转向“它在谁的真实工作里，带来了值得继续投入的改善”。
《自己搭了一个智能体，为什么还不能直接给别人用》
丸子wonderland，公众号：丸子的硅基手记自己搭了一个智能体，为什么还不能直接给别人用？
一 从一个商机看板说起
这个困难是创建者独有的，还是一类人反复遇到的？ 现有系统和流程，是否已经能解决大部分？ 在真实任务里，没人催的情况下，它是否被反复使用，并且确实省了事？ 接入、检查和维护的完整投入，与已验证的价值是否相称？ 
二 产品工作体现在具体选择里
