从提示词到Do Work Skill：构建AI Coding任务闭环的工程化方案

做 AI Coding 的人最近基本绕不开一个词Do Work Skill。它不是某一个模型的版本号也不是某个 IDE 插件的隐藏功能而是一种工程化思路把 AI 从“能生成代码”变成“能真正把一件事做完”。这事听起来简单真正落地时却会牵出任务拆解、上下文管理、执行循环、结果验证、日志审计一整套流程。我这两周一直在用这个思路重构自己的 AI 编码工作流今天把构建 Do Work Skill 解决方案的过程整理出来适合那些已经用过 AI 编程助手、但对“让 AI 稳定交付”还不满意的工程师。我不打算绑定某一款具体工具。Vercel 这类平台有 vibe coding 方案GLM、Claude、GPT 系列也都有各自的 coding plan但工具迭代太快今天写某个按钮在哪明天界面就变了。我更建议把注意力放在通用方法上无论你用哪种 AI Coding Agent只要按这套思路去搭 Skill都能减少“随机成功”的比例。1. 先搞清楚什么是“Do Work Skill”以及为什么普通提示词不够用1.1 提示词解决的是“生成”Skill 解决的是“闭环”很多工程师对 AI 编程的认知还停留在“写一段提示词让 AI 生成代码”。这种用法适合解决零散问题写一个正则、补一个函数、解释一段报错。但遇到“把一个功能完整落地”的任务单条提示词几乎必然翻车。原因很简单AI 生成的是文本片段而工程项目要求的是闭环——需求明确、代码改动、运行验证、错误修复、验收交付五个环节只要断一个结果都不可用。Do Work Skill 解决的就是这个闭环问题。它不是一句提示词而是一套可执行流程。这套流程里包含了任务理解、上下文收集、执行步骤、验证标准、失败回退策略甚至还包括 AI 在执行过程中如何写日志、如何请求人工确认。你可以把它理解成一个“岗位说明书”不只是告诉 AI 要做什么还要告诉它做到什么程度算完成、中间卡住了怎么办、哪些决策必须交给人类。1.2 一个 Skill 的基本组成部分我在实际使用中会把一个 Do Work Skill 拆成四个部分组成部分作用举例任务解析器把自然语言需求转成可执行任务列表“修复登录超时 bug”转成“复现问题、定位超时点、修改代码、跑测试”上下文管理器决定哪些信息可以给 AI哪些不该给只注入相关模块代码而不是整个仓库执行循环让 AI 改代码、跑验证、看日志、再修改循环执行“修改 → 运行测试 → 检查输出”验收器判断任务是否真正完成检查测试是否通过、代码格式是否合规、是否引入新问题这四部分缺一不可。很多人只搭了“任务解析器”和“上下文管理器”结果 AI 能输出方案但落不了地还有人只做了“执行循环”但任务目标不清晰AI 自己跑偏了都不知道。我建议你从最小闭环开始先别追求复杂编排。第一个 Skill 只需要能完成“单文件修改 一次运行验证”能稳定跑通之后再往上加批处理、队列、多 Agent 协作。2. 构建前先定边界什么样的任务适合做成 Do Work Skill2.1 适合做成 Skill 的任务特征不是所有任务都值得做成 Do Work Skill。如果任务太简单直接用自然语言提问就行套一层 Skill 反而增加开销。根据我的实测适合做 Skill 的任务通常有这些特征任务重复出现同样的流程可以复用到不同代码库。有明确验收标准比如测试通过、无 lint 错误、性能指标达标。需要多步操作单次生成无法完成必须配合修改和验证。错误成本可控AI 做错后能被发现也能被纠正。举一个典型例子给一个 Python 项目“新增一个 REST API 端点”。这个任务看起来简单但真正做的时候涉及路由注册、参数校验、错误处理、单元测试、文档更新如果只是让 AI“写一段 Flask 代码”它很容易只给你一个片段而不是完整交付。但如果做成 Skill这个流程就可以标准化。2.2 不适合的任务或者至少要先切碎有些任务不适合直接丢给 AI Coding Agent尤其是下面这些涉及大规模架构决策比如“重构整个微服务的拆分方式”。需要敏感权限比如直接操作生产数据库。需求本身模糊到连工程师都无法描述验收标准。项目结构极度混乱连上下文打包都做不到。遇到这类任务我的做法是先把大任务切成子任务。架构决策自己先定方向把 AI 限制在具体实现层生产环境操作拆成“生成脚本”和“人工执行”两步AI 只负责写脚本和检查脚本不直接执行。这不是不信任 AI而是把风险边界划清晰。一个 Skill 的输入越明确输出越可控。2.3 验收标准写在前面比写在后面重要构建 Skill 时最容易被忽略的是验收标准。很多人的流程是“让 AI 改代码 → 跑一下测试 → 绿了就收工”但“测试绿了”并不等于“任务完成”。测试覆盖不足时AI 可能只是修好了表面问题深层逻辑还是错的。我建议在 Skill 里显式写入验收清单。比如所有已有测试是否通过。新代码是否有对应的测试用例。是否引入类型检查或 lint 错误。是否修改了无关文件。性能指标是否在允许范围内。验收标准越具体AI 的行为就越收敛。不要只写“请确保质量”要写“运行 pytest必须全部通过新增代码行覆盖率不低于 80%”。模糊的标准会让 AI 自己定义什么叫“完成”这往往是跑偏的开始。3. 按执行循环搭一个最小可用的 Skill 骨架3.1 需求拆解把自然语言变成任务清单一个 AI Coding Agent 拿到任务后的第一件事应该是拆解需求而不是直接写代码。这个环节我踩过很多坑早期我在提示词里写“请修复登录超时问题”AI 直接改了一个 cookie 过期时间看起来合理但根因其实是 Redis 连接池配置错误。它没有先排查就直接“猜”了一个原因。为了避免这种情况我会在 Skill 中加一步强制性的“需求复述与拆解”。AI 必须先输出它理解的任务清单并标注哪些是已知事实、哪些是假设等人工确认后再开始执行。这一步能在早期拦截大量误解。一个完整的任务清单可能长这样复现用户反馈的“登录超时”。查看服务端日志定位超时发生在认证阶段还是会话验证阶段。检查配置文件中的 Redis 心跳超时参数。修改配置或代码确保网络抖动时不会误判会话失效。运行集成测试验证连续 100 次登录无超时。输出变更说明并附上测试结果日志。3.2 上下文打包不是把整个仓库丢给模型性能再强的模型上下文窗口也是有限资源。很多工程师习惯把整个项目目录扔给 AI让它“自己找”结果模型被无关代码淹没生成的代码反而丢失了对关键模块的关注。更稳妥的方式是在 Skill 中定义上下文收集规则先让 AI 基于任务关键词列出需要查看的文件列表。只读取和任务直接相关的文件包括配置、测试用例、流水线脚本。涉及接口时同时读取调用方和被调用方的代码。涉及数据模型时把表结构或 ORM 模型一并贴上。我通常会把上下文限制在 10 到 20 个文件以内。如果任务确实涉及整个项目那就说明拆分粒度还不够小。上下文打得好AI 的准确率会明显提升上下文塞得太多模型会“犹豫”输出质量和稳定性都会下降。3.3 执行循环修改、运行、看日志、再修改真正的 Do Work Skill 核心是“执行循环”。AI 改完代码后不能直接提交结果必须自己运行验证、检查输出、判断是否通过再决定继续修改还是收尾。这个循环可以表达成伪代码while task_list is not empty: step pop next task apply code change run validation command collect logs / output if validation passed: record result continue else: analyze logs with max 3 attempts if still failing: mark step as blocked request human review这里的关键是“循环次数要有限制”。如果没有限制AI 可能陷入不断修改、不断失败的无限循环浪费 tokens 和人力。我一般设置最多三次自动重试三次之后必须停下来让工程师介入。这不是能力问题而是防止 AI 在小问题上反复打转。执行循环还有一个容易被忽略的点每次修改的日志要保留。不管是修改前、修改后、测试结果还是 AI 的判断依据都应该写入日志文件。否则 AI 修了三轮最终修好了但没人知道它到底改了什么下次遇到同类问题又从头开始。3.4 用一个小样本任务验证 Skill 是否闭环Skill 搭好之后第一件事不是拿真实任务去试而是造一个“小样本任务”。比如我搭“新增 API 端点”的 Skill 时会先用一个测试项目验证项目里故意放一个缺失参数校验的已知问题看 Skill 能不能按流程发现并修复。这个小样本任务要满足三个条件任务足够小几分钟内能跑完。里面包含一个“设计好的坑”用来观察 AI 是否会跳过排查直接猜答案。验收标准明确能判断 AI 是否走到了“验证通过”这一步而不是“看起来完成了”。小样本验证通过后再拿真实任务进行灰度测试。不要一上来就把最重要的业务模块交给 AI 全自动处理先让它在可回滚的模块上跑几轮确认稳定性后再扩大范围。4. 把单次成功变成可复用方案模板、参数、日志4.1 把 Skill 拆成模板和参数单次成功只能算“碰巧”可复用才是“方案”。我把一个可复用的 Skill 拆成“模板”和“参数”两层。模板是不变的执行流程参数是根据具体任务变化的输入。拿“修复测试失败”这个 Skill 举例模板部分说明任务输入失败的测试名称、错误日志、相关代码路径分析阶段定位失败原因区分是断言错误、环境问题还是代码回归修复阶段修改实现代码不允许直接修改测试来达到通过目的验证阶段运行该测试、运行整组相关测试、运行 lint输出阶段输出变更 diff、测试结果、根因说明参数部分说明test_command当前项目实际使用的测试命令test_path指定测试文件或测试用例max_attempts最大自动修复次数常用 3lint_command代码风格检查命令模板写好后参数可以从一个配置文件读取。这样在不同项目之间复用 Skill 时只需要改参数文件而不用重写整个流程。4.2 输入输出规范文件、约定、检查点可复用方案还需要定义输入输出规范。我常用的约定是所有任务请求放到tasks/目录一个任务一个 Markdown 文件。执行结果写到output/目录包括变更 diff、测试日志、状态 summary。每个任务分配一个 ID命名格式如task_YYYYMMDD_HHMM便于回溯。涉及人工确认的地方在任务文件里写blocked标记。这套约定看起来朴素但能解决一个重要问题AI Coding Agent 执行任务时人类需要知道当前进展。没有这些检查点你只能盯着终端看既低效又容易漏掉问题。有了输出目录和任务状态标记你可以随时打开任务文件了解 AI 执行到哪一步、为什么停下来了、下一步计划是什么。4.3 让 AI 自己写“操作日志”便于人工审计很多人忽略日志的作用觉得只要代码能跑就行。但当你让 AI 批量处理任务时日志是唯一能还原过程的依据。我的 Skill 模板里会强制要求 AI 按固定格式记录日志## 执行记录 - 任务IDtask_20260801_1430 - 执行阶段分析 / 修改 / 验证 / 阻塞 - 输入文件src/user_auth.py - 修改内容调整 Redis 心跳超时判断逻辑 - 验证命令pytest tests/test_auth.py -x -q - 验证结果通过18 passed, 0 failed - 阻塞点无 - 人工确认需求无需有了这样的日志你就不需要重新打开代码去猜 AI 做了什么。出了问题时也能快速定位是上下文不完整、执行循环设计不合理还是验收标准没写清楚。日志不是为了审计而审计它是反馈循环的一部分用来持续改进 Skill 本身。5. 批量化和人机协同从“帮我写代码”进化到“帮我交付任务”5.1 任务队列和批处理的注意事项单任务 Skill 跑通后自然想做的事就是批量。比如一次性给 50 个测试失败用例做自动修复或者一次性给前端页面批量应用样式调整。批量处理能极大提升效率但也会放大问题。我建议首次上批量时遵循“先跑 3 个、再跑 10 个、最后跑全量”的节奏先选 3 个不同类型的问题观察 AI 是否都能正确闭环。再选 10 个观察队列是否稳定有没有任务互相干扰。最后才扩大到全量同时设置最大并发数。批量任务失败时最忌讳的是“整体失败重跑”。一个任务失败、其他任务全部作废浪费资源不说日志也会变得混乱。正确的做法是让每个任务独立记录状态失败任务单独重试重试超过次数后标记为 blocked 等待人工处理。5.2 人工检查点什么时候必须插入让 AI 全自动完成任务始终存在风险所以 Skill 设计里必须有人工检查点。我会在以下情况下强制插入人工确认修改涉及数据库迁移或数据结构变更。需要删除代码或文件尤其是看起来“未使用”的代码。需要修改鉴权、权限判断相关逻辑。AI 连续重试 2 次以上仍失败准备改变方向时。变更影响范围超过 3 个模块或 10 个文件。插入人工检查点不能靠 AI 自觉要在 Skill 模板里写成硬性条件。比如“当检测到 delete 操作时停止执行并输出待删文件清单等待人工确认”。没有这个硬性约束AI 很容易因为上下文遗漏而做出不可逆的改动。5.3 从单 Skill 到多 Skill 的编排当你的 Skill 数量变多比如已经有了“修复测试失败”“新增 API 端点”“前端组件改版”三个 Skill你会发现有些任务需要按顺序调用多个 Skill。这时候引入简单的编排层会很有效。编排层可以是一个脚本也可以是一个提示词模板核心功能是决定当前任务进入哪个 Skill。上一个 Skill 的输出如何转换成下一个 Skill 的输入。哪个阶段需要人工确认。整体失败时如何回滚。我不建议一开始就上复杂的 Agent 编排框架。先用一个简单的 JSON 或 YAML 配置文件把流程描述清楚跑一段时间后再根据实际瓶颈决定是否引入更重的调度系统。6. 实测中常见的坑为什么 AI 经常“看起来很努力结果不能用”6.1 “以为完成任务”和“真正完成任务”的区别这是我用 AI Coding Agent 过程中踩过最深的一个坑。AI 会在自己的回复里写“已完成”“已修复”但实际上它只是把代码改了一版并没有真正运行验证。比如它改了某段逻辑但测试命令拼错了运行时报的是“命令不存在”AI 却把它当成“通过了”。后来我在 Skill 里加了硬性要求任何状态标注为“通过”的验证必须在日志中附上实际命令输出并且输出要包含成功标志。比如pytest必须是passedpnpm lint必须是No errors。AI 不能只写“验证通过”必须写“运行了哪条命令看到了什么结果”。6.2 排查顺序先看输入再看上下文再看验证当 AI 输出的结果不可用时我一般按这个顺序排查看输入。任务描述是否足够具体有没有歧义验收标准是否清晰。看上下文。AI 是否拿到了正确的文件有没有遗漏关键配置或测试用例。看执行循环。AI 是否真的运行了验证还是只做了静态修改。看验证标准。测试通过之外有没有检查代码质量、边界条件、回归风险。最后才怀疑模型本身。很多问题归结到最后其实是上下文和流程设计的问题而不是模型能力不行。这五步能覆盖绝大多数 AI 编码失真的场景。不要一失败就换模型、换工具先看看自己的 Skill 设计是否有漏洞。6.3 一些稳妥的兜底策略最后分享几个我常用的兜底策略所有改动提前 commit 到一个分支重大改动禁止直接推到主干。每次批量执行前记录当前全量测试基线执行后自动对比。对 AI 生成代码安排“交叉检查”如果条件允许准备一份不包含 AI 辅助的纯人工代码在关键模块做对比审查。给 Skill 设置资源上限比如单任务最多运行 5 分钟或消耗 2000 个 token 单位超过上限自动暂停并报告。这几点不能保证不出错但能保证出错时损失可控。AI Coding 最大的价值并不是每行代码都正确而是能让你在短时间内覆盖更多工作量同时把人的精力集中在决策和审查上。Do Work Skill 的构建思路本质上是把这套协作方式规范化、可复用化。先从一个 1 小时能跑通的子任务开始跑稳了再往复杂场景推进这个顺序通常不会错。