零代码工程实践：一套自定义协议，把写代码这件事完整交给 Agent

📝

林是梦的零代码工程实践：一个月没写业务代码、需求照常上线。核心是一套被规范进 Skill 的状态机协议（dev-lifecycle.skill）——状态持久化到 JSON 文件实现断点续跑，三层循环（Review Loop / Step Loop / Auto Cascade）让开发可恢复可级联，Operation Contract 把每一步的输入输出状态改变写死成契约。协议先行，Agent 就是被缰绳约束的执行者。

一个月没写一行业务代码，需求却照常上线。这靠的不是 vibe coding，而是一套被规范进 Skill 的状态机协议，让 Agent 在 spec 评审、逐步开发、CI 部署之间断点续跑、循环反馈、自动级联。代码交出去之后，真正剩下的只有协议和决策。

最近一个月，我一行业务代码都没有写。但需求还是照样正常上线，只是代码全由 Agent 写的，我手里产出的东西变成了 Spec 文档、协议规范、和 review 意见。Agent 写代码依据的是我设计的一套协议，它完全照着协议开发，我在几个关键节点上给出审批意见。

这就是文章标题说的零代码工程。

什么是零代码工程

零代码工程协议被规范到 Skill 里，作者发布了一个「dev-lifecycle.skill」，开发全流程编排技能。

从需求想法的提出，到写代码、单元测试，code review，git 合并解决冲突后，最后部署到测试环境（Jenkins+Docker），部署完成发布通知——以上，Agent 全面彻底接管。

关键它并不是 vibe coding，而是能支持反复 code review，直到代码写的没有问题后，才提交测试。它是一个半自动流程，编排了多个 skills，实现从需求材料（接口文档、产品文档、会议纪要等）转成 spec、分步骤开发，到 Jenkins 测试部署。在这个流程中作者可以随时离开、中断，去开会去吃饭完全不影响。

实现这一切的核心机制就是定制了一套状态机协议，让 Agent 随时都能知道当前处于哪个阶段，下一个阶段该怎么执行。该 skill 已全部开源（github.com/linshidream/skill-hub）。

如何实现断点续跑

AI 写代码每次靠理解上下文和给出的提示词任务要求，来判断接下来要执行的动作，但是往往受限于上下文窗口，一旦达到 100% 后，注意力稀疏，执行产生偏差。

而人类工程师可以横跨数日乃至数周后，依然能够接替之前的 coding 任务。这除了靠自身记忆实现之外，最主要的：我自己写代码，能明确知道目前开发到哪个阶段了，代码写了一半了接着继续写。

所以，Agent 接管的第一步，需要将项目开发状态持久化到项目中，用 JSON 文件保存。Agent 每次开始新会话前，先读取活动状态文件路径，再读取其 phase（步骤）决定下面行为。

例如，当 phase 是 step:awaiting-review，它就问我是继续 review 还是通过？phase 是 building，它就去查 Jenkins 状态，实时查看构建状态。

会话恢复协议

这要求 Agent 每完成一次动作，都得更新 phase 步骤，以及维护任务执行历史——新会话恢复时就有了完整上下文。状态文件加入 .gitignore，不用提交，团队里的每个开发者维护自己的状态机。

设计循环反馈工程

所有工作都不是线性存在的，尤其是开发工作。前期的需求反复讨论、后面的编码、修复、再编码。这个过程是循环进行的，我们需要设计「循环 → 反馈 → 循环」工程。

在前期需求规格化，需要停下来反复 review；当 AI 写完代码后，同样需要反复 review，这个过程都需要人工参与。而当循环反馈的任务完成后，就会自动化。

两个 Loop

第一层是 Review Loop。 任何一个产物，spec 也好、某个 step 的代码也好，都走 producing（生产）、awaiting-review（评审）、revising（修复中）这三态循环，直到 approved（通过）。

awaiting-review 是个持久等待态，作者可能关掉终端去审查，第二天再回来，Agent 读一下状态文件就知道停在哪、等我什么。好几次就是这样：上午把 spec 审核通过，下午回一句通过，Agent 接着往下跑。

第二层是 Step Loop。 spec 里会把实现拆成几个业务闭环级的 step，比如实现供应商加密下单闭环是一个，联调和构建验证是一个。Agent 按顺序推进，每个 step 自己跑一遍 developing（开发）、awaiting-review（评审）、approved（通过），过了一个接下一个。

两个 Auto Cascade

第三层是 Auto Cascade。 一个 Review Loop 以 approved 退出后，后续步骤自动执行，直到撞上下一个需要介入的节点。spec 一过，自动切功能开发分支。代码一过，自动提交、push、合并测试分支、触发 CI。不需要在每个衔接点反复说”现在要做什么”。

三层叠在一起，开发就从一条会断的直线，变成一台能停在任意节点、随时能接着转的机器。Agent 能做到零代码而不失控，靠的就是这层结构。

