项目概览
这个仓库整理了三道来自真实招聘流程的 AI Coding 项目题，并提炼出一套适用于限时笔试、Take-home Assignment 和现场结对开发的通用方法。题面经过匿名化与结构化改写，不包含公司、面试官、招聘人员或客户名称。
仓库本身主要保存题目复盘与方法论。三个对应的个人解法位于独立仓库，其中包含源码、设计文档、测试和实际交付记录。
这些项目真正考察的并不只是代码量，而是需求理解、架构边界、过程控制、验收证据和取舍能力。
三道项目题分别考察什么
01：Computer Use Agent Dashboard
第一道题要求构建结合 Web、Agent 与隔离桌面的系统，重点考察 Computer Use、工具调用循环、会话隔离、可观测性和运行时可靠性。
处理此类项目时，不能只完成模型 API 调用和界面展示。还要关注 Agent 如何调用工具、不同会话如何隔离，以及失败状态能否被观察和恢复。
02：React Native 截图行动 Agent
第二道题是一个 48 小时的 React Native／iOS 项目。它以截图作为输入，重点考察多模态理解、结构化 Action、Human-in-the-loop、原生工具和 Memory。
- 题目复盘：React Native 截图行动 Agent
- 个人实现：ContactFlow
这类题目的关键是形成完整闭环：理解截图、生成结构化行动、让用户确认，并通过合适的原生能力执行，而不是只输出一段自然语言建议。
03：Jira 风格任务管理系统
第三道题要求在一天内完成 Web MVP，主要考察需求取舍、CRUD、看板拖拽、本地持久化、时间线和整体交付质量。
- 题目复盘：Jira 风格任务管理系统
- 个人实现：ForceTrack
该项目还保留了从 PRD 到 Repo Wiki 的 24 个真实 AI Coding 对话轮次，可用于观察需求、实现与文档是如何逐步推进的。
核心方法：六步完成 AI Coding 项目
AI Coding 项目通用解法把完整流程拆成六个阶段。无论题目是 Agent、移动端还是 CRUD 系统，都可以按这一顺序执行。
第一步：澄清需求并冻结范围
先把模糊描述转换成可以验证的 P0 范围。区分必须完成、可以延后和明确不做的内容，避免在限时项目中持续扩张需求。
可以先建立一个简化的需求矩阵：
需求：用户可以完成什么操作？
验收：如何证明操作成功？
优先级：是否属于 P0？
状态：未开始、进行中或已验证？
风险：依赖、权限、失败路径或时间成本是什么？矩阵的重点不是格式，而是让每项工作都对应清晰的验收证据。
第二步：审计 Starter 或现有仓库
如果面试方提供 Starter，不要立即重写。先检查现有目录、依赖、构建方式、数据模型和可复用组件，再决定哪些部分保留、扩展或替换。
- 确认项目能否正常安装、构建和运行。
- 识别已有状态管理、持久化和测试方案。
- 检查平台、权限与运行时约束。
- 记录阻塞项，避免让 AI 在错误假设上继续生成代码。
第三步：设计数据、状态、工具与运行时
不同题目会强调不同边界：Agent 项目需要考虑工具循环、会话隔离和失败恢复；移动端项目需要考虑结构化 Action、用户确认与原生工具；任务系统则需要关注 CRUD、拖拽状态、本地持久化和时间线。
设计时应明确正常状态、加载状态、失败状态和恢复方式。只有主路径而没有边界条件，通常不足以形成可交付闭环。
第四步：用垂直切片拆分 AI 任务
不要一次要求 AI 生成整个系统。更稳妥的方式是按垂直切片推进，让每个切片都包含必要的数据、逻辑、界面和验证。
给 AI 的任务合同可以至少写清以下内容：
目标：本轮要完成的可见结果
范围：允许修改的模块
约束：技术栈、时间和兼容要求
验收：必须通过的操作或检查
禁止项：本轮不应扩展的功能这种拆分方式能减少上下文漂移，也便于人工逐轮审查。
第五步：人工 Review 与自动化验证
AI 可以提高实现速度，但技术判断仍由开发者负责。每轮修改后都应检查代码是否符合需求、是否破坏已有行为，以及失败路径是否得到处理。
- 运行现有测试和构建流程。
- 手动验证核心用户路径。
- 检查状态、权限、持久化与边界条件。
- 确认界面展示与真实运行结果一致。
- 记录验收结果，而不是只记录“代码已生成”。
第六步：限时取舍、演示与最终交付
时间不足时，应主动砍掉低价值范围，优先保证 P0 闭环。最终交付不仅包括源码，还要使用构建结果、测试、演示和文档证明项目确实可运行。
一个简短的交付检查清单可以写成：
核心流程是否完整？
项目是否能够构建和启动？
关键失败路径是否处理？
数据或状态是否按要求保存？
演示步骤是否稳定可复现？
文档是否说明范围、取舍与已知限制？如何开始使用这个仓库
这是题目复盘与方法论仓库，不是一个需要统一安装依赖并启动的应用。因此，准备工作主要是阅读材料、复制模板，并结合具体题目建立自己的执行计划。
- 在 GitHub 页面克隆或下载当前仓库。
- 依次阅读三道项目题，理解不同形态下的工程目标与验收重点。
- 阅读通用解法，复制其中的需求矩阵、任务合同和交付检查清单。
- 选择一道题，将需求压缩为限时可完成的 P0 范围。
- 如需研究实现细节，再进入对应的个人解法仓库查看源码、设计文档与测试。
README 推荐的顺序是先读三道题，再读通用解法。实际做题时，不必完整照搬所有模板，应根据项目规模和时限删减。
基础实践示例
假设你正在练习 Jira 风格任务管理系统，可以先把一天内的目标限制为可验证的核心闭环：围绕 CRUD、看板拖拽、本地持久化和时间线安排实现与验收。每完成一部分，就同时验证状态更新和持久化结果，而不是等所有页面完成后再统一测试。
如果练习截图行动 Agent，则可围绕“截图输入、多模态理解、结构化 Action、用户确认、原生工具”组织垂直切片。每个阶段都要保留人工确认与验证步骤，避免把模型输出直接视为可靠执行结果。
对于 Computer Use Agent Dashboard，应优先验证工具循环、会话隔离、可观测性和运行时可靠性。界面只是系统的一部分，运行过程是否可追踪、失败后如何处理同样属于验收范围。
进阶技巧
把验收证据放在功能数量之前
限时项目中，三个经过测试和演示的完整功能，通常比十个无法稳定运行的页面更有说服力。每项 P0 功能都应能通过操作、测试、构建结果或文档得到证明。
让 AI 加速实现，而不是替代决策
AI 适合处理边界明确的任务，但范围划分、架构取舍、风险判断和最终 Review 仍需由开发者掌控。任务越模糊，一次性生成大量代码的返工风险越高。
优先检查状态与恢复路径
三道题虽然形态不同，却都涉及状态、失败、恢复、权限、持久化或边界条件。演示前应主动测试异常输入、工具失败、状态切换和重新进入应用后的表现。
用真实对话历史复盘协作方式
ForceTrack 的 24 个真实对话轮次适合用于分析 AI Coding 的过程控制。阅读时可以关注每轮目标如何收敛、任务如何拆分，以及结果如何从 PRD 逐步沉淀到仓库 Wiki。
结语
这套材料的价值不只是提供三道练习题，而是展示一种可复用的 AI Coding 交付思路：先理解需求并冻结范围，再审计环境、设计边界、拆分任务、人工审查，最后用测试、构建、演示和文档完成验收。
实际招聘流程的题面、时限和保密要求可能不同。使用这些方法时，应始终以收到的正式材料为准，并根据时间主动删减低价值范围。