企业官网建设流程全解析

一、先给结论

AI Coding 的发展，大致经历了这样一条路线：

代码补全 ↓ 对话式编程 ↓ Copilot 编程 ↓ Agent 编程 ↓ Spec-Driven Development ↓ Harness-Driven Development

这条演变背后的核心变化是：

AI Coding 正在从“帮人写几行代码”，发展为“在约束、工具、测试和反馈组成的环境中，独立完成软件工程任务”。

早期关注的是：

模型能不能写出一段看起来正确的代码？

现在更关注的是：

模型能不能在真实代码库中，理解目标、修改多个文件、运行测试、处理错误，并最终交付一个可验证的结果？

二、什么是 AI Coding

AI Coding 不只是“让 AI 生成代码”，而是 AI 参与软件开发全过程：

• 理解需求
• 阅读代码库
• 设计实现方案
• 拆解开发任务
• 编写和修改代码
• 运行测试
• 调试错误
• 重构代码
• 创建文档和提交记录
• 根据反馈继续迭代

因此，AI Coding 的能力不只取决于模型本身，还取决于：

模型能力 + 上下文管理 + 工具调用 + 任务规划 + 测试反馈 + 安全约束 + 人机协作流程

也就是说，AI 编程逐渐从单纯的模型问题，变成了一个完整的软件工程系统问题。

三、第一阶段：代码补全——AI 是“高级自动补全”

1. 典型形态

最早的 AI Coding 主要表现为：

• 根据当前代码补全下一行
• 根据注释生成函数
• 根据函数名猜测实现
• 自动生成重复性代码
• 补全类型、参数和 API 调用

使用方式通常是：

defcalculate_total(items):# AI 根据上下文补全这里

AI 可能生成：

returnsum(item.price*item.quantityforiteminitems)

2. 这一阶段解决了什么问题

它主要提高了：

• 打字效率
• 重复代码编写速度
• 常见 API 的使用效率
• 简单函数的实现速度
• 开发者查找模板代码的效率

3. 它的局限

代码补全有一个重要限制：

AI 只负责生成局部代码，不负责确认整个任务是否完成。

它通常不知道：

• 业务目标是什么
• 这段代码是否符合产品需求
• 其他模块是否需要同步修改
• 数据库迁移是否需要添加
• 测试是否需要更新
• 这段实现是否破坏已有逻辑

因此，它更像：

人类负责思考和决策 AI 负责局部代码生成

这个阶段的 AI 仍然是“代码输入法”，而不是软件工程师。

四、第二阶段：对话式编程——AI 开始理解自然语言需求

1. 从代码编辑转向自然语言交互

随后，开发者可以直接告诉 AI：

帮我写一个读取 CSV 文件并统计每个用户订单金额的 Python 函数。

AI 不再只根据光标附近的代码进行补全，而是根据一段自然语言描述生成完整代码。

这带来了几个变化：

• 编程入口从代码变成了自然语言
• AI 可以一次生成更完整的函数或模块
• 开发者可以要求 AI 解释代码
• AI 可以帮助定位报错
• AI 可以根据反馈修改实现

2. 人机交互变成循环

典型流程是：

人：实现一个登录接口 AI：生成第一版代码 人：增加验证码校验 AI：修改代码 人：这个错误怎么解决？ AI：解释错误并给出修复

这形成了一个基本循环：

描述 → 生成 → 反馈 → 修改

3. 仍然存在的问题

虽然 AI 可以写出更完整的代码，但它依然容易出现：

• 忽略隐含需求
• 误解业务规则
• 使用过时 API
• 只修改当前文件
• 忘记更新测试
• 生成无法运行的代码
• 解决一个问题时引入另一个问题

原因是：

自然语言需求通常是不完整、不精确、不可直接验收的。

例如：

做一个用户登录功能。

这句话没有说明：

• 使用邮箱还是手机号登录
• 密码如何存储
• 错误提示应该是什么
• 是否需要验证码
• 是否限制登录次数
• 是否支持第三方登录
• 登录成功后跳转到哪里
• 是否需要记录登录日志

AI 可以生成“一个看起来像登录功能的实现”，但不一定是用户真正需要的实现。

五、第三阶段：Copilot 编程——AI 进入开发环境

1. AI 不再只是聊天窗口

接下来，AI 被集成到 IDE 和代码编辑器中，能够：

• 读取当前文件
• 读取相关文件
• 根据项目上下文生成代码
• 直接修改代码
• 解释选中的代码
• 生成测试
• 根据错误信息提供建议

此时，AI 的角色从：

