之前在做项目重构时团队成员已经习惯用 AI 辅助写代码但很快遇到了一个尴尬的场景AI 能生成一段能跑通的函数却搞不定“改完 A 文件、同步更新 B 文件、再补上测试”这种完整任务。后来我们把工作流拆成可复用的技能方案把提示词、上下文、工具调用和验证流程固定下来AI 才开始真正“干活”而不是只当聊天窗口里的代码生成器。这篇文章就是围绕这套方法展开的。我会先梳理 AI Coding 的几个层次再给出一个可落地的工程化方案——我习惯叫它“Do Work Skill Solution”也就是一套让 AI Coding 真正完成开发任务的技能化工作流。内容会覆盖环境准备、核心思路、完整实战案例、常见问题和最佳实践适合正在把 AI 辅助开发引入日常项目的后端、前端和全栈工程师。1. AI Coding 与 Do Work Skill Solution1.1 AI Coding 到底是什么AI Coding 指的是利用大语言模型来辅助完成软件开发活动它并不仅仅指“让 AI 写一段代码”而是覆盖需求分析、代码生成、代码解释、测试编写、Bug 修复、代码审查等一系列环节。在实际开发中AI Coding 工具通常分为三个层次行级/函数级补全根据上下文自动补全代码比如 GitHub Copilot 这类插件。对话式代码助手开发者用自然语言描述需求AI 返回完整代码片段或修改建议比如 ChatGPT、GLM Coding Plan 等。自主执行型 AgentAI 不仅能生成代码还能读取项目文件、执行命令、运行测试、根据报错自动修复典型产品包括 Devin、Cursor、Vercel AI 等平台上的 Agent 能力。这三个层次对应的工程价值完全不同。前两个层次帮助开发者“写得更快”第三个层次才真正接近“替开发者完成一项工作”。这也是为什么 AI Coding Agent 在过去一段时间成为热点因为大家都意识到只有让 AI 具备工具调用和任务闭环能力才能大幅提升开发效率。1.2 Vibe Coding 与 AI Coding AgentVibe Coding 是最近出现的一个概念指的是开发者不再逐行编写代码而是通过自然语言描述意图让 AI 大量生成代码再由人来审查、调整和整合。这种模式强调“跟随感觉编程”适合原型验证、快速起项目但直接把这种模式放到生产项目里风险也很明显。AI Coding Agent 则更强调任务拆解和自主执行。比如你告诉 Agent“请帮我实现一个 JSON 配置校验工具支持必填字段和类型校验”Agent 会自己完成以下步骤分析项目结构和现有依赖。创建核心 Python 文件。生成测试用例。运行测试并修复失败用例。这种模式已经非常接近真实开发流程。不过 Agent 的能力边界、上下文管理、执行权限仍然是工程落地的核心难点后面我会重点展开。1.3 Do Work Skill Solution 是什么“Do Work Skill Solution”不是一个官方技术标准而是一套工程实践方法。它的核心思想是把一次完整的开发任务拆解成“提示词 上下文 工具调用 验证流程”的组合并将这种组合固化为可复用的技能或模板。简单来说普通使用 AI Coding 的方式是你帮我写一个函数解析 JSON 文件。 AI给你一段代码。 你好的我复制粘贴。Do Work Skill Solution 的方式是你请使用 config-validator 技能实现 JSON 配置校验功能。 AI先读取项目结构再创建代码文件编写测试运行测试返回执行结果。 你检查差异合并代码。两者最根本的差别在于前者是“生成代码”后者是“完成工作”。而要让 AI 从“生成代码”升级到“完成工作”关键不在于模型本身而在于我们如何设计任务描述、提供什么上下文、允许 AI 执行哪些操作以及如何验收结果。1.4 为什么需要掌握这套方法结合我的实际体验有几个原因非常具体AI 生成的代码单独看是对的但放到项目里常常对不上现有架构。多文件修改时AI 经常改了一处忘记另一处。AI 不会主动运行测试导致代码只能靠人肉验证。没有规范约束时AI 生成的代码风格五花八门。安全边界不明确时AI 可能执行了不该执行的命令。这些问题单靠“更好的模型”并不能完全解决必须靠工程流程和技能化方案来弥补。2. 环境准备与版本说明在开始配置 Do Work Skill Solution 之前我们先梳理一下环境。不同 AI Coding 工具的产品形态和功能更新非常快因此本文不会把版本号写死而是以通用流程和思路为主。2.1 基础运行环境项目推荐配置说明操作系统Windows 10/11、macOS、Linux与 AI Coding 工具关系不大编程语言Python 3.10 或 Node.js 18实战案例使用 PythonIDEVS Code 或 JetBrains 系列推荐 VS Code插件生态丰富包管理工具pip / uv / npm / pnpm根据项目实际选择版本控制Git用于查看 AI 的代码差异并回滚如果你当前环境里没有 Python建议先安装 Python 3.10 或更高版本。命令如下python --version如果输出类似Python 3.10.12说明环境没问题。如果没有安装请到 Python 官网下载对应安装包并记得勾选“Add Python to PATH”。2.2 AI Coding 工具选择目前主流 AI Coding 工具大致有以下几类IDE 插件型GitHub Copilot、通义灵码、CodeGeeX 等适合代码补全和对话式辅助。AI 原生编辑器Cursor、Windsurf 等内置 Agent 和上下文理解能力。通用模型平台ChatGPT、智谱 GLM、Kimi 等适合生成完整代码块和解释思路。Agent 平台型Vercel AI、Devin 等强调自动执行任务。由于这些工具迭代速度较快具体到某个插件的按钮位置或参数名建议以官方文档为准。本文的实战演示侧重「方法」不同工具都可以套用。2.3 示例项目结构为了方便后续实战演示我们先约定一个目录结构。以一个 Python 项目为例ai-coding-demo/ ├── .venv/ # 虚拟环境 ├── skills/ │ └── config-validator/ │ └── SKILL.md # 技能定义文件 ├── src/ │ └── config_validator/ │ ├── __init__.py │ └── validator.py # 核心校验逻辑 ├── tests/ │ └── test_validator.py ├── prompts/ │ └── validation-task.md # 任务提示词 ├── requirements.txt └── README.md这个结构并不复杂但它已经包含了“技能定义、源码、测试、任务模板”四个关键部分能支撑完整的工作流演示。2.4 初始化项目打开终端执行以下命令mkdir ai-coding-demo cd ai-coding-demo python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate然后创建requirements.txt后续如果用到测试框架再补充依赖pytest7.0安装依赖pip install -r requirements.txt到这里环境就准备好了。接下来进入核心章节拆解 Do Work Skill Solution 的关键设计思路。3. 核心思路拆解3.1 Prompt 不是越多越好而是越结构化越好很多开发者使用 AI Coding 时习惯直接写“帮我实现一个用户登录接口”然后 AI 返回一大段代码。这种方式在小任务里能用但在实际项目中需求越复杂输出质量越不稳定。解决思路是使用结构化的任务描述。我通常会把提示词组织成一张“任务卡片”包含以下字段角色和背景目标输入约束条件输出格式验收标准模板示例如下# 任务实现 JSON 配置校验工具 ## 角色 你是一名资深 Python 开发工程师熟悉配置文件的常见校验场景。 ## 目标 实现一个命令行工具用于校验 JSON 配置文件中的必填字段和字段类型。 ## 输入 - 配置文件路径JSON 格式 - 校验规则文件JSON 格式定义必填字段和类型 ## 约束 - 使用 Python 3.10不引入重量级框架 - 错误信息要包含字段路径便于定位 - 支持嵌套字段校验 ## 输出 - src/config_validator/validator.py - tests/test_validator.py - 命令行入口 cli.py ## 验收标准 1. 能通过 pytest 测试 2. 能处理文件不存在、JSON 解析失败等异常 3. 错误信息清晰可读这种结构化描述的价值在于AI 生成代码时不再需要猜测“你要什么”而是围绕明确的输入输出和验收标准展开。在 Do Work Skill Solution 中任务卡片是一个基本单元。3.2 上下文管理把项目状态喂给 AIAI Coding Agent 要完成真实任务必须理解项目上下文。但大模型的上下文窗口有限不可能把整个仓库都塞进去因此需要“有选择地提供上下文”。合理的上下文应该包含项目整体结构和关键文件路径。当前任务涉及的模块和依赖。相关代码文件的核心逻辑。项目编码规范或风格约束。已经尝试过的方案和失败原因。例如让 AI 修改一个 Python 函数时至少要把函数所在文件的路径、函数签名、调用方代码、测试文件路径都告诉它。上下文组织顺序也很重要把最重要的信息放在提示词开头模型关注度会更高。以下是一个上下文组织示例项目类型Python 3.10 CLI 工具 项目路径/Users/me/ai-coding-demo 核心文件 - src/config_validator/validator.py - src/config_validator/cli.py - tests/test_validator.py 当前任务为 validator.py 增加对数组类型字段的校验支持 已有逻辑validator.py 中 validate_value() 函数负责字段类型检查 依赖pytest, json 注意事项请保持现有函数签名和错误信息风格当你发现 AI 输出的代码风格和现有代码不一致时不要急着换模型先检查上下文是否给足了。3.3 多文件修改与 Agent 模式单文件生成是 AI Coding 最容易的场景但真实开发任务通常涉及多文件修改。比如新增一个命令行参数可能需要同时修改参数解析模块核心业务逻辑测试用例README 文档这时候如果只是简单问答AI 很可能只改到了其中一部分。所以在 Do Work Skill Solution 中我会要求 AI 在动手前先输出“文件修改计划”包含每个文件的修改点和修改原因。示例计划输出修改计划 1. src/config_validator/validator.py - 在 validate_value() 中增加数组类型分支 - 支持 list[str]、list[int] 等类型描述 2. src/config_validator/cli.py - 增加 --rules 参数用于指定校验规则文件 3. tests/test_validator.py - 新增数组字段校验测试用例 - 新增规则文件缺失时的异常测试 4. README.md - 更新命令示例如果 AI 工具支持 Agent 模式它会在项目内自动读取文件并执行修改但一定要让 AI 先输出计划避免直接跨越到修改阶段。3.4 技能化把流程固化成可复用模板“技能化”是 Do Work Skill Solution 的核心。一次任务如果只是临时跑一次用 prompt 就够了但如果是团队常用流程比如“创建服务接口”“添加数据库表”“修复测试失败”就应该固化成技能模板让任何成员甚至 AI Agent 自己都能按同一套流程执行。技能文件的结构可以很简单一个 Markdown 文件或 YAML 文件都行。以skills/config-validator/SKILL.md为例# config-validator 技能 ## 适用场景 需要为项目增加 JSON 配置文件校验能力时使用。 ## 输入要求 - 配置文件路径或样例配置 - 期望支持的校验规则 ## 执行步骤 1. 检查项目是否已有配置校验模块避免重复创建 2. 创建 validator.py实现基础校验逻辑 3. 编写 CLI 入口支持命令行调用 4. 编写 pytest 测试用例覆盖必填字段和类型校验 5. 运行测试确认全部通过 ## 验收标准 - pytest 全部通过 - 错误信息包含字段路径 - 支持嵌套字段 - 命令行入口可独立运行如果使用 YAML 格式可以写成name: config-validator description: 为项目增加 JSON 配置校验能力 version: 1.0.0 trigger: 用户请求实现配置校验或添加校验规则 steps: - check_existing_module - create_validator - create_cli - create_tests - run_tests acceptance_criteria: - pytest_pass - error_info_has_field_path - support_nested_fields - cli_standalone技能文件放到项目的skills/目录里一方面可以让团队成员共享另一方面也可以作为 AI Agent 的功能插件。3.5 验证闭环AI 生成代码后必须自动检查AI 生成的代码不能直接合入主干必须经过验证闭环。至少包含三个环节静态检查通过 lint 工具检查语法和风格问题。单元测试运行 pytest确认功能符合预期。人工审查由开发者查看代码差异确认没有越权修改和安全隐患。在命令行中验证命令大致如下# 运行测试 pytest -v # 静态检查如果项目使用 ruff ruff check src tests如果 AI 工具本身支持运行命令可以让它在生成代码后自动执行测试并把测试结果反馈出来。如果不支持则需要开发者在本地手动执行。无论哪种方式验证闭环都不能省略。4. 完整实战案例在项目里落地 AI Coding 技能前面讲了大量概念和思路接下来我们用一个小而完整的案例把 Do Work Skill Solution 的完整流程走一遍。这个案例是使用 AI Coding 实现一个 JSON 配置校验工具。4.1 需求分析假设我们有一个运维配置系统配置文件是 JSON 格式。希望提供一个校验工具满足以下需求检查必填字段是否存在。检查字段类型是否正确。支持嵌套对象和数组。提供命令行入口。错误信息能定位到具体字段路径。这是一个非常典型的开发任务适合用来演示 AI Coding 全流程。4.2 创建技能文件按照 Do Work Skill Solution 的思路先创建技能文件skills/config-validator/SKILL.md内容可以参考 3.4 节中的模板。这一步的作用是让 AI 明确任务的执行步骤和验收标准。4.3 编写任务提示词编写prompts/validation-task.md作为本次任务的主提示词# 任务实现 JSON 配置校验工具 ## 角色 你是一名资深 Python 开发工程师精通配置文件校验和命令行工具开发。 ## 目标 在现有项目中创建一个 JSON 配置校验工具支持必填字段校验、类型校验、嵌套对象校验和数组校验。 ## 输入 - 配置文件JSON 格式例如 config.json - 校验规则文件JSON 格式例如 schema.json 校验规则示例 { required: [server.host, server.port], type: { server.host: string, server.port: integer, server.timeout: integer, features: array } } ## 约束 - 使用 Python 3.10 - 不引入重量级框架 - 错误信息需要包含字段路径例如 server.port 类型错误期望 integer实际为 string - 需要支持嵌套字段通过点号路径表示层级关系 - 需要支持数组字段基本类型校验 ## 输出 - src/config_validator/validator.py核心校验逻辑 - src/config_validator/cli.py命令行入口 - tests/test_validator.py测试用例 ## 验收标准 1. pytest 全部通过 2. 命令行执行 python -m src.config_validator.cli config.json schema.json 能输出校验结果 3. 文件不存在时给出友好错误提示 4. JSON 解析失败时给出明确错误信息4.4 AI 生成核心代码这里我模拟一次 AI Coding 的输出结果生成的核心代码是src/config_validator/validator.py# 文件路径src/config_validator/validator.py import json from pathlib import Path from typing import Any, Dict, List, Union VALID_TYPES { string: str, integer: int, number: (int, float), boolean: bool, object: dict, array: list, } def load_json_file(file_path: str) - Dict[str, Any]: 加载 JSON 文件如果文件不存在或解析失败则抛出异常。 path Path(file_path) if not path.exists(): raise FileNotFoundError(f配置文件不存在: {file_path}) try: with path.open(r, encodingutf-8) as f: return json.load(f) except json.JSONDecodeError as e: raise ValueError(fJSON 解析失败: {e}) from e def _get_nested_value(data: Dict[str, Any], path: str) - Any: 通过点号路径获取嵌套字段值。 例如 data{server: {host: 127.0.0.1}}, pathserver.host current data for part in path.split(.): if not isinstance(current, dict): return None current current.get(part) return current def _validate_type(value: Any, expected_type: str) - bool: 校验单个字段的类型。 if expected_type not in VALID_TYPES: raise ValueError(f未知的校验类型: {expected_type}) if expected_type array: return isinstance(value, list) return isinstance(value, VALID_TYPES[expected_type]) def validate_config( config: Dict[str, Any], schema: Dict[str, Any] ) - List[str]: 根据 schema 校验 config。 schema 结构 { required: [server.host, server.port], type: { server.host: string, server.port: integer } } 返回错误信息列表如果校验通过则返回空列表。 errors: List[str] [] required_fields schema.get(required, []) type_rules schema.get(type, {}) # 必填字段校验 for field in required_fields: value _get_nested_value(config, field) if value is None: errors.append(f缺少必填字段: {field}) # 类型校验 for field, expected_type in type_rules.items(): value _get_nested_value(config, field) if value is None: continue if not _validate_type(value, expected_type): errors.append( f{field} 类型错误期望 {expected_type}实际为 {type(value).__name__} ) return errors随后生成命令行入口src/config_validator/cli.py# 文件路径src/config_validator/cli.py import argparse import json import sys from pathlib import Path from src.config_validator.validator import load_json_file, validate_config def main() - int: parser argparse.ArgumentParser(descriptionJSON 配置校验工具) parser.add_argument(config, help配置文件路径) parser.add_argument(schema, help校验规则文件路径) args parser.parse_args() try: config load_json_file(args.config) schema load_json_file(args.schema) except (FileNotFoundError, ValueError) as e: print(f加载文件失败: {e}, filesys.stderr) return 1 errors validate_config(config, schema) if errors: print(校验未通过) for error in errors: print(f - {error}) return 1 print(校验通过) return 0 if __name__ __main__: sys.exit(main())生成测试文件tests/test_validator.py# 文件路径tests/test_validator.py import pytest from src.config_validator.validator import ( load_json_file, validate_config, ) def test_validate_config_missing_required_field(): config {server: {host: 127.0.0.1}} schema { required: [server.host, server.port], type: {server.host: string, server.port: integer}, } errors validate_config(config, schema) assert len(errors) 1 assert 缺少必填字段: server.port in errors def test_validate_config_type_error(): config {server: {host: 127.0.0.1, port: 8080}} schema { required: [server.host], type: {server.host: string, server.port: integer}, } errors validate_config(config, schema) assert len(errors) 1 assert server.port 类型错误 in errors def test_validate_config_success(): config {server: {host: 127.0.0.1, port: 8080}} schema { required: [server.host, server.port], type: {server.host: string, server.port: integer}, } errors validate_config(config, schema) assert errors [] def test_load_json_file_not_found(): with pytest.raises(FileNotFoundError): load_json_file(no_such_file.json)上面这些代码是 AI 生成后的典型结果你需要审查它的逻辑是否满足需求。比如_get_nested_value函数对数组下标、嵌套数组等场景还不支持这些就是后续迭代的信号。4.5 运行与验证在项目根目录创建样例配置文件# config.json { server: { host: 127.0.0.1, port: 8080 } }创建校验规则文件# schema.json { required: [server.host, server.port], type: { server.host: string, server.port: integer } }运行命令行工具python -m src.config_validator.cli config.json schema.json预期输出校验未通过 - server.port 类型错误期望 integer实际为 str运行测试pytest -v预期输出应该显示所有测试用例通过。4.6 结果说明与改进方向这个案例展示了从需求分析、技能定义、提示词编写到代码生成、验证的全流程。虽然工具功能很简单但套路完全可以在更复杂的项目中复用。接下来你可以继续让 AI 增加以下功能数组元素类型校验。支持 default 默认值。支持枚举值校验。输出 JSON 格式的校验结果。每次增加功能时都先修改技能文件和任务提示词再让 AI 生成代码最后用测试验证。5. 常见问题与排查思路在把 AI Coding 应用到真实项目的过程中你大概率会遇到下面这些问题。我把常见现象、原因和解决思路整理成了表格方便快速查阅。问题现象常见原因解决思路AI 生成的代码无法运行缺少依赖或版本不兼容检查依赖声明和虚拟环境手动安装缺失依赖AI 改动了多余文件没有明确修改范围在提示词中设置“只允许修改指定文件”的约束并审查 git diffAI 反复使用不存在的 API模型幻觉或训练数据过期让 AI 标注依赖来源人工核对官方文档Agent 执行了危险命令权限边界设置过大限制 Agent 执行命令白名单生产环境禁用自动执行生成的测试用例质量低没有明确断言要求在验收标准中补充“测试必须包含正常和异常两条路径”项目风格不一致上下文缺少编码规范把项目的编码规范文件放到上下文或技能目录中上下文窗口不足项目太大、信息太多只提供核心文件路径和关键函数签名必要时分多轮对话模型输出的错误提示不准确模型没有实际运行代码要求模型在生成代码后给出“如何运行验证”的说明或让 Agent 自动执行命令从我的经验来看大部分问题都不是模型能力不够而是任务描述和上下文管理不到位。所以遇到问题时先不要急着责怪模型尝试调整提示词和上下文往往比换个更强的模型更有效。6. 最佳实践与工程建议6.1 从小任务开始人工验收不可省略AI Coding 工具最适合从“小而有明确边界”的任务开始比如为工具函数补充单元测试。实现一个独立的算法函数。重构某个模块的命名。编写命令行参数解析逻辑。这类任务上下文清晰、验收标准明确AI 出错的影响范围也小。更重要的是开发者可以在低风险场景中积累“如何描述任务、如何给上下文、如何写验收标准”的经验。不管 AI 生成得再好人工审查和验收都不能省略。代码审查时要特别关注几个点是否引入了多余依赖。是否修改了与任务无关的代码。是否有安全漏洞比如路径穿越、命令注入。错误处理是否正确。6.2 把 Prompt 模板纳入版本管理在我的团队实践里prompts/和skills/目录像普通源码一样纳入 Git 管理。这样做的好处是任务描述可以复用不用每次重新写。团队成员之间可以共享同一套流程。AI 生成行为更容易复现和调试。一个典型的提交记录可能是feat: 新增 config-validator 技能和任务模板6.3 将 AI Coding 集成到 CI 流程如果团队已经使用 CI可以考虑把 AI 生成代码的质量检查放入流水线例如通过 Git 提交触发测试。CI 中增加代码风格检查。自动运行安全扫描工具。一条基础命令可能是pytest -v ruff check src tests不过需要提醒的是CI 自动执行 AI 生成的代码风险很高建议在审查通过后再合入主干。6.4 安全边界与最小权限原则使用 AI Coding Agent 时安全边界是重中之重。建议遵循最小权限原则不要让 Agent 直接操作生产环境。不要将密钥、Token、数据库密码放入提示词或上下文。限制 Agent 可以执行的命令尤其是删除、覆盖、格式化等危险操作。每次 Agent 执行操作前先确认它要执行的命令清单。在测试环境或沙箱环境中验证 AI 的自动化流程。如果你在团队内部推广 AI Coding最好先制定一份“AI Coding 使用规范”明确哪些操作允许、哪些操作需要人工确认、哪些操作完全禁止。6.5 记录 Prompt 与生成结果沉淀团队经验每次 AI Coding 任务完成后除了代码提交还可以简单记录以下信息任务描述和使用的技能。生成结果的亮点和问题。调整了哪些提示词才达到理想效果。下次类似任务可以复用的经验。这些记录可以放在项目的 AI_NOTES.md 文件中。随着积累团队会逐步形成一套适合自己项目的 AI Coding 方法论而不是每次都从零开始试。6.6 不要盲目追求 Agent 全自动虽然 AI Coding Agent 看起来很强大但从工程角度看“全自动”和“质量稳定”在短期内很难兼得。比较稳妥的做法是先让 Agent 输出计划人工确认后再执行。让 Agent 修改代码但禁止直接推到主干。让 Agent 运行测试但保留人工检查测试覆盖率的环节。这套方式虽然没有“极端自动化”那么炫酷但更符合生产环境的质量要求。7. 总结与后续学习方向这篇文章围绕“AI Coding for Real Engineers”这个主题重点介绍了如何用 Do Work Skill Solution 这套技能化工作流把 AI Coding 从“生成代码片段”升级为“完成真实开发任务”。通过前面的内容我们可以提炼出几个关键点AI Coding 分为代码补全、对话生成、自主 Agent 三个层次工程价值依次递增。Do Work Skill Solution 是提示词、上下文、工具调用和验证流程的组合核心是“让 AI 干活”。结构化任务卡片、多文件修改计划、技能定义文件、验证闭环是落地 AI Coding 的四大支柱。实战中建议从小任务开始明确修改范围做好安全边界和人工审查。如果你接下来想深入了解 AI Coding可以从这几个方向继续学习函数调用与工具调用理解 Agent 如何执行外部命令和操作文件。主流 AI Coding Agent 的配置方式以官方文档为准实践不同工具的任务执行流程。本地模型与私有化部署适合对数据安全要求较高的团队。代码评审与测试生成自动化把 AI 能力扩展更广的工程环节。最后想说的是AI Coding 并不会取代工程师但它会持续改变工程师的工作方式。真正拉开差距的不是谁用到更新的模型而是谁能把 AI 的能力稳定地约束在工程规范之内。建议你先挑一个小任务按照本文的方法跑通一次完整流程然后把效果好的提示词和技能模板沉淀下来。用着用着你就会发现 AI Coding 开始真正帮你“干活”了。
AI Coding工程化：用Do Work Skill Solution让AI真正完成开发任务
之前在做项目重构时团队成员已经习惯用 AI 辅助写代码但很快遇到了一个尴尬的场景AI 能生成一段能跑通的函数却搞不定“改完 A 文件、同步更新 B 文件、再补上测试”这种完整任务。后来我们把工作流拆成可复用的技能方案把提示词、上下文、工具调用和验证流程固定下来AI 才开始真正“干活”而不是只当聊天窗口里的代码生成器。这篇文章就是围绕这套方法展开的。我会先梳理 AI Coding 的几个层次再给出一个可落地的工程化方案——我习惯叫它“Do Work Skill Solution”也就是一套让 AI Coding 真正完成开发任务的技能化工作流。内容会覆盖环境准备、核心思路、完整实战案例、常见问题和最佳实践适合正在把 AI 辅助开发引入日常项目的后端、前端和全栈工程师。1. AI Coding 与 Do Work Skill Solution1.1 AI Coding 到底是什么AI Coding 指的是利用大语言模型来辅助完成软件开发活动它并不仅仅指“让 AI 写一段代码”而是覆盖需求分析、代码生成、代码解释、测试编写、Bug 修复、代码审查等一系列环节。在实际开发中AI Coding 工具通常分为三个层次行级/函数级补全根据上下文自动补全代码比如 GitHub Copilot 这类插件。对话式代码助手开发者用自然语言描述需求AI 返回完整代码片段或修改建议比如 ChatGPT、GLM Coding Plan 等。自主执行型 AgentAI 不仅能生成代码还能读取项目文件、执行命令、运行测试、根据报错自动修复典型产品包括 Devin、Cursor、Vercel AI 等平台上的 Agent 能力。这三个层次对应的工程价值完全不同。前两个层次帮助开发者“写得更快”第三个层次才真正接近“替开发者完成一项工作”。这也是为什么 AI Coding Agent 在过去一段时间成为热点因为大家都意识到只有让 AI 具备工具调用和任务闭环能力才能大幅提升开发效率。1.2 Vibe Coding 与 AI Coding AgentVibe Coding 是最近出现的一个概念指的是开发者不再逐行编写代码而是通过自然语言描述意图让 AI 大量生成代码再由人来审查、调整和整合。这种模式强调“跟随感觉编程”适合原型验证、快速起项目但直接把这种模式放到生产项目里风险也很明显。AI Coding Agent 则更强调任务拆解和自主执行。比如你告诉 Agent“请帮我实现一个 JSON 配置校验工具支持必填字段和类型校验”Agent 会自己完成以下步骤分析项目结构和现有依赖。创建核心 Python 文件。生成测试用例。运行测试并修复失败用例。这种模式已经非常接近真实开发流程。不过 Agent 的能力边界、上下文管理、执行权限仍然是工程落地的核心难点后面我会重点展开。1.3 Do Work Skill Solution 是什么“Do Work Skill Solution”不是一个官方技术标准而是一套工程实践方法。它的核心思想是把一次完整的开发任务拆解成“提示词 上下文 工具调用 验证流程”的组合并将这种组合固化为可复用的技能或模板。简单来说普通使用 AI Coding 的方式是你帮我写一个函数解析 JSON 文件。 AI给你一段代码。 你好的我复制粘贴。Do Work Skill Solution 的方式是你请使用 config-validator 技能实现 JSON 配置校验功能。 AI先读取项目结构再创建代码文件编写测试运行测试返回执行结果。 你检查差异合并代码。两者最根本的差别在于前者是“生成代码”后者是“完成工作”。而要让 AI 从“生成代码”升级到“完成工作”关键不在于模型本身而在于我们如何设计任务描述、提供什么上下文、允许 AI 执行哪些操作以及如何验收结果。1.4 为什么需要掌握这套方法结合我的实际体验有几个原因非常具体AI 生成的代码单独看是对的但放到项目里常常对不上现有架构。多文件修改时AI 经常改了一处忘记另一处。AI 不会主动运行测试导致代码只能靠人肉验证。没有规范约束时AI 生成的代码风格五花八门。安全边界不明确时AI 可能执行了不该执行的命令。这些问题单靠“更好的模型”并不能完全解决必须靠工程流程和技能化方案来弥补。2. 环境准备与版本说明在开始配置 Do Work Skill Solution 之前我们先梳理一下环境。不同 AI Coding 工具的产品形态和功能更新非常快因此本文不会把版本号写死而是以通用流程和思路为主。2.1 基础运行环境项目推荐配置说明操作系统Windows 10/11、macOS、Linux与 AI Coding 工具关系不大编程语言Python 3.10 或 Node.js 18实战案例使用 PythonIDEVS Code 或 JetBrains 系列推荐 VS Code插件生态丰富包管理工具pip / uv / npm / pnpm根据项目实际选择版本控制Git用于查看 AI 的代码差异并回滚如果你当前环境里没有 Python建议先安装 Python 3.10 或更高版本。命令如下python --version如果输出类似Python 3.10.12说明环境没问题。如果没有安装请到 Python 官网下载对应安装包并记得勾选“Add Python to PATH”。2.2 AI Coding 工具选择目前主流 AI Coding 工具大致有以下几类IDE 插件型GitHub Copilot、通义灵码、CodeGeeX 等适合代码补全和对话式辅助。AI 原生编辑器Cursor、Windsurf 等内置 Agent 和上下文理解能力。通用模型平台ChatGPT、智谱 GLM、Kimi 等适合生成完整代码块和解释思路。Agent 平台型Vercel AI、Devin 等强调自动执行任务。由于这些工具迭代速度较快具体到某个插件的按钮位置或参数名建议以官方文档为准。本文的实战演示侧重「方法」不同工具都可以套用。2.3 示例项目结构为了方便后续实战演示我们先约定一个目录结构。以一个 Python 项目为例ai-coding-demo/ ├── .venv/ # 虚拟环境 ├── skills/ │ └── config-validator/ │ └── SKILL.md # 技能定义文件 ├── src/ │ └── config_validator/ │ ├── __init__.py │ └── validator.py # 核心校验逻辑 ├── tests/ │ └── test_validator.py ├── prompts/ │ └── validation-task.md # 任务提示词 ├── requirements.txt └── README.md这个结构并不复杂但它已经包含了“技能定义、源码、测试、任务模板”四个关键部分能支撑完整的工作流演示。2.4 初始化项目打开终端执行以下命令mkdir ai-coding-demo cd ai-coding-demo python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate然后创建requirements.txt后续如果用到测试框架再补充依赖pytest7.0安装依赖pip install -r requirements.txt到这里环境就准备好了。接下来进入核心章节拆解 Do Work Skill Solution 的关键设计思路。3. 核心思路拆解3.1 Prompt 不是越多越好而是越结构化越好很多开发者使用 AI Coding 时习惯直接写“帮我实现一个用户登录接口”然后 AI 返回一大段代码。这种方式在小任务里能用但在实际项目中需求越复杂输出质量越不稳定。解决思路是使用结构化的任务描述。我通常会把提示词组织成一张“任务卡片”包含以下字段角色和背景目标输入约束条件输出格式验收标准模板示例如下# 任务实现 JSON 配置校验工具 ## 角色 你是一名资深 Python 开发工程师熟悉配置文件的常见校验场景。 ## 目标 实现一个命令行工具用于校验 JSON 配置文件中的必填字段和字段类型。 ## 输入 - 配置文件路径JSON 格式 - 校验规则文件JSON 格式定义必填字段和类型 ## 约束 - 使用 Python 3.10不引入重量级框架 - 错误信息要包含字段路径便于定位 - 支持嵌套字段校验 ## 输出 - src/config_validator/validator.py - tests/test_validator.py - 命令行入口 cli.py ## 验收标准 1. 能通过 pytest 测试 2. 能处理文件不存在、JSON 解析失败等异常 3. 错误信息清晰可读这种结构化描述的价值在于AI 生成代码时不再需要猜测“你要什么”而是围绕明确的输入输出和验收标准展开。在 Do Work Skill Solution 中任务卡片是一个基本单元。3.2 上下文管理把项目状态喂给 AIAI Coding Agent 要完成真实任务必须理解项目上下文。但大模型的上下文窗口有限不可能把整个仓库都塞进去因此需要“有选择地提供上下文”。合理的上下文应该包含项目整体结构和关键文件路径。当前任务涉及的模块和依赖。相关代码文件的核心逻辑。项目编码规范或风格约束。已经尝试过的方案和失败原因。例如让 AI 修改一个 Python 函数时至少要把函数所在文件的路径、函数签名、调用方代码、测试文件路径都告诉它。上下文组织顺序也很重要把最重要的信息放在提示词开头模型关注度会更高。以下是一个上下文组织示例项目类型Python 3.10 CLI 工具 项目路径/Users/me/ai-coding-demo 核心文件 - src/config_validator/validator.py - src/config_validator/cli.py - tests/test_validator.py 当前任务为 validator.py 增加对数组类型字段的校验支持 已有逻辑validator.py 中 validate_value() 函数负责字段类型检查 依赖pytest, json 注意事项请保持现有函数签名和错误信息风格当你发现 AI 输出的代码风格和现有代码不一致时不要急着换模型先检查上下文是否给足了。3.3 多文件修改与 Agent 模式单文件生成是 AI Coding 最容易的场景但真实开发任务通常涉及多文件修改。比如新增一个命令行参数可能需要同时修改参数解析模块核心业务逻辑测试用例README 文档这时候如果只是简单问答AI 很可能只改到了其中一部分。所以在 Do Work Skill Solution 中我会要求 AI 在动手前先输出“文件修改计划”包含每个文件的修改点和修改原因。示例计划输出修改计划 1. src/config_validator/validator.py - 在 validate_value() 中增加数组类型分支 - 支持 list[str]、list[int] 等类型描述 2. src/config_validator/cli.py - 增加 --rules 参数用于指定校验规则文件 3. tests/test_validator.py - 新增数组字段校验测试用例 - 新增规则文件缺失时的异常测试 4. README.md - 更新命令示例如果 AI 工具支持 Agent 模式它会在项目内自动读取文件并执行修改但一定要让 AI 先输出计划避免直接跨越到修改阶段。3.4 技能化把流程固化成可复用模板“技能化”是 Do Work Skill Solution 的核心。一次任务如果只是临时跑一次用 prompt 就够了但如果是团队常用流程比如“创建服务接口”“添加数据库表”“修复测试失败”就应该固化成技能模板让任何成员甚至 AI Agent 自己都能按同一套流程执行。技能文件的结构可以很简单一个 Markdown 文件或 YAML 文件都行。以skills/config-validator/SKILL.md为例# config-validator 技能 ## 适用场景 需要为项目增加 JSON 配置文件校验能力时使用。 ## 输入要求 - 配置文件路径或样例配置 - 期望支持的校验规则 ## 执行步骤 1. 检查项目是否已有配置校验模块避免重复创建 2. 创建 validator.py实现基础校验逻辑 3. 编写 CLI 入口支持命令行调用 4. 编写 pytest 测试用例覆盖必填字段和类型校验 5. 运行测试确认全部通过 ## 验收标准 - pytest 全部通过 - 错误信息包含字段路径 - 支持嵌套字段 - 命令行入口可独立运行如果使用 YAML 格式可以写成name: config-validator description: 为项目增加 JSON 配置校验能力 version: 1.0.0 trigger: 用户请求实现配置校验或添加校验规则 steps: - check_existing_module - create_validator - create_cli - create_tests - run_tests acceptance_criteria: - pytest_pass - error_info_has_field_path - support_nested_fields - cli_standalone技能文件放到项目的skills/目录里一方面可以让团队成员共享另一方面也可以作为 AI Agent 的功能插件。3.5 验证闭环AI 生成代码后必须自动检查AI 生成的代码不能直接合入主干必须经过验证闭环。至少包含三个环节静态检查通过 lint 工具检查语法和风格问题。单元测试运行 pytest确认功能符合预期。人工审查由开发者查看代码差异确认没有越权修改和安全隐患。在命令行中验证命令大致如下# 运行测试 pytest -v # 静态检查如果项目使用 ruff ruff check src tests如果 AI 工具本身支持运行命令可以让它在生成代码后自动执行测试并把测试结果反馈出来。如果不支持则需要开发者在本地手动执行。无论哪种方式验证闭环都不能省略。4. 完整实战案例在项目里落地 AI Coding 技能前面讲了大量概念和思路接下来我们用一个小而完整的案例把 Do Work Skill Solution 的完整流程走一遍。这个案例是使用 AI Coding 实现一个 JSON 配置校验工具。4.1 需求分析假设我们有一个运维配置系统配置文件是 JSON 格式。希望提供一个校验工具满足以下需求检查必填字段是否存在。检查字段类型是否正确。支持嵌套对象和数组。提供命令行入口。错误信息能定位到具体字段路径。这是一个非常典型的开发任务适合用来演示 AI Coding 全流程。4.2 创建技能文件按照 Do Work Skill Solution 的思路先创建技能文件skills/config-validator/SKILL.md内容可以参考 3.4 节中的模板。这一步的作用是让 AI 明确任务的执行步骤和验收标准。4.3 编写任务提示词编写prompts/validation-task.md作为本次任务的主提示词# 任务实现 JSON 配置校验工具 ## 角色 你是一名资深 Python 开发工程师精通配置文件校验和命令行工具开发。 ## 目标 在现有项目中创建一个 JSON 配置校验工具支持必填字段校验、类型校验、嵌套对象校验和数组校验。 ## 输入 - 配置文件JSON 格式例如 config.json - 校验规则文件JSON 格式例如 schema.json 校验规则示例 { required: [server.host, server.port], type: { server.host: string, server.port: integer, server.timeout: integer, features: array } } ## 约束 - 使用 Python 3.10 - 不引入重量级框架 - 错误信息需要包含字段路径例如 server.port 类型错误期望 integer实际为 string - 需要支持嵌套字段通过点号路径表示层级关系 - 需要支持数组字段基本类型校验 ## 输出 - src/config_validator/validator.py核心校验逻辑 - src/config_validator/cli.py命令行入口 - tests/test_validator.py测试用例 ## 验收标准 1. pytest 全部通过 2. 命令行执行 python -m src.config_validator.cli config.json schema.json 能输出校验结果 3. 文件不存在时给出友好错误提示 4. JSON 解析失败时给出明确错误信息4.4 AI 生成核心代码这里我模拟一次 AI Coding 的输出结果生成的核心代码是src/config_validator/validator.py# 文件路径src/config_validator/validator.py import json from pathlib import Path from typing import Any, Dict, List, Union VALID_TYPES { string: str, integer: int, number: (int, float), boolean: bool, object: dict, array: list, } def load_json_file(file_path: str) - Dict[str, Any]: 加载 JSON 文件如果文件不存在或解析失败则抛出异常。 path Path(file_path) if not path.exists(): raise FileNotFoundError(f配置文件不存在: {file_path}) try: with path.open(r, encodingutf-8) as f: return json.load(f) except json.JSONDecodeError as e: raise ValueError(fJSON 解析失败: {e}) from e def _get_nested_value(data: Dict[str, Any], path: str) - Any: 通过点号路径获取嵌套字段值。 例如 data{server: {host: 127.0.0.1}}, pathserver.host current data for part in path.split(.): if not isinstance(current, dict): return None current current.get(part) return current def _validate_type(value: Any, expected_type: str) - bool: 校验单个字段的类型。 if expected_type not in VALID_TYPES: raise ValueError(f未知的校验类型: {expected_type}) if expected_type array: return isinstance(value, list) return isinstance(value, VALID_TYPES[expected_type]) def validate_config( config: Dict[str, Any], schema: Dict[str, Any] ) - List[str]: 根据 schema 校验 config。 schema 结构 { required: [server.host, server.port], type: { server.host: string, server.port: integer } } 返回错误信息列表如果校验通过则返回空列表。 errors: List[str] [] required_fields schema.get(required, []) type_rules schema.get(type, {}) # 必填字段校验 for field in required_fields: value _get_nested_value(config, field) if value is None: errors.append(f缺少必填字段: {field}) # 类型校验 for field, expected_type in type_rules.items(): value _get_nested_value(config, field) if value is None: continue if not _validate_type(value, expected_type): errors.append( f{field} 类型错误期望 {expected_type}实际为 {type(value).__name__} ) return errors随后生成命令行入口src/config_validator/cli.py# 文件路径src/config_validator/cli.py import argparse import json import sys from pathlib import Path from src.config_validator.validator import load_json_file, validate_config def main() - int: parser argparse.ArgumentParser(descriptionJSON 配置校验工具) parser.add_argument(config, help配置文件路径) parser.add_argument(schema, help校验规则文件路径) args parser.parse_args() try: config load_json_file(args.config) schema load_json_file(args.schema) except (FileNotFoundError, ValueError) as e: print(f加载文件失败: {e}, filesys.stderr) return 1 errors validate_config(config, schema) if errors: print(校验未通过) for error in errors: print(f - {error}) return 1 print(校验通过) return 0 if __name__ __main__: sys.exit(main())生成测试文件tests/test_validator.py# 文件路径tests/test_validator.py import pytest from src.config_validator.validator import ( load_json_file, validate_config, ) def test_validate_config_missing_required_field(): config {server: {host: 127.0.0.1}} schema { required: [server.host, server.port], type: {server.host: string, server.port: integer}, } errors validate_config(config, schema) assert len(errors) 1 assert 缺少必填字段: server.port in errors def test_validate_config_type_error(): config {server: {host: 127.0.0.1, port: 8080}} schema { required: [server.host], type: {server.host: string, server.port: integer}, } errors validate_config(config, schema) assert len(errors) 1 assert server.port 类型错误 in errors def test_validate_config_success(): config {server: {host: 127.0.0.1, port: 8080}} schema { required: [server.host, server.port], type: {server.host: string, server.port: integer}, } errors validate_config(config, schema) assert errors [] def test_load_json_file_not_found(): with pytest.raises(FileNotFoundError): load_json_file(no_such_file.json)上面这些代码是 AI 生成后的典型结果你需要审查它的逻辑是否满足需求。比如_get_nested_value函数对数组下标、嵌套数组等场景还不支持这些就是后续迭代的信号。4.5 运行与验证在项目根目录创建样例配置文件# config.json { server: { host: 127.0.0.1, port: 8080 } }创建校验规则文件# schema.json { required: [server.host, server.port], type: { server.host: string, server.port: integer } }运行命令行工具python -m src.config_validator.cli config.json schema.json预期输出校验未通过 - server.port 类型错误期望 integer实际为 str运行测试pytest -v预期输出应该显示所有测试用例通过。4.6 结果说明与改进方向这个案例展示了从需求分析、技能定义、提示词编写到代码生成、验证的全流程。虽然工具功能很简单但套路完全可以在更复杂的项目中复用。接下来你可以继续让 AI 增加以下功能数组元素类型校验。支持 default 默认值。支持枚举值校验。输出 JSON 格式的校验结果。每次增加功能时都先修改技能文件和任务提示词再让 AI 生成代码最后用测试验证。5. 常见问题与排查思路在把 AI Coding 应用到真实项目的过程中你大概率会遇到下面这些问题。我把常见现象、原因和解决思路整理成了表格方便快速查阅。问题现象常见原因解决思路AI 生成的代码无法运行缺少依赖或版本不兼容检查依赖声明和虚拟环境手动安装缺失依赖AI 改动了多余文件没有明确修改范围在提示词中设置“只允许修改指定文件”的约束并审查 git diffAI 反复使用不存在的 API模型幻觉或训练数据过期让 AI 标注依赖来源人工核对官方文档Agent 执行了危险命令权限边界设置过大限制 Agent 执行命令白名单生产环境禁用自动执行生成的测试用例质量低没有明确断言要求在验收标准中补充“测试必须包含正常和异常两条路径”项目风格不一致上下文缺少编码规范把项目的编码规范文件放到上下文或技能目录中上下文窗口不足项目太大、信息太多只提供核心文件路径和关键函数签名必要时分多轮对话模型输出的错误提示不准确模型没有实际运行代码要求模型在生成代码后给出“如何运行验证”的说明或让 Agent 自动执行命令从我的经验来看大部分问题都不是模型能力不够而是任务描述和上下文管理不到位。所以遇到问题时先不要急着责怪模型尝试调整提示词和上下文往往比换个更强的模型更有效。6. 最佳实践与工程建议6.1 从小任务开始人工验收不可省略AI Coding 工具最适合从“小而有明确边界”的任务开始比如为工具函数补充单元测试。实现一个独立的算法函数。重构某个模块的命名。编写命令行参数解析逻辑。这类任务上下文清晰、验收标准明确AI 出错的影响范围也小。更重要的是开发者可以在低风险场景中积累“如何描述任务、如何给上下文、如何写验收标准”的经验。不管 AI 生成得再好人工审查和验收都不能省略。代码审查时要特别关注几个点是否引入了多余依赖。是否修改了与任务无关的代码。是否有安全漏洞比如路径穿越、命令注入。错误处理是否正确。6.2 把 Prompt 模板纳入版本管理在我的团队实践里prompts/和skills/目录像普通源码一样纳入 Git 管理。这样做的好处是任务描述可以复用不用每次重新写。团队成员之间可以共享同一套流程。AI 生成行为更容易复现和调试。一个典型的提交记录可能是feat: 新增 config-validator 技能和任务模板6.3 将 AI Coding 集成到 CI 流程如果团队已经使用 CI可以考虑把 AI 生成代码的质量检查放入流水线例如通过 Git 提交触发测试。CI 中增加代码风格检查。自动运行安全扫描工具。一条基础命令可能是pytest -v ruff check src tests不过需要提醒的是CI 自动执行 AI 生成的代码风险很高建议在审查通过后再合入主干。6.4 安全边界与最小权限原则使用 AI Coding Agent 时安全边界是重中之重。建议遵循最小权限原则不要让 Agent 直接操作生产环境。不要将密钥、Token、数据库密码放入提示词或上下文。限制 Agent 可以执行的命令尤其是删除、覆盖、格式化等危险操作。每次 Agent 执行操作前先确认它要执行的命令清单。在测试环境或沙箱环境中验证 AI 的自动化流程。如果你在团队内部推广 AI Coding最好先制定一份“AI Coding 使用规范”明确哪些操作允许、哪些操作需要人工确认、哪些操作完全禁止。6.5 记录 Prompt 与生成结果沉淀团队经验每次 AI Coding 任务完成后除了代码提交还可以简单记录以下信息任务描述和使用的技能。生成结果的亮点和问题。调整了哪些提示词才达到理想效果。下次类似任务可以复用的经验。这些记录可以放在项目的 AI_NOTES.md 文件中。随着积累团队会逐步形成一套适合自己项目的 AI Coding 方法论而不是每次都从零开始试。6.6 不要盲目追求 Agent 全自动虽然 AI Coding Agent 看起来很强大但从工程角度看“全自动”和“质量稳定”在短期内很难兼得。比较稳妥的做法是先让 Agent 输出计划人工确认后再执行。让 Agent 修改代码但禁止直接推到主干。让 Agent 运行测试但保留人工检查测试覆盖率的环节。这套方式虽然没有“极端自动化”那么炫酷但更符合生产环境的质量要求。7. 总结与后续学习方向这篇文章围绕“AI Coding for Real Engineers”这个主题重点介绍了如何用 Do Work Skill Solution 这套技能化工作流把 AI Coding 从“生成代码片段”升级为“完成真实开发任务”。通过前面的内容我们可以提炼出几个关键点AI Coding 分为代码补全、对话生成、自主 Agent 三个层次工程价值依次递增。Do Work Skill Solution 是提示词、上下文、工具调用和验证流程的组合核心是“让 AI 干活”。结构化任务卡片、多文件修改计划、技能定义文件、验证闭环是落地 AI Coding 的四大支柱。实战中建议从小任务开始明确修改范围做好安全边界和人工审查。如果你接下来想深入了解 AI Coding可以从这几个方向继续学习函数调用与工具调用理解 Agent 如何执行外部命令和操作文件。主流 AI Coding Agent 的配置方式以官方文档为准实践不同工具的任务执行流程。本地模型与私有化部署适合对数据安全要求较高的团队。代码评审与测试生成自动化把 AI 能力扩展更广的工程环节。最后想说的是AI Coding 并不会取代工程师但它会持续改变工程师的工作方式。真正拉开差距的不是谁用到更新的模型而是谁能把 AI 的能力稳定地约束在工程规范之内。建议你先挑一个小任务按照本文的方法跑通一次完整流程然后把效果好的提示词和技能模板沉淀下来。用着用着你就会发现 AI Coding 开始真正帮你“干活”了。
