最近面了一家头部金融交易平台的 Flutter 高级工程师岗位。
这场面试最让我印象深刻的，不是 Dart 线程模型、Widget 重建优化、混合栈、FFI，也不是某道底层原理题答得好不好。
而是面试过半时，面试官突然问了一个问题：
你日常开发中怎么用 AI 提效？如果团队落地 AI 协同开发，你会怎么保证代码质量和风格统一？
我当时愣了一下。
不是因为这个问题难，而是因为我意识到：
AI 协同开发，已经从简历上的加分项，变成了高级工程师面试里的正式考察点。
面试官并不是在问“你会不会用 Copilot / Cursor / Claude”，而是在问：
你能不能把 AI 纳入真实团队工程体系，并控制它带来的质量风险？
这个问题，比某个具体技术点更值得琢磨。
为什么是先问这个？
细想下来，其实很合理。
交易平台的移动端团队有两个特点：
- 节奏快，人效要求高
- 场景重，质量红线硬
这两个特点，天然会推动团队更早关注 AI 协同开发。
1. 小团队快节奏，AI 是生产力工具
交易平台移动端团队通常不会特别大，但业务线非常多。
行情、交易、钱包、活动、KYC、合规、风控、推送、资产展示，经常多线并行，还要保障 7 x 24 小时线上可用性。
一个高级 Flutter 工程师，往往不是只写几个页面，而是要扛住一个完整模块：
- 需求评审
- 技术方案
- 页面开发
- 接口联调
- 异常兜底
- 性能优化
- 上线验证
- 线上问题排查
在这种团队里，AI 不是“尝鲜工具”，而是很现实的效率工具。
适合交给 AI 的事情很多：
- UI 组件初稿
- 表单校验
- DTO / Entity 转换
- 工具类函数
- 单元测试样例
- 接口对接模板
- 文档和注释初稿
人应该把精力放在更难替代的部分：
- 架构边界
- 性能瓶颈
- 安全校验
- 业务规则
- 金融精度
- 异常兜底
- 线上稳定性
说白了：
AI 做确定性执行，人做风险判断。
2. 金融场景不能只看“能不能跑”
交易平台和普通 ToC 产品不一样。
很多链路都和用户资产直接相关。
一次金额精度丢失、一个边界条件漏判、一个错误的状态刷新，都可能造成真实损失。
所以面试官问 AI，真正关注的不是：
AI 能不能帮你写代码？
而是：
AI 写出来的代码，谁审核？按什么标准审核？怎么进入现有工程规范？怎么避免引入安全隐患？
这说明一些团队已经走过了“AI 好不好用”的试探阶段，开始进入“AI 怎么工程化落地”的实战阶段。
面试官真正考察的是什么？
很多开发者对 AI 协同的理解，还停留在：
让 AI 帮我写个函数、生成个页面、补个单测。
这当然有用。
但高级岗面试里，这还不够。
这类问题真正考察的是三个能力。
1. 你把 AI 当代码生成器，还是协作伙伴？
最基础的用法是：
提需求 -> 粘代码 -> 跑通 -> 提交
这种用法，本质上还是把 AI 当成高级代码片段搜索引擎。
更合理的方式，是按风险等级分配任务。
低风险、强确定性任务：交给 AI 直接生成
- UI 初稿
- 普通表单
- DTO 转换
- Mock 数据
- 单测样例
中风险业务模块：AI 出初稿，人负责边界
- 页面状态
- 网络请求
- 错误处理
- 空数据和弱网兜底
- 业务流程串联
高风险核心链路：人主导，AI 辅助
- 交易链路
- 金额计算
- 安全校验
- Token / 签名逻辑
- 风控规则
- 性能瓶颈
我更愿意把 AI 看成一个：
执行力极强，但缺乏边界意识的初级工程师。
你的价值不是“让它写更多代码”，而是知道怎么拆任务、怎么设约束、怎么验收结果。
2. 你有没有 AI 时代的工程规范意识？
AI 写代码最大的问题，从来不是写不出来。
而是写出来之后：
- 风格不统一
- 分层不一致
- 命名漂移
- 异常处理随意
- 重复代码增加
- 隐性 Bug 变多
- 安全边界被忽略
如果团队里每个人都按自己的习惯问 AI，代码库很快就会变成风格混杂的拼接产物。
这也是面试官关心“怎么保证代码质量与风格统一”的原因。
我的做法是：给 AI 前置一套编码规范说明书。
至少要约束这些内容：
- 目录结构
- 命名规则
- 分层边界
- 状态管理方式
- 错误处理标准
- 日志和注释规范
- 单元测试要求
- 禁止项，比如硬编码密钥、重复模型、临时代码
这和新人入职培训很像。
区别是，这个“新人”执行力很强，但规则意识很弱。
越强大的工具，越需要清晰的规则把它框在可控范围内。
但光有规范还不够。
这里有一个面试官大概率不会明说、但会在心里默默打分的视角：技术债务的加速度。
AI 生成代码的速度，可能会让技术债务的累积速度从“走路”变成“高铁”。
一个高级工程师手写 100 行代码，通常会自然思考扩展性、边界和未来演进。但 AI 生成代码时，只会优先满足当前 Prompt。它不会主动关心三个月后这个模块要不要扩展，半年后这个抽象是否还成立。
所以规范的下一步，是给 AI 代码设计“退役策略”。
一个可落地做法是：给 AI 生成的类或方法增加标记，并附带生成时的 Prompt 摘要。
/// @AIGenerated
/// Prompt: 生成行情列表 item 的展示组件，包含涨跌幅颜色、价格、成交量展示。
/// Review: 仅允许 UI 展示逻辑，不允许包含行情计算和接口请求。
class MarketTickerItem extends StatelessWidget {
// ...
}
这不是为了甩锅，而是为了让后续接手的人知道：
这段代码最初是 AI 根据当时需求翻译出来的，不一定是深思熟虑后的长期抽象。
当模块半年后需要重构时，开发者才敢大胆重写，而不是被 AI 生成代码的结构绑架。
另一个重要原则是：
AI 生成的代码，必须尽量可被轻易删除。
Review 时要特别留意 AI 产生的非必要耦合。
比如 AI 为了快速完成功能，让 A 页面直接调用 B 页面内部 Provider。这种耦合在人手写时通常会下意识规避，但 AI 为了“跑通功能”经常这么干。一旦横向依赖产生，后续重构成本会成倍放大。
3. 你能不能画清 AI 和人的边界？
Flutter 开发里，AI 很适合做这些事：
- 普通页面
- 常规组件
- 表单校验
- JSON 解析模板
- 工具函数
- 单元测试
- 文档初稿
但这些事情不能直接交给 AI：
- 渲染性能优化
- 内存泄漏排查
- 原生混合栈架构
- 金融金额精度
- 资产安全逻辑
- 私钥、Token、签名链路
- 交易确认和风控边界
- 线上故障定位与灰度止损
尤其是交易场景。
涉及资产、订单、风控、安全的核心代码，就算是人写的，也要多重 Review 和测试验证。
能不能画清这条边界，才是判断工程师成熟度的关键。
这里还可以再往前走一步：AI 代码也要纳入可观测体系。
既然团队允许 AI 生成代码并合入主干，那线上监控最好多一个维度：
- 某个模块 Crash 率升高，是否和 AI 生成代码有关？
- 某次 ANR 增加，是人工重构引入，还是 AI 生成逻辑造成？
- AI 生成代码占比高的模块，缺陷密度是否更高？
换句话说，可以把 AI 生成代码当作一个特殊的“提交来源”来观测。
这才是从“用了 AI”到“管住 AI”的工程化闭环。
工程师能力模型正在变化
前两年大家还在争论：
AI 会不会取代程序员？
现在看，答案越来越清楚：
AI 不会直接取代程序员，但会使用 AI 的工程师，会逐步拉开和不会使用 AI 的工程师之间的差距。
更准确地说，工程师的核心价值权重正在变化。
过去更看重：
- 代码熟练度
- API 记忆量
- 手写代码速度
- 对框架用法的熟悉程度
现在更看重：
- 问题拆解能力
- 架构设计能力
- 质量把控能力
- AI 产出校验能力
- 业务边界判断能力
- 线上风险治理能力
就像 IDE 自动补全没有淘汰程序员，只是让“背 API 名称”不再是核心能力一样。
AI 代码生成也不会淘汰程序员，但会让“逐行手写重复业务代码”的价值持续下降。
对 Flutter 开发者来说，这个变化会更明显。
因为 Flutter UI 层标准化程度很高，组件化也成熟。很多页面、表单、列表、状态展示，AI 生成初稿的准确率已经很高。
如果一个 Flutter 开发者的核心价值还停留在：
- 会写 UI
- 会调接口
- 会拼页面
- 会处理普通状态
那很容易被 AI 拉平差距。
真正能拉开差距的，是更靠后的能力：
- 复杂架构设计
- 性能体验优化
- 工程规范治理
- 多端与原生混合
- 线上稳定性建设
- 金融 / 交易 / 出海等复杂业务理解
一个 Flutter 里很容易被忽视的坑
在落地 AI 规范时，我发现一个 Flutter 项目里非常高频的问题：
AI 很容易侵入 UI 层边界。
比如你让它生成一个行情列表页，它很可能会在 ListView.builder 的 itemBuilder 里直接写业务判断：
itemBuilder: (context, index) {
final item = orderBooks[index];
if (item.depth > 100 && item.priceChange > 0) {
// 直接在 UI 层写业务规则
}
return MarketItem(item: item);
}
你第一次告诉它“UI 层只负责渲染，业务逻辑下沉到 Controller”，它可能会照做。
但只要后续对话里你说“再加个小功能”，它为了省事，又会顺手把逻辑塞回 UI 里。
我的做法是，在 Prompt 模板里不要只写抽象原则，而是写成强约束规则：
任何包含 if / for / map / where 的业务逻辑，严禁出现在 build 方法及其子 Widget 中。
如需业务判断，必须先创建 UseCase / Controller / ViewModel 方法，再由 UI 层消费结果。
这种“物理规则”式的禁令，比只写“请遵守分层原则”更有效。
AI 不怕抽象原则不优雅，它怕的是验收条件不明确。
给移动端开发者的三个建议
面试官有句话我很认同：
我们不招只会用 AI 的人，也不招完全不用 AI 的人。我们要的是知道什么时候用、怎么用、哪里绝对不能用的人。
结合自己的实践，我给移动端开发者三个建议。
1. 不抵触，也不神化
不要焦虑 AI 抢饭碗，也不要觉得有了 AI 就不用深耕技术。
AI 是效率放大器。
基础越扎实的人，用它提效越明显；基础越薄弱的人，越容易被它带偏。
如果连 Dart 异步模型、Flutter 渲染机制、状态管理边界、内存和性能问题都没搞懂，就完全依赖 AI 写代码，最后只会把自己的技术判断力耗空。
2. 建立自己的 AI 工作流规范
不要零散地“随手问两句”。
建议沉淀自己的工作流：
- Prompt 模板
- 编码规范说明
- 代码 Review 清单
- 单元测试要求
- 高风险代码禁用规则
- AI 产出验收标准
- AI 生成代码的标记与追踪机制
同样是用 AI，有没有统一规范，产出质量和效率会差很多。
3. 把精力投向 AI 做不好的地方
AI 很适合加速实现，但不擅长承担最终责任。
移动端开发者应该把更多精力投向：
- 架构设计
- 性能优化
- 安全治理
- 业务理解
- 系统设计
- 线上稳定性
- 工程规范建设
AI 可以帮你更快地实现想法。
但决定“做什么、怎么做才对、出了问题谁负责”的，永远是人。
最后
这次面试给我的最大感受是：
真正的分水岭，从来不是“用不用 AI”，而是：
你有没有完成从“写代码的人”到“管控代码质量与工程方向的人”的转变。
行业变化从来不会提前打招呼。
它只会悄悄出现在面试题里。
等你反应过来的时候，新的能力标准，往往已经落地了。
你最近面试遇到过 AI 相关的问题吗？欢迎评论区聊聊。
