一个微软全栈工程师的实战观察：GPT-5.6 Sol + Codex + MCP 如何重构 .NET/Azure 企业交付

从 GPT-5.4/5.5 到 GPT-5.6 Sol 的 Agent 代际跃迁，以及需求访谈、Subagent、Chrome、Computer Use、SSH、Azure DevOps 和生产发布组成的企业级 AI 软件工程闭环。

从需求访谈、Figma 设计、ADR、Azure Boards、自动编码，到沙盒测试、QA 部署与带审批的生产发布。

时效说明： 本文涉及的模型、客户端、插件、MCP 和云服务状态核对至 2026-07-26。实际可用性仍取决于套餐、地区、组织策略和管理员配置。

过去我们谈 AI 编程，通常想到的是代码补全、生成一个方法，或者帮忙解释异常。

但在使用 GPT-5.6 Sol 完成真实项目后，我感受到的已经不是“写代码更快”，而是软件工程的操作方式正在改变：

我不再需要亲手编写每一行代码，而是通过对话说明业务目标、现有系统和验收标准；
Agent 可以先追问需求、挑战方案，再整理产品规格、领域术语和架构决策；
在接入对应 MCP 并获得授权后，它可以读取 Azure DevOps 中的 Work Item、代码库、Wiki、Pipeline 和测试信息；
它可以根据 Figma 或 Lovable 原型实现前端，再完成 ASP.NET Core 后端、数据库和 Azure 基础设施；
它可以在隔离工作区中编译、运行单元测试、集成测试和浏览器自动化测试；
在具备对应工具和权限后，它可以提交变更、触发 CI/CD、部署 QA，并分析测试和监控结果；
在生产阶段，它可以继续自动执行，但必须经过企业预先设置的审批、权限和策略门禁。

这已经不是传统意义上的“AI 辅助开发”，而是一个初步成形的 AI 软件交付控制面。

不过，要准确理解这件事，必须先纠正一个容易误导人的说法。

一、不是一个模型单独完成了一切

本文所说的 GPT-5.6 Sol，主要指它作为 Codex 前沿 Agent 编码模型时所表现出的规划、工具调用、代码理解和长任务执行能力。OpenAI 当前的 Codex 产品资料已经列出包含 Sol、Terra 和 Luna 在内的 GPT-5.6 模型家族；但不同 ChatGPT 套餐、组织策略、客户端和地区的可用能力仍可能不同。OpenAI Codex Pricing

真正完成端到端交付的，不是裸模型，而是下面这套组合：

flowchart LR
    A["GPT-5.6 Sol<br/>推理、规划、生成、复盘"] --> B["Codex Agent Runtime<br/>文件、终端、Git、沙盒、子 Agent"]
    B --> C["AGENTS.md / Skills<br/>工程规范与可复用工作流"]
    B --> D["MCP / Plugins<br/>Azure DevOps、Azure、Figma、Teams、浏览器"]
    C --> E["确定性工程工具<br/>编译器、测试、静态分析、IaC"]
    D --> E
    E --> F["Azure Pipelines<br/>CI、QA、E2E、制品、部署"]
    F --> G{"生产门禁"}
    G -->|"批准"| H["Prod<br/>灰度、验证、监控、回滚"]
    G -->|"拒绝"| I["返回 Agent 修复"]

可以把各层的职责概括为：

层	解决的问题	不应该承担的职责
GPT-5.6 Sol	理解意图、分析上下文、制定计划、生成与修复	充当最终权限系统
Codex Runtime	读写仓库、运行命令、管理工作区、调用工具	绕过沙盒和组织策略
`AGENTS.md`	保存仓库结构、构建命令、代码规范、完成定义	存放密码和临时需求
Skill	把优秀工程方法固化成可重复流程	直接提供外部系统权限
MCP	把 Azure DevOps、Figma、Azure 等能力暴露给 Agent	替代业务流程和权限治理
Pipeline / IaC / Tests	提供确定、可重复、可审计的执行与验证	依赖模型“感觉应该没问题”
Human Gate	确认业务取舍、不可逆架构决策和生产风险	重新手工完成所有机械步骤

OpenAI 的 Codex 最佳实践也给出了相似路径：提供正确上下文，用 AGENTS.md 固化指导，通过 MCP 连接外部系统，把重复做法做成 Skill，再自动化已经稳定的工作流。Codex Best Practices

因此，所谓“无需写代码”，更准确的含义是：

人可以不再手工输入代码，但系统仍然会生成、编译、测试、审查和运行代码。
人从代码输入者变成了目标、约束、风险和验收标准的负责人。

还要注意产品成熟度。OpenAI 把能力区分为 Experimental、Beta 和 Stable：实验能力适合探索，Beta 适合试点，生产主链路应优先依赖 Stable 能力，并为非稳定组件设计降级路径。OpenAI Feature Maturity

二、从 GPT-5.4 到 GPT-5.6 Sol：Agent 开始从“流程外骨骼”走向“流程内生”

我是从 GPT-5.4 一路使用到 GPT-5.5，再到 GPT-5.6 Sol 的。这段连续体验让我感受到的最大变化，并不只是回答质量提高，而是 模型对完整工程任务的组织能力出现了明显跃迁。

