企业官网建设流程全解析

AI Coding 工具越出越多，但很多团队的落地方式还停留在“让 AI 写一个函数”“让 AI 解释这段代码”。真正的痛点在于：AI 生成了代码之后，谁去验证它能跑？谁来把零散生成结果拼成完整交付物？答案已经从“人肉补位”变成一个工程概念——Do Work Skill。

Do Work Skill 是 AI Coding for Real Engineers 系列第 52 期的主题，核心思路是把 AI 的能力从“对话式写代码”升级成“完成完整工作任务”。它不是某个单一模型，也不是固定软件，而是一套技能化封装方案：把任务定义、上下文、执行步骤、质量校验、交付格式固定下来，让 AI Agent 可以按同一套方式反复执行。

这个方案最值得关注的有三点。第一，它把“随机生成”变成“流程化交付”，每一次任务都有明确的输入、输出和验收标准，不再依赖工程师反复打字调 prompt。第二，它支持批量任务，可以把一批需求丢给执行器处理，而不是开一个聊天窗口手点。第三，它可以暴露成 API 服务，接到 CI、工单系统或内部工具里，真正进入研发链路。

本文会用一个可落地的示例带读者完成：定义 Do Work Skill、编写执行器、跑通单任务与批量任务、封装 HTTP API、设计质量验证流程。如果你正在评估 AI Coding 工具，或者想把 AI Agent 真正接进研发流程，这篇可以直接收藏，按步骤落地。

1. Do Work Skill 核心能力速览

先给一张规格表，快速判断这个方案适不适合你。需要说明的是，以下能力项基于方案设计本身，具体的模型服务、token 消耗、任务耗时都需要按实际环境测试。

这套方案不是某个开箱即用的一键包，而是一种可复制的工程模式。看懂之后，你既可以用它接入现有 AI Coding 工具，也可以在自己的 Agent 系统里实现同样的能力。

2. 为什么 AI Coding 需要 Do Work Skill

过去一年，AI Coding 的形态变化很快。最早的 Copilot 是行级补全，接着是 Agent 式编程，再到 Vibe Coding 平台，用户描述需求就能生成一个可预览的页面。Vercel 等平台的 AI Vibe Coding 模式，已经让“数小时完成过去需要数周的工作”成为可能，国内团队也陆续推出 GLM Coding Plan 这类计划式方案。

但问题也随之而来：生成速度越快，验证压力越大。AI Coding 真正缺的不是代码生成能力，而是“把活干完”的能力。一个完整的 Do Work Skill 至少要经历需求解析、任务拆解、编码、测试、修复、交付六个环节。普通聊天式 AI Coding 只覆盖“编码”这一段，前后环节全靠人补，一旦任务稍微复杂，上下文一断，生成结果就无法直接使用。

Do Work Skill 的思路是把工程经验沉淀成可执行的契约。契约里明确输入是什么、输出是什么、中间要执行哪些动作、最终用什么标准验收。这样 AI Agent 的行为就从“概率生成文本”变成了“按流程完成任务”，即使中间某一步出错，也能定位到具体环节并重试。

和普通 Prompt 相比，Do Work Skill 的优势也很明显。Prompt 是一次性的，换一个任务就要重新写；Skill 是可复用的，定义一次之后可以不断被调用。Prompt 没有质量门禁，AI 输出什么就是什么；Skill 强制走验证流程，不满足条件就不算完成。团队内部可以积累多个 Skill，形成自己的“技能库”，新人上手也能直接使用团队沉淀的最佳实践。

3. Do Work Skill 解决方案总体设计

一个真正能落地的 Do Work Skill 解决方案，通常包含四个核心组件。

Skill 定义层：描述技能名称、输入参数、执行步骤、输出格式和验收标准。推荐使用 YAML 或 Markdown 格式，方便版本管理和 diff 审查。这一层负责把“做什么”变成机器可读的结构。

执行器层：负责加载 Skill 定义，读取任务输入，调用 LLM 服务，执行命令或脚本，写回结果。执行器是唯一的“马甲层”，它屏蔽了不同模型厂商 API 的差异，也方便接入真实工具链。

验证层：对执行结果做静态检查、单元测试、安全扫描或人工复核。验证层是 Do Work Skill 和普通 AI 生成之间最大的区别。没有验证层，AI 编码就永远停留在“看起来能用”的阶段。

调度层：负责把多个任务排队执行，记录日志、统计失败、执行重试。调度层可以独立成脚本，也可以封装成 API，让外部系统通过 HTTP 发起任务。

一个任务的生命周期可以概括为：外部系统提交任务请求，执行器加载对应 Skill，收集目标目录和上下文，调用 LLM 生成代码或分析结果，脚本自动跑测试和检查，结果写入输出目录，最后生成一份报告。整个过程可以设定超时和重试次数，避免单个任务卡死拖垮整条流水线。

