← → 翻页 · B 静态 · ESC 索引
FEISHU · PRODUCT ARTIFACTS
SWISS · IKB · 01 / 13
FIELD NOTE · 产物管理系统

把产物交给
正确的系统

基于飞书的产物管理工作流:从需求澄清、规格、拆票,到实现、验证与收口。
SOURCE · 基于飞书的产物管理工作流.md
→ swipe / arrow keys
01 · THE PREMISE
02 / 13
THE PREMISE · 先分工,再协作

不是把事情搬进 Base。
而是让每个系统只管一段。

工作流的核心不是增加一个工具,而是建立清晰的事实源、状态轴、执行上下文与验证证据。
02 · FACT SOURCES
03 / 13
FACT SOURCES · 四个系统,四种职责

同一件工作,不同的事实源

把“长文”“状态”“执行”“实现”分开保存,协作才不会靠记忆和复制粘贴维持。

规则:Base 管状态和关系;Wiki 管长文;Trellis 管上下文;代码仓库管实现事实。
REPO · 实现事实
WIKI · 长文
BASE · 状态
Trellis · 上下文
WIKI
Spec / Map / 研究 / 决策
BASE
身份 / 状态 / 关系 / 摘要
REPO
代码 / 测试 / ADR / 证据
03 · OPERATING FACTS
04 / 13
OPERATING FACTS · 当前版本的六个边界

先记住这六件事

01
不建 Issue

需求先在对话、研究、原型中澄清。

02
24 个字段

Base 只保留可查询、可关联的契约。

03
6 个状态

只保留一个状态轴,不维护工作流阶段。

04
先 Wiki,后 Base

长文回查完整后,才创建 Base 记录。

05
真实 ID 关系

父子项和依赖都使用 record ID 回写。

06
每次写入都回查

不能只看 ok: true 就宣称成功。

04 · THREE LAYERS
05 / 13
THREE LAYERS · 一条工作,三层事实

长文、队列、执行

LAYER 01 · WHY / WHAT
Wiki / Docx
保存 Engineering Spec、Map、研究、决策与长篇说明。
可读的正式产物
LAYER 02 · WHO / NEXT
飞书 Base
保存 Spec/Ticket 身份、状态、负责人、关系与证据摘要。
可查询的工作队列
LAYER 03 · HOW / PROOF
Trellis + Repo
保存执行上下文、计划、多会话证据、代码、测试与 ADR。
可验证的实现事实
ONE FLOW · THREE SOURCES · NO SILENT DUPLICATION
05 · THE FLOW
06 / 13
THE FLOW · 从澄清到收口

一条可回查的生产线

01Setup身份、Base、Wiki、项目
02Clarify目标、约束、验收
03To Spec先 Wiki,后 Base
04To Tickets垂直切片与依赖
05—07Start → Build → Close认领、实现、证据、人审
HITL 在关键节点拍板,AFK 负责确认后的重复执行。
06 · THE SHIFT
07 / 13
THE SHIFT · 从副本链到事实链

工作流改变的不是工具,是信息流

BEFORE副本链
Issue → Triage → Brief
需求先进入 Base,再被分诊、转译、复制到多个上下文。
  • Issue 变成第二份 Spec
  • 状态轴越来越多
  • Agent Brief 与 Human Brief 分裂
AFTER事实链
Clarify → Spec → Evidence
需求先完成澄清,再让 Wiki、Base、Trellis、Repo 各自保存一段事实。
  • 没有 Issue 进入 Base
  • 只有一个状态轴
  • 每次写入都回查证据
07 · HUMAN GATES
08 / 13
HUMAN GATES · HITL 不是阻力,是边界

人在三个地方拍板

HITL
确认
再执行
Agent 可以加速重复动作,但不能替人决定正式产物的边界。
01
需求澄清

目标、范围、约束、验收,决定是否继续交付。

02
拆票与依赖

确认垂直切片粒度、父子关系和阻塞边。

03
收口确认

人工确认代码/功能评审完成,并选择允许关闭的记录。

08 · EXECUTION LOOP
09 / 13
EXECUTION LOOP · Start → Inline / Trellis → Close

执行不是直线,是一条可恢复的闭环

01
认领
冻结 record ID 与最新快照,状态改为进行中。
02
执行
范围窄走 Inline;跨模块、多会话走 Trellis。
03
取证
代码、测试、命令结果、快照和回查事实一起整理。
04
收口
Ticket 和 Spec 分两次确认,不把 finish 当成完成。
LOOP
可恢复
状态、上下文、证据持续刷新
09 · HARD NUMBERS
10 / 13
HARD NUMBERS · 规则已经被压缩成几个数字

少一点状态,多一点可验证性

FIELD CONTRACT
一套字段契约

Base 当前保留 24 个字段,所有关系都能被查询和回查。

24
STATE AXIS
一个状态轴

只允许 6 个状态:ready-for-agent、进行中、阻塞、待评审、已完成、wontfix。

6
EXECUTION BINDING
一个 Spec,一个 task

Trellis 只保存执行上下文,不成为第二份业务 Spec。

1:1
10 · RUNTIME BOUNDARIES
11 / 13
RUNTIME BOUNDARIES · 不靠“看起来对”

四条不能越过的线

— 01 / ID
稳定 ID

不用标题更新记录,始终使用真实 record ID。

— 02 / SOURCE
不猜坐标

Base、table、view、Wiki 节点都来自项目契约。

— 03 / VERIFY
写入回查

未知 JSON 不是空结果,ok: true 也不是完成证据。

— 04 / HUMAN
人工门禁

测试通过、评审通过、归档,都不能自动关闭飞书记录。

11 · CLOSURE LEDGER
12 / 13
CLOSURE LEDGER · 收口不是一句“完成”

最终状态,需要一串证据

24
字段契约
身份、状态、关系、验收、验证证据都可追溯。
6
状态轴
只有已完成能满足依赖,wontfix 不是交付证明。
1:1
Spec / Trellis
一个飞书 Spec 绑定一个 Trellis task,Ticket 只是其计划单元。
2×
人工确认
Ticket 关闭一次,Spec 最终关闭再确认一次。
0
自动关闭
没有自动关闭。证据不足时,记录保留原状并给出下一步。
FEISHU · WORKFLOW
CLOSING
MANIFESTO

让事实
自己流动。

当每个系统只保存它应该保存的事实,协作就不再依赖复制、猜测和记忆。
13 PAGES · IKB
END OF FIELD NOTE
TAKEAWAYS
13 / 13
01

Wiki 保存长文

完整 Spec、Map、研究与决策,保持可读。

02

Base 保存状态

身份、关系、进度和下一步,保持可查询。

03

证据决定完成

没有直接验证证据,就记录未运行和下一步。

→ 完 · END OF FIELD NOTE