agentleFS
Sign inStart free
peterwangzepeterwangze/software-project-governance/skills/stage-selection/SKILL.md

stage-selection

Skill2 starsChanged 5 months agoMITView on GitHub

技术选型与方案预研——技术选型、PoC验证。阶段子工作流，可独立使用。

The file

Create a free account to mount
Files
SKILL.md

技术选型与方案预研 — 子工作流

本文件定义"技术选型与方案预研"阶段的独立子工作流。用户可单独加载本文件执行技术选型阶段。

阶段目标

从候选技术方案中选出最优方案。技术选型阶段的核心产出是"选型评估表"——回答"选什么、为什么、备选方案有什么、风险验证了吗"。

AI 编程场景特有风险

在 AI 辅助编程项目中，技术选型阶段存在以下特有风险：

风险说明缓解方向
AI 倾向"最流行"而非"最合适"AI 默认推荐社区声量最大的方案（如 React/PostgreSQL/Kubernetes），不考虑项目实际规模和团队能力，导致引入不必要的复杂度选型评估必须包含"为什么不选最流行的方案"理由；每个方案必须有"适用规模"标注
评估维度遗漏关键项AI 可能只比较功能和性能，忽略许可证风险、维护活跃度、安全漏洞历史、团队学习成本等关键维度强制评估维度 checklist——许可证、维护活跃度、安全、学习曲线、社区响应速度缺一不可
PoC 形式化AI 生成的 PoC 可能只验证"能跑起来"而不验证关键不确定性（高并发、大数据量、异常恢复），给出虚假的"验证通过"PoC 必须事先定义验证场景和通过标准；PoC 结论必须标注"验证了什么/没验证什么"
选型无差异化理由AI 给出"选 X 因为 X 好"的单方案论证，缺少"A 比 B 好在哪、为什么不用 C"的对比逻辑每个选型决策必须有：为什么选 A + 为什么不选 B + 为什么不选 C；缺少任何一项 = 选型不合格
未来承诺式选型AI 可能选择"马上要发大版本""路线图上有我们需要功能"的方案，基于未兑现的承诺做决策选型评估基于当前版本的实际能力，而非路线图承诺；如确实依赖未来版本，必须标注为风险

独立使用时的目标锚定

当本子工作流被独立加载（非通过 main-workflow.md 总入口加载）时，MUST 在执行阶段活动前完成：

  1. 目标确认：读取 .governance/plan-tracker.md，确认项目立项时定义的量化成功标准
  2. 偏离检查：对照成功标准，确认选型方向与项目总目标一致。如发现偏离，MUST 先记录到 .governance/decision-log.md 再继续
  3. 质量底线：选型决策必须有方案对比和"为什么不选其他"的理由（参考 profile 质量要求）

进入条件

  • 调研阶段已完成（G2 通过）
  • 有明确的调研结论和竞争分析支撑

活动清单

1. 选型范围确认

活动描述交互边界企业实践
列出待选型的技术领域框架、语言、数据库、部署方案、第三方服务等需用户确认：哪些领域需要正式选型[Amazon] 区分"必须选型"和"可快速决策"——不重要的用默认方案
确认选型优先级核心架构选型优先，周边工具可快速决策需用户确认[Amazon Bias for Action] 可逆选型（周边工具）快速决策，不可逆选型（数据/核心架构）深度评估
确认选型约束团队技能、公司技术栈、合规要求、预算限制需用户输入[华为] 约束条件必须在选型开始前显式列出，避免选完后才发现不兼容

2. 候选方案列举

活动描述交互边界企业实践
搜索候选方案每个领域至少列举 2 个候选，含主流方案和差异化方案自动执行（结果需人工验证）[Amazon] 不只列直接替代方案，也列"解决问题的不同方式"
建立评估维度许可证、性能、生态、学习曲线、团队熟悉度、维护活跃度、安全漏洞历史、社区响应速度自动执行 → 需用户确认[Google] 评估维度必须与项目成功标准对齐
填充评估矩阵逐候选按维度评估，标注评估置信度（实测/文档/推测）自动执行[ByteDance 数据驱动] 能量化的必须量化，不能量化的标注置信度

3. PoC 验证

活动描述交互边界企业实践
确定验证场景选型中最关键的不确定性需要 PoC 验证——不是"能跑起来"，而是"最可能失败的点"需用户确认：验证哪些关键假设[华为蓝军] PoC 验证"最可能失败的那个点"，不是"最容易通过的那个点"
定义通过标准每个验证场景有明确的通过/失败标准需用户确认[ByteDance] 没有预设标准的实验不是实验，是娱乐
执行 PoC搭建最小验证环境，在目标条件下测试需开发环境执行[Google] PoC 环境必须与目标环境足够接近，结论才有意义
记录 PoC 结果结论为"验证通过"、"风险可控"或"不推荐"；标注验证了什么/没验证什么自动执行[Amazon] PoC 结论必须诚实标注未验证的假设

