01
产物散落，上下文易丢
AI 擅长生成代码，却缺少从需求到验收的完整交付约束。PRD、方案、测试、发布材料散落各处，任务经常停在“看似完成”。
交付不闭环
Flowness 是面向 AI 研发的交付生命周期运行时。把需求、构建、验证、发布、验收 固化为可安装、可恢复、可校验的流程协议，让不同 Agent 在统一状态、产物与门禁下协作。
今天，团队每天都在发生这样一幕 ——
测试没跑、证据没留、审批被跳过、上下文丢了、回滚方案没人写—— 任务却已经停在了“看似完成”。
不是模型不够强，而是从需求到验收的整条链路，缺少统一、可校验的约束。
AI 擅长生成代码，却缺少从需求到验收的完整交付约束。PRD、方案、测试、发布材料散落各处，任务经常停在“看似完成”。
Claude Code、Codex、Cursor、OpenCode 的入口与资产形态各不相同。团队切换工具时要重复配置，流程和项目规则难以沉淀复用。
Agent 的“已完成”缺少统一证据和机器门禁。测试、人工审批、发布与回滚检查可能被跳过；出问题后也难以追溯与恢复。
真正缺的不是更强的模型，而是一条可核验的“交付轨道”： 让每一次 AI 交付都有明确的输入、输出、证据和门禁，让“完成”从一句口头结论， 变成一个能被机器检查、能被人复核、能被回滚的工程状态。
“我觉得做完了”
口头结论 · 不可核验“门禁通过了”
工程状态 · 可核验 · 可回滚产品由三层组成——安装即用，协议约束状态，产物沉淀证据。节点内部自由，节点边界严格受控。
通过 npm CLI 一次初始化或更新目标项目，按 Agent 自动生成 commands、skills、rules 等原生入口。
flowness.yaml 定义生命周期图、输入输出、证据与门禁；.flowness/progress.yaml 记录唯一运行状态。
每次迭代在 flowness/iter-*/ 下沉淀 PRD、方案、变更、测试、风险、发布、回滚与验收材料。
以状态机统一推进；只有产物、证据、Schema 与人工审批满足要求，才能进入下一节点，并支持中断恢复与失败重跑。
用 flowness.yaml 声明节点图、输入输出、证据和门禁，实现“节点内方法自由，节点边界严格受控”。
状态机统一推进 define→build→verify→release→close；产物、证据、Schema、人工审批全通过才放行，支持中断恢复与失败重跑。
一次初始化即为 Claude Code、Codex、Cursor、OpenCode 安装各自原生入口；外部 Skills、OpenSpec 只作节点内方法复用，不取代状态权威。
Agent 是入口，CLI 负责安装管理，Flowkit 运行时是唯一的状态与门禁权威，Provider 只提供节点内方法。
下面是 Flowness 控制台。以“会员权益改版 1.0”为例，看门禁如何拦住一次“看似完成”的交付。推荐用「演示导览」——一条剧本走完，边讲边演，评委一眼看懂每个功能在解决什么问题、带来什么价值。
产品把“完成”变成一件可以被检查的事：门禁没过，就进不了下一步—— 这正是 AI 交付最需要的那条底线。
统一多 Agent 的流程和资产，降低新项目接入、工具迁移与重复配置成本。
强制沉淀需求、变更、测试、风险、发布与验收证据，降低漏项、越级与返工风险。
形成可审计、可复盘、可度量的数据基础，让“完成”第一次变得可衡量。
当前已完成四类 Agent 适配与真实业务分支全生命周期内部验收。试用阶段建议以接入耗时、 门禁一次通过率、返工次数、缺陷逃逸率和交付周期验证收益，不虚报尚未在线上采集的数据。
AI 会写代码，我们让它完成交付。