“不积跬步，无以至千里。”
上篇讲的是底层逻辑：AI 原生研发不是让模型多写几行代码，而是把研发流程拆成一串“生成 -> 验证 -> 放行”的工程单元。AI 只负责生成候选，验证器和信任边界负责决定它能不能往下走。
这一篇聊落地。
我先说一个容易被忽略的判断：做 AI 研发流水线，最小可跑 demo 的价值不是“证明模型会写代码”。这件事早就不稀奇了。真正有价值的是，demo 会逼你回答一堆绕不开的问题：代码在哪里改，测试在哪里跑，失败怎么反馈，人审卡在哪里，证据怎么保存，批准以后内容被换了怎么办。
这些问题一旦不回答，demo 就只是一个脚本。一旦认真回答，它才开始变成流水线。
不要一上来做平台，先找一个小靶子
很多工程化项目失败，是因为第一步就想做平台。AI 研发流水线尤其不能这么干。
一开始就接一个历史包袱很重的大仓库，会同时遇到依赖装不起来、测试跑不完、模块边界不清、隐式配置太多、CI 规则复杂、review 责任链不明确等问题。最后你分不清到底是 AI 不行，还是仓库治理本来就不行。
更稳的做法是先找一个小而真实的靶子仓库。它不用复杂，但要具备几个条件：
- 有真实业务接口，而不是纯玩具函数；
- 有一组能稳定运行的测试；
- 改动范围能被控制在少数文件内；
- 需求能被写成明确验收标准；
- 失败时能看出是需求错、计划错、补丁错，还是测试环境错。
我会倾向于拿一个小型任务服务或笔记服务做起点。比如“给列表接口加分页”“补一个输入校验”“给某个查询加排序”。这些需求不高级，但非常适合打通管道。因为它们足够真实，又不会把第一版系统拖进复杂业务泥潭。
这里的目标不是炫技，而是让流水线第一次完整呼吸起来：一句需求进来，产出规约、计划、补丁、测试结果、门禁报告、证据包，最后停在人审边界前。
只要这条链路跑通，后面替换模型、增强检索、加扫描器、接真实 PR 系统，都是增量问题。管道没通之前，局部能力再漂亮也只是局部能力。
控制平面只做编排，不要塞业务判断
落地时我会先拆出一个控制平面。它听起来很大，其实第一版只需要做几件事：
- 记录当前跑到哪个阶段；
- 接收每个阶段的产物和门禁结果；
- 根据放行门决定下一跳；
- 在失败时把反馈带回去；
- 在人审处暂停；
- 把关键产物落盘，方便恢复和审计。
控制平面的边界要守住：它不应该知道“分页接口应该怎么改”，也不应该知道“某个测试为什么失败”。这些是阶段内部的事。控制平面只关心状态、路由和边界。
一个简化后的形状大概是这样：
defroute(stage:str,result:StageResult,state:PipelineState)->str:ifresult