企业官网建设流程全解析

我一开始用 AI 辅助干活的时候，有个特别深的挫败感：明明上周已经跟它交代过我写文档的习惯、代码风格、汇报方式，今天新建一个会话，它又全忘光了。每次都要重新把“我是谁、我想要什么风格、结论放前面、别给我列一堆废话”这些话说一遍，说多了我自己都烦。后来我做了个叫 Agent-Skills 的小项目，核心就一句话：把“工作方式”固化成一组 AI 可以按需加载的技能包，让模型在开工前先读取对应的“工作记忆”，它才终于像个跟了我一段时间的助手，而不是一个每次都在重新面试的新人。

这个项目适合谁？适合所有重度使用大模型写代码、写分析、写方案的人，尤其是那些想把个人经验沉淀成团队可复用模板的开发者。下面是我自己的实现笔记，偏实操，从设计思路、技能结构、代码实现到踩坑记录都有，你可以直接照着搭一个最小可用版本。

1. 这项工程在解决什么：AI 为什么总记不住你的习惯

1.1 每一次对话都是“失忆”的重新面试

大模型本身没有跨会话的记忆，这是架构决定的。每次对话结束，上下文窗口里的内容就被清空了，下次新建会话，模型对你的了解就是零。这个问题在浅层使用中不明显，比如偶尔让它写个文案、翻译一段话，不需要什么个性化；但一旦你进入高频工作流，比如每天让它辅助写周报、做代码评审、拆需求，问题就非常刺眼了。

我举个例子。我每周写技术周报，以前每次都要在提示词里重新强调：按项目维度归类、每条事项写“动作+结果”、阻塞问题单独列出来、总字数控制在 500 字以内。这些话每写一次就要占掉几百个 token，而且每次写出来的效果还不稳定——有时候它记得把结论放前面，有时候又洋洋洒洒写一大段背景。本质原因是“工作方式”没有被结构化，只是临时躺在提示词里，随用随丢。

Agent-Skills 解决的就是这个问题：把散落在提示词里的“做事偏好”抽出来，变成一个有结构、有版本、可以被动态加载的技能文件。AI 在启动任务前，先加载对应技能，表现就会稳定很多。

1.2 提示词、RAG、微调和 Agent-Skills 的定位差异

很多人会问：这不就是写个提示词模板吗？跟知识库 RAG 有什么区别？是不是微调才能根治？

我把这几个方案的定位理一下。普通提示词模板解决的是“一次性表达需求”，你写一段话，模型照着执行，缺点是每次都要重新写、难以复用、没有逻辑分支。RAG 解决的是“给模型提供外部知识”，比如把公司文档库接进来，让模型回答问题时能引用资料，它管的是“知道什么”，跟“怎么做”是两回事。微调则更重，它是去改模型的权重，让模型本身的行为发生偏移，成本高、周期长，而且只为了解决“输出风格”这种问题，性价比很低。

Agent-Skills 走的是中间路线：不动模型权重，也不做大规模知识检索，而是把“行为规范”做成模块化的技能描述，在运行时动态注入提示词。它管的是“怎么干活”，比提示词模板更系统，比 RAG 更贴近行为控制，比微调更轻量。用“系统”这个词可能更准确：它是一套管理行为描述的基础设施，不是单次输入的提示词。

1.3 Agent-Skills 想达到的效果

我做完这个小项目之后，给自己定的目标非常简单：让 AI 在接到常见任务时，表现得像“我远程带过一阵子的实习生”，而不是“一个什么都不知道但能力很强的陌生人”。

拆成可衡量的标准大概有三条。第一，同一类任务，连续多次执行，输出质量波动不能大，比如周报每一次都能按模板格式输出。第二，用户对输出的修正请求，能通过修改技能文件固化下来，下次直接生效，不需要重新教一遍。第三，不同技能之间可以组合，比如“需求分析技能”和“代码设计技能”可以串成一条完整的工作流，而不是每次都要单独触发。

如果你也在被“每次都要重新交代背景”折磨，那这个项目的基本方向就是对的：先把工作方式拆成技能，再让 AI 按需加载，最后在实战中持续迭代技能库。

2. 核心设计：把“工作方式”变成一组可加载的技能包

