Improvement Roadmap
“已在本副本实现”仅指这个静态作品集的代码与文档；“已在项目源码实现”指对应项目仓库已有可复现代码与本机验收；“待目标项目实现”仍需进入对应源码仓库完成。难度分越高，意味着跨仓库、数据、成本或运行环境依赖越多。
把“三个旗舰项目”、Z1 队友负责实现、智能座舱 RAG 为独立实验等口径写入自动校验，阻止后续编辑重新混淆。
目标：个人网站副本
涉及：content/site.js；tools/check_site.py；work/z1space.html；roadmap.html
预期效果：简历、案例页和材料页的项目数量、职责与指标归属保持一致。
验证：运行 python -B tools/check_site.py；篡改上述口径时检查应失败。
评分：重要程度 5/5 × 实现难度 1/5
替代方案：若未来项目事实变化，应同时更新数据源、证据记录和校验规则，不要只改展示文案。
新增 GitHub Actions，在 push 与 pull request 时检查数据/HTML 同步、链接与口径、可访问性与元数据，并执行部署打包。
目标：个人网站副本
涉及：.github/workflows/site-quality.yml；tools/sync_site.py；tools/check_site.py；tools/check_quality.py；tools/build_site.py
预期效果：GitHub 上的每次改动都有可复现质量门禁，失败不能被误当作可发布版本。
验证：本机依次运行四条工作流命令；仓库初始化并 push 后再以 Actions 绿灯作为远端验证。
评分：重要程度 5/5 × 实现难度 2/5
替代方案：当前目录尚未初始化 Git；在此之前以本机同命令的退出码和构建报告为准。
已从本地源码核对负反馈→SQLite Bad Case、四种产品事件，以及 CI 中的确定性 accept 门禁。当前缺少 12 题语义质量基线门禁、批量导入/状态闭环和远端 Actions 成功凭证，因此只判定部分完成。
目标：enterprise-rag-workbench 源码仓库
涉及：src/enterprise_rag/quality/；src/enterprise_rag/api/routes/quality.py；tests/test_quality_feedback.py；.github/workflows/ci.yml
预期效果：把“有测试”升级为可追踪的质量回收与发布验收门禁；Bad Case 可定位到查询、实际状态和失败原因。
验证：已读取 API、QUALITY_LOOP、CI 配置与 10-06 的 17/17 报告；远端 CI 成功与语义门禁未确认。
评分：重要程度 5/5 × 实现难度 4/5
替代方案：当前仍未把语义泛化诊断集作为阻断门禁：hashing-v1 的四类已知语义缺口需在引入真实嵌入模型和稳定基线后再纳入阈值。
README 说明数据源、目录、编辑、同步、检查、打包、部署和材料边界；静态站点保持零 npm 依赖，因此不制造空依赖锁文件。
目标：个人网站副本
涉及：README.md；.gitignore；deploy.json
预期效果：接手者能在没有私有工具链的环境中完成预览、校验和发布准备。
验证：全新 Python 环境执行 README 中四条命令；检查器同时拒绝意外加入的 npm 依赖。
评分：重要程度 5/5 × 实现难度 2/5
替代方案：若未来引入第三方依赖，再提交真实清单与锁文件；当前零依赖时无需形式化占位。
在推荐理由卡增加有用/无用反馈，记录 recommendation_id、reasonCode、版本与去重主体；归属校验后按有效反馈样本聚合。契约已随网站附带，产品实现待办。
目标：Z1Space 源码仓库
涉及：src/features/feedback/；server/routes/feedback；migrations/feedback.sql
预期效果：从实现阶段用例转向真实反馈数据，为后续提示词和检索优化提供证据。
验证：完成提交、重复提交、匿名限制、失败重试和 reasonCode 报表测试。
评分：重要程度 4/5 × 实现难度 3/5
替代方案：缺少源码和真实用户流量时，先用可导出的表单原型验证原因分类，不宣称已经上线。
用同一评测集比较 DeepSeek 与至少一个可替代模型或 mock 基线，记录质量、P50/P95 延迟、输入输出 token 和估算成本。
目标：enterprise-rag-workbench 源码仓库
涉及：tests/eval/model_matrix.yml；tools/benchmark_models.py；reports/model-selection.md
预期效果：把模型选择从偏好陈述变成可解释的产品与工程权衡。
验证：同一数据、参数和重复次数运行；报告披露价格日期、失败率和置信范围。
评分：重要程度 4/5 × 实现难度 4/5
替代方案：API 成本或密钥受限时用 mock 验证管线，并把质量结论标为未验证。
已核对批量写入 API、X-Request-ID → 领域事件 trace_id、观测测试和 docs/rollout.md。发布设计已完成；应用内关联不等于跨服务 span 链，实际灰度、回滚演练和新版容量仍待验证。
目标：agent-tree 源码仓库
涉及：docs/rollout.md；app/observability.py；app/event_bus.py；tests/test_observability.py
预期效果：说明如何从本机单实例压测走向可控发布，而不把设计方案包装成真实线上灰度。
验证：本轮读取源码与测试声明；发布策略是设计稿，本轮未执行底层测试或真实灰度。
评分：重要程度 4/5 × 实现难度 3/5
替代方案：在目标机器批准观察窗口与基线，演练正确性故障、长尾延迟和回滚；对批量写入作同环境比较，避免预设 20 entries/s 为硬上限。
定义并持久化 query_submitted、citation_clicked、refusal_shown、retry_after_refusal；工作台在引用核对、拒答后重问和有帮助/需要改进时联动记录。
目标：enterprise-rag-workbench 源码仓库
涉及：src/enterprise_rag/quality/；src/enterprise_rag/ui/app.js；docs/QUALITY_LOOP.md；tests/test_quality_feedback.py
预期效果：同时观察技术质量与用户行为，减少只用覆盖率或离线分数判断产品价值。
验证：事件聚合、反馈到 Bad Case、隐私字段边界和拒答事件均由 65 项回归覆盖；没有真实用户时不对点击率做业务推断。
评分：重要程度 4/5 × 实现难度 3/5
替代方案：无真实用户时只验证事件模型和合成数据，不对点击率或重试率做业务推断。
已有确定性验收中的 prompt_injection_rejected 和相关接口测试；仍需扩展恶意文档、越权、模型诱导与真实模型攻击场景。
目标：enterprise-rag-workbench 源码仓库
涉及：tests/security/prompt_injection.jsonl；tests/security/test_retrieval_boundaries.py；docs/security-model.md
预期效果：把安全边界纳入可回归验收，而不是依赖提示词自觉。
验证：原始验收报告中的安全样例已通过；不据此声称全面注入防护或跨租户隔离。
评分：重要程度 4/5 × 实现难度 3/5
替代方案：先写威胁模型与离线样本；在没有租户和权限实现时，不声称通过跨租户测试。
只有在稳定 Bad Case 数据、真实使用量、成本基线和客户部署约束出现后，再评估微调、定价和私有化方案。
目标：未来独立商业化阶段
涉及：future/research-plan.md
预期效果：避免过早建设高成本能力，把时间集中到可验证的质量闭环。
验证：进入条件包括稳定样本规模、可复现基线、真实成本数据与明确客户需求。
评分：重要程度 2/5 × 实现难度 5/5
替代方案：当前以 RAG 回归、提示词版本化和部署文档覆盖主要学习目标。