下面的比较是我的真实使用观察，不是 OpenAI 发布的横向 Benchmark：

能力	GPT-5.4 时期的实际体验	GPT-5.5 时期的实际体验	GPT-5.6 Sol 的实际体验
模糊需求处理	容易过早进入实现，需要强制先讨论	能提出更多问题，但仍需要流程提示	更容易先理解目标、边界和完成条件
Spec / Plan	需要明确要求生成并持续维护	能生成较好文档，但长任务可能偏离	会主动拆分层次，维护 Spec、Plan 与当前进度
任务拆解	依赖人工或 Skill 给出切片方式	可完成拆解，但常需要复核顺序	更能识别依赖、并行项、验证项和停止条件
长任务执行	容易忘记前置约束或提前宣布完成	稳定性提高，但仍需要频繁拉回	更持久，会继续检查、修复并报告验证证据
并行协作	主要依赖外部 Agent 框架	能配合子任务，但编排较重	能使用 Subagent 分担研究、实现、测试和审查
外部流程 Skill	常像必需的“工程外骨骼”	仍能显著减少遗漏	更多变成按风险选用的专业增强

为什么 5.4/5.5 时期 Superpowers 很重要

Superpowers 本质上是一套完整的 Agent 软件开发方法：先 Brainstorm，形成设计文档，再写实施计划，使用 Worktree 隔离开发，通过 Subagent 执行任务，按 Red-Green-Refactor 做 TDD，然后进行规格符合性和代码质量审查。

在 GPT-5.4 和 GPT-5.5 阶段，这套流程非常有价值，因为它通过强制性的 Skill 和文档，把模型容易遗漏的工程纪律外置了：

先设计，不要直接编码
→ 保存设计文档
→ 编写细粒度 Plan
→ 按 Plan 实施
→ TDD
→ 独立审查
→ 验证后才能宣布完成

这就像给一个能力很强、但工作习惯还不够稳定的工程师穿上一套“流程外骨骼”。

5.6 Sol 的变化，不是少写了几句 Prompt

OpenAI 对 GPT-5.6 的官方说明与这种体感基本一致：

更强的 Intent Understanding，能从上下文推断用户真正想完成的目标和工作深度，不再需要人为规定每一步；
能在多步骤任务中表现得更主动、更持久；
推荐使用更精简、结果导向的 Prompt，减少重复流程说明；
Responses API 提供 Multi-agent Beta，可由一个 GPT-5.6 实例协调多个 Subagent 并综合结果；
支持 Programmatic Tool Calling，把一组边界明确的工具调用、数据过滤和验证交给程序化执行；
在更少输出 Token 下达到更高的复杂任务质量。

这些并不只是营销形容词。官方迁移指南建议从 GPT-5.5/5.4 原有 Reasoning 设置开始，比较同级与低一级设置；在部分工作负载中，5.6 能以更少输出 Token 维持或提高质量，但是否降低总成本，仍必须用真实任务的 Token、延迟和成功率评测。OpenAI GPT-5.6 Model Guidance

这里要区分 Responses API 的 Multi-agent Beta 与 Codex 客户端的 Subagent：前者是 API 编排能力，后者是 Codex Runtime 的任务委派能力，二者相关但不是同一个产品开关。

因此，当 GPT-5.6 Sol 在 Codex 中接到“完成这个功能”的目标后，它已经可能自己完成：

探索仓库和现有文档；
识别业务与技术不确定项；
编写 Spec 和分层 Plan；
标记串行依赖与可并行任务；
把研究、实现、测试、文档和审查委派给不同 Subagent；
汇总结果，处理冲突；
编译、测试、运行浏览器验证；
发现失败后继续修复；
在满足完成定义后输出证据。

Codex 当前的 Subagent 能力也不是简单“同时开几个聊天窗口”。主 Agent 可以把独立工作委派出去，让子 Agent 各自拥有更干净的上下文，再由主 Agent 汇总。这样可以减少长任务中测试日志、搜索结果和中间代码对主需求上下文的污染。OpenAI Codex Subagents

但 Subagent 不是每个任务都会自动启动。是否委派取决于客户端能力、组织策略、用户指令、AGENTS.md、Skill 和任务是否适合并行；有依赖、共享状态或高耦合的工作仍应串行处理。

可以说“内生了 Superpowers”，但不能说“内置了 Superpowers”

更准确的技术表述是：

GPT-5.6 Sol + 当前 Codex Runtime 已经内生了大量过去需要 Superpowers 显式提供的通用编排能力，但它没有在模型内部安装同一个 Superpowers Skill 包。

二者的区别很重要：

模型内生能力：理解目标、规划、拆分、委派、持续执行、调用工具和验证；
Superpowers：一套有明确偏好的外部方法论，例如强制 TDD、固定文档顺序、两阶段审查和完成分支流程；
企业规则：组织自己的安全、审计、测试、架构与发布制度。

模型越来越聪明以后，通用方法 Skill 的价值会下降，但企业特有规则不会自动出现在模型里。

TDD Skill 可以不再“必装”，但 TDD 和测试门禁没有过时

我同意一个很现实的判断：对于测试基础良好、AGENTS.md 清晰、CI 门禁完整的仓库，GPT-5.6 Sol 往往不再需要每次加载一套很重的 TDD Skill。