4. 环境准备与前置条件

这个方案对硬件要求很低，普通开发机就能跑。不涉及本地大模型训练，也不需要独立显卡，关键是能访问一个可用的 LLM 服务。以下是推荐检查清单。

正式使用前，先确认几件事：LLM 服务地址能访问通；模型支持多轮任务窗口，至少能容纳一次任务所需的系统提示词和输入代码；目标代码仓库已经初始化好，并且有干净的测试命令。如果有一条不满足，后面的流程就会卡在同一个位置。

安装依赖通常只需要一条命令。如果你的执行器使用 Python 生态，可以这样装基础包：

pip install pyyaml requests fastapi uvicorn

这里不锁版本，是因为不同项目可能共用环境，锁死版本容易冲突。更稳的做法是为这个方案单独建一个虚拟环境，或者用项目级requirements.txt管理。

5. 搭建目录结构与 Skill 定义

建议按下面这个目录结构组织整套方案。目录分层清晰，后续扩展新 Skill 的时候不需要改动执行器代码。

do-work-skill/ ├── skills/ │ ├── code-review-skill.yaml │ └── task-breaking-skill.yaml ├── contexts/ │ └── repo_scan.md ├── inputs/ │ └── tasks/ ├── outputs/ │ ├── reports/ │ └── results/ ├── logs/ ├── runner.py ├── batch_run.sh ├── api_server.py └── requirements.txt

skills放所有技能定义，contexts放公共上下文说明，inputs/tasks放外部传入的任务 JSON，outputs放每次任务的产物，logs记录运行日志。第一次跑通之前，不用把每个目录都建好，代码里会预留自动创建目录的逻辑。

以代码审查技能为例，Skill 定义文件可以写成这样：

# skill.yaml —— Do Work Skill 定义示例 name: code-review-skill version: 0.1.0 description: 对指定目录的代码变更执行审查并生成问题清单 inputs: - name: target_dir description: 需要审查的代码目录 required: true type: string - name: focus description: 审查重点 required: false default: "bug,security,performance" steps: - name: gather_context action: collect_files params: extensions: [".py", ".js", ".ts"] - name: generate_review action: llm_task params: model: "your-llm-service" max_output_tokens: 2000 - name: write_report action: save_markdown params: output_dir: "./outputs/reports"

上面的action字段是示意，真正运行时需要由执行器把每个 action 映射到具体函数。Skill 定义的作用是把“流程步骤”和“具体实现”解耦，让你可以在不改代码的情况下新增技能。

Skill 文件看起来像配置，实际就是一种可执行工作流。团队长期使用后，可以在skills下积累代码审查、接口联调、测试生成、需求拆解等多个技能，每个技能都有明确的输入输出，形成一个可以被持续观测和优化的 AI 研发组件库。

6. 实现执行器与单任务运行

执行器是整套方案的大脑，负责读取 Skill 定义、解析任务输入、调用 LLM、执行本地命令、保存结果。先给一个最小可用的 Python 执行器示例，核心逻辑已经固定，你只需要替换 LLM 调用部分。

# runner.py —— 通用执行器示例 import json import sys from pathlib import Path try: import yaml except ImportError: raise SystemExit("请先安装 PyYAML: pip install pyyaml") def load_skill(skill_path: str) -> dict: with open(skill_path, "r", encoding="utf-8") as f: return yaml.safe_load(f) def run_skill(skill: dict, inputs: dict) -> dict: # 这里替换为真实的 LLM 调用逻辑 # 示例中直接生成固定报告，实际应调用你的模型服务 target = inputs.get("target_dir", "./src") focus = inputs.get("focus", "bug,security") # 模拟调用 LLM 的过程 report_lines = [ "# 代码审查报告", "", f"- 目标目录: {target}", f"- 审查重点: {focus}", "- 结论: 未发现阻塞性问题（示例输出）", ] report_path = Path("outputs") / "reports" / "report.md" report_path.parent.mkdir(parents=True, exist_ok=True) report_path.write_text("\n".join(report_lines), encoding="utf-8") return {"status": "success", "report": str(report_path)} if __name__ == "__main__": skill = load_skill(sys.argv[1]) inputs = json.loads(sys.argv[2]) result = run_skill(skill, inputs) print(json.dumps(result, ensure_ascii=False, indent=2))

执行器最关键的设计点是：输入全部走命令行参数，不写死任何路径。这样既能手动运行，也能被批量脚本调用，将来还能被 API 服务复用。

手动执行一个任务，命令大概长这样：

python runner.py ./skills/code-review-skill.yaml '{"target_dir": "./src", "focus": "bug,security"}'

