企业官网建设流程全解析

做了这么多年模型训练和知识工程，有个事越来越扎心：我们一直在给大模型喂教科书，但真正的专业工作里，教科书知识可能只占三成，剩下七成是说不清道不明的经验。前阵子和几个同行聊AGI的瓶颈，大家不约而同提到一个词——attas。这不是一个模型架构，也不是某个标注工具，而是一整套面向"人类专业经验"的采集与注入框架。这篇就聊聊为什么AGI缺的恰恰是教科书之外的东西，以及attas到底在解决什么问题、具体怎么落地。

1. 教科书知识喂不出AGI：问题出在哪里

1.1 从考试满分到上手干活，Gap到底在哪

先讲个我真实见过的场景。某团队做内部能力评测，模型在专业考试的客观题上表现相当能打，医学知识、法律条文、工程规范这些，正确率已经逼近甚至超过一般从业者。但把同样这批回答拿给一线干了十几年的老师傅看，反馈却很统一：这回答"对但不干活"。

为什么会出现这种现象？关键在于两类任务的信息结构完全不同。

考试题是完备的：题干给了你全部信息，条件无冗余、无缺失，答案一定藏在某一章里。真实任务是残缺的：现场信息大量丢失，噪音多，时间窗口紧张，你必须在信息不完整的情况下做判断，而且要承担判断错误的后果。

教科书知识的本质，是把已完成的工作结果写成文字。但真正干活的时候，绝大多数判断依据不在书里，在现场。老工程师听设备声音判断故障，机床刚有点异响，他不用等检测报告就能说出"主轴轴承保持架磨损"，你问他依据，他给你的解释永远是事后加工过的版本，真实的判别过程是一个长年训练出来的模式匹配动作。你把教科书里的故障诊断章节背得滚瓜烂熟，也练不出那个耳朵。

这就是AGI面临的核心矛盾：当前用于训练模型的文本语料，绝大部分是显性知识的沉淀，隐性知识几乎不会被记录下来。我们喂给模型的，本质上是一个体量巨大但严重偏科的教科书集合。模型再大，也只是把这个偏科集合学得更透而已。

1.2 教材里永远写不出来的那部分，恰是专家水平的分水岭

把知识粗暴分成两类，能帮我们看清问题。

显性知识：能写进文档、能画成流程图、能在课堂上讲清楚的。比如"四冲程发动机的工作顺序是进气、压缩、做功、排气"，比如"TCP三次握手"，比如"这个函数的返回值必须判空"。这类知识结构化程度高，语料里到处都是，模型学起来没难度。

隐性知识：操作性、情境性、身体化的。比如老交易员在行情突变前的仓位调整节奏，老护士一进病房扫一眼患者状态就知道要不要立刻叫医生，老村医把脉时对"这脉有点浮"的体感判别，资深策划看完用户反馈能直接定位核心问题而不是停在表象。

这些经验不是"专家不想写下来"，而是他的决策过程本身就不是语言推理式的。它是一套信号匹配加快速决策链：眼前的信息组合击中了他记忆里的某个模式，决策就出来了。你追问"当时你是怎么判断的"，他给你的回答往往是事后合理化的版本，不是真实的决策路径。

教科书和普通网络文本里几乎不存在这类知识。于是，不管模型参数多大、训练数据多全、算力多充裕，它学到的都只是知识的"书面形态"。这带来的直接后果是：模型可以在知识问答上碾压人类，但在需要真实判断力的专业场景里，距离哪怕一个普通熟手都还有明显差距。

所以AGI要真正逼近人类水平的智能，必须有一个稳定、可靠的通道，把人类专业经验从人脑搬运到模型。attas就是朝这个方向努力的框架思路之一。

2. attas 是什么：把老师傅脑子里的经验搬出来

2.1 一句话定义

attas是一个面向"人类专业经验"的知识采集与注入框架。不同材料里对它的具体表述略有差异，但核心思路高度一致：通过系统的任务拆解、专家访谈、现场跟学、经验编码和效果验证，把难以言传的专业经验转化为可供模型训练和对齐使用的结构化工件。

用大白话说：attas不是又一个模型架构，也不是数据标注工具，它是一套"怎么从专家脑子里把经验挖出来，再安全地灌进模型"的操作方法论。它假设的前提很直接——隐性知识既然在公开数据里不存在，那就别指望模型自己悟出来，直接从人身上拿。

2.2 为什么是"采集"而不是"学习"

