掌握Do Work Skill：让AI编码助手从写片段到交付完整工程

做技术开发时间久了，你会发现一个很明显的变化：AI 编码助手早已不只是“自动补全工具”，它已经能承担完整的模块开发、测试用例编写、代码重构、问题排查等工作。但同样是使用 AI 编码，不同工程师的产出质量可能天差地别。有人让 AI 写一个功能要做十轮对话还跑不通，有人一轮提示就能拿到可运行、可维护的代码。

这种差距背后，其实是一项非常实在的能力：Do Work Skill，也就是“让 AI 真正把活干完”的能力。本文不聊宏大的 AI 取代论，而是从实战角度拆解，如何把 AI 编码助手从“聊天式生成片段”升级成“能交付功能的工程助手”，包括核心概念、提示词设计、迭代验证闭环、完整实战案例，以及常见失败模式的排查方案。

无论你是刚接触 AI 编程的初级开发者，还是已经在团队里推广 AI 编码的资深工程师，这篇文章都值得读完并收藏。

1. 背景与核心概念

1.1 什么是 Do Work Skill

先做一个区分。很多人使用 AI 编码的方式是：

• “帮我写一个函数，实现 XX 功能。”
• “给一段 Python 代码，解析 JSON。”
• “这个报错什么意思，怎么改？”

这种用法不是不对，但它停留在“AI 作为自动补全 / 搜索引擎”的层面。AI 给你的是片段，而你自己仍然承担了大部分工程工作：拆分需求、设计结构、验证逻辑、处理边界条件、修复 bug。

Do Work Skill 指的是更高一层的用法：你描述清楚目标、约束和验收标准，AI 负责产出一个能落地交付的工程成果。这个成果可以是一个完整的脚本、一个模块、一组测试用例，甚至是一个可部署的小型服务。

换句话说，普通用法是让 AI “写代码”，Do Work Skill 是让 AI “完成一项工作”。

这个区别在真实项目中非常明显。比如 “写一个日志分析工具”这个需求：

• 普通用法：AI 给了一段能统计关键词的脚本，但文件路径写死，编码不支持 GBK，文件不存在时直接报错，没有命令行入口。
• Do Work Skill 用法：AI 产出的脚本带命令行参数、自动识别编码、有明确的错误提示、输出格式清晰，甚至一起生成测试用例和 README。

后者才是工程师真正需要的“干完活”。

1.2 AI 编码的能力边界

想用好一项工具，先要知道它擅长什么、不擅长什么。

当前主流的 AI 编码助手，通常比较擅长以下工作：

• 根据明确需求生成新代码文件。
• 在已有代码基础上做局部修改和重构。
• 解释报错信息、修复明显 bug。
• 生成单元测试、Mock 数据、配置文件。
• 把自然语言描述转换成 SQL、正则表达式、脚本命令。
• 对代码做 Code Review，指出潜在风险和风格问题。

同时，AI 在这些场景下仍然不可靠：

• 产品级需求的背后包含大量隐含规则，AI 无法自己推理出来。
• 跨多个文件的复杂架构决策，AI 容易生成“看似合理但实际不连通”的代码。
• 涉及真实业务数据、权限、安全边界时，AI 没有判断力。
• AI 经常会“自信地编造”不存在的 API、类名、第三方库能力。

所以 Do Work Skill 的核心并不只是“会写提示词”，而是清楚什么时候让 AI 做、什么时候自己接住。AI 是执行者，你才是负责人。

1.3 为什么需要单独打磨这项技能

很多工程师会有一种感觉：“AI 生成的代码我用不上，改起来比从头写还累。”

这种情况真实存在。但问题往往不是 AI 能力不够，而是交付方式不对。我们让 AI 干活的方式，和让一个新人同事干活的方式，应该有类似之处：你不能只丢一句“帮我做个模块”，而是要给出背景、约束、验收标准和迭代反馈。

