AI Coding 工程化进阶
AI Coding 的进阶能力不是“让模型多写代码”,而是把 prompt、上下文、工具、验证、代码审查和安全治理接成闭环。面试里要强调:AI 是加速器,工程师负责边界、判断和最终质量。
一、Prompt Engineering:把需求讲清楚
Prompt Engineering 关注单次任务如何描述清楚。好的 prompt 至少包含目标、上下文、约束、验收标准和禁止事项。
任务:为登录页 ViewModel 补充单元测试。
上下文:使用 Kotlin + Coroutines + Turbine,现有测试风格参考 LoginViewModelTest。
约束:只改测试文件,不改生产代码;覆盖成功、密码错误、网络异常。
验收:./gradlew testDebugUnitTest 通过;说明新增用例。
禁止:不要引入新依赖,不要重构 ViewModel。
常见技巧:
- 用“角色 + 任务 + 输入 + 输出格式 + 验证命令”减少歧义。
- 对大任务先让 AI 产出计划,再分步执行。
- 明确不可改文件、兼容版本、安全边界。
- 要求 AI 解释关键取舍,方便人工 review。
二、Context Engineering:让 AI 拿到正确上下文
Context Engineering 比 prompt 更重要。它解决“模型需要知道什么,不该知道什么,如何持续保持上下文准确”。
| 上下文类型 | 示例 | 作用 | 风险 |
|---|---|---|---|
| 代码上下文 | 相关类、测试、接口定义 | 避免编不存在 API | 上下文太多会稀释重点 |
| 项目规则 | AGENTS.md、架构约束、命名规范 | 避免破坏结构 | 规则过期会误导 |
| 历史决策 | ADR、issue、notepad、handoff | 继承非显然约束 | 记忆污染或重复记录 |
| 验证信息 | 测试命令、lint、构建结果 | 完成门禁 | 未实际运行会造成假通过 |
| 禁止范围 | 不改 README、不动依赖、不改生成物 | 控制 scope | 写得不清会范围膨胀 |
面试可说:我会先给 AI 最小但充分的相关文件,让它按现有模式改,完成后用测试、diff 和 review 校验,而不是让它凭记忆猜项目结构。
三、Agentic Coding 与工具调用
Agentic Coding 指 AI 不只是回答问题,还会读文件、搜索、编辑、运行测试、根据结果迭代。MCP(Model Context Protocol)和 tool calling 的价值是把外部系统能力以标准工具暴露给模型,例如代码仓库、浏览器、Figma、数据库、日志平台或移动设备。
典型闭环:
- 读取真实文件,确认现有模式。
- 制定小步计划和验收标准。
- 修改代码或测试。
- 调用构建、测试、lint、静态检查工具。
- 根据失败日志修复。
- 输出证据和剩余风险。
注意:工具调用提升能力,也放大风险。必须限制权限、敏感数据、可写目录和危险命令,并要求每次修改后有可复现验证。
四、AI Code Review 与防止结构性破坏
AI 生成代码常见问题不是语法错误,而是结构损伤:重复抽象、跨层调用、绕过既有架构、隐式全局状态、错误生命周期、测试只覆盖快乐路径。
AI Code Review 可以作为第一层筛查:
- spec review:是否满足需求,是否做了范围外功能。
- architecture review:是否符合分层、依赖方向和模块边界。
- security review:是否引入敏感日志、明文密钥、不安全网络或权限滥用。
- test review:是否覆盖边界、异常、并发和回归场景。
- maintainability review:命名、复杂度、重复、错误处理是否可维护。
防止 AI 结构 damage 的方法:
- 小 diff,一次只改一个明确目标。
- 先读现有实现和测试,禁止“重写式修复”。
- 让 AI 说明为什么改这些文件,并检查是否有更小改法。
- 用架构规则、lint、自定义检查和人工 review 双重门禁。
- 对核心模块要求先写失败测试,再实现。
五、AI Test Generation 与验证闭环
AI 很适合生成测试草稿、边界清单和 mock 数据,但测试有效性仍需人工确认。
Android 场景常见用法:
- ViewModel 状态机测试:输入 Intent,断言 State/Effect。
- Repository 测试:mock API/DAO,覆盖缓存、错误和重试。
- Coroutine/Flow 测试:使用
runTest、TestDispatcher、Turbine。 - UI 测试:生成 Espresso/Compose test 的骨架。
- 性能/稳定性:生成 Macrobenchmark 场景或 monkey 前置检查清单。
验证闭环必须包括:
AI 生成测试
→ 人工检查断言是否真的验证需求
→ 先确认测试能失败(避免无效测试)
→ 实现/修复代码
→ 运行测试 + lint/build
→ 记录命令和结果
易错点是 AI 可能写“只验证方法被调用”的弱测试,或者为了通过测试修改生产代码行为。工程上要优先验证用户可见行为和业务不变量。
六、AI 安全风险与治理
AI Coding 带来的安全风险包括代码风险、数据风险和供应链风险。
| 风险 | 例子 | 防护 |
|---|---|---|
| 敏感信息泄露 | 把 token、客户数据、日志上传给外部模型 | 脱敏、最小上下文、本地模型/企业网关 |
| 不安全代码 | 关闭证书校验、明文存储、宽权限 | 安全规则、SAST、人工安全 review |
| 依赖投毒 | 引入不存在或低信誉依赖 | 锁定依赖审批、SBOM、漏洞扫描 |
| 许可证风险 | 复制不明来源代码 | 代码来源审查、许可证扫描 |
| 过度自动化 | agent 自行改发布配置/密钥 | 权限隔离、只读默认、审批门禁 |
安全治理原则:不给 AI 不必要的秘密;不让 AI 绕过 review;不让 AI 单独决定安全策略;对生成代码使用和人工代码同等级别的审查、测试和审计。
七、移动开发工作流集成
在 Android 团队里,AI Coding 可以嵌入日常流程,但要和移动端特有验证结合。
- 需求阶段:让 AI 从 PRD 提取状态机、异常分支、埋点和权限影响。
- 开发阶段:生成 ViewModel、UseCase、Repository、Compose 预览、测试样例,但保持架构边界。
- 调试阶段:解释 crash stack、ANR trace、Perfetto 片段、Gradle 依赖冲突。
- 测试阶段:补充单元测试、UI 自动化、兼容性矩阵和回归清单。
- 发布阶段:检查隐私权限、混淆 keep、Baseline Profile、灰度开关和回滚预案。
- 安全阶段:辅助做敏感日志扫描、网络配置检查、权限最小化和依赖漏洞梳理。
移动端尤其要提醒 AI:生命周期、线程、协程取消、配置变更、低端机性能、Android 版本兼容、隐私合规和应用商店政策,这些是通用代码模型容易忽略的约束。
八、面试表达:从“会用 AI”到“能管 AI”
可以这样回答:
我会把 AI 放进工程闭环里:Prompt Engineering 负责把任务讲清楚,Context Engineering 负责给真实项目上下文,agentic coding 负责读写和运行验证,AI code review/test generation 提高覆盖率,最后由测试、lint、build、人工 review 和安全规则做 completion gate。我不把 AI 当成替代工程判断的工具,而是把它当成可审计、可回滚、受约束的协作者。
这类回答比“我用 AI 写页面很快”更高级,因为它体现了质量、验证、安全和团队协作意识。
高频面试题
Q1:Prompt Engineering 和 Context Engineering 有什么区别? Prompt Engineering 关注单次怎么问,让目标、约束和输出清楚;Context Engineering 关注给 AI 哪些真实项目上下文、规则、历史决策和验证信息,并控制上下文不过载或污染。
Q2:什么是 agentic coding? 它指 AI 能通过工具读文件、搜索、编辑、运行测试并根据结果迭代,而不是只生成文本。关键风险是权限和范围扩大,所以必须有工具权限、可写范围和验证门禁。
Q3:MCP / tool calling 对 AI Coding 的意义是什么? MCP 和 tool calling 把外部系统能力标准化地提供给模型,例如代码仓库、日志、浏览器、移动设备或设计系统。意义是让 AI 基于真实环境行动,但也需要权限控制、审计和敏感数据保护。
Q4:AI 生成测试靠谱吗? 可以作为草稿和边界补充,但不能盲信。要人工检查断言是否验证真实需求,最好先看到测试失败,再实现代码,最后运行测试、lint、build 形成证据。
Q5:如何防止 AI 破坏代码结构? 限制小 diff 和可改范围,要求先读现有模式,禁止重写式修复;用架构规则、review、测试和静态检查兜底;对核心模块先写失败测试,再让 AI 实现最小改动。
易错点 / 追问
- 不要把 AI Coding 讲成“模型替我负责”,责任仍在工程师和团队流程。
- 不要给 AI 过多无关上下文或敏感数据,Context Engineering 讲究最小充分。
- 不要接受未验证的 AI 输出,必须有测试、lint、build 或人工 review 证据。
- MCP/tool calling 不是越多越好,工具权限和审计比炫技更重要。
- AI 生成测试要防止弱断言和为了通过测试而改坏业务语义。