市面上很多方案想让模型自己从数据里"悟"出经验，这条路有明确的边界。处理显性知识没问题，因为数据是现成的；但隐性知识在数据里根本不存在，模型没有可学的东西。

attas的思路反过来了，把专家的经验当成一种矿藏。这个比喻值得多展开几句：

教科书是地表矿，露天的，谁都能捡。网络语料也是类似，量大、易得、但含金量有限。专业经验是深层矿，埋在专家脑子里，你得先通过任务分析知道矿脉大致在哪，再选择开采工具——访谈、跟学、复盘、对比——然后做选矿，把偏差和噪音滤掉，最后才能冶炼，也就是结构化编码和注入。

这个定位很重要。它决定了attas的工作方式不是"喂数据"，而是"对话+观察+验证"三方结合。访谈负责获取专家能说出来的部分，观察负责获取专家说不出来但实际在做的部分，验证负责确认我们采集到的经验是真的管用还是只是专家的自我感觉。

2.3 四个核心模块

根据我接触到的实践，attas通常由四个模块组成，缺一环效果都会打折。

任务场景拆解（Task Decomposition）：先搞清楚在这个专业领域里，哪些任务最依赖隐性经验，按发生频次、出错代价、经验依赖度三个维度排序。比如外科手术里"判断术中出血是否危险"就比"如何缝合"更依赖经验，前者优先级必须更高。

经验采集（Elicitation）：重头戏，常见手段有影子跟学（旁观专家做真实任务）、回溯式访谈（做完后追问决策过程）、关键事件访谈（专门聊出过问题的案例）、对比练习（让专家点评新手方案和专家方案的差异）。

经验编码（Representation）：把采集到的经验写成模型能消费的形式。不是简单记一句"专家说这样做"，而是做成结构化的决策单元，包含触发条件、候选方案、选择理由、例外情况和失败记忆。

验证闭环（Validation）：把编码后的经验做成模拟场景测试集，让模型实际执行，由专家打分并修正。这一步最容易被忽略，但恰恰是attas能沉淀出真正价值的地方。

这四块听着朴素，每块展开都有大量细节，下面重点讲实操。

3. attas 实操流程：从访谈老师傅到行为改变

3.1 第一步：任务场景拆解与专家画像

不要一上来就找专家聊天，那是浪费双方时间。先自己做场景清单：

1. 列出该领域的核心任务清单，控制在15到30个。
2. 标注每个任务的三个维度：出错代价（出事后果多严重）、经验依赖度（教科书能不能Cover）、发生频次（多久遇到一次）。
3. 选出5个"经验依赖度最高"的任务，作为第一批采集对象。

我见过一个很典型的失败案例。某团队想构建电力调度专家的经验库，花了大价钱请专家做了几十轮访谈，结果产出的内容跟教科书几乎一样。原因就是第一步没做好：访谈问题太宽泛，比如"讲一下你处理故障的思路"，专家听到这种问题，会自动切回教科书语言模式。只有把任务拆到"某个具体电站、某种天气、某条负荷曲线、某个时间点"这种粒度，专家才会开始讲真实场景里的判断。

专家画像同样要做。同一个领域里的两个专家，擅长的工况可能完全不同，表达习惯也差很多。有人擅长讲，讲得头头是道；有人擅长做，但说不出来。遇到后一种，就得多安排跟学，从他的动作顺序和犹豫节点里反向提取经验。做画像时还要弄清专家的经验适用范围，比如长期在北方设备上积累的老师傅，换到南方高湿环境，他的一些经验可能需要修正——这直接影响后续经验卡片的情境标签怎么写。

3.2 第二步：情境化采集，不是问答，是跟学

这是attas最核心的一步，也是最容易做走样的一步。我强烈建议按优先级使用以下几种手段。

跟学式观察：跟着专家一起处理真实或高仿真任务。你主要记录的不是他讲了什么，而是他做了什么：先做哪个、后做哪个、在哪一步停顿了、问了什么额外信息、跳过了手册里的哪一步。动作顺序本身就是经验。

回溯式访谈：任务刚结束，趁热问"刚才你在第三步停了两秒，那两秒你在判断什么？"注意要一直追问到决策依据层，不能停在"我在想怎么处理"这种表层回答。

关键事件访谈：专门聊那些出过问题的事故、险情和失败案例。问"当时哪个信号先让你觉得不对劲""如果重来一次，第一件事你会做什么"。这类问题最能逼出隐性判断，因为失败记忆通常带着强烈的情境细节。