Do Work Skill 就是一套系统化方法，把和 AI 协作从“碰运气”变成“可控过程”。一旦掌握，你的日常开发节奏会发生明显变化：简单功能一次成型，中等需求两三轮迭代收敛，复杂任务也能拆成多个小任务逐步推进。

接下来我会按完整流程拆解这项能力，包含环境准备、提示词设计、迭代验证，以及一个从零到可运行的实战案例。

2. 环境准备与版本说明

2.1 工具链选择

Do Work Skill 不是一个特定的软件，而是一套协作方法。因此环境准备的核心是：你已经有一个能持续获取 AI 编码能力的开发环境。

目前常见的搭配方式有三种：

1. 编辑器内置 AI 助手：比如 VS Code、JetBrains 系列中安装 AI 插件，可以在编码过程中直接对话、自动补全、选中代码后让 AI 解释或重构。
2. 独立对话式助手：把需求描述发给 AI 对话工具，再把生成结果复制到项目里。适合快速产出独立脚本。
3. 命令行/终端式 AI 工具：在终端里直接调用 AI 能力，适合处理文件级、多文件的代码任务。

我用 VS Code + Python 3.9 环境演示本文案例。版本只是一个参考，AI 编码助手本身不挑版本，你的实际环境是哪个版本就用哪个版本，重点演示的是流程和思路。

2.2 示例项目结构

为了把 Do Work Skill 讲清楚，我们用一个完整的小项目做素材：构建一个日志级别统计工具。

项目结构设计如下：

log_analyzer/ ├── log_analyzer.py # 主脚本 ├── sample.log # 示例日志文件 ├── test_log_analyzer.py # 单元测试 └── README.md # 使用文档

这个项目虽然简单，但覆盖了真实开发的几个关键环节：命令行参数、文件读取、异常处理、正则匹配、结果输出、单元测试。非常适合用来展示如何让 AI “把活干完”。

3. Do Work Skill 的核心能力拆解

在进入完整案例之前，先把 Do Work Skill 拆成四个核心能力。这四个能力会贯穿所有 AI 编码场景，理解了它们，后面的实战只是具体应用。

3.1 需求拆解：把一句话变成任务清单

AI 编码最常见的失败原因，不是 AI 笨，而是需求太笼统。

例如“帮我写个工具统计日志”这句话，AI 至少会遇到以下问题：

• 统计什么：关键词数量？日志级别？某个时间段的错误数？
• 输入方式：文件路径是写死还是命令行传入？
• 输出格式：命令行文本？JSON？表格？
• 运行环境：Python 版本？第三方库能不能装？
• 边界情况：文件不存在、编码不对、超大文件怎么办？

正确的做法，是先把需求拆解成任务清单，再带着清单和 AI 对话。一个合格的最小需求描述，通常包含四个部分：

1. 任务目标：一句话说明要交付什么。
2. 输入输出：明确输入形式和输出形式。
3. 约束条件：运行环境、依赖限制、编码要求等。
4. 验收标准：满足什么条件才算完成。

你会发现，这不只是在教你怎么问 AI，也是在锻炼你把模糊想法转成工程规格的能力。这本身就是一个高级工程师的基本功。

3.2 上下文注入：给 AI 足够的信息

AI 编码助手没有读心术，它只能基于你提供的上下文来生成结果。上下文不足时，AI 会选择“最常见”的实现方式，这往往不代表你的实际需求。

上下文注入有两种常见方式：

• 把代码文件内容贴给 AI：改某个函数时，把该函数所在文件、相关数据结构、调用关系一并贴进去。不要让 AI 凭记忆猜测你的项目结构。
• 提供示例输入输出：如果你要解析某种日志格式，把真实日志的行样本贴给 AI，再告诉它期望输出什么。Few-shot 示例比十句抽象描述更有效。

上下文的质量比数量重要。与其贴 1000 行无关代码，不如精挑两三段关键代码和一份真实数据样例。

