企业官网建设流程全解析

前两天有个朋友来找我吐槽，说团队里明明已经接入了AI助手，日常问答、资料整理都挺能打，可一到处理具体业务就翻车，要么答非所问，要么流程走到一半就卡住。我问他是不是直接把一段需求说明甩给了AI让它自由发挥，他点了点头。我说问题就出在这儿——你缺的不是一个更聪明的AI，而是一份写得合格的Skills。

这几年AI Agent的概念被炒得火热，但真正决定一个智能体能不能在真实工作里扛活的，往往不是底层模型多强，而是你给它配了哪些“技能”。所谓Skills，你可以把它理解成给AI发的“岗位说明书+操作手册+工具箱”三合一。它把一类任务拆解成清晰的步骤，配上可执行的脚本和限定条件，让AI从“什么都懂一点的聊天机器人”变成“能稳定干成一件事的员工”。这篇文章会把Skill从设计、编写、测试到踩坑修复的完整链路讲透，特别适合正在给助手写技能的同学，也适合想从零搭建一套内部AI工作流的小伙伴参考。

1. 先把“Skills”这件事掰开揉碎

1.1 一个Skill到底长什么样

很多人第一次接触Skills时有个误解，以为它就是一段写得很详细的提示词。其实提示词只是Skill的一部分，甚至不是最关键的那部分。一个完整的Skill通常是一个目录，里面有说明文件、资源文件和可执行脚本。说明文件负责告诉AI“什么时候该用这个技能、用的时候按什么步骤走、哪些事绝对不能做”，脚本则负责做那些AI本身不擅长或者不稳定的计算和处理。

举个例子，我之前带团队给客服场景写过一套“订单问题诊断与售后工单生成”的Skills，目录结构大致是这样的：

order-diagnosis-skill/ ├── SKILL.md ├── assets/ │ ├── exception_keywords.txt │ └── answer_templates.json └── scripts/ ├── analyze_order.py └── generate_ticket.py

SKILL.md是核心入口，AI会优先阅读它来决定是否调用这个技能以及如何调用。assets目录里放着辅助参考材料，比如异常问题关键词表、答复模板，AI在生成话术时可以参考。scripts目录存放真正干活的代码，比如从订单数据里提取特征、判断异常类型、自动填单。这三层各司其职：说明负责“知道怎么做”，资源负责“知道参考什么”，脚本负责“把事真正落地”。

1.2 为什么不能把需求一股脑塞给AI

我见过很多团队的第一个Skill是这么写的：让AI充当售后专家，分析订单数据并生成工单。听起来没问题，但实际跑起来就会出现大量幺蛾子。比如AI自己编造订单号，因为它其实没有权限访问数据库，只是凭借训练记忆“脑补”了一个；再比如它把“物流超时”和“商品破损”两种完全不同的售后类型揉在一个工单里，因为它分不清流程分支的判断标准。

根因在于：大模型是一个概率推理器，不是状态机。你给它一个开放目标，它会沿着最可能的语义路径走，但不会严格按业务规则去执行。Skill的价值就是把这些不确定性收敛住。它用明确的步骤约束AI的行为路径，用脚本接管需要精确计算的部分，用约束条件划定AI的自由度边界。一句话总结：Skill不是让AI更聪明，而是让AI更好用。聪明是模型的事，好用是工程的事。

这个观念如果没转过来，后面写多少Skill都会觉得别扭。

1.3 什么场景适合写Skill，什么场景不该写

动手之前先判断需求合不合适，能省下大量无用功。以我的经验，适合写成Skill的任务有三个特征：

• 任务流程相对固定，可以拆成若干个有序步骤，比如“先查库存-再算时效-后出方案”。
• 任务包含AI不擅长但规则能搞定的环节，比如精确计算、大小比较、格式校验。
• 同一个任务会被反复执行，且对输出的一致性有要求，比如定期生成报表、批量审核文案。

反过来，有些需求就不适合硬做Skill。比如高度依赖灵感和创意的头脑风暴，你给AI设太多条条框框反而压制输出质量；再比如一次性临时任务，花一两个小时写Skill还不如直接对话来得快。Skill是投资品，只有当你确定这个事会被反复干、而且干法相对稳定时，这份投资才划算。

