企业官网建设流程全解析

1. 把一本教材拆成智能体：我为什么动了这个念头

油藏工程这门课，教了这么多年，我最大的感受是：教材本身没问题，问题在于教材是"死"的。学生翻到"物质平衡方程"那一章，看到一堆推导，合上书就忘了；工程师遇到一个具体的边水油藏，想快速判断驱动类型，翻目录、翻索引，半小时过去了还没找到对应的判别标准。我自己编的那本新版教材，前后改了四稿，内容算是比较扎实了，但纸质书和PDF的交互能力就摆在那里——读者只能"读"，不能"问"。

真正让我下决心动手的，是去年带的一个项目。团队里有个刚毕业的硕士，理论基础不差，但每次做动态分析都要来问我："老师，这个油藏用哪种方法算地质储量比较合适？"我回答完，过两天他又来问类似的问题。不是他不用功，是教材里的知识是线性排列的，而实际工作中的问题是跳跃的、场景化的。你不可能要求一个工程师把整本书背下来再去现场。

所以我想做的事情很明确：把这本教材变成一个能对话、能推理、能根据具体油藏条件给出分析路径的智能体。不是简单的"电子书+搜索框"，而是把教材里的知识体系拆解成结构化的技能模块，让AI能够理解"什么是欠饱和油藏""什么条件下用弹性驱""物质平衡方程在什么假设下成立"这些概念之间的逻辑关系，然后针对用户的具体问题，组合调用这些知识。

关键词里提到的"book to skill"这个概念，恰好说中了我的思路。一本教材本质上就是一套领域知识的集合，而skill（技能）是把知识转化为可执行动作的中间层。我要做的，就是把教材的章节结构映射成技能树，把每个知识点封装成可被智能体调用的skill，再通过一个调度层来根据用户输入匹配最合适的技能组合。

这个项目适合谁参考？如果你手里有某个垂直领域的知识体系——不管是工程手册、操作规程、还是培训教材——想把它变成智能体，那这套思路可以直接复用。如果你只是想了解智能体开发的基本流程，这里面的架构设计、skill拆分、调试方法也有参考价值。我不打算讲太多抽象概念，重点放在"我具体怎么做的""踩了哪些坑""哪些地方和预想的不一样"。

2. 教材知识的结构化拆解：从章节目录到技能树

2.1 为什么不能直接把PDF丢给大模型

最开始我试过最省事的办法：把教材PDF转成文本，切块，做向量检索，套一个对话界面。跑起来倒是快，但效果很差。问"边水油藏的驱动指数怎么算"，它能把相关段落找出来，但回答是碎片化的，东一句西一句，没有逻辑串联。更麻烦的是，教材里有大量公式、图表、参数表，纯文本检索根本处理不了这些结构化信息。

问题的根源在于：教材的知识组织方式是"叙述型"的，而智能体需要的是"可调用型"的。叙述型知识适合人阅读，但不适合机器推理。你必须做一次转换，把"第3章第2节讲了什么"变成"当用户问X类问题时，调用Y技能，输入Z参数，输出W结果"。

这个转换过程，我称之为"知识的结构化拆解"。具体分三步：第一步是识别教材中的核心概念和它们之间的关系；第二步是把每个概念封装成独立的skill；第三步是定义skill之间的调用规则和参数传递方式。

2.2 技能粒度的选择：太粗和太细都是坑

拆skill的时候，粒度是最难把握的。我一开始拆得太细，把"孔隙度定义""渗透率定义""饱和度定义"都做成独立skill，结果调度层要处理几百个skill，匹配精度反而下降。后来拆得太粗，把"油藏描述"整个做成一 个skill，内部逻辑太复杂，调试的时候根本定位不到问题出在哪。

最后我采用的粒度标准是：一个skill对应一个"可独立完成的分析动作"。比如"判断油藏驱动类型"是一个skill，"计算弹性产率"是一个skill，"物质平衡方程求解"是一个skill。每个skill有明确的输入参数、输出结果和适用条件。这样拆下来，整本教材大概对应40-50个核心skill，调度层处理起来比较舒服。

这里有个经验：skill的划分要参考教材的"节"而不是"章"。章太大，节刚好。如果某一节内容特别多，再按"知识点"细分。比如"物质平衡方程"这一节，我拆成了"通用物质平衡方程""未饱和油藏物质平衡""气顶油藏物质平衡""水驱油藏物质平衡"四个skill，每个对应不同的油藏类型和假设条件。

