CSF

版本: v0.3 | 最后修订: 2026-07-06 | 项目: csf-core 🛡️ 规则语义变更须经Owner确认并全程记入日志。关键词: [FLDD, 开发执行, 主题包, 业务切片, BT, IT, DT, STB, DP, 验收, 信息隔离, 三栏自检, 修改自证, 验收三档, 沉淀级别] 适用场景: SP5 产品开发阶段全程

FLDD 开发执行

FLDD = Frontline Design & Development（一线设计与开发）。本文件是 SP5 产品开发阶段的方法论规程。FLDD 全程挂载为基础共识。

§ 0 核心设计思想

FLDD 阶段的核心问题：如何让开发者拿到刚好够用的、准确的材料，既不过载也不缺失。

解决方案 = 信息隔离 + 逐步投喂：

主题包的设计目的：将早期 domain + arch 阶段的大量原始资料，提炼为 FLDD 可直接消费的设计契约。开发者不碰 domain/、不碰 arch/——只读参谋长从主题包中准备好的材料。
业务切片的设计目的：从业务角度横向串联多个主题包，让参谋长和开发者理解业务上下文。同时作为主题包的质量校验维度。

五概念切分的核心目的：既给够又不给多。逐步迭代，保证开发输出无脑补无概念漂移，或漂移能及时发现和纠正。

缩写	全称	是什么
BT	Business Topic（业务主题）	业务边界单元。1 BT ≈ 1 个主题包，在早期需求分析与设计阶段（HQPD）产出，是所有下游工作的锚点
IT	Iteration Task（迭代任务）	同一 BT 的多次开发切片——把大主题包拆成”先做什么、后做什么”的多轮开发
DT	Dev Task（开发任务）	微观开发目标。用业务语言定义要完成什么能力，不涉及具体文件/行号
STB	Session Task Book（会话任务书）	开发者单次会话的工作输入——把 DT 翻译为”改哪些文件、怎么改、怎么验收”。对外概念阐述中亦称 Simple Task Brief
DP	Dev Plan（开发计划）	元层规划。调度全部 BT×IT×DT×STB 的跟踪/调度/验收框架。落地为 context-开发者.md §B 进度表

概念使用要点（在 FLDD 各环节中正确使用这些概念的关键）：

BT 是锚，不是变量：BT 生命周期稳定，不随开发推进而变。BT 内部分解为多个 IT，但 BT 本身的边界不因迭代而调整。
IT 是迭代切片，不是版本号：IT 回答”同一个 BT 先做什么、后做什么”。不要把它当作大版本号——它是能力递进的切分单位。1 BT → N IT，切分由参谋长决定。
DT 停留在业务语言层：DT 用业务语言定义要完成什么能力，不涉及具体文件/行号。那条线在 STB 才跨过——STB 把”做什么业务能力”翻译为”改哪些文件、怎么验收”。
STB 的弹性映射：1 个 STB 可以对应 1 个会话（形态 α），也可以跨 N 个会话（形态 β），也可以 N 个 STB 共同完成 1 个 DT（形态 γ）。实操默认 α 起手——一个 STB 一个会话。
DP 是元层，横跨所有维度：DP 不直接对应某个具体开发活动。它回答”所有 BT/IT/DT/STB 各自到了什么状态”。落地为 context-开发者.md §B 进度表——开发者每次会话开局扫表取活。
两套体系的 IT/STB 同名异义：项目管理线（GP→TP→IT→STB）和业务开发线（BT→IT→DT→STB+DP）交汇于 IT 和 STB，但语义不同。详见下方 §2 层级对应的两套体系说明。

信息流规则：

doc/domain/ + doc/arch/ → [参谋长加工] → doc/themes/ + doc/slices/ → [参谋长准备] → STB → 开发者
                                                                                   ↑
                                   开发者只读这里，不读上游 ←───────────────────────────┘

为什么这样设计：

避免开发者信息过载（超出会话上下文窗口）
避免乱读原始资料导致信息污染
避免开发者脑补设计（所有设计决策已在主题包中落定）

§ 1 输入与信息边界

FLDD 的唯一输入源

主题包（如 doc/themes/）— 每个含 package.md（设计契约）+ sources.md + verify.md。三件套的格式规范见 FLDD-主题包-创建指南.md。
业务切片（如 doc/slices/）— 业务维度的横向串联

禁止直接消费的上游

❌ doc/domain/（业务规则原始定义）— 参谋长可读，开发者不读
❌ doc/arch/（架构设计）— 参谋长可读，开发者不读

参谋长为开发者准备的所有材料，只能来源于主题包和业务切片。 如果 STB 中需要某个业务规则，参谋长从主题包中摘取相关段落放入 STB，而不是让开发者去读 domain/。