因为真正不可替代的不是“TDD Skill”这个文件，而是下面这些反馈事实：

改动前后必须有可失败、可重复的验证；
测试要验证公开行为，而不是复制实现；
Agent 不能只说“应该可以”，必须真正执行测试；
修复必须补回归覆盖；
没有通过 Build、Test、Lint、E2E 和必要安全检查，就不能宣布完成。

如果这些已经固化到测试框架、Pipeline、Hook 和完成定义里，5.6 Sol 可以自然地使用它们，专门 Skill 就从强制脚手架变成可选参考。

但在遗留系统、测试薄弱模块、金融结算、权限、并发、数据库迁移等高风险场景，TDD、系统化诊断和独立审查 Skill 仍然有价值。原因不是模型不聪明，而是这些 Skill 能把组织选择的风险偏好变成每次都必须重复的行为。

为什么 `grill-me` 反而仍然值得保留

模型可以从已知信息中推理，却无法知道业务人员没有说出的事实。

“修改报价是否重新审批”“代理审批是否允许越级”“海外订单由谁承担汇率风险”都不是靠更高 Reasoning 就能唯一推导出的答案。因此，5.6 Sol 越能快速实现，前置需求错误的代价反而越大。

这使 grill-me、grilling 或 grill-with-docs 成为更高杠杆的 Skill：

它们不是为了教 5.6 Sol 如何写 Plan，而是阻止一个执行速度极快的 Agent，把未经挑战的错误需求也高速实现出来。

我的建议因此从“给 Agent 安装一整套通用工程流程”变化为：

保留需求拷问与领域建模
→ 让 5.6 Sol 自主规划、拆解和委派
→ 用仓库规则与确定性测试约束完成标准
→ 只在高风险场景加载专门方法 Skill

三、它究竟能自动化到什么程度

如果企业已经有较好的仓库结构、自动化测试和 CI/CD，GPT-5.6 Sol + Codex 可以覆盖软件交付的大部分机械闭环。

阶段	Agent 可以完成	仍应由人负责
需求接入	读取会议纪要、邮件、Wiki 和 Work Item；识别冲突；逐项追问；形成用户故事与验收条件	业务目标、优先级、预算和范围确认
领域建模	统一术语；发现概念冲突；形成 `CONTEXT.md`、状态机、数据规则和 ADR	确认业务事实与难以逆转的决策
UI/UX	从自然语言生成原型；读取 Figma Frame、组件和变量；实现页面；比较截图差异	品牌、可用性和最终体验判断
架构设计	分析现有模块；提出 API、数据、缓存、消息、权限和部署方案；记录取舍	架构风险接受与跨系统责任边界
实施计划	按垂直切片拆分任务；建立依赖；写入 Azure Boards；定义每项完成条件	里程碑和资源优先级
编码	创建分支或 Worktree；修改前后端、迁移脚本、IaC 和测试；自我审查	对高风险实现做抽查或专题评审
沙盒验证	Restore、Build、Lint、Unit Test、Integration Test、E2E、差异检查、安全扫描	定义测试覆盖目标和不可接受风险
QA 发布	生成或修改 Pipeline；构建制品；部署 QA；执行 API、UI 和回归测试；分析日志	QA 准入规则与异常裁决
Prod 发布	生成发布说明；验证制品；执行灰度、健康检查、监控和回滚流程	生产审批、职责分离和紧急处置
线上运维	汇总 Application Insights/Azure Monitor 信号；诊断；创建 Bug；生成修复 PR	重大事故指挥、合规披露和业务决策

这里最关键的边界是：

测试环境可以高度无人值守；生产环境可以高度自动执行，但不应默认让 Agent 自己获得最终放行权。

Azure Pipelines 本身就支持 Dev、Test、QA、Staging 和 Production 环境，并记录部署历史、提交与 Work Item 的可追溯关系。Azure Pipelines Environments

生产环境的 Approval、Branch Control、Evaluate Artifact、Query Azure Monitor Alerts、Invoke REST API/Azure Function 和 Exclusive Lock 等门禁由资源所有者管理，而且不存放在普通 Pipeline YAML 中，提交代码的人或 Agent 不能仅通过修改仓库就删除这些检查。Azure Pipelines Approvals and Checks

这正是企业 Agent 应有的设计：AI 可以操作流水线，但不能拥有流水线之外的最终治理权。

四、一个贴近真实企业的 .NET + Azure 模板

下面用一个“企业订单与报价审批平台”作为模板。它也可以替换成 ERP 模块、财务报表系统、会员平台、供应链系统或内部运营后台。

1. 技术栈

前端：React + TypeScript，设计来源为 Figma 或 Lovable；
后端：ASP.NET Core Web API，企业现有 .NET LTS 版本；
数据：Azure SQL Database 或 Azure Database for PostgreSQL；
异步流程：Azure Service Bus；
缓存：Azure Managed Redis；
身份：Microsoft Entra ID；
密钥：Azure Key Vault；
部署：Azure App Service 或 Azure Container Apps；
可观测性：Application Insights + Azure Monitor；
基础设施：Bicep 或 Terraform；
工程平台：Azure Repos、Azure Boards、Azure Pipelines、Azure Test Plans。

