企业官网建设流程全解析

从 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。

什么意思？当一个任务被封装成 Skill，AI 不再是“临时发挥”，而是进入一条固定的工作流：理解任务、读取上下文、调用工具、执行迁移或生成、跑验证、输出结构化结果。人只在关键节点介入。这样，AI 从“一个聪明的实习生”变成了“一个稳定的自动化同事”。

读完这篇文章，你可以解决以下问题：

• 理解 Do Work Skill 和普通 Prompt、Agent 工作流的区别；
• 掌握一个 Do Work Skill 的基本组成部分和设计原则；
• 从零实现一个“数据库迁移脚本生成与验证”的真实 Skill；
• 知道怎么接入主流的 AI Coding Agent 并验证效果；
• 避开权限、回滚、上下文污染等常见工程坑。

2. AI Coding 为什么需要 Do Work Skill

2.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 Workflow

2025 年开始流行的 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 可以拆成五层：

很多团队做 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 Agent（Claude 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_ok=True) def read_file(path: str) -> str: return Path(path).read_text(encoding="utf-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_output=True, text=True, ) print(result.stdout) return result.returncode == 0 def run_verify(script_path: Path) -> bool: # 生产环境建议使用独立的只读连接先做影响分析，再决定是否执行。 # 这里用一个模拟验证来演示输出。 print("==> 在事务中验证迁移脚本") content = script_path.read_text(encoding="utf-8") if "BEGIN;" in content and "COMMIT;" in content: print("事务包裹检查通过") return True print("事务包裹检查失败") return False def main() -> int: parser = argparse.ArgumentParser(description="db-migration skill runner") parser.add_argument("--schema-file", required=True, help="当前表结构文件路径") parser.add_argument("--changes", required=True, 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, encoding="utf-8") lint_ok = run_sqlfluff(migration_path) verify_ok = run_verify(migration_path) report = OUTPUT_DIR / "verify_report.txt" report.write_text( f"lint_ok={lint_ok}\nverify_ok={verify_ok}\n", encoding="utf-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.sql：

CREATE 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_ok=True verify_ok=True

output/migration.sql的内容应该包含BEGIN;、ALTER TABLE和COMMIT;。

如何判断 Skill 是否“真的干活了”？我建议用三个标准：

第一，交付物是否存在于预期位置。如果 Agent 忙了半天，没有产出任何文件，说明 Skill 流程没被正确触发。

第二，验证报告是否记录了真实执行结果。报告里的lint_ok=True必须是sqlfluff的真实返回码，而不是 Agent 自己写的“看起来应该没问题”。

第三，失败路径是否被覆盖。故意把target_changes改成一个模糊的需求，比如“优化数据库”，观察 Skill 是否会及时失败而不是硬生生生成一个不靠谱的脚本。

如果运行失败，优先检查三件事：

• Python 脚本有没有语法错误，建议直接运行python skills/db-migration/scripts/run_skill.py --help；
• sqlfluff 是否安装，可用sqlfluff --version确认；
• Agent 是否真的进入了skills/db-migration目录执行，如果路径不对，会出现“找不到skill.yaml”的报错。

8. 常见问题与排查思路

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 时，回来对照检查每一步有没有遗漏。