用途
feasibility-reviewer 是一个系统架构评审技能，用于评估规划文档中提出的技术方案是否能在现实中成立，以及实现者能否在不做出重大架构决策的情况下直接依据该方案开始工作。它关注的是方案与既有代码、基础设施、框架约束之间的匹配程度，而非实现风格偏好。
主要能力
该技能围绕若干检查项展开，且仅在相关时应用：
- “已经存在什么？”：检查方案是否承认已有代码、服务和基础设施。如果提议新建某物，代码库中是否已有等价物？是否在棕地现实中假设绿地？此检查需要结合代码库阅读方案。
- 架构现实：所提方案是否与框架或技术栈冲突？是否假设基础设施不具备的能力？若引入新模式，是否处理与既有模式的共存？
- 影子路径追踪：对每个新数据流或集成点，追踪四条路径：正常（按预期工作）、空值（输入缺失）、空长度（输入存在但长度为零）、错误（上游失败）。对方案未涉及的路径生成发现。只描述正常路径的方案，是只在演示日有效的方案。
- 依赖：外部依赖是否被识别？是否存在未承认的隐式依赖？
- 性能可行性：所述性能目标是否与提议架构匹配？粗略估算即可。若目标缺失但工作对延迟敏感，则标记该缺口。
- 迁移安全：迁移路径是具体的，还是仅泛泛提及“迁移数据”？是否处理向后兼容、回滚策略、数据量和顺序依赖？
- 可实现性：工程师能否明天就开始编码？文件路径、接口和错误处理是否足够具体，还是实现者需要做出本应由方案完成的架构决策？
使用方式
该技能以系统架构师视角审阅规划文档，按相关性逐项应用上述检查。沉默仅在缺口会阻碍实现时才被视为发现。
置信度校准
- 高（0.80 以上）：具体技术约束阻碍方案，可具体指出。
- 中等（0.60-0.79）：约束可能存在，但取决于文档未载明的实现细节。
- 低于 0.50：完全抑制。
不标记的内容
- 实现风格选择（除非与既有约束冲突）
- 测试策略细节
- 代码组织偏好
- 无当前问题证据的理论可扩展性担忧
- 在提议方案可行时的“最好改成……”偏好
- 方案明确推迟的细节
适用场景
适用于技术规划文档的可行性评审，尤其是需要判断方案能否落地、实现者能否直接开工、迁移是否安全、性能目标是否合理等场景。
限制
该技能不评估实现风格、测试策略、代码组织偏好，也不处理无证据的理论可扩展性担忧。其检查项仅在相关时应用，且对置信度低于 0.50 的发现予以抑制。关于收费、价格、平台等具体信息，资料暂未提供。