企业官网建设流程全解析

1. 从"会写提示词"到"造Skill"：AI编程走到分水岭了

这两年我身边的开发者明显分成两种状态。一种还在对着对话框反复喂上下文：把公司的代码规范复制进去，把项目结构贴进去，再叮嘱模型"记得用error wrapping"，一轮对话下来光铺垫就花掉十分钟。另一种则开始用起了"技能包"——他们不再每次重复解释需求，而是直接丢一句"用xxx技能检查这段SQL"，模型自己就知道该套用哪套规范、走哪些检查步骤、按什么格式输出结果。

后者用的，就是现在AI编程圈里热度一路走高的"Skills"体系。所谓Skill，可以通俗理解成给代码助手安装的"岗位说明书"：把你希望模型稳定遵循的工作流程、专业知识、输出模板、边界约束打包成一个可命名的单元，之后一次命名调用，效果稳定发挥。而陌讯Skills，正是这类生态里目前覆盖面最广、社区活跃度最高的一套实现。

顶尖工程师为什么集体转向它？我自己的体会是：不是因为某单个技能写得多么惊艳，而是这套生态第一次把"AI编程技能"做成了有版本、有规范、能共享、能拆装的标准件。在AI编程工具已经多得让人挑花眼的当下，真正决定落地效果上限的，恰恰是"标准"这件事。这篇文章，我就围绕陌讯Skills这个生态，把一个AI编程Skill从设计、编码、调试到上架分享的完整链路拆开讲透，把我踩过的坑和沉淀下来的方法一并交代清楚。不管你现在是用AI辅助写业务代码，还是在带团队推行AI编程规范，这节内容都值得你花十分钟仔细看看。

2. 为什么说"标准化"是AI编程Skill生态的生死线

2.1 没有标准之前，提示词是"手工作坊"

先回到最原始的问题：为什么非得有一个标准化的Skill生态？因为过去靠提示词堆出来的"AI编程能力"，本质上是手工作坊。

我早先在一个跨平台项目里试着让AI帮我做代码审查。当时整理的审查提示词大概有八百字：要求模型先读文件、再对照项目规范、然后列问题清单、最后给出修改建议。第一次用得不错，第二次换了个文件，咦，输出格式变了；第三次换个人来用，效果又不一样。后来发现问题出在三个层面：一是提示词分散在每个人的聊天记录和文档里，没有统一载体；二是一段提示词里混着"应当做什么"和"不应当做什么"，模型经常抓不住优先级；三是没有版本概念，我改了一版之后，上个月用的旧版是什么样，完全无迹可寻。

这听起来很像软件开发早期没有版本控制、没有测试用例的状态。一个人自娱自乐没问题，一旦要团队协作，立刻崩盘。

2.2 标准件思维：把AI能力变成可安装的"插件"

陌讯Skills的做法，是先把一个Skill定义成一个结构化的"标准件"。它明确划分了：这个技能叫什么、用来干什么、在什么条件下触发、按什么步骤执行、输出什么格式、依赖哪些资源。这就像给模型一份"工单"，而不是一句"你看着办"。

标准化的第一个收益是可复用。团队里一个资深工程师把"安全审计"打包成Skill，其他人直接拉下来就能用，不必再读他大脑里那套经验。第二个收益是可组合。多个Skill像积木一样搭在一起，先跑"代码规范检查"，再跑"安全审计"，最后跑"生成变更总结"，就能组成一条自动化流水线。第三个收益是可传承。Skill本身是一个带版本号的文件，项目里引入哪个版本一目了然，新成员上手时，看一遍Skill清单就能理解团队在哪些环节依赖AI。

这个逻辑听起来不复杂，但真正把它做成一套"生态"——有仓库、有索引、有拉取命令、有版本规则——就不是随便一个工具能做到的了。陌讯Skills的优势在于，它把标准贯穿到了从创作到消费的每一个环节，而不是只给一个schema字段表就撒手不管。

3. 陌讯Skills的标准化内核：一个Skill到底长什么样

3.1 Skill包的物理结构：目录即契约