新项目这里应优先使用 Azure Managed Redis。微软已经公布 Azure Cache for Redis 全部 SKU 的退役计划，并建议现有实例尽快迁移；因此再把旧产品作为新架构默认项会误导读者。Azure Cache for Redis retirement

2. 从一句模糊需求开始

业务最初可能只说：

“我们需要增加报价审批。金额大时要领导审批，海外客户可能还要财务复核，最好下个月上线。”

传统流程通常要经历多轮会议，产品经理再写文档，架构师补设计，开发发现遗漏后继续回头确认。

Agent 的第一步不应是立即生成数据库表，而应该进入需求访谈：

“大额”的阈值按币种、区域还是公司主体计算？
审批链在创建报价时固化，还是随组织架构实时变化？
修改报价后，原审批是否失效？
财务复核是并行还是串行？
代理审批、超时升级、撤回和拒绝后重提如何处理？
已发送给客户的报价能否作废？
审批记录的审计保存年限是多少？

这类问题非常适合 grill-me 或 grill-with-docs。后者会在访谈过程中同步维护统一语言和架构决策，而不是会后再靠记忆整理。当前 Matt Pocock Skills 的说明中，grill-with-docs 会把确定的术语写入 CONTEXT.md，把少量真正难以逆转的决定写入 ADR。grill-with-docs

输出可能包括：

CONTEXT.md：Quote、Approval Route、Approval Snapshot、Revalidation 等正式术语；
docs/adr/ADR-004-approval-route-snapshot.md；
用户故事、边界条件、非功能需求；
可执行的验收场景；
明确的 Out of Scope。

3. 从规格到 Azure Boards

需求收敛后，Agent 再把当前对话和仓库事实综合为 Spec，并按端到端能力拆成垂直切片：

报价创建与审批路线计算；
审批提交与并发控制；
金额修改后的重新验证；
Entra ID 权限与代理审批；
审批审计查询；
前端待办与审批详情；
通知和超时升级；
生产迁移和历史数据兼容。

通过 Azure DevOps MCP，Agent 可以读取和管理 Work Item、Repo、Wiki、Pipeline、Test Plan 等上下文。微软官方实现建议按 Domain 只启用当前需要的工具，例如 core、work-items、repositories、wiki、pipelines 和 test-plans，避免把庞大工具集一次性加载给模型。该项目当前仍处于 Preview，进入企业主链路前应固定版本、验证身份范围并准备 REST API/CLI 降级路径。Microsoft Azure DevOps MCP Server

还要注意，微软当前官方 Azure DevOps MCP 只支持云端 Azure DevOps Services 和本地运行的 MCP Server；本地部署的 Azure DevOps Server/TFS 与远程托管版 MCP 尚不在官方支持范围内。对应场景应改用经过安全评估的内部 MCP 或既有 REST API/CLI 集成。Azure DevOps MCP FAQ

这一步的真正价值不是“AI 会创建 Ticket”，而是每个 Ticket 都可以携带：

明确的用户可见结果；
涉及的模块边界；
前置依赖；
接口与数据约束；
测试切面；
完成定义；
回滚或兼容要求。

当一个任务能够被准确描述、独立验证并安全回滚时，它才真正适合交给 Agent 独立执行。

4. 从 Figma/Lovable 到可维护前端

Figma 官方 MCP 可以把设计上下文提供给 Agent，也可以读取选中的 Frame 生成代码；当前远程 MCP 是官方推荐方式，且仍处在快速演进阶段。Figma MCP Server

但“从 Figma 生成代码”不应该等于“把像素翻译成一次性 JSX”。企业项目还需要 Agent：

识别并复用现有 Design Token；
把 Figma Component 映射到仓库已有组件；
保持表单校验、权限、国际化和无障碍规范；
生成 Story/示例页；
在不同分辨率下执行截图或结构化 UI 验证；
检查新页面是否绕开企业设计系统。

Lovable 则更适合快速把已讨论需求转成一个可交互的初始项目或原型。其 ChatGPT 集成目前会从对话创建起点，后续深度迭代仍在 Lovable 中进行。Lovable ChatGPT App

对已有大型 .NET 企业系统，我更推荐：

Lovable 用于快速探索和原型；Figma 成为设计事实来源；Codex 负责把批准后的设计按现有仓库架构落地。

这样既得到生成式 UI 的速度，也避免把原型代码直接当作生产架构。

5. Agent 实现后必须进入确定性反馈环

一个可靠的实现回合不应只是“代码已经写好”，而应该是：

理解任务
→ 检查现有实现与约束
→ 选择最小垂直切片
→ 先建立可失败的验证
→ 实现
→ 编译与测试
→ 自审 Diff
→ 修复
→ 再验证
→ 输出证据

在 .NET 项目中，Agent 可以自动执行：

dotnet restore 与锁定依赖检查；
dotnet build，并把 Warning 作为质量信号；
xUnit/NUnit/MSTest 单元测试；
WebApplicationFactory API 集成测试；
Testcontainers 数据库和消息组件测试；
EF Core Migration 生成、幂等性与升级路径验证；
OpenAPI Contract 检查；
前端类型检查、Lint、组件测试；
Playwright E2E 与截图对比；
依赖漏洞、Secret 和危险配置扫描；
对最终 Diff 做回归、安全、并发和可观测性审查。