对比法：准备一份新手方案和一份专家方案，让专家逐条点评差异。专家会说出大量"这里新手都会这么做，但其实……"的话，这些话天然就是结构化的训练信号。

采集过程中，录音、录像、操作日志都要留，最重要的是记录专家做判断那一刻的"现场信息"：眼前有哪些数据、听到了什么声音、闻到了什么气味、感受到了什么异常。判断所依赖的输入信号，和判断结论本身一样重要。

注意：访谈中最容易犯的错是把专家的话当金科玉律。专家也会事后合理化自己的决策，把当时的犹豫说成笃定。解决办法是交叉验证：同一场景问多个专家，同一事件让专家隔一段时间复述第二次，把稳定出现的判断路径才标记为可信经验。

3.3 第三步：结构化编码

采集到的原始材料是访谈稿、录像、操作日志，必须转成可用于训练的结构。我建议用"决策情境卡"作为基本单元，每个卡片包含六个字段：

场景描述：什么任务、什么环境、什么输入信号，越具体越好。 关键信号：专家主要依赖哪些信息做判断，这些信息的优先级排序是什么。 决策选项：当时考虑了哪几条路，最终选了哪一条。 选择理由：为什么这么选，排除了什么风险。 例外规则：什么情况下这条经验不成立。 失败记忆：同类场景下出过的教训，用一句话钉住。

举个例子，设备维修领域的卡片长这样：

场景：某产线主轴出现异响，但产线不能停。 关键信号：声音频率变化、振动值斜率、温度上升速率、上一个保养周期。 决策选项：a. 立即停机检查；b. 降速继续生产并观察；c. 维持现状观察15分钟再判断。 选择理由：温度上升速率正常但振动值斜率偏高，大概率是润滑问题而非轴承本体故障，停机损失远大于当前风险，选b并通知保养班组待命。 例外规则：如果异响伴随高次谐波成分，必须立即停机，不能犹豫。 失败记忆：上次因为贪生产时间延误了20分钟，结果轴承烧毁，教训是"斜率异常就要相信仪表，不要信'再撑一会'"。

这种卡片的好处是既保留了经验的情境性，又拆出了模型可学习的结构化逻辑。几百上千张卡片积累起来，就能形成某个领域的"经验语料库"。

编码时还要做一个关键动作：把专家口语里的模糊词量化。专家说"转速有点高"，得追问"大概比平时高多少？高了之后你第一反应查什么？"把模糊判断转成可验证的规则，模型才能用。这个动作做得好不好，直接决定后面注入的质量。

3.4 第四步：注入与验证闭环

编码完成后的注入方式，取决于技术栈，常见三种：

微调：把经验卡片转成指令数据，用LoRA或全参微调，让模型在相关任务上直接具备经验倾向。适合高频命中的稳定经验。

检索增强：把卡片向量化，推理时检索与当前场景匹配的经验注入上下文。适合覆盖面广、单条命中率不高的场景，改动小、见效快。

工作流约束：把经验编码成规则引擎或决策树，在关键节点约束模型输出。适合安全敏感场景，比如医疗、电力、检修，不允许模型自由发挥的部分就用硬规则兜底。

我个人更推荐"先RAG后微调"的顺序。先用检索把经验卡送进上下文，观察模型行为变化；行为稳定了，再把高频命中的卡片做成微调数据，减少推理时的检索开销。一上来就微调，很容易把模型训成"复读机"，只知道背诵经验文本。

验证环节建议设计三件套：

模拟场景测试集：把真实任务脱敏后做成标准化测试场景，模型跑一遍，专家打分。

对照组：同一场景分别测试注入前模型、注入后模型和专家本人的表现，三份结果放在一起对比，才能看出注入到底带了多少提升。

行为追踪：不只盯最终答案，还要看模型的决策顺序像不像专家。专家先看哪个指标、先排除哪个选项，模型有没有复现这个顺序。过程对了，结果才可靠。

只有闭环跑通了，经验才算真正进到模型里。

4. 避坑实录：做经验采集最容易翻车的五个地方

4.1 专家说的和做的不一样

这是踩过最多坑的地方。专家嘴上说"我都是按流程来的"，实际干活时明显跳过了好几个步骤。不是专家有意撒谎，而是他的流程知识已经自动化了，说出来的是"教科书版本"，做出来的才是"经验版本"。