问答机器人

变成：

代码编辑器中的协作助手

2. 上下文成为关键问题

AI Coding 的效果开始强烈依赖上下文质量。

AI 需要知道：

• 项目的目录结构
• 当前使用的框架
• 代码风格
• 数据模型
• 构建命令
• 测试命令
• 项目约定
• 相关模块之间的依赖关系

于是出现了各种上下文机制：

当前文件 + 打开的文件 + 相关代码片段 + 项目说明 + Git diff + 错误日志

3. 新的瓶颈：上下文窗口不等于理解能力

即使模型可以读取很多代码，也不代表它真正理解整个项目。

常见问题包括：

• 读取了太多无关文件
• 没有找到真正相关的代码
• 混淆多个相似模块
• 遗漏隐藏的架构约定
• 修改范围过大
• 记住了旧版本代码
• 只理解局部，无法理解全局影响

因此，AI Coding 开始需要更加结构化的工作方式，而不能只依赖“把代码全部塞进上下文”。

六、第四阶段：Agent Coding——AI 开始执行完整任务

1. AI 从“建议代码”变成“执行任务”

Agent Coding 的关键变化是：

AI 不只是告诉你应该怎么改，而是可以自己完成一系列操作。

例如：

用户：给这个项目增加 OAuth 登录支持。

Agent 可能执行：

1. 阅读项目目录
2. 查找现有认证逻辑
3. 查看依赖配置
4. 设计改动方案
5. 安装必要依赖
6. 修改后端代码
7. 修改前端页面
8. 添加环境变量
9. 编写测试
10. 运行测试
11. 根据报错继续修复
12. 汇总改动结果

这已经不是简单的代码生成，而是一个软件工程执行循环。

2. Agent 的基本循环

观察 Observe ↓ 思考 Plan ↓ 行动 Act ↓ 验证 Verify ↓ 根据反馈继续迭代

用伪代码表示：

whilenottask_completed:context=inspect_repository()plan=decide_next_step(context)result=use_tool(plan)feedback=run_tests_or_checks()update_state(feedback)

3. Agent 为什么比普通聊天更强

因为它具备了几个重要能力：

工具调用

可以调用：

• 文件读取工具
• 文件编辑工具
• 终端
• Git
• 测试框架
• 浏览器
• 数据库
• API
• 部署系统

多轮迭代

它可以：

修改代码 → 运行测试 → 看到错误 → 再修改

面向结果

传统聊天模型的输出是：

一段代码

Agent 的输出更接近：

一个经过验证的代码变更

4. Agent Coding 的新问题

Agent 变强之后，问题也从“代码写得对不对”变成了：

• 它是否理解了任务？
• 它是否修改了不该修改的文件？
• 它是否执行了危险命令？
• 它是否遗漏了测试？
• 它是否在错误方向上反复尝试？
• 它是否声称完成但实际上没有验证？
• 它是否引入安全漏洞？
• 它是否知道什么时候应该询问人类？

这说明：

Agent 能力越强，越需要明确的任务边界、执行规则和验证机制。

七、第五阶段：Spec-Driven Development——先明确“做什么”

1. 为什么需要 Spec

Agent 可以执行任务，但自然语言任务往往过于模糊。

例如：

优化一下这个页面。

对人类来说，这句话可能意味着：

• 提高加载速度
• 改善视觉设计
• 优化移动端体验
• 调整交互流程
• 修复无障碍问题
• 提高转化率

对 AI 来说，存在大量可能的解释。

因此，开发流程开始强调先编写 Spec：

需求目标 + 功能范围 + 非功能要求 + 约束条件 + 验收标准

2. Spec 的作用

Spec 主要解决四个问题。

统一目标

让人类、AI、测试人员理解的是同一件事。

限定范围

明确哪些内容要改，哪些内容不要改。

提供决策依据

当存在多种实现方式时，可以根据 Spec 判断哪种更符合要求。

支持验收

最终可以判断：

这个任务到底完成了吗？

3. Spec-Driven 的基本流程

用户需求 ↓ Spec：明确需求和验收标准 ↓ Plan：设计技术实现方案 ↓ Tasks：拆解开发任务 ↓ Implement：编写代码 ↓ Test：运行测试和检查 ↓ Review：人工或 AI 审查

也可以表示为：

Spec → Plan → Tasks → Implement → Verify

4. Spec 不等于传统文档

传统需求文档经常存在这些问题：

• 写给人看，但不容易执行
• 只有功能描述，没有验收标准
• 需求和实现混在一起
• 内容过于宏观
• 更新不及时
• 无法映射到测试

