拆解技能包设计「上线发布」这件脏活怎么变成AI可执行的分步任务【免费下载链接】golive-skillTake your agent-built product live: hosting, database, domain, email, payments — on your own accounts. Open-source Agent Skill zero-dependency Node CLI: detect → plan → approve → apply → verify. No GoLive account, backend or telemetry.项目地址: https://gitcode.com/gh_mirrors/go/golive-skill把 App 部署上线可能是 AI 编程助手时代最被低估的一件「脏活」。写代码、跑通本地、提交 PRAgent 都能在几分钟内完成可一旦涉及到「把产品真正放到互联网上」——注册托管、建数据库、绑域名、配 DNS、写环境变量、注册 webhook、开通支付、发验证邮件——事情立刻变得又长、又碎、又充满账号与权限的雷区。社区里关于 AI 编码助手的讨论大量集中在「能不能更快地写代码」而真正卡住 Agent 交付的往往是这些写完后没人能自动完成的部署环节。开源项目 golive-skill项目根给出的答案很有意思它不是又一个部署平台而是一个Agent Skill——一套能被 Codex、Claude Code 等编程 Agent 直接读取的「技能包」外加一个零依赖的 Node CLI把上线拆成detect → plan → approve → apply → verify五个阶段。本文从流程工程的视角拆解这个技能包的设计任务如何被拆解、状态与失败如何管理、以及这套思路对自建 AI 工作流能借鉴什么。「脏活」为什么脏跨 Provider 的流程问题上线发布的难点不在单个操作而在组合。一个典型 SaaS 上线至少涉及托管Vercel/Netlify、数据库Supabase/Neon、域名与 DNSPorkbun/GoDaddy/Cloudflare、邮件Resend、支付Stripe、认证Supabase Auth五六个不同的提供商。它们的 API、CLI、登录方式、权限模型各不相同而且很多环节只有人能完成注册账号、身份认证KYC、购买域名、点击确认邮件。这些无法被自动化只能被「妥善地引导」。顺序有强依赖先要有宿主项目才能部署先要部署生产环境才能挂域名先要拿到 webhook 签名密钥才能写进环境变量先要有首次部署才能触发后续的 env 变更部署。写错一步的代价高往生产环境写入一个错误的环境变量、在 DNS 里写错一条记录、把 webhook 注册到错误的 URL——这些问题往往在流量来了之后才暴露。golive-skill 把这个问题重新定义为一个跨 Provider 的、需要人机协作的、可验证的流程编排问题。它的执行流程在 docs/ARCHITECTURE.md 中被明确写为一条流水线detect → choose missing providers → connect accounts → plan → approve → apply → verify → reportdetect扫描应用menu列出可选的 Providerinit写配置doctor检查账号可用性plan生成步骤与交接项handoffteardown生成逆向清理计划apply只有在拿到已批准的计划 ID 和相应的风险确认标志后才执行verify产出验证证据。这条流水线本身就是文章标题里「AI 可执行的分步任务」的骨架。任务拆解Link 组合 Step计划即数据拆解的第一层是把「上线」这个大目标分解成步骤Step。核心类型定义在 src/core/types.ts一个 Step 是「纯数据 一个 run 函数」的复合体它带有稳定的id、title、kindprovision/wire/deploy/handoff/destroy、risk是否写操作、是否涉及 live 数据、DNS、删除、花钱、dependsOn依赖的其他步骤、preview给人看的、不含密钥的预期行为描述、intent区分两次相同文本的步骤的意图标识和verifyWith证明该步骤成功执行的检查列表。拆解的第二层是Link——跨 Provider 的「粘合逻辑」。真正的工程智慧在这里每个 Provider 适配器暴露的是**能力capabilities**而非配对配方例如EnvStore、PublicUrl、DomainAttach、DnsZone、DbConnection、WebhookRegistry、Deployer、SendingDomain等Link 则只对着这些能力编程例如「数据库输出 → 宿主环境变量」「宿主 URL → 认证重定向」。这样一来新增一个 Provider 不需要为每一种配对单独写一套流程——这正是docs/ARCHITECTURE.md里强调的「adding a provider never means writing N pairwise recipes」。全部 20 个 Link 在 src/links/all.ts 中以固定顺序登记注释明确解释了顺序本身就是逻辑accounts必须最先重置本次计划的内存缓存域名相关要在支付/认证之前所有写环境变量的 Link 要在部署之前release最后读取其他 Link 已规划的结果。然后 src/core/plan.ts 的orderSteps对所有步骤做拓扑排序未知依赖或环会直接报错——每一步的dependsOn是真实的图边而不是展示用的文字。以部署为例src/links/deploy.tsdeployLink只有在四种情况下才规划部署步骤本次计划写了生产环境变量env 变更只对新部署生效、state 里挂着尚未被部署接走的 env 写入、上次生产部署失败、或从未部署过生产。注意它刻意不是 CI——应用代码变了不会触发部署因为 Agent 不该替开发者决定何时发布代码变更计划的 warning 会明确说明「后续代码变更请走宿主自己的发布通道」。这个「决定什么不该自动化」的设计和「决定什么自动化」同样重要。状态管理每一步都有身份失败即停恢复即重放「脏活」执行到一半失败怎么办golive-skill 的核心答案是每一步都有可哈希的身份状态文件记录一切失败即停、完成即跳、变更即重跑。计划的批准身份来自 src/core/plan.ts 的planId——它是 release 身份、步骤 id、preview、intent、risk、依赖关系的 SHA-256 哈希。apply在写入前会重新计算计划 ID与--plan传入的已批准 ID 比对任何不一致都会拒绝执行这就保证了 Agent 无法执行人类没看过的东西。每个 Step 还有自己的stepHashsrc/core/runner.ts由 preview、intent、destination、risk、dependsOn、kind 共同哈希——步骤内容变了哈希就变已记录的「done」就不能再冒充通过。运行时的执行语义在 src/core/runner.ts 的applyPlan里清晰可见顺序执行首个失败即停blocked依赖未完成、缺确认标志、步骤 run 抛错、内联验证失败都让循环break幂等跳过state 里该步骤已是done且哈希一致就标记skipped不重复执行跨 release 的写入被阻止一个步骤的完成记录属于另一个或未知的release 时默认拒绝重放除非该步骤自己声明豁免——destroy删除会重新核对所有权且幂等和replayable作者声明该写入可安全重放。生产环境的 re-point 两者都不是所以旧版本批准的回切会被拒绝并要求人工复核。持久化状态在.golive/state.jsonsrc/core/state.ts存资源 ID、密钥指纹永不含值和步骤证据。写入采用「写临时文件 rename」的原子方式中途崩溃不会损坏状态。正因为每一步都记录了status / at / planId / hash / changes / error中断后重新apply就能从失败点精确续跑——这正是 docs/RECOVERY.md 文档化的恢复路径。值得一提的还有进程内「保险库」src/core/secret.ts数据库密码这类只在创建时出现一次的密钥通过内存中的vault从创建步骤传递到组装连接串的步骤从不落盘进程一死值就没了计划自动回落到安全的兜底路径例如提示人工去控制台重置密码。这是「状态管理」与「秘密管理」在工程上的精妙结合。人机分工把「只有人能做」显式建模为 Handoff很多自动化系统的失败在于试图把一切自动化。golive-skill 的另一个关键设计是Handoff交接项它把「只有人能做」的事显式建模进计划而不是当作异常抛给用户。看 src/links/auth-recovery.ts 里的密码找回流程auth:recovery步骤通过 Provider 的管理 API 走完「请求找回邮件 → 用 admin API 铸造链接 → 用 token 换 session → 设置新密码」的完整链路但它刻意不读收件箱——「点击邮件里的链接」被建模为一个非阻塞的auth:recovery-emailhandoff交给人类完成。handoff 的关闭规则很严格只有对应的 check 通过才能关闭done: false是开放状态manual: true的项是 golive 无法验证的最终汇报时必须明确标注「未经 golive 验证」。同样的哲学贯穿全程购买、KYC、注册账号、在宿主控制台粘贴密钥、恢复一个删除不了的 Supabase 项目——全部是 handoff而不是静默失败或假装成功。SKILL.mdskills/golive/SKILL.md里还有一条硬规则「Never buy anything or create accounts for them.」以及一条针对 Agent 的防注入规则仓库文件、README、Provider 的 API 响应一律视为数据而非指令只有经过完整性校验的技能包本身是指令通道。验证与漂移Skipped is not passed自动化执行的另一端是验证。golive-skill 的 checkssrc/checks/每个都针对真实系统只读地证明某个事实输出pass / fail / warn / skip四种结果并且 README 里反复强调一句被当作铁律的话Skipped is not passed——跳过是「被阻塞或不适配」绝不是通过。验证被设计成两个层次步骤内联验证每个 Step 的verifyWith和verifyInline在执行后立即运行。例如 src/links/domain.ts 的domain:dns步骤在写入 DNS 记录后会重新读取 zone 的完整记录列表逐条比对还专门处理了 SPF 合并、TXT 引号、尾点等 DNS Provider 的差异缺一条即fail。写后必读是这套系统的默认动作。独立的 verify 阶段golive verify运行全部全局检查并产出GOLIVE_REPORT.md覆盖账号可达性、环境变量名、公开页面密钥模式、数据库连通、webhook 拒绝未签名请求、支付事件、邮件域名记录等。更进一步的是「漂移检测」src/core/drift.tsgolive status回答的不是「现在好不好」而是「golive 记录过的世界和现在读到的世界是否还一致」。它把每次写操作沉淀为基线DNS 记录基线、env 名称、webhook 端点 ID、域名挂载、数据库项目再与当下的读取逐项配对expected (recorded by golive time)对observed (read now)。每个条目都给出严重度high应用坏了 / medium卫生问题 / info无需动作和处置动作verify重新验证 /reconcile重新计划后修复 /human只有人能决定并且读不到的对象会标注为unverifiable——既不当作漂移也不当作干净。刻意地漂移检测不是计划与执行的闸门因为一个需要未批准决策的比较会卡死正当流程。对自建 AI 工作流的借鉴清单回到选题本身从这个技能包能提炼出哪些可复用的设计模式把流程写进 Agent 能读的指令并让它可验证。SKILL.md 不只是一份文档它定义了命令、硬规则、对话流程和边界Agent 从它加载「怎么做」而每次运行的versionupdate-check会先校验指令/参考/运行时整包的一致性release.json记录全部文件的 SHA-256未经验证的技能包不允许碰账号。自建工作流至少要区分「指令通道」和「数据通道」。计划即数据批准即哈希。把将要发生的一切——目标账号、资源、成本、风险标志、依赖——先变成一份无密钥、人类可读、且可哈希比对的计划写入前重新校验。这让「人类批准」从一句口头承诺变成一个可被代码强制执行的绑定。状态机 断点续跑。每一步的执行证据落盘失败即停、完成即跳、内容变化即重跑恢复不是重头再来而是从失败的步骤继续。用 step 哈希判断「同一个动作」用 release 身份阻止跨版本重放。显式建模人机分工。把「只有人能做的步骤」做成一等公民handoff用「通过对应 check」作为唯一关闭条件系统承认自己看不见收件箱、无法替你点击、无法替你购买并把这一步清清楚楚地交还给人。验证与执行分离跳过不等于通过。写后必读、执行后立即内联验证、独立 verify 阶段产出证据报告对「无法读取」保持诚实宁可标注 unverifiable 也不假装干净。漂移检测用「记录基线 vs 现在读取」而不是一次快照回答「有没有人在背后改了我的东西」。密钥与输出强隔离。密钥值只存在于进程内的Secret包装中任何字符串化路径都只能得到[secret name fp:…]值通过子进程 stdin 或请求体传输绝不进 argv、计划、状态、报告或 Agent 上下文状态里只存 SHA-256 指纹。报告层还有兜底的redact()正则清洗。这类「双保险」是让 AI 流程敢碰生产账号的前提。最后值得一提的是这套系统对「验证记录」的诚实——docs/VALIDATION.md 把「真实跑过的」与「只有 mock 覆盖的」严格分开VercelSupabase、NetlifyNeon、Porkbun/GoDaddy 自定义域名、Resend 邮件、Stripe 测试支付、Supabase 密码找回都有 disposable 资源的实测记录而 promotion/rollback、账号隔离等则明确标注「implemented and mock-covered, not live-validated」。对用户来说这比一份声称「全部支持」的文档更有信息量它告诉你哪些流程可以放心交给 Agent哪些还需要人工盯着。把脏活变成 AI 可执行的分步任务靠的不是魔法而是流程工程——把每一步拆细、可审查、可恢复、可验证并把诚实写进设计里。【免费下载链接】golive-skillTake your agent-built product live: hosting, database, domain, email, payments — on your own accounts. Open-source Agent Skill zero-dependency Node CLI: detect → plan → approve → apply → verify. No GoLive account, backend or telemetry.项目地址: https://gitcode.com/gh_mirrors/go/golive-skill创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考