任務(wù))
之前在做項(xiàng)目重構(gòu)時(shí)團(tuán)隊(duì)成員已經(jīng)習(xí)慣用 AI 輔助寫代碼但很快遇到了一個(gè)尷尬的場景AI 能生成一段能跑通的函數(shù)卻搞不定“改完 A 文件、同步更新 B 文件、再補(bǔ)上測試”這種完整任務(wù)。后來我們把工作流拆成可復(fù)用的技能方案把提示詞、上下文、工具調(diào)用和驗(yàn)證流程固定下來AI 才開始真正“干活”而不是只當(dāng)聊天窗口里的代碼生成器。這篇文章就是圍繞這套方法展開的。我會(huì)先梳理 AI Coding 的幾個(gè)層次再給出一個(gè)可落地的工程化方案——我習(xí)慣叫它“Do Work Skill Solution”也就是一套讓 AI Coding 真正完成開發(fā)任務(wù)的技能化工作流。內(nèi)容會(huì)覆蓋環(huán)境準(zhǔn)備、核心思路、完整實(shí)戰(zhàn)案例、常見問題和最佳實(shí)踐適合正在把 AI 輔助開發(fā)引入日常項(xiàng)目的后端、前端和全棧工程師。1. AI Coding 與 Do Work Skill Solution1.1 AI Coding 到底是什么AI Coding 指的是利用大語言模型來輔助完成軟件開發(fā)活動(dòng)它并不僅僅指“讓 AI 寫一段代碼”而是覆蓋需求分析、代碼生成、代碼解釋、測試編寫、Bug 修復(fù)、代碼審查等一系列環(huán)節(jié)。在實(shí)際開發(fā)中AI Coding 工具通常分為三個(gè)層次行級(jí)/函數(shù)級(jí)補(bǔ)全根據(jù)上下文自動(dòng)補(bǔ)全代碼比如 GitHub Copilot 這類插件。對話式代碼助手開發(fā)者用自然語言描述需求AI 返回完整代碼片段或修改建議比如 ChatGPT、GLM Coding Plan 等。自主執(zhí)行型 AgentAI 不僅能生成代碼還能讀取項(xiàng)目文件、執(zhí)行命令、運(yùn)行測試、根據(jù)報(bào)錯(cuò)自動(dòng)修復(fù)典型產(chǎn)品包括 Devin、Cursor、Vercel AI 等平臺(tái)上的 Agent 能力。這三個(gè)層次對應(yīng)的工程價(jià)值完全不同。前兩個(gè)層次幫助開發(fā)者“寫得更快”第三個(gè)層次才真正接近“替開發(fā)者完成一項(xiàng)工作”。這也是為什么 AI Coding Agent 在過去一段時(shí)間成為熱點(diǎn)因?yàn)榇蠹叶家庾R(shí)到只有讓 AI 具備工具調(diào)用和任務(wù)閉環(huán)能力才能大幅提升開發(fā)效率。1.2 Vibe Coding 與 AI Coding AgentVibe Coding 是最近出現(xiàn)的一個(gè)概念指的是開發(fā)者不再逐行編寫代碼而是通過自然語言描述意圖讓 AI 大量生成代碼再由人來審查、調(diào)整和整合。這種模式強(qiáng)調(diào)“跟隨感覺編程”適合原型驗(yàn)證、快速起項(xiàng)目但直接把這種模式放到生產(chǎn)項(xiàng)目里風(fēng)險(xiǎn)也很明顯。AI Coding Agent 則更強(qiáng)調(diào)任務(wù)拆解和自主執(zhí)行。比如你告訴 Agent“請幫我實(shí)現(xiàn)一個(gè) JSON 配置校驗(yàn)工具支持必填字段和類型校驗(yàn)”Agent 會(huì)自己完成以下步驟分析項(xiàng)目結(jié)構(gòu)和現(xiàn)有依賴。創(chuàng)建核心 Python 文件。生成測試用例。運(yùn)行測試并修復(fù)失敗用例。這種模式已經(jīng)非常接近真實(shí)開發(fā)流程。不過 Agent 的能力邊界、上下文管理、執(zhí)行權(quán)限仍然是工程落地的核心難點(diǎn)后面我會(huì)重點(diǎn)展開。1.3 Do Work Skill Solution 是什么“Do Work Skill Solution”不是一個(gè)官方技術(shù)標(biāo)準(zhǔn)而是一套工程實(shí)踐方法。它的核心思想是把一次完整的開發(fā)任務(wù)拆解成“提示詞 上下文 工具調(diào)用 驗(yàn)證流程”的組合并將這種組合固化為可復(fù)用的技能或模板。簡單來說普通使用 AI Coding 的方式是你幫我寫一個(gè)函數(shù)解析 JSON 文件。 AI給你一段代碼。 你好的我復(fù)制粘貼。Do Work Skill Solution 的方式是你請使用 config-validator 技能實(shí)現(xiàn) JSON 配置校驗(yàn)功能。 AI先讀取項(xiàng)目結(jié)構(gòu)再創(chuàng)建代碼文件編寫測試運(yùn)行測試返回執(zhí)行結(jié)果。 你檢查差異合并代碼。兩者最根本的差別在于前者是“生成代碼”后者是“完成工作”。而要讓 AI 從“生成代碼”升級(jí)到“完成工作”關(guān)鍵不在于模型本身而在于我們?nèi)绾卧O(shè)計(jì)任務(wù)描述、提供什么上下文、允許 AI 執(zhí)行哪些操作以及如何驗(yàn)收結(jié)果。1.4 為什么需要掌握這套方法結(jié)合我的實(shí)際體驗(yàn)有幾個(gè)原因非常具體AI 生成的代碼單獨(dú)看是對的但放到項(xiàng)目里常常對不上現(xiàn)有架構(gòu)。多文件修改時(shí)AI 經(jīng)常改了一處忘記另一處。AI 不會(huì)主動(dòng)運(yùn)行測試導(dǎo)致代碼只能靠人肉驗(yàn)證。沒有規(guī)范約束時(shí)AI 生成的代碼風(fēng)格五花八門。安全邊界不明確時(shí)AI 可能執(zhí)行了不該執(zhí)行的命令。這些問題單靠“更好的模型”并不能完全解決必須靠工程流程和技能化方案來彌補(bǔ)。2. 環(huán)境準(zhǔn)備與版本說明在開始配置 Do Work Skill Solution 之前我們先梳理一下環(huán)境。不同 AI Coding 工具的產(chǎn)品形態(tài)和功能更新非常快因此本文不會(huì)把版本號(hào)寫死而是以通用流程和思路為主。2.1 基礎(chǔ)運(yùn)行環(huán)境項(xiàng)目推薦配置說明操作系統(tǒng)Windows 10/11、macOS、Linux與 AI Coding 工具關(guān)系不大編程語言Python 3.10 或 Node.js 18實(shí)戰(zhàn)案例使用 PythonIDEVS Code 或 JetBrains 系列推薦 VS Code插件生態(tài)豐富包管理工具pip / uv / npm / pnpm根據(jù)項(xiàng)目實(shí)際選擇版本控制Git用于查看 AI 的代碼差異并回滾如果你當(dāng)前環(huán)境里沒有 Python建議先安裝 Python 3.10 或更高版本。命令如下python --version如果輸出類似Python 3.10.12說明環(huán)境沒問題。如果沒有安裝請到 Python 官網(wǎng)下載對應(yīng)安裝包并記得勾選“Add Python to PATH”。2.2 AI Coding 工具選擇目前主流 AI Coding 工具大致有以下幾類IDE 插件型GitHub Copilot、通義靈碼、CodeGeeX 等適合代碼補(bǔ)全和對話式輔助。AI 原生編輯器Cursor、Windsurf 等內(nèi)置 Agent 和上下文理解能力。通用模型平臺(tái)ChatGPT、智譜 GLM、Kimi 等適合生成完整代碼塊和解釋思路。Agent 平臺(tái)型Vercel AI、Devin 等強(qiáng)調(diào)自動(dòng)執(zhí)行任務(wù)。由于這些工具迭代速度較快具體到某個(gè)插件的按鈕位置或參數(shù)名建議以官方文檔為準(zhǔn)。本文的實(shí)戰(zhàn)演示側(cè)重「方法」不同工具都可以套用。2.3 示例項(xiàng)目結(jié)構(gòu)為了方便后續(xù)實(shí)戰(zhàn)演示我們先約定一個(gè)目錄結(jié)構(gòu)。以一個(gè) Python 項(xiàng)目為例ai-coding-demo/ ├── .venv/ # 虛擬環(huán)境 ├── skills/ │ └── config-validator/ │ └── SKILL.md # 技能定義文件 ├── src/ │ └── config_validator/ │ ├── __init__.py │ └── validator.py # 核心校驗(yàn)邏輯 ├── tests/ │ └── test_validator.py ├── prompts/ │ └── validation-task.md # 任務(wù)提示詞 ├── requirements.txt └── README.md這個(gè)結(jié)構(gòu)并不復(fù)雜但它已經(jīng)包含了“技能定義、源碼、測試、任務(wù)模板”四個(gè)關(guān)鍵部分能支撐完整的工作流演示。2.4 初始化項(xiàng)目打開終端執(zhí)行以下命令mkdir ai-coding-demo cd ai-coding-demo python -m venv .venv # Windows .venv\Scripts\activate # macOS / Linux source .venv/bin/activate然后創(chuàng)建requirements.txt后續(xù)如果用到測試框架再補(bǔ)充依賴pytest7.0安裝依賴pip install -r requirements.txt到這里環(huán)境就準(zhǔn)備好了。接下來進(jìn)入核心章節(jié)拆解 Do Work Skill Solution 的關(guān)鍵設(shè)計(jì)思路。3. 核心思路拆解3.1 Prompt 不是越多越好而是越結(jié)構(gòu)化越好很多開發(fā)者使用 AI Coding 時(shí)習(xí)慣直接寫“幫我實(shí)現(xiàn)一個(gè)用戶登錄接口”然后 AI 返回一大段代碼。這種方式在小任務(wù)里能用但在實(shí)際項(xiàng)目中需求越復(fù)雜輸出質(zhì)量越不穩(wěn)定。解決思路是使用結(jié)構(gòu)化的任務(wù)描述。我通常會(huì)把提示詞組織成一張“任務(wù)卡片”包含以下字段角色和背景目標(biāo)輸入約束條件輸出格式驗(yàn)收標(biāo)準(zhǔn)模板示例如下# 任務(wù)實(shí)現(xiàn) JSON 配置校驗(yàn)工具 ## 角色 你是一名資深 Python 開發(fā)工程師熟悉配置文件的常見校驗(yàn)場景。 ## 目標(biāo) 實(shí)現(xiàn)一個(gè)命令行工具用于校驗(yàn) JSON 配置文件中的必填字段和字段類型。 ## 輸入 - 配置文件路徑JSON 格式 - 校驗(yàn)規(guī)則文件JSON 格式定義必填字段和類型 ## 約束 - 使用 Python 3.10不引入重量級(jí)框架 - 錯(cuò)誤信息要包含字段路徑便于定位 - 支持嵌套字段校驗(yàn) ## 輸出 - src/config_validator/validator.py - tests/test_validator.py - 命令行入口 cli.py ## 驗(yàn)收標(biāo)準(zhǔn) 1. 能通過 pytest 測試 2. 能處理文件不存在、JSON 解析失敗等異常 3. 錯(cuò)誤信息清晰可讀這種結(jié)構(gòu)化描述的價(jià)值在于AI 生成代碼時(shí)不再需要猜測“你要什么”而是圍繞明確的輸入輸出和驗(yàn)收標(biāo)準(zhǔn)展開。在 Do Work Skill Solution 中任務(wù)卡片是一個(gè)基本單元。3.2 上下文管理把項(xiàng)目狀態(tài)喂給 AIAI Coding Agent 要完成真實(shí)任務(wù)必須理解項(xiàng)目上下文。但大模型的上下文窗口有限不可能把整個(gè)倉庫都塞進(jìn)去因此需要“有選擇地提供上下文”。合理的上下文應(yīng)該包含項(xiàng)目整體結(jié)構(gòu)和關(guān)鍵文件路徑。當(dāng)前任務(wù)涉及的模塊和依賴。相關(guān)代碼文件的核心邏輯。項(xiàng)目編碼規(guī)范或風(fēng)格約束。已經(jīng)嘗試過的方案和失敗原因。例如讓 AI 修改一個(gè) Python 函數(shù)時(shí)至少要把函數(shù)所在文件的路徑、函數(shù)簽名、調(diào)用方代碼、測試文件路徑都告訴它。上下文組織順序也很重要把最重要的信息放在提示詞開頭模型關(guān)注度會(huì)更高。以下是一個(gè)上下文組織示例項(xiàng)目類型Python 3.10 CLI 工具 項(xiàng)目路徑/Users/me/ai-coding-demo 核心文件 - src/config_validator/validator.py - src/config_validator/cli.py - tests/test_validator.py 當(dāng)前任務(wù)為 validator.py 增加對數(shù)組類型字段的校驗(yàn)支持 已有邏輯validator.py 中 validate_value() 函數(shù)負(fù)責(zé)字段類型檢查 依賴pytest, json 注意事項(xiàng)請保持現(xiàn)有函數(shù)簽名和錯(cuò)誤信息風(fēng)格當(dāng)你發(fā)現(xiàn) AI 輸出的代碼風(fēng)格和現(xiàn)有代碼不一致時(shí)不要急著換模型先檢查上下文是否給足了。3.3 多文件修改與 Agent 模式單文件生成是 AI Coding 最容易的場景但真實(shí)開發(fā)任務(wù)通常涉及多文件修改。比如新增一個(gè)命令行參數(shù)可能需要同時(shí)修改參數(shù)解析模塊核心業(yè)務(wù)邏輯測試用例README 文檔這時(shí)候如果只是簡單問答AI 很可能只改到了其中一部分。所以在 Do Work Skill Solution 中我會(huì)要求 AI 在動(dòng)手前先輸出“文件修改計(jì)劃”包含每個(gè)文件的修改點(diǎn)和修改原因。示例計(jì)劃輸出修改計(jì)劃 1. src/config_validator/validator.py - 在 validate_value() 中增加數(shù)組類型分支 - 支持 list[str]、list[int] 等類型描述 2. src/config_validator/cli.py - 增加 --rules 參數(shù)用于指定校驗(yàn)規(guī)則文件 3. tests/test_validator.py - 新增數(shù)組字段校驗(yàn)測試用例 - 新增規(guī)則文件缺失時(shí)的異常測試 4. README.md - 更新命令示例如果 AI 工具支持 Agent 模式它會(huì)在項(xiàng)目內(nèi)自動(dòng)讀取文件并執(zhí)行修改但一定要讓 AI 先輸出計(jì)劃避免直接跨越到修改階段。3.4 技能化把流程固化成可復(fù)用模板“技能化”是 Do Work Skill Solution 的核心。一次任務(wù)如果只是臨時(shí)跑一次用 prompt 就夠了但如果是團(tuán)隊(duì)常用流程比如“創(chuàng)建服務(wù)接口”“添加數(shù)據(jù)庫表”“修復(fù)測試失敗”就應(yīng)該固化成技能模板讓任何成員甚至 AI Agent 自己都能按同一套流程執(zhí)行。技能文件的結(jié)構(gòu)可以很簡單一個(gè) Markdown 文件或 YAML 文件都行。以skills/config-validator/SKILL.md為例# config-validator 技能 ## 適用場景 需要為項(xiàng)目增加 JSON 配置文件校驗(yàn)?zāi)芰r(shí)使用。 ## 輸入要求 - 配置文件路徑或樣例配置 - 期望支持的校驗(yàn)規(guī)則 ## 執(zhí)行步驟 1. 檢查項(xiàng)目是否已有配置校驗(yàn)?zāi)K避免重復(fù)創(chuàng)建 2. 創(chuàng)建 validator.py實(shí)現(xiàn)基礎(chǔ)校驗(yàn)邏輯 3. 編寫 CLI 入口支持命令行調(diào)用 4. 編寫 pytest 測試用例覆蓋必填字段和類型校驗(yàn) 5. 運(yùn)行測試確認(rèn)全部通過 ## 驗(yàn)收標(biāo)準(zhǔn) - pytest 全部通過 - 錯(cuò)誤信息包含字段路徑 - 支持嵌套字段 - 命令行入口可獨(dú)立運(yùn)行如果使用 YAML 格式可以寫成name: config-validator description: 為項(xiàng)目增加 JSON 配置校驗(yàn)?zāi)芰?version: 1.0.0 trigger: 用戶請求實(shí)現(xiàn)配置校驗(yàn)或添加校驗(yàn)規(guī)則 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技能文件放到項(xiàng)目的skills/目錄里一方面可以讓團(tuán)隊(duì)成員共享另一方面也可以作為 AI Agent 的功能插件。3.5 驗(yàn)證閉環(huán)AI 生成代碼后必須自動(dòng)檢查AI 生成的代碼不能直接合入主干必須經(jīng)過驗(yàn)證閉環(huán)。至少包含三個(gè)環(huán)節(jié)靜態(tài)檢查通過 lint 工具檢查語法和風(fēng)格問題。單元測試運(yùn)行 pytest確認(rèn)功能符合預(yù)期。人工審查由開發(fā)者查看代碼差異確認(rèn)沒有越權(quán)修改和安全隱患。在命令行中驗(yàn)證命令大致如下# 運(yùn)行測試 pytest -v # 靜態(tài)檢查如果項(xiàng)目使用 ruff ruff check src tests如果 AI 工具本身支持運(yùn)行命令可以讓它在生成代碼后自動(dòng)執(zhí)行測試并把測試結(jié)果反饋出來。如果不支持則需要開發(fā)者在本地手動(dòng)執(zhí)行。無論哪種方式驗(yàn)證閉環(huán)都不能省略。4. 完整實(shí)戰(zhàn)案例在項(xiàng)目里落地 AI Coding 技能前面講了大量概念和思路接下來我們用一個(gè)小而完整的案例把 Do Work Skill Solution 的完整流程走一遍。這個(gè)案例是使用 AI Coding 實(shí)現(xiàn)一個(gè) JSON 配置校驗(yàn)工具。4.1 需求分析假設(shè)我們有一個(gè)運(yùn)維配置系統(tǒng)配置文件是 JSON 格式。希望提供一個(gè)校驗(yàn)工具滿足以下需求檢查必填字段是否存在。檢查字段類型是否正確。支持嵌套對象和數(shù)組。提供命令行入口。錯(cuò)誤信息能定位到具體字段路徑。這是一個(gè)非常典型的開發(fā)任務(wù)適合用來演示 AI Coding 全流程。4.2 創(chuàng)建技能文件按照 Do Work Skill Solution 的思路先創(chuàng)建技能文件skills/config-validator/SKILL.md內(nèi)容可以參考 3.4 節(jié)中的模板。這一步的作用是讓 AI 明確任務(wù)的執(zhí)行步驟和驗(yàn)收標(biāo)準(zhǔn)。4.3 編寫任務(wù)提示詞編寫prompts/validation-task.md作為本次任務(wù)的主提示詞# 任務(wù)實(shí)現(xiàn) JSON 配置校驗(yàn)工具 ## 角色 你是一名資深 Python 開發(fā)工程師精通配置文件校驗(yàn)和命令行工具開發(fā)。 ## 目標(biāo) 在現(xiàn)有項(xiàng)目中創(chuàng)建一個(gè) JSON 配置校驗(yàn)工具支持必填字段校驗(yàn)、類型校驗(yàn)、嵌套對象校驗(yàn)和數(shù)組校驗(yàn)。 ## 輸入 - 配置文件JSON 格式例如 config.json - 校驗(yàn)規(guī)則文件JSON 格式例如 schema.json 校驗(yàn)規(guī)則示例 { required: [server.host, server.port], type: { server.host: string, server.port: integer, server.timeout: integer, features: array } } ## 約束 - 使用 Python 3.10 - 不引入重量級(jí)框架 - 錯(cuò)誤信息需要包含字段路徑例如 server.port 類型錯(cuò)誤期望 integer實(shí)際為 string - 需要支持嵌套字段通過點(diǎn)號(hào)路徑表示層級(jí)關(guān)系 - 需要支持?jǐn)?shù)組字段基本類型校驗(yàn) ## 輸出 - src/config_validator/validator.py核心校驗(yàn)邏輯 - src/config_validator/cli.py命令行入口 - tests/test_validator.py測試用例 ## 驗(yàn)收標(biāo)準(zhǔn) 1. pytest 全部通過 2. 命令行執(zhí)行 python -m src.config_validator.cli config.json schema.json 能輸出校驗(yàn)結(jié)果 3. 文件不存在時(shí)給出友好錯(cuò)誤提示 4. JSON 解析失敗時(shí)給出明確錯(cuò)誤信息4.4 AI 生成核心代碼這里我模擬一次 AI Coding 的輸出結(jié)果生成的核心代碼是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: 通過點(diǎn)號(hào)路徑獲取嵌套字段值。 例如 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: 校驗(yàn)單個(gè)字段的類型。 if expected_type not in VALID_TYPES: raise ValueError(f未知的校驗(yàn)類型: {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]: 根據(jù) schema 校驗(yàn) config。 schema 結(jié)構(gòu) { required: [server.host, server.port], type: { server.host: string, server.port: integer } } 返回錯(cuò)誤信息列表如果校驗(yàn)通過則返回空列表。 errors: List[str] [] required_fields schema.get(required, []) type_rules schema.get(type, {}) # 必填字段校驗(yàn) for field in required_fields: value _get_nested_value(config, field) if value is None: errors.append(f缺少必填字段: {field}) # 類型校驗(yàn) 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} 類型錯(cuò)誤期望 {expected_type}實(shí)際為 {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 配置校驗(yàn)工具) parser.add_argument(config, help配置文件路徑) parser.add_argument(schema, help校驗(yàn)規(guī)則文件路徑) 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(校驗(yàn)未通過) for error in errors: print(f - {error}) return 1 print(校驗(yàn)通過) 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 類型錯(cuò)誤 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 生成后的典型結(jié)果你需要審查它的邏輯是否滿足需求。比如_get_nested_value函數(shù)對數(shù)組下標(biāo)、嵌套數(shù)組等場景還不支持這些就是后續(xù)迭代的信號(hào)。4.5 運(yùn)行與驗(yàn)證在項(xiàng)目根目錄創(chuàng)建樣例配置文件# config.json { server: { host: 127.0.0.1, port: 8080 } }創(chuàng)建校驗(yàn)規(guī)則文件# schema.json { required: [server.host, server.port], type: { server.host: string, server.port: integer } }運(yùn)行命令行工具python -m src.config_validator.cli config.json schema.json預(yù)期輸出校驗(yàn)未通過 - server.port 類型錯(cuò)誤期望 integer實(shí)際為 str運(yùn)行測試pytest -v預(yù)期輸出應(yīng)該顯示所有測試用例通過。4.6 結(jié)果說明與改進(jìn)方向這個(gè)案例展示了從需求分析、技能定義、提示詞編寫到代碼生成、驗(yàn)證的全流程。雖然工具功能很簡單但套路完全可以在更復(fù)雜的項(xiàng)目中復(fù)用。接下來你可以繼續(xù)讓 AI 增加以下功能數(shù)組元素類型校驗(yàn)。支持 default 默認(rèn)值。支持枚舉值校驗(yàn)。輸出 JSON 格式的校驗(yàn)結(jié)果。每次增加功能時(shí)都先修改技能文件和任務(wù)提示詞再讓 AI 生成代碼最后用測試驗(yàn)證。5. 常見問題與排查思路在把 AI Coding 應(yīng)用到真實(shí)項(xiàng)目的過程中你大概率會(huì)遇到下面這些問題。我把常見現(xiàn)象、原因和解決思路整理成了表格方便快速查閱。問題現(xiàn)象常見原因解決思路AI 生成的代碼無法運(yùn)行缺少依賴或版本不兼容檢查依賴聲明和虛擬環(huán)境手動(dòng)安裝缺失依賴AI 改動(dòng)了多余文件沒有明確修改范圍在提示詞中設(shè)置“只允許修改指定文件”的約束并審查 git diffAI 反復(fù)使用不存在的 API模型幻覺或訓(xùn)練數(shù)據(jù)過期讓 AI 標(biāo)注依賴來源人工核對官方文檔Agent 執(zhí)行了危險(xiǎn)命令權(quán)限邊界設(shè)置過大限制 Agent 執(zhí)行命令白名單生產(chǎn)環(huán)境禁用自動(dòng)執(zhí)行生成的測試用例質(zhì)量低沒有明確斷言要求在驗(yàn)收標(biāo)準(zhǔn)中補(bǔ)充“測試必須包含正常和異常兩條路徑”項(xiàng)目風(fēng)格不一致上下文缺少編碼規(guī)范把項(xiàng)目的編碼規(guī)范文件放到上下文或技能目錄中上下文窗口不足項(xiàng)目太大、信息太多只提供核心文件路徑和關(guān)鍵函數(shù)簽名必要時(shí)分多輪對話模型輸出的錯(cuò)誤提示不準(zhǔn)確模型沒有實(shí)際運(yùn)行代碼要求模型在生成代碼后給出“如何運(yùn)行驗(yàn)證”的說明或讓 Agent 自動(dòng)執(zhí)行命令從我的經(jīng)驗(yàn)來看大部分問題都不是模型能力不夠而是任務(wù)描述和上下文管理不到位。所以遇到問題時(shí)先不要急著責(zé)怪模型嘗試調(diào)整提示詞和上下文往往比換個(gè)更強(qiáng)的模型更有效。6. 最佳實(shí)踐與工程建議6.1 從小任務(wù)開始人工驗(yàn)收不可省略AI Coding 工具最適合從“小而有明確邊界”的任務(wù)開始比如為工具函數(shù)補(bǔ)充單元測試。實(shí)現(xiàn)一個(gè)獨(dú)立的算法函數(shù)。重構(gòu)某個(gè)模塊的命名。編寫命令行參數(shù)解析邏輯。這類任務(wù)上下文清晰、驗(yàn)收標(biāo)準(zhǔn)明確AI 出錯(cuò)的影響范圍也小。更重要的是開發(fā)者可以在低風(fēng)險(xiǎn)場景中積累“如何描述任務(wù)、如何給上下文、如何寫驗(yàn)收標(biāo)準(zhǔn)”的經(jīng)驗(yàn)。不管 AI 生成得再好人工審查和驗(yàn)收都不能省略。代碼審查時(shí)要特別關(guān)注幾個(gè)點(diǎn)是否引入了多余依賴。是否修改了與任務(wù)無關(guān)的代碼。是否有安全漏洞比如路徑穿越、命令注入。錯(cuò)誤處理是否正確。6.2 把 Prompt 模板納入版本管理在我的團(tuán)隊(duì)實(shí)踐里prompts/和skills/目錄像普通源碼一樣納入 Git 管理。這樣做的好處是任務(wù)描述可以復(fù)用不用每次重新寫。團(tuán)隊(duì)成員之間可以共享同一套流程。AI 生成行為更容易復(fù)現(xiàn)和調(diào)試。一個(gè)典型的提交記錄可能是feat: 新增 config-validator 技能和任務(wù)模板6.3 將 AI Coding 集成到 CI 流程如果團(tuán)隊(duì)已經(jīng)使用 CI可以考慮把 AI 生成代碼的質(zhì)量檢查放入流水線例如通過 Git 提交觸發(fā)測試。CI 中增加代碼風(fēng)格檢查。自動(dòng)運(yùn)行安全掃描工具。一條基礎(chǔ)命令可能是pytest -v ruff check src tests不過需要提醒的是CI 自動(dòng)執(zhí)行 AI 生成的代碼風(fēng)險(xiǎn)很高建議在審查通過后再合入主干。6.4 安全邊界與最小權(quán)限原則使用 AI Coding Agent 時(shí)安全邊界是重中之重。建議遵循最小權(quán)限原則不要讓 Agent 直接操作生產(chǎn)環(huán)境。不要將密鑰、Token、數(shù)據(jù)庫密碼放入提示詞或上下文。限制 Agent 可以執(zhí)行的命令尤其是刪除、覆蓋、格式化等危險(xiǎn)操作。每次 Agent 執(zhí)行操作前先確認(rèn)它要執(zhí)行的命令清單。在測試環(huán)境或沙箱環(huán)境中驗(yàn)證 AI 的自動(dòng)化流程。如果你在團(tuán)隊(duì)內(nèi)部推廣 AI Coding最好先制定一份“AI Coding 使用規(guī)范”明確哪些操作允許、哪些操作需要人工確認(rèn)、哪些操作完全禁止。6.5 記錄 Prompt 與生成結(jié)果沉淀團(tuán)隊(duì)經(jīng)驗(yàn)每次 AI Coding 任務(wù)完成后除了代碼提交還可以簡單記錄以下信息任務(wù)描述和使用的技能。生成結(jié)果的亮點(diǎn)和問題。調(diào)整了哪些提示詞才達(dá)到理想效果。下次類似任務(wù)可以復(fù)用的經(jīng)驗(yàn)。這些記錄可以放在項(xiàng)目的 AI_NOTES.md 文件中。隨著積累團(tuán)隊(duì)會(huì)逐步形成一套適合自己項(xiàng)目的 AI Coding 方法論而不是每次都從零開始試。6.6 不要盲目追求 Agent 全自動(dòng)雖然 AI Coding Agent 看起來很強(qiáng)大但從工程角度看“全自動(dòng)”和“質(zhì)量穩(wěn)定”在短期內(nèi)很難兼得。比較穩(wěn)妥的做法是先讓 Agent 輸出計(jì)劃人工確認(rèn)后再執(zhí)行。讓 Agent 修改代碼但禁止直接推到主干。讓 Agent 運(yùn)行測試但保留人工檢查測試覆蓋率的環(huán)節(jié)。這套方式雖然沒有“極端自動(dòng)化”那么炫酷但更符合生產(chǎn)環(huán)境的質(zhì)量要求。7. 總結(jié)與后續(xù)學(xué)習(xí)方向這篇文章圍繞“AI Coding for Real Engineers”這個(gè)主題重點(diǎn)介紹了如何用 Do Work Skill Solution 這套技能化工作流把 AI Coding 從“生成代碼片段”升級(jí)為“完成真實(shí)開發(fā)任務(wù)”。通過前面的內(nèi)容我們可以提煉出幾個(gè)關(guān)鍵點(diǎn)AI Coding 分為代碼補(bǔ)全、對話生成、自主 Agent 三個(gè)層次工程價(jià)值依次遞增。Do Work Skill Solution 是提示詞、上下文、工具調(diào)用和驗(yàn)證流程的組合核心是“讓 AI 干活”。結(jié)構(gòu)化任務(wù)卡片、多文件修改計(jì)劃、技能定義文件、驗(yàn)證閉環(huán)是落地 AI Coding 的四大支柱。實(shí)戰(zhàn)中建議從小任務(wù)開始明確修改范圍做好安全邊界和人工審查。如果你接下來想深入了解 AI Coding可以從這幾個(gè)方向繼續(xù)學(xué)習(xí)函數(shù)調(diào)用與工具調(diào)用理解 Agent 如何執(zhí)行外部命令和操作文件。主流 AI Coding Agent 的配置方式以官方文檔為準(zhǔn)實(shí)踐不同工具的任務(wù)執(zhí)行流程。本地模型與私有化部署適合對數(shù)據(jù)安全要求較高的團(tuán)隊(duì)。代碼評(píng)審與測試生成自動(dòng)化把 AI 能力擴(kuò)展更廣的工程環(huán)節(jié)。最后想說的是AI Coding 并不會(huì)取代工程師但它會(huì)持續(xù)改變工程師的工作方式。真正拉開差距的不是誰用到更新的模型而是誰能把 AI 的能力穩(wěn)定地約束在工程規(guī)范之內(nèi)。建議你先挑一個(gè)小任務(wù)按照本文的方法跑通一次完整流程然后把效果好的提示詞和技能模板沉淀下來。用著用著你就會(huì)發(fā)現(xiàn) AI Coding 開始真正幫你“干活”了。