企业官网建设流程全解析

1. 把“一部电影的时间”翻译成工程语言

“用一部电影的时间训练个人专属 Agent”这句话第一次听上去像个营销话术，但真做过几个项目之后，你会发现它其实是一个非常讲究的时间盒（Timebox）设计。一部电影按 120 分钟算，这个数字不是随便挑的——它短到让你不敢乱设计架构，又长到足够把一个能用的个人专属 Agent 从零跑到能对话、能干活、能被别人试用的状态。我前后用这个节奏跑过七八个不同方向的 Agent，有做内部知识问答的，有做文案风格模仿的，也有做数据分析助手的，最快的 96 分钟收工，最慢的一次磨到 3 个多小时，超时的原因几乎每次都一样：中途想改需求。

这里先把话说清楚：这篇里说的“训练”，指的不是拿显卡跑梯度下降，而是把一个大模型改造成“只为你服务”的形态——喂它你的资料、给它你的说话方式、把常用动作做成工具、让它记住跟你协作的历史。业界管这套叫上下文工程或者 Agent 工程，本质是围绕一个通用底座做外挂式定制。它的好处是门槛低、迭代快、当天就能改；坏处是对数据和指令的质量极其敏感，你偷懒的地方它会原样放大十倍还给你。

适合谁看？如果你手上有一批自己的文档、笔记、聊天记录、工作流，想让模型按你的方式处理问题，这套流程直接能用。如果你只是想随便聊聊天，那确实没必要折腾，用现成的对话界面就行。下面我按真实操作的顺序，把这 120 分钟拆开讲，每个环节的取舍逻辑、参数算法、以及那些文档里不会写的坑，我都摊开说。

1.1 120 分钟的时间盒怎么切

先说结论式的时间分配，我反复调过几轮，这个比例最稳。早期我把 60 分钟都花在写系统指令上，结果发现检索一团糟，指令写得再漂亮也是空中楼阁；后来改成先打通“能查到你想要的东西”，再打磨“怎么说话”，返工率立刻降下来。

注意最后那 5 分钟，很多人会忽略。它的作用不是“美化”，而是逼你在时间耗尽前产出一个可交付物。哪怕只是一个能跑的对话窗口加一段使用说明，也比一个“还差一点就完美”的半成品有价值得多。我个人的习惯是，第 100 分钟一到，无论测出多少问题，都先冻结一个版本存起来，后续所有改动都基于这个快照对比，这样你才知道自己是在变好还是变坏。

时间盒真正的价值在于强制取舍。120 分钟装不下“我再多找点资料”“我再换个大点的模型”“我再调调参数”这些无底洞，于是你被迫回答一个关键问题：哪些东西是必须有，哪些只是锦上添花。真实项目里，80% 的可用性来自 20% 的动作，时间盒就是帮你把那 20% 找出来。

1.2 Agent 的四个零件与各自的时间占比

不管是哪个方向的 Agent，拆到底层都是四块东西：底座模型、系统指令、工具集、记忆与知识。这四块里，只有底座模型是“你选完就不该动”的，剩下三块全是你的活。

底座模型选型我一般看三件事：指令遵循能力、结构化输出稳定性、以及长上下文的“中间遗忘”程度。前两个直接决定你的工作流能不能跑通，第三个决定你塞进去 30 页文档后它还能不能记住第 5 页说的话。我的经验是，选一个中等规模、响应快的云端接口做主力，再备一个本地能跑的做兜底，这样既不用在高峰期排队，也不用担心某些私密内容外流。

系统指令是四块里性价比最高的一块，30 分钟投入能换来体验上最明显的差别。工具集是第二高，但它有个隐性成本：每多一个工具，模型选错工具的概率就上升一截，所以 2–3 个是甜点区。记忆与知识在你第一次搭的时候权重很高，后面维护时反而最省事——只要入库时把元数据打对，后面加资料基本是纯增量。

把时间按这个比例分，你会发现“训练”这件事根本没有想象中那么玄。真正难的不是技术，是你有没有想清楚自己要什么。我见过太多人卡在第一步，因为他们对 Agent 的期待是一句“帮我处理工作”，这种描述没法落地，模型也不知道该干什么。

1.3 为什么第一步不是微调