3.3 验证闭环：生成 — 执行 — 纠错

很多人在 AI 生成代码后直接复制进项目，然后等着报错。这不是好的协作方式。

正确的方式是建立一个验证闭环：

1. 生成：让 AI 产出代码。
2. 执行：在本地运行，观察结果。
3. 纠错：把报错信息、不符合预期的输出反馈给 AI，让它修正。
4. 回归：修正后再运行，确认没有引入新问题。

这个闭环的速度越快，你和 AI 的协作效率越高。如果 AI 生成的是一个函数，你就直接写一个临时调用跑一下；如果是一个脚本，就用示例数据跑一次。不要等到项目集成阶段再验证。

3.4 过程管理：把大任务拆成小任务

AI 编码不适合“一口气生成整套系统”这种玩法。任务越大，AI 越容易发散，生成的代码越可能风格混乱、接口不统一、模块之间无法连通。

处理大任务的方法是拆分：

1. 把整体需求拆成独立的、可验证的子任务。
2. 每个子任务单独和 AI 协作完成。
3. 子任务完成后先本地验证，再组合进整体项目。
4. 最后一个阶段做整体集成测试。

例如要构建一个日志分析系统，可以拆成：日志文件读取模块、日志级别解析模块、统计聚合模块、命令行入口模块、测试与文档模块。每部分都是一个小而清晰的交付物。

4. 完整实战案例：让 AI 帮你构建日志分析工具

下面进入完整实战。我会沿用前面的思路，从最初一轮模糊的需求提示开始，逐步演示如何通过 Do Work Skill 拿到可运行的工程成果。

4.1 需求拆解阶段

先不急着让 AI 写代码，我们把“日志分析工具”这个模糊需求拆成任务清单。

我的拆解结果如下：

• 工具类型：Python 命令行脚本，不需要第三方库。
• 输入：命令行传入日志文件路径。
• 处理：逐行读取日志，统计 DEBUG、INFO、WARNING、ERROR、TRACE 五种级别的出现次数。
• 输出：总行数、匹配到级别的行数和百分比、各级别数量与占比。
• 健壮性：文件不存在时给出清晰提示；编码不兼容时尽量容错；一行多个级别时只记第一个匹配的级别。
• 交付物：主脚本、示例日志、单元测试、README。

这个任务清单虽然简单，但已经足够具体。把它喂给 AI，得到的代码质量会远远高于“帮我写个日志统计脚本”。

4.2 第一轮提示：模糊需求 vs 结构化需求

先来看一个模糊提示的示例。

帮我写一个日志分析工具，统计日志文件里的级别数量。

AI 大概率会生成类似这样的代码：

def count_levels(path): counts = {'INFO': 0, 'WARNING': 0, 'ERROR': 0} with open(path, 'r', encoding='utf-8') as f: for line in f: for level in counts: if level in line: counts[level] += 1 return counts

这段代码有三个明显问题：

• 用level in line做子串匹配，日志内容里如果出现 “INFOBAR” 或 “ERROR_CODE”，会被误判。
• path硬编码在函数形参里，没有命令行入口，没有测试调用，实际没法直接跑。
• 同一个日志行如果既包含INFO又包含ERROR，两个都会统计，不符合“一行一个级别”的常规语义。

如果直接把这段代码放进项目，后续大概率要返工。而如果我们在一开始就使用结构化需求，结果完全不同。

下面是结构化提示词示例。注意看四个要素如何逐一体现。

你是一位有丰富经验的 Python 工程师。请编写一个命令行日志分析工具，保存为 log_analyzer.py。 功能要求： 1. 通过命令行参数接收日志文件路径，例如执行：python log_analyzer.py sample.log 2. 统计日志文件中 DEBUG、INFO、WARNING、ERROR、TRACE 五种日志级别的出现次数 3. 输出总行数、匹配到级别的行数、每个级别的数量和占比 4. 使用正则匹配，只匹配独立的日志级别关键词，避免误判日志内容中的相似文本 5. 同一行日志中出现多个级别关键词时，只取第一个匹配项 6. 文件不存在或路径不是普通文件时，给出清晰错误提示并退出 7. 不依赖任何第三方库，只用 Python 标准库 请直接输出完整可运行的代码。