2.1 技能单元：一份描述不是一堆要求，而是一份“操作契约”

刚开始我犯过一个错误：把技能描述写成了“我希望你……”“请记得……”这种愿望清单。结果模型经常选择性忽略，因为这种描述太松散，没有约束力。后来我换了个思路，把每个技能当成一份“操作契约”，也就是明确写出：什么情况下该启用、进来时要接收什么输入、按什么步骤处理、最终输出成什么样、哪些事情绝对不要做。

拿“技术周报生成”这个技能举例，一份好的技能描述长这样：它有明确的触发条件，比如“用户要求写周报、做周总结、汇报本周进展”；它有明确的输入项，比如“本周完成事项、阻塞问题、下周计划”；它有步骤约束，比如“先问用户补齐缺失信息，再按项目维度归并事项，每条写成动作+结果”；它还有禁则，比如“不要用‘赋能’‘抓手’这类空词，不要编造未发生的事项”。

这种契约式描述的好处是：模型每次执行时有一条清晰的“行为路径”，不是自由发挥，而是按照步骤走。自由发挥对创作类任务有价值，但对工作流任务是灾难，稳定性才是第一位。

2.2 技能包的组织形态与技能清单

一个技能包本质上就是一个文件，我习惯用 JSON，因为它既方便程序读取，也方便人工维护。文件里除了技能主体，还要有id、version、trigger这些元信息，元信息不是摆设，后面做技能管理和版本对比时全靠它们。

{ "id": "weekly-report", "name": "技术周报生成", "version": "1.3.0", "trigger": "用户要求生成周报、写周总结、汇报本周工作", "input": ["本周完成事项", "阻塞问题", "下周计划"], "steps": [ "先检查输入是否齐全，缺失则向用户追问", "按项目维度归并本周完成事项", "每条事项写成“动作 + 结果”格式，尽量带上具体数字", "阻塞问题用一句话说明现状和需要谁支持", "输出 Markdown 格式周报，总字数控制在 500 字以内" ], "constraints": { "tone": "平实、不吹嘘", "style": "少形容词，多用事实和数字", "forbidden": [ "不要使用“赋能”“抓手”“闭环”等空泛词汇", "不要编造未发生的事项", "不要把本周问题和下周计划混在一起写" ] }, "output_template": "## 本周完成\n...\n## 阻塞问题\n...\n## 下周计划\n..." }

技能清单则是一个总索引，记录当前用户有哪些技能、每个技能对应的文件路径、加载优先级。优先级这个字段特别重要。假设用户同时导入了“周报生成”和“文档格式化”两个技能，它们都对输出风格有要求，如果优先级不清，模型就会困惑，不知道听谁的，最后输出一个四不像。我会在清单里给每个技能标注是否默认加载、是否按需加载，避免无冲突。

2.3 加载策略：不是把所有技能都塞进上下文

这是我在设计时反复斟酌的一个点：到底把多少技能塞进系统提示词里才合适？

一开始我很天真，觉得技能越多越好，把自己常用的十几个技能全塞进去。结果上下文被占掉一大半，不仅浪费 token，模型还容易出现“记忆混乱”——它同时记住好几套规则，遇到任务时不知道该执行哪套。后来我悟了：技能的加载要分层。

第一层是全局默认技能，只放那些在几乎所有任务中都要遵守的底线规则，比如“所有输出都用中文”、“代码要附注释”、“复杂问题先给结论再给推理”。这类技能数量必须控制在 3 个以内。第二层是按需加载技能，也就是真正的工作流技能，比如“技术周报生成”、“代码评审”、“需求拆解”，只有在对应任务触发时才注入。第三层是参考型资源，比如输出模板、代码规范文档，这些不需要常驻上下文，需要时再读取。

这样做的好处很明显：上下文窗口里的内容永远是“够用就好”，不会因为技能太多而拥堵，模型也能更专注地执行当前任务。

3. 实操落地：从零搭一个让 AI 记住工作方式的最小系统

3.1 技术选型与系统组成

我的目标是用最少的代码跑通闭环，不想一开始就引入重框架。系统组成其实很简单：一个支持函数调用的大模型 API、一个技能加载器（用来读取技能文件并注入提示词）、一个简单的任务分发逻辑。

