Appearance
AI 辅助读懂 C# 项目：从项目地图到 Read-Only Trace
“读懂项目”有两种完全不同的任务：第一次接手一个陌生系统，需要建立必要的项目地图；日常开发里只是问“这个按钮最后调用了什么”“阈值在哪里判断”，则应该使用 Read-Only Trace。后者不需要每次重新理解整个 solution。
1. 先判断你现在要读多深
| 目标 | 推荐方式 |
|---|---|
| 第一次接手陌生项目 | 建最小项目地图 |
| 查一个按钮/值/状态怎么工作 | Read-Only Trace |
| 准备修改明确功能 | Trace → Fast/Execution |
| 跨模块新功能/重构 | 扩大到局部架构地图 |
| “以前正常，现在异常” | Temporal Regression，不先画全项目地图 |
2. Read-Only Trace：只是查现状时，不启动开发流程
适合问题：
- 停机窗口电流是单帧还是连续判断？
- 这个阈值从哪个配置读取？
- 点击“应用设备”最终会不会启动输出？
- 这个日志里的值来自哪里？
- 当前示波器是
SING还是RUN？
推荐流程：
text
精确搜索目标词/成员
→ 找 owner
→ 看 direct caller / callee
→ 追到最终状态/设备/数据落点
→ 给证据结论
→ END默认不做：
- 不创建修改任务；
- 不跑 build/test；
- 不写 change record；
- 不加载额外 UI/架构/文档 Skill；
- 不因为“顺便看看”扫描全仓库。
Prompt
text
$host-computer-dev
只分析当前实现，不修改代码。
我想确认：【问题】
请只追踪最短调用链，给出：
1. 当前行为；
2. 关键文件/成员；
3. 最终数据或设备落点；
4. 结论依据。
不要构建、测试或写修改计划。3. 第一次接手陌生项目：建立最小项目地图
只需要先回答：
text
Solution / 启动项目在哪里？
UI 入口在哪里？
业务/Application 层在哪里？
设备/通信在哪里？
数据/配置/日志在哪里？
测试在哪里？不要一开始要求 AI 把几百个文件逐个总结。
WPF 重点
App.xaml/ 启动注册；- 主窗口与主要 Views；
- ViewModels / Commands；
- Services / Application；
- 设备与通信适配；
- 配置、日志、存储；
- tests。
WinForms 重点
Program.cs；- 主窗体和重要子窗体；
- Designer 与事件；
- 通信/设备类；
- Timer / Thread / Task；
- 数据保存和日志。
4. Context Budget：找到边界就停止扩搜
一个具体任务默认最多围绕几类证据：
text
目标文件
直接 owner
调用方/被调用方
最终 sink
必要配置/测试如果这些已经能解释行为，就停止。
只有遇到下面情况才扩大：
- 行为跨多个模块；
- owner 不明确；
- 状态被多处修改；
- 配置与代码冲突；
- 证据不足以回答；
- 需要做架构设计。
5. “按调用链读”比“按目录读”更有价值
不要问：
解释这个项目。
改成：
从
StartTestCommand开始，追到设备实际发送命令的路径。
不要问：
这个类是干嘛的？
改成：
SerialService对外提供哪些稳定能力，当前目标功能通过哪些调用点使用它？
不要问：
数据怎么保存？
改成：
从采集 callback 开始，追踪原始数据、工程值和最终 CSV/数据库的路径。
6. 事实和推测必须分开
推荐结论结构：
text
Confirmed:
- 当前代码明确显示……
Inferred:
- 从调用关系推断……
Unknown:
- 仅靠当前代码无法确认设备端真实行为……尤其涉及协议、设备内部状态和现场配置时，代码不能证明一切。
7. 如果用户随后说“那就改成……”
Read-Only Trace 应直接升级到修改路线，不要重新从头分析。
text
Trace 已确认当前行为
→ 用户给目标行为
→ 判断 Fast / Execution / Discovery
→ 复用刚才证据例如：
text
问：现在是单次判断还是连续？
→ Trace：单次
用户：改成连续 5 次才报警
→ Execution / BehaviorPatch
→ 不重新画项目地图8. 回归问题要换成时间维度
用户说：
- “昨天还正常”；
- “这次改完后不一样”；
- “旧版本没有问题”；
不要继续只读当前调用链并猜“哪里看起来可疑”。改走：
text
known-good
→ changed files
→ relevant method/config diff
→ behavior delta详见 Bug / 回归定位。
9. 项目知识从哪里复用
| 信息 | 优先来源 |
|---|---|
| 稳定业务术语 | CONTEXT.md |
| 历史 Bug / 已知环境坑 | .agent-memory/ |
| 长期设计原因 | ADR |
| 当前代码事实 | 仓库 |
| 当前任务目标 | 当前对话 |
不要每次重新发现已经记录过的路径和环境事实。
10. 读懂任务的验收标准
Read-Only Trace
应该能回答：
- 当前行为是什么；
- 证据在哪；
- 谁拥有这个行为；
- 最终影响什么；
- 哪些还不能确认。
项目地图
应该能回答：
- 启动入口；
- 主要模块；
- 关键依赖；
- 设备/通信/数据边界；
- 修改某类功能应该从哪里开始读。
常见错误
| 错误 | 更好的做法 |
|---|---|
| 每个问题先读 5–10 个文件 | 具体问题用 Trace |
| 按文件名猜职责 | 看调用关系和实际 owner |
| 查现状还跑 build/test | Read-Only 结束即可 |
| 把推测写成确定事实 | 标注 Evidence |
| 用户已给目标后重新分析一遍 | 复用 Trace 直接进入 Execution |
| 近期回归只看当前代码 | known-good first |
下一步
一句话原则
第一次接手项目建立必要地图；日常问题只追当前目标的最短调用链。