Playwright MCP 适合需要持久浏览器状态、结构化页面探索和自愈式测试的 Agent 循环；微软项目也特别指出，对于高吞吐编码 Agent，Playwright CLI + Skill 往往更节省上下文，而 MCP 更适合保持长期浏览器会话的探索场景。Microsoft Playwright MCP

这说明企业不应该为了“全部 MCP 化”而 MCP 化。能用确定 CLI、测试框架或 SDK 完成的事，通常继续用它们；只有需要外部上下文、授权和交互状态时才引入 MCP。

6. QA 可以接近无人值守

合并前，Azure Pipeline 执行：

Restore
→ Build
→ Unit Test
→ Integration Test
→ Contract Test
→ SAST / Dependency / Secret Scan
→ Publish Immutable Artifact

合并后，使用同一制品进入 QA：

IaC What-if
→ 部署 QA
→ 数据库兼容检查
→ API Smoke Test
→ Playwright E2E
→ Application Insights 查询
→ 测试报告与风险摘要

如果失败，Agent 获取 Pipeline 日志和测试证据，复现问题，创建修复分支，执行最小修复，再重新进入流水线。

Azure Pipelines 本身就是把持续集成、持续测试和持续交付组合起来的确定性平台，能够构建、测试并部署 C# 等多种技术栈。What is Azure Pipelines?

因此，Agent 不应替代 Azure Pipelines。更好的关系是：

Azure Pipelines 是铁路；Agent 是能够规划路线、修复故障、补齐测试并解释结果的智能调度系统。

技术上，可以在受信任的 Pipeline Runner 中使用 codex exec 非交互运行 Agent，让它读取日志、输出结构化诊断、生成补丁或执行仓库内验证。新流程应显式选择只读或 workspace-write 沙盒，并只授予单次任务所需权限；OpenAI 也建议在 CI 中把 API Key 仅暴露给那一次 Agent 调用，而不是整个执行 Job。Codex Non-interactive Mode

更安全的 Pipeline 拆法是：第一阶段只读分析失败；第二阶段在隔离工作区生成并验证 Patch；第三阶段只传递 Patch 制品；最后由一个不持有模型密钥、但拥有 Repo 写权限的独立 Job 创建 PR。这样即使测试脚本或依赖生命周期脚本被污染，也很难同时拿到模型密钥和代码库写权限。

7. 生产发布：自动执行，但保留不可伪造的门禁

生产发布建议采用：

只接受已经通过 QA 的不可变制品；
校验分支、签名、SBOM、安全扫描和数据库兼容性；
查询 Azure Monitor 当前是否存在高优告警；
由业务或发布负责人批准；
按目标平台执行发布：App Service 使用 Slot 部署与 Swap，Container Apps 使用 Revision 与流量权重，VM/Kubernetes 再选择适用的 Rolling 或 Canary；
自动运行健康检查和关键业务 Smoke Test；
观察错误率、延迟和关键业务指标；
达标后扩大流量，否则自动回滚；
Agent 生成发布总结并更新 Work Item。

Azure Pipelines 的 Deployment Job 支持 runOnce、Rolling 和 Canary 等策略，并提供部署历史与审计信息，但策略并非对所有目标资源通用：官方 Rolling 目前只支持 VM 资源；App Service 更适合 Slot Swap，Container Apps 则使用多 Revision 与流量拆分。Azure Pipelines Deployment Jobs Azure App Service with Azure Pipelines Azure Container Apps traffic splitting

这里的生产审批不是因为模型“不够聪明”，而是因为：

业务风险需要有人承担；
职责分离是治理要求；
生产变更可能涉及监管、合同和客户承诺；
模型无法自行获得组织授予责任的法律身份。

五、我会如何配置插件、MCP 和 Skill

很多人一看到 Agent 很强，就开始安装几十个工具。结果模型每次都面对庞大的工具说明、重复能力和过宽权限，反而变慢、变乱。

更好的方式是按交付链分层。

1. 微软技术栈优先插件

插件	推荐场景	优先级
Figma	读取设计、组件、Token，与设计稿协同	高
Teams	从项目频道读取讨论、生成状态同步	高
SharePoint	获取企业需求、规范、架构与合规文档	高
Outlook Email / Calendar	汇总需求邮件、会议背景和待办	中
GitHub	代码和 PR 位于 GitHub 时使用	条件性
Atlassian Rovo	企业使用 Jira/Confluence 时使用	条件性
Slack / Notion / Google Drive	按组织实际协作栈选择	条件性

这里列的是推荐组合，不代表每个 ChatGPT 账户都已开放。插件是否可安装、可连接和可执行写操作，取决于套餐、地区、工作区策略、管理员批准和目标系统授权。

如果主代码库在 Azure Repos，不要为了已有 GitHub 插件而迁移事实来源。使用 Azure DevOps MCP 连接 Azure Boards、Repos、Wiki、Pipelines 和 Test Plans 更自然。

2. 推荐 MCP 组合

