AI Coding 发展到现在主流工具的代码生成能力已经足够强。但把 AI 放进真实工程流程里大多数开发者会撞上一面墙AI 能写函数、能改代码却很难独立完成一个需求。你让它改一个接口它改完就停你让它修一个 bug它给出的补丁本地能跑一提交就破坏测试你让它顺便加个参数校验它会在十多个相关文件里各改一半最后还得人工收拾残局。这面墙的成因不在模型智商而在工作方式。我们正拿着一个聊天工具的用法去要求一个工程助手完成端到端交付。过去一年多AI Coding 工具在 agent 化、多文件编辑、自动执行命令这些能力上进步很快很多产品的宣传口径都是数小时内完成过去需要数周的开发工作但真正到生产环境里能不能兑现这个承诺取决于有没有一套可复用、可验证的工程流程来约束 Agent 的行为。这篇文章要讲的是可以落地到主流 AI Coding 工具里的工程化方案Do Work Skill。它的核心思路不是给 AI 塞更多领域知识而是给 AI 装上一套工程师工作方法——让它在执行任何开发任务时严格走完理解需求、制定方案、编码实现、质量验证、总结提交五个环节把生成代码升级成完成工作。如果你正在把 AI 编程助手引入日常开发流程或者想在团队里建立一套统一的 AI Agent 工作规范这篇文章会比较有用。读完你会理解 Do Work Skill 解决的是什么问题、如何配置文件、怎么验证效果以及新手最容易踩的坑。1. AI Coding 的真实瓶颈生成代码不等于完成工作先用一个具体场景说明这个瓶颈。假设你接手一个中等规模的 Web 项目要对订单模块增加一个取消订单的接口。把同样的需求交给一个普通 AI 对话窗口和一个有工程流程的 AI Agent差别往往不在代码正确性而在交付结果完整性。普通对话窗口的典型反应是立刻给出一个 controller 方法、一个 service 方法的示例附带你把这个文件放在 xxx 目录下。如果运气好代码可以运行但如果项目里用了统一返回格式、全局异常处理器、鉴权中间件、审计日志这段代码几乎必然要改。更麻烦的是AI 不会自己去读这些约定不会自己跑测试不会检查自己有没有破坏其他模块。这就是生成代码和完成工作的区别。真实开发任务包含一连串模型不擅长自动执行、但 AI Agent 可以按流程执行的动作阅读现有代码、识别项目约定、评估改动影响面、选择合适的实现位置、运行测试并修复问题、最终出具变更说明。这些动作单独看都不涉及高深智力缺了任何一个交付物质量就会明显下降。所以我的判断是2026 年的 AI Coding瓶颈已经从模型能不能生成代码转移到Agent 能不能按工程规范把任务交付完。模型能力是地基工作流是房子。地基再好没有施工流程盖出来的还是毛坯。从行业动态看这个趋势已经很明确。以 GLM Coding Plan、Vercel AI Vibe Coding 平台为代表的工具以及各类 AI Coding Agent 的最新进展都在往让 AI 自己动手完成整件事的方向演进。各家宣传的数小时内完成过去需要数周的开发工作本质上拼的不只是模型参数而是 Agent 对任务的理解深度和执行纪律。Do Work Skill 的思路就是把这种纪律显式化、可配置化。2. 什么是 Do Work Skill从一次性提示词到可复用工作流2.1 Skill 是什么在主流 AI Coding 工具里Skill技能通常指这样一类东西把一组指令、示例、甚至辅助脚本打包成一个可复用的单元按关键词或文件上下文触发。它和普通提示词的最大区别是三个可复用、可版本化、可触发。简单说普通提示词是每次现写的便签Skill 是放在工具箱里的标准工具。2.2 Do Work Skill 不是领域技能而是工程元技能很多人给 AI 配的 Skill 都是领域知识型比如 PostgreSQL 优化技巧、Kubernetes 排查指南、某某框架的最佳实践。这些当然有用。但真实的工程问题里更常见的失败不是AI 不懂领域知识而是AI 不按工程流程走。Do Work Skill 属于另一种类型工程元技能。它不教 AI 某个框架的 API而是规定 AI 在接到任何开发任务时应该以什么流程推进。它对应的是资深工程师的日常工作习惯接到需求先读代码不急着写动手前先给出方案确认影响面编码时遵守项目约定最小改动提交前跑测试、跑静态检查交付时说明改了什么、怎么验证。普通提示词和 Do Work Skill 的区别可以从几个维度看清楚。普通提示词每次都要重新写流程不固定验证步骤经常被省略也无法跨项目复用而 Do Work Skill 由关键词或文件模式自动触发五个阶段顺序固定验证环节强制要求整个 Skill 文件可以放进 Git 仓库随代码一起评审。这些差异看起来只是工程细节在实际使用中会造成天壤之别前者是随缘发挥后者是有纪律的交付。2.3 五个阶段拆解Do Work Skill 的流程可以拆成五个阶段。第一阶段是理解。Agent 需要先读需求描述找到现有代码中相关的文件、函数和数据模型识别项目的命名风格、目录结构、异常处理方式、日志规范。不理解的地方要问用户而不是猜测。很多开发者的第一反应是问来问去太啰嗦但真实项目里AI 猜错需求方向的代价远比多问一句话高得多。第二阶段是规划。Agent 输出一份具体的修改方案列出新增哪些文件、修改哪些文件、每个文件的改动点以及风险点。这一步的价值是让用户在 AI 动手前有机会纠偏避免改错方向。规划阶段还有一个隐藏收益它强制 Agent 先把问题想清楚再写代码显著降低了后续返工的概率。第三阶段是实现。动手编码时遵循项目已有风格尽量做到最小改动不修改与任务无关的文件关键改动点补充注释说明意图。最小改动这条要求比很多人想象的更重要——AI 一旦被放开手脚很容易顺手把无关代码
