“这个表到底由哪个模块负责？”
Agent 搜索 416 个 API、796 个文件，然后在相似的旧实现里做出猜测。
search
search
search
search
search
多端AI 客户端
按需接入 Flow2Spec
按需接入 Flow2Spec
1 库共享知识层
.Knowledge/
.Knowledge/
先读每次变更先定位事实
再开始写代码
再开始写代码
The context problem
AI 很会写。
但它总要重新猜一遍。
项目里的约束散落在代码、文档、聊天记录和某个人的记忆里。新会话从零开始，搜索越多，误读和漂移越容易发生。
“命中 m-product-review-template-library。”
先读取已验证的主题事实，再打开真正需要修改的文件。
✓ matcher hit
One small layer, four jobs
四层结构，
把上下文变成基础设施。
每一层只做一件事，组合起来却能让团队的 AI 协作拥有连续性。
Knowledge
项目事实的共享底座：API、边界、数据规则、工作流。
.Knowledge/topics/*.mdTask
每个开发者自己的进度、上下文和用户代办。
.task/<developerId>/Rules
让不同 agent 遵守同一套入口、门禁和交付规则。
AGENTS.md · .codex/Skills
把澄清、实现、修复、同步和提交变成可复用的工作流。
f2s-*Progressive routing
从一句话，到
一小块可验证的上下文。
不是把整个仓库塞进模型，而是先匹配，再展开依赖，最后只读取与当前任务有关的事实。
01一句需求自然语言描述
02命中主题匹配器 + 依赖展开
03读取事实只读真正相关的上下文
04实现并回写代码与知识保持一致
✦
上下文不是越多越好。
它应该刚好够用，并且下一次还能被复用。
A living development loop
每一次交付，
都让下一次更快。
知识库不是一次性文档工程。它随着真实开发被验证、被修订，再被下一次请求准确命中。
- 01描述需求用自然语言说清要改变什么。
- 02读取相关事实路由主题，展开依赖，补齐缺口。
- 03实现并回写代码和知识在同一条工作流里收口。
LC
Q7
shared knowledgetopic revision +1reviewed and merged
Built for shared repositories
两个人，
一份知识库。
任务进度按开发者隔离，确认后的项目事实留在共享的 `.Knowledge/`。并行开发不会把个人待办混进产品知识。
了解团队协作A calmer first run
三分钟，
让项目有章可循。
不用先整理完整知识库。先初始化，再用一次真实需求让它长出第一条可验证事实。
01写入协作骨架
初始化
npm i -g @double-coding/flow2spec && flow2spec init为项目写入知识库、规则和已选择客户端的入口。
会得到.Knowledge/ · AGENTS.md
02让需求进入路由
描述第一个需求
“给订单查询增加分页，先找相关事实。”
从真实模块或变更开始，按需建立主题事实，不必一次写完所有文档。
会得到命中主题 · 补齐上下文
03把结果留下来
验证并持续交付
事实已验证下一次请求可以直接复用
确认路由、主题和 revision 都健康，让这次验证过的事实成为下一次工作的捷径。
会得到可复用的项目记忆
Keep exploring
从这里，继续阅读。
从安装到协作，选择下一步要了解的内容。