很多人一听“训练”就想到准备数据集、租卡、跑 LoRA。我明确劝退：个人 Agent 场景下，微调的投入产出比极差。算笔账就明白了。假设你有 200 份文档共 40 万字，想通过微调让模型“记住”这些知识，你需要构造几万条指令-回答对，标注成本按每条 3 分钟算就是上千小时的工作量，训练还得反复试超参。更致命的是，知识一旦更新，你得重训——这对个人用户来说是灾难。

而外挂式方案里，加一份新文档的成本就是切片 + 入库，两分钟的事。改一次说话风格，改系统指令里的一句话，十秒钟。这种迭代速度上的差距，在实际使用中会放大成完全不同的体验：前者是“一个月更新一次的知识库”，后者是“今天发现答错，明天就修好了”。

微调真正适合的场景很窄：你需要模型学会一种它从没见过的输出格式，或者需要把推理成本压到极低（用小模型替代大模型干固定任务），再或者有大量高质量标注数据闲着没用。个人专属 Agent 一般不满足这些条件，所以老老实实走外挂路线，把 120 分钟花在刀刃上。

2. 开工前的半小时：把“专属”变成可执行清单

我踩过最贵的一个坑，是没做需求收敛就直接开干。那次的目标是“做一个帮我写周报的助手”，听起来挺具体，实际做起来发现要处理的信息源有五六个系统，每个系统的数据格式都不一样，光对齐字段就花了两天。后来我学乖了，动手前先花 15 分钟做两件事：写一句能力声明，列一张不做清单。这两样东西加起来不到 200 字，但能省下后面几小时的瞎折腾。

2.1 用一句话锁死 Agent 的边界

能力声明的模板我自己用的是这个：“当____时，它接收____，输出____，判断成功的标准是____。”四个空必须填满，填不满说明你还没想清楚。举个例子，“当我在整理会议记录时，它接收我粘贴的原始速记稿，输出结构化纪要（议题、结论、待办、责任人），判断成功的标准是待办项一条不漏且每条都有责任人”。

这个句式的好处是它天然包含了输入、输出和验收标准，而验收标准是绝大多数人漏掉的一环。没有验收标准，你就没法判断 Agent 到底好不好用，只能凭感觉说“好像还行”。有了它，你后面做评测集就有依据，改指令也知道往哪个方向调。

不做清单同样重要。还是上面那个例子，我在不做清单里写了：不做会议录音转写、不做跨语言翻译、不做任务派发。写下来的目的不是限制，而是防止你在第 90 分钟手痒去接一个计划外的功能。时间盒最怕的就是中途扩张范围，一扩张必然超时，超时之后人就容易烦躁，烦躁就会做出糟糕的技术决策。

还有一个细节：把能力声明写在文档最上面，后面写系统指令时直接复制粘贴进去。这样指令和需求不会走偏，也方便你事后复盘“当初到底想做成什么样”。

2.2 语料清点：20份文档胜过2000份

语料这块我的观点可能有点反直觉：第一次搭，20 份高质量文档比 2000 份杂乱资料效果好得多。原因在于检索的信噪比。你塞进去 2000 份文档，里面可能有 60% 是过期的、重复的、和主题无关的，检索时它们会挤占 top-k 的位置，把真正有用的内容挤出去，模型拿到一堆噪音自然答得一塌糊涂。

我一般按这个标准筛：优先选你自己写的、且最近半年内更新过的内容。自己写的东西风格一致，模型学起来不会精神分裂；近期更新的能保证事实正确。文档类型上，长文优于碎片，结构化优于流水账。如果有聊天记录，只挑那些信息密度高的段落，别整段导出，那里面 70% 是“好的”“收到”“我看下”。

清点的时候顺手做一件事：给每份文档打个标签，比如“产品规范”“技术方案”“历史决策”。这个标签后面会变成检索时的过滤条件，非常有用。我试过一个场景，问“这个功能当初为什么这么设计”，如果不带标签过滤，检索会把所有提到该功能的地方都捞出来，包括使用手册；带上“历史决策”的过滤，直接命中当初的讨论记录，答案质量天差地别。

2.3 选型：三条路线与它们的代价

工具选型我不给具体产品名，因为这类工具半年就换一茬，给你名字反而是害你。但选型的判断维度是稳定的，我列成表格，你拿去对照着挑就行。

