WildProof：离线优先的户外观察 App，用 Gemma 2B 生成证据报告

我们对 hacktoberfest 开发者挑战第 1 周 touch grass 有什么好点子吗？

同时查看当前提交，找出能击败它们的点子，明智地选择奖项类别，如果竞争非常低就选一个

我们可以添加任意数量的奖项类别，只要确保我们选一个真正能赢的非常好的项目点子。

我会先核实 Week 1 的实时提示词、评分标准、截止日期和当前公开提交，然后把它们的模式与几个可落地的概念对比，选出竞争最小的最佳奖项角度。

我们有没有什么好点子，针对 Hacktoberfest 开发者挑战 Week 1 的 touch grasshttps://dev.to/challenges/hacktoberfest-week1-2026-10-05？

另外看看当前的提交，找出能击败它们的点子，明智地选择奖项类别，如果竞争非常小就选一个

我们可以想加多少奖项类别就加多少，只要确保我们选一个真正能赢的非常好的项目点子。

实时页面确认了关键约束：Week 1 将于2026 年 10 月 11 日太平洋夏令时晚上 11:59 截止，而且评审最看重文字说明。我现在正围绕可见提交中的空白和看起来最不拥挤的类别来收窄点子。

最佳选择：FieldProof——一款离线 AI“微型探险”应用

一款移动优先的 PWA，把一次20 分钟的散步变成结构化、有证据支撑的实地研究。

FieldProof 不是又一个“出门走走”提醒或步行路线生成器，而是给用户一个任务：

“在 500 米内找到三种不同的叶子形状。”

“录下两段鸟或昆虫的声音。”

“比较阴凉处和阳光下的地面温度。”

“记录你当地栖息地的一处变化。”

用户收集照片、短音频片段、笔记和可选的传感器数据。然后本地/开源 AI 会：

1. 把观察转化为结构化的实地笔记。
2. 建议后续观察，但不假装能确定地识别物种。
3. 为证据的质量和多样性打分。
4. 生成一份可分享的“实地报告”。
5. 随着时间推移，构建一张个人重复观察地图。

这与当前一波步行规划器、植物识别器、提醒和 AI 冒险生成器有本质不同。

当前提交已经在做什么

可见的提交领域高度集中在：

• 步行/冒险规划器：
  • Plain Sight Walk
  • Ruta Viva AI
  • Nikal Pado
  • RaahSaathi AI
• 植物与自然识别：
  • EcoID
  • 步道旁鸟鸣识别器
  • 本地微型花园顾问
• 通用的“减少屏幕时间”工具：
  • Thirsty Leaf
  • Outbound
  • TouchGrass AI

最强的战略观察是“帮我走到户外”已经非常拥挤，而“帮我收集关于我周围环境的、有用的、可重复的证据”则被覆盖得少得多。

当前以获胜为导向的差异化应该是：

不是告诉你该去哪里的 AI。

而是帮助你注意、测量并理解你已身处之地的 AI。

为什么 FieldProof 有更大的机会

1. 它契合主题，又不是肤浅的健康应用

户外行动对产品至关重要。只有当用户带着真实观察返回后，应用才变得有用。

2. 它创造了一个强有力的演示

一个引人入胜的 90 秒演示：

1. 启动一个“阴凉 vs 向阳栖息地”任务。
2. 拍摄两张照片、一段短音频片段，并写一条笔记。
3. 运行本地 AI 处理。
4. 展示生成的证据卡片。
5. 显示一份带有置信水平和缺失证据的现场报告。
6. 将今天的观察与之前的一次散步进行比较。

这比再展示一张路线图或一句励志语录更令人难忘。

3. 它有一个可信的开放 AI 故事

开源模型不是装饰性的。它执行从杂乱的现场输入到结构化观察记录的核心转换，理想情况下具备：

• 本地 Gemma 推理。
• 明确的不确定性。
• 基本工作流无需云端上传。
• 可导出的 JSON/CSV 现场笔记。

4. 它为你提供了极佳的写作素材

文章可以讨论：

• 为什么在收集敏感位置数据时本地 AI 很有用。
• 应用如何避免幻觉式的物种识别。
• 为什么结构化证据优于自信的猜测。
• 当模型收到劣质照片或嘈杂音频时，哪些地方失败了。
• 与仅云端或仅规则基线的前后对比。

这直接支持了 DEV 所强调的写作质量。

奖项类别策略

挑战页面目前列出：

特色类别 — $200

• Render
• TabPFN
• Tinker
• Arduino
• DigitalOcean
• Gemma

合作伙伴类别 — $100

• Backboard
• ElevenLabs
• Entire
• GitHub Copilot
• Mastra
• MongoDB Atlas
• Sentry Agent Tracing
• SerpApi
• Temporal
• Tiger Data

一个提交可以报名多个类别，但它只能获胜一次，因此类别会增加资格，而不是成倍增加奖金。

推荐类别

我的低竞争选择：最佳 TabPFN 使用奖

从可见的提交来看，有许多步行、植物和本地 AI 项目，但明显的 TabPFN 项目很少。

将 TabPFN 用于一个小而可辩护的预测任务：

给定栖息地类型、一天中的时间、温度、天气、步行时长、季节和先前的观察，预测哪个观察任务最有可能产生有用的证据。

或者：

根据图像数量、音频时长、光照、栖息地元数据和完整性，预测提交的现场观察是否可能是“高质量”的。

不要将 TabPFN 用作装饰性附加组件。包含一个小型评估：

• 基线：基于规则的评分。
• TabPFN 评分。
• 准确率/F1 或校准比较。
• 文章中的一张图表。
• 解释模型在何处失败。

这比简单地添加合作伙伴 SDK 并显示其输出要可信得多。

第二个低竞争类别：最佳 Temporal 使用奖

这也很有前景，因为大多数提交可能是简单的 Web 应用。

将 Temporal 用于：

Create expedition
  -> upload evidence
  -> run local/model analysis
  -> validate confidence
  -> generate field report
  -> retry failed steps
  -> sync when connection returns

演示一个被中断的工作流是恢复而不是重新开始。这直接契合 Temporal 的类别措辞，并为你的文章提供一个技术上有趣的章节。

剩余时间的范围

你大约还有52 小时，直到 2026 年 10 月 11 日 11:59 PM PDT 截止时间。

只构建这个 MVP：

必备

