很多团队接入 AI 开发后，第一反应是：代码变快了。
但代码变快以后，半成品也会变快。
以前需求推进不顺，产品再解释，后端再补接口，前端再改字段，测试再追问题，运维最后等确认。流程慢，问题也慢。
AI 进来以后，执行被加速。如果协作方式还是老样子，就会出现一种情况：每个岗位都说自己做完了，但需求没有真正完成。
这就是我说的“一单到底”。
一单到底，不是多建一张工单，而是让一个需求或 bug 从出现开始，就进入同一张工作项。需求、上下文、代码改动、真实验收、截图证据、发布确认和责任人，都围绕这一张单流动。
以后不要问“前端做完了吗、后端做完了吗、测试测完了吗”，只问一句：这张工作项闭环了吗？
从岗位交接，到工作项闭环过去的研发流程，本质是岗位交接制。
产品交需求，后端交接口，前端交页面，测试交 bug，运维交发布。每个人都只证明自己那一段做了，整体有没有闭环，往往到联调、验收、上线前才暴露。
AI 改变的是成本结构。写代码、改接口、补页面、修 bug 变快以后，真正拖慢团队的东西变成解释、确认、验收和追责。
所以 AI 不是先淘汰岗位，而是先放大岗位之间的交接成本。
一单到底，就是把研发管理单元从“岗位”切到“工作项”。
岗位交接制关注“谁做完了自己那一段”，工作项闭环制关注“这件事有没有被真实完成”。
一张单，五道门• 入口门：新需求、新 bug、新意向必须先进入工作项。没有工作项，就不算进入研发流程。
• 上下文门：页面、接口、字段、权限、测试场景和发布影响不能散在文档、仓库、聊天记录和某个人脑子里。同仓、同工作项、同验收标准，本质都是为了减少上下文丢失。
• 执行门：AI 可以写代码、改接口、补测试、修 bug，但每次执行都要回到工作项，说明读了什么、改了什么、解决了哪个验收点。
• 验收门：代码生成了，不等于事情完成。验收不能靠 mock，必须真实环境联调，有截图、接口结果、日志或发布流水。没有证据的完成，只是更快地产生了半成品。
• 发布门：发布可以自动化，但责任不能自动化。Jenkins 可以推进流水线，负责人必须在关键节点二次确认，运维要上移到权限、审批、回滚和风险边界设计。
核心是状态机，不是人追问一单到底不能靠负责人每天在群里追问。
如果核心推进动作已经交给 AI，再靠人问“上下文齐了吗、验收证据有没有”，其实还是老流程。
真正要改的是把这些问题写进工作项状态机：
• 没有工作项，AI 不开始推进。
• 上下文未绑定，AI 不进入代码修改。
• 没有真实环境验收证据，工作项不能关闭。
• 没有负责人二次确认，发布流水线不能继续。
• 发布记录未回填，工作项不能归档。
这些问题不应该主要由人来问。它们应该变成 AI 推进流程里的自动检查项、阻断条件和异常提醒。
AI 负责把单往前推，系统负责判断能不能过门，人负责定义门槛和承担后果。
岗位不会消失，但只负责交接一段、不对闭环负责的工作方式会贬值。
因为当执行越来越便宜，真正贵的就是闭环。
你们团队关掉一张需求单时，最常缺的是上下文、验收证据，还是发布责任记录？