对策：以观察为准，以访谈为辅。访谈的价值是解释观察结果，不是替代观察。能跟现场就跟现场，跟不了现场就用仿真环境或高保真案例复盘。只要条件允许，永远不要只靠口述建经验库。

4.2 经验是情境绑定的，过度泛化会出大事

专家在某条产线上形成的判断规则，换一条产线、换一批设备、换一个季节，可能就不成立。如果直接把卡片灌给模型而不做情境标签，模型会把"这条产线的经验"当成"所有产线的通用规律"，在错误场景里给出危险建议。

对策：每张决策情境卡必须带强情境标签，包括设备型号、工况范围、地域环境、季节时间窗口。注入时模型必须能判断当前场景是否落在经验适用域里。这一步懒不得，出事的概率和代价都太高。

4.3 反例比正例更值钱

采集正例当然重要，但反例在训练里的价值更高。原因有两个：正例容易被教科书覆盖，反例几乎不会被记录；反例天然携带风险边界，模型知道"对的做法"不如知道"哪个忽略会导致灾难"来得有威慑力。

对策：反例卡片单独打标，给更高优先级。微调时加权，检索时提升命中权重，让失败记忆在关键时刻真正起约束作用。

4.4 模型学会了"说法"，没学会"判断"

这是最隐蔽的失败模式。模型背熟了经验卡片的措辞，回答问题时引经据典，说得头头是道，但换个场景就不会做判断了。因为它只学会了复述文本，没学会"匹配情境—提取信号—决定行动"的完整链路。

对策：验证时不要只看文案，要看推理路径。专门设计"新情境迁移测试"：给模型一个没见过的、但结构相似的新场景，看它能不能正确迁移经验。能迁过去，才算真学会了。

4.5 验证指标选错了，白干一场

很多人拿"回答准确率"当验证指标，在经验注入场景里这是误导性的。经验的价值不在最终答案正确，而在信息不全、时间紧迫、代价高昂的情况下做出了合理取舍。准确率衡量的是"知不知道"，不衡量"敢不敢断""会不会躲"。

对策：建立专家评审维度表，包括关键信号识别率、决策时耗、风险规避比例、例外处理合理性、解释可信度。让专家按维度逐项打分，比一个准确率数字靠谱得多。

5. 我的实操心得与后续扩展方向

最后聊点个人体会。做知识工程这些年，最大的感受是：技术方案永远比想象中简单，难的是把人的因素处理好。

采集经验本质上是和专家建立信任关系。你要让专家觉得"我不是在把你的手艺山寨走，而是在建一个你退休后还能延续你判断力的系统"。很多专家一开始拒绝，就是怕被替代。我后来学乖了，先挑一两个小而准的场景做起来，让专家看到系统确实能帮他把重复性工作减掉，他才愿意把真东西交出来。这个顺序反了，后面会很难推进。

另一个心得是节奏。经验采集不是一锤子买卖，是螺旋式的。第一批卡片注入后，一定要让专家看到模型输出，请他点评。他看到模型回答后，往往会主动说出"原来我当时忘说了一个重要判断"。第二轮采集的质量会肉眼可见地提升。所以整个项目里，访谈、编码、验证、再访谈的循环至少走三轮，效果才会稳定。我见过只做一轮就交付的项目，回来返工的成本比重新做还高。

关于attas后续的扩展方向，我看好三条。

一条是经验冲突仲裁。多个专家对同一场景给出相反建议时，框架需要能判断谁的适用域更匹配当前情况，甚至可以把冲突本身变成训练信号——冲突点往往就是领域里最微妙的判断点。

一条是经验衰减管理。经验随技术进步会过时，需要考虑定期让专家复核存量卡片，打上"已过时""需更新"的标签，避免模型持续输出旧时代的做法。

还有一条是跨领域经验迁移。维修老专家"听声辨障"和高炉操作工"看火候定性"，本质上可能共享同一种经验结构。如果能把不同领域的卡片统一到一个抽象层，AGI就能学到"判断力"本身，而不只是某个领域的具体经验。

这条路很长，但方向我认为是对的。AGI的瓶颈不在参数规模，而在我们有没有能力把人类几千年积累、却从未被写下来的那部分专业判断，系统化地交给模型。attas给了一个务实可行的起点——先从一个老师傅开始，一张卡片一张卡片地采，一个场景一个场景地验，把"说不清道不明"变成"说得清、验得过、用得上"。