AI Coding 工具最近一段时间的热度已经不用我再重复了。但真正在一线写代码的工程师大概率都有过这种体验让 AI 写一个脚本、做一个页面 Demo几秒钟就能出结果效率确实拉满可一旦进入真实项目从需求拆解到功能上线AI 生成的代码反而不太敢直接用要么跑不起来要么逻辑和上下文对不上。这个落差不是模型不够强而是大多数使用者还停留在“让 AI 写代码”的思维里没有切换到“让 AI 把活干完”的工作流。这一篇的核心主题是 Do Work Skill名字听起来像某个工具实际上它是一套以交付为导向的 AI Coding 方法论。我的判断是AI Coding 的分水岭已经不是模型能生成多少代码而是工程师能不能通过一套可复用的工作流让 AI 在有限的人工介入下把需求真正变成可运行、可测试、可交付的成果。读完这篇文章你会理解“把活干完”到底意味着什么也会拿到一套可以直接套用的任务拆解、代码生成、验证交付的完整流程。1. 为什么说 AI Coding 的分水岭是“把活干完”行业里有一个很流行的说法AI Coding 能让人在数小时内完成过去需要数周才能做完的开发工作。这句话不能算错但它有非常严格的前提——任务边界足够清晰、验证手段足够完备、工程师知道什么时候该收手。否则AI 生成代码的速度越快返工和排查的成本就越高。我见过不少团队引入 AI 编程助手之后第一周觉得效率翻倍第二周就开始发现代码库里出现大量“看起来对、跑起来错”的代码。典型情况有几种AI 为某个接口生成了不存在的依赖配置把旧项目的结构强行套到新项目上或者在完全没有测试的情况下自信地输出了完整实现。问题不在生成能力而在生成之后的验证链路没有建立起来。这就是“能写代码”和“能把活干完”的本质区别。“能写代码”是单点能力输入一句话输出一段代码“能把活干完”是流程能力它要求 AI 生成的每段代码都能被放到真实项目里运行能被测试验证能被安全地合并和部署。后者才是 AI Coding 真正值钱的地方也是工程师的核心竞争力所在。Vibe Coding 这个词之所以流行是因为它非常精准地描述了当下很多人的使用状态用自然语言描述需求AI 负责生成然后人负责“感觉差不多”。但真实项目的交付标准从来不是“感觉差不多”而是接口能调通、数据不会错、异常能兜底、部署能回滚。所以这篇文章要解决的不是“怎么向 AI 提一个更好的问题”而是“怎么设计一套流程让 AI 从需求到交付的每一环都可控、可验证、可复用”。2. “能写代码”和“能把活干完”是两回事我们拿一个最简单的功能来对比开发一个 REST API提供创建、查询、删除待办事项的能力。用传统的开发方式流程大概是这样的先设计接口路径和数据结构再写业务代码接着本地启动服务用 curl 或 Postman 验证然后补测试用例最后提交代码、走 Code Review、部署到测试环境。用 AI Coding 工具很多人会直接复制一段描述“帮我写一个待办事项 API支持增删查用 FastAPI。”AI 很快会返回一段像模像样的代码。但问题在于你拿到的只是一段代码不是一次交付。这段代码有没有装依赖、能不能启动、接口返回格式和你的前端约定是否一致、边界条件有没有处理都需要你亲自验证。传统方式和 AI Coding 方式真正的差异不是代码怎么写而是“验证和交付”这个环节被放大了。环节传统开发AI Coding 的常见做法Do Work Skill 做法需求拆解由工程师自己完成经常跳过直接让 AI 写代码先把需求拆成可交付的小任务代码生成手写AI 生成AI 生成但注明上下文和约束运行验证本地启动、接口调用往往省略强制要求启动并验证接口测试补充人工编写经常不写让 AI 生成测试并运行通过交付评审人工 Code Review容易跳过保留人工检查点和回滚方案从这个表格能看出AI Coding 真正改变的是把“代码生成”这个环节的成本降到了极低。但其他环节如果还是完全靠人肉补整体收益就会被大量浪费。“把活干完”的本质是让 AI 不只承担生成环节还要承担部分验证、错误修复和交付辅助工作而工程师从“逐行写代码”变成“设计任务和检查结果”。如果把 AI Coding 比作开车以前我们关注的是发动机马力有多大现在更重要的其实是方向盘、刹车、后视镜和导航系统。模型能力是发动机Do Work Skill 就是驾驶系统。3. Do Work SkillAI Coding 时代的核心技能组合Do Work Skill 不是某一个商业产品的官方名称而是我对一套 AI Coding 工作流方法的提炼。它的核心思想很简单把 AI 变成能真正完成任务的执行者而不是只会生成代码片段的助手。要实现这一点需要四个环节形成闭环第一个环节是任务拆解。AI 对“写一个待办事项 API”这种模糊需求的理解是概率性的它只能从训练数据里找到一个最像的答案。所以工程师要先把它转换成 AI 能理解的任务单元比如“定义数据模型”“实现创建接口”“实现查询接口”“实现删除接口”“补充测试”。第二个环节是上下文管理。AI 生成代码时往往缺乏对项目结构的全局感知尤其是跨文件依赖。你要明确告诉它项目的技术栈、目录结构、依赖管理方式、已有代码的约定而不是让它凭空发挥。第三个环节是验证闭环。AI 生成的代码必须被运行、被测试这一步不能省。启动服务、调用接口、跑测试用例任何一个环节失败都要把错误信息重新喂给 AI让它自己修正。第四个环节是交付产物。交付不只是代码文件还包括可复现的运行方式、测试说明、可能的已知限制。如果 AI 能在你的引导下产出这些它才真正完成了“干活”的闭环。这个组合为什么叫 Skill 而不是 Prompt因为 Prompt 只是一句话Skill 是一套可以被反复执行的流程。你可以在不同的项目里套用同一套任务拆解方法、同一种反馈修正机制它会慢慢变成你自己的能力而不是依赖某一次“灵感式提问”。一个容易产生的误区是以为 Skill 就是写一个超长的提示词把所有要求都塞进去。这其实是本末倒置。真正有效的 Skill是把任务细化、验证前置、反馈闭环这些工程动作内化成 AI 的使用习惯。4. 从需求到交付Do Work Skill 工作流拆解下面这套工作流是我建议你在真实项目中先从最小任务开始尝试的版本。它不复杂但每一步都有明确目的。第一步需求澄清。不要直接让 AI 写代码先让 AI 帮你列出实现这个需求需要回答的问题。比如数据怎么存储、接口格式是什么、是否需要鉴权、异常怎么处理。这一步能帮你发现需求里的盲区。第二步任务拆解。把需求拆成 AI 能一次完成一个小目标的子任务。每个子任务最好都能独立验证比如“先创建项目结构并让服务启动成功”就是一个好的子任务“把整个系统一次写完”就不是。第三步逐段生成与执行。每个子任务生成后立刻运行验证。不要等所有代码都生成了再统一调试那样错误堆积太多AI 和人都会崩溃。第四步错误反馈循环。如果运行失败把完整的错误日志提供给 AI要求它解释原因并给出修复方案。不要只说“不对”要让 AI 基于日志推理。第五步交付前检查。整理运行说明、测试方法、已知问题确认这次任务是否达到“可以交付”的标准。这套工作流可以固化成下面这个结构化任务描述模板直接复制到 AI 对话窗口里使用任务目标实现一个待办事项 REST API 技术栈Python FastAPI Uvicorn内存存储 功能要求 1. 提供创建待办事项的接口 2. 提供查看全部待办事项的接口 3. 提供按索引删除待办事项的接口 4. 接口返回 JSON 格式 约束条件 - 不接数据库数据保存在内存列表即可 - 代码结构清晰注释简洁 - 启动命令为 uvicorn app:app --reload 交付标准 - 启动服务后能通过 curl 完成创建、查询、删除三步操作 - 提供最小测试用例并保证运行通过你在实际项目中可以根据技术栈和团队规范替换技术细节。模板的价值在于强迫你把需求、约束、交付标准提前想清楚而不是把思考压力全部丢给 AI。5. 完整示例用 AI Coding 跑通一个待办事项 API现在用一个最小示例完整演示一遍 Do Work Skill 工作流。环境很简单Python 3 环境安装了 pip就可以继续。首先创建项目目录并放入 requirements.txtfastapi uvicorn pytest httpx然后按照工作流先向 AI 提出结构化任务描述。接着生成核心代码文件 app.pyfrom fastapi import FastAPI, HTTPException from pydantic import BaseModel from typing import List app FastAPI(titleTodo API) class TodoItem(BaseModel): title: str completed: bool False todos: List[TodoItem] [] app.get(/todos, response_modelList[TodoItem]) def list_todos(): return todos app.post(/todos, response_modelTodoItem) def create_todo(item: TodoItem): todos.append(item) return item app.delete(/todos/{index}) def delete_todo(index: int): if index 0 or index len(todos): raise HTTPException(status_code404, detailTodo not found) return todos.pop(index)这个文件已经足够完成核心功能。内存列表做存储接口返回 Pydantic 模型删除时先检查索引是否越界。麻雀虽小但该有的异常边界都有了。接着生成测试文件 test_todo.py使用 FastAPI 自带的 TestClientfrom fastapi.testclient import TestClient from app import app client TestClient(app) def test_create_todo(): resp client.post(/todos, json{title: 学习 Do Work Skill}) assert resp.status_code 200 assert resp.json()[title] 学习 Do Work Skill assert resp.json()[completed] is False def test_delete_todo(): # 先创建一条数据再删除索引 0 client.post(/todos, json{title: 临时数据}) resp client.delete(/todos/0) assert resp.status_code 200 def test_delete_todo_not_found(): resp client.delete(/todos/999) assert resp.status_code 404为什么补测试因为测试是验证闭环里最容易自动化的一环。AI 生成的业务代码可能有隐藏问题但测试如果能真实运行并通过交付信心就会高很多。如果 AI 只生成了 app.py没有生成测试文件你可以追加一条反馈“请根据 app.py 的接口定义补充 pytest 测试文件 test_todo.py覆盖创建、查询、删除、异常场景。”这里体现的就是上下文管理——AI 是基于你给定的 app.py 来生成测试而不是从零想象。6. 运行验证与交付检查清单代码和测试都生成之后进入验证环节。先在项目目录下安装依赖pip install -r requirements.txt启动服务uvicorn app:app --reload启动成功会看到类似输出说明服务已经在 127.0.0.1:8000 端口运行。然后另开一个终端用 curl 验证接口curl -X POST http://127.0.0.1:8000/todos \ -H Content-Type: application/json \ -d {title: 写一篇 AI Coding 实战文章}预期返回 JSON里面包含这条待办事项的 title 和 completed 字段。再查询列表curl http://127.0.0.1:8000/todos最后确认测试用例能全部通过。如果服务正在占用端口可以先停掉服务再运行 pytestpytest test_todo.py -v预期看到 3 个测试全部通过。如果运行失败不要慌直接把失败信息发给 AI让它基于日志定位问题。这是工作流里的错误反馈循环也是 Do Work Skill 和“一次性提问”最大的区别。交付检查可以按下面这个清单逐项确认服务能否正常启动。核心接口能否通过 curl 调用并返回预期结果。测试用例是否全部通过。删除不存在的数据时是否返回明确的 HTTP 状态码。是否有 README 或至少一段说明告诉下一个接手的人怎么启动和验证。7. 常见问题与排查思路AI Coding 在真实项目里最容易出问题的几个点我整理了一份排查表你在使用过程中可以直接对照。问题现象可能原因排查方式解决方案AI 生成代码后服务无法启动依赖缺失或版本不匹配查看启动日志检查安装的依赖列表补齐 requirements 依赖或将版本统一接口返回 404路由路径和前端调用不一致查看 FastAPI 自动生成的 /docs 文档让 AI 核对接口路径按契约统一路径删除数据时报索引越界没有处理空列表和越界访问用越界索引调用接口查看异常栈在代码中对索引合法性做判断AI 修改代码后其他功能坏掉修改时没有继承完整上下文回看最近一次修改的代码 diff让 AI 基于完整文件内容修改不要只给片段测试数据污染测试之间共享内存列表打印测试执行顺序和当前数据每个测试独立构造数据或用 fixture 清空数据这五个问题本质上是同一个根源AI 对项目和运行上下文的理解不完整。所以排查的第一步永远是看日志第二步是把完整日志和当前文件内容反馈给 AI而不是凭感觉重写。8. 工程实践建议与安全边界Do Work Skill 可以提升交付速度但不代表可以取消工程底线。以下几条建议是我认为 AI Coding 进入真实项目后必须守住的边界。第一代码审查仍然不能省。AI 生成的代码只是候选方案不是最终结论。提交之前你应该至少自己读一遍核心逻辑审查接口边界、异常处理和资源释放。如果团队有条件Code Review 流程应该照常走AI 生成的代码更容易混入看似正确、实际有问题的片段。第二敏感信息和密钥不能交给 AI 处理。不要让 AI 生成包含数据库密码、API Key、云服务凭证的配置代码。密钥应该通过环境变量或专门的配置中心注入AI 生成的内容里应该只有占位符。第三生产环境操作必须有回滚方案。涉及数据删除、批量更新、迁移脚本时先在测试环境完整跑一遍确认预期结果再准备回滚手段。AI 生成的 SQL 或迁移脚本绝对不能不加审查就在生产环境执行。第四明确 AI Coding 的适用范围。它最适合任务边界清晰、验证手段成熟的增量开发比如 CRUD 接口、数据处理脚本、自动化测试、文档生成。它不适合需求模糊、涉及复杂业务规则或高风险变更的场景。在这些场景里AI 是辅助分析的工具不是主要执行者。第五把 Skill 沉淀成团队资产。当你在某个项目中跑通了不错的 AI Coding 工作流可以把任务描述模板、常见错误反馈模板、项目结构约定整理成团队文档。这样才能让 AI Coding 的能力从个人技巧变成组织能力。9. 总结与下一步行动建议这篇内容想讲清楚的事情其实只有一件AI Coding 的价值不在于生成更多代码而在于形成一套能交付的闭环。Do Work Skill 的本质就是把任务拆解、上下文管理、验证闭环和交付检查串成一条可复用的工作流。你可以不用这个词但你应该在自己的项目里把这条链路跑通。下一步建议很直接。先找一个两周内要做完的小功能按照这篇里的任务描述模板把需求拆开用 AI Coding 工具逐段实现每段都运行验证最后补上测试和运行说明。跑通一次之后再把这套流程推广到更大范围的任务上。不用一次性让 AI 负责整个系统从最小可交付单元开始。你需要练的不是怎么写出更妙的提示词而是怎么让 AI 生成的每一段代码都能进入你的工程体系里被验证、被接受、被交付。这一关过去之后AI Coding 才真正变成了你的生产力。