不一致发现与修复

如果任何角色在 FLDD 过程中发现主题包与业务切片之间的不一致或错误：

不在当前开发任务中顺手修
参谋长单独起修复任务（可以是一个轻量 ad-hoc 会话）去核查和修改
修复完成后再回到开发任务继续

§ 2 层级对应（任务窗口视角）

GP 全景图 — 所有 TP 队列（≈ 产品 roadmap）
│
├─ TP = Topic Plan（主题计划：一个主题包的开发，如 TP-01 = TA-01）
│       或 Temporary Plan（临时计划：打岔处理某事后回归主线，如 TP-332）
│   │
│   │  TP README 中写明：
│   │  · 目的（业务上做什么）
│   │  · IT 分解（分几步做完）
│   │  · 每个 IT 对应什么业务能力
│   │
│   ├─ IT-1 = 第一轮切片（如"getAuthToken 端到端"）
│   │   └─ STB = 开发者单次会话的输入（修改哪些文件、达到什么效果）
│   │
│   ├─ IT-2 = 第二轮切片（如"initSystem + 用户档案"）
│   │   └─ STB
│   │
│   └─ IT-N → TP 闭合
│
├─ 下一个 TP ...

两套体系说明：CSF 中存在两套独立的概念体系，它们在 IT 和 STB 上有交集，但语境不同：

项目管理线（GP→TP→IT→STB）：全景图视角。GP = 项目整体，TP = 开发某个业务主题（BT）的项目计划，IT = TP 的分解步，STB = 开发者的会话输入。用于跟踪进度、滑动红点。

业务开发线（BT→IT→DT→STB+DP）：信息流视角。BT = 业务边界（≈主题包），IT = BT 内的迭代切片，DT = 微观开发任务，STB = DT 的具体化落地，DP = 元层调度。用于控制信息粒度、确保”既给够又不给多”。

两条线交汇于 IT 和 STB，但语义不同：项目管理中的 IT 回答”TP 分几步做”，业务开发中的 IT 回答”BT 按什么能力递进切分”。理解这个区别是正确使用 FLDD 的前提。

Owner 视角的对应：

“现在在做什么产品功能” → 看 context §B 定位段（当前 TP）
“这个功能分几步做” → 看 TP README 的 IT 分解表
“每步对应什么业务” → IT 分解表中每行用业务语言描述
“做到哪了” → context §C（上次结论）

§ 3 参谋长工作流

TP 立项

真读主题包 package.md（设计契约权威）
真读相关业务切片（业务上下文 + 与主题包交叉校验）
一致性 checklist（☐ 全通过才继续）：
- ☐ 主题包与业务切片之间无矛盾/遗漏（含横切机制切片，不只是直接对应切片）
- ☐ 主题包契约层术语与 doc/domain/ 一致
- ☐ 上游 TP 的接口输出 = 本 TP 假设的输入
- ☐ 本主题包是否有前置约束切片（设计前必须精读）
真读 dev/ 中上游 TP 已完成的代码（确认起点）
写 TP README：目的 / IT 分解 / 资源 / 防御
Owner 校验业务方向（用自然语言 brief，Owner 判断方向对不对）

一致性检查发现问题 → 先修后立项。不带着疑问往下走。

IT 设计（出 STB）

一致性 checklist（每次 IT/STB 必过）：

☐ 本轮涉及的主题包段落与业务切片一致（含横切机制切片，不只是直接对应切片）
☐ STB 中引用的业务术语 = 主题包契约层定义（L1 自检）
☐ 发现潜在错误 → 已报 Owner + 起修复任务
☐ 自 TP 立项以来是否有新增切片 → 有则补扫，检查本 IT 是否受影响

DP 四问（可以一段话答完，不必单独建文件）：

做什么：本轮切片的业务范围
为什么：为什么先做这个
怎么切：一个 STB 能装下吗（α1:1）还是要拆（β1:N）
吃得下吗：预算自评

STB 核心四件：

修改范围：本次可改的文件清单（范围外动代码 = 开发者必须 PENDING，不可直接改）
参考范围：本次只读的文件清单（只来自主题包 + 业务切片 + 已有代码，不引 domain/arch）
DT 清单：每个任务点一行（用业务语言 + 技术落点）+ 每条标沉淀级别（🔵TASK / 🟢PACK / 🟣FLDD）
验收断言：每个 DT 标明验收档位（🟢强/🔵中/🟡弱）和具体断言文字

任务下发

参谋长将 STB 写入开发者进度表（追加一行，内容列嵌入 STB 文件链接，设计列标 ✅）+ assign 到 §收件箱通知（通知有新任务入队，非发令枪）。

