QUOTE
真正的变化，不是让 AI 写得更快，而是让研发系统能够持续运行。
—— Yakir
Anthropic 前不久发布了一篇关于软件开发周期的文章：The AI-Native SDLC Playbook。
https://claude.com/blog/the-ai-native-sdlc-playbook
传统软件开发生命周期是一条流水线：规划 → 设计 → 开发 → 测试 → 部署 → 维护。
这套流程建立在一个前提上：写代码很慢，开发成本很高。所以过去所有的流程设计，本质上都在解决如何降低返工、如何控制质量。
AI Coding 出现以后，这个前提变了。当 AI 可以快速生成代码、测试和文档，开发速度明显提升，瓶颈开始向开发阶段的前后转移。
瓶颈转移
编码速度提上来了，需求确认、方案设计、测试、Review、发布这些依赖人工的环节，反而更容易卡住时间。
逐行 Review 不可持续
过去代码主要由人写，逐行检查是合理的。但 AI 生成的代码，一个 PR 可能几千行，人再靠逐行看，根本追不上 AI 的产出速度。
治理方式需要同步调整
AI 可以持续生成和修改代码，但很多审批还停留在每周会议、人工检查、固定委员会的节奏上。
「AI 很快，但流程还在按照人的节奏走，这个错位会越来越明显。」
02
LOOP
AI Native SDLC：从流水线到循环
AI 原生的软件开发生命周期，不是在原来的流程里加一个 AI 工具，而是重新设计整个研发流程。
传统 SDLC 是一条线，阶段与阶段之间靠人推动。AI Native SDLC 更像一个持续运行的 Loop：每个阶段都有明确的输入和输出，并且可以自动触发下一阶段。
— 从线性流水线到机器可读工件驱动的持续循环
六个阶段的核心差异
计划
从“委员会收集需求、签字确认”变成“AI 直接从源头提炼痛点，写入 intent.md，人能读懂、机器也能操作”。
设计
从“分析师写规范、设计师解读”变成“需求和设计压缩进一次与 Agent 的工作会议，标准以 Skill 形式编码，Git 版本控制”。
开发
从“手工写代码和测试，文档后补”变成“AI 生成测试和代码，机构知识以版本化的机器可读文件和 Skill 维护”。
测试
从“阶段末尾的质量关卡”变成“贯穿实施过程的持续评估”。
部署
从“人工逐行审查、周期不一致”变成“多层智能体审查，人工只留给受监管的关键代码；治理机制通过钩子作为审批门”。
维护
从“人监控生产、发现缺陷”变成“Agent 监控实时部署，突破控制带就诊断并作为新控制带写回循环”。
其中最关键的变化是：每个阶段都留下机器可以继续读取的工件。
intent.md（为什么做）、spec.md（做成什么样）、plan.md（怎么实现）、Code／Diff、Test Result、Review Result、Incident／Production Feedback。这些内容既方便人理解，也方便 AI 在下一阶段继续工作。
每个阶段提交一个工件，串起来就是完整的审计轨迹。
公司情况不同，技术栈不同，不可能直接照搬一整套设计。但核心目标是一致的：建设一个可以自动运行的 Loop 系统。
结合我们公司的移动端开发阶段，我有五点思考。
1．CLAUDE.md
用一页纸记录代码规范、常用命令、架构说明。AI 运行出错时可以迭代更新，build、run、test 相关命令都放进去。
2．Skill
Skill 本质是可复用的操作规范：针对具体任务，把公司和部门的流程规则固化下来。新建分支、合并分支、提交代码、国际化文案处理，这些都属于 Skill 的场景。
以前我理解 Skill 是用来做某个具体功能的，现在觉得它更重要的价值是固定规范流程。Skill 越完善，AI 的执行逻辑越可控，输出越稳定，每次运行都能拿到可靠结果，这是实现 Loop 的基础。
3．设计验证 Loop
一个能自己跑起来的开发循环，至少需要四个能力：
4．代码 Review
日常自动化 Review，每日运行。
完整功能走多 Agent 对抗性审查。
新功能用 TDD 模式开发。
5．多 Agent 协作
使用记忆管理插件，结合 hook、插件机制积累上下文。
交接靠生成交接文档，而非口头传递。
— 移动端团队建设 AI 开发 Loop 的五个抓手
「最终我们要建设的，是一个有规则、有反馈、有验证的环境，让 AI 持续完成开发任务。」
当这个 Loop 真正建立起来，AI 就从一个Coding 工具，变成了研发流程中的 Agent。
如果开发速度大幅提升，你团队当前的研发流程里，哪个环节会最先成为瓶颈？有没有已经在酝酿的优化方向？
我是 Yakir，一名移动端原生开发工程师，擅长将想法落地为移动端应用。
如果你觉得今天这篇有收获，欢迎点赞、在看、转发三连，我们下篇见。