MCP	用途	企业配置建议
Azure DevOps MCP	Work Item、Repo、Wiki、Pipeline、Test Plan	按 Domain 启用，读写权限分离
Azure MCP Server	查询和管理 Azure 资源	使用 Entra ID、Managed Identity、最小 RBAC
Figma MCP	设计上下文、组件、变量、画布	设计项目级授权，写操作单独审批
Playwright MCP	浏览器探索、QA、自愈式 E2E	QA 专用账号与隔离 Profile
Microsoft Learn MCP	获取最新微软官方文档和代码样例	作为只读知识源
企业自建 MCP	CMDB、审批、测试数据、业务规则、内部 API	严格 Schema、审计、幂等和工具白名单

Azure MCP Server 使用 Entra ID/Azure Identity，并让兼容 MCP 的 Agent 与 Azure 资源交互；这比把长期 Azure 密钥写进 Prompt 或脚本安全得多。Azure MCP Server

Microsoft Learn 也提供公开的只读 MCP 服务，便于 Agent 获取最新官方文档，而不是凭模型记忆猜测 SDK 和 Azure 配置。Microsoft Learn MCP Server

3. 推荐 Skill 链

在 GPT-5.6 Sol 下，我不再建议所有项目默认加载一整条重型 Skill 链。普通功能可以采用更轻的默认流程：

grill-with-docs
→ 5.6 Sol 自主生成 Spec / Plan
→ Subagent 并行研究、实现、测试与审查
→ 仓库内 Build / Test / E2E / Security 门禁
→ CI / QA 确定性验证
→ 发布审查与人工放行

高风险或工程基础薄弱的项目，再按需强化为：

grill-with-docs
→ to-spec
→ to-tickets
→ implement / tdd
→ independent code-review
→ CI / QA

各 Skill 的适用场景是：

Skill	适合什么时候
`grill-me` / `grilling`	想法模糊，需要逐个挑战假设，但暂时不写文档
`grill-with-docs`	需求访谈同时维护领域术语和 ADR
`domain-modeling`	业务术语混乱、同词多义、模型与代码不一致
`wayfinder`	大型项目仍处于“战争迷雾”，需要先建立决策地图
`prototype`	状态机、接口或 UI 需要先用廉价原型验证
`to-spec`	需要固定格式、可审计的正式规格时
`to-tickets`	复杂需求需要拆成可独立领取、验证的垂直切片时
`tdd`	测试薄弱或高风险模块需要强制 Red/Green 行为时
`diagnosing-bugs`	线上问题、性能问题、难复现 Bug
`code-review`	从正确性、回归、安全、可维护性和测试质量复核
`codebase-design`	在实现阶段设计小接口、深模块和可测试边界
`improve-codebase-architecture`	定期扫描和治理 Agent 加速后可能同步加速的代码熵
`skill-creator`	把企业自己的成熟流程做成 Skill
`plugin-creator`	把 Skill、MCP 和团队分发配置打包成插件

这里还有一个重要实践：Skill 要锁版本并验证依赖闭包。

这类社区 Skill 更新很快。例如近期版本已经把 to-prd 改名为 to-spec，把 to-plan 和 to-issues 合并为 to-tickets，并把主流程调整为 idea → to-spec → to-tickets → implement。Matt Pocock Skills Releases

所以企业不应该简单执行“永远安装 latest”，而应：

审查 SKILL.md、脚本、引用文件和间接依赖；
在测试仓库运行代表性任务；
固定已验证版本或 Commit；
记录来源、Hash、负责人和允许使用的工具；
升级时重新跑 Skill 行为测试。

Skill 本质上也是代码供应链的一部分。

六、从 Chrome 到 SSH：Agent 已经拥有软件交付“最后一公里”的执行能力

如果 Agent 只能修改仓库里的文件，它仍然只是一个高级编码工具。

当前 ChatGPT/Codex 客户端更有颠覆性的变化，是它已经可以在结构化工具之外继续操作浏览器、桌面应用和远程开发服务器。这填补了企业流程里最难自动化的“最后一公里”。

能力	最适合的场景	关键边界
MCP / Plugin	Azure DevOps、Figma、Teams、SharePoint 等有结构化接口的系统	首选方式，权限和数据结构最清晰
CLI / SDK	Build、Test、Git、IaC、Azure CLI、数据库迁移	最确定、最容易审计和重复
内置 Browser	Localhost、本地 Web 应用、独立浏览器任务	使用与个人 Chrome 分离的 Profile
Chrome 插件	已登录的 Azure Portal、Azure DevOps、内部后台和 SaaS	可以看到登录态，也意味着更高的数据与操作风险
Computer Use	Windows/macOS 桌面程序、安装器、只提供 GUI 的企业系统	只能操作获准应用；Windows 会占用前台桌面
SSH Remote Project	SSH 远程开发主机、内网构建机、QA Server	使用远端账号权限，必须按普通 SSH 生产标准治理
手机 Remote	查看进度、回复问题、批准命令、继续任务	手机是控制端，真正执行仍发生在已连接 Host

Chrome 插件：使用企业已有登录状态完成 Web 流程

ChatGPT 的 Chrome 插件不是一个全新的无状态浏览器。它可以在用户已有 Chrome Profile 和已登录站点中读取页面、点击、输入并执行多步骤任务，例如：

登录 Azure Portal 查看 App Service、Container Apps 或 Application Insights；
在 Azure DevOps 页面检查 Pipeline、Environment、Test Run 和 Work Item；
操作没有开放 API 的企业内部管理后台；
在真实登录状态下复现权限、Cookie、跳转和前端兼容问题；
在获准启用开发者模式后，结合 Chrome DevTools Protocol 检查 DOM、Console、Network 和性能 Trace。

