Sync: Systemic Reader Feedback Intake
- 日期：2026-05-14
- 来源材料：用户附件
check-qa.md - 证据入口：附件以
projects/finclaw/阅读路径为载体 - 实际问题范围：当前整个治理仓库和知识库的文档体系、读者路径、Agent 路由、约束承接和验收闭环
- 材料规模：596 行；附件自述阅读对象总量 2800+ 行
- 当前状态：已吸收到 Batch 8A feedback-root-cause register；作为全仓库共性问题的原始证据样本；未声明全部解决
1. 触发背景
Batch 8A 原结论是：仓库中缺少一份独立的逐人逐条原始反馈清单，因此“团队成员重构前反馈问题及根因逐条解决”不能被标记为 satisfied。
用户在 2026-05-14 提供 check-qa.md 作为原始团队反馈材料。该材料虽然以 FinClaw 文档阅读路径呈现，但它不是“单个成员感受”、不是“单份文档问题”、也不是“FinClaw 项目局部问题”。它暴露的是本次重构启动前已经分析过的系统性根因：整个治理仓库和知识库普遍存在的高抽象、低叙事、入口和受众错位、Agent-first 路由、人类阅读路径不足、自然语言约束难以执行、文档进展被误认为项目进展、以及实施 / 验收接力断层。
因此，本 intake 改变 Batch 8A 的 source 状态：
- 从“未发现原始材料”改为“已有一份可追溯的原始反馈证据样本”；
- 仍不能改为“全部团队反馈已补齐”；
- 不得把证据入口收窄为 FinClaw 局部问题；
- 必须把 FR-011 到 FR-018 作为 Batch 8B 生态层逐篇 audit 和 Batch 8C 项目层 audit 的通用检查维度。
2. 原始反馈主线
附件按 Q1-Q10 展开，反馈主线如下：
| Q | 核心反馈 | 影响范围 |
|---|---|---|
| Q2 | 文档读起来困难：结论堆叠、抽象词密度高、同义反复、缺视觉锚点 | 全仓库正式文档、项目正文、治理协议、Controller/packet 说明 |
| Q3 | 文档体系优先服务 Agent，不服务人；缺清晰人类阅读路径 | L0/L1/L1M 入口、项目入口、manifest/llms 路由 |
| Q4 | 人读不顺的文档 Agent 也会隐性误解；对象近义词、否定式约束、抽象层级跳跃会诱发漂移 | 全仓库术语、对象、约束、Agent 路由和任务包 |
| Q5 | 文档不是实现说明，而是防偏护栏；链路头重脚轻，越靠近执行越薄 | 生态层、项目层、评测层、Controller 承接层 |
| Q6 | “靠厚文档防走偏”在产品建设中容易变成反模式；治理工具被用于产品建设 | 全仓库治理方法、项目推进方式、closeout 语言 |
| Q7 | 多 Agent 约束应迁移到 schema / prompt / eval / CI，不应主要留在自然语言白皮书 | 所有项目的工程化、评测、任务包和 CI 承接 |
| Q8 | MVP / 执行文档没有说明怎么做：技术栈、架构、API、DB schema、JSON 样例、UI、部署、里程碑等均缺失 | 项目层实施输入、任务包、评测 case、工程 handoff |
| Q9 | MVP / 项目定义 “不是什么”较清楚，但“是什么”不够具体：首个用户、替代方案、产品形态、成功指标、时间盒缺失 | 项目定义、当前状态、PRD / design / task packet |
| Q10 | 文档设计的开发指导链路只走完前 2/3；实施承接方、任务包和反馈回流不清楚 | Controller 恢复层、下游工程承接、反馈回流协议 |
3. 对现有 FR register 的影响
该附件直接补强或新增以下反馈条目：
| FR | 影响 |
|---|---|
| FR-007 | “缺少原始反馈 intake”改为 partial：已有一份可追溯原始证据样本，但不是全团队全集 |
| FR-011 | 新增：治理仓库和知识库文档高抽象、低叙事、缺例子和视觉锚点，低上下文读者难以持续阅读 |
| FR-012 | 新增：文档和入口偏 Agent-first，缺人类阅读路径和读者可用性验证 |
| FR-013 | 新增：约束主要以否定式自然语言存在，未迁移到 schema / prompt / eval / CI |
| FR-014 | 新增：战略 / 产品 / MVP / PRD 链路头重脚轻，实施承接和技术设计断层 |
| FR-015 | 新增：MVP 缺第一个用户、替代方案、可想象产品形态、量化成功指标和时间盒 |
| FR-016 | 新增：文档进展容易替代项目进展，形成“对齐即进展”的误判 |
| FR-017 | 新增：缺完整正例、JSON 样例、用户旅程、线框图、状态机和真实验收 case |
| FR-018 | 新增：当前材料是一份原始证据样本，需要更多 reader testing 或团队确认来量化覆盖度，但不得因此收窄问题范围 |
4. 当前建议
- Batch 8A register 必须更新为“partial source intake”，不能继续写“完全没有原始反馈材料”。
- Batch 8B 必须按这些 FR 维度处理生态层逐篇 audit，不能把附件问题延后到 FinClaw 单项目批次。
- Batch 8C 必须把同一组 FR 维度应用到所有项目层文档体系，FinClaw 只是证据入口，不是唯一受影响项目。
- Batch 8D 决策时必须区分两件事：Admin 可登记和路由系统性反馈；是否由 Admin 统一重写各 Controller 项目正文仍需边界授权。
- 若团队接受附件建议，应将“约束迁移到 schema / prompt / eval / CI”和“原型 / 用户测试优先于继续加厚战略文档”升级为跨项目 Controller 执行输入。
5. 不声明事项
- 不声明这份附件覆盖全部团队成员或所有原始反馈来源；
- 不声明附件中的判断已经被所有项目 owner 接受；
- 不声明任何生态层或项目层文档已经完成重构；
- 不把“已登记反馈”误写成“已解决反馈”；
- 不把“证据入口在 FinClaw”误写成“问题只属于 FinClaw”；
- 不改变当前 Admin / Controller 权责边界。
6. 后续观察点
- 是否还有其他原始团队反馈材料需要继续 intake；
- 各 Controller 是否确认这些 FR 为其项目层重构输入；
- Batch 8B 是否逐篇验证生态层文档中的同类问题；
- Batch 8C 是否逐项目验证
projects/*文档中的同类问题； - 是否需要建立低上下文 reader testing 任务，对生态入口和项目入口重复阅读路径；
- 是否需要把约束自然语言迁移到工程仓库的 schema / eval / CI 任务包。