我的建议是第二次搭的时候选中间那条。第一次可以先用全托管平台跑通流程，感受一下“检索 + 指令 + 工具”是怎么协作的，等你发现某个环节怎么调都不听话、需要看内部细节时，再迁到编排框架上。这个顺序比反过来省时间，因为你先有了体感，学框架时知道每个抽象对应什么实际问题。

选型还有两个容易被忽略的点。一是向量检索库的选择，个人场景下文档量一般不超过 10 万块切片，用轻量的本地库完全够用，没必要上分布式方案，那玩意儿的运维成本比你的业务本身还高。二是要不要本地跑模型，如果你处理的资料涉密或者对延迟极敏感，本地跑是值得的，代价是要接受效果比云端旗舰模型差一截，尤其是复杂推理和长文档理解上。

3. 主体实操：120分钟一步步落地

前面铺垫完了，这部分是纯操作。我按时间顺序写，每一步都给出具体参数和判断依据，你照着改改就能用。需要说明的是，下面代码块里的接口名和字段名都是示意写法，不同工具的实际 API 会有差异，重点看逻辑而不是照抄。

3.1 前20分钟：语料清洗与切片参数怎么定

切片（chunking）是整个流程里最被低估的一步。很多人用默认参数直接切，切出来的块要么一句话被拦腰截断，要么一整章塞成一个块导致检索精度暴跌。我的做法是先看文档结构，再定参数。

以中文文档为例，我常用的基准是块大小 500 字、重叠 80 字。为什么是这两个数？块太小（比如 200 字）会导致一个完整论点被拆散，模型拿到半截话没法回答；块太大（比如 1500 字）会让检索的粒度变粗，你想查一个具体数字，结果捞回来一大段，模型还得自己找，找错的概率不低。500 字大概是一个完整段落到两个段落的长度，正好承载一个独立论点。80 字的重复是为了防止关键句刚好落在切口上，两边的块都能带一点上下文。

算一下总量：假设你清点出 20 份文档，平均每份 8000 字，总共 16 万字。按有效步长 420 字（500 减 80）算，切片数量约 160000 ÷ 420 ≈ 380 块。这个量级对任何轻量向量库都是小菜，检索延迟基本在 100 毫秒以内。

清洗这一步别省时间，我有三个固定动作。第一，去掉页眉页脚、目录、无关的版权声明，这些东西重复出现会污染检索。第二，把表格转成“字段：值”的文本形式，直接丢原始表格进去，模型经常读串行。第三，给每块加上元数据，至少包含来源文件名、章节标题、更新日期。元数据后面能救命，尤其是你问“最新版本怎么说”的时候。

# 切片示意：按段落聚合到目标长度，保留元数据 def split_doc(text, source, section, size=500, overlap=80): paras = [p.strip() for p in text.split("\n") if p.strip()] chunks, buf = [], "" for p in paras: if len(buf) + len(p) <= size: buf += p else: if buf: chunks.append({ "text": buf, "source": source, "section": section, "updated": "2025-01-01" }) # 保留尾部 overlap 字作为下一块开头 buf = buf[-overlap:] + p if buf: chunks.append({"text": buf, "source": source, "section": section, "updated": "2025-01-01"}) return chunks

注意：切片时不要跨章节合并。我见过为了凑够 500 字把两章内容拼在一起的，检索出来的块前半段讲 A 后半段讲 B，模型回答时会把两者混为一谈，这种错误极难排查，因为表面上答案读起来很通顺。

3.2 第20到45分钟：入库与检索验证

入库本身没啥技术含量，调个接口批量写进去就行。真正花时间的是验证检索质量，这一步决定了你后面所有工作有没有意义。我的做法是准备 5 个问题，每个问题我都清楚答案在哪份文档的哪一段，然后看检索返回的前 4 条里有没有命中。

这 5 个问题要有梯度：两个是直接查事实（“某个参数的上限是多少”），两个是需要跨段整合（“这个方案经历过哪几次调整”），一个是故意问文档里没有的（看它会不会硬编）。第三类问题最能暴露问题——如果检索层没有做阈值过滤，它会把最相似但无关的块捞回来，模型拿到之后就开始一本正经地胡说。

