在课程实战里，我排查过一份作业：代码已经推送，CI 检查通过，代码候选也批准过，任务里却仍然提示缺材料。
继续核对才发现，实际提交和对应检查没有关联到当前任务，验收说明也没有补齐。代码保存在仓库里，接手审核的人却无法从任务中看清：这轮交的是哪一版，验证了什么，还有什么没完成。
这类问题，也是我做 AI 产研协作时特别关注的部分。产品确认过的规则，开发有没有拿到；开发交付的版本，测试有没有测到；准备上线的内容，是否就是被验收的那一份。
一条需求能够持续推进，前一步就得留下下一步接得住的东西。
我会把这条研发流程分成六个阶段：规划、设计、开发、测试、发布、维护。每个阶段写清输入、交付物和继续推进的条件，再由对应负责人确认需要人判断的部分。
下面结合我们正在做的课程项目，把这六次交接展开。文中的产品截图来自课程实战页面存档，展示当时的界面与状态；手绘图用于解释流程，两者分别标注。
01 把 AI 能力放进一条完整需求里
现在的编码 Agent，已经能承担不少跨步骤工作。
Claude Code 可以读取项目里的共享规则；GitHub Copilot coding agent 可以研究仓库、修改代码并准备 PR；Codex 的官方实践也展示了用仓库规则和执行计划组织复杂改造的方式。这些能力让 AI 有机会接手更完整的任务。Claude Code 项目规则1、GitHub Agent 最佳实践2、Codex 工程实践3
在我们的《AI Native 全栈工程师》课程里，这些能力被放进了一个具体项目：拼团哇。
团长创建拼团，买家选择规格、下单，之后再处理订单与履约。学员有自己的个人项目和独立仓库，用自己的 Codex 推进任务；我负责给出需求、核对业务规则和审核交回来的成果。
课程实战入口存档：准备进度会保存，学员可以返回自己的项目继续。
项目里需要保存的内容包括需求意图、设计方案、实施计划、代码改动、验证记录和发布记录。团队可以用文档、任务卡、设计稿和 PR 来承载，具体文件名按项目约定。
需要对齐的是内容和状态：哪份已经确认，哪份正在修改，哪些问题还没解决。文档已经生成，只能说明有了一份草稿。
02 规划：先确认这轮到底要交什么
实战第一份作业是"建立工程底座与 Harness 交付流程"。Harness 可以理解为项目里用于检查代码、保存交付证据的约束和工具。
这一轮要求学员读需求、建立可运行的工程、补真实检查，再把代码版本、审核和验收关联起来。后续业务功能会在这套底座上继续。
首项作业的目标与验收条件，截取自任务页。
这张任务卡把原有行为、完成后的行为和验收条件放在一起。学员开始前，就可以看清本轮允许改哪里，以及交付时需要拿出什么材料。
把这份作业概括成一份意图，可以这样写：
目标：让个人项目可以安装、启动、构建，并建立真实交付检查。
本轮范围：工程底座、检查流程，以及当前任务所需的交付材料。
后续工作：业务页面和接口按后续作业继续，不把整个拼团系统塞进这一轮。
待确认：需求中的业务疑问、尚未具备的环境或授权。
这段是对任务的归纳，实际执行仍要读原文。AI 可以整理材料、发现冲突，也应把没有依据的规则保留为待确认项。
产品负责人接受目标和边界后，方案才有稳定的依据。工程师接手时，也能直接看清本轮要解决什么。
03 设计：把产品规则和现有系统一起看
随着拼团作业推进，界面背后的业务规则会越来越具体。
例如，项目需求要求发布后冻结商品和交易规则。设计发布功能时，就需要看清哪些字段会冻结、谁有权限操作、页面如何反馈，以及服务端怎样拒绝不符合规则的请求。
学员讨论中，有同学用"A 变成 A+B"来描述 AI 添加新逻辑。这个说法很直观，但多出的 B 要看它改变了什么。
我在课时里用"发布后允许改价"举例：原本不能修改价格，增加了这个入口后，已下单用户面对的交易条件也可能受到影响。这个例子用于说明业务变更，不代表项目中实际发生过这项改动。
这样的变化要先说明原规则、新行为和影响，交给产品负责人判断。拆分组件、整理重复代码、修复不符合既有要求的行为，则由工程流程核对。
AI 在设计阶段可以读取代码、检查接口、整理依赖，帮助发现规则与系统的冲突。产品确认业务取舍，工程确认实现方式和技术风险，验收条件也在这时进入方案。
技术修正由工程流程推进；改变业务行为时，再交给对应负责人确认。
04 开发：让 AI 在自己的项目里推进
课程实战要求学员把本人项目、仓库和本机 Codex 接起来。这样，任务讨论、代码改动和交付记录才能指向同一个对象。
启动实现前，先核对仓库、分支、未提交改动和允许修改的范围，再让 AI 说明准备怎么做、怎么检查。
对工程底座作业，计划可以很具体：检查模板现状，完成启动和构建，补任务要求的检查，然后整理实际改动与验证结果。
连接状态存档：准备步骤已完成，但截图时本机 Codex 离线。
这张截图也提醒我们，接入过程中的成功提示，要看它描述的是哪一个时点。准备步骤完成后，继续开发仍要核对当前连接和工作区。
实现过程中，构建报错、已有测试失败、组件调用不符合约定，适合交给 AI 继续排查和修正。扩大权限、改变状态流转、修改数据归属，则需要重新提出业务问题。
每轮交付时，接手者应能看清实际改了哪些内容，和计划有什么差异，哪些检查已经执行，哪些受环境限制还无法完成。
05 测试：代码、检查和验收说明对应同一版
回到开头那份作业。代码已经推送，检查通过，候选也获批，为什么任务仍然缺材料？
我们排查发现，当前任务没有登记这份提交，检查证据和验收说明也没有关联进来。审核者无法从任务里确认，这次交付和此前批准的内容是不是同一份。
接下来要让 Codex 找出实际交付的提交编号，关联对应检查，再补上验收说明。我才能核对代码版本、需求覆盖和仍未验证的地方。材料补齐以后，我还要逐项核对任务要求，才能决定这轮作业是否通过验收。
代码发生变化后，受影响的验证也要更新。验收记录必须能追溯到实际交付版本。
同学还会问，上一轮需求和任务通过了，这轮继续做，为什么又要审核。需要回到上次批准的内容和这次的改动：旧批准能覆盖哪些部分，新行为是否改变了规则，检查是否已经跟上当前版本。
CI 是推送后自动运行的一组检查。绿色结果能够说明什么，要看它实际检查了什么。例如，构建通过，不足以证明其他团长无法修改这个团；页面没有改价按钮，也还需要验证接口是否拒绝改价。
在课时里，我把"实现回读"解释成验收说明：把任务要求和实际行为逐条对上，附证据，并保留未完成、未验证项。
可以直接让 Agent 这样交接：
对照本轮任务和需求，记录交付版本、验证环境及账号角色。逐项列出已验证、失败和未验证的场景，并附证据。修复后更新受影响的结果；业务变化列为待决策项。账号信息只记录角色，不包含凭证或个人信息。
06 发布：继续核对环境、材料和线上行为
在实战里，代码交付、作业验收、预览部署和生产发布，都有各自需要核对的内容。
进入发布环节，AI 可以协助检查实际分支和版本，整理验证记录与未解决问题，核对配置、接口依赖、静态资源，并准备发布后的检查步骤。
我自己发布课程实战指南时，也把配图检查做到了实际课时页：先核对发布目录包含应上线的图片，部署后在正常登录的阅读页面逐张检查加载结果。
本地图片存在，只能证明本地有文件。发布目录是否带上它、页面是否引用正确、登录后是否能加载，还要分别核对。
发布负责人随后确认是否接受这次改动，以及是否授权对目标环境执行操作。以 GitHub 的 cloud agent 为例，官方文档保留了人工审核和合并环节；具体权限仍取决于平台与仓库设置。GitHub Agent 权限与审核4
本地构建通过、预览可访问、生产部署完成、线上业务验证通过，应分别记录。部署系统完成了动作，接下来还要对照需求检查实际行为。
回退也要区分入口、应用版本和已写入的数据。应用回退不会自动恢复业务数据。
07 维护：把卡住的反馈组织成下一步工作
实战协作里，我们还遇到过一个提示问题：验收说明没提交，页面却提示产品处理差异，双方都以为下一步该对方操作。
这种反馈先要查清楚实际材料。提交是否关联，检查是否属于当前版本，验收说明是否存在，哪些确认还没完成。根据这些事实，才能判断下一步由学员补材料，还是由我核对结果。
AI 可以先做只读调查，把页面提示、任务记录、错误信息和近期改动放在一起，区分已知事实和待核实的原因。
如果提示顺序不符合既定流程，就形成明确修复；如果现有流程无法满足新的协作需要，则回到规划阶段讨论。修复之后，还需要重新走一遍这个场景：缺少验收说明时，页面能否准确告诉学员缺什么、下一步由谁处理。
运行中的问题也一样。调查记录要留下影响范围、复现路径和仍不确定的部分，由负责人判断优先级与处置范围，AI 执行获准的工作。
维护留下的诊断和反馈，会成为下一轮需求或修复的输入。
08 学员的提问，让"成功"的边界更清楚
课程群里还有一段让我很重视的讨论。讲消息队列时，一位同学看着下单流程图问：
飞哥，应该是处理成功，才会成功吧？我看图第 5 步就返回成功了？
消息队列课时中的真实提问，昵称已遮挡。这段讨论关注下单流程何时可以返回成功。
当时那张图描述的是：订单创建后，接口返回下单成功，通知和统计等后续处理继续进行。
这句追问促使我们把"成功"说明得更准确：接口承诺的核心业务结果已经完成，与所有后续服务都处理完，是不同的完成条件。哪些事情必须在返回之前完成，要由业务规则决定。
把它放回 AI 产研协作，也有相同的问题：AI 说完成了，指的是代码写完、检查跑完、材料交齐，还是已经通过验收？
前面的作业反馈、审核疑问和这句提问，都在提醒我们把状态对应的事实写清楚。学员可以指出看不懂的提示，AI 协助核对记录，我再确认规则、完善讲解或安排后续工作。
如果团队准备尝试这套方式，我建议先选择一条范围清楚、有验证环境、可以回退的真实需求。把意图、方案、实现、证据和发布记录连起来，看下一位接手者是否能直接继续。
试点结束，再看重复解释、等待交接、理解偏差返工和验收缺口有没有减少。这些结果能帮助判断，AI 是否改善了从需求到交付的过程。
我们在课程实战里练习的，也是把每轮工作交清楚：这次解决了什么，交的是哪一版，验证了哪些行为，还有什么尚未确认，以及接下来由谁处理。
想看项目的准备步骤和交付要求，可以从课程目录与试读5了解这套实战安排。
引用链接
[1] Claude Code 项目规则: docs.anthropic.com/zh-CN/docs/...
[2] GitHub Agent 最佳实践: docs.github.com/en/copilot/...
[3] Codex 工程实践: developers.openai.com/cookbook/ex...
[4] GitHub Agent 权限与审核: docs.github.com/en/copilot/...
[5] 课程目录与试读: flyger.xyz/courses/AI-...
最后推荐一下我最近在做的小册：
《AI Native 全栈工程师：从单栈开发到独立交付》这不是一门单纯教你写代码的课，而是想讲清楚：工程师如何借助 AI，把一个想法变成真正可以上线、可以使用、可以迭代的产品。上个月，我自己开发了 可圈可点、拼团交易项目和这套个人课程系统。这些经验也会沉淀到这门课里。如果你想从前端/后端单栈开发，成长为能独立交付产品的 AI Native 工程师，可以私信我。
扫描以下二维码加小编微信，备注 "ai"，一起交流 AI 技术！
点个在看支持我吧，转发就更好了