这里多说一句选型思路。技能加载器不需要杂技术，就是读写文件、拼接字符串。任务分发逻辑才是关键，它要判断当前用户的输入命中了哪些技能，再把对应技能注入上下文。模型我选的是市面上主流的支持工具调用的大模型，因为 Agent 任务里经常要调用外部工具，比如查数据库、执行脚本，支持函数调用能省很多事。

整体架构用一个生活化类比来说：技能文件是“菜谱”，技能加载器是“找菜谱的人”，任务分发逻辑是“厨师长接到客人点菜后，把对应菜谱递给厨师”。客人不需要每次重新描述这道菜怎么做，厨师长也不用临场想，一切按既有流程走。

3.2 定义第一个技能：以“技术周报生成”为例

第一次做技能包，我强烈建议从一个你自己每周都会做的重复任务开始，因为频率高，你才能最快感受到效果差异。我自己第一个定的就是“技术周报生成”。

定义过程分四步。第一步，把这个任务在你这边的标准流程写下来，不用管格式，先写“我平时是怎么做的”：先把这一周做的事列出来，按项目归一下类，看看哪些是进展、哪些是阻塞，最后挑重点写成 500 字左右。第二步，把“我平时的偏好”补进去：我喜欢每条事项带数字，比如“性能优化完成，接口响应时间从 800ms 降到 200ms”；不喜欢空话套话；阻塞问题必须写清楚需要谁配合。第三步，把“我绝对不要的”也写进去：不要编造没做过的事，不要把所有事项平均用力写，要有主次。第四步，把它们整理成上面那种 JSON 结构。

这个过程中最重要的不是格式，而是把你自己平时“默认知道”的东西显性化。你觉得自己知道怎么写周报，但 AI 不知道，它只有看到你写出来的规则，才能照着执行。

3.3 实现技能加载器

技能加载器的实现不复杂，我用 Python 写了一个约 80 行的最小版本，核心就两个函数：一个是“根据用户输入匹配技能 ID”，一个是“把匹配到的技能注入系统提示词”。

import json from pathlib import Path SKILL_DIR = Path("./skills") def load_skill(skill_id: str) -> dict: skill_path = SKILL_DIR / f"{skill_id}.json" if not skill_path.exists(): return {} with open(skill_path, "r", encoding="utf-8") as f: return json.load(f) def match_skills(user_input: str) -> list[str]: matched = [] for skill_file in SKILL_DIR.glob("*.json"): with open(skill_file, "r", encoding="utf-8") as f: skill = json.load(f) trigger = skill.get("trigger", "") if any(keyword in user_input for keyword in trigger.split("、")): matched.append(skill["id"]) return matched def build_system_prompt(user_input: str) -> str: base = "你是一个经验丰富的工程效率助手，请严格按照给定的技能描述执行任务。" skills = match_skills(user_input) for skill_id in skills: skill = load_skill(skill_id) if not skill: continue base += f"\n\n[技能：{skill['name']}]\n" base += "触发条件：" + skill["trigger"] + "\n" base += "执行步骤：" + " → ".join(skill["steps"]) + "\n" base += "输出约束：" + json.dumps(skill["constraints"], ensure_ascii=False) + "\n" base += "输出模板：" + skill["output_template"] + "\n" return base

实际调用大模型时，只需要把build_system_prompt(user_input)的返回值作为系统提示词，把用户输入作为用户消息。就这么简单，一个能“记住工作方式”的最小系统就跑起来了。

我特意没把加载器写成复杂的插件系统，因为早期最重要的是让你看清楚核心链路：技能文件 → 匹配 → 注入。等这个链路跑顺了，再考虑加缓存、加线程、加 Web 界面都不迟。

3.4 跑通一次带技能的任务

系统搭好之后，我做了一次完整测试。输入是：“帮我把这周的工作整理成周报，这周完成了用户登录模块的重构和订单查询接口的优化，订单查询接口从 800ms 降到 200ms，另外支付回调有点问题，下周计划做数据监控。”