在提示词里，我做了几件事：

• 给 AI 一个角色：“有丰富经验的 Python 工程师”。
• 给出明确的交付物：log_analyzer.py完整脚本。
• 列出功能点、匹配规则、异常处理和依赖约束。
• 用“请直接输出完整可运行的代码”来避免 AI 只给片段或解释半天的敷衍输出。

这就是 Do Work Skill 里“需求拆解 + 上下文注入”的直接应用。

4.3 基于 AI 生成结果整理出的工程代码

下面是基于上述提示词，通过 AI 编码助手迭代修正后得到的最终版本。这个版本可以作为参考，读者也可以直接用这段代码跑通本地演示。

# 文件名：log_analyzer.py """ 日志级别统计工具 用法： python log_analyzer.py sample.log """ import argparse import re import sys from collections import Counter from pathlib import Path # 支持统计的日志级别，顺序即最终输出顺序 LOG_LEVELS = ("DEBUG", "INFO", "WARNING", "ERROR", "TRACE") # 使用词边界匹配，避免 INFO 匹配到 INFORMATION 这类日志内容 LEVEL_PATTERN = re.compile(r"\b(?:DEBUG|INFO|WARNING|ERROR|TRACE)\b") def analyze_log(file_path: str) -> tuple: """解析日志文件，返回总行数、匹配行数和级别计数。""" level_counter = Counter() total_lines = 0 matched_lines = 0 with open(file_path, "r", encoding="utf-8", errors="replace") as f: for line in f: total_lines += 1 match = LEVEL_PATTERN.search(line) if match: matched_lines += 1 level_counter[match.group(0)] += 1 return total_lines, matched_lines, level_counter def print_report(total_lines: int, matched_lines: int, level_counter: Counter) -> None: """打印统计结果到控制台。""" print(f"总行数: {total_lines}") print(f"匹配到日志级别的行数: {matched_lines}") if total_lines == 0: print("没有可统计的日志行。") return print("级别统计:") for level in LOG_LEVELS: count = level_counter.get(level, 0) percent = count / total_lines * 100 print(f" {level:<8} {count:>6} 条，占比 {percent:5.1f}%") def main() -> None: parser = argparse.ArgumentParser(description="统计日志文件中各日志级别的出现次数") parser.add_argument("log_path", help="日志文件路径") args = parser.parse_args() path = Path(args.log_path) if not path.exists(): print(f"错误：文件不存在：{path}") sys.exit(1) if not path.is_file(): print(f"错误：路径不是普通文件：{path}") sys.exit(1) try: total_lines, matched_lines, level_counter = analyze_log(str(path)) except UnicodeDecodeError as exc: print(f"错误：日志文件解码失败：{exc}") sys.exit(1) print_report(total_lines, matched_lines, level_counter) if __name__ == "__main__": main()

这个版本相比第一版，解决了前一轮的边界问题：

• 使用argparse解析命令行参数，而不是硬编码路径。
• 使用正则词边界匹配，避免误判INFORMATION、ERROR_CODE这类文本。
• 同一行只取第一个匹配的级别，语义更贴近实际情况。
• 文件路径检查、解码容错、控制台提示都做了处理。

4.4 运行与验证

先创建一份示例日志文件sample.log。

2025-06-01 10:00:01 INFO 用户登录成功 2025-06-01 10:00:02 DEBUG 缓存读取耗时 5ms 2025-06-01 10:00:03 WARNING 磁盘空间剩余 10% 2025-06-01 10:00:04 ERROR 数据库连接超时 2025-06-01 10:00:05 INFO 用户登出 2025-06-01 10:00:06 TRACE 进入支付回调

