Introduction引言
Not long ago, one of my engineering directors came to me with a request: His team seemed overloaded, and he wanted to hire another engineer. I decided to test a research assistant I had been building—an AI agent connected to our internal systems via MCP—by asking it to analyze the team’s workload and write a hiring case.不久前，我的一位工程总监向我提出请求：他的团队似乎不堪重负，想再招一名工程师。我决定测试一下我一直在构建的研究助手——一个通过 MCP 连接到我们内部系统的 AI 智能体——让它分析团队的工作负载并撰写一份招聘理由书。
What came back was thorough. Headcount, service ownership, sprint velocity, ticket backlog, and capacity allocation, all of it neatly summarized. But reading through the document, I felt the same frustration I’d felt with every AI-generated organizational report that’s come across my desk. It told me what was happening without helping me understand why, or what I should actually do. It was organized around the data rather than around the decision. In short, it was the kind of response that’s easy to agree with and difficult to act on.反馈回来的内容很详尽。人员编制、服务所有权、冲刺速度、工单积压和容量分配，所有这些都整理得井井有条。但在阅读这份文档时，我感到了与以往任何摆在案头的 AI 生成组织报告时同样的沮丧。它告诉了我正在发生什么，却没能帮我理解原因，也没告诉我实际上该做什么。它围绕数据而非决策进行组织。简而言之，这是一种容易让人赞同却难以付诸行动的回复。
Then I added one more thing to the configuration: the O’Reilly Expert MCP server. I reran the same analysis and asked a slightly different question: “How would the experts on O’Reilly review this request?”然后，我在配置中增加了一项内容：O’Reilly 专家 MCP 服务器。我重新运行了同样的分析，并提出了一个略有不同的问题：“O’Reilly 的专家们会如何评估这一请求？”
Instead of leading with headcount and ticket counts, the output now opened with a finding: “The operational overhead problem is structural, not a staffing deficiency.” Citing the Google SRE framework’s concept of operational toil, it noted that the team was operating at approximately 67% toil, well above the threshold at which the SRE literature recommends structural intervention, and made specific, concrete recommendations: run a toil audit, set explicit reduction targets, and assign operational runbook ownership. This wasn’t a recommendation for whether to hire or not. It was a grounded, traceable argument for doing something else instead.输出结果不再以人员编制和工单数量开头，而是以一个发现作为开场：“运营开销问题是结构性的，而非人员配置不足。”它引用了 Google SRE 框架中关于运营琐事（toil）的概念，指出该团队的琐事占比约为 67%，远高于 SRE 文献建议进行结构性干预的阈值，并提出了具体、实在的建议：进行琐事审计、设定明确的削减目标，并分配运营运行手册（runbook）的所有权。这并不是关于是否招聘的建议，而是一个有理有据、可追溯的替代方案。
That difference—between a data summary and an expert-grounded recommendation—is what this paper is about.这种差异——数据摘要与基于专家知识的建议之间的差异——正是本文探讨的主题。
What follows is a case study of how we built an organizational intelligence system at O’Reilly, using our own platform as a core component. The approach I describe is grounded in engineering because that’s where I work, but it generalizes to any function where important knowledge is scattered across multiple systems and important decisions require synthesizing all of it. The recipe has four steps: map your information hierarchy; connect those systems to an LLM via MCP and write a skill file that defines how it should reason; add the O’Reilly Expert MCP as an expert review layer that grounds the analysis in established frameworks; and build a lightweight system for human-in-the-loop review. I’ll explain each step in detail and make the case for why the third step is the one that changes everything.接下来是一个案例研究，讲述我们如何在 O’Reilly 构建组织智能系统，并以我们自己的平台作为核心组件。我所描述的方法基于工程领域，因为那是我的工作所在，但它同样适用于任何重要知识分散在多个系统、且重大决策需要综合所有这些信息才能做出的职能部门。该方法包含四个步骤：映射信息层级；通过 MCP 将这些系统连接到大语言模型（LLM），并编写定义其推理方式的技能文件；添加 O’Reilly 专家 MCP 作为专家评审层，将分析建立在既定框架之上；以及构建一个轻量级的“人在回路”（human-in-the-loop）评审系统。我将详细解释每一步，并阐述为什么第三步是改变一切的关键。
Why organizational intelligence is getting harder为什么组织智能变得越来越难
To understand the problem this approach solves, it helps to look briefly at how engineering has changed over the past three decades. These forces have played out first and fastest in engineering, but as AI tools proliferate beyond the engineering team, the underlying dynamic of more output, more decisions, and more scattered information is spreading to every part of the organization.要理解这种方法所解决的问题，简要回顾过去三十年工程领域的变化会有所帮助。这些力量首先在工程领域以最快的速度发挥作用，但随着 AI 工具在工程团队之外的普及，产出更多、决策更多、信息更分散的潜在动态正在蔓延到组织的每一个角落。
In the waterfall era of the 1990s, software organizations ran on central plans. Everything was specified up front, and leaders maintained visibility precisely because all information flowed through a single coordinating document. The plans were brittle and often fictional by the time they were executed, but at least everyone knew what was supposed to be happening.在 20 世纪 90 年代的瀑布式开发时代，软件组织依赖中央计划运行。一切都在前期确定，领导者之所以能保持可见性，正是因为所有信息都通过单一的协调文档流动。这些计划虽然僵化，在执行时往往已与现实脱节，但至少每个人都知道应该发生什么。
Agile replaced central plans with small, autonomous teams working in short sprints, and this solved the reliability problem while creating a visibility problem. Important decisions began happening locally and quickly—the right teams making the right calls—but the information needed to see across all of those decisions splintered into dozens of separate tools. Product strategy lived in one system, project execution in another, code in a third, and service ownership in a fourth. More things got shipped, but the big-picture view got harder to maintain.敏捷开发取代了中央计划，转而采用在短冲刺中工作的小型自治团队。这解决了可靠性问题，却带来了可见性问题。重要的决策开始在局部迅速发生——正确的团队做出了正确的决定——但洞察所有这些决策所需的信息却分散在数十个不同的工具中。产品策略存在于一个系统中，项目执行在另一个，代码在第三个，服务所有权在第四个。交付的东西更多了，但宏观视野却更难维持。
The agentic era has intensified this dynamic dramatically. Individual engineers today can ship in a day what used to take a full sprint team. The output is extraordinary, but the visibility is nearly gone.智能体时代极大地加剧了这种动态。今天的个体工程师一天内能交付的内容，过去需要整个冲刺团队才能完成。产出非常惊人，但可见性几乎消失了。
Any effort that spans multiple teams, such as a platform migration, a shared infrastructure change, or a reorganization, now requires enormous coordination overhead simply because the information decision-makers need to understand the full picture is distributed across too many places. And this isn’t a problem unique to engineering. It exists in any function that runs on data spread across multiple systems.任何跨团队的努力，例如平台迁移、共享基础设施变更或组织重组，现在都需要巨大的协调开销，仅仅是因为决策者理解全貌所需的信息分布在太多地方。这并非工程领域独有的问题，它存在于任何依赖分布在多个系统中的数据来运行的职能部门中。
Faced with this visibility problem, I wanted to build something I could ask big-picture questions and get synthesized answers back quickly. Things like:面对这种可见性问题，我想构建一个系统，让我可以询问宏观问题并快速获得综合答案。例如：
- What is the status of this cross-team migration effort, and which teams are behind?这项跨团队迁移工作的状态如何，哪些团队进度落后？
- A team seems overloaded. Do they actually need another engineer, or is something else going on?一个团队似乎不堪重负。他们真的需要再招一名工程师，还是发生了其他情况？
- What are the trade-offs of adopting this new infrastructure technology?采用这种新的基础设施技术有哪些权衡？
- Help me produce a scope statement from this product brief.请根据这份产品简报帮我拟定一份范围说明书。
Building something that could answer these well took two foundational steps, and getting it to provide recommendations based on my specific business context took two more. While my specific tools are from engineering, the structure applies equally to a sales team synthesizing CRM data and market research, or a finance team working across an ERP, a planning tool, and external benchmarks.构建一个能够很好地回答这些问题的系统需要两个基础步骤，而要让它基于我的具体业务背景提供建议，则还需要另外两个步骤。虽然我使用的具体工具来自工程领域，但其结构同样适用于综合 CRM 数据和市场研究的销售团队，或跨 ERP、规划工具和外部基准工作的财务团队。
Step 1: Map your information hierarchy第一步：映射您的信息层级
Every organization has a set of systems where important knowledge lives, and those systems form a natural hierarchy that spans from strategic intent at the top to operational detail at the bottom. Before you can build a useful research assistant, you need to make that hierarchy explicit, because it’s the map of how decisions get made, which sources carry the most authority, and how different kinds of questions should be approached.每个组织都有一套存储重要知识的系统，这些系统形成了从顶层的战略意图到底层的操作细节的自然层级。在构建有用的研究助手之前，您需要明确这一层级，因为它是决策制定的地图，决定了哪些来源最权威，以及应如何处理不同类型的问题。
At O’Reilly, our engineering hierarchy looks like this:在 O’Reilly，我们的工程层级如下：
| Layer | System | Purpose |
|---|---|---|
| Roadmap | Productboard | Strategic goals, initiatives, and feature prioritization |
| Execution | Jira | Epics, stories, sprints, and contributor tracking |
| Implementation | GitHub | Source code, PR history, and event instrumentation |
| Service catalog | Cortex | Service ownership, dependencies, on-call, and Slack channels |
| Observability | Datadog | System performance, errors, and incidents |
Your organization will have a different set of tools. A sales organization might place Salesforce at the top, followed by a revenue intelligence platform, marketing automation, and market research. A legal team might start with a contract management system, followed by a regulatory tracker, internal policy documentation, and a research database. The specific systems matter less than the act of mapping them: understanding which layer answers which kind of question, and which sources take precedence when they conflict.您的组织将拥有不同的工具集。销售组织可能会将 Salesforce 置于首位，其次是收入智能平台、营销自动化和市场研究。法律团队可能会从合同管理系统开始，随后是法规追踪器、内部政策文档和研究数据库。具体系统是什么并不重要，重要的是映射它们的过程：理解哪一层回答哪类问题，以及当来源冲突时哪一个优先。
Step 2: Connect your systems via MCP and write a skill that describes how to reason第二步：通过 MCP 连接您的系统并编写描述推理方式的技能
This step has two parts that must work together. First, you need to connect your systems to your AI tools via MCP. Then you have to write a skill file that tells the model what to do with that access. At O’Reilly, we call this complete grounding layer Expert Intelligence.这一步包含两个必须协同工作的环节。首先，您需要通过 MCP 将您的系统连接到 AI 工具。然后，您必须编写一份技能文件，告诉模型如何利用这些访问权限。在 O’Reilly，我们将这一完整的接地（grounding）层称为专家智能。
Configuring MCP is straightforward. Most major tools now offer MCP connectors, and connecting them is typically a matter of routine JSON configuration. For systems without MCP connectors, a bash-capable agent with curl and jq can often reach a REST API directly. MCP just makes it cleaner and more reliable.配置 MCP 非常简单。大多数主流工具现在都提供 MCP 连接器，连接它们通常只是常规的 JSON 配置。对于没有 MCP 连接器的系统，支持 bash 的智能体通过 curl 和 jq 通常可以直接访问 REST API。MCP 只是让这一切变得更简洁、更可靠。
But MCP connections alone aren’t enough, and this is the part most implementations get wrong. MCP gives the agent access to your data, but it doesn’t tell the agent how to use it effectively. Without explicit guidance, the agent retrieves information and organizes it the way the underlying systems organize it, which produces a data dump, not an analysis.但仅有 MCP 连接是不够的，这也是大多数实现方式出错的地方。MCP 让智能体能够访问您的数据，但它并未告诉智能体如何有效地使用这些数据。如果没有明确的指导，智能体只会按照底层系统的组织方式检索和整理信息，产生的是数据转储，而非分析。
The skill file—a CLAUDE.md or SKILLS.md document that provides specific reasoning instructions—transforms retrieval into analysis. Mine defines the reasoning hierarchy (which systems to consult for which types of questions, and how to weigh them), the output format (this is not a coding agent—it produces reports and recommendations, not code), epistemic standards (show your work, name gaps, surface assumptions for human verification), and tone. On that last point, I borrowed one of the most useful instructions from Ted Lasso: “be curious, not judgmental.” Adding it meaningfully improved the quality of the output.技能文件——一份提供具体推理指令的 CLAUDE.md 或 SKILLS.md 文档——将检索转化为分析。我的文件定义了推理层级（针对哪类问题咨询哪些系统，以及如何权衡它们）、输出格式（这不是编码智能体，它生成报告和建议，而非代码）、认识论标准（展示工作过程、指出差距、提出假设以供人工验证）以及语气。关于最后一点，我借用了 Ted Lasso 的一条最有用的指令：“保持好奇，不要评判。”添加这一条显著提高了输出质量。
The skill is a codified version of how a skilled analyst would approach these questions. It encodes your organization’s reasoning process and makes it repeatable.该技能是将熟练分析师处理这些问题的方法进行了编码。它将您组织的推理过程进行了固化，使其可重复。
Step 3: Add the expert layer第三步：添加专家层
With the research assistant connected to our internal systems, I had something genuinely useful: fast, synthesized answers to questions that previously would have taken days to research. But I kept running into the same problem: The reports felt generic, and people didn’t trust them. This challenge points to a fundamental limitation of AI-generated organizational analysis that goes beyond any particular implementation.随着研究助手连接到我们的内部系统，我拥有了一个真正有用的工具：能够快速、综合地回答以前需要几天时间研究的问题。但我一直遇到同样的问题：报告感觉很通用，人们不信任它们。这一挑战指出了 AI 生成的组织分析的一个根本局限，它超越了任何特定的实现。
The generic analysis problem通用分析问题
General-purpose AI assistants tend to produce a recognizable kind of organizational analysis: technically reasonable, balanced, cautious, and ultimately not very useful. This isn’t primarily a failure of knowledge—every major LLM has absorbed an enormous amount of management and organizational thinking. It’s a failure of grounding. When an AI assistant has no specific framework anchoring its response, it tends to produce recommendations broad enough to apply to almost any situation: consider the trade-offs, weigh your options, and ensure alignment across stakeholders. These responses are hard to disagree with and just as hard to act on.通用 AI 助手往往会产生一种可识别的组织分析：技术上合理、平衡、谨慎，但最终用处不大。这主要不是知识的缺失——每个主流大语言模型都吸收了海量的管理和组织思想。这是“接地”的缺失。当 AI 助手没有具体的框架来锚定其响应时，它倾向于给出适用于几乎任何情况的宽泛建议：考虑权衡、权衡选项、确保利益相关者之间的一致性。这些回复很难反驳，但也同样难以付诸行动。
When a report says, “The team appears overloaded. Consider adding headcount,” it’s not wrong. But that recommendation could apply to almost any team in almost any company! It won’t make a director change their mind, and it’s not one a leadership team can debate, refine, and act on.当报告说“团队似乎不堪重负，考虑增加人手”时，它并没有错。但这条建议几乎适用于任何公司的任何团队！它不会让总监改变主意，也不是领导团队可以辩论、细化并付诸行动的建议。
What happened when I added the expert layer当我添加专家层后发生了什么
Calling on the O’Reilly Expert MCP didn’t provide the model with new facts—most of the information was technically available already. However, without the Expert MCP and associated skills, the model couldn’t use that information for anything but the broadest analyses. Incorporating the Expert MCP and associated skills changed the character of the analyses by grounding them in specific frameworks, citing named authors and thresholds, and organizing their conclusions around established bodies of practitioner knowledge rather than general principles.调用 O’Reilly 专家 MCP 并没有为模型提供新的事实——大多数信息在技术上早已可用。然而，如果没有专家 MCP 和相关技能，模型无法将这些信息用于除最宽泛分析之外的任何用途。整合专家 MCP 和相关技能改变了分析的性质，将其建立在具体框架之上，引用了具名的作者和阈值，并将结论围绕既定的从业者知识体系而非一般原则进行组织。
To make this concrete, here’s the kind of output the research assistant produced before adding the Expert MCP:为了具体说明，以下是研究助手在添加专家 MCP 之前生成的输出类型：
The team appears overloaded. The backlog is large and the migration project is consuming significant sprint capacity. Consider adding headcount or reducing scope.团队似乎不堪重负。积压工作很多，迁移项目占用了大量冲刺容量。考虑增加人手或减少范围。
And here’s what it produced after:以下是添加之后产生的结果：
According to Google’s SRE guidance, sustained operational toil above approximately 50% indicates structural inefficiency rather than a staffing shortage. This team’s telemetry suggests approximately 67% operational toil. Hiring another engineer would likely increase total toil unless operational ownership is first reduced. Recommended actions: run a structured toil audit, set an explicit toil-reduction target below 50%, and assign runbook ownership for recurring operational tasks.根据 Google 的 SRE 指导意见，持续的运营琐事超过约 50% 表明是结构性效率低下，而非人员短缺。该团队的遥测数据表明运营琐事占比约为 67%。除非先减少运营所有权，否则再聘请一名工程师可能会增加总琐事。建议采取的行动：进行结构化琐事审计，设定低于 50% 的明确琐事削减目标，并为重复性运营任务分配运行手册所有权。
The second report cites a framework by name, references the specific threshold that framework establishes, applies it to the team’s actual data, reaches a different conclusion than the obvious one, and makes actionable recommendations. It’s the kind of analysis that changes a conversation because the director can see where the conclusions came from, engage with the reasoning, push back on the framework if they disagree, or accept it with confidence that it was reasoned rather than pattern-matched.第二份报告按名称引用了框架，参考了该框架建立的具体阈值，将其应用于团队的实际数据，得出了与显而易见结论不同的结论，并提出了可操作的建议。这种分析能够改变对话，因为总监可以看到结论的来源，参与推理过程，如果不同意可以反驳该框架，或者充满信心地接受它，因为它是经过推理而非模式匹配得出的。
When I shared this version with my engineering director, their reaction was immediate: This is defensible.当我与我的工程总监分享这一版本时，他们的反应非常直接：这是站得住脚的。
Frameworks aren’t facts框架不是事实
The most underappreciated aspect of O’Reilly’s content library is that the value isn’t primarily informational. Most of the facts in an O’Reilly book are available on the internet, and LLMs have already read much of the internet.O’Reilly 内容库最被低估的一点是，其价值主要不在于信息本身。O’Reilly 书籍中的大多数事实在互联网上都能找到，而大语言模型已经阅读了互联网上的大部分内容。
The deeper value of O’Reilly’s catalog is that it’s organized around coherent frameworks—complete mental models built by practitioners who spent years or decades developing them. Google SRE. Team topologies. Accelerate. Domain-driven design. The Manager’s Path. Wardley mapping. Designing Data-Intensive Applications. These are structured ways of thinking about specific classes of problems, developed with enough rigor that they can actually guide decisions.O’Reilly 目录更深层的价值在于，它是围绕连贯的框架组织的——由从业者花费数年或数十年开发的完整心智模型。Google SRE、团队拓扑（Team Topologies）、《加速》（Accelerate）、领域驱动设计、管理者的路径（The Manager’s Path）、沃德利地图（Wardley mapping）、《数据密集型应用系统设计》（Designing Data-Intensive Applications）。这些是思考特定类别的结构化方式，其严谨程度足以指导决策。
Frameworks are distinct from facts in a critical way: They tell you not just what’s true but what’s relevant, what to measure, what threshold matters, and what to do when you exceed it. A model with access to the SRE framework as an organized body of practitioner knowledge is more likely to surface it explicitly, apply it to the specific question at hand, and use it to anchor its recommendations, producing output that human reviewers can actually interrogate.框架与事实在关键方面有所不同：它们不仅告诉您什么是真的，还告诉您什么是相关的、衡量什么、什么阈值重要，以及当超过阈值时该做什么。一个能够访问 SRE 框架作为有组织从业者知识体系的模型，更有可能显式地呈现它，将其应用于当前的具体问题，并用它来锚定其建议，从而产生人类评审员可以实际审视的输出。
This points to the organizing principle behind the approach described in this paper:这指向了本文描述方法背后的组织原则：
Organizational data provides local evidence about what is happening in your specific context. Expert frameworks provide accumulated practitioner knowledge about how to think about problems of that kind. Good organizational judgment requires both.组织数据提供了关于您特定背景下正在发生什么的局部证据。专家框架提供了关于如何思考此类问题的积累的从业者知识。良好的组织判断力需要两者兼备。
The Expert MCP is the bridge between your specific business context and practitioner insights. It connects the AI’s access to your internal systems with a curated body of expertise relevant to the decisions your organization needs to make.专家 MCP 是您的具体业务背景与从业者见解之间的桥梁。它将 AI 对您内部系统的访问权限与与您组织需要做出的决策相关的精选专业知识体系连接起来。
Why use MCP rather than uploading your own documents为什么要使用 MCP 而不是上传您自己的文档
The natural objection at this point is “Couldn’t I get the same effect by dumping relevant PDFs into Claude, or using Claude Projects, or NotebookLM?”此时自然的反对意见是：“难道我不能通过将相关 PDF 扔给 Claude，或者使用 Claude Projects 或 NotebookLM 达到同样的效果吗？”
The short answer is not quite, and the reasons are practical as much as they are technical.简短的回答是：不完全能。原因既有实际层面的，也有技术层面的。
Uploading documents gives you retrieval from those specific documents. The O’Reilly Expert MCP differs in several operationally significant ways. First, the corpus is editorially curated around coherent practitioner frameworks. Unlike a collection of PDFs, which tends to reflect whatever you happened to find, the Expert MCP offers a sustained curatorial perspective: The authors are vetted, the content has been through editorial review, and it’s organized around established bodies of knowledge rather than assembled ad hoc. This is a much more expansive kind of evidence base. Second, the corpus is maintained and updated by O’Reilly. New titles are added, new editions replace old ones, and the content stays current without any management on your part. Third, the Expert MCP is configured once and works consistently across your entire organization and toolchain rather than being tied to a single user’s Claude Project or a document upload that expires. Finally, accessing content through a proper API respects the appropriate usage terms in a way that uploading copyrighted texts doesn’t.上传文档只能让您从这些特定文档中进行检索。O’Reilly 专家 MCP 在几个操作层面上有着显著不同。首先，语料库是围绕连贯的从业者框架进行编辑策划的。与倾向于反映您偶然发现的内容的 PDF 集合不同，专家 MCP 提供了一种持续的策展视角：作者经过审查，内容经过编辑审核，并且它是围绕既定的知识体系组织的，而不是临时拼凑的。这是一种更具扩展性的证据基础。其次，语料库由 O’Reilly 维护和更新。新书目被添加，新版本替换旧版本，内容保持最新，无需您进行任何管理。第三，专家 MCP 配置一次即可在整个组织和工具链中一致地工作，而不是绑定到单个用户的 Claude 项目或会过期的文档上传。最后，通过适当的 API 访问内容尊重了适当的使用条款，而上传受版权保护的文本则不然。
And when paired with a well-written skill, the agent can be directed to look explicitly for competing frameworks, surface cases where the literature disagrees, and name gaps in the available evidence, providing a meaningful check against the common tendency of AI tools to quietly favor whatever framework first seems to fit. That’s something you can encourage with any retrieval setup, but it works more reliably when the underlying corpus is organized around coherent bodies of thought rather than a heterogeneous collection of documents.当与编写良好的技能相结合时，智能体可以被引导去明确寻找相互竞争的框架，呈现文献中存在分歧的案例，并指出现有证据中的差距，从而针对 AI 工具悄悄倾向于任何看起来首先符合的框架的常见倾向提供有意义的检查。这是您可以通过任何检索设置鼓励的事情，但当底层语料库是围绕连贯的思想体系而非异构文档集合组织时，它工作得更可靠。
What we’re not claiming我们未声称的内容
I want to be clear about the limits of what Expert MCP does today. O’Reilly doesn’t claim that Expert MCP automatically selects the single correct framework for every situation, or that adding it to your configuration produces consultant-quality analysis without thoughtful prompting and human review.我想明确专家 MCP 目前的局限性。O’Reilly 并不声称专家 MCP 会自动为每种情况选择唯一正确的框架，或者将其添加到您的配置中就能在没有深思熟虑的提示和人工评审的情况下产生顾问级的分析。
The results described in this paper were the outcome of all four elements—the internal organizational data, the carefully designed skill architecture, the Expert MCP, and human review—in combination working together.
本文描述的结果是所有四个要素——内部组织数据、精心设计的技能架构、专家 MCP 和人工评审——共同作用的结果。
The Expert MCP is an important differentiator, but it’s not a magic layer you can add to an otherwise generic setup and expect to reproduce these results. The system works because each element does something the others cannot. The skill defines the reasoning process, the internal MCP connections provide the organizational evidence, the Expert MCP provides the expert frameworks, and human review supplies the judgment and context that no AI system can generate on its own.专家 MCP 是一个重要的差异化因素，但它不是一个可以添加到其他通用设置中并期望复制这些结果的神奇层。该系统之所以有效，是因为每个要素都做了其他要素无法做到的事情。技能定义了推理过程，内部 MCP 连接提供了组织证据，专家 MCP 提供了专家框架，人工评审提供了任何 AI 系统都无法独自生成的判断力和背景。
What the Expert MCP reliably contributes to that system is access to a curated body of practitioner knowledge: technical and managerial frameworks that are editorially organized around coherent bodies of thought and difficult to reconstruct from scattered web content or assembled document collections. Your organizational data still tells you what’s happening, while the O’Reilly Expert MCP helps interpret what it means. That’s a meaningful and concrete improvement over an ungrounded AI assistant, and it’s something you can put in production and build on today.专家 MCP 可靠地为该系统贡献的是对精选从业者知识体系的访问：围绕连贯思想体系进行编辑组织，且难以从零散的网络内容或拼凑的文档集合中重构的技术和管理框架。您的组织数据仍然告诉您正在发生什么，而 O’Reilly 专家 MCP 帮助解释其含义。这比未接地的 AI 助手有了有意义且具体的改进，这是您可以立即投入生产并在此基础上构建的东西。
A note on hallucinations关于幻觉的说明
No AI system eliminates the risk of hallucination. The Expert MCP doesn’t make the model infallible.没有任何 AI 系统能消除幻觉风险。专家 MCP 并不能使模型变得万无一失。
What it does is change the burden of proof. When every recommendation is grounded in a named framework, a named author, and a traceable citation, a human reviewer can check the reasoning rather than simply accepting or rejecting a conclusion. The question shifts from “Is this right?” (unanswerable in isolation) to “Does this framework actually say this, does it apply here, and do I agree with the conclusion?” That’s a question humans can engage with productively, which is exactly what you want from a decision-support tool.它所做的是改变举证责任。当每一项建议都建立在具名的框架、具名的作者和可追溯的引用之上时，人类评审员可以检查推理过程，而不是仅仅接受或拒绝结论。问题从“这是对的吗？”（孤立地无法回答）转变为“这个框架真的这么说吗？它适用于这里吗？我同意这个结论吗？”这是人类可以有效参与的问题，而这正是您希望从决策支持工具中获得的。
Step 4: Human review is nonnegotiable第四步：人工评审不可商量
Organizational systems rarely contain the full context behind a decision. The meeting that changed everything happened last Tuesday and hasn’t been written up yet. A key person is quietly planning to leave. A strategic direction shifted in a conversation that was never documented. AI can synthesize everything in your systems with remarkable fidelity, but it can’t know what isn’t there, and organizational reality changes faster than documentation does.组织系统很少包含决策背后的全部背景。改变一切的会议发生在上周二，还没有写成文档。关键人物正在悄悄计划离职。战略方向在从未记录的对话中发生了转变。AI 可以以惊人的保真度综合您系统中的一切，但它无法知道不存在的内容，且组织现实的变化速度比文档更新的速度要快。
More fundamentally: AI can identify trade-offs, but it can’t decide which trade-offs matter. That judgment requires human knowledge of context, priorities, and risk tolerance that can’t be fully encoded in any system. The goal isn’t to remove humans from the loop but to give them better-structured input to reason from.更根本的是：AI 可以识别权衡，但它无法决定哪些权衡是重要的。这种判断需要人类对背景、优先级和风险承受能力的了解，这些是无法完全编码在任何系统中的。目标不是将人类从回路中移除，而是为他们提供结构更好的输入以供推理。
Extend the expert layer by solving collaboration通过解决协作问题扩展专家层
As I started sharing analyses more broadly, I ran into a new set of limitations in the collaboration layer. The research assistant produced documents. I shared them in Google Docs, and people added comments, but when the AI updated a document based on reviewer feedback, I had to paste in a new version, which wiped out the existing comments. Documents proliferated without clear relationships between them, and the AI had no visibility into the discussions in the comments, which was where the most important context and pushback lived.当我开始更广泛地分享分析结果时，我在协作层遇到了一系列新的限制。研究助手生成了文档。我在 Google Docs 中分享它们，人们添加了评论，但当 AI 根据评审员的反馈更新文档时，我必须粘贴一个新版本，这会抹去现有的评论。文档激增而没有明确的联系，AI 无法洞察评论中的讨论，而那正是最重要的背景和反驳意见所在。
To solve the collaboration problem, I worked with one of our engineering directors to build what we call Superanswers, a system that uses GitHub as the source of truth for AI-generated research documents and their associated discussions.为了解决协作问题，我与我们的一位工程总监合作构建了我们称之为“超级答案”（Superanswers）的系统，该系统使用 GitHub 作为 AI 生成的研究文档及其相关讨论的单一事实来源。
The architecture is straightforward: Documents are stored as Markdown files in a GitHub repository, a GitHub Pages site renders them with a clean interface that supports inline commenting, and all discussion happens in GitHub Discussions, meaning every comment, question, and revision is versioned and traceable. Because the documents and their discussions live in GitHub, Claude Code has full access to both. It can read the document content plus the entire conversation that’s developed around it.架构很简单：文档以 Markdown 文件形式存储在 GitHub 仓库中，GitHub Pages 站点通过支持内联评论的简洁界面呈现它们，所有讨论都在 GitHub Discussions 中进行，这意味着每一条评论、问题和修订都是版本化且可追溯的。由于文档及其讨论存在于 GitHub 中，Claude Code 对两者都有完全的访问权限。它可以读取文档内容以及围绕它展开的整个对话。
This enables a qualitatively different kind of AI participation. Instead of generating a document and stepping back, we can now ask:这实现了质上不同的 AI 参与方式。我们不再只是生成文档然后退后，现在我们可以问：
What is the consensus around this project based on the discussion so far? What questions remain unresolved? Incorporate the reviewer comments and produce an updated version.根据目前的讨论，围绕这个项目的共识是什么？还有哪些问题未解决？整合评审员的评论并生成更新版本。
The AI becomes a participant in an ongoing conversation rather than a one-shot report generator, which meaningfully shifts how organizational knowledge gets built and refined.AI 成为持续对话的参与者，而不是一次性的报告生成器，这有意义地改变了组织知识构建和细化的方式。
What teams are using Superanswers for团队正在将 Superanswers 用于什么
As Superanswers has spread across our engineering organization, the range of questions people bring to it has been broader than I expected:随着 Superanswers 在我们的工程组织中普及，人们向它提出的问题范围比我预期的要广泛：
| Theme | Typical questions |
|---|---|
| Architecture and infrastructure | Should we make this change? What will it cost? What might break? |
| Operational effectiveness | Where is our toil coming from? What should we automate, simplify, or retire? |
| Team health and capacity | Where is the team’s time going? What’s limiting execution? |
| Organization and strategy | How should we organize, prioritize, and invest? |
| Engineering measurement | How do we know if we’re healthy and improving? |
| AI and organizational learning | How do we build better systems for reasoning and decision-making? |
None of these questions is about writing code. They are about understanding an organization, making decisions, and coordinating work, and most of them would map naturally onto the concerns of leaders in other functions. The same questions arise in any organization navigating rapid change with information scattered across too many places.这些问题都不涉及编写代码。它们关乎理解组织、做出决策和协调工作，其中大多数问题都可以自然地映射到其他职能部门领导者的关注点上。任何在信息分散在太多地方的情况下应对快速变革的组织，都会出现同样的问题。
How to use the recipe如何使用该配方
The AI conversation to date has been dominated by a particular set of questions. But there are more interesting questions we should be asking.迄今为止的 AI 对话一直被一组特定的问题所主导。但我们应该问一些更有趣的问题。
| We’ve spent a lot of time asking… | What else might be possible? |
|---|---|
| How do we make people more productive? | How do we make organizations more effective? |
| How do we produce faster? | How do we make faster decisions? |
| How do we generate output? | How do we generate understanding? |
| How do we accelerate execution? | How do we improve outcomes? |
| How do we gather data? | How do we build institutional knowledge? |
| How do we automate tasks? | How do we improve organizational learning? |
The challenges outlined in this chart aren’t unique to engineering. They exist wherever important information is scattered across multiple systems and important decisions require synthesizing all of it.此图表中概述的挑战并非工程领域所独有。它们存在于任何重要信息分散在多个系统、且重大决策需要综合所有这些信息才能做出的地方。
Individual productivity matters, but organizations don’t succeed by having contributors go faster in arbitrary directions. They do so by making good decisions about where to invest, allocating resources well, surfacing problems before they compound, and building institutional knowledge that persists over time.个体生产力很重要，但组织成功并非靠贡献者在任意方向上加速。成功在于就投资方向做出正确决策、合理分配资源、在问题恶化前发现问题，以及构建随时间推移而持久的制度性知识。
The recipe I’ve described can help organizations make those decisions and build that knowledge.我所描述的配方可以帮助组织做出这些决策并构建这些知识。
The recipe for building an organizational intelligence system:构建组织智能系统的配方：
- Map your information hierarchy. Identify the systems where important knowledge lives in your organization, from strategic intent down to operational detail. This is an organizational task, not a technical one, and doing it well requires understanding how decisions actually get made.映射您的信息层级。识别您组织中重要知识所在的系统，从战略意图到底层操作细节。这是一项组织任务，而非技术任务，做好它需要理解决策实际上是如何做出的。
- Connect those systems via MCP and write a skill that describes how to reason. The MCP connections give the AI access to your data; the skill file tells it how to think with that data. Without the skill, you get retrieval. With it, you get analysis.通过 MCP 连接这些系统并编写描述推理方式的技能。MCP 连接赋予 AI 访问您数据的权限；技能文件告诉它如何利用这些数据进行思考。没有技能，您得到的是检索。有了技能，您得到的是分析。
- Add the O’Reilly Expert MCP as an expert review layer. Organizational data provides local evidence about what is happening in your specific context; expert frameworks provide accumulated practitioner knowledge about how to reason about problems of that kind. This step bridges the two. The O’Reilly library spans engineering, management, data science, security, finance, product, and more, organized not as a collection of facts but as coherent frameworks developed by practitioners who spent careers building them. The result is analysis grounded in named frameworks with traceable citations, something human reviewers can engage with and question, rather than generic advice they can only accept or reject.
添加 O’Reilly 专家 MCP 作为专家评审层。组织数据提供了关于您特定背景下正在发生什么的局部证据；专家框架提供了关于如何思考此类问题的积累的从业者知识。这一步架起了两者的桥梁。O’Reilly 内容库涵盖工程、管理、数据科学、安全、金融、产品等领域，其组织方式不是事实集合，而是由花费职业生涯构建它们的从业者所开发的连贯框架。结果是建立在具名框架之上且带有可追溯引用的分析，这是人类评审员可以参与和质疑的对象，而不是他们只能接受或拒绝的通用建议。- Build a lightweight system for human-in-the-loop consensus. AI-generated analysis is a starting point, not an end point. You need a mechanism for people to review, challenge, and refine what the AI surfaces, one where those discussions become part of the context the AI can learn from in subsequent iterations.构建一个轻量级的“人在回路”共识系统。AI 生成的分析是一个起点，而非终点。您需要一种机制让人们评审、挑战和细化 AI 呈现的内容，让这些讨论成为 AI 在后续迭代中可以学习的背景的一部分。
The biggest practical lesson I took from this work is reframing what AI is actually for in an organizational context. The difference between a useful AI research assistant and a generic one isn’t primarily about which model you use or how much data you feed it. It’s about whether the reasoning combines local organizational evidence with established expert frameworks. Your data tells you what happened. Expert frameworks help interpret what it means. That combination, with human judgment applied at the end, is what makes the difference between a report that gets read (maybe) and filed away and a recommendation that changes a decision.我从这项工作中汲取的最大实际经验是重新定义了 AI 在组织背景下的真正用途。一个有用的 AI 研究助手与一个通用的 AI 助手之间的区别，主要不在于您使用什么模型或喂给它多少数据。而在于推理过程是否结合了局部组织证据与既定的专家框架。您的数据告诉您发生了什么。专家框架帮助解释其含义。这种结合，加上最后应用的人类判断，就是一份被阅读（可能）并归档的报告与一份改变决策的建议之间的区别。