如果执行成功，终端会输出状态码和报告路径。首次跑通后，再去替换你的真实 LLM 调用逻辑：把runner.py里的注释部分改成读取本地环境变量LLM_API_KEY，再通过 requests 把系统提示词、Skill 定义和任务输入一起发送给模型服务，拿到结果后写到输出目录。

这一步完成后，你就有了一套不依赖聊天窗口的 AI Coding 执行链路。接下来要做的就是把它放大到批量场景。

7. 批量任务与调度

批量任务的价值在于，把重复性工作从“人工盯聊天窗口”变成“脚本自动跑”。下面这个脚本会扫描inputs/tasks目录下所有 JSON 文件，逐个调用执行器，并把日志写入outputs/results。

#!/usr/bin/env bash # batch_run.sh —— 批量任务示例 skill_file="./skills/code-review-skill.yaml" inputs_dir="./inputs/tasks" outputs_dir="./outputs/results" mkdir -p "$outputs_dir" for task in "$inputs_dir"/*.json; do echo "=== processing $task ===" python runner.py "$skill_file" "$(cat "$task")" \ > "$outputs_dir/$(basename "$task" .json).log" 2>&1 if [ $? -ne 0 ]; then echo "failed: $task" else echo "done: $task" fi done

实际生产环境建议再补两层能力。第一层是任务级超时，给每个任务加timeout，防止模型服务长时间不返回导致脚本卡死。第二层是失败重试，对因为网络抖动、临时限流导致失败的任务，可以重试 1 到 3 次，重试间隔最好做指数退避。

从材料来看，常见的 AI Coding 任务失败原因集中在上下文窗口不够、模型输出截断、脚本执行权限错误三类。批量跑之前，建议先用两三个最小任务打通链路，再放量。批量结果不能只依赖终端输出，应该固定写入结构化日志，记录任务名、耗时、状态、输出产物路径，方便后期统计成功率。

如果任务数量很大，比如一次跑上百个代码目录审查，建议不要用for循环串行跑，而是引入简单的并发控制。可以基于 Python 的concurrent.futures实现线程池，把并发数控制在 3 到 5 个，避免同时打满模型服务的速率上限。

8. 质量验证与效果评估

Do Work Skill 和普通 AI 生成最大的不同，就是强制加入验证环节。没有验证，AI 输出代码质量高不高只能靠感觉；有了验证，每次任务都能得到客观结论。

常见的验证维度可以这样设计：

验证可以在执行器内部直接触发，也可以放在 CI 流程中独立执行。推荐第二种方式：执行器只负责生成结果，验证由 CI 任务完成，职责更清晰。

为了让人工复核也有统一标准，可以给每个 Skill 配一份“完成定义”清单，也就是 Definition of Done，简称 DoD。示例模板如下：

## 任务完成清单 - [ ] 代码通过静态检查 - [ ] 单测通过 - [ ] 关键路径已经人工审查 - [ ] 安全扫描无高危问题 - [ ] 输出报告已保存到指定目录 - [ ] 耗时和 token 消耗已记录

效果评估建议看两个指标：任务成功率，即一次运行不经过人工修复就通过全部验证的比例；平均返工次数，即一个任务在交付前要执行几轮“生成-验证-修复”。这两个指标直接决定了 AI Coding 方案是真正提效，还是换了一种方式给工程师增加工作量。

9. 接口 API 与工程集成

如果只做本地脚本，Do Work Skill 还是不够方便。把执行器封装成 HTTP API 之后，团队所有系统都能通过标准请求触发任务，这是接入 CI、工单平台、内部研发工具最关键的一步。

一个最小可用的 FastAPI 服务如下：

# api_server.py —— Do Work Skill API 示例 from fastapi import FastAPI from pydantic import BaseModel from runner import run_skill, load_skill app = FastAPI(title="Do Work Skill API") class TaskRequest(BaseModel): skill_path: str inputs: dict @app.post("/run") async def run_task(req: TaskRequest): skill = load_skill(req.skill_path) result = run_skill(skill, req.inputs) return {"code": 0, "data": result}

启动服务：

uvicorn api_server:app --host 127.0.0.1 --port 8000

调用接口：

curl -X POST http://127.0.0.1:8000/run \ -H "Content-Type: application/json" \ -d '{"skill_path": "./skills/code-review-skill.yaml", "inputs": {"target_dir": "./src", "focus": "bug,security"}}'

这里选用 127.0.0.1 而不是 0.0.0.0，是一种保守做法。AI Coding API 会读取代码仓库并触发模型调用，如果随意监听公网地址，会有代码泄露和接口被滥用的风险。生产环境建议加一层 API Key 鉴权，并且只允许内网访问。

接口设计上要注意，/run是同步接口，模型生成时间较长时容易触发 HTTP 超时。更稳的方案是拆成“提交任务”和“查询结果”两个接口：提交任务返回task_id，后台线程执行；查询接口根据task_id返回任务状态和产物路径。这套异步模式对批量和 CI 场景更友好。