2.3 用表格管理skill的元信息

拆完skill之后，我用一张表来管理所有skill的元信息。这张表是整个项目的核心资产，调度层的匹配逻辑、调试时的排查依据、后续扩展的参考，都靠它。

这张表看起来简单，但实际整理的时候花了我将近两周。最难的是"适用条件"这一列——很多教材里默认读者知道某个公式的适用前提，但机器不知道。你必须把隐含条件显式化。比如物质平衡方程，教材里可能只写"在忽略岩石和流体压缩性的条件下"，但实际使用中还要考虑"油藏是否封闭""是否有气顶""是否注水"等条件。这些都要在元信息里写清楚。

提示：skill元信息表建议用结构化格式存储（比如JSON或YAML），方便程序读取。我一开始用Excel，后来发现字段一多就乱，转成YAML之后清爽很多。

3. 智能体调度层的设计：让AI知道"什么时候该用哪个skill"

3.1 调度层的核心逻辑：意图识别加技能匹配

调度层是整个智能体的"大脑"。用户输入一个问题，调度层要做两件事：第一，理解用户到底想问什么（意图识别）；第二，从skill库里找到最合适的skill组合来回答这个问题（技能匹配）。

意图识别这块，我用的是"关键词+语义"的混合策略。纯语义匹配有时候会把"我想算地质储量"和"我想算可采储量"搞混，因为这两个问题的语义相似度很高，但对应的skill完全不同。加上关键词规则之后，准确率明显提升。比如检测到"地质储量""原始储量""OOIP"这些词，优先匹配RE-003；检测到"可采""采收率""最终采出"这些词，优先匹配RE-005。

技能匹配的难点在于"多跳调用"。用户问"这个油藏用物质平衡法算储量靠谱吗"，这个问题需要先调用RE-001判断驱动类型，再根据驱动类型决定是否适合用RE-003。这种依赖关系在skill元信息表的"依赖skill"列里已经定义了，调度层按照依赖图依次调用就行。

3.2 参数补全：用户没说全的时候怎么办

实际使用中，用户很少会把所有参数都一次性说清楚。比如问"帮我算一下弹性产率"，但没给综合压缩系数、孔隙度这些参数。这时候调度层不能直接报错，而是要根据skill的输入参数列表，逐项询问用户，或者根据已有信息做合理推断。

我的做法是：调度层维护一个"参数槽位"机制。每个skill的输入参数对应一个槽位，用户输入时能填多少填多少，剩下的槽位由调度层主动追问。追问的顺序按照参数的重要性排序——对结果影响大的参数先问，影响小的可以给默认值。

这里有个细节：有些参数之间是有关联的。比如你知道了地层压力和饱和压力，就能判断油藏是否饱和，进而决定用哪个物质平衡方程变体。这种关联规则我也写进了调度层，让它能做一些简单的逻辑推理，减少追问次数。

3.3 多轮对话的状态管理

油藏工程的问题往往不是一问一答能解决的。用户可能先问"这个油藏是什么驱动类型"，得到答案后再问"那用哪种方法算储量"，接着问"需要哪些数据"。这是一个连续的分析流程，调度层需要记住上下文。

我用了一个简单的会话状态机来管理多轮对话。每个会话有一个状态变量，记录当前进行到哪一步、已经收集了哪些参数、上一步的输出是什么。当用户输入新问题时，调度层先看会话状态，判断这是新问题还是上一步的延续。如果是延续，就把上一步的输出作为当前skill的输入之一。

这个机制听起来简单，但实际调试的时候发现了很多边界情况。比如用户中途换了话题，状态机要能识别并重置；用户同时问两个不相关的问题，状态机要能拆分处理。这些都是在实际使用中慢慢打磨出来的。

4. 知识注入的实操：把教材内容变成skill能理解的格式

4.1 公式的处理：不能只存LaTeX

教材里有大量公式，最开始我直接把LaTeX表达式存进skill，结果发现AI根本"理解"不了这些公式的物理含义。它能把公式原样输出，但你问它"这个公式里哪个参数对结果影响最大"，它就答不上来了。