驾驭的核心是协议

循环反馈能跑起来，是因为每个 step 的输入、输出、状态怎么改，都被写死成了一份契约。dev-lifecycle 叫它 Operation Contract（操作合约）。

比如 git-flow:integrate 这一步，输入是当前分支名和测试分支配置，成功输出是合并成功，如果冲突了，输出就是冲突报告，状态停在 integrating，把冲突记下来等我处理。每一步都这样——输入什么、输出什么、改哪个字段，全有约定，不能乱来。

完整的契约就是下面这张表。它是 dev-lifecycle 协议的骨架，从空文件夹到部署测试，每一跳该由谁驱动、凭什么往下走、往状态文件里写下什么，全在这里。

环节	phase 取值	谁在驱动	怎么往下走	写进状态文件，接手全靠它
骨架就绪	scaffold:done	project-init	自动移交需求整理	scaffold.ready=true
需求整理、出 spec	spec:intake → producing	Agent	spec 生成完转评审	spec、spec-sources、implementation
spec 评审（Review Loop）	spec:awaiting-review ⇄ revising	我	我回一句 approved	reviews 的轮次与反馈
spec 通过，自动切分支	spec:approved → branched	自动（Cascade 1）	git-flow:init 建分支	branch、feature、developer
逐步开发（Step Loop）	step:developing ⇄ awaiting-review ⇄ revising	Agent 写、我审	每个 step 我 approved 才进下一个	current-step、files-changed、checks
全部 step 通过	code:approved	自动（Cascade 2）	自动起提交链	history 追加事件
提交、推送	pushed	git-flow:commit / push 自动	—	commits[]、branch_pushed
合并测试分支	integrating → integrated	git-flow:integrate	无冲突自动过，有冲突停下等我	integration.resolved 或 conflicts
触发 CI 构建	building → deployed-test	ci-trigger + Jenkins	构建成功	build.status、构建编号
全流程完成	done	终态	收尾	完整 history 时间线

整条链跑下来，作者只出现在两个地方：spec 评审和逐步开发的 review。其余的环节，要么是 Agent 在执行，要么是协议自动级联，要么是 CI 在跑。

这张表也回答了，为什么它能接替下去。每一跳的进入条件、由谁驱动、往状态文件里留下什么，全写死在协议里，不在谁的开发者的脑子里。即使新开一个会话，Agent 读一下状态文件停在哪个 phase，就能精确接着往下跑，不用问我上次干到哪。

AI Native 真正关键的是协议先行，至于这些环节具体由哪个 Agent、用什么实现去完成，反而没那么重要了。协议先行的意义在于，执行动作被压扁成了可委托的原子动作，Agent 在协议约束下执行，协议就是 Agent 缰绳。这是区分是否是 Vibe Coding 的关键，稳定压倒一切。

AI Coding 的范式迁移

AI Coding 真正的变革，是面向 AI Native 工作流，把 Agent 做为一等公民。从项目的开始它就在存在，此后，开发流程被状态机和协议重写了，而 dev-lifecycle 就是这个重写的制度载体。

它定义状态机、定义 phase 取值、定义 cascade 规则、定义操作契约——任何理解这套协议的 Agent 都能接手执行，不绑死在某个具体 Agent 上，这才是它能跨会话、跨人、跨 Agent 的根。这是 AI Coding 从工具升级到范式的临界点。

作者还在思考：如果软件产出效率大幅提升之后，能不能反过来，帮那些还没完成数字化转型的小微企业？小微企业缺的是有人能快速给他们把一个具体的软件项目跑起来，以前这要一整支队伍的成本，现在一个人加一条编排链就能覆盖研发这条链路——One Person Company（一人公司）前夜真的到来了。

回到开头。一条编排链，从空文件夹到部署测试环境，作者只做决策和 review，三层循环让它可恢复可级联，operation contract 让 Agent 的每步可预期。开发流程被重写成了状态机，junior 的活交出去了，人升到了 senior 该待的位置，有了更多时间去想真正该想的事。

📊 GitHub 数据验证

项目	linshidream/skill-hub
描述	面向多 Agent、企业自建 Agent 和服务器运行时的通用 Skill Hub，像软件一样经历共建、校验、打包、发布、部署、加载和回滚的 Agent Skill 通用仓库
Stars	11
语言	Python
协议	MIT
创建时间	2026-06-01
最近推送	2026-07-16

⚠️ 项目非常新（创建约 2 个月、11 stars），是作者个人实践的开源沉淀，dev-lifecycle.skill 位于其 skills/dev/ 目录下。方法论价值 > 项目成熟度，生产接入前建议通读其协议定义。

开源地址： https://github.com/linshidream/skill-hub/tree/master/skills/dev/dev-lifecycle

本文转载自微信公众号（林是梦），内容有删节整理。