【S3W3 交叉评测】Remain Passport 的可验证性、知识沉淀与决策依据建议 #3

New issue

Closed

opened 2026-08-06 11:00:16 +08:00 by chozzc · 1 comment

chozzc commented 2026-08-06 11:00:16 +08:00

Copy link

1. 项目理解

我理解 Remain Passport 希望为物品、订阅服务和健康养护事项建立统一的数字护照，通过建档、养护推导、维修问诊和定期巡检，让 Agent 从一次性问答升级为能够长期维护生活资产的管理助手。

2. 项目亮点

• 使用统一 subject 模型管理不同类型对象，产品结构具有扩展性。
• 建档结果不是直接写入，而是先形成可编辑草稿并由用户确认。
• 维修问诊采用逐轮追问，并结合维修价、残值和新品价辅助修换决策。
• 模型或联网能力不可用时会明确降级，不使用假数据冒充真实能力。
• 访客 Demo 数据隔离，评审无需注册即可体验完整流程。

3. 当前问题

• 当前比赛仓库为无源码展示仓库，虽然能够验证产品体验，但难以独立核查 Skills 是否按照公开契约执行，也无法验证脱敏、权限和定时巡检的具体实现。
• 仓库目前提交历史较少，难以看到 Wave 3 相比前一阶段的真实迭代过程。
• 维修价、残值和新品价会明显影响修换建议，需要更加清楚地展示数据来源、抓取时间、样本范围和不确定性。
• “知识沉淀”会将维修结果转化为跨账号经验，需要进一步说明用户如何查看、撤回以及如何防止稀有型号或特殊描述被重新识别。
• 健康护照虽然声明不代替医疗诊断，但复查周期和行动建议仍应标明依据及适用边界。

4. 建议

• 至少公开一个经过简化的 Skill 执行 Trace，包含路由结果、输入 Schema、工具调用、脱敏前后字段、用户确认和最终写入结果。
• 在 Specs 中增加每项公开能力与可验证证据的逐条映射。
• 维修决策卡显示数据来源、更新时间、价格区间和置信度，不只给出单一金额。
• 为知识贡献提供查看、撤回和删除入口，并加入稀有字段重识别测试。
• 增加型号识别错误、价格数据缺失、图片模糊、联网失败和用户修改字段后的回归测试。
• 对健康事项明确区分通用提醒、来源明确的周期建议和必须咨询专业人员的内容。

5. 综合评价

项目的产品概念、交互闭环和 Demo 完成度较高，长期资产 Agent 的定位也具有差异化。当前最需要补强的是无源码情况下的可验证证据、决策数据来源以及跨账号知识沉淀的隐私治理。

## 1. 项目理解 我理解 Remain Passport 希望为物品、订阅服务和健康养护事项建立统一的数字护照，通过建档、养护推导、维修问诊和定期巡检，让 Agent 从一次性问答升级为能够长期维护生活资产的管理助手。 ## 2. 项目亮点 - 使用统一 subject 模型管理不同类型对象，产品结构具有扩展性。 - 建档结果不是直接写入，而是先形成可编辑草稿并由用户确认。 - 维修问诊采用逐轮追问，并结合维修价、残值和新品价辅助修换决策。 - 模型或联网能力不可用时会明确降级，不使用假数据冒充真实能力。 - 访客 Demo 数据隔离，评审无需注册即可体验完整流程。 ## 3. 当前问题 - 当前比赛仓库为无源码展示仓库，虽然能够验证产品体验，但难以独立核查 Skills 是否按照公开契约执行，也无法验证脱敏、权限和定时巡检的具体实现。 - 仓库目前提交历史较少，难以看到 Wave 3 相比前一阶段的真实迭代过程。 - 维修价、残值和新品价会明显影响修换建议，需要更加清楚地展示数据来源、抓取时间、样本范围和不确定性。 - “知识沉淀”会将维修结果转化为跨账号经验，需要进一步说明用户如何查看、撤回以及如何防止稀有型号或特殊描述被重新识别。 - 健康护照虽然声明不代替医疗诊断，但复查周期和行动建议仍应标明依据及适用边界。 ## 4. 建议 - 至少公开一个经过简化的 Skill 执行 Trace，包含路由结果、输入 Schema、工具调用、脱敏前后字段、用户确认和最终写入结果。 - 在 Specs 中增加每项公开能力与可验证证据的逐条映射。 - 维修决策卡显示数据来源、更新时间、价格区间和置信度，不只给出单一金额。 - 为知识贡献提供查看、撤回和删除入口，并加入稀有字段重识别测试。 - 增加型号识别错误、价格数据缺失、图片模糊、联网失败和用户修改字段后的回归测试。 - 对健康事项明确区分通用提醒、来源明确的周期建议和必须咨询专业人员的内容。 ## 5. 综合评价 项目的产品概念、交互闭环和 Demo 完成度较高，长期资产 Agent 的定位也具有差异化。当前最需要补强的是无源码情况下的可验证证据、决策数据来源以及跨账号知识沉淀的隐私治理。

