Vibe Coding 可行性评估
把模糊的“AI 能不能做”转换成可解释、可复核的场景级判断。这里的“可实现度”是：在当前已知条件下，使用 Vibe Coding 直接完成该场景并达到可验收状态的适配度。它不是 AI 生成代码占比，也不是生产安全或合规认证。
使用边界
- 输入可以是需求文档、用户故事、会议纪要或一段业务描述。
- 评估原型、内部工具或生产系统时，必须明确目标层级；未说明时按“可供真实用户验收的 MVP”评估，并声明该假设。
- 不因能生成界面就判定整个场景可实现。数据、接口、权限、异常路径、部署和验证都属于实现范围。
- 不虚构接口、数据、凭据、合规结论或现有基础设施。信息不足时给出“初步评估”，列明假设和待确认项。
- 高风险领域仍可评估 Vibe Coding 的辅助价值，但必须把专业工程、法务、安全或领域专家参与标为人工边界。
工作流
1. 建立评估上下文
先提取：业务目标、目标用户、主要触发条件、期望结果、使用端、数据来源、外部系统、权限、目标交付层级和成功标准。
如果关键资料缺失但不妨碍方向判断，继续评估并显式列出假设；只有缺失信息会让结论发生根本变化时，才先询问。至少区分：
- 已知事实
- 合理假设
- 待确认事项
2. 切分业务场景
以“参与者 + 触发 + 目标 + 可验证结果”为一个场景，不要把每个页面机械地当成一个场景。以下变化通常需要拆分：
- 参与者或权限边界变化
- 进入外部系统、敏感数据区或人工审批
- 关键状态发生转换
- 主流程进入会改变结果的异常或补偿路径
- 同一能力在不同渠道的约束显著不同
覆盖端到端主路径、关键异常路径和后台管理路径。为每个场景分配唯一编号，并标记为“核心 / 支撑 / 边缘”。通常保持 3–12 个场景；需求很小时可以更少，复杂项目可以更多，但避免为了凑数切分。
3. 评分与设限
评估前读取 评分规则。对每个场景逐项记录证据，不能只给一个主观总分。
评分维度使用 0–4 分，并按规则中的权重换算为 0–100%。存在硬约束时应用上限；上限优先于加权分。每个低分或上限都要对应具体原因与解除条件。
需要稳定计算时，将评分写入 JSON 并运行：
python3 scripts/calculate_scores.py assessment.json
脚本输出场景分、场景结论、项目加权分、关键路径门槛、复杂度分和最终难度标签。不要为了得到更好看的结果反向调整输入分数。
4. 绘制业务流程图
用 Mermaid flowchart 展示业务流程，而不是展示本 Skill 的评估步骤。每个场景节点至少包含：编号、场景短名、可实现度百分比。保留真实的顺序、分支、人工节点和外部系统边界。
按百分比着色：
- 80–100：绿色，直接适合
- 60–79：黄色，基本适合
- 40–59：橙色，部分适合
- 0–39：红色，不适合直接实现
- 非代码人工活动：灰色虚线
流程不明确时给“推定流程图”，不要把推定内容写成已确认事实。Mermaid 代码应保持简洁、可渲染；节点文字避免未转义的特殊符号。
5. 形成项目级结论
项目分按场景重要性加权：核心 3、支撑 2、边缘 1。若业务方提供更合理的权重，采用业务方权重并说明。
同时应用关键路径门槛：
- 任一核心场景存在当前硬阻塞，项目总分最高为 39%。
- 任一核心场景低于 40% 但不构成硬阻塞，项目总分最高为 59%。
项目结论：
- 80–100：适合直接 Vibe Coding
- 60–79：基本适合，需工程补强
- 40–59：仅部分适合，建议混合实现
- 0–39：不适合直接实现，可考虑原型验证
难度与可实现度分开计算。低可实现度不自动等于“复杂”，高可实现度也不自动等于“简单”。按评分规则输出且只输出一个最终标签：【简单】、【中等】 或 【复杂】。
6. 输出可决策报告
按 报告模板 输出。结论必须包含：
- 项目总体可实现度百分比、结论、难度标签和置信度
- 场景流程图与颜色图例
- 每个场景的百分比、关键证据、主要缺口和建议实现方式
- 可直接 Vibe Coding、需专业工程补强、暂不应实现三类边界
- 阻塞项、解除条件、最少待确认问题和下一步建议
判断原则
- 证据优先：引用输入中的事实；推断必须标注为推断。
- 当前条件优先：缺失的接口、数据和权限不能按“以后会有”计入可实现能力。
- 关键路径优先：不能用大量简单页面稀释支付、权限、核心数据或关键集成的阻塞。
- 可验收优先：能生成代码但不能测试、部署或验证，不算直接实现。
- 生产约束优先：涉及资金、隐私、医疗、法律、关键基础设施或高可用承诺时，明确专业评审与人工责任。
- 建议可执行：每个阻塞项都给出解除条件，每个低分场景都给出适合的实现模式。
