构建Do Work Skill：让AI在编程实战中从聊天机器人变成干活的人

先给结论这期文章我们要解决一个很现实的问题——AI 编程工具已经很多了但为什么你在项目里还是用不起来很多人把 AI Coding 当成“高级搜索引擎”问一句答一句代码还是要自己写、bug 还是要自己找。真正的 AI Coding 实战不是让模型帮你写一段代码而是把它训练成一个“能独立推进任务的执行者”。这就是 Do Work Skill 要解决的东西。从标题看这是 AI Coding for Real Engineers 系列的第 52 篇主题很明确构建一套 Do Work Skill 解决方案。简单解释一下Do Work Skill 不是某个具体模型或框架的名字而是一种工程方法论——把 AI 从“聊天机器人”改造成“干活的人”。它包含四层能力理解任务目标、读取真实项目上下文、调用外部工具执行操作、按照验证标准交付结果。这篇文章我会按工程落地的思路展开先拆解 Do Work Skill 的能力模型再讲环境准备、技能定义、执行工作流、批量任务和接口集成最后给出排查清单和最佳实践。无论你用的是 Claude Code、GLM Coding Plan、Vercel AI 这类在线平台还是本地 CLI 工具思路都可以复用。先说明一点文章里不会写死某个工具的版本号或显存参数因为 AI Coding 工具迭代太快今天写明天就可能过期。我会用通用工程框架 可替换工具链的方式来讲你拿到后只需要替换成自己正在用的工具。1. 核心能力速览这套 Do Work Skill 解决方案本质上是一套工程化架子。它不绑定具体工具而是定义了一套“AI 怎么在真实代码库里干活”的标准流程。下面这张表是按方案能力整理的能力项说明方案类型AI Coding 工程化方法论 工具链配置模板目标用户前端、后端、全栈工程师、技术负责人核心能力任务规划、代码检索、编辑执行、测试验证、批量任务技能定义方式YAML / JSON 结构化技能描述文件上下文来源代码仓库、文档、依赖清单、历史决策记录执行模式单任务交互、批处理队列、API 触发工具链依赖CLI Agent、代码检索工具、Git、测试框架是否需要 GPU不需要远程模型或本地小模型均可批量任务能力支持通过目录扫描 任务队列实现接口 API可通过通用 HTTP 或 CLI 集成最适合场景重复性开发任务、模块批量生成、代码重构、测试补全主要限制需要人工复核复杂架构决策仍需工程师把关从表格能看出这套方案的最大特点是不挑显卡、不挑环境重点在“流程设计”。这也是 AI Coding 和传统 AI 绘画、AI 视频项目最大的区别——它的运行成本主要是 token 费用和工程师的校验时间而不是本地推理资源。2. 适用场景与使用边界2.1 适合解决什么问题Do Work Skill 最适合解决四类问题。第一重复性代码任务。比如给一个包含 30 个组件的项目批量补充单元测试或者给多个微服务统一添加日志埋点。这类任务工作量大、规则明确非常适合交给 AI 执行。第二仓库级代码理解。新接手一个项目时让 AI 自动梳理模块结构、数据流、依赖关系生成一份项目地图。这比手翻代码快得多。第三跨文件重构。比如把一个工具库从 CommonJS 迁移到 ESM把 API 调用从回调改成 async/await。这类任务涉及多个文件联动需要 AI 具备全局编辑能力。第四文档与代码同步。接口变了文档没更新这是最常见的维护痛点。AI 可以根据代码变更自动生成变更说明。2.2 不适合什么场景需要强调几个边界。第一个边界系统架构设计。AI 可以帮你画出模块拆分但它无法理解公司内部的业务战略和团队协作约束。架构评审必须由人来做。第二个边界高风险变更。涉及数据库迁移、支付逻辑、权限控制等核心敏感代码AI 的输出只能作为初稿必须经过完整的人工评审和测试。第三个边界完全未知的前沿技术。AI 的训练数据有截止日期如果项目用到的最新框架版本它不认识你会得到大量幻觉代码。2.3 合规与安全边界这是一个必须重点强调的部分。使用 AI Coding 工具处理代码时需要注意以下几点不要在对话中粘贴包含密钥、Token、数据库密码的配置文件。处理客户数据和用户隐私信息时优先选用私有化部署或数据脱敏方案。涉及开源代码的学习和参考时注意 License 合规不要直接把受保护代码改写成自己的商业代码。AI 生成的代码也要走公司的代码审查流程不能因为“AI 生成的”就跳过 review。如果你的公司有代码保密要求先确认你用的 AI 编码工具是否会把代码发送到外部服务。清楚边界后我们再进入具体构建环节。整个方案的核心是把零散的“AI 对话能力”封装成可复用的“技能执行单元”。3. 环境准备与前置条件3.1 软件环境Do Work Skill 方案的运行环境很轻不需要 GPU不需要本地大模型。以下是通用的前置条件# 最低环境清单 # 操作系统Windows 10 / macOS 12 / Ubuntu 20.04 及以上 # Python 3.10用于编写任务脚本和技能加载器 # Node.js 18大多数 AI Coding CLI 工具需要 # Git 2.30 # Docker可选用于隔离任务环境检查本地环境python --version node --version git --version docker --version # 可选3.2 需要准备的模型服务AI Coding 的执行引擎需要一个大模型服务的 API 或 CLI 工具。常见的选项包括Claude CodeAnthropic 官方 CLI适合长上下文和复杂代码编辑。GLM Coding Plan面向中文开发者支持在数小时内完成过去需要数周开发的场景官方宣传重点是 agent 能力和结构化输出。Vercel AI Vibe Coding 平台面向 Web 前端的快速构建主打交互式生成。本地部署的开源模型比如通过 Ollama 或 LM Studio 运行 Qwen 系列、DeepSeek 系列等。这里不写死推荐哪一款因为工具更新很快。你可以根据自己的项目类型和预算选择。重点在于不管是哪款工具你都需要确认三件事它是否能读取项目目录结构而不是只看单个文件。它是否能执行终端命令比如运行测试、安装依赖、执行构建。它是否能编辑多个文件而不只是输出代码片段。3.3 初始化项目目录建议把 Do Work Skill 相关的配置、脚本、输出目录独立出来不要和业务代码混在一起。推荐结构如下do-work-skill/ ├── skills/ # 技能定义文件 │ ├── add-unit-tests.yaml │ ├── refactor-esm.yaml │ └── generate-api-client.yaml ├── templates/ # 任务模板 ├── scripts/ # 调度与批处理脚本 ├── contexts/ # 项目上下文资料 ├── outputs/ # AI 执行结果输出 └── logs/ # 运行日志这种目录结构的好处是技能定义、上下文资料和执行结果分离方便追溯。尤其是批量任务跑完以后你能清楚地看到每个任务输入了什么、输出了什么。3.4 确认工具权限AI Coding 工具如果需要自动执行命令或修改文件要给它明确的权限边界。通用原则是先在一个干净的 Git 分支上执行。用最小权限运行脚本不要直接在服务器生产目录里测试。如果工具支持 dry-run 模式先跑 dry-run 再看实际修改。设置读取和写入目录的白名单。4. Do Work Skill 的核心架构与构建步骤接下来是整个方案的骨架。Do Work Skill 不是写一个 prompt 就完了它需要一套完整的“技能定义 执行上下文 验证闭环”结构。我把它分成五个层级。4.1 第一层任务描述层Skill Definition技能定义文件是 Do Work Skill 的入口。它描述了这个技能“什么时候用、输入什么、输出什么、怎么做”。推荐用 YAML 格式可读性好也容易版本管理。下面是一个示例技能定义目标是把“为项目补充单元测试”定义成一个可复用技能name: add_unit_tests description: 为指定函数或模块补充单元测试生成符合项目测试规范的测试文件。 version: 1.0.0 input_schema: type: object properties: target_path: type: string description: 需要测试的源码文件或目录例如 src/utils/date.ts test_framework: type: string enum: [vitest, jest, pytest] coverage_level: type: string enum: [core, full] description: core只覆盖主要分支full覆盖所有分支和边界情况 required: - target_path steps: - step: 1 action: read_project_context description: 读取项目结构和测试配置确认测试命令与命名规范 - step: 2 action: read_target_code description: 读取目标文件代码分析导出函数和依赖 - step: 3 action: generate_test_plan description: 输出测试用例列表并在执行前给用户确认 - step: 4 action: create_test_file description: 创建测试文件并运行测试失败则修正后重试 - step: 5 action: verify_coverage description: 检查覆盖率输出测试报告 output_schema: type: object properties: test_files: type: array items: type: string success_count: type: integer coverage_report: type: string这个 YAML 文件解决的关键问题是让 AI 不再“猜”任务流程。每次调用技能时它都按照固定的步骤执行不会漏掉验证环节。4.2 第二层上下文注入层Context InjectionAI Coding 工具效果好不好一半取决于上下文质量。同一个任务给 AI 一个只有文件名的项目和一个有完整架构说明的项目输出质量差距巨大。上下文注入层建议包含五个来源项目结构文件让 AI 先读取根目录 README、package.json / pyproject.toml、tsconfig.json 等。代码规范文档ESLint 配置、代码风格指南、commit 规范。接口文档OpenAPI spec、GraphQL schema。历史决策记录ADRArchitecture Decision Records记录之前的架构选择和原因。任务说明也就是你希望 AI 完成的具体目标越具体越好。在实际操作中可以在发起任务前先生成一份project_context.md# 生成项目上下文摘要示例 cat package.json README.md docs/architecture.md contexts/project_context.md如果项目太大要用检索方式而不是全量塞入。比较通用做法是先把文件索引建立起来再通过关键词检索上下文片段让 AI 只读取与任务相关的部分。4.3 第三层执行工具层Tool OrchestrationAI 要“干活”必须能操作真实环境。执行工具层通常包括四类能力文件读写读取源码、创建文件、修改代码。命令执行运行 npm test、pytest、go build 等项目命令。代码检索搜索函数定义、变量引用、模块依赖。Git 操作创建分支、提交变更、对比 diff。大多数现代 AI Coding CLI 工具已经把这几类能力内置了。如果你用的是自定义方案需要自己写适配层。示例脚本如下# scripts/tool_wrapper.py # 用于把技能定义中的 action 映射到实际工具调用 import subprocess import json def read_file(path): with open(path, r, encodingutf-8) as f: return f.read() def run_command(cmd, cwdNone): result subprocess.run( cmd, shellTrue, cwdcwd, capture_outputTrue, textTrue, timeout60 ) return { stdout: result.stdout[-2000:], stderr: result.stderr[-2000:], returncode: result.returncode } def git_diff(branchmain): return run_command(fgit diff {branch} --stat) if __name__ __main__: # 简单测试 print(json.dumps(run_command(git status)))这一步的核心是“给 AI 接上手脚”。没有工具调用能力的 AI本质上还是聊天机器人。4.4 第四层验证闭环层Verification LoopAI 写完代码说“完成了”你信吗专业工程师的做法是——让 AI 自己验证。这一层把测试、构建、静态检查接入执行流程。执行流程 1. 生成代码 2. 运行针对性测试 3. 如果测试失败读取错误信息修改代码 4. 重复 2-3最多重试 N 次 5. 所有测试通过后运行全量检查lint / typecheck / build 6. 输出结果报告这个循环看起来简单但它是 Do Work Skill 和普通 AI 编程助手的核心区别。普通助手给你一段代码就结束了Do Work Skill 必须保证代码跑得通。4.5 第五层经验沉淀层Skill Memory这是大多数人忽略的一层。每次 AI 完成任务后把过程中遇到的问题、解决方式、用户纠正过的点记录下来沉淀为“技能记忆”。下次执行相似任务时AI 会自动规避之前踩过的坑。存储方式很简单就是一个带标签的 Markdown 或 JSON 文件{ skill: add_unit_tests, lessons: [ { issue: 某些文件依赖 mock 外部服务, solution: 在测试前检查是否有 http 调用需要先 mock, trigger: 文件 import 了 http client } ] }这套机制的效果是同一个技能用 10 次和用 100 次AI 的表现会越来越稳定。这就是“技能”和“一次性问答”的本质差别。5. 实战从需求到交付的一次完整任务流下面用一个虚构但典型的场景把这套方案串起来你要给一个 Node.js 项目里所有 API 路由文件批量补充参数校验逻辑并确保现有测试全部通过。5.1 准备阶段在项目根目录创建技能定义文件并写入执行目标mkdir -p skills/validate-api-routes技能定义的核心是让 AI 明确“校验逻辑要写成什么样的”。比如规定校验函数放在src/validators/目录。使用自定义的validateRequest(schema, req, res)函数。校验失败时返回400 { code: INVALID_PARAMS, message: ... }。不能影响现有路由的参数类型。同时把项目的路由文件列表传给 AIfind src/routes -name *.ts | sort contexts/route_files.txt5.2 执行阶段启动 AI Coding 工具选择validate-api-routes技能指定目标目录src/routes然后等待执行。这一阶段 AI 会自行完成这些动作读取src/routes下所有文件。分析每个路由函数的入参。参考已有 validator 的写法保持一致风格。创建新的校验文件或在原文件中插入校验逻辑。运行现有的npm test检查是否破坏功能。如果失败读取报错信息并修复。我建议以批处理脚本的方式触发而不是手动逐个操作。这样任务可重复执行也方便记录日志。5.3 验收阶段AI 执行完成后你不能直接 merge。按以下顺序验收先跑一次全量测试npm test再看 git diff确认改动都在预期范围内。抽查 3 个路由文件确认校验逻辑符合项目风格。用一条真实请求验证校验逻辑是否生效。核心判断标准代码风格统一、异常路径覆盖完整、测试全部通过、关键业务逻辑没有被 AI“顺手改编”掉。6. 接口 API 调用与批量任务设计Do Work Skill 方案要真正变成生产力工具必须支持接口调用和批量任务。下面给出两个层面的实现思路。6.1 通过 API 调用技能大多数 AI Coding 平台都提供 API 访问。以一个通用 HTTP 接口为例你可以这样做# 通用示例具体接口路径和参数以实际工具文档为准 curl -X POST https://api.example.com/v1/tasks \ -H Authorization: Bearer YOUR_API_KEY \ -H Content-Type: application/json \ -d { skill: add_unit_tests, input: { target_path: src/utils/date.ts, test_framework: vitest, coverage_level: full }, callback_url: https://your-server.com/callback }需要注意的是这里只是一个通用模板。不同平台对任务提交方式的定义完全不同有的用长连接轮询有的用 Webhook 回调。你只需要抓住三个关键点任务提交接口、任务状态查询接口、结果获取方式。Python 集成示例import requests import time API_BASE https://api.example.com/v1 API_KEY YOUR_API_KEY headers {Authorization: fBearer {API_KEY}} def submit_task(skill_name: str, payload: dict): resp requests.post( f{API_BASE}/tasks, json{skill: skill_name, input: payload}, headersheaders, timeout30 ) resp.raise_for_status() return resp.json()[task_id] def wait_for_task(task_id: str, timeout_seconds: int 600): start time.time() while time.time() - start timeout_seconds: resp requests.get(f{API_BASE}/tasks/{task_id}, headersheaders, timeout30) status resp.json()[status] if status in (succeeded, failed): return resp.json() time.sleep(10) raise TimeoutError(fTask {task_id} timed out) if __name__ __main__: task_id submit_task(add_unit_tests, { target_path: src/utils/date.ts, test_framework: vitest, coverage_level: full }) result wait_for_task(task_id) print(result)这个脚本解决了“把 AI 接入自动化流水线”的问题。你可以把它集成到 GitLab CI / GitHub Actions 中在质检阶段自动为新增代码生成测试建议。6.2 批量任务目录设计批量任务的核心是“输入目录 遍历 结果归集”。推荐做法是把每个子任务整理成独立的 JSON 描述文件然后让调度脚本逐个处理。// batch_tasks/001.json { task_id: 001, skill: add_unit_tests, target_path: src/utils/date.ts, test_framework: vitest, coverage_level: full }# scripts/batch_runner.py import json import os from pathlib import Path def load_tasks(batch_dir: str): tasks [] for file in sorted(Path(batch_dir).glob(*.json)): with open(file, r, encodingutf-8) as f: tasks.append(json.load(f)) return tasks def run_batch(batch_dir: str, output_dir: str): tasks load_tasks(batch_dir) results [] for task in tasks: print(fProcessing task {task[task_id]} ...) # 这里替换为实际的任务提交和等待逻辑 results.append({ task_id: task[task_id], status: success, output_path: f{output_dir}/{task[task_id]}/ }) with open(f{output_dir}/summary.json, w, encodingutf-8) as f: json.dump(results, f, ensure_asciiFalse, indent2) print(fDone. {len(results)} tasks processed.) if __name__ __main__: run_batch(batch_tasks, outputs)批量任务要做三件事失败任务自动重试一般重试一次即可重试次数过多反而浪费 token。每个任务独立记录日志和运行时长。最后汇总成一份 summary 文件方便人工抽查。6.3 接入 CI/CD 的注意事项把 AI Coding 接入 CI/CD 时要小心AI 生成的代码直接进主干风险极高。建议只在以下场景接入自动生成测试用例初稿生成后创建 MR/PR 而不是直接合并。自动生成 API 客户端代码结构变化需要人工确认。自动更新依赖版本说明和变更日志。CI 环境的鉴权信息要放在变量配置中不要硬编码在脚本里。同时要设置超时限制避免任务陷入死循环。7. 运行成本与性能观察方法7.1 Token 消耗是主要成本AI Coding 的最大成本不是 GPU而是 token。CLI Agent 在读取文件、生成代码、执行命令时都会消耗大量 token。尤其需要注意大文件读取一个 5000 行的文件可能消耗数万 token。多次重试每次重试都是一整轮对话上下文。长对话累积一个任务跑 30 分钟历史上下文可能会逼近模型窗口上限。建议在任务开始时用context_trim策略先总结已经完成的部分截断历史 token再继续后续任务。7.2 如何观察任务是否正常观察指标建议用这五类单任务时长一个常规代码生成任务应该在 2-5 分钟内完成超过 15 分钟说明任务拆得太粗或重试过多。修改文件数量根据任务类型有个合理区间批量补测试可能是 10-30 个文件重新实现功能可能只要 2-3 个文件。测试通过率低于 80% 需要审视技能定义或上下文质量。Token 消耗速率过快的 token 消耗通常意味着 AI 在大量读取无关文件。重试次数单个文件重试超过 3 次建议停下检查根因。7.3 降低成本的技巧几个亲测有效的思路在技能定义里限制读取文件的规模比如只读函数签名而不是整个文件。对超大仓库先用检索插件缩小范围。把大任务拆成多个小任务避免单个对话上下文过长。配置输出长度限制防止 AI 生成大量与任务无关的代码。不是每个任务都要全自动最高价值的任务先做人工规划。8. 常见问题与排查方法下面是 Do Work Skill 方案落地时最常遇到的一批问题对应排查思路如下。问题现象可能原因排查方式解决方案AI 修改了无关文件上下文注入范围太大检查上下文文件是否包含无关目录查看 diff收紧 context限制读取目录白名单测试一直失败项目测试环境需要 mock 服务查看失败日志中的错误类型在技能定义中增加预执行步骤先启动 mockToken 消耗异常大文件被反复读取开启 token 统计日志拆分文件使用检索代替全量读取AI 中途停止不干活工具链权限不足或命令执行超时检查日志中的 timeout 信息修改超时参数或调整命令执行方式API 调用返回格式错误技能定义中 output_schema 与实现不一致对比 schema 和实际返回修正 schema 或让 AI 按 schema 输出批量任务部分失败单个子任务输入不合法查看 summary.json 中失败项增加输入前置校验失败任务重试生成的代码风格不一致规范文档未注入上下文检查 context 中是否包含代码规范把 ESLint 配置和开发规范加入 context模型幻觉生成不存在的 API模型不了解项目依赖版本注入依赖版本文件信息在 context 中加入 package.json / requirements.txt任务结果难以追踪没有日志和输出归集检查 logs 和 outputs 目录建立标准化输出结构和日志规范另外两个高频提示不要让 AI 直接操作数据库。如果任务涉及数据库指定 AI 只生成 SQL 脚本和迁移文件实际操作由人工执行。AI 卡住不动时不要反复发送同一条消息。先检查上下文长度是否接近上限再决定是截断上下文还是重置对话。9. 最佳实践与使用建议结合前面构建过程这里整理一份可以直接照做的清单9.1 从最小闭环开始不要第一天就期望 AI 能独立完成“全仓库重构”。先选一个边界清晰、规则明确的小任务比如给一个工具函数补测试跑通“定义技能 → 注入上下文 → 执行 → 验证 → 沉淀经验”的最小闭环。确认效果稳定后再扩展任务复杂度。9.2 每次任务都要有明确的验收标准再强调一次没有验收标准AI 输出质量就没有测量口径。验收标准至少包含功能是否验证通过测试/构建。代码风格是否符合项目规范。改动范围是否超出预期。是否有未授权的副作用比如修改了配置文件。9.3 沉淀你自己的技能库团队可以建立一个内部技能库把常用任务固化为技能定义文件。随着团队使用次数增加每个技能的步骤和上下文会越来越完善。最终效果可能是新同事用同一套技能库也能产出和资深工程师接近的代码质量。9.4 明确人工复核的节点强烈建议在三个阶段设置人工节点任务规划阶段AI 给出执行计划后人工确认计划是否正确。关键文件修改后AI 完成关键模块代码后人工看一次 diff。全量验收阶段所有任务完成后人工运行整体测试并审查。9.5 版本管理所有技能文件技能定义文件、上下文模板、批量任务输入输出全部进入 Git 仓库。这样你可以对比不同版本技能定义的执行效果。如果某次任务效果明显变好可以回溯找出是改了哪个步骤带来的提升。10. 总结与下一步这篇文章把 Do Work Skill 解决方案拆成了五层结构任务描述层、上下文注入层、执行工具层、验证闭环层、经验沉淀层。这五层合起来构成了一个真正能“干活”的 AI Coding 工作流。从搜索结果来看AI Coding 工具生态在 2026 年已经进入了快速成熟阶段。GLM Coding Plan 这类中文工具在强调数小时内完成过去需要数周的开发工作Vercel AI 这类 Web 平台则在降低前端构建的交互门槛。工具会继续迭代但 Do Work Skill 这套方法论的底层逻辑不会变AI 要想在真实工程里创造价值必须有明确的目标、足量的上下文、可执行的工具链和可验证的输出。建议你现在就做三件事第一从你自己项目里挑一个重复性最高、规则最明确的小任务。第二按文章的技能定义模板写一个 YAML 文件跑通一次完整流程。第三把这次任务中遇到的问题记录下来沉淀成团队的第一条技能记忆。最容易踩的坑我也帮你标出来了不要跳过验收、不要给 AI 过大的权限、不要一次性丢一个超大仓库。控制好这三件事Do Work Skill 方案就成功了多半。后续可以继续扩展的方向包括把技能库接入团队 CI 流水线、给技能定义加版本热更新机制、统计不同模型的产出质量对比、以及建立一套基于 token 消耗和代码通过率的任务质量评估体系。这些方向任何一个展开都能做成单独的工程专题。