用 Ollama 辅助需求分析：TAPD 到 Notion 的自动化实验

需求信息经常散落在标题、描述、评论和附件中。开发前要重新整理功能点，测试时又要补充验收条件；如果只做一次复制粘贴，后续状态变化还会让 Notion 中的记录逐渐失真。这个实验希望打通 TAPD 与 Notion，并尝试用本地 Ollama 把非结构化需求整理成可继续使用的分析结果。

仓库创建于 2025 年 9 月 22 日。它最初是个人效率工具，目标不是替代产品或测试人员，而是减少重复搬运，让需求来源、分析结果和执行日志能够被追踪。

从 TAPD 拉取到 Notion 幂等写入

后端使用 Python 调用 TAPD Open API，按负责人、迭代或需求 ID 拉取 Story，并补充标签、附件和评论。写入 Notion 时，以 TAPD_ID 作为匹配依据，区分新建与更新，避免每次同步都产生重复页面。状态文件只记录上次同步时间和已跟踪 ID，用于确定增量边界与跟踪范围；它没有版本合并或冲突恢复机制。

命令行保留了 pull、update、export 等明确入口。默认路径优先输出计划动作，只有传入显式执行参数才真正写入远端。这个选择来自自动化工具最基本的风险：读取错误通常只是结果不完整，写入错误却可能批量污染已有资料，所以“先预览，再执行”比追求一次全自动更重要。

用 Ollama 生成结构化需求分析

LLM 分析模块把需求标题、编号和描述组装成提示词，请 Ollama 返回 JSON。目标字段包括摘要、核心功能、风险、验收关注点和测试点。服务端不会直接信任返回文本，而是定位 JSON、解析字段，并把字符串和数组规范成稳定结构；请求失败或格式错误会抛出清晰异常，调用方可以选择规则分析作为回退。

我选择本地 Ollama，一方面是为了学习模型服务的调用方式，另一方面是避免把业务需求默认发送到外部服务。它并不自动等于安全：模型文件、运行机器、日志和输入内容仍需管理，但至少让我能够在本地控制数据流向，并验证不同模型对结构化输出约束的响应。

这里的 AI 结果只是分析草稿。需求中的事实仍以 TAPD 原文为准，风险和测试点需要人工确认。模型适合补充遗漏视角，却不能决定业务优先级，也不能在描述不足时凭空补全真实规则。

可视化任务与日志

配套的 React 控制台把后端脚本包装成可观察任务。页面可以选择需求和操作参数，提交后轮询任务状态，并通过 cursor 增量获取日志。有新日志时缩短轮询间隔，长时间无变化时逐步放慢；刷新页面后，当前任务和日志仍保存在本地状态中。

这部分仍是普通前端工程，却直接影响自动化是否可用。没有状态、阶段和错误日志时，用户只看到一个长时间旋转的按钮，很难判断脚本正在拉取、分析还是写入。把 stdout、stderr 和系统消息区分显示后，失败可以被定位，终止操作也有明确反馈。

安全边界与未完成部分

仓库中涉及 TAPD、Notion、邮件和企业通知等外部能力，真实凭证只能通过环境变量提供，不能进入提交。常规同步、更新和清空命令默认 dry-run，只有传入 --execute 才写入；测试流落盘和邮件发送还分别保留额外确认参数。不能把后者扩大成所有命令都有确认文本，但显式执行开关至少降低了误触概率。

当前实现是面向个人环境的实验，部署、账号隔离和大规模任务队列并不完整。规则回退只能保证流程继续，并不代表分析质量与模型一致；轮询日志也不是实时流式通道。它验证了需求同步与 AI 分析可以组成一个受控工作流，但没有把自动生成结果当成最终业务结论。

这次实验的意义

这次实践让我把 AI 放进了一条真实的数据链路，而不是停留在独立聊天窗口。输入有来源，输出有 schema，写入有确认，失败有回退，过程有日志。对自动化系统来说，这些约束比提示词本身更决定可信度。

后端与模型分析代码见 TAPD_FLOW，配套控制台见 TAPD_FLOW_FRONTED。