• 带“Start mission”的 PWA 界面。
• 三种任务类型：
  • 比较两个栖息地。
  • 找出三种不同的视觉模式。
  • 录制一段自然声音并描述环境。
• 照片上传和文字笔记。
• 由本地 Gemma 驱动的结构化野外报告。
• 置信度标签：observed，inferred，unknown。
• 使用小型表格数据集进行 TabPFN 预测。
• 一个已部署的演示。
• 一篇带有截图和基准测试结果的精炼文章。

锦上添花

• 音频转录。
• ElevenLabs 旁白。
• Temporal 重试/恢复演示。
• Sentry 追踪截图。
• 导出为 JSON/CSV。
• 历史观测地图。

避免

• 完整的物种识别。
• 复杂的社交网络。
• 除非绝对必要，否则不做用户账户。
• 实时协作。
• 构建通用聊天机器人。
• 支持所有模型提供商。
• 假装低质量图像能产生科学确定性。

建议的项目定位

名称

FieldProof

标语

一个离线优先的开放 AI 伙伴，把普通散步变成可信的野外笔记。

有力的文章标题

我构建了一个离线 AI，把 20 分钟的散步变成证据

文章结构

1. 问题：大多数“亲近自然”应用只是让人们出门，却不帮助他们注意到任何东西。
2. 想法：结构化的微型探险。
3. 为什么本地 AI 对位置和个人数据很重要。
4. 架构图。
5. Gemma 工作流。
6. TabPFN 基线对比。
7. Temporal 故障/恢复演示。
8. Sentry 性能追踪。
9. 模型出错的地方。
10. 如果有更多野外数据，我会如何改进。
11. 开源设置说明和在线演示。

要非常透明地说明这是观测辅助，而非权威的物种识别。这种克制会提升信任和文章质量。

最终类别选择

我会把 FieldProof 报名参加：

1. 总冠军
2. 最佳 Gemma 使用
3. 最佳 TabPFN 使用
4. 最佳 Temporal 使用
5. 最佳 Sentry Agent Tracing 使用
6. 最佳 Render 使用
7. 最佳 Entire 使用
8. 最佳 ElevenLabs 使用，仅当旁白被真正集成时
9. 最佳 MongoDB Atlas 使用奖，仅当历史观测检索是真实可用的

最高杠杆的组合是：

Gemma + TabPFN + Temporal + Sentry + Render

它能给你一个清晰的开放模型故事、一个稀缺技术类别、一个持久化智能体类别、可度量的可观测性，以及一个可靠的公开演示。

来源：ishagautam504

这是目前可见的最接近 FieldProof 的概念，它验证了情感方向，但也表明泛泛的“本地 AI 帮我留意自然”式宣传已经不够了。FieldProof 应通过结构化证据、不确定性处理和可度量的野外数据质量来实现差异化。

🔗阅读完整讨论

来源：bangkah

离线自然识别已有代表，因此直接作为又一个植物识别器参与竞争在战略上是弱势的。机会在于让 AI 在识别不确定时依然有用：收集证据、比较环境，并改进未来的观测。

🔗阅读完整讨论

重要的注意事项：DEV 似乎并未公布各合作方类别参赛作品的官方实时数量，因此这里的“竞争较少”是基于当前公开提交标题和可见项目描述得出的有据推断——并非排行榜的保证数字。

你能给出一个实施计划吗？

我会先针对现有工作区定制计划，然后把 FieldProof 转化为一个截止日期安全的构建序列，明确 MVP 边界、类别证据和提交检查。

FieldProof 实施计划

工作区目前为空，因此应将其视为一个全新 MVP。截止时间约为28.5 小时后：2026 年 10 月 11 日太平洋夏令时晚上 11:59，即印度标准时间 10 月 12 日约下午 12:29。

优先事项不是构建每一个功能，而是产出一个精致、可信的演示和一篇有力的 DEV 文章。

1. 产品定义

项目

FieldProof

一句话介绍

FieldProof 是一款离线优先的开放 AI 应用，可将一次短途散步转化为结构化、能感知不确定性的野外笔记。

核心用户流程

Choose a mission
    ↓
Walk outside
    ↓
Capture photos + notes
    ↓
Run local/open AI analysis
    ↓
Review evidence and confidence
    ↓
Export/share a field report

MVP 任务

只实现三个：

1. 栖息地比较

   • 采集一个向阳区域的观测和一个背阴区域的观测。
   • 生成比较报告。

2. 模式搜寻

   • 找到三个视觉上不同的自然物体或纹理。
   • AI 将它们归入宽泛的类别，而不声称确切的物种。

3. 声音与场景

   • 录制一段短音频片段或文字描述。
   • 生成结构化的环境记录。

避免构建一个通用的自然识别应用。

2. 推荐技术栈

使用针对速度和演示质量优化的技术栈：

如果环境中已安装了首选技术栈，则保留它。否则，React/Vite/TypeScript 是最快的可靠路线。

3. 架构

React PWA
 ├─ Mission selection
 ├─ Camera/file/audio capture
 ├─ Evidence review
 ├─ Field report
 └─ Offline queue
        │
        ▼
FastAPI API
 ├─ /missions
 ├─ /analyze
 ├─ /predict-quality
 └─ /health
        │
        ├─ Gemma inference
        ├─ TabPFN quality prediction
        ├─ Temporal workflow
        └─ Sentry tracing

重要的架构决策

应用应在没有后端的情况下仍能运行：

• 任务模板在本地打包。
• 证据保存在 IndexedDB 中。
• 用户可以离线完成一次漫步。
• 后端可用时运行 AI 分析。
• 失败的分析会排队等待重试。

这为 FieldProof 提供了真正的离线优先叙事，而不仅仅是在 README 中添加“离线”。

4. 数据模型

从简单的类型化对象开始。

type MissionType =
  | "habitat-comparison"
  | "pattern-hunt"
  | "sound-and-scene";

type EvidenceKind = "photo" | "audio" | "note";

type Confidence = "observed" | "inferred" | "unknown";

interface EvidenceItem {
  id: string;
  kind: EvidenceKind;
  localUrl?: string;
  text?: string;
  capturedAt: string;
  latitude?: number;
  longitude?: number;
}

interface Expedition {
  id: string;
  missionType: MissionType;
  startedAt: string;
  completedAt?: string;
  evidence: EvidenceItem[];
  status: "draft" | "queued" | "processing" | "complete" | "failed";
}