RECHTAN commented 2026-08-06 17:03:39 +08:00

Owner

Copy link

回复 · Wave 3 交叉评测 Issue 3（2026-08-06）

构建号 0c6587483f25，已部署。可核验入口：curl -s https://passport.rechtan.com/version。

在这一条Issue是最新提出一条关于真实隐私风险、而不是证据充分性的问题：

「知识沉淀」会将维修结果转化为跨账号经验，需要进一步说明用户如何查看、撤回以及如何防止
稀有型号或特殊描述被重新识别。

本轮的开发窗口给了这条。理由是：其余意见（价格置信度、执行 Trace、能力↔证据映射、健康分档）
都是让已有能力更可信，而这一条是已有能力缺了一块——用户的维修经历被脱敏后成为跨账号
知识，用户看不到，也撤不回。

并且这条提议直接命中了一个真实漏洞，详见第三节。

一、查看与撤回入口（已上线）

GET    /api/v1/knowledge/contributions        本账号贡献的全部案例
DELETE /api/v1/knowledge/contributions/:id    撤回

界面在「账号」页的「我贡献的维修经验」区块：按贡献时间倒序，列出品类、症状与时间，
正文可展开（展示的是实际入库文本，不是摘要，否则「查看」没有意义），每条一个撤回按钮，
二次确认后删除。

几个实现上的决定，一并写出来供审阅：

• 撤回是物理删除，不是标记。行消失后向量索引不再命中，其他账号立即检索不到，
  不需要额外清理向量。
• 撤回别人的案例、或撤回一个不存在的 id，都返回 404，不返回 403。 两者必须不可区分，
  否则这个端点就成了「任意案例 id 是否存在」的探测器。
• 列表查询是知识库上唯一带 contributed_by 谓词的语句，检索路径仍然不按贡献者过滤。
  这一点在 db.rs 的知识库段落里写了注释，避免以后有人顺手把所有权谓词加到检索上，
  把跨账号知识变成私有缓存。
• 撤回写审计日志，事件名 knowledge.contribution_withdrawn。
• 访客问诊不再入库。 访客账号在 4 小时后连同数据一起删除，一个届时无法撤回的贡献，
  不该先被创建。
• 贡献者账号被删除后，其未撤回的贡献以无归属形式留在库中（contributed_by 为
  on delete set null）。本轮保持该行为，但把它写在了界面上的固定说明里，不默认用户知道。

二、什么会入库、什么不会

评测担心的「稀有型号或特殊描述被重新识别」，防线有三层，都可以说清楚：

1. 可复用性判定：只有 Agent 判断可跨账号复用的案例才入库，一次性个案不入库。
2. 脱敏：品牌、品类、症状、正文四个字段在写入前统一过一遍联系方式脱敏。
   入库文本里不含护照名称——护照名是用户自定义的，「爸爸的电动牙刷」这种名字本身就是标识。
3. 相似度门槛：检索分数低于 MIN_SCORE = 0.65 不返回，DUPLICATE_SCORE = 0.93
   以上视为重复不重复入库。

