> ## Documentation Index
> Fetch the complete documentation index at: https://aicoding.cscitech.top/llms.txt
> Use this file to discover all available pages before exploring further.

# 人、模型、工具与代码如何协作

# 人、模型、工具与代码如何协作

AI Coding 不是“人提一句要求，AI 独自把项目做完”，而是一套由**人、模型、工具与代码**共同参与的协作系统。

可以先把四者记成一个团队：

* **人**是负责人：定义目标、提供背景、判断取舍并验收结果；
* **模型**是智能助手：理解上下文、提出方案并生成候选内容；
* **工具**是执行环境：读取文件、修改代码、运行命令并收集反馈；
* **代码**是工作对象和事实依据：它既承载实现，也通过运行结果证明方案是否成立。

只有四者形成闭环，AI Coding 才能从“生成一段看起来正确的文字”变成“完成一个经过验证的开发任务”。

## 先用一个类比理解：软件开发小组

假设一个小组要改造一间房子：

* 人像项目负责人，决定房间要给谁使用、预算多少、什么效果算完成；
* 模型像设计顾问，根据要求提出布局和施工建议；
* 工具像卷尺、电钻和施工设备，把方案转化为实际操作；
* 代码像房屋本身，任何修改最终都要体现在结构中，并接受真实使用的检验。

设计顾问再聪明，也不能代替负责人决定真实需求；没有工具，设计只能停留在图纸上；不检查房屋，谁也无法确认改造是否安全。

AI Coding 中也是同样的关系：**人定方向，模型出候选方案，工具负责执行，代码和测试返回事实。**

## 一、人的职责：目标、判断与责任

人是整个协作流程的发起者和最终负责人，主要承担五项工作：

1. **定义目标**：要解决什么问题？为谁解决？
2. **补充上下文**：技术栈、相关文件、现有规则和历史背景是什么？
3. **设置约束**：哪些文件可以改？能否新增依赖？性能和安全要求是什么？
4. **做出取舍**：多个方案中选哪个？为什么？
5. **最终验收**：代码是否正确、安全、可维护并满足真实需求？

例如，“做一个登录功能”还不是完整目标。人需要进一步明确：使用密码还是验证码、是否需要找回密码、如何处理失败次数、数据如何保护，以及什么测试通过后才能上线。

<aside>
  🎯

  AI 可以协助分析和建议，但不能替人承担产品决策、安全责任与上线后果。
</aside>

## 二、模型的职责：理解、生成与解释

模型根据人提供的文字、代码和反馈，生成可能有用的候选内容，例如：

* 澄清需求并提出问题；
* 解释现有代码和报错；
* 给出任务拆解和实现方案；
* 生成代码、测试和文档初稿；
* 比较多种技术方案；
* 审查代码并指出潜在风险；
* 根据运行结果修正方案。

模型的优势是速度快、知识面广、善于处理模式化工作；局限是不了解未提供的项目事实，也可能产生过时用法、不存在的 API 或貌似合理的错误代码。

因此，模型最适合扮演“高效但需要审查的协作者”，而不是“永远正确的决策者”。

## 三、工具的职责：连接模型与真实项目

模型本身只能生成文字或操作建议。工具把这些建议连接到真实开发环境中。

不同工具可能提供以下能力：

| 工具能力   | 作用           | 需要防范的风险        |
| ------ | ------------ | -------------- |
| 读取文件   | 给模型提供项目上下文   | 读取到无关或敏感信息     |
| 搜索代码   | 找到函数、调用关系和配置 | 搜索不完整导致错误判断    |
| 修改文件   | 把方案写入项目      | 修改范围过大或覆盖正确代码  |
| 执行命令   | 安装依赖、构建和运行程序 | 破坏性命令、权限和供应链风险 |
| 运行测试   | 检查行为是否符合预期   | 测试不完整造成虚假安全感   |
| 查看版本差异 | 确认具体改了什么     | 未审查就接受全部修改     |

工具能力越强，AI 可以完成的步骤越多，但也越需要权限控制、修改前确认、版本管理和结果审查。

## 四、代码的职责：承载实现并提供事实反馈

代码不是被动的“输出结果”，而是协作过程中最重要的事实来源。

人和模型可以讨论方案，但最终要回到代码与运行结果：

* 现有接口到底如何定义，要看真实代码；
* 某个库是否已经使用，要看依赖配置；
* 修改是否有效，要运行程序和测试；
* 是否引入副作用，要查看差异和回归结果；
* 文档和推测发生冲突时，应进一步核对可执行事实。

一句重要原则是：**用代码、日志和测试验证 AI 的说法，不要只根据回答是否流畅来判断。**

## 四者如何形成协作闭环

一个可靠的协作流程通常包含以下七步：

1. **人提出任务**：说明目标、对象与验收标准；
2. **模型澄清问题**：找出缺少的信息和可能歧义；
3. **人补充上下文和约束**：提供相关代码、环境、规则和修改范围；
4. **模型提出计划**：拆解步骤，说明准备修改什么；
5. **工具执行最小修改**：读取文件、编辑代码并运行必要命令；
6. **代码和测试返回反馈**：提供输出、报错、差异和测试结果；
7. **人进行验收**：决定接受、继续迭代、回滚或更换方案。

可以把它记成：

**人定目标 → 模型出方案 → 工具做操作 → 代码给反馈 → 人做判断**