Chrome 插件首次使用新站点时会请求站点级授权，可选择单次允许、允许该站点、允许全部站点或阻止；浏览历史访问还会单独请求权限。完整 CDP 访问需要显式批准，组织管理员也可以禁用。ChatGPT Chrome Extension

不要把“站点已授权”理解为“业务操作已审批”。内置 Browser 文档明确把提交信息、购买、权限变更和删除数据等列为敏感操作确认；企业还应叠加网站自身 RBAC、MCP 审批和不可绕过的发布门禁。ChatGPT Built-in Browser

这使一个非常现实的 Agent 闭环成为可能：

修改前端
→ 启动本地服务
→ 浏览器复现
→ 检查 Console / Network / DOM
→ 修改代码
→ 再次执行相同 UI 流程
→ 截图与结果验证

对于 Localhost 和不需要个人登录态的页面，应优先使用 ChatGPT 内置 Browser。它有独立 Profile，适合本地预览、页面批注和自动回归，能减少个人浏览数据暴露。ChatGPT Built-in Browser

Computer Use：补齐没有 API、没有 MCP、只有 GUI 的环节

Computer Use 可以在 Windows 或 macOS 上查看和操作获准的图形界面，包括窗口、菜单、键盘输入和剪贴板。它适合：

安装和升级桌面客户端；
验证 WPF、WinForms、MAUI 或其他桌面应用；
复现只能通过 GUI 触发的问题；
修改必须点选的本地配置；
在多个应用之间搬运经过授权的数据；
操作没有 MCP、插件或稳定 API 的遗留系统。

在 Windows 上，Computer Use 会接管当前前台桌面的鼠标和键盘，不能在同一个 Windows Session 中一边让 Agent 操作、一边由人正常使用。更适合的企业部署是准备一台专用 Windows VM，让 Agent 控制 VM，而人通过手机或另一台设备查看进度和授权。ChatGPT Computer Use

Computer Use 也不是“系统管理员绕过器”。它不能替用户批准操作系统安全与隐私权限，不能自行以管理员身份认证，也不能通过控制终端应用绕过 ChatGPT 的 Shell 沙盒。文件和命令仍受项目权限、沙盒与审批策略限制。

SSH Remote Project：Agent 可以直接在远程工程环境工作

ChatGPT 桌面客户端可以从 ~/.ssh/config 发现具体 Host，通过 SSH 在远程主机启动 Codex App Server。远程项目中的 Agent 可以：

读取和修改远程文件；
在远程 Shell 中运行 Build、Test、Git 和诊断命令；
使用远程主机安装的 SDK、容器、MCP 和 Skill；
在本地电脑与远程主机之间 Handoff 同一个 Chat 和 Git 状态；
在高算力开发机、内网环境或专用 QA Host 上继续任务。

SSH 连接不是把一个万能 Root Shell 交给模型。Agent 获得的仍然只是该 SSH 账号本身拥有的权限，因此应使用专用账号、可信密钥、最小权限、网络分区和完整审计，生产服务器不应与日常开发 Agent 共用身份。ChatGPT Remote Connections

手机可以成为“审核与放行终端”

Remote Connection 会先把手机与运行 ChatGPT 桌面客户端的 Host 配对；这个 Host 可以是常开电脑，也可以再通过 SSH 连接远程开发环境。手机不会直接获得 SSH 密钥或绕过 Host。人在手机上可以：

查看 Agent 当前执行到哪里；
阅读 Diff、测试结果、终端输出和截图；
回答 Agent 的阻塞问题；
批准或拒绝命令与外部操作；
发送后续指令；
在任务完成或需要介入时收到通知。

这使软件工程的人机分工真正接近：

人：提出目标、回答关键业务问题、审查证据、授予权限、承担发布责任

Agent：分析、设计、写 Spec、写 Plan、拆任务、并行实现、测试、
       操作浏览器、连接远程环境、部署 QA、诊断失败、生成修复、
       准备生产发布并等待放行

所以，从理论能力覆盖面看，“人主要负责目标、审核和权限放行，常见工程执行活动由 Agent 完成”已经不再是科幻。

但这里仍应保留一个工程上的限定：

软件交付链中大多数常见的执行动作都可以高度自动化，不等于所有责任与授权都应该自动化。

浏览器页面可能包含 Prompt Injection，已登录 Chrome 中的点击会被网站视为用户本人操作；Computer Use 能看到屏幕内容；SSH 能触达远程文件和 Shell。能力越完整，越需要最小权限、站点白名单、专用账号、隔离 VM、不可绕过的生产门禁和人类最终责任。

七、什么时候 Agent 真的可能超过一个资深团队

说 GPT-5.6 Sol “比资深工程师团队还强”，如果不加限定，会显得像营销口号。

但在一些维度，它确实可能超过传统团队：