团队里经常有人问我：“是不是所有事都能做成Skill？”我的回答是：凡是你能写出一份可执行SOP的事，都有变成Skill的潜质；凡是连你自己都说不清楚怎么做的事，AI更没法替你干。

2. 写Skill之前的准备工作

2.1 明确边界：哪些事归Skill管，哪些事不归

这是最容易被跳过的环节，也是决定Skill生死的一步。正式下笔之前，你必须先回答几个问题：这个Skill的输入是什么，输出是什么？哪些场景归它管，哪些场景它一定要拒绝处理？

拿我们当时做的订单诊断Skill来说，提前就划清了边界：只处理“已付款但未完成”状态的订单，只诊断“发货超时、缺货、地址异常、物流停滞”这四类问题，其他问题一律转到人工客服。这个边界极其重要，因为AI的默认行为是“有问必答”，如果你不给它划出拒绝处理的范畴，它就会自信地把超出能力范围的事情也硬接下来。

实操中我习惯用一个小表格来记录边界条件：

把这张表贴在SKILL.md的显眼位置，相当于提前给AI立了规矩：能干什么、不能干什么，一目了然。很多Skill翻车就是因为边界没立住，AI啥都敢接。

2.2 场景剧本：把工作流画出来再谈写代码

边界确认之后，下一个动作是梳理工作流。这个过程我不建议直接开写，而是先在纸面上把流程画出来。哪怕你不画图，至少也要把步骤一条一条列出来。一个合格的Skill流程通常包含四个阶段：理解输入、查证信息、做出判断、生成输出。

以订单诊断为例，当时的流程是这样拆的：

1. 从用户对话中提取订单号，并确认订单状态符合预设边界。
2. 调用脚本查询订单当前状态、支付时间、发货时间、物流轨迹。
3. 根据数据判断异常类型：如果支付后超过48小时未发货，判定为发货超时；如果库存记录显示缺货且补货时间未知，判定为缺货；如果收件地址省市区为空或格式非法，判定为地址异常；如果物流轨迹超过72小时未更新，判定为物流停滞。
4. 针对异常类型，从答复模板库中选取话术，并生成工单草稿。

这里有一个关键认知：流程拆得越细，AI的自由发挥空间越小，输出就越稳定。反过来，如果只给AI说“分析订单问题并给出建议”，它大概率会在判断异常类型时漏掉某个分支，或者在话术里自由发挥出与业务口径不一致的内容。

2.3 工具盘点：哪些环节需要脚本兜底

流程理完之后，逐个环节问自己：这件事AI凭语言能力能不能稳定完成？如果答案是不确定，那就需要脚本兜底。

我总结了一套简单的判断标准：凡是涉及数值计算、数据查询、格式校验、正则匹配、时间比较的环节，统统交给脚本；凡是涉及语义理解、内容生成、情感判断、话术选择的环节，留给AI。这样分工的好处是让AI把算力花在它真正擅长的地方，同时把业务规则牢牢握在代码里。

比如订单诊断里，“支付时间是否超过48小时”这种判断虽然AI勉强能做，但它可能因为不同时区、日期格式等问题算错，对吧？就算它算对了，你也没法保证每次都对。同样的事用Python脚本三行搞定，精确到秒。这不是AI笨，而是这类精确计算根本不该交给语言模型去做。再比如，从用户输入里提取订单号这件事，AI可以做，但脚本配合正则表达式会更稳。两边结合：AI先做语义理解和用户意图判断，脚本再做精确的参数提取和格式校验。

所以筹备阶段就要把脚本清单列出来，标注每个脚本负责的输入、输出和处理逻辑。宁可脚本多设计一个，也别把关键环节裸奔交给AI去猜。

3. 核心文件实战：SKILL.md从零到一

3.1 写好“触发条件”：决定AI何时出手、何时沉默

SKILL.md开头部分最重要的内容就是触发条件。它解决“这个技能什么时候该被调用”的问题。写得太宽，AI会在不合适的场景下强行调用，导致答非所问；写得太窄，AI该用的时候却不知道用，技能就白写了。

触发条件的写法核心是“场景化描述+正向条件+负向条件”。比如订单诊断Skill的正向条件可以写：当用户询问订单状态、发货进度、物流异常，或明确表达对订单进展不满时。负向条件要单独写一段：当用户仅询问商品规格、价格优惠或售后政策时，不得调用本技能，而应转交通用客服流程。