这个循环可能重复多次。复杂任务越不适合一次性生成，越需要小步执行和逐步验证。

## 一个完整示例：给待办应用增加“截止日期”

### 第一步：人定义任务

一个过于模糊的要求是：

> 给任务加个日期。

更清晰的要求是：

> 在现有待办应用中增加可选的截止日期。列表按日期显示，逾期且未完成的任务标红；不要新增第三方依赖，并保持旧数据可用。完成后运行现有测试，并补充日期为空和日期过期的测试。

这一步由人负责，因为只有人知道真正需求和限制。

### 第二步：模型阅读上下文并提出计划

模型查看任务数据结构、列表组件、存储逻辑和测试文件后，可能提出：

1. 在任务对象中增加可选的 `dueDate`；
2. 修改创建任务的表单；
3. 在列表中显示并判断逾期状态；
4. 兼容没有日期的旧数据；
5. 增加对应测试。

这只是候选计划，人需要确认它没有漏掉关键需求。

### 第三步：工具执行修改

AI 编辑器或 Agent 根据确认后的计划修改相关文件、运行格式检查和测试。此时应限制修改范围，不要顺便重构无关模块。

### 第四步：代码和测试提供反馈

如果测试显示旧数据加载失败，说明方案没有真正满足“保持旧数据可用”。这个失败比模型的一句“已经兼容”更可信。

### 第五步：人验收并继续迭代

人检查代码差异、页面行为和测试覆盖，确认：

* 没有日期的任务仍能正常显示；
* 逾期判断考虑了时区；
* 已完成任务不会错误标红；
* 没有引入无关依赖或大范围改动。

如果不满足，就把具体反馈交给模型继续修正。

## 合理的人机分工

| 工作   | AI 适合做什么       | 人必须做什么          |
| ---- | -------------- | --------------- |
| 需求分析 | 整理描述、发现歧义、提出问题 | 确认真实目标与优先级      |
| 技术设计 | 给出多个方案及优缺点     | 根据业务和项目情况做取舍    |
| 编写代码 | 生成样板代码和实现初稿    | 审查关键逻辑与修改范围     |
| 调试   | 分析报错、提出可能原因    | 收集现场、验证假设和确认根因  |
| 测试   | 生成测试用例和测试代码    | 判断覆盖是否充分并检查测试质量 |
| 代码审查 | 查找常见漏洞和不一致     | 对正确性、安全性和上线负责   |
| 文档   | 生成结构和初稿        | 保证文档与真实系统一致     |

最健康的分工不是“AI 全做，人只点接受”，也不是“人拒绝使用 AI”，而是让 AI 承担高频生成和重复劳动，让人把精力放在目标、边界、证据和决策上。

## 常见的协作失败模式

### 1. 人不给上下文，模型只能猜

表现：只说“修一下”“优化一下”，却不提供代码、环境和验收标准。

改进：说明期望与实际结果，提供最小相关上下文，让 AI 先提问。

### 2. 模型一次改太多，工具扩大风险

表现：一个小需求修改几十个文件，还顺便升级依赖和重构架构。

改进：先审计划，限制文件和任务范围，分批执行并保留回滚点。

### 3. 代码能运行，就被误认为完全正确

表现：程序没有崩溃便直接提交，没有检查边界情况、安全性和真实需求。

改进：定义验收标准，运行针对性测试，查看差异并进行人工审查。

### 4. 人把最终判断交给模型

表现：AI 说“已经修复”“没有安全问题”，人便直接相信。

改进：要求证据，用测试、日志、代码位置和官方资料验证结论。

## 小练习：给四个角色分配职责

你准备让 AI 给一个购物网站增加“优惠券”功能。请判断下列任务主要应该由谁负责：

1. 确定优惠券可以与哪些促销叠加；
2. 根据现有代码生成折扣计算函数初稿；
3. 修改项目文件并运行测试；
4. 通过测试结果确认金额计算是否正确；
5. 决定功能是否可以上线。

### 参考答案

| 任务        | 主要负责人 | 说明                                |
| --------- | ----- | --------------------------------- |
| 确定促销叠加规则  | 人     | 这是业务规则，需要结合运营目标、成本和风险决定；模型可以协助梳理。 |
| 生成折扣函数初稿  | 模型    | 模型适合根据明确规则生成候选实现，但需要人审查金额精度与边界条件。 |
| 修改文件并运行测试 | 工具    | 编辑器或 Agent 负责实际操作；人需要控制权限和修改范围。   |
| 返回金额计算结果  | 代码与测试 | 可执行结果提供事实反馈；模型可以解释失败原因，但不能替代运行。   |
| 决定是否上线    | 人     | 上线涉及正确性、安全性、业务影响与责任，必须由人最终决定。     |

\*\*协作顺序：\*\*人先定义规则，模型生成方案，工具执行操作，代码和测试返回证据，最后由人验收并做决定。

## 本节结论

在人、模型、工具与代码的协作中，没有任何一个角色可以单独保证成功：

* 人提供方向、约束、判断与责任；
* 模型提供理解、生成、解释与建议；
* 工具提供读取、修改、执行与反馈能力；
* 代码提供真实实现和可验证的结果。

真正可靠的 AI Coding，不是让 AI 获得无限自主权，而是建立一个**目标明确、权限受控、修改可查、结果可测、责任归人**的协作闭环。