交付里程碑很容易在单人项目中退化成一次例行的进度汇报：告诉客户“已经做了多少”，然后继续往下做。但真正有效的里程碑确认，核心不是展示进展，而是在高成本投入尚未发生之前，就一个最小决策点取得明确答复。一人公司或自由职业者没有排期缓冲，一次方向错误就可能挤掉下一个项目。里程碑因此应当承担方向校准功能，而不是完成度展示。

确认点要放在成本拐点上

选择里程碑的标准不是工作量是否均匀分布，而是成本结构是否即将发生变化。更实用的做法是识别一个节点：此前的工作主要属于低成本假设，此后的工作进入高成本实现。网页项目中的线框图确认、内容项目中的目录与大纲确认、数据项目中的样本字段定义确认，都属于这类拐点。节点一旦被跳过，返工成本会从局部调整迅速变成范围重做。因此，判断里程碑位置时，重点不应是“现在做到哪里”，而是“现在确认是否仍然便宜”。

三个最小要素：交付物、查看点、下一步

每个里程碑至少要向客户说明三件事：当前阶段交付什么、客户看什么、确认之后下一步做什么。客户不需要理解内部实现细节，也不需要审阅完整任务分解；他需要知道眼前看到的内容处于什么精度、与最终效果还有多远、现在提出意见是否还能低成本吸收。三者缺一，确认就容易变成“我看到了”，而不是“我理解并同意在此基础上继续”。确认的目标也不是让客户替专业人士做判断，而是让那些一旦被默认接受就会形成沉没成本的假设，在代价还小的时候被暴露出来。

未确认时的暂停不是对抗

单人项目最怕在等待反馈时为了“不耽误排期”而继续推进。实际上，未确认就继续，只是把决策压力推移到后面的阶段。更稳妥的做法是事先约定短暂等待期，并明确默认规则：到期未反馈，则按现有方案继续推进，之后出现的调整再按新增需求处理。暂停推进是在守住排期边界，而不是拒绝合作；它让客户在有限时间内完成决策，也避免项目进入无限等待。每次确认只需保留一条极简记录，能对应到具体版本即可，不必额外引入复杂流程。

交付里程碑的最小确认逻辑，归根结底是把“我做完了你看”改写成“我先确认，再继续”。节点选在成本拐点，信息只讲精度与下一步，未确认时不默认追加投入。这套逻辑不依赖重型管理工具，依赖的是在每一次投入即将加大之前，先完成一次可以被追溯的方向确认。