检索参数上，我一般用召回 top-8、重排后取 top-4。为什么要两段？因为向量相似度高不等于内容相关，很多块字面相似但讲的是另一回事，加一层重排能把这类噪音滤掉。如果工具不支持重排，那就把 top-k 设小一点（3–4），宁缺毋滥。相似度阈值我通常设在 0.5–0.6 之间，低于这个值的直接丢弃，让模型回答“资料里没找到”，比让它瞎猜强一百倍。

还有一个实操技巧：把问题本身也做一次改写再检索。用户的原始提问往往很短很口语，比如“那个东西怎么配”，直接拿去检索效果很差。让它先扩展成“某某功能的配置方法是什么”，召回率能提升一截。这个改写动作可以用一次很便宜的模型调用完成，成本几乎可以忽略。

3.3 第45到80分钟：系统指令的三段式写法

系统指令这 30 分钟是投入产出比最高的。我的写法固定分三段：身份与风格、工作流程、边界与拒答。三段之外不加废话，因为指令越长，模型越容易顾此失彼。

第一段身份与风格。这里的关键是具体，别写“你是一个专业的助手”这种谁都能套的话。要写清楚：你在哪个领域、面向谁、用什么语气、回答多长、要不要用列表、遇到专业术语怎么处理。我给一个自己常用的模板片段：“你在帮助一位有五年经验的产品经理整理资料。回答控制在 200 字以内，先给结论再给依据，依据必须标注来源文档名。不使用感叹号，不使用‘非常’‘极其’这类程度副词。”

第二段工作流程，这是让 Agent 从“聊天”变成“干活”的关键。要把处理步骤写死，比如“第一步判断问题类型；第二步如果是事实类问题先查资料再回答；第三步如果资料不足，明确说明缺什么；第四步输出前自查是否引用了来源”。写流程的目的是让模型的推理路径稳定，同一类问题每次都走同样的路，输出质量才可复现。

第三段边界与拒答，也是最多人漏掉的。要明确写：哪些问题不回答、遇到不确定的信息怎么办、被要求做超出范围的事怎么回应。我通常写“资料中没有明确记载的内容，直接回答‘资料里没有找到相关记录’，不要推测”。这一句话能挡掉八成幻觉。

# 系统指令骨架示意 [身份] 你是……，服务于……，输出风格为…… [流程] 1) 判断问题类型 → 2) 检索资料 → 3) 组织答案并标注来源 → 4) 自查 [边界] 无资料支撑时不推测；超出范围时说明并给出替代建议； 不输出与任务无关的闲聊内容。

3.4 第80到105分钟：工具接入与流程编排

工具这块的原则是少而准。我建议第一次只接 2 个，最多 3 个。为什么？因为模型在多工具场景下要做“选哪个”的决策，工具越多，选错的概率越高，而且一旦选错，后面的流程全歪。我测过一个案例，从 3 个工具加到 8 个，任务成功率从 82% 掉到 61%，原因是模型频繁调用错误的工具。

工具描述（description）的写法有讲究。很多人写得像 API 文档：“查询订单接口，参数为 id”。模型看不懂这个工具什么时候该用。正确的写法要包含三件事：这个工具干什么、什么情况下用、什么情况下不要用。比如“查询历史版本内容。当用户询问某份文档过去的表述或变更原因时使用。如果用户问的是当前最新内容，不要用这个工具，直接查知识库。”

编排方式上，简单场景用“模型自主决定调哪个工具”就够了，复杂场景（比如需要按固定顺序跑三步）建议用显式流程，把步骤写死。显式流程的好处是可预测、好调试，坏处是不够灵活。我一般先在显式流程上跑通，等稳定了再逐步放开让模型自主决策，这个演进路径比一上来就追求全自主靠谱得多。

注意：每个工具都要有失败兜底。网络超时、返回空、格式不对，这些情况必须让 Agent 知道该怎么回应，而不是把原始报错抛给用户。我通常在工具层包一层，把异常转成“该操作暂时不可用，请稍后重试或改用其他方式”。

3.5 最后15分钟：用20条用例做回归

没有评测的 Agent 就是薛定谔的 Agent，你永远不知道它下一次会给你什么。15 分钟能做的事很有限，但足够建一个最小可用的回归集：20 条用例，覆盖 5 类问题（事实查询、跨文档整合、边界外提问、格式要求、多轮追问），每类 4 条。