能同时阅读大量代码、需求、日志和文档；
不厌倦地重复编译、测试、审查和修复；
可以按角色拆出需求、架构、测试、安全和运维子 Agent；
可以把每一次失败写回 AGENTS.md、Skill、测试或 Pipeline；
在保持在线的专用 Host 或云环境上，可以持续处理长任务和独立任务；
在拥有完整反馈环时，可以快速试错并保留证据；
没有人的疲劳成本，但仍可能误判、漏跑或错误解释测试，因此必须用 Pipeline 日志和门禁证明执行结果。

但它仍然不天然拥有：

企业内部没有写下来的隐性业务知识；
对客户、合同、监管和组织政治的真实责任；
对模糊价值冲突的最终裁决权；
生产事故中的法律与管理责任；
对恶意 Prompt、错误工具描述和过宽权限的天然免疫力。

所以我更愿意使用下面这个判断：

GPT-5.6 Sol 不是凭空替代一个资深团队。
它让一名真正懂业务和工程治理的资深工程师，把团队经验编译成一套可并行、可复制、可验证的数字化工程组织。

在这个组织里：

模型是推理引擎；
MCP 是神经和手脚；
Skill 是标准作业程序；
AGENTS.md 是团队工程手册；
Git、测试和制品是证据系统；
Pipeline 是执行纪律；
人类审批是责任边界。

八、企业落地最容易犯的七个错误

错误 1：给 Agent 一个超级管理员账号

开发、QA、生产必须使用不同身份。生产写权限不应直接授予日常编码 Agent。优先使用 Managed Identity、短期凭证、最小 RBAC 和环境审批。

错误 2：让 Prompt 承担硬规则

“不要删除生产数据”不能只写在 Prompt 中。必须同时落实为数据库权限、工具白名单、审批策略、备份、幂等设计和测试。

错误 3：把 MCP 当成越多越好

重复工具、超大 Schema 和过宽权限会增加选择错误和上下文污染。每个 Agent 只加载完成角色所需的最小工具集。

错误 4：没有自动测试，却期待自动开发

没有可执行反馈，Agent 只能根据文本猜测“完成了”。类型系统、测试、Lint、浏览器验证和监控才是自治能力的地基。

错误 5：QA 和 Prod 使用不同构建产物

必须 Build Once、Promote Many。QA 验证过的不可变制品才有资格进入生产。

错误 6：让 Agent 审查自己的全部高风险行为

关键 PR、安全变更、数据库破坏性迁移和生产放行，应使用独立 Reviewer、确定性策略或人工审批，而不是同一上下文里的“自我感觉良好”。

错误 7：只计算生成速度，不计算返工

真正应该观察的是从需求确认到生产验证的 Lead Time、一次通过率、回滚率、逃逸缺陷、人工等待时间和每个被接受变更的 Agent 成本。

九、一条现实的企业导入路线

不要第一天就追求“全公司无人值守生产发布”。建议逐级提升自治：

Level 1：只读工程助手

接入 Repo、Wiki、Work Item；
输出需求澄清、架构说明和代码分析；
不允许写外部系统。

Level 2：仓库内闭环

允许在隔离 Worktree 中修改代码；
自动 Build、Test、Lint、Review；
由人决定是否提交 PR。

Level 3：自动 PR 与 QA

自动拆 Ticket、创建分支和 PR；
Pipeline 自动部署 QA；
Agent 执行 API/E2E 并根据失败自动修复；
人审核合并。

Level 4：受控持续交付

合并后自动生成制品并进入 Staging；
自动执行安全、兼容性、监控和回归门禁；
生产由指定负责人批准；
自动灰度、观察和回滚。

Level 5：策略驱动自治

低风险、可逆变更在预授权策略内自动发布；
中高风险变更始终进入人工审批；
所有 Agent 行为有 Trace、制品、Diff、测试和审计证据；
用真实失败持续改进测试、Skill、AGENTS.md 和策略。

对大多数企业来说，QA 达到 Level 3～4，Prod 达到“自动执行 + 人工或策略放行”，已经能获得巨大的效率提升，而不需要拿生产安全做实验。

结语：真正被颠覆的是工程组织，而不只是 IDE

GPT-5.6 Sol 最让我震撼的地方，不是它能一次生成多少代码，而是它开始具备把一次模糊对话持续推进到可运行、可测试、可部署结果的能力。

从 5.4、5.5 到 5.6 Sol，真正的代际变化是：规划、拆解、文档、并行委派和验证，正在从必须由外部 Skill 逐步强制的流程，变成模型与 Agent Runtime 更自然的工作方式；而 Chrome、Computer Use 和 SSH 又让这套能力越过代码仓库，触达真实的软件运行环境。

但是，企业级全 AI 软件工程的核心从来不是“相信模型”。

它的核心是：

把业务语言说清楚；
把工程规范写清楚；
把外部能力通过 MCP 安全暴露；
把优秀方法做成 Skill；
把验收条件变成可执行测试；
把部署变成不可变、可审计的 Pipeline；
把不可接受风险固化成 Agent 无法自行绕过的门禁。

当这些条件成立后，一个资深 .NET 工程师不再只是某个模块的主要编码者，而可以成为一支 AI 工程团队的架构师、教练和治理者。

未来最有竞争力的工程师，未必是每天手写代码最多的人，而是最擅长把业务目标、领域知识、工程纪律和反馈环，配置成 Agent 能够持续执行的人。

这才是 GPT-5.6 Sol 对软件工程真正具有颠覆性的地方。