**导读**你会写 Skill 吗这道题在 AI 应用岗面试里出现频率越来越高但大多数人的回答只能得个知道这个东西的基础分。本文把这道题从认知到工程完整打通——帮你从我写过 Skill答到让面试官掏出本子记下来的水平。零基础友好含可直接抄的 Skill 模板。一、同一道题两种回答差距在哪里有读者发来一道字节的 AI 工程岗面试题“你的 Agent 系统里面Skill 是怎么编写的你怎么保证一个 Skill 是高质量的”他说自己当时回答了一通但明显感觉面试官不太满意。他的答案大概是这样的“就是给 AI 写指令嘛用 Markdown 文件告诉 AI 什么时候触发然后告诉它怎么做……”面试官点点头然后追了一句“那你觉得好不好的核心标准是什么”沉默了。小编帮他把答案重新梳理了一遍。好的回答应该是这样的“我不会把 Skill 简单理解成 Prompt 模板而是把它看成 Agent 系统中可复用的任务能力单元。一个高质量 Skill 应该包含触发条件、专家决策逻辑、反模式约束、资源导航、验证闭环和持续迭代机制。它的目标不是让 Agent 偶尔答得好而是让 Agent 在一类任务上稳定、可控、可复用地完成工作。”这两个回答差距就在这里。今天这篇把完整方法拆开讲。“Skill 写得好不好本质上是一道信息架构题而不是一道’指令是否清晰’的文案题。”二、面试官真正在考察什么这道题表面问 Skill实际上考察的是Agent 工程化能力可以拆成三层考察层次面试官真正想听什么任务抽象能力你能否判断什么任务适合 Skill 化什么任务不适合专家经验沉淀能力你能否把人的判断规则、决策树写进 Skill质量保障能力你有没有验证、评测和持续迭代机制不要一上来就说我会写 SKILL.md。先展示你对这三层的理解再说具体怎么做面试官才会觉得你是工程化思维而不是只会用工具。三、第一步写之前先判断——这个任务值不值得 Skill 化很多团队刚开始做 Agent容易犯一个错误什么任务都往 Skill 里塞。但 Skill 不是免费的——需要写说明、配脚本、放参考资料、做测试验证还要随着业务持续迭代。Skill 不是越多越好能稳定解决高价值重复问题才重要。判断公式值得做成 Skill 反复出现每天/每周都会碰到 足够复杂一句 Prompt 说不清楚 有专家判断熟手 vs 新手差距很大 对输出质量有要求反例不适合 Skill 化• “帮我把这段话翻译成英文” → 一句 Prompt 搞定不需要 Skill• 临时的 one-off 任务 → 没有复用价值封装了也白封装正例适合 Skill 化•writing-commit-messages每次提交代码都要写好的 commit message 需要判断类型feat/fix/chore、确定 scope、用一句话说清楚为什么改而不只是改了什么——熟手和新手写出来差距很大值得沉淀•reviewing-prs代码 Review 包含大量隐性判断安全风险、性能影响、边界处理每周都在做老工程师和新人的 Review 质量天差地别能说出这个前置判断就已经和大多数候选人拉开差距了。四、第二步写什么——不是给人写说明书是给 AI 写判断规则这是最容易翻车的一步。4.1 先破一个认知误区大多数人写 Skill 的姿势是这样的---name: code-reviewdescription: 代码审查技能---## 背景本技能基于团队多年的代码审查经验总结而成旨在提升代码质量。## 审查原则- 保持专业、建设性的语气- 关注代码质量而非个人风格- 平衡严格性和灵活性## 版本记录- v1.0: 初始版本如果这是给团队新人看的文档写得挺好的。但Skill 的读者是 AI不是人。内容为什么对 AI 没用“基于团队多年的代码审查经验”AI 不关心来源只关心现在该怎么做“保持专业、建设性的语气”专业对 AI 是无限大的可行域每次输出都不一样“平衡严格性和灵活性”AI 没有这个直觉这句话等于没说版本记录AI 每次被唤醒都是全新的v1.0 还是 v1.1 对它毫无意义问题不在于写得不够多而在于写错了对象。4.2 核心写专家决策树不是写流程说明Skill 最值钱的部分是告诉 AI•什么情况下走方案 A•什么情况下切到方案 B•什么情况下必须先补充信息再继续•什么情况下直接停止、不得执行以reviewing-prs为例差的写法对代码改动进行 Review给出改进建议。好的写法是把专家判断拆成可执行的条件分支当改动涉及数据库操作时- 必须检查 SQL 注入风险- 必须检查是否有事务保障- 必须确认索引使用合理不得全表扫描当改动涉及认证或权限逻辑时- 必须验证权限边界是否完整- 必须检查 token 有效期和异常处理- 不得跳过最小权限原则校验当 diff 行数超过 500 行时- 必须要求拆分为更小的 PR 再 Review- 不得对超大 diff 直接出意见质量无法保证当发现安全漏洞或数据泄露风险时- 必须立即标记为 Blocker- 不得给出可以合并的结论这才是把老工程师的经验沉淀进 Skill 的正确姿势。4.3 写约束时不做什么比做什么更精确大模型很容易为了完成任务而过度发挥——补充不存在的信息、跳过验证步骤、输出一堆没有优先级的内容。Skill 里必须明确反模式## 禁止行为- 不要把猜测的意图当成事实写进 Review 意见- 不要在缺少上下文时直接给结论应先提问- 不要把所有问题都标成同等优先级——必须区分 Blocker / Warning / Suggestion- 不要在发现安全问题时仍然给出approve每一条都是具体的、可检测的。做什么 → 描述无限大的可行域 → AI 随机游走不做什么 → 在可行域上画边界 → AI 的行为被收窄到你想要的范围五、第三步怎么组织——三级架构不要全塞一个文件一句话定义Skill 是一个文件夹里面装着指令文档、参考资料和可执行脚本。AI 拿到它就能胜任一项原本不会的特定工作。你可以把它理解成给 AI 装了一个能力插件——像给 PS 装滤镜包插上就多一项专长拔掉回到通用模式。三级分层加载L1frontmattername description → 始终在上下文约 100 词 → 唯一功能决定要不要触发这个 SkillL2SKILL.md body专家决策树 资源导航 → 触发后才加载控制在 500 行以内 → 告诉 AI 具体怎么做、怎么判断L3scripts / references / assets → 按需使用无上限 → scripts 执行但不读入零 token 成本三层的本质让每个信息在正确的时机出现而不是一股脑堆在上下文里。“上下文窗口不是你家的是公共资源。每一句话都要值得它占用的 token。”所以 Skill 里不该有这些文件❌ README.md — 给人看的AI 不需要❌ CHANGELOG.md — AI 每次唤醒都全新的版本记录没意义❌ QUICK_REFERENCE.md — 文档是给人扫的不是给 AI 的四种 L3 资源的本质区别资源类型放什么AI 怎么用scripts/可执行代码执行不读入零 token 成本references/规则、文档、Schema读入上下文辅助思考assets/模板、图片、样板文件直接用在输出里无需读懂agents/openai.yamlUI 元数据给界面看AI 不读references 渐进式披露规则Pattern 1 — 核心流程放 body细节链接到文件最常用## 高级操作→ [AUTH.md](references/AUTH.md) — OAuth 鉴权完整指南→ [RATE_LIMIT.md](references/RATE_LIMIT.md) — 限流策略参考Pattern 2 — 按领域拆分多维度 Skilldata-analysis-skill/references/├── sql-patterns.md ← 用户问 SQL 相关时只读这个├── chart-types.md ← 用户问可视化时只读这个└── statistics.md ← 用户问统计分析时只读这个⚠️ **重要规则references 只能一层深度。**不能 SKILL.md → A.md → B.mdClaude 遇到嵌套引用时会用head -100预览而非读完整文件导致信息不完整。所有参考文件必须从 SKILL.md 直接链接。六、第四步高风险低自由度分析类高自由度不同类型的任务对 AI 的自由度要求不一样。高风险任务必须降低自由度数据库迁移、线上配置修改、批量文件操作、CI/CD 发布这类任务不能让 AI 自由发挥。Skill 里必须明确写死约束## 高风险操作规则执行任何修改前必须先输出执行计划计划必须包含- 修改的文件或资源及原因- 影响范围评估- 验证方式- 回滚方案未经确认不得直接执行。执行后必须立即运行验证命令。验证失败必须停止输出失败原因不得继续下一步。面试中说出先控风险再做执行能展示你对 Agent 安全边界有实际思考。分析类任务保留合理自由度代码 Review、技术方案评估、架构分析这类任务约束太死反而会降低输出质量。这类 Skill 更适合规定分析框架而不是锁死步骤分析必须覆盖四个维度风险、收益、成本、落地难度。必须给出优先级排序不能一视同仁。不确定的信息必须单独标注不得以猜测代替事实。结论必须有依据不能只给判断。判断标准两个问题**做错了后果多严重**→ 越严重越低自由度**有多少种正确的做法**→ 越多越高自由度七、代码实战从零写一个高质量 Skill以writing-commit-messagesSkill 为例演示四个关键步骤。步骤一frontmatter 写法❌ 常见错误写法---name: commit-helperdescription: 我可以帮你写 commit message。---两个问题description 用了第一人称——description 会被注入 system prompt用我会导致人称混乱影响触发判断没有说什么时候用AI 无法判断用户说帮我提交代码到底要不要触发✅ 正确写法---name: writing-commit-messagesdescription: - Generates descriptive and well-structured Git commit messages by analyzing staged changes or diffs. Use when the user asks for help writing commit messages, wants to commit code, or needs to review staged changes for a summary.---三个关键点•命名用动名词形式writing-commit-messages而不是commit-helper或commitTool•第三人称描述“Generates…”不要我可以…•包含触发场景“Use when…”明确什么时候用命名规范只能用小写字母 数字 连字符≤ 64 字符不能含 “anthropic” 或 “claude”。步骤二脆弱操作交给脚本读取 git diff 是一个确定性操作每次结果必须一致适合脚本化# scripts/get_staged_diff.py# 获取当前暂存区的 diff供 AI 分析import subprocessimport sysdef get_staged_diff(): result subprocess.run( [git, diff, --cached, --stat], capture_outputTrue, textTrue ) if result.returncode ! 0: print(f❌ 错误{result.stderr}, filesys.stderr) sys.exit(1) diff subprocess.run( [git, diff, --cached], capture_outputTrue, textTrue ).stdout print(diff)if __name__ __main__: get_staged_diff()运行结果diff --git a/src/auth.py b/src/auth.pyindex 3a2b1c..5e8f2d 100644--- a/src/auth.py b/src/auth.py -12,6 12,10 class AuthService:...AI 拿到这份 diff结合 Skill 里的决策规则生成规范的 commit message。步骤三body 写决策规则 复杂工作流这是小编自己项目里用的 body 写法重点看工作流 Checklist的设计# Writing Commit MessagesAnalyze git diffs and generate descriptive commit messages.## Commit FormatUse Conventional Commits format:type(scope): short descriptionoptional body: explain WHY, not WHATTypes: feat / fix / refactor / chore / docs / test / perf## Decision RulesWhen diff touches authentication or permissions:- Type must be fix or feat, never chore- Body must explain security implicationWhen diff is larger than 300 lines:- Ask: This diff is large. Should I split it into multiple commits?- Do NOT generate a single commit for oversized diffsWhen diff only changes formatting/whitespace:- Type must be style or chore- Do NOT describe as fix or feat## Workflow: Commit with Staged ChangesCopy this checklist and check off as you go:Commit Progress:• Step 1: Run get_staged_diff.py to get current diff• Step 2: Identify changed files and understand intent• Step 3: Determine commit type and scope• Step 4: Draft short description (≤72 chars, imperative mood)• Step 5: Write body if change needs explanation (why, not what)• Step 6: Review against Conventional Commits rules• Step 7: Output final messageWork through each step in order. Do not skip Step 2 — understandingintent is the most common failure point.## Common Pitfalls- Do NOT describe what changed (thats in the diff); describe WHY- Do NOT use past tense (Added) — use imperative (Add)- Do NOT omit scope when multiple modules are touched两个设计重点① 复杂工作流用 Checklist对于多步骤的复杂操作在 Skill 里提供一个 Checklist——AI 在回复时可以把它复制出来边执行边打勾。好处是• AI 不会漏步骤Step 2 是最容易被跳过的• 用户能清楚看到 AI 执行到哪里了• 如果中途失败可以从失败的步骤重新继续这个模式对任何多步骤任务都适用数据处理、文档生成、部署流程……只要步骤数 ≥ 3 且顺序重要就应该考虑 Checklist。② 验证循环每个关键步骤后必须验证Validation rule: If any step produces unexpected output,stop and report the issue. Do NOT proceed to next step.run → fix → repeat只有通过才继续这是防止错误链式传播的核心机制。步骤四A-B 迭代测试写完 Skill 之后用两个独立的 Claude 实例来测试•Claude A写 Skill 的实例帮你分析和改进 Skill 内容•Claude B用 Skill 的实例加载 Skill 后执行真实任务观察 Claude B 的行为• 有没有漏掉 Checklist 里的某一步• 有没有在不该触发的场景下触发• 有没有按照决策规则正确分类 commit type把观察结果带回给 Claude A“Claude B 在处理只改了注释的 diff 时把 type 定成了 fix应该是 chore——怎么在 Skill 里加强这个判断”这个循环才是让 Skill 质量真正提升的机制而不是凭感觉改。八、面试答题框架总结把整套思路收一下。这道题三层回答递进展开第一层认知层打破面试官预期“我不会把 Skill 简单理解成 Prompt 模板而是可复用的任务能力单元。目标不是让 Agent 偶尔答得好而是在一类任务上稳定、可控、可复用地完成工作。”第二层设计层体现工程化思维“高质量 Skill 的核心是三件事上下文成本意识三级分层加载description 用第三人称含 when-to-use、专家判断沉淀条件决策树 反模式约束而不是流程说明、自由度匹配高风险任务先输出计划再执行分析任务保留框架自由度。”第三层工程层展示实操经验“落地要配质量保障链脆弱操作脚本化、复杂工作流用 Checklist 防漏步骤、验证循环强制通过后才继续最后用 A-B 双实例测试迭代而不是凭感觉改。”这道题基础分是我写过 Skill高分是说出三级架构顶分是把决策树、自由度光谱、Checklist 工作流和 A-B 迭代都说清楚——说明你不只是会写还真的在项目里打磨过。“Skill 写得好不好本质上是一道信息架构题而不是文案题。”这一句话就能让面试官知道你不是刚入门的选手。你有没有踩过 Skill 的坑description 写错了导致没触发或者 body 写了一堆但 AI 就是不按预期来学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
字节面试题：怎么写好一个 Skill？这套回答让面试官连追三问
发布时间：2026/7/23 2:34:35
**导读**你会写 Skill 吗这道题在 AI 应用岗面试里出现频率越来越高但大多数人的回答只能得个知道这个东西的基础分。本文把这道题从认知到工程完整打通——帮你从我写过 Skill答到让面试官掏出本子记下来的水平。零基础友好含可直接抄的 Skill 模板。一、同一道题两种回答差距在哪里有读者发来一道字节的 AI 工程岗面试题“你的 Agent 系统里面Skill 是怎么编写的你怎么保证一个 Skill 是高质量的”他说自己当时回答了一通但明显感觉面试官不太满意。他的答案大概是这样的“就是给 AI 写指令嘛用 Markdown 文件告诉 AI 什么时候触发然后告诉它怎么做……”面试官点点头然后追了一句“那你觉得好不好的核心标准是什么”沉默了。小编帮他把答案重新梳理了一遍。好的回答应该是这样的“我不会把 Skill 简单理解成 Prompt 模板而是把它看成 Agent 系统中可复用的任务能力单元。一个高质量 Skill 应该包含触发条件、专家决策逻辑、反模式约束、资源导航、验证闭环和持续迭代机制。它的目标不是让 Agent 偶尔答得好而是让 Agent 在一类任务上稳定、可控、可复用地完成工作。”这两个回答差距就在这里。今天这篇把完整方法拆开讲。“Skill 写得好不好本质上是一道信息架构题而不是一道’指令是否清晰’的文案题。”二、面试官真正在考察什么这道题表面问 Skill实际上考察的是Agent 工程化能力可以拆成三层考察层次面试官真正想听什么任务抽象能力你能否判断什么任务适合 Skill 化什么任务不适合专家经验沉淀能力你能否把人的判断规则、决策树写进 Skill质量保障能力你有没有验证、评测和持续迭代机制不要一上来就说我会写 SKILL.md。先展示你对这三层的理解再说具体怎么做面试官才会觉得你是工程化思维而不是只会用工具。三、第一步写之前先判断——这个任务值不值得 Skill 化很多团队刚开始做 Agent容易犯一个错误什么任务都往 Skill 里塞。但 Skill 不是免费的——需要写说明、配脚本、放参考资料、做测试验证还要随着业务持续迭代。Skill 不是越多越好能稳定解决高价值重复问题才重要。判断公式值得做成 Skill 反复出现每天/每周都会碰到 足够复杂一句 Prompt 说不清楚 有专家判断熟手 vs 新手差距很大 对输出质量有要求反例不适合 Skill 化• “帮我把这段话翻译成英文” → 一句 Prompt 搞定不需要 Skill• 临时的 one-off 任务 → 没有复用价值封装了也白封装正例适合 Skill 化•writing-commit-messages每次提交代码都要写好的 commit message 需要判断类型feat/fix/chore、确定 scope、用一句话说清楚为什么改而不只是改了什么——熟手和新手写出来差距很大值得沉淀•reviewing-prs代码 Review 包含大量隐性判断安全风险、性能影响、边界处理每周都在做老工程师和新人的 Review 质量天差地别能说出这个前置判断就已经和大多数候选人拉开差距了。四、第二步写什么——不是给人写说明书是给 AI 写判断规则这是最容易翻车的一步。4.1 先破一个认知误区大多数人写 Skill 的姿势是这样的---name: code-reviewdescription: 代码审查技能---## 背景本技能基于团队多年的代码审查经验总结而成旨在提升代码质量。## 审查原则- 保持专业、建设性的语气- 关注代码质量而非个人风格- 平衡严格性和灵活性## 版本记录- v1.0: 初始版本如果这是给团队新人看的文档写得挺好的。但Skill 的读者是 AI不是人。内容为什么对 AI 没用“基于团队多年的代码审查经验”AI 不关心来源只关心现在该怎么做“保持专业、建设性的语气”专业对 AI 是无限大的可行域每次输出都不一样“平衡严格性和灵活性”AI 没有这个直觉这句话等于没说版本记录AI 每次被唤醒都是全新的v1.0 还是 v1.1 对它毫无意义问题不在于写得不够多而在于写错了对象。4.2 核心写专家决策树不是写流程说明Skill 最值钱的部分是告诉 AI•什么情况下走方案 A•什么情况下切到方案 B•什么情况下必须先补充信息再继续•什么情况下直接停止、不得执行以reviewing-prs为例差的写法对代码改动进行 Review给出改进建议。好的写法是把专家判断拆成可执行的条件分支当改动涉及数据库操作时- 必须检查 SQL 注入风险- 必须检查是否有事务保障- 必须确认索引使用合理不得全表扫描当改动涉及认证或权限逻辑时- 必须验证权限边界是否完整- 必须检查 token 有效期和异常处理- 不得跳过最小权限原则校验当 diff 行数超过 500 行时- 必须要求拆分为更小的 PR 再 Review- 不得对超大 diff 直接出意见质量无法保证当发现安全漏洞或数据泄露风险时- 必须立即标记为 Blocker- 不得给出可以合并的结论这才是把老工程师的经验沉淀进 Skill 的正确姿势。4.3 写约束时不做什么比做什么更精确大模型很容易为了完成任务而过度发挥——补充不存在的信息、跳过验证步骤、输出一堆没有优先级的内容。Skill 里必须明确反模式## 禁止行为- 不要把猜测的意图当成事实写进 Review 意见- 不要在缺少上下文时直接给结论应先提问- 不要把所有问题都标成同等优先级——必须区分 Blocker / Warning / Suggestion- 不要在发现安全问题时仍然给出approve每一条都是具体的、可检测的。做什么 → 描述无限大的可行域 → AI 随机游走不做什么 → 在可行域上画边界 → AI 的行为被收窄到你想要的范围五、第三步怎么组织——三级架构不要全塞一个文件一句话定义Skill 是一个文件夹里面装着指令文档、参考资料和可执行脚本。AI 拿到它就能胜任一项原本不会的特定工作。你可以把它理解成给 AI 装了一个能力插件——像给 PS 装滤镜包插上就多一项专长拔掉回到通用模式。三级分层加载L1frontmattername description → 始终在上下文约 100 词 → 唯一功能决定要不要触发这个 SkillL2SKILL.md body专家决策树 资源导航 → 触发后才加载控制在 500 行以内 → 告诉 AI 具体怎么做、怎么判断L3scripts / references / assets → 按需使用无上限 → scripts 执行但不读入零 token 成本三层的本质让每个信息在正确的时机出现而不是一股脑堆在上下文里。“上下文窗口不是你家的是公共资源。每一句话都要值得它占用的 token。”所以 Skill 里不该有这些文件❌ README.md — 给人看的AI 不需要❌ CHANGELOG.md — AI 每次唤醒都全新的版本记录没意义❌ QUICK_REFERENCE.md — 文档是给人扫的不是给 AI 的四种 L3 资源的本质区别资源类型放什么AI 怎么用scripts/可执行代码执行不读入零 token 成本references/规则、文档、Schema读入上下文辅助思考assets/模板、图片、样板文件直接用在输出里无需读懂agents/openai.yamlUI 元数据给界面看AI 不读references 渐进式披露规则Pattern 1 — 核心流程放 body细节链接到文件最常用## 高级操作→ [AUTH.md](references/AUTH.md) — OAuth 鉴权完整指南→ [RATE_LIMIT.md](references/RATE_LIMIT.md) — 限流策略参考Pattern 2 — 按领域拆分多维度 Skilldata-analysis-skill/references/├── sql-patterns.md ← 用户问 SQL 相关时只读这个├── chart-types.md ← 用户问可视化时只读这个└── statistics.md ← 用户问统计分析时只读这个⚠️ **重要规则references 只能一层深度。**不能 SKILL.md → A.md → B.mdClaude 遇到嵌套引用时会用head -100预览而非读完整文件导致信息不完整。所有参考文件必须从 SKILL.md 直接链接。六、第四步高风险低自由度分析类高自由度不同类型的任务对 AI 的自由度要求不一样。高风险任务必须降低自由度数据库迁移、线上配置修改、批量文件操作、CI/CD 发布这类任务不能让 AI 自由发挥。Skill 里必须明确写死约束## 高风险操作规则执行任何修改前必须先输出执行计划计划必须包含- 修改的文件或资源及原因- 影响范围评估- 验证方式- 回滚方案未经确认不得直接执行。执行后必须立即运行验证命令。验证失败必须停止输出失败原因不得继续下一步。面试中说出先控风险再做执行能展示你对 Agent 安全边界有实际思考。分析类任务保留合理自由度代码 Review、技术方案评估、架构分析这类任务约束太死反而会降低输出质量。这类 Skill 更适合规定分析框架而不是锁死步骤分析必须覆盖四个维度风险、收益、成本、落地难度。必须给出优先级排序不能一视同仁。不确定的信息必须单独标注不得以猜测代替事实。结论必须有依据不能只给判断。判断标准两个问题**做错了后果多严重**→ 越严重越低自由度**有多少种正确的做法**→ 越多越高自由度七、代码实战从零写一个高质量 Skill以writing-commit-messagesSkill 为例演示四个关键步骤。步骤一frontmatter 写法❌ 常见错误写法---name: commit-helperdescription: 我可以帮你写 commit message。---两个问题description 用了第一人称——description 会被注入 system prompt用我会导致人称混乱影响触发判断没有说什么时候用AI 无法判断用户说帮我提交代码到底要不要触发✅ 正确写法---name: writing-commit-messagesdescription: - Generates descriptive and well-structured Git commit messages by analyzing staged changes or diffs. Use when the user asks for help writing commit messages, wants to commit code, or needs to review staged changes for a summary.---三个关键点•命名用动名词形式writing-commit-messages而不是commit-helper或commitTool•第三人称描述“Generates…”不要我可以…•包含触发场景“Use when…”明确什么时候用命名规范只能用小写字母 数字 连字符≤ 64 字符不能含 “anthropic” 或 “claude”。步骤二脆弱操作交给脚本读取 git diff 是一个确定性操作每次结果必须一致适合脚本化# scripts/get_staged_diff.py# 获取当前暂存区的 diff供 AI 分析import subprocessimport sysdef get_staged_diff(): result subprocess.run( [git, diff, --cached, --stat], capture_outputTrue, textTrue ) if result.returncode ! 0: print(f❌ 错误{result.stderr}, filesys.stderr) sys.exit(1) diff subprocess.run( [git, diff, --cached], capture_outputTrue, textTrue ).stdout print(diff)if __name__ __main__: get_staged_diff()运行结果diff --git a/src/auth.py b/src/auth.pyindex 3a2b1c..5e8f2d 100644--- a/src/auth.py b/src/auth.py -12,6 12,10 class AuthService:...AI 拿到这份 diff结合 Skill 里的决策规则生成规范的 commit message。步骤三body 写决策规则 复杂工作流这是小编自己项目里用的 body 写法重点看工作流 Checklist的设计# Writing Commit MessagesAnalyze git diffs and generate descriptive commit messages.## Commit FormatUse Conventional Commits format:type(scope): short descriptionoptional body: explain WHY, not WHATTypes: feat / fix / refactor / chore / docs / test / perf## Decision RulesWhen diff touches authentication or permissions:- Type must be fix or feat, never chore- Body must explain security implicationWhen diff is larger than 300 lines:- Ask: This diff is large. Should I split it into multiple commits?- Do NOT generate a single commit for oversized diffsWhen diff only changes formatting/whitespace:- Type must be style or chore- Do NOT describe as fix or feat## Workflow: Commit with Staged ChangesCopy this checklist and check off as you go:Commit Progress:• Step 1: Run get_staged_diff.py to get current diff• Step 2: Identify changed files and understand intent• Step 3: Determine commit type and scope• Step 4: Draft short description (≤72 chars, imperative mood)• Step 5: Write body if change needs explanation (why, not what)• Step 6: Review against Conventional Commits rules• Step 7: Output final messageWork through each step in order. Do not skip Step 2 — understandingintent is the most common failure point.## Common Pitfalls- Do NOT describe what changed (thats in the diff); describe WHY- Do NOT use past tense (Added) — use imperative (Add)- Do NOT omit scope when multiple modules are touched两个设计重点① 复杂工作流用 Checklist对于多步骤的复杂操作在 Skill 里提供一个 Checklist——AI 在回复时可以把它复制出来边执行边打勾。好处是• AI 不会漏步骤Step 2 是最容易被跳过的• 用户能清楚看到 AI 执行到哪里了• 如果中途失败可以从失败的步骤重新继续这个模式对任何多步骤任务都适用数据处理、文档生成、部署流程……只要步骤数 ≥ 3 且顺序重要就应该考虑 Checklist。② 验证循环每个关键步骤后必须验证Validation rule: If any step produces unexpected output,stop and report the issue. Do NOT proceed to next step.run → fix → repeat只有通过才继续这是防止错误链式传播的核心机制。步骤四A-B 迭代测试写完 Skill 之后用两个独立的 Claude 实例来测试•Claude A写 Skill 的实例帮你分析和改进 Skill 内容•Claude B用 Skill 的实例加载 Skill 后执行真实任务观察 Claude B 的行为• 有没有漏掉 Checklist 里的某一步• 有没有在不该触发的场景下触发• 有没有按照决策规则正确分类 commit type把观察结果带回给 Claude A“Claude B 在处理只改了注释的 diff 时把 type 定成了 fix应该是 chore——怎么在 Skill 里加强这个判断”这个循环才是让 Skill 质量真正提升的机制而不是凭感觉改。八、面试答题框架总结把整套思路收一下。这道题三层回答递进展开第一层认知层打破面试官预期“我不会把 Skill 简单理解成 Prompt 模板而是可复用的任务能力单元。目标不是让 Agent 偶尔答得好而是在一类任务上稳定、可控、可复用地完成工作。”第二层设计层体现工程化思维“高质量 Skill 的核心是三件事上下文成本意识三级分层加载description 用第三人称含 when-to-use、专家判断沉淀条件决策树 反模式约束而不是流程说明、自由度匹配高风险任务先输出计划再执行分析任务保留框架自由度。”第三层工程层展示实操经验“落地要配质量保障链脆弱操作脚本化、复杂工作流用 Checklist 防漏步骤、验证循环强制通过后才继续最后用 A-B 双实例测试迭代而不是凭感觉改。”这道题基础分是我写过 Skill高分是说出三级架构顶分是把决策树、自由度光谱、Checklist 工作流和 A-B 迭代都说清楚——说明你不只是会写还真的在项目里打磨过。“Skill 写得好不好本质上是一道信息架构题而不是文案题。”这一句话就能让面试官知道你不是刚入门的选手。你有没有踩过 Skill 的坑description 写错了导致没触发或者 body 写了一堆但 AI 就是不按预期来学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
![[Android] 可视化音乐制作 -短视频超火的音乐视频制作工具](http://pic.xiahunao.cn/yaotu/[Android] 可视化音乐制作 -短视频超火的音乐视频制作工具)