然后在命令行中运行：

python log_analyzer.py sample.log

预期输出如下：

总行数: 6 匹配到日志级别的行数: 6 级别统计: DEBUG 1 条，占比 16.7% INFO 2 条，占比 33.3% WARNING 1 条，占比 16.7% ERROR 1 条，占比 16.7% TRACE 1 条，占比 16.7%

到这里，一个可运行的日志分析工具已经完成。接下来验证异常情况。

python log_analyzer.py not_exist.log

预期输出：

错误：文件不存在：not_exist.log

运行结果符合预期，说明这段代码具备了实际交付的可用性。

4.5 让 AI 继续补测试和文档

Do Work Skill 的另一个要点，是主动要求 AI 补充工程配套。主脚本可用之后，我继续向 AI 发起第二轮需求：

请为 log_analyzer.py 编写 pytest 单元测试，测试文件保存为 test_log_analyzer.py。 要求覆盖以下场景： 1. 正常日志文件的统计结果是否正确，包括总行数和级别数量 2. 日志内容中包含 INFORMATION、ERROR_CODE 这类相似文本时，不能误判为日志级别 3. 同一行出现多个级别时，只统计第一个级别 4. 文件不存在时 analyze_log 不会崩溃，而是由上层处理错误

AI 生成的测试代码，整理后大致如下：

# 文件名：test_log_analyzer.py import pytest from log_analyzer import analyze_log def test_normal_log_count(tmp_path): log_file = tmp_path / "app.log" log_file.write_text( "2025-01-01 10:00:00 INFO start\n" "2025-01-01 10:00:01 WARNING low disk\n" "2025-01-01 10:00:02 ERROR timeout\n", encoding="utf-8", ) total, matched, counter = analyze_log(str(log_file)) assert total == 3 assert matched == 3 assert counter.get("INFO") == 1 assert counter.get("WARNING") == 1 assert counter.get("ERROR") == 1 def test_similar_text_not_matched(tmp_path): log_file = tmp_path / "app.log" log_file.write_text("INFO 用户请求 INFORMATION 资料\n", encoding="utf-8") total, matched, counter = analyze_log(str(log_file)) assert total == 1 assert matched == 1 assert counter.get("INFO") == 1 assert counter.get("information") is None def test_first_level_only(tmp_path): log_file = tmp_path / "app.log" log_file.write_text("INFO 用户操作成功 ERROR 后续重试\n", encoding="utf-8") total, matched, counter = analyze_log(str(log_file)) assert matched == 1 assert counter.get("INFO") == 1 assert counter.get("ERROR") == 0

运行测试：

python -m pytest test_log_analyzer.py -v

预期输出所有测试用例通过：

test_normal_log_count PASSED test_similar_text_not_matched PASSED test_first_level_only PASSED

到这里，AI 完成的不只是一个脚本，而是一个带测试、可回归、可维护的小模块。这就是 Do Work Skill 在实际项目中的效果：交付物是完整的，不是碎片化的。

5. 常见问题与排查思路

在使用 AI 编码助手的过程中，有一些失败模式非常典型。下面整理成排查表格，方便你对照自己的场景快速定位问题。

排查思路总结成一句话：**先把错误复现出来，再带着上下文去问 AI，最后用测试验证修复结果。**不要让 AI “盲改”，也不要接受 AI “只解释原因不给出修复”。

6. 最佳实践与工程建议

6.1 把提示词模板化

Do Work Skill 到了一定熟练度之后，可以把提示词沉淀成团队模板。我常用的模板结构如下：

任务：一句话说清楚要做什么 背景：当前项目情况 / 要改哪个文件 / 涉及哪些依赖 约束：不能用第三方库 / Python 版本 / 命名风格 验收标准：运行什么命令 / 期望看到什么结果 / 需要哪些测试