三、你建议的「稀有字段重识别测试」找出了一个真实漏洞

按建议补测试时，其中一条断言直接失败了：

400-8888-8888 仍留在入库文本里

原因：脱敏按连续数字段扫描，长度达到阈值才判定为标识。400-8888-8888 被拆成
3、4、4 三段，每段都不够长，于是一个完整的电话号码原样进入了跨账号知识库。
写下来的电话号码几乎总是带分隔符的，所以这不是边角情况——这条规则基本上等于没拦住手写号码。

修法：跨单个连字符合并数字段后再判长度；同时

• 不跨空格合并，否则「维修 12800 新品 19900」会被并成一个 10 位数字整段抹掉，
  而价格正是这些案例存在的意义；
• 豁免日期形状（4-2-2 / 2-2-4 / 4-2）。日期长度和电话一样，但它指向的不是人，
  而且「什么时候坏的」是案例里有用的信息。

对应测试（crates/passport-core/src/sanitize.rs）：

• a_hyphenated_hotline_is_one_number_not_three_short_ones
• a_written_date_is_not_an_identifier
• two_prices_side_by_side_are_not_joined_into_an_identifier
• prices_and_model_numbers_survive

修复只对修复之后的写入生效。本轮迁移登录体系时知识表整表清空，因此库里不存在按旧规则
写入的历史行。

四、其余三条测试

• only_the_same_fault_clears_the_retrieval_threshold（knowledge.rs）——
  把原先只写在注释里的那张相似度表固化成断言：同故障命中，跨品类不命中。
• a_rare_model_case_carries_no_way_back_to_its_contributor（knowledge.rs）——
  罕见品牌 + 型号 + 特殊描述的案例，断言入库文本不含联系方式、不含护照名称中的自定义部分。
  就是这条测出了第三节的漏洞。
• the_stored_vector_is_built_without_the_passport_name（knowledge.rs）——
  断言用于检索的向量文本不含护照名。
• a_withdrawn_case_stops_being_retrievable_by_anyone（db.rs，真库集成测试）——
  插入 → 检索命中 → 撤回 → 同一查询不再命中。CI 已配 DATABASE_URL，这条在 CI 里真的跑。

五、/version（Issue 1 的建议，一并落地）

$ curl -s https://passport.rechtan.com/version
{"agentEnabled":true,"buildId":"0c6587483f25","builtAt":"2026-08-06T08:14:07Z",
 "demoMode":true,"schemaVersion":"0028"}

作为后续证据文件与线上部署对账的锚点。

六、已接受，本轮没做

事项	原因
决策卡显示价格来源、抓取时间、区间与置信度	需改 DecisionCard schema 与 Skill 输出契约，改完必须重跑真实模型链路取证。两小时内做不实，宁可不做也不发一个更精确的假数字
健康事项三分档（通用提醒 / 有来源的周期建议 / 必须就医）	涉及 Skill 输出语义变更与升级路径设计，同上
脱敏 Skill 执行 Trace（路由、输入 Schema、工具调用、脱敏前后字段、用户确认、最终写入）	方向接受。需要单独的脱敏与审阅流程，不能赶工发布
SPECS 里能力↔证据逐条映射 / evidence.json	依赖 /version 的 buildId 先上线，本轮才具备前提
型号识别错误、价格缺失、图片模糊、联网失败、用户改字段后的回归测试	本轮只做了知识库相关四条，其余未做

不给完成时间。

七、关于「提交历史较少」

参赛仓是产出物快照仓，迭代发生在实现仓，所以从参赛仓看不到过程——这是仓库划分造成的，
不是没有迭代。本轮之后，/version 的 buildId 至少能让每一次线上部署对应到一个确定的构建，
再往前一步（构建 ↔ 证据 ↔ 结论的映射）是下一轮的事，本轮没做完，不预告。

八、一处复核限制

因为访客问诊不再入库，用访客 Demo 进入时「我贡献的维修经验」是空列表：能看到入口与说明，
但复现不了「贡献 → 撤回」的完整链路。隐私上这是正确的取舍，但确实让这条改动对免注册评审
不够可见，先讲清楚。

