# 第三篇｜AI 的实践论：人类如何与 AI 共同行动？

> 核心命题：当 AI 从"回答问题"进入"执行任务"，真正被重构的将不是软件，而是组织。

![image.png](https://developer.qcloudimg.com/http-save/yehe-1750537/861183719e981d0bf6ec1d0d9477caad.png)
## 0. 坐标

本文回答第三问："AI **能做什么**？以及我们该和它**如何共同行动**？" 前两篇解决了"是什么"和"知道什么"，实践论处理的是行动、责任与制度设计——这也是最直接触及工程与组织变革的一问。

## 1. 从 Copilot 到 Agent：自治的连续谱

"AI 协助编码"不是单一形态，而是一条自治程度递增的谱：

```mermaid
flowchart LR
 C[Copilot 人主导·AI 补全] --> AC[Agentic Coding AI 主导·人监督]
 AC --> AA[Autonomous Agent AI 执行·人设边界]
```

- **Copilot**：人写意图，AI 补全片段；决策权全在人。
- **Agentic Coding**：AI 拆任务、写代码、跑测试，人审批关键节点。
- **Autonomous Agent**：AI 端到端执行，人只设定目标与权限边界。

逻辑要点：**自治不是"全有或全无"，而是"权限 + 目标 + 约束 + 反馈"四个变量的具体配置**。讨论"AI 会不会取代人"是伪问题；真问题是每一步里**决策权落在哪一侧**。

## 2. 软件架构的重新定义：为什么 AI 会放大错误架构

当 AI 开始直接产生产量代码，架构问题被放大而非消失：

- **人设计 → AI 实现**：架构由人定，AI 负责落地——当前最稳妥的路径。
- **AI Coding 放大错误架构**：AI 擅长沿着既有结构快速生成，若结构本身错误，它会把错误复制得又快又多。
- **Context Engineering**：给 AI 足够且正确的上下文，比换更强的模型更有效。
- **Contract / Boundary**：用契约与边界约束 AI 的产出范围。
- **Architecture Fitness Function**：把架构质量量化成可自动校验的函数。

下面这张图把"AI 参与架构决策"的责任边界画出来（这也是"架构决策实验室"的核心场景）：

```mermaid
flowchart TD
 H[人 Human 定义边界与契约] --> C[Context 上下文与约束]
 C --> A[AI Agent 生成代码与方案]
 A --> F[Fitness Function 架构适配度校验]
 F -->|通过| D[交付 Deliver]
 F -->|不通过| H2[回退给人 重新定义边界]
 H2 --> H
```

关键结论：**当 AI 参与"定义边界、生成代码、执行决策、验证结果"时，人的角色从"写代码的人"上移为"定义边界与校验收敛的人"。**

## 3. AI 时代的组织：从岗位到能力单元

组织形态也随之改变：

- **人与 AI 的职责划分**：人负责目标、边界、责任；AI 负责执行、探索、重复劳动。
- **数字员工**：把 Agent 当作可委派任务的执行单元。
- **一个团队管理多个 Agent**：管理工作从"管人"延伸到"管 Agent 的组合"。
- **从岗位到能力单元**：固定岗位让位于按任务动态编排的能力组合（人 + 若干 Agent）。

## 4. 责任到底归谁：HITL 与 HOTL

这是实践论里最严肃的问题。责任控制有两种基本位置：

- **Human-in-the-loop（HITL）**：AI 每步都需人确认，人始终在回路内。
- **Human-on-the-loop（HOTL）**：AI 自主运行，人只在异常/高风险时介入。

```mermaid
flowchart TD
 D[AI 决策 Decision] --> R{风险评估 Risk}
 R -->|低风险| E[自主执行 Auto]
 R -->|高风险| HI[Human-in-the-loop 逐项审批]
 E --> M[监控 Monitoring]
 HI --> M
 M -->|异常| HO[Human-on-the-loop 人接管]
 M --> A[审计 Audit 全程可追溯]
```

逻辑要点：**HITL 和 HOTL 不是二选一，而是按风险分级混用**；责任制（accountability）与可审计性（auditability）是前提——没有审计日志的自动化，责任就无处安放。

## 5. AI 原生组织

当 AI 成为组织的一等公民，"原生"意味着不是"给旧流程加 AI"，而是从设计之初就考虑 AI：

- **AI 原生产品**：产品体验围绕 AI 能力而建。
- **AI 原生企业**：业务流程以 AI 执行单元为中心重组。
- **AI 原生软件工程**：开发流程、测试、部署都含 Agent。
- **AI 原生管理**：管理对象包含"人 + Agent"的混合单元。

## 6. 谁在行动？——行动闭环与制度设计

最终问题落到一条链条上：

```mermaid
flowchart TD
 H[人 Human 目标与权限] --> AI[AI Agent 计划与执行]
 AI --> T[工具 Tool 代码·API·部署]
 T --> W[世界 World 线上系统]
 W --> FB[反馈 Feedback 线上结果]
 FB --> AI
 AI -. 权限·目标·约束 .-> H
```

这一闭环说明：行动者不是单一的"人"或"AI"，而是一个**人—AI—工具—世界**的耦合系统。Agent 的行动边界由四个变量共同定义：**权限、目标、约束、反馈**。所谓"AI 时代的制度设计"，本质就是为这四个变量立法。

## 7. 结论

回到核心讨论题：当一个 Agent 自己分析需求、修改代码、调用 API、部署系统、依据线上反馈继续修改，"程序员完成了什么"这个问题，已经需要重新定义。

实践论的回答是：**程序员的工作从"产出代码"上移为"定义可验证的目标、设定权限边界、设计反馈与校验机制"**。我们不是在"使用 AI"，而是在与一种新的智能行动者**共同构造系统**——而构造者对边界与责任的定义，才最终决定了这套系统是可控的工具，还是失控的裂缝。

### 思考题

- 在"人设计 → AI 实现"里，"设计"与"实现"的边界到底划在哪里？写出你认为不可下放的三件事。
- 一个 Agent 依据线上反馈反复改代码，如果出事故，责任应当落在"写 Agent 的人""设目标的人"还是"批权限的人"？为什么？

核心命题：当 AI 从"回答问题"进入"执行任务"，真正被重构的将不是软件，而是组织。

03-AI实践论-人类如何与AI共同行动

人工智能

职业发展

架构设计

AI从回答问题转向执行任务，重构核心是组织而非软件。人类与AI协作沿自治谱系演进，人负责定义目标与边界，AI执行生成。架构错误被AI放大，需用契约和适应性函数约束。组织从岗位转向人机混合能力单元，责任由HITL/HOTL分级控制，程序员角色上移为边界定义与校验者。

软件工程

软件架构

Agent

Solid

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

03-AI实践论-人类如何与AI共同行动-腾讯云开发者社区-腾讯云

03-AI实践论-人类如何与AI共同行动

03-AI实践论-人类如何与AI共同行动

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