用 .NET MAUI 10 + VS Copilot 从 0 开发一个签到 App
第 8 篇：复盘 —— Copilot 在 MAUI 项目中的真实边界
到这一篇，其实功能已经全部完成了。
这个签到 App 从第 3 篇开始，核心页面几乎都是：
Copilot 生成 → 直接运行 → 少量整理 → 上线使用
所以第 8 篇不再写新功能，而是做一次工程级复盘：
- Copilot 在 MAUI 项目中
- 到底哪里“真的省时间”
- 哪里“必须有人盯着”
这不是宣传文，而是基于前 7 篇真实代码的结论。
一、一个前提：这不是玩具 Demo
先明确一个前提条件。
这个项目不是：
- Hello World
- 只展示 UI
- 只写几行示例代码
它具备：
- 多租户模型
- 本地数据库（FreeSql）
- 登录 / 注册 / 管理
- 页面间真实导航
也就是说：
它已经超过了 Copilot“演示级示例”的复杂度。
在这个前提下谈 Copilot，结论才有意义。
二、Copilot 真正擅长的三类 MAUI 代码
1️⃣ CRUD / 管理型页面（最强项）
典型代表：
- 租户管理页
- 注册页
- 简单列表页
这些页面的共同特征：
- UI 结构固定
- 逻辑高度重复
- 业务规则简单
Copilot 在这里的表现是：
几乎可以 100% 交付
你只需要：
- 描述页面职责
- 提供模型类型
剩下的：
- XAML
- Code-behind
- 基本校验
都能一次生成并直接跑起来。
2️⃣ XAML 布局与数据绑定
在 MAUI 项目中，XAML 是一个非常适合 Copilot 的领域。
原因很简单：
- 语法强约束
- 模式高度固定
- 人工写容易疲劳
在本项目中：
- StackLayout / CollectionView
- Border / Label / Button
全部由 Copilot 生成，且：
- 可读性好
- 层级清晰
- 几乎不需要返工
XAML 是 Copilot 的“舒适区”。
3️⃣ Code-behind 事件逻辑
很多人下意识会觉得：
“Code-behind 不够高级”
但从 Copilot 的角度看：
- 事件 → 方法
- 页面 → 局部状态
这是一个极易预测的结构。
在签到、注册、管理这些页面中：
- 直接事件绑定
- 直接调用 FreeSql
反而比强行 MVVM 更稳定。
三、Copilot 的三个“危险区”
说完优点，必须说限制。
⚠️ 1️⃣ 生命周期与导航
Copilot 很容易在：
- OnAppearing
- PushAsync / PopAsync
- Modal / 非 Modal
这些地方给出“看起来对，但顺序微妙错误”的代码。
在你的工程里：
- 导航是否正确
- 是否会重复 Push
👉 一定要人工走一遍流程。
⚠️ 2️⃣ 数据一致性与边界条件
例如：
- 删除租户后，关联用户怎么办？
- 注册时并发创建同名租户？
- 登录态是否过期？
Copilot 通常会：
- 给出“理想路径”
- 忽略异常分支
这不是 Bug，而是模型能力边界。
⚠️ 3️⃣ 架构设计问题
如果你问 Copilot：
“这个项目架构合理吗？”
它通常会：
- 建议重构
- 引入更多抽象
- 上升复杂度
但在真实项目中：
过早架构，才是最大的风险。
这一点，必须由人来判断。
四、一个非常重要的结论
在这个 MAUI 项目中，我得到一个非常明确的结论：
Copilot 更像一个“初级但极其勤奋的同事”。
它的特点是：
- 写得快
- 覆盖面广
- 不会嫌你烦
但它不会：
- 为你承担架构后果
- 为你理解真实业务
所以最优用法不是：
“让 AI 写代码，我来检查”
而是：
“我决定方向，AI 填充实现”。
五、如果重来一次，我会怎么用 Copilot？
结合这 7 篇的经验，如果从零再来一次：
- 页面原型：100% Copilot
- CRUD 页面：100% Copilot
- 导航与状态：人工主导
- 架构演进：延后决策
一句话总结：
让 Copilot 做“体力活”，人做“判断题”。
六、写在最后
这个系列并不是想证明：
- “AI 能完全取代开发者”
而是想展示：
在合适的边界内，Copilot 已经可以显著改变 MAUI 的开发节奏。
如果你是：
- .NET / C# 开发者
- 正在观望 MAUI
- 对 Copilot 持怀疑态度
那么这个签到 App，希望能给你一个足够真实的参考样本。
到这里，这个系列就完整结束了。
