规格先行
问题没定义清楚之前不动手。
写任何实现之前，先固定决策变量、约束语义和验收样例。规格模糊的时候，生成得越快返工越贵；规格清楚之后，实现就退化成一件可以交出去的事。自然语言运筹建模助手本身就是这条原则做成的产品。
我把哪些活交给了模型。
四个决策产品、两套能跑起来的全栈 Demo，一个人做出来的。模型接走的是实现和重构这类耗时的部分。问题怎么定义、约束怎么取舍、什么算通过，留在我这边。
4决策产品装载、调度、合单、建模各一个
2可运行全栈 Demo求解后端加可视化前端，各自能独立跑起来
3能力主线同一批作品，三个角度检验
1统一部署入口一份编排文件托管门户和全部 Demo
下面写的是这个仓库真实在用的协作方式。每一条都能在提交历史、测试和脚本里找到对应的东西。
Principles
四条原则
分层委派
决定质量上限的那部分不外包。
求解策略怎么选、哪些约束是硬的哪些是软的、失败之后该怎么办，这些判断由我来做。候选枚举、类型化实现、可视化脚手架、边界测试这些决定交付速度的活，交给模型。
统一脚手架
第二个产品不该从零开始。
两个 Demo 共用同一套形状：FastAPI 求解后端、React 可视化前端、独立容器镜像、同一套网关前缀和健康检查。换个新场景，要做的是替换求解核心，部署方式不用重新发明一遍。
闸门自动化
生成一快，人工复核第一个失效。
生成速度提上来之后，人工复核会先变成瓶颈，再变成走过场。所以检查必须是能执行的脚本：接口测试、前端构建校验，还有一个发现凭证或业务标识就直接让流程失败的隐私扫描。
Division of labour
每个阶段谁做什么
这张表是这一页的核心：产量来自分工，而判断那一半始终在我这边。
| 阶段 | 我负责 | AI 负责 | 通过标准 |
|---|---|---|---|
| 问题定义 | 抽象决策变量、约束与目标，写下验收样例 | 追问遗漏条件，把口述整理成结构化规格草稿 | 规格里不允许出现「视情况而定」 |
| 求解设计 | 选解法路线，划定硬约束，权衡性能 | 把伪代码落成带类型约束的实现 | 先有能解释的基线，再谈优化 |
| 服务实现 | 定义接口契约、幂等语义与错误码 | 生成路由、校验、适配层与异常分支 | 接口测试通过，异常路径有明确返回 |
| 界面交付 | 决定信息层级，以及约束怎么暴露 | 搭建组件、可视化与样例场景 | 前端构建通过，指标与结果同屏能对上 |
| 发布准备 | 确认公开边界与可举证的表述范围 | 同步文档、部署配置与替换清单 | 隐私扫描通过，没有未替换的占位符 |
Guardrails
跑得快之后靠什么兜底
生成越快，越需要不依赖人工注意力的检查。下面四项都是能直接执行的脚本。
- 接口与求解测试
两个 Demo 后端各自带 pytest 用例，覆盖健康检查、正常求解与边界参数。 - 构建即校验
前端以 TypeScript 严格模式构建，类型不通过就产不出静态资源。 - 自动隐私扫描
scripts/privacy_check.py 扫描全部可发布文本，命中凭证、内部域名或业务标识就直接失败。 - 表述纪律
「可扩展能力」和「已上线成果」在数据模型里就是两个字段，演进方向没机会被写成既成事实。
- 求解后端都是 FastAPI，健康检查端点的前缀可配置
- 前端都是 Vite + React + TypeScript，静态资源基路径与网关前缀对齐
- 每个 Demo 自带 Dockerfile，由同一份编排文件和网关配置托管
- 门户与 Demo 共用一个部署入口，升级只需要重建镜像
Applied per project
落到每个作品上
抽象原则谁都会讲，所以每个作品详情页都单独写了这一次人和模型各自做了什么。