AI Coding 中的 Spec 更强调：

• 精确
• 可操作
• 可验证
• 与代码库相关
• 能够指导 Agent
• 能够转化为测试

5. 一个简单例子

模糊需求

给系统增加文件上传功能。

更完整的 Spec

# 文件上传功能 Spec ## 目标 允许用户在个人资料页面上传头像。 ## 功能要求 - 支持 PNG、JPEG 和 WebP 格式 - 单个文件大小不得超过 5MB - 上传成功后显示新的头像 - 用户取消上传时不修改原头像 - 上传失败时显示明确的错误提示 ## 安全要求 - 服务端必须验证文件类型，不能只依赖文件扩展名 - 文件名不得直接用于存储路径 - 用户只能修改自己的头像 ## 验收标准 - 合法图片可以成功上传 - 超过 5MB 的文件会被拒绝 - 非图片文件会被拒绝 - 未登录用户不能调用上传接口 - 上传失败不会删除原头像

这样的 Spec 就可以直接指导：

• 技术方案设计
• 任务拆解
• 测试用例编写
• Agent 执行
• 最终验收

八、从 Spec 继续发展：为什么出现 Harness

1. Spec 仍然不够

Spec 解决了：

我们希望实现什么？

但它没有完全解决：

AI 应该在什么环境中实现？
它可以使用哪些工具？
如何获得反馈？
如何判断它真的完成了？
如果失败了，应该怎样恢复？

这就引出了Harness。

九、什么是 Harness

1. 基本含义

Harness 原意是“挽具、套具”，在软件工程和 AI 系统中通常可以理解为：

围绕 AI 模型搭建的一套执行、约束、反馈和验证系统。

在 AI Coding 中，Harness 不是单个提示词，也不只是测试工具，而是让 AI Agent 能够稳定完成工作的“运行环境”。

可以把它理解为：

Harness = AI Agent 的工作台、工具箱、护栏和反馈回路

2. Harness 通常包含什么

Harness ├── 任务输入 ├── Spec 和项目规则 ├── 代码库上下文 ├── 文件读写工具 ├── 终端和构建工具 ├── 测试与静态检查 ├── Git 和变更管理 ├── 权限控制 ├── 错误反馈 ├── 状态记录 ├── 重试与恢复机制 └── 最终验收标准

3. Harness 和 Spec 的区别

可以用一句话概括：

Spec 定义目的，Harness 提供实现目的所需的环境。

十、为什么 AI Coding 会从 Spec 走向 Harness

原因一：任务从局部代码变成了完整交付

早期任务是：

补全一个函数

现在任务可能是：

为一个已有项目增加完整功能，并保证不破坏现有系统

任务范围变大后，单纯依赖模型生成代码已经不够，需要：

• 获取上下文
• 调用工具
• 执行测试
• 处理错误
• 管理修改范围
• 保存中间状态

这些都属于 Harness 的职责。

原因二：模型会生成代码，但不会天然保证结果

语言模型的本质是根据上下文生成最可能的输出。

它擅长：

• 识别模式
• 生成代码
• 解释概念
• 推测实现

但它不会天然知道：

• 代码是否真的能运行
• 需求是否完全满足
• 是否违反项目规范
• 是否破坏其他功能
• 是否存在安全问题

因此，必须给它一个外部反馈系统：

AI 生成代码 ↓ 运行测试 ↓ 返回真实错误 ↓ AI 修复

Harness 的核心价值就是把“代码生成”连接到“真实验证”。

原因三：真实代码库具有复杂状态

一个真实项目并不是一组孤立的代码片段，而是一个复杂状态系统：

代码 + 依赖 + 配置 + 数据库 + 环境变量 + 测试 + 构建流程 + Git 状态 + 部署环境

AI 如果不了解这些状态，就容易做出局部正确、整体错误的修改。

Harness 可以帮助 Agent：

• 在正确目录中工作
• 使用正确的 Python 或 Node 环境
• 执行项目规定的测试命令
• 读取项目级规则文件
• 控制可以访问的资源
• 保留变更记录
• 在失败后恢复

原因四：AI Agent 需要“护栏”

Agent 能够执行终端命令之后，风险会增加。

例如，它可能：

• 删除重要文件
• 修改生产配置
• 暴露密钥
• 执行危险命令
• 大范围重写代码
• 引入不安全依赖

所以 Harness 需要提供权限和安全控制：

哪些文件可以修改？ 哪些命令可以执行？ 哪些操作必须人工批准？ 哪些目录禁止访问？ 哪些秘密不能进入上下文？