后来我改了一种方式：每个公式除了LaTeX表达式之外，还要附带三样东西——物理含义说明、参数敏感性描述、典型取值范围。比如物质平衡方程，除了公式本身，还要写清楚"这个方程的本质是物质守恒，累积产出量等于地下亏空量""地层压力对结果影响最大，压缩系数次之""原始地质储量的典型范围是XX到XX"。

这样处理之后，AI在回答问题时不仅能给出公式，还能解释公式的物理意义，甚至能根据用户提供的参数做敏感性分析。这才是智能体该有的样子，而不是一个公式查询器。

4.2 图表的处理：用描述性文本替代

教材里的图表，比如相态图、驱动指数三角图、水侵曲线，直接转成图片存进去，AI是没法处理的。我的做法是给每个图表写一段"描述性文本"，把图表里的关键信息用文字表达出来。

以驱动指数三角图为例，我写的描述是："三角图的三个顶点分别代表水驱、气驱、弹性驱。某个油藏的驱动类型对应三角图中的一个点，点的位置由各驱动指数的相对大小决定。水驱指数大于0.5时，点靠近水驱顶点；气驱指数大于0.5时，点靠近气驱顶点；弹性驱指数大于0.5时，点靠近弹性驱顶点。如果三个指数都在0.3到0.5之间，属于混合驱动。"

这段描述存进skill之后，用户问"我的油藏水驱指数0.6，气驱指数0.2，弹性驱指数0.2，是什么驱动类型"，AI就能根据描述做出判断。虽然不如直接看图直观，但至少能处理了。

4.3 案例的注入：让AI学会"举一反三"

教材里有很多例题和案例，这些是宝贵的教学资源。我把每个案例都拆解成"问题描述+分析过程+结论"三段式，存进对应的skill作为参考示例。

这样做的好处是，当用户提出类似问题时，AI可以参考案例的分析路径来组织回答。比如用户问"一个欠饱和油藏，原始压力高于饱和压力，生产一段时间后压力降到饱和压力以下，怎么分析"，AI可以调用教材里对应的案例，按照"先判断阶段→再选方法→再算参数"的路径来回答。

但要注意，案例不能直接照搬。教材里的案例往往有特定的数据条件，直接套用到用户的问题上可能会出错。所以我在每个案例后面都加了一句"本案例的适用条件是XX，如果你的情况不同，需要调整XX"。这样AI在引用案例时会更谨慎。

5. 调试过程中暴露的问题和解决思路

5.1 幻觉问题：AI会"编造"不存在的公式

调试初期最头疼的问题是幻觉。用户问一个教材里没有明确讲到的场景，AI会自己"编"一个公式出来，而且看起来还挺像那么回事。有一次它给了一个"修正物质平衡方程"，我查了半天，教材里根本没有这个东西。

解决这个问题的办法是加"知识边界"约束。在每个skill的元信息里，我增加了一个"知识范围"字段，明确写清楚这个skill覆盖了哪些内容、不覆盖哪些内容。当用户的问题超出知识范围时，调度层会返回"这个问题超出了当前知识库的范围，建议参考XX资料"，而不是让AI自由发挥。

另外，我在调度层加了一个"置信度检查"环节。AI生成的回答会经过一次自检，如果回答中引用了不存在的公式或参数，置信度会被标记为低，然后触发人工审核流程。虽然增加了工作量，但保证了输出的可靠性。

5.2 参数单位混乱：一个容易被忽视的坑

油藏工程里单位特别多，地层压力可以用MPa也可以用psi，渗透率可以用mD也可以用μm²，产量可以用m³/d也可以用bbl/d。用户输入的时候往往不带单位，AI就默认按教材里的单位处理，结果算出来的数字差了好几个数量级。

我后来在调度层加了一个"单位归一化"模块。用户输入参数时，调度层会先检测有没有单位标识，如果没有，就根据参数类型和数值范围做合理推断。比如地层压力输入"30"，大概率是MPa；输入"3000"，大概率是psi。推断完之后统一转换成教材使用的标准单位，再传给skill计算。

这个模块看起来简单，但实际写规则的时候要考虑很多情况。比如有些参数的范围有重叠，压力"100"既可能是MPa也可能是psi（虽然100MPa不太常见），这时候就要结合其他参数来判断。我的做法是维护一个"参数-单位-典型范围"的对照表，用范围匹配来做推断。

5.3 多skill冲突：两个skill都匹配怎么办