如果没有技能包，模型估计会洋洋洒洒写一段“本周工作总结”，很可能还带个“首先、其次、最后”。但这次系统先匹配到了weekly-report技能，把执行步骤、约束、模板全部注入上下文，模型的输出就完全变了样：它先按项目维度把两件事分开，每条都用了“动作+结果”结构，阻塞问题单独列出来写清现状，还自动把支付回调问题定位成“需要后端和支付渠道确认”，输出格式跟模板完全对齐。

这一步跑通的时候，我最大的感受是：AI 的输出终于从“像一篇文章”变成了“像一个懂你工作习惯的人写的文档”。这不是模型变聪明了，而是技能包把“你的工作方式”完整传递给了模型。

4. 技能包的持续进化：更新、版本管理与团队复用

4.1 技能包的版本管理思路

技能包不是写一次就定型了，它会随着你的工作方式一起进化。比如你换了新的周报模板、改了代码规范、新增了需求评审流程，技能包都要跟着改。既然技能包是文本文件，那最好的管理方式就是把它们放进 Git 仓库里，这绝对是我最推荐的做法。

版本管理的具体操作很简单：每个技能 JSON 里维护一个version字段，每次修改就升一个版本；技能包的目录结构按用户或者按团队组织，比如skills/me/weekly-report.json、skills/team/code-review.json；每次改动提交清晰的 commit message，说明“这次改了哪条规则、为什么要改”。

有人可能会觉得，管理几个 JSON 文件不必要用 Git。但我的真实体会是，当你手上有 20 多个技能文件迭代了两三个月之后，你会非常需要知道“上周周报输出格式突然不对，是不是我改了技能文件里的模板字段”。Git 能让你秒查这个问题，没有版本管理就只能靠回忆。

4.2 根据反馈修正技能：从“AI 不听”到“听得懂”

技能包跑起来之后，你会发现一个常态：模型不是每次都会严格执行。这时候第一反应不该是“模型真蠢”，而是“技能描述可能没写到位”。

我归纳过三类最常见的执行偏差。第一类是“工具性描述缺失”：你只说了“要写结论”，但没说“结论放在第一行还是第二段”，模型就自由发挥了。第二类是“边界不清晰”：你说“不要写废话”，但模型不知道对你来说什么是废话，你得具体到“不要出现‘总之’‘综上所述’这类词”。第三类是“步骤之间缺衔接”：你说完“第一步做什么、第二步做什么”，但没说“第二步需要用到第一步的什么输出”，模型会卡在中间不知道怎么办。

我修技能的时候会做一件事：把一次失败输出和一次理想输出放在一起对比，找出差异点，然后把差异点反推成一条新的规则。循环几次之后，技能描述就会越来越紧贴你的真实需求。

我强烈建议给技能加一个“禁止列表”。不要小看这招，实测下来，正面要求模型“要写清楚”“要简洁”效果很模糊，但反面约束“不要出现某个词”“不要超过 500 字”“不要在结论前加背景描述”效果立竿见影。人类注意力机制对“不要做什么”往往比“要做什么”更敏感，模型在这个场景下也有类似表现。

4.3 技能包分享与团队复用

当技能包的个人闭环跑顺之后，我马上想到一个问题：这套东西能不能让团队一起用？答案是能，但要做两个改造。

第一，去个人化。你自己的技能描述里肯定带了很多私人偏好，比如“我在周报里喜欢用某个词”。团队共享时，这些要去掉，改成团队通用的规范。第二，建立共享技能仓库，团队每个人都可以提交新技能或修改现有技能，但合并前要经过评审，就像代码评审一样。我会在仓库里放一个README.md，说明技能命名规范、字段含义、提交流程，让新人也能快速上手。

团队化之后，最大的价值是沉淀。以前团队的工作方式散落在每个人的脑子里，新人进来全靠老人带；现在新人只需要把团队技能包导入自己的 Agent，AI 就能在干活时自动遵守团队规范，老人也能少讲很多重复的注意事项。

5. 常见问题与避坑实录

5.1 技能之间打架怎么排查

多技能同时加载时，最先遇到的一定是规则冲突。有个很典型的场景：你同时导入了“周报生成”和“文档格式化”两个技能，一个要求“标题用三级结构”，另一个要求“所有文档尽量用一句话总结”，模型就会困惑。