这类机制通常称为：

• Guardrails
• Sandbox
• Permission Control
• Approval Gate
• Policy Enforcement

它们都是 Harness 的组成部分。

原因五：任务失败时需要恢复，而不是重新开始

真实开发很少一次成功。

常见过程是：

第一次实现失败 ↓ 测试发现问题 ↓ 修改方案 ↓ 第二次实现失败 ↓ 调整依赖或接口 ↓ 最终通过

如果没有 Harness，Agent 可能：

• 忘记之前做过什么
• 重复修改同一个地方
• 不知道当前 Git 状态
• 覆盖已有改动
• 在错误方向上继续尝试

Harness 可以保存：

• 当前任务状态
• 已完成步骤
• 测试结果
• 错误日志
• 文件变更
• 上一次决策
• 需要人工处理的问题

因此，Harness 让 Agent 从“一次性回答”变成“可以持续运行的工程过程”。

十一、Harness 的核心：闭环，而不是工具数量

很多人会把 Harness 理解成：

给 Agent 接上更多工具。

但工具多并不一定代表系统强大。

真正重要的是能否形成闭环：

明确目标 ↓ 读取正确上下文 ↓ 采取有限行动 ↓ 获得真实反馈 ↓ 根据反馈调整 ↓ 满足验收标准

可以写成：

Goal → Context → Action → Feedback → Evaluation → Correction

如果只有工具，没有反馈：

AI → 修改代码 → 结束

这仍然只是自动代码生成。

如果有完整 Harness：

AI → 修改代码 → 构建 → 测试 → 检查 → 修复 → 再测试 → 交付

这才接近真正的 Agentic Coding。

十二、从 Prompt 到 Spec，再到 Harness

AI Coding 的控制方式也在变化。

1. Prompt 驱动

帮我实现一个登录接口。

特点：

• 快
• 灵活
• 上手简单
• 依赖模型临场理解
• 结果不稳定
• 难以复用和验收

2. Spec 驱动

根据这份 Spec 实现登录功能，并满足所有验收标准。

特点：

• 目标更明确
• 方便拆解任务
• 方便编写测试
• 更适合多人协作
• 更容易复用
• 仍然依赖 Agent 自己完成执行

3. Harness 驱动

Agent 在规定的代码库、工具、权限、测试和反馈机制中， 按照 Spec 执行任务，直到满足验收条件。

特点：

• 不只规定目标
• 还规定执行环境
• 有明确工具
• 有自动反馈
• 有安全边界
• 有失败恢复
• 有最终验证
• 更适合长任务和批量任务

三者可以这样理解：

十三、Harness-Driven Development 的基本流程

第一步：定义任务目标

目标：为订单系统增加批量取消订单功能。

第二步：定义 Spec

- 用户可以一次选择多个待支付订单 - 已支付订单不能被批量取消 - 每次最多选择 50 个订单 - 操作完成后显示成功和失败数量 - 操作必须记录审计日志

第三步：准备 Harness

Harness 需要提供：

• 项目目录
• 项目规则
• 数据模型说明
• 可用工具
• 构建命令
• 测试命令
• 数据库测试环境
• Git 变更检查
• 安全权限

第四步：Agent 执行

读取代码 → 定位订单模块 → 设计修改方案 → 修改后端接口 → 修改前端交互 → 添加测试

第五步：自动反馈

运行单元测试 运行类型检查 运行 lint 运行集成测试 检查 API 文档 检查 Git diff

第六步：循环修复

测试失败 → 将真实错误反馈给 Agent → Agent 修改代码 → 重新运行测试

第七步：最终验收

Spec 条件全部满足 + 测试通过 + 代码变更在允许范围内 + 没有敏感信息泄露 + 人工审查通过

十四、Harness 中最重要的几个组件

1. 上下文加载器

负责向 Agent 提供正确的信息：

• 项目说明
• 目录结构
• 相关源码
• 编码规范
• 历史决策
• 测试方式
• 当前 Git 状态

关键不是“加载最多的信息”，而是：

加载对当前任务最有用的信息。

2. 工具层

典型工具包括：

read_file search_code write_file patch_file run_tests run_build git_diff database_query browser_test

工具应该：

• 能够返回真实结果
• 错误信息清晰
• 权限范围明确
• 尽量支持可逆操作

3. 验证器

验证器负责判断任务是否达到要求：

• 单元测试
• 集成测试
• 端到端测试
• 类型检查
• 静态分析
• 格式检查
• 安全扫描
• Spec 验收检查