团队里统一模板后，AI 编码的产出质量会变得可预测，而不是依赖个人发挥。

6.2 永远把人放在验证闭环里

AI 可以承担高强度的编码执行，但验收责任始终在工程师身上。对 AI 生成的每一段代码，至少要做好这几件事：

• 跑一遍工作流能覆盖到的最小测试。
• 检查是否有硬编码、密钥泄露、危险操作。
• 审视代码边界：输入为空、并发执行、权限不足时会怎样。
• 把不确定的 API 调用在官方文档里核对一遍。

尤其要注意“AI 自信地编造 API”这个问题，它对经验不足的开发者威胁最大。凡是 AI 提到但你没见过的函数名、类名、配置项，都要多加一步验证。

6.3 用版本管理和 Code Review 兜底

AI 生成代码同样要走版本管理流程。不要在主干上直接粘贴 AI 代码，而是单独开分支，经过测试和人工审查后再合并。

如果团队有 Code Review 文化，可以让 AI 先做一轮自审，再由工程师审查。比如让 AI “作为 Code Reviewer 检查这个文件，列出所有风险和优化点”，然后人工确认哪些建议合理。

6.4 控制上下文与敏感信息边界

在企业项目中，不要把源代码、数据库连接串、密钥、客户信息直接粘贴到公共聊天工具里。如果必须使用 AI 助手，优先选择本地部署或企业许可版本。

同时注意对话上下文的长度问题。不要在一轮会话里堆太多需求，重要信息要在每次迭代中重新确认，避免模型“遗忘”前面的关键约束。

6.5 从小任务开始建立信心

如果你刚开始打磨 Do Work Skill，不要直接拿核心业务模块练手。先选一些小而独立的任务：

• 写一个数据清洗脚本。
• 把某个模块从类方法改写成纯函数。
• 为老代码补充单元测试。
• 生成一份技术方案文档初稿。

在这些小任务上把提示词设计、验证闭环、代码审查跑顺，再逐步扩大到跨文件、跨模块的复杂任务。

6.6 维护个人提示词库

把一次次成功实践沉淀下来，形成自己的提示词库。比如我维护的库里就有这些条目：

• JSON 报文解析器需求模板
• Python 命令行工具模板
• SQL 优化审查模板
• 日志采集报错排查模板
• 前端组件代码生成模板

下次遇到类似任务时，直接套用模板再改细节，效率会翻倍。

7. 总结与下一步

回顾整篇文章，Do Work Skill 的本质并不是某项神秘技巧，而是把工程化方法应用到 AI 协作中。你掌握了四件事：

一是把模糊需求拆解成清晰的任务清单，让 AI 知道你真正要什么。二是学会注入上下文，用真实代码和样例数据引导 AI。三是建立生成、执行、纠错的验证闭环，确保每一次输出都可验证。四是把大任务拆成小任务，让 AI 在可控范围内逐步交付。

日志分析工具这个案例，本身就是一套可以反复练习的模板。你可以在本地把代码跑通，再尝试让 AI 增加更多需求：比如支持 JSON 格式输出、统计 TOP 10 错误日志、按时间范围做过滤，或把日志解析流程抽象成可扩展的类。

下一步建议按这个顺序持续练习：

1. 选一个自己手头的小工具脚本，用结构化提示词让 AI 重写一遍。
2. 在本地跑通并补充测试，把迭代过程记录下来。
3. 复盘哪些提示词有效，哪些地方 AI 连续犯错。
4. 逐渐把 AI 编码引入自己最熟悉的模块，同时强化人工审查意识。

AI 编码不会取代工程师的判断力，但它会放大一个有经验工程师的产出效率。Do Work Skill 本质上就是让 AI 成为那个“理解你意图、能快速执行、再被你审查修正”的可靠协作者。早点把这项能力打磨出来，你在日常开发中会明显感受到，交付一个完整功能不再是体力活。