外观
Q21–Q24：资深研发、工程化与协作
这组用于把十余年研发经验与 AI 应用岗位连起来。重点是设计边界、交付责任和证据，不必把每个旧项目重新包装成 AI 项目。
Q21 你的跨端经验怎样帮助 AI 应用架构？
**考察目的：**复用边界、组件抽象与复杂度控制。**难度：**资深核心。
**主问题：**从 Flutter/Web 和题型建模中，你能迁移哪些能力到教材系统？
直接答案与 STAR
可迁移的是区分稳定流程与变化点的能力。题型系统可以把通用作答生命周期与不同题型行为分开；多城市产品可以复用业务逻辑、通过配置管理差异。教材系统同样可以把任务、版本、校验和审计保持稳定，把模型/素材供应商及地区规则作为明确扩展点。
但不能把所有差异塞进一个庞大配置或基类。先识别真实复用需求，保留少量清晰接口，并通过契约测试约束实现。跨端 UI 与模型适配并非完全相同的问题，迁移的是设计方法，而不是直接复制旧架构。
**STAR｜简历事实：**S：智慧考试存在多学科题型和复杂互动题录入。T：我负责考生端与题库端架构及互动题开发。A：采用策略模式和模板方法分离通用作答流程与题型差异。R：支持题目模板扩展与复杂互动题录入；没有依据时不补写开发效率提升百分比。
第一层追问：策略模式和模板方法有什么区别？
**直接答案：**策略模式通常通过组合替换某个行为；模板方法在共同流程骨架中让特定步骤由子类或实现方提供。二者可以一起用，也有继承层次与接口复杂度的代价。面试要用真实变化点解释，而不是只背定义。
**STAR｜简历事实 + 假设映射：**S：题型共享提交和结果处理，但答案交互不同。T：减少通用逻辑与题型差异互相污染。A：简历记载用两类模式分离流程；在教材复现中可用供应商接口承担可替换行为。R：结果是能独立扩展差异点，具体代码规模和收益需以原项目记录为准。
第二层追问：为什么不是所有业务逻辑都跨端共享？
**直接答案：**平台生命周期、原生能力、性能和交互约束不同。应共享稳定的领域模型与业务规则，给平台能力留适配层；高性能渲染或特定设备接口可能保留原生实现。强行共享会让抽象充满条件分支，最终更难维护。
**STAR｜简历事实：**S：魔题库需要跨端改造并保留复杂题目展示。T：在改造期间兼顾已有能力。A：简历记载原生与 Flutter 混合架构、基础组件库，以及原生 Texture 和 DTCoreText 相关封装。R：支持模块独立开发和复杂题目渲染；不把混合架构描述为所有页面一次性完全重写。
分支追问：配置化 20 余个小程序，会有什么风险？
**直接答案：**配置组合可能产生不受控变体，公共改动容易影响多个城市。应区分受支持配置、构建产物身份和差异测试矩阵；关键业务要有共同契约及代表性变体测试。配置不是免测试的代码替代品。
**STAR｜简历事实 + 假设改进：**S：蓝睿时期存在多城市乘车二维码产品。T：复用逻辑并管理城市差异。A：简历记载 Taro 与动态编译支持一套代码维护 20 余个小程序；关于测试矩阵的详细做法需核对原记录。R：历史结果可说支持这批产品开发维护；配置测试方案作为当前设计建议讲述。
**优秀回答：**给出变化点、接口和不适合复用的边界，能连接旧经验与新系统。**常见误区：**组件化就是把文件拆小；配置越多越灵活；跨端必须 100% 共享代码。
关联学习：跨端与 Web 扩展、角色与模块边界、工具接口。
**实际源码：**迁移对照：system/app/tools.py::ToolSession.execute()、system/app/media.py::external_bytes()；它们示范受控接口与供应商适配，非原 Flutter/Web/题型源码。
验证与实验：system/tests/test_adapters.py::test_image_and_tts_contract（协议契约对照）；为新增 TTS 适配列出受影响字段和不应修改的流程，不将本用例当成跨端组件测试。
Q22 如何测试 AI 系统，并接入 CI 和发布？
**考察目的：**确定性测试、模型评测、交付门槛。**难度：**资深核心。
**主问题：**模型输出不确定，自动化测试是不是就没用了？
直接答案与 STAR
恰恰需要分层。Schema、工具权限、状态转移、版本、幂等和失败恢复都可以做确定性测试；适配器可以使用受控响应或契约测试验证请求与错误分类；真实模型质量需要固定评测集、人工准则和统计观察。不要把“生成文字完全相同”当所有测试的断言。
CI 应先运行便宜稳定的检查、构建与离线测试，真实服务测试可以单独触发并限制凭据和预算。发布包含数据库迁移、镜像/依赖版本、配置与回滚策略。VitePress 是独立静态构建，不能把教材 API 密钥打进网站产物。所有报告区分已跑、跳过和未验证。
**STAR｜简历事实 + 学习复现：**S：优食客有两个 iOS App 与公共组件。T：支持模块复用和版本发布。A：简历记载 CocoaPods 私有库和 Jenkins 自动化构建。R：可以说配置了持续集成支持发布；本包的 AI 测试或 GitHub Actions 属于本次实践，不能直接算作该历史项目成果。
第一层追问：哪些测试最值得优先写？
**直接答案：**优先覆盖高影响不变量与历史故障边界：未审核不能交付、越权工具不能执行、旧版本不能覆盖新版本、重复请求不重复产生业务效果、异常不会无限重试。相比逐行镜像实现的测试，这些用例更能防止真实回归。
**STAR｜学习复现：**S：时间有限但系统包含多个恢复分支。T：优先保证关键业务边界。A：把用户验收场景转为可执行断言，尤其测试失败和重复路径。R：证据来自通过的用例及其检查对象，不用“测试数量多”代表质量。
第二层追问：改了 Prompt，为什么也要走版本和回归？
**直接答案：**Prompt 会改变系统行为，相当于配置或程序的一部分。应记录模板版本、模型、参数和规则快照，用固定样本比较错误类型、质量与成本。回归失败可回到旧模板，但在途任务应保留自己的配置快照，避免一次运行中途切换语义。
**STAR｜假设方案：**S：为了让语言更自然调整生成提示词。T：避免因此丢失地区约束或引用。A：版本化提示词并跑代表性样本，保留新旧结果与配置。R：发现退化则暂停发布，不能只凭一篇文风更好就上线。
分支追问：数据库迁移失败，回滚镜像就够了吗？
**直接答案：**不够。代码回滚不自动还原数据和 Schema。需要评估迁移是否向后兼容、是否有数据丢失风险，以及备份、验证与恢复流程。优先使用可分阶段兼容变更；破坏性迁移要单独处理，不能在容器启动时无条件反复执行。
**STAR｜假设方案：**S：新增字段并改变版本记录结构。T：确保发布失败后可恢复服务。A：先实施兼容迁移、校验数据，再切换代码；准备可验证的恢复方案。R：回滚路径包含数据库状态，不能只报告镜像启动成功。
**优秀回答：**分清单测、集成、契约与模型评测，知道跳过测试不能算通过。**常见误区：**AI 只能人工测试；用同一模型评分就足够；CI 绿灯证明生产质量；镜像回滚等于系统回滚。
实际源码：system/app/db.py::migrate()、system/app/providers.py::run_model()；system/tests/conftest.py 的独立数据库夹具；Docker 与 CI 文件以包内实际配置为准。
验证与实验：system/tests/test_system.py::test_clean_migration_and_pgvector、test_killed_worker_resumes_after_generation；system/tests/test_adapters.py::test_no_credentials_never_falls_back。测试定义存在不等于已执行，执行状态见验收报告。
Q23 开源项目除了 Stars，还能证明什么能力？
**考察目的：**API 设计、兼容性、维护与外部反馈。**难度：**中高。
**主问题：**以 EasyLoading 或模板插件为例，你如何说明自己的技术贡献？
直接答案与 STAR
Stars 是关注信号，不直接等于用户数、代码质量或个人贡献。更有说服力的是说明具体使用场景、API 为什么这样设计、有哪些兼容性取舍、如何处理 issue 和版本演进，并展示自己提交的代码、文档或发布记录。
组件应把简单使用路径做清楚，同时为生命周期、并发调用、样式覆盖和错误情况保留一致行为。模板代码生成工具则要解释生成什么、减少哪类重复输入、如何适配项目约定以及怎样避免模板过时。这些内容比罗列数字更能体现工程能力。
**STAR｜简历事实：**S：Flutter 应用需要通用 Loading/Toast 能力，开发中也有模板代码需求。T：建设可复用组件与研发工具。A：简历列出 Flutter EasyLoading、Gitter、weapp-poem 和 fish-redux-template；后者被 fish-redux 官方 Plugins 收录。R：简历记录开源项目累计约 5.5k Stars，此处仅按简历口径，未将它视为当前在线统计或用户规模。
第一层追问：一个全局 Loading 组件，最难的边界是什么？
**直接答案：**要结合真实实现回答。可讨论并发请求争用显示/关闭、路由切换、组件卸载、动画与触摸遮挡等问题；但不能声称原组件实现了所有策略。关键是明确 API 的所有权与生命周期：谁有权结束哪一次展示，失败时如何清理。
**STAR｜假设方案：**S：两个异步请求共用全局 Loading，较快请求先调用关闭。T：避免较慢请求仍执行时提示消失。A：评估引用计数、句柄或由业务统一控制的方案，并说明 API 复杂度。R：通过并发用例验证选定语义，不把示例设计算作原开源项目既有实现。
第二层追问：破坏性 API 变更如何推进？
**直接答案：**先确认收益值得兼容成本，给出迁移指南、版本说明与受支持边界；可能先弃用旧接口并提供过渡层。需要验证常见使用方式，不能只保证自己的 Demo 正常。真正是否遵循某种版本策略，应以仓库记录为证据。
**STAR｜假设方案：**S：旧 API 无法安全表达并发展示。T：改进语义又减少迁移阻力。A：设计新接口、编写对照示例和兼容测试，明确弃用窗口。R：用户知道何时、为什么、怎样迁移；没有发布证据不声称已经完成迁移。
分支追问：如果面试官要求证明是你做的呢？
**直接答案：**打开公开仓库的提交、发布、文档与 issue 讨论，说明本人负责的部分和外部贡献。按能核对的范围回答，避免把整个社区成果归于自己。敏感公司代码不应为证明能力而随意展示。
**STAR｜简历事实 + 准备任务：**S：简历列出多个公开项目。T：让贡献可核实。A：面试前选择两个能解释的提交与一个 API 设计取舍，准备公开链接。R：以这些公开记录支撑贡献范围；具体链接和故事由本人核对后使用。
**优秀回答：**能从使用者视角解释 API 与维护取舍，清楚贡献边界。**常见误区：**Stars 等于日活；下载量等于独立用户；把社区全部工作归给自己。
**实际源码：**接口阅读练习：system/app/tools.py 的 ToolSession.specifications()、ToolSession.execute()；system/app/schemas.py::AssetArgs；本包不包含 EasyLoading 等历史开源源码。
**验证与实验：**机制对照 system/tests/test_system.py::test_context_and_tool_permissions：理解契约及负向测试。另在本人公开仓库选择真实提交解释生命周期和兼容性，不能用本测试证明历史组件行为。
Q24 AI 帮你写代码，如何体现你的研发能力与责任？
**考察目的：**技术判断、验证能力和真实贡献表达。**难度：**资深核心。
**主问题：**如果大量代码由 AI 辅助生成，你真正负责什么？
直接答案与 STAR
研发责任不只等于手动输入代码。需要本人确定问题和范围、选择架构、定义数据与权限边界、拆解任务、审查实现、设计有意义的验证并对交付结果负责。AI 可以提出候选方案、生成代码和测试，但不能用“它写的”解释自己不理解关键路径，也不能把未执行测试当证据。
讲述时说明哪些地方自己做了判断，哪些由工具协助，如何发现并修正问题。对当前系统，应能亲自解释检索过滤、局部修订、工具分发、租约和旧结果隔离，并现场修改一个约束验证效果。真实贡献比夸大“完全独立”更有说服力。
**STAR｜学习复现：**S：为了补齐 Agent 原理与实现理解，建设这套学习系统。T：达到能运行、修改、排障并讲清楚的程度。A：从需求覆盖矩阵出发，把代码、实验和问题一一对应，使用 AI 辅助开发后逐项核验。R：只能用本人实际完成的讲解和实验作为掌握证据；拿到压缩包或看到测试结果不等于已经理解。
第一层追问：AI 给出一个看起来正确的恢复实现，你怎么审？
**直接答案：**追问失败窗口：领取任务后崩溃、外部执行后未写回、租约过期旧进程返回、内容更新后迟到结果。检查数据唯一约束、事务边界与条件提交，再通过故障注入验证。代码能跑通正常路径不能证明恢复正确。
**STAR｜学习复现：**S：AI 生成了带重试循环的 worker。T：确认它不会重复覆盖或无限重试。A：手工推演提交前后状态，再运行针对崩溃窗口的测试。R：以观察到的数据库/文件状态判断实现，而不是接受模型自述“已实现幂等”。
第二层追问：遇到自己不会的技术，怎么推进而不失控？
**直接答案：**先缩小问题，读官方文档与当前版本示例，建立最小可复现实验，再带入系统；记录假设与未验证边界。关键机制应自己解释清楚，必要时请有经验的人评审。不能一口气引入多个不理解的框架后只靠报错驱动开发。
**STAR｜当前学习目标：**S：已有全栈与交付经验，但 Agent 技术缺乏系统理解。T：建立可验证的学习路径。A：按模型调用、检索、图状态、恢复、素材依赖逐步增加复杂度。R：阶段通过标准是能解释和修改对应机制，不是读完资料或记住名词。
分支追问：团队成员坚持另一种方案，你怎样处理？
**直接答案：**先确认共同目标和约束，再把争论转成可验证比较：需要解决什么问题、失败后怎样恢复、运维成本如何、有哪些证据。小范围验证有用，但也要设时间边界；决策后记录理由和复查条件。没有真实事件时应使用假设场景，不编造团队冲突故事。
**STAR｜假设方案：**S：一方建议立刻引入复杂队列，另一方希望先用数据库任务表。T：选择符合当前规模的实现。A：比较吞吐、恢复、维护成本和人员经验，先验证实际瓶颈。R：形成明确选择与迁移触发条件，而不是靠职级或框架热度决策。
**优秀回答：**能展示自己的判断与验证过程，承认不会的边界并给出学习方式。**常见误区：**把 AI 使用率当能力指标；任何结果都归功于自己；用“我能调 prompt”替代工程责任。
实际源码：system/app/graph.py::run_workflow()、system/app/tools.py::ToolSession.execute()、system/app/worker.py 的 recover_expired()、run_once()。
验证与实验：system/tests/test_system.py::test_killed_worker_resumes_after_generation、test_expired_lease_and_fencing、test_patch_cannot_change_unreviewed_or_unknown_blocks；选择一个实际执行的用例独立解释并修改，不能把交付者测试说成本人已完成。
官方核对资料
核对日期：2026-11-03；历史工作事实以个人记录与公开仓库证据为准。