Article

2026-07-09 Arkon Fullstack Challenge V1 AI辅助交付说明

临时-Arkon Challenge

Arkon Fullstack Challenge V1 AI辅助交付说明

日期：2026-07-09

关联文档：

1. 文档目的

本文档面向 challenge 评审方，用于说明本次 Arkon Fullstack Challenge 交付中 AI 的实际参与方式、人工主导边界、质量控制方法以及可验证产物。

我希望表达的重点不是“是否使用了 AI”，而是“是否能在真实工程任务中，把 AI 放进一个受约束、可追溯、可复核的交付流程里”。因此，以下内容会尽量对应评审时常见的关注点展开说明。

2. 本次 AI 参与的总体原则

本次任务中，AI 的定位更接近 受约束的工程协作执行器，而不是无边界的代码生成器。整个交付过程遵循以下原则：

  1. 先澄清需求和交付边界，再进入实现
  2. 先阅读现有仓库与上下文，再进行最小影响面修改
  3. 先验证真实问题，再决定是否接受当前实现
  4. 先完成本地自动化验证，再形成正式交付结论

对应到实际分工上，AI 主要参与以下环节：

  1. 需求与交付边界整理
  2. PRD、技术方案、自测计划、自测报告等文档协作产出
  3. 代码修改与问题修复
  4. Playwright 浏览器自动化验证
  5. 回归结果整理与交付材料归档

由我人工主导并最终拍板的部分包括：

  1. 需求理解与边界判断
  2. 方案取舍与实现接受标准
  3. 问题优先级和修复方向
  4. 是否继续扩测
  5. 是否具备交付条件

3. 本次交付中 AI 的实际使用方式

3.1 需求理解与边界整理

在编码之前，我先让 AI 协助梳理本次交付边界，而不是直接进入实现。重点确认了以下内容：

  1. 挂载路径是现有域名下的子路径，而不是独立站点
  2. 需要同时提交代码与文档，不是只交一个可运行页面
  3. 需要补齐正式交付物，包括 PRD、技术方案、自测计划、自测报告
  4. 验收不能只靠手点，需要有本地可重复执行的自动化验证
  5. 状态流、结果门控、子路径兼容和会话恢复是本题的关键边界

这一步的作用，是先把“要交付什么”与“怎么证明交付完成”压实，避免一开始就陷入局部编码。

3.2 文档协作产出

AI 参与产出了以下文档内容：

  1. PRD
  2. 技术方案
  3. 自测计划
  4. 自测报告
  5. AI辅助交付说明
  6. 全量自测结果 JSON

这些文档并不是一次性生成后直接交付，而是围绕以下维度反复收口：

  1. 是否与代码和测试结果一致
  2. 是否符合正式交付物的结构和命名风格
  3. 是否能被评审方快速理解和追问
  4. 是否避免空泛的 AI 话术

3.3 代码实现与问题修复

本次代码工作没有采用“重新生成一套应用”的方式，而是在现有仓库内做增量修复。AI 主要协助完成了以下工作：

  1. 修复子路径部署下客户端 fetch 与跳转逻辑
  2. 将分步保存改为更贴近步骤边界的 payload 提交
  3. 修复结果页在 basePath 下的路径问题
  4. 补上提交前对 activityLevel 的保存
  5. 将服务端校验错误转成结构化可消费响应
  6. 为前端补齐字段级友好错误提示
  7. 增加 Playwright 冒烟测试脚本
  8. 增加 60 条本地全量自测脚本

其中有一部分问题并不是在阅读代码时直接发现的，而是在浏览器实际操作和脚本回归中暴露出来，再回到代码中修复并复测通过。

3.4 自动化验证与回归

本次没有把“代码能跑起来”视为完成，而是把验证分成四层：

  1. lint
  2. 单元测试
  3. 生产构建验证
  4. Playwright 浏览器链路验证

最终本地完成了：

  1. npm run lint
  2. npm test
  3. NEXT_PUBLIC_BASE_PATH=/labs/arkon-challenge npm run build
  4. npm run smoke:e2e
  5. npm run selfcheck:full

其中 selfcheck:full 覆盖 60 条用例，并输出原始结果文件 全量自测结果.json，作为本次交付的验证凭证之一。

4. 本次实际使用的能力与未显式使用的能力

4.1 本次实际使用的能力

A. 代码上下文阅读与受约束修改

主要作用：

  1. 阅读现有仓库结构与实现方式
  2. 基于既有代码风格做最小影响面修改
  3. 避免无关重构和无依据扩写

本次用途：

  1. 修复问卷状态流和子路径兼容问题
  2. 调整前后端之间的校验反馈方式

B. Playwright 浏览器自动化

主要作用：

  1. 模拟真实用户填写、刷新、返回、提交、支付解锁等行为
  2. 验证多步表单、结果门控与恢复逻辑
  3. 将验证沉淀为仓库内可重复执行的脚本

本次用途：

  1. 冒烟测试
  2. 字段级错误提示验证
  3. 会话恢复验证
  4. 完整提交流程与结果页门控验证

说明：

本次没有使用内置页面操作能力做一次性手测，而是直接引入 playwright 包编写项目内脚本，目的是让验证结果可以重复执行、重复复核。

C. server-resource-bridge

主要作用：

  1. 定位服务器入口、部署目录、反向代理路径与运行方式
  2. 在需要排查环境问题时快速确认资源位置

本次用途：

  1. 确认 challenge 相关部署目录与代理路径
  2. 在前期环境核查时辅助定位目标机器与服务入口

D. aws-bridge-local

