工程对齐审查意见

审查日期: 2026-03-31 审查范围: ENGINEERING_ALIGNMENT.md、DEVELOPMENT_RULES.md、CHANGELOG.md、README.md 审查人: AI Assistant (Claude)

一、原则层面

文档列出了技术指标与生命服务指标的对应关系（如"响应时间<100ms → 用户3秒找到方法"），但右栏本质上是 UX 指标，不是生命状态指标。真正的生命指标应该是可量化的用户变化，例如：

建议: 在 DEVELOPMENT_RULES.md 0.7 节补充一个"生命指标测量框架"，明确哪些是代理指标（proxy）、哪些是直接指标。否则三问中的第二问"如何验证它真的改善了用户生命状态"无法落地。

文档只描述了原则本身，没有记录"哪个功能因无法回答三问而被否决"的历史决策。

建议: 在 ENGINEERING_ALIGNMENT.md 的 ADR 中补充 1-2 个"拒绝立项"的 ADR（ADR-REJECT 格式），让团队理解这个过滤器在真实场景中如何工作。

短期/中期/长期规划几乎全是技术债务和基础设施：覆盖率、监控、HA、缓存。但核心原则说"一切围绕用户生命状态提升"——用户直接感知到的功能在哪里？

根据 DEVELOPMENT_RULES.md 0.6 节描述的个性化服务，以下功能应在规划中但缺失：

建议: 在 ENGINEERING_ALIGNMENT.md 的 5.2/5.3 节中补充"用户功能"维度，与技术基建并列。否则可能出现基础设施完善但用户无感知的情况。

当前标记为 HIGH 技术债务，但向量检索是系统核心能力。SHA-256 代替 BGE 意味着所有向量搜索结果都是随机的，这直接违背"准确率>95%"的目标。

建议: 将 BGE 嵌入对接从 P1 提升到 P0，与 pgvector 安装同步进行。

DEVELOPMENT_RULES 的 v2.0.0 是文档版本，但与项目版本 1.3.0 混用容易造成混淆。

建议: 文档版本和项目版本分离。DEVELOPMENT_RULES 改为 doc-v2.0.0，项目版本统一为 v1.3.0-dev。

0.3 核心原则三问、0.7 技术与生命服务、0.8 标注系统等内容在两个文件中几乎相同。未来修改一处忘记同步另一处的风险很高。

建议: DEVELOPMENT_RULES 保留编码规范（第 1-17 节），核心原则部分只保留引用指向 ENGINEERING_ALIGNMENT.md。

虽然已加弃用声明，但 49 个文件依然影响项目观感。

建议: 将所有已归档报告移动到 docs/archive/ 子目录，根目录只保留 5-6 个活文档：

最大的风险: 规划偏技术侧，缺少用户功能维度。如果按当前规划执行，04-30 时系统会很稳定、监控很完善，但用户看到的还是 v1.1.0 的 Q&A 界面。
落地缺口: 核心原则从理念到工程实践之间，缺少测量框架和否决案例的支撑。

优先级	建议	工作量
P0	BGE 嵌入对接提升为 P0	已在规划中
P1	补充用户功能路线图到 5.2/5.3 节	2h
P1	分离文档版本与项目版本	1h
P1	消除 DEVELOPMENT_RULES 与 ENGINEERING_ALIGNMENT 重复内容	2h
P2	补充生命指标测量框架	半天（需讨论）
P2	归档报告移入 docs/archive/	1h
P3	补充 ADR-REJECT 否决案例	积累型，无需集中处理

本文档为审查意见，供团队讨论参考，不直接修改任何规范。