我的排查套路分三步。第一步，开启调试模式，把最终拼进系统提示词的完整文本打印出来，看看到底有哪些技能被注入。第二步，检查技能清单里的优先级字段，确保业务级技能（比如周报）优先于通用级技能（比如格式化）。第三步，直接修改低优先级技能的描述，在开头加一句“如果与其他技能冲突，以更具体的技能为准”。

这个问题最好的处理方式是提前预防：定义技能时，尽量让技能之间职责边界清晰；加载时，设置默认不加载通用技能，只有特定任务命中时才加载。

5.2 技能描述写得太抽象导致 AI 自由发挥

我最早写技能的时候，特别喜欢用“要逻辑清晰”“要重点突出”这种话。后来发现这跟没写一样，因为模型不知道对你来说什么叫“重点突出”。你以为它会抓项目进展，结果它抓的是你工作强度。

解决方法是把抽象要求翻译成具体规则。把“要重点突出”翻译成“标题下方第一句话必须是最重要的事实”；把“要逻辑清晰”翻译成“每个自然段只写一个事项，段与段之间不要重叠”；把“要简洁”翻译成“每条 30 字以内，超过就拆成两条”。具体到可检查的规则，模型才会照着做。

这条经验最初来自一次让我很崩溃的测试：我让模型“用专业语气写一份故障说明”，它给我写了一段像论文摘要一样的东西，措辞很严谨但没有一个有效信息。后来我把它改成“第一句写故障现象，第二句写影响范围，第三句写根因，后续补时间线”，输出立刻就能直接发出去。所以每次写技能描述的时候，我都会问自己一个问题：这条规则，新来的实习生能看懂吗？如果看不懂，就再拆细。

5.3 上下文超限如何瘦身

技能多了，上下文必然膨胀。我有一次把全部技能都设置成默认加载，开源项目跑起来直接提示上下文超限，最后模型干脆罢工了。

瘦身原则我在前面讲过，再展开一点：技能文件里最占空间的部分通常是“详细示例”和“长输出模板”，这两类内容不需要每次加载。我会把示例和模板单独拆成资源文件，技能文件里只保留“按照模板文件 xx.md 输出”的索引。这样上下文开销能减少一半以上。

另外可以给技能文件的steps字段设置数量上限，这个字段越多，响应越快但更占空间；如果步骤超过 5 条，可以把后面几条合并成“按既有流程处理”或者拆成子技能。尽量把每个技能控制在 600 字以内的描述量，这算是我的经验红线。

5.4 什么时候该放弃技能包改用代码控制

技能包不是万能的。如果某个任务的执行过程中包含大量确定性逻辑，比如必须查数据库、必须调用固定接口、必须做数据清洗，那就应该直接用代码控制，而不是让模型照技能描述自由发挥。我的判断标准很简单：如果这个任务“给一个初级工程师做，他会问 10 个问题”，那就该上代码，因为你需要的可能不是“学会工作方式”，而是一个确定的结果。

技能包最适合的是那种“执行路径稳定但输出内容灵活”的任务，比如写周报、做需求分析、生成方案初稿。一旦任务变成“必须有精确的数据结果”，就把它从技能包里摘出来，写成工具函数交给模型调用。这个边界分清楚之后，你的 Agent 会稳定很多，你会少生很多气在后面测试的时候，以上这些坑我基本上都踩过一遍，尤其是“技能描述写得太抽象”那一次，真的是浪费了我整整一个下午。但反过来，正是这些坑让我把技能描述打磨成了现在的样子，现在的规则越来越少，但每一条都能被精确执行。

我个人在实际操作中最大的体会是：Agent-Skills 本质上不是一个技术项目，而是一个“自我认知项目”。你得先清楚自己平时到底是怎么干活的，才能把这些方法教给 AI。所以一开始不用急，先挑一个高频任务跑起来，再慢慢往技能库里沉淀，几周之后你就会明显感觉到，和 AI 的配合从“每次重新面试”变成了“老搭档干活”。

最后再分享一个小技巧：给每个技能写一个“失败示例”，就是把你曾经觉得特别差的模型输出放进去，旁边标注“这就是错误示范，不要这样写”。实测下来，这比任何抽象要求都管用，AI 看完立刻就能避开最常见的坑。这个方法免费送给你，不用谢。