我第一次创建陌讯Skill的时候，以为就是写个Markdown提示词丢进去。真正动手才发现，一个合规的Skill包是一个有固定结构的目录。拿我维护最多的"sql-review"技能来举例，它的目录长这样：

sql-review/ ├── skill.yaml # 元信息，定义名称、版本、描述、触发关键词 ├── rules/ # 规则文件，存放具体的检查规则 │ ├── index-usage.md │ ├── implicit-conversion.md │ └── limit-clause.md ├── prompts/ # 提示词模板，按步骤拆分 │ ├── analyze.md │ └── report.md ├── scripts/ # 可选的执行脚本，用于预处理/后处理 │ └── normalize_sql.py └── tests/ # 测试用例，用真实SQL验证技能效果 ├── case1.sql ├── case1.expected.json └── case2.sql

这个结构初看有点繁琐，但用久了就明白它的好处。提示词模板被拆分成"分析"和"报告"两步，模型不会再把逻辑混在一起；规则文件独立成Markdown，等于把团队知识库嵌进了技能包；tests目录则让技能效果可以被持续验证。

拿rules/index-usage.md来说，它不是让模型"留意索引"，而是给出了可执行的判断标准：查询字段上是否有函数包裹、多列条件是否遵守最左匹配原则、模糊匹配是否使用了中缀通配符。这些规则写得越具体，模型产出的审查结果就越稳定。

3.2 skill.yaml：把"触发"和"上下文收集"写清楚

整个包的核心是skill.yaml。下面是一份精简但可跑通的示例：

name: sql-review version: 1.2.0 description: 对给定的MySQL查询语句执行索引失效风险、隐式类型转换和全表扫描风险检查 author: dev-skill-team license: MIT triggers: - "帮我检查SQL" - "review sql" - "这条查询会有问题吗" context: require: - "待检查的SQL语句" optional: - "表结构DDL" - "数据库版本" steps: - name: collect prompt: prompts/analyze.md - name: report prompt: prompts/report.md output: format: markdown sections: - "问题等级" - "风险描述" - "修改建议" - "示例改写"

你可能好奇context那一栏为什么重要。这是我从多次失败里学来的教训：模型在缺少表结构信息时，很大概率会根据字段名脑补类型，导致索引判断完全跑偏。所以我在optional里放了表结构DDL，并要求在收集阶段先判断上下文是否充足，不足时明确向用户追问，而不是硬着头皮分析。这一条规则，直接让技能产出的准确率上了一个台阶。

3.3 标准化的另一面：输出的一致性怎么保证

很多AI编程工具最大的问题不是"不会答"，而是"每次答得不一样"。今天让它生成错误处理代码，它给的是if err != nil；明天同样的需求它可能给你抛个panic；后天心情好，又开始自作主张上第三方库。

陌讯Skills对输出的一致性做了两层约束。第一层是output.sections字段——它规定报告必须包含哪几个小节，模型不能偷工减料。第二层是prompts里的"强约束语句"模板。比如sql-review的报告模板里规定：所有"修改建议"必须给出改写后的完整SQL和对应的EXPLAIN预期结果。这样下游消费报告的人就不用费力二次解析。

我举个直观对比。未封装成Skill之前，我让模型"检查一下SQL"，得到的是十几条笼统的建议："可能未走索引""建议添加LIMIT"。封装成Skill之后，同样一条SQL，输出被规整成一张包括风险等级、影响行数预判、改写SQL、改写前后执行计划对比的结构化Markdown报告。团队拿着这个报告，可以直接贴到工单评审环节。

4. 实战：从零封装一个"可上架"的Skill包

4.1 选题：什么样的任务才值得封装成Skill

动手之前先想清楚：不是所有AI需求都适合做成Skill。我自己定了一条判断线——要被封装的任务，必须满足三个条件：一是高频，这个任务你一个月至少会用到几次；二是稳定，任务的目标、步骤、交付物是相对明确的；三是可评审，输出结果能否被验证和判错。