开发者不需等 assign 才可动手——每次会话开局扫进度表即可取活（取活规则详见 context-开发者.md §B）。assign 的价值 = 通知“有新 STB 入队”，不是“允许开始”。

一个 IT 拆多个 STB 时，参谋长尽可能一次性设计多个 STB 并全部写入进度表（每个 STB 一行）。如果 STB-2 确实依赖 STB-1 产出才能设计 → 设计列标「⬜ 待STB」，开发者扫表时自然跳过。

STB 设计完成后直接写入进度表 + brief Owner。不制造审批关卡。Owner 在回合中自然回应（确认/纠偏）。

已知平台约束（示例）🟣FLDD

以下为示例，展示平台约束声明的格式。实际项目替换为当前平台的约束。

以下约束在设计 STB 时必须主动识别，不可在实现后才发现兜不住：

约束	说明	影响范围
`open-type="share"` 无法做 L1 弹窗拦截	微信小程序中该按钮点击后直接唤起系统分享面板，bindtap 在分享动作前不执行，无法插入 JS 弹窗逻辑。业务上需要「状态判断→弹窗提示→阻断分享」的场景，不能用 `open-type="share"`；必须改用普通按钮 + bindtap 自行处理分享调用（`wx.showShareMenu` / `wx.shareFileMessage` 等）。CF 层虽可拒绝 recordForward，但卡片已发出，用户体验差。	任何转发/分享类按钮，尤其涉及 closed/expired 等状态门控时

§ 4 开发者工作流

信息边界

开发者的全部信息来源 = STB + STB 中引用的主题包段落 + 已有代码。不读 domain/、不读 arch/、不读其他主题包。发现 STB 材料不够用 → PENDING 回参谋长要，不自行去找。

承接：三栏自检（收到 STB 后先不动键盘）

栏	内容
✅ 已读懂	STB 里我能直接动手的部分
🟡 不确定	我读出歧义 / 多解 / 缺料的点
🔵 准备假设	我打算按 X 假设处理，请校验

任一 🟡/🔵 非空 → 不动键盘，发 PENDING 回参谋长。三栏仅 ✅ 非空才进入编码。

开发者侧有更详细的承接执行表单（含沉淀标签核查、大图理解、文件范围确认），见 dev-context §A 三问承接。三栏自检是原则，三问承接是执行表单。

编码纪律

① 范围契约：每一行修改必须能直接追溯到 STB 的某个 DT。范围外动代码（包括调格式、改 import、修 typo、删”看起来无用”的代码）= 立 PENDING，不直接改。

② 等价检验：若新代码体量 > 旧等价代码 2 倍 → 停下在 devlog 中写明：为什么不能复用/改既有/为什么必须新写？参谋长校验后才继续。

③ 发现不一致：编码中发现主题包描述与实际情况矛盾 → 停下 PENDING 报参谋长，不自行解释或假设。

收尾：修改自证清单（每会话收尾必出）

本会话 diff 统计：A 文件 +N/-M、B 文件 +N/-M

逐改追溯：
  A:line XX-YY  ← STB DT #N「任务点描述」
  B:line XX     ← DT #M 副作用：补 import

✅ 范围外动：0 处
🟡 范围内但非计划：N 处
   - 文件:行号 描述（不属 STB DT，已说明原因）
   - 建议：保留 / 撤回 / 单独立 STB

铁律：自证清单未出 = 不予验收 = 任务不算完成。

验收三档产出（开发者按 STB 标注的档位提供）

档	形式	自证形式
🟢 强档	单元测试 / 接口断言脚本	测试输出片段粘贴
🔵 中档	数据库查询 / CF 调用响应 / console 输出	响应 JSON / 查询结果粘贴
🟡 弱档	操作步骤 + 预期屏幕表现	截图 + 操作步骤 + 实际表现对照

三档可混用（同一 STB 不同 DT 各档独立）。零新增工具 / 零基础设施成本。

沉淀级别（开发者须识别）

STB 中每条约定/惯例已由参谋长标注沉淀级别：

标签	含义	开发者行为
🔵 TASK	本任务特例，下任务作废	仅本次遵守
🟢 PACK	本主题包惯例，该包下所有 STB 继承	后续同包任务继续遵守
🟣 FLDD	FLDD 通用纪律，全阶段继承	所有任务必须遵守

开发者三栏自检时核标签是否齐全，缺标 = PENDING 回退。

§ 5 验收

参谋长验收（技术层）

步骤	操作	要点
① 读自证清单	看「✅ 范围外动：0 处」是否成立	自证清单未出 = 退回
② 抽查映射	随机抽 1-2 行 diff，反查清单是否对得上 STB DT	不匹配 = 退回
③ 看 🟡 段落	「范围内但非计划」每项判断留/撤/立新 STB	—
④ 验收三档核验	每个 DT 的产出是否达到标注档位	—
⑤ 通过/退回	通过 → 关任务；退回 → 开发者补充	—

