文档版本:v1.2 最后更新:2026-04-07 10:32:36
当前项目已经进入前后端联调和多产品线并行阶段,并且存在多条并行工作线程:
这份文档用于明确三条线程如何协作、各自负责什么,以及如何通过共享文档同步事实,而不是靠口头记忆维持项目状态。
当前采用的是:
对应关系:
当前跨线程沟通主线改为 6 份文件:
旧的:
默认不再作为主线协作文档继续扩写,只保留历史参考价值。
t2b.md由总控线程维护,写给后端线程,用于记录:
b2t.md由后端线程维护,写给总控线程,用于记录:
t2f.md由总控线程维护,写给前端线程,用于记录:
f2t.md由前端线程维护,写给总控线程,用于记录:
t2w.md由总控线程维护,写给网站线程,用于记录:
w2t.md由网站线程维护,写给总控线程,用于记录:
为了避免两份协作文档再次变成长讨论稿,当前约定两边都采用统一结构:
待确认已确认阻塞已完成下一步并且每条尽量固定包含:
这样做的目的不是增加格式负担,而是保证:
总控线程不替代前后端线程,而是负责:
总控线程至少持续关注:
以及当前代码事实:
miniprogram/backend/tools/mock-gps-sim/总控线程不应该:
总控线程只维护:
总控线程需要持续做两件事:
也就是说,总控线程不是“第三份协作文档”,而是:
当前建议三条线程按下面这条链协作:
前端/后端各自推进
-> 总控通过 t2b / t2f 下发阶段性要求
-> 前后端通过 b2t / f2t 回写事实与阻塞
-> 总控线程读取四份协作文档
-> 判断是否需要:
- 调整主线优先级
- 更新正式方案文档
- 修正索引与阶段总结
-> 再继续推进代码
也就是说:
t2b / b2t / t2f / f2t 是协作事实层doc/ 是正式知识层为了避免信息再次散掉,建议始终遵守下面的分层:
位于仓库根目录:
特点:
位于 doc/:
特点:
最终行为以代码和线上配置为准。
如果出现:
优先级应该是:
代码 / 运行结果
> 正式文档
> 协作文档
然后由总控线程负责把文档补齐。
这个项目已经同时存在多条主线:
如果所有讨论都只堆在一个线程里,会出现:
采用当前这种方式的好处是:
优先维护:
并把当前事实、阻塞和待确认事项回写到 f2t.md。
优先维护:
并把当前事实、完成项和待确认事项回写到 b2t.md。
优先维护:
当前项目的协作方式正式定为:
总控线程通过 t2b.md / t2f.md 下发阶段要求,前后端线程通过 b2t.md / f2t.md 回写事实,总控线程再维护全局主线、正式文档和阶段结论。
这样做的目标不是增加文书工作,而是:
截至当前阶段,这套方式已经进入实际执行状态:
后续如果线程数量增加,或者联调链变复杂,优先仍然是:
而不是先把协作体系做复杂。