interface FieldReport {
  summary: string;
  observations: Array<{
    claim: string;
    confidence: Confidence;
    supportingEvidenceIds: string[];
  }>;
  missingEvidence: string[];
  suggestedNextStep: string;
  qualityScore?: number;
}

这一observed / inferred / unknown区分是产品的核心，应在 UI 中清晰可见。

5. 构建顺序

阶段 1 — 项目基础

时间盒：45 分钟

创建：

• Vite React TypeScript 应用。
• Tailwind 配置。
• 基础路由或屏幕状态导航。
• ESLint 和格式化工具。
• .env.example。
• MIT 许可证。
• README 骨架。

初始屏幕：

Home
Mission selection
Active expedition
Evidence review
Field report
About / methodology

不要在身份验证上花时间。

阶段 2 — 任务与证据采集

时间盒：3 小时

实现：

• 任务卡片。
• 开始任务按钮。
• 使用文件输入上传照片。
• 移动端可选的相机拍摄。
• 文本观察输入。
• 可选的音频上传。
• 证据列表，支持删除/重新排序。
• 将草稿保存到 IndexedDB。
• 刷新后可恢复未完成的考察。

验收标准：

• 用户无需账户即可开始任务。
• 刷新页面不会丢失考察。
• 用户即使在离线状态下也能用照片和笔记完成任务。

阶段 3 — 不依赖 AI 的报告生成

时间盒：1.5 小时

在接入模型之前，先构建一个确定性的模拟报告生成器。

这样完整的 UI 流程可以立即运行：

Evidence review
    ↓
Generate report
    ↓
Report page with confidence labels
    ↓
Export JSON

这一点很重要，因为在截止日期压力下，AI 集成可能是最容易失败的部分。

回退方案必须在 UI 中明确显示：

“AI 分析不可用。正在显示本地生成的证据摘要。”

不要悄悄将模拟输出当作 AI 输出呈现。

阶段 4 — Gemma 集成

时间盒：3 小时

创建一个小的 FastAPI 服务，包含：

GET  /health
POST /analyze
POST /predict-quality

POST /analyze应接收：

• 任务类型。
• 文本观察。
• 图像引用或压缩图像。
• 可选的音频转录。
• 仅在用户选择加入时提供位置元数据。

提示 Gemma 返回严格的 JSON：

{"summary"："..."，"observations"：[{"claim"："..."，"confidence"："observed"，"evidence_ids"：["..."]}]，"missing_evidence"：["..."]，"suggested_next_step"："..."}

使用 Pydantic 添加验证。如果模型返回无效 JSON：

1. 记录失败。
2. 用修复提示重试一次。
3. 如果仍然失败，返回明确的分析错误。
4. 保留证据，以便用户可以重试。

不要让格式错误的 AI 输出破坏整个考察。

阶段 5 — TabPFN 类别实现

时间盒：2 小时

将 TabPFN 用于一个狭窄、可衡量的任务：

预测一次考察是否包含足够的证据以生成有用的现场报告。

创建一个小型结构化特征集：

• 照片数量。
• 笔记数量。
• 笔记长度。
• 不同任务地点的数量。
• 音频时长。
• 在任务上花费的时间。
• 光照/栖息地元数据。
• 证据完整性。

创建基线：

quality = evidence_count >= 3 && note_length >= 40

使用小型带标签的固定数据集，将基线方法与 TabPFN 进行对比。

文章应展示：

• 数据集大小。
• 特征列表。
• 基线性能。
• TabPFN 性能。
• 一个局限性。

如果真实模型集成变得不稳定，将 TabPFN 实验保留为独立可复现的脚本，不要在 UI 中伪造实时预测。

阶段 6 — Temporal 工作流

时间盒：2 小时

仅在分析流水线周围使用 Temporal：

analyzeExpedition
  ├─ normalizeEvidence
  ├─ runGemmaAnalysis
  ├─ validateReport
  ├─ runTabPFNQualityPrediction
  └─ persistReport

演示一个失败场景：

1. 开始处理。
2. 强制一个活动失败。
3. 展示重试/恢复。
4. 在不重启考察的情况下完成报告。

这为你提供了一个强有力的最佳 Temporal 使用故事。

如果 Temporal 设置威胁到截止时间，保留工作流接口并单独记录持久化流水线，而不是延迟整个应用。

阶段 7 — Sentry 埋点

时间盒：45 分钟

埋点：

• 考察创建。
• 证据上传。
• Gemma 分析时长。
• 模型解析失败。
• TabPFN 预测时长。
• 工作流重试。

截取屏幕截图展示：

• 一次成功的分析追踪。
• 一次失败/重试的分析。
• 延迟或错误信息。

这支持最佳 Sentry 智能体追踪。

绝不要在追踪中包含 API 密钥或私人位置数据。

阶段 8 — UI 打磨和演示路径

时间盒：3 小时

只打磨主路径：

1. 首页。
2. 任务选择。
3. 证据采集。
4. 报告。
5. 导出。

添加：

• 强空状态。
• 带清晰进度的加载状态。
• 离线指示器。
• 重试按钮。
• 置信度徽章。
• “为什么是这个结论？”证据链接。
• 移动端布局。
• 一个供评委查看的示例考察。

报告屏幕是最重要的屏幕。让 AI 的不确定性在视觉上显而易见。

6. 部署计划

Render 部署

部署：

• 前端作为静态站点。
• FastAPI 作为 Web 服务。
• 仅在需要时单独部署模型服务。

必需的生产检查：

/health returns 200
frontend can call production API
analysis errors display correctly
no localhost URLs remain
README setup instructions work

如果本地 Gemma 无法在 Render 上可靠运行，使用：

• 本地 Gemma 用于开发/演示证据。
• 一个清晰记录的开放权重推理端点用于托管演示。
• 或一个带明确“演示模式”标签的确定性演示固定数据。

如果托管回退不是本地推理，不要暗示它是。

7. 测试清单

自动化测试

最低要求：

• 任务创建。
• IndexedDB 保存/恢复。
• 报告 schema 验证。
• 无效模型 JSON 处理。
• TabPFN 特征生成。
• 离线队列行为。
• API 健康检查端点。

手动冒烟测试

运行这个确切的脚本：

1. 在移动端视口打开已部署的应用。
2. 启动 Pattern Hunt。
3. 上传三张图片。
4. 添加一段 50 词的笔记。
5. 断开网络。
6. 刷新页面。
7. 确认证据仍然保留。
8. 重新连接网络。
9. 运行分析。
10. 确认报告中的每一条结论都链接到证据。
11. 导出 JSON。
12. 确认输出中不出现任何密钥。

