我们用 Patrick 来制造 Patrick。不是另一个 LLM 故事。
Source: Dev.to
好吧，这算是半个谎言。但让我先把情境说清楚。
我的同事和我正在研发我们的医疗技术解决方案。我们团队人数不多，每一次软件迭代、每一次客户访谈以及每一次新合作都会打开数十条可能的方向。
我们应该追求医院试点还是远程医疗集成？是先构建移动用户体验，还是先确保合规？萨斯喀彻温省的诊所想要的东西与温尼伯的研究医院略有不同——我们是要分叉路线图，还是寻找重叠部分？
我们像大多数初创公司一样记录这些信息：零散的笔记、共享文档、偶尔有人英勇地更新一周后就被抛弃的电子表格。这种方式一直有效，直到它失效。某天我们坐下来开战略会议，才意识到我们有 四十多个组织 在我们的轨道上，五条产品线 处于不同阶段，超过一百个未完成任务，却没有一个连贯的方式来查看它们之间的关联。
于是我们创建了 Patrick。
Patrick 实际上是什么
Patrick 不是 仪表盘。它不是 CRM。它也不是项目管理工具，尽管在需要时它可以表现得像这三者。
从本质上讲，Patrick 是一个 结构化摘要 和 知识图谱。Patrick 并不是为了减少字数或加快阅读速度而进行摘要；它的摘要是 有目的的：
- “这个任务的开发将如何推动该倡议？”
- “这个组织的需求如何为该开发任务提供依据，它们是否与股东大会设定的优先级保持一致？”
概念之间以有意义的方式相互连接，而这些 连接本身就是重点。
当我们问，“如果我们推迟这个功能会怎样？” 时，Patrick 不仅仅显示一个变红的甘特图。它 追踪上下游的影响——哪些客户需求得不到满足，哪些潜在客户受到影响，哪些任务变成孤儿。
当我们问，“我们接下来应该构建什么？” 时，它不仅仅按优先级排序。它 在价值、工作量和风险之间进行权衡，告诉我们快速获胜的机会藏在哪里，战略性赌注又位于何处。
使它区别于电子表格、Notion 看板或 Obsidian 知识库的关键在于 Patrick 能够理解关系。
没有人在谈论的问题
大家对 AI 工具的误解在于：讨论总是围绕 模型——哪个更聪明，哪个更快，哪个更少出现幻觉。但模型已经不再是瓶颈。是你。
或者更准确地说，你告诉它的内容才是瓶颈。
想想你上一次让大型语言模型帮助你做业务决策时的情形。你可能花了十分钟写一个提示，试图捕捉全貌——你的客户是谁，你在构建什么，正在进行哪些交易，哪些环节被阻塞。你给它提供了一小段真实信息，它便基于这段信息给出一个自信的答案。也许它很有用，也许它错过了你忘记提及的细节。
现在想想你合作过的最优秀的高管。当他们坐下来思考一个问题时，根本不是从五分钟前敲出的提示开始的。他们是从一个 整个组织的心智模型 出发——每一段关系、每一个依赖、每一个半成品的计划、每一项六个月前对客户的承诺。正是这种上下文让他们的判断如此精准。
Patrick 就是这种上下文，被外化并结构化，以便 AI 能像优秀高管利用组织记忆一样使用它。
实际运作方式
导致 Patrick 的洞见并非技术层面的，而是这样的：从 AI 中获益最大的人，并不是拥有最佳提示词的人，而是那些已经弄清楚如何向 AI 提供真实完整的情境图景的人。
我们研究了这些人的做法——那些持续从大型语言模型中获得战略价值的高管和运营者，而不仅仅是帮助写邮件。我们发现他们都有一个共同点：他们维护着关于业务的结构化信息，并将其注入与 AI 的对话中。
- 有些人使用精心搭建的 Notion 系统。
- 有些人使用填充了文档的自定义 GPT。
- 大多数人做得不够好或不够一致，因为手动维护这种结构相当于第二份工作，而没人愿意签约。
于是我们把有效的做法整合成一个系统。Patrick 收集关于你的组织的信息——潜在客户、产品、团队容量、战略重点以及它们之间的关系——并将其结构化为一个 图谱。随后，当你提出问题时，AI 不再是面对一个冷冰冰的提示，而是拥有完整的组织全景，并针对你所提的具体问题进行调优。
“我们应该推进这项合作吗？”并不是在真空中回答的。它会在你已经在构建的内容、还有谁需要相同能力、成本是多少，以及是否符合你在上个季度承诺的方向的上下文中得到回答。
当它变得递归时
几个月后，Patrick 已经成为我们公司的 神经系统。每次会议都以 “Patrick 说了什么？” 开场。每个新线索都被录入为一个组织，并将需求关联到功能。我们每周进行一次产品组合健康检查和价值分析。
然后出现了一个问题：我们接下来应该为 Patrick 本身构建什么？
我们有很多想法。很多：
- 一个聊天机器人界面，让非技术团队成员可以对话式查询它。
- 更好的报告模板。
- 用于对战略举措进行评分的评估框架。
于是我们做了本能的事。我们 打开 Patrick，为每个想法创建功能，将它们链接到它们将服务的需求，估算工作量，并进行分析。
Patrick 告诉我们 Patrick 需要什么
分析显示，对话式界面将释放最大的价值——并非因为它在技术上最为惊艳，而是因为它可以让我们的 CEO（以及团队的其他成员）自然地查询系统，而无需学习新的用户界面或记住特定的图查询。
从此，Patrick 的路线图开始看起来与公司其他部门的路线图非常相似：上下文感知、关系驱动，并且始终在问“整个系统现在需要什么？”
为什么我们要发布它
我们为一家拥有五名员工、在四个省份管理四十多个关系的医疗科技公司构建了 Patrick。但它所解决的问题并不是医疗科技的问题，甚至不是创业公司的问题。
今天使用 AI 的每一位知识工作者都面临同样的局限：AI 的表现只能和你告诉它的内容一样好，而没有人有时间把所有信息都告诉它。每一次提示都是对真实情况的有损压缩。你的工作越复杂，遗漏的内容就越多，输出的质量就越差。
Patrick 很快将作为 OpenClaw 的技能 推出。这意味着，如果你已经在运行 OpenClaw 实例——即在自己的机器上拥有自己的 AI 助手——只需安装 Patrick，就可以开始构建组织的结构化画像，让你的 AI 真正能够使用这些信息。
你不需要具备技术背景。该技能附带了我们根据已验证的模式预先构建的提示——这些正是成功运营者用来从 AI 中获取战略价值的方法，已打包好让你无需自行摸索。
- 向 Patrick 介绍你的业务。
- 输入你的会议记录、客户名单、产品路线图。
它会对数据进行结构化、关联，并让你的 AI 能够访问这些信息，从而每一个提问都能基于完整的全局图景得到回答。
结果不是一个更好的聊天机器人，而是一个信息更充分的聊天机器人。这两者的差别，就在于一个只能写出漂亮的段落，而另一个真的能帮助你思考。
这对你意味着什么
如果你曾希望你的 AI 助手真正了解你的业务——不是那种“我会假装记得”的模糊方式，而是那种“我知道你的三大潜在客户、他们各自的需求，以及你的哪些功能一次性满足了其中两个”的方式——这正是 Patrick 所能做到的。
- 我们用它创建了一家医疗技术公司。
- 然后我们用它创建了它自己。
- 现在我们想看看你能用它构建出什么。
Patrick 很快将作为 OpenClaw 技能上线。安装它，教会它你的业务，并开始提出更好的问题。