CASE STUDY
2026.10.24 · 采集可靠性复盘 · 个人项目 · AI 协作Oct 24, 2026 · intake reliability review · Personal project · AI-assisted
Planbox：能找到原文，不等于信息已经可信
Planbox 试图解决一个我经常遇到的问题：活动信息收藏了很多，真正需要决定参加哪一场时，却还要重新找日期、地点、报名截止和准备要求。
最初的方向是活动机会管理，当前实现更接近本地信息整理原型。我负责范围、人工确认节点和数据流的产品决策，代码由 AI 编程工具完成。目标排序、具体时段规划和提醒效果没有因为写进方案就自动成立。
先保存来源，再让 AI 给出草稿
当前流程把来源、抽取草稿和确认后的活动分开。AI 提取的结果进入核对，用户可以对照来源修改，再决定是否确认。平台链接取不到正文时，需要有补充正文的入口。
这条路径的关键不只是“能抓到链接”。来源需要与正确的正文关联，用户已经写下的内容也不能在抓取失败后消失。否则，后面再漂亮的证据定位和字段展示，都可能建立在错误输入上。
“10 月下旬”不能导出成一个猜测的时刻
时间字段比看起来复杂。一个通知可能只有日期，没有具体时刻；可能有时区，也可能只写相对日期。把这些内容一律补成当年、当天 23:59，会制造海报没有提供的事实。
目前已有时间校验与 ICS 导出实现，保留日期精度、明确偏移和待核对状态。不完整的时间需要在确认与导出边界处理，而不是为了生成日历文件随意补全。
本地定向回归记录覆盖了时间契约和 ICS 文件格式；它们不证明真实日历客户端已经正确导入，也不证明提醒送达或一周排期更有效。
一段文字能定位，只说明它能定位
字段证据的读取会返回片段位置和它与当前值的关系。这个设计可以帮助用户找到原文，但 located 只表示片段在正文里出现，不代表它支持当前字段，更不代表已经人工确认。
例如，原文中出现一个日期，不一定说明它就是报名截止；出现一个地点，也可能只是往届活动的地址。证据位置、字段含义和人的判断需要分别处理。
改错之后，还要知道改了什么
本地原型已加入活动与草稿的字段更正、历史读取和整次撤回。记录保留旧值、新值、原因、来源与操作分组，并用版本和预期原值检查陈旧修改。
撤回也不是删除历史。它追加反向记录；如果同一字段已经被后续修改，就不能悄悄覆盖新的内容。这部分是为了让纠错过程可追溯，不是生产身份审计或完整状态机已经完成的证明。
最近的审查，仍然发现了输入丢失与来源错绑
最新审查记录在合成数据中复现了两类问题：同时填写链接和正文后，抓取降级会丢掉已写正文；小红书页面状态含多篇笔记时，解析器可能取第一篇，却保留目标链接的身份。
后者尤其值得警惕：界面可能展示一段确实存在的文字，但它属于另一条来源。这说明“字段旁边有证据”还不够，必须先守住来源归属。
这些问题目前尚未修复。这里引用的是当前本地分支与最近审查记录，不把它们描述成线上事故；真实平台出现这些数据形态的频率也没有验证。本地分支与公开远端快照存在差异。
下一步先让整理可信
Planbox 已有收集、草稿核对、字段更正/撤回和 ICS 导出路径，但可信基础任务仍未整项验收。原生小程序有接入源码，真机分享与正式 HTTPS 环境待验证；没有真实用户效果结果。
接下来应先处理正文保留和来源匹配，补齐状态与原子性边界，再用授权材料观察一个人能否完成收集、核对和日历使用。自动排期要建立在这组证据之上。
依据：公开分支固定快照中的更正与撤回契约、ICS 导出服务，以及本次核对的本地分支和合成数据审查记录。本轮未重跑模型、平台抓取或业务测试。
Planbox: finding the source does not make information trustworthy
Planbox starts with a problem I often encounter: I save plenty of event information, then have to find the dates, venues, deadlines, and preparation requirements all over again when deciding where to go.
The initial direction was opportunity management. The current implementation is closer to a local information-organizing prototype. I owned scope, human-review checkpoints, and data-flow decisions; AI coding tools produced the code. Ranking, concrete scheduling, and effective reminders are not implemented outcomes simply because they appear in a plan.
Keep the source before asking AI for a draft
The flow separates sources, extraction drafts, and confirmed events. AI results enter review, where people compare them with the source, edit fields, and decide whether to confirm. If a platform link cannot supply its content, a manual-completion path is needed.
Success is more than fetching a link. The right source must be associated with the right body, and material someone has already written must survive fetch failure. Otherwise, evidence markers and polished field displays may be built on the wrong input.
An approximate date must not become an invented time
A notice may provide a day but no time, include a time zone, or use a relative date. Filling every gap with the current year or 23:59 creates facts that the notice never supplied.
Time validation and ICS export now exist. They preserve date precision, explicit offsets, and unresolved-review states. Incomplete time information needs handling at confirmation and export boundaries rather than arbitrary completion to produce a calendar file.
Local focused regressions cover time contracts and ICS format. They do not establish correct import by actual calendar clients, notification delivery, or better week planning.
A located passage is only a located passage
Evidence responses provide passage locations and relationships with current field values. This helps someone find the text. A located status means the passage occurs in the source, not that it supports the field or has been reviewed.
A date in the text may not be the registration deadline. A location may describe a previous event. Source position, field meaning, and human judgment require separate treatment.
Corrections need a history
The local prototype supports field corrections, history, and whole-operation retraction for events and drafts. It retains old and new values, reasons, sources, and operation groups, with revision and expected-value checks against stale writes.
Retraction appends a reverse record rather than deleting history. Later changes to the same field prevent silently overwriting newer information. This makes corrections traceable; it does not establish production identity auditing or a complete state machine.
Recent review still found lost text and wrong source attribution
The latest review reproduced two issues with synthetic data. When a user supplies both a link and body text, fetch fallback can discard the text. When a Xiaohongshu page state contains several notes, the parser may choose the first while retaining the requested note’s identity.
The second issue is particularly revealing: a passage can genuinely exist while belonging to a different source. Displaying evidence beside a field is insufficient unless source attribution is correct first.
These defects remain unresolved. They describe the current local branch and review records, not observed production incidents. Their frequency in real platform responses is unmeasured. The local branch differs from the published remote snapshot.
Make organizing trustworthy before adding planning
Planbox has collection, draft review, corrections/retraction, and ICS paths, but trust-foundation work is not fully accepted. Native mini-program intake code exists; device sharing and production HTTPS remain unvalidated. There are no real-user outcome results.
The next step is to preserve submitted text, fix source matching, finish state and atomicity boundaries, and observe someone collecting, reviewing, and using authorized event information in a calendar. Automatic scheduling needs that evidence first.
Sources: the published branch’s fixed correction contract, ICS export service, and the local branch and synthetic-data review inspected for this update. No models, platform fetches, or business tests were rerun in this review.