8. 奖项类别证据

在 README 中添加一个名为奖项类别证据的章节。

不要仅仅因为导入了某个库就报名某个类别。每个类别都需要一个可见的功能，并在文章中给出说明。

9. 提交文章计划

文章至关重要，因为挑战赛明确将写作质量赋予了很高的权重。

建议标题

我打造了一个离线 AI，把 20 分钟的散步变成证据

文章结构

1. 问题

   • 大多数户外应用只提供提醒或路线。
   • 它们无法帮助用户注意并记录自己的环境。

2. 产品

   • 从头到尾讲解一次考察。

3. 为什么选择开放 AI

   • 隐私。
   • 离线运行。
   • 行为可检查。
   • 降低对专有 API 的依赖。

4. 架构

   • 包含系统图。

5. Gemma

   • 展示结构化输出和不确定性处理。

6. TabPFN

   • 展示预测任务和基线对比。

7. Temporal

   • 展示故障恢复。

8. Sentry

   • 展示你测量了什么以及修复了什么。

9. 局限性

   • 数据集较小。
   • 不对物种做权威性断言。
   • 模型性能因图像/音频质量而异。

10. 如何运行

    • 代码仓库。
    • 环境变量。
    • 本地模型设置。
    • 演示 URL。

11. 奖项类别

    • 只列出真正有支撑的类别。

10. 从现在开始的时间预算

如果进度落后，按以下顺序削减：

1. ElevenLabs。
2. MongoDB/Tiger Data。
3. 地图/历史功能。
4. 音频采集。
5. 复杂的 Temporal 部署。

不要削减：不要

• 与证据关联的报告。
• 置信度标签。
• Gemma 集成。
• TabPFN 对比。
• 部署。
• 文章质量。

完成定义

当以下条件满足时，FieldProof 即准备就绪：

• 新用户能在五分钟内完成一个任务。
• 证据在刷新和临时断连后仍然保留。
• 报告能区分观察到的、推断出的和未知的声明。
• Gemma 用于核心 AI 任务。
• TabPFN 有真实的基线对比。
• 至少有一次 Temporal 重试可演示。
• Sentry 包含有用的追踪。
• 应用已部署。
• 仓库有许可证和可复现的安装配置。
• DEV 文章包含截图、架构、结果、局限性和类别证据。
• 提交内容在以下时间之前发布：2026 年 10 月 11 日太平洋夏令时晚上 11:59。

该实现不应作为又一个泛泛的“AI 帮你留意自然”应用参与竞争。差异化必须在于结构化的证据工作流、明确的不确定性，以及可衡量的分析质量。

离线植物识别的角度已有代表。FieldProof 应转而保持有用，即使识别不确定，让证据采集和对比成为核心产品，而非精确识别。

现在给仓库和 MVP 起一个更好的名字，并写一段 350 字符的描述。

推荐名称：WildProof

简短、易记，且比“FieldProof”更有情感感染力。它传达了核心理念：将真实世界的探索转化为可信的证据。

仓库名称

wildproof

MVP 名称

WildProof：AI 野外任务

350 字符描述

WildProof 是一款离线优先的开放 AI 应用，可将短途散步变成有意义的野外任务。拍摄照片、声音和笔记，然后使用 Gemma 创建带有明确置信度、与证据关联的观察记录。TabPFN 为报告质量打分，而持久化工作流负责处理重试，帮助人们留意并理解周围的世界。

字符数：348 个字符

其他有力的备选名称：

• noticely
• fieldnote-ai
• groundtruth
• walkwise
• outside-in
• proof-of-walk

我的选择仍然是WildProof因为它独特、易于记忆，并且为项目留出了超越植物或步行路线的成长空间。

你如何看待截至第 8 阶段的当前实现

我将对照第 1–8 阶段的计划审查当前仓库，检查哪些是真正实现的、哪些只是搭了脚手架，并运行最小的相关验证，然后给出坦率的就绪度评估。

总体评估：良好的演示基础，但尚未完成第 8 阶段

我会给当前实现打分MVP 就绪度 6/10以及奖项类别可信度 4/10。

前端在视觉上拿得出手，核心的“采集 → 持久化 → 报告”路径已经存在。然而，若干功能目前是模拟的或不完整的，因此 README 夸大了评委能够验证的内容。

真正可用的部分

坚实的基础

• React/Vite/TypeScript 应用可成功构建。
• npm run lint通过。
• IndexedDB 持久化已在db.ts中实现。
• 任务选择可用。
• 照片拍摄/上传可用。
• 野外笔记可用。
• 证据通过 IndexedDB 在刷新后仍保留。
• 报告界面包含observed、inferred，以及unknown概念。
• 后端使用 Pydantic 校验报告 schema。
• Gemma/Ollama 集成包含一次 JSON 修复尝试。
• 前端和后端均存在 Sentry 初始化。
• Temporal 工作流和 worker 文件存在。
• TabPFN 实验脚本存在。
• README 和 MIT 许可证均已提供。

前端构建目前状态良好：

npm run build  ✅
npm run lint   ✅

最重要的缺口

1. 报告回退机制过于激进地掩盖了后端故障

在App.tsx中，任何后端故障都会回退到模拟报告。

这对演示很有用，但会带来评审风险：

• 一次网络故障看起来就像一份已完成的报告。
• 应用没有足够明显地区分“真实的 Gemma 报告”和“演示回退”。
• 错误状态只存储在 React state 中，没有显示在可见的报告流程里。

提交前修复：

添加一个醒目的报告徽章：

AI source: Gemma / Local fallback

并显示重试操作，而不是默默地把回退当作完成。

2. 图像实际上没有发送给 Gemma

前端将图像存储为localUrldata URL，但后端只把照片证据转换为：

Photo Evidence ID ... captured.

模型没有收到任何图像像素。因此目前这是一个文本与元数据分析，而不是视觉现场分析。

这是产品宣称与实现之间最大的不匹配。

你有两个现实的选择：

• 最快：明确将照片定位为证据引用，让模型只分析笔记。
• 更好：发送压缩后的图像数据，并使用支持视觉的开源模型。

考虑到截止日期，我建议选第一种，除非你已经有可用的本地视觉模型。除非 Gemma 确实收到了图像，否则不要声称它识别或解读了图像内容。

