Skip to content

C# 现代 AI IDE 协作流程(V10)

内容类型:方法说明难度:进阶适合:需要让 Codex、Claude Code、Cursor 等 Agent 直接读取和修改 C# 项目的工程师阅读时间:约 10 分钟前置:有 C# 项目经验,知道 Git Diff 和基本构建方式

现代 AI IDE 能读取仓库、修改文件、运行命令。真正决定效率和可靠性的,不是“它能不能改代码”,而是任务类型有没有先分对、上下文有没有收窄、验证有没有匹配风险

V10 不再把“先读项目 → 先写 Plan → 再修改 → 全面验证”当成所有任务的固定流程。

1. 第一步不是写 Plan,而是 Intent Gate

text
用户请求

只是问当前代码怎么工作?
   ├─ 是 → Read-Only Trace → 回答 → 结束
   └─ 否

目标和业务边界是否已经明确?
   ├─ 明确且小 → Fast
   ├─ 明确但涉及行为/跨层 → Execution
   └─ 仍有业务决策未确定 → Discovery

这一步能避免两类常见浪费:

  • 明明只是问“这个阈值在哪里判断”,却启动构建、测试和任务计划;
  • 用户已经给了完整修改方案,Agent 又重新访谈和写一遍长 Plan。

2. 四种常见协作方式

方式适合任务Agent 主要动作
Read-Only Trace查当前行为、调用链、配置来源精确搜索、最短调用链、证据结论
Fast文案、样式、局部显示、小逻辑直接定位、最小 patch、V0/V1
ExecutionBehaviorPatch、回归修复、明确跨层功能Compact Brief、代码事实核对、最小实现
Discovery新项目、新主流程、业务语义不清Decision Tree / Frontier、需求 Delta

Read-Only Trace

text
$host-computer-dev
只分析当前实现,不修改代码。
我想确认【问题】。
请只追踪最短调用链,给出当前行为、关键位置和结论依据。
不要构建、测试或写修改计划。

Fast

text
$host-computer-dev
这是明确的小修改,请走 Fast。
目标:【填写】
不要做无关设计、重构或全量回归;按影响做 V0/V1。

Execution

目标和边界已经明确时,Agent 最多整理一个短 Compact Brief

text
Target:
ConfirmedConstraints:
NonGoals:
CodeFactsToVerify:
ExpectedChangeSurface:
VerificationLevel:
BlockingUnknowns: []

BlockingUnknowns 为空,就直接实施,不需要再生成一份完整 PRD。

Discovery

只有当不同选择会改变最终业务结果时才问用户。代码位置、当前默认值、项目结构这类事实应该由 Agent 自己查。

3. Execution 内部还要分语义

子类型识别信号核心规则
MicroPatch“改个文字/样式/局部显示”不扩范围
BehaviorPatch“连续 5 次才报警”“只报警不停机”Behavior Contract
RegressionFix“以前正常,昨天改后坏了”known-good first
ExperimentalChange“先临时放开限制做测试”优先可恢复 override

不要只按“改动文件多少”判断任务大小。一个 15 → 16 A 的修改可能是跨 UI、Domain、MES、DeviceApply 的正式业务约束;一个 50 行纯样式调整反而可能只是 V1。

4. Agent 读取项目时要有 Context Budget

默认搜索顺序:

text
已有项目记忆 / 明确路径
→ target file
→ direct owner / caller / callee
→ data sink / behavior boundary
→ 停止扩搜

找到 owner、主要调用链和最终落点后,不要继续为了“更完整”扫描整个 solution。

对于 Read-Only 问题,通常不需要建立完整项目地图。只有第一次接手陌生系统、准备做跨模块设计时,才值得扩大阅读范围。

5. Rules、Context、Memory、ADR 不要混在一个文件里

推荐分工:

内容放哪里
AI 每次都要遵守的工程红线Rules / 项目说明
稳定业务术语与概念关系CONTEXT.md
以前改过什么、踩过什么坑.agent-memory/
难逆、非显然、经过真实取舍的长期决策ADR
本次任务目标与边界当前对话 / task brief

