最近一段时间陆续有工程师朋友问我同一个问题AI Coding 工具到底能不能真正用于真实项目问这个问题的人通常已经试过让 AI 写函数、改 bug、生成注释甚至用 agent 模式跑过一个小任务。他们的困惑也很一致简单 demo 看起来很惊艳一旦进入真实业务比如处理一批数据、改动一个遗留模块、按规范倒腾一份文档结果就开始不稳定。有时候能用有时候完全失控而且你还说不清哪里出了问题。我越来越倾向于一个判断AI Coding 真正缺的不是模型能力而是“能干活”的流程。模型能力是一回事能不能稳定地把一件具体工作做完是另一回事。后者就是我们要聊的 Do Work Skill 解决方案。Do Work Skill 不是一个花哨的新框架也不是某个工具的特殊模式。它更像是一套工程方法把一项工作涉及到的输入、上下文、执行步骤、验证标准、异常处理和输出约定显式地描述出来让 AI 按这套流程执行并让结果可以被检查、被复用、被迭代。这篇文章会从真实工程师视角拆解为什么多数 AI Coding 尝试会卡在“能写代码”和“能干活”之间以及怎么从一个小任务开始构建可复用的 Do Work Skill 解决方案。1. 先把问题说清楚AI Coding 缺的不是模型是“能干活”的流程1.1 从“能写代码”到“能干活”之间隔了什么一个很典型的现象是你给 AI 一个看起来非常明确的需求——“写一个 Python 脚本读取 Excel 订单表按日期汇总金额生成一份 Markdown 周报”它能很快给出代码。代码风格不错函数拆分也挺清晰甚至带了类型注解。但真把它丢进项目里你会发现一堆之前没回答的问题Excel 文件放在哪个目录文件名带不带日期订单表有哪几个字段金额列是整数还是字符串有没有空值日期格式是2026-08-07还是2026/8/7汇总维度是按自然周、工作日还是按订单状态分组如果某个文件打不开、字段缺失是报错停止还是跳过并记录最终 Markdown 要放在哪里文件名规则是什么这些信息AI 不会主动替你决定。如果你没有在输入里显式提供它就会“猜”。猜对了这一单算成功猜错了结果就是一份看着像样、细看不能用的产物。真实工程师和这类工具的差别恰恰在这里。一个会干活的人接到任务后会先确认输入边界再评估环境接着规划方案最后才是动手写代码。AI Coding 工具默认跳过了前面的环节直接把“写代码”这一步做得特别快。于是所有因为省略澄清而埋下的问题都会在验证阶段集中爆发。Do Work Skill 要解决的就是这个断层。它不要求模型更聪明而是要求我们把“怎么做这件事”的工程经验转译成 AI 能理解和执行的流程。1.2 Do Work Skill 到底是什么不是什么你可以把 Do Work Skill 理解成一份“任务执行说明书”。它把一项工作拆成六个部分任务目标这个 Skill 要完成什么边界在哪里。输入规范读什么文件、什么格式、字段含义、前置依赖。上下文信息项目结构、技术栈、业务规则、历史约定。执行步骤从开始到结束的分步操作顺序。验证标准怎么判断结果是正确的允许哪些误差。异常处理出错时如何重试、跳过、记录、上报。和 Prompt 模板相比Do Work Skill 多了一个关键东西验证闭环。Prompt 模板只解决了“怎么说”没有解决“怎么确认结果是对的”。真实项目里如果结果无法验证流程就无法稳定复制更谈不上批量使用。它也不是一个万能 Agent 配置。Agent 更偏重“让它自主行动”Do Work Skill 强调的是“让行动可控”。你可以把 Skill 作为 Agent 的一部分但如果只丢给 Agent 一句“帮我把数据处理好”没有定义输入和验收标准它给你的仍然是“猜出来的结果”。从项目管理的角度看这有点像“把老师傅的手感变成可交接的操作手册”。师傅知道什么情况要停下来、什么情况可以直接处理这些长期积累的判断很难直接传给别人。Do Work Skill 要做的是先把其中可穷举、可规则化的部分提炼出来变成 AI 能执行的步骤。至于那些需要主观判断的部分仍然需要人来兜底。所以不要把它理解为银弹。它不会让 AI 突然理解业务也不会让一个不存在的验证条件自动成立。它的价值在于让每次 AI Coding 行为从“一次碰运气”变成“一次有控制的生产活动”。2. 构建解决方案时的四个关键维度2.1 输入任务描述的质量决定结果上限绝大多数 AI Coding 翻车问题出在输入阶段而不是模型阶段。比如下面两种描述方式效果会差很多低质量描述帮我处理一下销售数据做一份报表。高质量描述读取 src/data/2026_w29_orders.xlsx订单表包含字段order_id, order_date, amount, status。按自然周汇总 amount 字段status 为 cancelled 的记录不参与汇总。输出 Markdown 文件到 docs/reports/2026_w29_sales_report.md表格包含周、订单数、总金额、取消订单数。第二种描述并没有使用什么复杂技巧它只是把关键信息补齐了。AI 不需要“知道”所有事情它只需要在生成代码时不再需要对输入做假设。一个容易忽略的点是任务描述要把“允许做什么”和“禁止做什么”写清楚。比如“只读取指定目录下以 .xlsx 结尾的文件”“不要修改源文件”“如果遇到字段缺失默认填 0 并记录到日志”。这些约束真实工程师会在工作时默默遵守但 AI 不会。你不说它就可能越过边界。我在实际项目里会把输入相关的内容固定成一个“任务说明头”类似这样任务生成销售周报 输入文件src/data/ 下最近的订单 Excel 输入格式订单表字段 order_id、order_date、amount、status 字段说明amount 为字符串需要转成浮点数order_date 可能为空 处理规则 - statuscancelled 的记录不参与金额汇总 - order_date 为空的记录不丢弃标记为 unknown_week - 不得修改源文件 输出docs/reports/ 下的 Markdown 周报 验收对样例文件运行后金额合计与人工统计误差小于 0.01这段内容不是一次性指令而是一个可复用的输入契约。每次执行同类任务时直接替换文件路径和时间范围即可。任务描述的质量决定了 AI 输出的上限。如果你想让它稳定干活第一步不是优化 Prompt 技巧而是把输入边界彻底量化。2.2 上下文给模型一张清晰的“工地地图”很多工程师会把大量上下文一股脑塞给 AI以为信息越多越准。实际效果常常相反。上下文不是越多越好而是越相关越好。AI 的注意力是有限的当上下文里堆满了无关文件、陈旧说明、大段代码注释时真正关键的信息反而容易被稀释。你会看到 AI 开始纠结于一些无关紧要的角落或者被历史约定误导。更好的做法是给模型一张“工地地图”。假设你要让 AI 在一个已有项目里新增一个功能可以先提供项目的目录结构标明哪些目录可以修改哪些不要碰。使用的技术栈和依赖版本比如 Python 3.11、FastAPI 0.110、pandas 2.2。与本任务相关的模块入口文件路径。数据字典或数据库表结构描述。项目里已有的编码规范比如是否使用类型注解、是否必须写测试。本地环境的启动方式和常用命令。这些信息的组织方式也有讲究。不要直接把整个 README 复制过去而要根据当前任务裁剪。比如这次任务只涉及某个微服务那其他微服务的介绍就没有必要出现。如果任务需要修改数据库表就要把表结构、索引、外键关系放进去如果只是写一个离线脚本数据库表结构可能就不重要。还有一点容易被忽略上下文和任务是两层东西。上下文描述项目环境它是静态的、可复用的。任务定义本次目标它是动态的、每次不同的。在构建 Do Work Skill 时我会把上下文单独写成一个文档和任务描述分开。任务每次变化上下文不变。这样既能减少 token 浪费也能降低模型被陈旧信息干扰的概率。有一点需要特别提醒不要直接把“整个项目压缩包”丢给 AI然后让它自己摸索。如果是本地小项目可能还行一旦项目规模变大、文件变多AI 会在探索阶段消耗大量上下文真正用于思考如何实现的时间反而变少。更合理的路径是你先把地图画好它把力气花在干活上。注意先不要急着给模型超长文档。上下文不是越多越好而是越相关越好。一个清晰的目录结构往往比几万行代码更有用。2.3 验证没有反馈闭环就没有稳定输出AI Coding 从“看起来能跑”到“真正可用”最大的分水岭是验证。很多工程师的流程是这样的让 AI 生成代码复制到项目里跑一次没报错OK。但这个“没报错”只能说明语法没问题不能说明结果是对的。一个脚本可能正常退出却生成了错误的数据一个接口可能返回 200却悄悄算错了数值。所以我在构建任何 Skill 时都要求包含“验证步骤”。验证不能是事后补救而是要写进执行流程里。具体做法可以分三层最小样例验证。先用一组你知道正确答案的数据跑一遍确认输出符合预期。自动化断言。如果任务涉及数据处理让 AI 同时生成一个校验脚本对汇总金额、记录数、空值数量做断言。人工抽查。对关键输出抽几条记录人工核对确认 AI 没有把规则理解偏。举个例子还是订单周报任务。AI 生成主脚本后我还会要求它生成一个check_report.py做的事情包括重新读取源文件计算每条订单的 amount 总和。过滤掉 cancelled 记录后再计算一次。读取生成的 Markdown把里面的总金额和计算结果对比。如果差异超过 0.01退出码必须不是 0。这样AI 有没有跑对不是靠肉眼判断而是靠脚本判断。下次再执行同类任务时这个校验脚本也会成为 Skill 的一部分持续约束后续输出。验证的标准也需要提前定义。比如“金额合计误差小于 0.01”“所有文件都处理到”“失败请求自动重试 3 次”“输出表头必须包含 xxx 字段”。这些标准越具体AI 在执行时越容易自我判断。如果只说“请确保结果准确”那它大概率会自己定义一个“准确”的标准。2.4 迭代把一次成功变成可复用的资产第一次让 AI 完成任务无论成功与否都不应该只留下一个结果还应该留下一份复盘记录。实际项目里我会按这个顺序处理记录任务目标和最终方案。记录哪些输入描述有效哪些信息被 AI 误解。记录验证脚本发现过什么问题。把有效的 Prompt、上下文、验证脚本、目录结构整理成一个新的 Skill 版本。提交到 Git 仓库标注变更说明。这个过程等于把一个“一次性成功的经验”改造成“可复用的资产”。为什么要沉淀到仓库里而不是保存在聊天记录里因为聊天记录是封闭的无法被团队使用也无法做版本对比。而一份 Skill 文档放在 Git 仓库里其他人可以通过 diff 看到这周和上周的差别知道输入规范改了什么、验证标准加了什么。长期来看这个文档就是一个团队对某类任务的共同认知。迭代还有一个方向让 Skill 越来越多但也要注意别让它变成“死文档”。如果项目结构改了、字段变了、工具升级了Skill 里的上下文信息就会过期。这时候需要有人负责更新或者在每次执行失败时把错误信息回填到 Skill 里。一个值得记住的判断是一个 Skill 的价值不在于它一次性生成了多少代码而在于它能不能在下一次任务里减少重复沟通、降低验证成本、提高输出稳定性。3. 一套可落地的“Do Work Skill”构建流程3.1 先做最小可运行样本构建 Skill 时最大的误区是一上来就想做一个覆盖所有情况的完整方案。结果是流程设计得很宏大实现时到处是漏洞最后只能放弃。我更建议先做最小可运行样本。选择一条最典型的数据、一个最核心的步骤、一条最关键的输出先跑通。以销售周报为例最小样本可以是数据一个只有 10 条记录的 Excel 文件。任务按日期汇总金额输出 Markdown。验证人工先算好预期结果。先让 AI 只处理这个文件。跑通后你观察它在哪些地方问了问题、哪些地方猜了规则然后把问过的和猜过的地方都补充到输入规范里。这个阶段的核心原则是宁可先用 3 条样例验证也不要一次性处理 200 个文件。小样本能让你快速暴露流程中的信息缺口同时把试错成本控制在很小范围内。最小样本跑通后再逐步增加复杂度从单文件变成多文件。从固定文件名变成动态发现目录下最新文件。从无异常变成有空值、重复记录、错误状态。从单次输出变成失败重试和日志记录。每一步都把新处理规则追加到 Skill 文档里。这个增量过程比直接设计一个“万能方案”要可靠得多。3.2 用阶段门卡住质量在复杂任务里我不建议让 AI 一口气生成完整解决方案。更稳的做法是把流程拆成几个阶段每个阶段设置一个检查点。一个常见的阶段划分方式阶段输出检查点需求理解任务说明书输入、输出、边界、验收标准是否明确方案设计实现方案技术选型是否合理步骤是否可执行代码实现代码和脚本是否有测试是否有日志是否满足规范验证复核验证报告样例是否通过结果是否可复现异常是否处理交付沉淀文档和 Skill是否记录变更是否提交仓库是否可复用阶段门不是用来卡人的而是用来防止错误扩散。如果 AI 在需求理解阶段就把输入边界搞错了后面写出的代码再优雅也是白做。与其等 200 行代码生成完再发现问题不如在它动手之前先花两分钟确认任务说明书。在执行时你可以要求 AI 先输出“需求理解”和“实现方案”不要急着写代码。通过后再让它进入下一步。如果 AI 工具不支持这种交互模式你也可以手动分多次提问每次只让它完成当前阶段。这一步对很多工程师来说感觉像是在“变慢”。但实际上它是把不可控的试错变成了可控的检查。尤其在任务涉及生产数据、对外输出或代码交付时多一道阶段门远比后期返工划算。3.3 把流程固化到工程结构里当一类任务已经跑通多轮后我就会把 Skill 落到工程目录里。一个比较通用的结构是这样skills/ sales-report/ README.md # Skill 说明适用场景使用方式 task-spec.md # 任务说明头输入输出验收标准 context.md # 项目上下文目录结构技术栈 scripts/ generate_report.py # 主脚本 check_report.py # 校验脚本 examples/ sample_input.xlsx # 样例输入 sample_output.md # 样例输出 tests/ test_rule.py # 规则断言 logs/ run_20260807.log # 每次执行日志这几个文件各自负责一个职责README 是入口解释这个 Skill 解决什么问题、怎么使用。task-spec 描述任务本身每次执行时可以被复制到 AI 对话里。context 描述环境适合作为系统提示词的一部分。主脚本和校验脚本是执行核心保证结果可检查、过程可重跑。examples 和 tests 用来做回归验证防止后续改动破坏已有行为。logs 记录真实执行情况便于排查和持续改进。这种结构不是强制标准但它能保证一件事任何一个人接手这个 Skill不需要依赖原作者的记忆只看仓库就能理解任务的完整闭环。从版本管理角度看Skill 和代码没有区别。每次修改都应该有 commit message说明“为什么改”。如果你发现自己总是在复制同一个 pattern只是改了路径和字段名那说明它已经可以固化成模板了。3.4 从单次任务走向批量与协同单次任务跑通后Skill 还只是“个人效率工具”。真正让它产生长期价值是从单次任务走向批量与协同开始的。批量使用有一个前提任务必须是可重试、可隔离、可对比的。具体来说可重试单条任务失败后不能影响其他任务重新执行时不能产生重复结果。可隔离每次执行的输入、输出、日志都能对应到同一个批次。可对比两次执行之间能够比较结果差异判断改动是变好了还是变坏了。如果这三个条件不满足批量使用等于放大错误。常见的反面案例是让 AI 批量处理 100 个文件中途遇到一个坏文件就整体退出你根本不知道前面 50 个文件是否成功。这时不应该急着加并发而应该先让 Skill 具备“逐条处理、失败记录、断点续跑”的能力。团队协作层面Skill 的更新不应该完全依赖某个人的个人偏好。当多人共用一个 Skill 时需要明确几件事谁负责维护输入规范和上下文文档谁来审核脚本修改新增的异常处理规则要不要经过测试后再合并如果 Skill 执行结果有问题反馈给谁当一个团队开始把“AI 怎么干活”当作一个正经的工程产物来管理时AI Coding 才真正进入了可维护阶段。4. 落地时最容易踩的坑和排查链路4.1 不是模型不行是输入边界和权限不清实际调试 AI Coding 问题时我会先压制住“换一个更聪明的模型”的冲动。大部分问题根源在输入和上下文而不是模型智力。有一次AI 生成了一个清理临时文件的脚本。它在本地测试时正常但部署到生产服务器后突然把所有目标目录下的文件都删了。事后排查发现任务描述里只说“清理临时文件”没说清楚“只删除 /tmp 下文件名以 tmp 开头的文件”AI 就按照“这个目录下的所有文件都可能是临时文件”来理解了。这类问题不是模型能力不足而是边界条件缺失。排查方向应该是任务描述里有没有明确“可以修改哪些范围”有没有明确“禁止触碰哪些路径”有没有提供权限验证的机制比如先 dry-run 列出将要删除的文件一个比较稳妥的做法是涉及删除、覆盖、写库等高风险操作时强制要求 AI 先执行一次“模拟模式”输出将要执行的动作清单由人确认后再真正执行。从工程安全角度这比让 AI 直接动手靠谱得多。注意如果任务会修改生产环境、删除文件或写入重要数据先在任务说明里加一条“必须提供模拟运行的输出”再决定是否放行。4.2 批量任务为什么容易“越跑越乱”批量任务常见的问题不是“AI 能力不行”而是“你的流程没有幂等性”。比如让 AI 生成一批月度报表第一次跑到第 37 个项目时中断了。你修复问题后重新运行结果发现前半段项目生成了两遍后半段没有生成。原因在于执行流程没有记录“哪些任务已经成功完成”也没有在重跑时先消费日志。处理批量任务我会按以下顺序检查有没有给每条输入分配独立 ID有没有记录每个 ID 的状态待处理、处理中、成功、失败失败后有没有把错误信息和输入 ID 关联起来重新执行时能不能跳过已经成功的 ID并发多条任务时日志能不能拆分清楚这五个点决定了一个批量处理方案能不能长期使用。如果只能靠人工盯着终端输出那它还是一个半成品。批量任务还有一个隐性成本上下文管理。让 AI 连续处理多个文件时如果你把 100 个文件的内容一次性都塞进上下文处理到第 80 个时前面文件的信息可能已经干扰了当前的判断。更合理的做法是“一任务一上下文”每处理一个文件都使用相同的流程模板但只注入当前文件的信息。4.3 这套方案的适用边界Do Work Skill 不是所有任务都适合。我在实践中会按这三个问题来判断这个任务是不是重复出现的这个任务的目标是不是可以清晰定义这个任务的结果是不是可以验证如果三个答案都是“是”那很适合做成 Skill。典型场景包括数据处理与报表生成。批量文件转换。代码仓库的常规检查。接口文档更新。环境搭建和部署流程。如果出现下面这些情况就不要硬套任务本身是高度创意性的比如“想一个营销创意”。需求每半天变一次根本没有稳定的输入和输出。结果无法验证只能靠主观感觉。一次性探索任务做完就不再做第二次。对一次性任务直接让 AI 辅助写代码、探索思路效率更高。强行沉淀成 Skill反而会增加流程成本。还有一个容易被忽略的边界维护成本。Skill 需要更新文档需要维护测试需要运行。如果一个任务一个月才用一次而且每次输入都大不相同那维护这个 Skill 的成本可能已经超过了它的收益。做 Skill 也要算 ROI不是做得越多越好。4.4 排查链路五个层级当一个 Skill 执行结果异常时我建议按层级排查不要一上来就怀疑模型现象层先看结果到底错在哪。是报错、无输出、输出格式不对还是结果数值不对把现象记录下来。输入层检查任务描述、输入文件、字段格式、上下文文档有没有过期。多数问题在这一层就能找到原因。环境层检查依赖版本、Python 版本、权限、路径、网络连接。AI 生成的代码很可能假设了某一种环境实际环境不满足时结果就变了。流程层检查 Skill 的执行步骤是否完整验证脚本是否真正运行重试逻辑是否正确。比如校验脚本有没有被忽略失败任务有没有被正确隔离。边界层检查任务类型是否超出这个 Skill 的设计范围。如果是新需求可能需要新建 Skill而不是在旧 Skill 上打补丁。每一层都有自己的检查动作。比如输入层你可以先拿一个历史成功样例重新跑一遍。如果成功样例也失败了说明问题不在本次输入而在环境或 Skill 变更如果成功样例通过、失败样例还是失败那就去对比两个样例的差异。这种按层次排查的习惯能帮你少走很多弯路。毕竟 AI Coding 工具在“快速生成”方面很强但排查问题依然要靠工程师的逻辑判断。真正要小心的是让 AI 自己给自己做“无罪辩护”。当你问它“你生成的代码为什么有问题”时它通常会给出一个看似合理的解释但这个解释未必经过了验证。正确的做法是把排查过程也脚本化先跑样例、再看日志、最后定位差异而不是依赖 AI 的自我解释。回到开头的问题。AI Coding 是否可用于真实项目我的答案是可以但它需要一套完整的“干活流程”。单纯让 AI 写代码就像请了一个速度快但不懂业务的新人你得把所有上下文、边界、验收标准都告诉它还得亲自检查结果。Do Work Skill 的做法就是把这套“告诉它、约束它、检查它”的过程标准化变成可复用的工程资产。如果你现在还没构建过自己的 Skill我建议从一件最让你头疼的重复劳动开始。挑一个小任务写清输入、上下文、步骤、验证标准跑通最小样本然后把过程存到仓库里。下次再遇到同类任务你会明显感觉到AI Coding 不再只是“写代码很快”而是真的在帮你把活干完。这件事长期来看比某一个 AI 工具好不好用更重要。因为工具会迭代模型会升级但一个团队“如何定义任务、如何验证结果、如何沉淀经验”的能力才是 AI Coding 时代最值得投入的地方。