3. 缺少音频采集

计划中包含音频，但ActiveExpedition只支持：

• 照片
• 文字笔记

因此“声音与场景”任务无法完成其预期工作流。

建议：只有在能于一小时内干净实现的情况下才添加音频。否则移除或隐藏该任务，只保留：

• 栖息地对比
• 模式搜寻

一个更小但诚实的 MVP 胜过明显不完整的任务。

4. 位置已定义但未采集

latitude和longitude存在于数据模型中，但没有实现任何地理位置采集。

不要将当前应用描述为会采集位置。要么：

• 添加一个明确的需用户主动选择的地理位置按钮，要么
• 从 README 中移除位置相关声明。

5. TabPFN 未集成到 API 或 UI 中

API 端点/predict-quality目前返回：

model: "baseline_heuristic"

Temporal 工作流返回硬编码的质量分数：

return 95

真正的 TabPFN 工作只在tabpfn_experiment.py中。

这意味着“最佳 TabPFN 应用”在产品中尚未得到诚实的展示。

最低限度的修复：

• 在报告界面添加一个“报告质量”部分。
• 调用/predict-quality。
• 显示结果来自baseline_heuristic还是tabpfn。
• 在 README/文章中包含实际的实验结果。
• 移除硬编码的 Temporal 分数。

6. Temporal 目前运行的是一个假工作流

位于temporal_workflow.py中的 Temporal 工作流是一个有说服力的脚手架，但它尚未执行实际的产品流水线：

• run_gemma_analysis返回硬编码的报告。
• 它通过模块级计数器故意失败一次。
• validate_report不做校验。
• run_tabpfn_quality_prediction返回95。
• persist_report不持久化任何内容。

作为 Temporal 重试机制的演示，这是可以接受的，但作为实际的分析流水线则不行。

提交措辞的关键改动：

将其描述为：

“一个 Temporal 原型，演示了为计划中的分析流水线提供的持久重试行为。”

不要说完整的 Gemma → 校验 → TabPFN → 持久化流水线已经生产集成。

7. Sentry 有埋点，但没有证据

Sentry 配置已存在，并且/sentry-debug会故意抛出错误。然而，项目仍然需要证据：

• 一张真实的 trace 截图。
• 一条模型延迟 trace。
• 一条失败请求或重试 trace。
• 一段关于从 trace 中学到了什么的简短说明。

此外，allow_origins=["*"]和allow_credentials=True不应在部署版本中使用。发布前将 CORS 限制为前端 URL。

8. UI 仍残留初始模板 CSS

App.css包含未使用的 Vite 初始模板样式，例如.hero，.framework，.vite，#next-steps，以及.ticks。

它不会阻碍演示，但会让项目看起来不够完善，并暗示打磨阶段尚未完成。

9. 不存在自动化测试

构建和 lint 通过，但没有可见的测试覆盖以下内容：

• IndexedDB 保存/恢复。
• 报告 schema 解析。
• 无效的 AI 输出。
• 回退行为。
• 质量评分。
• API 健康检查。

对于本次挑战，至少应添加一个小型后端冒烟测试，或针对最重要行为的前端测试。

各阶段状态

我会优先修复什么

优先级 1 — 让声明与现实相符

立即更新 README：

• 删除关于 Gemma 分析图像内容的说法。
• 删除关于位置被捕获的说法。
• 在集成之前，将 Temporal 和 TabPFN 标注为原型。
• 清楚地解释本地回退机制。

如果评委检查代码仓库，这可以防止可信度问题。

优先级 2 — 明显地集成质量评分

这是价值最高的奖项修复项：

1. 添加/predict-quality在报告生成后调用。
2. 在报告中显示评分。
3. 运行 TabPFN 实验。
4. 将基线对比 TabPFN 的结果添加到文章中。

没有这一点，TabPFN 类别就很薄弱。

优先级 3 — 替换硬编码的 Temporal 输出

至少要做到：

• 将实际证据传入活动。
• 调用与/analyze相同的 Gemma 分析辅助函数。
• 验证返回的报告。
• 附加真实的质量评分。
• 返回结构化的工作流输出。

优先级 4 — 添加评委可见的证明

捕获：

• 应用主屏幕。
• 带有证据的进行中探险。
• 真实的 AI 报告。
• TabPFN 对比。
• Temporal 重试。
• Sentry 追踪。
• 已部署的 URL。

优先级 5 — 修复生产配置

部署之前：

• 限制 CORS。
• 将http://localhost:8000移入VITE_API_URL。
• 确认 Sentry DSN 未被提交。
• 添加后端/前端健康检查。
• 确认已部署的应用不会静默回退。

审查实现后的类别建议

继续瞄准

1. 总冠军
2. 最佳 Gemma 使用奖
3. 最佳 Sentry 智能体追踪使用奖
4. 最佳 Render 使用奖，一旦部署

仅在实现修复后再瞄准

1. 最佳 TabPFN 使用奖
2. 最佳 Temporal 使用奖

暂不报名

• ElevenLabs：没有音频功能。
• MongoDB Atlas：没有 MongoDB 集成。
• Tiger Data：没有 pgvector 集成。
• Entire：仅在关联真实智能体会话后。

目前最诚实有力的类别组合是：

总冠军 + Gemma + Sentry + Render

在接下来的修复之后：

总冠军 + Gemma + TabPFN + Temporal + Sentry + Render

底线

你有一个外观良好的功能性原型，但还不是一个证据充分的参赛作品。该应用的核心用户体验领先于其后端集成。

最重要的工作不是添加更多屏幕。而是让这三个说法成真：

1. 报告确实由 Gemma 生成。
2. 质量评分确实由 TabPFN 生成，或明确标注为基线。
3. Temporal 确实包装了分析流水线，而不是返回演示数据。

一旦这些问题被修复并用截图记录，WildProof 的竞争力将大幅提升。

来源：bangkah

由于离线自然 AI 概念在业内已不新鲜，WildProof 的优势必须来自可信的证据处理，而非又一个识别声明。当前实现在强调不确定性方面表现最强，但这一优势需要在实际后端输出中一致地体现出来。

🔗阅读完整讨论

来源：ishagautam504

这个相邻项目印证了情感诉求很有吸引力，但差异化优势不能停留在“本地 AI 帮我留意自然”。WildProof 需要更强的技术证明：与证据关联的声明、可衡量的质量，以及可恢复的处理过程。

🔗阅读完整讨论