4. 决策记录

活动描述交互边界企业实践
输出选型结论推荐方案 + 为什么选它 + 为什么不选其他候选自动执行[Amazon 6-Pager] 结论先写，再给证据——不是让人读完分析才知道结论
记录到决策日志决策编号、上下文、选择原因、备选方案、排除理由、可逆性自动执行[ByteDance Context not Control] 不只记录"选了什么"，更记录"为什么这样选"
用户确认确认选型结论需用户确认[Amazon Single-Threaded Owner] 最终决策有明确负责人

5. 长期可行性评估

活动描述交互边界企业实践
社区健康度评估贡献者多样性、issue 响应时间中位数、release 发布频率、是否有 bus factor 风险自动：GitHub/GitLab API 数据采集[Google] 开源项目的长期生命力取决于社区健康度而非 star 数
许可证合规审查许可证类型（copyleft/permissive）、与其他依赖的许可证兼容性、商业使用限制自动：许可证扫描 → 需用户确认：合规判断[华为] 许可证不合规是最容易被忽视的法律风险——选型阶段不审，后期改不了
替代成本估算如果未来需要迁移到替代方案，预估迁移成本（代码量、数据结构变更、团队学习曲线）自动：基于模块耦合度估算[Amazon] 可逆决策快速推进——但如果不可逆，必须知道"撤不回的代价"
技术债务风险评估deprecated API 使用量、breaking change 发布频率、已知的长期未修复 bug 数量自动：版本历史和 issue tracker 分析[ByteDance] 今天的选型 = 明天的技术债务——选之前先看对方自己有多少债

产出物标准

产出物格式要求质量标准企业实践来源
选型评估表≥2 候选 × ≥6 维度（许可证/性能/生态/学习曲线/维护/安全），有评分和置信度标注矩阵完整无空白；评分有依据（非纯主观）。重大选型决策使用 six-pager-template.md 进行结构化论证[Google] + [ByteDance] + [Amazon 6-Pager]
PoC 结果关键假设的验证结论 + 验证了什么/没验证什么结论明确（通过/风险可控/不推荐）；通过标准事先定义[华为蓝军] + [ByteDance]
决策记录选择原因 + 备选方案（≥2 个）+ 每个备选的排除理由 + 可逆性标注决策可追溯到评估矩阵；"为什么不选"比"为什么选"更有说服力[Amazon] + [ByteDance Context]

退出条件

  • 至少评估了 2 个候选方案（每个领域）
  • 评估标准在评估前已定义（≥6 个维度，含许可证和安全）
  • 选择原因已留痕（含"为什么不选"每个备选的具体理由）
  • 关键风险已通过 PoC 验证（PoC 有预设通过标准）
  • 选型结论已记录到决策日志（含可逆性标注）

Gate 映射

本阶段对应 G3 — 选型完成。

Gate 检查项对应活动判定标准自动化判定
是否评估了至少 2 个候选方案？候选方案列举选型评估表列出 ≥2 个候选可自动：计数检查
评估标准是否事先定义？候选方案列举≥6 个评估维度（含许可证/性能/生态/学习曲线/维护/安全）可自动：维度计数 + 关键词匹配关键维度
选择原因是否已留痕？决策记录决策记录有选择原因 + 备选方案 + 每个备选的排除理由可自动：检查字段完整性
"为什么不选"是否充分？决策记录每个被排除的候选有具体排除理由（非"不合适"等模糊表述）可自动：检查排除理由字段非空 + 长度 ≥20 字符
关键风险是否已通过 PoC 验证？PoC 验证PoC 结果文档存在，结论为"验证通过"或"风险可控"；通过标准事先定义可自动：检查 PoC 文件存在 + 通过标准字段
选型决策可逆性是否标注？决策记录每个选型决策标注可逆/不可逆可自动：检查可逆性字段

企业实践溯源

本子工作流的设计参考了以下企业实践，每条实践已映射到具体活动步骤：

企业核心实践映射到本工作流
AmazonBias for Action（可逆决策 70% 信息即推进）选型范围确认→可逆选型快速决策，不可逆选型深度评估
Amazon6-Pager（结论先行）决策记录→结论先写，再给证据
AmazonSingle-Threaded Owner决策记录→最终决策有明确负责人
GoogleDesign Doc（评估维度与成功标准对齐）候选方案列举→评估维度必须与项目目标对齐
GooglePoC 环境需接近目标环境PoC 验证→验证条件必须与生产条件足够接近
华为蓝军机制（验证最可能失败的点）PoC 验证→验证"最可能失败的点"，不是"最容易通过的点"
华为IPD 门控（约束条件前置）选型范围确认→约束条件必须在选型开始前显式列出
字节跳动数据驱动——能量化的必须量化评估矩阵→有评分有依据；PoC→有预设通过标准
字节跳动Context not Control（记录决策上下文）决策记录→不只"选了什么"，更记录"为什么这样选"

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free