每条用例记录三样东西：输入、期望输出要点、实际输出。通过标准不要定成“字面完全一致”，那不可能达到，定成“关键信息是否命中 + 是否引用了正确来源 + 有没有编造”。我一般用人工快速扫一遍，20 条大概 3 分钟能看完。

这个集合的价值在后续。你每次改指令、换模型、加工具，都拿这 20 条跑一遍，通过率掉了就回滚。我自己的记录里，有一次改了一句指令里的措辞，通过率从 18/20 掉到 13/20，原因是新措辞让模型倾向于简短回答，把引用来源那步给省略了。没有这个回归集，这种退化你根本发现不了，只会觉得“最近好像不太准”。

4. 让 Agent 像你而不是像客服的关键细节

跑通流程只是及格线，真正让 Agent 有“专属感”的是下面这些细节。这部分是我做了多个项目之后总结出来的，每一条都对应过具体翻车现场。

4.1 指令里必须写死的五类内容

我把必须写进系统指令的内容归成五类，缺一类体验就会掉一个档次。第一类是输出长度与结构，不写的话模型默认给你长篇大论，而多数场景你要的是三句话。第二类是术语口径，同一个概念在不同团队叫法不同，你要指定用哪个词，否则它会混着用，读起来很别扭。第三类是引用规则，要求它每条结论后面标注来源，这条能极大提升可信度，也方便你核查。第四类是不确定时的表达方式，明确告诉它“不确定就说不知道”，比让它猜要好。第五类是禁用表达，比如禁用“综上所述”“希望对你有帮助”这类客套话，写了之后输出立刻干净很多。

这五类内容加起来大概 300–500 字，写起来不费劲，但效果立竿见影。我做过一个对比，同样的底座模型、同样的知识库，只加这五类约束，人工评分从 3.2 分（5 分制）提到 4.1 分。提升主要来自“不用再费劲从一堆废话里找重点”。

写的时候有个小技巧：用正面描述代替负面禁止。“回答控制在 100 字内”比“不要长篇大论”有效，“先给结论”比“不要绕弯子”有效。模型对具体指令的遵循度远高于抽象要求。

4.2 检索效果的决定性参数

检索这块有三个参数值得盯：块大小、top-k、相似度阈值。它们互相影响，不能单独调。块调大，top-k 就该调小，否则塞进上下文的内容太多，模型反而抓不住重点；块调小，top-k 要适当放大，不然信息不全。

我常用的组合是 500 字块 + top-4 + 阈值 0.55。这个组合在中文技术文档上表现比较稳。但如果你的文档是对话记录或者短文案，块要降到 200–300 字，因为这类内容信息密度低，大块会稀释相关性。

还有个被严重低估的点：混合检索。纯向量检索擅长语义相似，但对精确匹配很弱，比如你问某个编号、某个型号，它可能给你语义相近但编号不同的内容。加上关键词检索做混合，两路结果合并再重排，精确匹配的召回率能提升一大截。这个改动在编排框架里一般十几行代码就能实现，性价比很高。

4.3 记忆分层的三层做法

“记住我”是个人 Agent 最容易被期待的能力，也是最容易做砸的。我的做法分三层，各层职责清晰，不混在一起。

第一层是会话内记忆，就是当前对话的历史，直接用上下文窗口承载。这层不需要额外设计，但要注意长度控制，超过一定轮数就做摘要压缩，否则上下文被闲聊占满，真正有用的信息反而进不来。

第二层是长期偏好，比如你的写作风格、常用术语、固定格式要求。这层我用一个结构化的配置文件存，每次对话开始时注入。为什么不放知识库？因为它是“规则”不是“知识”，走检索可能召回不到，而它必须每次都在场。

第三层是事实性记忆，比如你之前提过的项目背景、决策记录。这层走知识库检索，按需召回。这里的关键是写入时机：不要每句话都写，只在检测到明确的事实陈述且与已有内容不重复时写，否则记忆会迅速膨胀成一堆垃圾。

5. 常见问题与排查实录

5.1 问题速查表

下面这张表是我这几年攒下来的，按症状查原因，基本能覆盖八成情况。

5.2 三个我踩过的坑