Fast MicroPatch 默认不读取全部 Context、Memory 和 ADR。

6. 上位机项目的权限边界

Agent 可以自主进行:

  • 文件和 Git 只读分析;
  • 普通源码修改;
  • 静态检查;
  • 模拟、Fake、Replay;
  • 不触发真实设备的构建和 focused test。

下面动作要更严格:

  • 高压输出、运动机构、继电器、加热、气路等真实危险设备动作;
  • 修改联锁或安全停机语义;
  • 破坏性数据库操作;
  • 发布覆盖正式环境;
  • 无法撤销的现场配置。

真实设备动作是否允许执行,由人工明确授权;不能因为 Agent 能调用工具就默认可执行。

真实设备“只读查询”也需要确认不会改变状态、不会抢占现有 Session、不会清空关键诊断信息,并且现场允许当前查询。

7. 验证不是“每次都 dotnet test”

V10 使用 V0–V4:

等级典型任务默认验证
V0文案、静态资源Diff / static
V1XAML、普通局部代码affected build;有明确 focused test 才跑
V2设备、通信、MES、存储、共享约束affected build + focused fake/replay/test
V3状态机、联锁、并发、告警后果focused tests + WorkflowSmoke
V4发布、公共协议/Schema、大范围重构full checkpoint

重要纪律:

  • 0 个测试匹配不等于 Verified
  • E-SafeNet、权限、SDK、构建环境导致验证无法运行 → EnvironmentBlocked
  • 需要真实设备/HITL 但尚未执行 → HardwarePending
  • 当前证据不足但也不是环境/硬件阻断 → Unverified
  • 同一代码指纹已经证明是环境问题时,不要反复撞同一个失败路径;
  • Fake/Replay 通过不能写成现场设备已通过。

统一状态:

text
Verified
Unverified
EnvironmentBlocked
HardwarePending

8. 回归任务优先比较时间差异

用户出现下面描述时:

  • 以前正常;
  • 昨天修改后变了;
  • 新版本才出现;
  • 和旧目录结果不一样;

自动进入 Temporal Regression:

text
known-good
→ changed files
→ relevant method/config/protocol diff
→ behavior delta
→ 根因假设

“当前代码看起来不合理”不能单独证明它是本次回归原因。

如果只是回退到旧版本后恢复正常,记录 RolledBackToKnownGood;只有 causal behavior delta 已定位、修复并通过同一故障信号验证后,才写 RegressionFixed

9. 现代 AI IDE 最稳的输出是什么

不是一份越来越长的聊天记录,而是几个可审查对象:

text
任务边界
Git Diff
VerificationLevel
VerificationState
证据 / EvidenceGrade(需要时)
残余风险
必要的项目记忆/ADR

开发者最重要的人工工作仍然是:确认业务决策、审查 Diff、批准危险动作、连接真实设备验收。

10. 常见反模式

反模式后果V10 做法
每个任务都先完整 Plan小改变慢Fast / Compact Brief
AI 已经能查到的事实仍问用户反复确认Agent 先取证
把整个仓库塞进上下文重点被淹没Context Budget
改一行也跑全量单测时间浪费V0–V4
回归先分析“当前代码为什么怪”容易误判旧行为known-good first
临时测试直接改正式规则测完还要返工ExperimentalChange
构建/测试命令失败就说代码失败环境与代码混淆VerificationState
Fake/Replay 通过就写真机已验收证据等级被夸大HardwarePending

11. 和 Skill 配合

host-computer-dev V10 就是把上面这些规则固化给 Agent。长期做 C# 上位机项目时,推荐显式调用统一入口:

text
$host-computer-dev
【任务描述】

不需要用户自己决定每次应该叫哪个专家;只有明确想单独调用某个专家能力时才使用 00–15 独立 Skill。

相关页面:

一句话原则

现代 AI IDE 的效率不是让 Agent 少思考,而是让它只在真正需要决策、风险和验证的地方投入更多思考。

别来无恙 · C# 上位机 AI 实战站 · 从零到交付 · QQ 群:1016188499