Owner 验收（业务层）

IT 闭合时参谋长用自然语言向 Owner 描述”这轮做了什么业务能力”，Owner 判断是否符合预期。有 UI 产出的，Owner 可直接操作验证。

Owner 不需要看代码、不需要看 STB——只看业务结果。

验收后流转

验收 ACCEPTED 后：

参谋长判断沉淀级别（见 §7）
参谋长启动下一个 IT 设计（或判断 TP 闭合）
参谋长将新 STB 写入开发者进度表（追加一行 + 更新当前任务指针）
TP 闭合时更新 GP 全景图（context §B 定位段）标记 ✅ + 滑动红点

§ 6 开发者的全局视角

开发者需要知道自己”在干什么产品的什么部分”。

实现方式：context-开发者 §B 注入时，附带一段（≤5行）：

产品一句话（{产品名} 是什么）
当前 TP 在全局中的位置（如”TP-04 是小程序壳，所有用户从这里进入”）
上游已完成了什么（如”启动认证+访问控制已就位”）

不需要读 arch 七件套。不需要理解全局架构。只需要知道自己的工作落在产品的什么位置。

§ 7 沉淀

IT 验收 ACCEPTED 后，参谋长判断本轮经验的沉淀级别：

🔵 TASK：本次特例，不沉淀
🟢 PACK：写入 TP README §主题包惯例
🟣 FLDD：升库到本文件或开发者-instructions

TP 闭合时，更新 GP 全景图（context §B 定位段）标记 ✅。

§ 8 context-开发者 §B 注入模板

参谋长在窗口初始化或追加新 STB 时维护 context-开发者 §B 的标准格式：

### 定位

- **产品**：{产品名} — [一句话描述]
- **当前阶段**：SP5 FLDD 开发执行
- **上游已完成**：[简列已完成 TP]

### 进度表

| # | STB | TP | 状态 | 依赖 |
|---|---|---|---|---|
| 1 | [路径] | TP-NN 主题 | 🔴 当前 | — |
| 2 | [路径] | TP-NN 主题 | ⬜ 排队 | #1 |

> 🔴 = 当前执行中 / ✅ = 已完成验收 / ⬜ = 排队待执行

### 当前任务

→ **[STB 文件名](路径)**

三元组（目的/方法/资源/DT清单/验收断言）全部在 STB 文件中。开局时精读该文件 = 任务加载完成。

### SP 通用资源（每个任务共享）

- `doc/arch/design-tokens.md` — token 字典（示例）
- `doc/arch/插件简明索引.md` — 插件清单（示例）
- [其他 SP 级共享资源]

### 活跃防御（FLDD 级 / 全任务继承）

1. 范围外动代码 = PENDING（FLDD §4 范围契约）🟣FLDD
2. 发现不一致 = 停下报告（不自行假设）🟣FLDD
3. 全量 token 引用：wxss 禁硬编码颜色/px 字号 🟣FLDD
4. [其他 FLDD 级防御]

> 任务特有的防御条目写在 STB 文件内。

### 备忘

（初始为空）

与旧模板的关键区别：

三元组不在 context 中展开 → 指针到 STB 文件（开发者精读 STB = 加载三元组）
进度表队列式 → 参谋长可一次排入多个已设计完的 STB
活跃防御分层 → FLDD 级（context 中继承）+ 任务级（STB 中）
开发者做完一个 → 标 ✅ → 红点滑到下一个 → 下次会话自动承接

§ 9 业务自检嵌入点

业务自检不是独立流程，而是嵌入在 FLDD 各环节中的强制动作：

环节	自检动作	责任人
TP 立项	§3 一致性 checklist 3 项	参谋长
IT 设计	§3 一致性 checklist 3 项 + L1 术语自检	参谋长
开发中	发现不一致 → PENDING	开发者
参谋长验收	技术层 5 步（§5）	参谋长
IT 闭合	Owner 业务层验收	Owner
收尾后	参谋长问 Owner「是否需要业务映照自述」（L2）	参谋长发起，Owner 决定

L2 业务映照自述（收尾时触发）：

口语化段落，业务语言转述本会话交付物在业务上做了什么
限制在分包内、不补做契约层校验
Owner 说「要」才做，「不」则跳过

L3 他检（Owner 主动启动，频率极低）：

L2 自述暴露可疑信号时 Owner 要求深度业务校验
参谋长需读 domain/ + arch/ + 多个主题包才能回答
输出可能触发主题包重切

This site is open source. Improve this page.