第一个坑是过度依赖重排。有一段时间我迷信重排模型，把 top-k 开到 20 让重排去筛。结果延迟飙到 5 秒以上，用户体验极差，而准确率只提升了不到 3 个百分点。后来我明白，重排解决的是“排序问题”，解决不了“根本没召回”的问题。如果第一层召回就没捞到，重排再强也没用。正确做法是把功夫花在切片质量和查询改写上，重排只做最后一道保险。

第二个坑是指令里塞了互相冲突的要求。我有一次同时写了“回答要详细完整”和“控制在 150 字以内”，模型的表现非常不稳定，有时候给三行，有时候给三大段。排查了半天才发现是自己写的指令打架。这件事让我养成一个习惯：指令写完后通读一遍，专门找矛盾点。凡是“既要又要”的地方，必须明确优先级——“优先满足字数限制，超出的细节放到追问时再说”。

第三个坑是用测试集调参然后自己骗自己。我曾经拿 20 条用例反复调，调到 20/20 全过，特别有成就感。上线之后发现真实场景一塌糊涂。原因很简单，我调的参数是专门针对那 20 条优化的，过拟合了。后来我改成留 5 条“绝不看”的用例，只在最后验证时跑一次，这样得到的分数才可信。这个习惯我一直保持到现在，虽然会损失一些调参的“爽感”，但能避免上线翻车。

6. 上线之后：让 Agent 自己变好的小机制

120 分钟交付的版本一定是粗糙的，这很正常。真正让 Agent 从“能用”到“好用”的，是上线之后那几周的持续打磨。这部分我分享两个成本极低但效果明显的机制。

6.1 反馈闭环怎么搭

最简单的做法是给每次输出加一个“有用/没用”的按钮，点“没用”时弹一个输入框让人写一句原因。数据量不用大，一周能收到二三十条反馈就足够看出模式了。我一般按周汇总，把反馈分成三类：检索没找到、找到了但组织得不好、指令没遵守。三类问题对应的修法完全不同，混在一起看会找不到头绪。

还有一个更轻的做法：定期抽查对话记录。每周抽 10 条真实对话，自己读一遍，标出哪句让你觉得“这不对”。这个方法不需要任何埋点，成本就是 15 分钟阅读时间，但发现问题往往比结构化反馈还快，因为你是带着真实语境在读。

反馈拿回来之后，一定要落到具体的改动上，别只记在脑子里。我的习惯是每次改完在文档里记一行：改了什么、为什么改、改完通过率从多少到多少。三个月后回头看这份记录，你会发现自己对这套系统的理解深了一大截，而且能避免反复犯同一个错。

6.2 成本与延迟的日常控制

个人用的 Agent 很容易在成本上失控，因为每次对话都带检索、带历史、带工具调用，token 消耗比裸聊高好几倍。算一笔账：单次对话的输入大概是系统指令 800 token + 检索内容 2000 token + 历史 1000 token，输出预留 500 token，合计 4300 token 左右。按某些主流接口每百万输入 token 个位数人民币的价格算，单次成本大概两三分钱。一天问 50 次就是一块多，一个月三四十块，这个量级个人完全能接受。

真正要控的是异常消耗。比如工具调用陷入循环、上下文无限增长、误触发了长文档分析。我的做法是设三个硬约束：单次对话最多 3 次工具调用、历史超过 8 轮就做摘要、单次输入上限 8000 token。这三个数字不一定要跟我一样，但必须有，否则某天你会看到一张莫名其妙的账单。

延迟方面，用户能忍的阈值大概在 3 秒。超过这个数体感就明显变差。如果慢了，先看检索耗时（超过 300 毫秒就是块太多或者库太重），再看模型首 token 时间（超过 1.5 秒考虑换更快的接口），最后看是不是串了太多次模型调用（比如先改写再检索再回答，三轮下来就慢了）。我一般把“查询改写”和“正式回答”合并成一次调用，用同一个提示词让它先想后答，能省掉一轮往返。

最后分享一个我自己一直在用的小习惯：每次搭完一个 Agent，我都会在文档里留一段“给三个月后的自己看的说明”，写清楚当前版本的局限、已知问题、以及如果继续做下一步该动哪里。三个月后你大概率已经忘了当时的取舍，这段说明能让你十分钟内重新进入状态，而不是从头再摸一遍。这套 120 分钟的流程我改了七八次，每次调整的依据都来自这些说明——它们比任何教程都更贴合你手上的具体问题。