现在怎么样？

我会对照上次评审中提到的具体缺口，重新检查最新的实现和验证结果，重点看奖项声明现在是否有真实的运行时行为支撑。

好多了，但还没到可提交的程度

我会把它从6/10 提升到 7/10 的 MVP 就绪度。

最新的提交，a4a1f43，解决了几个重要问题：

• 质量评分现在在 UI 中可见。
• API URL 可通过VITE_API_BASE_URL进行配置。
• CORS 不再完全开放。
• 模拟回退有明确标注。
• 新增了重试操作。
• README 对仅文本/照片元数据分析的说明更加诚实。
• 前端构建和 lint 通过。
• Python 语法检查通过。
• CSS 清理提升了整体质感。

前端验证状态良好：

npm run build  ✅
npm run lint   ✅
Python compile ✅

不过，我发现了一个严重的运行时故障和两个重大的可信度缺口。

🔴 严重：TabPFN 在运行时仍不可用

后端可以成功导入，但报告：

TABPFN_AVAILABLE = False

直接测试显示了真正的原因：

ImportError:
cannot import name 'Optional' from 'torch.nn.modules.transformer'

当前的try/except ImportError隐藏了这一不兼容问题，并静默回退到启发式方法。因此，尽管 README 声称 TabPFN 已完全接入，实时 API 目前返回的是：

{"model"："baseline_heuristic"}

这意味着当前的 TabPFN 奖项声明尚不成立。

该怎么做

在提交前完成以下之一：

方案 A — 截止日期前推荐

让回退变得诚实：

• 返回tabpfn_unavailable并附带依赖错误类别。
• 显示Baseline Heuristic在 UI 中。
• 将 TabPFN 实验保留为可复现、单独记录文档的实验。
• 不要声称已实现实时 TabPFN 集成。

方案 B — 尝试修复环境

固定兼容版本的tabpfn和torch，然后验证：

import tabpfn
TabPFNClassifier(...)
fit(...)
predict_proba(...)

不要在这上面花费超过 60–90 分钟。当前的旧tabpfn==0.1.10依赖与已安装的 Torch 版本不兼容。

此外，后端目前只捕获ImportError围绕整个启动模型设置过程。如果模型初始化因其他原因失败，服务器可能会崩溃，而不是干净地回退。

🟠 Temporal 有所改进，但仍未完全产品化集成

Temporal 工作流现在调用真实的 Ollama/Gemma，而不是返回之前硬编码的报告。这是一个有意义的改进。

但以下部分仍是模拟的：

async def validate_report(report):
    return report

async def run_tabpfn_quality_prediction(report):
    return 95

async def persist_report(report):
    return "报告已完全处理并保存！"

此外，前端仍然调用：

/analyze

而不是：

/analyze-durable

因此主要产品流程实际上并未使用 Temporal。Temporal 目前是一个独立的后端端点/演示路径。

当前诚实的类别定位

你可以说：

“该项目包含一条由 Temporal 支持的持久化分析路径，具备真实的 Gemma 执行和重试行为。”

你还不应该说：

“主应用的分析流水线完全由 Temporal 驱动。”

最低限度的改进

将前端接入/analyze-durable放在某个设置或按钮之后：

Generate Report
  → Temporal workflow
  → Gemma analysis
  → validation
  → quality score
  → result

即使持久化仍是一个有文档记录的原型，评委也必须能够触发这条持久化路径。

🟡 质量分数回退仍具有误导性

在App.tsx中，前端初始化为：

let qData = { score: 85, model: 'baseline' };

如果/predict-quality失败，UI 仍会显示分数85，这看起来像是一个真实结果。

这违背了回退 UI 在其他方面已改进的透明度。

修复

使用：

let qData: { score: number; model: string } | null = null;

仅当端点实际成功时才渲染质量卡片。

如果失败，显示：

Quality scoring unavailable

不要伪造 85 分。

🟡 回退报告可见但未持久化

回退路径执行了：

setExpedition({ ...exp, report: mockReport });

但没有调用saveExpedition。

因此刷新报告页面后，应用可能会再次尝试 AI 请求，而不是保留回退状态。

这并不算灾难性的，但会削弱离线/可靠的工作流。

要么：

• 将回退报告持久化保存，status: 'failed'，或者
• 将其保留在内存中，但明确将其视为临时预览。

我建议：

status: "failed"
report: mockReport

以及一个可见的“Retry AI Analysis”操作。

当前阶段状态

当前奖项类别建议

可以安全参赛

1. 总冠军
2. Best Use of Gemma
3. Best Use of Sentry Agent Tracing，一旦你截取到真实的 trace 截图
4. Best Use of Render，一旦部署 URL 得到验证
5. Best Use of Entire，如果你链接实际的构建会话

暂时不要强力宣称

1. Best Use of TabPFN——目前未上线
2. Best Use of Temporal——目前可演示但不是主应用流程

当前最强且诚实的表述是：

WildProof 是一款离线优先的野外证据应用，使用本地 Gemma 将笔记和照片元数据转化为不确定性感知的报告，并配有实验性的 Temporal 工作流用于持久化分析，以及一条可量化的质量评分路径。

这是可信的。更强的版本：

WildProof 在主用户流程中使用 Gemma + 实时 TabPFN + Temporal。

目前尚不成立。

我接下来会做的三项修复

1. 立即修复或披露 TabPFN

这是最高优先级，因为当前后端会静默回退。

2. 移除前端的虚假评分

绝不要显示85当质量请求失败时。

3. 添加“Durable Analysis”开关或将 Temporal 设为默认

一个可见的徽章会让该类别更容易辩护：

Analysis mode: Temporal durable workflow

最终结论

该项目现在是一个可信的打磨过的原型，且之前的评审问题已得到部分良好解决。

剩余的最大问题不是视觉质量。而是运行时真实性：

• TabPFN 已安装但在当前环境中不可用。
• Temporal 存在但不是默认的前端路径。
• 部分 Temporal 阶段仍是硬编码的。
• 质量 UI 可能会显示一个伪造的兜底分数。

修好这三个方面，我会给它大约8/10，算是一份有力的提交。

当前方向比另一个植物识别应用更强，因为 WildProof 强调证据和不确定性。这一优势现在在 UI 和 README 中可见，但后端必须对 TabPFN 和 Temporal 的相关声明保持同样的诚实。