# 回复 · Wave 3 交叉评测 Issue 3（2026-08-06） 构建号 `0c6587483f25`，已部署。可核验入口：`curl -s https://passport.rechtan.com/version`。 在这一条Issue是最新提出一条**关于真实隐私风险、而不是证据充分性**的问题： > 「知识沉淀」会将维修结果转化为跨账号经验，需要进一步说明用户如何查看、撤回以及如何防止 > 稀有型号或特殊描述被重新识别。 本轮的开发窗口给了这条。理由是：其余意见（价格置信度、执行 Trace、能力↔证据映射、健康分档） 都是让已有能力**更可信**，而这一条是已有能力**缺了一块**——用户的维修经历被脱敏后成为跨账号 知识，用户看不到，也撤不回。 **并且这条提议直接命中了一个真实漏洞**，详见第三节。 ## 一、查看与撤回入口（已上线） ``` GET /api/v1/knowledge/contributions 本账号贡献的全部案例 DELETE /api/v1/knowledge/contributions/:id 撤回 ``` 界面在「账号」页的「我贡献的维修经验」区块：按贡献时间倒序，列出品类、症状与时间， 正文可展开（展示的是**实际入库文本**，不是摘要，否则「查看」没有意义），每条一个撤回按钮， 二次确认后删除。 几个实现上的决定，一并写出来供审阅： - **撤回是物理删除**，不是标记。行消失后向量索引不再命中，其他账号立即检索不到， 不需要额外清理向量。 - **撤回别人的案例、或撤回一个不存在的 id，都返回 404，不返回 403。** 两者必须不可区分， 否则这个端点就成了「任意案例 id 是否存在」的探测器。 - **列表查询是知识库上唯一带 `contributed_by` 谓词的语句**，检索路径仍然不按贡献者过滤。 这一点在 `db.rs` 的知识库段落里写了注释，避免以后有人顺手把所有权谓词加到检索上， 把跨账号知识变成私有缓存。 - **撤回写审计日志**，事件名 `knowledge.contribution_withdrawn`。 - **访客问诊不再入库。** 访客账号在 4 小时后连同数据一起删除，一个届时无法撤回的贡献， 不该先被创建。 - **贡献者账号被删除后，其未撤回的贡献以无归属形式留在库中**（`contributed_by` 为 `on delete set null`）。本轮保持该行为，但把它写在了界面上的固定说明里，不默认用户知道。 ## 二、什么会入库、什么不会 评测担心的「稀有型号或特殊描述被重新识别」，防线有三层，都可以说清楚： 1. **可复用性判定**：只有 Agent 判断可跨账号复用的案例才入库，一次性个案不入库。 2. **脱敏**：品牌、品类、症状、正文四个字段在写入前统一过一遍联系方式脱敏。 入库文本里不含护照名称——护照名是用户自定义的，「爸爸的电动牙刷」这种名字本身就是标识。 3. **相似度门槛**：检索分数低于 `MIN_SCORE = 0.65` 不返回，`DUPLICATE_SCORE = 0.93` 以上视为重复不重复入库。 ## 三、你建议的「稀有字段重识别测试」找出了一个真实漏洞 按建议补测试时，其中一条断言直接失败了： ``` 400-8888-8888 仍留在入库文本里 ``` 原因：脱敏按**连续数字段**扫描，长度达到阈值才判定为标识。`400-8888-8888` 被拆成 3、4、4 三段，每段都不够长，于是一个完整的电话号码原样进入了跨账号知识库。 写下来的电话号码几乎总是带分隔符的，所以这不是边角情况——这条规则基本上等于没拦住手写号码。 修法：跨单个连字符合并数字段后再判长度；同时 - **不跨空格合并**，否则「维修 12800 新品 19900」会被并成一个 10 位数字整段抹掉， 而价格正是这些案例存在的意义； - **豁免日期形状**（`4-2-2` / `2-2-4` / `4-2`）。日期长度和电话一样，但它指向的不是人， 而且「什么时候坏的」是案例里有用的信息。 对应测试（`crates/passport-core/src/sanitize.rs`）： - `a_hyphenated_hotline_is_one_number_not_three_short_ones` - `a_written_date_is_not_an_identifier` - `two_prices_side_by_side_are_not_joined_into_an_identifier` - `prices_and_model_numbers_survive` 修复只对修复之后的写入生效。本轮迁移登录体系时知识表整表清空，因此库里不存在按旧规则 写入的历史行。 ## 四、其余三条测试 - `only_the_same_fault_clears_the_retrieval_threshold`（`knowledge.rs`）—— 把原先只写在注释里的那张相似度表固化成断言：同故障命中，跨品类不命中。 - `a_rare_model_case_carries_no_way_back_to_its_contributor`（`knowledge.rs`）—— 罕见品牌 + 型号 + 特殊描述的案例，断言入库文本不含联系方式、不含护照名称中的自定义部分。 就是这条测出了第三节的漏洞。 - `the_stored_vector_is_built_without_the_passport_name`（`knowledge.rs`）—— 断言用于检索的向量文本不含护照名。 - `a_withdrawn_case_stops_being_retrievable_by_anyone`（`db.rs`，真库集成测试）—— 插入 → 检索命中 → 撤回 → 同一查询不再命中。CI 已配 `DATABASE_URL`，这条在 CI 里真的跑。 ## 五、`/version`（Issue 1 的建议，一并落地） ``` $ curl -s https://passport.rechtan.com/version {"agentEnabled":true,"buildId":"0c6587483f25","builtAt":"2026-08-06T08:14:07Z", "demoMode":true,"schemaVersion":"0028"} ``` 作为后续证据文件与线上部署对账的锚点。 ## 六、已接受，本轮没做 | 事项 | 原因 | | ------------------------------------------------------------ | ------------------------------------------------------------ | | 决策卡显示价格来源、抓取时间、区间与置信度 | 需改 `DecisionCard` schema 与 Skill 输出契约，改完必须重跑真实模型链路取证。两小时内做不实，宁可不做也不发一个更精确的假数字 | | 健康事项三分档（通用提醒 / 有来源的周期建议 / 必须就医） | 涉及 Skill 输出语义变更与升级路径设计，同上 | | 脱敏 Skill 执行 Trace（路由、输入 Schema、工具调用、脱敏前后字段、用户确认、最终写入） | 方向接受。需要单独的脱敏与审阅流程，不能赶工发布 | | SPECS 里能力↔证据逐条映射 / `evidence.json` | 依赖 `/version` 的 `buildId` 先上线，本轮才具备前提 | | 型号识别错误、价格缺失、图片模糊、联网失败、用户改字段后的回归测试 | 本轮只做了知识库相关四条，其余未做 | 不给完成时间。 ## 七、关于「提交历史较少」 参赛仓是产出物快照仓，迭代发生在实现仓，所以从参赛仓看不到过程——这是仓库划分造成的， 不是没有迭代。本轮之后，`/version` 的 `buildId` 至少能让每一次线上部署对应到一个确定的构建， 再往前一步（构建 ↔ 证据 ↔ 结论的映射）是下一轮的事，本轮没做完，不预告。 ## 八、一处复核限制 因为访客问诊不再入库，用访客 Demo 进入时「我贡献的维修经验」是空列表：能看到入口与说明， 但复现不了「贡献 → 撤回」的完整链路。隐私上这是正确的取舍，但确实让这条改动对免注册评审 不够可见，先讲清楚。

Jonashuang closed this issue 2026-08-06 22:18:35 +08:00

Sign in to join this conversation.

No Branch/Tag specified

Branches Tags

main

No results found.

Labels

Clear labels

No items

No labels

Milestone

Clear milestone

No items

No milestone

Projects

Clear projects

No items

No project

Assignees

Clear assignees

No assignees

2 participants

Notifications

Subscribe

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

RECHTAN/remain-passport#3

No description provided.