周二的技术调研困境
周一开完需求会，你领到了一个任务："这个功能用XX技术实现，你研究一下可行性。"
然后你开始干活——搜文档、看博客、翻GitHub、问同事。三天过去了，你有一堆零散的信息，但说不清楚：
- 哪个方案最适合我们的场景？
- 有没有隐藏的坑？
- 团队能不能快速上手？
- 维护成本有多高？
最后你稀里糊涂选了一个，上线后才发现各种问题——学习曲线陡峭、社区不活跃、跟现有架构不兼容。
你花了三天调研，结果比"直接干"好不到哪去。
问题不在你不够努力，而在你缺少一个结构化的调研框架。
这个模板的作用就是：给你一个系统性的技术评估流程，让你用AI当调研助手，在半天内产出高质量的技术选型报告。
核心模板：技术方案调研评估
把下面这段复制到 Claude 或 ChatGPT（推荐 Claude，上下文长适合长文档）：
你是一位资深技术架构师，擅长技术方案调研和选型评估。现在你是我的技术调研助手。
【调研背景】
- 项目/功能名称：[一句话描述]
- 业务目标：[这个功能要解决什么问题？有什么业务价值？]
- 技术约束：[如：必须用现有技术栈 / 性能要求QPS>1000 / 数据敏感需本地部署]
【候选技术方案】（至少2个，越多越好）
- 方案A：[名称 + 一句话描述]
- 方案B：[名称 + 一句话描述]
- 方案C：[可选，如果没有可以不写]
【团队现状】
- 技术栈：[如：Java Spring Boot + React + PostgreSQL]
- 团队规模：[X人，前端X人 / 后端X人 / 全栈X人]
- 经验水平：[如：后端3-5年经验，对XXX熟悉]
- 可投入时间：[如：调研1天 + 开发2周]
【评估重点】（按重要程度排序）
1. [如：开发效率]
2. [如：运行性能]
3. [如：长期维护成本]
4. [如：团队学习成本]
请帮我完成以下调研：
第一部分：方案概述
- 对每个方案用一句话概括：它是什么、解决什么问题、适合什么场景
- 列出每个方案的"一句话卖点"和"一句话软肋"
- 标注每个方案的成熟度（实验性/成熟/过时）
第二部分：多维度对比
制作一个对比表格，包含以下维度（按你标注的权重排序）：
- 开发效率（上手难度、开发速度、代码量）
- 运行性能（吞吐量、延迟、资源占用）
- 可维护性（代码可读性、扩展性、文档质量）
- 团队适配度（学习曲线、是否有经验可复用、是否需要招新人）
- 生态成熟度（社区活跃度、Issue响应速度、版本更新频率）
- 风险因素（许可证、供应商锁定、技术债务）
每个维度打分（1-5分），标注权重，计算加权总分。
第三部分：坑点预警
- 每个方案最大的坑是什么？（踩过的雷、已知的bug、常见误区）
- 在我们的场景下，哪个坑最可能导致上线失败？
- 有没有"看起来很好但实际很坑"的隐形问题？
第四部分：推荐方案
- 基于以上分析，推荐一个方案并说明理由
- 如果推荐方案A，同时说明什么情况下应该选B或C
- 给出一个"后悔最小化"判断：选了X方案，三个月后最可能后悔的点是什么？
第五部分：落地路线图
- 如果选推荐方案，给出一个最小可行验证（PoC）计划
- 需要几天？做什么？产出什么？
- 验证通过的判断标准是什么？
- 验证不通过时的Plan B是什么？
三种高频场景变体
变体一：框架/库选型（前端或后端）
适合：要选一个新技术栈或工具库
【调研背景】
- 项目：用户中心服务重构
- 业务目标：支持10万日活，响应时间<200ms
- 技术约束：必须兼容现有PostgreSQL，需要REST API
【候选方案】
- 方案A：Node.js + Express
- 方案B：Go + Gin
- 方案C：Python + FastAPI
【团队现状】
- 团队3人，后端2人（Java经验3年+），前端1人
- 可投入调研时间：1天
- 可投入开发时间：2周
【评估重点】
1. 开发效率
2. 运行性能
3. 团队学习成本
请帮我完成技术方案调研评估。
变体二：第三方服务 vs 自建
适合：纠结"用SaaS还是自己搞"
【调研背景】
- 项目：邮件发送功能
- 业务目标：支持订单通知、营销邮件，月发送量约10万封
- 技术约束：需要有发送日志、打开率统计
【候选方案】
- 方案A：直接用SendGrid/Mailgun（SaaS）
- 方案B：自建基于Nodemailer + SMTP
- 方案C：用AWS SES
【团队现状】
- 团队2人全栈，有运维经验但时间有限
- 不想在邮件基础设施上花太多时间
【评估重点】
1. 长期成本（不只是价格，含运维时间）
2. 可靠性（送达率、故障恢复）
3. 可控性（数据隐私、定制能力）
请重点帮我分析：自建和用SaaS的隐性成本差距有多大？值不值得自己搞？
变体三：架构模式选型
适合：决定用什么样的架构模式
【调研背景】
- 项目：内部数据看板
- 业务目标：多部门数据汇总展示，支持实时刷新
- 技术约束：需要支持10个以上数据源，权限隔离
【候选方案】
- 方案A：单体应用 + 统一数据层
- 方案B：微服务架构（每个数据源一个服务）
- 方案C：Serverless + API Gateway
【团队现状】
- 团队5人，有微服务经验但不多
- 预计维护周期：1年以上
【评估重点】
1. 架构复杂度 vs 团队能力匹配
2. 扩展性（未来加数据源的成本）
3. 运维成本
请重点帮我分析：微服务在这个场景下是"必要"还是"过度设计"？
快速版（10分钟搞定）
赶时间？用这个精简版：
帮我评估以下技术方案，用于[项目简述]。
候选方案：
- A：[方案名] — [一句话]
- B：[方案名] — [一句话]
团队：[X人，技术背景：____]
约束：[关键限制条件]
请给我：
1. 两个方案的对比表格（开发效率、性能、维护成本、学习成本四个维度）
2. 每个方案最大的坑
3. 推荐哪个 + 一句话理由
4. 如果用推荐方案，第一周该做什么
使用技巧
不要只列"好"的方案。 调研时人本能地只找支持自己观点的信息。让AI同时分析每个方案的"软肋"，能帮你发现真正的问题。
把团队现状写具体。 AI不知道你的团队会什么、不会什么。写清楚"后端有2人，Java经验3年，没接触过Go"，它才能给出贴合实际的评估。
权重比打分更重要。 同样的分数，不同权重下结论可能完全相反。花2分钟想清楚"我们最在意什么"，比纠结每个维度打几分更有价值。
让AI给出"后悔最小化"判断。 这是这个模板最有价值的部分——不是告诉你哪个最好，而是告诉你选了A之后最可能后悔什么。这能帮你做出更务实的选择。
PoC验证比文档调研更靠谱。 再好的分析也只是纸上谈兵。让AI帮你设计一个1-2天的最小验证计划，花半天时间动手试一下，比看十篇博客有用。
保存调研结果当"决策证据"。 把AI的输出存下来，分享给团队成员和老板。以后有人质疑你的选择，你有完整的分析过程可以拿出来——这是专业性的体现。
效果示例
输入：
【调研背景】
- 项目：用户行为分析系统
- 业务目标：追踪用户在全站的行为路径，支持漏斗分析和A/B测试
- 技术约束：已有PostgreSQL，需要对接现有的用户系统
【候选方案】
- 方案A：自研（基于Kafka + ClickHouse）
- 方案B：用SaaS（Mixpanel / 神策数据）
- 方案C：开源方案（PostHog自建）
【团队现状】
- 团队4人，后端2人（Java经验），前端1人，数据1人
- 无大数据基础设施经验
- 可投入时间：调研2天 + 开发1个月
【评估重点】
1. 开发效率
2. 长期运维成本
3. 数据隐私（用户数据不能出公司）
AI输出：
第一部分：方案概述
| 方案 | 一句话 | 卖点 | 软肋 | 成熟度 |
|---|---|---|---|---|
| A: 自研 | 用Kafka收数据，ClickHouse存和分析 | 完全可控，无数据泄露风险 | 基础设施复杂，团队无经验 | 成熟但复杂 |
| B: SaaS | 第三方分析平台，接入SDK即可 | 上手最快，功能开箱即用 | 数据出公司，长期成本高 | 成熟 |
| C: PostHog | 开源分析平台，自建部署 | 功能接近SaaS，数据自持 | 需要自己运维，资源消耗不小 | 较成熟 |
第二部分：多维度对比
| 维度(权重) | A:自研 | B:SaaS | C:PostHog |
|---|---|---|---|
| 开发效率(5) | 2 | 5 | 3 |
| 运维成本(4) | 2 | 4 | 3 |
| 数据隐私(4) | 5 | 1 | 4 |
| 团队适配(3) | 1 | 4 | 3 |
| 加权总分 | 2.7 | 4.2 | 3.3 |
第三部分：坑点预警
- A（自研）最大坑：ClickHouse的查询优化需要专门经验。团队没有大数据背景，上线后查询慢、成本高的问题会接踵而至。建议：如果选A，必须招一个有ClickHouse经验的人，或者安排2周专门学习。
- B（SaaS）最大坑：数据出公司的合规风险。如果你的用户数据涉及敏感信息（用户ID、行为轨迹），可能违反公司数据安全政策。建议：先和法务确认是否允许。
- C（PostHog）最大坑：自建运维成本被低估。PostHog需要Redis、ClickHouse、Kafka等多个组件，服务器资源消耗不小。建议：至少需要2台8C16G的服务器。
第四部分：推荐方案
推荐：方案C（PostHog自建）
理由：你明确说了"数据不能出公司"，这直接淘汰了方案B。方案A虽然可控性最强，但团队没有大数据经验，1个月内很难跑通。PostHog在"数据自持"和"上手难度"之间取得了最好的平衡。
什么情况下选B：如果法务确认数据可以出公司，且你愿意为省时间付年费，SaaS是最快的路。
什么情况下选A：如果你们打算长期投入大数据方向，或者对数据控制有极端要求，自研是终极方案。但现在不是好时机。
后悔最小化判断：选A（自研），三个月后最可能后悔的点——花了一个月搭好基础设施，结果发现查询性能不达标，还要花时间优化。选C的话，至少功能能跑起来。
第五部分：落地路线图
| 时间 | 任务 | 产出 |
|---|---|---|
| Day 1 | 部署PostHog（Docker Compose一键部署） | 可用的PostHog环境 |
| Day 2 | 前端接入SDK，验证数据采集 | 首条用户行为数据 |
| Week 1-2 | 配置核心事件（页面浏览、点击、转化） | 完整的事件追踪体系 |
| Week 3-4 | 搭建漏斗分析和A/B测试 | 第一个分析报告 |
验证通过标准：能正确追踪用户从 landing page 到 注册完成 的完整路径，数据准确率>95%。
Plan B：如果PostHog自建的运维成本超出预期，切换到方案B（SaaS）的免费额度范围内，先把业务跑起来。
和已有模板的关系
| 模板 | 解决什么问题 | 与本模板的关系 |
|---|---|---|
| 周四决策框架 | 多个选项之间的最终决策 | 前置步骤：先做技术调研，再做决策 |
| 周三编程提效 | 写代码时的协作 | 后置步骤：选完方案后进入开发 |
| 周四API文档 | 接口文档生成 | 后置步骤：方案确定后生成文档 |
| 代码审查 | 代码质量检查 | 后置步骤：开发过程中使用 |
本模板是技术决策链的第一环——调研评估。它不帮你做最终决定（那是周四决策框架的事），但它帮你把"拍脑袋"变成"有依据的选择"。
进阶用法
建立你的"技术选型档案"。 每次调研结果存到一个固定位置（Notion/飞书文档都行）。三个月后回头看，你会发现自己做过的技术决策有清晰的脉络——哪些判断是对的，哪些是运气。
把调研结果变成团队共享文档。 不要只给自己看。把AI的输出整理成一份团队可读的文档，附上你的判断和理由。这能减少后续沟通成本，也能让团队成员理解你的决策逻辑。
和"POC验证"联动。 调研只是纸上谈兵。让AI帮你设计一个2-3天的PoC计划，花一点时间动手验证，比看十篇博客更有价值。PoC的结果会反过来修正你的调研结论。
月度技术雷达。 每个月花30分钟让AI帮你扫描一下你技术栈周边的新动态——"我这个技术栈最近有什么值得关注的更新？"保持技术敏感度，不只是为了当下，也是为了未来的选择。
什么时候不该用
- 技术方案已经定了。 如果老板已经拍板了，不需要再调研。这个模板的价值在于"帮你做出选择"，不在于"在已确定的方向上找补"。
- 你是纯执行者不需要决策。 如果你的工作只是"按既定方案实现"，不需要你做技术选型，这个模板对你意义不大。
- 时间极度紧张。 如果明天就要上线，没时间去调研。先干活，事后补分析。这个模板适合"有时间做正确的事"的场景。
- 技术问题本身很简单。 CRUD增删改查不需要技术调研。只有涉及架构选型、工具选型、第三方服务选型时才需要这个模板。
写在最后
技术调研不是"查资料"——那是搜索引擎干的事。
技术调研是在约束条件下做权衡。没有完美的方案，只有"最适合当下"的方案。AI帮不了你决定"什么是最适合的"——但它能帮你把"适合"的标准看清楚，把每个方案的真面目摊开。
周二下午，关掉Slack，花半天时间认真调研一次。
一个月后你会感谢现在的自己——因为那个决策，影响了后面半年的开发效率和心情。
你选的技术方案，决定了你接下来三个月每天上班的心情。
别让"感觉差不多"毁了你的选择。让AI帮你把路看清，再走。