10. 资源占用与性能观察

Do Work Skill 的资源和传统本地大模型部署不同，重点不是显存，而是 token 消耗、响应延迟、任务吞吐和日志容量。

建议在每次任务执行时把元数据写入一个 JSON 日志文件，例如：

{ "task_id": "task_001", "skill": "code-review-skill", "status": "success", "duration_sec": 35, "prompt_tokens": 8200, "completion_tokens": 1800, "report_path": "outputs/reports/task_001.md" }

拿到这些数据后，可以持续优化：如果 prompt token 占用过高，先压缩上下文，只把改动的 diff 喂给模型，而不是整个文件；如果单任务耗时太长，考虑换更快的模型或者缩小输入范围；如果批量任务出现 429，就把并发数调低，增加退避时间。

这个方案毕竟要依赖外部模型服务，模型本身的固有延迟没法完全消除。你能控制的是输入输出大小、并发策略和失败重试逻辑，这三项优化到位，整体效率会有明显提升。

11. 常见问题与排查方法

首次搭建 Do Work Skill 方案，大概率会遇到下面几类问题。这里整理成排查表格，按“现象-原因-排查-解决”四步处理。

排查这类问题有一个通用顺序：先确认日志，再看服务状态，最后检查输入数据。日志是整个方案最重要的排障依据。批量任务跑挂了一次，不要急着调模型参数，先看它是哪个环节失败，是模型请求失败还是脚本执行失败，再决定下一步。

如果模型返回的内容形式不稳定，不要完全依赖 AI 自己解析，建议在 Skill 定义里严格规定输出格式，并在执行器里写一个“重试解析”逻辑：一旦 JSON 解析失败，就把错误信息和原始输出拼回 prompt 让模型重新生成。

12. 最佳实践与使用建议

把 Do Work Skill 真正落地到团队，下面几条经验比代码本身更重要。

第一个是初次使用先小后大。不要一上来就定义十个 Skill、跑一百个任务。先选一个高频场景，比如“代码变更审查”，用最小配置跑通单任务，再扩展到批量。前期阶段人工复核一定要保留，记录 AI 输出和人工修改的差异，这些差异就是后续优化 Skill 定义的依据。

第二个是保持一套最小可运行配置。把 Skill 定义、执行器、批量脚本和 API 服务放进同一个 Git 仓库，版本号严格对应。这样无论谁拉取代码都能还原环境，Skill 升级也不会影响线上正在跑的任务。

第三个是模型文件、任务输入、输出结果分目录管理。输入任务和输出结果不要混在一起，最好按任务 ID 归档，方便追溯。日志至少要保留最近一周，方便排查问题。

第四个是批量任务必须加日志和失败重试。任何一次网络抖动都可能让整个批量任务中断。给每个任务生成独立日志文件，记录开始时间、结束时间、状态、耗时、token 用量。失败任务单独写在failed_tasks.log里，人工确认原因后再决定是否重跑。

第五个是接口服务要限制访问范围。尽量部署在内网，增加简单的 Token 鉴权，不要用默认端口裸奔。AI Coding 工具会读取代码仓库，涉及公司核心代码时必须做访问控制和操作审计。

第六个是版权和数据合规。代码审查、代码生成都会把代码片段发送给模型服务，使用前要确认团队数据和公司合规要求。如果需要严格保密，建议选择私有化部署的模型服务，并在 Skill 定义中屏蔽敏感文件目录。

13. 总结与下一步

Do Work Skill 最值得尝试的点，就是它把 AI Coding 从“写代码”推到了“完成工作”的位置。方案本身不强依赖某个具体模型，也不要求高性能显卡，几乎所有团队都能以很低成本跑起来。

建议新读者最开始只做一件事：定义好一个代码审查 Skill，用一个小仓库跑通单任务。重点看两个数据：一次任务从提交到产出报告需要多久，报告里有多少问题被人工确认有效。这两个数据达标后，再往批量任务和 API 集成扩展。

最容易踩的坑是跳过质量验证直接放大批量。AI 生成的代码如果在没人检查和测试的情况下被合并，风险会成倍放大。Do Work Skill 的“验证层”不是可选配置，而是安全底线。

后续扩展可以从三个方向继续：一是积累更多 Skill 类型，把技术调研、接口联调、测试用例生成都纳入技能库；二是对接 CI/CD 流水线，让 Pull Request 自动触发 Skill 任务；三是增加异步任务队列，把提交和查询分离，支撑更大的并发量。

这套方案会随着模型能力的升级持续变强。现在的任务定义和验证流程，即使未来换更强的模型也能复用。建议收藏备用，从一次小范围的代码审查任务开始验证，跑通之后再逐步铺开。