拿"sql-review"来说，SQL审查在开发流程里几乎天天出现，审查步骤各团队都有固定套路，而且查出来的问题是客观可验证的，完全满足条件。相反，像"帮我头脑风暴一下产品名"这种开放发散任务，就不适合做成Skill——步骤和输出都不稳定，硬包装只会让模型束手束脚。

4.2 写schema：把步骤拆到"模型不会迷路"的程度

确定选题后，最关键的一步是把任务拆解成步骤。很多第一次做Skill的人在这里翻车——他们倾向于写一个大而全的提示词，试图让模型一步到位。结果就是模型要么丢失细节，要么把规则相互混淆。

我的拆法是把任务切成"收集—分析—生成—自检"四个阶段，每个阶段一个prompt文件。以sql-review为例：

• 分析阶段prompt开头先设定角色，然后要求逐条读取rules下的规则文件，并把规则的核心要点列成清单。
• 报告阶段prompt要求基于分析阶段的结论，按固定字段组织输出，并输出一条最佳改写方案。

这里有个细节值得注意：分析阶段的prompt不直接要求输出最终结论，只要求给出"证据链"——比如"该查询在order_id上使用了函数DATE()，导致索引失效，依据rules/index-usage.md第2条"。有了证据链，报告阶段就不会笔走龙蛇。

下面是analysis prompt的骨架：

你是一名资深数据库性能工程师。请按照rules目录下的规则，逐条分析用户提供的SQL。 约束： 1. 必须标注每一条风险对应的规则出处。 2. 若表结构DDL缺失，明确声明"缺少DDL，无法判断索引情况"，不得猜测。 3. 只输出风险点列表，不要输出修改方案。 输出格式： | 风险点 | 涉及规则 | 严重程度 | 证据 |

4.3 用陌讯CLI调试：test命令是真正的救星

写完Skill包，接下来是调试验证。陌讯生态提供了一个命令行工具，我把最常用的三条命令先亮出来：

# 在本地运行一次技能，模拟线上完整流程 陌讯 skill run sql-review -i "select * from orders where year(create_time)=2024" # 跑测试集，检查输出是否与预期结果一致 陌讯 skill test sql-review # 打包并预览即将发布的内容 陌讯 skill pack sql-review --check

skill test是我练习使用频率最高的命令。它做的事情很简单：读取tests目录下的case文件，依次执行Skill，再和expected.json里的人工期望做对比。对比不是靠字符串匹配，而是用语义相似度加字段级校验：报告里是否出现了"索引失效"、是否给出了"改写SQL"、风险等级是否标对。只要有一个字段缺失，测试就报红。

我一开始写测试用例时潦草得很，只塞了两条简单SQL。后来被一个线上事故教训了——一个性能很差的NOT LIKE查询，我的Skill压根没检出来。补齐测试用例，把它明确列为"中缀通配符不得出现在LIKE模式开头"的case，再跑test，技能效果立竿见影。现在我的规则是：每个规则文件至少配两条正向用例和一条反向用例。

4.4 上架与发布：版本号、变更日志、许可证一个都不能少

打包发布这件事，听起来简单，踩坑的地方其实不少。陌讯Skills的生态仓库对发布包的检查相当严格，我第一次提交时就因为缺变更日志被拒了。

发布前建议按这个清单自查：

• 版本号遵循语义化版本规则，破坏兼容性的改动必须升大版本。
• CHANGELOG里写明本次变更点和受影响规则。
• license字段不能空缺，团队内部使用也建议显式声明。

  注意：涉及敏感业务内部信息的规则，一定不要写进公开包。

• description字段写清楚这个Skill不能做什么，减少误触发。例如sql-review的description里我特意加了一句"不适用于PostgreSQL，仅限MySQL"。

实测下来，生态对description的要求比我想象的高。它不只是给人看的，模型判断一个请求要不要激活某个Skill时，description是重要依据。写得太宽泛，模型会把不相关的请求也路由过来，消耗上下文还容易误报。

5. 团队落地与常见问题：我替你们把坑踩平了

5.1 团队引入Skill时最容易踩的五个坑