这里有个经验：不要只依赖“关键词命中”这种低级方式。AI理解语义，你可以写“如果用户提到物流不动了、好几天没人管，这些表达也属于触发范围”。把真实用户会说的口语放进去，比干巴巴的关键词列表有效得多。

还有一个容易忽视的细节：触发条件里要定义“优先级”。如果用户同时触发了多个技能，AI该选谁？我的做法是在SKILL.md开头就声明：“当本技能与通用回复逻辑冲突时，以本技能为准，但用户明确表达退款投诉等拒绝范围内的意图时，本技能主动让位给人工升级流程。”优先级写清楚了，后面能少吵很多架。

3.2 工作流步骤怎么写才不会被误解

我见过最多的失败案例，是工作流步骤写得太像“愿景声明”。比如“分析订单状况并给出合理建议”，这种话AI看了等于没看，它不知道具体动作是什么。好的步骤描述要具体到“在什么条件下做什么判断，输出什么格式的结果”。

拿订单诊断的步骤来说，当时写的是：

• 步骤一：从用户输入中提取订单号。提取成功后，调用scripts/analyze_order.py获取订单信息；提取失败时，向用户索要完整订单号，不得猜测。
• 步骤二：根据脚本返回的状态字段判断处理分支：订单状态为paid时进入异常判断流程；为completed时直接告知用户订单已完成，后续不进入诊断逻辑；为canceled时如实告知用户订单已取消，并提示联系客服处理退款。
• 步骤三：在异常判断流程中，依次检查四个判定条件，任一条件命中即锁定对应异常类型，并联合相应的答复模板生成诊断结果。
• 步骤四：如果四个条件均不命中，输出“订单当前正常”的结论，不生成工单。

每一步都有明确的动作和条件分支，AI不需要“思考”只能“照做”。为了让它更稳，我给每一步还加了一个“完成标准”字段，比如步骤一的完成标准是“拿到合法格式的订单号并通过脚本接口校验”。这样AI在执行完一步之后能自查有没有做对。

写步骤有一个心法：把AI当成一个记性不好但执行力强的新员工。你不能说“处理一下这个订单”，你得说清什么叫“处理”、先干什么后干什么、干到什么程度算完。

3.3 约束与禁忌：给AI上紧箍咒

如果说工作流定义了“该怎么做”，那么约束与禁忌就定义了“绝对不能怎么做”。这部分写少了、写模糊了，Skill的质量就没了下限。

约束包括三个层面：数据隐私约束、操作范围约束、措辞风格约束。数据隐私层面，要明确“订单号、用户手机号、地址等敏感信息只能在脚本内部处理，不得写入对话日志之外的地方，不要向用户复述完整的隐私信息”。操作范围层面，要声明“本技能只能诊断和生成工单，不具备改单、退款、取消订单的权限”。措辞风格层面，要约定“面向用户的答复需要简洁、有礼貌，并且必须在结尾提供下一步指引”。

禁忌部分我会直接列一个负面清单：不得编造订单数据；不得在脚本返回异常时自行猜测数据填充；不得在内部信息缺失时拒绝回答，而应采取替代方案向用户说明情况；不得讨论与售后无关的话题。这些条款每一行都来自真实事故。比如“编造订单数据”这条，早期版本没有写，AI在脚本接口偶发超时时，竟然自己编了个“订单已发货”的假结果安抚用户，差点酿成重大客诉事故。

约束语气的选择上，尽量用“必须/不得”这种强指令，不要用“尽量/建议”这种软表述。模型对强指令的遵循率显著高于软性建议。

3.4 元数据与版本管理：让Skill可维护

不要小看SKILL.md头部那几行元数据。它看似没什么用，但在实际团队协作、多版本迭代、问题追溯时能省大量时间。我会在每个Skill的头部固定记录以下信息：

{ "order_id": "A20250315001", "status": "paid", "created_at": "2025-03-10T10:00:00Z", "shipped_at": null, "logistics": ["2025-03-12: 已揽收", "2025-03-12: 运输中"], "is_overdue_shipment": true, "is_out_of_stock": false, "is_address_invalid": false, "is_logistics_stalled": false, "abnormal_type": "shipment_timeout" }