软件项目的发现阶段从来不是一份文档，而是一堆散落的幻灯片、Google Docs 和通话记录。目标、干系人、需求、架构、粗略路线图，全在这些材料里，最后总得有人把它们拼成一份连贯的报告。

Discovery Phase AI 想接手的正是这份"第一稿"工作：上传源文件，逐条审阅模型给出的提案，然后导出报告。听起来像又一个"一键生成文档"的工具，但作者在实现里做的几个决定，反而比功能列表更值得看。

先说它到底能干什么。工具会针对发现阶段的各个环节起草内容：背景、执行摘要、问题陈述、干系人、目标与指标、用户与旅程、需求、架构、路线图。关键在于，模型写出的任何内容在你点击接受之前都不会被保存——审阅发生在落库之前，而不是事后补救。

每个阶段还挂着一个"用 AI 改进"的对话，附带质量评分和锚定在原文上的建议。改动的影响也会被追踪：你改了一条需求，系统会提示哪些目标、图表或里程碑可能已经过时。最终报告可导出为 PDF、Word、PowerPoint 或 Markdown，Mermaid 图表会渲染成图片。

技术栈上没有花活

后端是 Go 的模块化单体，用 chi 和 pgx，不引入 ORM，SQL 手写。每个模块遵循 repository → service → handler 的分层，模块之间不允许互相引用内部实现。前端是 React + TypeScript 跑在 Vite 上，富文本阶段用 Tiptap，图表用 Mermaid。数据库是 Postgres，所有状态都放在库里，因此可以并行跑多个实例。

模型侧用的是 Claude。这里有个容易被忽略的设计：模型没有任何工具权限，它的输出只被当作 JSON 解析，而且它提到的每一个记录 ID 都要先和数据库核对，通过之后才能触碰任何东西。

三道锁，锁的都是"不信任"

作者总结的第一条经验是：发给模型的一切都当作不可信数据。上传的文件、其他阶段的文本、聊天历史，全部被包装成不可信数据；一条建议性改动只能引用同一项目里真实存在的记录。这等于把提示注入的入口从源头收窄。

第二条是让 AI 的输出可审阅，而不是终稿。带类型的操作——新增、更新、删除——由用户逐条应用，比直接给出一份重写好的文档更容易让人建立信任。这个判断很务实：模型写得再顺，用户要的是能追溯的改动，不是一份无法核对的成品。

第三条是从第一天就给 AI 用量做计量。每次调用先预留额度，执行完再结算，这样并行请求也不会超支。对任何要长期跑模型调用的产品来说，这条几乎是必修课。

工具提供免费方案，不注册也能打开一份完整的示例报告，报告里的项目是虚构的。作者在结尾抛出的问题也很直接：你现在怎么做发现阶段，以及你希望这类工具在哪些地方做得不一样。

把这三条经验拎出来看，它们指向同一个态度——模型可以起草，但不能直接落笔；可以建议，但不能越权引用；可以调用，但不能透支额度。功能列表决定工具能做什么，这三条决定它敢不敢被放进真实项目里。