陌讯Skills在个人开发者手里通常上手很快，难的是团队落地。我把在几个项目里踩过的坑整理成了一张对照表，目的不是吓唬人，是帮你提前绕开：

其中版本锁pin这件事，我特别多说两句。AI编程领域的Skill和普通依赖库一样，升级可能是惊喜也可能是惊吓。我经历过一次：把sql-review从1.1升到1.2，新增了"隐式类型转换"检查规则，结果之前一个正常通过的兼容性报告突然多了一堆红字警告。不是规则错了，而是新规则覆盖了我没预料到的场景。如果没有锁版本，团队其他成员拉取到新版本时，就会看到不同的审查结果，沟通成本一下子就上来了。

5.2 效果不佳时，先排查这五个环节

Skill上线后表现不稳定，别急着怪模型。九成问题出在包本身。我总结了一套排查顺序：

1. 触发是否准确：整句输入和短指令的触发率有明显差异，检查description和triggers是否覆盖了团队习惯用语。
2. 上下文是否完整：很多审查类Skill报告缺失关键信息，是因为用户没有提供DDL或环境信息。
3. 步骤是否越级：模型动不动就"发挥"直接给结论，很可能是分析阶段和报告阶段的边界描述不够强硬。
4. 规则是否互相冲突：两个规则文件可能同时对同一场景给出相反判断。
5. 示例是否带偏：示例里的写法如果太"标准"，会让模型忽略现实中的杂音。

针对第4点，我现在的做法是在rules目录里加一个conflicts.md专门记录规则之间的关系。比如索引失效规则和隐式类型转换规则经常出现在同一条SQL上，我会在conflicts.md里写明判定优先级：先报类型转换，再报索引失效。不加这个说明，模型给出的风险列表经常分不清主次。

5.3 检查单：一个干净Skill包的"出厂标准"

结合上面所有经验，我整理了一份自我检查单，每次发布Skill前都会过一遍。这份清单对你也适用：

• 结构：目录包含skill.yaml、prompts、rules、tests，缺一不可。
• 描述：description字段讲清楚"做什么"和"不做什么"。
• 规则：每条规则有唯一编号、适用场景、判定条件和示例。
• 提示词：分步骤编写，每个prompt文件有明确输入输出说明。
• 测试：每个规则至少配两条通过用例和一条失败用例。
• 版本：每次改动更新版本号和CHANGELOG。
• 安全：不包含内部路径、密钥、代码片段中的敏感信息。
• 兼容：声明适用的开发语言、数据库版本、模型上下文窗口要求。

这份清单看起来严格，但它恰恰是陌讯Skills这套生态能在团队中站住脚的根本原因。没有这份"出厂标准"，一个Skill和一段随手写的提示词就没有本质区别。

6. 实践以后的个人体会

用陌讯Skills改造我们团队的AI编程流程已有大半年，最大的感受是：标准化带来的不只是效率，更是"安全感"。以前AI辅助编码像抽奖，同样的需求今天中奖明天翻车；现在借助Skill体系，至少团队内部的核心任务有了一条可控的、可追踪、可回滚的AI执行路径。

我特别想分享一个也许有些反常识的经验：Skill包的维护成本，远高于创建成本。真正拉开差距的不是谁写出了惊艳的提示词，而是谁在持续沉淀规则、更新测试用例、处理边界场景。我们团队每个Skill都有一位明确的"owner"，负责收集中午走查时发现的新问题，并把它固化成新规则。这个机制运行一个月后，sql-review的准确率从最初的七成提升到了九成以上，提升几乎全部来自持续的小版本迭代。

所以，如果你正准备进入AI编程Skill这个领域，我的建议是：不要一上来就追求做一个"全能王"技能，而是从自己团队最高频、最痛的那个点切入，把它做成标准件，用测试锁住行为，在真实项目里跑一个月再回头看收益。陌讯Skills现在生态里已经积累了覆盖代码生成、重构、审查、文档、测试等多种场景的技能包，直接拿来用是入门最快的路径，但真正让你团队受益的，一定是把自己沉淀出的规范也做成Skill，让AI真正理解你们的工作方式。