项目启动：四步

本课起小组学期项目启动，四步一次做完：建仓库 → 定规约 → 立规范 → 落骨架。前三步各产出一个后面能反复引用的东西，第四步才有可验证的基线；后续课次都在同一个仓库上按规约增量交付。

1四步各自产出什么

区分它们的办法是问一句：这一步留下来的东西，后面会被谁用到。

多人改同一套代码要有共同基线与历史：谁在什么时候改了哪一部分、依据哪条规约，都落在提交历史里。没有这份记录，课程后期复盘个人贡献时只能凭记忆，配置管理（configuration management）也就失去了对象。

规约先于代码：先把每条能力写成判定得出来的场景（Scenario），再交给 Harness 实现。规约既是给 Harness 的指令，也是验收时逐条对照的表——可验证需求（verifiable requirement）的意义正在于此：需求若不可判定，完成与否就没有客观依据。

分层、命名、接口风格、安全红线这些约束，要写在 Harness 每次都会读到的规则文件里；按场景执行的流程则写成技能。规范不定下来，同一个人另起一次会话生成的代码就会漂移，评审时无从对比——规范的作用正在于它不依赖某一次会话、某一位成员。

骨架是可启动的最小实现：一条命令可启动、健康检查端点返回成功。它不含业务，却是后续课次验收的起点——没有这条基线，出故障时无法区分是骨架缺陷还是当次新增能力的缺陷，回归也失去了对照物。

四步之间不是并列关系：每一步的产物都是下一步的输入，跳过前面任意一步，后面都只能靠人工补充说明。

对应的课程知识点：软件过程中的基线（baseline）与配置管理、需求到验收的可追溯性（traceability）、增量交付（incremental delivery）、质量门禁（quality gate）。四步不是四个并列动作：前三步确立可被反复引用的约定，第四步才产生第一个可验证的版本。

「完成现象」要能当场演示，而不是「差不多做完了」。

步骤	产出与下游用途	完成后的可验证点
建仓库	仓库、README、忽略规则、协作约定；供全组与教师复现	每人克隆（clone）后按 README 跑通一次；主干分支上随时可启动
定规约	一份变更的四份文件：动因、设计、需求规约、任务清单；供 Harness 实现，也供验收逐条对照	校验命令通过；另起一次会话只给出仓库路径与变更名，Harness 能照任务清单实现
立规范	规则文件，以及按需调用的技能；约束后续每一次生成	修改一次代码，生成产物的分层与命名符合规范；另起一次会话结果仍一致
落骨架	可启动的最小实现、健康检查端点、版本标签；作为后续课次的基线	克隆 → 填入配置 → 一条命令 → 健康检查端点返回成功，四步无需人工补充说明

四步都在本课完成，不跨课次：仓库是载体，规约是标准，规范是约束，骨架是基线。缺任何一步，后续课次都要回头补，且补做的代价逐次递增——因为每一步缺失的部分，都会在后续每一次增量中被重复承担。

这三种都不是能力问题，而是顺序问题；纠正办法都是补做被跳过的那一步。

偏差	为什么是问题	纠正办法
先写代码后补规约	验收时没有判定依据，完成与否只能声称「已完成」；后续做自动化回归测试时还要把规约重写一遍	停下手上的实现，先补齐四份文件与场景清单，再回到实现
规范留在会话里	会话结束即失效，更换成员或更换机器即回到各自的编码习惯，评审时没有统一对照物	常驻约束写成规则文件、流程写成技能，并用另起一次会话的方式验证结果一致
一次生成整套业务	无法启动，且发生故障时无法定位是骨架缺陷还是业务逻辑缺陷	回退到骨架那一组任务，先取得可启动的基线，再按能力逐次增量