如果你最近在项目里重度使用过 AI 编程助手大概率会遇到一种很微妙的状态AI 能写出看起来很合理的代码功能也实现了大半但离“把这件事干完”总是差那么几步。差在哪儿差在它没有检查自己有没有引入编译错误没有跑一遍完整测试没有确认这次改动和现有模块冲突也没有留下清晰的变更说明。作为工程师你最后还得花时间收拾这套半成品。换句话说AI Coding 真正难的地方不是“生成代码”而是“把活干完”。2026 年的 AI Coding 工具已经在自动补全、单文件生成、意图解析上做到相当成熟但一旦上升到真实项目交付模型推理能力和任务执行能力之间的差距就会显露出来。这正好是 Do Work Skill 这个概念要解决的问题。这篇文章要讲的不是某个模型有多强也不是某个 IDE 插件的新功能。我会把重点放在一套可复用的“Do Work Skill 解决方案”上怎样把一次开发任务拆解成 AI 能按步骤执行的流程怎样让 Agent 不只产出代码还完成验证、提交和收尾动作怎样把这种能力固化成一个 Skill 文件让团队里每个人都能直接复用。读完你会得到一套可以落到自己项目里的工程模板而不是一堆空泛的 AI Coding 概念。1. 这篇文章真正要解决的问题先说结论大多数人在 AI Coding 上遇到的瓶颈不是 AI 不够聪明而是我们没有给它一套“把工作做完”的流程。生成代码只是中间产物完成一项开发任务需要的是理解需求、制定方案、改代码、跑测试、修问题、整理提交这个完整闭环才是真正的 work。从 2026 年 8 月的 AI Coding 趋势看几件事已经非常明确第一个变化是 AI Coding Agent 正在从“聊天窗口里的代码生成器”变成“可以访问代码库、执行命令、读取测试结果的工作 Agent”。这意味着 AI 不再只是给你建议而是真的可以在你的项目里行动。第二个变化是越来越多的平台开始支持 Skill 或类似机制。Cursor、GLM Coding Plan、Vercel 的 AI Vibe Coding Platform 等产品都在往同一个方向走让开发者把常用工作流沉淀成可复用的技能包。Skill 有点像编程里的“函数封装”只不过封装的对象不是一段逻辑而是 AI 完成一类任务所需的提示词、步骤、工具调用和验证方式。第三个变化是大家开始用“数小时完成过去需要数周的开发工作”来描述 AI Coding 的收益。这种说法有营销成分但背后确实有真实的技术支撑当 Agent 能在项目里自主完成计划、编码、验证这三个环节时小规模需求的交付速度会显著提升。这篇文章会围绕 Do Work Skill 展开讲清楚它是怎么设计的、怎么落地、有哪些坑。无论你是后端工程师、前端工程师还是技术团队负责人都可以从中找到适合自己的接入方式。适合读这篇文章的人大概是这三类已经在用 AI 写代码但觉得 AI 只能“写出来”不能“干完活”的开发者。想让团队统一 AI 协作方式而不是每个人都靠自己的即时提问技巧来驱动 AI 的工程负责人。对 AI Coding Agent、Vibe Coding 这类新工作方式感兴趣想了解 Skill 机制背后设计思路的人。下面进入正题。2. 从“写代码”到“干完活”AI Coding 的认知转变要把 Do Work Skill 讲明白得先理解 AI Coding 这几年经历的三次工作模式变化。这三种模式到现在仍然并存但解决的问题层级完全不同。2.1 第一种模式交互式代码生成这是大家最熟悉的模式。你在 IDE 里装一个 AI 插件选中一段代码让 AI 补全、解释或者重构。它的工作单元是“代码片段”交互方式是“人提问AI 回答”。这种模式的优势是门槛低、反馈快。缺点是 AI 对整个项目的状态几乎无感知它不知道你的测试框架是什么版本不知道你项目的目录约定也不知道这次改动会影响哪些模块。结果是 AI 生成的代码经常和项目风格不一致放到项目里跑不起来你得手动修复。交互式代码生成适合碎片化任务但它本质上是一个更聪明的“搜索引擎”而不是一个能干活的同事。2.2 第二种模式Agent 自动执行Agent 模式和对话式补全最本质的区别是Agent 可以主动使用工具。它能看到你的文件树能读取文件内容能执行 shell 命令能查看测试结果然后根据这些结果调整自己的下一步动作。现在主流的 AI Coding Agent 基本都具备了这些能力。你给它一个任务比如“把用户登录接口从 JWT 换成 Session 方案”它理论上可以自己完成先扫描认证相关代码确定改动范围修改代码跑测试再根据测试失败信息继续修。但这里出现了一个很现实的问题如果没有明确约束Agent 经常会在某个环节停下来。它可能改了代码但没跑测试就告诉你完成了可能在测试失败后尝试两次就放弃了也可能在任务稍微复杂时把上下文搞得一团乱。原因不是模型弱而是它缺少“工作流”层面的引导。2.3 第三种模式Skill 驱动的工作流Skill 驱动模式解决的就是 Agent 的“行为过程”问题。它把任务的执行方式、验证标准、交付格式预先定义好然后让 Agent 按照这套流程去执行。这样做有三个好处可复用。团队里总结出的最佳实践可以沉淀成 Skill 文件新成员使用同样的流程完成任务。可预期。Skill 定义了每一步要做什么、做完怎么验证Agent 的完成质量更稳定。可收敛。就算任务执行到一半出问题Skill 也定义了回退和报告机制不会让 Agent 无限发散。用编程类比来说交互式代码生成像你在终端里手动敲命令每次都要重新输入Agent 自动执行像你写了一段自动化脚本但脚本里的每个步骤都是硬编码的而 Skill 驱动模式像一个封装好的函数有输入参数、有标准执行体、有返回值你可以随时调用它去处理同类任务。这三种模式的对比可以看这张表维度交互式代码生成Agent 自动执行Skill 驱动工作流AI 参与方式辅助生成自主执行部分环节按流程完成完整任务闭环上下文感知弱通常只看当前文件中可读项目相关文件强有明确的信息采集和任务边界定义产出质量不稳定依赖提问质量中等容易中途停滞稳定自带验证闭环可复用性低低高适合场景单点问题、快速补全任务边界清晰的开发项重复性、流程化、需要交付保障的任务3. Do Work Skill 的设计原理与核心概念现在可以正式讨论 Do Work Skill 了。从字面理解Do Work Skill 是一组让 AI 完成实际工作的技能定义。但这里的关键不是“Skill”这个文件格式而是它背后对“工作”这件事的拆解方式。3.1 什么是“把活干完”一个 AI 任务要被认为是“干完了”至少应该满足四个条件结果可见改动确实被写进了代码库而不是只停留在对话窗口里。质量可验证有测试、命令或人工检查方式能证明改动符合预期。上下文完整AI 在任务过程中需要的信息已经被定位和确认过而不是靠猜。交接清楚任务完成后AI 能说明改了哪些文件、为什么这么改、还有什么风险。这四个条件看起来简单但很多 AI Coding 场景都做不到。最常见的情况是AI 给出一段“看起来能跑”的代码但没检查你项目的依赖版本、没验证边界条件、没考虑和已有代码的兼容性。原因就是缺少一个强制性的验证和收尾环节。3.2 Do Work Skill 的五个核心环节一个完整的 Do Work Skill 通常包含以下五个环节我在设计自己的 Skill 时基本都会按这个框架来3.2.1 任务澄清ClarifyAI 在动手之前先用自己的话复述一遍任务明确完成标准和验收方式。这个步骤看起来多余但价值很高它能提前暴露理解偏差避免 AI 做了一半才发现方向不对。3.2.2 信息收集ContextAI 需要主动定位与任务相关的代码文件、配置项、数据结构和依赖关系。在这个环节Skill 应该给 AI 一个检查清单比如涉及哪些目录、需要读哪些配置文件、有没有类似的历史实现可以参考。3.2.3 方案规划PlanAI 输出一个分步执行计划每步要有明确的产出物。比如第一步新增数据库迁移文件产出物是 migration SQL第二步修改 Service 层产出物是改动的代码 diff第三步补充测试用例产出物是测试文件。计划要可回滚每个步骤都能独立验证。3.2.4 执行与自查Execute Self-ReviewAI 按照计划执行每一步并在执行后对代码做一轮自查。自查内容包括是否有未使用的变量、是否有明显逻辑漏洞、是否遵循项目现有的命名规范。这一步最容易出问题的地方是 AI 认为自己生成的代码没问题但实际跑编译或测试就报错。所以要尽量把执行和验证绑在一起。3.2.5 验证与交付Verify ReportAI 运行测试并报告结果只有验证通过才算完成。如果验证失败AI 需要根据错误信息回到执行环节继续修改而不是直接把失败结果交给你。最终交付时AI 应该输出一个简短报告改动清单、验证结果、已知风险、后续建议。这五个环节的本质是把一名工程师的思考过程外化成 AI 能遵循的流程。很多 AI Coding 项目失败的共同原因是缺少其中某一环最常见的就是跳过验证直接交付。3.3 Do Work Skill 与传统 Prompt 的区别有些人会问这不就是写一个 Prompt 吗为什么还要叫“Skill 解决方案”区别在于三个层面第一Prompt 是即时的Skill 是持久的。Prompt 只在当前对话里生效而 Skill 可以沉淀成一个独立文件被不同的任务、不同的项目反复调用。第二Prompt 只约束“怎么说”Skill 还能定义“怎么做”。Skill 文件里可以写明工具调用方式、验证命令、完成标准这些不是单纯的文字提示而是可执行的工程规范。第三Prompt 通常没有版本管理Skill 可以纳入代码仓库。这就意味着 Skill 本身可以 review、可以迭代、可以像代码一样做版本管理。这对团队协作的意义非常大。4. 环境准备与前置条件在写 Do Work Skill 的完整示例之前先把环境说清楚。以下是通用建议具体版本请以你项目的实际情况为准下面代码演示重点讲通用实现思路不会把版本号写死。4.1 需要一个可执行命令的 Agent 运行时Do Work Skill 要真正“干完活”前提是 AI 能执行命令、读写文件。也就是说你不能只在网页聊天窗口里用模型必须有本地 IDE 插件、CLI 工具或 Agent 平台支持。常见的可选方案包括Cursor 或同类 AI IDE开启 Agent 模式。支持 MCP 或 Tool Use 的 AI CLI 工具。可以使用 Shell 命令的 Agent 平台。选择标准很简单这个工具必须能读取指定文件内容执行指定 shell 命令并读取命令输出。三项能力缺一不可。4.2 项目代码需要纳入版本管理因为 Skill 流程里会包含 diff、提交、回滚等动作项目最好是 Git 仓库并且在开始执行任务前处于干净状态或者有清晰的分支。建议在实际项目中为 AI 任务单独拉一个分支不要直接在主干上执行。4.3 有可运行的测试基线无论项目是前端、后端还是移动端都应该有至少一条能自动运行的验证命令。这个命令不一定是最完整的单测套件但必须能在几秒或几分钟内跑完用来判断 AI 的改动是否破坏了已有功能。如果没有测试基线建议先补充一个 smoke test否则 Do Work Skill 里“验证闭环”这一环就失去了实际意义。4.4 准备好 Skill 文件目录我习惯在项目仓库里创建.workskills/目录把 Skill 定义和相关脚本放在里面。你可以在团队内部建立自己的约定但建议做到以下三点Skill 文件纳入版本管理方便评审和回滚。Skill 目录里避免放机密信息和绝对路径。Skill 文件命名和目录结构保持统一。接下来我们用一个最小示例来把整个方案跑通。5. 最小可用 Do Work Skill 的完整示例这个示例的目标是定义一套 Skill让 AI Coding Agent 能按“澄清上下文 → 制定计划 → 执行编码 → 自动验证 → 输出报告”的流程完成一个小型开发任务。为了保持简单示例采用一个 YAML 文件定义 Skill配合一个 Python 脚本和 Shell 脚本来实现执行与验证逻辑。5.1 定义 Skill 元信息创建一个文件.workskills/do-work-skill/skill.yamlname: do-work-skill version: 0.1.0 description: 通用开发任务执行 Skill要求 Agent 按“澄清-计划-执行-验证-报告”闭环完成工作。 trigger: - 用户提出一个开发任务如功能开发、Bug 修复、接口调整 inputs: task: description: 要执行的开发任务描述 required: true work_dir: description: 任务所在项目目录默认当前工作目录 required: false steps: - id: clarify name: 任务澄清 description: 用自己的话复述任务列出完成标准和验收方式在动手前向用户确认。 - id: context name: 信息收集 description: 定位相关代码文件、配置项和测试文件阅读后记录关键内容。 - id: plan name: 方案规划 description: 输出分步执行计划每步带可验证的产出物。 - id: execute name: 执行编码 description: 按计划修改代码每次修改保证语法正确必要时补充测试用例。 - id: verify name: 自动验证 description: 运行配置好的验证命令必须全部通过失败则回到 execute 步骤继续修改。 - id: report name: 交付报告 description: 输出改动文件列表、验证结果、已知风险和后续建议。 verify: command: bash .workskills/do-work-skill/verify.sh timeout: 120这个 YAML 文件的作用不是给代码库直接运行而是给 AI Agent 提供一套工作指引。不同 Agent 工具的 Skill 格式可能不同这里的核心是五个步骤的设计格式你可以根据实际工具调整。5.2 编写执行辅助脚本为了让 Skill 不只是一个“提示词”还需要一个可执行的辅助脚本负责解析任务和记录每一步的执行结果。先创建一个 Python 脚本.workskills/do-work-skill/run_skill.py#!/usr/bin/env python3 Do Work Skill 的轻量执行器示例。 这个脚本的作用不是代替 Agent 完成编码而是为 Skill 提供 1) 任务解析与步骤记录的骨架 2) 分步执行的日志输出 3) 调用验证脚本的统一入口。 import argparse import subprocess import sys import time from pathlib import Path def log_step(step_id: str, message: str) - None: timestamp time.strftime(%Y-%m-%d %H:%M:%S) print(f[{timestamp}] [step:{step_id}] {message}, flushTrue) def run_verify(work_dir: Path) - bool: verify_script work_dir / .workskills / do-work-skill / verify.sh if not verify_script.exists(): print(fverify 脚本不存在{verify_script}) return False print( 执行自动验证...) result subprocess.run([bash, str(verify_script)], cwdstr(work_dir), capture_outputTrue, textTrue) if result.stdout: print(result.stdout) if result.stderr: print(result.stderr, filesys.stderr) return result.returncode 0 def main() - int: parser argparse.ArgumentParser(descriptionDo Work Skill 轻量执行器) parser.add_argument(--task, requiredTrue, help要执行的开发任务描述) parser.add_argument(--work-dir, default., help项目根目录默认当前目录) args parser.parse_args() work_dir Path(args.work_dir).resolve() log_step(clarify, f收到任务{args.task}) log_step(context, 请 Agent 阅读项目 README、目录结构和关联测试文件。) log_step(plan, 请 Agent 输出分步实施计划并等待用户确认。) proceed input(是否确认计划并开始执行[y/N]: ).strip().lower() if proceed not in (y, yes): log_step(plan, 用户未确认计划任务终止。) return 0 log_step(execute, 开始编码执行请 Agent 在编码过程中保持项目现状可运行。) ok run_verify(work_dir) if ok: log_step(verify, 所有验证命令通过。) log_step(report, 交付完成请输出改动文件清单、验证结果与风险说明。) return 0 else: log_step(verify, 验证失败请根据错误信息返回 execute 步骤继续修改。) return 1 if __name__ __main__: sys.exit(main())5.3 编写验证脚本再创建一个 Shell 脚本.workskills/do-work-skill/verify.sh#!/usr/bin/env bash # 通用验证入口在测试环境或本地验证本次改动是否影响已有功能。 # 注意实际项目中请根据技术栈替换为真实的测试命令。 set -euo pipefail echo 检查项目必要配置文件... if [ ! -f README.md ]; then echo 错误项目缺少 README.md请先确认项目结构正确。 exit 1 fi # 这里替换为你项目的真实测试命令例如 # pytest -q # npm test # go test ./... echo 运行测试... # pytest -q # npm test echo 验证通过需要注意的是这个脚本里我故意用注释代替了真实测试命令因为不同技术栈差异太大。你在实际项目里应该把pytest -q、npm test或go test ./...这类真实命令填进去才能起到验证作用。5.4 给 Skill 添加必要的执行权限在命令行里执行下面的命令给脚本添加执行权限chmod x .workskills/do-work-skill/run_skill.py chmod x .workskills/do-work-skill/verify.sh到这里一个最小可用的 Do Work Skill 就搭好了。它不是什么宏大系统但已经具备“工作流”的雏形任务先澄清、信息再收集、计划要确认、执行完要验证、验证完要报告。用更通俗的话说我们终于给 AI Coding 装了一个“验收环节”不让它随便交半成品。6. 把 Skill 接入真实项目任务流与验证闭环有了最小示例下一步就是在真实项目里跑起来。这里我会用一个贴近现实的场景来演示假设的项目是一个 Python Web 后端目标是“新增一个健康检查接口/healthz”。6.1 准备任务分支先创建一个新分支保证主分支不被 AI 的实验性改动污染git checkout -b feat/healthz-with-ai这一步很重要的原因是AI Agent 可能会产生很多中间态改动如果和主线混在一起出了问题很难回退。单独拉分支等于给 AI 的操作加了一道安全边界。6.2 把任务交给 Skill 执行器在项目根目录执行python3 .workskills/do-work-skill/run_skill.py \ --task 新增一个 GET /healthz 接口返回 JSON 格式的存活状态并补充对应测试 \ --work-dir .执行器会按 Skill 定义的步骤依次工作。在“方案规划”环节它会等待你确认计划。这时你应该检查输出的计划是否合理比如是否定位了路由注册文件是否说明了测试文件放在哪里是否考虑了接口返回结构确认后AI 继续执行编码与验证。6.3 验证闭环如何处理失败假设 AI 写完代码后验证脚本执行了真实的测试命令发现新增接口的测试用例失败原因是接口返回的 JSON 字段命名和测试用例不一致。这时run_skill.py会返回非 0 退出码并向 Agent 反馈“验证失败请修改后重新验证”。在真正使用 AI Coding Agent 时这个反馈过程可能是自动的也可能是半自动的。关键是失败信息要能被带回执行环节而不是直接断开对话。这也正是 Skill 设计里 Execute 和 Verify 必须构成循环的原因。6.4 任务完成后的交付物验证通过后Skill 会要求 AI 输出一份交付报告。报告格式可以自定义但至少应包含以下内容## 变更报告 ### 改动文件 - app/routes.py新增 /healthz 路由 - tests/test_health.py新增健康检查接口测试 ### 验证结果 - 执行 pytest -q全部用例通过 ### 风险说明 - 无已知阻塞 - 健康检查接口不依赖数据库部署时无需额外配置有了这份报告Code Review 和工作交接都会轻松很多。AI 的产出不再是“一段神秘代码”而是有上下文、有验证、有说明的完整交付。6.5 让验证脚本反映真实工程标准很多人第一次尝试这个方案时会犯一个错误验证脚本只是简单执行了echo success或者只检查文件存在根本没有真正的测试动作。这会导致整个闭环形同虚设。正确做法是把项目原有的测试命令、lint 命令、构建命令一层层填进verify.sh。例如echo 运行单元测试... pytest -q echo 检查代码风格... ruff check . echo 构建产物确认... python -m build --wheel把真实的工程检查项全部纳入验证AI 一旦提交不达标的代码脚本会立刻让它回到修改循环。7. 常见问题与排查方法Do Work Skill 方案虽然不复杂但在实际落地时经常遇到以下几类问题。这里整理成表格方便直接对照排查。问题现象可能原因排查方式解决方案Agent 执行完代码但没有跑验证命令Skill 中未明确规定验证步骤或验证命令未绑定执行流程检查 Skill 的 steps 定义中 verify 环节是否在 execute 之后强制调用将 verify 步骤设为必选并在运行脚本中设置退出码判断验证脚本一直失败但本地人工跑测试是过的验证脚本里使用了错误的工作目录、环境变量或依赖路径在验证脚本首行打印当前目录和关键环境变量用人工命令复现脚本执行过程修正脚本中的路径引用使用相对项目根目录的路径必要时用set -euo pipefail尽早暴露问题Agent 在计划环节反复问你问题迟迟不进入执行任务描述本身不清晰或提问范围过大压缩任务边界补充“本次不做”的约束检查 Skill 中的 clarify 模板是否有引导性在任务描述里给出明确的验收标准和排除项并让 Skill 中的 clarify 步骤限定提问数量AI 改完代码后原有功能被破坏且未发现测试基线不完整没有覆盖原有核心功能检查项目的测试套件是否覆盖核心流程查看 diff 是否波及无关模块先补充冒烟测试再让 AI 执行任务在 Skill 中增加“只修改任务相关文件”的约束多个成员使用不同版本的 Skill行为差异大Skill 没有纳入版本管理或仓库版本不一致检查各成员的本地工作分支和 Skill 文件更新时间将 Skill 目录纳入 Git 仓库并统一从主分支同步Agent 说验证通过但你本地运行时发现报错验证脚本与实际运行环境不一致比如依赖没装全对比验证脚本执行环境和本地运行环境的 Python/Node 版本在验证脚本中加入依赖安装或环境检查步骤例如用固定锁文件安装依赖这些问题的核心规律是大部分失败都不是模型能力不够而是 Skill 流程的设计有漏洞。比如没有强制验证、没有清晰边界、没有足够完整的测试基线。解决方案也是工程化的不是靠换更大参数的模型能解决的。8. 最佳实践与工程建议把 Do Work Skill 放到团队和生产环境里使用单靠一个 YAML 文件和两个脚本是不够的。下面这些实践经验是在实际项目中逐步积累出来的按重要程度排列。8.1 从最小项目开始不要一开始就设计“万能 Skill”很多人搭建 Skill 时会忍不住把各种场景都塞进去结果 Skill 文件变得又长又复杂Agent 反而不知道执行重点在哪里。更好的做法是先从一个小项目、一类简单任务开始只覆盖一到两种任务类型比如“新增一个接口”或“修复一个 Bug”。跑通后再迭代扩展。Skill 的设计应该像代码一样保持单一职责。一个 Skill 处理一类任务比一个超级 Skill 处理所有任务要可靠得多。8.2 把验证命令当成 Skill 的灵魂Do Work Skill 与传统提示词模板最大的分水岭就是它自带验证闭环。但验证闭环的作用完全取决于验证命令的真实水平。在工程实践里一个有效的验证命令应该具备三件事# 1. 快速失败第一条命令失败就离开退出 set -euo pipefail # 2. 覆盖核心路径至少覆盖正常路径和一个异常路径 pytest -q tests/test_health.py::test_healthz_ok pytest -q tests/test_health.py::test_healthz_method_not_allowed # 3. 输出清晰失败时打印出可读的日志 pytest -q --tbshort如果项目里还没有测试先补测试再让 AI 干活。这一步不做Skill 的验证环节就是空转。8.3 区分“允许 AI 做的”和“禁止 AI 做的”在 Skill 定义中除了告诉 AI 要做什么还应该明确列出禁止事项。一个比较通用的红线清单是禁止直接推送到主分支。禁止修改与任务无关的核心配置文件。禁止删除未知用途的历史代码。禁止忽略测试失败强行提交。禁止使用需要额外授权的生产环境权限。这些约束可以写在 Skill 文件里也可以放在项目的AGENTS.md或类似说明文件中。AI 执行前会读取并遵循。8.4 为 AI 提供最小的本地沙箱环境如果团队条件允许建议为 AI Coding Agent 提供独立的环境变量配置、测试数据库或沙箱服务而不是直接给生产环境的连接信息。原因很简单AI 在自主执行过程中可能写出有问题的 SQL 或错误调用如果连的是生产环境后果不可控。沙箱环境还要遵循最小权限原则只给任务所需的权限比如能创建测试分支但不能推送主分支。能读取测试数据库但不能写入生产表。能执行构建命令但不能修改 CI/CD 配置。8.5 详细记录执行过程AI Agent 执行任务的过程比较长如果中间出现不可预测的行为完全没有记录就会很难复盘。建议在项目中引入执行日志至少记录这些内容任务开始时间 任务描述 执行了哪些命令 修改了哪些文件 每次验证的结果 最终交付状态我的做法是在.workskills/do-work-skill/目录下增加一个run.log文件由执行脚本把每一轮动作追加写入。这样即使任务失败也有迹可循。8.6 Skill 与 CI 流程保持一致Do Work Skill 里使用的验证命令应该和 CI 的验证命令保持一致或至少在逻辑上是同等的。否则容易出现“AI 本地验证通过推到远程 CI 却挂了”的尴尬情况。理想状态是Skill 里的verify.sh直接调用 CI 里预置的检查命令比如同一个 Makefile target。这样本地验证和远程 CI 的判定标准是一致的。# 示例verify.sh 调用项目 Makefile 中进行完整检查的 target make check8.7 把 Skill 迭代当成代码管理Skill 文件一定要进入 Git 仓库。每次修改 Skill 都要像修改普通代码一样经过 Code Review、测试和记录。尤其是验证命令的修改影响范围很大改之前要明确知道它会影响哪些任务。另外一个容易被忽略的点是Skill 文件的变更说明应该写清楚“为什么改”。比如“因为验证脚本没装测试依赖导致误报所以增加依赖安装步骤。”这类信息对后续维护者非常重要。9. 总结与下一步学习方向这篇文章的核心信息可以浓缩成一句话AI Coding 真正要解决的不是“让 AI 写代码”而是“让 AI 把活干完”Do Work Skill 就是把这件事工程化的一个方案。我们用一套最小示例跑通了 Skill 的完整设计流程从任务澄清、信息收集、方案规划、执行编码到自动验证和交付报告。如果你现在项目里已经在用 AI Coding 工具我建议你先别急着去追各种新模型而是做三件事第一盘点你项目里最高频、最重复的开发任务类型。挑一个跑通 Skill 闭环。 第二检查项目的测试基线和验证命令是否足够支撑自动化验证不足的部分尽快补上。 第三把第一个 Skill 纳入 Git 仓库让团队其他成员也能看到、能复用。AI Coding 的能力边界这几年一直在快速扩展。2026 年的 Agent 已经在代码理解、工具调用、多文件修改上有了明显进步Vercel AI Vibe Coding Platform、GLM Coding Plan 等工具也在给开发者提供更顺滑的 AI 协作体验。但无论工具怎么变工程化的底层逻辑不会变一份任务必须有起点、有步骤、有验收标准最终成果必须有可验证的依据。对你来说下一步真正值得深入研究的方向可能是两点一是针对具体技术栈设计更有针对性的验证命令把单元测试、集成测试、lint 检查、构建检查全部纳入 Skill二是思考如何把 Skill 和 CI/CD 流程打通让 AI 的产出从“个人辅助验证”升级为“团队统一验证”。这两件事做好AI Coding 才算真正融入了你的开发环境而不是停留在生成代码的玩具阶段。建议把这篇文章收藏起来等你准备搭建自己的 Do Work Skill 时按里面的目录结构创建文件把 Python 脚本和 Shell 脚本改成自己项目的真实命令先跑通一个最小闭环再逐步迭代。任何流程设计都要在真实项目里跑过一遍才能知道哪里会卡住Do Work Skill 也不例外。 Do Work Skill：让AI编程助手从生成代码到完整交付的工程方案
如果你最近在项目里重度使用过 AI 编程助手大概率会遇到一种很微妙的状态AI 能写出看起来很合理的代码功能也实现了大半但离“把这件事干完”总是差那么几步。差在哪儿差在它没有检查自己有没有引入编译错误没有跑一遍完整测试没有确认这次改动和现有模块冲突也没有留下清晰的变更说明。作为工程师你最后还得花时间收拾这套半成品。换句话说AI Coding 真正难的地方不是“生成代码”而是“把活干完”。2026 年的 AI Coding 工具已经在自动补全、单文件生成、意图解析上做到相当成熟但一旦上升到真实项目交付模型推理能力和任务执行能力之间的差距就会显露出来。这正好是 Do Work Skill 这个概念要解决的问题。这篇文章要讲的不是某个模型有多强也不是某个 IDE 插件的新功能。我会把重点放在一套可复用的“Do Work Skill 解决方案”上怎样把一次开发任务拆解成 AI 能按步骤执行的流程怎样让 Agent 不只产出代码还完成验证、提交和收尾动作怎样把这种能力固化成一个 Skill 文件让团队里每个人都能直接复用。读完你会得到一套可以落到自己项目里的工程模板而不是一堆空泛的 AI Coding 概念。1. 这篇文章真正要解决的问题先说结论大多数人在 AI Coding 上遇到的瓶颈不是 AI 不够聪明而是我们没有给它一套“把工作做完”的流程。生成代码只是中间产物完成一项开发任务需要的是理解需求、制定方案、改代码、跑测试、修问题、整理提交这个完整闭环才是真正的 work。从 2026 年 8 月的 AI Coding 趋势看几件事已经非常明确第一个变化是 AI Coding Agent 正在从“聊天窗口里的代码生成器”变成“可以访问代码库、执行命令、读取测试结果的工作 Agent”。这意味着 AI 不再只是给你建议而是真的可以在你的项目里行动。第二个变化是越来越多的平台开始支持 Skill 或类似机制。Cursor、GLM Coding Plan、Vercel 的 AI Vibe Coding Platform 等产品都在往同一个方向走让开发者把常用工作流沉淀成可复用的技能包。Skill 有点像编程里的“函数封装”只不过封装的对象不是一段逻辑而是 AI 完成一类任务所需的提示词、步骤、工具调用和验证方式。第三个变化是大家开始用“数小时完成过去需要数周的开发工作”来描述 AI Coding 的收益。这种说法有营销成分但背后确实有真实的技术支撑当 Agent 能在项目里自主完成计划、编码、验证这三个环节时小规模需求的交付速度会显著提升。这篇文章会围绕 Do Work Skill 展开讲清楚它是怎么设计的、怎么落地、有哪些坑。无论你是后端工程师、前端工程师还是技术团队负责人都可以从中找到适合自己的接入方式。适合读这篇文章的人大概是这三类已经在用 AI 写代码但觉得 AI 只能“写出来”不能“干完活”的开发者。想让团队统一 AI 协作方式而不是每个人都靠自己的即时提问技巧来驱动 AI 的工程负责人。对 AI Coding Agent、Vibe Coding 这类新工作方式感兴趣想了解 Skill 机制背后设计思路的人。下面进入正题。2. 从“写代码”到“干完活”AI Coding 的认知转变要把 Do Work Skill 讲明白得先理解 AI Coding 这几年经历的三次工作模式变化。这三种模式到现在仍然并存但解决的问题层级完全不同。2.1 第一种模式交互式代码生成这是大家最熟悉的模式。你在 IDE 里装一个 AI 插件选中一段代码让 AI 补全、解释或者重构。它的工作单元是“代码片段”交互方式是“人提问AI 回答”。这种模式的优势是门槛低、反馈快。缺点是 AI 对整个项目的状态几乎无感知它不知道你的测试框架是什么版本不知道你项目的目录约定也不知道这次改动会影响哪些模块。结果是 AI 生成的代码经常和项目风格不一致放到项目里跑不起来你得手动修复。交互式代码生成适合碎片化任务但它本质上是一个更聪明的“搜索引擎”而不是一个能干活的同事。2.2 第二种模式Agent 自动执行Agent 模式和对话式补全最本质的区别是Agent 可以主动使用工具。它能看到你的文件树能读取文件内容能执行 shell 命令能查看测试结果然后根据这些结果调整自己的下一步动作。现在主流的 AI Coding Agent 基本都具备了这些能力。你给它一个任务比如“把用户登录接口从 JWT 换成 Session 方案”它理论上可以自己完成先扫描认证相关代码确定改动范围修改代码跑测试再根据测试失败信息继续修。但这里出现了一个很现实的问题如果没有明确约束Agent 经常会在某个环节停下来。它可能改了代码但没跑测试就告诉你完成了可能在测试失败后尝试两次就放弃了也可能在任务稍微复杂时把上下文搞得一团乱。原因不是模型弱而是它缺少“工作流”层面的引导。2.3 第三种模式Skill 驱动的工作流Skill 驱动模式解决的就是 Agent 的“行为过程”问题。它把任务的执行方式、验证标准、交付格式预先定义好然后让 Agent 按照这套流程去执行。这样做有三个好处可复用。团队里总结出的最佳实践可以沉淀成 Skill 文件新成员使用同样的流程完成任务。可预期。Skill 定义了每一步要做什么、做完怎么验证Agent 的完成质量更稳定。可收敛。就算任务执行到一半出问题Skill 也定义了回退和报告机制不会让 Agent 无限发散。用编程类比来说交互式代码生成像你在终端里手动敲命令每次都要重新输入Agent 自动执行像你写了一段自动化脚本但脚本里的每个步骤都是硬编码的而 Skill 驱动模式像一个封装好的函数有输入参数、有标准执行体、有返回值你可以随时调用它去处理同类任务。这三种模式的对比可以看这张表维度交互式代码生成Agent 自动执行Skill 驱动工作流AI 参与方式辅助生成自主执行部分环节按流程完成完整任务闭环上下文感知弱通常只看当前文件中可读项目相关文件强有明确的信息采集和任务边界定义产出质量不稳定依赖提问质量中等容易中途停滞稳定自带验证闭环可复用性低低高适合场景单点问题、快速补全任务边界清晰的开发项重复性、流程化、需要交付保障的任务3. Do Work Skill 的设计原理与核心概念现在可以正式讨论 Do Work Skill 了。从字面理解Do Work Skill 是一组让 AI 完成实际工作的技能定义。但这里的关键不是“Skill”这个文件格式而是它背后对“工作”这件事的拆解方式。3.1 什么是“把活干完”一个 AI 任务要被认为是“干完了”至少应该满足四个条件结果可见改动确实被写进了代码库而不是只停留在对话窗口里。质量可验证有测试、命令或人工检查方式能证明改动符合预期。上下文完整AI 在任务过程中需要的信息已经被定位和确认过而不是靠猜。交接清楚任务完成后AI 能说明改了哪些文件、为什么这么改、还有什么风险。这四个条件看起来简单但很多 AI Coding 场景都做不到。最常见的情况是AI 给出一段“看起来能跑”的代码但没检查你项目的依赖版本、没验证边界条件、没考虑和已有代码的兼容性。原因就是缺少一个强制性的验证和收尾环节。3.2 Do Work Skill 的五个核心环节一个完整的 Do Work Skill 通常包含以下五个环节我在设计自己的 Skill 时基本都会按这个框架来3.2.1 任务澄清ClarifyAI 在动手之前先用自己的话复述一遍任务明确完成标准和验收方式。这个步骤看起来多余但价值很高它能提前暴露理解偏差避免 AI 做了一半才发现方向不对。3.2.2 信息收集ContextAI 需要主动定位与任务相关的代码文件、配置项、数据结构和依赖关系。在这个环节Skill 应该给 AI 一个检查清单比如涉及哪些目录、需要读哪些配置文件、有没有类似的历史实现可以参考。3.2.3 方案规划PlanAI 输出一个分步执行计划每步要有明确的产出物。比如第一步新增数据库迁移文件产出物是 migration SQL第二步修改 Service 层产出物是改动的代码 diff第三步补充测试用例产出物是测试文件。计划要可回滚每个步骤都能独立验证。3.2.4 执行与自查Execute Self-ReviewAI 按照计划执行每一步并在执行后对代码做一轮自查。自查内容包括是否有未使用的变量、是否有明显逻辑漏洞、是否遵循项目现有的命名规范。这一步最容易出问题的地方是 AI 认为自己生成的代码没问题但实际跑编译或测试就报错。所以要尽量把执行和验证绑在一起。3.2.5 验证与交付Verify ReportAI 运行测试并报告结果只有验证通过才算完成。如果验证失败AI 需要根据错误信息回到执行环节继续修改而不是直接把失败结果交给你。最终交付时AI 应该输出一个简短报告改动清单、验证结果、已知风险、后续建议。这五个环节的本质是把一名工程师的思考过程外化成 AI 能遵循的流程。很多 AI Coding 项目失败的共同原因是缺少其中某一环最常见的就是跳过验证直接交付。3.3 Do Work Skill 与传统 Prompt 的区别有些人会问这不就是写一个 Prompt 吗为什么还要叫“Skill 解决方案”区别在于三个层面第一Prompt 是即时的Skill 是持久的。Prompt 只在当前对话里生效而 Skill 可以沉淀成一个独立文件被不同的任务、不同的项目反复调用。第二Prompt 只约束“怎么说”Skill 还能定义“怎么做”。Skill 文件里可以写明工具调用方式、验证命令、完成标准这些不是单纯的文字提示而是可执行的工程规范。第三Prompt 通常没有版本管理Skill 可以纳入代码仓库。这就意味着 Skill 本身可以 review、可以迭代、可以像代码一样做版本管理。这对团队协作的意义非常大。4. 环境准备与前置条件在写 Do Work Skill 的完整示例之前先把环境说清楚。以下是通用建议具体版本请以你项目的实际情况为准下面代码演示重点讲通用实现思路不会把版本号写死。4.1 需要一个可执行命令的 Agent 运行时Do Work Skill 要真正“干完活”前提是 AI 能执行命令、读写文件。也就是说你不能只在网页聊天窗口里用模型必须有本地 IDE 插件、CLI 工具或 Agent 平台支持。常见的可选方案包括Cursor 或同类 AI IDE开启 Agent 模式。支持 MCP 或 Tool Use 的 AI CLI 工具。可以使用 Shell 命令的 Agent 平台。选择标准很简单这个工具必须能读取指定文件内容执行指定 shell 命令并读取命令输出。三项能力缺一不可。4.2 项目代码需要纳入版本管理因为 Skill 流程里会包含 diff、提交、回滚等动作项目最好是 Git 仓库并且在开始执行任务前处于干净状态或者有清晰的分支。建议在实际项目中为 AI 任务单独拉一个分支不要直接在主干上执行。4.3 有可运行的测试基线无论项目是前端、后端还是移动端都应该有至少一条能自动运行的验证命令。这个命令不一定是最完整的单测套件但必须能在几秒或几分钟内跑完用来判断 AI 的改动是否破坏了已有功能。如果没有测试基线建议先补充一个 smoke test否则 Do Work Skill 里“验证闭环”这一环就失去了实际意义。4.4 准备好 Skill 文件目录我习惯在项目仓库里创建.workskills/目录把 Skill 定义和相关脚本放在里面。你可以在团队内部建立自己的约定但建议做到以下三点Skill 文件纳入版本管理方便评审和回滚。Skill 目录里避免放机密信息和绝对路径。Skill 文件命名和目录结构保持统一。接下来我们用一个最小示例来把整个方案跑通。5. 最小可用 Do Work Skill 的完整示例这个示例的目标是定义一套 Skill让 AI Coding Agent 能按“澄清上下文 → 制定计划 → 执行编码 → 自动验证 → 输出报告”的流程完成一个小型开发任务。为了保持简单示例采用一个 YAML 文件定义 Skill配合一个 Python 脚本和 Shell 脚本来实现执行与验证逻辑。5.1 定义 Skill 元信息创建一个文件.workskills/do-work-skill/skill.yamlname: do-work-skill version: 0.1.0 description: 通用开发任务执行 Skill要求 Agent 按“澄清-计划-执行-验证-报告”闭环完成工作。 trigger: - 用户提出一个开发任务如功能开发、Bug 修复、接口调整 inputs: task: description: 要执行的开发任务描述 required: true work_dir: description: 任务所在项目目录默认当前工作目录 required: false steps: - id: clarify name: 任务澄清 description: 用自己的话复述任务列出完成标准和验收方式在动手前向用户确认。 - id: context name: 信息收集 description: 定位相关代码文件、配置项和测试文件阅读后记录关键内容。 - id: plan name: 方案规划 description: 输出分步执行计划每步带可验证的产出物。 - id: execute name: 执行编码 description: 按计划修改代码每次修改保证语法正确必要时补充测试用例。 - id: verify name: 自动验证 description: 运行配置好的验证命令必须全部通过失败则回到 execute 步骤继续修改。 - id: report name: 交付报告 description: 输出改动文件列表、验证结果、已知风险和后续建议。 verify: command: bash .workskills/do-work-skill/verify.sh timeout: 120这个 YAML 文件的作用不是给代码库直接运行而是给 AI Agent 提供一套工作指引。不同 Agent 工具的 Skill 格式可能不同这里的核心是五个步骤的设计格式你可以根据实际工具调整。5.2 编写执行辅助脚本为了让 Skill 不只是一个“提示词”还需要一个可执行的辅助脚本负责解析任务和记录每一步的执行结果。先创建一个 Python 脚本.workskills/do-work-skill/run_skill.py#!/usr/bin/env python3 Do Work Skill 的轻量执行器示例。 这个脚本的作用不是代替 Agent 完成编码而是为 Skill 提供 1) 任务解析与步骤记录的骨架 2) 分步执行的日志输出 3) 调用验证脚本的统一入口。 import argparse import subprocess import sys import time from pathlib import Path def log_step(step_id: str, message: str) - None: timestamp time.strftime(%Y-%m-%d %H:%M:%S) print(f[{timestamp}] [step:{step_id}] {message}, flushTrue) def run_verify(work_dir: Path) - bool: verify_script work_dir / .workskills / do-work-skill / verify.sh if not verify_script.exists(): print(fverify 脚本不存在{verify_script}) return False print( 执行自动验证...) result subprocess.run([bash, str(verify_script)], cwdstr(work_dir), capture_outputTrue, textTrue) if result.stdout: print(result.stdout) if result.stderr: print(result.stderr, filesys.stderr) return result.returncode 0 def main() - int: parser argparse.ArgumentParser(descriptionDo Work Skill 轻量执行器) parser.add_argument(--task, requiredTrue, help要执行的开发任务描述) parser.add_argument(--work-dir, default., help项目根目录默认当前目录) args parser.parse_args() work_dir Path(args.work_dir).resolve() log_step(clarify, f收到任务{args.task}) log_step(context, 请 Agent 阅读项目 README、目录结构和关联测试文件。) log_step(plan, 请 Agent 输出分步实施计划并等待用户确认。) proceed input(是否确认计划并开始执行[y/N]: ).strip().lower() if proceed not in (y, yes): log_step(plan, 用户未确认计划任务终止。) return 0 log_step(execute, 开始编码执行请 Agent 在编码过程中保持项目现状可运行。) ok run_verify(work_dir) if ok: log_step(verify, 所有验证命令通过。) log_step(report, 交付完成请输出改动文件清单、验证结果与风险说明。) return 0 else: log_step(verify, 验证失败请根据错误信息返回 execute 步骤继续修改。) return 1 if __name__ __main__: sys.exit(main())5.3 编写验证脚本再创建一个 Shell 脚本.workskills/do-work-skill/verify.sh#!/usr/bin/env bash # 通用验证入口在测试环境或本地验证本次改动是否影响已有功能。 # 注意实际项目中请根据技术栈替换为真实的测试命令。 set -euo pipefail echo 检查项目必要配置文件... if [ ! -f README.md ]; then echo 错误项目缺少 README.md请先确认项目结构正确。 exit 1 fi # 这里替换为你项目的真实测试命令例如 # pytest -q # npm test # go test ./... echo 运行测试... # pytest -q # npm test echo 验证通过需要注意的是这个脚本里我故意用注释代替了真实测试命令因为不同技术栈差异太大。你在实际项目里应该把pytest -q、npm test或go test ./...这类真实命令填进去才能起到验证作用。5.4 给 Skill 添加必要的执行权限在命令行里执行下面的命令给脚本添加执行权限chmod x .workskills/do-work-skill/run_skill.py chmod x .workskills/do-work-skill/verify.sh到这里一个最小可用的 Do Work Skill 就搭好了。它不是什么宏大系统但已经具备“工作流”的雏形任务先澄清、信息再收集、计划要确认、执行完要验证、验证完要报告。用更通俗的话说我们终于给 AI Coding 装了一个“验收环节”不让它随便交半成品。6. 把 Skill 接入真实项目任务流与验证闭环有了最小示例下一步就是在真实项目里跑起来。这里我会用一个贴近现实的场景来演示假设的项目是一个 Python Web 后端目标是“新增一个健康检查接口/healthz”。6.1 准备任务分支先创建一个新分支保证主分支不被 AI 的实验性改动污染git checkout -b feat/healthz-with-ai这一步很重要的原因是AI Agent 可能会产生很多中间态改动如果和主线混在一起出了问题很难回退。单独拉分支等于给 AI 的操作加了一道安全边界。6.2 把任务交给 Skill 执行器在项目根目录执行python3 .workskills/do-work-skill/run_skill.py \ --task 新增一个 GET /healthz 接口返回 JSON 格式的存活状态并补充对应测试 \ --work-dir .执行器会按 Skill 定义的步骤依次工作。在“方案规划”环节它会等待你确认计划。这时你应该检查输出的计划是否合理比如是否定位了路由注册文件是否说明了测试文件放在哪里是否考虑了接口返回结构确认后AI 继续执行编码与验证。6.3 验证闭环如何处理失败假设 AI 写完代码后验证脚本执行了真实的测试命令发现新增接口的测试用例失败原因是接口返回的 JSON 字段命名和测试用例不一致。这时run_skill.py会返回非 0 退出码并向 Agent 反馈“验证失败请修改后重新验证”。在真正使用 AI Coding Agent 时这个反馈过程可能是自动的也可能是半自动的。关键是失败信息要能被带回执行环节而不是直接断开对话。这也正是 Skill 设计里 Execute 和 Verify 必须构成循环的原因。6.4 任务完成后的交付物验证通过后Skill 会要求 AI 输出一份交付报告。报告格式可以自定义但至少应包含以下内容## 变更报告 ### 改动文件 - app/routes.py新增 /healthz 路由 - tests/test_health.py新增健康检查接口测试 ### 验证结果 - 执行 pytest -q全部用例通过 ### 风险说明 - 无已知阻塞 - 健康检查接口不依赖数据库部署时无需额外配置有了这份报告Code Review 和工作交接都会轻松很多。AI 的产出不再是“一段神秘代码”而是有上下文、有验证、有说明的完整交付。6.5 让验证脚本反映真实工程标准很多人第一次尝试这个方案时会犯一个错误验证脚本只是简单执行了echo success或者只检查文件存在根本没有真正的测试动作。这会导致整个闭环形同虚设。正确做法是把项目原有的测试命令、lint 命令、构建命令一层层填进verify.sh。例如echo 运行单元测试... pytest -q echo 检查代码风格... ruff check . echo 构建产物确认... python -m build --wheel把真实的工程检查项全部纳入验证AI 一旦提交不达标的代码脚本会立刻让它回到修改循环。7. 常见问题与排查方法Do Work Skill 方案虽然不复杂但在实际落地时经常遇到以下几类问题。这里整理成表格方便直接对照排查。问题现象可能原因排查方式解决方案Agent 执行完代码但没有跑验证命令Skill 中未明确规定验证步骤或验证命令未绑定执行流程检查 Skill 的 steps 定义中 verify 环节是否在 execute 之后强制调用将 verify 步骤设为必选并在运行脚本中设置退出码判断验证脚本一直失败但本地人工跑测试是过的验证脚本里使用了错误的工作目录、环境变量或依赖路径在验证脚本首行打印当前目录和关键环境变量用人工命令复现脚本执行过程修正脚本中的路径引用使用相对项目根目录的路径必要时用set -euo pipefail尽早暴露问题Agent 在计划环节反复问你问题迟迟不进入执行任务描述本身不清晰或提问范围过大压缩任务边界补充“本次不做”的约束检查 Skill 中的 clarify 模板是否有引导性在任务描述里给出明确的验收标准和排除项并让 Skill 中的 clarify 步骤限定提问数量AI 改完代码后原有功能被破坏且未发现测试基线不完整没有覆盖原有核心功能检查项目的测试套件是否覆盖核心流程查看 diff 是否波及无关模块先补充冒烟测试再让 AI 执行任务在 Skill 中增加“只修改任务相关文件”的约束多个成员使用不同版本的 Skill行为差异大Skill 没有纳入版本管理或仓库版本不一致检查各成员的本地工作分支和 Skill 文件更新时间将 Skill 目录纳入 Git 仓库并统一从主分支同步Agent 说验证通过但你本地运行时发现报错验证脚本与实际运行环境不一致比如依赖没装全对比验证脚本执行环境和本地运行环境的 Python/Node 版本在验证脚本中加入依赖安装或环境检查步骤例如用固定锁文件安装依赖这些问题的核心规律是大部分失败都不是模型能力不够而是 Skill 流程的设计有漏洞。比如没有强制验证、没有清晰边界、没有足够完整的测试基线。解决方案也是工程化的不是靠换更大参数的模型能解决的。8. 最佳实践与工程建议把 Do Work Skill 放到团队和生产环境里使用单靠一个 YAML 文件和两个脚本是不够的。下面这些实践经验是在实际项目中逐步积累出来的按重要程度排列。8.1 从最小项目开始不要一开始就设计“万能 Skill”很多人搭建 Skill 时会忍不住把各种场景都塞进去结果 Skill 文件变得又长又复杂Agent 反而不知道执行重点在哪里。更好的做法是先从一个小项目、一类简单任务开始只覆盖一到两种任务类型比如“新增一个接口”或“修复一个 Bug”。跑通后再迭代扩展。Skill 的设计应该像代码一样保持单一职责。一个 Skill 处理一类任务比一个超级 Skill 处理所有任务要可靠得多。8.2 把验证命令当成 Skill 的灵魂Do Work Skill 与传统提示词模板最大的分水岭就是它自带验证闭环。但验证闭环的作用完全取决于验证命令的真实水平。在工程实践里一个有效的验证命令应该具备三件事# 1. 快速失败第一条命令失败就离开退出 set -euo pipefail # 2. 覆盖核心路径至少覆盖正常路径和一个异常路径 pytest -q tests/test_health.py::test_healthz_ok pytest -q tests/test_health.py::test_healthz_method_not_allowed # 3. 输出清晰失败时打印出可读的日志 pytest -q --tbshort如果项目里还没有测试先补测试再让 AI 干活。这一步不做Skill 的验证环节就是空转。8.3 区分“允许 AI 做的”和“禁止 AI 做的”在 Skill 定义中除了告诉 AI 要做什么还应该明确列出禁止事项。一个比较通用的红线清单是禁止直接推送到主分支。禁止修改与任务无关的核心配置文件。禁止删除未知用途的历史代码。禁止忽略测试失败强行提交。禁止使用需要额外授权的生产环境权限。这些约束可以写在 Skill 文件里也可以放在项目的AGENTS.md或类似说明文件中。AI 执行前会读取并遵循。8.4 为 AI 提供最小的本地沙箱环境如果团队条件允许建议为 AI Coding Agent 提供独立的环境变量配置、测试数据库或沙箱服务而不是直接给生产环境的连接信息。原因很简单AI 在自主执行过程中可能写出有问题的 SQL 或错误调用如果连的是生产环境后果不可控。沙箱环境还要遵循最小权限原则只给任务所需的权限比如能创建测试分支但不能推送主分支。能读取测试数据库但不能写入生产表。能执行构建命令但不能修改 CI/CD 配置。8.5 详细记录执行过程AI Agent 执行任务的过程比较长如果中间出现不可预测的行为完全没有记录就会很难复盘。建议在项目中引入执行日志至少记录这些内容任务开始时间 任务描述 执行了哪些命令 修改了哪些文件 每次验证的结果 最终交付状态我的做法是在.workskills/do-work-skill/目录下增加一个run.log文件由执行脚本把每一轮动作追加写入。这样即使任务失败也有迹可循。8.6 Skill 与 CI 流程保持一致Do Work Skill 里使用的验证命令应该和 CI 的验证命令保持一致或至少在逻辑上是同等的。否则容易出现“AI 本地验证通过推到远程 CI 却挂了”的尴尬情况。理想状态是Skill 里的verify.sh直接调用 CI 里预置的检查命令比如同一个 Makefile target。这样本地验证和远程 CI 的判定标准是一致的。# 示例verify.sh 调用项目 Makefile 中进行完整检查的 target make check8.7 把 Skill 迭代当成代码管理Skill 文件一定要进入 Git 仓库。每次修改 Skill 都要像修改普通代码一样经过 Code Review、测试和记录。尤其是验证命令的修改影响范围很大改之前要明确知道它会影响哪些任务。另外一个容易被忽略的点是Skill 文件的变更说明应该写清楚“为什么改”。比如“因为验证脚本没装测试依赖导致误报所以增加依赖安装步骤。”这类信息对后续维护者非常重要。9. 总结与下一步学习方向这篇文章的核心信息可以浓缩成一句话AI Coding 真正要解决的不是“让 AI 写代码”而是“让 AI 把活干完”Do Work Skill 就是把这件事工程化的一个方案。我们用一套最小示例跑通了 Skill 的完整设计流程从任务澄清、信息收集、方案规划、执行编码到自动验证和交付报告。如果你现在项目里已经在用 AI Coding 工具我建议你先别急着去追各种新模型而是做三件事第一盘点你项目里最高频、最重复的开发任务类型。挑一个跑通 Skill 闭环。 第二检查项目的测试基线和验证命令是否足够支撑自动化验证不足的部分尽快补上。 第三把第一个 Skill 纳入 Git 仓库让团队其他成员也能看到、能复用。AI Coding 的能力边界这几年一直在快速扩展。2026 年的 Agent 已经在代码理解、工具调用、多文件修改上有了明显进步Vercel AI Vibe Coding Platform、GLM Coding Plan 等工具也在给开发者提供更顺滑的 AI 协作体验。但无论工具怎么变工程化的底层逻辑不会变一份任务必须有起点、有步骤、有验收标准最终成果必须有可验证的依据。对你来说下一步真正值得深入研究的方向可能是两点一是针对具体技术栈设计更有针对性的验证命令把单元测试、集成测试、lint 检查、构建检查全部纳入 Skill二是思考如何把 Skill 和 CI/CD 流程打通让 AI 的产出从“个人辅助验证”升级为“团队统一验证”。这两件事做好AI Coding 才算真正融入了你的开发环境而不是停留在生成代码的玩具阶段。建议把这篇文章收藏起来等你准备搭建自己的 Do Work Skill 时按里面的目录结构创建文件把 Python 脚本和 Shell 脚本改成自己项目的真实命令先跑通一个最小闭环再逐步迭代。任何流程设计都要在真实项目里跑过一遍才能知道哪里会卡住Do Work Skill 也不例外。