主要作用：

  1. 通过本地 bridge 间接访问 AWS 资源
  2. 在实例级别执行启停与恢复动作

本次用途：

  1. 在一次环境误操作后辅助恢复目标实例

4.2 本次未显式使用，但并非能力缺失的部分

A. 前端风格 SKILL / 后端风格 SKILL

这类能力本次没有被单独提取成显式 skill 执行，但并不代表缺失。

我的使用习惯通常是先完成对团队系统、现有仓库、相邻模块和既有实现的全量扫描，再判断是否需要把前端风格约束或后端风格约束单独提升成一条强规则。

本次 challenge 的范围相对集中，核心目标是完成一个独立可交付的小型业务闭环，因此我优先采用的是：

  1. 先对齐现有实现方式
  2. 先控制改动影响面
  3. 先修真实功能问题

只有在任务扩大到多页面统一治理、跨模块规范收敛或长期产品维护时，我才更倾向于把前端风格或后端风格显式抽成独立 skill。

B. Figma 相关能力

本次未显式使用。

原因是本题并非完整设计稿还原任务，也没有要求按高保真视觉稿逐像素对齐。

C. cloudflare-local

本次未使用。

其能力主要面向 DNS、Zone、流量分析等 Cloudflare 资源。本次交付重点在本地实现、验证与文档整理，不依赖 Cloudflare 层面的配置变更。

D. browser:control-in-app-browser

本次未使用。

原因是本次验证目标不是一次性点击检查，而是沉淀成仓库内的自动化回归脚本，因此最终选择了 Playwright 脚本方案。

E. documents / pdf / presentations / spreadsheets

本次未使用。

原因是当前交付以 Markdown 文档、代码仓库和测试结果为主，不需要再额外转制为 docx、pdf、ppt 或表格文件。

5. 评审可能关心问题的正面回答

5.1 是否是“AI 直接把代码写完”？

不是。

更准确地说，本次是“人工主导边界与验收，AI 参与实现、修复、验证和整理”的协作方式。AI 可以显著提高推进速度，但最终交付质量仍取决于：

  1. 是否先把需求边界想清楚
  2. 是否要求它在真实仓库上下文内工作
  3. 是否对输出结果做独立验证
  4. 是否在发现问题后继续修复而不是停留在表面完成态

5.2 如何避免 AI 生成看起来能跑、实际上不可靠的结果？

本次主要通过三层方式约束：

  1. 约束输入上下文：先读仓库、再改代码，不凭空重写
  2. 约束接受标准：必须通过本地 lint、单元测试和生产构建
  3. 约束最终结论：必须通过 Playwright 链路验证，并补齐 60 条回归

因此本次流程不是“生成即完成”，而是“生成 -> 验证 -> 修复 -> 复测 -> 文档化”。

5.3 本次如何证明测试不是走过场？

本次保留了完整的可验证证据链：

  1. 自测计划 中的用例矩阵
  2. 自测报告 中的执行结论
  3. 全量自测结果.json 原始结果文件
  4. smoke:e2e 与 selfcheck:full 两个仓库内脚本

这意味着评审方看到的不是一句“测试已通过”，而是：

  1. 有测试范围
  2. 有测试执行
  3. 有原始结果
  4. 有可重复运行的脚本

5.4 为什么这次没有把所有已有 AI 能力都用上？

我的原则是 按任务需要最小调用能力，而不是为了展示 AI 使用广度而刻意调用无关能力。

对一个范围清晰的 challenge 来说，更重要的是：

  1. 能否准确定义边界
  2. 能否快速收敛实现
  3. 能否沉淀验证证据
  4. 能否说明哪些能力真正被使用、哪些没有使用

从评审角度看，这种克制反而更接近真实工程判断。

5.5 如何看待 AI 在工程中的边界？

我的判断是，AI 在工程里最有效的角色不是“替代判断”，而是“放大执行密度”。一旦边界不清、验证不足、环境控制失效，AI 也会放大错误。

因此我更关注的是三件事：

  1. 是否先把边界压实
  2. 是否把验证独立出来
  3. 是否让最终交付能被他人复核

如果这三点做不到，AI 只会让问题更快发生；如果这三点做到，AI 才会真正提高交付效率。

6. 本次交付的可验证证据

6.1 文档证据

  1. PRD
  2. 技术方案
  3. 自测计划
  4. 自测报告
  5. AI辅助交付说明

6.2 测试证据

  1. npm run lint
  2. npm test
  3. NEXT_PUBLIC_BASE_PATH=/labs/arkon-challenge npm run build
  4. npm run smoke:e2e
  5. npm run selfcheck:full
  6. 全量自测结果.json

6.3 代码证据

本次核心修改集中在以下文件：

  1. src/app/page.tsx
  2. src/app/page.module.css
  3. src/app/result/[sessionId]/page.tsx
  4. src/app/api/session/[sessionId]/progress/route.ts
  5. src/lib/validation.ts
  6. scripts/playwright-smoke.mjs
  7. scripts/full-self-check.mjs

7. 结论

如果从评审视角看，这次交付想证明的并不是“我会不会使用 AI”，而是以下几点：

  1. 我会先定义边界，再推进实现
  2. 我会要求 AI 在真实仓库约束内工作，而不是脱离上下文自由生成
  3. 我会把测试从实现里独立出来，用自动化方式验证关键链路
  4. 我会保留足够的文档、脚本和结果文件，让交付可以被复核

因此，本次 AI 的价值不在于替代工程判断，而在于被组织进一个可控、可验证、可交付的研发流程中。