来源
- 来源类型：订阅邮件正文
- 来源标题：🧠 Community Wisdom 298
Community Wisdom 298：先找痛点与瓶颈，再决定用 AI 还是换工具
总体判断
这期四组讨论表面上分散在儿童篮球 AI 教练、Jira 与 Linear 迁移、平台团队的商业论证，以及工作中的 AI 用法，底层却在回答同一个问题：当一种新能力看起来可以加速工作时，怎样确认它击中了真正的约束。
最常见的顺序是先看到技术，再寻找它可以解决的问题。做 AI 产品时先问该用什么模型，改造研发流程时先问该换什么工具，建设平台时先列一组容易采集的指标，引入 AI 时先追求复杂、显眼的用例。这期社区讨论给出的顺序正好相反：先找到谁正在承受足够强的痛点，再分清问题来自能力、流程还是组织结构，随后建立从局部变化到业务结果的证据链，最后才选择模型、工具和推广方式。
这个判断与汉松当前的两类工作都有关。做 AI 健康管家时，模型能力需要嵌入专家知识、确定性流程、渠道和责任边界，才能构成完整产品。带研发团队时，AI 提升局部产能之后，系统瓶颈往往迁移到需求判断、协作接口、评审和验证。技术带来的速度只有穿过这些约束，才能变成最终结果。
一、AI 产品验证先找非解决不可的人
背景：一位家长想做儿童篮球 AI 教练。家长用手机录下训练，系统标出孩子做得好的地方和需要改进的动作，还可以加入动作匹配与奖励机制。讨论很快从这个功能是否合理，转向谁真正需要它、谁愿意付费，以及现有教练体系留下了什么缺口。
这是一个成立的使用场景，但问题在于：当许多人觉得 Gemini 已经能给出不错结果时，你能否让他们为它付费？
你指出了一个可能存在的问题。下一步要验证的是，其他人是否也看见这个问题，而且在意到愿意采取行动。对大多数家长、孩子和教练来说，它更像维生素。做得更好当然有益，但即使什么都不改变，事情大概也不会出问题。
哪些人如果不解决它，事情真的会变糟？他们才是第一批客户。
这段最有价值的地方，是把需求验证从普遍认同推进到行为后果。家长觉得赛后分析有帮助，只能证明产品具有可理解的价值。只有某一类家长、教练或机构会因为缺少持续反馈而失去训练效果、续费率、招生竞争力或学员进步，产品才获得足以驱动购买的压力。
因此，第一批客户的筛选条件可以写得更具体：训练目标较高，但一名教练同时带八到十个孩子，无法观察每次动作；家长愿意在课后继续投入；训练机构需要证明教学质量或形成差异化；教练愿意让反馈成为训练流程的一部分。这里每增加一个可观察条件，都比继续讨论视觉模型的能力更接近真实验证。
对健康 AI 产品也一样。广泛存在的信息需求，未必构成可持续产品。更重要的问题是：哪些用户因为信息不连续、专业资源不足或执行反馈缺失，正在承担明确损失；谁对改善结果拥有动机和预算；产品进入现有服务链后，谁会持续使用它。
二、模型只是能力组件，产品由专家、流程与渠道共同构成
背景：提问者担心没有合适的模型。社区成员却认为，更早需要确定的是一组能为机构创造结果的功能，其中有些由 AI 驱动，有些来自专家合作，有些适合确定性流程。
AI 模型只是为若干功能提供动力的工具。有些能力可以由专家合作完成，另一些可以完全采用确定性流程。真正需要优先考虑的是，你准备提供哪一组彼此配合的功能。
它也可以直接整合进俱乐部和学校，让机构天然获得用户订阅，并把这套能力变成自己的差异化优势。专家的输入也会让结果更有价值。
这给出了一条很实用的 AI 产品原则：把模型选型放在产品系统之后。儿童训练反馈至少涉及视频采集、动作识别、教练示范标准、同类动作比较、反馈表达、训练计划、激励机制和结果追踪。模型适合承担其中的识别、比较与生成，专家负责定义正确动作和风险边界，确定性流程负责身份、课程、记录、评分与通知，机构则提供服务场景和分发渠道。
单独的模型能力很容易被通用产品吸收。真正形成差异的部分通常来自三类组合：专有的领域判断，嵌入真实服务的工作流，以及能够持续产生反馈数据的渠道。提问者从面向家长的独立应用，转向与俱乐部或学校合作，实质上是在重写分发与使用频率，而不只是调整销售对象。
这对医疗健康场景尤其重要。模型可以解释、整理和生成建议，专家协议决定什么属于可靠建议，确定性系统维护个人状态与干预节奏，医疗或健康服务方承担可信入口和责任边界。产品设计应该先画出这套能力分工，再判断每个环节需要哪种模型。
三、换工具之前，先把流程问题和组织问题拆开
背景：一个约五十人的团队深度使用 Jira，工程师普遍反感它，提问者也难以在大量工单和看板之间导航，同时 Jira 的 MCP 与 Claude 等 AI 工具配合不够理想。社区对 Linear 的体验评价有分歧，却在迁移方法上形成了较稳定的判断。
五十人的 Jira 迁移可能比你试图解决的可用性问题更昂贵。先把痛点拆成流程与层级问题，例如日常导航，以及 AI 和 MCP 访问。Linear 可能改善其中一部分，但权限、报表、自动化和习惯仍然需要重建。
先让一个小团队试跑一条端到端流程，并测量什么真正变容易了。既然 PRD 已经连接业务与交付团队，改进进入 Jira 的交接过程，可能比替换 Jira 获得更多收益。
十次里有九次，问题出在流程而非工具。迁移到新工具以后，你会同时得到迁移留下的混乱和原来的流程问题。
这里值得保留的并非 Jira 或 Linear 谁更好，而是一种迁移诊断法。把抱怨拆成可以验证的摩擦：工程师每天完成核心动作需要多少步骤；工单层级是否超过决策需要；跨团队依赖怎样暴露；业务需求如何进入研发；AI 能否读取足够上下文并安全执行；哪些权限、报表和自动化是组织真实依赖。
随后用一条完整工作流做试点，而不是只比较界面。试点需要覆盖需求进入、任务分解、协作、状态同步、跨团队依赖、结果交付和复盘。只有端到端周期、维护成本、信息遗漏和成员体验同时改善，工具优势才穿过了组织系统。
AI 和 MCP 会让这个判断更复杂。一个工具拥有更好的 Agent 接口，确实可能改变操作成本，但它仍然无法替团队决定工作应该管理到什么粒度、谁负责拆解、跨团队如何协调。AI 可以降低流程的执行成本，流程本身仍需要组织做出选择。
四、平台团队需要证明它改变了业务结果的变化率
背景：平台团队通常缺少直接收入或即时成本节约。提问者想知道，开发者速度、数据可信度、上市时间和活跃用户等代理指标，怎样才能真正说服管理层。
当平台团队的工作与产品团队相关时，可以共享 OKR。平台团队重构了 X，使产品团队能够构建 Y，最终带来了某个业务结果。
可以用一阶导数来理解平台指标。与其追踪用户获取本身，不如测量平台是否提高了用户获取的速度。我正在建设产品平台，因此采用新产品接入速度作为平台指标。
平台价值的难点在于它是一种使能关系。直接统计平台完成了多少项目、服务了多少团队或获得多少内部活跃用户，只能说明平台发生了活动。更有说服力的证据链是：平台改变了产品团队的哪项能力，这项能力又如何改变交付节奏、质量或业务结果。
可以把商业论证写成三层：第一层是平台动作，例如统一数据能力、重构公共服务或缩短环境准备；第二层是被使能团队的行为变化，例如新产品接入更快、实验周期缩短、重复建设减少；第三层是业务结果，例如用户增长加速、上市时间提前、故障损失下降。每一层都需要说明基线、变化幅度和归因边界。
一阶导数的视角很适合平台团队。平台自身通常不拥有最终结果，却能改变结果发生的速度。新产品接入数量未必完全归因于平台，新产品接入所需时间、成功率和单位成本更接近平台能够控制的变量。共享 OKR 则把使能关系变成共同责任，避免平台团队只交付能力、产品团队却没有使用或反馈。
对 AI 基础设施和 Agent 平台也可以沿用这套方法。统计模型调用量、Agent 数量或 token 消耗只反映使用规模。更好的指标是：一条真实业务流程从提出到验证缩短多少；人工复核负担如何变化；错误能否更早被发现；多少团队在相同治理标准下完成了稳定交付。
五、最有效的 AI 用法往往在持续摩擦处形成闭环
背景：社区成员分享自己最喜欢的工作 AI 用法。案例从日历缓冲、工时记录，到会议行动项、跨工具信息检索、行业周报和 Obsidian 工作日志。它们大多没有追求复杂的独立产品，而是消除每天或每周重复出现的认知摩擦。
工作本身总会留下证据：提交记录、会议、日志、已发送邮件、消息、文件编辑、软件使用记录、打开的标签页和浏览历史。我把这些证据汇总到每周的表格里，保留足够细节，帮助自己回想做过什么，再分配工时。
每天读取邮件和消息，识别待办和已经完成的事情；周五再把这些信息汇总成每周记录，补充说明，提交到 Obsidian，并标出关键阻碍和跨周延续的事项。
Agent 根据会议记录和 Slack 互动生成待办，帮助我避免遗漏；需要过去的信息时，直接让 Claude 查找，无需再回忆它究竟在 Notion 还是 Slack。
这些案例共同采用了一种证据优先的个人工作系统。AI 没有凭空猜测人做过什么，而是读取工作自然留下的数字痕迹，再完成聚合、检索、提醒和压缩。原始证据仍然存在，人在最后进行项目归属、工时判断、优先级和意义解释。
这与汉松当前通过 cron、Obsidian、技能和长期记忆搭建的协作方式几乎同构。真正有复利的部分并非一次生成，而是稳定运行的循环：收集可追溯证据，转成结构化状态，在固定节奏里回顾，再把判断反馈到下一周。Agent 负责降低整理成本，人负责确认什么值得继续、什么构成阻碍、什么应该沉淀成方法。
另一个日历案例也说明，用例价值与复杂度关系很弱。根据健身课程自动在前后增加二十分钟通勤缓冲，只解决一个很小的问题，却长期保护了真实生活安排。好的 AI 自动化通常拥有明确触发条件、稳定动作和可以直接感知的结果。
六、AI 提升局部产能以后，系统瓶颈会向下游迁移
背景：邮件最后推荐了一篇关于容量与速度的文章，并用约束理论解释 Agent 编程带来的组织现象。
提高上游非瓶颈环节的局部产能，并不会改善系统吞吐量。它只会让下游约束被更多在制品、失败返工和延迟淹没。
这是整期可以继续延展的一条判断。AI 让代码、文档、原型和分析更快地产生，等于显著扩充若干上游环节的容量。只要评审、测试、决策、部署、客户反馈或责任确认仍是瓶颈，更多生成只会形成更大的待处理队列。
因此，衡量 AI 效率时不能停在个人产出或单步速度。需要观察系统吞吐量：从问题提出到结果验证的总周期是否缩短，在制品是否增加，返工率是否上升，下游等待时间是否变长，最终交付的质量和数量是否改善。
这也把前面几组讨论连接起来。儿童篮球产品需要先找到用户真正受限的环节；Jira 迁移需要识别流程与协作瓶颈；平台团队需要证明自己提高了业务能力的变化率；个人 AI 工作流则通过持续收集与反馈，减少行动和回顾之间的断裂。技术的价值取决于它是否作用在当前约束上。
贯穿判断：先定位约束，再选择能力，再建立证据链
这期可以压缩成一个三步方法。
第一，定位约束。找到事情无法继续改善的原因，以及哪一类人正在承担足够强的后果。第二，选择能力。判断问题需要模型、专家、确定性流程、工具替换还是组织调整，并让它们按真实职责组合。第三，建立证据链。从局部动作一路连接到行为变化、流程变化和最终结果，同时保留基线与归因边界。
这套方法能够避免两种浪费。一种是用先进技术解决弱需求，最终停在演示和礼貌性认可。另一种是在错误环节继续增加容量，让下游积压和返工加重。AI 时代的稀缺能力会越来越集中在约束识别、系统组合与结果验证上。
可复用判断
- 产品验证要寻找不解决就会承担明确后果的人，而不是只寻找觉得功能有帮助的人。
- 模型是产品系统中的能力组件。专家判断、确定性流程、分发渠道和反馈数据共同决定产品是否成立。
- 工具迁移前先把痛点拆成流程、层级、协作和接口问题，再用一条端到端工作流进行试点。
- 平台价值需要从平台动作连接到团队能力变化，再连接到业务结果。变化率通常比活动量更接近真实价值。
- 高复利 AI 工作流从自然产生的工作证据出发，在固定节奏中完成整理、回顾和反馈。
- 自动化价值取决于摩擦出现的频率和结果是否可感知，与方案复杂度没有稳定正相关。
- 提高非瓶颈环节的局部容量，只会增加在制品、返工和等待。AI 效率要用系统吞吐量检验。
- 先定位约束，再选择能力，最后建立证据链，可以同时用于产品、平台、团队和个人工作流。
可延展写作题
- AI 产品为什么应该先做能力分工图，再做模型选型？
- 从维生素到止痛药：怎样找到 AI 健康产品中非解决不可的第一批用户？
- Jira 与 Linear 之外，怎样判断研发团队面对的是工具问题还是组织问题？
- AI 平台如何用一阶导数指标证明自己的商业价值？
- 当 Agent 让代码产能增加十倍，研发系统的新瓶颈会出现在哪里？
- 如何把提交、会议、邮件和消息变成一套可追溯的每周工作记忆？