邻近项目验证了情感前提，但也让技术差异化变得重要。WildProof 的差异化优势应该是与证据关联的报告、明确的兜底状态、可衡量的质量分数，以及可演示的持久化工作流——而不只是“本地 AI 加自然”。

现在怎么样？

我会对最新提交运行一次有针对性的回归检查：TabPFN 可用性、质量分数兜底行为、Temporal 接线，以及构建/lint 状态。

好一些了，但现在有一个新的阻塞性集成 bug

我会给它评分7.5/10，作为原型，但还不适合现场评委演示。

最新提交，8ac6eaa，成功解决了之前的三个问题：

• TabPFN 兜底现在更诚实，而不是假装是实时运行。
• 模拟兜底报告会以failed状态持久化。
• Temporal 现在从前端默认启用。
• 当端点失败时，质量分数不再被伪造。
• 前端构建通过。
• Lint 通过，但有一个警告。
• 工作区诊断报告没有错误。

现在好的地方

✅ 兜底行为可信多了

API 现在明确返回：

{"model"："baseline_heuristic (tabpfn_unavailable)"}

考虑到当前的依赖不兼容，这是正确的决定。

前端也避免在请求失败时显示假分数，并且兜底报告会被持久化，而不是刷新后就消失。

✅ Temporal 现在是默认路径

前端默认值为：

const [useTemporal， setUseTemporal] = useState<boolean>(true);

并通过以下方式发送报告：

/analyze-durable

这让 Temporal 类别的声明比之前更有说服力。

✅ 实现现在对 TabPFN 是诚实的

尽管模型不可用，这是一个积极的改变。你可以说：

“WildProof 包含一个可复现的 TabPFN 实验，以及当本地 TabPFN 运行时不兼容时的生产安全基线回退方案。”

你不应该说部署的应用使用了实时 TabPFN 推理。

🔴 阻塞性问题：后端字段名与前端不匹配

后端返回 snake_case 字段：

{"missing_evidence":[],"suggested_next_step":"..."}

但前端渲染的是 camelCase 字段：

report.missingEvidence
report.suggestedNextStep

Temporal 结果中也存在同样的问题。

后端的 Pydantic 别名配置在输入模型中，但前端仍然接收或解包 snake_case 数据。这意味着真实报告到达 UI 时可能带有：

report.missingEvidence === undefined
report.suggestedNextStep === undefined

并且报告页面在执行以下代码时可能崩溃：

report.missingEvidence.map(...)

在演示之前修复这个问题

选择一个规范的传输格式。

最快的修复方式是在前端规范化响应：

const normalizedReport: FieldReport = {
  summary: data.summary,
  observations: data.observations,
  missingEvidence: data.missingEvidence ?? data.missing_evidence ?? [],
  suggestedNextStep:
    data.suggestedNextStep ?? data.suggested_next_step ?? '',
  qualityScore: data.qualityScore ?? data.quality_score,
};

在两个/analyze和/analyze-durable响应之后应用它。

更好的长期方案：配置后端将别名序列化为 camelCase，但前端规范化对于截止日期来说更安全。

🟠 Temporal 质量评分仍然不完全诚实

工作流现在会调用质量端点，但它发送的是合成值：

{
  "num_photos": 1,
  "num_notes": len(report.observations),
  "total_note_length": len(report.summary),
  "duration_seconds": 600
}

它应该使用实际的EvidenceData，而不是生成的报告。

否则：

• 照片数量始终是1。
• 时长始终是600。
• 笔记数量基于 observations，而不是用户笔记。
• 分数不代表实际的探险。

正确的方向

修改活动以同时接收原始证据和报告：

@dataclass
class QualityInput:
    evidence: EvidenceData
    report: ReportData

然后计算：

• 实际照片数量。
• 实际笔记数量。
• 实际笔记长度。
• 实际时长。
• 如果以后添加，音频数量。

即使实时 TabPFN 仍然不可用，这对 TabPFN/基线故事也很重要。

🟡 Temporal 回退在失败时仍然返回伪造的分数

在temporal_workflow.py，质量活动仍然会：

