项目背景
“湾大跑腿”是计算机课程期末项目，面向校内代取快递、代买物品和校内送物等轻量场景。普通用户既能发布任务，也能接取他人的任务；管理员负责用户、订单、公告、申诉和系统设置。
项目采用前后端分离架构：前端使用 Vue 3、TypeScript、Pinia 和 Axios，后端使用 FastAPI、SQLAlchemy、Pydantic 和 SQLite。订单围绕状态机流转，并通过接单人收款码完成线下付款演示。
我的角色
两位组员分别负责前端和后端，并各自与 AI 协作开发。我以 Tutor / 协调者 的角色参与项目，主要负责：
- 在开发前整理产品规格、API 约定和前后端协作规则，明确路径、字段、状态值与权限边界；
- 合并前后端分支，处理并行开发后的接口悬空、字段不一致和页面联调问题；
- 组织测试与 debug，检查订单状态流转、用户权限、申诉处理和收款流程；
- 在项目收口阶段补齐用户注册、订单大厅接入和面向演示的页面文案；
- 整理当前状态、接口契约、演示脚本、浏览器验收清单和最终 README，让项目能够交接和复现。
这不是一次“把前端和后端拼起来就结束”的协作。项目经历了两轮前后端并行开发、合并与扫尾，我需要持续判断哪些问题应该统一源头，哪些差异应该在边界层转换。
平台交付结果
最终课程交付版覆盖了完整的本地演示主线：
- 用户注册、登录、资料维护与收款码上传；
- 发布任务、订单大厅、接单、配送、确认收货和确认收款；
pending → accepted → delivering → waiting_confirm → waiting_payment → paid的订单状态闭环；- 用户申诉以及管理员处理异常订单；
- 管理员公告、订单、用户、申诉和系统设置管理；
- FastAPI 接口测试、前端构建检查、演示数据重置和现场演示脚本。
项目定位是课程演示，不接入真实支付、校园统一身份认证或生产级部署。收款码只用于线下结算流程展示。
进一步产出：前后端命名空间研究
项目完成后，我没有只保留最终代码，而是把这次 AI 协作开发过程转成了一个可研究的问题：同一个业务概念在什么情况下会被前后端命名为同一个字段，又为什么会产生不同名字？
我对四个开发阶段的代码快照进行了静态扫描和 Git 演进分析，覆盖后端契约、数据模型、Pydantic schema、路由、seed 配置，以及前端类型、API 封装、mock、状态管理和 normalize.ts 等层。最终口径识别出：
- 104 个跨项目唯一字段名；
- 45 个前后端同名字段；
- 31 个后端独有字段和 28 个前端独有字段；
- 自动提取并核验 12 组别名关系，例如
creator_id ↔ poster_id、access_token ↔ token； - 追踪字段差异在两轮并行开发、合并与扫尾过程中的产生和保留方式。
研究成果包
这项研究最终形成了一套可以从源代码重新计算的成果，而不只是结论性文字：
- 一份完整项目报告和一份适合快速阅读的精简报告；
scan_v2.py静态扫描器，可从四份代码快照重建统计结果；- 原始 JSON、字段台账、阶段汇总、Git 提交分析和别名轨迹；
- 四份独立附录：项目时间线、12 组别名证据卡、研究方法演进和代码位置索引；
- 带源码位置、提交历史和反事实分析的全链路证据目录；
- 精简包、完整包和归档包，方便阅读、复算与交接。
这部分产出保存在课程研究交付目录中。由于课程源码没有对外发布许可，项目页面只记录方法和结论，不公开仓库及原始证据文件。
研究结论
分析发现，同义字段是否同名，并不只是“命名规范有没有执行”的问题：
- 共享契约、核心业务实体、通用技术惯例和已经稳定联调的接口，会推动前后端使用同一个名字；
- UI 展示、数据库持久化、状态机、角色上下文和不同语言习惯，会让同一个概念出现合理的不同名字；
- AI 会在规则明确的区域复用已有命名，也会在契约空白处根据各自的前端或后端上下文放大差异；
normalize.ts等适配层能让项目运行，但也可能把字段漂移长期隐藏起来。
因此，治理目标不应该是“所有字段必须同名”，而应该是：核心契约字段必须统一，合理别名必须有台账、有集中转换、有测试，也能追溯到产生原因。
这段经历
这次课程项目让我同时经历了产品协作、工程收口和研究复盘。前半段要让多个开发者和多个 AI Agent 的代码真正跑到一起；后半段则把联调中反复出现的字段问题转成数据、证据和可复算的方法。
相比“完成了一个网站”，我更看重这次额外产出的能力：从一次具体工程中提炼问题，建立口径，编写工具，核验数字，再把结论组织成其他人能够复查和复用的材料。