验证器是 Harness 的“反馈传感器”。

4. 状态管理

长任务需要记录：

{"task":"增加批量取消订单","completed_steps":["定位订单模块","添加后端接口"],"current_step":"编写集成测试","test_status":"2 passed, 1 failed","files_changed":["orders/api.py","orders/service.py"]}

状态管理能够减少重复劳动，也方便任务暂停和恢复。

5. 权限和沙箱

Harness 应该限制：

• 文件访问范围
• 命令执行权限
• 网络访问权限
• 环境变量访问
• 数据库操作范围
• 生产环境操作权限

对于高风险操作，可以设置人工确认：

普通文件修改：自动执行 运行测试：自动执行 安装依赖：需要确认 删除数据库：禁止 部署生产环境：人工批准

6. 评估器

评估器不只检查“测试是否通过”，还可以检查：

• 是否完成全部需求
• 是否修改了不相关文件
• 是否遵守代码风格
• 是否增加了足够测试
• 是否引入不必要的依赖
• 是否存在安全风险
• 是否符合性能要求

十五、AI Coding 的能力评价标准正在变化

早期评价 AI Coding，常看：

• 代码是否语法正确
• 函数是否能运行
• 单个测试是否通过
• 代码生成速度

现在更重要的指标是：

1. 任务完成率

复杂任务最终是否真正完成，而不是只生成一段代码。

2. 一次成功率

是否需要大量人工修正。

3. 验证可靠性

Agent 是否会主动运行测试，并根据真实结果修复。

4. 变更准确性

是否只修改必要文件，避免无关重构。

5. 长任务稳定性

任务运行几十分钟甚至更久时，是否会迷失目标。

6. 安全性

是否能够避免：

• 泄露密钥
• 执行危险命令
• 引入漏洞
• 破坏数据
• 越权访问

7. 可审计性

能否回答：

• 改了哪些文件？
• 为什么这样改？
• 运行了哪些检查？
• 哪些测试通过了？
• 还有哪些风险？

这些指标都已经超出了单纯的模型代码生成能力，必须依赖 Harness。

十六、为什么未来的竞争不只是模型竞争

AI Coding 的最终效果可以近似表示为：

AI Coding 效果 = 模型能力 × 上下文质量 × 工具质量 × 反馈质量 × 任务定义质量 × 验证质量 × 安全控制质量

其中任何一项接近零，整体效果都会显著下降。

例如：

• 模型很强，但没有项目上下文，仍然会改错代码
• Spec 很清楚，但没有测试，仍然不知道是否完成
• 工具有很多，但反馈不真实，Agent 会在错误方向上运行
• 测试很完整，但权限过大，可能造成严重副作用
• Harness 很完善，但任务目标模糊，Agent 仍然不知道要做什么

因此，未来 AI Coding 产品的差异化，可能越来越体现在：

• 更好的代码库理解
• 更可靠的任务规划
• 更强的测试反馈
• 更好的状态管理
• 更细粒度的权限控制
• 更低成本的长任务运行
• 更完整的工程协作流程

十七、一个完整的现代 AI Coding 工作流

对应到实际开发：

1. 先写清楚需求 2. 检查项目规则和现有架构 3. 制定技术方案 4. 拆成可执行任务 5. 让 Agent 修改代码 6. 运行真实测试 7. 将错误反馈给 Agent 8. 循环直到通过 9. 检查 diff 和安全性 10. 人工确认后合并

十八、Spec 和 Harness 的关系

可以用下面这张表总结：

最关键的关系是：

Spec 定义正确结果 Harness 帮助产生正确结果 Evaluation 判断是否得到正确结果

十九、最终理解

从 Spec 到 Harness，反映了 AI Coding 的一个根本变化：

AI 生成代码 ↓ AI 理解任务 ↓ AI 执行任务 ↓ AI 根据反馈迭代 ↓ AI 在受控环境中完成可验证交付

因此：

• Spec解决“目标不清楚”
• Plan解决“方案不清楚”
• Tasks解决“执行步骤不清楚”
• Harness解决“执行环境、工具、反馈和安全不完整”
• Tests/Evaluation解决“无法确认是否真正完成”

最终，AI Coding 的核心不再是：

让模型写出更多代码。

而是：

让 AI 在明确目标、真实反馈和安全约束下，持续完成软件工程任务。

这也是为什么 AI Coding 会从Prompt-Driven走向Spec-Driven，再走向Harness-Driven：

从表达意图， 到定义规范， 再到构建一个能够稳定实现规范的执行系统。