一支只有几名成员的社区口述史小组，常常会遇到同一种麻烦：采访线索散落在聊天记录里，录音文件有的存手机、有的发在群中，受访者授权情况靠表格手动追踪，最后还要花时间核对哪段材料能公开。本文不从工具功能清单讲起，而是以“记录一条老街的店铺变迁”为具体场景，设计一套由 Telegram、Web App、Bot 和 GitHub 配合的轻量采集流程。
这套方案的目标不是把所有材料都塞进聊天软件，而是让采访者在街头用手机快速提交进度，让协调者在浏览器中看清项目状态，再通过 GitHub 维护程序和流程规范。关键原则是：聊天负责入口，应用负责整理，仓库负责可复现的代码；受访者的身份信息和原始录音则单独保护。
场景设定：三人小组记录一条老街的店铺记忆
假设项目持续六周，成员包括一名协调者、两名采访者，计划访问十家老店。每次外出，采访者需要记录店铺编号、采访时间、受访者是否同意录音、材料是否需要匿名，以及后续是否允许公开引用。网络可能不稳定，成员也不一定愿意在手机上填写复杂表单，因此提交入口最好足够简单。
把一条 Telegram 消息变成可追踪的采访任务
团队可以建立仅供成员使用的 Telegram 群，并配置一个 bot 作为任务登记入口。采访者完成访谈后，向 bot 发送类似“店铺 07，已完成，允许录音，不公开姓名，待整理”的简短消息，也可以按项目规则提交语音或文件。bot 根据预设选项确认收到，并回复一个任务编号，例如 ORAL-007。编号之后会用于网页记录、文件命名和审核沟通，避免只靠聊天时间来找材料。
需要注意，bot 不应被设计成“自动获得所有群消息”的万能监听器。团队应明确成员如何主动提交内容，检查 Telegram 群和 bot 的权限设置，并只收集完成工作所必需的信息。若采用 Telegram Web App，可由 bot 提供打开表单的入口，让采访者在手机里补充结构化字段，例如访谈地点、主题标签、授权状态和整理负责人。这样既保留聊天入口的便利，也避免把关键数据埋在自然语言消息中。
Web App 的核心：让协调者一眼看懂项目进度
这个 Web App 不必一开始就做成庞大的内容管理系统。首版只需解决三个问题：哪些采访已经完成、哪些材料还缺授权确认、哪些记录可以进入整理阶段。列表页按任务编号展示状态，详情页记录必要的元数据，并提供下一步操作，例如“待补签授权”“待转写”或“允许匿名引用”。
建议的数据字段与状态流转
每条记录可以包含 task_id、shop_code、interview_date、interviewer_id、consent_status、anonymity_required、transcription_status 和 review_status。受访者真实姓名、联系方式与公开展示用的店铺资料应分开保存；如果研究需要留存联系信息，应限制可访问人员，并制定明确的删除时间。状态可以按“已预约—已采访—待整理—待审核—可发布”推进，任何状态变化都记下操作者和时间，方便团队复核。
Telegram Web 是浏览器中访问 Telegram 的客户端；Telegram Web App 则是由 bot 等入口打开的交互式网页体验，两者用途不同。对于这个项目，成员可以用 Telegram Web 查看群内协调信息，而结构化采访表单应由 Web App 或独立网页承担。明确区分这两者，可以减少把聊天界面误当作项目数据库的风险。
GitHub 放什么：维护流程，不托管敏感采访材料
GitHub 适合保存应用代码、字段定义、部署说明、匿名化后的示例数据和团队操作手册。它能让成员通过提交记录追踪修改，也方便在新学期或新项目开始时复用经过验证的流程。但公开仓库不应出现原始录音、受访者姓名、电话号码、未公开的采访文本或真实访问令牌。即使仓库设为私有，也应按最小权限原则管理，并确认团队成员了解版本历史可能保留曾经提交过的内容。
一个适合小项目的仓库结构
oral-history-toolkit/
├── app/ # Web App 页面与业务逻辑
├── bot/ # Telegram bot 的消息处理逻辑
├── schema/ # 表单字段与状态定义
├── docs/ # 采访流程、部署与隐私说明
├── examples/ # 完全虚构的演示数据
└── tests/ # 状态流转与权限检查测试团队可以用 GitHub Issues 追踪“增加授权状态筛选”“修复重复任务编号”等开发事项，用 Pull Request 审查变更。若成员不熟悉编程，也可以在 docs 中维护采访清单和常见问题，由技术成员将经确认的流程变更落实到表单。演示数据必须使用虚构姓名和地址，不要为了方便而从真实访谈记录中复制一条再删掉部分字段。
从外出采访到资料审核：一条完整工作流
- 出发前：协调者在 Web App 建立店铺任务，分配采访者，并在 Telegram 群发布当天安排。
- 现场采集：采访者通过 bot 或 Telegram Web App 提交完成状态、授权选项和必要备注；网络不佳时先使用团队认可的本地记录方式，恢复连接后再补录。
- 材料归档：原始音频存放在经过访问控制的独立存储位置，文件名使用任务编号，不使用受访者姓名。应用只记录受控链接或材料是否已上传，不在普通群聊传播公开链接。
- 整理与复核：协调者在 Web App 筛选待转写和待确认记录；涉及公开引用的内容先检查授权范围，并按承诺进行匿名处理。
- 发布前检查：核对引用是否超出同意范围，确认地图、照片和文字不会意外暴露受访者身份，再将可公开内容整理到项目发布渠道。
隐私与可靠性：先划清边界，再追求自动化
口述史材料可能包含家庭经历、个人评价和可识别地点，因此不能因为团队规模小就忽略隐私。bot 回复时不应把敏感内容重新发到公开群；应用日志也不应完整记录消息正文或访问令牌。团队需要在采访前说明采集目的、保存方式、谁能查看以及撤回或删除请求如何处理。对于高敏感材料，应优先使用适当的加密存储和受限访问方案，并由项目负责人确认所在地适用的法律和伦理要求。
自动化也要有失败预案：bot 暂时不可用时，成员知道向谁报告；重复提交时，系统能依据任务编号识别而不是默默生成两条记录；表单字段更新时，旧记录仍能被正确读取。上线前用虚构任务测试权限、状态转换和异常输入，并在 README 中写清楚部署步骤、配置项和数据备份责任人。不要把 token 直接写入 GitHub 代码，应通过安全的环境变量或密钥管理方式配置，并在泄露时立即撤销和更换。
小结：让工具围绕采访伦理和团队动作设计
对这支街区研究小组而言，telegram bot 的价值在于降低现场登记成本，Web App 的价值在于呈现清晰的任务状态，GitHub 的价值在于让代码、字段和工作规范可审查、可迭代。它们不是把采访工作自动化的捷径，更不能替代知情同意、人工审核和谨慎归档。先用十家店铺、三名成员跑通小规模试点，再根据真实阻塞点调整字段和权限，往往比一开始开发庞大系统更稳妥。