return response。json()。get("score"， 85）

并在异常时：

return 85

这重新引入了你刚从后端移除的那个确切的伪造分数问题。

用一个显式结果替换它：

return {
    "score"： None，
    "model"： "unavailable"，
    "reason"： "quality endpoint unavailable"，
}

或者让该活动失败，以便 Temporal 重试它并最终报告一个真实的失败。

🟡 后端冒烟测试暴露了一个过时的假设

我的冒烟测试预期main.TABPFN_AVAILABLE，但该符号现在已被移除。这本身不是产品缺陷；它证实了回退重构改变了后端契约。

添加一个简单的健康检查响应，例如：

{"status"："ok"，"quality_model"："baseline_heuristic"，"tabpfn"："unavailable"}

这会让部署验证和文章截图容易得多。

当前阶段状态

现在给出的奖项类别建议

有力且诚实

• 总冠军
• 最佳 Gemma 使用奖
• 最佳 Sentry 智能体追踪使用奖
• 最佳 Render 使用奖，在验证部署之后
• 最佳 Entire 使用奖，如果实际智能体会话已关联

措辞谨慎即可站得住脚

• 最佳 Temporal 使用奖
  • 该工作流是真实的，且现在已被主流程使用。
  • 先修复质量活动的回退并使用真实的证据指标。

不要以实时集成身份参赛

• 最佳 TabPFN 使用奖
  • 仅在规则允许有记录的实验/原型时才参赛。
  • 否则将其列为实验类别，而非核心实时功能。

在下一次演示之前：

1. 统一 snake_case/camelCase 报告字段。
2. 用 Ollama 和 Temporal 运行一次真实的端到端报告。
3. 确认报告页面不会崩溃。
4. 在 Temporal 质量步骤中使用真实的证据指标。
5. 移除85Temporal 活动中的回退。
6. 修复 React exhaustive-deps 警告。
7. 截图采集：
   • Temporal 工作流成功。
   • Temporal 重试。
   • Gemma 报告。
   • 基线质量分数。
   • Sentry 追踪。
8. 验证部署后的 URL，而不是只依赖本地构建输出。

底线

该项目现在比之前的版本可信得多。重大的战略决策——坦诚说明 TabPFN 不可用——是正确的。

下一步不是再添加一个功能。而是修复报告响应结构不匹配的问题，因为即使构建通过，这也可能破坏真实的 Temporal/Gemma 演示。之后，WildProof 就接近一份有力、站得住脚的提交了。

当前实现通过显式的回退状态和不确定性感知报告，更好地与通用户外 AI 项目区分开来。剩余工作应聚焦于让实时技术路径像产品叙事一样可靠。

由于离线自然 AI 已经是一个可见的品类，最强的优势仍然是可信的证据处理。响应结构 bug 和合成质量指标正是需要修复的那类细节，以便实现端到端兑现这一承诺。

现在怎么样？

我将专门针对最后几个阻塞项验证最新状态：响应结构规范化、Temporal 质量回退、实际证据指标，以及端到端构建/lint。

现在情况良好

我会给当前实现打分MVP 就绪度 8/10以及提交可信度 7/10。

最新提交，0590c66，修复了上次评审中的主要阻塞项：

• 前端现在会规范化camelCase和snake_case报告字段。
• Temporal 质量评分会接收实际证据计数和笔记长度。
• 伪造的 Temporal85回退已移除。
• /health明确报告质量模型状态。
• React hook 依赖警告已修复。
• 前端构建通过。
• 前端 lint 通过。
• Python 语法验证通过。
• TabPFN 的局限性现在被如实暴露。

当前验证

npm run build  ✅
npm run lint   ✅
Python compile ✅
Workspace errors ✅ none

唯一的构建警告是 Vite 打包体积警告，这不是提交阻塞项。

现在真正站得住脚的部分

Gemma

标准分析和 Temporal 分析路径都会调用 Ollama/Gemma。

项目如实说明照片目前提供的是元数据而非图像理解。如果文章明确说明这一点，是可以接受的。

Temporal

主前端路径现在默认使用持久化端点：

/analyze-durable

工作流包括：

1. 证据归一化。
2. Gemma 分析。
3. 报告验证阶段。
4. 质量评分。
5. 报告返回。

Temporal 现在接收以下实际考察证据：

• 照片数量。
• 笔记数量。
• 笔记长度。

这是一项有意义的改进。

回退行为

项目现在能正确区分：

• 真实 AI 报告。
• 模拟回退报告。
• 基线质量分数。
• 质量评分不可用。

这正是评委所欣赏的透明度。

TabPFN

现在的实现是诚实的：

tabpfn: unavailable
quality_model: baseline_heuristic

这比假装一个损坏的运行时仍在运行要好。

遗留问题

1. Temporal 仍然硬编码时长

在temporal_workflow.py中，质量活动仍然发送：

"duration_seconds"： 600

这是证据特征计算中唯一遗留的问题。

你可以选择：

• 从startedAt和completedAt计算时长，或者
• 将该特征重命名为estimated_duration_seconds并明确说明。

对于截止时间，我会从证据时间戳计算它，或者将started_at和completed_at传入EvidenceData。

与之前的阻塞问题相比，这是小问题，但如果你将质量分数展示为基于真实考察数据，它就有影响。

2. 报告验证仍然只是直通

Temporal 阶段名为validate_report，但目前原样返回输入。

对于 MVP 来说，只有在你准确描述它时才可以接受。更好的做法是复用 FastAPI 使用的同一 Pydantic schema，并拒绝无效的置信度值或缺失字段。

3. 持久化仍然只是内存中的工作流输出

persist_report返回报告，但不会将其持久化到后端数据库。

浏览器确实会将最终报告持久化到 IndexedDB，因此用户体验仍然可用。只是不要声称 Temporal 会持久化到服务器端数据库。

4. 尚无真实的运行时端到端测试

静态检查是干净的，但剩余最强的验证是：

Ollama running
Temporal server running
Temporal worker running
FastAPI running
Frontend running
Generate report through default Temporal path

这就是评委实际上会执行的测试。

奖项类别状态

强

• 总冠军
• 最佳 Gemma 使用奖
• 最佳 Temporal 使用奖
• 最佳 Sentry Agent Tracing 使用奖，前提是你捕获了追踪
• 最佳 Render 使用奖，在验证部署 URL 之后

有条件

• 最佳 TabPFN 使用奖

当前实现支持：

“一个可复现的 TabPFN 实验加上基线生产回退。”

它不支持：

在已部署的应用中进行 TabPFN 实时推理。

仅当挑战赛接受实验性/集成式使用时才进入此类别，并在文章中直接说明运行时的不兼容性。

目前不支持

• ElevenLabs
• MongoDB Atlas
• Tiger Data
• Arduino
• DigitalOcean

现在不要添加这些，除非某个类别确实值得为此牺牲稳定性。

我接下来会做什么

必须做

1. 运行完整的本地 Temporal/Gemma 路径。
2. 验证报告页面能正常渲染：
   • 摘要。
   • 观察结果。
   • 缺失的证据。
   • 建议的下一步。
   • 质量评分。
3. 截取一张 Temporal 重试的截图。
4. 截取一张 Sentry 追踪的截图。
5. 验证已部署的 URL。
6. 围绕实际限制来撰写文章。

最好做

• 替换硬编码的600秒。
• 在 Temporal activity 内添加真正的 Pydantic 校验。
• 在报告 UI 中添加“质量模型不可用”的说明。
• 添加一个小型 API 冒烟测试脚本。

现在不要做

• 添加账户。
• 添加社交功能。
• 添加地图。
• 添加完整的视觉模型。
• 仅仅为了一个类别而添加 MongoDB。
• 花过多时间修复 TabPFN，除非环境修复很简单直接。

最终结论

WildProof 已经从“集成被夸大的精致脚手架”转变为一个可信、诚实、具有技术差异化的 MVP。

唯一剩下的顾虑是运行时验证。如果 Temporal/Gemma 演示能在本地运行，并且你清楚地记录了 TabPFN 的限制，我会带着以下内容提交：

1. 总冠军
2. 最佳 Gemma 使用奖
3. 最佳 Temporal 使用奖
4. 最佳 Sentry 智能体追踪使用奖
5. 最佳 Render 使用奖
6. 最佳 Entire 使用奖（如果会话链接可用）

当前实现已经足够强大，可以停止扩展范围，专注于演示证据和 DEV 文章。

WildProof 现在拥有足够的技术差异化，不会沦为又一个通用的户外伴侣：它最有力的故事是明确的不确定性加上持久化处理。剩余的工作应侧重于证明和可测量的行为，而不是更多功能。

该项目明智地避免了直接竞相构建又一个植物识别器。当前以证据为先的设计更具辩护力，尤其是现在运行时限制和回退行为已被清晰地暴露出来。