从 2024 年到 2026 年AI Coding 领域最明显的一个变化是大家讨论的重心从“哪个工具补全代码更准”慢慢变成了“怎么让 AI Agent 真正把活干完”。补全一段函数是效率工具但一个需求从拆解、编码、构建、验证到交付文档中间能少掉多少次人工介入才是真正的工程效率。很多人开始发现AI 生成代码很容易让 AI “负责任的干活”却很难。上下文一换、环境一变、验证环节一缺AI 生成的东西就变成了一个需要你去“收拾残局”的半成品。这篇文章要聊的 Do Work Skill就是针对这个问题的一套解决方案。它不是某个具体产品的功能开关而是一种把 AI Coding 从“一次性问答”升级为“可复用工作技能”的工程化方法。读完你可以理解它的核心设计并按步骤构建出一个真正能跑通、能验证、能回滚的 AI Coding 工作流。1. 这篇文章真正要解决的问题先对号入座。如果你属于下面任何一类开发者这篇文章值得继续读第一类团队已经买了 Copilot 或 Claude 这类 AI 编程工具但大家用下来发现AI 只能帮忙写点函数、补点测试遇到跨模块、多文件的完整需求AI 给出的结果依然难以直接信任。团队提效不明显工具费用倒是很实在。第二类你在研究 AI Coding Agent发现现在工具很多有偏向聊天的、有偏向终端自动执行的、有偏向 IDE 插件的。但每个工具都有自己的上下文管理方式、工具调用机制和权限模型很难统一沉淀成团队的工程资产。每个工程师都在用但每个人用的方式都不一样。第三类你想在团队里推动“AI 驱动开发流程”但不知道从哪里开始。是继续用 Vibe Coding 那种“边聊边写”的方式还是建立更严格的技能封装这两种方式的适用边界在哪里这篇文章的核心判断是AI Coding 真正的提效不在单次对话的“生成质量”而在把高频任务封装成可复用、可验证、可回滚的 Do Work Skill。什么意思当一个任务被封装成 SkillAI 不再是“临时发挥”而是进入一条固定的工作流理解任务、读取上下文、调用工具、执行迁移或生成、跑验证、输出结构化结果。人只在关键节点介入。这样AI 从“一个聪明的实习生”变成了“一个稳定的自动化同事”。读完这篇文章你可以解决以下问题理解 Do Work Skill 和普通 Prompt、Agent 工作流的区别掌握一个 Do Work Skill 的基本组成部分和设计原则从零实现一个“数据库迁移脚本生成与验证”的真实 Skill知道怎么接入主流的 AI Coding Agent 并验证效果避开权限、回滚、上下文污染等常见工程坑。2. AI Coding 为什么需要 Do Work Skill2.1 从 AI Coding 到 AI Coding Agent先统一概念。AI Coding 是一个很宽泛的范畴从早期 IDE 里的代码补全到今天能自动操作终端的 Agent都算 AI Coding。很多人不理解为什么 2026 年大家都在谈 Agent因为补全只解决了“怎么写一行代码”的问题而 Agent 要解决的是“怎么完成一个任务”的问题。举个例子。一个简单的迭代任务是“给用户表增加乐观锁字段版本号并同步更新所有涉及用户更新的 SQL”。传统补全工具只能帮你把ALTER TABLE写出来。但 AI Coding Agent 需要完成的是找到用户表相关的建表脚本生成合理的ALTER TABLE语句扫描项目中所有用户更新 SQL把缺少版本号条件的地方改掉跑一遍相关测试确认没有破坏现有行为。这个过程涉及“读代码—写代码—执行命令—看结果—修复错误”的循环。Agent 需要自己管理上下文、调用工具、判断下一步动作。2026 年行业里大量讨论的 AI Coding Agent核心能力就是这个循环能不能跑得稳。2.2 什么是 Skill 机制再收窄一层。Skill 机制是近年来 AI Coding 工具的一个重要演进方向。它的基本思路是把某一个领域的任务执行经验封装成一个可以被 Agent 加载的“技能包”。Skill 和普通 Prompt 的关键区别在于Skill 不只是“一段话”。它通常包含任务的输入输出定义执行步骤的描述需要调用的命令、工具或 API验证和修复的规则可以复用的模板、脚本和知识文档。可以把它理解为一个“岗位说明书 操作手册 工具清单”的组合。Agent 加载某个 Skill 后不是凭记忆随口回答而是按着这套操作流程去执行。2.3 Do Work Skill 的定义Do Work Skill 是我对这类技能包的一个强调性叫法重点在 Do Work 这两个词。它强调的不是“生成”而是“交付”。一个合格的 Do Work Skill必须具备四个特征第一个是结果导向。AI 执行完技能之后必须产出可验证的交付物比如 SQL 脚本、代码 diff、测试报告而不是只说一句“我已经完成了”。第二个是工具闭环。Skill 必须真实调用开发工具链比如执行git diff、跑pytest、执行sqlfluff lint让 AI 的每一步判断都有真实环境反馈而不是靠“想象”。第三个是可回滚。执行任务前要能备份或建立检查点执行失败时能恢复到原状态。这一条在生产环境尤其重要。第四个是可复用。同一个 Skill 可以被不同项目、不同成员调用输入是标准化的输出也是标准化的。这样团队才能不断沉淀自己的 AI 工作资产。说得直白一点没有 Do Work Skill 的 AI Coding是让 AI 帮你写代码有了 Do Work Skill 的 AI Coding是让 AI 在一个可控的流程里帮你把活干完。3. 为什么“会生成代码”不等于“会干活”3.1 生成只是工作链条的第一环很多团队在对比 AI Coding 工具时只关注“生成代码的质量”。这个指标有参考价值但不是决定性因素。真实开发工作是一个完整链条需求拆解 → 方案选型 → 环境准备 → 代码实现 → 静态检查 → 单元测试 → 构建部署 → 文档沉淀。AI 生成代码只覆盖了中间“代码实现”这一环。如果 AI 只是生成一段代码放在那里后面几环依然要人来做那么它解决的只是“打字”这个环节的提效。而打字本来就不是工程师最大的成本。真正的成本在理解需求、排查环境、修复 bug、验证行为。这就是为什么很多团队发现AI 补全率 40%这种数字很好看实际迭代速度却没快多少。因为瓶颈不在键盘上。3.2 单次对话为什么不可靠再往深一层看。如果让 AI Agent 用聊天窗口直接去干活会遇到几个典型问题第一个是上下文断裂。一次真实任务可能需要读取几十个文件、执行几十条命令。Chat 模式的上下文是碎片化的AI 很快会忘掉最开始确定的方案甚至会顺着错误的中间结果继续往下走。第二个是验证缺失。没有 Skill 约束时AI 生成的 SQL 可能没有测试过改动的代码可能没有跑过测试。AI 不会主动告诉你“我没有验证过”它只会给出看起来很完整的答案。第三个是工具权限模糊。Agent 到底能不能执行rm命令能不能操作数据库没有边界定义要么 AI 事事都问导致效率极低要么 AI 什么都敢动导致事故风险很高。第四个是没有回滚机制。Chat 模式下 AI 执行了一堆操作中途发现方案错了它不会像工程师那样“先把改动还原再重新尝试”而是往往在错误状态上继续叠加修补结果越补越乱。3.3 从 Vibe Coding 到 Engineering Workflow2025 年开始流行的 Vibe Coding本质是一种“沉浸在反馈循环里快速写代码”的体验。它对原型验证、个人项目很受用因为写错了可以随时重来不需要对稳定性负责。但到了真实工程里多人在一个仓库协作、数据库有线上数据、生产环境不允许反复试错Vibe Coding 的方式就撑不住了。2026 年 AI Coding 的一个明显转向就是从“随性生成”走向“Engineering Workflow”也就是把 AI 纳入已有的工程纪律代码评审、CI/CD、测试覆盖、权限控制。Do Work Skill 就是这条路上的一个关键载体。因为它把“AI 怎么干活”这件事从个人习惯变成了团队标准。4. Do Work Skill 核心架构与设计原则4.1 一个 Skill 的五层结构从工程实现角度看一个完整的 Do Work Skill 可以拆成五层层作用对应物任务定义层明确 Skill 能做什么、输入输出是什么skill.yaml上下文装配层收集完成任务的必要信息schema 读取脚本、代码扫描脚本执行编排层定义 AI 按什么步骤执行指令模板、步骤清单工具调用层让 AI 能真实操作环境CLI 脚本、测试命令验证回环层判断任务是否成功、失败怎么回滚验证脚本、回滚脚本很多团队做 AI Coding 落地方案时容易犯一个错误只写了“任务提示词”没有设计验证回环。结果 AI 生成了一堆代码团队还得安排一个人去逐行 review。那这个 Skill 就没有真正“干完活”只是把“写代码”变成了“改代码”成本并没有省下来。4.2 一个 Skill 的生命周期先看生命周期方便理解后面要写哪些文件触发任务 → 加载 Skill → 收集输入 → 生成执行计划 → 调用工具执行 → 自动验证 → 输出交付物 → 失败则修复或回滚 → 记录日志每个环节都可能需要人工介入但介入点应该是“审批”而不是“动手改”。比如生成迁移脚本后人工确认脚本内容没问题执行前人工确认环境正确执行失败且自动修复三次仍失败才需要人工介入排查。4.3 设计原则设计 Do Work Skill 时有五条原则比较重要。第一输入输出要显式声明。AI 是个没有记忆的组件Skill 的输入输出必须写在元数据里这样可以被其他工具调用也可以被测试。第二验证必须内建。一个没有验证步骤的 Skill 不是 Skill只是一个高级 Prompt。第三权限最小化。不要给 Agent 一把万能钥匙。执行数据库操作时用只读连接做预检用事务包裹变更回滚脚本独立存在。第四要给人留审批点。完全放权给 AI 执行生产环境操作是不负责任的。Skill 设计要能“暂停下来等确认”。第五可观测。每一步执行都要有日志AI 的每个动作都要能追踪否则出了问题你根本不知道 AI 做了什么。5. 开发环境与工具链5.1 基础环境本文的示例不依赖某个特定云平台只要你本机有常见的开发环境即可。版本请以实际项目为准这里给的是常见实践Python 3.10用于编写 Skill 的编排脚本sqlfluff用于 SQL 静态检查PostgreSQL 客户端 psql用于数据库验证任意支持 Skill 机制的 AI Coding AgentClaude Code、Cline、GLM Coding Plan 等Git例如使用 GitHub 作为项目仓库用于版本管理和回滚。如果你的技能包不是数据库迁移方向可以换成对应的 linter 和测试框架核心思想不变。5.2 工具选型建议工具选择上我更推荐选择那些支持“定义 skills/ 目录”的 Agent 工具。这类工具通常可以从项目目录里加载类似skill.yaml的配置文件并允许 Agent 在执行过程中调用本地的 shell 命令。如果你用的工具暂不支持标准 Skill 机制也不要紧。你依然可以把指令模板和脚本放到仓库指定目录通过自定义命令或 Prompt 引用的方式让 AI 加载。Do Work Skill 首先是一种工程组织方式其次才是工具接口。6. 完整示例构建“数据库迁移生成与验证”Skill这个章节我们做一个小而完整的实战构建一个名为db-migration的 Do Work Skill让 AI Coding Agent 完成“根据目标变更描述生成数据库迁移脚本并执行静态检查与事务验证”的任务。6.1 定义 Skill 元数据在项目根目录下创建skills/db-migration/skill.yaml文件name: db-migration description: 根据数据库变更需求生成迁移脚本并完成静态检查和事务验证 version: 1.0.0 author: team-database inputs: - name: source_schema type: string required: true description: 当前表结构信息可来自 schema.sql 或数据库导出结果 - name: target_changes type: string required: true description: 具体的变更需求例如“为 users 表增加 version 字段” outputs: - name: migration_script type: file path: output/migration.sql description: 生成的迁移脚本 - name: verify_report type: file path: output/verify_report.txt description: 校验报告包含 lint 和事务验证结果 tools: - sqlfluff - psql steps: - read_schema - generate_script - lint_script - verify_transaction - rollback_on_failure这个文件的作用是让 Agent 一看到db-migration这个任务就知道自己该收集什么输入、该用什么工具、最终要产出什么。没有这一层声明AI 很可能把source_schema理解成“提供一段样例即可”而不是去读真实的 schema 文件。6.2 编写执行指令模板在skills/db-migration/templates/task.md中定义 AI 的执行提示词# 数据库迁移脚本生成任务 你是一名资深数据库开发工程师。请严格按照以下步骤完成数据库迁移工作。 ## 输入 - 当前表结构见 {{ source_schema }} - 变更需求{{ target_changes }} ## 执行步骤 1. 分析变更需求对表结构、索引、外键和已有数据的影响。 2. 编写迁移脚本保存到 output/migration.sql。 3. 使用 sqlfluff 校验 SQL 语法和风格。 4. 在事务中执行迁移脚本验证失败时自动执行回滚脚本。 ## 强制规则 1. 必须在事务中执行禁止裸跑 DDL。 2. 禁止 DROP TABLE 操作禁用级联删除。 3. 迁移脚本必须包含回滚注释说明如何撤销。 4. 如果三次自动修复后仍然校验失败停止操作并输出错误报告。这里的关键是“把规则写清楚”。AI Agent 在缺少规则时会倾向于选择最直接的方案而数据库迁移最怕的就是“最直接的方案”把线上数据搞坏。另外步骤 4 的“三次自动修复”是一个常用保护机制。很多 Agent 框架支持自动重试但不限制重试次数就会在半路越偏越远。6.3 编写执行编排脚本为了让 Skill 可以被命令行调用也为了能和 Agent 的工具调用机制对接需要一个编排脚本。创建skills/db-migration/scripts/run_skill.py#!/usr/bin/env python3 import argparse import subprocess import sys from pathlib import Path ROOT Path(__file__).resolve().parents[1] OUTPUT_DIR ROOT / output OUTPUT_DIR.mkdir(exist_okTrue) def read_file(path: str) - str: return Path(path).read_text(encodingutf-8) def generate_migration(schema: str, changes: str) - str: # 在实际项目中这里可以调用 LLM也可以调用 Agent 工具的生成函数。 # 此处演示一个最小生成器便于跑通流程。 if version in changes and users in schema: return ( -- 为 users 表增加 version 字段\n BEGIN;\n ALTER TABLE users ADD COLUMN IF NOT EXISTS version BIGINT NOT NULL DEFAULT 1;\n COMMENT ON COLUMN users.version IS 乐观锁版本号;\n COMMIT;\n ) raise ValueError(无法根据当前输入生成合适的迁移脚本请补充 schema 信息) def run_sqlfluff(sql_path: Path) - bool: result subprocess.run( [sqlfluff, lint, str(sql_path)], capture_outputTrue, textTrue, ) print(result.stdout) return result.returncode 0 def run_verify(script_path: Path) - bool: # 生产环境建议使用独立的只读连接先做影响分析再决定是否执行。 # 这里用一个模拟验证来演示输出。 print( 在事务中验证迁移脚本) content script_path.read_text(encodingutf-8) if BEGIN; in content and COMMIT; in content: print(事务包裹检查通过) return True print(事务包裹检查失败) return False def main() - int: parser argparse.ArgumentParser(descriptiondb-migration skill runner) parser.add_argument(--schema-file, requiredTrue, help当前表结构文件路径) parser.add_argument(--changes, requiredTrue, help变更需求描述) args parser.parse_args() schema read_file(args.schema_file) migration generate_migration(schema, args.changes) migration_path OUTPUT_DIR / migration.sql migration_path.write_text(migration, encodingutf-8) lint_ok run_sqlfluff(migration_path) verify_ok run_verify(migration_path) report OUTPUT_DIR / verify_report.txt report.write_text( flint_ok{lint_ok}\nverify_ok{verify_ok}\n, encodingutf-8, ) if not lint_ok or not verify_ok: print(SKILL 执行失败请人工介入。) return 1 print(SKILL 执行成功交付物见 output/ 目录。) return 0 if __name__ __main__: sys.exit(main())这个脚本的主要意义是“把执行过程固定下来”。Agent 不需要凭感觉决定下一步做什么只需要按脚本的步骤调用。脚本里的generate_migration函数在实际使用中可以替换为调用 LLM 的代码也可以替换为 Agent 工具的生成能力。你可能会觉得这个脚本太简单。确实它没有真实连接数据库但这正是我要说明的点Do Work Skill 的骨架是“输入产出、调用工具、验证结果”这三个动作至于生成和验证逻辑用什么实现每个团队都可以按自己的工程基建来替换。6.4 编写回滚与验证脚本数据库操作必须能回滚。创建skills/db-migration/scripts/rollback.sh#!/usr/bin/env bash set -euo pipefail # 用法./rollback.sh 迁移脚本路径 # 回滚逻辑读取脚本中的 ROLLBACK 段并执行。 # 这里仅演示结构实际生产环境应连接数据库执行。 MIGRATION_FILE${1:?请提供迁移脚本路径} echo 从迁移脚本中提取回滚语句 grep -E ^-- ROLLBACK $MIGRATION_FILE || { echo 错误迁移脚本中未包含回滚标记拒绝执行。 exit 1 } echo 回滚完成示例回滚脚本的要点是必须在执行迁移前就准备好。不要在 AI 执行失败之后再让 AI 现场写回滚逻辑。人在紧急状态下容易犯错AI 在报错堆栈面前也一样。6.5 构造测试输入在项目目录创建input/schema.sqlCREATE TABLE users ( id BIGSERIAL PRIMARY KEY, name VARCHAR(128) NOT NULL, email VARCHAR(255) NOT NULL );然后在终端运行编排脚本python skills/db-migration/scripts/run_skill.py \ --schema-file input/schema.sql \ --changes 为 users 表增加 version 字段如果按上述代码执行你会看到sqlfluff lint应该能通过前提是你本地已经安装 sqlfluff。输出目录下会出现两个文件output/migration.sql和output/verify_report.txt。6.6 接入 AI Coding Agent上述脚本可以独立运行但真正的价值是接入 AI Coding Agent。在支持 Skill 机制的 Agent 中你只需要在配置里声明db-migration这个 Skill并告诉 Agent使用 db-migration Skill根据 input/schema.sql 和需求“为 users 表增加 version 字段”完成任务。Agent 会自己加载skill.yaml读取task.md模板调用run_skill.py然后根据verify_report.txt判断任务是否完成。如果你的 Agent 不支持自动加载也可以在配置文件中加入一条自定义命令让 Agent 遇到“数据库迁移”关键词时自动执行run_skill.py。7. 运行结果与效果验证执行成功后output/verify_report.txt的内容应该类似lint_okTrue verify_okTrueoutput/migration.sql的内容应该包含BEGIN;、ALTER TABLE和COMMIT;。如何判断 Skill 是否“真的干活了”我建议用三个标准第一交付物是否存在于预期位置。如果 Agent 忙了半天没有产出任何文件说明 Skill 流程没被正确触发。第二验证报告是否记录了真实执行结果。报告里的lint_okTrue必须是sqlfluff的真实返回码而不是 Agent 自己写的“看起来应该没问题”。第三失败路径是否被覆盖。故意把target_changes改成一个模糊的需求比如“优化数据库”观察 Skill 是否会及时失败而不是硬生生生成一个不靠谱的脚本。如果运行失败优先检查三件事Python 脚本有没有语法错误建议直接运行python skills/db-migration/scripts/run_skill.py --helpsqlfluff 是否安装可用sqlfluff --version确认Agent 是否真的进入了skills/db-migration目录执行如果路径不对会出现“找不到skill.yaml”的报错。8. 常见问题与排查思路问题现象可能原因排查方式解决方案Agent 执行 Skill 后没有生成任何文件Skill 元数据配置错误或 Agent 未正确加载查看 Agent 运行日志确认是否加载skill.yaml检查 Skill 目录路径和name字段是否匹配sqlfluff lint 报错但 Agent 没有修复指令模板未明确要求 AI 主动修复查看task.md中是否包含“修复”步骤在步骤中增加“修复后重新 lint”的循环迁移脚本缺少事务包裹生成逻辑没有把BEGIN;和COMMIT;写进模板检查脚本中generate_migration返回内容在生成阶段强制拼接事务包裹Agent 反复执行失败但一直重试缺少失败终止条件检查指令模板是否允许无限重试在 Skill 中规定“最多修复三次失败则转人工”回滚脚本找不到迁移脚本路径路径传递错误检查 rollback.sh 的入参是否需要绝对路径在编排脚本中将绝对路径传给回滚脚本Skill 输入内容太多Agent 上下文爆炸直接把整库 schema 塞进提示词查看输入文件是否过大先用脚本提取变更涉及的子集表结构生产环境执行时没有提示确认缺少人工审批点检查 Skill 是否有人工确认流程在关键操作前增加阻塞式确认步骤9. 工程化落地建议9.1 从一个小场景做起不建议一开始就构建一个大而全的“全流程 AI 开发 Skill”。最稳妥的方式是挑一个团队每天都在做、出错成本较低、验证标准清晰的重复性任务。数据库迁移、接口文档生成、依赖升级、代码格式化都是不错的起点。当这个 Skill 跑顺了团队对“AI 能稳定干活”建立了信心再逐步扩展到更复杂的任务。9.2 Skill 也要版本管理Skill 本身就是一份代码资产应该放进 Git 仓库统一管理。每次修改指令模板、调整工具版本都应该走 MR/PR 评审流程。我建议把 Skill 按以下目录组织skills/ db-migration/ skill.yaml templates/ scripts/ tests/ api-doc-generator/ skill.yaml templates/ scripts/ tests/tests/目录很重要。Skill 的逻辑也会变变完之后不能影响已有任务的稳定性。至少留一个最小输入样例作为回归测试。9.3 权限与安全边界这是最重要的一条。给 Agent 的权限永远遵循最小原则。常见的做法是默认禁止 Agent 直接连接生产数据库迁移类 Skill 只能输出脚本文件执行操作交由 DBA 审核后手动执行如果必须让 Agent 自动执行则使用独立的 testing 数据库并且连接账号只有目标库的临时权限。不要图省事给 Agent 一个超级账号。AI Coding Agent 是辅助工具不是运维系统它的价值在于生成和验证不在于拥有无限权限。9.4 日志与可观测性Skill 执行时一定要记录日志。建议至少记录以下信息输入参数的摘要Agent 每一步决策的上下文调用了哪些命令返回码是什么验证结果和最终交付物路径。没有日志的 AI Coding 流程一旦出现问题你连复盘都无从下手。这个坑我已经看很多团队踩过了AI 做了很多事最后所有人只知道结果不对但没人知道哪一步开始错的。9.5 建立评测基线不要让“AI 生成的代码能不能跑”成为唯一评价标准。建议为每个 Skill 建立一组评测用例。每次升级模型、调整提示词、修改脚本都用同一组用例跑一遍对比交付物的质量和验证通过率。如果你在做 AI Coding 笔试或团队能力评估这种“评测集”的思路尤其有用。它能把“AI 能力强不强”这种主观问题变成“在固定 Skill 和输入下交付率是多少”这种容易比较的问题。10. 总结与后续学习方向回到最初的问题AI Coding 从“生成代码”到“真正干活”差距到底在哪里差距不在模型能力而在工程流程。模型再强也需要有人告诉它任务边界在哪、工具是什么、怎么算完成、失败了怎么处理。Do Work Skill 解决的就是这件事。这篇文章真正讲清楚的几个点我帮你圈出来第一AI Coding 的核心提效场景不是“写代码”本身而是高频固定任务的自动化交付。第二Do Work Skill 是一个五层结构任务定义、上下文装配、执行编排、工具调用、验证回环。五层缺一不可。第三数据库迁移 Skill 的实战过程验证了一个结论即使生成逻辑很简单只要“生成—检查—验证—回滚”这条链路完整Skill 就是可用的。下一步你可以做三件事把db-migration示例中的generate_migration替换成你实际使用的 LLM 调用接入一个真实的测试数据库把事务验证跑通。观察团队成员使用这个 Skill 的过程记录哪个环节最需要人工介入再把介入点固化为审批流程。从团队的高频任务里挑第二个、第三个场景继续封装成 Skill慢慢形成自己的 AI 工作技能库。AI Coding 的竞争最终会比拼的是谁沉淀下来的“可干活技能”更多、更稳、更安全。Do Work Skill就是你在 2026 年值得认真投入的一个方向。建议把这篇文章收藏动手构建第一个 Skill 时回来对照检查每一步有没有遗漏。