有时候用户的问题会同时匹配多个skill。比如"帮我分析一下这个油藏的开发效果"，这个问题既涉及驱动类型判断，又涉及采收率预测，还涉及经济评价。调度层如果只选一个skill，回答就不完整；如果全选，又可能超出用户的实际需求。

我的解决方案是引入"优先级+组合"机制。每个skill有一个优先级分数，根据匹配度和用户历史行为动态调整。调度层先选优先级最高的skill，然后检查它的输出是否满足用户需求。如果不满足，再调用次优先级的skill，把结果组合起来。

组合的时候要注意逻辑顺序。比如先判断驱动类型，再根据驱动类型选择采收率预测方法，最后做经济评价。这个顺序不能乱，否则结果没有意义。我在调度层里定义了一套"skill执行顺序规则"，确保组合调用时逻辑正确。

6. 实际使用效果和几个典型场景

6.1 场景一：学生自学时的即时答疑

我让几个学生试用了这个智能体。有个学生反馈说，以前看书遇到不懂的概念，要么等下次上课问老师，要么自己上网搜，搜出来的结果质量参差不齐。现在直接问智能体，"欠饱和油藏和饱和油藏的区别是什么"，它能给出定义、判别标准、开发特征差异，还附带了教材里对应的章节页码。学生说这个体验比翻书好很多。

但也有学生反映，智能体有时候回答得太"官方"，像在背教材。我后来调整了回答风格，让它多用口语化的解释，多举例子。比如解释"弹性驱"的时候，不说"依靠岩石和流体弹性膨胀能量驱动"，而是说"就像你捏一个装满水的海绵，松手之后水被吸回去的那种力量"。这样学生更容易理解。

6.2 场景二：工程师做动态分析时的辅助工具

有个在油田工作的朋友试用之后说，他最喜欢的功能是"参数敏感性分析"。以前做动态分析，要手动改参数、重新计算、对比结果，很费时间。现在直接问智能体"如果渗透率降低20%，采收率会怎么变"，它能快速给出结果和解释。

不过他提了一个改进建议：希望能批量处理。比如一次性输入多个方案的参数，让智能体自动对比。这个功能我后来加上了，用表格形式输出对比结果，确实方便很多。

6.3 场景三：培训新员工时的标准化教材

有个做培训的朋友对这个思路很感兴趣。他说他们公司新员工培训，讲师水平参差不齐，讲出来的内容不一致。如果把培训教材做成智能体，新员工随时可以问，回答都是标准化的，能保证培训质量。

这个场景让我意识到，这套方法不仅适用于油藏工程教材，任何有标准化知识体系的领域都可以用。关键是把知识拆解成skill，把skill组织成可调用的结构，然后通过调度层来匹配用户需求。

7. 如果你也想做类似的项目，我的几条实操建议

第一，先想清楚"知识边界"在哪里。不要试图把整个领域的知识都塞进去，选一个相对封闭、结构清晰的知识体系作为起点。油藏工程教材就是一个很好的起点，因为它的知识框架比较成熟，概念之间的逻辑关系比较明确。

第二，skill的粒度比数量重要。宁可少做几个skill，也要保证每个skill的输入输出定义清楚、适用条件明确。我见过有人把skill拆得特别细，结果调度层根本管不过来。也见过有人把skill做得特别粗，内部逻辑复杂到没法调试。

第三，调试时间要留够。我整个项目大概花了三周做开发，但调试花了将近一个月。调试的重点不是修bug，而是打磨回答质量。AI的回答从"能用"到"好用"，中间有大量的细节要调。

第四，单位处理和参数补全是容易被忽视但极其重要的环节。这两个环节做不好，用户体验会大打折扣。用户不会按照你预设的格式输入参数，你必须能处理各种"不规范"的输入。

第五，多找真实用户试用。我自己测试的时候觉得挺好的，但学生和工程师一用，马上就发现了各种问题。真实用户的使用场景和你想象的完全不一样，他们的反馈是最有价值的改进依据。

最后说一个我自己的体会：把教材搬到AI上，最难的不是技术，而是"知识的结构化"。你需要把那些人类读者默认理解、但机器完全不理解的隐含信息显式化。这个过程很痛苦，但做完之后，你会发现自己对这本教材的理解也加深了一层。有些概念之间的逻辑关系，我以前讲课的时候从来没想过要讲清楚，但在拆解skill的过程中被迫想清楚了。这算是意外收获。